DATABASE MANAGEMENT SYSTEM ,DEC 2010 ANSWER BANK 1

DATABASE MANAGEMENT SYSTEM ,DEC 2010 ANSWER BANK 1

Prof. Sushant S.Sundikar DBMS Answer Bank , Dec 2010 Exam

1A. Discuss the main characteristics of the database approach and how it differs from traditional file

system.

The main characteristics of the database approach versus the file-processing approach are the following:

• Self-describing nature of a database system

• Insulation between programs and data, and data abstraction

• Support of multiple views of the data

• Sharing of data and multiuser transaction processing

Self-Describing Nature of a Database System

A fundamental characteristic of the database approach is that the database system contains not only the

database itself but also a complete definition or description of the database structure and constraints.

This definition is stored in the DBMS catalog, which contains information such as the structure of each file,

the type and storage format of each data item, and various constraints on the data. The information

stored in the catalog is called meta-data, and it describes the structure of the primary database.

The catalog is used by the DBMS software and also by database users who need information about the

database structure. A general-purpose DBMS software package is not written for a specific database

application, and hence it must refer to the catalog to know the structure of the files in a specific

database, such as the type and format of data it will access.

In traditional file processing, data definition is typically part of the application programs themselves.

Hence, these programs are constrained to work with only one specific database, whose structure is declared

in the application programs. Whereas file-processing software can access only specific databases, DBMS

software can access diverse databases by extracting the database definitions from the catalog and then

using these definitions.

Insulation between Programs and Data, and Data Abstraction

In traditional file processing, the structure of data files is embedded in the application programs,

so any changes to the structure of a file may require changing all programs that access this file. By contrast,

DBMS access programs do not require such changes in most cases. The structure of data files is stored in

the DBMS catalog separately from the access programs. We call this property program-data

independence. For example, a file access program may be written in such a way that it can access only

STUDENT records. If we want to add another piece of data to each STUDENT record, say the BirthDate,

such a program will no longer work and must be changed. By contrast, in a DBMS environment, we just

need to change the description of STUDENT records in the catalog to reflect the inclusion of the new

data item BirthDate; no programs are changed. The next time a DBMS program refers to the catalog, the

new structure of STUDENT records will be accessed and used.

In some types of database systems, such as object-oriented and object-relational systems, users

can define operations on data as part of the database definitions. An operation (also called a function or

method) is specified in two parts. The interface (or signature) of an operation includes the operation name

and the data types of its arguments (or parameters). The implementation (or method) of the operation is



specified separately and can be changed without affecting the interface. This may be termed program-

operation independence.

The characteristic that allows program-data independence and program-operation

independence is called data abstraction. A DBMS provides users with a conceptual representation of data

that does not include many of the details of how the data is stored or how the operations are

implemented. Informally, a data model is a type of data abstraction that is used to provide this

conceptual representation. The data model uses logical concepts, such as objects, their properties, and

their interrelationships, that may be easier for most users to understand than computer storage

concepts. Hence, the data model hides storage and implementation details that are not of interest to

most database users.

Support of Multiple Views of the Data

A database typically has many users, each of whom may require a different perspective or view of the

database. A multiuser DBMS whose users have a variety of distinct applications must provide facilities for

defining multiple views. For example, one user of the database of may be interested only in accessing

and printing the transcript of each student; the view for this user. A second user, who is interested only

in checking that students have taken all the prerequisites of each course for which they register, may

require the view. Hence a database must support multiple views of the database.

Sharing of Data and Multiuser Transaction Processing

A multiuser DBMS, as its name implies, must allow multiple users to access the database at the same time.

This is essential if data for multiple applications is to be integrated and maintained in a single database.

The DBMS must include concurrency control software to ensure that several users trying to update the

same data do so in a controlled manner so that the result of the updates is correct. For example, when

several reservation clerks try to assign a seat on an airline flight, the DBMS should ensure that each seat

can be accessed by only one clerk at a time for assignment to a passenger. These types of applications

are generally called online transaction processing (OLTP) applications. A fundamental role of multiuser

DBMS software is to ensure that concurrent transactions operate correctly.

1B. With a diagram, explain the component modules of a DBMS and their interactions



Figure illustrates, in a simplified form, the typical DBMS components. The database and the DBMS catalog

are usually stored on disk. Access to the disk is controlled primarily by the operating system (OS), which

schedules disk input/output. A higher-level stored data manager module of the DBMS controls access to

DBMS information that is stored on disk, whether it is part of the database or the catalog. The dotted

lines and circles marked A, B, C, D, and E in Figure illustrates accesses that are under the control of this

stored data manager. The stored data manager may use basic OS services for carrying out low-level data

transfer between the disk and computer main storage, but it controls other aspects of data transfer,

such as handling buffers in main memory. Once the data is in main memory buffers, it can be processed

by other DBMS modules, as well as by application programs.

The DDL compiler processes schema definitions, specified in the DOL, and stores descriptions of the

schemas (meta-data) in the DBMS catalog. The catalog includes information such as the names and sizes

of files, names and data types of data items, storage details of each file, mapping information among

schemas, and constraints.

The runtime database processor handles database accesses at runtime; it receives retrieval or update

operations and carries them out on the database. The query compiler handles high-level queries that

are entered interactively. It parses, analyzes, and compiles or interprets a query by creating database

access code, and then generates calls to the runtime processor for executing the code.

The precompiler extracts DML commands from an application program written in a host programming

language. These commands are sent to the DML compiler for compilation into object code for database

access. The rest of the program is sent to the host language compiler.

The client program that accesses the DBMS running on a separate computer from the computer on

which the database resides.

2A. What is entity type? What is entity set? Explain the differences among an entity and relationships

with examples.

Entity Types and Entity Sets: A database usually contains groups of entities that are similar. For

example, a company employing hundreds of employees may want to store similar information



concerning each of the employees. These employee entities share the same attributes, but each entity

has its own value(s) for each attribute. An entity type defines a collection (or set) of entities that have

the same attributes, for example two entity types in previous example are EMPLOYEE and COMPANY,

The collection of all entities of a particular entity type in the database at any point in time is called an

entity set.

An entity type is represented in ER diagrams as a rectangular box enclosing the entity type name.

Attribute names are enclosed in ovals and are attached to their entity type by straight lines. Composite

attributes are attached to their component attributes by straight lines. Multivalued attributes are

displayed in double ovals. The Entity is a real world object and relationship is association between two

or more entities.

(There is no much difference between entity and relationships. The question must me difference

between relationship type , relationship set and instances)

2B. What is meant by RAID? What are the different levels of RAID Technology? Explain

RAID, originally stands for Redundant Arrays of Independent Disks. The levels of RAID are as follows:

RAID level 0 uses data striping, has no redundant data and hence has the best write performance since

updates do not have to be duplicated. However, its read performance is not as good as RAID level 1,

which uses mirrored disks. In the latter, performance improvement is possible by scheduling a read

request to the disk with shortest expected seek and rotational delay. RAID level 2 uses memory-style

redundancy by using Hamming codes, which contain parity bits for distinct overlapping subsets of

components. Thus, in one particular version of this level, three redundant disks suffice for four original

disks whereas, with mirroring-as in level 1-four would be required. Level 2 includes both error detection

and correction, although detection is generally not required because broken disks identify themselves.

RAID level 3 uses a single parity disk relying on the disk controller to figure out which disk has failed.

Levels 4 and 5 use block-level data striping, with level 5 distributing data and parity information across

all disks. Finally, RAID level 6 applies the so-called P + Q redundancy scheme using Reed-Soloman

codes to protect against up to two disk failures by using just two redundant disks. Figure shows different

RAID Levels.



3A.Define Functional Dependency.

A functional dependency (FD) is a constraint between two sets of attributes in a relation from a

database.

Given a relation R, a set of attributes X in R is said to functionally determine another attribute Y,

also in R, (written X → Y) if and only if each X value is associated with precisely one Y value.

Customarily we call X the determinant set and Y the dependent attribute. Thus, given a tuple and the

values of the attributes in X, one can determine the corresponding value of the Y attribute. For the

purposes of simplicity, given that X and Y are sets of attributes in R, X → Y denotes that X functionally

determines each of the members of Y - in this case Y is known as the dependent set. Thus, a candidate

key is a minimal set of attributes that functionally determine all of the attributes in a relation.

3B. Define Normalization. Explain INF with example.

In the field of relational database design, normalization is a systematic way of ensuring that a database

structure is suitable for general-purpose querying and free of certain undesirable characteristics—

insertion, update, and deletion anomalies—that could lead to a loss of data integrity.

First normal form (1NF or Minimal Form) is a normal form used in database normalization. A

relational database table that adheres to 1NF is one that meets a certain minimum set of criteria. These

criteria are basically concerned with ensuring that the table is a faithful representation of a relation and

that it is free of repeating groups.

A table is in 1NF if and only if it is "isomorphic to some relation", which means, specifically, that it

satisfies the following five conditions:

1. There's no top-to-bottom ordering to the rows.

2. There's no left-to-right ordering to the columns.

3. There are no duplicate rows.

4. Every row-and-column intersection contains exactly one value from the applicable domain (and

nothing else).



5. All columns are regular [i.e. rows have no hidden components such as row IDs, object IDs, or

hidden timestamps].

Violation of any of these conditions would mean that the table is not strictly relational, and therefore

that it is not in 1NF. Examples of tables (or views) that would not meet this definition of 1NF are:

• A table that lacks a unique key. Such a table would be able to accommodate duplicate rows, in

violation of condition 3.

• A view whose definition mandates that results be returned in a particular order, so that the row

ordering is an intrinsic and meaningful aspect of the view. This violates condition 1. The tuples in

true relations are not ordered with respect to each other.

• A table with at least one nullable attribute. A nullable attribute would be in violation of

condition 4, which requires every field to contain exactly one value from its column's domain.

3C. Explain the different types of database operations of UPDATE that deals with constraint voilations

There are three basic update operations on relations: insert, delete, and modify. Insert is used to insert a

new tuple or tuples in a relation, Delete is used to delete tuples, and Update (or Modify) is used to

change the values of some attributes in existing tuples. Whenever these operations are applied, the

integrity constraints specified on the relational database schema should not be violated.

The Insert Operation

The Insert operation provides a list of attribute values for a new tuple t that is to be inserted

into a relation R. Insert can violate any of the four types of constraints discussed in the previous

section. Domain constraints can be violated if an attribute value is given that does not appear in

the corresponding domain. Key constraints can be violated if a ey value in the new tuple t

already exists in another tuple in the relation r(R). Entity integrity can be violated if the primary

key of the new tuple t is null. Referential integrity can be violated if the value of any foreign key

in t refers to a tuple that does not exist in the referenced relation. If an insertion violates one or

more constraints, the default option is to reject the insertion.

For Example:

Insert <Cecilia', 'F', 'Kolonsky', '677678989', '1960-04-05', '6357 Windy Lane, Katv, TX', F,

28000, null, 4> into EMPLOYEE.

The Delete Operation

The Delete operation can violate only referential integrity, if the tuple being deleted is referenced by the

foreign keys from other tuples in the database. To specify deletion, a condition on the attributes of the

relation selects the tuple (or tuples) to be deleted. Here are some examples.

1. Delete the WORKS_ON tuple with ESSN = '999887777' and PNO = 10.

• This deletion is acceptable.

2. Delete the EMPLOYEE tuple with SSN = '999887777'.



• This deletion is not acceptable, because tuples in WORKS_ON refer to this tuple. Hence, if

the tuple is deleted, referential integrity violations will result.

Several options are available if a deletion operation causes a violation. The first option is to reject the

deletion. The second option is to attempt to cascade (or propgate) the deletion by deleting tuples that

reference the tuple that is being deleted. For example, in operation 2, the DBMS could automatically

delete the offending tuples from WORKS_ON with ESSN = '999887777'. A third option is to modify the

referencing attribute values that cause the violation; each such value is either set to null or changed to

reference another valid tuple. Combinations of these three options are also possible.

The Update Operation

The Update (or Modify) operation is used to change the values of one or more attributes in a tuple (or

tuples) of some relation R. It is necessary to specify a condition on the attributes of the relation to select

the tuple (or tuples) to be modified. Updating an attribute that is neither a primary key nor a foreign key

usually causes no problems; the DBMS need only check to confirm that the new value is of the correct

data type and domain. Modifying a primary key value is similar to deleting one tuple and inserting

another in its place, because we use the primary key to identify tuples. If a foreign key attribute is

modified, the DBMS must make sure that the new value refers to an existing tuple in the referenced

relation (or is null).

For Example:

Update the SALARY of the EMPLOYEE tuple with SSN = '999887777' to 28000.

Update the DNO of the EMPLOYEE tuple with SSN = '999887777' to 1.

4A. What are different operations of relational algebra.

Different operations of Relational Algebra are:

The SELECT Operation

The SELECT operation is used to select a subset of the tuples from a relation that satisfy a selection

condition. One can consider the SELECT operation to be a filter that keeps only those tuples that satisfy a

qualifying condition. The SELECT operation can also be visualized as a horizontal partition of the relation

into two sets of tuples-those tuples that satisfy the condition and are selected, and those tuples that do

not satisfy the condition and are discarded. For example, to select the EMPLOYEE tuples whose

department is 4, or those whose salary is greater than $30,000, we can individually specify each of these

two conditions with a SELECT operation as follows:

σσσσDNO=4 (EMPLOYEE)

σσσσsALARY>30000(EMPLOYEE)

The PROJECT Operation



The PROJECT operation, on the other hand, selects certain columns from the table and discards the

other columns. If we are interested in only certain attributes of a relation, we use the PROJECT

operation to project the relation over these attributes only. The result of the PROJECT operation can

hence be visualized as a vertical partition of the relation into two relations: one has the needed

columns (attributes) and contains the result of the operation, and the other contains the discarded

columns. For example, to list each employee's first and last name and salary, we can use the PROJECT

operation as follows:

π LNAME, FNAME, SALARY( EMPLOYEE)

The general form of the PROJECT operation is :

π <attribute list> (R)

RENAME Operation

It is often simpler to break down a complex sequence of operations by specifying intermediate result

relations than to write a single relational algebra expression. We can also use this technique to rename

the attributes in the intermediate and result relations. This can be useful in connection with more

complex operations such as UNION and JOIN. To rename the attributes in a relation, we simply list the

new attribute names in parentheses, as in the following example:

TEMP � σσσσDNO=5 (EMPLOYEE)

R (FIRSTNAME, LASTNAME, SALARY) �π FNAME, LNAME, SALARY (TEMP)

The general RENAME operation when applied to a relation R of degree n is denoted by any of the following

three forms:

ρS(B1, B2. .... B)R) or ρS (R) or ρ (B1,B2,...,Bn)(R)

The UNION, INTERSECTION, and MINUS Operations

UNION: The result of this operation, denoted by R U S, is a relation that includes all tuples that are

either in R or in S or in both Rand 5. Duplicate tuples are eliminated.

INTERSECTION: The result of this operation, denoted by R ∩ S, is a relation that includes all tuples that

are in both Rand S.

SET DIFFERENCE (OR MINUS): The result of this operation, denoted by R - S, is a relation that includes all

tuples that are in R but not in S.

The CARTESIAN PRODUCT (or CROSS PRODUCT) Operation

Next we discuss the CARTESIAN PRODUCT operation-also known as CROSS PRODUCT or CROSS JOIN-

which is denoted by ×. This is also a binary set operation, but the relations on which it is applied do not



have to be union compatible. This operation is used to combine tuples from two relations in a

combinatorial fashion. In general, the result of R(A1,, A2, ... , An ) X S(B1,B2, ... , Bm) is a relation Q with

degree n + m attributes Q(A1,A2 ... , An, B1, B2, ... , Bm), in that order.

For example, suppose that we want to retrieve a list of names of each female employee's dependents.

We can do this as follows:

FEMALE_EMPS ��σσσσ SEX=' F' (EMPLOYEE)

EMPNAMES�π FNAME, LNAME, SSN (FEMALE_EMPS)

EMP_DEPENDENTS�EMPNAMES X DEPENDENT

ACTUAL_DEPENDENTS�σσσσSSN=ESSN (EMP_DEPENDENTS)

RESULT�π FNAME. LNAME, DEPENDENT_LNAME (ACTUAL_DEPENDENTS)

The JOIN Operation

The JOIN operation, denoted by is used to combine related tuples from two relations into single

tuples. This operation is very important for any relational database with more than a single relation,

because it allows us to process relationships among relations. To illustrate JOIN, suppose that we want to

retrieve the name of the manager of each department. To get the manager's name, we need to combine

each department tuple with the employee tuple whose SSN value matches the MGRSSN value in the

department tuple. We do this by using the JOIN operation, and then projecting the result over the

necessary attributes, as follows:

MGRSSN=SSN EMPLOYEE DEPT_MGR � DEPARTMENT

RESULT �π DNAME, LNAME, FNAME (DEPT_MGR)

The general form of a JOIN operation on two relations R(A 1 , A2, ... , An) and S(B1,B2, ... , Bm) is

<join condition> S R

4B. Mention the Queries for the following using Relational Algebra



5A. Explain the concepts of views with example in SQL.

A view in SQL terminology is a single table that is derived from other tables. A view in SQL terminology is

a single table that is derived from other tables physical form; it is considered a virtual table, in contrast to

base tables, whose tuples are actually stored in the database. We can think of a view as a way of

specifying a table that we need to reference frequently, even though it may not exist physically.

Specification of Views in SQL

In SQL, the command to specify a view is CREATE VIEW. The view is given a (virtual) table name (or view

name), a list of attribute names, and a query to specify the contents of the view. The views in VI and V2

create virtual tables whose schemas are illustrated in Figure

V1:

CREATE VIEW WORKS_ON1

AS SELECT FNAME, LNAME, PNAME, HOURS

FROM EMPLOYEE, PROJECT, WORKS_ON

WHERE SSN=ESSN AND PNO=PNUMBER; V2: CREATE VIEW DEPTINFO(DEPT_NAME,NO_OF_EMPS,TOTAL_ SAL)

AS SELECT DNAME, COUNT (*), SUM (SALARY) FROM DEPARTMENT, EMPLOYEE WHERE DNUMBER=DNO GROUP BY DNAME;



In VI, we did not specify any new attribute names for the view WORKS_ON1 (although we could have); in

this case, WORKS_ON1 inherits the names of the view attributes from the defining tables EMPLOYEE,

PROJECT, and WORKS_ON. View V2 explicitly specifies new attribute names for the view DEPT_INFO,

using a one-to-one correspondence between the attributes specified in the CREATE VIEW clause and

those specified in the SELECT clause of the query that defines the view.

We can now specify SQL queries on a view-or virtual table-in the same way we specify queries involving

base tables. For example, to retrieve the last name and first name of all employees who work on

'ProjectX', we can utilize the WORKS_ON1 view and specify the query below:

SELECT FNAME, LNAME FROM WORKS_ON1

WHERE PNAME='ProjectX';

If we do not need a view any more, we can use the DROP VIEW command to dispose of it. For example, to

get rid of the view VI, we can use the SQL statement

DROP VIEW WORKS_ON1;

View Update

Updating of views is complicated and can be ambiguous. In general, an update on a view defined on a

single table without any aggregate functions can be mapped to an update on the underlying base table

under certain conditions. For a view involving joins, an update operation may be mapped to update

operations on the underlying base relations in multiple ways. To illustrate potential problems with

updating a view defined on multiple tables, consider the WORKS_ON1 view, and suppose that we issue the

command to update the PNAME attribute of 'John Smith' from 'ProductX' to 'ProductY'. This view update is

shown below:

UPDATE WORKS_ON1 SET PNAME = 'ProductY' WHERE LNAME='Smith' AND FNAME='John' AND

PNAME='ProductX';

In summary, we can make the following observations:

• A view with a single defining table is updatable if the view attributes contain the primary key of

the base relation, as well as all attributes with the NOT NULL constraint that do not have default

values specified.

• Views defined on multiple tables using joins are generally not updatable.

• Views defined using grouping and aggregate functions are not updatable.

5B. Write the syntax for INSERT, DELETE & UPDATE commands with examples.

The INSERT Command



In its simplest form, INSERT is used to add a single tuple to a relation. We must specify the relation name

and a list of values for the tuple. The values should be listed in the same order in which the corresponding

attributes were specified in the CREATE TABLE command. For example, to add a new tuple to the EMPLOYEE

relation.

INSERT INTO EMPLOYEE VALUES ('Richard', 'K', 'Marini', '653298653', '1962-12-30', '98Oak Forest,Katy,TX', 'M', 37000, '987654321', 4);

A second form of the INSERT statement allows the user to specify explicit attribute names that correspond

to the values provided in the INSERT command. This is useful if a relation has many attributes but only a

few of those attributes are assigned values in the new tuple. Attributes with NULL allowed or DEFAULT

values are the ones that can be left out. For example, to enter a tuple for a new EMPLOYEE for whom we

know only the FNAME, LNAME, DNa, and SSN attributes, we can use

INSERT INTO EMPLOYEE (FNAME, LNAME, DNO, SSN) VALUES ('Richard', 'Marini', 4, '653298653');

Attributes not specified are set to their DEFAULT or to NULL, and the values are listed in the same order

as the attributes are listed in the INSERT command itself. It is also possible to insert into a relation multiple

tuples separated by commas in a single INSERT command. The attribute values forming each tuple are

enclosed in parentheses.

INSERT INTO DEPTS_INFO (DEPT_NAME, MGR_SSN) SELECT DNAME,MGRSSN FROM DEPARTMENT;

The DELETE Command

The DELETE command removes tuples from a relation. It includes a WHERE clause, similar to that used in an

SQL query, to select the tuples to be deleted. Tuples are explicitly deleted from only one table at a time.

However, the deletion may propagate to tuples in other relations if referential triggered actions are

specified in the referential integrity constraints of the DDL statements. Depending on the number of

tuples selected by the condition in the WHERE clause, zero, one, or several tuples can be deleted by a

single DELETE command. A missing WHERE clause specifies that all tuples in the relation are to be

deleted; however, the table remains in the database as an empty table.

DELETE FROM EMPLOYEE WHERE LNAME='Brown'; DELETE FROM EMPLOYEE

The UPDATE Command

The UPDATE command is used to modify attribute values of one or more selected tuples. As in the DELETE

command, a WHERE clause in the UPDATE command selects the tuples to be modified from a single

relation. However, updating a primary key value may propagate to the foreign key values of tuples in

other relations if such a referential triggered action is specified in the referential integrity constraints of

the DDL. An additional SET clause in the UPDATE command specifies the attributes to be modified and



their new values. For example, to change the location and controlling department number of project

number 10 to 'TEXAS' and 5.

UPDATE PROJECT

SET PLOCATION = 'TEXAS', DNUM = 5 WHERE PNUMBER=10;

Several tuples can be modified with a single UPDATE command.

UPDATE EMPLOYEE SET SALARY=SALARY+ 1.1*SALARY AS INCREASED_SAL WHERE DNO=5;

6A. What are the circumstances under which stored procedures are used.

A stored procedure or in simple a proc is a named PL/SQL block which performs one or more specific

task. This is similar to a procedure in other programming languages. A procedure has a header and a

body. The header consists of the name of the procedure and the parameters or variables passed to the

procedure. The body consists or declaration section, execution section and exception section similar to a

general PL/SQL Block. A procedure is similar to an anonymous PL/SQL Block but it is named for repeated

usage.

We can pass parameters to procedures in three ways.

1) IN-parameters

2) OUT-parameters

3) IN OUT-parameters

A procedure may or may not return any value.

6B. Write the syntax for stored procedure.

General Syntax to create a procedure is:

CREATE [OR REPLACE] PROCEDURE proc_name [list of parameters]

IS

Declaration section

BEGIN

Execution section

EXCEPTION

Exception section

END;

IS - marks the beginning of the body of the procedure and is similar to DECLARE in anonymous PL/SQL

Blocks. The code between IS and BEGIN forms the Declaration section.

The syntax within the brackets [ ] indicate they are optional. By using CREATE OR REPLACE together the

procedure is created if no other procedure with the same name exists or the existing procedure is

replaced with the current code.

The below example creates a procedure ‘employer_details’ which gives the details of the employee.

1> CREATE OR REPLACE PROCEDURE employer_details



2> IS

3> CURSOR emp_cur IS

4> SELECT first_name, last_name, salary FROM emp_tbl;

5> emp_rec emp_cur%rowtype;

6> BEGIN

7> FOR emp_rec in sales_cur

8> LOOP

9> dbms_output.put_line(emp_cur.first_name || ' ' ||emp_cur.last_name

10> || ' ' ||emp_cur.salary);

11> END LOOP;

12>END;

13> /

6C. Describe the concept of triggers in DBMS. Explain the same with an example.

A trigger is a pl/sql block structure which is fired when a DML statements like Insert, Delete, Update is

executed on a database table. A trigger is triggered automatically when an associated DML statement is

executed.

The Syntax for creating a trigger is: CREATE [OR REPLACE ] TRIGGER trigger_name

{BEFORE | AFTER | INSTEAD OF }

{INSERT [OR] | UPDATE [OR] | DELETE}

[OF col_name]

ON table_name

[REFERENCING OLD AS o NEW AS n]

[FOR EACH ROW]

WHEN (condition)

BEGIN

--- sql statements

END;

• CREATE [OR REPLACE ] TRIGGER trigger_name - This clause creates a trigger with the given name

or overwrites an existing trigger with the same name.

• {BEFORE | AFTER | INSTEAD OF } - This clause indicates at what time should the trigger get fired.

i.e for example: before or after updating a table. INSTEAD OF is used to create a trigger on a

view. before and after cannot be used to create a trigger on a view.

• {INSERT [OR] | UPDATE [OR] | DELETE} - This clause determines the triggering event. More than

one triggering events can be used together separated by OR keyword. The trigger gets fired at

all the specified triggering event.

• [OF col_name] - This clause is used with update triggers. This clause is used when you want to

trigger an event only when a specific column is updated.

• CREATE [OR REPLACE ] TRIGGER trigger_name - This clause creates a trigger with the given name

or overwrites an existing trigger with the same name.

• [ON table_name] - This clause identifies the name of the table or view to which the trigger is

associated.

• [REFERENCING OLD AS o NEW AS n] - This clause is used to reference the old and new values of

the data being changed. By default, you reference the values as :old.column_name or

:new.column_name. The reference names can also be changed from old (or new) to any other



user-defined name. You cannot reference old values when inserting a record, or new values

when deleting a record, because they do not exist.

• [FOR EACH ROW] - This clause is used to determine whether a trigger must fire when each row

gets affected ( i.e. a Row Level Trigger) or just once when the entire sql statement is

executed(i.e.statement level Trigger).

• WHEN (condition) - This clause is valid only for row level triggers. The trigger is fired only for

rows that satisfy the condition specified.

-- TRIGGER EXAMPLE

CREATE TABLE DEPT(

DEPTNO NUMBER(2),

DNAME VARCHAR2(14),

LOC VARCHAR2(13)

);

INSERT INTO DEPT VALUES (10, 'ACCOUNTING', 'NEW YORK');

INSERT INTO DEPT VALUES (20, 'RESEARCH', 'DALLAS');

INSERT INTO DEPT VALUES (30, 'SALES', 'CHICAGO');

INSERT INTO DEPT VALUES (40, 'OPERATIONS', 'BOSTON');

create or replace trigger deptbs before insert or update or delete

on dept

begin

dbms_output.put_line('before statement (dept)');

end;

/

insert into dept values(05,'PRODUCTION','BGM');

drop table dept;

7A. How the schedules are characterized based on serializability.

Suppose that two users-two airline reservation clerks submit to the DBMS transactions T1 and T2 at

approximately the same time.

If no interleaving of operations is permitted, there are only two possible outcomes:

1. Execute all the operations of transaction T1 (in sequence) followed by all the operations of

transaction T2 (in sequence).

2. Execute all the operations of transaction T2 (in sequence) followed by all the operations of

transaction T1(in sequence).

These alternatives are shown in Figure a and b, respectively. If interleaving of operations is allowed,

there will be many possible orders in which the system can execute the individual operations of the

transactions. Two possible schedules are shown in Figure c. The concept of serializability of schedules is



used to identify which schedules are correct when transaction executions have interleaving of their

operations in the schedules. This section defines serializability and discusses how it may be used in

practice.

Serial, Nonserial, and Conflict-Serializable Schedules

Schedules A and B in Figure a and b are called serial because the operations of each transaction are

executed consecutively, without any interleaved operations from the other transaction. In a serial

schedule, entire transactions are performed in serial order: T1 and then T2 in Figure a, and T2 and then T1

in Figure b. Schedules C and D in Figure c are called nonserial because each sequence interleaves

operations from the two transactions. Formally, a schedule S is serial if, for every transaction T

participating in the schedule, all the operations of T are executed consecutively in the schedule;

otherwise, the schedule is called nonserial. Hence, in a serial schedule, only one transaction at a time is

active-the commit (or abort) of the active transaction initiates execution of the next transaction. No

interleaving occurs in a serial schedule.



The problem with serial schedules is that they limit concurrency or interleaving of operations. In a serial

schedule, if a transaction waits for an [/0 operation to complete, we cannot switch the CPU processor to

another transaction, thus wasting valuable CPU processing time. In addition, if some transaction T is quite

long, the other transactions must wait for T to complete all its operations before commencing. Hence,

serial schedules are generally considered unacceptable in practice. A schedule S of n transactions is

serializable if it is equivalent to some serial schedule of the same n transactions. Two schedules are

called result equivalent if they produce the same final state of the database. The safest and most

general approach to defining schedule equivalence is not to make any assumption about the types of

operations included in the transactions. Two schedules are said to be conflict equivalent if the order of

any two conflicting operations is the same in both schedules. If two conflicting operations are applied in

different orders in two schedules, the effect can be different on the database or on other transactions in

the schedule, and hence the schedules are not conflict equivalent.

7B. Explain the different desirable properties of transactions.

Transactions should possess several properties. These are often called the ACID properties, and they

should be enforced by the concurrency control and recovery methods of the DBMS. The following are

the ACID properties:

1. Atomicity: A transaction is an atomic unit of processing; it is either performed in its entirety

or not performed at all.

2. Consistency preservation: A transaction is consistency preserving if its complete

execution takes the database from one consistent state to another.

3. Isolation: A transaction should appear as though it is being executed in isolation from other

transactions. That is, the execution of a transaction should not be interfered with by any other

transactions executing concurrently.

4. Durability or permanency: The changes applied to the database by a committed

transaction must persist in the database. These changes must not be lost because of any failure.

8A. What are the rules of Binary locks involved in transaction.

If the simple binary locking scheme is used in transaction , every transaction must obey the following

rules:

1. A transaction T must issue the operation 1ock_i tem(X) before any read_i tem(X) or wri te_item(X)

operations are performed in T.

2. A transaction T must issue the operation unlock_i tem(X) after all read_i tem(X) and wri te_item(X)

operations are completed in T.

3. A transaction T will not issue a lock_i tem(X) operation if it already holds the lock on item X.



4. A transaction T will not issue an unlock_i tern(X) operation unless it already holds the lock on item X.

8B. Describe the optimistic concurrency control techniques.

In optimistic concurrency control techniques, also known as validation or certification techniques, no

checking is done while the transaction is executing. Several proposed concurrency control methods use

the validation technique. In this scheme, updates in the transaction are not applied directly to the

database items until the transaction reaches its end. During transaction execution, all updates are

applied to local copies of the data items that are kept for the transaction. At the end of transaction

execution, a validation phase checks whether any of the transaction’s updates violate serializability.

Certain information needed by the validation phase must be kept by the system. If serializability is not

violated, the transaction is committed and the database is updated from the local copies; otherwise, the

transaction is aborted and then restarted later.

There are three phases for this concurrency control protocol:

1. Read phase: A transaction can read values of committed data items from the database.

However, updates are applied only to local copies (versions) of the data items kept in the

transaction workspace.

2. Validation phase: Checking is performed to ensure that serializability will not be violated if the

transaction updates are applied to the database.

3. Write phase: If the validation phase is successful, the transaction updates are applied to the

database; otherwise, the updates are discarded and the transaction is restarted.

8C. How does Index locking resolve the phantom problem.

A transaction T1 may read a set of rows from a table perhaps based on some condition specified in the

SQL WHERE-clause. Now suppose that a transaction T2 inserts a new row that also satisfies the WHERE-

clause condition used in T1, into the table used by T1. If T1 is repeated, then T1 will see a phantom, a row

that previously did not exist.

Two-phase locking can also be applied to indexes, where the nodes of an index correspond to disk

pages. However, holding locks on index pages until the shrinking phase of 2PL could cause an undue

amount of transaction blocking. This is because searching an index always starts at the root, so if a

transaction wants to insert a record (write operation), the root would be locked in exclusive mode, so all

other conflicting lock requests for the index must wait until the transaction enters its shrinking phase.

This blocks all other transactions from accessing the index, so in practice other approaches to locking an

index must be used.

The tree structure of the index can be taken advantage of when developing a concurrency control

scheme. For example, when an index search (read operation) is being executed, a path in the tree is

traversed from the root to a leaf. Once a lower-level node in the path has been accessed, the higher-level

nodes in that path will not be used again. So once a read lock on a child node is obtained, the lock on the



parent can be released. Second, when an insertion is being applied to a leaf node (that is, when a key

and a pointer are inserted), then a specific leaf node must be locked in exclusive mode. However, if that

node is not full, the insertion will not cause changes to higher-level index nodes, which implies that they

need not be locked exclusively.

DATABASE MANAGEMENT SYSTEM ,DEC 2010 ANSWER BANK 1

Documents

Transcript of DATABASE MANAGEMENT SYSTEM ,DEC 2010 ANSWER BANK 1