Date post: | 07-Apr-2015 |
Category: |
Documents |
Upload: | smallcar88 |
View: | 2,519 times |
Download: | 1 times |
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Chapter 5
Understanding Entity Relationship Diagrams
5-2
Outline
Notation basics Understanding relationships Generalization hierarchies Business rule representation Diagram rules Alternative notations
5-3
Basic Symbols
Entity Typesymbol Relationship
symbol
Primary Key
AttributesRelationship
name
Entity Typename
CourseNoCrsDescCrsUnits
Course
OfferNoOffLocationOffTime
Offering
Has
5-4
Cardinalities
Course Offering
Course1 Offering1
Course2
Course3
Offering2
Offering3
Offering4
5-5
Cardinality Notation
Inside symbol: minimum cardinality
CourseNoCrsDescCrsUnits
Course
OfferNoOffLocationOffTime
Offering
Has
Perpendicular line: one cardinality
Outside symbol: maximum cardinality
Circle: zero cardinality
Crow's foot: many cardinality
5-6
Classification of Cardinalities Minimum cardinality based
Mandatory: existence dependent Optional
Maximum cardinality based Functional 1-M M-N 1-1
5-7
Summary of Cardinalities
Classification Cardinality Restrictions
Mandatory Minimum cardinality 1
Optional Minimum cardinality = 0
Functional or single-valued
Maximum cardinality = 1
1-M Maximum cardinality = 1 in one direction and maximum cardinality > 1 in the other direction.
M-N Maximum cardinality is > 1 in both directions.
1-1 Maximum cardinality = 1 in both directions.
5-8
More Relationship Examples
FacSSNFacSalaryFacRankFacHireDate
Faculty
OfferNoOffLocationOffTime
Offering
TeamTeachesOfficeNoOffPhoneOffType
Office
WorksIn
5-9
Comparison to Access Notation
CourseCoursenoCrsDescCrsUnits
1 8
OfferingOfferNo
CourseNoOffLocation
OffTime...
Access Relationship Diagram
CourseNoCrsDescCrsUnits
Course
OfferNoOffLocationOffTime
Offering
Has
ERD (Crow's Foot)
5-10
Understanding Relationships Identification dependency M-N relationships with attributes Self identifying relationships M-way relationships Equivalence between M-N and 1-M
relationships
5-11
Identification Dependency
BldgIDBldgNameBldgLocation
Building
RoomNoRoomCapacity
Room
Contains
Identification Dependency Symbols: Solid relationship line for identifying
relationships Diagonal lines in the corners denote
weak entities.
5-12
M-N Relationships with Attributes
StdSSNStdName
StudentOfferNoOffLocationOffTime
Offering
EnrollsIn
EnrGrade
attribute of relationship
5-13
M-N Relationships with Attributes (II)
AuthNoAuthName
AuthorISBNTitle
Book
AuthOrder
b) Writes relationship
Writes
PartNoPartName
PartSuppNoSuppName
Supplier
Qty
Provides
a) Provides relationship
5-14
Instance Diagrams for Self-Referencing Relationships
Faculty1
Faculty2 Faculty3
Faculty4 Faculty5
IS300
IS320
IS480 IS460
IS461
(a) Supervises (b) PreReqTo
5-15
ERD Notation for Self-Referencing Relationships
FacSSNFacName
Faculty
a) manager-subordinate
Supervises
b) course prerequisites
CourseNoCrsDesc
Course PrereqTo
5-16
Associative Entity Types for M-way Relationships
PartNoPartName
PartSuppNoSuppName
Supplier
Associativeentity type
ProjNoProjName
Project
UsesPart-Uses
Supp-Uses
Proj-Uses
5-17
Relationship Equivalence
Replace M-N relationship Associative entity type Two identifying 1-M relationships
M-N relationship versus associative entity type Largely preference Associative entity type is more flexible in
some situations
5-18
Associative Entity Type Example
StdSSNStdName
StudentOfferNoOffLocationOffTime
Offering
EnrGrade
EnrollmentRegisters GrantsAttDatePresent
Attendance
RecordedFor
5-19
Generalization Hierarchies
EmployeeEmpNo
EmpNameEmpHireDate
...
SalaryEmpEmpSalary
HourlyEmpEmpRate
generalization hierarchysymbol
supertype
subtypes
5-20
Inheritance Subtypes inherit attributes of supertypes
(direct and indirect) Allows abbreviation of attribute list Applies to code (methods) as well as
attributes (data)
5-21
Generalization Constraints
BondRate
FaceValue
StockOutShares
IssuedShares
SecuritySymbol
SecNameLastClose
D,C
DisjointnessConstraint
CompletenessConstraint
5-22
Multiple Levels of Generalization
SecuritySymbol
SecNameLastClose
StockOutShares
IssuedShares
BondRate
FaceValue
D,C
CommonPERatioDividend
PreferredCallPriceArrears
D,C
5-23
Comprehensive Example
OfferingOfferNoOffLocationOffTime
EnrGrade
EnrollmentRegisters
Grants
CourseNoCrsDescCrsUnits
Course
FacultyFacSalaryFacRankFacHireHate
SSNNameCityStateZip
UnivPerson
Has
Teaches
Supervises
CStudentStdClassStdMajorStdGPA
5-24
Business Rules Enforce organizational policies Promote efficient communication Formal representation in ERD Informal representation in documentation
associated with an ERD Use rules language to formally represent
in relational database after conversion
5-25
Formal Representation Primary key constraints: entity identification Named relationships: direct connections among
business entities Identification dependency: knowledge of other
entities for identification Cardinalities: restrict number of related entities
in a business situation Generalization hierarchies: classification of
business entities and organizational policies
5-26
Informal Representation Specify as documentation associated elements
of an ERD Candidate key constraints: alternate ways to
identify business entities Reasonable values: fixed collection of values or
consistent with another attribute Null value constraints: data collection
completeness Default values: simplify data entry and provide
value when unknown
5-27
Diagram Rules Ensure that ERD notation is correctly used Similar to syntax rules for a computer
language Completeness rules: no missing
specifications Consistency rules: no conflicts among
specifications Supported by the ER Assistant
5-28
Completeness Rules Primary Key Rule: all entity types have a PK (direct,
indirect, or inherited) Naming Rule: all entity types, relationships, and
attributes have a name Cardinality Rule: cardinality is specified in both directions
for each relationship Entity Participation Rule: all entity types participate in an
at least one relationship except for entity types in a generalization hierarchy
Generalization Hierarchy Participation Rule: at least one entity type in a generalization hierarchy participates in a relationship
5-29
Primary Key Rule Issue Primary key rule is simple in most cases
For some weak entities, the PK rule is subtle Weak entity with only one 1-M identifying
relationship
Weak entity must have a local key to augment the borrowed PK from the parent entity type
Violation of PK rule if local key is missing
5-30
PK Rule Violation Example
BldgIDBldgNameBldgLocation
BuildingRoomRoomNoRoomCapacity
Contains
PK rule violation A single 1-M identifying relationship Room does not have a local key.
5-31
Naming Consistency Rules Entity Name Rule: entity type names must
be unique
Attribute Name Rule: attribute names must be unique within each entity type and relationship
Inherited Attribute Rule: attribute names in a subtype do not match inherited (direct or indirect) attribute names.
5-32
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-33
Connection Consistency Rules Relationship/Entity Connection Rule:
relationships connect two entity types (not necessarily distinct)
Relationship/Relationship Connection Rule: relationships are not connected to other relationships
Redundant Foreign Key Rule: foreign keys are not used.
5-34
Identification Dependency Rules Weak entity rule: weak entities have at
least one identifying relationship
Identifying relationship rule: at least one participating entity type must be weak for each identifying relationship
Identification dependency cardinality rule: the minimum and maximum cardinality must equal 1 for a weak entity in all identifying relationships
5-35
Example of Diagram Errors
OfferingOfferNoOffLocationOffTimeCourseNo
EnrGrade
EnrollmentRegisters Grants
CourseNoCrsDescCrsUnits
Course
FacultyFacSalaryFacRankFacHireHate
SSNNameCityStateZip
UnivPerson
Has
Teaches
Supervises
CStudentStdClassStdMajorStdGPA
Rule 6 Violation(Weak Entity)
Rule 7 Violation(Identifying Relationship)Rule 8 Violation
(Id Dependency Cardinality)
Rule 9 Violation(Redundant FK)
5-36
Corrected ERD
OfferingOfferNoOffLocationOffTime
EnrGrade
EnrollmentRegisters
Grants
CourseNoCrsDescCrsUnits
Course
FacultyFacSalaryFacRankFacHireHate
SSNNameCityStateZip
UnivPerson
Has
Teaches
Supervises
CStudentStdClassStdMajorStdGPA
5-37
Support in the ER Assistant Relationship formation rules are supported
by diagram construction 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-38
ERD Variations No standard ERD notation Symbol variations Placement of cardinality symbols Rule variations Be prepared to adjust to the ERD notation
in use by each employer
5-39
ERD Rule Variations Lack of ERD standards M-way relationships M-N relationships Relationships with attributes Self-referencing relationships Relationships connected to other
relationships Adapt to notations in work environments
5-40
Chen ERD Notation
CourseCourseNoCrsDescCrsUnits
Has
OfferingOfferNo
OffLocationOffTime
...
(0:N) (1:1)
Mininum cardinalityfor Course
Maximum Cardinalityfor Course
Maximum Cardinalityfor Offering
Mininum cardinalityfor Offering
5-41
Unified Modeling Language Standard notation for object-oriented
modeling Objects Object features Interactions among objects
UML supports class diagrams, interface diagrams, and interaction diagrams
More complex than ERD notation
5-42
Simple Class Diagram
Offering
EnrollmentCount() : Integer OfferingFull() : Boolean
OfferNo : Long OffTerm : String OffYear : Integer OffLocaton : String
Faculty
FacAge() : Integer
FacSSN : String FacFirstName : String FacLastName : String FacDOB : Date
0..n
0..1Teaches
TaughtBy
Object name
Attributes
Operations
Association
Role nameCardinality
5-43
Association Class
Offering
EnrollmentCount() : Integer OfferingFull() : Boolean
OfferNo : Long OffTerm : String OffYear : Integer OffLocaton : String
Student
StdAge() : Integer
StdSSN : String StdFirstName : String StdLastName : String StdDOB : Date
0..n
0..nTakes
Enrolls
Enrollment
EnrGrade : Numeric
Associationclass
5-44
Generalization Relationship
Undergraduate
Major : String Minor : String
Graduate
ThesisTitle : String ThesisAdvisor : String
Status{complete}
Generalizationname
Student
StdSSN : Long StdFirstName : String StdLastName : String
Generalizationconstraint
5-45
Composition Relationship
OrdLine
LineNo : Integer Qty : Integer
Composition symbol (dark diamond)
Order
OrdNo : Long OrdDate : Date OrdAmt : Currency
1..n
1..1
5-46
Summary Data modeling is an important skill Crow’s Foot ERD notation is widely used Use notation precisely Use the diagram rules to ensure structural
consistency and completeness Understanding the ERD notation is a
prerequisite to applying the notation on business problems