Re: database systems and organizational intelligence

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                                               |
+--------------------------+-----------------------+

+==========================+=-=-=-=-=-=-=-=-=-=-=-=+
| 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 Thu May 27 2004 - 22:01:37 CEST