Re: Principle of Orthogonal Design

On 27 jan, 14:28, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> David Cressey wrote:
> > "Jan Hidders" <hidd..._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.
>
> I might suggest: "Inferable from the definition."

Yes. A good suggestion.

> Presumably one can infer (calculate/prove) from the definition of FK that:
> FK a,b -> a
>
> Or did he mean FD above instead of FK?

Yes, I did. Apologies for the typo.

• Jan Hidders