Object/Relational Mapping is the Vietnam of Computer Science

Ruby
101

Austin Z. wrote:

Well, it isn’t. And most SQL databases are still better structured
than object databases will ever be.

disclaimer: I have plenty of experience with SQL but none at all with
object databases.

That being said, it seems to me that OODBs are simply an object-based
implementation of a relational database, as opposed to the current crop
of SQL databases which are record-based. Otherwise the concepts between
OODB and SQLDB seem to map 1-to-1. Instead of rows in tables you have
objects in a graph. Instead of a foreign key you have a direct pointer
to an object. Instead of an index on a foreign key (Foo#bar) you keep a
list of references (Bar#foo[]) in the foreign object.

These are physical implementation details, not major conceptual
differences. And I fail to see how that makes an OODB inherently
hierarchical. Of course it’s possible to make a hierarchical object
model but that only reveals the incompetence of the designer, not of
OODBs as a whole.

Please enlighten me. Thank you.

Daniel DeLorme

102

On 3/28/07, Eleanor McHugh [email protected] wrote:

checking with Google. Each time someone fires off an ill-considered
opinion based on fashion, marketing hype or religious predilection
they’re effectively polluting our shared intellectual space, and yet
somehow it’s those who suffer this on a daily basis who’re the
offensive ones…

As the one who has been accused of being excessively abusive in this
thread, I need to point out that I didn’t call the author of the
original post an idiot; I said that they were either ignorant or an
idiot. One cannot rationally say that “I think relational databases
are evil” if you know anything about the theory unless you’re being
willfully ignorant and/or stupid. As is said above, you’re choosing
fashion, hype, or religion over science and knowledge.

There are a lot of things that one can say about SQL databases that
are minimally based on relational theory, most of them pretty darned
awful, but the merest bit of knowledge about data theory precludes you
from suggesting that any of a number of other “database” types are
even viable from that standpoint.

They may work, but they don’t do so through any rigorous theory or
application of computer science; there’s a lot of code out there that
does exactly that, and I’ve written some of it. (Not for these types
of systems, obviously.) But ultimately, one hits a point where the
lack of theory involved in your data store will come to bite you. A
lot of people start looking at other options than SQL databases
precisely because the reality of SQL doesn’t match relational algebra
and the relational model. They assume that because database management
system vendors, who are part of the hype machine and are just as
vulnerable to the hype, didn’t implement things properly, that the
whole theory is bunk.

Well, it isn’t. And most SQL databases are still better structured
than object databases will ever be.

-austin

103

On Mar 28, 2007, at 7:54 PM, Austin Z. wrote:

There’s no theory behind OODBs, much less relational theory. OODBs are
ways to serialize your object graph.

OK Austin, I’ll give you 100% of that statement. Let’s say you are
completely right.

Who says that isn’t useful?

Ruby includes Marshal, YAML, and PStore for these uses, right?
Arguably one of their biggest weaknesses is that they have to restore
the entire graph before they can do anything with it right? If an
OODB can eliminate that one restriction, wouldn’t that put it leaps
and bound ahead of all three of these libraries?

I don’t know about you, but I use all three of those a lot. So it
seems a simple OODB has some value for me.

James Edward G. II

104

On 3/28/07, Daniel DeLorme [email protected] wrote:

objects in a graph. Instead of a foreign key you have a direct pointer
to an object. Instead of an index on a foreign key (Foo#bar) you keep a
list of references (Bar#foo[]) in the foreign object.

There’s no theory behind OODBs, much less relational theory. OODBs are
ways to serialize your object graph. The concepts between OODB and
SQLDB barely map at all, except that they both store data; the
concepts between OODB and relational theory are so far apart as to not
even be on the same planet.

You don’t normalize data in object databases; there’s no reason to do
so. You structure things according to your application’s object model
– and pray to Codd that you never need to access the data in a
different way than your object model.

These are physical implementation details, not major conceptual
differences. And I fail to see how that makes an OODB inherently
hierarchical. Of course it’s possible to make a hierarchical object
model but that only reveals the incompetence of the designer, not of
OODBs as a whole.

Object graphs are inherently hierarchical, not relational. I suspect
you’ll be enlightened even by what’s on Wikipedia, flawed as it is. I
strongly recommend you read that and what’s on Ward Cunningham’s c2
wiki; you’ll learn a lot more than I have patience to explain right
now, because OODBs are conceptually no different than hierarchical
databases from the 1970s married to conceptually “hot” object
orientation. Same thing with XML databases.

Hierarchical databases can have value, but rarely as much as their
proponents suppose, and never as much as relational databases.

-austin

105

I don’t use: .NET, Major relational products (often)… many other
‘things’.

http://www.matisse.com/pdf/product_information/Whitepapers/DotNETarticle.pdf

The idea that ‘post-relational’ implies a product which is a
‘later/better’ than relational products is at the least, humorous.
Dick Pick is chuckling.
Some are taking it seriously though:
http://www.fit.vutbr.cz/study/courses/PRD/

There are some interesting experience summaries here:

Being lost is beautiful.
As then you can find your way.

Markt

106

Austin Z. wrote:

OODB and SQLDB seem to map 1-to-1. Instead of rows in tables you have
objects in a graph. Instead of a foreign key you have a direct pointer
to an object. Instead of an index on a foreign key (Foo#bar) you keep a
list of references (Bar#foo[]) in the foreign object.

There’s no theory behind OODBs, much less relational theory. OODBs are
ways to serialize your object graph. The concepts between OODB and
SQLDB barely map at all, except that they both store data; the
concepts between OODB and relational theory are so far apart as to not
even be on the same planet.

I see that you barely skimmed over my post and failed to answer any of
the 3 ways in which I showed how OODBs and SQLDBs are similar. Instead
you answered with something that boils down to your usual “OODBs are
evil” mantra. Proof by repeated assertion works in politics, not
science. (although I’m just a humble engineer; what do I know about
lofty “science”, heh?)

You don’t normalize data in object databases; there’s no reason to do
so. You structure things according to your application’s object model
– and pray to Codd that you never need to access the data in a
different way than your object model.

How is a class not normalized? How are instances of a class different
than rows of a table?

Object graphs are inherently hierarchical, not relational.

Er… maybe there’s a definition of “hierarchical” that I haven’t heard
about. I mean, hierarchical trees are a form of graph but the opposite
is just not true. I suspect you’ll be enlightened even by what’s on
Wikipedia, flawed as it is. :stuck_out_tongue:

Daniel DeLorme

107

On 3/28/07, Daniel DeLorme [email protected] wrote:

even be on the same planet.
I see that you barely skimmed over my post and failed to answer any of
the 3 ways in which I showed how OODBs and SQLDBs are similar. Instead
you answered with something that boils down to your usual “OODBs are
evil” mantra. Proof by repeated assertion works in politics, not
science. (although I’m just a humble engineer; what do I know about
lofty “science”, heh?)

Sorry, Daniel, but you didn’t show anything. You claimed that
they’re similar; you conflated things that have no relationship
whatsoever. Foreign keys and object pointers aren’t even remotely
related. If modern object databases are beginning to look like
relational databases (which they’re not, really) it’s because the
practitioners have realised that what they’re doing is technical bunk.
You’ve confused physical implementation similarities (because SQL
database providers are hitting the ODB bong, too) with logical models.

Seriously: read about the relational data model. You won’t confuse
object databases and relational databases (even SQL databases!) ever
again.

You’re right that object graphs don’t have to be hierarchical;
object databases are uniformly so, though. I highly recommend you take
the time it requires to study relational theory. I’m not a heavy
practitioner myself, anymore – I don’t do stuff that needs databases
right now.

By the by, I’ve never said the ODBs are evil. Just stupid and not
based on any viable theory of data modelling, and of limited utility
because of that stupidity. Relational theory, however, provides for
the ability to model anything in data storage efficiently (and not
related to the physical models).

-austin

108

On 3/28/07, James Edward G. II [email protected] wrote:

On Mar 28, 2007, at 7:54 PM, Austin Z. wrote:

There’s no theory behind OODBs, much less relational theory. OODBs are
ways to serialize your object graph.
OK Austin, I’ll give you 100% of that statement. Let’s say you are
completely right.

Who says that isn’t useful?

James, if you look over what I’ve said in this thread, you’ll note
that I have explicitly said that you can successfully store your
data. The moment you need to access the data in a different direction,
you’re completely screwed.

Heck, I use Marshal in PDF::Writer because I need to store a
specific object graph and never query the data structures in a
different way.

Persistent data – especially that which belongs to businesses – is
often very different, though. Remember the maxim I postulated early in
the thread: data is king. The data you have is far more important than
your program, and OODBs fall down because they typically tie you to a
single object model.

As I was discussing with someone off-list, the data that I need for a
customer report is very different than the data that I need for a
summary of how many customers bought a particular widget and how often
in which locale. Object databases force you to query for a full object
even if you need a tiny portion of that object. In the putative
example I describe above, I only need to know a customer’s locale
(state or province, if you prefer) – but with an object database I
have to restore the entire customer object before I can then whittle
down the data to exactly what I need. Worse, because most people don’t
know anything about data modelling (and thus make pretty bad object
modellers, too), there’s a good chance that all of my orders are
reachable through my customers, meaning that to get to the orders, I
have to query through the customer object in the first place!

Pascal (or Date) had a good definition of the relational data model.
The relational model is tuples and attributes with associations
(relations); yes, I’m paraphrasing here.

Ruby includes Marshal, YAML, and PStore for these uses, right?
Arguably one of their biggest weaknesses is that they have to restore
the entire graph before they can do anything with it right? If an
OODB can eliminate that one restriction, wouldn’t that put it leaps
and bound ahead of all three of these libraries?

It’d put it a couple of steps ahead, not leaps and bounds, because
you’re still stuck with your single query path. If that’s all your
data needs, fine. But most data needs much more than that, and it
must be dealt with by more than one application ultimately.

I have said a lot of things about this and how one would work with
both application and integration databases as Martin F. has talked
about them (and wrapping the databases in services) – and that’s
often a good thing to deal with, too, but it’s sometimes not
applicable.

I don’t know about you, but I use all three of those a lot. So it
seems a simple OODB has some value for me.

I rarely use those in real applications. They’re good for
checkpointing, as far as I’m concerned, and that’s about it. I
certainly wouldn’t store a customer’s persistent data in them, or in
an OODB. Period.

-austin

109

Austin Z. wrote:

Sorry, Daniel, but you didn’t show anything. You claimed that
they’re similar; you conflated things that have no relationship
whatsoever.

It might be impudent of me but have you considered that just maybe you
are the one who can’t see the relationship? But you are right I didn’t
show anything. Just take any ORM layer and the fact that you can
directly and easily map a SQLDB to an object model is all the proof I
need that a RDBMS can indeed be expressed as an object graph and that
an OODB can therefore be relational.

You’re right that object graphs don’t have to be hierarchical;
object databases are uniformly so, though.

I have trouble believing that all of OODB implementers would be so
stupid as to implement a hierarchical-only structure. If that is indeed
the case then I can see that a being a complete waste of time.

It’s now clear to me that we are arguing about different things; you
about the (hierarchical) OODBs that you know and I about the
(relational) OODBs that I can imagine. In the end, I believe OO is more
about the physical model than the logical model of data.

Darn semantics strike again!

I highly recommend you take
the time it requires to study relational theory. I’m not a heavy
practitioner myself, anymore – I don’t do stuff that needs databases
right now.

Unfortunately my brain has a strong resistance to jargon-rich
litterature such as academic papers or legalese. :frowning:

Daniel

110

On 3/28/07, Daniel DeLorme [email protected] wrote:

Austin Z. wrote:

Sorry, Daniel, but you didn’t show anything. You claimed that
they’re similar; you conflated things that have no relationship
whatsoever.
It might be impudent of me but have you considered that just maybe you
are the one who can’t see the relationship? But you are right I didn’t
show anything. Just take any ORM layer and the fact that you can
directly and easily map a SQLDB to an object model is all the proof I
need that a RDBMS can indeed be expressed as an object graph and that
an OODB can therefore be relational.

Wrong. This is completely backwards. The relational model can
certainly model an object graph; an object graph is not thereby
automatically relational. You’re assuming that “a therefore b” also
means “b therefore a” and that just ain’t the case at all.

Object databases aren’t based on relational theory. They pride
themselves on being so-called “post-relational”; in reality, they’re
not based on any viable theory. They’re brute force applications of
fads and prejudices.

Darn semantics strike again!

Object database proponents tend to believe that the relational theory
is … bunk. In return, they offer nothing that hasn’t been tried
before and shown wanting.

I highly recommend you take
the time it requires to study relational theory. I’m not a heavy
practitioner myself, anymore – I don’t do stuff that needs databases
right now.
Unfortunately my brain has a strong resistance to jargon-rich
litterature such as academic papers or legalese. :frowning:

The basics of it aren’t hard; it’s set theory with relational algebra.
I’m just not good enough at it to explain it nearly as well as some of
the papers that are out there. If you’d really like, I’ll look at
posting some pointers to good explanations of the relational theory of
data on my blog when I have time (I’m in the middle of a QA handoff
right now, so I have little time for serious research). The starting
points I mentioned earlier, though (Wikipedia and the c2 wiki) are
really good and get you ready for understanding much of what Fabian
Pascal and Chris Date say. One of these days I will buy the Third
Manifesto, but right now, I have far too much to do otherwise.

-austin

111

Austin Z. wrote:

I highly recommend you take
the time it requires to study relational theory
Unfortunately my brain has a strong resistance to jargon-rich
litterature such as academic papers or legalese. :frowning:
The basics of it aren’t hard; it’s set theory with relational algebra.
I’m just not good enough at it to explain it nearly as well as some of
the papers that are out there.

I’m presenting on this subject this very evening to the Melbourne
Ruby group this very evening. It’s a compressed version of a seminar
series I’ve produced to introduce the basics of information modeling
for relational databases, with tie-ins to object modeling and object
role modeling (which is unrelated to the former, BTW).

I demystify the meaning and key functions of normalization, show the
weaknesses inherent in both the relational and the object oriented
approaches (some of which are common to both), and show how object
role modeling avoids the major weaknesses of both sides, by combining
strong normalisation and constraint capability with efficient and
convenient database access.

I’ll be posting my slides and a video of my presentation somewhere
hopefully shortly afterwards, and code will be forthcoming in the
following months.

Clifford H…

112

On Thu, 29 Mar 2007, Daniel DeLorme wrote:

Unfortunately my brain has a strong resistance to jargon-rich litterature
such as academic papers or legalese. :frowning:

http://erlang.org/download/armstrong_thesis_2003.pdf

-a

113

On 29-Mar-2007, at 07:20, Austin Z. wrote:

As I was discussing with someone off-list, the data that I need for a
customer report is very different than the data that I need for a
summary of how many customers bought a particular widget and how often
in which locale.

We do such analyses (a good variety of them) in stock portfolio
management, several hundred times a day. The ‘anchors’ of such
search are very ad-hoc in practice.

Fund managers, who typically do not have programming skills, sit with
programmers to interactively build hyper-cubes with arbitrary classes
– and their attributes – as dimensions. We have several such ‘cube
terminals’ open in front of us. Minute-by-minute decisions are made
based on analyses of such cubes. Typical number of individual
objects read during an analysis ranges between 1.5 and 20 million.
On our 833 MHz UltraSparc server, most of them take under 10 seconds!

Object databases force you to query for a full object
even if you need a tiny portion of that object. In the putative
example I describe above, I only need to know a customer’s locale
(state or province, if you prefer) – but with an object database I
have to restore the entire customer object before I can then whittle
down the data to exactly what I need.

Not necessary – partitioning techniques, vertical partitioning in
particular, have long been (as in, for over twenty years) used in
some object databases. In Vision, for instance, an opaque object
stub is what is returned upon object retrieval. Which parts of the
object ‘actually’ get loaded is dependent upon access; however, the
developer is unaware of this (the ‘opaque’ part).

A variety of collection classes (examples include lists, indexed
lists and time-series collections) are used to model relationships
between different classes. Navigation uses the keys of such
collections. Back references are established, where needed,
similarly to foreign keys in RDBMSs.

Over the years of such every-day-hundreds-of-ad-hoc analyses, I have
not felt constrained to hierarchically navigate anything at all!

One point where I agree with you is that most such systems are vendor-
specific. Vision, for instance, provides only one way of accessing
information – through a dialect of Smalltalk.

Greetings,
JS

114

Austin:

The basics of it aren’t hard; it’s set theory with relational algebra.
I’m just not good enough at it to explain it nearly as well as some of
the papers that are out there. If you’d really like, I’ll look at
posting some pointers to good explanations of the relational theory of
data on my blog when I have time (I’m in the middle of a QA handoff
right now, so I have little time for serious research). The starting
points I mentioned earlier, though (Wikipedia and the c2 wiki) are
really good and get you ready for understanding much of what Fabian
Pascal and Chris Date say. One of these days I will buy the Third
Manifesto, but right now, I have far too much to do otherwise.

I for one would very much appreciate that [1].

I had a dig in Wikipedia, and there are good articles there; they’re
about at my level. There are good explainations of the underlying model,
and how you’d use that in simple ways.

Here: Relational algebra - Wikipedia
also: http://en.wikipedia.org/wiki/Relational_model

I couldn’t find anything about databases at http://c2.com; I imagine I’m
looking in the wrong place.

I didn’t find anything that made me think: “But of course! I see why
this is the correct way now! Data stored like this has features A, B and
C, and clearly, those provide essential benefits X, Y and Z”

X could be “being able to see my data in any new way that I want in a
new application” and Y might be “being able to guarantee that at a
future time I can respond to new requirements on my model and add new
kinds of information, or merge it with other models”. Z might be “being
able to provide queries to others that transparently expand the view of
the world they have”, etc. All of these are just example ideas I like at
the moment, but I’d embrace other benefits if I could see they were
obviously much more important.

Cheers, and good luck with the hand off,
Benjohn

[1] I’d love it if there were knowledge consultants in the world. Just
like I can go to a shop and have someone assist me in buying clothes,
I’d like to be able to go to someone and say “I’d like to know about x”,
and they would say “ah perhaps you’d like this, this and this, then”,
and I’d say “yes, those sound good, but this isn’t quite right”, etc. x
could be music, or part of biology, or international relations. And then
I could just drink things up and appreciate everything out there that
interests me.

115

Daniel DeLorme wrote:

relational model.
Have you got an example?

116

Austin Z. wrote:

an OODB can therefore be relational.

Wrong. This is completely backwards. The relational model can
certainly model an object graph; an object graph is not thereby
automatically relational. You’re assuming that “a therefore b” also
means “b therefore a” and that just ain’t the case at all.

I think you have it backwards. All relational models can be expressed
with an object graph but not all objects graphs can be expressed with a
relational model. Which is why I said than an OODB can be relational,
not that all OODBs are inherently relational.

Object database proponents tend to believe that the relational theory
is … bunk.

It’s not because some OODB proponents are ignorant that it makes OODBs
an inherently worthless concept. I’d rather base my opinion on my own
analysis of the potential rather than the claims of the
proponents/marketers.

points I mentioned earlier, though (Wikipedia and the c2 wiki) are
really good and get you ready for understanding much of what Fabian
Pascal and Chris Date say.

After reading the “Interpretation” part of the wikipedia article I think
I’m starting to understand your position. You like the elegance of set
operations, the higher-level abstraction of manipulating relations
rather than individual rows. Am I right? Well anyway it didn’t change my
opinion. I still believe that:

  tuples of relation == rows of table == instances of class

Daniel

117

On 29 Mar 2007, at 03:56, Daniel DeLorme wrote:

object graph and that an OODB can therefore be relational.
No, this demonstrates that an OODB can be implemented in terms of an
SQLDB. This in no way demonstrates that the converse is true. Much of
the point of an OODB is to capture a given object hierarchy, which is
essentially a constrained Entity-Relationship model - the most
obvious constraint being the relaxation of normalisation conditions.

Personally I want each item of data to occur once - and only once -
in my database, as that way I can ensure that a single change is
reflected universally and performed efficiently. I also want the
flexibility of joins to composite new views of my database based upon
whatever arbitrary query conditions I need fulfilling, and yet again
I want that process to be efficient and to guarantee that all data
returned is universally accurate and consistent at the instant that
the query is performed. Everything else I can do in software.

My measure of efficiency in this case would be based upon individual
data store reads, as for any significant data-set that will be the
primary constraint on my application’s performance. Compositing
objects at run-time will be many orders of magnitude faster than
loading the data from persistent storage.

It’s now clear to me that we are arguing about different things;
you about the (hierarchical) OODBs that you know and I about the
(relational) OODBs that I can imagine. In the end, I believe OO is
more about the physical model than the logical model of data.

Which is its shortcoming. If you model data based upon a physical
structure, you then need to optimise your database engine to suit
that structure. Taking the relational path and putting logical
structure first leads to an implementation that is optimised for
general queries, not just the specific queries embodied in a given
object model.

Think of the relational model as a scientist’s take on data, where an
OODB would be an engineer’s.

The scientist is interested in the general properties of data itself,
with the nature of individual data items being an implementation
detail - sure they add character to the problem space, but they don’t
really further one’s understanding of it’s geometric principles. The
fact that the relational model is a process-oriented implementation
of Occam’s Razor sits well with this view.

The engineer of course is more concerned about getting “this damn
thing I’m building now” to work and often cuts a few corners where
theory is concerned. Fine, do that in your software if it makes
sense, but don’t do it with your data model: it’s the underpinning of
not only your application, but of every other application that needs
access to the same data-space, so generalising the model at a later
date will be the most expensive change you can make.

Ellie

Being and Doing are merely useful abstractions for the ‘time’-
dependent asymmetries of phase space.

118

Daniel DeLorme schrieb:

relational model. Which is why I said than an OODB can be relational,
not that all OODBs are inherently relational.

I am really for OODBs, but I can’t agree with you here. A simple class
can be seen as a data container. In that regard it is really not more
than a table with the attributes being the columns and each instance is
a row. But that is not really an object. That is a data based view on an
object that every union based type fulfills. It gets really object
oriented when you add inheritance here. And then the mapping is not so
direct anymore. (Note: you don’t really need classes for this, but I
will use them for better understanding)

So for example I have class A with an attribute id and a class B with an
attribute email and a class C that has the parents A and B and has an
attribute name. Now what do we do? Make a table for A, one for B and one
for C, or one table for all of them? Even if you simplify this to single
inheritance, you still have that problem.

When I for example use one table per class and link these tables
together to represent the inheritance, then I get a massive problem in
my queries. Because If I query on C I might have to query on A and B as
well.

When each subclass table contains all data of that class and the super
classes, then a query on C is done on only one table. But the relation C
“is a” A is not represented in this. C could be a class completely
unrelated to A, which means we reduced it to the data holder type again.

It is the same when you store A,B and C in the same table. Only that you
then need additional logic based on the class for the empty entries.

So I think there is a part of the object system that is equal (bijective
projection) to a part of the relational system, but in both cases not
the whole model is covered.

So if your objects can be mapped nicely to an relational database, then
most possibly you are using a not so object oriented part of your object
system.

Then two more things…

  • OODBs are restricted to one language only:
    db4o is an example against it. Not only covers it the Java Platform, it
    covers also the .Net languages. And of course an object stored from .Net
    can be used in the Java Platform as normal object then. You could say
    that .Net and the Java Platform are using more or less the same kind of
    class structure (single inheritance for example), but then it is all a
    question of doing the mapping, or not?

  • OODBs don’t allow me to access the data in a different way than my
    original object modell:
    Well, is there really a limitation that prevents a OODB from saying that
    certain attributes of an class are really the properties of another
    class? This way I don’t need to always create a full object.

  • OODBs have roots and I have to use these roots to navigate to my real
    object:
    db4o for example allows you to query on a per class base, so each
    instance can be root. You need other objects only for joins. see
    S.O.D.A.

  • OODBs are hierarchic:
    I think they can be, but they don’t have to. There is also for example
    the network model. In fact it might also use parts of the relational
    model. I think the queries used for the OODB are giving a hint how it is
    represented inside, but in general it is an implementation detail. So an
    object graph can be understood as directed graph, and of course I can
    define a a minimal spanning tree on the subgraph that is transitive
    reachable from my selected root. But the root is more or less arbitrary,
    and the graph might not be connected enough for just one tree.

  • object-relational databases are OODBs:
    As I tried to show with the subclass example there are parts of the
    object model that don’t fit so well in the relational model and there
    are parts of the relational model that don’t fit so well in the object
    model. So in the end you get only a part of both worlds. Up to you to
    decide if that is good enough

  • there are much less tools for OODBs:
    that’s right, no use to say more.

I also think that the relational algebra is more advanced than
everything an OODB could provide. I think most OODB queries will for
example have a problem with operations like getting the maximum/minimum
of something, or subtracting one attribute from the other and such
things. So especially in cases of reporting OODBs are not that good, not
unless you do many of the operations outside the database system.

bye blackdrag

119

Jochen T. [email protected] writes:

So for example I have class A with an attribute id and a class B with
an attribute email and a class C that has the parents A and B and has
an attribute name. Now what do we do? Make a table for A, one for B
and one for C, or one table for all of them? Even if you simplify this
to single inheritance, you still have that problem.

When I for example use one table per class and link these tables
together to represent the inheritance, then I get a massive problem in
my queries. Because If I query on C I might have to query on A and B
as well.

The inheritance relation of an ER model can be represented in the
table model as views. Depending on the circumstances, it might be
favourable to model the subclasses as distinct tables and the
respective superclasses as views or the other way around.

Either way, queries over the subclasses will query the superclasses, but
that’s not different from the OO point of view.

So if your objects can be mapped nicely to an relational database,
then most possibly you are using a not so object oriented part of your
object system.

As Austin already has mentioned, object modeling can be seen as a
special form of ER modeling - which explains the plethora of
dysfunctional and outright ugly object hierarchies one encounters in
software engineering because those people do not understand the
fundamental mathematics.

S.O.D.A.
The point is still valid: OODBs are not suited to represent arbitrary
views to the data as long as there isn’t a possibility of creating new
object classes based on the query.

I also think that the relational algebra is more advanced than
everything an OODB could provide. I think most OODB queries will for
example have a problem with operations like getting the
maximum/minimum of something, or subtracting one attribute from the
other and such things. So especially in cases of reporting OODBs are
not that good, not unless you do many of the operations outside the
database system.

While relational databases do have a sound mathematical foundation
in relational algebra and set theory (which faciliates optimising
queries in an efficient way), I haven’t seen anything like that for
OODBs.

Sebastian

120

On 3/29/07, Daniel DeLorme [email protected] wrote:

Austin Z. wrote:

an OODB can therefore be relational.
Wrong. This is completely backwards. The relational model can
certainly model an object graph; an object graph is not thereby
automatically relational. You’re assuming that “a therefore b” also
means “b therefore a” and that just ain’t the case at all.
I think you have it backwards. All relational models can be expressed
with an object graph but not all objects graphs can be expressed with a
relational model. Which is why I said than an OODB can be relational,
not that all OODBs are inherently relational.

Um, no. All object graphs can be modelled in a relational schema (that
is, an instance of the relational model). Some of them aren’t
convenient to do, but they can be modelled. Object databases, on the
other hand, reject that theory.

There’s nothing that says that an object database couldn’t be based on
the relational model. Sadly, object database vendors pride
themselves on their relational model ignorance. It’s that simple.

Object database proponents tend to believe that the relational theory
is … bunk.
It’s not because some OODB proponents are ignorant that it makes OODBs
an inherently worthless concept. I’d rather base my opinion on my own
analysis of the potential rather than the claims of the
proponents/marketers.

The potential of an object layer on top of the relational model is
definitely possible and would be very useful, although you really
want to use the proper relational model (e.g., not even what SQL
database vendors are selling these days – since we’re talking
potential here). The reason I mentioned “The Third Manifesto” is
that it’s an attempt by colleagues of Fabian Pascal (Chris Date and
Hugh Darwen) to deal with this:
http://en.wikipedia.org/wiki/The_Third_Manifesto

Really worthwhile, from everything I hear. I just have too many things
to do to risk being inspired by this thing right now :wink:

points I mentioned earlier, though (Wikipedia and the c2 wiki) are
really good and get you ready for understanding much of what Fabian
Pascal and Chris Date say.
After reading the “Interpretation” part of the wikipedia article I think
I’m starting to understand your position. You like the elegance of set
operations, the higher-level abstraction of manipulating relations
rather than individual rows. Am I right? Well anyway it didn’t change my
opinion. I still believe that:

  tuples of relation == rows of table == instances of class

Sadly, that’s not how current object databases work. Additionally, you
generally won’t model your classes exactly the same as your relations
as I was mentioning to my off-list correspondent. You should model
your objects on your queries more often than not.

If what you’re saying is that there isn’t a meaningful
object-relational impedance, I’d agree with you completely. However,
the perception of an object-relational impedance has caused a lot of
people to hare off in directions that don’t make any sense whatsoever.

-austin