数据仓库设计技巧PPT课件( 43页).ppt

数据仓库设计技巧PPT课件( 43页).ppt

《数据仓库设计技巧PPT课件( 43页).ppt》由会员分享，可在线阅读，更多相关《数据仓库设计技巧PPT课件( 43页).ppt（43页珍藏版）》请在冰豆网上搜索。

商业智能核心技术与应用,数据仓库设计,数据仓库的基本概念,数据仓库是面向主题的、集成的、稳定的、随时间不断变化的数据库系统。

它介于数据源与多维数据库之间，起到承上启下的作用。

数据仓库是通过对来自不同的数据源进行统一处理及管理，通过灵活的展现方法来帮助决策支持。

数据仓库的设计理念,在设计仓库数据库之初把用户的分析需求纳入考虑范围是十分有必要的。

同时，数据仓库的构建必需基于业务数据库，业务数据源的结构也是不得不考虑的问题。

因此在设计数据仓库的时候，应该坚持用户驱动与数据驱动相结合的设计理念。

业务数据模型设计的设计范式,1NF如果一个表中没有重复组（即行与列的交叉点上只有一个值，而不是一组值）,且定义了关键字、所有非关键属性都依赖于关键字，则这个表属于第一范式（常记成1NF）2NF如果一个表属于1NF，且不包含部分依赖性，既没有任何属性只依赖于关键字的一部分，则这个表属于第二范式（常记成2NF）。

3NF如果一个表属于2NF，且不包含传递依赖性（即没有一个非关键属性依赖于另一个非关键属性，或者说没有一个非关键属性决定另一个非关键属性），则这个表是第三范式（常记成3NF）。

业务数据模型设计的ER图表示,ER模型（实体联系模型）简称ER图。

它是描述概念世界，建立概念模型的实用工具。

ER图包括三个要素：

实体、属性、实体之间的联系联系归结为三种类型：

一对一联系（1:

1）设A、B为两个实体集。

若A中的每个实体至多和B中的一个实体有联系，反过来，B中的每个实体至多和A中的一个实体有联系，称A对B或B对A是1:

1联系。

一对多联系（1:

n）如果A实体集中的每个实体可以和B中的几个实体有联系，而B中的每个实体至我和A中的一个实体有联系，那么A对B属于1:

n联系。

多对多联系（m:

n）若实体集A中的每个实体可与和B中的多个实体有联系，反过来，B中的每个实体也可以与A中的多个实体有联系，称A对B或B对A是m:

n联系。

多对多联系举例,每个统计特征对销售人员来说是怎么样的呢？

数据仓库模型设计最佳实践,数据仓库模型设计主要分三个阶段：

1、概念设计2、逻辑设计3、详细设计并分别产生三类设计模型1、主题域模型2、业务数据模型3、物理模型,8,数据仓库模型设计采用迭代式开发，这一点也符合数据仓库系统迭代开发的特点。

它具有较好的灵活性和易变性，适应于主题不明确或不确定的需求。

概念设计,数据仓库是面向主题来组织数据，一个数据仓库有若干个主题，而每个主题又有一个数据集合体做支撑，这个数据集合称为主题域。

概念设计的中心工作是在需求分析基础上设计的主题域模型。

主体域模型是客观到主观之间的桥梁，是与硬件环境、软件选择无关的数据抽象模型，是为下一步建立业务数据模型、物理模型服务的概念性工具。

主题域具有两个特性1、独立性，即主题域具有明确的边界与独立的内涵，虽然主题间可以有交叉，但不影响其独立性。

2、完备性，即每个主题的分析要求所需的数据均应能在主题域中得到。

采用概念数据模型设计就是要设计主题域的数据结构。

数据仓库项目的主题域模型示例,逻辑设计,逻辑设计设计到的知识点包括：

业务数据模型设计的建模对象应包含实体、属性、关键字和联系。

业务数据模型设计应该遵守规范化准则：

即第三范式设计准则。

业务数据模型的ER图表示法。

逻辑设计的中心工作是设计业务数据模型，业务数据模型是用具体的软件结构来实现概念数据模型。

目前数据仓库一般是建立在关系数据库基础上，因此数据仓库的设计中采用的业务数据模型就是关系模型。

业务数据模型设计的建模对象,实体我们把客观存在并且可以相互区别的事物称为实体。

实体可以是实际事物，也可以是抽象事件。

属性描述实体的特性称为属性。

关键字如果某个属性值能唯一地标识出实体集中的每一个实体，可以选作关键字。

联系实体集之间的对应关系称为联系，它反映现实世界事物之间的相互关联。

联系分为两种，一种是实体内部各属性之间的联系。

另一种是实体之间的联系。

逻辑设计方法定义实体,逻辑设计方法定义实体层级,逻辑设计方法定义量度组,逻辑设计方法定义关系,逻辑设计的关键因素,粒度特例,详细设计,物理模型是从业务数据模型创建而来的，建立物理模型通过扩展业务数据模型，使模型中包含关键字和物理特性。

物理模型设计包括：

设计存储结构创建实体设计索引策略创建索引设计存储策略创建分区,设计存储结构创建实体,创建物理实体表视图约束,创建事实表,只包括主键、外键和度量,事实表,一个OLAP模型可以有多个事实表事实表经常有millionsofrows事实往往是数字量度有些事实可以被累加，另一些不能最小粒度原则不欢迎描述性属性（瘦高vs.矮胖）,创建维度表,维度描述事实逻辑上通过key关联维度表往往包含相当多的属性典型的属性是文本的、离散的维度往往含有层次主键往往是系统产生的primarykey很可能是共享的,维度表设计,常规维度主键代理键（可选）名称排序键（可选）自定义汇总公式（可选）父子维度父键一元运算符（可选）,数据仓库的星型结构,Employee_Dim,EmployeeKey,EmployeeID.,EmployeeKey,Time_Dim,TimeKey,TheDate.,TimeKey,Product_Dim,ProductKey,ProductIDProduceNameProductBrandProductCategory.,ProductKey,Customer_Dim,CustomerKey,CustomerID.,CustomerKey,Shipper_Dim,ShipperKey,ShipperID.,ShipperKey,Sales_Fact,TimeKeyEmployeeKeyProductKeyCustomerKeyShipperKey,UnitsPrice.,TimeKey,CustomerKey,ShipperKey,ProductKey,EmployeeKey,维度键,数据仓库的雪花型结构,二级维度表,Sales_Fact,TimeKeyEmployeeKeyProductKeyCustomerKeyShipperKey,UnitsPrice.,Product_Brand_Id,ProductBrand,ProductCategoryID,Product_Category_Id,ProductCategory,ProductCategoryID,Product_Dim,ProductKey,ProductName,ProductSize,ProductBrandID,主维度表,雪花型结构的特点,节省存储空间一定程度上的范式,星型vs.雪花型,Whichoneisbetter?

长期以来的争论两种观点各有支持者争论在继续目前看来，大部分更加倾向于星型,支持星型维度的论点,事实表总会是很大的，在维度表上节省的空间相对来说是很小的增加了数据模型的复杂度查询操作概念上更复杂了从数据仓库到多维数据库的加载时间会更长因此，只有当维度表极大，存储空间是个问题时，才考虑雪花型维度简而言之，最好就用星型维度即可,支持雪花型维度的论点,从数据仓库到多维数据库的加载过程中，雪花型维度的效率更高。

雪花型维度描述了更清晰的层次概念。

只有当最终用户可能直接访问数据仓库时才考虑星型。

（而这是不被建议的）。

思考：

PrimaryKey与Key,本身已经有了Key的标识以后，是否还需要PrimaryKey?

技巧：

创建数字主键,数字之间的比较永远比字符比较快得多。

物理存储时，数字简单得多，因为它们长度一样。

字符则不同。

内存中，字符占的空间大得多。

（4byte的指针+文本长度*2（Unicode）+2。

数字则仅有4bytes支持变化维度,注意,维度表与事实表不是绝对的同一个表，可以同时是维度表与事实表同一个表，可以有时是维度表，有时是事实表,创建“父子型”维度,父子维度,缓慢变化维,不变化更新新增举例：

当某销售人员从一个部门调至另一个部门，他的历史业绩该如何核算？

创建物理模型,主键：

PK_，整型自增外键：

FK_排序键：

Sort_字符类型：

nvarchar量度类型：

float、numeric,创建视图、约束,视图尽量少用或不用视图，以避免意想不到的逻辑陷阱约束尽量使用约束，以确保数据的完整性。

正确的数据所带来的益处会远远大于ETL性能的损失。

设计索引策略创建索引,创建索引用以提高查询速度避免索引对ETL的不良影响,设计存储策略创建分区,分区存储后的数据单元易于：

重构索引重组恢复监控,设计数据更新,数据提取是捕获源数据的过程。

有两种捕获数据的主要方法,

（1）完全刷新：

对移入中间数据库的数据进行完全复制。

该复制可能替换数据仓库中的内容，及时在新的时间点上添加完整的新副本，或者与目标数据进行比较，以便在目标中生成一条修改记录。

（2）增量更新：

只捕获源数据中修改的数据，如何捕获数据修改与数据源本身是密切相关的，实际上是逐个实现的问题。

数据更新-增量抽取,动手实验,动手实验,主题：

分选分析分析需求：

根据分选前后数据，分析各分选点的不同产品产出结构情况。

分析角度：

日期，分选前物料，分选后物料，物料分类，分选点，供应商，国家，产地，皮种，分选前数量，分选后数量,