Re: Entity and Identity

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. Received on Wed Jul 22 2009 - 22:18:30 CEST