当数据库学习者已经基本掌握了某一种数据库设计工具后，那么如何着手开始设计数据库呢？在这里我和正准备设计第一个数据库应用项目的朋友来谈一谈项目实施前的分析工作。
一、在没有谈之前，我们首先认识一下人类的记录事物的行为。理解人类记录自身社会行为活动的原因。
纵观人类社会的发展，人类记录事件的行为方式是伴随人类文明发展而不断变化，但最终目的都是对人类各种社会行为活动的历史追朔，从而分析过去和现在的关系，分析前因后果的内部联系，明确利益分配和责任承担，分解复杂事物便于驾驭复杂事物等等。因此就有了古代的节绳记事及现代的计算机等记录载体的出现，而我们要谈到的是计算机领域存储数据的数据库部分。数据库的发展是伴随着计算机的快速发展而发展，由最早的卡片穿孔和磁带顺序存储发展到后期广泛应用的磁盘随机存储形式，数据的组织模型也由早期的网状数据库模型、层次数据库模型发展到现在普遍使用的关系数据库模型，后期由于面向对象的设计思想出现又发展出面向对象数据库模型。在本文中我们重点讨论关系型数据库的设计，其他知识只简略描述。
二、设计数据库时为什么要进行设计前的分析？
有人会不要思索的回答“是设计需要当然要做需求分析”，也有人会说“这只是为了形成设计文档而做的工作”，还有人说“有点故弄玄虚，不用做分析一样可以设计数据库”，有许多的回答让我们对数据库设计分析存在的意义增加了一些疑问。
实际上在设计数据库之前的分析工作十分重要，注意我这里所讲的分析不只是客户所提出的那些需求分析，除了客户提出的要求之外，设计人员还要更广泛的考虑到社会事物普遍规律，把握事物的本质以便更好的绘制出数据库应用系统的E-R模型（实体-关系模型）。在现实的数据库设计过程中，有些设计人员好象并没做相关分析也比较快的完成了数据库的设计工作，似乎并不需要这些分析过程，然而事实上这些设计人员恰恰相反，他们以非常快的速度完成了分析的过程，这是因为他们通过长期的工作总结出了一套更快捷的分析经验，一旦所设计的内容与其经验相符合，那么经验将充分发挥作用；如果没有任何经验可以参考，那么必然会从头开始一步一步的做完分析过程。（注意：以上我所描述的设计人员并不是职业分析员，分析员的职业特点决定了分析员所针对分析工作的必要性。）分析的目的就是利用现有分析方法对人类可以认识的事物及人类各种社会行为活动概括简化并抽象为可以理解和解释的文字及图示模型，程序员往往可以根据这些被抽象化的文字与模型通过模拟再现事物及人类行为过程。用更少的文字概括分析目的就是“通过分析事物创建模型，利用模型模拟再现事物”。实际上当我们面对一个复杂的事物进行分析时，我们会发现其过程是一个比较枯燥和艰巨，分析工作的结果往往会产生大量的文档，这些文档又会随着分析的深入不断更新，程序设计员根本没有更多的精力去应对这样的工作量，这也是出现职业分析人员及各种分析工具的原因。
三、设计数据库前涉及到的分析方法。
到现在为止还没有比较完美的完全针对数据库的分析方法，当前软件工程进行需求分时通常采用结构化分析方法和面向对象的分析方法。从面向对象的语言发展的快速趋势看，已经有一部分程序员能熟练使用面向对象的系统分析方法，但在使用面向对象的分析方法对关系型数据库进行分析时，发现数据库模拟的实体却无法做到面向对象能做到的继承的特性，这实在令人感到沮丧，因此在分析某个阶段又不得不回到结构分析方法上来。（关于使用面向对象的方法进行数据库设计时内部不可调和的矛盾的认识请参考coffeewoo的专栏的这篇文章
http://blog.csdn.net/coffeewoo/archive/2010/02/05/5291582.aspx），正如“coffeewoo”所说的那样 “关系数据库的高效及方便不是面向对象数据库模式在短期内可以轻易达到的，我们不能因为倒脏水把婴儿也泼掉了” 因此我们应从务实角度出发去分析去设计，在分析阶段要尽量使用面向对象的分析方法进行分析，这种分析方法能有效的对人类个体或团体的社会事件及行为加以抽象与概括，便于认识与理解事物的本质轮廓，面向对象的分析方法指导分析人员对已经认识的事物采用图型或文字对其本质进行描述并形成文档，同时能指导程序员在计算机环境下模拟再现真实世界中的人类个体或团体的社会行为。当然这个过程也可以通过结构化分析方法来完成，但结构化分析方法显然更适合局部事物或封闭事件内的具体行为过程的分析，它往往是在已知条件不变的环境下对事物进行分析，如果当已知条件本身发生的变化，应用结构化分析方法就明显力不从心，结果只能将原来的分析描述推翻重来。但也不能说面向对象的方法就能解决所有一切，例如对于真实存在但人类无法全面认识的事物，即便采用了面向对象的分析方法也不可能准确的描述事物的本质，其分析描述结果也不足以指导程序员通过计算机模拟事物的行为。但结构化分析方法则不同，它不会因此而影响描述事物现有的行为，它完全可以对人类不完全认识的事物进行局部分析描述，而不需要受到环境其他因素的影响。这里可能涉及到与哲学相关的认识论问题，但本文里不去讨论。（注意我们这里没讨论另一种系统分析方法----原型法，这是因为原型法并不是一个具体的分析手段而是软件工程的实施手段，这里不做讨论。）本人建议在数据库设计前尽量使用面向对象的分析方法来进行分析，毕竟大量的数据库设计是针对各种商业团体，而商业团体已经明确的被社会定义为实体，完全适合采用面对象的分析方法进行分析，这也是本人推荐使用面向对象的分析方法的原因，强调一下笔者仅仅一家之言，因此只能是建议性的推荐并无绝对可言，有不同观点的朋友希望能有所交流。话回本文的主题上来，由于我们论坛的主题是 MS Access 数据库平台，我们就是针对设计 Access 数据库前的分析方法进行研讨。
四、举例进行分析过程的解析。
下面我们拿企业物资入库的局部行为活动进行分析。
我们通过与企业相关人员交流后获得了如下一份记录物资入库活动的核心文件，即物资入库单见下图所示。
有工作经验的朋友对上图应该比较熟悉，现在根据上图所示的入库单我们来初步分析该入库单所蕴含的，我们所关注的，对数据库设计有用的重要信息。我们将这些信息罗列如下：
| 描述入库单本身的信息 |
编号、日期 、合计（金额） |
| 描述入库物资的重要信息 |
物资类别、材料名称、材料规格或代号、单位、单价、金额、备注、序号 |
| 入库活动的参与者信息 |
经办人、仓库管理员、验收人、部门负责人 |
| 仓库信息 |
仓库编号 |
| 物资供应方信息 |
交来单位/部门、发票号/生产单号 |
| 其他信息 |
暂无 |
为了更形象的分析这些信息，我们在上图所示的入库单上进行了相关标注如下图所示。
通过标注后，入库单中的所有信息与我们的数据库设计的相关性开始清晰起来。如果只针对企业内部的入库行为活动进行分析，那么我们采用结构化分析可以很快的得到业务流程，我们通过与企业相关人员进行交流可以将入库业务流程绘制成如下流程图。
上图分成三个栏位即 文档来源与输入、处理过程、数据存储与输出。来访的朋友如果对流程图不熟悉则可以在网上找一些相关资料做以参考。在我画的上图中我们重点来看文档来源与输入一栏，这一栏中包含了所有涉及数据库设计的重要线索，下面我们同时结合入库单凭证进行分析。
通过上面的流程图，我们可以找到即几个重要的已知条件即信息来源，我们将他们枚举出来。
1、供应商提供的发票。
2、与发票内容对应的到货记录。
3、仓库编号信息。
4、交来物资货品的供应单位信息。
5、物资分类定义的标准，就是规定的物资类别。
6、物资货品到货后的检验信息。
7、接收货品的公司内部职员信息。
这些信息数据通过入库管理的处理后从而生成了入库单。我们再绘制一张图就是 DFD 数据流程图，通过这张图可以让我们更清楚的理解这些信息数据被加工的过程。
数据流图四种基本图形符号：
 ：箭头，表示数据流；
〇：圆或椭圆，表示加工；
= ：双杠，表示数据存储；
□：方框，表示数据的源点或终点。 |
但 DFD 图是描述数据加工过程的流程图，它的重点在数据被加工的前后过程的描述上，而数据库设计的重点也是通过存储数据表中的数据来描述真实世界里各种实体的属性状态，显然DFD 图不能描述实体属性的，靠DFD图实现数据库模型当然是不可行的，现阶段我们还只能采用E-R(实体-联系)模型来来实现对实体的属性状态及实体之间的联系进行描述。下面我们就采用E-R图对企业物资入库管理活动进行分析。（本人强调：软件设计如果使用结构化分析方法来进行分析时，业务流程图和数据流图必然是强有力的分析工具，我们不能说E-R图比这两种工具更好，因为每种工具都有它自己的适用对象，我们不能割裂开说谁好谁不好，而是应该将它们有机的联合起来。）
在没有利用 E-R 图 进行数据库建模分析之间前我们先确定物资入库管理活动的边界及找到边界中所有值得关注实体。（注： 业务活动的边界≠系统边界）
我们通过上面的分析可以得知“物资入库活动”的边界存在于企业内部，由企业内不同职责的雇员与所传递的文档共同参与构成。
在这个活动边界中涉及到的实体有 包括采购员、检验员、仓库管理员、采购主管的“雇员”，采购订单、质检报告、 到货记录、发票、物资仓库。我们针对这些实体一一分析。
●将采购员、检验员、仓库管理员、采购主管归纳为采购商的“雇员”是比较容易理解的，现实世界中我们也是用这样的语言及文字称呼与认识的，这种归纳在软件分析中称之为抽象或泛化如下图所示。
● 采购订单实体是采购行为的重要文档，它也是物资入库管理活动中各种文档的信息原始来源。我们接下来分析采购订单的所有信息并以属性形式来描述。
我们找到采购商提供的产品购销合同样本如下图所示，（补充说明：通过与采购商的相关人员交流后得知产品购销合同、购销订单、购销协议虽然都是购销双方针对产品进行交易活动的书面约定，但还有一些不同。其中购销合同的约束条款更加全面、具体更容易实施；其中购销协议约束效力就不如购销合同那样具体，它的自由度比较大，它往往是作为规范购销活动的一个基础框架。而购销订单则是约定每一次购销渗活动的重要细节，多数是约定所购销产品的项目、结算金额、交货地点、交货期等。一般情况下购销订单都是购销协议或购销合同约定下的子文档，附属于协议或合同，但也并不绝对。）
（注：为了缩小图的尺寸，我没有将合同最后购销双方签字盖章的部份放到图中。）
虽然我们讨论的是购销订单，但以更加规范的购销合同来讨论会更好一些，我们重点来关注与物资入库活动相关的在合同中约定的重要信息。
被关注的信息：供应商名称、需方名称、产品信息、验收标准、交货期。
实际上入库活动真正需要依据的是产品到货记录和检验报告，而产品到货记录和检验报告的信息数据来源同样是产品购销合同（订单），这也是我强调为什么购销合同是这些购销活动及相关的活动的最基础的数据来源的原因。我为什么一直在强调这个信息来源，其原因是我们是准备使用计算机来存储和管理这个信息数据，而计算机存储和使用这些数据的优点是一次录入信息数据后可以多次提取和使用这些数据；在我们在企业经营活动中，每一次检验到货，每一次办理入库都会重复性书写相关信息，因此效率不高。这里我们只要理解“信息来源”这一概念就可以了，这一概念将为Access 人机交互设计提供思路。
下面我们绘出 采购订单实体的抽象示意图
从图上可以看出“订单”实体列出了十个重要属性，其中“货品”属性又有七个重要子属性。
为了使上述分析更有层次性，我们往往把像“货品”这样具有子属性的属性视为一个与“订单”实体相联系的另一个实体，我们为这个新实体命名为“货品明细”。而“订单”实体是通过一个“订单编号”这一标识性的属性（在“订单”实体中它是“主键”用简写PK表示）与“货品明细”实体建立联系，为了保证这个联系的明确性我们在“货品明细”实体中显性的增加了一个“订单编号”这一属性（在“货品明细”实体中它是“外键”用简写FK表示）。
听着有一点不理解，实际上很容易理解。我到现实世界中来理解它：
在 现实世界中当我们签定了“订单编号”为“2010052001”的订单后并没有明确订购的货品有哪些，而是通过增加了一个附件文本约束了所订购的货品，这个附件我们就可以视为所订货的“货品明细”，为了与其他订单区别开我们会在附件上明确的标注上“订单编号：2010052001”。 这时这个“订单编号”就是“订单”与“附件”的联系纽带。
回过头来我们再理解上面的分析，就可以理解了。（分析小经验：如果当前实体中的信息通过其中一个标识性的属性而从属于另外一个实体时，那么指定的标识性的属性就是外键）通常采购员将上面描述的“货品明细”称之为“订单明细”而“订单”和“订单明细”从文字字面上更容易理解为从属关系了。下面我们重新画出这个简单的E-R图。
但是这个简单的实体联系图并不简单，它完整的展示了最基本的二个实体之间的联系模型，即通过“订单编号”实现了一对多的联系方式，这就是大家所认识到的一张订单可以订购多种货品实体联系模型。
-- 未完待续 -- 2010-6-20
