第一部分
1前言
大家好，本文是详细介绍几个仓库系列的第四篇。
第一个是简介，后三个属于仓库设计部分：
数据仓库概述。在本文中，我简要介绍了数据仓库的基本概念和一般构建过程。我没有走太远，给你一个基本的了解。数据仓库架构，这部分决定了数据仓库的结构和边界。我们从四个不同的角度给大家带来了一个相对全面的宏观认识，当然我们还是需要一个部署架构。数据仓库规范约束了数据管理的全过程，以保证数据管理有序、高效、高质量的发展。第一部分是心理方法。我们简要说明了规范的重要性以及设计和着陆的方法。下一部分是动作。我们从四个不同的方向呈现一个完整的标准模型供您参考。数据模型可以说是数据仓库的基石，承载着数据存储的重要功能。第一部分主要介绍了数据建模的理论。我们先没有过多介绍数据仓库建模，而是从更大的角度来解释。在接下来的部分中，我们主要介绍数据建模在真实的仓库构建场景中的实践。
由于数据仓库建模的重要性，大部分关于数据仓库的文章都将被解释。当然主要是维度建模。一开始我以为这一章会讲三个范式，然后就结束了。因为大家已经讲的很好了，甚至我打算直接转载。
后来因为其他一些原因，7月份开了公开课《数据仓库的前世今生》，8月份翻看了一下DAMA2.0的一些内容，突然意识到数据建模不等于数据仓库建模。事实上，数据仓库建模只是数据建模的一个分支。除了范式建模和维度建模之外，还有其他几种建模方法，但是数据仓库建模很少使用。
既然这是一篇关于数据建模的理论文章，为什么不跳出数据仓库建模，从更大的角度展开呢？
2什么是模型？
说到模型，还有一个容易混淆的概念：什么是模型？
从字面上看，“模式”是一种标准，或者说是一种套路，“公式”是方式、方法和形式。当这两个词连接在一起时，它们可以被解释为可重用和可引用的方法和知识体系。
在互动百科中定义为：
模式是指从生产经验和生活经验中抽象和升华出来的核心知识体系。模式实际上是解决某一类问题的方法论。把解决某些问题的方法总结到一个理论层面，也就是模式。模式是一种引导。在良好的指导下，会帮助你完成任务，做出优秀的设计方案，达到事半功倍的效果。你会得到解决问题的最佳方案。
其实有些人会把模式误认为模型，你可以参考上面的定义来识别。
好了，回到正题。既然说建模，那么什么是模型呢？
现实中我们经常会听到各种各样的模型，数学模型、算法模型、数据模型、概念模型、记忆模型、领域模型、编程模型、行业研究模型。哈哈，是不是很乱！反正我是有点晕，但是能和模特联系起来的东西总给人一种高高在上的感觉。
模型是对现实客观事物的一种表征和抽象。可以是文字、图表、公式、计算机程序或者其他物理模型。可以说，模型是通过适当的过滤和适当的表达规则对对象实体的简洁模仿。通过这种模仿，人们可以认识所研究的实体的本质，便于人们从形式上分析和处理实体。
模型不仅可以描述物理对象，也可以描述虚拟对象。对实物的描述很容易理解，比如建筑模型、车模、飞机模型等。
以上解释不太好理解。好吧，看我下面的解释：
根据wiki的定义，模型是指对一个实际问题或客观事物和规律进行抽象后的形式化表达。
这里强调的是：抽象！模型可以简化人们的认知成本，帮助人们摆脱众多的细节和迷雾，认识客观事物。比如古代战争中用来讨论战术的军事沙盘，所有的情况都是地理上集中呈现在桌面上，给你一个直观全面的认识。
3什么是数据模型？
百度的定义：
维基MBA智库的定义：
通俗版的解释：
数据模型是现实世界或业务逻辑在数据层面上的投影，是以标准化的模式组织数据元素来模拟现实世界的信息框架和蓝图。
目的和功能：
方便人与人之间的信息传递和交流。通过数据模型便于人们了解现实世界。通过计算机算法模型和规则模型，可以预测客观虚拟事物的发展或轨迹。现实世界的虚拟事物被抽象成信息世界的逻辑模型，再转换成计算机世界的数据模型，而计算机能存储和识别的是物理模型。
总而言之，数据模型有以下目的：
以结构化、便捷的方式呈现给人们理解具体事实，如BI模型、分析模型等。有助于更好地理解业务，如业务模型、概念模型、领域模型和逻辑模型。根据样本数据或人们的经验猜测，建立模型来预测其他类似的事物或场景，比如算法模型。现实世界的信息被转换成数据模型，该数据模型被呈现给计算机，并可用于存储或计算，例如物理数据存储模型。
根据数据模型的用途不同，建模方法也大相径庭。所以我们在做数据建模之前，首先要想清楚模型的具体用途和场景。
我们所说的数据仓库建模，实际上就是建立一个数据存储模型，对我们日常业务活动或信息系统存储的有价值的数据进行结构化存储。
数据仓库建模的目的是利用数据建模方法帮助更好地组织和存储数据，从而达到性能、成本、效率和质量的最佳平衡。
性能，一个好的数据模型可以帮助我们快速查询所需的数据，减少110的数据吞吐量。成本，好的数据模型可以大大减少不必要的数据冗余，还可以实现计算结果的重用，从而大大降低大数据系统中的存储和计算成本。效率，一个好的数据模型可以大大提高用户使用数据的体验，提高使用数据的效率。质量好的数据模型可以改善数据统计口径的不一致性，降低数据计算错误的可能性。
高质量数据建模的重要性；
更低的存储成本，更高的查询效率，清晰的数据结构，易于理解和使用简化的ETL处理逻辑，更好的数据质量保证(一致性、准确性、完整性、及时性)，更灵活地应对变化，更好地满足客户需求。
4一般数据建模过程
研究阶段-概念模型-逻辑模型-物理模型-生产应用迭代
在调研阶段，需要做业务调研，需求调研，数据探索。
业务调研有助于我们了解业务，了解结合业务的需求。我们应该从一开始就根据需求设计模型。最后，需要结合业务和需求做数据探索，保证原始数据的现状能够满足现有和未来的业务需求。应用场景主要分为数据仓库建模、BI建模、算法建模等。不同的应用场景建模方法会有很大的差异。只有对业务、需求、数据和应用场景有足够的了解，才能设计出高质量的数据模型。
在构思阶段，我们必须做好以下工作：
注重对整体架构的整体理解和思考，确定系统的核心，划定系统范围和边界。与领域模型类似，在这个阶段，我们会对建模的范围、工作量和重点有一个整体直观的了解，同时确保与客户达成共识。需要确定该领域的基本和关键业务实体，同时给出实体间关系的描述。我们应该统一各种商业术语和命名惯例。我们要明确后面要用到的数据存储的类型(通常是某种数据库，下面我们会介绍)，因为不同的数据存储对应的逻辑模型设计可能会有很大的不同。
上图来自DAMA2.0，左边是关系概念数据模型，右边是维度概念数据模型。
在逻辑阶段，需要进一步细化概念模型确定的边界。
逻辑文档详细，需要添加所有实体属性，实体之间的关系要描述清楚，要使用术语，要遵循命名规范，项目文件要用Case工具创建，每个实体和关键属性都要描述清楚。模型不受底层实际存储数据库的约束，但是我们需要定义实体属性和实体之间的关系(这里是主键和外键关系，一对一或一对多或多对多关系)，实体和属性的备注，属性和约束的数据类型(null、非null、主键和外键约束)。我们应该遵循先标准化，后反向标准化的设计顺序。标准化的设计可以消除冗余，便于理解。反向标准化设计主要是为了使用方便，但一定不能把懒惰和不专业当成反向标准化。
上图来自DAMA2.0，仅供参考。在逻辑模型的设计中，关系模型设计思想和维度模型的区别是显而易见的。关系模型的设计侧重于捕获业务流程的规则。维度模型设计侧重于捕获业务问题，以确定业务流程的运行状态和性能。它是维度概念数据模型的完整属性透视图。
在物理模型阶段，主要针对不同的数据存储类型，根据逻辑模型，利用模型设计工具自动生成。
常用的模型设计工具有：PowerDesigner。对于主键和外键约束，我们可以在OLTP系统中生成它们，但它们通常不用于OLAP环境。建模工具可以直接生成模型设计交付文档、数据库建表报表等。根据物理模型。需要考虑未来的查询性能需求和存储空间占用情况。确定需要使用哪些约束、索引以及表字段备注的准确性和完整性。当然，之前很多时候，因为商业竞争，我们不在这里写备注。
生产和迭代。实物模型部署后，将逐步投入生产。随着业务的深入或变化，模型也需要优化和改进。高质量的车型更能适应未来需求的变化，但一劳永逸的车型几乎不存在。
5数据存储技术发展的三个阶段
如上所述，在概念模型设计阶段，我们应该确定使用哪种存储类型的数据库。
经过50多年的发展，数据存储经历了三个主要阶段。
第一阶段：数据库技术的诞生和三种模式的争论。
现在是进入20世纪60年代，雄心勃勃的美国人提出了登月计划，这在当时可能是件大事。但是要飞到月球上，你必须有一个交通工具。美国人以希腊神话中的太阳神命名这艘宇宙飞船。制造这艘飞船，我们可以利用美国庞大的社会资源，但这个超级复杂的东西有无数个零件，如何管理它们成了一个大问题。于是计算机界的百年老店IBM出来了，开发了一个软件叫ICS，专门用来管理这些零件信息。后来以此为基础，诞生了著名的IMS(信息管理系统)数据库。这是现代数据库的原型。直到今天，这个健壮的数据库还在银行的一些重要核心岗位上发挥着余热。
IMS数据库是基于层次结构的，从上到下搜索很容易，但是左右横向查询就不好用了。另一家老牌公司GE看到了这一点，并开发了一种新的基于网络的数据库IDS。这个看起来像蜘蛛网结构的数据库很快取得了不错的市场成绩。作为行业的领头羊，IBM自然不会坐视不管。在超级英雄EF的带领下。Codd(下图中，他获得了图灵奖)，他提出了关系模型。一、时间、层级、网络、关系三种关系模式杀暗。直到一种重要语言的出现，-SQL，改变了整个战局。这就是这样一种简单易懂的语言，可以很容易地描述战争态势的数据访问需求和平衡倾斜关系模型。后来聪明人聚集的加州大学伯克利分校开发了INGRES(现在的PostgreSQL)数据库，证明了关系模型是可靠的，从而结束了战争。
注：以上两段摘自CSDN文章：
https://blog.csdn.net/hzbooks/article/details/108480871
第二阶段：SQL语言促进了关系数据库的统治地位。
由于SQL超低的学习成本和关系数据库对SQL的天然支持，关系数据库迅速普及，几乎完全占领市场。和我们熟悉的数据库一样，基本上都是关系数据库。
第三阶段：新数据库百花齐放。
后来，随着互联网用户规模和数据量的不断增加，以及7X24小时在线的要求，传统关系数据库的性能随着数据量的增加而迅速下降，难以升级和扩展，扩展成本和数据规模呈指数级增长，这促使开发人员探索新的数据存储方式。
NoSQL(不仅仅是SQL)一般指非关系数据库。我们通常会根据不同的使用场景选择不同的NoSQL数据库，但由于它不支持SQL，大大增加了数据从业者的使用难度。好在后来有人想到在上面封装一层SQL解析器，加速了无SQL数据存储的快速普及，比如Hive，SparkSQL等等。其他不提供SQL查询或者SQL支持不到位的，几乎无法扩大影响力和知名度，有的甚至已经逐渐被淘汰。
尽管对SQL的开放支持使NoSQL数据存储受到欢迎，但仍有一些问题使其无法取代传统的关系数据库。近年来，随着分布式协议的成熟，人们找到了解决这些痛点的新方法。
NoSQL(不仅仅是SQL)一般指非关系数据库。我们通常会根据不同的使用场景选择不同的NoSQL数据库。但由于其对SQL的支持较弱，用户往往局限于技术圈，他们通常能提供相对完整的SQL支持能力。或者说，如果再加一层SQL的转换和分析，比如Hive，SparkSQL等等，就更容易普及到更广泛的数据从业者。
NewSQL是各种新型可伸缩/高性能数据库的缩写。这种数据库既具有NoSQL存储和管理海量数据的能力，又保持了传统数据库支持ACID和SQL的特点。
NewSQL系统是为了满足集成NoSQL和关系数据库的特点而提出的。其中，NoSQL提供可扩展性和高可用性，而传统的RDBMS提供关系模型、ACID事务支持和SQL。用户不再考虑一个可以解决所有问题的解决方案(一刀切)，逐渐转向为OLTP等不同的工作负载提供特定的数据库。大多数NewSQL数据库都是全新的，要么侧重于OLTP，要么采用OLTP/OLAP的混合架构。
什么样的数据库可以称之为NewSQL？它应具有以下基本特征：
SQLACID交易，支持跨行交易自动伸缩可伸缩性自动故障转移
最后一张图有点搞笑，但是真的，就一个数据管理系统而言，得SQL者得天下，因为不支持SQL很难普及。SQL是最伟大的语言，数据从业者的最爱，不接受反驳，哈哈。
6数据建模方法有哪些？
上表是DAMA 2.0给出的建模方法和数据库跨应用模式。
在数据建模阶段，我们需要根据不同的应用场景选择合适的建模方法和数据存储。同时，还需要根据数据存储的不同类型来调整建模方法。比如在关系数据库中实现的范式模型就是星型模型，在多维数据库环境中实现的维度模型通常称为联机分析处理数据库。
关系建模
关系模型是由EF提出的。1970年IBM研究院的Codd，后于1971年提出范式理论。
关系模型又叫范式建模，因为其原理的核心是“规范化”的思想，即在保证数据存储完整性的同时，尽量减少冗余数据的结构化过程。
范式是符合一定层次的关系模式的集合。目前关系数据库中有六种范式：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、Boyce-Codd范式(BCNF)、第四范式(4NF)和第五范式(5NF)。
规范化本质上是拆分数据存储结构。范式级别越高，分割越精细。同时，标准化程度越高，冗余度越低，但会给具体查询带来负担。所以在实际操作中，我们通常会用到第三范式。
除了标准化之外，我们在对关系建模时也使用ER模型，即由美籍华裔计算机科学家陈品山提出的实体-关系模型。它是一种数据模型或模式，用于概念性数据模型的高级描述。
ER模型将现实世界抽象成不同的实体，每个实体具有不同的属性。实体之间的关系称为关系，分为三种(1:1，1:n，m:3)。
ER模型和规范化理论共同构成了关系建模理论，OLTP系统基本上都使用关系建模。
示例1: ER模型
下面是学生-课程-老师实体关系图的网上摘录，供大家参考。
假设每个学生修几门课，每个学生每门课只拿一个成绩。每个老师只教一门课，一门课由几个老师教。“学生”有属性：学号、姓名、地址、年龄、性别。“教师”有属性：员工号、教师姓名、职称，“课程”有属性：课程号、课程名称。
示例2:标准化
上面提到的标准化的主要实现方案是拆分，下面是一个集团公司合作伙伴的实体-关系-属性的临时样本。写作很简单，只要你能理解这个问题。
由于供应商和客户既有共同属性，又有独特属性，集团客户分为内部客户和外部客户。为了减少冗余，我们需要设计父子两种类型的实体，将共享的属性抽象为父实体。
另外，公司和供应商之间会有采购合同，采购合同要和供应商实体分开。
维度建模
联机分析处理的概念是由关系数据库之父E.F.Codd于1993年首先提出的。Codd提出了多维数据库和多维分析的概念，将业务系统为业务逻辑和事务添加、删除、查询而设计的存储结构，转化为面向分析、以查询为中心的多维分析存储结构。所有对象都被抽象为三个类别：维度、度量和属性：
维度可以理解为不同的分析视角。属性用于定义和描述维度。度量是由一个或多个维度定义的值。
有两种存储格式：
关系OLAP(ROLAP):基于关系数据库的OLAP实现。详细数据和聚集的粗粒度数据通常存储在关系数据库中。OLAP(MOLAP):有时候立方体是可以被构造的。优点是好用，缺点是占用存储空间大。
以上两段是数据仓库系列开头的两段摘录。
我发现了一件有趣的事情。关系建模和维度建模的理论应该是同一个人(关系数据库之父E.F.Codd)提出来的。维度建模比关系建模晚出现20年。这20年恰好是信息化从起步到普及的阶段。存储在OLTP系统中的数据开始有了分析和应用的需求和场景。然而，OLTP数据库在分析和处理海量数据时存在很多缺点，如大量的资源消耗和性能问题。
在此背景下，关系模型的创始人提出了维度模型和多维分析数据库，将客观世界抽象为维度-属性-度量三个概念，从而构成了维度模型。
维度模型在关系数据库中实现时，通常称为雪花模型或星座模型，经过逆三范式或逆归一化后成为星型模型。
当维度模型在多维分析数据库中实现时，称为联机分析处理数据库。在OLAP多维数据库中，维度数据所涉及的格式和技术被用来索引这些数据的存储。性能汇总或预计算汇总表通常由多维数据库引擎建立和管理。由于预先计算、索引策略和其他优化方法，多维数据库可以实现高性能查询。
在NoSQL数据存储类型中实现维度模型时，由于索引的缺失和Join实现的低性能，维度模型会退化为星型模型甚至不被建模，即直接粗暴地加宽表。
在NewSQL数据存储类型中实现维度模型时，慢慢回归到最早的关系数据库的星型模型、雪花型模型或者星座型模型，比如最近流行的Doris。
其他建模方法
DAMA 2.0给出了另外四种类型的数据建模方法：面向对象、基于事实、基于时间和非关系。
但由于这些建模方法都有各自的局限性，适用场景有限或者难以学习和理解，在生产实践中也没有用到，这里就不介绍了。有兴趣可以参考DAMA 2.0或者百度。
第二部分
第一部分主要阐述了数据建模的理论知识，介绍了数据建模的过程和常用的建模方法。
本文基于上一篇文章的建模理论，结合真实的仓库场景，为您介绍完整的仓库建模流程。
1仓库建模在仓库建设过程中的地位
这张截图来自之前从0到1构建数据仓库的经验。它采用的是瀑布模式，但在实际操作中，往往采用的是螺旋迭代模式，因为很难有人一步考虑到所有的细节。
通过业务调研，我们熟悉了相关的业务流程。通过需求调研，我们明确了现阶段数据建设的要求、内容和边界。数据研究，也就是数据探索，对所需的数据来源做了整体的安排。如果不清楚，就要迅速找出错在哪里，如果缺失了，就要想办法弥补或者补救。如果真的缺失了，就应该停止项目或者至少重新规划。我们只是数据的搬运工，不可能凭空捏造数据…
然后，根据研究阶段的结果，我们进行了五个主要的架构设计，实施了技术选择，制定了仓库规范，并分发到所有参与者。
接下来，我们进入了仓库建模阶段，这个阶段对仓库建设的成败起着决定性的作用。
我经常把数据仓库比作一个可以自己运行的生态系统。当然，我们把它比作人类是最合适的：人需要吃饭，需要清点仓库，需要周期性的去源头获取数据。人有大脑和中枢神经控制身体，有作息时间控制全局。人有骨骼肌，仓库的骨骼肌就是数据模型。
数据仓库模型承担着数据存储的重要功能，我们需要从全局的角度进行设计，因为它本身就是一个整体。有手有脚的数据仓库模型要分成很多不同的部分，这样人的手、脚、身体、大脑才能正常工作，数据模型的不同部分也需要很好的工作。人体的肌肉和脉络堵塞了，人就会生病，所以Inmon的数据建模思路侧重于整体思考和统一设计，Kimball的数据建模思路提出了总线架构，殊途同归，实际上是为你提供了一套整体设计方法论，打通数据模型甚至仓库运作的奇八脉。
2探索数据仓库建模中理论与实践相结合的方法
前两页是之前的PPT，供你参考。
经过几十年的理论研究、实践探索和各种方法论的碰撞，国外很多数据从业者终于给我们留下了一套完整的方法论。实际上，两种权威理论包含了两种不同的方法论：数据仓库构建方法和数据仓库建模方法。
In的仓库构建方法论提倡自上而下的瀑布式构建过程。其数据仓库模型设计的出发点是整合数据，从整个企业的角度整合各个系统中的数据，打通所有数据源，消除冗余、错误和不兼容，采用标准化的模型设计方法，统一存储企业的所有数据，为数据分析和决策服务。但是这种标准化的模型设计方法并不适合分析决策的场景，所以后来在此基础上增加了新的数据集市来支持各部门的业务应用。
标准化的设计可以减少冗余，避免数据不一致，全局兼容、完整的设计可以保证数据的完整性。但这种建模方式对建模人员的能力要求非常高，还需要对企业业务和数据有全面深入的了解。业务简单好做，但对于复杂的业务场景，必然会拉长建设周期，大大增加模型设计的难度，以至于一开始用这种方法实现的数据仓库大多以失败告终。
Kimball的数据仓库构建方法提倡自下而上的构建，而不是构建复杂的数据仓库，直接构建集市来支持业务需求。然而，当有更多的数据集市时，在多个数据集市之间会引起混乱和不兼容。为了解决这一问题，总线体系结构的概念被提出。总线架构由两部分组成：一致性维度和一致性事实。我们集中设计和管理所有维度，统一定义所有指标，然后让所有数据集市都符合这个一致性维度和一致性事实。
因为数据集市是直接构建的，不需要太多的数据集成，所以Kimball的构建方式会比Inmon的简单很多。虽然总线架构解决了多个数据集市之间的兼容性问题，但是这种建模方法仍然存在以下两个问题：1 .模型的稳定性完全取决于建模者对业务场景和分析需求的理解。2.完全基于业务需求的建模会丢弃需求“不需要”的数据，导致数据丢失。本质上，这是违背仓库建设原则的，所以我们需要永久保存ODS层的数据，以保证将来需要的时候有办法检索到。
最好是练真知识，适合自己的。
其实我们并不局限于某一种建模方法。我们需要根据各种建模理论和实际的业务场景来选择合适的方法。
上图是我们常规的仓库建模流程，接下来我会一一给大家讲解。我们主要采用统一调查、统筹规划、分散设计、集中评价的建设思路，自上而下与自下而上相结合的设计方法。
注意：这里的顶和底不是架构图的顶和底，而是数据流的上游和下游。我们称之为上游数据源和下游数据应用。
通过三步研究，我们了解了业务流程，明确了短期和中期需求，对源头的数据质量和存储格式有了清晰的认识。
经过三步调查，我们将制定一个数据仓库的层次结构，逻辑上分为三层：ODS、DW和DM。目前常用的四层、五层甚至七层，本质上都是这三层的细化。例如，在ODS层之前可以有一个STG层。STG英文翻译staging，也叫stage，是一个临时的数据存储区。数据源提取或上传的数据(通常是增量的)会先暂存在STG中，ETL会简单的清理、合并、转换后再存入ODS层。DW层还将细分为DWD、DWS等。当然，建立一个主题广泛的表格是可能的。宽表需要细分为明细宽表和汇总宽表吗？宽表应该属于DW还是DM？当然，你可以把它放在任何地方。只要合乎逻辑，这些都不重要。
分层架构出来后，我们会根据每一层的不同用途进行有针对性的建模。
ODS层、原始数据存储区、存储结构与源一致。原则上不需要清洗和转换。命名：数据源的原始名称，数据保留时间取决于下游。如果在ODS-DW过程中没有丢失任何信息，则只能保存3-7天。停留时间越短，对运维人员的要求越高。如果这个过程是可信的
息丢失为防止万一 ODS 层需要永久保留，保留策略有很多，比如从时间上划分为冷热数据冷数据可以归档转移到更便宜的存储，比如对数据内容上进行归类对于一段时间后就失去价值的数据直接删除即可例如系统运行日志。
DW 层，数据仓库的核心存储层，这一层数仓建模的核心，相对标准的思路是我们在明细层采用范式建模的思路自顶向下设计把 ODS 层的数据完整的整合进来，打破孤岛（ID 映射）、消除冗余，再往上层可以采用维度建模的思路，基于 DWD 层做轻度汇总、重度汇总，主要以满足业务需求为主，后期如有需求新增或变化可以基于 DWD 层的完整数据重新汇总。DW 层的数据是需要长期保留的。
当然在大数据场景下，我们通常需要考虑存储和计算开销，会去评估这些成本投入是否产生了足够的价值，明细层往往也会采用维度建模而且完全面向需求去设计，就是说短期用不到的数据我们就先不引入 DW 层了，等需要的时候再根据原始数据算。
这里需要说明一下，数据丢失远比计算错误更需要引起大家重视。由于某些原因很多大数据从业者没有认识到数据丢失的惨重后果。记得之前有一次为了降低成本老板甚至让删除一年之前的原始归档数据，结果没几天新的需求 DW 层无法满足需要重刷历史数据，幸好当时我们找借口拖着没删。
DM 层，数据集市层在逻辑上会包含多个数据集市。DWS 层汇总的通常是公用的、经常被使用的数据，绝大多数常规业务也都可以基于 DWS 直接实现，满足不了的时候我们需要根据各部门或者项目的需求去重新组织构建对应的数据集市，这一层通常也是采用维度建模方法自下而上完全面向需求去设计，数据集市往往伴随着对应的部门或项目需求而建立或者终止。
这里先做个简单的总结：
ODS 不用建模直接用源端数据存储结构。DWD 范式建模，保证 ODS 到 DW 信息不丢失，如果 DWD 也采用维度建模 ODS 数据一定要长期保留。DWS 维度建模面向需求设计，存储一些全域经常被使用到的数据。DM 完全面向需求建模，生命周期跟对应需求的生命周期一致。
横向分层讲完了，那我们接下来聊聊纵向分域吧。
分域的目的是为了给数据或表进行归类，从而方便数据管理。分域的概念也主要用在 DW 和 DM 层。DW 层主要面向业务过程划分数据域，数据域下边再划分多个主题，主题下边会有多个业务过程，理论上每个业务过程对应一张表，但当所有表设计好以后需要结合 ETL 过程和业务使用习惯考虑是否需要对多张表进行合并操作。DM 层划分数据域的方式就简单了，完全对应需求场景或者使用部门就好了。
分层和分域的概念讲完后，我们接下来需要制定相应的模型设计和使用规范。具体到落地阶段了，那么很多事情我们就必须把它明确下来，上边我们提到的内容在具体细节上可能会有多种选择，比如 ODS 数据保留策略、DWD 采用何种建模方法、有无主题宽表以及宽表归属哪一层等等，这些都需要通过规范去明确从而避免多人协作过程中的混乱。更具体的内容可以参考文末推荐阅读里的相关历史文章。
对于一致性维度、一致性事实的保障策略，也需要通过规范去明确和约束，确保同一个维度或度量在数仓的所有地方有相同的含义。我们也要通过规范教会大家如何才能建设出来统一高质量的数据模型。
以上的统一调研、整体规划（分层架构、规范制定、主题域划分）后，我们进入了分散设计的阶段。
分散设计
到这里，由于数仓模型设计的复杂性，我们需要多人合作共同完成建模工作，这时候架构师或者建模师可以结合之前分层分域的成果，按层按域将模型设计任务进行拆解后分发给不同的人完成。我们通常可以这样拆分：ODS 层可以按源端类型拆分、DW 层可以按数据域分成多块、DM 层就按数据集市拆分。这样核心建模师只需要完成 DW 层即可，每人分别负责不同的数据域，ODS 层甚至可以分配给 ETL 工程师负责这样刚好顺便熟悉了源端存储结构以及对数据质量的探查，DM 层完全可以分配给 BI 工程师通常会开发成单表查询的模式。这样子做完分工后，在模型设计规范的统一指导和架构师或总建模师的协调下，相信最终是可以设计出一套统一完善且相互兼容的数仓模型的。
统一评审
虽然我们有完善的模型设计规范做指导，但考虑到各个部分建模者的不同情况，设计上难免会有疏漏，这就需要最终的统一评审环节。我们可以逐层分域的去评审，参与方主要有以下角色：架构师、总建模师、该模块主建模师、业务专家、数据运维、ETL 工程师。
交付与迭代
统一评审结束后，我们最终会形成一套完整的数据模型设计文档，通常是逻辑模型。
我们根据逻辑模型生成物理模型，然后交付给 ETL 工程师负责后续的数据开发。我们通常需要 ETL 工程师除了具备基本的开发能力外，还要有一定的数据探查、数据建模能力，确保在数据开发阶段能够发现原有模型设计的不足并及时反馈，比如现有模型如果使得 ETL 开发变的异常复杂或者程序性能低下，这时候通常就需要考虑修改模型设计了。我们经常使用的维度退化和宽表“模型”就是最常见的为了提高程序执行效率而做的规范化方面的妥协。
军事建模与仿真
仿真技术作为一种计算机技术，在构建和体验仿真世界中发挥着越来越重要的作用。现在，仿真技术广泛应用于航天技术、工业设计、军事教学和技术培训等领域。环球网军事今天发布的这篇文章主要介绍了仿真技术在军事领域的应用，包括其发展、应用现状及其未来前景。
21世纪，战争少了，但军事训练不能懈怠。虚拟现实技术的应用对没有实战的军事仿真具有重要意义。长期以来，仿真技术一直在军事训练中发挥着重要作用，它更接近一体化联合作战和指挥训练仿真的特点。其目标是建立一个集成的、一致的和可互操作的虚拟作战环境。计算机模拟使军事训练更有针对性和真实性。前者的典型代表是美军提出的高层架构HLA，使训练者在和平时期能体验更真实的战场感受。因此，利用新的仿真技术提高军事训练的有效性，已经成为信息时代各国军队面临的共同问题。在军事领域，基于建模与仿真的作战指挥和军事训练已经显示出巨大的军事和经济效益。
首先，仿真技术使军事装备的组织、作战指挥和模拟训练变得更加容易。军事训练可以在实验室条件下进行，训练的组织实施不受时间和气象条件的限制。分布式训练模拟系统甚至可以让来自不同地方的参与者一起参与训练。由于利用计算机仿真进行军事训练的巨大优势和潜力，世界主要发达国家都非常重视建模与仿真技术的发展。目前，仿真技术在作战指挥和军事训练中的应用主要包括四个方面：
第一，仿真技术。作战模拟可分为几种类型，如野战军事演习、野战实验、沙盘作战、地图作战、战争对抗、计算机模拟等。利用虚拟现实技术，不仅为研究战争提供了科学的方法，使研究过程更加逼真，更加贴近实战，实现了作战过程的模拟，而且使研究结果更加可信，从而有助于提高指挥艺术和作战技能。计算机模拟是将对抗的全过程结构和大部分规则预先编入计算机程序，然后用计算机语言描述战斗过程，并由计算机进行处理的一种新的模拟方法。
第二，模拟武器装备。训练是培养人员掌握武器装备操作和战术运用的主要手段。计算机仿真在装备训练中的研究和应用起步较早，技术相对成熟。训练模拟的主要载体是各种训练模拟器和系统，如飞行训练模拟器、炮兵模拟训练系统等。通过虚拟的作战环境和模拟的作战过程，训练者可以快速掌握宝贵的作战技能和经验，生动的视觉、听觉甚至动作感受也可以让训练者获得真实的作战经验。
第三，指挥训练模拟。培训的主要对象是部门领导、参谋和其他政府人员。培训内容主要包括地图绘制、消防协同、情报合成等专项业务技能和流程。因此，很容易有针对性地设计具体的作战场景，高效、便捷、经济地提高政府机关受训人员的专业素质。以某国航空兵模拟系统为例，该系统除了具备“空中格斗”中的“引导指挥口令自动识别”、“模拟飞行员语音报告空情”等主要功能外，还具备“模拟实战拦截”、“人员训练管理”等多项功能。试行期间，飞行引导员的培训周期缩短了近一半。
第四，联合作战模拟。联合作战的最新定义包括：信息优势、精确打击力量、战斗识别、战区联合导弹防御、城市军事行动、联合战备、联合反水雷、电子战、信息战、检测生化制剂、实时后勤管理、防止大规模杀伤性武器等。为了实现这一目标，在联合作战和战场环境的模拟中加入了图像增强、激光、红外、热传感器和扫描、多光谱、高光谱等军用光电视觉成像模拟效果。这些效果可应用于飞行部队的夜视镜、观测仪、瞄准镜、飞行员、夜视镜，以及地面部队的微光电视。海军近战武器系统的仿真丰富了军事仿真的内容，提高了监视、侦察和跟踪仿真训练的沉浸感和构想性。
仿真技术的创新推动了军事训练的发展，信息化条件下的作战指挥和军事训练对仿真技术提出了新的要求。由中国仿真学会、国际建模与仿真学会、亚洲仿真联盟联合主办的首届世界仿真技术应用展览会(简称“世界仿真展”)将于2016年10月9日至11日在北京国家会议中心举行，携手载人航天、北京仿真中心、国防科技大学、清华大学、北京航空航天大学、AVIC双兴、华如科技、数字冰雹、海信金科等庞大阵容为您带来全新军事训练。有理由相信，随着信息技术的不断发展和进步，仿真技术的创新将在未来的作战指挥和军事训练中大放异彩。