重新审视Codasyl模型及ANSI网络模型标准

### 重新审视 Codasyl 模型及 ANSI 网络模型标准 #### 1. Codasyl 模型概述 Codasyl 模型规模庞大，具备众多规范设施，支持三级模式架构，不过这些层级与 ANSI/SPARC 的定义并非完全对应，且该模型缺少查询语言和数据字典工具。尽管如此，它仍是一种主流的数据模型，预计会长期被使用，就像 Cobol 和 Fortran 语言一样。 #### 2. Codasyl 模型各部分分析 ##### 2.1 模式（Schema） - **理论基础缺失**：Codasyl 模式基于记录和集合构建网络数据模型，但缺乏理论基础，导致其发展不均衡且不一致。该模型由委员会制定，修改和增强往往源于个别临时提案，而非基于完善的形式化模型需求。 - **记录键问题**：记录键提案虽获通过，但更多是因为提案者展示了其可能的应用示例，而非基于记录应具备独立于集合类型的访问路径这一原则。存储相关的记录键既过时又具局限性，理想情况下应在存储模式中声明，而非模式中。由于 1981 年的 Cobol JoD 和 ANSI 不允许使用记录键，未来 Codasyl 模型实现中包含记录键的可能性较低。 - **集合顺序准则**：集合顺序准则存在争议，多数选项代表访问路径，可从模式中移除，以简化模式且不损失建模能力。集合选择准则在模式中也不必要，应留给子模式由用户指定所需的选择路径。 - **多成员集合类型**：多成员集合类型引发诸多批评，单成员集合类型理论上更具吸引力，多成员集合类型编程繁琐，且会使 Codasyl 集合结构复杂化。不过，也有部分人支持多成员集合类型。 以下是集合顺序准则的相关情况总结： | 准则类型 | 特点 | 是否必要 | | ---- | ---- | ---- | | 排序选项 | 由成员记录的数据项组成的键定义，信息已存在于数据库中 | 否 | | 位置集合顺序准则 - 时间顺序 | 不允许在队列中间插入，不适合存储/更新基本信息 | 否 | | 位置集合顺序准则 - 相邻顺序 | 可将顺序信息存储在显式记录中，并非必须使用集合顺序准则 | 否 | ##### 2.2 子模式（Subschema） 子模式为 Cobol 和 Fortran 用户提供了一定服务，但缺乏高级查询语言是严重缺陷。此前对当前指示符的批评表明，有必要废除它们，采用 1975 年 IBM 的 R. W. Engles 提出的用户定义和用户控制的游标。 ##### 2.3 存储模式（Storage schema） 存储模式旨在提供以下功能： - 独立于模式，便于进行数据库重组。 - 独立于操作系统和物理存储，允许在不同环境中使用相同的存储模式。不过，使用用户定义的页面大小作为磁盘访问单位时，非磁盘访问单位倍数的任意页面大小可能成本较高。 - 具备重组功能。 - 保证操作效率。但存储系统的效率不仅取决于存储模式，还与操作系统和物理设备的特性有关，且 DSDL 过于复杂，难以清晰评估不同功能选择的整体影响。 ##### 2.4 支持特性 - **并发使用**：允许并发使用，可在领域和页面上设置锁，并支持 COMMIT/ROLLBACK 功能。 - **完整性控制**：模式和子模式通过 CALL 和 CHECK 子句实现完整性控制，集合成员子句可视为集合类型的完整性约束。 - **访问控制**：提供了较好的访问控制功能。 - **数据字典**：虽认识到数据字典的需求，但未将其视为模型的一部分，而是由实现者提供支持。 - **对小用户的适用性**：该模型对小用户而言过于复杂，简单的子集可能更具吸引力。 #### 3. 记录选择格式的演变 - **1975 年 Cobol JoD**：记录选择格式 1 在记录放置由 Location Mode Direct 定义时，允许通过数据库键直接访问；格式 2 允许通过 Calc 键直接访问。 - **1978 年 Cobol JoD**：引入记录键概念，移除 Areas/Location - mode/user -