Fundamentals of Database System

Chapter Two
Database system Concepts and Architectures
2.1 Database Terminology
Any firm that gathers extensive amounts of information to be retrieved at some point in the future
depends on a file system (generally a database system) that allows for the access of specific information
in a timely and cost effective manner. This information is usually stored in files, records and fields.
A file is a set of related information stored together. It is a collection of information relative to a number
of related objects. For example, a bank needs to collect various types of information about customers,
employees, savings accounts, demand accounts, etc. Each one of these is a ‘subpackage’ of information,
stored as a file. They may have 4 files (Employee File, a Customer File, a Savings Account file and a
Demand Account file).
A record is a collection of information about an object. If we look at the example from above, the
Customer File, a record is a collection of information about a customer object. The record contains
information required by the bank about each customer, and stored for each customer. For example,
information contained in a customer record may include at least first_name, last_name, id_number,
birth_date. Each of these pieces of information are taken together to form a customer record. Because
each record in the file contain the same number and types of fields, the records have the same type.
A field is a piece of information about an entity, contained in a record. In the above example, the 4
pieces of information, first_name, last_name, id_number and birth_date are all fields. Therefore we can
use the following definitions, a record is a collection of related fields, and a file is a collection of related
records, of the same type.
Keys:- In most cases there is a field in a record that identifies that particular record uniquely. This field
is referred to as the primary key of the record. In some cases, there may not be a single field that
uniquely identifies a record and serve as the primary key. In these cases, a combination of two or more
fields can serve as the primary key. This is called a composite key.
Let’s assume there is a field for Customer Name. In this case, because it is likely that two customers will
have the same name, therefore duplicate values, Customer Name can’t be used as a primary key. This is
referred to as a secondary key. A secondary key is a field which identifies a record, but that does not
uniquely identify a record.

AASTU Compiled by Chere L. (M.Tech) Page 1

 Fundamentals of Database System
2.2 Data Models, Schemas, and Instances
2.2.1 Data Models
A specific DBMS has its own specific Data Definition Language, but this type of language is too low
level to describe the data requirements of an organization in a way that is readily understandable by a
variety of users. We need a higher-level language. Such a higher-level is called data-model. A model is a
representation(abstraction) of real world objects and events and their associations. The main uses of
model is to help you understand the complexities of the real-world environment.
A data model a set of concepts to describe the structure of a database, and certain constraints
that the database should obey. Most data models also include a set of operations.
• Structure of database: is about data types, relationships, and constraints that should hold for data
• Data Model Operations: Operations for specifying database retrievals and updates by referring
to the concepts of the data model. Operations on the data model may include basic operations
and user-defined operations.
A data model is a description of the way that data is stored in a database. Data model helps to
understand the relationship between entities and to create the most effective structure to hold data. The
main purpose of Data Model is to represent the data in an understandable way.
Data Model is a collection of tools or concepts for describing

Data and Data relationships

Data semantics

Data constraints
Therefore Data Model:
 Useful in understanding complexities of the real-world environment
 Facilitate interaction among the designer, the applications programmer, and the end user
 Data model organizes data for various users as end users have different views and needs for data
Data modeling is an iterative, progressive process. You start with a simple understanding of the
problem domain, and as your understanding of the problem domain increases, so does the level of detail
of the data model. The final data model is in effect a “blueprint” containing all the instructions to build
a database that will meet all end-user requirements. This blueprint is narrative and graphical in nature,
meaning that it contains both text descriptions in plain, unambiguous language and clear, useful
diagrams depicting the main data elements.

AASTU Compiled by Chere L. (M.Tech) Page 2

 Fundamentals of Database System

Categories of data models

Many data models have been proposed, which we can categorize according to the types of concepts they
use to describe the database structure. The categories of data model includes:

Conceptual

Physical

Implementation(Representational)

Conceptual (high-level, semantic) data models:

 Provide concepts that are close to the way many users perceive data. (Also called entity-based
or object-based data models.).
 Conceptual data models use concepts such as entities, attributes, and relationships.

Entity: represents real world object or concept such as of the employee, project

Attribute: represents property that describes entity more, e.g. employee’s name or salary

Relationship: represent an association among two or more entities.
 Entity-Relationship model is a popular high level conceptual model.

Physical (low-level, internal) data models:

 Provide concepts that describe details of how data is stored on the computer storage media,
typically magnetic disks.
 Concepts provided by low-level data models are generally meant for computer specialists, not
for end users..

Implementation (representational) data models:

 Provide concepts that fall between the above two, balancing user views with some computer
storage details.
 Provide concepts that may be easily understood by end users but that are not too far removed
from the way data is organized in computer storage.
 Representational data models hide many details of data storage on disk but can be implemented
on a computer system directly.
 Representational or implementation data models are the models used most frequently in
traditional commercial DBMSs. These include the widely used relational data model, as well as
the so-called legacy data models, the network and hierarchical models.

AASTU Compiled by Chere L. (M.Tech) Page 3

 Fundamentals of Database System

Type of data models

1) Hierarchical Model
This model implemented in a joint effort by IBM and North American Rockwell around 1965. Resulted
in the IMS family of systems. Other system based on this model: System 2k (SAS inc.).
The hierarchical data model organizes data in a tree structure. There is a hierarchy of parent and child
data segments. This structure implies that a record can have repeating information, generally in the child
data segments. Data in a series of records, which have a set of field values attached to it. It collects all
the instances of a specific record together as a record type.

The simplest data model

Record type is referred to as node or segment

Nodes are arranged in a hierarchical structure as sort of upside-down tree

The top node is the root node

A parent node can have more than one child node

A child node can only have one parent node

The relationship between parent and child is one-to-many

Relation is established by creating physical link between stored records (each is stored with
a predefined access path to other records)

To add new record type or relationship, the database must be redefined and then stored in a
new form.

AASTU Compiled by Chere L. (M.Tech) Page 4

 Fundamentals of Database System

Advantages of Hierarchical Data Model:

Hierarchical Model is simple to construct and operate on

Corresponds to a number of natural hierarchically organized domains - e.g., assemblies in
manufacturing, personnel organization in companies

Language is simple; uses constructs like GET, GET UNIQUE, GET NEXT, GET NEXT
WITHIN PARENT etc.

Disadvantages of Hierarchical Data Model:

Database is visualized as a linear arrangement of records

Navigational and procedural nature of processing

Little scope for "query optimization"

Addition, deletion, and search operations are very difficult.

There is duplication of data.

We must write a program and may complex programming is required.

2) Network Model
The network model is the first one to be implemented by Honeywell in 1964-65 (IDS System). Adopted
heavily due to the support by CODASYL (CODASYL - DBTG report of 1971). Later implemented in a
large variety of systems - IDMS (Cullinet - now CA), DMS 1100 (Unisys), IMAGE (H.P.), VAX -
DBMS (Digital Equipment Corp).
The network model is a database model conceived as a flexible way of representing objects and their
relationships. Its distinguishing feature is that the schema, viewed as a graph in which object types are
nodes and relationship types are arcs, is not restricted to being a hierarchy or lattice. The nodes
corresponds to record types and the links to pointers or relationships. All the relationship are hardwired
or pre-computed and build into structure of database itself because they are very efficient in space
utilization and query execution time.
The network data structure looks like a tree structure except that a dependent node which is called a
child or member, may have more than one parent or owner node. The network model replaces the
hierarchical model with a graph thus allowing more general connections among the nodes. The main
difference of the network model from the hierarchical model is its ability to handle many to many
relationships. In other words it allow a record to have more than one parent.

AASTU Compiled by Chere L. (M.Tech) Page 5

 Fundamentals of Database System
Generally the network model characterized by the following concepts

Like hierarchical model network model is a collection of physically linked records.

Allows record types to have more than one parent unlike hierarchical model

A network data models sees records as set members and each set has an owner and one or more
members

Allow member records to have more than one owner

Advantages of Network Data Model:

Conceptual simplicity:- Just like the hierarchical model, the network model is also
conceptually simple and easy to design.

Capability to handle more relationship types:- The network model can handle the one to
many as well as many to many relationships which is real help in modeling the real life
situations. Also it able to model complex relationships and represents semantics of add/delete
on the relationships.

Can handle most situations for modeling using record types and relationship types.

Ease of data access:- The data access is easier and flexible than the hierarchical model.
Programmers can do optimal navigation through the database.

Language is navigational; uses constructs like FIND, FIND member, FIND owner, FIND
NEXT within set, GET etc.

Data integrity- The network model does not allow a member to exist without an owner.

Duplication of data is reduced as compared to hierarchical model.

Data independence- The network model is better than the hierarchical model in isolating the
programs from the complex physical storage details.

Easy to show the connection of items and Good for network type problem.

AASTU Compiled by Chere L. (M.Tech) Page 6

 Fundamentals of Database System
Disadvantages of Network Data Model:

Navigational and procedural nature of processing

System complexity:- All the records are maintained using pointers and database contains a
complex array of pointers that thread through a set of records. Hence the whole database
structure becomes very complex.

Operational Anomalies:- The insertion, deletion and updating operations of any record
require large number of pointers adjustments.

Absence of structural independence:- structural changes to the database is very difficult.

Little scope for automated "query optimization”

Programming is required.

3) Relational Data Model

Following a famous paper written by Ted Codd in 1970, database systems changed significantly. Codd
proposed that database systems should present the user with a view of data organized as tables called
relations. Behind the scenes, there might be a complex data structure that allowed rapid response to a
variety of queries. But, unlike the user of earlier database systems, the user of a relational system would
not be concerned with the storage structure. Queries could be expressed in a very high-level language,
which greatly increased the efficiency of database programmers.
First commercial system in 1981-82. Now in several commercial products (DB2, ORACLE, SQL
Server, SYBASE, INFORMIX).

AASTU Compiled by Chere L. (M.Tech) Page 7

 Fundamentals of Database System

Terminologies originates from the branch of mathematics called set theory and relation

Can define more flexible and complex relationship

Viewed as a collection of tables called “Relations” equivalent to collection of record types

Relation: Two dimensional table

Stores information or data in the form of tables rows and columns

A row of the table is called tuple equivalent to record

A column of a table is called attribute equivalent to fields

Data value is the value of the Attribute

Records are related by the data stored jointly in the fields of records in two tables or files. The
related tables contain information that creates the relation

The tables seem to be independent but are related somehow.

No physical consideration of the storage is required by the user

Many tables are merged together to come up with a new virtual view of the relationship

The rows represent records (collections of information about separate items)

The columns represent fields (particular attributes of a record)

Conducts searches by using data in specified columns of one table to find additional data in
another table

In conducting searches, a relational database matches information from a field in one table
with information in a corresponding field of another table to produce a third table that
combines requested data from both tables

AASTU Compiled by Chere L. (M.Tech) Page 8

 Fundamentals of Database System

4) Entity Relationship Model

The conceptual simplicity of relational database technology triggered the demand for RDBMSs. In turn,
the rapidly increasing requirements for transaction and information created the need for more complex
database implementation structures, thus creating the need for more effective database design tools.
Complex design activities require conceptual simplicity to yield successful results.
Although the relational model was a vast improvement over the hierarchical and network models, it still
lacked the features that would make it an effective database design tool. Because it is easier to examine
structures graphically than to describe them in text, database designers prefer to use a graphical tool in
which entities and their relationships are pictured. Thus, the entity relationship (ER) model, or ERM, has
become a widely accepted standard for data modeling.

ER model is the graphical representation of entities and their relationships in a database
structure that quickly became popular because it complemented relational data model concepts.

The relational data model and ER-model combined to provide the foundation for tightly
structured database design.

ER models are normally represented in an entity relationship diagram (ERD), which uses
graphical representations to model database components.

2.2.2 Schemas and Instances

In any data model, it is important to distinguish between the description of the database and the
database itself. For instance, when a database is designed using a Relational data model, all the data is
represented in a form of a table. In such definitions and representation, there are two basic components
of the database. The two components are the definition of the Relation or the Table and the actual data
stored in each table.
The data definition is what we call the Schema or the skeleton of the database and the Relations with
some information at some point in time is the Instance or the flesh of the database.
Schemas
 Schema describes how data is to be structured, defined at setup/Design time (also called
"metadata")
 Since it is used during the database development phase, there is rare tendency of changing the
schema unless there is a need for system maintenance which demands change to the definition of
a relation.
 Most data models have certain conventions for displaying schemas as diagrams. A displayed
schema is called a schema diagram.

AASTU Compiled by Chere L. (M.Tech) Page 9

 Fundamentals of Database System
 The following figure, shows a schema diagram for the database. The diagram displays the
structure of each record type but not the actual instances of records. We call each object in the
schema (such as STUDENT or COURSE) a schema construct

 A schema diagram displays only some aspects of a schema, such as the names of record types
and data items, and some types of constraints.
 Other aspects are not specified in the schema diagram; for example, in the previous figure shows
neither the data type of each data item, nor the relationships among the various files.
 Many types of constraints are not represented in schema diagrams.
 For example a constraint such as students majoring in computer science must take CS1310
before the end of their sophomore year is quite difficult to represent diagrammatically.

Defines DBMS schemas at three levels:

 Internal schema: at the internal level to describe physical storage structures and access paths.
Typically uses a physical data model.
 Conceptual schema: at the conceptual level to describe the structure and constraints for the
whole database for a community of users. Uses a conceptual or an implementation data model.
 External schema: at the external level to describe the various user views. Usually uses the same
data model as the conceptual level.

AASTU Compiled by Chere L. (M.Tech) Page 10

 Fundamentals of Database System
Instances
 It is the collection of data in the database at a particular point of time (snap-shot).
o Also called State or Snap Shot or Extension of the database
o Refers to the actual data in the database at a specific point in time
o State of database is changed any time we add, delete or update an item.
 Valid state: the state that satisfies the structure and constraints specified in the schema and is
enforced by DBMS
 Since Instance is actual data of database at some point in time, changes rapidly
 The actual data in a database may change quite frequently.
 For example, the database shown in the previous figure changes every time we add a new student
or enter a new grade.
When we define a new database, we specify its database schema only to the DBMS. At this point, the
corresponding database state is the empty state with no data. We get the initial state of the database
when the database is first populated or loaded with the initial data

2.3 Three-Schema Architecture and Data Independence

The Three of the four important characteristics of the database approach, listed in chapter 1, Section 1.2,
subsection 3, are
(1) use of a catalog to store the database description (schema) so as to make it self-describing,
(2) insulation of programs and data (program-data and program-operation independence), and
(3) support of multiple user views.
In this section we specify an architecture for database systems, called the three-schema architecture,
that was proposed to help achieve and visualize these characteristics. Then we discuss the concept of
data independence further.

Three-Level database architecture (ANSI-SPARC Architecture)

The major aim of DB is to provide users with an abstract view of data, hiding certain details of how
data is stored and manipulated. Since DB is a shared resources each users may require a different view
of the data. To satisfy these needs, the architecture of most commercial DBMSs available today is based
on the so-called ANSI-SPARC Architecture.(America National Standard Institution Standard Planning
and Requirement committee).

AASTU Compiled by Chere L. (M.Tech) Page 11

 Fundamentals of Database System
The purpose and origin of the Three-Level database architecture

All users should be able to access same data. This is important since the database is having a
shared data feature where all the data is stored in one location and all users will have their own
customized way of interacting with the data.

User's view is unaffected or immune to changes made in other views. Since the requirement of one
user is independent of the other, a change made in one user’s view should not affect other users.

Users should not need to know physical database storage details. As there are naïve users of the
system, hardware level or physical details should be a black-box for such users.

DBA should be able to change database storage structures without affecting the users' views. A
change in file organization, access method should not affect the structure of the data which in turn
will have no effect on the users.

Internal structure of database should be unaffected by changes to physical aspects of storage.

DBA should be able to change conceptual structure of database without affecting all users. In any
database system, the DBA will have the privilege to change the structure of the database, like
adding tables, adding and deleting an attribute, changing the specification of the objects in the
database.

Three-level ANSI-SPARC Architecture of a Database

External view: This is a highest level of abstraction as seen by user. Users' view of the database. This
level of abstraction describes only the part of entire database that is relevant to a particular user.
Different users have their own customized view of the database independent of other users. It is based
on the conceptual model, is the end user view of data environment. Each external view described by
means of a schema called an external schema or subschema.

AASTU Compiled by Chere L. (M.Tech) Page 12

 Fundamentals of Database System
Conceptual level: At this level of database abstra
abstraction
ction all the database entities and the relationships
among them are included. Describes what data is stored in database and relationships among the data.
Community view of the database. One conceptual view represents the entire database. the conceptual
schema
chema defines thus conceptual view.

Internal(physical) level: This lowest level of abstraction. it closest to physical storage device. It
describes how data are actually stored on the storage medium. The internal schema, which contains the
definition of the
he stored record, the method representing the data fields, expresses the internal view and
the access aids used.

ANSI-SPARC
SPARC Architecture and Database Design Phases

AASTU Compiled by Chere L. (M.Tech) Page 13

 Fundamentals of Database System
The following example can be taken as an illustration for the difference between the three levels in the
ANSI-SPARC database Architecture. Where:
 The first level is concerned about the group of users and their respective data requirement
independent of the other.
 The second level is describing the whole content of the database where one piece of information
will be represented once.
 The third level

Differences between Three Levels of ANSI-SPARC Architecture

Data Independence
The three-schema architecture can be used to further explain the concept of data independence , which
can be defined as the capacity to change the schema at one level of a database system without having to
change the schema at the next higher level.
Application programs interact with the external database schema, which has an interface, or mapping, to
the conceptual schema. The conceptual schema is concerned with the identity and relationships between
elements of data of interest to an organization, and has an interface or mapping to the internal schema.
The internal schema controls how the data is stored on physical media, such as magnetic disks.

AASTU Compiled by Chere L. (M.Tech) Page 14

 Fundamentals of Database System
In a database environment, if there is a requirement to change the structure of a particular file of data
held on disk, this will be recorded in the internal schema. The interface between the internal schema and
the conceptual schema will be amended to reflect this, but there will be no need to change the external
schema. This means that any such change of physical data storage is transparent to users and application
programs. This approach removes the problem of physical data dependence.
In a similar manner, any changes to the conceptual schema, can be isolated from the external schema
and the internal schema; such changes will be reflected in the interface between the conceptual schema
and the other levels. This achieves logical data independence. What this means effectively, is that
changes can be made at the conceptual level, where the overall model of an organizations data is
specified, and these changes can be made independently of both the physical storage level, and the
external level seen by individual users. The changes are handled by the interfaces between the
conceptual, middle layer, and the physical and external layers.
Mappings among schema levels are needed to transform requests and data. Programs refer to an
external schema, and are mapped by the DBMS to the internal schema for execution. When a schema at
a lower level is changed, only the mappings between this schema and higher-level schemas need to be
changed in a DBMS that fully supports data independence. The higher-level schemas themselves are
unchanged. Hence, the application programs need not be changed since they refer to the external
schemas.
The ability to modify a scheme definition in one level without affecting a scheme definition in a higher
level is called data independence. We can define two types of data independence
 Logical data independence
 Physical data independence

Logical Data Independence:

Refers to immunity of external schemas to changes in conceptual schema.

Conceptual schema changes e.g. addition/removal of entities should not require changes to
external schema or rewrites of application programs.

The capacity/ability to change/modify the conceptual schema without having to change the
external schemas and their application programs (i.e. without causing application programs to
be rewritten).

Usually done when logical structure of database is altered

Logical data independence is harder to achieve as the application programs are usually heavily
dependent on the logical structure of the data. An analogy is made to abstract data types in
programming languages.

AASTU Compiled by Chere L. (M.Tech) Page 15

 Fundamentals of Database System
Physical Data Independence

The ability to modify the physical schema without changing the logical schema and without
causing application programs to be rewritten

Applications depend on the logical schema

In general, the interfaces between the various levels and components should be well defined so
that changes in some parts do not seriously influence others.

The capacity to change the internal schema without having to change the conceptual schema

Modifications at this level are usually to improve performance

Refers to immunity of conceptual schema to changes in the internal schema

Internal schema changes e.g. using different file organizations, storage structures/devices
should not require change to conceptual or external schemas.

Data Independence and the ANSI-SPARC Three-level Architecture

AASTU Compiled by Chere L. (M.Tech) Page 16

 Fundamentals of Database System
2.4 Centralized and Client-Server Architectures
Centralized DBMS
Earlier architectures used mainframe computers to provide the main processing for all system functions,
combines everything into single system including user application programs and user interface
programs, as well as all the DBMS functionality. The reason was that most users accessed such systems
via computer terminals that did not have processing power and only provided display capabilities.
Therefore, all processing was performed remotely on the computer system, and only display information
and controls were sent from the computer to the display terminals, which were connected to the central
computer via various types of communications networks.

All the DBMS functionality, application program execution, and user inter-face processing were carried
out on one machine. The figure above illustrates the physical components in a centralized architecture.
Gradually, DBMS systems started to exploit the available processing power at the user side, which led to
client/server DBMS architectures.

AASTU Compiled by Chere L. (M.Tech) Page 17

 Fundamentals of Database System

Client-Server Architectures:
The client/server architecture was developed to deal with computing environments in which a large
number of PCs, workstations, file servers, printers, data-base servers, Web servers, e-mail servers, and
other software and equipment are connected via a network. The idea is to define specialized servers with
specific functionalities.
There are different client-server DBMS. This includes Specialized Servers with Specialized functions,
Clients and DBMS Server.
Specialized Servers with Specialized functions.
 File Servers --- maintains the files of the client machines.
 Printer Servers -- being connected to various printers; all print requests by the clients are
forwarded to this machine.
 Web Servers and E-mail Servers also fall into the specialized server category

Clients:- The resources provided by specialized servers can be accessed by many client machines.
 The client machines provide appropriate interfaces and a client-version of the system to access
and utilize the server resources as well as with local processing power to run local applications.
 Clients maybe diskless machines or PCs or Workstations with disks with only the client software
installed. Others would have both client and server functionality.
 Connected to the servers via some form of a network (LAN: local area network, wireless
network, etc.)

DBMS Server
 A server is a system containing both hard-ware and software that can provide services to the
client machines, such as file access, printing, archiving, or database access.
 Provides database query and transaction services to the clients
 Sometimes called query and transaction servers

Two main types of basic DBMS architectures were created on this underlying client/server framework:
 Two-tier client/server architecture
 Three-tier client/server architecture

AASTU Compiled by Chere L. (M.Tech) Page 18

 Fundamentals of Database System
(a) Two Tier Client-Server Architecture
 User Interface Programs and Application Programs run on the client side
 Interface called ODBC (Open Database Connectivity) provides an Application program
interface (API) allow client side programs to call the DBMS. Most DBMS vendors provide
ODBC drivers.
 A client program may connect to several DBMSs.
The different approach to two-tier client/server architecture was taken by some object-oriented DBMSs,
where the software modules of the DBMS were divided between client and server in a more integrated
way. For example, the server level may include the part of the DBMS software responsible for handling
data storage on disk pages, local concurrency control and recovery, buffering and caching of disk
pages, and other such functions. Meanwhile, the client level may handle the user interface; data
dictionary functions; DBMS interactions with programming language compilers; global query
optimization, concurrency control, and recovery across multiple servers; structuring of complex objects
from the data in the buffers; and other such functions.
In this approach, the client/server interaction is more tightly coupled and is done internally by the
DBMS modules some of which reside on the client and some on the server rather than by the
users/programmers. The exact division of functionality can vary from system to system. In such a
client/server architecture, the server has been called a data server because it provides data in disk pages
to the client. This data can then be structured into objects for the client programs by the client-side
DBMS software.

The architectures described here are called two-tier architectures because the software components are
distributed over two systems: client and server. The advantages of this architecture are its simplicity and
seamless compatibility with existing systems.

AASTU Compiled by Chere L. (M.Tech) Page 19

 Fundamentals of Database System

(b) Three Tier Client-Server Architecture

The emergence of the Web changed the roles of clients and servers, leading to the three-tier architecture.
Many Web applications use an architecture called the three-tier architecture, which adds an intermediate
layer between the client and the database server, as illustrated in Figure below:

AASTU Compiled by Chere L. (M.Tech) Page 20

 Fundamentals of Database System
The Intermediate Layer called Application Server or Web Server depending on the application. This
server plays an intermediary role by running application programs, stores the web connectivity software
and the rules and business logic (constraints) part of the application used to access the right amount of
data from the database server.
Clients contain GUI interfaces and some additional application-specific business rules. The intermediate
server accepts requests from the client, processes the request and sends database queries and commands
to the database server, and then acts as a conduit for passing (partially) processed data from the database
server to the clients, where it may be processed further and filtered to be presented to users in GUI
format. Thus, the user interface, application rules, and data access act as the three tiers.
Figure 2.7(b) shows another architecture used by database and other application package vendors. The
presentation layer displays information to the user and allows data entry. The business logic layer
handles intermediate rules and constraints before data is passed up to the user or down to the DBMS.
The bottom layer includes all data management services. The middle layer can also act as a Web server,
which retrieves query results from the database server and formats them into dynamic Web pages that
are viewed by the Web browser at the client side.
It can also improve database security by checking a client’s credentials before forwarding a request to
the data-base server.
 encrypt the data at the server before transmission
 decrypt data at the client
Other architectures have also been proposed. It is possible to divide the layers between the user and the
stored data further into finer components, thereby giving rise to n-tier architectures, where n may be
four or five tiers. Typically, the business logic layer is divided into multiple layers. Besides distributing
programming and data throughout a network, n -tier applications afford the advantage that any one tier
can run on an appropriate processor or operating system platform and can be handled independently.

2.5 Classification of DBMSs

Several criteria are normally used to classify DBMSs.
Based on the data model used:
• Traditional: Relational, Network, Hierarchical.
• Emerging: Object-oriented, Object-relational.
Based on number of users:
• Single-user: support only one user at a time and typically used with micro- computers
• Multi-user: support con-current multiple users. It include major of DBMSs.

AASTU Compiled by Chere L. (M.Tech) Page 21

 Fundamentals of Database System
Based on number of sites:
• Centralized: the data is stored at a single computer site. A centralized DBMS can support
multiple users, but the DBMS and the database reside totally at a single computer site.
• Distributed: an have the actual database and DBMS software distributed over many sites,
connected by a computer network. It supports multiple computers and use multiple databases.
• Distributed Database Systems have now come to be known as client server based database
systems because they do not support a totally distributed environment, but rather a set of
database servers supporting a set of clients.
• Variations of Distributed Environments:
 Homogeneous DDBMS: use the same DBMS software at all the sites
 Heterogeneous DDBMS: use different DBMS software at each site
• It is also possible to develop middleware software to access several autonomous preexisting
databases stored under heterogeneous DBMSs. This leads to federated DBMS (or multi-
database system), in which the participating DBMSs are loosely coupled and have a degree of
local autonomy.
We can also classify a DBMS on the basis of the types of access path options for storing files. One well-
known family of DBMSs is based on inverted file structures. Finally, a DBMS can be general purpose
or special purpose. When performance is a primary consideration, a special-purpose DBMS can be
designed and built for a specific application; such a system cannot be used for other applications without
major changes. Many airline reservations and telephone directory systems developed in the past are
special-purpose DBMSs. These fall into the category of online transaction processing (OLTP) systems,
which must support a large number of concurrent transactions without imposing excessive delays.

AASTU Compiled by Chere L. (M.Tech) Page 22