Database Management

System (DBMS)
SEM 1
IBS
 Basic Definitions

 Database: A collection of related data.

 Data: Known facts that can be recorded and have an implicit meaning.
 Mini-world: Some part of the real world about which data is stored in a database.
For example, student grades and transcripts at a university.
 Database Management System (DBMS): The DBMS is a general-purpose
software system that facilitates the processes of defining, constructing,
manipulating, and sharing databases among various users and applications
 Database System: The DBMS software together with the data itself. Sometimes,
the applications are also included.
DBMS

 The DBMS is a general-purpose software system that facilitates the processes

of defining, constructing, manipulating, and sharing databases among
various users and applications.
 Defining a database involves specifying the data types, structures, and
constraints of the data to be stored in the database.
 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 in the mini
world, and generating reports from the data.
 Sharing a database allows multiple users and programs to access the
database simultaneously.
 It is useful to describe the database as a part of a larger
undertaking known as an information system within any
organization.
 The Information Technology (IT) department within a
company designs and maintains an information system
consisting of various computers, storage systems, application
software, and databases.
 Phases of Designing a Database

 Design of a new application for an existing database or design of a brand new

database starts off with a phase called requirements specification and analysis.
 These requirements are documented in detail and transformed into a conceptual
design that can be represented and manipulated using some computerized tools so
that it can be easily maintained, modified, and transformed into a database
implementation.
 The design is then translated to a logical design that can be expressed in a data
model implemented in a commercial DBMS.
 The final stage is physical design, during which further specifications are provided
for storing and accessing the database.
Characteristics Of The Database Approach

 Way of Storing the data

 Reduced Redundancy
 Concurrent Access
 Data Consistency
 Security
 Transaction Support
 Self-describing nature of a database system
 Support of Multiple Views of the Data
Advantages of Using the DBMS Approach

 Controlling Redundancy
 Restricting Unauthorized Access
 Providing Backup and Recovery
 Providing Multiple User Interfaces
 Representing Complex Relationships among Data
 Enforcing Integrity Constraints
 Availability of Up-to-Date Information
Data Models

 Data abstraction generally refers to the suppression of details

of data organization and storage, and the highlighting of the
essential features for an improved understanding of data.
 One of the main characteristics of the database approach is to
support data abstraction so that different users can perceive
data at their preferred level of detail.
Data Models

 A data model—a collection of concepts that can be used to

describe the structure of a database—provides the necessary
means to achieve this abstraction.
 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.
Categories of Data Models

 Many data models have been proposed, which we can

categorize according to the types of concepts they use to
describe the database structure.
 High-level or conceptual data models provide concepts that are
close to the way many users perceive data,
 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
Types of Data Models

 Relational Data Models

 Object Data Model
 Hierarchical Data Model
 Network Data Models
High-level Or Conceptual Data Models

 Conceptual data models use concepts such as entities, attributes, and

relationships.
 An entity represents a real-world object or concept, such as an
employee or a project from the mini world that is described in the
database.
 An attribute represents some property of interest that further describes
an entity, such as the employee’s name or salary.
 A relationship among two or more entities represents an association
among the entities, for example, a works-on relationship between an
employee and a project.
Schemas, Instances, and Database State

 In any data model, it is important to distinguish between the description of the

database and the database itself.
 The description of a database is called the database schema, which is specified during
database design and is not expected to change frequently
 The data in the database at a particular moment in time is called a database state or
snapshot. It is also called the current set of occurrences or instances in the database.
Relational Model Concepts

 The relational model represents the database as a collection of

relations
 each relation resembles a table of values
 In the formal relational model terminology, a row is called a
tuple, a column header is called an attribute, and the table is
called a relation
Domains, Attributes, Tuples, and Relations
Domains

 A domain D is a set of atomic values. By atomic we mean that each value in the
domain is indivisible as far as the formal relational model is concerned.
 Some examples of domains follow:
 Social_security_numbers. The set of valid nine-digit Social Security numbers.
 Names: The set of character strings that represent names of persons.
 Employee_ages. Possible ages of employees in a company; each must be an integer value
between 15 and 80.
 A relation schema R, denoted by R(A1, A2, ...,An), is made up of a relation name R
and a list of attributes, A1, A2, ...,An.
 The degree (or arity) of a relation is the number of attributes n of its relation
schema.
 A relation of degree seven, which stores information about university students,
would contain seven attributes describing each student. as follows:
 STUDENT(Name, Ssn, Home_phone, Address, Office_phone, Age, Gpa)
 Using the data type of each attribute, the definition is sometimes written as:
 STUDENT(Name: string, Ssn: string, Home_phone: string, Address: string,
Office_phone: string, Age: integer, Gpa: real)
 Several types of attributes occur in the ER model:
 simple versus composite,
 single valued versus multivalued, and
 stored versus derived
 NULL Values
 Complex Attributes
Complex Attributes
Values and NULLs in the Tuples

 An Each value in a tuple is an atomic value; that is, it is not divisible into components
within the framework of the basic relational model. Hence, composite and multivalued
attributes are not allowed.
 important concept is that of NULL values, which are used to represent the values of
attributes that may be unknown or may not apply to a tuple.
 In general, we can have several meanings for NULL values, such as value unknown, value
exists but is not available, or attribute does not apply to this tuple (also known as value
undefined)
E-R Data Model

 Overview of the database design process:

 Requirements collection and analysis: During this step, the
database designers interview prospective database users to
understand and document their data requirements.
 Conceptual schema: The conceptual schema is a concise
description of the data requirements of the users and includes
detailed descriptions of the entity types, relationships, and
constraints;
E-R Data Model

 Overview of the database design process:

 Logical design or data model mapping: It includes the
transformation of conceptual schema from high level data model to
implementation data model.
 Physical design: during which the internal storage structures, file
organizations, indexes, access paths, and physical design
parameters for the database files are specified.
 For example, an EMPLOYEE entity may be described by the
employee’s name, age, address, salary, and job.
Entity Types, Entity Sets, Attributes,
and Keys

 Entities and Attributes: The basic object that the ER model

represents is an entity, which is a thing in the real world with
an independent existence. 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). Each entity has attributes—the particular properties
that describe it.
Entity Types, Entity Sets, Keys, and Value Sets

 An entity type defines a collection (or set) of entities that have

the same attributes.
 The collection of all entities of a particular entity type in the
database at any point in time is called an entity set
Entity Types, Entity Sets, Keys, and Value Sets
Key Attributes of an Entity Type

 An important constraint on the entities of an entity type is the key or uniqueness

constraint on attributes.
 An entity type usually has one or more attributes whose values are distinct for each
individual entity in the entity set.
 Such an attribute is called a key attribute, and its values can be used to identify
each entity uniquely.
 In ER diagrammatic notation, each key attribute has its name underlined inside the
oval
 An entity type may also have no key, in which case it is called a weak entity type
Rules For Denoting In ER Diagram

 An entity type is represented in ER diagrams as a rectangular

box enclosing the entity type name.
 Attribute names are enclosed in ovals and are attached to
their entity type by straight lines.
 Composite attributes are attached to their component
attributes by straight lines.
 Multivalued attributes are displayed in double ovals.
 Relational Model Constraints

 There are generally many restrictions or constraints on the actual values in a

database state. These constraints are derived from the rules in the mini world that
the database represents.
 The schema-based constraints include:
 domain constraints,
 key constraints,
 Constraints on NULLs,
 entity integrity constraints,
 referential integrity constraints
 Foreign Key.
A Sample Database Application

 Consider a sample database application, called COMPANY

 The COMPANY database keeps track of a company’s
employees, departments, and projects.
 Suppose that after the requirements collection and analysis
phase, the database designers provide the following description
of the mini-world—the part of the company that will be
represented in the database.
A Sample Database Application

 The company is organized into departments. Each department has a unique

name, a unique number, and a particular employee who manages the
department. We keep track of the start date when that employee began
managing the department. A department may have several locations.
 A department controls a number of projects, each of which has a unique
name, a unique number, and a single location.
 We store each employee’s name, Social Security number, address, salary,
gender, and birth date. An employee is assigned to one department, but may
work on several projects, which are not necessarily controlled by the same
department. We keep track of the current number of hours per week that an
employee works on each project. We also keep track of the direct supervisor
of each employee (who is another employee).
A Sample Database Application

 We want to keep track of the dependents of each employee for

insurance purposes. We keep each dependent’s first name, sex,
birth date, and relationship to the employee.
Initial Conceptual Design of the COMPANY Database

 four entity types can be identified:

 An entity type DEPARTMENT with attributes Name, Number, Locations, Manager,
and Manager_start_date. Locations is the only multivalued attribute. We can specify
that both Name and Number are (separate) key attributes because each was specified to
be unique.
 An entity type PROJECT with attributes Name, Number, Location, and
Controlling_department. Both Name and Number are (separate) key attributes.
 An entity type EMPLOYEE with attributes Name, Ssn, Sex, Address, Salary,
Birth_date, Department, and Supervisor. Both Name and Address may be composite
attributes; however, this was not specified in the requirements. We must go back to the
users to see if any of them will refer to the individual components of Name—
First_name, Middle_initial, Last_name—or of Address.
 An entity type DEPENDENT with attributes Employee, Dependent_name, Sex,
Birth_date, and Relationship (to the employee).
Relationship Types, Sets, and Instances

 A relationship type R among n entity types E1, E2, ..., En

defines a set of associations— or a relationship set—among
entities from these entity types.
 In ER diagrams, relationship types are displayed as diamond-
shaped boxes, which are connected by straight lines to the
rectangular boxes representing the participating entity types.
The relationship name is displayed in the diamond-shaped box
Relationship Degree, Role Names,
and Recursive Relationships

 Degree of a Relationship Type: 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.
Cardinality Ratios for Binary Relationships

 The cardinality ratio for a binary relationship specifies the

maximum number of relationship instances that an entity can
participate in.
 The possible cardinality ratios for binary relationship types are
1:1, 1:N, N:1, and M:N
 Cardinality ratios for binary relationships are represented on
ER diagrams by displaying 1, M, and N on the diamonds
Cardinality Ratios for Binary Relationships
Participation Constraints and Existence Dependencies

 The participation constraint specifies whether the existence of an entity depends on

its being related to another entity via the relationship type.
 This constraint specifies the minimum number of relationship instances that each
entity can participate in, and is sometimes called the minimum cardinality
constraint.
 There are two types of participation constraints—total and partial
 In ER diagrams, total participation (or existence dependency) is displayed as a
double line connecting the participating entity type to the relationship, whereas
partial participation is represented by a single line
Attributes of Relationship Types

 Relationship types can also have attributes, similar to those of

entity types.
 Attributes of 1:1 or 1:N relationship types can be migrated to
one of the participating entity types.
 In a 1:1 relationship, the attribute of a relationship can be
determined by any of the participating entity.
 For a 1:N relationship type, a relationship attribute can be
migrated only to the entity type on the N-side of the
relationship.
Attributes of Relationship Types

 For M:N relationship types, some attributes may be determined

by the combination of participating entities in a relationship
instance, not by any single entity. Such attributes must be
specified as relationship attributes.
Weak Entity Types

 Entity types that do not have key attributes of their own are
called weak entity types.
 A weak entity type normally has a partial key, which is the
attribute that can uniquely identify weak entities that are
related to the same owner entity
 In ER diagrams, both a weak entity type and its identifying
relationship are distinguished by surrounding their boxes and
diamonds with double lines