Re: Principle of Orthogonal Design

On 18 jan, 20:52, mAsterdam <mAster..._at_vrijdag.org> wrote:
> 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:
> >>>http://www.wseas.us/e-library/conferences/2006madrid/papers/512-451.pdf
> >> Unfortunately the link times out.
>
> > Hmm, not for me. But to help you out:
>
> >http://www.adrem.ua.ac.be/bibrem/pubs/pood.pdf
>
> 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.

Hmm, I would call that the strong POOD (or strong POD), and that, I would agree, seems to make no sense.

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

No, no, not exactly. It could be that there are tuple constraints that don't allow you to construct the tuple in question. Say you have R(a,b) and S(a,b) and for R the tuple constraint that b > 5 and for S the tuple constraint that b <= 5. In that case you cannot construct a tuple that is both in R and S, but they still have the same header.

What they probably should have said is: R and S are said to have overlapping meaning if it does not follow from the constraints / dependencies that the intersection of R and S is always empty.

Note that I'm talking about dependencies and not the relvar predicates as they do, but the intent is the same. So this, or rather the design principle based on this definition, I would call the weak POOD. Does that make more sense to you?

• Jan Hidders