Re: Principle of Orthogonal Design
Date: Sun, 20 Jan 2008 04:40:45 -0800 (PST)
Message-ID: <788ddeef-803e-4043-844d-1435af75b132_at_d21g2000prf.googlegroups.com>
On 19 jan, 16:55, mAsterdam <mAster..._at_vrijdag.org> wrote:
> Jan Hidders wrote:
> > mAsterdam 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
>
> below: EE
>> >> If you have a tuple-type, make sure to have only one base
> >> 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):
> >> 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.
>
> We agree on that, that is clear.
> So ok, but - from the huge category of easily asked but
> hard to answer questions: - why?
>
> Why doesn't the (strong) PoOD make sense to you?
It is at the same time too strong and too weak. It is too strong because it forbids cases where there is in fact no redundancy, and at the same time allows cases where there is redundancy. Moreover, you can always trivially satisfy it by renaming R(a,b) to R(r_a,r_b). How exactly does that improve the design?
> It does not make sense to me, and I am putting some effort
> into finding out why it doesn't. The track I am on now gives
> rejection because of inappropriate equalization of meaning
> with form (i.c. the heading).
> This track does not give me any distinction between the validity
> of the strong (EE: original) and the weak (EE: extended)
> PoOD, because both build on the sentence quoted hereunder.
> >> EE: 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".
>> >> With this trick, meaning is forced into synonymity with the
> >> 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.
> >> signature of the relation.
>> > the tuple constraint that b <= 5. In that case you cannot construct a
> > 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
> > tuple that is both in R and S, but they still have the same header.
>
> Which could be rephrased as different B domains for R and S (so that
> R, S becomes an acceptable schema to PoOD), but I won't for the sake
> of argument.
For the sake of the argument, please do. :-) It would allow me to reply with the following: In that case there is still a counterexample, namely if there is a tuple constraint a < b for R and a >= b for S. Of course if you want, you can redefine the notion of header such that this is also included.
> > 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.
>
> Maybe, but it would not take away my objection.
> As long as R\S and S\R are allowed to be non-empty,
> R and S are independent, regardless of their heading.
In that case you still might have redundancy. If you decompose in to the following three, R' = R/S, RS' = R intersect S, S' = S/R, then you have removed that redundancy. That's the motivation if the definition of "overlapping meaning" that I gave.
- Jan Hidders