5 copyright © 2006, oracle. all rights reserved. understanding entity relationship diagrams (...
TRANSCRIPT
5Copyright © 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
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.
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
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.
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
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
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
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).
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
5.2 - 11
Multiple Levels of Generalization(An Example)
SecuritySymbol
SecNameLastClose
StockOutShares
IssuedShares
BondRate
FaceValue
D,C
CommonPERatioDividend
PreferredCallPriceArrears
D,C
有價證券
債券股票
特別股普通股
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
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
5.2 - 14
Converting Database Relationship Diagraminto ER Diagram
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
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
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)
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
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
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
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.
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.
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
5.2 - 24
PK Rule Violation Example
BldgIDBldgNameBldgLocation
BuildingRoomRoomNoRoomCapacity
Contains
• A single 1-M identifying relationship• Room does not have a local key.
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.
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
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
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
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
5.2 - 30
分組專題(ER Diagram and Diagram Rules)
下一週上課前一天中午十二點整交
分組專題 #4 第五章 161~163頁 Problems 1, 2, 3, 4, 5, 18