Re: The relational model is a wrong theory

From: vldm10 <vldm10_at_yahoo.com>
Date: Sun, 13 Oct 2019 12:30:13 -0700 (PDT)
Message-ID: <64cc5707-8187-40e0-b1d1-0b084aa768ce_at_googlegroups.com>


My db design is based on atomic structures. I am the only one who has achieved db design at the level of atomic structures. Date & Darwen are bluffing with 6NF. In fact, they just said what atomic structures should look like, which is clear to everyone. What is only important, they have not solved problem. This is the next question: how to get atomic structures and what is the appropriate theory.

The second important thing is that I'm not based on predicates, but on concepts. Concepts are at a higher level of generality than predicates.

The third important thing in my db solution, I only have the add operation. I don't have any other data operation. For example, I do not have a "delete" or "update" operation on some data.

Date & Darwen make the most simple examples in their book Temporal Data and the Relational Model, so we cannot accept that as a theory. For example, they have an example, which has one relation and a simple key.

Date & Darwen make the most simple examples in their book Temporal Data and the Relational Model, so we cannot accept that as a theory. For example, they have one relation and a simple key.

RM accepts "Anchor Modeling". For example, in the paper "Anchor Modeling", which received the first prize at the World Congress, there is the following text "using the Sixth Normal Form" in the title of the paper. There is real chaos here.

The Sixth Normal Form has some "dependencies" and the goal is atomism. However, "Anchor Modeling" has an "Anchor technique" that is the opposite of normal forms. Various changes to "Anchor" accumulate here. I personally could not find a single atom of science in this compound of RM and AM.

Finally, let's mention that Codd chose the surrogate key as the entity key, which is contrary to his previous theory. What's wrong too, this Codd key is invisible to database users.

Vladimir Odrljin Received on Sun Oct 13 2019 - 21:30:13 CEST

Original text of this message