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