The Myth of relational algebra (was Re: Clean Object Class Design -- What is it?)
Date: Fri, 7 Sep 2001 11:52:22 +0200
"Bob Badour" <bbadour_at_golden.net> schrieb im Newsbeitrag
> Please show me a complex system so complex that it has an integrity
> constraint one cannot declare with a well-formed-formula.
There is an easy and complex answer to this:
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.
class cd < media
class book < media
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"
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"
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:
media: reference to class media
collection of stock_media
In an RDMS we could transform this into:
create table stock (
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
- You can transform any object hierarchy to a flat structure and some integrity constraints
- You can translate a collection of objects into a table with 1:n relation
- You can translate a reference into a 1:1 relation
- The design with an OODB is much easier and more logical
- In an OODB you need far less constraints, because they will be fulfilled automatically .
- 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
I prefer to define multiple inheritance with the help of interfaces andinterface 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.
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)
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.deReceived on Fri Sep 07 2001 - 11:52:22 CEST