关系数据库的四个层次结构是什么？

层次模型是数据库系统中最早使用的模型，它的数据结构类似一颗倒置的树，每个节点表示一个记录类型，记录之间的联系是一对多的联系，基本特征是：

* 一定有一个，并且只有一个位于树根的节点，称为根节点；

* 一个节点下面可以没有节点，即向下没有分支，那么该节点称为叶节点；

* 一个节点可以有一个或多个节点，前者称为父节点，后者称为子节点；

* 同一父节点的子节点称为兄弟节点。

* 除根节点外，其他任何节点有且只有一个父节点；

图11.7是一个层次模型的例子。

层次模型中，每个记录类型可以包含多个字段，不同记录类型之间、同一记录类型的不同字段之间不能同名。如果要存取某一类型的记录，就要从根节点开始，按照树的层次逐层向下查找，查找路径就是存取路径。如图11.8所示。

层次模型结构简单，容易实现，对于某些特定的应用系统效率很高，但如果需要动态访问数据（如增加或修改记录类型）时，效率并不高。另外，对于一些非层次性结构（如多对多联系），层次模型表达起来比较繁琐和不直观。

2．网状模型

网状模型可以看作是层次模型的一种扩展。它采用网状结构表示实体及其之间的联系。网状结构的每一个节点代表一个记录类型，记录类型可包含若干字段，联系用链接指针表示，去掉了层次模型的限制。网状模型的特征是：

1. 允许一个以上的节点没有父节点；

2. 一个节点可以有多于一个的父节点；

例如，图11.9（a）和图11.9（b）都是网状模型的例子。图11.9（a）中节点3有两个父节点，即节点1和节点2；图11.9（b）中节点4有三个父节点，即节点1，节点2和节点3。

由于网状模型比较复杂，一般实际的网状数据库管理系统对网状都有一些具体的限制。在使用网状数据库时有时候需要一些转换。例如，如图11.10所示。

网状模型与层次模型相比，提供了更大的灵活性，能更直接地描述现实世界，性能和效率也比较好。网状模型的缺点是结构复杂，用户不易掌握，记录类型联系变动后涉及链接指针的调整，扩充和维护都比较复杂。

3．关系模型

关系模型是目前应用最多、也最为重要的一种数据模型。关系模型建立在严格的数学概念基础上，采用二维表格结构来表示实体和实体之间的联系。二维表由行和列组成。下面以教师信息表和课程表为例，说明关系模型中的一些常用术语：

表11.1 教师信息表（表名为：tea_info）

TNO(教师编号)

NAME(姓名)

GENDER(性别)

TITLE(职称)

DEPT(系别)

805

李奇

女

讲师

基础部

856

薛智永

男

教授

信息学院

表11.2 课程表（表名为：cur_info）

CNO(课程编号)

DESCP(课程名称)

PERIOD(学时)

TNO(主讲老师编号)

005067

微机基础

40

805

005132

数据结构

64

856

1. 关系（或表）：一个关系就是一个表，如上面的教师信息表和课程表。

2. 元组：表中的一行为一个元组（不包括表头）。

3. 属性：表中的一列为一个属性。

4. 主码（或关键字）：可以唯一确定一个元组和其他元组不同的属性组。

5. 域：属性的取值范围。

6. 分量：元组中的一个属性值。

7. 关系模式：对关系的描述，一般表示为：关系名（属性1，属性2，... ...，属性n）。

关系模型中没有层次模型中的链接指针，记录之间的联系是通过不同关系中的同名属性来实现的。 关系模型的基本特征是：

1. 建立在关系数据理论之上，有可靠的数据基础；

2. 可以描述一对一，一对多和多对多的联系。

3. 表示的一致性。实体本身和实体间联系都使用关系描述。

4. 关系的每个分量的不可分性，也就是不允许表中表。

关系模型概念清晰，结构简单，实体、实体联系和查询结果都采用关系表示，用户比较容易理解。另外，关系模型的存取路径对用户是透明的，程序员不用关心具体的存取过程，减轻了程序员的工作负担，具有较好的数据独立性和安全保密性。

关系模型也有一些缺点，在某些实际应用中，关系模型的查询效率有时不如层次和网状模型。为了提高查询的效率，有时需要对查询进行一些特别的优化

作为一名数据的规划者，我们肯定希望自己的数据能够有秩序地流转，数据的整个生命周期能够清晰明确被设计者和使用者感知到。直观来讲就是如图这般层次清晰、依赖关系直观。

但是，大多数情况下，我们完成的数据体系却是依赖复杂、层级混乱的。如下图，在不知不觉的情况下，我们可能会做出一套表依赖结构混乱，甚至出现循环依赖的数据体系。

因此，我们需要一套行之有效的数据组织和管理方法来让我们的数据体系更有序，这就是谈到的数据分层。数据分层并不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：

1）清晰数据结构： 每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解；

2）减少重复开发： 规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算；

3）统一数据口径： 通过数据分层，提供统一的数据出口，统一对外输出的数据口径；

4 ）复杂问题简单化： 将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题。

为了满足前面提到好处，通常将数据模型分为三层：数据运营层（ ODS ）、数据仓库层（DW）和数据应用层（APP）。简单来讲，我们可以理解为：ODS层存放的是接入的原始数据，DW层是存放我们要重点设计的数据仓库中间层数据，APP是面向业务定制的应用数据。下面详细介绍这三层的设计。

（2）数据模型的分层

1）源数据层（ODS）

此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。

2）数据仓库层（DW）

也称为细节层，DW 层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。

此层可以细分为三层：

明细层DWD（Data Warehouse Detail） ：存储明细数据，此数据是最细粒度的事实数据。该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。

中间层DWM（Data WareHouse Middle） ：存储中间数据，为数据统计需要创建的中间表数据，此数据一般是对多个维度的聚合数据，此层数据通常来源于DWD层的数据。

业务层DWS（Data WareHouse Service） ：存储宽表数据，此层数据是针对某个业务领域的聚合数据，业务层的数据通常来源与此层，为什么叫宽表，主要是为了业务层的需要在这一层将业务相关的所有数据统一汇集起来进行存储，方便业务层获取。此层数据通常来源与DWD和DWM层的数据。

在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。

3）数据应用层（DA 或 APP）

前端应用直接读取的数据源；根据报表、专题分析的需求而计算生成的数据。

4）维表层（Dimension）

最后补充一个维表层，维表层主要包含两部分数据：

A）高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

B）低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

（3）问题扩展

数据仓库系统架构

上图系统各部分的执行流程是：

1）确定分析所依赖的源数据。

2）通过ETL将源数据采集到数据仓库。

3）数据按照数据仓库提供的主题结构进行存储。

4）根据各部门的业务分析要求创建数据集市（数据仓库的子集）。

5）决策分析、报表等应用系统从数据仓库查询数据、分析数据。

6）用户通过应用系统查询分析结果、报表。

（4）结合项目中使用

电商网站的数据体系设计，这里针对用户访问日志这一部分数据进行举例说明:

在ODS层中，由于各端的开发团队不同或者各种其它问题，用户的访问日志被分成了好几张表上报到了我们的ODS层。

为了方便大家的使用，我们在DWD层做了一张用户访问行为天表，在这里，我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面，统一字段名，提升数据质量，这样就有了一张可供大家方便使用的明细表了。

在DWM层，我们会从DWD层中选取业务关注的核心维度来做聚合 *** 作，比如只保留人、商品、设备和页面区域维度。类似的，我们这样做很多个DWM的中间表。

然后在DWS层，我们将一个人在整个网站中的行为数据放到一张表中，这就是我们的宽表了，有了这张表，就可以快速满足大部分的通用型业务需求了。

最后，在APP应用层，根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。