DATABASE MANAGEMENT SYSTEMS

UNIT 1 – TOPIC 1
INTRODUCTION TO DBMS
Database

A database is a collection of data, typically describing the activities of one or more related
organizations.

Example: a university database might contain information about the following:

• Entities such as students, faculty, courses, and classrooms.
• Relationships between entities, such as students' enrollment in courses, faculty teaching
courses, and the use of rooms for courses.

Database Management System (DBMS)

 A database management system, or DBMS, is software designed to assist in maintaining
and utilizing large collections of data.
 The alternative to using a DBMS is to store the data in files and write application-specific
code to manage it.

A Historical Perspective or History of Data base Systems

 Finding information from a huge volume of papers or deleting/modifying an entry is a

difficult task in pen and paper based approach.
 To overcome the hassles faced in manual record keeping, it is desirable to
computerize storage of data.
 From the earliest days of computers, storing and manipulating data have been a major
application focus.
 In the late 1960s, IBM developed the Information Management System (IMS) DBMS,
used even today in many major installations.
 IMS formed the basis for an alternative data representation framework called the
hierarchical data model.
 In 1970, Edgar Codd, at IBM's San Jose Research Laboratory, proposed a new data
representation framework called the relational data model.
 In the 1980s, the relational model consolidated its position as the dominant DBMS
paradigm, and database systems continued to gain widespread use.
 SQL was standardized in the late 1980s, and the current standard, SQL: 1999, was
adopted by the American National Standards Institute (ANSI) and International
Organization for Standardization (ISO).
 Specialized systems have been developed by numerous vendors for creating data
warehouses, consolidating data from several databases, and for carrying out
specialized analysis.
 Commercially, database management systems represent one of the largest and most
vigorous market segments.
 FILE SYSTEMS VERSUS DBMS

File System Database Management System (DBMS)

1. It is a software system that manages 1. It is a software system used for creating and managing the
and controls the data files in a computer databases. DBMS provides a systematic way to access, update,
system. and delete data.

2. File system does not support multi-

2. Database Management System supports multi-user access.
user access.

3. Data consistency is less in the file

3. Data consistency is more due to the use of normalization.
system.

4. File system is not secured. 4. Database Management System is highly secured.

5. File system is used for storing the 5. Database management system is used for storing the
unstructured data. structured data.

6. In the file system, data redundancy is

6. In DBMS, Data redundancy is low.
high.

7. No data backup and recovery process

7. There is a backup recovery for data in DBMS.
is present in a file system.

8. Handling of a file system is easy. 8. Handling a DBMS is complex.

9. Cost of a file system is less than the 9. Cost of database management system is more than the file
DBMS. system.

10. If one application fails, it does not 10. If the database fails, it affects all application which depends
affect other application in a system. on it.

11. In the file system, data cannot be

11. In DBMS, data can be shared as it is stored at one place in a
shared because it is distributed in
database.
different files.

12. These system does not provide

12. This system provides concurrency facility.
concurrency facility.

13. Example: NTFS (New technology

13. Example: Oracle, MySQL, MS SQL Server, DB2,
file system), EXT (Extended file
Microsoft Access, etc.
system), etc.
ADVANTAGES OF A DBMS

 Data Independence: The DBMS provides an abstract view of the data that hides data
representation and storage details.
 Efficient Data Access: A DBMS utilizes a variety of sophisticated techniques to store
and retrieve data efficiently.
 Data Integrity and Security: If data is always accessed through the DBMS, the DBMS
can enforce integrity constraints. For example, before inserting salary information for an
employee, the DBMS can check that the department budget is not exceeded. Also, it can
enforce access controls that govern what data is visible to different classes of users.
 Data Administration: When several users share the data, centralizing the administration
of data can offer significant improvements.
 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. Further, the DBMS protects users from the effects of system failures.
 Reduced Application Development Time: The high-level interface to the data,
facilitates quick application development.

Database System Applications

Applications where we use Database Management Systems are:

• Telecom: There is a database to keep track of the information regarding calls made,
network usage, customer details etc. Without the database systems it is hard to maintain
that huge amount of data that keeps updating every millisecond.
• Industry: Where it is a manufacturing unit, warehouse or distribution centre, each one
needs a database to keep the records of ins and outs. For example distribution centre
should keep a track of the product units that supplied into the centre as well as the
products that got delivered out from the distribution centre on each day; this is where
DBMS comes into picture.
• Banking System: For storing customer info, tracking day to day credit and debit
transactions, generating bank statements etc. All this work has been done with the help of
Database management systems.
• Education sector: Database systems are frequently used in schools and colleges to store
and retrieve the data regarding student details, staff details, course details, exam details,
payroll data, attendance details, fees details etc. There is a hell lot amount of inter-related
data that needs to be stored and retrieved in an efficient manner.
• Online shopping: You must be aware of the online shopping websites such as Amazon,
Flipkart etc. These sites store the product information, your addresses and preferences,
credit details and provide you the relevant list of products based on your query. All this
involves a Database management system.
 DATABASE MANAGEMENT SYSTEMS
UNIT 1 – TOPIC 2
DATA MODELS

DATA MODEL
 A data model is the underlying structure of DBMS. It is a collection of high-level data
description constructs that hide many low-level storage details.
 A data model describes how a database’s logical structure is represented.
 It is a conceptual tool used to describe data, relationship, semantics and constraints.
 Most database management systems today are based on the relational data model.
 A semantic data model is a more abstract, high-level data model that makes it easier for
a user to come up with a good initial description of the data in an enterprise.
 A widely used semantic data model called the entity-relationship (ER) model allows us to
pictorially denote entities and the relationships among them.

Data model types

• Older models:
– Network model
– Hierarchical model
• Relational model
• Entity-Relationship data model (mainly for database design)
• Object-Oriented data models

Hierarchical Model
 Hierarchical Model was the first DBMS model.
 This model organizes the data in the hierarchical tree structure.
 The hierarchy starts from the root which has root data and then it expands in the form
of a tree adding child node to the parent node.
 This model easily represents some of the real-world relationships like food recipes,
sitemap of a website etc.
Network Model
 This model is an extension of the hierarchical model.
 It was the most popular model before the relational model.
 This model is the same as the hierarchical model; the only difference is that a record
can have more than one parent.
 It replaces the hierarchical tree with a graph.

Relational model

 The central data description construct in this model is a relation, which can be thought
of as a set of records.
 A description of data in terms of a data model is called a schema.
 In the relational model, the schema for a relation specifies its name, the name of each
field (or attribute or column), and the type of each field.
 Students ( sid: string, name: string, login: string, age: integer, gpa: real)
Entity-Relationship Model

 Entity-Relationship Model or simply ER Model is a high-level data model diagram.

 In this model, we represent the real-world problem in the pictorial form to make it
easy for the stakeholders to understand.
 It is also very easy for the developers to understand the system by just looking at the
ER diagram.
 We use the ER diagram as a visual tool to represent an ER Model.

Object-Oriented Data Model

 The real-world problems are more closely represented through the object-oriented
data model.
 In this model, both the data and relationship are present in a single structure known as
an object.
 We can store audio, video, images, etc in the database which was not possible in the
relational model (although you can store audio and video in relational database, it is
advised not to store in the relational database).
 In this model, two are more objects are connected through links. We use this link to
relate one object to other object.
 DATABASE MANAGEMENT SYSTEMS
UNIT 1 – TOPIC 3
LEVELS OF ABSTRACTION & DATA INDEPENDENCE

LEVELS OF DATA ABSTRACTION

In a Database Management System (DBMS), abstraction refers to the process of hiding the
complexity of the underlying data structure and operations from the users. This abstraction is
essential for managing large volumes of data efficiently and for providing a simplified
interface for users to interact with the database.

There are 3 level architecture of database design.

Physical level / Internal View: (How) it is the lowest level of data abstraction. It tells us
how the data is actually stored in memory. While designing the database few basic
information needs to be considered like, storage allocation, indexing methods, data retrieval
mechanisms, usability, size of the memory etc.

Example : record : customer

Logical level / Conceptual View: (What) The conceptual level, also known as the logical
level, is the level of abstraction that defines the overall structure (schema) of the database. It
hides the details of the physical storage from the database users and applications . It defines
the relationships and constraints among the data elements without specifying how the data is
physically stored.

The conceptual level is designed to provide a high-level view of the database that is
independent of any specific implementation. It allows users to define the structure of the
database in a way that is meaningful to them without worrying about the details of how the
data is stored or accessed.

Example : type customer = record

customer_id : string;
customer_name : string;
customer_street : string;
customer_city : string;
end;
 View level / External View: (Who)
The external level, also known as the View level, is the highest level of abstraction and is
closest to the end users. It defines how the data is viewed by the users or applications that
access the database. It provides a high-level view of the database that is tailored to the
specific needs of each user or application.

The external level is designed to provide a level of abstraction that shields the users or
applications from the complexities of the underlying database. It allows users to work with
the data in a way that is meaningful to them without worrying about the details of how the
data is stored or organized.

Benefits of Levels of Abstraction in DBMS

The levels of abstraction in DBMS provide several benefits to users and applications,
including:

 The levels of abstraction in DBMS provide a separation between the way data is viewed by
users or applications and how it is stored and accessed by the database management system.
This allows changes to be made to the physical storage and access methods without affecting
the external or conceptual levels.

 The levels of abstraction in DBMS make it easier for database administrators to manage the
database. They can make changes to the physical storage and access methods without
affecting the users or applications that interact with the database.

 The levels of abstraction in DBMS allow the database management system to optimize the
physical storage and access methods for performance without affecting the way data is
viewed by users or applications.

 The levels of abstraction in DBMS allow users or applications to view the data in a way that
is meaningful to them without worrying about the underlying implementation details. This
makes it easier to adapt to changing business requirements and user needs.

Data Independence

The ability to modify the schema in one level without affecting the schema in next higher
level is called data independence. It helps to keep the data separated from all programs that
makes use of it.

 Physical Data Independence – The ability to modify the physical schema without
changing the logical schema. It helps to keep the data separated from all program that
makes use of it. Example: The Conceptual structure of the database would not be
affected by any changes like utilizing a new storage device, change in storage size of
the database system server, modifying the data structures used for storage, using an
alternate file organization technique, changing from sequential to random access files
etc.
 Logical data independence: The ability to modify the logical schema without
affecting the schema in next higher level (external schema). The user view of the data
would not be affected by any changes to the conceptual view of the data. These
changes may include insertion or deletion of attributes, altering table structures
entities or relationships to the logical schema, etc.
 DATABASE MANAGEMENT SYSTEMS
UNIT 1 – TOPIC 4
STRUCTURE OF DBMS

STRUCTURE OF DBMS

Database Management System is the combination of a Database and all the functionalities to
organize and manage the data. It is software that allows us to efficiently interact with data at
various levels of abstraction.

As Database Management System is a complex set of programs, it is necessary to understand all

the components of DBMS so that we can easily manage the database

● A database system is partitioned into modules, each of that deal with responsibilities of the
overall system.
● The structure of DBMS refers to the logical representation of all of its modules.
● The functional components of a database system can be broadly divided into the
o Query processor
o Storage manager and
o Disk Storage

o
1. Query Processor:
It interprets the requests (queries) received from end user via an application program into
instructions. It also executes the user request which is received from the DML compiler.

Query Processor contains the following components

● DDL Interpreter –
DDL Interpreter interprets DDL statements like those used in schema definitions (such as
create, remove, etc.). This interpretation yields a set of tables that include the meta-data
(data of data) that is kept in the data dictionary.
● DML Compiler –
DML Compiler converts DML statements like select, update, and delete into low-level
instructions or simply machine-readable object code, to enable execution. It processes the
DML statements into low level instruction (machine language), so that they can be
executed.
● Query Evaluation Engine –
It evaluates the SQL commands used to access the database's contents before returning the
result of the query. A single query can be translated into a number of evaluation plans.
● Query Optimizer –
query optimization determines the most effective technique to carry out a query.

2. Storage Manager :
● Storage Manager is a program that provides an interface between the data stored in the
database and the queries received.
● It is also known as Database Control System.
● It maintains the consistency and integrity of the database by applying the constraints and
executes the DCL statements.
● It is responsible for updating, storing, deleting, and retrieving data in the database.

It contains the following components –

● Authorization Manager –
It ensures role-based access control, i.e. it checks whether the particular person is privileged to
perform the requested operation or not.

● Integrity Manager –
It checks the integrity constraints when the database is modified.

● Transaction Manager –
It controls concurrent access by performing the operations in a scheduled way that it receives
the transaction. Thus, it ensures that the database remains in the consistent state before and after
the execution of a transaction.

● File Manager –
It manages the file space and the data structure used to represent information in the database.
● Buffer Manager –
It is responsible for cache memory and the transfer of data between the secondary storage and
main memory.

3. Disk Storage:
A DBMS can use various kinds of Data Structures as a part of physical system implementation
in the form of disk storage.

It contains the following components – Data Files, Data Dictionary, and Indices

Data Files – It stores the data in the files supported by the native Operating System.

Data Dictionary – It contains the information about the structure of any database object. It is
the repository of information that governs the metadata.

Indices – These indices are used to access and retrieve the data in a very fast and efficient way.
It provides faster retrieval of data item.

Types of Database Users

1. Database Administrator (DBA):

• It is a person or a team, who is responsible for managing the overall database
management system.
• It is the leader of the database. It is like a super-user of the system.
• It is responsible for the administration of all the three levels of the database.

DBA is responsible for:

• Deciding the instances for the database.

• Defining the Schema
• Liaising with Users
• Define Security
• Back-up and Recovery
• Monitoring the performance

2. Database Designers:
• Database designers design the appropriate structure for the database, where we share
data.

3. System Analyst:
• System analyst analyses the requirements of end users, especially naïve and
parametric end users.

4. Application Programmers:
• Application programmers are computer professionals, who write application
programs.
5. Naïve Users / Parametric Users:
• Naïve Users are Un-sophisticated users, which has no knowledge of the database.
These users are like a layman, which has a little bit of knowledge of the database.
• Naive Users are just to work on developed applications and get the desired result.
• For Example: Railway’s ticket booking users are naive users. Or Clerical staff in any
bank is a naïve user because they don’t have any DBMS knowledge but they still use
the database and perform their given task.

6. Sophisticated Users:
• Sophisticated users can be engineers, scientists, business analyst, who are familiar
with the database. These users interact with the database but they do not write
programs

7. Casual Users / Temporary Users:

• These types of users communicate with the database for a little period of time.
 DATABASE MANAGEMENT SYSTEMS
UNIT 1 – TOPIC 5
Database Design and E R Model

Database design is the set of procedures or collection of tasks used for organizing the data to
implement a database.
It involves several key steps to ensure efficient storage, retrieval, and manipulation of data.

The database design process can be divided into six steps. The ER model is most relevant to
the first three steps.

1. Requirements Analysis:
 what data is to be stored in the database,
 what applications must be built on top of it, and
 what operations to be performed to meet performance requirements.

2. Conceptual Database Design: Based on the information gathered, develop a high-

level description of the data to be stored in the database, along with the constraints.

3. Logical Database Design: We must choose a DBMS to implement our database

design, and convert the conceptual database design into a database schema in the data
model of the chosen DBMS.

4. Schema Refinement: The fourth step in database design is to analyze the collection
of relations in our relational database schema to identify potential problems, and to
refine it.

5. Physical Database Design: In this step, we consider typical expected workloads that
our database must support and further refine the database design to ensure that it
meets desired performance criteria.

6. Application and Security Design: Any software project that involves a DBMS must
consider aspects of the application that go beyond the database itself. Implement
security measures such as authorization, authentication, and encryption to protect the
database. Enforce data integrity etc.

Entity-Relationship Model:

• An Entity-Relationship Model specifies the enterprise schema that represents the

logical structure of the database graphically.

• 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.

• It provides useful concepts that allow us to move front an informal description of

what users want from their database to a more detailed, precise description that can be
implemented in a DBMS.
 History of ER models

• Peter Chen proposed ER Diagrams in 1971 to create a uniform convention that can be
used as a conceptual modeling tool.

• ER diagrams are used to model and design relational databases.

Components of ER Diagram:

Entity and Entity Set:

● An entity is an object that exists and is distinguishable from other objects. Entities are
objects of physical(Person, place, thing) or conceptual existence (sales, concert etc.)
– Examples:
• Person: PROFESSOR, STUDENT
• Place: STORE, UNIVERSITY
• Object: MACHINE, BUILDING
• Event: SALE, REGISTRATION

● An entity is represented with a RECTANGLE

An entity set is a set of entities of the same type that share the same properties.
Example: set of all persons, companies, trees, holidays

Strong Entity

The Strong Entity is the one whose existence does not depend on the existence of any
other entity in a schema. It is denoted by a single rectangle. A strong entity always has the
primary key in the set of attributes that describes the strong entity. It indicates that each
entity in a strong entity set can be uniquely identified.
Set of similar types of strong entities together forms the Strong Entity Set. A strong entity
holds the relationship with the weak entity via an Identifying Relationship, which is
denoted by double diamond in the ER diagram. On the other hands, the relationship
 between two strong entities is denoted by a single diamond and it is simply called as a
relationship.

Weak Entity
A Weak entity is the one that depends on its owner entity i.e. a strong entity for its
existence. A weak entity is denoted by the double rectangle. Weak entities do not have
the primary key instead it has a partial key that uniquely discriminates the weak entities.
The primary key of a weak entity is a composite key formed from the primary key of the
strong entity and partial key of the weak entity.
The collection of similar weak entities is called Weak Entity Set. The relationship
between a weak entity and a strong entity is always denoted with an Identifying
Relationship i.e. double diamond.

ATTRIBUTES
• An entity is represented by a set of attributes that is descriptive properties possessed
by all members of an entity set.
Example:
• customer = (Customer_id, name, street, city, salary )
• movie= (title, director, written by, duration, release date)

Attributes are represented with ELLIPSE

Use LINES to link attributes to entities

An attribute can be of many types, here are different types of attributes defined in ER database
model:
1. Simple attribute: The attributes with values that are atomic and cannot be broken down
further are simple attributes. For example, student's age.

2. Composite attribute: A composite attribute is made up of more than one simple

attribute. For example, student's address will contain, house no., street name, pin
code etc.

3. Derived attribute: These are the attributes which are not present in the whole database
management system, but are derived using other attributes. For example, average age of
students in a class.

Example: age, and its value is derived from the stored attribute Date of Birth.

4. Single-valued attribute: As the name suggests, they have a single value.

5. Multi-valued attribute: They can have multiple values.

 Relationship
• It is an association between two entities. It shows how the two entities are connected.
• Named set of all similar relationships with the same attributes and relating to the same
entity types
• Relationship is represented with DIAMOND

Teaches

• Relationships relate entities within the entity sets involved in the relationship type to
each other.

ER – Relationships
Relationship Set: Collection of similar relationships.
• An attribute can also be property of a relationship set. For instance, the depositor
relationship set between entity sets customer and account may have the attribute
access-date
Mapping Cardinality
Types of Relationships
• Three types of relationships can exist between entities
• One-to-one relationship (1:1): One instance in an entity (parent) refers to one and
only one instance in the related entity (child).
• One-to-many relationship (1:M): One instance in an entity (parent) refers to one or
more instances in the related entity (child)
• Many-to-many relationship (M:N): exists when one instance of the first entity
(parent) can relate to many instances of the second entity (child), and one instance of
the second entity can relate to many instances of the first entity.
 DATABASE MANAGEMENT SYSTEMS
UNIT 1 – TOPIC 6
Database Design and E R Model

Degree of Relationship
A Relationship describes relation between entities. Relationship is represented using diamonds
or rhombus.

Degree of relationship represents the number of entity types that associate in a relationship.
Types:
Now, based on the number of linked entity types, we have 4 types of degrees of relationships.
1. Unary Relationship
2. Binary Relationship
3. Ternary Relationship
4. N-ary Relationship

1. Unary Relationship
In this type of relationship, both the associating entity type are the same. in other words, in a
relation only one entity set is participating then such type of relationship is known as a unary
relationship or Recursive Relationship

Example: In a particular class, we have many students, there are monitors too. So, here class
monitors are also students.

2. Binary Relationship
In a Binary relationship, there are two types of entity associates.

In other words, in a relation when two entity sets are participating then such type of
relationship is known as a binary relationship. This is the most used relationship and one can
easily be converted into a relational table.

This is further divided into three types.

One to One Relationship
This type of relationship is rarely seen in real world

The above example describes that one student can enroll only for one course and a course
will also have only one Student. This is not what you will usually see in real-world
relationships.

One to Many Relationships

The below example showcases this relationship, which means that 1 student can opt for many
courses, but a course can only have 1 student. Sounds weird! This is how it is.

Many to One Relationship

It reflects business rule that many entities can be associated with just one entity. For example,
Student enrolls for only one Course but a Course can have many Students.

Many to Many Relationships

A many-to-many relationship occurs when multiple records in a table are associated with
multiple records in another table.

3. Ternary Relationship
Relationship of degree three is called Ternary relationship.
A Ternary relationship involves three entities. In such relationships we always consider two
entities together and then look upon the third.
4.. n-ary Relationship
In the N-ary relationship, there are n types of entity that associates. There is one limitation of
the N-ary relationship, as there are many entities so it is very hard to convert into an entity,
rational table.
Example: We have 5 entities Teacher, Class, Location, Salary, Course. So, here five entity
types are associating we can say an n-ary relationship is 5.

ADDITIONAL FEATURES OF THE ER MODEL

Class Hierarchies:
Using the ER model for bigger data creates a lot of complexity while designing a database
model, So in order to minimize the complexity Generalization, Specialization, and
Aggregation were introduced in the ER model.

1. Generalization –
Generalization is the process of extracting common properties from a set of entities and
creating a generalized entity from it. It is a bottom-up approach in which two or more
entities can be generalized to a higher-level entity if they have some attributes in
common.
ISA (`is a’) Hierarchies is used to represent Generalizatio - referred as a superclass-
subclass relationship.

2. Specialization –

Specialization is a top-down approach, and it is opposite to Generalization.

In specialization, one higher level entity can be broken down into two lower level entities.
Specialization is used to identify the subset of an entity set that shares some distinguishing
characteristics.
 Normally, the superclass is defined first, the subclass and its related attributes are defined
next, and relationship set are then added.

ISA (`is a’) Hierarchies is used to represent Specialization - referred as a superclass-

subclass relationship.

3.Aggregation:
Sometimes we have to model a relationship between a collection of entities and relationships.
There is a limitation with E-R model that it cannot express relationships among relationships.
Aggregation allows us to indicate that a relationship set (identified through a dashed box)
participates in another relationship set.
So aggregation is an abstraction through which relationship is treated as higher level entities.

Participation Constraints:

Participation constraints define the least number of relationship instances in which an entity
must compulsorily participate.

Types of Participation Constraints:

There are two types of participation constraints- Total Particiapation

Partial Participation
 1. Total Participation
• It specifies that each entity in the entity set must compulsorily participate in at least
one relationship instance in that relationship set.
• That is why, it is also called as mandatory participation.
• Total participation is represented using a double line between the entity set and
relationship set.

● Double line between the entity set “Student” and relationship set “Enrolled in” signifies
total participation.
● It specifies that each student must be enrolled in at least one course.

2. Partial Participation
• It specifies that each entity in the entity set may or may not participate in the
relationship instance in that relationship set.
• That is why, it is also called as optional participation.
• Partial participation is represented using a single line between the entity set and
relationship set.

● Single line between the entity set “Course” and relationship set “Enrolled in” signifies
partial participation.

● It specifies that there might exist some courses for which no enrollments are made.
 DATABASE MANAGEMENT SYSTEMS
UNIT 1 – TOPIC 7
Conceptual Design Using the ER Model

Developing an ER diagram presents several choices, including the following:

 Should a concept be modeled as an entity or an attribute?

 Should a concept be modeled as an entity or a relationship?
 What are the relationship sets and their participating entity sets?
 Should we use binary or ternary relationships?
 Should we use aggregation?

1. Entity vs. Attribute

While identifying the attributes of an entity set, it is sometimes not clear whether a property
should be modeled as an attribute or as an entity set.

Example : Consider the relationship “Employee WorksIn Department”, if we want to add

address information to the Employee entity set.

Should address be an attribute of Employees or an entity (connected to Employees by a

relationship)?

Now this depends upon the use we want to make of address information, and the semantics of
the data:

• If we have several addresses per employee, address must be an entity (since

attributes cannot be set-valued) and an association between employees and
addresses using a relationship say Has_address.

• If the structure (city, state, zipcode etc.) is important, e.g., we want to retrieve
employees in a given city, address must be modeled as an entity with these
attributes (since attribute values are atomic).

Consider another example below:

In the “Employee WorksIn Department” Relationship, it is possible for an employee to work in a

given department over more than one period, which is not possible to accomodate as an attribute.

• Works_In4 does not allow an employee to work in a department for two or more periods.
• Similar to the problem of wanting to record several addresses for an employee, We want
to record several values of the descriptive attributes for each instance of this relationship.
Accomplished by introducing new entity set, Duration.

2. Entity vs. Relationship

Look at the example below : Consider the relationship set called Manages.

Suppose that each department manager is given a discretionary budget. 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.

What if a manager manages more than one department and the discretionary budget is a sum of
all the departments he manages.

Redundancy: given employee will have the same value in the dbudget field

Misleading: Suggests dbudget associated with department - mgr combination.

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_Appt, and use a ternary relationship, say Man ages3, to relate a manager, an
appointment, and a department.
3. Binary vs. Ternary Relationships

Consider an ER Diagram that 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.

If each policy is owned by just 1 employee, and each dependent is tied to the covering policy,
the ternary relationship as above is inaccurate.

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.

• each dependent entity is uniquely identified by taking pname in conjunction with the
policyid of a policy entity

Solution can be:

• 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 us to introduce an identifying relationship that is binary

The best way to model this situation is to use two binary relationships, as shown in Figure
4. Aggregation v/s Ternary relationship

• The choice between using aggregation or ternary relationship is mainly determined by

existence of a relationship that relates relationship set to entity set.

• The choice may also be guided by certain integrity constraints that we want to express.

According to the ER diagram shown in Figure above, 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 shown below without the need
for aggregation.

Consider the constraint that each sponsorship (of a project by a department) be mon itored by at
most one employee. We cannot express this constraint in terms of the Sponsors2 relationship set.
On the other hand, we can easily express the constraint by drawing an arrow from the aggregated
relationship Sponsors to the relationship Monitors in the aggregation ER diagram.