Functional Dependency, Normalization INFO 340 Lecture 6 Functional Dependency, Normalization

DeMorgan’s Theorem A AND B = A OR B A OR B = A AND B

For the following questions, use DeMorgan’s theorem to write 2 alternative versions of the where clause. Use the relations Fig 3.3 (pg 80) in the book: From the staff table, which staff are male or have a birthdate after Jan 1, 1952 ? What are the clientno’s and maxrents where the preference type is a flat and the telephone # has a 0 as a first digit ? Which clients had viewed property before May 15, 2004 and preferred a house?

“Spreadsheet Syndrome”? When you use a spreadsheet program, you only really have one table. This leads to duplication of data. Order ID Request Date Vendor Name Delivery Attention Delivery Address Delivery Box Delivery Phone Shipping Method Tax Rate Product Number Product Description Qty Unit Size Unit Price Total 252101 2008-12-02 12:33:23 Dell Computer Corp Michael Middlebrooks Hlth Sci Bldg BB-704 Seattle,,WA 98195 357470 543-4599 Standard 9% 341-2648 400 / 800 GB Data Cartridge for LTO Ultrium 3 Tapes - 15 pack 1.00 15 pack 491.39 535.62 310-8156 350W Additional Power Supply, SP Only, for Dell AX150 each 299.25 326.18 253517 2008-12-09 12:13:00 Buy.com HSB BB704 1959 NE Pacific Street Seattle,WA 98195-7470 206-221-5790 Second Day PCI1394_2LP Startech.com 2 Port IEEE-1394 FireWire Low Profile PCI Card with Digital Video Editing Kit - PCI1394_2LP 4.00 ea 21.26 92.69 253779 2008-12-10 11:39:02 Hlth Sci Bldg BB-704 Seattle,,WA 98195 A1613067 CAT6 Snagless Tip Network Cable - Pink - 3 ft 12.00 6.15 80.44 A0158659 CAT6 Snagless Tip Network Cable - Blue - 20 ft 2.00 15.83 34.51 http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html

Normalization Goal: Every non-key column is directly dependent on the key, the whole key, and nothing but the key! Goal: Reduce redundancies, less anomalies, and improve efficiency.

Functional Dependency & Normalization How normalization can be used when designing a relational database. The potential problems associated with redundant data in base relations. The concept of functional dependency, which describes the relationship between attributes. The characteristics of functional dependencies used in normalization.

Functional Dependency & Normalization How to identify the most commonly used normal forms, namely First Normal Form (1NF), Second Normal Form (2NF), and Third Normal Form (3NF).

Functional Dependency & Normalization Characteristics of a suitable set of relations include: the minimal number of attributes necessary to support the data requirements of the enterprise; attributes with a close logical relationship are found in the same relation; minimal redundancy with each attribute represented only once with the important exception of attributes that form all or part of foreign keys.

What happens if normalization hasn’t occurred? Data duplication Multiple truths Inability to separate entities Difficulty to query Multiple truths – If only one part is updated, may have conflicting information. Inability to separate – If Staff & Branch are in the same table, with the staffID as the primary key, you can not create a branch without a staff member. Same if you need to remove a staff member, bye bye branch.

Functional Dependency A  B if for each value of A there is associated exactly one value of B. Or think of it mathematically: F(A) = B, A B Example: Name  Date of Birth. That is for a given person’s name, there is only one DOB that is associated with them. On the other hand, a date does not functionally determine a person. Many people can be born on a given day.

Full functional dependency Functional dependencies can work on sets, for example: (student_no, course_no)  instructor is valid. A fully functional dependency is when you can not remove items from the first set (the A in AB) and maintain a functional dependency. The above example is not a full functional dependency, because course_no instructor is a functional dependency.

Transitive Dependency Important to recognize a transitive dependency because its existence in a relation can potentially cause update anomalies. Transitive dependency describes a condition where A, B, and C are attributes of a relation such that if A → B and B → C, then C is transitively dependent on A via B (provided that A is not functionally dependent on B or C).

Transitive Dependency Example Consider functional dependencies in the StaffBranch relation staffNo → sName, position, salary, branchNo, bAddress branchNo → bAddress Transitive dependency, branchNo → bAddress exists on staffNo via branchNo.

Functional Dependency & Normalization Main characteristics of functional dependencies used in normalization: There is a one-to-one relationship between the attribute(s) on the left-hand side (determinant) and those on the right-hand side of a functional dependency. Holds for all time. The determinant has the minimal number of attributes necessary to maintain the dependency with the attribute(s) on the right hand-side.

Functional Dependency & Normalization

Normalization Formal technique for analyzing a relation based on its primary key and the functional dependencies between the attributes of that relation. Often executed as a series of steps. Each step corresponds to a specific normal form, which has known properties. As normalization proceeds, the relations become progressively more restricted (stronger) in format and also less vulnerable to update anomalies.

Functional Dependency & Normalization

1st Normalized Form A relation in which the intersection of each row and column contains one and only one value. Atomicity. Based upon you’re requirements, a column holds only one value. Requirements are important. Again, an address maybe fine as one text string, but if it should be decomposed into house number, street, city, etc. then it needs to be. The great NULL debate. Many hold that normalized tables can not have NULLs.

Examples of 1NF Let’s look at what’s not 1NF. Imagine a table with names and telephone numbers. What if we need more than one telephone #? Add the value to the existing field, maybe a string value separated by comma. Breaks 1NF Fig 13.10 in book It is completely possible to be 1NF and have duplicate values carried over different rows. This is fixed in 2NF.

2nd Normal Form Based on the concept of full functional dependency. A relation that is in 1NF and every non-primary-key attribute is fully functionally dependent on the primary key.

2NF examples Student Class Location John CSE 143 EEB 103 EE 131 Susie INFO 340 MGH 238 MATH 124 PAR 104 While in 1NF form, it is not in 2NF form. Candidate Key {Student,Class} . Location is not fully functional dependent, since it is dependent only on Class. Student Class John CSE 143 EE 131 Susie INFO 340 MATH 124 Remember, all candidate keys must be examined, even if a primary key has been chosen. Still not immune to update issues. Class Location CSE 143 EEB 103 EE 131 INFO 340 MGH 238 MATH 124 PAR 104

3rd Normal Form Based on the concept of transitive dependency. A relation that is in 1NF and 2NF and in which no non-primary-key attribute is transitively dependent on the primary key.

3NF example PublisherID Name Address City State ZIP 1 Apress 2560 Ninth Street, Station 219 Berkeley CA 94710 PublisherID Name Address ZIP 1 Apress 2560 Ninth Street, Station 219 94710 ZIP City State 94710 Berkeley CA Looks good, but notice that City and State are really dependent on ZIP, not Publisher_ID. A good way to find transitive functional dependencies is think to yourself. If I update this column, do I need to update others? In this case, updating the City column would require you to update the ZIP and possible the State column. This example, though, hints that one of the dangers of normalization, that you can sometimes go too far..

Homework 13.1, 13.3,13.10,13.11

In First, Second, or Third Normal Form Books Lecture 6 Class Exercise For every relation: Identify all FD’s Including transitive 2) Answer whether it is In First, Second, or Third Normal Form