逻辑模型指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看，数据仓库的数据逻辑模型也许是整个项目最重要的方面，需要领域专家的参与。从内容上看，涉及的方面有确立主题域，粒度层次的划分，确定数据分割策略，关系模式的确定。
逻辑模型建设方法
逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF,即 Third Normal Form)和星型模式 (Star-Schema)
第三范式
关系模式满足以下特征：
1 每个属性的值唯一,不具有多义性;
2. 每个非主属性必须完全依赖于整个主键,而非主键的一部分;
3. 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去
星型模型
星型模式是一种多维的数据关系，它由一个事实表(Fact Table)和一组维表(Dimens ion Table)组成。每个维表都有一个维作为主键，所有这些维则组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实 (Fact)，它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。
第三范式和星型模式在数据仓库中的应用
大多数人在设计中央数据仓库的逻辑模型时，都按照第三范式来设计;而在进行物理实施时，则由于数据库引擎的限制，不得不对逻辑模型进行不规范处理 (De-Normalize)， 以提高系统的响应速度，这当然是以增加系统的复杂度、维护工作量、磁盘使用比率 (指原始数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。
那么，在中央数据仓库中是否可以采用星型模式来进行模型设计呢?我们知道，星型模式中有一个事实表和一组维表，我们可以把事实看成是各个维交叉点上的值。
星型模式之所以速度快，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。因此，在星型模式设计的数据仓库中，作报表的速度虽然很快，但由于存在大量的预处理，其建模过程相对来说就比较慢。当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。由于事实表的主键由所有维表的主键组成，这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。综合这些讨论，不难得出结论，星型模式比较适合于预先定义好的问题，如需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此，星型模式在一些要求大量报表的部门数据集市中有较多的应用。
总之，上面讨论了数据仓库模型设计中常用的两种方法。对于部门数据集市，当数据量不大、报表较固定时可以采用星型模式;对于企业级数据仓库，考虑到系统的可扩展能力、投资成本和易于管理等多种因素，最好采用第三范式。
逻辑模型指数据仓库数据的逻辑表现形式。从最终应用的功能和性能的角度来看，数据仓库的数据逻辑模型也许是整个项目最重要的方面，需要领域专家的参与。从内容上看，涉及的方面有确立主题域，粒度层次的划分，确定数据分割策略，关系模式的确定。
逻辑模型的质量标准
对逻辑模型的评估，就是对逻辑模型质量的考察，什么是逻辑模型的质量呢？从狭义的概念说，逻辑模型是否正确表达了业务规则，也就是准确，但是随着人们对数据仓库认识的加深，质量的含义不断延伸,现在对模型质量要求不仅仅单纯指单纯的业务规则，还包括模型满足用户分析需求的程度，它是一个包含丰富内涵、具有多维因素的综合性概念。相应地逻辑模型质量概念的认识也从狭义向广义转变，准确性已不再是衡量唯一标准。评估逻辑模型一般包括如下方面的标准
正确性
逻辑模型的建设方法是正确的，遵循了从上到下和从下到上相结合的方法，选择了正确的模型表示方式，对实际业务采用正确的概化抽象。
准确性（精度）
指逻辑模型和实际业务即“真值”之间的差异程度。误差越小，准确性就越高。这里，所谓的“真值”是可知的，尽管逻辑模型经过了抽象，概化等方法总结共性，但是模型的具体化后，与“真值”是应当符合的。可以通过范围误差、计数误差、不回答率、加工整理差错、模型假设误差等影响准确性的各个因素，测算统计估算值的变动系数、标准差、均方差、曲线配合吻合度、假设检验、偏差等，修正逻辑模型将其的误差控制在一个可接受的置信区间内。
适用性
指收集的信息是否有用，是否符合用户的需求。它要求逻辑模型的粒度，分割方式符合用户的分析需求。
可解释性
是指在公布逻辑模型时，应同时公开逻辑模型的的补充解释信息或称为“元数据”，即关于模型数据的解释说明。内容包括所使用的建设方法，建设目标，以防止模型数据二义性导致错误解释和使用。
完备性
目前的业务需求和所用的业务规则完全包含在逻辑模型中。模型中不存在没有包含的需求业务对象（如实体，属性，以及之间的关系）
一致性
模型中的各个对象命名方式统一，有明确的命名规范。而且模型中各个相关对象的粒度一致，业务逻辑模型对象的划分标准应当统一。
扩展性
当新的业务产生时，仅仅是增加了相关逻辑模型对象的实例内容，不影响目前的逻辑模型，模型这些分类能够随统计分析需求的不同进行相应的调整，无需改变数据库结构，具有灵活的扩展性。仅在个别情况下，需要对逻辑模型的属性或者实体本身增加，支持分步骤的实施。
可衔接性
逻辑模型来自拥有行业经验的概念模型，里面凝聚了许多成功的经验，而且从规划上符合行业系统的长远发展，因此逻辑模型应当从概念模型上相对平滑的过度过来。此外，物理模型应当来自与逻辑模型，逻辑模型的建设应当具有一定的可操作性，便于向物理模型的转化。
逻辑模型中常犯的错误：
命名规范不统一
对于汇总数据，低粒度数据或历史数据采用已定义的命名规范。
粒度层次不统一
有的具体，有的过于抽象
不准确
业务关系表示错
不全面：
一些属性外键标识没有主表
无用关联关系多：
模型中各种对象所表示的内容，应当与用户的业务分析需求密切相关。
与行业通用模型移动的兼容性差：
与行业通用模型存在较大的差异，不利于系统的将来发展符合信息发展的趋势。
总结
商业智能和数据仓库系统的建设作为一个渐进、迭代的过程，其发展趋势是从现有的初步应用如报表分析、数据集市，向深度和广度复杂分析和数据挖掘技术应用发展，其依赖的数据存储模型，包括逻辑模型和物理模型，也是一个不断发展，不断丰富完善的过程。
