Download presentation
1
Entity Relationship (E-R) Modeling
10/15/2002 TCSS445A Isabelle Bichindaritz
2
TCSS445A Isabelle Bichindaritz
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
TCSS445A Isabelle Bichindaritz
Attributes Characteristics of entities Domain is set of possible values ( (true, false), … ) Primary keys underlined 10/15/2002 TCSS445A Isabelle Bichindaritz
12
TCSS445A Isabelle Bichindaritz
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
TCSS445A Isabelle Bichindaritz
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
TCSS445A Isabelle Bichindaritz
Derived Attributes 10/15/2002 TCSS445A Isabelle Bichindaritz
17
TCSS445A Isabelle Bichindaritz
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
TCSS445A Isabelle Bichindaritz
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
TCSS445A Isabelle Bichindaritz
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
TCSS445A Isabelle Bichindaritz
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
TCSS445A Isabelle Bichindaritz
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
TCSS445A Isabelle Bichindaritz
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
10/15/2002 TCSS445A Isabelle Bichindaritz
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.