数据库设计

设计步骤

1、抽取实体

2、分析实体包含哪些属性

3、考虑实体和实体之间的关系：1：1，1：N，M：N

1、需求分析
明确系统要解决的问题；
收集用户需求，分析系统中涉及的数据及其使用方式；
输出结果：数据需求说明书。

2、概念结构设计
使用 E-R 图（实体-联系图） 描述现实世界中的实体、属性及其关系；
输出结果：E-R 图。

3、逻辑结构设计
将 E-R 图转换为关系模型（表结构）；
确定主键、外键、字段类型、约束条件；
输出结果：关系模式设计表。

4、物理结构设计
确定数据在数据库中的物理存储结构；
优化索引、分区、缓存策略；
输出结果：物理存储设计方案。

5、数据库实施
使用 SQL 语句创建数据库及表；
定义索引、视图、触发器等；
导入初始数据。

6、数据库运行与维护
定期备份；
性能优化；
数据安全与权限管理。

ER图工具

模型复杂度
如果只是小型系统、课程作业，用 Draw.io、dbdiagram.io 这样的在线工具就够了。
如果是企业级系统、数据库模型非常复杂，则建议用 Visual Paradigm、PowerDesigner 这类专业工具。

团队协作 / 多人编辑
在线工具通常天然支持多人协作、版本控制（如 dbdiagram.io, Creately）
桌面工具如果支持团队功能，要检查其版本控制 / 共享机制。

设计范式

第一范式：列不可再分

要求：表中每个字段都是不可再分的基本数据项。

示例：学生表中不能将“联系方式”同时存手机号和邮箱。

第二范式（2NF）：一张表只描述一件事

要求：在 1NF 的基础上，非主属性完全依赖于主键。

示例：如果主键是（学号, 课程号），则“姓名”只依赖学号，应拆分成独立的学生表。

第三范式（3NF）：一张表中的每一个列都直接依赖主键，而不是间接依赖

要求：在 2NF 的基础上，消除传递依赖。

示例：学生表中“专业名”依赖“专业号”，应将“专业”信息单独建立一张表。

实际设计中，一般达到 3NF 即可满足大部分系统需求，部分高并发系统会为性能适度反范式化

在上述表中，姓名和科目名称这两列并不是依赖于id这一列，而是分别依赖于学号和科目号
因此我们说这两列并不是直接依赖于主键，因此不符合第三范式

数据库设计是否一定要符合三个范式呢?或者说是不是符合的范式越高越好呢?
    数据库设计的范式和数据库的查询性能往往是互相矛盾的，范式越高查询性能越差所以，我们一般的策略是:如果需要频繁查询的表，尽是的降低范式从而获得更好的查询性能反之，尽是的提高范式