如何建立和评估数据仓库逻辑模型

逻辑模型指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看，数据仓库的数据逻辑模型也许是整个项目最重要的方面，需要领域专家的参与。从内容上看，涉及的方面有确立主题域，粒度层次的划分，确定数据分割策略，关系模式的确定。

逻辑模型建设方法

逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF,即 Third Normal Form)和星型模式 (Star-Schema)

第三范式

关系模式满足以下特征：

1 每个属性的值唯一,不具有多义性;

2 每个非主属性必须完全依赖于整个主键,而非主键的一部分;

3 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去

星型模型

星型模式是一种多维的数据关系，它由一个事实表(Fact Table)和一组维表(Dimens ion Table)组成。每个维表都有一个维作为主键，所有这些维则组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实 (Fact)，它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。

第三范式和星型模式在数据仓库中的应用

大多数人在设计中央数据仓库的逻辑模型时，都按照第三范式来设计;而在进行物理实施时，则由于数据库引擎的限制，不得不对逻辑模型进行不规范处理 (De-Normalize)， 以提高系统的响应速度，这当然是以增加系统的复杂度、维护工作量、磁盘使用比率 (指原始数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。

那么，在中央数据仓库中是否可以采用星型模式来进行模型设计呢我们知道，星型模式中有一个事实表和一组维表，我们可以把事实看成是各个维交叉点上的值。

星型模式之所以速度快，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。因此，在星型模式设计的数据仓库中，作报表的速度虽然很快，但由于存在大量的预处理，其建模过程相对来说就比较慢。当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。由于事实表的主键由所有维表的主键组成，这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。综合这些讨论，不难得出结论，星型模式比较适合于预先定义好的问题，如需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此，星型模式在一些要求大量报表的部门数据集市中有较多的应用。

总之，上面讨论了数据仓库模型设计中常用的两种方法。对于部门数据集市，当数据量不大、报表较固定时可以采用星型模式;对于企业级数据仓库，考虑到系统的可扩展能力、投资成本和易于管理等多种因素，最好采用第三范式。

逻辑模型指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看，数据仓库的数据逻辑模型也许是整个项目最重要的方面，需要领域专家的参与。从内容上看，涉及的方面有确立主题域，粒度层次的划分，确定数据分割策略，关系模式的确定。

逻辑模型的质量标准

对逻辑模型的评估，就是对逻辑模型质量的考察，什么是逻辑模型的质量呢？从狭义的概念说，逻辑模型是否正确表达了业务规则，也就是准确，但是随着人们对数据仓库认识的加深，质量的含义不断延伸,现在对模型质量要求不仅仅单纯指单纯的业务规则，还包括模型满足用户分析需求的程度，它是一个包含丰富内涵、具有多维因素的综合性概念。相应地逻辑模型质量概念的认识也从狭义向广义转变，准确性已不再是衡量唯一标准。评估逻辑模型一般包括如下方面的标准

正确性

逻辑模型的建设方法是正确的，遵循了从上到下和从下到上相结合的方法，选择了正确的模型表示方式，对实际业务采用正确的概化抽象。

准确性（精度）

指逻辑模型和实际业务即“真值”之间的差异程度。误差越小，准确性就越高。这里，所谓的“真值”是可知的，尽管逻辑模型经过了抽象，概化等方法总结共性，但是模型的具体化后，与“真值”是应当符合的。可以通过范围误差、计数误差、不回答率、加工整理差错、模型假设误差等影响准确性的各个因素，测算统计估算值的变动系数、标准差、均方差、曲线配合吻合度、假设检验、偏差等，修正逻辑模型将其的误差控制在一个可接受的置信区间内。

适用性

指收集的信息是否有用，是否符合用户的需求。它要求逻辑模型的粒度，分割方式符合用户的分析需求。

可解释性

是指在公布逻辑模型时，应同时公开逻辑模型的的补充解释信息或称为“元数据”，即关于模型数据的解释说明。内容包括所使用的建设方法，建设目标，以防止模型数据二义性导致错误解释和使用。

完备性

目前的业务需求和所用的业务规则完全包含在逻辑模型中。模型中不存在没有包含的需求业务对象（如实体，属性，以及之间的关系）

一致性

模型中的各个对象命名方式统一，有明确的命名规范。而且模型中各个相关对象的粒度一致，业务逻辑模型对象的划分标准应当统一。

扩展性

当新的业务产生时，仅仅是增加了相关逻辑模型对象的实例内容，不影响目前的逻辑模型，模型这些分类能够随统计分析需求的不同进行相应的调整，无需改变数据库结构，具有灵活的扩展性。仅在个别情况下，需要对逻辑模型的属性或者实体本身增加，支持分步骤的实施。

可衔接性

逻辑模型来自拥有行业经验的概念模型，里面凝聚了许多成功的经验，而且从规划上符合行业系统的长远发展，因此逻辑模型应当从概念模型上相对平滑的过度过来。此外，物理模型应当来自与逻辑模型，逻辑模型的建设应当具有一定的可 *** 作性，便于向物理模型的转化。

逻辑模型中常犯的错误：

命名规范不统一

对于汇总数据，低粒度数据或历史数据采用已定义的命名规范。

粒度层次不统一

有的具体，有的过于抽象

不准确

业务关系表示错

不全面：

一些属性外键标识没有主表

无用关联关系多：

模型中各种对象所表示的内容，应当与用户的业务分析需求密切相关。

与行业通用模型移动的兼容性差：

与行业通用模型存在较大的差异，不利于系统的将来发展符合信息发展的趋势。

总结

商业智能和数据仓库系统的建设作为一个渐进、迭代的过程，其发展趋势是从现有的初步应用如报表分析、数据集市，向深度和广度复杂分析和数据挖掘技术应用发展，其依赖的数据存储模型，包括逻辑模型和物理模型，也是一个不断发展，不断丰富完善的过程。

1、首先你得搞清楚建设数仓的目的是什么

是偏向于整合各系统数据，为数据分析决策服务，还是偏向于快速的完成分析决策需求？

如果是前者，那么在数据仓库建模的时候一般会选择ER建模方法；

如果是后者，一般会选择维度建模方法。

ER建模：即实体关系建模，由数据仓库之父BIll Inmon提出，核心思想是从全企业的高度去设计三范式模型，用实体关系描述企业服务。主张的是自上而下的架构，将不同的OLTP数据集中到面向主题的数据仓库中。

维度建模：由Kimball提出，核心思想是从分析决策的需求出发构建模型。这种模型由事实表和维表组成，即星型模型和雪花模型。Kimball倡导自下而上的架构，可以针对独立部门建立数据集市，再递增的构建，汇总成数据仓库。

2、其次你得进行深入的业务调研和数据调研

业务调研：深入的业务调研能使你更加明确数仓建设的目的；同时也利于后续的建模设计，随着调研的开展，如何将实体业务抽象为数仓模型会更加明朗。

数据调研：各部门或各科室的数据现状了解，包括数据分类、数据存储方式、数据量、具体的数据内容等等。这对后续的主数据串联或者维度一致性处理等等都是必须的基础。

3、然后是数据仓库工具选型

传统型数据仓库：一般会选择第三方厂家的数据库和配套ETL工具。因为有第三方支持，相对有保障；但缺点也很明显，受约束以及成本较高。

NoSQL型数据仓库：一般是基于hadoop生态的数据仓库。hadoop生态已经非常强大，可以找到各种开源组件去支持数据仓库。缺点是需要招聘专门人士去摸索，并且相对会存在一些未知隐患。

4、最后是设计与实施

设计：包括数据架构中的数据层次划分以及具体的模型设计；也包括程序架构中的数据质量管理、元数据管理、调度管理等；

实施：规范化的项目管理实施，但同时也需记住一点，数据仓库不是一个项目，它是一个过程。

oracle数据仓库本质上是依赖于关系型数据库来实现了OLAP的，所以ORACLE数据仓库中在建模中会使用星型模型来实现

teradata的话，其实是依赖于teradata的硬件设备来实现，所以它的数据仓库在设计上就不需要设计成星型模型的

设计成星型模型的话，会有数据冗余，但是查询快，而teradata直接有穿透功能，所以就没有必要设计成星型模型了

目前，大家公认的数据仓库创始人W HInmon在他所著的《建立数据仓库》一书中对数据仓库所下的定义;数据仓库就是面向主题的、集成的、稳定的、不同时间的数据集合，用以支持经营管理中的决策制定过程。数据仓库中的数据面向主题与传统的数据库面向应用相对应。主题是一个在较高层次将数据归类的标准，每一个主题对应一个宏观的分析领域。数据仓库的集成特性是指在数据进入数据仓库之前，必须进行数据加丁一和集成，这是建立数据仓库的关键步骤，首先要统一原始数据中的矛盾之处，还要将原始数据结构做一个从面向应用向面向主题的转变，数据仓库的稳定性是指数据仓库反映的是历史数据的内容，而不是日常事务处理产生的数据，数据经加工和集成进入数据仓库后是很少修改或根本不修改的;数据仓库是不同时间的数据集合，它要求数据仓库中的数据保存时限能满足进行决策分析的需要，而且数据仓库中的数据都要标明该数据的历史时期。

数据仓库最根本的特点是物理地存放数据，而且这些数据并不是最新的、专有的，而是来源于其他数据库，它要建立在一个较全面和完善的信息应用的基础上，用于支持高层决策分析，而事务处理数据库在企业的信息环境!!，承担的是日常 *** 作性的任务，数据仓库是数据库技术的一种新的应用，到目前为止，数据仓库还是用数据库管理系统来管理其中的数据。

A关系。

参考数据库access2003应用教程人民邮电出版社第6页“每一个关系都是一个二维表”。

表由字段组成。就像一张纸质表一样，假如你有一张人员基本信息表，姓名、性别、年龄、出生年月日、家庭住址、职务、职称，等等这些在数据库表设计中就称为字段，字段；

有一些属性，最重要属性是它数据类型，比如姓名、性别、家庭住址、职务、职称在ACCESS中一般设置成文本类型，出生年月日则是日期类型，年龄可以整数型或者小数类型。

Access拥有的报表

创建功能能够处理任何它能够访问的数据源。Access提供功能参数化的查询，这些查询和Access表格可以被诸如VB6和NET的其它程序通过DAO或ADO访问。在Access中，VBA能够通过ADO访问参数化的存储过程。

与一般的CS关系型数据库管理不同，Access不执行数据库触发，预存程序或交互式登录 *** 作。Access 2010包括了嵌入ACE数据引擎的表级触发和预存程序，在Access 2010中，表格，查询，图表，报表和宏在基于网络的应用上能够进行分别开发。

百度百科-ACCESS数据库

　多维数据库（Multi Dimensional Database,MDD）可以简单地理解为：将数据存放在一个n维数组中，而不是像关系数据库那样以记录的形式存放。因此它存在大量稀疏矩阵，人们可以通过多维视图来观察数据。多维数据库增加了一个时间维，与关系数据库相比，它的优势在于可以提高数据处理速度，加快反应时间，提高查询效率。

目前有两种MDD 的OLAP产品：基于多维数据库的MOLAP和基于关系数据库的ROLAP。ROLAP建立了一种新的体系，即星型结构。

MDD并没有公认的多维模型，也没有像关系模型那样标准地取得数据的方法(如SQL、API等)。基于MDD的OLAP产品，依据决策支持的内容使用范围也有很大的不同。

在低端，用户使用基于单用户或小型LAN的工具来观察多维数据。这些工具的功能性和实用性可能相当不错，但由于受到规模的限制，它们不具备OLAP的所有特性。这些工具使用超立方结构，将模型限制在n维形态。当模型足够大且稀疏数据没有控制好时，这种模型将会不堪一击。这些工具使用数据库的大小是以MB来计量的，而不是以GB计量的，因此只能进行只读 *** 作，且具备有限的复杂计算。

在高端，OLAP工具用4GL提供了完善的开发环境、统计分析、时间序列分析、财政报告、用户接口、多层体系结构、图表等许多其他功能。尽管不同的OLAP工具都使用了它们自己的多维数据库，但它们在不同程度上也利用了关系数据库作为存储媒体。因为关系数据库和OLAP工具同时在高端服务器上处理，所以速度和效率仍然很快。

纯多维数据库引擎也被开发出来。尽管这些工具缺乏4GL及充分的开发环境，但却有比高端MDD工具所使用的数据库更为复杂的数据库。这些工具也具有统计分析、财务分析和时间序列分析等功能，并有自己的API，允许其对前端的开发环境开放。

MDD能提供优良的查询性能。存储在MDD中的信息比在关系数据库中的信息具有更详细的索引，可以常驻内存。MDD的信息是以数组形式存放的，所以它可以在不影响索引的情况下更新数据。因此MDD非常适合于读写应用。

以上就是关于如何建立和评估数据仓库逻辑模型全部的内容，包括:如何建立和评估数据仓库逻辑模型、请问数据仓库都用什么建立、teradata数据仓库和oracle数据库有什么异同之处等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！