ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 逻辑模型建设-星型与雪花型的区别

逻辑模型建设-星型与雪花型的区别

原创 Linux操作系统 作者:ceo_lxy 时间:2011-03-21 15:32:44 0 删除 编辑
逻辑模型指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看,数据仓库的数据逻辑模型也许是整个项目最重要的方面,需要领域专家的参与。从内容上看,涉及的方面有确立主题域,粒度层次的划分,确定数据分割策略,关系模式的确定。
   
逻辑模型建设方法
    逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF,即 Third Normal Form)和星型模式 (Star-Schema)
    第三范式
    关系模式满足以下特征:
    1 每个属性的值唯一,不具有多义性;
    2. 每个非主属性必须完全依赖于整个主键,而非主键的一部分;
    3. 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去
    星型模型
    星型模式是一种多维的数据关系,它由一个事实表(Fact Table)和一组维表(Dimens ion Table)组成。每个维表都有一个维作为主键,所有这些维则组合成事实表的主键,换言之,事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实 (Fact),它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。
   
第三范式和星型模式在数据仓库中的应用
    大多数人在设计中央数据仓库的逻辑模型时,都按照第三范式来设计;而在进行物理实施时,则由于数据库引擎的限制,不得不对逻辑模型进行不规范处理 (De-Normalize), 以提高系统的响应速度,这当然是以增加系统的复杂度、维护工作量、磁盘使用比率 (指原始数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。
    那么,在中央数据仓库中是否可以采用星型模式来进行模型设计呢?我们知道,星型模式中有一个事实表和一组维表,我们可以把事实看成是各个维交叉点上的值。
    星型模式之所以速度快,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。因此,在星型模式设计的数据仓库中,作报表的速度虽然很快,但由于存在大量的预处理,其建模过程相对来说就比较慢。当业务问题发生变化,原来的维不能满足要求时,需要增加新的维。由于事实表的主键由所有维表的主键组成,这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。综合这些讨论,不难得出结论,星型模式比较适合于预先定义好的问题,如需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此,星型模式在一些要求大量报表的部门数据集市中有较多的应用。
    总之,上面讨论了数据仓库模型设计中常用的两种方法。对于部门数据集市,当数据量不大、报表较固定时可以采用星型模式;对于企业级数据仓库,考虑到系统的可扩展能力、投资成本和易于管理等多种因素,最好采用第三范式。
逻辑模型指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看,数据仓库的数据逻辑模型也许是整个项目最重要的方面,需要领域专家的参与。从内容上看,涉及的方面有确立主题域,粒度层次的划分,确定数据分割策略,关系模式的确定。

   
逻辑模型的质量标准
    对逻辑模型的评估,就是对逻辑模型质量的考察,什么是逻辑模型的质量呢?从狭义的概念说,逻辑模型是否正确表达了业务规则,也就是准确,但是随着人们对数据仓库认识的加深,质量的含义不断延伸,现在对模型质量要求不仅仅单纯指单纯的业务规则,还包括模型满足用户分析需求的程度,它是一个包含丰富内涵、具有多维因素的综合性概念。相应地逻辑模型质量概念的认识也从狭义向广义转变,准确性已不再是衡量唯一标准。评估逻辑模型一般包括如下方面的标准
    正确性
    逻辑模型的建设方法是正确的,遵循了从上到下和从下到上相结合的方法,选择了正确的模型表示方式,对实际业务采用正确的概化抽象。
    准确性(精度)
    指逻辑模型和实际业务即“真值”之间的差异程度。误差越小,准确性就越高。这里,所谓的“真值”是可知的,尽管逻辑模型经过了抽象,概化等方法总结共性,但是模型的具体化后,与“真值”是应当符合的。可以通过范围误差、计数误差、不回答率、加工整理差错、模型假设误差等影响准确性的各个因素,测算统计估算值的变动系数、标准差、均方差、曲线配合吻合度、假设检验、偏差等,修正逻辑模型将其的误差控制在一个可接受的置信区间内。
    适用性
    指收集的信息是否有用,是否符合用户的需求。它要求逻辑模型的粒度,分割方式符合用户的分析需求。
    可解释性
    是指在公布逻辑模型时,应同时公开逻辑模型的的补充解释信息或称为“元数据”,即关于模型数据的解释说明。内容包括所使用的建设方法,建设目标,以防止模型数据二义性导致错误解释和使用。
    完备性
    目前的业务需求和所用的业务规则完全包含在逻辑模型中。模型中不存在没有包含的需求业务对象(如实体,属性,以及之间的关系)
    一致性
    模型中的各个对象命名方式统一,有明确的命名规范。而且模型中各个相关对象的粒度一致,业务逻辑模型对象的划分标准应当统一。
    扩展性
    当新的业务产生时,仅仅是增加了相关逻辑模型对象的实例内容,不影响目前的逻辑模型,模型这些分类能够随统计分析需求的不同进行相应的调整,无需改变数据库结构,具有灵活的扩展性。仅在个别情况下,需要对逻辑模型的属性或者实体本身增加,支持分步骤的实施。
    可衔接性
    逻辑模型来自拥有行业经验的概念模型,里面凝聚了许多成功的经验,而且从规划上符合行业系统的长远发展,因此逻辑模型应当从概念模型上相对平滑的过度过来。此外,物理模型应当来自与逻辑模型,逻辑模型的建设应当具有一定的可操作性,便于向物理模型的转化。
   
逻辑模型中常犯的错误:
   
命名规范不统一
    对于汇总数据,低粒度数据或历史数据采用已定义的命名规范。
    粒度层次不统一
    有的具体,有的过于抽象
    不准确
    业务关系表示错
    不全面:
    一些属性外键标识没有主表
    无用关联关系多:
    模型中各种对象所表示的内容,应当与用户的业务分析需求密切相关。
    与行业通用模型移动的兼容性差:
    与行业通用模型存在较大的差异,不利于系统的将来发展符合信息发展的趋势。
    总结
    商业智能和数据仓库系统的建设作为一个渐进、迭代的过程,其发展趋势是从现有的初步应用如报表分析、数据集市,向深度和广度复杂分析和数据挖掘技术应用发展,其依赖的数据存储模型,包括逻辑模型和物理模型,也是一个不断发展,不断丰富完善的过程。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12122734/viewspace-690065/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-06-02

  • 博文量
    519
  • 访问量
    490244