某某市房地产综合信息管理系统方案12章

第12章 房产综合信息管理系统数据库概念

模型

根据南京、长沙实地考察结果显示，他们主要面临的问题就是数据不集中，整个房产MIS 分成几个数据库，有SQLSERVER ，也有ORACLE ，运行在不同的服务器上。这样给现在的维护、数据采集等带来了很大的麻烦，有于系统已运行多年，想把它们统一起来需要造成很大的人力物力的投入。鉴于此情况加上**市房产局MIS 还是空白，我们一开始就设计出一个信息中心，一体化的数据结构。

● 全局统一的数据字典，统一的指标体系，统一的分类编码体系，并能保证数据存储、备份、传输、访问等的安全。

● 以大型数据库系统为依托，能提高大量数据的吞吐性能 ，保障整个系统管理规范化，数据的完整和可靠。

● 房产信息资源数据库系统的设计必须考虑到与相关业务系统的信息交到，提供统一的标准数据接口。

● 房产信息资源数据库系统进行统一管理、集中控制，实现网络互连（内外网），实现房产交易、大市场等的使用和信息共享，提高决策能力，有效地化解和防范数据遗失、被盗等风险。

§12.1 数据模式的设计

数据模式的设计分为两个阶段：规范化（Normalization ）的数据模式设计和非规范化（Denormalization ）的数据模式设计。

1. 规范化的数据模式设计

规范化的数据模式是关系型系统的理想设计目标。其设计步骤大致可分为以下几个方面：

● 实体（Entities ）的抽取 ----对应表

● 关系（Relationships ）的定义 ----对应主键、外部键 ● 属性（Attributes ）的定义 ----对应字段 规范化的数据模式应满足三个范式（INF/2NF/3NF）的要求：

● 第一范式（Sirst Normal Form:1NF）：实体中的每一个属性必须具有原子性， 不可再进行拆分；实体中不允许有多值的属性或重复的组存在；实体的每一个实例中，每一个属性只有一个对应值。

● 第二范式（Second Normal Form:2NF）：实体中，除被定义为主健的属性外，其它属性的存在必须依赖于作为主键的属性。

● 第三范式（Third Normal Form：3NF ）：实体中，非主键属性的存在不能依赖于其它非主键属性。

采用规范化数据模式设计的结果，是产生最小的表，最短的记录行。其实质是消除数据冗余。规范化数据模式具有以下优点：

● 没有冗余数据，节约存储空间；

● 由于表中不含多余的字段，记录行的长相对较短，一次I/0操作可以读取更多的记录，加快了数据检索、排序操作；

● 由于没有冗余数据，提高了数据一致性、完整性维护的效率； ● 整个数据模式的结构清晰，易于维护和修改。

2. 用非规范化（Denormalization ）的设计思想优化数据模式

现实当中出于对系统性能方面的考虑，经常采用非规范化的设计思想来优化数据库的设计。例如，在上一些数据容量很大的表上进行联接、排序操作时，公耗费大量系统资源，影响系统的整体效率。为了减少这类操作，可采用非规范化的设计思想。

优化的对象：规范化的数据模式。

作为非规范化设计的一个前提：在一组相关的表中，如果数据查询（Select ）操作的频率明显高于数据更新（Update/Insert/Delete）操作的频率，可以针对这样一组表采用非规范化的设计。

非规范化的设计思想可以在很大程度上提高系统的性能，尤其是查询方面的性能，但它并不是万能的。相反。它会带来一些负面影响：

● 增加了数据一致性管理、维护的复杂度； ● 需要额外的存储空间；

● 降低了数据变更（Update/Insert/Delete）操作的效率； ● 这种变动一般情况下是针对某类具体应用的。一旦应用发生改变，结构需做相关的调整，降低了系统设计的灵活性；

● 一方面，它可以简化代码设计；另一方，它也可能使代码设计更加复杂

3. 数据模式设计时需考虑的几个问题

为了确保表中每一条记录的唯一性，每个表都应该有一个主键（Primary Key ），主键的取值应尽量考虑采用系统自动分配的值（如：序列），可确保主键的唯一性。

为表中的字段选择合适的数据类型（如：Char 与Varchar2），定义合适的精度范围。

采用约束（Constraints ）机制来维护表自身数据的一致必一、完整性，降

低管理、维护的复杂度。

表与表之间的引用完整性约束，通常情况下是通过定义外部键（Foreign Key ）来完成的。当相关字段的内容发生变更时，系统自动执行引用完整性的检查。在变更操作频繁的情况下，这种检查往往会消耗大量的系统资源，可考虑取消外部键的定义，用手工方式来维护表与表之间的引用完整性。

数据库设计时充分考虑面向GIS 设计原则、房产预警预报和产籍管理系统大量数据的存储。

● 房产GIS 主要提供用户网上快速查询、精确定位，并提供图、声、像等多媒体数据库存储及快速下载；

● 采用GIS 技术实现房产分幅图，分层图、分户图一体化管理，实现由图查文、由文查图、图上查封、注销登记等图上作业；

● 正确快捷的编丘编幢功能、集成分层分户图绘制及面积计算分摊功能；

虽然目前**市房产局GIS 系统不是考虑重点，但在设计数据库模型时我们需要根据上面三点科学的以数据库进行建模。

对于数据量非常宠大的表或短期内数据的增长速率非常快的表（比如产籍档案的数据录入），考虑采用分区技术（Partitions ）。分区技术是指在表的内部依据一定的规则（如：按地理位置或年月），将数据划分为几个子集，分别存储。它是一种对数据进行纵向分割的技术，对外表现为一个逻辑实体，内部各子集（分区）之间相对独立。

分析表本身的技术特点（如：是静态表/动态表、查询密集型/变更密集型等）和数据量的大小、数据的增长速率，为表设计适当的物理分布策略和存储参数，提高I/O效率，避免存储空间的动态分配，减少存储碎片，消灭记录行的动态迁移。

12.1.1 数据访问途径的设计

为提高系统的运行效率，数据访问途径的设计至为关键。有四种数据存储组织结构的设计直接影响数据的访问途径：Cluster,Hash Cluster,B*-Tree Index

和Bitmap Index。其中，基于B*-Tree的索引是最常用的数据访问途径。

考虑不同的应用类型和系统资源的利用情况，对数据的访问有不同的策略：OLTP 类的应用中，利用索引可以明显提高系统的运行能力；在BATCH 、OLAP 类的应用中，利用FULL Table Scan的数据访问方式效率更高。

一般而言，一次性检索出的数据量超过表中的数据总量的20％时，选择FULL Table Scan的数据访问方式效率更高。

12.1.2 索引设计原则

索引设计中的几个原则：

● 数据量小（如：记录数少于250条），并且很少用于联接操作的表不为其设计索引；

● 数据变更频繁的表不适合创建过多的索引；

● 为数据随机分布的表创建索引，可以有效提高数据的检索效率 ● 索引有较高的访问频率，在进行物理存储设计时应合理分布（如：创建索引表空间和数据表空间，并将两者分布在不同的磁盘上等），并为其设计合适的存储参数。

根据以上要求和近一个多月的实地调研，我们做出了**市房地产信息系统整个数据库概念模型。

12.1.3 数据结构动态调整与修改

当某一表其中一个字段发生改变时，我们可以在作很小的修改来调整整个系统的正常运行。我们采用J2EE 体系，STRUTS 架构，MVC 模式能很好的处理这方面问题。整个数据库的连接在一个数据导航器类中，即使现在用的是ORACLE 数据库，后来改换成SQLSERVER 数据库，在整个数据库结构相同的情况下也不需要修改本房产管理系统（只需要在WSL 内建立一个同名POOL 和同名DataSource 即可），某一表内的所有字段或部分在STRUTS 的VO 内实现，某一表结构发生改变时只需要修改此VO 类文件，然后对此类文件重新编译即可。在流程动态定制那一节内，我们给用户做了可对本系统的二次开发能力，管理员可通过本系统创建表，字段（字段的类型、长度、精度等

也由用户自己定制）。详细情况见7.11节。

§12.2 房地产系统与其他系统的联系

（图12-1）

房产局信息系统组成及与外部系统的接口

（图12-1）

§12.3 存量房业务数据概念模型

存量房业务数据概念模型

§12.4 房地产市场数据概念模型

房地产市场：企业和项目数据库概念模型

房地产市场：其它业务库概念模型

§12.5 知识库与行政办公数据概念模型

知识库概念模型 行政办公库概念模型

其他系统

§12.6 系统库数据概念模型

系统库概念模型

业务系统

§12.7 字典库数据概念模型

词典库模型

业务系统