Re: Principle of Orthogonal Design

From: Brian Selzer <>
Date: Mon, 28 Jan 2008 14:29:22 GMT
Message-ID: <6Flnj.893$>

"Jan Hidders" <> wrote in message
> On 28 jan, 02:12, mAsterdam <> 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}

    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
Received on Mon Jan 28 2008 - 15:29:22 CET

Original text of this message