Introduction to Data Management. Lecture #7 (Relational Design Theory)

Transcription

1 Introduction to Data Management Lecture #7 (Relational Design Theory) Instructor: Mike Carey Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Announcements v HW#2 is underway...! (From HW #1 solution) Use your best judgement on data types and NULLs Capture all the capturable ICs (PK/FK/UNIQUE) v A few logistical notes (waiting list, office hours) Send me an if you need a quiz make-up plan 420 ( 330) Hybrid F2F/online (Piazza) class (K) v Today s plan: Super-quick E-R wrap-up (from last time) Relational DB design theory (I) Disclaimer: Not the most exciting part of CS122A J Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 2

2 Reminder: Putting the Basics Together (from E-Rà Relational) cid cname login oid shipto total Customer 1 Placed N Order 1 sku pname color listprice N Has N LineItem lno price Product 1 For qty Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 3 Reminder: Putting It Together (Cont d.) CREATE TABLE Customer ( cid INTEGER, cname VARCHAR(50), login VARCHAR(20) NOT NULL, PRIMARY KEY (cid), UNIQUE (login)) CREATE TABLE Product ( sku INTEGER, pname VARCHAR(100), color VARCHAR(20), listprice DECIMAL(8,2), PRIMARY KEY (sku)) CREATE TABLE Order ( oid INTEGER, custid INTEGER, shipto VARCHAR(200), total DECIMAL(8,2), PRIMARY KEY (oid), FOREIGN KEY (custid) REFERENCES Customer)) CREATE TABLE LineItem ( oid INTEGER, lno INTEGER, price DECIMAL(8,2), qty INTEGER, sku INTEGER, PRIMARY KEY (oid, lno), FOREIGN KEY (oid) REFERENCES Order ON DELETE CASCADE), FOREIGN KEY (sku) REFERENCES Product)) Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 4

3 Reminder: Putting It Together (Cont d.) Customer cid cname login 1 Smith, James jsmith@aol.com 2 White, Susan suzie@gmail.com 3 Smith, James js@hotmail.com Product sku pname color listprice 123 Frozen DVD null Graco Twin Stroller green Moen Kitchen Sink black Order oid custid shipto total LineItem oid lno price qty item 1 3 J. Smith, 1 Main St., USA Mrs. Smith, 3 State St., USA Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 5 Relational Model and E-R Schema Translation: Summary v Relational model: a tabular representation of data. v Simple and intuitive, also widely used. v Integrity constraints can be specified by the DBA based on application semantics. DBMS then checks for violations. Most important ICs: Primary and foreign keys (PKs, FKs). In addition, we always have domain constraints. v Powerful and natural query languages exist (soon!) v Rules to translate E-R to relational model Can be done by a human, or automatically (using a tool) Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 6

4 Relational Database Design v Two aspects to the RDB design problem: Logical schema design: We just saw one approach, namely, doing E-R modeling followed by an E-R à relational schema translation step Physical schema design: Later, once we learn about indexes, when should we utilize them? v We will look at both problem aspects this term, starting first with relational schema design Our power tools will be functional dependencies (FDs) and normalization theory Note: FDs also play an important role in other contexts as well, e.g., SQL query optimization Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 7 So, Given a Relational Schema... v How do I know if my relational schema is a good logical database design or not? What might make it not good? How can I fix it, if indeed it s not good? How good is it, after I ve fixed it? v Note that your relational schema might have come from one of several places You started from an E-R model (but maybe that model was wrong or incomplete in some way?) You went straight to relational in the first place It s not your schema you inherited it! J Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 8

5 Ex: Wisconsin Sailing Club Proposed schema design #1: sid sname rating age date bid bname color 22 Dustin /10/ Interlake blue 22 Dustin /10/ Interlake red 22 Dustin /8/ Clipper green 22 Dustin /7/ Marine red 31 Lubber /10/ Interlake red 31 Lubber /6/ Clipper green 31 Lubber /12/ Marine red Q: Do you think this is a good design? (Why or why not?) Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 9 Ex: Wisconsin Sailing Club Proposed schema design #2: sid sname rating age 22 Dustin Lubber Q: What about this design? Is #2 better than #1...? Explain! Is it a best design? How can we go from design #1 to this one? si d bid date /10/ /10/ /8/ /7/ /10/ /6/ /12/ bid bname color 101 Interlake blue 102 Interlake red 103 Clipper green 104 Marine red Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 10

6 Ex: Wisconsin Sailing Club Proposed schema design #3: sid sname rating age 22 Dustin Lubber Q: What about this design? Is #3 better or worse than #2...? What sort of tradeoffs do you see between the two? si d bid date /10/ /10/ /8/ /7/ /10/ /6/ /12/ Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 11 bid bname 101 Interlake 102 Interlake 103 Clipper 104 Marine bid color 101 blue 102 red 103 green 104 red The Evils of Redundancy (or: The Evils of Redundancy) v Redundancy is at the root of several problems associated with relational schemas: Redundant storage (space) Good rule to follow: Insert/delete/update anomalies One fact, one place! v Functional dependencies can help in identifying problem schemas and suggesting refinements. v Main refinement technique: decomposition, e.g., replace R(ABCD) with R1(AB) + R2(BCD). v Decomposition should be used judiciously: Is there reason to decompose a relation? Does the decomposition cause any problems? Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 12

7 Functional Dependencies (FDs) v A functional dependency X à Y holds over relation R if, for every allowable instance r of R: For t1 and t2 in r, t1.x = t2.x implies t1.y = t2.y I.e., given two tuples in r, if the X values agree, then their Y values must also agree. (X and Y can be sets of attributes.) v An FD is a statement about all allowable relations. Identified based on application semantics (similar to E-R). Given some instance r1 of R, we can check to see if it violates some FD f, but we cannot tell if f holds over R! v Saying K is a candidate key for R means that Kà R Note: K à R alone does not require K to be minimal! If K is minimal, then K is a candidate key (else it s a super key). Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 13 Example: Constraints on an Entity Set v Suppose you re given a relation called HourlyEmps: HourlyEmps (ssn, name, lot, rating, hrly_wages, hrs_worked) v Notation: Let s denote this relation schema by simply listing the attributes: SNLRWH This is really the set of attributes {S,N,L,R,W,H}. Sometimes, we will refer to all attributes of a relation by using the relation name (e.g., HourlyEmps for SNLRWH). v Suppose we also have some FDs on HourlyEmps: ssn is the key: S à SNLRWH rating determines hrly_wages: R à W Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 14

8 Example (Cont d.) Wages HourlyEmps2 5 7 v Problems due to R à W : S N L R H Update anomaly: What if we change W in just Attishoo the 1st tuple of SNLRWH? Smiley Insertion anomaly: What if Smethurst we want to insert a new employee and don t know Guldu the proper hourly wage for Madayan his or her rating? Deletion anomaly: If we S N L R W H delete all employees with Attishoo rating 5, we lose the stored Smiley information about the Smethurst wage for rating 5! How about two smaller tables? Guldu Madayan Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 15 R W 8 10 Reasoning About FDs v Given some FDs, we can usually infer additional FDs: ssn did, did lot implies ssn lot (Translation: Matching ssns imply matching lots.) v An FD f is implied by a set of FDs F if f holds whenever all FDs in F hold. F + = closure of F is the set of all FDs that are implied by F. v Armstrong s Axioms (X, Y, Z are sets of attributes): Reflexivity: If X Í Y, then Y X Augmentation: If X Y, then XZ YZ for any Z Transitivity: If X Y and Y Z, then X Z v These are sound and complete inference rules for FDs! Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 16

9 Armstrong s Axioms: Examples pno name title state zip 1 Sandy Professor CA Joe Jim Gray Professor CA Anhai Professor WI Alex Associate Professor CA v Reflexivity: If X Í Y then YàX: Í zip (zip, name), so (zip, name) à zip. v Augmentation: If XàY then XZàYZ for any Z: zip à state, so (zip, title) à (state, title). v Transitivity: If XàY and YàZ then XàZ: pno à zip and zip à state, so pno à state. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 17 Reasoning About FDs (Cont d.) (Recall: two matching X s always have the same Y ) v A few additional rules (which follow from AA): Union: If X Y and X Z, then X YZ Decomposition: If X YZ, then X Y and X Z v Example: Contracts(cid,sid,pjid,did,pid,qty,value), and: The contract id is the key: C CSJDPQV A project purchases each part using single contract: JP C A dept purchases at most one part from a supplier: SD P v JP C, C CSJDPQV imply JP CSJDPQV v SD P implies SDJ JP (New candidate keys...!) v SDJ JP, JP CSJDPQV imply SDJ CSJDPQV Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 18