C C++最全维度建模的10大基本原则_引入新维度到模型要考虑，2024年最新C C++程序员进大厂面试必备基础技能

2401_84978645

于 2024-05-15 01:56:53 发布

阅读量434

点赞数 3

分类专栏：程序员文章标签： c语言 c++ 学习

本文链接：https://blog.csdn.net/2401_84978645/article/details/138879185

版权

40 篇文章 0 订阅

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

维度建模应该使用最基础的原子数据进行填充，以支持不可预知的来自用户查询的过滤和分组请求，用户通常不希望每次只看到一个单一的记录，但是你无法预测用户想要掩盖哪些数据，想要显示哪些数据，如果只有汇总数据，那么你已经设定了数据的使用模式，当用户想要深入挖掘数据时他们就会遇到障碍。当然，原子数据也可以通过概要维度建模进行补充，但企业用户无法只在汇总数据上工作，他们需要原始数据回答不断变化的问题。

业务流程是组织执行的活动，它们代表可测量的事件，如下一个订单或做一次结算，业务流程通常会捕获或生成唯一的与某个事件相关的性能指标，这些数据转换成事实后，每个业务流程都用一个原子事实表表示，除了单个流程事实表外，有时会从多个流程事实表合并成一个事实表，而且合并事实表是对单一流程事实表的一个很好的补充，并不能代替它们。

原则2中描述的可测量事件总有一个日期戳信息，每个事实表至少都有一个外键，关联到一个日期维度表，它的粒度就是一天，使用日历属性和非标准的关于测量事件日期的特性，如财务月和公司假日指示符，有时一个事实表中有多个日期外键。

在组织事实表时粒度上有三个基本原则：事务，周期快照或累加快照。无论粒度类型如何，事实表中的度量单位都必须达到相同水平的详细程度，如果事实表中的事实表现的粒度不一样，企业用户会被搞晕，BI应用程序会很脆弱，或者返回的结果根本就不对。

由于事实表存储的是业务流程事件的结果，因此在它们的外键之间存在多对多(M:M)的关系，如多个仓库中的多个产品在多天销售，这些外键字段不能为空，有时一个维度可以为单个测量事件赋予多个值，如一个保健对应多个诊断，或多个客户有一个银行账号，在这些情况下，它的不合理直接解决了事实表中多值维度，这可能违反了测量事件的天然粒度，因此我们使用多对多，双键桥接表连接事实表。

属性之间分层的、多对一(M：1)的关系通常未规范化，或者被收缩到扁平型维度表中，如果你曾经有过为事务型系统设计实体关系模型的经历，那你一定要抵抗住旧有的思维模式，要将其规范化或将M:1关系拆分成更小的子维度，维度反向规范化是维度建模中常用的词汇。
在单个维度表中多对一(M:1)的关系非常常见，一对一的关系，如一个产品描述对应一个产品代码，也可以在维度表中处理，在事实表中偶尔也有多对一关系，如详细当维度表中有上百万条记录时，它推出的属性又经常发生变化。不管怎样，在事实表中要慎用M:1关系。

更重要的是，编码和关联的解码及用于标记和查询过滤的描述符应该被捕获到维度表中，避免在事实表中存储神秘的编码字段或庞大的描述符字段，同样，不要只在维度表中存储编码，假定用户不需要描述性的解码，或它们将在BI应用程序中得到解决。如果它是一个行/列标记或下拉菜单过滤器，那么它应该当作一个维度属性处理。
尽管我们在原则5中已经陈述过，事实表外键不应该为空，同时在维度表的属性字段中使用“NA”或另一个默认值替换空值来避免空值也是明智的，这样可以减少用户的困惑。