ON MEANING IN DATA MANAGEMENT

From: Dave Tallman

Date: 06 Oct 2005

The author of the following quote resists the idea that a primary function of an RDBMS is indeed to manage the meaning of the data, through constraints.

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. ...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.

From: Hugh Darwen

Couldn't agree more. The strength of the relational model lies in its total abandonment of meaning. The word "meaning" is bandied about sometimes in ways that make me wonder if some people don't know what it means, whether they spell it that way or the posh way, "semantics".

From: Fabian Pascal

Well, careful now.

If by meaning you mean (pun intended) verbs, sure (see Meaning: the Desirable Impossible). But isn't the sum total of integrity constraints the best approximation to the user-understood MEANING of the database that the DBMS can have? Chris Date says so. Without that, would RM be useful at all?

From: Hugh Darwen

The meaning of relation SP as understood by the user is

Supplier S# supplies part P# in a quantity of QTY

We can express the relevant constraints (a key and two foreign keys) informally, thus:

If Supplier S# supplies part P# in a quantity of QTY, then there exists a supplier with supplier number S# and there exists a part with part number P# and there does not exist a quantity QTY2 such that QTY<>QTY2 and S# supplies P# in a quantity of QTY2.

From the long conditional sentence I have just written, we can derive the following extended predicate for SP (as Chris does):

Supplier S# supplies part P# in a quantity of QTY and there exists a supplier with supplier number S# and there exists a part with part number P# and there does not exist a quantity QTY2 such that QTY<>QTY2 and S# supplies P# in a quantity of QTY2.

But what is gained by writing that extended predicate? The essential meaning is the in the first conjunct. The rest is just consequential. The DBMS kind-of understands the consequential stuff but does not understand the essential bit (thank goodness). And, yes, the verb is the important bit. I accept that the DBMS understands that S# must look like a supplier number, P# and part number and QTY a quantity, but those are all consequences too.

BTW, I detest the term "semantic constraint" that some people use, imagining that some constraints are to do with meaning and others are not. They are all just constraints.

From: Fabian Pascal

Ed. Note: The above entity type business rule/table constraint subsumes not only the identifier business rule/PK constraint and the referential attribute business rule/FK constraint, but also the property type business rule/domain constraint and the attribute type business rule/column constraint (see Conceptual Modeling and Database Design).

But my point—and Date's, by the way—is that the constraints are what the data "means" to the DBMS, and that without constraints a data model has no usefulness, because the data can be anything. After all isn't that one of the main criticisms of current SQL products—poor integrity support?

As long as constraint meaning and verb meaning are not confused, I don't see what use the data model would have without the former. And, as I said, it the best approximation to the user-understood meaning that a DBMS can have.

The article I referred you to implies, if not states, that constraints mean nothing and have no value.

From: Hugh Darwen

Personally, I find it nonsense to use the word "means" here. I gave you my meaning of foreign key constraints etc. in plain English. The DBMS doesn't know that. No doubt it has its own internal interpretation of a constraint, in terms of the algorithm it uses to check it, but we don't need to talk about that. The DBMS only knows that certain tuples can appear in SP only if certain matching tuples appear in S and P, etc., and we convey that by expressing constraints to it in its prescribed language.

This is only a small point, even though it is one that drives me crazy. To me, it's a misappropriation of the verb "to mean". I would never dream of explaining constraints to my students in such a vague manner. How would it help them if I did? (Please answer)

From: Fabian Pascal

Well, I don't, and neither does Chris Date. We explicitly qualify it by saying that the DBMS does not really understand the business rule or the constraint, all it can deal with is the algorithms, and that is what the business rule/constraints "mean" to it. The point is that's the best that can be done to approach full meaning, otherwise you can put anything in the database, which to me says it is "meaningless" to the DBMS[, as it can do nothing about it].

It helps a lot, and it does not have to be vague. And in fact, not doing it is at least in part contributed to the failure of the relational model to be properly understood in the industry. I've argued about this with Chris too, and about the tendency to stay away from the conceptual level because it's informal and imprecise and fuzzy, and loaded, etc. It is all that, but whether we like it or not, the relations in logical models represent that level in the database, and staying strictly within relations and not specifying what they represent/mean it's, in my opinion, intellectual masturbation. In the context of ignorance in the industry, I am hardly surprised, therefore, by "it's theory and who cares".

Ed. Note: The usefulness of the relational model is that it provides a formal way to express the real world, thus bridging between computers and users.

What I try to do in my just completed paper Conceptual Modeling and Database Design is to relate the latter to the former without being vague. It's tough, and it still won't catch with most people, but it's worth a shot.

Posted 12/10/05