Sql server 国家数据存储

可以在关系数据存储上实现多维数据集，但是使用这种方法存在一些主要问题。技术上可行的主要原因与如何配置DSV有关。DSV本质上是物理数据库和多维数据集/维度定义之间的逻辑层。您可以在数据库中定义命名查询或创建视图来展平数据，而不是将关系表导入DSV

这种方法的优点如下：

它相对容易实现，因为您不必构建整个ETL子系统来开始OLAP

这种方法可以很好地用于原型化您希望构建更长期的解决方案的方式。您可以在1-2天内对其进行原型化，并在今天展示OLAP的一些好处

一些非常非常大的表不必完全复制就可以支持OLAP多维数据集。我有几个几十亿行的表，它们几乎是完全标准化的事实表。它们唯一没有的列是日期键，并且它们还包含一些字段上的空值，这些字段不应该有空值。您可以在视图或命名查询中创建代理日期键并设置空值，而不是复制这些非常庞大的表。如果复制表不会带来巨大的性能提升，那么这可能是在数据库中以更原始的格式保留的一种候选方法

这种方法的缺点如下：

如果您还没有建立真正的Kimball方法数据仓库，那么您可能没有以分类账的方式跟踪交易。Kimball方法事实表（至少据我所知）总是通过行的加减来更改值。如果有人取消了订单的一部分，则无法为单个事务更新多维数据集中的值。相反，您必须用负值来平衡事务。如果必须更新事务，则必须完全重新处理多维数据集的分区以替换值，这可能是一个非常昂贵的操作。除非源系统是分类账样式的交易系统，否则您可能必须在ETL子系统中构建分类账样式的副本

如果您没有构建Kimball方法数据仓库，那么您可能正在数据库中使用未经验证且可能是非整数的主键。这直接影响多维数据集中的查询性能。它还为您建立了一个理论上不灵活的数据仓库。例如，如果您有一个使用整数键的产品订购系统，并且您开始使用第二个产品订购系统来替代传统系统或与传统系统协同使用，则您可能难以仅通过DSV将数据组合在一起，因为每个系统具有不同的数据点、度量、工作流，数据类型等。更糟糕的是，如果订单id的数据类型相同，并且订单id值在系统之间重叠，则必须声明可以在两个系统之间使用的代理项。如果不使用扁平化的数据仓库，这可能很难实现，但并非不可能

如果从关系数据存储开始，然后移动到扁平数据库，则可能需要构建两次系统。坦率地说，我认为重复工作的数量是微不足道的。在关系数据存储中构建多维数据集所学的大部分内容将转化为设置新的OLAP多维数据集。不过，主要的问题是，您可能会创建一个新的多维数据集，然后旧多维数据集的任何用户都必须迁移到新多维数据集。任何在SSRS或Excel中构建的报告都可能会在此时中断，需要从头重写。因此，重建多维数据集的主要成本实际上是重建依赖对象，而不是重建多维数据集本身

---

如果你想让我进一步阐述以上任何一点，请告诉我。祝你好运。

你基本上是在问一个百万美元的问题“我如何构建DWH”。这并不是一个可以果断回答的问题

然而，这里有一个启动：

如果您正在寻找一种最低限度的可行产品，请注意，您所处的环境是数据环境，而不是纯软件环境。在数据密集型环境中，增量构建产品要困难得多，因为在系统中引入更改的工作量要大得多。想象一下，你在一个软件中所做的每一个改变都必须以某种方式与你所做过的任何事情向后兼容。现在您了解了Microsoft所处的地狱：-）

此外，数据系统还涉及许多第三方工具，如DBs、ETL工具和报告平台。您所做的选择对于系统的预期开发应该是可行的，否则您可能不得不完全替换这些工具

虽然您可以从基于简单复制SQL的DB克隆开始，然后将其聚合或推送到OLAP中，但我建议您从一开始就使用真正的ETL工具。如果你预见到增长的需要，这一点尤其正确。10次中有9次，需求会增加

如果您不介意成本的话，MS-SQL是DB的不错选择。自然的ETL工具是SSIS，它也是一个可靠的工具

---

即使您的第一次转换仅仅是“获取此表并将其转储到其中”，您仍然可以在流程管理（作业是否运行？如果失败会发生什么？等等）和调试方面获得很多好处。此外，由于需要处理需求和/或特殊情况，有机增长更容易。

请澄清pt。2.在我对OLAP多维数据集进行的稀疏实验中，使用现有的数据模型来构建多维数据集非常困难——在ETL工具中，数据是否通常必须“非规范化”为星形/雪花模式？我在第2点进行了扩展