"Hi, I'm SuperNorm, here to guide you through the Normalisation Process"

Relaxation Corner | Site Map | FAQ's

Home  >  Theory  >  Database Concepts
Search This Site

|Home Database Concepts |Normalisation Concepts | 1 NF | 2 NF |3 NF |4-7 NF |

Theory Pages


Web Links

Down Loads

Discussion Room

Contact Us


Database Types:

Flat File

A relatively simple database system in which each database is contained in a single table.

Designing a flat file database is a relatively straightforward procedure. Since you can't share information between files in a true flat file database, everything you want to track in your database needs to have a field defined for it.

For example, if you have a file named Invoices and you want to include customer information, you need to define fields for customer name, address, city, state, and postcode. These fields will be in addition to the fields you may have already defined in the Invoices file. If you want to include product information, you need to define fields for product name, color, size (or other attributes), and price. As you can see, your flat file database can contain a large number of fields and in many cases a lot of duplicate data, such as customer or product names.

Designing a flat file database is simply a matter of deciding what data you want to track and creating a field for each piece of data. However, Flat File systems have their problems.

Problem: You store the same information in several places, such as: Customer Names, Product Information, Order and Invoice Information. Suppose you have to change some of the data e.g. product name supplied to customers.

When you update these items, it is time consuming to find all of the places they occur and then type in the same information repeatedly. How can you be completely sure that all customer records are the same?


In the early 1960s, IBM recognised that the business world organised data in the form of a hierarchy rather than one record type (flat file).

A business has to deal with several types which are hierarchically related to each other e.g. a company has several departments, each with the attributes: manager, number of staff, address, telephone number etc.
Each department requires several parts to make its product, with attributes: part number, number in stock each part may have several suppliers, with attributes: address, price etc.


Developed in mid 1960s as part of work of CODASYL (Conference on Data Systems Languages) which proposed programming language COBOL (1966) and then network model (1971).

The objective of a network model is to separate data structure from physical storage, eliminate unnecessary duplication of data with associated errors and costs. It uses the concept of M:N linkages or relationships. E.g.

An Owner record can have many Member records.
A Member record can have several Owners.

Network databases differ from Hierarchical databases because a Hierarchical model allows only 1:M relationships.


An important feature of relational systems is that a single database can be spread across several tables. Therefore relational database systems can use multiple tables to store information, and each table can have a different record format.

In contrast to flat-file databases, relational databases use relationships between the files to bring the data together on one form or layout. Designing a relational database takes a lot of planning, before you even create your first file and define your first field. Planning ahead, in terms of identifying the key entities, will save time and effort later on and will result in fewer changes to be made later.

Relational Databases are the main focus of this site.


<<<Back to Database Concepts

Next to Normalisation Concepts>>>