小小饰界商城系统数据库设计文档.docx
《小小饰界商城系统数据库设计文档.docx》由会员分享,可在线阅读,更多相关《小小饰界商城系统数据库设计文档.docx(24页珍藏版)》请在冰豆网上搜索。
![小小饰界商城系统数据库设计文档.docx](https://file1.bdocx.com/fileroot1/2023-5/28/a7656dc9-f475-42a4-acfa-b5cc1a60d3db/a7656dc9-f475-42a4-acfa-b5cc1a60d3db1.gif)
小小饰界商城系统数据库设计文档
小小饰界网站的设计与实现
数据库设计说明书
版本:
1.0
文档信息及版本历史
文档信息
项目名称
小小饰界网站
文档名称
小小饰界网站数据库设计说明书
存储位置
版本
作者/修改者
日期
描述
1.0
2014/3/26
开始撰写文档
2014/4/2
撰写修改文档
2014/4/16
修改文档
目录
1引言3
1.1编写目的3
1.2术语表3
1.3数据库命名约定3
1.4参考资料3
2数据库环境说明4
3数据库的命名规则4
4概要设计4
4.1实体图4
4.2总体ER图7
5逻辑设计8
5.1关系设计8
5.2关系优化9
5.3约束的说明10
5.4基本表10
6物理设计13
6.1确定关系模型的存取方法13
6.2确定数据库的存储结构13
7存储过程、函数及触发器的设计14
8安全性设计14
8.1用户帐号密码的加密方法14
8.2角色与权限14
9数据库实施15
1引言
1.1编写目的
本文档是小小饰界概要设计文档的组成部分,编写数据库设计文档的目的是:
明确数据库的表名、字段名等数据信息,用来指导后期的数据库脚本的开发,本文档遵循《数据库设计和开发规范》。
本文档的读者对象是需求人员、系统设计人员、开发人员、测试人员。
1.2术语表
定义系统或产品中涉及的重要术语,为读者在阅读文档时提供必要的参考信息。
序号
术语或缩略语
说明性定义
1
PM
ProjectManager,项目经理
2
ornament
饰品网站缩略词
3
概念数据模型
关系数据库的逻辑设计模型,叫概念数据模型。
主要内容包括一张逻辑E--R图及其相应的数据字典。
4
物理数据模型
关系数据库的物理设计模型,叫物理数据模型。
主要内容包括一张物理表关系图及其相应的数据字典。
5
角色
数据库中享有某些特权操作的用户,叫角色。
1.3数据库命名约定
前缀
说明
PK
表示主键
UK
表示唯一键
FK
表示外键
UI
表示唯一索引
NUI
表示非唯一索引
1.4参考资料
资料名称
作者
文件编号、版本
资料存放地点
《统一软件开发过程》
IvarJacobson,JamesRumbaugh,GradyBooch
第一版
小组办公室
《数据库系统概论》
萨师煊王珊
第四版
小组办公室
《软件工程》
钱乐秋赵文耘牛军钰
第一版
小组办公室
2数据库环境说明
数据库实例
数据库管理系统
数据库部署环境
数据库设计工具
数据库存放位置
说明
ornament
MySql,版本:
5.5
windows,JDKMyEclipse8.5,Tomcat5.0
visio,rose
E:
\ornament
ornament饰品网上购物网站
3数据库的命名规则
本数据库设计完全按照《数据库设计规范》命名。
4概要设计
数据库设计人员根据根据需求分析文档,抽象出系统实体及实体之间的联系,画出实体属性图及实体联系图(E_R图)。
通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,并采用自底向上的方法.用E-R图表示各实体之间的联系。
4.1实体图
通过需求分析我们得到客户,商品和仓库等最基本的实体,画出它们的实体图如下:
(1)会员实体—属性图,如图4.1所示。
图4.1会员实体—属性图
(2)商品实体—属性图,如图4.2所示。
图4.2商品实体—属性图
(3)商品类别实体—属性图,如图4.3所示。
图4.3商品类别实体—属性图
(4)购物车实体—属性图,如图4.4所示。
图4.4购物车实体—属性图
(5)订单实体—属性图,如图4.5所示。
图4.5订单实体—属性图
(6)客服实体—属性图,如图4.6所示。
图4.6客服实体—属性图
(7)系统管理员实体—属性图,如图4.7所示。
图4.7系统管理员实体—属性图
(8)评论实体—属性图,如图4.8所示。
图4.8评论实体—属性图
4.2总体ER图
通过以上分ER图,我们得到下面的总ER图,如图4.10所示。
图4.10总ER图
5逻辑设计
本次设计的数据库在mysql上实现,将概念结构设计中的E-R图转换成mysql支持的关系数据模型。
5.1关系设计
关系设计包括实体转换和联系转换。
(1)实体转换
将每个单独的实体转换为一张单独的表,具体转换如下:
会员:
会员号,密码,地址,邮编,电话,性别,姓名
商品:
商品编号,商品名称,商品单价。
商品类别:
商品类别编号,商品类别名。
购物车:
购物车编号,会员号,商品编号,商品名称,商品类别编号,商品单价,商品数量。
订单:
订单编号,会员号,订单总额,订货日期,订单状态。
客服管理员:
客服编号,客服用户名,客服密码。
系统管理员:
系统用户名,系统密码。
(2)联系转换
一个实体型转换为关系模式,实体的属性就是关系的属性,实体的码就是关系的码。
对于实体间的联系有以下几种不同的情况:
①多对多联系转换为一张单独的关系表
商品表:
商品编号,商品名称,商品单价,库存量。
②一对多的联系通过在多表中添加属性来实现
商品表:
商品编号,商品名称,商品单价,库存量,商品类别编号。
会员表:
会员号,密码,地址,邮编,电话,性别,姓名。
订单表:
订单编号,会员号,订单总额,订货日期,订单状态,商品编号,商品单价,商品数量。
5.2关系优化
为了减少以上表数据的冗余,将表优化,结果如下:
(1)会员表:
函数依赖集为F1={会员号→(密码,地址,邮编,电话,性别,姓名)}∈2NF
主属性:
会员号
非主属性:
密码,地址,邮编,电话,性别,姓名
主键:
会员号
(2)商品表:
函数依赖集为F3={商品编号→(商品名称,商品类别编号,商品库存量,商品单价)}∈3NF
主属性:
商品编号
非主属性:
商品名称,商品类别编号,商品库存量,商品单价
主键:
商品编号
(3)商品类别表:
函数依赖集为F4={商品类别编号→商品类别名}∈3NF
主属性:
商品类别编号
非主属性:
商品类别名
主键:
商品类别编号
(4)订单总表:
函数依赖集为F4={订单编号→(会员号,订单总额,订货日期,订单状态)}∈3NF
主属性:
订单编号
非主属性:
会员号,订单总额,订货日期,订单状态。
主键:
订单编号
(5)订单明细表:
函数依赖集为F5={(订单编号,商品编号)→(订货日期,商品单价,商品数量)}∈3NF
主属性:
订单编号,商品编号
非主属性:
订单总额,订货日期,商品单价,商品数量
主键:
订单编号,商品编号
5.3约束的说明
根据参照完整性,表与表之间有主键、外键、用户自定义约束。
(1)会员号为客户表的主键。
(2)性别只能为‘M’或’F’,对性别设立用户自定义约束。
(3)会员密码必须在6位以上。
(4)仓库表中仓库编号为主键。
(5)商品表中商品编号为主键。
(6)商品类别表中商品类别编号为主键。
(7)商品表中的商品类别编号应参照商品类别表中的类别编号。
(8)购物车表中的会员号应参照客户表中的会员号。
(9)商品暂存表中的商品数量默认为“0”。
(10)订单总表中订单编号为主键。
(11)订单明细表中订单编号和商品编号为主键。
(12)订单明细表中的订单编号应参照订单总表中的订单编号。
(13)订单明细表中的商品编号应参照商品表中的商品编号。
(14)订单状态设置默认值为0。
(15)一个会员购买某种商品的数量不能超过该商品的库存量,当会员购买之后,该商品的库存量应自动减少。
(16)当生成订单明细表后,订单总表要自动生成,订单时间由系统自动生成,当修改订单明细表时,订单总表也要做相应的修改。
(17)为会员舍弃商品后,应自动在订单明细表和订单总表中要做相应的修改。
5.4基本表
通过上面的关系转换与关系优化,我们最终得到8张基本表。
(1)会员表(customer表)如表5.1所示。
表5.1会员表
属性名
数据类型
是否为空
含义
是否为主键
cust_id
char(9)
notnull
会员号
primarykey
cust_code
char(12)
notnull
密码
addr
char(40)
notnull
地址
zip
char(6)
notnull
邮编
tel_no
char(11)
notnull
电话
sex
char
(2)
notnull
性别
cust_name
Char(20)
notnull
昵称
(2)商品表(product表)如表5.2所示。
表5.2商品表
属性名
数据类型
是否为空
含义
是否为主键
prod_id
char(6)
notnull
商品编号
primarykey
prod_name
varchar(20)
notnull
商品名称
kind_no
char(6)
notnull
商品类别编号
foreignkey(3)
storage
int
notnull
商品库存量
prod_price
numeric(7,2)
notnull
商品单价
image_path
Varchar(20)
Notnull
图片路径
(3)商品类别表(kind表)如表5.3所示。
表5.3商品类别表
属性名
数据类型
是否为空
含义
是否为主键
kind_no
char(6)
notnull
商品类别编号
primarykey
kind_name
varchar(20)
notnull
商品类别名
(4)购物车表(gouwu表)如表5.4所示。
表5.4购物车表
属性名
数据类型
是否为空
含义
是否为主键
gouwu_id
char(9)
notnull
购物车编号
primarykey
cust_id
char(9)
notnull
会员号
foreignkey
(1)
prod_id
char(6)
notnull
商品编号
foreignkey
(2)
prod_name
varchar(20)
notnull
商品名称
kind_no
char(6)
notnull
商品类别编号
foreignkey(3)
prod_price
numeric(7,2)
notnull
商品单价
counts
int
notnull
商品数量
(5)订单总表(orders表)如表5.5所示。
表5.5订单总表
属性名
数据类型
是否为空
含义
是否为主键
order_no
varchar(20)
notnull
订单编号
primarykey
cust_id
Char(9)
Notnull
会员号
Foreignkey
(1)
detail-order_no
varchar(20)
notnull
详细订单编号
Foreignkey(6)
total_count
int
notnull
商品总数
total_price
numeric(8,2)
notnull
订单总额
order_tel
char
notnull
电话号码
order_date
date
notnull
订货日期
order_status
varchar(6)
notnull
订单状态
(6)订单详表(detail_orders表)如表5.6所示。
表5.6订单详情表
属性名
数据类型
是否为空
含义
是否为主键
detail-order_no
varchar(20)
notnull
详细订单编号
primarykey
prod_id
char(6)
notnull
商品编号
foreignkey
(2)
prod_name
Varchar(20)
Notnull
商品名称
Count1
int
notnull
每种商品数量
price
numeric(8,2)
notnull
每种商品总额
order_no
varchar(20)
notnull
订单编号
Foreginkey(5)
(7)客服管理员(kefu表)如表5.7所示。
表5.7客服管理员
属性名
数据类型
是否为空
含义
是否为主键
kefu_id
char(10)
notnull
客服管理员编号
primarykey
kefu_username
char(10)
notnull
客服管理员帐号
kefu_password
char(6)
notnull
客服管理员密码
(8)管理员(admin表)如表5.8所示。
表5.8系统管理员
属性名
数据类型
是否为空
含义
是否为主键
admin_username
char(10)
notnull
系统管理员帐号
primarykey
admin_password
char(6)
notnull
系统管理员密码
(9)评论表(ping表)如表5.9所示。
表5.9系统管理员
属性名
数据类型
是否为空
含义
是否为主键
content
char(100)
notnull
评论内容
primarykey
prod_id
char(6)
notnull
商品编号
foreignkey
(2)
prod_name
varchar(20)
notnull
商品名称
6物理设计
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构,它依赖于选定的数据库管理系统。
为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程,就是数据库的物理设计。
它包括如下几个方面:
6.1确定关系模型的存取方法
数据库系统是多用户共享的系统,对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。
物理设计的任务之一就是要确定哪些存取方法,即建立哪些存取路径。
常用的存取方法有三类。
第一类是索引方法,目前主要是B+树索引方法;第二类是聚簇方法;第三类是HASH方法。
在实际设计中最常用的存取方法是索引,使用索引可以大大减少数据的查询时间,在建立索引时应遵循:
在经常需要搜索的列上建立索引; 在主关键字上建立索引;在经常用于连接的列上建立索引,即在外键上建立索引;在经常需要根据范围进行搜索的列上创建索引,因为索引已经排序,其指定的范围是连续的等规则。
才能充分利用索引的作用避免因索引引起的负面作用。
以下介绍索引方法和聚簇方法。
(1)索引存取方法的选择
①由于会员表的cust_id经常在查询和连接操作的条件中出现,故在cust_id上建立B+树索引。
②由于商品表的prod_id、prod_name、kind_no经常在查询和连接操作的条件中出现,故在这些属性上建立B+树索引。
③由于商品类别表中kind_no、kind_name经常在查询和连接操作的条件中出现,故在这些属性上建立B+树索引。
④由于订单总表中的order_no、cust_id经常在查询和连接操作的条件中出现,故在这些属性上建立B+树索引。
⑤由于订单总表的tot_amt和订单明细表的qty、dis_price经常作为最大值、最小值以及求和等聚集函数的参数,故在这些属性上建立B+树索引。
⑥由于订单明细表的order_no、order_date经常在查询和连接操作的条件中出现,故在这些属性上建立B+树索引。
(2)聚簇存取方法的选择
①由于订单总表和订单明细表的order_no经常要进行连接操作,为了提高order_no的查询速度,则对此关系建立一个聚簇索引。
②由于订单明细表和商品表的prod_id经常要进行连接操作,为了提高prod_id的查询速度,故对此关系建立一个聚簇索引。
③由于订单总表和客户表的cust_id经常要进行连接操作,为了提高cust_id的查询速度,故对此关系建立一个聚簇索引。
6.2确定数据库的存储结构
确定数据库的存储结构主要指确定数据的存放位置和存储结构,包括确定关系、索引、日志、备份等的存储安排及存储结构,以及确定系统存储参数的配置。
(1)确定数据的存放位置
为了提高系统性能,我们根据应用情况将数据的易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。
即把优惠表、仓库表作为数据稳定和存取频率较低部分;而把客户表、商品表、商品类别表、订单总表、订单明细表作为数据易变和经常存取部分,分开存放。
(2)确定系统配置
在进行物理设计时,根据应用环境,将数据库的大小的参数值设置为:
事务日志的分配空间为1.00MB,文件按10百分比自动增长,并将文件增长限制为10.00MB;数据文件的分配空间为2.00MB,文件按10百分比自动增长,并将文件增长限制为10.00MB。
7存储过程、函数及触发器的设计
存储过程:
根据具体的业务逻辑确定输入参数个数,类型,确定对哪几个表进行何种作。
在定义存储过程时,要使用其完成单一、相对集中的任务,不要定义已由其它定义提供功能的过程。
触发器:
对于复杂业务规则使用触发器,简单的完整性规则通过约束实现。
8安全性设计
根据系统需要设计相关用户和角色,并赋予相关操作权限。
8.1用户帐号密码的加密方法
对用户帐号的密码进行加密处理,确保在任何地方都不会出现密码的明文。
用户帐号采用MD5进行数据加密后再录入数据库,以防止任何地方密码的安全性要求。
8.2角色与权限
确定每个角色对数据库表的操作权限,如创建、检索、更新、删除等。
每个角色拥有刚好能够完成任务的权限,不多也不少。
在应用时再为用户分配角色,则每个用户的权限等于他所兼角色的权限之和。
角色
可以访问的表与列
操作权限
系统管理员
可访问所有表
完全控制权限
客服管理员
可访问所有表
系统管理员赋予他控制权限
会员
可访问部分表中的部分信息
检索商品和更新个人信息、购买商品
游客
可访问商品表信息
检索商品
9数据库实施
此阶段主要任务包括创建数据库,加载初始数据.
(1)创建数据库
createdatabaseornament;
useornament;
go
(2)系统管理员表的建立
CREATETABLEadmin(
admin_usernamechar(10)NOTNULL,
admin_passwordchar(12)NOTNULL,
PRIMARYKEY(admin_username)
);
(3)客服管理员表的建立
CREATETABLEkefu(
kefu_idchar(10)NOTNULL,
kefu_usernamechar(10)NOTNULL,
kefu_passwordchar(12)NOTNULL,
PRIMARYKEY(kefu_id)
);
(4)客户表的建立
CREATETABLEcustomer(
cust_idchar(20)NOTNULL,
cust_codechar(12)NOTNULL,
addrchar(40)NOTNULL,
zipchar(6)DEFAULTNULL,
tel_nochar(11)DEFAULTNULL,
sexchar
(2)NOTNULL,
cust_namechar(20)NOTNULL,
PRIMARYKEY(cust_id)
);
(5)商品类别表的建立
CREATETABLEkind(
kind_nochar(6)NOTNULL,
kind_namevarchar(20)NOTNULL,
PRIMARYKEY(kind_no)
);
(6)商品表的建立
CREATETABLEproduct(
prod_idchar(6)NOTNULL,
prod_namevarchar(30)NOTNULL,
kind_nochar(6)NOTNULL,
storageint(11)NOTNULL,
prod_pricedecimal(7,2)NOTNULL,
image_pathvarchar(20)NOTNULL,
PRIMARYKEY(prod_id),
constraintfk_k_idforeignkey(kind_no)referencesstudent(kind_no)
);
(7)购物车表的建立
CREATETABLEgouwu(
gouwu_idchar(6)NOTNULL,
cust_idchar(9)NOTNULL,
prod_idchar(6)NOTNULL,
prod_namevarchar(30)NOTNULL,
kind_nochar(6)NOTNULL,
prod_pricedecimal(7,2)NOTNULL,
countsintNOTNULL
PRIMARYKEY(gouwu_id),
constraintfk_c_idforeignkey(cust_id)referencescustomer(cust_id),
constraintfk_p_idforeignkey(prod_id)referencesproduct(prod_id),
constraintfk_k_idforeignkey(kind_no)referenceskind(kind_no)
);
(8)订单总表的建立
CREATETABLEorders(
order_novarchar(50)NOTNULL,
cust_idchar(8)NOTNULL,
detail_order_novarchar(50)NOTNULL,
total_countint(11)NOTNULL,
total_pricedecimal(8,2)NOTNULL,
order_telch