分层数据库模型
分层模型以树状结构表示数据，其中每个记录都有一个父项。为了保持顺序，有一个排序字段使兄弟节点保持记录状态。这些类型的模型基本上是为早期大型机数据库管理系统设计的，例如IBM的信息管理系统(IMS)。
这种模型结构允许两种/各种类型的数据之间一对一和一对多的关系。这种结构对于描述现实世界中的许多关系非常有帮助。目录，任何嵌套和排序的信息。
分层结构用作存储中记录的物理顺序。可以通过使用与顺序访问相结合的指针向下浏览数据结构来访问记录。因此，当没有为每个记录也包括完整路径时，层次结构不适合某些数据库操作。
这种类型的数据库中的数据是分层结构的，通常被开发为倒置树。结构中的“根”是数据库中的单个表，其他表充当从根流出的分支。下图显示了典型的分层数据库结构。
代理商数据库
在上图中，代理预定了几个演艺人员，而每个演艺人员都有自己的日程安排。代理人有责任维持几个需要满足娱乐需求的客户。客户通过代理商预订业务，并向代理商付款以获取其服务。
此数据库模型中的关系由术语“父/子”表示。父表可以与这种类型的关系中的一个或多个子表链接，但是单个子表只能与一个父表链接。这些表通过指针/索引或表中记录的物理排列显式链接。
用户可以通过从根表开始并遍历树直到目标数据来访问数据。用户必须熟悉数据库的结构才能访问数据而没有任何复杂性。
好处
由于表结构之间存在显式链接，因此用户可以非常快速地检索数据。
参照完整性是内置的，并且会自动强制执行，因此必须将子表中的记录链接到父表中的现有记录，并且如果在父表中删除了一条记录，则会导致所有关联记录子表也将被删除。
缺点
当用户需要将记录存储在当前与父表中的任何记录都不相关的子表中时，记录会变得很困难，并且用户必须在父表中记录其他条目。
这种类型的数据库不能支持复杂的关系，并且还存在冗余的问题，由于在各个站点上记录的数据不一致，可能导致产生不正确的信息。
考虑一个使用上图所示数据库图的示例。在将娱乐者分配给Agents表中的特定业务代表之前，用户无法在Entertainers表中输入该娱乐者的新记录，因为子表(Entertainers)中的记录必须与父表(Agents)中的记录相关。因此，这种类型的数据库存在冗余数据的问题。例如，如果客户和演艺人员之间存在多对多关系；一个艺人会为许多客户表演，一个客户会雇用许多艺人。分层数据库中的这种类型的关系无法轻松建模，因此开发人员必须将冗余数据引入Schedule和Engagements表中。
Schedule表现在将包含客户数据，其中包含诸如客户名称，地址和号码之类的信息，以显示每个演艺人员为谁表演和在哪里表演。该数据是冗余的，因为当前它也存储在“客户端”表中。
现在，“参与度”表将包含有关演艺人员的数据，其中包含诸如演艺人员姓名，号码和演艺人员类型之类的信息，以指示哪些演艺人员正在为给定的客户表演。此数据也是多余的，因为它当前存储在Entertainers表中。
这种冗余的问题在于，这可能会导致产生不正确的信息，因为它打开了允许用户不一致地输入单个数据的可能性。
通过创建一个专门用于娱乐人员的分层数据库和另一个专门用于代理的数据库，可以解决此问题。“艺人”数据库将仅包含“艺人”表中记录的数据，而修订后的“特工”数据库将包含“特工”，“客户”，“付款”和“订婚”表中记录的数据。不需要，因为您可以在Agents数据库中的Engagements表和Entertainers数据库中的Entertainers表之间定义逻辑子关系。有了这种关系，您就可以检索各种信息，例如给定客户的已预订演艺人员列表或给定艺人的表演时间表。下图描述了整个图片。
分层数据库非常适合于1970年代大型机使用的磁带存储系统，并且在基于这些系统的组织中非常流行。但是，即使分层数据库提供了对数据的快速直接访问，并且在某些情况下很有用，但是很明显，仍需要一种新的数据库模型来解决日益增长的数据冗余和数据之间复杂关系的问题。
该数据库模型的思想对于某种类型的数据存储很有用，但是它并不是非常通用，并且仅限于某些特定用途。
例如，公司中的每个人都可以向给定部门报告，则该部门可以用作父记录，而各个员工将代表次要记录，每个记录都以层次结构链接回该父记录。
以上是 分层数据库模型 的全部内容， 来源链接： utcz.com/z/348982.html
