学位论文-—广东工业大学中介机构管理系统课程设计.doc

中介机构管理系统

课 程 设 计

课程名称_ 《管理信息系统》___
题目名称 中介机构管理系统
学生学院 管理学院
专业班级
学 号
学生姓名_____ _______
指导教师

2011年12 月 03日

广东工业大学课程设计任务书

题目名称
中介系统研究与开发
学生学院
管理学院
专业班级
工商2
姓 名

学 号

一、课程设计的内容
通过调查商品房销售的现状业务流程的基础上，应用 MIS课程所学的知识，设计一个电子商务在中介系统中的运用。内容包括：
1、电子商务在中介系统上应用的概述
2、中介管理信息系统分析
3、中介管理信息系统设计
4、中介管理信息系统实现
5、中介管理信息系统系统运行与评价
6、中介开发、运行后的心得、体会与收获
二、课程设计的要求与数据
综合运用信息管理与信息系统专业所学习的知识和技能，进调查评价房屋中介现有的业务流程，运用电子商务的知识和技术，在现代原理与方法的指导下，在计算机网络平台上，进行房屋中介的业务流程再造，在此基础上完成系统开发，撰写设计报告。
技术方面应用VFP技术设计开发的房屋中介系统。
要收集房屋中介业务流程中用到的主要数据资料，包括相关的中介信息、员工信息资料以及相关客户的信息资料等，并尽可能参与实际业务操作来收集数据资料，设计测试数据和系统试运行数据资料。
三、课程设计应完成的工作
1、研究房屋中介与客户关系管理理论、方法与技术，并撰写综述
2、了解能应用到房屋中介系统的现代管理技术，并撰写综述
3、明确房屋中介系统的用户需求，对系统的开发进行可行性分析；完成结构化系统分析，得到由再造后的业务流程图、实体联系图、数据流图和功能层次图为主的房屋中介管理系统逻辑模型。
4、依据逻辑模型完成系统总体设计，完成详细设计，得到房屋中介管理系统实施方案。
5、应用VFP技术设计开发房屋中介系统的实现.
6. 在此基础上，总结上述各项工作和系统研究与开发的心得、体会与收获，撰写信息系统开发设计报告。
四、课程设计进程安排
序号
设计各阶段内容
地点
起止日期
1
系统分析工作
学校
10.20-10.25
2
系统的总体设计
学校
10.26-10.30
3
系统的详细设计与开发
学校
11.1-11.9
4
系统的调试、实现，并完成报告初稿
学校
11.10-11.13
5
参考指导教师意见，完善系统并修改报告
学校
11.14-11.15
6
提交报告修改稿，指导教师审核修改稿
学校
11.16-11.17
7
学生演示系统
学校
11.18

五、 应收集的资料及主要参考文献
1. 杨军.基于JSP商品销售系统的实现与安全设计.盐城工学院学报（自然科学报）第21卷第3期2008.9
2. 杨琳、何芳.商品房销售数据仓库的模型建立.计算机技术与发展.第16卷第11期2006.11
3. 雷兰.商品房买卖纠纷及案例评析.科学出版社.2005.1
4. 卢春雷、李雪梅、王莉、林旺.Visual Foxpro 程序设计与应用.中国铁道出版社.2005.1
5. 邵兵家等. 客户关系管理. 清华大学出版社，2004.5
6. 李洪涛. 面向中小家电企业进销存管理系统的设计与开发.2010.4
7. 徐永江. 信息系统开发过程中常见的思想问题与对策分析. 《 湖北农机化 》, 2008. 4

发出任务书日期：2011年 10月 20 日 指导教师签名：刘高勇
计划完成日期： 2011 年 11月 10 日 基层教学单位责任人签章：
主管院长签章：

房产中介机构管理系统

目录
1. 前言概述 5
2. 系统分析 5
2.1 用户需求分析 5
2.2 可行性研究 6
2.2.1 技术层面上的可行性： 6
2.2.2 经济层面上的可行性： 6
2.2.3 社会层面上的可行性： 7
2.3 现状调查 7
2.3.1组织机构调查 7
2.3.2 工作现状调查 8
2.3.3 信息需求调查分析 10
2.3.4 现状评价： 11
2.4 目标分析 11
2.4.1导出基本项 11
2.4.3 ERD导出一般关系模型 16
2.4.4 新的业务流程图： 19
2.4.5 数据流程分析 20
2.4.6 功能层次图 24
3.总体设计 25
3.1 总体设计 25
3.1.1. 一般关系模型设计：于系统分析中的初步构思一样。 25
3.1.2. 处理功能总体结构设计： 25
3.1.3 系统平台的总体结构设计（略） 26
3.2 详细设计 26
3.2.1 代码系统设计 26
3.2.2 系统平台具体设计： 27
3.2.3 数据库结构的具体设计： 28
3.2.4 模块设计 31
4.系统实现 31
4.1 数据库表结构的建立与数据输入： 32
4.2 应用程序设计与测试： 37
5．系统运行 38
5.1系统操作使用的简要说明： 38
5.2 运行系统并打印报表 38
6. 系统评价 48

1. 前言概述
这个系统是为房地产经纪公司服务的，房地产经纪公司是一家专业集房地产咨询、租赁、买卖的专业代理公司。公司业务包括中介代理（住宅部、商铺部、写字楼部），还包括专业咨询（房屋导购、按揭贷款、投资分析）等，提供专业投资置业咨询顾问服务。
系统的基本任务有：房源信息管理：主要是完成录入新房源信息、浏览所以房源、维护房源信息和查询房源信息这几个任务。需求信息管理：主要是求购和求租信息的录入、维护和查询。客户信息管理：包括了录入客户资料、维护客户资料和查询客户资料这几个任务。交易记录管理：包括了录入新交易记录、统计交易情况和查询交易记录这几个任务。
系统的主要任务主要是市场部调研员手工输入得到的大量房源信息和需求信息，以及客户的相关信息。然后销售部进行交易的处理和交易数据的输入。系统能自动的统计、查询和打印相关报表。
而这个系统的开发目的主要是让公司通过使用房产中介管理系统，使得公司的管理更加系统化、规范化和自动化了，而且能使资源更加合理的配置，能缩短了工作时间，提高了客户满意度与成功率，更能节约资源和提高工作效率和公司效益。
2. 系统分析
2.1 用户需求分析
现公司使用的都是中介管理系统是人工系统，数据的输入、数据的分类汇总、数据的查询和报表的制作及打印等工作都是人工操作。由于公司业务频繁，单证票据处理量大，而且月末的交易汇总的大量工作使得公司的运行负担太重，效率太低，且数据管理较为混乱。所以原始的人工系统已经满足不了业务量的大增和公司管理规范的需求了，开发新的计算机管理系统是迫不及待的首要工作。综上所述，要求新系统通过原始数据的输入，能实现自动更新数据，及能实现多功能的查询，汇总和打印相关报表，从而使公司的管理更加系统化、规范化，更能节约资源和提高工作效率和公司效益。
2.2 可行性研究
现在需要开发一个房产中介管理系统，从而使公司的运行效率更高，成本更低、效益更好。 现在提供三个解决方案：
1、仍旧维持原来的旧系统，对旧系统进行修改与升级，这样投入的人力、资金会比较少，但这只是对旧系统的修补，而未着手与建立新系统，这样公司的问题并不能得到很好的解决。
2、为公司建立一个较大的管理系统，成立专门的研究小组，在短期内实现新旧系统的更换，另外更换一些员工，请些既有房产中介业务经验又有计算机网络知识的人员，这样短期内就能取得效益，但是公司要投入大量的人力和资金。
3、由于公司较小，所以可以在不影响公司平时正常运营的情况下，逐渐地开发一个较小的但较适合于中小型公司的系统，虽然短期内很难取得效益，但这样公司需投入的人力资金都较少，而且是着眼于长远效益的。
所以，实行第三个方案是比较合适的。
这一系统是一个中小型的数据库系统，可利用Oracale、SQL SERVER 2000、VFP等工具开发。现在从技术、经济和人文社会这三个层面来评价论证用VFP开发本系统的必要性、可能性和有益性。
2.2.1 技术层面上的可行性：
（1） 公司现全是手工操作，而计算机使用太少，使得工作效率太低，有碍于公司的发展。
（2） 通过适当的资金投入，人员培训和硬软件设备的投入，可适应用VFP该系统开发和运行管理的要求。
（3）用VFP开发该系统，操作及实现比较简单易懂，且能满足用户需求，能提高公司的工作效率和使资源合理分配。

2.2.2 经济层面上的可行性：
（1）手工操作已不适应于公司业务量的增长，若不及时开发新系统，必将影响公司的高效运行，必将现状公司的经济效益的提高。
（2）用VFP开发该系统，所需的自己、人力和技术等资源较少，经济上是可能的。
（3）使用该系统后，公司运行管理将会较为合理、规范，将会产生长期的经济效益。

2.2.3 社会层面上的可行性：
（1）该业务与客户、与外界交流较多，若系统效率低，必将影响其社会效应以及会影响其业务量的增长。
（2）由于该系统开发和操作都比较简单，所需资源也较少，所以能得到领导和员工的支持，且相关人员也将能较快和较好的适应该系统。
（3）该系统的开发和使用，不仅能改善公司的管理秩序，且能提高公司的经济效益和社会效益，也能提高公司对顾客的服务质量，让客户更满意。

2.3 现状调查
2.3.1组织机构调查
现状组织结构图：
总经理办公室
销售部
市场部
财务部
行政部
培训部
一分店
二分店
三分店

2.3.2 工作现状调查
初始业务流程图：
产权人
业务员
房源登记

需房登记
核对信息
登记汇总表
需房者
介绍、看房
买卖协商、租赁协商
业务员
房屋出售合同
房屋租赁合同
登记交易
交易登记表
错误
分析核对资料
符合要求的
房源登记表
需房登记表
汇总登记表
正确
需房者
成功
签定合同协议
不成功
销售主管

首先是产权人或需房者到销售部业务员那里进行房源信息登记或需房信息登记，然后业务员对登记的房源登记表和需房登记表分析核对，然后对正确无误的汇总形成汇总表，进行人工分析核对资料，看看房源信息与需房信息是否有相匹配的，若有则业务员联系双方，然后陪同需房者去看房，如果需房者对此房满意则与产权人进行买卖或租赁的初步协商，如果双方的协商成功则产权人、需房者和销售部主管三方进行出售或租赁房屋合同的签定，然后业务员要进行交易记录，生成交易登记表；如果产权人和需房者双方协商不成，则业务员直接进行不成功的交易登记，最后交易登记表上交销售部主管。

2.3.3 信息需求调查分析
资料收集: 收集业务流程图中用到的各种相关单据、票证、帐簿、报表的原始资料。

用户信息表：
用户信息表
姓名
性别
电话
地址
备注

房源信息表：
房源信息表
物业名称
房主
房产类型
租售状态
装修程度
面积
户型
楼层
地区
总价
建成时间
电话
备注

需房信息表：
需房信息表
需房者
电话
地区
需房状态
户型
房产类型
面积
装修程度
楼层
备注

交易信息表：
交易信息表
交易类型
房产类型
房主
电话
需房者
电话
户型
面积
房产类型
楼层
装修程度
建成时间
交易时间
交易金额
地区
备注

2.3.4 现状评价：
该现在的系统由于是人工传送表单，且要经过的部门较多，使得信息处理效率低。而且要进行高效的查询很难实现，这很难满足客户的需求，从而会影响公司的经济效益。
2.4 目标分析
2.4.1导出基本项
原始数据基本数据项：
用户信息：姓名、性别、电话、地址、备注
房源信息：物业名称、租售状态、房产类型、地区、楼层、户型、面积、装修程度、总价、建成时间、房主、电话、备注
需房信息：需房状态、房产类型、地区、楼层、户型、面积、装修程度、需房者、电话、备注
交易信息：交易类型、户型、地区、楼层、房产类型、面积、装修程度、建成时间、交易时间、交易金额、房主、电话、需房者、电话、备注
汇总所有数据项，去掉重复的，得到以下基本项：
姓名、性别、电话、地址； 物业名称、租售状态、需房状态、房产类型、
地区、楼层、户型、面积、装修程度、总价、建成时间、房主； 交易类型、交易时间、交易金额。

设计ER图的基本原则：

原则1（确定实体）：能独立存在的事物，例如人、物、事、地、团体、机构、活动等等，在其有多个由基本项描述的特性需要关注时，就应把它作为实体。在该系统中涉及到的实体有：业务人、需房者、产权人、楼房。
原则2（确定联系）：两个或多个实体间的关联与结合，当需要予以关注时，应作为联系。实体间的联系可分为一对一、一对多、多对多三类。联系通常是某类行为动作，ERD中关注的是其状态与结果而非其过程。
原则3（确定属性）：实体的属性是实体的本质特征。实体应有标识属性（能把不同个体区
分开来的属性组），并指定其中一个作为主标识。联系的属性是联系的结果或状态。

业务员
业务员号
姓名
性别
电话
所在分店
年龄
产 权 人
编号
姓名
性别
电话
地址
邮箱
楼 房
楼房编号
房产类型
物业名称
楼层
面积
地区
装修状态
价格
需房者
需房者编号
姓名
性别
年龄
电话
地址
家庭人数

原则4（一事一地）：所有基本项在同一E-R图中作为属性要在且仅在在一个地方出现。

2.4.2 根据四个原则画出机构的初始ER图
楼房
产权人
需房者
业务员
买、租房登记
交易
出售、租房登记
N
N
M
K
K
M
M
M
编号
业主
地区
面积
房产类型
楼层
编号
业主
楼层
地区
房产类型
面积
编号
物业名称
房产
类型
交易金额
交易时间
交易类型
M
类型
类型

从上面ERD可得到售房登记关系，如下图：
售房登记关系：
登记
日期
物业名称
业主
经手
工号
地区

房产
类型
面积

总价

户型

楼层

外码
外码

主码

这样就会出现两个问题：一是主码（复合码）太复杂，不便于查询；二是当一个业主有几套房子要买或租时，日期、业主、经手工号就要多次重复。针对这个问题，我引进了联系虚体房屋出售单。它虽不是实体，但它可以简化这个复杂的联系，这样就可以使用“售房单号”作为房屋出售单关系的主码。对买房登记关系和交易关系也作同样的处理。这样可得到下面的引进联系虚体后的ERD。

由初始联系实体图，引进联系虚实体、合并、修改后得出改进后的全局ER图，如下：
年龄
性别
姓名

*业务员号
业务员

电话

所在分店

1
地址
1
邮箱
年龄
性别
经手
经办

姓名

电话
M
购买
*产权人号
买房登记单
M M
产权人

出售
房屋出售单
M 1 1 *买房单号
*需要者号
需房者

*售房单号
姓名
M 1 1
M
售房登记
卖出
年龄

买入
家庭人数
性别

地址

买房登记
电话

M
M
业主
物业名称
*楼房编号
房产类型
面积
户型
楼层
地区
M
楼房
交易时间
交易
面积
房产类型
交易金额
地区
*交易单号
交易单
M

2.4.3 ERD导出一般关系模型
ERD导出一般模型关系的四条原则：

原则一（实体转换为关系）：ER图中的每一个独立实体变换为一个关系，其属性变为关系的属性，其主标识变为关系的主码。

原则二（从实体及其主从联系转换为关系）：ER图中的从实体及相应的“的”联系变为一个关系，从实体的属性加上主实体关系的主码构成这个关系的属性。其主实体关系的主码，在主从联系为一个对多联系时还要加上可把同一个主实体个体所对应的从实体个体区分开来，从实体的一组属性，作为改关系的主码，对子类实体可作类似一对多联系的从实体的转换。
根据以上的两个原则可得出数据储存初步构思的关系框架：

需房者关系：
需房者号
姓名
性别
年龄
地址
家庭人数
电话

主码

产权人关系：
产权人号
姓名
性别
年龄
地址
邮箱
电话

主码

业务员关系：
业务员号
姓名
性别
年龄
电话
所在分店

外码
主码

原则三（一对多联系转换为联系）：1：M联系通过在“多”实体关系中增加相联系的“1”实体关系的主码及联系本身的属性来表达。其中“1”实体主码为外来码。

原则四（多对多联系转换为关系）：M：M联系转换成一个独立的关系，被联系实体关系的主码（作为外来码）和联系本身的属性作为该关系的属性，被联系实体关系的主码组成其复合主码。

楼房关系：
楼房
编号

物业名称
业主
地区

房产
类型

面积

装修状态

户型

楼层

外码

主码

交易关系：
交易
单号

产权人

客户
经手
工号
面积

房产
类型

地区

交易
时间

交易
金额

外码
外码
外码

主码

出售登记关系：
售房
单号

物业名称
业主
经手
工号
地区

房产
类型

面积

总价

户型

楼层

外码
外码

主码

买房登记关系：
买房
单号

需房者

经手
工号
户型

地区

楼层
面积

房产
类型

外码
外码

主码

2.4.4 新的业务流程图：
经过以上对初始的业务流程图的分析，以及对实体联系图进行改造后，得出了下面的改造后的新业务流程图。
首先是产权人或需房者在网上或到门店登陆系统进行房源或需房查询，如果找到有适合自己需求的信息，则与业务员联系，再进行看房后，若满意则产权人、需房者和业务员三方进行初步协商，协商成功则进行合同的签定，接着业务员进行交易登记，若不成功也要进行不成功交易登记。 如果一开始就没有查询到合适自己需求的信息，则进行房源登记或需房登记，同时也进行产权人资料或需房者资料的登记。经业务员审查信息是正确，汇总登记资料后，则在系统上发布信息。

新的业务流程图：

需房者
产权人
房源查询
需房查询
房源、需房登记
产权人、客户资料登记
买卖租赁协商
签订合同
销售合同
租赁合同
交易登记
成功交易登记表
未成功交易登记表
交易产权人资料
交易客户资料
房源表
需房表
产权人资料
需房者资料
资料
无合适的
成功
房源资料表
有合适的
介绍、看房
汇总登记资料
资料汇总表
不成功

2.4.5 数据流程分析
2.4.5.1 根据新的业务流程图，和全局ER图，得出新数据流程图（DFD）:

图T：
0
房产中介管理
产权人
客户

上级及
有关部
门
FT－1房源信息查询要求
FT－2需房信息查询要求
FT－11新信息库
FT－12交易记录

图0：
FT－1
1
查询
FT－2
满足
要求
S0-1房源查询结果
S0-2需房查询结果
3
交易
协商
S0-3 合同
不满足
要求
2
信息登记
FT-11
4
交易
登记
FT-12

图1为基本加工

图2：
产权人
客户
业务员
2.1
信息
登记
S2-2 需房表
S2-3 产权人资料
S2-4 客户资料
FT-11
2.2
整理
S2-1 房源表

图3：
S0-1
S0-2
3.1
介绍、看房
S3-1初步协议
3.2
签合同
S0-3

图4：
S0-3
4.1
交易
登记
S4-1 成功交易登记表
S4-2未成功交易登记
S4-3交易产权人资料
S4-4 交易客户资料
4.2
整理
FT-12

2.4.5.2 数据字典（DD）：

基本项表:
编号
项名
类型
长度
1
姓名
字符型
10
2
性别
字符型
2
3
电话
数字型
10
4
地址
字符型
20
5
物业名称
字符型
10
6
租售状态
字符型
8
7
房产类型
字符型
10
8
地区
字符型
40
9
楼层
数字型
4
10
房主
字符型
10
11
面积
数字型
8
12
装修程度
字符型
10
13
总价
数字型
10
14
建成时间
日期型
8
15
交易金额
数字型
8
16
交易类型
字符型
10
17
交易时间
日期型
8

数据储存：
编号
数据存储表名
写入
结构
读出
S0-1
房源查询结果
P1
房源号，结果单
P3.1
S0-2
需房查询结果
P1
房源号，结果单
P3.1
S0-3
合同
P3.2
房源号，合同号
P4.1
S2-1
房源表
P2.1
房源号
P2.2
S2-2
需房表
P2.1
房源号
P2.2
S2-3
产权人资料
P2.1
客户号
P2.2
S2-4
客户资料
P2.1
客户号
P2.2
S3-1
初步协议
P3.1
协议单
P3.2
S4-1
成功交易登记表
P4.1
交易编号
P4.2
S4-2
未成功交易登记
P4.1
交易编号
P4.2
S4-3
交易产权人资料
P4.1
客户号
P4.2
S4-4
交易客户资料
P4.1
客户号
P4.2

数据流表：
编号
数据流表名
来源
结构
去向
FT-1
房源信息查询要求
产权人

查询模块
FT-2
需房信息查询要求
客户

查询模块
FT-11
新信息库
业务部

上级
FT-12
交易记录
业务部

上级

2.4.6 功能层次图
房产中介管理系统

登记功能
查询功能
浏览功能
房源信息登记

需求信息登记

交易信息登记

客户信息登记

房源信息查询

需求信息查询

交易信息查询

客户信息查询

房源信息浏览
需求信息浏览
交易信息浏览
客户信息浏览

注：关于功能层次图的几点说明：
① 功能层次图只展示任务的分解，不涉及数据的流动。
② 只表示上层任务可由哪些子任务协同完成，不管顺序与调用。
③ 严格按层次画出，不同任务的相同子任务也分别重画并重编号。
④ 常伴随数据流程图的构思来绘制。

3.总体设计
3.1 总体设计
3.1.1. 一般关系模型设计：于系统分析中的初步构思一样。
3.1.2. 处理功能总体结构设计：
由数据流程图导出初始模块结构图有两种分析方法：
3.1.2.1 以变换为中心的分析
① 找出变换中心（主处理）、逻辑输入和逻辑输出。在数据流图中几股数据流的汇合处往往就是系统的变换中心。如果一时难以确定，则可以确定哪些数据流是逻辑输入和逻辑输出。方法是从物理输入端开始，逐步向系统的中间移动，直到达到一个再不能被作为系统输入的数据流（即与物理输入流相比，结构有真正变化的数据流）为止，则其前一个数据流就是系统的逻辑输入。同样，从物理输出端开始，逐步向系统的中间移动，也可以找到离物理输出端最远的但仍可视为系统输出（与物理输出流的结构是基本相同的）的那个数据流，它就是逻辑输出。对系统的每一股输入和输出，都可用上面的方法找出相应的逻辑输入和逻辑输出，而位于逻辑输入和输出之间的处理就是系统的变换中心了。不过有些系统只有输入和输出两部分而没有变换中心。
② 设计系统最上两层模块。在完成①之后，可以将整个数据流图反映的系统用一个模块来表示，这就是顶层主模块。然后将顶层主模块分解为三个子模块，即：将逻辑输入设计为一个向主模块提供数据的输入模块，将逻辑输出设计成一个输出主模块数据的输出模块，以及设计一个将逻辑输入变换成逻辑输出的主处理模块，也称主控模块。顶层模块起控制和协调下层模块作用，一般不做实质性的数据处理，在系统实现时常表现为一个控制性的功能选择菜单。
③ 设计中、下层模块。这一步仍然按自顶向下逐步细化的原则设计每个模块的下属模
块。输入模块的功能是向它的调用模块提供数据，所以它本身必定要有一个数据来源，因此输入模块可由两部分组成，一为接受输入数据，另一部分则将接受到的数据变换成其调用模块所需的数据。换言之，对于每一个输入模块，我们必须设计两个下层模块，一是输入模块，另一个是变换模块。同理，对于每一个输出模块，必须设计两个下属模块，一是变换模块，另一个是输出模块。这个设计过程可以由顶向下递归地进行，直至真正达到系统的输入端或输出端。
变换模块的分解没有一定的规则可遵循，必须根据数据流程图中具体的组成情况而定。另外，每设计出一个新的模块都要给它一个适当的名称，以能正确反映出该模块的功能为准。

3.1.2.2 以事务为中心的分析
它同样遵循由顶向下逐步细化的原则，先设计主模块，后设计相应于发射中心的输入模块，相应于集束中心的输出模块，相应于事务中心的事务调度模块，再为每一种类型的事务处理设计一个事务处理模块，然后为每个事务处理设计下面的操作模块，并为操作模块设计细节模块。每个操作模块可能被多个事务处理模块所共享，而成为共用模块。同样每个细节处理模块又可能被多个操作模块所共享而成为公用模块。在各类不同的实际问题中，可能有多个细节模块，也可能没有细节模块。

3.1.3 系统平台的总体结构设计（略）

3.2 详细设计
3.2.1 代码系统设计
代码设计的基本原则：
1、唯一确定性：每一个代码都只代表唯一的实体或属性。
2、标准化与通用性：国内外有关的编码标准是代码设计的重要依据。另外，系统内部使用的同一种代码应做到统一，代码的使用范围越大越好。
3、简明性：代码必须简单明了，短小精悍。但必须以有利于对数据统计、汇总、分析等操作为宜。
4、稳定性核可扩充性：代码系统一旦制定出来并应用到系统中去，要有相对的稳定性，一般考虑3～5年的使用期限。同时也要考虑系统的发展和变化，当增加新的实体或属性时，可直接利用源代码加以扩充，而不要重新改变代码系统。
5、容易修改：当某个代码在条件、特点或代表的实体关系改变时，容易修改，也要方便系统的初始化。
6、满足系统要求，便于记忆和使用：例如，会计科目、一级科目代码国家已统一规定，明细科目（二级、三级科目等）的编码位数及方法，则要根据业务处理要求，核算方法、报表要求、管理要求以及计算机处理特点和会计人员的记忆等因素全盘考虑，从而满足新系统的要求。如果代码含有逻辑意义，则有利于记忆。
房源号
客户号
交易号
顺序码
顺序码
顺序码
层次码
1
1
01
2
2
02
3
3
03
.
.
.

.
.
.
.
.
.
.
.

3.2.2 系统平台具体设计：
公司部门内部局域网采用以太网的结构。物理上由路由器、服务器、工作站和操作终端通过集线器形成星型结构共同构成局域网。
具体网络布局图如下：

INTERNET
防火墙
理由器

交换机

3.2.3 数据库结构的具体设计：

完整性说明：DB的完整性是指数据的正确性和相容性。在数据库设计中要根据数据库中存储的数据的语义信息，结合具体DBMS确定其各个级别的各种完整性要求。
A、字段（属性）级的完整性：通过在数据库表结构中增加字段完整性行，可以在该行的有字段完整性要求的字段所对应的单元格中指明“非空”来规定该字段不能取空值；标注①、②…等标号，再在框架下部说明中的字段完整性说明中对相应标号列出具体要求。VFP中对字段完整性要求可以有如下内容：验证规则――字段值必须满足的条件，出错信息――违反规则时指出错误的提示信息，缺省值――没有输入时字段的自动取值；此外，还可有字段的长名与注释，字段的输出显示的标题、样式，字段的输入格式（掩码）等。
B、记录（元组）级完整性：在框架下部说明中的记录完整性说明中列出具体要求。VFP中对记录完整性要求可以有如下内容：①记录验证，包括：验证规则――同一记录不同字段取值之间要满足的条件，出错信息――违反验证规则时显示的提示信息；②更新检错触发器，包括：插入触发器――插入或追加记录时被触发，要求记录满足该触发条件，修改触发器――修改记录时被触发，要求对记录的修改必须满足该触发条件，删除触发器――删除记录时被触发，只有满足该条件的记录才能被删除。
C、表（关系）级完整性：包括函数依赖约束、实体完整性约束、统计约束。函数依赖约束主要是在数据库设计中通过规范化分解到BCNF或3NF，然后在关系模式定义中确定主码，再由DBMS保证主码取值不能重复来保证，在优化中降低了关系的规范化程度后，就一定要由DBA或应用程序员设计输入程序与修改程序（而不是DBMS提供的系统输入工具）来完成数据的输入与修改，这些程序中要有保证函数依赖约束的能力。实体完整性是指主码不能取空值，VFP是在字段完整性行中指定的。统计约束是一个字段值与关系中多个记录的多个字段的统计值之间要满足的条件，这也是通过专门设计的输入或修改应用程序来控制的。后面两种约束要在表框架的完整性说明的表级完整性中具体规定。
D、参照完整性（RI）：两个不同的数据库表（关系）的记录（元组）间的对应关系，主要指在建立父表主码到子表外码的永久关联的基础上，确定子表记录与相关联的父表记 录之间的对应规则。设计参照完整性首先要画出数据库表间的永久关联图。

各数据库标的具体框架如下所示：
房源信息表：
列名
数据类型
宽度
可否为空
房屋编号
数字型
4
否
物业名称
字符型
10
否
业主
字符型
8
否
地区
字符型
20
否
房产类型
字符型
10
否
面积
数字型
8
否
总价
数字型
10
否
户型
字符型
10
否
楼层
数字型
4
否
销售状态
字符型
6
否

需房信息表：
列名
数据类型
宽度
可否为空
记录号
数字型
4
否
需房者
字符型
10
否
房产类型
字符型
10
否
户型
字符型
10
否
地区
字符型
20
否
楼层
数字型
5
否
面积
数字型
10
否
总价
数字型
10
否

交易信息表：
列名
数据类型
宽度
可否为空
交易编码
数字型
4
否
房产类型
字符型
10
否
户型
字符型
10
否
地区
字符型
20
否
楼层
数字型
5
否
面积
数字型
10
否
交易时间
数字型
8
否
交易金额
数字型
10
否
房主
字符型
10
否
需房者
字符型
10
否

客户信息表：
列名
数据类型
宽度
可否为空
客户号
数字型
2
否
姓名
字符型
8
否
性别
字符型
2
否
年龄
数字型
2
否
地址
字符型
20
否
电话
数字型
10
否

员工信息表：
列名
数据类型
宽度
可否为空
员工号
数值型
2
否
姓名
字符型
10
否
性别
字符型
2
否
年龄
数值型
2
否
所在分店
字符型
10
否

3.2.4 模块设计
进入用户菜单

房源信息管理
需求信息管理
交易记录
客户信息
出售信息管理
出售信息查询
出租信息管理
出租信息查询
求购信息管理
求购信息查询
求租信息管理
求租信息查询
显示欢迎界面
启动表单
输入用户名和密码
退出系统

4.系统实现
4.1 数据库表结构的建立与数据输入：
数据库表结构的建立：
create table 房源信息表（房屋编号N（4），物业名称C（10），业主C（8），地区C（20），面积N（8），楼层N（4），租售状态C（6），备注M（4））
create table 需房信息表（需房者C（10），房产类型C（10），地区C（20），面积N（10），备注M（4））
create table交易信息表（交易编码N（2）,房产类型C（10），地区C（20），面积N（10），交易时间D（8），房主C（10），需房者C（10））
c reate table客户信息表（姓名C（10），性别C（2），年龄N（2），地址C（20），电话N（20））
create table 员工表 （员工号 C (10), 姓名 C （8），年龄N（2），职务 C（10），电话N（20），地址 C（20），所在分店 C（10）
系统命令执行结果的数据库表结构及其关联图：

参照完整性：

房源表：