Re: database systems and organizational intelligence

Hell, with a big enough hammer you can smash any square peg into a round hole, but that don't make the peg round.

Okay, you both win. I give up. As Dorothy Parker said when asked to use the word, "horticulture" in a sentence, "You can lead a horticulture, but you can't make her think."

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40b64920$0$48959$e4fe514c_at_news.xs4all.nl...
> Alan wrote:
>
> [snip]
> > In
> > relational theory, a functional dependency is not a relation. A relation
is
> > a set. A functional dependency specifies constraints between attributes
of
> > the set.
> > Here's an example of a relation:
> >
> > STUDENT(Name, SSN, HomePhone, Address, Age, GPA)
> >
> > There is a functional dependency SSN -> (uniquely determines) Name, for
> > example.
>
> Couldn't the functional dependencies you stated here be
> relationally expressed? Like so:
>
> +--------------------------------------------------+
> |Predicate: |
> |The value of the attribute identified by |
> | <Dependent> is uniquely determined by the |
> | value of the key identified by <DependentOn> |
> +--------------------------------------------------+
> | FD |
> +--------------------------+-----------------------+
> |Dependent : AttributeName | DependentOn : KeyName |
> +==========================+=-=-=-=-=-=-=-=-=-=-=-=+
> | Student.Name | Student.SSN |
> | Student.HomePhone | Student.SSN |
> | Student.Adress | Student.SSN |
> | Student.Age | Student.SSN |
> | Student.GPA | Student.SSN |
> +--------------------------+-----------------------+
>
> > Do you see any functions there?
>
> *If* we would have a situation were all attributes are
> only dependent on the key (that is if it would be sufficently
> normalized), we would see:
> DependentOn = IsUniquelyDeterminedBy(Dependent)
>
> Just to counter the counterintuitive part:
> Every <Dependent> fed to the function IsUniquelyDeterminedBy
> gives you one <DependentOn>.
>
> (aside: in the above relation "FD" the attribute "Dependent"
> would then become the whole key, hence the =-=- ).
>
> > Here is a function:
> >
> > num_Business_Days = (DELTA(start_date, end_date))
> >
> > Looky. There is data USED in the function.
> >
> > That's all there is to it. You can twist it around any which way you
like,
> > but a functional dependency is not a relation. Period. Perhaps you
should
> > open an argument clinic. And I don't mean arguments to a function.
>
> [snip]
> > Terrific, but this discipline is Relational Database Theory, and
> > while derived from mathematics, we have our own definitions.
> > Best to use _those_.
>
> Ok. Which? Where do they differ?
>
> [snip]
> >> Types, Constraints, and other Rules for the data.
> >> This is where OO starts to come in to play, but we are talking
> >> about Relational Theory, not OO. This is a whole 'nother can of
worms...
>
> Well, yes. But I don't mind getting my hands dirty.
> The use of exclusive terminology alienates "the other camp".
> I am trying to avoid that.
>
> I once heard about the OO smokescreen conspiracy -
> there is a relational smokescreen conspiracy as well.
>
> >>>>>The cdt glossary was written by whom? They have what credentials?
> By you, your credentials, if you care to contribute.
>
>
Received on Fri May 28 2004 - 00:31:25 CEST