正如它的名字所示（Business Model and Mapping Layer），业务逻辑层需要把物理层的数据源以一种业务用户的视角来重新组织物理层的各个数据源（所谓的Mapping），同时在业务逻辑层里，我们将 需要真正构建数据仓库里的星型模型，包括：
· 事实表
· 维表
· 维表的层次结构（hierarchy）
· 事实表度量（measure）来提供一个模型供展现层使用，所以在业务逻辑层，用户需要同时具有技术的知识（数据仓库星型模型），又需要有业务的视角（构 建一个对于业务而言有意义的星型模型）。我们先来看看业务模型层和它所对应的物理层的一个比较： 窗体顶端 窗体底端 窗体顶端 窗体底端 窗体顶端 窗体底端
窗体顶端 窗体底端 业务逻辑层的一个关键的定义是： Captures how users think about their business using their own vocabulary 需要注意的是，虽然业务模型层同样都是来源于物理层的表和列，但是业务模型层更加强调以业务的观点来看所有的数据。其中Mapping一词意味著用户需要 匹配业务模型层的数据和物理层的数据，一个从业务逻辑层看起来的一个逻辑表，其数据来源可以是由物理层的多个数据源组成；而同样的，一个业务模型层的一列 数据，也可以被匹配成物理层不同数据源的多列数据组合而成：比如假设我们在物理层有三个不同的子系统分别对应不同的地区（华北，华南，华东），则如果我们 在业务模型层要定义全国的一个销售额总和的时候，应该就需要把三个子系统的销售额的列在业务模型层相加，才能够形成一个针对全国的分析模型。这个正是 BIEE架构设计里一个非常灵活的地方。当然，如果我们已经在物理层组织好了一个简单的星型模型数据（使用物理层建模），其实我们可以简单地把它从物理层 拖动到业务逻辑层就可以形成一个可用的业务逻辑层的星型模型原型（业务模型层的星型模型会自动延用物理层的建模），然后只需要把这个业务模型拖入到展现层 里，我们就能够做出一个最简单的可供查询的数据模型：是的，在最简单的模型下一切都很简单，我们甚至可以不去建立维表的层次关系，就可以形成一个马上可以 投入使用的模型，只是在没有建立维表的层次关系的时候，我们只能做一些一般性的报表，但是报表出来的结果没有办法下转（商业智能报表的一种典型操作）！业 务模型层的一个最常用的词是logical，如果说我们在物理层都是使用表，表的主键外键，表的列的概念的话，那么我们在业务模型层都要在物理层的名词前 加上logical一词，如：
· Logical Table
· Logical Column
· Logical Primary Key
· Logical Join ·
。。。等等！这些词表明的真正含义是指业务模型层，我们的所谓的表，列等概念都是可以定义出来的（可以和物理层的概念并非是一对一的关系），比如业务模型 层的一个表由多个物理层的表组成等等，对于业务模型层的这种定义和修改不会影响物理层的各种定义所以我们甚至可以在现有的一些业务系统里拿出不同的数据， 在物理层或者业务模型层定义出所需要的分析模型，但是同时这种定义根本不会影响到源系统的任何数据。