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

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

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

模型设计

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

有几种规模供参考。