Chapter 4140.118.48.162/gjhwang/IMDB-chapter04.pdf · 2020. 10. 7. · 4 12 Resolving Multivalued...

4

1

Chapter 4

Entity Relationship (ER) Modeling

Database Systems:Design, Implementation, and Management,

Sixth Edition, Rob and Coronel

Database Systems: Design, Implementation, & Management, 6th Edition, Rob & Coronel

4

2

In this chapter, you will learn:

•How relationships between entities aredefined and refined, and how suchrelationships are incorporated into thedatabase design process

•How ERD components affect databasedesign and implementation

•How to interpret the modeling symbols for thefour most popular ER modeling tools

•That real-world database design oftenrequires that you reconcile conflicting goals


4

3

The Entity Relationship (ER) Model

•ER model forms the basis of an ER diagram

•ERD represents the conceptual database asviewed by end user

•ERDs depict the ER model’s three maincomponents:

–Entities

–Attributes

–Relationships


4

4

Entities•Refers to the entity set and not to a single

entity occurrence

•Corresponds to a table and not to a row in therelational environment

•In both the Chen and Crow’s Foot models, anentity is represented by a rectanglecontaining the entity’s name

•Entity name, a noun, is usually written incapital letters


4

5

Attributes

•Characteristics of entities

•In Chen model, attributes are represented byovals and are connected to the entityrectangle with a line

•Each oval contains the name of the attribute itrepresents

•In the Crow’s Foot model, the attributes aresimply written in the attribute box below theentity rectangle


4

6

The Attributes of the STUDENT Entity


4

7

Domains

•Attributes have a domain:

–The attribute’s set of possible values

•Attributes may share a domain


4

8

Primary Keys

•Underlined in the ER diagram

•Key attributes are also underlined infrequently used table structure shorthand

•Ideally composed of only a single attribute

•Possible to use a composite key:

–Primary key composed of more than oneattribute


4

9

The CLASS Table (Entity)Components and Contents


4

10

Attributes

•Composite attribute

•Simple attribute

•Single-value attribute

•Multivalued attributes


4

11

A Multivalued Attribute in an Entity


4

12

Resolving Multivalued Attribute Problems

•Although the conceptual model can handlemultivalued attributes, you should notimplement them in the relational DBMS

–Within original entity, create several newattributes, one for each of the originalmultivalued attribute’s components

•Can lead to major structural problems in the table

–Create a new entity composed of originalmultivalued attribute’s components


4

13

Splitting the MultivaluedAttribute into New Attributes


4

14

Components of the Multivalued Attribute


4

15

A New Entity Set Composed of aMultivalued Attribute’s Components


4

16

Derived Attributes

•Attribute whose value may be calculated(derived) from other attributes

•Need not be physically stored within thedatabase

•Can be derived by using an algorithm


4

17

Depiction of a Derived Attribute


4

18

Relationships

•Association between entities

•Participants:

–Entities that participate in a relationship

•Relationships between entities alwaysoperate in both directions

•Relationship can be classified as 1:M

•Relationship classification is difficult toestablish if you only know one side


4

19

Connectivity and Cardinality

•Connectivity

–Used to describe the relationship classification

•Cardinality

–Expresses the specific number of entityoccurrences associated with one occurrenceof the related entity

•Established by very concise statementsknown as business rules


4

20

Connectivity and Cardinality in an ERD


4

21

RELATIONSHIP Strength

•Existence dependence–Entity’s existence depends on the existence of

one or more other entities•Existence independence

–Entity can exist apart from one or more relatedentities

•Weak (non-identifying) relationships–One entity is not existence-independent on

another entity•Strong (Identifying) Relationships

–Related entities are existence-dependent


4

22

A Weak (Non-Identifying) RelationshipBetween COURSE and CLASS


4

23

A Weak RelationshipBetween COURSE and CLASS


4

24

Relationship Participation

•Optional:

–One entity occurrence does not require acorresponding entity occurrence in a particularrelationship

•Mandatory:

–One entity occurrence requires acorresponding entity occurrence in a particularrelationship


4

25

A Strong (Identifying) RelationshipBetween COURSE and CLASS


4

26

An Optional CLASS Entity in the RelationshipPROFESSOR teaches CLASS


4

27

COURSE and CLASSin a Mandatory Relationship


4

28

Relationship Strength and Weak Entities

•Weak entity meets two conditions–Existence-dependent:

•Cannot exist without entity with which it has arelationship

–Has primary key that is partially or totallyderived from the parent entity in therelationship

•Database designer usually determineswhether an entity can be described as weakbased on the business rules


4

29

A Weak Entity in an ERD


4

30

A Weak Entity in a Strong Relationship


4

31

Relationship Degree

•Indicates number of associated entities orparticipants

•Unary relationship

–Association is maintained within a single entity

•Binary relationship

–Two entities are associated

•Ternary relationship

–Three entities are associated


4

32

Three Types of Relationships


4

33

The Implementationof a Ternary Relationship


4

34

Recursive Relationships

•Relationship can exist between occurrencesof the same entity set

•Naturally found within a unary relationship


4

35

An ER Representationof Recursive Relationships


4

36

The 1:1 Recursive Relationship“EMPLOYEE is Married to EMPLOYEE”


4

37

Implementation of the M:N Recursive“PART Contains PART”Relationship


4

38

Implementation of the 1:M “EMPLOYEEManages EMPLOYEE”Recursive Relationship


4

39

Composite Entities

•Also known as bridge entities

•Composed of the primary keys of each of theentities to be connected

•May also contain additional attributes thatplay no role in the connective process


4

40

Converting the M:N Relationshipinto Two 1:M Relationships


4

41

The M:N RelationshipBetween STUDENT and CLASS


4

42

A Composite Entity in an ERD


4

43

Entity Supertypes and Subtypes

•Generalization hierarchy

–Depicts a relationship between a higher-levelsupertype entity and a lower-level subtypeentity

•Supertype entity

–Contains shared attributes

•Subtype entity

–Contains unique attributes


4

44

Nulls Created by Unique Attributes


4

45

A Generalization Hierarchy


4

46

Disjoint Subtypes

•Also known as non-overlapping subtypes

–Subtypes that contain a subset of thesupertype entity set

–Each entity instance (row) of the supertypecan appear in only one of the disjoint subtypes

•Supertype and its subtype(s) maintain a 1:1relationship


4

47

The EMPLOYEE/PILOTSupertype/Subtype Relationship


4

48

A Generalization Hierarchywith Overlapping Subtypes


4

49

A Comparison of ER Modeling Symbols


4

50

The Chen Representationof the Invoicing Problem


4

51

The Crow’s Foot Representationof the Invoicing Problem


4

52

The Rein85 Representationof the Invoicing Problem


4

53

The IDEF1X Representationof the Invoicing Problem


4

54

Developing an ER Diagram

•Database design is an iterative rather than alinear or sequential process

•Iterative process

–Based on repetition of processes andprocedures


4

55

A Supertype/Subtype Relationship


4

56

A Supertype/Subtype Relationshipin an ERD


4

57

Components of the ER Model


4

58

The Completed Tiny College ERD


4

59

The Challenge of Database Design:Conflicting Goals

•Database design must conform to designstandards

•High processing speeds are often a toppriority in database design

•Quest for timely information might be thefocus of database design


4

60

Various Implementationsof a 1:1 Recursive Relationship


4

61

Summary

•Entity relationship (ER) model–Uses ER diagrams to represent conceptual

database as viewed by the end user–Three main components

•Entities•Relationships•Attributes

–Includes connectivity and cardinality notations

•Connectivities and cardinalities are based onbusiness rules


4

62

Summary (continued)

•ER symbols are used to graphically depict theER model’s components and relationships

•ERDs may be based on many different ERmodels

•Entities can also be classified as supertypesand subtypes within a generalizationhierarchy

•Database designers are often forced to makedesign compromises

Date post:	19-Mar-2021
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

Chapter 4140.118.48.162/gjhwang/IMDB-chapter04.pdf · 2020. 10. 7. · 4 12 Resolving Multivalued...

Documents