简单讲，就是明确具体业务，抽象实体和关系，结合具体的建模方法，确定所有关键成分和属性，最后建数据表进行数据的存储和计算。
目前数据建模的方法论有两大阵营，一个是基于关系型数据库理论设计出来的，比如基于3NF的范式建模。虽然目前也有不少非关系型数据库以及不少半结构化和非结构化数据。但将半结构化/非结构化数据转化为结构化数据，然后再利用关系型数据库处理仍然是一种通用的主流数据处理方案。
另一个是基于数据仓库之父BillInmon提出的维度建模理论，是从全企业的高度利用实体关系来对企业业务进行描述。
通常我们将操作型系统简称为OLTP（On-LineTransactionProcessing）—联机事务处理，将分析型系统简称为OLAP（On-LineAnalyticalProcessing）—联机分析处理。
针对这两种不同的数据用途，如何组织数据，更好地满足数据使用需求。这里就涉及到数据建模问题。即设计一种数据组织方式（模型），来满足不同场景。在OLTP场景中，常用的是使用实体关系模型（ER）来存储，从而在事务处理中解决数据的冗余和一致性问题。
在OLAP场景中，有多种建模方式有：ER模型、星型模型和多维模型。下面分别说明下：
1、ER模型OLAP中的ER模型，与OLTP中的有所区别。其本质差异是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。
2、星型模型
星型模型，是维度模型在关系型数据库上的一种实现。该模型表示每个业务过程包含事实表，事实表存储事件的数值化度量，围绕事实表的多个维度表，维度表包含事件发生时实际存在的文本环境。
3、多维模型多维模型，是维度模型的另一种实现。当数据被加载到OLAP多维数据库时，对这些数据的存储的索引，采用了为维度数据涉及的格式和技术。性能聚集或预计算汇总表通常由多维数据库引擎建立并管理。由于采用预计算、索引策略和其他优化方法，多维数据库可实现高性能查询。
02维度建模
维度建模，是数据仓库大师RalphKimball提出的，是数据仓库工程领域最流行的数仓建模经典。
维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。
它是面向分析的，为了提高查询性能可以增加数据冗余，反规范化的设计技术。
1、事实表
事实表产生于业务过程，存储了业务活动或事件提炼出来的性能度量。从最低的粒度级别来看，事实表行对应一个度量事件。
事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表。
事务事实表，用于承载事务数据，通常粒度比较低，它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表，例如产品交易事务事实、ATM交易事务事实。
注意：这里需要值得注意的是，在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。
2、维度表
退化维度（DegenerateDimension）
在维度类型中，有一种重要的维度称作为退化维度，亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。
缓慢变化维（SlowlyChangingDimensions）
SCD常用的三种处理方式：
①TYPE1直接覆盖原值
②TYPE2增加维度行
在为维度成员增加新行时，需为其分配新的主代理键。并且，至少需要在维度行再增加三列：有效日期、截止日期、行标识。这个地方可联想拉链表设计。
③TYPE3增加属性列
④混合方式
可根据实际业务场景，混合或选择使用以上三种方式，以快速方便而又准确的分析历史变化情况。
3、粒度
用于确定某一事实表中的行表示什么，是业务最小活动单元或不同维度组合，即业务细节程度。
4、维度建模流程
由于在维度建模过程中，涉及到很多概念。下面通过一个场景来，来一一说明。例如：常见的电商下单环节，每个用户提交一笔订单（仅限一个物品），就对应于一条订单记录。
【业务过程】：下订单【粒度】：每笔订单（拆分为单个物品）【维度】：地域、年龄、渠道等（可供分析的角度）【事实/度量】：订单金额等（可用于分析的数据）
维度建模的步骤如下：
（1）收集业务需求与数据实现
在开始维度建模工作之前，需要理解业务需求，以及作为底层源数据的实际情况。通过与业务方沟通交流、查看现有报表等来发现需求，用于理解他们的基于关键性能指标、竞争性商业问题、决策制定过程、支持分析需求的目标。同时，数据实际情况可通过与数据库系统专家交流，了解访问数据可行性等。
（2）选择业务过程
（5）确认维度（描述环境）
维度提供围绕某一业务过程事件所涉及的"谁、什么、何处、何时、为什么、如何"等背景。维度表包含分析应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度，就能够将所有可能存在的维度区分开来。
（6）确认事实（用于度量）
（7）部署方式-星型模型或多维模型
选择一种维度模型的落地方式。既可以选择星型模型，部署在关系数据库上，通过事实表及通过主外键关联的维度表；也可以选择多维模型，落地于多维数据库中。
03维度建模方法论
数据仓库建模方法论可分为：维度建模、范式建模、DataVault模型、Anchor模型。
1、维度模型
企业中最流行、也是最经典的数仓建模经典，数据仓库大师RalphKimball的经典著作《数据仓库工具箱维度建模权威指南第三版》一本书进行了论述。从事数据仓库/ETL/BI的同学，强烈建议买一本至少读一遍。
按数据组织类型划分可分为星型模型、雪花模型、星座模型。
（1）星型模型
星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。
（2）雪花模型
雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。这种模型维护成本高，性能方面也较差，所以一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。
（3）星座模型
星座模型，是对星型模型的扩展延伸，多张事实表共享维度表。数仓模型建设后期，大部分维度建模都是星座模型。
2、范式模型
即实体关系（ER）模型，数据仓库之父Immon提出的，从全企业的高度设计一个3NF模型，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF。此建模方法，对建模人员的能力要求非常高。
3、DataVault模型
DataVault由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性）三部分组成，是DanLinstedt发起创建的一种模型方法论，它是在ER关系模型上的衍生，同时设计的出发点也是为了实现数据的整合，并非为数据决策分析直接使用。
4、Anchor模型
高度可扩展的模型，所有的扩展只是添加而不是修改，因此它将模型规范到6NF，基本变成了K-V结构模型。一般很少使用，本文不多做介绍。
04建模规范
以维度建模为理论基础，定义一系列术语来描述建模对象。下图摘自于《阿里巴巴大数据实践之路》。
数据域
指面向业务分析，将业务过程或者维度进行抽象的集合。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。
业务过程
指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程是一个不可拆分的行为事件，通俗地讲，业务过程就是企业活动中的事件。
修饰类型
是对修饰词的一种抽象划分，是从属于某个业务域的。
修饰词
指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于一种修饰类型。
度量/原子指标
原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。
维度
维度属性
维度属性隶属于一个维度，如地理维度里面的国家名称、国家ID、省份名称等都属于维度属性。
派生指标
数据层次的划分：
ODS：OperationalDataStore，操作数据层，在结构上其与源系统的增量或者全量数据基本保持一致。它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。其主要作用是把基础数据引入到MaxCompute。
CDM：CommonDataModel，公共维度模型层，又细分为DWD和DWS。它的主要作用是完成数据加工与整合、建立一致性的维度、构建可复用的面向分析和统计的明细事实表以及汇总公共粒度的指标。
DWD：DataWarehouseDetail，明细数据层。
DWS：DataWarehouseSummary，汇总数据层。
ADS：ApplicationDataService，应用数据层。
具体仓库的分层情况需要结合业务场景、数据场景、系统场景进行综合考虑。
数据分类架构
该数据分类架构在ODS层分为三部分：数据准备区、离线数据和准实时数据区。在进入到CDM层后，由以下几部分组成：
公共维度层：基于维度建模理念思想，建立整个企业的一致性维度。
明细粒度事实层：以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当的冗余，即宽表化处理。
公共汇总粒度事实层：以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段来物理化模型。
数据处理流程架构
数据划分及命名空间约定
按业务划分：命名时按主要的业务划分，以指导物理模型的划分原则、命名原则及使用的ODSproject。例如，按业务定义英文缩写，阿里的“淘宝”英文缩写可以定义为“tb”。
按数据域划分：命名时按照CDM层的数据进行数据域划分，以便有效地对数据进行管理，以及指导数据表的命名。例如，“交易”数据的英文缩写可定义为“trd”。
按业务过程划分：当一个数据域由多个业务过程组成时，命名时可以按业务流程划分。业务过程是从数据分析角度看客观存在的或者抽象的业务行为动作。例如，交易数据域中的“退款”这个业务过程的英文缩写可约定命名为“rfd_ent”。
数据模型
模型是对现实事物的反映和抽象，能帮助我们更好地了解客观世界。数据模型定义了数据之间关系和结构，使得我们可以有规律地获取想要的数据。例如，在一个超市里，商品的布局都有特定的规范，商品摆放的位置是按照消费者的购买习惯以及人流走向进行摆放的。
数据模型的作用
数据模型是在业务需求分析之后，数据仓库工作开始时的第一步。良好的数据模型可以帮助我们更好地存储数据，更有效率地获取数据，保证数据间的一致性。
模型设计的基本原则
建立核心模型与扩展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化或是少量应用的需要。在必须让核心模型与扩展模型做关联时，不能让扩展字段过度侵入核心模型，以免破坏了核心模型的架构简洁性与可维护性。
底层公用的处理逻辑应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑在多处同时存在。
适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
相同的字段在不同表中的字段名必须相同。
表命名规范需清晰、一致，表命名需易于下游的理解和使用。
（8）补充说明
一个模型无法满足所有的需求。
需合理选择数据模型的建模方式。
通常，设计顺序依次为：概念模型->逻辑模型->物理模型。
维度表设计要点：
维度的作用一般是查询约束、分类汇总以及排序等。维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成的维度属性的优劣，决定了维度使用的方便性，成为数据仓库易用性的关键。正如Kimball所说的，数据仓库的能力直接与维度属性的质量和深度成正比。
在整个设计过程中，应当遵循下面一些原则：
维度属性尽量丰富，为数据使用打下基础。
给出详实的、富有意义的文字描述。
沉淀通用维度属性，为建立一致性维度做好铺垫。
严格区分事实与维度，通过使用场景进行区分。
事实表设计要点：
事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。在设计过程中，可以选择不同类型的事实表，它们有各自的适用场景。
选择一种适合的事实表类型。
事实尽可能完整，包含整个业务过程的全部事实。
确保每一个事实度量都是一致性，反复计算都会得到相同的结果。尽量记录一些“原子”事实，而不是加工后的结果。
可适当做些”维度退化属性”，提高事实表的查询性能。
为提高聚合性能，可适度做些上卷汇聚事实表。
05建模工具
1、PowerDesigner
PowerDesigner是目前数据建模业界的领头羊。功能包括：完整的集成模型，和面向包含IT为中心的、非IT为中心的差异化建模诉求。
支持非常强大的元数据信息库和各种不同格式的输出。PowerDesigner拥有一个优雅且人性化的界面，非常易懂的帮助文档，快速帮助用户解决专业问题。
2、ER/Studio
ER/Studio是一个支持多平台环境的直观数据建模工具，并且本地集成了用于处理大数据平台，例如-MongoDB和HadoopHive。
它能够进行正向和逆向工程，并且拥有“比较合并”功能，能够输出例如XML、PNG、JPEG等格式文档。内建自动执行任务功能支持当前流行数据库平台。ER/Studio功能非常强大，拥有直观的界面和很好的用户支持特别易于马上开始工作。
3、SparxEnterpriseArchitect
EnterpriseArchitect是一个拥有丰富功能的数据建模工具。自诩是高性价比的明智之选。EnterpriseArchitect帮助企业用户快速建立强大的可维护的系统，而且很容易在共享项目中扩展到大型的协作团队中去。
EnterpriseArchitect同样有动态运行模拟模型的能力，用以验证模型和更加正确和深入的理解原来商业系统运作的方式。
4、CAERwin
5、IBMInfoSphereDataArchitect
InfoSphere是一个很创新的、运行在开源平台-Eclipse上的数据建模工具。Infopshere主要聚焦于一下三个主要的特性：高效、简洁、高度集成。
6、Visio
Visio是Office软件系列中的负责绘制流程图和示意图的软件，是一款便于IT和商务人员就复杂信息、系统和流程进行可视化处理、分析和交流的软件。同时它也可以用来数据库建模。
7、ExcelMapping
通过我们最熟悉的Excel进行维护数据模型、血缘关系和元数据管理