Re: Mixing OO and DB

Marshall wrote:

>On Mar 8, 4:53 am, rp..._at_pcwin518.campus.tue.nl (rpost) wrote:
>> David Cressey wrote:
>> >Before I move on, I have to give an opinion based on my own data-centric
>> >world view. If you don't understand the data, then you don't know what
>> >you're talking about. In short, I completely fail to grasp how one can
>> >understand a system in terms of "behavior" without understanding the data
>> >that the behavior affects. This is something that it's going to take me
>> >years of lurking in comp.objects to grasp.
>>
>> I don't think so. Can we understand the differences between sets,
>> multisets, ordered lists, queues and stacks just by
>> "understanding the data"?
>
>No, you're not following what David is saying, I don't believe.
>Queues/stacks etc. are not objects in the domain of discourse.
>They are data structures; they are part of the toolset. If this
>was what was at issue, then one could be said to understand
>any specific SQL database if one understood the relational
>algebra.

Yes, exactly; in the relational world, we're tied to a single data type, the relation, with particular operations on it. In the OO world we are generally concerned with specifying data types and their operations, and the semantics of these operations are known as "behavior" in the OO world.

>"Understanding the data" means knowing the semantics of
>the data in the domain of discourse.

Yes. But "semantics" is a very vague term. It's better to be more precise.

[...]

>> This is what the OO world calls "behaviour".
>
>Is it? I don't believe there is a lot of agreement in the OO world
>about what exactly "behavior" means. I actually suspect that many
>of them like it that way. At least some of the time, "behavior" means
>nothing more than the set of methods of a class.

I don't think so: it is that plus an understanding (often implicit) on what these methods are supposed to do - their behavior.

>> Behaviour is what an object looks like
>> from the outside. Data structure is what it looks like from the inside,
>> its implementation.
>
>"Data" is not "data structure" or implementation.

Another term without a good common definition. Better to avoid it altogether.

>> Here, I have some data for you:
>>
>> 1,129,960,000 March 8, 2008

[...]
>> Completely useless, unless you understand which interactions
>> with the real world these figures correspond to.
>
>It's useless because you haven't specified any semantics.
>Once you tell me what the data *means* it won't be useless
>any more.

That doesn't mean anything to me, until you specify what it means for something to "mean" something. I want an operational definition.

>> So I think your suggestion that understanding is somehow tied to data,
>> not to behaviour, is flat-out wrong. We do need to understand the
>> operations on our data before we can understand the data.
>
>That cannot be the case. If it were so, a read-only SQL database
>would be useless, because one is unable to transform it at all.

Reading (e.g. SQL SELECT) is an operation.

>It has no behavior. But often one can get extraordinary use out
>of a read-only SQL database, provided one knows the semantics,
>understands the data.

Its "behavior" in the OO sense is the semantics of the relational query language.

But for understanding, another thing is required: we need to understand what interactions with the real world the data correspond to. For instance, we might say that the numbers roughly correspond to what you'd get if you count all human beings in every country of the world and sort the resulting numbers in decreasing order. Although this operation is imaginary, it does bring the numbers into correspondence with reality, and that is what they mean. The explanations of OO that I've seen aren't very helpful here; they always leave the difference implicit between an OO model of something (with classes, properties, etc.) and that which it models (e.g. actual countries and numbers of persons). But the claim is that classes, properties etc. are in a one-to-one correspondence with things in reality. Relational databases attempt to do the same kind of modelling, but with the restriction that it is done entirely in terms of the relational model.

>Marshall

-- 
Reinier