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

The entity relationship model maps entities to tables, attributes to columns, relationships to foreign keys, and business rules to constraints.. Overview of Data Modeling and Database De

Trang 1

Overview of Data Modeling and

Database Design

8

Trang 2

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

Schedule: Timing Topic

40 minutes Lecture

40 minutes Total

Class Management Note:

Files required for this lesson are:

Demonstration: None

Practice: None

Trang 3

Overview of Data Modeling and Database Design 8Ć3

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

D Describe the stages of system development

D List and define basic types of data relationships

D Define a relational database and its components

D Read an entity relationship model

D Translate an entity relationship model into a relational database design

Trang 4

This lesson is an overview to the DDL lessons Please remember that as an

overview, you are presenting basic concepts Students can gain additional information about this topic from the Concepts Manual and by attending the

Develop Complex Data Models and Design Database course.

Trang 5

Overview

When you create a database, you need to carefully consider its components Forassistance 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 Oracle7Server, you complete the system development cycle Each stage of the cycle containsspecific 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 gooddatabase 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 fromcontrolling data redundancy to enhancing communications with users By meetingeach of these challenges through good database design, you improve the performance

of your database

Trang 6

Trang 7

System Development Cycle

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

an operational database

Stages of Development

Strategy and Analysis

D Study and analyze the business requirements Interview users and managers toidentify the information requirements Incorporate the enterprise and applicationmission statements as well as any future system specifications

D Build models of the system Transfer the business narrative developed in thestrategy and analysis phase into a graphical representation of business informationneeds and rules Confirm and refine the model with the analysts and experts

Design

D 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

D Build the prototype system Write and execute the commands to create the tablesand supporting objects for the database

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

Trang 8

Trang 9

Integration with Other Systems

Often, there are requirements that a new system integrate with existing systems, oreven 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 thevery 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-worldsituations or a large set of data, factors that can reveal design flaws

Avoid Reinventing the Wheel

Many of the problems you will face will have been encountered by others before you.Use existing successful design solutions wherever you can

Trang 10

Trang 11

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 adatabase system

Trang 12

Trang 13

Entity Relationship Modeling

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

Entity Relationship Models

Entity relationship models separate the information required by a business from theactivities 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

D Documents information requirements for the organization in a clear, preciseformat

D Provides an easily understood pictorial map for the database design

D Develops and refines the model easily

D Provides a clear picture of the scope of the information requirements

D Offers an effective framework for integrating multiple applications, developmentprojects, and purchased application packages

Key Components

Component Description

Entity A thing of significance about which information needs to

be known

Attribute Something that describes or qualifies an entity

Relationship A named association between entities showing optionality

or degree

Trang 14

Trang 15

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 discretecategory or collection of related data Examples are customer, orders, and employees

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

D Soft box with any dimensions

D Singular, unique entity name

D Entity name in uppercase

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

Attributes

An attribute describes entities and holds the specific information that should beknown about an entity For example, for the customer entity, the attributes would becustomer 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 notappear 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:

D Use singular names in lowercase

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

D 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 beuniquely identifiable

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

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

Trang 16

Trang 17

Entity Relationship Model Concepts continued

Relationships

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

it is recursive

Each direction of the relationship contains

D A name, for example, taught by or assigned to.

D An optionality, either must be or may be.

D 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

Symbol Description

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.”

Note for page 8-18

Question: Name some examples of these types of relationships in the topslide

Trang 18

Trang 19

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 relationshipincluded in a UID must be mandatory and one and only one in the direction thatparticipates in the UID

Example

When you order items, you have an order number and an item with a unique line itemnumber 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 specificorder number to which the item is related

Order number Item number Product number

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

Many-to-many Degree of one or more in both directions Very common

Resolve them with an intersection entity

Trang 20

Trang 21

D Minimizes data redundancy

D Reduces integrity problems

D Identifies missing entities, relationships, and tables

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

another non-UID attribute

Trang 22

Trang 23

Integrity Constraints and Keys

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

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

Integrity Constraint Type Description

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

NULL

Column Values in the column must match the defined

datatype

User-defined Values must comply with the business rules

Examples of UserĆDefined Data Integrity Constraints

D An employee in the finance department cannot have a title of programmer

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

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

User-defined data integrity constraints can be set by management policy or

be required by laws Frequently, these business rules reflect business

Trang 24

Trang 25

Integrity Constraints and Keys continued

Primary Keys

Each row in the table is uniquely identified by a column or set of columns called aprimary key (PK) The primary key is defined as allowing no duplicate values andcannot be NULL

A primary key consisting of multiple columns is called a composite primary key or acompound primary key The columns of a composite primary key must be unique incombination, although the individual columns can have duplicates No part of aprimary key can contain a null value

Candidate Keys

A table can have several candidate keys A candidate key is a column or combination

of columns that can serve as the primary key for the table

Select one candidate key to be the primary key for the table The other candidates

become alternate keys or unique keys They must be UNIQUE and NOT NULL.

The concept of manipulating a set of information at a time will seem

strange to participants who have worked only with third generation

languages (3GLs)

Technical Note:

Rows are unique in a table, but rows do not have names like columns ortables You cannot use row order to access a specific row; instead, use thecontent of a row to access the row Relate this back to the roles in the datamodel: each instance of an entity must be uniquely identifiable

Primary keys are not syntactically or structurally required to crate tables,even within the Oracle7 Server Create primary keys if you expect theServer to enforce data integrity

Trang 26

Trang 27

Integrity Constraints and Keys continued

Foreign Keys

A foreign key (FK) is a column or combination of columns in one table that refers to

a primary key or unique key in the same table or in another table Foreign keys arebased on data values and are purely logical, not physical pointers A foreign keyvalue must match an existing primary key value or unique key, or else be NULL If aforeign key is part of a primary key, it cannot contain a null value because no part of

PRODUCT_ID 10011 10013 30421 41010 20180

DATE_ORDERED31-AUG-9231-AUG-9201-SEP-9202-SEP-92

Primary Key Foreign Key

Trang 28

Trang 29

Designing the Database

The database design stage produces design specifications for a relational database,including definitions for relational tables, indexes, views, and storage space

Map the Entity Relationship Model to a Table Instance Chart

1. Map the simple entities to tables

2. Map the attributes to columns and document sample data Clearly label the

column names and their associated generic datatypes; for example, character,number, or date

3. Map the unique identifiers to a primary key Be sure to include any foreign keycomponents of the primary key

4. Map relationships to foreign keys

Additional Requirements

D Design the indexes, which are database objects that provide direct, quick access torows You may want to create indexes for alternate keys, foreign keys, and

columns frequently used in the search condition

D Establish view definitions, which are logical tables based on one or more tables orviews Views can restrict access, provide improved presentation of information,and can contain a pre-packaged complex query

D Plan the physical storage space, which is the amount of space required to store thedata of a table in the database

D Redefine integrity constraints

For more information, see

Develop Complex Data Models and Design Databases course description.

Tiêu đề	Overview of Data Modeling and Database Design
Trường học	Oracle University
Chuyên ngành	Database Design
Thể loại	Bài giảng

Định dạng
Số trang	40
Dung lượng	314,58 KB