数据仓库基础信息

daladalabao

已于 2023-04-27 07:24:46 修改

阅读量793

点赞数 1

文章标签：数据仓库

于 2023-04-26 22:10:12 首次发布

本文链接：https://blog.csdn.net/qq_45450889/article/details/130395595

版权

在这里插入图片描述

数据仓库

数据仓库概述

什么是数据库

什么是数据集市

什么是数据仓库

数据仓库和数据库的对比

什么是数据湖

数据存储架构
数据处理工具
- 聚焦如何把数据搬到湖里
- 关注如何对湖中的数据进行分析、挖掘、利用
- 数据湖和数据仓库的对比

数据仓库的特点

数据仓库是集成的
数据仓库的数据是稳定的：一般情况下不会对数据进行修改
数据仓库中的数据是随时间变化而变化的
- 随时间变化不断增加新的数据内容
- 随时间变化不断删去旧的数据内容
- 数据仓库中包含大量的综合数据，所以要按照时间段进行综合

数据仓库分层

分层的优势Why

复杂问题简单化
减少重复开发
隔离原始数据

四层分层

ODS（数据原始层）：存放原始数据
DWD（数据明细层）：对ODS层数据进行情学、维度退化、脱敏等
DW（数据汇总层）：对DWD层数据进行轻度的汇总
DM（数据集市层）：为各种统计报表提供数据

三层分层

ODS
DW（数据仓库层）：数据清洗、初步汇总
DM

五层分层

ODS
DWD
DWS
ADS（数据应用层）：为各种统计报表提供数据
DIM（维表层）：基于维度建模理念思想，建立整个企业的一致性维度
- 高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万或者上亿级别的
- 低基数维度数据：一般是配置表，比如枚举值中对应的中文含义，或者日期维表。数据量较小

数据仓库核心理论

数据仓库建模

为什么需要数据建模
- 性能：快速查询所需要的数据，减少数据的I/O吞吐
- 成本：减少不必要的数据冗余，实现计算结果复用，降低数据的存储和计算成本
- 效率
- 质量：改善数据统计口径的不一致性，减少数据计算错误的可能性
常见的四种数据仓库建模模型
- 数据处理大致分为两类
  - 操作型处理：联机事务处理（OLTP）
  - 分析型处理：联机分析处理（OLAP）
- ER模型（范式模型）
  - 特点
    - 优点：设计思路自上而下，适合上游基础数据存储，同一份数据只存储一份，没有数据冗余，方便解耦，易维护
    - 缺点：开发周期长维护成本高
  - 范式理论：
  - 用于OLTP
- 维度模型
  - 用于OLAP系统中
  - 以事实表为中心进行表组织
  - 维度建模设计
    - 选择需要进行决策分析的业务过程
    - 定义粒度
    - 识别维度
    - 确认事实
  - 细分模型
    - 星型模型
      - 由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表
      - 和雪花模型的区别在于维度的层级，标准的星型模型维度只有一层，而雪花模型可能会涉及多层
    - 雪花模型
      - 所谓的“雪花化”就是将星型模型中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了以事实表为中兴的雪花型结构
    - 星座模型
      - 数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享
- Data Vault模型
  - 由Hub（关键核心业务实体）、Link（关系）、Satellite（实体属性）组成
  - 设计的出发点是为了实现数据的整合
- Anchor模型
  - 对Data Vault模型做了进一步的规范化处理
  - 高度可扩展的模型：所有的扩展知识添加而不是修改，因此他将模型规范到6NF，基本变成了K-V结构模型
模型选择
- 星型还是雪花，取决于行能优先还是灵活更有先
- 传统行业中，业务相对稳定，以范式建模为主。如电信、金融行业
- 互联网公司，业务变化快以维度建模为主
数仓建模流程
- 业务建模：需求沟通
- 概念(领域)建模：抽象关键业务
- 逻辑建模：表设计
- 物理建模：建表
数仓建模过程
- 选择业务过程
- 选择数据域
  - 申明粒度
  - 确认维度
  - 确认事实
模型设计思路
- 自上而下：所有的数据，能够提供统一视图
- 自下而上：只加载需要的数据
模型落地实现

事实表设计

设计原则
- 尽可能包含所有与业务相关的事实
- 只选择与业务相关的事实
- 分解不可加性事实为可加性的事实
  
  比如订单的优惠率分为订单原价和订单优化金额
- 在选择维度和事实之前必须先声明粒度
- 同一个事实表中不能有多种不同粒度的事实
  
  有机票支付成功事务事实表，字段为：机票id、订单id、票支付金额、票折扣金额、订单支付金额、订单票数
  该表中的订单支付金额和订单票数为订单级，和事实表粒度不一致，且不能进行汇总
- 事实的单位要保持一致
- 对null值要进行处理
- 使用退化维度提高事实表的易用性
  
  通过事实表的外键关联专门的为表的方式来获取维度
  和大数据领域的事实表设计不同，大数据领域中是在事实表中存储各类常用未读信息减少关联操作
事实表设计方法
- 选择业务过程及确定事实表类型
  
  以淘宝的一个交易订单为例：买家下单->创建订单->等待买家付款->买家付款->等待卖家发货->卖家发货->等待买家确认收货->买家确认收货->交易成功
  - 分析业务的生命周期
  - 明确关键业务步骤
    
    创建订单、买家付款、卖家发货、买家确认收货
  - 根据具体业务，选择与维度建模有关的业务过程
  - 根据选择的业务过程来确定事实表的类型
- 声明粒度
  - 粒度的作用
    
    粒度的声明，意味着事实表中的每一行所表示的业务含义
  - 粒度的选择：尽量选择最细级别的原子粒度
- 确定维度
- 确定事实
  
  选择与业务过程有关的所有事实
- 冗余维度
  
  冗余常用维度字段（比如商品类目），方便下游用户使用（过滤查询、控制聚合）
三种事实表
- 事务事实表
  
  也可称为原子事实表，描述业务过程，跟踪控件或时间上某点的度量时间，保存的是最原子的数据。
  类似于mysql binlog日志，每一次相关的 change 都记录下来，生成一行新的数据。
- 周期快照事实表
  
  以一个周期为时间间隔，来记录事实，一般周期可以是每天、每周、每月、每年等。
  只看某个业务过程，比如订单收货，数据按订单收货时间来切分，周期可以为每天、每月等。
- 累计快照事实表
  
  用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点；当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。
  要看整个生命周期的多个业务过程，比如：创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间，分别作为一个字段，便于计算不同业务过程的时间间隔。

多维体系结构

总线架构
一致性维度

在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这个问题。
一致性事实

维度设计

维度基本概念

维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实”，将环境描述为“维度”，维度是用于分析事实所需要的的多样环境。
维度所包含的表示维度的列，称为维度属性。

如何获取维度或维度属性

维度设计原则

维度属性的作用一般是查询约束、分类汇总以及排序

维度属性尽量丰富，为数据使用打下基础

比如淘宝商品维度有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基础。
给出详实的、富有意义的文字描述

属性不应该是编码，而应该是真正的文字。在阿里巴巴维度建模中，一般是编码和文字同时存在，比如商品维度中的商品ID和商品标题、类目ID和类目名称等。ID一般用于不同表之间的关联，而名称一般用于报表标签
区分数值型属性和事实
沉淀出通用的维度属性，为建立一致性维度做好铺垫

有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表的不同宇段混合处理得到，或者通过对单表的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进行沉淀。一方面，可以提高下游使用的方便性，减少复杂度；另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。

维度的基本设计方法

选择维度或新建维度
确定主维表

此处的主维表一般是ODS表，直接与业务系系统同步。以淘宝商品维度为例，sauctionauctions是与前台商品中心系统同步的商品表，此表即是主维表。
确定相关维表

数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以淘宝商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、SPU、卖家、店铺等维度存在关联关系。
确定维度属性

六范式与反范式

六范式

一范式

数据库表的每一列都是不可分割的原子数据项
二范式

在 1NF 的基础上，实体的属性完全函数依赖于主关键字（混合主键），不能存在部分函数依赖于主关键字（混合主键）
三范式

在 2NF 的基础之上，消除了非主属性对于主键（复合主键）的传递依赖。
BC范式

定义：关系模式R中，若每一个决定因素都包含码，则R属于BCFN。
理解：根据定义我们可以得到结论，一个满足BC范式的关系模式有：
所有非主属性对每一个码都是完全函数依赖；
所有主属性对每一个不包含它的码也是完全函数依赖；
没有任何属性完全函数依赖于非码的任何一组属性。
例如有关系模式C(Cno, Cname, Pcno)，Cno，Cname，Pcno依次表示课程号、课程名、先修课。可知关系C只有一个码Cno，且没有任何属性对Cno部分函数依赖或传递函数依赖，所以关系C属于第三范式，同时Cno是C中的唯一决定因素，所以C也属于BC范式。
四范式

定义：限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。
理解：显然一个关系模式是4NF，则必为BCNF。也就是说，当一个表中的非主属性互相独立时（3NF），这些非主属性不应该有多值，若有多值就违反了4NF。
五范式

第五范式，又称为完美范式，越往下，冗余度越低。
第五范式有以下要求：
必须满足第四范式；
表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。
第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况，而第五范式则处理相互依赖的多值情况。

反范式

一般来说，数据库只需要满足第三范式（3NF）即可。
反范式化设计数据库，是为了提高查询效率，采用空间换时间的实现思路。
应用场景：当冗余的信息有价值或者能大幅度提高查询效率的时候，我们才会采取反范式的优化。
一些情况下，比如存在频繁查询时，可以容忍适当的冗余设计，目的是减少多表关联查询，提高效率。
例如：订单表中冗余了商品信息和用户相关信息，避免查询订单时关联用户表和商品表去查询相关信息，提高效率。
优点：增加数据表中的冗余字段来提高数据库的读性能
缺点：
存储空间变大了
一个表中字段做了修改，另一个表中冗余字段也需要做同步修改，否则数据不一致
若采用存储过程来支持数据的更新、删除等额外操作，如果更新频繁会非常消耗系统资源
在数据量小的情况下，反范式不能体现性能的优势，可能还会让数据库的设计更加复杂

范式化设计与反范式设计的优缺点

范式化设计（时间换空间）
- 优点：范式化的表减少了数据冗余，数据表更新操作快、占用存储空间小
- 缺点
  - 查询时需要对多个表进行关联，查询性能降低
  - 索引优化会更难进行
反范式化设计（空间换时间）
- 优点
  - 可以减少表关联
  - 可能更好的进行索引优化
- 缺点
  - 存在大量冗余数据
  - 数据维护成本更高（删除异常，插入异常，更新异常）

元数据

元数据（Metadata）最基本的定义就是“关于数据的数据”。
元数据打通了源数据、数据仓库、数据应用，记录了数据从产生到消费的全过程。元数据主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。在数据仓库系统中，元数据可以帮助数据仓库管理员和开发人员非常方便地找到他们所心的数据，用于指导其进行数据管理和开发工作，提高工作效率。
正是有了元数据，才使得数据仓库的最终用户可以随心所欲地使用数据仓库，利用数据仓库进行各种管理决策模式的探讨。元数据是数据仓库的应用灵魂，可以说没有元数据就没有数据仓库。

元数据的类型

技术元数据

技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发、管理和维护数据仓库使用的数据。
它主要包含以下信息：
数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；
业务系统、数据仓库和数据集市的体系结构和模式；
汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚合、汇总和预定义的查询与报告；
由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则及安全（用户授权和存取控制）。
业务元数据

业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。
业务元数据主要包括以下信息：
使用者的业务术语所表达的数据模型、对象名和属性名；
访问数据的原则和数据的来源；
系统所提供的分析方法及公式和报表的信息。
在信息打包过程中，需要用包图表示维度和类别还有它们之间的传递和映射关系，实际上这个操作就是在原业务系统的基础上创建了元数据。其中的维度、类别还有层次关系是属于典型的技术型元数据，而业务系统中与之对应的术语则属于业务元数据。比如日期、区域、产品、客户年龄和客户状况等维度，实际销售、计划销售、预测销售、计划偏差和预测偏差等指标皆属于元数据。这些数据在以后的分析中起到了极为重要的作用。

元数据的作用

元数据是数据管理、数据内容、数据应用的基础，在数据管理方面为集团数据提供在计算、存储、成本、质量、安全、模型等治理领域上的数据支持。
从元数据的类型和作用来看，元数据实际上是要解决何人在何时、何地为了什么原因及怎样使用数据仓库的问题。再具体化一点，元数据在数据仓库管理员的眼中是数据仓库中的包含了所有内容和过程的完整知识库和文档，而在最终用户（即数据分析人员）眼中，元数据则是数据仓库的信息地图。
数据分析员为了能有效地使用数据仓库环境，往往需要元数据的帮助。尤其是在数据分析员进行信息分析处理时，他们首先需要去查看元数据。元数据还涉及到数据从操作型环境到数据仓库环境中的映射。当数据从操作型环境进入数据仓库环境时，数据要经历一系列重大的转变，包含了数据的转化、过滤、汇总和结构改变等过程。数据仓库的元数据要能够及时跟踪这些转变，当数据分析员需要就数据的变化从数据仓库环境追溯到操作型环境中时，就要利用元数据来追踪这种转变。另外，由于数据仓库中的数据会存在很长一段时间，其间数据仓库往往可能会改变数据的结构。随着时间的流逝来跟踪数据结构的变化，是元数据另一个常见的使用功能。
元数据描述了数据的结构、内容、链和索引等项内容。在传统的数据库中，元数据是对数据库中各个对象的描述，数据库中的数据字典就是一种元数据。在关系数据库中，这种描述就是对数据库、表、列、观点和其他对象的定义；但在数据仓库中，元数据定义了数据仓库中的许多对象——表、列、查询、商业规则及数据仓库内部的数据转移。元数据是数据仓库的重要构件，是数据仓库的指示图。元数据在数据源抽取、数据仓库开发、商务分析、数据仓库服务和数据求精与重构工程等过程都有重要的作用

数据治理

数据治理概念

数据治理是指将数据作为组织资产而展开的一系列的具体化工作，是对数据的全生命周期管理。
数据治理体系是指从组织架构、管理制度、操作规范、IT应用技术、绩效考核支持等多个维度对组织的数据模型、数据架构、数据质量、数据安全、数据生命周期等各方面进行全面的梳理、建设以及持续改进的体系。

数据治理目标

数据治理的目标是提高数据的质量准确性和完整性，保证数据的安全性（保密性、完整性及可用性），实现数据资源在各组织机构部门的共享；推进信息资源的整合、对接和共享，从而提升集团公司或政务单位信息化水平，充分发挥信息化作用。

数据治理体系

如下图所示，数据治理体系包含两个方面：一是数据质量核心领域，二是数据质量保障机制。

数据治理核心领域

为了有效管理信息资源，必须构集团级数据治理体系。数据治理体系包含数据治理组织、数据构架管理、主数据管理、数据质量管理、数据服务管理及数据安全管理内容，这些内容既有机结合，又相互支撑。

数据治理方法

数据资源梳理
数据采集清洗
基础库主题库建设

一般情况下，可以将数据分为基础数据、业务主题数据和分析数据。基础数据一般指的是核心实体数据，或称主数据，例如智慧城市中的人口、法人、地理信息、信用、电子证照等数据。主题数据一般指的是某个业务主题数据，例如市场监督管理局的食品监管、质量监督检查、企业综合监管等数据。而分析数据指的是基于业务主题数据综合分析而得的分析结果数据，例如市场监督管理局的企业综合评价、产业区域分布、高危企业分布等。那么基础库和主题库的建设就是在对业务理解的基础上，基于易存储、易管理、易使用的原则抽像数据存储结构，说白了，就是基于一定的原则设计数据库表结构，然后再根据数据资源清单设计数据采集清洗流程，将整洁干净的数据存储到数据库或数据仓库中。
元数据管理

元数据管理是对基础库和主题库中的数据项属性的管理，同时，将数据项的业务含义与数据项进行了关联，便于业务人员也能够理解数据库中的数据字段含义，并且，元数据是后面提到的自动化数据共享、数据交换和商业智能（BI）的基础。需要注意的是，元数据管理一般是对基础库和主题库中（即核心数据资产）的数据项属性的管理，而数据资源清单是对各类数据来源的数据项的管理。
血缘追踪

数据被业务场景使用时，发现数据错误，数据治理团队需要快速定位数据来源，修复数据错误。那么数据治理团队需要知道业务团队的数据来自于哪个核心库，核心库的数据又来自于哪个数据源头。我们的实践是在元数据和数据资源清单之间建立关联关系，且业务团队使用的数据项由元数据组合配置而来，这样，就建立了数据使用场景与数据源头之间的血缘关系。数据资源目录：数据资源目录一般应用于数据共享的场景，例如政府部门之间的数据共享，数据资源目录是基于业务场景和行业规范而创建，同时依托于元数据和基础库主题而实现自动化的数据申请和使用
质量管理

数据价值的成功发掘必须依托于高质量的数据，唯有准确、完整、一致的数据才有使用价值。因此，需要从多维度来分析数据的质量，例如：偏移量、非空检查、值域检查、规范性检查、重复性检查、关联关系检查、离群值检查、波动检查等等。需要注意的是，优秀的数据质量模型的设计必须依赖于对业务的深刻理解，在技术上也推荐使用大数据相关技术来保障检测性能和降低对业务系统的性能影响，例如 Hadoop，MapReduce，HBase 等。
商业智能

数据治理的目的是使用，对于一个大型的数据仓库来说，数据使用的场景和需求是多变的，那么可以使用 BI 类的产品快速获取需要的数据，并分析形成报表
数据共享交换

数据质量衡量标准

数据的准确性

数据准确性（Accuracy）是指数据采集值或者观测值和真实值之间的接近程度，也叫做误差值，误差越大，准确度越低。
指数据中记录的信息和数据是否准确，数据记录的信息是否存在异常或错误。准确性关注的是数据记录中存在的错误，如字符型数据的乱码现象就存在着准确性的问题，还有就是异常的数值：异常大或者异常小的数值、不符合有效性要求的数值等。
数据的精确性

数据的精确性（Precision）是指对同一对象的观测数据在重复测量时所得到不同数据间的接近程度。精确性，也可以叫精准性。精确性与我们数据采集的精度有关系。精度高，要求数据采集的粒度越细，误差的容忍程度越低。
比如测量人的身高，我们可以精确到厘米，多次测量差异只会在厘米级别；测量北京到上海的距离，我们精确到公里，多次测量结果间的差异会在公里级别:采用游标卡尺测量一个零件的厚度，可以精确到1/50毫米，多次测量的结果间的误差也只会在1/50毫米间。采用的测量方法和手段直接影响着数据的精确性。
数据的真实性

数据的真实性，也叫数据的正确性(Rightness)。数据的正确性取决于数据采集过程的可控程度，可控程度高，可追溯情况好，数据的真实性容易得到保障，而可控程度低或者无法追溯，数据造假后无法追溯，则真实性难以保证。为了提高数据的真实性，采用无人进行过程干涉的智能终端直接采集数据，能够更好地保证所采集数据的真实性，减少人为干预，减少数据造假，从而让数据更加正确地反应客观事物。
数据的及时性

数据的及时性（In-time）就是指数据能否在需要的时候得到保证。
比如月初会对上个月的经营和管理数据进行统计汇总，这些数据能否及时处理完成，财务能否在月度关账后及时核算。数据的及时性是我们数据分析和挖掘及时性的保障。如果公司的财务核算复杂，核算速度缓慢，上个月的数据在月中才能统计汇总完成，等需要调整财务策略的时候，已经到了月底了，一个月已经快过完了。特别是公司做大了之后，业务覆盖多个市场，多个国家，数据不能及时汇总，会影响到高层决策的及时程度，数据的及时性与企业数据处理的速度和效率有直接的关系，为了提高数据的及时性，越来越多的公司采用管理信息系统，并在管理信息系统中附加各种自动数据外理功能，能够在数据上传系统之后自动完成绝大部分报表，从而保证数据外理的效率。计算机自动外理中间层数据是提高企业数据处理效率的有效手段。
除了保证数据采集的及时性和数据外理的效率问题外，还需要从制度和流程上保证数据传输的及时性，数据报表完成了，要及时或者在要求的时间范围内发送到指定的部门，或者上传到指定的存储空间。
数据的即时性

指数据采集时间节点和数据传输的时间节点，一个数据在数据源头采集后立即存储，并立即加工呈现，就是即时数据，而经过一段时间之后再传输到信息系统中，则数据即时性就稍差。
比如微博的数据采集，当用户发布了微博，数据立即能够被抓取和加工，会生成即时微博数据报告，并随着时间推移，数据不断变化，我们可以称作是即时采集和处理的。一个生产设备的仪表即时反应着设备的温度、电压、电流、气压等数据，这些数据生成数据流，随时监控设备的运行状况，这个数据可以看作是即时数据。而当设备的即时运行数据存储下来，用来分析设备运行状况与设备寿命的关系，这些数据就成为历史数据。
数据的完整性

比如一条信息采集12个数据点，如我们采集员工信息数据的时候，要求填写姓名，出生日期，性别，民族、籍贯，身高、血型、婚姻状况，最高学历，最高学历专业、最高学历毕业院校、最高学历毕业时间等12项信息，而某一员工仅仅填写了部分信息，如只填写了其中的5项，则该员工所填写数据的完整性只有一半。
一个公司数据的完整性体现着这个公司对数据的重视程度。要求采集数据而实际上并未完整采集，只采集了一部分，这就是不完整的，往往是公司对数据采集质量要求不到位导致的。公司要求每个人都填写完整的个人信息表，而有部分员工拒绝填写，公司2000员工，只有1200人填写了完整的个人信息表，则这个数据集就是不完整的。
另外，对于动态数据，还要从时间轴上去衡量数据采集的完整性。比如，我们要求每小时采集一次数据，每天会形成24个数据点，记录为24条数据，但是员工渎职，只记录了20次，那么这个数据集也是不完整的。
数据的全面性

数据的全面性和完整性不同，完整性衡量的是应采集和实际采集的差异。而全面性指的是数据采集点的遗漏情况。
比如说，我们要采集员工行为数据，我们只采集了员工上班打卡和下班打卡的数据，上班时间的员工行为数据并未采集，或者没有找到合适的方法来采集。那么，这个数据集就是不全面的。
比如描述一个产品的包装，仅仅描述了产品包装的正面和背面，没有记录产品包装的侧面，则就是不全面的。我们记录一个客户的交易数据，我们只采集了客户订单中的产品、订单中产品的价格和数量，而没有采集客户送货地址，采购时间，这个数据采集就是不全面的。
比如腾讯OO和微信的用户数据记录了客户交流沟通的数据；阿里和京东的用户数据记录了用户的购买交易数据；百度地图记录了用户出行的数据；大众点评和美团记录了客户餐饮娱乐的数据。对于全面描述一个人的生活的衣食住行各方面，这些公司的数据都是不全面的，而如果把他们的数据整合起来，则会形成更加全面的数据。所以说，数据的全面性是一个相对的概念。过度追求数据的全面性是不现实的。
数据的关联性

数据的关联性是指各个数据集之间的关联关系。
比如员工工资数据和工绩效考核数据是通过员工这个资源关联在一起来的，而且绩效数据直接关系到工资的多少。采购订单数据与生产订单数据之间通过物料的追溯机制进行关联，而生产订单又是由员工完成的，即通过员工作业数据与员工信息数据关联起来。