实践出真知 有关数据库设计经验简介--.doc

　　实践出真知 有关数据库设计经验简介 如果将数据库设计比作是福尔摩斯破案，根据各种条件，限制，规则，抽丝拨茧，寻找其中的相互联系，一步一步深入案件的中间，最终解决案件。但破案首先需要有方法，那么对于数据库设计目前以使用已久的一系列设计数据库结构的成熟方法（比如：规范化）都可以作为破案所需方法的良好的根基。实际上，这些方法几乎都是经典的设计方法，因此，在进行数据库设计的时候，遵循这些方法并不会感觉到太困难。正如同我们所知，我们可以直接将你按方法的设计可以直接转变成SQL SERVER表。 但是，除非你只是为了抓一个现显的小偷，否则需要各种条件，规则，限制，联系都必须考虑到。如同我们在需要统一的考虑数据库解决方案中的分布、冗余、集群、24/7支持、存取过程、触发器、约束和完整性等问题的时候，就需要引入数据库结构的技术。这种技术没有提供物理地实现数据库的方法，但可以通过它来选择一种最佳的方法。 在现代按照不同的设计可以将整个数据库系统按不同服务需求分解成不同的组成部分，而不是使用一种技术完成整个的任务。它们可以分为： ● OLTP（联机事务处理）－－OLTP数据库存储当前业务运作所需要得数据，它的主要目的是使当前的公共数据完整合理，要达到这个目的需要遵循两条原则：1、每一个当前数据块只能存储在一个可供编辑的位置，此处的如何改动都会反映倒所有使用这一数据的地方。2、提供事务支持，以便对数据库进行多项更改一起生效。如果事务中的一个更改失败了，其他的所有更改也都不允许生效，事务中止，所有操作回滚。 ● 业务数据存储（Operational Data Store，ODS）――用于日报表的汇总数据。这些数据经常取之几个完全不同的地方，并进行了一定程度的预汇总，以便节省查询的时间。它的目的是向用户提供操作数据并跟踪近期的趋势，以便做出决策。 ● 数据仓库（Data art）――为汇总而优先的专用数据存储，用于特定的场合，其存储的内容作为数据仓库的子集。数据集市通常使用被成为OLAP的技术进行处理。它通常为一个公司的特定需求，或一个机构的特定业务而建立的，一般有两种特殊的数据库结构：星型模式和雪花模式。 对于以上四种类型，最终采用的数据库总体结构完全取决于该数据库将要解决的问题规模。 现在的大部分计算机系统中，数据库是核心。即使不是一个以数据库为核心的系统，也拥有一个数据存储的需要。软件归根结底，也是对数据的处理。 在Inter中，在银行、政府机关、公司、学校、超市、药店等地方，都有许多数据库实例。这类数据库设计的过程一般可以分解成下面几个步骤： ● 定义目标――不要由于觉得显而易见而一笑置之,这个很重要，因为很多项目都是由于开发者不清楚用户实际上要做什么或需要什么，而冒然断定或没有能够很好地听取用户的正确意见或全部意见而带来的麻烦。在这个阶段，我们要为最终创建的系统定义功能、性能、面向客户群，并写需求报告。 ● 逻辑设计――为了达到最终的目标而，通过对用户业务的分析，实施的逻辑设计 ● 物理设计――利用逻辑设计的成果，并将其转换成一个真正的实现。这个阶段涉及到数据库系统如何物理地实现以及我们需要使用那些硬件和软件。 ● 物理实现――项目的实现阶段涉及实际的物理数据、数据库服务器的制定以及编写存取数据的代码。 ● 复查――评定是否达到最终目标的过程。大多数的项目都忽视了这个阶段，原因是耗时太长，并且引发不起人们的一点兴趣：测试、编写文档以及完成一些不愿意做，但又必须做的事情。这个阶段，应该有一个利用用户反馈信息的方法和维护更改所有问题的计划。 在用户使用过程中，用户实际只要能够浏览和处理他们所需的数据，就很少对原始数据或者用来存取数据的实际接口感兴趣。项目设计分析人员，可能因为这样那样原因，往往使一些系统使用起来非常笨拙，考虑欠佳的原因。 下面几点是我从学校、从同事、从书籍，从实际设计中得到的一些概念设计经验之谈： 1、定义目标阶段：信息采集，收集数据库项目中的信息。 a、在这里应该尽量避免一开始就设计结构。即使你具有数据库设计的经验，也不要在这里定义表和字段等等，你应该对它们逐步地进行处理。在听取用户讲解其想法和需求，并归纳出该项目应该应该完成的任务之前，不要深入到某一个具体的部分。我们常常在对所完成的任务没有足够了解之前，就对它实施一种结构和一种解决方案，这样即不利于客户也不利于我们。 b、在分析过程中，尽快地将所需的数据编写成文档是一个很好的习惯。例如：在公司，因为一个员工生病或者另谋高就，为了不对开发速度造成很大的影响，接替人员需全力以赴地了解项目的全部内容，能够为其提供帮助的唯一途径就是全部的信息文档。因此你了解编写文档重要性，要求是不把任何项目内容留在你的脑袋中。在对用户需求进行记录时应注意： △ 维护一套共享的系统设计和说明书文档