Re: Principle of Orthogonal Design


"Jan Hidders" <hidders@xxxxxxxxx> wrote in message
news:0a872b75-448e-4131-ba5b-6bcee88da815@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 28 jan, 02:12, mAsterdam <mAster...@xxxxxxxxxxx> wrote:
Jan Hidders wrote:
mAsterdam wrote something very much like:
Pragmatical redefinitions must be temporary and tracked.
Sure, we agree on that.

<unsnip>

Wether the relation between heading and tuples goes
via names or ordering is relevant or not.

If it is not I want it out of scope.

</unsnip>

I don't think that it is possible to get it out of scope. If you think
it is, then by all means provide an equivalent and complete definition
where it is. I'm also not sure what your problem exactly is. We have a
definition that works for the named perspective, which is arguably the
most appropriate for the relational model anyway, so can we now
please, please, please, pretty please, move on with the discussion?


I don't think the definition is sufficient even for the named perspective:
consider

R1 {J, K}
KEY {J}
KEY {K}

R2 {J, A}
KEY {J}
FOREIGN KEY {J} REFERENCES R1

R3 {K, A}
KEY {K}
FOREIGN KEY {K} REFERENCES R1


Supposing that J, K and A have different types and discounting any meaning
attributed by relation names, there is overlap between R2 and R3.

J and K are both keys for R1, so J --> K and K --> J.

And due to the foreign keys between R2 and R1 and R3 and R1:

from J --> K and K --> A, J --> A can be inferred;
from K --> J and J --> A, K --> A can be inferred.

So, if there are tuples {j1, k1} in R1, {j1, a1} in R2, and {k1, a2} in R3,
the database is inconsistent due in my opinion to a POOD violation.

I think, therefore, that you need to adjust your definitions to reflect the
interactions between inclusion dependencies and functional dependencies. I
think the closure of F union I is applicable here, where F is the set of all
functional dependencies and I is the set of all inclusion dependencies.

DEFINITION: Two relations R and S are said to have dependency-induced
overlap if there is a dependency that requires that sometimes some
tuples(1) of R are also in S.

(1) for some definition of tuples that allows restricted
reshuffling of its values. To do.

The only way to achieve (1) so that it also takes all normal inclusion
dependencies into account is to define tuples as something equivalent
to bags of values.

Nice, a third alternative way to state the same relation.
How can this be relevant?

It shows to what unacceptable consequences your demand is leading. It
destroys the relational model as we know it.

Such an operation on its internal organs is going
to change the relational model beyond recognition.

This is hardly surprising when part of the (database local)
definition of relation is under discussion. More specifically:
How do tuples conform to relation headers?

Hm? What makes you think that this is under discussion? As far as I am
concerned we are firmly sticking to the usual definitions.

I'm going to
strongly insist that we stick to the classical definitions of the
named perspective and state in the definition that we are talking
about inclusion up to relabeling:

DEFINITION: Two relations R and S are said to have dependency-induced
overlap if there is a dependency that requires that sometimes some
tuples of R are also in S after renaming the attribute names.

Two glossary todo items: [Trivial](new) and [Type].
The s/meaning overlap/dependency induced overlap/
did help to clarify.

This time 'type' is the label on a jar containing something else.

I don't think I used the word "type" in any of my definitions. I only
mentioned it because you did. You want to redefine that also? Is there
no end to this madness? ;-)

Which 'classical definitions of the named perspective' do you mean?

As in the Alice book. Pretty much *the* authority in the area of
database theory.

Do you have a suggestion for
s/type/$some_name_dependent_notion_similar_to_but_not_the_same_as_type/
in PoOD related discussions ?

Yes, don't. :-) IMNSHO that part of the POOD discussion clearly
doesn't make sense and at best leads only to a crippled version of the
relational model. But if you insist and want a name for that kind of
thing then I can tell that suspect (but might be wrong because it's
not really well defined) that the thing your are talking about is
often called a "named type", and if you want to emphasize that you are
talking about the other kind the term "anonymous type" is often used.

-- Jan Hidders



.

Relevant Pages

  • Re: Principle of Orthogonal Design
    ... the individuals represented are just different kinds of the same sort of ... to functional dependencies and logical consequents than to appeal to ... You can generalize this by defining the notion of overlap ... indeed redundancy. ...
    (comp.databases.theory)
  • Re: Help needed on Boyce-Codd Normal Form.
    ... exactly one teacher. ... But a student can take multiple subjects. ... the other specified dependencies. ...
    (comp.databases.theory)