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

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

3. 5.2 - 3 Generalization Hierarchies Employees are classified as salaried employees and hourly employees. Both salaried and hourly employees are specialized kinds of employees.

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

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

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

7. 5.2 - 7 Notations of Generalization Constraints Completeness Constraint ( 完全性限制 ) C ompleteness 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

8. 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. SalaryEmpHourlyEmp Employee

9. 5.2 - 9 Example 2 of Generalization Constraints 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).

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

11. 5.2 - 11 Multiple Levels of Generalization (An Example) 有價證券 債券 股票 特別股 普通股

12. 5.2 - 12 SymbolMeaning 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

13. 5.2 - 13 SymbolMeaning 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. Summary of Crow’s Foot Notation

14. 5.2 - 14 Converting Database Relationship Diagram into ER Diagram

15. 5.2 - 15 A Comprehensive Example ( 同意 ) identification relationship mandatory relationship optional relationship FacDept... 2 1 5 3 4 7 8 6 stdSSN stdClass stdMajor stdGPA

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

17. 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)

18. 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 Employee EmpSalary

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

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

21. 5.2 - 21 Completeness Rules 1.Primary Key Rule All entity types have a primary key. (direct, borrowed, or inherited) 2.Naming Rule All entity types, relationships, and attributes are named. 3.Cardinality Rule Cardinality is given for both entity types in a relationship.

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

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

24. 5.2 - 24 PK Rule Violation Example A single 1-M identifying relationship Room does not have a local key.

25. 5.2 - 25 Consistency Rules 1.Entity Name Rule Entity type names are unique. 2.Attribute Name Rule Attribute names are unique within entity types and relationships. 3.Inherited Attribute Name Rule Attribute names in a subtype do not match inherited (direct or indirect) attribute names. 4.Relationship/Entity Type Connection Rule All relationships connect two entity types (not necessarily distinct). 5.Relationship/Relationship Connection Rule Relationships are not connected to other relationships.

26. 5.2 - 26 Consistency Rules 6.Weak Entity Rule Weak entities have at least one identifying relationship. 7.Identifying Relationship Rule For each identifying relationship, at least one participating entity type must be weak. 8.Identification Dependency Cardinality Rule For 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 Rule Redundant foreign keys are not used. parent child

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

28. 5.2 - 28 Example of Diagram Errors Correct Diagram Violations of Consistency Rules 6 to 9

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

30. 5.2 - 30 分組專題 (ER Diagram and Diagram Rules) 下一週上課前一天中午十二點整交 分組專題 #4 第五章 161~163 頁 Problems 1, 2, 3, 4, 5, 18