Re: Principle of Orthogonal Design

On 23 jan, 16:00, mAsterdam <mAster..._at_vrijdag.org> wrote:
> Jan Hidders wrote:
> > mAsterdam wrote:
> >> Jan Hidders wrote:
> >>> mAsterdam wrote:
> >>>> Jan Hidders wrote:
> >>>>> JOG wrote:
> >>>>>>>>> ... I certainly find that appealing to notions
> >>>>>>>>> of "meaning" within formal design recommendations
> >>>>>>>>> seems to head towards very slippery ground.
> >>>>>> ... Years of working with the semantic web,
> >>>>>> ontologies, expert systems, etc have emphasised to me that
> >>>>>> "meaning" is only something that can be obtained via situated
> >>>>>> embodiement within the environment concerned, and that context is
> >>>>>> far too  complex a beast to be tamed by computerized encoding.
> >>>>>> As such I'd rather rules appealed to functional dependencies and
> >>>>>> logical consequents than to appeal to the slippery notion of
> >>>>>> "meaning".
> >>>>> Hear hear. But I think the part of POOD that actually does make sense
> >>>>> and really removes redundancy and update anomalies can be defined that
> >>>>> way. For example, if there is an inclusion dependency between a
> >>>>> relation R and S then it makes sense to say that there is overlap in
> >>>>> meaning.
> >>>> ?
> >>>> inclusion dependency --> meaning overlap
> >>> Yes. An inclusions dependency implies meaning overlap.
> >>> It is a sufficient condition, but not a necessary one.
> >>>> ?
> >> The easiest case of meaning overlap, then, should be
> >> with the the most simple form of inclusion dependency:
> >> RI, the foreign key.
> >> How does the meaning overlap with simple RI?

>


> > Well, if you have R(a,b) and S(c,d) and a FK R[a,b] to S[c,d], then


> > there is meaning overlap. The inclusion dependencies we are

>

Correct. A small but very important difference.

> The defieniendum 'meaning overlap' is defined even
> narrower again.

Correct. I wanted to start simple. So you would like a wider definition? Your wish is my command:

DEFINITION: Two relations R and S are said to have overlap in meaning if there is a dependency that requires that sometimes some tuples of R are also in S after renaming the attribute names, or vice versa.

It's a bit hand-wavy for my taste, because it doesn't define the type of dependencies but it will probably do for the moment.

> An inconvenient implication:
> "In other words, such an 'individual user database' ought
> not to include any views and/or base tables whose meanings overlap" ²
> together with your definiens gives: all foreign keys are out.

Under their definition of the POOD rule, yes, but not under mine. Btw. normalization rules never should be applied to views, only to base tables, and it is a normalization rule we are talking about here.

Unfortunately I also just noticed a related flaw in my POOD rule, so I'm going to have to redefine it slightly. First some additional terminology:

DEFINITION: A join dependency is said to be a proper if it does not hold that any of its components is a subset of another component.

Now the rule:

DEFINITION: A schema is said to violate POOD if it contains relations R and S such that a component C of a proper join dependency of R overlaps in meaning with a component D of a proper join dependency of S, and either R and S are different, C and D are different, or both.

> > So far so good?

>

I suspect with the new POOD the baby is quite safe. :-)

• Jan Hidders