database.system.concept

对关系模型的介绍

关系模型是当今商用数据处理应用的主流数据模型。它获得主流地位是因为他的简约相比起早期的数据模型例如网状模型和层次模型，极大减少了程序员的工作量。

在这个章节，我们首先要学习关系模型的基础。当今有大量的为关系数据库存在的理论。我们在第6章节先学习部分关于理论解决查询问题的内容，在第7、8章我们会进行测试数据库方向的理论知识以便对于对设计数据库结构模型有所帮助，在12’、13章时我们将会讨论如何更加有效地处理信息。

关系数据库建设

一个关系数据库由一个表格的集合组成，每个表格都有一个唯一的名字。打个比方，有个教职工表格figure2.1，存储着教职工的信息。这个表格有四列名称：教职工号、姓名、部门、薪水。这个表格的每一行都记录着教职工包括教职工号、姓名、部门、薪水在内的信息。相似地，课程表格figure2.2存储由每个学科的课程编号、课程名称、部门、学分构成的信息。通过教职工号的值来识别每个教职工，就像用课程编码的值来识别课程一样。

Figure2、3整合出了第三个表格：prereq，存储着每个课程的前提课程。这个表格有两个字段，课程编码和前提课程编码。每一行都由两个课程标识符组成，例如第二课程是第一课程的前提课程。

因此，prereq中的一行表格表明两门课之间的关系是一门课是另一门课的前提课程。另一个例子，我们认为教职工表格的一行可以是具体ID和名字、部门、薪水之间的关系。

总之，一个表格中的一行代表了一套数据之间的关系。这个表格是这些关系的集合，在表格的目录和数学目录之中有一个密切的对应关系，这就是关系数据模型得名的由来。在数学术语当中，一个数组是一个数值的顺序。数据之间的关系代表了数学元数的值，元数的值与表格中的一行相对应。

更具体的说，这个问题的执行结果是一个表格，这个表格由一列和许多行组成，这些行包括教员的名字，这个行的名称叫记录。如果问题在Figure1.2上用表格管理，结果将包括两行，一行是EI Said,另一行是Califieri。

   问题可能包含不止一个表的信息。例如，下面的问题要找教员的ID和一些教员的部门名称，这些教员的部门预算要超过95000.。

                      查找  教员的ID，部门名称

                      来自  教员、部门

                      条件  部门预算高于95000

   如果上面的问题在Figure1.2的表中被管理，这个系统将找到两个部门（科学和金融）符合条件，有五个教员在这些部门。因此，结果将有两列五行：（12121 ，Finance）,（45565，Computer Science），（10101，Computer Science）（83821，Computer Science），（76543，Finance）。

 

 

1.5.3 数据定义语言

  SQL提供了一个丰富的DDL,DDL可以对表进行定义，DDL也有完整的约束、声明。

   例如，下面SQL DDL声明定义了部门表：

                      Creat table  department

                        Dept-name    char(20)

                        Building       char(15)

                        Budget        numeric(12,2)

执行上面的DDL声明创建了部门表。这个表有三列：dept-name,building,budget.。这三列有具体的数据类型。第3章会详细介绍数据类型。另外，DDL更新了包含元数据的数据字。表模式是元数据的一个例子。

 

 

1.5.4 数据库模式

SQL不像图灵机一样强有力，一些运算可能使用通用的程序语言，而不会使用SQL。SQL也不能支持一些功能，比如，使用者的输入、输出展示、网络交流。运算和动作都必须用主机语言（C,C++,Java）编写. 应用程序是用来影响数据库的。大学信息系统就是一个程序，允许学生注册课程、班级花名册，估算学生的GPA，查询学生成绩单，等等。

为了使用数据库，DML需要在主机上被执行。这有两种做法：

1、提供一个可以给数据库发送DML和DDL声明和检索结果的应用程序界面。

      ODBC为使用C语言提供了一个可以普遍使用的应用程序界面标准。JDBC也提供了与C语言相应的标准。

2、通过扩大主机语言的语法可以在主机语言中嵌套DML调用。通常情况下，一个具体的字符界面DML调用和一个预处理程序组成DML的与预译程序，这个可以使DML声明转变成正常的主机语言的程序调用。

 

 

 

1.6  数据库设计

   设计数据库是为了方便管理大量的正文信息。这些大的正文信息不会被隔离存储。它们是某些事件操作的一部分，这些时间的结尾部分可能是数据库的信息也可能是一些装置或服务。数据库仅仅扮演了一个支持的角色。

   数据库设计主要是数据库模式的设计。一个完整的、满足所有事件被模式化的数据库应用环境的设计需要关注许多的问题。在这篇文章里，我们先关注数据库书写的需要和数据库模式的设计。第九章讨论所有的应用设计进程。

 

 

1.6.1   设计进程

   一个高水平的数据模型提供了一个有概念框架的数据库设计者去完善数据库使用者的数据需要，并且考虑数据库如何将这些需求结构化实现。数据库设计初期是去描绘数据库使用者的未来数据需求。数据库设计者需要让专家领域和使用者执行任务非常敏感的互相影响。这个阶段的结果是使用者需求的具体化。

   接下来，设计者选择了一个数据模型和提供被选择的数据模型概念，将这些需求翻译成一个概念化的数据库模型。概念化设计阶段模型发展提供了事件细节的综述。为了确认所有的数据需求的确令人满意并且不与其它任何一个相冲突，设计者会去复审。设计者也可以检查设计去移除任何多余的部分。

当我们谈论数据库的时候，我们必须区分数据库模式（数据库的逻辑设计）和数据库实例（数据库中数据在给定时间内的快照）。关系的概念与变量的程序设计相符合。一般来说，在外面讨论第3章的SQL语言之前，我们不会关心每个属性域的精准定义。关系实例的概念与可编程语言中的每一个值的概念相符合。给定变量的值可能随时间而变化。类似的，当关系被更新时，关系实例的内容可能随时间而变化。相反的是，关系的模式一般不会改变，虽然了解关系模式和关系实例之间的区别很重要，但我们经常使用相同的名称（例如指导员）来同时引用模式和实例。在需要的地方，我们明确的引用模式和实例，例如“指导员模式”或“指导员关系的实例”。但是，如果我们明确表示的是模式还是实例，我们只需使用关系名称。考虑图2.5中的关系，这种关系模式注意的是属性的名称同时出现在指令或架构和部门架构中，这种重复不是巧合。相反的是，在关系模式中使用公共属性是关联不同关系的元组的一种方法。例如，假设我们希望提供有关所有在沃森大楼工作的教员的信息。我们首先调查了沃森公司所有部门的关系和部门名称。然后，对于每个这样的部门，我们查看指导员关系以及相应部门名称相关联的讲师信息。莱茵斯继续我们大学数据库的例子。一所大学的每门课程可能会提供多次，在不同的学期，甚至在一个学期内，我们需要一个关系来描述每个人提供的班级的部分。这个模式是:

图2.6显示了部分关系的实例。我们需要一个关系来描述教师和他们教的班级之间的联系，描述这种关联的关系模式是:

图2.7显示了一个示例关系的实例，正如你所想象的，在一个大学数据库中有更多的关系。除了我们已经列出的那些关系，部门，课程，部分，本例和教学，我们在本文中使用了以下关系:

我们必须有一种方法来指定如何区分给定关系中的元组。这是用它们的属性来表示的。也就是说，元组属性值必须使其能够唯一的标识元组。换句话说，关系中的任何两个元的组所有属性都不被允许有完全相同的值，超级键是一组由一个或多个属性组成的集合，这些属性集合在一起，允许我们唯一的标识关系中的一个元组。例如，属性ID是足以用来区分一个教官组和另一个教官组，因此，ID是一个超级键。另一方面，因为几个教员可能有相同的名称。

我们会使用术语“主键”来表示一个被数据库设计者选择作为带有关系的压缩元组的主要方法。一个键（无论是主要、次要，还是超级）是一个完整关系的性质，而不是个别的元组，。

任意两个在一个关系中被禁止同时使用同一个值。一个键所代表的名称说明了在现实世界的企业中的约束已经开始被模仿

主键必须小心选择。正如我们指出的，一个人的名字明显看来是不够的，因为这里可能有一些人有相同的名字。在美国，一个人的社区保险号码的属性是一个次要键，而非美国公民的居民通常没有社区保险号码，国际企业通常会建立他们自己特殊的识别方式。一个可选的选项作为一个键通常被当做一些独特的其他属性的集合。

主键应当选择属性值从不改变或是极少改变的。例如一个人的地址不应该被作为逐渐使用，因为这容易改变。社区保险号码，从另一个方面来说，是可靠并从不改变的。用于企业的辨识手段通常不会改变，除非两个企业合并，在这样的情况里，同样的识别码会被两家企业同时使用，辨析码的再分配会被要求确保他们的独一性。

  通常的习惯会将主键以关系模式的方式先于其他的元素分配。打个比方，部门一栏中部门先被分配，这个主键也被添加了下划线。

  一个关系，称为r1，可以包含它的主键分配和其他关系，叫做r2这种分配叫做r1引用r2的外部键。关系r1也被称为外部键从属的引用关系，r2被称为外部键的被引用关系。举个例子，部门名在教职工表格中教职工表格的外来件，引用了部门这一栏的数据，而部门是部门名一栏的主键，在任意一个数据库实例中，被给出的任意元数，被称为Ta，从教职工关系之中，这里一定有一些元数，称为Tb，在部门关系之中，Ta部门属性的值和Tb部门属性的主键的值完全相同。

  现在我们来讨论下部门和教师的关系。我们有理由去要求一个课程中是否存在一个单元，这个课程一定是由至少一个教职工来执教的，然而，也有可能一门课存在着被多个教职工执教的可能性。为了解决这一问题的约束，我们要求如果一个特殊的集合在这个部分出现，然后这个相同的集合一定会出现在教师一栏。然而，这个值的选项没有形成教师一栏的主键，而多个教职工可能会上同一节课。到最后，我们不能分清一个来自教师一栏的外部键（尽管我们可以分清一个来自其他表格的外部键）

  

  从节到教学的约束条件是参照完整性的一个例子，参照完整性需要一个出现在至少一个元组的引用关系也出现在出现在规定属性中的值。

翻译自《database.system.concept》6th edition