如何设计一个数据库才是高性能合理科学的
的软件] 所组成， 个成功的管理系统，是由： 一 个成功的管理系统，是由：[50% 的业务 + 50% 的软件 所组成，而 50% 的成功软件 的程序] 所组成，数据库设计的好坏是一个关键。 又有 [25% 的数据库 + 25% 的程序 所组成，数据库设计的好坏是一个关键。如果把企业的数据比 做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。 做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。 有关数据库设计的材料汗牛充栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那 样，再好的老师也比不过经验的教诲。所以我归纳历年来所走的弯路 及体会，并在网上找了些对数据库设 计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验。精选了其中的 60 个最佳技巧，并把这 些技巧编写成了本文，为了方便索引其内容划分为 5 个部分： 第 1 部分 - 设计数据库之前：这一部分罗列了 12 个基本技巧，包括命名规范和明确业务需求等。 第 2 部分 - 设计数据库表：总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。 第 3 部分 - 选择键：怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键的正确用法，还有何 时以 及如何索引字段以获得最佳性能等。 第 4 部分 - 保证数据完整性：讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。 第 5 部分 - 各种小技巧：不包括在以上 4 个部分中的其他技巧，五花八门，有了它们希望你的数据库开发 工作会更轻松一些。
第 1 部分 - 设计数据库之前
考察现有环境 在 设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库项 目都不是从头开始建立的； 通常， 机构内总会存在用来满足特定需求 的现有系统 （可能没有实现自动计算） 。 显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会 忽略的细微问题。 一般来说，考察现有系统对你绝对有好处。 定义标准的对象命名规范 一 定要定义数据库对象的命名规范。对数据库表来说，从项目一开始就要确定表名是采用复数还是 单数形式。此外还要给表的别名定义简单规则（比方说，如果表名是 一个单词，别名就取单词的前 4 个 字母； 如果表名是两个单词， 就各取两个单词的前两个字母组成 4 个字母长的别名； 如果表的名字由 3 个 单词组成， 你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母， 结果还是组成 4 字母 长的别名，其余依次类推）对工作用表来说，表名可以加上前缀 WORK_ 后面附上采用该表的应用程序 的名字。表内的列[字段]要针对键采用一整套设计规则。比如，如果键是数字类型，你可以用 _N 作为后 缀；如果是字符类型则可以采用 _C 后缀。对列[字段]名应该采用标准的前缀和后缀。再如，假如你的表
里有好多"money"字段，你不妨给每个列[字段]增加一个 _M 后缀。还有，日期列[字段]最好以 D_ 作 为名字打头。 检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊 涂了。假如你坚持统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、 Query 或者 Report 等前缀加以区别。 如 果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象（比如 tbl_Employees） 我在和 SQL Server 打交道的时候还用过 tbl 来索引表， 。 但我用 sp_company （现 在用 sp_feft_）标识存储过程，因为在有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。我 在实现 SQL Server 2000 时用 udf_ （或者类似的标记）标识我编写的函数。 工欲善其事， 工欲善其事，必先利其器 采 用理想的数据库设计工具， 比如： SyBase 公司的 PowerDesign， 她支持 PB、 VB、 Delphe 等 语言，通过 ODBC 可以连接市面上流行的 30 多个数据库，包括 dBase、FoxPro、VFP、SQL Server 等，今后有机会我将着重介绍 PowerDesign 的使用。 获取数据模式资源手册 正在寻求示例模式的人可以阅读 《数据模式资源手册》 一书， 该书由 Len Silverston、 H. Inmon W. 和 Kent Graziano 编写，是一本值得拥有的最佳数据建模图书。该书包括的章节涵盖多种数据领域，比 如人员、机构和工作效能等。 其他的你还可以参考：萨师煊 王珊著 数据库系统概论 畅想未来， 畅想未来，但不可忘了过去的教训 我发现询问用户如何看待未来需求变化非常有用。这样做可以达到两个目的：首先，你可以清楚地 了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有确定的需求 变更时用户将和你一样感到吃惊。 一定要记住过去的经验教训！我们开发人员还应该通过分享自己的体会和经验互相帮助。即使用户 认为他们再也不需要什么支持了，我们也应该对他们进行这方面的教育，我们都曾经面临过这样的时刻" 当初要是这么做了该多好.."。 在物理实践之前进行逻辑设计 在深入物理设计之前要先进行逻辑设计。随着大量的 CASE 工具不断涌现出来，你的设计也可以达 到相当高的逻辑水准，你通常可以从整体上更好地了解数据库设计所需要的方方面面。 了解你的业务 在你百分百地确定系统从客户角度满足其需求之前不要在你的 ER（实体关系）模式中加入哪怕一个 数据表（怎么，你还没有模式？那请你参看技巧 9）。了解你的企业业务可以在以后的开发阶段节约大量 的时间。一旦你明确了业务需求，你就可以自己做出许多决策了。 一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流。采用客户的术语并且向他 们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数。这样你 就可以让你的客户纠正你自己的理解然后做好下一步的 ER 设计。 创建数据字典和 ER 图表 一 定要花点时间创建 ER 图表和数据字典。 其中至少应该包含每个字段的数据类型和在每个表内的 主外键。创建 ER 图表和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。越早 创建越能有助于避免今后面临的可能混乱， 从而可以让任何了解数据库的人都 明确如何从数据库中获得数 据。 有一份诸如 ER 图表等最新文档其重要性如何强调都不过分，这对表明表之间关系很有用，而数据 字典则说明了每个字段的用途以及任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的。 创建模式
一张图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话。模 式有助于提高协作效能，这样在先期的数据库设计中几乎不可能出现大的问题。模式不必弄的很复杂；甚 至可以简单到手写在一张纸上就可以了。只是要保证其上的逻辑关系今后能产生效益。 从输入输出下手 在 定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输 出）以决定为了支持这些输出哪些是必要的表和字段。举个简单的 例子：假如客户需要一个报表按照邮政 编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。 报表技巧 要 了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每 个季度还是每年？如果需要的话还可以考虑创建总结表。系统生成的 主键在报表中很难管理。用户在具有 系统生成主键的表内用副键进行检索往往会返回许多重复数据。 这样的检索性能比较低而且容易引起混乱。 理解客户需求 看 起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）。不 要依赖用户写下来的需求，真正的需求在客户的脑袋里。你要让客户 解释其需求，而且随着开发的继续， 还要经常询问客户保证其需求仍然在开发的目的之中。一个不变的真理是："只有我看见了我才知道我想要 的是什么"必然会导 致大量的返工，因为数据库没有达到客户从来没有写下来的需求标准。而更糟的是你 对他们需求的解释只属于你自己，而且可能是完全错误的。
第 2 部分 - 设计表和字段
检查各种变化 我 在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。比方说，姓氏就是如此（注意 是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存 储客户信息时，我倾向于在单独的一 个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。 采用有意义的字段名 有一回我参加开发过一个项目，其中有从其他程序员那里继承的程序，那个程序员喜欢用屏幕上显 示数据指示用语命名字段，这也不赖，但不幸的是，她还喜欢用一些奇怪的命名法，其命名采用了匈牙利 命名和控制序号的组合形式，比如 cbo1、txt2、txt2_b 等等。 除非你在使用只面向你的缩写字段名的系统，否则请尽可能地把字段描述的清楚些。当然，也别做 过头了，比如 Customer_Shipping_Address_Street_Line_1，虽然很富有说明性，但没人愿意键入 这么长的名字，具体尺度就在你的把握中。 采用前缀命名 如果多个表里有好多同一类型的字段（比如 FirstName），你不妨用特定表的前缀（比如 CusLastName）来帮助你标识字段。 时效性数据应包括"最近更新日期/时间"字段。时间标记对查找数据问题的原因、按日期重新处理/ 重载数据和清除旧数据特别有用。 标准化和数据驱动 数 据的标准化不仅方便了自己而且也方便了其他人。比方说，假如你的用户界面要访问外部数据源 （文件、XML 文档、其他数据库等），你不妨把相应的连接和路径信息存储在用户界面支持表里。还有， 如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状 态等），那么产生工作流的数据 也可以存放在数据库里。预先安排总需要付出努力，但如果这些过程采用数据驱动而非硬编码的方式，那 么策略变更和维护都会方便 得多。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户， 由用户来维护自己的工作流过程。 标准化不能过头
对 那些不熟悉标准化一词（normalization）的人而言，标准化可以保证表内的字段都是最基础的 要素， 而这一措施有助于消除数据库中的数据冗余。 准化有好几种形式， Third Normal Form 标 但 （3NF） 通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，3NF 规定：
? ? ?
表内的每一个值都只能被表达一次。 表内的每一行都应该被唯一的标识（有唯一键）。 表内不应该存储依赖于其他键的非键信息。 遵 守 3NF 标准的数据库具有以下特点：有一组表专门存放通过键连接起来的关联数据。比方说， 某个存放客户及其有关定单的 3NF 数据库就可能有两个表：Customer 和 Order。Order 表不包含定 单关联客户的任何信息，但表内会存放一个键值，该键指向 Customer 表里包含该客户信息的那一行。 更高层次的标准化也有，但更标准是否就一定更好呢？答案是不一定。事实上，对某些项目来说， 甚至就连 3NF 都可能给数据库引入太高的复杂性。 为 了效率的缘故，对表不进行标准化有时也是必要的，这样的例子很多。曾经有个开发餐饮分析软 件的活就是用非标准化表把查询时间从平均 40 秒降低到了两秒左右。虽然我不得不这么做，但我绝不把 数据表的非标准化当作当然的设计理念。而具体的操作不过是一种派生。所以如果表出了问题重新产生非 标 准化的表是完全可能的。 不活跃或者不采用的指示符 增 加一个字段表示所在记录是否在业务中不再活跃挺有用的。不管是客户、员工还是其他什么人， 这样做都能有助于再运行查询的时候过滤活跃或者不活跃状态。 同时 还消除了新用户在采用数据时所面临 的一些问题，比如，某些记录可能不再为他们所用，再删除的时候可以起到一定的防范作用。 使用角色实体定义属于某类别的列[字段 使用角色实体定义属于某类别的列 字段] 字段 在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联 关系，从而可以实现自我文档化。 这 里的含义不是让 PERSON 实体带有 Title 字段，而是说，为什么不用 PERSON 实体和 PERSON_TYPE 实体来描述人员呢？比方说，当 John Smith, Engineer 提升为 John Smith, Director 乃至最后爬到 John Smith, CIO 的高位，而所有你要做的不过是改变两个表 PERSON 和 PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的 PERSON_TYPE 表就包含了所有 PERSON 的可能类型，比如 Associate、Engineer、Director、CIO 或者 CEO 等。 还有个替代办法就是改变 PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个 人所处位置的具体时间。 采用常用实体命名机构数据 组 织数据的最简单办法就是采用常用名字，比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE 等等。当你把这些常用的一般名字组合起来或者创建特定的相应副实体时，你就得到了自己用的 特殊版本。开始的时候采用一般术语的主要原因在于所有的具体用户 都能对抽象事物具体化。 有 了这些抽象表示，你就可以在第 2 级标识中采用自己的特殊名称，比如，PERSON 可能是 Employee、Spouse、Patient、Client、Customer、Vendor 或者 Teacher 等。同样的， ORGANIZATION 也可能是 MyCompany、MyDepartment、Competitor、Hospital、Warehouse、 Government 等。最后 ADDRESS 可以具体为 Site、Location、Home、Work、Client、Vendor、 Corporate 和 FieldOffice 等。 采用一般抽象术语来标识"事物"的类别可以让你在关联数据以满足业务要求方面获得巨大的灵活性， 同时这样做还可以显著降低数据存储所需的冗余量。
用户来自世界各地 在设计用到网络或者具有其他国际特性的数据库时，一定要记住大多数国家都有不同的字段格式， 比如邮政编码等，有些国家，比如新西兰就没有邮政编码一说。 数据重复需要采用分立的数据表 如果你发现自己在重复输入数据，请创建新表和新的关系。 每个表中都应该添加的 3 个有用的字段
? ? ?
dRecordCreationDate，在 VB 下默认是 Now()，而在 SQL Server 下默认为 GETDATE() sRecordCreator，在 SQL Server 下默认为 NOT NULL DEFAULT USER nRecordVersion，记录的版本标记；有助于准确说明记录中出现 null 数据或者丢失数据的原因 对地址和电话采用多个字段 描述街道地址就短短一行记录是不够的。 Address_Line1、 Address_Line2 和 Address_Line3 可 以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类 别。 过分标准化可要小心，这样做可能会导致性能上出现问题。虽然地址和电话表分离通常可以达到最 佳状态，但是如果需要经常访问这类信息，或许在其父表中存放"首选"信息（比如 Customer 等）更为 妥当些。非标准化和加速访问之间的妥协是有一定意义的。 使用多个名称字段 我觉得很吃惊，许多人在数据库里就给 name 留一个字段。我觉得只有刚入门的开发人员才会这么 做，但实际上网上这种做法非常普遍。我建议应该把姓氏和名字当作两个字段来处理，然后在查询的时候 再把他们组合起来。 我最常用的是在同一表中创建一个计算列[字段]， 通过它可以自动地连接标准化后的字段， 这样数据 变动的时候它也跟着变。不过，这样做在采用建模软件时得很机灵才行。总之，采用连接字段的方式可以 有效的隔离用户应用和开发人员界面。 提防大小写混用的对象名和特殊字符 过 去最令我恼火的事情之一就是数据库里有大小写混用的对象名，比如 CustomerData。这一问 题从 Access 到 Oracle 数据库都存在。 我不喜欢采用这种大小写混用的对象命名方法， 结果还不得不手 工修改名字。想想看，这种数据库/应用程序能混到采用更强大数据库的那一天吗？ 采用全部大写而且包 含下划符的名字具有更好的可读性（CUSTOMER_DATA），绝对不要在对象名的字符之间留空格。 小心保留词 要 保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，最近我编写的一个 ODBC 连接程序里有个表，其中就用了 DESC 作为说明字段名。后果可想而知！DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT * 语句倒是能用，但我得到的却是一大堆毫无用 处的信息。 保持字段名和类型的一致性 在 命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在某个表中叫做 "agreement_number"，你就别在另一个表里把名字改 成"ref1"。假如数据类型在一个表里是整数，那 在另一个表里可就别变成字符型了。记住，你干完自己的活了，其他人还要用你的数据库呢。 仔细选择数字类型 在 SQL 中使用 smallint 和 tinyint 类型要特别小心，比如，假如你想看看月销售总额，你的总 额字段类型是 smallint，那么，如果总额超过了 $32,767 你就不能进行计算操作了。 删除标记
在表中包含一个"删除标记"字段， 这样就可以把行标记为删除。 在关系数据库里不要单独删除某一行； 最好采用清除数据程序而且要仔细维护索引整体性。 避免使用触发器 触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用 触发器，你最好集中对它文档化。 包含版本机制 建 议你在数据库中引入版本控制机制来确定使用中的数据库的版本。无论如何你都要实现这一要求。 时间一长，用户的需求总是会改变的。最终可能会要求修改数据库 结构。虽然你可以通过检查新字段或者 索引来确定数据库结构的版本，但我发现把版本信息直接存放到数据库中不更为方便吗？ 给文本字段留足余量 ID 类型的文本字段，比如客户 ID 或定单号等等都应该设置得比一般想象更大，因为时间不长你多 半就会因为要添加额外的字符而难堪不已。比方说，假设你的客户 ID 为 10 位数长。那你应该把数据库 表字段的长度设为 12 或者 13 个字符长。这算浪费空间吗？是有一点，但也没你想象的那么多：一个字 段加长 3 个字符在有 1 百万条记录， 再加上一点索引的情况下才不过让整个数据库多占据 3MB 的空间。 但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。身份证的号码从 15 位 变成 18 位就是最好和最惨痛的例子。 字段]命名技巧 列[字段 命名技巧 字段 我 们发现，假如你给每个表的列[字段]名都采用统一的前缀，那么在编写 SQL 表达式的时候会得 到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列[字段]名同某些 数据库联系起来，不过就连这些工具有 时不也连接错误嘛。举个简单的例子，假设有两个表： Customer 和 Order。Customer 表的前缀是 cu_，所以该表内的子段名如下：cu_name_id、 cu_surname、cu_initials 和 cu_address 等。Order 表的前缀是 or_，所以子段名是： or_order_id、or_cust_name_id、or_quantity 和 or_description 等。 这样从数据库中选出全部数据的 SQL 语句可以写成如下所示： Select * From Customer, Order Where cu_surname = "MYNAME" ;and cu_name_id = or_cust_name_id and or_quantity = 1 在没有这些前缀的情况下则写成这个样子（用别名来区分）： Select * From Customer, Order Where Customer.surname = "MYNAME" ;and https://www.doczj.com/doc/a812115321.html,_id = Order.cust_name_id and Order.quantity = 1 第 1 个 SQL 语句没少键入多少字符。但如果查询涉及到 5 个表乃至更多的列[字段]你就知道这 个技巧多有用了。
第 3 部分 - 选择键和索引
数据采掘要预先计划 我 所在的某一客户部门一度要处理 8 万多份联系方式，同时填写每个客户的必要数据（这绝对不 是小活） 我从中还要确定出一组客户作为市场目标。 。 当我从最开始设计表和字段的时候， 我试图不在主 索 引里增加太多的字段以便加快数据库的运行速度。然后我意识到特定的组查询和信息采掘既不准确速度也 不快。结果只好在主索引中重建而且合并了数据字段。我 发现有一个指示计划相当关键--当我想创建系统
类型查找时为什么要采用号码作为主索引字段呢？我可以用传真号码进行检索，但是它几乎就象系统类型 一样对我 来说并不重要。采用后者作为主字段，数据库更新后重新索引和检索就快多了。 可 操作数据仓库（ODS）和数据仓库（DW）这两种环境下的数据索引是有差别的。在 DW 环境 下，你要考虑销售部门是如何组织销售活动的。他们并不是数据库管理员，但是他们确定表内的键信息。 这里设计人员或者数据库工作人员应该分析数据库结构 从而确定出性能和正确输出之间的最佳条件。 使用系统生成的主键 这类同技巧 1，但我觉得有必要在这里重复提醒大家。假如你总是在设计数据库的时候采用系统生 成的键作为主键，那么你实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对 存储数据中每一行的访问。 采用系统生成键作为主键还有一个优点：当你拥有一致的键结构时，找到逻辑缺陷很容易。 分解字段用于索引 为 了分离命名字段和包含字段以支持用户定义的报表，请考虑分解其他字段（甚至主键）为其组成 要素以便用户可以对其进行索引。索引将加快 SQL 和报表生成器脚本的执行速度。比方说，我通常在必 须使用 SQL LIKE 表达式的情况下创建报表，因为 case number 字段无法分解为 year、serial number、case type 和 defendant code 等要素。性能也会变坏。假如年度和类型字段可以分解为索 引字段那么这些报表运行起来就会快多了。 键设计 4 原则
? ? ? ?
为关联字段创建外键。 所有的键都必须唯一。 避免使用复合键。 外键总是关联唯一的键字段。 别忘了索引 索 引是从数据库中获取数据的最高效方式之一。95% 的数据库性能问题都可以采用索引技术得到 解决。作为一条规则，我通常对逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非 成组索引，对任 何外键列[字段]采用非成组索引。不过，索引就象是盐，太多了菜就咸了。你得考虑数据 库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如 运行查询显示主表和所有关联表的某条记录就用得上。还有，不要索引 memo/note 字段，不要索引大 型字段（有很多字符），这样作会让索引占用太多的存储空间。 不要索引常用的小型表 不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删 除操作的索引维护可能比扫描表空间消耗更多的时间。 不要把社会保障号码（ 不要把社会保障号码（SSN）或身份证号码（ID）选作键 ）或身份证号码（ ） 永 远都不要使用 SSN 或 ID 作为数据库的键。除了隐私原因以外，须知政府越来越趋向于不准许 把 SSN 或 ID 用作除收入相关以外的其他目的，SSN 或 ID 需要手工输入。永远不要使用手工输入的 键作为主键，因为一旦你输入错误，你唯一能做的就是删除整个记录然后从头开始。 我在破解他人的程序时候，我看到很多人把 SSN 或 ID 还曾被用做系列号，当然尽管这么做是非 法的。而且人们也都知道这是非法的，但他们已经习惯了。后来，随着盗取身份犯罪案件的增加，我现在 的同行正痛苦地从一大摊子数据中把 SSN 或 ID 删除。 不要用用户的键
在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选 择用户可编辑的字段作为键。这样做会迫使你采取以下两个措施：
?
在 创建记录之后对用户编辑字段的行为施加限制。假如你这么做了，你可能会发现你的应用程序在商务需 求突然发生变化，而用户需要编辑那些不可编辑的字段时缺乏 足够的灵活性。当用户在输入数据之后直到 保存记录才发现系统出了问题他们该怎么想？删除重建？假如记录不可重建是否让用户走开？
?
提出一些检测和纠正键冲突的方法。通常，费点精力也就搞定了，但是从性能上来看这样做的代价就比较 大了。还有，键的纠正可能会迫使你突破你的数据和商业/用户界面层之间的隔离。 所以还是重提一句老话：你的设计要适应用户而不是让用户来适应你的设计。 不 让主键具有可更新性的原因是在关系模式下， 主键实现了不同表之间的关联。 比如， Customer 表 有一个主键 CustomerID，而客户的定单则存放在另一个表里。Order 表的主键可能是 OrderNo 或者 OrderNo、CustomerID 和日期的组合。不管你选择哪种键设置，你都需要在 Order 表中存放 CustomerID 来保证你可以给下定单的用户找到其定单记录。 假如你在 Customer 表里修改了 CustomerID，那么你必须找出 Order 表中的所有相关记录对 其进行修改。否则，有些定单就会不属于任何客户--数据库的完整性就算完蛋了。 如果索引完整性规则施加到表一级，那么在不编写大量代码和附加删除记录的情况下几乎不可能改 变某一条记录的键和数据库内所有关联的记录。而这一过程往往错误丛生所以应该尽量避免。 可选键(候选键 有时可做主键 可选键 候选键)有时可做主键 候选键 记住，查询数据的不是机器而是人。 假如你有可选键，你可能进一步把它用做主键。那样的话，你就拥有了建立强大索引的能力。这样 可以阻止使用数据库的人不得不连接数据库从而恰当的过滤数据。在严格控制域表的数据库上，这种负载 是比较醒目的。如果可选键真正有用，那就是达到了主键的水准。 我的看法是，假如你有可选键，比如国家表内的 state_code，你不要在现有不能变动的唯一键上 创建后续的键。你要做的无非是创建毫无价值的数据。如你因为过度使用表的后续键[别名]建立这种表的 关联，操作负载真得需要考虑一下了。 别忘了外键 大多数数据库索引自动创建的主键字段。但别忘了索引外键字段，它们在你想查询主表中的记录及 其关联记录时每次都会用到。 还有， 不要索引 memo/notes 字段而且不要索引大型文本字段 （许多字符） ， 这样做会让你的索引占据大量的数据库空间。
第 4 部分 - 保证数据的完整性
用约束而非商务规则强制数据完整性
如 果你按照商务规则来处理需求， 那么你应当检查商务层次/用户界面： 如果商务规则以后发生变化， 那么只需要进行更新即可。 假如需求源于维护数据完整性的需 要， 那么在数据库层面上需要施加限制条件。 如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通 知用户界面。 除非你的字段命名很冗长，否则字段名本身还不够。 只要有可能，请采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包 括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完 整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。
分布式数据系统
对 分布式系统而言，在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估 计一下未来 5 年或者 10 年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段中设置一 些标记。在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输，请写下 你自己的批处理或 者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据，比如计 算常数和利息率等，设置版本号保证数据 在每个站点都完全一致。
强制指示完整性(参照完整性 强制指示完整性 参照完整性?) 参照完整性
没有好办法能在有害数据进入数据库之后消除它，所以你应该在它进入数据库之前将其剔除。激活 数据库系统的指示完整性特性。 这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。 如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成 多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。
采用视图
为了在你的数据库和你的应用程序代码之间提供另一层抽象，你可以为你的应用程序建立专门的视 图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
给数据保有和恢复制定计划
考虑数据保有策略并包含在设计过程中，预先设计你的数据恢复过程。采用可以发布给用户/开发人 员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来"更新查询"供以后万一数据 丢失可以重新处理更新。
用存储过程让系统做重活
解决了许多麻烦来产生一个具有高度完整性的数据库解决方案之后，我决定封装一些关联表的功能 组，提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是一个 存放数据的地方，它也是简化编码之地。
使用查找
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列 表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国 家代码、状态代码等。
第 5 部分 - 各种小技巧
文档、文档、 文档、文档、文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。 采用给表、列[字段]、触发器等加注释的数据库工具。是的，这有点费事，但从长远来看，这样做对 开发、支持和跟踪修改非常有用。 取 决于你使用的数据库系统，可能有一些软件会给你一些供你很快上手的文档。你可能希望先开始 在说，然后获得越来越多的细节。或者你可能希望周期性的预排，在 输入新数据同时随着你的进展对每一 部分细节化。不管你选择哪种方式，总要对你的数据库文档化，或者在数据库自身的内部或者单独建立文 档。这样，当你过了一 年多时间后再回过头来做第 2 个版本，你犯错的机会将大大减少。
使用常用英语（或者其他任何语言） 使用常用英语（或者其他任何语言）而不要使用编码
为 什么我们经常采用编码（比如 9935A 可能是'青岛啤酒'的供应代码，4XF788-Q 可能是帐目编 码）？理由很多。但是用户通常都用英语进行思考而不是编码。工作 5 年的会计或许知道 4XF788-Q 是 什么东西，但新来的可就不一定了。在创建下拉菜单、列表、报表时最好按照英语名排序。假如你需要编 码，那你可以在编码旁附上用户知道的英语。
保存常用信息
让 一个表专门存放一般数据库信息非常有用。 我常在这个表里存放数据库当前版本、 最近检查/修复 （对 FoxPro）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱 怨他们的数据库没有达到希望的要求而与你联系时，这样做 对非客户机/服务器环境特别有用。
测试、测试、 测试、测试、反复测试
建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试 并且同用户一道保证你选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针 对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。
数据库设计心得体会(精选多篇) 跟老板做了两个算是比较大的项目，数据库主体都是我设计的。第一个感觉很失败；第二个现在正在用，虽然总结了第一个的教训，但感觉还是有些遗憾。把这过程中的一些心得记在这里，以便日后用到时来查阅。若以后还有机会再设计数据库——现在倒还有些期待，呵呵，再有新的体会，也全部补充到这里。 1.尽量使用数据冗余。 随着磁盘容量的大幅飙升，这一点已经不会产生什么问题。当然冗余归冗余，不能把数据的关联弄的乱七八糟的。 本科数据库课程中学的知识直接拿来，在实际中会出大问题。满足三级范式的数据库结构会让你面对大量的连表查询，应用程序中会用到大量的数据库访问，既繁琐（烦死你）又使程序运行速度减慢。 2.尽量不要使用varchar(max)类型 这一点主要是用动软代码生成器自动生成代码时，如果varchar 的最大长度指定为max，在自动生成代码时，它无法生成这一最大长度，需要手动补进去。 现在感觉用个varchar(1000)就够了。 3.使用预留字段。 数据库表（尤其是动态表格），在你把所有字段都设计好了之后，再添加几个备注字段和预留字段。 之前我觉得这样做没多大意义，因为预留字段的列名是没有实际意义的。这样程序中使用的时候就会让人费解。但现在觉得还是有必
要的，很有必要的，即便在用到时需要自己十分清楚之前预留的无意义字段现在表示什么意义。不过我的第二个数据库中还是没采用，这也是遗憾之处啊。 个人感觉用note1、note2、r1（r表示reserve）、r2、r3，2个备注字段和3个预留字段就足够了,再多的话就不容易记住哪个字段具体表示什么意义了，容易晕。类型就都用varchar(200)吧。 数据库设计心得体会（2）： 在我看来，数据库课程设计主要的目标是利用课程中学到的数据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高我们综合运用所学知识的能力。 当我们这组决定做大学生就业咨询系统时，我们并没有着手写程序。而是大家一起商量这个系统概述、系统目标、系统需求、业务流程分析、数据流程分析和数据词典。当这些都准备好了之后，我们进行模块的分工。每个人都有自己的模块设计，而且写出来的代码要求可以实现相应模块的功能，得到理想的效果。当每个人都把自己的分工做好了，最后会由一个人把这些全部组合搭建在一起。我们使用的是html和php相互嵌套使用，当一个系统做好了之后，我会好好地把程序都看一遍，理会其中的奥秘。 我所负责的是数据库的备份和还原还有一些界面的实现。还记得自己刚接触html的时候，觉得很感兴趣，所以有一段时间几乎到了
目录 第一章：项目计划 (2) 1.1项目背景: (2) 1.2系统开发目的： (2) 1.3定义： (2) 第二章：详细分析 (2) 2.1、系统功能 (2) 2.2、系统结构 (3) 2.3、数据流图 (3) 2.4、户类型与职能 (4) 2.5、系统环境需求 (5) 第三章：系统概念设计 (5) 第四章：逻辑设计 (6) 4.1系统关系模型 (6) 4.2系统数据库表结构 (6) 第五章：源码 (9) 第六章：小结 (14)
第一章：项目计划 1.1项目背景: 教务系统管理平台充分利用互联网络B/S管理系统模式，以网络为平台，为各个学校教务系统的管理提供一个平台，帮助学校管理教务系统，用一个账号解决学校教务教学管理，并且学校可以自由选择学校需要的教务管理系统，灵活地定制符合学校自己实际情况的教务系统. 1.2系统开发目的： 提高学生，老师管理和操作事务的运作效率。 1.3定义： 学生选课和老师评分必须在管理员的设置条件下进行。 第二章：详细分析 2.1、系统功能 设置学期时间：管理员登录系统后设置学期的时间，只有当时间为某个状态时，其他角色例如老师，才能做某些事情。学期时间只能由角色管理员操作：包括对学期时间表的增加，删除，对某个学期时间状态的改变。 学生选课：当管理员设置为学期开始时，学生可以选课，学生选课受学分影
响，只能选择总学分为多少的课程。 老师评分：当管理员设置为学期评分时，老师才可以评分。 个人信息管理：对自己个人信息进行添加和修改。 成绩查询：学生可以对自己成绩进行查询。 个人课表查询：按时间的不同，每个角色都有自己不同的课表。 2.2、系统结构 功能描述：学生选课和老师评分必须在管理员设置学期的条件下进行。 2.3、数据流图 顶层图
数据库管理系统的设计与实现 1.DBMS的目标 （1）用户界面友好对一个实用DBMS来说，用户界面的质量直接影响其生命力。DBMS的用户接口应面向应用，采用适合最终用户的交互式、表格式、菜单式、窗口式等界面形式，以方便使用和保持灵活性。一般地说，用户界面应具有可靠性、简单性、灵活性和立即反馈等特性。 （2）功能完备DBMS功能随系统的规模的大小而异。大型DBMS功能齐全，小型DBMS功能弱一些。DBMS主要功能包括数据定义、数据库数据存取、事务控制、数据库组织和存储管理、数据库安全保护等等。我们在下面讨论这些功能的内容。 （3）效率高系统效率包括三个方面:一是计算机系统内部资源的使用效率。能充分利用资源（包括存储空间、设备、CPU等），并注意使各种资源负载均衡以提高整个系统的效率，二是DBMS本身的运行效率。三是用户的生产率。这是指用户学习、使用DBMS和在DBMS基础上开发的应用系统的效率。 2.DBMS的基本功能 （1）数据库定义对数据库的结构进行描述，包括外模式、模式、内模式的定义;数据库完整性的定义;安全保密定义（如用户口令、级别、存取权限）;存取路径（如索引）的定义。这些定义存储在数据
字典（亦称为系统目录）中，是DBMS运行的基本依据。为此，提供数据定义语言DDL。 （2）数据存取提供用户对数据的操纵功能，实现对数据库数据的检索、插入、修改和删除。一个好的DBMS应该提供功能强易学易用的数据操纵语言（DML）、方便的操作方式和较高的数据存取效率。DML有两类:一类是宿主型语言，一类是自含型语言。前者的语句不能独立使用而必须嵌入某种主语言，如C语言、COBOL语言中使用。而后者可以独立使用，通常以供终端用户交互使用和批处理方式两种形式使用。 （3）数据库运行管理这是指DBMS运行控制、管理功能。包括多用户环境下的并发控制、安全性检查和存取权限控制、完整性检查和执行、数据加密、运行日志的组织管理、事务的管理和自动恢复（保证事务的正确性），这些功能保证了数据库系统的正常运行。 （4）数据组织、存储和管理DBMS要分门别类地组织、存储各类数据，包括数据字典（亦称系统目录）、用户数据、存取路径等等。要确定以何种文件结构和存取方式在存储级上组织这些数据，如何实现数据之间的联系。数据组织和存储的基本目标是提高存储空间利用率，选择合适的存取方法确保较高存取（如随机查找、顺序查找、增、删、改）效率。 （5）数据库的建立和维护包括数据库的初始建立、数据的转换、数据库的转储和恢复、数据库的重组织和重构造以及有性能监测分析等功能。
卷号：0001 卷内编号：2008-0430 上海红门智能系统有限公司 智能一卡通系统 数据库设计报告 文件状态：[√] 草稿[ ] 正式发布[ ] 正在修改文件标识：https://www.doczj.com/doc/a812115321.html,-SD-DATABASE 当前版本： 1.0.0 作者：吕瑞锋 完成日期：2008-04-30
版本历史
目录 0. 文档介绍 (4) 0.1文档目的 (4) 0.2文档范围 (4) 0.3读者对象 (4) 0.4参考文献 (4) 0.5术语与缩写解释 (4) 1. 数据库环境说明 (6) 2. 数据库的命名规则 (6) 3. 逻辑设计 (6) 4. 物理设计 (6) 4.0表汇总 (7) 4.1表A (10) 4.N 表N (11) 5. 安全性设计 (42) 5.1防止用户直接操作数据库的方法 (43) 5.2用户帐号密码的加密方法 (43) 5.3角色与权限 (43) 6. 优化 (43) 7. 数据库管理与维护说明 (44)
0. 文档介绍 0.1 文档目的 本说明书是一本针对数据库开发者，程序设计员的设计使用说明书，便于指导数据库的后续开发和数据库的扩展，同时为前台的客户端设计提供数据库的结构说明。 0.2 文档范围 0.3 读者对象 0.4 参考文献 提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：[标识符] 作者，文献名称，出版单位（或归属单位），日期 例如： [AAA]作者，《立项建议书》，机构名称，日期 [SPP-PROC-SD] SEPG，系统设计规范，机构名称，日期 SQL Server 编程技术内幕------------------ （美）John Papa , Matthew SQL Server 网络数据库指南--------------------- （美）Paul DuBois
汽车租赁系统 一、课程设计的目的和意义 随着汽车租赁领域的繁荣和飞速发展，租车行业的信息量越来越大，越来越复杂。传统的管理方式无法适应当前迅速发展的市场，计算机和计算机网络技术迅速发展和普及，使用汽车租赁系统可以使得汽车租赁的效率得到很大的提高，同时降低经营成本，提高利润。 应用对数据库原理的理论学习，通过实践熟练掌握数据库创建、基本操作、程序系统的建立。并通过数据库原理软件设计实践，巩固在课堂教学中学习的关于数据库原理的有关知识和数据库系统建立的方法，熟练掌握对于实际问题，为了建立一个关系数据库信息管理系统，必须得经过需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施以及数据库运行和维护的一般过程，为毕业设计打下基础。 二、术语定义 E-R图：为理解和表示问题域的信息而建立的数据模型，简称E-R图。具有实体、关系、属性三要素。 数据流图：数据流图是用来描绘软件系统逻辑模型的图形工具，是描绘信息在系统中流动和处理的情况的。 数据字典：数据字典是对数据流图中出现的所有数据元素、数据流、文件、处理的定义的集合。 三、数据库的要求 主要功能：本系统包括客户信息管理、车辆信息管理、汽车租赁归还管理、会员类型管理、会员信息管理、保险公司管理、汽车经销商管理等。具有添加、修改、查询、删除等功能。方便租赁公司的工作，提高租赁公司的工作质量和工作效率。 性能要求：租借和归还信息必须及时更新，汽车租赁系统的信息必须无差错的存储在主服务器上。 输出要求：数据完整，详实。 输出要求：简捷，快速，实时、准确。 安全与要求：管理员享有对客户信息库及汽车租借信息库和职员信息库的管理与修改。工作人员只享有对汽车租赁信息库的部分修改（写入与读出）。 完成期限：预计三个月 一、汽车租赁系统需求分析： 系统功能需求： 1）客户可以通过不同的方式（包括、前台、网上）预订车辆 1、能够保存客户的预订申请单 2、能够保存客户的历史记录 3、工作人员可以处理申请 4、技术人员可以保存对车辆检修的结构 2）满足以上功能需要以下几个模块： 1、基本数据维护模块。基本数据维护模块提供了使用者录入、修改并维护基本数据的途径。 例如对客户的个人信息、租赁信息、车辆的基本信息等的录入和修改 2、基本业务模块。基本业务模块中，客户可以填写汽车租赁申请表，工作人员负责处理这 些表格。同时，技术人员可以提交每辆车的状态，以便工作人员根据这些资料决定是否
摘要 数据库原理及应用课程设计是软件工程专业集中实践性环节之一，是学习完《数据库原理及应用》课程后进行的一次全面的综合练习。其目的在于加深对数据库基础理论和基本知识的理解，掌握使用数据库进行软件设计的基本方法，提高运用数据库解决实际问题的能力，最终实现对于给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求(信息要求和处理要求)。 数据库及其应用系统是具有管理功能的计算机系统，而数据库原理及应用课程设计在开发应用程序中至关重要，合理的数据表结构不尽有利于软件的快速开发，而且有利于以后对软件的维护。 目前，我国的科技水平高速发展，计算机作为今天使用最广的现代化工具已深入到各个领域，并且正在成为未来社会——信息社会的重要支柱。在这样的大背景下，现代图书馆的管理方式，资源建设等方面都发生了重大变化，这种变化表现在图书馆工作，管理和服务平台发生的变化，图书馆不再是传统的手工操作，人工管理，而是全面实行计算机管理。 一个简单的图书管理系统包括图书馆内书籍的信息、学校在校学生的信息以及学生的借阅信息。系统在IBMDB2平台上用SQL语言来编写实现。此系统功能分为面向学生和面向管理员两部分，其中学生可以进行借阅、续借、归还和查询书籍等操作，管理员可以完成书籍和学生的增加，删除和修改以及对学生，借阅、续借、归还的确认。 关键词：SQL语言；数据库设计；图书管理系统
目录 1需求分析．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．1 1.1需求分析过程．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．1 1.2数据字典．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．2 2概念模式设计．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．3 2.1实体．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．3 2.2 局部视图．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．3 2.3视图集成．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．4 3逻辑模式设计．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．6 3.1将E-R图转化为关系模式．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．6 3.2数据模型的优化．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．6 4检验是否满足用户需求．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．8 4.1调查用户需求．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．8 5其它数据库对象(物理数据库设计)的考虑．．．．．．．．．．．．．．．．．．．．．．．．．．．．9 5.1建表．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．9 5.2合法用户名字、权限、角色．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．10 5.3视图．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．10 5.4触发器．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．11 5.5索引．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．11 6备份及恢复策略．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．11 6.1备份策略．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．11 6.2恢复策略．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．11
四六级英语考试网上报名系统 数据库设计报告 文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改文件标识：Company-Project-SD-DATABASE 当前版本： 1.0 作者：俞乔丹 完成日期：2019/4/20
版本历史 版本/状态作者参与者起止日期备注1.0俞乔丹俞乔丹2019/4/15-2019/4/20初步定稿
目录 0. 文档介绍 (4) 0.1文档目的 (4) 0.2文档范围 (4) 0.3读者对象 (4) 0.4参考文献 (4) 0.5术语与缩写解释 (4) 1. 数据库环境说明 (5) 2. 数据库的命名规则 (5) 3. 逻辑设计 (5) 4. 物理设计 (5) 4.0表汇总 (5) 4.1表A (6) 4.N 表N (6) 5. 安全性设计 (6) 5.1防止用户直接操作数据库的方法 (6) 5.2用户帐号密码的加密方法 (6) 5.3角色与权限 (7) 6. 优化 (7) 7. 数据库管理与维护说明 (7)
0. 文档介绍 0.1 文档目的 数据库设计文档的编写是为了研究四六级英语考试网上报名系统的开发途径和应用 方法。同时它也是进行项目策划，概要设计和详细设计的基础，是维护人员进行内部维 护，信息更新，验收和测试的依据。本说明书的预期读者是于该系统开发有联系的决策 人。支持本项目的领导和公司员工，软件测试人员。 0.2 文档范围 本文档适用于项目开发的设计阶段，在项目开发阶段可以按照本文档检验数据库实施情 况。 0.3 读者对象 开发人员，用户，测试人员，后期修改人员。 0.4 参考文献 [C#+sql Server中小型信息系统开发实例精选] 黄明，机械工业出版社.2007.4 [C#专业项目实例开发] Arora，中国水利水电出版社,2007 [数据库原理及应用] 王雯，北京机械工业出版社2009.11 [数据库基础与实践技术] 何玉洁，,机械工业出版社.2013.3 [C#数据库系统开发完全手册] 王小科，人们邮电出版社，2006.12 0.5 术语与缩写解释 缩写、术语解释 SPP精简并行过程，Simplified Parallel Process SD系统设计，System Design
会议管理系统数据库计说明书 编写：匿名日期：2013-7-31 审核：日期： 批准：日期： 受控状态：是 发布版次：5.0 日期：2013-7-31 编号：
变更记录 日期版本变更说明作者2013-7-17 1.0 初始文档匿名2013-7-25 2.0 升级文档匿名2013-7-29 3.0 升级文档匿名2013-7-30 4.0 升级文档匿名2013-7-31 5.0 最终文档匿名 签字确认 职务姓名签字日期
目录 1引言 (4) 1.1预期的读者 (4) 1.2数据库说明 (4) 1.3目的和作用 (4) 2数据库设计 (4) 2.1抽象数据对象 (4) 2.1.1系统主要业务分析 (4) 2.1.2需求分析参考 (5) 2.2系统物理结构设计 (5) 2.3数据库逻辑设计 (5) 2.3.1数据库设计命名规范 (6) 2.3.2数据库表名汇总 (7) 2.3.3数据库表结构设计 (7) 2.4存储过程设计 (12) 2.5触发器设计 (12) 2.6J OB设计 (12) 3数据字典设计 (13)
1 引言 1.1 预期的读者 主要为本公司以及承包方的阅读者，如设计人员、开发人员等。有时可以包括客户方的阅读者,如：业务人员、系统管理人员等。 1.2 数据库说明 会议管理系统采用的时当前流行的企业级数据库oracle，使用的版本是9i。设计的数据库全局数据库名为icss，开发用的表空间名是test，操作的用户名为test，密码为test。 1.3 目的和作用 将业务分析，系统设计中对信息的描述进一步分析并加以总计，抽象出数据集合（数据库表）。对数据集合做进一步分析，确定集合之间的关系并最终形成数据库物理模型，以便开发人员建立物理数据库。 2 数据库设计 2.1 抽象数据对象 2.1.1 系统主要业务分析 根据物流系统的业务流程描述，我们大致可以从中抽象出几个数据集合，如：普通用户、会议申请、会议室管理、设备管理、会议管理 按照业务及系统功能简单总结数据对象： ●用户 ●会议申请信息 ●会议审批 ●会议设备
1.1、功能特点 ?前台基本功能 进货管理:进行商品采购入库,采购退货,进/退单据和当前库存查询,与供货商的往来帐务。 销售管理:进行商品销售,顾客退货,销/退单据和当前库存查询,POS 销售统计,与客户的往来帐务。 库存管理:包括库存之间商品调拔,商品的报损溢,强大的库存盘点功能,库存商品报警查询。 统计报表:完整的统计查询功能，每张单据每次收款付款都可以清楚的反映。 日常管理:对供货商,客户,业务员综合管理,对日常收入支出管理,客户借货坏帐管理,合同管理。 基本设置:商品信息,商品调价,供货商,客户,员工,会员,仓库等基本参数的设置。 系统维护:数据库备份/恢复,系统初始化,操作员修改密码,年终结算,查看日志,打印条码,赠品管理。 ?后台基本功能 商品销售:进行商品的销售工作,用户可以通过输入商品的条码,编号来选择商品。 销售退货:进行已销售商品的顾客退货工作,同样可以通过商品条码和编号来选择商品。 打印设置:设置小票的标题和脚注以及要选择的打印机。 兑换赠品:有关会员用积分兑换赠品的管理工作。 赠送赠品:有关赠品的赠送管理工作。 修改密码:修改当前收银员的密码。 快捷键设置:设置 POS 中各功能的快捷键。 出入款管理:管理有关收银员的出入款工作。 1.2、系统要求 1、计算机硬件在586等级以上. 2、软件要求操作系统为中文WIN98,WIN2000,WINXP.WIN2003 3、装有microsoft数据库驱动程序 4、屏幕分辨率800X600以上.
二、快速入门
后台主界面及功能说明： 图1 2.1、基本设置：在基本设置中可以对商品信息、商品调价、供货商、客户、员工、操作员、会员、仓库进行设置 2.1.1、商品信息 在基本设置模块中点击“商品信息”进入商品信息界面如图2
四六级英语考试网上报名系统数据库设计报告
版本历史
目录 0. 文档介绍 (4) 0.1文档目的 (4) 0.2文档范围 (4) 0.3读者对象 (4) 0.4参考文献 (4) 0.5术语与缩写解释 (4) 1. 数据库环境说明 (5) 2. 数据库的命名规则 (5) 3. 逻辑设计 (5) 4. 物理设计 (5) 4.0表汇总 (5) 4.1表A (6) 4.N 表N (6) 5. 安全性设计 (6) 5.1防止用户直接操作数据库的方法 (6) 5.2用户帐号密码的加密方法 (6) 5.3角色与权限 (7) 6. 优化 (7) 7. 数据库管理与维护说明 (7)
0. 文档介绍 0.1 文档目的 数据库设计文档的编写是为了研究四六级英语考试网上报名系统的开发途径和应用方法。同时它也是进行项目策划，概要设计和详细设计的基础，是维护人员进行内部维护，信息更新，验收和测试的依据。本说明书的预期读者是于该系统开发有联系的决策人。支持本项目的领导和公司员工，软件测试人员。 0.2 文档范围 本文档适用于项目开发的设计阶段，在项目开发阶段可以按照本文档检验数据库实施情况。 0.3 读者对象 开发人员，用户，测试人员，后期修改人员。 0.4 参考文献 [C#+sql Server中小型信息系统开发实例精选] 黄明，机械工业出版社.2007.4 [C#专业项目实例开发] Arora，中国水利水电出版社,2007 [数据库原理及应用] 王雯，北京机械工业出版社2009.11 [数据库基础与实践技术] 何玉洁，,机械工业出版社.2013.3 [C#数据库系统开发完全手册] 王小科，人们邮电出版社，2006.12 0.5 术语与缩写解释
目录 第一章引言 (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背景 随着科学技术的不断提高，计算机科学日渐成熟，其强大的功能已为人们深刻认识，它已经进入人类社会的各个领域并发挥着越来越重要的作用，然而在计算机应用普及以前我国大部分高校的学生信息管理仅靠人工进行管理和操作，这种管理方式存在着许多缺点，如：效率低，密保性差，另外时间一长，将产生大量的文件和数据，其中有些是冗余或者针对同一目的的数据不相吻合，这对于查找、更新和维护文件等管理工作带来了不少困难，同时也跟不上信息时代高速、快捷的要求，严重影响了消息的传播速度。然而现今学校的规模不断扩大，学生数量急剧增加，有关学生的各种信息也成倍增长，人工管理信息的缺点日渐突出，面对庞大的学生信息量，如何利用现代信息技术使其拥有快捷、高效的适应能力已成为当务之急。正因为如此，学生宿舍管理系统成为了学生管理不可缺少的部分，它的内容对于学校的管理者来说都至关重要，所以学生宿舍管理系统应该能
仓库管理系统数据库设计 1概述（设计题目与可行性分析） 1.1设计题目 设计一个仓库数据库管理系统，要求实现入库、出库、库存和采购等功能。 随着经济的飞速发展，，仓库管理变成了各大公司日益重要的内容。仓库管理过程的准确性和高效性至关重要。影响着公司的经济发展和管理。利用人工管理强大而数据烦琐的数据库显的效率过于低。利用计算机高效、准确的特点能够很好的满足公司的管理需要。提高公司各个员工的工作效率和公司的运做效率。利用计算机对仓库数据信息进行管理具有着手工管理所无法比拟的优点。目前一个现代化的仓库管理系统已经成为仓库管理不可缺少的管理手段。 1.2 可行性研究 可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。可行性研究的目的不是解决问题而是分析问题能不能解决；至少从下面三个方面分析可行性研究。 1.2.1技术可行性 该仓库数据库管理系统不不是很复杂，设计实现该数据库技术难度不是很大，利用目前现有的技术和工具能在规定的时间内做出该系统。该系统利用SQL2000和 visual studio 工具就能很好的实现该系统。 1.2.2经济可行性 当今世界是经济时代，一个公司的员工工作效率的高低直接影响着这个公司的发展。因此利用计算机进行信息管理有着无可比拟的好处，该系统相对较小，代码行较少，数据库设计不是很麻烦，开发周期较短。而且便于维护。但其带来的经济效益远远高于其开发成本。在经济上是可行的。 1.2.3操作可行性 在当今社会，随着义务教育的普及。和计算机的普及，公司的员工基本上都会进行电脑的基本操作，由于本软件系统采用相对友好的界面，用户 在使用过程中不需要懂太多的电脑专业知识，只需要基本的电脑操作就可
《数据库系统概论》课程设计报告 课程名称：数据库系统概论 院系年级：14级电气信息工程系 专业班级：计算机科学与技术1班 学号： 姓名： 联系电话： 指导教师： 安徽马鞍山
2016年6月 第一章相关方法技术 1.1数据库应用特点 数据库技术是现代信息科学与技术的重要组成部分，是计算机数据处理与信息管理系统的核心。数据库技术研究和解决了计算机信息处理过程中大量数据有效地组织和存储的问题，在数据库系统中减少数据存储冗余、实现数据共享、保障数据安全以及高效地检索数据和处理数据。随着计算机技术与网络通信技术的发展，数据库技术已成为信息社会中对大量数据进行组织与管理的重要技术手段及软件技术，是网络信息化管理系统的基础。 1.2数据与处理 以处理为中心 根据处理功能设计数据文件，处理功能需要什么数据就创建什么数据文件。处理功能是主动的，数据结构是依赖的。势必导致数据的冗余存储，潜在数据的不一致性。只适合科学计算，不适合数据密集型的事务处理系统。 以数据为中心 只要应用领域内的业务内容不变，其信息结构是稳定，多变的是处理功能。主张设计稳定的数据结构，自动适应处理程序的多变性。凡是数据库应用系统，适合采用以数据为中心的应用模式。 1.3数据库设计方法 （1）功能驱动方法: 这个方法设计依赖处理中心强调先根据功能要求画出分层的数据流程图从数据流程图当中收集数据项及其数据存储以及数据字典依据数字字典分析提取出数据库相关的各种信息类。 （2）E-R建模方法： 采用以数据为中心的设计策略在初步了解领域当中各种业务需求和处理过程基础上 1.4数据库设计步骤 按照规范化设计方法，从数据库应用系统设计和开发的全过程来考虑，将数据库及其应用软件系统的生命周期可以细分为七 个阶段：规划、需求分析、概念结构设计、逻辑结构设计、物理结构设计、实施及运行维护。 各阶段需完成的工作分别为： 1、应用规划 规划阶段进行系统的必要性和可行性分析，确定数据库系统在整个管理系统中的地位。 规划阶段必须要完成的任务包括：确定系统的范围；确定开发工作所需的资源（人员、硬件和软件）；估算软件开发的成本；确定项目进度。
数据库课程设计——学生信息管理系统 学院：机电工程学院 班级：09工业工程 组员：郎建鹏 学号：0911******* 指导老师：李峰平
目录 第一章系统分析 (2) 1 建立新系统的必要性 (2) 2 业务流程分析（业务流程图） (2) 3 数据流程图 (3) 4 数据字典 (4) 第二章系统设计 (4) 1 数据库设计（E-R） (4) 2系统运行环境 (6) 3输入输出设计 (10) 第三章设计总结 (10) 参考文献……………………………………………………………… 图例说明………………………………………………………………
第一章系统分析 1 建立新系统的必要性 这次的课程设计是在学习完《数据库原理》和《delphi程序设计》基础上进行的一次系统性的训练，既是对所学知识的巩固，也是对自己综合运用所学知识解决实际问题的一次锻炼。学生信息管理系统的主要目的是为了方便学校对学生的信息进行录入、修改、查询，提高学校的工作效率。这一系统的开发成功，解决了手写速度慢、容易出错的现状。 学生信息管理可以帮助学校最迅速最准确的完成所需的工作。无论是在适用性、灵活性和易操作性方面都显示出了它的强大功能。 2 业务流程分析（业务流程图）
数据流图是结构化分析中不可缺少的有力工具，它描述了系统的分解，即系统由哪些部分组成，各部分之间有什么联系等。但是，它还不能完整地表达一个系统的全部逻辑特征，特别是有关数据的详细内容。因此，仅仅一套数据流图并不能构成系统说明书，只有对图中出现的每一个成分都给出详细定义以之后，才能全面地描述一个系统。对数据流、数据存储和数据处理的详细描述，需要用数据字典（DD）。它包括数据流、数据存储、外部项和处理过程的详细条目。数据字典中把数据的最小单位定义为数据项，而若干数据项可以组成一个数据结构。数据字典是通过以数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。 第二章系统设计 1 数据库设计（E-R） （1）管理员实体的E-R图 （2）普通用户实体的E-R图
教务管理系统数据库(SQL Server 2008 + delphi7) 实验报告 班级: 姓名: 学号: 指导教师: 完成日期: 目录 第一章系统概述 (3) 第二章系统分析 (3) 第三章系统设计 (4) 第四章系统功能 (9) 第五章系统实现 (9) 第六章源程序附录 (15) 第七章参考文献 (73)
第一章系统概述 学校学生管理信息系统就是针对学校人事处的大量业务处理工作而开发的管理软件,就是典型的管理信息系统(Management Information System)。它就是一个教育单位不可缺少的部分,它的内容对于学校的决策者与管理者来说都至关重要,它能够为用户提供充足的信息与快捷的查询手段。能有效的帮助学校与老师掌握学生的情况,为学生提供成绩跟课程方面的查询。 本系统就是以delphi7编辑用户界面,以SQL server 2008为数据源后台而成的学生信息管理系统。本系统就是以计算机为基础,由人与计算机结合的对信息进行收集、存储、维护、加工、传递与使用的一种管理系统,其目的就是使人流、物流、资金流与信息流处于最佳状态,以最少的资源投入获得最佳的综合效益。本系统主要包括学生信息管理模块、教师信息管理模块、课程信息管理模块、成绩信息管理模块与系统维护模块等部分。在校务管理中,为有关部门提供完整、综合、共享的信息,对于学校的教育管理、教务与 科研等都有很大的实用价值。 第二章系统分析 1、问题定义 随着科学技术的不断提高,计算机科学日渐成熟,其强大功能已为人们深刻认识,它已进入人们生活的各个领域,并发挥了越来越重要的作用,针对人工管理的缺点,最好的解决办法就就是借助计算机技术提供一个电子化的学生信息管理平台。为了更好地管理学生与教职工的资料文档,我开发一个软件工程学生信息管理系统。教师与学生可以应用该系统实现如下功能: 1、可随时查询出不同系及各系教师与各系学生情况,系、教师与学生各反映如下情况: 系:系号、系名、系负责人、专业数等。 教师:工号、姓名、性别、职称、工龄、出生年月、基本工资等。 学生:学号、姓名、性别、年龄等。 2、为简单起见教师与学生区分系别,而课程不分系,课程需反映如下信息: 课程代号、课程名、课时数、必修课、学分。 3、学生入学时新生需录入登记,登记后即可选课学习课程(一学期约20学分)。 4、一门只由一位教师上,一位教师可上多门课,满30人才开课。 5、学生选每门课有个成绩,若成绩不及格则补考后还需记录补考成绩。 1)在某数据库管理系统中建立各关系模式对应的库表,并设计所需的视图、索引等。 2)能对各库表进行输入、修改、删除、添加、查询、打印等基本操作。 3)新生入校登记后可即时选课,老生每学期开始前可选课或作选课调整,一般要选共约20学分的若干门课程。 4)能明细查询某学生的选课情况及某课程的选修学生情况。 5)能统计查询出某学生的成绩单(包括总成绩、平均成绩、不及格门数等)及某门课的选课人数、最高分、最低分、平均成绩等统计信息。 6)能分析出某教师的教学质量情况(可根据该教师所任所有课优良数平均超过一定百分比来粗略评定)。 7)其她您认为子系统应有的查询、统计功能。 8)要求子系统设计得界面友好,功能选择方便合理,并适当考虑子系统在其安全性、完整性、备份、恢复等方面的功能要求
数据库原理设计心得体会 这段时间的设计与制作，给了你怎样的一些心得体会呢?那么记录下来吧!下面是WTT为大家整理的，供大家参考。 数据库原理设计心得体会(一) 在我看来，数据库课程设计主要的目标是利用课程中学到的数据库知识和技术较好的开发设计出数据库应用系统，去解决各行各业信息化处理的要求。通过这次的课程设计，可以巩固我们对数据库基本原理和基础理论的理解，掌握数据库应用系统设计开发的基本方法，进一步提高我们综合运用所学知识的能力。 当我们这组决定做大学生就业咨询系统时，我们并没有着手写程序。而是大家一起商量这个系统概述、系统目标、系统需求、业务流程分析、数据流程分析和数据词典。当这些都准备好了之后，我们进行模块的分工。每个人都有自己的模块设计，而且写出来的代码要求可以实现相应模块的功能，得到理想的效果。当每个人都把自己的分工做好了，最后会由一个人把这些全部组合搭建在一起。我们使用的是和php相互嵌套使用，当一个系统做好了之后，我会好好地把程序都看一遍，理会其中的奥秘。 我所负责的是数据库的备份和还原还有一些界面的实现。还记得自己刚接触的时候，觉得很感兴趣，所以有一段时间几乎到了痴迷的程度。然而Php是我刚接触不久的一种编程语言。不过
觉得它的功能真的很强大，可以开发出很多大型的系统。但是在做备份和还原的时候，要考虑的东西还是很多的。当我遇到错误的时候，感到很受打击。值得欣慰的是，在同学的帮助和大量参考书的查阅下，我把自己的模块做好了。这就是我收获最大的地方。而且，我明白了遇到困难永不放弃的重要性，我知道了团队合作的重要性，我领悟了只有坚持不懈才会取得胜利。 知识的获得是无止境的，只要你想学，只要你行动，没有什么会难倒我们的。回首这一个多星期的课程设计，我很欣慰。因为我有了动力，有了勇气。谢谢老师对我们的不懈帮助，谢谢学校给了我们这一次实践的机会，也谢谢组员们的关怀。这些美好的回忆美好的东西将永远伴随着我。 数据库原理设计心得体会(二) 两个星期的时间非常快就过去了，这两个星期不敢说自己有多大的进步，获得了多少知识，但起码是了解了项目开发的部分过程。虽说上过数据库上过管理信息系统等相关的课程，但是没有亲身经历过相关的设计工作细节。这次实习证实提供了一个很好的机会。 通过这次课程设计发现这其中需要的很多知识我们没有接触过，去图书馆查资料的时候发现我们前边所学到的仅仅是皮毛，还有很多需要我们掌握的东西我们根本不知道。同时也发现有很多已经学过的东西我们没有理解到位，不能灵活运用于实际，不能很好的用来解决问题，这就需要我们不断的大量的实践，通过
新闻管理系统数据库设计说明书 目录 1引言 (1) 1.1编写目的 (1) 1.2背景 (1) 1.3定义 (1) 1.4参考资料 (1) 2外部设计 (2) 2.1标志符和状态 (2) 2.2使用它的程序 (2) 2.3约定 (2) 2.4专门指导 (5) 2.5支持软件 (5) 3结构设计 (5) 3.1概念结构设计 (5) 3.2逻辑结构设计 (11) 3.3物理结构设计 (11) 4运用设计 (15) 4.1数据字典设计 (15) 4.2安全保密设计 (16)
1引言 1.1编写目的 本文档为新闻管理系统的数据库设计报告，为新闻管理系统的设计主要依据，主要针对新闻管理系统的概要设计和详细设计人员，作为项目验收的主要依据。 1.2背景 （1）待开发的软件系统名称：新闻管理系统 （2）本项目的任务提出者：team小分队 （3）开发者：team小分队 （4）用户：社会各阶级人群，主要人群大学生 1.3定义 （1）可靠性（Reliable），软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。 （2）安全性（Secure），软件系统所承担的交易的商业价值非常高，系统的安全性非常重要。（3）可伸缩性（SCAlable），软件必须能够在用户的使用率、用户的数目增长很快的情况下，保持合理的性能。只有这样，才能适应用户市场拓张的可能。 （4）可定制化（CuSTomizable），同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。 （5）可扩展性（Extensible），在新技术出现的时候，一个软件系统应当导入新技术，从而对现有系统进行功能和性能的拓展。 （6）可维护性（MAIntainable），软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有的系统中去。一个易于维护的系统可以有效地降低技术支持的花费。 （7）客户体验（Customer Experience），软件系统必须易于使用。 （8）市场时机（Time to Market），软件用户要面临同业竞争，软件提供商也要面临同业竞争，以最快的速度争夺市场先机非常重要。 1.4参考资料 《软件工程》
《数据库原理与应用》 课程设计 个人总结 题目机票预订系统 专业班级计0903 学号 2 姓名王龙飞 指导老师强新建 完成时间2012.1.12
课程设计心得体会及总结 两个星期的时间非常快就过去了，这两个星期不敢说自己有多大的进步，获得了多少知识，但起码是了解了项目开发的部分过程。虽说上过数据库上过管理信息系统等相关的课程，但是没有亲身经历过相关的设计工作细节。这次实习证实提供了一个很好的机会。 通过这次课程设计发现这其中需要的很多知识我们没有接触过，去图书馆查资料的时候发现我们前边所学到的仅仅是皮毛，还有很多需要我们掌握的东西我们根本不知道。同时也发现有很多已经学过的东西我们没有理解到位，不能灵活运用于实际，不能很好的用来解决问题，这就需要我们不断的大量的实践，通过不断的自学，不断地发现问题，思考问题，进而解决问题。在这个过程中我们将深刻理解所学知识，同时也可以学到不少很实用的东西。 从各种文档的阅读到开始的需求分析、概念结构设计、逻辑结构设计、物理结构设计。亲身体验了一回系统的设计开发过程。很多东西书上写的很清楚，貌似看着也很简单，思路非常清晰。但真正需要自己想办法去设计一个系统的时候才发现其中的难度。经常做到后面突然就发现自己一开始的设计有问题，然后又回去翻工，在各种反复中不断完善自己的想法。 我想有这样的问题不止我一个，事后想想是一开始着手做的时候下手过于轻快，或者说是根本不了解自己要做的这个系统是给谁用的。因为没有事先做过仔细的用户调查，不知道整个业务的流程，也不知道用户需要什么功能就忙着开发，这是作为设计开发人员需要特别警惕避免的，不然会给后来的工作带来很大的麻烦，甚至可能会需要全盘推倒重来。所以以后的课程设计要特别注意这一块的设计。 按照要求，我们做的是机票预订系统。说实话，我对这个是一无所知的，没有订过机票，也不知道航空公司是怎么一个流程。盲目开始设计的下场我已经尝过了，结果就是出来一个四不像的设计方案，没有什么实际用处。没有前期的调查，仅从指导书上那几条要求着手是不够的。 在需求分析过程中，我们通过上网查资料，去图书馆查阅相关资料，结合我们的生活经验，根据可行性研究的结果和客户的要求，分析现有情况及问题，采用结构，将机票预定系统划分为两个子系统：客户端子系统，服务器端子系统。在两周的时间里，不断地对程序及各模块进行修改、编译、调试、运行，其间遇到很多问题：由于忘记了一些语言的规范使得在调试过程中一些错误没有发现，通过这次课程设计，我对调试掌握得更加熟练了，意识到了程序语言的规范性以及我们在编程时要有严谨的态度，同时在写程序时如有一定量的注释，既增加了程序的可读性，也可以使自己在读程序时更容易。 我们学习并应用了语言，对数据库的创建、修改、删除方法有了一定的了解，通过导入表和删除表、更改表学会了对于表的一些操作，为了建立一个关系数据库信息管理系统，必须得经过系统调研、需求分析、概念设计、逻辑设计、物理设计、系统调试、维护以及系统评价的一般过程，为毕业设计打下基础。 很多事情不是想象中的那么简单的，它涉及到的各种实体、属性、数据流程、数据处理等等。很多时候感觉后面的设计根本无法继续，感觉像是被前面做的各种图限制了。在做关系模型转换的时候碰到有些实体即可以认为是实体又可以作为属性，为了避免冗余，尽量按照属性处理了。 物理结构设计基本没有碰到问题，这一块和安全性、完整性不觉就会在物理结构设计中添加一些安全设置：主键约束、约束、定义等。最后才做索引的部分，对一些比较经常使用搜索的列，外键上建立索引，这样可以明显加快检索的速度，最后别忘记重要的安全性设置，限制用户访问权限，新建用户并和数据库用户做相应的映射。 不管做什么，我们都要相信自己，不能畏惧，不能怕遇到困难，什么都需要去尝试，有些你开始认为很难的事在你尝试之后你可能会发现原来她并没有你以前觉得的那样，自己也