二手房交易信息管理系统Word下载.doc
- 文档编号:2985183
- 上传时间:2023-05-01
- 格式:DOC
- 页数:25
- 大小:1.25MB
二手房交易信息管理系统Word下载.doc
《二手房交易信息管理系统Word下载.doc》由会员分享,可在线阅读,更多相关《二手房交易信息管理系统Word下载.doc(25页珍藏版)》请在冰点文库上搜索。
二、管理员对功能的需求:
1.查询所有用户的信息
2.删除不合法的用户
3.添加商品
4.发布公告
系统功能结构图如图2-1所示。
图2-1二手房交易信息管理系统功能结构图
2.2业务流程分析
2.2.1数据流图
根据以上分析,我们得出二手房交易信息管理系统数据流图如图2-2所示。
图2-2二手房交易信息管理系统数据流图
图2-3系统数据流图
2.3业务规则及约束分析
基于上述功能分析,二手房交易信息管理系统的业务规则及约束如下:
(1)所有用户均可搜索商品信息,但是只有注册用户才能够提交订单。
(2)每位用户由唯一的编号标识,注册编号由系统按照时间顺序自动生成。
(3)用户登录系统的账号为用户注册时输入的用户名称。
(4)系统管理员可以查看会员信息,但是不能增加和修改注册信息,必要时可以删除用户信息。
(5)系统管理员统一对系统中的数据维护。
(6)收购员只能进行商品收购登记及汇总。
(7)每个房子由唯一的房源编号标识。
(8)每个业务员由工作证号唯一标识。
(9)会员可以根据房源编号搜索房源信息。
(10)房屋居间服务合同需合同签订状态,即是否签订。
(11)用户可以查询自己的合同。
(12)一个买方可以购买或租赁多个房子。
(13)一个卖方可以提供多个房子。
(14)二手房中记录房源的状态。
(15)房屋居间服务合同有房源编号和是否签订共同决定。
三、概念结构设计
3.1确定实体集和属性
(1)买方实体集。
其属性有:
注册号、用户ID,真实姓名、密码、Email、地址、电话、注册时间(系统自动生成)、密保问题、密保答案等。
图3-1买方实体集
(2)卖方实体集。
图3-2卖方实体集
(3)二手房实体集。
房源编号、房源名称,所属区域编号、楼盘编号、建筑单位、户型编号、面积、楼层、单元、车库面积、装修状况、物业管理费、权属等。
图3-3二手房实体集
(4)管理员实体集。
管理员ID,管理员名,密码等。
图3-4管理员实体集
(5)业务员实体集。
工作证号、姓名、年龄、Email、地址、电话、服务区域等。
图3-5业务员实体集
(6)租赁订单实体集。
订单号、订单时间、订单人姓名、订单人电话、订单人地址、Email等。
图3-6租赁订单实体集
(7)购买订单实体集。
图3-7购买订单实体集
(8)房屋居间服务合同实体集。
房源编号、房源名称、甲方实际售价、建筑面积、权属、乙方联系电话、乙方身份证号、甲方联系电话、甲方身份证号、丙方(合同负责人)、是否签订等。
图3-8房屋居间服务合同实体集
(9)公告实体集。
主题、内容、公告时间、公告总数、房源总数等。
图3-9公告实体集
3.2确定联系集及属性
(1)买方和租赁订单之间的“登记1”联系集。
它是一对多的联系,其描述属性有:
真实姓名、电话、地址、Email。
(2)买方与购买订单之间的“登记2”联系集。
(3)买方与管理员之间的“管理1”联系集。
它是多对多的联系集,无描述属性。
(4)买方与业务员之间的“服务1”联系集。
它是多对一的联系集,无描述属性。
(5)买方与房屋居间服务合同之间的“签订1”联系集。
电话。
(6)买方与二手房之间的“需求”联系集。
它是一对多的联系,无描述属性。
(7)卖方与管理员之间的“管理2”联系集。
它是多对多的联系,无描述属性。
(8)卖方与业务员之间的“服务2”联系集。
它是多对一的联系,无描述属性。
(9)卖方与房屋居间服务合同之间的“签订2”联系集。
(10)卖方与二手房之间的“提供”联系集。
(11)业务员与二手房之间的“服务3”联系集。
区域编号。
(12)二手房与房屋居间服务合同之间的“签订3”联系集。
房源编号、房源名称、面积、权属。
(13)管理员与公告之间的“贴出”联系集。
3.3总体E-R图设计
根据以上分析,我们得出二手房交易信息管理系统总体E-R图如图3-16所示。
图3-10二手房交易信息管理系统总体E-R图
四.逻辑结构设计
4.1关系模式转换
根据以上分析得出的E-R模型进行关系模式转换,我们得出二手商品交易系统关系模式为:
(1)买方(注册号、用户ID,真实姓名、密码、Email、地址、电话、注册时间、密保问题、密保答案、工作证号)
(2)卖方(注册号、用户ID,真实姓名、密码、Email、地址、电话、注册时间、密保问题、密保答案、工作证号)
(3)二手房(房源编号、房源名称、所属区域编号、楼盘编号、建筑单位、户型编号、面积、楼层、总楼层、单元、车库面积、基础设施、装修状况、物业管理费、权属、注册号、注册号)
(4)管理员(管理员ID,管理员名,密码)
(5)业务员(工作证号、姓名、年龄、Email、地址、电话、QQ、服务区域)
(6)租赁订单(订单号、订单时间、订单人姓名、订单人电话、订单人地址、Email、注册号)
(7)购买订单(订单号、订单时间、订单人姓名、订单人电话、订单人地址、Email、注册号)
(8)房屋居间服务合同(房源编号、是否签订、房源名称、甲方实际售价、建筑面积、权属、乙方联系电话、乙方身份证号、甲方联系电话、甲方身份证号、丙方(合同负责人)、注册号、注册号)
(9)公告(主题、内容、公告时间、公告总数、房源总数、管理员ID)
(10)管理1(管理员ID、注册号)
(11)管理2(管理员ID、注册号)
(12)贴出(主题,管理员ID)Error!
Nobookmarknamegiven.Error!
Nobookmarknamegiven.
4.2关系表优化
经过以上分析,我们得出了二手商品交易系统的关系模式,进一步对其进行分析求精,系统关系模式不存在函数依赖并且满足BCNF范式。
4.3完整性约束
(1)买方关系模式的主键为注册号,其中注册号由5位字符组成,第一位为大写字母“E”;
(2)卖方关系模式的主键为注册号,其中注册号由5位字符组成,第一位为大写字母“E”;
(3)二手房关系模式的主键为房源编号,外键为注册号(买方及卖方),其中房源编号由5位字符组成,第一位为大写字母“G”,接着四位为流水编号;
户型编号只可以取1、2、3、4,代表四种户型;
单元只可以取1、2、3、4,代表四个单元;
装修状况取1、2、3,代表三种装修程度,即无装修、普通装修、精装修。
(4)业务员关系模式的主键为工作证号,其中工作证号由5位字符组成,第一位为大写字母“B”,接着四位为流水编号;
服务区域取1、2、3、4,代表四个区域。
(5)管理员模式的主键为管理员ID,其中管理员ID由5位字符组成,第一位为大写字母“A”,接着四位为流水编号。
(6)租赁订单关系模式的主键为订单号,其中订单号由5位字符组成,第一位为大写字母“L”,接着四位为流水编号;
外键为注册号(买方)。
(7)购买订单关系模式的主键为订单号,其中订单号由5位字符组成,第一位为大写字母“P”,接着四位为流水编号;
(8)房屋居间服务合同关系模式的主键为房源编号和是否签订,外键为注册号(买方及卖方);
丙方取1,即中介公司负责人。
(9)公告关系模式的主键为主题。
4.4用户子模式设计
将概念模型转换为全局逻辑模型后,还应该根据局部应用需求,结合具体DBMS的特点,设计用户的外模式。
目前关系数据库管理系统一般都提供了视图概念,可以利用这一功能设计更符合局部用户需要的用户外模式。
定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发。
由于用户外模式与模式是相互独立的,因此在定义用户外模式时可以注重考虑用户的习惯于方便。
包括:
(1)使用更符合用户习惯的别名。
在合并各分E-R图时,曾做了消除命名冲突的工作,以使数据库系统中同一关系和属性具有唯一的名字。
这在设计数据库整体结构时是非常必要的。
但对于某些局部应用,由于改用了不符合用户习惯的属性名,可能会使他们感到不方便,用视图机制可以在设计用户视图时重新定义某些属性名,使其与用户习惯一致,以方便用户。
但为了应用的规范化,也不应该一味地迁就用户。
(2)可以对不同级别的用户定义不同的视图,以保证系统的安全性。
所以针对不同级别的用户定义不同的外模式,以满足系统对安全性的要求。
(3)简化用户对系统的使用。
如果某些局部应用中经常要使用某些很复杂的查询,为了方便用户,可以将这些复杂查询定义为视图,用户每次只对定义好的视图进行查询,大大简化了用户的使用
1.对于买方建立如下视图
买方(注册号,注册时间)原因说明如下表:
表4-1
注册号
注册时间
便于二手房信息管理机构对用户的监管
便于二手房交易信息管理系统对注册用户进行统一协调
2.对于买方建立如下视图
表4-2
3.对于二手房建立如下视图
二手房(房源编号,面积,装修状况)原因说明如下表:
表4-3
房源编号
面积
装修状况
便于对二手房交易管理系统对房源统一管理
便于用户了解并匹配自己的需求
便于用户了解并匹配自己的需求及房源定价
4.对于管理员建立如下视图
管理员(管理员ID,管理员名)原因说明如下表:
表4-4
管理员ID
管理员名
便于二手房信息管理机构对管理员的监管
便于二手房交易信息管理系统对管理员进行统一协调
5.对于业务员建立如下视图
业务员(工作证号,姓名,电话)原因说明如下表:
表4-5
工作证号
姓名
电话
便于对二手房交易管理系统对业务员统一管理
便于用户对业务员的了解
便于用户与业务员的联系
6.对于租赁订单建立如下视图
租赁订单(订单号,订单时间,订单人姓名)原因说明如下表:
表4-6
订单号
订单时间
订单人姓名
便于系统对各订单进行分析和查找
便于系统对各订单分类及查找
便于用户对自己信息的查找
7.对于购买订单建立如下视图
购买订单(订单号,订单时间,订单人姓名)原因说明如下表:
表4-7
8.对于房屋居间租赁合同建立如下视图
合同(甲方,乙方,丙方)原因说明如下表:
表4-8
甲方
乙方
丙方
便于对系统对各合同信息的查询
9.对于公告建立如下视图
公告(主题,内容,房源总数)原因说明如下表:
表4-9
主题
内容
房源总数
便于对二手房交易管理系统对公告统一管理
便于用户对公告的查询
便于用户了解房源的数量
4.5数据结构
根据系统分析和模块设计,本系统中个模块的数据项和数据结构如下:
(1)表名:
买方信息表
标识:
buyer
数据来源:
买方用户管理模块输入
表4-10买方信息表
属性名
存储代码
数据类型
字符长度/bit
是否允许为空
B_no
char
10
否
用户ID
B_id
真实姓名
B_name
密码
B_password
B_email
20
地址
B_add
电话
B_tel
B_time
密保问题
B_S_question
是
密保答案
B_S_answer
Work_no
(2)表名:
卖方信息表
seller
卖方用户管理模块输入
表4-11卖方信息表
S_no
S_id
S_name
S_password
S_email
S_add
S_tel
S_time
(3)表名:
二手房信息表
secondhouse
基础数据管理模块输入
表4-12二手房信息表
H_no
房源名称
H_name
所属区域编号
reg_no
楼盘编号
Item_no
建筑单位
Item_cop
户型编号
Stru_no
area
楼层
floor
单元
unit
车库面积
cararea
fitment
物业管理费
serverfee
权属
belong
(4)表名:
管理员信息表
administrator
公司内部信息管理模块输入
表4-13管理员信息表
A_id
A_name
8
A_password
(5)表名:
业务员信息表
businessman
表4-14业务员信息表
BU_name
年龄
BU_age
2
BU_email
BU_tel
BU_add
服务区域
(6)表名:
租赁订单信息表
leaseorder
售房信息管理模块输入
表4-15租赁订单信息表
L_no
L_time
订单人电话
订单人地址
(7)表名:
购买订单信息表
purchaseorder
表4-16购买订单信息表
P_no
P_time
(8)表名:
房屋居间服务合同信息表
contract
表4-17房屋居间服务合同信息表
实际售价
salemoney
乙方联系电话
乙方身份证号
B_idcard
甲方联系电话
甲方身份证号
S_idcard
bingfang
是否签订
signed
(9)表名:
公告信息表
announcementinf
登录模块录入
表4—18公告信息表
subject
公告时间
time
content
50
公告总数
A_sum
H_sum
(10)表名:
管理1表
表4—19管理1表
(11)表名:
管理2表
表4—20管理2表
(12)表名:
贴出表
表4—21贴出表
五、数据库建立
5.1建表
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 二手房 交易 信息管理 系统