# Re: Principle of Orthogonal Design

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Tue, 22 Jan 2008 20:37:48 +0100
Message-ID: <47964552\$0\$85796\$e4fe514c_at_news.xs4all.nl>

```> 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> R1 { X INTEGER, Y INTEGER }
>>>> OP> R2 { A INTEGER, B INTEGER }
>>>> 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.

(Unicode)
> :-) 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