Database Design and the

Database Design and the
Entity/Relationship 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??!!!

Being a DBA Database Design Steps
1. Requirements Specification Determine the requirements of clients 2. Conceptual Design Express client requirements in terms of some high-level model (e.g., E/R model). Confirm with clients that requirements are correct. 3. Functional Requirements Specify required data operations priorities, response times 4. Logical Design Convert E/R model to relational, object-based, XML-based,… 5. Physical Design Specify file organizations, build indexes

Conceptual Design The E/R Data Model
What is a Data Model? Framework for organizing and interpreting data Example: E/R Data Model Relationship Entity1 Entity2 Attribute2a Attribute2b Attribute1a Attribute1b Attribute2c

E/R Data Model Basics Entities Relationships
noun phrases (e.g., Bob Smith, Thayer St. Branch) contained in entity sets (e.g. Employee, Branch) have attributes (e.g., Employee = (essn, ename, …)) Relationships verb phrases (e.g., works_at, works_for) relate 2 (binary) or more (n-ary) entities relationship sets characterize relationships amongst entity sets e.g., (Bob Smith, Thayer St Branch) Î Works_At

E/R Data Model An Example
Works_At Employee Branch essn phone bname bcity since seniority ename children Entity Set Relationship Set Attribute Employee Works_At phone Works_For manager worker Lots of notation to come. Color is irrelevant

E/R Data Model Types of Attributes
Works_At Employee Branch essn phone bname since seniority bcity ename children Works_For manager worker ename Default children Multivalued Derived seniority

E/R Data Model Types of relationships
Works_At Employee Branch essn phone bname since seniority bcity ename children Works_For manager worker Works_For Many-to-One (n:1) Works_At Many-to-Many (n:m)

E/R Data Model Recursive relationships
Works_At Employee Branch essn phone bname since seniority bcity ename children Works_For Recursive relationships: Must be declared with roles manager worker manager Employee Works_For worker

E/R Data Model Design Issue #1: Entity Sets vs. Attributes
Employee Uses Employee Phone vs phone_no phone_loc no loc 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)

E/R Data Model Design Issue #2: Entity Sets vs. Relationship Sets
An Example: How to model bank loans Loans Borrows Customer Branch Customer Loan vs cssn cname bname bcity cssn cname lno amt (a) lno amt (b) 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)

E/R Data Model Design Issue #3: Relationship Cardinalities
An Example: Borrows ? ? Customer Loan Variations on Borrows: 1. Can a customer hold multiple loans? 2. Can a loan be jointly held by more than 1 customer?

E/R Data Model Design Issue #3: Relationship Cardinalities
Borrows ? ? Customer Loan Cardinalities of Borrows: Borrows Borrows Borrows Borrows

E/R Data Model Design Issue #3: Relationship Cardinalities (cont)
In general... 1:1 n:1 1:n n:m

E/R Data Model Design Issue #4: N-ary vs Binary Relationship Sets
An Example: Works_At Ternary: Works_at Employee Branch Choose n-ary when possible! Dept (Joe, Thayer, Acct) Î Works_At vs Binary: WAE WAB Employee WA Branch WAD (Joe, w3) Î WAE (Thayer, w3) Î WAB (Acct, w3) Î WAD Dept

E/R Data Model Keys A. Superkey: B. Candidate Key: C. Primary Key:
Key = set of attributes identifying individual entities or relationships Employee essn ename eaddress ephone A. Superkey: any attribute set that distinguishes identities e.g., {essn}, {essn, ename, eaddress} B. Candidate Key: “minimal superkey” (can’t remove attributes and preserve “keyness”) e.g., {essn}, {ename, eaddress} C. Primary Key: candidate key chosen as the key by a DBA e.g., {essn} (denoted by underline)

E/R Data Model Relationship Set Keys
Works_At Employee Branch ... ... essn ename bname bcity since Q: What attributes are needed to represent relationships in Works_At? e1 b1 e2 b2 e3 A: {essn, bname, since}

E/R Data Model Relationship Set Keys (cont.)
Works_At Employee Branch ... ... essn ename bname bcity since Q: What are the candidate keys of Works_At? e1 b1 e2 b2 e3 A: {essn}

? Works_At ? Employee Branch ... ... essn ename bname bcity since Q: What are the candidate keys if Works_At is...? a. 1:n A: {bname} b. n:m A: {essn, bname} c. 1:1 A: {essn} or {bname}

General Rules for Relationship Set Keys R E1 E2 ... ... P (E1) P (E2) If R is: R 1:1 1:n n:1 n:m Candidate Keys P (E1) or P (E2) P (E2) P (E1) P (E1) È P (E2)

E/R Data Model Existence Dependencies and Weak Entity Sets
Idea: Existence of one entity depends on another Example: Loans and Loan Payments Loan_Pmt Payment Loan lno lamt pno pdate pamt Weak Entity Set Identifying Relationship Total Participation

Loan_Pmt Payment Loan lno lamt pno pdate pamt Weak Entity Sets existence of payments depends upon loans have no superkeys: different payment records (for different loans) can be identical instead of keys, discriminators: discriminate between payments for given loan (e.g., pno)

Loan_Pmt Payment Loan lno lamt pno pdate pamt Identifying Relationships We say: Loan is dominant in Loan_Pmt Payment is subordinate in Loan_Pmt Payment is existence dependent on Loan

Loan_Pmt Loan Payment lno lamt pno pdate pamt All elements of Payment appear in Loan_Pmt

... atta1 attam attb1 ... attbn Q. Is {attb1, …, attbn} a superkey of E2? A: No Q. Name a candidate key of E2 A: {atta1, attb1} Q. Does total participation of E2 in R Þ E2 is existence-dep? A: No

E/R Data Model Extensions to the Model: Specialization and Generalization
An Example: Customers can have checking and savings accts Checking ~ Savings (many of the same attributes) Old Way: Has1 Customer Savings Acct acct_no balance interest Has2 Checking Acct acct_no balance overdraft

An Example: Customers can have checking and savings accts Checking ~ Savings (many of the same attributes) Alternative Way: acct_no balance Has superclass Customer Account Isa Savings Acct Checking Acct interest overdraft subclasses

Subclass Distinctions: 1. User-Defined vs. Condition-Defined User: Membership in subclasses explicitly determined (e.g., Employee, Manager < Person) Condition: Membership predicate associated with subclasses - e.g: Person Isa Child Adult Senior age < 18 age > 65 18  age

Subclass Distinctions: 2. Overlapping vs. Disjoint Overlapping: Entities can belong to >1 entity set (e.g., Adult, Senior) Disjoint: Entities belong to exactly 1 entity set (e.g., Child) Person Isa Child Adult Senior age < 18 age > 65 18  age

E/R Data Model Summary Entities, Relationships (sets)
Both can have attributes (simple, multivalued, derived, composite) Cardinality or relationship sets (1:1, n:1, n:m) Keys: superkeys, candidate keys, primary key DBA chooses primary key for entity sets Automatically determined for relationship sets Weak Entity Sets, Existence Dependence, Total/Partial Participation Specialization (E/R + inheritance)

E/R Diagrams and Relations
Relational Schema Entity Sets E = (a1, …, an) E a1 an …

Relational Schema Entity Sets E = (a1, …, an) Relationship Sets R = (a1, b1, c1, …, ck) a1: E1’s key b1: E2’s key c1, …, ck: attributes of R E a1 an … E2 bm E1 a1 an ck R … b1 c1 Not the whole story for Relationship Sets …

bm E1 a1 an ck R … b1 c1 What about… Could have: R = (a1, b1, c1, …, ck) but… a1 is a key for R a1 also a key for E1 = (a1, …, an) Rule of Thumb Fewer tables good, as long as no redundancy Instead: Ignore R Add b1, c1, …, ck to E1 instead (i.e: E1 = (a1, …, an,, b1, c1, …, ck))

Relationship Cardinality Relational Schema n:m E1 = (a1, …, an) E2 = (b1, …, bm) R = (a1, b1, c1, …, cn) E2 bm E1 a1 an ck R … b1 c1 ? R

Relationship Cardinality Relational Schema n:m E1 = (a1, …, an) E2 = (b1, …, bm) R = (a1, b1, c1, …, cn) n:1 E1 = (a1, …, an, b1, c1, …, cn) E2 bm E1 a1 an ck R … b1 c1 ? R R

Relationship Cardinality Relational Schema n:m E1 = (a1, …, an) E2 = (b1, …, bm) R = (a1, b1, c1, …, cn) n:1 E1 = (a1, …, an, b1, c1, …, cn) 1:n E1 = (a1, …, an) E2 = (b1, …, bm,, a1, c1, …, cn) E2 bm E1 a1 an ck R … b1 c1 ? R R R

Relationship Cardinality Relational Schema n:m E1 = (a1, …, an) E2 = (b1, …, bm) R = (a1, b1, c1, …, cn) n:1 E1 = (a1, …, an, b1, c1, …, cn) 1:n E1 = (a1, …, an) E2 = (b1, …, bm,, a1, c1, …, cn) 1:1 Treat as n:1 or 1:n E2 bm E1 a1 an ck R … b1 c1 ? R R R R

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

Translating E/R Diagrams to Relations
balance bname bcity assets acct_no Acct-Branch Account Branch Depositor Loan-Branch Borrower Customer Loan cname ccity cstreet lno amt Q. What are the schemas?

Bank Database Account bname acct_no balance Branch bname bcity assets
Depositor cname acct_no Borrower cname lno Customer cname cstreet ccity Loan bname lno amt

Bank Database Account bname acct_no balance Branch bname bcity assets
Downtown Mianus Perry R.H. Brighton Redwood A-101 A-215 A-102 A-305 A-201 A-222 A-217 500 700 400 350 900 750 Branch bname bcity assets Downtown Redwood Perry Mianus R.H. Pownel N. Town Brighton Brooklyn Palo Alto Horseneck Bennington Rye 9M 2.1M 1.7M 0.4M 8M 0.3M 3.7M 7.1M Depositor cname acct_no Johnson Smith Hayes Turner Jones Lindsay A-101 A-215 A-102 A-305 A-201 A-217 A-222 Borrower cname lno Jones Smith Hayes Jackson Curry Williams Adams L-17 L-23 L-15 L-14 L-93 L-11 L-16 Customer cname cstreet ccity Jones Smith Hayes Curry Lindsay Turner Williams Adams Johnson Glenn Brooks Green Main North Park Putnam Nassau Spring Alma Sand Hill Senator Walnut Harrison Rye Pittsfield Stanford Princeton Palo Alto Woodside Brooklyn Loan bname lno amt Downtown Redwood Perry Mianus R.H. L-17 L-23 L-15 L-14 L-93 L-11 L-16 1000 2000 1500 500 900 1300

E/R Diagrams & Relations
Relational Schema Weak Entity Sets E1 = (a1, …, an) E2 = (a1, b1, …, bm) E1 a1 an E2 b1 … bm IR

Relational Schema Multivalued Attributes Emp = (ssn, name) Emp-Depts = (ssn, dept) Emp ssn name dept ssn name 001 … Smith ssn dept 001 … Acct Sales Emp Emp-Depts

Relational Schema Subclasses Method 1: E = (a1, …, an) E1 = (a1, b1, …, bm) E2 = (a1, c1, …, ck) E a1 an E2 c1 b1 Isa E1 … bm ck

E/Rb Relational Schema Subclasses Method 1: E = (a1, …, an) E1 = (a1, b1, …, bm) E2 = (a1, c1, …, ck) Method 2: E1 = (a1, …, an, b1, …, bm) E2 = (a1, …, an, c1, …, ck) E a1 an E2 c1 b1 Isa E1 … bm ck

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

Subclass Distinctions: 3. Total vs. Partial Membership Total: Every entity of superclass belongs to a subclass e.g., Partial: Some entities of superclass do not belong to any subclass (e.g., Suppose Adult condition is age ³ 21 ) Person Isa Child Adult Senior age < 18 age³ 18 age³ 65

E/R Data Model Extensions to the Model: Aggregation
E/R: No relationships between relationships E.g.: Associate loan officers with Borrows relationship set Borrows Customer Loan ? Loan_Officer Employee Associate Loan Officer with Loan? What if we want a loan officer for every (customer, loan) pair?

Database Design and the

Similar presentations

Presentation on theme: "Database Design and the"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Database Design and the

Similar presentations

Presentation on theme: "Database Design and the"— Presentation transcript:

Similar presentations

About project

Feedback