1

Database Fundamentals
Every organization, be it large or small, requires information. Information is derived from data.
Thus the organization collects data on its customers, it employees, its products, and host of other
things. An orderly collection of related information or interrelated data organized in a useful manner is
what we called database. Examples of database are dictionary, telephone directory, bank accounts,
student records, inventories, cookbook, music collections, etc.

Actually, you can store a list in a Microsoft Word table or on a Microsoft Excel spreadsheet. But
if you place this information in a Word table or in an Excel spreadsheet, you are faced with problem;
you end up repeating some of the information. Consider what happens if an employee moves or a last
name is changed. You have to ensure that information is updated everywhere it is stored. (It is not a
matter for a small list, but for a large list with information that requires constant updating, such as
address list, it is a huge task to keep data up-to-date in this way.)

Therefore, merely storing the data is not enough; of course, those facts must be retrieved and
organized if their meaning is to be extracted. The database management system fills up these needs.

What is Database Management System (DBMS)?

Database Management System (DBMS) is a software application that stores the structure of the
database, the data itself, and the relationships among data in a database as well as forms, inquiry and
reports pertaining to the database. Its primary functions are to store, retrieve, and organized data.

By their nature, databases are more complex and more difficult to learn than those most word
processors and spreadsheets. You need not only to know how to build tables and queries; you’ve got
to know why you’re supposed to build them in a particular way.

Advantages of Database Management System

 Data Independence It is a separation of data from the application programs that use the data.
The organized data be changed and evolves necessitating changes in application programs that
process data.
 Sharing Data It allows all the authorized users in an organization to share its data. It provides
the user to precise view of data required for making decision or performing some functions
without making the user aware of the overall complexity of the database.
 Integrated Data It is considered integrated for any item of data that can be used to satisfy an
inquiry or a report.
 Ease of Application Development It reduces cost and time for developing business applications.
A program can code and debug a new application at least 2 to 4 times faster than any with
conventional data files.
 Data Accessibility It provides multiple retrieval parts to each item of data, providing the user
greater flexibility in locating and retrieving data than with data files.
 2

 Uniformed Security, Privacy and Integrated Controls It improves the data protection,
centralized control and standard procedures provided by a dispersed data file system. The
database will be vulnerable than conventional files, which is exposed to more users if proper
controls are not applied.
Note: Using traditional (conventional) approach to data management, separate files are created
to support each program. Separate files make logical sense, but they can lead to problems, too.
Let us examine the example below:

FINANCIAL BILLING PROGRAM BILLS

GRADE FILE REPORT GRADE REPORT PROGRAM GRADE

Although the files pictured in this figure are different, they do have some fields in
common for example, both programs need student names and mailing address, so student names
and addresses will appear in both.

Financial file Grade file

Student Name Student Name

Student Name Student Name

What happens if a student moves? What if one is updated and the other is not? The computer will
now hold two different values for the same attributes, one of, which must be wrong. Therefore
data redundancy can lead to multiple, incompatible versions of the “truth” and that in return
compromises data integrity.

 Reduced Redundancy Data It carried in separate files tends to repeat some of the same data
over and over, that information appears at least only once.

Disadvantages of Database System

 Access This refers to users who have improper access to a database. The employees must be
trained to correct ways of using database management system, especially in a large
organization.
 Expense It is usually expensive to set-up and maintain database. The employees must be
trained to use the database properly.
 Excess an organization that carries more data files than expected; it is theoretically possible for
a database to carry unsuitable data.
 3

The File Organization

System Files – The most common is an operating system. It needs to start the computer. It controls
and supervises the operation of the computer – executes application programs like
database management system, interacts with I/O devices, and manages the files
through the use of its memory.

Application Software files – Program files needed to run the application program.

Data Files – Files created by the user using application program

Methods of Information Retrieval

Insertion – It is the process of adding a new record to an existing file.

Writing – Transfer a record from the main memory to secondary storage device.

Updating – It makes new changes to the contents of a record maintained on a file to reflect its new
status.

Deleting – The act of removing a record from the file.

Merging – It could be a record or file merging. It is a combination of two or more files in the same
sequence into a single output. File.

Sorting – It is the act of rearranging the records in a file to produce ordered reports.

Searching – To satisfy specific criteria that involve looking for records with a certtain key value.

Matching – To compare two or more records against other in order to ensure that there is a complete
set of records for each key. Mismatch records are highlighted for subsequent action.

Database Design Guidelines

When designing a database, the actions you take and the decisions you make will determine
the tables and fields that will be included in the database. As you create a database, you should follow
these general guidelines:

1. Determine the purpose of your database and how it is to be used. You need to know what
information you want from the database. From that, you can determine what subjects you
 4

need to store facts about (tables) and what facts you need to store about each subject (fields in
the tables)
Talk to people who will use the database. Brainstorm about the questions you’d like the
database to answer. Sketch out the reports you’d like it to produce. Gather the forms you
currently use to record your data. Examine well-designed databases similar to the one you are
designing.

2. Identify the table. Determining the tables can be the trickiest step in the database design
process. That’s because the results you want from your database – the reports you want to
print, the forms you want to use, the questions you want an answer – don’t necessarily
provides clues about the structure of the tables that produce them.
Examine the requirements for the database in order to identify the main objects that
are involved. There will be a table for each object you identified.
In one database, for example, the main objects might be the departments and
employees. Thus there would be two tables: one for the departments and the other for the
employees. In another database, the main objects might be clients and recruiters. In this case,
there would also be two tables: one for the clients and the other for the recruiters. In still
another database, the main objects might be books, publishers, and authors. Here, there
would be three tables: one for book, second for publishers, and third for authors.

3. Determine the fields you need. There are two important objects in your database – the data,
which refers to the information that goes to your database and the fields, which refers to the
type of data that make up the database.
There will be many fields; each contains a type of data. Examine the project
requirements to determine all possible fields. For example, in an Employee Table, the fields
might include Employee Name, Street Address, City, State, Postal Code, Date Hired, Salary, and
so on. Each table must contain information about the same subject, and each field in the table
contains individual facts about the table’s subject.
When sketching out the fields for each table, keep these tips in mind:
 Relate each field directly to the subject of the table.
 Don’t include derived or calculated data (data that is the results of an
expression)
 Include all the information you need.
 Store the information in its smallest logical parts (for example, First name, Last
name, rather than Full name.
4. Determine the primary key. In order for a database management system to connect
information stored in a separate tables – for example to connect a customer with all the
customer orders - each table in your database must include a field or sets of fields that
uniquely identifies each individual record in the table. Such field or sets of field is known as
primary key. Therefore, Primary key is the unique identifier for record in the table. For a
 5

Department table, for example, the unique identifier might be the Department Code. For a
Book table, the unique identifier might be the ISBN number.
5. Determine the relationships among tables. Now that divided your information into tables and
identified the primary key field, examine the list of tables you have created to see which tables
are related. When you determine that the two tables are related, include matching fields in the
two tables.
For example, in a database containing employees and departments, there is a
relationship between the two tables because one department can have many employees
assigned to it. Department Code could be the matching field in the two tables.
6. Determine the data types of the fields. For each field, determine the type of the data field can
contain. One field, for example, might contain only numbers. Another field might contain
currency amounts, while the third field might contain only dates. Some fields contain text data,
meaning, it contain combination of letters, numbers, and special characters.
For example, in an Employee table, the Date Hired field would contains date, the Salary
field would contain currency amounts, and the Hours Worked field would contain numbers
7. Identify and remove any unwanted redundancy. Redundancy is the storing a piece of data in
more than one place. Redundancy usually causes problems, such as wasted space, difficulties
with update, and possible data inconsistency.
Examine each table you have created to see if it contains redundancy and if so, determine
whether the redundancy causes these problems. If it does, remove the redundancy by splitting
the table into two tables.
For example, you may have a single table of employees. In addition to common employee data
(name, address, earnings, and so on), the table might contain department number and
department name. If so, the Department name could repeat multiple times. Every employee
whose department number is 12, for example, would have the same department name. It
would be better to split the table into two tables, one for employees and one for department.
In the department table, the Department name is stored only once
8. Determine the location for the database. The database you have design should be stored in a
single file.

Types of Databases

Analytic Databases - (a.k.a. OLAP- On Line Analytical Processing) are primarily static, read-only
databases which store archived, historical data used for analysis. For example, a company might store
sales records over the last ten years in an analytic database and use that database to analyze
marketing strategies in relationship to demographics.

Operational Databases - (a.k.a. OLTP On Line Transaction Processing), on the other hand, are used to
manage more dynamic bits of data. These types of databases allow you to do more than simply view
archived data. Operational databases allow you to modify that data (add, change or delete data).

These types of databases are usually used to track real-time information. For example, a company
might have an operational database used to track warehouse/stock quantities. As customers order
 6

products from an online web store, an operational database can be used to keep track of how many
items have been sold and when the company will need to reorder stock.

Database Models

Besides differentiating databases according to function, databases can also be differentiated according
to how they model the data.

Hierarchical Databases - As its name implies, the Hierarchical Database Model defines hierarchically-
arranged data. Perhaps the most intuitive way to visualize this type of relationship is by visualizing an
upside down tree of data. In this tree, a single table acts as the "root" of the database from which
other tables "branch" out.

You will be instantly familiar with this relationship because that is how all windows-based directory
management systems (like Windows Explorer) work these days.

Relationships in such a system are thought of in terms of children and parents such that a child may
only have one parent but a parent can have multiple children. Parents and children are tied together
by links called "pointers" (perhaps physical addresses inside the file system). A parent will have a list of
pointers to each of their children.

This child/parent rule assures that data is systematically accessible. To get to a low-level table, you
start at the root and work your way down through the tree until you reach your target. Of course, as
you might imagine, one problem with this system is that the user must know how the tree is structured
in order to find anything!

Network Databases - The network model is very similar to the hierarchical model actually. In fact, the
hierarchical model is a subset of the network model. However, instead of using a single-parent tree
hierarchy, the network model uses set theory to provide a tree-like hierarchy with the exception that
child tables were allowed to have more than one parent. This allowed the network model to support
many-to-many relationships.
 7

The Relational Database Model - Of course in the 80's the "Relational Database Model" became the
rage. The Relational Model developed out of the work done by Dr. E. F. Codd at IBM in the late 1960s
who was looking for ways to solve the problems with the existing models.

Because he was a mathematician, he naturally built the model on mathematical concepts which he
expounded in the famous work called "A Relational Model of Data for Large Shared Databanks".

At the core of the relational model is the concept of a table (also called a relation) in which all data is
stored. Each table is made up of records (horizontal rows also known as tuples) and fields (vertical
columns also known as attributes).

It is important to note that how or where the tables of data are stored makes no difference. Each table
can be identified by a unique name and that name can be used by the database to find the table
behind the scenes. As a user, all you need to know is the table name in order to use it. You do not need
to worry about the complexities of how the data is stored on the hard drive.

So how do you find data in a relational database if there is no map (like a hierarchy defined by
pointers) to follow?

Well, in the relational model, operations that manipulate data do so on the basis of the data values
themselves. Thus, if you wish to retrieve a row from a table for example, you do so by comparing the
value stored within a particular column for that row to some search criteria.

For example, you might say (not getting into syntax yet) "Give me all the rows from the 'STUDENTS'
table which have 'Selena' in the 'FIRST_NAME' column."

The database might return a list which looks essentially like this:

Selena Sol SID-001 213-456-7890

Selena Roberts SID-268 818-934-5069

Selena Smith SID-991 310-234-6475

This data access methodology makes the relational model a lot different from and better than the
earlier database models because it is a much simpler model to understand. This is probably the main
reason for the popularity of relational database systems today.

Another benefit of the relational system is that it provides extremely useful tools for database
administration. Essentially, tables can not only store actual data but they can also be used as the
means for generating meta-data (data about the table and field names which form the database
structure, access rights to the database, integrity and data validation rules etc).

Thus everything within the relational model can be stored in tables. This means that many relational
systems can use operations recursively in order to provide information about the database. In other
words, a user can query information concerning table names, access rights, or some data and the
results of these queries would then be presented to the user in the form of a table.

This makes database administration as easy as usage!

Client/Server Databases - Most databases that you will come across these days will be relational
databases. However, there are many types of relational databases and not all of them will be useful for
web applications.

In particular, it will be the client/server databases rather than the stand-alone packages that you will
use for the web.

A client/server database works like this: A database server is left running 24 hours a day, and 7 days a
week. Thus, the server can handle database requests at any hour. Database requests come in from
"clients" who access the database through its command line interface or by connecting to a database
socket. Requests are handled as they come in and multiple requests can be handled at one time.

For web applications which must be available for worldwide time zone usage, it is essential to build
upon a client/server database which can run all the time.