DBMS

DATABASE
DESIGN
Presented by:

TRI_QUAD TEAM
 LEARNING OUTCOMES
In this chapter, you will learn to:
Understand that successful database design must align
with the broader information system it supports.MISSION
Explain how successful information systems are developed
using the Systems Development Life Cycle (SDLC).
Recognize that databases require frequent evaluation and
updates following the Database Life Cycle (DBLC).
Compare different database design strategies, including
top-down vs. bottom-up and centralized vs. decentralized
design approaches.
THE INFORMATION SYSTEM
Provides for data collection, storage, and retrieval
Composed of
- People, hardware, software
- Database(s), application programs, procedures
Systems analysis
- Process that SERVICE
establishes
02 need for and extent of information system
Systems development
- Process of creating information system
 THE INFORMATION SYSTEM (CONT’D.)
Applications
Transform data into the information that forms the basis for
decision making

Usually produce the following:

- Formal report
- Tabulations
- Graphic displays

Composed of the following two parts:

- Data
- Code (program instructions)
THE INFORMATION SYSTEM (CONT’D.)
Performance depends on three factors:
- Database design and implementation
- Application design and implementation
- Administrative procedures

Database development
SERVICE 02
- Process of database design and implementation
- Implementation phase includes:
Creating database storage structure
Loading data into the database
Providing for data management
 THE SYSTEMS DEVELOPMENT
LIFE CYCLE (SDLC)
Traces history (life cycle) of information system
Database design and application development mapped out
and evaluated
Divided into the following five phases:
Planning
Analysis
Detailed Systems Design
Implementation
Maintenance
Iterative rather than sequential process
 THE SYSTEMS
DEVELOPMENT LIFE
CYCLE (SDLC)
(CONT’D.)
THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) (CONT’D.)
Planning
General overview of company and objectives

Assessment of flow-and-extent requirements

Should the existing system be continued?
Should the existing system be modified?
Should the existing system be replaced?

Study and evaluate alternate solutions

Technical aspects of hardware and software requirements
System cost
Operational cost
THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) (CONT’D.)
Analysis
Problems defined during planning phase are examined in greater
detail during analysis

Thorough audit of user requirements

Existing hardware and software systems are studied

Goal:
Better understanding of:
System's functional areas
Actual and potential problems
Opportunities
THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) (CONT’D.)

Detailed System Design

Designer completes design of system's processes

Includes all necessary technical specifications

Steps laid out for conversion from old to new system

Training principles and methodologies are also planned

Submitted for management approval
THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) (CONT’D.)
Implementation

Hardware, DBMS software, and application programs are

installed
Database design is implemented

Cycle of coding, testing, and debugging continues until database

is ready for delivery

Database is created and system is customized

Creation of tables and views
User authorizations
THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) (CONT’D.)

Maintenance

Three types of maintenance activity:

Corrective maintenance
Adaptive maintenance
Perfective maintenance

Computer-aided systems engineering (CASE)

Produce better systems within reasonable amount of time
and at reasonable cost
CASE-produced applications are structured, documented,
and standardized
 ICEBREAKER
"Guess the Baby Picture!"

Each slide will show a baby picture.

Your task: Guess who it is!

5 points for the person who guessed correctly.

Use the raise hand button.

ICEBREAKER

MISSION
ICEBREAKER

MISSION
ICEBREAKER

MISSION
ICEBREAKER

MISSION
ICEBREAKER

MISSION
ICEBREAKER

MISSION
ICEBREAKER

MISSION
 THE
DATABASE
LIFE CYCLE
(DBLC)
 THE DATABASE LIFE CYCLE (DBLC) (CONT’D.)

The Database Initial Study

Overall purpose:
- Analyze company situation
- Define problems and constraints
- Define objectives
- Define scope and boundaries

Interactive and iterative processes required to complete

first phase of DBLC successfully
 THE
DATABASE
LIFE CYCLE
(DBLC)
(CONT’D.)
 THE DATABASE LIFE CYCLE (DBLC) (CONT’D.)

Database Design
Necessary to concentrate on data characteristics required
to build database model

Two views of data within system:

- Business view
Data as information source
- Designer's view
Data structure, access, and activities required to
transform data into information
 Two views of data

THE
DATABASE
LIFE CYCLE
(DBLC)
(CONT’D.)
 THE DATABASE LIFE CYCLE (DBLC) (CONT’D.)

Database
design
process
 THE DATABASE LIFE CYCLE (DBLC) (CONT’D.)

Implementation and Loading

Actually implement all design specifications from previous
phase:
- Install the DBMS
Virtualization: creates logical representations of
computing resources independent of physical resources
- Create the Database
- Load or Convert the Data
 THE DATABASE LIFE CYCLE (DBLC) (CONT’D.)

Testing and Evaluation

Test the Database
Integrity and Security
Access Control Measures
Audit trails and Data Encryption
Fine-Tune the Database
Optimize Performance
Evaluate Database and Application Programs
Perform system-wide testing
Refine Deployment Plans, Conduct User training,
and Finalize Documentation
Test Backup and Recovery Plans
 THE DATABASE LIFE CYCLE (DBLC) (CONT’D.)
Operation
Once database has passed evaluation stage, it is considered
operational.

The beginning of operational phase starts the process of

system evolution.

Problems not foreseen during testing surface.

Solutions may include:

- Load-balancing software to distribute transactions among
multiple computers
- Increasing available cache
 THE DATABASE LIFE CYCLE (DBLC) (CONT’D.)

Maintenance and Evolution

Required periodic maintenance:
- Preventive maintenance (backup)
- Corrective maintenance (recovery)
- Adaptive maintenance
- Assignment of access permissions and their
maintenance for new and old users
- Generation of database access statistics
- Periodic security audits
- Periodic system-usage summaries
CONCEPTUAL DESIGN
Data modeling creates an abstract database structure
-Represents real-world objects

Embodies a clear understanding of business and its functional areas

Ensure that all data needed are in model, and that all data in model
are needed

Requires four steps:

1. Data Analysis and Requirements
2. Entity Relationship Modeling and Normalization
3. Data Model Verification
4. Distributed Database Design
 CONCEPTUAL DESIGN (CONT’D.)

Data Analysis and Requirements

Discover data element characteristics

-Obtains characteristics from different sources

Requires thorough understanding of the company’s

data types and their extent and uses

Take into account business rules

-Derived from description of operations
 CONCEPTUAL DESIGN (CONT’D.)

Entity Relationship Modeling and Normalization

Designer enforces standards in design documentation

- Use of diagrams and symbols, documentation writing

style, layout, other conventions

Business rules must be incorporated into conceptual model

ER model is a communications tool as well as design blueprint

Normalize the tables

CONCEPTUAL DESIGN (CONT’D.)
CONCEPTUAL DESIGN (CONT’D.)

Data Model Verification

• Verified against proposed system processes

• Revision of original design

-Careful re-evaluation of entities
-Detailed examination of attributes describing entities

• Define design’s major components as modules:

-Module: information system component that handles specific
function
CONCEPTUAL DESIGN (CONT’D.)

Dristibuted Database Design

Distributed database design is used when a database needs to be spread
across multiple geographic locations, which may involve varying access
processes
Ex: retail and warehouse operations may necessitate separate
physical databases.

Portions of the database, known as database fragments, consist of

specific subsets of data (rows or columns) stored in different locations.

The design focuses on creating an optimal allocation strategy for these

fragments, ensuring database integrity, security, and performance.
DBMS SOFTWARE SELECTION
Critical to information system’s smooth operation

Common factors affecting purchasing decisions:

Cost
DBMS features and tools
Underlying model
Portability
DBMS hardware requirements
LOGICAL DESIGN
Logical design is the second stage in database design, aiming
to create an enterprise-wide database based on a specific
data model, independent of physical details. It involves
mapping all objects from the conceptual model to the chosen
database model. In relational databases, this includes defining
tables, relationships, and constraints such as domain
definitions, data validations, and security views.
 LOGICAL DESIGN (CONT’D.)
Logical Design Steps

1. Map the Conceptual Model to the Logical Model

The first step in logical design is mapping the conceptual model to

the chosen database structure. In the case of relational databases,
this involves translating the ER model into relations (tables),
columns, and constraint definitions. This process is commonly
used in database design projects today.
LOGICAL DESIGN (CONT’D.)
 LOGICAL DESIGN (CONT’D.)
Logical Design Steps

2. Validate the Logical Model Using Normalization

During logical design, all tables must be properly normalized,

ideally in third normal form (3NF). The process may reveal new
attributes or tables, requiring further refinement. Normalization
ensures that attributes are fully dependent on the primary key
and prevents data anomalies. Database design is iterative, with
normalization happening at different stages to improve the
model.
 LOGICAL DESIGN (CONT’D.)
Logical Design Steps
3. Validate Logical Model Integrity Constraints

When translating the conceptual model to the logical model,

define attribute domains, enforce constraints, and ensure entity
and referential integrity. Specify user access and security through
views, especially for distributed databases. Finally, validate the
model against end-user requirements.
 LOGICAL DESIGN (CONT’D.)
Logical Design Steps

4. Validate the Logical Model against User Requirements

In the final step of logical design, validate the model against end-
user data, transaction, and security requirements. This ensures
the logical model aligns with user needs before defining the
system's physical requirements for the selected DBMS and
hardware environment.
PHYSICAL DESIGN
Process of selecting data storage organization and data access
characteristics of the database.

Storage characteristics are function of:

- Device types supported by hardware
- Type of data access methods supported by system
- DBMS
More complex when data are distributed .
PHYSICAL DESIGN (CONT’D.)
Physical Design Steps
1. Define Data Storage Organization

Designer must determine several attributes:

Data volume
Data usage patterns
SERVICE 02
Which in turn influence:
Location and physical storage organization for each table
What indexes and the type of indexes to be used for each table
What views and the type of views to be used on each table
PHYSICAL DESIGN (CONT’D.)
Physical Design Steps
2. Define Integrity and Security Measures

Define user and security groups and roles

Database role: set of database privileges that could be assigned as a
unit to a user or group
SERVICE 02
Assign security controls
Specific access rights on database objects to a user or group of users
Can also revoke during operation to assist with backups or
maintenance events
PHYSICAL DESIGN (CONT’D.)
Physical Design Steps
3. Determine Performance Measures

Performance can be affected by characteristics:

Storage media
Seek time
Sector and block (page) size
Buffer pool sizeSERVICE 02
Number of disk platters

Fine-tuning the DBMS and queries to ensure that they will meet
end-user performance requirements
DATABASE DESIGN STRATEGIES
Top-down design
Identifies data sets
Defines data elements for each of those sets
Definition of different entity types
Definition of each entity’s attributes

Bottom-up design
Identifies data elements (items)
Groups them together in data sets
DATABASE DESIGN STRATEGIES (CONT’D.)
 CENTRALIZED VS.
DECENTRALIZED DESIGN
Centralized design
When data component is composed of small number of
objects and procedures
Typical of small systems

Decentralized design
Data component has large number of entities
Complex relations on which complex operations are performed
Problem is spread across several operational sites
CENTRALIZED VS. DECENTRALIZED DESIGN (CONT’D.)
CENTRALIZED VS. DECENTRALIZED DESIGN (CONT’D.)
 SUMMARY
Information system facilitates transformation of data into information
Manages both data and information
SDLC traces history (life cycle) of an application within the information
system
DBLC describes history of database within the information system
Database design and implementation process moves through series of
well-defined stages
Conceptual design subject to several variations:
Top-down vs. bottom-up
Centralized vs. decentralized
THANK YOU!
DBMS | Database Design

TRI-QUAD TEAM