数仓建模 - 维度 vs 关系
复杂的数据关系
数据仓库模型建设
数据管理一直在演进，从早期的电子表格、蛛网系统到架构式数据仓库。发展至今以维度建模和关系建模为主，而随着互联网的发展，数据从GB到PB的裱花，企业业务迭代更新亦是瞬息万变，对维度模型的偏爱渐渐有统一互联网数仓建模标准的趋势。
数仓模型不分高下，都是一种观察现实的角度。维度模型以实体与实体之间发生的事务/实为切入，而关系建模则以实体与实体之间的关系来组织数据。在当前的环境下，互联网更倾向于维度建模，而传统行业则较多沿用关系建模。
个人先后经历金融、互联网数仓建设，有多个0到1的项目经历，对于数仓建设仍在持续学习中。如有错误之处，还请多指出交流。
模型理念
维度建模
以事实表为核心，多个维度表作为手臂形成的星型模型，是维度建模的典型实现方式。
事实表，记录业务过程中发生的可度量事件，如订单中的消费金额，折扣金额或是库存数量等，在实际业务中事实表占据主要的存储，如订单表；而维度表，则是对业务过程度量有关的文本环境，描述“谁、什么、哪里、何时、如何、为什么”，常用的维度表有日期、产品、用户、地址等。一般维度表会冗余信息，有超过100个列的维度表，这样的不规范化带来数据组织上的简单。
关系建模
关系建模，被称为“实体-关系”模型，以一种“标准化”的方式存在，强调数据之间非冗余，满足3NF。在建设过程中，将数据标准化到细节级数据，如用户主题下，会有用户与姓名、用户与年龄、用户与住址等。在传统行业中，成熟的关系建模有ls-ldm模型，面向金融行业形成10大主题。
建模实现的对比
维度建模：从实际的需求出发进行数据建设，一般面向部门/业务形成独立的数据集市，这样的方式带来鲜明的特点，高效。但由于基于需求出发，往往导致频繁的需求迭代带来的维护成本较高，一旦业务过程发生调整，模型有可能会重来的风险。
关系建模：面向企业进行模型建设，具有较强的抽象性。建设时以3NF的方式建设无冗余的数据，使模型具有很高的灵活性，但由于不能直接面向需求，效率上不如维度模型。另外面向企业建设，周期相比于维度建模，要长的多，但也有个好处：企业数据集成更容易。
模型选择
在企业内，这两种建模方式往往同时存在，基础数据仓库的建设使用关系建模，技术的优雅换来了数据的精简，保证高度抽象、高度一致性，要求业务稳定；往上维度建模更合适一些，偏向于直接面对业务，靠数据的冗余带来了可用性，保证查询效率。两者优势互补
Data Vault 简介
在大数据的环境下，数据存储和发展已发生很大变化，曾经的维度建模和关系建模在当前的场景下都有各自的不足之处。那数据仓库在大数据环境下如何发展、成熟？Inmon等就提出了data vault模型
data valult是一个面向细节的、历史追溯的并且唯一链接的规范化表集，能给支持一个或者多个业务功能区；是一种中心辐射式模型，其设计重点围绕着业务键的集成模式。data vault有三种基本的实体(结构)
- 中心表(Hub)：实际业务键的集合，如订单信息表等
- 链接表(Link)：记录着业务键之间的关系和联系，没有开始或者结束日期，只记录数据到达数据仓库那一时刻的关系的一种表达
- 卫星表(Satellite)：数据仓库概念的表，存储了随时间推移的非易失数据。
从建模风格上看，它采用了一种由第三范式方法与维度建模方法混合而成的方式，以二者的独特组合来满足企业需求。