一、行业分析以及人才培养目标
在当今这个信息爆炸的时代，人们越来越为在浩如烟海的资料中寻找有用信息而烦恼。特别是随着网络和电子商务的发展，面对越来越多的信息和数据，需要对其进行妥善保存及有效管理，这都需要大量的数据库管理员。随着信息系统数据库应用的重要性日益凸显，对从事数据库系统维护和数据库开发的技术人员的需求与日俱增，对其专业能力的要求也不断提高。
根据廊坊职业技术学院（以下简称“我院”）计算机科学与工程系计算机应用技术（软件开发方向）专业的人才培养目标，需要培养具备较强的软件开发、管理、维护等方面的能力，使学生成为精操作、能实践、懂管理、会维护的高素质高技能应用型人才。这些学生所面向的工作领域主要有：软件开发、软件运行维护、网站开发和数据库管理与维护等。这些岗位都需要具备数据库的相关知识和操作能力，因此数据库课程是本专业的基础课程。
二、课程建设的性质、定位与目标
数据库课程是一门专业基础课程。它的前导课是“计算机导论”“程序设计基础”，前导课为本门课程奠定了计算机基础操作能力和基础程序设计能力，它是“Web应用开发”“综合实训”等后续课程在后台数据库开发、管理、维护方面能力培养的重要途径，数据库课程为专业培养目标的实现起到了承上启下的作用。
数据库课程的总体目标是掌握数据库的理论知识，具备数据库的实际操作能力以及培养数据库管理的职业素质。具体来说，包括知识目标、能力目标和素质目标，其中知识目标是了解掌握数据库的原理等理论知识；能力目标是建立、管理和维护数据库；素质目标是通过小组学习形成团队意识，通过维护数据库安全，形成不恶意破坏数据库数据，不危害他人数据库的良好职业道德。
三、课程建设的理念与思路
高等职业教育培养什么人和怎样培养人，这是一切课程建设的基础。高职教育是培养生产一线的高技能应用型人才的教育。高职教育必须与岗位结合，必须与真实的工作任务和真实的生产过程相结合。数据库课程开发建设的指导思想是：以校企合作为基础，跟进主流技术，改革课程内容。以我院计算机科学与工程系为例，本系一直与相关计算机科技企业合作，根据技术发展，企业需要改革相关课程内容，本门课程经历了从最初的VFP到SQLSERVER到ORACLE再到MYSQL＼ORACLE的三次变革，适应了软件开发行业对数据库技术的要求。
课程内容选取和内容组织安排以专业的培养目标、服务领域、课程性质为依据，以岗位能力为核心，进行课程定位。通过对目前计算机行业，特别是一些网络公司的广泛调研，根据企业对技能型人才在素质和技能方面的要求，对本门课程的培养目标进行了重新定位。通过本门课程的学习，使学生具有较强的岗位能力，使学生的团队协作能力、收集处理信息能力、分析和解决问题的能力等各方面的培养都得到加强。专业技能达到能够进行分析、设计、开发和管理数据库的培养目标。
教学模式及教学方法设计的总体思路是整合理论，突出实践，实施任务驱动教学。对理论教学内容进行合理的整合和更新。将学术为主而在实际设计开发中无用的内容进行了大胆删减。同时将网络数据库的实践开发技术，如整体设计建设一个网络数据库纳入到教学内容中。实践教学内容由原来的了解认识已有的数据库改为设计开发新的数据库，实施任务驱动教学，强调动手，重视实训，充分体现了实践教学与社会需求的结合。
四、课程面对的学生基础及其智能特点分析
本课程所面对的基本学情是：学生的学习态度大都比较端正，其中约15%的学生（主要是职高对口生）相关知识基础好，在高中阶段系统地学习过数据库，有良好的学习方法，但对再次学习数据库兴趣一般；65%的学生，基础一般，对数据库的接触了解不多，但有一定的学习兴趣；大概20%的学生，基础差，不仅对数据库完全不了解，先修课程如“程序设计基础”等也没学好，几乎没有学习方法，对学习和程序设计看起来很相似的数据库没有兴趣。
通过学情分析，得出学生在学习过程中遇到的困难主要分为三类：基础好、学过数据库的学生在学习简单知识时，感觉听课没有热情，操作没有动力；大部分课程，大部分学生在听课时都能听懂，但自己动手时又往往想不到如何运用学到的知识，操作大都困难；基础不好的学生面对难度较大的内容，听课时产生畏难情绪，操作时不敢下手。
针对学情以及课程特点，在教学过程中我们指导学生采用以下学法：当课程难度较小时，为激发学生的学习热情，引导学生采取一题多解以及给自己出提高题，争取自己难倒自己的学习模式，即多样求解，自我设计；当课程难度适中时，为解决学生能懂不能做的情况，引导学生加强操作，边做边探索，也可与其他同学多交流，把别人的知识真正变成自己的，即自主探索，合作交流；当课程难度较大时，为便于理解，以联系实际学习，化难为简，与学生交流互动，启发学习，即联系实际，交互启发。
五、课程内容的选取以及教学组织安排
本课程内容选取立足于学习与工作的一致性，学习对未来工作的适应性，以工作任务整合、设计学习任务。参照企业的要求以及相关培训资料来进行课程教学，以校企合作为依托，跟进主流技术。
通过课程组教师深入、系统的分析，将教材中的章节重新编排，将教学内容总体安排为：数据库整体概述、OracleSQL和PL/SQL三大单元。其中，数据库整体概述单元要求学习了解数据库发展历史，熟悉数据库开发环境，安排8学时；OracleSQL单元要求学习掌握select（子查询、多表查询、过滤排序等）、create（table、view、index等）、insert、update、delete、drop等查、建、增、改、删操作，安排72学时；PL/SQL单元要求学习掌握基本语言、流程控制、游标、函数、包、触发器等，安排40学时。加机动8学时，共128学时。
六、课程采用的教学模式以及教学方法手段
1.教学模式采用任务驱动模式。首先由教师描述任务，进行分析，得到解决方案，实施方案，然后进行知识小结，归纳总结出方法，再拓展相类似的任务，进一步熟悉掌握。这个过程是教师引导操作，这是学习知识、培养能力的过程。对拓展的任务再进行分析、解决、实施、总结，要运用教师指导的学法（难度小的多样求解，自我设计；难度适中的自主探索，合作交流；难度大的联系实际，交互启发）由学生独立完成，这是能力深化、知识循环的过程。总体来说，模式是：教学中，边教、边学、边练，教师是导航员；实训中，边练、边学、边教，教师是答疑师。
2.教学方法主要采用以下三种。（1）“案例”教学法。在讲授新课时，为了激发学生的学习兴趣，实施“案例”教学法。实施过程是：先举一个生活中的相关实例，进而分析在生活中的解决方法，然后探讨在数据库中的解决方法，最后在数据库中进行操作，这样使得新知识容易懂，记得牢。例如，在讲授多表查询时，先举水果店，计算利润的例子。利润=销售-成本，那么需要查询进货单和销售记录两表的信息，这样引出数据库多表连接查询的概念，进而分析查询语句。（2）“任务驱动”教学法。在实训操作时，为了能提高实训效率，实施“任务驱动”教学法。实施过程是：上课后，先通过教学软件发任务要求，一般题目在3～5个之间，分必答题和提高题；然后规定完成时间，一般要求在10分钟内做完必答题；到时间后上交或抽查完成情况，最后讲评。这样使学生有操作的紧迫感，在短时间内完成也有成就感。例如，在练习操作逻辑判断（case）语句时，先发三道题目，两道必答，一道提高；10分钟后，大部分学生完成必答题，部分学生同时完成提高题；然后就完成情况讲评，若无大问题，继续发下一轮题目。（3）“小组讨论”教学法。在巩固提高时，为了循环知识、深化能力，实施“小组讨论”教学法。实施过程是：在布置任务前，首先进行分组；然后以组为单位进行任务作业讨论，得到答案；由教师抽选每组一名学生进行汇报，最后给定全组分数。这样使得学生重视团队，爱钻研学习。例如：分组后，出一道查询题，说明此题5分，小组讨论分析后，由教师抽选的一名学生汇报答案，解答正确得5分，多种解答加倍得分，两种得10分，三种得15分，最后给定全组的分数。
3.考核评价体现多元化、立体化、职业化。将总成绩分为课上表现（占5%）、职业素质（占5%）、实验实训（占20%）和期末考试（占70%）。课上表现主要考核出勤纪律和学习的积极主动性，由教师评价；职业素质主要考核职业道德和团队意识，由教师和其他学生共同评价；实验实训的任务作业和实训报告大部分由企业提供，由教师和企业共同评价；期末考试以30%的笔试理论+70%的上机实践组成，上机实践题目源于企业培训中心的试题库，由企业主体、教师辅助评价。整体考评重视实践操作，体现校企合作，凸显岗位能力。
七、课程所需的教学条件
1.课程对师资方面的要求。需要任课教师专业基础扎实，有丰富的教学经验；具有开发网络数据库的实践工作经历，有较强的操作技能，需要构建专兼结合的双师型教学团队。
2.课程对校内外实训方面的要求。在校内，需要充足的多媒体教室和机房实训室，以满足教学的需要，满足数据库的实验实训需要，并保证实验实训顺利进行；在校外，需要与相关企业达成实习基地、科研合作以及培训等协议，保证学生有充分的条件进行顶岗实习等实践技能的训练，满足工学结合的需求。
3.课程对学习资源方面的要求。在教材方面，选择优秀、实用性强的数据库教材；从数据库领域的基础知识入手，保证学生无数据库基础也能学会；配有相关的例题和实训，注重学生动手能力的培养。在软件方面，既要考虑企业里实际软件的使用情况，也要考虑多媒体教学以及学生实训的要求。在参考资料方面，为与实际工作相衔接，补充建议学生学习企业的相关培训教程，创建适应工作实际情况及学生实际情况的试题库。在网络资源方面，可采用QQ进行课下网上答疑，对学有余力的学生，介绍其一些网上的数据库教学资料和视频，如数据库部级精品课网站、数据库网络视频、数据库学习网等。
八、课程开发特色及创新
1.校企合作，共建课程。课程情景资料、电子教案等文本，开发工具、试题库等软件以及实训均以企业的资源为蓝本，校企合作，共建课程。
2.任务驱动，贯穿始终。课程内容贴近实际，整个实训操作以一个典型的数据库系统为例展开，按实际工作任务，以工作任务为导向，整合和优化教学内容，内容新颖，实用性强。
考虑性能的时机
考虑应用程序和数据库各自不同的性能特征的时间，是在对这些应用程序和数据库进行设计的初始阶段，即开发过程的一开始。对你的DB2应用程序和数据库所需要的资源进行合理评估，将会帮助用户在开发过程的早期对设计和实现做出适当的决定。如果你的应用程序访问数据库的性能直到后来才被说明，那么就要做必需的修改以获得足够的响应时间，并处理你的批处理窗口；这将会变得更加困难，并且消耗时间。
关注焦点
当设计性能的时候，将大部分的精力集中在重要的DB2数据和程序上是很明智的做法。对应用程序或者事务进行定义是这部分工作中的重点，以下一个或者多个特点是适用的：
它们表现了所有业务工作量中的大部分
它们有一个很关键的响应时间需求
它们包括了复杂的逻辑和/或数据访问需求
它们访问大量的数据
它们消耗大量的资源
它们直接与客户进行交互（通过网络、ATM等），与此相反，应用程序大多面向公司内部
数据库设计
数据库设计发生在以下两个阶段：
数据库逻辑设计
数据库物理设计
数据库的逻辑模型只是所有用户数据需求规格化的形式表现。这个模型通常是数据建模阶段的输出或者是最终结果。它很少在实际意义上被实现。更何况，在考虑如何在数据库管理系统中实际地组织和存储数据之前，它只是数据的一个理想化的视图。
当考虑到特定数据库对象的体系结构的时候，逻辑模型才会转化为物理模型。在这一设计阶段，才需要考虑到数据访问需求和性能因素的一些细节。在进行物理设计的过程中，两个关键的因素是表设计和索引设计。这两个问题将会在下面进行详细讨论。
DB2性能管理的方式
为了确保你的DB2应用程序有足够的性能，采取积极的态度总比消极应对有意义得多。在DB2数据库设计的早期阶段总结出性能因素是至关重要的。然后在项目中，努力尽早地确定满足你的服务级别协议（SLA）的性能“基线”的测量标准，这样你就可以在首次演示和应用程序变更的时候追踪性能特点及其发展趋势。不断地监测你的DB2系统和应用程序，以便在大多数的问题成形之前预见到它们。
传统意义上，许多客户都是直到应用程序开发项目的最后阶段才开始关心性能问题。但是这样的等待是毫无益处的。早在描述用户界面和处理逻辑的阶段就去思考数据库设计的性能特点，是比较有好处的。例如，在你的重要的DB2工作（见前面所述）中，创建最好的索引的一个基本的指导就是对SQL语句中的谓词的考虑。
即使是你开发出的最初设计是一个有效的设计，但是以下的若干修改仍然是必要的，例如对你的应用程序进行修改，或者数据库以卷的形式增长，或者是限制系统资源。如果现有的应用程序没有充分的运行，那么通常情况下你都会希望最好能够在现有的索引上面添加更多的列，或者在表上添加新的索引。不论改变表的设计，或者修改客户的需求，还是使表非标准化，通常情况下都不是好的选择。
理解DB2性能单凭经验的方法
单凭经验的方法（又叫做ROT）在进行计划、监测，以及对DB2的性能进行优化时是很有用处的。ROT典型地基于以前的经验（例如，长时间的观测平均水平），或者是基于对比较复杂的公式进行简化。
记住下面这一点是很重要的，ROT对于粗略的估计有用，但是进行详细分析的时候就不行了。只是因为这些经验出现在某些文章中，就把它们作为性能的精确引证是很危险的。最好的情况下，它们是估计值；在最坏的情况下，它们对于你特定的DB2环境来说就是无效的。
ROT应该在你的环境中得到（或者是对其进行调整，使其适应你的环境）。它们应该与你的实际经验相联系，而不是被盲目接受，这样你才会对它们的值有信心。从那些在你的特殊环境之外得到的ROT开始也许会有些帮助。但是当你从你的DB2系统中收集、分析、记录了合适的数据之后，就需要对这些经验值进行校正或者修改。IBM的红皮书是一本有关ROT的值得阅读的资源，里面含有许多关于性能监测工具的推荐经验。
另一个要考虑的事项就是ROT需要持续一段时间。随着硬件技术的发展，软件编码的改进，系统的体系结构发生了变化，这使得ROT更加不可靠，甚至是完全错误的。随着时间的发展，使ROT发生改变的最大因素恐怕就是最新发布的DB2自身了。
DB2工作量
磁盘I/O通常是影响响应时间的最大因素，但是，通过查看GETPAGE(GP)需求可以更容易地看到潜在的性能问题。当监测DB2的活动并进行报告分析的时候，GETPAGE的数量很可能就是显示DB2整体工作情况的最好的指示器。
大部分的DB2安装工作可以分为以下几个较清晰的类别：
事务：这是运行在事务管理器控制之下的程序，例如CICS和IMS/TM。SQL通常比较简单，但是事务卷是很繁重的。事务必须为用户提供非常及时的响应时间，这样应用程序才不会被迫等待很长的时间以获得所需的资源。通常是第一个用户调用事务时才会产生读取索引和数据页的I/O开销。随后的用户可以在缓冲池中访问部分资源。
查询：这是通常情况下为决策支持运行的程序。其中的SQL也许十分复杂，但是卷通常要比事务的卷轻松许多。查询用户通常需要等待几分钟，甚至是几个小时，具体时间依赖于产生用户需要的结果集所查询的数据量。查询通常会调用针对整个表的扫描，并且对结果排序也是此类工作量的另一个常见特点。
批处理和实用工具集：批处理和实用工具集程序需要处理大量的数据，并且通常是以顺序的方式处理数据。在特定的窗口中结束处理对于这些程序来说是很重要的。多次使用位置正确的COMMIT（提交）语句是这些应用程序具有的一个很重要的特点。批处理和实用工具集通常需要消耗大量的各类资源，进行压缩的时候，通常可以逐步提高工作量。
标准化
标准化是应用程序进行数据实体分析的标准化过程，最终将把数据实体转换为一系列经过良好设计的结构体。通常，逻辑数据模型的设计目标是正确性、一致性、没有冗余和简单化。而且，关系理论原则也需要数据库进行标准化。
还有几条连续编号的规则，被称为范式，它可以相当详细地定义标准化数据。我在这里并不详细讨论这些规则。大多数的专家都会建议设计者们尽力遵循前三条的规则，因此这样的数据可被称为遵循第三范式。
对表进行非标准化的意思是，对一个先前遵守范式的表进行修改，使其违反一条或者多条范式规则。有时候，由于性能的原因，确实需要进行这个非标准化的过程。有关标准化的更进一步的详细信息，你可以在大多数的讲述关系数据库的书籍中找到。
DB2表空间的类型
在定义DB2数据库的时候，实际的表必须在被成为表空间的DB2对象中进行创建。用户可以在DB2中定义四种不同类型的表空间，如下所示：
单一：一个单一的表空间可以包含多于一个的DB2表。这个空间由多个页组成，每个页都可以包含若干行，它们可能是来自表空间中定义的任何表的数据行。
分段：分段表空间可以包含多于一个的DB2表。这个表空间由多组页组成，每组页被称为一个段。每个段包含来自表空间中定义的某一个表的若干行。
分区：分区表空间只可以包含一个表。这个空间根据分区索引的关键值范围被划分成多个区。每个分区都作为一个独立的实体对待，允许SQL和DB2实用工具集的并发处理。
LOB：LOB表空间只存储LOB（大对象）数据。LOB包括了3个数据类型：BLOB（二进制大对象）、CLOB（字符型大对象），以及DBCLOB（双字节字符型大对象）。
表空间和表设计考虑事项记录尺寸和页尺寸
固定长度的记录比可变长度的记录要好，因为处理固定长度记录的DB2的代码经过了优化。如果记录是固定长度的，那么它就永远不需要从原来存储的页中被移动出来。然而，可变长度的记录可能增长到不再适合原来页的长度，因此它也就必须被移动到另一页。无论何时记录被顺序访问，都一定会出现一个额外的参考页。DB2UDBV8中的一个新特性就是当你不确定未来的数据长度增长情况时，允许你根据需要改变列的尺寸，这样你就可以不再需要创建可变长度的记录。
每页中记录的数量也是需要考虑的内容。DB2提供了一些有关页尺寸的选项，例如4KB,8KB,16KB和32KB。比较好的起点是选择默认的4KB，特别是当行的尺寸相对较小，或者是对数据的访问比较随机的情况下。然而，在一些情况下，也需要考虑较大的页尺寸。如果表中单个行的长度超过4KB，那么你就需要使用大一些的页尺寸，因为DB2不支持跨行的记录。
还有另一种情况是，当固定记录的总长度比二分之一的页（4KB）稍大一些的时候，一页中就只能放置一个记录。另外一种类似的情况是，固定记录的总长度略长于三分之一页、四分之一页，等。这样的设计不仅会浪费DASD空间，还会导致很多的DB2操作消耗更多的资源。因此，对于上面描述的记录而言，你需要考虑使用较大的页尺寸，这样就会相对地少浪费一些空间。
另外一些可能的页尺寸为8KB,16KB和32KB。页的尺寸并不在创建表（CREATETABLE）的语句中直接写明。相反，表中页的尺寸是由分配给包含这个表的表空间的缓冲池中的页尺寸决定的。要获得更详细的信息，你可以参考DB2SQL手册中有关创建表空间（CREATETABLESPACE）语句的内容。
非标准化考虑事项
逻辑数据模型是数据的一个理想描述。物理数据模型则是数据在现实世界的实现。标准化只集中在数据的内涵上面，而不考虑可能访问数据的应用程序的性能需求。数据库设计的充分标准化会带来性能的挑战。
有关此类性能问题的一个非常常见的例子就是连接操作。通常情况下，标准化过程的结果是给各个独立的表赋予相互关联的信息。应用程序需要从这些表中访问数据。关系数据库提供了使用SQL语句来从多于一个的表中通过连接多个表去访问信息的能力。取决于表的数目和它们各自的尺寸，连接操作可能会消耗非常多的资源和时间。
因为在I/T中有如此多的事情需要考虑，于是出现了一个折中的想法。对那些包含被频繁访问列的多个表中的数据保存副本，与连接表的性能相比，成本高还是低呢？在逻辑数据库设计过程中，对你的数据模型尽量的执行标准化，之后再对其进行一定程度的非标准化，也许是进行潜在性能优化的一个选项。如果你决定进行非标准化了，要确保从头到尾地记录了文档：对某些细节的描述、执行非标准化步骤之后的推理，等。
设计较大的表
访问很大的DB2表需要消耗相当多的资源：CPU，内存，I/O。当设计大表的时候，用户需要做的两件最重要的事情就是：
实现分区
创建有用的索引
以上两个问题将在下面进行详细讨论。
使用分段或者分区表空间
如果数据中包含了LOB，那么用户就必须创建LOB表空间。对于非LOB的数据，通常的选择是分段或者分区表空间，具体选择哪一个在很大程序上取决于你要存储的数据量，同时还需要考虑相关应用程序需求的数据访问类型。不太推荐使用单一的表空间。
分段表空间比单一的表空间具有更多的性能优势，如下所示：
对于包含多于一个表的表空间，当DB2在一个表上获得锁定时，那个锁定不影响其他表分段的访问。
当DB2扫描一个表时，只访问与那个表相联系的分段。此外，空分段的页不会被取出。
如果一个表被清除了，不需要执行REORG实用工具集，它的分段就立即在COMMIT点上变成可再次使用的状态。
如果一个表中的所有行被删除了（被称为块删除），不需要执行REORG实用工具集，所有的分段都立即在COMMIT点上变成可再次使用的状态。
块删除操作起来更加有效，并且书写相当少的记录信息。
COPY（复制）实用工具集不复制由于块删除或者表清除所造成的空页。
当表达到一个特定的尺寸，它们的可管理性和性能都可以通过分区表空间获得改善。如果你想获得这方面的进展，在设计和创建时，以分区的形式定义表空间是一个明智的做法。分区表空间的一些潜在优势列举如下：
并行性：你可以利用三种类型的并行性，它们目前正应用于DB2UDB。DB2V3引入了查询并行性（多个I/O路径）。DB2V4则实现了CP并行性（多CP之上的多任务）。DB2UDBV5更是引入了系统查询并行机制（多个DB2数据共享群之上的多任务）。DB2的发展进化，显著提高了DB2应用程序处理分区表空间的并行处理能力。由于CPU时间的增加，这些查询所消耗的时间也显著的减少了。
在数据的一部分上工作：分区表空间允许DB2应用程序一次运行数据的一个分区，因而使其能够同时运行另外分区上的另外的工作或者应用程序。以同样的方式，你可以将块UPDATE（更新）、DELETE（删除）或INSERT（插入）操作分解为独立的工作。除增加了可用性之外，这一技术也为完成这类DB2工作减少消耗的时间提供了可能。
更快的访问被频繁访问的数据：如果分区索引能够将更多的频繁访问的行从剩余的表中分离出来，然后将那些数据置于一个它自己的，并且应用更高速DASD设备的分区之内。
一般而言，表越大，就越应该将其创建为一个分区的表。但是也有一些实际例子表明为小表创建分区表空间是有利的。当查找表用于连接其他大分区表空间时，通过将查找表分区，你能够使并行性在连接中最大化。
当你在连接谓词中利用分区方法时，需要考虑一个决定性的因素。被连接在分区方法上的表应该具有相同的分区数，并且应该设定为相同的值。
数据压缩DB2提供了压缩表空间或分区内数据的功能。通过指定CREATETABLESPACE（创建表空间）语句中的COMPRESSYES（压缩许可）选项，之后在表空间上同时执行LOAD或REORG实用工具集，即可完成该功能。数据的压缩是通过用更短的串来替换频繁出现的字符串实现的。系统还创建了一个字典，包含了原始字节串和它们的替代串之间的映射信息。
一定数量的CPU资源被用于在执行数据存储对其进行压缩，之后，当外部存储设备读取时，数据又被解压缩。然而，数据压缩也能够提供性能方面的好处，因为更多的数据存储在更小的空间内（在DASD上和缓冲池中）；同未经压缩的数据相比，这样可以产生更少的同时读取、更小的I/O等。
接下来是当试图决定是否压缩一个表空间或分区时，需要考虑的一些事情：
行的长度：行越长（尤其是在接近页的尺寸时），压缩的有效性就越低。DB2的行不能够跨页，当一页上有多于一行的情况时，你也许不能获得足够的压缩。
表的尺寸：对于较大的表，压缩具有较好的效果。对于很小的表，压缩字典的大小（8KB到64KB）可能会抵消压缩节省下的所有空间，
数据中的模式：对于一个特定的表空间或分区，数据中重复出现的模式的频率，决定了压缩的效果。含有大量重复字符串的数据能够获得显著的压缩效果。
压缩估计：DB2提供了一个单独的实用工具集，DSN1COMP，它可以用来测定数据压缩将有怎样的效果。想获得有关运行该使用工具的额外信息，请参考DB2实用工具集指南和参考手册。
处理成本：在压缩和解压缩DB2数据时，会消耗一些CPU资源。如果你用IBM的同步数据压缩硬件特征，所消耗的CPU资源将比利用DB2软件仿真程序低得多（当DB2启动时，这决定了硬件压缩特征是否可用）。
更好的字典：当用LOAD使用工具集来建立压缩字典时，DB2用户用最初载入的n行（n取决于你能够压缩的数据量）来决定字典的内容。REORG采用取样技术来建立字典。它不仅使用最初载入的n行，还在实用工具执行UNLOAD（未载入）阶段的剩余时间里继续对数据行采样。
通常情况下，我们推荐你在自己的特定环境下，压缩那些DB2表空间和分区，这将会使你的环境受益；因为在更小的空间内存储更多的数据的性能优势，几乎总是在价值上超过压缩和解压缩数据所消耗的CPU资源。
1背景分析
目前，产品化的数据库管理系统是以关系型数据库为主流，技术相对成熟。面向对象的数据库管理系统尽管技术上处于先进，数据库易于研发、维护，但至今为止，还没有成熟的产品。占主导位置的关系型数据库管理系统包括ORACLE、SYBASE、SQLServer、INFORMIX与INGRES，这些产品都支持UNIX、VMS、WINDOWS等不同平台，但支持的程度不一样。
通常系统的设计与研发阶段，设计人员、研发人员与测试人员仅会把工作重点放在系统的功能实现上，而此时因为测试数据较小，难以衡量系统的运行性能的优劣，然而如果系统进入实际运行阶段，大量的业务数据通常会使系统的性能逐步降低，此时再来考虑怎样提升性能则会花费更多的人力及财力。所以，设计出高质量的数据库结构就变得特别关键。
2数据库服务器选择
对于占主导位置的SQLServer、Oracle、SYBASE、DB2和INFORMIX数据库，分别从性能、运用风险、开放性、易维护性与价格等方面来分析比较。
2.1性能
SQLServer老版本服务器多用户时性能较差，新版本的性能有了显著的提升，各项处理能力都有了显著的提升，占有数项TPC-C（事务处理性能委员会）纪录，并支持集群。Oracle数据库性能最佳，占有WindowsNT平台下的TPC-D（基准测试，衡量联机事务处理系统的一个测试指标）及TPC-C的世界纪录。SYBASE数据库性能较好，满足Sun、IBM、HP、Compaq及Veritas集群设施的性能，达到高可用性；性能比SQLServer稍差，然而在UNIX平台下的并发性要高于SQLServer，适用于安全性要求较高的应用系统。DB2适合于数据仓库与在线事务处理，性能较好，支持胖客户端和应用模式。INFORMIX性能较好，支持集群，达到高可用性，适用于安全性要求极高的应用系统，特别是在金融业、证券行业的应用。
2.2运用风险
SQLServer属于完全重写的代码，性能及版本兼容性有了较大的改善，同Oracle、DB2的性能差距显著减小。该产品的产生经历了大量用户长期的测试，对产品的安全及稳定进行了全面的检测，安全稳定性有了显著的改善。Oracle长时期的研发经验，完全向下版本兼容，基本没有风险。能够安全的进行系列产品的升级，在企业、政府中获得普遍应用。而且假如在WINNT平台上不能满足数据的要求，能够安全的将数据转移到UNIX平台上来。SYBASE向下版本兼容，然而ct-library程序不易移植。研发周期较长，升级较为复杂，稳定性较佳，数据安全有保障，风险较小。在安全要求极高的金融、证券领域获得了普遍应用。DB2在巨型企业获得普遍的应用，向下版本兼容性较好，应用风险较小。INFORMIX研发周期较长，升级较为复杂，稳定性较佳，数据安全有较高保障，应用风险较小。在安全要求极高的金融、证券领域中获得了普遍应用。
2.3开放性
SQLServer仅能在Windows平台上部署、运行，C/S结构，操作系统的稳定对数据库是非常关键的。仅支持Windows平台，能够用ADO、DAO、OLEDB、ODBC、JDBC等网络数据库连接技术沟通。Windows平台的可靠性和安全性通过了最高级别的C2认证，在处理大数据量的重要业务时具备较好的性能。Oracle能在所有主流平台上部署、运行（包含Windows），完全支持目前所有的工业标准。利用完全开放策略，可以进行多层次网络计算，对多种工业规范提供支持，能够用ODBC、JDBC、OCI等网络数据库连接技术沟通。能够使客户选用最适合的解决方案，对开发商完全支持。SYBASE能在所有主流平台上部署、运行，C/S结构，能够用ODBC、JDBC、Jconnect、Ct-library等网络数据库连接技术沟通，在金融业中获得了普遍的应用。但因为早期Sybase同OS集成度不高，所以VERSION11.9.2以下版本需要较多OS及DB级补丁，在多平台的混合环境下会产生一定问题。DB2能在所有主流平台上部署、运行（包含windows）。有较佳的开放性，最适于海量数据。支持跨平台能力和多层结构，支持ODBC、JDBC等类型应用系统，在大型的国际企业中获得最为普遍的应用。IINFORMIX仅运行于UNIX平台，包括SUNOS（Sun的操作系统最初称呼）和HPUX（HewlettCPackardUNIX的缩写，属于惠普公司的UNIX操作系统），在金融业获得普遍的应用。
2.4易维护性与价格
SQLServer从易维护性与价格上SQLServer占有较大优势。基于Microsoft产品的一贯风格，SQLServer的图形管理界面导致了显著的易用性，微软的数据库管理员培训工作相对充分，能够轻松的找到技术较好的数据库管理员，数据库管理费用相对低，SQLServer的价格也是较低的。Oracle从易维护性与价格体来说，Oracle的价格是相对高的，管理相对复杂，因为Oracle的应用相当普遍，经验丰富的Oracle数据库管理员能够相对容易的找到，因而实现Oracle的良好管理。所以，Oracle的性价比在商用数据库中是最佳的。SYBASE的价格是相对低的，然而SYBASE的在企业及政府中的应用较少，较难找到经验丰富的管理员，运行管理费用偏高。DB2价格较高，管理员较少，在中国的应用相对少，只在金融业获得一定应用，运行管理费用都非常高，比较适用于大型企业的数据仓库应用。INFORMIX价格在这些数据库服务器中居于中间，同SYBASE类似，在企业及政府中应用相对较少，只在金融业获得了普遍的应用。经验丰富的管理人员偏少，运行管理费用偏高。
3数据库设计
数据库结构设计在该数据库管理系统研发过程中占据非常关键的地位，下面从数据库设计原则、数据库设计方法与步骤、逻辑数据模型设计等三方面简述该数据库管理系统数据库设计。
3.1数据库设计原则
该数据库管理系统的数据库参照以下设计原则：
（1）数据库设计要达到标准化与规范化。数据结构的标准化与数据关系的规范化有助于消除冗余数据。
（2）表中数据类型的合理化。合理的数据类型有助于提升该数据库管理系统数据库的运行性能。
（3）数据表命名的规范化。每个关系型数据库对数据表的命名都有一定要求，在对数据表命名时利用大小写敏感的形式，而且数据表命名长度不应过长，这样能够使该数据库管理系统可以应用在多个不同的数据库平台。
（4）数据库性能的完善。在运行环境已经固定的因素下，数据库的性能成为影响该人事数据库管理系统运行性能的主要条件。可以利用两个步骤开展数据库设计：先是进行逻辑设计，而后进行物理设计。逻辑设计要求消除所有的冗余字段，可以完整地说明数据库表之间的关系。然而对于多表之间关联的查询，去除所有冗余会损耗系统性能，也会增大系统研发难度。因此，找到一个平衡点成为数据库设计的关键，在物理设计中开发人员要分析关联数据表的数据量大小与访问频率，并对数据表中用来关联查询的关键字段留存适当的冗余，以提升数据库的性能。
3.2数据库设计方法与步骤
数据库的建设分成概念数据模型设计、逻辑数据模型设计与物理数据结构设计等三个阶段，其目的是达到合理的数据表结构，使数据的存取操作更为有序，数据的编辑、查询更为方便，从而实现该数据库管理系统数据库的建设。
（1）概念数据模型设计。概念数据模型反映的是系统最终用户对于数据存储的观点，代表了系统用户综合性的信息需求，它用数据类的方式表达企业级的数据需求，数据类描述了在业务环境中聚集起来的几个重要的类别数据。概念数据模型包括主要的实体和实体之间的关系。描述概念数据模型最常用的是“实体-关系”图（即E-R图），E-R图主要是由实体、属性及关系等三个要素组成的。
（2）逻辑数据模型设计。逻辑数据模型是指系统分析师、设计师对数据存储的见解、看法，是对前一阶段概念数据模型的分解与细化。逻辑数据模型是按照业务规则决定的，是业务对象、业务对象的数据项以及业务对象之间关系的描述。逻辑数据模型包括所有的实体与关系，决定每个实体的属性，指明每个实体的主键和外键。
（3）物理数据模型设计。物理数据模型是对真实数据库的表达。数据库对象包括表，视图、字段、数据类型、长度、主键、外键、索引以及是否可为空，还有默认值。概念数据模型到物理数据模型的转换是将概念模型中的对象转换为物理模型的对象。
4总结
开发数据库管理系统时，一个优秀的数据库服务器的选择和好的数据库结构设计起到举足轻重的地位。SQLServer属于微软公司研发的大型关系型数据库系统，功能相对全面，效率较高，管理与操作比较简单、方便，整个系统的安全及稳定也较高，并且性能价格比最好，节约企业资金，降低研发成本，是开发人员理想的选择，能够作为中型企业或单位的数据库平台。数据库结构设计在数据库管理系统研发过程中同样占据非常关键的地位，一个好的数据库结构是该数据库管理系统的基础，数据结构设计的优劣将直接影响到该系统的效率以及所要达到的效果。
1、课程指导思想
传统的课程内容陈旧而死板，侧重知识的罗列，实践案例少，并且与实际工作应用脱离，提不起学生兴趣。结合“sql数据库设计”这门课程的实际情况，我们的研究思路及重点是“培养学生的实际操作能力”，具体如下：
一是教学目标重心迁移，即从理论知识的存储转向职业能力的培养，导致教学方法逐渐从“教”法向“学”法转移，实现基于“学”的“教”。
二是教学内容重心迁移，即从知识的罗列、灌输转向动手操作、边做边学，利用项目案例，根据工作过程和知识点分布将其分解成若干个可操作性强的小项目，导致教学内容逐渐从“理论知识”向“实践应用”转移，实现基于“技能”的“传授”。
2、课程采用的教学方法
为培养学生的动手操作能力，在教学上，采用“项目”教学法，教师选取一个网站系统的数据库项目，教师分析和演示项目，然后学生对项目进行讨论；接着正式实施项目；然后演示项目结果，由学生阐述项目机理，教师总结归纳；最后由教师对学生的作品进行评估，并补充相关的拓展内容。通过采用项目教学法，让学生掌握数据库设计的方法，同时也学到了对应的技能点，从而将知识点融入项目训练中。与传统的教学方法相比，项目驱动教学法能更大地激发学生的学习兴趣和求知欲望，充分调动学生的学习积极性和主动性，从而培养学生自主学习、分析问题、解决问题的能力和协作、创新、探索的精神。
教师在项目教学中主要起引导作用，首先教师讲解项目背景，引入项目要求，然后由学生讨论及上机独立完成。通过这样的方法，学生在实践中思考的问题越多，学到的知识也就越多，对学习的兴趣就越浓厚，动手能力也从原来的照学变成了自主动手，培养学生的自学能力、创造能力，而这是当今社会最需要的。只有具有自学、创造能力的人才，才能在当今这个信息无限丰富的社会中立足，并能充分利用信息资源和技术，创造性地完成工作。
在实训过程中，教师充分体现学生的自主性和主体性，随时巡视，对学生解决不了的问题详细指导，以体现老师解惑的作用。在实训结束时，教师对项目及时点评，指出出现的问题及解决办法，总结所学技能点，从而巩固所学知识。
3、课程设计
本课程采用项目教学方式，以学生选课系统数据库项目为案例，课程共设计了十个项目，根据工作过程为导向设置了项目的完成顺序；同时依据各个项目涉及的知识点难度，又把项目划分了两个阶段。在本门课的教授中，让学生逐步掌握技能，最终使学生具备做数据库项目的能力。教师主要对学生进行方法上的指导为主，进而让学生进行实践。《sql数据库设计》课程内容组织如下图所示：
学生通过对上面所列的各个项目的操作练习，层层推进，逐步理解与掌握课程中操作要点，使学生最终能制作出综合数据库项目作品，达到企业要求。
4、课程评价设计
作为一门操作性和应用性非常强的课程，本课程的考核方式如果只取决于期末成绩，会使学生在平时的学习中不重视实践操作，只会在期末时突击完成任务。另外，传统考试中，以笔试为主，主要考察学生对书本知识的记忆，不利于扩大学生的知识面，忽视了对学生独立思考能力、知识的运用能力、创新能力以及其他素质的培养。
所以，在这门课的考核方式上，要把上述因素考虑进去，在期末成绩之外，平时表现也要作为考核总成绩的组成部分。因此，本课程的考评方式采用中间评价和期末评价两者综合的评价方式。中间评价占40%，期末评价占60%。
中间评价：主要由考勤、课堂任务考查、课后作业三部分组成。学生是否按时上课是学习态度问题，通过考勤登记了解学生的到课情况。在课堂项目考查中，老师检查学生每次课完成任务情况，对其完成情况进行评分。课后作业作为课堂所学技能的巩固和拓展，老师将每次课后作业收集，并进行打分和点评。每个项目的考核评价如下表：
期末评价：对学生进行综合项目评价，要求学生自行分组，在期末制作完成一个信息系统的数据库项目（如人才招聘系统、酒店管理系统等）。期末项目完成后，分组进行项目的展示与讲解：用3-5分钟的时间对本组的所做的项目进行展示与讲解。具体考核标准为：
在课堂中对《sql数据库设计》课程通过应用上面的项目教学方法进行教学，教学效果良好，学生的动手能力得到了很大提高，实现了教育部提出的高职高专教育要培养可持续发展的“技术型”人才的培养目标。学生的自主探索能力及自学能力、创造能力得到提高，在课程结束时学生能制作出数据库项目作品，适应企业的需要。
载入大表
在处理大批量数据时，将数据初始载入表中可能会对系统性能产生挑战。为了在载入过程中实现并行性，你可以手动创建多个LOAD作业，每个分区建一个；或者作为另一个选择，你可以在一个LOAD程序中载入多个分区。每个分区都延伸至I/O子系统，这种方式可以更容易地实现最理想的并行性。
为了使性能最优化，在LOAD语句中指定SORTKEYS参数也很重要。这个参数指示DB2将索引方法传递给内存中的分类程序，而不是将关键字写入或者再次读取DASD上的排序任务文件。SORTKEYS也能够实现载入和分类之间的交迭，因为分类是作为一个独立的任务运行的。
还有一些关于载入大表的额外的建议，如下：
一次LOAD一个表。
如果可能的话，为你预期的任务赋予较高的优先级，来获得最高的消耗时间。
在系统综合体上分配工作。
将二级索引分解为小段，以便获得并行性（见PIECESIZE内的讨论）。
在数据的初始载入过程中，指定LOGNO（用于防止记录日志，它耗费了相当多的资源），在成功载入数据之后运行一个图像复制。
自由空间考虑事项
分配自由空间的主要目的，是为了将数据行保存在相同的物理序列中作为群集索引，这样一来将减少需要重新组织数据的频率。此外，较好的行聚簇将导致更快的读取访问和更快的行插入。但是，自由空间的过度分配又将导致DASD空间的浪费、每一个I/O传输的数据较少、缓冲池的利用效率较低，以及需要扫描更多的页。
表空间和索引中的自由空间分配，由CREATE或ALTERTABLESPACE和CREATE或ALTERINDEX语句中的PCTFREE和FREEPAGE选项决定。
PCTFREE在载入或者重新组织数据时，为DB2指示表空间或索引中有多大的百分比是闲置的。在插入新的行和索引条目时，DB2将利用那些自由空间。如果没有足够的自由空间在正确的页（即以正确的聚簇序列）上写入行或者索引条目，那么DB2必须将多出来的数据放在另外的页上作为代替。在越来越多的记录放置在物理序列之外的情况下，系统性能将会受到严重影响。
FREEPAGE在载入或者重新组织数据时，为DB2指示一个整页成为自由空间的次数。例如，如果你将FREEPAGE确定为5，在每填满5页的数据之后，DB2将分配一整页的自由空间。如果你的表中的行大于半页，FREEPAGE将是很有用的，因为在这样的情况下，你不能在这一页中插入第二行。
是否在你的表空间内定义自由空间，分配的数量又是多少，这些都主要取决于表空间中表的插入特性（删除活动性居于次要程度）。换句话说，向表中插入行有多大的频率，并且这些行插入的位置是在哪里？根据上述标准，四种主要的类别如下：
只读表：如果在表上不会有任何修正，定义时就可以不分配自由空间。同样，也就不需要运行REORG实用工具集。
随机插入：对于含有相当大数量已有行和相对较少插入行的动作的表，使用默认的PCTFREE（表为5，索引为10）是一个好的起始点。之后，用RUANSTATS来监视数据组织破坏的程度，并且结合你要求的运行REORG的频率，根据需要上调或下调PCTFREE。对于插入活动很频繁的表，你可能需要使用比默认值较高的PCTFREE的值。对于初始为空或只含有极少数行的表（例如，在一个新数据库部署的过程中），你也许需要确定一个非常高的PCTFREE值，并相当频繁地运行REORG，直到表中的行数比较多了。
在表的末端插入：如果表中行的长度不增加，那么就没有必要分配自由空间，因为它们可以加在表的末端。而且既然它们是以物理聚簇序列的形式写入的，REORG也不需要了。但是如果表含有可修改的VARCHAR类型的列，或是如果表是压缩过的，那么行的长度有可能增加，这将使得一行被挤到另外一页上去。通过在表空间上执行RUNSTATS然后核查DB2目录表SYSIBM.SYSTABLEPART的NEARINDREF和FARINDREF列，你就能够确定这些。如果你的表变乱了，那么为表空间设定一个PCTFREE值，并且用RUNSTATS继续监视放错位置的行的数目。根据你观察到的数据和趋势，相应地调整你的REORG的频率和PCTFREE值。通过设定REORGTABLESPACE中的INDREFLIMIT和REPORTONLY选项，你就能够在更新后的DB2表中监视紊乱的数量和速度。
插入一个热点：这是表具有很频繁的插入活动的情况，这种插入活动集中在一个位置（或多个位置），而不是正好处于表的末端。这可能是要应付的最困难的种类。试着增加PCTFREE的数值。如果插入保持在开头的段，行也不是很长，几行可以存储在同一页之内。FREEPAGE是在这种情形下另外的一个考虑。有必要严密监视表变乱有多么快，这样就可以在性能显著下降之前运行REORG。
索引设计考虑事项索引是一个DB2对象（独立的VSAM数据集），它是从相应表中的一个或更多列中摘录出来的一系列有规则的条目。很多DB2专家主张为一个表空间建立恰当的索引，这也许是将访问DB2数据应用程序的性能最优化的惟一最有效的方法。几年前，在I/T中DASD的成本和空间是一个更重要的考虑因素。随着技术的发展，通过以特大硬盘为代价，加上更多索引（或增加现有索引的列）来减少I/O的折中方法，在这几年里越来越具吸引力。索引主要的性能优势表现在：
为表中被请求的数据行提供直接指针
消除了排序，如果结果集的请求顺序与索引相匹配的话
避免了必须读取数据行，如果被请求的列全部包含在索引条目中的话
分区索引
当在DB2UDBV7中创建分区表空间时，DB2依照CREATEINDEX语句中的PART子句将分区中的数据进行划分。那个索引则成为所谓的分区索引，这种分区方法被称为受控索引分区。为了对索引进行分区，建议你选择不易改变的关键列。对这些列的更改可能使得一个行从某一分区移动到另外一个分区，从而导致性能下降。
受控表分区是DB2V8的一个重要的特征。现在，当创建分区表时，分区界限的确定由CREATETABLE语句代替了原来的CREATEINDEX。在受控索引分区中，分区表的、分区索引和聚簇的概念全都结合在一起。而对于受控表分区，这三个概念是独立的。这就增加了灵活性，允许你去考虑更有潜力的设计方法；并且也因此增加了改善DB2数据库及其应用程序性能的可能性。
构建索引的时机
CREATEINDEX（创建索引）
CREATEINDEX语句使用户具有了这样的能力：立即构建索引，或者将构建推迟到更加方便的时间。如果你立即构建索引，将会对表空间进行扫描，这会占用相当长的时间。通过设定DEFER，你可以推迟索引的构建。
无论什么时候，只要可能，在最初载入一个表之前创建表上的所有索引，因为LOAD实用工具集构建索引比CREATEINDEX过程更加有效。如果你需要在已存在（并且有很多数据）的表上创建一个索引，那么可以使用DEFER语句。稍后，你就可以用REBUILDINDEX实用工具集，它和LOAD实用工具集一样，是一种更加有效的填充索引的方法。
PIECESIZE（片段尺寸）
DB2UDBV5引进了一个新特征，它给了你一定的灵活性，从而可以将非分区索引（NPI）分解为小段，并且控制组成索引空间的多个数据集的大小。分段的这种用法能够使一个NPI的索引页展开为多个数据集。
片段的尺寸由CREATE或ALTERINDEX语句中的关键字PIECESIZE确定。PIECESIZE的值必然是两个强制值中的一个，其变动范围为最小256KB到最大64GB。常规表空间的默认值为2GB，大的表空间默认值是4GB。如果你的NPI有可能显著增长，那么选择相对较大的表空间。同样，在确定首要和次要的空间分配数值（CREATEINDEX语句的PRIQTY和SECQTY选项）时，记住PIECESIZE的值。
利用这一选项，可以通过发挥并行性来改善NPI的扫描性能。另一个优势是可以减少读取或更新过程中的I/O冲突。通过设定较小的PIECESIZE值，你可以创建更多的片段，因而对片段的位置有更好的控制。将片段置于独立的I/O路径，可以减少了访问NPI所需的SQL操作的冲突。
理想的索引
通过检查一个应用程序中的SQL语句，你可以建立一个假想的完美的索引。
首先，索引所包括的所有列都是WHERE子句，这使得索引的审查可以用于将不合格的行拒于结果集之外。将这些列放在索引的开始。当在SQL语句上执行EXPLAIN时，这会使得MATCHCOLS的价值最大化。
其次，确保索引以适当的顺序含有这些列(依照ORDERBY子句)，从而可以避免进行排序。这可以在执行EXPLAIN时，通过检查PLAN_TABLE的所有不同的SORT*列来验证。
最后，如果可能的话，将所有的列包含在索引的SELECT中，这样就不需要访问表中的行了。索引条目可以提供所有的请求数据。这将在EXPLAIN中以INDEXONLY=Y的方式表现出来。
在很多情况下，实现如此理想的索引的代价太大了，或者说是不切合实际的，甚至是不可能实现的，因为所涉及的列的数量太大了。组成一个索引的列的数目在体系结构方面有限制，并且对于一个索引条目的总长也有限制（尽管这些限制实际上允许相当大的索引条目尺寸和灵活性）。此外，这也是出于索引维护成本的考虑。建立理想的索引可使查询性能获得极大提高，但是对于SQL写入DB2数据库（INSERT、UPDATE或DELETE）就有消极的影响。因此，你应该经常选择实现只包含WHERE和ORDERBY语句中涉及的列的索引。
并行处理的考虑事项
几年来，通过实现了并行处理的各种方法，DB2在数据访问方面的性能获得了改进。为了改进数据密集型只读查询的性能，DB2V3引进了查询I/O并行机制。在这种类型的并行性中，DB2充分利用了可用的I/O带宽，并使分区表空间中成为可能。利用这种方法，DB2使得一个查询中的多个并发I/O请求可同时进行，并在多个数据分区中执行了并行的I/O处理。这代表性地使得I/O绑定查询所耗费时间的显著降低，同时出现了CPU时间的较小增长。
DB2V4引入了另外的并行性技术，称为查询CP并行性。该方法将并行处理扩展至处理密集型的查询。用该方法，单个查询可使DB2生成数个任务，并行执行数据访问。对于这种类型的并行性，分区表空间显示出最佳的性能提升。
DB2UDBV5通过引进综合系统查询并行性，更进一步地扩展了并行处理。当查询CP并行性在DB2子系统中为某个查询使用了多个任务时，该方法使得DB2数据共享群中的所有成员能够处理一个单一的查询。主要为只读形式的I/O密集型和处理密集型查询可以从这种类型的并行性中获益。
并行访问的授权
在DB2环境下使系统获得并行性能力有一定的难度。首先，在DB2子系统级别，并行访问由安装面板DSNTIP4控制。DSNTIP4上的MAXDEGREE选项决定并行性的最大程度（并行任务的最大数目）。默认值为0，意味着对于DB2可调用的并行性程度没有上限。我建议你估计虚拟存储容量，以及你的z/OS环境限制，还应根据需要调整该参数，因此DB2将不会创建超过你的虚拟存储容量可以应对的并行任务。
通过BINDPLAN和BINDPACKAGE命令的DEGREE选项，你能够控制DB2是否使用并行处理。设定DEGREE(1)阻止并行处理，而DEGREE(ANY)允许并行处理。为了获得进一步的灵活性，动态SQL允许在一个计划或包内更改该选项，通过SETCURRENTDEGREE语句即可实现，SETCURRENTDEGREE语句用于控制某个寄存器中的数值。
当一个计划或包与DEGREE(ANY)绑定，或者CURRENTDEGREE寄存器设定为ANY时，DB2优化器考虑并行性是否是可能的，从而获得最有效的最终计划。如果并行性是不可能的，那么将会选择下一个允许并行性的最有效的最终计划。
限制分区扫描限制分区扫描是允许DB2在分区表空间中限制数据扫描的一种方法。根据SQL谓词的值，DB2能够决定最低和最高的分区，这可能包含了被SQL语句所请求的表的行，之后便将数据扫描限制在分区的范围内。为了使用该技术，SQL必须提供一个在分区索引的第一个关键列上的谓词。
并行性建议
为了使并行处理的性能最优化，需要考虑以下事项：
尽可能均匀地对表空间进行分区，因为并行性程度会受到数据不均匀的影响。DB2通常在最大物理分区的基础上将表空间划分为逻辑片段。
为DB2的应用程序处理分配尽可能多的中央处理器（CP），以及尽可能多的I/O设备和通道。
对于I/O密集型查询，确保分区的数量与可以访问表空间的I/O通道数量相同。
对于处理密集型查询，确保分区的数量与用于跨共享数据群处理查询的CP数量相同。
将表空间和索引的分区放在单独的DASD卷上，并且（如果可能的话）独立控制这些单元以便使I/O冲突最小化。
在规则的基础上执行RUNSTATS实用工具集，以便获得分区级别的统计表。
监视虚拟缓冲池的阈值和使用情况，确信你提供了足够的缓冲池空间来使调用的并行性程度最大化。
缓冲池的考虑事项
缓冲池的重要性
大多数专家认为在DB2环境下，数据库缓冲池是影响性能的最关键的因素。很多DB2的体系结构和设计是基于尽可能多的或实际上避免物理I/O这一概念。
DB2缓冲池由临近存储器的插槽组成。从DASD读入之后，数据和索引页进入这些插槽并且呆在其中，直到DB2缓冲管理器决定这些插槽需要被其他数据占用。被应用程序请求的数据通常存储在存储器内，而不是在外部的DASD，这种情形越经常出现，整体的性能就越好。本质上，数据是被重新利用了，从而使得应用程序需要的I/O数量最小化。
释放缓冲池插槽的决定基于最近最少使用（LRU）法则。DB2维护着两个LRU列表，一个是关于随机访问页的，另一个是关于顺序访问页的。这便阻止了完全占用缓冲池的大表扫描，以及对随机操作的负面影响。通过各种阈值的使用，DB2为你提供了改进缓冲池性能的额外灵活性。关于这些阈值的进一步详细讨论见DB2SQL参考手册的2.7.4部分。
缓冲池的合适大小
缓冲池尺寸的指定取决于可用的存储量（包括中央部分和扩展部分）。我建议你分析一下缓冲池分配，并且增加它的尺寸直到再也没有由于增加的分配而产生的额外吞吐量，或是MVS分页速率到达不可接受的程度。这将通过逐渐增加的VPSIZE来实现，只要DASDI/Os的数目保持减少，在分页的成本超过减少I/O的收益之前，VPSIZE将持续增加。
在早期，GETPAGES的数量可能是DB2工作量的最好衡量标准。缓冲池的用途是为了使I/O最小化（异步读取通常意味着一次做一个，这是基于性能立场上的一般要求。另一方面，同步读取通常意味着从DASD的随机I/O，因为所请求的页在缓冲池内找不到）。统计报告显示le每一个缓冲池中的GETPAGES和同步读取的数量。一个被普遍接受的ROT说，如果同步读取的GETPAGES比率小于10:1，那么你应该考虑配置更大缓冲池了。
多缓冲池配置
如果你的操作环境允许为DB2缓存配置容量相当大的存储器，那么多缓冲池配置可以最大限度地为特定的应用程序或数据库提供改善的性能。然而，请注意由于采用多个缓冲池，监视它们的工作效率变得更加重要。
普遍来讲，对配置多缓冲池有如下建议：
将表空间和它们相联系的索引分离到不同的池，以便使索引I/O最小化。
将具有不同数据访问模式的数据分别置于不同的缓冲池中。典型地，批处理和查询应用程序含有大量的连续处理，而OLTP的数据访问在本质上往往比较随机。这就提供了一种方法，来开发不同的阈值以在一个缓冲池适应各种特定类型的数据访问。
为了隔离应用程序，提供一个单独的缓冲池。这就提供了一种方法，来严密监视一个存在运行问题的应用程序，或是测试新的应用程序。
如果分类性能在你的环境下很重要，那么就为共作文件创建一个独立的缓冲池。
对于相对比较小但是更新很快的表，足够大的独立缓冲池可以同时消除读取和书写I/Os。
为只读表（小的、参考表）设立单独的缓冲池也可以提高性能。
总结
经过深思熟虑的数据库设计可以提供重大的性能优势，但是它必须在应用程序的开发过程中尽早开始。上述很多原则，在DB2的早期就已经被明智的开发人员所利用，并且至今仍保持着它们的正确性。然而清楚DB2功能上的进步，以及影响你当前和以后应用程序的其他领域内的硬件和软件技术的变化，同样也是至关紧要的。当数据库性能成为发展过程的一个重要焦点时，你的数据库设计，将使你更有可能为你的DB2应用程序提供最优化的性能。
以上就是“数据库管理系统设计方案范文”的相关内容啦。数据库设计是数据库系统中非常重要的一环，它可以提高数据的可靠性、安全性和可维护性，从而满足用户的需求，保证数据库系统的稳定运行。
一、数据库设计过程数据库技术是信息资源管理最有效的手段。数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。数据库设计的各阶段：A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。1.需求分析阶段需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(StructuredAnalysis，简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(DataDictionary，简称DD)来描述。2.概念结构设计阶段通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。概念模型特点：(1)具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。(2)应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。使用IDEF1X方法创建E-R模型的步骤如下所示:2.1第零步——初始化工程这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。2.2第一步——定义实体实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有“代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。2.3第二步——定义联系IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系(强制的或可选的)还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。2.4第三步——定义码通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图(KB图)。2.5第四步——定义属性从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。2.6第五步——定义其他对象和规则定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义发器、存储过程、视图、角色、同义词、序列等对象信息。3.逻辑结构设计阶段将概念结构转换为某个DBMS所支持的数据模型(例如关系模型)，并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。数据模型的优化，确定数据依赖，消除冗余的联系，确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：表内的每一个值都只能被表达一次。表内的每一行都应该被唯一的标识(有唯一键)。表内不应该存储依赖于其他键的非键信息。4.数据库物理设计阶段为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。5.数据库实施阶段运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C)，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。数据库实施主要包括以下工作：DDL定义数据库结构、用组织数据入库、编制与调试应用程序、数据库试运行，(DataDefinitionLanguage(DDL数据定义语言)用作开新数据表、设定字段、删除数据表、删除字段，管理所有有关数据库结构的东西)●Create(新增有关数据库结构的东西，属DDL)●Drop(删除有关数据库结构的东西，属DDL)●Alter(更改结构，属DDL)6.数据库运行和维护阶段在数据库系统运行过程中必须不断地对其进行评价、调整与修改。内容包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。7.建模工具的使用为加快数据库设计速度，目前有很多数据库辅助工具(CASE工具)，如Rational公司的RationalRose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracleDesigner等。ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构;画数据流图，生成应用程序。二、数据库设计技巧1.设计数据库之前(需求分析阶段)1)理解客户需求，包括用户未来需求变化。2)了解企业业务类型，可以在开发阶段节约大量的时间。3)重视输入(要记录的数据)、输出(报表、查询、视图)。4)创建数据字典和ER图表数据字典(DataDictionary，简称DD)是各类数据描述的集合，是关于数据库中数据的描述，即元数据，不是数据本身。(至少应该包含每个字段的数据类型和在每个表内的主外键)。数据项描述:数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系数据结构描述:数据结构名，含义说明，组成:[数据项或数据结构]数据流描述:数据流名，说明，数据流来源，数据流去向，组成:[数据结构]，平均流量，高峰期流量数据存储描述:数据存储名，说明，编号，流入的数据流，流出的数据流，组成:[数据结构]，数据量，存取方式处理过程描述:处理过程名，说明，输入:[数据流]，输出:[数据流]，处理:[简要说明]ER图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL表达式的文档化来说这是完全必要的。5)定义标准的对象命名规范数据库各种对象的命名必须规范。2.表和字段的设计(数据库逻辑设计)表设计原则1)标准化和规范化数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但ThirdNormalForm(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF标准的数据库的表设计原则是：“OneFactinOnePlace”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。2)数据驱动采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。举例，假如用户界面要访问外部数据源(文件、XML文档、其他数据库等)，不妨把相应的连接和路径信息存储在用户界面支持的表里。如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等)，那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。3)考虑各种变化在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。4)表名、报表名和查询名的命名规范(采用前缀命名)检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。你可以统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用Table、Query或者Report等前缀加以区别。如果采用了MicrosoftAccess，你可以用qry、rpt、tbl和mod等符号来标识对象(比如tbl_Employees)。用sp_company标识存储过程，用udf_(或者类似的标记)标识自定义编写的函数。字段设计原则：1)每个表中都应该添加的3个有用的字段。dRecordCreationDate，在SQLServer下默认为GETDATE()·sRecordCreator，在SQLServer下默认为NOTNULLDEFAULTUSER·nRecordVersion，记录的版本标记;有助于准确说明记录中出现null数据或者丢失数据的原因·时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。2)对地址和电话采用多个字段描述街道地址就短短一行记录是不够的。
Address_Line1、Address_Line2和Address_Line3可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。3)表内的列[字段]的命名规则(采用前缀/后缀命名)、采用有意义的字段名对列[字段]名应该采用标准的前缀和后缀。如键是数字类型：用_N后缀;字符类型：_C后缀;日期类型：_D后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个_M后缀。假设有两个表：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*FromCustomer,OrderWherecu_surname=“MYNAME”;andcu_name_id=or_cust_name_idandor_quantity=1在没有这些前缀的情况下则写成这个样子(用别名来区分)：Select*FromCustomer,OrderWhereCustomer.surname=“MYNAME”;andCustomer.name_id=Order.cust_name_idandOrder.quantity=1第1个SQL语句没少键入多少字符。但如果查询涉及到5个表乃至更多的列[字段]你就知道这个技巧多有用了。5)选择数字类型和文本类型的长度应尽量充足假设客户ID为10位数长。那你应该把数据库表字段的长度设为12或者13个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。6)增加删除标记字段在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。7)提防大小写混用的对象名和特殊字符采用全部大写而且包含下划符的名字具有更好的可读性(CUSTOMER_DATA)，绝对不要在对象名的字符之间留空格。8)小心保留词要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，用DESC作为说明字段名。后果可想而知!DESC是DESCENDING缩写后的保留词。表里的一个SELECT*语句倒是能用，但得到的却是一大堆毫无用处的信息。9)保持字段名和类型的一致性在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在表1中叫做“agreement_number”，就别在表2里把名字改成“ref1”。假如数据类型在表1里是整数，那在表2里可就别变成字符型了。当然在表1(ABC)有处键ID，则为了可读性，在表2做关联时可以命名为ABC_ID。10)避免使用触发器触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。3.选择键和索引(数据库逻辑设计)参考：《SQL优化-索引》一文4.数据完整性设计(数据库逻辑设计)1)完整性实现机制：实体完整性：主键参照完整性：父表中删除数据：级联删除;受限删除;置空值父表中插入数据：受限插入;递归插入父表中更新数据：级联更新;受限更新;置空值DBMS对参照完整性可以有两种方法实现：外键实现机制(约束规则)和触发器实现机制用户定义完整性：NOTNULL;CHECK;触发器2)用约束而非商务规则强制数据完整性采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键)的完整性所以不能强加于其他完整性规则之上。如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。3)强制指示完整性在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。4)使用查找控制数据完整性控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。5)采用视图为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。6)分布式数据系统对分布式系统而言，在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来5年或者10年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段中设置一些标记，在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输，请写下你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据，比如计算常数和利息率等，设置版本号保证数据在每个站点都完全一致。7)关系如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。8)给数据保有和恢复制定计划考虑数据保存策略并包含在设计过程中，预先设计你的数据恢复过程。采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。9)用存储过程让系统做重活提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方，它也是简化编码之地。5.其他设计技巧1)避免使用触发器触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。2)使用常用英语(或者其他任何语言)而不要使用编码在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。3)保存常用信息让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。4)包含版本机制在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。5)编制文档对所有的快捷方式、命名规范、限制和函数都要编制文档。采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2个版本，犯错的机会将大大减少。6)测试、测试、反复测试建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。7)检查设计在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。三、数据库命名规范1.实体(表)的命名1)表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则(比方说，如果表名是一个单词，别名就取单词的前4个字母;如果表名是两个单词，就各取两个单词的前两个字母组成4个字母长的别名;如果表的名字由3个单词组成，从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成4字母长的别名，其余依次类推)对工作用表来说，表名可以加上前缀WORK_后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意：将字段名称会统一成大写或者小写中的一种，故中间加上下划线。举例：定义的缩写Sales:Sal销售;Order:Ord订单;Detail:Dtl明细;则销售订单明细表命名为：Sal_Ord_Dtl;2)如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。举例：定义的缩写MaterialMa物品;物品表名为：Material,而不是Ma.但是字段物品编码则是：Ma_ID;而不是Material_ID3)所有的存储值列表的表前面加上前缀Z目的是将这些值列表类排序在数据库最后。4)所有的冗余类的命名(主要是累计表)前面加上前缀X冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表5)关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。关联表用于保存多对多关系。如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。
《数据库开发》是计算机专业的一门核心课程，通过本课程的学习，学生将能够进行初步的需求分析，根据分析结果设计数据库的概念结构模型和逻辑结构模型，并能够根据物理结构模型进行数据库实施和简单数据库应用系统的开发。本课程实践性非常强，注重培养学生的动手能力。所以，设计课程过程中，应该更加注重课程本身的实用性，更加注重课程内容本身与企业岗位的相结合。
《数据库开发》课程设计主要经历了企业调研、课程标准开发、课程方案设计等几个阶段。下面就分别说明一下课程设计的每个阶段。
1《数据库开发》课程企业调研
进行企业调研是课程建设要进行的第一步，只有进行了充分的企业调研才能培养出满足社会和企业需求的合格人才。才能根据需求进行课程的设计，这样才能使学校的课程更加适合企业，更加适合社会。为此，我们的项目团队到企业进行了实地调研，我们获取到了企业对于学生的需求和对于课程设置方面的建议。
本门课程在进行企业调研之前已经根据之前的教学经验设置了本门课程的任务，具体任务设置如下：
任务1数据库分析与设计
任务2系统前台页面设计
任务3数据库实现
任务4系统后台实现
任务5数据库维护
通过与企业专家进行研讨，最终获取来自企业关于《数据库开发》课程设计的建议。具体建议如下：
任务1教学要求及建议：
①数据库基本概念和知识简单带过，达到了解的程度即可。
②需求分析难度较高，不建议让学生进行整个系统的需求分析，可以编写需求规格说明书的部分内容。
③进行数据库概念结构设计时，可以先画出系统的各个部分的E_R图，最后在将整个系统的E_R图画出来。
④可以使用PowerDesigner软件进行数据库的概念结构设计和物理结构设计。
⑤这部分内容比较难，需要多练习，可以适当多加一些课时。
任务2教学要求及建议：
①本部分内容是对于之前所学网页设计和JSP的内容进行熟悉，可以以学生做为主。
②进行分小组教学，小组内进行角色划分，充分发挥团队的力量。
③因为是之前的知识可以适当减少课时。
任务3教学要求及建议：
①对于数据库管理软件可以选择相对比较容易上手的，如SQLServer、MySQL等。
②数据库管理软件图形界面操作时，应该注意多做练习培养学生的动手能力，选择是实例可以由浅入深，逐步较大难度和工作量。
③应该重点讲解SQL语句，因为SQL语句的大部分语法都是可以在不同数据库通用的。
④实现所用项目的数据库时，也应该将尽量让学生自己进行SQL语言的编写，这样可以更好的使掌握SQL语句的应用。
任务4教学要求及建议：
①讲解Spring的基本原理和用法时，应通过简单的实例学习Spring的应用。
②学生应该进行分小组不同模块的开发练习，小组规模不要太大，3个人为一组比较适宜。
③不应占用太多课时。
任务5教学要求及建议：
①数据库维护的内容应该以视图和索引为主，进行重点讲解。
②数据库的用户和权限的应该多做实例。
③触发器的使用可以简单讲解。
课程总体建议：
①课程讲解内容较多，且内容难度较高，需要课时较多。
②应重点讲解任务一和任务三的内容，其次是任务四和任务五的内容。
③学生多做练习，注意培养他们的团队合作能力和沟通能力，注意锻炼学生的自学能力。
有了企业调研结果作为课程设计的依据，就可以进行课程标准的制定。
2《数据库开发》课程标准的设计
课程标准是一门课程进行教学的根本依据，在课程标准中要包含课程的设计思路、能力目标和课程内容框架等内容。制定课程标准一定要详细描述课程各方面的内容，制定完整准确的课程标准是进行课程设计重要环节。
2.1课程设计思路本课程主要以企业实际项目为主线，通过五个典型的工作任务，使学生掌握数据库开发的相关知识和技能；学生在学习本课程过程中，主要学习的内容包括：数据库需求分析、数据库模型设计方法、使用数据库管理软件对数据库模型进行实施、使用数据库管理软件管理数据库，对已有的数据库开发数据库应用系统对数据进行增删改查的基本操作。将该课程的整个教学任务按照项目分为5个典型的工作任务，具体描述如下：
①数据库需求分析：对所选用的项目的需求使用需求分析方法进行分析，并编写需求规格说明书。
②数据库模型设计：根据上一个任务中编写的需求规格说明书，进行数据库的概念结构设计、逻辑结构设计和物理结构设计。
③数据库模型实施：选择数据库管理软件对上一个任务中设计的数据库模型进行实施，并介绍SQL语句的基本应用。
④数据库查询操作及视图、索引等数据库对象应用：对于已有数据库使用SQL语句进行查询的操作，并介绍视图、索引等主要数据库对象的应用。
⑤数据库应用系统开发：开发一个基于Web的数据库应用系统，对已有数据库实现数据的增删改查的功能。
以上的典型工作任务，与企业调研之前的工作任务对比情况，如下表所示：
2.2能力目标
①能够进行初步的需求分析
②能够根据需求分析的结果设计数据库的概念模型
③能够将数据库概念模型转换为逻辑模型，并生成物理模型
④能够使用SQL语句实施数据库模型
⑤能够使用SQL语句进行简单数据查询
⑥能够使用Spring+Hibernate开发基于Web数据库应用系统
在课程标准中，还包含其他的一些内容，比如课程内容、课程的考核方式等内容，这里不再赘述。制定完课程标准后，就要依据课程标准进行课程方案设计。
3《数据库开发》课程方案设计
根据课程标准，进行课程方案的设计，课程方案设计一般包含课程总体方案设计、课程任务方案设计和课程活动方案设计。
3.1课程总体方案设计课程总体方案设计是对于本课程的总体的介绍，其中包含课程的课时、适用专业、学习内容、能力目标、学习成果和考核方案等内容。
3.2课程任务方案设计课程任务设计方案是对于课程中涉及的典型工作任务的描述，它具体说明了课程中每个任务的学习内容、能力目标、学习环境、教学方法、学习成果和评价标准等内容。
3.3课程活动方案设计课程活动方案设计是对于每个典型工作任务中具体活动的描述，它具体说明了在典型工作任务中每个学习活动，介绍学习活动的内容、目标、活动具体设计、课程用到的参考资料等内容。
在完成课程的方案设计后，就可以根据方案进行数据库的实施了，在实施过程中还会遇到各种问题，实施完成后，要根据实施的情况，对课程的课程标准、课程设计方案等内容进行修订，从而使得课程的设计方案更加完善。
4结论
由上面的内容不难看出，《数据库开发》课程的设计或者是其他技术类课程的设计，都应该注重实践，减少课程理论知识的讲解，将课程的理论知识融入到学生完成的典型工作任务中，真正要做到“做中学”，要重视课程本身与企业的关联，要做到课程为企业服务，另外，课程本身中的内容还要与时俱进，跟得上社会发展。