《数据库基础与应用课程设计-物业管理系统》由会员分享，可在线阅读，更多相关《数据库基础与应用课程设计-物业管理系统（13页珍藏版）》请在金锄头文库上搜索。
1、苏 州 市 职 业 大 学课 程 设 计 说 明 书名称 物业管理系统 2010 年 06 月 20 日 至 2010 年 06 月 24 日 共 1 周院 系 计算机工程系 班 级 10 软件测试 姓 名 张莹 22 系主任 教研室主任 指 导 教 师 目录1.课程设计的目的与要求 .32.题目说明 .33.需求分析和数据库设计 .34.表和索引的创建及数据完整性 .95.数据库结构的实现 .96.遇到的问题和解决方法 .117.课程设计总结 .118.参考文献 .121.课程设计的目的与要求数据库基础与应用课程设计是计算机专业集中实践性环节之一，是学习完数据库系统概论课程后进行的一次全面的
2、综合练习。其目的在于加深对数据库基础理论和基本知识的理解，掌握使用 VB、C 、C+、PowerBuilder 等进行数据库开发的全过程，提高运用数据库解决实际问题的能力。2.题目说明物业管理系统；2.1、设计要求：进行需求分析，设计数据库的概念模型；楼盘信息管理：楼盘信息的添加、编辑和查询；住户信息管理：住户信息的添加、编辑和查询；报修事项管理：报修事项的添加、编辑和查询；投诉信息管理：投诉信息的添加、编辑和查询；报表管理：输出楼盘信息、住户信息、报修信息和投诉信息。2.2、本课题设计的基本要求：必须提交系统分析报告，包括系统的功能分析、系统的功能模块设计、数据库的数据字典，数据库的概念结构
3、（ER 图），数据库中的表、视图（如果使用）、存储过程（如果使用）的结构和定义（可以用 SQL 脚本提供）；系统的源程序，包括数据库脚本程序。3.需求分析和数据库设计3.1 信息收集和需求分析楼盘信息：包括的数据项有：楼盘编号，楼盘名称，楼层数，面积，户型，地址住户信息：包括的数据项有：业主编号，姓名，性别，电话，门牌号，面积，身份证报修事项：包括的数据项有：报修事项编号，报修名称，业主，电话，门牌号，维修状态，日期，受理人投诉信息：包括的数据项有：投诉事项编号，投诉名称，业主，电话，门牌号，解决状态，日期，受理人报表管理：楼盘信息，户主信息，报修信息，投诉信息3.2 概念设计E-R 图概念模
4、型用于信息世界的建模。概念模型不依赖于某一个数据库管理系统（DBMS），但可以方便的转换为计算机上某一 DBMS 所支持的特定的数据模型。通过对用户对数据的需求进行综合、归纳与抽象，将形成一个完善的概念模型，可以用 E-R(实体联系)图来表示。E-R 图是对现实世界的一种抽象，它的主要成份是实体、属性和联系。1. 实体：客观存在并可以互相区分的事物称为实体，是现实世界中各种事物的抽象。如本案例中一个班级为一个实体。一般来说，每个实体都相当于数据库中的一个表。实体用一个矩形框来表示。2. 属性：属性是实体所具有的某些特征，通过属性对实体进行刻画。实体是由属性组成的，如班级有班级名称、创建人等属性
5、。一个实体本身具有许多属性，能够唯一标识实体的属性称为该实体的码。属性用一个椭圆来表示，本案例中，为使E-R 图清晰直观，我们将属性内置于实体的矩形框中。3. 联系：现实世界的事物内部或事物之间都有联系，这些联系在信息世界里反映为实体内部或实体之间的联系，如班级属于某个学校，那么班级和学校之间是“属于”联系。联系有一对一联系，一对多联系和多对多联系，分别用 1：1、1：n和 m：n 来表示。如一个登录用户名只能填写一份个人资料，那么登录用户和个人资料就是一对一联系；一个班级只能属于一个学校，而一个学校可以拥有多个班级，学校和班级之间就是一对多联系；一个班级可以有多张相片，而一张相片也可为多个班
6、级所拥有，所以班级和相片之间是多对多联系。联系用菱形表示，并用线段联接相关的两个或多个实体，在菱形两端线段上标明联系的类型。本系统的实体有：楼盘实体、住户实体、保修事项、投诉事项。各个实体具体的描述 E-R图如图 1-1 到图 1-5 所示。楼盘楼盘编号楼盘名称 楼层数面积住户户型地址面积身份证性别门牌号姓名电话业主编号报修报修编号报修名称 报修业主报修时间图 1-3 保修事项实体属性图电话 维修状态门牌号 受理人图 1-1 楼盘实体属性图图 1-2 住户实体属性图投诉投诉编号投诉编号投诉编号 投诉编号图 1-4 投诉实体属性图电话处理状态门牌号受理人住户楼盘 居住申请报修提出投诉11图 1-
7、5 实体之间关系 ER 图3.3 逻辑设计概念设计的结果得到一个与计算机、软硬件的具体性能无关的全局概念模式。数据库逻辑设计的任务是将概念结构转换成特定 DBMS 所支持的数据模型（如关系模型）的过程。本案例中我们将其转换为关系模型。将 E-R 图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式，这种转换一般遵循如下原则：一个实体转换为一个关系模式，实体的属性就是关系的属性，实体的关键字就是关系的关键字。一个 1:1 联系可以转换为一个独立的关系模式，也可以与任意一端实体所对应的关系合并，在被合并关系中增加属性，其新增的属性为联系本身的属性和与联系相关的另一个实体的码
8、。一个 1:n 联系可以转换为一个独立的关系模式，也可以与 n 端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为 n 端实体的码。如果与 n 端的关系模式合并则在 n 端实体集中增加新属性，新属性由联系对应的 1 端实体集的码和联系自身的属性构成，新增属性后原关系的码不变。一个 m：n 联系转换为一个关系模式，与该联系相连的各实体的码以及联系本身具有的属性均转换为关系的属性，而关系的码为各实体码的组合。现在需要将上面的数据库概念结构转化为 SQL Server 2000 数据库系统所支持的实际数据模型，也就是数据库
9、的逻辑结构。物业管理系统数据库中各个表格的设计结果如下面的几个表所示。每个表表示在数据库中的一个数据表。表 1-1 Houses-info 楼盘基本信息表列名 数据类型 是否为空 说明HouseID Char(2) Not Null 楼盘编号（主键）HouseName Varchar (10) Not Null 楼盘名称Floors Int(4) Null 楼层数HouseStyle Varchar(10) Not null 户型Address Char(20) Not Null 地址Area Varchar(10) Null 面积表 1-2 Complains-info 投诉基本信息表列名
10、数据类型 是否为空 说明ComplainID Int(4) Not Null 投诉编号(主键)ComplainName Varchar(20) Null 投诉名称OwnerName Varchar(20) Not Null 业主姓名Date Datetime Not Null 日期DoorID Char(6) Null 门牌号（外键）ConductCondition Char(10) Not Null 处理状态Phone Char(20) Null 联系电话AgentName Varchar(10) Not Null 受理人ComplainDetials Varchar(50) Null 投诉
11、细节表 1-3 Repairs-info 维修基本信息表列名 数据类型 是否为空 说明RepairID Int(4) Not Null 维修编号(主键)RepairName Varchar(10) Null 维修名称OwnerName Varchar(10) Not Null 业主姓名Date Datetime Not Null 日期DoorID Char(6) Not Null 门牌号（外键）AgentName Varchar(10) Not Null 受理人RepairCondition Char(10) Not Null 维修状态RepairDetails Varchar(50) Nul
12、l 维修内容Phone Char(11) Not Null 联系电话表 1-4 Owner-info 业主基本信息表格列名 数据类型 是否为空 说明HouseID Char(2) Not Null 楼盘编号OwnerID Int(4) Not Null 业主编号OwnerName Varchar(10) Not Null 业主姓名Sex Char(2) Not Null 性别DoorID Char(6) Not Null 门牌号（主键）Phone Char(11) Not Null 联系电话IDNo Char(18) Not Null 身份证（唯一）Area Varchar(10) Not Null 面积4.表和索引的创建及数据完整性1) 建表。根据关系模式设计表，为表的各属性选择合适的数据类型以及属性可否为空。2) 设置主键，为数据库 SchoolMates 的每个表设置主键。每个表都应该具有主键，主键的存在就代表着表结构的完整性，表的记录必须得有唯一区分的字段，主键主要是用于与其他表的外键关联，本记录的修改与删除，如果没有主键，这些操作会变的非常麻烦。（提示：可以使用自动编号作为主键，就是新建一个 ID 字段，自动增长）3) 设置外键。例如
