21ISE37A – DATABASE MANAGEMENT SYSTEMS

Module – 2

Relational data Model and Language: Relational data model concepts,

Logical view of data, keys, integrity rules. integrity constraints: entity
integrity, referential integrity, Keys constraints, Domain constraints.
Functional dependencies, features of good relational database design,
atomic domain and Normalization (1NF, 2NF, 3NF, BCNF).
 Relational data model concepts:
• The relational data model represents the
database as a collection of relations.

• Each relation resembles a table of values.

• For example, the database of files that was

shown in Figure 1.2 is similar to the basic
relational model representation.
 Relational data model concepts:
• When a relation is thought of as a table of values, each row in the table represents a collection of related
data values.

• The table name and column names are used to help to interpret the meaning of the values in each row. For
example, the first table of Figure 1.2 is called STUDENT because each row represents facts about a particular
student entity.

• All values in a column are of the same data type.

• In the formal relational model terminology, a row is called a tuple, a column header is called an attribute,
and the table is called a relation. The data type describing the types of values that can appear in each column is
represented by a domain of possible values.
 Relational data model concepts:
• Figure 5.1 shows an example of a STUDENT relation.

• Each tuple in the relation represents a particular student entity (or object).

• NULL values represent attributes whose values are unknown or do not exist for some individual STUDENT
tuple.
 Relational data model concepts:
Domains, Attributes, Tuples, and Relations:

• Domain describes the data type and constraints of a column in a table. A domain defines the range of possible
values that a column can store in a database .

• For example, a column that stores user emails can have a domain of email addresses.

■ USA_phone_numbers. The set of ten-digit phone numbers valid in the India.

■ Aadhar_numbers. The set of valid nine-digit numbers.

 Relational data model concepts:
Denoting a relational model:
A relation schema R, denoted by R(A1, A2, … , An), is made up of a relation name R and a list of
attributes, A1, A2, … , An.
Degree of a relation R is = No. of attributes in R. A relation of degree seven, which stores
information about university students, would contain seven attributes describing each student as follows:
STUDENT(Name, Ssn, Home_phone, Address, Office_phone, Age, GPA)

Using the data type of each attribute, the definition is sometimes written as:
STUDENT(Name: string, Ssn: string, Home_phone: string, Address: string,
Office_phone: string, Age: integer, GPA: real)
 Relational data model concepts
Characteristics of Relations:
I. Ordering of Tuples in a Relation - A relation is defined as a set of tuples; i.e r = {t1, t2, … , tm}.

 In a relation, the rows shall be displayed in a certain order. For example, tuples in the STUDENT relation in
Figure 5.1 could be ordered by values of Name, Ssn, Age, or some other attribute. The relation displayed in
Figure 5.2 is considered identical to the one shown in Figure 5.1.
Characteristics of Relations:

II. Values and NULLs in the Tuples

 Each value in a tuple is an atomic value; that is, it is not divisible into components within the framework of
the basic relational model.

 Hence, composite and multivalued attributes are not allowed. This model is sometimes called the ‘flat
relational model’.

 An important concept is that of NULL values, which are used to represent the values of attributes that
may be unknown or may not apply to a tuple. A special value, called NULL, is used in these cases.

 For example, in Figure 5.1, some STUDENT tuples have NULL for their office phones because they do not
have an office (that is, office phone does not apply to these students).
INTEGRITY CONSTRAINTS
 INTEGRITY CONSTRAINTS
While modeling the design of the relational database, to maintain the data integrity, some
restrictions can be put like what values are allowed to be inserted in the relation, what kind of
modifications and deletions are allowed in the relation. These are the restrictions that can be
imposed on the relational database.
Types of Constraints:

I. Domain constraints

II. Key constraints

III. Entity Integrity constraints

IV. Referential integrity constraints

 INTEGRITY CONSTRAINTS
I. Domain constraints :

• Datatype check is to be done here, which means when we assign a data type to a column we limit the values that
it can contain. Eg. If we assign the datatype of attribute age as ‘int’, we can’t give it values other than ‘int’
datatype.
• Every domain must contain atomic values(smallest indivisible units) it means composite and multi-valued
attributes are not allowed.

Example: EID NAME Phone

101 Sai Prakash 30CC0425

Explanation:

In the above relation, Name is a composite attribute and Phone is a multi-values attribute, so it is
violating domain constraint.
 INTEGRITY CONSTRAINTS
2. Key Constraints or Uniqueness Constraints :

• A relation can have multiple keys, out of which we choose one of the keys as primary key. If there is a unique
constraints, there won’t be primary key. These are called uniqueness constraints since it ensures that every
tuple in the relation should be unique.
• Duplicate values are not allowed in the primary key.

Example:

Explanation:
In the above table, EID is the primary key, and first and the last tuple has the same value in EID ie 01, so it is
violating the key constraint.
 INTEGRITY CONSTRAINTS
3. Entity Integrity Constraints :

• Entity Integrity constraints says that no primary key can take NULL value, since using primary key we identify
each tuple uniquely in a relation.

Example:

Explanation:

In the above relation, EID is made primary key, and the primary key cant take NULL values but in the third tuple, the
primary key is null, so it is a violating Entity Integrity constraints.
 INTEGRITY CONSTRAINTS
4. Referential Integrity Constraints : (also called as Foreign Key Constraint)

• The Referential integrity constraints is specified between two relations to maintain the consistency among the tuples in two
relations.

• This constraint is enforced through foreign key, when an attribute in the foreign key of relation R1 have the same domain(s)
as the primary key of relation R2, then the foreign key of R1 is said to reference or refer to the primary key of relation R2.

Example:

Explanation: In the above, DNO of the first relation is the foreign key, and DNO in the second relation is the primary key. DNO =
22 in the foreign key of the first table is not allowed/inserted; since DNO = 22 is not defined in the primary key of the second
relation. Therefore, Referential integrity constraints is violated here
FUNCTIONAL DEPENDENCIES
 FUNCTIONAL DEPENDENCIES
• A functional dependency is a constraint that specifies the relationship between two sets of
attributes where one set can accurately determine the value of other sets.

• It is denoted as X → Y, where X is a set of attributes that is capable of determine the value of Y.

• The attribute set on the left side of the arrow, X is called Determinant, while on the right side, Y is
called the Dependent.

• Functional dependencies are used to mathematically express relations among database entities.
 FUNCTIONAL DEPENDENCIES
dept_ dept_ Some of the Functional Dependencies are,
roll_no name
name building a) roll_no → { name, dept_name, dept_building }
b) roll_no → dept_name
42 abc CO A4
c) dept_name → dept_building
43 pqr IT A3 d) roll_no → name
e) {roll_no, name} ⇢ {dept_name, dept_building}
44 xyz CO A4
f) name → dept_name
45 xyz IT A3 g) dept_building → dept_name
h) name → roll_no
46 mno EC B2
i) {name, dept_name} → roll_no
47 jkl ME B2 j) dept_building → roll_no
 FUNCTIONAL DEPENDENCIES
Some valid functional dependencies of given table are:
Example:
a) roll_no → { name, dept_name,
roll_no name dept_name dept_building dept_building }, Here, roll_no can determine

42 abc CO A4 values of fields name, dept_name and

dept_building, hence a valid Functional
43 pqr IT A3
dependency
44 xyz CO A4
b) roll_no → dept_name , Since, roll_no can
45 xyz IT A3
determine whole set of {name, dept_name,
46 mno EC B2
dept_building}, it can determine its subset
47 jkl ME B2 dept_name also.
 FUNCTIONAL DEPENDENCIES
Example: Some valid functional dependencies of given table are:
c) dept_name → dept_building, Dept_name can
roll_no name dept_name dept_building
identify the dept_building accurately, since
42 abc CO A4 departments with different dept_name will also
43 pqr IT A3 have a different dept_building

44 xyz CO A4 d) More valid functional dependencies:

roll_no → name,
45 xyz IT A3
{roll_no, name} ⇢ {dept_name,
46 mno EC B2
dept_building}, etc.
47 jkl ME B2
 FUNCTIONAL DEPENDENCIES
Here are some invalid functional dependencies:
dept_ dept_ a) name → dept_name; Students with the same name can
roll_no name be in different dept_name, hence this is not a valid
name building
functional dependency.
42 abc CO A4 b) dept_building → dept_name; There can be multiple
departments in the same building, For example, in the
43 pqr IT A3 above table departments ME and EC are in the same
building B2, hence dept_building → dept_name is an
44 xyz CO A4 invalid functional dependency.
45 xyz IT A3 c) More invalid functional dependencies:
name → roll_no,
46 mno EC B2
{name, dept_name} → roll_no,
47 jkl ME B2 dept_building → roll_no, etc.
 FUNCTIONAL DEPENDENCIES
Properties of functional dependencies:

• Augmentation: If X → Y is a valid dependency, then XZ → YZ is also valid by the augmentation rule.

For example, If roll_no → dept_building is valid, hence {roll_no, dept_name} → {dept_building,
dept_name} is also valid.

• Transitivity: If X → Y and Y → Z are both valid dependencies, then X→Z is also valid by the
Transitivity rule.
For example, If roll_no → dept_name & dept_name → dept_building are valid, then roll_no →
dept_building is also valid.
 FUNCTIONAL DEPENDENCIES
Types of Functional dependencies in DBMS:

• Trivial functional dependency

• Non-Trivial functional dependency

• Multivalued functional dependency

• Transitive functional dependency

 FUNCTIONAL DEPENDENCIES
1. Trivial Functional Dependency

In Trivial Functional Dependency, a dependent is always a subset of the determinant.

i.e. If X → Y and Y is the subset of X, then it is called trivial functional dependency

For example,
Here, {roll_no, name} → name is a trivial roll_no name Age
functional dependency, since the dependent name is
42 abc 17
a subset of determinant set {roll_no, name}
Similarly, roll_no → roll_no is also an example of
43 pqr 18
trivial functional dependency.
44 xyz 18
 FUNCTIONAL DEPENDENCIES
2. Non-trivial Functional Dependency

In Non-trivial functional dependency, the dependent is strictly not a subset of the determinant.
i.e. If X → Y and Y is not a subset of X, then it is called Non-trivial functional dependency.

For example,
Here, roll_no → name is a non-trivial functional roll_no name Age
dependency, since the dependent name is not a subset
42 abc 17
of determinant roll_no
Similarly, {roll_no, name} → age is also a non-trivial
functional dependency, since age is not a subset of 43 pqr 18
{roll_no, name}
44 xyz 18
 FUNCTIONAL DEPENDENCIES
3. Multivalued Functional Dependency

In Multivalued functional dependency, entities of the dependent set are not dependent on each other.
i.e. If a → {b, c} and there exists no functional dependency between b and c, then it is called
a multivalued functional dependency.
roll_no name age
For example,
42 abc 17
Here, roll_no → {name, age} is a multivalued
functional dependency, since the
43 pqr 18
dependents name & age are not dependent on each
other
44 xyz 18
(i.e. name → age or age → name doesn’t exist !)
 FUNCTIONAL DEPENDENCIES
4. Transitive Functional Dependency

In transitive functional dependency, dependent is indirectly dependent on determinant.

i.e. If a → b & b → c, then according to axiom of transitivity, a → c. This is a transitive functional
dependency enrol_ buildin
name dept
For example, no g_no
Here, enrol_no → dept and dept → building_no, 42 abc CO 4
Hence, according to the axiom of transitivity, enrol_no →
building_no is a valid functional dependency. This is an 43 pqr EC 2
indirect functional dependency, hence called Transitive
functional dependency. 44 xyz IT 1

45 abc EC 2
Features of good relational database design
 Features of good relational database design
Relational databases need ACID characteristics. ACID refers to four essential properties:
A - Atomicity,
C - Consistency,
I - Isolation,
D - Durability

These features are the key difference between a relational database and a non-relational database.
 Features of good relational database design
Atomicity - This principle states that database transactions must be all or nothing. If the transaction
fails, the entire transaction is rolled back. Atomicity prevents partial and incomplete transactions.
 Features of good relational database design
Consistency - According to this property, only valid transactions are allowed.
For example, a transaction crediting 5000 to a bank account with a current balance of 3000 is invalid.
Hence, the transaction will be blocked and aborted.
• Relational databases have data consistency because the information is updated across applications
and database copies (also known as ‘instances’). This means multiple instances always have the same
data.
E.g.: Credit and Balance tables; Change in one table should reflect in its corresponding tables.
 Features of good relational database design
Isolation - With a relational database, each transaction is separate and not dependent on others.
This is made possible by isolation. Changes in one transaction will not impact others until committed.

For instance, if Transaction T1 updates a row, Transaction T2 must wait until T1 commits or rolls back.
Isolation prevents T2 from reading unreliable data updated by T1 but not committed yet.

Isolation avoids concurrency issues like:

• Dirty reads - Reading uncommitted data from other transactions

• Non-repeatable reads - Same query yielding different results across transactions

 Features of good relational database design

Durability – Durability ensures that transactions, once committed, will survive permanently. Failed
hardware, power loss, and even database crashes will not undo committed transactions due to
durability support.

Durability means that you can recover data from a failed transaction. It also ensures that data
changes are permanent.
E.g.: Disconnection in internet during transaction.
Normalization (1NF, 2NF, 3NF, BCNF)
 Normalization (1NF, 2NF, 3NF, BCNF)
A large database defined as a single relation may result in data duplication. This repetition of data may result in:

• Making relations very large.

• It is not easy to maintain, to update and to search data in relation.

• Wastage and poor utilization of disk space and resources.

• The likelihood of errors and inconsistencies increases.

So to handle these problems, the relation has to be decomposed into smaller, simpler, and well-structured
relations that are satisfy desirable properties.

Normalization is a process of decomposing the relations into relations with fewer attributes.
Normalization (1NF, 2NF, 3NF, BCNF)
 Normalization (1NF, 2NF, 3NF, BCNF)
First Normal Form: A relation will be 1NF if it contains an atomic value.

1NF states that an attribute of a table cannot hold multiple values. It must hold only single-valued
attribute. First normal form disallows the multi-valued attribute, composite attribute, and their
combinations.
 Normalization (1NF, 2NF, 3NF, BCNF)
Second Normal Form:

• In the 2NF, relational must be in 1NF.

• In the second normal form, all non-key attributes are fully functional dependent on ‘all Prime keys’. Non-key
attributes should not depends on a subset of candidate key.

Before we learn about the second normal form, we need to understand the following −

 Prime attribute − An attribute, which is a part of the candidate-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.

If we follow second normal form, then every non-prime attribute should be fully functionally dependent on prime key
attributes. That is, if X → A holds, then there should not be any proper subset Y of X, for which Y → A also holds true.
 Normalization (1NF, 2NF, 3NF, BCNF)
We see here in Student_Project relation that the prime key attributes are Stu_ID and
Proj_ID. According to the rule, non-key attributes, i.e. Stu_Name and Proj_Name must be
dependent upon both and not on any of the prime key attribute individually. But we find that Stu_Name
can be identified by Stu_ID and Proj_Name can be identified by Proj_ID independently. This is called
partial dependency, which is not allowed in 2NF.

We broke the relation in two as depicted in the above picture. So there exists no partial dependency.
 Normalization (1NF, 2NF, 3NF, BCNF)
Third Normal Form: 3NF is used to reduce the data duplication.

For a relation to be in Third Normal Form, it must be in 2NF and the following must satisfy −

• No non-prime attribute is transitively dependent on prime key attribute.

• For any non-trivial functional dependency, X → A, then either −

o X is a superkey or,

o A is prime attribute.
 Normalization (1NF, 2NF, 3NF, BCNF)
• In the above Student_detail relation, Stu_ID is the key and only prime key attribute (Primary/candidate
key). All other 3 attributes are non-prime attributes. We find that City can be identified by Zip (Zip →City) or
vice versa (It’s a non trivial dependency). Neither Zip is a superkey nor is City a prime attribute. It violates
3NF.
• To bring this relation into third normal form, we break the relation into two relations as follows −

• Before normalization, for 10 different students 40 (10*4) cells are required in ‘Student_Detail’.
• After normalization, 30 (10*3)cells are required in ‘Student_Detail’ and just 1 (1*1) cell is required in ‘ZipCodes’
 Normalization (1NF, 2NF, 3NF, BCNF)
Boyce-Codd Normal Form: Boyce-Codd Normal Form (BCNF) is an extension of Third Normal Form on
strict terms. BCNF states that −

 A table is in BCNF if every functional dependency X → A, X must be a super-key of the table.

• In the previous image, Stu_ID is the super-key in the relation Student_Detail and Zip is the super-key
in the relation ZipCodes. So, Stu_ID → Stu_Name, Zip and Zip → City Which confirms
that both the relations are in BCNF.
 Normalization (1NF, 2NF, 3NF, BCNF)
Example 2: Consider a relation R with attributes (student, subject, teacher).

Student Teacher Subject Functional Dependencies:

Jhansi Saravanan DBMS i. (student, Teacher) -> subject
jhansi Das C++ ii. (student, subject) -> Teacher
subbu Saravanan DBMS iii. Teacher -> subject
subbu Prasad C++

Super keys are (student, teacher) and (student, subject); since a particular tuple can be identified.
These are satisfying BCNF i.e if for every non-trivial FD X->Y, X must be a Super key.
 Normalization (1NF, 2NF, 3NF, BCNF)
Example 2: Consider a relation R with attributes (student, subject, teacher).

Student Teacher Subject Functional Dependencies:

Jhansi Saravanan DBMS i. (student, Teacher) -> subject
jhansi Das C++ ii. (student, subject) -> Teacher
subbu Saravanan DBMS iii. Teacher -> subject
subbu Prasad C++

The above relation is not in BCNF, because in the FD (teacher->subject), teacher is not a key.
 Normalization (1NF, 2NF, 3NF, BCNF)
Decomposition for BCNF: Teacher-> subject violates BCNF [since teacher is not a candidate key].
If X->Y violates BCNF then divide R into R1(X, Y) and R2(R-Y).
So R is divided into two relations R1(Teacher, subject) and R2(student, Teacher).

R1 R2
Teacher Subject Student Teacher
Saravanan DBMS Jhansi Saravanan
DAS C++ Jhansi Das
Prasad C++ Subbu Saravanan
Subbu Prasad
THE END