房产管理系统数据库课程设计Word文档格式.docx

房产管理系统数据库课程设计Word文档格式.docx

《房产管理系统数据库课程设计Word文档格式.docx》由会员分享，可在线阅读，更多相关《房产管理系统数据库课程设计Word文档格式.docx（17页珍藏版）》请在冰豆网上搜索。

房产科把用户申请表（按照统一的格式由用户填写）输入系统后，系统首先检查申请表的合法性，对不合法的申请表系统拒绝接受，对合法的申请表根据类型分别进行处理。

如果是分房申请，则根据申请者的情况计算其分数，当分数高于阈值分数时，按分数高低将申请单插到分房队列的适当位置。

每月最后一天进行一次分房活动，从空房文件中读出空房信息，把好房优先分配给排在分房队列前面的符合该登记住房条件的申请者，从空房文件中删除掉这个房号的信息，从分房队列中删除申请单，并把此房号的信息和住户信息一起写到住房文件中，输出住房分配单给住户，同时计算房租并将算出的房租写到房租文件中。

如果是调房申请，则根据申请者的情况确定其住房等级，然后在空房文件中查找属于给等级的空房，退掉原住房，再进行与分房类似的处理。

如果是退房申请，则从住房文件和房租文件中删除有关的信息，再把此房号的信息写到空房文件中。

住户可向系统询问目前分房的阈值分数，居住某类房屋的条件，某房号的单位面积房租等信息。

房产科可以要求系统打印出住房情况的统计表，或更改某类房屋的居住条件、单位面积房租等。

4.2系统设计

4.2.1概念结构设计

（1）用户

图4-1用户E-R图

（2）申请表

图4-2申请表E-R图

（3）房产科-分配-住房

图4-3房产科分配住房E-R图

一个房产科分配多套住房（1：

m）

一套住房只被一个房产科分配（1：

1）

（4）管理-调房

图4-4房产科管理调房E-R图

一个房产科管理多个调房请求（1：

一个调房请求由一个房产科管理（1：

（5）管理-分房

图4-5房产科管理分房E-R图

一个房产科管理多个分房请求（1：

一个分房请求由一个房产科管理（1：

（6）管理-退房

图4-6房产科管理退房E-R图

一个房产科管理多个退房请求（1：

一个退房请求由一个房产科管理（1：

（7）视图集成

所有局部ER模式都设计好了后，接下来就是把它们综合成单一的全局概念结构。

全局概念结构不仅要支持所有局部ER模式，而且必须合理地表示一个完整、一致的数据库概念结构。

1）确定公共实体类型

为了给多个局部ER模式的合并提供开始合并的基础，首先要确定各局部结构中的公共实体类型。

2）局部ER模式的合并

合并的原则是：

首先进行两两合并；

先和合并那些现实世界中有联系的局部结构；

合并从公共实体类型开始，最后再加入独立的局部结构。

3）消除冲突

冲突分为三类：

属性冲突、结构冲突、命名冲突。

4）全局ER模式的优化

在得到全局ER模式后，为了提高数据库系统的效率，还应进一步依据处理需求对ER模式进行优化。

一个好的全局ER模式，除能准确、全面地反映用户功能需求外，还应满足下列条件：

实体类型的个数要尽可能的少；

实体类型所含属性个数尽可能少；

实体类型间联系无冗余。

综上所述，“图书管理系统”的全局ER模式如图4.3.7所示：

图4-7综合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.3数据库表空间和表结构设计

表4.3.1登陆信息表loca-in

属性名

存储代码

类型

长度

备注

账号

Local-id

char

20

登陆账号

密码

Local-p

登陆密码

角色

Local-r

10

登陆角色

表4.3.2用户信息表user_info

户主

huzhu

户主姓名

部门

bumen

工作部门

职称

zhicheng

房号

renkou

8

所住房号

人口

fanghao

int

家庭人口

表4.3.3住房要求user_q

要求

yaoqiu

申请要求

表4.3.4住房标准zhu_b

面积

mianji

Int

住房面积

最低分数

zuidifenshu

最低住房分数

表4.3.5住房文件zhu_w

户主职称

分数

fenshu

住房分数

4

房间号码

zhufangmianji

现住面积

表4.3.6房产文件fang_w

分配标志

fenpeibiaozhi

是否分配（是）

房租

fangzu

每平方米房租

表4.3.7分房要求fang_q

Huzhu

Char

申请人姓名

Bumen

Zhicheng

Fenshu

要求面积

yaoqiumianji

要求住房面积

表4.3.8调房要求tiao_q

Char

Renkou

Int

分房分数

Mianji

原住房面积

Fanghao

原房号

申请面积

shenqingmianji

表4.3.9退房要求tui_q

要退房号

4.4系统实施

1、登录信息loca-in

createtableloca-in

（

Local-idchar（20）notnull,

Local-pchar（20）notnull

Local-rchar（10）notnull

）

tablespacesusyhe_data;

2、用户信息表user_info

createtableuser_info

（

huzhuchar（20）notnull,primarykey（huzhu）

bumenchar（20）notnull,

zhichengchar（10）notnull,

renkouchar（8）,

fanghaoint

tablespacesushe_data;

3、住房要求user_q

createtableuser_q

huzhuchar（20）notnull,foreignkeyreferencesfaculty（huzhu）,

yaoqiuchar（10）notnull,

）

tablespacesushe_data;

4、住房标准zhu_b

createtablezhu_b

mianjiintnotnull,primarykey（huzhu）,

zuidifenshuintnotnull,

5、住房文件zhu_w

createtablezhu_w

huzhuchar（20）notnull,primarykey（huzhu）

zhichengchar（10）notnull,

bumenchar（20）notnull,foreignkeyreferencesmajor（bumen）,

fenshuintnotnull,

renkouint

fanghaochar（4）

zhufangmianjiint

6、房产文件fang_w

createtablefang_w

fanghaochar（4）primarykey,

fenpeibiaozhichar（4）notnull,

fangzuintnotnull,

zhufangmianjiintnotnull,

）

Tablespacesushe_data;

7、分房要求fang_q

createtablefang_q

huzhuchar（20）primarykeynotnull,

bumenchar（20）notnull,

renkouintnotnull,

yaoqiumianjiintnotnul

8、调房要求tiao_q

createtabletiao_q

huzhuchar（20）notnull,primarykey

bymenchar（20）notnull,

zhichengchar（10）notnull

renkouintnotnull

fenshuintnotnull

mianjiintnotnull

fanghaochar（4）notnull

shenqingmianjiintnotnull

9、退房要求tui_q

createtabletui_q

bumenchar（20）primarykey,

fanghaochar（4）notnull,

4.5创建其它数据库对象

视图的创建：

创建视图用于查寻用户信息

CREATEVIEWyhxx

AS

SELECTyaoqiu,zhufangmianji

FROMuser_infoJOINuser_qONuser_info.huzhu=user_q.huzhu

JOINzhu_wONuser_q.huzhu=zhu_w.huzhu

触发器的创建：

创建触发器zfq，使得在退房要求表中执行退房申请时，则从住房文件和房租文件中删除有关的信息，再把此房号的信息写到空房文件中

CREATETRIGGERzfq

ONtui_q

FORdelect

AS

BEGIN

delecttui_q

SETbumen,fanghaotofang_w

END

存储过程的创建：

创建一个存储过程fang_w1，输入房号，返回分配标志，房租，住房面积。

（一个输入变量，三个输出变量）

CREATEPROCfang_w1

@fanghaochar（4）,@fenpeibiaozhichar（4）output,@fangzuintoutput,@zhufangmianjiintoutput,

AS

SELECT@fenbeibiaozhi=分配标志,@fangzu=房租,@zhufangmianji=住房面积

FROMfang_w

WHERE房号=@fangha

5总结与展望

本次课程设计综合考察了我们对数据库知识的掌握熟练程度和实际运用能力。

其间，涉及到了数据库中的绝大多数的知识点，如数据库SQL语句的建表，插入，删除，修改等操作。

刚开始学的时候确实有很多地方我很不理解，每次上课时老师都会给我们出不同的设计题目，对于我们一个初学者来说，无疑是一个具大的挑战，撞了几次壁之后，我决定静下心来，仔细去学习。

老师会给我们需要的内容一些讲解，顺着老师的思路，来完成自己的设计，可是好多处的错误让人看的可怕，还看不出到底是哪里出现了错误，但是程序还是得继续下去，我多次请教了老师和同学，逐渐能自己找出错误，并加以改正。

其实现在想起来，收获还真是不少，虽然说以前非常不懂这门课程，在它上面花费了好多心血，觉得它很难，是需用花费了大量的时间学习。

现在真正的明白了很多。

只要努力去学习，就会灵活的去应用它。

通过这次课程设计，认识到了自身的不足。

首先是知识的匮乏，仅仅通过课上学习的东西远远不够课下应该多阅览相关书籍。

虽然能够勉强读懂程序但是到实际应用中就会看到差距。

之前我只能勉强读懂简单程序甚至不能分析运行结果，通过这次实际应用才明白自身知识的匮乏。

在这次设计过程中，体现出自己单独设计程序的能力以及综合运用知识的能力，从中发现自己平时学习的不足和薄弱环节，从而加以弥补。