I need to implement a granular, hierarchical security to my dimensions and cubes (facts).
The requirement is that when the user connects to SSAS I want them to see the subset of data data which belongs to that particular tenant only.
On top of that, I need to be able to allow the user to interact with dimensions and facts she/he has the rights to. For example, if Manager A manages Person B and Manager C, who manages Person D, then when Manager A look at sales he/she needs to be able to see everybody down the hierarchy, including Manager C and Person D sales. But if that OLAP client is Manager C, then he/she only sees Person D's sales. This has to work recursively as any hierarchy (child-parent relationship) does.
My basic data set is comprised by:
Tenant
Customer
Employee (self referencing entity for sales reps, managers, supervisors, etc)
Supervisor (a many to many relationship entity that specifies additional managers to a particular employee), i.e., the Manager ID on the Employee table refers to the primary manager. If that person is managed by somebody else in addition, then this table gets populated.
Role (employee's role including their seniority level)
Sales
Promotion
as for the relationships, each Tenant has multiple Customers, Employees Roles, Promotions and Sales. My transactional database is normalized to the 3rd normal form and all tenants share the same database.
I tried to denormalize the structure to the best of my knowledge when creating the dimensions and facts. For example, I have the Tenant surrogate key in the Sales fact and about any other dimension. By the way, is that something you guys would recommend?
I have researched the web and I see different approaches of implementing this design, being:
Security Wise
factless fact table between Fact and Dimensions and user context set via USERNAME(). In my case I would have to map all Dimensions to Employees (with a primary key/foreign key approach) and add new measure groups, etc.
use the Default member and Allowed set with STRMEMBER on each Tenant attribute, setting Visual Totals to true.
Management Hierarchy
mostly add new dimension over a factless for each many-to-many I want to map
It looks like there is some overlap between the approaches but I am not sure how well this would perform, nor do I know if there are any other ways to implement this.
Note: our system is a product sold on the web, therefore I can't simply have one role for each Tenant, otherwise this would have been easier to solve.
Can somebody recommend an approach?
Cheers,
Robson
Related
I'm designing database for an mobile-based ecom platform.
Currently, the system have one and only one shop. The design for the database of the system has the tables below:
User
Product
Category
Review
Order
Now, I want to scale up the system so that it can support multiple shops. User can sign-up as a seller and create their own shop, manage their own products and orders.
How can I design such a database from the original database which was designed only for one shop?
I have two options in mind but I have no idea whether they will works or not:
For each record in the table, I add a field shopId that ref to the id of the shop it belongs to. Then I will index this field to increase query's performance.
For each shop, I create a new collection/table to store the data that belongs to it. For example: shop1_product, shop1_order,... are the tables i will create for the shop1.
Are the approach above valid? Is there any other better approach.
P/s: I'm using MongoDB, and the system doesn't require operations across many shops.
Thank you guys!
My company has 10 sales persons, and I want that each person can view in my sales cube, only the data linked to this person.
For example Anne MARTIN will only see her sales and not the sales of Patrick DUMONT.
I already created a role that work fine for Anne MARTIN, but if I have 10 sales persons, I have to duplicate this role 10 times and create a new one for each new employee.
Everybody use a Windows credential, for example "domain\amartin" and I want to use this credential in my role to link with my dimension "sales person" and authorize to see only data linked with amartin.
I found some code on the net but I did not obtain anything ...
Is it possible and how to do it ?
thanks.
Damien.
It is common practice to create roles and assign membership to separate operations. Often, the model designer adds roles during the design phase. This way, all role definitions are reflected in the project files that define the model. Role membership is typically rolled out later as the database moves into production, usually by database administrators who create scripts that can be developed, tested, and run as an independent operation.
I am building a OLAP Cube in SSAS for an organization which has many different companies under its umbrella.
i have built a principal cube which consists of all the measure groups and dimensions, which has the data of all the companies in this organization.
Now this cube is ok for the top level management, but i need to limit the access of users from each of the companies, only to the data of its own company.
Is there a way to do that in the principal cube, without duplicating it to many sub cubes, each consists of only the relevant company?
Thank you in advance,
Tal
You can use role based security in combination cell-based security. below link can be useful:
https://learn.microsoft.com/en-us/sql/analysis-services/multidimensional-models/grant-custom-access-to-cell-data-analysis-services
We solved the problem through the automatic modification of MDX queries, restricting data through nested cubes (subcube) for each organization. Not only data, but also cube metadata were limited. The mechanism of roles to the customer is not suitable, as organizations and users are constantly added.The Ranet UI Pivot table was used in the Saas solution. The library allows you to parse and modify MDX query, as well as filter the metadata of the cube.
Microsoft CRM 2015.. a great little customer management system, but why did do they leave suppliers out?
Anyway how do I create and manage suppliers using Dynamics CRM?
or do you need different software for that?
Cheers,
In previous versions I have created custom entities for Vendor and Supplier. Here are some of the setup I did, of course always depends on business needs.
1:N Supplier to Product relationship
Added fields for supplier details
1:N Contact to Supplier for POC at organization
1:N User to Supplier for POC within our organization
If you are not using the out of the box quote to order to contract process then you will need to accommodate for Product inventory and qty on hand limits.
Used Goals and Rollups to set minimum inventory levels and restock alerts
Make sure finance is involved in the design of this process as they may be particular about how reordering is handled. While users may want it automated there might be internal requirements, specifics on contracts with suppliers that require some additional review.
Created relationships for Contract and opportunity records
This was needed to improve reporting since you cannot report out on second tier relationships. For example - how many opportunities are coming related to this particular supplier who is delayed delivering. If the supplier relationship is not on the Opportunity record itself you cannot get to it.
These were the key items I thought mattered. There is always more, but you should not need to purchase an alternative supplier tracking software.
I'm trying to create a proper database layout for a project I'm working on, however I can't seem to work out which is best.
Basically the "app" is something where a User can be assigned to many Products, and a Product can be have many Customers.
From here, each Customer has a Service, which is specific to that Customer and Product.
A Service can have many Incidents, but an Incident can only be assigned to one Service.
A User can also have Incidents, but an Incident can only have one User.
Here is the two designs I have made for this:
http://i.imgur.com/ZcCFcdg.png
As you can see, the left design has a table specific tables for the Many-Many relationships, where as the right one has a overall pivot table for them all.
I see both of these methods working (in my head) - however since I'm not the best with this, are there any downsides to either of these methods? And do you see any problems I'll run into, in the future?
Also, is the right one even a proper way of doing it?
I'm also going to be using the Eloquent ORM.
Look up 'Third Normal Form'. This gives rules on how to design tables. You could take one or other of your current designs and apply the three rules to see where you get to.
I would say the one on the right is wrong: too much duplicate information, and unclear relationships. The one on the left is OK, but the two Many-Many tables are redundant. You know a Product and Customer are linked because it's in the Service table. You know a User and Product are linked because its in the Incident + Service tables.
Cheers -
After clarification, a User belongs to a Customer. In that case, add CustomerID to the User table - this is important data about the user and should be included. It will allow you to stop the User raising Incidents on Products not associated with the Customer.
This also will enable you to list the Products associated with the User via the Customer the User is associated with.
Further, the Customer should have it's ID on Product, and Service should have the ProductId, not the CustomerID, as the Service is associated with a Product and only with a Customer via the Product it is associated with.