【序言】
浩浩荡荡的机房合作之路开始了，组长分配好任务，数据库这部分由我负责，这可是很好的一个再次学习机会，个人版机房重构过程中的数据库是改了又改，这样违背了开发的原则，也使得整个开发过程失去章法，乱作一团，效率低下；那么，通过这次合作，再来重温数据库的知识吧。
【明确方向——为什么要进行数据库设计】
我们现在所用到的数据库大部分是关系型数据库，本文中所提到的数据库均指关系型数据库，数据库理解起来就是实现对数据的管理，是对数据管理的高级阶段，进行数据库设计的原因有以下几点：
1、充分体现用户需求
数据库设计是在数据字典的基础上进行的，而数据字典是系统分析阶段的结果，在系统分析阶段需要尽可能地“理解”和“表达”用户需要，明确需求，进行业务流程分析，数据流程分析，产生数据流图，根据数据流图再产生数据字典，数据库是为应用服务的，满足应用系统的业务需求，准确地表达数据间的关系。
2、规范化，提高性能
良好的数据库设计对于一个高性能的应用程序非常重要，就像一个空气动力装置对于一辆赛车的重要性一样。如果一辆汽车没有平滑的曲线，将会产生阻力从而变慢。关系没有经过优化，数据库无法尽可能高效地运行。应该把数据库的关系和性能看作是规范化的一部分。
3、易于维护，方便扩展
数据库应该易于维护。这包括只存储数量有限的（如果有的话）重复性数据。如果有很多的重复性数据，并且这些数据的一个实例发生一次改变（例如，一个名字的改变），这个改变必须对所有的其他的数据都进行。为了避免重复，并且增强维护数据的能力，我们可以创建可能的值的一个表并使用一个键来引用该值。在这种方式中，如果值改变了名字，这个改变只在主表中发生一次，所有的其他表的引用都保持不变。
【蓄势待发——数据库设计背景】
需求分析阶段：分析用户活动，产生业务流程图→确定系统f范围，产生系统关联图→分析用户涉及的数据，产生数据流图→分析系统数据，产生数据字典；下面是过程中的图，不足之处请大家多多指点
：
数据流图（机房收费系统）：
顶层图：
一级细化图（部分）：
数据字典：
【厚积薄发——数据库设计进行】
1. 概念设计阶段
概念结构设计的目标是产生反映全用户信息需求的整体数据库概念结构，即概念模型。概念模型独立于数据库逻辑结构，独立于支持数据库的具体的DBMS,不考虑计算机软硬件技术细节，方便与用户的交流。描述概念模型的有力工具是“实体-联系”方法（Entity-Relationship，缩写为E-R），简称E-R方法。它采用E-R图模型将现实世界的信息结构统一用实体、属性及实体之间的联系来描述。
设计人员仅从用户角度看待数据及处理需求和约束，之后产生一个反映用户观点的概念模型，概念模型能充分反映现实世界中实体间的联系，又是各种基本数据模型的共同基础，从用户观点出发，对数据建模，是数据库设计人员与用户之间进行交流的工具。
E-R图：
局部：
整体（缺少属性）：
2. 逻辑设计阶段
逻辑设计的目的是得到一个与计算机软硬件的具体性能无关的全局概念模式，其主要任务是将概念结构转换成特定DBMS所支持的数据模型，在功能、性能、完整性和一致性约束及数据库可扩充性等方面均应满足用户提出的要求。逻辑设计的过程就是将概念设计的结果（E-R图）转换为某个DBMS所支持的数据模型，并对其进行优化的过程。
逻辑设计是从数据库实现的观点出发，对数据建模，是数据库设计人员与应用程序员之间进行交流的工具。（用到规范化和三范式，将在下一篇博客中讲述）
逻辑模型主要有层次、网状和关系模型三种。
关系模型：
3. 物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。通常包括存储记录的格式设计、存储方法设计、访问方法设计、完整性和安全性考虑四方面的内容。
4．创建数据库（Sql 语句，存储过程，视图等）
【扬帆远航——数据库设计后续】
数据库设计好之后就是实现，运行与维护，数据库投入运行标志开发任务的基本完成和维护工作的开始，并不意味着设计过程终结，由于应用环境在不断变化，数据库运行过程中物理存储也会不断地变化，所以对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。
一个规划和设计良好的数据库的优点是众多的，它也证实了这样一个道理，前期做的工作越多，后面所要做的就越少。数据库与需求是相辅相成的，所以，多花点时间（数据库设计最起码要占用整个项目开发的40%以上的时间）来理需求和设计数据库是值得的，也是必需的。
【总结】
温故而知新，路漫漫其修远兮，吾将上下而求索！
不足之处欢迎大家多多提意见~~