Unit 4 Relational Database Design

Introduction:
• The goal of a relational database design is to generate a set of relation schemas that allows
us to store information without unnecessary redundancy, yet also us to retrieve information
easily.
• The table is basic building block in the database design process.
• A poor table structure degrades the performance of the RDBMS.
• So reorganization a poor table structure and producing a good table is based on
normalization.
• Normalization reduces data redundancies and helps to eliminate the data anomalies that
result from those redundancy.
 Redundancies and Anomalies

• Database Design Anomalies

• An anomaly is simply an error or inconsistency in the database.
• A poorly designed database runs the risk of introducing numerous anomalies.
• When designing a database, it may have anomalies, data redundancy or duplication inherent in it.
• We have to subject the design to Normalization process to obtain an efficient database design.
• There are three types of Design Anomalies:
• Update Anomalies
• Delete Anomalies and
• Insert Anomalies
 Update Anomaly

• Update Anomaly arises when there is duplication of data.

• So when data is updated at one place, but not at another places, the database
table is rendered ambiguous.
• Consider the following Order table. Suppose the salesman Bob is promoted to
Officer, all the previous entries on Bob should also be updated, or else,
ambiguity arises.
• This is due to faulty design: the field 'designation' does not belong to Order
table.
 Delete Anomaly

• Delete Anomaly occurs when certain field information is lost due to deletion
of other fields.
• Consider the following table. It records the students and course details.
• Now if Clarina pass out of the class, and the record is deleted, it also deletes
the information that CourseID for Chemistry is 233!
• This is deletion anomaly. To rectify this defect, we should remove the student
name and course name fields from this table; they do not belong here!
 Insert Anomaly

• Insert Anomaly is when we are unable to insert a piece of information unless some other piece is also
present.
• This is an exact opposite of Delete Anomaly. Consider the same table.
• We cannot insert course Algebra (CourseID = 241), unless Daniel (StudentID = 10664) enrolls for
that course!
 Functional Dependency
• It is a relationship that exists when one attributes uniquely determine another
attributes.
• A functional dependency occurs when one attribute in a relation uniquely
determines another attribute.
• This can be written A -> B which would be the same as stating "B is functionally
dependent upon A."
• A dependency occurs in a database when information stored in the same database
table uniquely determines other information stored in the same table.
Determinant X Y Dependency Attributes
i.e. X Determines Y , Y is Determines by X or Y dependency on X

SID Name Valid SID Name Valid

1 Sangita 1 Sangita
2 Sangita 1 Sangita

SID Name SID Name UnValid

Valid
1 Sangita 1 Sangita
2 Rojina 1 Rojina
 Example:
Employee number Employee Name Salary City
1 Dana 50000 San Francisco
2 Francis 38000 London
3 Andrew 25000 Tokyo

In this example, if we know the value of Employee number, we can

obtain Employee Name, city, salary, etc.
By this, we can say that the city, Employee Name, and salary are
functionally depended on Employee number.
A functional dependency is denoted by an arrow →
The functional dependency of X on Y is represented by X →Y
 Trivial and non trivial Dependency
• A trivial functional dependency is a special case of functional dependency where the
dependency is considered obvious or trivial. It occurs when an attribute is functionally
dependent on a subset of attributes that includes itself.
• In other words, if attribute A is functionally dependent on attribute B, and B is a subset of
A, then the dependency A → B is considered trivial.
• Example : {Eid,Pno}Eid or {Eid.Pno}Pno
• A non-trivial functional dependency is a functional dependency that provides valuable and
non-obvious information about the relationships between attributes in a table.
• Eg. EidName, EidAddress, Eid Post, EidSalary
 Full Functional Dependency
• A full functional dependency occurs when you already meet the requirements
for a functional dependency and the set of attributes on the left side of the
functional dependency statement cannot be reduced any farther.
• ABC D Let D be the non prime key attribute and value of D
completely dependent upon all the prime key attributes.
• Then D is said to be fully functional depednet on prime key ABC
• But D cannot dependents on any subset of ABC.
Example
Student
SID Name IDProf Grade
101 Sushma P1 4
102 Rojina P2 3.6
103 Pinky P3 3.8
 Normalization
• Normalization is a database design technique that reduces data redundancy
and eliminates undesirable characteristics like Insertion, Update and Deletion
Anomalies. Normalization rules divides larger tables into smaller tables and
links them using relationships. The purpose of Normalisation in SQL is to
eliminate redundant (repetitive) data and ensure data is stored logically.
• The data in the database can be considered to be in one of a number of `normal forms'. Basically the
normal form of the data indicates how much redundancy is in that data. The normal forms have a strict
ordering:
• 1. 1st Normal Form
• 2. 2nd Normal Form
• 3. 3rd Normal Form
• 4. BCNF
• 5. 4th NF
• 6. 5th NF
• There are other normal forms, such as 4th and 5th normal forms. They are rarely utilized in system design
and are not considered further here.
 First Normal Form
• First normal form (1NF) deals with the `shape' of the record type
• A relation is in 1NF if, and only if, it contains no repeating attributes or groups of attributes.
• Example: The Student table with the repeating group is not in 1NF
• It has repeating groups, and it is called an `unnormalised table
 2NF
• A relation is said to be in 2NF if and only if
• It is already in 1NF
• Every non-prime attribute is fully dependent on the primary key of the
relation.
 3NF
• A relation is said to be in 3NF if and only if
• It is already in 2NF
• No non-prime attribute is transitively dependent on the primary key of the
relation.
BCNF