规范化通常导致表与“现实世界”中的实体不对应,它将“现实世界”中的实体分割成几张表来显示,以物理
表示法来反映实体结构,这样效率会比较差,常常要在
查询处理中进行很多连接操作。
关系模型表达数据和数据间关系的构造只有一种——表。例如,为了表达实体a和实体b之间的
多对多(*:*)关系、我们需要创建三张表,两个分别用于表达实体a和b,第三张表用于表达实体间的关系。它没有一种机制来区分实体和关系,也无法区分在实体间存在的不同种类的关系。例如,一个1:*关系可能是has、supervises、manages等等。如果可以进行区分,也许我们就可以将语义构建到操作中。所以,我们说关系模型语义过载了。
很多商业化系统不能完全支持实体和参照完整性、域等业务规则,所以需要将它们内置到应用程序中。这样当然是危险的,而且容易导致做重复的工作。更糟糕的是,可能还会引起不一致现象。而且,在关系模型中不支持其他类型的业务规则,这又意味着它们需要被构建到
dbms或应用程序中。
关系模型的
数据结构非常单一。在关系模型中,现实世界的实体以及实体间的各种联系均用关系来表示。在用户看来,关系模型
中数据的
逻辑结构是一张二维
数据表。
关系模型中常用的关系操作包括:选择(select)、投影(project)、连接(join)、除(Divide)、并(Union)、交(Intersection)、差(Difference)等查询(
Query)操作和增加(Insert)、删除(Delete)、修改(Update)操作两大部分。查询的
表达能力是其中最重要的部分。
关系操作的的特点是集合操作方式,即操作的对象和结构都是集合。这种操作方式也称为一次一集合(set-at-a-time)的方式。相应地,非关系数据模型的
数据操作方式则为一次一记录(
record-at-a-time)的方式。
早期的
关系操作能力通常用代数方式或逻辑方式来表示,分别称为关系代数和
关系演算。
关系代数是用对关系的运算来表达查询要求的方式。关系演算是用谓词来表达查询要求的方式。关系演算又可按
谓词变元得基本对象是
元组变量还是域变量分为
元组关系演算和
域关系演算。关系代数、元组关系演算和域关系演算三种语言在表达能力是完全等价的。
关系代数、元组关系演算和域关系演算均是抽象的
查询语言,这些抽象的语言与具体的DBMS中实现的实际语言并不完全一样。但它们能用作评估实际系统中查询
语言能力的标准或基础。实际的查询语言除了提供
关系代数或
关系演算的功能外,还提供了许多
附加功能,例如
集函数、关系赋值、算数运算等。
关系语言是一种高度非过程化的语言,用户不必请求DBA为其建立特殊的
存取路径,存取路径的选择由DBMS的优化机制来完成,此外,用户不必求助于
循环结构就可以完成数据操作。
关系模型允许定义三类
完整性约束;
实体完整性、
参照完整性和用户定义的完整性。其中实体完整性和参照完整性是关系模型必须满足的完整性
约束条件,体现了具体领域中的语义约束。
实体完整性规则:若属性A是基本关系R的
主属性,则属性A不能取
空值。实体完整性规则规定基本关系的所有主属性都不能取空值,而不仅是
主码整体不能取空值。
(1)实体完整性规则是针对基本关系而言的。一个基本表通常对应现实世界的一个
实体集。例如学生关系对应于学生的集合。
(4)主码中的属性即主属性不能取空值。所谓空值就是“不知道”或“无意义”的值。如果主属性取空值,就说明存在某个不可标识的实体,即存在不可区分的实体。这与第(2)点相矛盾,因此这个规则成为
实体完整性。
参照完整性规则:若属性(或属性组)F是基本关系R的
外码,它对于基本关系S的主码K相对应(基本关系R和S不一定是不同的关系),则对于R中的每个
元组在F上的值必须为:或者取空值(F的每个
属性值均为空值);或者等于S中某个元组的主码值。
用户定义的完整性就是针对某一具体
关系数据库的约束条件。它反映某一具体应用所涉及的数据必须满足的语义要求。例如某个属性必须取唯一值、某些属性值之间应满足一定的
函数关系、某个属性的
取值范围在0~100之间等。关系模型应提供定义和检验这类完整性的机制,以便于用统一的系统的方法处理他们,而不要由
应用程序承担这一功能。