I am creating a small (<100,000 transactions) data warehouse for trending that requires many lookup tables for select criteria in queries.
I’ve identified about 5 dimensions for the fact table, but my problem is that each transaction may require up to 20 different criteria (with lookup descriptions). The transaction dimension and the fact table both represent a specific transaction. My question is, how do I represent the 20 lookup descriptions per transaction? Should I keep this info in the dimension (repeated across all transactions), snowflake the lookups from the dimension, or just normalize the entire database?
Yes, Business Objects will “support” all three solutions. Normalizing the actual/physical data model would be the worst choice for any reporting solution including a Business Objects implementation. Normalizing eliminates redundant data thereby avoiding the problem of synchronizing insert/update/delete operations across multiple tables, but makes it hard to query the data for reports.
Reporting on transactional 3nf databases is slow.
Snow flakes are OK as long as the tables that join to the dimensions (that are joined to your fact) are low cardinality as this does not affect performance too much.
In my opinion you will get the best performance from a well designed star schema though…
I believe 100,000 is probably the max this reporting system will go in the next several years.
We do not need to change history in this data, but open status transactions will be updated in place. Maybe this is a reason enough to just carry the 20+ codes/descriptions in the transaction dimension? This is my first experience with de-normalizing data to this extreme and I’m struggling with it.