The Relational Model and Normalization (1) IS 240 – Database Management Lecture #7 – 2004-02-12...

The Relational Model and

Normalization (1)

IS 240 – Database ManagementLecture #7 – 2004-02-12

Prof. M. E. Kabay, PhD, CISSP

Norwich University

[email protected]

mailto:[email protected]

2 Copyright © 2004 M. E. Kabay. All rights reserved.

Topics

Intro to DB DesignRelational Model

DefinitionsFunctional DependenciesKeysUniqueness

Homework


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 pseudocodeCan 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


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


Definitions (cont’d)

Table

Row

Column

Cell



Record

Field

FileCell



Tuple

Attribute

RelationCell


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 colorHeight – and not weight or eye-colorSalary – 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 uniqueOrder of attributes and tuples is arbitrary – many

designs are functionally equivalent


Functional Dependencies

Relationship among attributes thatPermits one to determine the value of one

attribute . . . . . . given the value of another attribute

ExamplesStudent_ID allows student to find out the

current GPAPart_Number leads to current inventoryClinical_Code allows insurance carrier to

determine fee to be paid to doctor


Functional Dependencies (cont’d)

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



There is theoretically an N:1 relationship between determinant and dependant attributeA Part_Number determines exactly one

Part_CostHowever, 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)



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_PriceOther examples:

(State, Car_Reg#) Owner_Name(Patient_ID, Admission_Date) (Room#, Bed#)


Functional Dependencies (cont’d)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 CHowever, 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, norThat knowing the Date alone tells us the

Stock_Price


KeysA 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)


Keys (cont’d)

Every relation has at least one keyNo record (tuple, row) may duplicate

anotherMany relations have several possible keysDetermining which attributes or combinations

of attributes are keys requires analysis of the business modelThere 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.]


Normalization

Not all relations are equally usefulSome cause problems when we add, delete

or change part of the data in the relationsModification AnomaliesEssence of NormalizationClasses of Relations


Modification Anomalies

Suppose we have a record that stores information about a client who has bought something at our store

Client#Client_NameClient_AddressClient_Phone Item# Item_Name Item_PriceDate_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?


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?


Insertion Anomaly

A factory DB has a relation that groups Part#, Part_Name, Part_Cost, Inventory_Bin#, Bin_location, Bin_Capacity, Quantity_on_handHow 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?


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


HomeworkStudy Kroenke’s Chapter 5 pp 121 – 127

thoroughly using the full SQ3R method.Prepare for class on Tuesday the 17th of February

2004 by doing the SQ phases of SQ3R on pages 127-146 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 pointsWrite out the answers to questions 5.1 to 5.10

and submit them at the start of classBy Thursday 26 Feb 2004 – for up to 6 extra

points,Write out and submit the answers to question

5.24 parts a through f


DISCUSSION

Date post:	26-Mar-2015
Category:	Documents
Upload:	michael-douglas
View:	219 times
Download:	0 times

The Relational Model and Normalization (1) IS 240 – Database Management Lecture #7 – 2004-02-12...

Documents