1. 设计范式
范式是数据库设计的一系列指导原则，旨在通过减少数据冗余和提高数据一致性来组织数据，从而构建出对数据关系约束严格的数据库，以保证数据的准确性。但数据冗余越少，也意味着查询效率可能降低，因为多表联查的概率大大增加，因此现在的数据库设计只满足到第三范式的程度即可。为了更高的查询效率，我们也可以适当增加冗余字段，也就是反范式设计。
第一范式：
第一范式要求数据库表中的所有字段都是原子性的，即不可再分。这是因为，如果一列包含多个值，对该列的查询、更新和删除操作会变得非常复杂和低效，并难以对其进行约束。
不能满足第一范式的数据库不能称之为关系型数据库。
想要满足第一范式，我们需要做到，每一列都使用基本数据类型表示。
第二范式：
在满足第一范式的基础上，要求所有非主属性必须完全依赖于整个主键，而不能仅依赖于主键的一部分。如果一张表只有一列主键，不涉及联合主键，也就不涉及第二范式。
下面的表中，学生 ID 和 课程 ID 组成联合主键：
第三范式：
在满足第二范式的基础上，要求所有非主属性必须直接依赖于主键，而不能传递依赖于主键。
在数据库设计中，通常要求先达到第三范式的要求。再根据一些可能涉及到的频繁查询，对表进行反规范化设计。更高的范式意味着更多的表，更多的表意味着更多的 join，我们需要在性能和数据冗余程度间做出平衡。
2. 绘制 E-R 图
E-R 图用于确定实体与实体之间的关联关系，帮助他人快速理解整个系统的数据逻辑结构。
在 E-R 图中通常具有下面的关键要素：
实体：实体是现实世界中可以相互区分的事物或对象。例如：学生、课程、员工、部门、订单、产品。在 E-R 图中使用矩形表示。
属性：属性是实体的特征或性质。在 E-R 图中使用椭圆表示。
联系：联系是实体与实体之间的关系。在 E-R 图中使用菱形表示。在联系中，必须注明实体与实体之间的一对一、一对多、多对多等关系。
使用 draw.io 绘制的 E-R 图：
使用 Typora 绘制的 E-R 图：
Typora 代码块：
erDiagram
USER {
int user_id PK
string username
string phone
datetime register_time
}
ACTIVITY {
int activity_id PK
string activity_name
datetime start_time
datetime end_time
string status
}
PRIZE {
int prize_id PK
string prize_name
string prize_type
int stock_quantity
string image_url
}
WINNING {
int winning_id PK
int user_id FK
int activity_id FK
int prize_id FK
datetime winning_time
string claim_status
datetime claim_time
}
USER ||--o{ WINNING : "has"
ACTIVITY ||--o{ WINNING : "generates"
PRIZE ||--o{ WINNING : "awarded_as"使用 Typora 绘制的 E-R 图更具专业性，可以更好地供开发团队内部使用。而 draw.io 绘制的 E-R 图更为直观，可以提供给需求方。
对于已经存在的数据库表，我们也可以使用 Navicat、Workbench 等 MySQL 客户端来将数据库逆向为 E-R 图。