Database Integrity Issues

Another of these precursor milestones to be passed on the way to the milestone demarking the full computer automation of an organisation is the creation of some form of handle for what is known simply as database integrity. If the database for any number of reasons held corrupt or unconventional data elements in the place of correct values, when this information was routinely processed, there were usually unusual results in output.

Data integrity is one of the corner stones of IT Management practice, for the ultimate responsiblity for data integrity rests not with any of the external hardware or software or systems vendors. It is an issue which needs to be addressed in a proactive fashion. It is better to take the problems to the database and check for the existence of any previously identified types of data integrity failures, than to allow such errors to build up and multiply.

This proactive practice is characteristic of endeavors where failure cannot be repeatedly countenanced, and where there is much at stake riding on the integrity of the data itself. Quality assurance of the organisational data should be a necessary part of the organisational intelligence (or rules).

During the 1970's and 1980's and 1990's the term Relational Database received an increasingly widespread attention, both in theory and in practice. Relational databases were able to be created so that many types of previously identified database integrity exceptions could no longer arise. As we shall see in the next article, such advances were indentified as being required by computing theory in the 1970's.


By nature and requirement, they represented comprehensive statements of data processing requirements for the specific organisation, or organisational group. In many instances, these needs were formalised prior to any programming work into a requirements definition, as will be examined in a further chapter in depth.

Sufficient to say here that the applications software environment of the 1980's was characterised by screens of data. The more bits of data the organisation needed to maintain or access, the more screens got added to the application, so that it represented a graduated means of providing organisational information specific for the needs of the people within it.

The larger these database application software packages became, the greater became the need to cohesively manage their development, their deployment and their related menu and security access rights administration. Modular development became popular, if not mandatory, for database application software packages which attempted to answer and fullfil the entire spectrum of informational needs of an organisation.

Often, for all types of reasons, organisational needs could not be met with any single available database application software, but only via the integration of a number of packages. That an organisation is required to prepare financial reports and keep an account of various ledgers of operation often implied the integration of a separate financial package or packages (such as Accounts Payable, Accounts Receivable and General Ledger).

IT Management at any one (generic) organisational site often had to manage a number of separate but highly integrated database application software products. These products consisted of modules and sub-modules and at the atomic level some finite series of application software objects which were specifically written for some form of specific existent DBMS. Whenever the underlying DBMS was upgraded, and this was often associated with the release of new vendor machine operating system software, it was often mandatory that changes were made to each of this underlying series of application software programs.

Conversely, where new functionality or enhancements were released in the progression of vendor specific DBMS, it was only by some form of corresponding changes made in the database applications code that the users of the entire ensemble of systems could realise any substantial advantage of these enhancements.