 |
|
|---|---|
A Brief History | |
|
|
|
|
|---|---|
A Brief History | |
|
|
3) Emergence of the RDBMS |
Rule 2: Guaranteed Access Rule: Each and every datum (atomic value) in a relational database is guaranteed to be logically accessible by resorting to a table name, primary key value, and column name.
Rule 3: Systematic Treatment of Null Values: Null values (distinct from empty character string or a string of blank characters and distinct from zero or any other number) are supported in the fully relational DBMS for representing missing information in a systematic way, independent of data type.
Rule 4: Dynamic On-line Catalog Based on the Relational Model: The database description is represented at the logical level in the same way as ordinary data, so authorized users can apply the same relational language to its interrogation as they apply to regular data.
Rule 5: Comprehensive Data Sublanguage Rule: A relational system may support several languages and various modes of terminal use (for example, the fill-in-blanks mode). However, there must be at least one language whose statements are expressible, per some well-defined syntax, as character strings and whose ability to support all of the following is comprehensible: data definition, view definition, data manipulation (interactive and by program), integrity constraints, and transaction boundaries (begin, commit, and rollback).
Rule 6: View Updating Rule: All views that are theoretically updateable are also updateable by the system.
Rule 7: High-level Insert, Update, and Delete: The capability of handling a base relation or a derived relation as a single operand applies not only to the retrieval of data but also to the insertion, update, and deletion of data.
Rule 8: Physical Data Independence: Application programs and terminal activities remain logically unimpaired whenever any changes are made in either storage representation or access methods.
Rule 9: Logical Data Independence: Application programs and terminal activities remain logically unimpaired when information preserving changes of any kind that theoretically permit unimpairment are made to the base tables.
Rule 10: Integrity Independence: Integrity constraints specific to a particular relational database must be definable in the relational data sublanguage and storable in the catalog, not in the application programs.
A minimum of the following two integrity constraints must be supported:
2. Referential integrity: For each distinct nonnull foreign key value in a relational database, there must exist a matching primary key value from the same domain.
Rule 11: Distribution Independence: A relational DBMS has distribution independence. Distribution independence implies that users should not have to be aware of whether a database is distributed.
Rule 12: Nonsubversion Rule: If a relational system has a low-level (single-record-at-a-time) language, that low-level language cannot be used to subvert or bypass the integrity rules or constraints expressed in the higher-level (multiple-records-at-a-time) relational language.
Note: There is a rider to these 12 rules known as Rule Zero: "For any system that is claimed to be a relational database management system, that system must be able to manage data entirely through its relational capabilities."
On the basis of the above rules, there is no fully relational DBMS available today.
REFERENCES: Codd, E. (1985). "Is Your DBMS Really Relational?" and "Does Your DBMS Run By the Rules?" ComputerWorld, October 14 and October 21.
From the perspective of IT Management however, whatever DBMS or RDBMS it was that housed the organisational data in production realtime, it was this very ever-changing database of information which needed to be safeguarded with the utmost diligence.
The daily backups needed to be performed and checked off, and if they were automated then they needed to be checked. Periodically restores of such backups needed to be scheduled to test the integrity of the backup and restore process, or media, or device. A backup was useless if it could not be restored.
More importantly, the integrity of the database had to be maintained at the highest possible level. If this duty were not attended to by some responsible party internal or external to the organisation, then the value of the database as an entity would be suspect to varying degrees.
With experience in the field one understands that there are indeed usually an entire series of specific forms of data integrity issues and problems which may arise at any time within any given database, due to a number of different environmental factors.
At the top of the list, we see Rules 2 and 3 may have direct bearing on data integrity issues if they are not enforced. But it is Rule number 10 that is often quoted as the one which is not successfully established in certain instances by default within the DBMS, to make it a truly RDBMS.
As CJ Date points out in his article entitled Business Rules and the Relational Model, the title of Codd's orginal paper was "Deriveability, Redundancy, and Consistency of Relations Stored in Large Data Banks". (My underlining). He goes on to reinforce that the term "consistency of stored relations" from Codd, is implicitly the same thing as the term integrity constraints, and to note that another formal description for the set of these things is "the relation predicate.
When all is said and done however, the RDBMS vendors of today have a far more powerful and robust product than they had a decade ago, and while it is often very interesting examining the theoretical threads of the beginnings of the Relational Database concept, this article is bound closely to follow the path and perspective of the IT Management staff who have used all these evolving products, and seen the decades come and go.
For this reason, in terms of the technical evolution of the major RDBMS products available since the 1990's, we are going to skip this era, and move right up to the present day in 2002 and have a look under the bonnet of one of these major RDBMS products, just to see what it does.
Again, let me state clearly that while the academic approach to the failure of RDBMS vendors to supply greater support for integrity constraints, or for a number of technical issues by which their products may not conform 100% to the releational model is often warranted and heeded by the vendors, my approach has not had the luxury of time.
When we are dealing with a production database, alive and breathing through all forms of organisational processes, we cannot afford the time to wait for the longer term solutions to such problems. Production database integrity, and by this I mean real live day-to-day production sites, is a concern that needs to be addressed without delay. If you as an IT Manager designed a series of data integrity exceptions alerts to identify the quantitative failure of specific integrity constraints, and had such resolved, such a mechanism might work-around potential major problems.
Perhaps the real difference between a DBMS and an RDBMS is similar to the difference between a 6 cylinder car and an 8 cyclinder car? If we looked under the bonnet we might be able to tell, so lets choose one of the major 3 RDBMS vendors, and have a little look. In this article we have selected to check under the bonnet of the SQLServer product from Microsoft Corporation.
But this is not an RDBMS vendor promoting exercise. In fact, this article treats the three major RDBMS vendors equally. The viewpoint of this article again, for those interested in such contextual and between the lines issues, is from the perspective of organisational information technology management and engineering ... the task of the realtime balancing act when dealing with whatever solution is already made available in the environment and in keeping the organisation's information streams in a constantly scheduled circulatory flow.
As such, one machine and RDBMS today is much like any of the other two. Sure, there are major historical dfferences between the products in earlier times, but today with first quarter of the first decade of a new millenium over half finished, the products are looking very different than they were a decade ago.
We are concentrating on the management features, the RDBMS services and utilities, its import and export facilities, its replication and backup services and redundancy handling, the logging and alert subsystems, the quantifiable performance parameters, the actual database features and controls, the user and task concurrency management, the security management, the innate task scheduling services and controls.
But most of all we are looking for an underlying form of structured query language by which all of the above may be addressed, and a corresponding GUI by which DBA's and IT Managers can use as a resource should the corresponding SQL prove too detailed, irksome or indeed just beyond the current experience of those assigned some task. And the paramount end-result of all such investgative and research and development work that is conducted by the IT Management? It is simply working towards an automation of all the above.
Close competitive marketplace business has forced these larger three RDBMS vendors to calibrate their products with all forms of good management and adnministrative features that have arisen over the last decade. Whereas in years past this development of such features was not yet completed, in recent years each of the 3 products has evolved towards each other in terms of functionality.
So when we are looking below at the Microsoft SQLServer product, we could just as easily be looking at the latest Oracle product, or the latest IBM product, DB2. The purpose of the following is to open up a little black box called "The RDBMS" and take a look at the moving parts inside.