数据库设计毕业设计作业

数据库设计毕业设计作业内容摘要：

，对任何外键列采用非成组索引。 考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。 2) 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。 3) 不要索引 memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。 4) 不要索引常用的小型表。 不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。 对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。 数据完整性设计（数据库逻辑设计） 完整性实现机制： 实体完整性：主键 参照完整性： 父表中删除数据：级联删除；受限删除；置空值 父表中插入数据：受限插入；递归插入 父表中更新数据：级联更新；受限更新；置空值 DBMS 对参照完整性可以有两种方法实现：外 键实现机制（约束规则）和触发器实现机制 用户定义完整性： NOT NULL； CHECK；触发器 用约束而非商务规则强制数据完整性 采用数据库系统实现数据的完整性。 这不但包括通过标准化实现的完整性而且还包括数据的功能性。 在写数据的时候还可以增加触发器来保证数据的正确性。 不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所 16 以不能强加于其他完整性规则之上。 强制指示完整性 在有害数据进入数据库之前将其剔除。 激活数据库系统的指示完整性特性。 这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条 件。 使用查找控制数据完整性 控制数据完整性的最佳方式就是限制用户的选择。 只要有可能都应该提供给用户一个清晰的价值列表供其选择。 这样将减少键入代码的错误和误解同时提供数据的一致性。 某些公共数据特别适合查找：国家代码、状态代码等。 采用视图 为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。 这样做还等于在处理数据库变更时给你提供了更多的自由。 其他设计技巧 避免使用触发器 触发器的功能通常可以用其他方式实现。 在调试程序时触发器可能成为干扰。 假如你确实需 要采用触发器，你最好集中对它文档化。 使用常用英语（或者其他任何语言）而不要使用编码 在创建下拉菜单、列表、报表时最好按照英语名排序。 假如需要编码，可以在编码旁附上用户知道的英语。 保存常用信息 让一个表专门存放一般数据库信息非常有用。 在这个表里存放数据库当前版本、最近检查 /修复（对 Access）、关联设计文档的名称、客户等信息。 这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机 /服务器环境特别有用。 包含版本机制 在数据库中引入版本控制机制来确定使用 中的数据库的版本。 时间一长，用户的需求总是会改变的。 最终可能会要求修改数据库结构。 把版本信息直接存放到数据库中更为方便。 编制文档 17 对所有的快捷方式、命名规范、限制和函数都要编制文档。 采用给表、列、触发器等加注释的数据库工具。 对开发、支持和跟踪修改非常有用。 对数据库文档化，或者在数据库自身的内部或者单独建立文档。 这样，当过了一年多时间后再回过头来做第 2 个版本，犯错的机会将大大减少。 测试、测试、反复测试 建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。 最重要的是，让用户进行测试并且同用 户一道保证选择的数据类型满足商业要求。 测试需要在把新数据库投入实际服务之前完成。 检查设计 在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。 换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。 . 范式 . 规范化 本 章节 的目的就是通过详细的实例来阐述规范化的数据库设计原则。 在 关系型数据库中 中，简洁、结构明晰的表结构对数据库的设计是相当重要的。 规范化的表结构设计，在以后的数据维护中，不会发生插入（ insert）、删除（ delete）和更新（ update） 时的异常。 反之，数据库表结构设计不合理，不仅会给数据库的使用和维护带来各种各样的问题，而且可能存储了大量不需要的冗余信息，浪费系统资源。 要设计规范化的数据库，就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。 但是一些相关材料上提到的范式设计，往往是给出一大堆的公式，这给设计者的理解和运用造成了一定的困难。 因此，本文将结合具体形象的例子，尽可能通俗化地描述三个范式，以及如何在实际工程中加以优化应用。 . 数据冗余 数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。 比如说，一个部门雇员的电话不 应该被存储在不同的表中， 因为这里的电话号码是雇员 18 的一个属性。 如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。 . 规范化实例 为了说明方便，我们在本文中将使用一个 SAMPLE 数据表，来一步一步分析规范化的过程。 首先，我们先来生成一个的最初始的表。 CREATE TABLE SAMPLE ( PRJNUM INTEGER NOT NULL, PRJNAME VARCHAR(200), EMYNUM INTEGER NOT NULL, EMYNAME VARCHAR(200), SALCATEGORY CHAR(1), SALPACKAGE INTEGER) IN USERSPACE1。 ALTER TABLE SAMPLE ADD PRIMARY KEY (PRJNUM, EMYNUM)。 Insert into SAMPLE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(100001, 39。 TPMS39。 , 202020, 39。 Johnson39。 , 39。 A39。 , 2020), (100001, 39。 TPMS39。 , 202020, 39。 Christine39。 , 39。 B39。 , 3000), (100001, 39。 TPMS39。 , 202020, 39。 Kevin39。 , 39。 C39。 , 4000), (100002, 39。 TCT39。 , 202020, 39。 Johnson39。 , 39。 A39。 , 2020), (100002, 39。 TCT39。 , 202020, 39。 Apple39。 , 39。 B39。 , 3000)。 表 11 考察表 11，我们可以看到，这张表一共有六个字段，分析每个字段都有重 19 复的值出现，也就是说，存在数据冗余问题。 这将潜在地造成数据操作（比如删除、更新等操作）时的异常情况，因此，需要进行规范化。 . 第一范式 参照范式的定义，考察上表，我们发现，这张表已经满足了第一范式的要求。 因为这张表中字段都是单一属性的，不可再分； 而且每一行的记录都是没有重复的； 存在主属性，而且所有的属性都是依赖于主属性； 所有的主属性都已经定义 事实上在当前所有的关系数据库管理系统（ DBMS）中，都已经在建表的时候强制满 足第一范式。 因此，这张 SAMPLE 表已经是一张满足第一范式要求的表。 考察表 11，我们首先要找出主键。 可以看到，属性对 Project Number, Employee Number是主键，其他所有的属性都依赖于该主键。 . 从一范式转化到二范式 根据第二范式的定义，转化为二范式就是消除部分依赖。 考察表 11，我们可以发现，非主属性 Project Name部分依赖于主键中的Project Number。 非主属性 Employee Name， Salary Category和 Salary package都部分依赖于主键中的 Employee Number； 表 11 的形式，存在着以下潜在问题： 1． 数据冗余：每一个字段都有值重复； 2． 更新异常：比如 Project Name字段的值，比如对值 TPMS了修改，那么就要一次更新该字段的多个值； 3． 插入异常：如果新建了一个 Project，名字为 TPT, 但是还没有 Employee加入，那么 Employee Number将会空缺，而该字段是主键的一部分，因此将无法插入记录； Insert into SAMPLE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(100003, 39。 TPT39。 , NULL, NULL, NULL, NULL) 20 4． 删除异常：如果一个员工 202020, Kevin 离职了，要将该员工的记录从表中删除，而此时相关的 Salary 信息 C 也将丢失 , 因为再没有别的行纪录下 Salary C 的信息。 Delete from sample where EMYNUM = 202020 Select distinct SALCATEGORY, SALPACKAGE from SAMPLE 因此，我们需要将存在部分依赖关系的主属性和非主属性从满足第一范式的表中分离出来，形成一张新的表，而新表和旧表之间是一对多的关系。 由此，我们得到： CREATE TABLE PROJECT ( PRJNUM INTEGER NOT NULL, PRJNAME VARCHAR(200)) IN USERSPACE1。 ALTER TABLE PROJECT ADD PRIMARY KEY (PR。