事实表

事实表与维度表设计是数据仓库中的重要组成部分，用于有效管理和分析数据。事实表记录了业务过程的事实，而维度表则包含了描述事实表中数据的上下文信息。通过合理的设计方法，可以确保数据仓库的高效运作和数据分析的准确性。

账户活动事实表 账户活动事实表提供账户在特定期间内的活动摘要。例如，在月度快照中，每个账户都有一个记录，其中包含该月的所有活动。 维护策略 周期快照事实表通过一次性加载所有记录进行维护，并在当前紧迫滚动周期内进行增量更新。这确保了在整个历史周期内始终提供最新数据。 加载特性 周期快照事实表与事务粒度表具有相似的加载特性。在数据仓库加载过程中，所有记录将在每个周期性加载中按最近时间分区进行分组。

图5.5处理精确时间度量的事实表设计与日期维表不同，通常少有对分秒的描述。如果企业有定义明确时间片的属性（如轮班时间、广告时间等），可将这些属性定义为对午夜时点的偏移量。若粒度为分钟，则每日时间维度将产生1440条记录；若粒度为秒，则会有86400条记录。此时可采用之前描述的SQL日期时间戳设计。6.6大维度数据仓库中最有趣的维度包括客户、产品等，大企业客户维度通常有上百万记录，每条记录有上百个字段。大型个人客户维度则可能超过千万条记录，字段数多数时候较少。大维度通常由多个数据源衍生，企业中客户可来自多个账户管理系统，如银行中客户可能来自抵押、信用卡、支票和储蓄等多个业务部门。银行若欲创建所有部门客户维表，则需对这些独立客户列表进行剔重、规范化和合并，步骤见图5.6。

事实星座模式示例：以销售数据为例 销售事实表（Sales Fact Table） | 字段名 | 描述 ||---|---|| time_key | 时间维度键 || item_key | 商品维度键 || branch_key | 分支机构维度键 || location_key | 地理位置维度键 || units_sold | 销售数量 || dollars_sold | 销售额 || avg_sales | 平均销售额 | 运输事实表（Shipping Fact Table） | 字段名 | 描述 ||---|---|| time_key | 时间维度键 || item_key | 商品维度键 || shipper_key | 承运商维度键 || from_location | 起始地维度键 || to_location | 目的地维度键 || dollars_cost | 运输成本 || units_shipped | 运输数量 | 时间维度表（Time Dimension） | 字段名 | 描述 ||---|---|| time_key | 时间维度键 || day_of_the_week | 星期几 || month | 月份 || quarter | 季度 || year | 年份 | 地理位置维度表（Location Dimension） | 字段名 | 描述 ||---|---|| location_key | 地理位置维度键 || street | 街道 || city | 城市 || province_or_state | 省/州 || country | 国家 | 商品维度表（Item Dimension） | 字段名 | 描述 ||---|---|| item_key | 商品维度键 || item_name | 商品名称 || brand | 品牌 || type | 类型 || supplier_type | 供应商类型 | 分支机构维度表（Branch Dimension） | 字段名 | 描述 ||---|---|| branch_key | 分支机构维度键 || branch_name | 分支机构名称 || branch_type | 分支机构类型 | 承运商维度表（Shipper Dimension） | 字段名 | 描述 ||---|---|| shipper_key | 承运商维度键 || shipper_name | 承运商名称 || location_key | 承运商地理位置维度键 || shipper_type | 承运商类型 |

设计数据库时，有两个不争的事实：数据库中冗余的数据需要额外的维护，因此高质量的表应尽量减少冗余数据；数据库中经常变化的数据需要额外的维护，因此高质量的表应尽量避免数据频繁变动。评估数据库表设计的质量应考虑这些关键因素。

通过构建包含基础均衡、泡沫均衡、周期和混沌四种形态的多主体股市模型，并进行计算机仿真实验，本研究分析了不同市场形态下股票市场收益率的统计特征。 研究发现，四种市场形态都呈现出尖峰肥尾、波动聚集和长期记忆（PL）特性。其中，基础均衡状态下这些特征最为显著，周期和混沌状态次之，泡沫均衡状态最弱。

6.22 采用维度中的位置属性展现文本事实 在关系型数据库中，我们使用SQL语句存储一些具备严格约束的分析类型接口。这些接口需要在维度记录上展现复杂的对比。 案例分析 举例来说，假设我们希望测量所有客户的新旧程度、周期、强度的数值型值。可以邀请数据挖掘的同事，在被新旧程度、周期、强度标示的三维空间中识别自然群体。我们并不要求所有结果都以数值呈现，更倾向于在数据集市中对结果进行对比与分析，以便于找到隐含的自然群体与趋势。

设计数据库时，有两个不争的事实。数据库中冗余的数据需要额外的维护，因此质量好的一套表应该尽量减少冗余数据。数据库中经常发生变化的数据需要额外的维护，因此质量好的一套表应该尽量避免数据经常发生变化。评价数据库表设计的质量。

Oracle提供了查看表空间表信息的便捷方式。

表的扫描与驱动表示例：- select ename, sal from emp;（全表扫描）- select ename, sal from emp where sal > 1000;（部分扫描）问题：哪个语句执行速度更快？分析：在 sal 字段上建立索引的情况下，部分扫描语句（第 2 条）将比全表扫描语句（第 1 条）执行得更快。原则：尽量避免对大表进行全表扫描，尤其是在多表连接查询的情况下。