DBMS

WHAT IS DBMS?

A database management system (DBMS) is system software for creating and

managing databases. The DBMS provides users and programmers with a systematic
way to create, retrieve, update and manage data.
DBMS also provide protection and security on database.it maintain data consistency in
case of multiple user.
Example:
MYSQL, ORACLE, SQL etc.

COMPONENT OF DATABASE SYSTEM

Database system is divided into four pars.

USER

Users may be various types such as DBA system developer and end user.

DATABASE APPLICATION:
Database application may be personal, departmental and internal.

FUNCTIONS OF DBMS

There are several functions that a DBMS performs to ensure data integrity and consistency of
data in the database. The ten functions in the DBMS are:

data dictionary management

data storage management
data transformation
presentation
security management
multiuser access control
backup and recovery management
data integrity management
ADVANTAGE OF DBMS

Controlling Data Redundancy

Data Consistency
Data Sharing
Data Integration
DISADVANTAGE OF DBMS

Cost of Data Conversion

2
 Database Failures
Cost of Staff Training
Complexity

FILE SYSTEM:

A file management system is an abstraction to store, retrieve, manage and update the set of
files.

DATABASE ARCHITECTURE

Database architecture is logically divided into two types.

1. Logical two-tier Client / Server architecture

2. Logical three-tier Client / Server architecture

TWO-TIER CLIENT / SERVER ARCHITECTURE:

Two-tier Client / Server architecture is used for User Interface program and Application
Programs that runs on client side. An interface called ODBC (Open Database Connectivity)
3
provides an API that allow client side program to call the DBMS. Most DBMS vendors provide
ODBC drivers. A client program may connect to several DBMS's. In this architecture some
variation of client is also possible for example in some DBMS's more functionality is
transferred to the client including data dictionary, optimization etc. Such clients are called
Data server.

THREE-TIER CLIENT / SERVER ARCHITECTURE

4
Three-tier Client / Server database architecture is commonly used architecture for web
applications. Intermediate layer called Application server or Web Server stores the web
connectivty software and the business logic(constraints) part of application used to access the
right amount of data from the database server. This layer acts like medium for sending
partially processed data between the database server and the client.

DATABASE MODEL:

A Database model defines the logical design of data. The model describes the relationships
between different parts of the data. Historically, in database design, three models are
commonly used. They are,

Hierarchical Model

Network Model

Relational Model

HIERARCHICAL MODEL:

In this model each entity has only one parent but can have several children . At the top of
hierarchy there is only one entity which is called Root.

5
NETWORK MODEL:

In the network model, entities are organised in a graph,in which some entities can be
accessed through several path.

RELATIONAL MODEL:
Relational data model is the primary data model, which is used widely around the world for
data storage and processing. This model is simple and it has all the properties and
capabilities required to process data with storage efficiency.

CONCEPTS
Tables In relational data model, relations are saved in the format of Tables. This
format stores the relation among entities. A table has rows and columns, where rows
represents records and columns represent the attributes.

Tuple A single row of a table, which contains a single record for that relation is called
a tuple.

Relation instance A finite set of tuples in the relational database system represents
relation instance. Relation instances do not have duplicate tuples.

6
Relation schema A relation schema describes the relation name (table name),
attributes, and their names.

Relation key Each row has one or more attributes, known as relation key, which can
identify the row in the relation (table) uniquely.

Attribute domain Every attribute has some pre-defined value scope, known as
attribute domain.

7
ENTITY RELATIONAL(E-R) MODEL:

An entity relationship model, also called an entity-relationship (ER) diagram, is a

graphical representation of entities and their relationships to each other, typically used
in computing in regard to the organization of data within databases or information
systems. An entity is a piece of data-an object or concept about which data is stored.

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.
Its the database designers who design the schema to help programmers understand the
database and make it useful.

8
A database schema can be divided broadly into two categories

Physical Database Schema This schema pertains to the actual

storage of data and its form of storage like files, indices, etc. It defines
how the data will be stored in a secondary storage.

Logical Database Schema This schema defines all the logical

constraints that need to be applied on the data stored. It defines tables,
views, and integrity constraints.

DATABASE INSTANCE
It is important that we distinguish these two terms individually. Database schema is the
skeleton of database. It is designed when the database doesn't exist at all. Once the
database is operational, it is very difficult to make any changes to it. A database schema
does not contain any data or information.

A database instance is a state of operational database with data at any given time. It
contains a snapshot of the database. Database instances tend to change with time. A
DBMS ensures that its every instance (state) is in a valid state, by diligently following all
the validations, constraints, and conditions that the database designers have imposed.

OVERALL STRUCTURE OF DATABASE

9
10
 E-R MODEL CONCEPT

ENTITY
An entity can be a real-world object, either animate or inanimate, that can be easily
identifiable. 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.

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.

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.

There exists a 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.

TYPES OF ATTRIBUTES
Simple attribute Simple attributes are atomic values, which cannot be divided further. For
example, a student's phone number is an atomic value of 10 digits.

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.

These attribute types can come together in a way like

11
 simple single-valued attributes

simple multi-valued attributes

composite single-valued attributes

composite multi-valued attributes

ENTITY-SET AND KEYS

Key is an attribute or collection of attributes that uniquely identifies an entity among
entity set.

For example, the roll_number of a student makes him/her identifiable among students.

Super Key A set of attributes (one or more) that collectively identifies an entity in an entity
set.

Candidate Key A minimal super key is called a candidate key. An entity set may have more
than one candidate key.

Primary Key A primary key is one of the candidate keys chosen by the database designer
to uniquely identify the entity set.

RELATIONSHIP
The association among entities is called a relationship. For example, an
employee works_at a department, a student enrolls in a course. Here, Works_at and
Enrolls are called relationships.

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.

DEGREE OF RELATIONSHIP
The number of participating entities in a relationship defines the degree of the
relationship.

Binary = degree 2

Ternary = degree 3

n-ary = degree

MAPPING CARDINALITIES
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.
12
 One-to-one One entity from entity set A can be associated with at most one entity of entity
set B and vice versa.

One-to-many One entity from entity set A can be associated with more than one entities of
entity set B however an entity from entity set B, can be associated with at most one entity.

Many-to-one More than one entities from entity set A can be associated with at most one
entity of entity set B, however an entity from entity set B can be associated with more than
one entity from entity set A.

13
 Many-to-many One entity from A can be associated with more than one entity from B and
vice versa.

NOTATION OR REPRESENTATION OF ER MODEL

Let us now learn how the ER Model is represented by means of an ER diagram. Any
object, for example, entities, attributes of an entity, relationship sets, and attributes of
relationship sets, can be represented with the help of an ER diagram.

ENTITY
Entities are represented by means of rectangles. Rectangles are named with the entity
set they represent.

ATTRIBUTES
14
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).

If the attributes are composite, they are further divided in a tree like structure. Every
node is then connected to its attribute. That is, composite attributes are represented by
ellipses that are connected with an ellipse.

Multivalued attributes are depicted by double ellipse.

15
Derived attributes are depicted by dashed ellipse.

RELATIONSHIP
Relationships are represented by diamond-shaped box. Name of the relationship is
written inside the diamond-box. All the entities (rectangles) participating in a relationship,
are connected to it by a line.

BINARY RELATIONSHIP AND CARDINALITY

16
A relationship where two entities are participating is called a binary relationship.
Cardinality is the number of instance of an entity from a relation that can be associated
with the relation.

One-to-one When only one instance of an entity is associated with the relationship, it is
marked as '1:1'. The following image reflects that only one instance of each entity should be
associated with the relationship. It depicts one-to-one relationship.

One-to-many When more than one instance of an entity is associated with a relationship, it
is marked as '1:N'. The following image reflects that only one instance of entity on the left and
more than one instance of an entity on the right can be associated with the relationship. It
depicts one-to-many relationship.

Many-to-one When more than one instance of entity is associated with the relationship, it
is marked as 'N:1'. The following image reflects that more than one instance of an entity on
the left and only one instance of an entity on the right can be associated with the relationship.
It depicts many-to-one relationship.

17
 Many-to-many The following image reflects that 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.
It depicts many-to-many relationship.

PARTICIPATION CONSTRAINTS
Total Participation Each entity is involved in the relationship. Total participation is
represented by double lines.

Partial participation Not all entities are involved in the relationship. Partial participation is
represented by single lines.

DATABASE KEYS
Keys are very important part of Relational database. They are used to establish and identify relation between
tables. They also ensure that each record within a table can be uniquely identified by combination of one or
more fields within a table.

SUPER KEY
Super Key is defined as a set of attributes within a table that uniquely identifies each record within a table.
Super Key is a superset of Candidate key.

CANDIDATE KEY

18
Candidate keys are defined as the set of fields from which primary key can be selected. It is an attribute or set of
attribute that can act as a primary key for a table to uniquely identify each record in that table.

PRIMARY KEY
Primary key is a candidate key that is most appropriate to become main key of the table. It is a key that uniquely
identify each record in a table.

COMPOSITE KEY
Key that consist of two or more attributes that uniquely identify an entity occurance is called Composite key.
But any attribute that makes up the Composite key is not a simple key in its own.

19
SECONDARY OR ALTERNATIVE KEY
The candidate key which are not selected for primary key are known as secondary keys or alternative keys

NON-KEY ATTRIBUTE
Non-key attributes are attributes other than candidate key attributes in a table.

NON-PRIME ATTRIBUTE
Non-prime Attributes are attributes other than Primary attribute.

CONCEPT OF SUPER KEY

Definition: A super key is a set or one of more columns (attributes) to uniquely identify rows
in a table. Often people get confused between super key and candidate key, so we will also
discuss a little about candidate key here.

How candidate key is different from super key?

Answer is simple Candidate keys are selected from the set of super keys, the only thing we
take care while selecting candidate key is: It should not have any redundant attribute. Thats
the reason they are also termed as minimal super key.

Lets take an example to understand this: Employee table

Emp_SSN Emp_Number Emp_Name

123456789 226 Steve

999999321 227 Ajeet

20
888997212 228 Chaitanya

777778888 229 Robert

Super keys:

{Emp_SSN}
{Emp_Number}
{Emp_SSN, Emp_Number}
{Emp_SSN, Emp_Name}
{Emp_SSN, Emp_Number, Emp_Name}
{Emp_Number, Emp_Name}

All of the above sets are able to uniquely identify rows of the employee table.

Candidate Keys:
As I stated above, they are the minimal super keys with no redundant attributes.

{Emp_SSN}
{Emp_Number}

Only these two sets are candidate keys as all other sets are having redundant attributes that
are not necessary for unique identification.

Primary key:
Primary key is being selected from the sets of candidate keys by database designer. So
Either {Emp_SSN} or {Emp_Number} can be the primary key.

CANDIDATE KEY

A super key with no redundant attribute is known as candidate key. Candidate keys are
selected from the set of super keys, the only thing we take care while selecting candidate key
is: It should not have any redundant attributes. Thats the reason they are also termed as
minimal super key.

For example:

21
Emp_Id Emp_Number Emp_Name

E01 2264 Steve

E22 2278 Ajeet

E23 2288 Chaitanya

E45 2290 Robert

There are two candidate keys in above table:

{Emp_Id}
{Emp_Number}

Note: A primary key is being selected from the group of candidate keys. That means we can
either have Emp_Id or Emp_Number as primary key.

PRIMARY KEY
Definition: A primary is a column or set of columns in a table that uniquely identifies tuples
(rows) in that table.

Example:
Student Table

Stu_Id Stu_Name Stu_Age

22
101 Steve 23

102 John 24

103 Robert 28

104 Carl 22

In the above Student table, the Stu_Id column uniquely identifies each row of the table.

Note:

We denote the primary key by underlining the column name.

The value of primary key should be unique for each row of the table. Primary key column
cannot contain duplicate values.
Primary key column should not contain nulls.
Primary keys are not necessarily to be a single column; more than one column can also
be a primary key for a table. For e.g. {Stu_Id, Stu_Name}collectively can play a role of
primary key in the above table, but that does not make sense because Stu_Id alone is
enough to uniquely identifies rows in a table then why to make things complex. Having
that said, we should choose more than one columns as primary key only when there is
no single column that can play the role of primary key.

How to choose a primary key?

There are two ways: Either to create a column and let database automatically have numbers
in increasing order for each row or choose a column yourself making sure that it does not
contain duplicates and nulls. For e.g. in the above Student table, The Stu_Name column cannot
be a primary key as more than one people can have same name, similarly the Stu_Age column
cannot play a primary key role as more than one persons can have same age.

GENERALIZATION AND AGGREGATION

GENERALIZATION

23
Generalization is a bottom-up approach in which two lower level entities combine to form a higher level entity. In
generalization, the higher level entity can also combine with other lower level entity to make further higher level
entity.

SPECIALIZATION
Specialization is opposite to Generalization. It is a top-down approach in which one higher level entity can be
broken down into two lower level entity. In specialization, some higher level entities may not have lower-level entity
sets at all.

24
AGGREGRATION
Aggregration is a process when relation between two entity is treated as a single entity. Here the relation between
Center and Course, is acting as an Entity in relation with Visitor.

25
REDUCTION OF AN ER DIAGRAMS TO TABLES

As the database grows, the ER diagram representation becomes more complex and crowded. It is creates a difficult
situation to understand the requirement and their structure as a whole. Similarly, if ER diagram is represented at
very high level, it again creates a difficulty in understanding the system. But representation at high level and till the
minute levels is very necessary to understand the system well. These concepts are well defined by generalization
and specialization. Sometimes, we would have divided the entities into two or more entities to be more accurate in
design. But when compared to the whole database or user, it can be combined to one entity. Such a process is
called as aggregation.

Once designing ER diagram is complete, we need to put it into logical structure. But how it can be done? Let us
discuss this in the last section.

GENERALIZATION

In our Employee example, we have seen different types of employees like Engineer, Accountant, Salesperson,
Clerk etc. Similarly each employee belongs to different departments. We can represent it in an ER diagram as
below. When you see this diagram for the first time, you will not understand it quickly. One will take time to
understand it or he might misunderstand some requirement.

What if we group all the sub departments into one department and different employees into one employee?
However sub departments and different employee types have same features in their own domain. So if we merge
the child entities into their parent, it makes the diagram simpler, hence easy to understand. This method of merging
the branches into one is called generalization. We can see the generalized structure of requirement to understand it
quickly. So above ER diagram will be changed to as below:

26
Isnt it simpler? Generalization is the bottom up approach which helps to design the requirement at high level. Thus
making one to understand quickly.

SPECIALIZATION

It is opposite approach of generalization. Here, each entity is further divided into sub levels to understand it deeper.
In the above example, Department entity is further divided into sub departments to understand how they are
scattered. This method of representation helps the developer to code correctly and quickly. It is a top down
approach of breaking higher level entity to low level entity. Once the entities are understood at higher level, it makes
easy to understand the requirement at low level.

One more example of specialization would be Person. We can further divide person as STUDENT, TEACHER,
ENGINEER, SOLDIER etc. (Merging STUDENT, TEACHER, ENGINEER etc into PERSON is an example of
generalization).

AGGREGATION

Look at below ER diagram of STUDENT, COURSE and SUBJECTS. What does it infer? Student attends the
Course, and he has some subjects to study. At the same time, Course offers some subjects. Here a relation is

27
defined on a relation. But ER diagram does not entertain such a relation. It supports mapping between entities, not
between relations. So what can we do in this case?

If we look at STUDENT and COURSE from SUBJECTs point of view, it does not differentiate both of them. It offers
its subject to both of them. So what can we do here is, merge STUDENT and COURSE as one entity. This process
of merging is called aggregation. It is completely different from generalization. In generalization, we merge entities
of same domain into one entity. In this case we merge related entities into one entity.

Here we have merged STUDENT and COURSE into one entity STUDENT_COURSE. This new entity forms the
mapping with SUBJECTS. The new entity STUDENT_COURSE, in turn has two entities STUDENT and COURSE
with Attends relationship.

TRANSFORM ER DIAGRAM INTO TABLES

Since ER diagram gives us the good knowledge about the requirement and the mapping of the entities in it, we can
easily convert them as tables and columns. i.e.; using ER diagrams one can easily created relational data model,
which nothing but the logical view of the database.

There are various steps involved in converting it into tables and columns. Each type of entity, attribute and
relationship in the diagram takes their own depiction here. Consider the ER diagram below and will see how it is
converted into tables, columns and mappings.

28
The basic rule for converting the ER diagrams into tables is

Convert all the Entities in the diagram to tables.

All the entities represented in the rectangular box in the ER diagram become independent tables in the database. In
the below diagram, STUDENT, COURSE, LECTURER and SUBJECTS forms individual tables.

All single valued attributes of an entity is converted to a column of the table

All the attributes, whose value at any instance of time is unique, are considered as columns of that table. In the
STUDENT Entity, STUDENT_ID, STUDENT_NAME form the columns of STUDENT table. Similarly,
LECTURER_ID, LECTURER_NAME form the columns of LECTURER table. And so on.

Key attribute in the ER diagram becomes the Primary key of the table.

In diagram above, STUDENT_ID, LECTURER_ID, COURSE_ID and SUB_ID are the key attributes of the entities.
Hence we consider them as the primary keys of respective table.

Declare the foreign key column, if applicable.

In the diagram, attribute COURSE_ID in the STUDENT entity is from COURSE entity. Hence add COURSE_ID in
the STUDENT table and assign it foreign key constraint. COURSE_ID and SUBJECT_ID in LECTURER table forms
the foreign key column. Hence by declaring the foreign key constraints, mapping between the tables are
established.

Any multi-valued attributes are converted into new table.

A hobby in the Student table is a multivalued attribute. Any student can have any number of hobbies. So we cannot
represent multiple values in a single column of STUDENT table. We need to store it separately, so that we can store
any number of hobbies, adding/ removing / deleting hobbies should not create any redundancy or anomalies in the

29
system. Hence we create a separate table STUD_HOBBY with STUDENT_ID and HOBBY as its columns. We
create a composite key using both the columns.

Any composite attributes are merged into same table as different columns.

In the diagram above, Student Address is a composite attribute. It has Door#, Street, City, State and Pin. These
attributes are merged into STUDENT table as individual columns.

One can ignore derived attribute, since it can be calculated at any time.

In the STUDENT table, Age can be derived at any point of time by calculating the difference between DateOfBirth
and current date. Hence we need not create a column for this attribute. It reduces the duplicity in the database.

These are the very basic rules of converting ER diagram into tables and columns, and assigning the mapping
between the tables. Table structure at this would be as below:

Let us see some of the special cases.

Converting Weak Entity

Weak entity is also represented as table. All the attributes of the weak entity forms the column of the table. But the
key attribute represented in the diagram cannot form the primary key of this table. We have to add a foreign key
column, which would be the primary key column of its strong entity. This foreign key column along with its key
attribute column forms the primary key of the table.

In our example above, SUBJECTS is the weak entity. Hence, we create a table for it. Its attributes SUBJECT_ID
and SUBJECT_NAME forms the column of this table. Although SUBJECT_ID is represented as key attribute in the
diagram, it cannot be considered as primary key. In order to add primary key to the column, we have to find the
foreign key first. COURSE is the strong entity related to SUBJECT. Hence the primary key COURSE_ID of
COURSE is added to SUBJECT table as foreign key. Now we can create a composite primary key out of
COURSE_ID and SUBJECT_ID.

30
 Representing 1:1 relationship

Imagine SUBJECT is not a weak entity, and we have LECTURER teaches SUBJECT relation. It is a 1:1 relation.
i.e.; one lecturer teaches only one subject. We can represent this case in two ways

1. Create table for both LECTURER and SUBJECT. Add the primary key of LECTURER in SUBJECT table
as foreign key. It implies the lecturer name for that particular subject.
2. Create table for both LECTURER and SUBJECT. Add the primary key of SUBJECT in LECTURER table
as foreign key. It implies the subject taught by the lecturer.
In both the case, meaning is same. Foreign key column can be added in either of the table, depending on the
developers

choice.

Representing 1:N relationship

Consider SUBJECT and LECTURER relation, where each Lecturer teaches multiple subjects. This is a 1: N relation.
In this case, primary key of LECTURER table is added to the SUBJECT table. i.e.; the primary key at 1 cardinality
entity is added as foreign key to N cardinality entity

Representing M:N relationship

Consider the example, multiple students enrolled for multiple courses, which is M:N relation. In this case, we create
STUDENT and COURSE tables for the entities. Create one more table for the relation Enrolment and name it as

31
STUD_COURSE. Add the primary keys of COURSE and STUDENT into it, which forms the composite primary key
of the new table.

That is, in this case both the participating entities are converted into tables, and a new table is created for the
relation between them. Primary keys of entity tables are added into new table to form the composite primary key.
We can add any additional columns, if present as attribute of the relation in ER diagram.

Self Referencing 1:N relation

Consider the example of HOD and Lecturers. Here one of the Lecturers is a HOD of the department. i.e.; one HOD
has multiple lecturers working with him. In this case, we create LECTURER table for the Lecturer entity. Create the
columns and primary keys as usual. In order to represent HOD, we add one more column to LECTURER table
which is same column as primary key, but acts as a foreign key. i.e.; LECTURER_ID is the primary key of
LECTURER table. We add one more column HOD, which will have LECTURER_ID of the HOD. Hence LECTURER
table will show HODs Lecturer ID for each Lecturer. In this case, primary key column acts as a foreign key in the
same table.

Self Referencing M:N relation

Consider Student and Teacher example as Manny students have Many Teachers teaching the subjects. Here
relation between Student and Teacher is M:N. In this case, create independent tables for student and teacher, and
set their primary keys. Then we create a new table for the relationship have as STUDENT_TEACHER, which will
have student and teacher combination, and any other columns if applicable. Basically, student-teacher combination
is the two primary key columns from respective tables, hence establishing the relationship between them. Both the
primary keys from both tables act as a composite primary key in the new table. This reduces the storing of
redundant data and consistency in the database.

32
EXTENDED ENTITY-RELATIONSHIP MODEL
The Extended Entity-Relationship Model is a more complex and high-level model that
extends an E-R diagram to include more types of abstraction, and to more clearly express
constraints. All of the concepts contained within an E-R diagram are included in the EE-R
model, along with additional concepts that cover more semantic information. These
additional concepts include generalization/specialization, union, inheritance, and
subclass/superclass.

UNIT 2
RELATION DATA MODEL

33
Relational data model is the primary data model, which is used widely around the world for data storage and
processing. This model is simple and it has all the properties and capabilities required to process data with
storage efficiency.

CONCEPTS

Tables In relational data model, relations are saved in the format of Tables. This format stores the relation
among entities. A table has rows and columns, where rows represents records and columns represent the
attributes.

Tuple A single row of a table, which contains a single record for that relation is called a tuple.

Relation instance A finite set of tuples in the relational database system represents relation instance. Relation
instances do not have duplicate tuples.

Relation schema A relation schema describes the relation name (table name), attributes, and their names.

Relation key Each row has one or more attributes, known as relation key, which can identify the row in the
relation (table) uniquely.

Attribute domain Every attribute has some pre-defined value scope, known as attribute domain.

CONSTRAINTS

Every relation has some conditions that must hold for it to be a valid relation. These conditions are called
Relational Integrity Constraints. There are three main integrity constraints

Key constraints
Domain constraints
Referential integrity constraints

KEY CONSTRAINTS

There must be at least one minimal subset of attributes in the relation, which can identify a tuple uniquely. This
minimal subset of attributes is called key for that relation. If there are more than one such minimal subsets,
these are called candidate keys.

Key constraints force that

in a relation with a key attribute, no two tuples can have identical values for key attributes.
a key attribute can not have NULL values.

Key constraints are also referred to as Entity Constraints.

DOMAIN CONSTRAINTS

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

34
specific range of values. For example, age cannot be less than zero and telephone numbers cannot contain a
digit outside 0-9.

REFERENTIAL INTEGRITY CONSTRAINTS

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.

RELATIONAL ALGEBRA

Relational database systems are expected to be equipped with a query language that can assist
its users to query the database instances. There are two kinds of query languages relational
algebra and relational calculus.

RELATIONAL ALGEBRA

Relational algebra is a procedural query language, which takes instances of relations as input
and yields instances of relations as output. It uses operators to perform queries. An operator can
be either unary or binary. They accept relations as their input and yield relations as their
output. Relational algebra is performed recursively on a relation and intermediate results are
also considered relations.

The fundamental operations of relational algebra are as follows

Selection
Projection
Union
Set different
Cartesian product
Rename

Operators in Relational Algebra

Projection ()
Projection is used to project required column data from a relation.

Example :

R
(A B C)
----------
1 2 4
2 2 3

35
 3 2 3
4 3 4
(BC)
B C
-----
2 4
2 3
3 4

Note: By Default projection removes duplicate data.

Selection ()
Selection is used to select required tuples of the relations.

for the above relation

(c>3)R
will select the tuples which have c more than 3.

Note: selection operator only selects the required tuples but does not display them. For displaying, data
projection operator is used.

For the above selected tuples, to display we need to use projection also.

( (c>3)R ) will show following tuples.

A B C
-------
1 2 4
4 3 4

Union (U)
Union operation in relational algebra is same as union operation in set theory, only constraint is for union of
two relation both relation must have same set of Attributes.

Set Difference (-)

Set Difference in relational algebra is same set difference operation as in set theory with the constraint that
both relation should have same set of attributes.

Rename ()
Rename is a unary operation used for renaming attributes of a relation.
(a/b)R will rename the attribute b of relation by a.

Cross Product (X)

36
 Cross product between two relations let say A and B, so cross product between A X B will results all the
attributes of A followed by each attribute of B. Each record of A will pairs with every record of B.

below is the example

A B
(Name Age Sex ) (Id Course)
------------------ -------------
Ram 14 M 1 DS
Sona 15 F 2 DBMS
kim 20 M

A X B
Name Age Sex Id Course
---------------------------------
Ram 14 M 1 DS
Ram 14 M 2 DBMS
Sona 15 F 1 DS
Sona 15 F 2 DBMS
Kim 20 M 1 DS
Kim 20 M 2 DBMS

Note: if A has n tuples and B has m tuples then A X B will have n*m tuples.

Natural Join ()

Natural join is a binary operator. Natural join between two or more relations will result set of all
combination of tuples where they have equal common attribute.

Let us see below example

Emp Dep
(Name Id Dept_name ) (Dept_name Manager)
------------------------ ---------------------
A 120 IT Sale Y
B 125 HR Prod Z
C 110 Sale IT A
D 111 IT

Emp Dep

Name Id Dept_name Manager

-------------------------------
A 120 IT A
C 110 Sale Y
D 111 IT A

Conditional Join

37
 Conditional join works similar to natural join. In natural join, by default condition is equal between common
attribute while in conditional join we can specify the any condition such as greater than, less than, not equal

Let us see below example

R S
(ID Sex Marks) (ID Sex Marks)
------------------ --------------------
1 F 45 10 M 20
2 F 55 11 M 22
3 F 60 12 M 59

Join between R And S with condition R.marks >= S.marks

R.ID R.Sex R.Marks S.ID S.Sex S.Marks

-----------------------------------------------
1 F 45 10 M 20
1 F 45 11 M 22
2 F 55 10 M 20
2 F 55 11 M 22
3 F 60 10 M 20
3 F 60 11 M 22
3 F 60 12 M 59

38