但它有一些缺点：
>对于新的变化,它可能相当发展密集
>用户不能对数据进行实验,它被锁定到硬编码视图
>大报告可能很慢
我正在考虑逐步采用基于OLAP的方法,可以从Excel或某些基于Web的服务中查询.但是我想这样做的方式是在IT环境中引入最少的新复杂性 – 最少的不同的服务,同步任务等！
我在这方面有一些问题：
1)工作流相关：
>从“黑匣子sql服务器”到“OLAP准备使用”的良好开发路线是什么？
应该设置哪些服务器和服务,哪些脚本应该写？
哪些是最难的/最关键的/最耗时的部分？
2)ETL：
>我想最好为其数据仓库和生产sql单独使用服务器？
>如何保持同步(推/拉)？使用哪种技术/语言？
>对于我来说,SSIS看起来过于复杂,图形工作流程对我来说并不吸引人,我宁愿喜欢一个基于文本的脚本来完成这项工作.这可行吗
>或者只使用一个源和一个目的地的图形客户端是有利的吗？
3)开发：
>可以通过CLI工具高效地维护多少(数据集成,分析服务)？
>可以轻松地在生产和开发之间来回传递设置？
我对任何涵盖其中的一些答案感到满意 – 即使是MS环境,我也有兴趣了解其他技术的优势.
解决方法
>如果要实施多维数据集,则将生产sql Server与多维数据集的源分开.多维数据集需要大量的SELECT DISTINCT column_name FROM source.table.您不需要多维数据集处理来阻止您的任务关键生产系统.
>尽管您可以使用标准关系表实现OLAP多维数据集,但您将很快发现,除非您的数据是分类帐风格的系统,否则可能需要完全重新处理您的事实和维度表,这将需要一遍又一遍地重新引用源数据库. .这是建立一个单独的数据仓库的一个很大的参数,它使用事实表的分类帐式事务.例如,如果客户订购一些东西,然后取消它,您的源系统可能会将其视为状态更改.在您的事实表中,您可能需要将其显示为排序的一行,其数量和收入来源均为正数,而排除的数据排列为负数和收入来源.
> OLAP可能会对您的环境造成过度伤害.您似乎提出的主要问题是您的报告是静态的,用户需要直接访问数据.您可以构建数据模型,并在SSRS中为用户提供Report Builder访问权限,或者在其他BI套件(如Cognos,Business Objects等)中报告写入权限.我通常不推荐使用此方法,因为它超出了大多数用户应该拥有的知道获取数据,但在一个小商店这可能是足够的,它很容易实现.让我们面对它 – 用户通常只想将数据导入Excel以进一步操作.所以,如果你不想给他们一个Web前端,而你只是希望他们从Excel获取数据,你可以给他们直接的数据库访问生产数据的副本.这种方法的缺点是用户一般不了解sql或数据库关系. OLAP可以帮助您避免强迫用户学习sql或关系,但是最终不容易实现.如果您只有几个需要这种访问权限的用户,可以轻松地教授少数高级用户如何在Excel中对数据库执行基本查询,并且他们将很高兴获得这一点. OLAP将不会在明天做好准备.
>如果您只有几种源数据系统,您可以避免构建超级动态静态报告.例如,我有一个以C#编写的报告,基本上允许用户从30列列表中选择尽可能多的列,并在几个日期范围字段和字段过滤器列表中过滤数据.这份简单的报告涵盖了最终用户所有特别报告请求的40％,因为它涵盖了所有基本的核心客户指标和领域.我们最近将这份报告转交给了SSRS,这使得我们可以将现场数量提高到大约100个,并改善了整体用户体验.不管报告平台如何,即使在静态报告系统的范围内,也可以给予用户一些动态的灵活性.
>如果您只有几个数据库,您可以备份和还原数据库作为ETL.但是,如果你想做任何事情,那么你也可以咬住子弹,并使用SSIS(或其他一些ETL工具).一旦您进入数据仓库的ETL,您将使用面向图形的设计工具.编码适用于应用程序,但ETL更多地涉及工作流程,因此这些工具倾向于在图形UI上进行融合.您可以解决这个问题,并尝试从文本编辑器中编写数据仓库,但是最终您将失去很多. See this post for more details on the differences between loading data from code and loading data from SSIS.
反馈如何使用具有相关数据存储的库
可以通过关系数据存储实现多维数据集,但使用此方法存在一些主要问题.技术上可行的主要原因与您如何配置DSV有关. DSV本质上是物理数据库和多维数据集/维度定义之间的逻辑层.不必将关系表导入到DSV中,您可以在数据库中定义命名查询或创建视图,使数据平坦化.
这种方法的优点如下：
>相对容易实现,因为您不必构建整个ETL子系统即可开始使用OLAP.
>这种方法适用于原型设计如何构建更长期的解决方案.您可以在1-2天内对其进行原型化,并显示OLAP的一些优势.
>一些非常非常大的表不一定要完全重复,只是为了支持OLAP多维数据集.我有几十亿个行表,几乎完全是标准化的事实表.它们没有的唯一列是日期键,并且在字段上也包含一些NULL值,该字段根本不应为空.您可以创建替代日期键,并为视图或命名查询中的空值设置值,而不是复制这些非常大的表.如果您不会看到重复表格的巨大表现,那么这可能是在数据库本身中以更原始格式离开的候选人.
这种方法的缺点如下：
>如果你还没有建立一个真正的Kimball方法数据仓库,那么你可能不是用分类帐风格跟踪交易. Kimball方法事实表(至少根据我的理解)总是通过添加和减少行来改变值.如果有人取消订单的一部分,则无法更新单个事务的多维数据集中的值.相反,您必须平衡交易与负值.如果必须更新事务,那么您将必须完全重新处理多维数据集的分区以替换可能是非常昂贵的操作的值.除非您的源系统是分类帐式交易系统,否则您可能需要在ETL子系统中构建分类帐式副本.
>如果您不建立一个Kimball方法数据仓库,那么您可能在数据库中使用了可视化和非整数主键.这直接影响立方体内的查询性能.它还为您设置理论上不灵活的数据仓库.例如,如果您有一个使用整数键的产品订购系统,并且您开始使用第二个产品订购系统作为旧系统的替代品或与传统系统配合使用,您可能会很难将数据组合在一起,只是通过DSV因为每个系统都有不同的数据点,指标,工作流程,数据类型等.更糟糕的是,如果它们具有与订单id相同的数据类型,并且订单id值在系统之间重叠,那么您必须声明一个代理键可以跨两个系统使用.在不使用扁平化的数据仓库的情况下,这可能是困难的,但并非不可能实施.
>如果您从关系数据存储开始,然后移动到平坦的数据库,您可能需要建立系统两次.坦白说,我认为重复工作的数量是微不足道的.您学到的大部分建立立方体数据库的关系数据存储将转换为设置新的OLAP多维数据集.主要的问题是,您可能会完全创建一个新的多维数据集,然后旧多维数据集的任何用户都必须迁移到新的多维数据集.在SSRS或Excel中构建的任何报告可能会在这一点上破裂,需要从头改写.因此,重建多维数据集的主要成本在于重建依赖对象 – 而不是重建多维数据集本身.
如果你想要我扩大上述任何一点,让我知道.祝你好运.
