逻辑模型设计（什么是数据库的概念设计、逻辑设计、物理设计，以...）

如何实现逻辑数据模型
　　业务和系统开发领域绝对不能容许设计上的重大失误。可是，很多开发人员却因为不了解设计步骤而恰恰轻视乃至完全忽略了整个设计过程。而实际上，我们中的大多数人也确实缺乏必要的有关技能和知识，结果令我们往往“旁路”了项目开发中最重要的阶段。说真的，有本事敢直接绕过设计阶段的人还没诞生呢。　　　　　　　　如果我们不花点时间创建一个逻辑模型，那么要实现一套高效和优秀的设计是完全不可能的。略过设计步骤会产生大量的错误，而这些错误又会令我们耗费大量的时间在发现它们的时候反复调试和纠正。下面我就大致讨论下设计的逻辑和物理模型，然后引领读者经过逻辑模型的创建全过程。本文是有关主题系列的开篇，在后续的第2部分里，我会根据已经发现的缺陷修改我们的原始设计。　　　　　　数据库的设计方法　　在对数据库项目的需求着手评估和分析周，接下来的一步就是设计出一套方案帮助你达到项目的要求和目标。在开发领域这一步骤被称做数据库设计方法。它是一种结构化的措施，支持设计流程同时还包括了诸如公司业务流程、规定和文档等一系列工具。步步进阶的整套流程帮助开发人员计划、管理和控制设计及其实现从而高效地完成任务。　　　　这意味着，你拥有一整套方法，也就是按照特定顺序安排的项目列表，这些方法指引你经过数据模型创建的全过程。请不要错误地把这个过程理解为平常的过程，实际上它是完全必要的阶段。你应该从完全理解数据和用户需求这一目的出发研究该过程。　　　　每一个项目无论其规模大小都能从以下三种模型中获益：　　　　概念：明确和说明创建数据全局视图的主要对象，同时辅以一定的轻微细节。许多企业都局限于特定的数据库管理系统（DBMS），所以这一步可以忽略或者放到逻辑模型一组。　　逻辑：构造采用特定数据的模型，但还不用考虑最终保存数据以及运营应用程序的具体数据库系统。由于SQL Server是一种关系型数据库管理系统（RDBMS），所以我们要依赖于实体关系模型（ER：Entity-Relationship）。在这一阶段你必须明确实体、关系、属性并对你的数据实行规格化。逻辑模型建立在数据集合的基础之上。为了更深入地了解ER模型，不不妨访问下ITS数据库服务网站或者参考　　Mapping an ER Model to the Relational Model Web site（是一个.PDF文件）。　　物理：根据所采用的具体RDBMS设计实现逻辑模型的具体模型。在这一阶段，你需要说明数据表、索引等数据库对象，而物理模型就是根据数据表建立的。　　建立逻辑模型的真实用意无非是为了确认应用程序能满足最终的需求（包括输入和输出两方面）。换句话说，逻辑模型必须能产生所有已知的报告、查询等结果。此外，用户还应该能够以合理的方式输入和操作数据。一旦逻辑模型到位，你就应开始把你所了解的情况应用到项目的物理需求方面——比如说——物理模型。图A就描述了逻辑和物理模型在这一阶段的差别。　　　　图A　　　　　逻辑和物理数据模型　　逻辑模型的实现　　　　目前阶段的所谓“实现”其实就是完成逻辑模型的组件。在明确了实体、关系和属性的情况下，你应该揭示出那些在工作环境下可能会产生问题的缺陷：　　　　缺少的实体　　表示同一概念实体的多个实体　　需要额外实体来解决问题的多对多关系　　Aggregator：一家俱乐部，其成员可以享受打折服务。　　Corporate：代表其职员下定单的公司。它们不能享受的打折优不过需要获得旅行社的全方位服务支持。比如说，旅行社必须帮助它们解决一些诸如取消计划、飞机票订位过多等方面的问题。企业客户总是一样的而旅行者只能是其职员。　　Retail：不能享受任何折扣优惠的单独客户。　　这时，你应该准备定义应用程序的主要对象或者实体。为了针对客户类型应用以上的业务规则，你可能会把每一种客户类型当作单独的实体，如表A所示。数据类型和其他信息都是针对SQL Server考虑的。　　　　表A　　　　　定义应用实体　　　　　　　　看图B，你可以简化当前的模型：　　　　客户订单。　　某种特定类型的客户。　　图B　　　　不同实体之间的关系　　　　正如我们在上面所提到的那样，业务规则要求我们对客户实现区别对待。结果，客户不能总是具有同样的属性。我们的第1个解决方案是创建一个数据表，其中包含了各类客户的特定属性。这一原始设计带来了下列问题：　　　　所有的客户数据表都采用系统生成的主键，大致以种子值1开始递增。那就是说，你完全会遭遇重复的ClientID值。结果我们就无法恰当地把每一定单关联到特定的客户，因为每一客户表都包含了重复的值。　　因为每一客户表重复公共字段（如ClientID、ClientName、Address和Telephone）而产生了一些冗余的属性。　　客户会有更多的地址吗？也许他们会具有一个当地地址和一个付费的单位地址。　　客户只有一个电话号码？也许你应该列出多个电话号码乃至传真号码。　　有必要根据客户的类型来标识定单吗？显然你不能。　　找出和解决设计问题　　　　你首先采取的行动可能和我们用的不同，但那还不是关键的问题。最重要的是你可能没有认识的到设计中隐藏的问题。在后续的文章里我会采用已知的、业已得到证明的方法来寻找和解决设计问题，免得它们在今后的工作中引出不少漏子。
数据库的逻辑模型一般由谁设计完成
数据库逻辑设计决定了数据库及其应用的整体性能，调优位置。如果数据库逻辑设计不好，则所有调优方法对于提高数据库性能的效果都是有限的。为了使数据库设计的方法走向完备，数据库的规范化理论必须遵守。规范化理论为数据库逻辑设计提供了理论指导和工具，在减少了数据冗余的同时节约了存储空间，同时加快了增、删、改的速度。
另外，在规范的数据库逻辑设计时，还应考虑适当地破坏规范规则，即反规范化设计，来降低索引、表的数目，降低连接操作的数目，从而加快查询速度。常用的反规范技术有增加冗余列、增加派生列、重新组表等。
增加冗余列：有时要进行查询的列分布在不同的表中，如果这个连接查询的频率比较高，那就可以根据需要，把其它表中的这一列加进来，从而使得多个表中具有相同的列，它常用来在查询时避免连接操作。但它的坏处就是需要更多的磁盘空间，同时因为完整性问题需要增加维护表的工作量。
总之，在进行数据库逻辑设计时，一定要结合应用环境和现实世界的具体情况合理地选择数据库模式。

一般由设计师完成
什么是数据库的概念设计、逻辑设计、物理设计，以...
1.概念设计；对用户要求描述的现实世界(可能是一个工厂、一个商场或者一个学校等)，通过对其中住处的分类、聚集和概括，建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。所建立的模型应避开数据库在计算机上的具体实现细节，用一种抽象的形式表示出来。以扩充的实体—（E-R模型）联系模型方法为例，第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等，从而给出各部门内所用信息的局部描述(在数据库中称为用户的局部视图)。第二步再将前面得到的多个用户的局部视图集成为一个全局视图，即用户要描述的现实世界的概念数据模型。

2.逻辑设计；主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。

3.物理设计；根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。

4.三者关系：由上到下，先要概念设计，接着逻辑设计，再是物理设计，一级一级设计。