Re: Principle of Orthogonal Design

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

Relevant Pages

  • Re: Principle of Orthogonal Design
    ... "meaning" is only something that can be obtained via situated ... inclusion dependency --> meaning overlap ... An inclusions dependency implies meaning overlap. ... Under their definition of the POOD rule, yes, but not under mine. ...
    (comp.databases.theory)
  • Re: Principle of Orthogonal Design
    ... seems to head towards very slippery ground. ... "meaning" is only something that can be obtained via situated ... inclusion dependency --> meaning overlap ... How does the meaning overlap with simple RI? ...
    (comp.databases.theory)
  • Re: Principle of Orthogonal Design
    ... seems to head towards very slippery ground. ... "meaning" is only something that can be obtained via situated ... with the the most simple form of inclusion dependency: ... How does the meaning overlap with simple RI? ...
    (comp.databases.theory)
  • Re: Principle of Orthogonal Design
    ... 'collectivize' under a single predicate, ... "meaning" is only something that can be obtained via situated ... inclusion dependency --> meaning overlap ...
    (comp.databases.theory)
  • Re: Starbucks charges more for iced coffee than hot coffee.
    ... was to coffee, not sandwiches. ... Your clear meaning was that there were a significant group of people ... machines and laud Starbucks as producing palatable coffee. ... what was the point of your original post? ...
    (alt.coffee)