之前的章节中为您在实际使用层面介绍了直连模型，当前大部分公司都有 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表

Product表

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

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

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

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

模型设计

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

有几种规模供参考。