Re: Entity and Identity
Date: Mon, 27 Jul 2009 23:36:29 -0700 (PDT)
Message-ID: <17842d16-5b5e-4927-8ca2-7cae37cf4c14_at_h31g2000yqd.googlegroups.com>
On Jul 28, 5:38 am, toby <t..._at_telegraphics.com.au> wrote:
> On Jul 22, 4:18 pm, Nilone <rea..._at_gmail.com> wrote:
>
>
>
> > On Jul 22, 7:43 pm, Tegiri Nenashi <TegiriNena..._at_gmail.com> wrote:
>
> > > On Jul 22, 5:29 am, Nilone <rea..._at_gmail.com> wrote:
>
> > > > On Jul 20, 5:51 pm, "Walter Mitty" <wami..._at_verizon.net> wrote:
>
> > > > > I've known for quite some time that better minds than mine have gone astray
> > > > > in the attempt to overcome the object relational mismatch. Just last week,
> > > > > I ran across an article that outlines the O-R mapping problem better than I
> > > > > ever could.
>
> > > > > The article is called "The Vietnam of Computer Science", and here's a
> > > > > pointer:
>
> > > > >http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science...
>
> > > > > The article devotes rather too much time to exploring the analogy between
> > > > > the Vietnam war and ORM attempts. And as the article admits, all analogies
> > > > > eventually fail. Leaving that aside, I think the survey of problems
> > > > > encountered in crossing the divide is excellent.
>
> > > > > I want to draw particular attention to a heading entitled "Entity Identity
> > > > > Issues". Reading this section gave me a better understanding of the
> > > > > disconnect between me and Brian Seltzer over matters concerning entity and
> > > > > identity. My own view of identity is colored by my own experience. And
> > > > > that experience includes some practical work with relational databases,
> > > > > preceded by a little formal learning in that area and 20 years of work as a
> > > > > programmer. Unfortunately, none of that work included object oriented
> > > > > programming.
>
> > > > > Anyway, my view of identity (or of identification, if you prefer) is that an
> > > > > object's state is all we have to go on as the basis for identification. In
> > > > > particular, an object's location (as specified by a pointer) or its
> > > > > trajectory (a history of pointers over time) are unavailable for purposes of
> > > > > identification. This view of identity fits pretty comfortably into the
> > > > > relional model, but it runs afoul of object oriented thinking at least two
> > > > > important ways. Frst, if an object can conceal part of its state
> > > > > (encapsulation), then it necessarily can conceal some of what needs to be
> > > > > known to identify it. Second, if two objects are identical in state, then
> > > > > they are the same object, even if they differ in location (at the same point
> > > > > in time). I'll call this the "Doppelganger effect".
>
> > > > > When I see an SQL table with two different rows in one table that cannot be
> > > > > distinguished by their contents, my reaction is that the database designer
> > > > > made a mistake. Failing in that, the database updaters should have been
> > > > > more careful. Cases where duplication is intentional and carries
> > > > > significant information strike me as a misuse of SQL, and a misunderstanding
> > > > > of the relational model.
>
> > > > > The above doesn't pretend to explain Brian's view. But I think it sheds a
> > > > > little light on why I see things the way I do.
>
> > > > > Again, I recommend the article cited above.
>
> > > > The article states: 'The opposite approach--a "relational-only"
> > > > approach--is almost nonsensical to consider, given the technology of
> > > > the day at the time this was written'
>
> > > > It sounds as if it just might be doable. Not like a D language, but
> > > > like a DBMS with support for executing certain forms of data (since
> > > > code is just another type of data, lisp and prolog proved that). All
> > > > functions are relations, right? So can a functional programming
> > > > paradigm be embedded in the relational model? Is there a relational
> > > > model of computation? Just wondering...
>
> > > IMO function viewed as a relation offers too little insight to be
> > > practically useful (yet). Function composition is relational join
> > > (followed by projection of intermediate attributes) -- that is about
> > > it. What is recursion from relational perspective?
>
> > > I would suggest that the theory of binary relations (aka Relation
> > > Algebra) is more useful in computational world. Function composition
> > > is the exact relational composition (join). Roland Backhouse pioneered
> > > this direction, and J.N.Oliveira leaning it more towards databases...
>
> > Yes, that's what I was looking for. Function composition is join, and
> > then function application would be selection, right? The domain of
> > the function is the propositional condition that restricts the
> > selection, while the codomain would be the projection of the resulting
> > set of tuples. Recursive queries would substitute the result set into
> > the the selection condition (of course they would have to be the same
> > type). Recursively defined relations would produce infinite sets.
> > Any more references or information in this line?
>
> > I looked at some pages on relation algebra, but it's still beyond me,
> > I'll keep working at it, thanks for the info.
>
> For some discussion of functions & relational theory you might want to
> look in,http://www.abebooks.com/servlet/SearchResults?an=date&sts=t&tn=logic
> (yes this is another title from DBDebunk book list).
Thanks, I'll check it out. Received on Tue Jul 28 2009 - 08:36:29 CEST