| 前面定义的第一范式（1NF）是指关系模式中的属性是不可再分的，即原子的。然而，并不是所有的应用都是用1NF建模最好。例如，某些应用的用户将数据库视为对象（或实体）的一个集合，而不是记录的一个集合，这些对象可能需要若干条记录来表示。重要的是，如何在一个简单、易用的界面上体现用户直观概念上的一个对象与数据库系统概念上的一个数据项之间的一一对应关系。
|
|
|
| 嵌套关系模型（Nested Relational Model）是关系模型的一个扩展，域可以是原子的也可以赋值为关系。这样元组在一个属性上的取值可以是一个关系，于是关系可以存储在关系中。从而一个复杂对象就可以用嵌套关系的单个元组来表示。如果我们将嵌套关系的一个元组视为一个数据项，在数据项和用户数据库观念上的对象之间就有了一个一一对应的关系。
|
|
|
| 下面通过一个图书馆的例子来说明嵌套关系。假定对每本书存储如下信息：
|
|
|
|
|
| 如果为上面这些信息定义一个关系，下列一些域将是非原子的：
|
|
|
| （1）作者。一本书可能有一组作者，然而，我们可能想要寻找作者之一是Jones的所有书，这样我们就对域元素“作者集合”的一个子部分感兴趣。
|
|
|
| （2）关键字。如果我们为一本书存储了一组关键字，我们希望能够检索出关键字包含该集合中的一个或多个关键字的所有书，这样，我们就将关键字集合域视为非原子的。
|
|
|
| （3）出版社。与关键字和作者不同，出版社没有一个以集合为值的域。但是，我们可能将出版商视为由名字和分支机构这两个子字段组成的，这种观念使得出版商域成为非原子的。
|
|
|
|
|
|
|
| 上图表示了一个示例关系books，books关系可以用1NF表示，如下图所示。由于在1NF中我们只能有原子的域，然而我们又想要访问单个的作者和单个的关键字，我们对每个（关键字，作者）对都需要一个元组，出版商属性在1NF版本中被两个属性所取代：它们分别对应于出版商的每个子字段。
|
|
|
|
|
|
|
|
|
|
|
|
|
| .title→pub-name，pub-branch
|
|
|
| 我们可以使用下面的模式将这个关系分解成4NF，使得上图中flat-books关系的冗余就可以去除。下图显示了上图中的flat-books关系到上述分解的映射。
|
|
|
|
|
|
|
| .books4（title，pub-name，pub-branch）
|
|
|
|
|
|
|
| 管不用嵌套关系也足以表达上述示例书籍数据库，但是嵌套关系可以产生一个更易理解的模型：一个信息检索系统的典型用户根据具有作者集的书将该数据库看成一个非1NF的设计模型。4NF设计会要求用户在他们的查询中包含连接操作，因此使得与系统的交互复杂化。
|
|
|
| 我们可以设计一个无嵌套的关系视图（它的内容与flat-books一样）来免除用户在他们的查询中编写连接操作的需要，然而在这样的视图中，我们却失去了元组与书之间的一对一的对应。
|
|
|
| 面向对象数据库系统支持面向对象数据模型，是一个持久的、可共享的对象库的存储和管理者，而一个对象库是由一个OO模型所定义的对象的集合体。
|
|
|
| 对象：是由一组数据结构和在这组数据结构上的操作的程序代码封装起来的基本单位。对象之间的界面由一组消息定义。一个对象包括：属性集合、方法集合和消息集合。
|
|
|
| 对象标识：是指面向对象数据库中的每个对象都有一个唯一不变的标识。常用的几种标识有值标识、名标识和内标识。
|
|
|
| .值标识，使用一个值来标识，在关系数据库中通常使用这种形式的标识。例如，一个元组的主码标识了这个元组。
|
|
|
| .名标识，用用户提供的名称作为标识。这种形式的标识通常用于文件系统中的文件，不管文件的内容是什么，每个文件都被赋予一个名称来唯一标识。
|
|
|
| .内标识，是建立在数据模型或程序设计语言中内置的一种标识，不需要用户给出标识。面向对象系统中使用这种形式的标识，每个对象在创建时被系统自动赋予一个标识符。
|
|
|
| 封装：OO模型的一个关键概念就是封装。每一个对象是其状态和行为的封装。封装是对象的外部界面与内部实现之间实行清晰隔离的一种抽象，外部与对象的通信只能通过消息。
|
|
|
| 类：共享同样属性和方法集的所有对象构成了一个对象类（简称类）。例如，学生是一个类，黎明、张军、樊建喜是学生类中的一个对象。类是“型”，对象是“值”。
|
|
|
