###BeginCaseStudy###
Case Study: 3
Data Architect
General Background
You are the data architect for a company that uses SQL Server 2012 Enterprise Edition. You
design data modeling and reporting solutions that are based on a sales data warehouse.
Background
The solutions will be deployed on the following servers:
• ServerA runs SQL Server Database Engine, ServerA is the data warehouse server.
• ServerB runs SQL Server Database Engine, SQL Server Analysis Services (SSAS) in
multidimensional mode, and SQL Server Integration Services (SSIS).
• ServerC runs SSAS in tabular mode, SQL Server Reporting Services (SSRS) running
in SharePoint mode, and Microsoft SharePoint 2010 Enterprise Edition with SP1.
The data warehouse schema currently contains the tables shown in the exhibit. (Click the
Exhibit button.)
Business Requirements
The reporting solution must address the requirements of the sales team, as follows:
• Team members must be able to view standard reports from SharePoint.
• Team members must be able to perform ad-hoc analysis by using Microsoft Power
View and Excel.
• Team members can have standard reports delivered to them on a schedule of their
choosing.
The standard reports
• Will use a sales territory hierarchy for organizing data by region.
• Will be accessible from SharePoint.
The Excel ad-hoc reports
• Will use the same data store as the standard reports.
• Will provide direct access to the data store for the sales team and a simplified view for
the executive team.
Technical Requirements
The standard reports must be based on an SSAS cube. The schema of the data warehouse on
ServerA must be able to support the ability to slice the fact data by the following dates:
• Order date (OrderDateKey)
• Due date (DueDateKey)
• Ship date (ShipDateKey)
Additions and modifications to the data warehouse schema must adhere to star schema design
principles to minimize maintenance and complexity.
The multidimensional and tabular models will be based on the data warehouse. The tabular
and multidimensional models will be created by using SQL Server Data Tools (SSDT). The
tabular project is named AdhocReports and the multidimensional project is named Standard
Reports.
The cube design in the Standard Reports project must define two measures for the unique
count of sales territories (SalesTerritoryKey) and products (ProductKey).
A deployment script that can be executed from a command-line utility must be created to
deploy the StandardReports project to ServerB.
The tabular model in the AdhocReports project must meet the following requirements:
• A hierarchy must be created that consists of the SalesTerritoryCountry and
SalesTerritoryRegion columns from the DimSalesTerritory table and the
EmployeeName column from the DimEmployee table.
• A key performance indicator (KPI) must be created that compares the total quantity
sold (OrderQuantity) to a threshold value of 1,000.
• A measure must be created to calculate day-over-day (DOD) sales by region based on
order date.
SSRS on ServerC must be configured to meet the following requirements:
• It must use a single data source for the standard reports.
• It must allow users to create their own standard report subscriptions.
• The sales team members must be limited to only viewing and subscribing to reports in
the Sales Reports library.
A week after the reporting solution was deployed to production, Marc, a salesperson,
indicated that he has never received reports for which he created an SSRS subscription. In
addition, Marc reports that he receives timeout errors when running some reports on demand.
###EndCaseStudy###
You need to create the hierarchy in the AdhocReports project.
What should you do?
A.
Multi-select all of the columns, right-click the columns, and then click the Create Hierarchy
command.
B.
Use the RELATEDTABLEO function to consolidate the tables, multi-select the columns in
the hierarchy, right-click the columns, and then click the Create Hierarchy command.
C.
Use the RELATEDO function to consolidate the columns in the DimSalesTerritory table,
multi-select the columns, right-click the columns, and then click the Create Hierarchy
command.
D.
Use the RELATEDO function to consolidate the columns in the DimEmployee table, multiselect the columns, right-click the columns, and then click the Create Hierarchy command.
C.
Use the RELATEDO function to consolidate the columns in the DimSalesTerritory table,
multi-select the columns, right-click the columns, and then click the Create Hierarchy
command.
D. You have to consolidate columns in Employee table
(the one side of the relationship)
A – would work if all the columns would be in the same table: https://www.youtube.com/watch?v=qKKNY1Vj_2c but this is not our case
B – https://www.youtube.com/watch?v=yAcuqZj1iww No!! You need to go like in (C or D) We need to find a related field not a related computed column
C – would be quiete nice, but… you can find a related record for employee and you cannot find a related record for the territory. Here we would try to find one record related to territory, what is bad
D – is correct one. First build a “view” using related function and later build a hierarchy on it (like in “A”) – related function: https://www.youtube.com/watch?v=6cPjxEyhrVY It is easy to find a territory for a specific eemployee (look at database diagram)
I feel, it needs to be a combination of B+D.. But if it is a single answer to be chosen the D sounds correct
+1
no, i went =1 for Ralph’s answer “D”