Relational Databases

Computerworld - Everyone knows what a simple database is: Telephone directories, mail-order catalogs and dictionaries are all databases of sorts. Databases can be structured or organized in several different ways: as flat files, as hierarchical or networked structures or as related tables. Of these types, relational databases manage most organizations' data.

A database can be described as a table of data consisting of columns and rows, similar to a spreadsheet. Each row contains a single record; each column contains all the instances for each row of one particular piece of data. For example, a typical telephone directory consists of columns holding telephone numbers, subscriber names and subscriber addresses. Each row consists of a number, name and address. This simple form is called a flat file because of its two-dimensional nature and the fact that all data is stored in a single file.

Ideally, every database has at least one column with a unique identifier, or key. Consider the phone book: There may be many entries for J. Smith, but none of the phone numbers will be duplicated. The phone number serves as the key.

In reality, things aren't quite so simple. Two or more people sharing a phone might want a listing for each name; this causes the phone number to appear in two or more places, resulting in multiple rows with keys that aren't unique.

Data Causes Problems

In the simplest databases, every record is complete in a single row, meaning the phone company would need a separate column for every piece of account information. That would require a separate column for a secondary subscriber, another for a tertiary subscriber and so on for as many additional subscribers as might be needed.

This means every record in the database would have to have all the extra columns, even if most would never be used. It also means the database would have to be redesigned and rebuilt every time you rolled out a new service. Add touch-tone service, and you've got to rebuild to add a new column. Add caller ID, call waiting and so on, and you'd have to rebuild again and again.

In the 1960s, only the biggest companies could afford computers to manage their data. Moreover, databases built on static data models and procedural programming languages such as Cobol could be costly to maintain and weren't always reliable. Procedural languages specify sequences of events that the computer should step through to accomplish tasks. Programming such sequences was difficult, especially if you needed to change the structure of the database or cook up a new kind of report.