Re: Principle of Orthogonal Design

On 22 jan, 19:57, mAsterdam <mAster...@xxxxxxxxxxx> 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.

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?

-- Jan Hidders
.

Relevant Pages

  • 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
    ... "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
    ... "meaning" is only something that can be obtained via situated ... inclusion dependency --> meaning overlap ... An inclusions dependency implies meaning overlap. ... "No coffee, the pressure will get too high. ...
    (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)