Dealing with Databases

This week sees the start in a new series about databases. More specifically, relational databases. What are they? What are they for? How do I use them? These are just a few of the questions I will be answering in the forthcoming weeks.

What is a Database?

A database is a collection of information (data) that is stored and retrieved when required. Usually, databases store information regarding a particular subject. You might for example, have a database on your stamp collection and companies have databases on their customers, suppliers and invoices. Any "collective group" of such data could be called a database.

Databases will store details (lets say of the customers a company has) and each customers' details will be classed as a record. SO if my company has 1000 customers, then my database will have 1000 records.

Within our record, we will want to store individual items of information. Customer name, address, telephone number etc. Each of these items is known as a field. So databases are made of records which contain fields of data.

But there are different types of database and depending on what information you are storing will depend on which database you use.

Types of Database

I'll start with the simplest and move to the more complex. The simplest kind is known as a Flat File Database. You have probably used such a database already. For those of you who used Windows 3.x, did you ever use the Card applet? Or have used record cards? If so, then you have used a flat file database.

Flat file databases (typically) contain all the information in one place - on the card. These databases are easy to set up, but can end up having a lot of duplicated data. For example, suppose you have a flat file database that logs school children. One card for each child. On the card you would store the class they are in and their teacher. This information would be duplicated 20 - 30 times for each child in one class.

This is a bit wasteful in terms of space, but is more of a pain when, say, the teacher changes. You have to update each card. OK, 20 -30 cards might not be so bad, but what if you had a database where you had to change 1000's of records? This becomes more a problem. One way around this is to use a relational database.

This sounds a complicated concept but is in fact quite simple. What you do is store various bits of related data into separate files (known as tables). Take our school child example. Rather than store the class and teacher on the same table as the child's details, store these in a separate table. So you could have these tables.

Go To Page: 1 2

Articles in this Topic    Discussions in this Topic