收费停车场管理系统数据库设计数据库课程设计论文正稿Word格式.docx

收费停车场管理系统数据库设计数据库课程设计论文正稿Word格式.docx

《收费停车场管理系统数据库设计数据库课程设计论文正稿Word格式.docx》由会员分享，可在线阅读，更多相关《收费停车场管理系统数据库设计数据库课程设计论文正稿Word格式.docx（27页珍藏版）》请在冰豆网上搜索。

2.2.1需求分析阶段的目标

通过调查了解分析停车管理的现状，弄清用户对开发的数据库应用系统的确切要求，以及停车场管理的流程，系统的具体功能和数据库中数据信息。

2.2.2具体任务

（1）处理对象

系统处理的对象包括车辆信息、固定车位信息、自由车位信息、停车车辆信息以及收费记录等五个方面。

即

固定车位信息：

车位编号、车位位置、车牌号码、车主姓名、车辆品牌、车辆颜色、车辆照片、联系地址、联系方式、车位余额；

自由车位信息：

车位编号、车位位置；

车辆信息：

车牌号码、车辆品牌、车辆颜色；

停车信息：

车位编号、车牌号码、进入时间、离开时间、时间段、车位类型、在位情况、收费费率；

收费记录：

车位编号、车牌号码、停车时间、停车费用、发票编号。

（2）处理功能要求

整个系统具体包括三个子系统，分别为：

停车处理子系统、车位综合管理子系统以及收费子系统。

处理的功能包括：

车辆信息的查询以及更新；

空闲车位信息的查询；

固定车位信息的查询；

进出车辆记录的更新和收费信息的查询与更新等。

（3）安全性与完整性要求

安全性可以通过视图机制来完成，对不同用户设置不同权限，不同的用户只能访问授权的视图，这样可以提高一定的程度的安全性。

还可以通过存取控制机制：

即定义用户权限，并将用户权限登记到数据字典中以及合法的权限检查来保障安全性。

完整性可以通过声明完整性，即在定义表时声明数据完整性和过程完整性，在服务器端编写触发器来实现。

2.2.3结果

（1）体会和收获

通过对现在的停车场管理状况的调查，发现停车场管理缺少合适的管理系统，并了解了一下管理的大致流程。

与此同时通过网络搜索查找现行的停车场管理系统，根据这两者综合来进行需求分析。

调查时需要较强的信息捕捉能力以及事后的总结与思考，同时学会用网络较快较准确地搜索到需要的资料是很关键的。

（2）业务流程图

见附录1

（3）数据流图

见附录2

（4）数据字典

数据项：

表2-1数据项说明

数据项编号

数据项名

数据项含义

与其它数据项的关系

存储结构

别名

DI-1

Cwno

车位编号

char（10）

编号

DI-2

Carno

车牌号码

车牌

DI-3

Carname

车主姓名

姓名

DI-4

Carcolor

车辆颜色

char（4）

颜色

DI-5

Carpho

车辆照片

bit

照片

DI-6

Caradd

联系地址

char（20）

地址

DI-7

Cartel

联系方式

电话

DI-8

Carat

在位情况

DI-9

Carin

进入时间

datetime

DI-10

Carout

离开时间

DI-11

Carmon

车位余额

float

余额

DI-12

Montime

收费费率

费率

DI-13

Moneypay

停车费用

收费

DI-14

Cwtype

车位类型

DI-15

Cartime

停车时间

时间

DI-16

Piece

发票编号

Dl-17

Carsb

车辆品牌

车名

Dl-18

Cwpace

车位位置

位置

Dl-19

Timetype

时间段

char（6）

数据结构：

表2-2数据结构

数据结构编号

数据结构名

数据结构定义

组成

DS-1

Fixed

固定车位信息

Cwno、Cwpace、Carno、Carname、Carcolor、CarsbCarpho、Caradd、Cartel、Carmon

DS-2

Free

自由车位信息

Cwno、Cwpace

DS-3

Stop

停车信息

Cwno、Carno、Carat、Carin、Carout、Timetype、Cwtype、Montime

DS-4

Moneynote

收费记录

Cwno、Carno、Cartime、Moneypay、Piece

DS-5

Car

车辆信息

Carno、Carsb、Carcolor

（5）处理逻辑描述

表2-3处理逻辑描述

处理编号

处理功能

处理过程

PR-1

判断用户查询涉及的功能模块

固定车位信息模块、自由车位信息模块、停车车辆信息模块、进出车辆记录信息模块、收费记录模块：

先确定查询所涉及的功能模块；

然后，确定要查询的内容，确定查询数据流向；

最后显示查询结果。

PR-2

判断用户修改要涉及的模块，同时把相应的修改数据传到相应的模块之中

先确定更新所涉及的功能模块；

然后，把更新信息传送到相应的模块中；

最后，进行相应的更新操作。

3.概念设计阶段

3.1目标

概念结构设计师是将需求分析得到的用户需求抽象为信息结构即概念模型的过程。

它是整个数据库设计的关键。

概念结构设计步骤分为两步：

第一步是抽象数据并设计局部视图，第二步是集成局部视图，得到全局的概念结构。

3.2设计过程

（1）选择中层数据流为切入点，通常选择实际系统中的子系统；

（2）设计分E-R图，即各子模块的E-R图；

（3）生成初步E-R图，通过合并方法，做到各子系统实体、属性、联系统一；

（4）生成全局E-R图，通过消除冲突等方面。

通过分析系统的业务流图与数据流图，得到系统围绕“车辆”与“车位”之间的相互关系。

3.3阶段成果

分E-R图：

全局E-R图：

E-R图属性如下所示：

车辆：

Car（Carno,Carsb,Carcolor）Carno是主码；

固定车位：

Fixed（Cwno,Carpace,Carno,Carname,Carcolor,Carpho,Caradd,Cartel,Carmon）；

自由车位：

Freed（Cwno,Carpace）Cwno是主码；

收费：

Moneynote（Cwno,Carno,Cartime,Moneypay,Piece）Cwno和Carno是外码；

停车：

Stop（Cwno,Carno,Carin,Carout,Timetype,Cwtype,Montime）Cwno和Carno是外码；

4.逻辑设计阶段

4.1目标

逻辑结构设计的任务是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。

逻辑结构设计时一般要分为3步进行：

将概念结构转换为一般的关系、网状、层次模型；

将转换来的关系、网状、层次模型向特定DBMS支持下的数据模型转换；

对数据模型进行优化。

4.2任务与结果

4.2.1数据组织

（1）将E-R模型转换为关系模型

转换的原则是：

一个实体型转换为一个关系模式。

实体的属性就是关系的属性，实体的码就是关系的码。

对于实体间的联系则有以下不同的情况：

一个1：

1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。

三个或三个以上实体间的一个多元联系可以转换为一个关系模式。

与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。

一个1：

n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。

如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。

一个m：

n联系转换为一个关系模式。

与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。

3个或3个以上实体间的一个多元联系可以转换位一个关系模型。

与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。

具有相同码的关系模式可合并。

E-R图向关系模型转换的结果是：

Fixed（Cwno,Carpace,Carno,Carname,Carcolor,Carpho,Caradd,Cartel,Carmon）自由车位：

Stop（Cwno,Carno,Carin,Carout,Timetype,Cwtype,Carat,Montime）Cwno和Carno是外码；

（2）模型优化

关系模型Car和Moneynote由于没有出现部分函数依赖和传递函数依赖，所以以上模型已经达到3NF。

但是关系模型Stop存在函数传递依赖CarinTimetype,Timetype-/->

TimetypeMontime，因此应该将关系模型Stop转换为3NF，优化后的关系模型为“停车：

Stop（Cwno,Carno,Carin,Carout,Timetype）与费率信息：

Moneyt（Timetype,Montime）。

关系模型Fixed和Freed之间存在数据冗余，因此可以将两个关系模型合并为一个关系模型FFed,并添加识别信息，合并后的关系模型为

Ffed（Cwno,Carpace,Cartype,Carno,Carname,Carsb,Carcolor,Carpho,Caradd,Cartel,

Carmon）

模型优化后的关系模型为

车辆：

车位:

Ffe