UNIT I | MODULE 1: FUNDAMENTAL DATABASE CONCEPTS

UNIT I | MODULE 1: FUNDAMENTAL DATABASE CONCEPTS

Instructions to the learner

This module consists of:

• Learning Objectives – a list of milestones to be achieved in every lesson. This is an effective

way to make sure that the path to learning has been achieved;

• Pre – Test/Post – Test – a set of questions administered prior to and after every lesson in
increasing the students’ knowledge of content;

• Learning Discussion – topics are presented according to the objectives to be attained in every
lesson;

• Self – Assessment Questions – activities for the lesson to enhance the problem and critical
thinking skills of the students. This allows them to explore various solutions to real – life
situations; and

• Learning Summary – an idea of the topics given in each lesson. At a glance, the students will
be able to recall the main points covered in the lesson.
 UNIT I | MODULE 1: FUNDAMENTAL DATABASE CONCEPTS

Learning Objectives:
At the end of this module, you will be able to:

Define common database terms such as database, database management system, record and
field; (LO1 → CO1)

Identify the most common problem areas dealt with in the database design; and (LO2 → CO1)

Define the three conceptual levels used in database definition and design. (LO3 → CO1)
 UNIT I | MODULE 1: FUNDAMENTAL DATABASE CONCEPTS

Learning Discussion and Activities:

Ever since computers have existed, they have been used to store and process information.
Everything we do with computers today, every application, relies on the computer’s ability both to store
huge amounts of data, and to execute arithmetic, financial and other types of operations that data in
order to produce useful information.

In this module, we’ll go over some concepts commonly used when discussing database and database
design.

Databases

A database, in computer terms, is a collection of data, typically data about one specific enterprise.
Stricly speaking, a database does not have to be stored in a computer; employee records stored in a
filing cabinet would qualify as a database, for example.

A computer or set of computers upon which programs to access the database can run A DBMS can be
as simple as a list of phone numbers of your friend stored in a personal computer, or it can be as
complex as a system un by a company that handles inventory, billing, ordering, and payroll for its
wordlwide operations.

A DBMS should provide a convenient and efficient interface for both storing and retrieving data, as well
as for extracting useful information from the database. Due to the importance of database to most
organizations in general, the study and development of techniques for efficient DBMS is a major field of
information technology.

Self – Assessment Question 1.1

List five tasks around your workplace, home, or school which could be done faster or more
efficiently with the help of a DBMS.

Fundamental Database Systems Concepts

 UNIT I | MODULE 1: FUNDAMENTAL DATABASE CONCEPTS

Let’s say a business (like a grocery store) wants to make use of computers to keep track of its inventory
and supply functions. A list of supplies (and their addresses and phone numbers is typed into a file, as
well as a list of items which those supplies sell, including the price of each item, which particular
supplier carries it, and how much it weighs (for shipping and handling costs). The company would also
want to keep track of how many of each item they have in stock, and which items have run out and
have to be reordered.

Each item on lists such as these is commonly referred to as a record. One record may hold information
on pertaining to one supplier, or one item. Thus, a database of suppliers stored on a computer is stored
in a set or list of record, one after the other.

A record, on closer examination, is composed of several sub components, referred to as fields. Each
field hold as a single value or datum of the record. For a record holding information about a supplier, for
example, we can have one field for the supplier’s company name, another for his telephone number,
and yet another for his address. You might think of a record as a set of boxes for holding information,
each box holding a single field. For example:

Our database would be composed of lists of records with all records in one list having the same fields
for example:

And so on,

We now have a way of storing data on the computer, once data are stored however, we need some
way of extracting it in some useful form.

Returning to our example, the grocery store would then have a collection of small application programs,
perhaps written by the company programmer, that:

• Adds new item to the inventory, whenever a supplier makes a delivery;

• Deletes items from the inventory, whenever items are sold;
• Adds and deletes types of items, when the store decides to carry new brands or when some
items are no longer available;
• Changes prices of items, whenever the suppliers price change;
• Changes supplier information for an item, when suppliers stop carrying a certain brand, for
example, or when they start selling new ones;
• Prints total purchases of every type of item, when the store manager wants to see how many of
some type of item have been bought or sold; or which items have been selling more; and
• Print out graphs of sales per day, month or year, for when the manager has to go out an do a
presentation for the store owners or prospective suppliers.

And so on, this rather unwieldy collection is a standard file-processing system, in common use when
easy-to-use DBMSes were not widely available. Usually, such as DBMS has a design and structure
that was not well thought out beforehand; typically, more lists and programs are added onto the
systems as needs arise. In fact, some organizations still use their modern DBMS packages in this
manner. Such a system has severed major draw-backs:
 UNIT I | MODULE 1: FUNDAMENTAL DATABASE CONCEPTS

• Unplanned data redundancy and inconsistency. In such a system, the same piece of data
may be duplicated in several files. For example, the name of the supplier might be stored in the
list of suppliers, and in the list of items (to identify which suppliers carry which items). This may
result in wasted disk space and longer access time. But a worse problem would be keeping both
copies of the data consistent across all files. For example, a supplier marked as “Acme Inc.” in
the list of suppliers must also be marked as “Acme Inc.” in the list of items; a single error where
“Acme Ltd.” Was place instead it might cause that supplier to suddenly have no items for sale,
since the entry in the items list still reads “Acme Inc.” Also, any update to the supplier list must
necessitate a similar update to the items list.

• Isolating data. Writing application programs to retrieve and correlate data gathered from many
files would be difficult, especially if one wanted to watch out for the inconsistencies described
above. Also, if more than one programmer were working on the project, they would have to
agree on one format or (as is usually the case) the files may have to be converted to new
formats before they would work with a newer version of the system.

• Difficulty in accessing data. Requests not anticipated by the programmers would require
extra programming time, or would require the user to manually process the data on his/her own.
For example, if the store owner needed to see a list of suppliers who supplied vegetables, they
would either need to reclassify items to find out which items were ”vegetables”, then write an
application program to print the list, or they would print a list of suppliers and their items for sale,
and pick out the suppliers they wanted manually. This is neither efficient nor convenient for both
programmers and user.

• Security. Some functions of the systems should not be available to all users. For example, the
store manager might be the only one allowed to add new suppliers and items (to protect against
embezzlement by employees), the cashier might be allowed to remove items from inventory, the
stockroom may be allowed to add to inventory, and all other employees might only be able to
display the current inventory levels, but not to edit anything. Implementing this sort of security
scheme may be difficult, if not impossible, for systems.

• Data Ranges. The data stored may have pre-specified constraints on them-for example the
price of an Item must never be negative. The application programs must detect such impossible
values. Checking for these valid must be done by the application of the system, but updating
these ranges a later date (for example, if new postal regulations allow six-number zip codes,
instead of only 4-number ones) may involve more work than the company expected.

• Multiple Access. Larger database systems may be accessed at multiple terminals, and may
allow simultaneous updating of the data from our example, there may be a terminal at the
manager’s office, one at the cash register and other in the stockroom. If two users attempt to
update the same data at the same time, there must be some sort of arbitration routine that
checks that the data being inputted is still valid. Generally, this is a routine that allows user to
read a file at any given time, but allows more than one user to read a file at the same time. If the
application programs were not written with multi-user use in mind, it may require rewriting or
replacement of large parts of the old code.

Developments in database management systems have generally been in one or more these problem
areas.

Self – Assessment Question 1.2

Select one application from the list you wrote down for ASQ 1.1. What problems would you expect
to run into if you were tasked with creating a DBMS for it?
 UNIT I | MODULE 1: FUNDAMENTAL DATABASE CONCEPTS

Data Abstraction

One major purpose of a database management system (or any software system, for that matter) is to
make it easier for users to access and modify the data stored in the system. To this end, DBMSes
provide users with an abstracted view of the system, concealing certain “low-level” details of data
storage and maintenance. A store manager should not be expected to want to know how data date is
stored on the computer’s disk; he would want to know how to get the data in a usable form. Conversely,
a programmer seeking to make the data storage system more efficient might want to know exactly how
the data onto the disk.

When describing DBMSs, we have several levels of abstraction that describe how each class user of
programmer looks at the system.

• Physical level. This is the “nuts-and-bolts” view of the system, where the data structures and
file formats used by the system are described. This level is generally not visible to end users,
and is usually only used by the system programmers. Newer DBMSs even hide this level from
the application programmers, giving them only the conceptual view of the data.

• Conceptual level Here the user is given what data are actually stored in the system, and what
relationships they have with each other. This is the level used by the database administrator,
who is responsible for what information is allowed into the database.

• View level. Here only pan of the database is given to the user. Security considerations may
come into play here; a user view might allow someone to view a certain pan of the dataset, but
not to modify it. For example, an employee may look up on/her own salary rate, but he/she may
not be allowed to look up the salary rates of his/her boss, or co-workers. The view given to the
Head of Personnel, on the other hand, might not only allow the Head to view all salaries, but
even to modify them as he/she sees fit.

Each level is more general in its description than the one before it. Let’s say we have our inventory
database, one part of which is a list of items in inventory. Each item has the following data stored:

The name of the item

The retail price of the item
How many of this are currently in inventory

In a description of the database at the physical level (one which a systems programmer might use), we
may find how each piece of data is stored in memory and on disk. If the DBMS were written in Pascal,
for example, we may specify the item list to consists of a series of records, where each record is of the
form:
 UNIT I | MODULE 1: FUNDAMENTAL DATABASE CONCEPTS

type item = record

name = string [80]
price : real;
quantity : integer
end;

Here we see how many bytes each item stored would take up on disk or memory, what data types (for
this particular programming language) the programmer must use, and the range of valid values we can
store in the item list. We see that name is specified as a string of 80 characters. A user who finds that
he has to type in a longer name has to use abbreviations. Similarly, we see that quantity is stored as an
integer; therefore, we can never have negative values for quantity.

While this information may be quire useful for the programmer, most of it is not needed by the day-to-
day user of the system. The office manager or cashier would not be expected to know or even care
about how the data he or she is typing in is stored on disk; all they care about is that data can be
placed onto computer, and they can that data out again. Here we need a higher, more general picture
of the system, and here the conceptual views levels of abstraction comes in.

The database administrator (who in most cases is not the programmer, and might not have any
programming skills) must decide upon what data must go into the system and how each piece of data is
interrelated to each other. Taking our previous example further, the grocery store manager, who will
ultimately be the database administrator, knows that he has to store a database of items and a
database of suppliers, and somehow store sufficient data in the system for it to determine which
suppliers sell which item, and at which price. A description of the data at the conceptual level may only
contain descriptions of the data definitions, i.e., we can describe the two list above as:
items, which fields name. price and quantity
suppliers, with fields name, address and telephone number

Furthermore, we may have descriptions of how such list interrelate, such as ‘each supplier may carry
several items, and an item may be offered by many supplier’. These descriptions are dependent to a
large part on the data model (see Module 2) used by the DBMS designer.

The view level is much like the conceptual level, except that some parts of the database is visible. A
specific view is created for every class of user of the system. These classes are usually assigned on
the basis of security, or how much of the database a given user is allowed to access.

From our example. The view given to the grocery store manager would include all the databases we’ve
enumerated. The view granted to the cashier might only include the items database and the inventory
levels database he/she does not need to see the list of suppliers. The view granted to the stockroom
chief, however, requires the list of suppliers, if he/she is in charge or ordering new items for the store.

Self – Assessment Question 1.3

Write sample records and fields for the application you described in SAQ 1.1 and 1.2. How would
these records appear in a document describing the database at the physical level? The conceptual
level?
 UNIT I | MODULE 1: FUNDAMENTAL DATABASE CONCEPTS

Self – Assessment Question 1.3 continuation…

Learning Summary:

A database is a collection of data pertaining to one entity. A database management system (DBMS) is
a collection of related databases, and the software required to access those databases in useful
manner. Designing proper DBMSs requires attention to several problem areas, such as data
redundancy and inconsistency, data isolation, difficulty in data access, security, valid data ranges and
multiple access.

There are three levels of abstraction we can use when describing a DBMS. The physical level pertains
to the low-level structure and routine required by the database, such as those required by a system
programmer. The conceptual level deals with the different databases that make up the system, and the
relationship they have with each other. This is typically the level at which database administrator works.
The view level describes different “views” or proportions of the DBMS which are accessible to a specific
class of user. Different user may have different view of the data, depending on their needs and
privileges.

References:

Silberschatz, A. Et. Al. (2019). Database System Concepts, Seventh Edition. McGraw-Hill.

Chakrabarti, R. Et. Al. (2014). Advanced Database Management System. Dreamtech Press.

Alviar, U. G. Et. Al. (2006). Database Management Systems. University of the Philippines Open
University.