4. 数据仓库数据库与架构设计

数据仓库的物理设计不是“建一个库、建几张表”这么简单。它决定了后续 ETL 加载速度、查询性能、可维护性和扩展能力。本节围绕 SQL Server 平台，从数据库创建、Schema 规划、文件组管理、分区表、压缩与索引六个层面，给出一条可落地的设计路径。

一、数据库创建：先定排序规则与恢复模式

创建数据仓库数据库时，最先要确定的是排序规则（Collation）和恢复模式（Recovery Model）。排序规则影响字符串比较、连接和索引使用，一旦库建好再改代价极高。数据仓库通常建议使用与源系统一致的排序规则，避免 ETL 过程中出现隐式转换导致索引失效。恢复模式方面，若仓库允许在加载失败后重跑，可采用 SIMPLE；若要求可恢复到某个时间点，则用 FULL 并配合日志备份。

CREATE DATABASE DW_Sales
ON PRIMARY
( NAME = N'DW_Sales_Data',
  FILENAME = N'D:\SQLData\DW_Sales_Data.mdf',
  SIZE = 512MB, FILEGROWTH = 256MB )
LOG ON
( NAME = N'DW_Sales_Log',
  FILENAME = N'L:\SQLLog\DW_Sales_Log.ldf',
  SIZE = 256MB, FILEGROWTH = 128MB )
COLLATE Chinese_PRC_CI_AS;
ALTER DATABASE DW_Sales SET RECOVERY SIMPLE;

这里把数据文件放在 D 盘、日志放在 L 盘，是典型的 I/O 分离做法。数据仓库写入以批量加载为主，日志盘应使用顺序写性能较好的独立卷。

二、Schema 规划：按主题域分层

Schema 是数据库内的命名空间，用于把对象按职责分组。数据仓库推荐按分层 + 主题域组织，而不是把所有表堆在 dbo 下。常见划分：

• stg：暂存层，结构与源系统接近，用于快速落地原始数据；
• ods：操作数据层，做轻度清洗与标准化；
• dim：维度层，存放客户、产品、日期等维度表；
• fact：事实层，存放销售、库存等度量表；
• rpt：报表层，存放面向应用的宽表或聚合结果。

这样规划后，权限可以按 Schema 授予，例如只允许 ETL 账号写 stg 和 ods，只允许报表账号读 rpt，避免越权访问明细数据。

三、文件组管理：把大表与历史数据分开

文件组（Filegroup）是数据文件的逻辑容器。数据仓库中，建议至少划分：PRIMARY（系统对象）、FG_DIM（维度）、FG_FACT（事实）、FG_ARCHIVE（历史归档）。把事实表和历史分区放在独立文件组，可以单独备份、单独放到不同磁盘，也便于在分区切换时快速迁移。

四、分区表设计：按时间切分事实表

分区表适合数据量大、且查询常带时间条件的表。设计步骤是：先建分区函数，再建分区方案，最后在方案上建表。以销售事实表按年分区为例：

CREATE PARTITION FUNCTION PF_Year (int)
AS RANGE RIGHT FOR VALUES (2022, 2023, 2024, 2025);

CREATE PARTITION SCHEME PS_Year
AS PARTITION PF_Year
TO (FG_FACT, FG_FACT, FG_FACT, FG_FACT, FG_ARCHIVE);

RANGE RIGHT 表示边界值属于右侧分区，即 2022 归入 2022 年分区。分区键通常用日期代理键或年份列。分区表的最大收益是分区切换（SWITCH）：把 stg 中已加载好的数据以元数据操作瞬间并入事实表，几乎不产生日志和锁竞争。

五、压缩与索引策略

数据仓库以读为主、批量写为辅，适合使用页压缩（PAGE）。页压缩对重复度高的维度列和事实表外键列效果明显，通常可节省 50%～70% 空间，同时减少 I/O。行存储表建议对事实表使用 PAGE 压缩，对更新频繁的 stg 表可暂不压缩。

索引方面，事实表以聚集列存储索引（CCI）为主，适合大范围扫描和聚合；维度表保留聚集行存储索引，并在业务键上建唯一非聚集索引。若某些查询需要点查，可在事实表上补充非聚集索引，但要控制数量，避免拖慢批量加载。

六、落地检查清单

以上设计完成后，建议用一份小规模样例数据验证：向 stg 加载 100 万行销售记录，执行 SWITCH 并入事实表，观察耗时与日志增长；再对事实表执行一次聚合查询，对比压缩前后的逻辑读次数。只有经过验证的物理设计，才能真正支撑数据仓库的长期稳定运行。