Databases are the bees knees for storing data to which you refer on a regular basis, provided those data have a common arrangement or structure. They used to be monolithic structures basically like a giant spreadsheet for all your stuff. Then along came relational databases. These decreased the possibility of error by only requiring one entry for a particular item: if you have to enter it only once there would be less probability of mistyping it.
The relational database was invented by an E.F. Codd, a young programmer at IBM. He wrote a paper entitled ‘A relational model of data for large shared data banks’. He proposed shifting from storing data in hierarchical or navigational structures to organising data in table containing rows and columns. Each row is called a record and contains a unique instance of data for the categories defined by the columns. Each table has a unique primary key which identifies the information in a table. The relationship between tables can then be set via the use of foreign keys – a field in a table that links to the primary key of another table.1,2
That is all very well, but however databases are structured, they are like pot plants. They need constant care and attention. Many organisations do not understand that. What often happens is that someone comes up with an idea for a compilation of data that may be useful in dealing with a particular requirement. So, the database is constructed and the data inserted into the structure. As with most things like this, over time, requirements will change and that could mean the data structure will have to be changed and more data will need to be added to keep it up to date. If it is not, it fades into obscurity and irrelevance. A former colleague hilariously put it this way: there are databases, which are constantly used and updated; there are data repositories, which are used but not updated; and lastly there are data mortuaries, which are never used nor updated. The latter are where data goes to die.
Source
