On 3/20/07, Demetrius Gallitzin <gallitzin / gmail.com> wrote:
> 1) Enterprise integration.  Trying to put two relational database
> applications together costs as much effort as building one relational
> database application.   This falls under the work of William McCarthy
> (Ph.D.), REA modeling, and Pavel Hruby (Ph.D) pattern-based enterprise
> structures {now sold to Microsoft}.  Putting data into normalized form
> seems to put things into unique patterns that are painful to integrate
> (with someone else's project).  I look at two ERD diagrams for two
> applications, and then I'm told to make them work nicely together.

Then you're integrating them wrong. If you can't integrate two
databases, integrate two applications through application interfaces.
See the writings of Fowler and, to some degree, of DHH. Sometimes it's
useful to even take an approach where a "third" application is created
(single sign-on, for example). This is not something that is helped
*in the least* with OO databases. Repeat after me: OO databases aren't
a solution to anything but a single problem.

> 2) Business Analysis (OLAP and Data Mining)  -- Decision support is
> interested in analyzing rather than processing data. Normalized data,
> to me, seems all about processing data.  As the purpose of data
> analysis is to examine and uncover the redundancies in data, the
> uniqueness constraints placed on the relational model by the
> normalization process are not desirable for decision support (Roiger
> and Michael Geatz, _Data Mining: A Tutorial-Based Primer_ 2003, page
> 182). To me, it means that transaction databases in normalized form
> aren't structured well for OLAP or Data Mining type functions.

Again, your understanding is wrong. Normalized data is about data
representation. There's *nothing* wrong with the relational model for
decision support or business analysis. There may be problems with the
implementations of SQL databases, but set operations still apply to
business analysis -- and OO databases *still* hurt here because
they're only capable of asking a single question. DSS is all about
asking *lots* of questions in *lots* of different ways to uncover yet
other questions.

> When you have business models and you're forced to think in terms of
> Codd's normalized form, it seems to kill the agile environment.  I
> think in business terms, and then have to restructure the data into
> something foreign to the business....and a layer of maintainability
> and complexity above the business itself?

I think that's a lack of imagination. When I was doing significant
database work, I also thought in business terms. The team that had the
problems with their database were the fools who thought that the
database could be modelled based on the object model. They didn't
think beyond their UI object model, which wasn't the *only* model
necessary in the application (it was a billing application).

> Even if OO databases are flawed, I'd rather be able to think OO, store
> OO, and model things as OO.  Yeah, maybe a Smalltalk guy can help. :)

OO databases aren't flawed. They're disastrous.

-austin
-- 
Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/
               * austin / halostatue.ca * http://www.halostatue.ca/feed/
               * austin / zieglers.ca