3.1、物理建模

3.1.1 理论

• 第一范式：数据库表中的每一列都不可再分，也就是
  image.png
• 第二范式：在满足第一范式基础上要求每个字段都和主键相关，而不仅和主键部分相关（主要针对联合主键而言）
  image.png 订单详情表”使用“订单编号”和“产品编号”作为联合主键。此时“产
  品价格”、“产品数量”都和联合主键整体相关，但“订单金额”和“下单时间”
  只和联合主键中的“订单编号”相关，和“产品编号”无关。所以只关联了主
  键中的部分字段，不满足第二范式。
  把“订单金额”和“下单时间”移到订单表就符合第二范式了。 image.png
• 第三范式：表中的非主键字段和主键字段相关，不允许间接相关 image.png 上面表中的“部门名称”和“员工编号”的关系是“员工编号”→“部门编号”→“部门名称”，不是直接相关。此时会带来下列问题：
• 数据冗余：“部门名称”多次重复出现。
• 插入异常：组建一个新部门时没有员工信息，也就无法单独插入部门
  信息。就算强行插入部门信息，员工表中没有员工信息的记录同样是
  非法记录。
• 删除异常：删除员工信息会连带删除部门信息导致部门信息意外丢失。

• 更新异常：哪怕只修改一个部门的名称也要更新多条员工记录。
  

  正确的做法是：把上表拆分成两张表，以外键形式关联“部门编号”和“员工编号”是直接相关的。第二范式的另一种表述方式是：两张表要通过外键关联，不保存冗余字段。例如：不能在“员工表”中存储“部门名称”。 image.png

3.1.2、创建数据库、管理员数据库表

CREATE DATABASE `project_crowd` CHARACTER SET utf8;
use project_crowd;
drop table if exists t_admin;
create table t_admin
(
    id int not null auto_increment, # 主键
    login_acct varchar(255) not null, # 登录账号
    user_pswd char(32) not null, # 登录密码
    user_name varchar(255) not null, # 昵称
    email varchar(255) not null, # 邮件地址
    create_time char(19), # 创建时间
    primary key (id)
);