Database Management System Unit-2: Relational Model

UNIT- 2
Relational Model
1. Features of EER Model

 EER creates a design more accurate to database schemas.

 It reflects the data properties and constraints more precisely.
 It includes all modeling concepts of the ER model.
 Diagrammatic technique helps for displaying the EER schema.
 It includes the concept of specialization and generalization.
 It is used to represent a collection of objects that is union of objects of different of different
entity types.

1. Generalization: As mentioned above, the process of generalizing entities, where the

generalized entities contain the properties of all the generalized entities, is called
generalization. In generalization, a number of entities are brought together into one
generalized entity based on their similar characteristics. For example, pigeon, house sparrow,
crow and dove can all be generalized as Birds.Generalization is the process of generalizing the
entities which contain the properties of all the generalized entities.It is a bottom approach, in
which two lower level entities combine to form a higher level entity.Generalization is the
reverse process of Specialization.

2. Specialization: Specialization is the opposite of generalization. In specialization, a group of

entities is divided into sub-groups based on their characteristics. Take a group ‘Person’ for
example. A person has name, date of birth, gender, etc. These properties are common in all
persons, human beings. But in a company, persons can be identified as employee, employer,
customer, or vendor, based on what role they play in the company.Specialization is a process
that defines a group entities which is divided into sub groups based on their characteristic. It is
a top down approach, in which one higher entity can be broken down into two lower level
entity.It maximizes the difference between the members of an entity by identifying the unique
characteristic or attributes of each member.

1
Database Management System Unit-2: Relational Model

Similarly, in a school database, persons can be specialized as teacher, student, or a staff, based
on what role they play in school as entities.
3. Inheritance: We use all the above features of ER-Model in order to create classes of objects
in object-oriented programming. The details of entities are generally hidden from the user; this
process known as abstraction.
Inheritance is an important feature of Generalization and Specialization. It allows lower-level
entities to inherit the attributes of higher-level entities.

For example, the attributes of a Person class such as name, age, and gender can be inherited by
lower-level entities such as Student or Teacher.

4. Sub Class and Super Class: Sub class and Super class relationship leads the concept of

Inheritance. The relationship between sub class and super class is denoted with symbol.
 Super Class: Super class is an entity type that has a relationship with one or more
subtypes.An entity cannot exist in database merely by being member of any super class.
For example: Shape super class is having sub groups as Square, Circle, Triangle.

2
Database Management System Unit-2: Relational Model

 Sub Class: Sub class is a group of entities with unique attributes.Sub class inherits
properties and attributes from its super class. For example: Square, Circle, Triangle are the sub
class of Shape super class.

5. Category or Union: Category represents a single super class or sub class relationship with
more than one super class. It can be a total or partial participation. example Car booking, Car
owner can be a person, a bank (holds a possession on a Car) or a company. Category (sub class)
→ Owner is a subset of the union of the three super classes → Company, Bank, and Person. A
Category member must exist in at least one of its super classes.

6: Aggregation: Aggregation is a process that represents a relationship between a whole object

and its component parts. It abstracts a relationship between objects and viewing the
relationship as an object. It is a process when two entity is treated as a single entity. In the
example, the relation between College and Course is acting as an Entity in Relation with Student.

3
Database Management System Unit-2: Relational Model

1.1 Converting ER Diagram to Tables:

Rule-01: For Strong Entity Set With Only Simple Attributes: A strong entity set with only
simple attributes will require only one table in relational model.
 Attributes of the table will be the attributes of the entity set.
 The primary key of the table will be the key attribute of the entity set.

Roll_no Name Sex

Rule-02: For Strong Entity Set With Composite Attributes:

 A strong entity set with any number of composite attributes will require only one table in
relational model.
 While conversion, simple attributes of the composite attributes are taken into account and
not the composite attribute itself.

First-Name Last-Name

Roll_no First-name Last-Name Sex

Rule-03: For Strong Entity Set With Multi Valued Attributes: A strong entity set with any
number of multi valued attributes will require two tables in relational model.
 One table will contain all the simple attributes with the primary key.
 Other table will contain the primary key and all the multi valued attributes.

Roll_no city

Roll_no Mobile-no

Rule-04: Translating Relationship Set into a Table- A relationship set will require one table
in the relational model. Attributes of the table are
 Primary key attributes of the participating entity sets
 Its own descriptive attributes if any.
 Set of non-descriptive attributes will be the primary key.

4
Database Management System Unit-2: Relational Model

Emp_no Dept_id since

Rule-05: For Binary Relationships With Cardinality Ratios: The following four cases are
possible

Case-01: Binary relationship with cardinality ratio m:n : in this case separate table for
relationship will be required which will include the attributes which describe the identity of
relation entities i.e. primary key from both entities.

Here, three tables will be required: 1. A ( a1 , a2 ) 2. R ( a1 , b1 ) 3. B ( b1 , b2 )

Case-02: For Binary Relationship With Cardinality Ratio 1:n: in this case separate table for
relationship is not required. The table for Relationship can be merged with entity having many
relation. For binary relationship with cardinality ratio either m : 1 or 1 : n , always remember
“many side will consume the relationship” i.e. a combined table will be drawn for many side
entity set and relationship set. Here, combined table will be drawn for the entity set B and
relationship set R.

Here, two tables will be required: 1. A ( a1 , a2 ) 2. BR ( b1 , b2, a1 )

Case-03: For Binary Relationship With Cardinality Ratio m:1: in this case separate table for
relationship is not required. The table for Relationship can be merged with entity having many
relation. For binary relationship with cardinality ratio either m : 1 or 1 : n , always remember
“many side will consume the relationship” i.e. a combined table will be drawn for many side
entity set and relationship set. Here, combined table will be drawn for the entity set A and
relationship set R.

5
Database Management System Unit-2: Relational Model

Here, two tables will be required: 1. AR ( a1 , a2, b1 ) 2. B ( b1 , b2)

Case-04: For Binary Relationship With Cardinality Ratio 1:1 For binary relationship with
cardinality ratio 1 : 1 , two tables will be required. You can combine the relationship set with
any one of the entity sets. Here, two tables will be required. Either combine ‘R’ with ‘A’ or ‘B’

Way-01: AR ( a1 , a2 , b1 ) & B ( b1 , b2 )
Way-02: A ( a1 , a2 ) & BR ( a1 , b1 , b2 )

Rule-06: For Binary Relationship With Both Cardinality Constraints and Participation
Constraints:
 Cardinality constraints will be implemented as discussed in Rule-05.
 Because of the total participation constraint, foreign key acquires NOT NULL constraint i.e.
now foreign key cannot be null.

Case-01: For Binary Relationship With Cardinality Constraint and Total Participation
Constraint From One Side

Because cardinality ratio = 1 : n , so we will combine the entity set B and relationship set R.
Because of total participation, foreign key a1 has acquired NOT NULL constraint, so it can’t be
null now.

Then, two tables will be required: 1. AR ( a1 , a2, b1 ) 2. B ( b1 , b2 )

Case-02: For Binary Relationship With Cardinality Constraint and Total Participation
Constraint From Both Sides:
 If there is a key constraint from both the sides of an entity set with total participation, then
that binary relationship is represented using only single table.

6
Database Management System Unit-2: Constraints & Normalization

Here, Only one table is required. 1. ARB ( a1 , a2 , b1 , b2 )

Rule-07: For Binary Relationship With Weak Entity Set-: Weak entity set always appears in
association with identifying relationship with total participation constraint.

Here, two tables will be required: 1. A ( a1 , a2 ) 2. BR ( a1 , b1 , b2 )

2.1 BASIC CONCEPTS

1. Entity: An entity can be a real-world object, either animate or inanimate, that can be easily
identifiable. Or any real-world object can be represented as an entity about which data can be
stored in a database For example, in a school database, students, teachers, classes, and courses
offered can be considered as entities. All these entities have some attributes or properties that
give them their identity.
2. An entity set is a collection of similar types of entities. An entity set may contain entities
with attribute sharing similar values. For example, a Students set may contain all the students
of a school; likewise a Teachers set may contain all the teachers of a school from all faculties.
Entity sets need not be disjoint.
3. Attributes: Entities are represented by means of their properties, called attributes. All
attributes have values. For example, a student entity may have name, class, and age as
attributes. attributes gives identity to entity.
4. Domain: or range of values that can be assigned to attributes. For example, a student's
name cannot be a numeric value. It has to be alphabetic. A student's age cannot be negative,
etc. Attributes are the properties of entities. Attributes are represented by means of ellipses.
Every ellipse represents one attribute and is directly connected to its entity (rectangle).
5. Tuple: A single row of a table, which contains a single record for that relation is called a
tuple.

7
Database Management System Unit-2: Constraints & Normalization

2.2 CODD's RULES

Dr Edgar F. Codd, after his extensive research on the Relational Model of database systems,
suggested twelve rules of his own, which according to him, a database must obey in order to
be regarded as a true relational database. These rules can be applied on any database system
that manages stored data using only its relational capabilities.
 Rule 1: Information Rule: The data stored in a database, may it be user data or metadata,
must be a value of some table cell. Everything in a database must be stored in a table format.
 Rule 2: Guaranteed Access Rule: Every single data element (value) is guaranteed to be
accessible logically with a combination of table-name, primary-key (row value), and attribute-
name (column value). No other means, such as pointers, can be used to access data.
 Rule 3: Systematic Treatment of NULL Values: The NULL values in a database must be given a
systematic and uniform treatment. This is a very important rule because a NULL can be
interpreted as one the following − data is missing, data is not known, or data is not applicable.
 Rule 4: Active Online Catalog: The structure description of the entire database must be stored
in an online catalog, known as data dictionary, which can be accessed by authorized users.
Users can use the same query language to access the catalog which they use to access the
database itself.
Rule 5: Comprehensive Data Sub-Language Rule: A database can only be accessed using a
language having linear syntax that supports data definition, data manipulation, and
Transaction management operations. This language can be used directly or by means of some
application. If the database allows access to data without any help of this language, then it is considered
as a violation.
 Rule 6: View Updating Rule: All the views of a database, which can theoretically be updated,
must also be updatable by the system.
 Rule 7: High-Level Insert, Update, and Delete Rule: A database must support high-level
insertion, updation, and deletion. This must not be limited to a single row, that is, it must also
support union, intersection and minus operations to yield sets of data records.
 Rule 8: Physical Data Independence: The data stored in a database must be independent of
the applications that access the database. Any change in the physical structure of a database
must not have any impact on how the data is being accessed by external applications.
 Rule 9: Logical Data Independence: The logical data in a database must be independent of its
user’s view (application). Any change in logical data must not affect the applications using it.
For example, if two tables are merged or one is split into two different tables, there should be
no impact or change on the user application. This is one of the most difficult rule to apply.
 Rule 10: Integrity Independence: A database must be independent of the application that uses
it. All its integrity constraints can be independently modified without the need of any change
in the application. This rule makes a database independent of the front-end application and its
interface.
 Rule 11: Distribution Independence: The end-user must not be able to see that the data is
distributed over various locations. Users should always get the impression that the data is
located at one site only. This rule has been regarded as the foundation of distributed database
systems.

8
Database Management System Unit-2: Constraints & Normalization
 Rule 12: Non-Subversion Rule: If a system has an interface that provides access to low-level
records, then the interface must not be able to subvert the system and bypass security and
integrity constraints.

2.3 INTEGRITY CONSTRAINTS

Integrity constraints are a set of rules. It is used to maintain the quality of information. It
ensure that the data insertion, updating, and other processes have to be performed in such a
way that data integrity is not affected. Thus, is used to guard against accidental damage to the
database. Various types of Integrity Constraint are

1. Domain constraints: 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.
Attributes have specific values in real-world scenario. For example, age can only be a positive
integer. The same constraints have been tried to employ on the attributes of a relation. Every
attribute is bound to have a specific range of values. For example, age cannot be less than zero
and telephone numbers cannot contain a digit outside 0-9.
Example:

2. Entity integrity constraints: 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.
Example:

9
Database Management System Unit-2: Constraints & Normalization

3. Key constraints: Keys are the entity set that is used to identify an entity within its entity
set uniquely. An entity set can have multiple keys, but out of which one key will be the
primary key. A primary key can contain a unique and null value in the relational table. Example:

4. Referential Integrity Constraints: 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 be null or be
available in Table 2. So we can say Referential integrity constraints work on the concept of
Foreign Keys. A foreign key is a key attribute of a relation that can be referred in other
relation. Referential integrity constraint states that if a relation refers to a key attribute of a
different or same relation, then that key element must exist.
Example:

2.4 Enterprise Constraints: Enterprise constraints – sometimes referred to as semantic

constraints – are additional rules specified by users or database administrators and can be
based on multiple tables. Here are some examples.
 A class can have a maximum of 30 students.
 A teacher can teach a maximum of four classes per semester.
 An employee cannot take part in more than five projects.
 The salary of an employee cannot exceed the salary of the employee’s manager.

10
Database Management System Unit-2: Constraints & Normalization


2.5 DATABASE SCHEMA

A database schema is the skeleton structure that represents the logical view of the entire
database. It defines how the data is organized and how the relations among them are
associated. It formulates all the constraints that are to be applied on the data.
A database schema defines its entities and the relationship among them. It contains a
descriptive detail of the database, which can be depicted by means of schema diagrams. It’s
the database designers who design the schema to help programmers understand the
database and make it useful.

Above is a simple example of a schema diagram. It shows three tables, along with their data
types, relationships between the tables, as well as their primary keys and foreign keys.

2.6 FUNCTIONAL DEPENDENCY

The functional dependency is a relationship that exists between two attributes. It typically
exists between the primary key and non-key attribute within a table.
X → Y
The left side of FD is known as a determinant, the right side of the production is known as a
dependent.
For example: Assume we have an employee table with attributes: Emp_Id, Emp_Name,
Emp_Address. Here Emp_Id attribute can uniquely identify the Emp_Name attribute of
employee table because if we know the Emp_Id, we can tell that employee name associated
with it. Functional dependency can be written as:
Emp_Id → Emp_Name

We can say that Emp_Name is functionally dependent on Emp_Id.

11
Database Management System Unit-2: Constraints & Normalization

Types of Functional dependency

Figure: Types of Functional Dependency

1. Trivial functional dependency: A Dependency is said to be Trivial if in any dependency A

-> B, B is a entity which is subset of entity set A. The dependencies like: A → A, B → B are also
trivial
Example: Consider a table with two columns Employee_Id and Employee_Name.
{Employee_id, Employee_Name} → Employee_Id
It is a trivial functional dependency as Employee_Id is a subset of {Employee_Id, Employee
_Name}. Also following are trivial dependencies too.

Employee_Id → Employee_Id and Employee_Name → Employee_Name

2. Non-trivial functional dependency: A Dependency is said to be Non Trivial if in any

dependency A -> B, B is a entity which is not subset of entity set A. When A intersection B is
NULL, then A → B is called as complete non-trivial.
Example: 1. ID → Name, 2. Name → DOB

2.7 ANOMALIES: If a database design is not perfect, it may contain anomalies that is impurity,
which are like a bad dream for any database administrator. Managing a database with
anomalies is next to impossible.

 Update anomalies − If data items are scattered and are not linked to each other properly,
then it could lead to strange situations. For example, when we try to update one data item
having its copies scattered over several places, a few instances get updated properly while a
few others are left with old values. Such instances leave the database in an inconsistent state.
 Deletion anomalies − We tried to delete a record, but parts of it was left undeletedbecause
of unawareness, the data is also saved somewhere else.
 Insert anomalies − We tried to insert data in a record that does not exist at all.

2.8 RELATIONAL DECOMPOSITION:

Decomposition is the process of splitting the tables in two or more tables. When a relation in
the relational model is not in appropriate normal form then the decomposition of a relation is
required. In a database, it breaks the table into multiple tables. If the relation has no proper
decomposition, then it may lead to problems like loss of information. Decomposition is used
to eliminate some of the problems of bad design like anomalies, inconsistencies, and

12
Database Management System Unit-2: Constraints & Normalization
redundancy.

2.8.1 Types of Decomposition

Figure: Types of Decomposition

1. Lossless Decomposition: If the information is not lost from the relation that is
decomposed, then the decomposition will be lossless. The lossless decomposition guarantees
that the join of relations will result in the same relation as it was decomposed. The relation is
said to be lossless decomposition if natural joins of all the decomposition give the original
relation.
Example: Table: Employee_Department

EMP_I EMP_NAM EMP_AG EMP_CIT DEPT_I DEPT_NAM

D E E Y D E
22 Denim 28 Mumbai 827 Sales
33 Alina 25 Delhi 438 Marketing
46 Stephan 30 Bangalore 869 Finance
52 Katherine 36 Mumbai 575 Production
60 Jack 40 Noida 678 Testing

The above relation is decomposed into two relations Employee and Department

Table: Employee Table: Department

EMP_I EMP_NAM EMP_AG EMP_CIT DEPT_I EMP_I DEPT_NAM

D E E Y D D E
22 Denim 28 Mumbai 827 22 Sales
33 Alina 25 Delhi 438 33 Marketing
46 Stephan 30 Bangalore 869 46 Finance
52 Katherine 36 Mumbai 575 52 Production
678 60 Testing
60 Jack 40 Noida

Now, when these two relations are joined on the common column "EMP_ID", then the
resultant relation will look like: Employee X Department (Joint of Both Tables)

EMP_I EMP_NAM EMP_AG EMP_CIT DEPT_I DEPT_NAM

D E E Y D E
22 Denim 28 Mumbai 827 Sales
33 Alina 25 Delhi 438 Marketing
46 Stephan 30 Bangalore 869 Finance
13
Database Management System Unit-2: Constraints & Normalization
52 Katherine 36 Mumbai 575 Production
60 Jack 40 Noida 678 Testing

Hence, the decomposition is Lossless join decomposition.

2. Dependency Preserving: It is an important constraint of the database. In the

dependency preservation, at least one decomposed table must satisfy every dependency. If a
relation R is decomposed into relation R1 and R2, then the dependencies of R either must be a
part of R1 or R2 or must be derivable from the combination of functional dependencies of R1
and R2. For example, suppose there is a relation R (A, B, C, D) with functional dependency set
(A->BC). The relational R is decomposed into R1(ABC) and R2(AD) which is dependency
preserving because FD A->BC is a part of relation R1(ABC).

2.9 MULTIVALUED DEPENDENCY:

Multivalued dependency occurs when two attributes in a table are independent of each other
but, both depend on a third attribute. A multivalued dependency consists of at least two
attributes that are dependent on a third attribute that's why it always requires at least three
attributes.
Example: Suppose there is a bike manufacturer company which produces two colors (white
and black) of each model every year.

BIKE_MODE MANUF_YEA COLO

L R R
M2001 2008 Black
M3001 2013 White
M3001 2013 Black
M4006 2017 White
M4006 2017 Black

Here columns COLOR and MANUF_YEAR are dependent on BIKE_MODEL and independent of
each other. In this case, these two columns can be called as multivalued dependent on
BIKE_MODEL. The representation of these dependencies is shown below:
1. BIKE_MODEL → → MANUF_YEAR
2. BIKE_MODEL → → COLOR
So to remove this dependency the above table need to be decomposed in to two tables as
bellow.

BIKE_MODE MANUF_YEA BIKE_MODE COLO

L R L R
M2001 2008 M2001 Black
M3001 2013 M3001 White
M3001 2013 M3001 Black
M4006 2017 M4006 White 14
M4006 2017 M4006 Black
Database Management System Unit-2: Constraints & Normalization

This can be read as "BIKE_MODEL multi determined MANUF_YEAR" and "BIKE_MODEL multi
determined COLOR".

2.10 JOIN DEPENDENCY

Join decomposition is a further generalization of Multivalued dependencies. If the join of R1
and R2 over C is equal to relation R, then we can say that a join dependency (JD) exists. Where
R1 and R2 are the decompositions R1(A, B, C) and R2(C, D) of a given relations R (A, B, C, D).
Alternatively, R1 and R2 are a lossless decomposition of R. A JD ⋈ {R1, R2,...,Rn} is said to hold
over a relation R if R1, R2, , Rn is a lossless-join decomposition. The *(A, B, C, D), (C, D) will
be a JD of R if the join of join's attribute is equal to the relation R. Here, *(R1, R2, R3) is used to
indicate that relation R1, R2, R3 and so on are a JD of R.

15