实施
使用较标准的技术以数据库模式将模型转换为物理实施。使用规范化建模技术创建关系模式，根据 Ralph Kimball 的介绍创建维度模式。创建混合模式意味着，首先复制关系模式，然后在关系模式上搭建维度结构层次。（“文件描述”边栏列出了实施中最重要的文件，包括具有 DDL、系统验证、查询和用于生成示例代码的自动分析的文件。）
因为只使用了三个非关键属性，所以在每个表中添加了 SIZING 属性，类型为 CHAR(100)，这样可使行大小更接近实际。
必须 设置某些数据库参数，以便出现星型连接并使用物化视图。重要参数如下所示：
NAME VALUE ------------------------------ -------------------- compatible 10.2.0.1.0 optimizer_features_enable 10.2.0.1 optimizer_mode first_rows pga_aggregate_target 83886080 query_rewrite_enabled true query_rewrite_integrity stale_tolerated sga_target 167772160 star_transformation_enabled true
按照 Oracle 文档中的详细描述使用 EXPLAIN PLAN 来验证是否出现星型连接。
三种模式都加载了相同的数据。加载了相同数据的最好证据就是，三种模式都对示例查询生成了相同的回答。
分析所用的数据量如下所示。
OWNER TABLE_NAME NUM_ROWS AVG_ROW_LEN LAST_ANALYZED
------ ------------ ---------- ----------- -------------------
DIM ACCOUNT_DIM 2000 128 2006-01-14:19-51-56
COVERAGE_DIM 900 17 2006-01-14:19-51-57
POLICY_DIM 6000 128 2006-01-14:19-51-58
PREMIUM_FACT 1371183 23 2006-01-14:19-52-14
TIME_DIM 3600 21 2006-01-14:19-52-39
VEHICLE_DIM 24000 130 2006-01-14:19-52-39
HYB ACCOUNT 2000 128 2006-01-14:19-53-42
COVERAGE 144000 28 2006-01-14:19-53-47
POLICY 6000 142 2006-01-14:19-53-53
PREMIUM 1373463 49 2006-01-14:19-54-41
TIME_DIM 3600 21 2006-01-14:19-55-08
VEHICLE 24000 144 2006-01-14:19-55-10
REL ACCOUNT 2000 124 2006-01-14:19-39-22
COVERAGE 144288 27 2006-01-14:19-39-30
POLICY 6000 138 2006-01-14:19-39-31
PREMIUM 1389963 29 2006-01-14:19-40-08
VEHICLE 24000 139 2006-01-14:19-40-13
目的是为了提供足够大的数据量，以阻止优化程序走捷径，例如阅读整个表时阻止其使用索引及其他此类会破坏分析的优化技术。按照 Oracle 数据库数据仓库指南 10 g 第 2 版 (10.2) — 模式建模技术，如果优化程序发现“太小而不值得转换的表”，则星形转换可能不会发生。
实施的一个相当任意的目标是事实表至少有一百万个行。如果 QUERIES.SQL 生成的所有维度查询计划和混合查询计划都符合星型连接标准，则使用的数据量看来足够进行当前的分析。
由于弱实体必须以维度模式表示，因此维度模式中的 COVERAGE_DIM 行的行数较其他两种模式的 DIMENSION 表中的行数少。
以下为各种模式占用的空间：
OWNER TOTAL_SIZE --------------- ---------------- DIM 129,499,136 HYB 244,056,064 REL 130,023,424
因为混合模式集关系和维度于一体，所以它的大小大概是关系模式和维度模式的大小之和，再除去所有通用元素，则得出以上数字。