Hello,

A couple of data warehouse tools support analysis with snowflake
schemas very well. A lot of data structures can not be organized into a
system with a central fact table because several n:m relationships
exist between the entities.
Are there any improvements for multidimensional reports from such data
networks in the software development?

Regards,
Markus

Hi Markus,

In a dimensionally-modeled RDBMS schema, a helper table or bridge table
is used to resolve n:m relationships between dimensions.

The basic idea is that between two dimensions that have a n:m
relationship, there should be a bridge or intersection table whose sole
purpose is to provide foreign keys to each of the tables. Of course,
aggregation is then no longer a simple issue as it is in a simple star
schema, because the n:m relationship causes dramatic overcounting.
This must then be resolved by prorating the dimensional elements so
that when they role up they add up to whole numbers of fact entities.

Ralph Kimball has an excellent article on this topic here:
http://www.intelligententerprise.com...house1_1.jhtml

Good Luck,

Nenshad

Are any approaches recommended to exclude with any calculations such
overcounting?


This description "Managing Helper Tables" does not fit to the use case
I imagine. I get the impression that there are explanations missing
that can be expected after the subtitle "A careful look at many-to-many
relationships between important dimensions".

I am looking for experiences about multiple fact tables in a single
data warehouse project. The available facts depend on the
dimensionality.
How do you think about a kind of network model to navigate through the
database?
Can the constraints be detected that result into a logical data model
that is not only a consistent hierarchy?
Do you cooperate with "multi-info providers" like they are called in
the SAP Business Warehouse?

Regards,
Markus

The analysis of records from ticket tracking systems like Bugzilla is a
concrete example for an application with several n:m (many-to-many)
relationships.
1. Persons like customers enter some requests.
2. Further comments and documents from various authors can be added to
a request.
3. Each request and document can be categorized with specific key
words. (=> taxonomy, ontology)

Which design approaches do you recommend for a mapping to data
warehouse tools?
Would you like to share your experiences about reporting from such
models?

Regards,
Markus

Did you apply anything from the Common Warehouse Metamodel for the
desired use case (m:n / many-to-many relationships)?
How much experiences can be resued from the CWM DMSII extension package
here?

Regards,
Markus