上一篇
概念模型数据仓库建模怎么做？数据仓库建模步骤详解
概念模型是数据仓库建模的顶层抽象,它不关注具体的物理存储细节（如数据类型、索引、分区等），而是聚焦于业务实体、业务过程以及它们之间的逻辑关系，其核心目标是构建一个与业务语言一致、易于理解且能够支撑长期业务发展的数据蓝图。
核心构建要素
概念模型主要由三个关键部分组成：业务实体、业务过程和业务关系。
业务实体 (Business Entities)
业务实体代表企业中需要跟踪的关键对象，如客户、产品、供应商、门店等，在概念模型中，实体通常以矩形表示，重点在于定义实体的唯一标识符（主键）以及描述其属性的业务含义，而非技术实现。
业务过程 (Business Processes)
业务过程是指企业为了达成特定目标而执行的一系列操作，销售订单处理”、“库存补货”或“客户服务交互”，概念模型需要明确这些过程的边界，识别出过程中的关键度量指标（如销售额、数量）和维度属性（如时间、地点、产品类别）。
业务关系 (Business Relationships)
关系描述了实体之间或实体与过程之间的关联，常见的关系类型包括一对一、一对多和多对多，在数据仓库中，多对多关系通常需要通过桥接表或事实表来分解，但在概念阶段，只需明确其逻辑存在即可。
建模步骤详解
构建概念模型通常遵循以下逻辑步骤,确保从业务需求到数据结构的平滑过渡。
第一步：识别业务主体与边界
需要与业务专家沟通，确定数据仓库的范围，如果构建的是“零售分析数据仓库”，那么核心主体可能包括“顾客”、“商品”、“交易”和“门店”，需要明确哪些业务活动包含在内，哪些排除在外。
第二步：定义核心实体及其属性
针对识别出的主体，列出其关键属性。“顾客”实体可能包含顾客ID、姓名、注册日期、会员等级等，此时应避免技术细节，如“姓名”是VARCHAR(50)还是VARCHAR(100)并不重要，重要的是业务上需要记录姓名。
第三步：梳理业务过程与事实
确定需要分析的业务流程，以“销售”为例，这是一个典型的事务型过程，需要识别出该过程中的度量值（如销售金额、折扣额）以及参与该过程的实体（如顾客、产品、门店）。
第四步：建立实体间关系
将实体与过程连接起来，在概念模型中，这通常表现为实体围绕着一个中心过程分布。“顾客”与“销售过程”之间是多对多关系（一个顾客有多次销售，一次销售涉及一个顾客）；“产品”与“销售过程”也是多对多关系。
概念模型与逻辑/物理模型的区别
为了更清晰地理解概念模型的位置,以下表格展示了其在数据仓库建模体系中的层级差异：
| 维度 | 概念模型 (Conceptual) | 逻辑模型 (Logical) | 物理模型 (Physical) |
|---|---|---|---|
| 受众 | 业务人员、架构师 | 数据分析师、DBA | 数据库管理员、ETL开发人员 |
| 关注点 | 业务含义、实体关系 | 属性定义、主外键、规范化/反规范化 | 存储引擎、分区策略、索引、数据类型 |
| 抽象程度 | 高（业务语言） | 中（结构化数据） | 低（具体实现） |
| 变更频率 | 低（业务规则稳定） | 中（需求细化） | 高（性能优化、迁移） |
| 典型工具 | ER图、UML类图 | 逻辑ER图、数据字典 | SQL脚本、DDL语句 |
常见建模方法论的应用
在概念模型阶段,不同的建模方法论会有不同的侧重点，但核心思想一致。
维度建模 (Dimensional Modeling)
这是数据仓库最常用的方法，概念模型需识别出“事实表”和“维度表”。
- 事实表：对应业务过程，包含度量值和外键。
- 维度表：对应业务实体，包含描述性属性。
- 概念表达：在概念图中，事实表通常位于中心，维度表环绕四周，形成星型模式的雏形。
范式建模 (Normalized Modeling)
较少用于数据仓库，但有时用于操作型数据存储（ODS），概念模型需严格遵循第三范式（3NF），消除数据冗余。
- 概念表达：实体被拆分为多个细粒度表，通过外键紧密连接，形成网状结构。
数据立方体 (Data Cube)
用于OLAP分析的概念抽象。
- 概念表达：将多维数据抽象为立方体，每个维度代表一个轴，事实位于立方体内部。
最佳实践建议
- 使用业务语言：避免使用技术术语（如“ID”、“Type”），改用业务术语（如“客户编号”、“会员状态”）。
- 保持简洁：概念模型不应包含所有属性，只保留对业务分析至关重要的核心实体和关系。
- 迭代演进：概念模型不是一次成型的，应随着业务需求的深入不断调整。
- 可视化沟通：使用标准的ER图或UML图，确保业务人员和技术人员能就同一张图达成共识。
相关问题与解答
在概念模型阶段，是否需要确定主键和外键的具体技术实现（如自增整数、UUID）？
解答： 不需要，概念模型的核心目标是表达业务逻辑和实体关系，而非技术实现，主键和外键在概念模型中仅表示为“唯一标识”和“关联关系”，具体的技术实现（如使用自增整数以提高插入性能，或使用UUID以支持分布式系统）属于逻辑模型或物理模型阶段的决策，过早确定技术细节可能会限制后续设计的灵活性，并增加与业务人员沟通的认知负担。
如果业务实体之间存在多对多关系，在概念模型中应如何处理？
解答： 在概念模型中，多对多关系应被明确标识出来，但不需要立即创建桥接表，概念模型的重点是准确反映业务现实。“学生”和“课程”之间存在多对多关系，这在概念上是清晰的，具体的实现方式（如创建“选课记录”表作为桥接表）是在逻辑模型阶段，根据所选用的建模方法论（如维度建模中的事实表设计或范式建模中的第三范式分解）来确定的，在概念阶段，只需画出连线并标注“多对多”即可，无需过度设计中间结构。
