Re: Principle of Orthogonal Design

On 23 jan, 16:00, mAsterdam <mAster...@xxxxxxxxxxx> 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
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.

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?

Does PoODling flush bathwater, baby, or part of both?
The jury isn't even out yet.

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

-- Jan Hidders
.

Relevant Pages

  • 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: 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. ... "No coffee, the pressure will get too high. ...
    (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
    ... I started reading "Extended Principle of Orthogonal Design" ... Why doesn't the PoOD make sense to you? ... meaning is forced into synonymity with the ... As long as R\S and S\R are allowed to be non-empty, ...
    (comp.databases.theory)