Re: Principle of Orthogonal Design

On 27 jan, 13:20, Jan Hidders <hidd..._at_gmail.com> wrote:
> mAsterdam schreef:
>
> > This is all way over my head. Jan, you may be used to
> > sailing these waters; I am not. I think it is interesting,
> > but very time-consuming.
> > Am I talking rubbish? I try not to, but I don't know - nobody
> > else chimes in. You keep replying, but hey, you are a nice guy :-)
>
> > I'll make some bold statements here anyway, but I can't keep this up.
>
> Your non-bold statements are also be highly appreciated. :-)
>
> Too keep things manageable I'll try to trim the discussion heavily and
> keep what I think is really essential. So if I snip any of your
> comments it is not because I don't think they are interesting, but
> just that at the moment I think they are not at the core of the issue.
>
>
>
> > Jan Hidders wrote:
> > > mAsterdam wrote:
> > >> Jan Hidders wrote:
> > >>> ... I wanted to start simple ...
> > >> Even though this suggests otherwise, I'll risk assuming
> > >> that you understood the coffee analogy, and snipped it
> > >> for focus.
>
> > > I *think* I understood it, but I didn't want to get into a debate
> > > about it's appropriateness. My position is that in this case we don't
> > > really know precisely what this "coffee" thing is anyway. It is a
> > > rather vague and informal notion, so we can take the liberty to
> > > redefined in a way that seems to most practical for the time being...
>
> > Informal as far as most of its nature is concerned, sure.
> > Its existence, however, is neither vague nor informal.
> > Without it, the coffee-machine loses its purpose.
> > It is because of this, that pragmatical redefinitions
> > must indeed be temporary and tracked.
>
> Sure, we agree on that. It's just that I think it is sufficient to say
> at the beginning something like "for this discussion we are going to
> define 'overlapping meaning' as .." and you want to be more careful
> and really use another word. As I already said, I'm fine with that, so
> I don't think more discussion is needed here.
>
> [... very big and painful snip ...]
>
> > 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. Such an operation on its internal organs is going
> to change the relational model beyond recognition. 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.
>
> [... another big and painful snip ...]
>
> > >>> ...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.
> > >> Proper is a nicer than non-trivial.
> > > Note that it's semantically different. Not all proper join
> > > dependencies are non-trivial, and not all non-trivial join
> > > dependencies are proper.
>
> > Thanks, I have to read more carefully.
>
> > Trivial dependencies are the ones implied by the
> > candidate keys.
>
> Not precisely. Trivial dependencies are those that hold in any schema.
> For example the FK a,b -> a is always true as long as you have
> attributes 'a' and 'b' in the header. Another example is the JD
> [ {a,b}, {b,c}, {a,b,c} ] if the attributes in the header are {a,b,c}.
> This is always a lossless decomposition, but also a very redundant
> one. Another is the JD [ {a,b,c} ].
>
> > You include some of those in the problem space
> > while leaving some non-trivial dependencies out based on wether
> > any of its components is a subset of another component?
>
> > Let's see. This is because we are dealing with two relations
> > S and R, and we have to make sure that we get all
> > dependency-overlap, including the overlap of the trivial JD's.
>
> Yes. The intuition is that if there is a JD the relation is in fact a
> combination of one or more predicates namely the ones that correspond
> to each component of the JD. It is for these predicates that we want
> to check overlap. We want to explicitly include the case where it is
> actually just one, so we also want to consider the trivial JD [ {a, b,
> c} ] for the header {a, b, c}.
>
> In that terminology you can also perhaps understand why we only care
> about proper JDs. Suppose we have JD [ {a, b}, {b, c} ]. Then it
> follows that the following JD also holds: JD [ {a}, {a, b}, {b, c} ].
> I think you'll understand that if the first defines a lossless
> decomposition, then so does the second for the simple reason that it
> contains at least as much information as the first. But it is not true
> that the component {a} also necessarily corresponds to some meaningful
> predicate.  In fact, it probably doesn't. So that is why we want to
> exclude those.
>
> Having said that, there are actually more JD's that need to be
> excluded than I initially thought. For example, if the JD [ {a, b},
> {b, c} ] holds then also the JD  [ {a, c}, {a, b}, {b, c} ] holds.
> Also here there is not necessarily a meaningful intuitive predicate
> associated with the component {a, c}. So, at the risk of causing you a
> serious migraine I'm going to have to tweak my definitions a little.
>
> DEFINITION: A join dependency is said to be minimal if there is not
> another join dependency with a set of components that is a proper
> subset of the set of components of the first.
>
> Examples: If JD [ {a, b}, {b, c} ] holds then JD [ {a, b}, {b, c}, {a,
> c} ] is not minimal. The JD [ {a}, {a, b} ] is never minimal because
> the trivial JD [ {a, b} ] always holds.
>
> Note that a minimal join dependency is always also a proper join
> dependency.
>
> The new rule then becomes:
>
> DEFINITION: A schema is said to violate POOD if it contains relations
> R and S such that a component C of a minimal join dependency of R
> overlaps in meaning with a component D of a minimal join dependency of
> S, and either R and S are different, C and D are different, or both.

Oops. The "overlaps in meaning" should of course read "has dependencyinduced  overlap". Please apply Hanlon's razor. ;-)

• Jan Hidders