1. The Entity-Relationship Model (Chapter 3 Additional Notes – Part a) Laku Chidambaram W.P. Wood Professor of MIS University of Oklahoma

2. © Laku Chidambaram, Ph.D. Overview zDatabase Design: The E-R Model zEntities zAttributes zRelationships

3. © Laku Chidambaram, Ph.D. Database Design Engineer (A/C Receivable) Engineer Pilot (Order Entry) Pilot Passenger (Inventory) (Inventory)Passenger External View General Design (Comprehensive Data Model) General Design (Comprehensive Data Model) Conceptual Model (ERD) Blueprint (Database Schema) Blueprint Logical Model (Relational) Aircraft (Database) Physical Reality (DBMS)

4. © Laku Chidambaram, Ph.D. The Entity Relationship Diagram zAn E-R diagram is a graphical representation of an organization’s data zSuch data includes the people, places, objects, events, or concepts (along with their characteristics and relationships) that are relevant to an organization

5. © Laku Chidambaram, Ph.D. Entities zPerson, place, object, event, or concept about which the organization wishes to collect and maintain data zNouns are used to describe entities zExamples: yEmployee, Student, Nurse yCity, State, Country ySale, Registration, Account zEntity Type versus Entity Instance

6. © Laku Chidambaram, Ph.D. Types of Entities zStrong Entity: can exist independently zWeak Entity: cannot exist without the “owner” entity (with which it has an identifying relationship) yHas a primary key that is derived from the owner entity in the relationship EMPLOYEE has DEPENDENT

7. © Laku Chidambaram, Ph.D. Attributes zProperties or characteristics of entities (or relationships) zProvide the actual data that describe entities (or relationships) EMPLOYEE E_Address E_Name E_ID

8. © Laku Chidambaram, Ph.D. Unique Attributes zCandidate keys are ALL attributes that uniquely define an instance of an entity zA primary key is the candidate key that is chosen as the “most” unique of them all! zA primary key (or identifier) is ideal if it: ydoes not change over time yhas unique values that are not null ydoes not use “intelligent” features y(Note: may need to substitute simple keys for long, i.e., composite, keys)

9. © Laku Chidambaram, Ph.D. Composite Attributes zAttributes that are not “atomic” (or simple), i.e., those attributes that can (and need to) be broken down further EMPLOYEE E_Address (E_Street, E_City, E-Zip) E_Name E_ID

10. © Laku Chidambaram, Ph.D. Multi-valued Attributes zSome attributes may have multiple values... z… but they may need to be “fixed” before proceeding EMPLOYEE {E_Skill} EMPLOYEE has SKILL S_Code S_Name

11. © Laku Chidambaram, Ph.D. Derived Attributes zThose attributes whose values can be calculated from the values of other attributes (either in the database or in the system). zValue is not stored in the database (since it does not take up any space) yE.g., Age can be calculated, where date-of- birth is stored

12. © Laku Chidambaram, Ph.D. Relationships zRefer to the associations (or links) between entities zUse verbs to describe the links zMay have attributes (in some cases) zAre directional STUDENT Lives in DORMITORY EMPLOYEE Works in STORE

13. © Laku Chidambaram, Ph.D. Associative Entities zA (many-to-many) relationship that is better represented as an entity because it: ycontains attributes from the entities it links and has its own attributes yhas independent meaning to end-users CUSTOMER Orders PRODUCT CUSTOMERORDERPRODUCT