数据仓库模型的设计.doc
2.5数据仓库模型的设计
数据仓库模型的设计大体上可以分为以下三个层面的设计151:
.概念模型设计;
.逻辑模型设计;
.物理模型设计;
下面就从这三个层面分别介绍数据仓库模型的设计。
2.5.1概念模型设计
进行概念模型设计所要完成的工作是:
<1>界定系统边界
<2>确定主要的主题域及其内容
概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。
概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。
1.界定系统的边界
数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前:
. 要做的决策类型有哪些?
. 决策者感兴趣的是什么问题?
. 这些问题需要什么样的信息?
. 要得到这些信息需要包含原有数据库系统的哪些部分的数据?
这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。
2，确定主要的主题域
在这一步中，要确定系统所包含的主题域，然后对每个主题域的内容进行较明确数据仓库建模技术在电信行业中的应用的描述，描述的内容包括:
. 主题域的公共码键;
. 主题域之间的联系:
. 充分代表主题的属性组。
2.5.2逻辑模型设计
逻辑建模是数据仓库实施中的重要一环，因为它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用。在这一步里进行的工作主要有:
. 分析主题域，确定当前要装载的主题;
. 确定粒度层次划分;
. 确定数据分割策略;
. 关系模式定义;
. 记录系统定义
逻辑模型设计的成果是，对每个当前要装载的主题的逻辑实现进行定义，并将相关内容记录在数据仓库的元数据中，包括:
. 适当的粒度划分;
. 合理的数据分割策略;
. 适当的表划分;
. 定义合适的数据来源等。
I.分析主题域
在概念模型设计中，我们确定了几个基本的主题域，但是，数据仓库的设计方法是一个逐步求精的过程，在进行设计时，一般是一次一个主题或一次若干个主题地逐步完成的。所以，我们必须对概念模型设计步骤中确定的几个基本主题域进行分析，一并选择首先要实施的主题域。选择第一个主题域所要考虑的是它要足够大，以便使得该主题域能建设成为一个可应用的系统;它还要足够小，以便于开发和较快地实施。如果所选择的主题域很大并且很复杂，我们甚至可以针对它的一个有意义的子集来进行开发。在每一次的反馈过程中，都要进行主题域的分析。
z.粒度层次划分
数据仓库逻辑设计中要解决的一个重要问题是决定数据仓库的粒度划分层次，粒度层次划分适当与否直接影响到数据仓库中的数据量和所适合的查询类型。确定数据仓库的粒度划分，可以使用在粒度划分一节中介绍的方法，通过估算数据行数和所需的DASD数，来确定是采用单一粒度还是多重粒度，以及粒度划分的层次。
3.确定数据分割策略
在这一步里，要选择适当的数据分割的标准，一般要考虑以下几方面因素:数据量〔而非记录行数)、数据分析处理的实际情况、简单易行以及粒度划分策略等。数据量的大小是决定是否进行数据分割和如何分割的主要因素;数据分析处理的要求是选择数据分割标准的一个主要依据，因为数据分割是跟数据分析处理的对象紧密联系的;我们还要考虑到所选择的数据分割标准应是自然的、易于实施的:同时也要考虑数据分割的标准与粒度划分层次是适应的。
4.关系模式定义
数据仓库的每个主题都是由多个表来实现的，这些表之间依靠主题的公共码键联系在一起，形成一个完整的主题。在概念模型设计时，我们就确定了数据仓库的基本主题，并对每个主题的公共码键、基本内容等做了描述在这一步里，我们将要对选定_的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模式。
用关系型数据库来实现数据仓库信息模型时，目前较常用的两种建模方法是所谓的第三范式(3NF,即Third Normal Form)和星型模式Star-Schem司，我们将重点讨论两种方法的特点和它们在数据仓库系统中的适用场合。
4.1什么是第三范式
范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解，这个过程也称为规范化(Normalize)。在数据仓库的模型设计中目前一般采用第三范式，它有非常严格的数学定义。如果从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件:
1.每个属性的值唯一，不具有多义性;
2.每个非主属性必须完全依赖于整个主键，而非主键的一部分;
3.每个非主属性不能依赖于其他关系中的属性，团为这样的话，这种属性应该归到其他关系中去。
我们可以看到，第三范式的定义基本上是围绕主键与非主属性之间的关系而作出的。如果只满足第一个条件，则称为第一范式;如果满足前面两个条件，则称为第二范式，依此类推。因此，各级范式是向下兼容的。
4.2什么是星型模式
星型模式是一种多维的数据关系，它由一个事实表(Fact Table)和
一组维表(Dimension Table)组成。每个维表都有一个维作为主键，所有这些维则组合成事实表的主键，换言之，事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实(Fact)，它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。
与星型模式类似还有一种业界提的比较多的设计方式是雪花模式，它也是一种在关系数据库中实现多维数据关系的方式，与星型模式相区别的是它的维表结构与星型模式不同。星型模式中同一维度的不同层次位于一张维表中，维表由唯一主键和事实表关连;雪花模式中同一维度中的不同层次位于不同的层次表中，最低层次表与事实表关连，各个层次再分别和比自己高一级的层次表关连。
因为星型模式查询效率要比雪花模式高的多，所以比较多的是采用星型模式设计多维数据关系。
4. 3第三范式和星型模式在数据仓库中的应用
大多数人在设计中央数据仓库的逻辑模型时，都按照第三范式来设计;而在进行物理实施时，则由于数据库引擎的限制，不得不对逻辑模型进行不规范处理(De-Normalize)，以提高系统的响应速度，这当然是以增加系统的复杂度、维护工作量、磁盘使用比率(指原始数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。根据数据仓库的测试标准TPC-D规范，在数据仓库系统中，对数据库引擎最大的挑战主要是这样几种操作:多表连接、表的累计、数据排序、大量数据的扫描。下面列出了一些DBMS在实际系统中针对这些困难所采用的折衷处理办法:
1、如何避免多表连接:在设计模型时对表进行合并，即所谓的预连接(Pre-Join)。当数据规模小时，也可以采用星型模式，这样能提高系统速度，但增加了数据冗余量。
2、如何避免表的累计:在模型中增加有关小计数据(Summarized Data)的项。这样也增加了数据冗余，而且如果某项问题不在预建的累
计项内，需临时调整。
3、如何避免数据排序:对数据事先排序。但随着数据仓库系统的运行，不断有新的数据加入，数据库管理员的工作将大大增加。大量的时间将用于对系统的整理，系统的可用性随之降低。
4、如何避免大表扫描:通过使用大量的索引，可以避免对大量数据进行扫描。但这也将增加系统的复杂程度，降低系统进行动态查询的能力。
这些措施大都属于不规范处理。根据上面的讨论，当把规范的系统逻辑模型进行物理实施时，由于数据库引擎的限制，常常需要进行不规范处理。举例来说，当系统数据量很小，比如只有几个GB时，进行多表连接之类复杂查询的响应时间是可以忍受的。但是设想一下加果数据量扩展到很大，到几百GB，甚至上TB,一个表中的记录往往有几百万、几千万，甚至更多，这时进行多表连接这样的复杂查询，响应时间长得不可忍受。这时就有必要把几个表合并，尽量减少表的连接操作。当然，不规范处理的程度取决于数据库引擎的并行处理能力。数据仓库建设者在选择数据库引擎时，除了参考一些相关的基准测试结果外，最好是能根据自己的实际情况设计测试方案，从几个数据库系统中选择最适合自己企业决策要求的一种。
不规范化处理虽然是提高系统性能的一种有效手段，但是由于中央数据仓库的数据模型反映了整个企业的业务运行规律，在这里进行不规范处理容易影响整个系统，不利于今后的扩展。而且不规范处理产生的数据冗余将使整个系统的数据量迅速增加，这将增加DBA的工作量和系统投资。因此，当系统性能下降而进行不规范处理时，比较好的办法是选择问题较集中的部门数据集市实施这种措施。这样既能有效地改善系统
性能汉不至于影响整个系统。在国外一些成功的大型企业级数据仓
库案例中，基本上都是采用这种方法。
那么，在中央数据仓库中是否可以采用星型模式来进行模型设计呢?我们知道，星型模式中有一个事实表和一组维表，我们可以把事实看成是各个维交叉点上的值。例如，一个汽车厂在研究其销售情况时可以考察汽车的型号、颜色、代理商等多种因素，这些因素就是维，而销售量就是事实。这种多维模型能迅速给出基于各个维的报表，这些维必须事先确定。
星型模式之所以速度快，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。在上面的例子中，就是按照汽车的型号、颜色、代理商进行预先的销售量统计。因此，在星型模式设计的数据仓库中，作报表的速度虽然很快，但由于存在大量的预处理，其建模过程相对来说就比较慢。当业务问题发生变化，原来的维不能满足要求时，需要增加新的维。由于事实表的主键由所有维表的主键组成，这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。综合这些讨论，不难得出结论，星型模式比较适合于预先定义好的问题加需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此，星型模式在一些要求大量报表的部门数据集市中有较多的应用。
4. 4两种模式的比较
上面讨论了数据仓库逻辑模型设计中常用的两种方法.在数据仓库的应用环境中，主要有两种负载:一种是回答重复性的问题;另一种是回答交互性的问题。动态查询具有较明显的交互性特征，即在一个问题答案的基础上进行进一步的探索，这种交互过程常称为数据挖掘(Data Mining)或者知识探索(Knowledge Discovery)。对于以第一种负载为主的部门数据集市，当数据量不大、报表较固定时可以采用星型模式;对于中央数据仓库，考虑到系统的可扩展能力、投资成本和易于管理等
多种因素，最好采用第三范式。或者说对于数据仓库中当前详细级别的数据和轻度综合的数据可以采用第三范式的方式设计，对于高度综合的数据可以采用星型模式设计。
2.5.3物理模型设计
这一步所做的工作是确定数据的存储结构，确定索引策略，确定数据存放位置，确定存储分配。
确定数据仓库实现的物理模型，要求设计人员必须做到以下几方面: 要全面了解所选用的数据库管理系统，特别是存储结构和存取方法。
了解数据环境、数据的使用频度、使用方式、数据规模以及响应时间要求等，这些是对时间和空间效率进行平衡和优化的重要依据。
. 了解外部存储设备的特性，如分块原则，块大小的规定，设备的I/o特性等。
1.确定数据的存储结构
一个数据库管理系统往往都提供多种存储结构供设计人员选用，不同的存储结构有不同的实现方式，各有各的适用范围和优缺点，设计人员在选择合适的存储结构时应该权衡三个方面的主要因素:存取时间、存储空间利用率和维护代价。
2.确定索引策略
数据仓库的数据量很大，因而需要对数据的存取路径进行仔细的设计和选择。由于数据仓库的数据都是不常更新的，因而可以设计多种多样的索引结构来提高数据存取效率。
在数据仓库中，设计人员可以考虑对各个数据存储建立专用的、复杂的索引，以获得最高的存取效率，因为在数据仓库中的数据是不常更新的，也就是说每个数据存储是稳定的，因而虽然建立专用的、复杂的索引有一定的代价，但一旦建立就几乎不需维护索引的代价。
3.确定数据存放位置
我们说过，同一个主题的数据并不要求存放在相同的介质上。在物理设计时，我们常常要按数据的重要程度、使用频率以及对响应时间的要求进行分类，并将不同类的数据分别存储在不同的存储设备中。重要程度高、经常存取并对响应时间要求高的数据就存放在高速存储设备上，如硬盘;存取频率低或对存取响应时间要求低的数据则可以放在低速存储设备上，如磁盘或磁带。
数据存放位置的确定还要考虑到其它一些方法，如:决定是否进行合并表;是否对一些经常性的应用建立数据序列;对常用的、不常修改的表或属性是否冗余存储。如果采用了这些技术，就要记入元数据。
4.确定存储分配
许多数据库管理系统提供了一些存储分配的参数供设计者进行物理优化处理，如:块的尺寸、缓冲区的大小和个数等等，它们都要在物理设计时确定。这同创建数据库系统时的考虑是一样的。
数据仓库模型的设计
2.5数据仓库模型的设计 数据仓库模型的设计大体上可以分为以下三个层面的设计151: .概念模型设计; .逻辑模型设计; .物理模型设计; 下面就从这三个层面分别介绍数据仓库模型的设计。 2.5.1概念模型设计 进行概念模型设计所要完成的工作是: <1>界定系统边界 <2>确定主要的主题域及其内容 概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。 概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。 1.界定系统的边界 数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前: . 要做的决策类型有哪些? . 决策者感兴趣的是什么问题? . 这些问题需要什么样的信息? . 要得到这些信息需要包含原有数据库系统的哪些部分的数据? 这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。 2，确定主要的主题域 在这一步中，要确定系统所包含的主题域，然后对每个主题域的内
数据仓库物理模型设计
数据仓库物理模型设计 数据仓库的物理模型就是数据仓库逻辑模型在物理系统中的实现模式。其中包括了逻辑模型中各种实体表的具体化，例如表的数据结构类型、索引策略、数据存放位置和数据存储分配等。在进行物理模型的设计实现时，所考虑的因素有：I/O存取时间、空间利用率及维护的代价。 为确定数据仓库的物理模型，设计人员必须做这样几方面工作：首先要全面了解所选用的数据库管理系统，特别是存储结构和存取方法；其次了解数据环境、数据的使用频率、使用方式、数据规模及响应时间要求等，这些都是对时间和空间效率进行平衡和优化的重要依据；最后还需要了解外部存储设备的特征。只有这样才能在数据的存储需求与外部存储设备条件两者之间获得平衡。 1 设计存储结构 在物理设计时，常常要按数据的重要性、使用频率及对反应时间的要求进行分类，并将不同类型的数据分别存储在不同的存储设备中。重要性高、经常存取并对反应时间要求高的数据存放在高速存储设备上；存取频率低或对存取响应时间要求低的数据则可以存放在低速存储设备上。另外，在设计时还要考虑数据在特定存储介质上的布局。在设计数据的布局时要注意遵循以下原则。 l 不要把经常需要连接的几张表放在同一存储设备上，这样可以利用存储设备的并行操作功能加快数据查询的速度。 l 如果几台服务器之间的连接会造成严重的网络业务量的问题，则要考虑服务器复制表格，因为不同服务器之间的数据连接会给网络带来沉重的数据传输负担。 l 考虑把整个企业共享的细节数据放在主机或其他集中式服务器上，提高这些共享数据的使用速度。 l 不要把表格和它们的索引放在同一设备上。一般可以将索引存放在高速存储设备上，而表格则存放在一般存储设备上，以加快数据的查询速度。 在对服务器进行处理时往往要进行大量的等待磁盘数据的工作，此时，可以在系统中使用RAID（Redundant Array of Inexpensive Disk，廉价冗余磁盘阵列）。 2 设计索引策略 数据仓库的数据量很大，因而需要对数据的存取路径进行仔细地设计和选择。由于数据仓库的数据一般很少更新，所以可以设计索引结构来提高数据存取效率。在数据仓库中，设计人员可以考虑对各个数据存储建立专用的索引和复杂的索引，以获取较高的存取效率，虽然建立它们需要付出一定的代价，但建立后一般不需要过多的维护。 数据仓库中的表通常要比联机事务处理系统（OLTP）中的表建立更多的索引，表中应用的最大索引数应与表格的规模成正比。数据仓库是个只读的环境，建立索引可以取得灵活性，对性能极为有利。但是表若有很多索引，那么数据加载时间就会延长，因此索引的建立需要进行综合的考虑。在建立索引时，可以按照索引使用的频率由高到低逐步添加，直到某一索引加入后，使数据加载或重组表的时间过长时，就结束索引的添加。 最初，一般都是按主关键字和大多数外部关键字建立索引，通常不要添加很多的其他索引。在表建立大量的索引后，对表进行分析等具体使用时，可能需要许多索引，这会导致表的维护时间也随之增加。如果从主关键字和外部关键字着手建立索引，并按照需要添加其他索引，就会避免首先建立大量的索引带来的后果。如果表格过大，而且需要另外增加索引，那么可以将表进行分割处理。如果一个表中所有用到的列都在索引文件中，就不必访问事实表，只要访问索引就可以达到访问数据的目的，以此来减少I/O操作。如果表太大，并且经常要对它进行长时间的扫描，那么就要考虑添加一张概括表以减少数据的扫描任务。 3 设计存储策略
现代电信企业数据仓库系统建设
现代电信企业数据仓库系统建设 电信企业数据仓库建设的需求 电信行业目前主要的数据来自于计费系统和网管数据。电信系统经过多年的运行，已经存储了大量的历史数据。这些数据中蕴涵着丰富的信息，从中可以了解企业在电信市场经营过程中所处的态势、竞争对手的经营形势、客户群的分布状况、消费特征、企业经营发展的趋势等，对其进行分析处理可以得到很多令人欣喜的结论。强大的数据处理能力，加上丰富的企业数据，可以有力地促进企业经营和竞争。 目前，企业信息化建设呈现出“数据集中化、业务综合化、管理扁平化、决策科学化”的发展趋势。面对激烈的市场竞争，许多大型企业纷纷实施“以客户为中心，以服务求发展”的经营策略。如何优化客户关系，增强企业的竞争优势已经成为现代企业关注的焦点。现有的应用系统往往以“产品”为中心，以“单据（票证）”处理为基础，是面向联机事务处理（Online Transaction Processing，简称OLTP）的系统，而以客户为中心的经营管理模式要求对现有业务系统的数据进行有效的集成并加以重组，建立面向联机分析处理（Online Analysis Processing，简称OLAP）的系统。通过分析客户的行为，掌握不同类型客户的特征，进而为客户提供更加优质的服务，尤其是个性化的服务，同时全面掌握并理解、分析企业业务的发生情况，充分发挥企业现已积累的数据，为各级管理人员提供科学化管理和决策的有力依据，以提高企业的经营业绩，保证利润的持续增长。 面对纷繁复杂的市场竞争，众多企业立足于多年积累的数据和自身的核心业务，提出了建立企业级数据仓库的规划和实施方案，为企业的进一步发展奠定基础。 企业数据仓库系统的总体结构 一个典型的企业数据仓库系统通常包含数据源、数据存储与管理、OLAP服务器以及前端工具与应用四个部分 从系统结构看，电信行业数据仓库解决方案系统一般包括应用系统部分、中央数据仓库系统部分，数据源系统部分三大部分。如图所示：
数据仓库建模
背景介绍 熟悉社保行业的读者可以知道，目前我们国家的社保主要分为养老，失业，工伤，生育，医疗保险和劳动力市场这6 大块主要业务领域。在这6 大业务领域中，目前的状况养老和事业的系统已经基本完善，已经有一部分数据开始联网检测。而，对于工伤，生育，医疗和劳动力市场这一块业务，有些地方发展的比较成熟，而有些地方还不够成熟。 1.业务建模阶段 基于以上的背景介绍，我们在业务建模阶段，就很容易来划分相应的业务。因此，在业务建模阶段，我们基本上确定我们本次数据仓库建设的目标，建设的方法，以及长远规划等。如下图： 图8. 业务建模阶段 在这里，我们将整个业务很清楚地划分成了几个大的业务主线，例如：养老，失业，工伤，生育，医疗，劳动力等着几个大的部分，然后我们可以根据这些大的模块，在每个业务主线内，考虑具体的业务主线内需要分析的业务主题。 因此，业务建模阶段其实是一次和业务人员梳理业务的过程，在这个过程中，不仅能帮助我们技术人员更好的理解业务，另一方面，也能够发现业务流程中的一些不合理的环节，加以改善和改进。 同时，业务建模阶段的另一个重要工作就是确定我们数据建模的范围，例如：在某些数据准备不够充分的业务模块内，我们可以考虑先不建设相应的数据模型。等到条件充分成熟的情况下，我们可以再来考虑数据建模的问题。 2.领域概念建模阶段领域概念建模阶段是数据仓库数据建模的一个重要阶段，由于我们在业务建模阶段已经完全理清相应的业务范围和流程，因此，我们在这个领域概念建模阶段的最主要的工作就是进行概念的抽象，整个领域概念建模的工作层次如下图所示：
图9. 领域概念建模阶段 从上图我们可以清楚地看到，领域概念建模就是运用了实体建模法，从纷繁的业务表象背后通过实体建模法，抽象出实体，事件，说明等抽象的实体，从而找出业务表象后抽象实体间的相互的关联性，保证了我们数据仓库数据按照数据模型所能达到的一致性和关联性。 从图上看，我们可以把整个抽象过程分为四个层次，分别为： ?抽象方法层，整个数据模型的核心方法，领域概念建模的实体的划分通过这种抽象方法来实现。 ?领域概念层，这是我们整个数据模型的核心部分，因为不同程度的抽象方法，决定了我们领域概念的不同。例如：在这里，我们可以使用“参与方”这个概念，同时，你也可以把他分成三个概念：“个人”，“公司”，和“经办机构”这三个概念。而我们在构建自己的模型的时候，可以参考业务的状况以及我们自己模型的需要，选择抽象程度高的概念或者是抽象程度低的概念。相对来说，抽象程度高的概念，理解起来较为复杂，需要专业的建模专家才能理解，而抽象程度低的概念，较适合于一般业务人员的理解，使用起来比较方便。笔者在这里建议读者可以选用抽象概念较低的实体，以方便业务人员和技术人员之间的交流和沟通。 ?具体业务层，主要是解决具体的业务问题，从这张图我们可以看出，具体的业务层，其实只是领域概念模型中实体之间的一些不同组合而已。因此，完整的数据仓库的数据模型应该能够相应灵活多变的前端业务的需求，而其本身的模型架构具有很强的灵活性。这也是数据仓库模型所具备的功能之一。 ?业务主线层，这个层次主要划分大的业务领域，一般在业务建模阶段即已经完成这方面的划分。 我们一般通过这种大的业务主线来划分整个业务模型大的框架。 通过领域概念建模，数据仓库的模型已经被抽象成一个个的实体，模型的框架已经搭建完毕，下面的工作就是给这些框架注入有效的肌体。
数据仓库设计文档模板
数据仓库设计与实现 学号 128302106 姓名江晨婷 成绩 教师张丹平 二O一五年四月
数据仓库建设方案设计与实现 摘要：本文以博士学位调查为基础，创建方案，设计与实现数据仓库，通过对当前各种主流数据仓库软件在性能、价格等方面的对比，充分考虑统计业务、单位数量等实际情况，本系统决定采用SQL Server 2005数据仓库软件来构建综合信息分析系统的数据仓库。 关键词：数据仓库；联机分析；数据挖掘；博士学位 一、概述 数据仓库的设计一般从操作型数据开始，通常需要经过以下几个处理过程；数据仓库设计——数据抽取——数据管理。 1.数据仓库设计 根据决策主题设计数据仓库结构，一般采用星型和雪花模型设计其数据模型，在设计过程中应保证数据仓库的规范化和体系各元素的必要联系。 2.数据抽取 根据元数据库中的主题表定义、数据源定义、数据抽取规则定义对异地异构数据源进行清理、转换、对数据进行重新组织和加工，装载到数据仓库的目标库中。 3.数据管理 数据管理分为目标数据维护和元数据维护两方面。目标数据维护是根据元数据为所定义的更新频率、更新数据项等更新计划任务来刷新数据仓库，以反映数据源的变化，且对时间相关性进行处理。元数据是数据仓库的组成部分，元数据的质量决定整个数据仓库的质量。当数据源的运行环境、结构及目标数据的维护计划发生变化时，需要修改元数据。 二、博士学位授予信息年度数据统计分析 1.按主管部门统计 从主管部门的角度，分析在一个时间段（年）内，各主管部门所授予的博士学位信息统计。可回答如“2008，由某部门主管的，博士学位授予一共有多少，其平均学习年限是多少，脱产学习的有多少人?”等问题。具有表格和图形两种方式来展示分析结果。典型报表格式如表1所示
数据仓库的数据模型
业务驱动 任何需求均来源于业务,业务决定了需求,需求分析的正确与否是关系到项目成败的关键所在,从任何角度都可以说项目是由业务驱动的所以数据仓库项目也是由业务所驱动的. 但是数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求,分析,设计,测试等通常的软件声明周期之外;他还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的物理模型异常重要,这也是关系到数据仓库项目成败的关键. 数据仓库的结构总的来说是采用了三级数据模型的方式: 概念模型: 也就是业务模型,由企业决策者,商务领域知识专家和IT专家共同企业级地跨领域业务系统需求分析的结果. 逻辑模型：用来构建数据仓库的数据库逻辑模型。根据分析系统的实际需求决策构建数据库逻辑关系模型,定义数据库物体结构及其关系。他关联着数据仓库的逻辑模型和物理模型这两头. 物理模型：构建数据仓库的物理分布模型,主要包含数据仓库的软硬件配置,资源情况以及数据仓库模式。 如上图所示,在数据仓库项目中,物理模型设计和业务模型设计象两个轮子一样有力的支撑着数据仓库的实施,两者并行不悖,缺一不可.实际上,我有意的扩大了物理模型和业务模型的内涵和外延.在这里物理模型不仅仅是数据的存储,而且也包含了数据仓库项目实施的方法论,资源,以及软硬件选型等等;而业务模型不仅仅是主题模型的确立,也包含了企业的发展战略,行业模本等等. 一个优秀的项目必定会兼顾业务需求和行业的标准两个方面,业务需求即包括用户提出的实际需求,也要客观分析它隐含的更深层次的需求,但是往往用户的需求是不明确的,需要加以提炼甚至在商务知识专家引导下加以引导升华,和用户一起进行需求分析工作;不能满足用户的需求,项目也就失去原本的意义了. 物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基->层层建筑->封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免的要考虑到数据库的物理设计. 接下来,将详细阐述数据仓库概念模型(业务模型),逻辑模型,物理模型的意义. 概念模型设计 进行概念模型设计所要完成的工作是: 界定系统边界 确定主要的主题域及其内容
20120405-032 医院数据仓库数据模型设计
医院数据仓库数据模型设计 汪涛① ①安徽省中医院，230009，安徽省合肥市梅山路117号 摘要目的：数据模型设计是数据仓库建设的核心，本文提出一种医院数据仓库数据模型的设计方法。方法：以某一三甲医院的HIS数据为背景，采用数据驱动的手段，结合医院的需求，提出了医院数据仓库的三层数据模型，概念模型、逻辑模型、物理模型，并完整地给出了每个模型的具体的设计和主要内容。结果：设计并实现了医院数据仓库的的数据模型，并结合医院具体的数据给出了相应的实例。结论：此医院数据仓库的三层数据模型易于理解和实现，为医院数据仓库设计最终完成提供了基础。 关键词数据模型概念模型逻辑模型数据仓库 1 引言 随着医疗市场的竞争越来越激烈,为了提高医院的竞争力,各家医院对信息化建设投入不断加大[1]。医院信息系统的使用提高基本业务处理的效率，提升了管理的手段。但随着时间的推移，现有系统积累了海量数据，如何对其中的各类业务数据加以整合和利用，从中挖掘出隐藏在背后的有价值、可以利用的潜在信息，对以后医院科学的业务分析和管理决策十分重要的意义。数据仓库的出现正好可以解决以上问题，如“军字一号”医院信息系统上建立数据仓库，整合和分析历史数据[2]，为医院决策提供数据。而数据仓库系统如何对海量数据进行有效组织和管理，并使之支持千变万化的管理业务分析与决策，主要依赖于数据仓库系统逻辑数据模型(Logical Data Model，简称LDM )的设计[3]。一个好的逻辑数据模型能够最大的保证灵活性和可扩展性，以满足数据源的变化和应用需求的拓展。因此建设好LDM 是医院数据仓库的关键，本就此进行探讨。 2 数据仓库数据模型的概述 数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合，用来支持管理人员的决策,其与操作型数据库系统(OLTP)的建模方法是有不同的[4]。操作性数据库系统是为具体的业务活动，是在传统开发生命周期(SDLC)下进行的，但不适用与决策支持系统领域。在用户需求尚不明确的情况下，数据仓库的建模是从整合现有操作型数据开始的，分析业务系统的数据组织、关系模型，确定数据范围、主题，依次设计系统的概念模型、逻辑模型和物理模型；而在实际的项目实施当中，如在医院的数据仓库建设中，系统的初步需求还是需要首先了解和分析的。这为数据仓库建设提供了原始范围，以及最终为用户所接受提供保证。以下，我在设计医院数据仓库模型是从系统需求分析和HIS的数据分析开始的，采用三层模型设计的。 3 设计医院的数据仓库的数据模型 3.1 概念模型的设计 3.1.1 系统边界的确立，包括需求分析、数据来源等现有的医院数据是面向具体业务的，
电信企业数据仓库的设计和应用.doc资料
电信企业数据仓库的设计和应用 漆晨曦 编者按: 竞争的加剧使得营销能力成为决定电信企业竞争力的最重要因素，也使得数据仓库作为营销决策分析支撑的手段日益盛行，如何设计数据仓库、数据仓库上可以展开哪些应用、如何展开等成为电信企业迫切需要解决的问题。本期的这一组文章将围绕数据仓库在电信企业的应用展开深入的阐述，同时也是对上述问题的解答。 数据仓库技术在电信企业的盛行是电信行业竞争的必然结果。竞争使得企业的营销能力成为决定企业竞争力的最重要因素，而营销能力则建立在对客户的购买行为、消费行为、服务要求、营销参与等方面信息的收集、整合、存储的数据基础和分析基础上。为了收集和整合客户购买、消费、服务、营销等方面的海量数据，数据仓库必然地进入电信企业的采购单，比如某电信企业有千万级的电信客户，每个客户每月几百次的本地电话和上百分钟的长途电话，上TB级的数据使得原来的数据存储、分析方法和处理能力力不从心，“仓库”的概念随之被引进数据存储过程中。简单地说，数据仓库就是为了保证数据查询和分析的效率，按照主题将所有的数据分门别类进行存储，需要的时候，再按主题提取数据并进行了进一步的分析处理。 构建电信企业数据仓库 目前，电信企业数据仓库的应用一般集中在经营分析和营销决策支撑两方面。一方面数据仓库从营业、计费账务、渠道、客服中心等生产、管理系统获取市场经营的所有相关信息，经过整合、清洗等环节，按主题存储，形成企业内部有关市场经营的统一数据平台，通过查询、报表、多维分析等方式提供给数据分析用户和营销决策人员; 而另一方面，数据仓库根据客户交互系统的需求，经过分析或挖掘，将客户异常消费、流失客户预警、营销活动目标客户等信息反馈到各客户接触系统，供营销经理、营业员、客服人员对相应客户提供针对性营销和服务(数据仓库与电信企业其他生产管理系统之间的关系见图1)。
电信数据仓库设计的六个关键环节
电信数据仓库设计的六个关键环节 编者按 数据仓库技术经过了十几年的发展，在理论与工程实践上都取得了显著的成果。国际上许多重要的学术会议，如超大型数据库国际会议（VLDB）、数据工程国际会议（Data Engineering）等，都有大量专门研究数据仓库（Data Warehousing）、联机分析处理（On-Line Analytical Processing）、数据挖掘（Data Mining）的论文，各大数据库厂商纷纷推出相应产品支持数据仓库，比如NCR、SAS、Oracle、IBM、Informix、Sybase等都提出了相应的数据仓库解决方案。 随着信息技术的飞速发展，企业内部产生了越来越多的数据，但这些数据并没有产生应有的信息，困此，我们常常可以看到企业“数据爆炸、知识贫乏”的窘迫局面。如何有效地整合与充分利用信息资源，成为企业提高核心竞争力的关键。此外，数据仓库的设计与实现，在不同的行业存在着极大的差别，企业在设计过程中应该注意哪些细节问题？ 本期“方案评析”专题中所选的几篇文章，以电信、银行、医疗行业为实例，在实际操作的基础上，分析了企业经营分析与决策支持系统的建设应用，分析了建设数据仓库及基于数据仓库的商业智能系统应具备的基本条件，从确定主题、数据准备、建立模型、评估和解释模型、运用和巩固模型等方面，对数据仓库的设计方法，以及解决关键环节问题的技巧进行了深入剖析，具有较高的实用价值。 大型企业数据仓库系统的建设是一项复杂的系统工程，在设计中会遇到各种各样的技术问题。本文以电信行业数据创库设计为例，提供数据仓库设计过程中的六个关键环节，从技术上给读者提供参考。 环节一：异种数据源集成 企业在经营分析与决策支持系统的建设时，必须将遗留系统（Legacy System）进行高效全面的集成。由于遗留系统是在企业发展的不同时期建设的，往往缺乏全局规划，所以拥有不同的操作系统、不同的数据库、不同的网络通信机制等，形成了所谓的“信息孤岛”。 系统中采用异种数据源企业应用集成接口，来实现对异种数据源的透明访问，包括数据源元数据访问及业务操作数据访问。数据源分为在线数据源和离线数据源，在线数据源是指允许在线抽取的业务数据源，如营业数据; 离线数据源是指不允许直接在线抽取的数据源，如计费样单数据就是采用以脱机文件数据格式及FTP方式集成进系统。 对数据源实现元数据级的管理，数据源的连接类型（ODBC、OLEDB、JDBC、Native）、连接字符串，以及数据结构信息都以元数据的形式存储于元数据库中，通过控制台对其进行业务语义定义，使用户对整个企业的信息系统有了全面的掌握。 环节二：ODS层的设计 操作数据存储ODS（Operation Data Storage）是一个集成了来自不同数据库数据的环境。其目的是为终端用户提供一致的企业数据集成视图。它可以帮助用户轻松应对跨多个商业功能的操作挑战，是面向主题的、集成的、近实时的数据存储。
Oracle数据仓库设计指南
Oracle数据仓库设计指南 在一般的数据仓库应用系统中，根据系统体系结构的不同，数据仓库设计的内容和范围不尽相同，并且设计方法也不尽相同，下面的两幅图示分别表示带有ODS的数据仓库应用系统体系结构和不带ODS的数据仓库应用系统体系结构。本文将说明两个体系结构上的差异以及这种差异造成的设计方法的不同，并且重点介绍带有ODS的体系结构中数据仓库的设计方法。 在数据仓库的设计指导思想中，数据仓库的概念定义是非常重要的，数据仓库概念规定了数据仓库所具有的几个基本特性，这些特性也正是对数据仓库设计结果进行检验的重要依据。 根据Bill.Inmon的定义，“数据仓库是面向主题的、集成的、稳定的、随时间变化的，主要用于决策支持的数据库系统”。 ODS（Operational Data Store）是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。 一般在带有ODS的系统体系结构中，ODS都设计为如下几个作用： 1）在业务系统和数据仓库之间形成一个隔离层 一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。 2）转移一部分业务系统细节查询的功能 在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。 3）完成数据仓库中不能完成的一些功能 一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。
数据仓库与数据挖掘课程设计报告书
目录 1. 绪论 (2) 1.1项目背景 (2) 1.2 提出问题 (2) 2 数据库仓库与数据集的概念介绍 (2) 2.1数据仓库 (2) 2.2数据集 (3) 3 数据仓库 (3) 3.1 数据仓库的设计 (3) 3.1.1数据仓库的概念模型设计 (3) 3.1.2数据仓库的逻辑模型设计 (3) 3.2 数据仓库的建立 (4) 3.2.1数据仓库数据集 (4) 3.2.2建立维表 (4) 4.数据挖掘操作 (5) 4.1数据预处理 (5) 4.1.1描述性数据汇总 (5) 4.2决策树 (5) 5、实验心得 (13) 6、大总结 (14)
1. 绪论 1.1项目背景 在现在大数据时代，各行各业需要对商品及相关关节的数据进行收集处理，尤其零售行业，于企业对产品的市场需求进行科学合理的分析，从而预测出将来的市场，制定出高效的决策，给企业带来经济收益。 1.2 提出问题 对于超市的商品的购买时期和购买数量的如何决定，才可以使销售量最大，不积压商品，不缺货，对不同时期季节和不同人群制定不同方案，使企业收益最大，通过数据挖掘对数据进行决策树分析，关联分析，顺序分析与决策分析等可以制定出最佳方案。 2 数据库仓库与数据集的概念介绍 2.1数据仓库 数据仓库是为企业所有级别的决策制定过程提供支持的所有类型数据的战略集合。它是单个数据存储，出于分析性报告和决策支持的目的而创建。为企业提供需要业务智能来指导业务流程改进和监视时间、成本、质量和控制。 数据仓库是决策系统支持（dss）和联机分析应用数据源的结构化数据环境。
数据仓库研究和解决从数据库中获取信息的问题。数据仓库的特征在于面向主题、集成性、稳定性和时变性。 2.2数据集 数据集是指一种由数据所组成的集合。Data set（或dataset）是一个数据的集合，通常以表格形式出现。每一列代表一个特定变量。每一行都对应于某一成员的数据集的问题。它列出的价值观为每一个变量，如身高和体重的一个物体或价值的随机数。每个数值被称为数据资料。对应于行数，该数据集的数据可能包括一个或多个成员。 3 数据仓库 3.1 数据仓库的设计 3.1.1数据仓库的概念模型设计 概念模型的设计是整个概念模型开发过程的三阶段。设计阶段依据概念模型分析以及分析过程中收集的任何数据，完成星型模型和雪花型模型的设计。如果仅依赖ERD，那只能对商品、销售、客户主题设计成如图所示的概念模型。这种模型适合于传统的数据库设计，但不适合于数据仓库的设计。 3.1.2数据仓库的逻辑模型设计 逻辑建模是数据仓库实施中的重要一环，因为它能直接反映出各个业务的需求，同时对系统的物理实施有着重要的指导作用，它的作用在于可以通过实体和关系勾勒出企业的数据蓝图，数据仓库的逻辑模型设计任务主要有：分析主题域，确定要装载到数据仓库的主题、确认粒度层次划分、确认数据分割策略、关系模式的定义和记录系统定义、确认数据抽取模型等。逻辑模型最终设计成果包
数据仓库建设方案
数据仓库建设 商务智能（Business Intelligence）用于支持制定业务决策的技能、流程、技术、应用和实践。核心是通过数据提取、整理、分析，最终通过分析结果制定有关策略、规划，帮助企业了解新的趋势、抓住新的市场机会、发现潜在的威胁，达到资源的合理配置，节约成本提高效益。数据仓库是商业智能的基础，它为OLAP、数据挖掘提供分析和决策支持。 一、数据仓库概念 1.数据仓库定义 是一个面向主题的、集成的、相对稳定的、反映有有历史变化的数据集合，用于支持管理决策。具有以下特点： 详细交易及相关业务数据的集合 包含必要的内部与外部信息 来自于多个数据源、业务操作系统 保存一定的时间周期 按照企业内业务规则决定存储模型 2.建设的必要性 目前大多数信息系统由于建设时间、建设方、各阶段需求不同，会出
现一系列问题：缺乏整体规则、信息缺乏完整性、缺乏统一的信息管理标准和规范、信息孤岛、不具备大容量的数据管理和分析能力。 3.价值 提高管理决策的科学性和管理效率 信息的整合，可推动现在有信息管理体系的重构 打通信息孤岛全局共享，降低数据获取的难度 逐渐取代各类业务管理报表系统 运用历史数据发现规律 二、数据仓库建设 1.业务需求定义 梳理出所有业务过程，分析业务内容提取需求，对其相关的数据进行探查，并对各系统核心业务人员访谈，准确的了解业务需求情况，近期调研 2.技术体系结构 生命周期图
技术架构图：
3.数据仓库数据建模 数据模型是抽象描述现实世界的一种方法，是通过抽象的实体及实体之间的联系来表示现实世界中事务的相互关系的一种映射，数据仓库模型是数据模型中针对特定的数据仓库应用系统的特定模型。数据仓库建模方法种类较多，常见的三种是范式建模、维度建模、实体建模，每种方法本质上都是从不同的角度解决业务中的问题。 关于单独用一篇来详细介绍，这儿仅对维度建模做基本的介绍，维度建模由数据仓库领域另一位大师Ralph Kimall所倡导，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。 1.维度模型是什么 维度建模将客观世界划分为度量和上下文。度量是由业务过程和支持它们的业务源系统来捕捉的，常常以数据值形式出现，将其称作“事实”，事实由大量上下文包围着，这些文本形式的上下文被直观地分割成多个独立的逻辑块，我们称其为“维”。维度描述了度量上下文的5W（who、what、when、where、why）信息，以及这些上下文是如何作用的。 企业的每一个业务过程都可以用维度模型来描述，维度模型由一系列含有数值量度量的事实表组成，事实表中的数值则被一系列带有文本属性的维度表环绕。
数据仓库多维数据模型的设计说明
1、数据仓库基本概念 1.1、主题（Subject） 主题就是指我们所要分析的具体方面。例如：某年某月某地区某机型某款App的安装情况。主题有两个元素：一是各个分析角度（维度），如时间位置；二是要分析的具体量度，该量度一般通过数值体现，如App安装量。 1.2、维（Dimension） 维是用于从不同角度描述事物特征的，一般维都会有多层（Level：级别），每个Level 都会包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：以时间维为例，时间维一般会包含年、季、月、日这几个Level，每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性，这几个公共属性不仅适用于时间维，也同样表现在其它各种不同类型的维。 1.3、分层（Hierarchy） OLAP需要基于有层级的自上而下的钻取，或者自下而上地聚合。所以我们一般会在维的基础上再次进行分层，维、分层、层级的关系如下图：
每一级之间可能是附属关系（如市属于省、省属于国家），也可能是顺序关系（如天周年），如下图所示： 1.4、量度 量度就是我们要分析的具体的技术指标，诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。 1.5、粒度 数据的细分层度，例如按天分按小时分。 1.6、事实表和维表 事实表是用来记录分析的内容的全量信息的，包含了每个事件的具体要素，以及具体发
生的事情。事实表中存储数字型ID以及度量信息。 维表则是对事实表中事件的要素的描述信息，就是你观察该事务的角度，是从哪个角度去观察这个内容的。 事实表和维表通过ID相关联，如图所示： 1.7、星形/雪花形/事实星座 这三者就是数据仓库多维数据模型建模的模式 上图所示就是一个标准的星形模型。 雪花形就是在维度下面又细分出维度，这样切分是为了使表结构更加规范化。雪花模式可以减少冗余，但是减少的那点空间和事实表的容量相比实在是微不足道，而且多个表联结操作会降低性能，所以一般不用雪花模式设计数据仓库。 事实星座模式就是星形模式的集合，包含星形模式，也就包含多个事实表。
数据仓库模型建设规范10
数据仓库模型建设规范 1.概述 数据仓库不同于日常的信息系统开发,除了遵循其他系统开发的需求、分析、设计、测试等通常的软件生命周期之外，它还涉及到企业信息数据的集成,大容量数据的阶段处理和分层存储,数据仓库的模式选择等等,因此数据仓库的模型设计异常重要,这也是关系到数据仓库项目成败的关键。 物理模型就像大厦的基础架构,就是通用的业界标准,无论是一座摩天大厦也好,还是茅草房也好,在架构师的眼里,他只是一所建筑,地基—层层建筑—封顶,这样的工序一样也不能少,关系到住户的安全,房屋的建筑质量也必须得以保证,唯一的区别是建筑的材料,地基是采用钢筋水泥还是石头,墙壁采用木质还是钢筋水泥或是砖头;当然材料和建筑细节还是会有区别的,视用户给出的成本而定;还有不可忽视的一点是,数据仓库的数据从几百GB到几十TB不等,即使支撑这些数据的RDBMS无论有多么强大,仍不可避免地要考虑数据库的物理设计。 数据仓库建模的设计目标是模型的稳定性、自适应性和可扩展性。为了做到这一点，必须坚持建模的相对独立性、业界先进性原则。 2.数聚模型架构 在数聚项目实施过程，我们一般将数据仓库系统的数据划分为如下图所示几个层次。
2.1.数据架构图
2.2.架构工作方法规范
2.3.准备层L0 2.3.1.主要数据结构 临时表：从数据源抽取，直接落地到临时表。临时表总是保存这次抽取的数据，不保留历史数据。也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果 是增量抽取的话，就是自从上次修改后的数据。 接口表：从临时表，经过清洗、转换到达接口表。接口表保存历史数据，也就是说，如果是全量抽取的话，就是源系统整个表的数据，如果是增量抽取的话。 接口表里面也是源系统整个表的数据。 转换表：为了进行清洗和转换建立的中间辅助表。 2.3.2.命名规范 临时表：L0_TMP_源系统_具体业务或 L0_TMP_业务主题_具体业务（对单一源）举例：L0_TMP_POS_SALESORDER 接口表：L0_DCI_业务主题_具体业务表 举例：L0_DCI_SALES_SALESORDER 转换表：L0_MAP_具体业务表 举例：L0_MAP_SALES 2.3.3.开发工作 ●开发数据抽取接口，落地TMP区 ●开发数据清洗转换程序，落地DCI区，多源系统进行合并 ●开发数据装载程序，装载到L1层 2.4.原子层L1 2.4.1.主要数据结构 维度表：整个数据仓库一致的维度 代码表：维度属性，非维度代码等。 原子事实表：根据业务主题，形成原子事实表 汇总事实表：根据分析主题，业务主题形成合并或汇总的事实表。