机房收费系统数据库概念结构设计
数据库的设计大致流程想必大家都知道，不知道的也能很容易的在网上找到相关的资料，通常，我们将数据库设计分为6个阶段，即需求分析阶段、概念结构设计阶段、逻辑结构设计阶段、物理结构设计阶段、实施阶段、运行和维护阶段。
本次我们不谈数据库设计的理论知识，主要是以机房收费系统的数据库设计为背景来说明数据库的概念结构设计是如何产生的，当然包括了数据库设计中最难的需求分析了，否则就谈不上什么数据库的概念结构设计了。
因为我们都已经做过一遍了，而且从一开始我们就是照着系统原型做的，没有从无到有的过程，所以无法体会真正的需求分析是什么样的，也就不会去思考待开发系统的的各种功能是如何抽象出来的。下面我就以我个人的理解来开始机房收费系统的数据库的设计之旅。
机房收费系统是给机房的值班人员和管理人员使用的，因此系统的用户将会是一个实体，为了满足客户需要，还要给用户进行权限设置。系统要管理的信息自然是学生本身的信息和学生因上机所产生的数据记录，因此学生也是一个必不可少的实体。
很多人因为三范式的原则，将原来学生信息中的有关卡信息的部分抽出来，形成了另一个实体，即卡实体。这样做提高了数据库的灵活性，在某位学生的卡丢了之后，即可将丢失的卡的信息从数据库中删除，将学生信息中的卡号更新即可。但是在系统的实际使用过程中，这样的设计并无多大优势，反而降低了查询效率，因为涉及到了两张表。有人说用视图就可搞定，但是相对于一张表来说，那就相对麻烦了点。
我们接着分析，系统用户操作会产生工作记录，学生在机房上机会产生上机记录，系统用户拥有对卡的注册、注销和充值的权限，因此会产生相应的数据信息，这样就差一个系统运行的基础数据设置了，这些数据信息需要一张表去存储，因此基本的数据库实体图就可以画出来了。
上面的图是极其简单的一张图，可能还有很多错误，毕竟还没有具备熟练准确的对待开发系统的进行抽象分析的能力。当然上面的图并没有给出各个实体的属性，下面我用power designer软件画出系统的概念结构图，当然这个图也不是标准的CDM，主要目的是给大家展示出各个实体的属性。
总之数据库的设计最难的是初期的需求分析阶段，也许需要开发方和客户方经过很长时间的反复讨论和交流，方才能够产生最终的结果，并且在后续的开发过程中也许还要不断的进行改进和完善。当然严格来讲，我这里说的也不能算是真正意义上的数据库设计，因为系统的蓝本和数据库蓝本的存在，会干扰我们的思考和分析，但这就是学习，要经历这个过程，亲手去做一个数据库，才会有深刻的体会，因为站在岸上永远也学不会游泳！
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
