关于Oracle数据库的学习记录：
五十四、数据库设计分析实战
巩固数据库的设计范式，先按照标准的数据库设计范式来出设计
所有和设计相关的话题，都没有一个绝对性的答案，只有相对合理的答案
1、设计要求
设计一个购物网站程序，基本要求如下：
**所有的商品由后台管理员进行管理，所发布的商品必须经过其他管理员审核后才可以由顾客购买
**每一个管理员都有一个自己的角色，每一个角色包含有多个权限组，每个权限组可以属于不同的角色，每个权限组有多个权限
**所有的商品需要按照类型进行分类，分类分为一级类型与二级类型
**每一件商品都可以有多张展示图片
**商品可以由用户进行评论，在评论时可以写出购买体会与打分
**每一个用户在每次订单中可以购买多件商品，并且要保留有详细的购买记录
**在进行购买商品配送时，要求用户提供有详细收件地址、联系人、电话等信息，一个用户可以设置多个地址，并且可以设置一个常用地址
2、设计实现
2.1所有的商品由后台管理员进行管理，所发布的商品必须经过其他管理员审核后才可以由顾客购买
商品信息应该是一张实体表，类似于dept表就属于一张实体表，实体表一定需要主键，由于此数据的主键不需要特殊的处理，所以可以直接使序列生成
**商品：
商品ID NUMBER ,pk
供应商ID NUMBER,fk
发布管理员ID VARCHAR2(50),fk
审核管理员ID VARCHAR2(50),fk
类型ID NUMBER,fk
子类型ID NUMBER,fk
名称 VARCHAR2(50)
价格 NUMBER
描述 CLOB
发布日期 DATE
审核日期 DATE
标记 NUMBER
审核未通过原因 VARCHAR2(200)
商品如果要有品牌的话，那么一个品牌就需要对应多个商品信息，使用第三范式
**供应商：
供应商ID NUMBER
名称 VARCHAR2(50)
联系人 VARCHAR2(50)
所有的商品一定由管理员进行维护
**管理员：
管理员ID VARCHAR2(50),pk
角色ID NUMBER,fk
密码 VARCHAR2(32)
上次登录时间 DATE
所发布的商品不能够直接让前台用户浏览，需要先审核，那么需要有一个明确的字段来描述当前商品的状态，例如：有一个flag字段，这个字段可以描述商品的状态：
**flag=0：此商品等待审核
**flag=1：此商品审核通过，可以正常浏览
**flag=2：此商品审核不通过，需要重新提交审核
**flag=3：此商品已经被逻辑删除了，不应该被搜索到
如果真的需要审核的话，那么审核管理员和发布管理员不能为同一个人，但是这个判断是由程序的逻辑业务来进行处理的，所以本次只是提供数据的存储
2.2每一个管理员都有一个自己的角色，每一个角色包含有多个权限组，每个权限组可以属于不同的角色，每个权限组有多个权限
每一个角色可以有多个管理员具备，但是一个管理员只能够有一个角色，属于一对多关系，使用第三范式
**角色：
角色ID NUMBER，pk
名称 VARCHAR2(50)
每一个角色包含多个权限组，每一个权限组可以属于多个角色，典型的多对多关系，使用第二范式
**权限组：
权限组ID NUMBER,pk
名称 VARCHAR2(50)
角色_权限组
角色ID NUMEBR,fk
权限组ID NUMEBR,fk
每一个权限组有多个权限，属于一对多关系，使用第三范式
**权限：
权限ID NUMBER,pk
权限组ID NUMBER,fk
名称 VARCHAR2(50)
路径 VARCHAR2(200)
2.3所有的商品需要按照类型进行分类，分类分为一级类型与二级类型
商品分为两类，类型与子类型，一个类型下有多个子类型，属于第三范式
**类型：
类型ID NUMEBR,pk
名称 VARCHAR2(50)
描述 CLOB
**子类型：
子类型ID NUMBER,pk
类型ID NUMEBR,fk
名称 VARCHAR2(50)
描述 CLOB
商品也有所属的类型，一个类型下有多个商品，一个子类型下也有多个商品，属于第三范式
2.4每一件商品都可以有多张展示图片
一个商品可以有多张图片，属于一对多关系，使用第三范式
**商品图片：
商品图片ID NUBMER,pk
商品ID NUMBER,fk
名称 VARCHAR2(50)
图片 BLOB
2.5商品可以由用户进行评论，在评论时可以写出购买体会与打分
每一个用户可以评价多个商品，每一个商品可以有多个用户评价，属于多对多关系，兵器而每一个用户针对于每一个商品可以写出自己的心得体会与打分
**用户：
用户ID VARCHAR2(50),pk
密码 VARCHAR2(32)
头像 BLOB
**评论：
评论ID NUMBER,pk
用户ID VARCHAR2(50),fk
商品ID NUMBER,fk
评论内容 CLOB
评论日期 DATE
成绩 NUMBER
2.6每一个用户在每次订单中可以购买多件商品，并且要保留有详细的购买记录
一个用户可以有多个订单，每一个订单可以有多个购买的商品，每个订单购买的详细内容，可以设计一个订单详情表描述，即：用户与订单属于第三范式，订单与订单详情表属于第三范式
**订单：
订单ID NUMBER,pk
用户ID NUMBER,fk
下单日期 DATE
联系人 VARCHAR2(50)
地址 VARCHAR2(200)
电话 VARCHAR2(50)
金额 NUMBER
订单状态 NUMBER
**订单详情：
订单详情ID NUMBER,pk
商品ID NUMBER,fk
订单ID NUMBER,fk
数量 NUMBER
2.7在进行购买商品配送时，要求用户提供有详细收件地址、联系人、电话等信息，一个用户可以设置多个地址，并且可以设置一个常用地址
如果要保存地址，需要知道用户所在的省份与城市，一个省份中包含有多个城市信息，一对多关系，一个省份能有多个用户地址，或者说一个城市可能有多个用户地址
**省份：
省份ID NUMEBR,pk
名称 VARCHAR2(50)
**城市：
城市ID NUMEBR,pk
省份ID NUMEBR,fk
名称 VARCHAR2(50)
**联系地址：
联系地址ID NUMBER,pk
省份ID NUMBER,fk
城市ID NUMBER,fk
用户ID NUMBER,fk
联系人 VARCHAR2(50)
电话 VARCHAR2(20)
地址 VARCHAR2(200)
地标 VARCHAR2(20)
常用地址标记 NUMBER
对于常用地址标记（flag=1，为常用）、（flag=0，为普通）
总结：前期的设计一定要按照数据库的设计范式来完成