机房收费系统--数据库设计

超、凢脫俗 2022-08-06 17:05 180阅读 0赞

在机房收费系统代码实现过程中，我们第一步要做的是设计数据库；翻阅师哥师姐们的博客，一个正规化的数据库设计应该考虑数据库设计范式以及关系模式的一些设计理念，于是又重新回顾了一番。

## 【E-R图】 ##

实体联系图最重要的是抽象实体，寻找联系，最后根据属性，考虑三范式要求，细分实体与联系。但并不是实体与联系分的越细化越好，只要能够满足需求就好 。下面是简单做的实体图：

![Center][]

**关系模型（由于缺乏波浪线，黑色字段为外键）：**

学生（卡号，学号，**用户号**，密码，姓名，性别，系别，班级，注册日期，金额，状态（使用/未用），备注）

注销（**卡号，用户号**，注册日期，返还金额，操作员姓名）

用户（用户号，密码，等级，姓名，性别，电话）

充值（**卡号，用户号**，充值金额，充值日期，充值时间）

结账（**用户号，计算机号**，注销卡数，充值金额，总金额）

<table></table>

电脑（电脑编号，**学生号，用户号**，账户名，IP地址）

设定基础数据（**用户号，计算机编号**，单位收费金额，递增时间，至少上机时间，准备时间，至少消费金额）

上机（**卡号，电脑编号**，上机时间，上机日期，备注）

下机（**卡号，电脑编号**，下机日期，下机时间，消费时间，消费金额，现有金额）

**问题一**：主外键寻找

主键是可以唯一标识一个或多个字段。主外键的作用，可以保证数据的一致性，增强数据的联系性。

对于实体图，1：N关系时，关系为N那一端的实体存在外键，且外键是关系为1那端实体的主键。例如：用户注册学生卡号时为1：N关系，学生字段中要存在“用户号”字段。

对于1:1型，实体双方均要将对方主键作为自己的外键。

联系的外键为两边实体的主键，主键为两个外键共同组成。

## 【三范式】 ##

数据库范式的应用优化数据结构，减少数据冗余，让数据变得更加明确简洁，有条理；降低错误数据和垃圾数据出现的机会。高层次的范式必定会实现低层次的范式，例如，第二范式一定满足第一范式，第三范式必定满足第二和第一范式。

实现的整体的实现思想就是分解，让表中的字段减少，表内的关系增强，达到高内聚低耦合的效果。

**第一范式（1NF）**：关系模式R中每一个原子都是不可分割的原子值。

简单理解就是一个关系中所有的字段是不可再分的。

例如，在机房收费的字段中会碰到这样一个字段名称DateTime，实现以后是会是：2015-02-07 23:55，很显然它实现以后并不是不可再分的，还可以分成日期和时间两个字段。

**第二范式（2NF）**：关系模式是1NF，每个非主属性完全依赖于候选键（都可以用来做主键的字段），就满足第二范式。

作用：可以减少冗余和异常现象

例如：学生表字段中

学生（卡号，学号，用户号，密码，姓名，性别，系别，班级，注册日期，金额，状态（使用/未用），备注）

卡号和学号均是候选键，FD:（卡号，学号）-->（姓名，性别）,存在另一字段，FD：（学号）-->(姓名，性别)，所以存在局部依赖，不满足第二范式。可利用分解的方法：

学生（学号，姓名，性别，系别，班级，年级，备注）

卡（卡号，密码，注册日期，金额，状态）

**第三范式（3NF）**：关系模式R是1NF，每个非主属性都不传递依赖于R的候选键。

在下机字段中：

下机（**卡号，电脑编号**，下机日期，下机时间，消费时间，消费金额，现有金额）

（下机日期，下机时间）依赖于（卡号，电脑编号），而（消费时间，消费金额，现有金额）依赖与（下机时间），这样就构成了传递依赖，是不符合第三范式的。

修改：

下机（**卡号，电脑编号**，下机日期，下机时间）

消费（消费时间，消费金额，剩余金额）

总结：万事有利也有弊，三范式的使用带来诸多便利的情况下，还伴随着很多问题：操作困难，查询一条记录要涉及很多表。范式越高实现越困难，一般设计要求只满足三范式即可。

## 【视图与存储过程】 ##

解决范式设计下存在的弊端，视图和存储过程无疑成为好帮手。

视图是虚拟的表，它真实存储的是查询语句而不是数据，表中记录是通过查询语句执行后得到的查询结果。这些数据来源于已经存在的表和字段，并且视图的数据会伴随着真实表的改变而发生改变。

创建举例(将学生表和卡组合在一起)：

create view StuAndCard                 ‘创建视图名

as

select student.stuID,student.Name,card.cardID,card.password      ’需要选出的字段名称

from student

join cardID on student.cardID=card.cardID      ‘连接条件

go

查询语句跟表的语句是相同的。

存储过程是预先写好的的能实现某功能的T-SQL程序，是一种数据库对象，并得到广泛的应用。用户自定义存储过程，可以通过输入参数，向客户端返回表格，结果或消息，也可返回输出参数。

实现语法：

create proc pr\_select

as

select \* from student

go

执行：exec pr\_select

从执行上看，一个存储过程就是一个批处理，为实现某一功能，组合一系列的T-SQL语句。

## 【总结】 ##

数据库设计，在多实践的基础上才能不断让自己的数据变得成熟，另外，范式应用一定要适度，千万不能因为高范式让程序执行变得过于复杂。

[Center]: /images/20220805/b8c5584a99e34b678970ed27edaa068a.png

发表评论取消回复

表情：

评论列表（有 0 条评论，180人围观）

还没有评论，来说两句吧...

相关阅读

相关数据库设计说明书——机房收费系统

数据库设计说明书 1引言 1.1编写目的说明编写这份数据库设计说明书的目的，指出预期的读者。本数据库设计说明书说明了机房收费系统的数据库

短命女/ 2022年09月19日 12:29/ 0 赞/ 188 阅读

相关概要设计说明书——机房收费系统

概要设计说明书 1引言 1.1编写目的根据软件需求说明，建立目标系统的总体结构和模块间的联系；定义数据库和数据结构；定义目标系统的外部接口包括用户界面

「爱情、让人受尽委屈。」/ 2022年09月19日 05:26/ 0 赞/ 295 阅读

相关机房收费系统数据库设计

机房收费系统拖了这么久，一直有畏惧的心理，加上最近我们专业一系列的期中考试，一直都没有开始。今天终于把一些重要紧急的事情处理完毕，开始着手机房收费系统这个重要不紧急的事

た入场券/ 2022年09月18日 05:00/ 0 赞/ 181 阅读

相关机房收费系统——数据库设计说明书

数据库设计说明书 1引言 1.1编写目的本文档描述了机房收费系统数据库的设计，提供了数据库设计的可视性及软件支持所需的信息，应用于机房收费系统开发前期，为后期的

迈不过友情╰/ 2022年08月09日 15:52/ 0 赞/ 235 阅读

相关概要设计说明书——机房收费系统

概要设计说明书 1引言 1.1编写目的根据软件需求说明建立目标系统的总体结构和模块间的联系；定义数据库和数据结构；定义目标系统的外部接口包括用户界面；设计系统的

怼烎@/ 2022年08月08日 15:57/ 0 赞/ 288 阅读

相关机房收费系统--设计模式思考

今天与阿真同学简略讨论了一下外观模式和抽象工厂+反射+配置文件在机房重构中的应用，引发了几个简单的思考，现与君共勉： 1. B

╰+攻爆jí腚メ/ 2022年08月08日 03:21/ 0 赞/ 154 阅读

相关机房收费系统--数据库设计

在机房收费系统代码实现过程中，我们第一步要做的是设计数据库；翻阅师哥师姐们的博客，一个正规化的数据库设计应该考虑数据库设计范式以及关系模式的一些设计理念，于是又

超、凢脫俗/ 2022年08月06日 17:05/ 0 赞/ 181 阅读

相关机房收费系统合作——再看数据库设计

机房合作我负责了最简单的D层，接口层，工厂层。反正D层是我来写，于是数据库索性也就顺便设计了。已经是第三次敲机房收费系统了，每次都是相隔半年左右吧。需求搞得透透的了，数

红太狼/ 2022年08月05日 00:56/ 0 赞/ 161 阅读

相关《机房收费系统》概要设计说明书

1引言 1.1编写目的这篇文档主要目的是为了开发此系统做一个总体的架构和数据结构设计，经评审后进一步细化，分别对每一个模块进行详细细化的编码方案、接口和数据库方面

港控/mmm°/ 2022年05月28日 11:56/ 0 赞/ 280 阅读

相关《机房收费系统》详细设计说明书

1引言 1.1编写目的详细设计说明书是在概要设计的基础上进一步明确系统结构，表示软件结构的图表，完成算法设计、数据结构设计、物理设计等，详细的描述的逐个模块，包括算法

r囧r小猫/ 2022年05月27日 08:36/ 0 赞/ 311 阅读