二手房信息管理系统的数据库系统设计与实现

目录

1、 需求分析说明书 ................................................................................................................... 3

1.1 需求获取............................................................................................................................ 4

1.2 售方功能需求 .................................................................................................................... 4

1.3 买方功能需求 .................................................................................................................... 4

1.4 管理员功能需求 ................................................................................................................ 5

1.5 系统功能需求 .................................................................................................................... 5

1.6 系统角色与流程分析 ........................................................................................................ 6

参考文献 ....................................................................................................错误!未定义书签。

1、 需求分析

在当今的社会，自从楼房的商业化之后，楼房的交易买卖便一直是政府税收

的重中之重。从2007年开始，中国的楼市迎来的交易的黄金期，楼房的价格不

断的提升，楼房的数量也受价格的影响不断的增加，因此房产的买卖也渐渐发展

起来，特别是二手房交易市场，现在全国各大城市都出现了很多的二手房交易所，

来协助人们进行二手房的交易，因此本文以二手房交易市场现状为考察对象，设

计了二手房交易管理系统。首先对二手房交易管理系统的国内外研究现状进行了

分析，并对系统的开发背景进行了介绍，明确了二手房交易平台的意义，然后对

二手房交易市场进行了需求获取与分析，以国内二手房交易的实际情况为背景，

对二手房交易系统进行了功能设计，对设计过程中使用的技术进行了描述，分别

对房产交易、房产信息以及房产的查询登记等功能进行了分析，并对房产管理过

程使用的数据格式以及数据类型进行总结，将这些数据信息映射到数据库，完成

了二手房交易管理系统数据库的概要设计工作。系统最终需要实现二手房交易管

理功能，可以实现二手房的信息录入、信息、查询以及登记等功能，同时还可以

对二手房交易的信息进行统计分析，为房产交易所制订下一步的房产交易计划提

供重要的参考资料。系统的开发需要满足了二手房交易管理的需求，同时还可以

为广大的房产交易用户提供房产卖买信息的发布功能，从而提高整个二手房交易

的效率。

在进行小组讨论之后，我们详细的设计了系统应该如何实现．并针对所设计

的系统对在设计过程中可能用到的数据进行了调查记录，以便于很好的支持系统

的设计与实现，争取连贯的设计本系统。

随着房产市场的持续升温以及互联网的迅速普及,传统的房产交易流程逐渐

从线下转向线上。购房者已经开始习惯从网络平台上寻找需要的房产信息,房产

经纪人也越来越重视通过网络进行房源推广和寻找潜在的客户。房产经纪人在搜

房网发布房源信息进行展示,购房者通过浏览搜房网寻找适合自己的出售信息,但

是房产签约交易仍然在线下进行,搜房网面临用户粘度小,核心竞争力不强的发展

问题。针对房产交易的网络化以及公司的发展壮大过程中所遇见的问题,迫切需

要一个房产交易平台系统提供房客源管理和在线交易等功能来实现线上房产交

易闭环,增强公司的核心竞争力。本系统按照实际业务需求进行设计,使用

技术,基于.NET FrameWork框架进行开发,数据存储使用微软的

SQLServer数据库实现。在本文中详细阐述了系统的需求分析、模块划分,功能设

计以及最终的系统实现。针对系统的特点决定使用B/S模式开发系统,部署时使

用分机房多机部署方案,在前端架设Nginx服务器进行负载均衡处理,数据层使用

Memcache缓存减轻数据库服务器负载压力,并提高站点访问速度。系统经过测试

部署上线后:业主可以通过系统管理自己的房源信息,购房者可以进行签约并查看

交易进度,经纪人在线对房客源进行管理并通过系统完成整个交易流程。系统满

足了业主、购房者和房产经纪人三方需求,增强了搜房网的核心

1.1 需求获取

根据小组讨论结果，我们一致决定采用多种方式相结合的方式对二手房交易

管理系统进行需求获取，系统需求获取的步骤如下所示：

对二手房交易的历史信息进行获取，然后上网查阅相关资料，总结出二手房

交易管理系统的需求说明书．说明书包括系统的开发背景、二手房工作流程以及

图1.1 系统功能需求

统计报表等。

将形成的详细的需求说明以二手房交易所的用户视角进行查看，并及时的进

行修改，直到需求说明可以完成反映二手房管理的各方面工作内容为止。

为了对整个的系统需求分析有一个直观的了解，给出总体图如图1.1所

示。

1.2 售方功能需求

第一、二手房信息发布

对房产信息进行发布，以便买房者可以及时了解房产信息。卖房者经过房产

交易所的审核之后，卖方代其在系统发布卖房信息。

第二、对发布的二手房信息进行维护

本功能主要包括对房产信息输入、修改、更新、删除等操作。系统要想正常

的运行的话必须进行资料的录入，像是二手房的相关买卖信息的录入。在进行录

入后系统要对这些信息简单的分类和一些相关的处理，以便于购房者和买房者进

行交易。本功能是必要的，也是首要的。

1.3 买方功能需求

第一、购买二手房

本系统把房产交易的各个步骤以及交易时所应该遵循的各个规章制度进行

了存档，它会指导用户进行交易，在出现问题时会及时的通知用户来更正，直到

用户拿到房产证为止。

第二、二手房信息浏览

本系统实现的一个重要功能便是二手房信息浏览。在系统中的后台数据库中

存有大量最新的二手房的交易的信息供用户查询。而且本系统与网络相连，所以

可以及时的更新后台数据库中的信息，定期清除失效的信息等等。实现买房者对

房产类型的选择比较功能，例如可以选择不同的几处房产，然后进行统一比较。

1.4 管理员功能需求

第一、二手房信息核实

第二、买房违规处理

第三、卖房违规处理

除此之外，系统的管理者主要负责对系统进行维护和升级，他拥有最高的权限，他可以

对系统进行所有的操作。

1.5 系统功能需求

第一、安全性需求

由于系统要存储工作人员的信息以及客户、房产方而的信息，有些信息可能

涉从到个人隐私问题，必须对这类信息进行安全的存储，保证除了系统川户外其

它人不能查看到相关的信息。为此本系统使用了很多的安全性的措施进行信息的

安全保护，最重要的是权限的设置，不同的用户有不同的权限去操作不同的资源。

没有获得相关的权限是无法操作相关的资源的，从而达到保护系统安全性的各种

要求。

第二、可拓展性要求

我国房产交易正处在不断的改革的过程中，交易流程、交易文件等都可能会

发生变化，所以系统必须有较高的可拓展性，以便有新的功能要加入系统或系统

功能要发生变化时，可以花费较小的代价完成系统的功能扩展。

第三、易操作性要求

系统的最终使用者是房产交易所的工作人员，他们的计算机水平可能不是很

高，所以要求系统在功能设计方面满足易操作性的要求。只有设计出一个简单易

操作的良好的用户界面才能让使用者又快又准确的掌握自己想得到的信息。而且

从本系统的商业性上看，只有这样这个系统才可能有广泛的市场前景，才能带来

收益。

第四、差错处理的要求

由于房产交易所越来越多，信息的种类也不是固定的，对系统的需求获取也

不可能完全反映用户的需求，所以，系统可能会发生一些开发人员想像不到的异

常，为了保证系统在发生异常时可以正常工作，必须要求系统有差错处理能力，

使系统尽快恢复正常。

第五、可移植性要求

可移植性是指系统的一次开发，可以多次进行部署，并且部署与平台无关，

即跨平台性，移植性高的系统，可以不加修改或少加修改在多个平台上运行，从

而可以减少软件开发的成本。类似于自动收款机的运作模式。为此，本系统必须

符合可移植性的要求，可以随时随地的出来其他的信息。

第六、灵活性原则

大型的二手房交易场所往往都下设几家分所，并且工作人员还经常在外进行

工作，比如对房风进行考察以及带领买房者参观房屋等，还要及时的将客户的要

求反馈给交易中心，以便及时进行处理，因此，这就要要求系统必须有灵话性，

可以满足工作人员在外工作的需求。

第七、和谐界面的要求

系统开发出来之后的使用者是用户而不是程度开发人员，必须使用户明白系

统的功能是怎样实现的，并且系统要实现易操作性，除了本身的功能设计之外，

还和系统的界面设计有很大的关系，要求设计和谐的用户界面，指导用户高效的

使用系统。

为了实现以上的功能，本系统使用了账户的注册机制．每一个登录使用本系

统的用户必须要用自己的相关信息进行登记注册，这样一来不但方便了系统而

且也使得用户省去了很多查找信息的麻烦，当系统的资料库有了新的房产信息后

系统就会自动的提供给每个注册过的用户，以方便用户的浏览，及时的掌握最新

的消息。

1.6 系统角色与流程分析

综合市场分析和对客观世界的抽象，二手房市场存在四个实体：二手房、买

方、卖方、交易所。

这四类实体映射到二手房管理系统中分别为二手房，买方，卖方和系统管理

员。

各个实体以及实体间的联系如图1.2所示：

图1.2 系统E-R图

图1.3更细致的描述系统各实体之间的动态联系。

图1.3 系统数据流程图

二手房的卖家通过编辑二手房的表单信息发布二手房出售信息，系统管理员

对卖家发布的二手房信息进行核实，如审核通过，则可以正式发布出售信息，买

家浏览待出售的二手房信息，若由意愿则进行购买，买卖双方签订购房合同。

在买卖过程中，系统管理员能够实时对买卖双方的行为进行监控，保证二手

房交易的公平性。若买方或者卖方出现不公平行为，系统管理员可以介入协调，

并对违规的一方进行违规处理，禁止其在一段时间内在平台的买卖行为。

2、逻辑设计

2.1 关系图

2.2 关系表

关系表如下（引用字体表示外键约束）：

买方（买方编号，姓名，身份证号，联系方式，购买凭证，禁用原因，禁用期限，

禁用人）

卖方（卖方编号，姓名，身份证号，联系方式，发布权限，禁用原因，禁用期限，

禁用人）

二手房（二手房编号，地址，户型，价格，有效期，状态，，发布时间，

发布人

房产证明，，，被购日期）

核实人购买人

管理员（管理员编号，姓名，身份证号，薪酬）

交流（，，内容，时间, 发言标志）

买方编号卖方编号

查看（，，浏览日期）

卖方编号二手房编号

2.3 数据字典

2.3.1 关系表总览

表的中文名称 表的英文名称

buyer 买方信息表

seller 卖家信息表

house 二手房信息表

admin 管理员信息表

chat 交流联系表

see 查看联系表

2.3.2 买方表

数据 自 不为 主 外 检查

中文名 字段名 长度

类型 增 空 键 键 约束

买方编号 buy_id int

姓名 buy_name varchar 20

身份证号 buy_num char 18

联系方式 buy_tel varchar 15

购买凭证 buy_evidence varchar 20

禁用原因 buy_disreason varchar 255

禁用期限 buy_distime datatime

禁用人 ad_id int

√ √ √

√

√

√

√

√

2.3.3 卖方表

数据 自 不为 主 外 检查

中文名 字段名 长度

类型 增 空 键 键 约束

卖方编号 sell_id int

姓名 sell_name varchar 20

身份证号 sell_num char 18

联系方式 sell_tel varchar 15

发布权限 sell_issue char 1

√ √ √

√

√

√

√ √

禁用原因 sell_disreason varchar 255

禁用期限 sell_distime datetime

禁用人 ad_id int

√

2.3.4 二手房信息表

数据 自 不为 主 外 检查

中文名 字段名 长度

类型 增 空 键 键 约束

二手房编号 house_id int

地址 houe_addr varchar 50

户型 house_type varchar 10

价格 house_prince float

有效期 house_time varchar 20

状态 house_status varchar 10

发布人 sell_id int

发布时间 issue_time datetime

房产证明 house_evidence varchar 20

核实人 app_ad_id int

购买人 buy_id int

被购日期 sell_time datetime

√ √ √

√

√ √

√

√

√ √

√

√

√

√

2.3.5 管理员表

数据 自 不为 主 外 检查

中文名 字段名 长度

类型 增 空 键 键 约束

管理员编号 ad_id int

姓名 ad_name varchar 20

√ √ √

√

身份证号 ad_num char 18

薪酬 ad_salary float

√

√

2.3.6 交流表

数据 自 不为 主 外 检查

中文名 字段名 长度

类型 增 空 键 键 约束

交流序列号 chart_id int

买方编号 buy_id int

卖方编号 sell_id int

内容 chat_content varchar 255

时间 chat_time datetime

√ √

√ √ √

√ √ √

√

√

2.3.7 查看表

数据 自 不为 主 外 检查

中文名 字段名 长度

类型 增 空 键 键 约束

查看序列号 view_id int

买方编号 buy_id int

二手房编号 house_id int

浏览时间 view_time datetime

√ √

√ √ √

√ √ √

√

2.4 数据库创建

create database HouseSale

2.4.1 数据库创建语句

create table admin(

ad_id int identity(1,1) primary key ,

ad_name varchar(20) not null,

ad_num char(18) not null unique,

ad_salary float not null

)

2.4.2 买方表创建

create table buyer(

buyer_id int identity(1,1) primary key ,

buy_name varchar(20) not null,

buy_num char(18) not null unique,

buy_tel varchar(15) not null,

buy_evidence varchar(20) not null,

buy_disreason varchar(255),

buy_distime datetime,

ad_id int,

constraint ad_id_constr

foreign key(ad_id)

references admin(ad_id)

on delete cascade

on update cascade,

)

2.4.3 卖方表创建

create table seller(

sell_id int identity(1,1) primary key ,

sell_name varchar(20) not null,

sell_num char(18) not null,

sell_tel varchar(15) not null,

sell_issue char(1) not null,

sell_disreason varchar(255),

sell_distime datetime,

ad_id int,

constraint seller_ad_id_constr

foreign key(ad_id)

references admin(ad_id)

on delete cascade

on update cascade,

constraint sell_issue_check

check(sell_issue in ('Y','N'))

)

2.4.4 二手房表创建

create table house(

house_id int identity(1,1) primary key ,

house_addr varchar(50) not null,

house_type varchar(10) not null,

house_prince float not null,

house_time varchar(20) not null,

house_status varchar(10),

sell_id int not null,

issue_time datetime not null,

house_evidence varchar(20),

app_ad_id int,

buy_id int,

sell_time datetime,

constraint house_ad_id_constr

foreign key(app_ad_id)

references admin(ad_id)

on delete cascade

on update cascade,

constraint house_sell_id_constr

foreign key(sell_id)

references seller(sell_id)

on delete no action

on update cascade,

constraint type_check

check(house_type in ('一居室','二居室','三居室','四居室','五居室')),

constraint status_check

check(house_status in ('审核','出售','已出售'))

)

2.4.5 管理员表创建

create table admin(

ad_id int identity(1,1) primary key ,

ad_name varchar(20) not null,

ad_num char(18) not null unique,

ad_salary float not null

)

2.4.6 交流表创建

create table chat(

chat_id int identity(1,1) not null ,

buy_id int,

sell_id int,

chat_content varchar(255) not null,

chat_time datetime not null,

primary key (buy_id,sell_id),

constraint chat_buy_id_constr

foreign key(buy_id)

references buyer(buyer_id)

on delete cascade

on update cascade,

constraint chat_sell_id_constr

foreign key(sell_id)

references seller(sell_id)

on delete no action

on update cascade

)

2.4.7 查看表创建

create table see(

view_id int identity(1,1) not null ,

buy_id int,

house_id int,

view_time datetime not null,

primary key (buy_id,house_id),

constraint view_buy_id_constr

foreign key(buy_id)

references buyer(buyer_id)

on delete cascade

on update cascade,

constraint view_house_id_constr

foreign key(house_id)

references house(house_id)

on delete no action

on update cascade

)