Re: Principle of Orthogonal Design

Jan Hidders schreef:
> mAsterdam wrote:

>> Jan Hidders wrote:
>>> mAsterdam wrote:
>>>> Jan Hidders wrote:
>>>>> mAsterdam wrote something very much like:
>>>>>> Pragmatical redefinitions must be temporary and tracked.

>> Joachim Hereth also uses examples where there is no
>> distinction between attribute and type.

'usual' depends on what you are used to. "In theory the difference between practice and theory is due to practical considerations that theorists find it impractical to fit into their theories." (http://www.kettering.edu/~jhuggins/humor/theory.html) With this piece of folklore from the village of theory practitioners in effect we exclude 'type' from the topic, and in the end - if something useful comes up we check what (if anything) is needed for generalization. I have seen it before somewhere, but during this thread I was not aware of it until this post.

Your mentioning this simplification puts (for me - not for someone who indeed considers this step usual) a light on the original PoOD. A little rephrasing here and there makes me understand the whole discussion much better. It looks valid, and with it, I think I can overcome the problems induced by my not being able to "grasp all the consequences of making attributes and types indiscriminate". E.g. if there is only one attribute-type, it is immediately clear that the number of attributes determines the tuple-type; at some point I did put a question mark when you made a remark to that effect.

Thank you.

> Technically there's not much difference between those two points of
> view.
>

>>>>>> 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.
>> My demand to get irrelevant stuff out of scope?

It is a sidetrack.
If I would have known that all attributes are (for the sake of simplicity assumed to be) of the same type, I would not have proposed it. Retract.

[snip]

>>>> 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.
>> Ah... (<=== sigh of relief), now that is a lot
>> stronger than my reservation.
>>
>>> But if you insist and want a name for that kind of thing
>> I don't. I prefer to completely throw
>> "...type-compatibility as we define it
>> requires the two tables to have identical column names."
>> out - which is what you seem to be doing. Are you?

So far, so good.

> For type-compatibility as a prerequisite for taking
> the union of two relations I am not.

Just when I thought I was starting to understand ..

--
What you see depends on where you stand.