Re: OODBMS Furue or Not ?

#11

Guillermo Schwarz wrote:

Quote:

"Lee Fesperman" <firstsql (AT) ix (DOT) netcom.com> escribió en el mensaje
news:3F399B2D.447B (AT) ix (DOT) netcom.com..

SELECT shape FROM shape_table WHERE shape.getArea() < 100;

And we could create ShapeList extending Shape, so that complex
structures could be accessed using the same queries.

That's the point of the previous paragraph -- "The value of an
object column can be an instance of its defined class or one
of its subclasses."

Yes, in an OO model that's true. That's is not the case though in the
relational model. A triangle, a square and a circle would be stored in
different tables, not in the same table as in a OO database.

In a relational database, I can define a shape domain whose values are -- triangles,
squares and cicles. The shape values can reside in a single column of a single table.

Quote:

Complex relationships can be stored in object columns, but we
encourage the use of relational facilities for modeling complex
relationships. As OODBMS proponents have discovered, accessing
complex relationships using object structures is too difficult.

So we need O/R mapping anyway, right.

Yes, you often would. However, an ORDBMS provides 'native' mapping
capabilities. See my article on byte.com --
http://www.byte.com/documents/byt1043081505209/ (it's free, but
you have to register).

It asked me to register and it was not free, therefore I couldn't read it.

I do apologize; byte.com has changed its policies. It's available free in PDF at
http://www.firstsql.com/NativeWrappersA.pdf.

Quote:

The fact that you need mapping means that individual fields in a class must
be mapped to fields in a table. But a field in a class may dynamically refer
to different classes in an object model, that is not the case in the
relational model.

Relational domains can support inheritance. A column in a table can be defined on a
domain. The values for such a domain can be from the declared type of from a derived
sub-type.

Quote:

You are misinformed in stating that RDBMSs can't adequately model
complex relationships. This is where the relational model excels.

RDBMSs can model complez relationships as long as the reference
from one table to the other is fixed. If you want to model the
shape hierarchy the RDBMS model becomes messy, IMHO.

I just modelled that using a relational domain. How is that messy?

Can you show us the resulting model?

The shape domain is defined in the database. The values for the shape domain can be a
triangle, square, circle, etc., which are sub-types of the shape type.

In FirstSQL/J, the shape domain and its sub-types are implemented with Java classes
cataloged in the database with the CREATE CLASS command.

Quote:

Relationships do not have to be fixed in relational. An RDBMS is
uniquely capable of handling dynamic relationships.

Can you show us some example?

A simple one:

The database has two tables --- suppliers and customers. Each table has a city column.

I can create a dynamic (ad-hoc) relationship between the two tables based on values in
the city columns.

Quote:

It's the OO
model that tends to be inflexible and overly complex (messy).

The OO model has a bunch of ways of handling relationships --
is-a, has-a and various ad-hoc techniques with only vague
guidelines as to which to use. This is complex and rigid.
You also have to worry about direction in relationships.

The relational model does not have direction in relationships?

In relational, all relationships are bi-directional. Direction is not an issue.

Quote:

The relational model has exactly one way to represent relationships ---
as values in tables (actually, in relations). Blindly simple and
powerful at the same time.

That's why versioning is so crucial in OO designs. You never have
a clue whether you did it right.

Do you mean you never change your relational database model? Once done it is
cast in stone?

That is not what I meant. If you understand your data and its relationships, you can
create a normalized structure with constraints that properly represents your information
and is flexible in the face of future changes. OO concepts provide no way to determine
if your design is proper ... thus you must determine it through experiments.

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: OODBMS Furue or Not ?

comp.databases.object comp.databases.object

Re: OODBMS Furue or Not ? - 09-04-2003 , 01:11 AM