Database Technology and Application 数据库技术及应用 ——SQL Server Database Technology and Application

课程名称：数据库技术 教材：数据库技术及应用 李雁翎 总学时:48学时（理论32学时+上机16学时） 任课教师：毕娜 所学专业：网络工程

课程要求 不旷课、不迟到、不早退 认真听课，认真复习，认真完成作业。 尽量靠前坐

课程要求 上课时将手机、呼机等通讯工具关闭，上课认真听讲 跟上进度，完成课堂习题 课下复习，完成课后作业 上机前做好准备

学习这门课程的相关思考？ 接触过哪些数据库？ 这说明什么？ 这些数据库是用什么方法什么软件管理的？

教学目的 通过本课程的学习,能对数据库技术及其应用系统有一个较全面的认识。 了解数据库系统的基本概念和体系结构。 掌握关系数据库SQL语言的使用技术。 了解和掌握关系数据库的规范化理论及数据库设计的全过程，能进行数据库结构的设计和简单应用系统的设计。 了解数据库系统的保护措施。

为什么学习数据库技术 随着科学技术和社会经济的飞速发展，人们掌握的 信息量急剧增加，要充分地开发和利用这些信息资源， 就必须有一种新技术能对大量的信息进识别、存储、处 理与传播。随着计算机软硬件技术的发展，20世纪60年 代末，数据库技术应运而生，并从70年代起得到了迅速 的发展和广泛的应用。数据库技术主要研究如何科学地 组织和存储数据，如何高效地获取和处理数据。数据库 技术作为数据管理的最新技术，目前已广泛应用于各个 领域。对于一个国家来说，数据库的建设规模、数据库 信息量的大小和使用频度已经成为衡量这个国家信息化 程度的重要标志。

为什么学习数据库技术（续） 在新的时代中数据库管理技术的运用最成功的方面体 现在营销方面。主要分为：运营数据库与营销数据库。 运营数据库 企业用来执行业务交易，并且记录交易状态和订单 执行情况的系统所产生的数据库。

为什么学习数据库技术（续） 营销数据库 企业利用经营过程中采集的各种客户消费信息、行 为信息和背景资料，经过一定分析和整理后，以客户 为核心来构建的。

第 1 章 数据库系统概述 本章重点： 数据 数据模型 数据库 数据库管理系统 数据库系统的体系结构 数据库系统 数据库设计

1.1 信息、数据与数据处理 1.1.1 信息与数据 1.1.2 数据处理

1.1.1 信息与数据 1.信息 信息（Information）是人们对于客观事物属性和运动状态的反映。它所反映的是关于某一客观系统中，某一事物的存在方式或某一时刻的运动状态。 2.数据 数据(Data)是反映客观事物存在方式和运动状态的记录，是信息的载体。对客观事物属性和运动状态的记录是用一定的符号来表达的，因此说数据是信息的具体表现形式。

1.1.1 信息与数据 数据(Data)是数据库中存储的基本对象 数据的定义 描述事物的符号记录 数据的种类 文本、图形、图像、音频、视频、学生的档案记录、货物的运输情况等 数据的特点 数据与其语义是不可分的

1.1.1 信息与数据 数据举例： 数据的含义称为数据的语义，数据与其语义是不可分的。 例如 93是一个数据 语义1：学生某门课的成绩 例如 93是一个数据 语义1：学生某门课的成绩 语义2：某人的体重 语义3：计算机系2003级学生人数 语义4：请同学给出。。。

1.1.1 信息与数据 数据举例： 学生档案中的学生记录 （刘华，男，1991，辽宁，市场营销系，2010） 数据的形式不能完全表达其内容 数据的解释 语义：学生姓名、性别、出生年月、籍贯、所在系别、入学时间 解释：刘华是个大学生，1991年出生，辽宁人，2010年考入市场营销系

1.1.1 信息与数据 3. 数据与信息 数据与信息在概念上是有区别的。从信息处理角度看，任何事物的存在方式和运动状态都可以通过数据来表示的，数据经过加工处理后，使其具有知识性并对人类活动产生作用，从而形成信息。 信息是有用的数据，数据是信息的表现形式。信息是通过数据符号来传播的，数据如不具有知识性和有用性则不能称其为信息，也就没有价值输入计算机或数据库中进行处理。

1.1.2 数据处理 人工管理阶段 文件系统阶段 数据库系统阶段 所谓数据处理，实际上就是利用计算机对各种类型的数据进行加工处理。它包括对数据的采集、整理、存储、分类、排序、检索、维护、加工、统计和传输等一系列操作过程。数据处理的目的是从人们收集的大量原始数据中，获得人们所需要的资料并提取有用的数据成份，作为行为和决策的依据。 人工管理阶段 文件系统阶段 数据库系统阶段

1.1.2 数据处理 1.人工管理阶段 时期 20世纪40年代中--50年代中 产生的背景 应用需求 科学计算 硬件水平 无直接存取存储设备 应用需求 科学计算 硬件水平 无直接存取存储设备 软件水平 没有操作系统 处理方式 批处理

1.1.2 数据处理 特点 数据的管理者：用户（程序员），数据不保存 数据面向的对象：某一应用程序 数据的共享程度：无共享、冗余度极大 数据的独立性：不独立，完全依赖于程序 数据的结构化：无结构 数据控制能力：应用程序自己控制

人工管理阶段应用程序与数据之间的对应关系

1.1.2 数据处理 2.文件系统阶段 特点 数据的管理者：文件系统，数据可长期保存 20世纪50年代后期至60年代中后期，随着硬件方面磁鼓、磁盘联机的外存储器的研制并投入使用，软件方面高级语言和操作系统软件出现，这时计算机的应用不仅仅用于科学计算，同时也开始以“文件”的方式介入数据处理。 特点 数据的管理者：文件系统，数据可长期保存

1.1.2 数据处理 数据面向的对象：某一应用程序 数据的共享程度：共享性差、冗余度大 数据的结构化：记录内有结构,整体无结构 数据的独立性：独立性差，数据的逻辑结构改变必须修改应用程序 数据控制能力：应用程序自己控制

文件系统阶段应用程序与数据之间的对应关系

1.1.2 数据处理 文件系统中数据的结构 记录内有结构。 数据的结构是靠程序定义和解释的。 数据只能是定长的。 可以间接实现数据变长要求，但访问相应数据的应用程序复杂了。 文件间是独立的，因此数据整体无结构。 可以间接实现数据整体的有结构，但必须在应用程序中对描述数据间的联系。 数据的最小存取单位是记录。

1.1.2 数据处理 文件系统有数据冗余、数据不一致和数据联系弱三个缺点。 职工档案文件 工号：123；职工姓名：张三；职工电话：67890123 工号：124；职工姓名：李四；职工电话：67543210 工号：125；职工姓名：张三；职工电话：65467890 冗余，且可能不一致 职工工资文件 工号：123；职工工资：2230元；职工电话：62345000 工号：124；职工工资：3500元；职工电话：67543210 工号：125；职工工资：2400元；职工电话：65467890 原因：文件中数据没有联系

1.1.2 数据处理 3.数据库系统阶段 进入20世纪60年代后期，随着计算机应用领域的日益发展，计算机用于数据处理的范围越来越广，数据处理的数据量越来越大，仅仅基于文件系统的数据处理技术很难满足应用领域的需求。于此同时，计算机硬件技术也正在飞速发展，磁盘存储技术取得重要突破，大容量磁盘进入市场，数据处理软件环境的改善成为许多软件公司的重要投入。在实际需求迫切、硬件与软件竞相拓展的环境中，数据库系统应运而生。 在数据库系统阶段数据处理的特点是： （1）数据整体结构化； （2）数据共享性高； （3）具有很高的数据独立性； （4）完备的数据控制功能。

1.1.2 数据处理

1.2 数据描述 所谓数据描述，就是以“数据”符号的形式，从满足用户需求出发，对客观事物属性和运动状态进行描述。数据的“描述”既要符合客观现实，又要适应数据库原理与结构，同时也适应计算机原理与结构。 由于计算机不可能直接处理现实世界中的具体事物，所以人们必须事先把具体事物转换成计算机能够处理的数据。在数据库技术中使用数据模型来抽象、表示现实世界中的数据和信息。 三个数据范畴：现实世界、信息世界和计算机世界。

1.2 数据描述 现实世界 概念模型 现实世界 数据库设计人员完成 认识 抽象 概念模型 逻辑模型 数据库设计人员完成 信息世界 概念模型 现实世界 概念模型 数据库设计人员完成 现实世界 认识 抽象 概念模型 逻辑模型 数据库设计人员完成 信息世界 概念模型 逻辑模型 物理模型 由DBMS完成 DBMS支持的数据模型 机器世界 现实世界中客观对象的抽象过程

1.3 数据模型 1.3.1 两大类数据模型 1.3.2 概念模型 1.3.3 最常用的数据模型 1.3.4 关系模型 1.3.5 面向对象模型

数据模型 在数据库中用数据模型这个工具来抽象、表示和处理现实世界中的数据和信息。 通俗地讲数据模型就是现实世界的模拟 数据模型应满足三方面要求 能比较真实地模拟现实世界 容易为人所理解 便于在计算机上实现

1.3.1 两大类数据模型 数据模型分为两类（分属两个不同的层次） (1) 概念模型 也称信息模型，它是按用户的观点来对数据和信息建模，用于数据库设计。 (2) 逻辑模型和物理模型 逻辑模型主要包括网状模型、层次模型、关系模型、面向对象模型等，按计算机系统的观点对数据建模，用于DBMS实现。 物理模型是对数据最底层的抽象，描述数据在系统内部的表示方式和存取方法，在磁盘或磁带上的存储方式和存取方法。

1.3.1 两大类数据模型 客观对象的抽象过程---两步抽象 现实世界中的客观对象抽象为概念模型； 把概念模型转换为某一DBMS支持的数据模型

1.3.2 概念模型 信息世界中的基本概念 概念模型的一种表示方法 两个实体型之间的联系 两个以上实体型之间的联系 单个实体型内的联系 一个实例

1.3.2 概念模型 概念模型的用途 概念模型用于信息世界的建模 是现实世界到机器世界的一个中间层次 是数据库设计的有力工具 概念模型又称实体-联系模型（Entity Relationship Model简称E-R模型），主要用于描述信息世界中实体的联系，是建立概念模型的实用工具。 概念模型的用途 概念模型用于信息世界的建模 是现实世界到机器世界的一个中间层次 是数据库设计的有力工具 数据库设计人员和用户之间进行交流的语言

1.3.2 概念模型 对概念模型的基本要求 较强的语义表达能力 能够方便、直接地表达应用中的各种语义知识 简单、清晰、易于用户理解

一、信息世界中的基本概念 1.实体(Entity) 实体(Entity)是客观存在并相互区别的“事物”。 可以是具体的人、事、物或抽象的概念。 2.属性(Attribute) 实体有若干个特性，每一个特性称为实体一个属性。 一个实体可以由若干个属性来刻画。

一、信息世界中的基本概念 属性的取值范围称为该属性的域。 3.实体型(Entity Type) 用实体名和属性名称集来描述同类实体，称为实体型。 4.实体集(Entity Set) 实体集是若干个同类实体全部信息的集合。 5.域（Domain） 属性的取值范围称为该属性的域。

一、信息世界中的基本概念 6. 码(Key) 如果某个属性或某个属性集的值能够唯一地标识 出实体集中的某一个实体，该属性或属性集就可称 为码 （关键字）。 7.联系(Relationship) 联系是两个或两个以上的实体集间的关联关系。 实体内部的联系通常是指组成实体的各属性之间的联系。 实体之间的联系通常是指不同实体集之间的联系。

二、 概念模型的一种表示方法 实体－联系方法(E-R方法) 用E-R图来描述现实世界的概念模型 E-R方法也称为E-R模型

E-R图 实体型 属性 用矩形表示，矩形框内写明实体名。 用椭圆形表示，并用无向边将其与相应的实体连接 起来 学生 教师 学生 学号 年龄 性别 姓名

E-R图(续) 联系 联系本身： 用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型（1:1、1:n或m:n）

联系的表示方法 实体型A 联系名 实体型B 1 1:1联系 n 1:n联系 m m:n联系

联系的表示方法示例 班级 班级-班长 班长 1 1:1联系 课程 选修 学生 m n m:n联系 组成 1:n联系

联系的属性 联系的属性： 联系本身也是一种实体型，也 可以有属性。如果一个联系具有属性，则这些属性也要用无向边与该联系连接起来 课程 m 联系本身也是一种实体型，也 可以有属性。如果一个联系具有属性，则这些属性也要用无向边与该联系连接起来 课程 选修 学生 m n 成绩

三、两个实体型之间的联系 用图形来表示两个实体型之间的这三类联系 实体型A 联系名 实体型B 1 1:1联系 n 1:n联系 m m:n联系

两个实体型之间的联系（续） 班级 一对一联系（1:1） 1 实例 定义： 班长 班级-班长 班长 1 1:1联系 一对一联系（1:1） 　 实例 一个班级只有一个班长 一个班长只在一个班中任职 定义： 如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1:1

两个实体型之间的联系（续） 一对多联系（1：n） 实例 班级 定义： 1 组成 n 学生 一个班级中有若干名学生， 每个学生只在一个班级中学习 定义： 如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1:n 班级 组成 学生 1 n 1:n联系

两个实体型之间的联系（续） 多对多联系（m:n） 实例 课程 定义： m 选修 n 学生 课程与学生之间的联系： 一门课程同时有若干个学生选修 一个学生可以同时选修多门课程 定义： 如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m≥0）与之联系，则称实体集A与实体B具有多对多联系，记为m:n 课程 选修 学生 m n m:n联系

课程、教师与参考书三个实体型 四、两个以上实体型之间的联系 课程 讲授 教师 1 m 两个以上实体型间1:n联系 参考书 n 实例 一门课程可以有若干个教师讲授， 使用若干本参考书， 每一个教师只讲授一门课程， 每一本参考书只供一门课程使用

两个以上实体型之间的联系(续) 供应商、项目、零件三个实体型 两个以上实体型间的多对多联系 多个实体型间的一对一联系 供应商 供应 项目 m 实例 供应商、项目、零件三个实体型 一个供应商可以供给多个项目多种零件,每个项目可以使用多个供应商供应的零件,每种零件可由不同供应商供给 多个实体型间的一对一联系 供应商 供应 项目 m p 两个以上实体型间m:n联系 零件 n

五、单个实体型内的联系 一对多联系 职工 领导 1 n 实例 职工实体型内部具有领导与被领导的 联系 某一职工（干部）“领导”若干名职工 一个职工仅被另外一个职工直接领导 这是一对多的联系 职工 领导 1 n 单个实体型内部1:n联系

六、一个实例 用E-R图表示某工程公司原材料库房管理系统的 概念数据库设计 系统调研 (1).公司有多个原材料库房，每个库房分布在不同的地方，每个库房有不同的编号，公司对这些库房进行统一管理。

一个实例（续） (2).每个库房可以存放多种不同的原材料，为了便于管理，各种原材料分类存放，同一种原材料集中存放在同一个库房中。 (3).每一个库房可安排一名或多名员工在库房工作，在这些库房，每一个管理员有且仅有一名员工是他的直接领导。

一个实例（续） (4).同一种原材料可以供应多个不同的工程项目，同一个工程项目要使用多种不同的原材料。 (5).同一种原材料可由多个不同的厂家供应，同一个生产厂家可供应多种不同的原材料。

一个实例（续） 概念数据库设计 对调研结果进行分析，可以归纳出相应的实体型、联系型及其属性。 库房实体型：具有库房号、地点、库房面积、库房类型等属性。 原材料实体型：具有材料号、名称、规格、单价、说明等属性。 员工实体型：具有员工号、姓名、性别、出生日期、职称等属性。

一个实例（续） 工程项目实体型：具有项目号、预算资金、开工日期、竣工日期等属性 生产厂家实体型：具有厂家号、厂家名称、通信地址、联系电话等属性。 工作联系型：是1：n型联系。 领导联系型：是1：n型联系。 存放联系型：是m：n型联系，且具有“库存量”属性。 供应联系型：是一个三元联系型，且具有“供应量”属性。

一个实例（续） 库房实体型：

一个实例（续） 2.原材料实体型：

一个实例（续） 3.员工实体型：

一个实例（续） 4.程项目实体型：

一个实例（续） 5.生产厂家实体型：

一个实例（续） 分析并设计出对应的实体型、联系型及其属性后，画出ER图 库存号 地点 库房面积 库房类型 员工号 姓名 性别 职称 库房 工作 员工 1 n 存放 原材料 库存量 材料号 名称 规格 单价 说明 供应 供应量 生产厂家 m p 厂家号 厂家名称 通信地址 联系电话 工程项目 项目号 竣工日期 开工日期 预算资金 领导

1.3.3 最常用的数据模型 非关系模型 层次模型(Hierarchical Model) 网状模型(Network Model) 关系模型(Relational Model) 面向对象模型(Object Oriented Model）

层次模型： 用树型（层次）结构表示实体类型及实体间联系的数据模型称为层次模型(Hierarchical Model)。 层次模型是指用树行结构表示实体及其之间的联系，树中每一个节点代表一个记录类型，树状结构表示实体型之间的联系。 　　 在一个层次模型中的限制条件是：有且仅有一个节点，无父节点，此节点为树的根；其他节点有且仅有一个父节点。 　　　　 缺点：只能表示1：N的联系。尽管有许多辅助手段实现M：N的联系，但比较复杂，不易掌握。

层次模型像一颗倒立的树，结点的双亲是唯一的 Ｒ 1 根结点 2 兄弟结点 3 叶结点 4 5 层次模型像一颗倒立的树，结点的双亲是唯一的

网状模型 用有向图结构表示实体类型及实体间联系的数据结构模型称为网状模型（Network Model）。 特点：用网络结构表示实体类型及其实体之间联系的模型。顾名思义，一个事物和另外的几个都有联系……这样构成一张网状图。 　　 网状模型主要有以下两个特征: 　　 (1)允许一个以上的节点无双亲。 　　 (2)一个节点可以有多于一个的双亲。

网状数据模型的数据结构 R1 R2 R3 L4 R4 R5 L5 Ｒ 1 2 R3 L1 L2

1.3.4 关系模型 关系数据库系统采用关系模型作为数据的组织方式 1970年美国IBM公司San Jose研究室的研究员E.F.Codd首次提出了数据库系统的关系模型 计算机厂商新推出的数据库管理系统几乎都支持关系模型

1.3.4 关系模型 这里介绍的关系模型是用户观点下的数据模型，实际 上关系模型是可以在某种DBMS的支持下、用某种语言进行 种操作。 把支持关系模型的数据库管理系统称为关系数据库管 理系统，简称RDBMS

1.3.4 关系模型 关系模型的组成： 关系数据结构 关系操作集合 关系完整性约束 关系模型（Relational Model）的所谓“关系”是有特定含义的。一般地说，任何数据模型都描述一定事物数据之间的关系。 关系模型的组成： 关系数据结构 关系操作集合 关系完整性约束

1.3.4 关系模型 数据结构是用来描述现实系统中数据的静态特性的，它不仅要描述客观存在的实体本身，还要描述实体间的联系。 1.数据结构 数据结构是用来描述现实系统中数据的静态特性的，它不仅要描述客观存在的实体本身，还要描述实体间的联系。 在用户观点下，关系模型中数据的逻辑结构是一张二维表，它由行和列组成。 　例如，新生信息表：

1.3.4 关系模型 (1) 关系: 一个关系对应于一张二维表。 (2) 关系名: 如“新生信息” 。 (3)分量 (4) 元组: 表中的一行，对应于存储文件中的一个记录。 (5) 属性: 表中的一列。 (6) 属性名: 给每个属性起一个名字。对应于存储文件中 的字段。

1.3.4 关系模型 (7）超码：能唯一标识元组的属性或属性集。 (8) 候选码：如果在一个关系中，存在多个属性(或属性组 合)都能用来唯一标识该关系的元组，这些属性(或属性组 合)都称为该关系的候选码(或候选关键字)。 例如，假设 “新生信息”关系中的姓名没有重名现 象，则学号和姓名都是候选码。 (9) 主码：在若干个候选码中指定作为码的属性(或属性组 合)称为该关系的主码(或主关键字)。 　 例如，学号可以作为“新生信息”关系的主码。

1.3.4 关系模型 (10) 全码: 如果一个关系模型的所有属性一起构成该关系 的码，则称为全码。 (11) 主属性: 包含在候选码中的属性。如学号。 (12) 非主属性: 不包含在任何候选码中的属性称为非码 属性或非主属性。如性别和年龄。 (13) 域：属性的取值范围。 如，性别域: (男、女)，年龄域: 大于0的整数。

1.3.4 关系模型 (14) 关系模式：对关系的描述。 一般表示为： 关系名(属性1，属性2，…，属性n) 例如， “新生信息”表表示为： 　 例如， “新生信息”表表示为： 　　 新生信息(学号，姓名，性别，出生年月，籍贯，班级编号)

1.3.4 关系模型 学生 选修 课程 在关系模型中，实体和实体之间的联系都是用关系来 表示的。 例如，学生、课程和选修关系可以表示为： 新生信息(学号，姓名，性别，出生年月，籍贯，班级编号) 课程(课程号，课程名，学分) 选修(学号，课程号，成绩) m 学生 选修 课程 n

1.3.4 关系模型 2.数据操作 数据操作用于描述数据的动态特性。关系模型的数据操作是集合操作性质的，即数据操作的对象和操作结果均为若干个元组，或属性集合，甚至是若干关系的操作，它当然包含了单个行的操作，而非关系模型的数据操作则都是单个的数据行的操作。 关系模型的数据操作主要是查询、插入、删除和修改。

1.3.4 关系模型 数据约束用于对数据本身、数据与数据间的约束。 主要包括三类: 实体完整性 参照完整性 用户定义的完整性。 3.数据约束 数据约束用于对数据本身、数据与数据间的约束。 主要包括三类: 实体完整性 参照完整性 用户定义的完整性。 其中，实体完整性和参照完整性是关系模型必须满足的完整性约束条件，用户定义的完整性是指针对具体应用需要自行定义的约束条件。

1.3.4 关系模型 （1）实体完整性 实体完整性是对关系中元组的唯一性约束，也就是 对组成主键的属性值的约束，即关系(表) 中组成主键的属 性值不能重复，且不能是空值(NULL)。Null它不等于0, 也不等于空字符串，而是未知的值，是不确定的值。 （2）参照完整性 参照完整性是对关系数据库中建立关联关系的关系 间数据参照引用的约束，也就是对组成外键的属性值的约 束。准确地说，参照完整性是指关系中的外键，必须是另 一个关系的主键有效值，或者是NULL（空）值。

1.3.4 关系模型 例如，对于以下三个关系模式： 新生信息(学号，姓名，性别，出生年月，籍贯，班 级编号) 课程(课程号，课程名，学分) 选修(学号，课程号，成绩) 选修关系的学号必须在学生信息关系中存在的学号， 而选修关系的课程号也必须是一个在课程关系中存在的课 程号。 主码:学号 主码: 课程号 主码: (学号，课程号)

1.3.4 关系模型 例如，设有以下两个关系模式： 职工(职工编号，姓名，性别，部门编号) 部门(部门编号，名称，地址，简介) 在“职工”关系中，主码为职工编号，在“部门”关系中，主 码为部门编号，所以“职工”关系中的部门编号是该关系的外 码。 “职工”关系为参照关系； “部门”关系为被参照关系。

1.3.4 关系模型 （3）用户自定义完整性 用户自定义完整性约束是用户自行定义的删除约束、更新约束、插入约束。 例如：对于关系模式： 新生信息(学号，姓名，性别，出生年月，籍贯，班级编号) 可以定义: 性别字段的值只能为“男”和“女”

1.3.4 关系模型 (1) 表中的每一个数据项必须是单值的，每一个属性 必须是不可再分的基本数据项。 例如，下表就是一个不满该要求的表 4.对关系的限制 (1) 表中的每一个数据项必须是单值的，每一个属性 必须是不可再分的基本数据项。 例如，下表就是一个不满该要求的表 职工编号 姓名 工资 基本工资 职务工资 工龄工资 001 赵军 2000 500 002 刘娜 1800 400 300 003 李东 2300 700 800 ……

1.3.4 关系模型 (2) 每一列中的数据项具有相同的数据类型，来自同 一个域。例如，姓名都是字符类型，成绩都是整数类型。 (3) 每一列的名称在一个表中是唯一的。 (4) 列次序可以是任意的。 (5) 表中的任意两行(即元组)不能相同。 (6) 行次序可以是任意的。

1.3.4 关系模型 5.关系规范化 要把一组数据存储到数据库中，如何为这些数据设计一个合适的逻辑结构呢？如在关系数据库系统中，针对一个具体问题，应该构造几个关系？每个关系由哪些属性组成？使数据库系统无论是在数据存储方面，还是在数据操纵方面都有较好的性能。这就是关系数据库规范化理论要研究的主要问题。 　 E-R模型的方法讨论了实体与实体之间的数据联系，而关系规范化理论主要讨论实体内部属性与属性之间的数据的联系，其目标是要设计一个“好”的关系数据库模型。

1.3.4 关系模型 例如： 关系：学生(学号,姓名,性别,课程号,课程名称,成绩) 学号 姓名 性别 课程号 课程名称 成绩 0601001 张军 男 001 市场营销 78 0601002 李辉 002 营销调研 89 0601003 赵心 女 003 统计学 85 0601004 林梅 004 数据库技术 79 90

1.3.4 关系模型 “学生”关系存在以下问题: (1) 数据冗余 所谓数据冗余就是数据的重复出现。当一个学生选修 多门课程时，学生信息重复出现，导致了数据冗余的现象。 例如，以上关于“林梅”的信息就出现了三次；同样，一门 课程有多个学生选修，也导致了该课程信息的冗余。例如, “市场营销”课程被“林梅”和“张军”选修了，因此，其课 程名称出现了两次。显然，数据冗余会导致数据库存储性 能的下降，同时还会带来数据的不一致性问题。

1.3.4 关系模型 (2) 不一致性 由于存在着数据冗余，因此，如果某个数据需要修改, 则可能会因为其多处存在而导致在修改时不能全部修改过 来，产生数据的不一致。 例如，假设有40名学生选修了“市场营销”这门课, 则在关系表中就会有40条记录包含有课程名称“市场营销 ”，如果该课程名称需要改成“数据库原理及应用”，则 可能会只修改了其中的一些记录而其他记录没有修改。这 就是数据的不一致，也叫更新异常。

1.3.4 关系模型 (3) 插入异常 如果新生刚刚入校，还没有选修课程，则学生信息就 无法插入到表中，因为课程号为空，而主码为（学号，课 程号），根据关系模型的实体完整性规则，主码不能为空 或部分为空，因此无法插入新生数据，这就是插入异常。 又如，学校计划下学期开一门新课“网络营销”，该课程 信息也不能马上添加到表中，因为还没有学生选修该课 程，无法知道学生的信息。简单来说，插入异常就是该插 入的数据不能正常插入。

1.3.4 关系模型 (4) 删除异常 当学生毕业时，需要删除相关的学生记录，于是就会 删除对应的课程号、课程名信息。这就是删除异常。例 如，在“学生”关系表中要删除学生记录（060103，赵 心，女，003，统计学，85），则会丢失课程号“003”， 课程名为“统计学”的课程信息。简单来说，删除 异常就是不该删除的数据被异常地删除了。

1.3.4 关系模型 为了克服以上问题，可以将“学生”关系分解为： 学生基本信息（学号，姓名，性别） 课程（课程号，课程名称） 选修（学号，课程号，成绩） 分解后的关系 在一定程度上解决了数据冗余 解决了插入异常问题 解决了删除异常的问题

1.3.4 关系模型 规范化理论用于改造关系模式，通过分解关系模式来 消除其中不合适的数据依赖，以解决数据冗余、插入异常、 删除异常等问题。 所谓规范化，就是用形式更为简洁、结构更加规范的 关系模式取代原有关系的过程。

1.3.4 关系模型 要设计一个好的关系，必须使关系满足一定的约束条件, 这种约束条件已经形成规范，分成几个等级，一级比一级 要求更严格。满足最低一级要求的关系属于第一范式 （1NF），在此基础上如果进一步满足某种约束条件，达到 第二范式标准，则称该关系属于第二范式（2NF），等等， 直到第五范式。 一个较低的范式，可以通过关系的无损分解转换为若 干个较高级范式的关系，这一过程叫做关系的规范化。

1.3.4 关系模型 (1) 第一范式（1NF） 定义：如果一个关系模式R的所有属性都是不可分的基 本数据项，则R属于1NF。 第一范式是对关系模式的最起码的要求。不满足第一 范式的数据库模式不能称为关系数据库。

1.3.4 关系模型 例如，以下“学生”关系满足第一范式 学号 姓名 性别 课程号 课程名称 成绩 0601001 张军 男 001 市场营销 78 0601002 李辉 002 营销调研 89 0601003 赵心 女 003 统计学 85 0601004 林梅 004 数据库技术 79 90

1.3.4 关系模型 以下“工资”表具有组合数据项，不属于第一范式。 职工编号 姓名 工资 基本工资 职务工资 工龄工资 001 赵军 2000 500 002 刘娜 1800 400 300 003 李东 2300 700 800 ……

1.3.4 关系模型 将“工资”表规范化为第一范式： 职工编号 姓名 基本工资 职务工资 工龄工资 001 赵军 2000 500 002 刘娜 1800 400 300 003 李东 2300 700 800 …… 　 满足第一范式的关系模式不一定就是一个好的关系模式。例如，对于前面的“学生”关系，已经分析过，它存在数据冗余、插入异常、删除异常等问题。

1.3.4 关系模型 (2) 第二范式(2NF) 定义：若关系模式R是1NF，并且每一个非主属性都完全函数依赖于R的码，则R属于2NF。 例如，对于学生关系： 学生(学号,姓名,性别,课程号,课程名称,成绩) 码:（学号，课程号） 因此: 学号、课程号是主属性，性别、课程名称、成绩是非主属性。 存在部分函数依赖： 学号→姓名 学号→性别 课程号→课程名称 存在非主属性对码的部分函数依赖，因此不是2NF

学号 姓名 性别 0601001 张军 男 0601002 李辉 0601003 赵心 女 0601004 林梅 课程号 课程名称 001 市场营销 002 营销调研 003 统计学 004 数据库技术

学号 课程号 成绩 0601001 001 78 0601002 002 89 0601003 003 85 0601004 004 79 90

1.3.4 关系模型 改进方法： 对该关系进行分解，生成若干关系，以消除部分函数依赖。分解为以下三个关系： 学生基本信息（学号，姓名，性别） 　 对该关系进行分解，生成若干关系，以消除部分函数依赖。分解为以下三个关系： 　 学生基本信息（学号，姓名，性别） 　 课程（课程号，课程名称） 　 选修（学号，课程号，成绩） 　 可以看出，在这三个关系中不存在部分函数依赖，因此问题得到了解决。 　 实际上，这里就是把描述不同主题的内容分别用不同的关系来表示。

1.3.4 关系模型 (3) 第三范式(3NF) 定义：如果关系模式R是第一范式，且每个非主属性都非传递函数依赖于主码，则R属于3NF。

1.3.4 关系模型 例如，关系Housing是学生住宿收费表，SID为学生编号，Sname为学生姓名，Building为楼的编号，Fee为每季度需支付的费用。假设一个学生只住在一个大楼里，一个大楼只有一种收费标准。 SID Sname Building Fee 10 Tom A 1100 11 Jerry 12 Kate B 1200 13 Tony 14 John C 1300 15 Mary D 1400

1.3.4 关系模型 主码: SID 存在函数依赖： SID→Building Building→Fee 即存在非主属性Fee对码SID的传递函数依赖，因此关系Housing不是第三范式。

1.3.4 关系模型 该关系存在插入异常、删除异常等问题。例如，如果SID为15的学生退学了，则不仅删除了该学生的信息，同时删除了D楼的收费信息，出现了删除异常。如果新建了一个大楼，还没有学生入住，则该新楼的信息也无法插入到表中，也就是出现了插入异常。同样，如果有400名学生住在同一个楼里，则该楼的信息就要重复400次，因此也存在数据冗余问题。

1.3.4 关系模型 改进方法：将关系Housing分解为两个关系。 “Stu-Housing”关系： SID Sname Building 10 Tom A 11 Jerry 12 Kate B 13 Tony 14 John C 15 Mary D

1.3.4 关系模型 分解后的关系解决了插入异常、删除异常、数据冗余的问题。 “Housing-Fee”关系： Building Fee A 1100 B 1200 C 1300 D 1400 　 分解后的关系解决了插入异常、删除异常、数据冗余的问题。

1.3.4 关系模型 规范化的本质是把表示不同主题的信息分解到不同的关系中，如果某个关系包含有两个或两个以上的主题，就应该将它分解为多个关系，使每个关系只包含一个主题。 在分解关系之后，需要注意建立起关系之间的关联约束（参照完整性约束）。 关系变得更加复杂，对关系的使用也会变得复杂，因此并不是分解得越细越好。一般来说，用户的目标是第三范式（3NF）数据库，因为在大多数情况下，这是进行规范化功能与易用程度的最好平衡点。在理论上和一些实际使用的数据库中，有比3NF更高的等级。

1.3.4 关系模型 将E-R图转换成关系模型的方法： 1.将每个实体的属性写出来形成一个关系模式 2.每个多对多的联系转换成一个关系模式 3.将一对多的联系所对应的“多方”实体（关系）中加入“一方”的主码作为外码 4.对于一对一的联系，可以在任一方加入另一方的主码作为外码

1.3.5 面向对象模型 面向对象模型(Object Oriented Model)最基本的概念是对象（Object）和类（Class）。在面向对象模型中，对象是指客观的某一事物，其对对象的描述具有整体性、完整性，对象不仅包含描述它的数据，而且还包含对它进行操作的方法的定义，对象的外部特征与行为是封装在一起的。其中，对象的状态是该对象属性集，对象的行为是在对象状态上操作的方法集。共享同一属性集和方法集的所有对象构成了类。

1.4 数据库系统 1.4.1 数据库 1.4.2 关系数据库 1.4.3 数据库管理系统 1.4.4 数据库系统组成

1.4.1 数据库 数据库(Data Base，简称DB)是数据库系统的核心部分，是数据库系统的管理对象。 所谓数据库，是以一定的组织方式将相关的数据组织在一起，长期存放在计算机内，可为多个用户共享，与应用程序彼此独立，统一管理的数据集合。

1.4.2 关系数据库 在一个给定的应用领域中，若干关系及关系之间联系的集合构成一个关系数据库（Relational Data Base）。 在关系数据库中，将一个关系视为是一张二维表，又称其为数据表（简称表），这个表包含表结构、关系完整性、表中数据及数据间的联系。

1.4.2 关系数据库 关系数据库的主要特点如下： （1）一个关系数据库是由若干满足关系模型，且彼此关联的关系组成。 （2）关系数据库要以面向系统的思想组织数据，使数据具有最小的冗余度，支持复杂的数据结构。 （3）关系数据库具有高度的数据和程序的独立性，应用程序与数据的逻辑结构及数据的物理存储方式无关。

1.4.2 关系数据库 据能为多个用户服务。 （5）关系数据库允许多个用户同时访问，同时提了 （4）关系数据库中数据具有共享性，使数据库中的数 据能为多个用户服务。 （5）关系数据库允许多个用户同时访问，同时提了 各种控制功能，保证数据的安全性、完整性和并发性控制。

1.4.3 数据库管理系统 数据库管理系统(Data Base Management System，简称DBMS)是位于用户与操作系统之间，具有数据定义、管理和操纵功能的软件集合。 DBMS的主要功能包括数据定义功能、数据操纵功能、数据库的运行管理功能、数据库的建立和维护功能。为了实现这些管理和控制的功能，DBMS提供了数据子语言，由以下三个部分组成： （1）数据定义语言(Data Definition Language简称DDL)。 定义数据库中的数据对象。

1.4.3 数据库管理系统 （2）数据操纵语言(Data Manipulation Language简称 DML)。 操纵数据实现对数据库的基本操作 (查询、插入、删除和修改) （3）数据控制语言(Data Control Language简称DCL)

1.4.4 数据库系统组成 数据库系统的体系结构 数据库系统的体系结构是数据库系统的一个总的框架。尽管实际的数据库系统软件产品多种多样，它们支持的数据模型也不一定不同，使用不同的数据库语言，建立在不同的操作系统之上，数据的存储结构也各不相同，但是绝大多数数据库系统在总的体系结构上都具有三级模式的结构特征。 （1）外模式 （2）模式 （3）内模式

1.4.4 数据库系统组成 三级模式结构：外模式、模式和内模式 外模式/模式映像 应用A 应用B 应用C 应用D 应用E 外模式1 外模式2 外模式3 模式 内模式 数据库 模式/内模式映像

1.4.4 数据库系统组成 　　三级模式是对数据的三个抽象级别，它把数据的具体组织留给DBMS管理，使用户能逻辑地抽象地处理数据，而不必关心数据在计算机中的表示和存储。为了实现这三个抽象层次的联系和转换，数据库系统在这三级模式中提供了两层映像：外模式／模式映像；模式／内模式映像。

1.4.4 数据库系统组成 1. 模式(逻辑模式) 是数据库中全体数据的逻辑结构和特性的描述，是所有用户的公共数据视图。 以某一种数据模型为基础。不仅要定义数据的逻辑结构，而且要定义与数据有关的安全性、完整性要求；不仅要定义记录内部的结构，而且要定义数据以及不同记录之间的联系。 模式既不涉及数据的物理存储细节和硬件环境，也与具体的应用程序和开发工具无关。 DBMS提供模式数据描述语言描述模式。

1.4.4 数据库系统组成 2. 外模式(子模式或用户模式) 是数据库用户看到的数据视图，是与某一应用有关的数据的逻辑表示。 通常是模式的子集，由于不同的用户其需求不同，看待数据的方式不同，对数据的要求不同，使用的程序设计语言也可以不同，因此不同用户的外模式描述是不同的。即使对模式中同一数据，在外模式中的结构、类型、长度、保密级别等都可以不同。 DBMS提供外模式数据描述语言来描述外模式。

1.4.4 数据库系统组成 3. 内模式 是全体数据库数据的内部表示或者低层描述，用来定义数据的存储方式和物理结构。 通常用内模式数据描述语言来描述和定义。

1.4.4 数据库系统组成 1. 外模式/模式映像 定义某一个外模式和模式之间的对应关系。当模式改变时，外模式/模式的映像要作相应的改变(由DBA负责)以保证外模式保持不变。 对应于同一个模式，可以有任意多个外模式。 2. 模式/内模式映像 定义数据的逻辑结构和存储结构之间的对应关系，说明逻辑记录和字段在内部是如何表示的。这样，当数据库的存储结构改变时，可相应修改模式／内模式的映像，从而使模式保持不变。

1.4.4 数据库系统组成 二级映像功能使数据库系统中的数据具有较高的逻辑独立性和物理独立性。 说明： 模式（全局逻辑结构）应该首先定义，因为它独立于数据库的其他所有结构描述。 内模式（存储模式）依赖于全局逻辑结构，独立于任何一个外模式（用户的局部逻辑结构）。 外模式独立于存储模式和存储设备，它必须在数据库的全局逻辑结构描述（模式）的基础上定义。

1.4.4 数据库系统组成 一个子模式一旦被定义，则除非模式结构的变化使得子模式中的某些数据无法再从数据库中导出，否则不必改变子模式。通过调整外模式/模式映像可实现这一点。这就是子模式对于模式的相对独立性，即逻辑数据独立性。 应用程序是在子模式的数据结构上编制的，因此，它必然依赖于特定的子模式。但是，在一个完善的数据库系统中，它是独立于存储设备和存储模式的，并且只要数据库全局逻辑模式的变化不导致其对应的子模式的改变，则应用程序也是独立于数据库模式的。

1.4.4 数据库系统组成 数据库系统的组成 数据库系统的组成是在计算机系统的意义上来理解数据库系统，它一般由支持数据库的硬件环境、支持数据库的软件环境（操作系统、数据库管理系统、应用开发工具软件、应用程序等）、数据库、开发、使用和管理数据库应用系统的人员组成。

1.5 数据库设计 1.5.1 数据库设计的任务 1.5.2 数据库设计的方法与步骤

1.5.1 数据库设计的任务 数据库设计的任务主要就是设计数据库模式。这一数据库模式要能够概括具体的数据库应用系统的数据库全局的数据结构，能够反映使用本系统所有用户的数据视图。一个良好的数据库模式应具有最小的数据冗余，在一定范围内实现数据共享特性。 数据库模式一经设计完成，通常情况下是不轻易改动的，它不仅作为应用程序存取数据、处理数据的数据结构参照，还要成为实现数据物理存储的数据结构定义的依据。

1.5.2 数据库设计的方法与步骤 数据库设计归纳为如下几个阶段：需求分析阶段、概念结构设计阶段、逻辑结构设计阶段、物理结构设计阶段、实施阶段、使用与维护阶段。 1.需求分析阶段 需求分析阶段是数据库设计的基础，是数据库设计的最初阶段。这一阶段要收集大量的支持系统目标实现的各类基础数据、用户需求信息和信息处理需求，并加以分析归类和初步规划，确定设计思路。需求分析做得好与坏，决定了后续设计的质量和速度，制约数据库应用系统设计的全过程。

1.5.2 数据库设计的方法与步骤 2.概念结构设计阶段 将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。概念结构是独立于支持数据库的DBMS和使用的硬件环境的。 人们提出了多种概念结构设计的表达工具，其中最常用、最有名的是E-R模型。

1.5.2 数据库设计的方法与步骤 的数据进行分类、组织，形成实体、实体的属性，标识实 在概念结构设计阶段，首先要对需求分析阶段收集到 的数据进行分类、组织，形成实体、实体的属性，标识实 体的码，确定实体之间的联系类型(1:1，1:n，m:n)，针 对各个局部应用设计局部视图（如分E-R图）。合并局部视 图，通过消除各局部视图的属性冲突、命名冲突、结构冲 突、数据冗余等，最终集成为一个全局视图（如整体的E-R 图）。 概念模型是数据库逻辑设计的依据，是整个数据库设 计的关键。

1.5.2 数据库设计的方法与步骤 数据库逻辑结构设计是在概念模型的基础上进行的，逻辑结构设计，就是根据已设计好的概念模型（E-R模 3.逻辑结构设计阶段 数据库逻辑结构设计是在概念模型的基础上进行的，逻辑结构设计，就是根据已设计好的概念模型（E-R模 型），将其转换为与DBMS支持的数据模型相符的逻辑结构。

1.5.2 数据库设计的方法与步骤 用于为逻辑数据模型选取一个最适合应用环境的物理结构，包括数据库在物理设备上的存储结构和存取方法。 4. 物理结构设计阶段 用于为逻辑数据模型选取一个最适合应用环境的物理结构，包括数据库在物理设备上的存储结构和存取方法。 由于不同的数据库产品所提供的物理环境、存取方法和存储结构各不相同，供设计人员使用的设计变量、参数范围也各不相同，所以物理结构设计没有通用的设计方法可以遵循。 主要考虑问题：物理数据库结构应能满足事务在数据库上运行时响应时间少、存储空间利用率高和事务吞吐率大的要求。

1.5.2 数据库设计的方法与步骤 5. 数据库实施阶段 完成数据库物理设计之后，设计人员就要用DBMS提供 的数据定义语言和其他实用程序将数据库逻辑设计和物理 设计结果严格地描述出来，成为DBMS可以接受的源代码， 再经过调试产生目标模式，然后就可以组织数据入库了， 这就是数据库实施阶段。

1.5.2 数据库设计的方法与步骤 (1) 用DBMS提供的数据定义语言（DDL）描述数据库结构。 (2) 组织数据入库。 (3) 编制与调试应用程序。数据库应用程序的设计应该与数 据库设计并行进行。因此，在部分数据录入到数据库中之 后，就可以开始对应用程序进行调试了。这时由于数据入库 尚未完成，可以先使用模拟数据，模拟数据应该具有一定的 代表性，足够测试系统的多数功能。应用程序的设计、编码 和调试方法、步骤应遵循软件工程的规范。 (4) 数据库试运行：功能测试；性能测试。

1.5.2 数据库设计的方法与步骤 6.使用与维护阶段 数据库实施阶段的任务完成后，数据库应用系统将投入使用。为了保证数据库的性能良好，在实际应用中，有时也需要对数据库进行调整、修改和扩充。

1.5.2 数据库设计的方法与步骤 在数据库运行阶段，对数据库经常性的维护工作主要是由DBA完成的。工作主要包括： (1) 数据库的转储和恢复。 (2) 数据库的安全性、完整性控制: DBA需要应用环境的变化 修改原有的安全性控制和完整性约束。 (3) 数据库性能的监督、分析和改进。 (4) 数据库的重组织和重构造。数据库运行一段时间后，由 于记录的不断增、删、改，会使数据库的物理存储变坏，从 而降低数据库存储空间的利用率和数据的存取效率，使数据 库的性能下降，因此需要对数据库进行重新组织。

1.6 小结

作业 P25 1、6、11、13、14