Understanding the Hierarchical Database Model
了解分层数据库模型
The earliest model was the hierarchical database model, resembling an upside-down tree. Files are related in a parent-child manner, with each parent capable of relating to more than one child, but each child only being related to one parent. Most of you will be familiar with this kind of structure—it’s the way most file systems work. There is usually a root, or top-level, directory that contains various other directories and files. Each subdirectory can then contain more files and directories, and so on. Each file or directory can only exist in one directory itself—it only has one parent. As you can see in the image below A1 is the root directory, and its children are B1 and B2. B1 is a parent to C1, C2, and C3, which in turn has children of its own.
最早的模型是分层数据库模型，类似于颠倒的树。文件以亲子方式关联，每个父母都可以关联多个孩子，但是每个子只关联一个父母。你们中的大多数人都将熟悉这种结构，这是大多数文件系统工作的方式。通常有一个根目录或顶层目录，其中包含其他各种目录和文件。然后，每个子目录可以包含更多文件和目录，依此类推。每个文件或目录本身只能存在于一个目录中，只有一个父目录。如下面的图像所示，A1是根目录，其子级是B1和B2。B1是C1的父级，C2和C3，后者又拥有自己的孩子。
This model, although being a vast improvement on dealing with unrelated files, has some serious disadvantages. It represents one-to-many relationships well (one parent has many children; for example, one company branch has many employees), but it has problems with many-to-many relationships. Relationships such as that between a product file and an orders file are difficult to implement in a hierarchical model. Specifically, an order can contain many products, and a product can appear in many orders. Also, the hierarchical model is not flexible because adding new relationships can result in wholesale changes to the existing structure, which in turn means all existing applications need to change as well. This is not fun when someone has forgotten a table and wants it added to the system shortly before the project is due to launch! And developing the applications is complex because the programmer needs to know the data structure well in order to traverse the model to access the needed data. As you’ve seen in the earlier chapters, when accessing data from two related tables, you only need to know the fields you require from those two tables. In the hierarchical model, you’d need to know the entire chain between the two. For example, to relate data from A1 and D4, you’d need to take the route: A1, B1, C3 and D4.
尽管该模型在处理不相关文件方面进行了巨大改进，但存在一些严重的缺点。它很好地代表了一对多的关系（一个父母有很多孩子；例如，一个公司分支有很多雇员），但是它在多对多关系方面存在问题。产品文件和订单文件之间的关系很难在层次模型中实现。具体来说，一个订单可以包含许多产品，而一个产品可以出现在许多订单中。同样，分层模型也不灵活，因为添加新的关系可能导致对现有结构的全面更改，这又意味着所有现有应用程序也需要更改。当有人忘记了一个表并希望在项目启动前不久将其添加到系统中时，这就不好玩了！而且开发应用程序很复杂，因为程序员需要充分了解数据结构才能遍历模型以访问所需的数据。正如您在前面的章节中所看到的那样，当从两个相关表中访问数据时，您只需要知道这两个表中所需的字段即可。在分层模型中，您需要了解两者之间的整个链。例如，关联来自A1和D4，您需要采用以下路线：A1，B1，C3和D4。
