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>
>>> 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. :-)
>>> 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.
>>> 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.
Date: Tue, 22 Jan 2008 20:37:48 +0100
Message-ID: <47964552$0$85796$e4fe514c_at_news.xs4all.nl>
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> 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