下载文档原格式
SQL Server 2021复习讲义-2021罗剑高老师2021级计算机网络技术专业网络数据库（SQL Server 2021）课程复习资料(可供2021级SQLServer2021参考，考核内容基本与SQL Server 2021一致）广东农工商职业技术学院罗剑高 2021年12月前言为了帮助同学们在教材的基础上更好地复习、更有效地掌握重点，笔者整理了该资料。
该资料撰写的依据是课程所选教材（SQL Server 2021应用教程梁庆枫、颜虹主编）和课程教学目标。
闭卷考试的内容都是基本内容，请同学们认真复习教材里的练习题。
数据库的建立、维护，数据表的建立、维护、查询，索引的概念、创建，视图的概念、创建，存储过程的编程及触发器的编程等是本课程的重点，需掌握。
第1章数据库基础知识1.1 数据库系统的基本概念数据库（database, DB），数据库管理系统（database management system, DBMS），数据库系统（database system, DBS）DB是存放数据的地方，是数据集合，如：在关系型数据库系统中，从逻辑上说，DB是由若干数据表组成的，从物理上来说，DB是由若干文件组成的。
DBMS是软件系统，是DBS的核心组成部分。
DBS是数据库系统，是一个实际可运行的，按照数据库方法存储、维护、提供数据服务的计算机系统，由计算机硬件、DB、DBMS、应用系统和用户构成。
需说明的是，在不引起混淆的情况下，人们常常将DBMS称为DB。
例如，平常所说的Access、SQL Server、Oracle和MySQL等数据库，都属于DBMS的范围。
例题：1．DB就是存放数据的地方，是需要长期存放在计算机内的、有组织的、可共享的的数据集合。
2．DBS是采用了数据库技术的计算机系统，DBS是一个集合体，包含数据库、计算机硬件、软件和（）。
A. 系统分析师B. 程序员C. 数据库管理员D. 操作员 3.数据库系统的英文缩写是（）。
关系数据库范式（1NF,2NF,3NF,BCNF）基本概念定义：符合某⼀种级别的关系模式的集合，表⽰⼀个关系内部各属性之间的联系的合理化程度。
关系模式的范式主要有4种，即第⼀范式（1NF）、第⼆范式（2NF）、第三范式（3NF）和BCNF范式。
满⾜这些范式条件的关系模式可以在不同程度上避免冗余问题、插⼊问题、更新问题和删除问题。
符合⾼⼀级范式的设计，必定符合第⼀级范式。
如符合2NF，必定符合1NF。
把⼀个给定关系模式转化为某种范式的过程称为关系范式的规范化过程，简称规范化。
1. 第⼀范式（1NF）关系模式R中每个属性的值域都是不可分的简单数据项的集合，则称这个关系模式为第⼀范式关系模式1NF。
在任何⼀个关系数据库系统中，第⼀范式都是⼀个最基本的要求。
2. 第⼆范式（2NF）定义：关系模式R是1NF的前提下，每⼀个⾮主键属性都完全函数地依赖于R的键，则R成为第⼆范式关系模式2NF。
例如，关系模式TaobaoPucharsedLog(s_id#, date, buyer_id#, buyer_name, buyer_age, seller_id#, seller_age, goods_id#, goods_name, amount), 其中的键为s_id, buyer_id, seller_id, goods_id四个。
就其中的seller_name属性来说，它仅仅依赖于键seller_id, 和其他键没有关系，即⾮主键属性seller_name部分地依赖于键{s_id#, buyer_id#, seller_id#, goods_id#}，因此TaobaoPucharsedLog关系不符合2NF定义，不是2NF，这将导致三个问题：(1)插⼊异常。
插⼊时必须给定键值，如果键值的⼀部分为空，则导致数据⽆法插⼊。
(2)删除异常。
删除某个信息，整个元组就不能存在了，也必须跟着删除，从⽽丢失了其他信息，产⽣了删除异常，即不应删除的信息也删除了。
关系数据库范式
关系数据库范式是一种用于设计关系数据库的规则和标准，以确保数据的一致性、完
整性和有效性。
主要目的是减少数据冗余和数据维护的复杂性，从而提高数据库的性能和
可靠性。
在关系数据库中，范式共有6个阶段，分别为第一范式（1NF）、第二范式（2NF）、
第三范式（3NF）、巴斯科范式（BCNF）、第四范式（4NF）和第五范式（5NF）。
第一范式（1NF）：属性不可分
第一范式指任何一个关系模式的所有属性都是不可分的原子值，也就是属性的值都不
能再细分成更小的部分。
例如，一个表中的地址字段，可以将其拆分为街道、城市、州和邮政编码等多个部分，但是在1NF中，这些部分都必须被当做单独的属性来存储。
第二范式（2NF）：满足1NF的基础上，消除部分依赖
第二范式指任何非主键属性都必须完全依赖于主键，也就是非主键属性不能只依赖于
主键的一部分。
例如，一个订单表中的商品名称、商品价格和商品数量，都必须依赖于唯一的订单编
号（主键），而不能只依赖于日期等其他属性。
如果存在部分依赖，需要对表进行拆分。
例如，一个客户和订单表中，一个客户可以下多个订单，但是每个订单只能对应一个
客户。
如果将客户的联系方式和收货地址存储在订单表中，就会出现多值依赖的问题。
因此，需要对表进行拆分。
第五范式（5NF）：尽量避免冗余
第五范式指关系模式中的数据不能通过拆分为更小的关系模式来避免冗余数据。
例如，一个图书馆书籍表中，如果将每个书籍作者的个人信息存储在作者表中，就会
出现多次重复的数据。
因此，需要将重复的数据存储在单独的表中，并通过关联方式进行
连接。
数据库范式判断技巧
数据库范式是一种规范化数据库结构的方法，它有三个级别：第一范式（1NF），第二范式（2NF）和第三范式（3NF）。
判断数据库是否符合范式可以通过以下技巧：
1. 第一范式（1NF）判断：
- 每个字段都应该是不可分割的，不允许包含多个值。
- 每个字段都应该具有唯一的名称。
- 需要确保每个字段都包含一个原子值，不允许重复的值。
2. 第二范式（2NF）判断：
- 每个非主键字段都必须完全依赖于主键，即非主键字段不能依赖于其他非主键字段。
- 如果有非主键字段依赖于部分主键，需要将该字段拆分出去，创建一个新的表。
3. 第三范式（3NF）判断：
- 每个非主键字段都必须直接依赖于主键，不能依赖于其他非主键字段。
- 如果有非主键字段同时依赖于其他非主键字段，需要将其中的依赖关系拆分出来，创建一个新的表。
判断数据库是否符合范式要根据具体的表结构和数据依赖关系来进行分析。
一种常用的方法是对每个表进行逐个字段分析，检查字段是否满足范式要求。
如果存在违反范式的情况，需要对表结构进行调整，使其符合范式要求。
1NF, 2NF, 3NF, 4NF, 5NF, BCNF第一范式（1NF）无重复的列基本上现在的关系型数据库都会符合第一范式，不符合的也建立不了。
第二范式（2NF）属性完全依赖于主键要求数据库表中的每个实例或行必须可以被惟一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
例如：员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。
这个惟一属性列被称为主关键字或主键、主码。
所以员工的其它信息都依赖于员工编号。
所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体第三范式（3NF）属性不依赖于其它非主属性要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
简而言之，第三范式就是属性不依赖于其它非主属性。
修正的第三范式（BCNF）要求关系模型中所有的属性（包括主属性和非主属性）都不传递依赖于任何候选关键字。
也就是说，当关系型表中功能上互相依赖的那些列的每一列都是一个候选关键字时候，该满足BCNF。
BCNF实际上是在第三范式的基础上，进一步消除了主属性的传递依赖。
第四范式（4NF）当一个表中的非主属性互相独立时（3NF），这些非主属性不应该有多值。
若有多值就违反了第四范式。
定义比较抽象，可以参照下面的例子理解。
CUSTOMERID PHONE CELL10008828-123414908888888810008838-1234149099999999由于PHONE和CELL是互相独立的，而有些用户又有两个和多个值。
数据库范式名词解释
数据库范式是数据库设计中的一种理论，它基于离散数学中的知识，主要为了解决数据存储和优化的问题。
其核心目标是为了减少数据冗余，提高数据的一致性和完整性。
范式包括六种，从低到高依次是：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF)和第五范式（5NF，又称完美范式）。
其中，满足最低要求的范式是第一范式（1NF）。
第一范式（1NF）要求在关系模型中，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合、数组、记录等非原子数据项。
如果实体中的某个属性有多个值时，必须拆分为不同的属性。
在符合第一范式（1NF）的表中，每个域值只能是实体的一个属性或一个属性的一部分。
简而言之，第一范式就是无重复的域。
数据库范式的主要作用是解决关系数据库中数据冗余、更新异常、插入异常、删除异常问题。
通过应用数据库范式，可以避免数据冗余，减少数据库的存储空间，并降低维护数据完整性的成本。
数据库范式是关系数据库核心的技术之一，也是从事数据库开发人员必备知识。
前言：最近看了看自己的这个简单的文章感觉不错，有机会一定将这个文档更新，分享给所有人们，祝大家学有所成。
本人最近研究mysql，有机会和大家分享mysql笔记^_^文档书写时间：2009年Sql server基础1 Transact-SQL 语言SQL 语言是一种介于关系代数与关系演算之间的语言其功能包括查询操纵定义和控制4 个方面是一个通用的功能极强的关系数据库语言SQL 语言的组成:数据定义语言DDL Data Definition Languagecreate table 创建一个数据库表drop table 从数据库中删除表alter table 修改数据库表结构create view 创建一个视图drop view 从数据库中删除视图create index 为数据库表创建一个索引drop index 从数据库中删除索引create procedure 创建一个存储过程drop procedure 从数据库中删除存储过程...数据操纵语言DML Data Manipulation Languageselect 从数据库表中检索数据行和列insert 向数据库表添加新数据行delete 从数据库表中删除数据行update 更新数据库表中的数据数据控制语言DCL Data Control Languagegrant 授予用户访问权限deny 拒绝用户访问revoke 解除用户访问权限2 条件表达式和逻辑运算符SQL Server提供的算术运算符运算符功能+ 完成两个数值型数据的相加操作/两个字符型数据的字符串串联操作- 完成两个数值型数据的相减操作* 完成两个数值型数据的相乘操作/ 完成两个数值型数据的相除操作% 完成两个数值型数据的模运算SQL Server提供的逻辑运算符运算符功能AND 二元运算，当参与运算的子表达式全部返回TRUE时，整个表达式的最终结果为TRUEOR 二元运算，当参与运算的子表达式中有一个返回为TRUE时，整个表达式返回TRUENOT 对参与运行的表达式结果取反IN 如果操作数与表达式列表中的任何一项匹配，则返回TRUE BETWEEN 如果操作数位于某一指定范围，则返回TRUEEXISTS 如果表达式的执行结果不为空，则返回TRUEANY 对OR操作符的扩展，将二元运算推广为多元运算ALL 对AND运算符的扩展，将二元运算推广为多元运算SOME 如果在一系列比较中，有某些子表达式的值为TRUE，那么整个表达式返回TRUELIKE 如果操作数与一种模式相匹配，那么就为 TRUE比较运算符运算符功能!= 不等于，等同于<>!< 不小于，等同于>=!> 不大于，等同于<=注：通配符：'_' % []3 T-SQL基础操作：Insert：语法：insert into table_name(col_name1...) values (value1...)通过insert select语句将现有表中的数据添加到新表中例如：Insert into tongxulu (姓名,地址,电子邮件)Select SName,SAddress,SEmailFrom student通过select into 语句将现有的表中的数据添加到新表中Select student.SName,student.SAddressInto tongxueluFrom student通过union关键字合并数据进行插入Union:用于将两个不同的数据或查询结果组合成新的结果集例如：Insert student(sname,sgread)Select '张三'，1 unionSelect '李四'，2 unionSelect '王五'，3Update:语法：update <表名> set <列名=更新值> [where <更新条件>]Delete:语法：delete from <表名> [where <删除条件>]Truncate table:语法：Truncate table <表名>数据查询1 使用select查询语法：select <列名>From <表名>[where <条件查询>][order by <排序的列名> [desc 或 asc]]A 查询数据和列B 条件查询C 使用别名D 查询空行（is null）E 查询中使用常量F 查询使用的行数（top num）2 查询排序：使用。
sqlserver面试题SQL Server面试题1. 简介SQL Server是由微软公司开发的关系型数据库管理系统（RDBMS），广泛应用于企业级应用程序、数据仓库以及一系列Web 应用程序中。
在SQL Server的面试过程中，面试官通常会涉及各个方面的知识，包括SQL语法、数据库设计与优化、性能调优、高可用性等。
以下是一些常见的SQL Server面试题及其解答，希望能对您的面试准备有所帮助。
2. SQL基础2.1 SELECT语句在SQL Server中，SELECT语句用于从表中检索数据。
如果要查询一个表中的所有列，可以使用以下语法：SELECT * FROM 表名;如果只需要查询特定的列，可以使用以下语法：SELECT 列名1, 列名2 FROM 表名;2.2 WHERE子句WHERE子句用于指定查询时的条件，可以根据条件过滤出符合要求的行。
例如：SELECT 列名1, 列名2 FROM 表名 WHERE 条件;2.3 ORDER BY子句ORDER BY子句用于按照指定的列对查询结果进行排序，默认情况下是升序排序。
例如：SELECT 列名1, 列名2 FROM 表名 ORDER BY 列名;2.4 GROUP BY子句GROUP BY子句用于按照指定的列对查询结果进行分组。
例如： SELECT 列名1, 列名2 FROM 表名 GROUP BY 列名;3. 数据库设计与优化3.1 范式和反范式范式是用来评估数据库设计是否合理的一种标准。
常见的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）等。
范式化的设计可以提高数据的一致性和减少冗余，但也会增加查询的复杂度。
反范式化是根据实际需求和性能考虑，对数据库进行冗余设计，以提高查询性能。
3.2 索引的优化索引是提高查询性能的重要手段。
在SQL Server中，可以通过CREATE INDEX语句创建索引。
合理选择索引列、避免过多的索引以及定期维护索引可以提高查询性能。
1 第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在第一范式（1NF）中表的每一行只包含一个实例的信息。
例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。
简而言之，第一范式就是无重复的列。
2 第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。
这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。
所谓完
全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
简而言之，第二范式就是非主属性非部分依赖于主关键字。
3 第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。
简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
简而言之，第三范式就是属性不依赖于其它非主属性。
数据库的三范式
1N:关系R中的属性都是不可分割的项.
2N:在1N的基础上,每个非主属性完全函数依赖于码.
3N:在2N的基础上,每一个非主属性既不部分依赖于码也不传递依赖于码.
1N 消除非主属性对码的部分函数依赖
2N 消除非主属性对码的传递函数依赖
3N 消除主属性对码的部分和传递函数依赖
BCNF 消除非平凡且非函数依赖的多值依赖
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。
反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。
实质上，设计范式用很形象、很简洁的话语就能说清楚，道明白。
本文将对范式进行通俗地说明，并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。
范式说明
第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。
这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
例如，如下的数据库表是符合第一范式：
而这样的数据库表是不符合第一范式的：
很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。
因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。
假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个数据库表不满足第二范式，因为存在如下决定关系：
(课程名称) → (学分)
(学号) → (姓名, 年龄)
即存在组合关键字中的字段决定非关键字的情况。
由于不符合2NF，这个选课关系表会存在如下问题：
(1) 数据冗余：
同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
(2) 更新异常：
若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：
假设要开设一门新的课程，暂时还没有人选修。
这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
(4) 删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。
但是，与此同时，课程名称和学分信息也被删除了。
很显然，这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表：
学生：Student(学号, 姓名, 年龄)；
课程：Course(课程名称, 学分)；
选课关系：SelectCourse(学号, 课程名称, 成绩)。
这样的数据库表是符合第二范式的，消除了数据冗余、更新异常、插入异常和删除异常。
另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。
第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。
所
谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C 传递函数依赖于A。
因此，满足第三范式的数据库表应该不存在如下依赖关系：
关键字段→非关键字段x →非关键字段y
假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系： (学号) → (所在学院) → (学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。
把学生关系表分为如下两个表：
学生：(学号, 姓名, 年龄, 所在学院)；
学院：(学院, 地点, 电话)。
这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。
鲍依斯-科得范式（BCNF）：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第
三范式。
假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。
这个数据库表中存在如下决定关系：
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。
但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。
它会出现如下异常情况：
(1) 删除异常：
当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。
(2) 插入异常：
当仓库没有存储任何物品时，无法给仓库分配管理员。
(3) 更新异常：
如果仓库换了管理员，则表中所有行的管理员ID都要修改。
把仓库管理关系表分解为二个关系表：
仓库管理：StorehouseManage(仓库ID, 管理员ID)；
仓库：Storehouse(仓库ID, 存储物品ID, 数量)。
这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。
