《数据库基础及实践技术——SQL Server 2008》一1.3 数据和数据模型

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
简介: 本节书摘来自华章出版社《 数据库基础及实践技术——SQL Server 2008》一 书中的第1章,第1.3节,作者:何玉洁,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.3 数据和数据模型

本节介绍如何理解现实世界、如何将之“信息化”以及如何描述现实世界的信息结构等内容。

1.3.1 数据和数据模型概述

  1. 数据
    为了了解世界、研究世界和交流信息,人们需要描述各种事物。用自然语言来描述虽然很直接,但过于烦琐,不便于形式化,而且也不利于用计算机来表达。为此,人们常常只抽取那些感兴趣的事物特征或属性,作为事物的描述。例如,一个学生可以用如下记录来描述:(张三,9912101,1981,计算机,应用软件),单凭这样一条记录人们一般不容易知道其准确含义,但如果对其加以准确解释,就可以得到如下信息:张三是9912101班的学生,1981年出生,是计算机系应用软件专业的。这种对事物描述的符号记录称为数据。数据有一定的格式,例如,性别是一个汉字的字符。这些格式的规定是数据的语法,而数据的含义是数据的语义。人们通过解释、推论、归纳、分析和综合等方法,从数据所获得的有意义的内容称为信息。因此,数据是信息存在的一种形式,只有通过解释或处理才能成为有用的信息。
  2. 数据模型
    模型,特别是具体的模型,人们并不陌生。一张地图、一组建筑设计沙盘、一架航模飞机等都是具体的模型。一眼望去,会使人联想到现实生活中的事物。模型是现实世界特征的模拟和抽象。数据模型(data model)也是一种模型,它是对现实世界中的数据特征的抽象。

数据库是企业或部门相关数据的集合,它不仅要反映数据本身的内容,而且要反映数据之间的联系。由于不可能用计算机直接处理现实世界中的具体事物,因此,必须把现实世界中的具体事物转换成计算机能够处理的对象。在数据库中用数据模型这个工具来抽象、表示和处理现实世界中的数据和信息。通俗地讲,数据模型就是对现实世界数据的模拟。
对数据库中数据的组织都是基于某种数据模型的,因此,了解数据模型的基本概念是学习数据库的基础。
数据模型一般应满足3个方面的要求:第一个方面是可以比较真实地模拟现实世界;第二个方面是容易被人们理解;第三个方面是便于在计算机中实现。用一种模型来很好地满足这3个方面的要求是比较困难的。在数据库系统中针对不同的使用对象和应用目的,采用不同的数据模型。
不同的数据模型实际上是提供给我们模型化数据和信息的不同工具。根据模型应用目的的不同,可以将这些模型划分为两大类,它们属于两个不同的层次。
一类是概念层数据模型,也称为概念模型或信息模型,该模型从数据的应用语义视角来抽取模型并按用户的观点来对数据和信息进行建模。这类模型主要用在数据库设计阶段,它与具体的数据库管理系统无关。另一类是组织层数据模型,也称为组织模型,该模型从数据的组织层来描述数据。所谓组织层就是指用什么样的数据结构来组织数据。数据库发展到现在主要包括如下几种组织模型(或称做组织方式):层次模型(用树形结构组织数据)、网状模型(用图形结构组织数据)、关系模型(用简单二维表结构组织数据)以及对象-关系模型(用复杂的表格以及其他结构组织数据)。组织层数据模型主要是以计算机系统的观点对数据进行建模,它与所使用的数据库管理系统的种类有关,主要用于DBMS的实现。
组织层数据模型是数据库系统的核心和基础。各个厂商开发的数据库管理系统都基于某种组织层数据模型。
为了把现实世界中的具体事物抽象、组织为某一具体DBMS支持的数据模型,人们通常首先将现实世界抽象为信息世界,然后再将信息世界转换为机器世界,即首先把现实世界中的客观对象抽象为某一种信息结构,这种信息结构并不依赖于具体的计算机系统,而且也不与具体的DBMS相关,而是概念级的模型,也就是我们前面所说的概念层数据模型,然后再把概念层数据模型转换为DBMS支持的组织层数据模型。注意,从现实世界到概念层数据模型使用的是“抽象”技术,从概念层数据模型到组织层模型使用的是“转换”,也就是说,先有概念层数据模型,然后再到组织层数据模型。从概念层数据模型到组织层数据模型的转换应该是比较直接和简单的,因此,使用合适的概念层数据模型就显得比较重要。上述过程如图1-4所示。

3422843cdcf87a945d804fe4b39bf51dbb32f45d

1.3.2 数据模型三要素

数据一般包括如下两个特征:
静态特征。数据的静态特征包括数据的基本结构、数据间的联系以及对数据取值范围的约束。例如,1.1.1节中给出的学生管理的例子,学生基本信息包含:学号、姓名、性别、出生日期、所在系、专业、所在班、特长、家庭住址,这些都是学生所具有的基本特征,是学生数据的基本结构。再看数据之间的联系,学生选课信息包括:学号、课程号和考试成绩,学生选课信息中的学号与学生基本信息中的学号就有一种参照的关系,即学生选课信息中的学号所能取的值必须在学生基本信息中的学号取值范围之内,因为只有这样学生选课信息中所描述的学生选课情况才是有意义的(不允许记录一个根本就不存在的学生的选课情况),这就是数据之间的联系。下面再看一下数据取值范围的约束。我们知道人的性别一项的取值只能是“男”或“女”、考试成绩一般在0~100分之间等,这些都是对某个列的数据取值范围进行了限制,目的是在数据库中存储正确的、有意义的数据,这就是对数据取值范围的约束。
动态特征。数据的动态特征是指对数据可以进行的操作以及操作规则。对数据库数据的操作主要有查询数据和更改数据,更改数据一般又包括对数据的插入、删除和修改。
我们将对数据的静态特征和动态特征的描述称为数据模型三要素,即在描述数据时要包括数据的基本结构、数据的约束条件(这两个属于静态特征)和定义在数据上的操作(属于动态特征)。
一般来讲,数据模型是严格定义的一组概念的集合,这些概念准确地描述了系统的静态特征、动态特征和完整性约束条件。因此,数据模型一般由数据结构、数据操作和数据完整性约束三部分组成,这三部分就称为数据模型的三要素。

  1. 数据结构
    数据的结构是所研究的对象类型的集合,这些对象是数据库的组成部分。数据结构包括两类,一类是与数据类型、内容、性质有关的对象,比如关系模型中的域、属性和关系等;另一类是与数据之间联系有关的信息,它从数据组织层表达数据记录与字段的结构。

数据结构是刻画数据模型最重要的方面。因此,在数据库系统中,人们通常按照数据结构的类型来命名数据模型。如层次结构、网状结构和关系结构的数据模型分别命名为层次模型、网状模型和关系模型。
数据结构是对数据的静态特征的描述。

  1. 数据操作
    数据操作是指对数据库中的各种对象(型)的实例(值)允许执行的操作的集合,包括操作及有关的操作规则。它描述的是系统的信息更改与使用,包括以下两个方面。

数据查询:在数据集合中提取用户感兴趣的内容,不改变数据结构与数据值。
数据更改:包括插入、删除和修改数据,此类操作改变数据的值。
数据模型必须定义这些操作的确切含义、操作符号、操作规则以及实现操作的语言。数据操作是对数据的动态特征的描述。

  1. 数据完整性约束
    数据完整性约束是一组完整性规则的集合。完整性规则是给定的数据模型中数据及其联系所具有的制约和依存规则,用以保证数据的正确、有效和相容,使数据库中的数据值与现实情况相符。例如,学生选课表中的学号与学生基本信息表中的学号之间的制约关系、人的年龄应该在0~200之间的取值约束等。

1.3.3 概念层数据模型

  1. 基本概念
    从图1-4可以看出,概念层数据模型实际上是现实世界到机器世界的一个中间层次。

概念层数据模型是抽象现实系统中有应用价值的元素及其联系,反映现实系统中有应用价值的信息结构,不依赖于数据的组织层结构。
概念层数据模型用于信息世界的建模,是现实世界到信息世界的第一层抽象,是数据库设计人员进行数据库设计的工具,也是数据库设计人员和用户之间进行交流的工具,因此,该模型一方面应该具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识;另一方面还应该简单、清晰、易于用户理解和便于向机器世界的转换。
概念层数据模型是面向用户、面向现实世界的数据模型,它与具体的DBMS无关。采用概念层数据模型,设计人员可以在设计的开始把主要精力放在了解现实世界上,而把涉及DBMS的一些技术性问题推迟到设计阶段去考虑。
常用的概念层数据模型有实体–联系(Entity-Relationship,E-R)模型和语义对象模型。下面我们只介绍实体–联系模型。

  1. 实体–联系模型
    由于直接将现实世界信息按具体的数据组织模型进行组织,必须同时考虑很多因素,设计工作非常复杂,并且效果也不是很理想,因此需要一种方法来对现实世界的信息结构进行描述。事实上已经有了一些这方面的方法,我们要介绍的是P. P. S.Chen于1976年提出的实体–联系方法,即通常说的E-R方法或实体–联系方法。这种方法简单、实用,得到了非常普遍的应用,也是目前描述信息结构比较常用的方法。

实体–联系方法使用的工具称做E-R图,它所描述的现实世界的信息结构称为企业模式(enterprise schema),也把这种描述结果称为E-R模型。
实体–联系方法试图定义许多数据分类对象,然后数据库设计人员就可以通过直观的识别方法将数据项归类到已知的类别中。
实体–联系方法主要涉及3个概念:实体、属性和联系。
(1)实体(Entity)
数据是用来描述现实世界的,而描述的对象是形形色色的,有具体的,也有抽象的;有物理存在的,也有概念性的。例如,学生、课程等都是具体的对象,足球比赛可看成是抽象的对象。
实体是具有相同性质并且彼此之间可以相互区分的现实世界对象的集合。
例如,“学生”是一个实体,这个实体中的每个学生都有学号、姓名、性别、出生日期等相同的属性。
在关系数据库中,一般一个实体被映射成一个关系表,表中的一行对应一个可区分的现实世界对象(这些对象组成了实体),称为实体实例(entity instance)。例如,“学生”实体中的每个学生都是“学生”实体的一个实例。
注意:有些书籍中使用实体集和实体类型来表示我们所说的实体,用实体来表示我们所说的实体实例。
在E-R图中用矩形框表示具体的实体,把实体名写在框内。
(2)属性(Attribute)
每个实体都具有一定的特征或性质,这样人们才能根据实体的特征来区分一个个实例。比如学生的学号、姓名、性别等都是学生实体具有的特征。将实体所具有的特征称为它的属性。
属性是描述实体或者联系(在下文有说明)的性质的数据项。
在实体中,属于一个实体的所有实例都具有共同的性质,这些性质就是实体的属性。例如,“学生”实体的学号、姓名、性别、出生日期、所在系等性质就是“学生”实体的属性。
每个实体都有一个标识符(或叫实体的码),标识符是实体中的一个属性或者一个属性集合,每个实体实例在标识符上具有不同的值。标识符用于区分实体中的每个不同的实例,这个概念类似于后面介绍的关系中的候选码的概念。例如,“学生”实体的标识符是学生的“学号”。
在E-R图中用圆角矩形框表示属性,框内写上属性名。当实体所包含的属性比较多时,为了简洁,我们在E-R图中经常省略对属性的描述,而在其他地方将属性单独罗列出来。
(3)联系
在现实世界中,事物内部以及事物之间是有联系的,这些联系在信息世界反映为实体内部的联系和实体之间的联系。实体内部的联系通常是指组成实体的各属性之间的联系,实体之间的联系通常是指不同实体之间的联系。例如,在“职工”实体中,假设有属性“职工号”和“部门经理号”,通常情况下,“部门经理号”与“职工号”之间有一种关联关系,即部门经理号的取值受职工号取值的约束(因为部门经理也是职工,也有职工号),这就是实体内部的联系。而“学生”实体(设有以下属性:学号、姓名、性别、所在系、班号)和“班级”实体(设有以下属性:班号、班主任、班级人数)之间也有联系,这个联系是“学生”实体中的“班号”必须是“班级”实体中已经存在的班号,这种联系就是实体之间的联系。
联系是数据之间的关联集合,是客观存在的应用语义链。联系用菱形框表示,框内写上联系名,并用连线将有关的实体连接起来。
两个实体之间的联系可以分为如下3类:
一对一联系(1 : 1)。如果实体A中的每个实例在实体B中至多有一个(也可以没有)实例与之关联,反之亦然,则称实体A与实体B具有一对一联系,记为1 : 1。一对一联系示意图如图1-5a所示。

screenshot

例如,部门和经理(假设一个部门只有一个经理,一个人只担任一个部门的经理)、系和系主任(假设一个系只有一个系主任,一个人只担任一个系的主任),它们都是一对一联系。部门和经理之间的一对一联系如图1-6a所示。
一对多联系(1 : n)。如果实体A中的每个实例在实体B中有n(n≥0)个实例与之关联,而实体B中每个实例在实体A中只有一个实例与之关联,则称实体A与实体B是一对多联系,记为1 : n。一对多联系示意图如图1-5b所示。
例如,一个部门有若干个职工,而一个职工只在一个部门工作,则部门和职工之间就是一对多联系(如图1-6b所示)。又如,假设一个系有多名教师,而一个教师只在一个系工作,则系和教师之间也是一对多联系。
多对多联系(m : n)。如果对于实体A中的每个实例,实体B中有n(n≥0)个实例与之关联,而对于实体B中的每个实例,在实体A中也有m(m≥0)个实例与之关联,则称实体A与实体B的联系是多对多联系,记为m : n。多对多联系示意图如图1-5c所示。
例如,在学生和课程之间,一个学生可以选修多门课程,一门课程也可以有多个学生选修,因此学生和课程之间是多对多的联系,如图1-6c所示。

screenshot

实际上,一对一联系是一对多联系的特例,而一对多联系又是多对多联系的特例。
E-R模型不仅能描述两个实体之间的联系,而且还能描述两个以上实体之间的联系。比如有顾客、商品、销售人员3个实体,并且有以下语义:每个顾客可以从多个销售人员那里购买多种商品,每种商品可由多个销售人员卖给多个顾客,每个销售人员可以将多种商品卖给多个顾客。描述顾客、商品和销售人员之间的销售和购买关系的E-R图如图1-7所示,这里将联系命名为“购买”。

b554c0887334863fe61d04362db0c4c559fffd9f

联系也可以有自己的附加属性。例如,在图1-6c的“选课”联系中,可以有考试日期、考试成绩等属性。

1.3.4 组织层数据模型

组织层数据模型是从数据的组织方式的角度来描述信息,目前,在数据库领域中最常用的组织层数据模型主要有4种,分别是层次模型、网状模型、关系模型和面向对象模型。组织层数据模型是按存储数据的逻辑结构来命名的,例如,层次模型采用的是树形结构。目前使用最普遍的是关系数据模型。关系数据模型技术从20世纪70年代开始到现在已经发展得非常成熟,因此,我们重点介绍关系数据模型。
关系数据模型(下面简称关系模型)是目前最重要的数据模型之一。关系数据库就是采用关系模型作为数据的组织方式。20世纪80年代以来,计算机厂商推出的数据库管理系统几乎都支持关系模型,非关系系统的产品也大都加上了关系接口。
下面从数据模型的三要素角度来介绍关系模型的特点。

  1. 关系模型的数据结构
    关系模型源于数学,它把数据看成是二维表中的元素,而这个二维表就是关系。

关系系统要求让用户所感觉的数据库就是一张张表。在关系系统中,表是逻辑结构而不是物理结构。实际上,系统在物理层可以使用任何有效的存储结构来存储数据,如有序文件、索引、哈希表、指针等。因此,表是对物理存储数据的一种抽象表示—对很多存储细节的抽象,如存储记录的位置、记录的顺序、数据值的表示,以及记录的访问结构(如索引)等,对用户来说都是不可见的。
表1-1所示的是学生基本信息的关系模型形式。
screenshot

用关系表示实体以及实体之间联系的模型称为关系模型。下面介绍关系模型中的一些基本术语。
(1)关系
关系就是二维表,它满足如下条件:
关系表中的每一列都是不可再分的基本属性。如表1-2所示的表就不是关系表,因为“出生日期”列不是基本属性,它包含了子属性“年”、“月”、“日”。
表中各属性不能重名。
表中的行、列次序并不重要,即交换列的前后顺序,如在表1-1中,将“性别”放在“年龄”的前面,不影响其表达的语义。
screenshot

(2)元组
表中的每一行数据称为一个元组,它相当于一个记录值。例如,表1-1所示的学生关系中的元组有:
(0811101,王小东,18,男,计算机)
(0811102,张小丽,18,女,计算机)
(0821101,李海,19,男,信息管理)
(0821103,赵耀,19,男,信息管理)
(3)属性
二维表中的每个列称为一个属性(或称做字段),每个属性有一个名字,称为属性名。二维表中对应某一列的值称为属性值;二维表中列的个数称为关系的元数。如果一个二维表有n个列,则称其为n元关系。表1-1所示的学生关系有学号、姓名、年龄、性别、所在系5个属性,是一个五元关系。
在数据库中有两套标准术语,一套用的是表、行、列;而另一套用关系(对应表)、元组(对应行)、属性(对应列)。
(4)值域
属性的取值范围称为值域。例如,如果大学生的年龄假设是14~40之间的整数,则属性“年龄”的值域就是[14..40],而人的性别只能是“男”或“女”,因此,属性“性别”的值域就是{男,女}。
(5)关系模式
二维表的结构称为关系模式,或者说,关系模式就是二维表的表框架或表头结构。设有某关系,名为R,属性分别为A1,A2,…,An,则关系模式可以表示为:R(A1,A2,…,An)。
例如,表1-1所示关系的关系模式为:学生(学号,姓名,年龄,性别,所在系)。
如果将关系模式理解为数据类型,则关系就是该数据类型的一个具体值。
(6)关系数据库
对应于一个关系模型的所有关系的集合称为关系数据库。
(7)候选键
如果一个属性或属性集的值能够唯一标识一个关系的元组而又不包含多余的属性,则称该属性或属性集为候选键。候选键也称为候选码或候选关键字。一个关系的候选键可以不唯一。
(8)主键
主键(primary key)也称为主码或主关键字,是表中的属性或属性组,用于唯一地确定一个元组。主键可以由一个属性组成,也可以由多个属性共同组成。例如,表1-1所示的学生关系中,学号就是其主键,因为学号的一个取值可以唯一地确定一个学生。而表1-3所示的选课关系的主键就由学号和课程号共同组成,因为一个学生可以选修多门课程,而且一门课程也可以有多个学生选修,因此,只有将学号和课程号组合起来才能共同确定一行记录。我们称由多个属性共同组成的主键为复合主键。当某个关系的主键是由多个属性共同组成时,需要用括号将这些属性括起来,表示共同作为主键。例如,表1-3中选课关系的主键是:(学号,课程号)。
screenshot

注意,我们不能根据关系表在某时刻存储的内容来决定其主键,这样做是不可靠的,这样做只能是猜测。表的主键与其实际的应用语义有关、与表的设计者的意图有关。例如,对于表1-3,如果允许一个学生对同一门课程有多次考试(例如,对考试不及格的情况,一般都允许有多次考试),则选择(学号,课程号)作为主键显然就不够了。对于这种情况,可以在表中添加一个新列:考试次数。现在学生选课表就包含学号、课程号、成绩和考试次数4个属性。对于允许一个学生对同一门课程有多次考试的情况,其主键为:(学号,课程号,考试次数)。为什么不可以不添加“考试次数”列,而让(学号,课程号,成绩)作为该关系的主键,请读者自己思考。
有时一个关系中可能存在多个可以作为主键的属性,比如,对于“学生”关系,假设增加了“身份证号”属性,则“身份证号”属性也可以作为学生关系的主键。如果关系中存在多个可以作为主键的属性,则称这些属性为候选键属性,相应的键为候选键。从候选键中选取哪一个作为主键都可以,因此,主键是从候选键中选取出来的。
(9)主属性和非主属性
包含在任一候选键中的属性称为主属性。不包含在任一候选键中的属性称为非主属性。
例如,学生选课关系中,学号和课程号为主属性,成绩为非主属性。

  1. 关系模型的数据操作
    关系模型的操作对象是集合,而不是行,也就是操作的对象以及操作的结果都是完整的表(是包含行集的表,而不只是单行,当然,只包含一行数据的表是合法的,空表或不包含任何数据行的表也是合法的)。而非关系型数据库系统中典型的操作是一次一行或一次一个记录。因此,集合处理能力是关系系统区别于其他系统的一个重要特征。

关系模型的数据操作主要包括4种:查询、插入、删除和修改。关系数据库中的信息只有一种表示方式,那就是表中的行、列位置有明确的值。这种表示是关系系统中唯一可行的方式(当然,这里指的是逻辑层)。特别地,关系数据库中没有连接一个表到另一个表的指针。在表1-1和表1-3中,表1-1的学生基本信息的第一行数据与表1-3的学生选课信息的第一行有联系(当然也与第二行和第三行有联系),因为学生0811101选了课程。但在关系数据库中这种联系不是通过指针来实现的,而是通过学生基本信息表“学号”列的值与学生选课表“学号”列的值实现联系的(学号值相等)。但在非关系系统中,这些信息一般由指针来表示,这种指针对用户来说是可见的。
需要注意的是,当我们说关系数据库中没有指针时,并不是指在物理层没有指针,实际上,在关系数据库的物理层也使用指针,但所有这些物理层的存储细节对用户来说都是不可见的。

  1. 关系模型的数据完整性约束
    数据完整性是指数据库中存储的数据是有意义的或正确的。关系模型中的数据完整性规则是对关系的某种约束条件。它的数据完整性约束主要包括三大类:实体完整性、参照完整性和用户定义的完整性。

(1)实体完整性
实体完整性指的是关系数据库中所有的表都必须有主键,而且表中不允许存在如下的记录:
无主键值的记录
主键值相同的记录
因为若记录没有主键值,则此记录在表中一定是无意义的。前面介绍过,关系模型中的每一行记录都对应客观存在的一个实例或一个事实。例如,一个学号唯一地确定了一个学生。如果表中存在没有学号的学生记录,则此学生一定不属于正常管理的学生。另外,如果表中存在主键值相等的两个或多个记录,则这两个或多个记录会对应同一个实例。这会出现两种情况,第一,若表中的其他属性值也完全相同,则这些记录就是重复的记录,存储重复的记录是无意义的;第二,若其他属性值不完全相同则会出现语义矛盾,比如同一个学生(学号相同),而其名字不同或性别不同,显然不可能。
在关系数据库中主键的属性不能取空值。关系数据库中的空值是特殊的标量常数,它代表未定义的(不适用的)或者有意义但目前还处于未知状态的值。例如,当向表1-3所示的学生选课表中插入一行记录时,在学生还没有考试之前,其成绩是不确定的,因此此列上的值为空。数据库中的空值用“NULL”表示。
(2)参照完整性
参照完整性有时也称为引用完整性。现实世界中的实体之间往往存在着某种联系,在关系模型中,实体以及实体之间的联系在关系数据库中都用关系来表示,这样就自然存在着关系(实体)与关系(实体)之间的引用关系。参照完整性就是描述实体之间联系的。
参照完整性一般是指多个实体或关系表之间的关联关系。如在表1-3中,学生选课表中的学生必须受限于表1-1的学生基本信息表中已有的学生,我们不能在学生选课表中描述一个根本就不存在的学生的选课情况,也就是学生选课表中学号的取值必须在学生基本信息表的学号的取值范围内。这种一个表中某列的取值受另一个表的某列的取值范围约束的特点称为参照完整性。在关系数据库中用外键(foreign key,有时也称为外码或外部关键字)来实现参照完整性。例如,我们只要将学生选课表中的“学号”定义为引用学生基本信息表中的“学号”的外键,就可以保证选课表中的“学号”的取值在学生基本信息表中的已有“学号”范围内。
外键一般出现在联系所对应的关系中,用于表示两个或多个实体之间的关联关系。外键实际上是表中的一个(或多个)属性,它引用某个其他表(特殊情况下,也可以是外键所在的表)的主键,当然,也可以是候选码,但多数情况下是主键。
下面再看几个指定外键的例子。
【例1-1】“学生”关系模式和“专业”关系模式所包含的属性如下,其中主键用下划线标识。
学生(学号,姓名,性别,专业号,出生日期)
专业(专业号,专业名)
这两个关系之间存在着引用关系,即“学生”关系中的“专业号”引用了“专业”关系中的“专业号”,显然,“学生”关系中“专业号”的值必须是确实存在的专业的专业号。也就是说,“学生”关系中的“专业号”参照了“专业”关系中的“专业号”,即“学生”关系中的“专业号”是引用了“专业”关系中的“专业号”的外键。
【例1-2】学生、课程以及学生与课程之间的选课情况可以用如下3个关系模式表示:
学生(学号,姓名,性别,专业号,出生日期)
课程(课程号,课程名,学分)
选课(学号,课程号,成绩)
在这3个关系模式中,“选课”中的“学号”必须是“学生”中已有的学生,因此“选课”中的“学号”引用了“学生”中的“学号”。同样“选课”中的“课程号”也必须是“课程”中已有的课程,即“选课”中的“课程号”引用了“课程”中的“课程号”。因此,“选课”中的“学号”是引用了“学生”中“学号”的外键,而“选课”中的“课程号”是引用了“课程”中“课程号”的外键。
主键要求必须是非空且不重复的,但外键无此要求。外键可以有重复值,这点我们从表1-3可以看出。外键也可以取空值,例如,职工与其所在的部门可以用如下两个关系模式表示:
职工(职工号,职工名,部门号,工资级别)
部门(部门号,部门名)
其中,“职工”中的“部门号”是引用“部门”中“部门号”的外键,如果某个新来职工还没有被分配到具体的部门,则其“部门号”就为空值;如果这个职工已经被分配到了某个部门,则其部门号就有了确定的值(非空值)。
另外,外键不一定要与被引用列同名,只要它们的语义相同即可。例如,对于例1-1中的学生关系模式,如果将该关系模式中的“专业号”改为“所学专业”也是可以的,只要“所学专业”属性的语义与专业关系模式中的“专业号”语义相同,且取值域相同即可。
(3)用户定义的完整性
用户定义的完整性也称为域完整性或语义完整性。任何关系数据库系统都应该支持实体完整性和参照完整性,除此之外,不同的数据库应用系统根据其应用环境的不同,往往还需要一些特殊的约束条件,用户定义的完整性就是针对某一具体应用领域定义的数据约束条件,它反映某一具体应用所涉及的数据必须要满足应用语义的要求。
用户定义的完整性实际上就是指明关系中属性的取值范围,也就是属性的域,即限制关系中的属性的取值类型及取值范围,防止属性的值与应用语义矛盾。例如,学生的考试成绩的取值范围为0~100,或取{优、良、中、及格、不及格}。又如,假设有工作表(工作编号,工作性质,最低工资,最高工资),则应该约束其中的“最低工资”要小于或等于“最高工资”。

1.3.5 E-R模型向关系模型的转换

E-R模型向关系模型的转换要解决的问题是如何将实体以及实体间的联系转换为关系模式,如何确定这些关系模式的属性和键。
关系模型的逻辑结构是一组关系模式的集合。E-R图由实体、实体的属性以及实体之间的联系三部分组成,因此将E-R图转换为关系模型实际上就是将实体、实体的属性以及实体间的联系转换为关系模式,转换的一般规则为:
一个实体转换为一个关系模式。实体的属性就是关系的属性,实体的标识符就是关系的主键。
对于实体间的联系有以下不同的情况:
1)一个1∶1联系可以转换为一个独立的关系模式,也可以与任意一端所对应的关系模式合并。
如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,每个实体的码均是该关系模式的主键,同时也是引用各自实体的外键。
如果是与联系的任意一端实体所对应的关系模式合并,则需要在该关系模式的属性中加入另一个实体的码和联系本身的属性,同时新加入的实体的码为此关系模式中引用另一个实体的外键。
2)一个1∶n联系可以转换为一个独立的关系模式,也可以与n端所对应的关系模式合并。
如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系模式的属性,而关系模式的主键为n端实体的码,同时n端实体的码为此新关系模式中引用n端实体的外键,1端实体的码作为引用1端实体的外键。
如果是与n端所对应的关系模式合并,则需要在n端对应的关系模式的属性中加入1端实体的码以及联系本身的属性,同时1端实体的码在n端实体中作为引用1端实体的外键。
3)一个m∶n联系转换为一个独立的关系模式,与该联系相连的各实体的码以及联系本身的属性均转换为该关系模式的属性,新关系模式的主键包含各实体的码,同时新关系模式中各实体的码为引用各自实体的外键。
3个或3个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为此关系模式的属性,而此关系模式的码包含各实体的码,同时新关系模式中的各实体的码为引用各自实体的外键。
具有相同主键的关系模式可以合并。
【例1-3】1∶1联系示例。设有描述部门和经理关系的E-R图如图1-8所示,将其转换为合适的关系模式。
解:对于1∶1联系,可以有下列两种转换方法。
1)将联系与某一端实体的关系模式合并,则转换后的结果为:
经理(经理号,经理名,电话)
其中“经理号”为主键。
部门(部门号,部门名,经理号)
其中“部门号”为主键,“经理号”为引用“经理”关系模式的外键。
或者:
经理(经理号,部门号,经理名,电话)
其中“经理号”为主键,“部门号”为引用“部门”关系模式的外键。
部门(部门号,部门名)
其中“部门号”为主键。
2)将联系转换为一个独立的关系模式,则转换后的结果为:
经理(经理号,经理名,电话)
其中“经理号”为主键。
部门(部门号,部门名)
其中“部门号”为主键。
部门_经理(经理号,部门号)
其中“经理号”和“部门号”为候选键,同时也为引用“部门”和“经理”关系模式的外键。
在1∶1联系中一般不将联系单独设计为一个关系模式,因为这样转换出来的关系模式个数比较多,对应的表的个数也多,而查询时涉及的表个数越多,查询效率就越低。
【例1-4】1∶n联系示例。设有描述部门和职工关系的E-R图如图1-9所示,将其转换为合适的关系模式。
解:对于1∶n联系,可以有下列两种转换方法。
1)如果将联系与n端实体的关系模式合并,则转换成如下两个关系模式:
部门(部门号,部门名)
其中“部门号”为主键。
职工(职工号,部门号,职工名,性别)
其中“职工号”为主键,“部门号”为引用“部门”关系模式的外键。
2)如果将联系作为一个独立的关系模式,则转换为如下3个关系模式:
部门(部门号,部门名)
其中“部门号”为主键。
职工(职工号,职工名,性别)
其中“职工号”为主键。
部门_职工(部门号,职工号)
其中“职工号”为主键,同时也为引用“职工”关系模式的外键,“部门号”为引用“部门”关系模式的外键。
同1∶1联系转换为关系模式的原因一样,对于1∶n联系,通常也不将联系转换为一个独立的关系模式。
【例1-5】m∶n联系示例。设有描述教师、课程和教师授课关系的E-R图,如图1-10所示,将其转换为合适的关系模式。
解:对于m∶n联系,必须将联系转换为一个独立的关系模式。该E-R图转换后的结果为:
教师(教师号,教师名,职称)
其中“教师号”为主键。
课程(课程号,课程名,学分)
其中“课程号”为主键。
授课(教师号,课程号,授课时数)
其中(教师号,课程号)为主键,同时也为引用“教师”和“课程”关系模式的外键。

相关实践学习
使用SQL语句管理索引
本次实验主要介绍如何在RDS-SQLServer数据库中,使用SQL语句管理索引。
SQL Server on Linux入门教程
SQL Server数据库一直只提供Windows下的版本。2016年微软宣布推出可运行在Linux系统下的SQL Server数据库,该版本目前还是早期预览版本。本课程主要介绍SQLServer On Linux的基本知识。 相关的阿里云产品:云数据库RDS SQL Server版 RDS SQL Server不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的License费用,减少额外支出。 了解产品详情: https://www.aliyun.com/product/rds/sqlserver
相关文章
|
7天前
|
SQL 人工智能 算法
【SQL server】玩转SQL server数据库:第二章 关系数据库
【SQL server】玩转SQL server数据库:第二章 关系数据库
46 10
|
7天前
|
SQL 算法 数据库
【SQL server】玩转SQL server数据库:第三章 关系数据库标准语言SQL(二)数据查询
【SQL server】玩转SQL server数据库:第三章 关系数据库标准语言SQL(二)数据查询
64 6
|
2天前
|
SQL 关系型数据库 MySQL
关系型数据库插入数据的语句
使用SQL的`INSERT INTO`语句向关系型数据库的`students`表插入数据。例如,插入一个`id`为1,`name`为'张三',`age`为20的记录:`INSERT INTO students (id, name, age) VALUES (1, '张三', 20)。如果`id`自增,则可简化为`INSERT INTO students (name, age) VALUES ('张三', 20)`。
5 2
|
2天前
|
SQL 存储 Oracle
关系型数据库查询数据的语句
本文介绍了关系型数据库中的基本SQL查询语句,包括选择所有或特定列、带条件查询、排序、分组、过滤分组、表连接、限制记录数及子查询。SQL还支持窗口函数、存储过程等高级功能,是高效管理数据库的关键。建议深入学习SQL及相应数据库系统文档。
6 2
|
4天前
|
SQL 数据库
数据库SQL语言实战(二)
数据库SQL语言实战(二)
|
4天前
|
SQL 关系型数据库 数据库
【后端面经】【数据库与MySQL】SQL优化:如何发现SQL中的问题?
【4月更文挑战第12天】数据库优化涉及硬件升级、操作系统调整、服务器/引擎优化和SQL优化。SQL优化目标是减少磁盘IO和内存/CPU消耗。`EXPLAIN`命令用于检查SQL执行计划,关注`type`、`possible_keys`、`key`、`rows`和`filtered`字段。设计索引时考虑外键、频繁出现在`where`、`order by`和关联查询中的列,以及区分度高的列。大数据表改结构需谨慎,可能需要停机、低峰期变更或新建表。面试中应准备SQL优化案例,如覆盖索引、优化`order by`、`count`和索引提示。优化分页查询时避免大偏移量,可利用上一批的最大ID进行限制。
29 3
|
7天前
|
SQL 监控 数据库
数据库管理与电脑监控软件:SQL代码优化与实践
本文探讨了如何优化数据库管理和使用电脑监控软件以提升效率。通过SQL代码优化,如使用索引和调整查询语句,能有效提高数据库性能。同时,合理设计数据库结构,如数据表划分和规范化,也能增强管理效率。此外,利用Python脚本自动化收集系统性能数据,并实时提交至网站,可实现对电脑监控的实时性和有效性。这些方法能提升信息系统稳定性和可靠性,满足用户需求。
29 0
|
7天前
|
SQL 存储 数据挖掘
数据库数据恢复—RAID5上层Sql Server数据库数据恢复案例
服务器数据恢复环境: 一台安装windows server操作系统的服务器。一组由8块硬盘组建的RAID5,划分LUN供这台服务器使用。 在windows服务器内装有SqlServer数据库。存储空间LUN划分了两个逻辑分区。 服务器故障&初检: 由于未知原因,Sql Server数据库文件丢失,丢失数据涉及到3个库,表的数量有3000左右。数据库文件丢失原因还没有查清楚,也不能确定数据存储位置。 数据库文件丢失后服务器仍处于开机状态,所幸没有大量数据写入。 将raid5中所有磁盘编号后取出,经过硬件工程师检测,没有发现明显的硬件故障。以只读方式将所有磁盘进行扇区级的全盘镜像,镜像完成后将所
数据库数据恢复—RAID5上层Sql Server数据库数据恢复案例
|
8天前
|
人工智能 Cloud Native 算法
数据之势丨AI时代,云原生数据库的最新发展趋势与进展
AI与云数据库的深度结合是数据库发展的必然趋势,基于AI能力的加持,云数据库未来可以实现更快速的查询和决策,帮助企业更好地利用海量数据进行业务创新和决策优化。
数据之势丨AI时代,云原生数据库的最新发展趋势与进展
|
11天前
|
SQL 安全 Java
SQL server 2017安装教程
SQL server 2017安装教程
14 1