CO-1

Databases and database systems are an essential component of life in modern society: most of us
encounter several activities every day that involve some interaction with a database. For
example, if we go to the bank to deposit or withdraw funds, if we make a hotel or airline
reservation, if we access a computerized library catalog to search for a item, or if we purchase
something online—such as a book, toy, or computer—chances are that our activities will involve
someone or some computer program accessing a database. Even purchasing items at a
supermarket often automatically updates the database that holds the inventory of grocery items.

Data vs Information:
The terms “data” and “information” are often used interchangeably, but they actually aren’t the
same. Data can come in the form of:

• text,
• observations,
• figures,
• images,
• numbers,
• graphs, or
• symbols.

For example, data might include individual prices, weights, addresses, ages, names,
temperatures, dates, or distances, etc. Data is a raw form of knowledge and, on its own, doesn’t
carry any significance or purpose. In other words, you have to interpret data for it to have
meaning. Data can be simple—and may even seem useless until it is analyzed, organized, and
interpreted. There are two main types of data:

• Quantitative data is provided in numerical form, like the weight, volume, or cost of an
item.
• Qualitative data is descriptive, but non-numerical, like the name, gender, or eye color of a
person.

Information is defined as knowledge gained through study, communication, research, or

instruction. Essentially, information is the result of analyzing and interpreting pieces of data.
Whereas data is the individual figures, numbers, or graphs, information is the perception of those
pieces of knowledge.

For example, a set of data could include temperature readings in a location over several years.
Without any additional context, those temperatures have no meaning. However, when you
analyze and organize that information, you could determine seasonal temperature patterns or
even broader climate trends. Only when the data is organized and compiled in a useful way can it
provide information that is beneficial to others.
History of Database Systems:

Databases are a foundational element of the modern world. We interact with them even without
knowing it — any time we buy something online, or log in to a service, or access our bank
accounts, and so on. The concept of a database existed long before computers.
In these times, data was stored in journals, in libraries, and in hundreds of filing cabinets.
Everything was recorded via paper — and that meant it took up space, was hard to find, and
difficult to back up. And then computers became available, and with them, the opportunity for
better data management.

• The 1960s – beginnings

• Charles Bachman designed the first computerized database in the early
1960s. This first database was known as the Integrated Data Store, or IDS.
• This was shortly followed by the Information Management System, a
database created by IBM.
• Both databases were forerunners of the ‘navigational database’.
• Navigational databases required users to navigate through the entire
database to find the information they wanted.
• There are two main models of this:
• hierarchical model (data is organised like a family tree)
• network model (a record to have more than one parent and child record)

• The 1970s – relational databases

• A relational database is one that shows the relationship between different
data records.
• searchable
• more space-efficient (reduced data storage costs)
• Ted Codd defined the relational data model
• Won the ACM Turing Award for this work
• IBM then released their relational database, named as, System R
• The first in the history of databases to use structured query language
(SQL)

• The 1980s – growth and standardisation

• emergence of Object-oriented database management systems (OODBMS)
• view data as ‘objects’
• work with programming languages that supported the ‘object-oriented’
approach

• The 1990s – the internet

• object oriented database systems grow more popular in the 90s.
• the creation of the World Wide Web
• demand for client-server database systems
• the creation of MySQL in 1995
Databases:
➢ Databases and database technology have had a major impact on the growing use of
computers. It is fair to say that databases play a critical role in almost all areas where
computers are used, including business, electronic commerce, social media, engineering,
medicine, genetics, law, education, and library science.

➢ A database is a collection of related data and it is designed, built, and populated with data
for a specific purpose.

➢ The end users of a database may perform business transactions (for example, a customer
buys a camera) or events may happen (for example, an employee has a baby) that cause
the information in the database to change.

➢ A database can be of any size and complexity. For example, the list of names and
addresses referred to earlier may consist of only a few hundred records, each with a
simple structure. On the other hand, the computerized catalog of a large library may
contain half a million entries.

➢ A database of even greater size and complexity would be maintained by a social media
company such as Facebook, which has more than a billion users. The database has to
maintain information on which users are related to one another as friends, the postings of
each user, which users are allowed to see each posting, and a vast amount of other types
of information needed for the correct operation of their Web site. For such Web sites, a
large number of databases are needed to keep track of the constantly changing
information required by the social media Web site.

➢ An example of a large commercial database is Amazon.com. It contains data for over 60

million active users, and millions of books, CDs, videos, DVDs, games, electronics,
apparel, and other items. The database occupies over 42 terabytes and is stored on
hundreds of computers (called servers). Millions of visitors access Amazon.com each day
and use the database to make purchases. The database is continually updated as new
books and other items are added to the inventory, and stock quantities are updated as
purchases are transacted.

➢ A database may be generated and maintained manually or it may be computerized. For

example, a library card catalog is a database that may be created and maintained
manually.

➢ A computerized database may be created and maintained either by a group of application

programs written specifically for that task or by a database management system. Of
course, we are only concerned with computerized databases in this text.
An Example of a simple Database

Student
Name Roll Number Course No
Akash 34434 1
Mahesh 34345 2
Ramesh 45556 1

Course
Course No Course Name Department
1 BCA CA
2 MCA CA

Let us consider a simple example: a COLLEGE database for maintaining information concerning
students, and courses in a College. Figure shows the database structure and a few sample data
records. The database is organized as two files, each of which stores data records of the same
type.

The STUDENT file stores data on each student and the COURSE file stores data on each course.

To define this database, we must specify the structure of the records of each file by specifying
the different types of data elements to be stored in each record. In Figure, each STUDENT
record includes data to represent the student’s Name, Student Roll number and course no.

Each COURSE record includes data to represent the Course no, Course name and Department
(the department that offers the course).

Database management system (DBMS):

A database management system (DBMS) is a computerized system that enables users to create
and maintain a database. In other words, 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 for example: Oracle, Microsoft SQL Server, MS Access,
IBM’s DB2, MySql, Ingres, Informix etc.

➢ Defining a database involves specifying the data types, structures, and constraints of the
data to be stored in the database. The database definition or descriptive information is
also stored by the DBMS in the form of a database catalog or dictionary; it is called meta-
data.

➢ Constructing the database is the process of storing the data on some storage medium that
is controlled by the DBMS.
 ➢ Manipulating a database includes functions such as querying the database to retrieve
specific data, updating the database to reflect changes and generating reports from the
data.

➢ Sharing a database allows multiple users and programs to access the database
simultaneously.

Other important functions provided by the DBMS include protecting the database and
maintaining it over a long period of time.

➢ Protection includes 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.

An application program accesses the database by sending queries or requests for data to the
DBMS.

The DBMS acts as an intermediary/interface between the Database and the Users.

Some examples of DBMS are:

❖ The top commercial DBMS:

➢ Oracle
➢ Microsoft SQL Server
➢ IBM DB2
➢ Microsoft Access, etc.
 ❖ The top open-source DBMS:

➢ MySQL
➢ PostgreSQL
➢ MongoDB
➢ Cassandra
➢ Redis
➢ SQL Lite, etc.

Characteristics of the Database Approach:

The main characteristics of the database approach versus the file-processing approach are the
following:

❖ Self-describing nature of a database system

❖ Insulation between programs and data, and data abstraction
❖ Support of multiple views of the data
❖ Sharing of data and multiuser transaction processing

Self-describing nature of a database system: A fundamental characteristic of the database

approach is that the database system contains not only the database itself but also a complete
definition or description of the database structure and constraints. This definition is stored in the
DBMS catalog, which contains information such as the structure of each file, the type and
storage format of each data item, and various constraints on the data. The information stored in
the catalog is called meta-data, and it describes the structure of the primary database. It is
important to note that some newer types of database systems, known as NOSQL systems, do not
require meta-data. Rather the data is stored as self-describing data that includes the data item
names and data values together in one structure.
Insulation between Programs and Data, and Data Abstraction: In traditional file processing,
the structure of data files is embedded in the application programs, so any changes to the
structure of a file may require changing all programs that access that file. By contrast, DBMS
access programs do not require such changes in most cases. The structure of data files is stored in
the DBMS catalog separately from the access programs. We call this property program-data
independence.

The characteristic that allows program-data independence and program-operation independence

is called data abstraction. A DBMS provides users with a conceptual representation of data that
does not include many of the details of how the data is stored or how the operations are
implemented. Informally, a data model is a type of data abstraction that is used to provide this
conceptual representation. The data model uses logical concepts, such as objects, their properties,
and their interrelationships, that may be easier for most users to understand than computer
storage concepts. Hence, the data model hides storage and implementation details that are not of
interest to most database users.

Support of Multiple Views of the Data: A database typically has many types of users, each of
whom may require a different perspective or view of the database. A view may be a subset of the
database or it may contain virtual data that is derived from the database files but is not explicitly
stored.

Sharing of Data and Multiuser Transaction Processing: A multiuser DBMS, as its name
implies, must allow multiple users to access the database at the same time. This is essential if
data for multiple applications is to be integrated and maintained in a single database. The DBMS
must include concurrency control software to ensure that several users trying to update the same
data do so in a controlled manner so that the result of the updates is correct. For example, when
several reservation agents try to assign a seat on an airline flight, the DBMS should ensure that
each seat can be accessed by only one agent at a time for assignment to a passenger. These types
of applications are generally called online transaction processing (OLTP) applications. A
fundamental role of multiuser DBMS software is to ensure that concurrent transactions operate
correctly and efficiently.

Database-System Applications:

Databases are widely used. Here are some representative applications:

• Enterprise Information
◦ Sales: For customer, product, and purchase information.
◦ Accounting: For payments, receipts, account balances, assets and other accounting
information.
◦ Human resources: For information about employees, salaries, payroll taxes, and
benefits, and for generation of paychecks.
◦ Manufacturing: For management of the supply chain and for tracking production of
items in factories, inventories of items in warehouses and stores, and orders for items.
 ◦ Online retailers: For sales data noted above plus online order tracking, generation of
recommendation lists, and maintenance of online product evaluations.

• Banking and Finance

◦ Banking: For customer information, accounts, loans, and banking transactions.
◦ Credit card transactions: For purchases on credit cards and generation of monthly
statements.
◦ Finance: For storing information about holdings, sales, and purchases of financial
instruments such as stocks and bonds; also for storing real-time market data to enable
online trading by customers.

• Universities: For student information, course registrations, and grades (in addition to standard
enterprise information such as human resources and accounting).

• Airlines: For reservations and schedule information. Airlines were among the first to use
databases in a geographically distributed manner.

• Telecommunication: For keeping records of calls made, generating monthly bills, maintaining
balances on prepaid calling cards, and storing information about the
communication networks.

DBMS Users
1) Actors on the Scene

• Database Administrator: Administering these resources is the responsibility of the

database administrator (DBA). The DBA is responsible for authorizing access to the
database, coordinating and monitoring its use, and acquiring software and hardware
resources as needed.
• Database Designers: Database designers are responsible for identifying the data to be
stored in the database and for choosing appropriate structures to represent and store this
data. These tasks are mostly undertaken before the database is actually implemented and
populated with data. It is the responsibility of database designers to communicate with all
prospective database users in order to understand their requirements and to create a
design that meets these requirements.
• End users are the people whose jobs require access to the database for querying,
updating, and generating reports; the database primarily exists for their use. There are
several categories of end users:
o Casual end users occasionally access the database, but they may need different
information each time.
o Naive or parametric end users make up a sizable portion of database end users.
Their main job function revolves around constantly querying and updating the
database, using standard types of queries and updates.
 o Sophisticated end users include engineers, scientists, business analysts, and others
who thoroughly familiarize themselves with the facilities of the DBMS in order to
implement their own applications to meet their complex requirements.
o Standalone users maintain personal databases by using ready-made program
packages that provide easy-to-use menu-based or graphics-based interfaces. An
example is the user of a financial software package that stores a variety of
personal financial data.

2) Workers behind the Scene

• DBMS system designers and implementers design and implement the DBMS modules
and interfaces as a software package. A DBMS is a very complex software system that
consists of many components, or modules, including modules for implementing the
catalog, query language processing, interface processing, accessing and buffering data,
controlling concurrency, and handling data recovery and security.

• Tool developers design and implement tools—the software packages that facilitate
database modeling and design, database system design, and improved performance. Tools
are optional packages that are often purchased separately. They include packages for
database design, performance monitoring, natural language or graphical interfaces,
prototyping, simulation, and test data generation.

• Operators and maintenance personnel (system administration personnel) are responsible

for the actual running and maintenance of the hardware and software environment for the
database system.

File Processing Systems:

➢ One way to keep the information on a computer is to store it in operating system files. To
allow users to manipulate the information, the system has a number of application
programs that manipulate the files. Application programs are usually written in languages
like COBOL, C, and C++ etc.

➢ New application programs are added to the system as the need arises so the File
Processing system stores permanent records in various files, and it needs different
application programs to extract records from, and add records to, the appropriate files.

➢ Before database management systems (DBMSs) were introduced, organizations usually

stored information in such systems. Keeping organizational information in a file-
processing system has a number of major disadvantages:

1) Data redundancy and inconsistency: In traditional software development utilizing file

processing, every user group maintains its own files for handling its data-processing applications.
For example, consider the COLEGE database example; here, two groups of users might be the
course registration personnel and the accounting office. In the traditional approach, each group
independently keeps files on students. The accounting office keeps data on registration and
related billing information, where as the registration office keeps track of student courses and
grades. Other groups may further duplicate some or all of the same data in their own files.

This redundancy in storing the same data multiple times leads to several problems:

➢ First, there is the need to perform a single logical update—such as entering data on a new
student—multiple times: once for each file where student data is recorded. This leads to
duplication of effort.

➢ Second, storage space is wasted when the same data is stored repeatedly, and this
problem may be serious for large databases.

➢ Third, files that represent the same data may become inconsistent. This may happen
because an update is applied to some of the files but not to others. Even if an update—
such as adding a new student—is applied to all the appropriate files, the data concerning
the student may still be inconsistent because the updates are applied independently by
each user group. For example, one user group may enter a student’s birth date
erroneously as ‘JAN-19-1988’, whereas the other user groups may enter the correct value
of ‘JAN-29-1988’.

2) Difficulty in accessing data: Sometimes we may have to write a new application program to
satisfy an unusual request. Suppose that one of the university clerks needs to find out the names
of all students who live within a particular postal-code area. The clerk asks the data-processing
department to generate such a list. Because the designers of the original system did not anticipate
this request, there is no application program on hand to meet it. There is, however, an application
program to generate the list of all students. The university clerk has now two choices: either
obtain the list of all students and extract the needed information manually or ask a programmer
to write the necessary application program. Both alternatives are obviously unsatisfactory. The
point here is that conventional file-processing Systems do not allow needed data to be retrieved
in a convenient and efficient manner.

3) Integrity problems: The data values stored in the database must satisfy certain types of
consistency constraints. For example, the balance of bank accounts may never fall below a
prescribed amount. Developers enforce these constraints in the system by adding appropriate
code in the various application programs. However, when new constraints are added, it is
difficult to change the programs to enforce them.

4) Atomicity problems: A computer system, like any other device, is subject to failure. In many
applications, it is crucial that, if a failure occurs, the data be restored to the consistent state that
existed prior to the failure. Consider a program to transfer $500 from the account balance from
account A to the account balance of account B. If a system failure occurs during the execution of
the program, it is possible that the $500 was removed from the account A but was not credited to
the account B, resulting in an inconsistent database state. Clearly, it is essential to database
consistency that either both the credit and debit occur, or that neither occur. That is, the funds
transfer must be atomic—it must happen in its entirety or not at all. It is difficult to ensure
atomicity in a conventional file-processing system.

5) Concurrent-access anomalies: Concurrent access means many systems allow multiple users
to update the data simultaneously.

Consider account A, with an account balance of $10,000. If two people debit the account balance
(by say $500 and $100, respectively) from account A at almost exactly the same time, the result
of the concurrent executions may leave an incorrect (or inconsistent) state. Suppose that the
programs executing on behalf of each withdrawal read the old balance, reduce that value by the
amount being withdrawn, and write the result back. If the two programs run concurrently, they
may both read the value $10,000, and write back $9500 and $9900, respectively. Depending on
which one writes the value last, the account balance of department A may contain either $9500
or $9900, rather than the correct value of $9400. To guard against this possibility, the system
must maintain some form of supervision. But supervision is difficult to provide because data
may be accessed by many different application programs that have not been coordinated
previously.

6) Security problems: Not every user of the database system should be able to access all the
data. For example, in a university, payroll personnel need to see only that part of the database
that has financial information. They do not need access to information about academic records.
Enforcing such security constraints is difficult.

Advantages of Using the DBMS Approach:

1) Controlling Redundancy: This redundancy in storing the same data multiple times leads to
several problems. First, there is the need to perform a single logical update—such as entering
data on a new student—multiple times: once for each file where student data is recorded. This
leads to duplication of effort.

Second, storage space is wasted when the same data is stored repeatedly, and this problem may
be serious for large databases

Third, files that represent the same data may become inconsistent. This may happen because an
update is applied to some of the files but not to others.

So any redundancies that exist in the database are controlled by DBMS and the system ensures
that these multiple copies are consistent.

2) Enforcing Integrity Constraints: Most database applications have certain integrity

constraints that must hold for the data. A DBMS should provide capabilities for defining and
enforcing these constraints. The simplest type of integrity constraint involves specifying a data
type for each data item.
A more complex type of constraint that frequently occurs involves specifying that a record in one
file must be related to records in other files. This is known as a referential integrity constraint.
Another type of constraint specifies uniqueness on data item values and this is known as a key or
uniqueness constraint.
Another example of constraint is the value for the age of an employee may be in the range of 16
and 65.

3) Shared Data: A Database allows the sharing of data under its control by any no of application
programs or users.

4) Restricting Unauthorized Access: When multiple users share a large database, it is likely
that most users will not be authorized to access all information in the database. For example,
financial data such as salaries and bonuses is often considered confidential and only authorized
persons are allowed to access such data. In addition, some users may only be permitted to
retrieve data, whereas others are allowed to retrieve and update. Hence, the type of access
operation—retrieval or update—must also be controlled. Typically, users or user groups are
given account numbers protected by passwords, which they can use to gain access to the
database. A DBMS should provide a security and authorization subsystem, which the DBA uses
to create accounts and to specify account restrictions. Then, the DBMS should enforce these
restrictions automatically.

5) Providing Backup and Recovery: A DBMS must provide facilities for recovering from
hardware or software failures. The backup and recovery subsystem of the DBMS is responsible
for recovery. For example, if the computer system fails in the middle of a complex update
transaction, the recovery subsystem is responsible for making sure that the database is restored to
the state it was in before the transaction started executing.

6) Representing Complex Relationships among Data: A database may include numerous

varieties of data that are interrelated in many ways. A DBMS must have the capability to
represent a variety of complex relationships among the data, to define new relationships as they
arise, and to retrieve and update related data easily and efficiently.

7) Providing Multiple User Interfaces: Because many types of users with varying levels of
technical knowledge use a database, a DBMS should provide a variety of user interfaces. These
include apps for mobile users, query languages for casual users, programming language
interfaces for application programmers, forms and command codes for parametric users, and
menu-driven interfaces and natural language interfaces for standalone users.

8) Security Management: Security rules determine which users can access the database, which
data objects each user can access and which data operations the user can perform. All database
users may be authenticated to the DBMS through a user name and passwords or through
biometric authentication.
Database System Environment:

Database System Environment can be divided into 3 parts:

1. Hardware
2. Software
 3. User
• Database Administrator
• Database Designer
• Application Programmers
• End Users

Hardware: All the physical devices of a computer system are referred as hardware. A computer
system can have number of different hardware such as processor, memory, hard disk, monitor,
keyboard, mouse etc. From the database point of view hardware can be divided into 2 categories;
1. The processor and main memory:
• Supports the execution of the database software
2. The secondary storage devices
• Used to store data of system permanently
• These includes hard disks, magnetic tapes, compact disks, pen drive etc…

Software: Software provides the interface between users and database stored in physical
devices.

• Application program, DBMS and OS together generate the software component here.
• Application program are developed using programming languages like C, C++, Java and
etc.
• These application programs use the functionalities of the DBMS software to perform
various operations on the database.
• The OS (Operating System) manages all hardware of the computer.

Users: Any person who communicate with the database is known as Database User.
1. Database administrator
• Has central control over the database system including data & programs.
• DBA is responsible for proper functioning of the database system.
2. Database designer
• Identify the data to be stored in database and designs structure of the database for
an organization.
3. Application programmers
• These users write application programs to interact with the database.
• Application programs can be written in some programming languages such as
C++, Java, .Net etc.
• Such programs access the database by issuing the request, typically a SQL
statement to DBMS.
4. End Users
• Interact with the system by using pre-developed application programs.
• End users do not know about the working, database design, the access mechanism
etc.
• They just use the system to get their task done.
Three level architecture or View of Data:

A major purpose of a database system is to provide users with an abstract view of the data. That
is, the system hides certain details of how the data are stored and maintained.

Data Abstraction

Since many database-system users are not computer trained, developers hide the complexity
from users through several levels of abstraction, to simplify users’ interactions with the system:

➢ Physical level: It is a lowest level of abstraction that describes how the data are actually
stored. The physical level describes the complete details of data storage and access paths
for the database.

➢ Logical level: The next-higher level of abstraction that describes what data are stored in
the database, and what relationships exist among those data. The Logical level hides the
details of physical storage structure and concentrates on describing Entities, Data types,
Relationships and Constraints.

Database administrators, who must decide what information to keep in the database, use
the logical level of abstraction.

➢ View level: The highest level of abstraction describes only part of the entire database.
Many users of the database system do not need all the information; instead, they need to
access only a part of the database so the view level describes the part of the database that
a particular user group is interested in and hides the rest of the database from that user
group. The system may provide many views for the same database.

Figure shows the relationship among the three levels of abstraction:

Types of Databases or Data Models:

Data Model is a collection of conceptual tools for describing data, data relationships, data
semantics, and consistency constraints. A data model provides a way to describe the design of a
database at the physical, logical, and view levels.

A Data Model is a plan for building a database. Every DBMS is based on a particular data
model. A Data model consists of rules and standards that define how data is organized in a
database. There are many basic types of data models:

1) Hierarchical Database (Hierarchical Data Model): The hierarchical database is the oldest
form of the database. It was developed by IBM for its IMS (Information management
system).This data model organizes the data in a tree structure that is each child node can have
only one parent node and at the top of the structure, there is a single parent node. This model
uses parent-child relationship that is one-to-many relationship, however it restricts a child
segment having only one parent segment.

Limitation:
1. Non-hierarchical relationships are difficult to map on this model. Thus, it is inflexible.
2. The processing is sequential along the branches of the tree and therefore the access time
becomes longer.
3. This hierarchical tree is implemented through pointers from parents to their children. This
requires extra storage.
4. Deletion of parent deletes its children nodes.
5. Changes in relationships require changes in the entire structure of the database.
In this model, links are ‘hardcoded’ into the data structure, that is, the link is permanently
established and cannot be modified.

2) Network Data Model: The network data model was developed as an alternative to the
hierarchical database. This model was formulated in 1991 by Database Task group(DBTG) in the
conference on Data System languages. The Network Data model expands on the hierarchical
data model by providing multiple paths among the segments, that is, more than one parent-child
relationship. Hence this model allows many-to-many relationships. The main disadvantage is
that it can be quite complicating to maintain all the links.

3) Relational Model: The relational model uses a collection of tables to represent both data and
the relationships among those data. Each table has multiple columns, and each column has a
unique name. Tables are also known as relations.

Relational database model uses two-dimensional table to store data. They order data in a table
comprising of rows and columns and differ remarkably from their hierarchical and network
counterparts. There are no parent and child data set. The relational data model is the most widely
used data model, and a vast majority of current database systems are based on the relational
model.

4) Entity-Relationship Model: The entity-relationship (E-R) data model uses a collection of

basic objects, called entities, and relationships among these objects. An entity is a “thing” or
“object” in the real world that is distinguishable from other objects. The entity-relationship
model is widely used in database design.

5) Object-Based Data Model: Object-oriented programming (especially in Java, C++, or C#)

has become the dominant software-development methodology. This led to the development of an
object-oriented data model that can be seen as extending the E-R model with notions of
encapsulation, methods (functions), and object identity. The object-relational data model
combines features of the object-oriented data model and relational data model.

Instances and Schemas:

➢ The description of a database is called the database schema, which is specified during
database design or the overall design of the database is called the database schema and is
not expected to change frequently. A displayed schema is called a schema diagram. The
diagram displays the structure of each record type but not the actual instances of records.
A schema diagram displays only some aspects of a schema, such as the names of record
types and data items, and some types of constraints. Other aspects are not specified in the
schema diagram.

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

➢ The actual data in the database may change quiet frequently so 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 or it is also called
database state or snapshot.

➢ When we define a new database, we specify its database schema only to the DBMS. At
this point, the corresponding database state is the empty state with no data. We get the
initial state of the database when the database is first populated or loaded with the initial
data. From then on, every time an update operation is applied to the database, we get
another database state. At any point in time, the database has a current state.
Database systems have several schemas, partitioned according to the levels of abstraction.

➢ The physical schema describes the database design at the physical level,

➢ The logical schema describes the database design at the logical level.

➢ A database may also have several schemas at the view level, sometimes called
subschemas that describe different views of the database.

Notice that the three schemas are only descriptions of data; the actual data is stored at the
physical level only. In the three-schema architecture, each user group refers to its own external
schema. Hence, the DBMS must transform a request specified on an external schema into a
request against the conceptual schema, and then into a request on the internal schema for
processing over the stored database. If the request is database retrieval, the data extracted from
the stored database must be reformatted to match the user’s external view. The processes of
transforming requests and results between levels are called mappings. These mappings may be
time-consuming, so some DBMSs—especially those that are meant to support small databases—
do not support external views. Even in such systems, however, it is necessary to transform
requests between the conceptual and internal levels.

Three Schema Architecture

Data Independence:

Data Independence can be defined as the capacity to change the schema at one level of a
database system without having to change the schema at the next higher level. We can define
two types of data independence:

1) Logical data independence is the capacity to change the conceptual schema without
having to change external schemas or application programs. We may change the
conceptual schema to expand the database (by adding a record type or data item), to
change constraints, or to reduce the database (by removing a record type or data item).

2) Physical data independence is the capacity to change the internal schema without having
to change the logical schema. Hence, the external schemas need not be changed as well.
Changes to the internal schema may be needed because some physical files were
reorganized—for example, by creating additional access structures—to improve the
performance of retrieval or update.

If the same data as before remains in the database, we should not have to change the conceptual
schema. For example, providing an access path to improve retrieval speed of SECTION records
by semester and year should not require a query such as list all sections offered in fall 2008 to be
changed, although the query would be executed more efficiently by the DBMS by utilizing the
new access path.

Data independence occurs because when the schema is changed at some level, the schema at the
next higher level remains unchanged; only the mapping between the two levels is changed.
Hence, application programs referring to the higher-level schema need not be changed.

Database Languages:

A database system provides a data-definition language to specify the database schema and a
data-manipulation language to express database queries and updates. In practice, the data-
definition and data-manipulation languages are not two separate languages; instead they simply
form parts of a single database language, such as the widely used SQL language.
1) Data-Definition Language:

We specify a database schema by a set of definitions expressed by a special language called a

data-definition language (DDL). The DDL is also used to specify additional properties of the
data. The DBMS will have a DDL Compiler whose function is to process DDL statements.

We specify the storage structure and access methods used by the database system by a set of
statements in a special type of DDL called a data storage and definition language. These
statements define the implementation details of the database schemas, which are usually hidden
from the users.
The data values stored in the database must satisfy certain consistency constraints. For example,
suppose the university requires that the account balance of a department must never be negative.
The DDL provides facilities to specify such constraints. The database system checks these
constraints every time the database is updated.

It is a set of SQL Commands used to create, modify and delete database structures but not data.
These commands are normally not used by a general user but by the DBA.

2) Data-Manipulation Language

A data-manipulation language (DML) is a language that enables users to access or manipulate

data .The types of access are:

• Insertion of new information into the database

• Deletion of information from the database
• Modification of information stored in the database

A query is a statement requesting the retrieval of information. The portion of a DML that
involves information retrieval is called a query language. Although technically incorrect, it is
common practice to use the terms query language and data-manipulation language
synonymously.

3) Data-Control Language

DCL includes commands such as GRANT and REVOKE which mainly deal with the rights,
permissions, and other controls of the database system. Following are the DCL commands:
• GRANT: This command gives users access privileges to the database.
• REVOKE: This command withdraws the user’s access privileges given by using the
GRANT command.

4) Transaction-Control Language

Transactions group a set of tasks into a single execution unit. Each transaction begins with a
specific task and ends when all the tasks in the group successfully complete. If any of the tasks
fail, the transaction fails. Therefore, a transaction has only two results: success or failure. The
following TCL commands are used to control the execution of a transaction:
 • COMMIT: Commits a Transaction.
• ROLLBACK: Rollbacks a transaction in case of any error occurs.
• SAVEPOINT: Sets a save point within a transaction.

4) Data Query Language

DQL is a portion of a SQL statement that allows you to get and organise data from a database.
Use the SELECT command to extract data from a database in order to perform actions on it. It is
the same as the projection operation in relational algebra. The result of a select statement on a
table or collection of tables is compiled into a new temporary table, which is subsequently
displayed or received by a program, i.e. a front-end.

Database Administrator:

One of the main reasons for using DBMSs is to have central control of both the data and the
programs that access those data. A person who has such central control over the system is called
a database administrator (DBA). The functions of a DBA include:

1) Schema definition: The DBA creates the original database schema by executing a set of
data definition statements in the DDL.

2) Security and Authorization: The Database Administrator (DBA) is responsible for

ensuring that unauthorized data access is not permitted. Users can be granted permission
to access only certain view and relations.

3) Schema and physical-organization modification: The Database Administrator (DBA)

carries out changes to the schema and physical organization to reflect the changing needs
of the organization.

4) Data Availability and Recovery from failures: The Database Administrator (DBA)
must take steps to ensure that if the system fails, users can continue to access as much of
the uncorrupted data as possible.

5) Routine maintenance: Examples of the database administrator’s routine maintenance

activities are:

◦ Periodically backing up the database, either onto tapes or onto remote servers, to prevent
loss of data in case of disasters such as flooding.
◦ Ensuring that enough free disk space is available for normal operations, and upgrading disk
space as required.
DBMS Interfaces:
User-friendly interfaces provided by a DBMS may include the following:

1) Menu-based Interfaces for Web Clients or Browsing:

These interfaces present the user with lists of options (called menus) that lead the user through
the formulation of a request. Menus do away with the need to memorize the specific commands
and syntax of a query language; rather, the query is composed step-by-step by picking options
from a menu that is displayed by the system. Pull-down menus are a very popular technique in
Web-based user interfaces.

2) Apps for Mobile Devices:

These interfaces present mobile users with access to their data. For example, banking,
reservations, and insurance companies, among many others, provide apps that allow users to
access their data through a mobile phone or mobile device.

The apps have built-in programmed interfaces that typically a limited menu of options for mobile
access to the user data, as well as options such as paying bills (for banks) or making reservations
(for reservation Web sites).

3) Forms-based Interfaces:

A forms-based interface displays a form to each user. Users can fill out all of the form entries to
insert new data, or they can fill out only certain entries, in which case the DBMS will retrieve
matching data for the remaining entries.

Forms are usually designed and programmed for naive users. Many DBMSs have forms
specification languages, which are special languages that help programmers, specify such forms.

SQL*Forms is a form-based language that specifies queries using a form designed in conjunction
with the relational database schema.

Oracle Forms is a component of the Oracle product suite that provides an extensive set of
features to design and build applications using forms.

4) Graphical User Interfaces:

A GUI typically displays a schema to the user in diagrammatic form. The user then can specify a
query by manipulating the diagram. In many cases, GUIs utilize both menus and forms.

5) Speech Input and Output:

Limited use of speech as an input query and speech as an answer to a question or result of a
request is becoming commonplace. Applications with limited vocabularies, such as inquiries for
telephone directory, flight arrival/departure, and credit card account information, are allowing
speech for input and output to enable customers to access this information. The speech input is
detected using a library of predefined words and used to set up the parameters that are supplied
to the queries. For output, a similar conversion from text or numbers into speech takes place.

6) Interfaces for Naive Users:

Parametric users, such as bank tellers, often have a small set of operations that they must perform
repeatedly. For example, a teller is able to use single function keys to invoke routine and
repetitive transactions such as account deposits or withdrawals, or balance inquiries. Systems
analysts and programmers design and implement a special interface for each known class of
naive users. Usually a small set of abbreviated commands is included, with the goal of
minimizing the number of keystrokes required for each request.

7) Interfaces for the DBA:

Most database systems contain privileged commands that can be used only by the DBA staff.
These include commands for creating accounts, setting system parameters, granting account
authorization, changing a schema, and reorganizing the storage structures of a database.
 E-R Model

The entity-relationship (E-R) data model uses a collection of basic objects, called entities, and
relationships among these objects. The ER data Model allows us to describe the data involved in
the real-world enterprise in terms of objects and relationships and is widely used in the database
design.

Entities: An entity is a “thing” or “object” in the real world that is distinguishable from other
objects. An entity may be an object with a physical existence (for example, a particular person,
car, house, or employee) or it may be an object with a conceptual existence (for instance, a
company, a job, or a university course). Entities can even be events such as an appointment to
see a doctor.

Entities are the principal data objects about which information is to be collected and is
distinguishable from other objects; they usually denote a person, place, thing, object, event or
concept of informational interest. In other words, the entity can be uniquely identified. The
examples of entities are:

• A particular person, for example Dr. A.P.J. Abdul Kalam is an entity.

• A particular department, for example Electronics and Communication
Engineering Department.
• A particular place, for example Coimbatore city can be an entity.

Attributes: An Entity is represented by a set of attributes. Attributes are particular properties

that describe the entity. For example, an EMPLOYEE entity may be described by the employee’s
name, age, address, salary, and job.

Values: Each Entity will have a value for each of its attributes. For example The EMPLOYEE
entity e1 has four attributes: Name, Address, Age, and Home_phone; their values are ‘John
Smith,’ ‘2311 Kirby, Houston, Texas 77001’, ‘55’, and ‘713-749-2630’, respectively.

Entity Set: An entity set is a set of entities of the same type that share the same properties, or
attributes. The set of all people who are employees at a given company, for example, can be
defined as the entity set Employee. Similarly, the entity set student might represent the set of all
students in the university.
Types of Attributes:
1) Composite versus Simple (Atomic) Attributes: Composite attributes are the attributes that
can be divided into subparts (that is, other attributes). For example, an attribute name could be
structured as a composite attribute consisting of first name, middle, initial, and last name.

The address can be defined as the composite attribute address with the Attributes Street, city,
state, and zip code. Note also that a composite attribute may appear as a hierarchy. In the
composite attribute address, its component attribute street can be further divided into street
number, street name, and apartment number. Figure depicts these examples of composite
attributes:

A simple attribute is an attribute that cannot be subdivided. For example marital status, rollno,
accountno etc.
2) Single-Valued versus Multivalued Attributes: A single valued attribute is an attribute that
can have only a single value. For example age is a single valued attribute. Loanno, Accountno
etc are single valued attributes.

Multivalued attributes are attributes that can have many values. For example colors attribute for
a Car or a Degree attribute for a person. An Employee may have zero or more phone numbers.

3) Derived Attributes: A Derived attribute is the attribute whose value is calculated or derived
from the values of other attributes. For a particular person entity, the value of Age can be
determined from the current
attribute is hence called a derived attribute and is said to be derivable from the Birth_date
attribute, which is called a stored attribute.

Relationships:
A relationship is an association among two or more entities. The entities that participate in a
relationship are also known as participants. Each relationship is identified by a name. For
example: PROFESSOR teaches CLASS, EMPLOYEE Works_For DEPARTMENT etc.

A Relationship set is a set of relationships of the same type. For example, consider a relationship
type WORKS_FOR between the two entity types EMPLOYEE and DEPARTMENT, which
associates each employee with the department for which the employee works. Each relationship
instance in the relationship set WORKS_FOR associates one EMPLOYEE entity and one
DEPARTMENT entity. In Figure, the employees e1, e3, and e6 work for department d1; the
employees e2 and e4 work for department d2; and the employees e5 and e7 work for department
d3.

Partcipant Relationship Set Partcipant

Degree of a Relationship Type or Relationship Degree:
The degree of a relationship type is the number of participating entity types. Hence, the
WORKS_FOR relationship is of degree two. A relationship type of degree two is called binary,
and one of degree three is called ternary. An example of a ternary relationship is SUPPLY,
shown in Figure, where each relationship instance associates three entities a supplier s, a part p,
and a project j whenever s supplies part p to project j.

Relationships can generally be of any degree, but the ones most common are binary
relationships. Higher-degree relationships are generally more complex than binary relationships.

Null Values :-

An attribute takes a null value when an entity does not have a value for it. The null value may
For example, the ApartmentNumber attribute of an address applies
only to addresses that are in apartment buildings and not to other types of residences, such as
single-family homes. Similarly, a CollegeDegrees attribute applies only to persons with college
degrees. For such situations, a special value called null is created. An address of a single-family
home would have null for its ApartmentNumber attribute, and a person with no college degree
would have null for CollegeDegrees.

Null can also be used if we do not know the value of an attribute for a particular entity-for
example, if we do not know the home phone of an employee. The meaning of the former type of
null is not applicable, whereas the meaning of the latter is unknown. The "unknown" category of
null can be further classified into two cases. The first case arises when it is known that the
attribute value exists but is missing-for example, if the Height attribute of a person is listed as
null. The second case arises when it is not known whether the attribute value exists-for example,
if the HomePhone attribute of a person is null. For example In application forms, there is one
column called middlename so one may have no middle name then a null value is entered in that
column.

Role Names:-

Each entity type that participates in a relationship type plays a particular role in the relationship
The role name
signifies 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.

Role names are not technically necessary in relationship types where all the participating entity
types are distinct, since each participating entity type name can be used as the role name.
However, in some cases(Unary relationship) 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 each participation. Such relationship types are called recursive
relationships. Figure 3.11 shows an example. The SUPERVISION relationship type relates an
employee to a supervisor, where both employee and supervisor entities are members of the same
EMPLOYEE entity type. Hence, the EMPLOYEE entity type participates twice in
SUPERVISION: once in the role of supervisor (or boss), and once in the role of supervisee (or
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.

1) Structural constraints: Cardinality ratio and participation constraints, taken together, will be
referred as the structural constraints of a relationship type.

a) Cardinality Ratios for Binary Relationships Or Mapping Cardinalities:

Mapping cardinalities, or cardinality ratios, express the number of entities to which another
entity can be associated via a relationship set. For a binary relationship set R between entity sets
A and B, the mapping cardinality must be one of the following:

-to-one. An entity in A is associated with at most one entity in B, and an entity in B is

associated with at most one entity in A.
The relationship between the President and the country is an example of one-to-one relationship.
For a particular country there will be only one President. In general, a country will not have more
than one President hence the relationship between the country and the President is an example of
one-to-one relationship.

Another Example: HOD manages DEPARTMENT

One-to-many. An entity in A is associated with any number (zero or more) of entities in B. An

entity in B, however, can be associated with at most one entity in A.

Example of one-to-many relationship is Country having states. For one country there can be
more than one state hence it is an example of one-to-many relationship.

Another Example: HOD manages EMPLOYEES

-to-one. An entity in A is associated with at most one entity in B. An entity in B,

however, can be associated with any number (zero or more) of entities in A.

For Example: EMPLOYEE ManagedBy HOD

 -to-many. An entity in A is associated with any number (zero or more) of entities in B,
and an entity in B is associated with any number (zero or more) of entities in A.

For Example: EMPLOYEE WorksOn PROJECT

b) Participation Constraints:

The participation of an entity set E in a relationship set R is said to be total if every entity in E
participates in at least one relationship in R. If only some entities in E participate in relationships
in R, the participation of entity set E in relationship R is said to be partial.

Customer Participation is partial because an individual can be a bank customer whether

or not he has a loan with the bank.

Loan participation is total because we expect that every loan entity to be related to at least
one Customer.
Existence Dependency: An Entity is said to be existence dependent if it can exist in the database
only when it is associated with another related entity or we can say that an entity is existence
dependent if it has a mandatory foreign key- that is a foreign key attribute that cannot be null.
For example DEPENDENT entity is clearly existence dependent on the EMPLOYEE entity.

2) Key Constraints:

An important constraint on the entities of an entity type is the key on attributes.

a) Super Key: A Superkey is a set of one or more attributes that, taken collectively, allows
us to identify uniquely a tuple in the relation. For Example CustomerID attribute of the
customer relation. Thus CustomerID is a superkey. Similarly the combination of
CustomerName and CustomerID is a superkey for the relation Customer. The
CustomerName alone is not a superkey as several people might have the same name.

b) Candidate Key: The concept of Superkey is not sufficient for our purposes since a
superkey may contain extraneous attributes. If K is a superkey, then so is any superset of
K. Suppose that a combination of CustomerName and Adrress is sufficient to distinguish
among members of the Customer relation. Then, both {CustomerID} and
{CustomerName, Address} are candidate keys. Although the attributes CustomerID and
CustomerName together can distinguish Customer tuples, their combination,
{CustomerID, CustomerName}, does not form a candidate key, since the attribute
CustomerID alone is a candidate key.

c) Primary Key: Primary key denote a candidate key that is chosen by the database
designer as the principal means of identifying entities within an Entity Set or we can say
that out of all available candidate keys, a database designer can identify a Primary Key.

d) Foreign Key: Sometimes the information stored in an Entity set is linked to the
information stored in another entity set or A Foreign Key is an attribute whose values
match the Primary Key values in the related Entity Set. For example DeptNo in the
Department table is a primary key while Deptno in the employee table is a foreign key.

e) Composite Key: Ideally a Primary key is composed of only a single attribute. However it
is possible to use a composite key that is a primary key composed of more than one
attribute.

Weak Entity Sets:

A Weak Entity is one that meets two conditions:

1) It is existence dependent.
 2) It does not have sufficient attributes to form a primary key is termed a weak entity set. An
entity set that has a primary key is termed a strong entity set.

For a weak entity set to be meaningful, it must be associated with another entity set, called the
identifying or owner entity set. Every weak entity must be associated with an identifying entity;
that is, the weak entity set is said to be existence dependent on the identifying entity set. The
identifying entity set is said to own the weak entity set that it identifies. The relationship
associating the weak entity set with the identifying entity set is called the identifying
relationship.

The identifying relationship is many-to-one from the weak entity set to the identifying entity set,
and the participation of the weak entity set in the relationship is total.

The primary key of a weak entity set is formed by the primary key of the identifying entity set,

Consider the entity type DEPENDENT, related to EMPLOYEE, which is used to keep track of
the dependents of each employee via a 1:N relationship. An Employee may or may not have
dependents but the DEPENDENT must be associated with an EMPLOYEE so The
DEPENDENT cannot exist without the EMPLOYEE so DEPENDENT is a weak Entity. In our
example, the attributes of DEPENDENT are Name (the first name of the dependent), Birth_date,
Sex, and Relationship (to the employee). Two dependents of two distinct employees may, by
chance, have the same values for Name, Birth_date, Sex, and Relationship, but they are still
distinct entities. They are identified as distinct entities only after determining the particular
employee entity to which each dependent is related. Each employee entity is said to own the
dependent entities that are related to it.

EMPLOYEE ---- EmpNo, Ename, DoB, Hiredate, Salary

DEPENDENT -----EmpNo, Name, Birth_date, Sex, Relationship

Entity Relationship Diagram(ER Diagrams):

ER Diagram can express the overall logical structure of a database graphically. Following
symbols are used in the ER Model:
An Employee Entity Set:

Relationship between Entity Sets:

Derived Attribute:

Multivalued Attribute:
Composite Attribute:

ER Diagram with Composite, Multivalued and Derived Attribute:

Weak Entity:
One-to-many:

Many-to-many:

Ternary Relationship:
Role Names:
Extended E-R Features

Although the basic E-R concepts can model most database features, some aspects of a database
may be more aptly expressed by certain extensions to the basic E-R model. In this section, we
discuss the extended E-R features of specialization, generalization, higher- and lower-level entity
sets, attribute inheritance, and

Specialization:

Specialization is the process of defining a set of subclasses of an entity type; this entity type is
called the superclass of the specialization or the process of designating subgroupings within an
entity set is called specialization.

The set of subclasses that forms a specialization is defined on the basis of some distinguishing
characteristic of the entities in the superclass. For example, the set of subclasses {SECRETARY,
ENGINEER, TECHNICIAN} is a specialization of the superclass EMPLOYEE that
distinguishes among employee entities based on the job type of each employee.

As an example, Consider an entity set person with attributes PersonId, name, street, city etc. A
Person may be further classified as one of the following:

Each of these person types is described by a set of attributes that includes all the attributes of
entity set person plus possibly additional attributes. Specialization is a top-design process.
Generalization:

Generalization is the reverse process of abstraction in which we suppress the differences among
several entity types, identify their common features, and generalize them into a single superclass
of which the original entity types are special subclasses.

Generalization proceeds from the recognition that a number of entity sets share some common
features (namely, they are described by the same attributes and participate in the same
relationship sets).

For example, consider the entity types CAR and TRUCK shown in Figure 4.3(a). Because they
have several common attributes, they can be generalized into the entity type VEHICLE, as
shown in Figure 4.3(b). Both CAR and TRUCK are now subclasses of the generalized superclass
VEHICLE. We use the term generalization to refer to the process of defining a generalized entity
type from the given entity types. Notice that the generalization process can be viewed as being
functionally the inverse of the specialization process; we can view {CAR, TRUCK} as a
specialization of VEHICLE rather than viewing VEHICLE as a generalization of CAR and
TRUCK.
Attribute Inheritance:
A crucial property of the higher- and lower-level entities created by specialization and
generalization is attribute inheritance. The attributes of the higher-level entity sets are said to be
inherited by the lower-level entity sets. For example, student and employee inherit the attributes
of person.

A lower-level entity set (or subclass) also inherits participation in the relationship sets in which
its higher-level entity (or superclass) participates. Like attribute inheritance, participation
inheritance applies through all tiers of lower-level entity sets. For example, suppose the person
entity set participates in a relationship person dept with department. Then, the student, employee,
instructor and secretary entity sets, which are subclasses of the person entity set, also implicitly
participate in the person dept relationship with department. The above entity sets can participate
in any relationships in which the person entity set participates.

Aggregation:

One limitation of the E-R model is that it cannot express relationships among relationship.
Consider the ternary relationship WorksOn between an Employee, branch and Job. Now we
suppose we want to record managers for tasks performed by an Employee at a branch, that is, we
want to record managers for (Employee, Branch, Job) combination.

There is redundant information in the resultant figure, however, since every Employee, Branch,
Job combination in manages is also in WorksOn.

So Aggregation is an abstraction through which relationships are treated as higher-level entities.

Thus, for our example, we regard the relationship set WorksOn as a higher-level entity set called
WorksOn. Such an entity set is treated in the same manner as is any other entity set. We can then
create a binary relationship manages between WorksOn and Manager to represent who manages
what task.

Reduction of an ER Diagram to Tables:

1) Representation of Strong or regular Entity type:

Each regular entity type in an ER Diagram is transformed into a relation. The name given to
the relation is the same as entity type.

Each simple attribute of the entity type becomes an attribute of the Relation.

The Identifier of the Entity type becomes the Primary key of the corresponding relation.

2) Converting Composite Attribute in an ER Diagram to tables:

When a regular entity type has a composite attribute, only the simple component attributes of
the composite attribute are included in the relation.

3) Converting Multivalued Attribute in an ER Diagram to tables:

When the regular entity type contains a multivalued attribute, two new relations are created.
The first relation contains all of the attributes of the entity type except the multivalued
attribute. The second relation contains two attributes that form the Primary key of the second
relation. The first of these attributes is the Primary key from the first relation, which becomes
the foreign key in the second relation.

4)
For each weak entity type, create a new relation and include all of the simple attributes as
attributes of the relation. Then include the Primary key of the identifying relation as the
foreign key attribute of this new relation. The Primary key of the new relation is the
combination of the Primary key of the Primary key of the identifying and the partial
identifier of the weak entity type. In this example, DEPENDENT is weak entity.

5) Mapping of Binary one-to-one relationship type:

Choose one of relations-S, say-and include as a foreign key in S the primary key of T. It is
better to choose an entity type with total participation in R in the role of S. Include all the
simple attributes of the 1:1 relationship type R as attributes of S.
6) Mapping of Binary one-to-many relationship type:

For each regular binary 1:N relationship type R, Identify the relation S that represents the
entity type at the N-side of the relationship type. Include a foreign key in S, the primary key
of the relation T that represents the other entity type participating in R. This is done because
each entity instance on the N side is related to at most one entity instance on the 1-side of the
relationship type. Include any simple attribute of the 1:N relationship type as attributes of S.

7) Mapping of Binary many-to-many relationship type:

For each binary M:N relationship type R, create a new relation S to represent relationship R.
Include a foreign key attributes in S the primary keys of the relations that represent the
participating entity type, their combinations will form the primary key of S. Also include any
simple attributes of the M:N relationship type as attributes of S. In binary M:N it is necessary
to create separate relationship S.
8) Mapping of Generalization:
Create a schema for the higher level entity set. For each lower level entity set, create a
schema that includes an attribute for e ach of the attributes of that entity set plus one for each
attribute of the primary key of the higher level entity set. Thus:

The Primary key attribute of the higher level entity set becomes Primary key attribute of the
higher level entity set as well as lower level entity sets.

2) Alternatively we can create just two relations, corresponding to employee and customer.

The first approach is general and always applicable.

9) Mapping of Aggregation:
The Employee, Branch, Job and manager entity sets and WorksOn relationship set are
mapped as described in previous section.

For the manages relationship set, we create a relation with the following attributes: The key
attribute of manager, The key attribute of WorksOn and the descriptive attribute of manages.