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

来源:Oracle认证    发布时间:2012-11-12    Oracle认证视频    评论

在Internet中,在银行、政府机关、公司、学校、超市、药店等地方,都有许多数据库实例。这类数据库设计的过程一般可以分解成下面几个步骤:

● 定义目标――不要由于觉得显而易见而一笑置之,这个很重要,因为很多项目都是由于开发者不清楚用户实际上要做什么或需要什么,而冒然断定或没有能够很好地听取用户的正确意见或全部意见而带来的麻烦。在这个阶段,我们要为最终创建的系统定义功能、性能、面向客户群,并写需求报告。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

视频学习

我考网版权与免责声明

① 凡本网注明稿件来源为"原创"的所有文字、图片和音视频稿件,版权均属本网所有。任何媒体、网站或个人转载、链接转贴或以其他方式复制发表时必须注明"稿件来源:我考网",违者本网将依法追究责任;

② 本网部分稿件来源于网络,任何单位或个人认为我考网发布的内容可能涉嫌侵犯其合法权益,应该及时向我考网书面反馈,并提供身份证明、权属证明及详细侵权情况证明,我考网在收到上述法律文件后,将会尽快移除被控侵权内容。

最近更新

社区交流

考试问答