有关数据库设计经验简介
数据库设计经验分享
注：
直接引自赛迪网技术社区 » 数据库综合技术专区下一篇文章，
觉得还可以没有经过修改．部分观点可能描述不够准确,但并不阻碍我们分享好经验.
如果将数据库设计比作是福尔摩斯破案，根据各种条件，限制，规则，抽丝拨茧，寻找其中的相互联系，一步一步深入案件的中间，最终解决案件。但破案首先需要有方法，那么对于数据库设计目前以使用已久的一系列设计数据库结构的成熟方法（比如：规范化）都可以作为破案所需方法的良好的根基。实际上，这些方法几乎都是经典的设计方法，因此，在进行数据库设计的时候，遵循这些方法并不会感觉到太困难。正如同我们所知，我们可以直接将你按方法的设计可以直接转变成SQL SERVER表。
但是，除非你只是为了抓一个现显的小偷，否则需要各种条件，规则，限制，联系都必须考虑到。如同我们在需要统一的考虑数据库解决方案中的分布、冗余、集群、24/7支持、存取过程、触发器、约束和完整性等问题的时候，就需要引入数据库结构的技术。这种技术没有提供物理地实现数据库的方法，但可以通过它来选择一种最佳的方法。
在现代按照不同的设计可以将整个数据库系统按不同服务需求分解成不同的组成部分，而不是使用一种技术完成整个的任务。它们可以分为：
● OLTP（联机事务处理）－－OLTP数据库存储当前业务运作所需要得数据，它的主要目的是使当前的公共数据完整合理，要达到这个目的需要遵循两条原则：1、每一个当前数据块只能存储在一个可供编辑的位置，此处的如何改动都会反映倒所有使用这一数据的地方。2、提供事务支持，以便对数据库进行多项更改一起生效。如果事务中的一个更改失败了，其他的所有更改也都不允许生效，事务中止，所有操作回滚。
● 业务数据存储（Operational Data Store，ODS）――用于日报表的汇总数据。这些数据经常取之几个完全不同的地方，并进行了一定程度的预汇总，以便节省查询的时间。它的目的是向用户提供操作数据并跟踪近期的趋势，以便做出决策。
● 数据仓库（Data Warehouse）――保存整个公司的重要数据和历史数据，它的目的一是利用公司现存历史信息做出决策；二是从数据库系统的角度将活动的事务处理从报告中分力出来，以便更加细致地进行查询，而不会影响用户在OLTP系统中创建和存储的数据的能力。
● 数据集市（Data Mart）――为汇总而优先的专用数据存储，用于特定的场合，其存储的内容作为数据仓库的子集。数据集市通常使用被成为OLAP的技术进行处理。它通常为一个公司的特定需求，或一个机构的特定业务而建立的，一般有两种特殊的数据库结构：星型模式和雪花模式。
对于以上四种类型，最终采用的数据库总体结构完全取决于该数据库将要解决的问题规模。
现在的大部分计算机系统中，数据库是核心。即使不是一个以数据库为核心的系统，也拥有一个数据存储的需要。软件归根结底，也是对数据的处理。
在Internet中，在银行、政府机关、公司、学校、超市、药店等地方，都有许多数据库实例。这类数据库设计的过程一般可以分解成下面几个步骤：
● 定义目标――不要由于觉得显而易见而一笑置之,这个很重要，因为很多项目都是由于开发者不清楚用户实际上要做什么或需要什么，而冒然断定或没有能够很好地听取用户的正确意见或全部意见而带来的麻烦。在这个阶段，我们要为最终创建的系统定义功能、性能、面向客户群，并写需求报告。
● 逻辑设计――为了达到最终的目标而，通过对用户业务的分析，实施的逻辑设计
● 物理设计――利用逻辑设计的成果，并将其转换成一个真正的实现。这个阶段涉及到数据库系统如何物理地实现以及我们需要使用那些硬件和软件。
● 物理实现――项目的实现阶段涉及实际的物理数据、数据库服务器的制定以及编写存取数据的代码。
● 复查――评定是否达到最终目标的过程。大多数的项目都忽视了这个阶段，原因是耗时太长，并且引发不起人们的一点兴趣：测试、编写文档以及完成一些不愿意做，但又必须做的事情。这个阶段，应该有一个利用用户反馈信息的方法和维护更改所有问题的计划。
在用户使用过程中，用户实际只要能够浏览和处理他们所需的数据，就很少对原始数据或者用来存取数据的实际接口感兴趣。项目设计分析人员，可能因为这样那样原因，往往使一些系统使用起来非常笨拙，考虑欠佳的原因。
下面几点是我从学校、从同事、从书籍，从实际设计中得到的一些概念设计经验之谈：
1、定义目标阶段：信息采集，收集数据库项目中的信息。
a、在这里应该尽量避免一开始就设计结构。即使你具有数据库设计的经验，也不要在这里定义表和字段等等，你应该对它们逐步地进行处理。在听取用户讲解其想法和需求，并归纳出该项目应该应该完成的任务之前，不要深入到某一个具体的部分。我们常常在对所完成的任务没有足够了解之前，就对它实施一种结构和一种解决方案，这样即不利于客户也不利于我们。
b、在分析过程中，尽快地将所需的数据编写成文档是一个很好的习惯。例如：在公司，因为一个员工生病或者另谋高就，为了不对开发速度造成很大的影响，接替人员需全力以赴地了解项目的全部内容，能够为其提供帮助的唯一途径就是全部的信息文档。因此你了解编写文档重要性，要求是不把任何项目内容留在你的脑袋中。在对用户需求进行记录时应注意：
△ 维护一套共享的系统设计和说明书文档。文档应该主要包含：设计会议记录，记录口头更改需求的文档和最终的所有说明书，比如，功能、技术、测试等各方面的内容。
△ 除了规范的文档外，要为所有的信息而开发和维护一个公共资料库。
△ 花一些时间召开会议，在客户讲述时，尽量不要发表你个人的意见。让客户畅所欲言，注意倾听客户的每一个建议、请求或想法。
△ 注意那些你添加的而没有得到用户许可的信息。
△ 应早确立项目使用的范围，并始终牢记在心。这样做可以避免日后开发的项目过大或遗漏了有用的东西。编写项目操作范围的说明书（任务说明或任务对象），用以来描述项目的参数。该说明书应该在项目的设计、实现过程中不断地进行协商、对比、完善，直到最后完成为止。若项目的对象和最终目标在这个阶段不予确认，或者没有记载任何内容，当你和客户的想法出现不一致时，就很可能与用户发生冲突。因此，要确保客户对你将要实现的系统十分清楚，并使用清晰易懂的语言进行描叙，尽可能详细描述项目所有内容。
c、在整个数据库设计期间，客户通常会对字段名、字段定义、业务规则、用户界面和颜色做一些修改，为此，你要做好思想准备。无论客户有什么要求，都应该给予支持，这个项目最终要由用户控制使用，所以你必须要使系统能够灵活地适用各种用途的变化，不管是次要的还是主要的，但对于这些客户的想法都要在客户在设计阶段对你做出的决策确认签字的基础上。
因为在任何时候，客户都有可能对你说，“怎么这里少了一项”、“我根本没这样说”等等。如果你在说话时，手中没有文档为自己撑腰，就会带来很多麻烦。因此，保存文档，如果你做出的决策与客户所说的不同，就应该利用文档来证明自己决策的正确性。
d、数据库原型作为公司与客户签定合约时相互交流信息所使用的画面。每次协商都要借助于开发的原型，它可以很好的反映开发商最终开发的产品。数据库设计者可以利用其为工作模型，设计文档所使用，避免用户所需信息的缺失。
e、与客户商谈时应注意，不要抢先发言；威胁客户；以及在他们向你讲述他们想要做的事情之前大谈你的看法，而不顾用户的期望都有可能造成项目的失败。与客户进行友善地商谈是我们获得设计信息得坚实基础。如果基础不牢靠，最终的产品也不会成功。在向客户提出：
1、谁使用这些数据？
2、如何使用这些数据？
3、客户需要那些报表？
4、以前数据处理办法？
5、由那些规则控制数据的使用？
这几个问题都很有必要了解清楚。
2、逻辑设计阶段
a、我认为在逻辑设计阶段，应禁止谈论性能问题，应该瞄准概念模型。作为一般建议，设计者最好尝试规范化尽量高的级别。如果在系统测试中，发现了性能问题，则可以反向规范化这个系统。但我们永远不要为了调整应用程序的性能而放弃规范化的结构。所以，提倡等到物理模型化阶段或至少迫不得已的理由再反向规范化。
b、在逻辑设计结束，下一步开始时，建议考虑一下以下问题：
1、数据的用法
报表的处理；数据的使用和所有权；与外部系统的接口；数据转换计划
2、容量的测定
表和数据库的增长
3、项目计划
4、最后的文档复审
通读所有文档，并对其修改和校准。使客户在合同上签字。
c、作为设计者，你还应对客户在未来可能产生的需求进行必要预测和文档编写。这样可以在客户未来的业务到来时，可以获得更多的操作时间。
但是，除非你只是为了抓一个现显的小偷，否则需要各种条件，规则，限制，联系都必须考虑到。如同我们在需要统一的考虑数据库解决方案中的分布、冗余、集群、24/7支持、存取过程、触发器、约束和完整性等问题的时候，就需要引入数据库结构的技术。这种技术没有提供物理地实现数据库的方法，但可以通过它来选择一种最佳的方法。
在现代按照不同的设计可以将整个数据库系统按不同服务需求分解成不同的组成部分，而不是使用一种技术完成整个的任务。它们可以分为：
● OLTP（联机事务处理）－－OLTP数据库存储当前业务运作所需要得数据，它的主要目的是使当前的公共数据完整合理，要达到这个目的需要遵循两条原则：1、每一个当前数据块只能存储在一个可供编辑的位置，此处的如何改动都会反映倒所有使用这一数据的地方。2、提供事务支持，以便对数据库进行多项更改一起生效。如果事务中的一个更改失败了，其他的所有更改也都不允许生效，事务中止，所有操作回滚。
● 业务数据存储（Operational Data Store，ODS）――用于日报表的汇总数据。这些数据经常取之几个完全不同的地方，并进行了一定程度的预汇总，以便节省查询的时间。它的目的是向用户提供操作数据并跟踪近期的趋势，以便做出决策。
● 数据仓库（Data Warehouse）――保存整个公司的重要数据和历史数据，它的目的一是利用公司现存历史信息做出决策；二是从数据库系统的角度将活动的事务处理从报告中分力出来，以便更加细致地进行查询，而不会影响用户在OLTP系统中创建和存储的数据的能力。
● 数据集市（Data Mart）――为汇总而优先的专用数据存储，用于特定的场合，其存储的内容作为数据仓库的子集。数据集市通常使用被成为OLAP的技术进行处理。它通常为一个公司的特定需求，或一个机构的特定业务而建立的，一般有两种特殊的数据库结构：星型模式和雪花模式。
对于以上四种类型，最终采用的数据库总体结构完全取决于该数据库将要解决的问题规模。
现在的大部分计算机系统中，数据库是核心。即使不是一个以数据库为核心的系统，也拥有一个数据存储的需要。软件归根结底，也是对数据的处理。
在Internet中，在银行、政府机关、公司、学校、超市、药店等地方，都有许多数据库实例。这类数据库设计的过程一般可以分解成下面几个步骤：
● 定义目标――不要由于觉得显而易见而一笑置之,这个很重要，因为很多项目都是由于开发者不清楚用户实际上要做什么或需要什么，而冒然断定或没有能够很好地听取用户的正确意见或全部意见而带来的麻烦。在这个阶段，我们要为最终创建的系统定义功能、性能、面向客户群，并写需求报告。
● 逻辑设计――为了达到最终的目标而，通过对用户业务的分析，实施的逻辑设计
● 物理设计――利用逻辑设计的成果，并将其转换成一个真正的实现。这个阶段涉及到数据库系统如何物理地实现以及我们需要使用那些硬件和软件。
● 物理实现――项目的实现阶段涉及实际的物理数据、数据库服务器的制定以及编写存取数据的代码。
● 复查――评定是否达到最终目标的过程。大多数的项目都忽视了这个阶段，原因是耗时太长，并且引发不起人们的一点兴趣：测试、编写文档以及完成一些不愿意做，但又必须做的事情。这个阶段，应该有一个利用用户反馈信息的方法和维护更改所有问题的计划。
在用户使用过程中，用户实际只要能够浏览和处理他们所需的数据，就很少对原始数据或者用来存取数据的实际接口感兴趣。项目设计分析人员，可能因为这样那样原因，往往使一些系统使用起来非常笨拙，考虑欠佳的原因。
下面几点是我从学校、从同事、从书籍，从实际设计中得到的一些概念设计经验之谈：
1、定义目标阶段：信息采集，收集数据库项目中的信息。
a、在这里应该尽量避免一开始就设计结构。即使你具有数据库设计的经验，也不要在这里定义表和字段等等，你应该对它们逐步地进行处理。在听取用户讲解其想法和需求，并归纳出该项目应该应该完成的任务之前，不要深入到某一个具体的部分。我们常常在对所完成的任务没有足够了解之前，就对它实施一种结构和一种解决方案，这样即不利于客户也不利于我们。
b、在分析过程中，尽快地将所需的数据编写成文档是一个很好的习惯。例如：在公司，因为一个员工生病或者另谋高就，为了不对开发速度造成很大的影响，接替人员需全力以赴地了解项目的全部内容，能够为其提供帮助的唯一途径就是全部的信息文档。因此你了解编写文档重要性，要求是不把任何项目内容留在你的脑袋中。在对用户需求进行记录时应注意：
△ 维护一套共享的系统设计和说明书文档。文档应该主要包含：设计会议记录，记录口头更改需求的文档和最终的所有说明书，比如，功能、技术、测试等各方面的内容。
△ 除了规范的文档外，要为所有的信息而开发和维护一个公共资料库。
△ 花一些时间召开会议，在客户讲述时，尽量不要发表你个人的意见。让客户畅所欲言，注意倾听客户的每一个建议、请求或想法。
△ 注意那些你添加的而没有得到用户许可的信息。
△ 应早确立项目使用的范围，并始终牢记在心。这样做可以避免日后开发的项目过大或遗漏了有用的东西。编写项目操作范围的说明书（任务说明或任务对象），用以来描述项目的参数。该说明书应该在项目的设计、实现过程中不断地进行协商、对比、完善，直到最后完成为止。若项目的对象和最终目标在这个阶段不予确认，或者没有记载任何内容，当你和客户的想法出现不一致时，就很可能与用户发生冲突。因此，要确保客户对你将要实现的系统十分清楚，并使用清晰易懂的语言进行描叙，尽可能详细描述项目所有内容。
c、在整个数据库设计期间，客户通常会对字段名、字段定义、业务规则、用户界面和颜色做一些修改，为此，你要做好思想准备。无论客户有什么要求，都应该给予支持，这个项目最终要由用户控制使用，所以你必须要使系统能够灵活地适用各种用途的变化，不管是次要的还是主要的，但对于这些客户的想法都要在客户在设计阶段对你做出的决策确认签字的基础上。
因为在任何时候，客户都有可能对你说，“怎么这里少了一项”、“我根本没这样说”等等。如果你在说话时，手中没有文档为自己撑腰，就会带来很多麻烦。因此，保存文档，如果你做出的决策与客户所说的不同，就应该利用文档来证明自己决策的正确性。
d、数据库原型作为公司与客户签定合约时相互交流信息所使用的画面。每次协商都要借助于开发的原型，它可以很好的反映开发商最终开发的产品。数据库设计者可以利用其为工作模型，设计文档所使用，避免用户所需信息的缺失。
e、与客户商谈时应注意，不要抢先发言；威胁客户；以及在他们向你讲述他们想要做的事情之前大谈你的看法，而不顾用户的期望都有可能造成项目的失败。与客户进行友善地商谈是我们获得设计信息得坚实基础。如果基础不牢靠，最终的产品也不会成功。在向客户提出：
1、谁使用这些数据？
2、如何使用这些数据？
3、客户需要那些报表？
4、以前数据处理办法？
5、由那些规则控制数据的使用？
这几个问题都很有必要了解清楚。
2、逻辑设计阶段
a、我认为在逻辑设计阶段，应禁止谈论性能问题，应该瞄准概念模型。作为一般建议，设计者最好尝试规范化尽量高的级别。如果在系统测试中，发现了性能问题，则可以反向规范化这个系统。但我们永远不要为了调整应用程序的性能而放弃规范化的结构。所以，提倡等到物理模型化阶段或至少迫不得已的理由再反向规范化。
b、在逻辑设计结束，下一步开始时，建议考虑一下以下问题：
1、数据的用法
报表的处理；数据的使用和所有权；与外部系统的接口；数据转换计划
2、容量的测定
表和数据库的增长
3、项目计划
4、最后的文档复审
通读所有文档，并对其修改和校准。使客户在合同上签字。
c、作为设计者，你还应对客户在未来可能产生的需求进行必要预测和文档编写。这样可以在客户未来的业务到来时，可以获得更多的操作时间。