Mixing OO and DB

On Fri, 8 Feb 2008 01:44:46 -0800 (PST), JOG wrote:

> On Feb 8, 8:50 am, "Dmitry A. Kazakov" <mail....TakeThisOut@dmitry-kazakov.de>
> wrote:
>> On Thu, 7 Feb 2008 14:15:53 -0800 (PST), Tegiri Nenashi wrote:
>>> On Feb 7, 2:04 pm, "Dmitry A. Kazakov" <mail....TakeThisOut@dmitry-kazakov.de>
>>> wrote:
>>>> On Thu, 7 Feb 2008 13:00:15 -0800 (PST), Tegiri Nenashi wrote:
>>>>> I suggest that OO ideas are too naive to continue influence
>>>>> programming. Formal Concept Analysis (FCA) is much more theoretically
>>>>> sound method how to organize things into taxonomies.
>>
>>>> Sorry, but the idea of subsets used in place of subtypes far surpasses in
>>>> naiveness anything one could charge "naive OO" with.
>>
>>> Are you referring to apparent object propelleheads unability to even
>>> coherently define what the object/type is?
>>
>> At least they try to face the problem.
>
> Although you only have to face the problem of definining what an
> "object" is if you've conjured that problem in the first place.

Much confusion arise from mixing domain and solution spaces when talking
about "objects." Otherwise I see nothing impossible neither in defining
"object" as a language term nor in doing so in the corresponding problem
domain. One should just remember that they are different beasts.

>> Which is not about clustering some arbitrary set of attributes.
>
> What is it about then? Genuinely interested.

It is about software design. Assuming that to design software is to cluster
a set of all possible programs into the categories "does-the-thing",
"does-other-thing" is funny, at least.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
 >> Stay informed about: Mixing OO and DB 

On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail....RemoveThis@dmitry-kazakov.de>
wrote:
> The same problem exists with any algebra less flat than numeric fields.
> What is the type of Matrix x Matrix?

Speaking of matrices, what do you possibly achieve by bundling
together the multiply(Matrix,Matrix) function together with the Matrix
data structure (other than loosing the symmetry: consider
matrix1.multiply(matrix2) method call how ugly is that)? Perhaps you
want a convenient listing of all the functions that have Matrix as a
first argument? Such a query shouldn't be a problem in any of
contemporary IDEs which *are* databases storing the source code. Or
you imply that you can define Matrix2x2 and subtype it into
GeneralMatrix? How silly is that (given that it is just simpler to
write general implementation). Or maybe one is advised to subclass the
other way?

If you serious about working with matrices (or any math) in your
application, then you design a mini-language which looks as Maple,
Matlab, or Mathematica.

> The point is though that there is nothing in RA to deserve a special
> treatment. That is actually is not an option, because we just cannot
> provide a tailored solution for each and ever algebra.

You mean you don't want to, or you are not qualified to?

> > For me, the big problem has always been the following :
>
> > SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
>
> > s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
>
> > In the OO world, the problem is that for each instance of SomeType held
> > in Somewhere, the *implementation* of the property 'x' could be merely
> > an actual data value, or a serious computation process. That is the ADT/OO
> > way.

If x is computed, then why don't you introduce a function that
computes it? In relational world a function call is a join. If this
function is not known at runtime, then what logic is involved in
selecting it? Can't the problem solved by dynamically constructing
this query?

> I see it different. First the above should be decomposed into primitive
> operations over the types involved. There is at least the type of the table
> and one of the cell. If SELECT were doubly dispatching, then one could
> certainly provide different implementations for different combinations of
> types.

What is SELECT? The whole query? The projection part? You OO guys
perfected the art speaking gibberish.

> To me a bigger problem is that RA is "computationally instable" in the
> sense that a minor variations of same constructs may have massive effects
> on resources consumptions, i.e. distributed overhead. OO tries to localize
> effects by decoupling and encapsulation.

You mean optimization? This is true, query optimization in relational
world is far more advanced than the one in the procedural programming
(which includes OO), and therefore it has more challenging problems.

> > It is because of this that I believe that the only paradigm that is capable
> > of providing the true engine for a relational info base that caters for
> > both OO and current RDBMS, is Functional programming (data values and
> > computation entities - functions - are treated the same, techniques such as
> > lazy evaluation, "copy on write" behaviour etc) .

Function is just a relation with functional dependency. It works
pretty much like an index. When a function is called from a query, it
is essentially a join, although there is no ambiguity which order this
join is evaluated. Therefore, in principle, FP is too weak to embrace
relational. It is more likely to happen the other way.

Relational programing has its weaknesses, but they are not what OO
propellerheads think. One missing part in the relational is formal
grammars and languages. The underlying theory of grammars and language
theory is Kleene algebra which is incompatible with RA. Witness how
regular expressions are integrated into SQL, as if there is no common
operation in relational algebra and algebra of strings...
 >> Stay informed about: Mixing OO and DB 

"Victor Porton" <porton.DeleteThis@narod.ru> wrote in message
news:89b92dec-b710-4c24-9c8e-731de01fb49a@u10g2000prn.googlegroups.com...
> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?
>
> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.
>
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?

First off, I think it's reall the mixing of OO and RDM that's of interest,
rather than the mixing of OO and DB.


Better minds than mine have attempted to deal with the impedance mismatch
between OO and RDM. In general, they have been disappointed by their own
results.

I suspect that most of them have gone about it in the wrong way. Most of
them have tried to project an object world onto a system of relations. What
they end up with is presistent data that captures the state of each object,
and its membership in a class. The behavior of objects that belong to any
class is generally defined outside of any coherent data model (even if it's
stored in a blob in a database).

I think it might be interesting to explore the whole concept backwards:
start with the idea that a table is just a specific class of object, and a
persistent table is just a specific class of persistent object. Then come
up with two things: how to store persistent objects and retrieve them when
necessary without regard for any data model; and how to get tables and
application objects to collaborate on common objectives.

This doesn't sound easy to me, at all. But it could be promising, provided
there is real value in OO. I don't know OO well enough to have a considered
opinion on that score.
 >> Stay informed about: Mixing OO and DB 

David Cressey wrote:

> "Victor Porton" <porton RemoveThis @narod.ru> wrote in message
> news:89b92dec-b710-4c24-9c8e-731de01fb49a@u10g2000prn.googlegroups.com...
>
>>I know both object oriented programming and DB (SQL). But it seems
>>that these are incompatible. Or may somebody advice how to meddle them
>>together?
>>
>>Being strong in both OOP and DB development, I am yet weak in writing
>>object oriented programs which use DB.
>>
>>Maybe somebody may suggest me some article about mixing together DB
>>and OOP?
>
> First off, I think it's reall the mixing of OO and RDM that's of interest,
> rather than the mixing of OO and DB.
>
> Better minds than mine have attempted to deal with the impedance mismatch
> between OO and RDM. In general, they have been disappointed by their own
> results.

Nuh uh--Not me! I was not disappointed. Raising the programming language
from the low OO level to the higher RM level works great!


> I suspect that most of them have gone about it in the wrong way. Most of
> them have tried to project an object world onto a system of relations. What
> they end up with is presistent data that captures the state of each object,
> and its membership in a class. The behavior of objects that belong to any
> class is generally defined outside of any coherent data model (even if it's
> stored in a blob in a database).
>
> I think it might be interesting to explore the whole concept backwards:
> start with the idea that a table is just a specific class of object,

A great blunder.


and a
> persistent table is just a specific class of persistent object. Then come
> up with two things: how to store persistent objects and retrieve them when
> necessary without regard for any data model; and how to get tables and
> application objects to collaborate on common objectives.
>
> This doesn't sound easy to me, at all. But it could be promising, provided
> there is real value in OO. I don't know OO well enough to have a considered
> opinion on that score.

Have you read _The Third Manifesto_ ? D&D put a lot of thought into what
parts of OO have any real value.
 >> Stay informed about: Mixing OO and DB 

"frebe" <frebe73 DeleteThis @gmail.com> wrote in message
news:081cbab9-89f6-4459-9e5c-3346e6d96e99@s37g2000prg.googlegroups.com...

> The problem occurs when one try to use classes/objects as data
> structures. The relational model only allow relations as data
> structures. If you create classes like "employee", "customer", you
> will soon encounter big problems. But classes like "SSN", "telephone
> no", "zip code" will fit perfect together with the relational model.

Alan Kay once said "I don't like data structures". This was in the context
of some lecture on virtual reality. If you'll think about the consequences
of that opinion for a little while, you'll be devastated.
 >> Stay informed about: Mixing OO and DB 

On Fri, 08 Feb 2008 13:48:50 GMT, David Cressey wrote:

> I think it might be interesting to explore the whole concept backwards:
> start with the idea that a table is just a specific class of object, and a
> persistent table is just a specific class of persistent object.

It so obvious that I wonder how one could even consider it "interesting,"
rather than mandatory. (BTW, persistence is an orthogonal issue to typed
relations. As well as concurrency is.)

The problem is that contemporary type systems in OOPL aren't very good to
handle this.

> This doesn't sound easy to me, at all. But it could be promising, provided
> there is real value in OO. I don't know OO well enough to have a considered
> opinion on that score.

Look, if typed systems had no sense, then why would anybody have table
cells typed? Once you accept usefulness of the latter, you should also
apply types to the former.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
 >> Stay informed about: Mixing OO and DB 

Dmitry A. Kazakov wrote:

> On Fri, 08 Feb 2008 13:48:50 GMT, David Cressey wrote:

>>I think it might be interesting to explore the whole concept backwards:
>>start with the idea that a table is just a specific class of object

In an RDB, a "table" T is more than that.
It also represents the extent set (all instances) of T.

Then we have issues coming from the semantics of relational algebra.

For example:

In an object type system, what would the semantics of "joins" be ??

Should it have the same semantics as the relational model (a new type
tuple etc) ?? Or something else ??

If so, how would this new type be implemented/realised in the underlying
system (closures etc) when the join is done on two different object
instances ??


>Then come up with two things: how to store persistent objects and
>retrieve them when
>necessary without regard for any data model; and how to get tables and
>application objects to collaborate on common objectives.

For me, the big problem has always been the following :

SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)

s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;

In the OO world, the problem is that for each instance of SomeType held
in Somewhere, the *implementation* of the property 'x' could be merely
an actual data value, or a serious computation process. That is the ADT/OO
way.

If the implementation is a computation process, there is also no guarantee
that each instance in Somewhere actually use the *same* implementation.

So all the optimisation etc that is achievable when you constrain x/y/z to
be raw data values only, is lost when you can no longer presume such
constraints.

It is because of this that I believe that the only paradigm that is capable
of providing the true engine for a relational info base that caters for
both OO and current RDBMS, is Functional programming (data values and
computation entities - functions - are treated the same, techniques such as
lazy evaluation, "copy on write" behaviour etc) .

With imperative prog langs (C, C++ , Java etc) , I can never see the
"mismatch impedence" ever being overcome.


Regards,
Steven Perryman
 >> Stay informed about: Mixing OO and DB 

On Feb 8, 7:32 pm, "Dmitry A. Kazakov" <mail....DeleteThis@dmitry-kazakov.de>
wrote:
> [snip]
> That would be unfortunate, because I see a general problem with declarative
> approaches as they try to sort things out per means of "magic." Without
> magical devices at hand, we should design them by themselves. How?

I'm wondering if that made more sense in the original russian?

>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
 >> Stay informed about: Mixing OO and DB 

On Fri, 08 Feb 2008 16:44:53 +0000, S Perryman wrote:

> Dmitry A. Kazakov wrote:
>
>> On Fri, 08 Feb 2008 13:48:50 GMT, David Cressey wrote:
>
>>>I think it might be interesting to explore the whole concept backwards:
>>>start with the idea that a table is just a specific class of object
>
> In an RDB, a "table" T is more than that.
> It also represents the extent set (all instances) of T.
>
> Then we have issues coming from the semantics of relational algebra.
>
> For example:
>
> In an object type system, what would the semantics of "joins" be ??
>
> Should it have the same semantics as the relational model (a new type
> tuple etc) ?? Or something else ??
>
> If so, how would this new type be implemented/realised in the underlying
> system (closures etc) when the join is done on two different object
> instances ??

The same problem exists with any algebra less flat than numeric fields.
What is the type of Matrix x Matrix? What is the type of Velocity /
Duration? etc. The problem is rather fundamental and appears when we deal
with operations built on tuples of types.

The point is though that there is nothing in RA to deserve a special
treatment. That is actually is not an option, because we just cannot
provide a tailored solution for each and ever algebra.

> >Then come up with two things: how to store persistent objects and
> >retrieve them when
> >necessary without regard for any data model; and how to get tables and
> >application objects to collaborate on common objectives.
>
> For me, the big problem has always been the following :
>
> SomeType = (x,y,z) (or if you prefer : type SomeType { x, y, z } etc)
>
> s = SELECT SomeType FROM Somewhere WHERE (x = 123) ;
>
> In the OO world, the problem is that for each instance of SomeType held
> in Somewhere, the *implementation* of the property 'x' could be merely
> an actual data value, or a serious computation process. That is the ADT/OO
> way.
>
> If the implementation is a computation process, there is also no guarantee
> that each instance in Somewhere actually use the *same* implementation.
>
> So all the optimisation etc that is achievable when you constrain x/y/z to
> be raw data values only, is lost when you can no longer presume such
> constraints.

I see it different. First the above should be decomposed into primitive
operations over the types involved. There is at least the type of the table
and one of the cell. If SELECT were doubly dispatching, then one could
certainly provide different implementations for different combinations of
types.

To me a bigger problem is that RA is "computationally instable" in the
sense that a minor variations of same constructs may have massive effects
on resources consumptions, i.e. distributed overhead. OO tries to localize
effects by decoupling and encapsulation.

> It is because of this that I believe that the only paradigm that is capable
> of providing the true engine for a relational info base that caters for
> both OO and current RDBMS, is Functional programming (data values and
> computation entities - functions - are treated the same, techniques such as
> lazy evaluation, "copy on write" behaviour etc) .

Doesn't it just postpone the problem until run-time?

> With imperative prog langs (C, C++ , Java etc) , I can never see the
> "mismatch impedence" ever being overcome.

That would be unfortunate, because I see a general problem with declarative
approaches as they try to sort things out per means of "magic." Without
magical devices at hand, we should design them by themselves. How?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
 >> Stay informed about: Mixing OO and DB 

Responding to Porton...

> I know both object oriented programming and DB (SQL). But it seems
> that these are incompatible. Or may somebody advice how to meddle them
> together?

Superficially they are not. An OO Class Model and a Data Model (nee
Entity Relationship Diagram) use essentially the same notation and both
are normalized using the same NF criteria.

The difference lies in the way the models are constructed and the way
that elements of the entire model (the Class Diagram is only one
component of an OOA/D model and cannot be separated from the other
components) play together. While the construction paradigms are not
directly incompatible, they will typically lead to different models
because different things are abstracted (problem space subject matters
vs data) and there are different goals in creating the model.

One manifestation of that is that the OO model will be highly tailored
to the unique rules and policies needed to solve the problem in hand. In
contrast, the goal of a Data Model is to represent data in a generic,
usage-independent manner.

Thus there is an inherent incompatibility but it lies in the goals and
construction methodologies rather than the notation syntax or element
semantics.

Generally speaking the OO paradigm is overkill for pure data processing
(i.e., classic CRUD/USER processing). In addition the RAD IDEs have
largely automated much of what one would construct from scratch in an OO
context. In doing so, though, the RAD IDEs have limited themselves to
situations where 2D layered models apply and one can provide 1:1 mapping
between the UI and the DB (i.e., form-based UIs that map conveniently to
stored tables). For that sort of pure data processing the RAD paradigm
is much better suited.

OTOH, when one has to solve a large problem using complex business rules
and policies in a manner that is unique to the problem, one begins to
realize the benefits of the OO paradigm -- particularly when the
requirements are volatile over time. But for those sorts of
applications, both the UI and the persistence mechanisms are of
relatively little importance. Thus the problem solution doesn't care if
one communicates with the user via a GUI, a web browser, or smoke
signals. Nor does the problem solution care if the data store is an RDB,
an OODB, flat files, or clay tablets.

So in OO applications, the UI and persistence access tend to be isolated
and encapsulated as low level service subsystems. The subsystem
interface then allows the mechanisms to be substituted transparently
without touching the problem solution.

A corollary is that because such subsystems are narrowly defined around
a particular subject matter like an RDB, one can abstract the invariants
of the paradigm. Thus for an RDB access subsystem one abstracts classes
like Schema, Table, Tuple, and Query rather than objects like Customer,
Order, and Shipment. That, in turn, allows one to express detailed
differences in terms of external configuration data. (In an RDB, the
schema itself becomes an identity mapping mechanism; one just needs to
link interface messages to schema names.) So typically one only needs to
design and implement a UI or DB paradigm once in an OO fashion; one can
then reuse the subsystem across different applications by simply
providing an appropriate configuration file and an interface (think: GoF
Facade pattern).

> Being strong in both OOP and DB development, I am yet weak in writing
> object oriented programs which use DB.

If you are solving CRUD/USER problems my advice would be to forget about
using OO and employ traditional RAD techniques. If you are solving
non-CRUD/USER problems, then I think all you have to do is isolate,
encapsulate, and abstract the invariants of the DB paradigm.

>
> Maybe somebody may suggest me some article about mixing together DB
> and OOP?

You might check out Fig. 17.2 in "Executable UML" by Mellor and Balcer.
The example is about abstracting a web browser UI but it is a good
example of abstracting the paradigm invariants. Exactly the same model
could be used for any application that talks to a web browser; all that
changes is what instances are initialized and what their attribute
values are -- all provided by configuration data. The extrapolation to a
model with objects like Table and Query should be fairly obvious.


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl.DeleteThis@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info.DeleteThis@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
 >> Stay informed about: Mixing OO and DB 

H. S. Lahman wrote:

> Responding to Porton...
>
>> I know both object oriented programming and DB (SQL). But it seems
>> that these are incompatible. Or may somebody advice how to meddle them
>> together?
>
> Superficially they are

[snipped lengthy bs complete with not 1 but 8 paradigms]

> fairly obvious.

Seldom in the history of mankind have so many words said so little.

(Lots of greek and latin roots always bode ill.)
 >> Stay informed about: Mixing OO and DB 

On Fri, 8 Feb 2008 13:18:05 -0800 (PST), Tegiri Nenashi wrote:

> On Feb 8, 11:32 am, "Dmitry A. Kazakov" <mail....TakeThisOut@dmitry-kazakov.de>
> wrote:

>> The same problem exists with any algebra less flat than numeric fields.
>> What is the type of Matrix x Matrix?
>
> Speaking of matrices, what do you possibly achieve by bundling
> together the multiply(Matrix,Matrix) function together with the Matrix
> data structure (other than loosing the symmetry: consider
> matrix1.multiply(matrix2) method call how ugly is that)?

Egh, prefix notation is just a notation, utterly misleading in most cases,
BTW. Semantically matrix multiplication deals with a triplet:

Multiply : Matrix x Matrix -> Matrix

So if Multiply is to be bound to an object then that has to be a tuple
(Matrix, Matrix, Matrix).

(If you think that OO = prefix notation, then it is not the OO I meant.)

> If you serious about working with matrices (or any math) in your
> application, then you design a mini-language which looks as Maple,
> Matlab, or Mathematica.

Really? And what if I am serious about working with something else too?
What about "serious" working with matrices *and* data bases? So next time
it should be me whining here about impedance between OO, DB and now a fancy
matrix language? What a brilliant future waits for us...

>> The point is though that there is nothing in RA to deserve a special
>> treatment. That is actually is not an option, because we just cannot
>> provide a tailored solution for each and ever algebra.
>
> You mean you don't want to, or you are not qualified to?

Neither. I do admire compiler construction, but customers became thrifty.
Silly they don't want to pay for developing a new programming language for
each other new project!

>> To me a bigger problem is that RA is "computationally instable" in the
>> sense that a minor variations of same constructs may have massive effects
>> on resources consumptions, i.e. distributed overhead. OO tries to localize
>> effects by decoupling and encapsulation.
>
> You mean optimization? This is true, query optimization in relational
> world is far more advanced than the one in the procedural programming
> (which includes OO), and therefore it has more challenging problems.

If solution is itself a problem... No, I didn't mean optimization. What
makes you believe in optimization? How reliable your belief is? Let you
look at a program, can you predict if it meets time and space constraints?
Before optimization? After optimization?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
 >> Stay informed about: Mixing OO and DB 

> Even when the
> relational schema is embedded in a single application, state changes
> for different reasons and as different rates from behavior.

Would you mind giving examples of such changes? (You can skip the
"denormalisation for performance" example.)

>      The object model, on the other hand, is optimized to address
> non-functional requirements (NFRs) related to the problem domain.

Doesn't that indicate that OO is pretty low-level, and that the
coupling between the logical model and the phisycal model is high?
Wouldn't it be better if we could separate the logical model handling
functional requirements, and the physical model handling non-
functional requirements?

> > Maybe somebody may suggest me some article about mixing together DB
> > and OOP?
>
>      Because of the impedance mismatch, most OO systems use some form
> of object-relational mapping.  

O/R mapping is not the best way of mixing together DB and OOP.

//frebe
 >> Stay informed about: Mixing OO and DB