Database Management

System
Hemant Singh
Assistant Professor
 Data
 Raw facts and figure is known as Data.
 Data is unorganized and unrefined facts.
 Data doesn’t depend on information.
 Raw data alone is insufficient for decision
making.
 An example of data is a student’s lecture
attendance.
 Information
 Processed form of data is called information.
 Information is a group of data that
collectively carries a logical meaning.
 Information depends on data.
 Information is sufficient for decision making
 The average score of a class is the
information derived from the given data.
 Database
 Repository of data is know as Database.
 A database is an organized collection of data, so
that it can be easily accessed and managed.
 You can organize data into tables, rows, columns,
and index it to make it easier to find relevant
information.
 The college Database organizes the data about the
admin, staff, students and faculty etc.
Database…
 A cylindrical structure is used to display the
image of a database.
 What is DBMS
 Database Management System is basically
software that provide interface or tool to
manages the collection of related data,
updating data, creating tables and a lot more.
 It is used for storing data and retrieving the
data effectively when it is needed.
 Characteristics of DBMS
1. Database system contains not only the database
itself but also an entire definition or description
of the database structure and constraints also
known as metadata of the database.
2. Redundancy: DBMS follows Normalization which
divides the data in such a way that repetition is
minimum.
 Characteristics of DBMS…
3. Data Consistency: On Live data, i.e. data that is
being continuously updated and added, maintaining
the consistency of data can become a challenge. But
DBMS handles it.
4. Support Multiple user and Concurrent Access
5. Query Language: DBMS provides users with a
simple Query language, using which data can be
easily fetched, inserted, deleted and updated.
 DBMS Vs. File System
1. In DBMS, the user is not 1. In this system, the user
required to write the has to write the
procedures. procedures for managing
2. Searching data is easy the database.
2. Searching is difficult in
in Dbms
File System
3. Dbms is structured data 3. Files are unstructured
4. No data redundancy in data
Dbms 4. Data redundancy is there
5. Memory utilization well in file system
in dbms 5. Memory utilization poor
in file system
 DBMS Vs. File System
 No data inconsistency  Inconsistency in file
in dbms system
 File system provides the
 DBMS gives an abstract
detail of the data
view of data that hides representation and
the details. storage of data.
 DBMS provides a crash  File system doesn't have a
recovery mechanism, crash mechanism, i.e., if
i.e., DBMS protects the the system crashes while
user from the system entering some data, then
failure. the content of the file will
lost.
 Data Models
 Data Models help us in representing data
accurately.
 It helps us in finding the missing data and also in
minimizing Data Redundancy.
 The information in the data model can be used
for defining the relationship between tables,
primary and foreign keys, and stored procedures.
 Data Models…

1. Hierarchical database

2. Network database

3. Relational database

4. ER model database
 Hierarchical DBMS
 In a Hierarchical database, model data is
organized in a tree-like structure.
 Data is Stored Hierarchically (top down or bottom
up) format
 Data is represented using a parent-child
relationship. In Hierarchical DBMS parent may
have many children, but children have only one
parent.
Hierarchical DBMS
 Network Model

 The network database model allows each

child to have multiple parents.

 It helps you to address the need to model

more complex relationships like as the

orders/parts many-to-many relationship.

Network Model
 Relational model
 Dr. E.F. Codd proposed the relational Model to
model data in the form of relations or tables in
1970.
 It’s a mathematical model and more flexible than
any other model.
 Secure: Relational Model is more secure than any
other relational model.
 Data is more accurate in the relational data model.
 Relational model
 Data is represented in rows and columns
called relations.
 Data is stored in tables having relationships
between them called the Relational model.
Relational model
 Important Terminologies

 Entity: Any real world object is represented as

entity in relational model. e.g Student
 Attribute: Attributes are the properties that
define an entity. e.g. ROLL_NO, NAME,
ADDRESS
 Tuple : Each row in the relation is known as a
tuple. The above relation contains 4 tuples,
 Important Terminologies
 Degree: The number of attributes in the relation is known as
the degree of the relation. The STUDENT relation defined
above has degree 5.

 Cardinality: The number of tuples in a relation is known as

cardinality. The STUDENT relation defined above has

cardinality 4.
 Column: The column represents the set of values for a
particular attribute. The column ROLL_NO is extracted from
the relation STUDENT
 DBMS Architecture
 The DBMS design depends upon its architecture.
The basic client/server architecture is used to deal
with a large no 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.
Types of DBMS Architecture
 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.
 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.
 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.
 2-Tier Architecture
 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.
2-Tier 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.
 Database Instance
 The data which is stored in the database at a
particular moment of time is called an
instance of the database.
 Data model Schema
 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.
 Data model Schema
 A schema contains schema objects like table,
foreign key, primary key, views, columns,
data types etc.
 A database schema can be represented by
using the visual diagram. That diagram shows
the database objects and relationship with
each other.
 A schema diagram can display only some aspects
of a schema like the name of record type and
constraints.
 Other aspects can't be specified through the
schema diagram.
 For example, the given figure neither show the
data type of each data item nor the relationship
among various files.
 Three schema Architecture
 The three schema architecture is also called
ANSI/SPARC architecture or three-level architecture.
 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.
 Data Abstraction in DBMS
 Data abstraction is the procedure of hiding
irrelevant or unwanted data from the end user.
 The database system contains intricate data
structures and relations. The developers keep away
the complex data from the user and remove the
complications so that the user can comfortably
access data in the database and can only access the
data they want.
 The main purpose of data abstraction is to
hide irrelevant data and provide an abstract
view of the data.
Levels of Data Abstractions in DBMS
 Physical or Internal Level:
 The physical or internal layer is the lowest
level of data abstraction in the database
management system.

 It is the layer that defines how data is actually

stored in the database.

 It defines complex data structures in detail,

so it is very complex to understand, which is
why it is kept hidden from the end user.
 Physical or Internal Level…
 Data Administrators (DBA) decide how to
arrange data and where to store data. The
Data Administrator (DBA) is the person whose
role is to manage the data in the database at
the physical or internal level.
 Logical or Conceptual Level:
 The logical or conceptual level is the intermediate
or next level.
 It explains what data is going to be stored in the
database and what the relationship is between
them.
 Logical or Conceptual Level
 It describes the structure of the entire data
in the form of tables.
 The logical level or conceptual level is less
complex than the physical level.
 With the help of the logical level, Data
Administrators (DBA) abstract data from raw
data present at the physical level.
 View or External Level:
 View or External Level is the highest level of data
abstraction.
 There are different views at this level that define
the parts of the overall data of the database.
 This level is for the end-user interaction; at this
level, end users can access the data based on
their queries.
 Advantages of data abstraction in
DBMS
 Users can easily access the data based on
their queries.

 It provides security to the data stored in the

database.


Database systems work efficiently because of

data abstraction.
Different types of Database Users
 Database users are categorized based up on their

interaction with the database. These are seven types of

database users in DBMS.

I. Database Administrator (DBA)

II. Naive / Parametric End Users :

III. Sophisticated Users :

IV. Database Designers :

V. Application Programmers :
 Database Administrator (DBA)
 Database Administrator (DBA) is a person/team who
defines the schema and also controls the 3 levels of
database.
 The DBA will then create a new account id and password
for the user if he/she need to access the database
 DBA is also responsible for providing security to the
database and he allows only the authorized users to
access/modify the data base.
 Database Administrator (DBA)…
 DBA is responsible for the problems such as
security breaches and poor system response time.
 DBA also monitors the recovery and backup and
provide technical support.
 The DBA has a DBA account in the DBMS which
called a system or super user account.
 DBA repairs damage caused due to hardware
and/or software failures.
 Database Administrator (DBA)…

 DBA is the one having privileges to perform

DCL (Data Control Language) operations such
as GRANT and REVOKE, to allow/restrict a
particular user from accessing the database.
 Naive / Parametric End Users
 Parametric End Users are the unsophisticated who
don’t have any DBMS knowledge but they frequently
use the database applications in their daily life to get
the desired results.
 For examples, Railway’s ticket booking users are naive
users. Clerks in any bank is a naive user because they
don’t have any DBMS knowledge but they still use the
database and perform their given task.
 Sophisticated Users :
 Sophisticated users can be engineers, scientists,
business analyst, who are familiar with the
database.
 They can develop their own database applications
according to their requirement.
 They don’t write the program code but they
interact the database by writing SQL queries
directly through the query processor.
 Database Designers :
 Data Base Designers are the users who design
the structure of database which includes
tables, indexes, views, triggers, stored
procedures and constraints which are usually
enforced before the database is created or
populated with data.
 He/she controls what data must be stored
and how the data items to be related.
 Entity Relation model
 The Entity Relational Model is a model for
identifying entities to be represented in the
database and representation of how those
entities are related.
 The Entity Relationship Diagram explains the
relationship among the entities present in the
database.
 ER models are used to model real-world
objects like a person, a car, or a company and
the relation between these real-world
objects.
 In short, the ER Diagram is the structural
format of the database.
Why Use ER Diagrams In DBMS?
 ER diagrams are used to represent the E-R
model in a database, which makes them easy
to be converted into relations (tables).
 ER diagrams provide the purpose of real-
world modeling of objects which makes them
intently useful.
 ER diagrams require no technical knowledge
and no hardware support.
 These diagrams are very easy to understand
and easy to create even for a naive user.
 It gives a standard solution for visualizing the
data logically.
Components of ER Diagram
 Entity

 An Entity may be an object with a physical

existence – a particular person, car, house, or
employee – or it may be an object with a
conceptual existence – a company, a job, or a
university course.
 Types of Entities
 Strong Entity:
1. A Strong Entity is a type of entity that has a

key Attribute.
2. Strong Entity does not depend on other
Entity in the Schema.
3. It has a primary key, that helps in
identifying it uniquely, and it is represented
by a rectangle.
4. These are called Strong Entity Types.
 Types of Entities…
 For Example, A company may store the
information of dependents (Parents, Children,
Spouse) of an Employee.
 But the dependents don’t have existed without
the employee. So Dependent will be a Weak Entity
Type and Employee will be Identifying Entity type
for Dependent, which means it is Strong Entity
Type.
 Types of Entities…
 A weak entity type is represented by a Double
Rectangle.
 The participation of weak entity types is always
total.
 The relationship between the weak entity type and
its identifying strong entity type is called
identifying relationship and it is represented by a
double diamond.
Strong Entity and Weak Entity
 Attributes

 Attributes are the properties that define the

entity type.
 For example, Roll_No, Name, DOB, Age,
Address, and Mobile_No are the attributes
that define entity type Student.
 Attributes
 In ER diagram, the attribute is represented by
an oval.
 Types of attributes
 Key Attribute:
 The attribute which uniquely identifies each
entity in the entity set is called the key
attribute.
 For example, Roll_No will be unique for each
student
 In ER diagram, the key attribute is
represented by an oval with underlying lines.
 Simple attribute
 It is also known as atomic attributes. When an
attribute cannot be divided further, then it is
called a simple attribute.
 For example, in a student table, the branch
attribute cannot be further divided. It is called a
simple or atomic attribute because it contains
only a single value that cannot be broken further.
 Composite Attribute
 An attribute composed of many other
attributes is called a composite attribute.
 For example, the Address attribute of the
student Entity type consists of Street, City,
State, and Country.
 In ER diagram, the composite attribute is
represented by an oval comprising of ovals.
Composite Attribute
 Single-valued Attribute:

 Those attributes which can have exactly one

value are known as single valued attributes. They
contain singular values, so more than one value
is not allowed.
 For example, the DOB of a student can be a
single valued attribute. Another example is
gender because one person can have only one
gender.
 Multivalued Attribute
 An attribute consisting of more than one
value for a given entity.
 For example, Phone_No (can be more than
one for a given student). In ER diagram, a
multivalued attribute is represented by a
double oval.
Multivalued Attribute
 Derived Attribute
 An attribute that can be derived from other
attributes of the entity type is known as a
derived attribute.
 E.g.; Age (can be derived from DOB). In ER
diagram, the derived attribute is represented
by a dashed oval.
Derived Attribute
 Participation Constraint

 Participation Constraint is applied to the

entity participating in the relationship set. It

is of two type:
 Total Participation
 Partial Participation
 Total Participation
 Each entity in the entity set must participate
in the relationship.
 If each student must enroll in a course, the
participation of students will be total. Total
participation is shown by a double line in the
ER diagram.
 Partial Participation
 The entity in the entity set may or may NOT
participate in the relationship.
 If some courses are not enrolled by any of the
students, the participation in the course will
be partial.
 The diagram depicts the ‘Enrolled in’ relationship set with
Student Entity set having total participation and Course Entity
set having partial participation.
Every student in the Student Entity set participates in
a relationship but there exists a course C4 that is not
taking part in the relationship.
 Relationship
 A relationship is used to describe the relation
between entities.
 Diamond or rhombus is used to represent
the relationship.
Relationship
 Types of relationship :
 One-to-One Relationship
 When only one instance of an entity is
associated with the relationship, then it is
known as one to one relationship.
 Types of relationship :
 One-to-many relationship
 When only one instance of the entity on the
left, and more than one instance of an entity
on the right associates with the relationship
then this is known as a one-to-many
relationship.
 Types of relationship :
 For example, Scientist can invent many
inventions, but the invention is done by the
only specific scientist.
 Many-to-one relationship
 When more than one instance of the entity on
the left, and only one instance of an entity on
the right associates with the relationship then
it is known as a many-to-one relationship.
 For example, Student enrolls for only one
course, but a course can have many students.
 Many-to-many relationship
 When more than one instance of the entity on
the left, and more than one instance of an
entity on the right associates with the
relationship then it is known as a many-to-
many relationship.
 For example, Employee can assign by many
projects and project can have many
employees.
 Notation of ER diagram
 Database can be represented using the
notations. In ER diagram, many notations are
used to express the cardinality. These
notations are as follows:
Cardinality in DBMS (Mapping
Constraints)
 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.
 Cardinality is very important in the Database
of various businesses. For example, if we
want to track the purchase history of each
customer then we can use the one-to-many
cardinality to find the data of a specific
customer.
 Keys
 Keys play an important role in the relational
database.
 It is used to uniquely identify any record or
row of data from the table. It is also used to
establish and identify relationships between
tables.
 Keys
 For example, ID is used as a key in the
Student table because it is unique for each
student. In the PERSON table,
passport_number, license_number, SSN are
keys since they are unique for each person.
Keys
Types of keys:
 Super Key
 Super key is an attribute or set of attribiutes
that can uniquely identify a tuple. A super key
is a superset of a candidate key.
 Super Key
 For example: In the above EMPLOYEE table,
for(EMPLOEE_ID, EMPLOYEE_NAME), the name
of two employees can be the same, but their
EMPLYEE_ID can't be the same. Hence, this
combination can also be a key.
 The super key would be EMPLOYEE-ID
(EMPLOYEE_ID, EMPLOYEE-NAME), etc.
 Candidate key
 A minimal set of super key is called
candidate key.
 Because we select a candidate key from a set
of super keys such that the selected
candidate key is the minimum attribute
required to uniquely identify the table.
 Candidate key
 A candidate key is an attribute or set of
attributes that can uniquely identify a tuple.
 Except for the primary key, the remaining
attributes are considered a candidate key.
The candidate keys are as strong as the
primary key.
 Candidate key
 For example: In the EMPLOYEE table, id is
best suited for the primary key. The rest of
the attributes, like SSN, Passport_Number,
License_Number, etc., are considered a
candidate key.
 Primary key
 It is the first key used to identify one and only
one instance of an entity uniquely.
 An entity can contain multiple keys, as we
saw in the PERSON table. The key which is
most suitable from those lists becomes a
primary key.
 In the EMPLOYEE table, ID can be the primary
key since it is unique for each employee. In
the EMPLOYEE table, we can even select
License_Number and Passport_Number as
primary keys since they are also unique.
 For each entity, the primary key selection is
based on requirements and developers.
 Foreign key
 Foreign keys are the column of the table used to point to
the primary key of another table.
 Every employee works in a specific department in a
company, and employee and department are two
different entities.
 So we can't store the department's information in the
employee table.
 That's why we link these two tables through the primary
key of one table.
 Foreign key
 We add the primary key of the DEPARTMENT
table, Department_Id, as a new attribute in
the EMPLOYEE table.
 In the EMPLOYEE table, Department_Id is the
foreign key, and both the tables are related.
Foreign key
 Alternate key
 There may be one or more attributes or a
combination of attributes that uniquely identify
each tuple in a relation. These attributes or
combinations of the attributes are called the
candidate keys.
 One key is chosen as the primary key from these
candidate keys, and the remaining candidate key, if
it exists, is termed the alternate key.
 For example, employee relation has two
attributes, Employee_Id and PAN_No, that act
as candidate keys. In this relation,
Employee_Id is chosen as the primary key, so
the other candidate key, PAN_No, acts as the
Alternate key.
 Composite key
 Whenever a primary key consists of more
than one attribute, it is known as a composite
key. This key is also known as Concatenated
Key.
Composite key
 Composite key
 For example, in employee relations, we assume that an
employee may be assigned multiple roles, and an employee
may work on multiple projects simultaneously.
 So the primary key will be composed of all three attributes,
namely Emp_ID, Emp_role, and Proj_ID in combination.
 So these attributes act as a composite key since the
primary key comprises more than one attribute.
 Artificial key
 The key created using arbitrarily assigned
data are known as artificial keys.
 These keys are created when a primary key is
large and complex and has no relationship
with many other relations.
 The data values of the artificial keys are
usually numbered in a serial order.
Artificial key
 Artificial key
 For example, the primary key, which is
composed of Emp_ID, Emp_role, and Proj_ID,
is large in employee relations. So it would be
better to add a new virtual attribute to
identify each tuple in the relation uniquely.
Relation among different keys
Find super, candidate and PK?