Re: 4 the FAQ: Are Commercial DBMS Truly Relational?

From: Laconic2 <laconic2_at_comcast.net>
Date: Sat, 9 Oct 2004 07:11:09 -0400
Message-ID: <JpmdnTK5C9X_WvrcRVn-rA_at_comcast.com>


"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:hqd6kc.4go.ln_at_mercury.downsfam.net...
> It said often here that no commercially available DBMS is truly
relational,
> but I haven't seen a succinct list of reasons. What are they?
>
> One that I have gleaned from lurking is that the DBMS's allow duplicates,
as
> in:
>
> CREATE TABLE AnyTable (col1 char(1), col2 char(1), col3 char(1));
> INSERT INTO AnyTable (col1,col2,col3) VALUES ('A','B','C');
> INSERT INTO AnyTable (col1,col2,col3) VALUES ('A','B','C');
>
> The table create specifies no constraints, and so the next two insert
> statements are both allowed. The objection to this seems to be that the
> RDM requires an implied unique constraint on all columns of all tables.
> Because such a constraint is not present, they are not truly relational.
>
> Is that right?

Yes. You'll often see tables described as "bags rather than sets" in here. What the mathematical types mean by a bag is a collection that allows duplicates. A bag with six black socks in it and six white socks in it is not the same as a bag with one black sock and one white sock. This is true, in concept, even if you can't tell the black socks apart or tell the white socks apart.

>
> What are some of the other objections?
>
Another objection is this: in mathematics, a relation has no need for NULLS. Every tuple is a distinct point in the same space. A row with a NULL in it is projected onto a subspace of the original space.

> We could probably have the same discussion re: Structured Query Language
is
> not relational.

Codd objected to the language SQL when it was proposed to use it for access to relational data. His objections are pretty well catalogued, somewhere. I haven't read these, but I'll bet they present a fairly formal case for the difference between SQL and "a relational sublanguage".

About 20 years ago, when the "relational Derby" was on in full swing, with vendors from IBM to Cullinane announcing their relational database, the debate about whether they were "really relational" or not raged even worse than it does today. Codd devised a set of 12 rules that a system purported to be relational must follow. Some of the RDBM systems of the day scored pretty high on the 12 rules test.

But the problem is that the 12 rules aren't built in such a way that "11 out of 12 is pretty good". They are built like the axioms in an axiomatic development of a branch of mathematics. If you break even one of the rules, all bets are off as to whether the resulting system will behave the way a relational system is asserted to behave.

SQL became the lingua franca by propagation. Then, after a while, a standards committee was set up. See Joe Celko on that.

In my consulting practice, I never tried to distinguish between "a true relational database" and Oracle, DB2, or SQL Server. It just wouldn't have helped communication between me and the client's people. And, to tell the truth, I regard Oracle as "close enough for practical purposes". This is genuine heresy to the true theoreticians. Ask me if I care.

I'm going to copy your post into a new thread, to discuss duplicates from a different point of view. Received on Sat Oct 09 2004 - 13:11:09 CEST

Original text of this message