# 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