关于数据库范式及关系的总结

 

关于数据库范式及关系的总结

PowerDesigner的使用：

1 创建概念模型，首先要找出实体，然后再确定实体之间的关系
2 生成报告、交给负责人认可
3 生成物理模型
4 建立数据库连接
5 导入数据库

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
数据建模技术：

数据模型：数据库系统中关于数据和联系的逻辑组织的形式表示。
        层次模型、网状模型和关系模型三种，现在应用最广泛的是关系模型。
关系模型与面向对象思想不一致，因此有了ORM来解决表和对象之间的关系。

数据库模式就是数据库结构，确定数据库模式是数据库建模的最重要任务
模式分为逻辑模式、外模式和内模式，实际上可以分别对应到表、视图和索引
模式在英文中是schema

模式：也叫作逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有
用户的公共数据视图。

外模式：是数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图
   是与某应用有关的数据的逻辑表示。

内模式：是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。

外模式也叫作子模式或者用户模式，内模式也叫作存储模式。

数据库建模就是确定数据库结构的过程，也就是定义数据库模式的过程。

将现实世界中的事物以及他们之间的联系抽象出来，并且以某种组织方式存储在数据库中。
这种组织方式就是数据库结构。

现实世界中的事物在数据库设计中称为实体，而事物与事物之间的联系叫做关系。

网上购物，业务流程是什么？有哪些事物呢？哪些事物需要持久化？哪些不需要？

数据库建模方法：1 ER图 2 对象定义语言（ODL：Object Defination Language）
矩形表示实体，椭圆表示属性，菱形表示关系

先有一个思路，然后画出ER图，确定好关系，然后导入关系型数据库中。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
数据库范式：
一范式：数据库表中不存在重复字段，并且字段不可分割
二范式：不存在非主键字段对任一主键字段的部分依赖关系（用来约束联合主键）
   一个爸爸和一个妈妈决定了一个孩子；一个妈妈决定了一个孩子就是不符合第二范式
   假如必须有两个主键但是你只设了一个主键的话，那么不符合第二范式
三范式：不存在非主键对任一主键的传递依赖关系。
   由a决定b，b决定c，但是没有a直接去决定c，就是传递依赖   
BC范式：
   任何字段都不存在传递函数依赖，即主键对主键没有传递依赖。

---------------------------------------------------------------------

第一范式就不说了，只要是个合法的表都满足第一范式，但是假如有个地址的字段，里面包含
国、省份、市、地区的话，可以通过设置外键，或是分解字段的方法来解决。

 

二范式主要规范联合主键情况：要求非主键字段不能由符合主键的一个完全决定，而必须由符合主键共同决定！
       只要没有使用联合主键，肯定不会出现违反第二范式的情况！
例：学生选课表的设计应该如何实现？
假设选课关系表为学号、姓名、年龄、课程名称、乘积、学分。
那么这个表里面的主键应该为学号和课程名称联合作为主键，这是毫无疑问的，但是不符合第二范式：因为姓名
可以由学号完全决定，和课程名称没有任何关系，也就是说姓名这个非主键字段对这个联合主键有部分依赖关系存在。
同理，学分完全由课程名称来决定，也是部分依赖的。
成绩是不存在部分依赖的，是由学号和课程名称共同决定的

所以这个表是不满足第二范式的，危害如下：
1 数据冗余
2 更新异常，若调整了课程的学分，那么每条记录都要调整
3 删除异常，假如要删一个学生，那么他选的课也跟着丢了，要是这门课没有别人选的话，该课程的信息就永远的丢失了
4 插入异常，假如新来了一门课程，但是没有人选，试问这怎么插入呢？没办法弄……
  
解决不满足第二范式情况的办法是分解主键
建立学生表（学号，姓名，年龄）课程表（课程名称、学分）和选课关系（学号，课程名称，成绩）

一般认为，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字

满足第二范式的设计肯定满足第一范式的要求！

 

下面说说第三范式：
要求不存在非关键字段对任一候选关键字段的传递函数依赖关系，其实，就是不能出现非主键字段决定其他非主键字段！

关键字段决定了非关键字段x，而x又决定了另外一个非关键字段y，这就不满足第三范式！

假设须生关系表（学号，姓名，年龄，所在班级，教室编号，班级人数）
主键是学号

学号确定了其余的字段，但是呢，所在班级直接决定了教室编号和班级人数，这就是典型的传递依赖，不满足第三范式

解决方法：
分解实体：学生（学号，姓名，年龄，所在班级）
   学院（班级，地点，人数）
   两者之间用主外键关系联系起来，二者是一对多的关系。

 

BC范式：主键也不可以有传递依赖关系。
例：
假如一个表（班号，课程号，老师号，课程时间）
那么课程号和班号唯一决定是课程时间
而且课程号和老师号也可以决定课程时间
但是呢，班号决定了老师号，这就是说主键存在传递依赖。

解决方法：分解关系
班级号，课程号，课程时间
班级号，老师号
建立成上面两个关系表就ok了

总的来说，各个范式都是在尽力去分解，不把数据都存在一个表中。
应该尽可能的去满足范式的要求！
在性能的要求下，也并非一定要严格遵从范式要求，以适当的数据冗余来提升性能也是一个很好的选择。

怎么在数据库中的表中表示关系：
关系种类：
一对一，多对多，一对多，多对一

怎么在数据库中的表里面表示上面这四种关系？？
可以通过外键方式；还可以通过主键对应方式，比如学生和电脑的一对一的关系可以通过
让学生的主键和对应电脑的主键一致来做到，其中必然有一个主键是主动变化的，而另外一个
主键是跟随这这个主键来变化

还有可以通过再建立一个关系表的方式，这个关系表中就有两个主键，一个是电脑，一个是学生
将他们两个关联起来，在学生表和电脑表中都不考虑关系的问题，全部让关系表去考虑

一对多或是多对一的关系里面，用多的那一端来存放外键，还可以用关系表方式。

多对多的关系只能用关系表来解决了，没别的办法了。

因此一对一有三种方式：主键方式，外键方式和关系表方式
一对多有两种方式：外键和关系表方式
多对多只有关系表方式

hibernate中强烈建议使用关系表，这样把对象和关系分离开来，好处理。