51CTO旗下网站
认识每一个“你”：微博中的用户模型
微博经历了6年的发展，已经成为了国内社交媒体的中坚力量。本文从微博的角度出发，对微博中用户模型的目的、维度和建模任务进行描述，并作为后续微博用户模型相关文章的总述。
作者：新浪微博冯扬来源：51CTO| 17:11
社交媒体（Social Media）相对于传统互联网媒体的最大区别是通过建立人与人之间的联系，极大提升了信息生产量以及传播效率。身处社交媒体中的每个人或组织同时扮演着信息生产者、传播者与接受者的角色。
在社交媒体背景下，用户生产、传播和接收信息更加便捷，使得之前相对集中的用户兴趣和行为变得更加碎片化和离散，因此社交媒体中的用户模型的构建和应用也发生了巨大的变化。
微博经历了6年的发展，已经成为了国内社交媒体的中坚力量。本文从微博的角度出发，对微博中用户模型的目的、维度和建模任务进行描述，并作为后续微博用户模型相关文章的总述。
构建用户模型的目的
刻画每个用户，是任何一家社交类型的服务都需要面对的问题。不同的公司针对各自业务会有不同的需求，构建用户模型的动机和目标也会存在一定差异。从微博自身的角度来讲，构建用户模型的目的包括：
完善及扩充微博用户信息
用户模型的首要动机就是了解用户，这样才能够提供更优质的服务。但是在微博中用户的信息提供得不尽完整，有些是因为平台的引导机制造成的（例如填写公司学校信息的时候，相应的机构名或者学校名并不在列表内），有时候又是用户不愿意或懒得提供（例如针对一些非必选项），而且对于用户自行输入的内容又很难进行规范化&&此外，一些隐性或变化频繁的信息（例如用户的兴趣、商业偏好、地理位置的变化等等）也需要通过用户的行为挖掘出来。
分析微博生态
除了了解用户，还需要了解自己。在掌握用户信息的基础上，平台就可以对自身的状况进行分析，从相对宏观的基础上把握微博的生态环境，为后续的优化和发展提供方向性。例如通过对用户信息的聚类，能够对微博用户进行人群的划分，掌握不同人群的活跃程度，信息的传播和引爆方式，行为及兴趣偏好等等。
支撑微博业务
在微博中的各项业务都与用户模型有着直接与间接的关系，无论是基于兴趣的推荐提升用户价值，精准的广告投放提升商业价值，还是针对特定群体的内容运营，用户模型都是其必不可少的基础支撑。直接地，用户模型可以用于兴趣匹配、关系匹配的推荐和投放；间接地，可以基于用户模型中相似的兴趣、关系及行为模式去推动信息及账号的传播和成长。
微博用户模型的维度划分
一个用户可以从多个方面去刻画，也就是说用户模型可以从多个维度来考虑和构建。
作为社交媒体，微博用户在平台上通过某些行为（如发微博、点击图片、播放视频、浏览信息流&&）生产或获取信息，也通过其它一些行为（如转发、评论、赞&&）将信息传播出去，信息的传播是通过用户之间的社交关系所进行的，并且在生产、消费、传播信息的过程中对信息的选择和过滤体现了用户在兴趣方面的倾向性。由此，我们可以将微博用户模型按照图1所示的四个维度进行划分，即属性维度、兴趣维度、社交维度和行为维度。
图1 微博用户模型的维度划分
用户属性和用户兴趣是通常用户画像中包含的两个维度。前者刻画用户的静态属性特征，例如用户的身份信息（性别、年龄、受教育程度、学校、工作单位&&），后者则用于刻画用户在信息筛选方面的倾向（例如用户的兴趣标签、能力标签等）。
社交维度是从社交关系及信息传播的角度来刻画用户的。在社交媒体中，用户不在仅仅是一个个体，用户以及用户之间的社交关系构成了一张网络，信息在这张网络中高速流动，但是这种流动并不是无差别的，信息的起始点，所经历的关键节点以及这些节点构成的关系圈都是影响信息流动的重要因素。社交维度就是要量化这些因素以及其影响程度。
行为维度是一个比较新的研究方向，目的是发现影响用户属性、信息变化的行为因素，分析典型用户群体的行为模式。一方面可以通过行为模式的复用来促进用户在微博平台的成长；另一方面也有利于平台认识用户，和发现新的或异常的用户行为。
用户建模的任务
属性和兴趣维度（用户画像）
属性和兴趣维度的用户模型都可以归入用户画像(User Profile)的范畴，即对用户的信息进行标签化。一方面，标签化是对用户信息进行结构化，方便计算机的识别和处理；另一方面，标签本身也具有准确性和非二义性，也有利于人工的整理、分析和统计。
用户属性指相对静态和稳定的人口属性，例如：性别、年龄区间、地域、受教育程度、学校、公司&&这些信息的收集和建立主要依靠产品本身的引导、调查、第三方提供等，在此基础上需要进行补充和交叉验证。
用户兴趣则是更加动态和易变化的特征，首先兴趣受到人群、环境、热点事件、行业&&等方面的影响，一旦这些因素发生变化，用户的兴趣容易产生迁移；其次，用户的行为（特指在互联网上的行为）多样且碎片化，不同行为反映出来的兴趣差异较大，在用户兴趣分析的过程中，主要考虑如下几个方面：
标签来源：不是所有的词都适合充当用户标签，这些词本身应该具有区分性和非二义性；此外，还需要考虑来源的全面性，除了用户主动提供的兴趣标签外，用户在使用微博的过程中的行为，构建的用户关系等也能够反应用户的兴趣，因此也要将其考虑在内。
权重计算：得到了用户的兴趣标签，还需要针对用户给这些标签进行权重赋值，用来区分不同标签对于该用户的重要程度。
时效性：随着时间的变化，用户的兴趣会发生转移，有些兴趣会贯穿用户使用社交媒体的全过程，而有些兴趣则是受热点时间、环境因素等的影响。
兴趣和能力的区分：用户具有某方面的兴趣，只代表了他愿意接受这方面的信息，并不能代表他具有产生相关内容的能力。区分兴趣和能力，能有助于预测兴趣相关内容潜在的生产者和传播者。
如果将微博中的用户视作节点，用户之间的关系视作节点之间的边，那么这些节点和边将构成一个社交的网络拓扑结构，或称作社交图谱。微博中的信息就是在这个图谱上进行传播。
从社交的维度建立用户模型，需要从不同的角度细致和全面地描述这个社交图谱的特征，反应影响信息传播的各层面上的因素，寻找节点之间的关联想，以及刻画图谱本身的结构特征。其中包括：
用户个体对信息传播的影响：不同用户在信息传播过程中的重要性不一样，影响大的用户对于信息的传播较影响小的用户更具有促进作用。
量化用户关系的远近：衡量存在直接关联（关注、被关注、互粉&&）用户之间的关系远近，关系越近的用户之间越容易产生信息传播行为。
延伸用户之间的关系：通过用户之间的直接关系（关注、被关注、互粉&&），让本身并不存在直接关系的用户产生关联。
寻找相似的用户：微博中非对等的关系本身可以认为是一种认证，用户基于兴趣、线下关系、或某种其它原因反应到线上的一种关联。那么在关系维度上的相似用户至少能反应他们在某种因素上的一致性。
识别关系圈：从关系图谱的本身的结构出发，从中发掘关联紧密的群体，有助于信息的精准投放和推广。
以上关于关系建模的任务可以看作是逐步深入的，从&个体&--&&关联&--&&相似&--&&群体&的逐渐深入。
分析用户的行为，建立行为模式有两个任务：针对典型个体行为进行时序分片，分析用户成长的相关因素；针对典型群体的行为进行统计，构建其行为模型。
典型个体的行为时序分析
所谓典型个体是指某段时间内，成长比较突出的微博用户。例如从一个新用户从新注册到粉丝过百、过千需要有一个积累过程，有些用户积累较快，有些较慢，而这些积累较快的用户可以作为典型个体；或者某些用户在某一阶段传播力有限，但在某时刻传播力激增，无论是互动还是内容传播覆盖面都变化很大，这种也可以作为典型个体。
针对典型个体，需要挖掘与其用户成长相关的行为因素。基本方法是对时间进行分片，获取用户在不同时间片上的行为统计，以及在各个时间分片上的用户成长指标（粉丝数、互动率、传播力等），如图2所示。在此基础上针对用户行为的统计量的变化，利用关联性分析或回归来分析用户成长与哪些因素有关。
图2 时间分片上的用户行为统计
典型群体行为模式分析
针对典型个体，从用户的基本信息、人口信息、兴趣维度，可以将相似的典型用户划分为同一的群体，称作典型群体，针对典型群体中的用户按照成长程度进行划分，按不同的成长阶段统计用户行为，即建立了该典型群体的行为模型。
例如，对于&北京，年龄在20~30岁，女性，电商领域，普通账号&这样的典型群体，从粉丝数、传播力、互动率等维度将其划分到初创、成长、快速提升、成熟&&等阶段，针对不同成长阶段内的行为组合进行统计，结果构成该群体的行为模式。
构建用户模型是社交媒体中的基础工作，涉及到数据、统计、挖掘等各方面的技术和手段。本文针对微博的特点和业务需要，针对其中的用户模型构建的目标和任务进行了简述。全文并没有涉及具体的方法和原理，后续会有相应的技术文章进行介绍。
需要指出的是，不同于传统互联网媒体，微博作为社交媒体最大的优势在于引入了非对等的用户关系，这种关系不仅令传播更加高效，也令考虑关系因素成为了用户建模中（无论是在属性、兴趣、社交还是行为维度上）非常重要手段。
想要进一步了解相关内容可关注&&微博：wbrecom&&& 公众号：微博推荐平台
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条头条头条头条头条
24H热文一周话题本月最赞
讲师：41371人学习过
讲师：206658人学习过
讲师：780955人学习过
精选博文论坛热帖下载排行
本书是全国计算机技术与软件专业技术资格（水平）考试的指定用书。按照新的网络工程师考试大纲的规定，本书包含了数据通信基础知识、网络体...
订阅51CTO邮刊博客访问： 20722
博文数量： 2
注册时间：
ITPUB论坛APP
ITPUB论坛APP
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： 数据仓库与数据挖掘 16:04:43
维度建模的基本概念及过程
摘要：本文首先介绍维度模型中的维度表和事实表这2个基本构成要素的基础知识；其次，介绍设计维度模型的4个基本步骤；再次，围绕某银行为实现业务价值链数据集成的需要，介绍多维体系结构中的3个关键性概念：数据仓库总线结构、一致性维度、一致性事实。
关键词：维度表;事实表;维度模型设计过程;数据仓库总线结构;一致性维度;一致性事实。
与流行的说法不同，Ralph
Kimball本人并没有定义“维度”和“事实”这样的术语。术语“维度”与“事实”，最初是20世纪60年代在一个由General
Mills与Dartmouth大学主持的联合研究计划中提出的。70年代，AC
Nielsen和IRI都一致地使用这些术语描述他们的数据发布应用，用现在更为准确的话来说，就是关于零售数据的维度数据集市（Data
Mart）。在简明性成为生活方式的潮流之前的长时期内，早期的数据库垄断组织们致力于将这些概念用来简化用做分析的信息。他们意识到，除非数据库做得简单易用，否则没有人会用它。因此，在将可理解性和性能作为最高目标的驱动下，产生了维度模型的构造思想。
事实表是维度模型的基本表，其中如图1.1所示存放有大量的业务性能度量值。力图将从一个业务处理过程得到的度量值数据存放在单个数据集市。由于度量值数据压倒性地成为任何数据集市的最大部分，因此应该避免在企业范围内的不同地方存储其拷贝。用术语“事实”代表一个业务度量值。可以设想一个作为例子的情形：查询某个客户在某个机构下某个产品合约账户的某个币种的某个时点余额，在各维度值(客户、产品合约、账户、机构、币种、日期)的交点处就可以得到一个度量值。维度值的列表给出了事实表的粒度定义，并确定出度量值的取值范围是什么。
图 1.1 示例事实表
事实表的一行对应一个度量值，一个度量值就是事实表的一行；事实表的所有度量值必须具有相同的粒度。最有用的事实是诸如账户余额这样的数字类型为可做加法的事实。可加性是至关重要的，因为数据仓库应用不仅仅只检索事实表的单行数据。相反，往往一次性带回数百、数千乃至数百万行的事实，并且处理这么多行的最有用的事就是将它们加起来。
当然，有些事实是半加性质的，而另外一些是非加性质的。半加性事实仅仅沿某些维度相加，例如销售占比，周期余额；而非加性事实根本就不能相加，例如状态。对于非加性事实，如果希望对行进行总结就不得不使用计数或平均数，或者降为一次一行地打印出全部事实行。
度量事实在理论上讲可以是文本形式的，不过这种情况很少出现。在大多数情况下，文本度量值可以是某种事物的描述并取自某个离散列表的值。设计者应该尽各种努力将文本度量值转换成维度，原因在于维度能够与其他文本维度属性更有效地关联起来，并且消耗少得多的空间。不能将冗余的文本信息存放在事实表内。除非文本对于事实表的每行来说都是唯一的，否则它应该归属到维度表中。真正的文本事实在数据仓库中是很少出现的，文本事实具有像自由文本内容那样的不可预见性内容，这几乎是不可能进行分析的。
所有事实表有两个或者两个以上的外关键字(如图1.1中FK符号标记的部分)，外关键字用于连接到维度表的主关键字。例如，事实表中的“产品合约关键字”总是匹配产品合约维度表的一个特定“产品合约关键字”。如果事实表中的所有关键字都能分别与对应维度表中的主关键字正确匹配，就可以说这些表满足引用完整性的要求。事实表要通过与之相连的维度表进行存取。
事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表。事务事实表用于承载事务数据，通常粒度比较低，例如产品交易事务事实、ATM交易事务事实；周期快照事实表用来记录有规律的、固定时间间隔的业务累计数据，通常粒度比较高，例如账户月平均余额事实表；累积快照事实表用来记录具有时间跨度的业务处理过程的整个过程的信息，通常这类事实表比较少见。这里需要值得注意的是，在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。
维度表是事实表不可分割的部分。如图1.2所示，维度表包含有业务的文字描述。在一个设计合理的维度模型中，维度表有许多列或者属性，这些属性给出对维度表的行所进行的描述。应该尽可能多地包括一些富有意义的文字性描述。对于维度表来说，包含50到100个属性的情形并不少见。维度表倾向于将行数做得相当少(通常少于100万行)，而将列数做得特别大。每个维度用单一的主关键字(如图1.2中PK符号标记的部分)进行定义，主关键字是确保同一与之相连的任何事实表之间存在引用完整性的基础。
图1.2 示例维度表
维度属性是查询约束条件、成组与报表标签生成的基本来源。在查询与报表请求中，属性用by这个单词进行标识。例如，一个用户表示要按“产品合约编号”与“机构编号”来查看账户余额，那么“产品合约编号”与“机构编号”就必须是可用的维度属性。
维度表属性在数据仓库中承担着一个重大的角色。由于它们实际上是所有令人感兴趣的约束条件与报表标签的来源，因此成为使数据仓库变得易学易用的关键。在许多方面，数据仓库不过是维度属性的体现而已。数据仓库的能力直接与维度属性的质量和深度成正比。在提供详细的业务用语属性方面所花的时间越多，数据仓库就越好。在属性列值的给定方面所花的时间越多，数据仓库就越好。在保证属性列值的质量方面所花的时间越多，数据仓库就越好。
维度表是进入事实表的入口。丰富的维度属性给出了丰富的分析切割能力。维度给用户提供了使用数据仓库的接口。最好的属性是文本的和离散的。属性应该是真正的文字而不应是一些编码简写符号。应该通过用更为详细的文本属性取代编码，力求最大限度地减少编码在维度表中的使用。有时候在设计数据库时并不能很确定，从数据源析取出的一个数字型数据字段到底应该作为事实还是维度属性看待。通常可以这样来做出决定，即看字段是一个含有许多的取值并参与运算的度量值(当事实看待)，还是一个多少变化不多并参与作为约束条件的离散取值的描述(当维属性看待)。
在维度类型中，有一种重要的维度称作为退化维度(Degenerate
Dimension)，这种维度指的是直接把一些简单的维度放在事实表中而不专门去做一个维度表。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度经常会和其他一些维度一起组合成事实表的主键。退化维度在分析中可以用来做分组使用。
维度表和事实表的融合
在理解了事实和维度表之后，现在就考虑将两个组块一起融合到维度模型中去的问题。如图1.3所示，由数字型度量值组成的事实表连接到一组填满描述属性的维度表——这个星型特征结构通常被叫做星型连接方案。该术语可以追溯到最早的关系数据库时期。
维度模型中的事实与维度表
关于其中用到的维度方案，应该注意的第一件事就是其简明性与对称性。很显然，业务用户会因为数据容易理解和浏览而从简明性方面受益。
维度模型的简明性也带来了性能上的好处。数据库优化器可以更高效率地处理这些连接关系较少的简单方案。数据库引擎可以采取的非常强劲的做法是，首先集中对建立了充足的索引的维度表进行约束(过滤)处理，然后用满足用户约束条件的维度表关键字的笛卡尔乘积一次性处理全部的事实表。令人惊奇的是，利用这种方法只需使用一次事实表的索引，就可以算出与事实表之间的任意n种连接结果。
最后，维度模型能够很自然地进行扩展以适应变化的需要。维度模型的可预定框架能够经受住无法预见的用户行为变化所带来的考验。每个维度都是平等的，所有维度都是进入事实表的对等入口。这个逻辑模型不存在内置的关于某种期望的查询形式方面的偏向，不存在这个月要问的业务问题相对于下个月来说具有优先方面的考虑。没有谁会希望，如果业务用户采用新的方式进行业务分析，就要调整设计方案这样的事情发生。
最佳粒度或者原子数据具有最佳的维度。被聚合起来的原子数据是最有表现力的数据。原子数据应该成为每个事实表设计的基础，从而经受住业务用户无法预见的查询所引起的特别攻击。对于维度模型来说，完全可以向方案中加入新的维度，只要其值对于每个现有的事实行存在唯一性定义就行。同样，可以向事实表加入新的不曾预料到的事实，只要其详细程度与现有事实表处在一致的水平面上就可以了。可以用新的不曾预料到的属性补充先前存在的维度表，也可以从某个前向时间点的角度在一个更低的粒度层面上对现存维度行进行分解。在每种情况下，可以简单地在表中加入新的数据行或者执行一条SQL ALTER
TABLE命令来对现存表格进行适当的修改。数据用不着重新加载，所有现存的数据存取应用可以继续运行而不会产生不同的结果。
具有一定顺序的四个步骤的方式进行维度数据库的设计。
四步骤维度设计过程
第一步 选取业务处理
业务处理过程是机构中进行的一般都由源系统提供支持的自然业务活动。听取用户的意见是选取业务处理过程的效率最高的方式。在选取业务阶段，数据模型设计者需要具有全局和发展的视角，应该理解整体业务流程的基础上，从全局角度选取业务处理。
要记住的重要一点是，这里谈到的业务处理过程并不是指业务部门或者职能。通过将注意力集中放在业务处理过程方面，而不是业务部门方面，就能在机构范围内更加经济地提交一致的数据。如果建立的维度模型是同部门捆绑在一起的，就无法避免出现具有不同标记与术语的数据拷贝的可能性。多重数据流向单独的维度模型，会使用户在应付不一致性的问题方面显得很脆弱。确保一致性的最佳办法是对数据进行一次性地发布。单一的发布过程还能减少ETL的开发量，以及后续数据管理与磁盘存储方面的负担。
第二步 定义粒度
粒度定义意味着对各事实表行实际代表的内容给出明确的说明。粒度传递了同事实表度量值相联系的细节所达到的程度方面的信息。它给出了后面这个问题的答案:“如何描述事实表的单个行?”。
粒度定义是不容轻视的至关重要的步骤。在定义粒度时应优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子型数据是所收集的最详细的信息，这样的数据不能再做更进一步的细分。通过在最低层面上装配数据，大多原子粒度在具有多个前端的应用场合显示出其价值所在。原子型数据是高度维结构化的。事实度量值越细微并具有原子性，就越能够确切地知道更多的事情，所有那些确切知道的事情都转换为维度。在这点上，原子型数据可以说是维度方法的一个极佳匹配。
原子型数据可为分析方面提供最大限度的灵活性，因为它可以接受任何可能形式的约束，并可以以任何可能的形式出现。维度模型的细节性数据是稳如泰山的，并随时准备接受业务用户的特殊攻击。
当然，可以总是给业务处理定义较高层面的粒度，这种粒度表示最具有原子性的数据的聚集。不过，只要选取较高层面的粒度，就意味着将自己限制到更少或者细节性可能更小的维度上了。具有较少粒度性的模型容易直接遭到深入到细节内容的不可预见的用户请求的攻击。聚集概要性数据作为调整性能的一种手段起着非常重要的作用，但它绝对不能作为用户存取最低层面的细节内容的替代品。遗憾的是，有些权威人士在这方面一直显得含糊不清。他们宣称维度模型只适合于总结性数据，并批评那些认为维度建模方法可以满足预测业务需求的看法。这样的误解会随着细节性的原子型数据在维度模型中的出现而慢慢地消逝。
第三步 选定维度
维度所引出的问题是，“业务人员将如何描述从业务处理过程得到的数据?”应该用一组在每个度量上下文中取单一值而代表了所有可能情况的丰富描述，将事实表装扮起来。如果对粒度方面的内容很清楚，那么维度的确定一般是非常容易的。通过维度的选定，可以列出那些使每个维度表丰满起来的离散的文本属性。常见维度的例子包括日期、产品、客户、账户和机构等。
第四步 确定事实
设计过程的第四步同时也是最后一步，在于仔细确定哪些事实要在事实表中出现。事实的确定可以通过回答“要对什么内容进行评测”这个问题来进行。业务用户在这些业务处理性能度量值的分析方面具有浓厚的兴趣。设计中所有供选取的信息必须满足在第2步中定义的粒度要求。明显属于不同粒度的事实必须放在单独的事实表中。通常可以从以下三个角度来建立事实表：
1、针对某个特定的行为动作，建立一个以行为活动最小单元为粒度的事实表。最小活动单元的定义，依赖于分析业务需求。比如用户的一次网页点击行为、一次网站登录行为，一次电话通话记录。这种事实表，主要用于从多个维度统计，行为的发生情况，主要用于业务分布情况，绩效考核比较等方面的数据分析。
2、针对某个实体对象在当前时间上的状况。我们通过对这个实体对象在不同阶段存储它的快照，比如账户的余额、用户拥有的产品数等，通过这种可以统计实体对象在不同的生命周期中的关键数量指标。
3、针对业务活动中的重要分析和跟踪对象，统计在整个企业不同业务活动中的发生情况。比如会员，可以执行或参与多个特定的行为活动。这种事实表是以上两种事实表的一个总结和归纳。它主要用于针对我们业务中的活动对象进行跟踪和考察。
机构一般都对不同业务处理过程的集成很感兴趣。低级别业务分析师在这方面的愿望可能并不是很急迫，但那些处于较高管理阶层的人员非常清楚，在跨业务的范围内进行数据的查看对于提高评估性能是很必要的。众多的数据仓库项目将注意力放在从终端到终端的视角，更好地理解顾客关系的管理需求方面了。如图3.1所示，在某大型国有银行中，在业务价值链的产品运营中，包含许多相关的业务处理，如营销支持、产品运营、风险管控、财务绩效等诸多业务处理。
业务价值链
给出了这种维度共享情形的逻辑表示形式.
业务处理之间的维度共享
单独查询各个集市，然后基于共同的维度属性对查询结果施加外连接。这个通常称作交叉探查(Drill
Across)的连接，在维度表属性具有同一性的情况下是很直接的。
数据仓库总线结构
很显然，想一个步骤就建成企业数据仓库太令人望而生畏了，然而，将它分成孤立的片段进行建造又会挫败一致性这个压倒一切的目标。要使数据仓库能够长期地成功运转，很需要有一种在体系结构上可以按增量方式建造企业数据仓库的方法。这里提倡使用的一种方法就是数据仓库总线结构。
通过为数据仓库环境定义标准的总线接口，独立的数据集市就可以由不同的小组在不同的时间进行实现。只要遵循这个标准，独立的数据集市就可以插入到一起并有效地共存。所有业务处理将创建一个维度模型系列，这些模型共享一组综合的具有一致性的共用维度，如图3.3。
图3.3 数据仓库总线结构
数据仓库总线结构提供了一种可用于分解企业数据仓库规划任务的合理方法。在体系结构确立阶段的较短时间内，开发团队设计出一整套在企业范围内具有统一解释的标准化维度与事实。这样，数据体系结构的框架就建立起来了。然后，开发团队可以全力以赴去实现严格依照体系结构进行迭代开发的独立数据集市。随着独立数据集市的投入使用，它们像积木块一样搭在了一起。在某种意义上讲，需要存在足够的数据集市才可能为集成的企业数据仓库带来美好的前景。
总线结构使数据仓库管理人员获取两个方面的优势。一方面，他们有了指导总体设计的体系框架，并且将问题分成了可以根据具体时限加以实施的以字节计量的数据集市块。另一方面，各数据集市开发团队遵照体系指南，可以相对独立地异步地开展工作。
一致性维度
在理解了总线结构的重要性以后，现在可以进一步开发发挥数据仓库总线奠基石作用的一致性标准维度了。一致性维度要么是同一的，要么是具有最佳粒度性与细节性的维度在严格数学意义上的子集。例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。
一致的维度具有一致的维度关键字、一致的属性列名字、一致的属性定义以及一致的属性值(将转化成一致的报表标签与分组标识)。如果属性标签的标记不同或者包含不同的值，维度表就不是一致的(不被处理成一致的)。如果客户或者产品维度是按非一致的方式进行配置的，那么，要么分散的数据集市不能在一起使用，要么更为严重的是，试图将它们用在一起将产生无效的结果。
一致的维度以几种不同的样式出现。在最基本的层次上，一致的维度意味着与同它们相连接的每种可能的事实表具有完全相同的内容。连接到产品服务签约事实上的日期维度表与连接到产品服务账户余额事实上的日期维度表是同一的。实际上，一致的维度在数据库范围内可能就是相同的物理表。不过，基于对配有多种数据库平台的数据仓库技术环境的典型复杂性的考虑，维度更有可能同时在每个数据集市都存在拷贝。在其中任何一种情况下，两个数据集市的日期维度都将具有相同数目的行、相同的关键字值、相同的属性标签、相同的属性定义与相同的属性值等。同样，也存在一致的数据内容、数据解释与用户展示。
一致性事实
到现在为止，我们已经讨论了建立一致性维度以将数据集市维系在一起的中心任务。这涵盖了数据仓库迁移开发所要付出的大量工作努力，余下的努力要投入到建立一致性事实定义上。
通常，像利润、经济资本、产品覆盖度、客户满意度以及其他关键性指标（KPI）需要在企业级共享的度量指标，都是必须保持一致性的事实。一般地说，事实表数据并不在各个数据集市之间明确地进行拷贝。不过，如果事实确实存在于多个位置，那么支撑这些事实的定义与方程(公式)都必须是相同的，假如将它们当作同种事物看待的话，如果这些事实具有相同的标记，那么需要在相同维度环境下对它们进行定义，同时使其在各个数据集市之间具有相同的度量单位。必须在数据命名实践中接受规范的约束，如果不可能做到使事实完全一致，那么应该对不同的解释给出不同的名称。这样可以减少计算中使用不兼容的事实的可能性。
本文作为维度建模综述性文章，基于维度建模理论知识并结合某企业的维度建模实践介绍了事实表、维度表、数据仓库总线结构、一致性维度、一致性事实等维度模型中的基本概念以及维度建模的设计过程。
[1].Ralph Kimball著，谭明金译.
《数据仓库工具箱：维度建模的完全指南（第二版）》，电子工业出版社，2003.
参照3种不同类型的事实表
阅读(18539) | 评论(0) | 转发(1) |
下一篇：没有了
相关热门文章
给主人留下些什么吧！~~
请登录后评论。