层次数据库模型
层次模型以树状结构表示数据，其中每条记录都有一个父级。为了保持顺序，有一个排序字段，用于按记录方式保存兄弟节点。这类模型主要用于早期的大型机数据库管理系统，例如 IBM 的信息管理系统 (IMS)。
这种模型结构允许两种/不同类型的数据之间建立一对一和一对多的关系。这种结构在描述现实世界中的许多关系方面非常有用;例如目录、任何嵌套和排序的信息。
层次结构用作存储中记录的物理顺序。可以使用指针结合顺序访问，在数据结构中向下导航来访问记录。因此，当每条记录未包含完整路径时，层次结构不适用于某些数据库操作。
此类数据库中的数据采用层次结构，通常以倒置树的形式构建。结构中的"根"是数据库中的单个表，其他表则作为从根延伸出来的分支。下图展示了一个典型的层次数据库结构。
经纪人数据库
在上图中，经纪人预订了多位艺人，而每位艺人都有自己的日程安排。经纪人的职责是维护多位需要满足娱乐需求的客户。客户通过代理预约，并向代理支付服务费。
此数据库模型中的关系用"父/子"表示。在这种关系中，一个父表可以与一个或多个子表链接，但一个子表只能与一个父表链接。这些表通过指针/索引或表内记录的物理排列显式链接。
用户可以从根表开始，沿着树向下访问目标数据。用户必须熟悉数据库结构才能轻松访问数据。
优点
- 由于表结构之间存在显式链接，用户可以非常快速地检索数据。
- 引用完整性是内置的，并自动强制执行，因此子表中的记录必须链接到父表中的现有记录，并且如果父表中删除一条记录，则会导致子表中的所有关联记录也将被删除。
缺点
- 当用户需要在子表中存储当前与父表中的任何记录均不相关的记录时，记录会变得困难，用户必须在父表中记录额外的条目。
- 这种类型的数据库无法支持复杂的关系，并且还存在冗余问题，这可能导致由于各个站点的数据记录不一致。
考虑使用上图所示数据库图表的示例。由于子表(艺人)中的记录必须与父表(代理)中的记录关联，因此用户无法在"艺人"表中为艺人输入新记录，直到该艺人被分配给"代理"表中的特定代理。因此，这种类型的数据库存在数据冗余的问题。例如，如果客户和艺人之间存在多对多关系，则一个艺人会为多个客户表演，而一个客户也会雇佣多个艺人。在分层数据库中，这种关系难以建模，因此开发人员必须在"日程安排"表和"参与"表中引入冗余数据。
- 现在，"日程安排"表将包含客户数据，其中包含客户姓名、地址和电话号码等信息，以显示每个艺人为谁表演以及在何处表演。这些数据是多余的，因为它目前也存储在"客户"表中。
- "活动"表现在将包含艺人的数据，其中包含艺人姓名、电话号码和艺人类型等信息，以指示哪些艺人正在为特定客户表演。这些数据也是多余的，因为它目前存储在"艺人"表中。
这种冗余的问题在于，它可能导致信息不准确，因为它有可能允许用户输入不一致的单条数据。
可以通过创建一个专门用于艺人的分层数据库和另一个专门用于经纪人的分层数据库来解决此问题。"艺人"数据库将仅包含"艺人"表中记录的数据，而修改后的"经纪人"数据库将包含"经纪人"、"客户"、"付款"和"活动"表中记录的数据。无需这样做，因为您可以在"代理"数据库中的"约定"表和"娱乐者"数据库中的"娱乐者"表之间定义逻辑子关系。通过此关系，您可以检索各种信息，例如，为特定客户预订的娱乐者列表或特定娱乐者的演出时间表。下图描述了整个情况。
层次结构数据库非常适合 20 世纪 70 年代大型机使用的磁带存储系统，并且在基于这些系统的数据库的组织中非常流行。但是，尽管分层数据库提供了快速、直接的数据访问，并且在多种情况下非常有用，但显然需要一种新的数据库模型来解决日益严重的数据冗余和数据间复杂关系问题。
这种数据库模型背后的理念对于特定类型的数据存储很有用，但它的功能并不十分强大，并且仅限于某些特定用途。
例如，如果公司中的每个人都可能向某个部门汇报，则该部门可以用作父记录，而各个员工将代表二级记录，每个二级记录都以分层结构链接回该父记录。
