Joh*_*ohn 5 extensibility database-design data-warehouse fact-table business-intelligence
我正在尝试建立一个数据集市.
我有很多维度和一些措施 - 事实.每项措施都与业务方面的所有维度相关联.有一种标准方法,将有一个包含所有措施的重要事实表.
但我有一个想法:如果每个度量都有单独的事实表,该怎么办？它将如何处理数据库性能,解决方案扩展性等？
编辑:::在非常复杂的企业环境中,基于olap立方体的巨大解决方案.因此,首先需要的是易于扩展和维护,然后是性能
悬崖笔记:我看到了一个事实表/度量概念的可扩展性问题.
如果您的目标是"可扩展性和维护性",那么您可以考虑遵循行业范围的标准方法......例如Kimball,首先按业务流程对事实进行分组,然后按照具有一致性维度的粒度进行分组.我很高兴地说,这将提供最大的灵活性和可扩展性,同时通过标准化确保可扩展性和维护.
另外,如果您为每个度量设计一个单独的事实表,那么您的SAN管理员会讨厌您的胆量,因为您通过度量数量有效地增加了空间需求...至少在最初所有度量当前适合单个事实表时.
针对DW的查询性能也将是一个问题......报告和/或即席查询将不得不扫描(或寻求... 如果您的管理员仍在与您交谈并且慷慨地给予您必要的帮助任何时候你需要组合多于1个度量的空间来正确索引你的事实表的垃圾.
我们还没有讨论olap立方体,但我已经害怕你将遇到的处理问题.全表扫描嘉豪...或分区扫描...如果你在事实表...你现在应该与地平线上的SQL 2012 ...我看着你列存储索引实现分区!