一. 将维度分组到表中
经验丰富的设计人员通常不难确定如何将维度属性分组到表中.多数对应分析类别的维度表具有深刻的业务特征,可以将此作为初步划分的基本依据某些不确定性产生的原因在于维度建模的特性.与实体—关系模型不同,维度模型不能揭示相互关联的属性之间存在的关系.认识到这种差异是处理混乱局面的第一步.上下文关系易于传递给事实表,而天然存在的相关性则由维度表中共存的属性表示
关联维度属性的两种方法
- 描述环境的明确的关系
- 描述亲和性的隐含关系
对维度分组时的考虑
那些对维度方法不熟悉的人可能面临这样的状况:很难确定两个维度是否属于同一维度表.(确实如此,工作中我一般的做法都是合并表…)
- 基于亲和性分组维度:在维度模型中,通常根据自然亲和性将维度分组为不同的表.例如,产品和品牌在订单产生之前彼此之间是存在关联的.事务不需要在这些元素之间建立关系.事实上,即使没有订单,产品也会具有品牌.更重要的是，这些属性只能以一种方法或在一种环境中关联.另一方面,一些属性只能基于事务或活动发生关联.例如,只有在产生订单时,销售人员和顾客才会建立关联.因此,这些属性应归入不同的表;它们的关系放置在事实表中.这种方式允许在顾客和售货员之间存在多种交互,甚至可能存在于不同的配搭方式中.它们之间的关系由事务来定义.当两个维度属性共享一个自然的亲和性关系,并且同时出现在一种环境中时,它们属于同一维度表.当它们的关系由事务或活动来决定,并且存在于不同的环境中时,应该将它们放置在不同的维度表中
- 可浏览性测试:例如时将产品和品牌分开破坏这些属性间的可浏览性.在这一配置中,只能研究订单环境中产品和品牌的交集.如果没有关于某个特定产品的订单,将不能确定产品的品牌,因此将这些属性放入同一表中会更有意义
Untitled.png (1330×1075) (amazonaws.com)
产品和品牌分开会破坏可浏览性
二. 分解大型维度表
维度表包含100个以上的属性是很常见的.有时,维度表包含如此多的属性以至于数据库管理员会担心并考虑它们对数据库的影响问题.这种担忧可能纯粹是技术性的,但的确是有根据的.例如,包含大量属性的行可能会对数据库管理员分配空间或指派区块大小产生影响.包含大量属性的维度也是ETL（抽取、转换、加载）开发人员所关心的.当某个表有大量类型2属性时,对维度的增量更新可能成为巨大的处理瓶颈.在此环境下,大型维度表包含如此多的缓慢变化维度,以至于开发人员开始质疑“缓慢”的真正含义
任意分隔维度表
虽然该方法解决了数据管理员提出的问题,但也带来了一系列的新问题.重要的是,可能无法解决ETL开发人员提出的所有问题:连接选择,事实表外键声明,ETL处理
分隔维度方法的替代方法
- 当存在某个维度具有海量的属性时,这一情况通常可以作为存在两个相异维度的标志
- 将自由形态的文本字段定位到支架表,当这些文本字段的数量和规模都很大时,它们可以被重新定位到不同的表中,并且用外键引用进行替换
- 寻找子类型(特殊类型的星型模式)
- 考虑微型维度
微型维度缓解ETL瓶颈和过度增长
当某个维度表包含大量的行,并且包含大量的类型2变化时,将会变得极其庞大.数据库管理系统技术的不断发展可能会减轻对表大小的担忧;10年前,一个包含100万行的表被认为时非常庞大的,但在今天几乎不会对这样的表存在任何的担忧,随着存储技术的改进,维度表也在迅速增长,但依然需要加载表
- 微型维度:当某个维度表快速增长或者相关的ETL过程耗费大量的时间,采用微型维度有助于减小由此带来的麻烦(什么是微型维度?如何使用?)
- 控制维度增长
- 微型维度和可浏览性
三. 角色维度和别名使用
业务过程的度量可以包含维度的多个实例.例如,当汽车经销商卖出一辆车时,两个雇员与此交易有关;卖车的销售人员和批准销售的管理员.这两种关系被称为角色.在事实表中,它们通过引用同一维度表的多个外键来表示.查询时,通过使用称为别名的技术区分不同的角色
四. 避免空值
尽管空值的概念不是关系模型的一部分,事实上每个关系数据库产品都支持空值的使用.空值是可以存储在数据库列中的特殊数据元素.空值是没有意义的,但它与空白、空串或零值存在明显的区别.SQL的扩展问题已经广受批评,最明显的是似乎混淆了数据和元数据,并包含了扭曲的逻辑系统
五. 行为维度
这是一种使用过去的行为模式来理解当前行为的强大分析技术.考虑这样一个问题;“产生超过100万美元的订单的客户与产生50万美元或更少订单的客户比较,有更多的折扣吗?”.这个问题使用了事实、订单总额作为维度,提供折扣额度的研究环境.回答这类问题需要高级的查询开发和详细的处理.行为问题是一种基于对过去维度成员的行为进行分组或过滤事实的方法.行为维度将事实转换为维度,以确保获得强大的分析能力,不需要使用复杂查询或详细处理的分析(可以理解维沉淀通用的需求)
网友评论