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

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

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