Database Management Systems

UNIT -1
This course provides fundamental and practical knowledge on database concepts by means
of organizing the information, storing and retrieve the information in an efficient and a
flexible way from a well-structured relational model. This course ensures that every student
will gain experience in creating data models and database design.
Course Objectives

• Demonstrate basic database concepts, including the structure and operation of the
relational data model.
• Introduce simple and moderately advanced database queries using Structured Query
Language (SQL).
• Explain and successfully apply logical database design principles, including E-R
diagrams and database normalization.
• Demonstrate the concept of a database transaction and related database facilities,
including concurrency control, and data object locking and protocols

Introduction to the Database:

Data can be character, text, words, numbers, pictures, sound, or video. It is a collection of
data.
Information is useful and usually formatted in a manner that allows it to be understood by a
human.

Knowledge – Facts, information, skills acquired through experience or education; theoretical

or practical understanding of a subject.
Database -It is a structured set of data held in a computer, especially one that is accessible in
various ways.

Database Management System (DBMS) – It refers to the technology for creating and
managing databases.

A Database (db.) is an organized collection of data, typically stored in electronic

format.
➢ It allows you to input, manage, organize and retrieve data quickly.

➢ Traditional databases are organized by records (rows), fields (columns) stored

in tables whichare stored in database files.

➢ It’s a file used to store information.

A Database table is a collection of Rows and Columns that is used to organize information
about a single topic or object. Each Row within a Table corresponds to a single record and
contains several different attributes that describe the row.
A Database Table is the most common and simplest form of data storage in a relational
Database.

History of DBMS:
➢ Early 1960’s: First general-purpose DBMS, designed by Charles Bachman at General
Electric called Integrated Data Store-Network data model.
➢ Late 1960’s: IBM developed the Information Manager System (IMS). It is an
alternative data representation framework- Hierarchical Data model
➢ 1970: Edgar Codd at IBM’s San Jose Research Laboratory, proposed a new data
representation framework-Relational Data model.
➢ 1980: Relational data model is most widely used the SQL query language for
relational databases developed as part of IBM’s system R Project
➢ Late 1980’s: SQL was standardized, SQL:1999.
➢ James Gray won the Turing Award for his contributions to Database Transaction
Management.

File Systems VS DBMS

File system Interface DBMS Interface

End User End User

Application Programs Application Programs

Interface through Query (SQL)

Interface through high level language
SELECT * FROM Customer_Details
READ CUSTOMER_DETAILS-FILE AT
END
STOP RUN DBMS

Operating System
Operating System (Disk Manager, File Manager)
(Disk Manager, File Manager)

Customer_Details table
Customer_Details file Customer_Loan table
Customer_Loan file

File System (Disk Storage) Database (Disk Storage)

 File Systems DBMS

1. Unstructured Data Structured Data

2. File location required for accessing Location is not required to access data
files

3. Size of file Size of file

4. Access of data is not much flexible Flexible access of data possible using Query
causes redundant data

5. Redundancy is more Redundancy can be removed

6. Inconsistent data Consistent data- using keys

7. Concurrent access causes problems Concurrent access can be done

8. Integrity constraints cannot be Integrity constraints can be applied when

provided data is predefined created.

9. Security is less- backup, restore Security is more – backup and restore can
problems be done.

Advantages of DBMS
1.Data Independence:
Application programs should not, ideally, be exposed to details of data representation and
storage. It provides an abstract view of data by hiding such details (It is a separation of data
and metadata)
2. Efficient Data Access:

DBMS uses a variety of techniques to store and retrieve data efficiently i.e accessing data
is an easier task by using standardized SQL commands.
3.Data Integrity and Security:If data is accessed through DBMS, the DBMS can enforce
some Integrity Constraints on the data stored in tables while creating the schema and what
should be visible to different classes of users. Ex: bank (minimum amt in account), Student
result (pass mark), Faculty (Salary)
4.Data Administration:
When several users share the data, centralizing the administration of data. It is the responsible
for organizing the data representation to minimize redundancy.

5.Concurrent Access and Crash Recovery:

A DBMS Schedules concurrent accesses to the data in such a manner that users can think of
the data as being accessed by only one user at a time.
6.Reduced Application Development Time:
The DBMS Supports important functions that are common to many applications accessing
data in the DBMS. This in conjunction with the high-level interface to the data, facilities
quick application development.
Describing and storing Data in DBMS:

➢ Abstractions
➢ Schemas
➢ Data Independence

Levels of Abstractions with 3 tier Architecture:

DDL is used to define the external and conceptual schemas by using commands like create,
alter, drop, rename, truncate.
➢ Information about all these three levels is stored in System catalog
➢ Database contains not only the user data but also meta-data (data about data),
data is nothing but collection of files corresponding to user tables and indexes
➢ RDBMS maintains information about every table and index that it contains.
The descriptive information itself is stored as a collection of special tables
called catalog table/data dictionary/System catalog.

Information regarding about the three levels of schemas is stored in system catalog
Note: the collection of files corresponding to user tables and indexes represent data.
The data in a DBMS is described at 3 levels of abstraction.
The database description consists of a schema at each of these 3 levels of Abstraction.
1) The Conceptual
2) The Physical
3) External
 Fig: Levels of Schema

External Schema:
➢ External Schema or view level: data access to be authorized at the level of one user or
group of users
➢ the uppermost level is called view level. It describes only the part of database, a
variety of information is stored in database, but user want only some information to
access.

➢ The external schema is designed to guide the user requirement

➢ This level simplifies the user interaction with the system and hides the complexity
that arises in the conceptual schema

➢ The external schema consists of collection of one or more views and relations from
conceptual schema

➢ A user can only view the data in the form of a table, but it is not stored explicitly

➢ Eg: Course info(Sid:string,fname:string, enrollment: integer)

Conceptual Schema:
➢ The conceptual schema is called as Logical schema describes the stored data in terms
of the data model.

➢ In a Relational DBMS, Conceptual schema describes all relations that are stored in
the database.

➢ The choice of relations, and the choice of fields for each relation/table makes a good
conceptual schema called conceptual database design

Ex: University database

Entities: Students, Faculty, Courses, Rooms, DOE, Admissions, Departments, Sports etc.,
Relations: Enrolled, Teaches, Works in
Use conceptual schema to describe the above entities and relations
Students(sid: string, name: string, login : string, age : integer, cgpa : real)

Faculty(fid : string, fname : string, salary : real)

Courses(cid : string, cname :string, credits: integer)

Enrolled(sid : string, cid: string, grade: string)

Teaches(fid: string, cid :string)

Physical Schema:
➢ A Physical Data Model is a representation of a data design as implemented or
intended to be implemented in a DBMS.

➢ It typically derives from a logical data model, though it may be reverse-engineered

from a given database Implementation.

➢ It specifies additional storage details ie. How the relations in the conceptual schema is
stored on secondary storage devices such as Disks and Tapes.

➢ Stores all relations as unsorted files of records (A file in a DBMS is either a collection
of records or a collection of pages, rather than collection of characters as in operating
system)

Eg: Create Indexes on the first column of the students, Faculty courses relations the sal
column of faculty and the capacity column of rooms.

Decision about the physical schema are based on understanding how data is accessed. This
process of arriving a good physical schema is called physical database design

Data Independence

➢ Applications programs are insulated from changes in the way the data is structured
and stored.
➢ Data Independence is achieved through the three levels of Abstraction

➢ Relations in external schema are generated on demand from the relations to the
conceptual schema.

Two types of Data Independence

Logical data Independence

If any change is made to conceptual schema either by adding or removing columns from
table, it should not affect the user view.

Ex: Faculty(fid: string, fname: string, salary:real)

Changed to
Faculty_public (fid : string, fname: string, Dept: string)

Faculty_private ( fid : string, salary: real)

Physical data Independence

The conceptual schema insulates users from changes in physical storage details.

• If any changes are made to physical schema it doesn’t affect the conceptual schema or
external schema, the conceptual schema hides details such as how data is actually laid
on the disk, the file structure and choice of indexes.

• As long as the conceptual schema remains same, we can change these storage details
without altering applications.

• Example: zoom link insulated in glearn

QUERIES:

A Query is a request for data or information from a database table or combination of tables.
This data may be generated as results returned by Structured Query Language(SQL) or as
pictorials, graphs or complex results)

Eg: Consider the sample University Database?

1) What is the name of the student with student ID 1234567?

2) What is the average salary of professors who teach course CS5647?

3) How many students are enrolled in CS5647?

Such questions involving the data stored in a DBMS are called queries.

A DBMS provides a specialized language called the Query Language , in which queries can
be posed.

A feature of Relational Model is that supports powerful Query LANGUAGE(SQL)

SQL is a database query language used for storing and managing data in relational DBMS.

RDBMS(MySQL, Oracle, Infomix, MS Access) use SQL as the standard database Query
Language.

There are two Two formal Query Language:-

1) Relational Calculus

2) Relational Algebra
Relational Calculus is based on mathematical logic and queries in this language have an
intuitive , precise meaning.

Relational Algebra is based on a collection of operators for manipulating relations, which is

equivalent in power to the calculus.

Basic Structural Query Representation:

Basic structure of an SQL expression consists of select, from and where clause.
Select Clause: Lists attributes to be copied corresponds to relational algebra
project. From Clause: Corresponds to Cartesian Product -Lists Relations to be used.
Where Clause: Corresponds to selection predicate in relational Algebra
Syntax:
SELECT COLUMNS NAMES
FROM TABLE_NAME
WHERE CONDITION/QUALIFICATION
Eg: What is the name of the student with SID 1234567?
SELECT SNAME
FROM STUDENT
WHERE SID = 1234567;
Structure Of DBMS:

➢ The structure of a DBMS based on the Relational Data Model.

➢ The DBMS acts as an interface between the user and the database. The user requests
the DBMS to perform various operations such as insert, delete, update and retrieval
on the database.

➢ The components of DBMS perform these requested operations on the database and
provide necessary data to the users.

The DBMS accepts SQL commands generated from a variety of user interfaces. The Query
Evaluation Engine evaluates and executes a plan against the database, and returns the answer.
1) When a user issues a query, the parser, parses the given request i/p into machine
understandable language, and query optimizer optimizes and produces a plan for evaluating
the query like how the data is stored to produce an efficient plan for evaluating the query
2) An execution plan is a blueprint for evaluating a query, represented as a tree of relational
operators (operators serves as a building blocks for evaluating queries posed against data,
which brings the needed data to the main memory)
1. Plan executor uses operator evaluator to evaluate the plan
2. The code that implements relational operators are on top of the file and access
method.
3. This information is taken by file and access method for accessing the data which is
requested by the user that is present in the file system.
4. Buffer manager takes the responsibility for taking the data from disk to main memory
for execution.
5. Disk space manager takes the responsibility by providing space in the disk when the
data is modified.
6. Transaction manager ensures that transactions request and release locks according to a
locking protocol and schedules the execution transactions
7. Lock manager keeps track of request of locks and grants on database objects when
they are available.
8. DBMS supports Concurrency control and Crash Recovery by carefully scheduling
user requests and maintaining a log of all changes to the database.
9. Recovery manager maintains a log and restores the system to a consistent state when a
crash occurs.
People who work with DBMS:
➢ Users (End users, Naïve users, Sophisticated users)
➢ Data Implementers
➢ Application Programmers
➢ DBA
➢ Users: A primary goal of database system is to store the
➢ Data and retrieve the particular data from database whenever needed.

1) End users: users interact with system without writing programs, they generate request
what they want from system

2) Naïve users: who interact with system by invoking one of the application programs
that have been written previously. (ex: ATM, user simply enters PIN and then checks
their account status or withdraw the amount by invoking the application program
ATM, but he/she doesn’t bother about the appl. Program.

3) Sophisticated users/Data Analyst: uses SQL to generate answers for complex queries,
they use data mining tools and Online Analytical processing tools

4) Data Implementers: These are the people who actually develop DBMS software.

5) Application Programmers: These people develop packages that facilitate data access
for end users (various applications like university, Railways, Bank, etc.,)

6) Database Administrator: DBA takes the responsibility of designing and maintaining

the databases

Responsibilities of DBA:
➢ DBA designs the conceptual schema (what relations to store) and physical schema
(how to store them)

➢ DBA ensures that unauthorized data access is not permitted.

➢ DBA ensures security by granting permissions to different users to access the only
certain views and relations.

➢ DBA ensures crash recovery and takes necessary steps to restore the data to a
consistent state. DBA ensures data tuning i.e, takes the responsibility for
modifying the database, in particular conceptual and physical schema (basing on
users’ requirements)
 Part -II – DATA MODELS

Data Models:
➢ A database Model defines the Logical design and structure of a database and defines
how data will be stored, accessed and updated in a database Management System.

➢ It describes the design of database to reflect entities, attributes, relationship among

data , constraints etc.

➢ A data model is a collection of high-level data description constructs that hides many
low-level storage details. DBMS allows a users to define the data to be stored in terms
of data model.

Importance of Data Models:

➢ Ensures that all data objects required by the database are accurately represented.

➢ Data Model structure helps to define the relational tables, primary and foreign keys
and stored procedures.

➢ It provides a clear picture of the base data and can be used by database developers to
create a physical database.
➢ It is also helpful to identify missing and redundant data.

➢ Though the initial creation of data model is labor and time consuming, in the long run,
it makes your IT infrastructure upgrade and maintenance cheaper and faster.

Types of Data Models:

➢ FLAT Data Model

➢ Hierarchical Database Model

➢ Network Data Model

➢ Object Oriented Data Model

➢ Relational Data Model

➢ ER Model

FLAT Data Model:

It is a simplest Data Model, It simply lists all the data in a single table, consisting of Rows
and Columns.

In order to manipulate the data or access the data, the computer has to read the entire Flat File
into memory, ie., which makes this model inefficient for all, but it suitable only for smallest
data sets.
 Fig: Flat Database Model

Hierarchical Data Model:

This database model organizes data into a tree-like-structure, with a single root, to which all
the other data is linked. The hierarchy starts from the Root data, and expands like a tree,
adding child nodes to the parent nodes.

Advantages
➢ promotes data sharing.

➢ Parent/child relationship promotes conceptual simplicity.

➢ Database security is provided and enforced by DBMS.

➢ Parent/child relationship promotes data integrity.

➢ It is efficient with 1:M relationships.

Disadvantages:

➢ Complex to implement

➢ Difficult to manage

➢ Lacks structural independence

➢ Implementation’s limitations
➢ Lack of standards
 Fig: Hierarchical Data Model

Network Data Model:

➢ The network model replaces the hierarchical model with a graph thus allowing more
general connections among the nodes
➢ In this model data is organized more like a graph, and are allowed to have more than
one parent node.
➢ Represent complex data relationships more effectively
o Improve database performance
o Impose a database standard
Advantages:
➢ The network model can handle the one to many and many to many relationships
which is real help in modeling the real-life situations.
➢ The data access is easier and flexible than the hierarchical model.
Disadvantages
➢ All the records are maintained using pointers and hence the whole database
structure becomes very complex.
➢ The insertion, deletion and updating operations of any record require large
number of pointers adjustments.

The Object-Oriented Model:

➢ This model is based on collection of objects. An object contains values stored in
instance variables with in the object. An object also contains bodies of code that
operate on the object. These bodies of code are called methods. Objects that contain
same types of values and the same methods are grouped together into classes.
➢ Modeled both data and their relationships in a single structure known as an object
➢ Object-oriented data model (OODM) is the basis for the object-oriented database
management system (OODBMS)
➢ ODM is said to be a semantic data model
The Relational Data Model:
➢ Developed by Codd (IBM) in 1970
➢ The Central Data Description construct in this model is a relation, which can be a set
of Records.
➢ A description of data in terms of a Data Model is called a Schema.
➢ In this Mode, the schema for a relation its name, the name of each field(attribute or
column).
Eg: Schema:
Students(Sid: string, sname: string, age:integer)

The Entity Relationship Model

➢ Widely accepted and adapted graphical tool for data modeling
➢ Introduced by Chen in 1976
➢ Graphical representation of entities and their relationships in a database structure
➢ Entity relationship diagram (ERD)
o Uses graphic representations to model database components
o Entity is mapped to a relational table
➢ Entity instance (or occurrence) is row in table
➢ Entity set is collection of like entities
➢ Connectivity labels types of relationships
➢ Diamond connected to related entities through a relationship line
Physical data models:

describe how data is stored as files in the computer by representing information such as
record formats, record orderings, and access paths. Physical data model represent the model
where it describes how data are stored in computer memory, how they are scattered and
ordered in the memory, and how they would be retrieved from memory. Basically physical
data model represents the data at data layer or internal layer.

XML Data Model:

An XML database is a is a database that can be used to store large amounts of data or
information in the XML format. They can handle data which is of any size or format. XML is
a markup language that uses “tags” or specially formatted text labels, to identify the function
of varied data elements within a document. XML databases are a flavor of document-oriented
databases which are in turn a category of NoSQL database. This data can be queried,
transformed, exported and returned to a calling system.

A key-value database:
also known as a key-value store is a type of non-relational database that uses a simple key-
value method to store data. A key-value database stores data as a collection of key-value pairs
in which a key serves as a unique identifier. Both keys and values can be anything, ranging
from simple objects to complex compound objects.
Ex: HBase runs on top of HDFS (Hadoop Distributed File system), providing BigTable- like
capabilities for Hadoop. HBase is a key/ value store.

What is SQL vs NoSQL vs key-value?

SQL databases are vertically scalable, while NoSQL databases are horizontally scalable. SQL
databases are table-based, while NoSQL databases are document, key-value, graph, or wide-
column stores. SQL databases are better for multi-row transactions, while NoSQL is better
for unstructured data like documents or JSON

PART -II -ER MODEL – ENTITY RELATIONSHIP MODEL

Introduction to Database Design

To design any of the database, we need 6 steps:

3 Steps Belong to ER Diagrams/Models

3 Steps are beyond the ER

➢ The Conceptual Model Is To Establish The Entities, Their Attributes, And Their
Relationships.

➢ The Logical Data Model Defines The Structure Of The Data Elements And Set The
Relationships Between Them.
➢ The Physical Data Model Describes The Database-Specific Implementation Of The
Data Model.
1) Requirement Analysis:
Understand what data is to be stored in database. This process is done by system
analyst of the enterprise/software company by conducting discussions with
groups/owners of the organization.

2) Conceptual Design:
The information gathered in the above step is used to develop a high-level description
of data to be stored in the database, along with constraints. It is transformed to ER
data Model.

3) Logical Data Design:

The ER diagrams are converted into database schema in the data model of the chosen
DBMS.

4) Schema Refinement and Normalization:

The initial set of tables that we got from logical data design may not be exact table, so
we need to refine them by applying normalization techniques to get the final set of
exact tables.

5) Physical Database Design:

For the above refined tables, the corresponding physical files and indexes are
designed.

6) Application and Security Design:

Design Methodologies like UML try to address complete s/w design and development
cycle. Identify entities and processes involved in application.
 ER MODEL
It is a Graphical or Visual Representation of Data and describes how data is related
to each other.

➢ What are the entities and relationships in the enterprise?

➢ What type of information about these entities and relationships should we store in
the database?

➢ What are the integrity constraints or business rules that hold?

➢ A database `schema’ in the ER Model can be represented pictorially (ER diagrams).

➢ Can map an ER diagram into a relational schema

➢ Entities - An entity is a real-world object that are represented in database. Data are
stored about such entities. It can be any object, place, person or class.

➢ Example – University DB- Student, Faculty, Department, Employees,Courses(

Entities)
➢ Entity sets – An Entity set is a set of entities of the same type that shares same
properties or attributes.
➢ Example – In our University DB- Entity set is Faculty – set of all Faculties

➢ In our University DB – Entity set is Student – Set of all students

➢ Attributes – It is a characteristic of an Object or Entity

Example – Student Entity – SID,SNAME,Phone Number, Mail ID etc

Faculty Entity – Fid, Fname, mailid, phone number etc

Symbols and Notations:-

Example:
Types of Attributes

1. Simple attributes
2. Composite attributes
3. Single valued attributes
4. Multi valued attributes
5. Derived attributes
6. Key attributes
7. Descriptive Attribute
➢ Simple Attributes- Simple attributes are those attributes which can not be divided
further. Ex: age, class
➢ Composite Attributes- Composite attributes are those attributes which are composed
of many other simple attributes. Ex: Address, name

➢ Single Valued Attributes- Single valued attributes are those attributes which can
take only one value for a given entity from an entity set. Ex: gender, age

➢ Multi Valued Attributes- Multi valued attributes are those attributes which can take
more than one value for a given entity from an entity set. Ex: mobile no, email- id

➢ Derived Attributes- Derived attributes are those attributes which can be derived from
other attribute(s). Ex: Age is derived from DOB

➢ Key Attributes- Key attributes are those attributes which can identify an entity
uniquely in an entity set.
Ex: Sno
Minimal set of attributes who values are uniquely identify an entity in the entity set
{Sno, sno+sname, Sno+saddr+sname}
 Descriptive Attribute- Descriptive attributes are used to record information about
the relationship, rather than about any one of the participating entities
Relationship and Relationship sets:

A Relationship is an association among several entities. For Example, we can define a

relationship Advisor or teaches that associates between two entities Faculty and Student
.

Types of Relationships:
The Association between more than one entity is called a Relationship. It represents in
Diamond shape.

➢ Unary Relationship
➢ Binary Relationship
➢ Ternary Relationship
Fig: Unary Relationship

Fig: Binary and Ternary Relationship

 Conceptual Schema:
Employees(ssn: integer,name:string, iot:real)
Departments(did:integer,dname:string,budget:real)
Manages( ssn:integer,did:string,since:string)

Strong Vs. Weak entity type

➢ Strong Entity: Entity that has its own key attribute.
E.g.: Employee, student, customer, policy holder etc.
➢ Weak entity: Entity that depends on other entity for its existence and doesn’t have key
attribute of its own
Eg: spouse of employee
Mapping Cardinality:
Cardinality tells how many times the entity of an entity set participates in a relationship
1) One- to –One
2) One-to-Many
3) Many-to-One
4) Many-to-Many
1) One-to-one: An Entity in A is related to one entity in B, and an entity in B is related
to atmost one entity in A.

P1
C1
P2
C2
P3
C3
P4
C4
Fig: One-To-One
2) One- to-Many: An entity in A is related to any number of entities in B, but an entity
in B is related to atmost one entity in A.

E1
O1
E2
O2
E3
O3
E4

E5

Fig: One-to-Many

3) Many-to-One:
An Entity in A is related to atmost one entity in B, but an entity in B is related to any
number of entities in A.

E1
D1
E2
D2
E3
D3
E4

E5

Fig: Many-to-One
4) Many-to-Many:
An Entity in A is related to any number of entities in B, an entity in B is related to any
number of entities in A.

S1
C1
S2
C2
S3
C3
S4 C4
Keys:
A Key is a minimal set of Attributes whose values uniquely identify an entity in the set.
Types of Keys:
1) Super Key
2) Candidate Key
3) Primary Key
4) Composite Key
5) Alternate Key
6) Foreign Key

Super Key:
A super key is a set of one of more columns(attributes) to uniquely identify the rows/tuples in
a table/relation
. Student Table
SID SNAME Phone Age CGPA
number
1 Raghu 98756 25 8.8
2 Sravya 95678 22 9.0
3 Kavya 98515 23 8.5
4 kavya 6556 23 9.0
5 Sravya 921451 26 8.5
Step 1:{sid}{sname}{ph number}{age}{cgpa}
Step 2: {sid,sname}{sid, phone number}{sid, age}{sid,cgpa}{sname,sid}{sname,ph
num} {sname,age} -Not Found {sname,cgpa} -Not Found {Phone number,age} {Phone
number,cgpa}{Age,sid}{age,sname}{age,ph num}{age,cgpa}
Step 3:
{sid, sname, phone number} ……Etc
Super Key Set:{ Sid,sname,phone number,cgpa}
Candidate Key:

A super key set with no redundant attribute is known as candidate key.

Or
Minimal set of Fields/attribute uniquely identify each record in a table/relation.
1) A Candidate Key can never be NULL or Empty. Its values should be unique.
2) There can be more than one candidate key for a relation or table
or

3) A Candidate key can be combination of more than one attributes.

Candidate Key{Sid, Phone number}

SID SNAME Phone Age CGPA

number
1 Raghu 98756 25 8.8
2 Sravya 95678 22 9.0
3 Kavya 98515 23 8.5
4 NULL 55646 23 9.0
5 Sravya 921451 26 8.5

PRIMARY KEY
Candidate Key is also called as Primary Key
{SID}
Criteria(PK)
1) The Primary Key Values should NOT BE NULL/EMPTY
2) The values entered should be UNIQUE
3) It should not contain any Redundancy Data.
Foreign Key:
Foreign Key are the columns of a table that points to the primary key of another table.
Eg: Student Table- Sid(PK)
Course Table- Cid(PK)
Enrolls -sid, cid
(Sid references student)
(cid references courses)
Composite Key:
Key that consists of 2 or more attributes that uniquely any record in a table is called
composite Key.
But the attributes which together form the composite key are not a key independent or
individually.
Eg: Sid,sub id marks
Sid and sub id both are required for getting data of marks.

Alternate Key:
Out of all candidate keys, only one gets selected as Primary key, remaining keys are known
as alternate keys or secondary keys.
Features of ER Model:
1) Key Constraints
2) Participation Constraints
3) Weak Entity
4) Class Hierarchies
5) Aggregation

Key Constraints: It is a condition or restriction, that each department has atmost one

manager is an Eg of Key Constraint.

Fig: Key Constraint on Manages – Binary Relationship set

Key Constraints for Ternary Relationships:

Each Employee works in at most one department and at a single Location.

Note: That each department can be associated with several employees and locations and each
location can be associated with several department and employees.
Participation Constraints:

➢ Total Participation
➢ Partial Participation

➢ The Participation of the entity set departments in the relationship set manages is said
to be total.
➢ A Participation ie., is not total is said to be a Partial.

➢ For Eg, The Participation of the Entity set Employees in Manages is partial, since not
every employee gets to manage a department.

Fig: Participation Constraint

Weak entity:

A weak entity set is one which does not have any primary key associated with it.

A weak entity type normally has partial key which is the set of attributes that can uniquely
identify weak entities that are related to same owner entity.

A Weak Entity can be identified uniquely only by considering the primary key of another
entity.

Owner Entity set and Weak entity set must participate in a one-to-many Relationship set.

Weak Entity set must have Total Participation in this identifying relationship set.

Fig: Weak Entity Set

Class Hierarchy:
➢ A class hierarchy or inheritance tree is a classification of object types, denoting
objects as the instantiations of classes (class is like a blueprint, the object is what is
built from that blueprint) inter-relating the various classes by relationships such as
"inherits", "extends", "is an abstraction of", "an interface definition".

➢ It is required to classify the entities in a Entity set into subclasses.

➢ For Example, Consider a Hours_Emp Entity set and a contract_Emps set to

distinguish the basis on which they are paid.
➢ Note: If we declare A ISA B, every A entity is also considered to be a B entity.

Fig : Class Hierarchy – ISA Relationship

We can specify two kinds of constraints w.r.to ISA Hierarchies

a) Overlap Constraint
b) Covering Constraints

a) Overlap Constraint: It determines whether two subclasses are allowed to contain the
same entity.
Eg:- Consider a person, can be both hour_Emp Entity and Contract_Emp Entity?
Ans-No

Can he be a both a Contarct_Emps Entity and a senior_Emp

Entity? Ans- YES
So, we can represent the data.

‘CONTRACT_EMPS OVERLAPS SENIOR_EMPS’

b) Covering Constraint: It determine, whether the entities in the subclasses collectively

include all entities in the superclass.
Eg_ Does Every Employee have to belong to only one of the sub classes – Ans: NO
 Does Every Motor_Vehicles Entity have to be either a Motorboats Entity or a
Cars Entity – Ans: YES
So, we can denote this by writing
‘Motorboats AND Car COVER Motor_Vehicles’
‘Hours_Emps AND Contract_EMP COVER Employees’
2 Approaches:
1) Specialization
2) Generalization

1) Specialization:
Employees is specialized into sub classes.
Specialization is the process of identifying subsets of an Entity set (Super Class) that
share some characteristic.

Superclass is defined first, then the sub classes are defined next, and later specific
attributes and relationship sets are added.

Fig: Specialization- Top Down Approach

2) Generalization:
Generalization is a bottom-up-approach in which two lower level entities combine to
form a higher level entity.
Its more like superclass and sub class system, but the only difference is the approach,
which is bottom-up. Hence, entities are combined to form a more generalized Entity.
 Fig: Generalization – Bottom-Up Approach

Aggregation:
Aggregation is a process when relation between two entities is treated as a single Entity.
Aggregation allows us to treat a relationship set as entity set for purposes of participation in
other relationships.

Fig: Aggregation
Conceptual Design with the ER Model:
Developing an ER Diagram present several choices, including the following:
a) Should a concept be modeled as an entity or an attribute?
b) Should a concept be modeled as an entity or a Relationship?
c) What is the Relationship sets and their participating entity sets?
should we use Binary or Ternary Relationships?
d) Should we use Aggregation?

1) Entity Vs Attribute
2) Entity Vs Relationship
3) Binary Vs Ternary Relationship
4) Aggregation Vs Ternary Relationships
Entity Vs Attribute:
➢ Should address be an attribute of Employees or an Entity (Connected to Employees
by a relationship)?

➢ Depends upon the use we want to make of address information, and the semantics of
the data:

For example, consider

adding address information to the Employees entity set. One option is to use an attribute address. This
option is appropriate if we need to record only one address per employee, and it suffices to think of an
address as a string. An alternative is to create an entity set called Addresses and to record associations
between employees and addresses using a relationship (say, Has_Address).
 Fig: Entity Vs Attribute

Entity Vs Relationship:
What if a manager gets discretionary budget that covers all managed depts?
Redundancy – dbudget stored for each department managed by manager.
Misleading: suggests dbudget associated with department-mgr. combination.

Fig: Entity Vs Relationship

Binary Vs Ternary Relationship:

By observing this ER Model, it can describing that as follows:

An Employee can own several policies.
Each policy can be owned by several employees.
Each dependent can be covered by several polocies.
This diagram indicates all are in a association mode.suppose that we have the following
additional requirements:
a) A policy cannot be owned jointly by two or more employees.
b) Every Policy must be owned by some employee
 c) Dependents is a weak entity set, and each dependent entity is uniquely identified by
taking pname along with policy id of a policy entity.

Ist Requirement: we can impose a Key Constraint on policies with respect to covers, but that
the policy can cover only one dependent.
IInd Requirement: We can impose a total participation constraint on policies.
IIIrd Requirement: In given fig, we cannot identify

Fig: Binary Vs Ternary Relationship

Aggregation versus Ternary Relationships:

According to this diagram, a project can be sponsored by any number of departments, a

department can sponsor one or more projects, and each sponsorship is monitored by one
or more employees.

If we don't need to record the until attribute of Monitors, then we might reasonably use a
ternary relationship as follows.

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