数仓建模方法主要有哪三种 数据仓库数据建模的几种思路？
数据仓库数据建模的几种思路？
说起建模，不得不说两个牛人，一个是数仓之父-Inmon,他推崇的是er模型另外一个是kimball,推崇的是维度模型。其实两种建模，各有所长。er模型就是实体关系模型，对建模人员要求高，且实施周期长，建设完成后数据间关系清晰且无冗余，对保证数据的一致性和准确性有天然的优势，但是后期不能应对业务变化。维度模型，是将业务数据拆分成维度表与事实表，维度表主要用来存放一些公共的不随业务发展变化的数据，比如员工信息、合同信息等事实表用来存放一些维度表的键值和度量值，比如员工id、交易金额等。维度建模的时候不需要建模人员对全局的数据有了解，只需要对相关的数据了解就行，而且在面对业务变化的时候有天然的优势。另外还有Inmon在er模型上改进后的datavault模型，不过datavault不能简单的称做模型，算一种整体的解决方案。
数仓建模全流程？
1、建模流程
其实就是业务模型-gt概念模型-gt逻辑模型-gt物理模型的这样一个流程，下面我们详细解释一下各个模型阶段都要做什么
业务建模(需求沟通)
根据业务部门进行划分，理清部门之间的关系，然后将各个部门的具体业务程序化，与业务部门开会协商出需求的指标、保存年限、维度等等。
总体来讲，就是要知道他们需要哪些指标以及他们能提供哪些数据。
业务建模的时间最长，而且与公司实际的业务环境息息相关，因此在这里需要根据实际生产环境和业务需求确认好数据仓库使用的工具和平台。
主要解决业务层面的分解和程序化。搞清楚系统边界，确定好主题域
1
1
因此，业务建模阶段其实是一次和业务人员梳理业务的过程，在这个过程中，不仅能帮助我们技术人员更好的理解业务，另一方面，也能够发现业务流程中的一些不合理的环节，加以改善和改进。
概念建模|领域建模(画图想好怎么做)
将业务模型抽象化，分组合并类似的概念，细化概念，抽象出实体与实体之间的联系，理清各组概念之间的联系。
说白了就是画图，把指标需要的哪些数据封装到一个实体里，实体与实体之间的关联等等用ER图表示出来。
先画出局部ER图，最后再综合画出全局ER图。
主要是对业务模型进行抽象处理，生成领域概念模型
1
1
在原有数据库基础上建立了一个比较稳固完善的模型，因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。
数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。
概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。
领域概念建模就是运用了实体建模法，从纷繁的业务表象背后通过实体建模法，抽象出实体，事件，说明等抽象的实体，从而找出业务表象后抽象实体间的相互的关联性，保证了我们数据仓库数据按照数据模型所能达到的一致性和关联性
逻辑建模(表设计)
将概念模型实体化，具体考虑概念对应的属性，事件考虑事实属性，维度考虑维度属性。
总体来说就是建表，前面已经画出了关系图，这里只要将表里头有哪些字段考虑出来就可以，如果是事实表就考虑事实字段和业务主键，如果是维度表就考虑维度属性，SCD策略等等。在这里需要确定数据粒度，如果多个指标都用到一个字段，则取粒度最小的指标。如果不确定指标的量度，则取毫秒级作为粒度。
物理建模(建表)
综合现实的大数据平台、采集工具、etl工具、数仓组件、性能要求、管理要求等多方面因素，设计出具体的项目代码，完成数仓的搭建。
2、建模的过程
假设我们现在在构建一张订单表
从多个维度进行统计组合，形成多维度数据集，来从多个角度观察业务过程的好坏
1
1
选择业务过程
确认哪些业务处理流程是数据仓库应该覆盖的，是维度方法的基础。因此，建模的第一个步骤是描述需要建模的业务流程。例如，需要了解和分析一个零售店的销售情况，那么与该零售店销售相关的所有业务流程都是需要关注的。为了描述业务流程，可以简单地使用纯文本将相关内容记录下来，或者使用“业务流程建模标注”（BPMN）方法，也可以使用统一建模语言（UML）或其他类似的方法。
业务过程就是需要那种业务场景下产生的订单表(划分到那个业务线和数据域)
业务过程就是用户下单的订单记录表
选择数据域
申明粒度
粒度就是确认一条记录代表的含义或者是细化到何种程度(一条记录代表一个订单还是多个订单，如拼团的时候团长的单)
在选择维度和事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在一个事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用性的关键。
从给定的业务流程获取数据时，原始粒度是最低级别的粒度。建议从原始粒度数据开始设计，因为原始记录能够满足无法预期的用户查询。汇总后的数据粒度对优化查询性能很重要，但这样的粒度往往不能满足对细节数据的查询需求。
不同的事实可以有不同的粒度，但同一事实中不要混用多种不同的粒度。维度模型建立完成之后，还有可能因为获取了新的信息，而回到这步修改粒度级别。
确认维度
维度的粒度必须和第二步所声明的粒度一致。
维度表是事实表的基础，也说明了事实表的数据是从哪里采集来的。
典型的维度都是名词，如日期、商店、库存等。维度表存储了某一维度的所有相关数据，例如，日期维度应该包括年、季度、月、周、日等数据。
确认事实
这一步识别数字化的度量，构成事实表的记录。它是和系统的业务用户密切相关的，因为用户正是通过对事实表的访问获取数据仓库存储的数据。大部分事实表的度量都是数字类型的，可累加，可计算，如成本、数量、金额等。
3、模型设计的思路
业务需求驱动，数据驱动，构造数据仓库有两种一是自上而下，一是自下而上。
自上而下
Bill Inmon先生推崇“自上而下”的，即一个企业建立唯一的数据中心，就像一个数据的仓库，其中数据是经过整合、经过清洗、去掉脏数据的、标准的，能够提供统一的视图。要建立这样的数据仓库，并不从它需要支持哪些应用入手，而是要从整个企业的环境入手，分析其中的概念，应该有什么样的数据，达成概念完成整；
自下而上
Ralph Kimball先生推崇“自下而上”的，他认为建设数据仓库应该按照实际的应用需求，加载需要的数据，不需要的数据不要加载到数据仓库中。这种建设周期较短，客户能够很快看到结果。（针对客户的需求，需求要什么就做什么）
4、模型落地实现
按照命名规范创建表
开发生成维表和事实表的代码
进行代码逻辑测试，验证数据加工逻辑的正确性代码发布，加入调度并配置相应的质量监控和报警机制
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
