5 copyright © 2006, oracle. all rights reserved. understanding entity relationship diagrams (...

30
5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams (實 實實實 ) Part II

Upload: kevin-parrish

Post on 29-Dec-2015

220 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5Copyright © 2006, Oracle. All rights reserved.

Understanding Entity Relationship Diagrams

(實體關係圖 )Part II

Page 2: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 2

Generalization Hierarchies(歸納分類的階層架構 )

• An ERD notation to support classification. It is

similar to the concept of inheritance.

• A collection of similar entity types are arranged in a

hierarchical structure to show similarity in

attributes.

• Each subtype or child type (子類別 ) entity (實體 )

may also be a supertype (超類別 ) or parent type

(父類別 ) entity at the same time.

• Used in ERD when a collection of entity types have

similar but different attributes

Page 3: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 3

Generalization Hierarchies

EmployeeEmpNoEmpNameEmpHireDate...

SalaryEmpEmpSalary

HourlyEmpEmpRate

generalization hierarchy symbol

supertype

subtypes

• Employees are classified as salaried employees and hourly employees.

• Both salaried and hourly employees are specialized kinds of employees.

Page 4: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 4

Generalization Hierarchies

• Supertype: Employee

• Subtype: SalaryEmp & HourlyEmp (with additional attributes)

• The relationship between a subtype and its supertype is known as ISA.– SalaryEmp IS AN Employee

– HourlyEmp IS AN Employee

EmployeeEmpNoEmpNameEmpHireDate...

SalaryEmpEmpSalary

HourlyEmpEmpRate

generalization hierarchy symbol

supertype

subtypes

Page 5: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 5

Inheritance(繼承 )

• Support sharing of attributes between a

supertype and a subtype

• Every subtype entity is also a supertype entity.

• Each subtype inherits the attributes of its

supertypes (directly and indirectly).

– Example: Every entity of SalaryEmp has an

employee number, name, and hiring date because

it is also an entity of Employee.

• The inherited attributes of a subtype are not

shown in the subtype of an ERD.

Page 6: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 6

Notations of Generalization Constraints

Disjointness Constraint (無重疊性限制 )

• Disjointness denotes that subtypes in a hierarchy

do not have any common entities.

• A symbol D denotes that intersection is empty

• No symbol denotes intersection is not empty

• Example:

– The generalization constraint between Faculty

and Student

Page 7: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 7

Notations of Generalization Constraints

Completeness Constraint (完全性限制 )

• Completeness denotes that an entity of a

supertype must be an entity in one of the

subtypes in a generalization hierarchy.

• A symbol C denotes that

The set of supertype entities equals the union of sets of

subtype entities.

• No symbol denotes that

Union of subtypes has fewer entities than their supertype

Page 8: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 8

Example 1 of Generalization Constraints

Disjointness (D) and completeness (C)• Every Employee entity must be either a SalaryEmp entity or

a HourlyEmp entity, but not both at the same time.

SalaryEmp HourlyEmp

EmployeeEmpNoEmpNameEmpHireDate...

SalaryEmpEmpSalary

HourlyEmpEmpRate

D C

Employee

Page 9: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 9

Example 2 of Generalization Constraints

EmployeeEmpNoEmpNameEmpHireDate...

SalaryEmpEmpSalary

HourlyEmpEmpRate

Employee

SalaryEmp HourlyEmp

No symbol ( lack of disjointness and completeness)• Some employees can be both salaried and hourly (not disjoint).• Some employees are not paid by salary or by hour (not complete).

Page 10: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 10

Example 3 of Generalization Constraints

Completeness• Some UnivPeople entity can be both a Student entity and

a Faculty entity.• Every UnivPeople entity must be either a Student entity or

a Faculty entity.

Student Faculty

UnivPeople

C

SSNNameCityState

UnivPeople

StdMajorStdClass

StudentFacSalryFacDept

Faculty

Page 11: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 11

Multiple Levels of Generalization(An Example)

SecuritySymbol

SecNameLastClose

StockOutShares

IssuedShares

BondRate

FaceValue

D,C

CommonPERatioDividend

PreferredCallPriceArrears

D,C

有價證券

債券股票

特別股普通股

Page 12: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 12

Symbol Meaning

Entity type with attributes (primary key underlined)

M-N relationship with attributes: attributes are shown if room permits; otherwise attributes are listed separately.

Identification dependency: identifying relationship(s) (solid relationship lines) and weak entity (diagonal lines in the corners of the rectangle).

Summary of Crow’s Foot Notation

StdSSNStdName……

Student

Enrolls_In

EnrGrade

Contains

Page 13: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 13

Symbol Meaning

Generalization hierarchy with disjointness and completeness constraints

Existence dependent cardinality (minimum cardinality of 1): inner symbol is a line perpendicular to the relationship line.

Optional cardinality (minimum cardinality of 0): inner symbol is a circle.

Single-valued cardinality (maximum cardinality of 1): outer symbol is a line perpendicular to the relationship line.

D,C

Contains

Teaches

Has

Summary of Crow’s Foot Notation

Page 14: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 14

Converting Database Relationship Diagraminto ER Diagram

Page 15: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 15

A Comprehensive Example

(同意 )

OfferingOfferNoOffLocationOffTime

EnrGrade

EnrollmentRegisters

Grants

CourseNoCrsDescCrsUnits

Course

FacultyFacSalaryFacRankFacHireHate

SSNNameCityStateZip

UnivPerson

Has

Teaches

Supervises

CStudentStdClassStdMajorStdGPA

identificationrelationship

mandatoryrelationship

optionalrelationship

FacDept. . .

21

5

3 4

7

8

6

stdSSNstdClassstdMajorstdGPA

Page 16: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 16

Representation of Business Rules

• Business rules (商業規則 ) enforce organizational

policies

• Formal Representation

– PKs

– Relationships

– Cardinalities

– Generalization hierarchies, etc.

• Informal Representation

– In documentation associated with an ERD

Page 17: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 17

Formal Representation of Business Rules

• Primary Key

– Support entity identification (人、事、時、地、物 )

Example : B9944101, B0107

• Relationships

Indicate connections among business entities

– Identification Dependency

Indicate knowledge of other entities for identification

(Example : B0107)

Page 18: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 18

Formal Representation of Business Rules

• Cardinalities

– Restrict number of related entities in a business

situation (e.g., M-N, 1-M)

• Generalization Hierarchies

– Support classification of business entities and

organizational policies

EmployeeEmpNoEmpNameEmpHireDate...

SalaryEmpEmpSalary

HourlyEmpEmpRate

D C

Employee

EmpSalary

Enrolls_In

EnrGrade

Page 19: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 19

Informal Representation of Business Rules

• Candidate Keys

– Alternate ways to identify business entities

• Attribute Comparison Constraints

– Restrict values of attributes (Example : salary > 25000)

• Null Value Constraints

– When data is unknown or inapplicable

• Default Values

– Simplify data entry, or

– Provide value when unknown

Page 20: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 20

Diagram Rules in ERDs(圖形規則 )

• Ensure that ERD notation is correctly used

• Similar to syntax rules for a computer language

• Type of Rules

– Completeness Rules (完整性規則 , 5 條 )— No missing symbols or specifications (規格 )

– Consistency Rules (一致性規則 ,9 條 )— No conflicts among symbols or specifications

• Supported by the ER Assistant

Page 21: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 21

Completeness Rules

1. Primary Key RuleAll entity types have a primary key.(direct, borrowed, or inherited)

2. Naming RuleAll entity types, relationships, and attributes are named.

3. Cardinality RuleCardinality is given for both entity types in a relationship.

Page 22: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 22

Completeness Rules

4. Entity Participation Rule

All entity types (except those in a generalization

hierarchy) participate in at least one relationship.

5. Generalization Hierarchy Participation Rule

Each generalization hierarchy participates in at least

one relationship with an entity type not in the

generalization hierarchy.

Page 23: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 23

Primary Key Rule Issue

• Weak entities with a single 1-M identifying

relationship

– Borrowed PK alone cannot identify weak entity

instances because there can be other weak entity

instances related to the same parent entity

– Must provide a Local Key (or Partial Primary Key)

to augment borrowed PK from the parent entity type

– Violation of the PK rule if a local key is not provided

• Associative entity types (having two 1-M identifying

relationships) do not need to provide a local key

although they can if needed

Page 24: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 24

PK Rule Violation Example

BldgIDBldgNameBldgLocation

BuildingRoomRoomNoRoomCapacity

Contains

• A single 1-M identifying relationship• Room does not have a local key.

Page 25: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 25

Consistency Rules

1. Entity Name RuleEntity type names are unique.

2. Attribute Name RuleAttribute names are unique within entity types and relationships.

3. Inherited Attribute Name RuleAttribute names in a subtype do not match inherited (direct or indirect) attribute names.

4. Relationship/Entity Type Connection RuleAll relationships connect two entity types (not necessarily distinct).

5. Relationship/Relationship Connection RuleRelationships are not connected to other relationships.

Page 26: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 26

Consistency Rules

6. Weak Entity RuleWeak entities have at least one identifying relationship.

7. Identifying Relationship RuleFor each identifying relationship, at least one participating entity type must be weak.

8. Identification Dependency Cardinality RuleFor each identifying relationship, the minimum and maximum cardinality must be 1 in the direction from the child (weak entity) to the parent entity type.

9. Redundant Foreign Key RuleRedundant foreign keys are not used.

Contains

parent

child

Page 27: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 27

Relationship Names

• No uniqueness requirement

• Participating entities provide a context for relationship names

• Use unique names as much as possible to distinguish relationships

• Must provide unique names for multiple relationships between the same entity types

Page 28: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 28

Offering

OfferNoOffLocationOffTimeCourseNo

EnrGrade

EnrollmentRegisters Grants CourseNoCrsDescCrsUnits

Course

Faculty

FacSalaryFacRankFacHireHate

SSNNameCityStateZip

UnivPerson

Has

Teaches

Supervises

C

Student

StdClassStdMajorStdGPA

Rule 6 Violation(Weak Entity)

Rule 7 Violation(Identifying Relationship)

Rule 8 Violation(Id Dependency Cardinality)

Rule 9 Violation(Redundant FK)

Example of Diagram Errors

Correct Diagram

Violations of Consistency Rules 6 to 9

Page 29: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 29

Support in the ER Assistant

• Construction of diagrams ensures that

relationships connect two entity types (not

necessarily distinct)

• Other rules are supported by the Check Diagram

feature

• For the Redundant Foreign Key rule, the ER

Assistant detects FKs that have the same name

as the associated PKs

Page 30: 5 Copyright © 2006, Oracle. All rights reserved. Understanding Entity Relationship Diagrams ( 實體關係圖 ) Part II

5.2 - 30

分組專題(ER Diagram and Diagram Rules)

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

分組專題 #4 第五章 161~163頁 Problems 1, 2, 3, 4, 5, 18