Understanding Entity Relationship Diagrams

Understanding EntityRelationship DiagramsDr. Chawalit Jeenanunta

Objective• Business rule representation• Diagram rules• Alternative notationsDr. Chawalit Jeenanunta DBMS: Slide 2

Formal Representation• Primary key constraints: entity identification• Named relationships: direct connectionsamong business entities• Identification dependency: knowledge ofother entities for identification• Cardinalities: restrict number of relatedentities in a business situation• Generalization hierarchies: classification ofbusiness entities and organizational policiesDr. Chawalit Jeenanunta DBMS: Slide 4

Informal Representation• Specify as documentation associated elements ofan ERD• Candidate key constraints: alternate ways to identifybusiness entities• Reasonable values: fixed collection of values orconsistent with another attribute• Null value constraints: data collection completeness• Default values: simplify data entry and provide valuewhen unknownDr. Chawalit Jeenanunta DBMS: Slide 5

Diagram Rules• Ensure that ERD notation is correctly used• Similar to syntax rules for a computerlanguage• Completeness rules no missing symbols or specifications• Consistency rules: no conflicts among symbols or specificationsDr. Chawalit Jeenanunta DBMS: Slide 6

Diagram Rules• Apply these rules when completing an ERD toensure that there are no notation errors in your ERD• Similar to syntax rules for a computer language:- Ensures proper language structure, not correct meaning- Diagram rules ensure proper structure among symbols- Do not ensure that you have considered multiplealternatives, correctly represented user requirements, andproperly documented your designDr. Chawalit Jeenanunta DBMS: Slide 7

Completeness Rules1. Primary Key Rule:all entity types have a PK (direct, indirect, or inherited)2. Naming Rule:all entity types, relationships, and attributes have a name3. Cardinality Rule:cardinality is specified in both directions for each relationship4. Entity Participation Rule:all entity types participate in an at least one relationship exceptfor entity types in a generalization hierarchy5. Generalization Hierarchy Participation Rule:at least one entity type in a generalization hierarchy participatesin a relationshipDr. Chawalit Jeenanunta DBMS: Slide 8

Completeness Rules• The first three rules are mandatory.A finished ERD should not violatethe PK, Naming, and Cardinalityrules.• PK rule:- Direct: Table contains the primarykey attribute(s)- Indirect: Table borrows (iddependent) for part or all of PK- Inherited: Table inherits PK from asupertype• The next two rules are optional.Most ERDs will not violate the EntityParticipation and GeneralizationHierarchy Participation rules.• Rule 5 applies to an entiregeneralization hierarchy, not to eachentity type in a generalizationhierarchy. In other words, at leastone entity type in a generalizationhierarchy should be connected to atleast one entity type not in thegeneralization hierarchy. In manygeneralization hierarchies, multipleentity types participate inrelationships. Generalizationhierarchies permit subtypes toparticipate in relationships thusconstraining relationshipparticipation.Dr. Chawalit Jeenanunta DBMS: Slide 9

Primary Key Rule Issue• Primary key rule is simple in most cases• For some weak entities, the PK rule is subtleWeak entity with only one 1-M identifying relationshipWeak entity must have a local key to augment theborrowed PK from the parent entity typeBorrowed PK alone cannot identify weak entity instancesbecause there can be many weak entity instances relatedto the same parent entityViolation of PK rule if local key is missingAssociative entity types do not need to provide a local keyalthough they can if neededDr. Chawalit Jeenanunta DBMS: Slide 10

PK Rule Violation ExampleDr. Chawalit Jeenanunta DBMS: Slide 11

Naming Consistency Rules• Consistency rules: noconflicting specifications• Naming rules: no conflictamong names• Entity Name Rule:entity type names must beunique• Attribute Name Rule:attribute names must beunique within each entitytype and relationship• Inherited Attribute Rule:attribute names in asubtype do not matchinherited (direct or indirect)attribute names.Dr. Chawalit Jeenanunta DBMS: Slide 12

Relationship Names• No uniqueness requirement• Participating entities provide a context forrelationship names• Use unique names as much as possible todistinguish relationships• Must provide unique names for multiplerelationships between the same entity typesDr. Chawalit Jeenanunta DBMS: Slide 13

Connection Consistency Rules• no conflicts or redundancies amongrelationships• Relationship/Entity Connection Rule: relationships connect two entity types (notnecessarily distinct) Do not connect relationships directly (connectthrough entity types) Self referencing relationships: connect the sameentity type two timesDr. Chawalit Jeenanunta DBMS: Slide 14

Connection Consistency Rules• Redundant Foreign Key Rule:- Foreign keys are redundant with 1-M relationships- Use FKs in the relational model, not in ERDs- Violation of this rule is common:- confusion between the ERDs and relational table design- Conversion replaces relationships with foreignkeysDr. Chawalit Jeenanunta DBMS: Slide 15

Identification Dependency Rules• Common source of diagramerrors• no conflicts amongcomponents of identificationdependency (weak entity,identifying relationships,cardinality specification)• Weak entity rule:weak entities have at leastone identifying relationship• Identifying relationship rule:at least one participatingentity type must be weak foreach identifying relationship• Identification dependencycardinality rule:Minimum and maximumcardinality must (1,1) for aweak entity in all identifyingrelationships(1,1) cardinality shouldappear near the parententity typeCommon source of diagramerrorsDr. Chawalit Jeenanunta DBMS: Slide 16

Example of Diagram Errors• Weak entity ruleviolation:Faculty is a weak entitybut it is not involved inany identifyingrelationshipsResolution: remove weakentity symbolsIn some cases, resolutioninvolves changing arelationship to identifyingStudentStdClassStdMajorStdGPARegistersUnivPersonSSNNameCityStateZipCRule 9 Violation(Redundant FK)Rule 8 Violation(Id Dependency Cardinality)EnrollmentEnrGradeOfferingOfferNoOffLocationOffTimeCourseNoGrantsTeachesHasRule 7 Violation(Identifying Relationship)CourseCourseNoCrsDescCrsUnitsRule 6 Violation(Weak Entity)FacultyFacSalaryFacRankFacHireHateSupervisesDr. Chawalit Jeenanunta DBMS: Slide 17

Example of Diagram Errors• Identifying relationshiprule violation:Has is an identifyingrelationship but neitherOffering nor Course is aweak entityResolution: make Has aregular (non-identifying)relationshipSometimes resolutioninvolves making an entitytype weakStudentStdClassStdMajorStdGPARegistersUnivPersonSSNNameCityStateZipCRule 9 Violation(Redundant FK)Rule 8 Violation(Id Dependency Cardinality)EnrollmentEnrGradeOfferingOfferNoOffLocationOffTimeCourseNoGrantsTeachesHasRule 7 Violation(Identifying Relationship)CourseCourseNoCrsDescCrsUnitsRule 6 Violation(Weak Entity)FacultyFacSalaryFacRankFacHireHateSupervisesDr. Chawalit Jeenanunta DBMS: Slide 18

Example of Diagram Errors• Redundant foreign key rule:CourseNo in Offering isredundant with the HasrelationshipResolution: remove theCourseNo attribute inOfferingThis rule can be violatedeven if the FK attribute hasa different name thanassociated PK. It is moredifficult to detect aredundancy if the FK has adifferent name.StudentStdClassStdMajorStdGPARegistersUnivPersonSSNNameCityStateZipCRule 9 Violation(Redundant FK)Rule 8 Violation(Id Dependency Cardinality)EnrollmentEnrGradeOfferingOfferNoOffLocationOffTimeCourseNoGrantsTeachesHasRule 7 Violation(Identifying Relationship)CourseCourseNoCrsDescCrsUnitsRule 6 Violation(Weak Entity)FacultyFacSalaryFacRankFacHireHateSupervisesDr. Chawalit Jeenanunta DBMS: Slide 20

Corrected ERDUnivPersonSSNNameCityStateZipStudentStdClassStdMajorStdGPACOfferingOfferNoOffLocationOffTimeTeachesHasFacultyFacSalaryFacRankFacHireHateRegistersEnrollmentEnrGradeGrantsCourseCourseNoCrsDescCrsUnitsSupervisesDr. Chawalit Jeenanunta DBMS: Slide 21

ERD Variations• No standard ERD notationMany notations: too many;source of confusionMany variations of a givennotation: many variations ofthe Crow’s Foot notationCrow’s foot notation iswidely used but it has manyvariations• Placement of cardinalitysymbols• Rule variations• Be prepared to adjust to theERD notation in use byeach employer• Symbol variationsDifferent symbols for entitytypes, relationships, andattributesDifferent symbols foridentification dependencyand generalizationhierarchiesDifferent definitions forcommonly used terms:existent dependent isdefined incorrectly by someauthors to meanidentification dependencyDr. Chawalit Jeenanunta DBMS: Slide 22

ERD Rule Variations• Lack of ERD standards• M-way relationships• M-N relationships• Relationships with attributes• Self-referencing relationships• Relationships connected to otherrelationships• Adapt to notations in work environmentsDr. Chawalit Jeenanunta DBMS: Slide 23

Chen ERD Notation• Original ERD notation• Widely known and used• Variations: Different relationship symbols Reversed cardinality positions Attributes are sometimes shown in ovals attachedto entity types and relationships M-way relationships supported Different symbol for associative entity types andweak entitiesDr. Chawalit Jeenanunta DBMS: Slide 24

Chen ERD NotationMaximum Cardinalityfor CourseMaximum Cardinalityfor OfferingCourseCourseNoCrsDescCrsUnits(0:N) (1:1)HasOfferingOfferNoOffLocationOffTime...Mininum cardinalityfor CourseMininum cardinalityfor OfferingDr. Chawalit Jeenanunta DBMS: Slide 25

Unified Modeling Language• Standard notation for object-orientedmodeling Objects Object features Interactions among objects• UML supports class diagrams, interfacediagrams, and interaction diagrams• More complex than ERD notationDr. Chawalit Jeenanunta DBMS: Slide 26

Simple Class DiagramObject nameAssociationOfferingFacultyAttributesOperationsOfferNo : LongOffTerm : StringOffYear : IntegerOffLocaton : StringEnrollmentCount() : IntegerOfferingFull() : BooleanTeaches0..n0..1TaughtByFacSSN : StringFacFirstName : StringFacLastName : StringFacDOB : DateFacAge() : IntegerCardinalityRole nameDr. Chawalit Jeenanunta DBMS: Slide 27

Association Class• Association class: similar to a M-N relationship withattributesAssociationclassEnrollmentEnrGrade : NumericOfferingStudentOfferNo : LongOffTerm : StringOffYear : IntegerOffLocaton : StringEnrollmentCount() : IntegerOfferingFull() : BooleanTakes0..n0..nEnrollsStdSSN : StringStdFirstName : StringStdLastName : StringStdDOB : DateStdAge() : IntegerDr. Chawalit Jeenanunta DBMS: Slide 28

Generalization Relationship• Generalization and inheritance are original featuresof the UML, not added later as generalizationhierarchies are for ERDsStudentGeneralizationnameUndergraduateMajor : StringMinor : StringStdSSN : LongStdFirstName : StringStdLastName : StringStatus{complete}GeneralizationconstraintGraduateThesisTitle : StringThesisAdvisor : StringDr. Chawalit Jeenanunta DBMS: Slide 29

Composition Relationship• Composition is similar to identification dependency• Dark diamond for a composition classOrderOrdNo : LongOrdDate : DateOrdAmt : Currency1..11..nOrdLineLineNo : IntegerQty : IntegerDr. Chawalit Jeenanunta DBMS: Slide 30

Summary• Data modeling is an important skill• Crow’s Foot ERD notation is widely used• Use notation precisely• Use the diagram rules to ensure structuralconsistency and completeness• Understanding the ERD notation is aprerequisite to applying the notation onbusiness problemsDr. Chawalit Jeenanunta DBMS: Slide 31