1. INTRODUCTIONRelational database design requires a good collection of relation schemas. 3.1.1. Pit-falls in Relational Database Design A bad design may lead to Repetition of information Inability to represent certain information Design Goals Avoid redundant data. Ensure that relationships among attributes are represented. Facilitate the checking of updates for violation of database integrity constraints. ExampleConsider the relation schema: Lending-schema= (branch_name, branch_city, assets,c ustomer_name, loan_no, amount).Table 3.1 Loan TableBranch_NameBranch_CityAssetsCustomer_NameLoan_NoAmount

DowntownBrooklyn900000JonesL-171000

RedwoodPalo Alto2100000SmithL-232000

PorryrideHorseneck1700000HayesL-151500

DowntownBrooklyn9000000JacksonL-143500

Here branch Downtown details are represented 2 times. This leads to a redundancy problem. 3.1.2. Redundancy Redundancy leads to Wastage of space. Complicates updating, introduces inconsistency. Null values Cannot store information about a branch if no loan exist.

Can use null values, but they are difficult to handle. 3.2 FUNCTIONAL DEPENDENCIES Functional dependencies are constraints on the set of legal relations. The functional dependency holds on R if and only if for any legal relations r(R), whenever any two tuples t1 and t2 of r agree on the attributes , they also agree on the attributes . That is, t1[] = t2 [] t1[ ] = t2 [ ] It requires that the value for a certain set of attributes determines uniquely the value for another set of attributes. In a given relation R, X and Y are attributes. Attributes Y is functionally dependent on attribute X if each value of X determines exactly one value of Y, which is represented as X > Yi.e., X determines Y or Y is functionally dependent on XX > Y does not imply Y > X For example, in a student relation the value of an attribute Marks is known then the value of an attribute Grade is determined since Marks > Grade3.2.1 Types Full functional dependency Partial functional dependency Transitive functional dependency 3.2.1.1. Full dependencies

Course_noIn a relation R, X and Y are attributes. X functionally determines Y. Subset of X should not functionally determine Y.

Marks

Student_no

Figure 3.1. Full dependencies

In the above example marks is fully functionally dependent on student_no and course_no together and not on subset of {student_no, course_no}. This means marks cannot be determined either by student_no or course_no alone.It can be determined only using student_no and course_no together. Hence marks are fully functionally dependent on {student_no, course_no}. 3.2.1.2. Partial dependenciesAttribute Y is partially dependent on the attribute X only if it is dependent on a subset of attribute X. For example course_name, Instructer_name are partially dependent on composite attributes {student-no,course_no} because course_no alone defines course_name, Instructor_name. 3.2.1.3. Transitive dependencies X, Y and Z are 3 attributes in the relation R.X YY ZX ZFor example, grade depends on marks and in turn mark depends on {student_no, course_no}, hence Grade depends fully transitively on {student_no & course_no}. 3.2.1.4. Use of Functional Dependencies We use functional dependencies to: Test relations to see if they are legal under a given set of functional dependencies. If a relation r is legal under a set F of functional dependencies, we say that r satisfies F. specify constraints on the set of legal relationsWe say that F holds on R if all legal relations on R satisfy the set of functional dependencies F. 3.2.2. Closure of a set of functional dependencies Given a set of functional dependencies F, there are certain other functional dependencies that are logically implied by F. For example: If AB and BC, then we can infer that AC The set of all functional dependencies logically implied by F is the closure of F. We denote the closure of F by F+. We can find all F+ by applying Armstrongs Axioms: Reflexivity Rule

If is a set of attributes and , then holds. Augmentation Rule If, then is a set of attributes, then holds. Transitivity Rule If holds and holds then holds. Sound (generate only functional dependencies that actually hold) and Complete (generate all functional dependencies that hold). were the rules.In addition to these three basic rules there are three additional rules to simplify manual computation of F+. Union Rule If holds and holds, then holds Decomposition Rule If holds, then holds and holds Pseudotransitivity Rule If holds and holds, then holdsExample: Consider the schema R = (A, B, C, G, H, I)Set of functional dependency F = {AB, AC, CGH, CGI, BH} Some members of F+ AH By transitivity from AB and BH then AH holds. AGI By augmenting AC with G, to get AGCG and then transitivity with CGI we get AGI. CGHI By union rule of CGH and CGI, CGHI holds. The left-hand and right-hand sides of a functional dependency are both subsets of R.

Procedure for Computing F+: To compute the closure of a set of functional dependencies F: F + = Frepeatfor each functional dependency f in F+apply reflexivity and augmentation rules on fadd the resulting functional dependencies to F +for each pair of functional dependencies f1and f2 in F +if f1 and f2 can be combined using transitivitythen add the resulting functional dependency to F +until F + does not change any further A set of size n has 2n subsets, there are a total of 2 2n = 2n+1 possible functional dependencies, where n is the number of attributes in R. Each iteration of the loop except the last iteration adds at least one functional dependency to F+. 3.2.3 Closure of attributes sets An attribute is functionally determined by if holds. Given a set of attributes , define the closure of (+) under F as the set of attributes that are functionally determined by under F Algorithm to compute +, the closure of under F result := a;while (changes to result) do for each in F dobegin

if result then result := resultend Example of Attribute Set Closure is R = (A, B, C, G, H, I) F = {AB ,AC, CGH ,CGI ,BH}To compute closure of A, (AG)+ The algorithm start with result = AG result = AG

A B includes B in result. Since A B is in F and Aresult, so result: = result B result = ABCGH (CGH and CGAGBC) result = ABCG (AC ) result = ABCGHI (CGI and CGAGBCH)Uses of Attribute Closure There are several uses of the attribute closure algorithm: Testing for super key: To test if is a super key, we compute +, and check if + contains all attributes of R. Testing functional dependencies To check if a functional dependency holds ( in other words, is in F+), just check if +. That is, we compute + by using attribute closure, and then check if it contains. Is a simple and cheap test, and very useful 3.2.4. CANONICAL COVER If a relational schema R has a set of functional dependencies. Whenever a user performs an update on the relation, the database system must ensure that the update does not violate any functional dependencies. The system must roll back the update if it violates any functional dependencies in the set F. The violation can be checked by testing a simplified set of functional dependencies. If simplified set of functional dependency is satisfied then the original functional dependency is satisfied and vice versa. Sets of functional dependencies may have redundant dependencies that can be inferred from the others. A canonical cover of F is a minimal set of functional dependencies equivalent to F, having no redundant dependencies or redundant parts of dependencies Extraneous Attributes An attribute of a functional dependency is said to be extraneous if we can remove it without changing the closure of the set of functional dependencies. Consider a set F of functional dependencies and the functional dependency in F. Attribute A is extraneous in if A and F logically implies

Attribute A is extraneous in if A the set of functional dependencies

Example: Given as F={AC,ABC}B is extraneous in ABC because {AC,ABC} logically implies AC.Example: Given F={AC,ABCD}C is extraneous in ABCD since ABC can be inferred even after deleting C. Testing if an Attribute is ExtraneousConsider a set F of functional dependencies and the functional dependency in F. To test if attribute A is extraneous in Compute ({} - A)+ using the dependencies in F Check that ({} - A)+ contains A; if it does, A is extraneous in To test if attribute is extraneous in . Compute + using only the dependencies in Check that + contains A; if it does, A is extraneous in Example: F contains ABCD, AE and EC. to check C is extraneous in ABCD, we compute the attribute closure of AB under F= {ABCD, AE, EC} The closure is ABCDE, which includes CD. So C is extraneous.Definition of Canonical Cover A canonical cover for F is a set of dependencies Fc such that F logically implies all dependencies in Fc, and Fc logically implies all dependencies in F, and No functional dependency in Fc contains an extraneous attribute, and Each left side of functional dependency in Fc is unique. To compute a canonical cover for F: Fc =F Use the union rule to replace any dependencies in F, 11 and 12 with 112Find a functional dependency with an extraneous attribute either in or .If an extraneous attribute is found, delete it from until F does not change Computing a Canonical Cover R = (A, B, C) F = {A BC, B C, A B, AB C}

By union rule combine A BC and A B into A BC. Set is now {A BC, B C, AB C}

A is extraneous in AB C Check if the result of deleting A from AB C is implied by the other dependencies After deleting A from AB C the resultant set will be {A BC, B C, B C} B C is already present in the set. So the resultant set is now {A BC, B C} C is extraneous in A BC. Removing C from A BC we get {A B, B C} The canonical cover is: A B & B C, Canonical cover might not be unique. 3.13. ANOMALIES IN DATABASES There are three types of anomalies. They are Insert Anomalies Update Anomalies Delete Anomalies Insert Anomalies: The inability to insert part of information into a relational schema due to the unavailability of part of the remaining information is called Insert Anomalies. Example: If there is a guid having no registered under him, then we cannot insert the guides information in the schema project. Update Anomalies: Updation of relation schema with redundancy may lead to update anomalies.

Example: If a person changes his address then the updating should be carried out wherever the copies occur. If it is not updated properly then data inconsistency arises. Delete Anomalies: If the deletion of some information leads to loss of some other information, then we say there is a deletion anomaly. Example: If a guide guides one student and if the student discontinues the course then the information about the guid will be lost.