某某房地产综合信息管理系统方案.docVIP

房产综合信息管理系统数据库概念模型 根据南京、长沙实地考察结果显示，他们主要面临的问题就是数据不集中，整个房产MIS分成几个数据库，有SQLSERVER，也有ORACLE，运行在不同的服务器上。这样给现在的维护、数据采集等带来了很大的麻烦，有于系统已运行多年，想把它们统一起来需要造成很大的人力物力的投入。鉴于此情况加上**市房产局MIS还是空白，我们一开始就设计出一个信息中心，一体化的数据结构。 全局统一的数据字典，统一的指标体系，统一的分类编码体系，并能保证数据存储、备份、传输、访问等的安全。 以大型数据库系统为依托，能提高大量数据的吞吐性能 ，保障整个系统管理规范化，数据的完整和可靠。 房产信息资源数据库系统的设计必须考虑到与相关业务系统的信息交到，提供统一的标准数据接口。 房产信息资源数据库系统进行统一管理、集中控制，实现网络互连（内外网），实现房产交易、大市场等的使用和信息共享，提高决策能力，有效地化解和防范数据遗失、被盗等风险。 数据模式的设计 数据模式的设计分为两个阶段：规范化（Normalization）））））） 由于表中不含多余的字段，记录行的长相对较短，一次I/0操作可以读取更多的记录，加快了数据检索、排序操作； 由于没有冗余数据，提高了数据一致性、完整性维护的效率； 整个数据模式的结构清晰，易于维护和修改。 2. 用非规范化（Denormalization）））））））采用GIS技术实现房产分幅图，分层图、分户图一体化管理实现由图查文、由文查图、图上查封、注销登记等图上作业正确快捷的编丘编幢功能、集成分层分户图绘制及面积计算分摊功能）Scan的数据访问方式效率更高。 一般而言，一次性检索出的数据量超过表中的数据总量的20％时，选择FULL Table Scan的数据访问方式效率更高。 索引设计原则 索引设计中的几个原则： 数据量小（如：记录数少于250条），并且很少用于联接操作的表不为其设计索引； 数据变更频繁的表不适合创建过多的索引； 为数据随机分布的表创建索引，可以有效提高数据的检索效率 索引有较高的访问频率，在进行物理存储设计时应合理分布（如：创建索引表空间和数据表空间，并将两者分布在不同的磁盘上等），并为其设计合适的存储参数。 根据以上要求和近一个多月的实地调研，我们做出了**市房地产信息系统整个数据库概念模型。 数据结构动态调整与修改 当某一表其中一个字段发生改变时，我们可以在作很小的修改来调整整个系统的正常运行。我们采用J2EE体系，STRUTS架构，MVC模式能很好的处理这方面问题。整个数据库的连接在一个数据导航器类中，即使现在用的是ORACLE数据库，后来改换成SQLSERVER数据库，在整个数据库结构相同的情况下也不需要修改本房产管理系统（只需要在WSL内建立一个同名POOL和同名DataSource即可），某一表内的所有字段或部分在STRUTS的VO内实现，某一表结构发生改变时只需要修改此VO类文件，然后对此类文件重新编译即可。在流程动态定制那一节内，我们给用户做了可对本系统的二次开发能力，管理员可通过本系统创建表，字段（字段的类型、长度、精度等也由用户自己定制）。详细情况见7.11节。 房地产系统与其他系统的联系 （图12-1） （图12-1）  存量房业务数据概念模型 房地产市场数据概念模型   知识库与行政办公数据概念模型  系统库数据概念模型  字典库数据概念模型