How to implement column-level security in SSAS (MSBI)? lets say In a cube 10 columns are there , i want restrict 2 columns for a role , and another 3 columns for an another role , how we do this implementing column level security ?
You mean SSAS Tabular? Since SQL Server 2017 you can set column level restrictions like this: https://learn.microsoft.com/en-us/analysis-services/tabular-models/object-level-security?view=asallproducts-allversions#column-level-security.
If you mean Power BI, that's not a feature supported out of the box. There are ways to fake it though: https://sqldusty.com/2019/10/08/dynamic-column-level-security-with-power-bi-and-ssas/
Related
I am new to the BI realm so forgive me for any mistakes in my understanding. I am designing a Cube using Pentaho with Saiku and have created a basic star schema to support it. My fact table consists of a few facts which are numerical values representing hours of work and cost of work and surrogate keys to the dimension tables.
I need to be able to perform sorting, filtering and querying on several dates related to my fact records. I have created a date dimension to accomplish this. The problem I am having is relating my fact table to this dimension multiple times. Using Schema Workbench I managed to create multiple DimensionUsage records for each of my surrogate keys with different names each pointing to my date dimension.
Upon importing this Mondrian file back into Pentaho and creating a new Saiku Query I am presented with my list of measures and the related dimensions. The issue is that all my references to my date dimension are named the same, the name of the dimension table rather than the name I specified in Schema Workbench. I am unable to tell which relation is for which date field. Any ideas of where I may have gone wrong or is this a limitation of the products I am using?
I am using Pentaho CE 7.1
I am doing the BI reports for a group of 5 companies. Since the information is more or less the same for all the companies, I am consolidating all the data of the 5 companies in one DB, restructuring the important data, indexing the tables (I can not do that in the original DB because ERP restrictions) and creating the views with all the information required.
In the group, I have some corporate roles that would be benefit of having the data of the 5 companies in one view, nevertheless, I am not interested that an employee of company 1 see the information of company 2, neither in the other way. There is any way to grant permissions restricting the information to the rows that contain employee´s company name in a specific column?.
I know that I could replicate the view and filtering the information using the WHERE clause, but I really want to avoid this. Please help. Thanks!
What you are talking about is row level security. There is little to no support out of the product for this.
Here are a couple articles on design patterns that can be used.
http://sqlserverlst.codeplex.com/
http://msdn.microsoft.com/en-us/library/bb669076(v=vs.110).aspx
What is the goal of consolidating all the companies into one database?
Here are some ideas.
1 - Separate databases makes it easier to secure data; However, hard to aggregate data.
Also, duplication of all objects.
2 - Use schema's to separate the data. Security can be given out at the schema level.
This does have the same duplicate objects, less the database container, but a super user group can see all schema's and write aggregated reports.
I think schema's are under used by DBA's and developers.
3 - Code either stored procedures and/or duplicate views to ensure security. While tables are not duplicated, some code is.
Again there is no silver bullet for this problem.
However, this is a green field project and you can dictate which way you want to implement it.
As of SQL Server 2016 there is support specifically for this problem. The MSDN link in the accepted answer already forwards to the right article. I decided to post again though as the relevant answer changed.
You can now create security policies which implement row level permissions like this (code from MSDN; assuming per-user permissions and a column named UserName in your table):
CREATE SCHEMA Security
GO
CREATE FUNCTION Security.userAccessPredicate(#UserName sysname)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS accessResult
WHERE #UserName = SUSER_SNAME()
GO
CREATE SECURITY POLICY Security.userAccessPolicy
ADD FILTER PREDICATE Security.userAccessPredicate(UserName) ON dbo.MyTable,
ADD BLOCK PREDICATE Security.userAccessPredicate(UserName) ON dbo.MyTable
GO
Furthermore it's advisable to create stored procedures which check permission too for accessing the data as a second layer of security, as users might otherwise find out details about existing data they don't have access to i.e. by trying to violate constraints. For details see the MSDN article, which is exactly on this topic.
It points out workarounds for older versions of SQL Server too.
If you want to restrict view data using the where clause, the easiest way is to create a view and then assign permission to the user.
example:
CREATE VIEW emp AS SELECT Name, Bdate, Address FROM EMPLOYEE WHERE id=5;
GRANT SELECT ON emp TO user
I have a Dimension (Account) with two attributes - Group and Account. The cube is a pre-built one and has no hierarchy defined on these attributes.
I need to write an MDX query that could provide me with number of accounts against each group.
Changing the cube is not an option so I am looking for a purely programmatic solution.
This could be fairly simple in T-SQL but doesn't seem so straightforward with MDX.
I'd like to design a cloud business solution with 4 default tables, a user may add a custom field(Column?) or a add a custom object(Table?).
My first thought was to create a new database for each account but there's a limit to database number on a sql server instance,
2nd solution : for each account create a new schema by duplicating the 4 default tables for each schema.
3rd solution : create 4 unique tables with a discriminant column (ACCOUNT_ID), if a user wants a new field add a join table dedictated to that ACCOUNT_ID, if he wants a new object then create a new table.
What are your thoughts? Does any body know how existing cloud solutions store data? (for instance salesforce)
BTW, I don't want to create a VM for each account.
Thanks all for your suggestions, that helped me a lot especially the microsoft article suggested by John.
Since few architectural points are shared between accounts (the 4 default tables are just a suggestion for the user, I expect a full customization), I've opted for the schema per account design with no EAV pattern.
We use a third-party product to manage our sports centre membership. We have several membership types (eg. junior, student, staff, community) and several membership statuses (eg. annual, active, inactive, suspended). Unfortunately the product only records a member's current membership type and status. I'd like to be able to track the way our members' type and status have changed over time.
At present, we have access to the product's database design. It runs on SQL Server and we regularly run our own SQL queries against the product's tables to produce our own tables. We then link our tables to pivot-tables in Excel to produce charts. So we're familiar with database design and SQL. However we're stuck as to how to best approach this problem.
The product records a member's membership purchases and their start and expiry dates. So we can work back through that data to determine a member's type and status at any point in time. For example, if they bought a junior membership on Jan 1, 2007 and it expired on Dec 31, 2007 and then they bought a student membership on Jun 1, 2008, we can see their status went from active to inactive to active (on Jan 1, 2008 and Jun 1, 2008, respectively) and their type went from junior to student (on Jun 1, 2008).
Essentially we'd like to turn a member's type and status properties into temporal properties or effectivities a-la Fowler (or some other thing that varies with time).
Our question (finally :) - given the above: what database table design would you recommend we use to hold this member information. I imagine it would have a column for MemberID so we can key into the existing Member table. It would also need to store a member's status and type and the date range they were held for. We'd like to be able to easily write queries against this table(s) to determine how many members of each type and status we had at a given point in time.
UPDATE 2009-08-25: Have been side-tracked and haven't had a chance to try out the proposed solutions yet. Hope to do so soon and will select an answer based on the results.
Given that your system is already written and in place, the simplest approach to this problem (and the one that affects the existing database/code the least), is to add a membership history table that contains MemberID, status, type and date columns. Then add an UPDATE and an INSERT trigger to the main member table. When these triggers fire, you write the new values for the member (along with the date of the status change) into the member history table. You can then just query this table to get the histories for each member.
This is fairly simple to implement, and won't affect the existing system at all.
I'll write this for you for a free membership. :)
I cannot recommend you enough to read Joe Celko's "Sql for smarties - advanced sql programming". he has a whole chapter on temporal database design AND how to (effeciently and effectively) run Temporal Projection, Selection and Temporal Join queries. And I would not do him justice to even attempt to explain what he says in his chapter in this post.
I would create a reporting database that was organized into a star schema. The membership dimension would be arranged temporally, so that there would be different rows for the same member at different points in time. That way different rows in the fact table could pertain to different points in history.
Then I would create update procedures for updating the reporting database periodically, say one a week, from the main database. This is where the main work would come.
Then, I would drive the reports off the reporting database. It's pretty easy to make a star schema do the same things a pivot table does. If necessary, I'd get some kind of OLAP tool to sit in front of the reporting database.
This is a lot of work, but it would pay off over time.
I would put the membership info in it's own table with start and end dates. Keeping the customer in separate table. This is a pain if you need the "current" membership info all the time but there are many ways to get around that either through queries or triggers.