Re: Principle of Orthogonal Design(B

On 22 jan, 20:37, mAsterdam <mAster..._at_vrijdag.org> wrote:
> 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

>

>


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

>


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

>

Not if the empty set is a candidate key of S.

• Jan Hidders