Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Relational Model and Normalization (1) IS 240 – Database Management Lecture #7 – 2004-02-12 Prof. M. E. Kabay, PhD, CISSP Norwich University

Similar presentations


Presentation on theme: "The Relational Model and Normalization (1) IS 240 – Database Management Lecture #7 – 2004-02-12 Prof. M. E. Kabay, PhD, CISSP Norwich University"— Presentation transcript:

1 The Relational Model and Normalization (1) IS 240 – Database Management Lecture #7 – Prof. M. E. Kabay, PhD, CISSP Norwich University

2 2 Copyright © 2004 M. E. Kabay. All rights reserved. Topics Intro to DB Design Relational Model Definitions Functional Dependencies Keys Uniqueness Homework

3 3 Copyright © 2004 M. E. Kabay. All rights reserved. Intro to DB Design: Kroenke Part III, Chapter 5 Need a language for thinking about entity relationships How can they be modeled using general concepts of database tools? Equivalent to developing program design using pseudocode Can translate designs into real code more easily than by working only with compilers or DBMS Normalization helps to sort out information in ways that can easily be handled in DBMS

4 4 Copyright © 2004 M. E. Kabay. All rights reserved. Relational Model: Definitions Different terminologies used by mathematicians, information technologists (IT) and users to describe information relationships Math: relation, attribute, tuple; cell = attribute X tuple IT: file (or dataset), field, record; cell = field X record Users: table, column, row; cell = column X row

5 5 Copyright © 2004 M. E. Kabay. All rights reserved. Definitions (contd) Table Row Column Cell

6 6 Copyright © 2004 M. E. Kabay. All rights reserved. Definitions (contd) Record Field File Cell

7 7 Copyright © 2004 M. E. Kabay. All rights reserved. Definitions (contd) Tuple Attribute Relation Cell

8 8 Copyright © 2004 M. E. Kabay. All rights reserved. Constraints of the Relational Model Each cell contains a single value (no lists, tables, arrays) All instances of an attribute (field, column) must be instances of the same quality; e.g., License number – and not VINS or color Height – and not weight or eye-color Salary – and all yearly or all monthly totals Every attribute (field, column) is uniquely identified (same name in all tuples (records, rows) Every tuple (record, row) is unique Order of attributes and tuples is arbitrary – many designs are functionally equivalent

9 9 Copyright © 2004 M. E. Kabay. All rights reserved. Functional Dependencies Relationship among attributes that Permits one to determine the value of one attribute given the value of another attribute Examples Student_ID allows student to find out the current GPA Part_Number leads to current inventory Clinical_Code allows insurance carrier to determine fee to be paid to doctor

10 10 Copyright © 2004 M. E. Kabay. All rights reserved. Functional Dependencies (contd) Representing a functional dependency Part_Number functionally determines Part_Cost Part_Number determines Part_Cost Part_Cost is dependent on Part_Number Part_Number Part_Cost In general, we say that a determinant determines the dependent attribute. Determinant dependent attribute

11 11 Copyright © 2004 M. E. Kabay. All rights reserved. Functional Dependencies (contd) There is theoretically an N:1 relationship between determinant and dependant attribute A Part_Number determines exactly one Part_Cost However, it is normal to expect that many different Part_Numbers may have the same particular Part_Cost Another formulation states that attribute X determines attribute Y, then X:Y::N:1 It is also possible that X:Y::1:1; e.g., Patient_ID SSN (in theory)

12 12 Copyright © 2004 M. E. Kabay. All rights reserved. Functional Dependencies (contd) A functional dependency may involve more than two attributes; e.g., if Extended_Price = Part_Price X Quantity_Ordered, then Extended price is functionally dependent on part price and quantity ordered. (Part_Price, Quantity_Ordered) Extended_Price Other examples: (State, Car_Reg#) Owner_Name (Patient_ID, Admission_Date) (Room#, Bed#)

13 13 Copyright © 2004 M. E. Kabay. All rights reserved. Functional Dependencies (contd) Functional dependencies are directional If A (B,C) we say that A determines both B and C; or in other words, A B and A C However, suppose (D,E) F Then it does not follow that D F nor that E F E.g., if (Stock_Name, Date) Stock_Price one cannot assert That knowing the Stock_Name alone tells us the Stock_Price, nor That knowing the Date alone tells us the Stock_Price

14 14 Copyright © 2004 M. E. Kabay. All rights reserved. Keys A group of one or more attributes (fields, columns) that uniquely identifies a tuple (records, row) is called a key; e.g., In a hospital DB, Doctor_ID might identify all the current attributes of a physician including name, address, SSN, specialty (or specialties), and so on; this would be the key But a patient record might be constructed to reflect the current admission; in which case Patient_ID and Admission_Date might be required to identify the current record uniquely; the key would be (Patient_ID,Admission_Date)

15 15 Copyright © 2004 M. E. Kabay. All rights reserved. Keys (contd) Every relation has at least one key No record (tuple, row) may duplicate another Many relations have several possible keys Determining which attributes or combinations of attributes are keys requires analysis of the business model There is no answer at the back of the book Analyst must find out what the users do with their data – e.g., do they care about historical records or only about the current status? [Explain why this matters.]

16 16 Copyright © 2004 M. E. Kabay. All rights reserved. Normalization Not all relations are equally useful Some cause problems when we add, delete or change part of the data in the relations Modification Anomalies Essence of Normalization Classes of Relations

17 17 Copyright © 2004 M. E. Kabay. All rights reserved. Modification Anomalies Suppose we have a record that stores information about a client who has bought something at our store Client# Client_Name Client_Address Client_Phone Item# Item_Name Item_Price Date_Purchased But what if we want to get rid of old client records without losing the Item#, Item_Name and Item_Price? How do we handle changing the price of an item without altering historical records? What do we do to manage the attributes of an item that no one has bought?

18 18 Copyright © 2004 M. E. Kabay. All rights reserved. Deletion Anomaly Patient record has information about Doctor_ID, Doctor_Name, Doctor_Phone etc. So what happens when we delete the last patient record that contains information about a particular doctor? Garage mechanic stores Auto_Name, Auto_VIN, Repair_type, Repair_type_cost.... So how does the mechanic remember the cost of changing a muffler if she deletes the last record that happens to contain information about that type of repair?

19 19 Copyright © 2004 M. E. Kabay. All rights reserved. Insertion Anomaly A factory DB has a relation that groups Part#, Part_Name, Part_Cost, Inventory_Bin#, Bin_location, Bin_Capacity, Quantity_on_hand How would one add information about a part that has not yet been assigned a bin#? How would one handle information about a part that gets assigned to two separate bins at different parts of the factory? Could one add information about a new bin without actually having a part assigned to it?

20 20 Copyright © 2004 M. E. Kabay. All rights reserved. Referential Integrity A DB used to handle information about library books includes a relation between many books and specific publishers. One publisher may be related to many books but each book has only one publisher. What problems will occur if the record for the last book from a publisher is deleted? Should this delete publisher information? Should it be possible to delete the record for a publisher even though there are many books left from that publisher? These rules are described as referential integrity constraints or inter-relation constraints

21 21 Copyright © 2004 M. E. Kabay. All rights reserved. Homework Study Kroenkes Chapter 5 pp 121 – 127 thoroughly using the full SQ3R method. Prepare for class on Tuesday the 17 th of February 2004 by doing the SQ phases of SQ3R on pages of Chapter 5. We will complete our introduction to normalization on Tuesday. This is difficult material, so STUDY. By Thursday 19 Feb 2004 – for 10 points Write out the answers to questions 5.1 to 5.10 and submit them at the start of class By Thursday 26 Feb 2004 – for up to 6 extra points, Write out and submit the answers to question 5.24 parts a through f

22 22 Copyright © 2004 M. E. Kabay. All rights reserved. DISCUSSION


Download ppt "The Relational Model and Normalization (1) IS 240 – Database Management Lecture #7 – 2004-02-12 Prof. M. E. Kabay, PhD, CISSP Norwich University"

Similar presentations


Ads by Google