一篇全面介绍数据仓库建模方法的热门文章，主要包括四个方面：1.什么是数据模型：简单来说就是对现实世界业务对象和关系的抽象.2.为什么需要数据模型：数据模型不是必需的。建模的目的是改进业务流程，消除信息孤岛和数据差异，提高业务支持的灵活性。3.如何建立数据模型：介绍了数据模型架构的五个主要部分、数据建模的四个阶段和三种主要的建模方法。4、数据仓库建模实例：给出一个社会保障的案例。所谓水无定势，兵无恒法。不同的行业有不同的特点。因此，从业务的角度来看，对应的数据模型有很大的不同。目前业界主流的数据仓库厂商主要是IBM和NCR。这两家公司除了提供比较强大的数据仓库平台外，针对某些行业也有自己的数据模型。比如在银行业，IBM有自己的BDWM（Bankingdatawarehousemodel），而NCR有自己的FS-LDM模型。在电信行业，IBM有TDWM（TelecomDatawarehousemodel），而NCR有自己的TS-LDM模型。所以，我们看到不同的公司对某个行业有自己的理解，所以对于某个行业就会有不同公司的模式。对于不同的行业，同一家公司会有不同的模式，这主要取决于不同行业的不同业务特点。比如IBM的TDWM模型一共包含以下9个概念，如下图：图1IBM的TDWM概念模型很多人可能会问，为什么你的模型有9个概念，而不是10个或11个？您的数据仓库模型的基础是什么？其实这是我们在向客户介绍我们的数据模型时经常被问到的问题。希望读者看完本文后能够找到自己的答案。虽然每个行业都有自己的模型，但我们发现不同行业的数据模型在数据建模方法上有共同的基本特征。写这篇文章的一个主要目的就是希望读者能够根据自己在数据仓库建设方面的经验，总结出一套适合自己在数据仓库建设时的建模方法，从而更好的帮助客户发挥数据仓库。本文的主线是回答以下三个问题：什么是数据模型，为什么需要数据模型，如何构建数据模型最后，在本文的最后，我们介绍了一个具体的数据模型仓库建模，帮助您了解整个数据建模的过程。什么是数据模型？数据模型是抽象描述现实世界的工具和方法。它是一种映射，通过抽象的实体和实体之间的连接形式来表示现实世界中交易之间的关系。在这里，数据模型表示实体之间的抽象关系，通过实体与实体之间关系的定义和描述来表达实际业务中的具体业务关系。数据仓库模型是数据模型中针对特定数据仓库应用系统的特定数据模型。一般来说，我们的数据仓库模型分为以下几个层次，如图1所示。图2数据仓库模型通过上图我们不难看出，在整个数据仓库建模过程中，我们一般需要经过四个流程：业务建模，业务模型生成，主要解决业务层面的分解和程序化。领域建模，生成领域模型，主要是对业务模型进行抽象，生成领域概念模型。逻辑建模，生成逻辑模型，主要是将领域模型的概念实体和数据库层面的实体之间的关系逻辑化。Physicalmodeling，生成物理模型，主要解决不同关系数据库的逻辑模型的物理化、性能等一些具体的技术问题。因此，在整个数据仓库模型的设计和架构中，既涉及到业务知识，也涉及到具体的技术。我们不仅需要了解丰富的行业经验，还需要一定的信息技术来帮助我们实现目标。数据模型，最重要的是，我们还需要一个非常适用的方法论来指导我们在业务的各个阶段进行模型的抽象、处理和生成。为什么需要数据模型在数据仓库的建设中，我们反复强调了数据模型的必要性，那么为什么数据模型如此重要呢？首先，我们需要了解整个数据仓库建设的发展历史。数据仓库的发展一般经历了三个过程：简单报表阶段：这个阶段系统的主要目标是解决业务人员在日常工作中需要的报表，生成一些可以帮助领导的简单报表做决定。聚合数据。这个阶段的表现形式大多是数据库和前端报表工具。数据集市阶段：该阶段主要是根据某个业务部门的需要，收集整理一定的数据，并根据业务人员的需要，展示多维度的报表，为具体的业务指导提供数据，并被能够提供具体的领导决策数据。数据仓库阶段：这个阶段主要是将整个企业的数据按照一定的数据模型进行收集整理，能够根据各业务部门的需求，提供跨部门、完全一致的业务报表数据，能够通过数据仓库传递。生成对业务有指导意义的数据，同时，为领导决策提供全面的数据支持。通过数据仓库建设的发展阶段可以看出，数据仓库建设与数据集市建设的重要区别在于数据模型的支持。因此，数据模型的构建对于我们数据仓库的构建具有决定性的意义。总的来说，数据模型的构建主要可以帮助我们解决以下几个问题：进行全面的业务梳理，完善业务流程。在商业模式建设阶段，可以帮助我们的企业或者管理机构全面梳理所属单位的业务。通过业务模型的构建，我们应该能够全面了解本单位的业务结构图和整个业务的运作情况，能够按照特定的规则对业务进行分类和编程。同时，有助于我们进一步完善业务流程，提高业务效率，指导我们业务单元的生产。建立全面的数据视角，消除信息孤岛和数据差异。通过数据仓库的模型构建，可以为企业提供一个整体的数据视角。不再是每个部门只关注自己的数据，通过模型的构建，勾勒出部门之间的内部关系，帮助消除各个部门之间的差距。更重要的是，通过数据模型的构建，可以保证整个企业的数据一致性，有效解决各部门之间的数据差异。解决业务变化和数据仓库的灵活性。通过数据模型的构建，可以很好的分离底层技术的实现和上层业务的展示。当上层业务发生变化时，通过数据模型，底层技术实现可以轻松完成业务变化，从而实现整个数据仓库系统的灵活性。帮助数据仓库系统本身的建设。通过数据仓库的模型构建，开发人员和业务人员可以轻松定义系统构建的范围和远期目标规划，从而使整个项目组明确当前的任务，加快整个系统的构建。如何建立数据模型既然建立数据模型是整个数据仓库建设中非常重要的关键环节，那么如何建立我们的数据仓库模型就是我们需要解决的问题。下面我们将详细介绍如何创建适合自己的数据模型。数据仓库数据模型架构数据仓库的数据模型架构与数据仓库的整体架构密切相关。我们先了解一下整个数据仓库的数据模型应该包含的几个部分。从下图中我们可以清楚的看出整个数据模型的架构分为5个部分，每个部分其实都有其独特的功能。图3数据仓库数据模型架构从上图我们可以看出整个数据仓库的数据模型大概可以分为5个部分：SystemofRecord：这部分是主要的数据仓库业务数据存储区，数据这里的模型保证了数据的一致性。内部管理域（Housekeeping）：这部分主要存储数据仓库内部管理使用的元数据，数据模型可以帮助统一元数据管理。SummaryofArea：这部分数据来自于系统记录域的汇总。这里的数据模型保证了分析域主题分析的性能，满足一些报表查询。分析区：这部分数据模型主要用于各业务部分的具体主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。FeedbackArea：可选，这部分数据模型主要用于对应的前端反馈数据，数据仓库可以根据业务需要设置该区域。通过对整个数据仓库模型数据区域的划分，我们可以了解到，一个好的数据模型不仅对业务进行了抽象的划分，而且在实现技术上也给出了具体的指导。它应该涵盖从业务到实施的方方面面。技术的各个部分。数据仓库建模阶段的划分前面我们已经介绍了数据仓库模型的几个层次，下面说说这些层次的不同阶段数据建模工作的主要内容：图4数据仓库建模阶段的划分从图中上面我们可以清楚的看到，数据仓库的数据建模大致分为四个阶段：业务建模，这部分建模工作主要包括以下几个部分：划分、定义各部门之间的业务工作，明确各业务部门之间的关系。深入了解每个业务部门内的特定业务流程并对其进行编程。提出并以编程方式修改和改进业务部门的工作流程。数据建模的范围、目标和整个数据仓库项目的分阶段。领域概念建模，这部分的建模工作，主要包括以下几个部分：提取关键业务概念并进行抽象。对业务概念进行分组，按照业务线聚合相似的分组概念。细化分组的概念，在分组的概念中明确和抽象业务流程。理清分组概念之间的关系，形成完整的领域概念模型。逻辑建模，这部分建模工作，主要包括以下几个部分：业务概念物化，及其具体属性事件物化，及其属性内容描述物化，及其属性内容物理建模，这部分建模工作主要包括以下部分：针对具体的物理平台，做相应的技术调整，考虑模型的性能，针对具体的平台做相应的调整，满足管理的需要，结合具体的平台，做相应的调整，生成最终的执行脚本并改进它。从我们上面对数据仓库的数据建模阶段的划分，我们可以了解到整个数据仓库建模的主要工作和工作量，希望对我们在实际的项目建设中有所帮助。数据仓库建模方法浩如烟海，表面上看起来五光十色，但本质上，一切都遵循着自己的规律。数据仓库的建模方法也有很多。每一种建模方法其实都代表着一种哲学观点，一种归纳，一种概括世界的方法。目前业界流行的数据仓库建模方法有很多。这里主要介绍范式建模、维度建模、实体建模等几种方法。每种方法实际上都是从不同的角度来看的。我们业务中的问题，无论从技术层面还是业务层面，其实都代表着一种哲学世界观。下面我们将详细介绍这些建模方法。1.范式建模法（ThirdNormalForm，3NF）范式建模法其实是我们在构建数据模型时经常使用的一种方法。这种方法主要是Inmon提倡的。主要解决关系型数据库中数据存储的问题。一种技术方法。目前我们在关系数据库中的建模方法大多采用三范式建模方法。范式是数据库逻辑模型设计的基本理论。关系模型可以无损地从第一范式分解为第五范式。这个过程也可以称为归一化。在数据仓库的模型设计中，目前普遍采用第三范式，它有严格的数学定义。从其表达的意义来看，一个符合第三范式的关系必须具备以下三个条件：每个属性值都是唯一的，没有歧义；每个非主属性必须完全依赖于整个主键，而不是主键部分；每个非主要属性不能依赖于其他关系中的属性，因为在这种情况下，该属性应该归因于其他关系。由于范式是在整个关系数据库理论的基础上发展起来的，这里就不多介绍了。有兴趣的读者可以通过阅读相应的资料获得这方面的知识。在Inmon看来，数据仓库模型的构建方法类似于业务系统的企业数据模型。在业务系统中，企业数据模型决定了数据的来源，企业数据模型也分为两个层次，即主题领域模型和逻辑模型。同样，主题领域模型可以看作是业务模型的概念模型，而逻辑模型则是领域模型在关系数据库上的实例词。图5当范式建模方法从业务数据模型转变为数据仓库模型时，还需要数据仓库的领域模型，即概念模型，同时还有领域模型的逻辑模型。在这里，业务模型中的数据模型与数据仓库模型略有不同。主要的区别是数据仓库的领域模型应该包含企业数据模型的领域模型之间的关系和每个主题领域的定义。数据仓库的领域模型的概念应该比业务系统的主题领域模型更广泛。数据仓库中的逻辑模型需要从业务系统数据模型中的逻辑模型中抽象出实体、实体的属性、实体的子类、实体的关系。在笔者看来，Inmon的范式建模方法最大的优势在于，从关系数据库的角度出发，结合业务系统的数据模型，可以更方便地实现数据仓库的建模。但其缺点也很明显。由于建模方法仅限于关系数据库，在某些时候它限制了整个数据仓库模型的灵活性和性能，特别是考虑到数据仓库的底层数据到数据集市。在汇总数据时，需要进行一些修改以满足相应的需求。因此，笔者建议读者在实际使用中参考此建模方法。2.维度建模法维度建模法，Kimball首先提出这个概念。最简单的描述就是根据事实表和维表构建数据仓库和数据集市。这种方法最广为人知的名称是星型模式。图6维度建模方法上图中的架构是一个典型的星型架构。星型模式之所以被广泛使用，是因为对每个维度都做了很多预处理，比如根据维度进行预统计、分类、排序等。通过这些预处理，可以大大提高数据仓库的处理能力。特别是对于3NF建模方法，星型模式在性能上有着明显的优势。同时，维度建模方法的另一个优点是维度建模非常直观，紧密围绕业务模型，能够直观地反映业务模型中存在的业务问题。无需特殊抽象就可以进行维度建模。这也是维度建模的优势。但是，维度建模方法的缺点也非常明显，因为在构建星型模式之前需要进行大量的数据预处理，这会导致大量的数据处理工作。而且，当业务发生变化，需要重新定义维度时，往往需要对维度数据进行重新预处理。而在这些过程中，往往会导致大量的数据冗余。维度建模方法的另一个缺点是，如果仅仅依靠纯维度建模，数据源的一致性和准确性无法保证，特别不适合数据仓库底层的维度建模。因此，在笔者看来，维度建模领域主要适用于数据集市层，其最大的作用其实是解决数据仓库建模中的性能问题。维度建模很难提供一种抽象的方法来完整描述真实业务实体之间的复杂关系。3.实体建模方法实体建模方法不是数据仓库建模中常用的方法，它来自一个哲学流派。从哲学的角度来说，客观世界应该细分，客观世界应该分为实体和实体之间的关系。那么我们完全可以在数据仓库的建模过程中引入这个抽象方法，整个业务也可以划分为实体，每个实体之间的关系以及这些关系的描述就是我们的数据。模型需要完成这项工作。实体法虽然乍看之下有些抽象，但其实很容易理解。即我们可以将任何业务流程分为实体、事件和描述三部分，如下图所示：图7实体建模方法上图表达了一个抽象的意思，如果我们描述一个简单的事实：“小明开车去学校去上学。”以这个业务事实为例，我们可以把“小明”和“学校”看成一个实体，“上学”描述的是一个业务流程。这里我们可以将其抽象为一个具体的“事件”，而“开车去”则可以看作是对“上学”事件的一种解释。从上面的例子我们可以了解到，我们使用的抽象归纳法其实很简单。任何业务都可以看成三部分：实体，主要是指领域模型中具体的概念主体，是指与之发生业务关系的客体。事件主要是指概念主体之间完成一个业务流程，特别是一个具体业务流程的过程。指令主要是针对实体和事件的特殊指令。由于采用实体建模的方式，可以很容易地实现业务模型的划分。因此，实体建模方法在业务建模和领域概念建模阶段有着广泛的应用。从笔者的经验来看，在没有现成的行业模型的情况下，可以采用实体建模的方法，与客户明确整个业务的模型，划分领域概念模型，抽象出具体的业务概念。结合客户的使用特点，您可以创建满足您需求的数据仓库模型。但是，实体建模方法也有其固有的缺陷。由于实体描述方法只是对客观世界的一种抽象方法，注定了这种建模方法只能局限于业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，正是范式建模和维度建模发挥其长处的阶段。因此，笔者建议读者在创建自己的数据仓库模型时，可以参考以上三种数据仓库建模方法，在不同的阶段采用不同的方法，从而保证整个数据仓库建模的质量。上面的数据仓库建模示例介绍了一些抽象的建模方法和理论，理解起来可能比较困难。因此，作者在这里举了一个例子。读者可以跟随我们的示例，初步了解整个数据仓库建模的大致流程。背景介绍熟悉社保行业的读者都可以知道，我国的社保主要分为养老、失业、工伤、生育、医疗保险和劳动力市场六大业务领域。在这六大业务领域中，目前养老和职业体系已经基本完善，部分数据已经开始上线测试。在工伤、生育、医疗和劳动力市场业务方面，有的领域比较成熟，有的领域还不够成熟。1.业务建模阶段基于以上背景介绍，我们可以很容易的划分出业务建模阶段对应的业务。因此，在业务建模阶段，我们就基本确定了我们数据仓库建设的目标、建设方式和远景规划。如下图所示：图8业务建模阶段在这里，我们把整个业务明确划分为几大业务线，比如：养老、失业、工伤、生育、医疗、劳务等主要部分，那么我们可以根据这些大模块来考虑各个业务主线内需要分析的业务主题。所以，业务建模阶段其实就是和业务人员一起梳理业务的过程。在这个过程中，不仅可以帮助我们的技术人员更好的了解业务，还可以发现业务流程中一些不合理的环节，改进和提高。同时，业务建模阶段的另一个重要任务就是确定我们数据建模的范围。比如在一些数据准备不够充分的业务模块中，我们可以考虑先不构建相应的数据模型。当条件完全成熟时，我们可以考虑数据建模的问题。2.领域概念建模阶段领域概念建模阶段是数据仓库数据建模的一个重要阶段。由于我们在业务建模阶段已经完全明确了相应的业务范围和流程，所以我们在这个领域概念建模阶段的主要任务是抽象概念。整个领域概念建模的工作层次如下图所示：图9领域概念建模阶段从上图我们可以清楚的看出，领域概念建模是使用实体的建模方法抽象实体如实体，事件，以及通过实体建模的方法从复杂的业务表象背后进行描述，从而找出业务表象背后的抽象实体之间的相互关系，保证我们的数据仓库数据符合的一致性和关联性一个数据模型就可以实现。从图中我们可以将整个抽象过程分为四个层次，分别是：抽象方法层，整个数据模型的核心方法，以及通过这个抽象方法对领域概念建模实体的划分。领域概念层是我们整个数据模型的核心部分，因为不同的抽象层次决定了我们领域概念的差异。例如：这里，我们可以使用“参与者”的概念，同时，你也可以将其分为“个人”、“公司”、“组织”三个概念。我们在构建自己的模型时，可以参考业务情况和自己模型的需求，选择抽象度高的概念或者抽象度低的概念。相对而言，抽象度高的概念理解起来比较复杂，需要专业的建模专家才能理解，而抽象度低的概念更适合一般业务人员理解，使用起来也更方便。笔者在此建议读者可以选择抽象概念较低的实体，以方便业务人员与技术人员的交流与交流。具体业务层主要是解决具体的业务问题。从这张图中我们可以看出，具体的业务层其实只是领域概念模型中实体的一些不同组合。因此，一个完整的数据仓库的数据模型应该能够响应灵活多变的前端业务需求，其自身的模型架构具有很强的灵活性。这是数据仓库模型的功能之一。业务主线层，这一层主要划分大的业务域，一般在业务建模阶段就已经完成了这个划分。我们一般用这条大业务主线来划分整个业务模型的大框架。通过领域概念建模，将数据仓库的模型抽象为个体实体，构建了模型的框架。接下来的工作就是将有效的主体注入到这些框架中。3.逻辑建模阶段领域概念建模之后，虽然模型的框架已经完成，但是还有很多细节工作要做。一般在这个阶段，我们还需要做很多工作，主要包括：实例化各个抽象实体，例如：在上面的概念模型之后，我们需要实例化这些抽象实体如“人”、“公司”的变化。主要是我们要考虑“person”的属性，包括那些，就是业务模块中用到的所有和“person”相关的属性，我们需要把这些属性附加到我们数据模型的“person”实体上，比如“人”的年龄、性别、受教育程度等等。同样，我们也需要为其他属性做这项工作。找出抽象实体之间的联系并举例说明。这里，我们主要考虑“事件”这个抽象概念的例子，比如必须考虑养老金领取等“事件”的属性，必须考虑失业人员培训等“事件”的属性。考虑等等。找到抽象事件之间的关系并解释它们。这里我们主要是想对“事件”做一个完美的“描述”。例如：对“事件”中的地域、事件等因素的考虑等。总而言之，在逻辑建模阶段，我们主要考虑抽象实体的一些细节属性。只有通过逻辑建模阶段，才能将整个概念模型连接成一个有机的实体，充分表达业务之间的关系。现阶段笔者建议大家可以参考3NF建模方法来表达实体的属性和实体之间的联系。例如：现阶段我们可以使用ERWIN等建模工具制作符合3NF的关系数据模型。4.物理建模阶段物理建模阶段是整个数据建模过程的最后一个过程。这个过程其实就是把之前的逻辑数据模型落地的过程。考虑到不同的数据仓库平台，数据模型的物理建模过程可能会略有不同。在这个阶段，我们的主要工作是生成创建表的脚本。不同的数据仓库平台可能会生成不同的脚本。针对不同的数据仓库平台，进行一些相应的优化工作，例如针对DB2数据仓库，创建一些MQT表来加快报表生成等。根据数据集市的需要，按照维??度建模的方法生成一些事实表、维度表等。根据数据仓库的ETL载体和元数据管理的需要，生成数据仓库维护的一些表，比如日志表等。经过物理建模阶段，整个数据仓库的模型已经完成，并且我们可以针对当前行业，根据自己的设计，创建符合自己需求的数据模型。在此，笔者以数据建模为例，希望能让读者对数据仓库建模有一个感性的认识。希望读者在使用这些数据仓库建模方法创建自己的数据模型时，能够根据业务的实际需求和自己对抽象能力的掌握，创建出适合自己的数据模型。
