Sebastian Hanigk schrieb:
> Jochen Theodorou <blackdrag / uni.de> 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.

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.

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

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

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

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.

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

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