The Database Concept! What do I mean by this? Well, I certainly do not mean that further down this article your going to see a fantastic picture of a new innovative concept car. (That would be nice though!)

No, what I mean by The Database Concept is basically the reason why we have databases today and use them so much in everyday life. Before I begin, lets just take a short look at the common problems with files systems in general that became apparent for us to consider the use of a database.

The problems with files systems that became apparent were:

• The structure of the records were defined in the application program. This produced two very unfortunate consequences:
• In order to change a file format, every program using the file has to be changed.
• At the same time, the file had to be rebuilt in the new format using ‘one-off’ conversion programs.
• The files were only designed to suite the application currently being developed. This caused many issues when trying to integrate applications as the files were often not compatible.
• Due to files being created to work with a particular application this meant that data such as customers names and addresses were having to be duplicated. We all know that this is a great waste of space, but lets face it, having to change one customer address meant having to change it accross all applications which was a waste of time.
• The ability to generalise querying and maintenance facilities was difficult due to the conversion process not being automated.

So, The Database Concept was born. The concept was aimed at solving issues like the ones I have listed above. To keep it simple, a leap was made to consider the data, instead of the application programs as priority within the initial design process.

Your average file-based system focused on the functionality of the programs which ended up producing files focused on implementing the storage needs of that particular application. So, this new alternative approach was to look first at the design of the applications data and only then would we write a program to process it.

Take a look at a basic concept of a database:

My illustration on the left attempts to show the data is the center of interest and is independent of the application programs that access/update it. Take note that we can also employ generalised maintenance and utility programs which will only be concerned with the database and not the associated applications. In order to achieve this the database not only has to include the data, but a description of the data within the database.

So, what I am saying here is in effect, we want the database to represent the applications data; i.e., the database models the application. Ok, so for realisation the features described above require a software system that manages the data and the schema information but also provides an interface for the user.

This type of software is called a Database Management System (which I and most others generally refer to it as DBMS for short). Although, commonly used is the term ‘database package’ which refers to the DBMS implementation offered by software vendors.

So, I hope you have managed to understand what is meant by The Database Concept and from the above article you are able to answer such questions as this one:

How do older file systems and the new database approach differ in terms of the relationship between the data and the application program?