Object/Relational Mapping is the Vietnam of Computer Science

[Jochen Theodorou]

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.

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

 

[Austin Ziegler]

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.

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

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

 

[Sebastian Hanigk]

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.

* 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.

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

 

[Chad Perrin]

[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.

That might just be an excellent idea for how to put together the
university of the future -- but I'm not holding my breath. I rather
suspect university "educations" will continue to be half-baked
checklists of topic overviews presented in the most painful
institutional styles available for quite some time to come.

 

[Jochen Theodorou]

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.

combining it with a view is surely a good idea. It makes the queries
more easy. I don't want to say it is different, it is just not as nice
as with normal tables.

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.

I don't agree with austin and the resulting ugly class hierarchy is
prove enough for me. Not in all cases of course

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.

ok, let me quote Carl here:
Indeed db4o was intended for one-app-one-schema but there is no reason
to stop thinking and designing here. Why should it not be possible to
have "object views" or "class-to-class" mappings if people need that? I
am sure that we will get to a stage where we will think about ways to
supply such functionality.

So I am not saying I know a database that can do arbitrary views, but on
the other hand I don't think OODBs will never be able to do that. Your
last resort is always a object describing the class and the values to
form an instance. db4o does already have this. So I think the step to an
arbitrary view is not out of reach.

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.

and why is it needed? you can describe objects as sets too, they are
just more complex. But I am no scientist in that area. In fact I think
the object model is a higher level of abstraction that allows you to use
different underlaying techniques, for example a partial relational
model. And of course you can apply the theories of that area for that
part of the implementation.

Why not consider OODB mathematics as part of graph theory and others?

bye blackdrag

 

[Austin Ziegler]

and why is it needed? you can describe objects as sets too, they are
just more complex.

No, they're not (more complex). The *only* thing about objects that
relational theory can't model is operations (e.g., encapsulation). So,
no, objects aren't just "more complex sets."

But I am no scientist in that area. In fact I think the object model
is a higher level of abstraction that allows you to use different
underlaying techniques, for example a partial relational model.

Please, please, *please* read more about relational theory before you
make statements like this, because it's technical nonsense. There *is*
no "object model."

Part of the problem, of course, is that a lot of terms are used and
reused imprecisely.

1. The Relational Model of Data is the combination of set theory and
relational algebra. There is no corresponding theory or mathematical
basis for object orientation. That is, there's no "Object Orientation
Model of Data".

Object orientation is, in fact, an implementation technique -- a
refinement of procedural programming that more tightly ties data with
operations related to that data. That's an important point, too:
object orientation is about *programming*. It is not about data and
the storage of data.

2. When *implementing* something, you will model the data. This can be
your data model that can be extended into an object model for
programming purposes. These "models" are better considered "schema";
they describe the layout of the data.

Just because one *can* create something that works without a
mathematical theory behind it does not mean that one *should* do so. One
certainly shouldn't claim that the thing without a mathematical theory
behind it is superior to the thing with -- because that's something you
should be able to demonstrate with, well, another theory. Performance
metrics are not evidence of superiority of concept; just of
implementation.

And of course you can apply the theories of that area for that part of
the implementation.

Why not consider OODB mathematics as part of graph theory and others?

There are no OODB mathematics, and that's part of the point that I've
been trying to make. If you can point to OODB mathematics papers and
theories, I'll retract or clarify that statement, but I have a
reasonably high level of confidence that object orientation isn't
expressed in terms of mathematics or theory the way that the relational
model is.

Sure, an object store can be set up to allow for smart loading and such,
but that *doesn't* mean that it's a good idea. It might be the "right
now" idea, but it is something you'll have to pay the piper for using at
some point in the future.

Like it or not.

-austin

 

[M. Edward (Ed) Borasky]

Please, please, *please* read more about relational theory before you
make statements like this, because it's technical nonsense. There *is*
no "object model."

Yet. That you know of. Yet.

Seriously, the folks in the UK that developed the PI-Calculus have done
some work in computer-science models of objects, but I don't know enough
about them to know if they're relevant to this discussion. The one
reference I have is on the edge of my readability scale -- if I sat down
with the book and the right programming language, I might be able to
learn it, but there are other things I'm more interested in doing.

 

[M. Edward (Ed) Borasky]

[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.

That might just be an excellent idea for how to put together the
university of the future -- but I'm not holding my breath. I rather
suspect university "educations" will continue to be half-baked
checklists of topic overviews presented in the most painful
institutional styles available for quite some time to come.

Maybe ... but for all practical purposes, you can do what benjohn
describes on the Internet. That's why I spend so much time here.

 

[Chad Perrin]

[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.

That might just be an excellent idea for how to put together the
university of the future -- but I'm not holding my breath. I rather
suspect university "educations" will continue to be half-baked
checklists of topic overviews presented in the most painful
institutional styles available for quite some time to come.

Maybe ... but for all practical purposes, you can do what benjohn
describes on the Internet. That's why I spend so much time here.

I do that as well, and rather enjoy it -- though it's a skill in itself,
and there aren't really "consultants" to handle it for you.

 

[Jochen Theodorou]

Austin Ziegler schrieb:
[...]

Please, please, *please* read more about relational theory before you
make statements like this, because it's technical nonsense. There *is*
no "object model."

of course there is none as you define it. Who said I am using the same
definition? Is your definition a common definition for "model" in
general? If so please point me to a reference. I don't know all the
correct UK/US terms used for this.

Part of the problem, of course, is that a lot of terms are used and
reused imprecisely.

1. The Relational Model of Data is the combination of set theory and
relational algebra. There is no corresponding theory or mathematical
basis for object orientation. That is, there's no "Object Orientation
Model of Data".

never said something different, or?

Object orientation is, in fact, an implementation technique -- a
refinement of procedural programming that more tightly ties data with
operations related to that data.

I usually define what should be done and how to change the state, yes.
How is that related to the problem?

That's an important point, too:
object orientation is about *programming*. It is not about data and
the storage of data.

I agree partially. It is a data structure, it is not more about
programming as a binary tree is. So it is about structuring your data to
fit your needs of computation... but that fits so much that is a useless
statement

2. When *implementing* something, you will model the data. This can be
your data model that can be extended into an object model for
programming purposes. These "models" are better considered "schema";
they describe the layout of the data.

What you want to say is, that a schema is no model? Or at last not all
schemata are models. I think.. I am not sure yet

Just because one *can* create something that works without a
mathematical theory behind it does not mean that one *should* do so.

or should not do so.

One
certainly shouldn't claim that the thing without a mathematical theory
behind it is superior to the thing with -- because that's something you
should be able to demonstrate with, well, another theory. Performance
metrics are not evidence of superiority of concept; just of
implementation.

I have never done that. So I guess you don't mean me, because I am well
aware of the problems of OODBs

There are no OODB mathematics, and that's part of the point that I've
been trying to make.

ah, yes, ok.

If you can point to OODB mathematics papers and
theories, I'll retract or clarify that statement, but I have a
reasonably high level of confidence that object orientation isn't
expressed in terms of mathematics or theory the way that the relational
model is.

ok, see "A Query Algebra for Object-Oriented Databases (1989)" on
citeseer http://citeseer.ist.psu.edu/shaw89query.html

Found after searching 2 minutes in google. And 1989 isn't very new. The
papers citing that paper are also quite interesting.

The nice thing in mathematics is, that I can use it to define very much
things... even if they are useless in the end. I guess you should give
more constraints.

Sure, an object store can be set up to allow for smart loading and such,
but that *doesn't* mean that it's a good idea. It might be the "right
now" idea, but it is something you'll have to pay the piper for using at
some point in the future.

depends on my goals, or not?

bye blackdrag

 

[Austin Ziegler]

Yet. That you know of. Yet.

Fair enough.

Seriously, the folks in the UK that developed the PI-Calculus have done
some work in computer-science models of objects, but I don't know enough
about them to know if they're relevant to this discussion. The one
reference I have is on the edge of my readability scale -- if I sat down
with the book and the right programming language, I might be able to
learn it, but there are other things I'm more interested in doing.

Do you have a pointer to an abstract?

-austin

 

[Austin Ziegler]

Austin Ziegler schrieb:
[...]

Please, please, *please* read more about relational theory before you
make statements like this, because it's technical nonsense. There *is*
no "object model."

of course there is none as you define it. Who said I am using the same
definition? Is your definition a common definition for "model" in
general? If so please point me to a reference. I don't know all the
correct UK/US terms used for this.

Like I said, "model" is a vague word. When you say "relational model",
the *meaning* is the "Relational Model of Data" (e.g., the theory). At
this point, there's nothing related for an "Object Model of Data".

When one says "object model", one usually means "the hierarchy or
graph of objects that I am using to represent the data and operations
in my implementation." In relational terms, that is a schema.

So, "relational model" and "object model" are two *totally* different
things as they are typically understood as one deals with a concept
and the other deals with a single implementation.

I agree partially. It is a data structure, it is not more about
programming as a binary tree is. So it is about structuring your data to
fit your needs of computation... but that fits so much that is a useless
statement

The classic definition of an object is data and the operations that
apply to that data encapsulated in one. I am sure that there are
definitions of OO out there where encapsulation isn't part of it, but
I consider encapsulation probably the defining feature of OO (even
more than inheritance, because there are strong arguments for
composition instead). That's a whole different argument, though, and
most OO systems these days accept encapsulation, inheritance,
polymorphism, and (often) access control (information hiding).

What you want to say is, that a schema is no model? Or at last not all
schemata are models. I think.. I am not sure yet

Just the opposite. An object model is closely related to a data model
(or a database schema, if you prefer). There's no overarching theory
of object modelling (at least not yet, as Ed pointed out), whereas
there *is* an overarching theory of data and relations.

or should not do so.

Fair enough, but if one chooses to step away from something that has
theoretical underpinnings, one should at least be prepared to make a
coherent explanation as to why it's better. Otherwise, you're not
doing much better than selling snake oil. I'm sure you've seen
programs by vendors that claim to have better-than-AES encryption
available that absolutely no one in the security industry has
reviewed. Why do we as technical people scoff at them yet swallow the
claims of other vendors (like the OODB or "Post-Relational" folks)
without even thinking?

I have never done that. So I guess you don't mean me, because I am well
aware of the problems of OODBs

I wasn't referring to you specifically; I was more referring to the
OODB vendors, who have no excuse for their specious claims.

ok, see "A Query Algebra for Object-Oriented Databases (1989)" on
citeseer http://citeseer.ist.psu.edu/shaw89query.html

I skimmed through this; reading it, it's an attempt to *return* some
level of relational algebra to object databases ... all the way back
in 1989. Sadly, the authors still think that first normal form is an
unnecessary restriction on the logical formation of the data -- and
they have to synthesize first normal form tuples to obtain relational
algebra capabilities in object databases.

I haven't looked further, but it's not quite a positive refutation of
my statement.

depends on my goals, or not?

I've said as much. Right now solutions usually meet one's immediate
goals, but rarely meet long-term goals and often result in increased
costs in the long-term.

-austin

 

[Mauricio Fernandez]

Yet. That you know of. Yet.

Seriously, the folks in the UK that developed the PI-Calculus have done
some work in computer-science models of objects, but I don't know enough
about them to know if they're relevant to this discussion. The one
reference I have is on the edge of my readability scale -- if I sat down
with the book and the right programming language, I might be able to
learn it, but there are other things I'm more interested in doing.

Are you referring to Abadi and Cardelli's object calculi? They don't seem any
more related to OODBs than say lambda calculus to the relational model, but
you can indeed consider them "object models", that term being as ambiguous as
it is

FWIW, http://lucacardelli.name/TheoryOfObjects.html
http://citeseer.ist.psu.edu/abadi94theory.html

--
Mauricio Fernandez - http://eigenclass.org - singular Ruby
** Latest postings **
The Neo-Rails controversy and a language generator
http://eigenclass.org/hiki/language-generator
Rails on 1.9: first benchmarks, YARV exposed to non-synthetic tests
http://eigenclass.org/hiki/non-synthetic-benchmarks-for-yarv

 

[Jochen Theodorou]

Austin Ziegler schrieb:
[...]

Please, please, *please* read more about relational theory before you
make statements like this, because it's technical nonsense. There *is*
no "object model."

of course there is none as you define it. Who said I am using the same
definition? Is your definition a common definition for "model" in
general? If so please point me to a reference. I don't know all the
correct UK/US terms used for this.

Like I said, "model" is a vague word. When you say "relational model",
the *meaning* is the "Relational Model of Data" (e.g., the theory). At
this point, there's nothing related for an "Object Model of Data".

but the relational algebra is about queries not data in the first place.

When one says "object model", one usually means "the hierarchy or
graph of objects that I am using to represent the data and operations
in my implementation." In relational terms, that is a schema.

the operations are part of the schema?

So, "relational model" and "object model" are two *totally* different
things as they are typically understood as one deals with a concept
and the other deals with a single implementation.

sorry I don't agree with you here. not with the word implementation. I
see them as orthogonal.

The classic definition of an object is data and the operations that
apply to that data encapsulated in one. I am sure that there are
definitions of OO out there where encapsulation isn't part of it,

from the view of data the operations are not relevant, or not? I mean
unless you make them part of the algebra... I think I have seen that
somewhere.. ah, not sure where, sorry

but
I consider encapsulation probably the defining feature of OO (even
more than inheritance, because there are strong arguments for
composition instead).

encapsulation in terms of grouping data together? hat is not more a
definition as a table is.

That's a whole different argument, though, and
most OO systems these days accept encapsulation, inheritance,
polymorphism, and (often) access control (information hiding).
right.


Just the opposite. An object model is closely related to a data model
(or a database schema, if you prefer). There's no overarching theory
of object modelling (at least not yet, as Ed pointed out), whereas
there *is* an overarching theory of data and relations.

data *and* relations, yes. A theory about data only would be useless, or
not?

Fair enough, but if one chooses to step away from something that has
theoretical underpinnings, one should at least be prepared to make a
coherent explanation as to why it's better.

coherent? "My tests are showing my application is faster with it" or "I
am faster in prototyping" is for some cases coherent enough.

[...]

I wasn't referring to you specifically; I was more referring to the
OODB vendors, who have no excuse for their specious claims.

and you are not referring to a specific OODB vendor either... just to a
blurred mass of unknown people. Don't mix the vendor with salesman. Some
are, but not all.

[...]

I skimmed through this; reading it, it's an attempt to *return* some
level of relational algebra to object databases ... all the way back
in 1989.

please read it again. there is no such thing as "returning" there is
only a thing of mapping one concept to another. Something like a morphism.

Sadly, the authors still think that first normal form is an
unnecessary restriction on the logical formation of the data -- and
they have to synthesize first normal form tuples to obtain relational
algebra capabilities in object databases.

where?

I have read: "One research direction in the modeling of object-oriented
is the extension of the relational model to build complex types. Early
extensions relaxed the first normal form requirement of the relational
model to allow set valued attributes.

I haven't looked further, but it's not quite a positive refutation of
my statement.

you claimed there is no algebra, I proved you wrong. I myself said there
is much space for nonsense and that without constraints there will never
be a "solution". So either we talk about such constraints or we end the
topic. It makes no use to give more and more new papers just that you
can say that you don't like the opinion of the author."

I guess you mean a different part?

I've said as much. Right now solutions usually meet one's immediate
goals, but rarely meet long-term goals and often result in increased
costs in the long-term.

might be true, but if your boss says that he needs to save money in the
short term it is a different thing. For example for prototypes, for
example for small applications, for example for applications that don't
share data, for example for applications without the need to do reporting.

bye blackdrag

 

[Austin Ziegler]

but the relational algebra is about queries not data in the first
place.

The Relational Model of Data is about how to organise the data in such a
way that relational algebra is able to work. So your statement isn't
really correct. Relational algebra doesn't work without the organisation
of the data into sets of tuples and attributes.

the operations are part of the schema?

Are you not understanding what I'm saying? I'm making an analogy here,
not a direct correspondence. What people call an "object model" is
similar to a relational schema. When I do my object models, I *start*
with how I need to model my data; then and only then do I start
considering my operations. (I will, of course, have considered the
"pipeline" for processing the data related to the purpose of the program
I'm working on.)

sorry I don't agree with you here. not with the word implementation. I
see them as orthogonal.

They're not orthogonal, really. A database schema and an object model
are orthogonal, but one deals with a higher level concept than the
other.

from the view of data the operations are not relevant, or not? I mean
unless you make them part of the algebra... I think I have seen that
somewhere.. ah, not sure where, sorry

I'd be considered an object apostate by some of the more vehement OOists
out there, mostly because I think that data is far more important than
operations involved and that I consider it a refinement of procedural
programming. Encapsulation is the only thing that seems to be *common*
among the various OO systems I've seen, but I've seen C code that I
would consider programmed in an OO-style even though there's no
encapsulation (as such) in C.

encapsulation in terms of grouping data together? hat is not more a
definition as a table is.

I can't parse this; encapsulation is, as I understand it, combining data
and operations.

Not at all. I think I've explained it above, but if you still don't
understand, please ask.

data *and* relations, yes. A theory about data only would be useless,
or not?

This is basic relational theory; please read more on it.

coherent? "My tests are showing my application is faster with it" or "I
am faster in prototyping" is for some cases coherent enough.

Not at all. Performance is about implementations, not about concepts.

[...]

I wasn't referring to you specifically; I was more referring to the
OODB vendors, who have no excuse for their specious claims.

and you are not referring to a specific OODB vendor either... just to a
blurred mass of unknown people. Don't mix the vendor with salesman. Some
are, but not all.

OO database vendors *as a class* make specious claims, usually about
being "post-relational" and not having coherent explanations for why
abandoning first normal form is a good idea. They can't explain it, so
they have to hype up things to distract others.

[...]

I skimmed through this; reading it, it's an attempt to *return* some
level of relational algebra to object databases ... all the way back
in 1989.

please read it again. there is no such thing as "returning" there is
only a thing of mapping one concept to another. Something like a
morphism.

No, it's "returning." I read it thoroughly enough to see that they were
trying to add some level of relational algebra *back* to object
databases because what was happening in object databases was simply not
good enough.

The authors weren't quite clear enough on the concepts (despite having
clearly read C.J. Date, as referenced in the paper) to admit this,
though.

where?

I have read: "One research direction in the modeling of
object-oriented is the extension of the relational model to build
complex types. Early extensions relaxed the first normal form
requirement of the relational model to allow set valued attributes.

They don't condemn this; first normal form is something that really
makes a lot of sense in data and object modelling. They have to
*synthesize* a first-normal form for their relational algebra to even
*work*!

you claimed there is no algebra, I proved you wrong. I myself said
there is much space for nonsense and that without constraints there
will never be a "solution". So either we talk about such constraints
or we end the topic. It makes no use to give more and more new papers
just that you can say that you don't like the opinion of the author."

I guess you mean a different part?

They added relational algebra to an object database model by
synthesizing a tuple for relational operations. That's an utter failure
to provide an object algebra. Read the paper again: they *clearly* say
they synthesize tuples to layer relational algebra on top of object
databases.

It's not a matter of disagreeing with the authors, it's a matter of
recognising that the paper doesn't really do what you think it does.

might be true, but if your boss says that he needs to save money in
the short term it is a different thing. For example for prototypes,
for example for small applications, for example for applications that
don't share data, for example for applications without the need to do
reporting.

All of these will benefit more from relational databases than object
databases. If they're *that* small, just use a plain-old object store
(like PStore or Madeleine, if you must); don't bother with an object
database -- because you'll spend almost as much time in the short term,
and much more time in the long term, with that as you would with a good
ORM and a good SQL database.

-austin

 

[M. Edward (Ed) Borasky]

Are you referring to Abadi and Cardelli's object calculi? They don't seem any
more related to OODBs than say lambda calculus to the relational model, but
you can indeed consider them "object models", that term being as ambiguous as
it is

FWIW, http://lucacardelli.name/TheoryOfObjects.html
http://citeseer.ist.psu.edu/abadi94theory.html

I knew *someone* would send me into the library.

Sangiorgi and Walker, _The Pi-Calculus: A Theory of Mobile Processes_,
Part VII (Objects and PI-Calculus)

It's on my to-read list. Pity the Summer of Code deadline has passed, eh?

 

[M. Edward (Ed) Borasky]

Fair enough.


Do you have a pointer to an abstract?

-austin

Sangiorgi and Walker, _The Pi-Calculus: A Theory of Mobile Processes_,
Part VII (Objects and PI-Calculus)

This is a book ... a big book with lots of abstract computer science in
it. The stuff I read for relaxation, because, well, mysteries and
Westerns bore me.

 

[Jochen Theodorou]

The Relational Model of Data is about how to organise the data in such a
way that relational algebra is able to work. So your statement isn't
really correct. Relational algebra doesn't work without the organisation
of the data into sets of tuples and attributes.

very right, it is not only the data, it is its organization and the
relations between them too. Might be that data is king, but only after
it is transformed with respect to the relational model.

Are you not understanding what I'm saying? I'm making an analogy here,
not a direct correspondence.

then why did you mention the operations at all?

What people call an "object model" is similar to a relational schema.

ah, well I used the term different. I used it in the term of... how
objects are related, behave and what operations can be done with them.

[...]

I can't parse this; encapsulation is, as I understand it, combining data
and operations.

that's how OO defines encapsulation, that is not how encapsulation
defines OO. At last that is my view on this.

[...]

This is basic relational theory; please read more on it.

that misses the point. I wanted to say, if you look at the OO world
without the same relations you use in the relational world, then what is
it worth? I mean if you take an object and rip off the methods, what is
left then? A mere data holder, a abstract type. Or not?

Not at all. Performance is about implementations, not about concepts.

If something proves to be better for a certain situation in a pragmatic
way, then I should really consider to use that.

[...]

OO database vendors *as a class* make specious claims,

"as a class"... a class without instances? A singleton then maybe.
Maybe even a non existing. Sorry, I am no friend of putting a vague
group people together and claiming that they are doing something bad.

[...]

No, it's "returning."

that's no base for discussion. returning or not does not matter.

I read it thoroughly enough to see that they were
trying to add some level of relational algebra *back* to object
databases because what was happening in object databases was simply not
good enough.

your view.

The authors weren't quite clear enough on the concepts (despite having
clearly read C.J. Date, as referenced in the paper) to admit this,
though.

what concepts? You are not very clear yourself. Basically you are saying
they have not understood the relational model and OO altogether. I guess
they are also of your class of OO database vendors.

They don't condemn this; first normal form is something that really
makes a lot of sense in data and object modelling. They have to
*synthesize* a first-normal form for their relational algebra to even
*work*!

extend is not really synthesize. And what exactly is so bad about that?
It is a common thing in mathematics.

They added relational algebra to an object database model by
synthesizing a tuple for relational operations. That's an utter failure
to provide an object algebra.

why? A detailed explanation please.

Read the paper again: they *clearly* say
they synthesize tuples to layer relational algebra on top of object
databases.

It's not a matter of disagreeing with the authors, it's a matter of
recognising that the paper doesn't really do what you think it does.

and what do you think that I think it does? That I can't use the
relational algebra as it is for an object algebra was clear from the
beginning. But that is not important here. The important thing is how a
modification I make affects the system as a whole. If it does not
violate other mathematic axioms then it is normally a valid model.

All of these will benefit more from relational databases than object
databases.

In what way? Don't come with "in the long term", mantras don't make up
for reasons.

If they're *that* small, just use a plain-old object store
(like PStore or Madeleine, if you must);

small in lines of code possibly yes, that does not mean it does not have
to query or has to handle data bigger than the available memory

don't bother with an object database

what bother? Depends on the database, or not?

-- because you'll spend almost as much time in the short term,
and much more time in the long term, with that as you would with a good
ORM and a good SQL database.

at the moment I can't say that this is true. Maybe the solutions of ORM
are quite good, but if you take a look in the Java world.. I really
prefer db4o over Hibernate+HSQLDB or even postgres/mysql/oracle/xy if my
application is "small".

bye blackdrag

 

[Sebastian Hanigk]

combining it with a view is surely a good idea. It makes the queries
more easy. I don't want to say it is different, it is just not as nice
as with normal tables.

The point is not that a view simplifies a query over a given inheritance
relation, a view is the table model implementation of ER-inheritance.

In general - and I have sometimes learned it the hard way - you have to
be very careful about what model one is talking: usually the highest
level is the ER model which will be implemented as a relational model
that will be (or can be) normalised and at last this relational model
will be implemented as a table model.

I don't agree with austin and the resulting ugly class hierarchy is
prove enough for me. Not in all cases of course

Ah, I think I have been misunderstood: ugly object models are mostly
produced by »software engineers« who have no knowledge about the
fundamentals of ER modeling.

Why not consider OODB mathematics as part of graph theory and others?

There is no such thing as OODB mathematics in a usable, formal sense.


Bye!

Sebastian

 

[Jochen Theodorou]

Sebastian Hanigk schrieb:
[...]

Ah, I think I have been misunderstood: ugly object models are mostly
produced by »software engineers« who have no knowledge about the
fundamentals of ER modeling.

ER modeling is good when you want to store your objects in a database in
the end, but that's all. Nearly any other more formal design method is
as good as ER.

There is no such thing as OODB mathematics in a usable, formal sense.

If I extend the relational algebra for the OO world and if I define all
the basic functions the relational algebra does have, then I get a
usable and formal expression. But not all that is usable for a
mathematician is usable for real life.

bye blackdrag