Re: identifying entities across database updates (was: Is a function a relation?)
Date: Fri, 03 Jul 2009 06:51:26 GMT
"none (Reinier Post)" <rp_at_raampje.> wrote in message
> Brian Selzer wrote:
>>I accept as an axiom that there are objects that can have a location in
>>or space. To formalize this, let C! be a 1-place relation that ranges
>>the objects in the Universe and expresses the property of having a
>>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.
> 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.
Among Hindu mystics, the division of the universe into objects is itself an illusion. It might be considered "the first great blunder" of someone who would understand ultimate reality.
Those of us who use databases for practical purposes, or who build databases for others to use, do not think like Hindu mystics. We accept subject matter entities as having real existence, and real identity. We routinely refer to the assertions made inside a database as "facts" rather than "opinions". It helps us get our job done, or at least gives us the comforting illusion that we are getting our job done. We even think of some keys as being "natural" and being subject to discovery rather than invention.
The fact that all of this is subjective rather than objective usually surfaces, in one way or another, during the requirements analysis phase of a database project. In interviews with subject matter experts and users of the data, you often hear people exclaim something like this: "Don't listen to all those other people. They're all idiots. I'm going to tell you how it really works." And that's only when you're building a database for actual users.
More than half the time nowadays, requirements analysis is done with marketing taking the part of some imagined future users of the product. These future users are supposed to materialize once the product is built, in a scenario that might be called the "field of dreams sales plan." You know, "build it, and they will buy."
its common to accept subject matter entities as really existing, and really havinmg identity. Received on Fri Jul 03 2009 - 01:51:26 CDT