数据仓库项目的需求、风险与数据建模

在数据仓库项目中，明确需求、评估数据风险以及设计合适的数据模型是至关重要的环节。以下将详细介绍相关内容。

1. 需求定义与审核

项目有一系列功能和非功能需求。例如：
- 若数据中心停电导致 ETL 失败，数据仓库中的数据不应损坏或受损，必须可恢复且无数据丢失。
- 用户数量预计在 300 到 500 之间，其中约 20% 为重度频繁用户，其余为偶尔使用的用户。
- 为保护投资，需使用与文件和电子邮件服务器相同的存储区域网络（SAN），而非创建新的独立 SAN。

David、Grace 和 Natalie 对这些需求进行了审核、记录，并获得必要的签字确认。他们从完整性、可行性以及对系统架构的影响等方面对需求进行了审查，并以补充规范格式记录，包括可用性、可靠性、性能、可支持性、设计约束、用户文档和帮助、接口以及适用标准等部分。业务用户、IT 架构组和运营团队对文档进行了审核并签字。

2. 数据可行性研究

在定义功能和非功能需求后，需要详细了解数据和源系统，这就需要进行数据可行性研究。其目的是探索源系统，通过列出主要数据风险并验证来理解数据，确定是否能按需求交付项目。
- 探索源系统 ：检查数据库平台、数据库结构并查询表。
- 理解数据 ：找出每个功能需求的数据位置，理解数据的含义和质量。
- 识别风险 ：查看需求与数据之间是否存在差距，即数据是否可用和可访问。

数据风险主要分为数据可用性风险和数据可访问性风险。例如，需求可能需要两年的历史数据，但只有六个月的数据，这就是数据可用性风险；若 ETL 系统无法提取数据并将其导入仓库，则属于数据可访问性风险。

以下是一些常见的数据风险示例：
| 编号 | 风险 |
| ---- | ---- |
| 1 | 无法在非功能需求规定的一小时内从 Jupiter 进行数据提取。 |
| 2 | 由于源系统中没有所需数据，无法满足功能需求。 |
| 3 | 数据存在但无法访问。 |
| 4 | 数据可用但需要先进行重组和清理。 |
| 5 | 可能无法使用与文件和电子邮件服务器相同的 SAN，因为数据仓库的数据量可能超过现有 SAN 的最大容量。 |
| 6 | 每日增量加载可能会使源系统变慢。 |
| 7 | 用户可能无法在不登录数据仓库的情况下使用前端应用程序。 |
| 8 | 初始数据加载可能比预期花费长得多的时间，影响项目进度。 |

针对这些风险，需要逐一进行验证和缓解：
- 风险 1 ：在知道要从 Jupiter 提取什么数据之前无法确定是否能在一小时内完成提取。可以快速构建一个简单的 SQL Server Integration Services (SSIS) 包来提取 Jupiter 库存表一周的数据。如果该包运行需要五分钟，那么大致可以认为该风险可控。若此方法过于简单，可构建一个从源系统多个大表中提取一天等效数据的包。
- 风险 2 ：与业务项目经理或熟悉源系统前端的人沟通，询问业务需求所需的数据在 Jupiter、Jade 或 WebTower9 中是否可用。对于不可用的数据，讨论是否有人可以安排以文本文件或电子表格的形式提供。
- 风险 3 ：了解源系统运行的 RDBMS。大多数公司使用流行的 RDBMS，如 Oracle、Informix 等，这些系统支持 ADO.NET、ODBC、JDBC 或 OLEDB，在获得安全权限后可使用 SSIS 访问数据。若源系统是专有系统且找不到 ODBC 或 JDBC 驱动程序，需与 DBA 讨论是否可定期将数据导出到文本文件。此外，连接性也可能是障碍，例如生产数据库服务器可能位于防火墙后面，可能需要打开防火墙漏洞。
- 风险 4 ：通过查询源系统发现源系统中的一些数据可能需要清理，常见的数据质量问题包括不完整数据、不正确/不准确数据、重复记录等。
- 风险 5 ：在设计 DDS 和 NDS 之前，难以准确估计数据存储大小。但可以进行大致估计：
- 对于业务需求 1 到 7 中的每个点，假设会有一个事实表和一个汇总表。估计事实表的宽度，简单事实表假设 5 个键列，复杂事实表假设 15 个键列。
- 估计维度表的宽度，简单维度假设 10 列，复杂维度假设 50 列，平均每列假设为 50 个字符。
- 假设汇总表的大小为事实表的 10% 到 20%。
- 事实表的深度取决于交易量，对于事务性事实表，查看源系统每天的事务数量；对于每日快照事实表，查看每个快照的记录数量，并乘以使用存储的时间。
- 查询源系统估计每个维度的记录数量。
- NDS 或 ODS 的大小估计差异较大，可查询源系统表来估计每个 NDS 或 ODS 表的大小。
- 风险 6 ：可通过构建简单的 SSIS 包模拟每日增量加载，在源系统使用时运行该包，测量性能是否下降。若有性能下降，可安排在非工作时间进行每日增量加载。
- 风险 7 ：通过构建简单的报告和简单的 OLAP 立方体并应用安全措施来缓解单登录需求。需要在 SQL Server Reporting Services (SSRS) 和 SQL Server Analysis Services (SSAS) 上应用 Windows 集成安全。
- 风险 8 ：根据功能需求 10 中指定的标准查询源系统来估计初始数据加载量。例如，查询源系统的销售订单表，找出满足历史数据需求需要加载到数据仓库的记录数量。

3. 数据建模

对于 Amadeus Entertainment 案例研究，采用 NDS + DDS 架构设计数据存储。
- 设计维度数据存储（DDS） ：用户将使用数据仓库在六个业务领域进行分析，以产品销售为例，产品销售事件发生时，角色包括客户、产品和商店，级别（即维度建模中的度量）包括数量、单价、价值、直接单位成本和间接单位成本。将度量放在事实表中，角色（加上日期）放在维度表中。
以下是产品销售事实表的一些度量计算：
- 销售价值 = 单价 × 数量
- 销售成本 = 单位成本 × 数量
- 利润 = 销售价值 - 销售成本

事实表中的四个键将事实表与四个维度相连，该事实表的粒度是每个销售的商品。

在实际数据建模中，会遇到复杂事件和例外情况，处理规则是始终参考源系统，复制或模仿源系统逻辑，确保数据仓库应用程序的输出与源系统一致。对于复杂的业务逻辑，如成本分配和客户盈利能力计算，若业务人员和源系统代码存在分歧，应告知业务项目经理并由其决定在数据仓库中实施哪种逻辑，且需记录并获得签字确认。

在零售中，销售税（增值税 [VAT]）的实现方式有多种，如不包含在销售事实表中、构建销售税事实表或在单价中包含折扣等。

事实表设计还包括：
- 退化维度 ：事实表中的 order_id 和 line_number 是退化维度，为区分不同源系统的相同订单 ID，可添加源系统 ID 列，并在事实表中添加时间戳列，包括记录加载时间和最后更新时间。
- 确定主键 ：通常可通过事实表中所有维度列的组合唯一标识事实表行，但可能存在重复行，此时可使用退化维度来确保唯一性。例如，在 Amadeus Entertainment 案例中，可使用 order_id 和 line_number 作为主键候选，也可创建新的事实表键列作为主键候选。

维度表和事实表的集合称为数据集市，仅在数据仓库采用维度模型时适用。

以下是产品销售事实表的最终形式：
| 列名 | 数据类型 | 描述 | 示例值 |
| ---- | ---- | ---- | ---- |
| sales_date_key | int | 客户购买产品的日期键 | 108 |
| customer_key | int | 购买产品的客户键 | 345 |
| product_key | int | 客户购买的产品键 | 67 |
| store_key | int | 客户购买产品的商店键 | 48 |
| order_id | int | WebTower9 或 Jade 订单 ID | 7852299 |
| line_number | int | WebTower9 或 Jade 订单行号 | 2 |
| quantity | decimal(9,2) | 客户购买的产品单位数量 | 2 |
| unit_price | money | 购买的产品单个单位的原始货币价格 | 6.10 |
| unit_cost | money | 产品单个单位的直接和间接成本（原始货币） | 5.20 |
| sales_value | money | 数量 × 单价 | 12.20 |
| sales_cost | money | 数量 × 单位成本 | 10.40 |
| margin | money | 销售价值 - 销售成本 | 1.80 |
| sales_timestamp | datetime | 客户购买产品的时间 | 02/17/2008 18:08:22.768 |
| source_system_code | int | 此记录来自的源系统键 | 2 |
| create_timestamp | datetime | 记录在 DDS 中创建的时间 | 02/17/2008 04:19:16.638 |
| update_timestamp | datetime | 记录最后更新的时间 | 02/17/2008 04:19:16.638 |

在跨国公司中，可能需要定义额外的列来存储“全球企业货币”的度量以及汇率，以满足全球交易数据分析的需求。

综上所述，数据仓库项目需要全面考虑需求、数据风险和数据建模等方面，确保项目的顺利进行和数据的有效利用。

数据仓库项目的需求、风险与数据建模

4. 数据建模流程总结

为了更清晰地展示数据建模的整体流程，我们可以用 mermaid 流程图来呈现：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A([开始]):::startend --> B(明确业务需求):::process
    B --> C(设计维度数据存储 - DDS):::process
    C --> C1(分析业务领域):::process
    C1 --> C2(确定事实和维度属性):::process
    C2 --> C3(定义数据层次结构):::process
    C3 --> C4(映射 DDS 与源系统):::process
    C4 --> C5(定义数据转换规则):::process
    C --> D(设计规范化数据存储 - NDS):::process
    D --> D1(对 DDS 进行规范化处理):::process
    D1 --> D2(结合源系统数据设计 NDS):::process
    D --> E([结束]):::startend
    C5 --> D

这个流程图展示了从明确业务需求开始，到设计维度数据存储（DDS），再到设计规范化数据存储（NDS）的完整数据建模流程。

5. 数据建模中的注意事项

在进行数据建模时，除了前面提到的复杂业务逻辑处理和主键确定等问题，还有一些其他的注意事项：
- 数据类型的选择 ：在定义数据类型时，要根据实际需求和数据的特性进行选择。例如，对于键列，使用整数类型作为代理键，因为它们是简单的递增整数值。而对于度量列，根据数据的性质选择合适的数值或货币类型，如 SQL Server 中的 decimal 或 money 类型。对于时间戳列，使用 datetime 类型来准确记录时间。
- 数据的一致性 ：确保数据仓库中的数据与源系统中的数据保持一致。这不仅包括数据的数值一致，还包括业务逻辑的一致。在处理复杂业务逻辑时，要与业务人员和源系统代码进行充分沟通，避免出现数据不一致的情况。
- 性能优化 ：在设计数据模型时，要考虑性能优化。例如，合理选择主键和聚簇索引（后续物理数据库设计中会详细涉及），可以提高数据查询和检索的速度。同时，对于大表和复杂查询，要进行适当的优化，如使用分区表、索引优化等。

6. 数据风险应对策略总结

为了更方便地查看和对比不同数据风险的应对策略，我们将其整理成以下表格：
| 风险编号 | 风险描述 | 应对策略 |
| ---- | ---- | ---- |
| 1 | 无法在规定一小时内从 Jupiter 进行数据提取 | 构建简单 SSIS 包提取一周或一天等效数据，根据运行时间判断风险；若时间过长，需进一步优化 |
| 2 | 源系统无所需数据，无法满足功能需求 | 与业务项目经理沟通，看能否安排以文本文件或电子表格形式提供数据 |
| 3 | 数据存在但无法访问 | 了解源系统 RDBMS，若为专有系统且无驱动，与 DBA 讨论导出数据到文本文件；处理连接性问题，如打开防火墙漏洞 |
| 4 | 数据可用但需重组和清理 | 查询源系统发现问题，进行数据清理操作 |
| 5 | 可能无法使用现有 SAN，因数据量超容量 | 提前大致估计数据存储大小，根据结果考虑是否购买新磁盘；设计 DDS 和 NDS 后更准确估计 |
| 6 | 每日增量加载使源系统变慢 | 构建 SSIS 包模拟加载，测量性能；若下降，安排在非工作时间加载 |
| 7 | 用户无法不登录数据仓库使用前端应用 | 构建简单报告和 OLAP 立方体，在 SSRS 和 SSAS 上应用 Windows 集成安全 |
| 8 | 初始数据加载比预期时间长，影响项目进度 | 根据功能需求标准查询源系统，估计加载量，提前做好时间规划 |

7. 项目整体流程回顾

从需求定义到数据可行性研究，再到数据建模，整个数据仓库项目的流程可以用以下步骤总结：
1. 需求收集与审核 ：明确功能和非功能需求，进行完整性、可行性和对系统架构影响的审查，并获得相关人员签字确认。
2. 数据可行性研究 ：探索源系统，理解数据，识别数据风险，并制定应对策略。
3. 数据建模 ：根据业务需求设计维度数据存储（DDS）和规范化数据存储（NDS），确定事实表和维度表的结构、属性和关系。
4. 后续实施与优化 ：根据设计好的数据模型进行数据库的物理设计，包括主键确定、聚簇索引选择等，然后进行数据加载和系统测试。在实施过程中不断优化系统性能，确保数据仓库项目的顺利运行。

通过以上对数据仓库项目的需求、风险和数据建模的详细介绍，希望能够帮助大家更好地理解和实施数据仓库项目，提高项目的成功率和数据的利用价值。在实际项目中，要根据具体情况灵活运用这些方法和策略，不断总结经验教训，以应对各种挑战。