数据仓库简介

1. 数据仓库是什么？

数据仓库，英文名称Data Warehouse，可简写为DW或DWH。数据仓库是为企业各级决策过程提供各类数据支持的战略集合。它是为分析报告和决策支持而创建的。 为需要业务智能的企业提供指导业务流程改进、监控时间、成本、质量和控制。

1. 数据仓库的特点

1.数据仓库的数据是面向主题的

与传统数据库面向应用的数据组织特征相对应，数据仓库中的数据是面向主题的。主题是什么？首先，主题是一个抽象的概念，是企业信息系统中数据的综合、分类和分析。从逻辑意义上，它是企业宏观分析领域所涉及的分析对象。面向主题的数据组织模式是对高层次分析对象的数据进行完整一致的描述，可以完整统一地描述各分析对象涉及的企业的数据，以及数据之间的联系。所谓的高层次是相对面向应用的数据组织模式，是指数据组织模式的主题具有较高的数据抽象水平。

2. 数据仓库的数据是集成的

数据来分散的数据库数据中提取数据仓库数据。操作数据和DSS分析数据差别很大。首先，数据仓库各主题对应的源数据在原分散数据库中有许多重复和不一致，不同在线系统的数据与不同的应用逻辑捆绑在一起；其次，数据仓库中的综合数据不能直接从原始数据库系统中获得。因此，在数据进入数据仓库之前，必须统一和综合。这一步是数据仓库建设中最关键、最复杂的一步。要完成的工作包括： (1)统一源数据中的所有矛盾，如同名异义、异名同义、单位不一致、字长不一致等。 (2)进行数据综合和计算。从原始数据库中提取数据仓库中的数据综合工作 数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。

3. 数据仓库的数据是不可更新的

数据仓库的数据主要用于企业决策分析，涉及的数据操作主要是数据查询，一般不修改操作。数据仓库的数据反映了历史数据的长期内容，数据库快照的收集，以及基于这些快照的统计、综合和重组的导出数据，而不是在线处理的数据。数据库中在线处理的数据集成并输入到数据仓库中。一旦数据仓库存储的数据超过数据仓库的数据存储期，这些数据将从当前的数据仓库中删除。数据仓库管理系统比数据库管理系统简单得多，因为数据仓库只进行数据查询操作。数据库管理系统中的许多技术难点，如完整性保护、并发控制等，在数据库管理中几乎可以节省。然而，由于数据仓库的查询数据量往往很大，对数据查询提出了更高的要求，需要各种复杂的索引技术；同时，由于数据仓库面向商业企业的高级管理人员，他们对数据查询的界面友好性和数据表了更高的要求。

4. 数据仓库的数据随时间变化

数据仓库中的数据不能更新是针对应用程序的，也就是说，数据仓库的用户在分析和处理时不进行数据更新。但这并不意味着所有的数据仓库数据在从数据集成输入数据仓库到最终删除的整个数据生存周期中都是永恒的。 随着时间的推移，数据仓库的数据不断变化，这是数据仓库数据的第四个特征。这一特征体现在以下三个方面： (1)数据仓库随时间增加新的数据内容。必须不断捕捉数据仓库系统OLTP数据库中变化的数据被添加到数据仓库中，即不断生成OLTP数据库的快照在统一集成后添加到数据库中；但对于不再改变的数据库快照，如果捕获新的变化数据，只生成新的数据库快照，而不修改原始数据库快照。 (2)随着时间的推移，数据仓库不断删除旧的数据内容。数据仓库的数据也有存储期。一旦超过此期限，将删除过期数据。但数据仓库中的数据时限远远长于操作环境中的数据时限。一般在操作环境中只保存60~数据需要90天，数据仓库需要保存很长时间(如5天)~适应10年DSS趋势分析的要求。 （3）数据仓库包含大量的综合数据，其中许多与时间有关，如数据经常根据时间段进行综合，或每隔一段时间进行抽样等。这些数据应该随着时间的变化而重新整合。因此，数据仓库的数据特征包含时间项，以标记数据的历史时期。

1. 数据仓库的发展历程

数据仓库的发展大致经历了三个过程：

• 简单报表阶段：在这个阶段，系统的主要目标是解决一些业务人员在日常工作中需要的报告，并生成一些简单的汇总数据，可以帮助领导做出决策。现阶段的大部分表现形式是数据库和前端报告工具。
• 数据集市阶段：现阶段主要根据业务部门的需要收集整理一定数据，根据业务人员的需要展示多维报表，提供具体业务指导数据和具体领导决策数据。
• 数据仓库阶段：现阶段主要根据一定的数据模型收集整个企业的数据，并根据各业务部门的需要提供跨部门、完全一致的业务报表数据，通过数据仓库生成指导业务的数据，同时为领导决策提供全面的数据支持。

从数据仓库建设的发展阶段可以看出，数据仓库建设与数据市场建设的重要区别在于数据模型的支持。因此，数据模型的建设对我们数据仓库的建设具有决定性的意义。

1. 数据库和数据仓库的区别

在了解数据库和数据仓库的区别之前，首先要掌握三个概念。数据库软件、数据库、数据仓库。

数据库软件：是一种可见、可操作的软件。用于实现数据库的逻辑功能。属于物理层。

数据库：用于存储数据的逻辑概念仓库。通过数据库软件实现。数据库由许多表组成，表是二维的，表中可以有许多字段。字段一字排开，相应数据一行一行写入表中。数据库的表可以用二维表达多维关系。市场上流行的数据库都是二维数据库。如：Oracle、DB2、MySQL、Sybase、MS SQL Server等。

数据仓库：是数据库概念的升级。从逻辑上讲，数据库和数据仓库之间没有区别们都是通过数据库软件存储数据的地方，但就数据量而言，数据仓库比数据库大得多。数据仓库主要用于数据挖掘和数据分析，辅助领导做出决策。

在IT数据库必须存在于架构系统中。必须有地方存储数据。比如网购、淘宝、京东等。库存数量、价格、用户账户余额等。这些数据存储在后台数据库中。或者最简单的理解，我们现在的微博，QQ用户名和密码等账户。后台数据库必须有一个user至少有两个字段，即用户名和密码，然后我们的数据存在于表上。当我们登录时，我们填写用户名和密码，这些数据将被传回后台，匹配表上的数据了，你就能登录了。匹配不成功就会报错说密码错误或者没有此用户名等。这个就是数据库，数据库在生产环境就是用来干活的。凡是跟业务应用挂钩的，我们都使用数据库。

数据仓库则是BI下的其中一种技术。由于数据库是跟业务应用挂钩的，所以一个数据库不可能装下一家公司的所有数据。数据库的表设计往往是针对某一个应用进行设计的。比如刚才那个登录的功能，这张user表上就只有这两个字段，没有别的字段了。但是这张表符合应用，没有问题。但是这张表不符合分析。比如我想知道在哪个时间段，用户登录的量最多？哪个用户一年购物最多？诸如此类的指标。那就要重新设计数据库的表结构了。对于数据分析和数据挖掘，我们引入数据仓库概念。数据仓库的表结构是依照分析需求，分析维度，分析指标进行设计的。

数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。

操作型处理，叫联机事务处理OLTP（On-Line Transaction Processing，），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。

分析型处理，叫联机分析处理OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。

1. 数据仓库架构分层

数据仓库标准上可以分为四层：ODS（临时存储层）、PDW（数据仓库层）、DM（数据集市层）、APP（应用层）。

 

 

  ODS层：

为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。一般来说ODS层的数据和源系统的数据是同构的，主要目的是简化后续数据加工处理的工作。从数据粒度上来说ODS层的数据粒度是最细的。ODS层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。历史数据一般保存3-6个月后需要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚至全量保存；

 

 

PDW层：

为数据仓库层，PDW层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。这一层的数据一般是遵循数据库第三范式的，其数据粒度通常和ODS的粒度相同。在PDW层会保存BI系统中所有的历史数据，例如保存10年的数据。

 

DM层：

为数据集市层，这层数据是面向主题来组织数据的，通常是星形或雪花结构的数据。从数据粒度来说，这层的数据是轻度汇总级的数据，已经不存在明细数据了。从数据的时间跨度来说，通常是PDW层的一部分，主要的目的是为了满足用户分析的需求，而从分析的角度来说，用户通常只需要分析近几年（如近三年的数据）的即可。从数据的广度来说，仍然覆盖了所有业务数据。

 

 

APP层：

为应用层，这层数据是完全为了满足具体的分析需求而构建的数据，也是星形或雪花结构的数据。从数据粒度来说是高度汇总的数据。从数据的广度来说，则并不一定会覆盖所有业务数据，而是DM层数据的一个真子集，从某种意义上来说是DM层数据的一个重复。从极端情况来说，可以为每一张报表在APP层构建一个模型来支持，达到以空间换时间的目的数据仓库的标准分层只是一个建议性质的标准，实际实施时需要根据实际情况确定数据仓库的分层，不同类型的数据也可能采取不同的分层方法。

 

为什么要对数据仓库分层：

1用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据；

 

2如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大

 

3通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。

 

1. 元数据介绍

当需要了解某地企业及其提供的服务时，电话黄页的重要性就体现出来了。元数据（Metadata）类似于这样的电话黄页。

1．元数据的定义

    数据仓库的元数据是关于数据仓库中数据的数据。它的作用类似于数据库管理系统的数据字典，保存了逻辑数据结构、文件、地址和索引等信息。广义上讲，在数据仓库中，元数据描述了数据仓库内数据的结构和建立方法的数据。

      元数据是数据仓库管理系统的重要组成部分，元数据管理器是企业级数据仓库中的关键组件，贯穿数据仓库构建的整个过程，直接影响着数据仓库的构建、使用和维护。

（1）构建数据仓库的主要步骤之一是ETL。这时元数据将发挥重要的作用，它定义了源数据系统到数据仓库的映射、数据转换的规则、数据仓库的逻辑结构、数据更新的规则、数据导入历史记录以及装载周期等相关内容。数据抽取和转换的专家以及数据仓库管理员正是通过元数据高效地构建数据仓库。

（2）用户在使用数据仓库时，通过元数据访问数据，明确数据项的含义以及定制报表。

（3）数据仓库的规模及其复杂性离不开正确的元数据管理，包括增加或移除外部数据源，改变数据清洗方法，控制出错的查询以及安排备份等。

      元数据可分为技术元数据和业务元数据。技术元数据为开发和管理数据仓库的IT 人员使用，它描述了与数据仓库开发、管理和维护相关的数据，包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。而业务元数据为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等，帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。

由上可见，元数据不仅定义了数据仓库中数据的模式、来源、抽取和转换规则等，而且是整个数据仓库系统运行的基础，元数据把数据仓库系统中各个松散的组件联系起来，组成了一个有机的整体，如图3.5 所示

 

2．元数据的存储方式

     元数据有两种常见存储方式：一种是以数据集为基础，每一个数据集有对应的元数据文件，每一个元数据文件包含对应数据集的元数据内容；另一种存储方式是以数据库为基础，即元数据库。其中元数据文件由若干项组成，每一项表示元数据的一个要素，每条记录为数据集的元数据内容。上述存储方式各有优缺点，第一种存储方式的优点是调用数据时相应的元数据也作为一个独立的文件被传输，相对数据库有较强的独立性，在对元数据进行检索时可以利用数据库的功能实现，也可以把元数据文件调到其他数据库系统中操作；不足是如果每一数据集都对应一个元数据文档，在规模巨大的数据库中则会有大量的元数据文件，管理不方便。第二种存储方式下，元数据库中只有一个元数据文件，管理比较方便，添加或删除数据集，只要在该文件中添加或删除相应的记录项即可。在获取某数据集的元数据时，因为实际得到的只是关系表格数据的一条记录，所以要求用户系统可以接受这种特定形式的数据。因此推荐使用元数据库的方式。

      元数据库用于存储元数据，因此元数据库最好选用主流的关系数据库管理系统。元数据库还包含用于操作和查询元数据的机制。建立元数据库的主要好处是提供统一的数据结构和业务规则，易于把企业内部的多个数据集市有机地集成起来。目前，一些企业倾向建立多个数据集市，而不是一个集中的数据仓库，这时可以考虑在建立数据仓库（或数据集市）之前，先建立一个用于描述数据、服务应用集成的元数据库，做好数据仓库实施的初期支持工作，对后续开发和维护有很大的帮助。元数据库保证了数据仓库数据的一致性和准确性，为企业进行数据质量管理提供基础。

 

3．元数据的作用

      在数据仓库中，元数据的主要作用如下。

（1）描述哪些数据在数据仓库中，帮助决策分析者对数据仓库的内容定位。

（2）定义数据进入数据仓库的方式，作为数据汇总、映射和清洗的指南。

（3）记录业务事件发生而随之进行的数据抽取工作时间安排。

（4）记录并检测系统数据一致性的要求和执行情况。

（5）评估数据质量。

          

 

 

1. 什么是数据模型

  数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。在这里，数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。

数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型，一般的来说，我们数据仓库模型分为几下几个层次，如图 2 所示。

图 2. 数据仓库模型

 

通过上面的图形，我们能够很容易的看出在整个数据仓库得建模过程中，我们需要经历一般四个过程：

• 业务建模，生成业务模型，主要解决业务层面的分解和程序化。
• 领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
• 逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
• 物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。

因此，在整个数据仓库的模型的设计和架构中，既涉及到业务知识，也涉及到了具体的技术，我们既需要了解丰富的行业经验，同时，也需要一定的信息技术来帮助我们实现我们的数据模型，最重要的是，我们还需要一个非常适用的方法论，来指导我们自己针对我们的业务进行抽象，处理，生成各个阶段的模型。

 

1. 为什么需要数据仓库模型

在数据仓库的建设中，我们一再强调需要数据模型，那么数据模型究竟为什么这么重要呢？首先我们需要了解整个数据仓库的建设的发展史。

数据仓库的发展大致经历了这样的三个过程：

• 简单报表阶段：这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前端报表工具。
• 数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。
• 数据仓库阶段：这个阶段，主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据，同时，为领导决策提供全面的数据支持。

通过数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。

一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题：

• 进行全面的业务梳理，改进业务流程。在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化，同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。
• 建立全方位的数据视角，消灭信息孤岛和数据差异。通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的数据，而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消灭各个部门之间的信息孤岛的问题，更为重要的是，通过数据模型的建设，能够保证整个企业的数据的一致性，各个部门之间数据的差异将会得到有效解决。
• 解决业务的变动和数据仓库的灵活性。通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库系统的灵活性。
• 帮助数据仓库系统本身的建设。通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。

 

1. 如何建设数据仓库模型

建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分，那么，怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。

3.1  数据仓库数据模型架构

数据仓库的数据模型的架构和数据仓库的整体架构是紧密关联在一起的，我们首先来了解一下整个数据仓库的数据模型应该包含的几个部分。从下图我们可以很清楚地看到，整个数据模型的架构分成 5 大部分，每个部分其实都有其独特的功能。

图 3. 数据仓库数据模型架构

 

从上图我们可以看出，整个数据仓库的数据模型可以分为大概 5 大部分：

• 系统记录域（System of Record）：这部分是主要的数据仓库业务数据存储区，数据模型在这里保证了数据的一致性。
• 内部管理域（Housekeeping）：这部分主要存储数据仓库用于内部管理的元数据，数据模型在这里能够帮助进行统一的元数据的管理。
• 汇总域（Summary of Area）：这部分数据来自于系统记录域的汇总，数据模型在这里保证了分析域的主题分析的性能，满足了部分的报表查询。
• 分析域（Analysis Area）：这部分数据模型主要用于各个业务部分的具体的主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。
• 反馈域（Feedback Area）：可选项，这部分数据模型主要用于相应前端的反馈数据，数据仓库可以视业务的需要设置这一区域。

通过对整个数据仓库模型的数据区域的划分，我们可以了解到，一个好的数据模型，不仅仅是对业务进行抽象划分，而且对实现技术也进行具体的指导，它应该涵盖了从业务到实现技术的各个部分。

3.2  数据仓库建模阶段划分

我们前面介绍了数据仓库模型的几个层次，下面我们讲一下，针对这几个层次的不同阶段的数据建模的工作的主要内容：

图 4. 数据仓库建模阶段划分

 

从上图我们可以清楚地看出，数据仓库的数据建模大致分为四个阶段：

1.   业务建模，这部分建模工作，主要包含以下几个部分：

• 划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
• 深入了解各个业务部门的内具体业务流程并将其程序化。
• 提出修改和改进业务部门工作流程的方法并程序化。
• 数据建模的范围界定，整个数据仓库项目的目标和阶段划分。

2.   领域概念建模，这部分得建模工作，主要包含以下几个部分：

• 抽取关键业务概念，并将之抽象化。
• 将业务概念分组，按照业务主线聚合类似的分组概念。
• 细化分组概念，理清分组概念内的业务流程并抽象化。
• 理清分组概念之间的关联，形成完整的领域概念模型。

3.   逻辑建模，这部分的建模工作，主要包含以下几个部分：

• 业务概念实体化，并考虑其具体的属性
• 事件实体化，并考虑其属性内容
• 说明实体化，并考虑其属性内容

4.   物理建模，这部分得建模工作，主要包含以下几个部分：

• 针对特定物理化平台，做出相应的技术调整
• 针对模型的性能考虑，对特定平台作出相应的调整
• 针对管理的需要，结合特定的平台，做出相应的调整
• 生成最后的执行脚本，并完善之。

从我们上面对数据仓库的数据建模阶段的各个阶段的划分，我们能够了解到整个数据仓库建模的主要工作和工作量，希望能够对我们在实际的项目建设能够有所帮助。

3.4 数据仓库建模方法

大千世界，表面看五彩缤纷，实质上，万物都遵循其自有的法则。数据仓库的建模方法同样也有很多种，每一种建模方法其实代表了哲学上的一个观点，代表了一种归纳，概括世界的一种方法。目前业界较为流行的数据仓库的建模方法非常多，这里主要介绍范式建模法，维度建模法，实体建模法等几种方法，每种方法其实从本质上讲就是从不同的角度看我们业务中的问题，不管从技术层面还是业务层面，其实代表的是哲学上的一种世界观。我们下面给大家详细介绍一下这些建模方法。

1. 范式建模法（Third Normal Form，3NF）

范式建模法其实是我们在构建数据模型常用的一个方法，该方法的主要由 Inmon 所提倡，主要解决关系型数据库得数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。

范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件 :

• 每个属性值唯一，不具有多义性 ;
• 每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
• 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。

由于范式是基于整个关系型数据库的理论基础之上发展而来的，因此，本人在这里不多做介绍，有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。

根据 Inmon 的观点，数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例。

图 5. 范式建模法

 

从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于：

• 数据仓库的域模型应该包含企业数据模型的域模型之间的关系，以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
• 在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。

以笔者的观点来看，Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。因此，笔者建议读者们在实际的使用中，参考使用这一建模方式。

2. 维度建模法

维度建模法，Kimball 最先提出这一概念。其最简单的描述就是，按照事实表，维表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式（Star-schema）。

图 6. 维度建模法

 

上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。通过这些预处理，能够极大的提升数据仓库的处理能力。特别是针对 3NF 的建模方法，星型模式在性能上占据明显的优势。

同时，维度建模法的另外一个优点是，维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。这一点也是维度建模的优势。

但是，维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。

另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。

因此以笔者的观点看，维度建模的领域主要适用与数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。

3. 实体建模法

实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。

虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分，实体，事件和说明，如下图所示：

图 7. 实体建模法

 

上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。

从上面的举例我们可以了解，我们使用的抽象归纳方法其实很简单，任何业务可以看成 3 个部分：

• 实体，主要指领域模型中特定的概念主体，指发生业务关系的对象。
• 事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。
• 说明，主要是针对实体和事件的特殊说明。

由于实体建模法，能够很轻松的实现业务模型的划分，因此，在业务建模阶段和领域概念建模阶段，实体建模法有着广泛的应用。从笔者的经验来看，再没有现成的行业模型的情况下，我们可以采用实体建模的方法，和客户一起理清整个业务的模型，进行领域概念模型的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。

但是，实体建模法也有着自己先天的缺陷，由于实体说明法只是一种抽象客观世界的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。

因此，笔者建议读者在创建自己的数据仓库模型的时候，可以参考使用上述的三种数据仓库得建模方法，在各个不同阶段采用不同的方法，从而能够保证整个数据仓库建模的质量。

 

数据仓库命名规范

                                                                                                                                                              

 

1. 概述

数据模型是数据管理的分析工具和交流的有力手段；同时，还能够很好地保证数据的一致性，是实现商务智能（Business Intelligence）的重要基础。因此建立、管理一个企业级的数据模型，应该遵循标准的命名和设计规范。

 

 

1. 数据仓库命名规范
   1. 命名规范
      1. 表属性规范
         1. 表名
            1. ODS层表名

前缀为ODS_应用系统名（缩写）_数据表名 。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：ODS_FUN_CUSTOMERINFO。表名称不能用双引号包含，表名长度不超过30个字符。如果ODS设计采用贴源设计，数据表名应与源系统一致。

1. 系统和应用名规则如下：
   1. 核心       COR
   2. 对公信贷    CLN
   3. 个贷       PLN
   4. 基金       FUN
   5. 票据       TIC
   6. 理财        FIN
   7. 报表        RPT
   8. ……
   9. 如有新系统，按规则添加[s1] 
      1. 1. 1. DW事实表表名

前缀为DW_主题名（缩写）_功能描述 。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：DW_ORD_DETAIL。表名称不能用双引号包含，表名长度不超过30个字符[s2] 。

1. 主题名规则如下：
   1. 订单       ORD
   2. 营销活动    MKC
   3. 贷款        LN
   4. 网银       NET
   5. 客户        CUS
   6. ……
   7. 如有新主题，按规则添加
2. 数据表名规则如下：
   1. 基础表        _BA
   2. 日汇总表       _D
   3. 月汇总表       _M
   4. 历史累计       _H
   5. 全量加载       _A
   6. 增量加载       _I

 

1. 1. 1. 1. 1. APP应用层表名

前缀为APP_主题名（缩写）_功能描述 。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：  APP_RPT_ DEALER_GOODS。表名称不能用双引号包含，表名长度不超过30个字符。

1. 主题名规则如下：
   1. 报表       RPT
2. 数据表名规则如下：

参考DW层表名称规范

1. 1. 1. 1. 1. DW/DM维度表表名

前缀为D_ 。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：D_ACCOUNT、D_PUB_DATE。表名称不能用双引号包含，表名长度不超过30个字符。

1. 数据表名规则如下：
   1. 日期维度      D_PUB_DATE
   2. 城市           D_CITY

 

1. 1. 1. 1. 1. 元数据表名

前缀为M_应用名（缩写）_功能描述 。数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：M_ETL_TASK。表名称不能用双引号包含，表名长度不超过30个字符。

1. 应用名规则如下：
   1. ETL        ETL
   2. 报表        RPT
   3. OLAP分析    OLP
   4. 源系统      SRC
   5. 数据库      DB
   6. 软硬件      SHW
   7. ……
   8. 如有新应用，按规则添加

 

1. 1. 1. 1. 表分区名

前缀为p 。分区名必须有特定含义的单词或字串。

例如 ：tbl_pstn_detail 的分区p2004100101表示该分区存储 2004100101时段的数据。

1. 1. 1. 1. 字段名

字段名称必须用字母开头，采用有特征含义的单词或缩写，不能用双引号包含。

 

1. 1. 1. 1. 字段排列

每个表中的字段排列也应该遵从相应的规则进行摆放：

• 同类属性尽量靠拢摆放

例如：“协议”实体中有一组“日期”属性，包括“开户日期”、“销户日期”、“签署日期”、“起息日期”、“到期日期”等，可以排列在一起、

• 相关属性尽量靠拢摆放

例如：“币种”、“金额”常常一起使用，应排列在一起；

• 重要的和常用的属性靠前
• 和源系统非常接近的表（特别是一对一的情况），和源系统的属性顺序一致

 

1. 1. 1. 1. 主键名

前缀为PK_。主键名称应是 前缀+表名+构成的字段名。如果复合主键的构成字段较多，则只包含第一个字段。表名可以去掉前缀。

1. 1. 1. 1. 外键名

前缀为FK_。外键名称应是 前缀+ 外键表名 + 主键表名 + 外键表构成的字段名。表名可以去掉前缀。

1. 1. 1. 索引
         1. 普通索引

前缀为IDX_。索引名称应是 前缀+表名+构成的字段名。如果复合索引的构成字段较多，则只包含第一个字段，并添加序号。表名可以[s3] 去掉前缀。

1. 1. 1. 1. 主键索引

前缀为IDX_PK_。索引名称应是 前缀+表名+构成的主键字段名，在创建表时候用using index指定主键索引属性。

1. 1. 1. 1. 唯一索引

前缀为IDX_UK_。索引名称应是 前缀+表名+构成的字段名。

1. 1. 1. 1. 外键索引

前缀为IDX_FK_。索引名称应是 前缀+表名+构成的外键字段名。

1. 1. 1. 1. 函数索引

前缀为IDX_func_。索引名称应是 前缀+表名+构成的特征表达字符。

1. 1. 1. 1. 簇索引

前缀为IDX_clu_。索引名称应是 前缀+表名+构成的簇字段。

1. 1. 1. 视图

前缀为V_。按业务操作命名视图。

1. 1. 1. 物化视图

前缀为MV_。按业务操作命名实体化视图。

1. 1. 1. 存储过程

前缀为SP_ 。按业务操作命名存储过程。

1. 1. 1. 触发器

前缀为Trig_ 。触发器名应是 前缀 + 表[s4] 名 + 触发器名。

1. 1. 1. 函数

前缀为Func_ 。按业务操作命名函数。

1. 1. 1. 数据包

前缀为Pkg_ 。按业务操作集合命名数据包。

1. 1. 1. 序列

前缀为Seq_ 。按业务属性命名。

1. 1. 1. 普通变量

前缀为Var_ 。 存放字符、数字、日期型变量[s5] 。

1. 1. 1. 游标变量

前缀为Cur_ 。存放游标记录集。

1. 1. 1. 记录型变量

前缀为Rec_ 。 存放记录型数据。

1. 1. 1. 表类型变量

前缀为Tab_ 。 存放表类型数据。

1. 1. 1. 数据库链接

前缀为dbl_ 。 表示分布式数据库外部链接关系。

1. 1. 命名
      1. 语言

命名应该使用英文单词，避免使用拼音，特别不应该使用拼音简写。命名不允许使用中文或者特殊字符。

英文单词使用用对象本身意义相对或相近的单词。选择最简单或最通用的单词。不能使用毫不相干的单词来命名。

当一个单词不能表达对象含义时，用词组组合，如果组合太长时，采用用简或缩写，缩写要基本能表达原单词的意义。

当出现对象名重名时，是不同类型对象时，加类型前缀或后缀以示区别。

1. 1. 1. 大小写

名称一律小写，以方便不同数据库移植，以及避免程序调用问题。

1. 1. 1. 单词分隔

命名的各单词之间可以使用下划线进行分隔。

1. 1. 1. 保留字

命名不允许使用SQL保留字。

1. 1. 1. 命名长度

表名、字段名、视图名长度应限制在20个字符内(含前缀)。

1. 1. 1. 字段名称

同一个字段名在一个数据库中只能代表一个意思。比如telephone在一个表中代表“电话号码”的意思，在另外一个表中就不能代表“手机号码”的意思。

不同的表用于相同内容的字段应该采用同样的名称，字段类型定义。

标签： shw铝电解电容器