Review of the Entity-Relationship Model Slides courtesy of Amol Deshpande material from ch. 2 of Korth & Silberschatz Database System Concepts,

Data Modeling Goals: Conceptual representation of the data “Reality” meets “bits and bytes” Must make sense, and be usable by other people Review: Entity-relationship Model Relational Model

Motivation You’ve just been hired by Bank of America as their DBA for their online banking web site. You are asked to create a database that monitors: customers accounts loans branches transactions, … Now what??!!!

Database Design Steps Three Levels of Modeling info Conceptual Data Model Logical Data Model Physical Data Model Conceptual DB design Logical DB design Physical DB design Entity-relationship Model Typically used for conceptual database design Relational Model Typically used for logical database design

Entity-Relationship Model Two key concepts Entities: An object that exists and is distinguishable from other objects –Examples: Bob Smith, BofA, CMSC424 Have attributes (people have names and addresses) Form entity sets with other entities of the same type that share the same properties –Set of all people, set of all classes Entity sets may overlap –Customers and Employees

Entity-Relationship Model Two key concepts Relationships: Relate 2 or more entities –E.g. Bob Smith has account at College Park Branch Form relationship sets with other relationships of the same type that share the same properties –Customers have accounts at Branches Can have attributes: –has account at may have an attribute start-date Can involve more than 2 entities –Employee works at Branch at Job

ER Diagram: Starting Example Rectangles: entity sets Diamonds: relationship sets Ellipses: attributes customer has cust-street cust-id cust-name cust-city account balance number access-date

Review Roadmap Details of the ER Model How to represent various types of constraints/semantic information etc. Design issues A detailed example

Relationship Cardinalities We may know: One customer can only open one account OR One customer can open multiple accounts Representing this is important Why ? Better manipulation of data Can enforce such a constraint Remember: If not represented in conceptual model, the domain knowledge may be lost

Mapping Cardinalities Express the number of entities to which another entity can be associated via a relationship set Most useful in describing binary relationship sets

Mapping Cardinalities One-to-One One-to-Many Many-to-One Many-to-Many customer has account customer has account customer has account customer has account

Types of Attributes Simple vs Composite Single value per attribute ? Single-valued vs Multi-valued E.g. Phone numbers are multi-valued Derived If date-of-birth is present, age can be derived Can help in avoiding redundancy, enforcing constraints etc…

Types of Attributes customer has cust-street cust-id cust-name cust-city account balance number access-date

Types of Attributes customer cust-street cust-id cust-name cust-city has account balance number access-date phone no. date-of-birth age multi-valued (double ellipse) derived (dashed ellipse)

Types of Attributes customer cust-street cust-id cust-name cust-city has account balance number access-date phone no. date-of-birth age month dayyear Composite Attribute

Next: Keys Key = set of attributes identifying individual entities or relationships

customer cust-street cust-id cust-name cust-city phone no. age date-of-birth Possible Keys: {cust-id} {cust-name, cust-city, cust-street} {cust-id, age} cust-name ?? Probably not. Domain knowledge dependent !! Entity Keys

Superkey any attribute set that can distinguish entities Candidate key a minimal superkey Can’t remove any attribute and preserve key-ness –{cust-id, age} not a superkey –{cust-name, cust-city, cust-street} is »assuming cust-name is not unique Primary key Candidate key chosen as the key by DBA Underlined in the ER Diagram

Entity Keys {cust-id} is a natural primary key Typically, SSN forms a good primary key Try to use a candidate key that rarely changes e.g. something involving address not a great idea customer cust-street cust-id cust-name cust-city phone no. age date-of-birth

Relationship Set Keys What attributes are needed to represent a relationship completely and uniquely ? Union of primary keys of the entities involved, and relationship attributes {cust-id, access-date, account number} describes a relationship completely customer has cust-id account number access-date

Relationship Set Keys Is {cust-id, access-date, account number} a candidate key ? No. Attribute access-date can be removed from this set without losing key-ness customer has cust-id account number access-date

Relationship Set Keys Is {cust-id, account-number} a candidate key ? Depends customer has cust-id account number access-date

Relationship Set Keys Is {cust-id, account-number} a candidate key ? Depends customer has cust-id account number access-date If one-to-one relationship, either {cust-id} or {account-number} sufficient Since a given customer can only have one account, she can only participate in one relationship Ditto account

Relationship Set Keys Is {cust-id, account-number} a candidate key ? Depends customer has cust-id account number access-date If one-to-many relationship (as shown), {account-number} is a candidate key A given customer can have many accounts, but at most one account holder per account allowed

Relationship Set Keys General rule for binary relationships one-to-one: primary key of either entity set one-to-many: primary key of the entity set on the many side many-to-many: union of primary keys of the associate entity sets n-ary relationships More complicated rules

Data Constraints Representing semantic data constraints We already saw constraints on relationship cardinalities

Participation Constraint Given an entity set E, and a relationship R it participates in: If every entity in E participates in at least one relationship in R, it is total participation partial otherwise

Participation Constraint customer has cust-street cust-id cust-name cust-city account balance number access-date Total participation

Cardinality Constraints customer has cust-id account number access-date 0..*1..1 How many relationships can an entity participate in ? Minimum - 0 Maximum – no limit Minimum - 1 Maximum - 1

Recursive Relationships Sometimes a relationship associates an entity set to itself

Recursive Relationships Must be declared with roles employee works-for emp-street emp-id emp-name emp-city manager worker

Weak Entity Sets An entity set without enough attributes to have a primary key E.g. Transaction Entity Attributes: transaction-number, transaction-date, transaction-amount, transaction-type transaction-number: may not be unique across accounts

Weak Entity Sets A weak entity set must be associated with an identifying or owner entity set Account is the owner entity set for Transaction

Weak Entity Sets account balance number Transaction has trans-type trans-number trans-date trans-amt Still need to be able to distinguish between different weak entities associated with the same strong entity

Weak Entity Sets account balance number Transaction has trans-type trans-number trans-date trans-amt Discriminator: A set of attributes that can be used for that

Weak Entity Sets Primary key: Primary key of the associated strong entity + discriminator attribute set For Transaction: {account-number, transaction-number}

Specialization Consider entity person: Attributes: name, street, city Further classification: customer Additional attributes: customer-id, credit-rating employee Additional attributes: employee-id, salary Note similarities to object-oriented programming

Specialization: Example

Aggregation No relationships between relationships E.g.: Associate account officers with has account relationship set customer has account account officer employee ?

Aggregation Associate an account officer with each account ? What if different customers for the same account can have different account officers ? customer has account account officer employee ?

Aggregation Solution: Aggregation customer has account account officer employee

More… Read Chapter 2 for: Specialization/Aggregation details Different types of specialization’s etc Generalization: opposite of specialization Lower- and higher-level entities Attribute inheritance …

An Example: Employees can have multiple phones E/R Data Model Design Issue #1: Entity Sets vs. Attributes Employee Phone Uses vs (a) (b) To resolve, determine how phones are used 1. Can many employees share a phone? (If yes, then (b)) 2. Can employees have multiple phones? (if yes, then (b), or (a) with multivalued attributes) 3. Else (a), perhaps with composite attributes phone_no phone_loc no loc Employee no loc phone

An Example: How to model bank loans E/R Data Model Design Issue #2: Entity Sets vs. Relationship Sets vs (a) To resolve, determine how loans are issued 1. Can there be more than one customer per loan? If yes, then (a). Otherwise, loan info must be replicated for each customer (wasteful, potential update anomalies) 2. Is loan a noun or a verb? Both, but more of a noun to a bank. (hence (a) probably more appropriate) Customer (b) Loans Branch Customer Loan Borrows lno amt ssn name ssn name lno amt bname bcity

An Example: Works_At E/R Data Model Design Issue #3: N-ary vs Binary Relationship Sets Employee Works_at Branch Dept Employee WA E Branch Dept WA Binary: Ternary: WA B WA D vs (Joe, Moody, Acct)  Works_At (Joe, w 3 )  WA E (Moody, w 3 )  WA B (Acct, w 3 )  WA D Choose n-ary when possible! (Avoids redundancy, update anomalies)

Example Design We will model a university database Main entities: Professor Projects Departments Graduate students etc…

professor area name SSN rank project start sponsor proj-number budget dept office name dept-no homepage grad age name SSN degree

professor area name SSN rank project start sponsor proj-number budget dept office name dept-no homepage grad age name SSN degree

professor area name SSN rank project start sponsor proj-number budget dept office name dept-no homepage grad age name SSN degree PI Co-PI RA Major Chair Supervises Mentor advisee advisor Appt Time (%)

professor area name SSN rank project start sponsor proj-number budget dept office name dept-no homepage grad age name SSN degree PI Co-PI RA Major Chair Appt Supervises Mentor advisee advisor Time (%)

professor area name SSN rank project start sponsor proj-number budget dept office name dept-no homepage grad age name SSN degree PI Co-PI RA Major Chair Appt Supervises Mentor advisee advisor Time (%) And so on…

Summary Entity-relationship Model Intuitive diagram-based representation of domain knowledge, data properties etc… Two key concepts: Entities Relationships Additional Details: Relationship cardinalities Keys Participation Constraints …

Database Design Steps Three Levels of Modeling info Conceptual Data Model Logical Data Model Physical Data Model Conceptual DB design Logical DB design Physical DB design Entity-relationship Model Typically used for conceptual database design Relational Model Typically used for logical database design

Review: Entity-Relationship Model Basics E1E1 Entity set R Relationship set Attribute (primary key if underlined) E1E1 … … … R E2E2 a1a1 anan c1c1 ckck b1b1 bmbm a

Thoughts… Nothing about actual data How is it stored ? No talk about the query languages How do we access the data ? Semantic vs Syntactic Data Models Remember: E/R Model is used for conceptual modeling Many conceptual models have the same properties They are much more about representing the knowledge than about database storage/querying

Thoughts… Basic design principles Faithful Must make sense Satisfies the application requirements Models the requisite domain knowledge If not modeled, lost afterwards Avoid redundancy Potential for inconsistencies Go for simplicity Typically an iterative process that goes back and forth

Relational Data Model Before = “Network Data Model” (Cobol as DDL, DML) Very contentious: Database Wars (Charlie Bachman vs. Mike Stonebraker) Introduced by Ted Codd (late 60’s – early 70’s) 1.Separation of logical, physical data models (data independence) 2.Declarative query languages 3.Formal semantics 4.Query optimization (key to commercial success) Relational data model contributes:

Key Abstraction: Relation bnameacct_nobalance Downtown Brighton A-101 A-201 A Account = Terms: Tables (aka: Relations) Why called Relations?

Why Called Relations? Given sets: R = {1, 2, 3}, S = {3, 4} R  S = { (1, 3), (1, 4), (2, 3), (2, 4), (3, 3), (3, 4) } A relation on R, S is any subset (  ) of R  S (e.g: { (1, 4), (3, 4)}) Mathematical relations Account  Branches  Accounts  Balances { (Downtown, A-101,500), (Brighton, A-201, 900), (Brighton, A-217, 500) } Database relations Given attribute domains Branches = { Downtown, Brighton, … } Accounts = { A-101, A-201, A-217, … } Balances = R

Relations bnameacct_nobalance Downtown Brighton A-101 A-201 A Account = Relational database semantics defined in terms of mathematical relations { (Downtown, A-101, 500), (Brighton, A-201, 900), (Brighton, A-217, 500) } Considered equivalent to…

Relations bnameacct_nobalance Downtown Brighton A-101 A-201 A Rows (aka: tuples) Account = Terms: Columns (aka: attributes) { (Downtown, A-101, 500), (Brighton, A-201, 900), (Brighton, A-217, 500) } Considered equivalent to… Tables (aka: Relations) Schema (e.g.: Acct_Schema = (bname, acct_no, balance))

Definitions 1.Relation Schema (or Schema) A list of attributes and their domains We will require the domains to be atomic E.g. account(account-number, branch-name, balance) Relation Instance A particular instantiation of a relation with actual values Will change with time bnameacct_nobalance Downtown Brighton A-101 A-201 A Programming language equivalent: A variable (e.g. x) Programming language equivalent: Value of a variable

Rest of the Class Converting from an E/R diagram to a relational schema –Remember: We still use E/R models for conceptual modeling of the database Relational Algebra –Data retrieval language

E/R Diagrams  Relations Convert entity sets into a relational schema with the same set of attributes Customer cname ccity cstreet Customer_Schema(cname, ccity, cstreet) Branch bname bcity assets Branch_Schema(bname, bcity, assets)

E/R Diagrams  Relations Convert relationship sets also into a relational schema Remember: A relationship is completely described by primary keys of associate entities and its own attributes Depositor_Schema(cname, acct-no, access-date) Account Customer Depositor acct-no balance cname ccity cstreet access-date Well… Not quite. We can do better. It depends on the relationship cardinality Customer_Schema(cname, ccity, cstreet) Account_Schema(acct-no, balance)

E/R Diagrams  Relations Say One-to-Many Relationship from Customer to Account  Many accounts per customer Account Customer Depositor acct-no balance cname ccity cstreet access-date Customer_Schema(cname, ccity, cstreet) Account_Schema(acct-no, balance, cname, access-date) Exactly same information, fewer tables

E/R Diagrams  Relations E/RRelational Schema Entity Sets E = (a 1, …, a n ) E1E1 … a1a1 anan

E/R Diagrams  Relations E/RRelational Schema Entity Sets E = (a 1, …, a n ) Relationship Sets R = (a 1, b 1, c 1, …, c n ) a 1 : E 1 ’s key b 1 : E 2 ’s key c 1, …, c k : attributes of R Not the whole story for Relationship Sets … E1E1 … a1a1 anan E1E1 … … … R E2E2 a1a1 anan c1c1 ckck b1b1 bmbm

E/R Diagrams  Relations Relationship CardinalityRelational Schema n:m E 1 = (a 1, …, a n ) E 2 = (b 1, …, b m ) R = (a 1, b 1, c 1, …, c n ) R E1E1 … … … R E2E2 a1a1 anan c1c1 ckck b1b1 bmbm

E/R Diagrams  Relations Relationship CardinalityRelational Schema n:m E 1 = (a 1, …, a n ) E 2 = (b 1, …, b m ) R = (a 1, b 1, c 1, …, c n ) n:1E 1 = (a 1, …, a n, b 1, c 1, …, c n ) E 2 = (b 1, …, b m ) R R E1E1 … … … R E2E2 a1a1 anan c1c1 ckck b1b1 bmbm

E/R Diagrams  Relations Relationship CardinalityRelational Schema n:m E 1 = (a 1, …, a n ) E 2 = (b 1, …, b m ) R = (a 1, b 1, c 1, …, c n ) n:1E 1 = (a 1, …, a n, b 1, c 1, …, c n ) E 2 = (b 1, …, b m ) 1:nE 1 = (a 1, …, a n ) E 2 = (b 1, …, b m,, a 1, c 1, …, c n ) R R R E1E1 … … … R E2E2 a1a1 anan c1c1 ckck b1b1 bmbm

E/R Diagrams  Relations Relationship CardinalityRelational Schema n:m E 1 = (a 1, …, a n ) E 2 = (b 1, …, b m ) R = (a 1, b 1, c 1, …, c n ) n:1E 1 = (a 1, …, a n, b 1, c 1, …, c n ) E 2 = (b 1, …, b m ) 1:nE 1 = (a 1, …, a n ) E 2 = (b 1, …, b m,, a 1, c 1, …, c n ) 1:1 Treat as n:1 or 1:n R R R R E1E1 … … … R E2E2 a1a1 anan c1c1 ckck b1b1 bmbm

Translating E/R Diagrams to Relations Acct-Branch AccountBranch Borrower CustomerLoan Depositor Loan-Branch Q. How many tables does this get translated into? A. 6 (account, branch, customer, loan, depositor, borrower) acct_no balance bname bcity assets cname ccity cstreet lno amt

Bank Database Account bnameacct_nobalance Depositor cnameacct_no Customer cnamecstreetccity Branch bnamebcityassets Borrower cnamelno Loan bnamelnoamt

Bank Database Account bnameacct_nobalance Downtown Mianus Perry R.H. Brighton Redwood Brighton A-101 A-215 A-102 A-305 A-201 A-222 A Depositor cnameacct_no Johnson Smith Hayes Turner Johnson Jones Lindsay A-101 A-215 A-102 A-305 A-201 A-217 A-222 Customer cnamecstreetccity Jones Smith Hayes Curry Lindsay Turner Williams Adams Johnson Glenn Brooks Green Main North Main North Park Putnam Nassau Spring Alma Sand Hill Senator Walnut Harrison Rye Harrison Rye Pittsfield Stanford Princeton Pittsfield Palo Alto Woodside Brooklyn Stanford Branch bnamebcityassets Downtown Redwood Perry Mianus R.H. Pownel N. Town Brighton Brooklyn Palo Alto Horseneck Bennington Rye Brooklyn 9M 2.1M 1.7M 0.4M 8M 0.3M 3.7M 7.1M Borrower cnamelno Jones Smith Hayes Jackson Curry Smith Williams Adams L-17 L-23 L-15 L-14 L-93 L-11 L-17 L-16 Loan bnamelnoamt Downtown Redwood Perry Downtown Mianus R.H. Perry L-17 L-23 L-15 L-14 L-93 L-11 L

E/R Diagrams & Relations E/RRelational Schema Weak Entity Sets E 1 = (a 1, …, a n ) E 2 = (a 1, b 1, …, b m ) E1E1 … … IR E2E2 a1a1 anan b1b1 bmbm

E/R Diagrams & Relations E/RRelational Schema Multivalued Attributes Emp = (ssn, name) Emp-Phones = (ssn, phone) Emp ssnname 001 … Smith … Emp-Phones ssnphone 001 … … Employee ssn name phone

E/R Diagrams & Relations E/RRelational Schema Subclasses Method 1: E = (a 1, …, a n ) E 1 = (a 1, b 1, …, b m ) E 2 = (a 1, c 1, …, c k ) E E2E2 ISA E1E1 … … b1b1 bmbm c1c1 ckck … a1a1 anan

E/R Diagrams & Relations E/RRelational Schema Subclasses Method 1: E = (a 1, …, a n ) E 1 = (a 1, b 1, …, b m ) E 2 = (a 1, c 1, …, c k ) Method 2: E 1 = (a 1, …, a n, b 1, …, b m ) E 2 = (a 1, …, a n, c 1, …, c k ) E E2E2 ISA E1E1 … … b1b1 bmbm c1c1 ckck … a1a1 anan

E/R Diagrams & Relations Subclasses example: Method 1: Account = (acct_no, balance) SAccount = (acct_no, interest) CAccount = (acct_no, overdraft) Method 2: SAccount = (acct_no, balance, interest) CAccount = (acct_no, balance, overdraft) Q: When is method 2 not possible? A: When subclassing is partial

Keys and Relations 1. Superkeys set of attributes of table for which every row has distinct set of values 2. Candidate keys “minimal” superkeys 3. Primary keys DBA-chosen candidate keys As in the E/R Model: Act as Integrity Constraints i.e., guard against illegal/invalid instance of given schema e.g., Branch = (bname, bcity, assets)  bnamebcityassets Brighton Brooklyn Boston 5M 3M Invalid!!