Re: Objects and Relations

On Feb 5, 11:58 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> On Feb 5, 4:35 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
>
> > On Feb 5, 7:25 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
> > > On Feb 5, 6:40 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>
> > > > On Feb 5, 5:09 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
> > > > > On Feb 3, 11:33 pm, "Walt" <wami..._at_verizon.net> wrote:
>
> > > > > > "David BL" <davi..._at_iinet.net.au> wrote in message
>
> > > > > > > Many of the wars between the OO and RM camps end up in side issues,
> > > > > > > often with unsubstantiated performance or scalability claims or
> > > > > > > discussions about whether physical independence is good or bad.
<snip>
> > > > > It's my impression that a poor understanding of object identity leads
> > > > > to designs with excessive class hierarchies. For example an Employee
> > > > > class can be specialised in many ways, such as SalariedEmployee,
> > > > > WagedEmployee, SalesEmployee. The fact of the matter is that
> > > > > external entities like humans are often capable of countless
> > > > > behaviors. Humans can be gardeners, psychopaths, circus performers,
> > > > > parents, carnivores, mammals and so on (and often all at once). RM is
> > > > > much better at stating factual information about humans without
> > > > > pretending to actually represent one for real. The information about
> > > > > a given human can and should be spread across lots of relations.
>
> > > > First, In the outside world we only identify things by the values of
> > > > the attributes they exhibit, and not by some omiscient OID.
>
> > > I'm not sure I follow. I don't see anything innately wrong or
> > > difficult with labelling external entities with unique identifiers. I
> > > agree that entities don't generally come already labelled. Is that
> > > what you mean?
>
> > > > Second the
> > > > 'things' and 'its' of which you speak are not absolute -
> > > > interpretation of their scope varies from individual to individual,
> > > > and their boundaries cross and blur. Trying to 'encapsulate' one is a
> > > > fool's errand, as they don't really exist.
>
> > > I'm not sure what you mean. Can you give me an example where it
> > > matters that the scope of an external entity is subjective?
>
> > > > So, Identity does not exist outside observable attributes, and
> > > > symbolic entities do nothing but generate query bias at the logical
> > > > layer.
>
> > > I agree with the query bias but not your reason for it. For example,
> > > I see no difficulty in assigning a label to a particular human. To
> > > the extent that facts about that human will be recorded in a typical
> > > RM application there is no confusion about the scope or boundary of
> > > the human.
>
> > > For me it is the problem with trying to record all conceivable
> > > information about a human in a single data structure that is
> > > problematic, and explains why OO has a hard time of it. I don't see
> > > how labelling a human in itself has any difficulties. The problem
> > > seems to have far more to do with type analysis (ie classifying
> > > humans) in order to know what attributes need to be recorded. This
> > > is the fool's errand.
>
> > I think I am finally catching on to at least one of your points, and
> > if I have, then I disagree with it.
>
> > OO folks are not confusing OO objects with the entity they are
> > modeling. One can model an "entity" many ways, with pros and cons to
> > various approaches. We can model an entity logically using sets,
> > propositions, functions, graphs, OO objects, etc. The question is not
> > "which of these is right" but "which of these is most useful for our
> > purpose".
>
> Sure, and I code a lot of OO, where the software happily does what its
> supposed to with no problems.

Your'e a better man than I ;-) as I have had a few opportunities where I needed to exorcise my Java code..

> However purposes and requirements
> change, as do the views of the data that people want.

Yes, huge.

> A lot in my
> albeit limited experience. If I have a system that can cope with that,
> and still achieve the same results as one can with a biased entity
> view, then more the better. Perhaps I do not emphasize my pragmatic
> side enough.

It shows on occasion.

>
> > One of the benefits to using something other than RM-as-typically-
> > implemented (using the form previously-known-as-1NF, for example) is
> > that you do not need to paste (as many) pieces back together in order
> > to view or use your model related to a single entity.
>
> Yes, I see the benefit. However I am looking to have my cake and eat
> it.

Yup, me too, but you simply are not going to get every desired feature. For example, I often want strong typing from the DBMS, but appreciate weak typing even more sometimes. I can almost get what I want with synonyms that can be of different types and be assigned to the same values (strings), but strong typing flies out the window with that. In other words, there are competing requirements.

> > Also, when you
> > do paste the pieces back together in a single view, you end up with
> > multiple propositions, with information repeated, when using RM-as-
> > typically-implemented.
>
> I do not believe RM is the last word in data management.

Ah ha, so we agree on that point. I'll savor that piece of cake.

> However it
> offers many important insights which must not be neglected, but built
> upon imo.

Some should be built on (those that advanced "data processing" such as attention to functional dependencies) and others dismissed (those that set us back decades, such as 1NF and 3VL) imo.

> > With OO and other models you might otherwise
> > have a single proposition that more closely aligns with a proposition
> > one might actually state about the modeled entity
>
> Absolutely. As long as its a proposition (not OO then...)

OO can be used to model predicates and propositions, right? I'm guessing that once you do, there could be features missing--what features do you want that you are missing in OO?

> I see
> nothing wrong with that at all. Cake and eating goodness.

A cup of hot chocolate would do for right now. It is darn cold here. --dawn

> > Every model is simply a model (a mathematical metaphor), and not the
> > actual object being modeled. So, it will fail to capture everything
> > about the thing it is modeling. It must capture that which is
> > relevant for purposes of the (user and the) software being written.
> > There are issues when modeling at the level of one entity, such as
> > asymmetry (and resulting query "bias"). There are also benefits to
> > modeling so that you have a good model for "one" (Seehttp://www.tincat-group.com/mewsings/2006/03/data-for-every-1.html). These
> > can be discussed as trade-offs, pros and cons, but not in the terms
> > you have set up, from my perspective.
>
> > --dawn
Received on Mon Feb 05 2007 - 21:41:56 CET