UNIT-2

Introduction to Database design and the Relational Model

Database Design and ER Diagrams, Entities, Attributes and Entity Sets, Relationships & Relationship
Sets, Additional Features of the ER Model, Conceptual Design with ER Model,
Introduction to the Relational Model, Integrity Constraints over Relations, Enforcing Integrity
Constraints, Querying Relational Data, Logical Database Design: ER to Relational,
Introduction to Views, Destroying/ Altering Tables and Views.
2.1 Introduction to Database design and ER diagrams:-

The entity-relationship (ER) data model allows us to describe the data involved in a real-world enterprise
in terms of objects and their relationships and is widely used to develop an initial database design.
The ER model is important primarily for its role in database design. It provides useful concepts that
allow us to move from an informal description of what users want from their database to a more
detailed and precise, description that can be implemented in a DBMS.
Even though the ER model describes the physical database model, it is basically useful in the design
and communication of the logical database model.

2.2 Overview of Database Design

Our primary focus is the design of the database. The database design process can be divided into six
steps:

Requirements Analysis

The very first step in designing a database application is to understand what data is to be stored in the
database, what applications must be built on the database, and what operations must be performed
on the database. In other words, we must find out what the users want from the database. This process
involves discussions with user groups, a study of the current operating environment, how it is
expected to change an analysis of any available documentation on existing applications and so on.

Conceptual Database Design

The information gathered in the requirement analysis step is used to develop a high-level description
of the data to be stored in the database, along with the conditions known to hold this data. The goal
is to create a description of the data that matches both—how users and developers think of the data
(and the people and processes to be represented in the data). This facilitates discussion among all the
people involved in the design process i.e., developers and as well as users who have no technical
background. In simple words, the conceptual database design phase is used in drawing ER model.

Logical Database Design

We must implement our database design and convert the conceptual database design into a database
schema (a description of data) in the data model (a collection of high-level data description constructs
that hide many low-level storage details) of the DBMS. We will consider only relational DBMSs, and
therefore, the task in the logical design step is to convert the conceptual database design in the form
of E-R Schema (Entity-Relationship Schema) into a relational database schema.

Schema Refinement

The fourth step in database design is to analyze the collection, of relations (tables) in our relational
database schema to identify future problems, and to refine (clear) it.
Physical Database Design

This step may simply involve building indexes on some tables and clustering some tables, or it may
 involve redesign of parts of the database schema obtained from the earlier design steps.

Application and Security Design

Any software project that involves a DBMS must consider applications that involve processes and
identify the entities.

2.3 Entities, Attributes and Entity Sets

Entity: An entity is an object in the real world that is distinguishable from other objects.
Entity set: An entity set is a collection of similar entities. The Employees entity set with attributes ssn,
name, and lot is shown in the following figure.

Attribute: An attribute describes a property associated with entities. Attribute will have a name and a
value for each entity.
Domain: A domain defines a set of permitted values for an attribute
Entity Relationship Model: An ERM is a theoretical and conceptual way of showing data relationships
in software development. It is a database modeling technique that generates an abstract diagram or visual
representation of a system's data that can be helpful in designing a relational database.
ER model allows us to describe the data involved in a real-world enterprise in terms of objects and their
relationships and is widely used to develop an initial database design.

2.4 Representation of Entities and Attributes

ENTITIES: Entities are represented by using rectangular boxes. These are named with the entity name that they
represent.
.

ATTRIBUTES: 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.

Types of attributes:
 Simple attribute − Simple attributes are atomic values, which cannot be divided further. Forexample, a student's
roll number is an atomic value.
 Composite attribute − Composite attributes are made of more than one simple attribute. For example, a
student's complete name may have first_name and last_name.

 Derived attribute − Derived attributes are the attributes that do not exist in the physical database, but their
values are derived from other attributes present in the database. For example, average_salary in a department
should not be saved directly in the database, instead it can be derived. For another example, age can be derived
from data_of_birth.

 Single-value attribute − Single-value attributes contain single value. For example − Social_Security_Number.
 Multi-value attribute − Multi-value attributes may contain more than one values. For example, a person can
have more than one phone number, email_address, etc.

2.5 Relationship and Relationship set

Relationships are represented by diamond-shaped box. Name of the relationship is written inside thediamond-box. All the
entities (rectangles) participating in a relationship, are connected to it by a line. Types of relationships:
Degree of Relationship is the number of participating entities in a relationship defines the degree of the relationship.
Based on degree the relationships are categorized as

2.5.1 Unary = degree 1

2.5.2 Binary = degree 2

2.5.3 Ternary = degree 3

2.5.4 n-array = degree
Unary Relationship: A relationship with one entity set. It is like a relationship among 2 entities of
same entity set. Example: A professor ( in-charge) reports to another professor (Head Of the Dept).
Binary Relationship: A relationship among 2 entity sets. Example: A professor teaches a course
and a course is taught by a professor.

Ternary Relationship: A relationship among 3 entity sets. Example: A professor teaches a course
in so and so semester.

n-array Relationship: A relationship among n entity sets.

Cardinality:
Defines the number of entities in one entity set, which can be associated with the number of
entities of other set via relationship set. Cardinality ratios are categorized into 4. They are.

1. One-to-One relationship: When only one instance of entities is associated with the
relationship, then the relationship is one-to-one relationship. Each entity in A is associated
with at most one entity in B and each entity in B is associated with at most one entity in A.
2. One-to-many relationship: When more than one instance of an entity is associated with a
relationship, then the relationship is one-to-many relationship. Each entity in A is associated
with zero or more entities in B and each entity in B is associated with at most one entity in A.

3. Many-to-one relationship: When more than one instance of entity is associated with the
relationship, then the relationship is many-to-one relationship. Each entity in A is associated
with at most one entity in B and each entity in B is associated with 0 (or) more entities in A.

4. Many-to-Many relationship: If more than one instance of an entity on the left and more than
one instance of an entity on the right can be associated with the relationship, then it depicts many-
to-many relationship. Each entity in A is associated with 0 (or) more entities in B andeach entity
in B is associated with 0 (or) more entities in A.
 Relationship Set:
A set of relationships of similar type is called a relationship set. Like entities, a relationship too can have
attributes. These attributes are called descriptive attributes.

Participation Constraints:
 Total Participation − If Each entity in the entity set is involved in the relationship then the
participation of the entity set is said to be total. Total participation is represented by double lines.
 Partial participation − If, Not all entities of the entity set are involved in the relationship then such
a participation is said to be partial. Partial participation is represented by single lines.
Example:

2.6 Additional Features Of The ER Model

Key Constraints

Consider a relationship set called Manages between the Employees and Departments entity sets such
that each department has at most one manager, although a single employee is allowed to manage more
than one department. The restriction that each department has at most one manager is an example
of a key constraint, and it implies that each Departments entity appears in at most one Manages
relationship in any allowable instance of Manages. This restriction is indicated in the ER diagram of
below Figure by using an arrow from Departments to Manages. Intuitively, the arrow states that
given a Departments entity, we can uniquely determine the Manages relationship in which it appears.
Key Constraints for Ternary Relationships

If an entity set E has a key constraint in a relationship set R, each entity in an instance of E appears
in at most one relationship in (a corresponding instance of) R. To indicate a key constraint on entity
set E in relationship set R, we draw an arrow from E to R.

Below figure show a ternary relationship with key constraints. Each employee works in at most one
department, and at a single location.

Weak Entities

Strong Entity set: If each entity in the entity set is distinguishable or it has a key then such an entity
set is known as strong entity set.

Weak Entity set: If each entity in the entity set is not distinguishable or it doesn't has a key then
such an entity set is known as weak entity set.

eno is key so it is represented by solid underline. dname is partial key. It can't distinguish the tuples
in the Dependent entity set. so dname is represented by dashed underline.
Weak entity set is always in total participation with the relation. If entity set is weak then the relationship
is also known as weak relationship, since the dependent relation is no longer needed when the owner
left.
Ex: policy dependent details are not needed when the owner (employee) of that policy left or fired
from the company or expired. The detailed ER Diagram is as follows.
The cardinality of the owner entity set is with weak relationship is 1 : m. Weak entity set is uniquely
identifiable by partial key and key of the owner entity set.
Dependent entity set is key to the relation because the all the tuples of weak entity set are associated
with the owner entity set tuples.

Dependents is an example of a weak entity set. A weak entity can be identified uniquely only by
considering some of its attributes in conjunction with the primary key of another entity, which is
called the identifying owner.
The following restrictions must hold:
 The owner entity set and the weak entity set must participate in a one-to-many relationship
set (one owner entity is associated with one or more weak entities, but each weak entity has
a single owner). This relationship set is called the identifying relationship set of the weak
entity set.
 The weak entity set must have total participation in the identifying relationship set

2.7 E-R Diagrams Implementation

Now we are in a position to write the ER diagram for the Company database which was introduced
in the beginning of this unit. The readers are strictly advised to follow the steps shown in this unit
to design an ER diagram for any chosen problem.

Step 1: Identify the Strong and Weak Entity Sets

After careful analysis of the problem we come to a conclusion that there are four possible entity sets
as shown below:
1. Employees Strong Entity Set
2. Departments Strong Entity Set
3. Projects Strong Entity Set
4. Dependents Weak Entity Set

Step 2: Identify the Relevant Attributes

The next step is to get all the attributes that are most applicable for each entity set. Do this work by
considering each entity set in mind and also the type of attributes. Next job is to pick the primary
key for strong entity sets and partial key for weak entity sets.

Example: Following are the attributes:

1. Employees SSN. Name, Addr, DateOfBirth, Sex, Salary
2. Departments DNo. DName, DLocation
3. Projects PNo. PName, PLocation
4. Dependents (weak) DepName, DateOf Birth, Sex, Relationship
The underlined attributes are the primary keys and DepName is the partial key of Dependents.
Also, DLocation may be treated as a multivalued attribute.

Step 3: Identify the Relationship Sets

In this step we need to find all the meaningful relationship sets among possible entity sets. This
step is very tricky, as redundant relationships may lead to complicated design and in turn a bad
implementation.

Example: Let us show below what the possible relationship sets are:
1. Employees and Departments WorksFor
2. Employees and Departments Manages
3. Departments and Projects Controls
4. Projects and Employees WorksOn
5. Dependents and Employees Has
6. Employees and Employees Supervises

Some problems may not have recursive relationship sets but some do have. In fact, our Company
database has one such relationship set called Supervises. You can complete this step adding possible
descriptive attributes of the relationship sets (Manages has StartDate and WorksOn has Hours).

Step 4: Identify the Cardinality Ratio and Participation Constraints

This step is relatively a simple one. Simply apply the business rules and your common sense. So,
we write the structural constraints for our example as follows:

1. WorksFor N: 1 Total on either side

2. Manages 1: 1 Total on Employees and Partial on Departments side
3. Controls 1: N Total on either side
4. WorksOn M: N Total on either side
5. Has 1: M Total on Dependents and Partial on Employees

Step 5: Identify the IS-A and Has-A Relationship Sets

The last step is to look for “is-a” and “has-a” relationships sets for the given problem. As far as
the Company database is concerned, there are no generalization and aggregation relationships
in the Company database.

The complete single ER diagram by combining all the above five steps is shown in figure
2.8 Class Hierarchies
To classify the entities in an entity set into subclass entity is known as class hierarchies. Example, we
might want to classify Employees entity set into subclass entities Hourly-Emps entity set and Contract-
Emps entity set to distinguish the basis on which they are paid. Then the class hierarchy is
illustrated as follows.

This class hierarchy illustrates the inheritance concept. Where, the subclass attributes ISA (read as
: is a) super class attributes; indicating the “is a” relationship (inheritance concept).Therefore, the
 attributes defined for a Hourly-Emps entity set are the attributes of Hourly-Emps plus attributes
of Employees (because subclass can have superclass properties). Likewise the attributes definedfor
a Contract-Emps entity set are the attributes of Contract-Emps plus attributes of Employees.

Class Hierarchy based on Sub-super Set

1. Specialization: Specialization is the process of identifying subsets (subclasses) of an entity set (superclass) that
share some special distinguishable characteristic. Here, the superclass (Employee) is defined first, then the subclasses
(Hourly-Emps, Contract-Emps, etc.) are defined next.
In short, Employees is specialized into subclasses.
2. Generalization: Generalization is the process of identifying (defining) some generalized (common) characteristics
of a collection of (two or more) entity sets and creating a new entityset that contains (possesses) these common
characteristics. Here, the subclasses (Hourly-Emps, Contract-Emps, etc.) are defined first, then the Superclass
(Employee) is defined, next.
In shortly, Hourly-Emps and Contract-Emps are generalized by Employees.

Class Hierarchy based on Constraints

1. Overlap constraints: Overlap constraints determine whether two subclasses are allowed
to contain the same entity.

Example: Can Akbar be both an Hourly-Emps entity and a Contract-Emps entity? The answer is, No.
Other example, can Akbar be both a Contract-Emps entity and a Senior-Emps entity (among them)?
The answer is, Yes. Thus, this is a specialisation hierarchy property. We denote this bywriting “Contract-Emps
OVERLAPS Senior-Emps”.

2. Covering Constraints: Covering constraints determine whether the entities in thesubclasses collectively include
all entities in the superclass.

Example: Should every Employee be a Hourly-Emps or .Contract-Emps?The Answer is, No. He can be a Daily-
Emps.
Other example, should every Motor-vehicle (superclass) be a Bike (subclass) or a Car(subclass)?
The Answer is YES. Thus generalization hierarchies property is that every instance of asuperclass is an instance of
a subclass.
We denote this by writing “ Bikes and Cars COVER Motor-vehicles”.

2.9 Aggregation
Aggregation allows us to indicate that a relationship set (identified through a dashed box) participates in another
relationship sets. That is, a relationship set in an association between entitysets. Sometimes we have to model a
relationship between a collection of entities and relationships.

Example: Suppose that we have an entity set called Project and that each Project entity is sponsored by one or more
departments. Thus, the sponsors relationship set captures this information but, a department that sponsors a project,
might assign employees to monitor the sponsorship. Therefore, Monitors should be a relationship set that associates
a sponsors relationship (rather
 than a Project or Department entity) with an Employees entity. However, again we have to define
relationships to associate two or more entities.

Use of Aggregation
We use an aggregation, when we need to express a relationship among relationships. Thus, there
are really two distinct relationships, Sponsors and Monitors, each with its own attributes.

2.10 Conceptual Database Design With The ER Model (ER Design Issues)
The following are the ER design issues:

1. Use entry sets attributes

2. Use of Entity sets or relationship sets

3. Binary versus entry relationship sets

4. Aggregation versus ternary relationship.

1. Use of Entity Sets versus Attributes

Consider the relationship set (called Works In2) shown in Figure

Intuitively, it records the interval during which an employee works for a department. Now suppose
that it is possible for an employee to work in a given department over more than one period.
This possibility is ruled out by the ER diagram’s semantics. The problem is that we want to record
several values for the descriptive attributes for each instance of the Works_In2 relationship. (This
situation is analogous to wanting to record several addresses for each employee.) We can address
this problem by introducing an entity set called, say, Duration, with attributes from and to, as shown
in Figure

2. Entity versus Relationship

Consider the relationship set called Manages that each department manager is given a discretionary
budget (dbudget), as shown in below figure, in which we have also renamed therelationship set to
Manages2.

There is at most one employee managing a department, but a given employee could manage several
departments; we store the starting date and discretionary budget for each manager- department pair. This
approach is natural if we assume that a manager receives a separate discretionary budget for each
department that he or she manages.

But what if the discretionary budget is a sum that covers all departments managed by that employee?
In this case each Manages2 relationship that involves a given employee will have the same value in
the dbudget field. In general such redundancy could be significant and could cause a variety of
problems. Another problem with this design is that it is misleading.

We can address these problems by associating dbudget with the appointment of the employee as
manager of a group of departments. In this approach, we model the appointment as an entity set, say
Mgr_Appts, and use a ternary relationship, say Man ages3, to relate a manager, an appointment, and
a department. The details of an appointment (such as the discretionary budget) are not repeated for
each department that is included in the appointment now, although there is still one Manages3
relationship instance per such department. Further, note that each department has at most one
manager, as before, because of the key constraint. This approach is illustrated in below Figure.
 3. Binary versus Ternary Relationships
Consider the ER diagram shown in below figure. It models a situation in which an employee can
own several policies, each policy can be owned by several employees, and each dependent can be
covered by several policies.

Suppose that we have the following additional requirements:

 A policy cannot be owned jointly by two or more employees.

 Every policy must be owned by some employee.
 Dependents is a weak entity set, and each dependent entity is uniquely identified by
taking pname in conjunction with the policyid of a policy entity (which, intuitively, covers
the given dependent).

The first requirement suggests that we impose a key constraint on Policies with respect to Covers,
but this constraint has the unintended side effect that a policy can cover only one dependent. The second
requirement suggests that we impose a total participation constraint on Policies. This solution is
acceptable if each policy covers at least one dependent. The third requirement forces usto introduce
an identifying relationship that is binary (in our version of ER diagrams, although there are versions
in which this is not the case).

Even ignoring the third point above, the best way to model this situation is to use two binary
relationships, as shown in below figure.
4. Aggregation versus Ternary Relationships
The choice between using aggregation or a ternary relationship is mainly determined by the existence
of relationship that relates a relationship set to an entity set (or second relationship set). The choice
may also be guided by certain integrity constraints to we want to express.

Consider the constraint that each sponsorship (of a project by a department) be monitored by at most
one employee. We cannot express this constraint in terms of the Sponsors2 relationship set. Also we
can express the constraint by drawing an arrow from the aggregated relationship. Sponsors to the
relationship Monitors. Thus, the presence of such a constraint serves as another reason for using
aggregation rather than a ternary relationship set.
2.1 Introduction to Relational Model:-
Relational Model was proposed by E.F Codd to model data in the form of relations or tables. After
designing the conceptual model of database using ER diagram, we need to convert the conceptual model
in the relational model which can be implemented using any RDBMS (Relational Data Base
Management System) like SQL, MY SQL etc.

The relational model is very simple and elegant; a database is a collection of one or more relations, where
each relation is a table with rows and columns.

This simple tabular representation enables even new users to understand the contents of a database, and it
permits the use of simple, high-level languages to query the data.

2.2 Relational Model

Relational Model represents how date is stored in relational databases.
A Relational database stores data in the form of relations (tables).
Consider a relation STUDENT with attributes ROLL_NO, NAME, ADDRESS, PHONE and AGE
as shown in table.
ROLL_NO NAME ADDRESS PHONE AGE
1 Nishma Hyderabad 9455123451 28
2 Sai Guntur 9652431843 27
3 Swetha Nellore 9156253131 26
4 Raji Ongole 9215635311 25
Attribute: Attributes are the properties that define a relation.
Ex: ROLL_NO, NAME

Tuple: Each row in a relation is known as tuple.

Ex:
1 Nishma Hyderabad 9455123451 28
Degree: The number of attributes in the relation is known as degree.
Ex: The degree of the given STUDENT table is 5.
Column: Column represent the set of values for a particular attribute.
The column ROLL_NO is extracted from the relation STUDENT.
Ex:
ROLL_NO
1

Null values: The value which is not known or unavailable is called NULL VALUE. It is representedby
blank space.

Cardinality: The number of tuples are present in the relation is called as its cardinality.

Ex: The Cardinality of the STUDENT table is 4.

2.3 Concept Of Domain
The domain of a database is the set of all allowable values (or) attributes of the database.
Ex: Gender (Male, Female, Others).

Relation
 A relation is defined as a set of tuples and attributes.
 A relation consists of Relation schema and relation instance.
 Relation schema: A relation schema represents the name of the relation with its attributes.
Ex: STUDENT (ROLL_NO, NAME, ADDRESS, PHONE and AGE) is Relation schema for STUDENT.
 Relation instance: The set of tuples of a relation at a particular instance of a time is calledRelation Instance.
An instance of “Employee” relation

Emp_code Emp_Name Dept_Name

01234 John HR
12567 Smith Sales
21678 Sai Production
12456 Jay Design

2.4 Importance of Null values:

 SQL supports a special value known as NULL which is used to represent the values of
attributes that may be unknown or not apply to a tuple.
 For example, the apartment number attribute of an address applies only to the address that is in
apartment buildings and not to other types of residences.
 It is important to understand that a NULL value is different from Zero value.
 A Null value is used to represent a missing value, but that is usually has one of the following
interpretations:
 Value unknown (Value exists but it is unknown)
 Value not available (exists but it is purposely withheld)
 Attribute not applicable (undefined for this tuple)
 It is often not possible to determine which of the meanings is intended.

2.5 Constraints

 On modeling the design of the relational data base, we can put some rules(conditions) like what
values are allowed to be inserted in the relation.
 Constraints are the rules enforced on the data columns of a table. These are used to limit
the type of data that can go into a table.
 This Ensure the accuracy and reliability of the data in the database. Constraints could
be on a column level or on a table level.
2.6 Domain Constraints In DBMS

 In DBMS table is viewed as a combination of rows and columns

 For example, if we are having a column called month and we want only (jan, feb,
march……) as values allowed to be entered for that column which is referred to
as domain for that column.
Definition: Domain constraint ensures two things it makes sure that the data value entered
for that particular column matches with the data type defined by that column
It shows that the constraints (NOT NULL/UNIQUE/PRIMARY KEY/FOREIGN
KEY/CHECK/DEFAULT)

Domain constraint= data type check for the column +constraints.

Example: we want to create a table “STUDENT” with “stu_id” field having a
value greater than 100, can create a domain and table like this.
 Create domain id_value int constraint id_test check (value>=100);
 CREATE table STUDENT (stu_id id value primary key, stu_name varchar(30),
stu_age int);

2.7 Key constraints in DBMS:

 Constraints are nothing but the rules that are to be followed while entering data into
columns of the database table.
 Constraints ensure that the data entered by the user into columns must be within the criteria
specified by the condition.
 We have 6 types of key constraints in DBMS
1. Not Null
2. Unique
3. Default
4. Check
5. Primary key
6. Foreign key
1. Not Null:
 Null represents a record where data may be missing data or data for that record may be
optional.
 Once not null is applied to a particular column, you cannot enter null values to that column.
 A not null constraint cannot be applied at table level.

Example:

Create table EMPLOYEE (id int Not null, name varchar Not null,
Age intnot null, address char (25), salary decimal (18,2), primary key(id));

 In the above example we have applied not null on three columns id, name and age
which means whenever a record is entered using insert statement all three columns
should contain a value other than null.
 We have two other columns address and salary, where not null is not applied which
means that you can leave the row as empty.

2. Unique:
Somet imes we need to maintain only. Unique data in the column of a database
table, this is possible by using a Unique constraint.

 Unique constraint ensures that all values in a column are Unique.

Example:

Create table PERSONS (id int unique, last_name varchar (25) not null,First name
varchar (25), age int);

 In the above example, as we have used unique constraint on ID column we are

not supposed to enter the data that is already present, simply no two ID values are
same.

3. Default:
Default in SQL is used to add default data to the columns.

 When a column is specified as default with same value then all the rows will
use the same value i.e., each and every time while entering the data we need
not enter that value.
 But default column value can be customized i.e., it can be over ridden when
inserting a data for that row based on the requirement.

(Row with default values “abc”)

Example:
Create table EMPLOYEE (id int Not null, last_name varchar (25) Not null,first_name
varchar (25), Age int, city varchar (25) Default Hyderabad);

 As a result, whenever we insert a new row each time we need not enter a
value for this default column that is entering a column value for a default column
is optional.

4. Check:
 Check constraint ensures that the data entered by the user for that column is
within the range of values or possible values specified.

Example: Create table STUDENT (id int, name varchar (25), age int,
check(age>=18));

 As we have used a check constraint as (age>=18) which means value entered by

user for this age column while inserting the data must be less than or equal to 18.
5. Primary Key:
 A primary key is a constraint in a table which uniquely identifies each row record
in a database table by enabling one or more column in the table as primary key.

Creating a primary key:

  A particular column is made as a primary key column by using the primary key
keyword followed by the column name.
Example:
Create table EMP (ID int, name varchar (20), age int, course varchar(10), Primary key
(ID));
 Here we have used the primary key on ID column then ID column must
contain unique values i.e., one ID cannot be used for another student.

6. Foreign Key:
 The foreign key constraint is a column or list of columns which points to the
primary key column of another table.
 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.

From the above two tables, COURSE_ID is a primary key of the table STUDENT_MARKS and
behaves as a foreign key as it is same in STUDENT_DETAILS and STUDENT_MARKS.
Example:

(Reference Table)

Create table CUSTOMER1 (id int, name varchar (25), course varchar (10),primary key (ID));

(Child table)

Create table CUSTOMER2 (id int, marks int, references customer1(ID));

2.8 Integrity Constraints in DBMS:

 There are two types of integrity constraints.
1. Entity Integrity Constraints
2. Referential Integrity Constraints

Entity Integrity constraints:

These constraints are used to ensure the uniqueness of each record or row
in the data table.
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 can‟t take
NULL values but in the 3rd tuple, the primary key is NULL, so it is violating
Entity integrity constraints.

Referential Integrity constraints:

The referential integrity constraint is specified between two relations or tables and used
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 as primary key of relation R2, then the foreign key of
R1 is said to reference or refer to the primary key of relation R2.
The values of the foreign key in a tuple of relation R1 can either take the values of the primary
key for some tuple in Relation R2, or can take NULL values, but can‟t be empty.
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 relation is not available in the second relation so, since
DNO=22 is not defined in the primary key of the second relation therefore Referential integrity
constraints is violated here.
Review Questions

1. Define the following terms and give examples

(i) cardinality (ii)unary relationships (iii)aggregation (iv)specialization

2. What is Entity set? and also define Relationship set. List and explain the symbols
used todraw ER Diagram.
3. Design a database for an airline. The database must keep track of customers and their
reservations, flights and their status, seat assignments on individual flights, and the
scheduleand routing of future flights. Your design should include an E-R diagram, a set
of relational schemas, and a list of constraints, including primary-key and foreign-key
constraints.
4. Discuss the representation of total participation and multivalued attribute in an E/R
diagram.
5. What is an Entity Relationship diagram and why it is useful?
6. What is a weak entity in ER diagram?
7. Give the diagrammatic representation of recursive relationship in an ER diagram and
also explain the importance of role names in representing a recursive relationship by
taking a realtime example.
8. Consider a database used to record the marks that students get in different exams of
different course offerings.
a. Construct an E-R diagram that models exams as entities, and uses a ternary
relationship,for the above database.
b. Construct an alternative E-R diagram that uses only a binary relationship
between students and course-offerings. Make sure that only one relationship
exists between a particular student and course-offering pair, yet you can represent
the marks that a student gets in different exams of a course offering.
9. Explain about relationship sets in ER model with examples.
10. Explain about ER model design issues.