维度设计基本方法
1、设计步骤：
1）第一步：选择维度或新建维度。
作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以淘宝商品维度为例，有且只允许有一个维度定义。
2）第二步：确定主维表。
此处的主维表一般是 ODS 表，直接与业务系统同步。以淘宝商品维度为例，s_auction_ auctions是与前台商品中心系统同步的商品表，此表即是主维表。
3）第三步：确定相关维表。
数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以淘宝商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、 SPU、卖家、店铺等维度存在关联关系。
4）第四步：确定维度属性。
本步骤主要包括两个阶段，其中第一个阶段是从主维表中选择维度属性或生成新的维度属性；第二个阶段是从相关维表中选择维度属性或生成新的维度属性。 以淘宝商品维度为例，从主维表（ s_auction_auctions）和类目、 SPU、卖家、店铺等相关维表中选择维度属性或生成新的维度属性。确定维度属性的几点提示：比如淘宝商品维度有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基础。
尽可能多地给出包括一些富有意义的文字性描述，比如商品维度中的商品ID 和商品标题、类目 ID 和类目名称等。 ID 一般用于不同表之间的关联，而名称一般用于报表标签，比如商品价格，可以用于查询约束条件或统计价格区间的商品数量，此时是作为维度属性使用的；也可以用于统计某类目下商品的平均价格，此时是作为事实使用的。另外，如果数值型字段是离散值，则作为维度属性存在的可能性较大；如果数 值型宇段是连续值，则作为度量存在的可能性较大，但并不绝对，需要 同时参考宇段的具体用途。
区分数值型属性和事实 数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性；如果通常
用于参与度量的计算， 则是作为事实。
尽量沉淀出通用的维度属性 有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表的不同宇段混合处理得到，或者通过对单表的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进行沉淀。一方面，可以提高下游使用的方便性，减少复杂度；另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。例如，淘宝商品的property 字段，使用 key:value 方式存储多个商品属性。 商品品牌就存存储在此字段中，而商品品牌是重要的分组统计和查询约束 的条件，所以需要将品牌解析出来，作为品牌属性存在。例如，商品是 否在线，即在淘宝网站是否可以查看到此商品，是重要的查询约束的条件，但是无法直接获取，需要进行加工，加工逻辑是：商品状态为0 和 l且商品上架时间小于或等于当前时间，则是在线商品g否则是非在线
商品。所以需要封装商品是否在线的逻辑作为一个单独的属性字段。
5）第五步：反规范化 将维度的属性层次合并到单个维度中的操作称为反规范化。
分析系统的主要目的是用于数据分析和统计，如何更方便用户进行统计分析决定了分析系统的优劣。采用雪花模式，用户在统计分析的过程中需要大量的关联操作，使用复杂度高，同时查询性能很差；而采用反规范化处理，则方便、易用且性能好。
2、维度整合
1）垂直整合：
" 即不同的来源表包含相同的数据集，只是存储的信息不同时，进行垂直整合。" “比如淘宝会员在源系统中有多个表，如会员基础信息表、会员扩展信息表、淘宝会员等级信息表、天猫会员等级信息表，这些表都属于会员相关信息表，依据维度设计方法，尽量整合至会员维度模型中，丰富其维度属性。”
水平整合：“即不同的来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。此时才用水平整合。” “比如针对蚂蚁金服的数据仓库，其采集的会员数据有淘宝会员、 1688 会员、国际站会员、支付宝会员等，是否需要将所有的会员整合到一个会员表中呢？如果进行整合，首先需要考虑各个会员体系是否有交叉，如果存在交叉，则需要去重；如果不存在交叉，则需要考虑不同子集的自然键是否存在冲突，如果不冲突，则可以考虑将各子集的自然键作为整合后的表的自然键；另一种方式是设置超自然键，将来源表各子集的自然键加工成一个字段作为超自然键。在阿里巴巴，通常采用将来源表各子集的自然键作为联合主键的方式，并且在物理实现时将来源字段作为分区字段。”
3、维度拆分
3.1水平拆分
3.1.1何时需要拆分？
由于维度分类的不同而存在的特殊的维度属性，可以通过水平拆分的方式来解决此问题。
3.1.2两种方案
方案一：将维度的分类实例化成不同的维度，同时在主维度表中保存公共属性；
方案二：维护单一维度，包含所有可能的属性。
3.2.3两个拆分依据
“依据一：是维度的不同分类的属性差异情况。
当维度属性随类型变化较大时，将所有可能的属性建立在一个表中是不切合实际的，也没有必要这样做，此时建议采用方案一” “比如在阿里巴巴数据仓库维度体系中，依据此方法，构建了商品维度、航旅商品维度等。公共属性一般比较稳定，通过核心的商品维度，保证了核心维度的稳定性；通过扩展子维度的方式，保证了模型的扩展性。”
“依据二：是业务的关联程度。
两个相关性较低的业务，耦合在一起弊大于利，对模型的稳定性和易用性影响较大。也要进行拆分，直接拆分成两个维度。” “比如在阿里巴巴数据仓库维度体系中，对淘系商品和 1688 商品构建两个维度。虽然淘系和1688 在底层技术实现上是统一的，但属于不同的BU，业务各自发展；在数据仓库层面，淘系和1688属于不同的数据集市，一般不会相互调用，业务分析人员一般只针对本数据集市进行统计分析。”
3.2 垂直拆分
为何做垂直拆分 “某些维度属性的来源表产出时间较早，而某些维度属性的来源表产出时间较晚；或者某些维度属性的热度高、使用频繁，而某些维度属性的热度低、较少使用；
或者某些维度属性经常变化，而某些维度属性比较稳定。在“水平拆分”中提到的模型设计的三个原则同样适合解决此问题。”
出于扩展性、产出时间、易用性等方面的考虑，设计主从维度。主维表存放稳定、产出时间早、热度高的属；从维表存放变化较快、产出时间晚、热度低的属性。 “比如在阿里巴巴数据仓库中，设计了商品主维度和商品扩展维度。其中商品主维度在每日的1 :30 左右产出，而商品扩展维度由于有冗余的产出时间较晚的商品品牌和标签信息，在每日的 3:00 左右产出。”
————————————————
概述
维度建模是一种将数据结构化的逻辑设计方法，它将客观世界划分为度量和上下文。度量是常常是以数值形式出现，事实周围有上下文包围着，这种上下文被直观地分成独立的逻辑块，称之为维度。它与实体-关系建模有很大的区别，实体-关系建模是面向应用，遵循第三范式，以消除数据冗余为目标的设计技术。维度建模是面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计技术。
维度建模优点
事实表
事实表存储了从业务活动或事件提炼出来的性能度量，它主要包含维度表的外键和连续变化的可加性数值或半可加事实。事实表产生于业务过程中而不是业务过程的描述性信息。它一般是行多列少，占了数据仓库的90%的空间。在维度模型中也有表示多对多关系的事实，其他都是维度表。
事实表粒度
事实表的粒度是产生事实行的度量事件的业务定义。粒度确定了事实表的业务主键， 事实表的所有度量值必须具有相同的粒度。
事实表类型
1.事务事实表
它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表。
2.周期快照事实表
它是按照良好的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充，而非替代品。
3.累积快照事实表
它用于描述业务过程中某个不确定时间跨度里的活动，它随着业务活动的发生会不断的更新。
事实表区别：
维度表
维度表是对业务过程的上下文描述，主要包含代理键、文本信息和离散的数字。它是进入事实表的入口，丰富的维度属性给出了对事实表的分析切割能力，它一般是行少列多。如果属性值是离散的，用于过滤和标记的，就放到维度表里，如果是属性值是连续取值，用于计算的，就放到事实表中。
维度表类型
缓慢变化维
1.类型1
字段值发生变化时覆盖原来的值。
2.类型2
字段值发生变化时会新增一行，重新分配代理键，每一行添加开始日期，结束日期，版本号，是否当前值。
3.类型3
每条记录会新增一列来标识变化前的值，发生变化时，把旧值放到新增的列中，把新值覆盖旧值。
4.混合类型
把上面的三种类型混合来使用。
日期维
它是数据仓库必须有的维度，包含日期，日期所属的周，月，季度，年等信息。
角色维
相同的维度表在维度模型中扮演不中的逻辑角色，一般通过创建视图来表示。
杂项维
如果每个属性值都很少，可以把这些维度的组合起来生成一个维度表。
支架维
如果维度之间是一对多的关系或区别于原维度的多个描述性维度属性，可以建雪花型支架维度。
多值维度桥接维
如果二个维度表是多对多的关系，可以使用多值维度设计。
微型维
一个大型维有些属性变化比较频繁，把这些属性单独生成一个微型维度表。
缩小维
它是维度表的一个子集或部分属性。
查找维
系统里代码表里维度信息。
层次维
有些维度表是有层次结构的，可以通过视图生成树形结构的维度表。
手工维护的维表
有些数据不在业务系统里，需要业务用户手工维护的维度表。
企业数据仓库总线架构
企业价值链
每家机构都有一个关键业务过程组成的潜在价值链，这个价值链确定机构主体活动的自然逻辑流程。数据仓库建设就是围绕着价值链建立一致化的维度和事实。
数据总线
这些业务过程都会共用一些维度，形成了企业数据仓库的总线，一致化维度和事实看作一组标准的应用程序连接口，可以看作一个数据仓库的总线架构。它可以将新的业务过程引入数据仓库中，该业务过程从总线获得动力，并且和其他已经存在的业务过程和谐共存。
数据总线矩阵
矩阵的每一行对应都对应机构中的一个业务过程，每一列都和一个业务维度相对应，用叉号填充显示的是和每一行相关的列。业务过程应该先从单个数据源系统开始，然后再进行多数据源的合并。
企业数据仓库总线矩阵是DW/BI系统的一个总体数据架构，提供了一种可用于分解企业数据仓库规划任务的合理方法，开发团队可以独立的，异步的完成矩阵的各个业务过程，迭代地去建立一个集成的企业数据仓库。
一致性维度和事实
企业数据仓库应该建立一个一致性维度和事实，而不是为每个部门建立维度和事实。
一致性维度
具有一致的维度关键字，一致的属性列名称，一致的属性定义和一致的属性值。一致性维度要么是统一的，要么是维度表的一个子集。
一致性事实
指每个度量在整个数据仓库中都是唯一的统计口径，为了避免歧义，一个度量只有唯一的业务术语。
维度模型设计方法
维度模型设计流程图
维度模型设计步骤
1.需求调研
2.数据探查
根据总线矩阵，确定业务过程的优先级，就要对候选数据源进行可行性评估，产出文档有源系统跟踪报告，数据评估报告。主要内容有：
3.高层模型设计
4.识别维度和度量
有了高层模型，就要设计维度和度量，维度和度量清单不仅仅是业务用户所关心，还要从业务过程出发，自上而下的设计所涉及的维度和度量。防止业务用户的需求变化带来的冲击。
5.确定命名规范
在详细设计之前，为DW/BI系统制定规范，主要包含源系统、主题、业务术语、报表，物理设计命名、调度任务、文档方面的规范。
6.编写详细设计映射文档
详细设计文档包括从源系统到维度模型的每个数据层的物理映射文档。
7.审查和验证模型
详细设计文档出来后，要和业务用户和团队成员进行评审，记录下来评审过程中的问题，形成问题清单。
8.完成设计文档
最后确定设计文档，进行下一步的ETL开发。
————————————————
标签：数仓,数据仓库,建模,业务,商品,维度,事实,属性 来源： https://blog.csdn.net/qq_22473611/article/details/118088324
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。