1. Database Truth of the Week
"The RDM is a formal system. It has two parts.
- The Deductive Subsystem: the formal language
- The Interpretation Subsystem i.e., the application--of that language
Without an interpretation subsystem there is no possibility of applying the formal system and it remains an abstract game of symbols.
Semantics is about applying the RDM to some subject. In effect, what you do is restrict the power of the abstract formalism so that it is more closely aligned with your intended use. That means you are using constraints to limit the vocabulary to the subject matter (and making it finite and usually fairly small) and restricting the possible interpretations that can be used consistently with the resulting subset of the formalism." --David McGoveran
Note: This is a 10/23/17 rewrite of a 7/29/12 post to bring it in line with the McGoveran interpretation [1] of Codd's true RDM.
To understand what's wrong with the picture of two weeks ago, namely:
"If
we step back and look at what RDBMS is, we’ll no doubt be able to
conclude that, as its name suggests (i.e., Relational Database
Management System), it is a system that specializes in managing the data
in a relational fashion. Nothing more. Folks, it’s important to keep in
mind that it manages the data, not the MEANING of the data! And if you
really need a parallel, RDBMS is much more akin to a word processor than
to an operating system. A word processor (such as the much maligned MS
Word, or a much nicer WordPress, for example) specializes in managing
words. It does not specialize in managing the meaning of the words ...
So who is then responsible for managing the meaning of the words? It’s
the author, who else? Why should we tolerate RDBMS opinions on our data?
We’re the masters, RDBMS is the servant, it should shut up and serve.
End of discussion." --Alex Bunardzic, Should Database Manage The Meaning?
it
helps to consider the quote in the context of another article by the
author, "The Myth of Data Integrity", where he reveals that those "DBMS
opinions" are constraints (the article has been deleted, but a
few comments remain online and are highly recommended for a feel of the
consequences of lack of foundation knowledge).
Database redundancy can wreak havoc with interpretation of analytics
results, but it also poses consistency risks that can affect the
correctness of the results themselves. The risks are too
underappreciated for effective prevention. Given industry practices,
analysts who use databases they did not design, or designed without
sufficient foundation knowledge, should be on the alert.
1. Database Truth of the Week
"If the physical model does not preserve the properties of the logical model, then it is—by definition—incorrect. That is why the physical model must be derived from the logical model, not the other way around." --David McGoveran
2. What's Wrong With This Database Picture?
"If we step back and look at what RDBMS is, we’ll no doubt be able to conclude that, as its name suggests (i.e. Relational Database Management System), it is a system that specializes in managing the data in a relational fashion. Nothing more. Folks, it’s important to keep in mind that it manages the data, not the MEANING of the data! And if you really need a parallel, RDBMS is much more akin to a word processor than to an operating system. A word processor (such as the much maligned MS Word, or a much nicer WordPress, for example) specializes in managing words. It does not specialize in managing the meaning of the words ... So who is then responsible for managing the meaning of the words? It’s the author, who else? Why should we tolerate RDBMS opinions on our data? We’re the masters, RDBMS is the servant, it should shut up and serve. End of discussion." --Alex Bunardzic, Should Database Manage The Meaning?
Here's what's wrong with the picture of two weeks ago, namely:
"Constraints are categorized as follows:
- Domain integrity Constraints
- Entity integrity Constraints
- Referential integrity Constraints
- Not null
- Unique
- Foreign key
- Check
- Primary key
Constraints are always attached to a column not a table."
--Dayakar, SQL Constraints
Despite being a critical database function, integrity is insufficiently understood and appreciated. Few practitioners know much beyond just awareness of primary key and referential constraints and question even their necessity.
SQL inhibits understanding, so if you want to really understand integrity, don't start with SQL. Instead, educate yourself on relational integrity and put your SQL DBMS's features in that context--how correctly and completely does it support all the necessary constraints? Then you can (1) make sure that the constraints that it does support are enforced and (2) be aware of those that it does not, the potential risks thereof and the defensive actions to be taken, if necessary. A bonus is that you will finally realize one of the many important differences between SQL DBMSs and a true RDBMS, which are confused in the industry[1].
I dare you to find this information anywhere else!!!!
"...having nothing in them of the feelings or principles of ’76 now look to a single and splendid government of an Aristocracy, founded on banking institutions and monied incorporations under the guise and cloak of their favored branches of manufactures commerce and navigation [add technology], riding and ruling over the plundered ploughman and beggared yeomanry." --Thomas Jefferson
The first Donald Trump who comes along is all it takes to dismantle 200 years of American vaunted democracy and whatever little civilization was there by executive order. The "indestructible" system of checks and balances is collapsing like a house of cards.
A nation that substitutes job training--if anything--for education, religion for reason and unbounded greed for morality regresses to the dark ages and self destructs.
