###BeginCaseStudy###
Case Study: 1
Tailspin Toys
Background
Tailspin Toys is a multinational company that manufactures toys. Tailspin Toys has offices in
five regions worldwide. The company sells toys at various retail stores. The company also
sells toys directly to consumers through a web site.
The company has the following departments:
• Sales
• Distribution
• Manufacturing
Each department has an office in each region.
The fiscal calendar of Tailspin Toys runs from June to May.
The network contains a server farm that has Microsoft SharePoint Server 2013 installed.
Existing Environment
Current Database Environment
Each department uses SharePoint team sites for internal collaboration.
All manufacturing information is stored in a relational database named Manufacturing. All
sales information is stored in a relational database named Sales.
Tailspin Toys deploys SQL Server Analysis Services (SSAS) and configures SSAS to use
tabular models. SSAS will be used for all sales reports.
Tailspin Toys deploys a SQL Server Reporting Services (SSRS) instance in SharePoint
mode.
Sales Database
A database named Sales contains two tables named FactSales and DimProduct. FactSales
contains the following columns:
• SalesID
• Total Due
• OrderDate
DimProduct contains the following columns:
• ProductID
• ProductName
• ProductCategory
• ProductSubcategory
The Sales database contains information about the products. Most of the products have a
category and a subcategory. Certain products only have a category.
A sample from DimProduct is shown in the following table.
Requirements
Security Requirements
Tailspin Toys identifies the following security requirement:
• Sales department users must be allowed to view the sales transactions from their
region only.
• Sales department users must be able to view the contents of the manufacturing
reports.
• Manufacturing department users must be able to create new manufacturing reports.
• Third-party and custom solutions must NOT be deployed to the reporting server.
• Sales department users must NOT be able to create new manufacturing reports.
Planned Reporting Implementation
The manufacturing department plans to use the SSRS instance for its reports. The
manufacturing department also plans to make its reports accessible from SharePoint. All
manufacturing reports will use an existing database named Manufacturing.
Reporting Requirements
Tailspin Toys identifies the following reporting requirements:
• All reports must contain the company logo and a header that contains the date and the
time that the report was executed.
• All reports must be created by using the SQL Server Data Tools.
Manufacturing report
You plan to create a report named Manufacturinglssues.rdl. The report has the following
requirements:
• Manufacturing department managers must be able to view product issues by product
type, manufacturing plant location, and error type.
• The manufacturing department managers must be able to change views by choosing
options from drop-down lists.
Sales reports
You plan to create a sales report named RegionalSales.rdl. The report has the following
requirements:
• Users must be able to view the report by using a web browser. By default,
subcategories and product details must be hidden when using the browser.
• Users must be able to subscribe to receive the report by email. The report must be sent
by email as a PDF attachment.
You plan to create a quarterly sales report named QuarterSales.rdl. The report must display
sales data by fiscal quarter.
Technical Requirements
Tailspin Toys identifies the following technical requirements:
• Products in the DimProduct table that do NOT have a subcategory must use the
category value as the subcategory value.
• SSRS must NOT connect to databases more frequently than once every 30 minutes.
• Sales department users must be able to use Microsoft Excel to browse tabular data.
###EndCaseStudy###
You need to recommend a solution for the sales department that meets the security
requirements.
What should you recommend?
A.
Create one role for all of the sales department users. Add a DAX filter that reads the
current user name and retrieves the user’s region.
B.
Create one role for each region. Configure each role to have read access to a specific
region. Add the sales department users to their corresponding role.
C.
Create a table for each region. Create a role for each region. Grant each role read access
to its corresponding table.
D.
Create one role for all of the sales department users. Configure the role to have read
access to the sales transactions. Ensure that all of the reports that access the sales
transaction data restrict read access to the data from the corresponding sales department
region only.
A?
Looks like A, but there isn’t told
that users/regions table exists to support this solution.
B will also work though it is less generic solution,
but cause we have only 5 regions there is no much
maintenance overhead to implement it.
Agree with B. There is nothing in the case study that would suggest that the users/regions table exists.
the information about the user region comes from the context of the task.
“Tailspin Toys has offices in five regions worldwide.” “Each department has an office in each region.” means that sales users are spread in 5 regions. then you should map them by region, it’s obvious that you have the information in which area the sales user is.
C seems wrong to me because you should create tables, when the reports accessing the sales cube. A and D sound not right but i am not sure. i would guess B is the right awnser
“A” is quite dynamic. Even if we don’t have table for it, DAX expression can return correct value.
What is the difference between B and C ???
They both create a role per region and assign read permissions to the specific region. 🙁
I guess it could be C since it`s the only option creating a table for each region.
In option B, how can you configure each role to have read access to a specific
region if you don`t have any info of the regions on the current DB schema?
As Dim said, option A would be right and easier to implement if we had users/regions table to support this option.
D option just sounds wrong as users could go directly to the DB and query transactions from all regions (security is implemented at the report level).
I would vote for A as it looks more generic