Presentation is loading. Please wait.

Presentation is loading. Please wait.

10/15/2002TCSS445A Isabelle Bichindaritz1 Entity Relationship (E-R) Modeling.

Similar presentations

Presentation on theme: "10/15/2002TCSS445A Isabelle Bichindaritz1 Entity Relationship (E-R) Modeling."— Presentation transcript:

1 10/15/2002TCSS445A Isabelle Bichindaritz1 Entity Relationship (E-R) Modeling

2 10/15/2002TCSS445A Isabelle Bichindaritz2 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

3 10/15/2002TCSS445A Isabelle Bichindaritz3 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 Websters 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

4 10/15/2002TCSS445A Isabelle Bichindaritz4 Data Models: Degrees of Data Abstraction Figure 3.1

5 10/15/2002TCSS445A Isabelle Bichindaritz5 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

6 10/15/2002TCSS445A Isabelle Bichindaritz6 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

7 10/15/2002TCSS445A Isabelle Bichindaritz7 Degrees of Abstraction Three main levels of data models: deliverables –Conceptual data model Project initiation and planning: ERDs with entities and relationships only Analysis: ERDs 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

8 10/15/2002TCSS445A Isabelle Bichindaritz8 Conceptual Data Model Example

9 10/15/2002TCSS445A Isabelle Bichindaritz9 Internal / External Data Models Example

10 10/15/2002TCSS445A Isabelle Bichindaritz10 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

11 10/15/2002TCSS445A Isabelle Bichindaritz11 Attributes Characteristics of entities Domain is set of possible values ( (true, false), … ) Primary keys underlined

12 10/15/2002TCSS445A Isabelle Bichindaritz12 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

13 10/15/2002TCSS445A Isabelle Bichindaritz13 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)

14 10/15/2002TCSS445A Isabelle Bichindaritz14 Multivalued Attributes

15 10/15/2002TCSS445A Isabelle Bichindaritz15 Multivalued Attributes

16 10/15/2002TCSS445A Isabelle Bichindaritz16 Derived Attributes

17 10/15/2002TCSS445A Isabelle Bichindaritz17 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)

18 10/15/2002TCSS445A Isabelle Bichindaritz18 Connectivity and Cardinality in an ERD Figure 3.12

19 10/15/2002TCSS445A Isabelle Bichindaritz19 Relationship Strength Existence dependence –Entitys 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 doesnt 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

20 10/15/2002TCSS445A Isabelle Bichindaritz20 Weak Relationship IE = Inversion Entity = a non-unique identifier for an entity

21 10/15/2002TCSS445A Isabelle Bichindaritz21 Strong Relationship

22 10/15/2002TCSS445A Isabelle Bichindaritz22 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

23 10/15/2002TCSS445A Isabelle Bichindaritz23 Optional Participation

24 10/15/2002TCSS445A Isabelle Bichindaritz24 Weak Entity Existence-dependent on another entity Has primary key that is partially or totally derived from parent entity Figure 3.19

25 10/15/2002TCSS445A Isabelle Bichindaritz25 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

26 10/15/2002TCSS445A Isabelle Bichindaritz26 Three Types of Relationships Figure 3.21

27 10/15/2002TCSS445A Isabelle Bichindaritz27 Composite Entities Used to bridge between M:N relationships Bridge entities composed of primary keys of each entity needing connection Figure 3.30

28 10/15/2002TCSS445A Isabelle Bichindaritz28 Composite Entities (cont.) Figure 3.31

29 10/15/2002TCSS445A Isabelle Bichindaritz29 Composite Entities (cont.)

30 10/15/2002TCSS445A Isabelle Bichindaritz30 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

31 10/15/2002TCSS445A Isabelle Bichindaritz31 Generalization Hierarchy with Disjoint Subtypes

32 10/15/2002TCSS445A Isabelle Bichindaritz32 Generalization Hierarchy with Overlapping Subtypes Figure 3.35

33 10/15/2002TCSS445A Isabelle Bichindaritz33 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 Crows Foot –Cannot detail all cardinalities Rein85 –Similar to Crows Foot –Operates at higher level of abstraction IDEF1X –Derivative of ICAM studies in the late 1970s –Uses fewer symbols

34 10/15/2002TCSS445A Isabelle Bichindaritz34 Comparison of E-R Modeling Symbols Figure 3.36

35 10/15/2002TCSS445A Isabelle Bichindaritz35 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

36 10/15/2002TCSS445A Isabelle Bichindaritz36 Supertype/Subtype Relationship in an ERD Figure 3.42

37 10/15/2002TCSS445A Isabelle Bichindaritz37 First ERD Segment Established Figure 3.43

38 10/15/2002TCSS445A Isabelle Bichindaritz38 Second and Third ERD Segments Established Figures 3.44 & 3.45

39 10/15/2002TCSS445A Isabelle Bichindaritz39 Fourth and Fifth ERD Segments Established Figures 3.46 & 3.47

40 10/15/2002TCSS445A Isabelle Bichindaritz40 Sixth and Seventh ERD Segments Established Figures 3.48 & 3.49

41 10/15/2002TCSS445A Isabelle Bichindaritz41 Eighth ERD Segment Established Figures 3.50

42 10/15/2002TCSS445A Isabelle Bichindaritz42 Ninth ERD Segment Established Figures 3.51

43 10/15/2002TCSS445A Isabelle Bichindaritz43 Components of E-R Model Table 3.2

44 10/15/2002TCSS445A Isabelle Bichindaritz44 Completed ERD Figure 3.52

45 10/15/2002TCSS445A Isabelle Bichindaritz45 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

46 10/15/2002TCSS445A Isabelle Bichindaritz46 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.

47 10/15/2002TCSS445A Isabelle Bichindaritz47 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 ?

48 10/15/2002TCSS445A Isabelle Bichindaritz48 Burger Inventory Example

Download ppt "10/15/2002TCSS445A Isabelle Bichindaritz1 Entity Relationship (E-R) Modeling."

Similar presentations

Ads by Google