数据库设计扫盲篇

数据库设计
需求分析的要点:
1、数据是什么？
2、数据有哪些属性？
3、数据和属性各自的特点有哪些？
逻辑分析:
使用ER图对数据库进行逻辑建模。
物理设计:
根据数据库自身的特点把逻辑设计转换为物理设计。
维护优化：
1、新的需求进行建表
2、索引优化
3、大表拆分


1、实体及实体之间的关系（一对一，一对多，多对多）。
2、实体所包含的属性有什么。
3、那些属性或属性的组合可以唯一标识一个实体。




分析需求时，须得到属性，可选唯一标识属性，存储特点。


逻辑设计：
1、将需求转化为数据库的逻辑模型
2、通过ER图的型式对逻辑模型进行展示
3、同所选用的具体的DBMS系统无关


名词解释：
关系：一个关系对应通常所说的一张表。
元组：表中的一行即为一个元组。
属性：表中的一列即为一个属性；每一个属性都有一个名称，称为属性名。
候选码：表中的某个属性组，它可以唯一确定一个元组（外键）。
主码：一个关系有多个候选码，选定其中一个为主码。
域：属性的取值范围。
分量：元组中的一个属性值。


ER图例说明：
矩形：表示实体集，矩形内写实体集的名字。
菱形：表示联系集。
椭圆：表示实体的属性。
线段：将属性连接到实体集，或将实体集连接到联系集。
实体集的名字加了下划线就是主键。


数据冗余
是指相同的数据在多个地方存在，或者说表中的，某个列可以由其它列计算得到，这样就说表中


存在着数据冗余。








第一范式：
定义：数据库中的表中的所有的字段都是单一属性的，不可再分的。
要求数据库中的表都是二维表。


第二范式：
定义：数据库的表中不存在非关键字段对任一候选关键字段的部分函数依赖。
所有单关键字段的表都符合第二范式。


第三范式：
定义：如果数据表中不存在非关键字段，对任意候选关键字段的传递函数依赖则符合第三范式。


BC范式：
定义：数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BC范式。也就


是说如果复合关键字，则复合关键字之间也不能存在函数依赖关系。




物理设计：
1、选择合适的数据库管理系统。
2、定义数据库、表及字段的命名规范。
3、根据所选的DBMS系统选择合适的字段类型。
4、反范式话设计。




所有对象命名应该遵循下述原则：


1、可读性原则
使用大写和小写来格式化的库对象名字以获得良好的可读性。


2、表意性原则
对象的名字应该能够描述它所标识的对象。


3、长名原则
尽可能少使用或者不使用缩写。




字段类型的选择原则
   列的数据类型一方面影响数据存储空间的开销，另一个方面也会影响数据查询性能。当一个 


列可以选择多种数据类型时，应该优先考虑数字类型，其次是日期或二进制类型，最后是字符类


型。对于相同级别的数据类型，应该优先选择占用空间小的数据类型。




1、在对数据进行比较（查询条件、JOIN条件及排序）操作时：
同样的数据、字符处理往往比数字处理慢。


2、在数据库中、数据处理以页为单位，列的长度越小、利于性能提升。


如何选择主键


1、区分业务主键和数据库主键
业务主键用于标识业务数据，进行表与表之间的关联;
数据库主键为了优化数据存储（Innodb会生成6个字节的隐含主键）


2、根据数据库的类型，考虑主键是否要顺序增长
有些数据库的是按主键的顺序逻辑存储的。


3、主键的字段类型所占空间要尽可能的小
对于使用聚集索引方式存储的表，每个索引后都会附加主键信息。


避免使用外键约束
1、降低数据导入的效率。
2、增加维护成本。
3、虽然不建议使用外键约束，但是相关联的列上一定要建立索引。


避免使用触发器
1、降低数据导入的效率。
2、可能会出现意想不到的数据异常。
3、使业务逻辑变得复杂。


关于预留字段
1、无法准确的知道预留字段的类型。
2、无法准确的知道预留字段中所存储的内容。
3、后期维护预留字段所要的成本，同增加一个字段所需要的成本是相同的。
4、严禁使用预留字段。


反范式化是针对范式化而言的，在前面介绍了数据库设计的第三范式，所谓的反范式化就是为了


性能和读取效率的考虑而适当的对第三范式的要求进行违反，而允许存在少量的数据冗余。


为什么反范式化：
1、减少表的关联数量
2、增加数据的读取效率
3、反范式化一定要适度