校友录管理系统需求分析剖析Word下载.docx
《校友录管理系统需求分析剖析Word下载.docx》由会员分享，可在线阅读，更多相关《校友录管理系统需求分析剖析Word下载.docx（9页珍藏版）》请在冰点文库上搜索。
学号：
20121112118
指导教师：
刘春华
系统的功能分析：
系统管理：
用户管理，修改密码，重新登录
退出系统数据操作：
数据录入，数据查询，数据删除，显示所有记录，存盘并退出，数据库需求分析：
根据系统功能，可以确定以下数据项和数据结构：
数据录入，必须包括：
姓名，性别，电话，家庭地址，邮编，E-mail等基本信息；
数据删除，删除某人的信息；
数据查询，可以按姓名，家庭住址，性别等多种方式查询；
显示所有信息
校友录网站的操作流程
如下所示：
1．新用户通过注册系统，获得用户登录账号。
同时发送用户账号信息以及个人信息到后台数据库相关表进行存储。
2．注册用户可修改登录密码、个人信息及个人头像，并将数据发送到后台数据库相关表进行更新。
3．注册用户可通过搜索功能进行同学、班级以及学校搜索，并可加入搜索到的相关班级，同时将相关数据发送到后台数据库相关表进行更新。
如果没有搜索到学校或班级，则可创建新的学校或班级。
4．用户登录进入校友录后，可以通过数据库的查询列举所加入的所有班级。
5．班级成员可在班级首页的留言板或班级留言板中进行留言，同时发送相关留言信息到后台数据库相关表进行存储。
6．班级成员可在上传照片页面中上传相片到所属的所有班级，同时发送相关留言信息到后台数据库相关表进行存储。
7．班级成员可在班级相册页面内对照片进行评论，同时发送相关评论信息到后台数据库相关表进行储存。
将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式，这种转换一般遵循如下原则：
一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的关键字就是关系的关键字。
一个1:
1联系可以转换为一个独立的关系模式，也可以与任意一端实体所对应的关系合并，在被合并关系中增加属性，其新增的属性为联系本身的属性和与联系相关的另一个实体的码。
n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。
如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
如果与n端的关系模式合并则在n端实体集中增加新属性，新属性由联系对应的1端实体集的码和联系自身的属性构成，新增属性后原关系的码不变。
一个m：
n联系转换为一个关系模式，与该联系相连的各实体的码以及联系本身具有的属性均转换为关系的属性，而关系的码为各实体码的组合。
每一实体转换成一个关系模式（带下划线的属性为码）
n
实体：
用户
对应关系模式：
用户表（登录名，密码）
n
个人资料
个人资料表（登录名，用户名，性别，出生日期，注册时间，电话，住址，E-MAIL，头像）
头衔
头衔表（头衔编号，头衔名称，描述）
班级
班级表（班级编号，班级名称，创建者，创建日期，所属学校）
学校
学校表（学校编号，学校名称）
留言
留言表（留言编号，留言内容，留言人，留言日期，修改日期，所属班级编号）
相片
相片表（相片编号，相片名称，上传人，上传日期，相片路径，相片大小）
评论
评论表（评论编号，评论人，评论日期，评论内容，评论相片，所属班级）
2）
每一m：
n的联系转换为一个关系模式
联系：
登录
所联系的实体及关键字：
用户（登录名），头衔（头衔编号），班级（班级编号）。
用户班级表（登录名，班级编号，头衔编号）
相册
班级（班级编号），相片（相片编号）。
相册表（班级编号，相片编号）
校友录总系统的E-R图：
我的系统E-R图如下：
用户与留言之间的E-R图：
好友管理分析e-r图：
网络通讯E-R图：
网络管理E-R图：
系统信息E-R图：
总结：
概念设计的结果得到一个与计算机、软硬件的具体性能无关的全局概念模式。
本次开发校友录系统需求分析结束后，我收获很多感触也很多。
在整个项目开始前，这次项目一开始我们就把整个项目的流程浏览了一次，大概有了一次初步的设计过程。
首先，利用了之前所学的知识制作了数据库，这一步对我们来说都是很轻松的。
接着开始了这个校友录系统整个布局，制作相应的按钮搜索图片，添加相应的控件，一路下来都还是比较顺利的由于这个项目没有什么固定的板式，我参考了之前所学的开发BBS论坛和新闻两个项目，其基本功能有很多的一致性。
其次，开始配置数据库，编写代码，在此过程中我也遇到了很多问题，尤其是在开发日志显示、查看、回复、发表页面出现了很多错误比如代码编写错误、未引用命名空间等等。
这次的开发系统功能相对复杂，需要自己编写代码，在同学的帮助自己的细心探索下还是顺利完成了数据库的配置。
最终整个开发页面在不断的完善也更新中告一段落。
升级会员 