Re: Mixing OO and DB

"rpost" <rpost_at_pcwin518.campus.tue.nl> wrote in message news:79aef$47d28c45$839b4533$7035_at_news1.tudelft.nl...
> 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"? Well, it depends on what you mean
> by "data", but my guess is that you'll agree that the differences
> between them are not so much in their data, in what information they
store,
> but on how we can access and update this information; the laws that
> govern their interaction with the rest of the world. This is what the
> OO world calls "behaviour". Behaviour is what an object looks like
> from the outside. Data structure is what it looks like from the inside,
> its implementation. The behaviour of sets, or multisets, or lists,
> can be implemented with many different concrete data structures,
> and conversely, the same concrete data structure can be used
> in implementing many different abstract data types.
>
> Can we understand the behaviour of sets without having a
> concrete data structure in mind? Yes, definitely, we can
> write down set operations and the laws that govern them, e.g.
>
> operations:
>
> empty: Set<T>
> isempty: Set<T> -> Boolean
> in: T x Set<T> -> Boolean
> singleton: T -> Set<T>
> union: Set<T> x Set<T>
> intersection: Set<T> x Set<T> -> Set<T>
>
> laws:
>
> isempty(empty) = true
> for all e in T: in(e, empty)
> for all e in T: in(e, singleton(e))
> for all e in T: in(e, singleton(e))
> for all e in T, X,Y in Set<T>:
> in(e, X) or in(e, Y) <=> in(union(X,Y))
> for all e in T, X,Y in Set<T>:
> in(e, X) and in(e, Y) <=> in(intersection(X,Y))
> (etc.)
>
> It's not easy, and I'm no expert in it, but it can be done,
> and I don't think you'll call this "understanding the data".
> What is more, I'll claim that all of the "understanding data"
> that you claim to be capable of is essentially of this nature:
> even with a concrete data structure in mind to aid understanding
> and the implementation, the data structure doesn't really mean
> anything without specifying the operations that can be performed
> on it; and that meaning essentially consists of the laws that
> govern the behaviour of those operations as observable from the
> outside, and is thereby essentially independent of that concrete
> data structure.
>

I'm going to mull this over at my leisure. I'm used to thinking at a more concrete level.

By "understanding the data", I mean something relatively "low level" (hee, hee) like understanding the captured data about cell phone calls before designing a system for reconciling roaming charges. You also have to understand behavior, but not so much the behavior of the system you are about to conceive. What you need to understand is the behavior of the people who use the data currently, and the desired behavior of those people, once the new system is built.

This business of "desired behavior of people" requires not only logic, but empathy! (There's another word that has been bandied about in these discussions.)

> No, but it is absolutely crucial. We can't specify any data at all
> without thinking of how to interpret it; and interpretation means to
> think of operations and how they are supposed to behave.
>
Agreed, that interpretation is crucial.

> In an RDBMS the focus is on data structures with "relational" behaviour,
> where the operations and their behaviour are fixed in the query language;
> this is a good fit for many of the data we need to work with in practice,
> but not for everything.
>
Agreed.

> You might just as well say: behaviour. The way in which your systems
> represent and access their data is ultimately subordinate to how the
> systems are supposed to *behave*, their functionality.
>

It depends on what you mean by "subordinate". If you mean something like Aristotle's "final cause", then maybe yes. But if you mean any of Aristotle's other causes, then the answer is probably no.

> >If you understand the data, and you understand the
> >(observable) behavior of each of the applications and each of the
databases,
> >you can understand the system. Otherwise, you can't understand the
system.
>
> The opposite is even more true: no data can be understood without
> understanding what operations are used to obtain and apply the data.
> Here, I have some data for you:
>
> 1,129,960,000 March 8, 2008
> 303,569,100 March 5, 2008
> 231,627,000
> 186,315,468 March 1, 2008
> 162,652,500 February 29, 2008
> 158,665,000
> 148,093,000
> 141,933,955 March 1, 2008
> 127,790,000 December 1, 2007
> 106,535,000
>
> Completely useless, unless you understand which interactions
> with the real world these figures correspond to.
>
I don't think so. You don't have to tell me what operations were done in the real world to arrive at that data. You only have to tell me what those operations were intended to accomplish. That's not the same thing. Received on Sat Mar 08 2008 - 15:02:26 CET