6 copyright © 2006, oracle. all rights reserved. developing data models for business databases...

6Copyright © 2006, Oracle. All rights reserved.

Developing Data Models for Business Databases

(Part II)

6.2 - 2

Finalizing (完成 ) an ERD

Data model is not complete without

• Adequate design documentation

• Careful consideration of design errors

6.2 - 3

Documenting an ERD

• Important for resolving questions and

communicating a design

• Identify inconsistency and incompleteness in a

specification

• Identify situations when more than one feasible

alternative exists

• Do not repeat the details of the ERD

• Incorporate documentation (文件 ) into the ERD

6.2 - 4

Documentation Example : Data Dictionary(Employee Entity)

Attributes DescriptionData type and length

Domain characteristics

Keys Nulls Default

EmpNo 員工編號 VARCHA(5) S+0001-9999 ；如：S0001

PK N

FName 員工的名 VARCHAR(20)

N

LName 員工的姓 VARCHAR(20)

N

Address 員工的通訊地址

VARCHAR(50)

N

Sex 員工的姓別 CHAR(1) ‘ M’ 或 ‘ F ’ N ‘M’

HireDate 雇用日期 Date N Date()

Position 員工的職位 VARCHAR(20)

‘Manager’,‘Supervisor’, or ‘Assistant’

N ‘Assistant’

Salary 員工的薪資 NUMBER(8) N

Email 員工的eMail

VARCHAR(20)

AK Y

6.2 - 5

Documentation with the ER Assistant

Documented in Comment

1. Entity type comments

2. Attribute comments

3. Relationship comments

1

2

3

6.2 - 6


Design Justifications ( 設計的理由 )

• Numbered

• Arrange in the diagram so that the numbers

indicate the applicable part of the ERD

• Explain choice among feasible alternatives

• Explain design subtleties ( 微妙處 )

6.2 - 7


Drag-and-drop to move the symbols

Click New to create a new Design Justification

1

24

3

5

6.2 - 8

Common Design Errors

More difficult to detect and resolve than diagram errors

• Design errors involve the meaning (semantics) of

ERD components, not just the structure (notation) of

components

Types of Common Design Errors

1. Misplaced Relationships

– In a large ERD, it is easy to connect the wrong entity

types.

6.2 - 9


2. Missing relationships

– Sometimes the requirements do not directly

indicate a relationship

– Consider indirect implications ( 間接的隱含意義 )

to detect whether a relationship is required.

– Example:

The requirements for Water Utility Database do

not directly indicate the need for a relationship

from Bill to Reading.

6.2 - 10


3. Incorrect Cardinalities

– A typical error involves the usage of a 1-M

relationship instead of a M-N relationship.

— This error can be caused by an omission in the

requirements.

– Reversed cardinality

— 1-M instead of M-1

– Errors on minimal cardinality

— 0 or 1

6.2 - 11


4. Overuse of specialized modeling constructs: Generalization hierarchies and M-way associative

entity type are specialized modeling constructs.

– Generalization hierarchies should not be used just

because an entity can exist in multiple states.— Example:

A project task can be started, in process, or

complete

– An M-way associative entity type should be used

when the database is to record combinations of

three (or more) entity types rather than just

combinations of two entity types.

6.2 - 12

Common Design Errors

5. Redundant Relationships

– Connection cycles in an ERD may indicate

redundant relationships.

– A relationship is redundant if it can be derived

from other relationships.

6.2 - 13

Redundant Relationships Example• Cycle relationships: Customer, Bill, Reading, and Meter• For the SentTo relationship, the bills associated with a customer can

be derived from the relationships Uses1, ReadBy2, and Includes3. In the opposite direction, the customer associated with a bill can be

derived from the Includes1, ReadBy2, and Uses3.

Uses CustNo

CustomerMeterNo

Meter

ReadNo

Reading

ReadBy

AssignedRateSetNo

RateSet

SentTo

IncludesBillNo

Bill

EmpNo

Employee

Performs

MinUsage

Rate

Contains

6.2 - 14

Final Water Utility ERD

RateSetNoRSAapprDateRSEffDateRateDesc

RateSetCustNoCustNameCustAddrCustType

Customer

BillNoBillDateBillStartDateBillEndateBillDueDAte

Bill

ReadNoReadTimeReadLevel

Reading

MeterNoMtrSizeMtrAddrMtrModel

Meter

Assigned Uses

ReadBy

IncludesMinUsageMaxUsageFixedAmtVarAmt

Rate

EmpNoEmpNameEmpTitle

EmployeePerforms

Contains

6.2 - 15

Converting an ERD to Relational Tables

• Understanding the conversion rules improves

the understanding of the ER Model, particularly

the difference between the ER Model and

Relational Model (關聯式模型 ).

• Some typical errors by novice ( 新手 ) data

modelers are due to confusion between these

two models.

• Most commercial DBMSs use the Relational

Model.

6.2 - 16

OfferingOfferNoOffLocationOffTime

EnrGrade

EnrollmentRegisters

Grants

CourseNoCrsDescCrsUnits

Course

FacultyFacSalaryFacRankFacHireHate

SSNNameCityStateZip

UnivPerson

Has

Teaches

Supervises

CStudentStdClassStdMajorStdGPA

The Example of University D/Bfor Table Conversion

6.2 - 17

Basic Conversion Rules

1. Entity Type Rule

Each entity type becomes a table.

2. 1-M Relationship Rule

Each 1-M relationship becomes a foreign key

in the table corresponding to the child entity

type (the entity type near the crow’s foot

symbol).

If the minimum cardinality on the parent side of

the relationship is one, the foreign key cannot

accept null values mandatory

If it is zero, FK can accept null optional

6.2 - 18

Summary of Basic Conversion Rules

3. M-N Relationship Rule

Each M-N relationship becomes an associative

table with a combined primary key consisting of

the primary keys of the two entity types

participating in the M-N relationship.

4. identification Relationship Rule

Each identifying relationship adds a component

to the primary key in the table corresponding to

weak entity type.

6.2 - 19

Application of Basic Rule 1


Course

CREATE TABLE Course (CourseNo CHAR(6) ,CrsDesc VARCHAR(30) NOT NULL ,CrsUnits NUMBER(2) DEFAULT 3 NOT NULL ,CONSTRAINT Course_pk PRIMARY KEY (CourseNo) );

CREATE TABLE Offering (OfferNo CHAR(6) ,OffLocation VARCHAR(10) ,OffTime Date ,CONSTRAINT Offering_pk PRIMARY KEY (OfferNo) );

OfferNoOffLocationOffTime

Offering

Each entity type becomes a table

OfferingOfferNoOffLocationOffTime

EnrGrade

EnrollmentRegisters

Grants


Course

FacultyFacSalaryFacRankFacHireHate

SSNNameCityStateZip

UnivPerson

Has

Teaches

Supervises

CStudentStdClassStdMajorStdGPA

Dictionary

6.2 - 20

Application of Basic Rule 2(Converting a Mandatory 1-M Relationship )


Course

OfferNoOffLocationOffTime

Offering

Has

CREATE TABLE Course (CourseNo CHAR(6) ,CrsDesc VARCHAR(30) NOT NULL ,CrsUnits NUMBER(2) DEFAULT 3 NOT NULL ,CONSTRAINT Course_pk PRIMARY KEY (CourseNo) );

CREATE TABLE Offering (OfferNo CHAR(6) ,OffLocation VARCHAR(10) ,OffTime Date ,CourseNo CHAR(6) NOT NULL ,CONSTRAINT Offering_pk PRIMARY KEY (OfferNo) ,CONSTRAINT Offering_CourseNo_fk

FOREIGN KEY (CourseNo) REFERENCES Course (CourseNo) );

Each 1-M relationship becomes a foreign key in the table corresponding to the child entity type

If the minimum cardinality on the parent

side of the relationship is one, the foreign

key cannot accept null values.

Old

6.2 - 21

Application of Basic Rule 2(Converting an Optional 1-M Relationship)

FacNoFacName

FacultyOfferNoOffLocationOffTime

Offering

Teaches

CREATE TABLE Faculty (FacNo CHAR(6) ,FacName VARCHAR(30) NOT NULL ,CONSTRAINT Faculty_pk PRIMARY KEY (FacNo) );

CREATE TABLE Offering (OfferNo CHAR(6) ,OffLocation VARCHAR(10) ,OffTime Date ,FacNo CHAR(6) ,CONSTRAINT Offering_pk PRIMARY KEY (OfferNo) ,CONSTRAINT Offering_FacNo_fk

FOREIGN KEY (FacNo) REFERENCES Faculty (FacNo) );

CREATE TABLE Faculty (FacNo CHAR(6) ,FacName VARCHAR(30) NOT NULL ,CONSTRAINT Faculty_pk PRIMARY KEY (FacNo) );

CREATE TABLE Offering (OfferNo CHAR(6) ,OffLocation VARCHAR(10) ,OffTime Date ,FacNo CHAR(6) NOT NULL ,CONSTRAINT Offering_pk PRIMARY KEY (OfferNo) ,CONSTRAINT Offering_FacNo_fk

FOREIGN KEY (FacNo) REFERENCES Faculty (FacNo) );

• Each 1-M relationship becomes a foreign key of child entity type.

• If the minimum cardinality on the parent side is 0, FK can accept null

6.2 - 22


StdSSNStdName

StudentOfferNoOffLocationOffTime

Offering

Enrolls_In

EnrGrade

CREATE TABLE Enrollment (StdSSN CHAR(10) ,OfferNo CHAR(6) ,EnrGrade CHAR(1) ,CONSTRAINT Enrollment_pk PRIMARY KEY (StdSSN, OfferNo) ,CONSTRAINT Enrollment_StdSSN_fk

FOREIGN KEY (StdSSN) REFERENCES Student (StdSSN) ,CONSTRAINT Enrollment_OfferNo_fk

FOREIGN KEY (OfferNo) REFERENCES Offering (OfferNo)

);

Each M-N relationship becomes an associative table with a combined primary key.

6.2 - 23

Application of Basic Rule 4(Identification Relationship Rule)

• Same conversion result as the previous slide

• Application of rule 3 vs. Application of rule 4

StdSSNStdName

StudentOfferNoOffLocation

Offering

EnrGrade

Enrollment

Registers Grants

Each identifying relationship adds a component to the primary key in the table corresponding to weak entity type.

Corresponding to M-N

StdSSNStdName

StudentOfferNoOffLocationOffTime

Offering

Enrolls_In

EnrGrade

6.2 - 24

StdSSNStdName

StudentOfferNoOffLocation

Offering

EnrGrade

Enrollment

Registers Grants


CREATE TABLE Enrollment (StdSSN CHAR(10) ,OfferNo CHAR(6) ,EnrGrade CHAR(1) ,CONSTRAINT Enrollment_pk PRIMARY KEY (StdSSN, OfferNo) ,CONSTRAINT Enrollment_StdSSN_fk

FOREIGN KEY (StdSSN) REFERENCES Student (StdSSN) ,CONSTRAINT Enrollment_OfferNo_fk

FOREIGN KEY (OfferNo) REFERENCES Offering (OfferNo)

);

Each identifying relationship adds a component to the primary key in the table corresponding to weak entity type

6.2 - 25

1-M Self-Referencing Relationship(Converting a 1-M relationship)

FacSSNFacName

Faculty Supervises

CREATE TABLE Faculty (FacSSN CHAR(11) ,FacName VARCHAR(30) ,FacSupervisor CHAR(11) ,… ,CONSTRAINT Faculty_pk PRIMARY KEY (FacSSN) ,CONSTRAINT Faculty_Supervisor_fk

FOREIGN KEY (FacSupervisor) REFERENCES Faculty (FacSSN) );

2.1-M Relationship Rule

Each 1-M relationship becomes a foreign key in the table corresponding to the child entity type

Supervises

Faculty_1

FacSSNFacName

Faculty

FacSSNFacName

6.2 - 26

CourseNoCrsDesc

Course PrereqTo

M-N Self-Referencing Relationship(Converting A M-N Relationship)

CREATE TABLE Course (CourseNo CHAR(6) ,CrsDesc VARCHAR(30) ,CONSTRAINT Course_pk PRIMARY KEY (CourseNo ) );CREATE TABLE PrereqTo (PrereqCNo CHAR(6) ,DependCNo CHAR(6) ,CONSTRAINT PrereqTo_pk PRIMARY KEY (PrereqCNo, DependCNo) ,CONSTRAINT PrereqTo_PrereqCNo_fk

FOREIGN KEY (PrereqCNo) REFERENCES Course (CourseNo) ,CONSTRAINT PrereqTo_DependCNo_fk

FOREIGN KEY (DependCNo) REFERENCES Course (CourseNo) );

3.M-N Relationship Rule

Each M-N relationship becomes an associative table with a combined primary key. (similar to slide 22)

slide 22

PrereqTo

Course_1

CourseNoCrsDesc

Course

CourseNoCrsDesc

6.2 - 27

ERD with Two Weak Entity Types

StdSSN

StudentOfferNo

Offering

EnrGrade

EnrollmentRegisters GrantsAttDatePresent

Attendance

RecordedFor

CREATE TABLE Attendance (StdSSN CHAR(11) ,OfferNo CHAR(6) ,AttDate Date ,Present CHAR(1) ,CONSTRAINT Attendance_pk PRIMARY KEY (StdSSN, OfferNo, AttDate) ,CONSTRAINT Attendance_OfferNo_StdSSN_fk FOREIGN KEY (StdSSN, OfferNo) REFERENCES Enrollment (StdSSN, OfferNo) );

Enrollment table

Each identifying

relationship adds a

component to the

primary key in the

table corresponding

to weak entity type.

From Enrollment

local key

4. identification Relationship Rule

6.2 - 28

Generalization Hierarchy Rule

1. Each entity type of a generalization hierarchy

becomes a table

– Each subtype table contains specific columns

2. Add a subtype column for the supertype table

3. Each subtype table uses the primary key of its

supertype table as its primary key.

4. Add Foreign key constraints for subtype tables

– ON DELETE CASCADE option for deletion of referenced

rows

• Reduce need for null values

6.2 - 29

Converting Generalization Hierarchy

CREATE TABLE Employee( EmpNo CHAR(6), EmpName VARCHAR(30), EmpHireDate DECIMAL(10,2), EmpType CHAR(1), CONSTRAINT Employee_pk PRIMARY KEY (EmpNo ) );CREATE TABLE SalaryEmp( EmpNo CHAR(6), EmpSalary NUMBER(7), CONSTRAINT SalaryEmp_pk PRIMARY KEY (EmpNo), CONSTRAINT SalaryEmp_fk FOREIGN KEY (EmpNo) REFERENCES Employee (EmpNo)

ON DELETE CASCADE );CREATE TABLE HourlyEmp( EmpNo CHAR(6), EmpRate NUMBER(8,2), CONSTRAINT HourlyEmp_pk PRIMARY KEY (EmpNo), CONSTRAINT HourlyEmp_fk FOREIGN KEY (EmpNo) REFERENCES Employee (EmpNo) ON DELETE CASCADE );

EmployeeEmpNo

EmpNameEmpHireDate

SalaryEmpEmpSalary

HourlyEmpEmpRate

subtype column

Supertype’s PK

Supertype’s PK

6.2 - 30

Converting 1-1 Relationships

EmpNoEmpName

EmployeeOfficeNoOffAddressOffPhone

Office

Manages

CREATE TABLE Employee( EmpNo CHAR(6), EmpName VARCHAR(30), CONSTRAINT Employee_pk PRIMARY KEY (EmpNo) );CREATE TABLE Office ( OffNo CHAR(6), OffAddress VARCHAR(30), OffPhone CHAR(4), EmpNo CHAR(6) NOT NULL, CONSTRAINT Office_pk PRIMARY KEY (OffNo), CONSTRAINT Office_EmpNo_fk FOREIGN KEY (EmpNo) REFERENCES Employee (EmpNo), CONSTRAINT Office_EmpNo_uk UNIQUE (EmpNo));

1-1 relationship• Add a FK• Add unique constraint

6.2 - 31

Comprehensive Example of Water Utility ERD

RateSetRateSetNoRSApprDateRSEffDate

CustNoCustNameCustType

Customer

BillNoBillDateBillStartDate

BillReadNoReadTimeReadLevel

Reading

MeterNoMtrSizeMtrModel

Meter

Assigned Uses

ReadBy

IncludesMinUsageMaxUsageFixedAmt

Rate

EmpNoEmpNameEmpTitle

EmployeePerforms

Contains

TaxPayerIDEnterpriseZone

Commercial ResidentialSubsidizedDwellingType

D,C

6.2 - 32

Summary

• Data modeling is an important skill for database design

• Use ERD notation precisely

• Preference for simpler designs at first

• Consider alternative designs later

• Review design for common errors

• Solve as many problems as possible

6.2 - 33

分組專題(Design Errors and Table Conversion Problems)

下一週上課前一天中午十二點整交

分組專題 #6第六章 202-203 頁 Data Modeling Problems 23第六章 211-213 頁 Conversion Problems 4,

9

6 copyright © 2006, oracle. all rights reserved. developing data models for business databases...

Documents