商务智能-数据仓库设计

传统数据库：在业务系统中使用的数据库，其中一般存储的是在线交易数据，是以业务单位组织数据并进行存储的。由于数据库是面向具体的应用，现在一般采用关系模型的设计方法。通过关系模型以保证数据的原子性、一致性和完整性，消除数据冗余，一般采用符合范式的规则来约束设计。

数据仓库：数据仓库从设计之初就是为了数据分析服务的，因此在数据组织上是以面向主题进行组织和存储的。是通过在多个维度上对历史数据进行观察和分析，为决策人员提供在该关注点(主题)上的辅助决策信息。因此在设计.上也不同于数据库的关系模型，而是采用多维分析数据模型。

事实表&维度表：事实表中一般存放的是和主题相关的度量(数值)数据以及为了和维表连接而建立的键字段，在维度表中存放的多是维度描述信息和键字段。

事务系统：事务系统是实时的，这就要求具有高时效性，客户查看账务余额需要几分钟是无法忍受的，因此在设计数据库的时候，首先考虑的是如何把这些交易数据快速、准确的写进去或者读取出来。

数据仓库是分析系统的数据平台，它利用从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。

分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。

数据驱动：是指根据当前数据基础和质量等情况，进行数据源分析。

需求驱动：是指根据业务方向性需求、业务问题等，确定系统范围和需求框架。

数据库的设计主要是以需求驱动为原则，也就是说数据库的设计的核心是满足应用需求下的数据存储管理。

数据仓库的设计是坚持“以数据驱动为中心，数据驱动和需求驱动相结合”的原则。

数据仓库三级模型：

• 概念模型：主要根据业务的范围和使用，从高度上进行一个抽象和概括，也就是划分主题域，划分主题域要根据业务的应用和需求来划分，用来达到数据和业务紧耦合的一个目的。
  • 划分方法：划分的方法是首先要确定系统边界，包括了解决策者需求(关注点)，需求类型。通过对业务系统的详细说明，确定数据覆盖范围，对数据进行梳理，列出数据主题详细的清单，了解源数据状况。对每个数据主题都作出详细的解释，然后经过归纳、分类，整理成各个数据主题域，确定系统包含的主题。列出每个数据主题域包含哪些部分，并对每个数据主题域作出详细的解释，最后划分成主题域概念模型。
  • 概念模型设计流程：
    • 
• 逻辑模型：以概念模型为基础，是对概念模型的进一步细化和分解。通过对实体和实体之间的关系，描述业务的需求和业务实现的技术领域，是业务需求人员和技术人员沟通的桥梁和平台。
  • 逻辑模型的设计是数据仓库实施中最重要的一步，因为它直接反映了数据分析部门的实际需求和业务规则，同时对物理
    模型的设计和实现具有指导作用。
  • 特点：通过实体和实体之间的关系勾勒出整个企业的数据蓝图和规划。逻辑模型一般遵循第三范式，与概念模型不同，它主要关注细节性的业务规则，同时需要解决每个主题域包含哪些概念范畴和跨主题域的继承和共享的问题。
  • 在该阶段，要根据分析的需求，列出需要分析的主题、需求目标、维度指标、维度层次、分析的指标、分析方法、数据来源等。
  • 举例：
    • 
    • 
  • 在逻辑模型设计中需要考虑粒度层次的划分。数据仓库的粒度层次划分直接影响了数据仓库模型的设计，通常细粒度的数据模型直接从企业模型选取实体作为逻辑模型的实体，而粗粒度的数据模型需要经过汇总计算得到相应的实体。粒度决定了企业数据仓库的实现方式、性能、灵活性和数据仓库的数据量。
  • 粒度指的是描述数据的综合程度。粒度规定了数据仓库潜在的能力和灵活性，如果没有粒度级别的变化，数据仓库将不能回答需要低于所采用细节级的问题。同时，粒度级别是数据仓库规模的主要决定因素之一，对操作的开销及性能都有显著影响。
  • 随着粒度级别的进入越来越高的细节级，项目需要处理更多的数据属性和它们之间的关系。如果粒度级别充分增加，一个相对小型的数据仓库也会变得非常巨大，这就要求有额外的技术上考虑。
  • 为了提高分析效率，常常在逻辑模型中引入冗余。将存放于数据源多个表中的数据进行合理合并，减少查询中的连接操作，提高查询效率。通过增加派生数据也能提高分析效率。用户经常查询的数据，增加派生数据，减少查询时的计算，提高查询效率。
  • 关系模式一般采取第三范式的特点进行定义，对当前的主题进行关系模式的划分，形成各个实体、实体属性、实体之间的关系等内容。同时在逻辑模型框架的基础.上对实体的中英文名称、属性、属性的值域进行明确、完善和细化，真实反映业务逻辑关系和业务规则。
  • 
• 物理模型：物理模型的设计是在逻辑模型的基础上，为应用生产环境选取一个合适的物理结构的过程，包括合适的存储结构和存储方法。
  • 将逻辑模型转变为物理模型包括以下几个步骤：
    1. 实体名(Entity)转变为表名(Table) 
    2. 属性名(Attribute) 转换为列名(Column) ，确定列的属性(Property)
    3. 确定表之间连接主键和外键属性或属性组
  • 
  • 在物理模型设计中同时要考虑数据的存储结构、存取时间、存储空间利用率、维护代价等。根据数据的重要程度、使用频率和响应时间将数据分类，不同类数据分别存放在不同存储设备中，重要性高、经常存取并对反应时间要求高的数据存放在高速存储设备上；存取频率低或对存取响应时间要求低的数据可以存放在低速存储设备上。根据数据量设定存储块、缓冲区大小和个数。
  • 数据仓库的数据模型相对数据库更简单一些，根据事实表和维度表的关系，主要有星型结构模型和雪花型结构模型两种。（雪花型模型是在星型模型之上进行了一个维度的调整）
    • 星型模型：当所有维表都直接连接到“事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。
      • 星型架构是一种非规范化的结构，多维数据集的每一个维度都直接与事实表相连接，所以数据有一定的冗余。如在商店维度表中，存在省A的城市B以及省A的城市C两条记录，那么省A的信息分别存储了两次，即存在冗余。
      • 
    • 雪花型模型：当一个或多个维表没有直接连到事实表，而是通过其他的维度表连接事实表上的时候，这时候整个图形结构就像一个雪花，所以叫雪花模型。
      • 雪花模型是对星型模型的一个扩展，是对星型模型维表按照范式进行约减和分解，原有的各维度按照层次被分解为更小的一个维表，形成局部的一个层次区域，这些被分解的表都连接到主维表而不是事实表。
      • 
    • 雪花型架构相对于星形架构的优点是，能够直接利用现有的数据库建模工具进行建模，提高工作效率；以后对维度表的变更会更加灵活，而星型结构会牵涉到大量的数据更新；由于不存在数据冗余，因此数据的装载速度会更快。雪花型架构通过去除了数据冗余，通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。
    • 雪花型模型也有一些不足之处，比如模型中的表会更多，这时候就使得模型变得更加复杂，因为查询是需要表的连接，所以会使得查询的效率变低。同时我们对表的元数据维护也变得更加复杂。

元数据：元数据(Metadata) 是关于数据的数据。元数据在数据仓库中有着举足轻重的作用，它不仅定义了数据仓库的作用，指明了数据仓库中信息的内容和位置，刻画了数据的抽取和转换规则，存储了与数据仓库主题有关的各种商业信息，而且整个数据仓库的运行都是基于元数据的，如修改跟踪数据、抽取调度数据、同步捕获历史数据等。

• 技术元数据：是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。
  • 数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；
  • 业务系统、数据仓库和数据集市的体系结构和模式；
  • 汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、预定义的查询与报告；
  • 由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全(用户授权和存取控制)。
• 商务元数据：从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂技术的业务人员也能够“读懂”数据仓库中的数据。
  • 使用者的业务术语所表达的数据模型、对象名和属性名；
  • 访问数据的原则和数据的来源；
  • 系统所提供的分析方法以及公式和报表的信息；
  • 具体包括一下信息：
    • 企业概念模型：这是业务元数据所应提供的重要的信息，它表示企业数据模型的高层信息、整个企业的业务概念和相互关系。以这个企业模型为基础，不懂数据库技术和SQL语句的业务人员对数据仓库中的数据也能做到心中有数。
    • 多维数据模型：这是企业概念模型的重要组成部分，它告诉业务分析人员在数据集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。这里的数据立方体表示某主题领域业务事实表和维表的多维组织形式。
    • 业务概念模型和物理数据之间的依赖：以上提到的业务元数据只是表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、多维数据库中的表、字段、维、层次等之间的对应关系也应该在元数据知识库中有所体现。

数据的抽取和清洗：

• 在数据仓库构建中，ETL贯穿于项目始终，它是整个数据仓库的生命线，包括了从数据抽取、清洗、整合，到转换，加载等的各个过程，ETL抽取整合数据的好坏直接影响到最终的结果展现。
• ETL是数据抽取(Extract) 、转换(Transform)、加载(Load )的简写，它是将OLTP系统中的数据经过抽取，并将不同数据源的数据进行转换、整合，得出一致性的数据，然后加载到数据仓库中。
• 数据的抽取：简而言之就是把源数据的数据抽取到数据仓库中。因为抽取到数据仓库中的数据可能来自各种数据源，因此数据类型也是不尽相同。抽取数据的方法分为逻辑抽取模式和物理抽取模式。
  • 逻辑抽取模式分为全抽取和增量抽取两种。全量抽取适用于那些数据量比较小，并且不容易判断其数据发生改变的诸如关系表，维度表，配置表等;增量抽取，一般是由于数据量大，不可能采用全量抽取，或者为了节省抽取时间而采用的抽取策略。
  • 物理抽取模式分为在线抽取和脱机抽取两类。在线抽取就是在事务处理系统使用业务数据库的同时抽取数据到数据仓库，显然抽取的操作会给业务系统性能带来一定的影响，适合与小数据量的抽取。而脱机(离线)抽取就是在业务系统不工作是的进行数据抽取。
• 数据的清洗：数据的清洗就是把不需要和不符合规范的数据进行处理，数据的清洗最好放在抽取的环节进行，这样可以节约后续的计算和存储成本。当元数据为数据库的时候，在其抽取数据的SQL中就可以进行很多数据清洗工作，比如空值的清洗。
  • 对于空值的处理是数据仓库中一个常见的问题，是将它作为脏数据还是作为特定的一种维成员，应根据实际情况进行判断。一般的做法是根据其有无分析价值而定。对于没有分析价值的空数据字段可直接忽略掉，不做清洗处理。而对于有分析价值的空字段数据就要根据实际情况进行相应的处理，转换为特定的值。
  • 当合并两个表时，因为表的定义不完全相同，可能会导致数据缺失。缺失值的处理方法：
    • 删除缺失值记录。当数据量很大时，可以删除存在有缺失值的数据行。
    • 用固定的值填充。这样处理会导致数据的偏离。
    • 用平均值填充。计算缺失值列里的未缺失值的平均值，用该值填充缺失值单元。
    • 用缺失单元列的未缺失值的众数填充。
    • 根据缺失值单元行的其他单元值填充。比如客户婚姻状况单元缺失，但是客户的性别、年龄、职业单元有数据，则可以根据同样性别、年龄、职业的客户的婚姻状况值填充。
    • 把缺失值当作该属性的一个取值。比如在决策树分析中常常将缺失值视同该属性的一种取值。
    • 利用已有的完整事例构建挖掘模型，然后使用这个模型为每个缺失值预测最有可能的值。
  • 不符合逻辑要求的数据，指的是不符合现实规律的数据，很多时候表现在和业务逻辑矛盾。这些数据可以采取等同于缺失值的处理方法进行处理。

数据的转换和装载策略：

• 所有抽取的数据必须转换为数据仓库可用的数据，拥有可以用来进行战略决策的信息，是数据仓库最根本的原则。
• 数据转换的基本任务是要完成数据的选择、分离/合并、转化、汇总和丰富。
• 数据转换的主要类型包括格式修正、字段解码、计算值和导出值、单个字段的分离、信息的合并、特征集合转化、度量单位的转化、日期/时间转化、汇总和键的重新构造。
• 使用转化工具，自动的工具会提高效率和准确性，并且转换参数和规则会被作为元数据存储起来，但是初始成本较高，而且也不是所有的转换都能使用工具实现;手工技术，这种方法会带来复杂的编码和测试，而且元数据比较难处理。
• 
• 
• 数据装载就是将转换好的数据保存到数据仓库当中。
• 在初始装载的时候，由于数据仓库中的表都是空的，这时候只要对数据仓库中的所有表进行数据插入就可以了。这种装载模式称作初始装载。
• 如果数据仓库中已经装载了部分数据，通常在数据量较少的情况下，可以先将目标数据库的数据全部清空掉，然后全部重新从数据源加载进来。这是一个最简单并且最直观的并且不容易出错的一种解决方案，但是在很多时候会带来性能上的问题。这种策略称作完全刷新。也可用在数据仓库中的部分表装载上。
• 对于已经存在目标数据库中的数据都是历史数据，对于数据源中的数据我们只应该考虑新修改的记录和新插入的记录，只应该考虑这两种数据。所以增量处理实质上就是处理变化的数据。这种装载数据的策略称作增量装载。
• 数据在初始装载完成之后，在以后对数据仓库中数据的维护一般有更新和刷新两种方法。
  • 更新指的是对数据源中增加的变化的应用数据。
  • 刷新则是在特定周期中完全重新装载。
  • 一般来说如果需要更新的记录数总数的25%，可能就要考虑使用刷新的方法。

数据仓库实施：

• 对于数据集市可以看作是数据仓库(事实和汇总)数据的一个子集。数据仓库中的数据包含了整个组织或企业的全部数据，建设的时候无论总技术上、经济上都有较大的风险，另外建设周期也会比较长。
• 在商务智能环境中，大部分分析活动均在于某个业务部门之上进行，因此可以建立针对部门的数据集市，这样每个数据集市中的数据通常就是为特定的功能或某一个部门所制定，不必对其他的部门或功能有效。
• 
• 数据仓库与数据集市对比：数据仓库中，它的数据覆盖了整个企业，包含了企业的各个部门和组织结构，而对于数据集市中的数据可能只针对某一个部门或者两个部门。数据仓库面对的是企业里面的多个主题，而对于数据集市，它只针对一个部门或两个部门，因此它的主题相对比较单一。数据仓库的数据源比较多，而数据集市它是针对某一个主题的，它的数据源就比较少。在实施周期上，数据仓库实施建设周期比较长，达到几个月甚至几年，而数据集市的建设周期就比较短，一般几个月就可以完成。
• 数据集市根据集合数据仓库的数据关系，可以分为依赖型的数据集市和独立型的数据集市
  • 
  • 
  • 业务范围的数据仓库就是将支持整个或一大部分业务的数据仓库，该业务需要更加完全集成的数据仓库，跨部门和业务线(Iine of business)具有较高的数据访问和使用率。即基于整个业务需求设计和构造仓库。可以将这种数据仓库视作跨整个企业使用的决策支持的数据公共存储库或者是其中的一个大型子集。这在整个企业当中业务范围的数据仓库在物理上可以是集中式的也可以是分布式独立的数据集市构架。
    • 独立的数据集市架构指单独的数据集市，这些数据集市是由特定的工作组、部门或业务线进行控制的，完全是为满足其需求而构建的。实际上，它们甚至与其他工作组、部门或业务线中的数据集市没有任何连通性。
    • 虽然不同的数据集市是在特定的工作组、部门或生产线中实现的，但它们可以是集成、互连的，以提供更加全局的业务范围的数据视图。实际上，在最高的集成层次上，它们可以成为业务范围的数据仓库。
  • 数据仓库的实现可以分为3种模式：
    • 爆炸式”开发模式。该模式指的是无论在数据仓库的规划上还是实施上都基于企业的总体、统一进行。由此带来的则是投入资金大、人员多、项目复杂，建设周期长，无论在经济上还是技术上风险都较大。
    • 自顶向下的开发模式就是总体规划，在单个项目阶段中实现数据仓库(数据集市)。自顶向下的实现需要在项目开始时完成更多计划和设计工作。（总体规划，分步实施）
    • 自底向上的开发模式包含数据仓库(数据集市)的计划和设计，不需要等待更大业务范围的数据仓库设计。
      • 开始可以挑选最紧迫需求数据仓库的部门进行建设，随着初始数据仓库(数据集市)实现的扩展，将逐渐增加对机构(企业)数据仓库的构建。此种方法在资金投入少、技术复杂度低，建设周期短，建设风险较小。
• 在使用自底向上或阶段性数据仓库项目模型，构建业务范围架构中的一系列数据集市时，可以一个接一个地集成不同业务主题领域中的数据集市，从而形成设计良好的业务数据仓库。这样的方法可以极好地适用于业务，每个数据集市都可以处理可识别的业务问题或主题领域，从而可以计算投资回报率(ROI)。同时可以构建团队进行测试并调整产品，而该方法也为构建团队提供了宝贵的学习曲线。

 

【学习于商务智能-西南财经大学https://www.icourse163.org/learn/SWUFE-1002080016?tid=1450214442#/learn/announce】