Re: Principle of Orthogonal Design

Jan Hidders wrote:

> mAsterdam wrote:

>> User defined datatypes (UDT) give the designer of a database
>> more decisions, more room for wrong decisions.
>> Row-, array-, reference-, multiset collection types
>> - choices, choices, choices.
>> How to deal with that freedom?
>> Enter the Principle of Orthogonal Design (POD):
>> If you have a tuple-type, make sure to have only one base
>> relvar for recording that tuple-type.

> 
> Hmm, I would call that the strong POOD (or strong POD), and that, I
> would agree, seems to make no sense.

We agree on that, that is clear.
So ok, but - from the huge category of easily asked but hard to answer questions: - why?

Why doesn't the (strong) PoOD make sense to you?

It does not make sense to me, and I am putting some effort into finding out why it doesn't. The track I am on now gives rejection because of inappropriate equalization of meaning with form (i.c. the heading).
This track does not give me any distinction between the validity of the strong (EE: original) and the weak (EE: extended) PoOD, because both build on the sentence quoted hereunder.

>> EE: Chapter 2:
>> "The meanings of R1A(t) and R1B(t) are said to overlap
>> iff it is possible to construct some tuple t so that R1A(t)
>> and R1B(t) are both true".
>>
>> Note that it does /not/ say 'all tuples t', but 'some tuple t',
>> So it does, in particular, /not/ exclude the possibilty
>> that R1A(t') is true and R1B(t') is not true or vice versa,
>> in other words, that R1A and R1B may be mutually independent.
>> With this trick, meaning is forced into synonymity with the
>> signature of the relation.

> 
> No, no, not exactly. It could be that there are tuple constraints that
> don't allow you to construct the tuple in question. Say you have
> R(a,b) and S(a,b) and for R the tuple constraint that b > 5 and for S
> the tuple constraint that b <= 5. In that case you cannot construct a
> tuple that is both in R and S, but they still have the same header.

Which could be rephrased as different B domains for R and S (so that R, S becomes an acceptable schema to PoOD), but I won't for the sake of argument.

> What they probably should have said is: R and S are said to have
> overlapping meaning if it does not follow from the constraints /
> dependencies that the intersection of R and S is always empty.

Maybe, but it would not take away my objection. As long as R\S and S\R are allowed to be non-empty, R and S are independent, regardless of their heading.

> Note that I'm talking about dependencies and not the relvar predicates
> as they do, but the intent is the same. So this, or rather the design
> principle based on this definition, I would call the weak POOD. Does
> that make more sense to you?

Maybe stating the obvious: not really.

I'll try to elaborate:

Design case:
S and R are sets of tuples we are trying to schematize:

If we do not allow R\S and S\R to be non-empty, the R,S design will be rejected, because R and S represent the same set, not because of (weak or strong) PoOD.
If we allow R\S and S\R to be non-empty, R and S are completely independent. If we allow only one of R\S and S\R to be non-empty, one of R and S is a subset of the other.

Wether a tuple in S carries the same meaning as or a different meaning than an identical tuple in R is not based on their having the same signature (heading if you prefer).

This changes when we apply DM Unseen's
'object to role transformation':
Stick the original relation name in a role attribute, like so:

T(role, a, b), role∈{'R','S'},

which forces any stuff together - based on shape, not on meaning.

--
What you see depends on where you stand.