1. Database Design – Lecture 4 Conceptual Data Modeling

2. 2 Lecture Objectives That key questions need to be answered when gathering requirements That a conceptual relational database model’s basic components are entities and relationships among entities How relationships between entities are defined and refined and how those relationships are incorporated into the database design process How ERD components affect database design and implementation

3. 3 Developing an ER Diagram Building an ERD usually involves the following activities: Create detailed narrative of organization’s description of operations Identify business rules based on description of operations Identify main entities and relationships from business rules Develop initial ERD

4. 4 Developing an ER Diagram Building an ERD continued: Identify attributes and primary keys that adequately describe entities Revise and review ERD

5. 5 Discovering Entities Requirements gathering – focusing on data: Interview end users Review existing documentation (forms, reports) Brainstorming Overview of the business Questionnaires Review system documentation Functional/non-functional requirements Work flow diagrams Data flow diagrams Use case descriptions

6. 6 Discovering Entities Use a technique like ‘noun filtering’ Look for nouns that describe data Similar nouns can be grouped into an entity Some nouns will become attributes

7. 7 Sample Conceptual Model - ERD This is a preliminary conceptual model. Model shows entities without attributes or relationships.

8. 8 Entity Corresponds to a table and not to a row in the relational environment Can be strong or weak Entity name is a noun

9. 9 Entity can be strong or weak Strong Entity (existence independent) Does not depend on the existence of some other entity to exist Each entity occurrence of a strong entity is uniquely identifiable using the primary key attributes of that entity type Can identify each Plan based on a plan code and can identify each Client by a client code. Therefore, both are strong entities. Entity Weak relationship (non-identifying)

10. 10 Entity Entity can be strong or weak Weak Entity (existence dependent) Does depend on the existence of some other entity in order to exist Cannot identify each occurrence of the Dependent. We can only Identify the Dependent by Knowing the Parent, through the primary key of the Parent. Can identify each parent based on a primary key (therefore it is a strong entity type) and can only identify each dependent only by knowing the Parent. Therefore dependent is a weak entity.

11. 11 Relationship Participation Optional participation One entity occurrence does not require corresponding entity occurrence in particular relationship Mandatory participation One entity occurrence requires corresponding entity occurrence in particular relationship

12. 12 Relationship Participation

13. 13 Relationship Participation

14. 14 Summary Entity relationship (ER) model Uses ERD to represent conceptual database as viewed by end user ERD’s main components: Entities Relationships Includes connectivity and cardinality notations Connectivities and cardinalities are based on business rules In ERD, M:N relationship is valid at conceptual level