Re: Principle of Orthogonal Design

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 23 Jan 2008 16:00:35 +0100
Message-ID: <479755b9$0$85777$e4fe514c_at_news.xs4all.nl>


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
> considering have to cover all the attributes of the involved
> 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.

The defieniendum 'meaning overlap' is defined even narrower again. Let me try an analogy here. Our coffeemachine design and test team, defines 'coffee' as 'the substance we can put in the coffeeholder of our espresso machine without wrecking the machine.' Chris: "Let's try caustic soda."
David: "No coffee, the pressure will get too high.

        Tea is good coffee, though."
Chris: "When the beans are grinded too fine the stuff

        will clutter the sieve".
Jan: "We'll have to exclude that, to."

It is meaning overlap, Jim, but not as we know it.

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.

I'll repeat that: all foreign keys are out.

¹ "The Principle of Orthogonal Design" draft, Date & McGoveran part 1: http://www.dbdebunk.com/page/page/622331.htm ² idem part 2: http://www.dbdebunk.com/page/page/622312.htm

>>>> Slowly, please - where has the 'might' (from the redundancy in
>>>> your other post) gone?
>>> That applied to my improved version of EE's definition of meaning
>>> overlap. Under the definition I'm using here this "might" has 
>>> become a "must".
>> Another change of the definition of meaning overlap? To what?

>
> Ok. For the time being I promise to stick to the following definition:
>
> DEFINITION: Two relations R and S are said to have overlap in meaning
> if there is an inclusion dependency from all attributes of R to all
> attributes of S, or vice versa.
>
> Once you are comfortable with this we can move on the the more subtle
> cases of meaning overlap. To be complete let met also fix the POOD
> rule for the moment:
>
> DEFINITION: A schema is said to violate POOD if it contains two
> different relations R and S such that a component of a non-trivial
> join dependency of R overlaps in meaning with a component of a non-
> trivial join dependency of S.
>
> So far so good?

Does PoODling flush bathwater, baby, or part of both? The jury isn't even out yet. Received on Wed Jan 23 2008 - 16:00:35 CET

Original text of this message