CS3402 Lecture 5

ER模型与关系模型

• 都是对数据的一种模型
• ER模型有很多的概念

　　　　实体Entities，关系relations，属性attributes等等

　　　　很好的满足了应用的需求

　　　　不适合计算机处理的需求

• 关系模型

　　　　只有一个概念：关系relation

　　　　物理世界是由一些表的集合组成的

　　　　很好地满足了计算机对数据的处理需求

数据建模完成之后, 可以把ER图转换成数据中的表 (关系建模)
            1.实体的名字转换为表的名字
            2.实体的属性转换为表中的列
            3.具有唯一特点的属性设置为表中的主键
            4.根据实体之间的关系设置为表中某列为外键列(主外键关联)
            注意:第四步主要是:实体关系--->表关系
      

ER模型到关系表的映射

http://www.cnblogs.com/muchen/p/5265305.html

函数依赖(functional dependency)

        函数依赖，是指关系中每行记录的某一列(或几列)的值唯一决定该条记录另一列的值。总的来说，有以下几种函数依赖：

        1. 平凡函数依赖(trivial functional dependency)

        是指一个或多个属性确定它自己，或者它的子集. 这种依赖在规范化中不会被用到.

        2. 增广函数依赖(augmented functional dependency)

        是指某个依赖式为真，则依赖式左侧，或者两侧同时增加某语句形成的一种依赖关系. 这种依赖在规范化中不会被用到。

        3. 等价函数依赖(equivalent functional dependency)

        这种依赖关系是一对对的。比如若A->B和B->A都为真，那么A能推出来的，B同样也能推出来，因此A->B和B->A就被称作等价函数依赖。这种依赖只需保留一组依赖关系即可，但它不属于规范化的范畴。

        4. 部分函数依赖(partial functional dependency)

        是指关系的一列函数依赖于组合主码的一部分。显然这种依赖只有组合主码才存在。这种依赖关系属于规范化范畴。

        5. 完全函数依赖(full key functional dependency)

        是指复合主码函数确定关系中的其他列，并且复合主码的任意部分不能单独确定其他列。这个概念和上面的部分函数依赖显然是对立的。这种依赖关系属于规范化范畴。

        6. 传递函数依赖(transitive functional dependency)

        是指非码列函数确定关系中的其他非码列。这种依赖关系属于规范化范畴。

        这六种函数依赖中只有后面三种和规范化设计有关。前面三种则因为对改进冗余信息并没有帮助，不纳入规范化过程中。

　　设计关系数据库时，遵从不同的规范要求，才能设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。一个关系是否满足某种范式通常要看它是否不包含某个函数依赖。
        目前关系数据库有六种范式：
        第一范式(1NF)
        第二范式(2NF)
        第三范式(3NF)
        巴斯-科德范式(BCNF)
        第四范式(4NF)
        第五范式(5NF，又称完美范式)
        注:满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF)，其余范式以次类推。一般说来，数据库只需满足第三范式(3NF)就行了           
    第一范式:
        一个表中, 每个列里面的值是不能再分割的. 即一个表中每一行都是唯一, 并且任何行都没有包含多个值的列，则它满足1NF.
        例如:我们设计的表中有一个列是:爱好
        这个列的值可能会是这样:足球篮球乒乓球
        但是这值是可以再分割的:足球、篮球、乒乓球
        所以这种设计是不满足第一范式
    第二范式:
        第二范式是在满足第一范式的基础上
        表中的非主键列都必须依赖于主键列(不包含部分函数依赖)
        例如:
        订单表: 订单编号 是主键
        订单编号  订单名称   订单日期  订单中产品的生产地
        这几个非主键列中,产品生产地是不依赖于订单编号的,所以这种设计是不满足第二范式
    第三范式:
        第三范式是在满足第二范式的基础上
        表中的非主键列都必须直接依赖于主键列, 而不能间接的依赖. (不包含传递函数依赖)
        (不能产生依赖传递)
        例如:
        订单表:   订单编号 是主键
        订单编号  订单名称  顾客编号  顾客姓名

        顾客编号依赖于订单编号,顾客姓名依赖于顾客编号,从而顾客姓名间接的依赖于订单编号,那么这里产生了依赖传递,所以这个设计是不满足第三范式的   

了解主键和外键
        主键:
        1.能做主键的列必须要满足非空唯一的特点
        2.只要满足非空唯一的任何列都可以做主键
        3.可以让表中一个有意义的列做主键,比如说学号,它既表示学生学号又作为表中的主键,因为这个列满足非空唯一的条件
        4.也可以找一个没有意义的列做主键,就是用来唯一标识一行记录的

        5.我们可以让多个列联合在一起做表中的主键,那么它就是联合主键,要求这几个列的值联合在一起是非空唯一的   

如下图所示，创建联合主键数据库自动将其列设置为not null：

create table t_csdn(id number,name varchar2(20),primary key(id,name))  

        外键:
        1.表中的某一个列声明为外键列,一般这个外键列的值都会引用于另外一张表的主键列的值(有唯一约束的列就可以,不一定非要引用主键列)
        2.另外一张表的主键列中出现过的值都可以在外键列中使用,没有出现过的值,都不能使用
        3.外键列值也可以为空的,前提是这个外键列在表中不做主键,因为我们也可以把表中的外键列当做主键来使用(只有满足非空唯一的要求就可以)
        4.如果把B表中的联合主键的值引用到A表中做外键,因为是两个列在B表中做联合主键,那么A表引用过来的时候也要把俩个列的值都引用过来,那么它们在A表中就会作为一个联合外键出现

如下图所示，引用上面所示的联合主键约束：