第一章:绪论
1.1数据库的四个基本概念
数据(Data)-
数据(Data)是数据库存储的基本对象。它是对现实世界中各种事物的符号化记录。数据的含义,通常被称为语义,是指数据所代表的具体内容,例如“成绩”、“体重”或“身高”。数据和语义是紧密相连的:数据本身是信息的载体,而语义则赋予了数据具体的含义和上下文。在数据库管理中,正确理解数据的语义对于确保信息的准确性和有用性至关重要。
例如,一个数字“83”在没有上下文的情况下是抽象的,但当我们知道这个数字代表的是某个学生的“成绩”时,它就具有了明确的意义。因此,在处理数据库中的数据时,不仅要关注数据本身,还要考虑其背后的语义,以确保数据的有效使用和管理。
数据库(Database)-
数据库(Database,简称DB)是长期储存在计算机内、有组织、可共享的大量数据的集合。数据库的主要特点包括:
-
按一定数据模型组织:数据库中的数据按照一定的数据模型(如关系模型、层次模型等)来组织。这些模型定义了数据的结构、约束和操作方式。
-
可被共享:数据库支持多用户访问,数据可以被多个用户或应用程序共享,提高了数据的利用率和协作效率。
-
冗余度较小:数据库设计时考虑到减少数据冗余,即同一数据不重复存储,这样可以节省存储空间,并减少数据不一致性的风险。
-
数据独立性较高:数据库系统实现了数据和程序的独立性。这意味着,应用程序和数据的物理存储相互独立,改变存储方式不会影响到应用程序的运行。
-
易拓展:数据库设计考虑到了未来的扩展性,可以方便地增加新的数据或修改数据结构,以适应不断变化的需求。
数据库在现代信息管理中扮演着核心角色,它们为各种类型的数据提供了有效的存储、检索、更新和管理手段。
数据库管理系统(DBMS)-
数据库管理系统(DBMS,Database Management System)是位于用户与操作系统之间的数据管理软件。它负责科学地组织、存储数据,以及高效地获取和维护数据。DBMS的主要功能包括:
-
数据定义语言(DDL):DBMS提供DDL,允许用户定义数据库中的数据对象,如表、视图等。它还负责分类组织、存储和管理各种数据,确定数据的文件结构和存取方式,以及实现数据之间的联系。
-
数据操纵语言(DML):通过DML,用户可以实现数据库的基本操作,包括查询、插入、删除和修改数据。这些操作是数据库日常使用中最常见的功能。
-
存取方法:DBMS提供多种存取方法,以提高数据存取效率。这些方法可能包括索引、哈希、聚簇等,以适应不同的数据访问需求。
-
数据安装、装卸和分类:DBMS负责数据的安装、装卸和分类,确保数据的有效组织和管理。
-
数据包装:DBMS还负责数据的包装,即数据的格式化和转换,以便于不同系统和应用程序之间的数据交换。
-
与其他数据网络的联系互访:DBMS支持与其他数据库和网络的数据交换和互访,从而实现数据的共享和集成。
总之,数据库管理系统是数据库生命周期的核心,它不仅负责数据的物理存储,还提供了数据定义、操作、维护和访问的全面支持,确保数据库的高效、安全和可靠运行。
数据库系统(DBS)-
数据库系统(DBS,Database System)是一个复杂的系统,由多个关键组件构成,包括:
-
数据库(Database):这是系统的核心,用于存储和管理大量数据。数据库按照一定的数据模型组织,如关系模型、层次模型等。
-
数据库管理系统(DBMS,Database Management System):DBMS是数据库系统的关键软件,负责数据的组织、存储、检索和维护。它提供了数据定义语言(DDL)和数据操纵语言(DML),以及多种存取方法,确保数据的有效管理和高效访问。
-
应用程序(Applications):应用程序是利用数据库中的数据进行操作和处理的软件。这些应用程序可以是定制的,也可以是通用的,如报告生成器、数据分析工具等。
-
管理员(Administrators):数据库管理员负责数据库系统的日常管理和维护,包括备份和恢复、性能监控、安全控制等。
数据库系统的关键优势在于其能够提供高效、可靠、安全的数据管理。它支持多用户访问,保证了数据的一致性和完整性,同时提供了灵活的数据访问和查询能力。数据库系统广泛应用于各种领域,如商业、科研、教育等,是现代信息技术的基石。
1.1.1小结
数据库是一个共享的数据集合,它具有以下关键特性:
-
最小冗余度:数据库设计时考虑减少数据冗余,即同一数据不重复存储,这有助于节省存储空间并降低数据不一致性的风险。
-
较高的数据独立性:数据库系统实现了数据和程序的独立性。这意味着,应用程序和数据的物理存储相互独立,改变存储方式不会影响到应用程序的运行。
数据库管理系统(DBMS)在数据库的建立、运用和维护过程中起着核心作用,其主要职责包括:
-
统一控制:DBMS对数据库进行统一管理,确保数据的一致性和准确性。
-
保证数据完整性:DBMS通过实施各种约束(如主键、外键等)来保证数据的完整性。
-
安全性控制:DBMS提供安全性控制,确保只有授权用户才能访问数据库,并保护数据免受未授权访问或破坏。
-
并发控制:在多用户同时使用数据库时,DBMS实施并发控制,以防止数据冲突和确保数据的一致性。
-
故障恢复:在发生系统故障或数据损坏时,DBMS负责对数据库进行恢复,确保数据的可靠性和持久性。
总之,数据库和数据库管理系统是现代信息管理的基础,它们提供了高效、安全、可靠的数据存储、检索和维护手段。
1.2数据模型
数据模型是对现实世界数据特征的抽象表示,它模拟了现实世界中的数据及其相互关系。数据模型是数据库系统的核心和基础,因为它决定了数据的组织、存储、操作和约束方式。具体来说,数据模型包括:
-
数据结构:定义了数据如何组织、存储,以及数据之间的关系。
-
数据操作:描述了对数据可以执行的操作,如查询、插入、删除和修改。
-
数据约束:确保数据的准确性和一致性,包括实体完整性、参照完整性等约束。
数据模型可以分为多种类型,如:
-
关系模型:以表格形式组织数据,表格中的行表示记录,列表示字段。关系模型是最常用的数据模型之一。
-
层次模型:以树状结构组织数据,其中每个记录有一个父记录和多个子记录。
-
网络模型:类似于层次模型,但允许一个记录有多个父记录。
-
面向对象模型:将数据组织为对象,每个对象包含数据和操作这些数据的方法。
每种数据模型都有其特点和适用场景,选择合适的数据模型对于数据库设计至关重要。
121两类数据模型
数据模型主要分为两类:概念模型和逻辑/物理模型。
概念模型:
概念模型是一种信息模型,它从用户的观点出发,对数据和其相关信息进行建模。这种模型主要用于数据库设计阶段,帮助设计人员理解并模拟现实世界的需求。概念模型通常使用实体-关系图(ER图)来表示,它关注数据的意义和用途,而不涉及具体的实现细节。
逻辑模型和物理模型:
-
逻辑模型:逻辑模型从计算机系统的角度对数据和信息进行建模。它包括了多种数据模型,如网状模型、层次模型和关系模型等。逻辑模型用于DBMS的实现,它定义了数据的结构、操作和约束,但仍然独立于具体的数据库管理系统和硬件。
-
物理模型:物理模型是数据最底层的抽象,它描述了数据在系统内部和设备上的表示和存取方法。物理模型涉及到数据的实际存储方式和存取路径,是DBMS直接管理和操作的部分。
这些模型的转换可以简单地理解为:
现实世界(用户需求)→ 概念模型(设计人员)→ 逻辑模型(设计人员+设计工具)→ 物理模型(DBMS实现)
在这个过程中,每个模型都提供了不同层次的抽象,从用户的需求到最终的物理实现,逐步细化和具体化。
122概念模型
概念模型用于信息世界的建模,它是现实世界到机器世界的中间层次。作为设计的有力工具,概念模型是设计人员和用户之间交流的语言,它要求具有较强的语义表达,同时简单清晰,易于用户理解。
在信息世界中,概念模型涉及以下基本元素:
-
实体:代表现实世界中的客观存在,如人、地点、事物等。
-
属性:实体所具备的某种特征,如人的年龄、地址等。
-
码:可以唯一标识一个实体的属性集,如学生的学号。
-
实体型:表示某种集合实体的名称,如“学生”是一个实体型。
-
实体集:同类型实体的集合,如所有学生的集合。
-
联系:实体型内部或实体型之间的联系,可能是一对一、一对多或多对多关系。
因此,概念模型通常采用实体-联系方法(Entity-Relationship Method,简称E-R方法或E-R模型)进行表示。E-R模型使用实体、属性和联系等基本元素,通过实体-关系图(ER图)来直观地表示信息世界中的结构和关系。
E-R模型的主要优点是它的直观性和易于理解,这使得它成为数据库设计和需求分析中的一个重要工具。
123数据模型的组成要素(逻辑模型的铺垫)
数据模型主要由三个关键要素组成,分别是数据结构、数据操作和数据的完整性约束条件。
数据结构:
数据结构描述了组成对象以及对象之间的联系。它是对系统静态特性的描述,包括数据的类型、内容、属性以及数据之间的关联方式。数据结构定义了数据的组织形式,是数据模型的基础。例如,在关系模型中,数据结构通常以表格形式表示,其中行表示记录,列表示字段。
数据操作:
数据操作定义了对各种数据类型的值允许执行的操作。这些操作包括查询和更新(插入、删除、修改)等。数据操作是对系统动态特性的描述,它决定了如何对存储在数据库中的数据进行访问和修改。例如,SQL(Structured Query Language)是一种广泛使用的数据操作语言,它允许用户查询和操作数据库中的数据。
数据的完整性约束条件:
数据的完整性约束条件是一组完整性规则的集合,这些规则确保数据的正确性、有效性和相容性。完整性约束定义了数据及其联系所必须遵循的规则,如主键约束、外键约束、唯一性约束和检查约束等。这些约束保证了数据库中数据的准确性和一致性,防止了不合法或不一致数据的出现。
综上所述,数据模型通过这三个要素为数据库的设计和实现提供了基础框架和规则,确保了数据库系统的有效性和可靠性。
124层次模型(逻辑模型)
层次模型是最早出现的数据模型之一,其典型代表是IBM公司的IMS(Information Management System)。层次模型使用树形结构来表示实体及其实体间的联系。
层次模型的条件:
层次模型必须满足以下条件:
-
根结点:有且只有一个结点没有双亲结点,这个结点被称为根结点。
-
双亲结点:除了根结点外,其他每个结点有且只有一个双亲结点。双亲结点是树结构中的一部分,如果某个结点不再细分,则它不是双亲结点,而是叶结点。
例如,在一个公司层次结构中,公司本身是根结点,部门是双亲结点,而员工则是叶结点。
数据操作:
层次模型的数据操作包括基础的四项:查询、插入、删除和修改。
完整性约束条件:
-
无双亲约束:每个结点(除了根结点)必须有一个双亲结点。
-
无子女约束:叶结点没有子女结点。
-
删除操作:删除双亲结点时,其所有子女结点也会被删除。
-
更新操作:更新操作时,必须更新所有相应的记录,以保证数据的一致性。
优点:
-
层次结构简单清晰,便于理解和查询。
-
性能高,尤其是在查询和性能方面。
-
数据完整性较好,因为结构定义了明确的父子关系。
缺点:
-
结点的多对多联系表示不自然,通常需要通过引入额外的结点(例如,使用重复的双亲)来解决。
-
更新操作限制较大,因为必须遵循严格的层次结构。
-
程序编写相对复杂,因为查询子女结点必须通过其双亲结点。
-
层次命令和操作不如其他模型(如关系模型)直观和灵活。
125网状模型(逻辑模型)
网状模型是数据库设计的一种逻辑结构,其典型代表是DBTG系统,也称为CODASYL系统。在实践应用中,网状模型被多个数据库系统采用,如Cullinet Software公司的IDMS、Univac公司的DMS1100,以及其他系统如IDS/2、IMAGE等。
网状模型的条件:
网状模型与层次模型的主要区别在于:
-
多根结点:允许一个以上的结点无双亲,即可以有多个根结点。
-
多双亲结点:允许一个结点可以有多个双亲。
与层次模型相比,网状模型的特点包括:
-
允许多个结点无双亲,从而提供更灵活的数据组织方式。
-
允许一个结点有多个双亲,这更直接地反映了现实世界中的复杂关系。
-
两个结点间可以有复合的联系,即多对多的关系。
-
更直接地描述现实世界,层次模型实质上是网状模型的一个特例。
数据操作:
网状模型对数据操作(查询、插入、删除、修改)增加了一些限制,主要是由于数据的复杂关系导致的。
完整性约束条件:
-
码:唯一表示数据项的集合,确保数据的唯一性。
-
一对多联系:一个联系中的双亲与子女是一对多联系,即一个双亲可以有多个子女,但一个子女只能有一个双亲。
优点:
-
更直接地描述现实世界中的复杂关系。
-
良好的性能和存取效率。
缺点:
-
结构和语言随着发展变得更加复杂,这不利于用户掌握。
-
联系是通过存取路径实现的,因此用户需要了解系统结构的细节,增加了使用的复杂性。
126关系模型(逻辑模型)
关系模型是由IBM公司的EF.Codd提出的一种数据模型。目前,几乎所有新推出的数据库管理系统都支持关系模型。
逻辑结构:
关系模型的逻辑结构可以类比为Excel表格,易于理解和操作。
包含的要素:
-
关系:在关系模型中,数据被组织成表格,每个表格被称为一个关系。
-
元组:关系中的每一行称为一个元组,代表一个数据记录。
-
属性:关系中的每一列称为一个属性,相当于表头,定义了数据类型和格式。
-
主码:属性组,可以唯一标识关系中的每个元组。
-
域:具有相同数据类型值的集合,是属性的取值范围。
-
分量:元组中的一个属性值。
-
关系模式:描述关系的结构,可以嵌套,即一个大属性嵌套一个个小属性。
数据操作:
关系模型的数据操作包括查询、插入、删除和修改,这些操作与传统数据库操作相同。
完整性约束条件:
-
实体完整性:确保每个元组在主属性上都是唯一的。
-
参照完整性:保持关系中不同表之间的引用一致性。
-
定义完整性:确保属性的定义遵循数据库的规则和约束。
优点:
-
建立在严格的数学概念基础上,提供了清晰的数据表示方法。
-
实体和各类联系都是用关系来表示,便于理解和操作。
-
存取路径对用户透明,保障了数据独立性和安全保密性。
-
简化了数据库的设计、管理和使用。
缺点:
-
查询效率在某些情况下可能不如格式化数据模型。
-
为提高性能,可能需要对查询请求进行优化。
-
增加了开发数据库管理系统的难度,特别是在处理复杂查询和大数据量时。
1.3数据库系统的结构
数据库系统通常采用三级模式结构,这是系统内部的逻辑结构,包括外模式、概念模式和内模式。这种结构有助于实现数据的独立性,使得用户和应用程序可以独立于数据的物理存储。
从“最终用户”的角度看,数据库系统的结构可以分为以下几种类型:
-
单用户结构:在这种结构中,数据库系统运行在单个用户的计算机上,适用于个人或小型企业。
-
主从式结构:在这种结构中,有一个主数据库服务器,多个从客户端连接到这个服务器。主服务器负责数据的管理和存储,而从客户端负责数据的应用和展示。
-
分布式结构:在分布式结构中,数据被存储在多个地理位置不同的数据库中,这些数据库通过网络连接,协同工作,提供全局的数据访问。
-
客户-服务器结构:在这种结构中,客户端负责数据的应用和展示,而服务器负责数据的管理和存储。客户端和服务器通过网络连接,客户端向服务器发送请求,服务器响应这些请求。
-
浏览器-应用服务器/数据库服务器多层结构:这是Web应用常用的结构。用户通过浏览器访问应用服务器,应用服务器处理业务逻辑,与数据库服务器交互,数据库服务器负责存储数据。
这些不同的结构适用于不同的应用场景和需求,提供了灵活性和可扩展性,使得数据库系统能够满足各种复杂的应用需求。
131数据库系统字段定义
在数据库系统中,字段定义是理解数据库结构的关键。以下是字段定义的几个重要概念:
-
型(Type):型是对某一类数据的结构和属性的说明或定义。它描述了数据的数据类型、格式和大小等属性。例如,整数型、字符串型、日期型等。
-
值(Value):值是型的具体赋值,它代表了实际存储在数据库中的数据。每个型可以有多个值,这些值必须符合型的定义。
-
模式(Schema):模式是对型的描述,它不涉及具体的值,而是描述了数据库的逻辑结构和特征。模式反映了数据的结构和联系,通常是相对稳定的,不会频繁变动。
-
实例(Instance):实例是模式的具体值,它反映了数据库在某一时刻的状态。同一模式可以有多个实例,随着数据的更新和变化,这些实例也会相应地改变。
例如,在一个学生信息数据库中,型可以定义为“学生编号”为整数型,“姓名”为字符串型,“出生日期”为日期型。这些型定义了数据表的结构。然后,每个学生的一条记录就是一个实例,包含了具体的值,如学生编号、姓名和出生日期。
132数据库系统的三级模式结构
数据库系统的三级模式结构包括模式、外模式和内模式,它们共同构成了数据库系统的逻辑结构。
-
模式(Schema):
- 也称逻辑模式,它是数据库系统中唯一的一个模式,位于外模式和内模式之间,起到衔接的作用。
- 模式描述了数据库中所有数据的逻辑结构和特征,与具体的应用程序、开发工具、高级程序语言等无关。
- 它定义了数据项的名字、类型、取值范围等,以及数据的安全性和完整性要求。
-
外模式(External Schema):
- 外模式是用户使用的局部逻辑结构和特征的描述,它是数据的视图,通常是一个应用有关的数据的逻辑表示。
- 外模式通常是模式的子集,而应用通常是外模式的子集。这种一对多的关系保证了数据库的安全性,用户只能检索和访问外模式中的数据。
-
内模式(Internal Schema):
- 内模式描述了数据的物理结构和存储方式,它是数据库内部的表示方式。
- 内模式包括存储方式(如顺序存储、B树结构存储、哈希方法存储等)、索引的组织方式、是否压缩存储、是否加密、记录结构的规定等。
- 每个数据库只有一个内模式,它决定了数据在物理存储设备上的存储方式和访问方法。
三级模式结构的主要优点是实现了数据的独立性,即数据的物理存储方式和逻辑结构相互独立,这使得数据库系统更加灵活和易于维护。用户可以通过外模式来访问数据,而不必关心数据的物理存储细节。
133数据库的二级映像功能与数据独立性
数据库系统的三级模式结构(模式、外模式、内模式)为数据的抽象提供了三个级别。二级映像功能负责在数据库管理系统(DBMS)中实现这三个抽象级别的联系和转换,确保了数据独立性的实现。
映像的级别:
-
外模式/模式映像:
- 外模式/模式映像负责实现数据的逻辑独立性。
- 当模式(逻辑结构)发生变化时,只需修改外模式/模式映像,而外模式保持不变。
- 这意味着应用程序不需要改变,因为它们是基于外模式编写的。
-
模式/内模式映像:
- 模式/内模式映像定义了数据的全局逻辑结构与存储结构之间的对应关系。
- 由于模式和内模式在数据库中是唯一的,模式/内模式映像通常包含在模式描述中。
- 当数据库的存储结构发生变化时(如存储方式、索引组织、压缩存储等),只需修改模式/内模式映像,模式保持不变。
- 这保证了数据的物理独立性,即应用程序也不受影响。
数据独立性的意义:
- 逻辑独立性:应用程序与数据的逻辑结构相互独立,模式的变化不会影响应用程序。
- 物理独立性:数据的物理存储方式与应用程序相互独立,存储结构的改变不会影响应用程序。
二级映像功能是实现数据独立性的关键,它提高了数据库系统的灵活性和可维护性,使得数据库管理员可以更自由地更改数据库的存储和逻辑结构,而无需担心应用程序的兼容性问题。
1.4数据库系统的组成
数据库系统是一个复杂的系统,它由多个组成部分构成,这些组成部分共同工作,确保数据库的高效、安全运行。
-
人员:
- 数据库管理员(DBA):负责决定数据库中的信息内容和结构,决定存储结构、存取策略,定义数据的安全性和完整性约束条件,监控数据库的使用和运行,包括周期性文件转储、系统故障修复、介质故障修复、监视审计文件等。
- 系统分析员和数据库设计人员:负责数据库的三级模式设计和管理。
- 应用程序员:负责开发与数据库接口的应用程序,特别是外模式和客户端的衔接。
- 最终用户:负责使用客户端应用程序与数据库系统交互。
-
硬件平台及数据库:
- 硬件平台需要满足一定的性能要求,包括足够大的内存、磁盘空间,以及较高的通道能力(数据传送率)。
-
软件:
- 支持DBMS运行的操作系统和编译系统。
- 与DBMS结合的高级语言和编译系统。
- 以DBMS为核心的应用开发工具。
- 为特定应用开发的数据库应用系统。
-
数据库管理系统(DBMS):
- 是数据库系统的核心,负责数据库的存储、管理和维护。
-
应用程序(APP):
- 基于DBMS开发的各种应用程序,用于数据的查询、插入、更新和删除等操作。
-
数据库(DB):
- 存储数据的集合,是数据库系统的核心。
对数据库管理员DBA的要求包括:
- 决定数据库中的信息内容和结构。
- 决定存储结构、存取策略。
- 定义数据的安全性和完整性约束条件。
- 监控数据库的使用和运行。
- 数据库的改进和重组。
数据库系统的这些组成部分协同工作,确保了数据的存储、管理、查询和维护的高效性和安全性。
第二章:关系数据库
2.1关系数据结构及形式化定义
211关系
关系模型是数据库理论中的一个核心概念,用于表示现实世界中的实体及其相互之间的联系。在关系模型中,数据的逻辑结构被组织成二维表的形式,这些表被称为“关系”。
以下是关系模型中几个重要的概念:
-
域(Domain):域是具有相同数据类型的值的集合。例如,姓名集合(如“张三”、“李四”)可以构成一个域。
-
笛卡尔积(Cartesian Product):笛卡尔积是由一组域的取值组成的组合,其中每个元素都是唯一的。笛卡尔积的每个元素称为一个元组(Tuple),其中元组中的每个值称为分量(Component)。例如,如果域D1有m1个元素,域D2有m2个元素,那么D1和D2的笛卡尔积的基数M(即可能的组合数)是m1*m2。笛卡尔积可以表示为一个二维表,其中每行代表一个元组,每列代表一个域。
-
关系(Relation):关系是笛卡尔积的任意子集,表示为R(D1, D2, …, Dn),其中R是关系名,n是关系的度(Degree)。关系中的每个元素是一个元组。根据度的不同,关系可以分为一元关系(n=1)、二元关系(n=2)等。关系也是以二维表的形式表示,其中表的每行代表一个元组,每列代表一个域。
在关系中,每一列都有一个属性名,用于区分不同的域。即使不同列可能来自相同的域,一个n度关系也会有n个不同的属性。
码(Key):码是用于唯一标识关系中每个元组的一个属性或属性组。候选码是能唯一标识元组的最小属性组,而全码是包含所有属性的码。
关系还可以根据其用途和性质进行分类:
- 基本关系(Base Relation):实际存储数据的表,反映了数据的逻辑结构。
- 查询表(Query Table):查询结果对应的表。
- 视图表(View Table):不直接存储数据,而是基于基本表或其他视图表定义的虚表。
这些概念是理解关系数据库的基础,有助于在设计和使用数据库时做出更合理的决策。
212关系模式
关系模式(Relational Schema)是对关系(Relation)的抽象定义,它描述了关系的结构以及完整性约束。在关系数据库中,关系模式被视为“型”,而关系本身则是“值”。
关系模式主要由两部分组成:
-
元组集合的结构:这部分定义了关系中的属性集合。每个属性都有一个名称,并来自特定的域(Domain)。属性之间的映射关系定义了属性之间的逻辑联系。例如,在“专业”与“学生”的关系中,每个专业对应多个学生,而在“统计学”与“张良”的关系中,张良可能是统计学的一个实例。
-
完整性约束条件:这些是确保数据完整性和一致性的规则。完整性约束可以包括实体完整性(如主键不能为空)、参照完整性(外键的有效性)、用户定义的完整性等。
关系模式的描述是静态的,因为它定义了关系结构的不变特征。相比之下,关系是动态的,它代表某一时刻数据库中实际存储的数据。因此,关系模式提供了一个框架,而关系则是这个框架中的实际内容。
在实际应用中,关系模式是数据库设计的基础,它帮助确保数据的逻辑一致性和有效性。通过定义清晰的关系模式,数据库管理员和开发者可以更有效地管理和查询数据。
213关系数据库
关系数据库(Relational Database)是基于关系模型的数据库,其中数据以表格形式组织,每个表格称为一个关系。关系数据库的核心是管理这些关系的集合。
关系数据库具有两个主要方面:
-
型 - 关系数据库模式:这是对整个数据库结构的描述,包括所有关系的结构、属性、域以及完整性约束。关系数据库模式定义了数据库中可以存储哪些类型的数据,以及这些数据如何关联。它相当于数据库的蓝图,指导如何存储、管理和查询数据。
-
值 - 关系集合:这是在某一时刻数据库中实际存储的数据集合。每个关系(表格)包含一系列的元组(行),每个元组根据关系模式定义的属性和域存储数据。关系集合反映了数据库在某一特定时间点的状态。
关系数据库的优势在于其结构化查询语言(SQL),它允许用户以声明性的方式查询、插入、更新和删除数据。此外,关系数据库通常支持事务处理,确保数据的一致性和完整性。
关系数据库广泛应用于各种领域,包括企业级应用、个人项目、学术研究等。它们通过提供灵活、可靠和高效的数据管理方式,支持复杂的数据操作和数据分析。
2.2关系操作
在关系数据库中,常用的关系操作主要包括两大类:查询操作和数据更新操作。
-
查询操作:这些操作用于从数据库中检索数据。主要的查询操作包括:
- 选择(Selection):从关系中选出满足特定条件的元组。
- 投影(Projection):从关系中选出特定的列(属性)。
- 连接(Join):将两个关系中满足特定条件的元组组合起来。
- 除(Division):从关系中除以另一个关系,得到包含前一个关系中所有元组,但不包含后一个关系中任何元组的部分。
- 并(Union):合并两个关系中的所有元组,去除重复的元组。
- 差(Difference):从第一个关系中去除在第二个关系中出现的所有元组。
- 交(Intersection):选出两个关系中都存在的元组。
- 笛卡尔积(Cartesian Product):将两个关系的所有可能组合列出。
-
数据更新操作:这些操作用于修改数据库中的数据。主要包括:
- 插入(Insert):向关系中添加新的元组。
- 删除(Delete):从关系中移除元组。
- 修改(Update):更改关系中元组的某些属性值。
这些操作的对象和结果都是集合。这意味着,无论是查询还是更新,操作都是对整个元组集合进行的,而不是单个元组。
关系操作可以使用不同的语言表达,主要包括:
- 关系代数语言:如ISBL(Information System Base Language),通过一系列对关系的运算来表达查询。
- 关系演算语言:如APLHA、QUEL,使用谓词逻辑表达查询要求。
- 域关系演算语言:如QBE(Query By Example),基本对象是域。
- 具有代数和演算双重特点的语言:如SQL(Structured Query Language),是关系数据库中最常用的语言,它结合了关系代数和关系演算的特点,既强大又灵活。
这些语言和操作构成了关系数据库的核心,使得用户能够高效地管理和查询数据。
2.3关系的完整性
关系完整性是关系模型中确保数据准确性和一致性的关键特性。它主要通过完整性约束来实现,这些约束分为三类:实体完整性、参照完整性和用户定义的完整性。
-
实体完整性:这是关系模型的基本要求。它确保每个表都有一个唯一标识每个元组的属性或属性组合,即主键。主键的值不能为空(NULL),因为它们必须能够唯一标识表中的每个元组。例如,在学生信息表中,学号通常作为主键,它不能为空,以确保每个学生都能被唯一标识。
-
参照完整性:参照完整性涉及多个表之间的关系。当一个表(参照关系)中的外键与另一个表(被参照关系或目标关系)的主键相对应时,必须满足参照完整性。这意味着外键的值要么为空,要么等于被参照关系中某个元组的主键值。例如,如果一个表包含订单信息,另一个表包含客户信息,订单表中的客户ID(外键)必须匹配客户表中的某个客户ID(主键),或者为空。
-
用户定义的完整性:这类完整性约束反映了特定应用领域中的语义要求。它们是应用程序特定的,超出了标准实体和参照完整性的范围。例如,可以定义一个约束,确保订单表中的订单日期不早于客户表中的客户注册日期。用户定义的完整性应由关系模型提供机制来定义和检验,以确保处理的一致性和避免应用程序的复杂性。
这些完整性约束对于维护数据库中数据的准确性和一致性至关重要。它们帮助确保数据库的可靠性和有效性,同时简化了应用程序的开发和维护。
2.4关系代数
关系代数是一种用于查询关系数据库的抽象语言。它通过一系列对关系的运算来表达查询,其中运算的对象和结果都是关系。关系代数的运算符主要分为两大类:集合运算符和关系运算符。
-
集合运算符:这些运算符作用于两个或多个关系,类似于传统的集合运算。它们包括:
- 交(Intersection, ∩):选出两个关系中共同存在的元组。
- 并(Union, ∪):合并两个关系中的所有元组,去除重复的元组。
- 差(Difference, -):从第一个关系中去除在第二个关系中出现的所有元组。
- 笛卡尔积(Cartesian Product, X):将两个关系的所有可能组合列出。
-
关系运算符:这些运算符通常作用于单个关系,用于从关系中提取特定的数据。它们包括:
- 选择(Selection):从关系中选出满足特定条件的元组。
- 投影(Projection, π):从关系中选出特定的列(属性)。
- 连接(Join):将两个关系中满足特定条件的元组组合起来。
- 除(Division, ÷):从关系中除以另一个关系,得到包含前一个关系中所有元组,但不包含后一个关系中任何元组的部分。
关系代数为数据库查询提供了强大的表达方式。它允许用户以非常精确和结构化的方式来定义和执行查询,从而有效地从数据库中检索和操作数据。
241传统的集合运算
在关系代数中,传统的集合运算之一是笛卡尔积。笛卡尔积是一种特殊的集合运算,用于将两个关系的所有可能组合列出。当两个关系R和S进行笛卡尔积运算时(表示为 R × S),结果是一个新的关系,其元组数量是R和S元组数量的乘积。
具体来说,如果关系R有n个元组,每个元组有k1个属性,而关系S有m个元组,每个元组有k2个属性,那么R × S的结果将是一个有n × m个元组的关系,每个元组有k1 + k2个属性。
以一个具体的例子来说明:
假设关系R是:
a | b |
---|---|
c | d |
关系S是:
e | f |
---|---|
g | h |
那么R × S的结果将是:
a | b | e | f |
---|---|---|---|
c | d | e | f |
a | b | g | h |
c | d | g | h |
在这个结果中,每个R中的元组与每个S中的元组都组合了一次。这个运算不关心两个关系之间是否有实际的关联,它只是简单地将两个关系的所有可能组合列出。
242专门的关系运算
在关系代数中,专门的关系运算包括选择、投影、连接和除。这些运算用于从数据库中提取和组合特定的数据。
-
选择(Selection):选择运算符(用符号¥表示)用于从关系中选出满足特定条件的元组。这些条件通过逻辑表达式来定义。例如,选择运算符可以用来找出所有年龄大于18岁的学生。
-
投影(Projection):投影运算符用于从关系中提取特定的列(属性)。它创建一个新关系,其中只包含原关系中的某些属性。例如,如果关系中有学生的详细信息,投影运算可以用来提取学生所在系的类别和专业类别。
-
连接(Join):连接运算符(用符号+表示)用于将两个关系的元组组合起来,基于它们共同的属性值。连接分为等值连接和自然连接。等值连接基于两个关系中相等的属性值,而自然连接除了基于相等属性值外,还会去除重复的属性。当连接关系中存在不匹配的元组时,这些元组被称为悬浮元组。外连接是一种特殊的连接,即使某些元组在另一个关系中没有匹配,也会保留这些元组,并在其他属性上填入空值。
-
除(Division):除运算符用于找出哪些元组在除数关系中对应的所有属性值都出现在被除数关系中。例如,可以用来找出参加了所有指定项目的运动员。
综合举例:
假设有三个关系:运动员(运动员号,姓名,性别,年龄,班级号),项目(项目号,项目名,比赛地),比赛(运动员号,项目号,成绩,名次)。
要求找出运动员张三参与的项目名和成绩,可以使用以下运算:
π项目名,成绩(¥姓名=“张三”(运动员+项目+比赛))
要找出同时参加了跳远和铅球项目的运动员号,可以使用以下运算:
π运动员号,项目号(比赛)÷π项目号(¥项目名=“跳远” V 项目名=“铅球”(项目))
这些运算符提供了强大的工具,用于从关系数据库中提取和组合数据。
第三章:关系数据库标准语言SQL
3.1SQL概述
312SQL的特点
SQL(Structured Query Language)作为数据库语言,具有几个显著的特点,这些特点使其成为管理和查询关系数据库系统的强大工具。
-
综合统一:SQL集数据定义语言(DDL)、数据操纵语言(DML)、数据控制语言(DCL)的功能于一体。这意味着SQL可以独立完成数据库生命周期中的所有活动,包括创建(CREATE)、修改(ALTER)、删除(DROP)数据库对象,查询(SELECT)、插入(INSERT)、更新(UPDATE)、删除(DELETE)数据,以及控制数据的访问权限(GRANT, REVOKE)。
-
高度非过程化:SQL是一种声明式语言,用户只需指定需要的结果,而不需要编写达到该结果的详细步骤。例如,在执行查询时,用户只需指定需要哪些数据,而不需要编写获取这些数据的详细算法。
-
面向集合的操作方式:SQL采用集合操作方式,这意味着操作的对象和查找结果不是单个记录,而是元组的集合。例如,一个SQL查询可能会返回满足特定条件的所有记录的集合,而不是单条记录。这种集合操作方式使得SQL非常适合处理大量数据。
-
以同一种语法结构提供多种使用方式:SQL既可以作为独立的语言使用,也可以作为嵌入式语言集成在其他编程语言中。这使得SQL具有很高的灵活性和适应性。
-
语言简洁,易学易用:SQL的语法相对简洁,核心命令如SELECT、CREATE、DROP、ALTER、INSERT、UPDATE、DELETE、GRANT和REVOKE等易于学习和使用。这种简洁性使得SQL成为广泛使用的数据库语言,即使是非专业的数据库用户也能够快速上手。
总的来说,SQL的特点使其成为数据库管理的一个强大而灵活的工具,适用于各种规模和复杂度的数据库应用。
313SQL的基本概念
SQL支持关系数据库的三级模式结构,包括外模式(External Schema)、模式(Schema)和内模式(Internal Schema)。这种结构使得SQL能够有效地处理数据库的逻辑和物理层面。
-
基本表(Base Table):在SQL中,基本表是一个独立存在的表,它对应关系数据库中的一个关系。每个基本表在数据库中有一个唯一的名称,并且对应一个存储文件。基本表通常包含数据,并且可以有一个或多个索引来提高查询效率。基本表是数据库中实际存储数据的地方。
-
存储文件:存储文件包含了基本表的数据,并具有两个结构:逻辑结构和物理结构。逻辑结构是用户可以看到和操作的关系模式,而物理结构则涉及数据在磁盘上的实际存储方式。物理结构对用户是隐蔽的,由数据库管理系统(DBMS)负责管理。
-
视图(View):视图是从一个或多个基本表中导出的虚拟表。它不存储数据,而是存储了视图的定义,即一个SQL查询。当查询视图时,数据库系统会根据视图的定义动态地生成数据。视图可以用来简化复杂的查询,提供数据的逻辑抽象,或者限制对数据的访问。用户可以在视图上再定义视图,从而创建更加复杂的逻辑数据结构。
SQL的基本概念还包括其他元素,如索引、约束、触发器等,这些都是数据库设计和操作中不可或缺的部分。理解这些基本概念对于有效地使用SQL进行数据库管理和查询至关重要。
3.2学生-课程数据库
学生-课程数据库是一个常见的关系数据库示例,用于管理学生、课程和成绩信息。这个数据库通常包含以下三个基本表:
-
Student(学生表):
- Sno(学号):唯一标识每个学生的编号。
- Sname(姓名):学生的姓名。
- Ssex(性别):学生的性别。
- Sage(年龄):学生的年龄。
- Sdept(所在系):学生所在的系或专业。
-
Course(课程表):
- Cno(课程号):唯一标识每个课程的编号。
- Cname(课程名):课程的名称。
- Cpno(先行课):如果该课程有先行课程,则记录先行课程的课程号。
- Ccredit(学分):该课程对应的学分。
-
SC(成绩表):
- Sno(学号):学生的学号。
- Cno(课程号):课程的课程号。
- Grade(成绩):学生在对应课程中的成绩。
3.3数据定义
在关系数据库中,数据定义涉及到创建、修改和删除数据库对象,这些对象包括模式(Schema)、表、视图、索引等。这些操作按照操作对象和操作方式的不同,有不同的SQL语句。
-
模式(Schema):
- 创建模式:使用
CREATE SCHEMA
语句。 - 删除模式:使用
DROP SCHEMA
语句。 - 模式定义:模式定义了数据库中对象的组织结构,它不能被修改。在现代数据库管理系统中,模式通常与特定的用户或应用程序相关联,用于组织和管理对象。
- 创建模式:使用
-
表(Table):
- 创建表:使用
CREATE TABLE
语句。 - 删除表:使用
DROP TABLE
语句。 - 修改表:使用
ALTER TABLE
语句。 - 表定义:表是数据库中存储数据的主要结构。每个表由一系列列(字段)组成,每个列都有特定的数据类型。表定义了数据的结构,可以被创建、删除和修改。
- 创建表:使用
-
视图(View):
- 创建视图:使用
CREATE VIEW
语句。 - 删除视图:使用
DROP VIEW
语句。 - 视图定义:视图是基于表的查询结果集,它不存储数据,而是存储了查询的定义。视图可以被创建和删除,但不能直接修改。视图提供了一种抽象,可以简化复杂的查询,并提供数据的逻辑视图。
- 创建视图:使用
-
索引(Index):
- 创建索引:使用
CREATE INDEX
语句。 - 删除索引:使用
DROP INDEX
语句。 - 修改索引:使用
ALTER INDEX
语句(在某些数据库系统中)。 - 索引定义:索引是一种特殊的数据库对象,用于提高查询效率。它可以基于表中的一个或多个列创建。索引可以被创建、删除和修改,以优化查询性能。
- 创建索引:使用
在现代化的数据库管理系统中,通常提供了一个层次化的数据库对象命名机制,这包括数据库、模式、表以及视图、索引等。这种层次化的结构有助于管理和组织复杂的数据库系统,同时提高数据的安全性和管理效率。
331模式的定义与删除
在SQL中,模式的定义和删除是数据库管理的重要部分。以下是创建和删除数据库的SQL语句的详细说明。
数据库的创建
-
关键字:
CREATE DATABASE
用于创建一个新的数据库。 -
数据库文件名:这是新数据库的名称。
-
数据文件和日志文件的定义:使用
ON
关键字后跟文件组定义。数据文件和日志文件可以通过以下参数进行定义:NAME
:指定数据库文件的逻辑名称。FILENAME
:指定数据库文件的实际路径和文件名。SIZE
:指定数据库文件的初始大小。UNLIMITED
:表示数据库文件的大小没有限制。FILEGROWTH
:指定数据库文件的增长量。
例如,创建数据库的SQL语句可能如下所示:
CREATE DATABASE StudentSys ON ( NAME='StudentSys', FILENAME='E:\StudentSys.mdf', SIZE=3MB, FILEGROWTH=1MB, MAXSIZE=UNLIMITED ) LOG ON ( NAME='StudentSys_log', FILENAME='E:\StudentSys_log.ldf', SIZE=1MB, FILEGROWTH=10%, MAXSIZE=100MB )
这段代码创建了一个名为
StudentSys
的数据库,包括一个3MB的数据文件和1MB的日志文件,数据文件的最大容量为无限,日志文件的最大容量为100MB。
数据库的删除
删除数据库的SQL语句相对简单,只需使用DROP DATABASE
关键字后跟数据库的名称。例如:
DROP DATABASE StudentSys
这条语句将删除名为StudentSys
的数据库。
在实际应用中,创建和删除数据库是一个敏感的操作,需要谨慎处理,以避免数据丢失或系统错误。
332基本表的定义,删除与修改
在SQL中,基本表的定义、删除和修改是数据库管理的关键操作。以下是这些操作的详细说明。
基本表的定义
-
关键字:
CREATE TABLE
用于创建一个新的表。 -
表名:这是新表的名称。
-
列定义:使用
(列名 数据类型 [完整性约束条件])
格式定义表中的列。列名
:表中的列名称。数据类型
:定义列可以存储的数据类型,如整数、字符串、日期等。完整性约束条件
:包括主键、唯一、外键、检查等,用于确保数据的完整性和一致性。
例如,创建一个学生表的SQL语句可能如下所示:
CREATE TABLE Student ( Sno CHAR(9) PRIMARY KEY, Sname CHAR(20) UNIQUE, Ssex CHAR(2), Sage SMALLINT, Sdept CHAR(20) );
在这个例子中,
Sno
列被定义为主键,确保每个学生都有一个唯一的学号。Sname
列被定义为唯一,确保每个学生的姓名是唯一的。
基本表的删除
删除表的SQL语句相对简单,只需使用DROP TABLE
关键字后跟表的名称。例如:
DROP TABLE Student
这条语句将删除名为Student
的表。
基本表的修改
修改表的SQL语句使用ALTER TABLE
关键字。例如,可以添加新的列、删除列、修改列的数据类型或添加完整性约束等。
数据类型和完整性约束
SQL支持多种数据类型,如整数、字符串、日期等,以及各种完整性约束,如主键、唯一、外键、检查等。这些定义确保了数据的准确性和一致性。
这些操作是数据库设计和维护中的基本组成部分,对于有效管理数据库至关重要。
所有数据类型定义
数据类型 | 描述 |
---|---|
bigint | bigint类型表示大整型数,用8个字节存储。 |
int | int类型表示整型数,用4个字节存储。 |
smallint | smallint类型表示短整型数,用2个字节存储。 |
tinyint | tinyint类型表示极小整型数,用1个字节存储。 |
bit | bit类型表示二进制数,用1个字节存储。 |
decimal | decimal类型表示精确数值,用8-17个字节存储。 |
money | money类型表示货币数值,用8个字节存储。 |
float | float类型表示浮点数,用4或8个字节存储。 |
real | real类型表示单精度浮点数,用4个字节存储。 |
datetime | datetime类型表示日期和时间,用8个字节存储。 |
smalldatetime | smalldatetime类型表示日期和时间,用4个字节存储。 |
char | char类型表示定长字符串,长度为0-8000个字符之间。 |
varchar | varchar类型表示变长字符串,长度为0-8000个字符之间。 |
text | text类型表示文本字符串,长度为0-2^31个字符之间。 |
nchar | nchar类型表示Unicode定长字符串,长度为0-8000个字符之间。 |
nvarchar | nvarchar类型表示Unicode变长字符串,长度为0-8000个字符之间。 |
ntext | ntext类型表示Unicode文本字符串,长度为0-2^30个字符之间。 |
binary | binary类型表示定长二进制数据,长度为0-8000个字节之间。 |
varbinary | varbinary类型表示变长二进制数据,长度为0-8000个字节之间。 |
image | image类型表示图像二进制数据,长度为0-2^31个字节之间。 |
uniqueidentifier | uniqueidentifier类型表示全局唯一标识符(GUID)。 |
sql_variant | sql_variant类型表示包含数据库某个特定类型数据的特殊数据类型。 |
xml | xml类型表示存储XML文档,长度为0-2^31个字符之间。 |
表级完整性约束
约束类型 | 描述 |
---|---|
PRIMARY KEY | 定义表中的唯一标识符,每个表只能有一个主键(而不一定要有主键)。 |
FOREIGN KEY | 定义一个列或一组列与另一个表中的列之间的引用完整性。 |
CHECK | 定义在插入或更新数据时要满足的条件,如果插入或更新数据时不满足条件,则会抛出错误。 |
UNIQUE | 定义一组列中的所有值的唯一性。 |
DEFAULT | 为一个列定义默认值。 |
NOT NULL | 确保一个列不能包含 NULL 值。 |
列级完整性约束
约束类型 | 描述 |
---|---|
PRIMARY KEY | 定义一列或一组列的值唯一标识行。 |
FOREIGN KEY | 定义一个列或一组列与另一个表中的列之间的引用完整性。 |
CHECK | 定义插入或更新列数据时必须符合的条件。 |
UNIQUE | 定义该列中所有值必须唯一的约束。 |
NOT NULL | 指定该列不允许为 NULL |
DEFAULT | 指定默认值,当没有提供该列的值时就使用默认值。 |
COLLATE | 指定用于该列排序和比较的字符集或排序规则(collation)。 |
IDENTITY | 自动分配 唯一的数值 作为每个 新行的主键值。 |
ROWGUIDCOL | 使用GUID作为该列在行中的标识符。 |
DESCRIPTION | 描述该列包含的数据。 |
FILESTREAM | 定义FILESTREAM列。 |
SPARSE | 定义SPARSE列。 |
MASKED | 隐藏敏感数据。 |
ENCRYPTED | 加密敏感数据。 |
333修改基本表
在SQL中,修改基本表的操作包括增加新列、删除列、删除指定的完整性约束条件以及修改原有列的定义。以下是这些操作的详细说明。
增加新列
使用ALTER TABLE
语句和ADD COLUMN
子句来增加新列。新增加的列将默认包含空值,无论基本表中原来是否有数据。
ALTER TABLE Student
ADD S_entrance DATE;
这个例子表示在Student
表中增加了一个名为S_entrance
的日期类型新列。
删除列
使用ALTER TABLE
语句和DROP COLUMN
子句来删除列。
ALTER TABLE Student
DROP COLUMN S_entrance;
这个例子表示从Student
表中删除名为S_entrance
的列。
删除指定的完整性约束条件
使用ALTER TABLE
语句和DROP CONSTRAINT
子句来删除指定的完整性约束条件。
ALTER TABLE Student
DROP CONSTRAINT <约束名>;
这里<约束名>
是你要删除的约束的名称。
修改原有列的定义
使用ALTER TABLE
语句和ALTER COLUMN
子句来修改原有列的定义。
ALTER TABLE Student
ALTER COLUMN Sage INT;
这个例子表示将Student
表中Sage
列的数据类型从当前类型改为INT
类型。
删除基本表
使用DROP TABLE
语句来删除基本表。你可以使用RESTRICT
或CASCADE
选项。
RESTRICT
:如果表被其他对象引用,则不会删除表。CASCADE
:如果表被其他对象引用,则同时删除引用该表的所有对象。
DROP TABLE Student RESTRICT;
或
DROP TABLE Student CASCADE;
这些操作是数据库管理和维护中常见的任务,对于保持数据库的准确性和适应性非常重要。
334索引的建立与删除
索引是关系数据库中用于加快查询速度的重要机制。在SQL Server中,索引分为几种类型,每种类型都有其特点和适用场景。
常见索引类型
- 顺序文件上的索引:是最基本的索引类型,用于加快对数据的顺序访问。
- B+树索引:是最常用的索引类型,具有动态平衡的特点,适用于范围查询和等值查询。
- 散列(Hash)索引:适用于等值查询,特别快,但不支持范围查询。
- 位图索引:适用于数据分布稀疏的情况,但性能可能不如B+树索引。
SQL Server中的索引分类
- 聚集索引(Clustered Index):决定了表中数据的物理顺序。一个表只能有一个聚集索引。聚集索引适用于返回范围数据的查询,但更新数据时效率较低。
- 非聚集索引(Non-clustered Index):提供了数据行的多个引用。一个表可以有多个非聚集索引。非聚集索引适用于返回精确匹配数据的查询,更新数据时效率较高。
- 唯一索引(Unique Index):确保索引列中的值是唯一的。创建主键或唯一键时会自动创建唯一索引。
操作索引的命令
-
查看索引信息:
EXEC sp_helpindex <表名>
这个命令显示表中所有索引的信息。
-
删除索引:
DROP INDEX <表名>.<索引名>
这个命令删除表中的指定索引。
-
创建索引:
CREATE UNIQUE CLUSTERED INDEX <索引名> ON <表名>(<列名><次序>,...)
其中
UNIQUE
代表索引是否唯一,CLUSTERED
代表是否聚集索引,<次序>
默认为升序ASC
,降序为DESC
。
建立索引是数据库性能优化的重要手段,但过度索引可能会导致性能下降。因此,选择合适的索引类型和列对于提高查询效率至关重要。
3.4数据查询
341单表查询
在SQL中,单表查询是数据库操作的基础。一个典型的SQL查询语句由以下几个部分组成:
- SELECT - 指定要显示的属性列
- FROM - 指定查询对象(基本表或视图)
- WHERE - 指定查询条件
- GROUP BY - 对查询结果按指定列的值分组
- HAVING - 只有满足指定条件的组才予以输出
- ORDER BY - 指定列值的升序或降序
具体事例1 - SELECT FROM
-
查询全体学生的学号与姓名
SELECT Sno, Sname FROM Student
-
查询全体学生的姓名,学号,所在系
SELECT Sname, Sno, Sdept FROM Student
-
查询全体学生的全部信息
SELECT * FROM Student
注意:虽然
SELECT *
可以查询所有列,但通常不推荐在大型数据库中使用,因为它可能导致性能问题。
具体事例2 - WHERE
-
查询计算机科学系全体学生的名单
SELECT Sname FROM Student WHERE Sdept="CS"
-
查询所有年龄在20岁以下的学生姓名及其年龄
SELECT Sname, Sage FROM Student WHERE Sage<20
-
查询考试成绩有不及格学生的学号
SELECT DISTINCT Sno FROM SC WHERE grade<60
说明:这里使用
SC
表而不是Student
表,因为Student
表不包含成绩信息。
WHERE后面的条件
- [NOT] BETWEEN…AND…
- IN…NOT IN…
- [NOT] LIKE:使用
%...%
或...._....
进行模糊查询。- 例如:
WHERE title LIKE ‘%computer%’
将查询在title
中包含computer
的书。 刘%
查询姓刘的,%杰
查询尾部是杰的。WHERE au_fname LIKE ‘_ean’
将查询在au_fname
中任何以ean
结尾的四字单词。- 转义字符:如果查询内容里带
%
或_
,可以在前面加一个\
,在后面加一个ESCAPE'\'
。- 例如:
WHERE Cname LIKE 'DB\_Design' ESCAPE'\'
;
- 例如:
- 例如:
- IS [NOT] NULL:查询缺少数据的列。
- 缺少不是0,就是无数据输入。
具体实例3 - ORDER BY
ORDER BY <列名> [[ASC] DESC],...
- 例如:
ORDER BY Sdept, Sage DESC
- 使得查询内容按照系号升序排列,在相同系号中,再按照年龄降序排列。
具体实例4 - 聚集函数
- COUNT([DISTINCT|ALL]<列名>,…,*) - 统计值个数。
- SUM(…) - 统计值总和。
- AVG(…) - 统计值平均。
- MAX(…) - 统计值中最大。
- MIN(…) - 统计值中最小。
具体实例5 - GROUP BY
与聚集函数联合使用,例如:
SELECT Cno, COUNT(Sno)
FROM SC
GROUP BY Cno
在这个例子中,GROUP BY Cno
按课程号对学号进行分组,并计算每个课程的学号数量。
具体实例6 - HAVING
HAVING
子句作用于聚集函数,例如:
SELECT Cno, COUNT(Sno)
FROM SC
GROUP BY Cno
HAVING COUNT(Sno) > 10
这个查询将列出至少有10名学生选修的课程号及其学生数量。
342连接查询
当查询涉及两个或更多表时,如果不同表中的列名有重复,需要使用表名加列名的形式来明确指定,例如Student.Sno
表示Student
表中的Sno
列,而SC.Sno
表示SC
表中的Sno
列。
表别名
通过别名可以简化查询,也可以用于创建虚拟表。例如:
SELECT S.Sname
FROM Student S
WHERE S.Sname='王伟'
在这个例子中,S
是Student
表的别名,查询只返回Sname
为’王伟’的记录。
LEFT OUTER JOIN …ON
外连接用于确保即使右表中没有匹配的行,左表中的所有行也会在结果集中出现。例如:
SELECT *
FROM student s LEFT OUTER JOIN sc
ON s.sno=sc.sno
这个查询返回student
表的所有行,以及sc
表中与之匹配的行。如果sc
表中没有匹配的行,相关列将显示为NULL
。
嵌套查询
利用WHERE
条件中的IN
、ANY
、ALL
等关键字,可以在一个查询中嵌套另一个查询。例如:
SELECT *
FROM Student
WHERE Sno IN (SELECT Sno FROM SC WHERE grade > 80)
这个查询找出所有成绩大于80分的学生。
EXISTS()
EXISTS
用于检查子查询是否至少返回一行数据。例如:
SELECT *
FROM Student
WHERE EXISTS (SELECT * FROM SC WHERE SC.Sno = Student.Sno AND grade > 90)
这个查询返回所有至少有一个成绩超过90分的学生。
UNION和INTERSECT和EXCEPT
这些操作用于合并两个或多个查询的结果集:
- UNION:合并两个查询的结果,并去除重复行。
- UNION ALL:合并两个查询的结果,保留重复行。
- INTERSECT:返回两个查询结果的交集。
- EXCEPT:返回第一个查询结果减去第二个查询结果的差集。
3.5数据更新
351插入数据
在SQL中,可以向表中插入数据,有两种常见方式:插入元组或插入子查询结果。
插入元组
这是插入单个记录的方式。格式如下:
INSERT INTO <表名> ([<属性列1>], [<属性列2>], ...)
VALUES (<常量1>, <常量2>, ...);
<表名>
:指定要插入数据的表。[<属性列1>], [<属性列2>], ...
:可选,指定要插入数据的列。如果不指定,则默认为表中所有列,且插入时必须为所有列提供值。<常量1>, <常量2>, ...
:提供要插入的值,与列的顺序和类型对应。
例如,向Student
表插入一条学生记录:
INSERT INTO Student (Sno, Sname, Sdept)
VALUES (202301, '张三', '计算机科学');
插入子查询结果
这种方式可以将一个查询的结果插入到表中。格式如下:
INSERT INTO <表名> ([<属性列1>], [<属性列2>], ...)
子查询 (SELECT <列1>, <列2>, ... FROM <表2> WHERE <条件>);
<表名>
:指定要插入数据的表。[<属性列1>], [<属性列2>], ...
:可选,指定要插入数据的列。- 子查询:
SELECT
语句,其结果将插入到指定的表中。
例如,将SC
表中成绩大于90的学生的信息插入到HighPerformers
表中:
INSERT INTO HighPerformers (Sno, Sname, Grade)
SELECT Student.Sno, Student.Sname, SC.Grade
FROM Student, SC
WHERE SC.Grade > 90 AND Student.Sno = SC.Sno;
352修改数据
在SQL中,可以使用UPDATE
语句来修改表中的数据。根据修改的范围和条件,可以分为以下几种情况:
修改单个元组的值
这是修改表中特定行的数据。格式如下:
UPDATE <表名>
SET <属性列1>=<值1>, <属性列2>=<值2>, ...
WHERE <条件>;
<表名>
:指定要修改数据的表。<属性列1>=<值1>, <属性列2>=<值2>, ...
:指定要修改的列及其新值。WHERE <条件>
:指定要修改的行。条件必须唯一标识一行,通常使用主键或唯一索引。
例如,将Student
表中学号为202301的学生的系别改为“电子工程”:
UPDATE Student
SET Sdept='电子工程'
WHERE Sno=202301;
修改多个元组的值
如果不使用WHERE
子句,将修改表中所有行的指定列。格式如下:
UPDATE <表名>
SET <属性列1>=<值1>, <属性列2>=<值2>, ...;
注意:这种操作会修改表中所有行,应谨慎使用。
带子查询的修改语句
这种修改方式结合了UPDATE
和SELECT
语句,通过子查询来确定要修改的行。格式如下:
UPDATE <表名>
SET <属性列1>=<值1>, <属性列2>=<值2>, ...
WHERE <列名> IN (SELECT <列名> FROM <表名> WHERE <条件>);
例如,将所有与SC
表中成绩大于90的学生相同的学生在Student
表中的系别改为“优秀生”:
UPDATE Student
SET Sdept='优秀生'
WHERE Sno IN (SELECT Sno FROM SC WHERE Grade > 90);
353删除数据
在SQL中,可以使用DELETE
语句来删除表中的数据。根据删除的范围和条件,可以分为以下两种情况:
删除满足条件的元组
这是删除表中满足特定条件的行的数据。格式如下:
DELETE FROM <表名>
WHERE <条件>;
<表名>
:指定要删除数据的表。WHERE <条件>
:指定要删除的行。条件可以是任何返回真或假的逻辑表达式。
例如,删除Student
表中所有“计算机科学”系的学生记录:
DELETE FROM Student
WHERE Sdept='计算机科学';
删除所有元组
如果不使用WHERE
子句,将删除表中所有行。格式如下:
DELETE FROM <表名>;
注意:这种操作会删除表中所有数据,应谨慎使用。
3.6空值的处理
在SQL中,空值(NULL)表示数据缺失或不适用。处理空值时需要特别注意,因为它们在逻辑运算和比较运算中表现出独特的性质。
查找空值
要查找包含空值的列,可以在SELECT
语句中使用WHERE
子句,并使用IS NULL
条件。例如:
SELECT *
FROM Student
WHERE Sname IS NULL;
这个查询将返回Student
表中Sname
列有空值的记录。
空值的约束条件
在创建表时,可以设置约束条件来限制空值的出现:
- NOT NULL约束:确保列不能有空值。
- UNIQUE约束:确保列的所有值都是唯一的,同时也意味着列不能有空值。
- 主键约束:列被设置为主键时,自动包含了NOT NULL和UNIQUE约束。
空值的逻辑和算术运算
空值在逻辑和算术运算中有特殊的性质:
- 算术运算:任何包含空值的算术运算(如加、减、乘、除)的结果都是空值。
- 比较运算:与空值的比较运算(如
=
、<
、>
等)的结果是未知的(UNKNOWN),而不是真(TRUE)或假(FALSE)。因此,SQL实际上使用三值逻辑:真(T)、假(F)和未知(U)。
在逻辑运算中:
- AND运算:如果任一操作数为空值(U),则结果为空值(U)。例如,
T AND U = U
,U AND F = F
。 - OR运算:如果任一操作数为真(T),则结果为真(T)。例如,
T OR U = T
,U OR F = U
。 - NOT运算:
NOT U
的结果是空值(U)。
3.7视图
视图是数据库中的一个虚拟表,它是从一个或多个表中导出的。数据库中只存放视图的定义,而不存放视图对应的数据。因此,当基本表的数据发生变化时,从视图中查询的数据也会相应变化。
建立视图
使用CREATE VIEW
语句来创建视图。格式如下:
CREATE VIEW <视图名> [(<视图列1>, <视图列2>, ...)]
AS
<select-from-where查询块>
[WITH CHECK OPTION];
<视图名>
:指定视图的名称。<视图列1>, <视图列2>, ...
:可选,指定视图中包含的列名。<select-from-where查询块>
:定义视图的查询语句。WITH CHECK OPTION
:可选,确保对视图的所有更新操作都符合WHERE
条件。
例如,创建一个名为View_Students
的视图,包含所有计算机科学系的学生:
CREATE VIEW View_Students
AS
SELECT Sno, Sname
FROM Student
WHERE Sdept='计算机科学'
WITH CHECK OPTION;
修改视图
使用ALTER VIEW
语句来修改视图。格式如下:
ALTER VIEW <视图名>
AS
<select-from-where查询块>;
删除视图
使用DROP VIEW
语句来删除视图。格式如下:
DROP VIEW <视图名>;
查询视图
查询视图与查询基本表的语句相同。例如:
SELECT * FROM View_Students;
更新视图
视图可以被更新,但并非所有视图都可以更新。更新视图时,数据库系统会将更新操作转换为对基本表的相应更新。
第四章:数据库安全性
数据库中的数据通常是共享的,这种共享性质虽然提高了数据的使用效率,但也带来了安全性问题。因此,对数据库的访问和使用需要有一定的限制和条件,以确保数据的完整性、机密性和可用性。
安全性的重要性
- 保护数据库:防止数据被非法泄露、更改或破坏。
- 确保数据的完整性:确保数据是准确和完整的。
- 确保数据的机密性:防止未授权访问敏感数据。
- 确保数据的可用性:确保合法用户可以在需要时访问数据。
系统安全保护措施
数据库系统的安全性是其性能的重要指标之一。为了达到这个目标,需要实施以下安全保护措施:
- 用户身份验证:确保只有合法用户可以访问数据库。
- 访问控制:限制用户对数据库的访问权限,确保用户只能访问他们被授权的数据。
- 数据加密:对敏感数据进行加密,以防止未授权的访问。
- 审计和监控:记录和检查用户对数据库的所有操作,以便及时发现和解决问题。
- 备份和恢复:定期备份数据库,以便在数据丢失或损坏时能够恢复。
411数据库的不安全要素
数据库面临的不安全要素主要包括未经授权的访问和恶意行为,这些行为可能由黑客或犯罪分子发起。为了应对这些威胁,需要实施一系列安全措施。
用户身份鉴别和存取控制
- 用户身份鉴别:类似于现实世界的保安,数据库需要识别和验证用户的身份,确保只有授权用户可以访问数据。
- 存取控制:类似于监控系统,数据库需要控制用户对数据的访问权限,确保用户只能访问他们被授权的数据。
- 视图:类似于假平台,视图可以隐藏表的某些部分,只显示用户需要看到的数据,从而增强安全性。
数据加密
- 数据加密存储:类似于保险箱,对数据进行加密存储,以防止未授权的访问。
- 数据加密传输:类似于地道信息,对数据在传输过程中的加密,以防止数据在传输过程中被窃取。
审计日志分析
- 审计日志分析:类似于监察系统,数据库需要记录所有用户操作的日志,以便及时发现和解决问题。
建立可信计算机系统
由于数据库最终是运行在计算机系统上的,因此还需要建立一套可信计算机系统的概念和标准,以确保整个系统的安全性。这包括硬件、软件和网络的安全性。
412安全标准简介
数据库安全标准的发展历程经历了多个阶段,这些标准旨在确保数据库系统的安全性,防止未经授权的访问和数据泄露。
TCSEC(DoD 85)
TCSEC,也称为Orange Book或DoD 85,是美国国防部在1985年颁布的一个标准,它定义了计算机系统的安全级别。这个标准将系统分为七个级别,从最低的D(无安全措施)到最高的A1(验证设计)。
欧洲和加拿大的标准
- ITSEC:欧洲的信息技术安全评估标准。
- CTCPEC:加拿大的可信计算机产品评估准则。
- FC:美国联邦准则。
这些标准的发展最终促成了1999年的CC V2.1国际标准。
CC(Common Criteria)
CC(Common Criteria)是国际上广泛认可的计算机安全评估标准,它将评估保证级别(EAL)从1到7进行分级,其中1是最低的保证级别,而7是最高的。EAL1相当于TCSEC的C1级别,而EAL7则相当于A1级别。
TDI紫皮书
1991年颁布的TDI紫皮书(Trusted Database Interpretation)将TCSEC扩展到数据库管理系统,为数据库安全性奠定了基础。它提出了四项基本规则:安全策略、责任、保证和文档。
CC对TCSEC的取代
CC标准已经基本取代了TCSEC,成为国际上评估计算机系统安全性的主要标准。
4.2数据库安全性控制
数据库安全性控制是为了防止非法使用数据库,包括绕过数据库管理系统及其授权机制、执行非授权操作、以及从数据库中推导出保密数据等行为。为了防止这些行为,可以采取以下反制措施:
用户身份鉴别
- 用户表示鉴定:系统通过用户名和密码等身份凭证来鉴定用户身份,只有合法用户才能访问数据库。
- 多因素认证:除了用户名和密码,还可以使用其他因素(如生物特征识别、安全令牌等)来增强身份验证的安全性。
存取控制
- 授权机制:数据库管理系统需要实施严格的授权机制,确保用户只能执行他们被授权的操作。
- 角色和权限:通过定义不同的角色和相应的权限,可以简化授权管理,提高系统的安全性。
数据加密
- 数据存储加密:将敏感数据以加密形式存储在数据库中,即使数据被非法访问,也无法读取其真实内容。
- 数据传输加密:在数据传输过程中使用加密技术,以防止数据在传输过程中被窃取或篡改。
其他安全措施
- 审计和监控:记录所有用户对数据库的操作,以便及时发现和应对安全威胁。
- 安全策略和培训:制定安全策略,并对用户进行安全意识和操作培训,以提高整体的安全性。
421用户身份鉴别
用户身份鉴别是数据库系统提供的最外层安全保护措施,用于确保只有合法用户能够访问数据库。用户身份通常由用户名和唯一的用户标识号(如用户ID)组成。
用户标识和鉴别方法
- 用户标识:由用户名和用户ID组成,用于标识和区分不同用户。
- 鉴别方法:
- 静态口令鉴别:用户自己设定的密码、身份证号、安全问题等。
- 动态口令鉴别:使用特定手机扫描的二维码或接收到的验证码。
- 智能卡鉴别:使用物理卡片进行身份验证。
- 生物特征鉴别:使用指纹、人脸等生物特征进行身份验证。
用户身份鉴别的重要性
用户身份鉴别是数据库安全性的第一道防线,它能够有效防止未授权用户访问数据库。随着技术的发展,用户身份鉴别方法也在不断进步,从传统的静态口令到动态口令、智能卡和生物特征识别,这些方法提高了身份鉴别的准确性和安全性。
422存取控制
存取控制是数据库安全性的一个关键方面,它确保只有授权用户能够访问数据库中的数据。常用的存取控制方法包括自主存取控制(DAC)和强制存取控制(MAC)。
自主存取控制(DAC)
- 自主存取控制:DAC允许数据库管理员为不同用户或用户组分配不同的权限,用户可以根据自己的权限来访问和操作数据。
- C2级:在TCSEC(Orange Book)标准中,C2级要求系统提供自主存取控制。
- 权限转让:在DAC中,用户可以转让其权限给其他用户。
强制存取控制(MAC)
- 强制存取控制:MAC要求对所有数据对象进行分类,并为用户授予访问特定分类数据的权限。
- B1级:在TCSEC标准中,B1级要求系统提供强制存取控制。
- 密级标定:每个数据对象都被标定一个密级,用户被授予相应密级的访问权限。
自主存取控制方法
- GRANT和REVOKE:在SQL中,使用
GRANT
和REVOKE
语句来实现自主存取控制。 - 权限查看:用户的数据对象和操作类型是权限查看的目标,定义用户可以在哪些数据库对象上进行哪种类型的操作。
- 数据库模式操作:对于数据库模式(如表、视图等),操作类型包括创建(CREATE)、删除(DROP)等。
- 数据操作:对于数据,操作类型包括查询(SELECT)、插入(INSERT)、更新(UPDATE)、删除(DELETE)等。
424授权:授予与回收
在数据库中,授权是通过GRANT
和REVOKE
语句来实现的。这些语句允许数据库管理员为用户或角色分配和回收特定的权限。
GRANT语句
- 一般格式:
GRANT <权限> [, <权限>] ... ON <对象类型><对象名> [, <对象类型><对象名>] ... TO <用户> [, <用户>] ... [WITH GRANT OPTION];
<权限>
:指定要授予的权限,如SELECT
,INSERT
,UPDATE
,DELETE
,ALTER
,INDEX
,REFERENCES
,TRIGGER
,CREATE
等。<对象类型><对象名>
:指定权限适用的对象,如TABLE
,VIEW
,PROCEDURE
,FUNCTION
,DATABASE
,SCHEMA
,TRIGGER
,USER
,ROLE
等。<用户>
:接收权限的用户或角色。WITH GRANT OPTION
:可选,允许用户将权限进一步授予其他用户。
REVOKE语句
- 一般格式:
REVOKE <权限> [, <权限>] ... ON <对象类型><对象名> [, <对象类型><对象名>] ... FROM <用户> [, <用户>] ... [CASCADE | RESTRICT];
<权限>
:指定要回收的权限。<对象类型><对象名>
:指定权限适用的对象。<用户>
:失去权限的用户或角色。CASCADE
:如果存在WITH GRANT OPTION
,则同时收回该用户授权的其他主体的所有权限。RESTRICT
:默认选项,不处理母体必须写的权限。
创建用户
- CREATE USER语句:
CREATE USER <用户名> [WITH <权限类型>] [<权限参数>] ...;
<用户名>
:新用户的名称。<权限类型>
:可选,指定新用户拥有的权限,如DBA
,RESOURCE
,CONNECT
。<权限参数>
:可选,根据权限类型提供相应参数。
权限类型
- 权限类型:如
SELECT
,INSERT
,UPDATE
,DELETE
,ALTER
,INDEX
,REFERENCES
,TRIGGER
,CREATE
等。
对象类型
- 对象类型:如
TABLE
,VIEW
,PROCEDURE
,FUNCTION
,DATABASE
,SCHEMA
,TRIGGER
,USER
,ROLE
等。
425数据库角色
角色是数据库中权限的集合,用于简化权限管理。通过将多个权限组合成一个角色,数据库管理员可以更有效地分配和控制权限。
角色创建
- 创建角色:使用
CREATE ROLE
语句来创建角色。CREATE ROLE <角色名>;
授权角色
- 授权权限:使用
GRANT
语句将权限授权给角色。GRANT <权限> [, <权限>] ... ON <对象类型><对象名> TO <角色> [, <角色>] ...;
使用角色
- 将角色授予用户:使用
GRANT
语句将角色授予用户。GRANT <角色> [, <角色>] ... TO <用户> [, <用户>] ... [WITH ADMIN OPTION];
WITH ADMIN OPTION
:可选,允许用户将角色进一步授予其他用户。
角色与权限的关系
- 角色与权限的集合:角色是一组权限的集合,例如,一个“管理员”角色可能包括创建表、修改数据等权限。
- 角色与用户的关系:当用户被赋予一个角色时,用户就拥有了该角色包含的所有权限。
角色与GRANT语句
- 简化权限管理:角色类似于查询块,它们可以简化权限的分配和管理过程。
- 角色作为权限使用:在
GRANT
语句中,可以将角色当作权限来使用,从而简化权限的分配。
角色撤销
- 撤销角色:使用
REVOKE
语句来撤销角色的权限。REVOKE <角色> [, <角色>] ... FROM <用户> [, <用户>] ...;
426强制存取控制方法
强制存取控制是一种高级的安全机制,它为每个数据对象(客体)和用户(主体)分配敏感度标记,用于控制数据的访问。这种方法通常用于军事和政府部门,以保证更高的安全性。
敏感度标记
- 标记等级:数据对象的敏感度标记可以是多个等级,如绝密(TS)、机密(S)、可信(C)、公开(P)。
- 访问控制:用户只有当其主体敏感度标记等于或大于所访问客体的敏感度标记时,才能访问该客体。
强制存取控制的特点
- 安全级别:MAC提供比自主存取控制(DAC)更高的安全性。
- 用户控制:用户不能直接感知或控制MAC机制,所有访问决策都由系统自动执行。
- 系统管理:MAC的实施和维护通常由数据库管理员或系统管理员进行。
应用场景
- 军事和政府机构:这些机构通常处理敏感数据,需要高度的安全保障。
- 安全要求高的企业:在需要保护机密信息的企业环境中,MAC可以提供必要的安全性。
强制存取控制的实现
- 标记系统:数据库管理系统需要有一个标记系统来识别和存储数据的敏感度。
- 访问决策:系统自动根据用户和数据的敏感度标记来决定是否允许访问。
4.3视图机制
视图是数据库中的虚拟表,它基于一个或多个基本表的查询结果创建。视图机制允许用户通过定义视图来简化复杂的查询,同时也可以用于数据保护。
视图的创建
- 创建视图:使用
CREATE VIEW
语句来创建视图。CREATE VIEW <视图名> AS <select-from-where查询块>;
<视图名>
:指定视图的名称。<select-from-where查询块>
:定义视图的查询语句。
视图与数据保护
- 数据保护:通过创建视图,可以只向用户展示他们需要看到的数据,隐藏敏感信息。
- 权限授予:将视图的权限授予用户,可以控制用户对数据的访问。
视图的作用
- 简化查询:视图可以简化复杂的查询操作,提高数据处理的效率。
- 数据保护:通过视图,可以实现对数据的细粒度控制,保护敏感信息不被未授权访问。
视图的维护
- 视图更新:视图可以更新,但更新的数据会反映在基本表上。
- 视图删除:可以使用
DROP VIEW
语句来删除视图。
视图与基本表的关系
- 基本表数据变化:基本表的数据变化会实时反映在视图中。
- 视图与权限:对视图的权限授予可以控制用户对数据的访问,实现数据保护。
4.4审计
数据库审计是数据库安全的一个重要方面,它通过记录用户对数据库的操作来监控数据库活动,帮助识别非法访问或数据操作。
审计日志
- 审计日志:数据库系统会记录所有用户对数据库的操作,包括查询、更新、删除等。
- 监控和分析:审计日志由专门的审计员监控,用于分析数据库活动,找出非法存取数据的行为。
审计要求
- 审计等级:在TCSEC(Orange Book)标准中,C2级及以上级别的系统必须实施审计。
- 审计日志内容:审计日志通常包括操作的时间、操作者、操作内容和操作结果等信息。
AUDIT和NOAUDIT语句
-
AUDIT语句:使用
AUDIT
语句来启用审计。AUDIT <操作> [, <操作>] ... ON <对象名> [, <对象名>] ...;
<操作>
:指定要审计的操作,如SELECT
,INSERT
,UPDATE
,DELETE
等。<对象名>
:指定要审计的对象,如表名、视图名等。
-
NOAUDIT语句:使用
NOAUDIT
语句来取消审计。NOAUDIT <操作> [, <操作>] ... ON <对象名> [, <对象名>] ...;
<操作>
和<对象名>
的使用与AUDIT
语句相同。
审计的重要性
- 数据保护:审计日志是发现和防止数据非法访问的关键工具。
- 合规性:对于需要遵守特定安全标准和法规的数据库系统,审计日志是必需的。
审计的实施
- 审计策略:数据库管理员需要制定审计策略,确定哪些操作和对象需要被审计。
- 审计日志管理:审计日志需要定期审查和分析,以发现潜在的安全威胁。
4.5数据加密
数据加密是将数据明文转换为密文的过程,它是保护数据在存储和传输过程中不被未授权访问的有效手段。
加密方法
- 存储加密:
- 透明加密:对数据的加密和解密过程对用户透明。
- 非透明加密:用户无法直接看到加密后的数据。
- 传输加密:
- 链路加密:对数据在传输过程中进行加密,但不涉及数据的最终存储。
- 端到端加密:从数据的源点到目的地点全程进行加密。
SSL传输方案
- SSL(安全套接层):SSL协议用于在客户端和服务器之间建立安全的加密连接。
- 实现思路:
- 确认通信双方端点的可靠性:通过数字证书进行服务器和客户端的认证。
- 协商加密算法:在确认端点可靠性后,双方协商本次通信的加密算法和密钥。
- 可信数据传输:使用协商好的密钥进行数据的加密传输。
数据加密的重要性
- 数据安全:加密可以防止数据在存储和传输过程中被未授权访问或窃取。
- 合规性:许多行业标准和法规要求对敏感数据进行加密。
加密技术的应用
- 数据库存储:对数据库中的敏感数据进行加密,以防止数据泄露。
- 数据传输:在数据通过网络传输时,使用加密技术来保护数据不被截获。
加密的挑战
- 密钥管理:加密和解密需要使用密钥,因此密钥的管理和存储是加密过程中的一个重要环节。
- 性能影响:加密和解密过程可能会对系统的性能产生一定的影响。
4.6其他安全性保护
除了数据加密和审计等常见的安全措施外,数据库系统还需要实施其他一些安全性保护措施来确保数据的安全。
推理控制
- 强制存取控制的补充:推理控制用于解决强制存取控制未解决的问题,特别是防止用户通过观察合法数据推知更高密级的数据。
- 基于函数依赖的推理控制:使用数据库的函数依赖关系来识别和阻止可能导致信息泄露的数据访问模式。
- 基于敏感关联的推理控制:识别和控制数据之间的敏感关联,以防止通过合法数据推导出敏感信息。
隐蔽信道
- 隐蔽信道的处理:隐蔽信道是数据库系统中的潜在安全威胁,它们允许用户绕过系统的访问控制机制进行非法通信。
- 强制存取控制的补充:隐蔽信道通常与强制存取控制相关联,需要特别注意和处理。
数据隐私保护
- 数据隐私保护的重要性:在数据的整个生命周期(收集、存储、处理和发布)中,都需要考虑数据隐私保护。
- 技术措施:包括数据匿名化、数据脱敏、访问控制等,以确保个人数据的隐私和保护。
安全性保护的实施
- 综合措施:数据库安全性保护需要综合运用多种技术和策略,以应对不同的安全威胁。
- 持续监控和更新:数据库安全措施需要持续监控和更新,以应对不断变化的安全威胁和法规要求。
第五章:数据库完整性
数据库的完整性是确保数据正确性和相容性的关键特性。它涵盖了两个主要方面:
- 正确性:确保数据与现实世界的语义相符,准确反映当前的实际状况。
- 相容性:保证数据在不同部分之间的一致性和协调性。
完整性约束条件的定义
完整性约束条件,也称为完整性规则,是一组用于确保数据库中数据满足特定语义要求的规则。在SQL中,这些规则通过以下几种方式得到实施:
- 实体完整性:确保表中的每一行都能被唯一识别。
- 参照完整性:维护表间关系的一致性,例如外键约束。
- 用户定义完整性:允许用户自定义特定于应用程序的约束条件。
完整性检查方法
完整性检查是验证数据是否满足上述完整性约束条件的机制。通常,这些检查在执行数据修改操作(如INSERT, UPDATE, DELETE)后立即进行。此外,还可以在事务提交之前执行一次额外的检查,以确保数据的完整性。
违约处理
当检测到违反完整性约束条件的操作时,数据库管理系统(DBMS)会采取相应的措施。常见的处理方法包括:
- 拒绝(Reject):直接拒绝执行违反约束的操作。
- 级联(Cascade):执行其他相关操作以保持数据的一致性,例如级联删除或更新相关联的数据。
通过这些机制,数据库完整性得到了有效保障,确保了数据的准确性和可靠性。
5.1实体完整性
511实体完整性定义
实体完整性是数据库完整性的一种形式,主要确保表中的每一行数据都能被唯一识别。它通常通过PRIMARY KEY约束来实现。主键约束确保某一列(或列的组合)中的值是唯一的,并且不为空。
- 单属性主键:当主键由单个属性构成时,可以定义为列级约束,即在属性定义时直接指定(如
Sno PRIMARY KEY
),也可以定义为表级约束,在所有属性定义后单独指定(如PRIMARY KEY (Sno)
)。 - 多属性主键:当主键由多个属性构成时,只能定义为表级约束,例如
PRIMARY KEY (Sno, Cno)
。
512实体完整性检查和违约处理
在执行涉及主键列的修改操作(如INSERT或UPDATE)时,数据库管理系统(DBMS)会执行实体完整性检查:
- 唯一性检查:确保修改后的主键值在表中是唯一的。如果存在重复值,则操作会被拒绝。
- 非空性检查:确保主键列的值不为空。如果修改后的主键值为空,则操作同样会被拒绝。
这些检查通常通过全表扫描来实现,但这可能非常耗时。为了提高效率,关系数据库管理系统(RDBMS)通常在主键上创建索引,如B+树索引,以加快查询和检查的速度。
5.2参照完整性
521参照完整性定义
参照完整性是数据库中维护表间关系一致性的一种机制。它确保外键中的值必须与参照表的主键中的值相匹配,从而保持表之间的引用完整性。
在SQL中,参照完整性通常通过FOREIGN KEY约束来实现。此约束定义了某一列(或列的组合)作为外键,并指明它参照(references)另一个表的主键。例如:
- 单属性外键:
FOREIGN KEY (Sno) REFERENCES Student (Sno)
在这个例子中,假设“Sno”是当前表中的一个列,它作为外键参照了“Student”表中的主键“Sno”。这意味着当前表中“Sno”列的每个值都必须在“Student”表的“Sno”列中有一个匹配的值。
参照完整性约束确保了数据库中相关表之间的数据一致性,防止了引用无效或不存在的数据。
522参照完整性检查和违约处理
在执行涉及外键列的操作(如INSERT或UPDATE)时,数据库管理系统(DBMS)会执行以下检查:
- 参照存在性检查:确保外键列的每个值都在被参照表的主键列中有对应的匹配值。如果添加了一个在参照表中不存在的外键值,则该操作会被拒绝。
违约处理方法
参照完整性的违约处理方法与实体完整性相似,但有一些不同之处。当检测到违反参照完整性的操作时,DBMS可以采取以下措施:
- 拒绝操作:直接拒绝执行导致参照不一致的操作。
- 设置为空值:将造成不一致的对应属性设置为空值。例如,如果学生表中的某个专业被删除,那么在其他参照学生表的表中,所有引用该专业的元组都将被设置为空值。
- 级联操作:自动修改或删除其他表中的相关元组以保持一致性。
通过这些机制,参照完整性得到了有效保障,确保了数据库中表间关系的正确性和数据的一致性。
5.3用户定义的完整性
531属性上的约束条件
在数据库中,除了实体完整性和参照完整性之外,还可以在属性级别上定义约束条件。这些约束条件用于确保列中的数据满足特定的语义要求。常见的属性级约束条件包括:
- NOT NULL:确保列中的值不为空。
- UNIQUE:确保列中的每个值都是唯一的。
- CHECK:允许定义自定义的条件,列中的值必须满足这些条件。
例如,CHECK (Ssex IN ('男', '女'))
确保了“Ssex”列中的值只能是“男”或“女”。
约束条件的检查
在执行修改操作(如INSERT或UPDATE)后,数据库管理系统(DBMS)会自动检查这些约束条件是否得到满足:
- 如果修改后的数据违反了任何约束条件,DBMS将拒绝执行该操作。
- 这种机制确保了数据的准确性和一致性,防止了不符合预定义规则的数据进入数据库。
532元组上的约束条件
元组上的约束条件是指在数据库表中的行级别上施加的约束。与列级约束(应用于单个列)不同,元组级约束涉及整个行的数据。这些约束条件确保行的所有属性共同满足特定的语义要求。
元组级约束的特点
- 应用于整个行:元组级约束考虑行中所有属性的组合,而不仅仅是单个属性。
- 与列级约束的对比:这与列级约束形成对比,后者仅关注单个属性。元组级约束可以看作是表级约束的一种,但它们专门针对行的整体性。
例子和实现
元组级约束的例子包括:
- 整体唯一性:确保行的所有属性组合在表中是唯一的。
- 跨列的条件:例如,
CHECK (列1 > 列2)
,确保一个列的值总是大于另一个列的值。
在SQL中,这些约束通常使用CHECK
子句在表定义中实现。当插入或更新行时,数据库管理系统(DBMS)会检查这些约束是否得到满足。如果违反了任何元组级约束,DBMS将拒绝执行该操作。
5.4完整性约束命名字句
在SQL中,可以为完整性约束条件指定一个名称,这有助于在以后的管理和维护中更清晰地引用这些约束。使用CONSTRAINT
关键字,可以给任何完整性约束条件(如主键、外键、唯一性约束或检查约束)指定一个名称。
命名完整性约束的语法
CONSTRAINT <约束名> <完整性约束条件>
例如,当创建一个表时,可以如下命名一个约束:
CREATE TABLE Student (
Sno INT,
Sname VARCHAR(50),
CONSTRAINT PK_Student PRIMARY KEY (Sno)
);
在这个例子中,PK_Student
是为主键约束指定的名称。
使用ALTER TABLE修改完整性约束
ALTER TABLE
语句用于修改已存在的表的完整性约束。例如,可以删除或添加约束:
- 删除约束:
ALTER TABLE Student DROP CONSTRAINT C4;
- 添加约束:
ALTER TABLE Student ADD CONSTRAINT C5 UNIQUE (Sname);
在这些例子中,C4
和C5
是约束的名称。删除约束时,需要指定要删除的约束的名称;添加约束时,需要指定新的约束条件和其名称。
5.6断言
在SQL中,除了标准的完整性约束外,还可以使用CREATE ASSERTION
语句来定义更为复杂和一般性的约束。这些声明性断言提供了一种方式来确保数据库的复杂业务规则得到满足。
断言的特点
- 严格性:断言对数据库的操作施加了严格的限制。任何导致断言不为真的数据库操作都会被拒绝。
- 复杂约束:断言可以表达比标准约束(如主键、外键、唯一性和检查约束)更复杂的业务规则。
创建断言的语法
CREATE ASSERTION <断言名> CHECK <条件>;
例如,假设我们想要限制每门课程最多有60名学生选修,可以使用以下断言:
CREATE ASSERTION CheckMaxStudents
CHECK (60 >= ALL (SELECT COUNT(*)
FROM SC
GROUP BY Cno));
在这个例子中,CheckMaxStudents
是断言的名称,CHECK
子句定义了具体的约束条件。
删除断言
如果需要删除一个断言,可以使用DROP ASSERTION
语句:
DROP ASSERTION <断言名>;
这将移除数据库中指定的断言。
5.7触发器
触发器是数据库中一种特殊类型的存储过程,它由特定的事件触发自动执行。这些事件通常是数据操作语言(DML)操作,如INSERT、UPDATE或DELETE,也可以是数据定义语言(DDL)操作。
触发器的类型
- DML触发器:在执行数据修改操作时触发。
- AFTER触发器:在数据修改操作执行后触发。
- INSTEAD OF触发器:代替数据修改操作执行。
- DDL触发器:在执行DDL操作时触发,通常用于审计或控制数据库结构的变化。
创建AFTER触发器
sql
复制
CREATE TRIGGER <触发器名>
ON <数据表名>
AFTER INSERT OR DELETE OR UPDATE
AS
BEGIN
-- 这里是要运行的SQL语句
END
这个触发器在指定的数据表发生增加、删除或更新操作后自动执行定义的SQL语句。
创建INSTEAD OF触发器
sql
复制
CREATE TRIGGER <触发器名>
ON <视图名>
INSTEAD OF <触发器类型>
AS
BEGIN
-- 这里是要运行的SQL语句
END
INSTEAD OF触发器用于视图上,它不会执行实际的数据修改操作,而是执行触发器内定义的操作。
管理触发器
- 查看触发器定义:使用
SP_HELPTEXT <触发器名>
。 - 查看表上的触发器:使用
SP_HELPTRIGGER <表名>
。 - 修改触发器:使用
ALTER TRIGGER
语句。 - 删除触发器:使用
DROP TRIGGER <触发器名>
语句。
第六章:关系数据理论
6.1问题的提出
在关系数据库的逻辑设计中,我们面临两个主要挑战:
- 构造数据模式:如何针对具体问题构建一个合适的关系模式?
- 规范化理论:利用关系数据库规范化理论作为逻辑设计的工具。
关系模式的组成
关系模式通常表示为五元组:
- R:关系名,代表元组的语义。
- U:属性集合。
- D:属性组U中属性所属的域。
- DOM:属性到域的映射。
- F:属性组U上的一组数据依赖。
在本章中,我们简化关系模式为三元组,因为D和DOM与模式设计关系不大。
第一范式(1NF)
关系模式必须满足第一范式,即每个分量必须是不可分割的数据项。
数据依赖
数据依赖是属性间相互约束的关系,反映了现实世界属性间的联系。主要类型包括:
- 函数依赖(FD):一个属性的值可以唯一确定另一个属性的值。
- 多值依赖(MVD):一个属性的值可以确定一组属性的值。
关系模式构建实例
考虑建立一个学校教务数据库,关系模式包括sno(学号)、sdept(系名)、mname(系主任姓名)、cno(课程号)和grade(成绩)。属性集合为 𝑈={𝑠𝑛𝑜,𝑠𝑑𝑒𝑝𝑡,𝑚𝑛𝑎𝑚𝑒,𝑐𝑛𝑜,𝑔𝑟𝑎𝑑𝑒}U={sno,sdept,mname,cno,grade}。
根据现实世界的语义,我们得到以下函数依赖集 𝐹F:
[在此处插入具体的函数依赖示例]
存在的问题
关系模式存在以下问题:
- 数据冗余:例如系主任信息重复。
- 更新异常:更换系主任时需更新多个元组。
- 插入异常:新成立的系无学生,无法录入系和系主任信息。
- 删除异常:当所有学生毕业时,删除学生信息会导致系和系主任信息丢失。
解决方案
使用规范化理论改造关系模式,消除不合适的数据依赖。将 𝑠𝑡𝑢𝑑𝑒𝑛𝑡<𝑈,𝐹>student<U,F> 分解为三个更小的模式:
- 𝑆(𝑠𝑛𝑜,𝑠𝑑𝑒𝑝𝑡,𝑠𝑛𝑜→𝑠𝑑𝑒𝑝𝑡)S(sno,sdept,sno→sdept)
- 𝑆𝐶(𝑠𝑛𝑜,𝑐𝑛𝑜,𝑔𝑟𝑎𝑑𝑒,(𝑠𝑛𝑜,𝑐𝑛𝑜)→𝑔𝑟𝑎𝑑𝑒)SC(sno,cno,grade,(sno,cno)→grade)
- 𝐷𝐸𝑃𝑇(𝑠𝑑𝑒𝑝𝑡,𝑚𝑛𝑎𝑚𝑒,𝑠𝑑𝑒𝑝𝑡→𝑚𝑛𝑎𝑚𝑒)DEPT(sdept,mname,sdept→mname)
这样解决了数据冗余和更新、插入、删除异常的问题。
6.2规范化
621函数依赖
在数据库设计中,理解关系模式中的函数依赖是至关重要的。关系模式R<U,F>由属性集合U和U上的函数依赖集F组成。函数依赖定义如下:
函数依赖:
- 若𝑋→𝑌且𝑌属于𝑋,则𝑌完全由𝑋决定,称为平凡函数依赖。
- 若𝑋→𝑌且𝑌不属于𝑋,则称𝑌非平凡函数依赖于𝑋。
- 若𝑋→𝑌且对𝑋的任何真子集𝑋′,都有𝑋′→/𝑌,则称𝑌对𝑋完全函数依赖。
- 若𝑋→𝑌且存在𝑋的真子集𝑋′,使得𝑋′→𝑌,则称𝑌对𝑋部分函数依赖。
传递函数依赖:
- 若𝑋→𝑌且𝑌→𝑍且𝑍和𝑌也是非平凡函数依赖,则𝑍对𝑋传递函数依赖。
举例:
- 平凡函数依赖:如(学号,姓名)→姓名,其中姓名由学号或姓名决定。
- 非平凡函数依赖:如(学号,课程号)→个人成绩,其中个人成绩由学号和课程号联合决定,个人成绩不构成(学号,课程号)的子集。
- 完全函数依赖:如(学号,课程号)→个人成绩,其中个人成绩完全由(学号,课程号)决定,没有任何真子集可以决定个人成绩。
- 传递函数依赖:在𝑆𝑡𝑑(𝑆𝑛𝑜【学号】,𝑆𝑑𝑒𝑝𝑡【所在系】,𝑀𝑛𝑎𝑚𝑒【系主任】)中,𝑆𝑛𝑜→𝑆𝑑𝑒𝑝𝑡(且不能反推),𝑆𝑑𝑒𝑝𝑡→𝑀𝑛𝑎𝑚𝑒,所以𝑆𝑛𝑜→𝑀𝑛𝑎𝑚𝑒,即𝑀𝑛𝑎𝑚𝑒传递函数依赖于𝑆𝑛𝑜。
622码
在数据库设计中,理解关系模式中的码是至关重要的。关系模式R<U,F>由属性集合U和U上的函数依赖集F组成。码的定义如下:
-
候选码(Candidate Key):候选码是R<U,F>中能够唯一标识元组的最小属性集。这意味着,对于R中的任意两个元组,这些属性的组合值是不同的。如果K是R的一个属性或属性组合,且U完全函数依赖于K,即K的全部分唯一确定U,则K称为R的一个候选码。
-
超码(Superkey):超码是能够唯一标识元组的一个属性或属性组合。如果U中的某些属性部分函数依赖于K,即K的某些部分能够唯一确定U,但P不是K的子集,那么K称为R的超码。候选码是最小的超码,因为需要全部份才能唯一确定U,意味着它的任何一个真子集都不能成为超码。
-
主属性与非主属性:主属性是包含在任何一个候选码中的属性。它们对于唯一标识元组至关重要。相反,非主属性是不包含在任何码中的属性。虽然它们可以存在于关系模式R中,但在唯一标识元组方面可以不起作用。
-
全码(All-key):当整个属性组都是码时,称为全码。这意味着关系模式R中的每个属性组合都参与唯一标识一个元组。
-
外码(Foreign Key):外码是关系模式R中的属性或属性组X,它不是R的码,但恰好是另一个关系模式的码。外码用于在关系之间建立联系,并维护引用完整性。例如,如果关系模式R1中的一个属性集X是关系模式R2的候选码,那么X在R1中就是外码。
要确定关系模式R中的码,需要进行逻辑判断,找出能够固定将R中的每一个单元一一划分的属性组合。理解这些概念对于数据库设计和维护数据完整性至关重要。
623范式
范式是符合某一种级别的关系模式的集合,关系数据库中的关系必须满足一定的要求。不同程度要求也有不同的范式。范式的种类有以下几种:
- 第一范式(1NF):确保每一列都是不可分割的数据项,即每个字段只包含原子值。
- 第二范式(2NF):在1NF的基础上,非主键属性必须完全依赖于主键,不能只依赖于主键的一部分。
- 第三范式(3NF):在2NF的基础上,非主属性不仅依赖于主键,还必须直接依赖于主键,不能有传递依赖。
- 巴斯-科德范式(BCNF):在3NF的基础上,对于每一个非平凡的函数依赖,决定因素都必须包含候选键。
- 第四范式(4NF):在BCNF的基础上,消除非平凡且非函数依赖的多值依赖。
- 第五范式(5NF):也称为“完美范式”,在4NF的基础上,消除任何剩余的函数依赖。
范式之间的关系:
- 从1NF开始,前一个范式包含着后一个范式,层层嵌套(第五范式要求最严格,第一范式要求最基础)。
- 这意味着,一个符合2NF的关系模式也一定符合1NF,但反过来则不一定成立。
规范化过程:
- 某一关系模式R为第n范式,就可以简单记为:R ∈ nNF。例如,如果一个关系模式符合第三范式,我们可以记为 R ∈ 3NF。
- 一个低一级范式的关系模式,通过模式分解转化为若干个范式的关系模式的集合,称为规范化。
- 规范化过程有助于减少数据冗余,提高数据完整性,并简化数据维护。
6242NF
第一范式(1NF)定义了关系模式的基本属性:每个属性的值域都是原子值,即每个字段只包含不可分割的最小数据单位。换句话说,第一范式要求表中的所有字段值都是不可再分的,确保了数据的原子性。
2NF的定义:
- 若关系模式R已满足第一范式(1NF),且其每个非主属性都完全函数依赖于任何一个候选码,则R符合第二范式(2NF)。
2NF的重要性:
- 2NF的目的是消除非主属性对主码的部分依赖,从而减少数据冗余和提高数据的一致性。
关系模式S-L-C的例子:
- 以关系模式S-L-C(Sno,Sdept,Sloc,Cno,Grade)为例,其中Sloc表示学生住处,假设同一系的学生住在相同地点。
- 该模式的候选码为(Sno,Cno)。
- 观察上述函数依赖,我们发现非主属性Sdept和Sloc并非完全依赖于候选码(Sno,Cno),因此S-L-C不符合2NF。
2NF不符合可能引发的问题:
- 插入异常:例如,若新学生尚未选课,则缺少Cno,导致无法插入其信息。
- 删除异常:若学生取消选课,删除相关课程后,其其他信息也可能丢失。
- 修改复杂:学生选多门课时,Sdept和Sloc需重复存储,若学生转系,则需更新所有相关记录,导致数据冗余和操作复杂。
解决方法:
- 为解决这些问题,我们可以采用投影分解法,将S-L-C分解为两个关系模式:
- SC(Sno,Cno,Grade):在此模式中,Grade完全依赖于候选码(Sno,Cno)。
- SL(Sno,Sloc,Sdept):在此模式中,Sdept和Sloc完全依赖于Sno。
- 经过这样的分解,每个关系模式中的非主属性都完全依赖于其候选码,从而满足了第二范式(2NF)的要求。
6253NF
第三范式(3NF)是数据库规范化理论中的一个重要概念,它是在满足第二范式(2NF)的基础上进一步规范化关系模式。
3NF的定义:
- 设关系模式R<U,F>∈2NF,若R中不存在这样的码X(非主属性),有一属性组Y(非主属性),与非主属性Z,且Y不包含X。使得X→Y,Y→Z成立,且Y→/X不成立,满足这种形式的R∈3NF。
- 换句话说,第三范式要求在满足第二范式的基础上,关系中不存在非主属性对于任何候选码的传递依赖。这意味着所有非主属性必须直接依赖于候选码,而不是通过其他非主属性间接依赖。
626BCNF
巴斯-科德范式(BCNF)是数据库规范化理论中的一个高级概念,它比第三范式(3NF)更进一步,通常被认为是修正的第三范式,有时也被称为扩充的第三范式。
BCNF的定义:
- 若关系模式R<U,F>∈1NF,对于R中的所有函数依赖X→Y,若Y不属于X,则X必须包含一个候选码。满足这一条件的关系模式R属于BCNF。
- 换句话说,在BCNF中,每一个决定属性集都必须包含候选码。
BCNF的性质:
- 所有非主属性完全依赖于每个候选码。
- 所有主属性都完全函数依赖于每个不包含它的候选码。
- 没有任何属性完全函数依赖于非码的任何一组属性。
BCNF在数据库规范化中的作用:
- 如果一个关系数据库的所有关系模式都属于BCNF,那么在函数依赖范畴内,就实现了模式的彻底分解,达到了最高的规范化程度。
- 从而消除了所有插入异常和删除异常。
627多值依赖
多值依赖是数据库理论中的一个概念,它描述了一种比函数依赖更复杂的数据依赖关系。在关系模式Teaching(C,T,B)中,我们可以看到非平凡的多值依赖,因为C→→T和B→→T都成立,且Z(即U-C-B)不为空。这种多值依赖的存在导致了数据冗余和操作复杂性的问题。为了解决这些问题,可能需要对这个关系模式进行分解,以消除多值依赖。
多值依赖的定义:
- 设R(U)是属性集U上的一个关系模式。设X, Y, Z是U的子集,并且Z=U-X-Y。多值依赖X→→Y在R(U)上成立,如果对于R(U)的任意关系r,给定的一对(x, z)值,有一组y值,这组y值仅仅决定于x值而与z值无关。换句话说,对于R(U)的任意关系r,如果存在t1和t2两个元组,它们在X和Z上的属性值相同,那么它们在Y上的属性值也必须相同。
多值依赖的性质:
- 对称性:如果X→→Y成立,那么X→→Z也成立,其中Z=U-X-Y。
- 传递性:如果X→→Y和Y→→Z成立,那么X→→Z也成立。
- 函数依赖是它的特殊情况:如果X→Y,那么X→→Y也成立。
- 相加性:如果X→→Y和X→→Z成立,那么X→→YZ也成立。
- 投影性:如果X→→Y在R(U)上成立,那么X→→Y在R(XY)上也成立。
与函数依赖的区别在于:
- 多值依赖的有效性与属性集的范围有关,因为它的定义不仅涉及属性集X和Y,还涉及U中其余属性Z。而函数依赖的有效性仅取决于X和Y。
- 不能断言X→→Y的子集存在,而函数依赖可以。
- 嵌入型多值依赖是指X和Y的有效性范围是U的一个子集。这意味着多值依赖不仅仅取决于X和Y之间的关系,还可能取决于U中其他属性的影响。
在关系模式Teaching(C,T,B)中,我们可以看到非平凡的多值依赖,因为C→→T和B→→T都成立,且Z(即U-C-B)不为空。这种多值依赖的存在导致了数据冗余和操作复杂性的问题。为了解决这些问题,可能需要对这个关系模式进行分解,以消除多值依赖。
6284NF
第四范式(4NF)是数据库范式理论中的一个高级概念,它在第三范式(3NF)的基础上进一步限制了关系模式中属性之间的多值依赖。
第四范式的定义:
- 设R(U, F)是一个关系模式,其中U是属性集,F是函数依赖集。
- R(U, F)属于第四范式(4NF),当且仅当对于R(U, F)中的所有非平凡多值依赖X→→Y,至少满足以下条件之一:
- X→Y是一个函数依赖,即Y完全函数依赖于X。
- X是一个超键,即X可以唯一标识关系中的每个元组。
简单来说,第四范式要求在关系模式中,如果一个属性集(X)决定了另一个属性集(Y)的多值依赖,那么X必须包含关系模式的码(即候选键)。这意味着,如果一个属性集能够引起多值依赖,它必须是关系模式的一个超键。
第四范式的目的:
- 第四范式的目的是消除关系模式中的数据冗余和更新异常,确保数据的一致性。
- 通过限制非平凡且非函数依赖的多值依赖,4NF能够进一步减少数据重复,简化数据维护操作,并提高数据处理的效率。
6.3范式与反范式设计
在讨论数据库设计时,我们必须认识到,规范化程度高的关系模式并不总是最佳选择。一个“合适的,反映现实世界的”模型需要根据具体情况进行深入分析。这时,反范式设计成为了一个重要的概念。
反范式设计:
- 通过在多个表中冗余数据,以空间换取时间,减少或避免表之间的关联,从而提高查询效率。
- 这种设计的关键在于确保冗余字段的一致性。
例如,在学生(s)、课程(c)和成绩(sc)的关系中,为了查询特定学生的成绩,可以通过在成绩表中冗余学生姓名来简化查询。
原始的查询需要关联学生表和成绩表:
SELECT sno, sname, cno, grade
FROM s, sc
WHERE s.sno = sc.sno AND s.sname = '特定人名';
而在反范式设计中,通过在成绩表中添加学生姓名字段,可以简化查询:
SELECT sno, sname, cno, grade
FROM sc
WHERE sname = '特定人名';
这种设计虽然提高了查询效率,但也带来了数据一致性的挑战。每次学生姓名更新时,都需要同步更新成绩表中的相应记录。
数据库设计的平衡:
- 总的来说,数据库设计应该根据实际需求和场景灵活选择范式或反范式设计。
- 目标是达到最佳的性能和可维护性平衡。
第七章:数据库设计
7.1数据库设计概述
数据库设计是一个复杂而细致的过程,它涉及在一个特定的应用环境中构建优化的数据库逻辑模式和物理结构。这一过程不仅包括创建数据库及其应用系统,而且还确保这些系统能够有效地存储和管理数据,以满足各种用户的信息管理要求和数据操作要求。
信息管理要求:
- 在数据库中应该存储和管理那些数据对象。这包括确定需要存储的数据类型、数据量以及数据之间的关系。
数据操作要求:
- 对数据对象需要进行哪些操作,如查询、增加、删除、修改、统计等。这些操作需求将直接影响数据库的设计和性能。
数据库设计的六个阶段:
- 需求分析:这是整个设计过程的基础,明确用户的需求和目标,决定了构建数据库的速度和质量。需求越明确,数据库构建就越明确,错误就越少。
- 概念结构设计:这一阶段是对需求的综合归纳和抽象,形成独立于数据库管理系统的概念模型。这个模型通常使用实体-关系(ER)图来表示。
- 逻辑结构设计:将概念结构转化为某个数据库管理系统所支持的数据模型进行优化。这通常涉及到将ER图转换为关系模型,并对其进行规范化处理。
- 物理结构设计:为逻辑数据结构选择一个合适应用环境的物理结构,包括存储结构和存取方法。这一阶段涉及到数据库的存储细节,如索引的创建、数据文件的布局等。
- 数据库实施:根据逻辑和物理设计,实际构建数据库。这包括创建数据库结构、导入数据、编写应用程序等。
- 数据库运行和维护:数据库构建完成后,正式进入运行阶段。这一阶段包括监控数据库性能、进行必要的调整和优化、以及进行日常维护工作。
在整个数据库设计过程中,每个阶段都是非常重要的,任何一个环节的缺失或考虑不周都可能导致数据库性能不佳或无法满足用户需求。因此,数据库设计需要细致入微,确保每个阶段都得到充分的关注和处理。
7.2需求分析(自学)
7.3概念结构设计
731概念模型
概念结构设计是将需求分析阶段得到的用户需求抽象为信息结构的过程。这个过程的核心是创建一个概念模型,它能够真实、充分地反映现实世界,同时易于理解、更改,并能够方便地向各种数据模型转换。
概念模型的特色:
- 真实性和充分性:概念模型应当真实地反映现实世界的实体、属性和关系,确保所有重要的需求和约束都得到体现。
- 易于理解:概念模型应该使用直观的符号和术语,使得即使是不熟悉计算机的用户也能够理解。这对于与非技术背景的用户沟通至关重要。
- 易于更改:在应用环境和应用要求发生变化时,概念模型应能够灵活地进行调整,以适应这些变化。
- 易于转换:概念模型应能够方便地转换为关系模型、网状模型、层次模型等各种数据模型,以便于在数据库管理系统中实现。
实体-关系(Entity-Relationship, E-R)模型:
- 描述概念模型的工具通常是实体-关系(Entity-Relationship, E-R)模型。
- E-R模型通过实体、属性和关系这三个基本概念来描述现实世界的逻辑结构。
- 在E-R模型中,实体表示现实世界中的对象,属性是实体的特征,关系则是实体之间的相互作用。
732E-R模型
E-R模型是数据库设计中用于描述现实世界的一种重要工具,它通过实体、属性和联系这三个基本概念来构建模型。在E-R模型中,实体间的联系可以分为以下几种类型:
-
两个实体间的联系:
- 1对1联系(1:1):如果实体集A中的每一个实体,在实体集B中至多有一个实体与之联系,反之亦然,则A与B具有1对1联系。例如,班级和班长之间的关系就是一对一的。
- 1对多联系(1:n):对于实体集A中的每一个实体,实体集B中有n个实体与之联系,但B中的每个实体最多只与A中的一个实体联系。例如,一个班级可以有多个学生,但每个学生只属于一个班级。
- 多对多联系(n:m):实体集A中的每一个实体,在实体集B中有多个实体与之联系,反之亦然。例如,课程和学生之间的关系是多对多的,因为一门课程可以被多个学生选修,一个学生也可以选修多门课程。
-
两个以上实体间的联系:
- 在涉及三个或更多实体时,联系可以是1对1、1对多或多对多。例如,一门课程可能由多个老师教授,使用多本参考书,但每个老师和每本参考书只对应一门课程,这里课程与老师、参考书之间就是一对多的联系。
-
单个实体型内的联系:
- 同一个实体集内的各实体之间也可以存在一对一、一对多或多对多的联系。例如,公司内部的员工之间可能存在领导和被领导的关系。
联系的度:
- 联系的度指的是参与联系的实体型的数量。两个实体型之间的联系度为2,称为二元联系;三个实体型之间的联系度为3,称为三元联系;以此类推,N个实体型之间的联系度为N元。
E-R图的表示方法:
- E-R模型通过E-R图来表示。在E-R图中,实体型用矩形表示,属性用椭圆表示,并用一条线段(无向边)将其与实体型连接起来。联系用菱形表示,并用无向边与有关实体型连接起来。在无向边旁标上联系的类型(1:1、1:n或n:m),以表示联系的基数。此外,联系也可以具有属性,这些属性同样用椭圆表示,并通过线段与菱形连接。
735概念结构设计
在E-R图的设计中,为了简化模型的处理,我们通常将现实世界中的事物尽可能作为属性来对待。这里有两个核心原则需要遵循:
- 属性的不可再分性:作为属性的元素应该是不可再分的,即它们不包含其他属性,也不再具有需要进一步描述的性质。
- 属性的独立性:属性应独立于其他实体,即在E-R图中表示的联系应该是实体间的联系,而不是实体与属性之间的联系。
E-R图的集成过程
E-R图的集成通常分为两个主要步骤:合并和修改重构。
-
合并:
- 在合并阶段,我们需要解决各个局部E-R图之间的冲突,主要包括:
- 属性冲突:可能涉及属性域的不同(如类型、取值范围或集合的差异)或属性取值单位的不同。
- 命名冲突:指不同意义的对象在不同局部应用中具有相同的名字,或者相同意义的对象具有不同的名字。
- 结构冲突:指同一实体在不同子系统的E-R图中属性个数、排列次序的不同,或者实体间联系的类型不同。
- 在合并阶段,我们需要解决各个局部E-R图之间的冲突,主要包括:
-
修改和重构:
- 在修改和重构阶段,我们的目标是消除冗余。冗余数据是指可以由基本数据导出的数据,而冗余联系则是指可以由其他联系导出的联系。
- 消除冗余通常依赖于数据字典和数据流图,依据数据项之间的逻辑关系进行。
- 此外,规范化理论也是消除冗余的重要工具。
通过上述步骤,我们可以确保E-R图在准确反映系统需求的同时,保持逻辑上的清晰和一致性。
7.4逻辑结构设计
741E-R图向关系模式的转换
在将E-R图转换为关系模式时,我们需要遵循一些基本的转换原则和步骤。这里是对您提供的内容的优化和补充:
-
转换原则:
- 实体型转换:每个实体型转换为一个关系模式,实体的属性转换为关系的属性,实体的键作为关系的键。
- 联系转换:
- 1:1联系:可以转换为一个独立的关系模式,或者与任一端实体对应的关系模式合并。
- 1:n联系:通常与n端实体对应的关系模式合并。
- m:n联系:转换为一个关系模式。关系的键是参与联系的各实体键的组合。
-
合并条件:
- 如果两个关系模式具有相同的关系键,可以考虑合并这两个关系模式。
-
转换步骤:
- 确定实体和联系。
- 为每个实体和联系创建关系模式。
- 确定每个关系模式的属性。
- 确定每个关系模式的键。
- 根据合并条件,合并相关的关系模式。
-
示例:
- 假设有两个实体:学生和课程,它们之间有一个m:n的联系“选课”。
- 学生实体转换为“学生”关系模式,属性包括学号、姓名等,键是学号。
- 课程实体转换为“课程”关系模式,属性包括课程号、课程名等,键是课程号。
- “选课”联系转换为“选课”关系模式,属性包括学生号、课程号和成绩,键是学生号和课程号的组合。
-
注意事项:
- 在合并关系模式时,需要确保合并后的模式不会出现数据冗余或更新异常。
- 对于复杂的E-R图,可能需要多次迭代来优化关系模式
742数据模型的优化
数据库逻辑设计的结果并非唯一。在获得初步数据模型之后,我们应适当对其进行修改和调整,以优化模型结构并提升应用性能。这一过程被称为“数据模型优化”。
关系数据模型的优化通常遵循规范化理论。以下是优化数据模型的方法:
- 确定数据依赖:识别并明确数据之间的依赖关系。
- 数据依赖的极小化处理:对关系模式之间的数据依赖进行简化,以消除冗余的联系。
- 分析关系模式:基于数据依赖理论,检查是否存在部分函数依赖、传递函数依赖、多值依赖等,以确定各关系模式分别满足第几范式。
- 评估模式适用性:根据需求分析阶段获得的应用处理要求,评估这些模式是否适合特定的应用环境,并考虑是否需要对其进行合并或分解。
- 模式分解:对关系模式进行必要的分解,以提升数据操作效率和存储空间利用率。
743设计用户子模式
定义数据库模式时,主要考虑的是系统的时间效率、空间效率和易维护性。然而,在设计用户外模式时,应更加注重用户的习惯和便利性,包括以下三个方面:
-
使用符合用户习惯的别名:在设计数据库整体结构时,合并各分E-R图以消除命名冲突,确保数据库系统中同一关系和属性具有唯一的名字是必要的。通过视图机制,可以在设计用户视图时重新定义某些属性名,使其与用户的习惯一致,从而方便用户使用。
-
针对不同级别的用户定义不同的视图:这一策略旨在保证系统的安全性。例如,在“产品”关系模式中,对于顾客的视图,可以展示产品号、产品名、规格和单价。而对于销售部门,则可以额外展示车间和生产负责人等信息。
-
简化用户对系统的使用:对于某些局部应用,如果经常需要进行复杂的查询,可以将这些复杂查询定义为视图。这样做可以简化用户的使用过程,提高效率。
7.5物理结构设计
数据库物理设计定义:数据库在物理设备上的存储结构与存取方式称为数据库的物理结构,它依赖于选定的数据库管理系统。总的来说,为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程,就是数据库的物理设计。
数据库物理设计步骤:
- 确定数据库物理结构:包括存取方法和存储结构。
- 对物理结构进行评价:重点在于时间和空间效率。若评价结果满足设计要求,则可进入物理实施阶段;否则,需重新设计或修改物理结构,有时甚至需要返回逻辑阶段修改模型。
关系数据库物理设计的内容:
-
为关系模式选择存取方法:
- B+树:定义了一种自平衡的树结构,适用于范围查询和顺序访问,效果在于提高了查询效率,局限性在于插入和删除操作可能导致树结构的调整。
- Hash:通过哈希函数直接定位数据,适用于键值对查找,效果在于快速访问,局限性在于哈希冲突和处理范围查询的困难。
- 聚簇:将相关数据存储在物理上相邻的位置,适用于经常一起访问的数据,效果在于减少磁盘I/O,局限性在于更新操作可能导致聚簇结构的维护开销。
-
设计关系、索引等数据库文件的物理存储结构:
- 确定数据库的存储结构:主要指数据库的存放位置和存储结构,涉及关系、索引、聚簇、日志、备份等的存储安排和存储结构,以及系统配置的确定。
- 存放位置和存储结构的确定:需综合考虑存取时间、存储空间利用率和维护代价三个因素。一般原则是将易变部分和稳定部分分开存储,经常存取部分和存取频率较低部分分开。
确定系统配置:
数据库管理系统一般都提供了一些存储分配参数,系统为这些参数赋予了合理的缺省值。进行物理设计时,需要根据应用环境确定这些参数值,以使系统性能最优。实际运行中,还需根据实际情况作进一步调整。
第八章:数据库编程
8.1嵌入式SQL
引入嵌入式SQL的意义
SQL作为一种非过程性语言,擅长于数据查询和操作,但在复杂的事务处理应用中,往往需要结合高级语言来实现完整的业务逻辑。嵌入式SQL的出现,正是为了解决这一需求,它允许在高级语言中直接嵌入SQL语句,从而实现数据库操作。
嵌入式SQL的定义
嵌入式SQL是指将SQL语句嵌入到程序设计语言中,如C、C++、Java等,这些语言被称为宿主语言或主语言。通过嵌入式SQL,可以在主语言中直接执行SQL语句,进行数据库操作。
嵌入式SQL的处理过程
嵌入式SQL的处理过程包括以下几个关键步骤:
- 编写包含SQL语句的主语言代码:在主语言代码中嵌入SQL语句,用于实现数据库操作。
- 使用预编译器处理:通过预编译器将SQL语句从主语言代码中分离出来,并转换为可执行的形式。这一步对于C语言等需要显式编译的语言尤为重要。
- 编译和链接:将预编译后的代码与主语言代码一起编译和链接,生成可执行文件。这一步对于确保SQL语句能够正确执行至关重要。
- 执行:运行可执行文件,执行SQL语句,完成数据库操作。这一步是嵌入式SQL处理过程的最后一步,也是实现数据库操作的关键。
不同主语言中的嵌入式SQL
-
主语言为C语言时的语句格式:
- SQL语句需要用特定的分隔符(如
EXEC SQL
)标识,以便预编译器识别。 - C语言变量与SQL语句中的参数通过宿主变量进行传递,实现数据交换。
- 需要注意的是,C语言中的嵌入式SQL需要经过预编译处理,这是与直接在数据库管理系统中执行SQL语句的主要区别。
- SQL语句需要用特定的分隔符(如
-
主语言为R语言时:
- 可以利用RODBC包来读取SQL Server数据库,实现嵌入式SQL的应用。
- R语言中,嵌入式SQL的使用更加简洁,通过RODBC函数直接执行SQL语句,无需预编译过程。
- 这种方式使得在R语言中执行SQL语句更加方便,同时也提高了数据处理的效率。
8.2TransactionSQL
Transaction SQL(T-SQL)是SQL Server的扩展,它添加了流程控制、变量声明等编程功能,使得SQL不仅仅是数据操作语言,还能进行复杂的数据处理和业务逻辑的实现。
变量
在T-SQL中,变量用于存储数据值,可以用来执行计算、控制流程等。
- 变量名:必须是一个合法的标识符,即以字母或下划线开头,由字母、数字或下划线组成,不区分大小写。
- 变量类型:可以是系统提供的任何数据类型,如INT、VARCHAR、DATETIME等。
- 变量分类:
- 全局变量:由SQL Server系统定义和维护,对整个服务器实例可见,通常以两个@符号开头,如@@VERSION。
- 局部变量:在批处理或过程中定义,仅在定义它们的范围内可见,以一个@符号开头。
语句块
语句块用于将多个语句组合在一起执行,可以提高代码的可读性和可维护性。
- 定义:语句块是一组SQL语句,它们被括在一对BEGIN…END语句中。
- 语法格式:
BEGIN -- SQL语句 END
- 实例:
BEGIN DECLARE @Counter INT SET @Counter = 1 WHILE @Counter <= 10 BEGIN PRINT @Counter SET @Counter = @Counter + 1 END END
控制流语句
T-SQL提供了多种控制流语句,用于控制代码的执行流程。
- WHILE循环语句:用于重复执行一个或多个语句,直到指定的条件为假。
- BREAK语句:用于退出最内层的WHILE或IF循环。
- CONTINUE语句:用于跳过当前循环的剩余部分,直接进入下一次循环。
游标
游标是一种数据库对象,用于遍历查询结果集中的每一行数据。
- 使用游标的原因:将集合操作转换为单个记录处理方式,允许用户逐行地访问记录,并按照自己的意愿来显示和处理这些记录。
- 使用游标的常规步骤:
- 声明游标:定义游标的数据类型、游标名和基表。
- 打开游标:执行查询并填充游标。
- 使用游标操作数据:通过FETCH语句逐行获取游标中的数据,并进行处理。
- 关闭游标:释放游标占用的资源。
8.3存储过程
存储过程是SQL Server数据库中独立于数据表之外的一种数据库对象,它是一组预编译好的SQL语句,用于完成某项特定任务。存储过程独立于程序源代码,可单独修改,可以被多次调用,并且可以引用其他存储过程。
存储过程的优点
- 模块化编程:创建一次存储过程就能永久存储在数据库中,可以在程序中重复调用任意多次,快速执行。
- 减少网络通信量:由于存储过程在服务器端执行,只需发送执行结果给客户端,从而减少了网络通信量。
- 预防SQL注入攻击:通过使用存储过程,可以避免直接将用户输入嵌入SQL语句,从而预防SQL注入攻击。
存储过程的缺点
- 依赖DBMS功能:过多依赖特定DBMS的功能(如触发器、存储过程等)可能导致在转换数据库平台或升级后台数据库系统软件版本时,之前的架构设计无法重用。
- 增加应用与数据库的耦合度:大量使用存储过程会增加应用系统与数据库的耦合程度,增加应用系统移植的难度。
- 增加程序调试难度:存储过程的调试通常比应用程序代码更复杂。
- 数据库压力与资源分配:大量使用存储过程可能导致数据库压力过大,而中间层压力太小,造成资源闲置。
- 版本控制与管理困难:在多人开发环境中,存储过程的版本控制和管理不如应用程序代码方便。
创建和执行存储过程
-
创建存储过程的格式:
CREATE PROCEDURE 存储过程名 【@parameters 数据类型】 【=default】 【output】 AS <SQL语句>
-
执行存储过程的格式:
EXEC | EXECUTE 【@返回状态=】 【schema_name.】存储过程名称 【@形参=】{value | @变量【output】 | 【DEFAULT】 【,...n】 【WITH RECOMPILE】