1. Conceptual Design & ERD Modelling
Chapter 03
Conceptual Design & ERD Modelling
Pearson Education © 2009

2. Chapter 12 - Objectives
How to use Entity–Relationship (ER) modeling in database design.
Basic concepts associated with ER model.
Diagrammatic technique for displaying ER.
How to identify and resolve problems with ER models called connection traps.
Concepts of Enhanced ER (EER) model.
Constraints on Specialization / Generalization
Pearson Education © 2009

3. Concepts of the ER Model
Entity types
Relationship types
Attributes
Pearson Education © 2009

4. Entity Type Entity type
Group of objects with same properties, identified by enterprise as having an independent existence.
Entity occurrence
Uniquely identifiable object of an entity type.
Pearson Education © 2009

5. Examples of Entity Types
Pearson Education © 2009

6. Relationship Types Relationship type
Set of meaningful associations among entity types.
Relationship occurrence
Uniquely identifiable association, which includes one occurrence from each participating entity type.
Pearson Education © 2009

7. ER Diagrams, Naming Conventions

8. Relationship Types Degree of a Relationship
Number of participating entities in relationship.
Relationship of degree :
one is unary (recursive)
two is binary
three is ternary
four is quaternary.
Pearson Education © 2009

9. Recursive relationship called Supervises with role names
Pearson Education © 2009

10. Relationship Types Recursive Relationship
Relationship type where same entity type participates more than once in different roles.
Relationships may be given role names to indicate purpose that each participating entity type plays in a relationship.
Pearson Education © 2009

11. Binary relationship called POwns
Pearson Education © 2009

12. Ternary relationship called Registers
Pearson Education © 2009

13. Quaternary relationship called Arranges
Pearson Education © 2009

14. Entities associated through two distinct relationships with role names
Pearson Education © 2009

15. Attributes Attribute Property of an entity or a relationship type.
Attribute Domain
Set of allowable values for one or more attributes.
Pearson Education © 2009

16. Attributes Simple Attribute
Attribute composed of a single component with an independent existence.
Composite Attribute
Attribute composed of multiple components, each with an independent existence.
Pearson Education © 2009

17. Attributes Single-valued Attribute
Attribute that holds a single value for each occurrence of an entity type.
Multi-valued Attribute
Attribute that holds multiple values for each occurrence of an entity type.
Pearson Education © 2009

18. Attributes Derived Attribute
Attribute that represents a value that is derivable from value of a related attribute, or set of attributes, not necessarily in the same entity type.
Pearson Education © 2009

19. Keys
Candidate Key
Minimal set of attributes that uniquely identifies each occurrence of an entity type.
Primary Key
Candidate key selected to uniquely identify each occurrence of an entity type.
Composite Key
A candidate key that consists of two or more attributes.
Pearson Education © 2009

20. ER diagram of Staff and Branch entities and their attributes
Pearson Education © 2009

21. Entity Type Strong Entity Type
Entity type that is not existence-dependent on some other entity type.
Weak Entity Type
Entity type that is existence-dependent on some other entity type.
Pearson Education © 2009

22. Strong entity type called Client and weak entity type called Preference
Pearson Education © 2009

23. Relationship called Advertises with attributes
Pearson Education © 2009

24. Structural Constraints
Main type of constraint on relationships is called multiplicity.
Multiplicity - number (or range) of possible occurrences of an entity type that may relate to a single occurrence of an associated entity type through a particular relationship.
Associate a pair of integer numbers (min, max) with each participation of an entity type E in a relationship type R, where 0 ≤ min ≤ max and max ≥ 1
Represents user policies (called business rules)
Pearson Education © 2009

25. Structural Constraints
The most common degree for relationships is binary.
Binary relationships are generally referred to as being:
one-to-one (1:1)
one-to-many (1:*)
many-to-many (*:*)
Pearson Education © 2009

26. Structural Constraints
Multiplicity is made up of two types of restrictions on relationships: cardinality and participation.
Pearson Education © 2009

27. Structural Constraints
Cardinality
Describes maximum number of possible relationship occurrences for an entity participating in a given relationship type.
Participation
Determines whether all or only some entity occurrences participate in a relationship.
Pearson Education © 2009

28. Multiplicity as cardinality and participation constraints
Pearson Education © 2009

29. Semantic net of Staff Manages Branch relationship type
Pearson Education © 2009

30. Multiplicity of Staff Manages Branch (1:1) relationship
Pearson Education © 2009

31. Semantic net of Staff Oversees PropertyForRent relationship type
Pearson Education © 2009

32. Multiplicity of Staff Oversees PropertyForRent (1:*) relationship type
Pearson Education © 2009

33. Semantic net of Newspaper Advertises PropertyForRent relationship type
Pearson Education © 2009

34. Multiplicity of Newspaper Advertises PropertyForRent (. :
Multiplicity of Newspaper Advertises PropertyForRent (*:*) relationship
Pearson Education © 2009

35. Summary of multiplicity constraints
Pearson Education © 2009

36. ER diagram of Branch user views of DreamHome
Pearson Education © 2009

38. Problems with ER Models
Problems may arise when designing a conceptual data model called connection traps.
Often due to a misinterpretation of the meaning of certain relationships.
Two main types of connection traps are called fan traps and chasm traps.
Pearson Education © 2009

39. Problems with ER Models
Fan Trap
Where a model represents a relationship between entity types, but pathway between certain entity occurrences is ambiguous.
Chasm Trap
Where a model suggests the existence of a relationship between entity types, but pathway does not exist between certain entity occurrences.
Pearson Education © 2009

40. An Example of a Fan Trap
Pearson Education © 2009

41. Semantic Net of ER Model with Fan Trap
At which branch office does staff number SG37 work?
Pearson Education © 2009

42. Restructuring ER model to remove Fan Trap
Pearson Education © 2009

43. Semantic Net of Restructured ER Model with Fan Trap Removed
SG37 works at branch B003.
Pearson Education © 2009

44. An Example of a Chasm Trap
Pearson Education © 2009

45. Semantic Net of ER Model with Chasm Trap
At which branch office is property PA14 available?
Pearson Education © 2009

46. ER Model restructured to remove Chasm Trap
Pearson Education © 2009

47. Semantic Net of Restructured ER Model with Chasm Trap Removed
Pearson Education © 2009

48. Enhanced Entity-Relationship Modeling

49. Created to design more accurate database schemas
The (EER) Model
Enhanced ER (EER) model
Created to design more accurate database schemas
Reflect the data properties and constraints more precisely
More complex requirements than traditional applications

50. Subclasses, Superclasses, and Inheritance
EER model includes all ER modeling concepts
In addition, EER includes:
Subclasses and superclasses
Specialization and generalization
Category or union type
Attribute and relationship inheritance

51. Subclasses, Superclasses, and Inheritance
Subtype or subclass of an entity type
Subgroupings of entities that are meaningful
Represented explicitly because of their significance to the database application
Type inheritance
Subclass entity inherits all attributes and relationships of superclass

52. Utilizing Specialization and Generalization in Refining Conceptual Schemas
Specialization process
Start with entity type then define subclasses by successive specialization
Top-down conceptual refinement process
Certain attributes may apply to some but not all entities of the superclass
Some relationship types may be participated in only by members of the subclass

53. Generalization Reverse process of abstraction
Generalize into a single superclass
Original entity types are special subclasses
Generalization
Process of defining a generalized entity type from the given entity types
Generalization process
Involves bottom-up conceptual synthesis

54. Constraints on Specialization and Generalization
May be several or one subclass
Determine entity subtype:
Predicate-defined (or condition-defined) subclasses
Attribute-defined specialization
User-defined

56. Constraints on Specialization and Generalization (cont’d.)
Disjointness constraint
Specifies that the subclasses of the specialization must be disjoint
Disjoint an entity can be a member of at most one of the subclasses of the specialization
Overlap that is the same entity may be a member of more than one subclass of the specialization
Completeness (or totalness) constraint
Every entity in the superclass must be a member of some subclass in the specialization/generalization
May be total or partial
Disjointness and completeness constraints are independent

57. Specialization and Generalization Hierarchies and Lattices
Specialization hierarchy
Every subclass participates as a subclass in only one class/subclass relationship
Results in a tree structure or strict hierarchy
Specialization lattice
Subclass can be a subclass in more than one class/subclass relationship

59. Modeling of UNION Types Using Categories
Union type or a category
Represents a single superclass/subclass relationship with more than one superclass
Subclass represents a collection of objects that is a subset of the UNION of distinct entity types
Attribute inheritance works more selectively
Category can be total or partial
Some modeling methodologies do not have union types

60. Design Choices for Specialization/Generalization
If all subclasses of a specialization/generalization have few specific attributes and no specific relationships
Can be merged into the superclass
Replace with one or more type attributes that specify the subclass or subclasses that each entity belongs to