层次数据库模型
层次模型以树状结构表示数据,其中每个记录只有一个父节点。为了维护顺序,存在一个排序字段,将兄弟节点以记录的方式保存。这些类型的模型主要设计用于早期的主机数据库管理系统,例如 IBM 的信息管理系统 (IMS)。
这种模型结构允许两种/多种类型的数据之间的一对一和一对多关系。这种结构在描述现实世界中的许多关系方面非常有用;目录,任何嵌套和排序的信息。
层次结构用作存储中记录的物理顺序。可以通过使用与顺序访问相结合的指针,向下遍历数据结构来访问记录。因此,当每个记录也没有包含完整路径时,层次结构不适用于某些数据库操作。
此类数据库中的数据按层次结构组织,通常开发为倒置树。"根"在结构中是数据库中的单个表,其他表充当从根流出的分支。下图显示了一个典型的层次数据库结构。

代理数据库
在上图中,一个代理预订了几个演艺人员,而每个演艺人员反过来都有自己的日程安排。代理的职责是维护几个需要满足娱乐需求的客户。客户通过代理预订活动,并向代理支付其服务费用。
在此数据库模型中,关系由术语父/子表示。父表可以与此类关系中的一个或多个子表链接,但单个子表只能与一个父表链接。表通过指针/索引或表中记录的物理排列明确链接。
用户可以通过从根表开始并向下遍历树到目标数据来访问数据。用户必须熟悉数据库的结构才能在没有任何复杂性的情况下访问数据。
优点
- 由于表结构之间存在显式链接,因此用户可以非常快速地检索数据。
- 引用完整性是内置的并自动执行的,因此子表中的记录必须链接到父表中的现有记录,并且如果父表中的记录被删除,则这也会导致子表中所有关联记录也被删除。
缺点
- 当用户需要在当前与父表中的任何记录无关的子表中存储记录时,记录会很困难,并且用户必须在父表中记录其他条目。
- 这种类型的数据库无法支持复杂的关系,并且还存在冗余问题,这可能导致由于在各个站点不一致地记录数据而产生不准确的信息。
考虑使用前面图中所示的数据库图的示例。在演艺人员表中,用户无法为演艺人员输入新记录,除非演艺人员被分配给代理表中的特定代理,因为子表(演艺人员)中的记录必须与父表(代理)中的记录相关。因此,这种类型的数据库存在冗余数据的问题。例如,如果客户和演艺人员之间存在多对多关系;一个演艺人员将为许多客户表演,而一个客户将聘用许多演艺人员。层次数据库中无法轻松地建模此类关系,因此开发人员必须在日程安排和活动表中引入冗余数据。
- 日程安排表现在将包含客户数据,其中包含客户姓名、地址和电话号码等信息,以显示每个演艺人员为谁以及在哪里表演。此数据是冗余的,因为它当前也存储在客户表中。
- 活动表现在将包含有关演艺人员的数据,其中包含演艺人员姓名、电话号码和演艺人员类型等信息,以指示哪些演艺人员正在为特定客户表演。此数据也是冗余的,因为它当前存储在演艺人员表中。
此冗余问题在于它可能导致产生不准确的信息,因为它打开了允许用户不一致地输入单个数据片的可能性。
可以通过为演艺人员创建一个层次数据库,为代理创建另一个层次数据库来解决此问题。演艺人员数据库仅包含演艺人员表中记录的数据,而修订后的代理数据库将包含代理、客户、付款和活动表中记录的数据。不需要,因为您可以定义代理数据库中活动表与演艺人员数据库中演艺人员表之间的逻辑子关系。有了这种关系,您可以检索各种信息,例如给定客户的预订演艺人员列表或给定演艺人员的演出时间表。下图描述了整个画面。

层次数据库非常适合 20 世纪 70 年代大型机使用的磁带存储系统,并且在数据库基于这些系统的组织中非常流行。但是,即使层次数据库提供了快速且直接的数据访问,并且在多种情况下都很有用,但很明显需要一个新的数据库模型来解决日益严重的数据冗余和数据之间复杂关系的问题。
此数据库模型背后的思想对于某种类型的数据存储很有用,但它并不十分通用,并且仅限于某些特定用途。
例如,在公司中,每个个人都可能向特定部门报告,则可以使用部门作为父记录,而个人员工将代表辅助记录,每个记录都链接回层次结构中的该一个父记录。
数据结构
网络
关系型数据库管理系统
操作系统
Java
iOS
HTML
CSS
Android
Python
C 编程
C++
C#
MongoDB
MySQL
Javascript
PHP