mysql 数据库设计

数据库设计

需求分析

*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.第二范式

不存在非关键字段对于候选关键字段的部分函数依赖；例如：表中的关键字段（商品名称）决定了非关键字段（价格、描述、重量、有效期、饮料）；关键字段（供应商名称）决定了非关键字段（供应商电话），所以关键字段和非关键字段之间存在着部分函数依赖；通俗的来说：就是第二范式要求表的主键和非主键之间“不能”有一毛钱的关系，这样才不会产生部分函数依赖；而属于完全函数依赖；这样就可以定义成：表中的非关键字段要和关键字段存在着完全函数依赖

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课号学生的

数据冗余:提供多个学生，会有许多课号地址冗余

所以要变为两个表

表一

  01            john         Male       kkkk@ee.net  222456   200401     

  01           mary         famale    kkk@fff.net    123455      200402

表二

ClassNo | ClassAddress

200401 A楼2

200402 A楼3

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范式的，消除了删除异常、插入异常和更新异常。

逻辑设计

反范式

本质上就是用空间来换取时间，把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联