数据库基本概念
引言
本章的目标是讲解数据库研究人员常常要使用到的一些理论和术语。

我所在的工作组集中了一批以开发性能优异的数据库系统为谋生手段的精英，数据库理论乍看起来与我们的具体工作相距甚远。

是否很有必要学习有关数据库理论方面的知识可能是留给你思考的一个问题。

我们说，理解一种技术的基本原理是非常重要的。

这就好比把你的汽车交给一个不懂火花塞工作原理的机械师，或是坐在一架由不懂飞行理论的驾驶员的飞机上。

如果你不懂数据库设计的相关理论，又怎能指望用户登陆门请你设计系统呢？
研究人员所用的某些术语和概念令我们感到困惑，部分原因是数学基础的问题。

有一些术语，大多数程序员理解为一种含义，而实际上是完全不同的另一种含义。

为了能设计合理的系统，了解关系数据库理论是十分重要的。

为了搞清楚研究人员的专业术语，我们需要学习一些关系数据库理论中较浅显的内容，并且同我们所熟知的SQL概念进行比较。

许多书中都讲解了这些内容，所以并不打算过于深入地探讨理论。

我们只提供一些基本且实用的数据库概念。

本章将主要从面向SQL的角度介绍关系理论。

我们将常常涉及相关理论的具体实现，尽管这超出了本书的范围，但却是难以避免的。

然而我们不会陷入实现的细节，仅仅给出一个概述。

更进一步的内容，参看第一章提到的参考书目。

在本章中，我们将会看到下列内容：
☐关系模型——考察相关的技术术语：我们将在后面的章节中构造它们
☐其他数据库概念的定义
关系模型
正像第1章中提到的，E.F.Codd早在1970年就提出了关系模型的概念。

在这一节中，我们将从SQL Server 的角度出发，考察一些在关系模型中比较重要的内容。

正像我们所看到的那样，SQL Server 与关系模型有很多共性的东西，但
也有一些微小的差别。

许多关系学派的学者阿谀奉承各类SQL（不仅是Micrsoft 的SQL Server）的实现。

本书并不去讨论它们中的每一个，我们将回避有关这些问题的争论，而只讨论SQL Server 的物理设计和实现部分的内容。

数据库
我们需要定义的第一个术语是数据库。

简单地说，数据库是一个为了能够无约束且快速检索而排列起来的数据集合。

这可能是图书馆的卡片目录，SQL Server 数据库或文本文件。

严格地讲，在关系理论中并没有这个概念，但是由于我们需要频繁地使用这个术语，所以在此介绍它是有必要的
在SQL Server中，数据库是逻辑地组织在一起的对象和数据的集合。

表
在关系模型中，有一个非常普遍的错误概念就是认为关系是指表之间的关系。

实际上，我们所说的关系（relation）与表这个术语几乎是同义词。

正像我们所看到的，关系模型所使用的不同命名不仅有大多数程序员最初就知道的表，而且还有包含在表中的元素。

我们处理的最主要的元素是表本身。

表是现实世界或虚拟世界中一些对象的物理描述。

在设计表时，你需要关注希望存储的信息，比如，人、地点和物。

为了设计一个正确的表以及它所包含的对象。

表这个术语很早就有，当时的含义是这样的：
表是数据的有序排列。

强调其数据必须按行和列排成一个矩形。

有两种普遍使用的表格：Excel电子数据报表和对Northwind数据库进行一次简单的SQL查询所得到的结果。

如图3-1所示：
图3-1
其实在出现计算机电子数据表格之前，人们在工作中使用的纸张就带有行和列（只是我们没有将它称做电子数据表格）。

在本章节的稍后部分我们将更加深入地探讨行和列。

正像我们在前面提到的，表通称为关系，或者更明确地称为被命名了的关系。

如同我们在稍后讨论的一样，表和视图都被认为是命名了的关系，而结果集被认为是没有命名的关系。

弄清这一点有助于你编写更好的SQL。

表3-1只是定义了很少几列用以描述有一个最普通的饭店内容。

在本章中，表中的每一项都被详细地定义。

在这里并没有指出表和关系是完全相同的含义。

下面是关系的定义：
关系：是属性和元组（tuples）的复合结构，其中属性是指独立的特性，比如，姓名和地址，在表中对应列；元组是指用来描述特定实体（比如，雇员）的属性值的集合，在表中对应行。

在一个关系中，元组不能重复，每一行的内容必须能够被惟一确定。

而且，在一个关系中，元组是没有顺序关系的；交换两个元组的位置不会改变关系。

这个定义在此刻看起来可能有些让人迷惑。

请不必担心，学习完本章后，一切问
题都将迎刃而解。

关系是基于集合论的一个十分严格的数学概念。

表是具有特定性质的关系的物理实现，即所有的表都可以用关系来定义，但并不是所有的关系都可以定义成表。

然而，对于一般的数据库程序员来说，这两个概念的差别确实十分微小。

我们将使用的另一个术语是表中的实体（entity）。

实体这个术语在逻辑模型中频繁使用，逻辑模型是指表的概念版本。

我个人很喜欢这个术语，这是由于它强调：表实际上事物的描述。

“表”与计算机学科之外的含义完全不同，它是一个十分严格的术语。

当我第一次告诉妻子，我创建了一张表，她认为我这个教授可能在说谎，“你用计算机创建表格？”。

确定实体只需要花费很少的时间，而且没有什么约束条件。

在下一章定义表时，我们将首先定义概念化的实体，以避免陷入表本身的结构中。

行与列
行（即记录）表示表中被物理描述的对象实例。

实例的概念与面向对象程序设计有关，但是，在关系的程序设计中会有不同的处理方式。

在面向对象（OO）程序设计（甚至OO数据库）中，类定义通常包含属性和方法，方法可以对类的某个特定实例实施操作，而实例通常被认为就是对象。

在SQL Server中，我们处理的表包含行和列，表的定义与OO中的类定义非常相似，表中的一行就是一个特定实例，它与对象类似。

在表中，没有为维护数据专门实现的方法，我们用能够与表中数据相互作用的专门的SQL操作实现。

实际上，区别它们的只要原因是实现。

由于SQL是为存取数据创建的，所以在任何时刻，都可以轻而易举地查看多个SQL对象的实例，而许多程序员却忘记OO对象与SQL Server中的行同义。

当我们在后面章节中更深入地探讨数据和对象模型后，就会清楚OO方法和关系数据库程序设计的相似之处了。

正像我们从表3-2中所看到的，关系模型中的行和列有着各自不同的名称。

行被称做元组，列被称做属性。

元组是一个比较有趣的技术术语，它可能使你停下来进行思考，也可能使你嬉笑（我就是这样）。

“元组”这个词并没有其他的含义，甚至有可能在一些字典中找不到它。

大概由于这个词没有确切的含义，所以在构造Codd的关系模型时选用了这个词，这样可以避免像表这样的术语产生混淆。

元组这个术语似乎并没有引起许多程序设计人员的关注，而将每列描述的内容称做属性却众所周知。

每列应该包含行即元组的实例特征即属性，或者更简单的说明，每列包含描述行的一个属性。

当我们这样看待列时，它就有了更多的含义，任何从事过OO程序设计的人都可以得到这样的结论：它与OO有很多特性相似之处。

关系理论有一个原则就是属性没有顺序。

你可能已经从实践中得到证实：在一个表中，列是没有先后顺序的，所以当SQL用户希望返回一个固定的列集时，不必提及列必须有效地存储在物理媒介上。

在这里，最重要的一点是你永远不要指出列的物理顺序。

在设计表时，对于数据排列的顺序有几个基本的习惯，例如：主码在表的左侧，后面跟随着比较重要的列，较少读取的数据放在表的右侧，但这只是程序员或用户的习惯。

在第5章中，我们将开始实际地设计表，到那时，我们再对此做更进一步讨论。

在表中，每一行包含相同的列集。

特定表中的每一列的名字必须惟一。

这一点是显而易见的，但还是有必要提一下。

我们需要讨论的最后一个术语是关系的度（degree），对应的是表中的列数。

这个术语使用的并不很多，但是我在一些文档中看到过它，为完整起见，在这里给出这个术语。

属性的特性
将本节这样命名使我自己都感到发笑。

然而，在一个表中，每一列又有若干特性。

最重要的是：
列的合法值
列是否是行标识的一部分
列值是必须的，还是可选的
在下面几节中，我们将更详细地讨论这些内容。

限定列的取值
SQL Server表提供了几种对进行列中的数值进行限制的方法：
☐（基本的）数据类型
☐用户定义的数据类型
☐约束条件
☐触发器和存储过程
☐。