ER建模----总结

其实、在工作中，数据库在后台这边全部设计好之后，前台就简单的多了！
而且，用有些用工具可以帮助完成前台的实现，但是只有数据库设计这一块是无法用工具帮助完成的！可见数据库在设计中是多么的重要！

一、数据库分析的前提条件

1.掌握关系型数据库理论：
关系DB = 实体 + 关系 = PK + FK
关系 = 一对一（11） + 一对多（1M,11）+多对多(MM,MM)


多对多一般要转换为两个一对多，通过中间表
为啥要用中间表呢？
其实是为了更加方便的增加属性！但是不能再PDM中直接修改增加属性和字段
！ 一般设计是在CDM中就必须要完成！（特殊情况例外）


2.数据库设计的3范式

1NF ： 不能将多个信息放入到一个字段中去（列不可再分），每个表都必须要有主键
（每一行都必须不同）。
2NF ： 每个表都必须要有他的自己的固有属性（非主键列必须要依赖主键列）
例如：找学生，只能找姓名、年龄等信息！而不能找班级信息
3NF ： 非主键列之间不相互依赖，而是相互独立的！例如：找员工实体，但是
他的出生日期和年龄不要设计在一个表中。


============================================================================================================================================

3、熟悉PD建模方法

说说关于DB设计的一些概念，所谓DB设计就是在软件工程中，通过需求分析来获取信息，然后抽象出一个虚拟的设计图，把整个工程中的数据实体和关系从宏观的角度描述出来，做到一个整体的把握，是建立实际数据库的基础和前提。

DB设计的基本步骤是先设计ER图（即概念数据模型，又称CDM），
CDM设计完之后再转换为物理数据模型（PDM），从CDM向PDM转换的时候，其实是CDM针对于哪一个RDBMS来进行转换的。例如，把一个CDM可以转换成相应的SQL物理数据模型，也可以将其转换成与ORACLE相对应的PDM。到PDM的阶段的时候其实已经产生了相应的实际数据库建表语句了，这个时候即可以用来进行程序开发。

在整个DB设计中其实我们需要做的只是完成2个事情：第一个是找实体，第二个是找关系。这两件事情才是DB设计的关键与核心，只有完善好这两项任务才能够设计出良好的RDBMS。

我们先从找实体来说起，从这一点上来看，我们可以很容易的联想到面向对象这种思想，在DB中其实一个表对应的是一个实体，其实就是一个类，而表中的每一行则对应了一个对象，在面向对象程序设计中，我们的目标其实就是要做好封装，简化代码，提高代码性能，其实从另外一个角度来说，也就是让我们所定义的类更新纯粹，降低与其他类（其实也就是对象与对象之间）之间的耦合性，


从设计CDM上来看，找实体的工作其实也类似如此，如果找到的实体能够更加独立，与其他实体之间有明显的区别，设计的效果将会是更加完美，因为在DB设计中，如果一个实体本应该可以分为两个实体进行处理的时候，却只当做了一个实体进行处理，那么则会造成很危险的后果，比如说在数据库中进行增加数据和删除数据时会产生异常情况，如果将实体分的更加纯粹，那么将会有效的避免这种情况的发生，另外一个方面，通常在这种情况下会出现数据冗余的现象，这种现象是我们要在DB设计中所高度重视的，一定要坚决的避免这种现象的发生。
下面看一个例子，来说说如果找到的实体没有尽可能的纯粹会产生的一些异常现象：


学号 姓名 性别 年龄 班级 班级楼层
1 张三 男 20 二班 一楼
2 张三 男 20 一班 二楼

这个是一个学生的信息表，上面有学号，姓名，性别，年龄，班级5个字段，
这个表似乎一看没有什么错误之处，但是却隐藏着巨大的弊端，假如，这个表中我们要删除关于学号为1的这个学生，但是并不想删除班级的信息，这个时候我们要怎么做呢，显然我们是做不到的，我们使用delete语句进行删除记录时只能针对一行记录进行删除，不能够删除一行的部分记录，这就产生了一种删除时造成的异常。另外一种情况，假如现在我们要增加一条记录，
如下表所示：


学号 姓名 性别 年龄 班级 班级楼层
1 张三 男 20 二班 一楼
2 张三 男 20 一班 二楼
3 李四 男 21 2班 一楼


这个时候我们来看一下，我们增加的学生号为3的一条记录，在字段班级处，我们输入的是记录二是数字2，我们想表达的意思其实是二班，但是却在输入记录的时候用阿拉伯数字表示二，用人类的思维来理解，这两个班所表达的意思是完全一致的，但是交给计算机处理的时候这2个班将会是两个完全不同的班级，这种情况也会引发出一种异常，增加异常。


出现上述两种情况的原因其实就是把多个实体放在了一个实体之中，没有完完全全的找到纯粹的实体，所以在DB设计的第一步找实体的时候我们应该努力找到尽量纯粹的实体，只有这样才能设计出完善的DBMS，之后再进行设计的下一个步骤。


在找完实体之后我们要做的是找关系，其实就我个人而言，DB设计中最复杂的部分也就是此处了，RDBMS之中关系是一个非常重要的概念，如何才能真正的理解它，一是要读懂需求，二则是要理解RDBMS之中非常重要的概念，一对一，一对多，多对多的三种关系模式，这
里就不详细叙述了，只有对这三种模式有深刻的理解才能够在DB设计中设计出良好的关系图。


另外一个方面，关系其实是非常复杂的，特别在对于大型项目设计的时候，实体的数量会非常的多，关系也会错综复杂，对RDBMS中三种关系深刻的理解将会在DB设计中起到举足轻重的作用。


在关系型数据库世界之中，其实就是众多的实体加上关系产生的一个虚拟的世界，实体的标志是主键，而关系的标识则是外键，从这个角度来说，其实关系型数据库就满足这个公式： 关系型数据库 = 外键 + 主键


现在再来详细讲讲范式，范式是什么呢，它是数据库表的一种规范，为什么EXCEL的表是表，数据库中的表也是表，他们不一样呢，正是因为数据库中的表满足范式。
范式一共有5种，但是其中我们只用到常见的3种，另外2种不必去掌握。

第一NF：
 表必须具有主键列
 不能让多个信息放到一个字段之中
 每行的属性（字段）必须相同
在第一范式中，我想说的是，将多个信息放入到一个字段之中，这个并不能完全的去遵守它，只能说在通常的情况下我们要按照范式去做，因为有时候在需求的驱动下，我们有必要把多个信息放入到一个字段之中。


第二NF:
 表中要有主键列和非主键列，非主键列必须依赖与主键列
 表中必须要有实体加关系的结构
这里说的非主键列不包含关系这种字段，比如说在刚才提及到的表中，班级这个字段，它是另外一个实体主键，是做为外键加入到学生表之中的，它是属于关系的字段，而不是属于非PK字段，这个则是第二范式的一个重点


第三NF：
 非PK字段之间是关系独立的
这个范式我想说明的是有时候可以不遵循第三范式，因为有时候我们没有必要做到非PK字段之间的关系是完全独立的，但是第一NF和第二NF是我们必须所遵守的。


关于范式其实就是一个规范，如果说当我们做为一些查询必须用到的表，有可能违背了三个范式，但是这样会提高我们查询的效率，这个时候我们也可以打破范式的约束，具体情况具体分析，因为在RDBMS之中，任何东西都是非常灵活的。


数据库是程序设计的基础，就像整个软件工程是一个座高楼大厦，数据库则是地基，数据库设计的好坏，直接影响到整座大厦今后的结构，DB设计是如此重要，我们必须深入了解其中的奥秘，才能在今后的IT生涯当中发现更多宝贵的财富。