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