The Entity-Relationship Model Database Management Systems, R. Ramakrishnan and J. Gehrke 1 Entities name ssn lot Employees Database Management Systems, R. Ramakrishnan and J. Gehrke 2 ER Model Basics � Entity: Real-world object distinguishable from other objects. An entity is described (in DB) using a set of attributes � Entity Set : A collection of similar entities. E.g., all employees – All entities in an entity set have the same set of attributes – Each entity set has a key – Each attribute has a domain Database Management Systems, R. Ramakrishnan and J. Gehrke 3
Relationships since name dname ssn lot did budget Employees Works_In Departments Database Management Systems, R. Ramakrishnan and J. Gehrke 4 ER Model Basics (Contd.) � Relationship : Association among two or more entities. – E.g., Attishoo works in Pharmacy department. � Relationship Set : Collection of similar relationships. – An n-ary relationship set R relates n entity sets E1 ... En – Each relationship in R involves entities e1 in E1, ..., en in En Database Management Systems, R. Ramakrishnan and J. Gehrke 5 Relationships (Contd.) name ssn lot Employees super- subor- visor dinate Reports_To � Want to capture supervisor-subordinate relationship Database Management Systems, R. Ramakrishnan and J. Gehrke 6
Relationships (Contd.) id name Parts name name id id Departments Suppliers � Want to capture information that a Supplier s supplies Part p to Department d Database Management Systems, R. Ramakrishnan and J. Gehrke 7 Ternary Relationship name id Parts name name id id Suppliers Departments Contract Database Management Systems, R. Ramakrishnan and J. Gehrke 8 How are these different? from to name dname ssn lot did budget Employees Works_In2 Departments name dname ssn lot did budget Works_In3 Departments Employees from Duration to Database Management Systems, R. Ramakrishnan and J. Gehrke 9
Key Constraints since name dname � An employee can ssn lot did budget work in many departments; a dept Works_In Employees Departments can have many employees since � Each dept has at name dname most one manager, ssn lot did budget according to the key constraint on Employees Manages Departments Manages. Database Management Systems, R. Ramakrishnan and J. Gehrke 10 Key Constraints: Examples � Example Scenario 1: An inventory database contains information about parts and manufacturers. Each part is constructed by exactly one manufacturer. � Example Scenario 2: A customer database contains information about customers and sales persons. Each customer has exactly one primary sales person. � What do the ER diagrams look like? Database Management Systems, R. Ramakrishnan and J. Gehrke 11 Participation Constraints since name dname � An employee can work in many ssn lot did budget departments; a dept Works_In can have many Employees Departments employees � Each employee works in at least since name one department dname according to the ssn lot did budget participation constraint on Works_In Employees Departments Works_In Database Management Systems, R. Ramakrishnan and J. Gehrke 12
Participation Constraints: Examples � Example Scenario 1 (Contd.): Each part is constructed by exactly one or more manufacturer. � Example Scenario 2: Each customer has exactly one primary sales person. Database Management Systems, R. Ramakrishnan and J. Gehrke 13 What does this mean? since since name name dname dname ssn lot did did budget budget Employees Manages Departments Works_In since Database Management Systems, R. Ramakrishnan and J. Gehrke 14 Weak Entities � A weak entity can be identified uniquely only by considering the primary key of another ( owner ) entity. – Owner entity set and weak entity set must participate in a one-to- many relationship set (one owner, many weak entities). – Weak entity set must have total participation in this identifying relationship set. name cost pname age ssn lot Employees Policy Dependents Database Management Systems, R. Ramakrishnan and J. Gehrke 15
Exercise � Give two real-life examples where each of the following would occur: – A key constraint – A participation constraint – A weak entity set Database Management Systems, R. Ramakrishnan and J. Gehrke 16 name ssn lot ISA (`is a’) Hierarchies Employees � As in C++, or other PLs, hourly_wages hours_worked ISA attributes are inherited. contractid � If we declare A ISA B, every A Contract_Emps entity is also considered to be a B Hourly_Emps entity. � Overlap constraints : Can Joe be an Hourly_Emps as well as a Contract_Emps entity? ( Allowed/disallowed ) � Covering constraints : Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no) � Reasons for using ISA : – To add descriptive attributes specific to a subclass . – To identify entitities that participate in a relationship . Database Management Systems, R. Ramakrishnan and J. Gehrke 17 name ssn lot Aggregation Employees � Used when we have to model a Monitors until relationship involving (entitity sets and) a since started_on dname relationship set . pid pbudget did budget – Aggregation allows us Sponsors Departments to treat a relationship Projects set as an entity set for purposes of � Aggregation vs. ternary relationship : participation in � Monitors is a distinct relationship, (other) relationships. with a descriptive attribute. � Also, can say that each sponsorship is monitored by at most one employee. Database Management Systems, R. Ramakrishnan and J. Gehrke 18
ER Modeling: Case Study Drugwarehouse.com has offered you a free life-time supply of prescription drugs (no questions asked) if you design its database schema. Given the rising cost of health care, you agree. Here is the information that you gathered: � Patients are identified by their SSN, and we also store their names and age. � Doctors are identified by their SSN, and we also store their names and specialty. � Each patient has one primary care physician, and we want to know since when the patient has been with her primary care physician. � Each doctor has at least one patient. Database Management Systems, R. Ramakrishnan and J. Gehrke 19 Conceptual Design Using the ER Model � Design choices: – Should a concept be modeled as an entity or an attribute? – Should a concept be modeled as an entity or a relationship? – Identifying relationships: Binary or ternary? Aggregation? � Constraints in the ER Model: – A lot of data semantics can (and should) be captured. – But some constraints cannot be captured in ER diagrams. Database Management Systems, R. Ramakrishnan and J. Gehrke 20 Entity vs. Attribute � Should address be an attribute of Employees or an entity (connected to Employees by a relationship)? � Depends upon the use we want to make of address information, and the semantics of the data: � If we have several addresses per employee, address must be an entity (since attributes cannot be set- valued). � If the structure (city, street, etc.) is important, e.g., we want to retrieve employees in a given city, address must be modeled as an entity (since attribute values are atomic). Database Management Systems, R. Ramakrishnan and J. Gehrke 21
Entity vs. Attribute (Contd.) to from name dname � Works_In4 does not ssn lot did budget allow an employee to work in a department Works_In4 Departments Employees for two or more periods. � Similar to the problem of wanting to record several addresses for an employee: name dname We want to record several ssn lot did budget values of the descriptive Works_In4 Departments attributes for each instance of Employees this relationship. Accomplished by Duration to introducing new entity set, from Duration. Database Management Systems, R. Ramakrishnan and J. Gehrke 22 Entity vs. Relationship � First ER diagram OK if since a manager gets a dbudget name dname separate discretionary ssn lot did budget budget for each dept. Employees Departments Manages2 � What if a manager gets a discretionary name budget that covers ssn lot all managed depts? since dname – Redundancy: dbudget did Employees budget stored for each dept managed by manager. Departments Manages2 ISA – Misleading: Suggests dbudget associated with This fixes the department-mgr Managers dbudget combination. problem! Database Management Systems, R. Ramakrishnan and J. Gehrke 23 Binary vs. Ternary Relationships name ssn lot pname age � If each policy is Employees Covers Dependents owned by just one employee, Bad design Policies and each dependent is tied policyid cost to the covering name pname age policy, first ssn lot diagram is Dependents inaccurate. Employees � What are the Purchaser Beneficiary additional constraints in the Better design 2nd diagram? Policies policyid cost Database Management Systems, R. Ramakrishnan and J. Gehrke 24
Recommend
More recommend
