有效数据库设计的目标Word下载.docx

有效数据库设计的目标Word下载.docx

《有效数据库设计的目标Word下载.docx》由会员分享，可在线阅读，更多相关《有效数据库设计的目标Word下载.docx（19页珍藏版）》请在冰豆网上搜索。

设计中错误的假定会渗入应用程序最低级的代码，导致子系统出现问题。

构建在这些子系统上的高级系统将沿袭设计缺陷并且它们的代码很快也会受损坏。

有时，代码受到一点损坏便会弥散到整个系统并且直到项目进入到相对较晚的阶段才会被注意到。

项目持续的时间越长，不正确的假设越难更改，开发人员越不愿意舍弃整个设计并重新开始。

问题在系统中存在的时间越长，越难消除它们。

某些情况下抛弃所有事物并从头开始可能更为容易，但这是一个大多数人都不愿意向更高的管理层呈交的决定。

项目管理

我的一个朋友是工程师，参与了一个非常庞大的卫星项目。

过了一段时间后，工程师们都意识到在当前的技术条件和设计状况下，该项目是不可行的。

最终项目经理被迫向高层主管汇报此情况，他本人因此被解雇了。

新的项目经理坚持了一段时间后也被迫向高层主管承认此项目不可行，当然他也被解雇了。

此项目在新的项目经理接手后又继续进行了一段时间，但是他后来也认识到该项目是无希望的，并且直到最后上层主管也不得不承认项目是没有结果时他也被解聘，最终整个项目彻底失败。

如果他们前期在项目设计上花费更多的时间并即时修正问题或立刻认识到项目不可能完成并在一开始就废弃项目，那么便可以节省大量时间、金钱和人力。

构建一个项目往往与建造一座房屋或摩天大楼相似。

在没有经过基于完善的建筑原则而深思熟虑的设计之前，完全不可能建造一个造价高达几十亿美元的摩天大楼。

但是，软件开发人员往往在还末确定肯定能完成软件开发时就匆忙开始编写代码。

编码比设计更有意思、更令人感兴趣。

编写代码还允许开发人员告知管理层和客户他们已经写了多少行代码，这样看似开发人员正在实施软件开发，即使这些代码由于错误的假设而毫无用处。

只有到了后期，他们才认识到基础设计有缺陷，编写的代码没有意义，而项目此时已经陷入了巨大的麻烦之中。

现在回到项目设计。

应用程序设计中数据库设计是最为关键的一项任务。

数据库是信息的存储库，供应用程序的其他部分进行管理并显示给用户。

如果数据库没有存储正确的数据，没有安全地保存数据，或者应用程序无法找到所需的数据，那么应用程序很少有成功的机会。

在这里，无用输入无用输出（GIGO）原则完全适用。

如果底层的数据不可靠，那么无论使用这些数据的应用程序完成什么任务，结果充其量也将是不可信的。

例如，假想构建了一个订单跟踪系统用以快速获取客户以往订单的信息。

遗憾的是，每次要求程序提取某个客户的记录，但它返回的结果却略有出入。

尽管程序能够快速找到数据，但是结果并不足够可信赖而被使用。

设想已经构建了一个令人吃惊的程序，该程序能够跟踪完成一个复杂任务的数千道工序，如建造一艘游轮或载客喷气式飞机。

该程序能够跟踪每道工序的完成状况，确定何时需要订购新的零件以便为后续建造阶段做好准备，甚至还能确定今后采购的现行价格从而决定是现在购买还是等到需要时再购买零件。

但是，程序将花费数个小时重新计算复杂的任务进度安排和价格详情。

尽管计算结果是正确的，但是计算过程太慢使得用户无法有效地做出任何更改。

更改飞机座椅织布的颜色或游轮走廊上使用的瓷砖都会延误整个项目。

假设构建了一个有效的订阅应用程序，该程序允许客户订阅公司每季的资讯和数据服务。

该程序能够快速查找并更新客户的订阅并且总能一致地为特定的客户显示同样的订价。

但是，当更改了某个发行刊物的价格时会发现并非所有客户的记录都显示更新的价格。

一些客户是按照新价格订阅的，另一些客户是按照旧价格订阅的，还有一些客户看似是按照从没见过的价格订阅的（本示例并不像看起来的那样牵强。

一些系统允许向客户群提供廉价订阅或特殊的奖励或者允许销售代表向特殊用户提供特价。

如果希望能够完成诸如更改标准价格而不干扰定制价格这样的操作，那么这种系统便要求特殊的设计）。

拙劣的数据库设计会导致上述这些问题和其他令人烦恼的问题以及付出潜在的昂贵代价。

良好的设计则可为完成应用程序其余部分打下坚实的基础。

有经验的开发人员知道错误在系统中停留的时间越长，则越难以查找和修正。

基于此逻辑，在开始构建应用程序之间实施正确的设计是非常重要的一环。

数据库设计也不例外。

在开始确定软件体系结构构思拙劣、实现拙劣或程序不合格之前，有缺陷的数据库设计注定项目会失败。

1.2信息容器

数据库是什么？

这个问题看似很简单，但是如果认真对待它，结果可能很有启发作用。

通过调研满足数据库定义的一些物理对象的优点和缺点，可以了解理想计算机化数据库具有的特性。

数据库是一种存储数据的工具，允许以某种方式创建、阅读、更新和删除数据。

这是一个非常宽泛的定义并且涵盖许多不为大多数人看做是现代数据库的物理对象。

例如，装满名片的信封、笔记本、装满客户档案的档案柜和人的大脑都符合此定义。

这些数据库都有各自的优缺点，从中可以洞察计算机数据库具有的理想特性。

只要不装过多的名片，名片盒就是有用的。

通过浏览所有名片可以查找一条特定的数据（例如一个人的电话号码）。

通过将更多的名片装进名片盒至少在一定程度上可以方便地扩展数据库。

如果名片的数量超过一打，找到特定的名片将是耗时的。

甚至还可以略微重新安排一下名片来方便查找经常使用的名片。

每次使用一张名片，就将其放在名片堆的前面，这样一段时间以后使用最多的名片会放在最前面。

笔记本是一种小型、便于使用和携带的数据库，不需要供电，也不要求在使用之前引导它。

另外，笔记本数据库也非常容易扩展，因为当第一本笔记本写满时可以买另一本笔记本加入到收集物中。

但是，笔记本的内容是按顺序安排的。

如果希望查找有关特定主题的信息，必须一次浏览一个页面直到找到想要的内容。

拥有的数据越多，这种搜索就会变得越困难。

档案柜存储的信息要比笔记本多很多，可以通过添加更多的文件或柜子来扩展这种数据库。

只要是根据用于安排档案的数据类型进行搜索的，在档案柜中查找某条特定的信息要比在笔记本中查找更为容易。

如果档案柜装满按照客户名整理排列的客户信息，并且希望找到某个特定的客户数据，那么这样是幸运的。

如果希望找到住在某个城市中的所有客户，则必须逐个遍历所有文件。

人的大脑是迄今创建的最为复杂的数据库。

它可以存储难以置信的数据量并允许采用多种不同的方式检索特定的数据块。

例如，现在您很可能可以轻易地回答如下有关您经常光顾的饭店的问题：

●哪家饭店距离您当前的位置最近？

●哪家饭店的甜点最好？

●哪家饭店的服务最好？

●哪家饭店的价格最便宜？

●哪家饭店最适合用商务午餐？

●总体来说您最喜欢哪家饭店？

人的大脑提供了多种不同的方式来获取相同的有关饭店的信息。

可以基于多种关键词（位置、甜点质量、费用等）来搜索相同的信息库。

若要使用名片盒（或饭店宣传册）、笔记本或档案柜来回答上述这些问题，则需要较长的时间和费力的搜索。

然而大脑也有缺点，至少作为数据库是这样的。

最明显的缺点是它会遗忘信息。

尽管可以记忆的信息量难以置信，但是随着时间的推移，其中一些信息将变得不可靠甚至会完全消失。

您还能记起小学老师的所有名字吗？

我就不能（我连自己老师的名字都记不得，更不用说您的老师）。

此外，大脑还会出现疲倦，此时它的准确性会降低。

尽管人的大脑擅长完成某些任务，如识别人脸或挑选饭店，它并不擅长其他任务，如提供去年某个特定的顾客购买的所有项目的准确清单。

相比于配偶的姓名，这些项目缺少情感意义，因此它们更难记忆。

所有这些信息容器（名片、笔记本、档案柜和大脑）都会因为令人误解的、不正确的和矛盾的信息而受到损坏。

如果在笔记本中写下不同形式的相同信息，那么数据将会不一致。

随后当您设法查找数据时，可能会先找到任一种形式的信息，而没有认识到还有其他形式的信息（存储不一致和自相矛盾的信息会使大脑变得非常混乱，特别是在大选年中收听政客们的演说时更是如此）。

下面各节总结了这些信息容器的优点和缺点。

1.3信息容器的优缺点

通过了解上一节描述的这些信息容器的优点和缺点，可以了解对于计算机化数据库有用的特性。

那么这些优点和缺点到底有哪些呢？

下面的列表汇总了一些信息容器的优点：

●上述这些数据库都不要求供电并且它们不会受到电源故障的影响。

●这些数据库能够相当安全和持久地保存数据（但要防火），数据基本不会消失。

●这些数据库（除了大脑）价格便宜且容易购买。

●这些数据库具有简单的用户界面，因此几乎任何人都会使用它们。

●使用这些数据库可以非常方便地添加、编辑和删除数据。

●若按照与整理档案柜相同的方式搜索数据，那么使用档案柜可方便地找到数据。

●大脑允许通过使用不同的关键字来查找数据（例如按照位置、价钱或服务质量）。

●所有这些数据库都允许查找它们包含的每条信息，尽管可能花费一段时间遍历所有信息。

●只要存储的实际数据是一致的，那么所有这些数据库（除了大脑）都提供一致的结果。

例如，使用相同笔记本的两个人会查找到相同的数据。

类似地，如果随后查看同一个笔记本，它将显示与以前看到的数据相同的数据（前提是没有修改它）。

●所有这些数据库（除了档案柜）都是便携的。

●大脑可以执行复杂的计算，至少对于有限的类型和数字是这样的。

●所有这些数据库都提供原子事务处理（或交易）。

最后一个优点比其他优点更为抽象一些，因此需要进行更多的说明。

原子事务处理可能是一系列较为复杂的行动，那些不直接参与执行事务的人将它们看做是单一操作。

最典型的示例是从一个银行账户向另一个账户转账。

假定Alice向Bob开了一张价值100美元的支票，并且需要在他们的账户之间转移这笔钱。

您拿起记账本从Alice的记录上扣除100美元并将100美元添加到Bob的记录上，然后放下笔记本。

其他使用笔记本的人可能在事务处理之前（此时Alice有100美元）或事务处理之后（此时Bob有100美元）查看它，但是不能在从Alice账户上扣除100美元但还没有转给Bob的事务处理过程中查看它。

当处理进行到一半时绝不允许办公室里粗鲁的同事从您的手中抢走笔记本，它是一种要么全做要么不做的事务处理。

除了上述优点以外，诸如笔记本和档案柜这样的信息容器有一些缺点。

研究这些缺点很有价值，这样一来便可以在构建计算机数据库时设法避免它们。

下面的列表汇总了这些信息容器具有的一些缺点。

●所有这些数据库都可能保存不完整的、不正确的或自相矛盾的数据。

●一些数据库容易丢失或被盗。

一些人可能会趁您吃午饭的时候窃取您的笔记本或者在公共汽车上从您的肩膀上偷看笔记本内容。

另外，当匆忙赶航班时甚至可能把笔记本遗忘在安检柜台上。

●在所有这些数据库中，纠正数据中较大的差错可能较为困难。

例如，可以在地址备忘录上使用钢笔更改某个人的地址。

如果在您所在区域建造了一个新城市，则更新数百个地址要困难得多（这种情况最近发生在我的居住地附近）。

这种情况需要对一摞名片、一本笔记本或档案柜进行冗长的搜索。

而您的大脑彻底更新这种变化可能需要几年的时间。

●根据不可控的因素，如情绪、疲劳程度甚至是否饥饿，大脑会在不同的时间给出不同的结果。

●所有这些数据库都位于一个单独的地方，因此不能方便地共享它们。

此外，每种数据库也不能方便地备份，如果原始的数据库丢失或破坏则会丢失数据。

下一节考虑将上述优点和缺点转换成在计算机数据库中希望获得或避免的特性。

1.4理想的数据库特性

通过了解物理数据库的优点和缺点，可以创建一个计算机数据库应该具有的特性列表。

其中一些是所有数据库都必须具有的基本特性（应该能够从数据库中获取数据。

这是很明显的特性）。

但是大多数特性至少部分依赖于良好的数据库特性。

如果没有构建良好的设计，则会丧失这些特性的部分或全部。

例如，任何恰当的数据库均提供备份特性，但是良好的设计可以使备份和恢复快速和方便得多。

下一节介绍优良的数据库系统应该提供的一些特性并解释了它们依赖良好数据库设计的具体程度。

1.4.1CRUD

CRUD代表任何数据库都应该提供的4种基本的数据库操作：

创建（Create）、读取（Read）、更新（Update）和删除（Delete）。

如果阅读万维网上的数据库文章和讨论，经常会看到人们提及术语CRUD（他们使用此术语或许仅是为了听起来专业和内行。

可以设想一些不支持所有这些方法的特殊的数据采集设备。

例如，飞机上的黑匣飞行数据记录器记录航班信息并随后播放，但不允许修改数据。

但是通常而言，如果不具备CRUD特性则不能称其为数据库。

CRUD通常是数据库必备的一个特性而并非良好的数据库设计要求的特性，但是良好的数据库设计可以有效地提供CRUD。

例如，假定设计一个数据库来跟踪canuggling联盟（可在网上查找它）的时间并且要求参与方的地址包括一个出现在States表中的State（状态）值。

当创建一个新的记录时（CRUD中的C），数据库必须验证新的State记录项。

与此类似，当更新一个记录时（CRUD中的U），数据库必须验证修改的State记录项。

当删除States表中的记录项时（CRUD中的D），数据库必须验证没有Participant（参与方）记录使用该状态。

最后，当读取数据时（CRUD中的R），数据库设计决定能否在几秒钟或几小时内找到想要的数据，或者根本就找不到想要的数据。

下一节描述的许多概念与CRDU操作相关。

1.4.2检索

检索（Retrieval）是读取的另一个名词，即CRUD中的R。

数据库应该允许查找每条信息。

如果没有办法随后取回数据而将这些数据置于数据库中是没有意义的（这将成为“数据黑洞”而不是数据库）。

数据库应该允许组织数据以便可以采用一种或多种特殊的方法找到特定的数据段。

举例而言，应该能够通过搜索客户名称或客户ID来查找客户的账单记录。

理想情况下，数据库还将合理组织数据以便以某种特定的方式相对快速和方便地取出数据。

例如，假定希望查看客户的居住地以便决定是否应该在一个新的程序开始递送服务。

为了获取此信息，能够基于他们的地址找到客户是有帮助的。

理想情况下，可以优化数据库从而通过地址快速搜索客户。

与此相反，很可能不需要很频繁地按照中间名来搜索客户（假设一个客户给您打电话问及“能否查找我的记录？

我不记得上个月是否支付了账单，而且我也不记得我的账户名或姓但却记得我的中间名是‘Konfused’”）。

如果常规的按地址搜索快于少见的按中间名的搜索则更好。

能够快速且可靠地查找到数据库中的所有数据是数据库设计的一个重要方面。

在一个设计拙劣的数据库中查找需要的数据可能会花费数个小时或数天而不是仅仅数秒的时间。

1.4.3一致性

CRUD中的R的另一个方面是一致性。

数据库应该提供一致的结果。

如果在一行中执行相同的两次搜索，应该得到相同的结果。

执行相同搜索的另一个用户也应该得到相同的结果（当然，假定其间底层的数据没有变化。

当股票价格剧烈波动时不能企望您的净值查询返回相同的结果）。

良好构造的数据库产品能够确保完全相同的查询返回相同的结果，但是设计还扮演着重要的角色。

如果数据库设计拙劣，则可能会在数据库的不同部分中存储相冲突的数据。

例如，您可能将一组联系信息存储在客户的订单中并将一组不同的信息存储在主客户记录中。

随后如果需要联系客户了解有关订单的问题，那么应该使用哪条联系信息呢？

1.4.4有效性（验证）

有效性与一致性的思想紧密相关。

一致性是指数据库的不同部分不能保存相同信息的相互矛盾的视图。

有效性是指在可能需要的地方相对数据库中的其他数据段对数据进行验证。

在CRUD术语中，当创建、更新或删除记录时可以对数据进行验证。

正如物理数据容器一样，计算机数据库可能保存不完整、不正确或相矛盾的数据。

我们无法防止不会拼写或只是简单录入错误信息的人破坏数据库，但是好的数据库设计有助于防范物理数据库无法阻止的一些错误类型。

例如，数据库可以方便地检验数据具有正确的类型。

如果用户看到一个Date（日期）字段并录入“Nothanks,I’mmarried”，那么数据库会指出这是无效的日期格式并拒绝接受此值。

类似地，数据库可以提示“Old”不是有效的年龄（Age），“Lots”不是有效的数量（Quantity），并且“Confusion”过长而不是一个两字母的状态缩写（尽管该值可以正确反映用户的思维状态）。

数据库还可以检验用户输入的值是否出现在数据库的其他部分中。

例如，一个粗心的打字员试图在State字段中输入CO却输入了CP。

数据库会检查有效状态列表并且会在列表中没有找到CP时拒绝接受该数据（如果数据库需要仅使用某些状态，那么可以限制列表只包含那些状态并使测试更加严格）。

数据库还可以检查数据的某些类型的条件。

假设数据库包含一个图书订购系统。

当顾客订购某种图书500册时（他并不想要那么多册），数据库可以检查其他部分来查看是否存在这么多册图书（对任意给定的图书大多数书店仅存有几册），如果没有足够的数量则会拒绝此订购。

此外，良好的数据库设计还有助于防止对数据库进行不正确的更改。

假定热牛奶咖啡及修理服务不再覆盖一座邻近的城市。

当设法从有效位置列表中删除该城市时，数据库可以指出在此城市中是否还存在客户。

根据数据库的设计，它能够拒绝删除该城市，除非已向那些客户表示歉意并从数据库中删除他们。

所有这些技术均依赖于良好、可靠的数据库设计。

但是它们仍然不能防范用户在姓字段中输入名字或者用户意外敲击CAPSLOCK键，但是它能够防止笔记本这样的数据库所不能防范的许多类型的错误。

1.4.5轻松的纠错

即使完美设计的数据库也无法确保绝对的有效性。

数据库如何知道一个客户的名字应该被拼写成Pheidaux而不是用户键入的Fido呢？

在笔记本上纠正单个错误非常容易。

只需划掉错误的值并写入新的值即可。

在笔记本中纠正系统的错误要困难得多。

假定雇佣了一个暑期实习生逐户上门推销家用产品，他详细记录了很多“DuckTape”订单，但是没有意识到实际的产品是“DuctTape”。

修正所有错误可能会很乏味和耗时（当然，乏味和耗时的工作正是暑期实习生从事的工作，因此可以让他们自己修正所犯的错误）。

此外，还可以忽视此问题并保留拼错的订单，但是随后如何知道某个客户何时真正想要为鸭子录音？

在计算机数据库中，这种纠错很简单。

一条简单的数据库命令即可更新整个系统中出现的所有产品名称“DuckTape”（实际上，这种纠错有时做起来过于简单。

如果不够小心，可能会意外将所有产品的名称更改为DuctTape，设置包括那些没有错误拼写为DuckTape的产品。

通过为数据库构建可靠的用户界面来避免这种情况）。

方便的纠正错误是计算机数据库内在的一种特性，但是为了从此特性中获得最大的收益，则需要良好的设计。

如果在自由编排格式的文本部分中包含订单信息，则数据库修订排印错误将会遇到麻烦。

如果将产品名称放在分离的字段中，则数据库能够轻易做出这种更改。

尽管轻松纠错基本上不受约束，但是需要作少许设计以便使它们尽可能有效和高效。

1.4.6速度

所有CRUD特性的一个重要方面是速度。

良好设计的数据库能够快速创建、读取、更新和删除记录。

不可否认的是，计算机数据库比笔记本或档案柜快速得多。

计算机数据库远不止每小时处理几十条记录，而能每秒处理几十条或上百条记录（我曾参与开发一个记账中心，它每3天可以处理大约300万个账户）。

良好的数据库设计在提高数据库效率上起着重要作用。

拙劣构造的数据库尽管仍然比等效的纸制数据库快速，但是要比良好设计的数据库慢得多。

数据库设计

上一段提到的记账中心有一个小问题：

它无法找到拖欠记账中心钱财最多的客户。

数据库每隔3天会列出一份欠钱的客户列表。

这份客户列表打印出来的一堆纸几乎高3英尺。

但是这份列表是随机排序的（很可能按照客户ID或鞋子尺码或其他同样无用的标准进行排序），因此不能推算出欠钱最多的客户。

大部分客户仅欠几元钱——太少而不必纠缠——但是少数客户却欠下上万元钱。

我们将此打印输出结果电子化处理后并按照余额来排列账户。

结果表明真正有问题的客户仅占据几页并且前5个账户的欠款超过了其他所有账户欠款的总和。

我引入这个故事的目的不是炫耀我的编程能力（老实说，这是一个非常容易的项目），而是为了说明数据库设计如何大幅改善系统性能。

在此通过很简单的改动（任何数据库都应该予以支持）可以在几秒钟内找出最令人忧虑（欠款最多）的客户，否则难以找到此客户。

并不是所有对数据库设计的更改都可以得到激动人心的结果，但是良好的设计的确在改善性能方面发挥着重要作用。

1.4.7原子事务处理

如果从Alice的账户向Bob的账户转账100美元，当数据库处于中间状态时其他人不能查看数据库，这种状态是已从Alice的账户扣除100美元但还没有添加到Bob的账户上。

事务处理要么其所属操作全部完成要么什么都不发生——而不能只进行一部分操作。

原子事务处理对于维护一致性和有效性很重要，因此对于CRUD中的R和U非常重要。

物理数据容器（如笔记本）支持原子事务处理，因为通常一次只有一个人能够使用它。

除非当您在笔记本中写入记录时办公室粗鲁的同事Derek从您的手中抢去笔记本，在允许其他人有机会使用笔记本之前只能完成一系列操作。

一些最简单的数据库类型，如平面文件和XML文件（本书后面将介绍它们）并不是本身就支持原子事务处理，但是更高级的关系数据库产品能够对此予以支持。

这些数据库允许开始事务处理并执行一系列操作。

然后可以提交事务处理以便使更改成为永久性的，或者回滚事务处理以便全部取消这些操作并将数据库恢复到开始事务处理之前的状态。

此外，如果数据库意外停止，这些数据库还将自动回滚打开的任何事务处理。

例如，假设开始一个事务处理，从Alice的账户中取出100美元，随后您公司的吉祥物（一匹小马）走进微机房，踩上电源板并切断了主机的电源。

当重新启动数据库（在将小马送至人力资源部后）时，它自动回滚事务处理以便使Alice找回她的钱。

然后需要再次尝试事务处理，但是至少要求系统没有丢失任何钱财。

原子事务处理与其说是数据库设计问题，还不如说是一种正确使用数据库特性的问题。

如果挑选了适当高级的数据库产品并正确使用事务处理，将会获得其好处。

如果决定使用平面文件来存储数据，则将需要亲自实现事务处理。

1.4.8ACID

本节对上一节描述的事务处理进行了更加详细的介绍，而不是讨论