Download as pdf or txt
Download as pdf or txt
You are on page 1of 22

Database Management Systems

Module 2

Introduction to Modeling
Objectives
• Definition of terms
• Importance of data modeling
• Describe the phases of the database and
application development life cycle
• Identify which modeling approach to use
for a given situation
Business Rules
• Statements that define or constrain some
aspect of the business
• Assert business structure
• Control/influence business behavior
• Expressed in terms familiar to end users
• Automated through DBMS software
A Good Business Rule is:
• Declarative–what, not how
• Precise–clear, agreed-upon meaning
• Atomic–one statement
• Consistent–internally and externally
• Expressible–structured, natural language
• Distinct–non-redundant
• Business-oriented–understood by
business people
A Good Data Name is:
• Related to business, not technical,
characteristics
• Meaningful and self-documenting
• Unique
• Readable
• Composed of words from an approved list
• Repeatable
Data Definitions
• Explanation of a term or fact
– Term–word or phrase with specific meaning
– Fact–association between two or more terms
• Guidelines for good data definition
– Gathered in conjunction with systems requirements
– Accompanied by diagrams
– Iteratively created and refined
– Achieved by consensus
Conceptual Data Modeling
• A conceptual data model is a detailed
model that shows the overall structure of
organizational data while being
independent of any database
management system or other
implementation considerations. Its
purpose is to show as many rules about
the meaning and interrelationships among
data as possible.
Process
• The first step is to develop a data model
for the current system.
• Next, build a new data model that includes
all the data requirements for the new
system.
• In the design stage, the conceptual model
is translated into a physical design.
Why Model?
•Top Five Reasons to Model
– Easy to Change
– Communication Method to
Gather Requirements
– Business Rules Validation
– Target User Involvement
– Documentation

What other reasons can you think of?


Why Model: A Practical Example
•Building a House
– The architect develops
the plan.
– The future home owners
approve the plan and hire
a builder.
– The builder determines
the timing, supplies, and
people needed to build
the house.
Database and Application Development Life
Cycle Information Requirements
Strategy and Analysis
Application Requirements
Strategy and Analysis
Logical Data Process
Modeling Cross-Checking Modeling
Entity Relationship
Diagram
Data Flow Diagram

Design
Database
Design Application
Relational and Physical Design
Model: Table, View, etc.

Generation Application
Database Development
Generation
SQL Script

Application

Database
Process Modeling

Data Flow Diagram


Process
Modeling

Application
Design

Application
Development

Application
Logical Data Modeling
Information Requirements

Entity Relationship Diagram


Logical Data
Modeling

Database
Design

Database
Generation

Database
Database Design
Information Requirements Relational Model

Logical Data
Modeling

Database
Design

Database
Generation

Database
Database Generation

SQL Script
CREATE TABLE DEPARTMENTS
Information Requirements (
ID NUMBER (6) NOT NULL ,
Name VARCHAR2 (50)

Logical Data
);
ALTER TABLE DEPARTMENTS

Modeling ADD CONSTRAINT DEPARTMENT_PK PRIMARY KEY ( ID ) ;


CREATE TABLE EMPLOYEES
(
ID NUMBER (6) NOT NULL ,
First Name VARCHAR2 (50) ,

Database Last Name VARCHAR2 (50) ,


Email VARCHAR2 (30) ,

Design Phone Number VARCHAR2 (20) ,


Hire Date DATE ,
Salary NUMBER (8,2) ,
Commission Percentage NUMBER (2,2) ,
DEPARTMENT_ID NUMBER (6) NOT NULL
Database );
ALTER TABLE EMPLOYEES
Generation ADD CONSTRAINT EMPLOYEE_PK PRIMARY KEY ( ID ) ;
ALTER TABLE EMPLOYEES
ADD CONSTRAINT Relation_1 FOREIGN KEY
(
DEPARTMENT_ID
)
REFERENCES DEPARTMENTS
(
ID
Database );
Data Type Model
•User data types that can be used in a
logical data model or relational design

Logical Data Model


Relational Model
Multidimensional Model
A model of business activities in terms of facts and
dimensions

Attributes

Measures

Cube

Dimensions Levels
Approaches to Modeling
– Top-down modeling
– Bottom-up modeling
– Targeted modeling

Database

Database
Synchronized Synchronized
Models Models

Database
Top-Down Modeling
Top-Down Modeling: Designing a New Database

1. Business information
2. One process model (DFD)
3. One logical data model
(ERD)
4. One multidimensional model
5. One or more relational
models
6. One or more physical
models for each relational
model
Database
Bottom-Up Modeling
Bottom-Up Modeling: Modifying an Existing Database

1. Produce a relational model.


2. Modify the relational model
and create additional
relational models.
3. Reverse engineer the logical
model from the relational
model.
4. Modify and check the design
rules for the logical model.
5. Generate the modified DDL
code. Database
Targeted Modeling
Targeted Modeling: Maintaining Existing Models by
Adapting to New Requirements
1. Change the logical data
model.
2. Engineer to modify the
relational model. Synchronized Models

2. Engineer to modify the logical


data model.
1. Change the relational data
model.
Database
Summary
• In this lesson, you should have learned
how to:
– List the reasons why modeling is important
– Describe the phases of the database and
application development life cycle
– Identify which modeling approach to use for
a given situation

You might also like