6.审计维度生成系统（Audit Dimension Assembler System）
主要功能是将与事实表相关的元数据内容加载到一张审计维度表中，这样最终用户可以像查看普通维度一样查看与事实表相关的元数据。
7.数据质量过滤系统（Quality Screen Handler System）
主要功能是在ETL的处理过程中自动的检测所有的数据质量问题。检测的结果将进入错误事件处理系统（详见子系统8）。
8.错误事件处理系统（Error Event Hander System）
主要功能是全面的记录和报告在ETL处理中的所有的错误事件。包括各类错误的分枝处理逻辑，还包括对ETL处理中数据质量的实时监控。
9.代理键生成系统（Surrogate Key Create System） 主要功能是以一种鲁棒的机制生成流水的代理键，生成规则不依赖与任何维度，也不依赖与任何数据库实例，可以支持分布式系统。
10.缓慢变化维处理系统（Slowly Changing Dimension Processor，SCD）
主要功能是处理维度表的属性随时间变化的情况，处理方式为：类型1（直接覆盖），类型2（生成新行），类型3（添加新列）。
11．迟到维度处理系统（Late Arriving Dimension Handler）
主要功能是当维度数据的变化情况到达数据准备区的时间晚于对应的事实数据时，对维度数据的插入和更新策略。
12．固定层级结构生成系统（Fixed Hierarchy Dimension Builder）
主要功能是对维度表中各类多对一关系的层级结构进行数据有效性检查和维护。 13．可变层级结构生成系统（Variable Hierarchy Dimension Builder）
主要功能是对维度表中所有的层深可变的层级结构的的数据有效性检查和维度，例如组织的层级结构，零件的层级结构等。
14．多值维度桥接表生成系统（Multivalued Dimension Bridge Table Builder） 主要功能是建立和维护桥接表，用来描述维度间的多对多关系。 15．杂项维度生成系统（Junk Dimension Builder）
主要功能是将来自多个数据源的多个低基数的标志字段、状态字段等小型维度建立成一个杂项维度，并对之进行维护。
16．交易粒度事实表加载系统（Transaction grain fact table loader）
主要功能是更新交易粒度事实表，包括对数据、索引和分区的处理。通常是用来处理增量数据，即最新的数据。需要使用代理键替换管道系统（详见子系统19）。
17．周期快照事实表加载系统（Periodic snapshot grain fact table loader）
主要功能是更新周期快照事实表，包括对数据、索引和分区的处理。包括对当期数据的增量更新策略。需要使用代理键替换管道系统（详见子系统19）。
18．累计快照事实表加载系统（Accumulating snapshot grain fact table loader）
主要功能是更新累积快照事实表，包括对数据、索引和分区的处理，同时更新维度外键和累积事实。需要使用代理键替换管道系统（详见子系统19）。
19．代理键替换管道系统（Surrogate key pipeline）
主要功能是使用多线程技术将来到数据仓库数据的自然键替换为代理键。 20．迟到事实处理系统（Late arriving fact handler） 主要功能是处理对迟到事实记录的插入和更新策略。 21. 聚合生成系统（Aggregate builder）
主要功能是创建和维护数据库物理结构，比如说聚合表，用于和 query-rewrite 技术配合使用，以提高数据库查询性能。也包括独立的聚合表和物化表。
22. 多维cube生成系统（Multidimensional cube builder）
主要功能是创建和维护星型架构用于装载多维cube，包括cube技术的一些专有工作，比如维度层次结构的维护。
23. 实时分区生成系统（Real-time partition builder） 三种事实表类型（参照子系统16，17，18）的特殊逻辑在内存中维护着一个“热分区”，它只包含最近一次已经统计到数据仓库表中以后的部分增量数据。
24. 维度管理子系统（Dimension manager system） 顾名思义，它是一个管理维度表的系统。它负责从集中存放维度表和事实表之间的维度一致性，请参照子系统25.
25.事实管理系统（Fact table provider system） 对应于维度表管理系统，它是一个事实表的管理系统，它接收从维度管理系统发过来的一致性维度。包括本地键替换，维度版本检查，和聚合表等维护系列工作。
26.任务调度系统（Job scheduler） 它负责ETL任务的安排和启动。它能够等待各种系统条件包括对优先级高的任务完成的依赖。能够针对异常情况发送警告。
27.工作流程监视系统（Workflow monitor）
它的主要功能是有控制台和报表系统用以监控ETL任务被任务调度系统启动以后的执行状况。包括处理的记录条数，错误摘要，和执行的活动。
28.恢复和重做系统（Recovery and restart system）
当任务执行过程中任务暂停后的重新启动，或者是恢复到任务执行前的状态重新执行。这个子系统严重依赖于备份子系统（参考子系统38）
29.并行处理和管道处理系统（Parallelizing/pipelining system）
它的主要功能是利用多处理器，网格计算资源以提高性能，和实现数据流处理。当不是写硬盘操作或者是执行过程中等待一个条件的发生的ETL的情况，是有必要采用并行化和管道化的。
30.异常放大系统（Problem escalation system）
它的主要功能是负责在一定的条件下提高错误的级别以跟踪和解决问题。包括简单错误日志记录，操作者通知，管理员通知和系统开发人员通知。
31.版本控制系统（Version control system） 使得元数据的归档能够有坚固的快照功能，可以查阅某一时刻改变前后的状态。能够迁入和迁出所有ETL模块和任务。源代码对比功能以快速展示改变前后的不同。
32.版本移植系统（Version migration system）
让程序可以在开发环境，测试环境，正式环境快速切换。版本控制系统的用于恢复移植的一个接口，也是配置完整数据库连接信息的一个接口。使得代理键生成不依赖于数据库的位置。
33.体系和依赖分析系统（Lineage and dependency analyzer）
对任何选中的数据组件，都要展示它的物理数据源和所有的后来的转换，不管是选中ETL管道中间的组件，或者是选中最终的数据结果，都一样展示。对任何选中的数据组件，都要展示它的下游的数据组件和可能会造成改变的最终数据结果的字段结构，不管是选中ETL管道中间的组件，或者是选中数据源，都一样展示。
34.符合规定报告系统（Compliance reporter） 符合规定的规则以证明系统报告的可信度。证明数据和转换没有改变。展示谁访问过或者改变过任何数据。
35.安全控制系统（Security system）
在ETL的管道中，实现对所有数据和元数据基于角色的权限控制。证明模块的版本没有改变。展示谁做过任何更改。
36.备份系统（Backup system）
对数据和元数据的备份，用于以后的数据的恢复，重启，安全，和符合规定的要求。 37.元数据管理系统（Metadata repository manager）
用于捕获和维护所有ETL的元数据的系统，包括所有转换逻辑。包括处理元数据，技术元数据和业务逻辑元数据。
38.项目管理系统（Project management system） 对所有ETL任务进行开发的跟踪系统。
1.1.12 数据库及数据仓库模型设计的三个主要步骤？
1. 概念数据模型（conceptual data model）
概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个主要步骤。
概念数据模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，它以数据类的方式描述企业级的数据需求，数据类代表了在业务环境中自然聚集成的几个主要类别数据。
概念数据模型的内容包括重要的实体及实体之间的关系。在概念数据模型中不包括实体的属性，也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。
概念数据模型的目标是统一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系。
在有些数据模型的设计过程中，概念数据模型是和逻辑数据模型合在一起进行设计的。
2. 逻辑数据模型（logical data model）
逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。
逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。
逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑数据在物理上如何来实现。 逻辑数据建模不仅会影响数据库设计的方向，还间接影响最终数据库的性能和管理。如果在实现逻辑数据模型时投入得足够多，那么在物理数据模型设计时就可以有许多可供选择的方法。
3. 物理数据模型(physical data model) 物理数据模型设计与概念数据模型设计、逻辑数据模型设计是数据库及数据仓库模型设计的三个主要步骤。
物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。
物理数据模型的内容包括确定所有的表和列，定义外键用于确定表之间的关系，基于用户的需求可能进行发范式化等内容。在物理实现上的考虑，可能会导致物理数据模型和逻辑数据模型有较大的不同。
物理数据模型的目标是指定如何用数据库模式来实现逻辑数据模型，以及真正的保存数据。
1.1.13 什么是多值维度，怎么处理多值维度？
在维度建模的数据仓库中，有一种维度表叫多值维度(multivalue dimension)。
多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多个值,第二种情况是事实表在某个维度表中有多条对应记录。
处理多值维度最好的办法是降低事实表的粒度。但是有些时候，事实表的粒度是不能降低的，多值维度的出现是无法避免的。这时，可以采用桥接表技术进行处理。在维度表属性间建立桥接表。这个桥接表可以解决维度属性之间的多对多关系，也解决掉的维度表的多值维度问题。
总之，多值维度是应该尽量避免的，它给数据处理带来了很大的麻烦。如果多值维度不能避免的话，应该建立桥接表来进行处理。
1.1.14 什么是缓慢变化维？怎么处理缓慢变化维？
缓慢变化维（Slowly Changing Dimensions、SCD）。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。
处理缓慢变化维的方法通常分为三种方式。
第一种方式是直接覆盖原值。这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息。
第二种方式是添加维度行。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。
第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用TYPE 1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。
在实际建模中，我们可以联合使用三种方式，也可以对一个维度表中的不同属性使用不同的方式，这些，都需要根据实际情况来决定，但目的都是一样的，就是能够支持方便的分析历史变化情况。
1.1.15 目前有两种比较通用的数据仓库建模方式
一种是维度建模，另一种是三范式建模。
1.1.16 数据仓库的两种架构和各自特点
星形架构（聚合速度快，占有存储空间小）
雪花型架构的特点（节省存储空间，一定程序上的范式，聚合速度慢）
1.1.17 如何处理海量数据的处理
选用优秀的数据库工具
编写优良的程序代码 分区操作
建立广泛的索引 建立缓存机制 加大虚拟内存
对数据进行分批次操作 使用临时表和中间表 优化SQL查询语句 使用文本格式进行处理
定制强大 的清洗规则和出错处理机制 建立视力或者物化视图 避免使用32位机 考虑操作系统问题
使用数据仓库和多维数据库存储 使用采样数据进行数据挖掘
1.1.18 Cube的几种存储方式？
MOLAP，ROLAP,HOLAP
1.2 数据分析
数据仓库、商业智能相关面试题(带答案)【精品文档】
