Analysis Services 教程方案
适用于： SQL Server Analysis Services Azure Analysis Services Power BI Premium本教程基于 Adventure Works Cycles（一家虚构的公司）。 Adventure Works Cycles 是一家大型跨国制造公司，生产金属和复合自行车并将其分发到北美、欧洲和亚洲的商业市场。 Adventure Works Cycles 的总部是华盛顿的 Bothell，该公司雇用了500名员工。 此外，Adventure Works Cycles 在其市场基础中雇佣了多个区域销售团队。
近年来，Adventure Works Cycles 收购了位于墨西哥的一家小型制造厂 Importadores Neptuno。 Importadores Neptuno 为 Adventure Works Cycles 产品系列制造了几个关键的子组件。 这些子组件将被运送到伯瑟尔市进行最后的产品装配。 在 2005 年，Importadores Neptuno 转型成为专注于旅游登山车系列产品的独立制造商和销售商。
在一个成功的财政年度之后，Adventure Works Cycles 现在希望通过将广告面向其最佳客户、通过外部网站扩展产品可用性以及通过降低生产成本来降低销售成本，从而扩大其市场份额。
当前分析环境
为了支持销售和营销团队以及高级管理层的数据分析需求，公司当前从 AdventureWorks2012 数据库中获取事务数据，以及电子表格中的销售配额等非事务性信息，并将此信息合并到 AdventureWorksDW2019 关系数据仓库中。 但是，关系数据仓库存在下列问题：
报表是静态的。 用户无法以交互方式浏览报表中的数据，以获取更详细的信息，例如，他们可以使用Microsoft Office Excel数据透视表。 虽然现有的一组预定义报表足以供许多用户使用，但更高级的用户却需要对数据库进行直接查询访问，以进行交互式查询和访问专用报表。 但是，由于 AdventureWorksDW2019 数据库的复杂性，因此此类用户需要太多的时间来了解如何创建有效的查询。
查询性能差异很大。 例如，有些查询只需几秒钟便可非常迅速地返回结果，而另一些查询需要几分钟才能返回结果。
聚合表难以管理。 为了改进查询响应时间，Adventure Works 的数据仓库团队在 AdventureWorksDW2019 数据库中生成了多个聚合表。 例如，他们生成了一种按月汇总销售额的表。 然而，尽管这些聚合表可显著提高查询性能，但是，他们所生成的用于在一段时间内维护这些表的基础结构却容易破坏并出现错误。
复杂的计算逻辑隐藏在报表定义中，所以很难在报表之间共享。 由于这种业务逻辑针对每个报表单独生成，因此，各个报表的汇总信息有时是不同的。 所以，管理人员对数据仓库报表数据的信任度是有限的。
用户所在的业务部门不同，其感兴趣的数据视图也不同。 每个组都很难理解与其不相关的数据元素。
对于需要专用报表的用户而言，计算逻辑非常具有挑战性。 由于这类用户必须为每个报表单独定义计算逻辑，因此，无法对如何定义计算逻辑进行集中控制。 例如，有些用户知道他们应使用基本统计技术（如移动平均值），但他们却不知道如何构建此类计算，因而也就无从使用这些技术。
组合相关的信息集时存在难度。 业务用户很难构造一些专用查询，以组合两个相关的信息集（如销售额和销售配额）。 此类查询会占用大量的数据库空间，因此，公司要求用户向数据仓库团队请求跨主题区域的数据集。 因此，仅定义了少数预定义报表，这些报表可以用于组合来自多个主题区域的数据。 此外，由于这些报表非常复杂，因此用户不愿尝试修改这些报表。
报表主要提供美国的业务信息。 非美国分公司的用户非常不满意只提供美国的业务信息，他们希望能够查看不同货币和不同语言的报表。
信息难以审核。 财务部门当前仅使用 AdventureWorksDW2019 数据库作为批量查询的数据源。 然后，再将数据下载到单个电子表格中，并花费大量时间准备数据和处理电子表格。 因此，很难在整个公司内准备、审核和管理公司财务报表。
解决方案
页:
[1]