数据仓库toolkit笔记1，Dimensional Modeling Primer

[b]数据仓库管理员的主要职责：[/b]
1，通过业务领域、工作职责和计算机能力来理解用户
2，通过数据仓库来确定业务用户所需要做的决定
3，使用数据仓库区分最好的用户：制定高效的、大影响力的决定的用户
4，找到潜在的新用户并让它们了解数据仓库
5，选择最有效、最易操作的数据子集到数据仓库，而不是将汪洋大海般的数据都弄过来
6，使得用户界面和应用简单、模板化，特别是匹配用户的认知和理解能力
7，确保数据准确且可信任，让数据保持一致性
8，持续监控数据和发布的报表的准确性
9，搜索新的数据源，持续改进数据仓库，从而适应报表需求和核心业务
10，通过展示数据仓库的业务决策所带来的好处而证明你的软件、职业、硬件开销有价值
11，按规律发布数据
12，保持业务用户对你的信任
13，维持业务用户、执行赞助和老板happy

[b]数据仓库的组件：[/b]
1，Operational Source System
即应用遗留系统
2，Data Staging Area
做ETL（extract-transformation-load）的地方，从Operational Source System抽取数据，过滤、合并、消重、转换数据格式，然后加载到展示区
Data Staging Area就相当于厨房，拿到很多原材料，加工之后成为美味佳肴，送给餐厅
Data Staging Area的核心架构需求就是它限制业务用户访问，且不提供面向查询和展示的服务
3，Data Presentation Area
含有一系列的数据集市，每个数据集市展现了一个单独的业务进程需要的数据，这些业务进程跨越了组织功能的界限
数据集市采用dimensional modeling和star schema，和3NF建模方式不同
第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分
第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖
第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式
鲍依斯-科得范式（BCNF）：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式
在可查询的Data Presentation Area里的数据必须是dimensional、atomic，必须依附于数据仓库总线架构
4，Data Access Tools
依赖于Data Presentation Area的多种建模、查询、报表、分析、数据挖掘工具

[b]Dimensional Modeling：[/b]
1，Fact Table
包含业务数据的表，如daily_sales_fact_table(date, product_key, store_key, quantity_sold, dollar_sales_amount)
fact table分三种粒度类别：transaction/periodic snapshot/accumulating snapshot
2，Dimension Table
Dimension table是fact table的entry point，包含了业务对象的文本描述，如
product_dimension_table(product_key, product_description, sku_number, brand_description, category_description, department_description,...)
Fact table和Dimension table需要join来查询数据，所以又称之为join star schema
每个数据集市可能包含多个fact tables，每个fact table可能对应5到15个dimension tables

现在FW的数据仓库模型就是这样，AS的log和UI/BVI的metadata被extract到BE做ETL，生成Fact table和Dimension Table供UI reporting使用
但是遇到的问题是fact table只有一个，而且特别大，所以可以按业务逻辑相应拆分
另外没有periodic snapshot和accumulating snapshot，加上后对Reporting的performance就会好很多