有效数据库设计的目标
有效数据库设计的目标
借助现代数据库工具，几乎所有人都能够创建数据库。但是问题是，得到的数据是否有用？
如果不能从其中快速、可靠且一致地取出数据，那么数据库不会有多少用处。如果数据库里都是不正确的或自相矛盾的数据，那么将毫无用处。此外，如果数据库被窃取、丢失或者当系统崩溃时遭受到仅半写入的数据的破坏，那么它也是无用的。
现代数据库工具、好的数据库设计和一些常识可以解决所有这些潜在的问题。只要能够了解这些问题的实质，则可以避免它们。
获得有用数据库的第一步是了解数据库的目标。数据库应该完成哪些任务？怎么样能使数据库变得有用以及它能解决什么样的问题？使用一个强大的数据库工具但却没有制定目标就像驾驶飞机在云中飞行而没有罗盘：您拥有自己需要的工具但是却不知道方向。 本章将描述数据库设计的目标。通过研究诸如文件这样能够充当数据库的信息容器，则可以定义数据库应该具有的特性和它们应该避免的问题。
在本章将会学到如下内容：
● 好的数据库设计之所以重要的原因。
● 可以充当数据库的各种不同的信息容器的优点和缺点。
● 如何使计算机化的数据库受益于这些优点并避免那些缺点。
● 好的数据库设计有助于达成数据库目标的方法。
● CRUD 和ACID 的概念以及它们和数据库设计相关的原因。
1.1 理解数据库设计的重要性
请暂时忘记本书是有关数据库设计的，并考虑常规的软件设计。软件设计在软件开发中起着重要的作用。设计规划了今后开发将会采用的大体结构和方向，决定系统各部分之间的交互关系以及哪些子系统对应用程序的其他部分提供支持。
如果应用程序的基础设计是有缺陷的，那么系统整体上将存在危险。设计中错误的假定会渗入应用程序最低级的代码，导致子系统出现问题。构建在这些子系统上的高级系统将沿袭设计缺陷并且它们的代码很快也会受损坏。
有时，代码受到一点损坏便会弥散到整个系统并且直到项目进入到相对较晚的阶段才第 章
第 章 1
第I部分数据库和数据库设计介绍
会被注意到。项目持续的时间越长，不正确的假设越难更改，开发人员越不愿意舍弃整个设计并重新开始。问题在系统中存在的时间越长，越难消除它们。某些情况下抛弃所有事物并从头开始可能更为容易，但这是一个大多数人都不愿意向更高的管理层呈交的决定。
项目管理
我的一个朋友是工程师，参与了一个非常庞大的卫星项目。过了一段时间后，工程师们都意识到在当前的技术条件和设计状况下，该项目是不可行的。最终项目经理被迫向高层主管汇报此情况，他本人因此被解雇了。新的项目经理坚持了一段时间后也被迫向高层主管承认此项目不可行，当然他也被解雇了。
此项目在新的项目经理接手后又继续进行了一段时间，但是他后来也认识到该项目是无希望的，并且直到最后上层主管也不得不承认项目是没有结果时他也被解聘，最终整个项目彻底失败。
如果他们前期在项目设计上花费更多的时间并即时修正问题或立刻认识到项目不可能完成并在一开始就废弃项目，那么便可以节省大量时间、金钱和人力。
构建一个项目往往与建造一座房屋或摩天大楼相似。在没有经过基于完善的建筑原则而深思熟虑的设计之前，完全不可能建造一个造价高达几十亿美元的摩天大楼。但是，软件开发人员往往在还末确定肯定能完成软件开发时就匆忙开始编写代码。编码比设计更有意思、更令人感兴趣。编写代码还允许开发人员告知管理层和客户他们已经写了多少行代码，这样看似开发人员正在实施软件开发，即使这些代码由于错误的假设而毫无用处。只有到了后期，他们才认识到基础设计有缺陷，编写的代码没有意义，而项目此时已经陷入了巨大的麻烦之中。
现在回到项目设计。应用程序设计中数据库设计是最为关键的一项任务。数据库是信息的存储库，供应用程序的其他部分进行管理并显示给用户。如果数据库没有存储正确的数据，没有安全地保存数据，或者应用程序无法找到所需的数据，那么应用程序很少有成功的机会。在这里，无用输入无用输出(GIGO)原则完全适用。如果底层的数据不可靠，那么无论使用这些数据的应用程序完成什么任务，结果充其量也将是不可信的。
例如，假想构建了一个订单跟踪系统用以快速获取客户以往订单的信息。遗憾的是，每次要求程序提取某个客户的记录，但它返回的结果却略有出入。尽管程序能够快速找到数据，但是结果并不足够可信赖而被使用。
设想已经构建了一个令人吃惊的程序，该程序能够跟踪完成一个复杂任务的数千道工序，如建造一艘游轮或载客喷气式飞机。该程序能够跟踪每道工序的完成状况，确定何时需要订购新的零件以便为后续建造阶段做好准备，甚至还能确定今后采购的现行价格从而决定是现在购买还是等到需要时再购买零件。但是，程序将花费数个小时重新计算复杂的任务进度安排和价格详情。尽管计算结果是正确的，但是计算过程太慢使得用户无法有效地做出任何更改。更改飞机座椅织布的颜色或游轮走廊上使用的瓷砖都会延误整个项目。
假设构建了一个有效的订阅应用程序，该程序允许客户订阅公司每季的资讯和数据服务。该程序能够快速查找并更新客户的订阅并且总能一致地为特定的客户显示同样的订价。但是，当更改了某个发行刊物的价格时会发现并非所有客户的记录都显示更新的价格。一
4
第1章有效数据库设计的目标
些客户是按照新价格订阅的，另一些客户是按照旧价格订阅的，还有一些客户看似是按照从没见过的价格订阅的(本示例并不像看起来的那样牵强。一些系统允许向客户群提供廉价订阅或特殊的奖励或者允许销售代表向特殊用户提供特价。如果希望能够完成诸如更改标准价格而不干扰定制价格这样的操作，那么这种系统便要求特殊的设计)。
拙劣的数据库设计会导致上述这些问题和其他令人烦恼的问题以及付出潜在的昂贵代价。良好的设计则可为完成应用程序其余部分打下坚实的基础。
有经验的开发人员知道错误在系统中停留的时间越长，则越难以查找和修正。基于此逻辑，在开始构建应用程序之间实施正确的设计是非常重要的一环。
数据库设计也不例外。在开始确定软件体系结构构思拙劣、实现拙劣或程序不合格之前，有缺陷的数据库设计注定项目会失败。
1.2 信息容器
数据库是什么？这个问题看似很简单，但是如果认真对待它，结果可能很有启发作用。通过调研满足数据库定义的一些物理对象的优点和缺点，可以了解理想计算机化数据库具有的特性。
数据库是一种存储数据的工具，允许以某种方式创建、阅读、更新和删除数据。
这是一个非常宽泛的定义并且涵盖许多不为大多数人看做是现代数据库的物理对象。例如，装满名片的信封、笔记本、装满客户档案的档案柜和人的大脑都符合此定义。这些数据库都有各自的优缺点，从中可以洞察计算机数据库具有的理想特性。
只要不装过多的名片，名片盒就是有用的。通过浏览所有名片可以查找一条特定的数据(例如一个人的电话号码)。通过将更多的名片装进名片盒至少在一定程度上可以方便地扩展数据库。如果名片的数量超过一打，找到特定的名片将是耗时的。甚至还可以略微重新安排一下名片来方便查找经常使用的名片。每次使用一张名片，就将其放在名片堆的前面，这样一段时间以后使用最多的名片会放在最前面。
笔记本是一种小型、便于使用和携带的数据库，不需要供电，也不要求在使用之前引导它。另外，笔记本数据库也非常容易扩展，因为当第一本笔记本写满时可以买另一本笔记本加入到收集物中。但是，笔记本的内容是按顺序安排的。如果希望查找有关特定主题的信息，必须一次浏览一个页面直到找到想要的内容。拥有的数据越多，这种搜索就会变得越困难。
档案柜存储的信息要比笔记本多很多，可以通过添加更多的文件或柜子来扩展这种数据库。只要是根据用于安排档案的数据类型进行搜索的，在档案柜中查找某条特定的信息要比在笔记本中查找更为容易。如果档案柜装满按照客户名整理排列的客户信息，并且希望找到某个特定的客户数据，那么这样是幸运的。如果希望找到住在某个城市中的所有客户，则必须逐个遍历所有文件。
人的大脑是迄今创建的最为复杂的数据库。它可以存储难以置信的数据量并允许采用多种不同的方式检索特定的数据块。例如，现在您很可能可以轻易地回答如下有关您经常光顾的饭店的问题：
5
第I部分数据库和数据库设计介绍
6 ●哪家饭店距离您当前的位置最近？
●哪家饭店的甜点最好？
●哪家饭店的服务最好？
●哪家饭店的价格最便宜？
●哪家饭店最适合用商务午餐？
●总体来说您最喜欢哪家饭店？
人的大脑提供了多种不同的方式来获取相同的有关饭店的信息。可以基于多种关键词
(位置、甜点质量、费用等)来搜索相同的信息库。若要使用名片盒(或饭店宣传册)、笔记本或档案柜来回答上述这些问题，则需要较长的时间和费力的搜索。
然而大脑也有缺点，至少作为数据库是这样的。最明显的缺点是它会遗忘信息。尽管可以记忆的信息量难以置信，但是随着时间的推移，其中一些信息将变得不可靠甚至会完全消失。您还能记起小学老师的所有名字吗？我就不能(我连自己老师的名字都记不得，更不用说您的老师)。
此外，大脑还会出现疲倦，此时它的准确性会降低。
尽管人的大脑擅长完成某些任务，如识别人脸或挑选饭店，它并不擅长其他任务，如提供去年某个特定的顾客购买的所有项目的准确清单。相比于配偶的姓名，这些项目缺少情感意义，因此它们更难记忆。
所有这些信息容器(名片、笔记本、档案柜和大脑)都会因为令人误解的、不正确的和矛盾的信息而受到损坏。如果在笔记本中写下不同形式的相同信息，那么数据将会不一致。随后当您设法查找数据时，可能会先找到任一种形式的信息，而没有认识到还有其他形式的信息(存储不一致和自相矛盾的信息会使大脑变得非常混乱，特别是在大选年中收听政客们的演说时更是如此)。
下面各节总结了这些信息容器的优点和缺点。
1.3 信息容器的优缺点
通过了解上一节描述的这些信息容器的优点和缺点，可以了解对于计算机化数据库有用的特性。那么这些优点和缺点到底有哪些呢？
下面的列表汇总了一些信息容器的优点：
●上述这些数据库都不要求供电并且它们不会受到电源故障的影响。
●这些数据库能够相当安全和持久地保存数据(但要防火)，数据基本不会消失。
●这些数据库(除了大脑)价格便宜且容易购买。
●这些数据库具有简单的用户界面，因此几乎任何人都会使用它们。
●使用这些数据库可以非常方便地添加、编辑和删除数据。
●若按照与整理档案柜相同的方式搜索数据，那么使用档案柜可方便地找到数据。
●大脑允许通过使用不同的关键字来查找数据(例如按照位置、价钱或服务质量)。
●所有这些数据库都允许查找它们包含的每条信息，尽管可能花费一段时间遍历所
有信息。
第1章有效数据库设计的目标
●只要存储的实际数据是一致的，那么所有这些数据库(除了大脑)都提供一致的结
果。例如，使用相同笔记本的两个人会查找到相同的数据。类似地，如果随后查
看同一个笔记本，它将显示与以前看到的数据相同的数据(前提是没有修改
它)。
●所有这些数据库(除了档案柜)都是便携的。
●大脑可以执行复杂的计算，至少对于有限的类型和数字是这样的。
●所有这些数据库都提供原子事务处理(或交易)。
最后一个优点比其他优点更为抽象一些，因此需要进行更多的说明。原子事务处理可能是一系列较为复杂的行动，那些不直接参与执行事务的人将它们看做是单一操作。
最典型的示例是从一个银行账户向另一个账户转账。假定Alice向Bob开了一张价值100美元的支票，并且需要在他们的账户之间转移这笔钱。您拿起记账本从Alice的记录上扣除100美元并将100美元添加到Bob的记录上，然后放下笔记本。其他使用笔记本的人可能在事务处理之前(此时Alice有100美元)或事务处理之后(此时Bob有100美元)查看它，但是不能在从Alice账户上扣除100美元但还没有转给Bob的事务处理过程中查看它。当处理进行到一半时绝不允许办公室里粗鲁的同事从您的手中抢走笔记本，它是一种要么全做要么不做的事务处理。
除了上述优点以外，诸如笔记本和档案柜这样的信息容器有一些缺点。研究这些缺点很有价值，这样一来便可以在构建计算机数据库时设法避免它们。
下面的列表汇总了这些信息容器具有的一些缺点。
●所有这些数据库都可能保存不完整的、不正确的或自相矛盾的数据。
●一些数据库容易丢失或被盗。一些人可能会趁您吃午饭的时候窃取您的笔记本或
者在公共汽车上从您的肩膀上偷看笔记本内容。另外，当匆忙赶航班时甚至可能
把笔记本遗忘在安检柜台上。
●在所有这些数据库中，纠正数据中较大的差错可能较为困难。例如，可以在地址
备忘录上使用钢笔更改某个人的地址。如果在您所在区域建造了一个新城市，则
更新数百个地址要困难得多(这种情况最近发生在我的居住地附近)。这种情况需要
对一摞名片、一本笔记本或档案柜进行冗长的搜索。而您的大脑彻底更新这种变
化可能需要几年的时间。
●根据不可控的因素，如情绪、疲劳程度甚至是否饥饿，大脑会在不同的时间给出
不同的结果。
●所有这些数据库都位于一个单独的地方，因此不能方便地共享它们。此外，每种
数据库也不能方便地备份，如果原始的数据库丢失或破坏则会丢失数据。
下一节考虑将上述优点和缺点转换成在计算机数据库中希望获得或避免的特性。
1.4 理想的数据库特性
通过了解物理数据库的优点和缺点，可以创建一个计算机数据库应该具有的特性列表。其中一些是所有数据库都必须具有的基本特性(应该能够从数据库中获取数据。这是很
7
第I部分数据库和数据库设计介绍
明显的特性)。
但是大多数特性至少部分依赖于良好的数据库特性。如果没有构建良好的设计，则会丧失这些特性的部分或全部。例如，任何恰当的数据库均提供备份特性，但是良好的设计可以使备份和恢复快速和方便得多。
下一节介绍优良的数据库系统应该提供的一些特性并解释了它们依赖良好数据库设计的具体程度。
1.4.1 CRUD
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’”)。如果常规的按地址搜索快于少见的按中间名的搜索则更好。
8
第1章有效数据库设计的目标
能够快速且可靠地查找到数据库中的所有数据是数据库设计的一个重要方面。在一个设计拙劣的数据库中查找需要的数据可能会花费数个小时或数天而不是仅仅数秒的时间。
1.4.3 一致性
CRUD中的R的另一个方面是一致性。数据库应该提供一致的结果。如果在一行中执行相同的两次搜索，应该得到相同的结果。执行相同搜索的另一个用户也应该得到相同的结果(当然，假定其间底层的数据没有变化。当股票价格剧烈波动时不能企望您的净值查询返回相同的结果)。
良好构造的数据库产品能够确保完全相同的查询返回相同的结果，但是设计还扮演着重要的角色。如果数据库设计拙劣，则可能会在数据库的不同部分中存储相冲突的数据。例如，您可能将一组联系信息存储在客户的订单中并将一组不同的信息存储在主客户记录中。随后如果需要联系客户了解有关订单的问题，那么应该使用哪条联系信息呢？
1.4.4 有效性(验证)
有效性与一致性的思想紧密相关。一致性是指数据库的不同部分不能保存相同信息的相互矛盾的视图。有效性是指在可能需要的地方相对数据库中的其他数据段对数据进行验证。在CRUD术语中，当创建、更新或删除记录时可以对数据进行验证。
正如物理数据容器一样，计算机数据库可能保存不完整、不正确或相矛盾的数据。我们无法防止不会拼写或只是简单录入错误信息的人破坏数据库，但是好的数据库设计有助于防范物理数据库无法阻止的一些错误类型。
例如，数据库可以方便地检验数据具有正确的类型。如果用户看到一个Date(日期)字段并录入“No thanks, I’m married”，那么数据库会指出这是无效的日期格式并拒绝接受此值。类似地，数据库可以提示“Old”不是有效的年龄(Age)，“Lots”不是有效的数量(Quantity)，并且“Confusion”过长而不是一个两字母的状态缩写(尽管该值可以正确反映用户的思维状态)。
数据库还可以检验用户输入的值是否出现在数据库的其他部分中。例如，一个粗心的打字员试图在State字段中输入CO却输入了CP。数据库会检查有效状态列表并且会在列表中没有找到CP时拒绝接受该数据(如果数据库需要仅使用某些状态，那么可以限制列表只包含那些状态并使测试更加严格)。
数据库还可以检查数据的某些类型的条件。假设数据库包含一个图书订购系统。当顾客订购某种图书500册时(他并不想要那么多册)，数据库可以检查其他部分来查看是否存在这么多册图书(对任意给定的图书大多数书店仅存有几册)，如果没有足够的数量则会拒绝此订购。
此外，良好的数据库设计还有助于防止对数据库进行不正确的更改。假定热牛奶咖啡及修理服务不再覆盖一座邻近的城市。当设法从有效位置列表中删除该城市时，数据库可以指出在此城市中是否还存在客户。根据数据库的设计，它能够拒绝删除该城市，除非已向那些客户表示歉意并从数据库中删除他们。
所有这些技术均依赖于良好、可靠的数据库设计。但是它们仍然不能防范用户在姓字段中输入名字或者用户意外敲击CAPS LOCK键，但是它能够防止笔记本这样的数据库所
9
第I部分数据库和数据库设计介绍
不能防范的许多类型的错误。
1.4.5 轻松的纠错
即使完美设计的数据库也无法确保绝对的有效性。数据库如何知道一个客户的名字应该被拼写成Pheidaux而不是用户键入的Fido呢？
在笔记本上纠正单个错误非常容易。只需划掉错误的值并写入新的值即可。
在笔记本中纠正系统的错误要困难得多。假定雇佣了一个暑期实习生逐户上门推销家用产品，他详细记录了很多“Duck Tape”订单，但是没有意识到实际的产品是“Duct Tape”。
修正所有错误可能会很乏味和耗时(当然，乏味和耗时的工作正是暑期实习生从事的工作，因此可以让他们自己修正所犯的错误)。此外，还可以忽视此问题并保留拼错的订单，但是随后如何知道某个客户何时真正想要为鸭子录音？
在计算机数据库中，这种纠错很简单。一条简单的数据库命令即可更新整个系统中出现的所有产品名称“Duck Tape”(实际上，这种纠错有时做起来过于简单。如果不够小心，可能会意外将所有产品的名称更改为Duct Tape，设置包括那些没有错误拼写为Duck Tape 的产品。通过为数据库构建可靠的用户界面来避免这种情况)。
方便的纠正错误是计算机数据库内在的一种特性，但是为了从此特性中获得最大的收益，则需要良好的设计。如果在自由编排格式的文本部分中包含订单信息，则数据库修订排印错误将会遇到麻烦。如果将产品名称放在分离的字段中，则数据库能够轻易做出这种更改。
尽管轻松纠错基本上不受约束，但是需要作少许设计以便使它们尽可能有效和高效。
1.4.6 速度
所有CRUD特性的一个重要方面是速度。良好设计的数据库能够快速创建、读取、更新和删除记录。
不可否认的是，计算机数据库比笔记本或档案柜快速得多。计算机数据库远不止每小时处理几十条记录，而能每秒处理几十条或上百条记录(我曾参与开发一个记账中心，它每3天可以处理大约300万个账户)。
良好的数据库设计在提高数据库效率上起着重要作用。拙劣构造的数据库尽管仍然比等效的纸制数据库快速，但是要比良好设计的数据库慢得多。
数据库设计
上一段提到的记账中心有一个小问题：它无法找到拖欠记账中心钱财最多的客户。数据库每隔3天会列出一份欠钱的客户列表。这份客户列表打印出来的一堆纸几乎高3英尺。
但是这份列表是随机排序的(很可能按照客户ID或鞋子尺码或其他同样无用的标准进行排序)，因此不能推算出欠钱最多的客户。大部分客户仅欠几元钱——太少而不必纠缠——但是少数客户却欠下上万元钱。
我们将此打印输出结果电子化处理后并按照余额来排列账户。结果表明真正有问题的客户仅占据几页并且前5个账户的欠款超过了其他所有账户欠款的总和。
我引入这个故事的目的不是炫耀我的编程能力(老实说，这是一个非常容易的项目)，10
第1章有效数据库设计的目标
而是为了说明数据库设计如何大幅改善系统性能。在此通过很简单的改动(任何数据库都应
该予以支持)可以在几秒钟内找出最令人忧虑(欠款最多)的客户，否则难以找到此客户。
并不是所有对数据库设计的更改都可以得到激动人心的结果，但是良好的设计的确在
改善性能方面发挥着重要作用。
1.4.7 原子事务处理
原子事务处理可能是一系列较为复杂的行动，那些不直接参与执行事务的人将它们看
做是单一操作。如果从Alice的账户向Bob的账户转账100美元，当数据库处于中间状态
时其他人不能查看数据库，这种状态是已从Alice的账户扣除100美元但还没有添加到Bob
的账户上。
事务处理要么其所属操作全部完成要么什么都不发生——而不能只进行一部分操作。
原子事务处理对于维护一致性和有效性很重要，因此对于CRUD中的R和U非常
重要。
物理数据容器(如笔记本)支持原子事务处理，因为通常一次只有一个人能够使用它。
除非当您在笔记本中写入记录时办公室粗鲁的同事Derek从您的手中抢去笔记本，在允许
其他人有机会使用笔记本之前只能完成一系列操作。
一些最简单的数据库类型，如平面文件和XML文件(本书后面将介绍它们)并不是本身
就支持原子事务处理，但是更高级的关系数据库产品能够对此予以支持。这些数据库允许
开始事务处理并执行一系列操作。然后可以提交事务处理以便使更改成为永久性的，或者
回滚事务处理以便全部取消这些操作并将数据库恢复到开始事务处理之前的状态。
此外，如果数据库意外停止，这些数据库还将自动回滚打开的任何事务处理。例如，
假设开始一个事务处理，从Alice的账户中取出100美元，随后您公司的吉祥物(一匹小马)
走进微机房，踩上电源板并切断了主机的电源。当重新启动数据库(在将小马送至人力资源
部后)时，它自动回滚事务处理以便使Alice找回她的钱。然后需要再次尝试事务处理，但
是至少要求系统没有丢失任何钱财。
原子事务处理与其说是数据库设计问题，还不如说是一种正确使用数据库特性的问题。如果挑选了适当高级的数据库产品并正确使用事务处理，将会获得其好处。如果决定
使用平面文件来存储数据，则将需要亲自实现事务处理。
1.4.8 ACID
本节对上一节描述的事务处理进行了更加详细的介绍，而不是讨论物理数据容器和计
算机数据库的新特性。
ACID是描述一个有效的事务处理系统应提供的4种特性的首字母缩写词。ACID代表Atomicity(原子性)、Consistency(一致性)、Isolation(隔离性)和Durability(持久性)。
原子性是指事务处理是原子的。事务处理中的操作要么全部完成要么都不执行。
一致性是指事务处理确保数据库在事务处理前后处于一致的状态。换句话说，如果事
务处理内的操作违反数据库的规则，则回滚事务处理。举例而言，假设数据库的规则规定
一个账户不能完成导致余额少于零的支付。此外，假定Alice的账户仅有75美元。现在开
11
第I部分数据库和数据库设计介绍
始一个事务处理，向Bob的账户添加100美元，然后试图从Alice的账户上扣除100美元。
这样做将使Alice负债25美元，违反了数据库的规则，因此会取消此事务处理并且都会设法忘记这种难堪的事件曾经发生过(实际上我们可能由于开错了支票而给Alice开了一张令人气愤的过多扣费的账单)。
隔离性是指事务处理向除了执行事务处理的人以外的所有人隐蔽其细节。假定开始了一个事务处理，从Alice的账户上扣除100美元并将这100美元添加到Bob的账户。在此操作的过程中，其他人都不能窥视数据库并且看不到Alice和Bob拥有100美元的状态。
任何查看数据库的人都能在某个账户上看到100美元，不同的是在事务处理之前是在Alice 的账户上而在事务处理之后却是在Bob的账户上。
具体而言，两个事务处理运行在隔离状态并且不能相互干扰。假设一个事务处理从Alice向Bob转账100美元，然后另一个事务处理从Bob向Cindy转账100美元。逻辑上，一个事务处理要先出现并在另一个事务处理开始之前结束。例如，当第二个事务处理开始时，它将看不到Alice的账户上消失了100美元，除非它已经转移到Bob的账户上。
事务处理出现的次序可能会造成很大不同。假设Alice最初有150美元，Bob最初有50美元。
现在假定第二个Bob到Cindy转账的事务处理先发生，如果事务处理首先从Bob的账户上扣除100美元，Bob将会透支，于是回滚此事务。我们评定Bob由于扣费过高而透支，并设法向Bob推销非常低价的每月仅10美元的透支保护。在此事务处理的所有操作完成后，Alice到Bob转账的事务处理才发生，并且成功地向Bob的账户转账100美元。
与此相反，假设Alice到Bob的事务处理先发生。此事务处理成功完成而不会带来任何问题，因此当Bob到Cindy的事务处理开始时，Bob的账户已有150美元并且第二个事务处理能够成功地完成。
数据库不能决定哪个事务处理首先开始，而只是决定在另一个事务处理开始之前提交或回滚一个事务。
持久性是指一旦提交了一个事务处理，它就不会消失。如果电源出问题，此时造成数据库重新启动，该事务处理的作用仍然保留。
持久性要求依赖于一致性规则。一致性确保如果事务处理使数据库处于一种违反数据库规则的状态，则不会完成事务处理。持久性意味着数据库将不能随后确定事务处理造成了这样一种状态，并且回溯性地删除该事务处理。
一旦提交了事务处理，那么它是不能改变的。
高端数据库可以通过连续的镜像(或影像)来提供持久性。每次执行数据库操作，都会将其镜像到另一个系统。如果主系统崩溃，则镜像数据库可以立即投入服务。
其他数据库可以通过日志提供持久性。数据库每次执行操作时，都会将此操作的记录写入到日志中。现在假设系统崩溃，当数据库重新启动时它将重新加载其最后保存的数据，然后重新运用日志描述的所有操作。相比于从镜像数据库重启，这种方式花费更长的时间，但是要求更少的资源，因此通常更加便宜。
为了提供持久性，在将其变化进行镜像或记录到日志中之前，数据库不认为事务处理12
第1章有效数据库设计的目标
是提交的，因此即使数据库崩溃，它也不会丢失变化。
1.4.9 持久性和备份
数据必须是持久的，它不应该自动更改或消失。如果连你都不信任数据库能够安全地
保存数据，那么数据库将毫无用处。
数据库产品应尽量保持数据的安全性，并且在正常操作中不需要做大量工作来获得数
据持久性带来的好处。但是当出现异常的情况时，可能需要采取特殊的行动并要求事先规划。例如，假定保存数据库的磁盘驱动器完全损坏。或者火灾使计算机完全损毁了，再有
就是用户意外或有意删除了数据库(一个用户对我曾参与的一个项目尝试这样做过一次，最
终大家都不高兴)。
在这些极端的情况下，数据库将无能为力。为了防止这类问题，需要执行常规的备份。
物理数据容器(如笔记本)通常难以备份，因此难以使其免受损伤。如果火灾烧毁了您
的账户收款笔记本，则将不得不依赖客户的诚信来收回欠款了。尽管我们爱戴客户，但我
不能确保大多数企业能如此信任他们。
在理论上可以创建笔记本的副本并将它们存放到不同的位置以防范这类事件，但是实
际上很少有企业这样做(除了可能的洗钱、走私和其他为了方便向执法人员和股东出示不同
账本的企图)。
但是计算机数据库备份起来相对容易。如果丢失少量数据并不会过度损害您，而且还
可以每日备份数据库。如果火灾、计算机病毒或其他某种意外事件破坏了主数据库，还可
以重新加载备份数据库并在一两个小时内做好恢复操作的准备。
如果数据库非常不稳定或者如果即使丢失少量数据仍会造成很大问题(可以想象在繁
忙的一小时内通过纽约证券交易所交易的资金有多少)，则需要不同的备份策略。很多高端
的数据库产品都允许镜像出现的每个数据库操作，因此对于出现的每种状况总是保留有完
整的副本。即便主数据库遭到破坏，仍可以在数分钟内恢复业务。一些数据库体系结构可
以如此快速地切换到备份数据库，甚至连用户都察觉不到发生了数据库切换。
备份计划
将备份存储到远离执行备份的计算机总是最好的做法。因此如果像火灾这样真正的大
事故发生并烧毁存有数据库的整座大楼，那么备份仍然是安全的。
我认识的几个开发组通常将备份直接存储到他们正备份的计算机旁边。这种做法仅可
以防范某些愚蠢的做法(在我曾工作过的小组中，大约每10个人一年中就有一人会意外删
除一个需要从备份中恢复的文件)，但却不能防范更大的意外事故。
我还知道有些公司制定了正式的备份计划，但是一旦提交了一个真正存储的备份，它
将转移至远离现场所在的位置，而且在需要它时花费较长的时间才能取回它。如果不能使
用它，那么备份基本没有多少用处！
在一个非常极端的示例中，我有一个客户甚至担心备份存储的位置距离原始数据库仅
30英里。他们的想法是在出现火山爆发或原子弹爆炸的时候备份可能仍不够安全。
13
第I部分数据库和数据库设计介绍
14 正确实现数据库备份的方法取决于多种因素，如认为问题出现的可能性多大、需要恢
复数据库的频率以及丢失一些数据并花费时间从备份恢复造成的损失有多么大，但是相比于笔记本，计算机数据库提供的选择要多得多。
良好的数据库设计有助于更为容易地创建备份。如果合理安排数据使得变化大都出现在局部区域，那么则可以相当频繁地备份此区域而不浪费时间备份仅偶尔变化的数据。
1.4.10 低成本和可扩充性
理想情况下，数据库应该容易获取易安装、便宜且易于扩展。如果发现每天需要处理的数据远多于期望的数据，则应该确保能够以某种方式增加数据库的容量。
尽管一些数据库产品非常昂贵，但是大多数数据库都具有适当的升级途径，因此可以购买价格最低的能够满足需求的许可证，至少开始时是这样。例如，SQL Server、Oracle 和MySQL都提供了免费的版本可以用来开始构建小型的单用户应用程序。它们也提供了更昂贵的版本，适用于非常大型的具有数百个用户的应用程序。
安装数据库绝不像购买一个新的笔记本一样容易和便宜，不过它也不必是一个耗时的金融噩梦。
尽管费用和容量更多是特定数据库产品而非数据库设计的特性，但是良好的数据库设计有助于获得一种不同类型的可扩展性。假定使用了笔记本数据库一段时间并发现需要获取新的信息类型。或许需要跟踪客户的饮食习惯，以便了解在特定的场合给它们什么样的饭店赠券。在这种情况下，若能够扩展数据库设计以容纳这种额外的信息则是令人满意的。
良好的数据库设计使得这种扩展成为可能。
1.4.11 易用性
笔记本和档案柜具有简单的用户界面，因此几乎所有人都可以有效使用它们(尽管有时搞得非常混乱，应该将“United States Postal Service”归档在“United States”、“Postal Service”还是“Snail Mail”)。
计算机应用程序的用户界面决定了对于一般用户而言的可用程度。用户界面设计并不属于数据库设计的内容，因此您可能想知道为何在这里提及易用性。
数据库级别最高的用户通常是编程人员和相对富有经验的数据库用户，他们知道操纵数据库的方式。良好的数据库设计可以使这些用户更容易访问数据库。只需要通过查看表的名称、字段和其他组织数据的数据库记录项，这种用户应该能够了解不同的数据段组合在一起的方式以及使用它们检索所需要的数据的方法。如果这些高级的用户可以方便地理解数据库，则可以为较低级的用户创建更好的用户界面。
1.4.12 便携性
计算机数据库提供的便携性能力远胜于笔记本。它允许从可以访问Web的任何地方访问数据，而不必实际转移物理数据库。差不多可以从任何地方访问数据库，而数据本身可以安全地存放在家中，从而远离扒手、掉在泥浆和遗忘在公共汽车上的危险。
实际上，新型的便携性可能有些过于容易了。尽管飞机上您座位后面的某个人无法像窥探笔记本那样从您背后偷窥计算机里的数据(是的，如果您使用笔记本是能够偷窥的)，
第1章有效数据库设计的目标
但是地球另一端的电脑黑客可能可以设法侵入数据库并在您睡着的时候窃取客户的数据。
这一问题引出了下一个主题，安全性。
1.4.13 安全性
相比起来，笔记本更容易丢失或窃取，但是高度便携的数据库却更容易遭到安全威胁。如果能够从全世界各地访问数据库，那么计算机窃贼和其他网络罪犯也可以访问数据库。
锁定数据库通常是应该通过网络和数据库的安全工具加以解决的安全问题。但是，有
一些设计技术可以用来更方便地确保数据库的安全性。
信息窃取
迄今发生了大量笔记本电脑、硬盘和磁盘丢失或被窃以及其他媒体潜在向坏蛋暴露机
密信息的事件。
● 2005年1月22日，北科罗拉多州大学的一个含有大约30 000个大学在职人员和
曾供职人员个人信息的硬盘被盗。
● 2005年12月22日，福特汽车公司的含有公司7 000个在职人员和曾供职人员的
名称和社会保险号码的计算机被窃。三天之后，即2005年12月25日，Ameriprise
金融公司的含有大约260 000客户的敏感信息的笔记本电脑被盗(后来找到了该笔
记本电脑)。
● 2006年6月1日，含有https://www.360docs.net/doc/032931286.html,公司大约243 000位客户信息的笔记本电脑被窃。
● 2007年1月13日，北科罗拉多州税务部门的一台含有30 000名纳税人的纳税信
息的计算机被盗。
● 2008年1月24日，一台含有大约30 000名病人秘密信息的Fallon Community Health
Plan电脑被窃。
● 最后，迄今最大的数据丢失事件出现在2006年5月3日，美国退役军人事务所一
台含有大约28 600 000名退伍军人和现役人员信息的笔记本电脑被盗。
我并不打算找出这些受害人。这是一个大问题，全球就算不到上千家也有上百家公司
遭受了类似的数据泄密事件。隐私权票据交换所网页(https://www.360docs.net/doc/032931286.html,/ar/ChronData Breaches.htm)上的“数据损失年表”列出了自从该网站开始于2005年跟踪事件以来单在美
国总数超过230 000 000项的泄密记录。
如果将数据分离到不同类型的用户需要操纵的类别中，可以向不同类型的用户授予不
同级别的权限。仅赋予用户访问他们绝对需要的数据不仅能减少合法用户做各种蠢事或错
事的机会，而且会降低攻击者冒充此类用户并做某种坏事的机会。即使愚笨的Carl不会故
意损毁您的数据，网上的恶棍也有可能会猜出Carl的口令(很自然是Carl)并设法从事破坏
活动。如果Carl没有权限破坏账户数据，那么网络恶棍也不能做到。
数据库安全的另一个新情况是：实际上，用户可以远程访问数据库而不必在本地保存
数据库的副本。可以使用掌上型电脑来访问数据库而不必将数据存储到您的计算机上。
这意味着若确实不知何故丢失了自己的计算机，数据仍然安全地存放在数据库的计算机上。
此问题更多的是应用程序体系结构问题而并非数据库设计问题(不要将数据本地存储
15
第I部分数据库和数据库设计介绍
在笔记本电脑上)，但是通过数据库设计限制用户仅能访问他们确实需要了解的数据是有帮助的。
1.4.14 共享
在许多人中间共享使用笔记本或装满名片的信封很不方便。实际上，两个用户很难同时使用同一个笔记本，而且在用户之间来回传递笔记本会带来一些花销。每天花时间穿越房间12个来回将是够令人厌烦的；跨越国家用快件邮件笔记本无疑是非常愚蠢的做法。
现代网络能够允许数百个乃至数千个用户从全球各地同时访问相同的数据库。尽管这在很大程度上是采用联网方法和特定数据库提供的工具，但是一些设计问题确实在起作用。
如果按照上一节中描述的那样，将数据划分到不同类型的用户需要使用的类别中，这不仅有助于提高安全性而且还有助于减少需要跨越网络传送的数据量。
将数据分解成适当的片段还有助于协调多个用户的操作。当伦敦的同事开始编辑客户的记录时，必须锁定此记录以便在编辑完成之前其他用户不能进入系统并将记录搞乱。适当对数据分组允许锁定尽可能少的数据以便使更多的数据可供其他用户编辑。
细致的设计允许数据库执行一些计算并仅将计算结果传送到正在夏威夷海滩辛勤工作的老板手中，而不必将整个数据库传送到那里并让他的计算机执行所有的工作。
良好的应用程序设计也非常重要。即使在做好高效使用数据库的准备之后，应用程序仍需要正确使用它。但是如果没有良好的数据库设计，则不可能实现这些技术。
1.4.15 执行复杂计算的能力
与人的大脑相比，计算机有点像傻瓜。它采用非常强大的硬件和极度复杂的算法来执行人们认为理所当然的任务，如人脸识别、与讲话者无关的语音识别和手写识别(尽管人的大脑和计算机还都不能辨认医生的处方)。此外，人的大脑是自动编程的，因此可以灵活且快速地学习新的任务。
尽管计算机缺乏人的大脑具有的自适应性，但是它擅长快速、重复和可靠地执行一系列明确定义的任务。计算机不会感到厌倦、注意力不集中并且不会犯简单的算术错误(除非它遭受声名狼藉的Pentium FDIV缺陷、f00f错误、Cyrix昏睡问题或其他一些程序错误的影响)。要点是如果底层的硬件和软件运行正确，计算可以无差错地每秒反复执行同样的任务上百万次。
在遇到结算支票簿、搜索余额小于零的账户和执行其他许多涉及数字的任务时，计算机明显要比大脑快速得多且不容易出错。
对于这类计算而言，计算机自然更快速，但是如果数据库设计拙劣，则即使这种令人吃惊的高计算速度也不可能起太多作用。良好的数据库设计可以在数秒内找到需要的数据而不必花费几个小时、几天或者根本找不到数据。
1.4.16 良好设计和拙劣设计对应的结果
表1-1总结了良好的设计和拙劣的设计影响上一节介绍的各种特性的方式。
16
第1章有效数据库设计的目标
17
第I部分数据库和数据库设计介绍
1.5 本章小结
本章说明了数据库设计在应用程序开发中起着重要的作用。如果数据库设计没有为构建项目的其余部分提供坚实的基础，则整个应用程序将会失败。
本章还介绍了可以表现为数据库的物理数据容器，讨论了这些对象的优缺点并解释了计算机数据库扬长避短的方式。
我们在本章中了解到良好的数据库需提供如下特性：
●CRUD
●检索
●一致性
●有效性
●便于纠错
●速度
●原子事务处理
●ACID
●持久性和备份
●低成本和可扩展性
●易用性
●便携性
●安全性
●共享
●执行复杂计算的能力
本章使用诸如笔记本和档案柜这样的物理对象来研究数据库目标和潜在的问题。这些物理系统能够较为有效地满足一些而非所有数据库目标。
下一章将介绍几种不同的计算机数据库，说明每种数据库能具体满足和不满足哪些目标。
尽管本书主要关注关系数据库，但是其他一些类型的数据库对于某些应用而言更为简单并且足够适用。
在阅读下一章之前，请进行如下的练习并测试您对本章介绍的数据库设计目标的了解情况。练习答案参见附录A。
1.6 练习
1．将本书比喻为数据库(假定不仅将其用做笔记本，并在页边空白乱涂)，试说明它提供了什么样的特性？缺少哪些特性？
2．描述本书提供的两个可帮助以不同的方式查找特定的数据段的特性。
3．CRUD代表什么内容？这些术语的含义是什么？
4．黑板如何实现CRUD方法？黑板作为数据库的特性在哪些方面能够与本书的数据18
第1章有效数据库设计的目标
库特性相比拟？
5．试构思一个食谱文件，针对每道食谱采用单个索引卡并且按照字母顺序存储索引卡。这种数据库的特性在哪些方面能够与本书的数据库特性相比较？
6．ACID代表什么内容？这些术语的含义是什么？
7．假设Alice、Bob和Cindy都有100美元的账户余额并且数据库不允许账户的余额
少于零。现在考虑3个事务处理：1)Alice向Bob转账125美元，2)Bob向Cindy转账150
美元，3)Cindy向Alice转账25美元并向Bob转账50美元。采用哪种次序可以成功执行上
述3个事务处理？
8．试解释中心数据库保护机密数据的方法。
19
数据库课程设计心得体会精选篇
数据库课程设计心得体会精选篇 课程培训活动，四对于提高专业技能的一个很好的方式，下面由小编为大家带来的数据库课程设计心得体会精选范文，仅供参考~ 数据库课程设计心得体会一 两个星期的时间非常快就过去了，这两个星期不敢说自己有多大的进步，获得了多少知识，但起码是了解了项目开发的部分过程。虽说上过数据库上过管理信息系统等相关的课程，但是没有亲身经历过相关的设计工作细节。这次实习证实提供了一个很好的机会。 通过这次课程设计发现这其中需要的很多知识我们没有接触过，去图书馆查资料的时候发现我们前边所学到的仅仅是皮毛，还有很多需要我们掌握的东西我们根本不知道。同时也发现有很多已经学过的东西我们没有理解到位，不能灵活运用于实际，不能很好的用来解决问题，这就需要我们不断的大量的实践，通过不断的自学，不断地发现问题，思考问题，进而解决问题。在这个过程中我们将深刻理解所学知识，同时也可以学到不少很实用的东西。 从各种文档的阅读到开始的需求分析、概念结构设计、逻辑结构设计、物理结构设计。亲身体验了一回系统的设计开发过程。很多东西书上写的很清楚，貌似看着也很简单，
思路非常清晰。但真正需要自己想办法去设计一个系统的时候才发现其中的难度。经常做到后面突然就发现自己一开始的设计有问题，然后又回去翻工，在各种反复中不断完善自己的想法。 我想有这样的问题不止我一个，事后想想是一开始着手做的时候下手过于轻快，或者说是根本不了解自己要做的这个系统是给谁用的。因为没有事先做过仔细的用户调查，不知道整个业务的流程，也不知道用户需要什么功能就忙着开发，这是作为设计开发人员需要特别警惕避免的，不然会给后来的工作带来很大的麻烦，甚至可能会需要全盘推倒重来。所以以后的课程设计要特别注意这一块的设计。 按照要求，我们做的是机票预订系统。说实话，我对这个是一无所知的，没有订过机票，也不知道航空公司是怎么一个流程。盲目开始设计的下场我已经尝过了，结果就是出来一个四不像的设计方案，没有什么实际用处。没有前期的调查，仅从指导书上那几条要求着手是不够的。 在需求分析过程中，我们通过上网查资料，去图书馆查阅相关资料，结合我们的生活经验，根据可行性研究的结果和客户的要求，分析现有情况及问题，采用client/server结构，将机票预定系统划分为两个子系统：客户端子系统，服务器端子系统。在两周的时间里，不断地对程序及各模块进行修改、编译、调试、运行，其间遇到很多问题：由于忘记了一
关于用户权限的数据库设计
1 设计思路 为了设计一套具有较强可扩展性的用户认证管理，需要建立用户、角色和权限等数据库表，并且建立之间的关系，具体实现如下。 1.1 用户 用户仅仅是纯粹的用户，用来记录用户相关信息，如用户名、密码等，权限是被分离出去了的。用户（User）要拥有对某种资源的权限，必须通过角色（Role）去关联。 用户通常具有以下属性： 编号，在系统中唯一。 ü名称，在系统中唯一。 ü用户口令。 ü注释，描述用户或角色的信息。 1.2 角色 角色是使用权限的基本单位，拥有一定数量的权限，通过角色赋予用户权限，通常具有以下属性： ü编号，在系统中唯一。 ü名称，在系统中唯一。 ü注释，描述角色信息 1.3 权限 权限指用户根据角色获得对程序某些功能的操作，例如对文件的读、写、 修改和删除功能，通常具有以下属性： ü编号，在系统中唯一。 ü名称，在系统中唯一。 ü注释，描述权限信息 1.4 用户与角色的关系 一个用户（User）可以隶属于多个角色（Role），一个角色组也可拥有多个用户，用户角色就是用来描述他们之间隶属关系的对象。用户（User）通过角色（Role）关联所拥有对某种资源的权限，例如 l 用户（User）： UserID UserName UserPwd 1 张三 xxxxxx 2 李四 xxxxxx …… l 角色（Role）： RoleID RoleName RoleNote 01 系统管理员监控系统维护管理员 02 监控人员在线监控人员 03 调度人员调度工作人员 04 一般工作人员工作人员…… 从该关系表可以看出，用户所拥有的特定资源可以通过用户角色来关联。 1.5 权限与角色的关系 一个角色（Role）可以拥有多个权限（Permission），同样一个权限可分配给多个角色。例如： l 角色（Role）： RoleID RoleName RoleNote 01 系统管理员监控系统维护管理员 02 监控人员在线监控人员
微信数据库分析与设计
微信数据库分析与设计 一、需求分析 微信作为当前的主要即时通讯工具之一，有着广泛的应用。其主要的功能是实现即时通信，这也是微信的核心功能。此外还有查看朋友圈动态、搜索好友、管理个人信息、建立用户自己的相册、收藏功能、摇一摇、搜索附近的人、购物、游戏等功能。此次对于微信平台的数据库设计主要对部分需要微信平台提供存储信息功能进行需求分析及设计。以下将对微信平台的主要需求做简要的分析并且根据分析做出数据流图使得对于微信平台数据库的设计有更好的理解。 微信的通信主要包括与微信好友进行相互通信，这其中通信内容包括文字、语音、图片及视频。当用户订阅了公众号之后，会接收公众号发送的消息并且也可向公众号发信息或许其提供的信息。 微信通信功能的另一个主要方面是实现群聊。用户可以加入一个微信群进行群。另一方面用户也可以选择自己的联系人进行群聊。 微信中通讯录实现了保存用户联系人的目的，并且订阅的公众号也保存于通讯录中，并且在通讯录中可以设定标签来为联系人分组。 微信朋友圈保存好友发送的与朋友共享的消息，其内容可为文字、图片、视频。在朋友圈中可以设定权限使得不同权限的用户查看的内容不一样。 摇一摇功能可以获取同一时刻一起摇动手机的用户，并且暂存于微信中。 附近的人功能可以识别在一定范围内的微信用户，并且将获得的用户信息也暂存在微信中，对于识别附近的用户可以设定具体的条件来扫描。 漂流瓶功能相当于随机的获取微信消息或者向微信用户随机的发送消息。 对于个人信息的编辑，用户可以根据自身需要编辑一些所需的个人信息。 最后在微信用户个人信息中有相册和收藏记录用户的照片和收藏的文字语音等信息。 以上是对微信的部分功能的需求分析，现根据以上需求对微信数据库画出数据流图： 第0层DFD： 第1层DFD：
数据库需求分析
数据库设计：需求分析? 设计一个性能良好的数据库系统，明确应用环境对系统的要求是首要的和基本的。因此，应该把对用户需求的收集和分析作为数据库设计的第一步。 需求分析的主要任务是通过详细调查要处理的对象，包括某个组织、某个部门、某个企业的业务管理等，充分了解原手工或原计算机系统的工作概况及工作流程，明确用户的各种需求，产生数据流图和数据字典，然后在此基础上确定新系统的功能，并产生需求说明书。值得注意的是，新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。 如图所示，需求分析具体可按以下几步进行： (1)?? 用户需求的收集。 (2)?? 用户需求的分析。 (3)?? 撰写需求说明书。 图 ?需求分析的过程 需求分析的重点是调查、收集和分析用户数据管理中的信息需求、处理需求、安全性与完整性要求。信息需求是指用户需要从数据库中获得的信息的内容和性质。由用户的信息需求可以导出数据需求，即在数据库中应该存储哪些数据。处理需求是指用户要求完成什么处理功能，对某种处理要求的响应时间，处理方式指是联机处理还是批处理等。明确用户的处理需求，将有利于后期应用程序模块的设计。 调查、收集用户要求的具体做法是： (1)?? 了解组织机构的情况，调查这个组织由哪些部门组成，各部门的职责是什么，为分析信息流程做准备。
(2)?? 了解各部门的业务活动情况，调查各部门输入和使用什么数据，如何加工处理这些数据。输出什么信息，输出到什么部门，输出的格式等。在调查活动的同时，要注意对各种资料的收集，如票证、单据、报表、档案、计划、合同等，要特别注意了解这些报表之间的关系，各数据项的含义等。 (3)?? 确定新系统的边界。确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。 在调查过程中，根据不同的问题和条件，可采用的调查方法很多，如跟班作业、咨询业务权威、设计调查问卷、查阅历史记录等。但无论采用哪种方法，都必须有用户的积极参与和配合。强调用户的参与是数据库设计的一大特点。 收集用户需求的过程实质上是数据库设计者对各类管理活动进行调查研究的过程。设计人员与各类管理人员通过相互交流，逐步取得对系统功能的一致的认识。但是，由于用户还缺少软件设计方面的专业知识，而设计人员往往又不熟悉业务知识，要准确地确定需求很困难，特别是某些很难表达和描述的具体处理过程。针对这种情况，设计人员在自身熟悉业务知识的同时，应该帮助用户了解数据库设计的基本概念。对于那些因缺少现成的模式、很难设想新的系统、不知应有哪些需求的用户，还可应用原型化方法来帮助用户确定他们的需求。就是说，先给用户一个比较简单的、易调整的真实系统，让用户在熟悉使用它的过程中不断发现自己的需求，而设计人员则根据用户的反馈调整原型，反复验证最终协助用户发现和确定他们的真实需求。 调查了解用户的需求后，还需要进一步分析和抽象用户的需求，使之转换为后续各设计阶段可用的形式。在众多分析和表达用户需求的方法中，结构化分析(Structured Analysis，SA)是一个简单实用的方法。SA方法采用自顶向下，逐层分解的方式分析系统，用数据流图(Data Flow Diagram，DFD)、数据字典(Data Dictionary，DD)描述系统。 1. 使用数据流图分析信息处理过程 数据流图是软件工程中专门描绘信息在系统中流动和处理过程的图形化工具。因为数据流图是逻辑系统的图形表示，即使不是专业的计算机技术人员也容易理解，所以是极好的交流工具。图给出了数据流图中所使用的符号及其含义。
有效数据库设计的目标
有效数据库设计的目标 借助现代数据库工具，几乎所有人都能够创建数据库。但是问题是，得到的数据是否有用？ 如果不能从其中快速、可靠且一致地取出数据，那么数据库不会有多少用处。如果数据库里都是不正确的或自相矛盾的数据，那么将毫无用处。此外，如果数据库被窃取、丢失或者当系统崩溃时遭受到仅半写入的数据的破坏，那么它也是无用的。 现代数据库工具、好的数据库设计和一些常识可以解决所有这些潜在的问题。只要能够了解这些问题的实质，则可以避免它们。 获得有用数据库的第一步是了解数据库的目标。数据库应该完成哪些任务？怎么样能使数据库变得有用以及它能解决什么样的问题？使用一个强大的数据库工具但却没有制定目标就像驾驶飞机在云中飞行而没有罗盘：您拥有自己需要的工具但是却不知道方向。 本章将描述数据库设计的目标。通过研究诸如文件这样能够充当数据库的信息容器，则可以定义数据库应该具有的特性和它们应该避免的问题。 在本章将会学到如下内容： ● 好的数据库设计之所以重要的原因。 ● 可以充当数据库的各种不同的信息容器的优点和缺点。 ● 如何使计算机化的数据库受益于这些优点并避免那些缺点。 ● 好的数据库设计有助于达成数据库目标的方法。 ● CRUD 和ACID 的概念以及它们和数据库设计相关的原因。 1.1 理解数据库设计的重要性 请暂时忘记本书是有关数据库设计的，并考虑常规的软件设计。软件设计在软件开发中起着重要的作用。设计规划了今后开发将会采用的大体结构和方向，决定系统各部分之间的交互关系以及哪些子系统对应用程序的其他部分提供支持。 如果应用程序的基础设计是有缺陷的，那么系统整体上将存在危险。设计中错误的假定会渗入应用程序最低级的代码，导致子系统出现问题。构建在这些子系统上的高级系统将沿袭设计缺陷并且它们的代码很快也会受损坏。 有时，代码受到一点损坏便会弥散到整个系统并且直到项目进入到相对较晚的阶段才第 章 第 章 1
数据库课程设计心得体会
数据库课程设计心得体会 数据库课程设计心得体会 数据库课程设计大赛的尘嚣渐渐远去,怀着对这次大赛的些许不舍,怀着对当初课程设计开始时候的豪情万丈的决心的留恋,怀着通过这次课程设计积累的信心与斗志,我开始写这篇文章,为自己的足迹留下哪怕是微不足道但是对自己弥足珍贵的痕迹并期望与大家共勉。 首先,让我的记忆追溯到大二暑假,在老大的指引下(老大劝我学https://www.360docs.net/doc/032931286.html,),我接触到microsoft 公司的.net产品。那个时候我已经学过vc 和asp,因为windows程序设计实验的课的关系,接触过vb,但是没有专门去学他,因为习惯了c++里面的class,int,觉得vb的sub,var 看着就不是很顺心。我是一个好奇心很强的人,突然看到了一个号称“.net是用于创建下一代应用程序的理想而又现实的开发工具”,而且主推c#语言,由于对c语言的一贯好感,我几乎是立刻对他产生了兴趣。我就开始了对c#的学习,任何语言都不是孤立存在的,所以数据交互是很重要的,暑假的时候我把我们这学期的课本数据库系统概论看了一遍。我记得以前用c语言编程的时候,数据是在内存中申请空间,譬如使用数组等等。很耗费内存空间。这个时候就是数据库站出来的时候啦,于是我又装上了sql server2000,以前学asp的时候用的是access,那个时候只是照着人家做,理论是什么也不是很清楚。 通过一个暑假的学习,基本搞清楚了理论方面的东西,具体怎么用也不是很清楚。但是这为这学期的课程设计打下了铺垫。 来到学校后,随着这学期的数据库课程大赛开始了,我有一个看法就是我自己应该具备的能力不是我会多少,而是我应该具备快速学会东西的能力。遇到什么就学什么。我们有时候很容易被一些专业名词说吓着,包括什么建模,软件工程,数据分析,数据挖掘等等。我身边就有很多同学被这些纸老虎所唬住,而没有勇气去接触他们,总是说这个太难了之类的退堂鼓的话,他们低估了自己的潜力同时也压抑住了他们自己的好奇心。其实都是纸老虎,又不是什么国家科研难题,只是去用一些工具,发明工具是很难,但是用一个工具就容易多了,just do it!我记得我做这个数据库之前,我们老师说要做好前期分析,我就在网上搜索用什么分析工具好。最后我选择了roseuml建模工具。在此之前,我脑袋里面没有软件建模的思想,什么uml 建模对我而言就是一张空白的纸。但是真正接触后并没有想象的那么难,有什么不懂的上网去搜索,这是一个信息横流的世界,有google,baidu就没有不能解决的知识难题。以及后来的数据库分析的时候用到的powerdesigner也是一样。 开发的时候我想过用什么架构,c/s模式?模式有很多,怎么选择?我就上网搜索现在最流行的架构是什么。结果搜到了mvc架构,就是你啦。我决定用这个架构,不会,没关系,咱学。just do it!前期工作准备好后,那么我就得把我暑假学的.net加以实践。这个时候我更加深入的了解了利用https://www.360docs.net/doc/032931286.html,操纵数据库的知识。并且对数据库里面的存储过程有了比较深入的了解。经过大概2个多星期的奋斗,我完成了我的数据库课程设计--基于.net数据集的图书馆管理系统。并最后非常荣幸的获得了大赛的一等奖以及以及新技术应用奖。 与其临渊羡鱼,不如退而结网。这次数据库课程设计给我的最大的印象就是如果自己有了兴趣,就动手去做,困难在你的勇气和毅力下是抬不了头的。从做这个数据库开始无论遇到什么困难,我都没有一丝的放弃的念头。出于对知识的渴望,出于对新技术的好奇,出于对一切未知的求知。我完成了这次数据库课程设计,不过这只是我学习路上的驿站,未来十年.net 的核心技术就是xml[至少微软是这么宣传的],我会继续学习它,包括jave公司的j2ee我也很想试试,语言本来就是相通的,just do it!语言并不重要毕竟它仅仅是工具,用好一个工具并不是一件值得为外人道的事情,主要是了解学习思想。古语说的好:学无止境啊! 我很庆幸我参加了这次数据库大赛,让我确实打开了眼界。 (最后,很感激学校给了我们这次动手实践的机会,让我们学生有了一个共同学习,增长
关于用户权限的数据库设计
1设计思路 为了设计一套具有较强可扩展性的用户认证管理，需要建立用户、角色和权限等数据库表，并且建立之间的关系，具体实现如下。 1.1用户 用户仅仅是纯粹的用户，用来记录用户相关信息，如用户名、密码等，权限是被分离出去了的。用户（User）要拥有对某种资源的权限，必须通过角色（Role）去关联。 用户通常具有以下属性： 编号，在系统中唯一。 ü名称，在系统中唯一。 ü用户口令。 ü注释，描述用户或角色的信息。 1.2角色 角色是使用权限的基本单位，拥有一定数量的权限，通过角色赋予用户权限，通常具有以下属性： ü编号，在系统中唯一。 ü名称，在系统中唯一。 ü注释，描述角色信息 1.3权限 权限指用户根据角色获得对程序某些功能的操作，例如对文件的读、写、 修改和删除功能，通常具有以下属性： ü编号，在系统中唯一。 ü名称，在系统中唯一。 ü注释，描述权限信息 1.4用户与角色的关系 一个用户（User）可以隶属于多个角色（Role），一个角色组也可拥有多个用户，用户角色就是用来描述他们之间隶属关系的对象。用户（User）通过角色（Role）关联所拥有对某种资源的权限，例如l用户（User）： UserID UserName UserPwd 1张三xxxxxx 2李四xxxxxx …… l角色（Role）： RoleID RoleName RoleNote 01系统管理员监控系统维护管理员 02监控人员在线监控人员 03调度人员调度工作人员 04一般工作人员工作人员…… 从该关系表可以看出，用户所拥有的特定资源可以通过用户角色来关联。 1.5权限与角色的关系 一个角色（Role）可以拥有多个权限（Permission），同样一个权限可分配给多个角色。例如：l角色（Role）： RoleID RoleName RoleNote 01系统管理员监控系统维护管理员 02监控人员在线监控人员
(完整版)需求分析+概要设计+详细设计+数据库设计模板
附录A 软件需求分析报告文档 (1) 附录B 软件概要设计报告文档 (13) 附录C 软件详细设计报告文档 (33)
附录A 软件需求分析报告文档 1. 引言.............................................................................................................. 错误!未定义书签。 1.1编写目的 (3) 1.2项目风险 (3) 1.3文档约定 (3) 1.4预期读者和阅读建议 (3) 1.5产品范围 (4) 1.6参考文献 (4) 2. 综合描述 (4) 2.1产品的状况 (4) 2.2产品的功能 (5) 2.3用户类和特性 (5) 2.4运行环境 (5) 2.5设计和实现上的限制 (5) 2.6假设和约束(依赖) (6) 3. 外部接口需求 (6) 3.1用户界面 (6) 3.2硬件接口 (7) 3.3软件接口 (7) 3.4通讯接口 (8) 4. 系统功能需求 (8) 4.1说明和优先级 (8) 4.2激励／响应序列 (9) 4.3输入／输出数据 (9) 5. 其它非功能需求 (9) 5.1性能需求 (9) 5.2安全措施需求 (10) 5.3安全性需求 (10) 5.4软件质量属性 (10) 5.5业务规则 (10) 5.6用户文档 (10) 6. 词汇表 (11) 7. 数据定义 (11) 8. 分析模型 (12) 9. 待定问题列表 (12)
1. 简介 1.1 编写目的 此文档对《点菜系统》做了全面细致的用户需求分析，明确该软件应具有的功能、性能、界面，使系统分析人员、软件开发人员能明确用户的需求，并在此基础上进一步提出概要设计说明书和后续设计与开发。本说明书的预期读者为客户、后续开发人员、测试人员、项目管理人员等。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括： ●正文风格； ●提示方式； ●重要符号； 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括： ●用户； ●开发人员； ●项目经理； ●营销人员； ●测试人员； ●文档编写入员。 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
数据库管理系统需求分析
图书管理系统需求分析文档 1.目的 1）能够存储大量的图书信息，快速有效的进行书籍数据管理，包括： ①图书信息的录入、删除及修改。 ②图书信息的多关键字检索查询。 ③图书的出借、返还和资料统计。 2）能够对一定数量的读者进行相应的信息存储与管理，这其中包括： ①读者信息的登记、删除及修改。 ②读者资料的统计与查询。 3）能够对需要的统计结果提供打印输出。 4）能够提供一定的安全机制，提供数据信息授权访问，防止随意删改，同时提供信息备份的服务。 2.概述 2.1用户需求分析 1）产品功能 登录系统：注册，注销，退出。 管理：用户管理，借阅管理，图书管理。 查询：读者查询，借阅查询，图书查询。 帮助：使用说明，关于。 2）用户角色
3）操作环境 4）设计实现约束 2.2建立需求模型 上图是用例图的建模过程，下面是该系统的用户需求陈述： （1）校图书馆准备开发“图书管理系统”，方便广大师生借阅、浏览： （2）师生需要先注册然后才能借阅图书。用户进行注册时需要输入个人信息，注册成功后，会获得一个由系统提供的标识其身份的标识码。 （3）用户登录进入图书管理系统后，可以通过Web页面查看图书的各种信息，如图书的借阅情况，作者等 （4）用户登录后可以借阅图书，并在系统规定的时间内还书。否则必须缴纳罚款金。用户借阅图书时，系统会注明借阅时间。 （5）图书管理员可以查询图书，查看一些借阅情况，更容易知道哪类图书需求量大，好做到合理的更新增减图书。有用户违规或没按时还书的情况，他们做处理，收罚金。 查询图书可以是用户得知图书更具体的位置以节省时间。 （6）管理员可以对书籍进行操控，注册，修改图书及信息；注册，修改读者信息；进行系统维护。 从上述需求陈述中可以发现以下元素： ①参入者 ·用户 ·管理员 ②基本用例 ●注册 ●登录 ●查询图书
数据库设计
数据库设计 摘要 现代科学技术飞速发展，数据库技术是计算机科学技术发展最快，应用最为广泛的技术之一。数据库技术是信息资源管理最有效的手段。根据一个给定的环境的信息需求、处理需求和应用环境，按照数据库规范化设计方法，遵循规范化理论，考虑数据库及其典型应用系统的开发过程，设计数据模式和应用系统，这就是本文所讨论的数据库设计。 关键词：数据库设计；结构设计；数据模式；概念结构；逻辑结构
一、引言 数据库设计是指对于一个给定的应用环境，构建最优的数据库模式，建立数据库及其应用系统，使之能有效的存储数据，满足各种用户的应用需求。数据库的设计关系到系统运行性能, 必须充分考虑数据的一致性、完整性、安全性、可伸缩性。而每一个数据库都是由多条记录组成的，各条记录之间的关系形成了数据库的模型。基本的数据库模型有：层次、网状和关系等三种。目前应用最为普遍的是关系数据库。 规范化理论定义了关系与关系模式。在关系模式中, 满足特定要求的关系就称之为范式, 由低到高分别为第一范式(1NF), 第二范式(2NF), 第三范式(3NF), 一直到第五范式(5NF)。满足这些规范的数据库是简洁的、结构明晰的, 同时, 不会发生插入( insert) 、删除( delete) 和更新( update) 操作异常。反之, 不仅给数据库的编程人员制造麻烦, 而且很难维护, 极大地浪费数据库资源和性能。在一般的应用数据库的设计中, 达到第三范式就可基本满足数据库的要求。下面将就数据库设计经验和技巧进行探讨。 二、数据库设计的目标及任务 (一)数据库设计的目标 数据库设计的目的即设计目标从根本上来说就是要实现数据的共享和安全存取。一个优秀的数据库设计必须要最终实现用户对于数据共享的具体要求，必须要在满足于用户的数据存取要求的基础上实现对于数据的关联性及优化，必须实现数据的安全性及可移植性，以保证用户数据能够简单的进行移植，必须要实现数据库的可扩容性结构以保证数据库对于用户未来数据要求的兼容性等等。 (二)数据库设计的任务 数据库设计的基本任务是：根据一个单位的信息需求、处理需求和数据库的支撑环境（包括DBMS、操作系统和硬件），设计出数据模式（包括外模式、逻辑（概念）模式和内模式）以及典型的应用程序。对应的，数据库设计的成果也包含两个部分：数据模式和以数据库为基础的应用程序，前者是数据库设计的基本成果，一般要符合数据库设计的目标；后者则是在基本成果上对数据库的具体应用。 三、数据库选择 应根据应用需要选择数据库。一般市场主要流行三大类数据库:大型数据库(Oracle) , 中小型数据库(SQL Server, DB, Informix) , 小型数据库(MySQL Server, Acess)。选用原则有
数据库设计心得体会(精选多篇)
数据库设计心得体会(精选多篇) 跟老板做了两个算是比较大的项目，数据库主体都是我设计的。第一个感觉很失败；第二个现在正在用，虽然总结了第一个的教训，但感觉还是有些遗憾。把这过程中的一些心得记在这里，以便日后用到时来查阅。若以后还有机会再设计数据库——现在倒还有些期待，呵呵，再有新的体会，也全部补充到这里。 1.尽量使用数据冗余。 随着磁盘容量的大幅飙升，这一点已经不会产生什么问题。当然冗余归冗余，不能把数据的关联弄的乱七八糟的。 本科数据库课程中学的知识直接拿来，在实际中会出大问题。满足三级范式的数据库结构会让你面对大量的连表查询，应用程序中会用到大量的数据库访问，既繁琐（烦死你）又使程序运行速度减慢。 2.尽量不要使用varchar(max)类型 这一点主要是用动软代码生成器自动生成代码时，如果varchar 的最大长度指定为max，在自动生成代码时，它无法生成这一最大长度，需要手动补进去。 现在感觉用个varchar(1000)就够了。 3.使用预留字段。 数据库表（尤其是动态表格），在你把所有字段都设计好了之后，再添加几个备注字段和预留字段。 之前我觉得这样做没多大意义，因为预留字段的列名是没有实际意义的。这样程序中使用的时候就会让人费解。但现在觉得还是有必
要的，很有必要的，即便在用到时需要自己十分清楚之前预留的无意义字段现在表示什么意义。不过我的第二个数据库中还是没采用，这也是遗憾之处啊。 个人感觉用note1、note2、r1（r表示reserve）、r2、r3，2个备注字段和3个预留字段就足够了,再多的话就不容易记住哪个字段具体表示什么意义了，容易晕。类型就都用varchar(200)吧。 数据库设计心得体会（2）： 在我看来，数据库课程设计主要的目标是利用课程中学到的数据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高我们综合运用所学知识的能力。 当我们这组决定做大学生就业咨询系统时，我们并没有着手写程序。而是大家一起商量这个系统概述、系统目标、系统需求、业务流程分析、数据流程分析和数据词典。当这些都准备好了之后，我们进行模块的分工。每个人都有自己的模块设计，而且写出来的代码要求可以实现相应模块的功能，得到理想的效果。当每个人都把自己的分工做好了，最后会由一个人把这些全部组合搭建在一起。我们使用的是html和php相互嵌套使用，当一个系统做好了之后，我会好好地把程序都看一遍，理会其中的奥秘。 我所负责的是数据库的备份和还原还有一些界面的实现。还记得自己刚接触html的时候，觉得很感兴趣，所以有一段时间几乎到了
数据库设计关于图书馆管理系统的设计(有完整代码)[1]
（2008/2009学年第2学期第18-19 周）
数据库课程设计任务书 一、目的 1.掌握计算机管理信息系统设计的一般方法，主要包括系统分析、系统设计的组织 和实施。 2.关系型数据库管理系统的编程技术，并能独立完成一般小系统的程序设计、调试 运行等工作。 3.培养把所学知识运用到具体对象，并能求出解决方案的能力。 二、任务（任选其一） A.运用关系型数据库管理系统，实现本院图书馆管理信息系统。具体要求如下： —图书、资料的登记、注销和查询。 —借书证管理，包括申请、注销借书证，查询借书证持有人等。 —借还图书、资料的登记、超期处理，超期拒借等。 —图书、资料查询，借、还图书和资料情况查询。 —图书、资料借阅情况的统计分析，拒此作为图书馆图书、资料订够的依据之一。 （本项不作为基本要求） B.运用关系型数据库管理系统，实现服务电话管理系统 向客户现场派技术人员的服务公司可以用服务电话管理系统跟踪客户、员工、工作 订单、发票、付款等等。 要求： 数据库要存储以下信息： —客户信息 —客户工需单信息 —完成工需单所需人工 —完成工需单所需部件 —部件信息 —付款信息 —雇员信息 完成的功能： —输入/查看客户工需单信息 —输入/查看部件、雇员等其它信息 —付款 —打印发票等
三、结果形式 1．设计报告：含E-R图、数据字典、关系模式、关系实例、查询描述、关系代数、SQL 实现的查询语言及查询结果。 2．上机实现。 四、考核 1．课程设计态度（20分）。 2．递交的书面材料（40分）。 3．上机运行情况（40分）
目录 1.问题描述 (1) 1.1背景 (1) 1.2数据需求 (2) 1.3事物需求 (2) 1.4关系模式 (3) ２.方案图表设计 (3) 2.1E-R图 (3) 2.2数据流程图 (7) 2.3数据字典 (7) 2.4关系图： (9) 3.数据库源代码 (10) 3.1数据库建立 (10) 3.2数据初始化 (12) 4.结果数据处理 (14) 4.1单表查询 (14) 4.2超期处理 (16) 4.3还书操作 (17) 4.4借书操作 (19) 4.5书籍状态 (20) 4.6读者状态 (21) 5.结束语 (22) 5.1课程设计心得 (22) 1.问题描述 1.1背景 随着图书馆规模的不断扩大，图书数量也相应的增加，有关图书的各种信息量也成倍增加，
数据库设计实例需求分析、概念结构、逻辑结构
数据库设计实例分析 一、需求分析实例 现要开发高校图书管理系统。经过可行性分析和初步的需求调查，确定了系统的功能边界，该系统应能完成下面的功能： （1）读者注册。 （2）读者借书。 （3）读者还书。 （4）图书查询。 1、数据流图 顶层数据流图反映了图书管理系统与外界的接口，但未表明数据的加工要求，需要进一步细化。根据前面图书管理系统功能边界的确定，再对图书管理系统顶层数据流图中的处理功能做进一步分解，可分解为读者注册、借书、还书和查询四个子功能，这样就得到了图书管理系统的第0层数据流图 从图书管理系统第0层数据流图中可以看出，在图书管理的不同业务中，借书、还书、查询这几个处理较为复杂，使用到不同的数据较多，因此有必要对其进行更深层次的分析，即构建这些处理的第1层数据流图。下面的图8-7分别给出了借书、还书、查询子功能的第1层数据流图 2、数据字典 数据项 数据项名称：借书证号 别名：卡号 含义说明：惟一标识一个借书证 类型：字符型 长度：20 …… 数据结构 （1）名称：读者类别 含义说明：定义了一个读者类别的有关信息 组成结构：类别代码+类别名称+可借阅数量+借阅天数+超期罚款额 （2）名称：读者 含义说明：定义了一个读者的有关信息 组成结构：姓名+性别+所在部门+读者类型 （3）名称：图书 含义说明：定义了一本图书的有关信息 组成结构：图书编号+图书名称+作者+出版社+价格 ……
数据流 （1）数据流名称：借书单 含义：读者借书时填写的单据 来源：读者 去向：审核借书 数据流量：250份/天 组成：借书证编号+借阅日期+图书编号 （2）数据流名称：还书单 含义：读者还书时填写的单据 来源：读者 去向：审核还书 数据流量：250份/天 组成：借书证编号+还书日期+图书编号 …… 数据存储 （1）数据存储名称：图书信息表 含义说明：存放图书有关信息 组成结构：图书+库存数量 说明：数量用来说明图书在仓库中的存放数 （2）数据存储名称：读者信息表 含义说明：存放读者的注册信息 组成结构：读者+卡号+卡状态+办卡日期 说明：卡状态是指借书证当前被锁定还是正常使用 （3）数据存储名称：借书记录 含义说明：存放读者的借书、还书信息 组成结构：卡号+书号+借书日期+还书日期 说明：要求能立即查询并修改 …… 处理过程 （1）处理过程名称：审核借书证 输入：借书证 输出：认定合格的借书证 加工逻辑：根据读者信息表和读者借书证，如果借书证在读者信息表中存在并且没有被锁定，那么借书证是有效的借书证，否则是无效的借书证。 …… 二、概念结构设计实例 1．标识图书管理系统中的实体和属性 参照数据字典中对数据存储的描述，可初步确定三个实体的属性为： 读者：｛卡号，姓名，性别，部门，类别、办卡日期，卡状态｝ 读者类别：{类别代码，类别名称，可借阅天数、可借阅数量，超期罚款额}
数据库设计说明书_完整版
目录 第一章引言 (1) 1.1编写目的 (1) 1.2背景 (1) 1.3参考资料 (2) 第二章外部设计 (3) 2.1标识符和状态 (3) 2.2命名约定 (3) 2.3设计约定 (3) 第三章结构设计 (4) 3.1概念结构设计 (4) 3.1.1实体和属性的定义 (4) 3.1.2设计局部ER模式 (13) 3.1.3设计全局ER模式 (20) 3.2逻辑结构设计 (21) 3.2.1模式 (21) 3.2.2外模式 (32) 3.3物理结构设计 (32) 第四章运用设计 (34) 4.1数据字典设计 (34) 4.2安全保密设计 (34) 4.3数据库实施 (34) 4.3.1创建数据库 (34) 4.3.2创建表 (34)
第一章引言 1.1编写目的 1、本数据库设计说明书是关于寝室管理系统数据库设计，主要包括数据逻辑结构设计、数据字典以及运行环境、安全设计等。 2、本数据库设计说明书读者：用户、系统设计人员、系统测试人员、系统维护人员。 3、本数据库设计说明书是根据系统需求分析设计所编写的。 4、本系统说明书为开发软件提供了一定基础。 1.2背景 随着科学技术的不断提高，计算机科学日渐成熟，其强大的功能已为人们深刻认识，它已经进入人类社会的各个领域并发挥着越来越重要的作用，然而在计算机应用普及以前我国大部分高校的学生信息管理仅靠人工进行管理和操作，这种管理方式存在着许多缺点，如：效率低，密保性差，另外时间一长，将产生大量的文件和数据，其中有些是冗余或者针对同一目的的数据不相吻合，这对于查找、更新和维护文件等管理工作带来了不少困难，同时也跟不上信息时代高速、快捷的要求，严重影响了消息的传播速度。然而现今学校的规模不断扩大，学生数量急剧增加，有关学生的各种信息也成倍增长，人工管理信息的缺点日渐突出，面对庞大的学生信息量，如何利用现代信息技术使其拥有快捷、高效的适应能力已成为当务之急。正因为如此，学生宿舍管理系统成为了学生管理不可缺少的部分，它的内容对于学校的管理者来说都至关重要，所以学生宿舍管理系统应该能
学习数据库的心得
学习数据库的心得各位读友大家好，此文档由网络收集而来，欢迎您下载，谢谢 篇一：SQL学习心得 SQL数据库学习心得 经过一个学期的数据库课程的学习，我基本上掌握了创建数据库以及对数据库的操作的基础知识。学习了SQL 数据库中的增、删、改、查等功能，数据库这门课涉及到以前的知识不多，是一门从头学起的课程，即使基础不是很好，只要认真听讲、复习功课，还是一门比较容易掌握的课。 正是由于这门课和以前关系不大，很多知识也从未接触过，因此对于这门课的学习方法就是：理论课上认真听老师讲理论知识，上机课上仔细看老师的演示过程、在电脑上按照老师的演示步骤自己做，遇到自己无法做出来的过程（步骤）请教老师或者同学。 在第一章基础篇里：开篇任务一是
对通讯录程序的主要功能做一个简单的介绍，并根据这些功能使用SQL Server2005设计了对应的数据库AddressList及数据表，并建立数据表之间的关系；了解了通讯录程序数据库AddressList包含的三个表以及表的相关属性。由于我在本学期初参加数学建模竞赛，耽误了几节课程，导致任务一的内容不会做。而C#数据库中的内容一环扣一环，后面的任务往往是在前面的任务基础上做的，所以一步跟不上，步步跟不上。在老师讲后面的任务时而我前面的任务既不太会做，又没有做完，导致在学习上很吃力。之后的任务都是在任务一的基础上的延伸，学习数据库的编写、功能等。在学习数据库和数据表创建和修改时，了解到表是建立关系数据库的基本结构，用来存储数据具有已定义的属性，在表的操作过程中，有查看表信息、查看表属性、修改表中的数据、删除表中 的数据及修改表和删除表的操作。
关系数据库设计
目录 一Codd的RDBMS12法则——RDBMS的起源 二关系型数据库设计阶段 三设计原则 四命名规则 数据库设计，一个软件项目成功的基石。很多从业人员都认为，数据库设计其实不那么重要。现实中的情景也相当雷同，开发人员的数量是数据库设计人员的数倍。多数人使用数据库中的一部分，所以也会把数据库设计想的如此简单。其实不然，数据库设计也是门学问。 从笔者的经历看来，笔者更赞成在项目早期由开发者进行数据库设计（后期调优需要DBA）。根据笔者的项目经验，一个精通OOP和ORM的开发者，设计的数据库往往更为合理，更能适应需求的变化，如果追其原因，笔者个人猜测是因为数据库的规范化，与OO的部分思想雷同（如内聚）。而DBA，设计的数据库的优势是能将DBMS的能力发挥到极致，能够使用SQL和DBMS实现很多程序实现的逻辑，与开发者相比，DBA优化过的数据库更为高效和稳定。如标题所示，本文旨在分享一名开发者的数据库设计经验，并不涉及复杂的SQL语句或DBMS使用，因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开发者能有所帮助，也希望读者能帮助笔者查漏补缺。 一 Codd的RDBMS12法则——RDBMS的起源 Edgar Frank Codd（埃德加·弗兰克·科德）被誉为“关系数据库之父”，并因为在数据库管理系统的理论和实践方面的杰出贡献于1981年获图灵奖。在1985年，Codd 博士发布了12条规则，这些规则简明的定义出一个关系型数据库的理念，它们被作为所有关系数据库系统的设计指导性方针。 1. 信息法则关系数据库中的所有信息都用唯一的一种方式表示——表中的值。 2. 保证访问法则依靠表名、主键值和列名的组合，保证能访问每个数据项。 3. 空值的系统化处理支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。 4. 基于关系模型的动态联机目录数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样 的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用 户可以访问的表中。 5. 统一的数据子语言法则一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少 有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规 则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是SQL) 6. 视图更新法则所有理论上可以更新的视图也可以由系统更新。 7. 高级的插入、更新和删除操作把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应 于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视 作集合。 8. 数据的物理独立性不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都 保持着逻辑上的不变性。 9. 数据的逻辑独立性当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑 上的不变性。 10. 数据完整性的独立性专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定 义，而且可以存储在数据目录中，而非程序中。
项目管理-项目需求分析与数据库设计
第3章项目需求分析与数据库设计 3.1 项目开发背景 移动数据库是移动计算环境中的分布式数据库，移动数据库的应用大都嵌入到诸如掌上电脑、PDA、嵌入式设备等移动设备中，故移动数据库有时也称为嵌入式移动数据库。 目前绝大多数行业中数据存储与管理都需要随时随地进行，如果将数据存放在中心服务器数据库中，不便于各项数据操作，这时可以将中心服务器中数据库的部分数据，在联网状态下下载和保存到移动数据库中。这样很多的功能实现就可以在离线情况下直接在移动设备端实施完成，同时大幅度减少了中心服务器的负荷和压力。另外在设备端中对移动数据库的各项数据改变，也可以在网络连通时再传回到服务器上，以便保持服务器端与设备端数据的同步。 根据物流配送行业的特点，目前很多公司从客户商品购买到货物发送到客户手中这一系列业务流程都采用基于嵌入式设备的移动解决方案。工作人员在开始一天的工作时，可以直接通过手持设备查看当天要发送的所有货物信息，例如货物的收件人、收件地址和联系方式，并且可以给出一个最佳的投递路线。除此之外，当货物送达后，客户还可以直接在手持设备上进行电子签名以确认货物的送达，而后工作人员就可以将客户签名和货物送达信息直接通过无线网络传递给中心服务器，避免了一系列的“纸上操作”过程，大大加快了工作效率。 随着3G时代的到来，嵌入式移动数据库的应用会越来越广，利用嵌入式移动设备，当无线网络畅通时，可以利用无线网络获取所需的信息，并将这些重要信息存放到移动数据库中，这样既可以减少中心服务器的负载，又可以随时随地取得资料。当无线网络再次畅通时，我们又可以将移动数据库中的数据改变回传至中心数据库服务器。中心服务器数据库中如果存在新的数据信息，移动数据库也会自动加载这些新信息，确保了移动数据库和中心服务器数据库之间的数据同步。 3.2 项目的需求分析设计 3.2.1 项目业务需求描述 嵌入式软件开发公司对各地物流运输公司进行调研之后，整理出将要实现的移动物流配送系统业务功能，移动物流配送系统面向三类用户：客户服务人员、库房管理人员（包括装车人员）、货物运输人员。 （1）客户服务人员可以利用手持移动设备为客户购买所需商品，建立新的订单，并将新的客户订单信息发往商品所在的物流公司中央数据库服务器。 （2）库房管理人员可以利用手持设备获得中央数据库中有关客户订单的信息，确认客户
数据库需求分析报告
高校学生学籍管理 §１概述 编写说明: 本章描述本软件开发得背景，系统目标，用户得业务情况,以便于需求理解。 §1·１背景 在学籍管理中,需要从大量得日常教学活动中提取相关信息，以反映教学情况．传统得手工操作方式，易发生数据丢失,统计错误,劳动强度高，且速度慢.使用计算机可以高速,快捷地完成以上工作。在计算机联网后，数据在网上传递,可以实现数据共享，避免重复劳动，规范教学管理行为,从而提高了管理效率与水平. §1·２系统目标 学籍管理信息系统以计算机为工具,通过对教务管理所需得信息管理,把管理人员从繁琐得数据计算处理中解脱出来,使其有更多得精力从事教务管理政策得研究实施,教学计划得制定执行与教学质量得监督检查，从而全面提高教学质量。 §１·3 业务模式 本系统就是运行在Ｗin9８、Win2０00、WiｎdｏwsNＴ等操作系统环境下得多台计算机构成得局域网，主要业务流程如下: ·按某学生某学期，学年考试及补考成绩，自动生成该学生就是否升留降级，退学。 ·按某学生在校期间累计补考科目门数与成绩自动生成该学生就是否结业，毕业,授位。 ·按某学生因非成绩原因所引起得学籍变更作自动处理． ·按每学期各年级班学生考试成绩自动生成补考名单,科目。 ·按每学期各年级学生考试成绩自动生成某课程统计分析表。 ·按同一年级学习成绩进行同一课程不同班级间成绩比较。 §2用户需求 编写说明: 此系统专门为高校学籍管理所设置。本节主要描述用户需求得使用范围,功能要求信息采集与各部门得使用权限 §2·１使用范围 按成都信息工程学院全日制学生学籍管理等相关文件完成本科与专科学生学籍状况得系统管理(本科生用学年学分制,专科生用学年制）。 系统中保留五个年级学生得信息，学生毕业一年后信息转储，但随时可以查询，输出. §2·２功能要求 ·学生档案管理: 学生得一般情况,及奖励，处分情况; ·学生成绩管理: 学习成绩,补考成绩; ·学籍处理: 学生留降级处理，休复学处理,退学处理; ·日常教务管理: 日常报表，如通知书,补考通知书等，学生学习成绩得各种分类统计; ·毕业生学籍处理：结业处理,毕业处理，授位处理,学籍卡片等。 §2·3信息采集与各部门得使用权限 每学期考试完毕由各系录入成绩，然后由教务科收集。为了信息得安全与数据得权威性,对于网上信息得使用权限与责任规定如下： 数据收集前得系统权限