Re: Do Data Models Need to built on a Mathematical Concept?

"Neo" <neo55592_at_hotmail.com> wrote in message news:4b45d3ad.0305041555.283d5994_at_posting.google.com...
> > You are confusing domains and relations.
>
> I will explain my understanding so you may correct me.
>
> I see a relation as a set(person).
> Each tuple as an element(john, mary,..) of the set.
> A tuple's attributes(gender,height) are properties of the
> element(john).
> The tuple itself represents john and no one attribute of the tuple is
> john.
>
> A domain is the set of acceptable values for an attribute of a tuple.

Well, uh, actually, that's right on.

> > If you want to think about "things in reality" (not the best
> > idea) then you should think of them as being individual
> > values in the database. That is, what's in one specific attribute
> > of one specific row of a relation is a "thing in reality." *Not*
> > a row.
>
> IMO, each tuple(row) can represents a thing in reality.
> A row itself in a table named Person represents a person, regardless
> of how many attributes it has.

Sure. In fact, we can refine that further. A table named Person (Persons is better) represents a *predicate* along with a (possibly empty) set of *propositions* that conform to that predicate. Thus:

Table Persons (Name string, heigh int, sex enum('Male', 'Female'))

The predicate is:
There exists a human called *Name* whose heigh in inches is *Height* and whose sex is *sex.* (Strictly speaking, it's incorrect to say "gender" and I'm a pedant, so there you are.)

The value of the table could be as follows:

"John Smith", 72, Male
"Mary Jones", 64, Female

Now here's the thing: what kinds of questions can we ask of this table? We can ask it, how many people are less than ten feet tall? How many men are there? Are there more men than women? How many people have a name that starts with "j"?

But we *can't* ask it things like, what kind of gas mileage does a Saturn get? How many chairs go on that airplane? What is the sound of one hand clapping?

The questions we can ask are strictly bounded by the predicate.

It is the predicate that enables us to ask questions, not the data itself. If I just had the data and no predicate, what could I ask? How many times does the number 72 appear in the second column? How many different values are there in the first column? Etc. These questions have no value.

You've expressed the desire to be able to work with sets of just anything. Well, that's okay. You can have a user defined type (UDT) that can hold your just-anything data and put it in a table. If you want to associate other data with your just-anythings, you can do that too, with the usual relational techniques. But what kind of questions can you ask about just-anything? Only those questions that can be expressed on values of your user defined type.

The key limitation is that without a predicate, you can't ask useful questions. This limitation comes from semantics, not from the relational model.

If I understand what you're trying to do, then to succeed, you'll need a way to dynamically make new predicates. Just storing arbitrary dynamic structured data is no big deal; it's not even very hard. But if you can figure out a way to dynamically create meaning, that would be huge.

Marshall

PS. My best guess is that it's impossible, but I've been wrong before. Received on Mon May 05 2003 - 03:30:01 CEST