第一范式（1NF）无重复的列
第二范式（2NF）属性
完全依赖于主键[消除非主属性对主码的部分函数依赖]
第三范式（3NF）属性
不依赖于其它非主属性[消除传递依赖]
两个属性组成的关系必为2NF，因为两个属性组成 的关系的码只有三种情况：全码；两个分别为码； 的关系的码只有三种情况：全码；两个分别为码； 其中一个是码 关系模式R<U,F> 关系模式R<U,F> 其中：U={A,B,C,D}，分别讨论关系模式R 其中：U={A,B,C,D}，分别讨论关系模式R是否满足 2NF。 2NF。
1)F={A→B,B→C,C→D,D→A} 2NF,因为没有非主属性 因为没有非主属性；
R是2NF,因为没有非主属性；
2)F=Φ 2)F=Φ 2NF,因为没有非主属性 因为没有非主属性；
R是2NF,因为没有非主属性；
5.2.4 2NF 3)F={A→B,B→A,A→C} 候选码为(A,D),(B,D) 因为存在非主属性C (A,D),(B,D)。 候选码为(A,D),(B,D)。
因为存在非主属性C对码 A,D)的部分函数依赖 所以R不是2NF 的部分函数依赖， 2NF。
（A,D)的部分函数依赖，所以R不是2NF。
规范化：由于A→C造成R不是2NF 所以分解为： A→C造成 2NF， 规范化：由于A→C造成R不是2NF，所以分解为： R1（A,C)和R2(A,B,D)均为 均为2NF. R1（A,C)和R2(A,B,D)均为2NF.
4)F={(A,B)→C,D→A} 候选码为(B,D), 因为存在非主属性A对码（ 候选码为(B,D), 因为存在非主属性A对码（B,D) 的部分函数依赖,所以R不是2NF
2NF的部分函数依赖,所以R不是2NF；
规范化：由于D→A造成R不是2NF 所以分解为： D→A造成 2NF， 规范化：由于D→A造成R不是2NF，所以分解为： R1（A,D)和R2(B,C,D)均为 均为2NF. R1（A,D)和R2(B,C,D)均为2NF.
另解： (A,B,C),R (A,B,D)进一步 分解为 (A,B,C),R’’(A,B,D)进一步R 另解：R’(A,B,C),R (A,B,D)进一步R’’分解为 R1”(A,D),R2 (A,D),R2”(B,D) R1 (A,D),R2 (B,D) 5.2.4 2NF 5)F={(A,B)→C,C→A} 候选码为(A,B,D) (B,C,D),因为没有非主 (A,B,D)和 候选码为(A,B,D)和(B,C,D),因为没有非主 属性, 所以， 2NF。
属性, 所以，R是2NF。 结论： 结论： 单个属性组成候选码的关系一定是2NF; 单个属性组成候选码的关系一定是2NF; 两个属性组成的关系一定是2NF;
没有非主属性的关系一定是2NF; 没有非主属性的关系一定是2NF; All-Key的关系一定是 的关系一定是2NF. All-Key的关系一定是2NF. 5.2.5 3NF 定义5.7 关系模式R U,F〉中若不存在这样的码X, 定义5.7 关系模式R〈U,F〉中若不存在这样的码X, 属性组Y及非主属性Z(Z Y)使得X→Y,（Y→X） Z(Z? 使得X→Y, 属性组Y及非主属性Z(Z?Y)使得X→Y,（Y→X） Y→Z,成立 则称R 成立, ∈3NF。
Y→Z,成立,则称R〈U，F〉∈3NF。 由定义5.7可以证明, R∈3NF， 5.7可以证明 由定义5.7可以证明,若R∈3NF，则每一个非主属 性既不部分依赖函数于码也不传递函数依赖于码。
性既不部分依赖函数于码也不传递函数依赖于码 等价定义：关系模式R U,F〉∈2NF， 等价定义：关系模式R〈U,F〉∈2NF，且每一个非 主属性都不传递函数依赖于码，则称R 主属性都不传递函数依赖于码，则称R〈U，F〉 ∈3NF。 ∈3NF。
判断3NF的方法是先判断2NF,然后检查有无非主属 3NF的方法是先判断2NF, 判断3NF的方法是先判断2NF,然后检查有无非主属 性对码的传递函数依赖 5.2.5 3NF 关系模式SC(SNO,CNO,G) (SNO,CNO)→G没 关系模式SC(SNO,CNO,G) (SNO,CNO)→G没 有非主属性对码的传递依赖， SC∈3NF； 有非主属性对码的传递依赖，故SC∈3NF；
⑵ 有没有用同一个表来介绍SQL的三大范式的例子
首先就得知道什么是sql的三大范式
1.什么是数据库三范式？分别是哪三范式？各有什么优缺点？
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是属性完全依赖于主键。
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。
问题分析
因此不满足第二范式的要求，会产生如下问题
数据冗余： 同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
更新异常：
1)若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
2)假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
删除异常 ： 假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。2.1.2 解决方案
把选课关系表SelectCourse改为如下三个表：学生：Student(学号，姓名, 年龄，性别，系别，系办地址、系办电话)；课程：Course(课程名称, 学分)；选课关系：SelectCourse(学号, 课程名称, 成绩)。2.2 第三范式（3NF）实例分析
接着看上面的学生表Student(学号，姓名, 年龄，性别，系别，系办地址、系办电话)，关键字为单一关键字"学号"，因为存在如下决定关系：
（学号）→ (姓名, 年龄，性别，系别，系办地址、系办电话)
但是还存在下面的决定关系
(学号) → (所在学院)→(学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况。 (数据的更新，删除异常这里就不分析了，可以参照2.1.1进行分析)
根据第三范式把学生关系表分为如下两个表就可以满足第三范式了：
学生：(学号, 姓名, 年龄, 性别，系别)；
系别：(系别, 系办地址、系办电话)。
总结
上面的数据库表就是符合I,II,III范式的，消除了数据冗余、更新异常、插入异常和删除异常。
希望对你有帮助哈
⑶ SQL server第一、第二、第三范式
一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值 都是不可再分的最小数据单位，则称R是第一范式的关系。例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码） 规范成为1NF有三种方法：
一是重复存储职工号和姓名。这样，关键字只能是电话号码。
二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性
三是职工号为关键字，但强制每条记录只能有一个电话号码。
以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。
第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。
例：选课关系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。 由以上条件，关键字为组合关键字（SNO，CNO）
在应用中使用以上关系模式有以下问题：
a.数据冗余，假设同一门课由40个学生选修，学分就 重复40次。
b.更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。
c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。
d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。
原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。
解决方法：分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系
⑷ sql中的范数是什么回事
3.4.1 第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范
式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中
不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的
属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为
一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中
的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显
示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而
言之，第一范式就是无重复的列。
3.4.2 第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）
必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以
被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如
图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，
因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在
仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出
来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上
一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关
键字。
3.4.3 第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求
一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，
其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2
的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入
员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会
有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。
所谓范式就是符合某一种级别的关系模式的集合。通过分解把属于低级范式的关系模式转换
为几个属于高级范式的关系模式的集合。这一过程称为规范化。
1、第一范式（1NF）：一个关系模式R 的所有属性都是不可分的基本数据项。
2、第二范式（2NF）：关系模式R 属于第一范式，且每个非主属性都完全函数依赖于
键码。
3、第三范式（3NF）：关系模式R 属于第一范式，且每个非主属性都不伟递领带于键
码。
4、BC 范式（BCNF）：关系模式R 属于第一范式，且每个属性都不传递依赖于键码
⑸ 数据库SQL，第二范式是不是完全函数依赖并且传递函数依赖
数据库SQL，第二范式是不是完全函数依赖并且传递函数依赖？
⑹ sql 新人 何谓依赖
对于初学者最好还是从字段之间的配比关系来理解依赖，凡是x n:1 y的则可看成y=f(x)也就是说y和x之间存在一个函数关系，进一步的说则可有两种说法：一种是x能推出y，一种是y函数依赖x。对于上题
学号n:1系名
系名n:1系大楼
结果是系大楼函数依赖系名，系名函数依赖学号，所以系大楼函数依赖学号，在关系代数中将复合函数又称为传递函数或传递依赖，所以系大楼传递依赖学号
在数据库中如果你真的这样建了表的话，一个系搬到另一栋系大楼的话，就要修改所有该系学生的信息了，这是很不科学的。
⑺ sql server 如何创建依赖关系，依赖关系是什么
依赖关系是两个表之间的约束，从表依赖主表，那从表有的数据主表必须有，就比如员工从表里有一个用户 他有姓名，有年龄....当中还有职位，这个职位里是数字和主表关联 如果他是1的话，主表里对应的员工就可以做到连表查询，如果主表里没有的话，那用户里的员工输入的1就会报错，主要是以约束他们的关系存在的
⑻ 什么是完全依赖
完全依赖，即完全函数依赖，设R为任一给定关系，X、Y为其属性集，若X → Y，且对X中的任何真子集X’ ，那么X’ ↛ Y 都成立，则称Y完全函数依赖于X。
Y函数依赖于X（X→Y），任何一个X的子集都能确定Y（完全函数依赖）f。
例：成绩完全依赖于（学号，课程号），X的部分子集确定Y（部分函数依赖）p。
例：课程名部分依赖于（学号，课程号），推论：如果X→Y，X是单个属性，则是完全函数依赖。
(8)sql什么是完全依赖扩展阅读：
完全函数依赖在数据库的运用：
根据Gartner的预计，全球非关系型数据库（NoSQL）在2020~2022预计保持在30%左右高速增长，远高于数据库整体市场。伴随着NoSQL和大数据技术的兴起和发展，在阿里云上直接开放提供服务也有1年多时间，并在去年的12月份全新发布X-Pack，将单一的HBase演进到一个完整的数据处理平台的能力。
HBase X-Pack的定位：HBase X-Pack是基于HBase及HBase生态构建的 低成本一站式数据处理平台；HBase X-Pack支持：HBase API(包括RestServerThriftServer)、关系Phoenix SQL、时序OpenTSDB、全文Solr、时空GeoMesa、图HGraph、分析Spark on HBase，是阿里云首个支持多模式的分布式数据库，且协议100%兼容开源协议；HBase X-Pack实现数据从处理、存储到分析全流程闭环，让客户用最低成本实现一站式数据处理。
⑼ SQL数据库三大范式
c
数据库范式1NF 2NF 3NF BCNF(实例）
设计范式（范式,数据库设计范式,数据库的设计范式）是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。关系数据库中的关系必须满足一定的要求，即满足不同的范式。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式（3NF）就行了。下面我们举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。
在创建一个数据库的过程中，范化是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。这样可能使数据库产生重复数据，从而导致创建多余的表。范化是在识别数据库中的数据元素、关系，以及定义所需的表和各表中的项目这些初始工作之后的一个细化的过程。
下面是范化的一个例子 Customer Item purchased Purchase price Thomas Shirt $40 Maria
Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25
如果上面这个表用于保存物品的价格，而你想要删除其中的一个顾客，这时你就必须同时删除一个价格。范化就是要解决这个问题，你可以将这个表化为两个表，一个用于存储每个顾客和他所买物品的信息，另一个用于存储每件产品和其价格的信息，这样对其中一个表做添加或删除操作就不会影响另一个表。
关系数据库的几种设计范式介绍
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）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。
⑽ SQL 请问SQL高手，系统中的这几个数据库都是做什么用的
数据：计算机中用来描述事物的记录
数据模型：是一种对客观事物抽象化的表现形式。数据模型应该真实、易于理解、便于实现
建模：对客观事物加以抽象，提取主要特征，归纳成一个简单清晰的轮廓，使复杂问题变得易于处理
数据模型三要素：数据结构、数据操作、完整性约束
数据结构描述静态特征，按数据结构可以把数据模型分为层次模型、网状模型、关系模型
数据操作描述动态特征，数据操作主要分为更新（插入、删除、修改）、检索两大类，统称增、删、改、查
完整性约束确保数据的正确性、有效性、相容性
数据库：简称DB(database)，是由数据库管理系统管理的数据的聚集
数据库管理系统:简称DBMS(DataBase Management System)是专门用于建立和管理数据库的一套软件，介于应用程序和操作系统之间。属于系统软件
数据库系统：简称DBS（DataBase System)。数据库、DBMS、应用程序和软件系统统称数据库系统
关系：关系就是一张二维表
关系模型：数据以关系的形式表示，就是以二维表的形式表示数据模型
属性：关系的标题栏中各列的名字
模式：关系的名称和关系的属性集
元组：二维表的所有行统称为元组，元组的各个分量对应于关系的各个属性。一个元组表示一个对象
域：关系的每个属性的取值范围
关系的实例：给定关系中元组的集合称为该关系的“实例”。一个给定的关系模式，可以有许多关系实例。
关系型数据库管理系统：简称RDBMS(Relationg DataBase Management System)，采用关系数据模型的数据库管理系统。
数据库系统的体系结构的三层结构和两层映象：从数据库管理的角度出发，数据库系统的体系可分三层，外模式、模式、内模式。两层映象是，外模式/模式映象、模式/内模式映象
外模式：又称用户模式，相当于SQL中的视图（VIEW)模式，是数据库用户可以看见和使用的局部数据的逻辑结构和特征描述，是与某应用有关的数据的逻辑表示
模式：分为概念模式、逻辑模式，是所有数据库用户的公共数据视图，是数据库中全部数据的逻辑结构和特征的描述，一个数据库只有一个模式
外模式/模式映象：把局部逻辑结构描述与全局逻辑结构描述联系起来。一个模式可以与多个外模式对应联系。例如，SQL SERVER中一个关系模式上可以建立多个满足不同用户要求的视图VIEW。这种映象可以保证数据与应用程序之间的逻辑独立性，即改变模式，不影响外模式，则与外模式相关的应用程序无序修改
内模式：由称为存储模式，是数据库物理结构和存储方式的描述，是数据在数据库内部的表示方式。一个数据库只有一个内模式。内模式描述记录的存储方式、索引的组织方式、数据是否压缩、是否加密等，不涉及硬件设备。
模式/内模式映象：把全局逻辑结构描述与物理结构描述联系起来。一个模式只有一个内模式。这种映象保证了数据与程序之间的物理独立性，当内模式修改时，由于模式未变，所以无需修改程序。
DBMS的体系结构（组成）：查询处理程序、存储管理程序、事务管理程序、客户/服务器程序体系结构
查询处理程序：负责查询处理，它的一个重要任务是“优化”查询。
事务管理程序：保证多个事务并发执行
存储管理程序：既管理磁盘上的数据文件又管理存放数据文件部分内容的内存数据缓冲区
客户/服务器程序体系结构：大多数DBMS程序采用这种程序体系结构，把整个DBMS程序系统划分为两部分，DBMS核心部分属于服务器程序，客户程序主要用于与用户相互配合并将查询或其他命令传送给服务器程序的查询接口。
数据库设计
数据库设计的步骤：需求分析、概念设计、逻辑设计、物理设计
需求分析和概念设计阶段的工作与具体数据库管理系统无关，这一阶段的工作独立于数据库管理系统
逻辑设计和物理设计阶段的共组与具体采用何种数据库管理系统相关。
需求分析阶段：应用领域的调查、定义信息与应用、定义操作任务、定义数据项、预测未来改变，结果产生相关文档
概念设计阶段：也称为建模
任务：数据库概念模式（模式）设计、事务设计
概念模式设计的工具：E/R图。对于面向对象的数据库则可采用面向对象定义语言ODL
E/R图：称为实体-联系模型
E/R图的组成：实体集（矩形）、属性（椭圆）、联系（菱形）
联系的类型：一对一、一对多、多对多。用线条和箭头表示不同的联系。箭头指向的一方代表“一”
键码属性的表示：下划线
联系中的角色：即一个实体集内部实体之间的联系
多向联系：多个实体集之间发生的一个联系
多向联系转化为双向联系的方法：将多向联系转换成实体集，然后在原来与之联系的实体集和新的实体集之间建立新的双向联系
E/R图中的子类的表示方法和继承：如果实体集B是实体集A的子类，则它们之间用一个标有isa的三角形和两根线条建立特殊的联系。三角形的尖端指向超类（父类），子类实体集上只需标出子类特有的属性，继承父类的所有属性。
ODL对象定义语言：是用面向对象的术语来说明数据库结构的一种推荐的标准语言，主要用途是书写面向对象数据库的设计
对象：是某种可研究，可观察的实体，例如：一个人、一门课程、一本书等等
类：具有相似特性的对象可以归为一类
ODL描述的三种特性：属性（Attribute)、联系（Relationship)、方法(Method)
ODL书写规则：
interface 类名1{
attribute 数据类型1 属性名1；
attribute 数据类型2 属性名2；
.
.
.
relationship [Set]<类名2> 联系名1
inverse 类名2::联系名2；
.
.
}
说明：
关键字interface、attribute、relationship、<set>、inverse
常用数据类型有string（字符串）、integer（整型）、float（浮点型）、enum（枚举型）
[]中的set为任选项，当类1与类2的联系是一对一时，不需要使用set，当类1与类2的联系是一对多时必须使用set
inverse表示在类2中联系名2所表示的联系与类1中联系名1所表示的联系是多对一的对应联系
ODL例一：用ODL描述制片公司与电影，假如制片公司部名称不重复。因为，一个制片公司可以制作多部影片，而一部影片只能由一个公司制作发行，所以制片公司与影片的关系是一对多的关系。
interface studio{
attribute string studioname;
attribute string address;
attribute string phone;
relationship set<movie> make
inverse movie::madeby;
}
interface movie{
attribute string movietitle;
attribute integer length;
attribute enum incolor ;
attribute integer year;
relationship set studio madeby
inverse studio::make;
}
ODL例二：用ODL描述学生与课程，一名学生可以选择多门课程来学习，一门课程可以被多名学生选修。
interface student{
attribute string sname;
attribute string address;
attribute enum gender ;
attribute integer age;
relationship set<course> choice
inverse course::choisedby;
}
interface course{
attribute string ctitle;
attribute integer credit;
relationship set<student> choisedby
inverse student::choice;
}
ODL例三：用ODL描述校长与学校的关系，一名校长只能管理一所学校，一所学校只能设一名校长。
interface chairman{
attribute string chname;
attribute enum gender ;
attribute integer age;
attribute string phone;
relationship set university manage
inverse university::leadby;
}
interface university{
attribute string unnmae;
attribute string addr;
relationship set chairman leadby
inverse chairman::manage;
}
ODL子类描述方法：自类继承父类的所有属性和联系。子类可以有自己的特殊属性和联系。子类中属性和联系的描述方法与上述例子相同。
interface 子类名:基类名
ODL子类描述例：硕士研究生类是学生的一个子类。每名硕士研究生有若干名导师，一名导师可以带多名硕士研究生。
interface student{
attribute string sname;
attribute string address;
attribute enum gender ;
attribute integer age;
}
interface master:student{
attribute string special;
relationship set<advisor> direct
inverse advisor::directedby;
}
interface advisor{
attribute string name;
attribute string address;
}
逻辑设计阶段：把概念设计阶段产生的数据库概念模式变换为数据库逻辑模式。数据库逻辑模式依赖于逻辑数据模型和数据库管理系统。目前做流行的数据库管理系统都是关系型逻辑数据模型。所以，本教程知讨论如何把概念模式转变为关系模型
逻辑设计阶段的步骤：
1.概念模式转变为关系模型
2.对关系模型进行规范化和优化
3.适应DBMS限制条件的修改
4.对性能、存储空间等的优化
1.概念模式转变为关系模型
E/R图转变为关系模型的方法：
1.一个实体集转变为一个关系模式，这个关系模式包含实体集所有的简单属性和复合属性的简单子属性。实体集的名称可以用作为关系模式的名称，用下划线来表示关系的键码
2.一个联系转变为一个关系模式，一般情况下用联系名作为关系名，用联系的实体集的键码和联系本身的属性作为此关系模式的属性集。
E/R图转变为关系模型实例：
实例一：一个班级只能有一个班长，而且必须有一个班长，E/R图如下：
学生与班级的联系是一对一的联系(1:1)。学生实体集的键码是学号。班级实体集的键码是班号。这个E/R图可以转变为如下的关系模型
学生（学号，姓名，性别，出生日期）
班级（班号，名称，地点）
班长（学号，班号，注册）
联系反映的是具有某学号的学生担任具有某班号班级的班长。这种转变方法是常用的方法。
如果想减少查询时使用连接操作的次数，提高查询效率，以上E/R图也可以转变为如下关系模型
学生（学号，姓名，性别，出生日期，班号）
班级（班号，名称，地点）
学生关系模式中的“班号”是外键码。这种关系模式中，由于学生关系中记录了所有学生的学号，但不是每个学生都担任班长（按教科书上的术语叫做不是全参与），因此不是每个元组的班号属性都有数据，即应该允许班号为空。否则，学生实体集必须是全参与，即每个学生都是班长。
实例二：一个影片公司可以制作多部影片，但是一部影片只能归一个制片公司所有。假如公司不重名，影片也不重名，则公司名称是制片公司实体集的键码，影片名是影片实体集的键码。
影片公司与影片的联系是1对多的联系（1：N)。这个E/R图可以转变为以下关系模型
影片公司（公司名称，地点）
影片（影片名，片长）
制作（公司名称，影片名）
同样，假如影片公司是全参与，即每个影片公司至少制作了一部电影，则可以转变为以下关系模型
影片公司（公司名称，地点，影片名）
影片（影片名，片长）
其中，影片公司关系中的影片名是外键码
实例三：学生与课程之间的联系是“选修”。一个学生可以选多门课程，一门课程可以被多名学生选修，所以它们之间的“选修”联系是多对多(N:M)
上述E/R图可以转变为以下关系模型
学生（学号，姓名）
课程（课程号，课程名）
选修（学号，课程号，成绩）
选修关系中的学号和课程号是外键码
2.对关系模型进行规范化和优化
为什麽要把关系模型规范化：为了有效地消除关系中存在的数据冗余和更新异常等现象
基本概念
函数依赖：如果关系R的两个元组在属性A1，A2，...An上一致，则它们的另一个属性B上也一致，那末，我们就说在关系R中属性B函数地依赖于属性A1，A2，...An或者说属性A1，A2，...An函数决定属性B。
关系的键码：
如果一个或多个属性的集合满足如下条件，则称该集合为关系R的键码（key):
1.这些属性函数决定该关系的所有其它属性。
2.的任何真子集都不能函数决定R的所有其它属性。
关系的超键码：包含键码的属性集称为超键码，是“键码的超集”的简称
函数依赖规则：分解/合并规则、传递规则、平凡依赖规则
平凡依赖：对于函数依赖A1，A2，...An->B，如果B是A中的某一个，我们称这种依赖是平凡依赖
非平凡依赖：对于函数依赖A1，A2，...An->B，如后B中至少有一个不在A中，我们称这种依赖是非平凡依赖
完全非平凡依赖：对于函数依赖A1，A2，...An->B，B中没有一个在A中，我们称这种依赖是完全非平凡依赖
主属性：键码所在的属性
非主属性：键码以外的属性
封闭集（闭包）对于给定的函数依赖集S，属性集A函数决定的属性集合就是属性集A在依赖集S下的封闭集
范式就是符合某一种级别的关系模式的集合。
规范化通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合，这一过程称为规范化
1范式（1NF)，如果一个关系模式R的所有属性都是不可分割的基本数据项，则这个关系属于1NF
2范式(2NF),若关系模式R属于1NF，且每个非主属性都完全依赖于键码，则R属于2NF
3范式（3NF),若关系模式R属于1NF，且每个非主属性都不传递依赖于键码，则R属于3NF
BC范式（BCNF),若关系模式属于1NF，且R的每个非平凡依赖的决定因素都包含键码，则R属于BCNF
规范化分解原则：无损连接、保持依赖
无损连接：当对关系模式R进行分解时，R的元组将分别在相应属性集进行投影而产生新的关系，如果对新的关系进行自然连接得到的元组的集合与原关系完全一致，则称为无损连接
保持依赖：如果分解后的总的函数依赖集与原函数依赖集保持一致，则称为保持依赖。
模式分解的两个规则：公共属性共享、相关属性合一
公共属性共享：保留公共属性，进行自然连接是分解后的模式实现无损连接的必要条件
相关属性合一：把以函数依赖的形式联系在一起的相关属性放在一个模式中，从而使原有的函数依赖得以保持，这是分解后的模式实现保持依赖的充分条件
模式分解的三种方法
一、部分依赖归子集；完全依赖随键码——用于建立2NF
例：关系R(A,B,C,D,E,F,G)上存在函数依赖,A->BCD,E->F,AE->G,AE->BCD,AE->F
分析以上依赖可以看出，AE是键码（AE->BCD)。因为AE是键码，A是主属性，A->BCD，所以BCD是部分依赖于AE
根据部分依赖归子集的方法，因为A是AE的真子集，所以A与BCD归在一起构成一个关系模式。R1(A,B,C,D)
同理对于AE->F，有E->F所以AE->F是部分依赖，非主属性F所依赖的真子集是E，所以E和F可以归在一个关系模式中R2(E,F)
AE->G是完全函数依赖，完全依赖随键码，所以AEG归在一个关系模式中R3(A,E,G)
因此R(A,B,C,D,E,F,G)可以分解为符合2NF的关系模式如下:
R1(A,B,C,D)
R2(E,F)
R3(A,E,G)
二、基本依赖为基础，中间属性做桥梁——用于建立3NF
例：关系R(A,B,C,D,E)上存在函数依赖,AB->C,C->D,D->E
显然中间桥梁是C->D，他构成了传递依赖链，因此，R可以分解为R1(A,B,C),R2(C,D)。分解后在R1，R2中都不存在传递依赖。
三、找违例自成一体，舍其右全集归一；若发现仍有违例，再回首如法炮制——用于建立BCNF
BCNF违例：违背BC范式的函数依赖称为BC范式违例
例：关系R(A,B,C,D,E)的键码是AB,有函数依赖AB->CDE,ABC->E,C->D
分析上述三个函数依赖可以看出，C->D是BCNF违例。因为它的决定因素不包含键码。我们作如下分解
违例自成一体，即CD构成一个关系模式R1(C,D)
舍其右全集归一，即从R的属性中取掉C->D的右边的属性D，其左边的属性C与其他所有属性构成一个新的关系R2(A,B,C,E)
新的关系模式如下：
R1(C,D)
R2(A,B,C,E)
注意：以BCNF违例为基础进行模式分解，最终得到的属于BCNF的关系模式都能实现无损连接，但未必能保持函数依赖
逻辑设计例一：假如有关系模式R(A,B,C,D)和函数依赖集S=。
（1）找出所有BCNF违例。
（2）如果该关系模式不是BCNF，则将它分解为BCNF
（3）找出所有的违背3NF的依赖
（4）如果该关系不是3NF，则将它分解为3NF
步骤一：找出R在S上的所有非平凡依赖，首先计算封闭集
单属性封闭集：A+=A,B+=BCD,C+=C,D+=D
双属性封闭集：AB+=ABCD,AC+=AC,AD+=AD,BC+=BCD,BD+=BCD,CD+=CD
三属性封闭集：ABC+=ABCD,ABD+=ABCD,BCD+=BCD,ACD+=ACD
四属性封闭集：ABCD+=ABCD
步骤二：根据计算所得的封闭集，找出键码和超键码
键码：AB
超键码：ABC,ABD,ABCD
步骤三：找出所有的非平凡函数依赖
B->C,B->D,AB->C,AB->D,BC->D,BD->C,ABC->D,ABD->C
其中，AB->C,AB->D,ABC->D,ABD->C不是BCNF违例，因为前两个依赖的决定因素本身就是键码，而后两个依赖的决定因素包含键码。所以，B->C,B->D,BC->D,BD->C是BCNF违例，因为它们的决定因素都不包含键码。实际上可以看出R不是2NF，因为存在部分函数依赖：ABC->D,ABD->C,AB->C,AB->D,B->C,B->D
步骤四：进行BCNF规范。BCNF违例自成一体。从以上BCNF违例中选择B->C自成一体
R1(B,C)
舍其右全集归一，即舍去B->C的右边属性C，所以得到
R2(A,B,D)
但是在R2中还存在BCNF违例B->D，因此B->D自成一体，得到R21(B,D),舍其右全集归一得到R22(A,B)
最后得到的关系模式是：R1(B,C),R21(B,D),R22(A,B)
通过关系模式分解，把一个非2NF的关系模式归范成一个BCNF。代价是，在实际操作中增加了连接操作。
（3）B->C,B->D，B不是键码也不是超键码，而C,D都是键码以外的属性，即是非主属性。所以R不是3NF。
逻辑设计例二：有关系R(A,B,C,D)和函数依赖集S=
（1）找出所有BCNF违例。
（2）如果该关系模式不是BCNF，则将它分解为BCNF
（3）找出所有的违背3NF的依赖
（4）如果该关系不是3NF，则将它分解为3NF
步骤一：找出R在S上的所有非平凡依赖，首先计算封闭集
单属性封闭集：A+=ABCD,B+=ABCD,C+=ABCD,D+=ABCD
双属性封闭集：AB+=ABCD,AC+=ABCD,AD+=ABCD,BC+=ABCD,BD+=ABCD,CD+=ABCD
三属性封闭集：ABC+=ABCD,ABD+=ABCD,BCD+=ABCD,ACD+=ABCD
四属性封闭集：ABCD+=ABCD
步骤二：找出所有非平凡函数依赖
A->B,A->C,A->D,B->A,B->C,B->D,C->A,C->B,C->D,D->A,D->B,D->C
AB->C,AB->D,AC->B,AC->D,AD->B,AD->C,BC->A,BC->D,BD->A,BD->C,CD->A,CD->B
ABC->D,ABD->C,BCD->A,ACD->B
步骤三：找出键码和超键码
键码：A,B,C,D
超键码：AB,AC,AD,BC,BD,CD,ABC,ABD,BCD,ACD,ABCD
根据以上结果分析，R是3NF也是BCNF
3NF要求不存在每个非主属性对于键码的部分依赖或传递依赖
练习：对于
1.R(A,B,C,D)和函数依赖集S=
2.R(A,B,C,D,E)和函数依赖集S=
3.R(A,B,C,D,E)和函数依赖集S=
（1）找出所有BCNF违例。
（2）如果该关系模式不是BCNF，则将它分解为BCNF
物理设计阶段：任务是在数据库逻辑设计的基础上，为每个关系模式选择合适的存储结构和存取路径
物理设计阶段步骤：
（1）分析影响数据库物理设计的因素；
（2）为关系模?
请参考