[
Lists Home |
Date Index |
Thread Index
]
Bullard, Claude L (Len) <len.bullard@intergraph.com> asks:
> Off topic, but since data warehousing comes up from
> time to time: what is the advantage of using
> an OLAP design vs a relational design? Is this
> advantage better or worse than a triple design?
>
Now you've done it, you've gone and imported a perm thread from the
database world into xml-dev...
With the exception of the specialized spatial, null compressed, database
designs, for the most part, OLAP designs are relational designs just
highly denormalized. I can't really see a significant relationship to
triple stores. Your prototypical warehouse "star" schema puts a single
large table at the center of a bunch of smaller tables (snowflake
schemas normalize a bit). Most of the many to many relationships are
denormalized. Relationships are hard coded in the center tables and your
standard relationship traversal goes away (that's the whole point, avoid
join processing costs at the cost of higher storage utilization).
Now you could just plop an entire triple store into a single table but I
can't see how that approach would work at all, all relationships would
be via procedural value look up and comparison. To put it another way,
triples are all about relationship management as opposed to value
management which is what a data warehouse schema is for.
Having said that I'll note that if you go to 5th normal form you end up
with a sort of inverted star; tiny little tables connected to a bunch of
larger tables. This is because you've used a single table (with
possibly a single column) to normalize out a bunch of relationships.
This pattern does have something to do with triple stores (since that's
what we're using it for). Given my statements above I'd guess it has
something to do with ending up with a single key for relationship
traversal across multiple dimensions/perspectives and thus being able to
annotate the relationships. I'd postulate that there are some formal
properties shared between graphs and 5th normal form databases.
|
