扩展内容:数据库与仪表板数据模型

之前的章节中为您在实际使用层面介绍了直连模型，当前大部分公司都有 DBA 专家进行数据库的构建与维护。

DBA 只需要完善数据库层面的内容即可（主外键、可空、唯一等），可以通过自动创建直连查询模型，将数据库的表结构与表关系完美的呈现出来。

本文面向此部分人员进行数据库与数据模型层面的介绍，希望帮助您进一步理解系统中数据模型。

星型架构

星型架构概述

星型架构是数据仓库广泛采用的成熟建模方法。它要求建模者将其模型表分类为“维度”或“事实” 。

星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余

表：建模对象，直观的可以理解成一个数据表。
维度表 ：又叫码表。维度表包含用作唯一标识符的键列以及描述性的列。常见的有 Products、Categories、Customers、Addresses 等。这些表的特点是当业务稳定时，不会随着时间的流逝而大量增加数据。
事实表 ：该表用于存储事件、流水等信息，常见的比如销售订单、银行流水、股票结余、汇率、温度等。这些表的特点是随着时间的流逝而规律性增加数据。事实表包含了与维度列相关的外键列和数值度量值列。维度列相关的外键列确定了事实表的维度，而查询时使用到的维度键值确定了事实表的粒度。例如，一个用于存储销售数据的事实表有三个维度键列：“EmployeeKey”、”ProductKey”和”CategoryKey” 。很容易理解该表有三个维度。若我们的仪表板使用了 Employee 和 Product 相关的维度，在这种情况下产生的是雇员-产品级别粒度的度量数据。

通常情况下，维度表包含的行数相对较少。另一方面，事实表可能包含非常多的行，并行数会随着时间的推移不断增长。

结构良好的模型设计应包括维度类型的表和事实类型的表。我们应该避免对一个表混用这两种类型。

星型架构进阶-雪花架构

雪花架构是在星型架构基础上进行了一次拓展，它使得一个或多个维度表在没有直接连接到事实表的情况下，通过其他维表连接到事实表。

该架构将原有的各维度表尽可能的扩展为更为原子化的维度表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。

例如，Sales 表按 Product 分类。而 Product 又按照 SubCategory 进行分类，SubCategory 又按照 Category 分类。

在系统中创建数据模型时，建议选择模仿雪花架构进行设计（也可能是因为源数据如此）。

当然，也可以选择模仿星型架构设计。一般而言，星型架构的特点导致会有冗余数据但其查询效率更加高。当然，最理想的决策取决于业务实际使用场景。

数据模型与关系

关系属性

我们一般建模的时候，设计人员没有将表类型配置为维度表或事实表。一个表到底是维度表还是事实表实际上是由表间关系决定的。表间关系确定了两个表之间的数据传播路径及表间关系的基数属性。

在创建数据模型时，设计器会自动检测所选择 database 的信息，自动构建表间关系，自动设置唯一值、不可空等内容。

当我们手动创建关系时，一般会将一个表中的一列关联到另一个表中的一列。通常是将一个表中的外键与相对应的表中的主键进行关联。

基数

在某些场景下，我们需要为有关系的表手动创建关系，其中创建的关系中就包含了基数这个属性。一共有五个基数选项，表示“从”和“到”相关列的关系信息。 “一”侧表示该列值唯一；“多”侧表示该列可以包含重复值；“可选一”侧表示该列包含“多”侧外键不包含的唯一值。

以下内容描述了这五个选项：

一对多 (1:*)
多对一 (*:1)
一对一 (1:1)
多对可选一 (*: optional 1)
可选一对多(optional 1:*)

常见的基数为“一对多” 或反过来的“多对一” 。该关系中的“一”这一方始终是维度类型表，而“多”始终是事实类型的表。

一对多和多对一基数选项基本相同，并且它们也是最常见的基数类型。配置一对多或多对一关系时，将选择与列关联顺序匹配的关系。设想一下，如何使用每个表中的 ProductID 列来配置从 Product 表到 Sales 表的关系。基数类型将为 一对多 ，因为 Product 表中的 ProductID 列包含唯一值。如果将表反向关联，即 Sales 到 Product ，则基数为多对一。

一对一 关系意味着两个列都包含唯一值。这种基数类型并不常见，并且由于冗余数据的存储，它可能代表了不太理想的模型设计。

多对可选一或可选一对多关系意味着一侧包含唯一值，另一侧包含重复值，但其去重的重复值集合是唯一值一侧的子集。

筛选器方向

筛选器是应用于模型的过滤条件，它改变了仪表板可见的行及行的值。

筛选器方向我们可以理解成箭头一侧可以获取箭尾一侧的数据，而箭尾一侧可以过滤箭头一侧的数据。

一般情况下，当主键外键关系确定后，我们会自动创建关系（包括基数和筛选器方向）。而每个表到底是箭头一侧还是箭尾一侧取决于表双方的基数类型。

一般情况下，数据过滤总是从箭尾一侧流向箭头一侧，反之则无法数据过滤。另外，一般箭尾一侧总是“一”的一方，而“多”的一方总是箭头所指的一侧。

基数类型	筛选器方向
一对多（或多对一）	单向双向
可选一对多（或多对可选一）	单向双向
一对一	双向

“单向”表示单一的过滤，而“双向”表示双方皆可对对方进行过滤。在一对多关系中，筛选方向始终从“一”侧开始；也可以选择从“多”侧开始（双向）。在一对一关系中，筛选方向始终同时从两个表开始。当基数类型包括“一”侧时，此类筛选器将始终从该侧传播。

尝试配置双向关系可能会导致筛选器传播路径不明确。即，从一个表到另外一个表的路径存在二义性。在这种情况下，Wyn将通过错误消息发出警报。

安全过滤器

主要用于过滤敏感数据。一般是过滤部门间的业务数据，不宜公开的数据等。

当系统管理员对模型设置安全过滤器后，根据人员不同的部门及个人属性，仪表板中呈现的数据而不同。

安全过滤器他可以是一个定值，也可以是一个变量。

显示所有维度

一般在数据呈现时，我们会呈现某产品卖出多少钱，但没有卖钱的产品我们会不呈现。

仪表板中“ 显示所有维度 ”这个开关，就是为了将没有卖钱的产品呈现出来。

比如我们有2个表，一个是Sales表，一个是Products表。

Sales表

SaleId	Amount	ProductKey
1	2	1
2	3	2
3	4	2

Product表

ProductId	ProductName
1	Fruit
2	Meat
3	Milk

根据建模情况， Sales表是事实表（基数为“多”的一侧），而Product表是维度表（基数为“一”的一侧），关系是由Product表（箭尾）指向Sales表（箭头）。

假设我们要呈现的维度是ProductName，呈现的度量值是Sum(Amount)

当我们没有勾选显示所有维度时，根据上述关系，最终呈现的结果是：

ProductName	Sum(Amount)
Fruit	2
Meat	7

而勾选了显示所有维度后，呈现的结果却是：

ProductName	Sum(Amount)
Fruit	2
Meat	7
Milk	NULL

模型设计

因为数据模型的可复用性，我们需要考虑直连模型的规模问题。

有几种规模供参考。

序号	直连模型规模	优点	缺点
1	大而全，所有的表都放在一个里面。	1. 所有的表数据和关系都在，可以使用任意数据进行制作仪表板。 2. 所有的仪表板都可以使用这一个数据模型。避免重复创建数据模型。	1. 由于所有数据全部放到一个数据模型中，存在一定的安全性隐患。 2. 表较多，实际使用时无针对性，寻找表和字段时比较慢。
2	按照关系，将有关系的表放在一个模型中，不存在孤岛情况。	将有关系的所有表都呈现，可以大概率满足一个业务部门的需求。	有关系的表都放到了一个数据模型中，那么就无法将两个数据模型中数据呈现在一个图表上。
3	按照业务使用的表范围（销售、客户关系、房产等），可能存在表的孤岛情况。	完全按照业务分层。层次更加清晰。	业务间数据无法在一个图表上呈现。

序号

直连模型规模

优点

缺点

大而全，所有的表都放在一个里面。

1. 所有的表数据和关系都在，可以使用任意数据进行制作仪表板。

2. 所有的仪表板都可以使用这一个数据模型。避免重复创建数据模型。

1. 由于所有数据全部放到一个数据模型中，存在一定的安全性隐患。

2. 表较多，实际使用时无针对性，寻找表和字段时比较慢。

按照关系，将有关系的表放在一个模型中，不存在孤岛情况。

将有关系的所有表都呈现，可以大概率满足一个业务部门的需求。

有关系的表都放到了一个数据模型中，那么就无法将两个数据模型中数据呈现在一个图表上。

按照业务使用的表范围（销售、客户关系、房产等），可能存在表的孤岛情况。

完全按照业务分层。层次更加清晰。

业务间数据无法在一个图表上呈现。