Re: domain questionnaire

JRStern wrote:
> On 24 Feb 2001 12:45:02 GMT, hidders_at_REMOVE.THIS.win.tue.nl (Jan
> Hidders) wrote:
> >
> >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.

Hmmm, I don't think so. The PK assumption holds for all relations; those that represent entities and those that represent relationships. The only thing that happens is that you become more conscious of the fact that the relations that represent entities in some sense also represent relationships. But the distinction between entity-relations and relationship-relations is not really clear cut anway.

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

Maybe you should keep in mind that a data model is not a model of reality but a model of the model that the users of the system have of (some part of) reality. So if these people agree with the model then the modeler has done his job well.

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

Sure, but you could also say that the predicate P(x) that is associated with the table is now changed into P(t,x) with the meaning that at time t it was true that P(x). Or, if you want to be even more careful, that at time t somebody told the database that P(x) was true. Or even better, the predicate P(t',t,x) meaning that at time t' the database was told that at time t the proposition P(x) was true.

> 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)).

There are more or less two reasons. The first is sort of the put-the-meta-data-where-your-mouth-is argument; if you claim that the relational model is the best way to represent any kind of data, then surely it is also the best way to store the meta-data. The second one is more practical and goes like this: if you've got a nice language for querying and updating the data then why not let the user use the same language for querying and updating the meta-data? This not only saves some coding but also makes life easier for the users.

-- 
  Jan Hidders