DRIVE

SUMMER 2014

PROGRAM

MBADS (SEM 3/SEM 5)

MBAFLEX/ MBA (SEM 3)
PGDISMN (SEM 1)
II

SEMESTER
SUBJECT CODE &
NAME
BK ID

MI0034 DATABASE MANAGEMENT SYSTEM

CREDIT & MARKS

4 Credits, 60 marks

B1973

ASSIGNMENT

Name:

Ajeet Kumar

Roll No:

1405010120

Center Code:

3293

MI0034 DATABASE MANAGEMENT SYSTEM

Q1 a. Database management system acts as intermediary agent

between programs and the data. Explain various procedures carried on
in a DBMS with example.
b. List and explain the properties of DBMS

Explaining the three procedures carried on in a DBMS

1. Controlling Redundancy: In file system, each application has its own private files, which
cannot be shared between multiple applications. This can often lead to considerable redundancy in
the stored data, which results in wastage of storage space. By having centralized database most of
this can be avoided. It is not possible that all redundancy should be eliminated. Sometimes there
are sound business and technical reasons for maintaining multiple copies of the same data. In a
database system, however this redundancy can be controlled.
For example: In case of college database, there may be the number of applications like General
Office, Library, Account Office, Hostel etc. Each of these applications may maintain the following
information into own private file applications:

It is clear from the above file systems, that there is some common data of the student which has to
be mentioned in each application, like Rollno, Name, Class, Phone_No~ Address etc. This will cause
the problem of redundancy which results in wastage of storage space and difficult to maintain, but
in case of centralized database, data can be shared by number of applications and the whole
college can maintain its computerized data with the following database:

It is clear in the above database that Rollno, Name, Class, Father_Name, Address,
Phone_No, Date_of_birth which are stored repeatedly in file system in each application, need not be
stored repeatedly in case of database, because every other application can access this information
by joining of relations on the basis of common column i.e. Rollno. Suppose any user of Library
system need the Name, Address of any particular student and by joining of Library and General
Office relations on the basis of column Rollno he/she can easily retrieve this information.

Thus, we can say that centralized system of DBMS reduces the redundancy of data to great extent
but cannot eliminate the redundancy because RollNo is still repeated in all the relations.

2. Integrity can be enforced: Integrity of data means that data in database is always accurate,
such that incorrect information cannot be stored in database. In order to maintain the integrity of
data, some integrity constraints are enforced on the database. A DBMS should provide capabilities
for defining and enforcing the constraints.

For Example: Let us consider the case of college database and suppose that college having only
BTech, MTech, MSc, BCA, BBA and BCOM classes. But if a \.,ser enters the class MCA, then this
incorrect information must not be stored in database and must be prompted that this is an invalid
data entry. In order to enforce this, the integrity constraint must be applied to the class attribute of
the student entity. But, in case of file system tins constraint must be enforced on all the application
separately (because all applications have a class field).

In case of DBMS, this integrity constraint is applied only once on the class field of the
General Office (because class field appears only once in the whole database), and all other
applications will get the class information about the student from the General Office table so the
integrity constraint is applied to the whole database. So, we can conclude that integrity constraint
can be easily enforced in centralized DBMS system as compared to file system.

3. Inconsistency can be avoided: When the same data is duplicated and changes are made at
one site, which is not propagated to the other site, it gives rise to inconsistency and the two entries
regarding the same data will not agree. At such times the data is said to be inconsistent. So, if the
redundancy is removed chances of having inconsistent data is also removed.

Let us again, consider the college system and suppose that in case of General_Office file. it is
indicated that Roll_Number 5 lives in Amritsar but in library file it is indicated that . Roll_Number 5
lives in Jalandhar. Then, this is a state at which tIle two entries of the same object do not agree
with each other (that is one is updated and other is not). At such time the database is said to be
inconsistent.
An inconsistent database is capable of supplying incorrect or conflicting information. So there
should be no inconsistency in database. It can be clearly shown that inconsistency can be avoided
in centralized system very well as compared to file system.
Let us consider again, the example of college system and suppose that RollNo 5 is .shifted from
Amritsar to Jalandhar, then address information of Roll Number 5 must be updated, whenever Roll
number and address occurs in the system. In case of file system, the information must be updated
separately in each application, but if we make updation only at three places and forget to make
updation at fourth application, then the whole system show the inconsistent results about Roll
Number 5.

In case of DBMS, Roll number and address occurs together only single time in General_Office table.
So, it needs single updation and then an other application retrieve the address information from

General_Office which is updated so, all application will get the current and latest information by
providing single update operation and this single update operation is propagated to the whole
database or all other application automatically, this property is called as Propagation of Update.
We can say the redundancy of data greatly affect the consistency of data. If redundancy is less, it is
easy to implement consistency of data. Thus, DBMS system can avoid inconsistency to great
extent.

4. Restricting unauthorized access: When multiple users share a database, it is likely that some
users will not be authorized to access all information in the database. For example, account office
data is often considered confidential, and hence only authorized persons are allowed to access
such data. In addition, some users may be permitted only to retrieve data, whereas other are
allowed both to retrieve and to update. Hence, the type of access operation retrieval or update
must also be controlled. Typically, users or user groups are given account numbers protected by
passwords, which they can use to gain access to the database. A DBMS should provide a security
and authorization subsystem, which the DBA uses to create accounts and to specify account
restrictions. The DBMS should then enforce these restrictions automatically.

5. Solving Enterprise Requirement than Individual Requirement: Since many types of users
with varying level of technical knowledge use a database, a DBMS should provide a variety of user
interface. The overall requirements of the enterprise are more important than the individual user
requirements. So, the DBA can structure the database system to provide an overall service that is
"best for the enterprise".
For example: A representation can be chosen for the data in storage that gives fast access for the
most important application at the cost of poor performance in some other application. But, the file
system favors the individual requirements than the enterprise requirements

Listing three important properties of database

Atomicity
Atomicity refers to the ability of the database to guarantee that either all of the tasks of a
transaction are performed or none of them are. Database modifications must follow an all or
nothing rule. Each transaction is said to be atomic if when one part of the transaction fails, the
entire transaction fails.
Consistency
The consistency property ensures that the database remains in a consistent state before the start
of the transaction and after the transaction is over (whether successful or not). For example, in a
storefront there is an inconsistent view of what is truly available for purchase if inventory is allowed
to fall below 0, making it impossible to provide more than an intent to complete a transaction at
checkout time. An example in a double-entry accounting system illustrates the concept of a true
transaction. Every debit requires an associated credit. Both of these happen or neither happen.
A distributed data system is either strongly consistent or has some form of weak consistency. Once
again, using the storefront example, a database needs to provide consistency and isolation, so that
when one customer is reducing an item in stock and in parallel is increasing the basket by one, this
is isolated from another customer who will have to wait while the data store catches up. At the
other end of the spectrum is BASE (Basically Available Soft-state Eventual consistency).
Weak consistency is sometimes referred to as eventual consistency, the database eventually
reaches a consistent state. Weak consistency systems are usually ones where data is replicated;
the latest version is sitting somewhere in the cluster, older versions are still out there. Eventually
all nodes will see the latest version.
Isolation
Isolation refers to the requirement that other operations cannot access or see the data in an
intermediate state during a transaction. This constraint is required to maintain the performance as
well as the consistency between transactions in a database. Thus, each transaction is unaware of
another transactions executing concurrently in the system.
Durability

Durability refers to the guarantee that once the user has been notified of success, the transaction
will persist, and not be undone. This means it will survive system failure, and that the database
system has checked the integrity constraints and won't need to abort the transaction. Many
databases implement durability by writing all transactions into a transaction log that can be played
back to recreate the system state right before a failure. A transaction can only be deemed
committed after it is safely in the log.
Durability does not imply a permanent state of the database. Another transaction may overwrite
any changes made by the current transaction without hindering durability.
meaning and example of domain
Definition: The domain of a database attribute is the set of all allowable values that attribute may
assume. In database technology, domain refers to the description of an attribute's allowed values.
The physical description is a set of values the attribute can have, and the semantic, or logical,
description is the meaning of the attribute. A group of computers and devices on a network that
are administered as a unit with common rules and procedures. Within the Internet, domains are
defined by the IP address. All devices sharing a common part of the IP address are said to be in the
same domain.
Examples: A field for gender may have the domain {male, female, unknown} where those three
values are the only permitted entries in that column.
defining degree of relation with example
Degree of relationship refers to the number of participating entities in a relationship. If there are
two entities involved in relationship then it is referred to as binary relationship. If there are three
entities involved then it is called as ternary relationship and so on.
On the other hand, it is the cardinality of relationship that defines the number of instances of one
entity as it relates to the number of instances of the other entity. Based on the different
combinations between two entities we can have either one-to-one, one-to-many or many-to-many
relationship.
The degree of relationship (also known as cardinality) is the number of occurrences in one entity
which are associated (or linked) to the number of occurrences in another.
There are three degrees of relationship, known as:
1. one-to-one (1:1)
2. one-to-many (1:M)
3. many-to-many (M:N)
meaning and example of entity set
An entity set is a logical container for instances of an entity type and instances of any type derived
from that entity type. (For information about derived types, see Entity Data Model: Inheritance.)
The relationship between an entity type and an entity set is analogous to the relationship between
a row and a table in a relational database: Like a row, an entity type describes data structure, and,
like a table, an entity set contains instances of a given structure. An entity set is not a data
modeling construct; it does not describe the structure of data. Instead, an entity set provides a
construct for a hosting or storage environment (such as the common language runtime or a SQL
Server database) to group entity type instances so that they can be mapped to a data store.
Example
The diagram below shows a conceptual model with three entity types: Book, Publisher, and Author.

explain primary key with example

Definition: The primary key of a relational table uniquely identifies each record in the table. It can
either be a normal attribute that is guaranteed to be unique (such as Social Security Number in a
table with no more than one record per person) or it can be generated by the DBMS (such as a
globally unique identifier, or GUID, in Microsoft SQL Server). Primary keys may consist of a single
attribute or multiple attributes in combination.
Examples: Imagine we have a STUDENTS table that contains a record for each student at a
university. The student's unique student ID number would be a good choice for a primary key in the
STUDENTS table. The student's first and last name would not be a good choice, as there is always
the chance that more than one student might have the same name.
define tuple with example
In the context of databases, a tuple is one record (one row).

i n mathematics, a tuple is an ordered list of elements. Related to this is an n-tuple, which in set
theory is a collection (sequence) of "n" elements. Given this, it might be more properly said that
tuples are implemented as records even though the terms are commonly used interchangeably.
A tuple is a finite ordered list of elements. In mathematics, an n-tuple is a sequence (or ordered
list) of n elements, where n is a non-negative integer. There is only one 0-tuple, an empty
sequence. An n-tuple is defined inductively using the construction of an ordered pair. Tuples are
usually written by listing the elements within parentheses "(\text{ })" and separated by commas;
for example, (2, 7, 4, 1, 7) denotes a 5-tuple. Sometimes other symbols are used to surround the
elements, such as square brackets "[ ]" or angle brackets "\langle\text{ }\rangle". Braces "{ }" are
never used for tuples, as they are the standard notation for sets. Tuples are often used to describe
other mathematical objects, such as vectors. In computer science, tuples are directly implemented
as product types in most functional programming languages. More commonly, they are
implemented as record types, where the components are labeled instead of being identified by
position alone.
defining cardinality ratio
In database design, the cardinality or fundamental principle of one data table with respect to
another is a critical aspect. The relationship of one to the other must be precise and exact between
each other in order to explain how each table links together.
In the relational model, tables can be related as any of "one-to-many" or "many-to-many." This is
said to be the cardinality of a given table in relation to another.
For example, consider a database designed to keep track of hospital records. Such a database
could have many tables like:

a doctor table with information about physicians;

a patient table for medical subjects undergoing treatment;

and a department table with an entry for each division of a hospital.

explaining the four types of mapping cardinalities
A mapping cardinality is a data constraint that specifies how many entities an entity can be
related to in a relationship set.
Example: A student can only work on two projects, the number of students that work on one
project is not limited.
A binary relationship set is a relationship set on two entity sets. Mapping cardinalities on binary
relationship sets are simplest.
Consider a binary relationship set R on entity sets A and B. There are four possible mapping
cardinalities in this case:
1. one-to-one - an entity in A is related to at most one entity in B, and an entity in B is
related to at most one entity in A.

2.

Example: person <-> weight

one-to-many - an entity in A is related to any number of entities in B, but an entity in B is
related to at most one entity in A.

Example: Birth Place <-> person

3.

many-to-one - an entity in A is related to at most one entity in B, but an entity in B is

related to any number of entities in A.

Example: author <-> book

4.

many-to-many - an entity in A is related to any number of entities in B, but an entity in B

is related to any number of entities in A.

Example: person <-> book

Describing two phase locking
Explaining growing phase, shrinking phase and strict two phase locking and deadlock
and starvation
In databases and transaction processing, two-phase locking (2PL) is a concurrency control method
that guarantees serializability. It is also the name of the resulting set of database transaction
schedules (histories). The protocol utilizes locks, applied by a transaction to data, which may block
(interpreted as signals to stop) other transactions from accessing the same data during the
transaction's life.
By the 2PL protocol locks are applied and removed in two phases:

Expanding phase: locks are acquired and no locks are released.

Shrinking phase: locks are released and no locks are acquired.

Two types of locks are utilized by the basic protocol: Shared and Exclusive locks. Refinements of
the basic protocol may utilize more lock types. Using locks that block processes, 2PL may be
subject to deadlocks that result from the mutual blocking of two or more transactions.
Two-phase locking
According to the two-phase locking protocol a transaction handles its locks in two distinct,
consecutive phases during the transaction's execution:
Expanding phase (aka Growing phase): locks are acquired and no locks are released (the
number of locks can only increase).
Shrinking phase: locks are released and no locks are acquired.
The two phase locking rule can be summarized as: never acquire a lock after a lock has been
released. The serializability property is guaranteed for a schedule with transactions that obey this
rule.
Typically, without explicit knowledge in a transaction on end of phase-1, it is safely determined only
when a transaction has completed processing and requested commit. In this case all the locks can
be released at once (phase-2).
Strict two-phase locking
To comply with the S2PL protocol a transaction needs to comply with 2PL, and release its write
(exclusive) locks only after it has ended, i.e., being either committed or aborted. On the other
hand, read (shared) locks are released regularly during phase 2. This protocol is not appropriate in
B-trees because it causes Bottleneck (while B-trees always starts searching from the parent root).
deadlock and starvation
deadlock
A deadlock is a condition that occurs when two threads or processes wait for each other to
complete the task. They will only hang up but never stop or finish their task. In computer science,

deadlocks can be seen everywhere. In a transaction database, when two processes each within its
own transaction update the same two rows of information but in the opposite order, will cause a
deadlock. In concurrent programming, a deadlock may occur when two competing actions will wait
for each other to proceed forward. In telecommunications systems, a deadlock can happen due to
loss or corruption of signals.
At present, deadlock is one of the main problems in multiprocessing systems and parallel
computing. As a solution, a locking system called process synchronization is implemented for
software as well as hardware.
starvation
From the dictionary of medical science, starvation is a result of severe or total lack of nutrients that
are needed for the maintenance of life. Similarly, in computer science, starvation is a problem that
is encountered when multiple threads or processes wait for the same resource, which is called a
deadlock.
In order to get out from a deadlock, one of the processes or threads should have to give up or roll
back so that the other thread or process can use the resource. If this continuously happens and the
same process or thread have to give up or roll back each time while letting other processes or
threads to use the resource, then the selected process or thread, which rolled back will undergo a
situation called starvation. Therefore, in order to get out from a deadlock, starvation is one of the
solutions. Therefore, sometimes starvation is called a kind of a livelock. When there are many high
priority processes or threads, a lower priority process or thread will always starve in a deadlock.
There can be many starvations such as starving on resources and starving on CPU. There are many
common examples on starvation. They are Readers-writers problem and dining philosophers
problem, which is more famous. There are five silent philosophers sitting at a round table with
bowls of spaghetti. Forks are placed between each pair of adjacent philosophers. Each philosopher
must alternately think and eat. However, a philosopher can only eat spaghetti when he has both
left and right forks.
Explaining five advantages of distributed database management systems
There are following advantages of DDBMs:
Reflects organizational structure
Many organizations are naturally distributed over several locations. For example, a bank has many
offices in different cities. It is natural for databases used in such an application to be distributed
over these locations. A bank may keep a database at each branch office containing details such
things as the staff that work at that location, the account information of customers etc.
The staff at a branch office will make local inquiries of the database. The company headquarters
may wish to make global inquiries involving the access of data at all or a number of branches.
Improved share ability and local autonomy
The geographical distribution of an organization can be reflected in the distribution of the data;
users at one site can access data stored at other sites. Data can be placed at the site close to the
users who normally use that data. In this way, users have local control of the data, and they can
consequently establish and enforce local policies regarding the use of this data. A global database
administrator (DBA) is responsible for the entire system. Generally, part of this responsibility is
assigned the local level, so that the local DBA can manage the local DBMS.
Improved availability
In a centralized DBMS, a computer failure terminates the applications of the DBMS. However, a
failure at one site of a DDBMS, or a failure of a communication link making\ some sites
inaccessible, does not make the entire system in opera bite. Distributed DBMSs are designed to
continue to function despite such failures. If a single node fails, the system may be able to reroute
the failed node's requests to another site.
Improved reliability
As data may be replicated so that it exists at more than one site, the failure of a node or a
communication link does not necessarily make the data inaccessible.
Improved Performance
As the data is located near the site of 'greatest demand', and given the inherent parallelism of
distributed DBMSs, speed of database access may be better than that achievable from a remote
centralized database. Furthermore, since each site handles only a part of the entire database, there
may not be the same contention for CPU and I/O services as characterized by a centralized DBMS.
Economics
It is now generally accepted that it costs much less to create a system of smaller computers with
the equivalent power of a single large computer. This makes it more cost effective for corporate
divisions and departments to obtain separate computers. It is also much more cost-effective to add
workstations to a network than to update a mainframe system.
The second potential cost saving occurs where database are geographically remote and the
applications require access to distributed data. In such cases, owing to the relative expense of data

being transmitted across the network as opposed to the cost of local access, it may be much more
economical to partition the application and perform the processing locally at each site.
Modular growth
In a distributed environment, it is much easier to handle expansion. New sites can be added to the
network without affecting the operations of other sites. This flexibility allows an organization to
expand relatively easily. Adding processing and storage power to the network can usually handle
the increase in database size. In a centralized DBMS, growth may entail changes to both hardware
(the procurement of a more powerful system) and software (the procurement of a more powerful or
more configurable DBMS)

8 advantages of ODBMS
Advantages of Object Oriented DBMSs (OODBMS)
An object database (also object-oriented database management system) is a database
management system in which information is represented in the form of objects as used in objectoriented programming. Object databases are different from relational databases which are tableoriented. Object-relational databases are a hybrid of both approaches.
Enhanced modeling capabilities it is easy to model the real-world object as close as possible
like the case of Object Oriented Programming concepts.
Extensibility Support for new data types - Unlike traditional DBMS products where the basic
data types are hard-coded in the DBMS and are unchangeable by the users, with an ODBMS the
user can encode any type of structure that is necessary and the ODBMS will manage that type.
Removal of impedance mismatch Impedance mismatch is a set of conceptual and technical
difficulties that are often encountered when a relational database management system (RDBMS) is
being used by a program written in an object-oriented programming language or style; particularly
when objects or class definitions are mapped in a straightforward way to database tables or
relational schema. The DML of OODBMS can eliminate the difficulties.
Expressive power provides an ability to handle objects like records in RDBMS. Hence, OODBMS
is more expressive than RDBMS. An object database stores complex data and relationships
between data directly, without mapping to relational rows and columns, and this makes them
suitable for applications dealing with very complex data.
Support for schema evolution
Support for long-duration transactions the process of object data involves increased
complexity. Hence, we need to provide support for long-duration transactions.
Applicability to advanced database applications enhanced modeling capabilities of
OODBMS makes it usable to application like computer-aided design (CAD), computer-aided software
engineering (CASE), office information systems (OISs), multimedia systems, and many more.
Improved performance improved performance in the case of object based applications.
Reusability the code can be reused. Inheritance, method support, etc enables the possibility of
reusing the code. An OODBMS can be programmed with small procedural differences without
affecting the entire system
OODBs eliminate need for user defined keys - The OODB model has an OID that it is
automatically generated by the system and that guarantees uniqueness to each object. This, in
addition to eliminating the need for user defined keys in the OODB model, has brought other
advantages to OODBs: 1) the OID cannot be modified by the application; 2) the notion of object
identity provides a separate and consistent notion of identity, which is independent of how an
object is accessed or modeled with descriptive data. Therefore, two objects are different if they
have different OIDs, even if they have the same structures and the same values for all their
properties.
OODBs reduce need for Joins - The capability of navigating through object structures and the
resulting path expressions in object attributes gives us a new perspective on the issue of joins in
OODBs. The relational join is a mechanism that correlates two relations on the basis of values of a
corresponding pair or attributes in the relations. Since two classes in an OODB may have
corresponding pairs of attributes, the relational join (or, explicit join) may still be necessary in
OODBs
Disadvantages of OODBMSs
There are following disadvantages of OODBMSs:
Lack of universal data model: There is no universally agreed data model for an OODBMS, and
most models lack a theoretical foundation. This .disadvantage is seen as a significant drawback,
and is comparable to pre-relational systems.
Lack of experience: In comparison to RDBMSs the use of OODBMS is still relatively limited. This
means that we do not yet have the level of experience that we have with traditional systems.
OODBMSs are still very much geared towards the programmer, rather than the nave end-user. Also
there is a resistance to the acceptance of the technology. While the OODBMS is limited to a small
niche market, this problem will continue to exist

Lack of standards: There is a general lack of standards of OODBMSs. We have already mentioned
that there is not universally agreed data model. Similarly, there is no standard object-oriented
query language.
Competition: Perhaps one of the most significant issues that face OODBMS vendors is the
competition posed by the RDBMS and the emerging ORDBMS products. These products have an
established user base with significant experience available. SQL is an approved standard and the
relational data model has a solid theoretical formation and relational products have many
supporting tools to help .both end-users and developers.
Query optimization compromises encapsulations: Query optimization requires. An
understanding of the underlying implementation to access the database efficiently. However, this
compromises the concept of incrassation.
Locking at object level may impact performance Many OODBMSs use locking as the basis for
concurrency control protocol. However, if locking is applied at the object level, locking of an
inheritance hierarchy may be problematic, as well as impacting performance.
Complexity: The increased functionality provided by the OODBMS (such as the illusion of a singlelevel storage model, pointer sizzling, long-durations transactions, version management, and
schema evolution--makes the system more complex than that of traditional DBMSs. In complexity
leads to products that are more expensive and more difficult to use.
Lack of support for views: Currently, most OODBMSs do not provide a view mechanism, which,
as we have seen previously, provides many advantages such as data independence, security,
reduced complexity, and customization.
Lack of support for security: Currently, OODBMSs do not provide adequate security
mechanisms. The user cannot grant access rights on individual objects or classes.
If OODBMSs are to expand fully into the business field, these deficiencies must be rectified.