密码修改画面,提示旧密码不正确、新密码格式不符、两次不同等
异常
用户旧密码错误
规则
密码需要大于6位小于12位
管理博客账号用例
用例名称
管理博客账号
用例ID
UC-25
参与者
管理员
描述
管理员进行博客账号管理
主事件流
用户
系统
1.单击博客账号管理图标
2.显示博客账号管理主画面,包括博客账号的列表及删除按钮
可选事件流
删除博客账号
用户
系统
1.单击[删除]按钮
2.提示确认删除
3.单击[确认]删除
4.系统删除博客账号的信息,提示删除成功
表2-5修改博客账号用例
用例名称
修改博客信息
用例ID
UC-28
参与者
博客使用者
描述
修改博客账号信息
风险
低
优先级
高
难度
低
启动
进入修改博客画面
前置条件
博客使用者已登陆
后置条件
更新Session中的博客信息
主事件流
用户
系统
1.单击修改博客信息链接
2.系统显示修改博客画面,初始化该博客相关信息
3.修改博客的相关信息,单击【保存】
4.检查同名的博客是否存在、检查博客的名称、描述是否包含特殊字符
5.保存博客的相关信息、提示保存成功
异常流
异常流
同名博客账号存在
系统
提示已有同名博客存在,提示用户重新输入博客的名称
系统
提示输入的信息不合法,提示用户重新输入博客的名称、描述
规则
博客名称不能包含特殊字符
博客的名称不能重复
2.6数据字典
数据字典是系统分析阶段的重要文档,它清楚地定义与详细地解释了数据流程图上不能详细表达的内容,同时它也是同用户交谈的工具。
下面详细列出本系统中的数据字典:
3系统设计
3.1系统总体结构设计
本系统主要包括三大模块组成:博客访问者模块、用户模块、系统管理员模块。
整个系统的结构框架如下图所示
3.2系统数据模型设计
由于博客系统中对博客内容的写入、修改和更新工作比较复杂,所以它的主要任务是进行大量的数据库操作,这就必然要存储和利用大量的、各种类型的数据。如何建立一个良好的数据库结构和文件组织形式,使其能够迅速、准确的查找所需要的数据,是衡量这个系统的主要指标之一。
(一)概念模型的建立
通过第二章中对系统数据流以及局部数据流和数据字典的分析,可以总结出系统中数据概念模型,如下图所示:
概念模型(E-R图):
图3-2用户概念模型
图3-3系统概念模型
(二)数据模型的建立
现根据上述概念模型,将它们转化为数据模型,由于数据较多,现举部分数据进行转换。根据关系模型的转换规则,转换方式分为如下几种:
(1)一个实体型转换为一个关系模型
博客(博客ID、内容、标题、所属分类ID、相关博客连接关键字、总点击率、写入入时间、作者、来源、标题图片连接、所属专题ID、博客管理员ID、外部连接的Url);
注册会员(ID、姓名、密码、email、自我论述、注册日期、密码问题、密码答案、性别、生日、真实姓名、国家、省、市、电话、地址、qq);
管理员(ID、姓名、密码、系统标识、权限、管理的博客分类ID、发表的日志数、自我论述、email);
站点信息(热门日志、最新日志、博客总数、日志总数、评论总数、会员总数、专题数)
关键字(ID、关键字名、关键字连接Url、关键字连接alt);
模版(模版ID、模版名称、模版类型、模版文件名、模版缩略图、是否为默认模版);
系统风格(ID、名称、是否默认风格、css文件路径);
(2)一个1:n联系转换为一个关系模型
包含(日志ID,内容,标题,所属分类ID,相关连接关键字,总点击率,发表时间,作者,来源,评论数,评论ID,评论内容,评论者姓名,评论时间,评论者ip地址,是所属专题ID,发表者的用户ID,上传文件ID,上传文件路径)
属于(注册用户ID,姓名,密码,email,自我论述,注册日期,密码问题,密码答案,性别,生日,真实姓名,国家,省,市,电话,地址,qq)
(3)一个1:1联系可以转换为一个关系模型
链接(关键字ID,关键字名,关键字连接Url,博客ID,内容,标题)
(4)三个或三个以上实体间的一个多元联系转换为一个关系模式
评论(日志ID,评论者ID,博客分类ID)
(三)数据模型的优化
数据库逻辑设计的结果不是唯一的。为了进一步提高系统数据库应用系统的性能,必须对数据模型进行优化。由于数据较多,只就部分数据举例如下:
1.确定数据依赖
新闻关系模型中存在如下数据依赖:
博客ID→内容,博客ID→标题,博客ID→所属分类ID,博客ID→相关博客连接关键字,新闻ID→录入时间,博客ID→作者,博客ID→来源,博客ID→日点击率,博客ID→评论ID,博客ID→标题图片连接,博客ID→所属专题ID,博客ID→发表者的管理员ID,博客ID→博客外部连接的Url,博客ID→上传文件ID,博客ID→上传文件路径,博客ID→评论数,上传文件ID→上传文件路径,评论ID→评论内容、评论ID→评论者姓名、评论ID→评论图象、评论ID→评论时间、评论ID→评论者ip地址,(日志ID、评论ID)→评论数,评论ID→评论数
其中码有(博客ID,评论ID,上传文件ID,日志ID)
2.消除冗余关系
观察上述依赖发现如果一篇日志含有多个评论,那么日志的其他属性将重复存储很多次,因此可以将关系模型转化为:
日志(日志ID、内容、标题、所属分类ID、总点击率、发表时间、作者、来源、评论数、标题图片连接、所属专题ID、发表者的用户ID、摘要、日志外部连接的Url、上传文件ID、上传文件路径、评论ID)
评论(日志ID、评论ID、评论数、评论内容、评论者姓名、评论图象、评论时间、评论者ip地址)
3.考查部分函数依赖、传递函数依赖等的存在性,以确定关系模型分别达到的范式
在"日志"关系模式中"评论ID"并不决定其他的非主属性,同时存在"日志ID→上传文件ID","上传文件ID→上传文件路径"这样的传递函数依赖,因此,在消除部分依赖和传递依赖后可以将关系转换为:
日志(日志ID、内容、标题、所属分类ID、相关日志连接关键字、总点击率、发表时间、作者、来源、评论数、是否头条新闻、标题图片连接、所属专题ID、发表者的用户ID、日志外部连接的Url)
评论(评论ID、评论内容、评论者姓名、评论图象、评论时间、评论者ip地址)
上传文件(上传文件ID、上传文件路径)
因此,可以确定这样的关系模型达到了第三范式。
4.确定是否分解
由于,关系模型的规范化程度并不是越高越好,在实际应用中高范式可能会带来程序查询时间的浪费,所以,在数据库文件设计上,本系统达到第三范式已经足够,无须在做分解。
3.3数据库表的设计
数据库设计是项目开发中的系统设计中非常重要的另一个关键环节,在这里之所以特别强调数据库设计的重要性,上因为数据库设计就像在建设高楼大厦的根基一样,如果设计不好,在后来的系统维护、变更和功能扩充时,甚至在系统开发过程中,将会引起比较大的问题,会遇到非常大的困难,大量的工作将会重新进行。
下面根据前面列出的系统用例图,开始设计相关数据库。
(1)数据库表及表之间的相互关系
本系统需要设计的数据库表如下
数据库表
序号
数据
上一篇:
asp医药连锁店管理系统ASP+源代码+可执行程序+论文(论文和程序)
下一篇:
试析影响公路路面平整度的因素及应采取的施工措施