Re: Principle of Orthogonal Design

From: Bob Badour <>
Date: Sun, 27 Jan 2008 09:28:11 -0400
Message-ID: <479c86f1$0$4043$>

David Cressey wrote:

> "Jan Hidders" <> wrote in message

>>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? Received on Sun Jan 27 2008 - 14:28:11 CET

Original text of this message