THE SQL Server Blog Spot on the Web
Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | Join | Help
in Search

SQLBI - Marco Russo

SQLBI is a blog dedicated to building Business Intelligence solutions with SQL Server

Surrogate key issues with Analysis Services

Usually I don't post something just to raise a question - but every rule has its exceptions.

As you know, using surrogate keys is a best practice for a lot of reasons. Everything works fine with SSAS when you use surrogate keys with a plain star schema. If you have an incremental process of the dimensions in the Data Warehouse, you are also granted that surrogate keys don't change their internal meaning during time. But, are you sure you want to use surrogate keys in end user reporting tool?

The problem arises when you have a daily reprocess of the whole OLAP database and of the whole relational data mart (or data warehouse, if you prefer). A complete reprocess is not so strange if you have less than 10 GB of data. I've seen the same technique applied to data mart with tens of millions of rows in the fact table and 20/30 GB of data (the process can be 3/4 hours each night).

Each dimension that makes the granularity attribute visible to end users, also exposes the surrogate key. Even if you change the Name property of the attribute, its Key still maintains the surrogate key. When the end user creates a pivot table with Excel 2007 or a report with ProClarity, he never see the surrogate key, but he save a document that contains that key and that will use this key to query the cube next time.

The user might open a query saved some days/months ago and... He doesn't see the same members, just because the same surrogate keys got a different meaning. If surrogate key are generated each night, this happens daily. Even with an incremental data mart you might have the need to reprocess (on the relational side) one or more dimensions in the future.

Now, the issue is both practical and philosophical. From the practical point of view, the user rants he lost his reports. From the philosophicalside, when you save a surrogate key in a report, you are giving a semantic value to something that probably shouldn't have one.

With SSAS and pivot tables this is a practical issue that may be approached in several ways. I'm studying what is the better balance between usability, maintainability and performance. But I'd like to get some comments about this issue that probably is very common. I did some search, but I haven't found a good discussion focused on the issues related to Analysis Services client tools.

Give me your feedback!


Published Tuesday, July 03, 2007 6:46 PM by Marco Russo (SQLBI)
Filed under:

Comments

 

Sqlgoof said:

Well i normally choose to eliminate unwanted attributes and this includes the SK. So for the productname atttribute for exmaple i'll use the SK as key and productname as name, then delete the SK as attribute. So in Excel you'll still have the key but only see the productname, i don't see how one will get away from that....

July 12, 2007 4:03 AM
 

Marco Russo (SQLBI) said:

The idea is to put:

SK as Attribute Key (invisible)

ProductName as Attribute (with an application-key as Attribute Key and ProductName as Attribute Description)

Marco

July 14, 2007 8:29 AM
 

SQLBI - Marco Russo said:

BI Developer Studio does a lot of automatic changes when you change something. Each dimension is stored

July 16, 2007 8:58 AM
 

AlbertoFerrari said:

One more problem raises when you have a parent/child hierarchy. In this case hiding the SK and leaving only the natural key as visible is not a viable solution because you need to use the primary key of the dimension to let the dimension relate to itself with the parent/child relationship.

So, for P/C hierarchies I had to use the natural key to make the relation from both the fact table and the hierarchy in itself.

Up to now, I haven't found a better solution with parent/child hierarchies, if anyone has a better idea she's welcome.

September 10, 2007 1:56 PM
Anonymous comments are disabled

About Marco Russo (SQLBI)

Marco Russo is a consultant, writer and trainer specialized in Business Intelligence with Microsoft technologies. He runs the SQLBI.EU website, which is dedicated to distribute resources useful for BI developers, like Integration Services components, Analysis Services models, tools, technical information and so on. Marco is certified as MCT, MCDBA, MCSD.NET, MCSA, MCSE+I.

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement