Databases as objects

An unexpected thing happened while debating topmind: I had an epiphany.
Instead of responding to the news group I thought about it for a short
bit (very short) and posted an article to my blog titled, "The RDB is
the biggest object in my system."

<http://blogs.in-streamco.com/anything.php?title=the_rdb_is_the_biggest_object_i n_my_syst>

What I realized while trying to describe my preference to use DB
procedures as the primary (re: only) interface between my applications
and the database is because I believe my DB's physical representation of
data belongs to it alone and that customers of the DB oughtn't be
permitted to directly manipulate (change or query) its data. I realized
this is exactly what data-hiding is all about and why expert object
oriented designers and programmers emphasize the importance of
interfaces to direct data manipulation.

I thought more about this and posted a second article, Databases as
Objects: My schema is my class, which explored more similarities between
databases and objects and their classes.

<http://blogs.in-streamco.com/anything.php?title=my_schema_is_an_class>

I intend next to explore various design patterns from GoF and Smalltalk:
Best Practice Patterns to see if the similarities persist or where they
break down, and what can be learned from both about designing and
implementing OO systems with relational data bases.

If you agree there's such a thing as an object-relational impedance
mismatch, then perhaps its because you're witnessing the negative
consequences of tightly coupling objects that shouldn't be tightly coupled.

There's a hypothesis in there somewhere.

As always, if you know of existing research on the subject I'm anxious
to read about it.

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

Thomas Gagne <tgagne{}wide-open-west.com> writes:
>As always, if you know of existing research on the subject I'm
>anxious to read about it.

No research - but I'd like to quote from my previous post:

"When you use a relational database via SQL, you also use
polymorphism: The same operation »SELECT« is supported by
an object, independent of whether it is a base table or a
»virtual« table (a »view«), independent of whether this is
a result of a join operation or of a union operation,
while the /implementation/ of »SELECT« might differ for
base tables and different types of views. [...]

When Alan Kay made up OOP, he thought of objects as of
independent entities communicating via messages, just like
cells or like computers within a network. Thus, a database
(server) is an example of ab object: It accepts messages
(in SQL, for example). It also has information hiding (you
can only communicate with it via those messages, but do
not access the data files directly).

Different SQL database programs also are an example for
useful polymorphism: They all understand the same
language, but might have different implementations
internally. Their client does not have to be aware of the
implementation details."

<db-20060706061022{}ram.dialup.fu-berlin.de>

Thomas Gagne wrote:
> An unexpected thing happened while debating topmind: I had an epiphany.
> Instead of responding to the news group I thought about it for a short
> bit (very short) and posted an article to my blog titled, "The RDB is
> the biggest object in my system."
>
> <http://blogs.in-streamco.com/anything.php?title=the_rdb_is_the_biggest_object_i n_my_syst>

>From the link:

"Why shouldn't applications have embedded SQL? Because it's the same as
accessing the private data members of an object. It shouldn't be done.
OO programmers know the correct way to interface with an object is to
use its method interface--not attempt direct manipulation of the
object's data. OO programmer's attempts to violate that rule is what
causes so much frustration mapping the application's data graph into a
relational database's tables, rows, and columns. Those things belong to
the DB--not to the application."

(end quote)

You OO'ers keep forgetting: SQL *is* an interface. I repeat, SQL *is*
an interface. It is *not* "low level hardware". You OO'ers keep
viewing it as low-level stuff because you don't seem to like it, and
you wrap anything you don't like behind OO and call it "low level" so
that it fits your personal subjective preference and world view. OO may
fit your mind better for whatever reason, but you cannot assume your
head is God's template for every *other* individual.

BTW, Microsoft has ADO, DAO, etc. which are OO wrappers around RDBMS.
Java and other vendors do also. Whether OO is the best way wrap RDBMS
calls is another debate. My point is they already exist.

Further, even if OO *was* the best way to access RDBMS thru an app,
that does not necessarily extrapolate to all domains. OO being good for
X does not automatically imply it is good for Y also. I have already
agreed that OO may be good for writing device drivers and
device-driver-like things; but it has not been shown useful to view
everything as a device driver. I am more interested in seeing how OO
models biz objects rather than how it wraps system services and the
like. Biz modeling has been OO's toughest evidence cookie to crack (but
perhaps not the only).

And finally, just because one *can* view everything as objects does not
necessarily mean one should. One can also view everything as Lisp or
assembler or that Brainf*ck language.

>
> What I realized while trying to describe my preference to use DB
> procedures as the primary (re: only) interface between my applications
> and the database is because I believe my DB's physical representation of
> data belongs to it alone and that customers of the DB oughtn't be
> permitted to directly manipulate (change or query) its data.

When was the last time you've seen this happen? Again, SQL is NOT
"physical representation". For that matter, neither are files even.
File systems are a hierarchical database-like thing. "POKE 462625" is
accessing the physical directly.

> I realized
> this is exactly what data-hiding is all about and why expert object
> oriented designers and programmers emphasize the importance of
> interfaces to direct data manipulation.

"Data hiding"? I am working on "OO hiding". Relational is a high-level
modeling technique which tends to use "declarative interfaces".
Declarative interfaces are not necessarily worse than "behavioral
interfaces", which OO relies on. This sounds like yet another battle
between declarative interfaces versus behavioral interfaces. Note that
one could potentially mix them in RDBMS, but so far it does not appeal
very practical. And this is largely because the tight association
between data and behavior that OO likes simply does not work well in
biz apps. Thus, heavy behavioraltizing of RDBMS is not useful. I am
just pointing out it could be done and probably would be done if it
proved useful. OO forces an overly tight view of data and behavior.
Relational provides a consistency to declarative interfaces, but OO
does not provide any real structure and consistency to behavioral
interfaces. It creates shanty-town biz models.

GOF patterns are supposed to be a solution, but GOF patterns have no
clear rules about when to use what and force a kind of IS-A view on
modeling instead of HAS-A. GOF patterns are like an attempt to catalog
GO TO patterns instead of rid GO TO's. Relational is comparable to the
move from structured programming from GO TO's: it provides more
consistency and factors common activities into a single interface
convention (relational operators). OO lets people re-invent their own
just like there are a jillion ways to do the equivalent of IF blocks
with GO TO's.

OO has simply failed to factor and standardize common relationship and
collection idioms!!!!
OO has simply failed to factor and standardize common relationship and
collection idioms!!!!

That is why OO is such mess and its hard to figure out people's OO
designs. It makes me feel like a building inspector in a shanty town:
there are no building codes and rules. Relational operators and
normalization rules reign in the "creativity" that should be reigned
in. The "self-handling noun" view of OOP means that you get
self-reinventing nouns.

>
> I thought more about this and posted a second article, Databases as
> Objects: My schema is my class, which explored more similarities between
> databases and objects and their classes.
>
> <http://blogs.in-streamco.com/anything.php?title=my_schema_is_an_class>

See about ADO, DAO above

>
> I intend next to explore various design patterns from GoF and Smalltalk:
> Best Practice Patterns

How measured as "best"? Subjective internal votes?

> to see if the similarities persist or where they
> break down, and what can be learned from both about designing and
> implementing OO systems with relational data bases.
>
> If you agree there's such a thing as an object-relational impedance
> mismatch, then perhaps its because you're witnessing the negative
> consequences of tightly coupling objects that shouldn't be tightly coupled.
>
> There's a hypothesis in there somewhere.
>
> As always, if you know of existing research on the subject I'm anxious
> to read about it.
>
> --
> Visit <http://blogs.instreamfinancial.com/anything.php>
> to read my rants on technology and the finance industry.

oop.ismad.com
-T-

Thomas Gagne wrote:
> If you agree there's such a thing as an object-relational impedance
> mismatch, ...

This mismatch is mostly caused by the lack of education of object
propellerheads. Witness pathetic atempts to enhance method dispatch
with predicates. Finally, some folks begin to understand predicate
importance! The problem is that if you do it in ad-hock basis you'll
get some inconsistent messy design.

Here are few facts, which may help you to further appreciate the power
of relations.
1. Function call is formally a relational join (followed by
projection). That is

f(a) is the same as pi_x ( `y=f(x)` |><| `x=a`)

where `y=f(x)` is a binary relation coressponding to the function, and
`x=a` is a relation that has a single tuple.

A consequence of this fact is that function calls (or arithmetic
expressions) fit naturally into the SQL select and where clause.

2. Function composition is a join (again followed by projection).

3. Predicates can be mixed with relations, and arbitrary relational
algebra expression can be transformed into a normal
'select-project-join' form. This explains why most queruies fit nicely
into "select from where" SQL template.

4. The aggregate/group by construct reflects yet another important
mathematical construction: the equivalence relation. This is why it is
so easy to write queries that count things in SQL.

This is only the beginning of the list, and I assure you that you'll
get more return on your investment not if you spend your time
"brainstorming" how to fit databases into objects, but educating
yourself what database management really is.

> 1. Function call is formally a relational join (followed by
> projection). That is

In my opinion, its not very useful to say "X is really a Y". A lot of
paradigms, idioms, and ideas are interchangable such that one can be
viewed as the other and visa versa. Thus, implimenting one in the
other does not carry much weight.

As far as the impedence mismatch, I do think it exists. The main reason
is that relational is heavily based on sets, but OO is based on
navigational structures (pointers). The two are very hard to reconcile.
A model based on graphs is very different to work with than one based
on sets. (They are also interchangable, but the choice is a matter of
human convenience and thus productivity.)

-T-

topmind wrote:

> Thomas Gagne wrote:
> > An unexpected thing happened while debating topmind: I had an
> > epiphany. Instead of responding to the news group I thought about
> > it for a short bit (very short) and posted an article to my blog
> > titled, "The RDB is the biggest object in my system."
> >
> > <http://blogs.in-streamco.com/anythin...db_is_the_bigg
> > est_object_in_my_syst>
>
> > From the link:
>
> "Why shouldn't applications have embedded SQL? Because it's the same
> as accessing the private data members of an object. It shouldn't be
> done. OO programmers know the correct way to interface with an
> object is to use its method interface--not attempt direct
> manipulation of the object's data. OO programmer's attempts to
> violate that rule is what causes so much frustration mapping the
> application's data graph into a relational database's tables, rows,
> and columns. Those things belong to the DB--not to the application."
>
> (end quote)
>
> You OO'ers keep forgetting: SQL is an interface. I repeat, SQL is
> an interface. It is not "low level hardware".

SQL is a set-oriented language, it's not an interface as a language
doesn't do anything without context (in this case a parser-interpreter
combi)

> You OO'ers keep
> viewing it as low-level stuff because you don't seem to like it, and
> you wrap anything you don't like behind OO and call it "low level" so
> that it fits your personal subjective preference and world view. OO
> may fit your mind better for whatever reason, but you cannot assume
> your head is God's template for every other individual.

of course it's not low level stuff, SQL is a set-oriented language and
therefore doesn't match object-oriented languages, so a 'translation'
has to be made as you can't project one onto another in a 1:1 fashion.

> BTW, Microsoft has ADO, DAO, etc. which are OO wrappers around RDBMS.

no they're not. ADO and DAO aren't OO, as they're COM based so they're
actually procedural (library interfaces implemented on a live object).
Furthermore, they provide the interface you talked about to the DB,
which is often referred to as 'the client interface' or 'provider' when
it comes to database access.

> Further, even if OO was the best way to access RDBMS thru an app,
> that does not necessarily extrapolate to all domains. OO being good
> for X does not automatically imply it is good for Y also.

you don't get the point: in an OO application, which works on data IN
the application, you want to do that in an OO fashion. To obtain the
data from the outside is initiated INSIDE the application, thus also in
an OO fashion. As an RDBMS doesn't understand OO in most cases, but it
works with SQL as it has a SQL interpreter in place to let you program
its internal relational algebra statements in a more readable way,
you've to map statements from OO to SQL and set oriented results (the
sets) from the DB back to OO objects.

> I have
> already agreed that OO may be good for writing device drivers and
> device-driver-like things; but it has not been shown useful to view
> everything as a device driver. I am more interested in seeing how OO
> models biz objects rather than how it wraps system services and the
> like. Biz modeling has been OO's toughest evidence cookie to crack
> (but perhaps not the only).

huh? walls full of books have been written about this topic and you
declare it the toughest cookie to crack...

> And finally, just because one can view everything as objects does not
> necessarily mean one should. One can also view everything as Lisp or
> assembler or that Brainf*ck language.

sure, but that doesn't mean the language necessarily fits the purpose
you want to use it for. data oriented operations on sets is best suited
with SQL, as it is designed for that. other languages are designed for
other purposes. Mixing the two is often not that successful, though
that's not a problem per se as processing data is more or less a 3 step
process:
- move data from data producer to data consumer
- process data in data consumer
- move data from original data consumer to original data producer

so you can easily chop up this process in 3 parts and implement the
parts in the language best fit for the job.

> > I realized
> > this is exactly what data-hiding is all about and why expert object
> > oriented designers and programmers emphasize the importance of
> > interfaces to direct data manipulation.
>
> "Data hiding"? I am working on "OO hiding". Relational is a high-level
> modeling technique which tends to use "declarative interfaces".
> Declarative interfaces are not necessarily worse than "behavioral
> interfaces", which OO relies on. This sounds like yet another battle
> between declarative interfaces versus behavioral interfaces.

Could you define 'interface' for me, as it gets more and more abiguous
definitions in this post alone.

> Note that
> one could potentially mix them in RDBMS, but so far it does not appeal
> very practical. And this is largely because the tight association
> between data and behavior that OO likes simply does not work well in
> biz apps. Thus, heavy behavioraltizing of RDBMS is not useful. I am
> just pointing out it could be done and probably would be done if it
> proved useful. OO forces an overly tight view of data and behavior.
> Relational provides a consistency to declarative interfaces, but OO
> does not provide any real structure and consistency to behavioral
> interfaces. It creates shanty-town biz models.

you declare a lot of IMHO rubbish as 'truth' here. E.g.: why wouldn't
biz apps be helped with OO?

> GOF patterns are supposed to be a solution, but GOF patterns have no
> clear rules about when to use what and force a kind of IS-A view on
> modeling instead of HAS-A.

You also fall into the 'use pattern first, find problem for it
later'-antipattern.

a pattern is a (not the) solution for a well defined recognizable
problem. So if you recognize the problem in your application, you can
use the pattern which solves THAT problem to solve THAT problem in your
application. THat's IT. The GoF book names a set of patterns and also
the problems they solve. If you don't have the problems they solve, you
don't need the patterns.

Btw, the GoF book discourages inheritance a lot, just read it. It says
don't use inheritance if you don't have to.

> GOF patterns are like an attempt to
> catalog GO TO patterns instead of rid GO TO's. Relational is
> comparable to the move from structured programming from GO TO's: it
> provides more consistency and factors common activities into a single
> interface convention (relational operators). OO lets people re-invent
> their own just like there are a jillion ways to do the equivalent of
> IF blocks with GO TO's.

I've read a lot of nonsense in your post, but this is one of the most
striking examples. WHat on earth have GO TO's to do with the topic at
hand?

> OO has simply failed to factor and standardize common relationship and
> collection idioms!!!!
> OO has simply failed to factor and standardize common relationship and
> collection idioms!!!!

take your pills, you apparently forgot them

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

topmind wrote:
> <snip>
>
> BTW, Microsoft has ADO, DAO, etc. which are OO wrappers around RDBMS.
> Java and other vendors do also. Whether OO is the best way wrap RDBMS
> calls is another debate. My point is they already exist.
>
> Further, even if OO *was* the best way to access RDBMS thru an app,
> <snip>
>
You're missing something. I am not advocating wrapping the RDB with OO
stuffs. I am not saying OO is the best way to access a
database--directly or through any of the frameworks mentioned above. In
fact, I'm advocating the opposite. Deal with the DB on its own terms,
but treat it as an object. I'm recommending against accessing it using
its low-level interface (SQL), but instead that a higher-level
application/schema/problem domain-specific API be constructed, most
likely using procedures, and that applications should access the DB that
way.

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

On 20 Dec 2006 17:07:51 -0800, aloha.kakuikanu wrote:

> Thomas Gagne wrote:
>> If you agree there's such a thing as an object-relational impedance
>> mismatch, ...
>
> This mismatch is mostly caused by the lack of education of object
> propellerheads. Witness pathetic atempts to enhance method dispatch
> with predicates. Finally, some folks begin to understand predicate
> importance! The problem is that if you do it in ad-hock basis you'll
> get some inconsistent messy design.
>
> Here are few facts, which may help you to further appreciate the power
> of relations.
> 1. Function call is formally a relational join (followed by
> projection). That is
>
> f(a) is the same as pi_x ( `y=f(x)` |><| `x=a`)
>
> where `y=f(x)` is a binary relation coressponding to the function, and
> `x=a` is a relation that has a single tuple.

LOL! That's amusing.

When you are going to turn your TV-set on, do you a relational join over
its diodes and resistors following by a majestic projection, or just press
the button "ON?"

> A consequence of this fact is that function calls (or arithmetic
> expressions) fit naturally into the SQL select and where clause.
>
> 2. Function composition is a join (again followed by projection).

Ah, you mean "ON" followed by "1"! GREAT!

> 3. Predicates can be mixed with relations, and arbitrary relational
> algebra expression can be transformed into a normal
> 'select-project-join' form. This explains why most queruies fit nicely
> into "select from where" SQL template.

These should be the buttons "Vol+" and "Vol-." But, wait, how to select
next to the last diode in SQL?

> 4. The aggregate/group by construct reflects yet another important
> mathematical construction: the equivalence relation. This is why it is
> so easy to write queries that count things in SQL.

Yes, I always wondered how much diodes the damned thing has...

> This is only the beginning of the list, and I assure you that you'll
> get more return on your investment not if you spend your time
> "brainstorming" how to fit databases into objects, but educating
> yourself what database management really is.

Isn't FORMAT C: /q everything one should know about it? (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Let me try to clear something up, and thanks to Topmind, Frans, and
Stefan for helping me get there.

In OO, objects are subclassed to make them more specific, not more
general. I consider SQL to be a low level language, as far as RDBs are
concerned, because it is application-ignorant. It's like C for
relational operations. SQL doesn't know anything about my application.

So, I subclass Model (so-to-speak) and add data that is domain-specific
to create my domain-specific database. Why access it from applications
using the same domain-ignorant language? Instead, I construct
procedures that create a domain-specific interface. Instead of the
lower-level

select * from account, user where user.userId=X and account.userId =
user.userId

when instead I can use

exec getAccountsFor {}userId=X

?

Besides its brevity, the procedure name clearly communicates the intent
of the operation (stbpp pattern: intention revealing message), makes
obvious its parameters, and provides a layer of indirection behind which
its implementation can change without affecting the procedure's users.

From SQL I've constructed procedures to provide a higher-level,
domain-specific, language-and-paradigm-neutral interface to a
domain-specific database.

To find all the places in my application source code that get account
information with user IDs it is much easier to find senders (callers) of
getAccountsFor than it would be to find all the SQL referencing both the
account and user tables. Could the latter be done? Sure, but when a
more efficient and accurate alternative exists why would you?

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

Stefan, what "subject" were you replying to when you wrote that?

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.