On the 7th of December, I, a database administrator, had a seminar from Mr. Chris Date about “Relational Remodeled” (into the 21st century with the relational model: a technical presentation).
It’s contents and implications still startles me. Not because the issues explained by Mr. Date were new, but that the issues are still, after so many years, very much alive. Chris told a small story during this seminar about a question, he once asked to his wife, when she tried to understand why he was so excited.
Chris asked her “what’s the most essential thing about databases”. She replied after a while: “I think, that you can trust the data, you have stored in the database!”
In my mind this is the most essential thing of all, regarding data in databases. Every question you “ask” the database, should give you a correct data, data you can trust. So this story really hit me. That was exactly (again) the thing bogging me for some weeks. Maybe in a different context (Oracle security alert 68), but nonetheless . In one of the more profound publications I got from Chris during this seminar, by him described as The Paper were it all started with, it’s stated as follows:
The large, integrated data banks of the future will contain many relations of various degrees in stored form. It will not be unusual for this set of stored relations to be redundant. Two types of redundancy are defined and discussed. One type may be employed to improve accessibility of certain kinds of information which happed to be in great demand. When either type of redundancy exists, those responsible for control of the data bank should know about it and have some means of detecting any “logical”? inconsistencies in the total set of stored relations. Consistency checking might be helpful in tracking down unauthorized (and possible fraudulent) changes in the data bank contents. Derivability, redundancy and consistency of relations stored in large data banks – E. F. Codd, August 19, 1969
Thirty-five years ago. Most of the time I am, or I am one of the people, who “is responsible for control of the data”. Regarding to the issue “security”, this is one of our biggest challenges as (database) administrators. How do you get someone out and keep him or her out, where he or she was not allowed to get in, in the first place. How do you “track down unauthorized (and possible fraudulent) changes in the data bank contents”.
Normally I would start saying: “start gathering information (and evaluate this information!) – don’t forget to use your common sense” (don’t allow select any table privileges in your database – eg. “select password from sys.link$” etc. etc.). Mr. Date’s remark, that one of the biggest problems with SQL is that “SQL does not support the relational model” and / or “Databases do not support the relational model or the relational model is not correctly implemented” does also not really help in this context.
If you think in terms like optimizers and query re-write you even start more wondering if your result set is the correct one. The better the optimizer becomes, the more code was used to build it, the more bugs there will arise. It’s all a merry-go-round. One thing i believe in though it will never be “secure”. There will be always someone smarter, than the person who build a better “security” scheme.
Mr. Date said during the seminar: “the abstraction level defines atomic“. As an example he tried to explain atomic to set this in the context of that there is an abstraction level when you look at atoms at an atomic level. Also the abstraction level in it’s place defines therefore atomic. He annotated that atoms exist out of electrons and neutrons and that it’s possible to split these again in quarks and strings.
Each level containing his own correct abstraction level. Lets do the merry-go-round in that perspective. We are all perfectionists in some or other way, let us be driven by the challenge and define the correct abstraction level, maybe it defines also the perfect relational model, database, ANSI SQL standard, etc.
In the meanwhile i will try to control the data bank the best i can, with the best means i can find or build.