Re: Principle of Orthogonal Design

From: mAsterdam <>
Date: Mon, 21 Jan 2008 00:35:39 +0100
Message-ID: <4793da87$0$85782$>

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:
>>>>>> Unfortunately the link times out.
>>>>> Hmm, not for me. But to help you out:
>>>> 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> 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.

Redundancy in what sense?

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

I can see that it is a lossless decomposition. What I don't see is which update anomaly is prevented by it. If I apply it to less abstract relations (say Brians example), I find myself having much more difficulty to come up with sensible predicates for R' , S' and especially for RS'. This makes me suspicious.

> 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

Original text of this message