10/15/2002 TCSS445A Isabelle Bichindaritz 1
Entity Relationship (E-R) Modeling
10/15/2002 TCSS445A Isabelle Bichindaritz 2
Learning Objectives• Conceptual model(s)• Internal and external models • Definition and refinement of
relationships between entities during the database design process
• ERD components and database design and implementation
• Interpretation of the modeling symbols for the four most popular E-R modeling tools
10/15/2002 TCSS445A Isabelle Bichindaritz 3
Basic Modeling Concepts• Art and science• Good judgment coupled with powerful design tools• Models
– “Description or analogy used to visualize something that cannot be directly observed” Webster’s Dictionary
– “A model is a representation of the world in simplified terms, it is an abstraction of the real world”
• Data Model– Relatively simple representation of complex real-world
data structures
10/15/2002 TCSS445A Isabelle Bichindaritz 4
Data Models: Degrees of Data Abstraction
Figure 3.1
10/15/2002 TCSS445A Isabelle Bichindaritz 5
Degrees of Abstraction• Conceptual
– Global view of data from application domain, based on end-users requirements
– Basis for identification and description of main data items
– ERD used to graphically represent conceptual data model (or class diagram in UML)
– Hardware and software (and DBMS) independent
• Internal– Representation of database as seen by DBMS– Adapts conceptual model to a specific DBMS– Software dependent
10/15/2002 TCSS445A Isabelle Bichindaritz 6
Degrees of Abstraction • External
– Users’ views of data environment– Provides subsets of internal view– Makes application program development easier– Facilitates designers’ tasks– Ensures adequacy of conceptual model– Ensures security constraints in design
• Physical– Lowest level of abstraction– Software and hardware dependent– Requires definition of physical storage devices and
access methods
10/15/2002 TCSS445A Isabelle Bichindaritz 7
Degrees of Abstraction • Three main levels of data models: deliverables
– Conceptual data model • Project initiation and planning: ERD’s with entities and
relationships only• Analysis: ERD’s refined with attributes
– Logical data model = Internal + external data model: a set of normalized relations, based on ERD and views/forms design
– Physical data model = physical file and database design
10/15/2002 TCSS445A Isabelle Bichindaritz 8
Conceptual Data Model Example
10/15/2002 TCSS445A Isabelle Bichindaritz 9
Internal / External Data Models Example
10/15/2002 TCSS445A Isabelle Bichindaritz 10
The Entity Relationship (E-R) Model
• Represents conceptual view• Main Components
– Entities• Stands for entity set• Corresponds to entire table, not row• Represented by rectangle• Rows correspond to entity instances or entity occurrences
– Attributes• Represented by ovals or in entity
– Relationships• Represented by diamonds or just a relationship name
10/15/2002 TCSS445A Isabelle Bichindaritz 11
Attributes• Characteristics of entities• Domain is set of possible values ( (true,
false), … )• Primary keys underlined
10/15/2002 TCSS445A Isabelle Bichindaritz 12
Attributes • Simple
– Cannot be subdivided– Age, sex, marital status
• Composite– Can be subdivided into
additional attributes– Address into street, city, zip
• Single-valued– Can have only a single
value– Person has one social
security number
• Multi-valued– Can have many values– Person may have several
college degrees– Can be represented by a 1-
M relationship
• Derived– Can be derived with
algorithm– Age can be derived from
date of birth
10/15/2002 TCSS445A Isabelle Bichindaritz 13
Attributes• Examples:
CLASS(CLASS_CODE, CRS_CODE, CLASS_SECTION, CLASS_TIME, CLASS_ROOM, PROF_NUM)
CLASS(CRS_CODE, CLASS_SECTION, CLASS_TIME, CLASS_ROOM, PROF_NUM)
STUDENT(Student_Id, Student_Name, Address, Phone_Number, Major)
10/15/2002 TCSS445A Isabelle Bichindaritz 14
Multivalued Attributes
10/15/2002 TCSS445A Isabelle Bichindaritz 15
Multivalued Attributes
10/15/2002 TCSS445A Isabelle Bichindaritz 16
Derived Attributes
10/15/2002 TCSS445A Isabelle Bichindaritz 17
Relationships• Association between entities• Connected entities are called participants• Operate in both directions• Connectivity describes relationship classification
– 1:1, 1:M, M:N
• Cardinality– Expresses number of entity occurrences associated with
one occurrence of related entity: (1,4), (1,N), …– How many classes does a professor teach ? (1,4)
10/15/2002 TCSS445A Isabelle Bichindaritz 18
Connectivity and Cardinality in an ERD
Figure 3.12
10/15/2002 TCSS445A Isabelle Bichindaritz 19
Relationship Strength• Existence dependence
– Entity’s existence depends on existence of related entities– Existence-independent entities can exist apart from related
entities– EMPLOYEE claims DEPENDENT
• Weak (non-identifying)
– One entity is existence-independent on another– PK of related entity doesn’t contain PK component of
parent entity
• Strong (identifying)
– One entity is existence-dependent on another– PK of related entity contains PK component of parent entity
10/15/2002 TCSS445A Isabelle Bichindaritz 20
Weak Relationship
IE = Inversion Entity = a non-unique
identifier for an entity
10/15/2002 TCSS445A Isabelle Bichindaritz 21
Strong Relationship
10/15/2002 TCSS445A Isabelle Bichindaritz 22
Relationship Participation• Optional
– Entity occurrence does not require a corresponding occurrence in related entity
– Shown by drawing a small circle on side of optional entity on ERD
• Mandatory– Entity occurrence requires corresponding occurrence in
related entity– If no optionality symbol is shown on ERD, it is
mandatory
10/15/2002 TCSS445A Isabelle Bichindaritz 23
Optional Participation
10/15/2002 TCSS445A Isabelle Bichindaritz 24
Weak Entity• Existence-dependent on another entity
• Has primary key that is partially or totally
derived from parent entity
Figure 3.19
10/15/2002 TCSS445A Isabelle Bichindaritz 25
Relationship Degree
• Indicates number of associated entities• Unary
– Single entity– Recursive– Exists between occurrences of same entity set
• Binary– Two entities associated
• Ternary– Three entities associated
10/15/2002 TCSS445A Isabelle Bichindaritz 26
Three Types of Relationships
Figure 3.21
10/15/2002 TCSS445A Isabelle Bichindaritz 27
Composite Entities• Used to ‘bridge’ between M:N relationships
• Bridge entities composed of primary keys of each entity needing connection
Figure 3.30
10/15/2002 TCSS445A Isabelle Bichindaritz 28
Composite Entities (con’t.)
Figure 3.31
10/15/2002 TCSS445A Isabelle Bichindaritz 29
Composite Entities (con’t.)
10/15/2002 TCSS445A Isabelle Bichindaritz 30
Entity Supertypes and Subtypes• Generalization hierarchy
– Depicts relationships between higher-level supertype and lower-level subtype entities
– Supertype has shared attributes– Subtypes have unique attributes– Disjoint relationships
• Unique subtypes• Non-overlapping• Indicated with a ‘G’
– Overlapping subtypes use ‘Gs’ Symbol
10/15/2002 TCSS445A Isabelle Bichindaritz 31
Generalization Hierarchy with Disjoint Subtypes
10/15/2002 TCSS445A Isabelle Bichindaritz 32
Generalization Hierarchy with Overlapping Subtypes
Figure 3.35
10/15/2002 TCSS445A Isabelle Bichindaritz 33
Comparison of E-R Modeling Symbols• Alternate styles developed to enable easier use of CASE
tools• Chen
– Moved conceptual design into practical database design arena
• Crow’s Foot– Cannot detail all cardinalities
• Rein85– Similar to Crow’s Foot – Operates at higher level of abstraction
• IDEF1X– Derivative of ICAM studies in the late 1970’s– Uses fewer symbols
10/15/2002 TCSS445A Isabelle Bichindaritz 34
Comparison of E-R Modeling Symbols
Figure 3.36
10/15/2002 TCSS445A Isabelle Bichindaritz 35
Developing an E-R Diagram
• Iterative Process– Step1: General narrative of organizational
operations developed– Step2: Basic E-R Model graphically depicted
and reviewed– Step3: Modifications made to incorporate
newly discovered E-R components
• Repeat process until designers and users agree E-R Diagram complete
10/15/2002 TCSS445A Isabelle Bichindaritz 36
Supertype/Subtype Relationship in an ERD
Figure 3.42
10/15/2002 TCSS445A Isabelle Bichindaritz 37
First ERD Segment Established
Figure 3.43
10/15/2002 TCSS445A Isabelle Bichindaritz 38
Second and Third ERD Segments Established
Figures 3.44 & 3.45
10/15/2002 TCSS445A Isabelle Bichindaritz 39
Fourth and Fifth ERD Segments Established
Figures 3.46 & 3.47
10/15/2002 TCSS445A Isabelle Bichindaritz 40
Sixth and Seventh ERD Segments Established
Figures 3.48 & 3.49
10/15/2002 TCSS445A Isabelle Bichindaritz 41
Eighth ERD Segment Established
Figures 3.50
10/15/2002 TCSS445A Isabelle Bichindaritz 42
Ninth ERD Segment Established
Figures 3.51
10/15/2002 TCSS445A Isabelle Bichindaritz 43
Components of E-R Model
Table 3.2
10/15/2002 TCSS445A Isabelle Bichindaritz 44
Completed ERD
Figure 3.52
10/15/2002 TCSS445A Isabelle Bichindaritz 45
Challenge of Database Design: Conflicting Goals
• Database must be designed to conform to design standards
• High-speed processing may require design compromises
• Quest for timely information may be the focus of database design
• Other concerns– Security– Performance– Shared access– Integrity
10/15/2002 TCSS445A Isabelle Bichindaritz 46
Burger Inventory Example
• The Burger store wants to develop a new inventory system. Analysts have determined that the following data are required to represent the data needed by the inventory system:– An INVOICE includes one or more INVOICE ITEMS,
each of which corresponds to an INVENTORY ITEM. Obviously, an INVOICE ITEM cannot exist without an associated INVOICE, and over time, there will be zero to many receipts, or INVOICE ITEMs, for an INVENTORY SYSTEM.
10/15/2002 TCSS445A Isabelle Bichindaritz 47
Burger Inventory Example
– Each PRODUCT has a RECIPE of INVENTORY ITEMs, containing several RECIPE LINEs. Thus, RECIPE LINE is an associative entity supporting a bill-of-materials type relationship between PRODUCT and INVENTORY ITEM.
– A SALE indicates that Burger sells one or more ITEM SALES, each of which corresponds to a PRODUCT. ITEM SALE cannot exist without an associated SALE, and over time there will be zero to many ITEM SALES for a PRODUCT.
Note: the following ERD does not represent weak entities,and relationships. Do you see any ?
10/15/2002 TCSS445A Isabelle Bichindaritz 48
Burger Inventory Example
Receipt_Num berSale_Date
SALE
Quantity_Sold
ITEM SALE
Product_IdProduct_Description
PRODUCT
Quantity_Used
RECIPE LINE
Invoice_Num berVendor_IdInvoice_DatePaid
INVOICE
Quantity_Added
INVOICE ITEM
Item _Num berItem _DescriptionQuantity_in_StockType_of_ItemMinim um _Order_Quantity
INVENTORY ITEM
sells
is ordered on
is produced by is used in
is invoiced on
includes