精品广东工业大学中介机构管理系统毕业论文.docx
《精品广东工业大学中介机构管理系统毕业论文.docx》由会员分享，可在线阅读，更多相关《精品广东工业大学中介机构管理系统毕业论文.docx（35页珍藏版）》请在冰豆网上搜索。
精品广东工业大学中介机构管理系统毕业论文
（此文档为word格式，下载后您可任意编辑修改！
）
课程设计
课程名称_《管理信息系统》___
题目名称中介机构管理系统
学生学院管理学院
专业班级
学号
学生姓名____________
指导教师
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
5、应收集的资料及主要参考文献
1.杨军.基于JSP商品销售系统的实现与安全设计.盐城工学院学报（自然科学报）第21卷第3期2008.9
2.杨琳、何芳.商品房销售数据仓库的模型建立.计算机技术与发展.第16卷第11期2006.11
3.雷兰.商品房买卖纠纷及案例评析.科学出版社.2005.1
4.卢春雷、李雪梅、王莉、林旺.VisualFoxpro程序设计与应用.中国铁道出版社.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.3ERD导出一般关系模型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、SQLSERVER2000、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图
从上面ERD可得到售房登记关系，如下图：
售房登记关系：
登记
日期
物业名称
业主
经手
工号
地区
房产
类型
面积
总价
户型
楼层
外码
外码
主码
这样就会出现两个问题：
一是主码（复合码）太复杂，不便于查询；二是当一个业主有几套房子要买或租时，日期、业主、经手工号就要多次重复。
针对这个问题，我引进了联系虚体房屋出售单。
它虽不是实体，但它可以简化这个复杂的联系，这样就可以使用“售房单号”作为房屋出售单关系的主码。
对买房登记关系和交易关系也作同样的处理。
这样可得到下面的引进联系虚体后的ERD。
由初始联系实体图，引进联系虚实体、合并、修改后得出改进后的全局ER图，如下：
1
1
M
MM
M11*买房单号
*售房单号
M11
M
M
M
2.4.3ERD导出一般关系模型
ERD导出一般模型关系的四条原则：
原则一（实体转换为关系）：
ER图中的每一个独立实体变换为一个关系，其属性变为关系的属性，其主标识变为关系的主码。
原则二（从实体及其主从联系转换为关系）：
ER图中的从实体及相应的“的”联系变为一个关系，从实体的属性加上主实体关系的主码构成这个关系的属性。
其主实体关系的主码，在主从联系为一个对多联系时还要加上可把同一个主实体个体所对应的从实体个体区分开来，从实体的一组属性，作为改关系的主码，对子类实体可作类似一对多联系的从实体的转换。
根据以上的两个原则可得出数据储存初步构思的关系框架：
需房者关系：
需房者号
姓名
性别
年龄
地址
家庭人数
电话
主码
产权人关系：
产权人号
姓名
性别
年龄
地址
邮箱
电话
主码
业务员关系：
业务员号
姓名
性别
年龄
电话
所在分店
外码
主码
原则三（一对多联系转换为联系）：
1：
M联系通过在“多”实体关系中增加相联系的“1”实体关系的主码及联系本身的属性来表达。
其中“1”实体主码为外来码。
原则四（多对多联系转换为关系）：
M：
M联系转换成一个独立的关系，被联系实体关系的主码（作为外来码）和联系本身的属性作为该关系的属性，被联系实体关系的主码组成其复合主码。
楼房关系：
楼房
编号
物业名称
业主
地区
房产
类型
面积
装修状态
户型
楼层
外码
主码
交易关系：
交易
单号
产权人
客户
经手
工号
面积
房产
类型
地区
交易
时间
交易
金额
外码
外码
外码
主码
出售登记关系：
售房
单号
物业名称
业主
经手
工号
地区
房产
类型
面积
总价
户型
楼层
外码
外码
主码
买房登记关系：
买房
单号
需房者
经手
工号
户型
地区
楼层
面积
房产
类型
外码
外码
主码
2.4.4新的业务流程图：
经过以上对初始的业务流程图的分析，以及对实体联系图进行改造后，得出了下面的改造后的新业务流程图。
首先是产权人或需房者在网上或到门店登陆系统进行房源或需房查询，如果找到有适合自己需求的信息，则与业务员联系，再进行看房后，若满意则产权人、需房者和业务员三方进行初步协商，协商成功则进行合同的签定，接着业务员进行交易登记，若不成功也要进行不成功交易登记。
如果一开始就没有查询到合适自己需求的信息，则进行房源登记或需房登记，同时也进行产权人资料或需房者资料的登记。
经业务员审查信息是正确，汇总登记资料后，则在系统上发布信息。
新的业务流程图：
2.4.5数据流程分析
2.4.5.1根据新的业务流程图，和全局ER图，得出新数据流程图（DFD）:
图T：
图0：
图1为基本加工
图2：
图3：
图4：
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、容易修改：
当某个代码在条件、特点或代表的实体关
升级会员 