# Re: Principle of Orthogonal Design

Date: Sun, 27 Jan 2008 12:15:44 -0800 (PST)

Message-ID: <dd210de6-d5cb-40a7-bfe7-567ed370b242_at_f47g2000hsd.googlegroups.com>

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