Database Management Systems

MMC103
 PURPOSE OF DBMS

• A database is a collection of data that is

organized, which is also called structured data.
It can be accessed or stored in a computer
system. It can be managed through a Database
Management System (DBMS), a software used
to manage data.
 CONTD..
• In DBMS, database systems provide a safe and
effective platform to manage vast amounts of
data. Their role is to provide services like
data organization, storage, and manipulation,
as well as to guarantee data integrity.
 CONTD..
• The following are the main disadvantages of DBMS
in File Processing:
• Data redundancy and inconsistency.
• Difficult in accessing data.
• Data isolation.
• Data integrity.
• Concurrency is not possible.
• Security Problems. “Because of the above
disadvantages, it is necessary for large organizations
to have an efficient database management system ”.
VIEWS OF DATA
 Contd..
• Database systems comprise complex data
structures.
• In order to make the system efficient in terms
of retrieval of data, and reduce complexity in
terms of usability of users, developers use
abstraction.
• (i.e. hide irrelevant details from the users.
This approach simplifies database design. )
 Contd..
• There are mainly 3 levels of data abstraction:

• Physical or Internal Level

• Logical or Conceptual Level

• View or External Level

 Contd..
Physical or Internal Level
• This is the lowest level of data abstraction. It
tells us how the data is actually stored in
memory. Access methods like sequential or
random access and file organization methods
like B+ trees and hashing are used for the
same.
 Contd..
Logical or Conceptual Level
• This level comprises the information that is
actually stored in the database in the form of
tables.
• It also stores the relationship among the data
entities in relatively simple structures. At this
level, the information available to the user at
the view level is unknown.
 Contd..
View or External Level
• This is the highest level of abstraction. Only a
part of the actual database is viewed by the
users. This level exists to ease the accessibility
of the database by an individual user.
 Data Models
Data Model
• A data model is a collection of concepts that can be
used to describe the structure of a database.
• By structure of a database we mean the data types,
relationships and constraints that apply to the data.
• Most data models also include a set of basic
operations for specifying retrievals and updates on
the database.
• Data model provides the necessary means to
achieve abstraction.
 Categories of Data Models
• Data models can be categorized according to
the types of concepts they use to describe the
database structure.
1. High-level or conceptual data models:
provide concepts that are close to the way
many users perceive data. Conceptual data
models use concepts such as entities,
attributes, and relationships.
 CONTD..
2.Representational or implementation data
models: provide concepts that may be easily
understood by end users but that are not too
far removed from the way data is organized in
computer storage.
 CONTD..
3. Low-level or physical data models: provide
concepts that describe the details of how data
is stored on the computer storage media,
typically magnetic disks. Physical data models
describe how data is stored as files in the
computer
 Three-Schema Architecture and Data
Independence
• The goal of the three-schema architecture is
to separate the user applications from the
physical database. In this architecture,
schemas can be defined at the following three
levels:
• The internal level has an internal schema.
• The conceptual level has a conceptual
schema.
• The external or view level.
DIAGRAM
 CONTD..
• Internal schema, which describes the physical storage
structure of the database. The internal schema uses a
physical data model and describes the complete details
of data storage and access paths for the database.
• conceptual schema, which describes the structure of
the whole database for a community of users. The
conceptual schema hides the details of physical storage
structures and concentrates on describing entities, data
types, relationships, user operations, and constraints.
 CONTD..
• The external or view level includes a number
of external schemas or user views. Each
external schema 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.
 Relational Model
• The relational model is today the primary data
model for commercial data processing
applications.
• It attained its primary position because of its
simplicity, which eases the job of the
programmer, compared to earlier data models
such as the network model or the hierarchical
model.
Structure of Relational Databases
• A relational database consists of a collection
of tables, each of which is assigned a unique
name.
• For Example:
 Contd..
• For example, consider the instructor table of
Figure which stores information about
instructors. The table has four column
headers: ID, name, dept name, and salary.
Each row of this table records information
about an instructor, consisting of the
instructor’s ID, name, dept name, and salary.
Typical DBMS Component Modules
 ER Model Concepts
• Entities and Attributes
– Entities are specific objects or things in the mini-world that
are represented in the database. For example the
EMPLOYEE John Smith, the Research DEPARTMENT,
the ProductX PROJECT
– Attributes are properties used to describe an entity. For
example an EMPLOYEE entity may have a Name, SSN,
Address, Sex, BirthDate
– A specific entity will have a value for each of its attributes.
For example a specific employee entity may have
Name='John Smith', SSN='123456789', Address ='731,
Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55’.
– Each attribute has a value set (or data type) associated
with it – e.g. integer, string, subrange, enumerated type, …
 Types of Attributes
• Simple
– Each entity has a single atomic value for the attribute. For
example, SSN or Sex.
• Composite
– The attribute may be composed of several components. For
example, Address (Apt#, House#, Street, City, State,
ZipCode, Country) or Name (FirstName, MiddleName,
LastName). Composition may form a hierarchy where
some components are themselves composite.
• Multi-valued
– An entity may have multiple values for that attribute. For
example, Color of a CAR or PreviousDegrees of a
STUDENT. Denoted as {Color} or {PreviousDegrees}.
 Types of Attributes (2)
• In general, composite and multi-valued
attributes may be nested arbitrarily to any
number of levels although this is rare. For
example, PreviousDegrees of a STUDENT is a
composite multi-valued attribute denoted by
{PreviousDegrees (College, Year, Degree,
Field)}.
 Entity Types and Key Attributes
• Entities with the same basic attributes are
grouped or typed into an entity type. For
example, the EMPLOYEE entity type or the
PROJECT entity type.
• An attribute of an entity type for which each
entity must have a unique value is called a key
attribute of the entity type. For example, SSN
of EMPLOYEE.
• A key attribute may be composite. For
example, VehicleTagNumber is a key of the CAR
entity type with components (Number, State).
 Contd..
• An entity type may have more than one key. For example, the
CAR entity type may have two keys:
– VehicleIdentificationNumber (popularly called VIN) and
– VehicleTagNumber (Number, State), also known as
license_plate number.
 ENTITY SET corresponding to the
ENTITY TYPE CAR
• CAR
• Registration(RegistrationNumber, State), VehicleID, Make,
Model, Year, (Color)
• car1
• ((ABC 123, TEXAS), TK629, Ford Mustang, convertible, 1999,
(red, black))
• car2
• ((ABC 123, NEW YORK), WP9872, Nissan 300ZX, 2-door, 2002,
(blue))
• car3
• ((VSY 720, TEXAS), TD729, Buick LeSabre, 4-door, 2003, (white,
blue))
 Relationships and Relationship Types (1)
• A relationship relates two or more distinct entities with a
specific meaning. For example, EMPLOYEE John Smith
works on the ProductX PROJECT or EMPLOYEE
Franklin Wong manages the Research DEPARTMENT.
• Relationships of the same type are grouped or typed into
a relationship type. For example, the WORKS_ON
relationship type in which EMPLOYEEs and PROJECTs
participate, or the MANAGES relationship type in which
EMPLOYEEs and DEPARTMENTs participate.
• The degree of a relationship type is the number of
participating entity types. Both MANAGES and
WORKS_ON are binary relationships.
 Database Schema
• A database schema refers to the logical and
visual configuration of the entire relational
database. The database objects are often
grouped and displayed as tables, functions,
and relations.
• A schema describes the organization and
storage of data in a database and defines the
relationship between various tables.
 Contd..
• In general, a relation schema consists of a list
of attributes and their corresponding domains.
 Keys
• A superkey is a set of one or more attributes
that, taken collectively, allow us to identify
uniquely a tuple in the relation. For example,
the ID attribute of the relation instructor is
sufficient to distinguish one instructor tuple
from another.
• A tuple, also known as a record or row, is a
basic unit of data in a relational database
management system (DBMS)
• Super key is a single key or a group of multiple
keys that can uniquely identify tuples in a
table.
• A primary key is the column or columns that
contain values that uniquely identify each row
in a table. A database table must have a
primary key for Optimize to insert, update,
restore, or delete data from a database table.
• A foreign key is a column or group of columns
in a relational database table that provides a
link between data in two tables
 Schema Diagrams
• A database schema, along with primary key
and foreign key dependencies, can be
depicted by schema diagrams.
 Example 1: Online Shopping System

• Entities: Customer, Order, Product, Category,

OrderDetail.

• Relationships: Customer 'places' Order, Order

'contains' Product, Product 'belongs to'
Category, OrderDetail 'connects' Order and
Product.
In this schema:
• The Customer table represents the customers who place orders.
• The Category table represents the categories to which products
belong.
• The Product table represents the products that can be ordered.
Each product belongs to a category, represented by the foreign
key CategoryID.
• The Order table represents the orders placed by customers.
Each order is placed by a customer, who is represented by the
foreign key CustomerID.
• The OrderDetail table represents the many-to-many
relationship between orders and products. Each row in this
table represents a product contained in an order and the
quantity of that product in the order.
• Description: This diagram models an online
shopping system. Customers place orders,
each of which contains one or more products.
Products belong to categories for easy
classification and search.
 ER Design Issues

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.
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.
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.
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.
 Concept design
• Conceptual database design is the process of
identifying the essential data elements,
relationships, and constraints in a data model,
which represents a particular organization's
business requirements.
• The conceptual design stage is the first step in
the database design process, which precedes
the logical and physical design stages.
Example
Objectives of Conceptual Database Design

The primary objective of conceptual database

design is to create a high-level data model that
reflects the business requirements and
provides a clear understanding of the data
elements, relationships, and constraints
involved.
The key objectives of conceptual database design are
as follows:
• Identify the entities and their attributes − Entities
are objects or concepts that exist in the real world
and can be distinguished from each other. Attributes
are the properties or characteristics of the entities.
• Define the relationships − Relationships are the
associations between entities. The second objective
of conceptual database design is to define the
relationships between the identified entities.
Relationships can be one-to-one, one-to-many, or
many-to-many.
• Establish the constraints − Constraints are the
rules that govern the relationships between
entities. The third objective of conceptual
database design is to establish the constraints
between entities, which ensure data
consistency and integrity.
 Process of Conceptual Database Design

The process of conceptual database design

involves the following steps :
Requirements gathering − The first step in
conceptual database design is to gather the
business requirements from the stakeholders.
This involves identifying the data elements,
relationships, and constraints that are
essential to the organization's business
requirements.
• Entity-relationship modeling − The second
step in conceptual database design is to create
an entity-relationship (ER) model, which
represents the entities, attributes, and
relationships between the entities. The
ER model is a graphical representation of the
data elements and their relationships.
Normalization − The third step in conceptual
database design is to normalize the ER model,
which ensures that the data is organized
efficiently and reduces data redundancy.
Review and feedback − The fourth step in
conceptual database design is to review the
ER model with the stakeholders and
incorporate their feedback into the design.
Thank you