Course Name: Database Management Systems

Course Code: UE19CS301

Unit : 1
1.Give examples of systems in which it may make sense to use traditional file
processing instead of a database approach?
Answer :
1.Small internal utility to locate files
2. Small single user application that does not require security (such as a
customized calculator or a personal address and phone book)
3. Real-time navigation system (with heavy computation and very little
data)
4. The students may think of others.

2.Define the following terms: data, database, DBMS, database system.

Answer :
Data: Known facts that can be recorded and have an implicit meaning.
Database: A database is an organized collection of structured information, or
data, typically stored electronically in a computer system
DBMS: A software package/ system to facilitate the creation and maintenance
of a computerized database.
database system: The DBMS software together with the data itself. Sometimes,
the applications are also included.
3. Explain Program-data independence, user view, DBA, end user, persistent
object, meta-data.

program-data independence: Data independence is the ability of to make

changes to data characteristics without have to make changes to the programs
that access the data.
user view: A view of part or all of the contents of a database specified to
facilitate a particular purpose or user activity. It is a partial and/or redefined
description of the logical schema of the database.
DBA: A Database Administrator (DBA) is individual or person responsible for
controlling, maintenance, coordinating, and operation of database
management system
end user: End users are the people whose jobs require access to a database for
querying, updating and generating reports.
persistent object: A persistent object is an object that has been assigned a
storage location in a database. When you commit the transaction in which you
create a persistent object, that object's data is saved in the database;
the object can then be accessed by other processes
meta-data: Metadata in DBMS refers to the information that describes the
schema and other information related to the stored data in the database,
including storage, programs, data elements, usage, and additional related
information.

4.Explain when not to use DBMS?

Answer :
In following situation, the DBMS may not be useful:
1. If the database and applications are simple, well defined, and not
expected to change.
2. If there are stringent real-time requirements that may not be met because
of DBMS overhead.
3. If access to data by multiple users is not required.

5.Explain with an example what is schema, instance and database state?

Answer :
The description of a database is called the database schema, which is specified
during database design and is not expected to change frequently
the diagram displays the structure of each record type but not the actual
instances of records. A schema diagram displays only some aspects of a schema,
such as the names of record types and data items, and some types of
constraints. Other aspects like data type of each data item nor the relationships
among the various files. Many types of constraints are not represented in
schema diagrams. A constraint such as students majoring in computer science
must take CS1310 before the end of their sophomore year is quite difficult to
represent diagrammatically.
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. In a given database state, each schema construct has its own
current set of instances; for example, the STUDENT construct will contain the
set of individual student entities (records) as its instances. Many database states
can be constructed to correspond to a particular database schema. Every time
we insert or delete a record or change the value of a data item in a record, we
change one state of the database into another state.
The distinction between database schema and database state is very important.
When we define a new database, we specify its database schema only to the
DBMS. At this point, the corresponding database state is the empty state with
no data. We get the initial state of the database when the database is first
populated or loaded with the initial data. From then on, every time an update
operation is applied to the database, we get another database state. At any
point in time, the database has a current state. The DBMS is partly responsible
for ensuring that every state of the database is a valid state—that is, a state that
satisfies the structure and constraints specified in the schema. Hence, specifying
a correct schema to the DBMS is extremely important and the schema must be
designed with utmost care. The DBMS stores the descriptions of the schema
constructs and constraints—also called the meta-data—in the DBMS catalog so
that DBMS software can refer to the schema whenever it needs to. The schema
is sometimes called the intension, and a database state is called an extension of
the schema.
The data stored in database at a particular moment of time is
called instance of database. Database schema defines the variable declarations
in tables that belong to a particular database; the value of these variables at a
moment of time is called the instance of that database.
6.Discuss the capabilities that should be provided by a DBMS.
New functionality is being added to DBMSs in the following areas:
•Scientific Applications – Physics, Chemistry, Biology - Genetics
•Earth and Atmospheric Sciences and Astronomy
•XML (eXtensible Markup Language)
•Image Storage and Management
•Audio and Video Data Management
•Data Warehousing and Data Mining – a very major area for future development
using new technologies
•Spatial Data Management and Location Based Services
•Time Series and Historical Data Management
The above gives rise to new research and development in incorporating new
data types, complex data structures, new operations and storage and
indexing schemes in database systems.
•Social Media platforms such as Facebook and Twitter are generating
millions of transactions a day and businesses are interested to tap into this
data to “understand” the users
•
•Cloud Storage and Backup is making unlimited amount of storage available
to users and applications
•New data storage, management and analysis technology was necessary to
deal with the commonly called as “Big Data”. onslaught of data in petabytes
 a day (10**15 bytes or 1000 terabytes) in some applications – this started
being
•Hadoop (which originated from Yahoo) and Mapreduce Programming
approach to distributed data processing (which originated from Google) as
well as the Google file system have given rise to Big Data technologies.
Further enhancements are taking place in the form of Spark based
technology.
•NOSQL (Not Only SQL- where SQL is the de facto standard language for
relational DBMSs) systems have been designed for rapid search and retrieval
from documents, processing of huge graphs occurring on social networks,
and other forms of unstructured data with flexible models of transaction
processing.

7. Explain data model, structure and constraints.

•Data Model:
•A set of concepts to
•describe the structure of a database,
•the operations for manipulating these structures,
• and certain constraints that the database should obey.
•Data Model Structure and Constraints:
•Constructs are used to define the database structure
•Constructs typically include elements (and their data types) as well as
groups of elements (e.g. entity, record, table), and relationships among
such groups
•Constraints specify some restrictions on valid data; these constraints
must be enforced at all times

8. Discuss the main categories of data models

•Conceptual (high-level, semantic) data models:
•Provide concepts that are close to the way many users perceive data.
•(Also called entity-based or object-based data models.)
•Physical (low-level, internal) data models:
•Provide concepts that describe details of how data is stored in the
computer. These are usually specified in an ad-hoc manner through DBMS
design and administration manuals
•Implementation (representational) data models:
 •Provide concepts that fall between the above two, used by many
commercial DBMS implementations (e.g. relational data models used in
many commercial systems).
•Self-Describing Data Models:
•Combine the description of data with the data values. Examples include
XML, key-value stores and some NOSQL systems.

9.Define the following terms: relation schema, relational database schema,

domain, relation instance, relation cardinality, and relation degree.

Answer A relation schema can be thought of as the basic information describing

a table or relation. This includes a set of column names, the data types
associated with each column, and the name associated with the entire table.
For example, a relation schema for the relation called Students could be
expressed using the following representation:
Students(sid: string, name: string, login: string, age: integer, gpa: real)
There are five fields or columns, with names and types as shown above.
A relational database schema is a collection of relation schemas, describing one
or more relations.
Domain is synonymous with data type.
Attributes can be thought of as columns in a table.
Therefore, an attribute domain refers to the data type associated with a column.
A relation instance is a set of tuples (also known as rows or records) that each
conform to the schema of the relation.
The relation cardinality is the number of tuples in the relation.
The relation degree is the number of fields (or columns) in the relation.

10.What is a relationship type? Explain the differences among a relationship

instance, a relationship type, and a relationship set.
Answer :
Relationship type is the nature of a relationship between entities, expressed
by the number of their possible occurrences in the related tables.

The differences between a relationship instance, a relationship type, and a

relationship set are:
1.Relationship instance is an association of entities, where the association
includes exactly one entity from each participating entity type.
2.Relationship type defines a relationship set among entities from these
types.
3.Relationship set is a set of associations.

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.
Mathematically, the relationship set R is a set of relationship instances ri, where
each ri associates n individual entities (e1, e2, . . . , en), and each entity ej in ri is
a member of entity set Ej , 1 ≤ j ≤ n. each of the individual entities e1, e2, . . . ,
en is said to participate in the relationship instance ri = (e1, e2, . . . , en).

Informally, each relationship instance ri in R is an association of entities, where

the association includes exactly one entity from each participating entity type.
Each such relationship instance ri represents the fact that the entities
participating in ri are related in some way in the corresponding mini world
situation.

For example, consider a relationship type WORKS_FOR between the two entity
types EMPLOYEE and DEPARTMENT, which associates each employee with the
department for which the employee works. Each relationship instance in the
relationship set WORKS_FOR associates one EMPLOYEE entity and one
DEPARTMENT entity. Figure 3.9 illustrates this example, where each relationship
instance ri is shown connected to the EMPLOYEE and DEPARTMENT entities that
participate in ri. In the mini world represented by Figure 3.9, the employees e1,
e3, and e6 work for department d1; the employees e2 and e4 work for
department d2; and the employees e5 and e7 work for department d3.

11 .Describe the two alternatives for specifying structural constraints on

relationship types. What are the advantages and disadvantages of each?
Answer :
Two alternatives for specifying structural constraints on relationship types are
cardinality ratio and participation. Cardinality ratio for a binary relationship
specifies the number of relationship instances that an entity can participate in.
The participation constraint specifies whether the existence of an entity
depends on its being related to another entity via the relationship type

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. For example, in the WORKS_FOR binary relationship
type, DEPARTMENT: EMPLOYEE is of cardinality ratio 1:N, meaning that each
department can be related to (that is, employs) any number of employees (N),9
but an employee can be related to (work for) at most one department (1). This
means that for this particular relationship type WORKS_FOR, a particular
department entity can be related to any number of employees (N indicates there
is no maximum number). On the other hand, an employee can be related to a
maximum of one department. The possible cardinality ratios for binary
relationship types are 1:1, 1:N, N:1, and M:N.
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.
Let’s consider company database 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. 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.

12. A database is being constructed to keep track of the teams and games of a
sports league. A team has a number of players, not all of whom participate in
each game. It is desired to keep track of the players participating in each game
for each team, the positions they played in that game, and the result of the
game. Design an ER schema diagram for this application, stating any
assumptions you make. Clearly indicate the cardinality mappings,
participation constraints in your ER diagram. Choose your favourite sport
(e.g., soccer, baseball, football).

Answer :
Assumptions: Each game in the schedule is identified by a unique Game#, and a
game is also identified uniquely by the combination of Date, starting Time, and
Field where it is played. A performance attribute is used to store information on
the individual batting performance of each player in a game. The following
design may be used for a baseball league. Here, we assumed that each game in
the schedule is identified by a unique Game#, and a game is also identified
uniquely by the combination of Date, starting Time, and Field where it is played.
The Performance attribute of PARTICIPATE is used to store information on the
individual performance of each player in a game

13.Discuss the role of a high-level data model in the database design process
Answer:
In the database design process first, we need to collect requirements of the
system and conduct analysis of these requirements. Once the requirements re
validated by customer we can go for software design process and database
design process.
In database design process, we start with conceptual schema for the database,
using a high-level conceptual data model. This step is called conceptual design.
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; these are expressed using the concepts provided by the high-level
data model. Because these concepts do not include implementation details,
they are usually easier to understand and can be used to communicate with
nontechnical users. The high-level conceptual schema can also be used as a
reference to ensure that all users’ data requirements are met and that the
requirements do not conflict. This approach enables database designers to
concentrate on specifying the properties of the data, without being concerned
with storage and implementation details, which makes it is easier to create a
good conceptual database design.
During or after the conceptual schema design, the basic data model operations
can be used to specify the high-level user queries and operations identified
during functional analysis. This also serves to confirm that the conceptual
schema meets all the identified functional requirements. Modifications to the
conceptual schema can be introduced if some functional requirements cannot
be specified using the initial schema
The next step in database design is the actual implementation of the database,
using a commercial DBMS. Most current commercial DBMSs use an
implementation data model—such as the relational (SQL) model—so the
conceptual schema is transformed from the high-level data model into the
implementation data model. This step is called logical design or data model
mapping; its result is a database schema in the implementation data model of
the DBMS. Data model mapping is often automated or semiautomated within
the database design tools.
The last step is the physical design phase, during which the internal storage
structures, file organizations, indexes, access paths, and physical design
parameters for the database files are specified. In parallel with these activities,
application programs are designed and implemented as database transactions
corresponding to the high-level transaction specifications.

14: Difference between a Database schema and Database Instance/ Database

State.
•Database Schema:
•The description of a database.
•Includes descriptions of the database structure, data types, and the
constraints on the database.

•Database State:
 •The actual data stored in a database at a particular moment in time. This
includes the collection of all the data in the database.
•Also called database instance (or occurrence or snapshot).
•The term instance is also applied to individual database components,
e.g. record instance, table instance, entity instance

•The database schema changes very infrequently.

•The database state changes every time the database is updated.

15. Mention the different Database states.

•Database State:
•Refers to the content of a database at a moment in time.

•Empty State:
•Refers to empty database when the database is first defined.
•Initial Database State:
•Refers to the database state when it is initially loaded into the system.
•Valid State:
A state that satisfies the structure and constraints of the database.

16. What are the advantages of 3-schema architecture?

•Self-describing nature
•Program-data independence.
•Support of multiple views of the data.

17. Explain 3-schema architecture.

•Defines DBMS schemas at three levels:
•Internal schema at the internal level to describe physical storage structures and
access paths (e.g indexes).
•Typically uses a physical data model.
•Conceptual schema at the conceptual level to describe the structure and
constraints for the whole database for a community of users.
•Uses a conceptual or an implementation data model.
•External schemas at the external level to describe the various user views.
•Usually uses the same data model as the conceptual schema.

18. What is data independence and mention its different types.

Data Independence is defined as a property of DBMS that helps you to change
the Database schema at one level of a database system without requiring to
change the schema at the next higher level. Data independence helps you to
keep data separated from all programs that make use of it. You can use this
stored data for computing and presentation.
•Logical Data Independence:
•The capacity to change the conceptual schema without having to change
the external schemas and their associated application programs.
•Physical Data Independence:
•The capacity to change the internal schema without having to change
the conceptual schema.
•For example, the internal schema may be changed when certain file
structures are reorganized or new indexes are created to improve database
performance
•When a schema at a lower level is changed, only the mappings between this
schema and higher-level schemas need to be changed in a DBMS that fully
supports data independence.
•The higher-level schemas themselves are unchanged.
•Hence, the application programs need not be changed since they refer to the
external schemas.

19. What are the different types of DBMS languages.

•Data Definition Language (DDL)
••Used by the DBA and database designers to specify the conceptual
schema of a database.
•In many DBMSs, the DDL is also used to define internal and external
schemas (views).
•In some DBMSs, separate storage definition language (SDL) and view
definition language (VDL) are used to define internal and external
schemas.
•SDL is typically realized via DBMS commands provided to the DBA and
database designers

•Data Manipulation Language (DML)

•High-Level or Non-procedural Languages: These include the relational
language SQL
•May be used in a standalone way or may be embedded in a programming
language
•Low Level or Procedural Languages:
•These must be embedded in a programming language

20. What are the different types of Data Manipulation Languages.

•High Level or Non-procedural Language:
•For example, the SQL relational language
•Are “set”-oriented and specify what data to retrieve rather than how to
retrieve it.
•Also called declarative languages.
•
•Low Level or Procedural Language:
 •Retrieve data one record-at-a-time;
•Constructs such as looping are needed to retrieve multiple records,
along with positioning pointers.

21. Explain the different types of interfaces available for DBMS.

•Stand-alone query language interfaces
•Example: Entering SQL queries at the DBMS interactive SQL interface
(e.g. SQL*Plus in ORACLE)

•Programmer interfaces for embedding DML in programming languages

•User-friendly interfaces
•Menu-based, forms-based, graphics-based, etc.
•Mobile Interfaces:interfaces allowing users to perform transactions using
mobile apps

•Natural language: free text as a query

•Speech : Input query and Output response
•Web Browser with keyword search
•Parametric interfaces, e.g., bank tellers using function keys.
•Interfaces for the DBA:
•Creating user accounts, granting authorizations
•Setting system parameters
•Changing schemas or access paths

22. What are the different types of Programmer interfaces for embedding DML
in a programming languages

•Embedded Approach: e.g embedded SQL (for C, C++, etc.), SQLJ (for Java)
•Procedure Call Approach: e.g. JDBC for Java, ODBC (Open Database
Connectivity) for other programming languages as API’s (application
programming interfaces)

•Database Programming Language Approach: e.g. ORACLE has PL/SQL, a

programming language based on SQL; language incorporates SQL and its data
types as integral components
•Scripting Languages: PHP (client-side scripting) and Python (server-side
scripting) are used to write database programs.

22. What are the different types of User-Friendly DBMS Interfaces

•Menu-based (Web-based), popular for browsing on the web

•Forms-based, designed for naïve users used to filling in entries on a form
•Graphics-based
•Point and Click, Drag and Drop, etc.
•Specifying a query on a schema diagram
•Combinations of the above:
•For example, both menus and forms used extensively in Web database
interfaces

23) What is the difference between Centralized and Client-Server DBMS

Architectures .
•Centralized DBMS:
•Combines everything into single system including- DBMS software,
hardware, application programs, and user interface processing
software.
•User can still connect through a remote terminal – however, all
processing is done at centralized site.

Client-Server Architectures:

•Print server
•File server
•DBMS server
•Web server
•Email server
•Clients can access the specialized servers as needed
•Client and server must install appropriate client module and server module
software for ODBC or JDBC
•A client program may connect to several DBMSs, sometimes called the data
sources.
•In general, data sources can be files or other non-DBMS software that manages
data.

24) Explain Three-tier client-server architecture

•Common for Web applications

•Intermediate Layer called Application Server or Web Server:

•Stores the web connectivity software and the business logic part of the
application used to access the corresponding data from the database server
•Acts like a conduit for sending partially processed data between the database
server and the client.
•Three-tier Architecture Can Enhance Security:
•Database server only accessible via middle tier
•Clients cannot directly access database server
•Clients contain user interfaces and Web browsers
•The client is typically a PC or a mobile device connected to the Web

25) What are the data models that exists in DBMS.

•Network Model
•Hierarchical Model
•Relational Model
•Object-oriented Data Models
•Object-Relational Models

26) Discuss relational Model.

•Relational Model:
•Proposed in 1970 by E.F. Codd (IBM), first commercial system in 1981-82.
•Now in several commercial products (e.g. DB2, ORACLE, MS SQL Server,
SYBASE, INFORMIX).
•Several free open source implementations, e.g. MySQL, PostgreSQL
•Currently most dominant for developing database applications.
•SQL relational standards: SQL-89 (SQL1), SQL-92 (SQL2), SQL-99, SQL3, …

27) Explain in detail the Database design process.

The above figure shows a simplified overview of the database design process.
The first step shown is requirements collection and analysis. During this step,
the database designers interview prospective database users to understand and
document their data requirements. The result of this step is a concisely written
set of users’ requirements. These requirements should be specified in as
detailed and complete a form as possible. In parallel with specifying the data
requirements, it is useful to specify the known functional requirements of the
application. These consist of the user defined operations (or transactions) that
will be applied to the database, including both retrievals and updates. In
software design, it is common to use data flow diagrams, sequence diagrams,
scenarios, and other techniques to specify functional requirements. We will not
discuss any of these techniques here; they are usually described in detail in
software engineering texts. Once the requirements have been collected and
analyzed, the next step is to create a conceptual schema for the database, using
a high-level conceptual data model. This step is called conceptual design.
During or after the conceptual schema design, the basic data model operations
can be used to specify the high-level user queries and operations identified
during functional analysis. The next step in database design is the actual
implementation of the database, using a commercial DBMS. Most current
commercial DBMSs use an implementation data model—such as the relational
(SQL) model—so the conceptual schema is transformed from the high-level data
model into the implementation data model. This step is called logical design or
data model mapping; its result is a database schema in the implementation data
model of the DBMS. Data model mapping is often automated or semiautomated
within the database design tools. The last step is the physical design phase,
during which the internal storage structures, file organizations, indexes, access
paths, and physical design parameters for the database files are specified. In
parallel with these activities, application programs are designed and
implemented as database transactions corresponding to the high-level
transaction specifications.

28) What are entities and Attributes.

•Entity is a basic concept for the ER model. Entities are specific things or objects
in the mini-world that are represented in the database.
•For example the EMPLOYEE John Smith, the Research DEPARTMENT, the
ProductX PROJECT
•Attributes are properties used to describe an entity.
•For example an EMPLOYEE entity may have the attributes Name, SSN, Address,
Gender, BirthDate
•A specific entity will have a value for each of its attributes.
•For example a specific employee entity may have Name='John Smith',
SSN='123456789', Address ='731, Fondren, Houston, TX', Gender='M',
BirthDate='09-JAN-55‘
•Each attribute has a value set (or data type) associated with it – e.g. integer,
string, date, enumerated type, …

29) what are the different types of attributes.

•Simple
•Each entity has a single atomic value for the attribute. For example, SSN or
Gender.
•Composite
•The attribute may be composed of several components. For example:
•Address(Apt#, House#, Street, City, State, ZipCode, Country), or
•Name(FirstName, MiddleName, LastName).
•Composition may form a hierarchy where some components are themselves
composite.
•Multi-valued
•An entity may have multiple values for that attribute. For example, Color of a
CAR or PreviousDegrees of a STUDENT.
•Denoted as {Color} or {PreviousDegrees}.
•Stored and Derived
Eg: DOB and AGE respectively.

30) With example explain Recursive Relationship.

•A relationship type between the same participating entity type in distinct roles
•Also called a self-referencing relationship type.
•Example: the SUPERVISION relationship
•EMPLOYEE participates twice in two distinct roles:
•supervisor (or boss) role
•supervisee (or subordinate) role
•Each relationship instance relates two distinct EMPLOYEE entities:
•One employee in supervisor role
•One employee in supervisee role
•In a recursive relationship type.
•Both participations are same entity type in different roles.
•For example, SUPERVISION relationships between EMPLOYEE (in role of
supervisor or boss) and (another) EMPLOYEE (in role of subordinate or worker).
•In following figure, first role participation labeled with 1 and second role
participation labeled with 2.
•In ER diagram, need to display role names to distinguish participations.