Re: Principle of Orthogonal Design

From: mAsterdam <>
Date: Tue, 22 Jan 2008 20:37:48 +0100
Message-ID: <47964552$0$85796$>

Jan Hidders wrote:

> mAsterdam wrote:
>> Jan Hidders wrote:

>>> mAsterdam wrote: ...
>>>> From JOG's OP:
>>>> OP> Darwen rejected the original POOD paper outright given that
>>>> OP> McGovern posits that:
>>>> OP>
>>>> OP>
>>>> OP> violates the principle, whatever the relations' attribute names.

>>> Interesting. I'm missing the context here, so I'm not sure about their
>>> positions, but I suspect that to some extent both are right. Darwen is
>>> right that McGoverns' definition is probably too strict, but McGovern
>>> is right that the attribute names shouldn't matter. I'll come back to
>>> this later, because I think there is a solution that might be
>>> acceptable for both. Well, acceptable for me, anyway. :-)
>>>>>>> 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?

>>> The same fact being represented in more than one place. Note the
>>> "might have" in the sentence. It could very well be that there is in
>>> fact no such redundancy, even if it does have overlapping meaning
>>> according to my definition. In that sense my definition of overlapping
>>> meaning is still too crude because it is a sufficient condition but
>>> not a necessary condition. This gets even worse if we start ignoring
>>> the attribute names.
>>> Can this be solved with a more refined notion of "overlapping meaning"
>>> that still is defined in terms of dependencies? I think it can. For
>>> that I need a new notion for a certain restricted class of
>>> dependencies: a qualified inclusion dependency. An example of such a
>>> dependency is a constraint like "if R(a=x,b=y) and x > 5 then
>>> S(c=x,d=y)". If such a constraint holds then certain facts represented
>>> in R will also be represented in S, and so there will very probably be
>>> redundancy and update anomalies.
>> The constraint only applies to a subset of R
>> I.o.w. R is a mix of constrained and unconstrained data.
>> We are talking a /design/ principle here, so my question
>> would be: how did these different sets end up disguised
>> as one in the first place?
> Very good point. But note that just horizontally splitting R turns the
> qualified inclusion dependency into a normal inclusion dependency,
> which is a good sign, but does not remove the redundancy.
>> But indeed, redundancy.

>>> In general a qualified inclusion dependency is of the form "if Q1 then
>>> Q2" where Q1 is a conjunction of atoms and simple equations, Q2 is a
>>> single atom, and there is at least one atom in Q1 with the same free
>>> variables as Q2. Such an inclusion dependency is said to hold between
>>> R and S if at least one atom in Q1 that has the same free variables as
>>> Q2 concerns R and the atom in Q2 concerns S.
>>> Our new definition of "overlapping meaning" might then be as follows:
>>> R and S are said to have overlapping meaning if there is a qualified
>>> dependency between R and S or between S and R that does not follow
>>> from the dependencies at relation level.
>> An inclusion dependency on a proper subset would be
>> a tell, right?
> Close, but not exactly. *Every* inclusion dependency in some sense
> causes redundancy, but if the set of attributes in which it ends is
> also a component of non-trivial join dependency, then you can remove
> this redundancy. So that is why the rule should say that only then
> there is a problem.

If the ID 'ends in' S(b),
R(a) レ S(b),
and S(b) is a component of a non-trivial join dependency, S(b) is not in 5NF already.

> :-) FWIW, that works for me also.

☺ - Hmm... Too small, I'll stick with :-) Received on Tue Jan 22 2008 - 20:37:48 CET

Original text of this message