Re: Principle of Orthogonal Design
Date: Mon, 21 Jan 2008 00:35:39 +0100
Message-ID: <4793da87$0$85782$e4fe514c_at_news.xs4all.nl>
Jan Hidders wrote:
> mAsterdam 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 >>>> 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. >> 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?
Not. But just renaming the attributes does not change the
tuple-type (which I earlier referred to as signature of
the relation), so, while it indeed does not improve the
design, it also has no bearing on satisfying PoOD as
I understand it from EE.
I could not find your definition, BTW.
(After partly rereading this thread:)
It is clear from JOG's OP that renaming the attribute doesn't
PoOdify the design - which made Darwen reject it.
From JOG's OP:
OP> Darwen rejected the original POOD paper outright given that OP> McGovern posits that: OP> OP> R1 { X INTEGER, Y INTEGER } OP> R2 { A INTEGER, B INTEGER } OP> OP> violates the principle, whatever the relations' attribute names. >> 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.
>
> Note that my definition differs in an important way from theirs.
> I forgot to emphasize this the last time.
Your definiton being ... , sorry, I could not find it. I apologize if you have already stated it - could you give your definition (possibly again)?
My remarks thusfar are based on EE's definition of 'meaning overlap'
>>>> 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". >>>> 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. >> 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. :-)
For the sake of the argument, consider it done :-)
> 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.
Nice diagonality.
> Of course if you want, you can redefine the notion of
> header such that this is also included.
I would not know how to do that.
>>> 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,
RS' = R ⋂ S (long live Unicode!)
> S' = S/R,
> then you have removed that redundancy.
> That's the motivation if the
> definition of "overlapping meaning" that I gave.
Somewhere, I must have missed a post.
Could you restate it?
> Actually, to really remove all such redundancy one would would need a
> stronger notion of "overlapping meaning", so we you can also deal with
> overlap modulo renaming, but I don't want to complicate things too
> much at this point.
No hurry, I have patience. I hope you to, because I am enjoying this conversation, but I expect to be rather busy in the coming days.
-- What you see depends on where you stand.Received on Mon Jan 21 2008 - 00:35:39 CET