Database Theory Links

[Tom Novelli]

Kyle Lahnakoski <kyle@arcavia.com> wrote:
>
> Massimo Dentico wrote:
> 
> > 
> > - ftp://ftp.netcom.com/pub/hb/hbaker/letters/CACM-RelationalDatabases.html
> > 
> > In my experience he is right. However, even OODBMS are not the ultimate
> > solution, at least in the current state.
> 
> I will agree that no all data can be effectively represented in a
> database.  I found the theory excellent starting point for defining,
> what I call, "set operations".  There are currently * basic DB operators
> (depending on who you talk to) select, filter, join, aggregation, union,
> intersection, difference, and cartesian product.  I am trying to write a
> document on a ninth DB operator: the "Self Join"; it will complete much
> of DB theory's shortcomings (but still not a holy grail).

Self Join... do you mean a simple way to nest subassemblies to an
arbitrary level, rather than an explicit join for each level?  That would
certainly help.

Still, the theory is fundamentally flawed.  It's based on index cards,
where items are referenced by some "key" (e.g., catalog number).  When the
US military started building computers, they just used them to automate
centuries-old logistics practices.  They accumulated piles of
punch-cards.  Relational database theory offered a way to keep that data
consistent... and 30 years later they adopted it.

Meanwhile, other people were taking advantage of the computer's
capabilities -- especially in graphics and game programs.  Many games do
in real-time what relational databases take minutes or hours to do.
Imagine running queries 30 times per second in a flight simulator.. :)

Summary: Typical data structures have a _fixed_ relationship.  Relational
theory generalizes to allow arbitrary joins, but in practice these are
mainly used to recreate the fixed relationship which already exists in a
non-relational database.

Tom Novelli