Query-by-Example (QBE)

QBE is both a query language and the name of a DB system including it. The system is no longer in use, but the language is part of IBM's Query Management Facility (QMF).

Basic Structure QBE has ``two-dimensional'' syntax. Queries are expressed by example. Close correspondence with domain relational calculus Non-procedural. Queries are expressed using skeleton tables. User selects the skeletons needed. User fills in skeletons with example rows. An example row consists of constants and example elements which are really

domain variables. Domain variables are preceded by an underscore character. Constants appear without any qualification.

QBE Skeleton Tables for the Bank Example

Queries on One Relation

_ Find all loan numbers at the Perryridge branch.

A P. before the variable causes printing. P. means print (display) duplicates are removed by default A P.ALL. prefix suppresses duplicate elimination. A P. in front of the row prints all attributes. The domain variable may be omitted if it is not used elsewhere. Arithmetic expressions are allowed. Comparison operators are allowed, space on left hand side is left blank. _x is a variable (optional; can be omitted in above query)

Display full details of all loans

Method 1:

Method 2: Shorthand notation

Find the loan number of all loans with a loan amount of more than $700

Find names of all branches that are not located in Brooklyn

Find the loan numbers of all loans made jointly to Smith and Jones.

Find all customers who live in the same city as Jones

Queries on Several Relations

Find the names of all customers who have a loan from the Perryridge branch.

Find the names of all customers who have both an account and a loan at the bank.

Negation in QBE

Find the names of all customers whohave an account at the bank, but do not have a loan from the bank.

¬ means “there does not exist”

Find all customers who have at least two accounts.

¬ means “not equal to”

The Condition Box

Allows the expression of constraints on domain variables that are either inconvenient or impossible to express within the skeleton tables.

Complex conditions can be used in condition boxes.

Condition Box

E.g. Find the loan numbers of all loans made to Smith, to Jones, or to both jointly

QBE supports an interesting syntax for expressing alternative values

Find all account numbers with a balance between $1,300 and $1,500

Find all account numbers with a balance between $1,300 and 2,000 but not exactly $1,500.

Find all branches that have assets greater than those of at least one branch located in Brooklyn

The Result Relation

Find the customer-name, account-number, and balance for all customers who have an account at the Perryridge branch.We need to:

Join depositor and account. Project customer-name, account-number and balance.

To accomplish this we:

Create a skeleton table, called result, with attributes customer-name, account-number, and balance.

The resulting query is:

Ordering the Display of Tuples

AO = ascending order; DO = descending order.

E.g. list in ascending alphabetical order all customers who have an account at the bank

When sorting on multiple attributes, the sorting order is specified by including with each sort operator (AO or DO) an integer surrounded by parentheses.

E.g. List all account numbers at the Perryridge branch in ascending alphabetic order with their respective account balances in descending order.

Aggregate Operations

The aggregate operators are AVG, MAX, MIN, SUM, and CNT .The above operators must be postfixed with “ALL” (e.g., SUM.ALL.or AVG.ALL._x) to ensure that duplicates are not eliminated.

E.g. Find the total balance of all the accounts maintained at the Perryridge branch.

UNQ is used to specify that we want to eliminate duplicates

Find the total number of customers having an account at the bank.

Query Examples

Find the average balance at each branch.

The “G” in “P.G” is analogous to SQL’s group by construct The “ALL” in the “P.AVG.ALL” entry in the balance column ensures that all balances are considered

To find the average account balance at only those branches where the average account balance is more than $1,200, we simply add the condition box:

Query Example

Find all customers who have an account at all branches located in Brooklyn.

Approach: for each customer, find the number of branches in Brooklyn at which they have accounts, and compare with total number of branches in BrooklynQBE does not provide subquery functionality, so both above tasks have to be combined in a single query.Can be done for this query, but there are queries that require subqueries and cannot be expressed in QBE.In the query on the next pageCNT.UNQ.ALL._w specifies the number of distinct branches in Brooklyn. Note: The variable _w is not connected to other variables in the query CNT.UNQ.ALL._z specifies the number of distinct branches in Brooklyn at which customer x has an account.

Modification of the Database – Deletion

Deletion of tuples from a relation is expressed by using D. command. In case where we delete information in only some of the columns, null values, specified by –, are inserted.

Delete customer Smith

Delete the branch-city value of the branch whose name is “Perryridge”.

Deletion Query Examples

Delete all loans with a loan amount between $1300 and $1500.For consistency, we have to delete information from loan and borrower tables

Delete all accounts at branches located in Brooklyn.

Modification of the Database – Insertion

Insertion is done by placing the I. operator in the query expression.Insert the fact that account A-9732 at the Perryridge branch has a balance of $700.

Provide as a gift for all loan customers of the Perryridge branch, a new $200 savings account for every loan account they have, with the loan number serving as the account number for the new savings account.

Modification of the Database – Updates

Use the U. operator to change a value in a tuple without changing all values in the tuple. QBE does not allow users to update the primary key fields.Update the asset value of the Perryridge branch to $10,000,000.

Data Integrity

The aim of data integrity is to specify rules that implicitly or explicitly define a consistent database state or changes of state. These rules may include facilities like those provided by most programming languages for declaring data types which constrain the user from operations like comparing data of different data types and assigning a variable of one type to another of a different type. This is done to stop the user from doing things that generally do not make sense. In a DBMS, integrity constraints play a similar role.

Integrity constraints guard against accidental damage to the database, by ensuring that authorized changes to the database do not result in a loss of data consistency.

The integrity constraints are necessary to avoid situations like the following:

1. Some data has been inserted in the database but it cannot be identified (that is, it is not clear which object or entity the data is about).

2. A student is enrolled in a course but no data about him is available in the relation that has information about students.

3. During a query processing, a student number is compared with a course number (this should never be required).

4. A student quits the university and is removed from the student relation but is still enrolled in a course.

Integrity constraints on a database may be divided into two types:

1. Static Integrity Constraints - these are constraints that define valid states of the data. These constraints include designations of primary keys etc.

2. Dynamic Integrity Constraints - these are constraints that define side-effects of various kinds of transactions (e.g. insertions and deletions).

1. Primary Keys 2. Domains 3. Foreign Keys and Referential Integrity 4. Nulls

Primary Keys

From the definition of candidate key, it should be clear that each relation must have at least one candidate key even if it is the combination of all the attributes in the relation since all tuples in a relation are distinct. Some relations may have more than one candidate keys.

The primary key of a relation is an arbitrarily but permanently selected candidate key. The primary key is important since it is the sole identifier for the tuples in a relation. Any tuple in a database may be identified by specifying relation name, primary key and its value. Also for a tuple to exist in a relation, it must be identifiable and therefore it must have a primary key. The relational data model therefore imposes the following two integrity constraints:

(a) no component of a primary key value can be null;

(b) attempts to change the value of a primary key must be carefully controlled.

The first constraint is necessary because if we want to store information about some entity, then we must be able to identify it, otherwise difficulties are likely to arise. For example, if a relation

CLASS (STUNO, LECTURER, CNO)

has (STUNO, LECTURER) as the primary key then allowing tuples like

3123 Null CP302Null Smith CP302

is going to lead to ambiguity since the two tuples above may or may not be identical and the integrity of the database may be compromised. Unfortunately most commercial database systems do not support the concept of primary key and it would be possible to have a database state when integrity of the database is violated.

The second constraint above deals with changing of primary key values. Since the primary key is the tuple identifier, changing it needs very careful controls. Codd has suggested three possible approaches:

Method 1

Only a select group of users be authorised to change primary key values.

Method 2

Updates on primary key values be banned. If it was necessary to change a primary key, the tuple would first be deleted and then a new tuple with new primary key value but same other values would be inserted. Of course, this does require that the old values of attributes be remembered and be reinserted in the database.

Method 3

A different command for updating primary keys be made available. Making a distinction in altering the primary key and another attribute of a relation would remind users that care needs to be taken in updating primary keys.

Domains

Many commercial database systems do not provide facilities for specifying domains. Domains could be specified as below:

Create Domain Name1 Char(10)Create Domain Stuno IntegerCreate Domain Name2 Char(10)Etc.

Note that NAME1 and NAME2 are both character strings of length 10 but they now belong to different (semantic) domains. It is important to denote different domains to

(a) Constrain unions, intersections, differences, and equijoins of relations.

(b) Let the system check if two occurrences of the same database value denote the same real world object.

The constraint on union-compatibility and join-compatibility is important so that only those operations that make sense are permitted. For example, a join on class number and student number would make no sense even if both attributes are integers and the user should not be permitted to carry out such operations (or at least be warned when it is attempted).

Domain Constraints All the values that appear in a column of a relation must be taken from the same domain. A domain usually consists of the following components.

1. Domain Name 2. Meaning 3. Data Type 4. Size or length 5. Allowable values or Allowable range ( if applicable)

Entity Integrity The Entity Integrity rule is so designed to assure that every relation has a primary key and that the data values for the primary key are all valid. Entity integrity guarantees that every primary key attribute is non null. No attribute participating in the primary key of a base relation is allowed to contain nulls. Primary key performs unique identification function in a relational model. Thus a null primary key performs the unique identification function in a relation would be like saying that there are some entity that had no known identity. An entity that cannot be identified is a contradiction in terms, hence the name entity integrity.

Operational Constraints These are the constraints enforced in the database by the business rules or real world limitations. For example if the retirement age of the employees in a organization is 60, then the age column of the employee table can have a constraint “Age should be less than or equal to 60”. These kinds of constraints enforced by the business and the environment are called operational constraints.

Null constraints NOT NULL constraint restricts attributes to not allow NULL values. NULL is a special value: Many possible interpretations: value unknown, value inapplicable, Value withheld, etc. Often used as the default value

Example: INSERT INTO Student VALUES (135, ’Maggie’, NULL, NULL); or INSERT INTO Student (SID, name) VALUES (135, ’Maggie’);

Foreign Keys and Referential Integrity

Some problems related to primary key arise because primary key value of a tuple may be referred in many relations of the database. When a primary key is modified, each of these references to a primary key must either be modified accordingly or be replaced by NULL values. Only then we can maintain referential integrity.

The concept of foreign key is important since a relational database consists of relations only (no pointers) and relationships between the relations are implicit, based on references to primary keys of other relations. These references are called foreign keys.

A foreign key in a relation R is a set of attributes whose values are required to match those of the primary key of some relation S.

In the following relation the supervisor number is a foreign key (it is the primary key of employee)

employee (empno, empname, supervisor-no, dept)

In the following relation Class, student-num and lecturer-num are foreign keys since they appear as primary keys in other relations (relations student and lecturer).

Class (student-num, lecturer-num, subject) student ( ) lecturer ( )

Foreign keys are the implicit references in a relational database. The following constraint is called referential integrity constraint:

If a foreign key F in relation R matches the primary key P of relation S than every value of F must either be equal to a value of P or be wholly null.

The justification for referential integrity constraint is simple. If there is a foreign key in a relation (that is if the relation is referring to another relation) then its value must match with one of the primary key values to which it refers. That is, if an object or entity is being referred to, the constraint ensures the referred object or entity exists in the database.

In the relational model the association between the tables is defined using foreign keys. The association between the SHIPMENT and ELEMENT tables is defined by including the Symbol attribute as a foreign key in the SHIPMENT table. This implies that before we insert a row in the SHIPMENT table, the element for that order must already exist in the ELEMENT table.

A referential integrity constraint is a rule that maintains consistency among the rows of two tables or relations. The rule states that if there is a foreign key in one relation, either each of the foreign key value must match a primary key value in the other table or else the foreign key value must be null.

When Should Constraints Be Checked? • Usually they are checked for each modification statement. • But sometimes deferred constraint checking is necessary.

Functional Dependencies

Functional dependencies assume that a relational schema has attributes (A, B, C... Z) and that the whole database is described by a single universal relation called R = (A, B, C, ..., Z). This assumption means that every attribute in the database has a unique name.

What is functional dependency in a relation? A functional dependency is a property of the semantics of the attributes in a relation. The semantics indicate how attributes relate to one another, and specify the functional dependencies between attributes. When a functional dependency is present, the dependency is specified as a constraint between the attributes. Consider a relation with attributes A and B, where attribute B is functionally dependent on attribute A. If we know the value of A and we examine the relation that holds this dependency, we will find only one value of B in all of the tuples that have a given value of A, at any moment in time. Note however, that for a given value of B there may be several different values of A.

B is functionally depend on A

In the figure above, A is the determinant of B and B is the consequent of A.

The determinant of a functional dependency is the attribute or group of attributes on the left-hand side of the arrow in the functional dependency. The consequent of a fd is the attribute or group of attributes on the right-hand side of the arrow.

Identifying Functional Dependencies

STAFFBRANCH

Staff # Sname Position Salary Branch# BaddressSL21 Kristy Manager 30000 B005 22 Deer

RoadSG37 Debris Assistant 12000 B003 162 Main

StreetSG14 Alan Supervisor 18000 B003 163 Main

StreetSA9 Traci Assistant 12000 B007 375 Fox

AvenueSG5 David Manager 24000 B003 163 Main

Street

A B

The functional dependency staff# → position clearly holds on this relation instance. However, the reverse functional dependency position → staff# clearly does not hold. The relationship between staff# and position is 1:1 – for each staff member there is only one position. On the other hand, the relationship between position and staff# is 1:M – there are several staff numbers associated with a given position.

Position is functionally dependent on Staff#

Staff# is NOT functionally dependent on Position

For the purposes of normalization we are interested in identifying functional dependencies between attributes of a relation that have a 1:1 relationship.

When identifying Fds between attributes in a relation it is important to distinguish clearly between the values held by an attribute at a given point in time and the set of all possible values that an attributes may hold at different times.

In other words, a functional dependency is a property of a relational schema (its intension) and not a property of a particular instance of the schema (extension).

The reason that we need to identify Fds that hold for all possible values for attributes of a relation is that these represent the types of integrity constraints that we need to identify. Such constraints indicate the limitations on the values that a relation can legitimately assume. In other words, they identify the legal instances which are possible. Let’s identify the functional dependencies that hold using the relation schema STAFFBRANCH In order to identify the time invariant Fds, we need to clearly understand the semantics of the various attributes in each of the relation schemas in question. For example, if we know that a staff member’s position and the branch at which they are located determines their salary. There is no way of knowing this constraint unless you are familiar with the enterprise, but this is what the requirements analysis phase and the conceptual design phase are all about!

staff# → sname, position, salary, branch#, baddress branch# → baddress baddress → branch# branch#, position → salary baddress, position → salary

Trivial Functional Dependencies As well as identifying Fds which hold for all possible values of the attributes involved in the fd, we also want to ignore trivial functional dependencies. A functional dependency is trivial if, the consequent is a subset of the determinant. In other words, it is impossible for it not to be satisfied. Example: the trivial dependencies include:

Staff# Position

Staff# Position

{ staff#, sname} → sname { staff#, sname} → staff#

Although trivial Fds are valid, they offer no additional information about integrity constraints for the relation. As far as normalization is concerned, trivial Fds are ignored.

Inference Rules for Functional Dependencies

F denotes, the set of functional dependencies that are specified on a relational schema R. Typically, the schema designer specifies the Fds that are semantically obvious; usually however, numerous other Fds hold in all legal relation instances that satisfy the dependencies in F. These additional Fds that hold are those Fds which can be inferred or deduced from the Fds in F. The set of all functional dependencies implied by a set of functional dependencies F is called the closure of F and is denoted F+.

The notation: F � X → Y denotes that the functional dependency X → Y is implied by the set of Fds F.

Formally, F+ ≡ {X → Y | F � X → Y}

A set of inference rules is required to infer the set of Fds in F+.

For example, if I tell you that Kristi is older than Debi and that Debi is older than Traci, you are able to infer that Kristi is older than Traci. How did you make this inference? Without thinking about it or maybe knowing about it, you utilized a transitivity rule to allow you to make this inference. The set of all Fds that are implied by a given set S of Fds is called the closure of S, written S+. Clearly we need an algorithm that will allow us to compute S+ from S. You know the first attack on this problem appeared in a paper by Armstrong which gives a set of inference rules. The following are the six well-known inference rules that apply to functional dependencies.

IR1: reflexive rule – if X ⊇  Y, then X →Y

IR2: augmentation rule – if X → Y, then XZ → YZ

IR3: transitive rule – if X → Y and Y→ Z, then X → Z

IR4: projection rule – if X→ YZ, then X → Y and X→ Z

IR5: additive rule – if X →Y and X →Z, then X →YZ

IR6: pseudo transitive rule – if X→ Y and YZ→ W, then XZ→ W

The first three of these rules (IR1-IR3) are known as Armstrong’s Axioms and constitute a necessary and sufficient set of inference rules for generating the closure of a set of functional dependencies.

These rules can be stated in a variety of equivalent ways. Each of these rules can be directly proved from the definition of functional dependency. Moreover the rules are complete, in the sense that, given a set S of Fds, all Fds implied by S can be derived from S using the rules. The other rules are derived from these three rules.

Given R = (A,B,C,D,E,F,G,H, I, J) and F = {AB → E, AG → J, BE → I, E → G, GI → H} Does F � AB → GH?

Proof 1. AB → E, given in F 2. AB → AB, reflexive rule IR1 3. AB → B, projective rule IR4 from step 2 4. AB → BE, additive rule IR5 from steps 1 and 3 5. BE → I, given in F 6. AB → I, transitive rule IR3 from steps 4 and 5 7. E → G, given in F 8. AB → G, transitive rule IR3 from steps 1 and 7 9. AB → GI, additive rule IR5 from steps 6 and 8 10. GI → H, given in F 11. AB → H, transitive rule IR3 from steps 9 and 10 12. AB → GH, additive rule IR5 from steps 8 and 11 - proven

Irreducible sets of dependencies

Let S1 and S2 be two sets of Fds, if every FD implied by S1 is implied by S2- i.e.; if S1+ is a subset of S2+-we say that S2 is a cover for S1+(Cover here means equivalent set). What this means that if the DBMS enforces the Fds in S2, then it will automatically be enforcing the Fds in S1.

Next if S2 is a cover for S1 and S1 is a cover for S2- i.e.; if S1+=S2+ -we say that S1 and S2 are equivalent, clearly, if S1 and S2 are equivalent, then if the DBMS enforces the Fds in S2 it will automatically be enforcing the Fds in S1, And vice versa.

Now we define a set of Fds to be irreducible( Usually called minimal in the literature) if and only if it satisfies the following three properties

1. The right hand side (the dependent) of every Fds in S involves just one attribute (that is, it is singleton set)

2. The left hand side (determinant) of every in S is irreducible in turn-meaning that no attribute can be discarded from the determinant without changing the closure S+(that is, with out converting S into some set not equivalent to S). We will say that such an Fd is left irreducible.

3. No Fd in S can be discarded from S without changing the closure S+(That is, without converting s into some set not equivalent to S)

Relation R {A,B,C,D,E,F} satisfies the following Fds AB → C C →A BC → D ACD → B BE → C

CE → FA CF → VD D →EF

Find an irreducible equivalent for this set of Fds? The solution is simple. Let us find the solution for the above.

1. AB → C 2. C →A 3. BC → D 4. ACD → B 5. BE →C 6. CE → A 7. CE → F 8. CF → B 9. CF → D 10. D → E 11. D → F

Now:

• 2 implies 6, so we can drop 6 • 8 implies CF → BC (By augmentation), by which 3 implies CF → D (By Transitivity), so we can drop 10. • 8 implies ACF → AB (By augmentation), and 11 implies ACD → ACF (By augmentation), and so ACD → AB (By Transitivity), and so ACD → B(By Decomposition), so we can drop 4

No further reductions are possible, and so we are left with the following irreducible set: AB → C C → A BC → D BE → C CE → F CF → B D → E D → F Alternatively: • 2 implies CD → ACD (By Composition), which with 4 implies CD → BE (By Transitivity), so we can replace 4 CD → B • 2 implies 6, so we can drop 6(as before) • 2 and 10 implies CF → AD (By composition), which implies CF → ADC (By Augmentation), which with (the original) 4 implies CF → B(By Transitivity), So we can drop 8.

No further reductions are possible, and so we are left with following irreducible set: AB → C C → A BC → D

CD → B BE → C CE → F CF → D D → E D → F Observe, therefore, that there are two distinct irreducible equivalence for the original set of Fds.

Concept Of redundancy (Updation Anomalies)

Analysis of Redundancies

A redundancy in a conceptual schema corresponds to a piece of information that can be derived (that is, obtained through a series of retrieval operations) from other data in the database.

Examples of Redundancies

Deciding About Redundancies The presence of a redundancy in a database may be decided upon the following factors An advantage: a reduction in the number of accesses necessary to obtain the derived information;

A disadvantage: because of larger storage requirements, (but, usually at negligible cost) and the necessity to carry out additional operations in order to keep the derived data consistent. The decision to maintain or delete a redundancy is made by comparing the cost of operations that involve the redundant information and the storage needed, in the case of presence or absence of redundancy.

Cost Comparison: An Example

The impact of redundancy with the help of an example.

Load and Operations for the Example

(1,1) (1,n) Person Residence

Town

Numberofinhabitants

In this schema the attribute Numberofinhabitants is redundant.

Table of volumes

Concept Type VolumeTownPersonResidence

EER

20010 00 00010 00 000

Table of operationOperation Type FrequencyOperation 1Operation 2

11

500 per day2 per day

Operation 1: adds a new person with a person’s town of residence.Operation 2: print all the data of a town (including the number of inhabitants).

Table of Accesses, with Redundancy

Operation 1Concept Type Accesses TypePersonResidenceTown

EntityRelationshipEntity

111

WWW

Operation 2Concept Type Accesses TypeTown Entity 1 R

Issues related to Redundancies (Anomalies)

The time has come to reveal the actual facts why normalization is needed. We will look in to the matter in detail now.

The serious problem with using the relations is the problem of update anomalies. These can be classified in to

Insertion anomalies

Deletion anomalies

Modification anomalies

Insertion Anomalies An "insertion anomaly" is a failure to place information about a new database entry into all the places in the database where information about that new entry needs to be stored. In a properly normalized database, information about a new entry needs to be inserted into only one place in the database; in an inadequately normalized database, information about a new entry may need to be inserted into more than one place and, human fallibility being what it is, some of the needed additional insertions may be missed.

This can be differentiated in to two types based on the following example

Emp_Dept

EName SSN BDate Address DNumber Dname DMGRSSN

Smith 123456789 1965-01-09 Kandivly 5 Research 333445555

Rajeev 333445555 1955-12-08 Vashi 5 Research 333445555

Geeta 999887777 1968-07-19 Sion 4 Admin 987654321

Rajesh 987654321 1941-06-20 Dadar 4 Admin 987654321

First Instance: - To insert a new employee tuple in to Emp_Dept table, we must include either the attribute values for the department that the employee works for, or nulls (if the employee does not work for a department as yet). For example to insert a new tuple for an employee who works in department no 5, we must enter the attribute values of department number 5 correctly so that they are consistent, with values for the department 5 in other tuples in emp_dept.

Second Instance: - It is difficult to insert a new department that has no employees as yet in the emp_dept relation. The only way to do this is to place null values in the attributes for the employee this causes a problem because SSN in the primary key of emp_dept table and each tuple is supposed to represent an employee entity- not a department entity.

Moreover, when the first employee is assigned to that department, we do not need this tuple with null values anymore.

Deletion Anomalies

A "deletion anomaly" is a failure to remove information about an existing database entry when it is time to remove that entry. In a properly normalized database, information about an old, to-be-gotten-rid-of entry needs to be deleted from only one place in the database; in an inadequately normalized database, information about that old entry may need to be deleted from more than one place, and, human fallibility being what it is, some of the needed additional deletions may be missed.

The problem of deletion anomaly is related to the second insertion anomaly situation, if we delete from emp_dept an employee tuple that happens to represent the last employee working for a particular department, the information concerning that department is lost from the database.

Modification Anomalies

In Emp_Dept, if we change the value of one of the attribute of a particular department- say, the manager of department 5-we must update the tuples of all employees who work in that department; other wise, the database will become inconsistent. If we fail to update some tuples, the same department will be shown to have 2 different values for manager in different employee tuple which would be wrong.

All three kinds of anomalies are highly undesirable, since their occurrence constitutes corruption of the database. Properly normalized databases are much less susceptible to corruption than are unnormalized databases.

Update Anomalies --- Redundant information not only wastes storage but makes updates more difficult since, for example, changing the name of the instructor of CP302 would require that all tuples containing CP302 enrolment information be updated. If for some reason, all tuples are not updated, we might have a database that gives two names of instructor for subject CP302. This difficulty is called the update anomaly.

Insertional Anomalies -- Inability to represent certain information --- Let the primary key of the above relation be (sno, cno). Any new tuple to be inserted in the relation must have a value for the primary key since existential integrity requires that a key may not be totally or partially NULL. However, if one wanted to insert the number and name of a new course in the database, it would not be possible until a student enrols in the course and we are able to insert values of sno and cno. Similarly information about a new student cannot be inserted in the database until the student enrols in a subject. These difficulties are called insertion anomalies.

Deletion Anomalies -- Loss of Useful Information --- In some instances, useful information may be lost when a tuple is deleted. For example, if we delete the tuple corresponding to student 85001 doing CP304, we will loose relevant information about course CP304 (viz. course name, instructor, office number) if the student 85001 was the only student enrolled in that course. Similarly deletion of course CP302 from the database may remove all information about the student named Jones. This is called deletion anomalies.

Normalization

Normalization is a formal process for determining which fields belong in which tables in a relational database. Normalization follows a set of rules worked out at the time relational databases were born. A normalized relational database provides several benefits:

Elimination of redundant data storage.

Close modeling of real world entities, processes, and their relationships.

Structuring of data so that the model is flexible.

Normalization ensures that you get the benefits relational databases offer. Time spent learning about normalization will begin paying for itself immediately.

Normalized Design: Pros and Cons

There are various advantages to producing a properly normalized design before you implement your system. A detailed list of the pros and cons are given below:

Pros of Normalizing Cons of normalizing

More efficient database structure.

Better understanding of your data.

More flexible data structure.

Easier to maintain database structure.

Few (if any) costly surprises down the road.

Validates your common sense and intuition. Avoid redundant fields.

Ensures that distinct tables exist when necessary.

You can’t start building the database before you know what the user needs.

1st Normal Form (1NF)

Def: A table (relation) is in 1NF if

1. There are no duplicated rows in the table.

2. Each cell is single-valued (i.e., there are no repeating groups).

3. Entries in a column (attribute, field) are of the same kind.

Note: The order of the rows is immaterial; the order of the columns is immaterial. The requirement that there be no duplicated rows in the table means that the table has a key (although the key might be made up of more than one column—even, possibly, of all the columns).

A relation is in 1NF if and only if all underlying domains contain atomic values only.

The first normal form deals only with the basic structure of the relation and does not resolve the problems of redundant information or the anomalies.

For example consider the following example relation:

student(sno, sname, dob) Add some other attributes so it has anomalies and is not in 2NF

The attribute dob is the date of birth and the primary key of the relation is sno with the functional dependencies sno -> sname and eno → dob The relation is in 1NF as long as dob is considered an atomic value and not consisting of three components (day, month, year). The above relation of course suffers from all the anomalies and needs to be normalized. (add example with date of birth)

A relation is in first normal form if and only if, in every legal value of that relation every tuple contains one value for each attribute

The above definition merely states that the relations are always in first normal form which is always correct. However the relation that is only in first normal form has a structure those undesirable for a number of reasons.

First normal form (1NF) sets the very basic rules for an organized database:

• Eliminate duplicative columns from the same table.

• Create separate tables for each group of related data and identify each row with a unique column or set of columns (the primary key).

2nd Normal Form (2NF)

Def: A table is in 2NF if it is in 1NF and if all non-key attributes are dependent on the entire key.

The second normal form attempts to deal with the problems that are identified with the relation above that is in 1NF. The aim of second normal form is to ensure that all information in one relation is only about one thing.

A relation is in 2NF if it is in 1NF and every non-key attribute is fully dependent on each candidate key of the relation.

Note: Since a partial dependency occurs when a non-key attribute is dependent on only a part of the (composite) key, the definition of 2NF is sometimes phrased as, "A table is in 2NF if it is in 1NF and if it has no partial dependencies."

Recall the general requirements of 2NF:

• Remove subsets of data that apply to multiple rows of a table and place them in separate rows.

• Create relationships between these new tables and their predecessors through the use of foreign keys.

These rules can be summarized in a simple statement: 2NF attempts to reduce the amount of redundant data in a table by extracting it, placing it in new table(s) and creating relationships between those tables.

For example. Imagine an online store that maintains customer information in a database. Their Customers table might look something like this:

CustNum FirstName LastName Address City State ZIP

1 John Doe 12Main Street

Sea Cliff NY 11579

2 Alan Johnson 82 Evergreen Tr

Sea Cliff NY 11579

3 Beth Thompson 1912 NE Ist St

Miami FL 33157

4 Jacob Smith 142 Irish Way

South Bend

IN 46637

5 Sue Ryan 412 NE Ist St

Miami FL 33157

A brief look at this table reveals a small amount of redundant data. We're storing the "Sea Cliff, NY 11579" and "Miami, FL 33157" entries twice each. Now, that might not seem like too much added storage in our simple example, but imagine the wasted space if we had thousands of rows in our table. Additionally, if the ZIP code for Sea Cliff were to change, we'd need to make that change in many places throughout the database.

In a 2NF-compliant database structure, this redundant information is extracted and stored in a separate table. Our new table (let's call it ZIPs) might look like this:

ZIP City State11579 Sea Cliff NY33157 Miami FL46637 South Bend IN

If we want to be super-efficient, we can even fill this table in advance -- the post office provides a directory of all valid ZIP codes and their city/state relationships. Surely, you've encountered a situation where this type of database was utilized. Someone taking

an order might have asked you for your ZIP code first and then knew the city and state you were calling from. This type of arrangement reduces operator error and increases efficiency.

Now that we've removed the duplicative data from the Customers table, we've satisfied the first rule of second normal form. We still need to use a foreign key to tie the two tables together. We'll use the ZIP code (the primary key from the ZIPs table) to create that relationship. Here's our new Customers table:

CustNum FirstName LastName Address ZIP

1 John Doe 12Main Street

11579

2 Alan Johnson 82 Evergreen Tr

11579

3 Beth Thompson 1912 NE Ist St

33157

4 Jacob Smith 142 Irish Way

46637

5 Sue Ryan 412 NE Ist St 33157

We've now minimized the amount of redundant information stored within the database and the structure is in second normal form.

Let’s take one more example

The concept of 2NF requires that all attributes that are not part of a candidate key be fully dependent on each candidate key. If we consider the relation

student (sno, sname, cno, cname)

and the functional dependencies

eno → ename

cno -> cname

and assume that (sno, cno) is the only candidate key (and therefore the primary key), the relation is not in 2NF since sname and cname are not fully dependent on the key. The above relation suffers from the same anomalies and repetition of information, since sname and cname will be repeated. To resolve these difficulties we could remove those attributes from the relation that are not fully dependent on the candidate keys of the relations. Therefore we decompose the relation into the following projections of the original relation:

S1 (sno, sname) S2 (cno, cname) SC (sno, cno)

Use an example that leaves one relation in 2NF but not in 3NF. We may recover the original relation by taking the natural join of the three relations. If however we assume that sname and cname are unique and therefore we have the following candidate keys

(sno, cno) (sno, cname) (sname, cno) (sname, cname)

The above relation is now in 2NF since the relation has no non-key attributes. The relation still has the same problems as before but it then does satisfy the requirements of 2NF. Higher level normalization is needed to resolve such problems with relations that are in 2NF and further normalization will result in decomposition of such relations

3rd Normal Form (3NF)

Def: A table is in 3NF if it is in 2NF and if it has no transitive dependencies.

The basic requirements of 3NF are as follows • Meet the requirements of 1NF and 2NF • Remove columns that are not fully dependent upon the primary key.

Although transforming a relation that is not in 2NF into a number of relations that are in 2NF removes many of the anomalies that appear in the relation that was not in 2NF, not all anomalies are removed and further normalization is sometime needed to ensure further removal of anomalies. These anomalies arise because a 2NF relation may have attributes that are not directly related to the thing that is being described by the candidate keys of the relation.

A relation R is in third normal form if it is in 2NF and every non-key attribute of R is non-transitively dependent on each candidate key of R.

To understand the third normal form, we need to define transitive dependence which is based on one of Armstrong's axioms. Let A, B and C be three attributes of a relation R such that

A→ B and B→ C

From these FDs, we may derive A→ C , this dependence A→ C is transitive.

The 3NF differs from the 2NF in that all non-key attributes in 3NF are required to be directly dependent on each candidate key of the relation. The 3NF therefore insists, in the words of Kent (1983) that all facts in the relation are about the key (or the thing that the key identifies), the whole key and nothing but the key. If some attributes are dependent on the keys transitively then that is an indication that those attributes provide information not about the key but about a non-key attribute. So the information is not directly about the key, although it obviously is related to the key.

Consider the following relation

subject (cno, cname, instructor, office)

Assume that cname is not unique and therefore cno is the only candidate key. The following functional dependencies exist

Eno → enameEno → instructorInstructor → office

We can derive Eno → office from the above functional dependencies and therefore the above relation is in 2NF. The relation is however not in 3NF since office is not directly dependent on cno. This transitive dependence is an indication that the relation has information about more than one thing (viz. course and instructor) and should therefore be decomposed. The primary difficulty with the above relation is that an instructor might be responsible for several subjects and therefore his office address may need to be repeated many times. This leads to all the updation problems. To overcome these difficulties we need to decompose the above relation in the following two relations:

s (cno, cname, instructor)

ins (instructor, office)

s is now in 3NF and so is ins.

An alternate decomposition of the relation subject is possible:

s(cno, cname)

inst(instructor, office)

si(cno, instructor)

The decomposition into three relations is not necessary since the original relation is based on the assumption of one instructor for each course.

The 3NF is usually quite adequate for most relational database designs. There are however some situations, for example the relation student(sno, sname, cno, cname) is in 2NF above, where 3NF may not eliminate all the redundancies and inconsistencies. The problem with the relation student(sno, sname, cno, cname) is because of the redundant information in the candidate keys. These are resolved by further normalization using the BCNF.

Imagine that we have a table of widget orders:

Order Number Customer Number

Unit Price Quantity Total

1 241 $10 2 $20

2 842 $9 20 $180

3 919 $19 1 $19

4 919 $12 10 $120

Remember, our first requirement is that the table must satisfy the requirements of 1NF and 2NF. Are there any duplicative columns? No. Do we have a primary key? Yes, the order number. Therefore, we satisfy the requirements of 1NF. Are there any subsets of data that apply to multiple rows? No, so we also satisfy the requirements of 2NF.

Now, are all of the columns fully dependent upon the primary key? The customer number varies with the order number and it doesn't appear to depend upon any of the other fields.

What about the unit price? This field could be dependent upon the customer number in a situation where we charged each customer a set price. However, looking at the data above, it appears we sometimes charge the same customer different prices. Therefore, the unit price is fully dependent upon the order number. The quantity of items also varies from order to order.

What about the total? It looks like we might be in trouble here. The total can be derived by multiplying the unit price by the quantity; therefore it's not fully dependent upon the primary key. We must remove it from the table to comply with the third normal form:

Order Number Customer Number Unit Price Quantity

1 241 $10 2

2 842 $9 20

3 919 $19 1

4 919 $12 10

Now our table is in 3NF.

Boyce-Codd Normal Form (BCNF)

The relation student(sno, sname, cno, cname) has all attributes participating in candidate keys since all the attributes are assumed to be unique. We therefore had the following candidate keys:

(sno, cno)

(sno, cname)

(sname, cno)

(sname, cname)

Since the relation has no non-key attributes, the relation is in 2NF and also in 3NF, in spite of the relation suffering the modification problems.

The difficulty in this relation is being caused by dependence within the candidate keys. The second and third normal forms assume that all attributes not part of the candidate keys depend on the candidate keys but does not deal with dependencies within the keys. BCNF deals with such dependencies.

A relation R is said to be in BCNF if whenever X → A holds in R, and A is not in X, then X is a candidate key for R.

It should be noted that most relations that are in 3NF are also in BCNF. Infrequently, a 3NF relation is not in BCNF and this happens only if

(a) the candidate keys in the relation are composite keys (that is, they are not single attributes),

(b) there is more than one candidate key in the relation, and (c) the keys are not disjoint, that is, some attributes in the keys are common.

The BCNF differs from the 3NF only when there are more than one candidate keys and the keys are composite and overlapping. Consider for example, the relationship

enrol (sno, sname, cno, cname, date-enrolled)

Let us assume that the relation has the following candidate keys:

(sno, cno)

(sno, cname)

(sname, cno)

(sname, cname)

(we have assumed sname and cname are unique identifiers). The relation is in 3NF but not in BCNF because there are dependencies

sno → snameeno → ename

where attributes that are part of a candidate key are dependent on part of another candidate key. Such dependencies indicate that although the relation is about some entity or association that is identified by the candidate keys e.g. (sno, cno), there are attributes that are not about the whole thing that the keys identify. For example, the above relation is about an association (enrolment) between students and subjects and therefore the relation needs to include only one identifier to identify students and one identifier to identify subjects. Providing two identifiers about students (sno, sname) and two keys about subjects (cno, cname) means that some information about students and subjects that is not needed is being provided. This provision of information will result in repetition of information and the anomaliess. If we wish to include further information about students and courses in the database, it should not be done by putting the information in the present relation but by creating new relations that represent information about entities student and subject.

These difficulties may be overcome by decomposing the above relation in the following three relations:

(sno, sname)

(cno, cname)

(sno, cno, date-of-enrolment)

We now have a relation that only has information about students, another only about subjects and the third only about enrolments. All the anomalies and repetition of information have been removed.

So, a relation is said to be in the BCNF if and only if it is in the 3NF and every non-trivial, left-irreducible functional dependency has a candidate key as its determinant. In more informal terms, a relation is in BCNF if it is in 3NF and the only determinants are the candidate keys.

Desirable properties of decompositions

So far our approach has consisted of looking at individual relations and checking if they belong to 2NF, 3NF or BCNF. If a relation was not in the normal form that was being checked for and we wished the relation to be normalized to that normal form so that some of the anomalies can be eliminated, it was necessary to decompose the relation in two or more relations. The process of decomposition of a relation R into a set of relations R1,R2,…..Rn was based on identifying different components and using that as a basis of decomposition. The decomposed relations R1,R2,…..Rn are projections of R and are of course not disjoint otherwise the glue holding the information together would be lost. Decomposing relations in this way based on a recognize and split method is not a particularly sound approach since we do not even have a basis to determine that the original relation can be constructed if necessary from the decomposed relations.

Desirable properties of decomposition are:

1. Attribute preservation

2. Lossless-join decomposition

3. Dependency preservation

4. Lack of redundancy

Attribute Preservation

This is a simple and an obvious requirement that involves preserving all the attributes that were there in the relation that is being decomposed.

Lossless-Join Decomposition

We decomposed a relation intuitively. We need a better basis for deciding decompositions since intuition may not always be correct. We illustrate how a careless decomposition may lead to problems including loss of information.

Consider the following relation

enrol (sno, cno, date-enrolled, room-No., instructor)

Suppose we decompose the above relation into two relations enrol1 and enrol2 as follows

enrol1 (sno, cno, date-enrolled)

enrol2 (date-enrolled, room-No., instructor)

There are problems with this decomposition but we wish to focus on one aspect at the moment. Let an instance of the relation enrol be

Sno Cno Date-Enrolled Room-no. Instructor830057830057820159825678826789

CP302CP303CP302CP304CP305

1FEB19841FEB198410JAN19841FEB198415JAN1984

MP006MP006MP006CE122EA123

GuptaJonesGuptaWilsonSmith

and let the decomposed relations enrol1 and enrol2 be:

Sno Cno Date-Enrolled830057830057820159825678826789

CP302CP303CP302CP304CP305

1FEB19841FEB198410JAN19841FEB198415JAN1984

Date-Enrolled Room-no. Instructor1FEB19841FEB198410JAN19841FEB198415JAN1984

MP006MP006MP006CE122EA123

GuptaJonesGuptaWilsonSmith

All the information that was in the relation enrol appears to be still available in enrol1 and enrol2 but this is not so. Suppose, we wanted to retrieve the student numbers of all students taking a course from Wilson, we would need to join enrol1 and enrol2. The join would have 11 tuples as follows:

Sno Cno Date-Enrolled Room-No. Instructor830057830057830057830057830057830057

CP302CP302CP303CP303CP302CP303

1FEB19841FEB19841FEB19841FEB19841FEB19841FEB1984

MP006MP006MP006MP006CE122CE122

GuptaJonesGuptaJonesWilsonWilson

(add further tuples ...)

The join contains a number of spurious tuples that were not in the original relation Enrol. Because of these additional tuples, we have lost the information about which students take courses from WILSON. (we have more tuples but less information because we are unable to say with certainty who is taking courses from WILSON). Such decompositions are called lossy decompositions.

A nonloss or lossless decomposition is that which guarantees that the join will result in exactly the same relation as was decomposed.

We need to analyze why some decompositions are lossy. The common attribute in above decompositions was Date-enrolled. The common attribute is the clue that gives us the ability to find the relationships between different relations by joining the relations together. If the common attribute is not unique, the relationship information is not preserved. If each tuple had a unique value of Date-enrolled, the problem of losing information would not have existed. The problem arises because several enrolments may take place on the same date.

A decomposition of a relation R into relations R1,R2,…..Rn is called a lossless-join decomposition (with respect to FDs F) if the relation R is always the natural join of the relations R1,R2,…..Rn It should be noted that natural join is the only way to recover the relation from the decomposed relations. There is no other set of operators that can recover the relation if the join cannot. Furthermore, it should be noted when the decomposed relations R1,R2,…..Rn are obtained by projecting on the relation R, for example R1 by projection π(R) the relation R1 may not always be precisely equal to the projection since the relation R1 might have additional tuples called the dangling tuples.

It is not difficult to test whether a given decomposition is lossless-join given a set of functional dependencies F. We consider the simple case of a relation R being decomposed into R1 and R2 . the decomposition is lossless-join, then one of the following two conditions must hold

R1 ∩ R2 → R1– R2

R1 ∩ R2 → R2 – R1

That is, the common attributes in R1 and R2 must include a candidate key of either R1 or R2.

Dependency Preservation

It is clear that decomposition must be lossless so that we do not lose any information from the relation that is decomposed. Dependency preservation is another important requirement since a dependency is a constraint on the database and if X → Y holds than we know that the two (sets) attributes are closely related and it would be useful if both attributes appeared in the same relation so that the dependency can be checked easily.

Let us consider a relation R(A, B, C, D) that has the dependencies F that include the following:

A→ BA → C

etc

If we decompose the above relation into R1(A, B) and R2(B, C, D) the dependency A→C cannot be checked (or preserved) by looking at only one relation. It is desirable that decompositions be such that each dependency in F may be checked by looking at only one relation and that no joins need be computed for checking dependencies. In some cases, it may not be possible to preserve each and every dependency in F but as long as the dependencies that are preserved are equivalent to F, it should be sufficient.

Let F be the dependencies on a relation R which is decomposed in relations R1,R2,….,Rn.

We can partition the dependencies given by F such that F1,F2,….,Fn. Fn are dependencies that only involve attributes from relations R1,R2,….,Rn. If the union of dependencies F1

imply all the dependencies in F, then we say that the decomposition has preserved dependencies, otherwise not.

If the decomposition does not preserve the dependencies F, then the decomposed relations may contain relations that do not satisfy F or the updates to the decomposed relations may require a join to check that the constraints implied by the dependencies still hold.

Consider the following relation

sub(sno, instructor, office)

We may wish to decompose the above relation to remove the transitive dependency of office on sno. A possible decomposition is

S1(sno, instructor)

S2(sno, office)

The relations are now in 3NF but the dependency instructor → office cannot be verified by looking at one relation; a join of S1 and S2 is needed. In the above decomposition, it is quite possible to have more than one office number for one instructor although the functional dependency instructor → office does not allow it.

Lack of Redundancy

Lossless-join, dependency preservation and lack of redundancy not always possible with BCNF. Lossless-join, dependency preservation and lack of redundancy is always possible with 3NF.

Deriving BCNF

Given a set of dependencies F, we may decompose a given relation into a set of relations that are in BCNF using the following algorithm. The algorithm consists of

(1) Find out the facts about the real world. (2) Reduce the list of functional relationships. (3) Find the keys. (4) Combine related facts.

If there is any relation R that has a dependency A→ B and A is not a key, the relation violates the conditions of BCNF and may be decomposed in AB and R - A. The relation AB is now in BCNF and we can now check if R - A is also in BCNF. If not, we can apply the above procedure again until all the relations are in fact in BCNF.

Multivalued dependencies

Several difficulties that can arise when an entity has multivalue attributes. It was because in the relational model, if all of the information about such entity is to be represented in one relation, it will be necessary to repeat all the information other than the multivalue attribute value to represent all the information that we wish to represent. This results in many tuples about the same instance of the entity in the relation and the relation having a composite key (the entity id and the mutlivalued attribute). Of course the other option suggested was to represent this multivalue information in a separate relation.

The situation of course becomes much worse if an entity has more than one multivaluedattributes and these values are represented in one relation by a number of tuples for eachentity instance such that every value of one the multivalued attributes appears with everyvalue of the second multivalued attribute to maintain consistency. The multivalued dependency relates to this problem when more than one multivalued attributes exist.

Consider the following relation that represents an entity employee that has onemutlivalued attribute proj:

emp (e#, dept, salary, proj)

normalization upto BCNF are based on functional dependencies; dependencies that apply only to single-valued facts. For example, e#→ dept implies only one dept value for each value of e#. Not all information in a database is single-valued, for example, proj in an employee relation may be the list of all projects that the employee is currently working on. Although e# determines the list of all projects that an employee is working on, eno→ proj is not a functional dependency.

Multivalued facts about an entity is represented by having a separate relation for that multivalue attribute and then inserting a tuple for each value of that fact. This resulted in composite keys since the multivalued fact must form part of the key.

The fourth and fifth normal forms deal with multivalued dependencies.

programmer (emp_name, qualifications, languages)

The above relation includes two multivalued attributes of entity programmer; qualifications and languages. There are no functional dependencies.

The attributes qualifications and languages are assumed independent of each other. If we

were to consider qualifications and languages separate entities, we would have two relationships (one between employees and qualifications and the other between employees and programming languages). Both the above relationships are many-to-manyi.e. one programmer could have several qualifications and may know several programming languages. Also one qualification may be obtained by several programmersand one programming language may be known to many programmers.

The above relation is therefore in 3NF (even in BCNF) but it still has some disadvantages. Suppose a programmer has several qualifications (B.Sc, Dip. Comp. Sc,etc) and is proficient in several programming languages; how should this information berepresented? There are several possibilities.

Cmp name Qualifications LanguagesSmithSmithSmithSmithSmithSmith

B.ScB.Sc B.ScDip. CSDip. CSDip. CS

FortranCobolPascalFortranCobolPascal

Cmp Name Qualification LanguageSmithSmithSmithSmithSmith

B.ScDip. CSNULLNULLNULL

NULLNULLFortranCobolPascal

Cmp Name Qualificatiom LanguageSmithSmithSmith

B.ScDip CSNULL

FortranCobolPascal

Other variations are possible (there is no relationship between qualifications and programming languages). All these variations have some disadvantages. If the information is repeated we face the same problems of repeated information and anomalies as we did when second or third normal form conditions are violated. If there is no repetition, there are still some difficulties with search, insertions and deletions. For example, the role of NULL values in the above relations is confusing.Also the candidate key in the above relations is (emp name, qualifications, language) andexistential integrity requires that no NULLs be specified. These problems may be overcome by decomposing a relation like the one above as follows:

Cmp Name QualificationsSmithSmith

B.ScDip. CS

Cmp Name LanguagesSmithSmithSmith

FortranCobolPascal

The basis of the above decomposition is the concept of multivalued dependency (MVD).Functional dependency A→ B relates one value of A to one value of B while multivalueddependency A→→ B defines a relationship in which a set of values of attribute B are determined by a single value of A.The concept of multivalued dependencies was developed to provide a basis for decomposition of relations like the one above. Therefore if a relation like enrolment(sno,subject#) has a relationship between sno and subject# in which sno uniquely determinesthe values of subject#, the dependence of subject# on sno is called a trivial MVD sincethe relation enrolment cannot be decomposed any further. More formally, a MVD X→→Y is called trivial MVD if either Y is a subset of X or X and Y together form therelation R. The MVD is trivial since it results in no constraints being placed on therelation. Therefore a relation having non-trivial MVDs must have at least three attributes;two of them multivalued. Non-trivial MVDs result in the relation having some constraintson it since all possible combinations of the multivalue attributes are then required to be inthe relation.Let us now define the concept of multivalued dependency. The multivalued dependency X→→Y is said to hold for a relation R(X, Y, Z) if for a given set of value (set of values ifX is more than one attribute) for attributes X, there is a set of (zero or more) associatedvalues for the set of attributes Y and the Y values depend only on X values and have nodependence on the set of attributes Z.

In the example above, if there was some dependence between the attributes qualificationsand language, for example perhaps, the language was related to the qualifications(perhaps the qualification was a training certificate in a particular language), then therelation would not have MVD and could not be decomposed into two relations as abve. Inthe above situation whenever X→→Y holds, so does X→→Z since the role of theattributes Y and Z is symmetrical.

Consider two different situations.(a) Z is a single valued attribute. In this situation, we deal with R(X, Y, Z) as before byentering several tuples about each entity.(b) Z is multivalued.Now, more formally, X→→Y is said to hold for R(X, Y, Z) if t1 and t2 are two tuples in Rthat have the same values for attributes X and therefore with t1[x] = t2[x] then R also

contains tuples t3 and t4 (not necessarily distinct) such that

t1[x] = t2[x] = t3[x] = t4[x]t3[Y] = t1[Y] and t3[Z] = t2[Z]t4[Y] = t2[Y] and t4[Z] = t1[Z]

In other words if t1 and t2 are given byt1 = [X, Y1, Z1], andt2 = [X, Y2, Z2]

then there must be tuples t3 and t4 such thatt3 = [X, Y1, Z2], andt4 = [X, Y2, Z1]

We are therefore insisting that every value of Y appears with every value of Z to keep the relation instances consistent. In other words, the above conditions insist that Y and Z are determined by X alone and there is no relationship between Y and Z since Y and Z appear in every possible pair and hence these pairings present no information and are of no significance. Only if some of these pairings were not present, there would be some significance in the pairings.

Give example (instructor, quals, subjects) --- explain if subject was single valued; otherwise all combinations must occur.

(Note: If Z is single-valued and functionally dependent on X then Z1 = Z2. If Z is multivalue dependent on X then Z1 <> Z2).

The theory of multivalued dependencies in very similar to that for functional dependencies. Given D a set of MVDs, we may find D+, the closure of D using a set of axioms.

Multivalued Normalization --- Fourth Normal Form

Def: A table is in 4NF if it is in BCNF and if it has no multi-valued dependencies.

An example of Programmer(Emp name, qualification, languages) and problems that may arise if the relation is not normalised further. The relation could be decomposed into P1(Emp name, qualifications) and P2(Emp name, languages) to overcome these problems. The decomposed relations are in fourth normal form (4NF).

A relation R is in 4NF if, whenever a multivalued dependency X→ Y holds then either

(a) the dependency is trivial, or (b) X is a candidate key for R.

The dependency X→→ Y in a relation R(X, Y) is trivial since they must hold for all R(X, Y). Similarly (X,Y) →Z must hold for all relations R(X, Y, Z) with only three attributes.

In fourth normal form, we have a relation that has information about only one entity. If a relation has more than one multivalue attribute, we should decompose it to remove difficulties with multivalued facts.

Intuitively R is in 4NF if all dependencies are a result of keys. When multivalued dependencies exist, a relation should not contain two or more independent multivalued attributes. The decomposition of a relation to achieve 4NF would normally result in not only reduction of redundancies but also avoidance of anomalies.

Fifth Normal Form

Def: A table is in 5NF, also called "Projection-Join Normal Form" (PJNF), if it is in 4NF and if every join dependency in the table is a consequence of the candidate keys of the table.

The normal forms discussed so far required that the given relation R if not in the given normal form be decomposed in two relations to meet the requirements of the normal form. In some rare cases, a relation can have problems like redundant information and update anomalies because of it but cannot be decomposed in two relations to remove the problems. In such cases it may be possible to decompose the relation in three or more relations using the 5NF.

The fifth normal form deals with join-dependencies which is a generalisation of the MVD. The aim of fifth normal form is to have relations that cannot be decomposed further. A relation in 5NF cannot be constructed from several smaller relations.

A relation R satisfies join dependency (R1,R2,…..,Rn) if and only if R is equal to the join of R1,R2,….,Rn where Ri are subsets of the set of attributes of R.

A relation R is in 5NF (or project-join normal form, PJNF) if for all join dependencies at least one of the following holds.

(a) (R1,R2,…..,Rn) is a trivial join-dependency (that is, one of Ri is R)

(b) Every Ri is a candidate key for R.

An example of 5NF can be provided by the example below that deals with departments, subjects and students.

Dept Subject Student

Comp Sc.

Mathematics

Comp Sc.

Comp Sc.

Physics

Chemistry

CP1000

MA1000

CP2000

CP3000

PH1000

CH2000

John Smith

John Smith

Arun Kumar

Reena Rani

Raymond Chew

Albert Garcia

The above relation says that Comp. Sc. offers subjects CP1000, CP2000 and CP3000 which are taken by a variety of students. No student takes all the subjects and no subject has all students enrolled in it and therefore all three fields are needed to represent the information.

The above relation does not show MVDs since the attributes subject and student are not independent; they are related to each other and the pairings have significant information in them. The relation can therefore not be decomposed in two relations

(dept, subject), and

(dept, student)

without loosing some important information. The relation can however be decomposed in the following three relations

(dept, subject), and

(dept, student)

(subject, student)

and now it can be shown that this decomposition is lossless.

Domain-Key Normal Form (DKNF)

Def: A table is in DKNF if every constraint on the table is a logical consequence of the definition of keys and domains.