房产管理数据库文档格式.docx
- 文档编号:15294396
- 上传时间:2022-10-29
- 格式:DOCX
- 页数:23
- 大小:346.26KB
房产管理数据库文档格式.docx
《房产管理数据库文档格式.docx》由会员分享,可在线阅读,更多相关《房产管理数据库文档格式.docx(23页珍藏版)》请在冰豆网上搜索。
3设计任务
房产管理系统应具有分房、调房、退房和咨询统计功能,同时应能对房产信息、住房信息、住户基本信息及住户家庭信息等进行管理,并建立住房和住户之间的对应关系。
对这些信息应能进行方便快捷的新增、修改和删除等操作,另外还能快速找到所需的信息,这个就是需要查询功能。
4设计内容
4.1需求分析
房产科把用户申请表(按照统一的格式由用户填写)输入系统后,系统首先检查申请表的合法性,对不合法的申请表系统拒绝接受,对合法的申请表根据类型分别进行处理。
如果是分房申请,则根据申请者的情况计算其分数,当分数高于阈值分数时,按分数高低将申请单插到分房队列的适当位置。
每月最后一天进行一次分房活动,从空房文件中读出空房信息,把好房优先分配给排在分房队列前面的符合该登记住房条件的申请者,从空房文件中删除掉这个房号的信息,从分房队列中删除申请单,并把此房号的信息和住户信息一起写到住房文件中,输出住房分配单给住户,同时计算房租并将算出的房租写到房租文件中。
如果是调房申请,则根据申请者的情况确定其住房等级,然后在空房文件中查找属于给等级的空房,退掉原住房,再进行与分房类似的处理。
如果是退房申请,则从住房文件和房租文件中删除有关的信息,再把此房号的信息写到空房文件中。
住户可向系统询问目前分房的阈值分数,居住某类房屋的条件,某房号的单位面积房租等信息。
房产科可以要求系统打印出住房情况的统计表,或更改某类房屋的居住条件、单位面积房租等。
4.2系统设计
4.2.1概念结构设计
E-R图是分为两部分实体和属性,每个实体可以有多个属性,这些属性用来表示实体的性质。
不同实体之间可以用关系进行连接,表明各个实体之间的内在联系。
实体和实体之间的关系有一对一的关系(1:
1),一对多的关系(1:
N)和多对多的关系(N:
M)。
用户信息E-R图,如图4—1所示。
图4—1用户信息E-R图
住房要求E-R图,如图4—2所示。
图4—2住房要求E-R图
住房标准E-R图,如图4—3所示。
图4—3住房标准E-R图
房产文件E-R图,如图4—4所示。
图4—4房产文件E-R图
住房文件E-R图,如图4—5所示。
图4—5住房文件E-R图
分房要求E-R图,如图4—6所示。
图4—6分房要求E-R图
退房要求E-R图,如图4—7所示。
图4—7退房要求E-R图
调房要求E-R图,如图4—8所示。
图4—8调房要求E-R图
总E-R图,如图4—9所示。
图4—9总E-R图
4.2.2逻辑结构设计
数据库逻辑设计的任务是将概念结构转换成特定DBMS所支持的数据模型的过程。
从此开始便进入了“实现设计”阶段,需要考虑到具体的DBMS的性能、具体的数据模型特点。
从E-R图所表示的概念模型可以转换成任何一种具体的DBMS所支持的数据模型,如网状模型、层次模型和关系模型。
这里只讨论关系数据库的逻辑设计问题,所以只介绍E-R图如何向关系模型进行转换。
关系模型的逻辑结构是一组关系模式的集合。
E-R图则是由实体,实体的属性和实体间的联系三个要素组成。
所以将E-R图转换为关系模型实际上就是要将实体,实体的属性和实体间的联系转换为关系模式。
转换原则如下。
1.实体类型的转换:
一个实体型转换成一个关系模式。
实体的属性就是关系的属性,
实体的码就是关系的码。
2.联系类型的转换,根据不同的情况做不同的处理。
(1)一个1:
1的联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,每个实体的码均是该关系的候选码。
如果与某一端实体对应的关系模式合并,则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
(2)一个1:
N的联系可以转换为一个独立的关系模式,也可以与N端对应的关系模式合并。
如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为N端实体的码。
(3)一个M:
N联系转换为一个关系模式。
与该联系相连的各实体的码为各实体码的组合。
(4)三个或三个以上实体间的一个多元联系可以转换为一个关系模式。
与该多元联系相连的各实休的码以及联系本身的属性均转换为关系的属性,而关系的码为各实体码的组合。
(5)具有相同码的关系模式可合并。
3.根据房产管理系统的E-R图转换为关系模型如下。
将每一个实体转换成一个关系(关系就是给出关系名,属性就是实体属性,并标明该关系的主键用下划线来表示)
关系模式:
用户信息(户主,部门,职称,人口,房号)
住房要求(户主,要求)
住房标准(面积,最低分数)
房产文件(房号,住房面积,分配标志,房租)
住房文件(户主,职称,部门,人口,分数,房号,住房面积)
分房要求(户主,部门,职称,人口,分数,要求面积)
退房要求(部门,房号)
调房要求(户主,部门,职称,人口,分数,面积,房号,申请面积)
以上关系模式均为3NF。
4.2.3物理结构设计
用户信息如表4—1所示。
表4—1用户信息表user_info
属性名
存储代码
类型
长度
备注
户主
huzhu
char
20
户主姓名
部门
bumen
工作部门
职称
zhicheng
10
房号
fanghao
8
所住房号
人口
renkou
int
家庭人口
住房要求如表4—2所示。
表4—2住房要求user_q
要求
yaoqiu
申请要求
住房标准如表4—3所示。
表4—3住房标准zhu_b
面积
mianji
Int
住房面积
最低分数
zuidifenshu
最低住房分数
住房文件如表4—4所示。
表4—4住房文件zhu_w
户主职称
分数
fenshu
住房分数
房间号码
zhufangmianji
现住面积
房产文件如表4—5所示。
表4—5房产文件fang_w
分配标志
fenpeibiaozhi
4
是否分配(是)
房租
fangzu
每平方米房租
分房要求如表4—6所示。
表4—6分房要求fang_q
huzhu
Char
申请人姓名
要求面积
yaoqiumianji
要求住房面积
调房要求如表4—7所示。
表4—7调房要求tiao_q
Char
Int
分房分数
原住房面积
原房号
申请面积
shenqingmianji
退房要求如表4—8所示。
表4—8退房要求tui_q
要退房号
4.3系统实施
4.3.1数据库实现
1、用户信息表user_info
createtableuser_info
(
huzhuchar(20)notnull,primarykey(huzhu)
bumenchar(20)notnull,
zhichengchar(10)notnull,
renkouchar(8),
fanghaoint
)
tablespacesushe_data;
2、住房要求user_q
createtableuser_q
(
huzhuchar(20)notnull,foreignkeyreferencesfaculty(huzhu),
yaoqiuchar(10)notnull,
)
tablespacesushe_data;
3、住房标准zhu_b
createtablezhu_b
mianjiintnotnull,primarykey(huzhu),
zuidifenshuintnotnull,
4、住房文件zhu_w
createtablezhu_w
huzhuchar(20)notnull,primarykey(huzhu)
zhichengchar(10)notnull,
bumenchar(20)notnull,fore
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 房产 管理 数据库