ans mi0034 databasemanagementsystem sda 2012 ii 130213070828 phpapp02 (1)

7/27/2019 Ans Mi0034 Databasemanagementsystem Sda 2012 II 130213070828 Phpapp02 (1)

1/82

MI0034 Database

Management

Systems

MI00

A t y a b G u l f C a t e r i n g C o

B l o c k 1 1 , S t r e e t 1 0 8

J a b r i y a -

K u w a i t

1 1 / 0 2 / 2 0 0 9

Zafar Ishtiaq- 531111145

Assignment SET I and SET II .


2/82


3/82

Data dependence

Using file-based system, the physical structure and storage of the data files and

records are defined in the application program code. This characteristic is known

as program-data dependence. Making changes to an existing structure are rather

difficult and will lead to a modification of program. Such maintenance activities

are time-consuming and subject to error.

Incompatible file formats

The structures of the file are dependent on the application programming

language. However file structure provided in one programming language such as

direct file, indexed-sequential file which is available in COBOL programming, may

be different from the structure generated by other programming language such

as C. The direct incompatibility makes them difficult to process jointly.Fixed queries / proliferation of application programs

File-based systems are very dependent upon the application programmer. Any

required queries or reports have to be written by the application programmer.

Normally, a fixed format query or report can only be entertained and no facility

for ad-hoc queries if offered.

File-based systems also give tremendous pressure on data processing staff, with

users' complaints on programs that are inadequate or inefficient in meeting their

demands. Documentation may be limited and maintenance of the system is

difficult. Provision for security, integrity and recovery capability is very limited.

Database Systems:

In order to overcome the limitations of the file-based approach, the concept of

database and the Database Management System (DMS) was emerged in 60s.

A database is an application that can store and retrieve data very rapidly. The

relational bit refers to how the data is stored in the database and how it isorganized. When we talk about database, we mean a relational database, in fact

an RDBMS - Relational Database Management System.
http://cplus.about.com/od/glossar1/g/applicationdefn.htmhttp://cplus.about.com/od/glossar1/g/rdbms.htmhttp://cplus.about.com/od/glossar1/g/rdbms.htmhttp://cplus.about.com/od/glossar1/g/applicationdefn.htm


4/82

In a relational database, all data is stored in tables. These have the same structure

repeated in each row (like a spreadsheet) and it is the relations between the

tables that make it a "relational" table

Advantages:

A number of advantages of applying database approach in application system are

obtained including:

Control of data redundancy

The database approach attempts to eliminate the redundancy by integrating the

file. Although the database approach does not eliminate redundancy entirely, itcontrols the amount of redundancy inherent in the database.

Data consistency:

By eliminating or controlling redundancy, the database approach reduces the risk

of inconsistencies occurring. It ensures all copies of the idea are kept consistent.

More information from the same amount of data

With the integration of the operated data in the database approach, it may be

possible to derive additional information for the same data.

Sharing of data

Database belongs to the entire organization and can be shared by all authorized

users.

Improved data integrity

Database integrity provides the validity and consistency of stored data. Integrity

is usually expressed in terms of constraints, which are consistency rules that the

database is not permitted to violate.

Improved security

Database approach provides a protection of the data from the unauthorized

users. It may take the term of user names and passwords to identify user type


5/82

and their access right in the operation including retrieval, insertion, updating and

deletion.

Enforcement of standards

The integration of the database enforces the necessary standards including dataformats, naming conventions, documentation standards, update procedures and

access rules.

Economy of scale

Cost savings can be obtained by combining all organization's operational data into

one database with applications to work on one source of data.

Balance of conflicting requirements

By having a structural design in the database, the conflicts between users or

departments can be resolved. Decisions will be based on the base use of

resources for the organization as a whole rather that for an individual entity.

Improved data accessibility and responsiveness

By having an integration in the database approach, data accessing can be crossed

departmental boundaries. This feature provides more functionality and better

services to the users.

Increased productivity

The database approach provides all the low-level file-handling routines. The

provision of these functions allows the programmer to concentrate more on the

specific functionality required by the users. The fourth-generation environment

provided by the database can simplify the database application development.

Improved maintenance

Database approach provides a data independence. As a change of data structure

in the database will be affect the application program, it simplifies databaseapplication maintenance.

Increased concurrency


6/82

Database can manage concurrent data access effectively. It ensures no

interference between users that would not result any loss of information nor loss

of integrity.

Improved backing and recovery services

Modern database management system provides facilities to minimize the amount

of processing that can be lost following a failure by using the transaction

approach.

Disadvantages

In split of a large number of advantages can be found in the database approach, it

is not without any challenge. The following disadvantages can be found including:

Complexity

Database management system is an extremely complex piece of software. All

parties must be familiar with its functionality and take full advantage of it.

Therefore, training for the administrators, designers and users is required.

Size

The database management system consumes a substantial amount of main

memory as well as a large number amount of disk space in order to make it runefficiently.

Cost of DBMS

A multi-user database management system may be very expensive. Even after

the installation, there is a high recurrent annual maintenance cost on the

software.

Cost of conversion

When moving from a file-base system to a database system, the company is

required to have additional expenses on hardware acquisition and training cost.

Performance

As the database approach is to cater for many applications rather than exclusively

for a particular one, some applications may not run as fast as before.


7/82

Higher impact of a failure

The database approach increases the vulnerability of the system due to the

centralization. As all users and applications reply on the database availability, the

failure of any component can bring operations to a halt and affect the services to

the customer seriously

Q2. What is the disadvantage of sequential file organization? How do you

overcome it? What are the advantages & disadvantages of Dynamic Hashing?

Disadvantage of Sequential file organization:

A file that contains records or other elements that are stored in a chronological

order based on account number or some other identifying data are called

sequential files . In order to locate the desired data, sequential files must be read

starting at the beginning of the file. A sequential file may be stored on a

sequential access device such as magnetic tape or on a direct access device such

as magnetic disk but the accessing method remains the same.

Slow Access :

The Major issue with the Sequential files is the slow access of information as the

read attempts go through the files one by one until arrived to the desired record.

That makes all file operation read write and update very time consuming in

comparison to the random access files.

Dynamic Hashing:

Advantages

The main advantage of hash tables over other table data structures is speed. This

advantage is more apparent when the number of entries is large (thousands or

more). Hash tables are particularly efficient when the maximum number of

entries can be predicted in advance, so that the bucket array can be allocated

once with the optimum size and never resized.
http://www.answers.com/topic/sequential-filehttp://www.answers.com/topic/sequential-file


8/82

If the set of key-value pairs is fixed and known ahead of time (so insertions and

deletions are not allowed), one may reduce the average lookup cost by a careful

choice of the hash function, bucket table size, and internal data structures. In

particular, one may be able to devise a hash function that is collision-free, or even

perfect (see below). In this case the keys need not be stored in the table.

Disadvantages

Hash tables can be more difficult to implement than self-balancing binary search

trees. Choosing an effective hash function for a specific application is more an art

than a science. In open-addressed hash tables it is fairly easy to create a poor

hash function.

Although operations on a hash table take constant time on average, the cost of a

good hash function can be significantly higher than the inner loop of the lookup

algorithm for a sequential list or search tree. Thus hash tables are not effective

when the number of entries is very small. (However, in some cases the high cost

of computing the hash function can be mitigated by saving the hash value

together with the key.)

For certain string processing applications, such as spell-checking, hash tables may

be less efficient than tries, finite automata, or Judy arrays. Also, if each key is

represented by a small enough number of bits, then, instead of a hash table, one

may use the key directly as the index into an array of values. Note that there are

no collisions in this case.

The entries stored in a hash table can be enumerated efficiently (at constant cost

per entry), but only in some pseudo-random order. Therefore, there is no efficientway to efficiently locate an entry whose key is nearest to a given key. Listing all n

entries in some specific order generally requires a separate sorting step, whose

cost is proportional to log(n) per entry. In comparison, ordered search trees have

lookup and insertion cost proportional to log(n), but allow finding the nearest key
http://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.htmlhttp://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.htmlhttp://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.htmlhttp://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.htmlhttp://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.htmlhttp://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.htmlhttp://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.htmlhttp://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.htmlhttp://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.htmlhttp://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.html


9/82

at about the same cost, and ordered enumeration of all entries at constant cost

per entry.

If the keys are not stored (because the hash function is collision-free), there maybe no easy way to enumerate the keys that are present in the table at any given

moment.

Although the average cost per operation is constant and fairly small, the cost of a

single operation may be quite high. In particular, if the hash table uses dynamic

resizing, an insertion or deletion operation may occasionally take time

proportional to the number of entries. This may be a serious drawback in real-

time or interactive applications.

Hash tables in general exhibit poor locality of referencethat is, the data to be

accessed is distributed seemingly at random in memory. Because hash tables

cause access patterns that jump around, this can trigger microprocessor cache

misses that cause long delays. Compact data structures such as arrays, searched

with linear search, may be faster if the table is relatively small and keys are

integers or other short strings. According to Moore's Law, cache sizes are growing

exponentially and so what is considered "small" may be increasing. The optimal

performance point varies from system to system.

Hash tables become quite inefficient when there are many collisions. While

extremely uneven hash distributions are extremely unlikely to arise by chance, a

malicious adversary with knowledge of the hash function may be able to supply

information to a hash which creates worst-case behavior by causing excessive

collisions, resulting in very poor performance (i.e., a denial of service attack). In

critical applications, either universal hashing can be used or a data structure with

better worst-case guarantees may be preferable.
http://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.htmlhttp://rajaghoshtech2.blogspot.com/2010/03/advantages-and-disadvantages-of-hashing.html


10/82

Q3. What is relationship type? Explain the difference among a relationship

instance, relationship type & a relation set?

A3.

A relationship type R among n entity types E1, E2, , En is a set of associations

among entities from these types. Actually, R is a set of relationship instances ri

where each ri is an n-tuple of entities (e1, e2, , en), and each entity ej in ri is a

member of entity type Ej, 1jn. Hence, a relationship type is a mathematical

relation on E1, E2, , En, or alternatively it can be defined as a subset of the

Cartesian product E1x E2x xEn . Here, entity types E1, E2, , En defines a set of

relationship, called relationship sets.

Q4. What is SQL? Discuss.

A4.

Abbreviation ofstructuredquerylanguage, and pronounced either see-kwellor as

separate letters. SQL is a standardized query language for requesting information

from a database. The original version called SEQUEL (structured English querylanguage) was designed by an IBM research center in 1974 and 1975. SQL was

first introduced as a commercial database system in 1979 by Oracle Corporation.

Historically, SQL has been the favorite query language for database management

systems running on minicomputers and mainframes. Increasingly, however, SQL is

being supported by PC database systems because it supports distributed

databases (databases that are spread out over several computer systems). This

enables several users on a local-area network to access the same databasesimultaneously.

Although there are different dialects of SQL, it is nevertheless the closest thing to

a standard query language that currently exists. In 1986, ANSI approved a

rudimentary version of SQL as the official standard, but most versions of SQL since
http://www.webopedia.com/TERM/Q/query_language.htmlhttp://www.webopedia.com/TERM/D/database.htmlhttp://www.webopedia.com/TERM/I/IBM.htmlhttp://www.webopedia.com/TERM/D/database_management_system_DBMS.htmlhttp://www.webopedia.com/TERM/M/minicomputer.htmlhttp://www.webopedia.com/TERM/M/mainframe.htmlhttp://www.webopedia.com/TERM/S/support.htmlhttp://www.webopedia.com/TERM/P/PC.htmlhttp://www.webopedia.com/TERM/D/distributed_database.htmlhttp://www.webopedia.com/TERM/D/distributed_database.htmlhttp://www.webopedia.com/TERM/C/computer_system.htmlhttp://www.webopedia.com/TERM/U/user.htmlhttp://www.webopedia.com/TERM/L/local_area_network_LAN.htmlhttp://www.webopedia.com/TERM/A/access.htmlhttp://www.webopedia.com/TERM/S/standard.htmlhttp://www.webopedia.com/TERM/A/ANSI.htmlhttp://www.webopedia.com/TERM/A/ANSI.htmlhttp://www.webopedia.com/TERM/S/standard.htmlhttp://www.webopedia.com/TERM/A/access.htmlhttp://www.webopedia.com/TERM/L/local_area_network_LAN.htmlhttp://www.webopedia.com/TERM/U/user.htmlhttp://www.webopedia.com/TERM/C/computer_system.htmlhttp://www.webopedia.com/TERM/D/distributed_database.htmlhttp://www.webopedia.com/TERM/D/distributed_database.htmlhttp://www.webopedia.com/TERM/P/PC.htmlhttp://www.webopedia.com/TERM/S/support.htmlhttp://www.webopedia.com/TERM/M/mainframe.htmlhttp://www.webopedia.com/TERM/M/minicomputer.htmlhttp://www.webopedia.com/TERM/D/database_management_system_DBMS.htmlhttp://www.webopedia.com/TERM/I/IBM.htmlhttp://www.webopedia.com/TERM/D/database.htmlhttp://www.webopedia.com/TERM/Q/query_language.html


11/82

then have included many extensions to the ANSI standard. In 1991, ANSI updated

the standard. The new standard is known as SAG SQL.

SQL was one of the first commercial languages for Edgar F. Codd's relational

model, as described in his influential 1970 paper, "A Relational Model of Data forLarge Shared Data Banks".[5] Despite not adhering to the relational model as

described by Codd, it became the most widely used database language.[6][7]

Although SQL is often described as, and to a great extent is, a declarative

language, it also includes procedural elements. SQL became a standard of the

American National Standards Institute (ANSI) in 1986, and of the International

Organization for Standards (ISO) in 1987. Since then, the standard has been

enhanced several times with added features. However, issues of SQL code

portability between major RDBMS products still exist due to lack of full

compliance with, or different interpretations of, the standard. Among the reasonsmentioned are the large size and incomplete specification of the standard, as well

as vendor lock-in.

SQL was initially developed at IBM by Donald D. Chamberlin and A. Murphy in the

early 1970s. This version, initially called SEQUEL (Structured English Query

Language), was designed to manipulate and retrieve data stored in IBM's original

quasi-relational database management system, System R, which a group at IBM

San Jose Research Laboratory had developed during the 1970s.[8] The acronym

SEQUEL was later changed to SQL because "SEQUEL" was a trademark of the UK-based Hawker Siddeley aircraft company.[9]

The first Relational Database Management System (RDBMS) was RDMS,

developed at MIT in the early 1970s, soon followed by Ingres, developed in 1974

at U.C. Berkeley. Ingres implemented a query language known as QUEL, which

was later supplanted in the marketplace by SQL.[9]

In the late 1970s, Relational Software, Inc. (now Oracle Corporation) saw the

potential of the concepts described by Codd, Chamberlin, and Boyce and

developed their own SQL-based RDBMS with aspirations of selling it to the U.S.

Navy, Central Intelligence Agency, and other U.S. government agencies. In June

1979, Relational Software, Inc. introduced the first commercially available

implementation of SQL, Oracle V2 (Version2) for VAX computers. Oracle V2 beat

IBM's August release of the System/38 RDBMS to market by a few weeks.[citation

needed]
http://www.webopedia.com/TERM/E/extension.htmlhttp://en.wikipedia.org/wiki/Edgar_F._Coddhttp://en.wikipedia.org/wiki/Relational_modelhttp://en.wikipedia.org/wiki/Relational_modelhttp://en.wikipedia.org/wiki/SQL#cite_note-codd-relational-model-4http://en.wikipedia.org/wiki/SQL#cite_note-codd-relational-model-4http://en.wikipedia.org/wiki/SQL#cite_note-codd-relational-model-4http://en.wikipedia.org/wiki/Codd%27s_12_ruleshttp://en.wikipedia.org/wiki/Codd%27s_12_ruleshttp://en.wikipedia.org/wiki/SQL#cite_note-SQL-Fundamentals-5http://en.wikipedia.org/wiki/SQL#cite_note-SQL-Fundamentals-5http://en.wikipedia.org/wiki/SQL#cite_note-SQL-Fundamentals-5http://en.wikipedia.org/wiki/Declarative_programminghttp://en.wikipedia.org/wiki/Declarative_programminghttp://en.wikipedia.org/wiki/Procedural_programminghttp://en.wikipedia.org/wiki/Technical_standardhttp://en.wikipedia.org/wiki/American_National_Standards_Institutehttp://en.wikipedia.org/wiki/International_Organization_for_Standardshttp://en.wikipedia.org/wiki/International_Organization_for_Standardshttp://en.wikipedia.org/wiki/Vendor_lock-inhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/Donald_D._Chamberlinhttp://en.wikipedia.org/w/index.php?title=A._Murphy&action=edit&redlink=1http://en.wikipedia.org/wiki/IBM_System_Rhttp://en.wikipedia.org/wiki/IBM_Almaden_Research_Centerhttp://en.wikipedia.org/wiki/IBM_Almaden_Research_Centerhttp://en.wikipedia.org/wiki/SQL#cite_note-chamberlin-boyce-sequel-7http://en.wikipedia.org/wiki/SQL#cite_note-chamberlin-boyce-sequel-7http://en.wikipedia.org/wiki/SQL#cite_note-chamberlin-boyce-sequel-7http://en.wikipedia.org/wiki/Trademarkhttp://en.wikipedia.org/wiki/United_Kingdomhttp://en.wikipedia.org/wiki/United_Kingdomhttp://en.wikipedia.org/wiki/Hawker_Siddeleyhttp://en.wikipedia.org/wiki/SQL#cite_note-oppel-databases-8http://en.wikipedia.org/wiki/SQL#cite_note-oppel-databases-8http://en.wikipedia.org/wiki/SQL#cite_note-oppel-databases-8http://en.wikipedia.org/wiki/Relational_database_management_systemhttp://en.wikipedia.org/wiki/MIThttp://en.wikipedia.org/wiki/Ingres_(database)http://en.wikipedia.org/wiki/University_of_California,_Berkeleyhttp://en.wikipedia.org/wiki/QUEL_query_languageshttp://en.wikipedia.org/wiki/SQL#cite_note-oppel-databases-8http://en.wikipedia.org/wiki/SQL#cite_note-oppel-databases-8http://en.wikipedia.org/wiki/SQL#cite_note-oppel-databases-8http://en.wikipedia.org/wiki/Oracle_Corporationhttp://en.wikipedia.org/wiki/RDBMShttp://en.wikipedia.org/wiki/United_States_Navyhttp://en.wikipedia.org/wiki/United_States_Navyhttp://en.wikipedia.org/wiki/Central_Intelligence_Agencyhttp://en.wikipedia.org/wiki/Federal_government_of_the_United_Stateshttp://en.wikipedia.org/wiki/Oracle_databasehttp://en.wikipedia.org/wiki/VAXhttp://en.wikipedia.org/wiki/System/38http://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_neededhttp://en.wikipedia.org/wiki/System/38http://en.wikipedia.org/wiki/VAXhttp://en.wikipedia.org/wiki/Oracle_databasehttp://en.wikipedia.org/wiki/Federal_government_of_the_United_Stateshttp://en.wikipedia.org/wiki/Central_Intelligence_Agencyhttp://en.wikipedia.org/wiki/United_States_Navyhttp://en.wikipedia.org/wiki/United_States_Navyhttp://en.wikipedia.org/wiki/RDBMShttp://en.wikipedia.org/wiki/Oracle_Corporationhttp://en.wikipedia.org/wiki/SQL#cite_note-oppel-databases-8http://en.wikipedia.org/wiki/QUEL_query_languageshttp://en.wikipedia.org/wiki/University_of_California,_Berkeleyhttp://en.wikipedia.org/wiki/Ingres_(database)http://en.wikipedia.org/wiki/MIThttp://en.wikipedia.org/wiki/Relational_database_management_systemhttp://en.wikipedia.org/wiki/SQL#cite_note-oppel-databases-8http://en.wikipedia.org/wiki/Hawker_Siddeleyhttp://en.wikipedia.org/wiki/United_Kingdomhttp://en.wikipedia.org/wiki/United_Kingdomhttp://en.wikipedia.org/wiki/Trademarkhttp://en.wikipedia.org/wiki/SQL#cite_note-chamberlin-boyce-sequel-7http://en.wikipedia.org/wiki/IBM_Almaden_Research_Centerhttp://en.wikipedia.org/wiki/IBM_Almaden_Research_Centerhttp://en.wikipedia.org/wiki/IBM_System_Rhttp://en.wikipedia.org/w/index.php?title=A._Murphy&action=edit&redlink=1http://en.wikipedia.org/wiki/Donald_D._Chamberlinhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/Vendor_lock-inhttp://en.wikipedia.org/wiki/International_Organization_for_Standardshttp://en.wikipedia.org/wiki/International_Organization_for_Standardshttp://en.wikipedia.org/wiki/American_National_Standards_Institutehttp://en.wikipedia.org/wiki/Technical_standardhttp://en.wikipedia.org/wiki/Procedural_programminghttp://en.wikipedia.org/wiki/Declarative_programminghttp://en.wikipedia.org/wiki/Declarative_programminghttp://en.wikipedia.org/wiki/SQL#cite_note-SQL-Fundamentals-5http://en.wikipedia.org/wiki/SQL#cite_note-SQL-Fundamentals-5http://en.wikipedia.org/wiki/Codd%27s_12_ruleshttp://en.wikipedia.org/wiki/Codd%27s_12_ruleshttp://en.wikipedia.org/wiki/SQL#cite_note-codd-relational-model-4http://en.wikipedia.org/wiki/Relational_modelhttp://en.wikipedia.org/wiki/Relational_modelhttp://en.wikipedia.org/wiki/Edgar_F._Coddhttp://www.webopedia.com/TERM/E/extension.html


12/82

After testing SQL at customer test sites to determine the usefulness and

practicality of the system, IBM began developing commercial products based on

their System R prototype including System/38, SQL/DS, and DB2, which were

commercially available in 1979, 1981, and 1983, respectively.[10]

This chart shows several of the SQL language elements that compose a single

statement.

The SQL language is subdivided into several language elements, including:

Clauses, which are constituent components of statements and queries. (Insome cases, these are optional.)[11]

Expressions, which can produce either scalar values or tables consisting ofcolumns and rows of data.

Predicates, which specify conditions that can be evaluated to SQL three-valued logic (3VL) or Boolean (true/false/unknown) truth values and which

are used to limit the effects of statements and queries, or to changeprogram flow.

Queries, which retrieve the data based on specific criteria. This is the mostimportant element ofSQL.

Statements, which may have a persistent effect on schemata and data, orwhich may control transactions, program flow, connections, sessions, or

diagnostics.

o SQL statements also include the semicolon (";") statementterminator. Though not required on every platform, it is defined as a

standard part of the SQL grammar. Insignificant whitespace is generally ignored in SQL statements and

queries, making it easier to format SQL code for readability.
http://en.wikipedia.org/wiki/SQL/DShttp://en.wikipedia.org/wiki/IBM_DB2http://en.wikipedia.org/wiki/SQL#cite_note-IBM-history-9http://en.wikipedia.org/wiki/SQL#cite_note-IBM-history-9http://en.wikipedia.org/wiki/SQL#cite_note-IBM-history-9http://en.wikipedia.org/wiki/SQL#cite_note-10http://en.wikipedia.org/wiki/SQL#cite_note-10http://en.wikipedia.org/wiki/SQL#cite_note-10http://en.wikipedia.org/wiki/Scalar_(computing)http://en.wikipedia.org/wiki/Table_(database)http://en.wikipedia.org/wiki/Column_(database)http://en.wikipedia.org/wiki/Row_(database)http://en.wikipedia.org/wiki/Ternary_logichttp://en.wikipedia.org/wiki/Ternary_logichttp://en.wikipedia.org/wiki/Boolean_logichttp://en.wikipedia.org/wiki/Truth_valuehttp://en.wikipedia.org/wiki/Semicolonhttp://en.wikipedia.org/wiki/Whitespace_(computer_science)http://en.wikipedia.org/wiki/Whitespace_(computer_science)http://en.wikipedia.org/wiki/File:SQL_ANATOMY_wiki.svghttp://en.wikipedia.org/wiki/File:SQL_ANATOMY_wiki.svghttp://en.wikipedia.org/wiki/File:SQL_ANATOMY_wiki.svghttp://en.wikipedia.org/wiki/File:SQL_ANATOMY_wiki.svghttp://en.wikipedia.org/wiki/Whitespace_(computer_science)http://en.wikipedia.org/wiki/Semicolonhttp://en.wikipedia.org/wiki/Truth_valuehttp://en.wikipedia.org/wiki/Boolean_logichttp://en.wikipedia.org/wiki/Ternary_logichttp://en.wikipedia.org/wiki/Ternary_logichttp://en.wikipedia.org/wiki/Row_(database)http://en.wikipedia.org/wiki/Column_(database)http://en.wikipedia.org/wiki/Table_(database)http://en.wikipedia.org/wiki/Scalar_(computing)http://en.wikipedia.org/wiki/SQL#cite_note-10http://en.wikipedia.org/wiki/SQL#cite_note-IBM-history-9http://en.wikipedia.org/wiki/IBM_DB2http://en.wikipedia.org/wiki/SQL/DS


13/82

[edit] Queries

The most common operation in SQL is the query, which is performed with the

declarative SELECT statement. SELECT retrieves data from one or more tables, or

expressions. Standard SELECT statements have no persistent effects on thedatabase. Some non-standard implementations of SELECT can have persistent

effects, such as the SELECT INTO syntax that exists in some databases.[12]

Queries allow the user to describe desired data, leaving the database

management system (DBMS) responsible for planning, optimizing, and performing

the physical operations necessary to produce that result as it chooses.

A query includes a list of columns to be included in the final result immediately

following the SELECT keyword. An asterisk ("*") can also be used to specify that

the query should return all columns of the queried tables. SELECT is the most

complex statement in SQL, with optional keywords and clauses that include:

The FROM clause which indicates the table(s) from which data is to beretrieved. The FROM clause can include optional JOIN subclauses to specify

the rules for joining tables.

The WHERE clause includes a comparison predicate, which restricts therows returned by the query. The WHERE clause eliminates all rows from the

result set for which the comparison predicate does not evaluate to True.

The GROUP BY clause is used to project rows having common values into asmaller set of rows. GROUP BY is often used in conjunction with SQL

aggregation functions or to eliminate duplicate rows from a result set. The

WHERE clause is applied before the GROUP BY clause.

The HAVING clause includes a predicate used to filter rows resulting fromthe GROUP BY clause. Because it acts on the results of the GROUP BY

clause, aggregation functions can be used in the HAVING clause predicate.

The ORDER BY clause identifies which columns are used to sort theresulting data, and in which direction they should be sorted (options are

ascending or descending). Without an ORDER BY clause, the order of rows

returned by an SQL query is undefined.

The following is an example of a SELECT query that returns a list of expensive

books. The query retrieves all rows from the Booktable in which theprice column

contains a value greater than 100.00. The result is sorted in ascending order by
http://en.wikipedia.org/w/index.php?title=SQL&action=edit&section=2http://en.wikipedia.org/wiki/Select_(SQL)http://en.wikipedia.org/wiki/Table_(database)http://en.wikipedia.org/wiki/SQL#cite_note-ms-sql-select-into-11http://en.wikipedia.org/wiki/SQL#cite_note-ms-sql-select-into-11http://en.wikipedia.org/wiki/SQL#cite_note-ms-sql-select-into-11http://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Query_planhttp://en.wikipedia.org/wiki/Query_optimizerhttp://en.wikipedia.org/wiki/From_(SQL)http://en.wikipedia.org/wiki/Join_(SQL)http://en.wikipedia.org/wiki/Where_(SQL)http://en.wikipedia.org/wiki/Having_(SQL)http://en.wikipedia.org/wiki/Order_by_(SQL)http://en.wikipedia.org/wiki/Order_by_(SQL)http://en.wikipedia.org/wiki/Having_(SQL)http://en.wikipedia.org/wiki/Where_(SQL)http://en.wikipedia.org/wiki/Join_(SQL)http://en.wikipedia.org/wiki/From_(SQL)http://en.wikipedia.org/wiki/Query_optimizerhttp://en.wikipedia.org/wiki/Query_planhttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/SQL#cite_note-ms-sql-select-into-11http://en.wikipedia.org/wiki/Table_(database)http://en.wikipedia.org/wiki/Select_(SQL)http://en.wikipedia.org/w/index.php?title=SQL&action=edit&section=2


14/82

title. The asterisk (*) in the select listindicates that all columns of the Booktable

should be included in the result set.

SELECT *

FROM BookWHERE price > 100.00

ORDER BY title;

The example below demonstrates a query of multiple tables, grouping, and

aggregation, by returning a list of books and the number of authors associated

with each book.

SELECT Book.title,

COUNT(*) AS Authors

FROM Book JOIN Book_author

ON Book.isbn = Book_author.isbn

GROUP BY Book.title;

Example output might resemble the following:

Title Authors

---------------------- -------

SQL Examples and Guide 4

The Joy of SQL 1An Introduction to SQL 2

Pitfalls of SQL 1

Under the precondition that isbn is the only common column name of the two

tables and that a column named title only exists in the Books table, the above

query could be rewritten in the following form:

SELECT title,

COUNT(*) AS AuthorsFROM Book NATURAL JOIN Book_author

GROUP BY title;

However, many vendors either do not support this approach, or require certain

column naming conventions in order for natural joins to work effectively.


15/82

SQL includes operators and functions for calculating values on stored values. SQL

allows the use of expressions in the select listto project data, as in the following

example which returns a list of books that cost more than 100.00 with an

additional sales_taxcolumn containing a sales tax figure calculated at 6% of the

price.

SELECT isbn,

title,

price,

price * 0.06 AS sales_tax

FROM Book

WHERE price > 100.00

ORDER BY title;

[edit] Subqueries

Queries can be nested so that the results of one query can be used in another

query via a relational operator or aggregation function. A nested query is also

known as a subquery. While joins and other table operations provide

computationally superior (i.e. faster) alternatives in many cases, the use of

subqueries introduces a hierarchy in execution which can be useful or necessary.

In the following example, the aggregation function AVG receives as input the

result of a subquery:

SELECT isbn, title, price

FROM Book

WHERE price < AVG(SELECT price FROM Book)

ORDER BY title;

Q5. What is Normalization? Discuss various types of Normal Forms?

Normalization is A process of decomposing tables to eliminate data redundancy

is called Normalization.

1N.F:- The table should caontain scalar or atomic values.

2 N.F:- Table should be in 1N.F + No partial functional dependencies

3 N.F :-Table should be in 2 N.F + No transitive dependencies
http://en.wikipedia.org/w/index.php?title=SQL&action=edit&section=3http://en.wikipedia.org/w/index.php?title=SQL&action=edit&section=3


16/82

The normal forms defined in relational database theory represent guidelines for

record design. The guidelines corresponding to first through fifth normal forms

are presented here, in terms that do not require an understanding of relational

theory. The design guidelines are meaningful even if one is not using a relational

database system. We present the guidelines without referring to the concepts ofthe relational model in order to emphasize their generality, and also to make

them easier to understand. Our presentation conveys an intuitive sense of the

intended constraints on record design, although in its informality it may be

imprecise in some technical details. A comprehensive treatment of the subject is

provided by Date [4].

The normalization rules are designed to prevent update anomalies and data

inconsistencies. With respect to performance tradeoffs, these guidelines are

biased toward the assumption that all non-key fields will be updated frequently.They tend to penalize retrieval, since data which may have been retrievable from

one record in an unnormalized design may have to be retrieved from several

records in the normalized form. There is no obligation to fully normalize all

records when actual performance requirements are taken into account.

2 FIRST NORMAL FORM

First normal form [1] deals with the "shape" of a record type.

Under first normal form, all occurrences of a record type must contain the same

number of fields.

First normal form excludes variable repeating fields and groups. This is not so

much a design guideline as a matter of definition. Relational database theory

doesn't deal with records having a variable number of fields.

3 SECOND AND THIRD NORMAL FORMS

Second and third normal forms [2, 3, 7] deal with the relationship between non-key and key fields.

Under second and third normal forms, a non-key field must provide a fact about

the key, us the whole key, and nothing but the key. In addition, the record must

satisfy first normal form.


17/82

We deal now only with "single-valued" facts. The fact could be a one-to-many

relationship, such as the department of an employee, or a one-to-one

relationship, such as the spouse of an employee. Thus the phrase "Y is a fact

about X" signifies a one-to-one or one-to-many relationship between Y and X. In

the general case, Y might consist of one or more fields, and so might X. In thefollowing example, QUANTITY is a fact about the combination of PART and

WAREHOUSE.

3.1 Second Normal Form

Second normal form is violated when a non-key field is a fact about a subset of a

key. It is only relevant when the key is composite, i.e., consists of several fields.

Consider the following inventory record:

---------------------------------------------------

| PART | WAREHOUSE | QUANTITY | WAREHOUSE-ADDRESS |

====================-------------------------------

The key here consists of the PART and WAREHOUSE fields together, but

WAREHOUSE-ADDRESS is a fact about the WAREHOUSE alone. The basic problems

with this design are:

The warehouse address is repeated in every record that refers to a partstored in that warehouse.

If the address of the warehouse changes, every record referring to a partstored in that warehouse must be updated.

Because of the redundancy, the data might become inconsistent, withdifferent records showing different addresses for the same warehouse.

If at some point in time there are no parts stored in the warehouse, theremay be no record in which to keep the warehouse's address.

To satisfy second normal form, the record shown above should be decomposed

into (replaced by) the two records:

------------------------------- ---------------------------------

| PART | WAREHOUSE | QUANTITY | | WAREHOUSE | WAREHOUSE-ADDRESS |

====================----------- =============--------------------


18/82


19/82

------------------------- -------------------------

| EMPLOYEE | DEPARTMENT | | DEPARTMENT | LOCATION |

============------------- ==============-----------

To summarize, a record is in second and third normal forms if every field is eitherpart of the key or provides a (single-valued) fact about exactly the whole key and

nothing else.

3.3 Functional Dependencies

In relational database theory, second and third normal forms are defined in terms

of functional dependencies, which correspond approximately to our single-valued

facts. A field Y is "functionally dependent" on a field (or fields) X if it is invalid to

have two records with the same X-value but different Y-values. That is, a given X-

value must always occur with the same Y-value. When X is a key, then all fields

are by definition functionally dependent on X in a trivial way, since there can't be

two records having the same X value.

There is a slight technical difference between functional dependencies and single-

valued facts as we have presented them. Functional dependencies only exist

when the things involved have unique and singular identifiers (representations).

For example, suppose a person's address is a single-valued fact, i.e., a person has

only one address. If we don't provide unique identifiers for people, then there will

not be a functional dependency in the data:

----------------------------------------------

| PERSON | ADDRESS |

-------------+--------------------------------

| John Smith | 123 Main St., New York |

| John Smith | 321 Center St., San Francisco |

----------------------------------------------

Although each person has a unique address, a given name can appear withseveral different addresses. Hence we do not have a functional dependency

corresponding to our single-valued fact.

Similarly, the address has to be spelled identically in each occurrence in order to

have a functional dependency. In the following case the same person appears to

be living at two different addresses, again precluding a functional dependency.


20/82

---------------------------------------

| PERSON | ADDRESS |

-------------+-------------------------

| John Smith | 123 Main St., New York |

| John Smith | 123 Main Street, NYC |---------------------------------------

We are not defending the use of non-unique or non-singular representations.

Such practices often lead to data maintenance problems of their own. We do wish

to point out, however, that functional dependencies and the various normal

forms are really only defined for situations in which there are unique and singular

identifiers. Thus the design guidelines as we present them are a bit stronger than

those implied by the formal definitions of the normal forms.

For instance, we as designers know that in the following example there is a single-

valued fact about a non-key field, and hence the design is susceptible to all the

update anomalies mentioned earlier.

----------------------------------------------------------

| EMPLOYEE | FATHER | FATHER'S-ADDRESS |

|============------------+-------------------------------|

| Art Smith | John Smith | 123 Main St., New York |

| Bob Smith | John Smith | 123 Main Street, NYC |

| Cal Smith | John Smith | 321 Center St., San Francisco |

----------------------------------------------------------

However, in formal terms, there is no functional dependency here between

FATHER'S-ADDRESS and FATHER, and hence no violation of third normal form.

4 FOURTH AND FIFTH NORMAL FORMS

Fourth [5] and fifth [6] normal forms deal with multi-valued facts. The multi-

valued fact may correspond to a many-to-many relationship, as with employeesand skills, or to a many-to-one relationship, as with the children of an employee

(assuming only one parent is an employee). By "many-to-many" we mean that an

employee may have several skills, and a skill may belong to several employees.

Note that we look at the many-to-one relationship between children and fathers

as a single-valued fact about a child but a multi-valued fact about a father.


21/82

In a sense, fourth and fifth normal forms are also about composite keys. These

normal forms attempt to minimize the number of fields involved in a composite

key, as suggested by the examples to follow.

4.1 Fourth Normal Form

Under fourth normal form, a record type should not contain two or more

independent multi-valued facts about an entity. In addition, the record must

satisfy third normal form.

The term "independent" will be discussed after considering an example.

Consider employees, skills, and languages, where an employee may have several

skills and several languages. We have here two many-to-many relationships, one

between employees and skills, and one between employees and languages.Under fourth normal form, these two relationships should not be represented in a

single record such as

-------------------------------

| EMPLOYEE | SKILL | LANGUAGE |

===============================

Instead, they should be represented in the two records

-------------------- -----------------------

| EMPLOYEE | SKILL | | EMPLOYEE | LANGUAGE |

==================== =======================

Note that other fields, not involving multi-valued facts, are permitted to occur in

the record, as in the case of the QUANTITY field in the earlier PART/WAREHOUSE

example.

The main problem with violating fourth normal form is that it leads to

uncertainties in the maintenance policies. Several policies are possible for

maintaining two independent multi-valued facts in one record:

(1) A disjoint format, in which a record contains either a skill or a language, but

not both:


22/82

-------------------------------


|----------+-------+----------|

| Smith | cook | |

| Smith | type | || Smith | | French |

| Smith | | German |

| Smith | | Greek |

-------------------------------

This is not much different from maintaining two separate record types. (We note

in passing that such a format also leads to ambiguities regarding the meanings of

blank fields. A blank SKILL could mean the person has no skill, or the field is not

applicable to this employee, or the data is unknown, or, as in this case, the datamay be found in another record.)

(2) A random mix, with three variations:

(a) Minimal number of records, with repetitions:

-------------------------------


|----------+-------+----------|

| Smith | cook | French || Smith | type | German |

| Smith | type | Greek |

-------------------------------

(b) Minimal number of records, with null values:

-------------------------------


|----------+-------+----------|| Smith | cook | French |

| Smith | type | German |

| Smith | | Greek |

-------------------------------

(c) Unrestricted:


23/82

-------------------------------


|----------+-------+----------|

| Smith | cook | French |

| Smith | type | || Smith | | German |


-------------------------------

(3) A "cross-product" form, where for each employee, there must be a record for

every possible pairing of one of his skills with one of his languages:

-------------------------------


|----------+-------+----------|


| Smith | cook | German |

| Smith | cook | Greek |

| Smith | type | French |



-------------------------------

Other problems caused by violating fourth normal form are similar in spirit to

those mentioned earlier for violations of second or third normal form. They take

different variations depending on the chosen maintenance policy:

If there are repetitions, then updates have to be done in multiple records,and they could become inconsistent.

Insertion of a new skill may involve looking for a record with a blank skill, orinserting a new record with a possibly blank language, or inserting multiple

records pairing the new skill with some or all of the languages.

Deletion of a skill may involve blanking out the skill field in one or morerecords (perhaps with a check that this doesn't leave two records with the

same language and a blank skill), or deleting one or more records, coupled

with a check that the last mention of some language hasn't also been

deleted.


24/82

Fourth normal form minimizes such update problems.

4.1.1 Independence

We mentioned independent multi-valued facts earlier, and we now illustrate

what we mean in terms of the example. The two many-to-many relationships,

employee:skill and employee:language, are "independent" in that there is no

direct connection between skills and languages. There is only an indirect

connection because they belong to some common employee. That is, it does not

matter which skill is paired with which language in a record; the pairing does not

convey any information. That's precisely why all the maintenance policies

mentioned earlier can be allowed.

In contrast, suppose that an employee could only exercise certain skills in certain

languages. Perhaps Smith can cook French cuisine only, but can type in French,

German, and Greek. Then the pairings of skills and languages becomes

meaningful, and there is no longer an ambiguity of maintenance policies. In the

present case, only the following form is correct:

-------------------------------


|----------+-------+----------|


| Smith | type | French |



-------------------------------

Thus the employee:skill and employee:language relationships are no longer

independent. These records do not violate fourth normal form. When there is an

interdependence among the relationships, then it is acceptable to represent them

in a single record.

4.1.2 Multivalued Dependencies

For readers interested in pursuing the technical background of fourth normal

form a bit further, we mention that fourth normal form is defined in terms of

multivalued dependencies, which correspond to our independent multi-valued


25/82

facts. Multivalued dependencies, in turn, are defined essentially as relationships

which accept the "cross-product" maintenance policy mentioned above. That is,

for our example, every one of an employee's skills must appear paired with every

one of his languages. It may or may not be obvious to the reader that this is

equivalent to our notion of independence: since every possible pairing must bepresent, there is no "information" in the pairings. Such pairings convey

information only if some of them can be absent, that is, only if it is possible that

some employee cannot perform some skill in some language. If all pairings are

always present, then the relationships are really independent.

We should also point out that multivalued dependencies and fourth normal form

apply as well to relationships involving more than two fields. For example,

suppose we extend the earlier example to include projects, in the following sense:

An employee uses certain skills on certain projects. An employee uses certain languages on certain projects.

If there is no direct connection between the skills and languages that an

employee uses on a project, then we could treat this as two independent many-

to-many relationships of the form EP:S and EP:L, where "EP" represents a

combination of an employee with a project. A record including employee, project,

skill, and language would violate fourth normal form. Two records, containing

fields E,P,S and E,P,L, respectively, would satisfy fourth normal form.

4.2 Fifth Normal Form

Fifth normal form deals with cases where information can be reconstructed from

smaller pieces of information that can be maintained with less redundancy.

Second, third, and fourth normal forms also serve this purpose, but fifth normal

form generalizes to cases not covered by the others.

We will not attempt a comprehensive exposition of fifth normal form, but

illustrate the central concept with a commonly used example, namely oneinvolving agents, companies, and products. If agents represent companies,

companies make products, and agents sell products, then we might want to keep

a record of which agent sells which product for which company. This information

could be kept in one record type with three fields:

-----------------------------


26/82

| AGENT | COMPANY | PRODUCT |

|-------+---------+---------|

| Smith | Ford | car |

| Smith | GM | truck |

-----------------------------

This form is necessary in the general case. For example, although agent Smith

sells cars made by Ford and trucks made by GM, he does not sell Ford trucks or

GM cars. Thus we need the combination of three fields to know which

combinations are valid and which are not.

But suppose that a certain rule was in effect: if an agent sells a certain product,

and he represents a company making that product, then he sells that product for

that company.

-----------------------------

| AGENT | COMPANY | PRODUCT |

|-------+---------+---------|


| Smith | Ford | truck |

| Smith | GM | car |


| Jones | Ford | car |

-----------------------------

In this case, it turns out that we can reconstruct all the true facts from a

normalized form consisting of three separate record types, each containing two

fields:

------------------- --------------------- -------------------

| AGENT | COMPANY | | COMPANY | PRODUCT | | AGENT | PRODUCT |

|-------+---------| |---------+---------| |-------+---------|

| Smith | Ford | | Ford | car | | Smith | car || Smith | GM | | Ford | truck | | Smith | truck |

| Jones | Ford | | GM | car | | Jones | car |

------------------- | GM | truck | -------------------

---------------------


27/82

These three record types are in fifth normal form, whereas the corresponding

three-field record shown previously is not.

Roughly speaking, we may say that a record type is in fifth normal form when its

information content cannot be reconstructed from several smaller record types,i.e., from record types each having fewer fields than the original record. The case

where all the smaller records have the same key is excluded. If a record type can

only be decomposed into smaller records which all have the same key, then the

record type is considered to be in fifth normal form without decomposition. A

record type in fifth normal form is also in fourth, third, second, and first normal

forms.

Fifth normal form does not differ from fourth normal form unless there exists a

symmetric constraint such as the rule about agents, companies, and products. In

the absence of such a constraint, a record type in fourth normal form is always in

fifth normal form.

One advantage of fifth normal form is that certain redundancies can be

eliminated. In the normalized form, the fact that Smith sells cars is recorded only

once; in the unnormalized form it may be repeated many times.

It should be observed that although the normalized form involves more record

types, there may be fewer total record occurrences. This is not apparent when

there are only a few facts to record, as in the example shown above. Theadvantage is realized as more facts are recorded, since the size of the normalized

files increases in an additive fashion, while the size of the unnormalized file

increases in a multiplicative fashion. For example, if we add a new agent who sells

x products for y companies, where each of these companies makes each of these

products, we have to add x+y new records to the normalized form, but xy new

records to the unnormalized form.

It should be noted that all three record types are required in the normalized form

in order to reconstruct the same information. From the first two record typesshown above we learn that Jones represents Ford and that Ford makes trucks. But

we can't determine whether Jones sells Ford trucks until we look at the third

record type to determine whether Jones sells trucks at all.

The following example illustrates a case in which the rule about agents,

companies, and products is satisfied, and which clearly requires all three record


28/82

types in the normalized form. Any two of the record types taken alone will imply

something untrue.

-----------------------------

| AGENT | COMPANY | PRODUCT ||-------+---------+---------|


| Smith | Ford | truck |

| Smith | GM | car |


| Jones | Ford | car |

| Jones | Ford | truck |

| Brown | Ford | car |

| Brown | GM | car || Brown | Totota | car |

| Brown | Totota | bus |

-----------------------------

------------------- --------------------- -------------------

| AGENT | COMPANY | | COMPANY | PRODUCT | | AGENT | PRODUCT |

|-------+---------| |---------+---------| |-------+---------|

| Smith | Ford | | Ford | car | | Smith | car | Fifth

| Smith | GM | | Ford | truck | | Smith | truck | Normal

| Jones | Ford | | GM | car | | Jones | car | Form| Brown | Ford | | GM | truck | | Jones | truck |

| Brown | GM | | Toyota | car | | Brown | car |

| Brown | Toyota | | Toyota | bus | | Brown | bus |

------------------- --------------------- -------------------

Observe that:

Jones sells cars and GM makes cars, but Jones does not represent GM. Brown represents Ford and Ford makes trucks, but Brown does not sell

trucks.

Brown represents Ford and Brown sells buses, but Ford does not makebuses.

Fourth and fifth normal forms both deal with combinations of multivalued facts.

One difference is that the facts dealt with under fifth normal form are not


29/82

independent, in the sense discussed earlier. Another difference is that, although

fourth normal form can deal with more than two multivalued facts, it only

recognizes them in pairwise groups. We can best explain this in terms of the

normalization process implied by fourth normal form. If a record violates fourth

normal form, the associated normalization process decomposes it into tworecords, each containing fewer fields than the original record. Any of these

violating fourth normal form is again decomposed into two records, and so on

until the resulting records are all in fourth normal form. At each stage, the set of

records after decomposition contains exactly the same information as the set of

records before decomposition.

In the present example, no pairwise decomposition is possible. There is no

combination of two smaller records which contains the same total information as

the original record. All three of the smaller records are needed. Hence aninformation-preserving pairwise decomposition is not possible, and the original

record is not in violation of fourth normal form. Fifth normal form is needed in

order to deal with the redundancies in this case.

5 UNAVOIDABLE REDUNDANCIES

Normalization certainly doesn't remove all redundancies. Certain redundancies

seem to be unavoidable, particularly when several multivalued facts are

dependent rather than independent. In the example shown Section 4.1.1, it

seems unavoidable that we record the fact that "Smith can type" several times.

Also, when the rule about agents, companies, and products is not in effect, it

seems unavoidable that we record the fact that "Smith sells cars" several times.

6 INTER-RECORD REDUNDANCY

The normal forms discussed here deal only with redundancies occurring within a

single record type. Fifth normal form is considered to be the "ultimate" normal

form with respect to such redundancies.

Other redundancies can occur across multiple record types. For the example

concerning employees, departments, and locations, the following records are in

third normal form in spite of the obvious redundancy:

------------------------- -------------------------
http://www.bkent.net/Doc/simple5.htm#label4.1.1http://www.bkent.net/Doc/simple5.htm#label4.1.1


30/82

| EMPLOYEE | DEPARTMENT | | DEPARTMENT | LOCATION |

============------------- ==============-----------

-----------------------

| EMPLOYEE | LOCATION |

============-----------

In fact, two copies of the same record type would constitute the ultimate in this

kind of undetected redundancy.

Inter-record redundancy has been recognized for some time [1], and has recently

been addressed in terms of normal forms and normalization [8].

7 CONCLUSION

While we have tried to present the normal forms in a simple and understandableway, we are by no means suggesting that the data design process is

correspondingly simple. The design process involves many complexities which are

quite beyond the scope of this paper. In the first place, an initial set of data

elements and records has to be developed, as candidates for normalization. Then

the factors affecting normalization have to be assessed:

Single-valued vs. multi-valued facts. Dependency on the entire key. Independent vs. dependent facts. The presence of mutual constraints. The presence of non-unique or non-singular representations.

Q6. What do you mean by Shared Lock & Exclusive lock? Describe briefly two

phase locking protocol?

A database is the huge collection of data that is stored into it in form of tables.

This data is very important for the companies who use those databases as anyloss or misuse of this data can put both the company and customers into trouble.

In order to avoid this situation and protect the customers, database developing

companies provide much security featured with their database products; one of

them is Locking system to maintain the integrity of database. There are two types

of lock available with database system, these are:
http://www.blurtit.com/q144771.htmlhttp://www.blurtit.com/q144771.html


31/82

1) Shared Lock: is provided to the readers of the data. These locks enable all the

users to read the concurrent data at the same time, but they are not allowed to

change/ write the data or obtain exclusive lock on the object. It could be set for

table or table row. Lock is released or unlocked at the end of transaction.

2) Exclusive Lock: is provided to the writers of the data. When this lock is set on a

object or transaction, it means that only writer, who has set the lock can change

the data, and if other users cannot access the locked object. Lock is released at

the end of change in transaction. Can be set on Tables or rows.

Exclusive locks

Exclusive locks protect updates to file resources, both recoverable and non-

recoverable. They can be owned by only one transaction at a time. Anytransaction that requires an exclusive lock must wait if another task currently

owns an exclusive lock or a shared lock against the requested resource.

Shared locks

Shared locks support read integrity. They ensure that a record is not in the

process of being updated during a read-only request. Shared locks can also be

used to prevent updates of a record between the time that a record is read and

the next syncpoint.

A shared lock on a resource can be owned by several tasks at the same time.

However, although several tasks can own shared locks, there are some

circumstances in which tasks can be forced to wait for a lock:

A request for a shared lock must wait if another task currently owns anexclusive lock on the resource.

A request for an exclusive lock must wait if other tasks currently own sharedlocks on this resource.

A new request for a shared lock must wait if another task is waiting for anexclusive lock on a resource that already has a shared lock.


32/82

In databases and transaction processing,two-phase locking (2PL) is a concurrency

control method that guarantees serializability.[1][2] It is also the name of the

resulting set of database transaction schedules (histories). The protocol utilizeslocks, applied by a transaction to data, which may block (interpreted as signals to

stop) other transactions from accessing the same data during the transaction's

life.

By the 2PL protocol locks are applied and removed in two phases:

1. Expanding phase: locks are acquired and no locks are released.2. Shrinking phase: locks are released and no locks are acquired.

Two types of locks are utilized by the basic protocol: Sharedand Exclusive locks.Refinements of the basic protocol may utilize more lock types. Using locks that

block processes, 2PL may be subject to deadlocks that result from the mutual

blocking of two or more transactions.

2PL is a superset of strong strict two-phase locking (SS2PL),[3]

also called

rigorousness,[4]which has been widely utilized for concurrency control in general-

purpose database systems since the 1970s. SS2PL implementations have many

variants. SS2PL was called strict 2PL[1]but this name usage is not recommended

now. Now strict 2PL (S2PL) is the intersection of strictness and 2PL, which isdifferent from SS2PL. SS2PL is also a special case ofcommitment ordering,[3]and

inherits many of CO's useful properties. SS2PL actually comprises only one phase:

phase-2 does not exist, and all locks are released only after transaction end. Thus

this useful 2PL type is not two-phased at all.

Neither 2PL nor S2PL in their general forms are known to be used in practice. Thus

2PL by itself does not seem to have much practical importance, and whenever 2PL

or S2PL utilization has been mentioned in the literature, the intention has been

SS2PL. What has made SS2PL so popular (probably the most utilized serializabilitymechanism) is the effective and efficient locking-based combination of two

ingredients (the first does not exist in both general 2PL and S2PL; the second does

not exist in general 2PL):

1. Commitment ordering, which provides both serializability, and effectivedistributed serializability and global serializability, and
http://en.wikipedia.org/wiki/Databasehttp://en.wikipedia.org/wiki/Transaction_processinghttp://en.wikipedia.org/wiki/Concurrency_controlhttp://en.wikipedia.org/wiki/Concurrency_controlhttp://en.wikipedia.org/wiki/Serializabilityhttp://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Bern1987-0http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Bern1987-0http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Bern1987-0http://en.wikipedia.org/wiki/Database_transactionhttp://en.wikipedia.org/wiki/Schedule_(computer_science)http://en.wikipedia.org/wiki/Lock_(computer_science)http://en.wikipedia.org/wiki/Deadlockhttp://en.wikipedia.org/wiki/Supersethttp://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Raz1992-2http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Raz1992-2http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Raz1992-2http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Breit1991-3http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Breit1991-3http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Breit1991-3http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Bern1987-0http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Bern1987-0http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Bern1987-0http://en.wikipedia.org/wiki/Schedule_(computer_science)#Stricthttp://en.wikipedia.org/wiki/Special_casehttp://en.wikipedia.org/wiki/Commitment_orderinghttp://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Raz1992-2http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Raz1992-2http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Raz1992-2http://en.wikipedia.org/wiki/Global_serializability#The_commitment_ordering_solutionhttp://en.wikipedia.org/wiki/Serializabilityhttp://en.wikipedia.org/wiki/Commitment_orderinghttp://en.wikipedia.org/wiki/Serializabilityhttp://en.wikipedia.org/wiki/Serializability#Distributed_serializabilityhttp://en.wikipedia.org/wiki/Global_serializabilityhttp://en.wikipedia.org/wiki/Global_serializabilityhttp://en.wikipedia.org/wiki/Serializability#Distributed_serializabilityhttp://en.wikipedia.org/wiki/Serializabilityhttp://en.wikipedia.org/wiki/Commitment_orderinghttp://en.wikipedia.org/wiki/Serializabilityhttp://en.wikipedia.org/wiki/Global_serializability#The_commitment_ordering_solutionhttp://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Raz1992-2http://en.wikipedia.org/wiki/Commitment_orderinghttp://en.wikipedia.org/wiki/Special_casehttp://en.wikipedia.org/wiki/Schedule_(computer_science)#Stricthttp://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Bern1987-0http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Breit1991-3http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Raz1992-2http://en.wikipedia.org/wiki/Supersethttp://en.wikipedia.org/wiki/Deadlockhttp://en.wikipedia.org/wiki/Lock_(computer_science)http://en.wikipedia.org/wiki/Schedule_(computer_science)http://en.wikipedia.org/wiki/Database_transactionhttp://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Bern1987-0http://en.wikipedia.org/wiki/Two-phase_locking#cite_note-Bern1987-0http://en.wikipedia.org/wiki/Serializabilityhttp://en.wikipedia.org/wiki/Concurrency_controlhttp://en.wikipedia.org/wiki/Concurrency_controlhttp://en.wikipedia.org/wiki/Transaction_processinghttp://en.wikipedia.org/wiki/Database


33/82

2. Strictness, which provides cascadelessness (ACA, cascade-lessrecoverability) and (independently) allows efficient database recovery from

failure.

Additionally SS2PL is easier, with less overhead to implement than both 2PL andS2PL, provides exactly same locking, but sometimes releases locks later. However,

practically (though not simplistically theoretically) such later lock release occurs

only slightly later, and this apparent disadvantage is insignificant and disappears

next to the advantages of SS2PL.
http://en.wikipedia.org/wiki/Schedule_(computer_science)#Stricthttp://en.wikipedia.org/wiki/Serializability#Correctness_-_recoverabilityhttp://en.wikipedia.org/wiki/Data_recoveryhttp://en.wikipedia.org/wiki/Data_recoveryhttp://en.wikipedia.org/wiki/Serializability#Correctness_-_recoverabilityhttp://en.wikipedia.org/wiki/Schedule_(computer_science)#Strict


34/82

Master of Business Administration - MBA Semester III

MI0034 Database Management System - 4 Credits

Assignment - Set- 2 (60 Marks)

Answer all the Questions

Q1. Define Data Model & discuss the categories of Data Models? What is thedifference between logical data Independence & Physical Data Independence?

A data model is a picture or description which depicts how data is to be arranged

to serve a specific purpose. The data model depicts what that data items are

required, and how that data must look. However it would be misleading to discuss

data models as if there were only one kind of data model, and equally misleading

to discuss them as if they were used for only one purpose. It would also be

misleading to assume that data models were only used in the construction of datafiles.

Some data models are schematics which depict the manner in which data records

are connected or related within a file structure. These are called record or

structural data models. Some data models are used to identify the subjects of

corporate data processing - these are called entity-relationship data models. Still

another type of data model is used for analytic purposes to help the analyst to

solidify the semantics associated with critical corporate or business concepts.

The record data model

The record version of the data model is used to assist the implementation team

by providing a series of schematics of the file that will contain the data that must

be built to support the business processing procedures. When the design team

has chosen a file management system, or when corporate policy dictates that a

specific data management system, these models may be the only models

produced within the context of a design project. If no such choice has been made,

they may be produced after first developing a more general, non-DBMS specific

entity relationship data model.

Early data models
http://www.martymodell.com/dadmc/dadmc07.htmlhttp://www.martymodell.com/dadmc/dadmc07.htmlhttp://www.martymodell.com/dadmc/dadmc07.htmlhttp://www.martymodell.com/dadmc/dadmc07.html


35/82

Although the term data modeling has become popular only in recent years, in fact

modeling of data has been going on for quite a long time. It is difficult for any of

us to pinpoint exactly when the first data model was constructed because each of

us has a different idea of what a data model is. If we go back to the definition we

set forth earlier, then we can say that perhaps the earliest form of data modelingwas practiced by the first persons who created paper forms for collecting large

amounts of similar data. We can see current versions of these forms everywhere

we look. Every time we fill out an application, buy something, make a request on

using anything other than a blank piece of paper or stationary, we are using a

form of data model.

These forms were designed to collect specific kinds of information, in specific

format. The very definition of the word form confirms this.

A definition

A form is the shape and structure of something as distinguished from its

substance. A form is a document with blanks for the insertion of details or

information.

Almost all businesses and in fact almost all organization use forms of every sort to

gather and store information.

Data Management Systems

Until the introduction of data management systems (and data base management

systems) data modeling and data layout were synonymous. With one notable

exception data files were collections of identically formatted records. That

exception was a concept introduced in card records - the multi-format-card set, or

master detail set. This form of card record layout within a file allowed for

repeating sets of data within specific a larger record concept - the so-called logical

record (to distinguish it from the physical record). This form was used most

frequently when designing files to contain records of orders, where each order

could have certain data which was common to the whole order (the master) and

individual, repetitive records for each order line item (the details). This method of

file design employed record fragmentation rather than record consolidation.
http://www.martymodell.com/dadmc/dadmc07.htmlhttp://www.martymodell.com/dadmc/dadmc07.htmlhttp://www.martymodell.com/dadmc/dadmc07.htmlhttp://www.martymodell.com/dadmc/dadmc07.html


36/82

To facilitate processing of these multi-format record files, designers used record

codes to identify records with different layouts and redundant data to permit

these records to be collected (or tied) together in sequence for processing.

Because these files were difficult to process, the layout of these records, and the

identification and placement of the control and redundant identifier data fieldshad to be carefully planned. The planning and coordination associated with these

kinds of files constituted the first instances of data modeling.

The concepts associated with these kinds of files were transferred to magnetic

media and expanded by vendors who experimented with the substitution of

physical record addresses for the redundant data. This use of physical record

addresses coupled with various techniques for combining records of varying

lengths and formats gave rise to products which allowed for the construction of

complex files containing multiple format records tied together in complexpatterns to support business processing requirements.

These patterns were relatively difficult to visualize and schematics were devised

to portray them. These schematics were also called data models because they

modeled how the data was to be viewed. Because the schematics were based on

the manner in which the records were physically tied together, and thus logically

accessed, rather than how they were physically arranged on the direct access

device, they were in reality data file structure models, or data record structure

models. Over time the qualifications to these names became lost and they

became simply known as data models.

Whereas previously data was collected into large somewhat haphazardly

constructed records for processing, these new data management systems allowed

data to be separated into smaller, more focused records which could be tied

together to form a larger record by the data management system. The this

capability forced designers to look at data in different ways.

Data management models

The data management systems (also called data base management systems)

introduced several new ways of organizing data. That is they introduced several

new ways of linking record fragments (or segments) together to form larger

records for processing. Although many different methods were tried, only three


37/82

major methods became popular: the hierarchic method, the network method,

and the newest, the relational method.

Each of these methods reflected the manner in which the vendor constructed and

physically managed data within the file. The systems designer and theprogrammer had to understand these methods so that they could retrieve and

process the data in the files. These models depicted the way the record fragments

were tied to each other and thus the manner in which the chain of pointers had

to be followed to retrieved the fragments in the correct order.

Each vendor introduced a structural model to depict how the data was organized

and tied together. These models also depicted what options were chosen to be

implemented by the development team, data record dependencies, data record

occurrence frequencies, and the sequence in which data records had to be

accessed - also called the navigation sequence.

The hierarchic model

The hierarchic model (figure 7-1) is used to describe those record structures in

which the various physical records which make up the logical record are tied

together in a sequence which looks like an inverted tree. At the top of the

structure is a single record. Beneath that are one or more records each of which

can occur one or more times. Each of these can in turn have multiple records

beneath them. In diagrammatic form the top to bottom set of records looks like ainverted tree or a pyramid of records. To access the set of records associated with

the identifier one started at the top record and followed the pointers from record

to record.


38/82

The various records in the lower part of the structure are accessed by first

accessing the records above them and then following the chain of pointers to the

records at the next lower level. The records at any given level are referred to as

the parent records and the records at the next lower level that are connected to

it, or dependent on it are referred to as its children or the child records. There canbe any number of records at any level, and each record can have any number of

children. Each occurrence of the structure normally represent the collection of

data about a single subject. This parent-child repetition can be repeated through

several levels.


39/82

The data model for this type of structural representation usually depicts each

segment or record fragment only once and uses lines to show the connection

between a parent record and its children. This depiction of record types and lines

connecting them looks like an inverted tree or an organizational hierarchy chart.

Each file is said to consist of a number of repetitions of this tree structure.

Although the data model depicts all possible records types within a structure, in

any given occurrence, record types may or may not be present. Each occurrence

of the structure represents a specific subject occurrence an is identified by a

unique identifier in the single, topmost record type (the root record).

Designers employing this type of data management system would have to

develop a unique record hierarchy for each data storage subject. A given

application may have several different hierarchies, each representing data about

a different subject, associated with it and a company may have several dozen

different hierarchies of record types as components of its data model. A

characteristic of this type of model is that each hierarchy is normally treated as

separate and distinct from the other hierarchies, and various hierarchies can be

mixed and matched to suit the data needs of the particular application.

The network model

The network data model (figure 7-2) has no implicit hierarchic relationship

between the various records, and in many cases no implicit structure at all, withthe records seemingly placed at random. The network model does not make a

clear distinction between subjects mingling all record types in an overall

schematic. The network model may have many different records containing

unique identifiers, each of which acts as an entry point into the record structure.

Record types are grouped into sets of two, one or both of which can in turn be

part of another set of two record types. Within a given set, one record type is said

to be the owner record and one is said to be the member record. Access to a set

is always accomplished by first locating the specific owner record and then

following the chain of pointers to the member records of the set. The networkcan be traversed or navigated by moving from set to set. Various different data

structures can be constructed by selecting sets of records and excluding others.


40/82

Each record type is depicted only once in this type of data model and the

relationship between record types is indicated by a line between them. The line

joining the two records contains the name of the set. Within a set a record can

have only one owner, but multiple owner member sets can be constructed using

the same two record types

The network model has no explicit hierarchy and no explicit entry point. Whereas

the hierarchic model has several different hierarchies structures, the network

model employs a single master network or model, which when completed looks


41/82

like a web of records. As new data is required, records are added to the network

and joined to existing sets.

The relational model

The relational model (figure 7-3), unlike the network or the hierarchic models did

not rely on pointers to connect and chose to view individual records in sets

regardless of the subject occurrence they were associated with. This is in contrast

to the other models which sought to depict the relationships between record

types. In the network model records are portrayed as residing in tables with no

physical pointer between these tables. Each table is thus portrayed independently

from each other table. This made the data model itself a model of simplicity, but

it in turn made the visualiz

ans mi0034 databasemanagementsystem sda 2012 ii 130213070828 phpapp02 (1)

Documents