I need to use Data Cubes to analyse the Sales Performance. Since the product costs are highly confidential it should not be exposed to the middle management. However, the other information needs to be published to the middle management. Is there a feature in SSAS that could enable this requirement?
SSAS Features for Confidential Data Handling
cubedata-warehouseSecuritysql serverssas
Related Solutions
The "header - detail" pattern is very common the domain of sales transactions.
To answer your question, there are so many factors that will come into play which you've not discussed. For example:
- If your DW infrastructure has a great deal of RAM and is on SSD storage, reads in this case are cheap, so it might make sense to denormalize some dimensions in the interest of usability.
- What are the use-cases of the data? In this case I can probably make assumptions - it is sales data. It'll be used for accounting, executive reporting, predictive analysis, customer service, and for just about every possible ad-hoc query you can imagine.
One general principle I use when deciding whether to snowflake a dimension or simply include it's value in the fact table is this:
- If the dimension has many attributes which might be useful for reporting (or if there will be report(s) solely on that dimension), I create a dimension for it.
Example: Consider the
CUSTOMER
dimension. A sales order has a customer, but there are other attributes which belong with theCUSTOMER
dimension which you might want to report on, like customer location, customer age/sex/marital status, customer type, customer create date, etc., and many other customer-related attributes. I wouldn't put all of these in a fact table, so in this case I "snowflake" to a customer dimension as there are many more attributes related toCUSTOMER
which might be relevant to your sales fact data. There would likely also be reports that solely rely on theCUSTOMER
dimension - like a "new customer by month" report. You wouldn't expect this to be in the fact data. ThePRODUCT
dimension is another I would almost always put in it's own dimension.
- If the dimension is a single value with no other useful attributes connected to it, I may consider it for inclusion in a fact table.
Example: We might have an attribute called "Order Source Channel" - which might be a single value describing where the sales order came from e.g. it might have values like
eCommerce
,Kiosk
,Point-of-Sale
,Phone-In
, etc. It's a single value, and no other related attributes exist for this entity. In this case, I am tempted to leave it in the fact table, rather than create a single-attribute dimension and require my users to do an additional join, etc.
Remember:
- The above is a generality, and I don't treat is as a hard-fast rule
- Data modeling is as much an art as it is a science. There are many scenarios which can go either way, and only experience will help you decide which way to go.
- Usability of your DWH structure should be as much a consideration as is performance. I try to never create a data model that requires my power-users to write SQL queries with 15+ or more joins just to get at sales data. This will lead to someone writing incorrect SQL (it always does). This will sometimes be mistaken as "bad data". This is what you, as a DWH developer, don't want happening.
Typically only the role definitions are part of the project. The role memberships are different by environment (dev,test,prod), are usually not administered by the model developers, and so are maintained separately. Then only row-level security is driven from a table in the model.
Best Answer
This is an overly broad question but SSAS has security features that allow you to shield data for certain users.
You should look into Roles and Permissions.
Since you are talking about shielding costs you probably just want to limit access to certain measures so you're probably looking for Grant custom access to cell data which limit access to the values:
If you want to hide the fact that the measure exists you need to look at Grant custom access to dimension data