UNIT 6 DATABASE MANAGEMENT

SYSTEMS
Structure
6.0 Objectives
6.1 Introduction
6.2 File Oriented Approach
6.3 Database Approach
6.4 Database and DBMS
6.4.1 Database
6.4.2 Why Use a Database?
6.4.3 Database Management System (DBMS)
6.4.4 Characteristics of Data in a Database

6.5 Levels of Abstraction in a DBMS

6.5.1 External View
6.5.2 Conceptual View
6.5.3 Internal View
6.5.4 Data Independence
6.5.5 Database Languages and Interfaces

6.6 Database Environment

6.7 Various DBMS Architectures
6.7.1 Flat-file Database
6.7.2 Hierarchical Database Management System
6.7.3 Network Database Management System
6.7.4 Relational Database Management System

6.7.5 Object Oriented Database Management System

6.8 Types of DBMS Architectures

6.8.1 Centralised DBMS Architecture
6.8.2 Client / Server Architecture

6.9 Database Security

6.10 Popular DBMS Packages
6.11 Database Project Environment
6.11.1 Analysis
6.11.2 Design
6.11.3 Development
6.11.4 Implementation
6.11.5 Maintenance
6.12 Database Administrator
6.13 Summary
6.14 Answers to Self Check Exercises
6.15 Keywords
6.16 References and Further Reading 47
Middleware Technologies
6.0 OBJECTIVES
After going through this Unit, you should be able to:
 appreciate the limitations of the traditional approach to application system
development;
 give reasons why the database approach is now being increasingly adopted;
 discuss different views of data;
 list the components of a database management system;
 enumerate the features and capabilities of a database management system; and
 discuss the security threats for the DBMS and their counter measures.

6.1 INTRODUCTION
We all live in an age where the world is full of data and information. Everyone is aware
of Internet, which has become a huge source of information and also growing everyday.
The amount of data is actually very large to access and maintain.
For example, if we go to the bank to deposit or withdraw funds, if we make booking in
a hotel or railways reservation, even purchasing items from a supermarket or Mall, all
these activities involves an automatic update of the database which keeps the inventory
of the store room or showroom items.
Relational database systems have become increasingly popular since the late 1970’s.
They offer a powerful method for storing data in an application-independent manner.
This means that for many enterprises the database is at the core of the IT strategy.
Developments can progress around a relatively stable database structure which is secure,
reliable, efficient, and transparent.
In early systems, each suite of application programs had its own independent master
file. The duplication of data over master files could lead to inconsistent data. Efforts to
use a common master file for a number of application programs resulted in problems of
integrity and security. The production of new application programs could require
amendments to existing application programs, resulting in unproductive maintenance.
Data structuring techniques, developed to exploit random access storage devices,
increased the complexity of the insert, delete and update operations on data. As a first
step towards a DBMS, packages of subroutines were introduced to reduce programmer
effort in maintaining these data structures. However, the use of these packages still
requires knowledge of the physical organisation of the data. In the traditional database
applications, most of the information was stored and accessed in either textual or numeric
form. But nowadays, video clips, pictures files, weather data, satellite images and sound
image files are stored in separate and specialised databases such as multimedia databases.
In this unit we will introduce basic concepts of file oriented approach, drawbacks with
file oriented approach, database approach, use of DBMS, levels of abstraction of
DBMS, types of DBMS and security features.

6.2 FILE ORIENTED APPROACH

A file based system is a collection of application programs that perform services for the
48 users wishing to access information. For each application a separate master file and its
own set of personal files were present. Each program within a file based system defines Database Management
and manages its own data. Because of this, there are certain limits as to how that data Systems
can be used or transported. File based systems were developed as better alternatives
to paper based filing systems. By having files stored on computers, the data could be
accessed more efficiently. It was common practice for larger companies to have each
of its departments looking after its own data. The problems that arise with this type of
file based system are listed below:
 Data separation and isolation
 Limited Data Sharing – No centralised control of data.
 Program Data dependence – All programs maintain metadata for each file they
use.
 Data Redundancy (Duplication of data) – Different systems / programs have
separate copies of the same data. The same piece of information may be stored in
two or more files. For example, the particulars of an individual who may be a
customer or an employee may be stored in two or more files. Some of this
information may be changing, such as the address, the pay drawn, etc. It is therefore,
quite possible that while the address in the master file for one application has been
updated the address in the master file for another application may have not been.
It may not also be easy for the computer-based system to even find out as to in
how many files the repeating items such as the address is occurring. The solution
therefore, is to avoid this data redundancy and the keeping of multiple copies of
the same information and replace it by a system where the address is stored at just
one place physically, and is accessible by all applications from this itself.
The disadvantages of file based systems are:
 Incompatible data (different file formats).
 Lack of flexibility in organising and querying the data.
 Increased number of different application programs
 Lengthy Development times – Programmers must design their own file formats.
 Excessive Program Maintenance.
 Each Application programmer must maintain their own data.
 Each Application program needs to include code for the metadata of each file.
 Each application program must have its own processing routines for reading,
inserting, updating and deleting data
 Lack of coordination and central control.
 Problems with Data Redundancy.
 Waste of space to have duplicate data.
 Causes more maintenance headaches.
 When data changes in one file, could cause inconsistencies.
 Compromises data integrity.
These disadvantages of file based system motivate a database approach, which will be
taken in the next section for discussion.
49
Middleware Technologies
6.3 DATABASE APRROACH
Having pointed out some difficulties that arise in a straight forward file-oriented approach
towards information system development, it is useful to see how the problems stated in
the earlier section can be mitigated by using the database approach.
Organisations involved in manufacturing and business or public utility services such as
hospitals, hotels, government departments, etc. would be in a position to rely into the
database approach. Some of the advantages of database approach are:
 Central Repository of shared data
 Data is managed by a controlling agent
 Stored in a standardised, convenient form
 Consistency of data
 Integrity of data
 Security of data (Unauthorised access is restricted)
 Data independence
 Allows for more analysis of the same amount of data
 Improves data access and system performance
 Potentially increases productivity
 Increases concurrency
 Provides data backups and recovery.
Some potential disadvantages of database systems are the cost of implementing them,
the amount of effort needed to transfer data into the database from a current system,
and also the impact on the whole company if the database fails (even if only for a
relatively short period). It requires DBMS software for implementation.

6.4 DATABASE AND DBMS

You have seen in the previous section the purpose for which a DBMS approach is
preferred over the conventional file based approach. Since the DBMS of an organisation
will in some sense reflect the nature of activities in the organisation, some familiarity with
the basic concepts, principles and terms used in this field are important. This section
concentrates on those components which are relevant in the context of a database
approach.

6.4.1 Database
A database is a logically coherent collection of data with some inherent meaning,
representing some aspect of real world and which is designed, built and populated with
data for a specific purpose.

6.4.2 Why Use a Database?

A database gives users access to data, which they can view, enter, or update, within the
limits of the access rights granted to them. Databases become all the more useful as the
amount of data stored continues to grow.
50
A database can be local, meaning that it can be used on one machine by one user only, Database Management
or it can be distributed, meaning that the information is stored on remote machines and Systems
can be accessed over a network. The primary advantage of using databases is that they
can be accessed by multiple users at once.

6.4.3 Database Management System (DBMS)

It is a collection of programs that enables user to create, store, modify and extract
information from a database. In other words it is general-purpose software that provides
the users with the processes of defining; constructing and manipulating the database for
various applications. There are different types of DBMSs, ranging from small systems
that run on personal computers to huge systems that run on mainframes.
The major operations that can, be performed on the database by using database software
are:
 Database Definition
 Database creation (storing data in a defined database)
 Retrieval (query and reporting)
 Update(Changing the contents of the database)
 Programming User Facilities for system development)
 Database revision and restructuring
 Database integrity control
 Performance Monitoring
The following are some of the examples of database applications:
 Computerised Library Systems
 Automated Teller Machines (ATMs)
 Flight Reservation Systems
 Railway Reservation Systems
 Inventory Management Systems
 Application Systems meant for Government Organisations
 Banking Systems
 Insurance Systems
 Hospitals and Health Sector
 Retails Markets
 Transport
 Education
 Manufacturing
 IT and BPO
 Share Business 51
Middleware Technologies 6.4.4 Characteristics of Data in a Database
The data in a database should have the following characteristic features:
 Shared – Data in a database are shared among different users and applications.
 Persistence – Data in a database exist permanently in the sense the data’s life
time is beyond the scope of the process that created it.
 Validity/Integrity/Correctness – Data should be correct with respect to the
real world entity that they represent.
 Security – Data should be protected from unauthorised access.
 Consistency – Whenever more than one data element in a database represents
related to real-world values, the values should be consistent with respect to the
relationship.
 Non-Redundancy – No two data items in a database should represent the same
real-world entity.
 Independence – The three levels in the schema: internal, conceptual and external
(discussed in the later sections), should be independent of each other so that the
changes in the schema at one level should not affect the other levels.
Self-Check Exercise
Note: i) Write your answers in the space given below.
ii) Check your answers with the answers given at the end of this Unit.
1) Define a DBMS. Give some examples.
.....................................................................................................................
.....................................................................................................................
.....................................................................................................................

6.5 LEVELS OF ABSTRACTION IN A DBMS

The three-level architecture forms the basis of modern database architectures. This is in
agreement with the ANSI/SPARC study group on Database Management Systems.
ANSI/SPARC is the American National Standards Institute/Standard Planning and
Requirement Committee). As shown in the figure, the architecture for DBMSs is divided
into three general levels: External, Conceptual and Internal.

Fig. 6.1: Three-level architecture

52
External Level: This level is concerned with the way individual users see the data. Database Management
Systems
Conceptual level: This level can be regarded as a community user view ­ a formal
description of data of interest to the organisation, independent of any storage
considerations.
Internal level: This level is concerned with the way in which the data is actually stored.

Fig. 6.2: Working of the three- level architecture

6.5.1 External View

A user is anyone who needs to access some portion of the data. They may range from
application programmers to casual users with ad ­hoc queries. Each user has a language
at his/her disposal.
The application programmer may use any high level language or a front-end interface
while the casual user will probably use a query language.
Regardless of the language used, it will include a Data Sub­ Language DSL which is
that subset of the language which is concerned with storage and retrieval of information
in the database and may or may not be apparent to the user.
A DSL is a combination of two languages:
Data definition language (DDL) – provides for the definition or description of
database objects.
Data manipulation language (DML) – supports the manipulation or processing of
database objects.
Each user sees the data in terms of an external view: Defined by an external schema,
consisting basically of descriptions of each of the various types of external record in
that external view, and also a definition of the mapping between the external schema
and the underlying conceptual schema.

6.5.2 Conceptual View

 An abstract representation of the entire information content of the database.
 It is in general a view of the data as it actually is, that is, it is a “model” of the “real
world”
 It consists of multiple occurrences of multiple types of conceptual record, defined
in the conceptual schema.
53
Middleware Technologies  To achieve data independence, the definitions of conceptual records must involve
information content only.
 storage structure is ignored
 access strategy is ignored
 In addition to definitions, the conceptual schema contains authorisation and
validation procedures.

6.5.3 Internal View

The internal view is a low-level representation of the entire database consisting of multiple
occurrences of multiple types of internal (stored) records.
It is however at one remove from the physical level since it does not deal in terms of
physical records or blocks nor with any device specific constraints such as cylinder or
track sizes. A detail of mapping to physical storage is highly implementation specific and
is not expressed in the three-level architecture.
The internal view described by the internal schema:
 defines the various types of stored record
 what indices exist
 how stored fields are represented
 what physical sequence the stored records are in
In effect the internal schema is the storage structure definition.
Mappings
The conceptual/internal mapping:
 defines conceptual and internal view correspondence
 specifies mapping from conceptual records to their stored counterparts
 An external/conceptual mapping:
 defines a particular external and conceptual view correspondence
 A change to the storage structure definition means that the conceptual/internal
mapping must be changed accordingly, so that the conceptual schema may remain
invariant, achieving physical data independence.
A change to the conceptual definition means that the conceptual/external mapping must
be changed accordingly, so that the external schema may remain invariant, achieving
logical data independence.

6.5.4 Data Independence

The three schema architecture further explains the concept of data independence, the
capacity to change the schema at one level without having to change the schema at the
next higher level.
There are two types of data independence:
i) Logical data independence
 The ability to change the conceptual schema without having to change the external
schemas or application programs. When data is added or removed, only the view
definition and the mappings need to be changed in the DBMS that support logical
data independence.
54
 If the conceptual schema undergoes a logical reorganisation, application programs Database Management
that reference the external schema constructs must work as before. Systems

ii) Physical data independence

 The ability to change the internal schema without having to change the conceptual
schema. By extension, the external schema should not change as well.
 Physical file reorganisation to improve performance (such as creating access
structures) results in a change to the internal schema. If the same data as before
remains in the database, the conceptual schema should not change.
 For example, providing an access path to improve retrieval speed of section records
by semester and year, should not require a query to be changed, although it should
become more efficient by utilising the access path.
With a multi-level DBMS, the catalogue must be expanded to include information on
how to map requests and data among the levels. The DBMS uses additional software
to accomplish the mappings.
Data independence occurs because when the schema is changed at some level, the
schema at the next higher level remains unchanged. Only the mapping between the
levels is changed.

6.5.5 Database Languages and Interfaces

Because a database supports a number of user groups, as mentioned previously, the
DBMS must have languages and interfaces that support each user group.
DBMS Languages
 DDL – the data definition language, used by the DBA and database designers
to define the conceptual and internal schemas.
 The DBMS has a DDL compiler to process DDL statements in order to identify
the schema constructs, and to store the description in the catalogue.
 In databases where there is a separation between the conceptual and internal
schemas, DDL is used to specify the conceptual schema, and SDL, storage
definition language, is used to specify the internal schema.
 For true three-schema architecture, VDL, view definition language, is used to
specify the user views and their mappings to the conceptual schema. But in most
DBMSs, the DDL is used to specify both the conceptual schema and the external
schemas.
 Once the schemas are compiled, and the database is populated with data, users
need to manipulate the database. Manipulations include retrieval, insertion, deletion
and modification.
 The DBMS provides operations using the DML, data manipulation language.
 In most DBMSs, the VDL, DML and the DML are not considered separate
languages, but a comprehensive integrated language for conceptual schema
definition, view definition and data manipulation. Storage definition is kept separate
to fine-tune the performance, usually done by the DBA staff.
 An example of a comprehensive language: SQL, which represents a VDL, DDL,
DML as well as statements for constraint specification, etc. 55
Middleware Technologies DBMS Interfaces
Types of interfaces provided by the DBMS include:
Menu-Based Interfaces for Web Clients or Browsing
 Present users with list of options (menus)
 Lead user through formulation of request
 Query is composed of selection options from menu displayed by system.
Forms-Based Interfaces
 Displays a form to each user.
 User can fill out form to insert new data or fill out only certain entries.
 Designed and programmed for naïve users as interfaces to canned transactions.
Graphical User Interfaces
 Displays a schema to the user in diagram form. The user can specify a query by
manipulating the diagram. GUIs use both forms and menus.
Natural Language Interfaces
 Accept requests in written English, or other languages and attempt to understand
them.
 Interface has its own schema, and a dictionary of important words. Uses the
schema and dictionary to interpret a natural language request.
Interfaces for Parametric Users
 Parametric users have small set of operations they perform.
 Analysts and programmers design and implement a special interface for each class
of naïve users.
 Often a small set of commands included to minimise the number of keystrokes
required. (I.e. function keys)
Interfaces for the DBA
 Systems contain privileged commands only for DBA staff.
 Include commands for creating accounts, setting parameters, authorising accounts,
changing the schema, reorganising the storage structures etc.
Self-Check Exercise
Note: i) Write your answers in the space given below.
ii) Check your answers with the answers given at the end of this Unit.
2) Describe the three levels of data abstraction?
3) What is Data Independence?
.....................................................................................................................
.....................................................................................................................
.....................................................................................................................

56
.....................................................................................................................
 Database Management
6.6 DATABASE ENVIRONMENT Systems
The following components form the Database System Environment:
Stored Data Manager
 The database and the database catalogue are stored on disk
 Access to the disk is handled by the Operating System.
 A higher-level stored data manager controls access to DBMS information that is
stored on disk, whether part of the database or the catalogue.
 The stored data manager may use basic OS services for carrying out low-level
data transfer, such as handling buffers.
 Once data is in buffers, the other DBMS modules, as well as other application
programs can process it.
DDL Compiler
A DDL Compiler processes the schema definitions and stores the descriptions (meta-
data) in the catalogue.
Runtime Database Processor
It handles database access at runtime. It receives retrieval or update operations and
carries them out on the database. Its access to the disk goes through the stored data
manager.
Query Compiler
It handles high-level queries entered interactively. It parses, analyses and interprets a
query, then generates calls to the runtime processor for execution.
Precompiler
Precompiler extracts DML commands from an application program written in a host
language. The commands are sent to DML compiler for compilation into code for
database access. The rest is sent to the host language compiler.
Client Program
This program accesses the DBMS running on a separate computer from the computer
on which the database resides. It is called the client computer, and the other is the
database server. In some cases a middle level is called the application server.
Database System Utilities
DBMSs have database utilities that help the DBA manage the system. Functions include:
 Loading - used to load existing text/sequential files into the database. Source
format and desired target file are specified to the utility, and the utility reformats the
data to load into a table.
 Backup – creates a backup copy of the database, usually by dumping database
onto tape. Can be used to restore the database in case of failure. Incremental
backup can be used which records only the changes since the last backup.
 File Reorganisation – reorganise database files into different file organisations
to improve performance. 57
Middleware Technologies  Performance Monitoring – monitors database usage and provides statistics to
the DBA. DBA uses the statistics for decision-making.
Tools, Environment and Communication Facilities
 CASE Tools – used in the design phase to help speed up the development process.
 Data dictionary system – stores catalogue information about schemas and
constraints, as well as design decisions, usage standards, application program
descriptions, user information. Also called an information repository. Can be
accesses directly by DBA or users when needed.
 Application development environments – (i.e., JBuilder) provide environment
for developing database applications, and include facilities to help in database
design, GUI development, querying and updating and application development.
 Communication software – allow users at remote locations to access the database
through computer terminals, workstations or personal computers. Connected to
the database through data communications hardware such as phone lines, local
area networks etc.
Self-Check Exercise
Note: i) Write your answers in the space given below.
ii) Check your answers with the answers given at the end of this Unit.
4) What is a DML Compiler?
.....................................................................................................................
.....................................................................................................................
.....................................................................................................................

6.7 TYPES OF DBMS SYSTEMS

There are several common types of databases; each type of database has its own data
model (how the data is structured). They include; Flat File Model, Hierarchical
Model, Relational Model, Network Model, Object Oriented Relational Model.
These approaches differ in the way in which they permit the user to view and manipulate
relationships. As far as practical implementation is concerned, nowadays, only Relational
and Object Oriented Relational models are the most preferred models by the software
industry.

6.7.1 Flat-file Database

A flat file database is a database designed around a single table. The flat file design puts
all database information in one table, or list, with fields to represent all parameters. A
flat file may contain many fields, often, with duplicate data that are prone to data
corruption. If you decide to merge data between two flat files, you need to copy and
paste relevant information from one file to the other. There is no automation between
flat files. If you have two or more flat files that contain client addresses, for example,
and a client moved, you would have to manually modify the address parameters in each
file that contains that client’s information. Changing information in one file has no bearing
on other files. Flat files offer the functionality to store information, manipulate fields,
print or display formatted information and exchange information with others, through
email and over the Internet. Some flat files may be attached to external files, such as
58 text editors, to extend functionality and manage related information.
6.7.2 Hierarchical Database Management System Database Management
Systems
As its name implies, the Hierarchical Database Model defines hierarchically-arranged
data.
Perhaps the most intuitive way to visualise this type of relationship is by visualising an
upside down tree of data. In this tree, a single table acts as the “root” of the database
from which other tables “branch” out.
You will be instantly familiar with this relationship because that is how all windows-
based directory management systems (like Windows Explorer) work these days.
Relationships in such a system are thought of in terms of children and parents such that
a child may only have one parent but a parent can have multiple children. Parents and
children are tied together by links called “pointers” (perhaps physical addresses inside
the file system). A parent will have a list of pointers to each of their children as shown in
the figure 6.3.

Fig. 6.3: Hierarchical Database Model

This child / parent rule assures that data is systematically accessible. To get to a low-
level table, you start at the root and work your way down through the tree until you
reach your target. Of course, as you might imagine, one problem with this system is that
the user must know how the tree is structured in order to find anything!
The hierarchical model however, is much more efficient than the flat-file model we
discussed earlier because there is not as much need for redundant data. If a change in
the data is necessary, the change might only need to be processed once. Consider the
student flat-file database example as given below:
Table 6.1: Student flat-file
Name Address Course Grade
Mr. Eric Tachibana 123 Kensigton Chemistry 102 C+
Mr. Eric Tachibana 123 Kensigton Chinese 3 A
Mr. Eric Tachibana 122 Kensigton Data Structures B
Mr. Eric Tachibana 123 Kensigton English 101 A
Ms. Tonya Lippert 88 West 1st St. Psychology 101 A
Mrs. Tonya Ducovney 100 Capitol Ln. Psychology 102 A
Ms. Tonya Lippert 88 West 1st St. Human Cultures A
Ms. Tonya Lippert 88 West 1st St. European Governments A
59
Middleware Technologies As we mentioned before, this flat-file database would store an excessive amount of
redundant data. If we implemented this in a hierarchical database model, we would get
much less redundant data. Consider the following hierarchical database scheme:

Fig. 6.4: Hierarchical database Model for Student flat-file

However, as you can imagine, the hierarchical database model has some serious
problems. For one, you cannot add a record to a child table until it has already been
incorporated into the parent table. This might be troublesome if, for example, you wanted
to add a student who had not yet signed up for any courses.
Worse, yet, the hierarchical database model still create repetition of data within the
database. You might imagine that in the database system shown above, there may be a
higher level that includes multiple courses. In this case, there could be redundancy
because students would be enrolled in several courses and thus each “course tree”
would have redundant student information.
Redundancy would occur because hierarchical databases handle one-to-many
relationships well but do not handle many-to-many relationships well. This is because a
child may only have one parent. However, in many cases you will want to have the child
be related to more than one parent. For instance, the relationship between student and
class is a “many-to-many”. Not only can a student take many subjects but a subject
may also be taken by many students. How would you model this relationship simply
and efficiently using a hierarchical database? The answer is that you wouldn’t.
Though this problem can be solved with multiple databases creating logical links between
children, the fix is very kludge and awkward. Faced with these serious problems, the
computer brains of the world got together and came up with the network model.
Disadvantage
Links are unidirectional i.e., parent to child only. The model does not support many to
many relationships. So, in this model if we need any information from lower level then
we have to follow the complete hierarchy of the system.

6.7.3 Network Database Management System

In this many users can access and share one or more databases located on a network.
The network model is the entity relationship model with all relationship restricted to be
either binary or many-one relationships.
The data is represented by collection of records and relationships among data are
represented as links, which can be diagrammatically viewed as pointers. The pointers
are used to locate a particular record.

60
 Database Management
Systems

Fig. 6.5: A Network Scheme for a Bank Database

Disadvantage
The use of pointers leads to complex structures, which makes mapping of related data
very difficult.

6.7.4 Relational Database Management System

Relational database, on the other hand, incorporates multiple tables with methods for
the tables to work together. The relationships between table data can be collated,
merged and displayed in database forms. Most relational databases offer functionality
to share data:
 Across networks
 Over the Internet
 With laptops and other electronic devices, such as palm pilots
 With other software systems
Designing a relational database takes more planning than flat file databases. With flat
files, you may add information, as you deem necessary. With relational databases, you
must be careful to store data in tables such that the relationships make sense. Building
a relational database is dependant upon your ability to establish a relational model. The
model must fully describe how the data is organised, in terms of data structure, integrity,
querying, manipulation and storage.
Relational databases allow you to define certain record fields, as keys or indexes, to
perform search queries, join table records and establish integrity constraints. Search
queries are faster and more accurate when based on indexed values. Table records can
be easily joined by the indexed values. Integrity constraints can be established to ensure
that table relationships are valid. If you are able to establish a one-to-many relationship
in your data tables, you should be using a relational database because a flat file is not
sufficient to handle your data processing needs.
Relational databases offer more robust reporting with report generators that filter and
display selected fields. Relational databases offer the capability to build your own
reporting modules. Most relational databases also offer the capability to import and
export data from other software. Let us see the terminology that is used in RDBMS:
Relation -> table; Tuple -> Row, Record;
Cardinality -> No. of rows; Attribute -> column, field
61
Middleware Technologies Degree -> No. of columns; Primary Key -> unique identifier
Domain -> Set of legal values;

Fig. 6.6: Components of RDBMS

Example: A database file that consists of more than one tables and the relationship can
be created between tables on the common field is called relational database. For example
a database “student” is created having two tables “Address” and “Marks” as shown in
figure below.
Address Marks
Code Code
Name Math
City Physics
Telephone English

In the above tables, “Code” is common field in both tables and these two tables are
linked together on this field.
The relational database is very popular and it is mostly used to create and maintain the
large amount of related data. In business, a relational database contains the following
types of tables.
 Table to store customer information
 Table to store employee information
 Table to store order information
 Table to store inventory information etc.
The customer, order and inventory table can be linked together to process or to generate
reports of orders and billing etc.

6.7.5 Object Oriented Relational Database Management

System
Object oriented databases are also called Object Database Management Systems
(ODBMS). Object databases store objects rather than data such as integers, strings or
real numbers. Objects are used in object oriented languages such as Smalltalk, C++,
Java, and others. Objects basically consist of the following:
62
 Attributes – Attributes are data which defines the characteristics of an object. Database Management
This data may be simple such as integers, strings, and real numbers or it may be a Systems
reference to a complex object.
 Methods – Methods define the behaviour of an object and are what was formally
called procedures or functions.
Therefore objects contain both executable code and data. There are other characteristics
of objects such as whether methods or data can be accessed from outside the object.
We don’t consider this here, to keep the definition simple and to apply it to what an
object database is. One other term worth mentioning is classes. Classes are used in
object oriented programming to define the data and methods the object will contain.
The class is like a template to the object. The class does not itself contain data or
methods but defines the data and methods contained in the object. The class is used to
create (instantiate) the object. Classes may be used in object databases to recreate
parts of the object that may not actually be stored in the database. Methods may not be
stored in the database and may be recreated by using a class.
Comparison to Relational Databases
Relational databases store data in tables that are two dimensional. The tables have
rows and columns. Relational database tables are “normalised” so data is not repeated
more often than necessary. All table columns depend on a primary key (a unique value
in the column) to identify the column. Once the specific column is identified, data from
one or more rows associated with that column may be obtained or changed.
To put objects into relational databases, they must be described in terms of simple
string, integer, or real number data. For instance in the case of an airplane. The wing
may be placed in one table with rows and columns describing its dimensions and
characteristics. The fuselage may be in another table, the propeller in another table,
tires, and so on.
Breaking complex information out into simple data takes time and is labor intensive.
Code must be written to accomplish this task.
Object Persistence
With traditional databases, data manipulated by the application is transient and data in
the database is persisted (Stored on a permanent storage device). In object databases,
the application can manipulate both transient and persisted data.
When to Use Object Databases
Object databases should be used when there is complex data and/or complex data
relationships. This includes a many to many object relationship. Object databases should
not be used when there would be few join tables and there are large volumes of simple
transactional data.
Object databases work well with:
 CAS Applications (CASE-computer aided software engineering, CAD-computer
aided design, CAM-computer aided manufacture)
 Multimedia Applications
 Object projects that change over time.
 Commerce. 63
Middleware Technologies Self-Check Exercise
Note: i) Write your answers in the space given below.
ii) Check your answers with the answers given at the end of this Unit.
5) What is Data Model?
.....................................................................................................................
.....................................................................................................................
.....................................................................................................................
.....................................................................................................................

6.8 VARIOUS DBMS ARCHITECTURES

DBMS may not be similar for all the applications. Let us discuss various types of
DBMS architectures in this session.

6.8.1 Centralised DBMS Architecture

 Used mainframes to provide main processing for user application programs, user
interface programs and DBMS functionality
 User accessed systems via “dumb” computer terminals that only provided display
capabilities, with no processing capabilities.
 All processing was performed remotely on the computer system, and only display
information was sent to the terminals, connected via a network.
 Dumb terminals were replaces with workstations, which lead to the client/server
architecture.

6.8.2 Client / Server Architecture

 Define specialised servers with specific functionalities (file servers, print servers,
web servers, database servers)
 Many client machines can access resources provided by specialised server.
 Client machines provide user with the appropriate interfaces to utilise servers, as
well as with local processing power to run local applications.
 Some machines are client sites, with client software installed and other machines
are dedicated servers.
 Client – a user machine that provides user interface capabilities and local
processing.
 Server – machine that provides services to client machines such as file access,
printing, and database access.
Two-tier Client / Server Architecture
 In relational DBMSs, user interfaces and application programs were first moved
to the client side.
 SQL provided a standard language, which was a logical dividing point between
client and server.
 Query and transaction functionality remained on server side. In this architecture,
64 the server is called a query server, or transaction server.
 In relational DBMSs, the server is called an SQL server, because most RDBMSs Database Management
use SQL. Systems

 In such systems, the user interface and application programs run on the client,
when DMBS access is needed, the program establishes a connection to the DBMS
on the server side. Once the connection is created, the client can communicate
with the DBMS.
 ODBC (Open Database Connectivity) is a standard that provides and application
processing interface which allows client side programs to call the DBMS as long
as both sides have the required software. Most database vendors provide ODBC
drivers for their systems.
 Client programs can connect to several RDBMS and send query and transaction
requests using the ODBC API
 Query requests are sent from the client to the server, and the server processes the
request and sends the result to the client.
 A related Java standard is JDBC, which allows Java programs to access the
DBMS through a standard interface.
 These systems are called two tier architectures because the software components
are distributed over two systems, the client and server.
Three-tier Client/Server Architecture for Web Applications
 Many web applications use three-tier architecture, which adds an intermediate
layer between the client and the database server.
 The middle tier is called the application server, or the web serrver. Plays an
intermediate role, by storing business rules (procedures/constraints) used to access
data from database.
 Can improve database security by checking the client’s credentials before
forwarding request to database server.
 Clients contain GUI interfaces and application specific rules.
 The intermediate server accepts the requests from the client, processes the request
and sends the database commands to the db server, then passes the data from the
database server to the client, where it may be processes further and filtered.
 The three tiers are: user interface, application rules, and data access.

GUI Web Interface

Application Programs,

DBMS

Fig. 6.7: Three-tier client/server Architecture

Let us study the security features of the database in the next section.
65
Middleware Technologies
6.9 DATABASE SECURITY
Databases need to have level of security in order to protect the database against both
malicious and accidental threats. 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 unauthorised 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.
Some threats related to the hardware of the system are as follows:
 Equipment failure
 Deliberate equipment damage (e.g. arson, bombs)
 Accidental / unforeseen equipment damage (e.g. fire, flood)
 Power failure
 Equipment theft
Threats can exist over the communication networks that an organisation uses. Techniques
such as wire tapping, cable disruption (cutting / disconnecting), and electronic interference
can all be used to disrupt services or reveal private information.
Countermeasures
Some countermeasures that can be employed are outlined below:
 Access Controls (can be Discretionary or Mandatory)
 Authorisation (granting legitimate access rights)
 Authentication (determining whether a user is who they claim to be)
 Backup
 Journaling (maintaining a log file - enables easy recovery of changes)
 Encryption (encoding data using an encryption algorithm)
 RAID (Redundant Array of Independent Disks - protects against data loss due to
disk failure)
 Polyinstantiation (data objects that appear to have different values to users with
different access rights / clearance)
 Views (virtual relations which can limit the data viewable by certain users).

66
 Database Management
6.10 POPULAR DBMS PACKAGES Systems
There are many popular DBMS available in market, some of them are:
 Borland Paradox
 Filemaker
 IBMDB2
 Informix
 Ingres
 Interbase
 Microsoft SQL Server
 Microsoft Access
 Microsoft FoxPro
 Oracle
 Sybase
 MySQL
 PostgreSQL
 mSQL
 SQL Server
Let us discuss the database project development in the next section.

6.11 DATABASE PROJECT DEVELOPMENT

The conventional Systems Life Cycle consists of:
 Analysis
 Design
 Development
 Implementation
 Maintenance
In practice these phases are not always sharply distinguished; for small projects it may
not be necessary to go formally through every one. The move from one phase to the
next is essentially a move from the general to the specific.
At each stage, particularly where a DBMS is involved, we shall be concerned both
with information and with processes to be performed using that information.

6.11.1 Analysis
The outputs from this stage should be:
A CONCEPTUAL DATA MODEL describing the information which is used within
the organisation but not in computer-related terms. This level of data analysis will be 67
Middleware Technologies considered in more detail later. One of the problems with any systems design in a large
organisation is that it must proceed in a piecemeal manner – it is impossible to create a
totally new Global system in one fell swoop, and each sub-system must dovetail with
others which may be at quite a different stage of development. The conceptual data
model provides a context within which more detailed design specifications can be
produced, and should help in maintaining consistency from one application area to
another.
A CONCEPTUAL PROCESS MODEL describing the functions of the organisation
in terms of events (e.g. a purchase, a payment, a booking) and the processes which
must be performed within the organisation to handle them. This may lead to a more
detailed functional specification - describing the organisational requirements which must
be satisfied, but not how they are to be achieved.

6.11.2 Design
This stage should produce:
A LOGICAL DATA MODEL: a description of the data to be stored in the database,
using the conventions prescribed by the particular DBMS to be used. This is sometimes
referred to as a SCHEMA and some DBMSs also give facilities for defining SUB-
SCHEMA or partitions of the overall schema. Logical data models supported by present
day DBMSs will be considered later.
A SYSTEM SPECIFICATION, describing in some detail what the proposed system
should do. This will now refer to COMPUTER PROCESSES, but probably in terms
of INPUT and OUTPUT MESSAGES rather than internal logic, describing, for instance,
the effect of selecting an item from a menu, or any option within a command driven
system. Program modules are defined in terms of the screen displays and/or reports
which they generate. Note that the data referred to here has a temporary existence, in
contrast with what is stored in the database itself.

6.11.3 Development
Specification of the database itself must now come down another level, to decisions
about PHYSICAL DATA STORAGE in particular files on particular devices. For
this a knowledge of the computer operating system, as well as the DBMS, is required.
Conventional program development - coding, testing, debugging etc. may also be done.
If a totally packaged system has been purchased this may not be necessary - it will
simply be a matter of discovering how to use the command and query language already
supplied to store and retrieve data, generate reports and other outputs. Even here an
element of testing and debugging may be involved, since it is unlikely that the new user
of a system will get it exactly right the first time. It is certainly inadvisable for this sort of
experimentation to take place using a live database!

6.11.4 Implementation
This puts the work of the previous three phases into everyday use. It involves such
things as loading the database with live rather than test data, staff training, probably the
introduction of new working practices. It is not unusual to have an old and a new
system running side by side for a while so that some back-up is available if the new
system fails unexpectedly.

6.11.5 Maintenance
68 Systems once implemented generally require further work done on them as time goes
by, either to correct original design faults or to accommodate changes in user requirements Database Management
or operating constraints. One of the objectives of using a DBMS is to reduce the Systems
impact of such changes - for example the data can be physically re-arranged without
affecting the logic of the programs which use it. Some DBMSs provide utility programs
to re-organise the data when either its physical or logical design must be altered.

6.12 DATABASE ADMINISTRATOR (DBA)

The database administrator (DBA) is the person (or group of people) responsible for
overall control of the database system. The DBA’s responsibilities include the following:
 Deciding the information content of the database, i.e. identifying the entities of
interest to the enterprise and the information to be recorded about those entities.
This is defined by writing the conceptual schema using the DDL.
 Deciding the storage structure and access strategy, i.e. how the data is to be
represented by writing the storage structure definition. The associated internal/
conceptual schema must also be specified using the DDL.
 Liaising with users, i.e. to ensure that the data they require is available and to write
the necessary external schemas and conceptual/external mapping (again using
DDL).
 Defining authorisation checks and validation procedures. Authorisation checks
and validation procedures are extensions to the conceptual schema and can be
specified using the DDL.
 Defining a strategy for backup and recovery. For example periodic dumping of
the database to a backup tape and procedures for reloading the database for
backup. Use of a log file where each log record contains the values for database
items before and after a change and can be used for recovery purposes.
 Monitoring performance and responding to changes in requirements, i.e. changing
details of storage and access thereby organising the system so as to get the
performance that is “best for the enterprise”.

6.13 SUMMARY
A database system is an integrated collection of related files along with the details about
their definition, interpretation, manipulation and maintenance. A DBMS is a major
software component of database system. It consists of collection of interrelated data
and programs to access that data. The primary goal of a DBMS is to provide an
environment which is both convenient and efficient to use in retrieving information from
and storing information into the database.
The DBMS not only makes the integrated collection of reliable and accurate data
available to multiple applications and users but also controls from unauthorised, users
to access the data.
A DBMS is a major software system consisting of a number of elements. It provides
users DDL for defining the external and conceptual view of the data and DML for
manipulating the data stored in the database. The database manager is the component
of DBMS that provide the interface between the user and the file system. The database
administration defines and maintains the three level of the database as well as the mapping
between levels to insulate die higher levels from changes that take place in the lower
levels. The DBA is responsible for implementing measures for ensuring the security,
integrity and recovery of the database. 69
Middleware Technologies
6.14 ANSWERS TO SELF CHECK EXERCISES
1) DBMS short for Database Management System is a software system that uses a
standard method of cataloging, retrieving, and running queries on data. The DBMS
manages incoming data, organises it, and provides ways for the data to be modified
or extracted by users or other programs. Some DBMS examples include MySQL,
PostgreSQL, Microsoft Access, SQL Server, FileMaker, Oracle, RDBMS,
Clipper, and Foxpro.
2) There are three levels of abstraction:
a. Physical level: The lowest level of abstraction describes how data are stored.
b. Logical level: The next higher level of abstraction, describes what data are
stored in database and what relationship among those data.
c. View level: The highest level of abstraction describes only part of entire
database.
3) Data independence means that the application is independent of the storage
structure and access strategy of data?. In other words, The ability to modify the
schema definition in one level should not affect the schema definition in the next
higher level.
Two types of Data Independence:
Physical Data Independence: Modification in physical level should not affect
the logical level.
Logical Data Independence: Modification in logical level should affect the view
level. Logical Data Independence is more difficult to achieve
4) It translates DML statements in a query language into low-level instruction that the
query evaluation engine can understand.
5) It is a collection of conceptual tools for describing data, data relationships data
semantics and constraints.

6.15 KEYWORDS
Data definition language : The subset of SQL used for defining and
(DDL) examining the structure of a database.
Data manipulation : 1.The subset of SQL used for inserting, deleting,
language (DML) updating and fetching data in a database.
Data Sub Language (DSL) : A computer language used to define or
manipulate the structure of a relational database
management system (DBMS)
SQL : SQL is short for Structured Query Language, an
international standard language for manipulating
relational databases.

6.16 REFERENCES AND FURTHER READING

Desai, Bipin C. An Introduction to Database Systems. New Delhi: Galgotia, 1999.
70 Print
Leon, Alexis and Leon, Mathews. Database Management Systems. New Delhi: Vikas Database Management
Publishing, 2002. Print Systems

Navathe, Elmasri. Fundamental of Database Systems. 3rd ed. Pearson Education,

2003. Print
Ramakrishna, Raghu and Gehrke, Johannes. Database Management Systems. 2nd
ed. Mc Graw Hill, 2000. Print
Silberschats, Abraham, F.Korth, Henry and Sudarshan S. Database System Concepts.
5th ed. Mc Graw Hill International Edition, 2006. Print
Umanath, Narayan S. and Scamell, Richard W. Data Modeling and Database Design.
Cengage Learning, 2009. Print

71