Ch 5 - Entity Relationship Diagrams

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

CourseOfferNoOffLocationOffTime

Offering

Has

5-4

Cardinalities

Course OfferingCourse1 Offering1

Course2

Course3

Offering2

Offering3

Offering4

5-5

Cardinality Notation

Inside symbol: minimum cardinality



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

OfficeWorksIn

5-9

Comparison to Access Notation

CourseCoursenoCrsDescCrsUnits

1 8

OfferingOfferNo

CourseNoOffLocation

OffTime...

Access Relationship Diagram



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

RoomContains

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

Student OfferNoOffLocationOffTime

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


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 GrantsCourseNoCrsDescCrsUnits

Course


SSNNameCityStateZip

UnivPerson

Has

Teaches

Supervises


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


Course


SSNNameCityStateZip

UnivPerson

Has

Teaches

Supervises


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

Ch 5 - Entity Relationship Diagrams

Documents

Transcript of Ch 5 - Entity Relationship Diagrams