Re: Principle of Orthogonal Design

"Jan Hidders" <hidders_at_gmail.com> wrote in message news:c4a59c20-5686-4f4a-aa43-512cdee1df64_at_d70g2000hsb.googlegroups.com...
>
> 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 :-)
> >

It's even further over my head.

> > >>> 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} ].

I really need to understand the word "trivial" as used above in a more careful manner than I do.

Unfortunately, my intuitive grasp of the word "trivial" comes from hearing it used by engineers rather than mathematicians. When engineers use the word "trivial", there is almost always an overtone of snobbism present. A problem is "trivial" if it's unworthy of the attention of someone so important as the person speaking. It should be assigned to a "junior" person.

In mathematics, the "trivial case" is almost always easy, but easiness is not what relegates it to triviality. It's more like "orthogonality to the peculiarities of the item under discussion", or something like that.

So I need to understand "trivial dependencies", in a really tight fashion. My loose understanding of one form of trivial dependence is that a component of a composite key is trivially dependent on that key. In this case, "trivial" means, to me, that the dependency provides no additonal information about anything. The sort of thing that, in common parlance, would draw the response, "well, duh!"

But I don't have a general understanding of what makes trivial dependencies trivial. Received on Sun Jan 27 2008 - 13:49:20 CET