⽹上购物系统-关系型数据库设计举例
⽹上购物系统
1.系统需求分析
1.1前台功能分析
⽹上购物系统前台的⽤户共分两类：⼀类是注册⽤户(正式⽤户)，这类⽤户有基本的信息，可以对⾃⼰的信息进⾏查看与修改，可以随时实现⽹上购物。当⽤户在⽹站所购商品总⾦额达⼀定数量，可以根据所购商品总⾦额数量不同⾃动升级成为不同等级的VIP会员，并享受不同折扣优惠；另⼀类⽤户是游客（未注册⽤户），他们只能查看、浏览⽹站信息，可以把商品加⼊购物车或收藏夹，但不能实现购买。
游客：可以查看商品信息、浏览⽹站信息，可以把商品加⼊购物车或收藏夹，但不能实现购买。经过注册可以成为注册⽤户。
注册⽤户：
登录后对可以对个⼈信息进⾏查看和修改。
商品信息浏览、商品查、商品评论和建议。
注册⽤户不仅可以对⽹站商品进⾏浏览和查外，还可以对商品进⾏评论、向管理员发送消息提出⾃⼰的建议。
选购商品加⼊购物车或收藏夹、对购物车或收藏夹信息进⾏管理。
⽤户注册后，登陆到电⼦商务⽹站中，可以进⼊购物流程。⽤户在浏览商品后，可将满意商品放⼊购物车或收藏夹，购物车内可以随意增加、删除商品，修改商品数量，并同时统计购物车内商品总额。⽤户可对购物车的商品进⾏修改或删除，或对收藏夹中商品进⾏删除。
结帐、确认订单、订单状态查询、历史订单查询。
那些年我们错过的大雨⽤户确认购物车内信息⽆误，即可⽣成订单。在⽣成订单时，必须填写⼀张配送单。配送单默认为⽤户注册时的基本信息，当然配送地址可由⽤户修改为合适的收货地址，⽀付⽅式也可根据提⽰由⽤户⾃定。下单后，⽤户可以在前台页⾯查看订单状态，订单状态可以是“末处理”，“已发货”，“已付款”。
5、发表及回复留⾔。
为了加强注册⽤户之间的交流，⽹站还提供了论坛功能，注册⽤户可以在某⼀个论坛版块中发贴，也可以回复别⼈的贴⼦。
1.2后台功能分析
⽹上购物系统后台主要是供管理员使⽤的，管理员可对商品的⼀级分类信息、⼆级分类信息、商品信息进⾏添加、删除、查询及修改；对⽤户订单进⾏处理；管理⽤户在论坛中发表的留⾔，删除不健康及不利于⽹站的留⾔；回复⽤户发送的消息；对⽹站的新闻、公告进⾏管理。
管理员也可以具有不同的权限分为超级管理员和普通管理员，普通管理员具有以上权限，超级管理员除了可以具有以上所有功能外，还可以添加、删除普通管理员。
2.数据库设计
2.1数据库概念结构设计
对⽹上购物系统进⾏分析之后，抽象出有关的数据，按照现实世界的事物能作为属性对待的，尽量作为属性对待的原则。作为“属性”，不能再具有需要描述的性质，“属性”必须是不可分的数据项，不能包含其它的属性；“属性”不能与其它实体具有联系，E-R图中所表⽰的联系是实体与实体的联系。依照以上准则，可以确定哪些为实体，哪些为属性，每个实体具有哪些属性，实体之间存在何种联系。经分
析之后，该系统中包含的实体以及实体之间的联系如下所⽰：
实体：⼀级分类、⼆级分类、商品、⽤户、订单、订单明细、送货地址、论坛版块、留⾔、VIP⽤户等级、管理员、新闻、公告。
（注：因为订单中包含若⼲订单明细，根据“属性”是不可分的数据项，所以要反“订单明细”上升为实体。同样的道理，⼀个⽤户对应多个送货地址，所以“送货地址”也要上升为实体。另外，因为⽤户等级要与优惠政策挂钩，所以⽤户等级也要定义为实体，即VIP等级。）
实体间存在的联系：
⼀级分类和⼆级分类之间存在⼀对多的⼦类联系
⼆级分类与商品之间存在⼀对多的分类联系
商品与注册⽤户之间存在三个多对多的联系：收藏、选购和评论
⽤户与订单之间存在⼀对多的下单联系
订单与送货地址之间存在多对⼀的对应2联系
⽤户与送货地址之间存在⼀对多的对应1联系
订单与订单明细之间存在1对多的包含1联系
订单明细与商品之间存在多对1的包含2联系
论坛版块与留⾔之间存在⼀对多的归属联系
⽤户与留⾔之间存在⼀对多的发贴联系和多对多的回复联系
⽤户与VIP等级之间存在多对⼀的属于联系
⽤户与管理员之间存在多对多的消息联系
实体的属性：
⼀级分类：⼀级分类号，⼀级分类名
⼆级分类：⼆级分类号，⼆级分类名，⼀级分类号
商品：商品号，商品名称，所属分类，颜⾊，⼤⼩，商品描述，单价，库存量，已售出量，其他
⽤户：⽤户号，⽤户名，密码，真实姓名，性别，出⽣年⽉，邮箱，电话，单位，城市，地址，注册时间，积分，⽤户等级，安全问题，安全答案
（注：积分属性⽤来记录该⽤户的总订单⾦额，⼀元为⼀分；为了让忘记密码的⽤户可以从邮箱中回密码，设置安全问题，安全答案两个属性）
VIP⽤户等级：⽤户等级，⽤户折扣，积分下限，积分上限
（注：⽤户等级分为四等，根据等级分别享有10折（即普通客户）、9折、8.5折、7.5折优惠。）
订单：订单号，⽤户号，订货时间，收货⼈，收货⼈电话，送货⽅式，送货地址，邮编，订单总⾦额，发货时间，订单状态
订单明细：订单明细号，订单号，商品号，数量，单价，折扣价
送货地址：⽤户号，地址，邮编，电话。
论坛版块：版块号，版块名称，版主
留⾔：留⾔号，⽤户号，标题，内容，时间，回复数量，查看数量，最后回复⼈，是否置顶，是否精华，所属版块。
管理员：管理员ID，密码，权限
个性网游名字新闻：新闻号，标题，内容，时间
公告：公告号，标题，内容，时间
加了下划线的属性组为实体的码。
联系的属性：
选购：⽤户号，商品号，数量，单价，折扣价，选购时间
收藏：⽤户号，商品号，收藏时间
评论：⽤户号，商品号，标题，评论内容，评论时间
消息：消息发送者，消息接收者，内容，时间，状态
回复：⽤户号，留⾔号，主题，内容，回复时间
系统E-R如下图所⽰：
2.2数据库逻辑结构设计
2.2.1关系模型的设计
根据系统E-R图，把实体与实体之间的联系转换成关系模型，E-R图中的每个实体转换成⼀个关系模型，实体之间⼀对多的联系合并到多⽅实体对应的关系模型中，把⼀⽅的码与联系的属性纳⼊到多⽅实体对应的关系模型中，为实体之间多对多的联系创建⼀个新的关系模型，它包含双⽅的码以及联系的属性。具有相同码的关系模型有些情况下可以考虑把它们合并。在转换过程中应该按照关系规范化的理论，对关系模型进⾏优化，减少冗余和数据操作异常，提⾼查询速度，在性能与范式之间作出权衡，⼀般所设计出的关系数据库达到3NF就基本符合要求。按照以上原则，我们可以把系统E-R图中实体及实体之间的联系转换成关系模型，如下所⽰：
⼀级分类（⼀级分类号，⼀级分类名）
⼆级分类（⼆级分类号，⼆级分类名，⼀级分类号） //已经包含了⼀级分类与⼆级分类之间的⼀对多联系
商品（商品号，商品名称，所属分类，颜⾊，⼤⼩，商品描述，单价，库存量，已售出量，其他） //已经包含了⼆级分类与商品之间的⼀对多联系
⽤户（⽤户号，⽤户名，密码，真实姓名，性别，出⽣年⽉，邮箱，电话，单位，城市，地址，注册时间，积分，⽤户等级，安全问题，安全答案） //已经包含了VIP⽤户等级与⽤户之间的⼀对多联系
VIP⽤户等级（⽤户等级，⽤户折扣，积分下限，积分上限）
订单（订单号，⽤户号，订货时间，收货⼈，收货⼈电话，送货⽅式，送货地址，邮编，订单总⾦额，发货时间，订单状态） //已经包含了⽤户与订单之间、送货地址与订单之间的⼀对多联系
订单明细（订单明细号，订单号，商品号，数量，单价，折扣价，订货时间）//已经包含了订单与订单明细之间、商品与订单明细之间的⼀对多联系
送货地址（⽤户号，地址，邮编，电话）
论坛版块（版块号，版块名称，版主）
留⾔（留⾔号，⽤户号，标题，内容，时间，回复数量，查看数量，最后回复⼈，是否置顶，是否精华，所属版块）//已经包含了论坛版块与留⾔之间的⼀对多联系
管理员（管理员ID，密码，权限）
新闻（新闻号，标题，内容，时间）
公告（公告号，标题，内容，时间）
收藏夹（⽤户号，商品号，收藏时间） // 对应收藏联系
购物车（⽤户号，商品号，数量，折扣价，选购时间） //对应选购联系
评论（⽤户号，商品号，标题，评论内容，评论时间） //对应评论联系
消息（消息发送者，消息接收者，内容，时间，状态） //对应消息联系
回复（⽤户号，留⾔号，主题，内容，回复时间）//对应回复联系赖明育
各关系模型中加下划线的属性组为码。为了⽅便起见，也可为某些表添加⼀个具有唯⼀标识的属性作为码，如：
回复（回复ID，⽤户号，留⾔号，主题，内容，回复时间）//添加回复ID作为码
消息（消息ID，消息发送者，消息接者，内容，时间，状态）//添加消息ID作为码
评论（评论ID，⽤户号，商品号，标题，评论内容，评论时间）//添加评论ID作为码
购物车（购物车ID，⽤户号，商品号，数量，折扣价，选购时间）//添加购物车ID作为码
收藏夹（收藏ID，⽤户号，商品号，收藏时间）//添加收藏ID作为码
2.2.2约束的说明
在SQL Server2000中或2005中创建⽹上购物系统的数据库NetShop，建⽴各个表及有关的完整性约束，建议在SQL Server中创建的表名及表中的字段名都使⽤英⽂，且做到见名知意。
对约束的要求：
（1）实体完整性约束：为各个表创建主键约束，以实现实体完整性约束。
（2）参照完整性约束：为各个表创建外键约束或创建触发器来实现参照完整性约束。
（3）⽤户⾃定义完整性约束： 根据本系统对数据的要求，为表中的某些列实现以下⾃定义完整性约束。有的可以通过在定义表时指定数据类型，长度来实现，有的通过核查约束来实现，有的通过默认值、是否允许空值来实现，有的通过触发器来实现。
数据类型约束
数据长度、精度约束
取值范围约束
⽤户表中密码⾄少6位，并不能与⽤户号同名。
性别只能取‘男’或‘⼥’
订单表中订单号共12位，前8位是订货⽇期，后4位是流⽔号，格式为“200707010001”。
幼儿园中班开学寄语订货时间要早于发货时间。
订单状态取值为“末处理”，“已发货”，“已付款”。
订单⾦额必须是明细表中同⼀订单所有商品总价格之和（触发器完成）。
其他：如默认值、空值等等
徐暐翔还有其他约束吗？
2.2.3检查是否⽀持复杂应⽤
1、当⽤户订购某⼀商品时，要根据订货数量与商品库存量⽐较的结果选择是否能够正常订购，或不能，提⽰有关信息，若能，还应即时修改商品的库存量与已售出量。
可以创建⼀个触发器，当⽤户添加订购信息时能做出相应处理。
2、如何使⽤户在完成⼀定的订购⾦额或数量后⾃动VIP⽤户？
普通⽤户变成VIP⽤户主要看⽤户累计完成的订购⾦额或数量，如果是达到⼀定要求，也必须由触发器便⾃动将⽤户升级为不同的VIP⽤户。
3、订单上的订单⾦额是如何取得其值？
在⼀个订单上可能有多种商品，因此，订单⾦额是⼀个计算列，不能让⽤户输⼊，可以设置触发器来完成统计功能。
查看某个⽤户的所有订单。
黄造时可以创建⼀个带⼀个输⼊参数的存储过程来实现。
查看某张订单中的订单明细。
可以创建⼀个带⼀个输⼊参数的存储过程来实现。
进⼀步的思考
如何实现商品销售排⾏榜？
如何确认畅销商品、滞销商品？
这些关系表达到了第⼏范式？
2.3数据库物理结构设计
在经常查询，但更新较少的列上建⽴索引以提⾼查询速度。
发布评论