Re: Principle of Orthogonal Design
Date: Thu, 24 Jan 2008 02:58:48 -0800 (PST)
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?
>> > considering have to cover all the attributes of the involved
> > 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
> > relations.
> Your definiens is close to D&M's ╣▓, even the isomorphism
> requirement is now there ('cover all the attributes'), with
> an added application restriction to inclusion dependencies.
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.
> 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
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.
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.
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?
> Does PoODling flush bathwater, baby, or part of both?
> The jury isn't even out yet.
- Jan Hidders