"Austin Ziegler" <halostatue / gmail.com> writes:

>>> Sadly, the authors still think that first normal form is an
>>> unnecessary restriction on the logical formation of the data -- and
>>> they have to synthesize first normal form tuples to obtain relational
>>> algebra capabilities in object databases.
>> where?
>>
>> I have read: "One research direction in the modeling of
>> object-oriented is the extension of the relational model to build
>> complex types. Early extensions relaxed the first normal form
>> requirement of the relational model to allow set valued attributes.
>
> 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*!

Interestingly, it can be shown that the Relational Model still is
perfectly sound even if you remove the first normal-form (as opposed
to all higher normal forms).

> All of these will benefit more from relational databases than object
> databases. If they're *that* small, just use a plain-old object store
> (like PStore or Madeleine, if you must); don't bother with an object
> database -- 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.

The real problem IMO is not that we need a "OODB" or an object
calculus (which would not be very hard to construct, there are lots of
them out there; but they are hardly useful for expressing database
operations).  It's clear to me that a good datastore will be based on
the relational model.

The real problem is it's implementation at the moment, which
constrains the developers a lot.  I argue that the following features
would take a big deal of the pain usually connected with ORM without
changing the validity of the Relational Model.

* Dynamically, strongly typed values.  (Types can be enforced (or even
  ducktyped!) by help of constraints.)

* Dynamically defined relvars.

* Dynamic fields.  (This is, in the end, dynamic relvars and DKNF).

The problem is not the Relational Model, but the current
implementations of it: they live in a world that's very different from
the one of a Ruby program.  Still, I argue that all three above
features are consistent with the Relational Model.

That said, I honestly have no idea how to implement all this
efficiently.  :-(

> -austin
-- 
Christian Neukirchen  <chneukirchen / gmail.com>  http://chneukirchen.org