Pipeline Data Cube Design Question

I'm looking more for SSAS 2008 best practice design advice, rather than for an answer to a specific question (although I have a specifc set of examples).

First issue:  Creating a non-additive measure group and an additive measure group.  We have some fact data in our current cube that is additive, and some fact data that is non-additive; all stored in the same fact table.  We do not currently have measures implemented that reflect this aggregation distinction.  Question:  Is it considered good practice to segregate additive and non-additive fact data into a) different fact tables and/or b) different measure groups?  My thought is that it would be an acceptable design approach, but am looking for feedback.

Second issue:  Non-additive fact data is only available at a non-leaf grain.  The example here is that we have non-additive fact data which is only available for the 4th or 5th levels of our 6-level geography dimension.  Our solution has been to create a custom geography branch, which now essentially serves as our 'aggregation treatment' for non-additive fact data.  I don't believe it's a good practice to have the geography dimension serve this function because we end up having to create a custom geo member for each non-additive fact data element.  Question:  What is considered best practice

Hi

I have a fact table that lists projects and the site visit dates that related to those projects.   For each site visit date there are a number of associated KPIs.

However to make life a little bit more complicated these KPIs are prorated by year so for each site visit there may be several rows in the fact table that relate to each year ie 2005,  2006 etc...

The issue I am having is that I have been given a requirement to view each KPI at the site visit level.   My first idea was to create an aggregate table for each site visit with totals for each year ie  2005 sales total,  2006 sales total etc...    The issue is that totals can be for any year between 2005 and 2014 and clearly creating all these hard coded totals means there will be a huge number of KPIs required with in-built time logic at the site visit level ie for each KPI I would need a separate measure for each possible year.

Any other alternatives?   The underlying fact table will of course show the end user a list of site visits and the KPIs relating to each year,  but the end user wants to be able to view the data in a repivoted format so that site visit returns 1 row with the prorated date columns appearing vertically across.   For the time being I cannot see that this is possible without having a huge agg

For handy database interface, is it good to use SqldataSources exclusively intead of EntLib functions?

Thanks for any feedback.

In this article, Paul Ballard shows how you can provide data binding support for your custom collections to enable sorting, searching, and editing in as simple a manner as possible. In addition, he shows how to make all of these features available in the Windows and Web Forms Designers, just like an ADO.NET DataSet.

Paul Ballard

MSDN Magazine August 2005

I have a data modeling question that hopefully this fictious example will help explain.  My application is data driven and the classes reflect the tables to a large degree.   In this example my database has two tables:

• VendorMaster with an int Primary Key of VendorID
• VendorContact with an int Primary Key of ContactID

The VendorContact table also has a Foreign Key of VendorID in order to associate the contact with a specific Vendor.  In this example a Vendor can only have one contact.

My question is how to represent these two tables in terms of classes.  In my current design I have two classes:

• VendorMaster
• VendorContact

In order to represent the relationship between a VendorMaster and VendorContact, my VendorMaster class contains a property called VendorContact.

My questions are about the VendorContact class and how it represents the relationship between a VendorMaster and itself.

Option #1

The VendorContact class should contain an int property of VendorID

Option #2

The VendorContact class should contain a VendorMaster Property

I am not sure which option is the 'best' option to take. My concern is that if I go with option #2 that I would create a cyclical relationship between the VendorMaster and Vendo