第一章
数据仓库和商业智能(DW和BI)的目标
1、DW/BI系统首先要能方便地存取数据
2、DW/BI必须以一致的形式展示信息。具体体现在，对于不同性能度量参数，具有不同的名称。
3、DW/BI系统必须能够适应变化。当业务发生变化时，已存在的数据和应用不能被破坏。
4、DW/BI系统必须能够及时展示信息。
5、DW/BI中的数据必须有安全保障措施。
6、DW/BI必须成为提高决策制定能力的权威和可信的基础。
7、DW/BI成功的标志是业务群体接受DW/BI系统。
维度建模
维度建模是实现DW和BI的首选技术，原因是以用户可理解的方式发布数据，且提供了高效的查询性能。维度建模的设计模型必须保持简单，复杂的数据模型最终会导致模型过度复杂，导致查询性能下降。
维度模型不要求符合数据库的范式(NF)，过于严谨的模型会导致用户在查询时过于复杂，维度模型对数据进行了一种以用户可理解的、满足查询性能要求的、灵活多变的方式进行了包装。
在关系型数据库中实现的维度模型称为星型模型
在多维数据库环境中实现的维度模型称为联机分析处理(OLAP)多维数据库，在数据库中对数据建立索引和其他优化方法，可以获得高效的性能查询。
一般是将事实数据加载到星型模型中，然后将OLAP多维数据库移植到星型模型上。
事实表和维度表
事实表中的每一行数据都代表一个度量事件，每行中的数据是一个特定级别的细节数据，称为粒度，维度建模的核心原则之一就是同一事实表中的所有度量行必须具有相同的粒度。
一个事实表以外键关联着许多维度表，这里以销售事实表为例，销售事实表包含着商品ID，品种ID，产商ID等，这些ID以外键的形式和其他维度表关联，如商品维度表，产商维度表，维度表中有着许多属性值，比如商品维度表有着商品名称，原料，生产日期等属性值，一般BI系统通过维度表来对数据进行查询，因此维度表的属性值必须设置地简单，不要有一些智能含义，比如前两位数字代表商品类别，3~4位代表生产日期，如果有这些属性值，应该尽可能地拆分出来，以不同的维度属性展现给用户，方便数据过滤、分组和制作报表等工作。
从上面这段可以看出来，维度表的数据的入口，可以这么认为，维度表的好坏直接关系到数据仓库的好坏，DW/BI的分析能力直接取决于维度表的质量和深度。因此，在搭建数据仓库时，首先应该把维度表构建地足够的完善。强大的维度属性能够带来强壮的分片-分块分析能力。
下面是一个产品的维度表
可以看到，该表格中的数据存在不少的冗余，当然可以把品牌名称，类别名称等维度信息再抽出来成为一个维度表，如果再抽出来的来，这种模型就称为雪花模型，但是维度表并不要求要和关系型数据库一样，不一定非要规范化。这是因为和事实表相比，维度表占用的空间实在是小得多，冗余的数据对数据仓库的总容量不会产生较大的影响，一般维度表的建立往往需要关注简单性和可访问性。
DW/BI架构
DW/BI分为四个组成部分，分别是：操作型原系统、ETL系统、数据展现和商业智能应用
操作型原系统其实可以认为是在BI之外的，操作型原系统的目的是用于获取业务数据，很难在原系统处进行数据的查询，原系统主要关注的是系统的可用性和处理性能。
ETL系统的第一步是获取数据，理解数据源并导入数据，以便于后续的数据操作。
ETL包括了数据的清洗(消除拼写错误、解析为标准格式等)、合并来自不同数据源的数据等。
ETL系统的主要任务是在交付过程中划分维度和事实。
展示区的主要作用是支持组织、存储数据，支持用户、报表的制作，以及其他分析性商业智能(BI)的查询，展示区最好有足够详细的原子数据，如果仅有聚合后的数据而没有详细的原子数据，无法满足用户变化的需求。此外，展示区不能仅设计为完成每日普通报表，还要考虑下和其他部门的交叉部分。例如销售事实数据，除了得出销售额这些基本的报表之外，还要考虑到公司的其他部门如市场部门，财务部门等部门业务。最后，维度表的维度设计必须是公共的、一致性的，如果没有一个公共一致的维度，那么维度模型的使用就有局限性，如果想要建立一种健壮的、集成的DW/BI环境，必须要有一个公共一致的维度模型。
商业智能应用泛指为用户提供利用展示区制定分析决策的能力
