Re: A real world example

Bob Badour wrote:
> JOG wrote:
> >>They must have a common property because they're related. I would
> >>argue that "Me now" is part of "Me over my whole lifetime."
> >
> > "Me now" and "Me over my lifetime" could have a common property, but
> > they don't _have to_ as they are entities from separate domains. Again
> > it's the universe of discourse under concern that matters. At some
> > point the chances are they will have common properties, but a DNA value
> > might not be recorded for "Me now" and it still be perfectly valid in
> > its domain.
>
> You overestimate the use and importance of DNA. That will change in
> coming decades.

I'm well versed in DNA and RNA given my other half is a geneticist dealing with ID2 knockout stem cell research. Using the concept as it is viewed by layman served well enough to illustrate the principle, so enough pedantry bob.

> [snip]
> >>>Something must remain constant to compare entities - something must
> >>>identify them. If nothing remains constant the things being compared,
> >>>by liebniz equality, are different things full stop. This is what
> >>>mathematical logic is grounded in, we can't just avoid it. You seem to
> >>>be saying it is possible that "every attribute of something has
> >>>changed, yet it is still the same thing". Surely that's logical
> >>>nonsense!
>
> "This hammer has been in our family for over 150 years. In that time, we
> replaced the handle five times and the head twice!"

As I said (il)logical nonsense. Washington's hammer, theseus' ship, it doesn't matter (Marshall called me on this when I first arrived. I think he referred to it as "High School philosophy"). If two things have the same identity there has to be a common attribute to identify it as such, full stop. No oid's here thank you.

> [snip]
> > Brian Selzer wrote:
> >>"Are you the same person you were when you were 10?" depends on the context
> >>of the query, not necessarily the data, but in either context, you must be
> >>able to correlate the state when you were 10 to the state you are now in
> >>order to do the comparison. In the one context, you would compare the
> >>individual properties; in the other you would compare the universal
> >>properties.
> >
> > No! You have already presumed they are the same person if you do that.
> >
> > All one needs to do is see if the two entities _do correlate or not_
> > (And not assume they do a priori). If they don't, as in the identity is
> > not the same, I conclude they are different people. If they do, I can
> > say they are the same person, but in different states. I apologise for
> > banging on about liebniz all the time, but thats exactly how we
> > distinguish whether something is the same thing or not (conceding that
> > functional dependency means we can rely on the key for identity in RM).
> > I think this is a big point where we are differing.
>
> Given that Selzer makes up his own meanings for words, what makes you
> think you have any insight into what he thinks?

Well, I recognise him making the same mistakes I once did. That gives me insight into what might rectify them, and its why I can't be as fatalist about it as yourself.

Jim.

>
> >>>>>This is exactly the same as the basic philosophical question of change.
> >>>>>Are you the same person you were when you were 10? In one context the
> >>>>>answer is absolutely not, so an appropriate identifier is not DNA. In
> >>>>>another yes you are the same person, so DNA is perfect. It depends on
> >>>>>the domain you are considering, and one must pick the correct key
> >>>>>accordingly.
> >>>
> >>>I worry you have glazed over this, but it highlights how the context
> >>>information is more complex than we initially think, and we must
> >>>understand that context to make the right key choices (especially if
> >>>you want to make inter-relation value comparisons).
> >>>
> >>>My DNA don't change over my lifetime, so its a good key for that
> >>>conceptual entity (n.b. the representative label to record the DNA
> >>>might change, but the value is the same.)
>
> Actually, your DNA change constantly. The length of the 10 year old's
> telomeres, for example, are longer. (But size isn't everything--or so
> I've been told.)
>
>
> >>>>>>Here's a simple example of what can happen:
> >>>>>>
> >>>>>>create table P
> >>>>>>(
> >>>>>> x int primary key,
> >>>>>> y int
> >>>>>>)
> >>>>>>create table F
> >>>>>>(
> >>>>>> x int primary key references P(x),
> >>>>>> z int
> >>>>>>)
> >>>>>>insert P (x, y) values (1, 1)
> >>>>>>insert P (x, y) values (2, 3)
> >>>>>>insert P (x, y) values (3, 2)
> >>>>>>insert F (x, z) values (1, 5)
> >>>>>>insert F (x, z) values (2, 4)
> >>>>>>select * from P join F on (p.x = F.x)
> >>>>>>update P
> >>>>>> set x = case x
> >>>>>> when 1 then 2
> >>>>>> when 2 then 1
> >>>>>> end
> >>>>>> where x in (1, 2)
> >>>>>>select * from P join F on (p.x = f.x)
> >>>>>>
> >>>>>>RESULTS:
> >>>>>>
> >>>>>>Before:
> >>>>>>x y x z
> >>>>>>------ -------- ------- --------
> >>>>>>1 1 1 5
> >>>>>>2 3 2 4
> >>>>>>
> >>>>>>After:
> >>>>>>x y x z
> >>>>>>------ ------- -------- --------
> >>>>>>1 3 1 5
> >>>>>>2 1 2 4
> >>>>>>
> >>>>>>
> >>>>>>Should the new values for x in P have cascaded into F?
>
> Of course not. Otherwise, you would have included "ON UPDATE CASCADE"
> somewhere in the foreign key declaration.
>
>
> Assume that
> >>>>>>the
> >>>>>>system only has the before image and the after image (the first two
> >>>>>>columns
> >>>>>>in RESULTS) in order to complete the update. How can such a system
> >>>>>>differentiate between the above update and the following update?
> >>>>>>
> >>>>>>update P
> >>>>>> set y = case y
> >>>>>> when 1 then 3
> >>>>>> when 3 then 1
> >>>>>> end
> >>>>>> where x in (1, 2)
> >>>>>>
> >>>>>>Clearly first update affects a key, and consequently, the changes
> >>>>>>should
> >>>>>>cascade,
>
> Actually, they should not cascade as explained above. However, if they
> were to cascade, how they do so would depend on the implementation of
> the dbms. Hopefully, the dbms implementers would at least document the
> implementation.
>
>
> but with the information available (both updates produce the
> >>>>>>exact
> >>>>>>same before and after images), the system cannot differentiate between
> >>>>>>the
> >>>>>>two updates; therefore, it cannot determine whether or not to cascade
> >>>>>>the
> >>>>>>changes. Updates within the Relational Model are are constrained in
> >>>>>>the
> >>>>>>same way as this hypothetical system. All that is available is the
> >>>>>>preceding instance and the succeeding instance, and if the only key
> >>>>>>can
> >>>>>>change, then there is no way to correlate tuples.
>
> I don't recall where either set algebra or predicate calculus cover
> cascading updates for assignment statements. Perhaps Selzer could cite
> his source.
>
>
> >>>>>I'll consider the example in due course. RL work to do in the meantime,
> >>>>>sigh. All best, Jim.
> >>>>
> >>>>Another example is trying to write an update trigger in Sql Server to log
> >>>>changes to one table in another. The deleted and inserted pseudotables
> >>>>can
> >>>>be thought of as the preceding and succeeding database instances
> >>>>respectively. Unless you constrain updates to a single row, or reject
> >>>>updates that affect both key and non-key columns, or use a surrogate, you
> >>>>can't tell what changed to a particular row. In fact, it's possible for
> >>>>it
> >>>>to appear that nothing at all has changed, even though new key values
> >>>>have
> >>>>been propogated into referencing tables. (Sql Server does not faithfully
> >>>>implement the relational model. It can tell the difference between the
> >>>>two
> >>>>updates above, even though within a trigger on P, the deleted and
> >>>>inserted
> >>>>pseudotables would appear identical.)
>
> Since when does the RM say anything about the implementation of
> triggered procedures? Perhaps Selzer could cite his reference.
Received on Thu Aug 17 2006 - 01:41:20 CEST