Tài liệu overview of data modeling and database design pdf

¢ Translate an entity relationship diagram into a relational database design.. You also translate an entity relationship model into a relational database design.. e Translate an entity r

Overview of Data Modeling and

Database Design

ORACLE’

Objectives

¢ Describe the stages of system development

¢ List and define basic types of data relationships

¢ Define a relational database and its components

¢ Read an entity relationship diagram

¢ Translate an entity relationship diagram into a relational database design

8-2 Introduction to Oracle: SQL and PL/SQL Using Procedure Builder

Objectives

Before you build your tables, you design your database In this lesson, you

examine the data modeling process and relational database concepts, and define normalization You also translate an entity relationship model into a relational database design

At the end of this lesson, you should be able to

e Describe the stages of system development

e List and define basic types of data relationships

e Define a relational database and its components

e Read an entity relationship model

e Translate an entity relationship model into a relational database design

¢ Complete the system development cycle

¢ Model and design the database

¢ Meet the challenges to managing data with good

database design

8-4 Introduction to Oracle: SQL and PL/SQL Using Procedure Builder

Overview

When you create a database, you need to carefully consider its components For assistance with the design, you can follow the concepts outlined in this lesson

System Development Cycle

In order to logically and successfully create the database objects in the Oracle7

Server, you complete the system development cycle Each stage of the cycle contains specific activities that you perform to achieve the best possible database design Database Design

Database design is just one of the stages of the development cycle Through good database design, you can achieve a reliable, high-performance system

Challenges to Managing Data

There are many challenges you face as you design your system They range from controlling data redundancy to enhancing communications with users By meeting each of these challenges through good database design, you improve the performance

of your database

ORACLE’

System Development Cycle

¢ Database development

— ls atop-down, systematic approach

— Transforms business information requirements into an operational database

— Consists of five stages

¢ Once the design is in place, you can build the database by executing SQL commands

Build

and Document

System Development Cycle

From concept to production, develop a database by using the system development cycle The cycle contains multiple stages of development This top-down, systematic approach to database development transforms business information requirements into

an operational database

Stages of Development

Strategy and Analysis

e Study and analyze the business requirements Interview users and managers to identify the information requirements Incorporate the enterprise and application mission statements as well as any future system specifications

e Build models of the system Transfer the business narrative developed in the strategy and analysis phase into a graphical representation of business information needs and rules Confirm and refine the model with the analysts and experts Design

e Design the database The entity relationship model maps entities to tables,

attributes to columns, relationships to foreign keys, and business rules to

constraints

Build and Document

e Build the prototype system Write and execute the commands to create the tables and supporting objects for the database

e Develop user documentation, help-screen text, and operations manuals to support the use and operation of the system

e Roll out the system to the users Operate the production system Monitor its

performance, and enhance and refine the system

— Integration with other systems

— Documentation and communication

Database Design

Designing a relational database system involves converting a model into a workable software representation The entities (or objects) perceived by the user are

transformed into tables in the database All forms of design involve a mixture of

rules, judgements, and common sense, and relational design is no different

During a design effort, your goal is to design reliable, high-performance systems using the deliverables from the analysis effort The following key factors describe in detail why you should bother to design at all

Integration with Other Systems

Often, there are requirements that a new system integrate with existing systems, or even with systems yet to be built Good design extends the integration benefits

mentioned above into corporate or worldwide systems

Documentation and Communication

A major part of a designer’s job is to communicate design decisions to others At the

very least, these decisions need to be documented

Scalability

Tackle performance issues during design rather than during production For example, developing an application in a small, controlled environment does not test real-world situations or a large set of data, factors that can reveal design flaws

Avoid Reinventing the Wheel

The objective is to produce a model that fits a multitude of these uses, can be

understood by an end user, but contains sufficient detail for a developer to build a

database system

ORACLE’

Benefits of Entity Relationship Models

¢ Communicate concepts in people’s minds

¢ Effective for collecting and documenting an

organization’s information requirements

¢ Provide an easily understood pictorial map of the

system

¢ Can be easily developed and refined

¢ Clearly define the scope of the information needs

¢ Separate the information required by a business from

the activities performed by the business

— Something that describes or qualifies an entity

— Examples: name, phone, identification number

¢ Relationship

— Anassociation between two entities

— Examples: orders and items, customers and sales

8-12 Introduction to Oracle: SQL and PL/SQL Using Procedure Builder

Entity Relationship Modeling

Entity relationship models are derived from business specifications or narratives This model is a graphical representation of business information needs and rules

Entity Relationship Models

Entity relationship models separate the information required by a business from the activities performed within a business Although businesses can change their

activities, the type of information tends to remain constant Therefore, the data

structures also tend to be constant

Benefits of Entity Relationship Models

Documents information requirements for the organization in a clear, precise

format

Provides an easily understood pictorial map for the database design

Develops and refines the model easily

Provides a clear picture of the scope of the information requirements

Offers an effective framework for integrating multiple applications, development projects, and purchased application packages

Attribute Something that describes or qualifies an entity

Relationship A named association between entities showing optionality

or degree

ORACLE’

Entity Relationship Model

¢ Create an entity relationship diagram from business specifications or narratives

CUSTOMER : EMPLOYEE

# id assigned to wid

* name the sales * last name

o phone rep to °o first name

Singular, unique name Singular name

Synonym in parentheses Mandatory marked with "*"

Optional marked with "o"

CUSTOMER assigned to EMPLOYEE

# id KR _-_-_- _- _— _—_ #* = id

* name the sales | * last name

o phone rep to °o first name

Unique Identifier (UID)

Primary marked with "#"

Secondary marked with "(#)"

8-14 Introduction to Oracle: SQL and PL/SQL Using Procedure Builder

Entity Relationship Model Concepts

An entity relationship model is composed of entities, attributes, and relationships Entities

An entity represents a thing of significance about the business system, or a discrete category or collection of related data Examples are customer, orders, and employees

To represent an entity in a model, use the following conventions:

e Soft box with any dimensions

e Singular, unique entity name

e Entity name in uppercase

e Optional synonym names in uppercase within parentheses ““()”

Attributes

An attribute describes entities and holds the specific information that should be

known about an entity For example, for the customer entity, the attributes would be customer number, name, phone number, and address

If an entity does not have attributes that need to be known from the business

viewpoint, then it is not within the scope of the system requirements, and should not appear in the model

Each of the attributes is either required or optional This state is called optionality

To represent an entity in a model, use the following conventions:

e Use singular names in lowercase

e Tag mandatory attributes, or values that must be known, with an asterisk “*”’

e Tag optional attributes, or values that may be known, with an “o”

Unique Identifiers

A unique identifier (UID) is any combination of attributes or relationships, or both, that serves to distinguish occurrences of an entity Each entity occurrence must be uniquely identifiable

e Tag each attribute that is part of the UID with a number symbol (#)

e Tag secondary UIDs with a number sign in parentheses (#)

the client o name phone

for

Degree - One and only one

Entity Relationship Model Concepts continued

Relationships

Each entity must have a relationship that represents the information requirements and rules of the business The relationship is a two-directional association between two entities, or between an entity and itself When an entity has a relationship with itself,

it is recursive

Each direction of the relationship contains

e A name, for example, taught by or assigned to

e An optionality, either must be or may be

e A degree, either one and only one or one or more

Note: Cardinality is a synonym for the term degree

Relationship Syntax

Each source entity {may be | must be} relationship name {one and only one | one or more} destination entity

Note: Convention is to read clockwise

Relationship Diagramming Conventions

Dashed line Optional element indicating “may be.”

Solid line Mandatory element indicating “must be.”

Crow’s foot Degree element indicating “one or more.”

Single line Degree element indicating “one and only one.”

— Are very common

— Example: passengers and plane

¢ Many-to-many

— Have a degree of one or more in both directions

— Are resolved with an intersection entity

— Example: Employees and skills

Entity Relationship Model Subset

Entity Relationship Model Concepts continued

Unique Identifier Through the Relationship

An entity may be uniquely identified through a relationship Use a UID bar to

indicate that a relationship is part of the entity’s unique identifier The relationship included in a UID must be mandatory and one and only one in the direction that participates in the UID

Example

When you order items, you have an order number and an item with a unique line item number But when another order is placed, that item number is no longer unique Therefore, the item is uniquely identified by its attribute number and the specific order number to which the item is related

One-to-one Degree of one and only one in both directions These types

are rare, and may really be the same entity, or an attribute

of the entity

Many-to-one Degree of one or more in one direction and a degree of one

and only one in the other direction Very common

ORACLE’

Normalization

Benefits

¢ Minimizes data redundancy

¢ Reduces integrity problems

¢ Identifies missing entities, relationships, and tables

First normal form All attributes must be single-valued

Second normal form | An attribute must depend upon its entity's

entire UID

Third normal form No non-UID attribute can be dependent upon

another non-UID attribute

Entity Relationship Model Concepts continued

e Minimizes data redundancy

e Reduces integrity problems

e Identifies missing entities, relationships, and tables

Third normal form (3NF) No non-UID attribute can be dependent upon

another non-UID attribute

ORACLE’

Integrity Constraints

¢ Ensure data consistency

¢ Should be enforced by the database server or the application software

Integrity Constraints and Keys

Ensure that users perform only operations that leave the database in a correct and consistent state by enforcing data integrity constraints All data integrity constraints should be enforced by the database server or the application software Keys

correspond to integrity constraints The three types of keys are primary key, unique key, and foreign key

Entity No part of a primary key can be NULL and the

value must be unique

Referential Foreign key values must match a primary key or be

Examples of User-Defined Data Integrity Constraints

e Anemployee in the finance department cannot have a title of programmer

e A salesperson’s commission cannot exceed 50% of the base salary

e Customers can only have Excellent, Good, or Poor credit rating values

ORACLE’

Defining a Primary Key

¢ Aprimary key (PK) allows no duplicate values and cannot