1st Week

DATABASE MANAGEMENT SYSTEM (DBMS)

A DB is a collection of related information stored, so that it is available to many users for

different purposes.

Collection of inter-related data

A shared collection of logically related data to meet the needs of an organization.

A data structure stores Meta data (data about data)

Data is recorded for some specific purpose

A DB is a self-describing collection of integrated records.

A database is designed, built, and populated with data for a specific purpose. It has an intended
group of users and some preconceived applications in which these users are interested.

On the conceptual level, the user talks of things in his world, for example, in terms of entities
and relationships. On the logical level, the user talks of things in the database system, for
example, in terms of relations and join operations.

1
The data must be organized in some logical manner so that it can be processed effectively and
efficiently. Data can be organized in the form of file, records, fields, characters.

File: A group of related records is called a file- student

Record: A set of related data items (fields) is called a record

Field: An individual data item within a record is called a field. Ex. Roll,
name, age, sex,
class of a student.

DBMS: A set of related programs that controls the creation

maintenance and utilization
of database of an organization.

A DBMS is a collection of interrelated data and set of programs to

access the data

Two basic operations performed by the DBMS

i) Management/ Maintenance of the Data in the Database

ii) Management of the user associated with the database.

Why DB (Problem with file system)?

Redundancy: Repeated occurrences of the same data in different files.

Problems: Wastage of memory, increased management, increased processing time and cost.
Inconsistency: Logical mismatch of data in files especially caused due to changes.

Atomicity: There may be partial updates in files.

Data Program dependence: Changes in program structure required to incorporate new data
type. Changes in file structure leads to changes in the application program structure.
Data isolation: Multiple files and formats.
Inflexibility: Analysis of data as well as the realization of new application is problematic.

redundancy: multiple copies

• inconsistency: independent updates

• inaccuracy: concurrent updates

• incompatibility: multiple formats

• insecurity: proliferation

2
• inauditability: poor chain of responsibility

• inflexibility: changes are difficult to apply

Solution:

Minimal data redundancy:

Redundancy is carefully controlled by availed duplicate copies of the same data by an integrated
view on data.
The controlled redundancy improves performance.
Data independence:

Application programmes are independent of representation of data and data storage (Abstract
view)
Efficient data Access:

DBMS uses a variety of techniques to store and retrieve data efficiently.

• Application of index structures to have faster access.
Concurrent data access:

System to allow simultaneous access to the same data by different users.

• Each user gets the impression of exclusively accessing data.
• Concept of transaction for the synchronization of concurrent data access.
Consistency of data:

Caused by lack of redundancy. DBMS must ensure consistency of data after each transaction.
Integrity of data:

correctness and completeness of data (Semantic aspects), formulation of integrity constraints and
integrity rules.
• DBMS checks constraints for each insertion, change and deletion of data.
Data Security:

Protection of the database against unauthorized access (view on data)

Access control with authentication and encoding as the possible protection mechanisms

CHARACTERISTICS OF THE DATABASE APPROACH

Programs isolated from data through abstraction:

 Does not expose details of how (or where) data is stored or how operations are
implemented.
 Data sharing through multiple views

3
Multiuser transaction processing

• Encapsulates sequence of operations to behave atomically

Data is self-defining

• Database system contains complete definition of structure and constraints as meta-data (data
about data)

• Database catalog used by:

DBMS software

Database users who need information about database structure

Assignment Question:

Explain the importance of Data Requirements and also outline the data requirements for a
university database.

4
Levels of Data:

Real World Data- objects or entities exist in reality (eg: student, vehicle, Employee)

Meta Data – it is a way to store data in database/ what type of data is stored in Database

What is the type of data/ size of the data

Data Existence – actual data of the entities or objects

(eg: Student Name, Student id) (eg: Vehicle reg#, Model #) (eg: EmplId, EmplDesignation,
EmplSal)

Student (Real World Data)

Name, StdId, StdClass (Data Existence)

Ali CS-007 4

20 Characters Alpha Numeric Numeric Integer/ Character (Meta Data)

5
 2nd Week

Limitations of DBMS:
Increased complexity: A multiuser DBMS is extremely complex piece of software.

Large storage requirement: The large complexity and wide functionality makes DBMS
complex and large size so it occupies a large storage space (few gigabytes)
Required Specialized Manpower : Technical Team to maintain DB

Installation and management cost Increases

Hardware Requirements: depending upon the environment and functionality.
Required Backup and Recovery system in case of damages and failures

Problems of centralizations downtimes and failures

Database Administrators (DBA)

How to design

Manage the data in the DB

Manage the use of DB

DBA also has the responsibility to making proper backups, recovery of DB

Also have some very precisely duties

 Schema Definition- create all the meta data information on which DB is based.
 Grant Data Access - proper access rights to each users, as per role
 Periodical Maintenance
o Monitoring the storage space as the data grows.
o Secure and proper function of DB (all users use their authorities)

Database administrator (DBA) responsible for:

• Authorizing access to the database
• Coordinating and monitoring its use
• Acquiring software and hardware resources
• Tuning the DBMS for best performance
Database designer responsible for:

• Identifying the data to be stored

• Choosing appropriate structures to represent and store this data

6
WHEN NOT TO USE A DBMS
• Simple, well-defined applications with no expected changes at all
• Small variety of data and/or small amount of data
• Stringent, real-time requirements that cannot afford DBMS overhead
• Only single (personal) access to data
Architecture of Database:

7
8
Internal Level:

 Defines the intentions of the database. Internal schema or view defines the structures of
the data and other data related activities in the database
 Describe the physical storage structure of the database.
 Detailed data structure of the data items.
 It defines the intention of the DB, (intention is almost permanent),
 small change in the intention of DB, it requires more changes

Conceptual Level:

 At this level, contains definitions of all the data, defines rules and structure of that data
 Describe relationships among the data., logical structure of the DB

9
  Also holding the authorization and holding information

External Level:

 closest to the user, relevant to the user

 mainly concerned with the way of data is viewed by the user
 contains large number of user views.

Assignment Question: Interpret . Data is Resource

Data Independence:

It is the major feature of the Three Level Database Architecture. It ensures that the change in the
lower level of abstraction in three level architecture does not affect the structure and
functionality of the higher levels.

The ability to modify the schema definition in one level without affecting a schema definition in
the next higher level.

Two Types of Data Independence:

i) Logical Data Independence:

Changes in the conceptual model, do not affect the external views or application
program
All changes are transparently done at different levels
 Adding a file to the database
 Adding a new field in a file
 Changing the type of a specific field

ii) Physical Data Independence

It provides changes transparency between the conceptual and internal levels

For example, Creating additional access structure to improve performance of .the
retrieval and update.

Functions of DBMS

 Data Processing
 User accessible Catalog
 Transaction Support

10
  Concurrency Control Services
 Recovery Services
 Authorization Services
 Support for Data Communication
 Integrity Services

Database Development Process

Approach 1 Approach 2
Preliminary Study Analyze Phase
Requirement Analysis Conceptual Model (requirement analysis)
Database Design Conceptual to Logical Model
Physical Design Select DB
Implementation Develop Physical DB
Maintenance Implement
Test
DATABASE CATALOG

11
 3rd Week

Data Flow Diagrams (DFDs):

DFDs model a perspective of the system that is most readily understood by users – the flow of
information through the system and the activities that process this information

 Most common tool used for deigning database systems

 Used to design systems graphically and expresses different system details.
 Shows the flow of data between different processes or a specific system
 It links processes and describe the information flow
 Flow of information through the system and the activities that process this information

The system scope and boundaries are clearly indicated on the diagrams.

The technique of decomposition of high level data-flow diagrams to a set of more detailed
diagrams, provides an overall view of the complete system.

Data flow diagrams are used to graphically represent the flow of data in a business
information system. DFD describes the processes that are involved in a system to transfer data
from the input to the file storage and reports generation.

graphically representing the functions, or processes, which capture, manipulate, store, and
distribute data between a system and its environment and between components of a system.

DFD has often been used due to the following reasons:

 Logical information flow of the system

 Determination of physical system construction requirements
 Simplicity of notation
 Establishment of manual and automated systems requirements

DFD for a retail store, Billing System

12
Types of DFDs:
i. Context diagram

 This level provides least amount of details of the working system

 Explains the single process and single system.
 Presents an overview of the system and its interaction with external entities.
 Just show the flow of information to and from the process/ system

ii. Level 0 diagram

 Provides the working of whole system
 Shows the interaction between a numbers of processes and may include a large
number of external entities.
Detailed diagram

 Further explain the functionality of the processes that we showed briefly in the
Level 0 Diagram
Elements of data-flow diagrams:
i. Processes
 Essential activities carried out by the system boundaries

ii. Data-Flows
 Used to model the flow of information into the system, out of the system, and
between elements within the system.

iii. Data Stores

 Where data is stored and retrieved within the system. This may be a file

iv. External Entities

 Entities outside of the system boundary which interact with the system

13
Level 0 Diagram

14
Basic terminologies of relational data model: (RDBMS)
1. Entity: A real world object with some properties which can be easily identified is
called an entity.
2. Attributes: An attribute is a descriptive property or a characteristics of an entity.
Ex name, roll marks, etc.
3. Degree: The no of columns or attributes associated with a table ( or a relation
among them) is called degree of the relation.
4. Cardinality: The no of rows in a table is called cardinality.
5. Tuples: A relation consisting of a number of records represented in row wise
information called tuples.
6. Domain: The set of possible values that can allotted to an attribute is called
domain of that attribute. Domain d is a set of atomic values of an attribute.
7. Entity set: A set of entities representing a real world object. Ex. Student,
teacher, depositor, player etc.
8. Weak entity: An entity set which may not have sufficient attribute to form a
primary key then it is called an weak entity.
9. Strong entity: An entity set which have a key attribute.
10. Key: An attribute that allows us to uniquely identity a record or an entity type

Basic Building Blocks of Data Model:

The basic building blocks of all data models are

 Entities,
 Attributes,
 Relationships, and
 Constraints.

A relationship describes an association among entities. For example, a relationship exists

between customers and agents that can be described as follows: an agent can serve many
customers, and each customer may be served by one agent

One-to-many (1:M or 1..*) relationship. A painter paints many different paintings, but each
one of them is painted by only one painter. Thus, the painter (the “one”) is related to the
paintings (the “many”). Therefore, database designers label the relationship “PAINTER paints
PAINTING” as 1:M. (Note that entity names are often capitalized as a convention, so they are
easily identified.) Similarly, a customer (the “one”) may generate many invoices, but each
invoice (the “many”) is generated by only a single customer. The “CUSTOMER generates
INVOICE” relationship would also be labeled 1:M.

15
 Many-to-many (M:N or *..*) relationship. An employee may learn many job skills, and each
job skill may be learned by many employees. Database designers label the relationship
“EMPLOYEE learns SKILL” as M:N.

Similarly, a student can take many classes and each class can be taken by many students, thus
yielding the M:N relationship label for the relationship expressed by “STUDENT takes CLASS.”

One-to-one (1:1 or 1..1) relationship. A retail company’s management structure may require
that each of its stores be managed by a single employee. In turn, each store manager, who is an
employee, manages only a single store. Therefore, the relationship “EMPLOYEE manages
STORE” is labeled 1:1.

A constraint is a restriction placed on the data. Constraints are important because they help to
ensure data integrity. Constraints are normally expressed in the form of rules. For example:

 An employee’s salary must have values that are between 25,000 and 350,000.
 A student’s GPA must be between 0.00 and 4.00.
 Each class must have one and only one teacher.

Database Designer is going to build the Data Model, has to be understand

 what types of data are in an organization,

 how the data are used, and
 what time frames they are used

From a database point of view, the collection of data becomes meaningful only when it reflects
properly defined business rules. Business rules must be rendered in writing and updated to reflect
any change in the organization’s operational environment.

The process of identifying and documenting business rules is essential to database design for
several reasons:

They help to standardize the company’s view of data.

They can be a communications tool between users and designers.

They allow the designer to understand the nature, role, and scope of the data.

They allow the designer to understand business processes.

16
 They allow the designer to develop appropriate relationship participation rules and constraints
and to create an accurate data model.

4th Week

Entity:

 A real world object with some properties which can be easily identified is called an
entity. Two types of entities
i) Independent Entity (Strong Entity):

An entity type whose instances can exist independently, that is, without being linked to the
instances of any other entity type is called strong entity type. A major property of the strong
entity types is that they have their own identification.

ii) Dependent Entity (Weak Entity): An entity whose existence depends on the existence
of another entity is called dependent entity.

Example:

• The existence of the entity marks depend an existence of student.

• Dependent entities are also called weak entities.

Attributes:

 The characteristics of an entity are called attributes.

 An attribute of an entity type is a defining property or quality of the instances of that
entity type. Entity instances of same entity type have the same attribute
 Attributes are the units that describe the characteristics or properties of entities.
 An attribute is identified by a name allocated to it and that has to be unique with respect
to that entity type. It means one entity type cannot have two attributes with the same
name.

Domain:

Domain is the set of possible values that an attribute can have, name and the domain, are part of
the definitions of an attribute.

Domain is a form of a check or a constraint on attribute that it cannot

have a value outside this set.

Assignment Question:

Explain. Associating domain with an attribute helps in maintaining the integrity of the database

17
Types of Attributes

i) Simple Attributes:
 An attribute that is a single whole is a simple attribute. The value of a simple
attribute is considered as a whole, not as comprising of other attributes or
components. For example, attributes stName, stFatherName, stDateOfBorth of
an entity type STUDENT are example of simple attribute
 An attribute composed of a single component with an independent existence

ii) Composite Attributes:

 A Composite attribute is the one that actually consist of all other attributes
 Attribute consists of collection of other simple or composite attributes then it
is called a composite attributes OR an attribute which is further divided into
simple or composite attribute.
iii) Single valued
iv) Multi-valued
v) Required : Mandatory value, don’t allow this attribute to null value. (Key Attribute)
vi) Stored
vii) Derived
Sometimes attributes are not stored, rather they are computed or derived based on
some other value. This other value may be stored in the database or obtained some
other way. For example, we may store the name, father name, address of employees,
but age can be computed from date of birth.
Advantage of declaring age as derived attribute is that whenever we will access the
age, we will get the accurate, current age of employee since it will be computed right
at the time when it is being accessed.

18
ER Model(Entity - Relationship):

Relationships: (it represents an association between two or more entities)

It is a graphical representation of conceptual database design

After two or more entities are identified and defined with attributes, the participants determine if
a relationship exists between the entities.

A relationship type is an abstraction of a relationship i.e. a set of relationships instances sharing

common attribute.

Entities enrolled in a relationship are called its participants. The participation of an entity in a
relationship is total when all entities of that set might be participant in the relationship otherwise
it is partial.

Relationships Symbol:
Shown as a Diamond, it is doubled if one of the participants is dependent on the other.
Participants are connected by continuous lines, labeled to indicate cardinality.
In partial relationships roles (if identifiable) are written on the line connecting the partially
participating entity rectangle to the relationship diamond.
Total participation is indicated by double lines

Types of Relationships:

1. Unary Relationship
An ENTITY TYPE linked with itself, also called recursive relationship
(one student connects with other students, like CR connects with students
Students shares the common room)
2. Binary Relationship
A Binary relationship is the one that links two entities sets

3. Ternary Relationship
A Ternary relationship is the one that involves three entities

19
Relationship Cardinalities
The cardinality of a relationship is the number of entities to which another entity can map under
that relationship.

i. One-to-One mapping:
A mapping R from X to Y is one-to-one if each entity in X is associated with at most
one entity in Y and vice versa
For example: Citizen and ID# are two Entity sets, each citizen has the ID# and one ID#
represents one citizen.

Citizen ID

ii. One-to-Many mapping:

A mapping R from X to Y is one-to-many if each entity in X is associated with many
entities in Y but each entity in Y is associated with one entity in X.

Types of Cardinality

Minimum: optional or compulsory

Maximum

20
Week 5:

Assignment Question:

Identify the details where an ER diagram helps to design Database.

Build- ERD

In a university, a Student enrolls in Courses. A student must be enrolled to at least one or more
Courses. Each course is taught by a single Teacher/ Professor. To maintain instruction quality, a
Teacher/ Professor can deliver only one course

Step 1: Entity Identification

i) Student
ii) Course
iii) Professor

Step 2) Relationship Identification

i) The student is enrolled in a course (at least one or more)

ii) Professor delivers a course (only one course/ not more than one)

Step 3) Cardinality Identification

i) A student can be assigned multiple courses

ii) A Professor can deliver only one course

The existence of an optional entity indicates that the minimum cardinality is 0 for the optional
entity. The existence of a mandatory relationship indicates that the minimum cardinality is at
least 1 for the mandatory entity.
21
Step 4) Identify Attributes

Need to study the files, forms, reports, data currently maintained by the organization to identify
attributes, it's important to identify the attributes without mapping them to a particular entity

Practice Question:

Student, Teacher, Course and Course offering are entities of DB. Students may enrolled
themselves in the offering courses in respective semester and year, courses are assigned in way
that no two teachers can be taught the same subjects, all courses fulfills the prerequisite criteria.
All the information related the course may be stored in DB. Build the ER diagram.

22
There are two types of participation constraints: Total and Partial
 Total Participation
Total Participation is when each entity in the entity set occurs in at least one
relationship in that relationship set.
For instance, consider the relationship borrower between customers and loans. A
double line from loan to borrower, as shown in figure below indicates that each loan
must have at least one associated customer.

 Partial Participation
Partial Participation is when each entity in the entity set may not occur in at least one
relationship in that relationship set. For instance, If a company policy states that
employee (manager) must manage a department, However every employee may not
manage a department, so the participation of EMPLOYEE in the MANAGES relationship
type is partial, meaning that some or part of the set of employee entities are related to
some department entity via MANAGES, but not necessarily all.
Note: Partial Participation is represented by single line connecting entities in
relationship.

Assignment Question:

Given the conceptual model in above Figure

23
a. Write the business rules that are reflected in it.

b. Identify all of the cardinalities.

Practice Question:

Develop an ER Diagram that models the examination System.

Entities: Student, Teacher, Exam, Courses

24