Re: Principle of Orthogonal Design

From: mAsterdam <>
Date: Fri, 18 Jan 2008 20:52:54 +0100
Message-ID: <47910261$0$85796$>

Jan Hidders wrote:
> mAsterdam wrote:
>> Jan Hidders wrote:
>>> Anyway, the stronger POOD that requires that headers are distinct
>>> sounds like nonsense to me. Why would R(A, B) be a worse design than
>>> R(R_A, R_B)?
>>> The weaker POOD looks more interesting to me. I even found a published
>>> paper about it:

>> Unfortunately the link times out.
> Hmm, not for me. But to help you out:

Thank you for helping me out by providing the document.

I started reading "Extended Principle of Orthogonal Design" by Erki Eessaar

User defined datatypes (UDT) give the designer of a database more decisions, more room for wrong decisions. Row-, array-, reference-, multiset collection types - choices, choices, choices.
How to deal with that freedom?
Enter the Principle of Orthogonal Design (POD):
If you have a tuple-type, make sure to have only one base relvar for recording that tuple-type.
Nonloss decomposition is explained briefly.

And here is where I lost Date & McGoveran (or Erki Eessaars interpration, I don't know) in Chapter 2):
"The meanings of R1A(t) and R1B(t) are said to overlap iff it is possible to construct some tuple t so that R1A(t) and R1B(t) are both true".

Note that it does /not/ say 'all tuples t', but 'some tuple t', So it does, in particular, /not/ exclude the possibilty that R1A(t') is true and R1B(t') is not true or vice versa, in other words, that R1A and R1B may be mutually independent. With this trick, meaning is forced into synonymity with the signature of the relation. I call BS. Guidelines to reduce design choices are welcome, but not this one.

The extended version (Chapter 4.2.) implicitly uses the same criterion for detecting "overlapping meanings".

Brian Selzer (elsewhere in this thread) did a good job by providing a sensible situation with two relations with the same signature but distinct, independent meanings.

Let's not extend this.

What you see depends on where you stand.
Received on Fri Jan 18 2008 - 20:52:54 CET

Original text of this message