数据库建模与设计

数据库设计步骤：

需求分析：数据流图、数据字典

概念结构设计

逻辑结构设计：https://baike.baidu.com/item/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%9A%84%E9%80%BB%E8%BE%91%E7%BB%93%E6%9E%84%E8%AE%BE%E8%AE%A1/5719552?fr=aladdin

物理结构设计

在进行数据库逻辑结构设计（对于关系型数据库就是设计关系模式）的关系模式设计的时候，可能会存在数据冗余过大，插入异常，删除异常，修改异常的问题，这是修改关系模式，使之满足关系范式，可以避免这些问题。

范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。实际上你可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。

“关系模式”和“关系”的区别，类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例，你可以把”关系”理解为一张带数据的表，而“关系模式”是这张数据表的表结构。

函数依赖：
我们可以这么理解（但并不是特别严格的定义）：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。

候选码：R<U,F>中，U完全依赖于K，则称K为候选码，K的任一个真子集都不是候选码，包含候选码的叫超码，候选码也称为码。

主属性：包含在任何一个码中的属性称为主属性。

主码：候选码中的一个。

符合1NF的关系中的每个属性都不可再分。

2NF在1NF的基础之上，消除了非主属性对于候选码的部分函数依赖。

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。

结论：
符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。

参考：https://www.zhihu.com/question/24696366

物理结构设计索引：https://www.cnblogs.com/auxg/p/Cluster-and-NonCluster-index.html