# Re: Principle of Orthogonal Design

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Fri, 18 Jan 2008 20:52:54 +0100
Message-ID: <47910261\$0\$85796\$e4fe514c_at_news.xs4all.nl>

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

```>> Unfortunately the link times out.
>
>

```

Thank you for helping me out by providing the document.

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.

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