database system concepts

    关系数据库由一组表组成，每个表是一个被标记的独一无二的。例如，观察图2.1的教师表，它储存了大量的关于教师们的信息。那张表有4张数据域标题，学号，名字，课程名称，和工资。这张表的每行都记录了关于老师的信息。包括了身份证，名字，课程名称，和工资。类似的，那图2.2的表格储存了关于由资源名称，题目，课程名称，学分，对于每个名称。注意每位老师都是通过列id的值来标识的，而每一门课程都是由列课程id的值来标识的。

    图2.3展示了一个表，prerep，这储存了必先具备的课程。这张表有两列，课程名称，和prerep名称。每行由一双课程身份标识，例如，那第二课程是一个第一门课的先决条件。

然而，在那张表里的每行都表明了两个课程是在某种意义上相关的，就是一个课程是另一个课程的先决条件.

指定ID与名称、部门名称和工资对应价值之间的关系。
一般来说，表中的一行表示一组数值之间的关系。从关系数据模型的名字来看，由于表是这种关系的集合，表的概念与关系的数学概念有着密切的对应关系。在数学术语中，元组只是值的序列（或列表），是一个关系——关于n值之间的数学表示的值的元组，即具有n个值的元组，它对应于表中的一行。

因此，在关系模型中，术语Relationship用于引用表，而tuple则用于引用行。类似地，术语属性指表的一列。查看图2.1，我们可以看到关系指导员有四个属性：ID、Name、Det Name和工资。我们使用关系实例来引用关系的特定实例，即包含特定的行集。图2.1所示的讲师实例有12个元组，对应于12个教员。在本章中，我们将使用许多不同的关系来说明关系数据模型的各种概念。这些关系代表了大学的一部分。为了简化我们的演示，他们没有包括大学数据库中包含的所有数据。我们将在第7章和第8章中详细讨论关系结构是否合适的标准。元组在关系中出现的顺序是无关的，因为关系是一个集合。

那两张图是相同的，因为两者都包含了相同的元组。为了便于解释，我们将大力的展示被分类的他们的第一属性。

   对于每个关系的属性，都有一种被允许的价值叫做该属性的域。然而那教师关系的薪水的领域属性是一套所有可能的薪水价值，而且那名字属性的领域是一种所有可能的指令名的集合。

   我们要求，对于所有的关系，所有的属性的领域应该是自动的。一个领域是自动的，如果领域的要素被认为是不可分割的单位。例如，想象一下那教师表有一个电话号码的属性，它可以分一串的对应的电话号码给教师。然而那电话号码的领域将不会自动化，因为领域其中的一个要素是一串电话号码，它有元件，也就是说在集合中，它是必不可分的。

   那重要的问题不是领域本身自己，而是我们在我们的数据库中如何使用领域这个要素。 现在假设电话号码属性储存一个单一的电话号码。即使如此，如果我们把电话号码属性中的值拆分为国家代码，地区代码，和当地代码，我们将会把它当作一个非原子值。如果我们对待每个电话号码像作为一个不可分割的单元，那么那电话号码属性将有一个原子领域。

   在这篇文章中，也就是片段3第6部分，我们假定所有属性有原子领域。在片段22中，我们该讨论允许非原子域的关系数据模型。

   空值是一个特殊的值，表示该值未知或不存在。例如，在猜想之前，我们在教师关系里包括了电话号码属性。它可能是一个电话号码什么都没有的教师，或者那电话号码是没有列于表格的。我们将不得不使用空值来表示那值是未知的或者不存在的。当我们进入或更新数据库的时候，我们应当好好看看之后会空值引起许多困难，因此，如果可能的话，应该予以消除。我们应好好想想空值是最初缺席的，在3.6单元我们描述了没有不同操作空值的影响。

  .当我们讨论数据库时，我们必须区分数据库模式，即数据库的逻辑设计，以及数据库实例，它是数据库中的数据，在给定的时间内的快照。关系的，概念，对于一个变量的编程语言，而关系模式的概念对应于，类型定义的编程语言概念。一般来说，关系模式是一个属性列表和他们的相关区域。在我们讨论这个，之前，我们不会关心每个属性，的区域的定义。语言在第三章。关系实例的概念，对应变量值的编程语言概念。给定变量的，类型可能随时间而改变。

   .类似的，关系实例的内容，随着关系的更新而随时间而变化。相反，关系的模式通常不会改变关系。虽然知道关系模式和关系，实例，之间的区别很重要，但是我们经常使用相同的名称，例如讲师，来引导模式和实例。在需要时，我们显示的引用模式或实例。例如，教员模式或教员关系的实例。但是当我们明确表示模式或，实例时，我们只使用关系名称。考虑图2.5的组成关系，这种关系的模式是部门（所有员工，建筑，预算）。  注意属性，员工出现在教师模式和时间表和部门计划。这种，重复并非巧合。襄樊在关系模式中使用公共属性是关联不同关系元组的一种方法。例如，假设我们希望找到关于在沃申大楼工作的所有员工的信息。我们首先看一下部门关系，找到了在watson部门工作的员工jame。然后对于每一个这样的部门，我们在教师关系中查询与相应的部门相关的讲师信息。让我们继续我们的大学数据库示例，大学里的每门课程都可以提供多次，跨越不同的学期，甚至是一个学期，我大学里的每门课程都可以提供多次，跨越不同的学期，甚至是一个学期，我，我语，我大学里的每门课程都可以提供多次，跨越不同的学期，甚至是一个学期。我们需要一个关系来描述每一个独立的提供货节的课程，模式部分（课程编号，secid，学期，学年，建筑，教室编号，上课时间。图2.6，显示了几段关系的一个事例，我们需要一个关系来描述教师和学生之间的关系，以及他们教的课程。描述该关联的模式是，教师（ID，课程，选择，学期，年份）。

从图2.7中展示了一个教师关系的示例实例。正如你所想像的，有非常多保持在一个真实的大学数据库。除此之外，那些我们已经列入的关系，教师，公寓，课程，单元，prepeq，和老师们。我们在这文章中使用了以下的关系。

我们必须有一种方法来指定给定关系中的元组是如何被释放的。这是用它们的属性来表示的。也就是说，元组属性值的值必须是能够唯一标识元组的值。换句话说，关系中的两个元组对所有属性都不允许具有完全相同的值。超级键是一个或多个属性集合的集合，它允许我们在关系中唯一地标识一个元组。例如，关系指导员的ID属性足以区分一个指导员元组和另一个指导员元组，因此ID是一个超级键。另一方面，指导员的name属性不是超级键，因为几个指导员的名字可能是相同的，形式上，让R表示关系模式r中的属性集。如果我们说R的一个子集K是r的一个超级键，那么我们将考虑的范围限制在关系r的实例上，其中没有两个不同的元组对K中的所有属性都有相同的值。

主关键字应该被选择，如果这样，它的属性值就永远不会或很少会改变。
    例如，一个person的地址字段不应该是主关键字的一部分，因为它很可能会改变。从另一方面来说，社保号码保证不会改变。
企业产生的唯一标识符一般不改变，除非两个企业合并；在这种情况下，两个企业可能都发出相同的标识符，并且可能需要重新分配标识符以确保它们是唯一的。
   我们都习惯在其他属性之前列出关系模式的主键属性；例如，我们会首先将部门的部门名称属性列出来，因为它是主关键字。主键属性也需要强调。举例来说，一个关系，比如R1，可以在它的属性中包含另一个关系的主键，比如R2。此属性称为来自R1的外键，引用R2。因此关系R1也称为外键从属关系的引用关系，而R2称为外键的引用关系。例如，讲师中的属性部门名称被认为是来自导师、引用部门的外键，因为部门名称是部门的主键。在部门关系中必须有一个元组，比如TB，所以TA的部门名称属性的值，主键和部门名称与TB的值相同。现在考虑这个部分与教学的关系。如果一个课程存在一个部分，那么必须至少由一个教师来授课；当然，它可能由不止一个教师教授。为了保证一个特定的老师来教授，我们需要在一节中出现一个特定的组合（如课程ID，秒ID，学期，年份等），那么这些同样的组合必须出现在教学中。
    然而，这套值并不能构成教师的主键，因为不止一个教师可以教这样一个部分。因此，我们不能从节中声明外键约束（尽管我们可以在另一个方向定义外键约束，从教育到剖析）。

从剖析到教育的约束是引用完整性约束的一个例子；引用完整性约束要求在引用关系中任何元组的指定属性中出现的值，也需要出现在引用关系中的至少一个元组的指定属性中。图表可以通过架构图描述数据库模式，以及主键和外键依赖关系。图2.8显示了我们大学组织的架构图。每个关系都显示为一个框，顶部的关系名称是蓝色，而属性则在框中列出。主键属性显示为下划线。外键依赖项从引用关系的外键属性到引用关系的主键出现。

                翻译自《DATABASE SYSTEM CONCEPTS》  Abraham Silberschatz   Henry F.Korth   S.Sudarshan