数据建模流程: 概念模型＞＞逻辑模型＞＞物理模型

 数据建模流程

概念模型

概念模型是一种高层次的数据模型，用于描述系统中的关键业务概念及其之间的关系。它主要关注业务需求和数据需求，而不涉及具体的技术实现细节。概念模型通常用于在项目初期帮助业务人员和技术人员达成共识，确保对业务需求的理解一致

特点

1. 业务导向：概念模型主要从业务角度出发，描述业务实体、属性和它们之间的关系。

2. 高层次抽象：它不涉及具体的技术细节，如数据库表结构、数据类型等。

3. 易于理解：概念模型通常使用图形化的表示方法（如实体-关系图），便于业务人员和技术人员共同理解。

4. 独立于技术实现：概念模型不依赖于特定的数据库管理系统或技术平台。

组成部分

1. 实体（Entity）：表示业务中的关键概念或对象，如“客户”、“订单”、“产品”等。

2. 属性（Attribute）：描述实体的特征或属性，如“客户”实体可能有“姓名”、“地址”、“电话”等属性。

3. 关系（Relationship）：表示实体之间的关联，如“客户”与“订单”之间的关系可以是“客户下订单”。

作用

1. 需求分析：帮助业务人员和技术人员共同理解和定义业务需求。

2. 沟通工具：作为业务人员和技术人员之间的沟通桥梁，确保双方对业务需求的理解一致。

3. 设计基础：为后续的逻辑模型和物理模型设计提供基础。

4. 文档化：作为项目文档的一部分，记录业务需求和数据需求。

示例

在线商店的概念模型

• 实体：客户、订单、产品、支付。

• 属性：

  • 客户：客户ID、姓名、地址、电话。

  • 订单：订单ID、订单日期、总金额。

  • 产品：产品ID、名称、价格、库存。

  • 支付：支付ID、支付日期、支付金额。

• 关系：

  • 客户与订单：一个客户可以有多个订单。1对多

  • 订单与产品：一个订单可以包含多个产品。1对多

  • 订单与支付：一个订单对应一个支付。1对1

示例:电脑租赁业务的概念模型

实体：采购管理, 库存管理, 设备管理, 客户关系管理, 合同管理, 统计分析, 系统管理

属性：

• 采购管理：采购订单、供应商信息、采购日期、采购金额等。

• 库存管理：库存数量、库存位置、库存状态、入库日期、出库日期等。

• 设备管理：设备ID、设备名称、设备状态、维护记录、购买日期等。

• 客户关系管理：客户ID、客户姓名、联系方式、客户等级、历史交易等。

• 合同管理：合同ID、合同日期、合同金额、合同状态、相关客户等。

• 统计分析：分析类型、分析日期、分析结果、相关数据等。

• 系统管理：系统日志、用户权限、系统配置、维护记录等。

关系：

• 采购管理与库存管理：采购的物品需要入库，库存管理需要根据采购订单调整库存。

• 库存管理与设备管理：设备可能作为库存的一部分进行管理，设备出库和入库需要记录。

• 库存管理与合同管理：库存管理需要根据合同需求调整库存，合同管理需要确保合同中的物品有足够库存。

• 客户关系管理与合同管理：合同管理需要与客户关系管理相结合，以确保合同的执行和客户满意度。

• 统计分析与各个管理模块：统计分析需要从各个管理模块收集数据，进行分析以支持决策。

• 系统管理与各个管理模块：系统管理负责维护整个系统的运行，确保各个管理模块的数据安全和系统稳定。

注意

注重全局的理解

需要对整体架构做思考

通常是自上而下的模式，与业务反复沟通澄清需求

划定系统边界，避免方向性错误

业务主导

用一页纸整体展示

逻辑模型

逻辑模型是一种详细的数据模型，用于描述系统中的数据结构、关系和约束，而不涉及具体的物理存储细节。逻辑模型是概念模型和物理模型之间的桥梁，它更详细地定义了数据的组织方式，但仍然独立于特定的数据库管理系统（DBMS）或技术平台。

逻辑模型在整个的模型设计过程中所占的工作量是最高的,达到60%~70%, 

1.充分分析业务流程,将业务对象的数据属性和数据关系分析清晰, 业务对象和逻辑实体并不一定是一一对应的,往往是1对多的关系

2.逻辑模型需要继承自概念模型, 即基于概念模型来设计逻辑模型, 也要考虑后面物理模型的设计(考虑物理模型的物理数据库的存储情况来做属性微调和管理变更, )

3.对概念模型里面多对多的关系进行拆分

特点

1. 详细的数据结构：逻辑模型详细描述了实体、属性、关系和约束。

2. 独立于技术实现：虽然逻辑模型比概念模型更详细，但它仍然不涉及具体的物理存储细节，如文件组织、索引等。

3. 规范化：逻辑模型通常遵循规范化原则，以减少数据冗余和提高数据完整性。

4. 易于转换：逻辑模型可以相对容易地转换为物理模型，适用于不同的数据库管理系统。

组成部分

1. 实体（Entity）：表示业务中的关键概念或对象，如“客户”、“订单”、“产品”等。

2. 属性（Attribute）：描述实体的特征或属性，如“客户”实体可能有“客户ID”、“姓名”、“地址”、“电话”等属性。

3. 关系（Relationship）：表示实体之间的关联，如“客户”与“订单”之间的关系可以是“客户下订单”。

4. 约束（Constraints）：定义数据的规则和限制，如主键、外键、唯一性约束等

作用

1. 详细设计：在概念模型的基础上，进一步详细设计数据结构。

2. 规范化：通过规范化过程，减少数据冗余和提高数据完整性。

3. 沟通工具：作为业务人员、数据架构师和开发人员之间的沟通工具，确保对数据结构的理解一致。

4. 转换基础：为物理模型的设计和实现提供基础。

示例

在线商店的逻辑模型

• 实体：客户、订单、产品、支付。

• 属性：

  • 客户：客户ID（主键）、姓名、地址、电话。

  • 订单：订单ID（主键）、客户ID（外键）、订单日期、总金额。

  • 产品：产品ID（主键）、名称、价格、库存。

  • 支付：支付ID（主键）、订单ID（外键）、支付日期、支付金额。

• 关系：

  • 客户与订单：一个客户可以有多个订单（一对多关系）。

  • 订单与产品：一个订单可以包含多个产品，一个产品可以属于多个订单（多对多关系，通常通过关联表实现）。

  • 订单与支付：一个订单对应一个支付（一对一关系）。

示例: 电脑租赁业务的逻辑模型

1. 实体及其属性

订单详细信息

• 订单编号：唯一标识一个订单。

• 产品编号：唯一标识一个产品。

• 产品名称

• 产品类型

• 产品数量

• 租赁周期

订单基本信息

• 订单编号：唯一标识一个订单。

• 客户编号：唯一标识一个客户。

• 联系人姓名

• 订单日期

• 订单状态

• 订单金额

• 优惠金额

合同基本信息

• 合同编号：唯一标识一个合同。

• 签订人名称

• 签订日期

• 合同开始日期

• 合同结束日期

• 合同状态

• 合同金额

• 合同质量

• 合同押金

合同历史信息

• 合同编号：唯一标识一个合同。

• 变更项目

• 合同变更时间

• 变更后合同状态

• 变更后合同开始日期

• 变更后合同结束日期

合同结算信息

• 合同编号：唯一标识一个合同。

• 结算状态：合同的结算状态。

• 结算金额：合同的结算金额。

• 结算时间：合同结算的时间。

合同订单信息

• 合同编号：唯一标识一个合同。

• 订单编号：唯一标识一个订单。

• 订单顺序号：可能与订单在合同中的顺序有关

2. 实体之间的关系

• 订单与合同：通过“合同订单信息”实体关联，表示一个合同可以包含多个订单。

• 合同历史：通过“合同历史信息”实体记录合同的变更历史。

• 合同结算：通过“合同结算信息”实体记录合同的结算情况。

3. 逻辑模型的作用

• 数据组织：该模型详细描述了订单和合同相关的数据结构，包括各个实体的属性及其关系。

• 数据完整性：通过定义主键和外键（如订单编号、合同编号），确保数据的完整性和一致性。

• 业务规则：通过定义各种状态（如订单状态、合同状态）和金额字段，支持业务规则的实施。

• 历史记录：通过“合同历史信息”实体，记录合同的变更历史，支持审计和跟踪。

注意

• 使用标准业务术语

• 遵守模型设计规范

• 先范式建模、再逆规范化

• 定义需完整且准确

• 应用成熟的建模模式

• 一定程度抽象，保证模型弹性

• 重要数据关系需强制建立

• 使用建模工具

• 与概念模型保持一致，拆分概念模型中的多对多关系

建模工具

专业术语 

与逻辑模型相关的常见专业术语

实体（Entity）

• 表示业务中的关键概念或对象，如“客户”、“订单”、“产品”等。

属性（Attribute）

• 描述实体的特征或属性，如“客户”实体可能有“客户ID”、“姓名”、“地址”、“电话”等属性。

关系（Relationship）

• 描述实体之间的关联和依赖。，如“客户”与“订单”之间的关系可以是“客户下订单”。

主键（Primary Key）

• 实体的唯一标识确保每个实体实例的唯一性, 如“客户ID”可以作为“客户”实体的主键。

外键（Foreign Key）

• 在一个实体中引用另一个实体的主键，建立实体之间的关系。如“订单”实体中的“客户ID”可以作为外键，引用“客户”实体的主键。

规范化（Normalization）

• 通过分解实体和属性，减少数据冗余, 提高数据完整性和一致性。

约束（Constraints）

• 定义数据的规则和限制，确保数据的完整性和一致性。如主键约束、外键约束、唯一性约束等。

实体-关系图（Entity-Relationship Diagram, ERD）

• 用图形化表示实体、属性和关系的图表,  帮助理解和沟通数据模型。

数据字典（Data Dictionary）

• 描述数据模型中所有实体、属性、关系和约束的文档。

范式（Normal Forms）

• 规范化过程中的不同级别，如第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等。

多对多关系（Many-to-Many Relationship）

• 两个实体之间的关联，其中一个实体的实例可以与另一个实体的多个实例相关联，反之亦然。通常通过关联表实现。

一对一关系（One-to-One Relationship）

• 两个实体之间的关联，其中一个实体的一个实例只能与另一个实体的一个实例相关联。

一对多关系（One-to-Many Relationship）

• 两个实体之间的关联，其中一个实体的一个实例可以与另一个实体的多个实例相关联(常见)

关联实体（Associative Entity）

• 用于解决多对多的实体关系，通常包含两个外键，分别引用相关实体的主键。

派生属性（Derived Attribute）

• 通过计算或其他属性派生出来的属性，如“年龄”可以通过“出生日期”计算得出。减少数据冗余，提高数据一致性。

域（Domain）

• 属性的取值范围或数据类型，如“年龄”属性的域可以是0到120的整数。

候选键（Candidate Key）

• 能够唯一标识实体实例的属性或属性组合，如“客户ID”和“身份证号”都可以作为“客户”实体的候选键。

复合键（Composite Key）

• 由多个属性组成的主键，在需要多个属性唯一标识实体时使用。如“订单ID”和“产品ID”可以组合成“订单明细”实体的复合键。

弱实体（Weak Entity）

• 依赖于另一个实体存在的实体，如“订单明细”依赖于“订单”存在。

递归关系（Recursive Relationship）

• 实体与自身之间的关系，描述实体内部的层次结构。

示例

遵守规范

设计逻辑模型时应遵守的规范

业务驱动

• 理解需求：确保模型满足业务需求，与业务目标一致。

• 业务术语：使用业务熟悉的术语命名实体和属性。

规范化

• 范式应用：遵循规范化原则（如1NF、2NF、3NF）以减少冗余和依赖。

• 平衡：在规范化和性能之间找到平衡，避免过度规范化。

1NF（第一范式）

确保每列的原子性，即每个字段不可再分。要求每行数据唯一，通常通过主键实现

2NF（第二范式）

在1NF的基础上，非主键字段完全依赖于主键

3NF（第三范式）

在2NF的基础上，消除传递依赖，确保非主键字段之间没有依赖关系

一致性

• 命名规范：统一命名实体、属性和关系，保持一致性。

• 数据类型：统一相同属性的数据类型和格式。

可扩展性

• 灵活设计：确保模型能适应未来业务变化。

• 模块化：采用模块化设计，便于扩展和维护。

模块化设计是一种将复杂系统分解为独立、可管理和可重用模块的方法。 

1. 理解业务需求
分解业务功能：将业务需求分解为独立的功能模块，每个模块对应一个特定的业务领域或功能。

识别核心数据实体：确定业务中的核心数据实体（如客户、订单、产品等）并围绕这些实体设计模块

2. 划分模块
按业务领域划分：根据业务领域（如销售、财务、库存等）划分模块，每个模块负责一个
业务领域的
数据处理。

按功能划分：根据功能（如数据采集、数据清洗、数据存储、数据分析等）划分模块，每个模块
专注于一个功能。

3. 定义模块边界
明确模块职责：为每个模块定义清晰的职责和范围，确保模块之间职责不重叠。

模块接口设计：定义模块之间的交互接口（如输入、输出、调用方式），确保模块间的通信标准化。

4. 数据模型分层
分层设计：将数据模型分为不同的层次（如数据源层、数据存储层、数据处理层、数据服务层等），
每个层次负责特定的功能。

层次解耦：确保各层次之间的依赖最小化，便于单独修改和扩展某一层次。

5. 模块独立性
低耦合：尽量减少模块间的依赖，确保一个模块的修改不会影响其他模块。

高内聚：确保每个模块内部的功能高度相关，提高模块的独立性和可维护性。

6. 使用标准化组件
通用组件：识别和设计可重用的通用组件（如数据验证、数据转换、日志记录等），减少重复开发。

组件库：建立和维护一个组件库，便于在多个项目中复用。

7. 数据流设计
明确数据流向：设计清晰的数据流，确保数据在不同模块间的流动是高效和可控的。

数据接口标准化：使用标准化的数据格式（如JSON、Avro、Parquet等）和协议（如REST、gRPC等）
进行模块间的数据交换。

8. 测试与验证
单元测试：为每个模块编写单元测试，确保模块的功能正确性。

集成测试：进行模块间的集成测试，确保模块间的交互正常。

9. 文档化
模块文档：为每个模块编写详细的设计文档，包括功能描述、接口规范和使用示例。

数据字典：维护数据字典，记录每个模块中的数据字段定义和业务含义。

10. 版本控制与变更管理
版本控制：对每个模块进行版本控制，便于追踪变更和管理不同版本。

变更管理：建立变更管理流程，确保模块的修改经过充分测试和验证。

11. 持续改进
反馈机制：建立反馈机制，收集模块使用中的问题和改进建议。

迭代优化：根据反馈和业务变化，持续优化和调整模块设计。

示例：模块化设计在数据仓库中的应用

数据源模块：负责从不同数据源（如数据库、API、文件）提取数据。

数据清洗模块：负责数据清洗、去重、格式转换等。

数据存储模块：负责将清洗后的数据存储到数据仓库或数据湖中。

数据分析模块：负责从存储层读取数据并进行业务分析。

数据服务模块：提供API或数据接口，供其他系统或应用使用。

 数据完整性

• 主键和外键：使用主键确保唯一性，外键维护关系完整性。

• 约束：通过约束（如唯一性、非空）保证数据质量。

性能优化

• 索引：合理使用索引提升查询性能。

• 分区：对大表进行分区，优化查询和管理。

文档化

• 模型文档：详细记录模型设计、实体、属性和关系。

• 数据字典：维护数据字典，说明每个字段的含义和来源。

安全性

• 数据权限：设计时考虑数据访问权限，确保敏感数据安全。

• 加密：对敏感数据进行加密存储和传输。

版本控制

• 版本管理：对模型设计进行版本控制，便于追溯和回滚。

• 变更记录：记录每次变更的原因和内容。

数据治理

• 数据质量：确保数据准确性、一致性和完整性。

• 元数据管理：有效管理元数据，支持数据发现和使用。

测试与验证

• 模型验证：通过测试确保模型符合业务需求。

• 数据验证：验证模型中的数据是否准确和完整。

先范式建模、再逆规范化

1. 先范式建模

• 目标：通过规范化设计，确保数据结构的合理性、减少冗余、提高数据一致性。

• 步骤：

  1. 1NF（第一范式）：确保每列的原子性，消除重复组。

  2. 2NF（第二范式）：消除部分依赖，确保非主键字段完全依赖于主键。

  3. 3NF（第三范式）：消除传递依赖，确保非主键字段之间没有依赖关系。

  4. 更高范式（可选）：如BCNF（巴斯-科德范式）、4NF（第四范式）等，进一步优化数据结构。

2. 再逆规范化

• 目标：在范式模型的基础上，通过引入冗余或合并表来优化查询性能。

• 常见逆规范化技术：

  1. 合并表：将多个规范化的表合并为一个表，减少查询时的表连接操作。

  2. 增加冗余字段：在表中添加冗余字段，避免频繁的表连接。

  3. 预计算字段：存储预计算的结果（如总和、平均值），避免实时计算。

  4. 分区表：将大表按某种规则分区，提高查询效率。

  5. 物化视图：创建物化视图，存储复杂查询的结果，提升查询性能。

为什么先范式建模、再逆规范化？

• 规范化是基础：

  • 范式建模确保数据结构的合理性和一致性，是逻辑建模的基础。

  • 只有在规范化的基础上，才能准确识别哪些地方需要逆规范化。

• 逆规范化是优化：

  • 逆规范化是在范式模型的基础上，针对性能瓶颈进行的优化。

  • 通过逆规范化，可以在不牺牲数据一致性的前提下，显著提升查询性能。

应用示例

• 电商订单系统的数据模型

• 步骤：

  1. 范式建模：

     • 订单表（Orders）：存储订单基本信息。

     • 订单明细表（OrderDetails）：存储每个订单的商品明细。

     • 商品表（Products）：存储商品信息。

     • 用户表（Users）：存储用户信息。

  2. 逆规范化：

     • 在Orders表中增加冗余字段（如TotalAmount，预计算订单总金额）。

     • 创建物化视图，存储用户订单历史，避免频繁查询多表连接。

     • 将Orders和OrderDetails合并为宽表，减少查询时的表连接操作。

成熟的建模模式

 抽象和模型弹性

1. 抽象：将具体业务细节提炼为通用概念，避免过度依赖特定业务规则或流程。例如，用“客户”代替“VIP客户”或“普通客户”。

2. 模型弹性：模型能够适应业务变化，如新增需求或规则调整，而无需大规模重构。

示例：

• 抽象：用“订单状态”代替“待付款、已发货”等具体状态。

• 弹性：通过配置表管理状态变化，避免频繁修改代码。

重要数据关系的强制建立

重要数据关系是指对业务逻辑和数据分析至关重要的实体之间的关联。

这些关系是业务规则的核心，必须在逻辑模型中明确体现。

（1）主键与外键约束

• 为每个实体定义唯一标识（主键）。

• 在关联实体中通过外键引用主键，确保关系明确。

• 例如：订单表中包含客户ID（外键），强制关联到客户表的主键。

（2）关系基数约束

• 明确关系的基数（1:1、1:N、M:N）。

• 例如：一个客户可以有多个订单（1:N），但一个订单只能属于一个客户。

（3）非空约束

• 强制要求关键字段（如外键）不能为空。

• 例如：订单表中的客户ID字段必须非空。

（4）业务规则校验

• 在数据录入或处理时，通过业务逻辑校验强制建立关系。

• 例如：创建订单时，必须验证客户ID是否存在。

（5）数据模型设计工具

• 使用ER图（实体关系图）等工具，明确标识重要关系。

• 在设计阶段就确保这些关系被纳入模型。

物理模型

物理模型是数据建模的最终阶段，它将逻辑模型转化为具体的、可实现的数据库结构。物理模型定义了数据在数据库中的实际存储方式，包括表结构、字段类型、索引、分区等细节

物理模型的设计步骤

（1）基于逻辑模型

• 将逻辑模型中的实体转化为表，属性转化为字段，关系转化为外键。

（2）选择数据库平台

• 根据项目需求选择合适的数据库管理系统（如 MySQL、PostgreSQL、Oracle 等）。

（3）优化设计

• 根据性能需求优化表结构，如添加索引、分区、冗余字段等。

（4）生成DDL脚本

• 根据物理模型生成数据库的DDL（数据定义语言）脚本，用于创建表、索引等。

（5）测试与调整

• 在测试环境中验证物理模型的性能，并根据测试结果进行调整。

示例

注意

• 使用建模工具自动生成

• 标准术语自动转换字段名称

• 表空间、索引、视图、主键等

• 根据数据环境设计分区

• DBA深度介入

• 与数据库DDL保持一致

• 版本管理