Components of Database
Management Systems Software (6
Components) | DBMS
By Saritha Pujari Database
Some of the most important functional components of
database management systems software are as follows:
At the core of the database approach, lie the database management
systems (DBMS). DBMS is the software that is responsible for
managing the database. The management of a database includes
activities such as:
a. Organising data by defining the data elements and their interrelationships;
b. Updating the data by appending to the database;
c. Modifying the database by changing the values of various attributes in the database;
d. Providing access to the database by satisfying the queries of users
in the forms in which the user needs the information and
e. Exercising adequate control over the flow of data to and from the
data base.
Thus, DBMS software creates, stores, updates, retrieves and selects
data for communication to the users in the format as specified by
them. The user of a database may be a human or a user program. In
addition, DBMS software, generally, has facilities for generating
applications. Thus, DBMS software should have programs to
perform a variety of functions. The functional components of DBMS
software are:
a. Data Definition Language
b. Data Manipulation Language
c. Query Language
d. Report Generator
e. Application Generator
f. User Interface
These components are represented in Fig. 9.1.
A brief introduction to the functional components of a
DBMS is presented in the following section:
(i) Data definition language:
Data definition language (DDL) is used to define the contents and
the structure of a database. These definitions are kept in the data
dictionary. The data dictionary or directory contains information of
the definition, structure and other characteristics of data in the
database.
The data dictionary defines the entities and the attributes that
describe these entities. It may also include information on reports
in which these attributes appear frequency of use, access
permissions, etc. Such information about the data is also termed as
meta-data.
A database can be viewed at the logical level, conceptual level, or
internal (physical) level. The logical level is the way the user views a
portion of the database that is required for the application on hand.
The conceptual level is the way the entire database is viewed by the
user. The internal or the physical view of the database is the way the
entire data is physically stored in the database. A manager is more
concerned with the conceptual view of database and need not
bother much about the physical view of databases. Figure 9.2 shows
different ‘view’ levels of a database.
The definition of the entire database is also called schema. The
definitions for a specific part of the database are collectively called
sub-schema. Thus, the Data Definition Level (DDL) is used to define
the schema and sub-schema in a database. Figure 9.3 shows the
statements from a data definition language for an application (thus
shows the sub-schema), giving the logical view of the database.
The data dictionary is helpful in ensuring that the user need not be
aware of the physical location of attributes in the database. If the
attribute is defined in the data dictionary, it can be referred to by
the name given to it in the dictionary. The DBMS automatically
locates the data on the attribute and passes it on to the user.
(ii) Data manipulation language:
The data manipulation language (DML) is a set of procedural
commands that enable programmers to append, modify, update and
retrieve data. It has other facilities for data manipulation such as
sorting, indexing, etc. The DML uses simple verbs such as Delete,
Sort, Insert, Select, Display, Add, etc. as commands for
manipulation of data.
(iii) Query language:
A Query language is user oriented. It enables the user of the
database to make ad-hoc queries from the database using simple
words from a natural language like English. It is, in a way, similar to
DML but offers more commands for retrieval of information.
The commands of the query language have been standardised by the
American National Standards Institute (ANSI). A set of these
standard commands is called Structured Query language (SQL).
Using SQL, a user can make any query from a database using
powerful commands like SELECT, PROJECT and JOIN. In fact,
these three commands form the core of SQL.
(iv) Report generators:
The requirements for generation of reports from the database are
different in different applications. In the report, data may be
represented using the graphs, pictures, maps and other forms that
can help in improving comprehension.
Modern DBMS packages offer facilities for creating reports in the
formats using special report generating programs. These programs
can not only access the data from a database, but also offer a host of
graphic facilities. These facilities include the picture library from
where pictures and other graphics can be picked up, remodelled and
incorporated in the report.
(v) Application generators:
Most of the DBMS packages include programming facilities
available in the Fourth Generation Languages (4GLs). These
languages have limited but very powerful commands that are useful
for developing applications.
The popularity of 4GLs as programming languages is primarily in
the small, adhoc applications. These applications are developed by
users themselves to meet their minor data processing needs. They
have also been used by IT professionals for prototyping various
components of an application.
(vi) User interface:
The user interface is a shell that provides the environment for
interaction of a user with the database. The user interface, in the
modern DBMS packages is quite user friendly and makes use of
graphic icons to identify the operations. The user can click on these
icons to perform various operations.
Models of Database Architecture:
Hierarchical, Network and
Relational Models
by Saritha Pujari Database
Advertisements:
Some of the board models of database architecture are as
follows:
The process of defining the conceptual design of data elements and
their inter-relationships is called data modeling. The traditional
applications approach to data organisation built different models
for each data file.
Image Courtesy : ysma.gr/static/images/6_4_DBinput.jpg
Such a diversity of ways in which different data elements are linked
and stored in data files make these files suitable only for the
applications that they were originally created for. In fact, the details
regarding the exact placement of different data elements in a file
have to be documented very carefully.
Any change in the order in which various data elements are placed
results in changes in the application programs using the data file.
The database approach uses a common data model for the entire
database and the user program is not concerned with the placement
of a particular data element. The database management system
(DBMS) acts as an interface between the database and the user
programs.
The DBMS fetches the data from the database and makes it available to the user program. This feature offers the advantage of data
independence in the database approach.
Conceptually, there are three broad options with regard to
database models. These are:
a. Hierarchical model
b. Network model
c. Relational model
(a) Hierarchical model:
This model presents data to users in a hierarchy of data elements
that can be represented in a sort of inverted tree. In a sales order
processing system, a customer may have many invoices raised to
him and each invoice may have different data elements. Thus, the
root level of data is customer, the second level is invoice and the last
level is line items such as invoice number, date, product, quantity,
etc.
This structure is quite natural when seen from the event point of
view. However, the lower levels are owned by higher level data
elements, and elements at the same level have no linkage at all. As a
result, the query such as what products are purchased by which
customer, in the above example, shall be difficult to carry out in the
hierarchical structure.
The query as to which customer purchased which product would be
convenient. Thus, where there are many-to-many relationships
between two entities, this model would not be appropriate. Figure
9.4 shows the hierarchical model of data for a sales order processing
application.
(b) Network model:
In the network model of database, there are no levels and a record
can have any number of owners and also can have ownership of
several records. Thus, the problem raised above in the sales order
processing will not arise in the network model.
As there is no definite path defined for retrieval of data, the number
of links is very large and thus network databases are complex, slow
and difficult to implement. In view of the difficulty in
implementation, network model is used only when all other options
are closed.
The typical example of a network database may be the employee
and the department he/she has worked or can work with in future.
Figure 9.5 shows the network model of data for an employee
information system.
(c) Relational model:
The most recent and popular model of database design is the
relational database model. This model was developed to overcome
the problems of complexity and inflexibility of the earlier two
models in handling databases with many-to-many relationships
between entities.
These models are not only simple but also powerful. In the
relational database, each file is perceived as a flat file (a two
dimensional table) consisting of many lines (records), each record
having key and non-key data item(s). The key item(s) is the data
element(s) that identifies the record. Figure 9.6 shows the files, and
the fields that each record shall have in a customer invoicing
system.
In these files, the key data items are customer id, invoice no, and
product code. Each of the files can be used separately to generate
reports. However, data can also be obtained from any combination
of files as all these files are related to each other with the help of key
data items specified above.
This is the fundamental advantage of the relational model of
database along with its simplicity and the robustness.
The relational model draws greatly on the work of E.F.
Codd who identifies features of a good relational database
as following:
a) All information is logically represented as tables and the access of
data are possible by the names of fields. Thus, the order, position or
file linkage is not a matter of concern for users.
b) The data dictionary has information regarding the database
structure including the data type; size, etc., definitions, relationships and access permissions. The authorised users can learn about
the database environment and change the environment using the
data description language (DDL).
c) A data manipulation language (DML) is available to users including programmers for creation, insertion, modification, retrieval,
organising and deletions of any part of the database. These manipulations are possible at the record level as well as for the whole
file, giving the flexibility in defining access permissions for various
categories of users.
d) Any modification in the structure of database in terms of splitting
the table horizontally or vertically should not have any impact on
the logic of the program using the database. This data independence
is the core advantage of the relational model of database.
e) The distributed independence of data is another feature of a good
relational database. The user programs do not require any change
when data are first distributed or redistributed. The actual physical
location of data does not matter to the user so long as that field
appears in the data dictionary as local.
As may be noted from Fig. 9.6, none of the fields is common in any
two files except the key item. So, the data redundancy can be
avoided in this model. For this purpose, a process of data
normalisation is undertaken while designing the structure of a
database.