identifying entities across database updates (was: Is a function a relation?)

Brian Selzer wrote:

>I accept as an axiom that there are objects that can have a location in time
>or space. To formalize this, let C! be a 1-place relation that ranges over
>the objects in the Universe and expresses the property of having a location
>in time and space--that is, being concrete.

Wait. Assuming that objects exist doesn't imply that we can uniquely identify them. You and I, or even I and I, may very well disagree on how to partition the universe into objects, depending on the purpose of our description. How many objects is a chair? How many objects is the character A? Can it be green? Is the chemical element C an object? Is course 430, Database Design and Administration at Moron University, an object? The reconciliation of different, overlapping database schemas, even within the same organization, is an important practical problem. So your relation is rather big. It certainly isn't a normal database relation.

In order to apply the relational model, we don't have to assume the existence of objects at all. It's an extra step you choose to make. Aren't you just complicating matters for ytourself, and for the rest of us?

>Given C!, the properties of
>being ordinary, O!, and being abstract, A!, can be defined. Only those
>objects that can have a location in time or space are ordinary, and those
>are exactly the objects that possibly exemplify C!; every other object is
>abstract and as such cannot have a location in time or space, and the
>abstract objects are exactly the objects that don't possibly exemplify C!.
>
>The integer 5 is an abstract object. Abstract objects do not actually
>exist: they just are.

But can we identify them uniquely? Are the character 'A', the ASCII character 'A', the English character 'A', and the Arial character 'A' the same object, or are they not; if not, how many different objects are they? Why call these things objects at all? Isn't it better to call them something else? 'Values' comes to mind.

>Under the Domain Closure Assumption, the only objects
>that actually exist are those that exemplify C! and are represented in the
>database, but that doesn't mean that abstract objects can't be discussed: it
>just means that the quantifier forall ranges over every object that can
>possibly be, which includes all objects that cannot have a location in time
>and space, all objects that can, but don't, and all objects that actually
>do.

I think that's a bit much to ask. You can't quantify over them unless you know how to find them and to tell them apart.

>It is a consequence of assuming a fixed domain of quantification for
>actual existence to be expressed as a predicate--call it E!. Obviously, E!
>implies C!.

Existence is a property of predicates or properties, not of objects or values. It is nonsensical to state that 3 exists. But I'm not sure that you need O! or E! anyway.

>In contrast to the assignment of the integer 5, which as an abstract object
>does not exemplify C!, for the assignment to PQ to succeed, due to the
>Domain Closure Assumption the objects that each tuple in the relation maps
>to must exist--that is, they must exemplify E! which implies that they must
>exemplify C!. In that sense, the assignment of the relation asserts the
>existence of the objects that its tuples map to, so it's not that much of a
>stretch to say that the relation just sprang into existence. Of course,
>all of this assumes that the user making the assertion is not lying or
>mistaken.

And this is your weak point. You want to express identity beyond identifiability by attributes, but natural attributes are all that we can see, so we have no way of verifying this identity. The usual position is simply not to assume this identity at all: assuming it can only serve to confuse things, by suggesting identifiability that doesn't really exist.

One day, Mary came home from school and her goldfish was floating sideways in its bowl. She ran to her mother and cried: mommy, mommy, Britney is ill! Put your coat on, her mother said, we're taking her to see the doctor. They took the whole bowl into the car, carefully wrapped in a towel to keep Britney from catching a cold, and parked around the corner, right in front of an animal store. Look at these happy little goldfish in the window, said Mary to her goldfish, we're going to make you better and you'll be just as happy as they are.

  http://www.nytimes.com/2004/05/02/magazine/fixing-nemo.html

It took a long wait before the doctor could finally see Mary and her poor little fish. But it was worth it! Don't worry, said the doctor, we have just the treatment for her. By tomorrow, she'll be as good as, erhm, as gold. Mary went home in delight.

The doctor called up the data entry screen and entered:

  patient's name: Brittany
  owner's name: Mary

  type:           goldfish
  healthy:        -

The next day, when Mary returned with her mother, the screen had changed. Now it said:

  patient's name: Brittany
  owner's name: Mary

  type:           goldfish
  healthy:        +

Treatment was unusually difficult, said the doctor, that'll be $100. Now it was Mary's mother's turn to start sobbing. But Mary went home with a healthy little goldfish, and they lived happily ever after.

Later that day, the doctor got a phone call. It was Mary's mother. I refuse to pay that bill, she said, you know why. Prove it, said the doctor. Mary's mother went over to his office and opened the transaction log.

You're essentially saying that, if the doctor's database was designed according to your principles, her malpractice suit will hinge on whether she sees an update or an delete/insert. Is that a reasonable position?

I don't think so. Why are you holding it, then? You may be confusing database tuples with objects in the OO world. The difference is in the nature of the relationship between attribute updates and the object being modelled.

In an OO fishtank, setting the 'healthy' property of a fish to '+' will actually heal the fish! In a database, unless we have some really unusual user-defined types inside, it will do no such thing, but will only change our *statement* on the health of that fish. This is why it's useless to regard our database tuples as 'really' standing for identifiable objects: we can only do that to the extent that we can actually identify these objects by the tuple's attribute values.

-- 
Reinier