The Myth of relational algebra (was Re: Clean Object Class Design -- What is it?)

"Bob Badour" <bbadour_at_golden.net> schrieb im Newsbeitrag news:v2Vk7.768$LE3.134318184_at_radon.golden.net...

>

There is an easy and complex answer to this:

easy answer:

If relational algebra is that powerful, that you can declare any possible integrity constraint, why is it not possible to have relational integrity in an OODB ?

solution a: relational algebra can describe anything - than it is possible to have relational integrity in an OODB
solution b: relational algebra cannot describe the relations in an OODB - than we need a more powerful concept.

complex answer:

I believe, that relational algebra works also in a proper defined OODB.

If we look a typical object hierarchy:

class media

    title: string
end

class cd < media

    number_of_songs: integer
end

class book < media

    number_of_pages: integer
end

one possibility to implement this hierarchy in an RDMS is to flatten out the hierarchy (Not very effective, but possible)

create table media (

    obj_id integer, // a unique id to identify the object     hierarchy varchar(20), // objects of class media have hierarchy "0", child objects have "0-1" .. "0-n"

    // objects of class cd have hierarchy "0-1", child objects have "0-1-1" .. "0-1-n"

    // objects of class book have hierarchy "0-2", child objects have "0-2-1" .. "0-2-n"

    title char(20),
    cd_number_of_songs integer,
    book_number_of_pages integer
)
to ensure structural integrity you can have these constraints:

    cd_number_of_songs must be null if hierarchy does not start with "0-1"     book_number_of_pages must be null if hierarchy does not start with "0-2"

Now lets look at some relations:

class stock_media

    media: reference to class media
    items_on_stock: integer
    item_in_shelf: integer
end

class stock

    collection of stock_media
end

In an RDMS we could transform this into:

create table stock (

    obj_id integer,
    hierarchy varchar(20),
    media_id integer,
    items_on_stock integer
    item_in_shelf integer
)

some integrity constraints could be:

    media_id must exists in obj_id of table media     if a record in media is deleted all records in table stock with media_id = obj_id must be deleted as well

What does this example show:

1. You can transform any object hierarchy to a flat structure and some integrity constraints
2. You can translate a collection of objects into a table with 1:n relation
3. You can translate a reference into a 1:1 relation
4. The design with an OODB is much easier and more logical
5. In an OODB you need far less constraints, because they will be fulfilled automatically .
6. Not shown but obvious: Queries are much easier to formulate in an OODB, than in a RDBMS 7....100: OODB rules! :-)

and finally. Of course is it possible to define relational constraints in an OODB. But most of the constraints are implemented automatically and you don't have to formulate all these things over and over again.

What about multiple inheritance ?

I prefer to define multiple inheritance with the help of interfaces and interface delegation. In this way, multiple inheritance does not change the structure of the object hierarchy.

Another myth states, that RDBMS are much more effective and quicker than an OODB. Often this myth is explained with relational algebra and the possibility to optimize queries in an RDBMS.

As with all myths, there is true part:
Relational algebra gives you the possibility to transform a query in order to optimize it.

Wrong is:
1. That all optimizations of a query are done with relational algebra. The most common optimization is to use an index. Relational algebra is used to transform the query to use the index. But the index in itself is not defined by relational algebra. (Since an index is normally a tree-structure, it has more in common with an OODB if you want)

But:
2. You can use these techniques with an OODB as well. 3. An OODB has build in optimizations like references (a controlled shortcut for a 1:1 relation). Or collections as controlled shortcuts for joins and 1:n relations.
4. An OODB can outperform an RDMS.

--
Adrian Veith,
Veith System GmbH.
www.db-gonzales.de