数据库的层次结构

1、树状结构
在历史上，层次数据库最早出现，将数据库保存为文件中的记录，各种逻辑被嵌套到一起，而没有将同样的记录按照线性排列。层次数据库对某些查询非常适合，但是过强的结构限制了人们对数据的自由操控，后来出现的网络（CODASYL）数据库，虽然灵活了很多，但数据操控仍然很困难，知道关系型理论的出现，才证明的了数据库设计是科学而不是工艺，然而，因为层次模型很有弹性，所以层次结构依然极为常见（至少层次描述非常常见），例如XML和LDAP等层次技术非常活跃，严格的说HTML也算是一种层次存取数据的方式。
层次式数据不太容易理解，比如ERP系统中最基本的物料单，层次结构之所以复杂，主要原因不是因为组件之间的关系表达，而是访问树的方式，我们访问树的部分或全部节点，通常按照顺序返回这些节点，访问树通常由DBMS引擎以过程性方式实现，而过程性操作正是违背关系理论的主要表现之一。
2、树状结构和主从结构
很多人认为“父子关系”和“主从关系”没有什么不同，实际上这两种关系有着很多的不同。
1） 树状结构保存只需要一个表。代表层次结构的树，其所有节点完全相同，叶子节点的类型有时可能不同，例如文件系统中的文件夹和文件节点，如果撇去这点，所有的节点类型完全相同，我们可以用相同的方法描述，而且同一个表来代表节点，换句话说，表与它本身之间有种主从关系，而不是两个类型不同的表关系。
2）深度。层次结构中，与根节点的距离本身是重要的信息，而在主从关系中，不是主表就是明细表。
3）所有权。主从关系中，可以明确的外键完整性约束，例如，每个表中订单必须与另外一张表的已存在的ID对应，但层次结构，比如，虽然比如经理的工号虽然是参照已经存在的员工的工号规则来的，但是经理向老板报告，不跟员工报告，这会导致NULL值问题。
4）多重父节点。以父节点似乎别数据结合子节点，是假设一个子节点只有一个父节点，实际上生活中，很多情况下都不是这样，比如机械零件和螺丝钉，那就不是树了，父子关系就无能为力了。
其实某位大牛曾经说过：从关系理论角度去理解树的结构，树有两种实体类型，一个是节点，另一个是节点之间的连接。这样的设计世界上是解决了完整性约束的的问题，因为只有实际存在连结的节点才能被描述。这种描述实际上最后能描出一个图来，也就是能解决一个子节点对应多个父节点的问题。
DBMS厂商常常实现了空间数据处理或全文索引等特殊功能，但对层次结构的支持很薄弱或者根本没有。
处理层次结构的主要困难在于树的访问，当然仅仅为了在图形用户界面中显示树状结构，每次用户点击将树展开并没有什么问题