学习

这一页有部分内容暂时无法显示，其余内容完整。

A. 数据仓库（Data Warehousing）概念与动机

从操作型数据库到数据仓库
文稿将“操作型数据库（Operational Databases）→ 多维视图（Multidimensional view）→ 数据仓库（Data Warehouse）”作为演进路径，说明分析型需求催生了多维视角与新的存储组织方式。
ETL 的角色
把操作型数据库中的数据抽取、转换并加载到数据仓库的整个过程称为 ETL（Extract, Transform, Load）。该过程是从操作性数据到仓库数据的桥梁。
为什么需要新的建模技术
为支持对同一数据集的“多维视图”，需要新的建模方法；数据仓库可被理解为“具有多维的立方体（cube）”，其底层以**星型模式（Star schema）**等模式来实现。
为何需要 OLAP
由于数据仓库的存储结构与规模，检索大量记录并对海量数据进行“即时汇总（on the fly）”需要 OLAP（On-Line Analytical Processing） 工具的支持。
面向商业智能（BI）的消费形态
在数据仓库之上，常用的洞察载体包括：报表（Reports）、图表（Charts）、仪表板（Dashboards）与交互式数据导航。这些共同构成组织的 Business Intelligence 能力。
核心动因：决策支持
文稿多次强调：对高效决策支持系统（DSS）的需求 促使新的数据存储设施——数据仓库——的出现。

星型模式的定义与缘起
星型模式是将多维决策支持数据映射到关系型数据库的一种数据建模技术。之所以发展出该模式，是因为传统的 ER/范式化 并不能很好满足高级数据分析的结构诉求。
三大组成：事实（Facts）、维度（Dimensions）、属性（Attributes）。
- 事实（Facts）：用于刻画业务活动的数值型度量（如销售金额）。
- 维度（Dimensions）：为事实提供观察视角的限定条件（如地点、时间、产品等）。
- 属性（Attributes）：维度下的进一步细分信息（文稿在结构图中标注“3. Attributes”并在后续练习中要求为各维定义属性）。

业务背景（操作系统）
招生办公室面向国际学生处理入学、缴费与营销（常通过海外代理）；该处维护全部国际学生详情与缴费信息。学校为多校区，第一门课常经代理办理，后续课程多由学生直接与学院对接；国际学生按学期多次缴费。
分析需求（面向数据仓库）
学院希望通过数据仓库回答至少以下问题：
1. 特定国家带来的总收入；
2. 某年特定研究生课程的总收入；
3. 各代理带来的总收入；
4. 每年产生的缴费笔数。
作业任务（建模与实现）
根据给定表数据，请：
1. 明确主要事实；
2. 定义与描述可能的维度；
3. 绘制学生注册主题的星型模式；
4. 为各维度定义属性；并在实验中实现该数据仓库。

启发

此处有一段内容暂不支持显示。

下列为基于讲义内容的操作建议（便于你在实验与作业中使用）：

确定主题与事实：以“缴费/收入”为主题，先界定度量（如金额、笔数）与粒度（如按笔、按学生-课程-学期）。
识别维度与属性（对照案例问题）：
- 国家维（国家→地区层级等）；
- 课程维（课程、层次、学院、校区等）；
- 时间维（年、学期、月份等）；
- 代理维（代理标识、代理国家、合作类型等）；
- 学生维（可按需求保留匿名化的人口统计属性）。
绘制星型模式：1 张事实表（度量列：收入金额、缴费笔数；外键指向各维），若需可加派生/预计算指标以便 OLAP。
准备到实现：基于 ETL 将操作系统表清洗、整合、维表标准化（字典化）、事实表生成与加载，最后接驳 BI/可视化工具进行验证。

数据仓库通过 ETL→星型建模→OLAP/BI 消费 的链路，把分散的操作数据转化为面向决策的多维数据资产；案例任务要求你围绕“收入/缴费”主题完成从事实与维度定义到仓库实现的全流程设计。