School of Computing Science and Engineering

Program: B.Tech
Course Name:DBMS
I
Course code: (E2UC302)
Chapter 1: Introduction
• Data, Information, Knowledge.
• Introduction: An overview of the database management system
• Purpose of Database Systems
• Database system Vs file system
• Database system concept and architecture
• Data Modelling using Entity Relationship model
• Enhanced ER model
 Data
 Data is collection of unstructured facts and figures about the object of
interest.
 For e.g. data about an employee would include information like name,
address, age, educational qualifications etc.
 For example, take yourself. You may be 5ft tall, have brown hair and blue
eyes. All of this is “data”. You have brown hair whether this is written
down somewhere or not.

Figure 1: Example of Data

 Requirement Meet by Data

Requirement Description
Integrity Data should be accurate e.g. my LinkedIn profile should
contain valid country name.
Availability I should be able to access LinkedIn and see my data at all
times.
Security Only my friends should be able to see my posts and no
one else.
Independent of I should be able to access the same data from my Android
Application app as well as from web browser on my laptop.
Concurrency All my friends should be able to see my posts at the same
time.
 Information
 Systematic and meaningful form of data.
 Information allows us to expand our knowledge beyond the range of our
senses. We can capture data in information, then move it about so that
other people can access it at different times.
 If I take a picture of you, the photograph is information. But what you look
like is data.
 Information helps human beings in their decision making.

Figure 2: Example of Information

 Knowledge
 Knowledge is information processed in the mind of individual.
 It gives answers to “Why and how”, “Know how”, “Truth and beliefs” and
“judgments”
 Think of this as the map of the World we build inside our brains. Like a
physical map, it helps us know where things are – but it contains more than
that. It also contains our beliefs and expectations.

Figure 3: Example of Knowledge

Data, Information and Knowledge

Figure 4: Example of Data, Information and Knowledge

 Database
 A repository of logically related and similar data.
 An organized collection of related information so that it can easily be accessed, managed and updated.
 It is supposed to meet the requirements of different users of an organization.
 A self describing collection of integrated records.
 For example: The college Database organizes the data about the admin, staff, students and faculty etc.
 Using the database, you can easily retrieve, insert, and delete the information.

Figure 5: Example of Database

Database Management System (DBMS)
• Collection of interrelated data
• Set of programs to access those data.
• DBMS contains information about a particular enterprise
• DBMS provides an environment that is both convenient and efficient to use.
• Database Applications:
• Banking: all transactions
• Airlines: reservations, schedules
• Universities: registration, grades
• Sales: customers, products, purchases
• Manufacturing: production, inventory, orders, supply chain
• Human resources: employee records, salaries, tax deductions
• Databases touch all aspects of our lives.
Database Management System (DBMS)
 DBMS provides an interface to perform various operations like database
creation, storing data in it, updating data, creating a table in the database.
 It provides protection and security to the database. In the case of multiple
users, it also maintains data consistency.
 Example includes MySQL, Oracle, IBM’s DB2, Microsoft’s SQL Server,
MS-Access etc are a very popular commercial database which is used in
different applications.

Figure 6: Example of DBMS

Database Management System (DBMS)

DBMS allows users the following tasks:

 Data Definition: It is used for creation, modification, and removal of definition
that defines the organization of data in the database.
 Data Updation: It is used for the insertion, modification, and deletion of the
actual data in the database.
 Data Retrieval: It is used to retrieve the data from the database which can be
used by applications for various purposes.
 User Administration: It is used for registering and monitoring users, maintain
data integrity, enforcing data security, dealing with concurrency control,
monitoring performance and recovering information corrupted by unexpected
failure.
Purpose of Database System
• In the early days, database applications were built on top of file
systems
• Drawbacks of using file systems to store data:
• Data redundancy and inconsistency
• Multiple file formats, duplication of information in different files
• Difficulty in accessing data
• Need to write a new program to carry out each new task
• Data isolation — multiple files and formats
• Integrity problems
• Integrity constraints (e.g. account balance > 0) become part of program code
• Hard to add new constraints or change existing ones
Purpose of Database Systems (Cont.)
• Drawbacks of using file systems (cont.)
• Atomicity of updates
• Failures may leave database in an inconsistent state with partial updates carried
out
• E.g. transfer of funds from one account to another should either complete or not
happen at all
• Concurrent access by multiple users
• Concurrent accessed needed for performance
• Uncontrolled concurrent accesses can lead to inconsistencies
• E.g. two people reading a balance and updating it at the same time
• Security problems
• Database systems offer solutions to all the above problems
Advantages of DBMS
• Controls database redundancy: It can control data redundancy because it stores all the
data in one single database file and that recorded data is placed in the database.
• Data sharing: In DBMS, the authorized users of an organization can share the data among
multiple users.
• Easily Maintenance: It can be easily maintainable due to the centralized nature of the
database system.
• Reduce time: It reduces development time and maintenance need.
• Backup: It provides backup and recovery subsystems which create automatic backup of
data from hardware and software failures and restores the data if required.
• multiple user interface: It provides different types of user interfaces like graphical user
interfaces, application program interfaces
 Disadvantages of DBMS
 Cost of Hardware and Software: Processor with high speed of data
processing and memory of large size is required.
 Cost of Data Conversion: Very difficult and costly method to convert
data of data file into database.
 Cost of Staff Training: A lot of amount for the training of staff to run
the DBMS.
 Appointing Technical Staff: Trained technical persons such as database
administrator, application programmers, data entry operators etc. are
required to handle the DBMS.
 Database Damage: All data is integrated into a single database. If
database is damaged due to electric failure or database is corrupted on
the storage media, then your valuable data may be lost forever.
Characteristics of DBMS
 It uses a digital repository established on a server to store and manage the
information.
 It can provide a clear and logical view of the process that manipulates data.
 DBMS contains automatic backup and recovery procedures.
 It contains ACID properties which maintain data in a healthy state in case of
failure.
 It can reduce the complex relationship between data.
 It is used to support manipulation and processing of data.
 It is used to provide security of data.
 It can view the database from different viewpoints according to the requirements
of the user.
 Database system Vs file system

File based systems were an early attempt to A database approach is a well-organized

computerize the manual system. It is also called a collection of data that are related in a
traditional based approach in which a decentralized meaningful way which can be accessed by
approach was taken where each department stored different users but stored only once in a
and controlled its own data with the help of a data system. The various operations performed by
processing specialist. The main role of a data the DBMS system are: Insertion, deletion,
processing specialist was to create the necessary selection, sorting etc.
computer file structures, and also manage the data
within structures and design some application
programs that create reports based on file data.
Database system Vs file system
Database system Vs file system
 DBMS Architecture
 The DBMS design depends upon its architecture.
 The basic client/server architecture is used to deal with a large number of PCs, web servers,
database servers and other components that are connected with networks.
 The client/server architecture consists of many PCs and a workstation which are connected
via the network.
 DBMS architecture depends upon how users are connected to the database to get their
request done.
 Database architecture can be seen as a single tier or multi-tier. But logically, database
architecture is of two types like: 2-tier architecture and 3-tier architecture.
 DBMS Architecture
1-Tier Architecture
 In this architecture, the database is directly available to the user.
 It means the user can directly sit on the DBMS and uses it.
 Any changes done here will directly be done on the database itself.
 It doesn't provide a handy tool for end users.
 The 1-Tier architecture is used for development of the local application, where
programmers can directly communicate with the database for the quick response.
 DBMS Architecture
2-Tier Architecture:
 The 2-Tier architecture is same as basic client-server.
 In the two-tier architecture, applications on the client end can directly communicate with the database
at the server side.
 For this interaction, API's like: ODBC, JDBC are used.
 The user interfaces and application programs are run on the client-side.
 The server side is responsible to provide the functionalities like: query processing and transaction
management.
 To communicate with the DBMS, client-side application establishes a connection with the server side
 DBMS Architecture
3-Tier Architecture
 The 3-Tier architecture contains another layer between the client and server.
 In this architecture, client can't directly communicate with the server.
 The application on the client-end interacts with an application server which further
communicates with the database system.
 End user has no idea about the existence of the database beyond the application server.
 The database also has no idea about any other user beyond the application.
 The 3-Tier architecture is used in case of large web application.
 DBMS Architecture: Three schema Architecture

 The three schema architecture is also called ANSI/SPARC architecture or three-level

architecture.
 This framework is used to describe the structure of a specific database system.
 The three schema architecture is also used to separate the user applications and physical
database.
 The three schema architecture contains three-levels. It breaks the database down into three
different categories.
 The Three-Schema Architecture

• Internal Schema
• Describes the physical storage structure
• Uses a physical data model
• Conceptual Schema
• Describes the structure of the whole database
• Uses a conceptual or an implementation data model
• External Schema
• Includes a number user views
• Uses a conceptual or an implementation data model
• Mappings
• The process of transforming requests and results between levels
 DBMS Architecture: Three schema Architecture
In the above diagram:
 It shows the DBMS architecture.
 Mapping is used to transform the request and response between various database levels of architecture.
 Mapping is not good for small DBMS because it takes more time.
 In External / Conceptual mapping, it is necessary to transform the request from external level to
conceptual schema.
 In Conceptual / Internal mapping, DBMS transform the request from the conceptual to internal level.
 Objectives of Three schema Architecture:
 Different users need different views of the same data.
 The approach in which a particular user needs to see the data may change over time.
 The users of the database should not worry about the physical implementation and internal workings of
the database such as data compression and encryption techniques, hashing, optimization of the internal
structures etc.
 All users should be able to access the same data according to their requirements.
 DBA should be able to change the conceptual structure of the database without affecting the user's
 Internal structure of the database should be unaffected by changes to physical aspects of the storage.
The Three-schema architecture
Data Independence
 Data independence refers characteristic of being able to modify the schema
at one level of the database system without altering the schema at the next
higher level.
 There are two types of data independence: Logical Data Independence and
Physical Data Independence

Figure 5: Data Independence

 Logical Data Independence

 Logical data independence refers characteristic of being able

to change the conceptual schema without having to change the
external schema.
 Logical data independence is used to separate the external
level from the conceptual view.
 If we do any changes in the conceptual view of the data, then
the user view of the data would not be affected.
 Logical data independence occurs at the user interface level.
 Physical Data Independence

 Physical data independence can be defined as the capacity to

change the internal schema without having to change the
conceptual schema.
 If we do any changes in the storage size of the database system
server, then the Conceptual structure of the database will not
be affected.
 Physical data independence is used to separate conceptual
levels from the internal levels.
 Physical data independence occurs at the logical interface
level.
Data Models
 Data Model is the modeling of the data description, data semantics, and consistency
constraints of the data.
 It provides the conceptual tools for describing the design of a database at each level
of data abstraction.
 Therefore, there are following four data models used for understanding the structure
of the database:
 Data Models
 Relational Data Model: This type of model designs the data in the form of rows and columns within a table. Thus,
a relational model uses tables for representing data and in-between relationships. Tables are also called relations.
This model was initially described by Edgar F. Codd, in 1969. The relational data model is the widely used model
which is primarily used by commercial data processing applications.

 Entity-Relationship Data Model: An ER model is the logical representation of data as objects and relationships
among them. These objects are known as entities, and relationship is an association among these entities. This
model was designed by Peter Chen and published in 1976 papers. It was widely used in database designing. A set of
attributes describe the entities. For example, student_name, student_id describes the 'student' entity. A set of the
same type of entities is known as an 'Entity set', and the set of the same type of relationships is known as
'relationship set'.

 Object-based Data Model: An extension of the ER model with notions of functions, encapsulation, and object
identity, as well. This model supports a rich type system that includes structured and collection types. Thus, in
1980s, various database systems following the object-oriented approach were developed. Here, the objects are
nothing but the data carrying its properties.

 Semi-structured Data Model: This type of data model is different from the other three data models (explained
above). The semi-structured data model allows the data specifications at places where the individual data items of
the same type may have different attributes sets. The Extensible Markup Language, also known as XML, is widely
used for representing the semi-structured data. Although XML was initially designed for including the markup
information to the text document, it gains importance because of its application in the exchange of data.
 Data Model Schema and Instance
 The data which is stored in the database at a particular moment of time is called an instance of the
database.
 The overall design of a database is called schema.
 A database schema is the skeleton structure of the database.
 It represents the logical view of the entire database.
 A schema contains schema objects like table, foreign key, primary key, views, columns, data types,
stored procedure, etc.
 A database schema can be represented by using the visual diagram.
 That diagram shows the database objects and relationship with each other.
 A database schema is designed by the database designers to help programmers whose software will
interact with the database.
 The process of database creation is called data modeling.
 A schema diagram can display only some aspects of a schema like the name of record type, data type,
and constraints. Other aspects can't be specified through the schema diagram.
 Data Model Schema and Instance
 For example, the given figure neither show the data type of each data item nor the relationship
among various files.
 In the database, actual data changes quite frequently. For example, in the given figure, the database
changes whenever we add a new grade or add a student.
 The data at a particular moment of time is called the instance of the database.
Levels of Abstraction
• Physical level describes how a record (e.g., customer) is stored.
• Logical level: describes data stored in database, and the relationships
among the data.
type customer = record
name : string;
street : string;
city : integer;
end;
• View level: application programs hide details of data types.
• Views can also hide information (e.g., salary) for security purposes.
View of Data
An architecture for a database system
Database Schema

Figure : Database Schema

ER (Entity Relationship) Diagram in DBMS
 ER model stands for an Entity-Relationship model. It is a high-level data model.
 This model is used to define the data elements and relationship for a specified
system.
 It develops a conceptual design for the database.
 It also develops a very simple and easy to design view of data.
 In ER modeling, the database structure is portrayed as a diagram called an entity-
relationship diagram.
 For example, Suppose we design a school database, In this database, the student
will be an entity with attributes like address, name, id, age, etc.
The address can be another entity with attributes like city, street name, pin code,
etc and there will be a relationship between them.
Components of ER Diagram
Components of ER Diagram
Components of ER Diagram
Components of ER Diagram
Components of ER Diagram
Components of ER Diagram
Components of ER Diagram
Components of ER Diagram
Reduction of ER diagram to Table
 The database can be represented using the notations, and these notations can be reduced
to a collection of tables.
 In the database, every entity set or relationship set can be represented in tabular form.
 The ER diagram is given below:
Reduction of ER diagram to Table
 In the STUDENT table, Age is the derived attribute. It can be calculated at any point of time by
calculating the difference between current date and Date of Birth.
 Using these rules, you can convert the ER diagram to tables and columns and assign the
mapping between the tables. Table structure for the given ER diagram is as below:
Enhanced ER model
 Enhanced entity-relationship diagrams are advanced database diagrams very
similar to regular ER diagrams which represent the requirements and
complexities of complex databases.
 It is a diagrammatic technique for displaying the Sub Class and Super Class;
Specialization and Generalization; Union or Category; Aggregation etc.
 Generalization and Specialization: These are very common relationships found
in real entities. However, this kind of relationship was added later as an enhanced
extension to the classical ER model.
 Specialized classes are often called subclass while a generalized class is called
a superclass, probably inspired by object-oriented programming.
 A sub-class is best understood by “IS-A analysis”. The following statements
hopefully make some sense to your mind “Technician IS-A Employee”, and
“Laptop IS-A Computer”.
ER Design Issues
we will discuss the basic design issues of an ER database schema in the following points:
1) Use of Entity Set vs Attributes
 The use of an entity set or attribute depends on the structure of the real-world enterprise that is being modelled and the
semantics associated with its attributes.
 It leads to a mistake when the user use the primary key of an entity set as an attribute of another entity set. Instead, he
should use the relationship to do so. Also, the primary key attributes are implicit in the relationship set, but we designate
it in the relationship sets.
2) Use of Entity Set vs. Relationship Sets
 It is difficult to examine if an object can be best expressed by an entity set or relationship set.
 To understand and determine the right use, the user need to designate a relationship set for describing an action that
occurs in-between the entities.
 If there is a requirement of representing the object as a relationship set, then its better not to mix it with the entity set.
3) Use of Binary vs n-ary Relationship Sets
 Generally, the relationships described in the databases are binary relationships.
 However, non-binary relationships can be represented by several binary relationships.
 For example, we can create and represent a ternary relationship 'parent' that may relate to a child, his father, as well as
his mother. Such relationship can also be represented by two binary relationships i.e, mother and father, that may relate
to their child. Thus, it is possible to represent a non-binary relationship by a set of distinct binary relationships.
4) Placing Relationship Attributes
 The cardinality ratios can become an affective measure in the placement of the relationship attributes. So, it is better to
associate the attributes of one-to-one or one-to-many relationship sets with any participating entity sets, instead of any
relationship set. The decision of placing the specified attribute as a relationship or entity attribute should possess the
charactestics of the real world enterprise that is being modelled.
Generalization
 Generalization is like a bottom-up approach in which two or more entities of
lower level combine to form a higher level entity if they have some attributes in
common.
 In generalization, an entity of a higher level can also combine with the entities of
the lower level to form a further higher level entity.
 Generalization is more like subclass and superclass system, but the only
difference is the approach. Generalization uses the bottom-up approach.
 In generalization, entities are combined to form a more generalized entity, i.e.,
subclasses are combined to make a superclass.
For example, Faculty and Student entities can be generalized and create a higher
level entity Person.
Specialization
 Specialization is a top-down approach, and it is opposite to Generalization.
 In specialization, one higher level entity can be broken down into two lower
level entities.
 Specialization is used to identify the subset of an entity set that shares some
distinguishing characteristics.
 Normally, the superclass is defined first, the subclass and its related attributes are
defined next, and relationship set are then added.
 For example: In an Employee management system, EMPLOYEE entity can be
specialized as TESTER or DEVELOPER based on what role they play in the
company.
Specialization
 Specialization is a top-down approach, and it is opposite to Generalization.
 In specialization, one higher level entity can be broken down into two lower
level entities.
 Specialization is used to identify the subset of an entity set that shares some
distinguishing characteristics.
 Normally, the superclass is defined first, the subclass and its related attributes are
defined next, and relationship set are then added.
 For example: In an Employee management system, EMPLOYEE entity can be
specialized as TESTER or DEVELOPER based on what role they play in the
company.
 Aggregation
In aggregation, the relation between two entities is treated as a single entity. In
aggregation, relationship with its corresponding entities is aggregated into a higher
level entity.
For example: Center entity offers the Course entity act as a single entity in the
relationship which is in a relationship with another entity visitor. In the real world,
if a visitor visits a coaching center then he will never enquiry about the Course only
or just about the Center instead he will ask the enquiry about both.
Cardinality in DBMS (Mapping Constraints)
Cardinality:
 Cardinality means how the entities are arranged to each other or what is the relationship
structure between entities in a relationship set.
 In a Database Management System, Cardinality represents a number that denotes how many
times an entity is participating with another entity in a relationship set.
 The Cardinality of DBMS is a very important attribute in representing the structure of a
Database.
 In a table, the number of rows or tuples represents the Cardinality.
Cardinality Ratio:
 Cardinality ratio is also called Cardinality Mapping, which represents the mapping of one
entity set to another entity set in a relationship set.
 We generally take the example of a binary relationship set where two entities are mapped to
each other.
 There are four types of Cardinality Mapping in Database Management Systems:
 One to one
 Many to one
 One to many
 Many to many
Cardinality in DBMS (Mapping Constraints)
One to One:
 One to one cardinality is represented by a 1:1 symbol. In this, there is at most one relationship from one entity to another entity.
For example, one student can have only one student id, and one student id can belong to only one student. So, the relationship
mapping between student and student id will be one to one cardinality mapping.
 Another example is the relationship between the director of the school and the school because one school can have a maximum
of one director, and one director can belong to only one school.
Many to One Cardinality:
 In many to one cardinality mapping, from set 1, there can be multiple sets that can make relationships with a single
entity of set 2. Or we can also describe it as from set 2, and one entity can make a relationship with more than one
entity of set 1.
 One to one Cardinality is the subset of Many to one Cardinality. It can be represented by M:1.
 For example, there are multiple patients in a hospital who are served by a single doctor, so the relationship between
patients and doctors can be represented by Many to one Cardinality.
Cardinality in DBMS (Mapping Constraints)
One to Many Cardinalities:
 In One-to-many cardinality mapping, from set 1, there can be a
maximum single set that can make relationships with a single or
more than one entity of set 2. Or we can also describe it as from set
2, more than one entity can make a relationship with only one entity
of set 1.
 One to one cardinality is the subset of One-to-many Cardinality.
 It can be represented by 1: M.
For Example, in a hospital, there can be various compounders, so the
relationship between the hospital and compounders can be mapped
through One-to-many Cardinality.
Many to Many Cardinalities:
 In many, many cardinalities mapping, there can be one or more than
one entity that can associate with one or more than one entity of set
2. In the same way from the end of set 2, one or more than one entity
can make a relation with one or more than one entity of set 1.
 It is represented by M: N or N: M.
 One to one cardinality, One to many cardinalities, and Many to one
cardinality is the subset of the many to many cardinalities.
For Example, in a college, multiple students can work on a single
project, and a single student can also work on multiple projects. So, the
relationship between the project and the student can be represented by
many to many cardinalities.
Cardinality in DBMS (Mapping Constraints)
Cardinality:
 Cardinality means how the entities are arranged to each other or what is the relationship
structure between entities in a relationship set.
 In a Database Management System, Cardinality represents a number that denotes how many
times an entity is participating with another entity in a relationship set.
 The Cardinality of DBMS is a very important attribute in representing the structure of a
Database.
 In a table, the number of rows or tuples represents the Cardinality.
Cardinality Ratio:
 Cardinality ratio is also called Cardinality Mapping, which represents the mapping of one
entity set to another entity set in a relationship set.
 We generally take the example of a binary relationship set where two entities are mapped to
each other.
 There are four types of Cardinality Mapping in Database Management Systems:
 One to one
 Many to one
 One to many
 Many to many
Enhanced ER model
 This example instance of “sub-class” relationships. Here we have four sets of employees: Secretary,
Technician, and Engineer.
 The employee is a super-class of the rest three sets of individual sub-class is a subset of Employee set.
 An entity belonging to a sub-class is related to some super-class entity.
 For instance emp, no 1001 is a secretary, and his typing speed is 68.
 Emp no 1009 is an engineer (sub-class) and her trade is “Electrical”, so forth.
 Sub-class entity “inherits” all attributes of super-class; for example, employee 1001 will have attributes eno,
name, salary, and typing speed.
Enhanced ER Model: Example
Thank you