Austin Z. schrieb:
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.
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?
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.
[…]
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.
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.
[…]
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?
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?
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.
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.
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.
[…]
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.
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.”
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.
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.
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
