Conceptual Design Steps in Database Design and The Entity- Relationship Model • Requirements Analysis – user needs; what must database do? CS 186 Spring 2006 • Conceptual Design Lectures 19 & 20 – high level descr (often done w/ER model) R &G - Chapter 2 • Logical Design A relationship, I think, is like a – translate ER into DBMS data model shark, you know? It has to • Schema Refinement constantly move forward or it – consistency, normalization dies. And I think what we got on • Physical Design - indexes, disk layout our hands is a dead shark. • Security Design - who accesses what, and how Woody Allen (from Annie Hall, 1979) Databases Model the Real World Conceptual Design • “Data Model” allows us to translate real • What are the entities and relationships in world things into structures computers the enterprise? can store • What information about these entities and • Many models: Relational, E-R, O-O, relationships should we store in the Network, Hierarchical, etc. database? • Relational • What are the integrity constraints or –Rows & Columns business rules that hold? – Keys & Foreign Keys to link Relations Enrolled • A database `schema’ in the ER Model can sid cid grade Students be represented pictorially (ER diagrams). 53666 Carnatic101 C sid name login age gpa 53666 Reggae203 B 53666 Jones jones@cs 18 3.4 • Can then map an ER diagram into a 53650 Topology112 A 53688 Smith smith@eecs 18 3.2 relational schema. 53666 History105 B 53650 Smith smith@math 19 3.8 ER Model Basics name ssn lot ER Model Basics (Contd.) since Employees name dname ssn lot did budget • Entity: Real-world object, distinguishable from other objects. An entity is described using a set Employees Works_In Departments of attributes. • Entity Set: A collection of similar entities. E.g., • Relationship: Association among two or more entities. all employees. E.g., Attishoo works in Pharmacy department. – All entities in an entity set have the same set – relationships can have their own attributes. of attributes. (Until we consider hierarchies, • Relationship Set: Collection of similar relationships. anyway!) –An n-ary relationship set R relates n entity sets E1 ... En ; – Each entity set has a key (underlined). each relationship in R involves entities e1 E1, ..., en En – Each attribute has a domain. name since dname ssn lot did budget ER Model Basics (Cont.) name Key Constraints ssn lot Employees Manages Departments An employee can Employees since work in many Works_In dname super- subor- departments; a did budget visor dinate since dept can have Reports_To Departments Works_In many employees. •Same entity set can participate in different In contrast, each dept relationship sets, or in different “roles” in has at most one the same set. manager, according to the key constraint Many-to- 1-to Many 1-to-1 on Manages. Many Participation Constraints Weak Entities • Does every employee work in a department? A weak entity can be identified uniquely only by • If so, this is a participation constraint considering the primary key of another – the participation of Employees in Works_In is said to be (owner) entity. total (vs. partial) – What if every department has an employee working in it? – Owner entity set and weak entity set must • Basically means “at least one” participate in a one-to-many relationship set (one owner, many weak entities). since name dname – Weak entity set must have total participation in ssn lot did budget this identifying relationship set. Employees Manages Departments name cost ssn lot pname age Works_In Means: “exactly one” Employees Policy Dependents since Weak entities have only a “partial key” (dashed underline) Binary vs. Ternary Relationships Binary vs. Ternary Relationships (Contd.) name ssn lot pname age • Previous example illustrated a case when two binary Employees Covers Dependents relationships were better than one ternary. If each policy is owned by just 1 employee: Bad design Policies • An example in the other direction: a ternary Key constraint on relation Contracts relates entity sets Parts, Policies would policyid cost Departments and Suppliers, and has descriptive mean policy can name pname age only cover 1 ssn lot attribute quantity. dependent! Dependents – No combination of binary relationships is an Employees adequate substitute. quantity Purchaser • Think through all Beneficiary the constraints in Parts Contract Departments the 2nd diagram! Better design Policies policyid cost Suppliers name Aggregation ssn lot Binary vs. Ternary Relationships (Contd.) Employees quantity Used to model a relationship Monitors until Parts Contract Departments involving a relationship set. VS. started_on since Suppliers Allows us to treat a dname pid pbudget did budget Parts needs Departments relationship set as an entity set Projects Sponsors Departments can-supply for purposes of Suppliers deals-with participation in Aggregation vs. ternary relationship? (other) Monitors is a distinct relationship, – S “can-supply” P, D “needs” P, and D “deals-with” S does with a descriptive attribute. not imply that D has agreed to buy P from S. relationships. – How do we record qty? Also, can say that each sponsorship is monitored by at most one employee. name ISA (`is a’) Hierarchies ssn lot Review - Our Basic ER Model As in C++, or other PLs, Employees attributes are inherited. hourly_wages hours_worked • Entities and Entity Set (boxes) ISA If we declare A ISA B, contractid • Relationships and Relationship sets (diamonds) every A entity is also –binary considered to be a B Hourly_Emps Contract_Emps –n-ary entity. • Key constraints (1-1,1-M, M-M, arrows on 1 side) • Overlap constraints: Can Simon be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed) • Participation constraints (bold for Total) • Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no) • Weak entities - require strong entity for key • Reasons for using ISA: • Aggregation - an alternative to n-ary relationships – To add descriptive attributes specific to a subclass. • i.e. not appropriate for all entities in the superclass • Isa hierarchies - abstraction and inheritance – To identify entities that participate in a particular relationship • i.e., not all superclass entities participate Conceptual Design Using the ER Model Entity vs. Attribute • Should address be an attribute of Employees • ER modeling can get tricky! or an entity (related to Employees)? • Design choices: • Depends upon how we want to use address – Should a concept be modeled as an entity or an attribute? information, and the semantics of the data: – Should a concept be modeled as an entity or a relationship? • If we have several addresses per employee, – Identifying relationships: Binary or ternary? Aggregation? address must be an entity (since attributes • Note constraints of the ER Model: cannot be set-valued). – A lot of data semantics can (and should) be captured. •If the structure (city, street, etc.) is important, – But some constraints cannot be captured in ER diagrams. address must be modeled as an entity (since • We’ll refine things in our logical (relational) design attribute values are atomic). Entity vs. Attribute (Cont.) Entity vs. Relationship OK as long as a from to name dname manager gets a ssn lot did since dbudget • Works_In2 does not budget separate name dname allow an employee to discretionary budget ssn lot did budget Employees Works_In2 Departments work in a department (dbudget) for each for two or more periods. dept. EmployeesManages2 Departments • Similar to the problem of What if manager’s wanting to record several dbudget covers all name addresses for an ssn lot managed depts? dname employee: we want to name dname did (can repeat value, but Employees budget record several values of ssn lot did budget such redundancy is the descriptive attributes Departments for each instance of this Employees Works_In3 Departments problematic) is_manager relationship. managed_by since from Duration to apptnum Mgr_Appts dbudget A Cadastral E-R Diagram These things get pretty hairy! • Many E-R diagrams cover entire walls! • A modest example: A Cadastral E-R Diagram Logical DB Design: ER to Relational ssn name lot • Entity sets to tables. 123-22-3666 Attishoo 48 name 231-31-5368 Smiley 22 cadastral: showing or recording property boundaries, subdivision lines, buildings, ssn lot and related details 131-24-3650 Smethurst 35 Source: US Dept. Interior Bureau of Land Management, Employees Federal Geographic Data Committee Cadastral Subcommittee http://www.fairview-industries.com/standardmodule/cad-erd.htm CREATE TABLE Employees (ssn CHAR(11), name CHAR(20), lot INTEGER, PRIMARY KEY (ssn)) Relationship Sets to Tables Review: Key Constraints CREATE TABLE Works_In( • Each dept has at • In translating a many-to- ssn CHAR(1), most one since many relationship set to a did INTEGER, name dname manager, since DATE, ssn lot did budget relation, attributes of the according to the PRIMARY KEY (ssn, did), relation must include: key constraint on FOREIGN KEY (ssn) Manages. Employees Manages Departments 1) Keys for each REFERENCES Employees, participating entity set FOREIGN KEY (did) (as foreign keys). This REFERENCES Departments) set of attributes forms ssn did since a superkey for the Translation to relation. 123-22-3666 51 1/1/91 relational model? 123-22-3666 56 3/3/93 2) All descriptive 1-to-1 1-to Many Many-to-1 Many-to-Many attributes. 231-31-5368 51 2/2/92 Translating ER with Key Constraints Review: Participation Constraints since name dname • Does every department have a manager? ssn lot did budget – If so, this is a participation constraint: the participation of Employees Manages Departments Departments in Manages is said to be total (vs. partial). • Since each department has a unique manager, we •Every did value in Departments table must appear in a could instead combine Manages and Departments. row of the Manages table (with a non-null ssn value!) CREATE TABLE Manages( CREATE TABLE Dept_Mgr( since name dname ssn CHAR(11), did INTEGER, ssn lot did budget did INTEGER, dname CHAR(20), since DATE, Vs.