Introduction

A database-management system (DBMS) is a collection of interrelated data

and a set of programs to access those data. This is a collection of related data
with an implicit meaning and hence is a database. The collection of data,
usually referred to as the database, contains information relevant to an
enterprise. The primary goal of a DBMS is to provide a way to store and
retrieve database information that is both convenient and efficient. By data,
we mean known facts that can be recorded and that have implicit meaning.
Database systems are designed to manage large bodies of information.
Management of data involves both defining structures for storage of
information and providing mechanisms for the manipulation of information.
In addition, the database system must ensure the safety of the information
stored, despite system crashes or attempts at unauthorized access. If data
are to be shared among several users, the system must avoid possible
anomalous results.
Data Processing Vs. Data Management Systems
Although Data Processing and Data Management Systems both refer to
functions that take raw data and transform it into usable information, the
usage of the terms is very different. Data Processing is the term generally
used to describe what was done by large mainframe computers from the late
1940's until the early 1980's (and which continues to be done in most large
organizations to a greater or lesser extent even today): large volumes of raw
transaction data fed into programs that update a master file, with fixed-
format reports written to paper.
The term Data Management Systems refers to an expansion of this concept,
where the raw data, previously copied manually from paper to punched
cards, and later into data-entry terminals, is now fed into the system from a
variety of sources, including ATMs, EFT, and direct customer entry through
the Internet. The master file concept has been largely displaced by database
management systems, and static reporting replaced or augmented by ad-hoc
reporting and direct inquiry, including downloading of data by customers.
The ubiquity of the Internet and the Personal Computer have been the
driving force in the transformation of Data Processing to the more global
concept of Data Management Systems.
File Oriented Approach
The earliest business computer systems were used to process business
records and produce information. They were generally faster and more
accurate than equivalent manual systems. These systems stored groups of
records in separate files, and so they were called file processing systems. In
a typical file processing systems, each department has its own files, designed
specifically for those applications. The department itself working with the
data processing staff, sets policies or standards for the format and
maintenance of its files.
Programs are dependent on the files and vice-versa; that is, when the
physical format of the file is changed, the program has also to be changed.
Although the traditional file oriented approach to information processing is
still widely used, it does have some very important disadvantages.
File Systems Versus A DBMS (Characteristics)
In earlier days, the databases were created directly on top of file systems. File
system has many
disadvantages.
1. Not enough primary memory to process large data sets. If data is
maintained in other storage devices like disks, tapes and bringing
relevant data to main memory, it increases the cost of performance.
Problem in accessing the large data due to addressing the data using
32 bit or 64 bit mode addressing mechanism.
2. Programs must be written to process the user request to process the
data stored in files which are complex in nature because of large
volume of data to be searched.
3. Inconsistent data and complexity in providing concurrent accesses.
4. 4.Not sufficiently flexible to enforce security policies in which different
users have permission to access different subsets of the data.
A DBMS is a piece of software that is designed to make the preceding tasks
easier. By storing data in a DBMS, rather than as a collection of operating
system Files, we can use the DBMS's features to manage the data in a robust
and efficient manner.
Characteristics
Traditionally data was organized in file formats. DBMS was all new concepts
then and all the research was done to make it to overcome all the deficiencies
in traditional style of data management. Modern DBMS has the following
characteristics:
• Real-world entity: Modern DBMS are more realistic and uses real
world entities to design its architecture. It uses the behavior and
attributes too. For example, a school database may use student as
entity and their age as their attribute.
• Relation-based tables: DBMS allows entities and relations among
them to form as tables. This eases the concept of data saving. A user
can understand the architecture of database just by looking at table
names etc.
• Isolation of data and application: A database system is entirely
different than its data. Where database is said to active entity, data is
said to be passive one on which the database works and organizes.
DBMS also stores metadata which is data about data, to ease its own
process.
• Less redundancy: DBMS follows rules of normalization, which splits
a relation when any of its attributes is having redundancy in values.
Following normalization, which itself is a mathematically rich and
scientific process, make the entire database to contain as less
redundancy as possible.
• Consistency: DBMS always enjoy the state on consistency where the
previous form of data storing applications like file processing does not
guarantee this. Consistency is a state where every relation in database
remains consistent. There exist methods and techniques, which can
detect attempt of leaving database in inconsistent state.
• Query Language: DBMS is equipped with query language, which
makes it more efficient to retrieve and manipulate data. A user can
apply as many and different filtering options, as he or she wants.
Traditionally it was not possible where file-processing system was
used.
• ACID Properties: DBMS follows the concepts for ACID properties,
which stands for Atomicity, Consistency, Isolation and Durability.
These concepts are applied on transactions, which manipulate data in
database. ACID properties maintains database in healthy state in
multitransactional environment and in case of failure.
• Multiuser and Concurrent Access: DBMS support multi-user
environment and allows them to access and manipulate data in
parallel. Though there are restrictions on transactions when they
 attempt to handle same data item, but users are always unaware of
them.
• Multiple views: DBMS offers multiples views for different users. A
user who is in sales department will have a different view of database
than a person working in production department. This enables user to
have a concentrate view of database according to their requirements.
• Security: Features like multiple views offers security at some extent
where users are unable to access data of other users and departments.
DBMS offers methods to impose constraints while entering data into
database and retrieving data at later stage. DBMS offers many different
levels of security features, which enables multiple users to have
different view with different features.
Concurrent Use
A database system allows several users to access the database concurrently.
Answering different questions from different users with the same (base)
data is a central aspect of an information system. Such concurrent use of data
increases the economy of a system.
Structured and Described Data
A fundamental feature of the database approach is that the database systems
do not only contain the data but also the complete definition and description
of these data. These descriptions are basically details about the extent, the
structure, the type and the format of all data and, additionally, the
relationship between the data. This kind of stored data is called metadata
("data about data").
Separation of Data and Applications
As described in the feature structured data the structure of a database is
described through metadata which is also stored in the database. An
application software does not need any knowledge about the physical data
storage like encoding, format, storage place, etc. It only communicates with
the management system f a database (DBMS) via a standardized interface
with the help of a standardized language like SQL..
Data Integrity
Data integrity is a byword for the quality and the reliability of the data of a
database system. In a broader sense data integrity includes also the
protection of the database from unauthorized access (confidentiality) and un
authorized changes..
Transactions
A transaction is a bundle of actions which are done within a database to bring
it from one consistent state to a new consistent state..
Data Persistence
Data persistence means that in a DBMS all data is maintained as long as it is
not deleted explicitly. The life span of data needs to be determined directly
or indirectly be the user and must not be dependent on system features.
Additionally data once stored in a database must not be lost. Changes of a
database which are done by a transaction are persistent. When a transaction
is finished even a system crash cannot put the data in danger.
Database Users
Users are put into different groups based on how they want to use the
system. There are four different kinds of database users: Naive Users,
Application programmers, Analysts, Specialized Users and Database
Programmers. The person in charge of the system as a whole is termed the
database administrator (DBA). The DBA also needs to define schema, storage
structure and access methods. DBA modifies schema and physical
organization, grants access to data, specifies integrity constraints and does
regular maintenance.
The people who use the system are called users. Users can be categorized
into those who actually use and manage the material (referred to as "Actors
on the Scene") and those who make it possible to create the database and the
DBMS software (referred to as "Workers Behind the Scene").
Users are put into different groups based on how they want to use the
system. There are four different kinds of database users:
Naive Users:
Naive users are people who don't know much about computers and use the
system by calling up one of the application programs that have already been
written. For example, a bank teller uses a program called "initaite_transfer"
to move Rs. 15,000 from account A to account B. This program asks the teller
for the amount of money that needs to be moved, the account that the money
is coming from, and the account that the money is going to.
Application programmers:
These are people who work in computers and write programs for
applications. Application programmers have a lot of tools to choose from
when making user interfaces. E.g., RAD (Rapid Application Development)
tools let an application programmer make forms and reports without having
to write a program.
Sophisticated users:
These people know how to use the system without writing programs. They
write their requests in a language for talking to databases. They send each
query to a query processor, whose job is to turn DML statements into
instructions that the storage manager can understand. This group is made
up of analysts who use queries to look at data in the database.
For example, Online Analytical Processing (OLAP) tools make analysts' jobs
easier by letting them see data summaries in different ways. For example,
analysts can see total products by categories, by no. of sales, or by a
combination of categories and no. of sales.
Specialized users:
Specialized users are advanced users who write database programs that
don't fit into the traditional way of processing data. Among these
applications are computer-aided design systems, knowledge base and expert
systems, systems that store data with complex data types (like audio/visual
data), and systems that model the environment.
Database Administrators
One of the main reasons to use DBMS is to have centralized control over both
the data and the programs that access the data. The person in charge of the
system as a whole is termed the database administrator (DBA). The following
are some of the duties of the DBA:
Advantages and Disadvantages of a DBMS
Using a DBMS to manage data has many advantages:
Data independence: Application programs should be as independent as
possible from details of data representation and storage. The DBMS can
provide an abstract view of the data to insulate application code from such
details.
Efficient data access: A DBMS utilizes a variety of sophisticated techniques
to store and retrieve data efficiently. This feature is especially important if
the data is stored on external storage devices.
Data integrity and security: If data is always accessed through the DBMS,
the DBMS can enforce integrity constraints on the data. For example, before
inserting salary information for an employee, the DBMS can check that the
department budget is not exceeded. Also, the DBMS 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. Experienced
professionals, who understand the nature of the data being managed, and
how different groups of users use it, can be responsible for organizing the
data representation to minimize redundancy and fine-tuning the storage of
the data to make retrieval efficient.
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: Clearly, the DBMS supports many
important functions that are common to many applications accessing data
stored in the DBMS. This, in conjunction with the high-level interface to the
data, facilitates quick development of applications. Such applications are also
likely to be more robust than applications developed from scratch because
many important tasks are handled by the DBMS instead of being
implemented by the application.
Disadvantages of a DBMS
Danger of a Overkill: For small and simple applications for single users a
database system is often not advisable.
Complexity: A database system creates additional complexity and
requirements. The supply and operation of a database management system
with several users and databases is quite costly and demanding.
Qualified Personnel: The professional operation of a database system
requires appropriately trained staff. Without a qualified database
administrator nothing will work for long.
Costs: Through the use of a database system new costs are generated for the
system itselfs but also for additional hardware and the more complex
handling of the system.
Lower Efficiency: A database system is a multi-use software which is often
less efficient than specialized software which is produced and optimized
exactly for one problem.
Applications of DBMS:
Databases are widely used. Some of them are as follows.
• Banking: For customer information, accounts, loans and banking
transactions.
• Airlines: For reservation and scheduled information Airlines were
among the first to use database in a geographically distributed manner
terminal situated around the world accessed the central database
system through phone lines and other data networks.
• Universities: For student, course registration and grade information.
• Credit card transactions: For purchases on credit cards and
generation of monthly statements.
• Telecommunications: For keeping records of calls made, generating
monthly bills, maintaining balances on prepaid calling cards and
storing information about the communication network.
• Finance: For storing information about holdings, sales and purchases
of financial instruments such as stocks and bonds.
• Manufacturing: For management of supply chain and for tracking
production of items in factories, inventory of items in warehouses and
orders for items.
• Human resources: For information about employees, salaries, payroll
taxes& benefits and for generation of payments.
Brief Introduction of different Data Models; concepts of Schema
Underlying the structure of a database is the data model: a collection of
conceptual tools for describing data, data relationships, data semantics, and
consistency constraints.
To illustrate the concept of a data model, we outline two data models in this
section: the entity relationship model and the relational model. Both provide
a way to describe the design of a database at the logical level. Data model
tells how the logical structure of a database is modeled. Data Models are
fundamental entities to introduce abstraction in DBMS. Data models define
how data is connected to each other and how it will be processed and stored
inside the system. The very first data model could be flat data-models where
all the data used to be kept in same plane. Because earlier data models were
not so scientific they were prone to introduce lots of duplication and update
anomalies.
Other Data Models
The object-oriented data model is another data model that has seen
increasing attention. The object-oriented model can be seen as extending
the E-R model with notions object-oriented data model. The object-
relational data model combines features of the object-oriented data model
and relational data model. Semi structured data models permit the
specification of data where individual data items of the same type may have
different sets of attributes. This is in contrast with the data models
mentioned earlier, where every data item of a particular type must have the
same set of attributes. The extensible markup language (XML) is widely
used to represent semi structured data.
Historically, two other data models, the network data model and the
hierarchical data model, preceded the relational data model. These models
were tied closely to the underlying implementation, and complicated the
task of modeling data. As a result they are little used now, except in old
database code that is still in service in some places.
Categories of data models
➢ Conceptual (high-level, semantic) data models: Provide concepts that
are close to the way many users perceive data (Also called entity-based or
object-based data models).
➢ Physical (low-level, internal) data models: Provide concepts that
describe details of how data is stored in the computer.
➢ Implementation (representational) data models: Provide concepts
that fall between the above two.
1. Hierarchical models:
Advantages:
➢ Hierarchical model is simple to construct and operate on.
 ➢ Corresponds to a number of natural hierarchical organized domains
– e.g., assemblies in manufacturing, personal organization in
companies.
➢ Language is simple; uses constructs like GET, GET UNIQUE, GET
NEXT, GET NEXT WITHIN PARENT etc.,
Disadvantages:
➢ Navigational and procedural nature of processing.

➢ Database is visualized as a linear arrangement of records.

➢ Little scope for “query optimization”.

➢ One-to-many relationships.
2. Network model:
Advantages:
➢ Network model is able to model complex relationships and
represents semantics of add/delete on the relationships.
➢ Can handle most situations for modeling using record types and
relationship types.
➢ Language is navigational; uses constructs like FIND, FIND member,
FIND owner, FIND NEXT within set, GET etc. Programmers can do
optimal navigation through the database.
Disadvantages:
➢ Navigational and procedural nature of processing.

➢ Database contains a complex array of pointers that are expensive

and difficult to update
when inserting and deleting.
➢ Little scope for automated “query optimization”.
3. Relational model:
➢ A relation, basically a table with rows and columns.
➢ Every relation has a schema, which describes the columns, or fields.
 ➢ Student information in a university database may be stored in a
relation with the following schema
➢ Students (sid: string, name: string, login: string, age: integer, gpa:
real)
Instances and Schemas
Databases change over time as information is inserted and deleted. The
collection of information stored in the database at a particular moment is
called an instance of the database. The overall design of the database is called
the database schema. Schemas are changed infrequently, if at all. The
concept of database schemas and instances can be understood by analogy to
a program written in a programming language. A database schema
corresponds to the variable declarations (along with associated type
definitions) in a program. Each variable has a particular value at a given
instant. The values of the variables in a program at a point in time correspond
to an instance of a database schema. Therefore Database schema skeleton
structure of and it represents the logical view of entire database. It tells
about how the data is organized and how relation among them is associated.
It formulates all database constraints that would be put on data in relations,
which resides in database. A database schema defines its entities and the
relationship among them. Database schema is a descriptive detail of the
database, which can be depicted by means of schema diagrams. All these
activities are done by database designer to help programmers in order to
give some ease of understanding all aspect of database.
Database systems have several schemas, partitioned according to the levels
of abstraction. The physical schema describes the database design at the
physical level, while the logical schema describes the database design at the
logical level. A database may also have several schemas at the view level,
sometimes called sub schemas, that describe different views of the
database. Of these, the logical schema is by far the most important, in terms
of its effect on application programs, since programmers construct
applications by using the logical schema. The physical schema is hidden
beneath the logical schema, and can usually be changed easily without
affecting application programs. Application programs are said to exhibit
physical data independence if they do not depend on the physical schema,
and thus need not be rewritten if the physical schema changes.
.
Database schema skeleton structure of and it represents the logical view of
entire database. It tells about how the data is organized and how relation
among them is associated. It formulates all database constraints that would
be put on data in relations, which resides in database.
Levels of Abstraction in a DBMS (Three tier schema architecture )
The data in a DBMS is described at three levels of abstraction.
The database description consists of a schema at each of these three levels
of abstraction.
External, Conceptual and Physical
Views describe how users see the data.
Conceptual schema defines logical structure.
Physical schema describes the files and indexes used.

Conceptual schema:
▪ The conceptual schema(also called as logical schema) describes the stored
data in terms of the data model of the DBMS.
▪ In a relational DBMS, the conceptual schema describes all relations that
are stored in the database.
▪ In our sample university database, these relations contain information
about entities, such as students and faculty, and about relationships, such as
students’ enrollment in courses.
Students(sid: string, name: string, login: string, age: integer, gpa:
real)
Faculty(fid: string, fname: string, salary : real)
Courses(cid: string, cname: string, credits: integer)
Rooms(nw: integer, address: string, capacity: integer)
Enrolled (sid: string, cid: string, grade: string)
Teaches (fid: string, cid: string)
The choice of relations, and the choice of fields for each relation, is not always
obvious, and the process of arriving at a good conceptual schema is called
conceptual database design.
Physical Schema:
▪ The physical schema specifies storage details.
▪ It summarizes how the relations described in the conceptual schema are
actually stored on secondary storage devices such as disks and tapes.
▪ Decides what file organizations to use to store the relations and create
auxiliary data structures, called indexes, to speed up data retrieval
operations.
▪ A sample physical schema for the university database is to store all
relations as unsorted files of records.
o Create indexes on the first column of the students, faculty and
courses relations, the salary column of faculty, and the capacity of
column of rooms.
External Schema:
▪ This schema allows data access to be customized at the level of individual
users or groups of users.
▪ A database has exactly one conceptual schema and one physical schema,
but it may have several external schemas.
▪ An external schema is a collection of one or more views and relations from
the conceptual schema.
▪ A view is conceptually a relation, but the records in a view are not stored
in the DBMS.
Data Independence
A very important advantage of using a DBMS is that it offers data
independence. That is, application programs are insulated from changes in
the way the data is structured and stored. Data independence is achieved
through use of the three levels of data abstraction; in particular, the
conceptual schema and the external schema provide distinct benefits in this
area.
Relations in the external schema (view relations) are in principle generated
on demand from the relations corresponding to the conceptual schema.3 If
the underlying data is reorganized, that is, the conceptual schema is changed,
the definition of a view relation can be modified so that the same relation is
computed as before. For example, suppose that the Faculty relation in our
university database is replaced by the following two relations:
Faculty_public(fid: string, fname: string, office: integer)
Faculty_private(fid: string, sal: real)
Intuitively, some confidential information about faculty has been placed in a
separate relation and information about offices has been added. The
Courseinfo view relation can be redefined in terms of Faculty public and
Faculty private, which together contain all the information in Faculty, so that
a user who queries Courseinfo will get the same answers as before.
Thus users can be shielded from changes in the logical structure of the data,
or changes in the choice of relations to be stored. This property is called
logical data independence.
In turn, the conceptual schema insulates users from changes in the physical
storage of the data. This property is referred to as physical data
independence. The conceptual schema hides details such as how the data is
actually laid out on disk, the file structure, and the choice of indexes. As long
as the conceptual schema remains the same, we can change these storage
details without altering applications.
Database Architecture
Database architecture uses programming languages to design a particular
type of software for businesses or organizations. Database architecture
focuses on the design, development, implementation and maintenance of
computer programs that store and organize information for businesses,
agencies and institutions.
The functional components of a database system can be broadly divided into
query processor components and storage manager components.
Query Processor:
The query processor components include
• DDL interpreter, which interprets DDL statements and records the
definitions in the data dictionary.
• DML compiler, which translates DML statements in a query language
into an evaluation plan consisting of low-level instructions that the
query evaluation engine understands.
A query can usually be translated into any of a number of alternative
evaluation plans that all give the same result. The DML compiler also
performs query optimization, that is, it picks the lowest cost evaluation
plan from among the alternatives. Query evaluation engine, which executes
low-level instructions generated by the DML compiler.
1. DML Compiler: It translates DML statements in a query language into
low-level instructions that the query evaluation engine understands.
2. Embedded DML Pre-compiler: It converts DML statements embedded in
an application program to normal procedure calls in the host language. The
pre-compiler must interact with the DML compiler to generate the
appropriate code.
3. DDL Interpreter: It interprets DDL Stateline its and records them in a set
of tables containing metadata.
4. Transaction Manager: Ensures that the database remains in a consistent
(correct) state despite system failures, and that concurrent transaction
executions proceed without conflicting.
5. File Manager: Manages the allocation of space on disk storage and the
data structures used to represent information stored on disk.
6. Buffer Manager: Is responsible for fetching data from disk storage into
main memory and deciding what data to cache in memory.
Also some data structures are required as part of the physical system
implementation:
1. Data Files: The data files store the database by itself.
2. Data Dictionary: It stores metadata about the structure of the
database, as it is used heavily.
3. Indices: It provides fast access to data items that hold particular
values.
4. Statistical Data: It stores statistical information about the data in
the database. This information used by the query processor to select
efficient ways to execute a query.
The architecture of a DBMS can be seen as either single tier or multi-tier. The
tiers are classified as follows:
1-tier architecture
2-tier architecture
3-tier architecture
n-tier architecture.
1- tier architecture:
One-tier architecture involves putting all of the required components for
a software application or technology on a single server or platform.

2- tier architecture: The two-tier is based on Client Server architecture.

The two-tier architecture is like client server application. The direct
communication takes place between client and server. There is no
intermediate between client and server.

3- tier architecture: A 3-tier architecture separates its tiers from each

other based on the complexity of the users and how they use the data
present in the database. It is the most widely used architecture to design
a DBMS.

Database Environment
A database management system (DBMS) is a collection of programs that
enables users to create and maintain a database. The DBMS is hence a
general-purpose software system that facilitates the processes of
defining, constructing, manipulating, and sharing databases among
various users and applications.
Defining a database involves specifying the data types, structures, and
constraints for the data to be stored in the database.
Constructing the database is the process of storing the data itself on
some storage medium that is controlled by the DBMS.
Manipulating a database includes such functions as querying the
database to retrieve specific data, updating the database to reflect
changes in the mini world, and generating reports from the data.
Sharing a database allows multiple users and programs to access the
database concurrently.
Other important functions provided by the DBMS include protecting the
database and maintaining it over a long period of time.
Protection includes both system protection against hardware or
software malfunction (or crashes), and security protection against
unauthorized or malicious access. A typical large database may have a
life cycle of many years, so the DBMS must be able to maintain the
database system by allowing the system to evolve as requirements
change over time. We can call the database and DBMS software together
a database system.

Centralized DBMS Architecture

Architectures for DBMSs have followed trends similar to those for general
computer system architectures. Earlier architectures used mainframe
computers to provide the main processing for all functions of the system,
including user application programs and user interface programs, as well
as all the DBMS functionality.
As prices of hardware declined, most users replaced their terminals with
personal computers (PCs) and workstations. At first, database systems
used these computers in the same way as they had used display terminals,
so that the DBMS itself was still a centralized DBMS in which all the DBMS
functionality, application program execution, and user interface
processing were carried out on one machine.
Gradually, DBMS systems started to exploit the available processing
power at the user side, which led to client/server DBMS architectures.
Client/Server Architecture:
The client/server architecture was developed to deal with computing
environments in which a large number of PCs, workstations, file servers,
printers, database servers, Web servers, and other equipment are
connected via a network. The idea is to define specialized servers with
specific functionalities.
The resources provided by specialized servers can be accessed by many
client machines. The client machines provide the user with the
appropriate interfaces to utilize these servers, as well as with local
processing power to run local applications. This concept can be carried
over to software, with specialized software-such as a DBMS or a CAD
(computer-aided design) package being stored on specific server
machines and being made accessible to multiple clients.

The concept of client/server architecture assumes an underlying

framework that consists of many PCs and workstations as well as a
smaller number of mainframe machines, connected via local area
networks and other types of computer networks. A client in this
framework is typically a user machine that provides user interface
capabilities and local processing. When a client requires access to
additional functionality-such as database access-that does not exist at
that machine, it connects to a server that provides the needed
functionality.
A server is a machine that can provide services to the client machines,
such as file access, printing, archiving, or database access. In the general
case, some machines install only client software, others only server
software, and still others may include both client and server software.
However, it is more common that client and server software usually run
on separate machines.
In client/server architecture, the user interface programs and application
programs can run on the client side. When DBMS access is required, the
program establishes a connection to the DBMS (which is on the server
side); once the connection is created, the client program can
communicate with the DBMS. A standard called Open Database
Connectivity (ODBC) provides an application programming interface
(API), which allows client-side programs to call the DBMS, as long as both
client and server machines have the necessary software installed. Most
DBMS vendors provide ODBC drivers for their systems.
 Entity –Relationship Modelling ER-Model [Entity-Relationship Model] It
is a popular high level conceptual data model. This model is used
for the conceptual design of database applications
An Entity–relationship model (ER model) describes the structure of a
database with the help of a diagram, which is known as Entity
Relationship Diagram (ER Diagram). An ER model is a design or blueprint
of a database that can later be implemented as a database.
ER Diagram
An ER diagram shows the relationship among entity sets. An entity set is
a group of similar entities and these entities can have attributes. In terms
of DBMS, an entity is a table or attribute of a table in database, so by
showing relationship among tables and their attributes, ER diagram
shows the complete logical structure of a database.
Components of ER Diagram
ER model describes entities, relationships and attributes
Entity
An Entity may be an object with a physical existence – a particular person,
car, house, or employee – or it may be an object with a conceptual
existence – a company, a job, or a university course.
Attributes
Each entity has attributes. An attribute defines set of properties that are
used to describe an entity. For example, an employee entity has
attributes like employeeid, employee_name, designation, salary etc,,
There are different types of attributes in ER diagram
• Key attributes
• Simple versus composite attributes
• Single valued versus multivalued attributes
• Stored versus derived attributes
Key Attributes
The attribute which uniquely identifies each entity in the entity set is called
key attribute. Key attribute uniquely identify an entity, For example,
Roll_No will be unique for each student. In ER diagram, key attribute is
represented by an oval with underlying lines.
Simple versus composite attributes
Simple attribute is also called atomic attributes. The attributes that are
not divisible are called simple attributes. Examples of simple attributes
include registerno, voterid, aadharno etc
The attributes that are divisible are called composite attributes. Ie, the
composite attributes can be divided into smaller sub-parts. The value of the
composite attribute is the concatenation of the value of its component simple
attributes.
Example of composite attribute is the address. It can be further divided
into house name, city name, district and pin code etc..student name is also a
composite attribute. It can be divided into first name, middle name and last
name. In ER diagram, composite attribute is represented by an oval
comprising of ovals.

Single valued versus multi-valued attributes

Most attributes have a single value for a particular entity. Such attributes
are called single-valued attributes, For example, age is a single valued
attribute of a person, and Date-of-birth is also a single valued attribute.
Some attributes have multiple values foe a particular entity. Such attributes
are called multi-valued attributes. For example, degree is a multi-valued
attribute of a person.ie some person may not have a degree, but someone has
more than one degrees or others have only one degree. Phone number is also
a multi-valued attribute because some people have more than one phone
numbers
In ER diagram, multi-valued attribute is represented by double oval.

Stored versus derived attributes

In some cases, two or more attribute values are related. For example, age and
date-of-birth of a person. Ie, we can determine the age of a person by
knowing their date of birth and current date. Thus, the age attribute is called
derived attribute and the date-of-birth is called stored attribute.
The derived attribute is derived from the stored attribute. In ER diagram,
derived attribute is represented by dashed oval

Complex Attributes
Composite and multi-valued attributes can be nested. We can represent
such attributes by grouping the components using parenthesis () and
separated by commas (,) and displaying between curly braces {}. Such
attributes are called complex attributes
For eg if a person has more than one residence with different address
{
(housename1, place 1),(house name2,place2),…
}
Entity type and Entity sets
A database usually contains group of entities that are similar. For
example, a company contains hundreds of employees that share the same
attributes such as name, age, salary, designation etc.
Collection of entities that have the same attribute is called entity types. Each
entity type in the database is described by it’s name and attributes

The collection of all entities of particular entity type in the database at any
point in time is called an entity set. The entity set is usually referred using
the same name as the entity type
In the above example of STUDENT entity type, a collection of entities from
the Student entity type would form an entity set. We can say that entity type
is a superset of the entity set as all the entities are included in the entity type

Domain(Value Set) of an attribute

Domain means set of permissible values that are given to an attribute.Each
simple attribute of an entity type is associated with a value set or domain of
values,which specifies set of values that may be assigned to that attribute for
each individual entity.If the range of ages allowed for the employees is
between 18 and 50 we can specify domain of age attributr of employee to be
set of integer number between 18 and 50.
Relationship Types, Relationship Sets, Roles, and Structural
Constraints
Relationship:
A relationship describes an association among entities.
Relationship Type:
A Relationship Type is a type of association that can exist between two entity
types.
Relationship set:
A relationship set is a set of associations of the same entity types.
A relationship type R among n entity types E1, E2, ..., En defines a
set of associations or a relationship set among entities from these entity
types. A relationship type and its corresponding relationship set are referred
to by the same name, R. Mathematically, the relationship set R is a set of
relationship instances ri, where each ri associates n individual entities (e1,
e2, ..., en), and each entity ej in ri is a member of entity set Ej,
Hence, a relationship set is a mathematical relation on E1, E2, ..., En. It can be
defined as a subset of the Cartesian product of the entity sets E1 × E2 × ... ×
En. Each of the entity types E1, E 2, ..., En is said to participate in the
relationship type R; similarly, each of the individual entities e1, e2, ..., en is
said to participate in the relationship instance ri = (e1, e2, ..., en).
The degree of a relationship type is the number of participating entity types.
Hence, the WORKS_FOR relationship between EMPLOYEE and
DEPARTMENT is of degree two. A relationship type of degree two is called
binary, and one of degree three is called ternary.
In ER Diagram, Relationships are represented by a diamond symbol
connected to the related entities. The relationship name (an active or
passive verb), is written inside the diamond.

Role Names and Recursive Relationships.

Each entity type that participates in a relationship type plays a particular
role in the relationship. The role name indicates the role that a participating
entity from the entity type plays in each relationship instance, and helps to
explain what the relationship means. For example, in the WORKS_FOR
relationship type, EMPLOYEE plays the role of employee or worker and
DEPARTMENT plays the role of department or employer.
In some cases the same entity type participates more than once in a
relationship type in different roles. In such cases the role name becomes
essential for distinguishing the meaning of the role that each participating
entity plays. Such relationship types are called recursive relationships.

The above figure shows recursive relationship type supervision between

employee in the supervisor role(1) and employee in subordinate role(2).
Hence employee entity type participate twice in supervision once in the
role of supervisor and once in the role of subordinate.
Constraints on Binary Relationship Types:
Relationship types usually have certain constraints that limit the possible
combinations of entities that may participate in the corresponding
relationship set. For example if the company has a rule that each employee
must work for exactly one department, then we would like to describe
this constraint in the schema.
There are two main types of binary relationship constraints:
1. Cardinality ratio
2. Participation constraints.
1. Cardinality Ratios for Binary Relationships:
The cardinality ratio for a binary relationship specifies the maximum
number of relationship instances that an entity can participate in.
The possible cardinality ratios for binary relationship types are 1:1, 1:N, N:1,
and M:N.
That is,
• One to One
• One to Many
• Many to One
• Many to Many.
One to One(1:1)
When every entity set is related to maximum one entity of other entity set.
Eg:

One to many(1:M)
When every entity of first entity set is related to atmost(max) n entities of
other entity set.
Eg:
Many to One(M:1)
When many entity of first entity set is related to one entity of other entity
set.
Eg:

Many to Many(M:N) When many occcurance of one entity is related to many

occurance other entity set.
Eg:

2.Participation Constraints and Existence Dependencies:

The participation constraint specifies whether the existence of an entity
depends on a relationship type. This constraint specifies the minimum
number of relationship instances that each entity can participate in, and is
sometimes called the minimum cardinality constraint.
There are two types of participation constraints—total and partial. If a
company policy states that every employee must work for a department,
then an employee entity can exist only if it participates in at least one
WORKS_FOR relationship instance. Thus, the participation of EMPLOYEE
in WORKS_FOR is called total participation. It means that every entity in
the total set of employee entities must be related to a department entity via
WORKS_FOR. Total participation is also called existence dependency.
In manages relationship, we do not expect every employee to manage a
department, so the participation of EMPLOYEE in the MANAGES
relationship type is partial. It means that some or part of the set of
employee entities are related to some department.
entity via MANAGES, but not necessarily all. The cardinality ratio and
participation constraints, taken together is called structural constraints of
a relationship type.
Weak Entity Types
Entity types that do not have key attributes of their own are called weak
entity types. In contrast, regular entity types that do have a key attribute are
called strong entity types. Entities belonging to a weak entity type are
identified by being related to specific entities from another entity type in
combination with one of their attribute values. This other entity type is
called the identifying or owner entity type. A weak entity type always has
a total participation constraint (existence dependency) with respect to
its identifying relationship because a weak entity cannot be identified
without an owner entity
A weak entity type normally has a partial key, which is the attribute
that can uniquely identify weak entities that are related to the same owner
entity. A strong entity type is a regular entity type that have a key attribute
are called strong entity type
Notation for ER Diagrams: ER Diagrams are used to represent the ER model
Design.

Relationships can also have attributes associated to them. These

attributes are called relationship attributes.
Examples of ER Diagrams
Entity types EMPLOYEE, DEPARTMENT, and PROJECT are shown in
rectangular boxes in the COMPANY ER-diagram.
Relationship types are shown in diamond-shaped boxes attached to the
participating entity types with straight lines. Eg: WORKS_FOR, MANAGES etc.
Attributes are shown in ovals, and each attribute is attached by a straight line
to its entity type or relationship type. Component attributes of a composite
attribute are attached to the oval representing the composite attribute.
Multivalued attributes are shown in double ovals. Eg: Locations attribute of
DEPARTMENT. Key attributes have their names underlined. Eg: ssn
Derived attributes are shown in dotted ovals. Eg: Number_of_Employees
Hours is a Relationships attribute associated with the relationship
WORKS_ON.
Weak entity types are placed in double rectangles and their identifying
relationships are placed in double diamonds.
The partial key of the weak entity type is underlined with a dotted line. The
cardinality ratio of each binary relationship type is specified by attaching a
1, M, or N on each participating edge. The cardinality ratio of
DEPARTMENT:EMPLOYEE in MANAGES is 1:1, whereas it is 1:N for
DEPARTMENT: EMPLOYEE in WORKS_FOR, and M:N for WORKS_ON. The
participation constraint is specified by a single line for partial participation
and by double lines for total participation (existence dependency). The
SUPERVISION relationship type has role names because the same
EMPLOYEE entity type plays two distinct roles in that relationship. The
cardinality ratio is 1:N from supervisor to supervisee because each employee
in the role of supervisee has at most one direct supervisor. But an employee
in the role of supervisor can supervise zero or more employees.
EER stands for Enhanced ER or Extended ER. The various EER Model
Concepts
• Includes all modeling concepts of basic ER.
• Additional concepts:
• Subclasses/Superclasses and Attribute Inheritance
• Specialization/Generalization
• These are fundamental to conceptual modelling
• The additional EER concepts are used to model applications more
completely and moreaccurately.
• EER includes some object-oriented concepts, such as inheritance.
• Subclasses & Superclasses and Attribute Inheritance
Subclass - Often an Entity has many subgrouping which are
meaningful and need to beexplicitly represented. These are called
subclasses.
Superclass - Is the term used to describe the Entity that contains a
subclass(s).
Example: EMPLOYEE entity type is grouped into SECRETARY, ENGINEER,
MANAGER,TECHNICIAN, SALARIED_EMPLOYEE, HOURLY_EMPLOYEE.
Here EMPLOYEE is superclass, SECRETARY, ENGINEER, etc. is subclass of
EMPLOYEE. The relationship between a superclass and any of its
subclasses a superclass/subclass relationships or class/subclass
relationships.
Example: EMPLOYEE/SECRETARY,EMPLOYEE/TECHNICIAN.
A class/subclass relationship is also called IS-A relationships
e.g. SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, etc.
An entity that is member of a subclass represents the same real-world entity
as some member ofthe superclass:
• The subclass member is the same entity in a distinct specific role
• An entity cannot exist in the database merely by being a member of
a subclass; it mustalso be a member of the superclass
• A member of the superclass can be optionally included as a member
of any number of its subclasses.
Examples: A salaried employee who is also an engineer belongs to the two
subclasses:
ENGINEER, and SALARIED_EMPLOYEE
A salaried employee who is also an engineering manager belongs to the three
subclasses:
MANAGER,ENGINEER, and SALARIED_EMPLOYEE

Attribute Inheritance
An entity that is member of a subclass inherits
• All attributes of the entity as a member of the superclass.
• All relationships of the entity as a member of the superclass.
Example: SECRETARY (as well as TECHNICIAN and ENGINEER) inherit the
attributes Name, SSN, …, from EMPLOYEE. Every SECRETARY entity will have
values for the inherited attributes.
2 . Specialization and Generalization
Specialization
• Specialization is the process of defining a set of subclasses of a superclass.
• The set of subclasses is based upon some distinguishing characteristics of
the entities in the superclass
Example: {SECRETARY, ENGINEER, TECHNICIAN} is a specialization
of EMPLOYEE based upon job type. Another specialization of
EMPLOYEE based on method of pay is {SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE}.
Superclass/subclass relationships and specialization can be
diagrammatically represented in EER diagrams
• Attributes of a subclass are called specific or local attributes.
• For example, the attribute TypingSpeed of SECRETARY
The subclass can also participate in specific relationship types. For
example in fig 4.1, a relationship BELONGS_TO of HOURLY_EMPLOYEE

Generalization
The reverse of the specialization process
• Generalization takes common features of subclasses and creates a
superclass.
• Example: CAR, TRUCK generalized into VEHICLE; both CAR,
TRUCK become subclasses of the superclass VEHICLE
– We can view {CAR, TRUCK} as a specialization of VEHICLE
– Alternatively, we can view VEHICLE as a generalization of CAR and TRUCK.
Figure 4.3a shows CAR and TRUCK with several common attributes.
Figure 4.3b showsVEHICLE superclass with CAR and TRUCK subclasses
Diagrammatic notation are sometimes used to distinguish between
generalization and specialization.
• An arrow pointing to the generalized superclass represents a
generalization
• Arrows pointing to the specialized subclasses represent a specialization
• We do not use this notation because it is often subjective as to which
process is more appropriate for a particular situation