《Star Schema完全参考手册》章节试读

《Star Schema完全参考手册》的笔记-第63页 - 过程处理中的事实表

为了便于分析研究，应该为每个过程建立一个事实表。
如何判断给定的两个事实是否属于同一个过程？
1，这些事实是否同时发生？
2，这些事实是否可以用在同一个粒度？
如果其中一条不满足，说明两个事实不属于同一个过程。

《Star Schema完全参考手册》的笔记-第107页 - 深度学习维度表

1，将维度分组到表中
需要确定维度属性是属于同一个表还是多个表，其实可以根据直觉判断，如果抽象成理论则是：对于有亲密关系的维度放到同一个表里，对于有同时浏览需求的维度放到同一个表里。

《Star Schema完全参考手册》的笔记-第52页 - 第4章 过程处理中的事实表

一个过程对应一个事实表
如果两个事实，不是同时发生或者粒度不同，就是两个过程

《Star Schema完全参考手册》的笔记-第16页 - 数据仓库体系结构

三类体系结构：
1，INMON，企业信息化工厂
2，KIMBALL，维度数据仓库
3，独立数据集市
INMON和KIMBALL体系结构相同点：
1，操作系统和分析系统是分离的
2，ETL过程整合了多种类型操作型系统的数据，将信息集中到一起，保存到一个单独的数据仓库中
区别：
1，KIMBALL是根据维度建模的原则设计的，而INMON是根据ER模型设计的。
2，KIMBALL能被分析型系统直接访问。
3，INMON里数据集市是为部门使用重新组织整理的，而KIMBALL的数据集市是包含在数据仓库里的
4，INMON里只有数据集市是按照维度设计的，而KIMBALL是全部按照维度设计的。

《Star Schema完全参考手册》的笔记-第35页 - 星型模型与多维数据集

星型模型：事实表和维度表相关联，为维度表分配一个代理键，用于唯一地区分表中的每一条记录。
缓慢变化维：维度属性也会变化，但是相对于快速变化的事实表，维度变化比较缓慢，因此被称为缓慢变化维。
缓慢变化维的两种处理方法：
1，当一个维度值的源发生变化，并且不需要在星型模型中保留历史记录时，仅仅使用变化的值重写维度即可。
2，大部分的维度值变化需要记录历史。
多维数据集：
多维数据集预先计算好维度值和事实值来获取各种组合值。该方式的优势1是速度快，优势2是不受SQL限制。缺陷在于预先准备的数据量过大。

《Star Schema完全参考手册》的笔记-第3页 - 分析型数据库与维度设计

基本概念：
(1)操作型系统：直接支持业务系统的执行，就是通常所说的OLTP（联机事物处理系统），主要的操作类型包括插入、删除、查询、更新，使用基于第三范式的实体－关系设计
(2)分析型系统：支持对业务系统的评价，应该就是通常所说的OLAP（联机分析处理系统），主要的操作类型就是查询，使用维度设计（星型模型或者多维数据集）
(1)星型模型：针对关系型数据库的维度设计被称为星型模型，相关维度成为维度表中的列，事实则存储在事实表的各个列中。星型模型的示意图(2)雪花模型：星型模型中并不是严格遵守第三范式，比如在星星模型中商品维表中会带上品牌信息，按照第三范式，非关键字之间应该相互独立，品牌应该单独做一张表，这种设计被称为雪花模型，附加表通常被叫做支架表。

《Star Schema完全参考手册》的笔记-第83页 - 维度一致性问题

这一章内容不知道是理解问题还是翻译上的问题，没有很看明白到底是在讲什么，准备之后对照下英文版再看下，先跳过。