《数据虚拟化:商务智能系统的数据架构与管理》一 2.6 标准化模式、星形模式和雪花模式

简介: 本节书摘来自华章出版社《数据虚拟化:商务智能系统的数据架构与管理》一 书中的第2章,第2.6节,作者:[荷]里克 F. 范德兰斯(Rick F. van der Lans),更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.6 标准化模式、星形模式和雪花模式

每种数据存储都有一种模式,所有列、主键和外键形成了这样一个模式。例如,网络内容管理的数据库包括像CUSTOMER、CUSTOMER_ORDER和DVD_RELEASE这样表的定义。
某些特定的模式流行起来以至于它们被命名。我们在整本书中都提到的最有名的4个模式是:
标准化模式
非标准化模式
星形模式
雪花模式
本节可以看作一个模式形式的进阶课程,更详细的描述见文献[27]和文献[25]。此外,对于模式形式,并没有一个完全的清单。例如,其他模式形式如电子资料室(见文献[28])是值得一说的,但是我们把它们写在了更专业化的书中。

2.6.1 标准化模式

标准化模式是4个模式中最古老的。第一篇关于标准化模式的文章写于20世纪70年代(例如,见文献[29]和文献[30])。标准状态下,每个商务实例中只存储一次,或者换句话说,一个表格应该不包括复制的数据,表格的每一列是以这样方式组织的。William Kent曾经这样概括:在一个标准化表格中,每一列如果不是主键的一部分,那么这一列就应该依赖于主键,并且是主键的全部,并且只依赖于主键(见文献[31])。在非正式的情况下,这意味着在两个非主键之间,不存在一对一或者一对多的关系。
标准化模式的目的是避免存储重复的数据使得被存储的数据变得不一致。因为标准化模式的表格不包含重复的数据,它们与数据插入、更新和删除的事务高度适应。原因是没有重复的数据,每次插入、更新和删除只涉及一行。因此,它在很长的一段时间里是开发生产数据库的首选模式形式。

2.6.2 非标准化模式

顾名思义,非标准化模式是标准化模式的反义词。当表不遵循以上规则,包含着复制的数据,它就是非标准化模式。例如,WEBSITE_TITLE这一列也可以添加到CUSTOMER表中,CUSTOMER表中可能包含了复制的数据。下面这个表是扩展版本的CUSTOMER表的一些行与列的子集:
screenshot

可以清楚地看到,对于每个用户,都有网站ID和网站标题两列。不过,因为用户共享网站,所以导致一个特定的网站ID属于一个特定的网站标题这样的情况不停地重复出现。这个表将这个现象展现得非常清楚。例如,网站ID号为1并且该网站标题为世界一流电影这个组合,在这个非标准化的CUSTOMER表中被存储了58 014次。这个现象出现的原因是非主键列WEBSITE_ID和WEBSITE_TITLE有一对一的关系,所以它就包括了重复的数据。或者用William Kent的话来说,WEBSITE_TITLE这一列是依赖着不是非主键的列WEBSITE_ID。
在很长的一段时间里,标准化模式是设计数据库表的首选模式。随着数据仓库和数据集市的到来,另外的一些模式变得流行起来。星形模式和雪花模式是其中两个最有名的模式。Ralph Kimball对于这些较新的模式形式贡献较大。

2.6.3 星形模式

图2-10展示了一个用星形模式设计的数据库。它代表了一些数据来自样本数据库(见图1-13)。在星形模式中,表分为维度表和事实表。在这里,CUSTOMER、DVD_RELEASE和DATE构成了维度表,TRANSACTION构成了事实表。星形模式名字的由来是因为其构图特征,事实表在中间,维度表像射线那样从中间发射出来,共同构成了一个星形的图案。
每一个维度表都有一个主键和一系列的特征属性来描述这个维度。CUSTOMER表就是维度表中一个典型的例子。在维度表中的每一行都代表着一些业务对象,在CUSTOMER表中,每一行代表着一个用户。在维度表中,非主键列的数据是用来描述业务的。维度表与维度表之间没有关系,只与事实表有关系。

screenshot

事实表是星形模式的中心表,每个事实表都有一个主键包含着它引用的所有维度表中的主键。事实表中的一行往往代表着一个业务事件。潜在的事实表的例子是从银行账户取钱,一次航班的预定以及在柜台前的一次支付。
在图2-10中,TRANSACTION是事实表。它指的是其他三个事实表—CUSTOMER表、DVD_RELEASE表和DATE表,并且它的主键由那三个表的主键组成。这就暗示了在TRANSACTION表中,一行代表了一个客户在具体日期购买或者租用一个具体的DVD版本支付了多少。一个事实表非主键的列是所有的量。通常,量是数值,是可加的数字,像租金、购买价格以及运费。事实表彼此之间没有关系,只是和维度表有关系(通常不只一个)。
因为这个特殊的主键结构,事实表和每个维度表之间的关系总是一对多。并且,在TRANSACTION表中的每一行属于且仅属于一个客户、一个DVD版本和一个日期。对每个客户、每个DVD版本和每个日期,一定有许多交易。
星形模式中维度表和事实表中的主键由代理键值填充满,这些主键对企业用户是没有意义的。因此,它们有时被叫作无意义键值。在大多数情况下,这些只是普通数字。所有CUSTOMER、DVD_RELEASE和DATE表的主键包含代理、无意义的键。一个有意义的键(相反的)的例子是如果日期/时间值用作DATE表的主键值。代理键被用于获得永不改变的、永远代表业务对象(维度)或者业务事件(事实)的关键值。这些用于代表特定对象和事件的键值是必要的,因为它们是不变的常量。
值得注意的是,事实表有标准化模式,而维度表是非标准的。例如,在CUSTOMER表中,WEBSITE_TITLE和COUNTRY_NAME是不标准的,因为它们都是非主键并且它们之间存在着一对多的关系。当有很多客户住在同一个国家的时候,他们都有同一个国家名字和相同的ISO3166国家代码,这是重复数据,因此这个表是不标准的。
几乎每个星形模式都包含一个日期维度。这并不惊奇,因为一个事实表记录了一些业务事件。由于这样一个业务发生在时间的某个角落,事件的发生时刻是描述它的一个必要部分。在这个表中大多数的数据,像月份、周是衍生的数据。这些列是被增添用于提高查询性能,但是也有一些列不包含衍生数据,如假日。
以星形模式安排表的主要目标是限制做连接查询的时候必须参与的表的数目。经常提及的改善查询性能方式是避免表之间的连接查询。另一个优点是书写查询和为最终用户提供一套能从工具中生成查询的选项变得更容易。事实上,重复数据增加的存储空间不是主要因素。另外,重复数据造成的数据不一致性被认为是不严重的问题。它在一个数据仓库的环境里,所有插入和更新都被执行在控制模式下是有意义的。
一个数据存储可以包含许多事实表和诸多星形模式。如果事实表共享了相同的维度表,这些维度表被叫作一致性维度表。只有事实表被相同的维度表访问这样一个方式设计,上述情况才可能发生。

2.6.4 雪花模式

从某种意义上来说,雪花模式和星形模式很像,都是由中心的事实表连接多个表并使用了代理主键。最重要的不同是雪花模式中的维度表是标准化的(如图2-11所示)。如图2-11所展现的,一些列从CUSTOMER表删除了,并且放在了三张外加的表中。
雪花模式中的事实表只和维度表有关,这一点和星形模式一样。而另一方面,维度表可以和其他的表存在一对多的关系。例如,每个区域可以有很多顾客,但是每个顾客只能属于一个区。从某种程度上讲,这些维度表构成了层次。例如,在图2-11中,CUSTOMER表是在REGION表的下一层,而REGION表在COUNTRY表的下一层。换句话说,REGION表中的数据粒度级别比CUSTOMER表中的低。事实上,雪花模型和星形模型都不存在多对多的关系。
雪花模式的优点在于,与等价的星形模式相比减少冗余数据存储。除此之外,雪花模式还可支持维度表中更低级别的查询。就查询而言,为了获取一个网站标题的URL,只需查询一个小表即可。至于雪花模式的事实表和维度表中的关键字,和星形模式中的一样,它们都包含了代理键值。

screenshot

相关文章
|
5月前
|
分布式计算 Kubernetes Hadoop
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
282 6
|
3月前
|
NoSQL 关系型数据库 MySQL
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
218 56
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
|
5月前
|
缓存 监控 API
探索微服务架构中的API网关模式
【10月更文挑战第5天】随着微服务架构的兴起,企业纷纷采用这一模式构建复杂应用。在这种架构下,应用被拆分成若干小型、独立的服务,每个服务围绕特定业务功能构建并通过HTTP协议协作。随着服务数量增加,统一管理这些服务间的交互变得至关重要。API网关作为微服务架构的关键组件,承担起路由请求、聚合数据、处理认证与授权等功能。本文通过一个在线零售平台的具体案例,探讨API网关的优势及其实现细节,展示其在简化客户端集成、提升安全性和性能方面的关键作用。
110 2
|
5月前
|
分布式计算 资源调度 Hadoop
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
127 2
|
5月前
|
存储 缓存 监控
探索微服务架构中的API网关模式
【10月更文挑战第1天】探索微服务架构中的API网关模式
115 2
|
22天前
|
人工智能 BI
【瓴羊数据荟】 AI x Data :大模型时代的数据治理与BI应用创新 | 瓴羊数据Meet Up第4期上海站
瓴羊「数据荟」Meet Up城市行系列活动第四期活动将于3月7日在上海举办,由中国信息通信研究院与阿里巴巴瓴羊专家联袂呈现,共同探讨AI时代的数据应用实践与企业智能DNA的革命性重构。
【瓴羊数据荟】  AI  x Data :大模型时代的数据治理与BI应用创新 | 瓴羊数据Meet Up第4期上海站
|
3月前
|
供应链 监控 安全
基于Quick BI的多部门组织下的数据共享及管理方案
本文介绍了企业在使用Quick BI时面临的数据共享与安全控制需求,涵盖技术、财务、销售等部门的具体挑战,并提出了基于角色组授权、工作空间隔离、行级权限管理等解决方案,确保数据既能高效共享又能安全可控。
253 5
基于Quick BI的多部门组织下的数据共享及管理方案
|
4月前
|
人工智能 算法 BI
聚焦AI与BI融合,引领数智化新潮流 | 【瓴羊数据荟】瓴羊数据Meet Up城市行第一站完美收官!
当BI遇见AI,洞见变得触手可及 —— 瓴羊「数据荟」数据Meet Up城市行·杭州站启幕,欢迎参与。
631 5
聚焦AI与BI融合,引领数智化新潮流 | 【瓴羊数据荟】瓴羊数据Meet Up城市行第一站完美收官!
|
4月前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
4月前
|
缓存 监控 API
探索微服务架构中的API网关模式
随着微服务架构的兴起,API网关成为管理和服务间交互的关键组件。本文通过在线零售公司的案例,探讨了API网关在路由管理、认证授权、限流缓存、日志监控和协议转换等方面的优势,并详细介绍了使用Kong实现API网关的具体步骤。
73 3

热门文章

最新文章