0% found this document useful (0 votes)
7 views13 pages

DBMS Introduction

xcvzvvvvvvvvvvz
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
Download as pdf or txt
0% found this document useful (0 votes)
7 views13 pages

DBMS Introduction

xcvzvvvvvvvvvvz
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
Download as pdf or txt
Download as pdf or txt
You are on page 1/ 13

1.

1 Database Management Systems

A Database Management System (DBMS) is a set of computer programs that controls the creation,
maintenance, and the use of a database. It allows organizations to place control of database development
in the hands of database administrators (DBAs) and other specialists. A DBMS is a system software
package that helps the use of integrated collection of data records and files known as databases. It allows
different user application programs to easily access the same database.

A database management system is a suite of software applications that together make it possible for
people or businesses to store, modify, and extract information from a database. Sound like something
found only in bank vaults? It's not. You can find database management systems many places in your
everyday life.

A collection of programs that enables you to store, modify, and extract information from a database.
There are many different types of DBMSs, ranging from small systems that run on personal computers to
huge systems that run on mainframes.

The following are examples of database applications:


 Computerized library systems
 Automated teller machines
 Flight reservation systems
 Computerized parts inventory systems

Some of the DBMS Software are:


 Oracle
 MS SQL Server
 MS Access

1.2 Purpose of Database Systems

DBMS is used to overcome the problems caused due to the file-processing approach.
The DBMS (Database Management System) is preferred ever the conventional file processing system due
to the following advantages:

1. Controlling Data Redundancy


In the conventional file processing system, every user group maintains its own files for handling its data
files. This may lead to
• Duplication of same data in different files.
• Wastage of storage space, since duplicated data is stored.
• Errors may be generated due to updating of the same data in different files.
• Time in entering data again and again is wasted.
• Computer Resources are needlessly used.
• It is very difficult to combine information.

2. Elimination of Inconsistency
In the file processing system information is duplicated throughout the system. So changes made in one
file may be necessary be carried over to another file. This may lead to inconsistent data. So we need to

Chapter1 - DBMS Fundamentals: 1


remove this duplication of data in multiple file to eliminate inconsistency.

3. Better service to the users


A DBMS is often used to provide better services to the users. In conventional system, availability of
information is often poor, since it normally difficult to obtain information that the existing systems were
not designed for. Once several conventional systems are combined to form one centralized database, the
availability of information and its update is likely to improve since the data can now be shared and DBMS
makes it easy to respond to anticipated information requests.

4. Flexibility of the System is improved


Since changes are often necessary to the contents of the data stored in any system, these changes are made
more easily in a centralized database than in a conventional system. Applications programs need not to be
changed on changing the data in the database.

5. Integrity can be improved


Since data of the organization using database approach is centralized and would be used by a number of
users at a time. It is essential to enforce integrity-constraints.
In the conventional systems because the data is duplicated in multiple files so updating or changes may
sometimes lead to entry of incorrect data in some files where it exists.

6. Standards can be enforced


Since all access to the database must be through DBMS, so standards are easier to enforce. Standards may
relate to the naming of data, format of data, structure of the data etc. Standardizing stored data formats is
usually desirable for the purpose of data interchange or migration between systems.

7. Security can be improved


In conventional systems; applications are developed in an ad-hoc /temporary manner. Often different
system of an organization would access different components of the operational data, in such an
environment enforcing security can be quiet difficult. Setting up of a database makes it easier to enforce
security restrictions since data is now centralized. It is easier to control that has access to what parts of the
database. Different checks can be established for each type of access (retrieve, modify, delete etc.) to each
piece of information in the database.

8. Organization's requirement can be identified


All organizations have sections and departments and each of these units often consider the work of their
unit as the most important and therefore consider their need as the most important. Once a database has
been setup with centralized control, it will be necessary to identify organization's requirement and to
balance the needs of the competing units. So it may become necessary to ignore some requests for
information if they conflict with higher priority need of the organization.
It is the responsibility of the DBA (Database Administrator) to structure the database system to provide
the overall service that is best for an organization.

9. Overall cost of developing and maintaining systems is lower


It is much easier to respond to unanticipated requests when data is centralized in a database than when it
is stored in a conventional file system. Although the initial cost of setting up of a database can be large,
one normal expects the overall cost of setting up of a database, developing and maintaining application
programs to be far lower than for similar service using conventional systems, Since the productivity of
programmers can be higher in using non-procedural languages that have been developed with DBMS than
using procedural languages.

Chapter1 - DBMS Fundamentals: 2


10. Data Model must be developed
Perhaps the most important advantage of setting up of database system is the requirement that an overall
data model for an organization be build. In conventional systems, it is more likely that files will be
designed as per need of particular applications demand. The overall view is often not considered.
Building an overall view of an organization's data is usual cost effective in the long terms.

11. Provides backup and Recovery


Centralizing a database provides the schemes such as recovery and backups from the failures including
disk crash, power failures, software errors which may help the database to recover from the inconsistent
state to the state that existed prior to the occurrence of the failure, though methods are very complex.

Other Advantages of DBMS Software:

Warehouse of Information
The database management systems are warehouses of information, where large amount of data can be
stored. The common examples in commercial applications are inventory data, personnel data, etc. It often
happens that a common man uses a database management system, without even realizing, that it is being
used. The best examples for the same, would be the address book of a cell phone, digital diaries, etc. Both
these equipments store data in their internal database.

Defining Attributes
The unique data field in a table is assigned a primary key. The primary key helps in the identification of
data. It also checks for duplicates within the same table, thereby reducing data redundancy. There are
tables, which have a secondary key in addition to the primary key. The secondary key is also called
'foreign key'. The secondary key refers to the primary key of another table, thus establishing a relationship
between the two tables.

Systematic Storage
The data is stored in the form of tables. The tables consists of rows and columns. The primary and
secondary key help to eliminate data redundancy, enabling systematic storage of data.

Changes to Schema
The table schema can be changed and it is not platform dependent. Therefore, the tables in the system can
be edited to add new columns and rows without hampering the applications, that depend on that particular
database.

No Language Dependence
The database management systems are not language dependent. Therefore, they can be used with various
languages and on various platforms.

Table Joins
The data in two or more tables can be integrated into a single table. This enables to reduce the size of the
database and also helps in easy retrieval of data.

Multiple Simultaneous Usage


The database can be used simultaneously by a number of users. Various users can retrieve the same data
simultaneously. The data in the database can also be modified, based on the privileges assigned to users.

Data Security
Data is the most important asset. Therefore, there is a need for data security. Database management
Chapter1 - DBMS Fundamentals: 3
systems help to keep the data secured.

Privileges
Different privileges can be given to different users. For example, some users can edit the database, but are
not allowed to delete the contents of the database.

Abstract View of Data and Easy Retrieval


DBMS enables easy and convenient retrieval of data. A database user can view only the abstract form of
data; the complexities of the internal structure of the database are hidden from him. The data fetched is in
user friendly format.

Data Consistency
Data consistency ensures a consistent view of data to every user. It includes the accuracy, validity and
integrity of related data. The data in the database must satisfy certain consistency constraints, for
example, the age of a candidate appearing for an exam should be of number datatype and in the range of
20-25. When the database is updated, these constraints are checked by the database systems.

1.3 Data Abstraction

The major purpose of a database system is to provide users with an abstract view of the system.
The system hides certain details of how data is stored and created and maintained. Complexity should be
hidden from database users.

There are several levels of abstraction:

 Physical Level:
How the data are stored.
E.g. index, B-tree, hashing.
Lowest level of abstraction.
Complex low-level structures described in detail.

 Conceptual Level:
Next highest level of abstraction.
Describes what data are stored.
Describes the relationships among data.
Database administrator level.

 View Level:
Highest level.
Describes part of the database for a particular group of users.
Can be many different views of a database.
E.g. tellers in a bank get a view of customer accounts, but not of payroll data.
Fig. 1.1 (figure 1.1 in the text) illustrates the three levels.

Chapter1 - DBMS Fundamentals: 4


Figure 1.1: The three levels of data abstraction

1.4 Data Models

Data models are a collection of conceptual tools for describing data, data relationships, and data
semantics and data constraints.
A data model in software engineering is an abstract model that describes how data are represented and
accessed. Data models formally define data elements and relationships among data elements for a
domain of interest.

i. Physical Data Model


A physical data model (a.k.a. database design) is a representation of a data design which takes into
account the facilities and constraints of a given database management system. In the lifecycle of a project
it is typically derived from a logical data model, though it may be reverse-engineered from a given
database implementation. A complete physical data model will include all the database artifacts required
to create relationships between tables or achieve performance goals, such as indexes, constraint
definitions, linking tables, partitioned tables or clusters. The physical data model can usually be used to
calculate storage estimates and may include specific storage allocation details for a given database
system.

ii.File-System based model


A flat file database describes any of various means to encode a database model (most commonly a table)
as a singular file (such as .txt or .ini). A "flat file" is a plain text or mixed text and binary file which
usually contains one record per line[2] or 'physical' record (example on disc or tape). Within such a
record, the single fields can be separated by delimiters, e.g. commas, or have a fixed length. In the latter
case, padding may be needed to achieve this length. Extra formatting may be needed to avoid delimiter
collision. There are no structural relationships between the records.

iii. Hierarchical Data Model


A hierarchical data model is a data model in which the data is organized into a tree-like structure. The
structure allows repeating information using parent/child relationships: each parent can have many

Chapter1 - DBMS Fundamentals: 5


children but each child only has one parent. All attributes of a specific record are listed under an entity
type.
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. These record types are the equivalent of tables in
the relational model, and with the individual records being the equivalent of rows. To create links
between these record types, the hierarchical model uses Parent Child Relationships. These are a 1:N
mapping between record types. This is done by using trees, like set theory used in the relational model,
"borrowed" from math. For example, an organization might store information about an employee, such as
name, employee number, department, salary. The organization might also store information about an
employee's children, such as name and date of birth. The employee and children data forms a hierarchy,
where the employee data represents the parent segment and the children data represents the child segment.
If an employee has three children, then there would be three child segments associated with one employee
segment. In a hierarchical database the parent-child relationship is one too many. This restricts a child
segment to having only one parent segment.

iv. Network Data Model


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 popularity of the network data model coincided with the popularity of the hierarchical data model.
Some data were more naturally modeled with more than one parent per child. So, the network model
permitted the modeling of many-to-many relationships in data. The basic data modeling construct in the
network model is the set construct. A set consists of an owner record type, a set name, and a member
record type. A member record type can have that role in more than one set; hence the multi-parent
concept is supported. An owner record type can also be a member or owner in another set. The data
model is a simple network, and link and intersection record types (called junction records by IDMS) may
exist, as well as sets between them. Thus, the complete network of relationships is represented by several
pair wise sets; in each set some (one) record type is owner (at the tail of the network arrow) and one or
more record types are members (at the head of the relationship arrow). Usually, a set defines a 1:M
relationship, although 1:1 is permitted.

v. E-R Data Model


The E-R (entity-relationship) data model views the real world as a set of basic objects (entities) and
relationships among these objects. It is a way of graphically representing the logical relationships of
entities (or objects) in order to create a database. In ER modeling, the structure for a database is portrayed
as a diagram, called an entity-relationship diagram (or ER diagram), that resembles the graphical
breakdown of a sentence into its grammatical parts.
An entity-relationship model (ERM) is an abstract and conceptual representation of data. Entity-
relationship modeling is a database modeling method, used to produce a type of conceptual schema or
semantic data model of a system, often a relational database, and its requirements in a top-down fashion.
Diagrams created by this process are called entity-relationship diagrams, ER diagrams, or ERDs.

vi. Relational Model


The Relational Model is a clean and simple model that uses the concept of a relation using a table rather
than a graph or shapes. The information is put into a grid like structure that consists of columns running
up and down and rows that run from left to right, this is where information can be categorized and sorted.
A relational database consists of a collection of tables, each having a unique name. A row in a table
represents a relationship among a set of values. Thus a table represents a collection of relationships.
Chapter1 - DBMS Fundamentals: 6
There is a direct correspondence between the concept of a table and the mathematical concept of a
relation. A substantial theory has been developed for relational databases.
(RDBMS - relational database management system) A database based on the relational model developed
by E.F. Codd. A relational database allows the definition of data structures, storage and retrieval
operations and integrity constraints. In such a database the data and relations between them are organized
in tables. A table is a collection of records and each record in a table contains the same fields.

vii. Object-Oriented data Model


Object DBMSs add database functionality to object programming languages. They bring much more than
persistent storage of programming language objects. Object DBMSs extend the semantics of the C++,
Smalltalk and Java object programming languages to provide full-featured database programming
capability, while retaining native language compatibility. A major benefit of this approach is the
unification of the application and database development into a seamless data model and language
environment. As a result, applications require less code, use more natural data modeling, and code bases
are easier to maintain. Object developers can write complete database applications with a modest amount
of additional effort.

According to Rao (1994), "The object-oriented database (OODB) paradigm is the combination of object-
oriented programming language (OOPL) systems and persistent systems. The power of the OODB comes
from the seamless treatment of both persistent data, as found in databases, and transient data, as found in
executing programs."

In contrast to a relational DBMS where a complex data structure must be flattened out to fit into tables or
joined together from those tables to form the in-memory structure, object DBMSs have no performance
overhead to store or retrieve a web or hierarchy of interrelated objects. This one-to-one mapping of object
programming language objects to database objects has two benefits over other storage approaches: it
provides higher performance management of objects, and it enables better management of the complex
interrelationships between objects. This makes object DBMSs better suited to support applications such
as financial portfolio risk analysis systems, telecommunications service applications, World Wide Web
document structures, design and manufacturing systems, and hospital patient record systems, which have
complex relationships between data.

viii. Object / Relational Model


Object/relational database management systems (ORDBMSs) add new object storage capabilities to the
relational systems at the core of modern information systems. These new facilities integrate management
of traditional fielded data, complex objects such as time-series and geospatial data and diverse binary
media such as audio, video, images, and applets. By encapsulating methods with data structures, an
ORDBMS server can execute complex analytical and data manipulation operations to search and
transform multimedia and other complex objects.
As an evolutionary technology, the object/relational (OR) approach has inherited the robust transaction-
and performance-management features of it s relational ancestor and the flexibility of its object-oriented
cousin. Database designers can work with familiar tabular structures and data definition languages
(DDLs) while assimilating new object-management possibilities. Query and procedural languages and
call interfaces in ORDBMSs are familiar: SQL3, vendor procedural languages, and ODBC, JDBC, and
proprietary call interfaces are all extensions of RDBMS languages and interfaces. And the leading
vendors are, of course, quite well known: IBM, Inform ix, and Oracle.

ix. Semi-Structured Data Model


In semi structured data model, the information that is normally associated with a schema is contained
within the data, which is sometimes called ``self-describing''. In such database there is no clear separation
Chapter1 - DBMS Fundamentals: 7
between the data and the schema, and the degree to which it is structured depends on the application. In
some forms of semi structured data there is no separate schema, in others it exists but only places loose
constraints on the data. Semi-structured data is naturally modeled in terms of graphs which contain labels
which give semantics to its underlying structure. Such databases subsume the modeling power of recent
extensions of flat relational databases, to nested databases which allow the nesting (or encapsulation) of
entities, and to object databases which, in addition, allow cyclic references between objects.
Semi structured data has recently emerged as an important topic of study for a variety of reasons. First,
there are data sources such as the Web, which we would like to treat as databases but which cannot be
constrained by a schema. Second, it may be desirable to have an extremely flexible format for data
exchange between disparate databases. Third, even when dealing with structured data, it may be helpful to
view it as semi structured for the purposes of browsing.

x. Associative Model
The associative model divides the real-world things about which data is to be recorded into two sorts:
Entities are things that have discrete, independent existence. An entity’s existence does not depend on any
other thing. Associations are things whose existence depends on one or more other things, such that if any
of those things ceases to exist, then the thing itself ceases to exist or becomes meaningless.
An associative database comprises two data structures:
1. A set of items, each of which has a unique identifier, a name and a type.
2. A set of links, each of which has a unique identifier, together with the unique identifiers of three other
things, which represent the source, verb and target of a fact that is recorded about the source in the
database. Each of the three things identified by the source, verb and target may be either a link or an item.

xi. Entity-Attribute-Value (EAV) Data Model


The best way to understand the rationale of EAV design is to understand row modeling (of which EAV is
a generalized form). Consider a supermarket database that must manage thousands of products and
brands, many of which have a transitory existence. Here, it is intuitively obvious that product names
should not be hard-coded as names of columns in tables. Instead, one stores product descriptions in a
Products table: purchases/sales of individual items are recorded in other tables as separate rows with a
product ID referencing this table. Conceptually an EAV design involves a single table with three
columns, an entity (such as an olfactory receptor ID), an attribute (such as species, which is actually a
pointer into the metadata table) and a value for the attribute (e.g., rat). In EAV design, one row stores a
single fact. In a conventional table that has one column per attribute, by contrast, one row stores a set of
facts. EAV design is appropriate when the number of parameters that potentially apply to an entity is
vastly more than those that actually apply to an individual entity.

xii. Context Data Model


The context data model combines features of all the above models. It can be considered as a collection of
object-oriented, network and semi structured models or as some kind of object database. In other words
this is a flexible model; you can use any type of database structure depending on task. Such data model
has been implemented in DBMS Context.
The fundamental unit of information storage of Context is a CLASS. Class contains METHODS and
describes OBJECT. The Object contains FIELDS and PROPERTY. The field may be composite; in this
case the field contains Subfields etc. The property is a set of fields that belongs to particular Object.
(similar to AVL database). In other words, fields are permanent part of Object but Property is its variable
part. The header of Class contains the definition of the internal structure of the Object, which includes the
description of each field, such as their type, length, attributes and name. Context data model has a set of
predefined types as well as user defined types. The predefined types include not only character strings,
texts and digits but also pointers (references) and aggregate types (structures).

Chapter1 - DBMS Fundamentals: 8


Instances and Schemas

Database Instance
The term instance is typically used to describe a complete database environment, including the RDBMS
software, table structure, stored procedures and other functionality. It is most commonly used when
administrators describe multiple instances of the same database. The information in a database at a
particular point in time is called an instance of the database.

Database Schema
Database schema is a description of the structure of a database or a directory (file systems).
There are 3 kind of schemas in Databases -
* conceptual schema which is a map of concepts and their relationships
* logical schema which is a map of entities and their attributes and relations
* physical schema which is a particular implementation of a logical schema

Analogy with programming languages:


 Data type definition - scheme
 Value of a variable - instance

1.5 Data Independence

The ability to modify a scheme definition in one level without affecting a scheme definition in a higher
level is called data independence.
There are two kinds:

 Physical data independence


The ability to modify the physical scheme without causing application programs to be rewritten
Modifications at this level are usually to improve performance

 Logical data independence


The ability to modify the conceptual scheme 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.

1.6 Database Administrator


A database administrator (DBA) is a person responsible for the design, implementation, maintenance and
repair of an organization's database. The role includes the development and design of database strategies,
monitoring and improving database performance and capacity, and planning for future expansion
requirements. They may also plan, co-ordinate and implement security measures to safeguard the
database.
A database administrator (DBA) directs or performs all activities related to maintaining a successful
database environment. Responsibilities include designing, implementing, and maintaining the database
system; establishing policies and procedures pertaining to the management, security, maintenance, and
use of the database management system; and training employees in database management and use.

Chapter1 - DBMS Fundamentals: 9


Roles of DBA:

 Scheme definition: the creation of the original database scheme. This involves writing a set
of definitions in a DDL (data storage and definition language), compiled by the DDL
compiler into a set of tables stored in the data dictionary.
 Storage structure and access method definition: writing a set of definitions translated by
the data storage and definition language compiler
 Scheme and physical organization modification: writing a set of definitions used by the
DDL compiler to generate modifications to appropriate internal system tables (e.g. data
dictionary). This is done rarely, but sometimes the database scheme or physical organization
must be modified.
 Granting of authorization for data access: granting different types of authorization for data
access to various users
 Integrity constraint specification: generating integrity constraints. These are consulted by
the database manager module whenever updates occur.

Elaborated Roles of DBA:


 establishing the needs of users and monitoring user access and security;
 monitoring performance and managing parameters to provide fast query responses to front-end users;
 mapping out the conceptual design for a planned database in outline;
 considering both back-end organization of data and front-end accessibility for end-users;
 refining the logical design so that it can be translated into a specific data model;
 further refining the physical design to meet system storage requirements;
 installing and testing new versions of the database management system (DBMS);
 maintaining data standards, including adherence to the Data Protection Act;
 writing database documentation, including data standards, procedures and definitions for the data
dictionary (metadata);
 controlling access permissions and privileges;
 developing, managing and testing back-up and recovery plans;
 ensuring that storage, archiving, back-up and recovery procedures are functioning correctly;
 capacity planning;
 working closely with IT project managers, database programmers and web developers;
 communicating regularly with technical, applications and operational staff to ensure database
integrity and security;
 Commissioning and installing new applications and customizing existing applications in order to
make them fit for purpose.

1.7 Database Users


Database Users are the people who are authorized to use the Database for a purpose. They can query a
database and/or update it depending upon their privileges.
Database Users include:
 DBAs
 DB Designers / Developers
 Systems Analysts / SW Engineers
 End Users

Chapter1 - DBMS Fundamentals: 10


Types of Database Users:

 Application programmers are computer professionals interacting with the system


through DML calls embedded in a program written in a host language (e.g. C, PL/1,
Pascal).
o These programs are called application programs.
o The DML precompiler converts DML calls (prefaced by a special character like
$, #, etc.) to normal procedure calls in a host language.
o The host language compiler then generates the object code.
o Some special types of programming languages combine Pascal-like control
structures with control structures for the manipulation of a database.
o These are sometimes called fourth-generation languages.
o They often include features to help generate forms and display data.
 Sophisticated users interact with the system without writing programs.
o They form requests by writing queries in a database query language.
o These are submitted to a query processor that breaks a DML statement down
into instructions for the database manager module.
 Specialized users are sophisticated users writing special database application programs.
These may be CADD systems, knowledge-based and expert systems, complex data
systems (audio/video), etc.
 Naive users are unsophisticated users who interact with the system by using permanent
application programs (e.g. automated teller machine).

1.8 Application Architecture


Application architecture is the organizational design of an entire software application, including all sub-
components and external applications interchanges. There are several design patterns that are used to
define application architecture. These patterns help to communicate how an application will complete the
necessary business processes as defined in the system requirements.

1-Tier Architecture
It is a simple form of standalone application architecture where everything resides in a single program. -
Tier Architecture is the simplest, single tier on single user, and is the equivalent of running an application
on a personal computer. The entire required components to run the application are located within it. User
interface, business logic, and data storage are all located on the same machine. They are the easiest to
design, but the least scalable. Because they are not part of a network, they are useless for designing web
applications.

2-Tier Architecture
2-Tier Architectures supply a basic network between a client and a server. For example, the basic web
model is a 2-Tier Architecture. A web browser makes a request from a web server, which then processes
the request and returns the desired response, in this case, web pages. This approach improves scalability
and divides the user interface from the data layers. However, it does not divide application layers so they
can be utilized separately. This makes them difficult to update and not specialized. The entire application
must be updated because layers aren’t separated.

Chapter1 - DBMS Fundamentals: 11


3-Tier Architecture
3-Tier Architecture is most commonly used to build web applications. In this model, the browser acts like
a client, middleware or an application server contains the business logic, and database servers handle data
functions. This approach separates business logic from display and data. But, it does not specialize
functional layers. Its fine for prototypical or very simple web applications, but it doesn’t measure up to
the complexity demanded of web applications. The application server is still too broad, with too many
functions grouped together. This reduces flexibility and scalability.

N-Tier Architecture
Usually N-Tier Architecture begins as a 3-Tier model and is expanded. It provides finer granularity.
Granularity is the ability of a system, in this case, an application, to be broken down into smaller
components or granules. The finer the granularity, the greater is the flexibility of a system. It can also be
referred to as a system’s modularity. Therefore, it refers to the pulling apart of an application into separate
layers or finer grains.
N-Tier (Multi-Tier) architecture is a client-server architecture in which, the presentation, the application
processing and the data management are logically separate processes. For example, an application that
uses middleware to service data requests between a user and a database employs multi-tier architecture.
The most widespread use of "multi-tier architecture" refers to three-tier architecture.

1.9 Overall Database System Structure and Components

Database systems are partitioned into modules for different functions. Some functions (e.g. file systems)
may be provided by the operating system.

Components include:

 File manager manages allocation of disk space and data structures used to represent information
on disk.
 Database manager: The interface between low-level data and application programs and queries.
 Query processor translates statements in a query language into low-level instructions the
database manager understands. (May also attempt to find an equivalent but more efficient form.)
 DML precompiler converts DML statements embedded in an application program to normal
procedure calls in a host language. The precompiler interacts with the query processor.
 DDL compiler converts DDL statements to a set of tables containing metadata stored in a data
dictionary.

In addition, several data structures are required for physical system implementation:

 Data files: store the database itself.


 Data dictionary: stores information about the structure of the database. It is used heavily. Great
emphasis should be placed on developing a good design and efficient implementation of the
dictionary.
 Indices: provide fast access to data items holding particular values.

Chapter1 - DBMS Fundamentals: 12


Figure 1.6: Database system structure

Chapter1 - DBMS Fundamentals: 13

You might also like