数据库设计
需求分析
*1.用户模块
用于记录记录注册用户信息
包括属性:用户名，密码，电话，邮箱，身份证号，地址，姓名，昵称．．．
可选唯一标志属性:用户名，电话，身份证号
存储特点:随系统上线时间逐渐增加,需要永久存储
*２.商品模块
用于记录记录注册用户信息
包括属性:商品编码，商品名称，商品品类，重量，价格．．．
可选唯一标志属性:商品编码，商品名称
存储特点:对下线商品可归档
*3.订单模块
用于记录记录注册用户信息
包括属性:订单号，用户姓名，用户电话，收货地址，商品编号，数量，价格，订单状态，支付状态，订单类型．．．
可选唯一标志属性:订单号
存储特点:永久存储(分表，分库存储)
逻辑设计
*1.第一范式
数据库表中的所有字段都是单一属性，不可再分
例如：
StudyNo | Name | Sex | Contact
20040901 john Male Email:kkkk@ee.NET,phone:222456
20040901 mary famale email:kkk@fff.net phone:123455
以上的表就不符合，第一范式：主键StudyNo重复(实际中数据库不允许重复的)，而且Contact字段可以再分
所以变更为正确的是
StudyNo | Name | Sex | Email | Phone
20040901 john Male kkkk@ee.net 222456
20040902 mary famale kkk@fff.net 123455
*2.第二范式
不存在非关键字段对于候选关键字段的部分函数依赖；例如：表中的关键字段（商品名称）决定了非关键字段（价格、描述、重量、有效期、饮料）；关键字段（供应商名称）决定了非关键字段（供应商电话），所以关键字段和非关键字段之间存在着部分函数依赖；通俗的来说：就是第二范式要求表的主键和非主键之间“不能”有一毛钱的关系，这样才不会产生部分函数依赖；而属于完全函数依赖；这样就可以定义成：表中的非关键字段要和关键字段存在着完全函数依赖
StudyNo | Name | Sex | Email | Phone | ClassNo | ClassAddress
01 john Male kkkk@ee.net 222456 200401 A楼2
01 mary famale kkk@fff.net 123455 200402 A楼3
这个表完全满足于第一范式,
主键由StudyNo和ClassNo组成，这样才能定位到指定行
但是,学生和班级是多对多关系，所以StudyNo和ClassNo才能标志出一个学生,ClassAddress部分依赖于关键字(ClassNo-〉ClassAddress),
存在问题 :
插入异常：如果没有200401这个课号，则找不到这个课号信息
删除异常：本例删除一个200401的学生信息，则也找不到这个课号信息
更新异常: 如果要更新200401课号地址(只更新一个学生的)，势必要更新所有200401课号学生的
数据冗余:提供多个学生，会有许多课号地址冗余
所以要变为两个表
表一
StudyNo | Name | Sex | Email | Phone | ClassNo
01 john Male kkkk@ee.net 222456 200401
01 mary famale kkk@fff.net 123455 200402
表二
ClassNo | ClassAddress
200401 A楼2
200402 A楼3
*3.第三范式
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john Male kkkk@ee.net 优秀 $1000
20040902 mary famale kkk@fff.net 良 $600
这个完全满足了第二范式,但是bounsLevel和bouns存在传递依赖
更改为：
StudyNo | Name | Sex | Email | bouunsNo
20040901 john Male kkkk@ee.net 1
20040902 mary famale kkk@fff.net 2
bounsNo | bounsLevel | bouns
1 优秀 $1000
2 良 $600
*4.BC范式
假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
把仓库管理关系表分解为二个关系表：
仓库管理：StorehouseManage(仓库ID, 管理员ID)；
仓库：Storehouse(仓库ID, 存储物品ID, 数量)。
这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。
逻辑设计
反范式
本质上就是用空间来换取时间，把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联