Re: Authoritative References

"Laconic2" <laconic2_at_comcast.net> wrote in message news:rcidnRoyEf3HtvzcRVn-gQ_at_comcast.com...
>
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:wU58d.172724$D%.67806_at_attbi_s51...
>
> > Cool! So suddenly I'm less clear on what the essential
> > difference between a relation and a function is. Now
> > it seems like it's just two ways of looking at the same
> > thing, since both must have a key, and may have more
> > than one. Perhaps the differences is simply that of
> > saying (n, m) for the relation and n -> m for the
> > function. Hmmm.....
>
>
> You probably already know all this, but it's better to make it explicit.
>
> Going back to the math, a function has only one value, a relation does
not
> necessarily. Thus Cosine is a function, but Arc Cosine is a relation.
> That is, there is a whole set of angles whose cosine have the same value.
>
> Now let's go back to data. "Find all the employees who live in Nashua,
NH."
>
> In the most usual design of personnel data, it's going to look like this:
>
> select employee_id, first_name, last_name
> from employees
> where city = 'NASHUA' and state = 'NH'
>
> Now, the fact that we are working with a relation here, rather than a
> function, is predicated on the fact that the result is a set, not an
> individual employee. There is a unique key here, but it didn't determine
> the answer.
>
> If you restrict your self to a functional view, "Where does employee with
> id = 12345 live?" is an easy question to phrase.
> But the previous question is not.

It is just as easy to work with functions both when looking at only one element in the domain of the function and when looking at the function as a whole. A function is a set, afterall. You are correct about the difference. If the domain of your function contains sets (of key parts) and the range of the function contains sets, then you can have a function with one "point" like:

Person({"12345") = {{"John"}, {"Doe"}, {}, {"jdoe_at_aol.com",john_doe_at_tincat-group.com}}

This works very well with OOP and XML, for example and it also shows how process and data are so connected -- it's all functions! The Person function takes input and gives output. Queries in databases with this model use similar query languages with different names, but a query for "Find all the employees who live in Nashua, NH." might look like:

List Employees with City = "Nashua" and State = "NH"

And then the query for the e-mail addresses of thesee same folks would be

List Employees with City = "Nashua" and State = "NH" EmailAddresses

Everything in this query is viewed in terms of the function Employees. This is independent of where the data are stored -- this is the logical model of the data. It is not in 1NF (although the physical model could be if so desired) because of the "graph" functions (linking to whatever data are relevant) that operate on it and it can handle these queries using set functions.

While this model maps handily to a SQL-based model, the reverse is not the case, largely because there is an ordering to any values that are lists (such as the e-mail addresses) and because virtual fields in specific databases, such as Oracle (stored procedures), will not return lists.

--dawn Received on Mon Oct 04 2004 - 15:10:55 CEST