What is data abstraction ? Explain different levels of data abstraction?

Ans :-

Database systems are made-up of complex data structures. To ease the user
interaction with database, the developers hide internal irrelevant details from
users. This process of hiding irrelevant details from user is called data
abstraction.

Levels of Abstraction
 Physical level: describes how a record (e.g., customer) is stored.
 Logical level: describes data stored in database, and the relationships
among the data.
type customer = record
customer_id : string;
customer_name : string;
customer_street : string;
customer_city : string;
end;
 View level: application programs hide details of data types. Views can
also hide information (such as an employee’s salary) for security
purposes.

Database System Concepts - 5th Edition, May 23, 2005 1.6 ©Silberschatz, Korth and Sudarshan
 View of Data

An architecture for a database system

Database System Concepts - 5th Edition, May 23, 2005 1.7 ©Silberschatz, Korth and Sudarshan

What do you mean by Data modelling ? Discuss different types of data modelling.?

Ans :-

Database design is defined as: "design the logical and physical structure of one or more databases to
accommodate the information needs of the users in an organization for a defined set of applications".
The design process roughly follows five steps:
1. Planning and analysis
2. Conceptual design
3. Logical design
4. Physical design
5. Implementation

The data model is one part of the conceptual design process. The other, typically is the functional
model. The data model focuses on what data should be stored in the database while the functional
model deals with how the data is processed. To put this in the context of the relational database,
the data model is used to design the relational tables. The functional model is used to design the
queries which will access and perform operations on those tables.
Data Model
A data model is a collection of conceptual tools for describing data, data relationships,
data semantics, and consistency constraints.
Some of the most popular data models are explained below:

1. Entity Relationship Model (ER)

2. Relational Model
3. Object-oriented Data Model
4. Object-relational Data Model

Relational Model
Attributes
 Example of tabular data in the relational model

Database System Concepts - 5th Edition, May 23, 2005 1.12 ©Silberschatz, Korth and Sudarshan
 The Entity-Relationship Model
 Models an enterprise as a collection of entities and relationships
 Entity: a “thing” or “object” in the enterprise that is distinguishable
from other objects
 Described by a set of attributes
 Relationship: an association among several entities
 Represented diagrammatically by an entity-relationship diagram:

Database System Concepts - 5th Edition, May 23, 2005 1.16 ©Silberschatz, Korth and Sudarshan

Object-oriented Data Model

 The object-oriented data model is based on the Object-oriented paradigm

introduced for database management.
 This model extends the representation of entities by adding notions like
Inheritance, Encapsulation, Methods (functions), and Object identity. These key
concepts of object-oriented programming have found application in data
modeling.
 The object-oriented data model also supports a rich type system, including
structured, collection types and complex types.

Object-relational Data Model

 Object-Relational Data Models
 Extend the relational data model by including object orientation and
constructs to deal with added data types.
 Allow attributes of tuples to have complex types, including non-atomic
values such as nested relations.
 Preserve relational foundations, in particular the declarative access to
data, while extending modeling power.
 Provide upward compatibility with existing relational languages.

 Database System Concepts - 5th Edition, May 23, 2005 1.31

Thus, Object-
©Silberschatz, Korth and Sudarshan

relational database systems provide a convenient migration path for users of

relational databases who wish to use object-oriented features

List Significant difference between file processing system and DBMS.?

File Processing System Database Management System

On the other hand, a file system is a A database is generally used for storing related,
more unstructured data store for storing structured data, with well defined data formats, in an
arbitrary, probably unrelated data. efficient manner for insert, update and/or retrieval.

A file system provides much looser While databases are consistent at any instant in
guarantees about consistency, isolation time,provide,isolated transactions and durable writes,
and durability.

A file-processing system coordinates A database management system coordinates both the

only the physical access to the data. physical and the logical access to the data
File Processing System Database Management System

A file-processing system is designed to A database management system is designed to allow

allow predetermined access to data (i.e. flexible access to data (i.e. queries)
compiled programs)

Unauthorized access cannot be Unauthorized access is restricted in DBMS

restricted in DBMS

Redundancy cannot be controlled in File Redundancy can be controlled in File processing

processing system. system.

Explain various function of database administrator .?

1.11.2 Database Administrator

One of the main reasons for using DBMSs is to have central control of both the data and the
programs that access those data. A person who has such central control over the system is called a
database administrator (DBA). The functions of a DBA include:
Schema definition. The DBA creates the original database schema by executing a set of data
definition statements in the DDL.
Storage structure and access-method definition.
Schema and physical-organization modification. The DBA carries out changes to the schema and
physical organization to reflect the changing needs of the organization, or to alter the physical
organization to improve performance.
Granting of authorization for data access. By granting different types of authorization, the
database administrator can regulate which parts of the database various users can access. The
authorization information is kept in a special system structure that the database system consults
whenever someone attempts to access the data in the system.
Routine maintenance. Examples of the database administrator’s routine maintenance activities are:
Periodically backing up the database, either onto tapes or onto remote servers, to prevent loss of data
in case of disasters such as flooding.
Ensuring that enough free disk space is available for normal operations, and upgrading disk space as
required.
Monitoring jobs running on the database and ensuring that performance is not degraded by very
expensive tasks submitted by some users.

Write short note on data independance & list types ?

Data Independence
 Data independence is a form of database management that keeps data
separated from all programs that make use of it.
 As a cornerstone for the idea of a DBMS or database management system, this
independence ensures that the data cannot be redefined or reorganized by any
of the programs that make use of it.
 In this manner, the data remains accessible, but it is also stable and cannot be
corrupted by the applications.
 Within the environment of a centralized DBMS, database management relies on
the process of data independence.
 While data transparency still exists as far as the ability of different applications to
access and use the data for completing tasks, no program or application can
read and then begin to make changes to the data itself.
 The consistency of the information makes the overall process of maintaining and
managing a single database or multiple databases within a single environment
much easier.
 One of the functions of data independence is to restrict access to the storage
structure of the data by the user applications.
 By effectively hiding the specifics of the structure from the applications, the
potential for any one application to alter the nature of the data becomes
impossible. As a result, the essential data retains its integrity and remains
consistent no matter how many databases or database applications access it.

1. Logical data independence is the capacity to change the conceptual schema without having to
change external schemas or application programs. We may change the conceptual schema to
expand the database (by adding a record type or data item), or to reduce the database (by
removing a record type or data item). In the latter case, external schemas that refer only to the
remaining data should not be affected. Only the view definition and the mappings need be
changed in a DBMS that supports logical data independence. Application programs that reference
the external schema constructs must work as before, after the conceptual schema undergoes a
logical reorganization. Changes to constraints can be applied also to the conceptual schema
without affecting the external schemas or application programs.

2. Physical data independence is the capacity to change the internal schema without having to
change the conceptual (or external) schemas. Changes to the internal schema may be needed
because some physical files had to be reorganized—for example, by creating additional access
structures—to improve the performance of retrieval or update. If the same data as before remains
in the database, we should not have to change the conceptual schema.
Whenever we have a multiple-level DBMS, its catalog must be expanded to include information
on how to map requests and data among the various levels. The DBMS uses additional software
to accomplish these mappings by referring to the mapping information in the catalog. Data
independence is accomplished because, when the schema is changed at some level, the schema at
the next higher level remains unchanged; only the mapping between the two levels is changed.
Hence, application programs referring to the higher-level schema need not be changed.
 The three-schema architecture can make it easier to achieve true data independence, both
physical and logical. However, the two levels of mappings create an overhead during
compilation or execution of a query or program, leading to inefficiencies in the DBMS. Because
of this, few DBMSs have implemented the full three-schema architecture.

Design an ER diagram for banking enterprise and convert it into relational model ?

ER Diagram:

Relational Model:
Entities
Discuss different types of attributes with suitable example ?
What is an Attribute and it’s types with Examples: Generally attribute
constitutes a character and explains the characteristics of an entity. In database
management system (DBMS) it assigns a database component or database field.
Attribute stores or saves only a piece of data. For example, in an invoice the attribute
may be the price or date. In this article, we will discuss the various types of attributes
with examples.
Also See: What is Database Management System

What is an Attribute and it’s types with

Examples
Another example: consider the entity student and it has the attribute like student-
Lname, student- Fname, student-Email, student-phone and many. This entity can be
represented in two models, they are

 Chen model
 Crow’s foot model

In Chen model, attributes are represented by ovals and where as the entity is by a
rectangle. These two are connected to each other by a line.

Chen
Model
In Crow’s foot model, attributes are portrayed in a rectangle box; below the entity box.

Crow Model
Types of Attributes with Examples
The different types of attributes are as follows

 Single valued attributes

 Multi valued attributes
 Compound /Composite attributes
 Simple / Atomic attributes
 Stored attributes
 Derived attributes
 Complex attributes
 Key attributes
 Non key attributes
 Required attributes
 Optional/ null value attributes

The detailed explanation of all the attributes is as follows:

Single Valued Attributes: It is an attribute with only one value.

 Example: Any manufactured product can have only one serial no. , but the single valued
attribute cannot be simple valued attribute because it can be subdivided. Likewise in the
above example the serial no. can be subdivided on the basis of region, part no. etc.

Multi Valued Attributes: These are the attributes which can have multiple values for
a single or same entity.

 Example: Car’s colors can be divided into many colors like for roof, trim.
 The notation for multi valued attribute is:

Fig3: Multi value attribute notation

Compound / Composite attributes: This attribute can be further divided into more
attributes.

 The notation for it is:

 Fig 4: Compound / Composite attribute notation

 Example: Entity Employee Name can be divided into sub divisions like FName, MName,
LName.

Fig 5: Sample of compound / composite attribute

Simple / Atomic Attributes: The attributes which cannot be further divided are
called as simple / atomic attributes.

 Example: The entities like age, marital status cannot be subdivided and are simple
attributes.

Stored Attributes: Attribute that cannot be derived from other attributes are called as
stored attributes.

 Example: Birth date of an employee is a stored attribute.

Derived Attributes: These attributes are derived from other attributes. It can be
derived from multiple attributes and also from a separate table.

 Example: Today’s date and age can be derived. Age can be derived by the difference
between current date and date of birth.
 The notation for the derived attribute is:
 Fig 6: Notation of derived attribute
Complex Attributes: For an entity, if an attribute is made using the multi valued
attributes and composite attributes then it is known as complex attributes.

 Example: A person can have more than one residence; each residence can have more
than one phone.

Key Attributes: This attribute represents the main characteristic of an entity i.e.
primary key. Key attribute has clearly different value for each element in an entity set.

 Example: The entity student ID is a key attribute because no other student will have the
same ID.

Fig 7: Sample of key attribute

Non- Key Attributes: Excluding the candidate key attributes in an entity set are the
non key attributes.

 Example: First name of a student or employee is a non-key attribute as it does not

represent main characteristic of an entity.
 Fig 8: Sample of non-key attribute
Required Attributes: Required attribute must have a data because they describe the
vital part of entity.

 Example: Taking the example of a college, there the student’s name is a vital thing.

Fig 9: sample of required attribute

Optional / Null value Attributes: It does not have a value and can be left blank, it’s
optional can be filled or cannot be.

 Example: Considering the entity student there the student’s middle name and the email
ID is optional.

Fig 10: Sample of optional / null attribute

These are different types of attributes and they all play a vital role in the database
management system. Generally an oval is used to represent an attribute as shown below:

Fig 11: Notation of an attribute

Because of their versatility they have wide applications and there are many models in
which we can the attributes as explained above.
Design an ER diagram for online railway reservation system and convert it into relational
model ?
Step 1: E-R Diagram
Step 2: Converting the E-R Diagram into Tables
a. Converting entity to table and attribute to columns
USER

U_id Primary Key

Password

Security_quest

Passenger
PNR Primary Key

P_name

Age

Gender

Seat_no.

Reserve_status

U_id Foreign key references to U_id of User table.

Status_id Foreign key references to Status_id of Train_Status Table.

Train_id Foreign key references to Train_id of Train Table

Train_Status

Status_id Primary Key

Wait_seat
Status_id Primary Key

Avail_seat

Booked_seat

Train_id Foreign key references to Train_id of Train Table

PNR Foreign key references to PNR of Passenger table.

Train

Train_id Primary Key

T_name

Train_type

Avail_class

Status_id Foreign key references to Status_id of Train_Status Table.

Route
Arr_time

Depart_time

Stop no.

Station_id Foreign key references to Station_id of Station table.

Train_id Foreign key references to Train_id of Train Table

Station

Station_id Primary Key

Station_name

Step 3: Mapping of Attributes

a. Simple Attributes
Simple attributes which cannot be divided into subparts.
Example: Seat Number of passenger
b. Composite Attributes
Composite attributes which can be divided into subparts.
Example: Passenger Name, Reservation status
P_name

First_Name
First_Name

Middle_Name

Last_name

Reserve_status

Waiting

Confirmed

Step 4: Mapping of entity set

a. Weak entity set
For each weak entity type with owner entity, create a table and include all simple
attributes of weak entity type as columns of table, including foreign key attributes as the
primary key of the table that correspond to the owner entity type.(Owner entity is strong
entity having own primary key.)
Example: Route (Weak Entity) in Train (Owner entity).

Step 5: Mapping of Relationships

a. Foreign Key approach
Passenger_Table

U_id Passenger table makes foreign key references to U_id of User table.
U_id Passenger table makes foreign key references to U_id of User table.

Status_id Passenger table makes foreign key references to Status_id of Train_Status Table.

Train_id Passenger table makes foreign key references to Train_id of Train Table

Train_Status

Train_id Train_status table makes foreign key references to Train_id of Train Table

PNR Train_status table makes foreign key references to PNR of Passenger table.

Train

Route

Station_id Route table makes foreign key references to Station_id of Station table.

Train_id Route table makes foreign key references to Train_id of Train Table

Step 6: Identifying the relationships

a. Passenger can book many tickets.
Therefore the relations are 1……..N.
b. Trains are associated with each Train_status
Therefore the relation is M……..1.
c. Trains can route from one route.
Therefore the relations are N……..1.
d. Station has a set of Route.
Therefore the relations are 1……..N.

Explain Generalization and specialization with suitable example ?

Generalization –
Generalization is the process of extracting common properties from a set of entities and
create a generalized entity from it. It is a bottom-up approach in which two or more
entities can be generalized to a higher level entity if they have some attributes in
common. For Example, STUDENT and FACULTY can be generalized to a higher level
entity called PERSON as shown in Figure 1. In this case, common attributes like
P_NAME, P_ADD become part of higher entity (PERSON) and specialized attributes
like S_FEE become part of specialized entity (STUDENT).

Specialization –
In specialization, an entity is divided into sub-entities based on their characteristics. It is
a top-down approach where higher level entity is specialized into two or more lower
level entities. For Example, EMPLOYEE entity in an Employee management system
can be specialized into DEVELOPER, TESTER etc. as shown in Figure 2. In this case,
common attributes like E_NAME, E_SAL etc. become part of higher entity
(EMPLOYEE) and specialized attributes like TES_TYPE become part of specialized
entity (TESTER).

10) Write short note on -> 1) Total Participation 2) Partial Participation 3)Storage Manager and Query
processor. ?

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—that we illustrate by example. If a company
policy states that every employee must work for a department, then an employee
entity can exist only if it participates in at least one WORKS_FOR relationship
instance (Figure 7.9). Thus, the participation of EMPLOYEE in WORKS_FOR is
called total participation, meaning that every entity in the total set of employee
entities must be related to a department entity via WORKS_FOR. Total participation
is also called existence dependency. In Figure 7.12 we do not expect every employee
to 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. We will
refer to the cardinality ratio and participation constraints, taken together, as the
structural constraints of a relationship type.
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 (see Figure 7.2). Notice that in this
notation, we can either specify no minimum (partial participation) or a minimum
of one (total participation). The alternative notation (see Section 7.7.4) allows the
designer to specify a specific minimum number on participation in the relationship,
such as 4 or 5.

11) Explain Following Relational algebra operation

a) Natural Join b) Assignment c) Generalized Projection d) Set Intersection ?

6.4.1 Generalized Projection

The generalized projection operation extends the projection operation by allowing
functions of attributes to be included in the projection list. The generalized form
can be expressed as:
F1, F2, ..., Fn (R)

where F1, F2, ..., Fn are functions over the attributes in relation R and may involve
arithmetic operations and constant values. This operation is helpful when developing
reports where computed values have to be produced in the columns of a query
result.
As an example, consider the relation
EMPLOYEE (Ssn, Salary, Deduction, Years_service)
A report may be required to show
Net Salary = Salary – Deduction,
Bonus = 2000 * Years_service, and
Tax = 0.25 * Salary.
Then a generalized projection combined with renaming may be used as follows:
REPORT (Ssn, Net_salary, Bonus, Tax)(Ssn, Salary – Deduction, 2000 * Years_service,
0.25 * Salary(EMPLOYEE)

6.3.2 Variations of JOIN: The EQUIJOIN

and NATURAL JOIN
The most common use of JOIN involves join conditions with equality comparisons
only. Such a JOIN, where the only comparison operator used is =, is called an
EQUIJOIN. Both previous examples were EQUIJOINs. Notice that in the result of an
EQUIJOIN we always have one or more pairs of attributes that have identical values
in every tuple. For example, in Figure 6.6, the values of the attributes Mgr_ssn and
Ssn are identical in every tuple of DEPT_MGR (the EQUIJOIN result) because the
equality join condition specified on these two attributes requires the values to be
identical in every tuple in the result. Because one of each pair of attributes with
identical values is superfluous, a new operation called NATURAL JOIN—denoted by
*—was created to get rid of the second (superfluous) attribute in an EQUIJOIN condition.
6 The standard definition of NATURAL JOIN requires that the two join attributes
(or each pair of join attributes) have the same name in both relations. If this is
not the case, a renaming operation is applied first.
Suppose we want to combine each PROJECT tuple with the DEPARTMENT tuple that
controls the project. In the following example, first we rename the Dnumber attribute
of DEPARTMENT to Dnum—so that it has the same name as the Dnum attribute in
PROJECT—and then we apply NATURAL JOIN:
PROJ_DEPT PROJECT * (Dname, Dnum, Mgr_ssn, Mgr_start_date)(DEPARTMENT)
The same query can be done in two steps by creating an intermediate table DEPT as
follows:
DEPT (Dname, Dnum, Mgr_ssn, Mgr_start_date)(DEPARTMENT)
PROJ_DEPT PROJECT * DEPT
The attribute Dnum is called the join attribute for the NATURAL JOIN operation,
because it is the only attribute with the same name in both relations. The resulting
relation is illustrated in Figure 6.7(a). In the PROJ_DEPT relation, each tuple combines
a PROJECT tuple with the DEPARTMENT tuple for the department that controls
the project, but only one join attribute value is kept.
If the attributes on which the natural join is specified already have the same names in
both relations, renaming is unnecessary. For example, to apply a natural join on the
Dnumber attributes of DEPARTMENT and DEPT_LOCATIONS, it is sufficient to write
DEPT_LOCS DEPARTMENT * DEPT_LOCATIONS
The resulting relation is shown in Figure 6.7(b), which combines each department
with its locations and has one tuple for each location. In general, the join condition
for NATURAL JOIN is constructed by equating each pair of join attributes that have
the same name in the two relations and combining these conditions with AND.
There can be a list of join attributes from each relation, and each corresponding pair
must have the same name.

What are the advantages of relational model ?

The relational database model was first introduced by E.F. Codd of IBM in 1969. In the
relational model, data are structured into tables (i.e., "relations") consisting of rows and
columns. Each row contains a single record comprised of individual data elements (or
"attributes") organized in columns containing elements of the same kind according to the rules
defined for that column. Alternate database models include the network, hierarchical, flat file,
and object-oriented models.

Simplicity

The relational model structures data in a manner that avoids complexity. The table
structure is an intuitive organization familiar to most users, particularly those who have
worked with physical or software spreadsheets, check registers or other tabular data.
Data are organized naturally within the model, simplifying the development and use of
the database.
Ease of Data Retrieval

Under the relational model, accessing data in a database does not require navigating a
rigid pathway through a tree or hierarchy. Users can query any table in the database,
and combine related tables using special join functions to include relevant data
contained in other tables in the results. Results can be filtered based on the content of
any column, and on any number of columns, allowing users to easily retrieve
meaningful results. Users can choose which columns to include in the results so that
only relevant data are displayed.

Data Integrity

Data integrity is an essential feature of the relational model. Strong data typing and
validity checks ensure data fall within acceptable ranges, and required data are present.
Referential integrity among tables prevents records from becoming incomplete or
orphaned. Data integrity helps to ensure accuracy and consistency of the data.

Flexibility

The relational database model is naturally scalable and extensible, providing a flexible
structure to meet changing requirements and increasing amounts of data. The relational
model permits changes to a database structure to be implemented easily without
impacting the data or the rest of the database. The database analyst can quickly and
easily add, remove, and modify tables and columns in an existing database to meet
business requirements. There is theoretically no limit on the number of rows, columns or
tables. In reality, growth and change are limited by the relational database management
system and physical computing hardware, and changes may impact external
applications designed for a specific database structure.
Normalization

A systematic methodology exists for ensuring a relational database design is free of

anomalies that may impact the integrity and accuracy of the database. "Database
normalization" provides a set of rules, qualities and objectives for the design and review
of a database structure. Normalization objectives are described in levels called "normal
forms." Each level of normalization must be completed before progressing to the next
level. A database design is generally considered normalized when it meets the
requirements of the third normal form. Normalization provides designers with confidence
the database design is robust and dependable.

Design Extended ER diagram for Banking database system ?

What are various types of Keys ? Explain with suitable example.?