Re: Principle of Orthogonal Design
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 27 Jan 2008 09:28:11 -0400
Message-ID: <479c86f1$0$4043$9a566e8b_at_news.aliant.net>
>
> It's even further over my head.
>
>
> 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.
Date: Sun, 27 Jan 2008 09:28:11 -0400
Message-ID: <479c86f1$0$4043$9a566e8b_at_news.aliant.net>
David Cressey wrote:
> "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.
I might suggest: "Inferable from the definition."
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?