Unit – 2

Part -1:
Relational database model: Topics
• Logical view of data,
• keys,
• Integrity rules,
• Relational Database design: features of good relational
database design, atomic domain
• Normalization (1NF, 2NF, 3NF, BCNF).
Relational Database Model
• E.F.codd first proposed the relational database Model also he is
known as the father of Relational model.
• The relational model is set of 2 dimensional table consists of rows and
columns.
• Tables in the database is known as relation and Columns in the table
are called the attributes of a tables and rows in the table are called
records or tuples
• The relational database model consists of set of tables having the
unique name
LOGICAL VIEW OF DATA:
Introduction:
• Logical structure of tables is consist of 2- dimensional tables consist of
numbers of horizontal rows and vertical columns
• Table is an abstract entity which does not say how the data is stored
in the physical memory of the computer system
• Each table in the database has its own unique name through which
we can refer the content of the table by the unique name
Characteristics of a Table
Example of Table
There is Customer Table contain all information about the Customer
• Cust_id, Cust_Name, Cust_Age, Cust_Address, Cust_Mobile_No,
Cust_Phone_No
Attribute of the Table
• Each column in the above table represent the data item in the
database
• Each column in the table represent the attribute in the table
• The table consists of atleast one column.
• No two columns has the same name in the same table ,it is possible
to have two column with same column name but in the different
tables.
• The ANSI/SQL Standard does not specify a maximum numbers of
rows and columns in the table.
Records/Tuples
• A single Record consist all the information of the single entity.
• Each horizontal row in the Customer table represented a single entity
• A table consists of any number of rows, The ANSI/SQL Standard does
not specify the limits of rows in the table.
• Empty table - when there is zero row consist in the table
Keys
• A Column value in the table that uniquely identifies each single record
in the table is called key of an table
• Consist of one or more attributes that determine other attributes.

Used to:
• Ensure that each row in a table is uniquely identifiable
• Establish relationships among tables and to ensure the integrity of
the data
Keys
An Example of a Simple Relational Database
 SQL - Create Table statement
• CREATE TABLE VENDOR (
ven_code numeric(10),
vend_contact varchar2(50) DEFAULT ‘HelpDesk’,
vend_areacode numeric(10) NOT NULL,
vend_phone numeric(10),
CONSTRAINT vend_pk PRIMARY KEY (ven_code ) );
• CREATE TABLE PRODUCT(
PROD_CODE numeric(10) NOT NULL,
PROD_DESCRIPT varchar2(50) NOT NULL,
PROD_PRICE numeric(5,2) DEFAULT =00.00,
PROD_ON_HAND numeric(5) CHECK (PROD_ON_HAND >0),
V_code numeric(10),
CONSTRAINT pk_prod PRIMARY KEY (PROD_CODE),
CONSTRAINT fk_vc FOREIGN KEY (V_code) REFERENCES
VENDOR(vend_code) );
 Integrity Constraint/Rules
• Integrity constraints are a set of rules. It is used to maintain the quality of information.
• Integrity constraints ensure that the data insertion, updating, and other processes have
to be performed in such a way that data integrity is not affected.
• Thus, integrity constraint is used to guard against accidental damage to the database.
 Integrity Constraint/Rules
Domain Integrity
• Domain constraints can be defined as the definition of a valid set of values
for an attribute
• The data type of domain includes string, character, integer, time, date,
currency, etc. The value of the attribute must be available in the
corresponding domain
Integrity Constraint/Rules
Entity integrity
• The entity integrity constraint states that primary key value can't be null
• This is because the primary key value is used to identify individual rows in relation
and if the primary key has a null value, then we can't identify those rows
• A table can contain a null value other than the primary key field
Integrity Constraint/Rules
Referential Integrity
• A referential integrity constraint is specified between two tables
• In the Referential integrity constraints, if a foreign key in Table 1 refers
to the Primary Key of Table 2, then every value of the Foreign Key in
Table 1 must either be null or be available in Table 2
• For referential integrity to hold in a relational database, any field in a
table that is declared a foreign key can contain only values from a
parent table's primary key.
• For instance, deleting a record that contains a value referred to by a
foreign key in another table would break referential integrity.
Integrity Constraint/Rules
Referential Integrity
Key Constraints
• Constraints are the rules that are to be followed while entering data into columns of the
database table
• Constraints ensure that data entered by the user into columns must be within the criteria
specified by the condition
• For example, if you want to maintain only unique IDs in the employee table or if you want
to enter only age under 18 in the student table etc

• The main purpose of the foreign key is only those values are allowed in the present table
that will match to the primary key column of another table
Database Normalization
Normalization:
• Normalization is a process of organizing the data in database to avoid
data redundancy, insertion anomaly, update anomaly & deletion
anomaly.
• Database Normalization is a technique that helps in designing the
database in an optimal manner so as to ensure data integrity and
prevent data redundancy.
• Redundancy in relation may cause insertion, deletion
and updation anomalies.
• Anomalies are caused when there is too much redundancy in the
database's information and the tables are of poor design which
eventually leads to inconsistency in the database.
• The core idea of database normalization is to divide the tables into
smaller sub tables and links them using relationship.
 Anomalies in DBMS
• Example: Suppose a manufacturing company stores the employee details in a
table named employee that has four attributes:
• emp_id for storing employee’s id,
• emp_name for storing employee’s name,
• emp_address for storing employee’s address and
• emp_dept for storing the department details in which the employee works.
At some point of time the table looks like this:

- This table is not normalized.

- We will see the problems that we face,
when a table is not normalized.
Anomalies in DBMS
Update Anomaly:
• In the example, we have two rows for
employee Rick as he belongs to two
departments of the company.
• If we want to update the address of Rick
then we have to update the same in two
rows or the data will become inconsistent.
• If somehow, the correct address gets
updated in one department but not in
other then as per the database, Rick would
be having two different addresses, which is
not correct and would lead to inconsistent
data.
Anomalies in DBMS
Insert anomaly:
• Suppose a new employee joins the company, who is under
training and currently not assigned to any department then we
would not be able to insert the data into the table if emp_dept
field doesn’t allow nulls.
Delete anomaly:
Suppose, if at a point of time the company closes the department
D890 then deleting the rows that are having emp_dept as D890
would also delete the information of employee Maggie since she
is assigned only to this department.
Normalization Forms
To overcome these anomalies we need to normalize the data.
1st Normal Form (1NF)
• In this Normal Form, we tackle the problem of atomicity.
• In simple terms, a single cell cannot hold multiple values.
• If a table contains a composite or multi-valued attribute, it violates
the First Normal Form.
• A relation is in first normal form if it does not contain any composite
or multi-valued attribute.
• A relation is in first normal form if every attribute in that relation
is singled valued attribute.
1 Normal Form (1NF)
st

In the table, we can clearly see that

the Phone Number column has two
values.
Thus it violated the 1st NF.
Now if we apply the 1st NF to the above
table we get the below table as the
result.
Functional Dependency
• Functional Dependency between the attributes.
• A->B: attribute A determines B, B is functionally dependent on A (If value of A
is known, value of B can be determined)
• For eg. Student_Id -> Student_Name
• A->B, B->C : C is transitively dependant on A

• Prime Attribute:
• An attribute, which is a part of the prime-key, is known as a prime attribute.
• Non-prime attribute:
• An attribute, which is not a part of the prime-key, is said to be a non-prime
attribute.
2nd Normal Form (2NF)
• A table is said to be in 2NF if both the following conditions hold:
1. Table is in 1NF (First normal form)
2. No non-prime attribute is dependent on the proper subset of any candidate key
of table.
• To be in 2NF, all partial functional dependencies must be removed, i.e
every non-prime attribute should be fully functionally dependent on prime
key attribute.
• Partial functional dependencies occur when there is a composite primary
key and only one part of the key is needed to determine one or more other
attributes.
• Partial dependency can occurs only in tables with a composite key
• Partial dependencies can be corrected by removing those attributes to a
separate table whose primary key is just the portion of the key from the
original table
Example- 2nd NF
• Functional Dependency for Customer_Rental Table or Relation
Composite
Key

Step 1 : Primary key: Customer_No + Property_no

Step 2 : Full Functional Dependency:
(Customer_No+Property_No)->(Rent-Start, RentFinish)
Step3 Partial Dependency:
(Customer_No)-> Cust_Name
(Property_No)->(P_Address, Rent, Owner_No, Owner_Name)
Example- 2nd NF (Remove partial dependency)
Property Owner Table
Customer Table

Rental Table
Example- 2nd NF
1. Student_id + subject_id together forms a
? more meaningful primary key ( composite key).
2. Because - Student_id alone is not able to fetch
? data uniquely same way subject_id alone is also
not able to uniquely identify the data.

3. But the Teacher’s name only

depends upon subject_id, it has
nothing to do with student_id.
This is partial dependency.
Example- 2nd NF (Remove partial
dependency)
• To remove partial dependency, we will have to remove teacher
column from Score table
• We can add teachers to subject table or make separate table for
teacher and refer teacher_id wherever required.

Or
We have Three tables
We will add some
more information in
score table- Exam
Name, Total Marks

This is updated
Score table
3rd Normal Form (3NF)
• Third Normal form Based on the concept of transitive dependency.
• Transitive dependencies occurs when non key attributes are
functionally determined by other non-key attributes.
• A relation that is in 1NF and 2NF and in which no non-key attribute is
transitively dependent on the primary key.
• A table is in 3NF if it is in 2NF and it should not have transitive
dependency.
 Example - 3NF

• New column exam_name depends on

the primary key (student_id + • Total_marks doesn’t depends upon
subject_id) students or subject.
• For eg, a Mechanical student will have • Total_marks depends upon exam_name
Workshop exam but IT student won’t, • For eg, practical marks are of 40 or 50
for Jave we have practical exam etc marks, sessionals are of 30-40 marks,
• So, exam_name depends on student and main exams are of 60-70 marks.
subject both.
 Example - 3NF
Solution:

• When there is an attribute in the table which depends on some non-

prime attribute and not on the prime attributes.
• Solution is – take exam_name and total_marks and put them in a
separate table named- exam table
Example - 3NF

This table is in 2NF because its

primary key is not composite
However the table still has
anomalies.

This Professor table has Transitive Dependencies.

• (Prof. #)->(Dept Code)
• (Dept Code)-> (Dept Code, Dept Aide, Dept Fax#)
• All the attributes are known but only through a chain of inferences
• The anomalies can be resolved by removing the attributes determined by a non – key
attribute to a separate table.
Example - 3NF (After Removing Transitive Dependency)

After Removing Transitive Dependency

Normalization series
BCNF (Boyce-Codd Normal Form)
For a table to be in BCNF, it should satisfy two conditions-
• Table should be in the third normal form
• For any dependency A->B, A should be a super key.
• Which means, A can not be a non prime attribute with B being a prime attribute.
• BCNF doesn’t allow a non prime attribute to determine prime attribute.
• Until now we have seen, a non prime attribute can depends upon –
• Prime attributes (called functional dependency)
Or
• Part of primary key (called partial dependency)
Or
• Other non – prime attribute (called transitive dependency)
• But what if a non-prime attribute starts deriving a prime attributes-
(Violation of BCNF)
 Example- BCNF
Table holds below information-
- Student_id,
- Subject opted by the student, and
- The name of the professor assigned for tat
particulat student for a particular subject
Constraints-
• One student can enroll for multiple subjects
• For each subject a professor is assigned to the
student
• There can be multiple professors teaching one -This table satisfies 1-NF – as all the values are
subject atomic
• student_id + subject together forms the primary -This table also satisfies 2-NF as there is no
key partial dependency
• Also, as one professor teaches only one subject, we -This table also satisfies 3-NF as there is no
can use the professor column to find the subject transitive dependency
name as well. - But it doesn’t satisfy BCNF
 Example- BCNF
• You can see,
• Professor -> Subject (professor can leads us to subject)
• And subject is a part of primary key, hence it is a prime attribute
• While professor is a non prime attribute
• So, it doesn’t satisfy BCNF
Example- BCNF
Thank You!!!