知网查重论文样例--基于Java Web的房地产销售系统数据库设计
数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。
本系统的整体数据库表设计如下。
图4.9. 房地产销售系统整体数据库图
通过整体数据库图我们能看到系统本身共有11张数据库表，其中相关关系主要围绕着房源信息和客户信息，数据库表之间通过外键相互关联从而保证了数据表的关系与真实世界之间的一致性。
(1) 房源信息管理模块
本模块涉及两张数据表分别是楼房信息和房屋信息，分别如表4.1和表4.2所示。
表4.1 楼房表清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 楼房编号 | buildingID | varchar(10) | Y | N | 无 | 主键 |
| 国家 | country | varchar(20) | N | N | 无 | 所属国家 |
| 省 | province | varchar(20) | N | Y | 无 | 所在省份 |
| 市 | city | varchar(20) | N | N | 无 | 所在城市 |
| 动工开始 | beginTime | datetime | N | N | 无 | 动工开始日期 |
| 动工结束 | endTime | datetime | N | N | 无 | 动工结束日期 |
| 楼房名称 | name | varchar(50) | N | N | 无 | 楼房名称 |
| 占地面积 | area | double | N | N | 无 | 楼房占土地面积 |
| 具体位置 | positon | text | N | N | 无 | 具体位置如XX街 |
| 楼房说明 | statement | text | N | N | 无 | 楼房整体简介 |
| 开售时间 | saleTime | datetime | N | N | 无 | 楼房开盘时间 |
楼房表清单作为系统中的pojo类型，描述的是整栋楼房对象，其中在数据库存储中的作为唯一主键的是buildingID，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
表4.2 房屋表清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 房屋编号 | houseID | varchar(10) | Y | N | 无 | 主键 |
| 楼房编号 | buildingID | varchar(10) | N | N | 无 | 外键，参考楼房ID |
| 房间号 | number | integer | N | N | 无 | 房间号码 |
| 种类 | type1 | varchar(20) | N | N | 无 | 房源种类:房屋、店铺 |
| 房型 | type2 | varchar(20) | N | N | 无 | 房源类型：几室几厅 |
| 说明 | statemetn | varchar(20) | N | N | 无 | 房间说明 |
| 面积 | area | double | N | N | 无 | 房间面积：xx平米 |
| 楼层 | floor | integer | N | N | 无 | 所在楼层：x层 |
| 价格 | price | double | N | N | 无 | 购买者创建时间 |
房屋表清单作为系统中的对于房屋描述的pojo类型，描述的是系统中的单个对象，其中在数据库存储中的作为唯一主键的是houseID，其中对于此房屋所属的楼房是使用外键buildingID作为约束并与楼房表相关联，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
通过上述两表我们可以看出一个具体的房间需要很多信息进行描述，此外为了能够节省存储空间同时能够进行优化，本系统将楼房和房屋分离，在存储上避免了对每个房屋进行楼房相关信息描述节省了很多存储空间。
(2) 员工信息管理模块
本模块涉及两张数据表分别是楼房信息和房屋信息，分别如表4.3和表4.4所示。
表4.3 员工基本信息清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 员工编号 | staffID | varchar(10) | Y | N | 无 | 主键 |
| 姓名 | name | varchar(20) | N | N | 无 | 员工姓名 |
| 年龄 | age | integer | N | N | 无 | 员工年龄 |
| 性别 | sex | char | N | N | 无 | 员工性别 |
| 部门 | department | varchar(20) | N | N | 无 | 所属部门 |
| 职位 | position | varchar(20) | N | N | 无 | 所在职位 |
| 薪水 | salary | double | N | N | 无 | 员工工资 |
| 工作年龄 | workage | datetime | N | N | 无 | 工作年龄 |
| 身份证 | idential | varchar(18) | N | N | 无 | 身份证号 |
| 电话 | telNum | varchar(11) | N | N | 无 | 电话号码 |
| 状态 | state | integer | N | N | 无 | 当前员工工作状态 |
员工基本信息清单作为系统中的pojo类型，描述的是系统中的员工对象，其中在数据库存储中的作为唯一主键的是staffID，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
表4.4员工销售清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 销售编号 | saleInfoID | varchar (10) | Y | N | 无 | 主键 |
| 员工工号 | staffID | varchar(20) | N | N | 无 | 外键：参考员工ID |
| 时间 | saleTime | datetime | N | N | 无 | 销售日期 |
| 房屋编号 | houseID | varchar(20) | N | N | 无 | 外键：参考房屋ID |
| 合同编号 | contactID | varchar(20) | N | N | 无 | 外键：参考合同ID |
| 说明 | statement | text | N | N | 无 | 销售说明 |
员工销售表清单作为系统中的pojo类型，描述的是员工销售记录对象，其中在数据库存储中的作为唯一主键的是saleInfoID，员工销售与员工相对应，因此需要saffID作为外键约束，同时销售记录需要涉及房屋信息，因此用houseID作为外键约束，同时需要绑定相应的合同，因此contactID也是必须的，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
通过上述两表我们可以看出员工信息管理模块除了对员工的基本信息进行管理之外还对其相应的销售情况进行了记录，在销售行业当一个员工的销售量非常高的时候对应的工资或奖金也会逐渐增加，此处设计的目的就是基于此给出员工的销售情况从而不仅能激发员工的热情也能给企业带来更大的收益。
(3) 销售方案管理模块
本模块涉及两张数据表分别是市场调研和销售方案，分别如表4.5和表4.6所示。
表4.5 市场调研清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 调研编号 | researchID | varchar(10) | Y | N | 无 | 主键 |
| 开始时间 | beginTime | datetime | N | N | 无 | 实际调研开始日期 |
| 结束时间 | endTime | datetime | N | N | 无 | 实际调研结束日期 |
| 方法 | method | text | N | N | 无 | 调研中采用的方法 |
| 结论 | conclusion | text | N | N | 无 | 调研结果 |
| 执行者 | who | text | N | N | 无 | 调研团队 |
市场调研清单作为系统中的pojo类型，描述的是市场调研记录对象，其中在数据库存储中的作为唯一主键的是reasearchID，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
表4.6 销售方案清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 方案编号 | methodID | varchar(10) | Y | N | 无 | 主键 |
| 楼房编号 | buildingID | varchar(10) | N | N | 无 | 外键，参考楼房ID |
| 说明 | satement | text | N | N | 无 | 方案说明 |
| 描述 | description | text | N | N | 无 | 方案描述 |
| 起草 | drafTime | datetime | N | N | 无 | 起草时间 |
| 结草 | endTime | datetime | N | Y | 无 | 结草时间 |
| 执行 | excuteTime | datetime | N | Y | 无 | 执行时间 |
| 状态 | state | integer | N | N | 无 | 处理状态 |
| 经办人 | who | varchar(10) | N | N | 无 | 外键，参考员工ID |
| 调研信息 | researchID | varchar(10) | N | N | 无 | 外键，参考调研ID |
销售方案表清单作为系统中的pojo类型，描述的是系统中销售方案对象，其中在数据库存储中的作为唯一主键的是methodID，每个销售方案都是针对相应楼盘信息，因此需要对楼盘信息进行绑定，buildingID正是基于此作为外键约束，销售方案同时要结合调研信息，reasearchID作为调研信息存在，同时每个方案有相应的经办人因此who作为外键参考员工信息，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
通过上述两表我们可以看销售方案的确定需要参照当前的调研信息，然后由起草、审讨、结草、执行以及舍弃等状态生命周期，其中需要由部门主管即经办人参加其中所有的讨论和状态决定决议。
(4) 销售合同管理模块
本模块仅涉及一张数据库表即销售合同，销售合同作为能够给公司带来利润的注入血液的成分在本系统中起着不可缺少的地位，销售系统中销售合同的数据表如下：
表4.7 销售合同清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 合同编号 | contactID | varchar(10) | Y | N | 无 | 主键 |
| 房屋编号 | houseID | varchar(10) | N | N | 无 | 外键，参考房屋ID |
| 客户编号 | customerID | varchar(10) | N | N | 无 | 外键，参考客户ID |
| 员工编号 | staffID | varchar(10) | N | N | 无 | 外键，参考员工ID |
| 说明 | statement | text | N | N | 无 | 合同说明 |
| 开始时间 | beginTime | datetime | N | N | 无 | 合同生效时间 |
| 结束时间 | endTime | datetime | N | Y | 无 | 合同到期时间 |
销售合同表清单作为系统中的pojo类型，描述的是销售合同记录对象，其中在数据库存储中的作为唯一主键的是contactID，销售合同同时要关联多个信息，分别是房屋信息、客户信息以及员工信息，因此销售合需要对应的houseID、customerID和staffID进行外键约束，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
通过上表我们看出销售合同包含着3个外键，分别是房屋、客户、员工，这和实际操作上合同的签署情况是一直的。
(5) 客户信息管理模块
本模块涉及两张数据表分别是客户基本信息和客户相关资料，分别如表4.8和表4.9所示。
表4.8 客户基本信息清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 客户编号 | customerID | varchar(10) | Y | N | 无 | 主键 |
| 姓名 | name | varchar(20) | N | N | 无 | 客户姓名 |
| 年龄 | age | integer | N | N | 无 | 客户年龄 |
| 性别 | sex | char | N | N | 无 | 客户性别 |
| 电话 | telNumber | varchar(18) | N | N | 无 | 联系电话 |
| 地址 | address | text | N | N | 无 | 住址信息 |
楼房表清单作为系统中的pojo类型，描述的是客户对象，其中在数据库存储中的作为唯一主键的是customerID，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
表4.9 客户资料清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 资料编号 | infoID | varchar(10) | Y | N | 无 | 主键 |
| 时间 | time | datetime | N | N | 无 | 来访时间 |
| 房屋类型 | houseType | integer | N | N | 无 | 喜好房屋类型 |
| 价格区间 | priceRange | text | N | N | 无 | 可接受价格区间 |
| 顾客编号 | customerID | datetime | N | N | 无 | 外键，参考顾客ID |
| 说明 | statement | text | N | N | 无 | 喜好说明 |
楼房表清单作为系统中的pojo类型，描述的是整栋楼房对象，其中在数据库存储中的作为唯一主键的是infoID，每个客户可能有多个资料，因此为了识别此资料归属于那个客户，需要customerID进行外键约束，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
本模块设计两张表的目的在于客户基本资料用于存储客户的基本信息，对于客户资料是记录来进行观看房源的客户的喜好资料，从而为系统本身后期开发中对于数据挖掘或行为推荐提供帮助。
(6) 售后处理管理模块
本模块仅涉及一张数据库表即售后记录，售后作为销售中后期对所售商品的维护起着不可缺少的作用，其数据库表设计如下：
表4.10 售后信息清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 合同编号 | afterSaleID | varchar(10) | Y | N | 无 | 主键 |
| 客户编号 | customerID | varchar(10) | N | N | 无 | 外键，参考客户ID |
| 房屋类型 | houseType | integer | N | N | 无 | 房屋类型 |
| 问题描述 | problem | text | N | N | 无 | 售后问题信息描述 |
| 地址 | address | text | N | N | 无 | 客户地址 |
| 电话 | telNumber | varchar(18) | N | N | 无 | 客户电话 |
| 时间 | time | datetime | N | N | 无 | 客户申请服务时间 |
| 问题程度 | eventType | integer | N | N | 无 | 问题程度 |
| 处理状态 | sate | integer | N | N | 无 | 售后处理状态 |
| 房屋编号 | houseID | varchar(10) | N | N | 无 | 外键，参考房屋ID |
| 顾客姓名 | cusName | datetime | N | N | 无 | 顾客姓名 |
售后表清单作为系统中的pojo类型，描述的是整栋楼房对象，其中在数据库存储中的作为唯一主键的是afterSaleID，每个售后的处理必然是对应某个销售合同的信息，因此此表需要contactID进行外键关联约束，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
通过上表我们看出售后需要对客户清单和房屋清单进行管理，以二者为外键进行参考引用，同时售后管理需要记录问题内容和程度以及客户能够接受的处理时间从而不仅能够合理的筛选售后服务人家而且能够在客户接受的最快的时间内提供服务。
(7) 房屋预约管理模块
本模块仅涉及一张数据库表即预约信息表，房屋预约的目的是能够给即将来访的顾客提前记录其预约信息同时根据其个人相关信息准备好推荐的资料为接下来的来访打好基础做好准备帮助客户买到心仪的房型的同时能够为自己的销售业绩增添一笔收益。
房屋预约管理模块中房屋预约清单数据库的设计如下：
表4.11 房屋预约清单
| 中文名称 | 英文名称 | 类型长度 | 主键 | 空值 | 默认值 | 备注 |
| 预约编号 | appointID | varchar(10) | Y | N | 无 | 主键 |
| 客户编号 | customerID | varchar(10) | N | N | 无 | 外键，参考客户ID |
| 时间 | time | datetime | N | N | 无 | 预约到来的时间 |
| 房源类型 | hosueType | integer | N | N | 无 | 喜好的房型 |
| 地址 | address | text | N | N | 无 | 喜好的地址 |
| 说明 | statemen | text | N | N | 无 | 预约说明 |
| 最小价格 | priceMin | double | N | N | 无 | 能够接受的最低价格 |
| 最高价格 | priceMax | double | N | N | 无 | 能够接受的最高价格 |
| 面积 | area | double | N | N | 无 | 房屋所占平方米 |
房屋预约表清单作为系统中的pojo类型，描述的是整栋楼房对象，其中在数据库存储中的作为唯一主键的是appointID，房屋预约信息是客户对于指定房源类型进行预约咨询，因此需要customerID进行外键关联，其他属性均作为对表的描述信息，各个相关类型描述如表内容所示。
通过上表我们看出房屋预约清单的所有相关数据，其中包含的关联客户，那么在客户来之前服务人员或接待人员接口根据系统本身查看此客户之前的来访信息或记录从而根据其喜好给出相应的合理的推荐。
