Databases Model the Real World

The EntityRelationship

• “Data Model” allows us to translate real
world things into structures computers
can store
• Many models: Relational, E-R, O-O,
Network, Hierarchical, etc.
• Relational
– Rows & Columns
– Keys & Foreign Keys to link Relations

R &G - Chapter 2

A relationship, I think, is like a
shark, you know? It has to
constantly move forward or it
dies. And I think what we got
on our hands is a dead shark.


Woody Allen (from Annie Hall, 1979)

Steps in Database Design
• Requirements Analysis
– user needs; what must database
• Conceptual Design
– high level descr (often done w/ER
• Logical Design
– translate ER into DBMS data model
• Schema Refinement
– consistency, normalization
• Physical Design - indexes, disk layout
• Security Design - who accesses what,
and how

ER Model Basics










5366 Jones jones@cs
5368 Smith smith@eecs 18
5365 Smith smith@mat 19

Conceptual Design


• What are the entities and relationships
in the enterprise?
• What information about these entities
and relationships should we store in the
• What are the integrity constraints or
business rules that hold?
• A database `schema’ in the ER Model
can be represented pictorially (ER
• Can map an ER diagram into a
relational schema.

ER Model Basics






• Entity: Real-world object, distinguishable
from other objects. An entity is described
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.
(Until we
consider hierarchies, anyway!)
– Each entity set has a key
– Each attribute has a domain.




• Relationship: Association among two or more
entities. E.g., Attishoo works in Pharmacy
– relationships can have their own attributes.
• Relationship Set: Collection of similar
– An n-ary relationship set R relates n entity sets
E1 ... En ; each relationship in R involves entities e1
 E1, ..., en  En

and has descriptive attribute qty. No combination of binary relationships is an adequate substitute. Ternary Relationships If each policy is owned by just 1 employee: Key constraint on Policies would mean policy can only cover 1 dependent! •Think through all the constraints in the 2nd diagram! name ssn Employees lot pname Bad design ssn name age Covers Dependents • Previous example illustrated a case when two binary relationships were better than one ternary relationship. Departments and Suppliers. Ternary Relationships (Contd. – Weak entity set must have total participation in this identifying relationship set. many weak entities).name name ER Model Basics (Cont. lot did budget since Manages Many-toMany 1-to Many 1-to-1 Departments A weak entity can be identified uniquely only by considering the primary key of another ( owner) entity. name lot cost pname age Works_In Means: “exactly one” since Policy Employees Dependents Weak entities have only a “partial key” (dashed underline) Binary vs. this is a participation constraint – the participation of Employees in Works_In is said to be total (vs. partial) – What if every department has an employee working in it? name dname • Basically means “at least one” ssn An employee can work in many departments. or in different “roles” in the same set. Policies policyid cost pname lot age Dependents Employees Purchaser Better design Beneficiary Policies policyid cost • An example in the other direction: a ternary relation Contracts relates entity sets Parts. ssn Em ployees Works_In since Weak Entities Participation Constraints • Does every employee work in a department? • If so. one manager.) ssn Key Constraints lot since ss n lot Employees dname did Manages budget Departments Employees rsupe visor since dname budget did Departments s ubord inate Works_In • Same entity set can participate in different relationship sets. each dept has at most employees. . – Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner.) Binary vs. according to the key constraint on Manages. a dept can have Inmany contrast.

Entity vs. name Monitors until since started_on pid pbudget did dname budget Sponsors Departments Projects Allows us to treat a relationship Aggregation vs. address must be an entity (since attributes cannot be set-valued). .require strong entity for key • Next. arrows on 1 side) • Participation constraints (bold for Total) • Weak entities . • ER modeling can get tricky! • 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? • Note constraints of the ER Model: – A lot of data semantics can (and should) be captured. Similar to the problem of wanting to record several addresses for an employee: we want to record several values of the descriptive attributes for each instance of this relationship.) qty Parts Contract Departments Suppliers Parts VS . relationships purposes of with a descriptive attribute. a couple more “advanced” concepts… – S “can-supply” P. address must be modeled as an entity (since attribute values are atomic). and D “dealswith” S does not imply that D has agreed to buy P from S. and the semantics of the data: •If we have several addresses per employee.Summary so far Binary vs. ternary participation set as an entityrelationship? in (other) set for ❖Monitors is a distinct relationship. Attribute (Cont. ❖ Also.) is important. – But some constraints cannot be captured in ER diagrams. street. – How do we record qty? Aggregati on ssn Conceptual Design Using the ER Model lot Employees Used to model a relationship involving a relationship set. etc. to lot Works_In2 Employees ssn dname did budget Departments name lot Employees did Works_In3 dname budget Departments to from Dur tion a .1-M. Ternary Relationships (Contd. •If the structure (city.) from name ssn • Works_In2 does not allow an employee to work in atwo department for or more • periods. D “needs” P. Departments needs can-supply Suppliers deals-with • Entities and Entity Set (boxes) • Relationships and Relationship sets (diamonds) – binary – n-ary • Key constraints (1-1. can say that each sponsorship is monitored by at most one employee. M-M. • We’ll refine things in our logical (relational) design Entity vs. Attribute • Should address be an attribute of Employees or an entity (related to Employees)? • Depends upon how we want to use address information.

but such redundancy is problematic) since name ssn dbudget lot Employees dname budget did Departments Manages2 name ssn lot dname did Employees budget Departments is_manager apptnum managed_by Try this at home . credits. name CHAR(20). PRIMARY KEY (ssn)) . etc. Federal Geographic Data Committee Cadastral Subcommittee http://www. semester taken.Now you try it Entity vs. titles.htm Converting ER to Relational Logical DB Design: ER to Relational ssn • Entity sets to tables. What if manager’s dbudget covers all managed depts? (can repeat value. subdivision lines. Teachers • Courses have ids. lot INTEGER. and related details Source: US Dept. Interior Bureau of Land Management. • But many simple concepts in ER are subtle to specify in relations ssn lot name lot 123-22-3666 Attishoo 48 231-31-5368 Smiley 22 131-24-3650 Smethurst 35 Employees CREATE TABLE Employees (ssn CHAR(11). • Must track which classes a professor has taught • Database should work over multiple semesters since Mgr_Appts dbudget These things get pretty hairy! A Cadastral E-R Diagram • Many E-R diagrams cover entire walls! • A modest example: cadastral: showing or recording property boundaries.fairview-industries. Relationship OKseparate as long as a manager gets discretionary a budget dept. … • Courses have multiple sections that have time/rm and exactly one teacher • Must track students’ course schedules and transcripts including grades. buildings.Courses database: • Courses.

Vs. we could instead combine Manages and Departments. budget REAL. since DATE. relationship to a did ssn INTEGER. since DATE. FOREIGN KEY (ssn) REFERENCES Employees) Review: Key Constraints most one • Each dept has at manager. since name dname ssn lot did budget Employees Manages Departments Translation to relational model? 1-to-1 1-to Many Many-to-1 Many-to-Many Review: Participation Constraints • Does every department have a manager? – If so. : DATE. budget REAL. CREATE TABLE Dept_Mgr( did INTEGER. 123-22-3666 51 1/1/91 123-22-3666 231-31-5368 56 51 3/3/93 2/2/92 Translating ER with Key Constraints n lot Employees name ss since Manages did bu Depar tments dname dget • Since each department has a unique manager. pname lot age ssn name Policy Employees Dependents . ssn CHAR(11). did). PRIMARY KEY (did). PRIMARY KEY (did). ON DELETE NO ACTION) Review: Weak Entities • A weak entity can be identifed uniquely only by considering the primary key of another (owner) entity. according to the key constraint on Manage s. but little else (without resorting to CHECK constraints which we’ll learn later). ssn did since 2) All descriptive attributes. attributes of the relation must since include PRIMARY KEY (ssn. PRIMARY KEY (did). – Owner entity set and weak entity set must participate in a one-to-many relationship set (1 owner. ssn CHAR(11). – Weak entity set must have total participation in this cost identifying relationship set. since DATE. relation. this is a participation constraint: the participation of Departments in Manages is said to be total (vs. FOREIGN KEY (did) REFERENCES Departments) did INTEGER. dname CHAR(20). FOREIGN KEY (ssn) REFERENCES Employees. 1) Keys for each participating FOREIGN KEY (ssn) entity set (as foreign REFERENCES Employees. partial).Relationship Sets to Tables CREATE TABLE Works_In( • In translatingset a many-to-many CHAR(1). keys). many weak entities). This set of attributesFOREIGN KEY (did) forms a superkey for REFERENCES Departments) the relation. FOREIGN KEY (ssn) REFERENCES Employees. • Every did value in Departments table must appear in a row of the Manages table (with a non-null namessn value!) dname Manages Em ployees Departments Works_In since Participation Constraints in SQL • We can capture participation constraints involving one entity set in a binary relationship. ssn CHAR(11) NOT NULL.

functional dependencies) cannot be expressed. – Functional Dependency information and normalization techniques are especially useful. whether or not to use ISA hierarchies. ON DELETE CASCADE) Summary of ER (Cont. especially for a large enterprise. Common choices include: – Entity vs. age INTEGER.) • Several kinds of integrity constraints: – key constraints – participation constraints • Some foreign key constraints are also implicit in the definition of a relationship set. attribute.Translating Weak Entity Sets • Weak entity set and identifying relationship set are translated into a single table. ISA hierarchies (see text if you’re curious). and attributes (of entities and relationships). • Ensuring good database design: resulting relational schema should be analyzed and refned further. CREATE TABLE Dep_Policy ( pname CHAR(20). – When the owner entity is deleted. aggregation.) • ER design is subjective.ary relationship. • Constraints play an important role in determining the best database design for an enterprise. close to the way people think about their applications. binary or n. • Some additional constructs: weak entities. relationship. and aggregation. • Many other constraints (notably. There are often many ways to model a given scenario! • Analyzing alternatives can be tricky. ssn). . – Note: There are many variations on ER model • Both graphically and conceptually • Basic constructs: entities. relationships. ssn CHAR(11) NOT NULL. Summary of Conceptual Design • Conceptual design follows requirements analysis. – Yields a high-level description of data to be stored • ER model popular for conceptual design – Constructs are expressive. all owned weak entities must also be deleted. entity vs. Summary of ER (Cont. PRIMARY KEY (pname. FOREIGN KEY (ssn) REFERENCES Employees. cost REAL.