有关数据库概念设计几点见解经验谈(2)

● 逻辑设计――为了达到最终的目标而，通过对用户业务的分析，实施的逻辑设计

● 物理设计――利用逻辑设计的成果，并将其转换成一个真正的实现。这个阶段涉及到数据库系统如何物理地实现以及我们需要使用那些硬件和软件。

● 物理实现――项目的实现阶段涉及实际的物理数据、数据库服务器的制定以及编写存取数据的代码。

● 复查――评定是否达到最终目标的过程。大多数的项目都忽视了这个阶段，原因是耗时太长，并且引发不起人们的一点兴趣：测试、编写文档以及完成一些不愿意做，但又必须做的事情。这个阶段，应该有一个利用用户反馈信息的方法和维护更改所有问题的计划。

在用户使用过程中，用户实际只要能够浏览和处理他们所需的数据，就很少对原始数据或者用来存取数据的实际接口感兴趣。项目设计分析人员，可能因为这样那样原因，往往使一些系统使用起来非常笨拙，考虑欠佳的原因。

下面几点是我从学校、从同事、从书籍，从实际设计中得到的一些概念设计经验之谈：

1、定义目标阶段：信息采集，收集数据库项目中的信息。

a、在这里应该尽量避免一开始就设计结构。即使你具有数据库设计的经验，也不要在这里定义表和字段等等，你应该对它们逐步地进行处理。在听取用户讲解其想法和需求，并归纳出该项目应该应该完成的任务之前，不要深入到某一个具体的部分。我们常常在对所完成的任务没有足够了解之前，就对它实施一种结构和一种解决方案，这样即不利于客户也不利于我们。

b、在分析过程中，尽快地将所需的数据编写成文档是一个很好的习惯。例如：在公司，因为一个员工生病或者另谋高就，为了不对开发速度造成很大的影响，接替人员需全力以赴地了解项目的全部内容，能够为其提供帮助的唯一途径就是全部的信息文档。因此你了解编写文档重要性，要求是不把任何项目内容留在你的脑袋中。在对用户需求进行记录时应注意：

△ 维护一套共享的系统设计和说明书文档。文档应该主要包含：设计会议记录，记录口头更改需求的文档和最终的所有说明书，比如，功能、技术、测试等各方面的内容。

△ 除了规范的文档外，要为所有的信息而开发和维护一个公共资料库。

△ 花一些时间召开会议，在客户讲述时，尽量不要发表你个人的意见。让客户畅所欲言，注意倾听客户的每一个建议、请求或想法。

△ 注意那些你添加的而没有得到用户许可的信息。

△ 应早确立项目使用的范围，并始终牢记在心。这样做可以避免日后开发的项目过大或遗漏了有用的东西。编写项目操作范围的说明书（任务说明或任务对象），用以来描述项目的参数。该说明书应该在项目的设计、实现过程中不断地进行协商、对比、完善，直到最后完成为止。若项目的对象和最终目标在这个阶段不予确认，或者没有记载任何内容，当你和客户的想法出现不一致时，就很可能与用户发生冲突。因此，要确保客户对你将要实现的系统十分清楚，并使用清晰易懂的语言进行描叙，尽可能详细描述项目所有内容。

c、在整个数据库设计期间，客户通常会对字段名、字段定义、业务规则、用户界面和颜色做一些修改，为此，你要做好思想准备。无论客户有什么要求，都应该给予支持，这个项目最终要由用户控制使用，所以你必须要使系统能够灵活地适用各种用途的变化，不管是次要的还是主要的，但对于这些客户的想法都要在客户在设计阶段对你做出的决策确认签字的基础上。

因为在任何时候，客户都有可能对你说，“怎么这里少了一项”、“我根本没这样说”等等。如果你在说话时，手中没有文档为自己撑腰，就会带来很多麻烦。因此，保存文档，如果你做出的决策与客户所说的不同，就应该利用文档来证明自己决策的正确性。

d、数据库原型作为公司与客户签定合约时相互交流信息所使用的画面。每次协商都要借助于开发的原型，它可以很好的反映开发商最终开发的产品。数据库设计者可以利用其为工作模型，设计文档所使用，避免用户所需信息的缺失。

e、与客户商谈时应注意，不要抢先发言；威胁客户；以及在他们向你讲述他们想要做的事情之前大谈你的看法，而不顾用户的期望都有可能造成项目的失败。与客户进行友善地商谈是我们获得设计信息得坚实基础。如果基础不牢靠，最终的产品也不会成功。在向客户提出：

1、谁使用这些数据？

2、如何使用这些数据？

3、客户需要那些报表？

4、以前数据处理办法？

5、由那些规则控制数据的使用？

这几个问题都很有必要了解清楚。