database management system - jaipur national universityjnujprdistance.com/assets/lms/lms jnu/mca/sem...

Database Management System

Board of Studies

Prof. H. N. Verma Prof. M. K. GhadoliyaVice- Chancellor Director, Jaipur National University, Jaipur School of Distance Education and Learning Jaipur National University, JaipurDr. Rajendra Takale Prof. and Head AcademicsSBPIM, Pune

___________________________________________________________________________________________

Subject Expert Panel

Dr. Ramchandra G. Pawar Ashwini PanditDirector, SIBACA, Lonavala Subject Matter ExpertPune

___________________________________________________________________________________________

Content Review Panel

Gaurav Modi Shubhada PawarSubject Matter Expert Subject Matter Expert

___________________________________________________________________________________________Copyright ©

This book contains the course content for Database Management System.

First Edition 2013

Printed byUniversal Training Solutions Private Limited

Address05th Floor, I-Space, Bavdhan, Pune 411021.

All rights reserved. This book or any portion thereof may not, in any form or by any means including electronic or mechanical or photocopying or recording, be reproduced or distributed or transmitted or stored in a retrieval system or be broadcasted or transmitted.

___________________________________________________________________________________________

I

Index

ContentI. ...................................................................... II

List of FiguresII. ..........................................................VI

List of TablesIII. ......................................................... VII

AbbreviationsIV. ......................................................VIII

Case StudyV. .............................................................. 138

BibliographyVI. ......................................................... 146

Self Assessment AnswersVII. ................................... 149

Book at a Glance

II

Contents

Chapter I ....................................................................................................................................................... 1Database Management System ................................................................................................................... 1Aim ................................................................................................................................................................ 1Objectives ...................................................................................................................................................... 1Learning outcome .......................................................................................................................................... 11.1 Database: An Introduction ....................................................................................................................... 21.2 Conventional File Oriented System ......................................................................................................... 2 1.2.1 Disadvantages of Conventional File Oriented System ............................................................ 21.3 Database Organisation ............................................................................................................................. 31.4 Basic Components of DBMS ................................................................................................................... 41.5 Advantages and Disadvantages of DBMS ............................................................................................... 51.6 Database Design ....................................................................................................................................... 6 1.6.1 Design Process ......................................................................................................................... 7 1.6.2 Advantages of Developing a Database Designing Model ....................................................... 7Summary ....................................................................................................................................................... 8References ..................................................................................................................................................... 8Recommended Reading ............................................................................................................................... 8Self Assessment ............................................................................................................................................. 9

Chapter II ....................................................................................................................................................11Data Modelling ............................................................................................................................................11Aim ...............................................................................................................................................................11Objectives .....................................................................................................................................................11Learning outcome .........................................................................................................................................112.1 Introduction to Database Modelling ...................................................................................................... 122.2 Types of Data Models ............................................................................................................................ 12 2.2.1 Record Based Data Modelling ............................................................................................... 12 2.2.1.1 Hierarchical Data Model ......................................................................................... 12 2.2.1.2 Network Data Model ............................................................................................... 13 2.2.1.3 Relational Data Models ........................................................................................... 142.3 Object Based Data Model ...................................................................................................................... 15Summary ..................................................................................................................................................... 17References ................................................................................................................................................... 17Recommended Reading ............................................................................................................................. 17Self Assessment ........................................................................................................................................... 18

Chapter III .................................................................................................................................................. 20Introduction to Relational Database Management Systems .................................................................. 20Aim .............................................................................................................................................................. 20Objectives .................................................................................................................................................... 20Learning outcome ........................................................................................................................................ 203.1 Relational Database Management System ............................................................................................. 213.2 The Relational Data Structure ................................................................................................................ 223.3 Keys ....................................................................................................................................................... 233.4 Constraints ............................................................................................................................................. 25 3.4.1 Domain Constraints ............................................................................................................... 26 3.4.2 Entity Integrity Constraint ..................................................................................................... 26 3.4.3 Referential Integrity ............................................................................................................... 27 3.4.4 Operational Constraints ......................................................................................................... 283.5 Codd’s 12 Rules ..................................................................................................................................... 28Summary .................................................................................................................................................... 31References ................................................................................................................................................... 31Recommended Reading ............................................................................................................................. 32Self Assessment .......................................................................................................................................... 33

III

Chapter IV .................................................................................................................................................. 35Relational Database Management Systems and Normalisation ............................................................ 35Aim .............................................................................................................................................................. 35Objectives ................................................................................................................................................... 35Learning outcome ........................................................................................................................................ 354.1 Relational Database Design ................................................................................................................... 364.2 Key Constraints ...................................................................................................................................... 374.3 Introduction to Normalisation ................................................................................................................ 38 4.3.1 Problems Addressed by Normalisation .................................................................................. 384.4 Normal Forms ....................................................................................................................................... 39 4.4.1 First Normal Form (INF) ....................................................................................................... 39 4.4.2 Second Normal Form (2NF) .................................................................................................. 40 4.4.3 Third Normal Form ............................................................................................................... 42 4.4.4 Boyce-Codd Normal Form .................................................................................................... 43 4.4.5 Fourth Normal Form (4NF) .................................................................................................. 45Summary .................................................................................................................................................... 47References ................................................................................................................................................... 47Recommended Reading ............................................................................................................................. 48Self Assessment ........................................................................................................................................... 49

Chapter V .................................................................................................................................................... 51Database Design and Entity-Relationship Modelling ............................................................................ 51Aim .............................................................................................................................................................. 51Objectives .................................................................................................................................................... 51Learning outcome ........................................................................................................................................ 515.1 Introduction of Design Process .............................................................................................................. 52 5.1.1 Design Process ....................................................................................................................... 52 5.1.2 Design Alternatives ................................................................................................................ 545.2 The Entity-Relationship Model .............................................................................................................. 545.3 Components of an E-R Model ............................................................................................................... 56 5.3.1 Entities and Entity Sets .......................................................................................................... 56 5.3.2 Attributes ................................................................................................................................ 575.4 Entity-Relationship Diagram ................................................................................................................. 58 5.4.1 Relationships and Relationship Sets ...................................................................................... 59 5.4.2 Terms Associated With Entities and Relationships ................................................................ 60 5.4.3 Other Styles of ER Diagram .................................................................................................. 655.5 Roles in ER Diagrams ............................................................................................................................ 655.6 Generalisation ........................................................................................................................................ 665.7 Aggregation ............................................................................................................................................ 66Summary .................................................................................................................................................... 69References ................................................................................................................................................... 69Recommended Reading ............................................................................................................................. 70Self Assessment ........................................................................................................................................... 71

Chapter VI .................................................................................................................................................. 73SQL: Queries and Subqueries .................................................................................................................. 73Aim .............................................................................................................................................................. 73Objectives .................................................................................................................................................... 73Learning outcome ........................................................................................................................................ 736.1 Introduction to SQL .............................................................................................................................. 746.2 SQL Data Types ..................................................................................................................................... 746.3 Clauses in SQL ....................................................................................................................................... 756.4 Types of Functions ................................................................................................................................. 826.5 Joining Tables ........................................................................................................................................ 856.6 Subqueries .............................................................................................................................................. 88

IV

6.6.1 Predicate Subqueries .............................................................................................................. 88 6.6.2 Quantified Subqueries ............................................................................................................ 89 6.6.3 Scalar Subqueries ................................................................................................................... 90 6.6.4 Correlated Subqueries ............................................................................................................ 91 6.6.5 Table Subqueries .................................................................................................................... 916.7 Grouping Queries ................................................................................................................................... 926.8 Union Queries ........................................................................................................................................ 946.9 SQL Data Manipulation Language (DML) ............................................................................................ 956.10 Data Definition Language (DDL) ........................................................................................................ 956.11 Views .................................................................................................................................................... 96 6.11.1 Updating a View ................................................................................................................... 97 6.11.2 SQL Dropping a View .......................................................................................................... 97Summary .................................................................................................................................................... 98References .................................................................................................................................................. 98Recommended Reading ............................................................................................................................. 99Self Assessment ......................................................................................................................................... 100

Chapter 7 .................................................................................................................................................. 102Database Security and Integrity ............................................................................................................. 102Aim ............................................................................................................................................................ 102Objectives ................................................................................................................................................. 102Learning outcome ...................................................................................................................................... 1027.1 Introduction to Database Security ........................................................................................................ 1037.2 Database Security Threats .................................................................................................................... 103 7.2.1 Data Tampering .................................................................................................................... 103 7.2.2 Identity Threats .................................................................................................................... 104 7.2.3 Data Theft and Eavesdropping............................................................................................. 104 7.2.4 Password-Related Threats .................................................................................................... 104 7.2.5 Unauthorised Access to Tables and Columns ...................................................................... 104 7.2.6 Unauthorised Access to Data Rows ..................................................................................... 1047.3 Data Security Requirements ................................................................................................................ 105 7.3.1 Vulnerability Assessments ................................................................................................... 105 7.3.2 Monitoring of Database Protocol Traffic (SQL) .................................................................. 105 7.3.3 Access Control ..................................................................................................................... 106 7.3.4 Authentication ...................................................................................................................... 106 7.3.5 Integrity ................................................................................................................................ 107 7.3.6 Availability ........................................................................................................................... 1077.4 Roles .................................................................................................................................................... 1077.5 Granting and Revoking Privileges and Roles ...................................................................................... 1087.6 Digital Signatures as Passwords for Data Security ...............................................................................1107.7 Introduction to Data Integrity ...............................................................................................................1107.8 Integrity Constraints ..............................................................................................................................111 7.8.1 Entity Integrity Constraints ...................................................................................................111 7.8.2 Referential Integrity ..............................................................................................................111 7.8.3 Domain Level Integrity .........................................................................................................112 7.8.4 Column Integrity ...................................................................................................................112Summary ...................................................................................................................................................113References .................................................................................................................................................113Recommended Reading ............................................................................................................................114Self Assessment .........................................................................................................................................115

Chapter VIII .............................................................................................................................................117Structure, Components, Functions and Implementation of Database Management System ............117Aim .............................................................................................................................................................117Objectives ..................................................................................................................................................117

V

Learning outcome .......................................................................................................................................1178.1 Structure of DBMS ...............................................................................................................................1188.2 Execution Steps of DBMS ....................................................................................................................1188.3 Components of DBMS ..........................................................................................................................1198.4 Functions and Services of a DBMS ..................................................................................................... 1218.5 Types of Database Systems .................................................................................................................. 123 8.5.1 Centralised Database System ............................................................................................... 123 8.5.2 Parallel Database System ..................................................................................................... 124 8.5.3 Client/Server Database System ............................................................................................ 127 8.5.4 Distributed Database Systems ............................................................................................ 1288.6 Database Administrator ........................................................................................................................ 1298.7 Transaction Processing......................................................................................................................... 130 8.7.1 ACID criteria (Atomicity, Consistency, Isolation, Durability) ............................................ 132 8.7.2 Benefits of Transaction Processing ...................................................................................... 132 8.7.3 Implementation .................................................................................................................... 132Summary .................................................................................................................................................. 134References ................................................................................................................................................ 134Recommended Reading ........................................................................................................................... 135Self Assessment ......................................................................................................................................... 136

VI

List of Figures

Fig. 1.1 Database organisations ..................................................................................................................... 3Fig. 1.2 Components of DBMS ..................................................................................................................... 4Fig. 2.1 Record based data model ................................................................................................................ 12Fig. 2.2 Hierarchical model ......................................................................................................................... 13Fig. 2.3 An example of hierarchical relationship ......................................................................................... 13Fig. 2.4 Network model ............................................................................................................................... 13Fig. 2.5 An example of network data model ................................................................................................ 14Fig. 2.6 Relational data model ..................................................................................................................... 14Fig. 3.1 Relational data structure ................................................................................................................. 23Fig. 3.2 Primary key-foreign key relationship ............................................................................................. 25Fig. 5.1 Design process ................................................................................................................................ 52Fig. 5.2 Flow of design process ................................................................................................................... 53Fig. 5.3 Notations for ER diagrams ............................................................................................................. 55Fig. 5.4 An example of an ER diagram ....................................................................................................... 56Fig. 5.5 Component of an E-R model ......................................................................................................... 56Fig. 5.6 Types of attribute ........................................................................................................................... 57Fig. 5.7 Sample of ER diagram .................................................................................................................... 59Fig. 5.8 Unary relationship .......................................................................................................................... 60Fig. 5.9 Binary relationship ......................................................................................................................... 60Fig. 5.10 Ternary relationship (a) ................................................................................................................. 61Fig. 5.10 Ternary relationship (b) ................................................................................................................ 61Fig. 5.11 One-to-one cardinality .................................................................................................................. 61Fig. 5.12 One-to-many cardinality ............................................................................................................... 62Fig. 5.13 Many-to-one cardinality ............................................................................................................... 62Fig. 5.14 Many-to-many cardinality ............................................................................................................ 62Fig. 5.15 Diagram showing weak entity ...................................................................................................... 63Fig. 5.16 Participation .................................................................................................................................. 63Fig. 5.17 Many-to-many relationship .......................................................................................................... 64Fig. 5.18 E-R diagram showing composite relationship .............................................................................. 64Fig. 5.19 E-R diagram with role indicators .................................................................................................. 65Fig. 5.20 Generalisation ............................................................................................................................... 66Fig. 5.21 E-R diagram with redundant relationships ................................................................................... 67Fig. 5.22 E-R diagram with aggregation ...................................................................................................... 67Fig. 7.1 Common uses of roles .................................................................................................................. 108Fig. 8.1 Structure of DBMS ........................................................................................................................119Fig. 8.2 Functions and services of DBMS ................................................................................................. 121Fig. 8.3 Types of Database Management System ...................................................................................... 123Fig. 8.4 Centralised database system ......................................................................................................... 124Fig. 8.5 Shared memory architecture ......................................................................................................... 125Fig. 8.6 Shared disk storage ....................................................................................................................... 125Fig. 8.7 Independent resources architecture .............................................................................................. 126Fig. 8.8 Hierarchical network .................................................................................................................... 126Fig. 8.9 Client server database ................................................................................................................... 127Fig. 8.10 Distributed database systems ...................................................................................................... 128

VII

List of Tables

Table 1.1 Student information systems .......................................................................................................... 2Table 2.1 Student table ................................................................................................................................. 15Table 2.2 Programme table .......................................................................................................................... 15Table 3.1 User table ................................................................................................................................... 21Table 3.2 RDBMS terminology ................................................................................................................... 21Table 3.3 Element table ................................................................................................................................ 24Table 3.4 Shipment table .............................................................................................................................. 24Table 3.5 Employee Table ........................................................................................................................... 25Table 3.6 Important elements of referential integrity .................................................................................. 27Table 3.7 Codd’s 12 Rules ........................................................................................................................... 30Table 4.1 Customer relation ......................................................................................................................... 36Table 4.2 Department relation showing lack of atomicity ........................................................................... 39Table 4.3 Department relation in 1NF ......................................................................................................... 40Table 4.4 Department relation in 1NF ......................................................................................................... 40Table 4.5 Employees’ skills ........................................................................................................................ 41Table 4.6 (a) Employees ............................................................................................................................. 41Table 4.6 (b) Employees’ skills ................................................................................................................... 41Table 4.7 Tournament winners .................................................................................................................... 42Table 4.8 (a) Tournament winners .............................................................................................................. 43Table 4.8 (b) Player dates of birth ................................................................................................................ 43Table 4.9 Normalisation to BCNF ............................................................................................................... 44Table 6.1 SQL data types ............................................................................................................................. 75Table 6.2 List of suppliers ............................................................................................................................ 76Table 6.3 Example of queries (1) ................................................................................................................. 78Table 6.4 Example of queries (2) ................................................................................................................. 78Table 6.5 Example of queries (3) ................................................................................................................. 78Table 6.6 BETWEEN Operators .................................................................................................................. 79Table 6.7 An example of LIKE operator ..................................................................................................... 80Table 6.8 Example of LIKE operator ......................................................................................................... 81Table 6.9 Example of Logical operator ...................................................................................................... 81Table 6.10 Example of OR operator ........................................................................................................... 82Table 6.11 Example of NOT operator ......................................................................................................... 82Table 6.12 Aggregate function ..................................................................................................................... 83Table 6.13 Joining table ............................................................................................................................... 85Table 6.14 Rows of joining table are combines ........................................................................................... 86Table 6.15 Outer joins .................................................................................................................................. 87Table 6.16 In sub-query ............................................................................................................................... 88Table 6.17 Scalar subquery ......................................................................................................................... 90Table 6.18 Table of subqueries .................................................................................................................... 91Table 7.1 Availability aspect ...................................................................................................................... 107

VIII

Abbreviations

ACID - Atomicity, Consistency, Isolation, Durability ANSI - American National Standards Institute BCNF - Boyce-Codd Normal FormCPUs - Central Processing UnitsDBA - Database AdministratorDBMS - Database Management systemDDL - Data Definition LanguageDML - Data Manipulation LanguageDTP - Distributed Transaction ProcessingDQL - Data Query LanguageE-R - Entity-RelationshipERM - Entity- Relationship ModelERD - Entity-Relationship DiagramI/O - Input/output IT - Information Technology NF - Normal Forms2NF - Second Normal Form3NF - Third Normal Form 4NF - Fourth Normal FormOS - Operating SystemsPRDBMS - Pseudo-Relational Database Management Systems RDBMS - Relational Database Management SystemRI - Referential IntegritySQL - Structure Query LanguageTRDBMS - Truly-Relational Database Management Systems

1

Chapter I


Aim

The aim of this chapter is to:

introduce database management system•

elucidate conventional file oriented system•

explain database organisation•

Objectives

The objectives of this chapter are to:

explain database design•

describe the components of DBMS •

enlist the advantages and disadvantages of DBMS•

Learning outcome

At the end of this chapter, you will be able to:

understand the concept of database design•

describe basic terminologies of DBMS•

describe architecture of DBMS•


2

1.1 Database: An IntroductionIn current era, the term database has been used to indicate a place where data resides. A database in computer science can be defined as a structured collection of related data that is stored in a specific format which can be shared and accessed by multiple users. The data in turn may be defined as a known fact that can be recorded and that have implicit meaning. It is the raw fact from which information is to be derived and presented to the user.

For example, in the student database the names addresses, departments of students stored in student information file is the collection of related data having its implicit meaning. Data can be stored in database in variety of forms such as numbers, text, bits, bytes, yes or no form. Data can also be objects like images, documents or video segments. Datum is single piece of information and data is usually collection of datums.

For example, the table below shows the facts (data) used in the student information system. Here, a single entity can be referred to as a datum.

Student Enrolment Number

Student First Name

Student Last

Name

Student Middle Name

Hostellite ( Yes/No)

Date of Birth Department

20112908001 Vishakha Joshi Narendra Y 10-08-1986 Computer

Table 1.1 Student information systems

Database system is a computerised system organised in such a way so that a computer program or person using a query language can consult it to answer queries. The information is retrieved in answer to queries and that can be used to make decisions. The computer program used to manage and query a database is known as Database Management System (DBMS).

1.2 Conventional File Oriented SystemConventional file based system is basically a file based system, in which we manually or through computer handle the database such as updating, insertion, deletion, adding new files to database etc.

1.2.1 Disadvantages of Conventional File Oriented SystemThe conventional file processing system suffers from the following shortcomings:Data redundancy and inconsistencyDifferent programmers create different files with different data structures due to decentralised approach. Hence, data would be duplicated at various places. This may lead to data inconsistency that is copies of data at various places may not agree due to data changes which does not get reflected at other places if not taken care of. This even leads to poor data control.

Difficulty in accessing dataConventional file system does not allow new data to be retrieved in a convenient and efficient manner. For example, in student information system, if the data processing department is required to provide a data of students living in particular area, new program has to be generated if such kind of request was not anticipated previously, and hence, a program to generate such a list does not exist. More responsive data retrieval systems are required for general use.

Program-data dependenceIf it is decided to change the structure of data in the file, all the programs accessing data from that file needs to change. Often, it is difficult to even locate all the programs affected by such changes and this can again lead to wrong information being conveyed.

3

Atomicity problemSometimes, it may be essential to carry out number of operations to occur concurrently. For example, if in a banking system some amount is to be transferred from account of customer X to customer Y, then these two operations of debiting from the account of customer X and crediting to the account of customer Y should be atomic, it must happen in entirety or not at all. It is difficult to ensure atomicity in a conventional file-processing system.

Concurrent-access anomaliesCurrent era demands concurrent access to the files which is not possible without inconsistencies in Conventional File System.

Security problemsEvery user in the file system should not be allowed to access all the data and each user should be allowed access to the relevant data only. This cannot be achieved through conventional File System and any user can have access to vulnerable data. For example, student should not have access to exam data.

1.3 Database OrganisationA database organisation as shown in the figure below has three levels of schema:

Convert by Application program and presented different views to different users

Conversion by DBMS S/W



Conceptual Schema

Internal Schema

External Schema 1

External Schema 2

External Schema 3

Physical Database

Fig. 1.1 Database organisations

Internal schema• which deals with physical storage organisation, i.e., it defines how and where the data are organised in physical storage.Conceptual schema• which deals with overall logical organisation: It describes the stored data structure, data types, relationships, operations and constraints.External schema• that defines views of the database for individual user.


4

Due to these three schemas, it is easier to achieve data independence. The change in schema at some level does not cause any inconsistency at other levels.

1.4 Basic Components of DBMS

Database System

DBMS components

Users/ Programmers

Application programs/queries

Software to process queries/ program (DML/SQL)

Data Description Language (DDL)

Software for controlled access of stored data

Stored database definition (metadata)

Stored Physical Database

Fig. 1.2 Components of DBMS

The DBMS provides Data Description Language (DDL) facility, which is used to create and destroy databases and database objects. The structure and usage of four basic DDL commands are as follows:

Create:• The CREATE DATABASE statement is used to create a database. The CREATE TABLE statement is used to create a table in a database.

Syntax: CREATE DATABASE database_name CREATE TABLE table_name ( column_name1 data_type, column_name2 data_type, column_name3 data_type, .... )

Example: - CREATE DATABASE student_db CREATE TABLE Students( Stud_id int,

5

LastName varchar(20), FirstName varchar(20), Address varchar(20), City varchar(20) )

Alter- the ALTER TABLE statement is used to add, delete, or modify columns in an existing table.• Syntax: 1) ALTER TABLE table_name

ADD column_name datatype 2) ALTER TABLE table_name

DROP COLUMN column_nameDrop- the DROP TABLE statement is used to delete a table.•

Syntax: 1) DROP TABLE table_name 2) DROP DATABASE database_name

1.5 Advantages and Disadvantages of DBMSDBMS provides centralised control of the operational data. Some of the advantages of data independence, integration and centralised control are:

Redundancies and inconsistencies can be reduced:Data inconsistencies are often encountered in everyday life. For example, we have all come across situations when a new address is communicated to an organisation that we deal with (For example, a bank, or Telecom, or a gas company), we find that some of the communications from that organisation are received at the new address while others continue to be mailed to the old address. In DBMS due to centralised control of all the data in a database would involve reduction in redundancy as well as inconsistency. It also is likely to reduce the costs for collection, storage and updating of data.

Better service to the users:Due to one centralised database, the availability of information and its up-to-dateness is likely to improve since the data can now be shared and the DBMS makes it easy to respond to unforeseen information requests. Centralising the data in a database also often means that users can obtain new and combined information that would have been impossible to obtain otherwise.

Flexibility of the system is improved:Changes are often necessary to the contents of data stored in any system. These changes are more easily made in a database than in a conventional system in that these changes do not need to have any impact on application programs.

Cost of developing and maintaining systems is lower:Although the initial cost of setting up of a database can be large, one normally expects the overall cost of setting up a database and developing and maintaining application programs to be lower than for similar ser vice using conventional systems since the productivity of programmers can be substantially higher in using non-procedural languages that have been developed with modern DBMS than using procedural languages.

Standards can be enforced:Since all access to the database must be through the DBMS, standards are easier to enforce. Standards may relate to the naming of the data, the format of the data, the structure of the data etc.


6

Security can be improved:Setting up of a database makes it easier to enforce security restrictions since the data is now centralised. It is easier to control who has access to what parts of the database.

Integrity can be improved:Since the data of the organisation using a database approach is centralised and would be used by a number of users at a time, it is essential to enforce integrity controls.

Enterprise requirements can be identified:All enterprises have sections and departments and each of these units often consider the work of their unit as the most important and therefore consider their needs as the most important. Once a database has been set up with centralised control, it will be necessary to identify enterprise requirements and to balance the needs of competing units.

Data model must be developed:One of the important advantage of setting up a database system is the requirement that an overall data model for the enterprise be built.

Some of the disadvantages of DBMS are:Increased Complexity and size:Due to the expected functionality from DBMS, it becomes necessary for database administrators, designers to understand the full functionality to avoid bad designing which can lead to serious consequences and hence loss to the organisation.

Specialised manpower and increased installation and management cost:Because of rapid changes in database technology, business needs it requires trained manpower to install, maintain, update and backup database, which, in turn requires substantial annual maintenance and support cost.

Need for explicit backup and recovery:A comprehensive procedure is required for providing backup copies of data and restoring a database when backup occurs.

Confidentiality, privacy and security:To reduce the chances of unauthorised users accessing sensitive information, it is necessary to take technical administrative and, possibly, legal measures. Most databases store valuable information that must be protected against deliberate trespass and destruction.

Data quality:Since the database is accessible to users remotely, adequate controls are needed to control users updating data and to control data quality. With increased number of users accessing data directly, there are enormous opportunities for users to damage the data. Unless there are suitable controls, the data quality may be compromised.

1.6 Database DesignDatabase systems are designed to manage large bodies of information. These large bodies are part of operation of some enterprise whose end product may be information from the database or may be some service for which the database plays important role. For example, the employee database or the reservation systems. Database mainly involves the design of the database schema. The design of the complete database application environment that meets the needs of the enterprise being modelled requires thorough study of requirements and design process.

7

1.6.1 Design ProcessFor developing a good database design, it is essential to understand the meaning of information and the intended use of stored information. The initial phase of database designing mainly is to gather data requirements, characterise fully the data needs of the possible data users. The database designer needs to interact extensively with the domain experts and users to carry out this task. The outcome of this phase is a specification of user requirements. Then the collected information is analysed for ensuring:

Correctness• : The information should represent the real world correctly.Consistency• : The definition of an entity must cover all possible values that it may take. All the constraints of the real world entity must be adequately depicted.Completeness• : The defined entity should be complete, i.e., no attribute should be missing. All the relevant attributes of the real world entity should be included in the model.Realistic representation• : The representation of the entity must be realistic.Need• : The usefulness of the information for the application should be established.

Next, the designer chooses a data model, translates the requirements gathered into the conceptual schema of the database. The schema developed at this conceptual design phase provides a detailed overview of the enterprise. The designer’s reviews the schema to confirm that all data requirements are satisfied and are not in conflict with each other and at the same time is sufficient to represent the facts. The designer also removes any redundant features. The focus is describing the data and their relationships, rather than on specifying physical storage details.

1.6.2 Advantages of Developing a Database Designing ModelIt helps in representing the real world objects in computer usable form. It also helps in representing the associations and relationships among the real world objects. It defines how the object interacts in the application. It allows the database designers to capture the static and dynamic organisation and flow of information within a host enterprise. It allows the designers and users of the system to understand the system being modelled in its totality. It helps in improving the maintainability, scalability and reliability of the system.


8

SummaryA database in computer science can be defined as a structured collection of related data that is stored in a specific • format which can be shared and accessed by multiple users.Datum is single piece of information and data is usually collection of datum• Database system is a computerised system organised in such a way so that a computer program or person using • a query language can consult it to answer queries. The information is retrieved in answer to queries and that can be used to make decision • The computer program used to manage and query a database is known as Database Management system • (DBMS).A schema defines different views of the database for the use of various system components of the DBMS and • for database security.A database organisation has three levels of schema: Internal schema, Conceptual schema, External schema.• The DBMS provides Data Description Language (DDL) facility,• which is used to create and destroy databases and database objects.Data modelling and database design are very critical phases in the database development life cycle.• Database systems are designed to manage large bodies of information.•

ReferencesGary, B., Shelly & Rosenblatt, H. J., 2011. • Systems Analysis and Design, Cengage Learning. Sosinsky, B., 2009. • Networking Bible, John Wiley and Sons.Goyal,A., 2008. • Database Management System (DBMS) Basic Concepts [Online] Available at: <http://dbmsbasics.blogspot.com/2008/02/database-system-and-its-components.html>. [Accessed 12 September 2011].Knol a unit of knowledge, • Database design steps / How to develop a database: Data Models & the Database Development Life Cycle [Online] (Updated 15 August 2010) Available at: <http://knol.google.com/k/database-design-steps-how-to-develop-a-database#>. [Accessed 12 September 2011].Janakiram, D., 2008. Introduction to Database Management System [Video online] Available at: <http://www.• youtube.com/watch?v=EUzsy3W4I0g> [Accessed 9 September 2011]. Srinath, S., 2008. Conceptual Designs [Video online] Available at: <http://www.youtube.com/• watch?v=EuSBAOpXjU0> [Accessed 9 September 2011].

Recommended ReadingO’Neil, P. & O’Neil, E., 2001. • Database--principles, programming and performance, 2nd ed., Morgan Kaufmann.Kedar, S., 2009. • Database Management System, Technical Publications.Connolly, T., 2008. • Database Systems: A Practical Approach To Design, Implementation And Management, 4th ed., Pearson Education India.

9

Self AssessmentWhich of following statements is true?1.

Database system is a computerised system organised in such a way that a computer program or person using a. a query language can refer to it, to answer queries.Data information is a computerised system organised in such a way that a computer program or person using b. a query language can refer to it, to answer queries.Data management is a computerised system organised in such a way that a computer program or person c. using a query language can refer to it, to answer queries.Database process is a computerised system organised in such a way that a computer program or person using d. a query language can refer to it, to answer queries.

The information is retrieved in answer to queries and that can be used to make ________.2. new dataa. programb. coding c. decisionsd.

The computer program used to manage and query a database is known as __________.3. data processing a. programming b. database management system c. data logging d.

The conventional file processing system suffers from ____________. 4. data redundancy and inconsistency a. accessing b. processing c. managing d.

Different programmers create different files with different data structures due to _________________ 5. approach.

centraliseda. integrateb. decentralisedc. compactd.

____________ file system does not allow new data to be retrieved in a convenient and efficient manner.6. Unadventurousa. Conventionalb. Activistc. Predictabled.


10

If it is decided to change the structure of data in the file, all the programs accessing data from that file needs to 7. be ___________.

saved a. managed b. changed c. retrieved d.

Every user in the file system should not be allowed to access all data and each user should be allowed access 8. to the __________ data only.

relevanta. essentialb. inappropriatec. unrelatedd.

______________that defines views of the database for individual user.9. Internal Schema a. External Schema b. Physical data c. Conceptual schema d.

The Data Definition Language is used to _____________ databases and database objects. 10. assemble and builda. create and destroyb. program and arrange c. store and mix d.

11

Chapter II

Data Modelling

Aim


explain database modelling•

elaborate the types of data models•

explicate object based data models•

Objectives


explain record based data model•

explicate hierarchical data model•

elucidate • object database management system

Learning outcome


recognise network model•

identify relational data model•

describe data modelling•


12

2.1 Introduction to Database ModellingData Modelling is used for representing entities of interest and their relationships in the database. It helps in understanding what data means. A data model is the conceptual way of structuring the data. Building a data model requires careful analysis of the entities, relationships and attributes. The database designer analyses and presents the data models to ensure that:

Each user’s view of the data is understood.• The nature of the data, independent of its physical representation is clearly understood.• The data is correctly used at correct places.•

A data model should provide the way of structuring the data (consisting of the set of rules according to which databases can be constructed) for the entities being modelled, allow a set of manipulative operations (For example, updating and retrieving the data from the database) to be defined on them, and, enforce set of constraints (or integrity rules) to ensure accuracy of data.

2.2 Types of Data ModelsMost commercial DBMS‘s support a single data model but different DBMS may support different data models. The common goal is to specify data storage and retrieval mechanism. Data models can be as follows:

Record-based data models• Object-based data models• Physical data models•

The major difference between the database models lies in the modes of depicting constraints and relationships among the data elements.

2.2.1 Record Based Data ModellingIn record based models, the database consists of a number of fixed-format records of several types. Each record type defines a fixed number of fields, each typically of fixed length. The three principle types of record based models are:

Record Based Model

Hirearchical Data

Model

Network Data

Model

Relational Data

Model

Fig. 2.1 Record based data model

2.2.1.1 Hierarchical Data ModelThis model is represented by an upside down tree and arranged as hierarchy of segments. A segment is an equivalent of file-system’s record type. Here, the relationship between the files or records forms a hierarchy. It is one of the oldest database models used by the enterprise in the past. The figure below shows the hierarchical model.

13

Level-0: Report Parent (Node)

Level-1: Root Children (Segment)

Level- Segments (Level-1 Children)

A

A

A A

A

Fig. 2.2 Hierarchical model

The figure below shows hierarchical relationship of department with faculty and subject. We see here that Department is related to FACULTY and also SUBJECT. FACULTY in turn is related to COURSE and SUBJECT related to TOPIC. Here, DEPARTMENT is at the top of hierarchy from which large amount of information can be derived.

Department

Faculty Subject

Course Topic

Fig. 2.3 An example of hierarchical relationship

2.2.1.2 Network Data ModelThe network model is very similar to the hierarchical one; it is also based on the concept of parent/child relationship but removes the restriction of one child having one and only one parent.

A

B C D

Fig. 2.4 Network model

In the network database model, a parent can have multiple children, and a child can have multiple parents. This structure could be visualised as several trees that share some branches. In network database jargon these relationships came to be known as sets. In addition to the ability to handle a one-to-many relationship, the network database can handle many-to-many relationships. Also, data access did not have to begin with the root; instead one could traverse the database structure starting from any table and navigating a related table in any direction.


14

Order Header

Customer Salesman Product

Fig. 2.5 An example of network data model

In this example, to find out what products were sold to what customers we still would have to start with ORDER_HEADER and then proceed to CUSTOMER and PRODUCT.

Things greatly improve for the scenario when customers place an order through more than one agent: no longer does one have to go through agents to list customers of the specific product, and no longer has one to start at the root in search of records.

2.2.1.3 Relational Data ModelsRelational models just like hierarchical and network models are based upon tables and use parent/child relationships.

FK_Category_Category

FK_Product_Category

FK_ProductProperty_Product

FK_levelCost_Product

CategoryProductProperty Category_ID

Category_Parent Name Property_ID

Product_ID Propertty_Key Property_Value

ProductProduct_ID Category_ID Name DescriptionWholesale_Cost SKU

LevelCost Produc_ID Min_QtyCost

LevelCost_ID

Fig. 2.6 Relational data model

15

This relationship was implemented through column values as opposed to a low-level physical pointer defining the relationship. This model uses tables to represent the data and the relationships among those data. Each table has multiple columns and each column is identified by a unique name. Figure 2.7shows a sample relational database comprising two tables: one showing the student details and other shows the programme details. In this sample database each row in the table represents a different student. Relationships link rows from two tables on the basis of the field, in this case –programme code.

Student Name Address Programme

codeStudent Enroll

NoStudent

Category

Divya Shah Mahatma Nagar, Calcutta 06 0606005 Open

Niharika Pandit Sahakarnagar, Pune 07 06064512 Open

Priya Mathur M.G.Road,DivyaKunj,Bombay 05 06061253 OBC

Table 2.1 Student table

Programme Name Programme Code

Computer Engineering 06

Information Technology 07

Textile Engineering 05

Table 2.2 Programme table

2.3 Object Based Data ModelIn an object oriented database, information is represented in the form of objects as used in Object-Oriented Programming. When database capabilities are combined with object programming language capabilities, the result is an object database management system (ODBMS).An ODBMS makes database objects appear as programming language objects in one or more object programming languages.

An ODBMS extends the programming language with transparently persistent data, concurrency control, data • recovery, associative queries, and other capabilities. Some object-oriented databases are designed to work well with object-oriented programming languages such as Python, Java, C#, Visual Basic .NET, C++ and Smalltalk. Others have their own programming languages. ODBMSs use exactly the same model as object-oriented • programming languages. Object databases are generally recommended when there is a business need for high performance processing on complex data. An Object-oriented database models represents an entity and a class. A class represents both object attributes as well as the behaviour of the entity.

For example, a CUSTOMER class will have not only the customer attributes such as CUST-ID, CUST-NAME, and CUST-ADDRESS and so on, but also procedures that imitate actions expected of a customer such as update-order. Instances such as class-object correspond to individual customers. Within an object, the class attributes takes specific values, which distinguish one customer (object) from another.

However, all objects belonging to a class, share the behaviour pattern of the class. The object-oriented database maintains relationships through logical containment. This model is based on encapsulation of the data and code related to an object into a single unit, whose contents are not visible to the outside world.


16

Therefore, Object Oriented Data models emphasise on objects. The structure for any given class or type of object • could be anything a programmer finds useful for example a linked list, a set, an array and so forth. Furthermore, an object may contain varying degrees of complexity, making use of multiple types and multiple structures. Object Oriented Databases are suited for multimedia applications as well as data with complex relationships, which are difficult to model and process in a relational DBMS.

For example, consider an object representing a bank account. The object contains instance variables number and balance. The object contains a method pay-interest which adds interest to the balance. Under most data models, changing the interest rate entails changing code in application programs. In the object-oriented model, this only entails a change within the pay interest method.

Here each object has its own unique identity, independent of the values it contains. Two objects containing the same values are distinct. Distinction is created and maintained in physical level by assigning distinct object identifiers.

17

SummaryA data model is the conceptual way of structuring the data. Building a data model requires careful analysis of • the entities, relationships and attributes. Datum is single piece of information and data is usually collection of datums.Most commercial DBMS‘s support a single data model but different DBMS may support different data • models.Data models can be classified into three different categories: Record-Based data models, Object-based data • models, Physical data models.In hierarchical data model the relationship between the files or records forms a hierarchy.• The Network is also based on the concept of parent/child relationship but removes the restriction of one child • having one and only one parent.The Relational model uses tables to represent the data and the relationships among those data. Each table has • multiple columns and each column is identified by a unique name.In an object oriented database, information is represented in the form of objects as used in Object-Oriented • Programming discrepancy.In the network database model a parent can have multiple children, and a child can have multiple parents.• In network database jargon the relationships are known as sets.• An ODBMS extends the programming language with transparently persistent data, concurrency control, data • recovery, associative queries, and other capabilities.

ReferencesSilverston, L., 2001• . The Data Model Resource Book: a library of universal data models by industry types, vol. 2, Wiley.Hoberman, S., 2007. • Data modelling made simple: a practical guide for business & IT professionals, Technics Publications.Modell, M., 1992. • Data Analysis, Data Modelling and Classification. [Online] Available at: <http://www.martymodell.com/dadmc/index.html>. [Accessed 11 September 2011].Mullins, C. S., 2002. • Database Trends and Applications. [Online] Available at: <http://www.craigsmullins.com/dbta_015.htm> [Accessed 9 September 2011]. Srinath, S., 2008. • Introduction to Data Warehousing and OLAP. [Video Online] Available at: <http://www.youtube.com/watch?v=G4NYQox4n2g > [Accessed 9 September 2011]. Srinath, S., 2008. • Relational Model. [Video online] Available at: <http://www.youtube.com/watch?v=gGGHjYbQMvw> [Accessed 9 September 2011].

Recommended ReadingMcnurlin, 2003. • Information Systems Management In Practice, 6th ed., Pearson Education India.Itl Education Solutions Limited, 2010. • Introduction to Database Systems, Pearson Education India.Singh, K. S., 2009. • Database Systems: Concepts, Design and Applications, 3rd ed., Pearson Education India.


18

Self AssessmentData model is a collection of conceptual tool for describing ____________.1.

dataa. data relationshipsb. databasec. relationshipd.

In a relational model, the columns of the table are called ___________.2. Columnsa. Attributesb. Recordsc. Entitiesd.

Which of the following is not an Object Oriented feature?3. Abstractiona. Encapsulationb. Polymorphismc. Attributesd.

An Object Oriented DBMS is capable of holding ___________.4. Data and Texta. Only Pictures b. Only Voice c. Tabled.

The relational data model was first introduced by ____________.5. SPARCa. E. F. Coddb. ANSIc. Chend.

A collection of data designed to be used by different people is called ___________.6. dataa. databaseb. RDBMSc. DBMSd.

Which kind of relationship can be handled by network database? 7. Many-to-many relationshipsa. One-to-many relationshipsb. One-to-one relationshipsc. Many-to-one relationshipsd.

19

Which of the following statements is true?.8. Some object-oriented databases are designed to work well with procedure-oriented programming a. languages.Some procedure-oriented databases are designed to work well with object-oriented programming b. languagesSome object-oriented databases are designed to work well with object-oriented programming languagesc. Some object-oriented databases does not work well with object-oriented programming languagesd.

A9. n object may contain varying degrees of_____________making use of multiple types and multiple structures.

complexitya. compatibilityb. authenticityc. equality d.

Th10. e object-oriented database maintains relationships with the help of _________.physical containmenta. virtual containmentb. software containmentc. logical containment d.


20

Chapter III

Introduction to Relational Database Management Systems

Aim


explain the concept of Relational Database Management System•

explicate various concepts of RDBMS like keys, constraints, integrity•

elucidate the Codd’s 12 Rules•

Objectives


explain various keys of relation data structure •

elucidate the concept of constraints•

elaborate the types of integrity constraints•

Learning outcome


identify referential integrity •

describe referential integrity •

understand operational constraints •

21

3.1 Relational Database Management SystemRDBMS is an acronym for Relational Database Management System. The data in RDBMS is stored in database objects called tables. The database tables are the primary data storage for every RDBMS and essentially they are collections of related data entries.

For example, a table called Users might store information about many persons and each entry in this table will represent one unique user. Even though all user entries in the Users table are unique, they are related in a way that they describe similar objects.

First Name Last Name Date of Birth

John Smith 12/2/1969

David Stonewall 01/03/1954

Susan Grant 03/03/1970

Table 3.1 User table

A relational database management system (RDBMS) is a database management system (DBMS) that is based on the relational model introduced by E. F. Codd in 1970, who laid down the principles of mathematical theory. The relational model is based on this mathematical theory. Relational databases are the most common kind of database in use today.

Relational Terms Previously used Terms

Relation Table

Tuple Row, Record

Cardinality Number of rows

Attribute Columns, Field

Degree Number of Columns

Primary key Unique Identifier

Domain Set of legal values

Table 3.2 RDBMS terminology

Each database table consists of columns and rows. Each table column defines the type of data stored in it, and this data type is valid for all rows in this table. A table row is a collection of data having 1 entry for each column in this particular table. RDBMS store the data into group of tables, which might or might not be related by common fields (database table columns). RDBMS also provide relational operators to insert/update/delete information stored into the database tables. MS SQL Server, DB2, Oracle and MySQL are all RDMS.

A short definition of a RDBMS may be a DBMS in which data is stored in the form of tables and the relationship among the data is also stored in the form of tables. As a simple explanation, relational data model allows various data packets/files to be related to each other with a set of relations.


22

For example, if customer names are stored in one file ‘CUSTOMER’ and other file contains the names of cities ‘CITY’. Then CUSTOMER file can have a relation with CITY, which will help identify which city the customer belongs to. It is entirely based on the predicate logic and set theory of mathematics. Codd used mathematical n-ary relations as a base to represent data, which is a subset of the Cartesian product of n sets. These sets are bound to each other in a structured manner with various constraints (i.e. relations). The data, as mentioned above is managed by using relational calculus and various constraints to form a container that holds it (which is also known as schema), the relation between data can be expressed in a particular structured language.

The data is arranged in a relation, which is visually represented in a two dimensional table. The data is inserted into the table in the form of tuples (which are nothing but rows). A tuple is formed by one or more than one attributes, which are used as basic building blocks in the formation of various expressions that are used to derive meaningful information. There can be any number of tuples in the table, but all the tuple contain fixed and same attributes with varying values.

The relational model is implemented in database where a relation is represented by a table. A tuple is represented • by a row. An attribute is represented by a column of the table, attribute name is the name of the column such as ‘identifier’, ‘name’, ‘city’ etc., attribute value contains the value for column in the row, and constraints are applied to the table and form a logical schema.In order to facilitate the selection of a particular row/tuple from the table, the attributes i.e. column names are • used and to expedite the selection of the rows some fields are defined uniquely to use them as indexes. This process helps in searching the required data as fast as possible. All the relational algebra operations, such as Select, Intersection, Product, Union, Difference, Project, Join, Division, Merge, etc. can also be performed on the Relational Database Model. Operations on the Relational Database Model are facilitated with the help of different conditional expressions, various key attributes, pre-defined constraints etc. For example, selection of information of the customer, who is living in some city for more than 20 years.The relational model consists of three components:•

A Structural component, which is a set of TABLES (also called RELATIONS). �MANIPULATIVE component consisting of a set of high-level operations, which act upon and produce �whole tables.A SET OF RULES for maintaining the INTEGRITY of the database. �

3.2 The Relational Data StructureThe terminology associated with relational database theory originates from the branch of mathematics called set theory although there are widely used synonyms for these precise mathematical terms.

Da• ta structures are composed of two components, which represent a model of the situation being considered. These are as follows:

ENTITY TYPES For example, data group types �RELATIONSHIPS between the entity types �

Entity types are represented by RELATIONS or BASE TABLES. These two terms are interchangeable - a • RELATION is the mathematical term for a TABLE. A base table is loosely defined as an un-ordered collection of zero, one or more tuples (rows) each of which consists of one or more unordered attributes (columns).

23

Student Enroll. No. Name Age Department0706001 Asha Patnis 16 Computer0706002 Vailshali Bishwas 17 Computer0707005 Suvarna Pande 13 Information Technology0703008 Sandesh Agnihotri 15 Civil

D1

07010010707999

Any noun

Computer, Mechanical,

Civil, Inf. Tech etc.

13 to 17

D2

D3

D4

Dom

ains

Rel

atio

n

Car

dina

lity

Tuples

Attributes

Degree

Fig. 3.1 Relational data structure

All tuples are made up of exactly the same set of attributes. Each column is drawn from a domain, that is, a set • of values from which the actual values are taken (e.g. a set of car model names). More than one column in a table may draw its values from the same domain. A column entry in any row is • single-valued, i.e. it contains exactly one item only (for example, a surname). Repeating groups, i.e. columns, which contain sets of values rather than a single value, are not allowed. Each row of a table is uniquely identified by a PRIMARY KEY composed of one or more columns. This implies • that a table may not contain duplicate rows. The notion of superkey, primary key and candidate key are also applicable to the relational model. The relational data model includes several types of constraints whose objective is to maintain the accuracy and integrity of the data in the database. The number of attributes in a relation is called degree of the relation. A relation having degree one is called • unary, a relation with degree two is called binary etc. Cardinality of a relation is defined as the number of tuples or rows are in the relation. So, the cardinality of a relation changes with time as more and more tuples get added or deleted but the degree does not.

3.3 KeysThe value of a key attribute can be used to uniquely identify each tuple in a relation. A set of attributes constituting a key is a property of the relational schema; it is a constraint that should hold on every relation state of the schema. A key is determined from the meaning of the attributes and the property is time-invariant. It must continue to hold when we insert new tuples in the relation. Note that, in general, a column, or group of columns, that uniquely identifies a row in a table is called a CANDIDATE KEY.


24

There may be more than one candidate key for a particular table; one of these will be chosen as the primary key. The candidate key cannot contain NULL value and should always contain a unique value. Primary key is the candidate key in the relation whose values are used to identify tuples in the relation. Thus, a primary key is nothing but a candidate key that identifies a record uniquely. We use the convention that the attributes that form the primary key of a relation’s schema are underlined.

Symbol Name Atomic Number Melting Point Boiling Point

Al Aluminium 13 933 2792

Fe Iron 26 1811 3134

Ni Nickel 28 1728 3186

Cu Copper 29 1357 3200

Ag Silver 47 1235 2435

Au Gold 79 1337 3129

Table 3.3 Element table

In the table above, the attributes symbol, name, and atomic number uniquely identify each row, so any one can be candidate key, i.e. we can say that the ‘elementtable’ has three candidate keys. Since, the body of the relation is a set and sets do not contain duplicate elements, hence, at any given time no two tuples (rows) of a relation can be the same.

Let R be the relation of attributes A1, A2 … An. The set of attributes K = (Ai, Aj … An) of R is said to be a candidate key of R if and only if the following two properties are satisfied.

UniquenessAt any given time no two distinct tuples (rows) of R have the same value for Ai, the same value for Aj ….. and the same value for An.

MinimalityNo proper subset of the set (Ai, Aj … An) has the uniqueness property. Every relation has at least one candidate key, because at least the combination of all its attributes has the uniqueness property. In case of relations of a base table, one candidate key is designated as a primary key and the remaining candidate keys are alternate keys.

For example, in the table above, since the relation has three candidate keys any of them can be taken as a primary key. There are no hard and fast rules as to which key to choose as primary but it is a matter of preference and convenience for the database designers. Now, consider the table shown below.

Symbol Quality Destination

Al 100 Delhi Fe 500 Delhi Ni 5 Delhi Cu 150 Chennai Ag 400 KochiAu 2 Kolkata Au 30 Mumbai

Table 3.4 Shipment table

25

Consider the attribute item of relation in the ‘shipmenttable’. A given value for that item appears in the table only if the same value appears as the value of the primary key symbol in the ‘elementtable’. Such an attribute is called the foreign key.

A foreign key is a primary key for other table, in which it uniquely identifies a record. A foreign key defines relation between two (or more) tables. A foreign key can contain NULL value. A foreign key and the primary key should also be defined on the same underlined domain. A pictorial representation is given below.

ELEMENT_TABLESymbolName Atomic NumberMelting_PointBoiling Point

SHIPMETN_TABLEItemQuantityDestination

P♂ ♂

F

Fig. 3.2 Primary key-foreign key relationship

3.4 ConstraintsConstraints are logic rules that are used to ensure data consistency or avoid certain un-acceptable operations on the data i.e. its objective is to maintain the accuracy and integrity of the data in the database. Integrity constraints are rules, which all instances of the DB must satisfy in order to correctly model the real world. Any operation that would violate a declared constraint will be disallowed.

ExampleIt is impossible to violate the rules so long as no two tuples in the employee relation have the same ID.

ID Name Dept. Supervisor

1456 Brown 4 Null

3567 Jones 5 1456

1256 Smith 2 3567

Table 3.5 Employee Table

Employee relation real world rules: An employee has only one name is in one department, has one supervisor.The major types of integrity constraints are:

Domain constraints• Entity integrity constraints• Referential integrity constraints• Operational constraints•


26

3.4.1 Domain ConstraintsDomain constraints specify that the value of each attribute must be atomic from the domain. All the values taken from the column of a relation must be taken from the same domain. A domain is the set of values that may be assigned to an attribute.

A domain definition usually consists of following components:• Domain name �Meaning �Data-type �Size or length �Allowable values or allowable range �

For example in the ‘elementtable’, the domain for the column “symbol” is a character of length 2 and should be from the list of elements in periodic table, the first letter should be in capital. Similarly, the domain of the column atomic number is an integer.

3.4.2 Entity Integrity ConstraintEntity integrity constraint states that no part of a primary key field can contain NULL – if it did it would not be distinguishable from any other NULL.

Total participation constraints are encoded by insisting that the foreign key representing the relationship is NOT NULL. One may wish to specify that other attributes are required (i.e. not null).For example, every order must have a date associated with it. The primary key value is used to identify individual tuples in a relation. Thus, a null primary key value within a base relation would be like saying that there was some entity that has no known identity and we might not be able to distinguish them. An entity that cannot be identified is the contradiction in terms, hence, named entity integrity.

Entity integrity constraints are specified on the individual relations. In some cases, a particular attribute cannot • be assigned a data value. There are two situations where this is likely to occur.

There is no applicable data value. �Applicable data value is not known when the values are assigned. �

Consider a situation where you are filling your details, there is a column for Fax number and you don’t have • a Fax number. You will leave the field blank. This is an example of no applicable value. In another situation suppose you are filling values for an element in the ‘elementtable’, where you are required to fill in the melting point of gold. You don’t know the melting point of gold. So you have that field blank, since the information is not known at • that instance of time. The relational model allows you to assign a null value to an attribute in situations described above. The null value is the value that is assigned when no other value applies or when the applicable value is not known. In reality, a null is not a value, but rather the absence of a value. For example null is not same as 0 (in numeric • field) por blank (in character fields). The inclusion of nulls in the relational model is somewhat problematic because operations involving nulls sometimes generate unpredictable results. On the other hand using null for missing values is the good practice. But, it is imperative that the primary key values should be non-null.

27

3.4.3 Referential IntegrityOften, in relational database, we wish to ensure that a value that appears in one relation for a given set of attributes also appears for a certain set of attributes in another relation. This condition is called Referential Integrity (RI).

It is the concept of relationships between tables, based on the definition of a primary key and a foreign key.• The following table includes the important elements of referential integrity:•

Term Definition

Child Table A table, where the referential constraints are defined. A child table is synonymous with the referencing table.

Parent Table The table being referenced by a Child table. A Parent table is synonymous with the referenced table.

Primary Key A primary key uniquely identifies a row of a table.

Foreign Key A foreign key refers to columns in the Child table. A foreign key may consist of up to 16 columns.

Referencing columns Referencing columns are within a referencing table that are foreign keys for columns in some other referenced table.

Referenced columns Referenced columns are defined as either primary key columns or unique columns in a referenced table.

Table 3.6 Important elements of referential integrity

Importance of referential integrityBy providing specification of columns within a referencing table that are foreign keys for columns in some other referenced table, referential integrity is a reliable mechanism which prevents accidental database corruptions when doing inserts, updates, and deletes. It states that a row cannot exist in a table with a non-null value for a referencing column if an equal value does not exist in a referenced column.

For example, let’s suppose in customer_service database, there is a tuple t1 in the employee_phone relation with t1 [employee_number] = ‘1018’, but there is no tuple in the employee relation for the 1018. This situation would be undesirable.

We expect the employee relation to list all employee_number. Therefore, tuple t• 1 would refer to an employee that does not exist. Clearly, we would like to have an integrity constraint that prohibits this sort of situation. We could define employee_number in employee relation as a foreign key in employee_phone relation. Under this situation, employee is the referenced table, employee_name of employee table is the referenced column; • employee_phone is the referencing table, employee_name of employee_phone is the referencing column. Once we define the employee_number as a foreign key in employee_phone relation, if we try to insert a row • with a primary key value that does not exit in employee table, the system will not allow this insertion. This is the way the RDBMS maintains referential integrity. The following summarise the benefits of referential integrity:•

Ensure data integrity and consistency base on primary key and foreign key �Increases development productivity. �


28

Defining referential constraintsReferential constraint provide a means of ensuring that changes made to the database by authorised users do not result in a loss of data consistency.

The constraints are in the following forms:• Key declarations: � The stipulation that certain attributes form a candidate key for a given entity set. The set of legal insertions and updates is constrained to those that do not create two entities with the same value on a candidate key.Form of a relationship: � It forms a relationship like the following: Many to many, one to many, one to one. A one-to-one or one-to-many relationship restricts the set of legal relationships among entities of a collection of entity sets.

So in general, the referential constraint is the combination of the foreign key, the parent key, and the relationship between them. Proper definition of referential constraints not only allows us to test values inserted in the database, but also permits us to test queries to ensure that the comparisons made make sense.

The REFERENTIAL INTEGRITY RULE of the model states that, for every foreign key value in a table there • must be a corresponding primary key value in another table in the database. The parent key must exist when the referential constraint is defined, it must be either a unique primary index or a unique secondary index.

3.4.4 Operational ConstraintsThese constraints are forced in the database by the business rules or the real world limitations. For example, if the retirement age of the employees in an organisation is 60, then the age column of the employee table can have a constraint that age should be less than or equal to 60. These kinds of constraints, enforced by the business and the environment are called operational constraints.

3.5 Codd’s 12 RulesOne well-known definition of what constitutes a relational database system is Codd’s 12 rules. Codd’s 12 rules are a set of 12 rules proposed by Edgar F. Codd in 1970, a pioneer of the relational model for databases, designed to define what is required from a database management system in order for it to be considered relational, i.e., an RDBMS. He placed the rules in three main categories:

First, structural features that support the view of data. They include relations and their underlying components, • views and queries, both mechanisms for creating virtual queries.Second, integrity features such as entity and referential integrity and also application specific constraints.• Finally data manipulation features for data retrieval, insertion, deletion and update.•

For example, the system must qualify as relational, as a database, and as a management system. For a system to qualify as a relational database management system (RDBMS), that system must use its relational facilities (exclusively) to manage the database.

29

The rulesRule Description

Rule 1The information rule: All information in the database is to be represented in one and only one way, namely by values in column positions within rows of tables.

Rule 2

The guaranteed access rule: All data must be accessible with no ambiguity. This rule is essentially a restatement of the fundamental requirement for primary keys. It says that every individual scalar value in the database must be logically addressable by specifying the name of the containing table, the name of the containing column and the primary key value of the containing row.

Rule 3

Systematic treatment of null values: The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of “missing information and inapplicable information” that is systematic, distinct from all regular values (for example, “distinct from zero or any other number,” in the case of numeric values), and independent of data type. It is also implied that such representations must be manipulated by the DBMS in a systematic way.

Rule 4

Active online catalogue based on the relational model: The system must support an online, inline, relational catalogue that is accessible to authorised users by means of their regular query language. That is, users must be able to access the database’s structure (catalogue) using the same query language that they use to access the database’s data.

Rule 5

The comprehensive data sub-language rule: The system must support at least one relational language that

Has a linear syntax• Can be used both interactively and within application programs,• Supports data definition operations (including view definitions), data • manipulation operations (update as well as retrieval), security and integrity constraints, and transaction management operations (begin, commit, and rollback).

Rule 6 The view-updating rule: All views that are theoretically updatable must be updatable by the system.

Rule 7

High-level insert, update, and delete: The system must support set-at-a-time insert, update, and delete operators. This means that data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table.

Rule 8Physical data independence: Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure.

Rule 9

Logical data independence: Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence. For example, adding an attribute or column to the base table should not disrupt the programs or the interactive commands that have no use for the new attribute.


30

Rule 10

Integrity independence: Integrity constraints must be specified separately from application programs and stored in the catalogue. It must be possible to change such constraints as and when appropriate without unnecessarily affecting existing applications.

Rule 11

Distribution independence: The distribution of portions of the database to various locations should be invisible to users of the database. Existing applications should continue to operate successfully:

When a distributed version of the DBMS is first introduced; and• When existing distributed data are redistributed around the system.•

Rule 12The nonsubversion rule: If the system provides a low-level (record-at-a-time) interface, then that interface cannot be used to subvert the system, for example, bypassing a relational security or integrity constraint.

Table 3.7 Codd’s 12 Rules

Codd produced these rules as part of a personal campaign to prevent his vision of the relational database being diluted. Rule 12 was particularly designed to counter such a positioning. In fact, the rules are so strict that all popular so-called “relational” DBMSs fail on many of the criteria. However, many of the early implementations of the relational model did not conform to all of Codd’s rules, so the term gradually came to describe a broader class of database systems.

At a minimum, these systems:• Presented the data to the user as relations (a presentation in tabular form, i.e. as a collection of tables with �each table consisting of a set of rows and columns, can satisfy this property.)Provided relational operators to manipulate the data in tabular form. The most popular definition of an �RDBMS is a product that presents a view of data as a collection of rows and columns not based strictly upon relational theory. The majority of real world popular RDBMS products implement some of Codd’s 12 rules.

A second, theory-based school of thought argues that if a database does not implement all of Codd’s rules, it • is not relational. This view, shared by many theorists and other strict adherents to Codd’s principles, would disqualify most DBMSs as not relational. For clarification, they often refer to RDBMSs as Truly-Relational Database Management Systems (TRDBMS), • naming others Pseudo-Relational Database Management Systems (PRDBMS). Almost all DBMSes employ SQL as their query language. Alternative query languages have been proposed and implemented, but very few have become commercial products.

31

Summary The frustration with the inadequate capabilities of network and hierarchical databases resulted in the invention • of the relational data model.A relational database management system (RDBMS) is a database management system (DBMS) that is based • on the relational model as introduced by E. F. Codd in 1970.Relational databases are the most common kind of database in use today.• RDBMS is an acronym for Relational Database Management System. • A short definition of a RDBMS may be a DBMS in which data is stored in the form of tables and the relationship • among the data is also stored in the form of tables. The data in RDBMS is stored in database objects called tables. • The database tables are the primary data storage for every RDBMS and essentially they are collections of related • data entries. Each database table consists of columns and rows. • Each table column defines the type of data stored in it and this data type is valid for all rows in this table. • A table row is a collection of data having 1 entry for each column in this particular table. • As a simple explanation, relational data model allows various data packets/files to be related to each other with • a set of relations. An attribute is represented by a column of the table and attribute name is the name of the column such as • ‘identifier’, ‘name’, ‘city’ etc., attribute value contains the value for column in the row, and constraints are applied to the table and form a logical schema.The terminology associated with relational database theory originates from the branch of mathematics called • set theory although there are widely used synonyms for these precise, mathematical terms. Data structures are composed of two components, which represent a model of the situation being considered. • These are ENTITY TYPES, for example, data group types and RELATIONSHIPS between the entity types. The relational data model includes several types of constraints whose objective is to maintain the accuracy and • integrity of the data in the database.The number of attributes in a relation is called degree of the relation. A relation having degree one is called • unary, a relation with degree two is called binary etc.Constraints are logic rules that are used to ensure data consistency or avoid certain un-acceptable operations on • the data i.e. its objective is to maintain the accuracy and integrity of the data in the database.Domain constraints specify that the value of each attribute must be atomic from the domain.• Entity integrity constraint states that no part of a primary key field can contain NULL – if it did, it would not • be distinguishable from any other NULL. Often, in relational database, we wish to ensure that a value that appears in one relation for a given set of • attributes also appears for a certain set of attributes in another relation. This condition is called Referential integrity (RI).

ReferencesSumathi, S. & Esakkirajan, S., 2007. • Fundamentals of Relational Database Management Systems, Springer, Gillenson, M. L., 2008. • Fundamentals Of Database Management Systems,Wiley-India.Chin, S., and Orjan, 1999,• relational database management system (RDBMS., [Online] Available at< Timanhttp://searchsqlserver.techtarget.com/definition/relational-database-management-system> [Accessed 5 July 2011].2010, • Codd’s Rules, [Online]. Available at <http://www.wildewood.co.uk/comp/more/codds_rules.html> [Accessed 5 July 2011].


32

Janakiram, D., 2008. • Transaction Processing and Database Manager. [Video online] Available at: <http://www.youtube.com/watch?v=ldIbItnHX9o> [Accessed 9 September 2011]. Srinath, S., 2008.• Data Mining and Knowledge Discovery. [Video online] Available at: <http://www.youtube.com/watch?v=m5c27rQtD2E> [Accessed 9 September].

Recommended ReadingHaan, L.D., Daneil, F. & Morton, K.,2009. • Beginning Oracle SQL, Apress.Perry, J. T. & Newmark, R., 2011. • Building Accounting Systems Using Access 2010, Cengage Learning.Hernandez, M. J., 2003. • Database design for mere mortals: A hands-on guide to relational database design, Addison-Wesley.

33

Self Assessment Data in RDBMS is stored in _______.1.

tablea. entityb. attributes c. setsd.

The database tables are the ________ data storage for every RDBMS and essentially are collections of related 2. data entries.

virtual a. primaryb. secondary c. temporary d.

The __________ is implemented in database where a relation is represented by a table. 3. database model a. main model b. relational modelc. real model d.

A tuple is formed by one or more than one____________.4. elementsa. attributesb. pointsc. commandsd.

A tuple is represented by a _____.5. rowa. column b. tablec. characteristic d.

_________ types are represented by relations or base tables.6. Material a. Entityb. Attribute c. Integer d.

A column entry in any row is______. 7. single-valueda. dual-valuedb. double-valuedc. multiple-valuedd.


34

The terminology associated with relational database theory originates from the branch of mathematics called 8. ____ theory.

semia. short b. setc. small d.

The number of attributes in a relation is called ______of the relation.9. degreea. levelb. gradec. scaled.

Cardinality of a relation is defined as the number of _______in the relation.10. rowa. column b. tablec. entity d.

35

Chapter IV

Relational Database Management Systems and Normalisation

Aim


describe the key constraints•

explain the concept of normalisation and various normal forms•

explicate the design of a normalised database•

Objectives


elaborate on first normal forms•

explain the problems addressed by normalisation •

enlist the types of normal forms •

Learning outcome


describe relational database design •

understand concept of key constraints •

describe the concept of normalisation•


36

4.1 Relational Database DesignDatabase normalisation is performed while designing a relational database to improve the logical consistency of the database design and the transactional performance. There are two commonly used systems of diagramming to aid in the visual representation of the relational model:

The entity-relationship diagram (ERD) • The related IDEF diagram •

These are the ones used in the IDEF1X method created by the U.S. Air Force based on ERDs. The tree structure of data may enforce hierarchical model organisation, with parent-child relationship table.

For example, a simple description of some relvar and their attributes is as follows:Customer (Customer ID, Tax ID, Name, Address, City, State, Zip, Phone) • Order (Order No, Customer ID, Invoice No, Date Placed, Date Promised, Terms, Status) • Order Line (Order No, Order Line No, Product Code, Qty) • Invoice (Invoice No, Customer ID, Order No, Date, Status) • Invoice Line (Invoice No, Line No, Product Code, Qty Shipped) • Product (Product Code, Product Description).•

In this design we have six relvars constraint namely, Customer, Order, Order Line, Invoice, Invoice Line and Product.

The bold, underlined attributes are candidate keys. The non-bold, underlined attributes are foreign keys. Usually one candidate key is arbitrarily chosen to be called the primary key and used in preference over the other candidate keys, which are then called alternate keys. A candidate key is a unique identifier enforcing that no tuple will be duplicated; this would make the relation into something else, namely a bag, by violating the basic definition of a set.

Both foreign keys and superkeys (which include candidate keys) can be composite, that is, can be composed of several attributes. Below is a tabular depiction of a relation of our example of Customer relvar; a relation can be thought of as a value that can be attributed to a relvar.

Customer ID Tax ID Name Address [More Fields...]

1234567890 555-5512222 Munira 323 Broadway ...

2223344556 555-5523232 Akshta 1200 Main Street ...

3334445563 555-5533322 Nira 871 1st Street ...

4232342432 555-5325523 E. F. Codd 123 It Way ...

Table 4.1 Customer relation

If we attempt to insert a new customer with the ID 1234567890, this would violate the design of the relvar since • Customer ID is a primary key and we already have a customer 1234567890. The DBMS must reject a transaction such as this that would render the database inconsistent by a violation of an integrity constraint. Foreign keys are integrity constraints enforcing that the value of the attribute set is drawn from a candidate key in another relation, for example in the order relation, the attribute Customer ID is a foreign key.

37

A join is the operation that draws on information from several relations at once. By joining relvars from the • example above we could query the database for all of the Customers, Orders, and Invoices. If we only wanted the tuples for a specific customer, we would specify this using a restriction condition. If we wanted to retrieve all of the Orders for Customer 1234567890, we could query the database to return every row in the Order table with Customer ID 1234567890 and join the Order table to the Order Line table based on Order No. There is a flaw in our database design above. The Invoice relvar contains an Order No attribute. So, each tuple in the Invoice relvar will have one Order No, • which implies that there is precisely one Order for each Invoice. But in reality an invoice can be created against many orders, or indeed for no particular order. Additionally the Order relvar contains an Invoice No attribute, implying that each Order has a corresponding Invoice. But again this is not always true in the real world. An order is sometimes paid through several invoices, and sometimes paid without an invoice.

In other words there can be many Invoices per Order and many Orders per Invoice. This is a many-to-many relationship between Order and Invoice (also called a non-specific relationship). To represent this relationship in the database a new relvar should be introduced whose role is to specify the correspondence between Orders and Invoices:

Order Invoice (Order No, Invoice No)The Order relvar has a one-to-many relationship to the Order Invoice table, as does the Invoice relvar. • If we want to retrieve every Invoice for a particular Order, we can query for all orders in the Order No. in Order • relation equals the Order No in Order Invoice and the Invoice No in Order Invoice table equals the Invoice No in Invoice table.

Set-theoretic formulationBasic notions in the relational model are relation names and attribute names. We will represent these as strings such as “Person” and “name” and we will usually use the variables and a, b, c to range over them. Another basic notion is the set of atomic values that contains values such as numbers and strings.

Our first definition concerns the notion of tuple, which formalises the notion of row or record in a table:• Tuple: � A tuple is a partial function from attribute names to atomic values.Header: � A header is a finite set of attribute names. The next definition defines relation which formalises the contents of a table as it is defined in the relational model.Relation: � A relation is a tuple (H, B) with H, the header, and B, the body, a set of tuples that all have the domain H.

Such a relation closely corresponds to what is usually called the extension of a predicate in first-order logic • except that, here, we identify the places in the predicate with attribute names. Usually in the relational model a database schema is said to consist of a set of relation names, the headers that are associated with these names and the constraints that should hold for every instance of the database schema.

Relation universe: � A relation universe U over a header H is a non-empty set of relations with header H.Relation schema: � A relation schema (H,C) consists of a header H and a predicate C(R) that is defined for all relations R with header H. A relation satisfies a relation schema (H, C) if it has header H and satisfies C.

4.2 Key ConstraintsOne of the simplest and most important types of relation constraints is the key constraint. It tells us that in every instance of a certain relational schema the tuples can be identified by their values for certain attributes.

SuperkeyA superkey is written as a finite set of attribute names. A superkey K holds in a relation (H, B) if and only if there exist no two distinct tuples such that t1 [K] = t2 [K]. A superkey holds in a relation universe U if it holds in all relations in U.


38

4.3 Introduction to NormalisationDatabase normalisation is a technique for designing relational database tables to minimise duplication of information and, in doing so, to safeguard the database against certain types of logical or structural problems, namely data anomalies.

For example, when multiple instances of a given piece of information occur in a table, the possibility exists that these instances will not be kept consistent when the data within the table is updated leading to a loss of data integrity.

A table that is sufficiently normalised is less vulnerable to problems of this kind because its structure reflects • the basic assumptions for when multiple instances of the same information should be represented by a single instance only. Higher degrees of normalisation typically involve more tables and create the need for a larger number of joins, which can reduce performance. Accordingly, more highly normalised tables are typically used in database applications involving many isolated transactions (e.g. an Automated teller machine), while less normalised tables tend to be used in database applications that do not need to map complex relationships between data entities and data attributes (for example, a reporting application or a full-text search application).

4.3.1 Problems Addressed by NormalisationA table that is not sufficiently normalised can suffer from logical inconsistencies of various types, and from anomalies involving data operations such as:

An update anomalyThe same information can be expressed on multiple records; therefore, updates to the table may result in logical inconsistencies.

For example, each record in an “Employees’ Skills” table might contain an Employee ID, Employee Address, and Skill; thus, a change of address for a particular employee will potentially need to be applied to multiple records (one for each of his skills).

If the update is not carried through successfully if, that is, the employee’s address is updated on some records �but not others then the table is left in an inconsistent state.Specifically, the table provides conflicting answers to the question of what this particular employee’s address �is. This phenomenon is known as an update anomaly.

An insertion anomalyThere are circumstances in which certain facts cannot be recorded at all.

For example, each record in a “Faculty and Their Courses” table might contain a Faculty ID, Faculty Name, Faculty Hire Date, and Course Code thus we can record the details of any faculty member who teaches at least one course, but we cannot record the details of a newly hired faculty member who has not yet been assigned to teach any courses. This phenomenon is known as an insertion anomaly.

A deletion anomalyThere are circumstances in which the deletion of data representing certain facts necessitates the deletion of data representing completely different facts. The “Faculty and Their Courses” table described in the previous example suffers from this type of anomaly, for if a faculty member temporarily ceases to be assigned to any courses, we must delete the last of the records on which that faculty member appears. This phenomenon is known as a deletion anomaly.

Ideally, a relational database table should be designed in such a way as to exclude the possibility of update, insertion, and deletion anomalies. The normal forms of relational database theory provide guidelines for deciding whether a particular design will be vulnerable to such anomalies. It is possible to correct glitches in design so as to make it

39

adhere to the demands of the normal forms: this is called normalisation. Normalisation typically involves decomposing anomalies table into two or more tables that were they to be combined (joined), would convey exactly the same information as the original table.

4.4 Normal Forms Database theory describes a table’s degree of normalisation in terms of normal forms of successively higher degrees of strictness. A table in third normal form (3NF), for example, is consequently in second normal form (2NF) as well; but the reverse is not always the case. Although the normal forms are often defined informally in terms of the characteristics of tables, rigorous definitions of the normal forms are concerned with the characteristics of mathematical constructs known as relations.

Whenever information is represented relationally, it is meaningful to consider the extent to which the • representation is normalised. Edgar F. Codd first proposed the process of normalisation .The normal forms (abbrev. NF) of relational database theory provide criteria for determining a table’s degree of vulnerability to logical inconsistencies and anomalies. The higher the normal form applicable to a table, the less vulnerable it is to such inconsistencies and anomalies. Each table has a “highest normal form” (HNF): by definition, a table always meets the requirements of its HNF • and of all normal forms lower than its HNF; also by definition, a table fails to meet the requirements of any normal form higher than its HNF. The normal forms are applicable to individual tables; to say that an entire database is in normal form n is to say • that all of its tables are in normal form n. Edgar F. Codd originally defined the first three normal forms (1NF, 2NF, and 3NF). These normal forms are summarised as all non-key attributes depend only on the key.The fourth and fifth normal forms (4NF and 5NF) deal specifically with the representation of many-to-many • and one-to-many relationships among attributes. Sixth normal form (6NF) incorporates considerations relevant to temporal databases. The forms of normalisation are as follows:

4.4.1 First Normal Form (INF)First normal form (INF) is now considered to be part of the formal definition of a relation in the basic (flat) relational model. It states that the domain of an attribute must include only atomic (simple, indivisible) values and that the value of any attribute in a tuple must be a single value from the domain of that attribute.

Thumb RuleA relation R is in first normal form (1NF) if and only if all underlying domains contain atomic values only. First normal form (1NF) sets the very basic rules for an organised database:

Eliminate duplicative columns from the same table.• Create separate tables for each group of related data and identify each row with a unique column or set of • columns (the primary key).

For example, consider the DEPARTMENT relation schema whose primary key is DNO. This includes the attribute DLOC and we assume that each department can have a number of locations.As shown in the table given below, this is not in 1NF since DLOC is not an atomic attribute.

DNAME DNO DMGRSSN DLOC

Research 3 23561161 (Bombay, Bangalore, Chennai)

Administration 2 87611676 Bombay

Headquarters 1 53416787 Chennai

Table 4.2 Department relation showing lack of atomicity


40

The department relation is not in 1NF. DEPT_LOCATIONS along with the primary key DNO as shown in table given below. Then the primary key of this relation is (DNO, DLOC).

DNO DLOC

1 Chennai

2 Bombay

3 Bombay

3 Bangalore

3 Chennai

Table 4.3 Department relation in 1NF

Expand the primary key in table so that there will be a separate tuple in the original DEPARTMENT relation for each location of a department. Here primary key becomes {DNO, DLOC}. The disadvantage of this solution is redundancy in relation as shown in table given below.

DNAME DNO DMGRSSN DLOC

Research 3 23561161 Bombay

Administration 2 87611676 Bombay

Headquarters 1 53416787 Chennai

Research 3 23561161 Bangalore

Research 3 23561161 Chennai

Table 4.4 Department relation in 1NF

4.4.2 Second Normal Form (2NF)A relation R is in second normal form (2NF) if and only if it is in 1NF and every non-key attribute is fully dependent on the primary key.

Thumb RuleThe criteria for second normal form (2NF) are:

The table must be in 1NF.• None of the non-prime attributes of the table are functionally dependent on a part (proper subset) of a candidate • key; in other words, all functional dependencies of non-prime attributes on candidate keys are full functional dependencies.

Note that if none of a 1NF table’s candidate keys are composite, for example, every candidate key consists of just one attribute then we can say immediately that the table is in 2NF.Consider the table below describing employees’ skills:

41

Employee Skill Current Work Location

Jones Typing 114 Main Street

Jones Shorthand 114 Main Street

Jones Whittling 114 Main Street

Roberts Light Cleaning 73 Industrial Way

Ellis Alchemy 73 Industrial Way

Ellis Juggling 73 Industrial Way

Harrison Light Cleaning 73 Industrial Way

Table 4.5 Employees’ skills

The table’s only candidate key is {Employee, Skill}. The remaining attribute, Current Work Location, is dependent on only part of the candidate key, namely Employee. Therefore the table is not in 2NF. Note the redundancy in the way Current Work Locations are represented we are told three times that Jones works at 114 Main Street, and twice that Ellis works at 73 Industrial Way. This redundancy makes the table vulnerable to update anomalies: it is, for example, possible to update Jones’ work location on his “Typing” and “Shorthand” records and not update his “Whittling” record.

A 2NF alternative to this design would represent the same information in two tables table given below:•

Employee Current Work location

Jones 114 Main Street

Roberts 73 Industrial Way

Ellis 73 Industrial Way

Harrison 73 Industrial Way

Table 4.6 (a) Employees

Employee Skill

Jones Typing

Jones Shorthand

Jones Whittling

Roberts Lighting Cleaning

Ellis Alchemy

Ellis Juggling

Harrison Light Cleaning

Table 4.6 (b) Employees’ skills


42

Update anomalies cannot occur in these tables, which are both in 2NF. Not all 2NF tables are free from update • anomalies, however. An example of a 2NF table which suffers from update anomalies is:

Tournament Year Winner Winner Date of Birth

Des Moines Masters 1998 Chip Masterson 14 March 1977

Indiana Invitational 1998 Al Fredrickson 21 July 1975

Cleveland Open 1999 Bob Albertson 28 September 1968

Des Moines Masters 1999 Al Fredrickson 21 July 1975

Indiana Invitational 1999 Chip Masterson 14 March 1977

Table 4.7 Tournament winners

Even though Winner and Winner Date of Birth are determined by the whole key Tournament, Year} and not • part of it, particular Winner / Winner Date of Birth combinations are shown redundantly on multiple records. This problem is addressed by third normal form (3NF).

4.4.3 Third Normal Form A relation R is in third normal form (3NF) if and only if it is in 2NF and every non-key attribute is non-transitively dependent on the primary key. An attribute C is transitively dependent on attribute A, if there exists an attribute B such that: A ’! B and B ’! C. Note that 3NF is concerned with transitive dependencies which do not involve candidate keys.

A 3NF relation with more than one candidate key will clearly have transitive dependencies of the form: primary key ’! other_candidate_key ’! Any_non-key_column .For relations with just one candidate key, this is equivalent to the simpler: A relation R having just one candidate key is in third normal form (3NF) if and only if no non-key column (or group of columns) determines another non-key column (or group of columns).

For relations with just one candidate key, this is equivalent to the simpler: A relation R having just one candidate key is in third normal form (3NF) if and only if no non-key column (or group of columns) determines another non-key column (or group of columns).

Thumb ruleThe criteria for third normal form (3NF) are:

The table must be in 2NF.• Every non-prime attribute of the table must be non-transitively dependent on every candidate key. A violation • of 3NF would mean that at least one non-prime attribute is only indirectly dependent (transitively dependent) on a candidate key.

For example, an example of a 2NF table that fails to meet the requirements of 3NF is as shown in the above table. The only candidate key is {Tournament, Year}. The breach of 3NF occurs because the non-prime attribute Winner Date of Birth is transitively dependent on {Tournament, Year} via the non-prime attribute Winner. The fact that Winner Date of Birth is functionally dependent on Winner makes the table vulnerable to logical inconsistencies, as there is nothing to stop the same person from being shown with different dates of birth on different records.In order to express the same facts without violating 3NF, it is necessary to split the table into two tables given below:

43

Tournament Year Winner

Indiana Invitational 1998 Al Fredrickson

Cleveland Open 1999 Bob Albertson

Des Moines Masters 1999 Al Frederickson

Indiana Invitational 1999 Chip Masterson

Table 4.8 (a) Tournament winners

Player Date of Birth

Chip Masterson 14 March 1977

Al Fredrickson 21 July 1975

Bob Albertson 28 September 1968

Table 4.8 (b) Player dates of birth

Update anomalies cannot occur in these tables, which are both in 3NF.

4.4.4 Boyce-Codd Normal FormA relation R is in Boyce-Codd normal form (BCNF) if and only if every determinant is a candidate key. When a relation has more than one candidate key, anomalies may result even though the relation is in 3NF.

3NF does not deal satisfactorily with the case of a relation with overlapping candidate keys i.e. composite candidate keys with at least one attribute in common. BCNF is based on the concept of a determinant. A determinant is any attribute (simple or composite) on which some other attribute is fully functionally dependent.

Thumb Rule A relation is in BCNF is, and only if, every determinant is a candidate key.Consider the following relation and determinants.

R (a,b,c,d)• a, c -> b ,d• a, d -> b•

Here, the first determinant suggests that the primary key of R could be changed from a, b to a, c. If this change was done all of the non-key attributes present in R could still be determined, and therefore this change is legal.

However, the second determinant indicates that a, d determines b, but a, d could not be the key of R as a, d does not determine the entire non key attributes of R (it does not determine c). The first determinate is a candidate key, but the second determinant is not a candidate key, and thus this relation is not in BCNF (but is in 3rd normal form).


44

Patient No Patient Name Appointment Id Time Doctor

1 John 0 09:00 Zorro

2 Kerr 0 09:00 Killer

3 Adam 1 10:00 Zorro

4 Robert 0 13:00 Killer

5 Zane 1 14:00 Zorro

Table 4.9 Normalisation to BCNF

Let’s consider the database extract shown in above table. This depicts a special dieting clinic where the each patient has 4 appointments. On the first they are weighed, the second they are exercised, the third their fat is removed by surgery.

Not all patients need all three appointments! If the Patient Name begins with a letter before “P” they get a morning appointment, otherwise they get an afternoon appointment.

Appointment 1 is either 09:00 or 13:00, appointment 2 is 10:00 or 14:00, and so on. From this we can extract the following determinants:

DB(Patno,PatName,appNo,time,doctor)Patno -> PatNamePatno,appNo -> Time,doctorTime -> appNo

Now we have to decide what the primary key of DB is going to be. From the information we have, we could chose:

DB (Patno, PatName, appNo, time, doctor) (example a)orDB (Patno, PatName, appNo, time, doctor) (example b) Example a - DB (Patno, PatName, appNo, time, doctor

1NF Eliminate repeating groups. None:DB (Patno, PatName, appNo, time, doctor) 2NF Eliminate partial key dependenciesDB (Patno, appNo, time, doctor)R1 (Patno, PatName) 3NF Eliminate transitive dependenciesNone: As just as 2NF BCNF Every determinant is a candidate keyDB (Patno, appNo, time, doctor)R1 (Patno, PatName) Go through all determinates where ALL of the left hand attributes are present in a

relation and at least ONE of the right hand attributes are also present in the relation. Patno -> PatName

45

Patno is present in DB, but not PatName, so not relevant.Patno, appNo -> Time, doctor

All LHS present, and time and doctor also present, so relevant. Is this a candidate key? Patno,appNo IS the key, so this is a candidate key. Thus this is OK for BCNF compliance.

Time -> appNoTime is present, and so is appNo, so relevant. Is this a candidate key? If it was then we could rewrite DB as:DB (Patno, appNo, time, doctor)This will not work, as you need both time and Patno together to form a unique key. Thus this determinate is not a candidate key, and therefore DB is not in BCNF. We need to fix this.

BCNF: rewrite toDB (Patno, time, doctor)R1 (Patno, PatName)R2 (time, appNo)Time is enough to work out the appointment number of a patient. Now BCNF is satisfied, and the final relations shown are in BCNF.Example b - DB (Patno, PatName, appNo, time, and doctor)

1NF Eliminate repeating groups. None:DB (Patno, PatName, appNo, time, doctor)

2NF Eliminate partial key dependenciesDB (Patno, time, doctor)R1 (Patno, PatName)R2 (time, appNo)

3NF Eliminate transitive dependenciesNone: so just as 2NF

BCNF Every determinant is a candidate keyDB(Patno,time,doctor)R1(Patno,PatName)R2(time,appNo)Go through all determinates where ALL of the left hand attributes are present in a relation and at least ONE of the right hand attributes are also present in the relation.

Patno -> PatNamePatno is present in DB, but not PatName, so not relevant.

Patno, appNo -> Time, doctorNot all LHS present, so not relevant.

Time -> appNoTime is present, and so is appNo, so relevant. This is a candidate key.However, Time is currently the key for R2, so satisfies the rules for BCNF.

BCNF: as 3NFDB (Patno, time, doctor)R1 (Patno, PatName)R2 (time, appNo)

4.4.5 Fourth Normal Form (4NF) To be in fourth normal form, a relation must first be in Boyce-Codd normal form. Additionally, a given relation may not contain more than one multi-valued dependency. We can use the given multi-valued dependencies to improve the database design by decomposing it into fourth normal form. A relation schema R is in 4NF with respect to a set D of functional and multi-valued dependencies if for all multi-valued dependencies in of the form a’!’!b, where aÍR and b Í R, at least one of the following hold:

a’!’!b is a trivial multi-valued dependency.a is a superkey for schema R.


46

Thumb ruleA database design is in 4NF if each member of the set of relation schemas is in 4NF.The definition of 4NF differs from the BCNF definition only in the use of multi-valued dependencies. Every 4NF schema is also in BCNF. To see why, note that if a schema is not in BCNF, there is a nontrivial functional dependency a’!b holding on R, where a is not a superkey. Since a’!b implies a’!’!b, by the replication rule, R cannot be in 4NF. If we are given a set of functional and multi-valued dependencies, it is best to find a database design that meets the three criteria:

4NF.• Dependency Preservation.• Lossless-join.•

If we only have functional dependencies, the first criteria are just BCNF. We cannot always meet all three criteria. When this occurs, we compromise on 4NF, and accept BCNF, or even 3NF if necessary, to ensure dependency preservation.

47

Summary Database normalisation is usually performed when designing a relational database to improve the logical • consistency of the database design and the transactional performance.The DBMS must reject a transaction that would render the database inconsistent by a violation of an integrity • constraint.Foreign keys are integrity constraints enforcing that the value of the attribute set is drawn from a candidate key • in another relation; for example, in the order relation the attribute Customer ID is a foreign key. The Invoice relvar contains an Order No attribute. So, each tuple in the Invoice relvar will have one Order No, • which implies that there is precisely one order for each invoice. But in reality an invoice can be created against many orders or indeed for no particular order.Additionally, the Order relvar contains an Invoice number attribute, implying that each order has a corresponding • invoice. But again, this is not always true in the real world. An order is sometimes paid through several invoices, and sometimes paid without an invoice. • The Order relvar has a one-to-many relationship to the Order-Invoice table, as does the Invoice relvar. • A header is a finite set of attribute names. It is a relation which formalises the contents of a table as it is defined • in the relational model.A relation is a tuple (H, B) with H, the header, and B, the body, a set of tuples that all have the domain H.• One of the simplest and most important types of relation constraints is the key constraint. It tells us that in every • instance of a certain relational schema the tuples can be identified by their values for certain attributes. Database normalisation is a technique for designing relational database tables to minimise duplication of • information and, in so doing, to safeguard the database against certain types of logical or structural problems, namely data anomalies. The normal forms of relational database theory provide guidelines for deciding whether a particular design will • be vulnerable to such anomalies. It is possible to correct glitches in design so as to make it adhere to the demands of the normal forms called and • this process is called normalisation. The higher the normal form applicable to a table, the less vulnerable it is to such inconsistencies and • anomalies. Each table has a “highest normal form” (HNF) by definition, a table always meets the requirements of its HNF • and of all normal forms lower than its HNF; also by definition, a table fails to meet the requirements of any normal form higher than its HNF.

ReferencesBarrier Reef Institute of TAFE, 2001, • Introduction to Normalisation. [Online] Available at: <http://tle.tafevc.com.au/toolbox/file/f567850b-9966-154c-cd52-6025f598004f/1/306_02.zip/content/normalisation/normalisation_intro.htm>. [Accessed 7 July 2011].Haithcoat, T., Veenstra, P., • Relational Database Management Systems, Database Design, and GIS. [Pdf] Available at: <http://msdis.missouri.edu/presentations/gis_advanced/pdf/Relational.pdf> [Accessed 7 July 2011].Janakiram, D., 2008. • Transaction Processing and Database Manager. [Video online] Available at: <http://www.youtube.com/watch?v=5ammL5KU4mo> [Accessed 9 September 2011]. Janakiram, D., 2008. • Concurrency Control Part – 3. [Video online] Available at: <http://www.youtube.com/watch?v=-EJa_I_4-vg> [Accessed 9 September 2011]. Kedar, S., 2009. • GUI and Database Management, Technical Publications. Ray, 2010. • Distributed Database Systems, Pearson.


48

Recommended ReadingSchulman, J., 2006. • Managing your patients’ data in the neonatal and pediatric ICU: an introduction to databases and statistical analysis, Wiley-Blackwel.Group, I., .• Introduction to Database Management Systems, Tata McGraw-Hill Education.Sumathi, S. & Esakkirajan, S., • .Fundamentals of Relational Database Management Systems, Springer.

49

Self AssessmentThe entity-relationship diagram (ERD) and the related IDEF diagram used in the IDEF1X method has been 1. created by the ____________based on ERDs.

U.S. Air Forcea. U.S. Navy b. U.S. Army c. U.S. Government d.

The DBMS must reject a transaction that would render the database inconsistent by a violation of an 2. ____________constraint.

dishonestya. reliabilityb. integrityc. key d.

One of the simplest and most important types of relation constraints is the ___________constraint.3. keya. integrity b. superkey c. foreign d.

A _________ is the operation that draws on information from several relations at once. 4. linka. bondb. unitec. joind.

A relation R is in _________normal form, if and only if every determinant is a candidate key.5. E. F. Codda. Boyce-Coddb. Faginc. Collin Whited.

When a relation has more than one candidate key, anomalies may result even though the relation is 6. in_________.

2NFa. 4NFb. 5NFc. 3NFd.

Which of the following statements is false?? 7. 3NF does not deal satisfactorily with the case of a relation with overlapping candidate keys. a. BCNF is based on the concept of a determinant.b. A relation is in BCNF is, and only if, every determinant is a candidate key.c. A relation is in BCNF is, and only if, every determinant is a parent key.d.


50

Which of the following statements is true??8. A relation R is in first normal form (1NF) if and only if all underlying domains contain atomic structures a. only.A relation R is in first normal form (1NF) if and only if all underlying domains contain atomic values b. only.A relation R is in first normal form (1NF) if and only if all underlying domains contain atomic formulas c. only.A relation R is in first normal form (1NF) if and only if all underlying domains contain atomic weights d. only.

Normalisation process was developed by_________.9. E. F. Codda. R. F. Boyceb. R. Faginc. Collin Whited.

Name the process which corrects glitches in design so as to make it adhere to the demands of the normal 10. forms.

neutralisationa. stagnationb. normalisationc. organisationd.

51

Chapter V

Database Design and Entity-Relationship Modelling

Aim


explain the design process•

explain alternative design method •

explicate Entity- Relationship Model •

Objectives


elucidate conceptual schema •

explain logically structuring data •

enlist the component of an E-R model •

Learning outcome


describe the entity-relationship diagram •

understand the other styles of ER diagram •

determine the data to be stored•


52

5.1 Introduction of Design ProcessDatabase design is the process of producing a detailed data model of a database. This logical data model contains all the needed logical and physical design choices and physical storage parameters needed to generate a design in a Data Definition Language, which can then be used to create a database. A fully attributed data model contains detailed attributes for each entity. The term database design can be used to describe many different parts of the design of an overall database system. Principally, and most correctly, it can be thought of as the logical design of the base data structures used to store the data. However, the term database design could also be used to apply to the overall process of designing, not just the base data structures, but also the forms and queries used as part of the overall database application within the Database Management System or DBMS.

5.1.1 Design ProcessThe process of doing database design generally consists of number of steps which will be carried out by the database designer. Not all of these steps will be necessary in all cases. Usually, the designer must do the following:

Determine the data to be stored in the database.• Determine the relationships between the different data elements.• Superimpose a logical structure upon the data on the basis of these relationships.•

Data to be stored

Superimpose a logical structure

upon the data

Determine relationship between

different Data

Fig. 5.1 Design process

Within the relational model the final step can generally be broken down into two further steps: Determining the grouping of information within the system, generally determining what are the basic objects • about which information is being stored.Determining the relationships between these groups of information or objects. •

The tree structure of data may enforce a hierarchical model organisation with a parent-child relationship table. An object database will simply use a one-to-many relationship between instances of an object class. It also introduces the concept of a hierarchical relationship between object classes termed inheritance.

53

Following are the elements in a design process:

Determining data to be

stored

Conceptual schema

Logically structuring

data

Physical database design

Fig. 5.2 Flow of design process

Determining the data to be storedThe data to be stored in the database must be determined in cooperation with a person who does have expertise • in that domain and who is aware of what data must be stored within the system. Above mentioned process is one which is generally considered as a part of requirements analysis and requires skill on the part of the database designer to elicit the needed information from those with the domain knowledge. It is required because those with the necessary domain knowledge frequently fail to express clearly what their • system requirements for the database are as they are unaccustomed to thinking in terms of the discrete data elements which must be stored. The outcome of this phase is the specification of the user requirements.

Conceptual schemaOnce a database designer is aware of the data, which is to be stored within the database, they must determine • how the various pieces of that data relate to one another.When performing this step, the designer is generally looking out for the dependencies in the data, where one • piece of information is dependent upon another, for example, when one piece of information changes, the other will also.

For example, in a list of names and addresses, the address is dependent upon the name, because if the name is different then the associated address is different too. However, the inverse is not necessarily true, i.e. when the address changes name may be the same. Consider another example, assuming the normal situation where two people can have the same address but one person cannot have two addresses.

Next the designer chooses the data model. The entity-relationship model is typically used to represent the conceptual design. Conceptual design provides the graphical representation of the schema.

Logically structuring dataOnce the relationships and dependencies amongst the various pieces of information have been determined, it is • possible to arrange the data into a logical structure which can then be mapped into the storage objects supported by the database management system. In the case of relational databases, the storage objects are tables which store data in rows and columns. Each • table may represent an implementation of either a logical object or a relationship joining one or more instances of one or more logical objects. Relationships between tables may then be stored as links connecting child tables with parents. Since complex • logical relationships are nothing but tables, they probably have links to more than one parent.

Physical database designThe physical design of the database specifies the physical configuration of the database on the storage media. • The designer uses the resulting system-specific database schema in the subsequent physical-design phase in • which the physical features of the database are specified. These features include the form of file organisation and the internal storage structures.


54

5.1.2 Design AlternativesA major part of the database design process is deciding how to represent the design containing various types of “things” such as people, places, products and the one which collectively referred to as an entity. While designing the databases, we must ensure that we avoid two major pitfalls.

Redundancy: • It refers to the information being repeated at various places in database. Information should appear in exactly one place in order to ensure consistency of data.Incompleteness: • A bad design may make certain aspects of the enterprise difficult or impossible to model. Such incompleteness is unattractive and may be prevented with primary key.

5.2 The Entity-Relationship ModelER diagrams were originally proposed in 1976 by Dr. Pin-Shan Chen. It is intended primarily for the database design process by allowing the specification of an enterprise scheme. This represents the overall logical structure of the database.

Entity-relationship model is a data modelling method used to model a system and its requirements in a top-• down approach. This approach is commonly used in database design. The diagrams created using this method are called ER diagrams. An entity-relationship model (ERM) is a representation of structured data and entity-relationship modelling is the process of generating these models. The end-product of the modelling process is an entity-relationship diagram (ERD) or ER diagram, a type of • conceptual data model or semantic data model. The E-R (entity-relationship) data model views the real world as a set of basic objects (entities) and relationships among these objects. The first stage of information system design uses these models during the requirements analysis to describe • information needs or the type of information that is to be stored in a database. In case of the design of an information system that is based on a database, the conceptual data model is mapped to a logical data model, such as the relational model. This in turn is mapped to a physical model during physical design. The notation for ER diagrams are as follows:•

Symbol Meaning

Entity

Weak Entity

Relationship

Identifying Relationship

55

Attribute

Key Attribute

Multi valued Attribute

Composite Attribute

Derived Attribute

E1 E2R Total Participation of E2 in R

E1 E2R

1 NCardinality Ratio 1:N for E1:E2 in R

E2R

min, max Structural Constraint (min,max) on partici-pation of E in R

Fig. 5.3 Notations for ER diagrams


56

People

City Population

Names

Lives in

Fig. 5.4 An example of an ER diagram

For example, consider a database that contains information on the residents of a city. The ER diagram shown in the image above contains two entities - people and cities. There is a single “Lives In” relationship. In our example, due to space constraints, there is only one attribute associated with each entity. People have names and cities have populations. In a real-world example, each one of these would likely have many different attributes.

5.3 Components of an E-R ModelThe E-R model forms the basis of the ER diagrams. The ERDs comprise of three main components, namely entities, attributes, and relationships.

People

Names

Lives in

Fig. 5.5 Component of an E-R model

5.3.1 Entities and Entity SetsAn entity is an object that exists and is distinguishable from other objects. Entity is the fundamental item in any data model.

An entity may be concrete (a person or a book, for example) or abstract (like a holiday or a concept). Each • uniquely identifiable instance of an entity type is referred to as an entity occurrence or entity instance. Thus, an entity set is a set of entities of the same type (for example, all persons having an account at a bank).Entity sets need not be disjoint. For example, the entity set employee (all employees of a bank) and the entity • set customer (all customers of the bank) may have members in common.An entity has a name and is represented by a set of attributes. For example, name, Cust_Id, street, city for • “customer” entity.The domain of the attribute is the set of permitted values (For example, the telephone number must be seven • positive integers).

57

An analogy can be made with the programming language notion of type definition. The concept of an entity set corresponds to the programming language type definition. A variable of a given type has a particular value at a point in time. Thus, a programming language variable corresponds to an entity in the E-R model.

5.3.2 AttributesFormally, an attribute is a function which maps an entity set into a domain. Every entity is described by a set of (attribute, data value) pairs. There is one pair for each attribute of the entity set. For example, a particular customer entity is described by the set {(name, Rama), (Cus_Id., 120- 123-456), (street, North), (city, Bombay)}. It is possible to define a set of entities and the relationships among them in a number of different ways. The main difference is in how we deal with attributes.

For example, consider the entity set employee with attributes employee-name and phone number. We could treat phone as an entity itself, with attributes phone-number and location.

Then we have two entity sets, and the relationship set EmpPhn defining the association between employees and • their phones. This new definition allows employees to have several (or zero) phones. New definition may more accurately reflect the real world. We cannot extend this argument easily to making • employee-name an entity. The question of what constitutes an entity and what constitutes an attribute depends mainly on the structure of the real world situation being modelled and the semantics associated with the attribute in question.Each attribute is associated with the set of values called as domain. The domain defines the potential values • that an attribute can hold. For example, if the age of the student in class is between 14 and 17 then, we can define a set of values for the age attribute of the student entity as the set of integers between 14 and 17. Attributes may share a domain.• For example, the date-of-birth attributes for both the teacher and student entities can share the same domain. Domain can be composed of more than one domain. • For example, the domain for the date-of-birth attribute is made up of sub-domains-day, month and year. A fully developed data model includes domains for each attribute in the E-R model.•

Attributes can be characterised into following types:

Types of Attributes

Simple and Composite Attributes

Null Attributes

Derived attributes

Single valued and multi-valued

attribute

Fig. 5.6 Types of attribute

Simple and composite attributesAttributes which cannot be subdivided into subparts or attribute which is composed of a single component with • an independent existence is called the simple attribute. Similarly, an attribute composed of multiple components, each with an independent existence is composite. • A composite attribute may appear as hierarchy. •


58

For example, a particular customer entity may be described by name if simple attribute is considered or could be structured as a composite attribute consisting of first-name, middle-name and last-name.

Single valued and multi-valued attributeThe attributes that hold a single value for a single entity are single valued. The majority of the attribute are • single valued for a particular entity. For example• , an enrolment number attribute for the particular student may refer to only one enrolment number. There may be situations where for an entity the attribute may be the set of values for example the student may • have registered in zero, one or number of subjects in a particular semester. Hence, different student entities within the entity set may have different number of values for subjects registered. This type of attribute is said to be multi-valued attribute.

Null attributesA null value is used when an entity does not have a value for an attribute. • Example is when the student does not register in any subject; it implies the attribute is not applicable. Null can also designate that an attribute value is unknown.•

Derived attributesThe value for this type of attribute can be derived from the values of other related attributes or entities. • Example Consider that the semester test marks for the subject is computed on the basis of average test marks from test1, test2, test3. Thus the value for subject test marks for the semester will be derived from test marks in the three progressive tests carried for the subject during the semester.

5.4 Entity-Relationship DiagramAn entity-relationship (ER) diagram is a specialised graphic that illustrates the interrelationships between entities in a database. We can express the overall logical structure of a database graphically with an E-R diagram. It follows certain conventions for representing the entities and attributes in the E-R diagram.

Rectangles representing entity sets with the name of entity in the box•

If the attribute is composite , its component attributes are shown as ellipses representing attributes attached to • the relevant entity by a line and labelled with the attribute name.

Lines link attribute to entity sets and entity sets to relationship sets. If the attribute is simple or single valued, • a single line is used. If the attribute is derived, a dotted line is used. If the attribute is multi-valued, then the double lines are used.

59

Diamonds represent relationships with relationship name inside the diamond. The two sides of the diamond are • connected to the entity set.

The entity name is written in uppercase whereas the attribute name is written in lower case.• The primary keys (key attributes) are underlined.•

In the text, lines may be directed (have an arrow on the end) to signify mapping cardinalities for relationship sets. An example is shown in the figure below.

Belongs to

Student First name

Student Name

Address

City

StreetPin

State

Age

Date-of-Birth

Department Code

Department NameStudent

Enroll Number

Student Surname

Student Department

Fig. 5.7 Sample of ER diagram

5.4.1 Relationships and Relationship SetsIn real world entities are associated with each other.

For example, the customer is associated with a Bank Account, or as shown in above figure student is associated with department etc. Thus, a relationship is an association between several entities.

A relationship set is a set of relationships of the same type. Formally it is a mathematical relation on n ³ 2 • (possibly non-distinct) sets.


60

If E1 E2.... En are entity sets, then a relationship set R is a subset of{ (e1 e2.... en ) | e1 e E1 e2 e E2 . . . . ene En }Where (e1 e2.... en ) is a relationship.For example, consider the two entity sets student and department as shown in the figure above.We define the relationship to denote the association between students and their departments. The most efficient • way of representing a relationship is to use an additional entity called the relationship entity. For instance, in the book-distributor-order example the books are ordered from the distributor. To represent the • relationship, we form a relationship entity called ORDERS. The ORDERS entity has attributes for the BOOK and the DISTRIBUTOR from whom the books are ordered. In addition, the relationship entity could have attributes of its own. For example, the order quantity is an attribute of the ORDER entity. Relationships are, thus, used to aid the database in constructing how data are to be used within the database. Usually • the name of the entity is an active verb but passive verbs can also be used. Occasionally, there are relationships involving more than two entity sets. The role of an entity is the function it plays in a relationship. For example, the relationship works-for could be ordered pairs of employee entities. The first employee takes the role of manager and the second one will take the role of worker. A relationship • may also have descriptive attributes. For example, date (last date of account access) could be an attribute of the CustAcct relationship set.

5.4.2 Terms Associated With Entities and RelationshipsSome terms associated with entities and relationships are described below:DegreeA relationship can include one or more entities. The degree of a relationship is the number of entities that participate in the relationship. The degree is of three types namely:

Unary relationshipsIt defines a relationship between two instances of one entity type .For example, consider the entity SUBJECT. If to take certain subject you need to take another subject like to take statistics you need to take Maths, this type of relationship is said to be Unary and is represented as shown in figure given below.

Subject

Requires

Fig. 5.8 Unary relationship

Binary relationshipsRelationships of degree 2 are called binary relationships, for example, it is a relationship between the instances of two entity types. Most relationships in databases are binary.

RequiresSubject Subject

Fig. 5.9 Binary relationship

61

Ternary relationshipIt is a simultaneous relationship among the instances of three entity types.

Teaches Student

Teacher

Student

Fig. 5.10 Ternary relationship (a)

Quaternary relationshipIt is a simultaneous relationship among the instances of four entity types.

StudiesStudent

Teacher

Subject

Course Material

Fig. 5.10 Ternary relationship (b)

CardinalitiesMapping cardinality expresses the number of entities to which another entity can be associated via a relationship set. A cardinality is expressed with the help a crowsfoot symbol ( ) in ERD. If an entity has a crowsfoot symbol drawn against it, then many occurrences of that entity may relate to the other entity.

Conversely if no crowsfoot is drawn against it, at most one occurrence of that entity may relate to the other entity. For binary relationship sets between entity sets A and B, the mapping cardinality must be one of following points:

One-to-one• An entity in A is associated with at most one entity in B, and an entity in B is associated with at most one entity in A. As shown in the figure below a student can have only one enrolment number and one enrolment number cam be given to only on student.

HasStudent Enrolled In

Fig. 5.11 One-to-one cardinality


62

One-to-many• An entity in A is associated with any number of entities in B. An entity in B is associated with at most one entity in A. As shown in the fig. below a publisher publish many books but a book may be published by one publisher.

PublishesPublisher Book

Fig. 5.12 One-to-many cardinality

Many-to-one• An entity in A is associated with at most one entity in B. An entity in B is associated with any number in A.

Enrolled In Student Department

Fig. 5.13 Many-to-one cardinality

Many-to-many• An entity in A is associated with any number of entities in B and an entity in B is associated with any number in A.

RegistersStudent Courses

Fig. 5.14 Many-to-many cardinality

The appropriate mapping cardinality for a particular relationship set depends on the real world being modelled. Minimum cardinality is the minimum number of instances of entity B associated with each instance of entity A. This is also called “modality” which specifies whether the relationship exists or not.

Existence dependenciesExistence dependency means if the existence of entity X depends on the existence of entity Y, then X is said to be existence dependent on Y. (Or we say that Y is the dominant entity and X is the subordinate entity.)

For example, consider account and transaction entity sets, and a relationship log between them. This is one-to-many from account to transaction. If an account entity is deleted, its associated transaction entities must also be deleted. Thus account is dominant and transaction is subordinate.

A strong entity is one which is not existence dependent. A weak entity type is dependent on the existence of • another entity. For example, PARENT is a weak entity as it needs the EMPLOYEE for its existence. Weak entities can be shown using a double-lined rectangle as in figure given below.

63

EmployCompany Employee

HasParent

Fig. 5.15 Diagram showing weak entity

ParticipationAn entity can participate in the relationship partially or totally. Participation can also be of the type optional or • mandatory. If the occurrence of one entity does not require the occurrence of another corresponding entity in the relationship the participation is said to be optional or partial. Whereas, if the occurrence of one entity requires the occurrence of another corresponding entity in the relationship • the participation is said to be optional or partial. As shown in figure below, it indicates that a STUDENT must have DEPARTMENT associated with it but a • particular DEPARTMENT may not have STUDENTS associated with it.

Enrolled In Student Department

Fig. 5.16 Participation

KeysDifferences between entities must be expressed in terms of attributes. A superkey is a set of one or more attributes, • which taken collectively, allow us to identify uniquely an entity in the entity set.For example, in the entity set customer, customer-name and S.I.N. is a superkey.Note that customer-name alone is not unique, as two customers could have the same name. A superkey may • contain extraneous attributes and we are often interested in the smallest superkey. A superkey for which no subset is a superkey is called a candidate key. In the example above, S.I.N. is a candidate key, as it is minimal and uniquely identifies a customer entity.A primary key is a candidate key (there may be more than one) chosen by the DB designer to identify entities • in an entity set. An entity set that does not possess sufficient attributes to form a primary key is called a weak entity set. One that does have a primary key is called a strong entity set.

For example, The entity set transaction has attributes transaction-number, date and amount. Different transactions on different accounts could share the same number. These are not sufficient to form a primary key (uniquely identify a transaction). Thus, transaction is a weak entity set.

For a weak entity set to be meaningful, it must be part of a one-to-many relationship set. This relationship set • should have no descriptive attributes. (Why?) The idea of strong and weak entity sets is related to the existence dependencies seen earlier.

Member of a strong entity set is a dominant entity. �Member of a weak entity set is a subordinate entity. �


64

A weak entity set does not have a primary key but we need a means of distinguishing among the entities. The • discriminator of a weak entity set is a set of attributes that allows this distinction to be made. The primary key of a weak entity set is formed by taking the primary key of the strong entity set on which its existence depends (see mapping constraints) plus its discriminator.Transaction is a weak entity. It is existence-dependent on account. The primary key of account is account-number. • Transaction-number distinguishes transaction entities within the same account (and is thus the discriminator). So the primary key for transaction would be (account-number, transaction-number).

The primary key of a weak entity is found by taking the primary key of the strong entity on which it is existence-dependent, plus the discriminator of the weak entity set.

Composite entitiesTo translate the E-R model into the relational database model, it is required to transform the many-to-many • relationships from E-R models into one-to-many relationships, as the relational model requires the use of one-to-many relationships. Hence, the many-to-many relationships in the E-R model are broken up into one to-many relationships. This • is done using composite entities. The composite entity consists of primary keys of each entity to be connected. • They are represented by using a diamond shape within a rectangle. • Consider the example as shown in the figure given below, where an author can write for more than one publisher • and a publisher can publish works of many authors. This relationship cannot be transformed into relational table as we require one-to-many relationships.

Works For Author Publisher

Fig. 5.17 Many-to-many relationship

This can be solved by using composite entity called WORK which has the primary key of the author as well • as publisher as its attributes. The E-R diagram is as shown in the figure given below. This E-R diagram can now be transformed into relational • model.

Work

City CityName

NameAuthor_ID

Author_ID Work_type Work_title

Publisher_ID

Publisher_ID

Country

Country

Author Publisher

Fig. 5.18 E-R diagram showing composite relationship

65

5.4.3 Other Styles of ER DiagramThe text uses one particular style of diagram. Many variations exist. Some of the variations you will see are:

Diamonds being omitted: A link between entities indicates a relationship. In this case, we have to create an • intersection entity to possess the attributes.

Numbers instead of arrowheads indicating cardinality.• Symbols, 1, n and m used �E.g. 1 to 1, 1 to n, n to m �Easier to understand than arrowheads �

A range of numbers indicating optionality of relationship.• For example, (0, 1) indicates minimum zero (optional), maximum 1 �Can also use (0, n), (1, 1) or (1, n) �Typically used on near end of link - confusing at first, but gives more information. �For example, entity 1 (0, 1) — (1, n) entity 2: indicates that entity 1 is related to between 0 and 1 occurrences �of entity 2 (optional).Entity 2 is related to at least 1 and possibly many occurrences of entity 1 (mandatory). �Multi-valued attributes may be indicated in some manner �Means attribute can have more than one value. �

Extended E-R diagrams allowing more details/constraints in the real world to be recorded.• Composite attributes �Derived attributes �Subclasses and superclasses �Generalisation and specialisation �

5.5 Roles in ER DiagramsThe function that an entity plays in a relationship is called its role. Roles are normally explicit and not specified. They are useful when the meaning of a relationship set needs clarification.

For example, the entity sets of a relationship may not be distinct. The relationship works-for might be ordered pairs of employees (first is manager, second is worker). In the E-R diagram, this can be shown by labelling the lines connecting entities (rectangles) to relationships (diamonds).

Employee

Employee Name Employee ID

Works for

Manager

Worker

Fig. 5.19 E-R diagram with role indicators


66

5.6 GeneralisationConsider extending the entity set account by classifying accounts as being either savings-account or cheque-account. Each of these is described by the attributes of account plus additional attributes. (Savings has interest-rate and cheque has overdraft-amount.) . We can express the similarities between the entity sets by generalisation. This is the process of forming containment relationships between a higher-level entity set and one or more lower-level entity sets.

Generalisation hides differences and emphasises similarities.Distinction made through attribute inheritance.• Attributes of higher-level entity are inherited by lower-level entities.• Two methods for conversion to a table form:•

Create a table for the high-level entity along with the tables for the lower-level entities containing their �specific attributes.Create only tables for the lower-level entities. �

In E-R diagrams, generalisation is shown by a triangle, as shown in the figure given below.

Account

Savings Account

Checking Account

Account_no

Interest Rate Overdraft Amount

Balance

IS A

Fig. 5.20 Generalisation

5.7 AggregationThe E-R model cannot express relationships among relationships. Consider a DB with information about employees who works on a particular project and use a number of machines doing that work. We get the E-R diagram as shown in the figure below.

67

Works

Users

Name Id

Id

Hours Numbers

Employee

Machinery

Project

Fig. 5.21 E-R diagram with redundant relationships

Relationship sets work and use could be combined into a single set. However, they shouldn’t be, as this would obscure the logical structure of this scheme.

The solution is to use aggregation. This is an abstraction through which relationships are treated as higher-level entities. For our example, we treat the relationship set work and the entity sets employee and project as a higher-level entity set called work. Figure given below shows the E-R diagram with aggregation.

Works

Users

Name Id

Id

Hours Numbers

Employee

Machinery

Project

Fig. 5.22 E-R diagram with aggregation


68

Hence, transforming an E-R diagram with aggregation into tabular form is easy. We create a table for each entity and relationship set as before. The table for relationship set users contains a column for each attribute in the primary key of machinery and work.

69

Summary Database design is the process of producing a detailed data model of a database. This logical data model contains • all the needed logical and physical design choices and physical storage parameters needed to generate a design in a Data Definition Language, which can then be used to create a database.Within the relational model the final step can generally be broken down into two further steps that of determining • the grouping of information within the system, generally determining what are the basic objects about which information is being stored, and then determining the relationships between these groups of information or objects. This step is not necessary with an Object database.Once a database designer is aware of the data which is to be stored within the database, they must then determine • how the various pieces of that data relate to one another.Once the relationships and dependencies amongst the various pieces of information have been determined, it is • possible to arrange the data into a logical structure which can then be mapped into the storage objects supported by the database management system. The physical design of the database specifies the physical configuration of the database on the storage media. • A major part of the database design process is deciding how to represent in the design the various types of • “things” such as people, places, products and the like which collectively are referred to as an entity.Redundancy refers to the information being repeated at various places in database. Information should appear • in exactly one place in order to ensure consistency of data.A bad design may make certain aspects of the enterprise difficult or impossible to model. Such incompleteness • is unattractive and may be prevented with primary key. Entity-relationship model is a data modelling method used to model a system and its requirements in a top-• down approach. This approach is commonly used in database design. The diagrams created using this method are called ER diagrams. The E-R model forms the basis of the E-R diagrams. The ERDs comprise three main components- entities, • attributes and relationships.An entity is an object that exists and is distinguishable from other objects. Entity is the fundamental item in • any data model.An attribute is a function which maps an entity set into a domain. • Attributes which cannot be subdivided into subparts or attribute which is composed of a single component with an independent existence is called the simple attribute.An entity-relationship (ER) diagram is a specialised graphic that illustrates the interrelationships between • entities in a database.

ReferencesRitchie, C., • Database Principles and Design, Cengage Learning EMEA. Singh, S. K., • Database Systems: Concepts, Design and Applications, Pearson Education. Barrier Reef Institute of TAFE, 2001, • Introduction to Normalisation. [Online] Available at: < http://tle.tafevc.com.au/toolbox/file/f567850b-9966-154c-cd52-6025f598004f/1/306_02.zip/content/normalisation/normalisation_intro.htm> [Accessed 7 July 2011]. SQA• , 2007, Fundamentals of Database Design: The Process of Normalisation. [Online]Available at: http://www.sqa.org.uk/elearning/MDBS01CD/page_20.htm [Accessed 6 July 2010].Janakiram, D., 2008. • Concurrency Control Part – 3. [Video online] Available at: <http://www.youtube.com/watch?v=-EJa_I_4-vg> [Accessed 9 September 2011]. Dr. Srinath, S., 2008. • Structured Query Language. [Video online] Available at: <http://www.youtube.com/watch?v=64szTfLNu3o> [Accessed 9 September].


70

Recommended ReadingConolly, T., Begg, C., • 2008, Database Systems: A Practical Approach To Design, Implementation and Management, 4th ed., Pearson Education India.Coronel, C., Morris, S., & Rob, P., 2009. • Database systems: design, implementation, and management, Cengage Learning.Wang, S. & Wang, H., 2011. • Database Design and Implementation, Universal-Publishers.

71

Self AssessmentWho introduced E-R model? 1.

E. F. Codda. Boyceb. Silberschatzc. P. P. Chend.

An association among three entities is called __________.2. binary relationshipa. ternary relationshipb. recursivec. nonrecursived.

____________defines a relationship between two instances of one entity type 3. binary relationship.Ternary relationshipa. Unary relationshipb. Binary relationship c. Quaternary relationship d.

The attribute composed of a single component with an independent existence is called ___________.4. Composite attributea. Atomic attributeb. Single-valued attributec. Derived attributed.

Which of the following is the component of E-R model? 5. Attributea. Unitb. Correlationc. Objectd.

________________ expresses whether the relationship exists 6. Cardinalitya. Modalityb. Degreec. Objectd.

Which of the following expresses the number of entities to which another entity can be associated via a 7. relationship set?

Cardinalitya. Modalityb. Degreec. Attributed.


72

In E-R diagram ______________ represents entity set.8. rectanglea. ovalb. diamondc. lined.

__________ representing entity sets with the name of entity in the box.9. Rectanglesa. Circleb. Diamond c. Link d.

______________ defines a relationship between two instances of one entity type.10. Unary relationshipsa. Binary relationshipsb. Ternary relationshipsc. Quaternary relationship d.

73

Chapter VI

SQL: Queries and Subqueries

Aim


introduce Structure Query Language •

enlist the types of SQL data type•

explain clauses in SQL•

Objectives


elucidate SQL Data Query Language•

explain logical operators •

enlist different types of functions used in SQL•

Learning outcome


enlist different types of subqueries •

understand SQL data manipulation language functions•

identify data definition language •


74

6.1 Introduction to SQL SQL (Structured Query Language) is a database sublanguage for querying and modifying relational databases. It was developed by IBM Research in the mid 70’s and standardised by ANSI in 1986. SQL is an ANSI (American National Standards Institute) standard computer language for accessing and manipulating database systems. SQL statements are used to retrieve and update data in a database.

SQL works with database programs like MS Access, DB2, Informix, MS SQL Server, Oracle, Sybase, etc. In • their SQL standard, the American National Standards Institute declared that the official pronunciation is “es queue el.” However, many database professionals have taken to the slang pronunciation “sequel.” The choice is yours. SQL comes in many flavours. Oracle databases utilise their proprietary PL/SQL. Microsoft SQL Server makes • use of Transact-SQL. However, all of these variations are based upon the industry standard ANSI SQL. SQL can execute queries against a database, SQL can retrieve data from a database, SQL can insert new records in a database, SQL can delete records from a database, and SQL can update records in a database.The Relational Model defines two root languages for accessing a relational Database Relational Algebra and • Relational Calculus. Relational Algebra is a low-level, operator-oriented language. Creating a query in Relational Algebra involves combining relational operators using algebraic notation. Relational Calculus is a high-level, declarative language. Creating a query in Relational Calculus involves describing what results are desired. SQL is a version of • Relational Calculus. The basic structure in SQL is the statement. Semicolons separate multiple SQL statements. The Structured Query Language (SQL) comprises one of the fundamental building blocks of modern database architecture. SQL defines the methods used to create and manipulate relational databases on all major platforms.

6.2 SQL Data TypesFollowing is a list of general SQL data types that may not be supported by all relational databases.

Data Type Syntax Explanation (if applicable)

Integer INTEGER or INTIt represents a signed integer, decimal or binary.Whether the integer is decimal or binary is implementation defined.

Smallint SMALLINT

It represents a signed integer, decimal or binary.Whether the integer is decimal or binary is implementation defined. Also the actual precision of INT and SMALLINT is implementation defined but the precision of SMALLINT must not exceed that of INT.

Numeric NUMERIC(p,s)

Where p is a precision value; s is a scale value.Scale value is the number of digits after the decimal point. For example, numeric (6, 2) is a number that has 4 digits before the decimal and 2 digits after the decimal.The default for scale is zero and for precision is implementation defined.

Decimal Real DECIMAL (p,s) REAL Where p is a precision value; s is a scale value. Single-precision floating point number.

Double Precision Double Precision Double-precision floating point number.

75

Float FLOAT(p) Where p is a precision value.

Character CHAR(x) or CHARACTER (x)

Where x is the number of characters to store. x should be an integer greater than zero. This data type is space padded to fill the number of characters specified.

Character varying VARCHAR2(x) Where x is the number of character to store. This data type does NOT space pad.

Bit BIT (X) Where x is the number of bits to store.

Bit varying BIT VARYING(x) Where x is the number of bits to store. The length can vary up to x.

DATE DATE Stores year, month and day values.

Time TIME Store the hour, minute and second values.

Timestamp TIMESTAMP Stores year, month, day, hour, minute, and second values

Time with time zone

TIME WITH TIME ZONE

Exactly the same as time, but also stores an offset from UTC of the time specified.

Timestamp with time zone

TIMESTAMP WITH TIME ZONE

Exactly the same as timetstamp, but also store an offset from UTC of the time specified.

Boolean Yes/no (true/false)(1 for yes 0 for no) Either something is or something is not.

Table 6.1 SQL data types

6.3 Clauses in SQLThey are the commands issued during a query. SELECT, INSERT, ADD, DROP,CREATE, etc are all clauses that begin each SQL Query and execute some sort of action upon your database.

SQL Data Query Language (DQL)• It is one of the most commonly used SQL statements that enable the users to query one or more tables to get the information they want. DQL has only one data query statement whose syntax is SELECT.

SELECT• The SQL SELECT statement queries data from tables in the database. The statement begins with the SELECT keyword. The result of the SELECT statement is another table- a table derived from tables used for the SELECT operation. This is referred to as the closure property of the relational system. The closure property means since the result of SELECT statement is a table; it is possible to apply another SELECT operation on the result. SELECT operations can also be nested.

SyntaxSELECT [ DISTINCT | ALL ]column_expression1, column_expression2, ....[ FROM from_clause ][ WHERE where_expression ][ GROUP BY expression1, expression2, .... ][ HAVING having_expression ][ ORDER BY order_column_expr1, order_column_expr2, .... ]


76

The SELECT statement is used to form queries for extracting information out of the database. The SELECT clause specifies the table columns that are retrieved. The FROM clause specifies the tables accessed. The WHERE clause specifies which table rows are used. The WHERE clause is optional; if missing, all table rows are used.

For example,SELECT name FROM s WHERE city=’Rome’This query accesses rows from the table - s. It then filters those rows where the city column contains Rome. Finally, the query retrieves the name column from each filtered row. The ALL and DISTINCT specifiers are optional. DISTINCT specifies that duplicate rows are discarded. A duplicate row is when each corresponding select-list column has the same value. The default is ALL, which retains duplicate rows.

For example,SELECT descr, colour FROM pThe column names in the select list can be qualified by the appropriate table name:SELECT p.descr, p.colour FROM pA column in the select list can be renamed by following the column name with the new name.

For example:SELECT name supplier, city location FROM s

This produces:

Supplier Location

Pierre Paris

John London

Mario Rome

Table 6.2 List of suppliers

The select list may also contain expressions. A special select list consisting of a single ‘*’ requests all columns in all tables in the FROM clause.

For example,SELECT * FROM spReturns all rows and all columns in all tables. The * delimiter will retrieve just the columns of a single table when qualified by the table name.

For example:SELECT sp.* FROM spThis produces the same result as the previous example. An unqualified * cannot be combined with other elements in the select list; it must be stand alone. However, a qualified * can be combined with other elements.

For example,SELECT sp.*, cityFROM sp, sWHERE sp.sno=s.sno

77

FROM Clause• The FROM clause always follows the SELECT clause. It lists the tables accessed by the query.

For example,SELECT * FROM sWhen the From List contains multiple tables, commas separate the table names. For example,SELECT sp.*, cityFROM sp, sWhen the From List has multiple tables, they must be joined together. Correlation Names: Like columns in the select list, tables in the FROM LIST can be renamed by following the table name with the new name.

For example,SELECT supplier.name FROM s supplierThe new name is known as the correlation (or range) name for the table. Self joins require correlation names.

WHERE clause• The WHERE clause is optional. When specified, it always follows the FROM clause. The WHERE clause filters rows from the FROM clause tables. Omitting the WHERE clause specifies that all rows are used. Following the WHERE keyword is a logical expression, also known as a predicate.

The predicate evaluates to a SQL logical value true, false or unknown. The most basic predicate is a comparison:

Colour = ‘Red’This predicate returns:True - if the colour column contains the string value — ‘Red’,False- if the colour column contains another string value (not ‘Red’), orUnknown- if the colour column contains null.Generally, a comparison expression compares the contents of a table column to a literal, as above. A comparison expression may also compare two columns to each other. Table joins use this type of comparison

For example,SELECT * FROM sp WHERE qty >= 200The following example query will return the number, quantity and price of all orders for more than 5 items sorted in descending order by order number. In addition it rounds the order price to two decimal places and applies a dollar ($) sign to the output.

For example,SELECT number, quantity, CONCAT (‘$’, ROUND (price, 2))FROM OrderWHERE quantity > 5ORDER BY number DESCThe ORDER BY and GROUP BY clause may refer to a column, a column alias, or an expression. The HAVING clause is evaluated after the grouping and aggregate columns have been resolved. Both operands of a comparison should be the same data type; however automatic conversions are performed between numeric, date time and interval types. The CAST expression provides explicit type conversions as explained later.

ORDER BY clause• The ORDER BY clause is optional. If used, it must be the last clause in the SELECT statement. The ORDER BY clause requests sorting for the results of a query. When the ORDER BY clause is missing, the result rows from a query have no defined order (they are unordered). The ORDER BY clause defines the ordering of rows based on columns from the SELECT clause.


78

The ORDER BY clause has the following general format: �ORDER BY column-1 [ASC|DESC] [column-2 [ASC|DESC]]... Column-1, column-2 ... is column names specified (or implied) in the select list. If a select column is renamed (given a new name in the select entry), the new name is used in the ORDER BY list. ASC and DESC request ascending or descending sort for a column. ASC is the default. ORDER BY sorts �rows using the ordering columns in left-to-right, major-to-minor order. The rows are sorted first on the first column name in the list. If there are any duplicate values for the first �column, the duplicates are sorted on the second column (within the first column sort) in the Order by list, and so on. There is no defined inner ordering for rows that have duplicate values for all Order By columns. Database nulls require special processing in ORDER BY. A null column sorts higher than all regular values; �this is reversed for DESC. In sorting, nulls are considered duplicates of each other for ORDER BY. Sorting on hidden information makes no sense in utilising the results of a query. This is also why SQL only allows select list columns in ORDER BY. For convenience when using expressions in the select list, select items can be specified by number (starting �with 1). Names and numbers can be intermixed.

Example queries:SELECT * FROM sp ORDER BY 3 DESC

Sr.no P. No Qty.

S1 P1 NULL

S3 P1 1000

S3 P2 200

S2 P1 200

Table 6.3 Example of queries (1)

SELECT name, city FROM s ORDER BY name

Name City

John London

Mario Rome

Pierre Paris


SELECT * FROM sp ORDER BY qty DESC, sno

Sr.no P. No Qty.

S1 P1 NULL

S3 P1 1000

S2 P1 200

S3 P2 200


79

Extended comparisons• In addition to the basic comparisons described above, SQL supports extended comparison operators — BETWEEN, IN, LIKE and IS NULL.

BETWEEN operator• The BETWEEN operator implements a range comparison, that is, it tests whether a value is between two other values. BETWEEN comparisons have the following format:

value-1 [NOT] BETWEEN value-2 AND value-3

This comparison tests if value-1 is greater than or equal to value-2 and less than or equal to value-3. It is equivalent to the following predicate:

Value-1 >= value-2 AND value-1 <= value-3Or, if NOT is included:NOT (value-1 >= value-2 AND value-1 <= value-3)For example,SELECT *FROM spWHERE qty BETWEEN 50 and 500

Sr.no P.no Qty.

S2 P1 200

S3 P2 200

Table 6.6 BETWEEN Operators

IN operator• The IN operator implements comparison to a list of values, that is, it tests whether a value matches any value in a list of values. IN comparisons have the following general format:

Value-1 [NOT] IN (value-2 [, value-3] ...)

This comparison tests if value-1 matches value-2 or matches value-3, and so on.It is equivalent to the following logical predicate:

value-1 = value-2 [ OR value-1 = value-3 ] ...

or if NOT is included:

NOT (value-1 = value-2 [ OR value-1 = value-3 ] ...)

For example,SELECT name FROM s WHERE city IN (‘Rome’,’Paris’)

Name

Pierre

Mario


80

LIKE operator• The LIKE operator implements a pattern match comparison, that is, it matches a string value against a pattern string containing wild-card characters. The wild-card characters for LIKE are percent — ‘%’ and underscore — ‘_’. Underscore matches any single character. Percent matches zero or more characters.

Examples,

Match Value Pattern Result

‘abc’ ‘_b_’ True

‘ab’ ‘_b_’ False

‘abc’ ‘%b%’ True

‘ab’ ‘%b%’ True

‘abc’ ‘a_’ False

‘ab’ ‘a_’ True

‘abc’ ‘a%_’ True

‘ab’ ‘a%_’ True

Table 6.7 An example of LIKE operator

LIKE comparison has the following general format:value-1 [NOT] LIKE value-2 [ESCAPE value-3]All values must be string (character). This comparison uses value-2 as a pattern to match value-1. The optional ESCAPE sub-clause specifies an escape character for the pattern, allowing the pattern to use ‘%’ and ‘_’ (and the escape character) for matching. The ESCAPE value must be a single character string. In the pattern, the ESCAPE character precedes any character to be escaped.

For example, to match a string name ending with ‘%’, use:

name LIKE ‘%/%’ ESCAPE ‘/’A more contrived example that escapes the escape character:y LIKE ‘/%//%’ ESCAPE ‘/’... matches any string beginning with ‘%/’.The optional NOT reverses the result so that:z NOT LIKE ‘abc%’is equivalent to:NOT z LIKE ‘abc%’IS NULL Operator

A database null in a table column has a special meaning the value of the column is not currently known (missing), however its value may be known at a later time. A database null may represent any value in the future, but the value is not available at this time. Since two null columns may eventually be assigned different values, one null can’t be compared to another in the conventional way. The following syntax is illegal in SQL:

WHERE qty = NULL

A special comparison operator — IS NULL, tests a column for null. It has the following general format:

value-1 IS [NOT] NULL

81

This comparison returns true if value-1 contains a null and false otherwise.The optional NOT reverses the result:

value-1 IS NOT NULL

is equivalent to:

NOT value-1 IS NULL

For example,SELECT * FROM sp WHERE qty IS NULL

Sr.no P.no Qty.

S1 P1 NULL

Table 6.8 Example of LIKE operator

Logical operators• The logical operators are AND, OR, NOT. They take logical expressions as operands and produce a logical result (True, False, and Unknown). In logical expressions, parentheses are used for grouping.

AND operator• It has the following general format: predicate-1 AND predicate-2

AND returns• True — if both operands evaluate to trueFalse — if either operand evaluates to falseUnknown — otherwise (one operand is true and the other is unknown orboth are unknown)For example,SELECT *FROM spWHERE sno=’S3’ AND qty < 500

Sr.no P.no Qty.

S3 P2 200

Table 6.9 Example of Logical operator

OR operator• The OR operator combines two logical operands. The operands are comparisons or logical expressions. It has the following general format:Predicate-1 OR predicate-2

OR returns• True — if either operand evaluates to true


82

False — if both operands evaluate to falseUnknown — otherwise (one operand is false and the other is unknown orboth are unknown)For example,SELECT *FROM sWHERE sno=’S3’ OR city = ‘London’

Sr. no Name City

S2 John London

S3 Mario Rome

Table 6.10 Example of OR operator

AND has a higher precedence than OR, so the following expression: a OR b AND c is equivalent to: a OR (b AND c)

NOT operator• The NOT operator inverts the result of a comparison expression or a logical expression. It has the following general format:

NOT predicate-1

Example query:

SELECT *FROM spWHERE NOT sno = ‘S3’

Sr.no P.no Qty.

S1 P1 NULL

S2 P1 200

Table 6.11 Example of NOT operator

SQL functions• SQL has a lot of built-in functions for counting and calculations.Function Syntax (Set Functions)The syntax for built-in SQL functions is:

SELECT set-function ( [DISTINCT|ALL] column-1 ) FROM table

6.4 Types of FunctionsThere are several basic types and categories of functions in SQL. The basic types of functions are aggregate functions and scalar functions.

Aggregate functions• Aggregate functions operate against a collection of values, but return a single value.

83

Note: If used among many other expressions in the item list of a SELECT statement, the SELECT must have a GROUP BY clause.

Function Description

AVG (column) Returns the average value of a column

COUNTS (Column) Returns the number of row (without a NULL value) of a column.

COUNT(*) Returns the number of selected rows

MAX(column) Returns the highest value of a column

MIN(column) Returns the lowest value of a column

SUM(column) Returns the total sum of a column

Table 6.12 Aggregate function

The DISTINCT and ALL specifiers in syntax are optional. ALL specifies that all non-null values are summarised; it is the default. DISTINCT specifies that distinct column values are summarised; duplicate values are skipped. DISTINCT has no effect on MIN and MAX results. The AVG function returns the average value of a column in a selection. NULL values are not included in the calculation.

SELECT AVG (column) FROM table ExampleThis example returns the average age of the persons in the “Persons” table:SELECT AVG (Age) FROM Persons

ExampleThis example returns the average age for persons that are older than 20 years:

SELECT AVG (Age) FROM Persons WHERE Age>20The COUNT (column) function returns the number of rows without a NULL value in the specified column.

SELECT COUNT (column) FROM table

ExampleWith this “Persons” Table:This example finds the number of persons with a value in the “Age” field in the “Persons” table:

SELECT COUNT (Age) FROM Persons

The COUNT (column) function is handy for finding columns without a value. Note that the result is one less than the number of rows in the original table because one of the persons does not have an age value stored.The COUNT (*) function returns the number of selected rows in a selection.

SELECT COUNT (*) FROM table

This example returns the number of rows in the table:

SELECT COUNT (*) FROM Persons


84

Example:Return the number of persons that are older than 20 years:SELECT COUNT (*) FROM Persons WHERE Age>20The SUM function returns the total sum of a column in a given selection.NULL values are not included in the calculation.SELECT SUM (column) FROM table

ExampleThis example returns the sum of all ages in the “person” table:SELECT SUM (Age) FROM Persons

ExampleThis example returns the sum of ages for persons that are more than 20 years old:SELECT SUM (Age) FROM Persons WHERE Age>20The MAX function returns the highest value in a column. NULL values are not included in the calculation.

ExampleSELECT MAX (Age) FROM Persons

Result:Note: The MIN and MAX functions can also be used on text columns, to find the highest or lowest value in alphabetical order. The MIN function returns the lowest value in a column. NULL values are not included in the calculation. SELECT MIN (column) FROM tableSELECT MIN (Age) FROM PersonsThe MIN and MAX functions can also be used on text columns, to find the highest or lowest value in alphabetical order.

Scalar functions• Scalar functions operate against a single value and return a single value based on the input value.SQL has the following built-in functions:

SUBSTRING (exp-1 FROM exp-2 [FOR exp-3])

Extracts a substring from a string - exp-1, beginning at the integer value exp-2, for the length of the integer value - exp-3. exp-2 is 1 relative. If FOR exp-3 is omitted, the length of the remaining string is used. Returns the substring.

UPPER(exp-1)

Converts any lowercase characters in a string - exp-1 to uppercase. Returns the converted string.LOWER(exp-1)

Converts any uppercase characters in a string - exp-1 to lowercase. Returns the converted string.

TRIM([LEADING|TRAILING|BOTH] [FROM] exp-1)TRIM([LEADING|TRAILING|BOTH] exp-2 FROM exp-1)

Trims leading, trailing or both characters from a string - exp-1. The trim character is a space, or if exp-2 is specified, it supplies the trim character. If LEADING, TRAILING, BOTH are missing, the default is BOTH. Returns the trimmed string.

85

POSITION(exp-1 IN exp-2)Searches a string - exp-2, for a match on a substring - exp-2. Returns an integer, the 1 relative position of the match or 0 for no match.

CHAR_LENGTH(exp-1)CHARACTER_LENGTH(exp-1)Returns the integer number of characters in the string - exp-1.

OCTET_LENGTH(exp-1)Returns the integer number of octets (8-bit bytes) needed to represent the

string - exp-1.EXTRACT(sub-field FROM exp-1)

Returns the numeric sub-field extracted from a date-time value - exp-1. subfield is YEAR, QUARTER, MONTH, DAY, HOUR, MINUTE, SECOND,TIMEZONE_HOUR or TIMEZONE_MINUTE. TIMEZONE_HOUR andTIMEZONE_MINUTE extract sub-fields from the Time-zone portion of exp-1 QUARTER is (MONTH-1)/4+1.

6.5 Joining TablesThe FROM clause allows more than 1 table in its list, however, simply listing more than one table will very rarely produce the expected results. The rows from one table must be correlated with the rows of the others. This correlation is known as joining.

The following query:

SELECT * FROM sp, p

Produces:

S. no P.No Qty. P.No. Descr. Colour

S1 P1 NULL P1 Widget Blue

S1 P1 NULL P2 Widget Red

S1 P1 NULL P3 Dongle Green

S2 P1 200 P1 Widget Blue

S2 P1 200 P2 Widget Red

S2 P1 200 P3 Dongle Green







Table 6.13 Joining table


86

Each row in sp is arbitrarily combined with each row in p, giving 12 result rows (4 rows in sp X 3 rows in p.) This is known as a Cartesian product.

A more usable query would correlate the rows from sp with rows from p, for instance, matching on the common column — pno:

SELECT *FROM sp, pWHERE sp.pno = p.pno

This produces:

S.no P.No Qty. P.No Descr. Colour

S1 P1 NULL P1 Widget Blue




Table 6.14 Rows of joining table are combines

Rows for each part in p are combined with rows in sp for the same part by matching on part number (pno). In this query, the ‘WHERE clause’ provides the join predicate by matching pno from p with pno from sp.

The join in this example is known as an inner equi-join. equi meaning that the join predicate uses = (equals) to match the join columns. Other types of joins use different comparison operators. For example, a query might use a greater-than join.

The term inner means only rows that match are included. Rows in the first table that have no matching rows in the second table are excluded and vice versa (in the above join, the row in p with pno P3 is not included in the result.)

An outer join includes unmatched rows in the result. More than 2 tables can participate in a join. This is basically just an extension of a 2 table join. 3 tables — a, b, c, might be joined in various ways:

a joins b which joins ca joins b and the join of a and b joins ca joins b and a joins c

With inner joins, this structure is not explicit. It is implicit in the nature of the join predicates. With outer joins, it is explicit; This query performs a 3 table join:SELECT name, qty, descr, colorFROM s, sp, pWHERE s.sno = sp.snoAND sp.pno = p.pno

87

It joins s to sp and sp to p, producing:

Name Qty Descr. Colour

Pierre NULL Widget Blue

John 200 Widget Blue

Mario 1000 Widget Blue

Mario 200 Widget Red

Note that the order of tables listed in the FROM clause should have no significance, nor does the order of join predicates in the WHERE clause.

Outer joinsAn inner join excludes rows from either table that don’t have a matching row in the other table. An outer join provides the ability to include unmatched rows in the query results. The outer join combines the unmatched row in one of the tables with an artificial row for the other table. This artificial row has all columns set to null.The outer join is specified in the FROM clause and has the following generalformat:Table-1 { LEFT | RIGHT | FULL } OUTER JOIN table-2 ON predicate-1Predicate-1 is a join predicate for the outer join. It can only reference columns from the joined tables. The LEFT, RIGHT or FULL specifiers give the type of join:

LEFT: Only unmatched rows from the left side table (table-1) are retained.RIGHT: Only unmatched rows from the right side table (table-2) are retained.FULL: Unmatched rows from both tables (table-1 and table-2) are retained.

For example:SELECT pno, descr, color, sno, qtyFROM p LEFT OUTER JOIN sp ON p.pno = sp.pno

P. No. Descr. Colour S. No Qty.

P1 Widget Blue S1 NULL

P1 Widget Blue S2 200

P1 Widget Blue S3 1000

P2 Widget Red S3 200

P3 Dongle Green NULL NULL

Table 6.15 Outer joins

Self joinsA query can join a table to itself. Self joins have a number of real world uses.For example, a self join can determine which parts have more than one supplier.

SELECT DISTINCT a.pnoFROM sp a, sp bWHERE a.pno = b.pnoAND a.sno <> b.sno


88

P.No

P1

As illustrated in the above example, self joins use correlation names to distinguish columns in the select list and where predicate. In this case, the references to the same table are renamed - a and b. Self joins are often used in Subqueries.

6.6 SubqueriesSubqueries are identifying features of SQL. It is called Structured Query Language because a query can nest inside another query. There are 3 basic types of subqueries in SQL:

Predicate subqueries• : Extended logical constructs in the WHERE (and HAVING) clause.Scalar subqueries• : Standalone queries that return a single value; they can be used anywhere a scalar value is used.Table subqueries• : Queries nested in the FROM clause. All Subqueries must be enclosed in parentheses.

6.6.1 Predicate SubqueriesPredicate subqueries are used in the WHERE (and HAVING) clause. Each is a special logical construct. Except for EXISTS, predicate subqueries must retrieve one column (in their select list.)

IN subqueryThe IN subquery tests whether a scalar value matches the single query column value in any subquery result row or not. It has the following general format:

Value-1 [NOT] IN (query-1)Using NOT is equivalent to:NOT value-1 IN (query-1)

For example, to list parts that has suppliers:SELECT * FROM p WHERE pno IN (SELECT pno FROM sp)

P.No. Descr. Color

P1 Widget Blue

P2 Widget Red

Table 6.16 In sub-query

The Self join example in the previous subsection can be expressed with an IN subquery as follows:

SELECT DISTINCT pnoFROM sp aWHERE pno IN (SELECT pno FROM sp b WHERE a.sno <> b.sno)

P.No

P1

Note: The subquery WHERE clause references a column in the outer query (a.sno). This is known as an outer reference. Subqueries with outer references are sometimes known as correlated subqueries.

89

A quantified subquery allows several types of tests and can use the full set of comparison operators. It has the following general format:

Value-1 { = | > | < | >= | <= | <>} {ANY|ALL|SOME} (query-1)

The comparison operator specifies how to compare value-1 to the single query column value from each subquery result row. The ANY, ALL, SOME specifiers give the type of match expected. ANY and SOME must match at least one row in the subquery. ALL must match all rows in the subquery, or the subquery must be empty (produce no rows).

For example, to list all parts that has suppliers.

SELECT *FROM pWHERE pno =ANY (SELECT pno FROM sp)

P.No. Descr. Color

P1 Widget Blue

P2 Widget Red

A self join is used to list the supplier with the highest quantity of each part (ignoring null quantities).

SELECT *FROM sp aWHERE qty >ALL (SELECT qty FROM sp bWHERE a.pno = b.pnoAND a.sno <> b.snoAND qty IS NOT NULL)

S.No. P.No Qty.

S3 P1 1000

S2 P2 200

6.6.2 Quantified SubqueriesA quantified subquery can use the all comparison operators for several types of tests. The general syntax is:Value_1 {=|>|<|>=|<=|<>} {ANY | ALL | SOME} (query_1)

The comparison operator is used to compare value_1 to the single query column value from each subquery result row. If we are using ALL clause then must match the all rows in subquery or subquery must be empty. If we are using ANY or SOME clause then must match at least one row in the subquery.


90

For Example:mysql> SELECT * FROM Client WHERE C_ID= ANY(SELECT C_ID FROM Products);

C_ID Name City

1 A K Ltd Delhi

2 V K Associate Mumbai

3 R K India Banglore

4 A T Ltd Delhi

4 rows in set (0.00 sec)

6.6.3 Scalar SubqueriesThe Scalar subquery can be used anywhere a value can be used. The subquery must refer just to one column in the select list. It must also retrieve no more than one row. When the subquery returns a single row, the value of the single select list column becomes the value of the scalar subquery. When the subquery returns no rows, a database null is used as the result of the subquery.

Should the subquery retrieve more than one row, it is a run-time error and aborts query execution. A scalar subquery can appear as a scalar value in the select list and where predicate of another query. The following query on the sp table uses a scalar subquery in the select list to retrieve the supplier city associated with the supplier number (sno column in sp):

SELECT pno, qty, (SELECT city FROM s WHERE s.sno = sp.sno) FROM sp.

P.No Qty. City

P1 NULL Paris

P1 200 London

P1 1000 Rome

P2 200 Rome

Table 6.17 Scalar subquery

The next query on the sp table uses a scalar subquery in the WHERE clause to match parts on the colour associated with the part number (pno column in sp).

SELECT *FROM sp

WHERE ‘Blue’ = (SELECT colour FROM p WHERE p.pno = sp.pno)

S.No. P.No. Qty.

S1 P1 NULL

S2 P1 200

S3 P1 1000

91

Note that both example queries use outer references. This is normal in scalar subqueries. Often, scalar subqueries are known as aggregate queries.

6.6.4 Correlated SubqueriesIt is one that is executed after the outer query is executed. So, correlated subquery takes an approach opposite to that of normal subqueries. The correlated subquery is executed as follows:

The outer query receives a row.• For each candidate row of outer query the subquery is executed once.• The results of the correlated subquery are used to determine whether the candidate row should be part of the • result set.The process is repeated for all rows.•

Correlated subqueries differ from normal subquery in that the nested SELECT statement refers back to the table in the first SELECT statement.

For example, to find out the names of all the students who appeared in more than six papers of their opted course, the SQL will beSELECT NAMEFROM STUDENT_DB pWHERE 6 < (SELECT COUNT (*)FROM RESULT_DB spWHERE sp.stuno = p.stuno)

Correlated subqueries can improve the SQL performance when:Only few rows are retrieved through the outer query and especially when outer queries WHERE clause, which • limits the number of rows retrieved can use an index.The correlated inner queries are performed through an index scan. This is very important if the table or tables • against which the inner query is performed is large and the index scan has to retrieve only the small percentage of its rows.

6.6.5 Table SubqueriesTable subqueries are queries used in the FROM clause, replacing a table name. Basically, the result set of the table subquery acts like a base table in the FROM LIST. Table subqueries can have a correlation name in the FROM LIST. They can also be in outer joins. The following two queries produce the same result:SELECT p.*, qtyFROM p, spWHERE p.pno = sp.pnoAND sno = ‘S3’

P.No. Descr. Color Qty.

P1 Widget Blue 1000

P2 Widget Red 200

Table 6.18 Table of subqueries

SELECT p.*, qtyFROM p, (SELECT pno, qty FROM sp WHERE sno = ‘S3’)WHERE p.pno = sp.pno


92

P.No. Descr. Color Qty.

P1 Widget Blue 1000

P2 Widget Red 200

6.7 Grouping QueriesA grouping query is a special type of query that groups and summarises rows. It uses the GROUP BY Clause. A grouping query groups rows based on common values in a set of grouping columns. Rows with the same values for the grouping columns are placed in distinct groups. Each group is treated as a single row in the query result.

Even though a group is treated as a single row, the underlying rows can be subject to summary operations known as Set Functions whose results can be included in the query. The optional HAVING Clause supports filtering for group rows in the same manner as the WHERE clause filters FROM rows.

For example, grouping the sp table on the pno column produces 2 groups.

S.No P.No Qty.

S1 P1 NULL ‘P1’ Group

S2 P1 200

S3 P1 1000

S3 P2 200 ‘P2’ Group

The P1 group contains 3 sp rows with pno=’P1’The P2 group contains a single sp row with pno=’P2’Nulls get special treatment by GROUP BY. GROUP BY considers a null as distinct from every other null. Each row that has a null in one of its grouping columns forms a separate group. Grouping the sp table on the qty column produces 3 groups. The row where qty is null forms a separate group.

S.No P.No Qty.

S1 P1 NULL NULL Group

S2 P1 200 200 Group

S3 P2 200

S3 P1 1000 ‘P2’ Group

GROUP BY clauseGROUP BY is an optional clause in a query. It follows the WHERE clause or the FROM clause if the WHERE • clause is missing. A query containing a GROUP BY clause is a grouping query. The GROUP BY clause has the following general format:

GROUP BY column-1 [, column-2] ... column-1 and column-2 are the grouping columns. They must be �names of columns from tables in the FROM clause; they can’t be expressions. GROUP BY operates on the rows from the FROM clause as filtered by the WHERE clause. It collects the �rows into groups based on common values in the grouping columns.

Except nulls, rows with the same set of values for the grouping columns are placed in the same group. If any • grouping column for a row contains a null, the row is given its own group.

93

For example,SELECT pnoFROM spGROUP BY pno

P.No.

P1

P2

In grouping queries, the select list can only contain grouping columns, plus literals, outer references and • expression involving these elements. Nongrouping columns from the underlying FROM tables cannot be referenced directly. However, non-grouping • columns can be used in the select list as arguments to Set Functions. Set Functions summarise columns from the underlying rows of a group.

HAVING clauseThe HAVING clause is associated with grouping queries and aggregate queries. It is optional in both cases. In grouping queries, it follows the GROUP BY clause. In aggregate queries, HAVING follows the WHERE clause or the FROM clause if the WHERE clause is missing. If the HAVING clause predicate evaluates to true for a grouped or aggregate row, the row is included in the query result, otherwise, the row is skipped (not included in the query result).

For example,SELECT sno, COUNT(*) partsFROM spGROUP BY snoHAVING COUNT(*) > 1

S.No Parts

S3 2

Aggregate queriesAn aggregate query can use Set Functions and a HAVING clause. It is similar to a grouping query except there • are no grouping columns. The underlying rows from the FROM and WHERE clauses are grouped into a single aggregate row. An aggregate query always returns a single row, except when the HAVING clause is used. An aggregate query • is a query containing Set Functions in the select list but no GROUP BY clause. The Set Functions operate on the columns of the underlying rows of the single aggregate row. Except for outer • references, any columns used in the select list must be arguments to Set Functions. An aggregate query may also have a HAVING clause. The HAVING clause filters the single aggregate row. • If the HAVING clause predicate evaluates to true, the query result contains the aggregate row. Otherwise, the query result contains no rows.


94

For example:SELECT COUNT (DISTINCT pno) number_parts, SUM (qty) total_partsFROM sp

Number_parts Total_Parts

2 1400

Subqueries are often aggregate queries. For example, parts with suppliers.SELECT *FROM pWHERE (SELECT COUNT(*) FROM sp WHERE sp.pno=p.pno) > 0

P.No. Descr. Color

P1 Widget Blue

P2 Widget Red

6.8 Union QueriesThe SQL UNION operator combines the results of two queries into a composite result. The component queries can be SELECT/FROM queries with optional WHERE/GROUP BY/HAVING clauses. The UNION operator has the following general format:

query-1 UNION [ALL] query-2• query-1 and query-2 are full query specifications. •

The UNION operator creates a new query result that includes rows from each component query. By default, UNION eliminates duplicate rows in its composite results. The optional ALL specifies requests that duplicates be retained in the UNION result. The component queries of a union query can also be union queries themselves. Parentheses are used for grouping queries. The select lists from the component queries must be union-compatible. They must match in degree (number of columns).

For example,SELECT * FROM spUNIONSELECT CAST(‘ ‘ AS VARCHAR(5)), pno, CAST(0 AS INT)FROM pWHERE pno NOT IN (SELECT pno FROM sp)

S.No P.No. Qty.

S1 P1 NULL

S2 P1 200

S3 P1 1000

S3 P2 200

95

6.9 SQL Data Manipulation Language (DML)The SQL DML provides commands for updating, inserting, deleting, modifying and querying the data or tuples in the database. These commands may be issued interactively so that a result is returned immediately following the execution of the statement. The syntax of SQL DML commands is INSERT, DELETE and UPDATE.

INSERT syntaxINSERT INTO table_name [ ( col_name1, col_name2, .... ) ]VALUES (expression1_1, expression1_2, ....), (expression2_1, expression2_2, ....), .... INSERT INTO table_name [(col_name1, col_name2,)] SELECT ... INSERT INTO table_name SET col_name1 = expression1, col_name2 = expression2, .... This is the SQL command to insert records into a table in the database. This statement comes in three forms. The first inserts data from a VALUES clause; VALUES (10, 4 + 3, CONCAT (‘1’, ‘1’, ‘c’) ),( 11, (28 / 2) - 7, CONCAT(col1, ‘c’)) The second form is used to copy information from a SELECT query into the table specified in the INSERT statement. For example; INSERT INTO table (col1, col2, col3)SELECT id, num, descriptionFROM table2WHERE description LIKE ’11%’

UPDATE syntaxUPDATE table_nameSET col_name1 = expression1, col_name2 = expression2, ....[WHERE expression][LIMIT limit_amount ]

It updates information in a table. The SET clause is a list of assignments that describe how the columns of the data matched by the WHERE clause are to be updated. Any columns not assigned in the SET clause are left unchanged.

For example, UPDATE EmployeeSET salary = salary * 1.25WHERE name = ‘Bob’UPDATE OrderSET id = id + 3, part = CONCAT(part, ‘-00’)WHERE part LIKE ‘PO-%’

6.10 Data Definition Language (DDL)The DDL provides commands for defining relation schemas, deleting relation schemas and modifying relation schemas. These commands are used to create, alter and drop tables. The syntax of the commands are CREATE, ALTER and DROP. The main logical SQL data definition statements are:

CREATE TABLE syntax

CREATE TABLE [IF NOT EXISTS] table_name (column_declare1, column_declare2, constraint_declare1, ...) column_declare::= column_name type [ DEFAULT expression ][NULL | NOT NULL] [INDEX_BLIST | INDEX_NONE] type::= BIT | REAL | CHAR | TEXT | DATE | TIME |FLOAT | BIGINT | DOUBLE | STRING | BINARY | NUMERIC |DECIMAL | BOOLEAN | TINYINT | INTEGER | VARCHAR |SMALLINT | VARBINARY | TIMESTAMP | LONGVARCHAR |JAVA_OBJECT | LONGVARBINARYconstraint_declare :: = [ CONSTRAINT constraint_name ]


96

PRIMARY KEY (col1, col2, ... ) |FOREIGN KEY (col1, col2, ...) REFERENCES f_table [ ( col1, col2, ... ) ][ON UPDATE triggered_action ] [ON DELETE triggered_action ] |UNIQUE (col1, col2, ...) |CHECK (expression)[INITIALLY DEFERRED | INITIALLY IMMEDIATE][NOT DEFERRABLE | DEFERRABLE]triggered_action :: = NO ACTION | SET NULL | SET DEFAULT | CASCADE

When declaring string or binary column types the maximum size must be specified. The following example declares a string column that can grow to a maximum of 100 characters, CREATE TABLE Table ( str_col VARCHAR(100) ).

When handling strings, the database will only allocate as much storage space as the string uses up. If a 10 character string is stored in str_col, then only space for 10 characters will be allocated in the database. So, if you need a column that can store a string of any size, use an arbitrarily large number when declaring the column. Unique, primary/foreign key and check integrity constraints can be defined in the CREATE TABLE statement. The following is an example of defining a table with integrity constraints.

CREATE TABLE Customer ( number VARCHAR(40) NOT NULL, name VARCHAR(100) NOT NULL, ssn VARCHAR(50) NOT NULL, age INTEGER NOT NULL, CONSTRAINT cust_pk PRIMARY KEY (number), UNIQUE ( ssn ), // (An anonymous constraint) CONSTRAINT age_check CHECK (age >= 0 AND age < 200))

6.11 ViewsThere are two kinds of tables, base tables and views. Base table is a physical table that is not defined in terms of other tables. It contains data of its own. Views are not autonomous and do not exists by their own right. A view is a named table that is represented, not by its own physically separate stored data, but by its definition in terms of other named tables (base tables or views). When users see a view they see the same data that is in the database tables but perhaps with a different perspective. Views don’t contain any data. Instead view is a virtual table, deriving its data from base tables.

CREATE VIEW syntaxCREATE VIEW table_name [(column_name1, column_name2 ...)]AS SELECT ... Creates a new view. A view is a virtual table based on the result of a SELECT query. The content of a view may reference any number of other tables and views.

For example,CREATE VIEW view_name AS SELECT column_name(s) FROM table_name WHERE condition

A view acts like a regular table and can be queried as you would a table made with the CREATE TABLE statement. Views are read-only. Use views to control how users see your data. Views allow you to provide focus, simplification, and customisation of tables in your database. They also offer a security mechanism (they restrict users from seeing tables but provide access to views based on the tables). In addition, views keep the data independent of the database structure.

For example, CREATE VIEW [Current Product List] AS SELECT ProductID,ProductName FROM Products WHERE Discontinued=No

97

6.11.1 Updating a ViewYou can update a view by using the following syntax:

CREATE OR REPLACE VIEW view_name AS SELECT column_name(s) FROM table_name WHERE condition

For example, CREATE VIEW [Current Product List] AS SELECT ProductID,ProductName,Category FROM Products WHERE Discontinued=No

6.11.2 SQL Dropping a ViewYou can delete a view with the DROP VIEW command:DROP VIEW view_name

For example, DROP VIEW Current Product List


98

Summary SQL (Structured Query Language) is a database sublanguage for querying and modifying relational • databases.SQL works with database programs like MS Access, DB2, Informix, MS SQL Server, Oracle, Sybase, etc.• SQL comes in many flavours. Oracle databases utilise their proprietary PL/SQL. Microsoft SQL Server makes • use of Transact-SQL.The Relational Model defines two root languages for accessing a relational Database Relational Algebra and • Relational Calculus. Relational Algebra is a low-level, operator-oriented language.Creating a query in Relational Calculus involves describing what results are desired. SQL is a version of Relational • Calculus. The basic structure in SQL is the statement. Semicolons separate multiple SQL statements.Clauses in SQL are the commands issued during a query. SELECT, INSERT, ADD, DROP, CREATE, etc are • all clauses that begin each SQL Query and execute some sort of action upon your database.The SQL SELECT statement queries data from tables in the database. The statement be The WHERE clause is • optional. When specified, it always follows the FROM clause. The WHERE clause filters rows from the FROM clause tables. gins with the SELECT keyword.The ORDER BY clause is optional. If used, it must be the last clause in the SELECT statement. The ORDER • BY clause requests sorting for the results of a query.Database nulls require special processing in ORDER BY. A null column sorts higher than all regular values; this • is reversed for DESC. In sorting, nulls are considered duplicates of each other for ORDER BY.The LIKE operator implements a pattern match comparison, that is, it matches a string value against a pattern • string containing wild-card characters. The wild-card characters for LIKE are percent — ‘%’ and underscore — ‘_’. Underscore matches any single character. Percent matches zero or more characters.Scalar functions operate against a single value and return a single value based on the input value.• The FROM clause allows more than 1 table in its list, however, simply listing more than one table will very • rarely produce the expected results. The rows from one table must be correlated with the rows of the others. This correlation is known as joining.An inner join excludes rows from either table that don’t have a matching row in the other table. An outer join • provides the ability to include unmatched rows in the query results. The outer join combines the unmatched row in one of the tables with an artificial row for the other table. This artificial row has all columns set to null.The Scalar subquery can be used anywhere a value can be used. The subquery must refer just one column in • the select list. It must also retrieve no more than one row. When the subquery returns a single row, the value of the single select list column becomes the value of the scalar subquery. When the subquery returns no rows, a database null is used as the result of the subquery. Only few rows are retrieved through the outer query and especially when outer queries WHERE clause, which • limits the number of rows retrieved can use an index.

References Dr. Gordon, R., 1980. • SQL - Subqueries and Schema. [pdf] Available at: <http://db.grussell.org/slides/sql4.pdf> [Accessed 9 September 2011].Dobre, A., Schneuwly, D & Bleisch, S. • Structured Query Language SQL. [Pdf] Available at: <http://www.gitta.info/RelQueryLang/en/text/RelQueryLang.pdf> [Accessed 9 September 2011]. Sheldon, R. & Forrest, H., 2003. • SQL: a beginner’s guide, McGraw-Hill Professional. Groff, 2003. • Sql: The Complete Reference 2, Tata McGraw-Hill Education. Dr. Srinath, S., 2008. • Storage Structures. [Video online] Available at: <http://www.youtube.com/watch?v=9E4M6MCD4aI> [Accessed 9 September]. Dr. Srinath, S., 2008. • Query Processing and Optimization II. [Video online] Available at: <http://www.youtube.com/watch?v=FqUPoZzU834> [Accessed 9 September].

99

Recommended ReadingDonahoo, J, D. & Speegle, G. D., 2005. • SQL: practical guide for developers, Academic Press.Harrington, J. L., 2010. • SQL Clearly Explained, Elsevier.Oppel., 2005. • Sql Demystified, Tata McGraw-Hill Education.


100

Self Assessment_____________ is a database sublanguage for querying and modifying relational databases.1.

SQL a. MSb. Accessc. Excel d.

Which standards of computer are followed by SQL?2. IEEEa. CODECb. ANSIc. AIEEEd.

________ databases utilise their proprietary PL/SQL.3. Oraclea. Sunb. Solar c. Microsoft d.

Which of the following statements is true??4. MAC Server makes use of Transact-SQL.a. Database Server makes use of Transact-SQL.b. Macro Server makes use of Transact-SQL.c. Microsoft SQL Server makes use of Transact-SQL.d.

SQL has a lot of built-in functions for___________________.5. debug and deactivate a. drawing and mixingb. counting and calculationsc. checking and editing d.

Scalar functions operate against a ____________ value and return a _______ value based on the input value.6. single and single a. double and single b. negative and positive c. minus and plus d.

The ____________ must refer just one column in the select list.7. subquerya. query b. main query c. same queryd.

101

A grouping query is a special type of query that groups and summarises________.8. columna. rowb. data c. Table d.

Database _________ require special processing in ORDER BY9. .nullsa. valuesb. objectsc. picturesd.

The ORDER BY clause is________.10. main function a. compulsoryb. optionalc. essentiald.


102

Chapter VII

Database Security and Integrity

Aim


introduce database security•

elucidate database security threats •

explain the concept of data tampering •

Objectives


elaborate on data theft and eavesdropping •

describe the password-related threats•

explain data security requirement •

Learning outcome


describe monitoring of database protocol traffic (SQL)•

understand concept of access control •

understand the concept of authentication•

103

7.1 Introduction to Database SecurityDatabase security is the system, processes, and procedures that protect a database from unintended activity. Unintended activity can be categorised as authenticated misuse, malicious attacks or inadvertent mistakes made by authorised individuals or processes. Database Security is a specialty within the much broader area of computer security. Traditionally databases have been protected from external connections by firewalls or routers on the network perimeter with the database environment existing on the internal network.

As the use of the web grows on both Intranets and the public Internet, information security is becoming crucial to organisations. The Web provides a convenient, cheap, and instantaneous way of publishing data. Now that it is extremely easy to disseminate information, it is equally important to ensure that the information is only accessible to those who have the rights to use it. With many systems implementing dynamic creation of web pages from a database, corporate information security is even more vital.

Previously, strict database access or specialised client software was required to view the data. Now anyone with a web browser can view data in a database that is not properly protected. Never before has information security had so many vulnerable points. As the computing industry moves from the mainframe era to the client/server era to the Internet era, a substantially increasing number of points of penetration have opened up. Additional network security devices that detect and alert on malicious database protocol traffic include network intrusion detection systems along with host-based intrusion detection systems.

7.2 Database Security ThreatsDatabase security is the system, processes, and procedures that protect a database from unintended activity. Unintended activity can be categorised as authenticated misuse, malicious attacks or inadvertent mistakes made by authorised individuals or processes. Database Security is a specialty within the much broader area of computer security. Traditionally databases have been protected from external connections by firewalls or routers on the network perimeter with the database environment existing on the internal network. A threat is any type of situation that will adversely affect the database system. Some factors that drive the need for security are as follows:

Theft and fraud• Confidentiality• Integrity• Privacy• Database availability•

Threats to database security can come from many sources. People are a substantial source of database threats. Different types of people can pose different threats. Users can gain un-authorised access through the use of another person’s account. Some users may act as hackers and/or create viruses to adversely affect the performance of the system. Programmers can also pose similar threats. The Database Administrator can also cause problems by not imposing an adequate security policy.

7.2.1 Data TamperingData tampering is the deliberate destruction or manipulation of data. The tampering may or may not be detected until some time in the future. Data is threatened both in-transit (physically or electronically) and while it is stored.

For example, unprotected data packets can be intercepted and modified, or data can become corrupted due to execution of malicious code that has been executed by an attacker exploiting buffer overflow vulnerability. Beyond controlling access, sensitive data should be encrypted using hashes and digital signatures.


104

7.2.2 Identity ThreatsAs the sheer number of people and activities increase within the organisation, database security focuses on identity threats. One of the major identify threats is identity spoofing. Identity spoofing occurs when the method of authentication has been compromised. This can happen when an attacker has hacked or can replay a user’s authentication sequence. Using a valid user’s credentials, an attacker can impersonate that user and gain access to the areas of the application and data that are normally accessible to the impersonated user.

For example, authentication protocols that use passwords without encrypting them disclose credential information to an eavesdropper, who can then use this information to impersonate the user. Use strong authentication methods, such as Kerberos authentication and client authentication certificates, to best prevent spoofing. Storing authentication information in cookies and self-designed authentication schemes are the weakest and most easily foiled.

7.2.3 Data Theft and EavesdroppingData theft is the act of information from a database by an unknowing victim with the intent of compromising privacy or obtaining confidential information. Data theft is increasingly a problem for individual computer users, as well as big corporate firms. There is more than one way to steal data. Some popular methods are Ecommerce, Password cracking and eavesdropping. In eavesdropping the data sent on insecure lines can be wiretapped and recorded. If no encryption mechanism is used, there is a good chance of losing your password and other private information to the eavesdropper.

7.2.4 Password-Related ThreatsIn distributed systems the users must remember multiple passwords for the different applications and servers they use. Users typically respond to the problem of managing multiple passwords in several ways, such as:

They may select easy-to-guess passwords such as name, fictional character or a word found in dictionary. All • such passwords are vulnerable to attacks.They may also choose to standardise passwords so that they are the same on all machines or web sites. This • results in a potentially large exposure in the event of a compromised password. They can also use password with slight variations that can be easily derived from known passwords.Users with complex passwords may write them down where an attacker can easily find them or they may just • forget them requiring costly administration and support efforts. All of these strategies compromise password secrecy and service availability. Moreover administration of • multiple user accounts and passwords is complex, time consuming, and costly.

7.2.5 Unauthorised Access to Tables and ColumnsThe database may have confidential tables or confidential columns in a table, which should not be accessible to all users authorised to access the database. It should be possible to protect the data on a column level.

7.2.6 Unauthorised Access to Data RowsIn databases there may be confidential row, or rows in a table, which should not be accessible to all users, authorised to access the database. It should be possible to protect the data on a row level. In such cases granular access control or a way to enforce confidentiality on the data may be required.

For example, in a banking system we would allow customers to view only the information belonging to them but not of other customers. Hence, the system must be flexible and should support different security policies depending on what user you are dealing with.

105

7.3 Data Security RequirementsDatabase security is more critical as networks have become more open. Database security can begin with the process of creation and publishing of appropriate security standards for the database environment. The standards may include specific controls for the various relevant database platforms polices and governmental regulations.

7.3.1 Vulnerability AssessmentsAn important procedure when evaluating database security is performing vulnerability assessments against the database. A vulnerability assessment attempts to find vulnerability holes that could be used to break into the database. Database administrators or information security administrators run vulnerability scans on databases to discover mis-configuration of controls within the layers mentioned above along with known vulnerabilities within the database software. The results of the scans should be used to harden the database in order to mitigate the threat of compromise by intruders.

A program of continual monitoring for compliance with database security standards is another important task • for mission critical database environments. Two crucial aspects of database security compliance include patch management and the review and management of permissions (especially public) granted to objects within the database. Database objects may include table or other objects listed in the Table link. The permissions granted for SQL language commands on objects are considered in this process.

One should note that compliance monitoring is similar to vulnerability assessment with the key difference • that the results of vulnerability assessments generally drive the security standards that lead to the continuous monitoring program.

Essentially, vulnerability assessment is a preliminary procedure to determine risk where a compliance program is • the process of on-going risk assessment. The compliance program should take into consideration any dependencies at the application software level as changes at the database level may have effects on the application software or the application server.

Application level authentication and authorisation mechanisms should be considered as an effective means • of providing abstraction from the database layer. The primary benefit of abstraction is that of a single sign-on capability across multiple databases and database platforms. A Single sign-on system should store the database user’s credentials (login id and password), and authenticate to the database on behalf of the user.

7.3.2 Monitoring of Database Protocol Traffic (SQL)Another security layer of a more sophisticated nature includes the real-time monitoring of database protocol traffic (SQL) over the network. Analysis can be performed on the traffic for known exploits or network traffic baselines can be captured overtime to build a normal pattern used for detection of anomalous activity that could be indicative of intrusion. These systems can provide a comprehensive Database audit trail in addition to the intrusion detection (and potentially protection) mechanisms.

When a network level audit system is not feasible, a native database audit program should be instituted. The • native audit trails should be extracted on a regular basis and transferred to a designated security system where the database administrators do not have access. This ensures a certain level of segregation of duties that may provide evidence the native audit trails were not modified by authenticated administrators. Generally, the native audit trails of databases do not provide sufficient controls to enforce separation of duties; • therefore, the network and/or kernel module level host based monitoring capabilities provides a higher degree of confidence for forsenices and preservation of evidence. After an incident occurs, the usage of Database Forensics can be employed to determine the scope. A Database Security program should include the regular review of permissions granted to individually owned • accounts and accounts used by automated processes. The accounts used by automated processes should have appropriate controls around password storage such as sufficient encryption and access controls to reduce the risk of compromise.


106

In conjunction with a sound Database Security program, an appropriate disaster recovery program should exist • to ensure that service is not interrupted during a security incident or any other incident that results in an outage of the primary database environment. An example is that of replication for the primary databases to sites located in different geographical regions.

7.3.3 Access ControlAccess to protected information must be restricted to people who are authorised to access the information. The computer programs, and in many cases the computers that process the information, must also be authorised. This requires that mechanisms be in place to control the access to protected information.

The sophistication of the access control mechanisms should be in parity with the value of the information being protected - the more sensitive or valuable the information the stronger the control mechanisms need to be. The foundation on which the access control mechanisms are built should start with identification and authentication.

Identification is an assertion of who someone is or what something is. If a person makes the statement “Hello, my name is John Doe.” they are making a claim of who they are. However, their claim may or may not be true. Before John Doe can be granted access to protected information it will be necessary to verify that the person claiming to be John Doe really is John Doe.

7.3.4 AuthenticationAuthentication is the act of verifying a claim of identity. There are three different types of information that can be used for authentication, something you know, something you have, or something you are. Examples of something you know include such things as a PIN, a password, or your mother’s maiden name. Examples of something you have include a driver’s license or a magnetic swipe card. Something you are refers to biometrics.

Examples of biometrics include palm prints, finger prints, voice prints and retina (eye) scans. Strong authentication • requires providing information from two of the three different types of authentication information. For example, something you know plus something you have. This is called two factor authentications. On computer systems in use today, the Username is the most common form of identification and the Password is the most common form of authentication. Usernames and passwords have served their purpose but in our modern world they are no longer adequate. • Usernames and passwords are slowly being replaced with more sophisticated authentication mechanisms. After a person, program or computer has successfully been identified and authenticated then it must be determined what informational resources they are permitted to access and what actions they will be allowed to perform (run, view, create, delete, or change). This is called authorisation. Authorisation to access information and other computing services begins with administrative policies and • procedures. The policies prescribe what information and computing services can be accessed, by whom, and under what conditions. The access control mechanisms are then configured to enforce these policies. In the access control mechanism, a system offers will be based upon one of three approaches to access control • or it may be derived from a combination of the three approaches. The non-discretionary approach consolidates all access control under a centralised administration. The access to information and other resources is usually based on the individuals function (role) in the organisation or the tasks the individual must perform. The discretionary approach gives the creator or owner of the information resource the ability to control access to those resources. In the Mandatory access control approach, access is granted or denied bases upon the security classification • assigned to the information resource. Examples of common access control mechanisms in use today include Rolebased access control available in many advanced Database Management Systems, simple file permissions provided in the UNIX and Windows operating systems, Group Policy Objects provided in Windows network systems, Kerberos and the simple access lists used in many firewalls and routers. To be effective, policies and other security controls must be enforceable and upheld. Effective policies ensure • that people are held accountable for their actions. All failed and successful authentication attempts must be logged, and all access to information must leave some type of audit trail.

107

7.3.5 IntegrityIntegrity means that data should be protected from deletion and corruption, both while it resides within the database and while being transmitted over the network. A secure system ensures that data it contains is valid. Integrity has several aspects and have control access to application tables and system commands, so that only authorised users can alter data.

Referential integrity is the ability to maintain valid relationships between values in the database, according to rules that have been specified. A database must be protected against viruses designed to corrupt the data. The network traffic must be protected from deletion, corruption and eaves dropping.

7.3.6 AvailabilityIn secured systems, the data must be made available to authorised users without delay. Denial-of-service attacks are attempts to block authorised users ability to access and use the system when needed. System availability has a number of aspects.

Resistance: • A secure system must have facilities within the database to prohibit runaway queries. User profiles must be in place to define and limit the resources any given user may use to ensure fair resource utilisation.Scalability: • Regardless of the number of users or processes requesting services system performance must not be affected.Flexibility: • Administrators must have adequate means of managing the user population, may be by creating various directories.Ease-of-use: • Valid users should not face difficulties due to security restrictions.

Availability Aspect Description

Resistance

A secure system must be designed to fend off situations, or deliberate attacks, which might put it out of commission. For example, there must be facilities within the database to prohibit runaway queries. User profiles must be in place to define and limit the resources any given user may consume. In this way the system can be protected against users consuming too much memory or too many processes, lest others be prevented from doing their work.

Scalability System performance must remain adequate regardless of the number of users or processes demanding service.

Flexibility Administrators must have adequate means of managing the user population. For example they might do this by using a directory.

Ease of Use The security implementation itself must not diminish the ability of valid users to get their work done.

Table 7.1 Availability aspect

7.4 RolesDatabase management systems provides for easy and controlled privilege management through roles. Roles are named groups of related privileges that you grant to users or other roles. Roles are designed to ease the administration of end-user system and object privileges. However, roles are not meant to be used for application developers, because the privileges to access objects within stored programmatic constructs need to be granted directly. These properties of roles allow for easier privilege management within a database: Reduced privilege administration Rather than explicitly granting the same set of privileges to several users, you can grant the privileges for a group of related users to a role, and then only the role needs to be granted to each member of the group.


108

Dynamic privilege management:• If the privileges of a group must change, only the privileges of the role need to be modified. The security domains of all users granted the group’s role automatically reflect the changes made to the role.Selective availability of privileges: • You can selectively enable or disable the roles granted to a user. This allows specific control of a user’s privileges in any given situation.Application awareness:• Because the data dictionary records which roles exist, you can design database applications to query the dictionary and automatically enable (and disable) selective roles when a user attempts to execute the application via a given username.Application-specific security:• You can protect role use with a password. Applications can be created specifically to enable a role when supplied the correct password. Users cannot enable the role if they do not know the password.

Common uses for rolesIn general, you create a role to serve one of two purposes: to manage the privileges for a database application or to manage the privileges for a user group and the sections that follow describe the two uses of roles.

Users

PAY_CLERK Role

ACCTS_PAY Role ACCTS_REC Role

MANAGER Role REC_CLERK Role

Privileges to execute the

ACCTS_PAY application

Privileges to execute the

ACCTS_REC application

Application Privileges

Application Roles

User Roles

Fig. 7.1 Common uses of roles

7.5 Granting and Revoking Privileges and RolesWho Can Grant or Revoke Roles depends on the DBMS. For example, any user with the GRANT ANY ROLE system privilege can grant or revoke any role to or from other users or roles of the database. Additionally, any user granted a role with the ADMIN OPTION can grant or revoke the privileges and role to or from other users. In most DBMS the DBAs and security officers have the power to grant and revoke the privileges and roles to the users.

Grant: define access privilegesSynopsisGRANT {ALL | privilege-list }ON { tablename [(column-comma-list)] | view-name[(column-comma-list)] }TO { PUBLIC | user-list }[ WITH GRANT OPTION ]

109

DescriptionThe key word PUBLIC indicates that the privileges are to be granted to all roles, including those that might be created later. PUBLIC can be thought of as an implicitly defined group that always includes all roles. Any particular role will have the sum of privileges granted directly to it, privileges granted to any role it is presently a member of, and privileges granted to PUBLIC.

If WITH GRANT option is specified, the recipient of the privilege can in turn grant it to others. Without a grant option, the recipient cannot do that. Grant options cannot be granted to PUBLIC. There is no need to grant privileges to the owner of an object (usually the user that created it), as the owner has all privileges by default. (The owner could, however, choose to revoke some of his own privileges for safety.)

The right to drop an object or to alter its definition in any way is not described by a grantable privilege; it is inherent in the owner, and cannot be granted or revoked. The owner implicitly has all grant options for the object, too. Depending on the type of object, the initial default privileges might include granting some privileges to PUBLIC.

The default is no public access for tables, schemas, and tablespaces; CONNECT privilege and TEMP table creation privilege for databases; EXECUTE privilege for functions; and USAGE privilege for languages. The object owner can of course revoke these privileges. The possible privileges are:

SELECT: • Allows SELECT from any column of the specified table, view, or sequence.Also allows the use of COPY TO.INSERT: • Allows INSERT of a new row into the specified table. Also allows COPY FROM.UPDATE: • Allows UPDATE of any column of the specified table. SELECT ... FOR UPDATE and SELECT ... FOR SHARE also require this privilegeDELETE: • Allows DELETE of a row from the specified table.REFERENCES: • To create a foreign key constraint, it is necessary to have this privilege on both the referencing and referenced tables.TRIGGER: • Allows the creation of a trigger on the specified table.CREATE: • For databases, allows new schemas to be created within the database. For schemas, allows new objects to be created within the schema. To rename an existing object, you must own the object and have this privilege for the containing schema. For table spaces, allows tables, indexes, and temporary files to be created within the tablespace, and allows databases to be created that have the tablespace as their default tablespace.CONNECT: • Allows the user to connect to the specified database. This privilege is checked at connection start-up.TEMPORARY TEMP: • Allows temporary tables to be created while using the database.EXECUTE: • Allows the use of the specified function and the use of any operators that are implemented on top of the function. This is the only type of privilege that is applicable to functions.USAGE: • For procedural languages, allows the use of the specified language for the creation of functions in that language. This is the only type of privilege that is applicable to procedural languages. For schemas, allows access to objects contained in the specified schema (assuming that the objects’ own privilege requirements are also met). Essentially this allows the grantee to “look up” objects within the schema.ALL PRIVILEGES: • Grant all of the available privileges at once.

For example,Grant inserts privilege to all users on table films.

GRANT INSERT ON films TO PUBLIC: • Grant all available privileges to user manual on view kinds.GRANT ALL PRIVILEGES ON kinds TO manual: • Note that while the above will indeed grant all privileges if executed by a superuser or the owner of kinds, when executed by someone else it will only grant those permissions for which someone else has grant options.Grant membership in role admins to user manager: • GRANT admins TO manager;


110

Revoke: Remove access privilegesSynopsisREVOKE {ALL | privilege-list}ON [tablename [(column comma list) ] | view name] [(column comma list) ]FROM {PUBLIC | user-list)

DescriptionIf ‘ALL’ is specified then all privileges for the object specified will be revoked. If a ‘privilege-list’ is specified then only those privileges will be revoked. The ‘ON’ clause specifies the object from which the privileges are removed. It can be a table or a view. If an optional ‘column-comma-list’ is specified, the privilege will be restricted to those columns. The FROM clause is used to identify the users from whom the privileges are taken away. The keyword PUBLIC means the privileges are revoked from all known users of the system.

For example,Revoke insert privilege for the public on table films:REVOKE INSERT ON films FROM PUBLIC;Revoke all privileges from user manual on view kinds:REVOKE ALL PRIVILEGES ON kinds FROM manual;Note that this actually means “revoke all privileges that I granted”. Revoke membership in role admins from user joe: REVOKE admins FROM joe;

7.6 Digital Signatures as Passwords for Data SecurityThe real plan for the public-key system is to use it in conjunction with the secret-key system. Rather than having a large private key that must be transported from computer to computer, the private key would instead be encrypted using a secret-key system. The user then simply remembers a simple password (like the PIN for his or her ATM card) that is used to decrypt the private key.

Encrypted private keys could then be stored on servers, in smart cards, or on your credit card. Sending a certain code encrypted with your private key, for example, would only permit access to a database. The encoded document is received by the user authentication program, it is decoded with your public key, and access is granted.

7.7 Introduction to Data IntegrityData integrity refers to the method of authenticating the data that whether it is validated or not. Validation here refers to know that whether the data can be used further or not and its significance can also be known by the person too. Validity is one of the most essential components of data integrity. Validation makes sure that there are no errors in the data and the errors that can be found in the data may be due to some virus or bugs which need to be removed.

Data integrity is mainly composed of the errors which are occurred part of the humans. The error may have been incurred due to the data entry in the computer. Another reason could be due to the transmission of data from one place to the other and sometime data integrity could also be caused due to the malfunctioning of some of the parts of the computer or even the hard disk of the computer is not working properly. At time data integrity can create certain problems for people but some solutions can also exist for these as well.

One of the major solutions that can be helpful in removing all the error that had been occurred in data integrity could be, if all the files, folders and documents in the computer are backup which as a results validates that the data is protected and will not be lost at all. Sometimes the data can be saved if the security items had been installed in the computer which as a result controls all the errors.

Lastly the person can make use of the error recognition in case of finding out the errors. This is one of the simplest ways of detecting the errors. When all the functions are being performed it must be made sure that integrity and reliability both are being performed at the same time.

111

7.8 Integrity ConstraintsIntegrity constraints are used to ensure accuracy and consistency of data in a relational database. Data integrity is handled in a relational database through the concept of referential integrity. There are many types of integrity constraints that play a role in referential integrity. Codd, initially defined two sets of constraints, but in his second version of the relational model, he came up with following integrity constraints:

Entity integrity• Referential integrity• Domain integrity• Column integrity•

7.8.1 Entity Integrity ConstraintsIn a relational database, entity integrity is a property that ensures that no records are duplicated and that no attributes that make up the primary key are NULL. It is one of the properties necessary to ensure the consistency of the database. Entity Integrity ensures that there are no duplicate records within the table and that the field that identifies each record within the table is unique and never null.

The existence of the Primary Key is the core of the entity integrity. If you define a primary key for each entity, they follow the entity integrity rule. Entity integrity specifies that the primary keys on every instance of an entity must be kept, must be unique and must have values other than NULL. Entity Integrity ensures two properties for primary keys. The primary key for a row is unique; it does not match the primary key of any other row in the table.

The primary key is not null, no component of the primary key may be set to null. The uniqueness property ensures that the primary key of each row uniquely identifies it; there are no duplicates. The second property ensures that the primary key has meaning, has a value; no component of the key is missing. The system enforces Entity Integrity by not allowing operations (INSERT, UPDATE) to produce an invalid primary key. Any operation that creates a duplicate primary key or one containing nulls is rejected.

7.8.2 Referential IntegrityReferential integrity in a relational database is consistency between coupled tables. Referential integrity is usually enforced by the combination of a primary key or candidate key (alternate key) and a foreign key. For referential integrity to hold, any field in a table that is declared a foreign key can contain only values from a parent table’s primary key or a candidate key.

For instance, deleting a record that contains a value referred to by a foreign key in another table would break referential integrity. The relational database management system (RDBMS) enforces referential integrity, normally either by deleting the foreign key rows as well to maintain integrity, or by returning an error and not performing the delete. Which method is used would be defined by the definition of the referential integrity constraint.

For example,An employee database stores the department in which each employee works. The field “Department Number” in the Employee table is declared a foreign key, and it refers to the field “Index” in the Department table which is declared a primary key. Referential integrity would be broken by deleting a department from the Department table if employees listed in the Employee table are listed as working for that department.

Referential integrity rulesA referential integrity rule is a rule defined on a key (a column or set of columns) in one table that guarantees that the values in that key match the values in a key in a related table (the referenced value). Referential integrity also includes the rules that dictate what types of data manipulation are allowed on referenced values and how these actions affect dependent values. The rules associated with referential integrity are:

Restrict• : Disallows the update or deletion of referenced data.Set to Null• : When referenced data is updated or deleted, all associated dependent data is set to NULL.


112

Set to Default• : When referenced data is updated or deleted, all associated dependent data is set to a default value.Cascade• : When referenced data is updated, all associated dependent data is correspondingly updated. When a referenced row is deleted, all associated dependent rows are deleted. No Action: Disallows the update or deletion of referenced data. This differs from RESTRICT in that it is checked at the end of the statement, or at the end of the transaction if the constraint is deferred.

7.8.3 Domain Level IntegrityA domain defines the possible values of an attribute. Domain integrity rules govern these values. In a database system, the domain integrity is defined by:

The datatype and the length• The NULL value acceptance• The allowable values, through techniques like constraints or rules• The default value•

For example, if you define the attribute of Age, of an Employee entity, is an integer, the value of every instance of that attribute must always be numeric and an integer. If you also define that this attribute must always be positive, the negative value is forbidden.The value of this attribute being mandatory indicates that the attribute can be NULL. All of these characteristics form the domain integrity of this attribute.

This type of data integrity warrants the following: the identity and purpose of a field is clear and all of the tables in which it appears are properly identified; field definitions are consistent throughout the database; the values of a field are consistent and valid; and the types of modifications, comparisons and operators that can be applied to the values in the field are clearly identified.

Each attribute in the model should be assigned domain information which includes:Data type: • Basic data types are integer, decimal, or character. Most data bases support variants of these plus special data types for date and time.Length: • This is the number of digits or characters in the value. For example, a value of 5 digits or 40 characters.Date format: • The format for date values such as dd/mm/yy or mm/dd/yyyy or yy/mm/dd.Range: • The range specifies the lower and upper boundaries of the values the attribute may legally have.Constraints: • Are special restrictions on allowable values. For example, the Leaving Date for an Employee must always be greater than the HireDate for that Employee.Null support: • Indicates whether the attribute can have null values.Default value (if any): • The value an attribute instance will have if a value is not entered.

7.8.4 Column IntegrityThis section describes the rules that can be applied to table columns to enforce different types of data integrity.

Null rule: • A null rule is a rule defined on a single column that allows or disallows inserts or updates of rows containing a null (the absence of a value) in that column.Unique column values: • A unique value rule defined on a column (or set of columns) allows the insert or update of a row only if it contains a unique value in that column (or set of columns).Primary key values: • A primary key value rule defined on a key (a column or set of columns) specifies that each row in the table can be uniquely identified by the values in the key.Complex integrity checking: • Complex integrity checking is a user-defined rule for a column (or set of columns) that allows or disallows inserts, updates, or deletes of a row based on the value it contains for the column (or set of columns).

113

Summary Database security is the system, processes and procedures that protect a database from unintended activity. • Unintended activity can be categorised as authenticated misuse, malicious attacks or inadvertent mistakes made by authorised individuals or processes. Database security is a specialty within the much broader area of computer security. Traditionally databases have • been protected from external connections by firewalls or routers on the network perimeter with the database environment existing on the internal network. Threats to database security can come from many sources. People are a substantial source of database threats.• Data tampering is the deliberate destruction or manipulation of data.• One of the major identify threats is identity spoofing. Identity spoofing occurs when the method of authentication • has been compromised. This can happen when an attacker has hacked or can replay a user’s authentication sequence.Data theft is the act of information from a database by an unknowing victim with the intent of compromising • privacy or obtaining confidential information.In distributed systems the users must remember multiple passwords for the different applications and servers • they use.The database may have confidential tables or confidential columns in a table, which should not be accessible • to all users authorised to access the database.Database security is more critical as networks have become more open. Database security can begin with the • process of creation and publishing of appropriate security standards for the database environment.An important procedure when evaluating database security is performing vulnerability assessments against the • database. A vulnerability assessment attempts to find vulnerability holes that could be used to break into the database.• A program of continual monitoring for compliance with database security standards is another important task • for mission critical database environments.Application level authentication and authorisation mechanisms should be considered as an effective means of • providing abstraction from the database layer.Security layer of a more sophisticated nature includes the real-time monitoring of database protocol traffic • (SQL) over the network.A Database Security program should include the regular review of permissions granted to individually owned • accounts and accounts used by automated processes.Access to protected information must be restricted to people who are authorised to access the information.• Integrity means that data should be protected from deletion and corruption, both while it resides within the • database and while being transmitted over the network.A secure system must have facilities within the database to prohibit runaway queries.• Database management systems provides for easy and controlled privilege management through roles. Roles are • named groups of related privileges that you grant to users or other roles.

References Shulman, A. • Top Ten Database Security Threats. [pdf] Available at: <http://www.schell.com/Top_Ten_Database_Threats.pdf> [Accessed 13 September 2011]. Anuramn, 2010. • Threats to Database Security. [Online] Available at: <http://www.brighthub.com/computing/smb-security/articles/61554.aspx> [Accessed 13 September 2011].Dr. Srinath, S., 2008. • Functional Dependencies and Normal Form. [Video online] Available at: <http://www.youtube.com/watch?v=YD8dhOmuVnY> [Accessed 9 September]. Janakiram, D., 2008. • Distributed Transaction Models. [Video online] Available at: <http://www.youtube.com/watch?v=hNOEL3SM9No&feature=related> [Accessed 9 September 2011].


114

Singh, S.K., 2009. • Database Systems: Concepts, Design and Applications, Pearson Education India. Hoffer, 2009. Modern Database Management Systems, 9/E, Pearson Education India.•

Recommended ReadingGertz, M. & Jajodia, S., 2008. • Handbook of database security: applications and trends, Springer.McNicholas, M., 2007. • Maritime security: an introduction, Butterworth-Heinemann.Atluri, V & Hale, J., 2000. • Research advances in database and information systems security: IFIP TC11 WG11.3 Thirteenth Working Conference on Database, Springer.

115

Self Assessment Database ___________ is the system, processes, and procedures that protect a database from unintended 1. activity.

securitya. management b. organisation c. service d.

________________activity can be categorised as authenticated misuse, malicious attacks or inadvertent mistakes 2. made by authorised individuals or processes.

Intendeda. Unintendedb. Plannedc. Involuntaryd.

Who provide 3. convenient, cheap, and instantaneous way of publishing data? Paper a. Webb. Notes c. Television d.

Which of the following statements is true?? 4. Database is the system, processes, and procedures that protect a database from unintended activity.a. Database security is the system, processes, and procedures that protect a database from unintended b. activity.Database Management is the system, processes, and procedures that protect a database from unintended c. activity.Database organisation is the system, processes, and procedures that protect a database from unintended d. activity.

The Database Administrator can also cause problems by not imposing an adequate security__________ .5. policya. deviceb. codec. system d.

Data tampering is the deliberate destruction or manipulation of ______________.6. message a. data b. system c. threats d.

One of the major identify threats is identity __________________. 7. spoofinga. threatb. spamming c. jam d.


116

Identity spoofing occurs when the method of ______________ has been compromised.8. licensea. authenticationb. approvalc. supportd.

___________ is the act of information from a database by an unknowing victim with the intent of compromising 9. privacy or obtaining confidential information.

Data spoofing a. Data Spammingb. Data theftc. Data nickingd.

Database security is more critical as networks have become more _______. 10. open a. reserve b. important c. secure d.

117

Chapter VIII

Structure, Components, Functions and Implementation of Database Management System

Aim


describe the structure of a DBMS •

explain the execution of steps of a DBMS •

explicate component of a DBMS •

Objectives


elaborate on first normal forms•

discuss the problems addressed by normalisation •

enlist the database control system component •

Learning outcome


describe the functions of database manger •

understand DML processor •

identify transaction management •


118

8.1 Structure of DBMSThe structure of the DBMS varies greatly from system to system; therefore, a generalised component structure of DBMS is not possible to make. A structure of DBMS with its components and relationships between them is shown in the figure given below. The DBMS is partitioned into several modules. Each module or component is assigned a specific operation to perform. Some of the functions of the DBMS are supported by operating systems (OS) to provide basic services and DBMS is built on top of it. The physical data and system catalog are stored on a physical disk. Access to the disk is controlled primarily by OS which schedules disk input/output. Therefore, while designing a DBMS, its interface with the OS must be taken into account.

8.2 Execution Steps of DBMSAs shown in figure given below, logical steps followed while executing users request to access database system are:

Users issue a query using particular database language, for example, SQL commands.• The passed query is presented to the query optimiser, which uses information about how the data is stored to • produce an execution plan for evaluating the query.The DBMS accepts the users SQL commands and analyses them.• The DBMS produces the query evaluation plans, that is, the external schema for the user, the corresponding • external/conceptual mapping, the conceptual schema, the conceptual/internal mapping and the storage structure definition. Thus, an evaluation plan is a blueprint for evaluating the query.The DBMS executes these plans against the physical database and returns the answers to the users.•

Using components such as transaction manager, buffer manager, recovery manager, the DBMS supports the concurrency and crash recovery by carefully scheduling user’s requests and maintaining a log of all changes to the database.

119

Index Files

Data FilesSystem catalog/Data dictionary (Metadata)

Physical Database

Database schemes and mappings

Application programsQueries

DBA Users Programmers

DDL Statements

DDL Processor

DDL Compiler

Interactivity Query

Query Processor

Query Compiler

DML Statemets

DML Processor

DML Compiler

System catalog/Data dictionary (Metadata)

Authorisation Control

Command Processor

Transaction Manager

Buffer Manager

Query Optimiser

Scheduler

Recovery Manager

Integrity CheckerD

atab

ase

Man

agem

ent S

yste

m (D

BM

S)

Run

Tim

e D

atab

ase

Man

ager

Fig. 8.1 Structure of DBMS

8.3 Components of DBMSThe DBMS accepts the SQL commands generated from a variety of user interfaces, produces query evaluation plans, executes these plans against the database and returns the answers. The major software module or the components of DBMS are as follows:

Query processorThe query processor transforms users queries into series of low-level instructions directed to the run time database manager. It is used to interpret the online users query and convert it into an efficient series of operations in a form, which is capable of being sent to the run time data manager for execution. The query processor uses the data dictionary to find the structure of the relevant portion of the database and uses this information in modifying the query and preparing an optimal plan to access the database.


120

Run time database managerIt is a central component of a DBMS, which interfaces user submitted application programs and queries. It handles database access at run time. It converts operations in user’s queries coming directly via the query processor or indirectly via an application program from the user’s logical view to a physical file system. It accepts the queries and examines the queries, the external and conceptual schema to determine what conceptual records are required to satisfy the user’s request.

The run time data manager then places a call to the physical database to perform the request. It enforces constraints to maintain the consistency and integrity of the data as well as its security. It also performs its backing and recovery. Run time database manager is sometimes referred to as the database control system and has the following components:

Authorisation control• : This module checks that the user has necessary authorisation to carry out the required operation.Command processor• : It processes the queries passed by authorisation control module.Integrity Checker• : It checks for necessary integrity constraints for all the requested operations that changes the database.Query Optimiser• : It determines an optimal strategy for the query execution. It uses information on how the data is stored to produce the efficient execution plan for evaluating the query.Transaction manager• : The transaction manager performs the required processing of operation it receives from transactions. It ensures the following:

Transaction requests and releases locks according to a suitable locking protocol. �Schedules the execution of the transactions. �

Scheduler• : The scheduler is responsible for ensuring that the concurrent operations on the database proceed without conflicting with one another. It controls the relative order in which transaction operations are executed. Data manager• : It is responsible for actual handling of data in the database. This module has two components:

Recovery manager: � It ensures that the database remains in a consistent state in presence of failures. It is responsible for the following:

- Transaction commits and aborts operations- Maintaining the log - Restoring the system to a consistent state after a crash

Buffer manager: � It is responsible for transfer of data from main memory and secondary storage (such as disk or tape drives etc.). Buffer manager is sometimes referred to as a cache manager.

DML processorUsing a DML compiler, the DML processor converts the DML statements embedded in an application program into standard function calls in the host language. The DML compiler converts the DML statements written in host programming language into object code for database access. The DML processor must interact with the query processor to generate the appropriate code.

DDL processorUsing a DDL compiler, the DDL processor converts the DDL statements into a set of tables containing metadata. These tables contain the metadata concerning the database and are in a form that can be used by other components of the DBMS. These tables are then stored in the system catalog while control information is stored in data file headers. The DDL compiler processes schema definitions, specified in the DDL and stores description of the schema (metadata) in the DBMS system catalog. The system catalog includes information such as the names of data files, data items, storage details of each data files, mapping information amongst schema and constraints.

121

8.4 Functions and Services of a DBMSDBMS offers several important functions that guarantee integrity and consistency of data in the database. Figure shown below illustrates the functions and services of a database.

Data dictionary/ System catalogue Management

Data Definition Services

Database Access and Application Interface

Utility Services

Data Independence Services

Transaction Management

Concurrency Control Services

Backup and Recovery Management

Authorisation Security Management

Database Communication Interface

Data Manipulation Management

Data Storage Management

Index Files

Data Files

System catalogue/Data dictionary (Metadata)

Physical Database

Fig. 8.2 Functions and services of DBMS

Data storage managementDatabase Management System (DBMS) is a suite of programs, which typically manages large structured sets of persistent data, offering ad hoc query facilities to many users. They are widely used in business applications. When DBMS is used, information systems can be changed much more easily as the organisation’s information requirements change.

New categories of data can be added to the database without disruption to the existing system. The DBMS also provides for forms and screen definition, report definitions, data validation rules, procedural code, structure to handle video and picture formats and so on.

Data manipulation managementDBMS can be an extremely complex set of software programs that controls the organisation, storage and retrieval of data (fields, records and files) in a database. It includes a DML processor component to deal with the Data Manipulation Language.


122

Data definition servicesDBMS accepts the data definitions such as external schema, the conceptual schema, the internal schema and the associated mappings in source form. It converts them to the appropriate object form using a DDL processor component.

Data dictionary/system catalog managementThe DBMS provides a data dictionary and system catalog function in which descriptions of data items are stored and which is accessible to users. All of the various schemas and mappings and all of the various security and integrity constraints in both source and object forms are stored in data dictionary. The system catalog is automatically created by the DBMS and consulted frequently to solve the user’s request.

Database communication interfacesThe DBMS provides special communication routines to allow the database to accept end-user request and transmit the response back to the end user in the computer network environment. The DBMS integrates with a communication software component called data communication manager (DCM) which controls these message communication activities.

Authorisation/security managementData security prevents unauthorised users from viewing or updating the database. Using passwords, users are allowed access to the entire database or subsets of the database, called subschema’s .For example, an employee database can contain all the data about an individual employee but one group of users may be authorised to view only payroll data while others are allowed access to only work history and medical data.

This way the DBMS prevents unauthorised access to the data. The DBMS monitors and controls the level of access for each user and the operation that each user can perform on the data depending on the access privileges or access rights of the users. Some DBMS uses various security management techniques like data encryption, security audits and provides audit trails for recording various database activities.

Backup and recovery managementThe DBMS provides mechanisms for backing up data periodically and recovering from different types of failures. The recovery mechanism of DBMS makes sure that the database is returned to a consistent state after a transaction fails or aborts due to a system crash, hardware or software crash/failure, power failure and so on. DBMS may support full or partial backup. Full backup saves entire data may be entire file or the database, whereas, partial backup may store only changes made after the last backup. Partial backup is less time consuming. Some DBMS supports online-backup.

Concurrency control servicesSince DBMS supports concurrent access and data sharing among multiple users, it needs to manage concurrent access to the database. DBMS ensures that the database is kept in the consistent state and the integrity of the data is preserved. It ensures that concurrent updating is handled correctly.

Transaction managementA transaction is a series of database operations carried out by a single user or application program, which accesses or changes the contents of the database. Therefore, a DBMS must provide a mechanism to ensure either that all the updates corresponding to a given transaction is made or that none of them is made.

Integrity servicesA DBMS must provide means to ensure that both the data in the database and changes to the data follow certain rules so that correctness and consistency of the stored data is maintained.

Data independence servicesA DBMS must support the independence of programs from the actual structure of the database.

123

Utility servicesThe DBMS provides a set of utility services used by the DBA and the database designer to create, implement, monitor and maintain the database. These utility services help the DBA to administer the database effectively.

Database access and application programming interfacesAll DBMSs provide interface to enable applications to use DBMS services. They provide data access via structured query language (SQL). The DBMS query language contains two contains two components:

A data definition language (DDL), which defines the structure in which data are stored.• The data Manipulation Language (DML) allows end users to extract the data from the database.•

8.5 Types of Database SystemsOn the basis of the site locations, DBMS which are presently being used are being described below.

Types of DBMS

Centralised DBMS

Parallel DBMS

Distributed DBMS

Client/Server DBMS

Fig. 8.3 Types of Database Management System

8.5.1 Centralised Database SystemThe centralised database system consists of a single processor together with its associated data storage and other peripherals, for example, the database server is confined to a single location. The system offers data capabilities to the users who are located at the same site or may be geographically dispersed provided they are interconnected.


124

Local User #1 Local User #2

Remote User #2

Local User #4Local User #3

Remote User #1

Physical Data

Fig. 8.4 Centralised database system

Advantages of centralised database systemMost of the functions such as update, backup, query control access and so on are easier to accomplish in a • centralised database system. Organisation has a free hand to decide upon the size of the database server (computer which may be a desktop • PC or a mainframe) depending upon the database requirements.

Disadvantages of centralised database systemWhen the central site computer or database system goes down, then all users are blocked from using the system • until it is restored back. Communication costs from terminals to the central site can be expensive.•

8.5.2 Parallel Database SystemParallel database systems consists of multiple data processing Units (CPUs) and data storage disks in parallel. Hence, they improve processing and input/output (I/O) speeds. Parallel database systems are used in applications that have to query extremely large databases or that have to process an extremely large number of transactions per second. Parallel database systems can have following architectures:

Shared memory architecture: • It is where all the processors share a common memory as in figure given below.

125

Processor

Processor

Processor

Memory

Storage Disk

Storage Disk

Fig. 8.5 Shared memory architecture

Shared disk storage• : It is where all the processors share a common storage media as in figure shown below.

Processor

Memory

Processor

Memory Memory

Processor

Storage Disk

Fig. 8.6 Shared disk storage

Independent resources architecture• : Here, all the processors use their own resources as shown in the figure given below.


126

Processor

Memory

Memory

Processor

Storage Disk

Storage Disk

Fig. 8.7 Independent resources architecture

Hierarchical Network• which is the combination of all the above networks is shown in the figure given below.

Processor

Processor

Processor

Memory

Storage Disk

Storage Disk

Processor

Processor

Processor

Memory

Storage Disk

Storage Disk

Fig. 8.8 Hierarchical network

127

Advantages of parallel database systemParallel database systems are very useful for applications that have to query extremely large databases of the • order of terabytes or that have to process an extremely large number of transactions per second for example, order of thousand transactions per second.System throughput and response time are very high. •

Disadvantages of parallel database systemThere is a start-up cost associated with initiating a single process and the start-up time may overshadow the • actual processing time, affecting speedup adversely.Since processes executing in a parallel system often access shared resources, a slowdown may result from • interference of each new process as it competes with existing one for commonly used resources.

8.5.3 Client/Server Database SystemIn client/server architecture the client is generally a desktop PC, whereas, the server can be a large workstation, mini range computer system or mainframe computer systems. The applications and tools of the DBMS run on one or more client platforms, while the DBMS software resides on server. The server computer is called a backend and the client’s computer is called the frontend. The server and client are connected into a network. A typical client/ server system is as shown in figure given below.

The client applications may be tools, user or vendor applications. They issue SQL statements for data access. The DBMS server stores the related software, processes the SQL statements and returns the result. The communication network interface enables client applications to connect to the server, send SQL statements and receive results or error messages or error return code after the server has processed the SQL statements. In client/server database architecture majority of the DBMS services are performed on the server.

Client 4: Application & Tools

Server: DBMS Software

Client 1: Application & Tools Client 2: Application & Tools Client 3: Application & Tools

Physical Database

Communication network

Fig. 8.9 Client server database


128

Advantages of client server database systemClient server has less expensive platform to support applications, which previously required expensive computers. • It offers icon based, menu driven user friendly interface.Client/Server environment facilitates in more productive work by the users and making better use of existing • data. It is more flexible system as compared to centralised system.Response time and throughput is high. The server (database) can be custom built to the database function, hence, • can provide better DBMS performance.The client provides better interfaces, high availability, faster responses and overall improved ease of use to the • user. A single database can be shared across several distinct client systems.

Disadvantages of client server database systemProgramming cost is high, particularly, in the initial phases.• There is a lack of management tools for diagnosis, performance monitoring, tuning and security control for the • DBMS, client and OS and networking environment.

8.5.4 Distributed Database Systems A distributed database is a database that is under the control of a central database management system (DBMS) in which all storage devices are not attached to a common CPU. It may be stored in multiple computers located in the same physical location or may be dispersed over a network of interconnected computers.

Collections of data (for example, in a database) can be distributed across multiple physical locations. A distributed database is distributed into separate partitions/fragments. Each partition/fragment of a distributed database may be replicated (for example, redundant fail-overs, RAID like).

Client 1Server

Physical Data

Client 1Server

Physical Data

Client 1Server

Physical Data

Client 1Server

Physical Data

Communication network

Fig. 8.10 Distributed database systems

129

Advantages of distributed databasesReflects organisational structure:• Database fragments are located in the departments they relate to.Local autonomy:• A department can control the data about them (as they are the ones familiar with it.)Improved availability:• A fault in one database system will only affect one fragment, instead of the entire database.Improved performance:• Data is located near the site of greatest demand and the database systems themselves are parallelised, allowing load on the databases to be balanced among servers. (A high load on one module of the database won’t affect other modules of the database in a distributed database.)Economics:• It costs less to create a network of smaller computers with the power of a single large computer.Modularity systems: • It can be modified, added and removed from the distributed database without affecting other modules (systems).

Disadvantages of distributed databasesComplexity:• Extra work must be done by the DBAs to ensure that the distributed nature of the system is transparent. It needs to be done to maintain multiple disparate systems, instead of one big one. Extra database design work must also be done to account for the disconnected nature of the database, for example, joins become prohibitively expensive when performed across multiple systems. Economics: • Increased complexity and a more extensive infrastructure means extra labour costs.Security:• Remote database fragments must be secured and they are not centralised so the remote sites must be secured as well. The infrastructure must also be secured (for example, by encrypting the network links between remote sites).Difficult to maintain integrity: • In a distributed database, enforcing integrity over a network may require too much of the network’s resources to be feasible.Inexperience:• Distributed databases are difficult to work with, and as a young field there is not much readily available experience on proper practice.Lack of standards: • There are no tools or methodologies yet to help users convert a centralised DBMS into a distributed DBMS. Database design more complex: • Besides normal difficulties, the design of a distributed database has to consider fragmentation of data, allocation of fragments to specific sites and data replication.

8.6 Database AdministratorA Database Administrator (DBA) is a person who is responsible for the environmental aspects of a database. In general, these include:

Recoverability: • Creating and testing BackupsIntegrity: • Verifying or helping to verify data integritySecurity: • Defining and/or implementing access controls to the dataAvailability: • Ensuring maximum uptimePerformance: • Ensuring maximum performance given budgetary constraintsDevelopment and testing support:• Helping programmers and engineers to efficiently utilise the database.

DutiesThe duties of a database administrator vary and depend on the job description, corporate and Information Technology (IT) policies and the technical features and capabilities of the DBMS being administered. They nearly always include disaster recovery (backups and testing of backups), performance analysis and tuning, data dictionary maintenance, and some database design.


130

Some of the roles of the DBA may include the following:Installation of new software:• It is primarily the job of the DBA to install new versions of DBMS software, application software, and other software related to DBMS administration. It is important that the DBA or other staff members test this new software before it is moved into a production environment.Configuration of hardware and software with the system administrator:• In many cases the system software can only be accessed by the system administrator. In this case, the DBA must work closely with the system administrator to perform software installations, and to configure hardware and software so that it functions optimally with the DBMS.Security administration: • One of the main duties of the DBA is to monitor and administer DBMS security. This involves adding and removing users, administering quotas, auditing, and checking for security problems.Data analysis: The DBA will frequently be called on to analyse the data stored in the database and to make • recommendations relating to performance and efficiency of that data storage. This might relate to the more effective use of indexes, enabling “Parallel Query” execution, or other DBMS specific features.Database design (preliminary):• The DBA is often involved at the preliminary database-design stages. Through the involvement of the DBA, many problems that might occur can be eliminated. The DBA knows the DBMS and system, can point out potential problems, and can help the development team with special performance considerations.Data modelling and optimisation:• By modelling the data, it is possible to optimise the system layout to take the most advantage of the I/O subsystem. Responsible for the administration of existing enterprise databases and the analysis, design, and creation of • new databases.

8.7 Transaction ProcessingIn computer science, transaction processing is information processing that is divided into individual, indivisible operations, called transactions. Each transaction must succeed or fail as a complete unit; it cannot remain in an intermediate state.DescriptionTransaction processing is designed to maintain a computer system (typically, but not limited to, a database or some modern file systems) in a known, consistent state, by ensuring that any operations carried out on the system that are interdependent are either all completed successfully or all cancelled successfully.

For example, consider a typical banking transaction that involves moving Rs.500 from a customer’s savings account to a customer’s checking account. This transaction is a single operation in the eyes of the bank, but it involves at least two separate operations in computer terms: debiting the savings account by Rs. 500, and crediting the checking account by Rs. 500. If the debit operation succeeds but the credit does not (or vice versa), the books of the bank will not balance at the end of the day. There must therefore be a way to ensure that either both operations succeed or both fail, so that there is never any inconsistency in the bank’s database as a whole. Transaction processing is designed to provide this.

Transaction processing allows multiple individual operations to be linked together automatically as a single, indivisible transaction. The transaction processing system ensures that either all operations in a transaction are completed without error, or none of them are. If some of the operations are completed but errors occur when the others are attempted, the transaction processing system “rolls back” all of the operations of the transaction (including the successful ones), thereby erasing all traces of the transaction and restoring the system to the consistent, known state that it was in before processing of the transaction began. If all operations of a transaction are completed successfully, the transaction is “committed” by the system, and all changes to the database are made permanent; the transaction cannot be rolled back once this is done.

131

Transaction processing guards against hardware and software errors that might leave a transaction partially completed, with the system left in an unknown, inconsistent state. If the computer system crashes in the middle of a transaction, the transaction processing system guarantees that all operations in any uncommitted (i.e., not completely processed) transactions are cancelled.

Transactions are processed in a strict chronological order. If transaction n+1 touches the same portion of the database as transaction n, transaction n+1 does not begin until transaction n is committed. Before any transaction is committed, all other transactions affecting the same part of the system must also be committed; there can be no “holes” in the sequence of preceding transactions.

MethodologyThe basic principles of all transaction-processing systems are the same. However, the terminology may vary from one transaction-processing system to another, and the terms used below are not necessarily universal (used in all kind of databases).

RollbackTransaction-processing systems ensure database integrity by recording intermediate states of the database as it is modified, then using these records to restore the database to a known state if a transaction cannot be committed. For example, copies of information on the database prior to its modification by a transaction are set aside by the system before the transaction can make any modifications (this is sometimes called a before image). If any part of the transaction fails before it is committed, these copies are used to restore the database to the state it was in before the transaction began (rollback).

Roll forwardIt is also possible to keep a separate journal of all modifications to a database (sometimes called after images); this is not required for rollback of failed transactions, but it is useful for updating the database in the event of a database failure, so some transaction-processing systems provide it. If the database fails entirely, it must be restored from the most recent back-up. The back-up will not reflect transactions committed since the back-up was made. However, once the database is restored, the journal of after images can be applied to the database (rollforward) to bring the database up to date. Any transactions in progress at the time of the failure can then be rolled back. The result is a database in a consistent, known state that includes the results of all transactions committed up to the moment of failure.

DeadlocksIn some cases, two transactions may, in the course of their processing, attempt to access the same portion of a database at the same time, in a way that prevents them from proceeding.

For example, transaction A may access portion X of the database, and transaction B may access portion Y of the database. If, at that point, transaction A then tries to access portion Y of the database while transaction B tries to access portion X, a deadlock occurs, and neither transaction can move forward. Transaction-processing systems are designed to detect these deadlocks when they occur. Typically both transactions will be cancelled and rolled back, and then they will be started again in a different order, automatically, so that the deadlock doesn’t occur again. Or sometimes, just one of the deadlocked transactions will be cancelled, rolled back, and automatically re-started after a short delay.

Deadlocks can also occur between three or more transactions. The more transactions involved, the more difficult they are to detect, to the point that transaction processing systems find there is a practical limit to the deadlocks they can detect.


132

8.7.1 ACID criteria (Atomicity, Consistency, Isolation, Durability)To ensure integrity of data, it is essential that the database system possesses following properties of the transaction:AtomicityAtomicity refers to the ability of the DBMS to guarantee that either all of the tasks of a transaction are performed or none of them are. The transfer of funds can be completed or it can fail for a multitude of reasons, but atomicity guarantees that one account won’t be debited if the other is not credited as well.

ConsistencyConsistency refers to the database being in a legal state when the transaction begins and when it ends. This means that a transaction cannot break the rules, or integrity constraints, of the database. If an integrity constraint states that all accounts must have a positive balance, then any transaction violating this rule will be aborted. Integrity constraints come in several forms, of which the most common are entity integrity (the absence of duplicate rows), referential integrity (consistency between related tables) and domain integrity (obedience to limits of the data domain - for instance, a warehouse cannot contain a negative number of widgets).

IsolationIsolation refers to the ability of the application to make operations in a transaction appear isolated from all other operations. This means that no operation outside the transaction can ever see the data in an intermediate state; a bank manager can see the transferred funds on one account or the other, but never on both even if he ran his query while the transfer was still being processed.

DurabilityDurability refers to the guarantee that once the user has been notified of success, the transaction will persist, and not be undone. This means it will survive system failure, and that the database system has checked the integrity constraints and won’t need to abort the transaction. Many databases implement durability by writing all transactions into a log that can be played back to recreate the system state right before the failure. A transaction can only be deemed committed after it is safely in the log.

8.7.2 Benefits of Transaction ProcessingTransaction processing has these benefits:

It allows sharing of computer resources among many users. • It shifts the time of job processing to when the computing resources are less busy• It avoids idling the computing resources without minute-by-minute human interaction and supervision• It is used on expensive classes of computers to help amortise the cost by keeping high rates of utilisation of • those expensive resources

8.7.3 ImplementationImplementing the ACID properties correctly is not simple. Processing a transaction often requires a number of small changes to be made, including updating indices that are used by the system to speed up searches. This sequence of operations is subject to failure for a number of reasons; for instance, the system may have no room left on its disk drives, or it may have used up its allocated CPU time.

ACID suggests that the database be able to perform all of these operations at once. In fact this is difficult to • arrange. There are two popular families of techniques: write ahead logging and shadow paging. In both cases, locks must be acquired on all information that is updated, and depending on the implementation, on all data that is being read. In write ahead logging, atomicity is guaranteed by ensuring that information about all changes is written to a log before it is written to the database. That allows the database to return to a consistent state in the event of a crash. In shadowing, updates are applied to a copy of the database, and the new copy is activated when the transaction commits. The copy refers to unchanged parts of the old version of the database, rather than being an entire duplicate.

133

Until recently almost all databases relied upon locking to provide ACID capabilities. This means that a lock • must always be acquired before processing data in a database, even on read operations. Maintaining a large number of locks, however, results in substantial overhead as well as hurting concurrency. If user A is running a transaction that has read a row of data that user B wants to modify, for example, user B must wait until user A’s transaction is finished. An alternative to locking is multi-version concurrency control, in which the database maintains separate copies of • any data that is modified. This allows users to read data without acquiring any locks. Going back to the example of user A and user B, when user A’s transaction gets to data that user B has modified, the database is able to retrieve the exact version of that data that existed when user A started their transaction. This ensures that user A gets a consistent view of the database even if other users are changing data that user A needs to read. A natural implementation of this idea results in a relaxation of the isolation property, namely snapshot isolation.It is difficult to guarantee ACID properties in a network environment. Network connections might fail, or two • users might want to use the same part of the database at the same time. Two-phase commit is typically applied in distributed transactions to ensure that each participant in the transaction agrees on whether the transaction should be committed or not. Care must be taken when running transactions in parallel. Two phase locking is typically applied to guarantee full isolation.Standard transaction-processing software, notably IBM’s Information Management System, was first developed • in the 1960s, and was often closely coupled to particular database management systems. Client-server computing implemented similar principles in the 1980s with mixed success. However, in more recent years, the distributed client-server model has become considerably more difficult to maintain. As the number of transactions grew in response to various online services (especially the Web), a single • distributed database was not a practical solution. In addition, most online systems consist of a whole suite of programs operating together, as opposed to a strict client-server model where the single server could handle the transaction processing.

Today, a number of transaction processing systems are available that work at the inter-program level and which scale to large systems, including mainframes. An important open industry standard is the X/Open Distributed Transaction Processing (DTP). However, proprietary transaction-processing environments such as IBM’s CICS are still very popular, although CICS has evolved to include open industry standards as well.


134

Summary The structure of the DBMS varies greatly from system to system; therefore, a generalised component structure • of DBMS is not possible to make.The DBMS is partitioned in several modules. Each module or component has been assigned a specific operation • to perform.Users issue a query using particular database language, for example, SQL commands.• The passed query is presented to the query optimiser, which uses information about how the data is stored to • produce and produce an execution plan for evaluating the query.The DBMS accepts the users SQL commands and analyses them.• The DBMS accepts the SQL commands generated from a variety of user interfaces, produces query evaluation • plans, executes these plans against the database and returns the answers. The query processor transforms users queries into series of low-level instructions directed to the run time database • manager. It is used to interpret the online users query and convert it into an efficient series of operations in a form capable of being sent to the run time data manager for execution.The run time data manager then places a call to the physical database to perform the request. It enforces • constraints to maintain the consistency and integrity of the data as well as its security. It also performs its backing and recovery.Using a DML compiler, the DML processor converts the DML statements embedded in an application program • into standard function in the host language.DBMS offers several important functions that guarantee integrity and consistency of data in the database. • The DBMS accepts the data definitions such as external schema, the conceptual schema, the internal schema • and the associated mappings in source form. It converts them to the appropriate object form using a DDL processor component.The DBMS provides a data dictionary and system catalog function in which descriptions of data items are stored • and which is accessible to users. All of the various schemas and mappings and all of the various security and integrity constraints in both source and object forms are stored in data dictionary.The DBMS provides special communication routines to allow the database to accept end-user request and • transmit the response back to the end user in the computer network environment.The DBMS provides mechanisms for backing up data periodically and recovering from different types of • failures.DBMS supports concurrent access and data sharing among multiple users it needs to manage concurrent access • to the database. DBMS ensures that the database is kept in the consistent state and the integrity of the data is preserved. It ensures that concurrent updating is handled correctly.

References Sumathi, S. & Esakkirajan, S., 2007. • Fundamentals of Relational Database Management Systems, Springer, pp. 1-29. Singh, S.K., 2009. • Database Systems: Concepts, Design and Applications, Pearson Education India. Ning, P., 2002. • Database management Systems. [Pdf] Available at: <http://printfu.org/read/csc-742-database-management-systems-3f20.html?f=1qeYpurpn6Wih-SUpOGumaqnh6_CuYWrnJeQtsri1cjW4MqMvNfT1c_K3dfX4pS57uDZ0dzph6_bn6Ksi-LoiLDgn52gsIfe3djk39m-xMvh0oen4rCWrorLkq3cqKqfr4_N4OPmn6OXydnlzN3qy-fmk8_i2ZPiy9j loM7S6ZW43Nre4tvYo8vY06mdoKG5pZ-UwJ-qxLjJ2dG_2NLZ0t7bzJrf2suWo-I> [Accessed 13 September 2011]. Varde, A., 2002. • Introduction to Databases. [Pdf] Available at: <http://printfu.org/read/introduction-to-databases-9699.html?f=1qeYpurpn6Wih-SUpOGumKqnh7Xd6tfjzNrT5tLd4obp3IWw0OrG1snY1eWLqeegp6eH4OOYoOeilqGsi9jp2ena1by_29HZiqDjrJqolsyXqNimo6mfltDZ5OKjnaPd2s-Tz-Kk3OTRk9XW3p3yx-XO19rQpam2tbjZ4N3g45Tl0cuOqvM>[Accessed 13 Spetember 2011].

135

Srinath, S., 2008. • ER Model to Relational Mapping. [Video online] Available at: <http://www.youtube.com/watch?v=WIkw87aLAMc> [Accessed 9 September]. Srinath, S., 2008. • Lecture - 4 Relational Model. [Video online] Available at: <http://www.youtube.com/watch?v=nc1yivH1Yac> [Accessed 9 September].

Recommended ReadingMajumdar, 2001. • Int To Dbms , Tata McGraw-Hill Education.North, K., 1995. Windows multi-DBMS programming: using C++, Visual Basic, ODBC, OLE2, and tools for • DBMS projects, Wiley.Connolly, 2008. • Database Systems: A Practical Approach To Design, Implementation And Management, 4/E, Pearson Education India.


136

Self AssessmentDBMS accepts the ____________commands and analyses them.1.

SQLa. user b. computerc. codesd.

Which of the following statements is true??2. The DBMS executes plans against the central database and returns the answers to all computers.a. The DBMS executes plans against the physical database and returns the answers to the users.b. The DBMS executes plans against the main database and returns the answers to the managers.c. The DBMS executes plans against the entire database and returns the answers to the same database.d.

The __________ processor transforms users’ queries into series of low-level instructions directed to the run 3. time database manager.

SQLa. fast b. dynamic c. queryd.

The run time data _________places a call to the physical database to perform the request.4. managera. organiserb. administratorc. processor d.

Which of the following is the module check that the user has necessary authorisation to carry out the required 5. operation?

Command processor a. Integrity checkerb. Query Optimiserc. Authorisation controld.

__________processes the queries passed by authorisation control module.6. Command processor a. Query Optimiserb. Authorisation controlc. Integrity checkerd.

__________ checks for necessary integrity constraints for all the requested operations that change the 7. database.

Command processor a. Query Optimiserb. Authorisation controlc. Integrity checkerd.

137

_________ determines an optimal strategy for the query execution. It uses information on how the data is stored 8. to produce the efficient execution plan for evaluating the query.

Command processor a. Query Optimiserb. Authorisation controlc. Integrity checkerd.

___________transaction manager performs the required processing of operation it receives from transactions.9. Query optimisera. Transaction managerb. Integrity checkerc. Data mangerd.

_______________ is responsible for actual handling of data in the database.10. Query optimisera. Transaction managerb. Integrity checkerc. Data mangerd.


138

Case Study I

Database Management Systems: A Case Study of Faculty of Open Education

We live in the information and the microelectronic age, where technological advancements become a major determinant of our everyday life. Such progress in technology cannot perhaps be finished or sustained without simultaneous advancement in management systems.

The impact of computer technology on organisations and society is increasing as new technologies evolve and existing technologies expand. Because of the influence of the improvement in the computer technology, people can also build their own computerised systems with easy-to-use construction tools.

Management is a process by which certain goals are achieved through the use of resources like materials, people, • money, time. These resources are considered to be inputs and the attainment of the goals is viewed as the output of the process. Database systems continue to be a key aspect of Computer Science & Engineering today. Representing knowledge within a computer is one of the central challenges of the field. Database research has • focused primarily on this fundamental issue. This paper presents a database management system developed for AOF (Faculty of Open Education) course books. Its rationale is based on the development of a database application that share data and operations through a database. It supports organisation’s manipulation and retrieval of data. In order to organise large amounts of data (book’s names, ISBN numbers, number printed; authors’ names, and addresses, etc.) similar user interfaces are developed for different types of users. In addition, they can create special reports. It also encourages users who have no previous programming • experience. The detail of the study is presented in the third part of the paper.

Management Information Systems Management Information Systems (MIS) consists of a collection of interrelated data and information structure that are organised in such a way that it corresponds to the needs and structure of an organisation and can be used by more than one person for more than one application.

A (MIS) is a formal, computer-based system, intended to retrieve, extract and integrate data from various sources in order to provide timely information for routine, structured and anticipated types of decisions. In addition, it has been successful in acquiring and storing large quantities of detailed data concerning transaction processing. MIS has the following characteristics:

It supports record keeping and data processing functions. • Same databases can be shared for all functions of the organisation • Every manager, from the different levels of the organisation can reach easily to the data. • All data and information can be used only by authorised personnel. Thus, system’s security is provided.•

Organisations require MIS because of some specific causes. These causes are; Complexity of data transfer and communication problems because of this complexity. • Work and force repetitions, creation of same data, and storing them in many different places. • Applying many kinds of operations and information flows when obtaining same data. • Impossibility of working with data. It’s hard to get useful and necessary information because their form and • positions are not proper.Insufficient data source. • Limited information support. •

139

Database approach Misplacing information is a problem. Having the right information is not enough; we also have it logically and physically organised so that you can easily access it and make the sense of it.

Having the right information and being able to get it quickly will increase productivity. Once getting the • information; it must be stored so that people can get it easily and make changes as needed. There are two views of information, physical and logical. The physical view deals with how information is stored on storage devices, while the logical view deals with • how you arrange information while you are working with it. Everyone has his or her own files of information. And the software that each person uses to maintain the • information in the file is called a file management system. There are some basic problems with using files and file management systems. First, the same information may be stored in many different places. This problem is known as data redundancy. For example, a course book’s chapter names appear in two different places. Second, because the same information exists in several places, there is the issue of data integrity. Data integrity • deals with the correctness of the information. Although the author’s title is correct in the chapters file, it isn’t correct in the addresses file; this is the loss of data integrity. Because of these problems, all the organisation’ s information stored in one place and a software is proved that • anyone can use to access any of the information. These concepts are called database and database management system (DBMS). A database is a group of related files, and a DBMS is the software designed to create, store, and manipulate a database. One facet of a database management system is processing inserts, updates, and deletes. This all has to do with • putting information into the database. Changes in data representation will often be needed as a result of changes in query, update, and report traffic and natural growth in the types of stored information. A relational database is a big spreadsheet that several people can update simultaneously.The relationships between the many individual records stored in a database can be expressed by several logical • structures. DBMS are designed to use these structures to execute their functions. One of these structures is relational. Relational database allows the user to think in the form of two-dimensional tables, which is the way many people see data reports. This structure is most popular for DSS databases. The database approach offers a number of important and practical advantages to an organisation. Reducing • redundancy improves the consistency of data while reducing the waste in storage space.Sharing data often permits new data processing applications to be developed without having to create new data • files. In general, less redundancy and greater sharing lead to less confusion between organisational units and less time spent resolving errors and inconsistencies reports. The database approach also permits centralised control over data standards, security restrictions, and integrity • controls. This facilitates the natural evolution and change of information systems and organisations. Databases are very commonly used in everyday life. The relational model of databases provides a very simple • way of looking at data structured into tables

(Source: Zehra, K., 2004. Database Management Systems: A Case Study of Faculty of Open Education [Online] Available at: < http://www.tojet.net/articles/313.pdf> [Accessed 14 September 2011])

Questions: Explain the impact of computer technology on our lifestyle.1. Answer:With the advent of computer technology, every aspect of human life has been transformed. Today, a newer faster approach to any issue has become the norm and our life has become very easy because of technology. One must notice that progress in technology cannot perhaps be finished or sustained without simultaneous advancement in management systems. The impact of computer technology on organisations and society is increasing as new technologies evolve and existing technologies expand. Because of the influence of the improvement in the computer technology, people can also build their own computerised systems with easy-to-use construction tools.


140

Management is a process by which certain goals are achieved through the use of resources like materials, people, money, time. These resources are considered to be inputs and the attainment of the goals is viewed as the output of the process. Database systems continue to be a key aspect of Computer Science & Engineering today.

What is MIS?2. Answer:Management information systems (MIS) consists of a collection of interrelated data and information structure that organised in such a way that it corresponds to the needs and structure of an organisation and can be used by more than one person for more than one application.A (MIS) is a formal, computer-based system, intended to retrieve, extract, and integrate data from various sources in order to provide timely information for routine, structured, and anticipated types of decisions.

What are the characteristic of MIS?3. Answer:Following are the characteristic of MIS:

It supports record keeping and data processing functions. �Same databases can be shared for all functions of the organisation. �Every manager from different levels of the organisation can access the data easily. �All data and information can be used only by authorised personnel. Thus, system’s security is provided. �

Why is MIS required?4. Answer:Organisations require MIS because of some specific causes. These causes are;

Complexity of data transfer and communication problems because of this complexity. �Work and force repetitions, creation of same data, and storing them in many different places. �Applying many kinds of operations and information flows when obtaining same data. �Impossibility of working with data. It’s hard to get useful and necessary information because their form �and positions are not proper.Insufficient data source. �Limited information support. �

Explain the Database Approach mentioned in this case study. 5. Answer:Misplacing information is a problem. Having the right information is not enough; we also have it logically and physically organised so that you can easily access it and make the sense of it. Having the right information and being able to get it quickly will increase productivity. Once getting the information; it must be stored so that people can get it easily and make changes as needed. There are two views of information, physical and logical.

The physical view deals with how information is stored on storage devices, while the logical view deals �with how you arrange information while you are working with it. Everyone has his or her own files of information. And the software that each person uses to maintain the information in the file is called a file management system. There are some basic problems with using files and file management systems. First, the same information may be stored in many different places. This problem is known as data redundancy. For example, a course book’s chapter names appear in two different places. Second, because the same information exists in several places, there is the issue of data integrity. Data �integrity deals with the correctness of the information. Although the author’s title is correct in the chapters file, it isn’t correct in the addresses file; this is the loss of data integrity.

141

Because of these problems, all the organisation’ s information stored in one place and a software is proved that anyone can use to access any of the information. These concepts are called database and database management system (DBMS).

One facet of a database management system is processing inserts, updates, and deletes. This all has to do with putting information into the database. Changes in data representation will often be needed as a result of changes in query, update, and report traffic and natural growth in the types of stored information. A relational database is a big spreadsheet that several people can update simultaneously.

Relational database, one of the structures of DBMS, allows the user to think in the form of two-dimensional tables, which is the way many people see data reports. This structure is most popular for DSS databases. The database approach offers a number of important and practical advantages to an organisation. Reducing redundancy improves the consistency of data while reducing the waste in storage space.

Sharing data often permits new data processing applications to be developed without having to create new data files. In general, less redundancy and greater sharing lead to less confusion between organisational units and less time spent resolving errors and inconsistencies reports.

The database approach also permits centralised control over data standards, security restrictions, and integrity controls. This facilitates the natural evolution and change of information systems and organisations. Databases are very commonly used in everyday life. The relational model of databases provides a very simple way of looking at data structured into tables.


142

Case Study II

DBMS in several departments

Why not use an off-the-shelf solution?If you have a standard requirement and are prepared to modify the way that you work then you can probably use a standard off-the-shelf program. However, if you have unique database requirements or don’t want to change the way that you work then you will need one of the bespoke solutions. Here are the some of the examples where DBMS provides the solutions.

2.1 Activity DatabaseThe building managers of an organisation with a large number of sites need to be more in touch with the work being done on their buildings. In addition, the different FM departments often arranged for repairs and maintenance to be done without being aware that another facilities section had arranged for conflicting work to be done on the same building. This had serious Health and Safety implications and control issues whenever there was a problem with contractors or untidy workingThe solution

Prior to the installation of the database, the facilities managers created a Safety sign with contact information • and details of the work to be done and issued it to the contractors. This process was done manually within a word processing program.The activity database application now produces the Safety signs. The data entry consists of a single form requiring • the same information that was entered onto the safety sign. The process requires no additional administration work and, in addition, the user is able to see other work being planned by other facilities managers on the same day.Any authorised individual can now search and find information under various headings about the work to be • done on single buildings or to get an overall picture of specific types of work being done within the whole organisation.

2.2 Work DoneA repairs and maintenance company does a variety of work for different clients. The work done by the operative is recorded on Job sheets. Until the development of the Work done database, invoicing information was taken directly from the Job sheets. This meant that there was no accessible history about the work done for different clients. In addition, when a client wanted a report about the work done on their buildings this had to be manually extracted from the Job sheets and word processed.The solution

Details from the Job sheets are entered into a database, which produces monthly reports of the work done. This • is supplied to the clients who regard these reports as a value added aspect of using the company. Clients can also request special reports covering time periods or types of work carried out on their buildings. • They cannot get this degree of information from competitors and the database has substantially increased the company’s leverage.

2.3 Building InformationA facilities management department constantly needed to check the original paper based building specifications to find paint colours and the details of fixtures used within the buildings under their control. There was often no recorded information that gave suppliers address details.

143

The solution Whenever an area needs painting or replacement fixtures are needed then the Building Information database is • searched. The search can be done on a single building or across all buildings and the database has developed into a valuable resource. It is possible to search for door furniture for example and then drill down to door handles and find all the different • types, together with their suppliers and the price at the last supply date.Paint colours are also stored and are searched in the same way. This application now saves valuable time in • finding replacement items and in addition it is helping to rationalise supply and save costs.

2.4 Conference ManagerThe organisation runs several international seminars every year and the requirement was to enable better control of the whole process, from mailing through to invoicing.The solution

Mailing lists of potential attendees are held and labels produced when a conference is being planned. The • mailing list is built by a combination of manual entry and direct import from external sources and also contains potential Guest speakers.When a booking is made the source of the lead is recorded and response statistics are generated.• In addition to attending the seminar, delegates can take part in special trips and dinners and all of these additional • requirements are stored and included in the invoice generated. The application now produces the customised letters that go out with the documentation, prints the handouts, • badges and various delegate reports and creates the invoices.

2.5 Subscription ManagerThe client needed a complete solution to marketing and distributing a monthly journal. This included mailing potential subscribers, tracking when subscriptions are due, issuing invoices and sending out reminders.The Solution

The database application includes a module which generates direct mailing letters and supplies statistics on the • source of leads. The mailing list is generated by importing data from other sources and mailings can be made based upon various criteria.The subscription module produces reminders and invoices at the appropriate time and keeps long term information • about subscribers.

2.6 Analysis of Product Test DataA large amount of data, generated from testing the performance of competitors’ products, was stored in spreadsheets. The information within this data was only accessible to the laboratory technicians who had tested the products. There was no formal method of comparison and there were inconsistencies in recording the results of testsThe Solution

The Product Analysis Database system now produces a range of reports and charts which present product • comparisons in an easy to understand way.The existing data was imported and immediately became useful information. The simple entry form has enabled • quicker input and helped to rationalise the new test data.The system is designed to be used without any user training and has been made available to sales personnel • who are able to show comprehensive comparisons between products.

2.7 Project AdministratorThe consulting and projects department required a software solution that could be used to increase their efficiency in dealing with the administration of projects. The application needed to handle all aspects of project management, including setting milestones, comparing forecast costs with actual and producing regular update reports.


144

The solutionThe application was designed from the onset to allow organic growth . Initially the central module was developed • and enabled the project managers to control milestones and produce update reports about their projects.The cost comparison module was then developed and allowed the entry of forecast monthly costs. The actual • costs are included via an import routine that collects them from the organisation’s accounting system.Reporting options are extensive, including exports to Excel and the creation of Word documents which can be • edited and e-mailed as required. The user can also choose data items from a pick list and generate an export file that can be used by other systems.The application also includes a contact module within which people in a global address list are associated with • a particular project.

2.8 Product Ordering and Supply SystemA wholesaler needed to computerise their sales, ordering and distribution system. On a daily basis they received large numbers of orders and each customer required quantities of various products, none of which are stocked. These orders must be consolidated and placed with the appropriate supplier. Once received the products are sent to the customer and an invoice is raised. There are various invoice layouts, dictated by the customer requirements.The solution

The application enables the input of sales orders, establishing which manufacturer the items need to be ordered • from at entry time. The system then consolidates the individual orders and a purchase order for the manufacturer is produced when the minimum order quantity has been reached.As goods are received from the manufacturer they are checked into the database and the system generates a • despatch note which is used to make up the customer order. The system then produces a customised invoice based upon the cost price and the appropriate margin for that customer.

2.9 Temporary Staff BookingThis application which books occasional staff and then records the time to be charged out for those personnel was an existing Open Access (OA) application (OA is a DOS product). This application needed to be converted to a windows database and MS Access was chosen. The users wanted to transfer seamlessly to a windows database and have exactly the same functionality. All data had to be converted and be available in exactly the same format.The solution

We examined the OA application and developed the functional specification.• An efficient new system was then developed within MS Access which could be controlled with the same function • keys or used with a mouse for new users.Import routines were also supplied that enabled the existing data to be transferred without loss.•

(Source: dbms creative database solutions, Why not use an off-the-shelf solution? [Online] Available at: <http://www.dbms-solutions.co.uk/CaseStudies/casdefault.asp> [Accessed 14 September 2011].)

Questions:What do you understand by Activity Database?1. How do you analyse Work Done database?2. Analyse Building Information and explain the solution provided for it.3. Explain how a Subscription Manager will utilise DBMS.4.

145

Case Study III

Management Information System in Restaurant

A waiter takes an order at a table, and then enters it online via one of the six terminals located in the restaurant dining room. The order is routed to a printer in the appropriate preparation area: the cold item printer if it is a salad, the hot-item printer if it is a hot sandwich or the bar printer if it is a drink.

A customer’s meal check-listing (bill) the items ordered and the respective prices are automatically generated. This ordering system eliminates the old three-carbon-copy guest check system as well as any problems caused by a waiter’s handwriting.

When the kitchen runs out of a food item, the cooks send out an ‘out of stock’ message, which will be displayed on the dining room terminals when waiters try to order that item. This gives the waiters faster feedback, enabling them to give better service to the customers.

Other system features aid management in the planning and control of their restaurant business. The system provides up-to-the-minute information on the food items ordered and breaks out percentages showing sales of each item versus total sales. This helps management plan menus according to customers’ tastes.

The system also compares the weekly sales totals versus food costs, allowing planning for tighter cost controls. In addition, whenever an order is voided, the reasons for the void are keyed in. This may help later in management decisions, especially if the voids consistently related to food or service.

Acceptance of the system by the users is exceptionally high since the waiters and waitresses were involved in the selection and design process. All potential users were asked to give their impressions and ideas about the various systems available before one was chosen.

(Source: Himadri, B., 2010. MIS Case Studies. [pdf] Available at: <http://himadri.cmsdu.org/documents/MIS_Case_Studies.pdf> [Accessed 14 September 2011].)

Questions: In the light of this IT system, describe the decisions to be made in the area of strategic planning, managerial 1. control and operational control. What information would you require to make such decisions? What would make this IT system a more complete MIS, rather than just doing transaction process? 2. What would be the probable effects on the customers and the management if this IT system becomes more 3. formal?


146

Bibliography

ReferencesAnuramn, 2010. • Threats to Database Security. [Online] Available at: <http://www.brighthub.com/computing/smb-security/articles/61554.aspx>. [Accessed 13 September 2011].Barrier Reef Institute of TAFE, 2001, • Introduction to Normalisation. [Online] Available at: <http://tle.tafevc.com.au/toolbox/file/f567850b-9966-154c-cd52-6025f598004f/1/306_02.zip/content/normalisation/normalisation_intro.htm> [Accessed 7 July 2011].Chin, S., and Orjan, 1999. • Relational database management system (RDBMS). [Online] Available at: <Timanhttp://searchsqlserver.techtarget.com/definition/relational-database-management-system> [Accessed 5 July 2011].Codd’s Rules• . [Online] Available at < http://www.wildewood.co.uk/comp/more/codds_rules.html> [Accessed 5 July 2011].Dobre, A., Schneuwly, D & Bleisch, S., • Structured Query Language SQL. [pdf] Available at: <http://www.gitta.info/RelQueryLang/en/text/RelQueryLang.pdf> [Accessed 9 September 2011]. Gordon, R., 1980. • SQL - Subqueries and Schema. [Online] Available at: <http://db.grussell.org/slides/sql4.pdf> [Accessed 9 September 2011].Groff, 2003. • Sql: The Complete Reference 2, Tata McGraw-Hill Education, pp. 1- 150. Gary, B., Shelly & Rosenblatt, H. J., 2011. • Systems Analysis and Design, Cengage Learning, pp. 392-401. Gillenson, M. L., 2008. • Fundamentals Of Database Management Systems, Wiley-India, pp. 32-200.Haithcoat, T., Veenstra, P., • Relational Database Management Systems, Database Design, and GIS. [pdf] Available at: <http://msdis.missouri.edu/presentations/gis_advanced/pdf/Relational.pdf> [Accessed 7 July 2011].Hoberman, S., 2007. • Data modelling made simple: a practical guide for business & IT professionals, Technics Publications.Hoffer, 2009. Modern Database Management Systems, 9/E, Pearson Education India, pp. 410-563. • Janakiram, D., 2008. • Introduction to Database Management System. [Video online] Available at: <http://www.youtube.com/watch?v=EUzsy3W4I0g> [Accessed 9 September 2011]. Janakiram, D., 2008. • Transaction Processing and Database Manager. [Video online] Available at: <http://www.youtube.com/watch?v=5ammL5KU4mo> [Accessed 9 September 2011]. Janakiram, D., 2008. • Concurrency Control Part – 3. [Video online] Available at: <http://www.youtube.com/watch?v=-EJa_I_4-vg> [Accessed 9 September 2011]. Janakiram, D., 2008. • Distributed Transaction Models. [Video Online] Available at: <http://www.youtube.com/watch?v=hNOEL3SM9No&feature=related> [Accessed 9 September 2011]. Kedar, S., 2009. • GUI and Database Management, Technical Publications, pp.8-97. Knol a unit of knowledge, • DATABASE DESIGN STEPS / HOW TO DEVELOP A DATABASE: Data Models & the Database Development Life Cycle. [Online] (Updated 15 August 2010) Available at: < http://knol.google.com/k/database-design-steps-how-to-develop-a-database#> [Accessed 12 September 2011].Mullins, C. S., 2002. • Database Trends and Applications. [Online] Available at: <http://www.craigsmullins.com/dbta_015.htm> [Accessed 9 September 2011]. Modell, M., 1992. • Data Analysis, Data Modelling and Classification. [Online] Available at: < http://www.martymodell.com/dadmc/index.html>. [Accessed 11September 2011].Mullins, C. S., 2002. • Database Trends and Applications. [Online] Available at: <http://www.craigsmullins.com/dbta_015.htm> [Accessed 9 September 2011]. Ray, 2010. • Distributed Database Systems, Pearson, pp.1-15. SQA• , 2007. Fundamentals of Database Design: The Process of Normalisation. [Online] Available at: http://www.sqa.org.uk/elearning/MDBS01CD/page_20.htm [Accessed 6 July 2010].Sosinsky, B., 2009. • Networking Bible, John Wiley and Sons, pp. 11-56.

147

Srinath, S., 2008. Conceptual Designs. [Video Online] Available at: <http://www.youtube.com/• watch?v=EuSBAOpXjU0> [Accessed 9 September].Srinath, S., 2008. • Introduction to Data Warehousing and OLAP. [Video online] Available at: <http://www.youtube.com/watch?v=G4NYQox4n2g > [Accessed 9 September]. Srinath, S., 2008. • Relational Model. [Video online] Available at: <http://www.youtube.com/watch?v=gGGHjYbQMvw> [Accessed 9 September]. Srinath, S., 2008. Data Mining and Knowledge Discovery. [Video online] Available at: <http://www.youtube.• com/watch?v=m5c27rQtD2E> [Accessed 9 September]. Srinath, S., 2008. • Structured Query Language. [Video online] Available at: <http://www.youtube.com/watch?v=64szTfLNu3o> [Accessed 9 September]. Srinath, S., 2008. • ER Model to Relational Mapping. [Video online] Available at: <http://www.youtube.com/watch?v=WIkw87aLAMc> [Accessed 9 September]. Srinath, S., 2008. • Lecture - 4 Relational Model. [Video online] Available at: <http://www.youtube.com/watch?v=nc1yivH1Yac> [Accessed 9 September]. Srinath, S., 2008. • Storage Structures. [Video online] Available at: <http://www.youtube.com/watch?v=9E4M6MCD4aI> [Accessed 9 September]. Srinath, S., 2008. • Query Processing and Optimization II. [Video online] Available at: <http://www.youtube.com/watch?v=FqUPoZzU834> [Accessed 9 September].Sumathi, S. & Esakkirajan, S., 2007. • Fundamentals of Relational Database Management Systems, Springer, pp. 740-720. Sumathi, S. & Esakkirajan, S., 2007. • Fundamentals of Relational Database Management Systems, Springer, pp. 1-29. Singh, S.K., 2009. • Database Systems: Concepts, Design and Applications, Pearson Education India, pp. 200-456. Silverston, L., 2001• . The Data Model Resource Book: a library of universal data models by industry types, vol. 2, Wiley.Singh, S. K., • Database Systems: Concepts, Design and Applications, Pearson Education. pp.237-300. Singh, S.K., 2009. • Database Systems: Concepts, Design and Applications, Pearson Education India, pp. 469-474. Sheldon, R. & Forrest, H., 2003. • SQL: a beginner’s guide, McGraw-Hill Professional, pp. 1-250. Shulman, A. • Top Ten Database Security Threats [pdf] Available at: <http://www.schell.com/Top_Ten_Database_Threats.pdf> [Accessed 13 September 2011].


148

Recommended ReadingAtluri, V & Hale, J., 2000. • Research advances in database and information systems security: IFIP TC11 WG11.3 Thirteenth Working Conference on Database, Springer.Connolly, T., 2008. • Database Systems: A Practical Approach to Design, Implementation and Management, 4th ed., Pearson Education India.Coronel, C., Morris, S., & Rob, P., 2009. • Database systems: design, implementation and management, Cengage Learning.Donahoo, J, D. & Speegle, G. D., 2005. • SQL: practical guide for developers, Academic Press.Haan, L.D., Daneil, F. & Morton, K.,2009. • Beginning Oracle SQL, Apress.Hernandez, M. J., 2003. • Database design for mere mortals: a hands-on guide to relational database design, Addison-Wesley.Harrington, J. L., 2010. • SQL Clearly Explained, Elsevier.Itl Education Solutions Limited, 2010. Introduction to Database Systems,• Pearson Education India.Kedar, S., 2009. • Database Management System, Pune; Technical Publications..Mcnurlin, 2003. • Information Systems Management in Practice, 6th ed., Pearson Education India.O’Neil, P. & O’Neil, E., 2001. • Database--principles, programming, and performance, 2nd ed., Morgan Kaufmann.Perry, J.T. & Newmark, R., 2011. • Building Accounting Systems Using Access 2010, Cengage Learning.Ritchie, C., .• Database Principles and Design, Cengage Learning EMEA.Schulman, J., 2006. • Managing your patients’ data in the neonatal and pediatric ICU: an introduction to databases and statistical analysis, Wiley-Blackwell.Gertz, M. & Jajodia, S., 2008. • Handbook of database security: applications and trends, Springer.Group, I., .• Introduction to Database Management Systems, Tata McGraw-Hill Education.McNicholas, M., 2007. • Maritime security: an introduction, Butterworth-Heinemann.Majumdar, 2001. • Int To Dbms , Tata McGraw-Hill Education.North, K• ., 1995. Windows multi-DBMS programming: using C++, Visual Basic, ODBC, OLE2 and tools for DBMS projects, Wiley.Oppel., 2005. • Sql Demystified, Tata McGraw-Hill Education.Sumathi, S. & Esakkirajan, S., • .Fundamentals of Relational Database Management Systems, Springer.Singh, K. S., 2009. • Database Systems: Concepts, Design and Applications, 3rd ed., Pearson Education India.Srinath, S., 2008. • Functional Dependencies and Normal Form. [Video Online] Available at: <http://www.youtube.com/watch?v=YD8dhOmuVnY> [Accessed 9 September]. Wang, S. & Wang, H., 2011. • Database Design and Implementation, Universal-Publishers.

149

Self Assessment Answers

Chapter Ia1. d2. c3. a4. c5. b6. c7. a8. b9. a10.

Chapter IIb1. c2. d3. a4. b5. c6. a7. c8. a9. d10.

Chapter IIIa1. b2. c3. b4. a5. b6. a7. c8. a9. a10.

Chapter IVa1. c2. a3. d4. b5. d6. d7. b8. a9. c10.


150

Chapter Vd1. b2. b3. c4. a5. b6. a7. c8. a9. a10.

Chapter VIa1. c2. a3. d4. c5. a6. a7. b8. a9. c10.

Chapter VIIa1. b2. b3. b4. a5. d6. a7. b8. c9. a10.

Chapter VIIIa1. b2. d3. a4. d5. a6. a7. d8. b9. b10.

database management system - jaipur national universityjnujprdistance.com/assets/lms/lms jnu/mca/sem...

Documents