提示：该博文为视频笔记，可前往视频结合笔记一起学习效果更佳~
数据库设计整体流程
1.现实世界的实体模型通过建模转换为信息世界的概念模型（即E-R模型）
2.概念模型经过模型转化，得到数据库世界使用的数据模型（在关系数据库设计中为关系模型）
3.数据模型进一步规范化（使用范式等），得到数据库模型
这里以一个例子引入
业务实例：设计petStore数据库 宠物商店系统的业务逻辑如下：
1 用户注册：输入用户号、用户名、密码、性别、住址、邮箱及电话进行注册，注册成功以后就可以按产品的分类浏览网站
2 商品管理：为管理员所用，管理员可以增加商品分类，可以为每个分类增加商品，其中商品包括商品号、商品名、商品分类、市场价格、当前价格、数量及商品介绍
3 用户订购宠物：当用户看中某个宠物时，可以加入购物车；当用户选择完毕时，就可以购买下单了。购买涉及订单、订单明细，其中，订单包括订单号一订单日期一订单总价一订单状态等信息；而对于每个订单，有订单明细表，列出了所购商品号、单价和数量
第一步-构建ER图
首先，根据以上义务逻辑，我们可以确定系统有三个实体：用户，商品，订单
用户和订单是一对多的关系（一个用户对应多个订单，一个订单对应一个用户）
订单与商品是多对多的关系（一个订单可以对应多个商品，反之也一样）
画出ER图
第二步-根据ER图转换为关系模式
首先，我们先看商品和订单两个实体如何转换，由于他们是多对多的联系，要单独抽出一个【选购】的关系模式，同时选购带有着联合主键
下面加粗的为主键
商品（商品号，商品名，商品分类，市场价格，当前价格，数量，商品介绍）
订单（订单号，订单日期，订单总价，订单状态）
选购（商品号，订单号，单价，数量）
我们来看订单和用户的联系，他们之间是一对多的联系
【一对多的联系分为两种转换方式 ①将他们之间的联系单独抽出来作为一个联系模式 ② 将一端的主键加到多端的实体属性中，同时要把联系上的属性也加到多端实体的属性中（这里用户和订单的联系“属于”中没有属性）】
这里我们使用第二种
用户（用户号，用户名，密码，性别，住址，邮箱，电话）
订单（订单号，用户号，订单日期，订单总价，订单状态）
这里就有问题了，这里我们有两个订单的关系模式，我们要选哪个？
当然，为了满足第二种方法，我们留下下面订单的关系模式
最终得出：
商品 （商品号，商品名，商品分类，市场价格，当前价格，数量，商品介绍）
订单（订单号，订单日期，订单总价，订单状态）
选购 （商品号，订单号，单价，数量）
用户 （用户号，用户名，密码，性别，住址，邮箱，电话）
订单 （订单号，用户号，订单日期，订单总价，订单状态）
第三步-通过范式理论把数据库规范化
● 第一范式(1ND)–满足原子性,字段属性不可再切分
● 第二范式(2ND)–不能存在部分函数依赖,就是去除部分依赖关系
● 第三范式(3ND)–不能存在传递函数依赖
显然第一范式满足，但是我们看第二范式，对于【商品】中的商品分类，他是不依赖于商品号的，我们要把这个分类去掉，新加一个表【商品分类表】（分类号，分类名称），把商品中的分类去掉，替换成分类号
所以最终规范化的数据库关系模式如下
商品表product（商品号，商品名，分类号，市场价格，当前价格，数量，商品介绍）
订单明细表lineitem（商品号，订单号，单价，数量）
用户表account（用户号，用户名，密码，性别，住址，邮箱，电话）
订单表orders（订单号，用户号，订单日期，订单总价，订单状态）
商品分类表category（分类号，分类名称）
总结
三步骤流程 构建ER图 --> 根据ER图转换为关系模式 --> 通过范式理论规范化