Database Reference
In-Depth Information
• We can use Analysis Services to model
joins inside the Data Source View of
the project using Named Queries. By doing this, we are relying on Analysis
Services to query the database efficiently and recreate the star schema.
Although this approach might seem almost equivalent to the use of views in
the relational database, in our opinion there are some very good reasons to
use views instead of the Data Source View. We discuss these in the section
later on in this chapter called
Views versus the Data Source View
.
• We can build Analysis Services dimensions from a set of snowflaked tables.
This can have some benefits since it makes it easier for the Dimension
Wizard to set up optimal attribute relationships within the dimension, but
on the other hand as we've already noted, it means we have to remember
which columns join to each other every time we build a dimension from
these tables. It's very easy to make mistakes when working with complex
snowflakes and to get the error message,
the '[tablename]' table that is
required for a join cannot be reached based on the relationships in the
Data Source View
when you try to process the dimension.
•
We can leave the snowflake schema in place and create one Analysis Services
dimension for each table, and then use referenced relationships to link these
dimensions back to the fact table. Even if this solution seems an interesting
one, in our opinion, it is the worst.
First of all, the presence of reference dimensions may lead, as we will discuss
later, to performance problems either during cube processing or during
querying. Additionally, having two separate dimensions in the cube does not
give us any benefits in the overall design and may make it less user-friendly.
The only case where this approach could be advisable is when the dimension
is a very complex one; in this case it might be useful to model it once and use
reference dimensions where needed. There are some other situations where
reference dimensions are useful, but they are rarely encountered.
In all cases, the rule of thumb we recommend and use is the same: keep it simple!
This way we'll make fewer mistakes and find it easier to understand our design.
Search WWH ::
Custom Search