摘要：在当今数字化时代，数据已成为企业的重要资产，而数据模型设计则是构建高效数据平台的关键环节。合理的数据模型能够确保数据的准确性、一致性和可用性，为企业的数据分析、决策制定提供有力支持。本文将基于两篇文章，深入探讨数据平台的数据模型设计相关内容，包括数据模型的设计方法、评价指标、维度模型与宽表设计的优缺点以及在数据平台中的占比情况等。

01

—

数据模型设计方法

1、明确设计目标与步骤

数据模型设计的首要任务是确立目标，将分散、杂乱的小数仓整合为可复用、共享的数据中台。设计过程包含多个关键步骤，如选择业务过程，这是构建模型的基础，明确企业运营中的关键活动；声明粒度，确保同一事实表内粒度一致，从原子粒度开始设计以应对多样查询需求，同时根据需求建立上卷汇总粒度；确认维度，维度围绕业务过程提供描述性属性，用于过滤和分类事实，需确保维度表主键唯一；确定用于度量的事实，事实以数值表示且同一事实表中的度量粒度相同。

此外，还需制定命名规范，涵盖源系统、主题等多方面；编写详细设计映射文档，明确从源系统到维度模型各数据层的物理映射；进行审查和验证，与业务用户和团队成员共同评估模型；最后完成设计文档，为后续 ETL 开发做准备。

2、数仓分层架构与模型整合

数据仓库通常采用分层架构，如 ODS（原始数据层）、DWD（明细数据层）、DWS（轻度汇总层）、ADS/DM（应用层 / 集市层）等。在模型设计中，需对各层进行合理规划与整合。例如，控制 ODS 层源头，确保数据唯一性与一致性，其表命名应遵循特定规则。

划分主题域，如商品域、会员域等，构建总线矩阵，明确各主题域下业务过程的分析维度，确保维度一致性，避免因维度不一致导致分析困难。事实表整合时，遵循统计粒度一致原则，对重复内容进行去除与整合，同时补齐不全的数据。

这里需要说明一下为什么数据仓库的模型需要进行分层设计：

在数据中台尚未构建之时，大多数公司的分析师在开展结合业务的数据分析工作（此类工作需大量数据支持）并以报表服务业务部门运营时，面临着诸多困境。分析师常常处于缺乏可复用数据的境地，只能依赖原始数据进行清洗、加工以及指标计算。

由于多数分析师并非技术专业出身，他们所编写的 SQL 质量往往不尽人意，甚至会出现 5 层以上的嵌套情况。这类 SQL 对资源的消耗极为庞大，极易造成队列阻塞，进而干扰其他数仓任务，这自然引发了数据开发人员的不满。于是，数据开发人员可能会收回分析师的原始数据读取权限，而分析师则会抱怨数仓数据存在缺陷，所需数据常常缺失，一个需求的处理甚至常常需要等待一周乃至半个月之久。如此一来，分析师与数据开发人员之间的矛盾便逐渐产生了。

为了解决数据分析师和数据开发人员的矛盾，延伸出数据模型，而数据模型的分层设计就是为了解决数据分析师快速的使用数据进行分析，那么数据分层的设计就需要有复用性的特性。

3、模型开发与应用迁移注意事项

模型开发阶段，要严格配置任务依赖，防止错误数据导致资源浪费；及时删除任务中的临时表，避免空间占用；任务名称与表名保持一致，方便管理；合理管理生命周期，如 ODS 和 DWD 保留历史数据，DWS/ADS/DM 设置适当周期；DWD 层表可采用压缩存储。

应用迁移过程中，核心是比对数据，确保一致性后进行迁移并删除老数据表。此过程需谨慎操作，避免数据错误或丢失。

02

—

数据模型评价方法

一、数据模型好坏的评价指标1、完善度DWD 层完善度：通过跨层引用率衡量，即 ODS 层直接被 DWS/ADS/DM 层引用的表占所有 ODS 层表（仅统计活跃表）的比例，该比例越低越好，理想情况不允许跨层引用，ODS 层数据应仅被 DWD 引用。DWS/ADS/DM 层完善度：以汇总数据查询比例为指标，即 DWS/ADS/DM 层的查询占所有查询的比例，越高说明上层数据建设越完善，能提升查询速度、降低成本。2、复用度以模型引用系数作为衡量标准，指一个模型被读取并直接产出下游模型的平均数量。一般低于 2 表示复用性较差，3 以上相对较好（经验值）。理想的数据模型设计应呈现交织的发散型结构，而非自下而上的单线结构，以提高模型复用和共享能力。

如上图所示，可以通过数据血缘查看当前数据的流向，如上图所示，图1 复用性差，图2 的复用性相对较好。

3、规范度规范度主要考量模型的分层信息、主题域归属、命名规范以及字段命名一致性等方面。若大量表无分层或主题域归属，命名不规范，将导致模型难以查找和复用。例如，表命名应包含主题域、分层、数据类型等信息，相同字段在不同模型中的命名需保持一致。

03

—

维度模型和宽表设计优缺点

在数据仓库建模的时候通常采用维度建模和宽表建模的方式进行建模，那么他们的区别是什么了？

一、维度模型设计

1、优点

维度建模具有诸多优势，其结构清晰，便于理解，无论是业务人员还是数据开发人员都能快速掌握模型逻辑。在应用开发方面，由于其结构特点，能够提高开发效率，减少开发成本。查询性能方面表现出色，通过维度表与事实表的关联，可快速聚合出结果，减少表连接操作，提升查询速度，满足企业对数据快速响应的需求。同时，模型具有良好的扩展性，能够适应企业业务的不断发展和变化，轻松应对新的分析需求。

2、缺点

然而，维度模型也并非完美无缺。在处理缓慢变化维度时可能面临挑战，例如当维度数据发生变化，如用户的收货地址变更，需要采用特定的处理方式，如拉链表等，增加了数据管理的复杂性。此外，对于一些复杂的业务逻辑，可能需要更多的设计和优化工作，以确保模型的准确性和有效性。

二、宽表设计1、优点宽表设计旨在提高查询性能，通过将多个维度冗余到事实表中，实现单表查询，避免了复杂的表连接操作，能够快速响应用户查询请求。这种设计方便使用，降低了使用成本，尤其对于非技术人员，无需了解复杂的表关联逻辑即可获取所需数据。在构建公共指标数据层方面表现突出，提升了公共指标的复用性，减少了数据的重复加工，提高了数据处理效率，进而提升用户满意度。2、缺点但宽表设计也存在一些问题，数据冗余是其主要缺点之一，冗余的数据会占用更多的存储空间，增加存储成本。灵活性较差，当线上业务表结构发生变更时，宽表模式的改造工作量较大，需要对整个宽表进行调整。开发宽表需要深入了解业务全流程，明确需扩展的维度和沉淀的指标，否则容易导致宽表重复迭代，难以适应业务快速迭代的需求。

三、数据仓库的模型设计与传统数据库设计的区别如下

用途：数据仓库主要用于支持企业的决策分析和业务统计等；传统数据库主要用于支撑业务系统的日常操作和数据增删改查等。

数据：数据仓库存储以主题为单位的历史数据，具有冗余度高、数据结构复杂、数据量大的特点；传统数据库存储当前业务系统的交易数据和日志信息，数据结构较简单、冗余度低。

设计和结构：

具体到建模方面，数据仓库常用星型模型、雪花模型等，如星型模型以一个中心事实表为核心，围绕它建立多个维度表，简单直观，易于理解和查询，适用于大部分数据仓库设计场景；雪花模型在星型模型基础上进一步细化维度表，将其规范化成多个层级，适用于具有复杂维度关系的场景，但查询和维护的复杂度会增加。而传统数据库通常采用如 ER 建模等方法。

此外，传统数据库设计主要是建立物理数据模型，包括确定建立哪些表、表中有哪些字段、表的主键和外键以及字段的数据类型和约束等工作内容。而数据仓库的模型设计还需考虑数据的集成、不更新性以及随时间变化等特点。例如，数据仓库中的数据来自不同的应用，需经过 ETL 过程；其主要操作集中在数据查询上，且数据会随着时间而变化。同时，数据仓库还可能采用分层设计、主题域设计等方法，中间层是数据仓库性能的关键，主题域设计可实现业务紧耦合、便于数据拓展和使用等。

04

—

实际案例

案例背景

假设我们正在为一家电商企业设计数据模型，该企业主要业务包括商品销售、用户管理、订单处理、物流配送以及客户评价等环节，需要对海量的业务数据进行有效的管理和分析，以支持企业的决策制定、业务优化以及客户服务提升等目标。

维度建模

1、设计过程

选择业务过程：确定与销售业务紧密相关的 “订单处理” 作为核心业务过程，因为订单数据包含了商品购买的关键信息，如购买商品、购买时间、购买数量、购买金额以及用户和商品的关联等，这些信息对于分析销售趋势、用户购买行为以及商品销售情况等具有重要意义。

声明粒度：以 “订单” 作为事实表的粒度，意味着事实表中的每一行代表一个订单的详细信息。例如，在记录订单金额时，是针对每个订单的具体金额进行记录，而不是汇总或细分到其他层级（如按商品类别或按用户区域汇总后的金额）。这种原子粒度的设计能够提供最详细的订单信息，为后续可能的各种分析需求提供最大的灵活性，无论是按订单维度进行深入分析，还是向上卷汇总到更高层级（如按天、按月统计订单总量和总金额等）都能够实现。

确认维度：围绕订单处理业务过程，确定关键维度，如 “时间维度”（包含订单日期、下单时间、发货时间、收货时间等，用于按时间周期分析订单情况，如按季度统计销售趋势、按月分析销售波动等）、“用户维度”（包括用户 ID、用户名、用户注册时间、用户等级、用户地址等，用于分析不同用户群体的购买行为和偏好，如对比新老用户的购买频率、分析不同地区用户的购买偏好等）、“商品维度”（涵盖商品 ID、商品名称、商品类别、商品品牌、商品价格、商品库存等，用于了解各类商品的销售情况，如哪种商品销量最高、不同品牌商品的销售额占比等）、“店铺维度”（如果平台有多个店铺，则包含店铺 ID、店铺名称、店铺类型等，用于分析不同店铺的经营状况和业绩差异）。这些维度表与订单事实表通过外键关联，能够为订单数据提供丰富的上下文描述，方便从多个角度对订单数据进行筛选、分类和分析。

确认用于度量的事实：在订单事实表中，确定用于度量的事实，如 “订单金额”（表示每个订单的总金额，是最直接反映销售业绩的关键指标，可用于统计总销售额、平均订单金额等）、“购买数量”（记录每个订单中购买商品的数量，可用于分析商品销售数量分布、畅销商品的销量情况等）、“折扣金额”（如果订单中存在商品折扣，则记录折扣的金额，有助于分析促销活动对销售的影响、计算实际销售额与原价销售额的差异等）。这些事实均以数值形式表示，并且都与订单粒度保持一致，确保在进行数据分析和计算时不会出现重复计算或统计口径不一致的问题。

基于上面的模型设计，输出逻辑模型设计图

2、架构特点与优缺点

缺点

数据冗余：为了提高查询性能，维度表中可能会存在一定的数据冗余。例如，在用户维度表中，如果一个用户有多个订单，那么用户的基本信息（如用户名、用户注册时间等）会在每个与该用户相关的订单记录中重复存储。这种数据冗余虽然在一定程度上提高了查询速度，但会增加数据存储的成本，并且在数据更新时需要同时更新多个冗余的记录，增加了数据维护的复杂性。

处理复杂业务逻辑能力有限：对于一些复杂的业务逻辑，如涉及多个事实表之间的复杂关联关系或多步骤业务流程的建模，维度建模可能会显得力不从心。例如，在分析电商平台的退款流程时，涉及到订单状态的多次变更、退款金额的计算以及与支付系统、库存系统等多个系统的交互，这种复杂的业务逻辑在维度建模中可能难以直接清晰地表达，需要进行额外的设计和处理，否则可能会导致数据模型的理解和维护困难。

优点

查询性能高：由于星型模型的结构特点，在进行数据分析查询时，能够快速地从事实表和维度表中获取所需数据，通过简单的连接操作即可实现多维度的数据分析。例如，查询某个地区在特定时间段内某个品牌商品的销售总额，只需将订单事实表与用户维度表（通过用户地址筛选地区）、商品维度表（通过品牌筛选）和时间维度表（通过时间段筛选）进行连接，即可快速获取结果，大大提高了查询效率，适用于对实时性要求较高的数据分析场景，如电商平台的实时销售报表生成、实时用户行为分析等。

便于理解和使用：其结构简单直观，无论是业务人员还是数据分析师，都能够轻松理解数据模型的逻辑关系，快速上手进行数据分析工作。例如，业务人员可以直观地理解从用户维度、商品维度等对销售数据进行分析的方式，无需深入了解复杂的数据库结构和技术细节，降低了数据分析的门槛，促进了业务与数据的融合，有助于企业更好地利用数据进行决策。

可扩展性强：当企业业务发展需要增加新的维度或事实时，维度建模能够相对容易地进行扩展。例如，企业决定开展新的营销活动，需要记录每个订单的营销渠道来源，只需在订单事实表中添加 “营销渠道” 字段，并在相关维度表中建立对应的维度信息（如营销渠道维度表，包含渠道 ID、渠道名称、渠道类型等），然后通过外键关联即可实现对营销渠道维度的数据分析，而不会对现有数据模型的整体结构造成重大影响，能够很好地适应企业业务的不断变化和发展。

架构特点：维度建模采用星型模型架构，以订单事实表为核心，周围连接多个维度表，如用户维度表、商品维度表、时间维度表等。这种架构使得数据关系清晰明了，易于理解和导航。例如，当需要分析某个时间段内某个用户购买了哪些商品时，只需通过订单事实表中的外键关联，即可快速从相关维度表中获取用户信息和商品信息，无需复杂的多表连接操作。

宽表设计1、设计思路在电商数据模型的宽表设计中，为了提高查询性能和方便数据分析，将多个维度的信息直接冗余到事实表中，形成一个包含大量字段的宽表。例如，在销售订单宽表中，除了包含订单的基本信息（如订单 ID、订单金额、订单时间等）和度量事实（如购买数量、折扣金额等）外，还将用户维度的相关信息（如用户 ID、用户名、用户等级、用户地址等）、商品维度的信息（如商品 ID、商品名称、商品类别、商品品牌、商品价格、商品库存等）、店铺维度的信息（如店铺 ID、店铺名称、店铺类型等）以及时间维度的部分信息（如订单日期、下单时间等）都整合到一张表中。这样，在进行数据分析时，无需进行多表连接操作，直接从宽表中查询所需字段即可，大大提高了查询效率，适用于对查询响应速度要求极高的场景，如电商平台的实时销售数据监控、实时用户行为分析以及需要快速生成报表的场景。缺点数据冗余严重：宽表中整合了多个维度的信息，导致数据冗余程度较高。例如，用户的基本信息会在每个与该用户相关的订单记录中重复存储，商品的信息也会在每个包含该商品的订单记录中重复出现。这种大量的数据冗余不仅占用了大量的存储空间，增加了存储成本，还可能影响数据更新的效率，因为当某个维度信息发生变化时，需要在宽表中的多个记录中进行更新，增加了数据维护的复杂性和成本，并且可能导致数据不一致的问题。灵活性欠佳：宽表的结构相对固定，一旦设计完成，后期对表结构的修改和扩展难度较大。例如，如果企业业务发生变化，需要增加新的维度或修改现有维度的结构，可能需要对整个宽表进行重新设计和调整，涉及到大量的数据迁移和转换工作，成本高昂且耗时。此外，宽表设计适用于相对稳定、明确的业务分析需求，如果业务需求不断变化或需要进行复杂的多维度分析，宽表可能无法很好地满足需求，灵活性较差，限制了企业对数据的深入挖掘和利用能力。开发难度大且迭代成本高：开发宽表需要深入了解业务全流程，准确确定需要冗余到事实表中的维度和指标，否则容易导致宽表设计不合理，需要频繁进行迭代优化。例如，在电商业务快速发展过程中，如果对业务流程或分析需求的理解不够深入，可能会导致宽表中包含不必要的字段或缺少关键字段，随着业务的发展，可能需要不断修改宽表结构，每次迭代都需要涉及大量的数据处理工作，包括数据迁移、数据清洗和转换等，开发成本较高且迭代周期较长，难以快速适应业务的变化。

优点

查询性能卓越：通过将多个维度信息冗余到事实表中，实现了单表查询，避免了多表连接操作带来的性能开销，能够快速获取数据，满足实时性要求极高的数据分析需求。例如，在查询某个用户的购买历史及相关商品和店铺信息时，直接从宽表中筛选用户 ID 相关的记录，即可一次性获取所有需要的信息，查询速度极快，能够为电商平台的实时运营决策提供及时的数据支持，如实时调整推荐商品、实时监控销售趋势等。

使用便捷性高：对于数据分析人员和业务人员来说，宽表设计使得数据查询和使用变得更加简单直接，无需了解复杂的表关联逻辑即可获取所需数据，降低了数据分析的难度和门槛。例如，业务人员可以直接从宽表中获取订单的详细信息以及相关的用户、商品和店铺信息，快速进行数据分析和业务洞察，有助于提高业务决策的效率和准确性，促进业务的快速发展。公共指标复用性好：在构建公共指标数据层方面表现出色，由于宽表中包含了丰富的信息，许多常见的公共指标（如销售额、销售量、客单价等）可以直接从宽表中计算和获取，并且可以被多个不同的业务分析场景复用，减少了数据的重复加工和计算，提高了数据处理效率，降低了数据处理成本，有助于企业整合和优化数据分析流程，提高数据资产的利用价值。

ER 建模

1、设计流程

概念模型设计：从业务角度出发，对电商企业中的主要实体进行抽象和识别，确定 “用户”“商品”“订单”“店铺”“物流”“评价” 等为关键实体，以及它们之间的相互关系。例如，一个用户可以下多个订单，一个订单属于一个用户，所以用户和订单之间是一对多的关系；一个订单中包含多个商品，一个商品可以被多个订单包含，因此订单和商品之间是多对多的关系；一个店铺可以有多个订单，一个订单属于一个特定的店铺，所以店铺和订单之间是一对多的关系；一个订单对应一个物流配送记录，一个物流配送记录只与一个订单相关，所以订单和物流之间是一对一的关系；一个用户可以对多个订单进行评价，一个订单可以被多个用户评价，所以用户和评价、订单和评价之间都是多对多的关系。通过 ER 图（实体关系图）清晰地描绘这些实体和关系，为后续的逻辑模型设计奠定基础。

逻辑模型设计：在概念模型的基础上，进一步细化实体的属性和关系，将其转化为具体的数据库表结构。例如，对于 “用户” 实体，确定其属性包括用户 ID（作为主键，唯一标识每个用户）、用户名、密码、用户注册时间、用户等级、用户联系方式、用户地址等；对于 “商品” 实体，属性有商品 ID（主键）、商品名称、商品类别、商品品牌、商品价格、商品库存、商品描述等；对于 “订单” 实体，属性包括订单 ID（主键）、订单金额、订单时间、用户 ID（作为外键关联用户表）、店铺 ID（外键关联店铺表）等；对于 “店铺” 实体，属性有店铺 ID（主键）、店铺名称、店铺类型、店铺地址、店铺联系方式等；对于 “物流” 实体，属性包括物流 ID（主键）、订单 ID（外键关联订单表）、物流状态、物流配送时间、物流公司等；对于 “评价” 实体，属性有评价 ID（主键）、订单 ID（外键关联订单表）、用户 ID（外键关联用户表）、评价内容、评价时间、评价星级等。同时，根据实体之间的关系，在表中定义相应的主键和外键约束，确保数据的完整性和一致性。例如，在订单表中，通过用户 ID 外键关联用户表，通过店铺 ID 外键关联店铺表，确保每个订单都能正确关联到对应的用户和店铺；在评价表中，通过订单 ID 和用户 ID 外键分别关联订单表和用户表，保证评价与订单和用户的正确对应关系。

缺点

查询性能相对较低：在进行复杂查询时，尤其是涉及多个实体之间的关联查询时，由于 ER 模型需要通过多表连接操作来获取数据，可能会导致查询性能下降。例如，查询某个用户购买的所有商品以及相关店铺信息，需要连接用户表、订单表、商品表和店铺表等多个表，随着数据量的增加，连接操作的开销会越来越大，查询响应时间会变长，无法满足实时性要求较高的数据分析需求，可能影响企业对数据的快速分析和决策制定，特别是在处理大数据集和复杂分析场景时，这种性能瓶颈会更加明显。

不太适合数据分析场景：虽然 ER 建模能够准确地反映业务逻辑和数据关系，但对于数据分析人员来说，其复杂的表结构和多表连接操作增加了数据分析的难度。在进行数据分析时，需要编写复杂的 SQL 查询语句来获取所需数据，这对于数据分析人员的技术要求较高，并且可能会降低数据分析的效率。此外，由于 ER 模型主要关注数据的存储和事务处理，对于数据分析中常见的多维分析和数据挖掘需求支持不够友好，难以直接从模型中快速获取多维度的汇总信息和深层次的数据洞察，不利于企业充分挖掘数据的价值，限制了数据在企业决策中的作用发挥。

模型扩展性受限：当企业业务发生较大变化或需要增加新的分析维度时，ER 建模的扩展性可能会受到一定限制。由于其结构相对固定，对实体和关系的修改可能会涉及到多个表的结构调整和数据迁移，成本较高且复杂。例如，企业决定开展新的业务模式，需要在现有数据模型中增加新的实体和关系，如引入会员积分系统，需要创建新的积分实体并建立与用户、订单等实体的关系，这可能需要对数据库结构进行较大幅度的修改，包括修改现有表结构、添加新表、调整外键关系等，同时还需要处理大量的历史数据迁移工作，工作量巨大且容易出错，可能会影响企业业务的正常发展和数据的连续性。

数据完整性强：ER 建模通过主键和外键约束，有效地保证了数据的完整性。例如，在订单表中，外键用户 ID 和店铺 ID 必须分别指向用户表和店铺表中已存在的记录，否则无法插入订单数据，这就确保了订单数据与用户和店铺数据的一致性，避免了孤儿数据（即没有关联到有效实体的数据）的出现。同时，在数据更新和删除时，也可以通过级联操作或限制操作来维护数据的完整性，防止因数据操作不当导致的数据不一致问题，保证了企业数据资产的准确性和可靠性，为企业的决策分析提供了可信的数据支持。

适用于事务处理系统：由于其对数据完整性和一致性的严格要求，ER 建模非常适合用于支撑电商平台的日常事务处理系统，如订单管理系统、库存管理系统、用户账户管理系统等。在这些系统中，数据的准确性和一致性至关重要，任何数据错误都可能导致业务流程出现问题，如订单处理错误、库存数量错误、用户信息错误等。ER 建模能够确保数据在事务处理过程中的正确性，保障业务系统的稳定运行，提高企业的运营效率和客户满意度。

逻辑清晰易维护：ER 模型清晰地展示了实体之间的关系，使得数据结构易于理解和维护。无论是数据库管理员还是开发人员，都可以通过 ER 图快速了解数据库的结构和业务逻辑，方便进行数据库设计、开发和维护工作。例如，当企业业务发生变化需要修改数据库结构时，开发人员可以根据 ER 图快速定位需要修改的实体和关系，进行相应的调整，同时由于 ER 建模的规范性，也降低了因结构修改而引入新错误的风险，有助于提高企业数据管理的效率和质量，降低数据管理成本。

特点：

ER 建模注重数据的完整性和一致性，通过严格定义实体、属性和关系，以及主键和外键约束，确保数据在数据库中的准确性和可靠性。在电商数据模型中，这种建模方式能够清晰地反映业务逻辑和数据之间的内在联系，使得数据的存储和管理更加规范化。例如，在处理订单与用户、店铺、商品等关系时，通过外键约束保证了订单数据与相关实体数据的一致性，避免了数据的孤立和错误关联，为企业的业务运营提供了坚实的数据基础，有助于保证业务流程的正常运转，如订单处理、库存管理、用户服务等环节都依赖于准确一致的数据。

总结

维度建模适用于以数据分析和决策支持为主要目标的场景，特别是在处理大规模数据和复杂分析需求时，其查询性能和可扩展性优势明显，但需要注意数据冗余问题。宽表设计在对查询响应速度要求极高的场景下表现出色，能提高公共指标复用性，但数据冗余严重且灵活性差。ER 建模则侧重于数据的完整性和一致性，适合事务处理系统，但在查询性能和数据分析灵活性方面存在不足。在实际的电商数据模型设计中，需要根据企业的具体业务需求、数据特点和应用场景，综合考虑选择合适的数据建模方法，或结合使用多种方法，以构建高效、灵活、可靠的数据模型，为企业的运营提供好的模型设计。