怎样设计一个优秀的数据库
一个成功的管理系统，是由：[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、W. H. Inmon 和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 语句可以写成如下所示：
1Select* From Customer, Order Where cu_surname = "MYNAME" ;
2and cu_name_id = or_cust_name_id and or_quantity = 1
在没有这些前缀的情况下则写成这个样子（用别名来区分）：
1Select* From Customer, Order Where Customer.surname = "MYNAME" ;
2and https://www.doczj.com/doc/4416489531.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.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）数据库的建立和维护包括数据库的初始建立、数据的转换、数据库的转储和恢复、数据库的重组织和重构造以及有性能监测分析等功能。
大工15春《SQL数据库课程设计》模板及要求网络教育学院 《SQL数据库课程设计》 题目：XX系统的设计与实现 学习中心： 专业： 年级：年春/秋季
学号： 学生： 指导教师： 《SQL数据库课程设计》要求 《SQL数据库课程设计》是大连理工大学网络教育学院计算机应用技术专业开展的一项实践教学环节，是理论联系实践的纽带和桥梁，是培养学生综合运用所学知识解决实际问题的有效手段。该课程设计要求如下：1．要求学生以SQL Server 2008或其他版本为后台数据库，以VB、VC 或其他开发工具作为前台开发工具，围绕自己选定的某一个具体的系统完成一个小型数据库应用系统的开发，例如《图书管理系统的设计与实现》《书店管理系统的设计与实现》等。其课程设计具体内容包括项目概况、需求分析、详细设计等，详见课程离线作业中上传的《SQL数据库课程设计模板》。 注意：禁止撰写《学生成绩管理系统》课程设计！！ 2．要求学生必须按照《SQL数据库课程设计模板》提供的格式和内容进行课程设计，完成课程设计模板提供的全部课程设计内容，字数要求达到3000字以上。 3．学生在进行课程设计的过程中，可参考辅导教师在导学资料中上传的
文献资料，有问题可通过课程论坛答疑。 4．2015年春季学期学生提交本课程设计形式及截止时间 学生需要以WORD附件形式（附件的大小限制在10M以内）将完成的课程设计以"离线作业"形式上传至课程平台中的"离线作业"模块，通过选择已完成的课程设计，点"上交"即可，如下图所示。 截止时间：2015年9月1日。在此之前，学生可随时提交课程设计，如需修改，可直接上传新文件，平台会自动覆盖原有文件。 5．课程设计批阅 老师会在离线作业关闭后集中批阅课程设计，在离线作业截止时间前不进行任何形式的批阅。 注意： 本课程设计应该独立完成，不准抄袭他人或者请人代做，如有雷同作业，
数据库课程设计完 整版
HUNAN CITY UNIVERSITY 数据库系统课程设计 设计题目：宿舍管理信息系统姓名： 学号： 专业：信息与计算科学指导教师：
20年 12月1日 目录 引言3 一、人员分配 4 二、课程设计目的和要求 4 三、课程设计过程 1.需求分析阶段 1.1应用背景 5 1.2需求分析目标5 1.3系统设计概要5 1.4软件处理对象 6 1.5系统可行性分析6 1.6系统设计目标及意义7 1.7系统业务流程及具体功能 7
1.8.1数据流程图8 2.系统的数据字典11 3.概念结构设计阶段 13 4.逻辑结构设计阶段 15 5.物理结构设计阶段 18 6.数据库实施 18 7.数据库的运行和维护 18 7.1 解决问题方法 19 7.2 系统维护 19 7.3 数据库性能评价 19 四、课程设计心得. 20参考文献 20 引言
学生宿舍管理系统对于一个学校来说是必不可少的组成部分。当前好多学校还停留在宿舍管理人员手工记录数据的最初阶段，手工记录对于规模小的学校来说还勉强能够接受，但对于学生信息量比较庞大，需要记录存档的数据比较多的高校来说，人工记录是相当麻烦的。而且当查找某条记录时，由于数据量庞大，还只能靠人工去一条一条的查找，这样不但麻烦还浪费了许多时间，效率也比较低。当今社会是飞速进步的世界，原始的记录方式已经被社会所淘汰了，计算机化管理正是适应时代的产物。信息世界永远不会是一个平静的世界，当一种技术不能满足需求时，就会有新的技术诞生并取代旧技术。21世纪的今天,信息社会占着主流地位，计算机在各行各业中的运用已经得到普及，自动化、信息化的管理越来越广泛应用于各个领域。我们针对如此，设计了一套学生宿舍管理系统。学生宿舍管理系统采用的是计算机化管理，系统做的尽量人性化，使用者会感到操作非常方便，管理人员需要做的就是将数据输入到系统的数据库中去。由于数据库存储容量相当大，而且比较稳定，适合较长时间的保存，也不容易丢失。这无疑是为信息存储量比较大的学校提供了一个方便、快捷的操作方式。本系统具有运行速度快、安全性高、稳定性好的优点，而且具备修改功能，能够快速的查询学校所需的住宿信息。 面对当前学校发展的实际状况，我们经过实地调研之后，对宿舍管理系统的设计开发做了一个详细的概述。
《数据库原理与应用》课程设计指导书 制订教师：张娟 城市学院 2015年12月
数据库课程设计指导书 模块01 “教学管理系统”数据库设计 1、设计步骤 工作任务 任务1：“学分制教学管理系统”需求分析 任务2：“学分制教学管理系统”概念设计 任务3：“学分制教学管理系统”逻辑设计 任务4：“学分制教学管理系统”逻辑设计 学习目标 理解关系型数据库基本概念 熟悉数据库设计的主要阶段和步骤 掌握数据库概念设计中绘制E-R 图的方法 掌握将E-R 图转换为数据表逻辑形式的方法 理解并掌握数据库设计规范化方法 2、设计内容 任务1-1 “学分制教学管理系统”需求分析 ● 数据库设计 ● 数据库系统的分析与设计一般分为需求分析、概念设计、逻辑设计、物理设计四个阶段。在数据库系统设计的整个过程中，需求分析和概念设计可以独立于任何的数据库管理系统（DBMS ），而逻辑设计和物理设计则与具体的数据库管理系统密切相关。 需求分析 概念设计 逻辑设计 物理设计 需求分析说明书 独立于数据库管理系统 相关于数据库管理系统 DBMS 的特征 硬件和操作系统的特征 数据库概念模式 数据库逻辑模式 数据库物理模式 需求分析 分析用户的要求。需求分析是数据库系统设计的基础，通过调查和分析，了解用户的信息需求和处理需求，并以数据流图、数据字典等形式加以描述。 概念设计 主要是把需求分析阶段得到的用户需求抽象化为概念模型。概念设计是数据库系统设计的关键，我们将使用E-R 模型作为概念模式设计的工具。 逻辑设计 就是将概念设计阶段产生的概念模式转换为逻辑模式。因为逻辑设计与数据库管理系统（DBMS ）密切相关，本书以关系模型和关系数据库管理系统为基础讨论逻辑设计。
摘要 数据库原理及应用课程设计是软件工程专业集中实践性环节之一，是学习完《数据库原理及应用》课程后进行的一次全面的综合练习。其目的在于加深对数据库基础理论和基本知识的理解，掌握使用数据库进行软件设计的基本方法，提高运用数据库解决实际问题的能力，最终实现对于给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求(信息要求和处理要求)。 数据库及其应用系统是具有管理功能的计算机系统，而数据库原理及应用课程设计在开发应用程序中至关重要，合理的数据表结构不尽有利于软件的快速开发，而且有利于以后对软件的维护。 目前，我国的科技水平高速发展，计算机作为今天使用最广的现代化工具已深入到各个领域，并且正在成为未来社会——信息社会的重要支柱。在这样的大背景下，现代图书馆的管理方式，资源建设等方面都发生了重大变化，这种变化表现在图书馆工作，管理和服务平台发生的变化，图书馆不再是传统的手工操作，人工管理，而是全面实行计算机管理。 一个简单的图书管理系统包括图书馆内书籍的信息、学校在校学生的信息以及学生的借阅信息。系统在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
SQL上机实验项目设计列车信息查询数据库 学号：24110121 姓名：王若龙
1、实验项目名称：数据模型的建立过程与方法 2、实验项目编号：ab0822420305 3、实验性质：必做 4、实验类型：设计 5、实验目的：熟练掌握数据模型的设计、建立的过程与方法。 6、实验内容： 设计一个数据库，实现列车车次信息和车站信息的基本管理，为列车运行时刻信息的录入、修改、查询与统计等功能提供数据库支撑。 要求： （1）设计该数据库E-R图 （2）将E-R模型转换为关系模型，并规范化 （3）用SQL语句定义并建立数据库表结构 （4）提供以下SQL语句，并加以说明。 查询某车站火车到站出站信息。 查询某列火车沿途经过站点信息 查询从某站点上车，到达某站点，共有哪些列车可供乘坐。 统计某段时间经过某站点的列车共有多少。
（1）设计E-R 图 （2）将E-R 模型转换为关系模型，并规范化 车站信息（车站号，车站名） 列车信息（车次，始发站，终点站，出发时间，到达时间） 乘务人员（车次，姓名，职务） 经由信息（车次，车站名，到站时间，出站时间） （3）用SQL 语句定义并建立数据库表结构 车站信息表（station ），采用命令行创建方式。 字段名 代码 类型 约束 车站号 sno char （5） 主键 车站名 sname char （20） 列车信息表（train ），采用命令行创建方式。 字段名 代码 类型 约束 车次 tno char （5） 主键 始发站 sf char(20) Not null 终点站 zd char(20) Not null 出发时间 cf time 到达时间 dd time
HUNAN CITY UNIVERSITY 数据库系统课程设计设计题目：宿舍管理信息系统 姓名： 学号： 专业：信息与计算科学 指导教师： 20年 12月1日 目录 引言 3 一、人员分配 4 二、课程设计目的和要求 4 三、课程设计过程 1.需求分析阶段 1.1应用背景 5 1.2需求分析目标5 1.3系统设计概要 5 1.4软件处理对象 6 1.5系统可行性分析 6 1.6系统设计目标及意义7
1.7系统业务流程及具体功能 7 8 2.系统的数据字典11 3.概念结构设计阶段 13 4.逻辑结构设计阶段 15 5.物理结构设计阶段 18 6.数据库实施 18 7.数据库的运行和维护 18 7.1 解决问题方法 19 7.2 系统维护 19 7.3 数据库性能评价 19 四、课程设计心得. 20 参考文献 20 引言 学生宿舍管理系统对于一个学校来说是必不可少的组成部分。目前好多学校还停留在宿舍管理人员手工记录数据的最初阶段，手工记录对于规模小的学校来说还勉强可以接受，但对于学生信息量比较庞大，需要记录存档的数据比较多的高校来说，人工记录是相当麻烦的。而且当查找某条记录时，由于数据量庞大，还只能靠人工去一条一条的查找，这样不但麻烦还浪费了许多时间，效率也比较低。当今社会是飞速进步的世界，原始的记录方式已经被社会所淘汰了，计算机化管理正是适应时代的产物。信息世界永远不会是一个平静的世界，当一种技术不能满足需求时，就会有新的技术诞生并取代旧技术。21世纪的今天,信息社会占着主流地位，计算机在各行各业中的运用已经得到普及，自动化、信息化的管理越来越广泛应用于各个领域。我们针对如此，设计了一套学生宿舍管理系统。学生宿舍管理系统采用的是计算机化管理，系统做的尽量人性化，使用者会感到操作非常方便，管理人员需要做的就是将数据输入到系统的数据库中去。由于数据库存储容量相当大，而且比较稳定，适合较长时间的保存，也不容易丢失。这无疑是为信息存储量比较大的学校提供了
目录 前言------------------------------------------------------------ 1 正文 1 1引言 ---------------------------------------------------------- 1 2数据库设计----------------------------------------------------- 1 2.1本系统功能需求分析------------------------------------------- 2 2.2业务流图----------------------------------------------------- 2 2.3数据字典(DD： DATA DICTIONARY) --------------------------------- 3 2.4E-R 图------------------------------------------------------ 5 2.5概念数据模型和物理概念模型----------------------------------- 5 2.6创建数据库以及数据表----------------------------------------- 7 2.7数据测试---------------------------------------------------- 11 3存在问题和建议------------------------------------------------ 22 4收获和体会---------------------------------------------------- 22 致------------------------------------------------------------- 23 参考文献------------------------------------------------------- 23
1.1、功能特点 ?前台基本功能 进货管理:进行商品采购入库,采购退货,进/退单据和当前库存查询,与供货商的往来帐务。 销售管理:进行商品销售,顾客退货,销/退单据和当前库存查询,POS 销售统计,与客户的往来帐务。 库存管理:包括库存之间商品调拔,商品的报损溢,强大的库存盘点功能,库存商品报警查询。 统计报表:完整的统计查询功能，每张单据每次收款付款都可以清楚的反映。 日常管理:对供货商,客户,业务员综合管理,对日常收入支出管理,客户借货坏帐管理,合同管理。 基本设置:商品信息,商品调价,供货商,客户,员工,会员,仓库等基本参数的设置。 系统维护:数据库备份/恢复,系统初始化,操作员修改密码,年终结算,查看日志,打印条码,赠品管理。 ?后台基本功能 商品销售:进行商品的销售工作,用户可以通过输入商品的条码,编号来选择商品。 销售退货:进行已销售商品的顾客退货工作,同样可以通过商品条码和编号来选择商品。 打印设置:设置小票的标题和脚注以及要选择的打印机。 兑换赠品:有关会员用积分兑换赠品的管理工作。 赠送赠品:有关赠品的赠送管理工作。 修改密码:修改当前收银员的密码。 快捷键设置:设置 POS 中各功能的快捷键。 出入款管理:管理有关收银员的出入款工作。 1.2、系统要求 1、计算机硬件在586等级以上. 2、软件要求操作系统为中文WIN98,WIN2000,WINXP.WIN2003 3、装有microsoft数据库驱动程序 4、屏幕分辨率800X600以上.
二、快速入门
后台主界面及功能说明： 图1 2.1、基本设置：在基本设置中可以对商品信息、商品调价、供货商、客户、员工、操作员、会员、仓库进行设置 2.1.1、商品信息 在基本设置模块中点击“商品信息”进入商品信息界面如图2
序言 (1) 一、图书馆管理系统E-R 图 (2) 二、图书馆管理系统功能实现示意图 (3) 三、图书馆管理系统功能图例 (4) 3.1 读者借阅图书 (4) 3.2 读者归还图书 (4) 3.3 读者续借图书 (5) 3.4 读者查询借阅图书情况 (5) 3.5 读者检索图书信息 (6) 四、图书馆管理系统附加功能 (7) 4.1 往学生表中插入列"系部"，其值等于学号中代表系部的位的 值，再插入列"专业号"，其值等于学号中代表专业的位的值 . 7 4.2 查询每个学生对书本的借阅数量 (9) 4.3 查询各个专业的学生借阅书本的数量 (11) 五、图书馆管理系统数据库、数据表源代码......... 错误！未定义书签。 5.1 图书馆管理系统"数据库"源代码 ................ 错误！未定义书签。 5.2 图书馆管理系统"数据表"源代码 ................ 错误！未定义书签。 六、图书馆管理系统存储过程源代码..................... 错误！未定义书签。 6.1 读者借阅图书存储过程................................ 错误！未定义书签。 6.2 读者还书存储过程........................................ 错误！未定义书签。 6.3读者续借图书存储过程................................. 错误！未定义书签。 6.4 读者查询借阅图书情况存储过程................ 错误！未定义书签。 6.5 读者检索的图书信息存储过程.................... 错误！未定义书签。 七、图书馆管理系统触发器源代码......................... 错误！未定义书签。 7.1 借书要求（书本没有库存，则无法进行借书操作）错误！未定 义书签。 7.2 借书要求（读者最多借阅量）.................... 错误！未定义书签。 7.3 续借次数要求................................................ 错误！未定义书签。 7.4 读者还书信息插入RDeleted表................... 错误！未定义书签。
数据库设计的基本步骤 一、数据库设计的生存期 按照规范设计的方法，考虑到数据库及其应用系统开发的全过程，将数据库 设计分为六个阶段。如下图。 ① 需求分析 需求收集和分析, 需求。 ② 概念结构设计 对需求进行综合、归纳与抽象，形成一个独立于具体 DBMS 的概念模型（用 E-R 图表示）。 ③ 逻辑结构设计 将概念结构转换为某个DBMS 所支持的数据模型（例如关系模型），并对其 进行优化。 ④ 物理结构设计 为逻辑数据模型选取一个最适合应用环境的物理结构 （包括存储结构和存取 方法）。 ⑤ 数据库实施 需求A 祈断段 T 1 概念设计阶段 i 逻辑 q 丰计阶段 1 物理. 1 殳计阶段 j 数据E L 支实施阶段 数据库运荷? 维护阶段 得到用数据字典描述的数据需求，用数据流图描述的处理
运用DBMS 提供的数据语言（例如 SQL ）及其宿主语言（例如C）,根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 ⑥数据库运行和维护 数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。 说明：设计一个完善的数据库应用系统是不可能一蹴而就的，它往往是上述 六个阶段的不断反复。 二、数据库设计阶段的内容 设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。下面针对各阶段的设计内容给出各阶段的设计描述。如下图。 阶段 濮块结构） 三、数据库设计阶段的模式 数据库结构设计的不同阶段形成数据库的各级模式，如下图 需求数据字睦、全系统中数据项、 分析數据證、数据存储的描述 数1E流图和判定我（利宦 闕）、数据字典中处理过程的 描述 设计 概念模型〔E?兄图） 模块设计 IPO表 编写模武装入 数JE 实施数揭库试 运行阶段 Create … L o豆恋■?. 程序编码 编译联结 测试 Tlain () * ■ A if???then ■■ i HUl 数据宇典 系窥说朋书包括： ①新系统要求、 方案和概图 ②反映新系统信息 流的数据流图 方法选择物理 存取路径建立设计
仓库管理系统数据库设计 1概述（设计题目与可行性分析） 1.1设计题目 设计一个仓库数据库管理系统，要求实现入库、出库、库存和采购等功能。 随着经济的飞速发展，，仓库管理变成了各大公司日益重要的内容。仓库管理过程的准确性和高效性至关重要。影响着公司的经济发展和管理。利用人工管理强大而数据烦琐的数据库显的效率过于低。利用计算机高效、准确的特点能够很好的满足公司的管理需要。提高公司各个员工的工作效率和公司的运做效率。利用计算机对仓库数据信息进行管理具有着手工管理所无法比拟的优点。目前一个现代化的仓库管理系统已经成为仓库管理不可缺少的管理手段。 1.2 可行性研究 可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。可行性研究的目的不是解决问题而是分析问题能不能解决；至少从下面三个方面分析可行性研究。 1.2.1技术可行性 该仓库数据库管理系统不不是很复杂，设计实现该数据库技术难度不是很大，利用目前现有的技术和工具能在规定的时间内做出该系统。该系统利用SQL2000和 visual studio 工具就能很好的实现该系统。 1.2.2经济可行性 当今世界是经济时代，一个公司的员工工作效率的高低直接影响着这个公司的发展。因此利用计算机进行信息管理有着无可比拟的好处，该系统相对较小，代码行较少，数据库设计不是很麻烦，开发周期较短。而且便于维护。但其带来的经济效益远远高于其开发成本。在经济上是可行的。 1.2.3操作可行性 在当今社会，随着义务教育的普及。和计算机的普及，公司的员工基本上都会进行电脑的基本操作，由于本软件系统采用相对友好的界面，用户 在使用过程中不需要懂太多的电脑专业知识，只需要基本的电脑操作就可
宁夏大学物理电气信息学院综合性实验 实验报告 课程名称数据库应用 实验学期 2011 至 2012 学年第二学期学生所在系物理电气信息学院电气系 年级 09级专业班级电子信息工程（1）班 学生姓名学号 任课教师 实验成绩 任课教师制 2012 年 6 月 10 日
实验题目小型超市商品进销存管理系统 一、实验目的 1、掌握计算机管理信息系统设计的一般方法，主要包括系统分析、系统设计的组织和实施。 2、关系型数据库管理系统SQL语言编辑能力，并能独立完成一般小系统的结构设计、调试运行等工作。 3、提高学生实践使用SQL语言的能力，把所学知识运用到具体对象，并能求出解决方案的能力。 二、实验环境 本次实验主要选用数据库软件设计语言SQL Server 2008版本进行该系统设计。 三、实验内容 1、需求分析 本软件对超市的采购、销售、仓库、资金、帐务等实际运作流程均实现了动态的计算管理，使得超市经营者能够迅速的掌控该超市的实际运作状况、合理做出超市的战略决策。软件提供的商品入库流水账、商品销售流水账、商品台账、会计账及各种报表在提高超市工作效率、减少人为的差错、最大限度堵塞漏洞的基础上很好的减轻了采购、销售、仓库、财务等环节工作人员的劳动强度，全面体现了现代小中型企业管理理论所倡导的工作高效、环境轻松的氛围。并且本系统的开发，为超市的工作效率带来了一个质的飞跃，为此主要表现有以下几个方面： 第一，本系统的运行可以代替人工进行许多繁杂的劳动； 第二，本系统的运行可以节省许多资源； 第三，本系统的运行可以大大的提高企业的工作效率； 第四，本系统可以使敏感文档更加安全，等等。 本产品的开发所需的设备在现有条件下，只需要少量的投入资金就可以实现。因此在经济上是可行的。 2、数据库设计 (1)系统要求实现：基本资料、进货管理、销售管理、库存管理、财务管理、自动编制记帐凭证等管理功能。系统总设计图如下所示：
教务管理系统数据库(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)要求子系统设计得界面友好,功能选择方便合理,并适当考虑子系统在其安全性、完整性、备份、恢复等方面的功能要求
数据库技术与应用 课程设计说明书 题目：学生成绩管理系统 院系： 专业班级： 学号： 学生姓名： 指导教师： 2014年 12 月 22 日 一概述 1.1目的与要求
随着科技的发展，基本上所有的具有一定数量数据的机构都开始使用计算机数据库来做管理。几乎所有学校也都已经在使用计算机管理数据的机制，大大减少了学校学生成绩管理的工作量。该课程设计要求设计一个学生成绩的数据库管理系统，数据库中要求包含学生的基本信息，学科基本信息，以及学生所学课程的考试成绩。要方便学生进行成绩查询，通过该课程设计，应该达到把数据库理论知识更加的巩固加深，加强动手能力与实践能力，学以致用，与现实生活中的应用充分的结合起来。 1.2设计环境 ① Microsoft SQL Server 2000 ② Microsoft Visual C++ 6.0 二需求分析 2.1 系统功能要求设计 此系统实现如下系统功能： （1）使得学生的成绩管理工作更加清晰、条理化、自动化。 （2）通过用户名和密码登录系统，查询课程基本资料，学生所选课程成绩，修改用户密码等功能。容易地完成学生信息的查询操作。 (3) 设计人机友好界面，功能安排合理，操作使用方便，并且进一步考虑系统在安全性，完 整性，并发控制，备份和恢复等方面的功能要求。 2.2 系统模块设计 成绩管理系统大体可以分成二大模块如，一是学生的基本信息模块，里面应该包含学生的各方面的基本信息；再者便是课程管理模块，在该模块中应该包含有对学生成绩信息的查询和处理，如平均成绩、最好成绩、最差成绩以及不及格学生的统计等功能模块；再其次还有教师、课程等相关信息的模块；可以得到系统流程图： 登陆失败 用户 验证
HUNAN CITY UNIVERSITY 数据库系统课程设计 设计题目：宿舍管理信息系统 姓名： 学号： 专业：信息与计算科学 指导教师： 20年 12月1日
目录 引言 3 一、人员分配 4 二、课程设计目的和要求 4 三、课程设计过程 1.需求分析阶段 1.1应用背景 5 1.2需求分析目标5 1.3系统设计概要 5 1.4软件处理对象 6 1.5系统可行性分析 6 1.6系统设计目标及意义7 1.7系统业务流程及具体功能 7 1.8.1数据流程图8 2.系统的数据字典11 3.概念结构设计阶段 13 4.逻辑结构设计阶段 15 5.物理结构设计阶段 18 6.数据库实施 18 7.数据库的运行和维护 18 7.1 解决问题方法 19 7.2 系统维护 19 7.3 数据库性能评价 19 四、课程设计心得. 20参考文献 20
引言 学生宿舍管理系统对于一个学校来说是必不可少的组成部分。目前好多学校还停留在宿舍管理人员手工记录数据的最初阶段，手工记录对于规模小的学校来说还勉强可以接受，但对于学生信息量比较庞大，需要记录存档的数据比较多的高校来说，人工记录是相当麻烦的。而且当查找某条记录时，由于数据量庞大，还只能靠人工去一条一条的查找，这样不但麻烦还浪费了许多时间，效率也比较低。当今社会是飞速进步的世界，原始的记录方式已经被社会所淘汰了，计算机化管理正是适应时代的产物。信息世界永远不会是一个平静的世界，当一种技术不能满足需求时，就会有新的技术诞生并取代旧技术。21世纪的今天,信息社会占着主流地位，计算机在各行各业中的运用已经得到普及，自动化、信息化的管理越来越广泛应用于各个领域。我们针对如此，设计了一套学生宿舍管理系统。学生宿舍管理系统采用的是计算机化管理，系统做的尽量人性化，使用者会感到操作非常方便，管理人员需要做的就是将数据输入到系统的数据库中去。由于数据库存储容量相当大，而且比较稳定，适合较长时间的保存，也不容易丢失。这无疑是为信息存储量比较大的学校提供了一个方便、快捷的操作方式。本系统具有运行速度快、安全性高、稳定性好的优点，并且具备修改功能，能够快速的查询学校所需的住宿信息。 面对目前学校发展的实际状况，我们通过实地调研之后，对宿舍管理系统的设计开发做了一个详细的概述。
网络教育学院《SQL数据库课程设计》 题目：学生信息管理系统的设计与实现学习中心：奥鹏学习中心 专业： 年级：年 /秋季 学号： 学生： 指导教师：龙珠
1 项目概况 1.1 SQL 数据库简介 Microsoft SQL Server 2000 是Microsoft 公司继SQL Server 6.5和SQL Server 7.0以后，在新千年推出的又一改进的新版关系型数据管理系统。它能使用户快捷地管理数据库和开发应用程序。SQL Server 2000 使用了了先进的数据库结构，与Windows DNA紧密集成，具有强大的Web 功能，它可以利用高端硬件平台以及最新网络和存储技术，可以为最大的Web站点和企业应用提供优良的扩展性和可靠性，使用户能够在Internet 领域快速建立服务系统，为占领市场赢得宝贵的时间。同时，SQL Server 2000 还为用户提供了重要的安全性功能的增强，为用户的数据安全提供了可靠的保证。另外，SQL Server 2000还为用户提供了重要的安全性功能的增强，为用户的数据安全提供了可靠的保证。另外,SQL Server 2000 在数据库服务器自动管理技术方面处于数据库领域的领先地位，它可以使用户免去繁琐复杂的工作量，从而有精力处理更重要的问题，使用系统在商业战略上占得先机。 SQL Server 2000 的特性Microsoft® SQL Server? 2000 的特性包括： 1、Internet 集成。SQL Server 2000 数据库引擎提供完整的XML 支持。它还具有构成最大的Web 站点的数据存储组件所需的可用性、可伸缩性和安全功能。 2、可伸缩性和可用性。同一个数据库引擎可以在不同的平台上使用，从运行 Microsoft Windows® 98 的便携式电脑到运行 Microsoft Windows 2000 数据中心版的大型多处理器服务器。 3、业级数据库功能。SQL Server 2000 关系数据库引擎支持当今苛刻的数据处理环境所需的功能。数据库引擎充分保护数据完整性，同时将管理上
. 中北大学 数据库课程设计 说明书 班 级： 学号： 姓 名： 学 专 方 向： 指导教师： 企业信息化软件开发与应用
成绩： 2014 年 6 月 1.需求分析 随着城市人口规模的扩大和公安部门对城市及农村人口管理工作规性的逐渐增强，户籍管理工作的业务量急剧增大。传统的手工方法，存在效率低、易出错等缺点，已经难以满足当前户籍管理工作的要求。 因此，结合当前日益成熟的计算机相关技术，开发一个专门针对户籍管理的系统已经非常必要了。户籍管理信息系统是公安部门不可缺少的一部分，更是适应现代户籍制度并推动户籍管理走向科学化、规化、自动化的必要条件。该管理系统能够为用户提供充足的信息和快捷的查询手段，以帮助用户了解户籍工作的情况。它大大改善了公安部门管理、查询户籍的基础工作环境，在一定程度上反映出户籍管理的现代化管理模式。因此人口户籍管理信息系统的开发迫在眉睫。 该课程设计就户籍的迁入、迁出、注销，身份证的办理、领取做了简单地设计。 1.1项目开发背景 近年来，随着计算机技术的发展和互联网时代的到来，我们已经进入了信息时代，随着人口的不断增长，户籍管理部门也应得到良好的发展，利用现代化管理工具使其变成半自动化必定会提高其工作效率。 1.2项目开发目的 户籍管理系统是针对户籍管理部门而开发的，为其改变人口信息仍需要手动处理和查询，个人的信息在处理中丢失或者不明确等现象而设计的。通过这个户籍管理系统，可以让
户籍管理部门提高工作质量和效率，从而达到更快捷、更准确、更方便的目的。 1.3需求分析阶段的目标与任务 1.3.1划分功能模块 在构造系统时，首先从需求出发构造数据库表，然后再由数据库表结合需求化分系统功能模块，这样就把一个大的系统分解为几个小的系统。经过调查分析，户籍信息管理系统应具有以下功能： （1）对户籍的变动进行处理。任何管理部门的户籍信息不会是一成不变的，总是在不断的变化：有迁出、有迁入、户口合并，也有因故注销。因此，设计系统时应考虑到这些情况，实现户籍的日常管理工作。 （2）对所管辖户籍所分离出的个人信息的计算、统计。找到符合条件的个人，进行核对无误后，生成档案文件进行转存，保证数据的安全完整，以此来实现身份证的办理与领取。 （3）查询统计功能。要求即可以单项查询，比如查看某个人工的户口情况等；也可以多项查询，比如同一户口特征的户口浏览，并按照所需的要求进行数据的转存。 1.3.2处理对象 户籍信息:户籍号，户主姓名 户籍成员信息:姓名，户主关系，性别，民族，籍贯，住址，身份证号，文化程度，职业，户籍号，迁入时间，迁出时间，迁入地，迁出地 身份证：姓名，身份证号，性别，民族，地址
精心整理仓库管理系统数据库设计 班级： 学号、姓名： 学号、姓名： 1. （1
（2）分析设计顶层数据流图 由于在搜寻指定货物时会因货物量大而加重任务量，在对一些货物及人员就行更新时也会因为复杂而手忙脚乱。这样在交易活动中不断地产生新数据，使得信息量逐渐加大。但使用本系统可以很方便的对所需信息进行查询，也可适时的利用插入功能对相关数据进行更新，这样及时、便捷、高效的得到查询统计结果。因此，设计顶层数据流图如图1所示： （ 进
1 据流图 （4）制定整理数据字典 数据流图反应了数据和处理之间的关系，数据字典是系统中各类数据描述的集合。通常包括数据项、数据结构、数据流、数据存储和处理过程5个部分。 数据项数据项含义数据类型宽度与其他数据项的 逻辑关系 可否为 空值 是否为主(P)/ 外(F)键 货物编号char 8 NO YES(P)
数据项数据项含义数据类型宽度与其他数据项的 逻辑关系 可否为 空值 是否为主(P)/ 外(F)键 货物名称char 8 NO 货物类别char 8 NO 货物数量int 8 NO 备注char 12 客户编号char 8 NO 客户名称char 4 NO 编号char 18 NO 货物价格int 12 NO 2. （1
3 出库单联系转换为出库单关系（编号，货物编号，仓库编号，客户编号，货物价格，出库数量，出库日期） （2）将CDM转换成PDM 利用PowerDesigner的“Generate Physical Data Model”工具将CDM转换成PDM，如图6所示。
图6 仓库管理PDM图 、数据库实施与维护 （1）仓库管理 及时向上级部门和领导提供库存查询信息。为了防止超储造成产品库存积压，同时也为了避免产品库存数量不足而影响市场需求，仓库管理员要经常与入库经理、出库经理和货物经理核实货物库存信息，也应该经常提供库存报警数据。 CREATE TABLE 表名 （2）入库管理 各生产车间随时将制造出来的产品连同填写好的入库单（入库小票）一起送至仓库。仓库人员首先进行检验，一是抽检产品的质量是否合格，二是核对产品的实物数量和规格等是否与入库单上的数据相符，当然还要校核入库单上的产品代码。检验合格的产品立即进行产品入库处理，同时登记产品入库流水帐。检验不合格的产品要及时退回车间。 （3）出库管理 仓库保管员根据销售科开出的有效产品出库单（出库小票）及时付货，并判明是零售出库还是成批销售出克，以便及时登记相应的产品出库流水帐。 5、可行性分析 （1）技术可行性：