Managing Information Technology
| Date | 01 March 1991 |
| Published date | 01 March 1991 |
| DOI | https://doi.org/10.1108/eb027065 |
| Pages | 91-92 |
| Author | Ralph Cornes |
| Subject Matter | Information & knowledge management |
Managing Information Technology
by Ralph Cornes
When relational databases (RDBs) appeared there was a deal of confusion
about what they were. Everybody now knows that they are only a collection of
very simple records in 'card-indexed' files, where anything is automatically
cross-referenced to everything else, but as late as 1986 I had to explain to the
MD of a software house that his product was not relational even though it
allowed cross-references to be built between files. Relational databases provide
automatic cross-referencing and keep it up to date. They also check it is not
self-contradictory, or in RDB jargon, ensure it has 'referential integrity'.
RDBs insist on simple data structures because it appeared that automatic
cross-referencing could work only if records were simple, and probably
because when Codd was developing the theory he had to keep it as simple as
possible. RDBs stopped data processing (DP) from choking on its own
complexity, but although they provide logically sound methods of structuring
data, they are sometimes found wanting. DP needs to manipulate complex
records.
Various 'post-relational' models have emerged to help. Semantic databases
allow you to infer relationships without defining them explicitly. The captain
of a ship is defined by being nominated as captain in the record for the
ship.
You
don't need an ancillary file of 'captains' in the personnel system - or rather you
do but the semantic model sets it up for you. Entity-Relation databases
concentrate on how the relationship operates. An employee does not simply
'belong' to a department. He or she works there on specific tasks for 39 hours
each week with four weeks annual holiday.
But it looks as though the main thrust of database theory is towards object-
oriented databases, and in particular a version called the second normal form
(2NF) database.
Confusingly there is also a movement in computing generally to a technique
called Object Oriented Programming (OOPs), which applies the ideas behind
object oriented databases to the programs which drive them. As an OOPs
'object' is itself
a
mixture of data and programming logic, the confusion about
object oriented databases will be worse than with RDBs.
An OOPs object is a piece of program code wrapped around a chunk of data.
A calendar date might need changing from
'10/6/91'
to '10th June
1991',
so a
normal sub-routine
is
written. The sub-routine becomes part of an object when
it always finds input in a particular place and always provides output to a
particular place. It also is constructed of sub-objects, in turn constructed of
sub-sub-objects, placed in a chain or processing pipe passing data along it.
If I wanted the date to be 'Monday, 10th June
1991',
I would need a 'day'
routine to turn calendar dates to week-days. If written as an object, the day
routine sub-object can be used unchanged in other objects, for example
91
To continue reading
Request your trial