Re: domain questionnaire

On 24 Feb 2001 12:45:02 GMT, hidders_at_REMOVE.THIS.win.tue.nl (Jan Hidders) wrote:
>> >> How can you compare two objects, if you don't have their
>> >> identities separate before hand?
>> >
>> >By having some way to refer to them. That is not the same as knowing
>> >how to identify them, i.e., determine if two references refer to the
>> >same object. You know, "morning star", et cetera.
>>
>> We're getting very Lewis Carroll here, "What do you call the name of
>> the song?" she asked. There are many, many subtle complexities. How
>> would you model the morning star issue in relational terms? <g>
>
>Well, deciding how the tables will look is not a problem. In both
>cases you get a table with a PK 'name' and some attributes of the
>planet. But where you might go wrong is in the interpretation of this
>table. What does a record mean? The wrong interpretation is that every
>record represents a different planet. The right interpretation is that
>every record represents the fact that a certain planet with that name
>has the attributes as mentioned in the record.

Of course. That is, I agree. But, what if I thought I was building a table of celestial objects? That is, are you suggesting that PKs are always labels only, and may or may not indicate things which are actually distinct in the world? That would seem to take the punch out of the PK concept.

Or, it would mean that databases are bases of data, and not bases of real-world objects -- or even bases of data accurately representing (and THERE is a word with huge philosophical debates about it!) real-world objects. I'm fine with that, but I'm not sure how many other people would be.

>> Once you allow for identity, you may need to reify other things that
>> relational has always treated as metadata -- timestamps and ordering
>> come to mind.
>
>I don't really agree. For introducing time stamps you don't need to
>change the relational model. You just need to reconsider very carefully
>what exactly the facts are that every record represents.

The "timestamp" I had in mind was the SQLServer use of the term, where it represents the time at which a record is updated. This has no necessary connection with the object in the world, it is metadata from the perspective of the application domain. And, I don't know of any license in the traditional relational model for mixing metadata in at the tuple level (yes, Codd did require that table definitions -- the original metadata -- be available itself in table form (and I have always sort of wondered why, and more or less considered it a mistaken requirement, although it is a useful feature and I can see no theoretical harm to the main model by its inclusion)).

J. Received on Sat Feb 24 2001 - 20:50:02 CET