数据库管理系统设计方案范文 数据库设计案例材料汇总

数据库设计是指在设计数据库系统时，将用户需求转化为数据库模式的过程。它的主要目的是满足用户的需求，提高数据的可靠性、安全性和可维护性。以下是“数据库管理系统设计方案范文，以及数据库设计案例材料汇总”的相关内容，可供朋友们借鉴。

数据库设计方案1

1.数据库设计原则

数据设计原则包括统一原则、标准化原则、规范性原则、保护性原则、完整性原则，并发性原则，安全性原则、备份性原则、数据关联性原则、适应性原则、可靠性与完整性原则、快速访问原则。

1、统一原则

数据库统一标准化处理，统一建设，实现信息资源标准化和开放共享。

2、标准化原则

并遵从各项技术规定，做好数据库的标准化设计与建设。各配套设备的性能和技术要求稳定可靠，所有的数据库设计符合国家标准和行业规范。

3、规范性原则

数据处理及数据建库实行规范化设计与建设，为业务系统提供支撑。

4、保护性原则

项目建设要充分考虑易维护性原则，软件建设做好售后服务，为后期建设提供良好基础。

5、完整性原则

在系统设计中，我们选用产品和系统时，应充分考虑系统的升级、扩展、维护问题，设计应全面、周到，注意预留到位并留有充分余某某,以适应未来发展需要。

6、并发性原则

项目建设过程中具有一定的抗干扰性，提高稳定性。

7、安全性原则

系统的数据库必须分层次和级别、保证数据库在各种级别保密程度上的查询访问，防止信息被任意查询和破坏，对各种各样的计算机病毒，系统都应具有高度的免疫力。

8、备份性原则

系统的设计和设备配置必须保证信息的安全，有较好的数据安全措施，有较强的数据备份和系统恢复功能。

9、数据关联性原则

考虑数据与数据之间关联性问题，实现数据间的共享开放。

10、适应性原则

系统设计应符合统一规划、阶段性实施的原则，充分考虑未来技术发展所带来的系统扩充的需求，预留足够的接口空间，可满足以后的软件升级及设备扩容。

11、可靠性与完整性原则

即系统的设计能充分考虑系统的发展需要，能充分适应科技的快速进步，对系统的扩展性预留可持续发展的接口和技术空间。

12、快速访问原则

系统安全可靠，运行稳定，能够快速进行访问。

2.数据库逻辑设计

数据库逻辑设计包括数据库逻辑划分、矢量数据逻辑设计、栅格数据逻辑设计。

1、数据库逻辑上是由一个或多个表空间组成的，表空间物理上是由一个或多个数据文件组成的；而在逻辑上表空间又是由一个或多个段组成的。在数据库中，通过为每种不同的数据对象分配不同的段，来保存数据。在数据库中，段是由一个或多个区组成的，而区又是由连续存储的数据块所 组成的。块则是数据库的I/O 最小的单位。本项目的数据库逻辑划分包括空间数据库和非空间数据库。

2、矢量数据逻辑设计包含了公共基础数据、林业信息资源中的矢量数据，综合对黑龙江林业数据源和功能进行分析，将矢量数据按照数据类型分为公共基础数据库、林业基础矢量数据库、林业专题矢量数据库，每一个数据库需按照数据内容和数据特点组织成不同的图层。

矢量数据主要是指大比例尺地形图。此项目中矢量数据主要为点、线、面形状矢量数据以及不同种类业务的矢量数据,合理的分层便于进行叠加分析、图形的无逢拼接以实现系统图形的大范围漫游。矢量数据一般通过记录坐标的方式来尽可能将地理实体的空间位置表现的准确无误,显示的图形一般为矢量图。

矢量数据是计算机中以矢量结构存贮的内部数据。是跟踪式数字化位的直接产物。在矢量数据结构中,点数据可直接用坐标描述；线数据可用均匀或不均匀间隔的顺序坐标链来描述；面状数据(或多边形数据)可用边界线来描述。矢量数据的组织形式较为复杂，以弧段为基本逻辑单元,而每一弧段以两个或两个以上相交结点所限制,并为两个相邻多边形属性所猫述。

3、栅格数据逻辑设计包括影像数据、DEM高程数据等。

栅格数据是按网格单元的行与列排列、具有不同灰度或颜色的阵列数据。每一个单元(象素)的位置由它的行列号定资料的组织进行归类，各专题规划所包含的文档和图片，保持原有规划好成果的顺序和分类，对于没有电子文档只有纸质文本的规划成果资料同样通过文件扫描来进行归类组织入库。

4、数据组织

针对数据的组织，可借助专门的软件工具来辅助实现。通过该工具，可重新定义不同数据体系之间的对应关系（映射），即可由计算机自动完成大部分的数据重组织工作。少量不能由计算机自动完成的部分，可采用人工方式将不同层的数据进行组织、建立索引等。

5．数据安全设置

对各用户权限进行设置，遵循权限最小化原则，删除或锁定无关用户。对密码策略进行设置，包括：密码长度、字符组成、有效期等进行设置。对日志进行设置，对用户登录、操作等进行记录。

数据库设计方案2

对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求数据库设计的各阶段：A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模，如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。需求分析阶段需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(StructuredAnalysis，简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(DataDictionary，简称DD)来描述。2.概念结构设计阶段通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。

数据库设计方案3

一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立 数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计的各阶段： A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。 B、在概念设计阶段：形成独立于机器和各 DBMS 产品的概念模式(信息世界 模型)，用 E-R 图来描述。 C、在逻辑设计阶段：将 E-R 图转换成具体的数据库产品支持的数据模型， 如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑， 在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。 D、在物理设计阶段：根据 DBMS 特点和处理的需要，进行物理存储安排，设 计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处 理需求)。 需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要 求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明 确对新系统的各种要求、确定新系统的边界。 常用的调查方法有： 跟班作业、开调查会、请专人介绍、询问、设计调查 表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。 自顶向 下的结构化分析方法(Structured Analysis，简称 SA 方法)从最上层的系统组织 机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描 述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典 (Data Dictionary，简称 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 定义数据库结构、 用 组织数据入库 、 编制与调试应用程序、数据库试运行 ，(Data Definition Language(DDL 数据 定义语言)用作开新数据表、设定字段、删除数据表、删除字段，管理所有有关 数据库结构的东西) ●Create (新增有关数据库结构的东西，属 DDL) ●Drop (删除有关数据库结构的东西，属 DDL) ●Alter (更改结构，属 DDL) 6. 数据库运行和维护阶段 在数据库系统运行过程中必须不断地对其进行评价、 调整与修改。 内容包括： 数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析 和改进、数据库的重组织和重构造。 7. 建模工具的使用 为加快数据库设计速度，目前有很多数据库辅助工具(CASE 工具)，如 Rational 公司的 Rational Rose，CA 公司的 Erwin 和 Bpwin，Sybase 公司的 PowerDesigner 以及 Oracle 公司的 oracle Designer 等。 ERwin 主要用来建立数据库的概念模型和物理模型。它能用图形化的方式， 描述出实体、联系及实体的属性。ERwin 支持 IDEF1X 方法。通过使用 ERwin 建 模工具自动生成、更改和分析 IDEF1X 模型，不仅能得到优秀的业务功能和数据 需求模型，而且可以实现从 IDEF1X 模型到数据库物理设计的转变。ERwin 工具 绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X 工具箱可 以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中， ERwin 可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的 类型。 设计人员可根据需要选用相应的数据库设计建模工具。 例如需求分析完成之 后，设计人员可以使用 Erwin 画 ER 图，将 ER 图转换为关系数据模型，生成数据 库结构;画数据流图，生成应用程序。 二、数据库设计技巧 1. 设计数据库之前(需求分析阶段) 1) 理解客户需求，包括用户未来需求变化。 2) 了解企业业务类型，可以在开发阶段节约大量的时间。 3) 重视输入(要记录的数据)、输出(报表、查询、视图)。 4) 创建数据字典和 ER 图表 数据字典(Data Dictionary，简称 DD)是各类数据描述的集合，是关于数据 库中数据的描述，即元数据，不是数据本身。(至少应该包含每个字段的数据类 型和在每个表内的主外键)。数据项描述: 数据项名，数据项含义说明，别名，数据类型，长度，取值范 围，取值含义，与其他数据项的逻辑关系 数据结构描述: 数据结构名，含义说明，组成:[数据项或数据结构] 数据流描述: 数据流名，说明，数据流来源，数据流去向， 组成:[数据结 构]，平均流量，高峰期流量 数据存储描述: 数据存储名，说明，编号，流入的数据流，流出的数据流， 组成:[数据结构]，数据量，存取方式 处理过程描述: 处理过程名，说明，输入:[数据流]，输出:[数据流]，处 理:[简要说明] ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得 数据。ER 图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以 及任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的。 5) 定义标准的对象命名规范 数据库各种对象的命名必须规范。 2. 表和字段的设计(数据库逻辑设计) 表设计原则 1) 标准化和规范化 数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但 Third Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最 好平衡。简单来说，遵守 3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需 进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放 通过键连接起来的关联数据。 2) 数据驱动 采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大 增强系统的灵活性和扩展性。 举例，假如用户界面要访问外部数据源(文件、XML 文档、其他数据库等)， 不妨把相应的连接和路径信息存储在用户界面支持的表里。 如果用户界面执行工 作流之类的任务(发送邮件、打印信笺、修改记录状态等)，那么产生工作流的数 据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上， 如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己 的工作流过程。 3) 考虑各种变化 在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。 4) 表名、报表名和查询名的命名规范 (采用前缀命名)检查表名、报表名和查询名之间的命名规范。你可能会很快 就被这些不同的数据库要素的名称搞糊涂了。 你可以统一地命名这些数据库的不 同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象(比如 tbl_Employees)。用 sp_company 标识存储过程， 用 udf_ (或者类似的标记)标识自定义编写的函数。 字段设计原则： 1) 每个表中都应该添加的 3 个有用的字段。 dRecordCreationDate，在 SQL Server 下默认为 GETDATE()·sRecordCreator，在 SQL Server 下默认为 NOT NULL DEFAULT USER· 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 * 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 Customer.name_id = Order.cust_name_id and Order.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 对参照完整性可以有两种方法实现：外键实现机制(约束规则)和触发 器实现机制用户定义完整性： NOT NULL;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) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用 完整的单词。 举例： 定义的缩写 Material Ma 物品; 物品表名为：Material, 而不是 Ma. 但是字段物品编码则是：Ma_ID;而不是 Material_ID 3) 所有的存储值列表的表前面加上前缀 Z 目的是将这些值列表类排序在数据库最后。 4) 所有的冗余类的命名(主要是累计表)前面加上前缀 X 冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表 5) 关联类通过用下划线连接两个基本类之后， 再加前缀 R 的方式命名,后面 按照字母顺序罗列两个表名或者表名的缩写。 关联表用于保存多对多关系。 如果被关联的表名大于 10 个字母，必须将原来的表名的进行缩写。如果没 有其他原因，建议都使用缩写。

数据库设计方案4

1 背景分析

目前，产品化的数据库管理系统是以关系型数据库为主流，技术相对成熟。面向对象的数据库管理系统尽管技术上处于先进，数据库易于研发、维护，但至今为止，还没有成熟的产品。占主导位置的关系型数据库管理系统包括ORACLE、SYBASE、SQL Server、INFORMIX与INGRES，这些产品都支持UNIX、VMS、WINDOWS等不同平台，但支持的程度不一样。

通常系统的设计与研发阶段，设计人员、研发人员与测试人员仅会把工作重点放在系统的功能实现上，而此时因为测试数据较小，难以衡量系统的运行性能的优劣，然而如果系统进入实际运行阶段，大量的业务数据通常会使系统的性能逐步降低，此时再来考虑怎样提升性能则会花费更多的人力及财力。所以，设计出高质量的数据库结构就变得特别关键。

2 数据库服务器选择

对于占主导位置的SQL Server、Oracle、SYBASE、DB2和INFORMIX数据库，分别从性能、运用风险、开放性、易维护性与价格等方面来分析比较。

2.1 性能

SQL Server老版本服务器多用户时性能较差，新版本的性能有了显著的提升，各项处理能力都有了显著的提升，占有数项TPC-C（事务处理性能委员会）纪录，并支持集群。Oracle数据库性能最佳，占有Windows NT平台下的TPC-D（基准测试，衡量联机事务处理系统的一个测试指标）及TPC-C的世界纪录。SYBASE数据库性能较好，满足Sun、IBM、HP、Compaq及Veritas集群设施的性能，达到高可用性；性能比SQL Server稍差，然而在UNIX平台下的并发性要高于SQL Server，适用于安全性要求较高的应用系统。DB2适合于数据仓库与在线事务处理，性能较好，支持胖客户端和应用模式。INFORMIX性能较好，支持集群，达到高可用性，适用于安全性要求极高的应用系统，特别是在金融业、证券行业的应用。

2.2 运用风险

SQL Server属于完全重写的代码，性能及版本兼容性有了较大的改善，同Oracle、DB2的性能差距显著减小。该产品的产生经历了大量用户长期的测试，对产品的安全及稳定进行了全面的检测，安全稳定性有了显著的改善。Oracle长时期的研发经验，完全向下版本兼容，基本没有风险。能够安全的进行系列产品的升级，在企业、政府中获得普遍应用。而且假如在WINNT平台上不能满足数据的要求，能够安全的将数据转移到UNIX平台上来。SYBASE向下版本兼容，然而ct-library程序不易移植。研发周期较长，升级较为复杂，稳定性较佳，数据安全有保障，风险较小。在安全要求极高的金融、证券领域获得了普遍应用。DB2在巨型企业获得普遍的应用，向下版本兼容性较好，应用风险较小。INFORMIX研发周期较长，升级较为复杂，稳定性较佳，数据安全有较高保障，应用风险较小。在安全要求极高的金融、证券领域中获得了普遍应用。

2.3 开放性

SQL Server仅能在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（Hewlett C Packard UNIX的缩写，属于惠普公司的UNIX操作系统），在金融业获得普遍的应用。

2.4 易维护性与价格

SQL Server从易维护性与价格上SQL Server占有较大优势。基于Microsoft产品的一贯风格，SQL Server的图形管理界面导致了显著的易用性，微软的数据库管理员培训工作相对充分，能够轻松的找到技术较好的数据库管理员，数据库管理费用相对低，SQL Server的价格也是较低的。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 总结

开发数据库管理系统时，一个优秀的数据库服务器的选择和好的数据库结构设计起到举足轻重的地位。SQL Server属于微软公司研发的大型关系型数据库系统，功能相对全面，效率较高，管理与操作比较简单、方便，整个系统的安全及稳定也较高，并且性能价格比最好，节约企业资金，降低研发成本，是开发人员理想的选择，能够作为中型企业或单位的数据库平台。数据库结构设计在数据库管理系统研发过程中同样占据非常关键的地位，一个好的数据库结构是该数据库管理系统的基础，数据结构设计的优劣将直接影响到该系统的效率以及所要达到的效果。

数据库设计方案5

《数据库开发》是计算机专业的一门核心课程，通过本课程的学习，学生将能够进行初步的需求分析，根据分析结果设计数据库的概念结构模型和逻辑结构模型，并能够根据物理结构模型进行数据库实施和简单数据库应用系统的开发。本课程实践性非常强，注重培养学生的动手能力。所以，设计课程过程中，应该更加注重课程本身的实用性，更加注重课程内容本身与企业岗位的相结合。

《数据库开发》课程设计主要经历了企业调研、课程标准开发、课程方案设计等几个阶段。下面就分别说明一下课程设计的每个阶段。

1 《数据库开发》课程企业调研

进行企业调研是课程建设要进行的第一步，只有进行了充分的企业调研才能培养出满足社会和企业需求的合格人才。才能根据需求进行课程的设计，这样才能使学校的课程更加适合企业，更加适合社会。为此，我们的项目团队到企业进行了实地调研，我们获取到了企业对于学生的需求和对于课程设置方面的建议。

本门课程在进行企业调研之前已经根据之前的教学经验设置了本门课程的任务，具体任务设置如下：

任务1 数据库分析与设计

任务2 系统前台页面设计

任务3 数据库实现

任务4 系统后台实现

任务5 数据库维护

通过与企业专家进行研讨，最终获取来自企业关于《数据库开发》课程设计的建议。具体建议如下：

任务1 教学要求及建议：

①数据库基本概念和知识简单带过，达到了解的程度即可。

②需求分析难度较高，不建议让学生进行整个系统的需求分析，可以编写需求规格说明书的部分内容。

③进行数据库概念结构设计时，可以先画出系统的各个部分的E_R图，最后在将整个系统的E_R图画出来。

④可以使用PowerDesigner软件进行数据库的概念结构设计和物理结构设计。

⑤这部分内容比较难，需要多练习，可以适当多加一些课时。

任务2 教学要求及建议：

①本部分内容是对于之前所学网页设计和JSP的内容进行熟悉，可以以学生做为主。

②进行分小组教学，小组内进行角色划分，充分发挥团队的力量。

③因为是之前的知识可以适当减少课时。

任务3教学要求及建议：

①对于数据库管理软件可以选择相对比较容易上手的，如SQL Server、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 结论

由上面的内容不难看出，《数据库开发》课程的设计或者是其他技术类课程的设计，都应该注重实践，减少课程理论知识的讲解，将课程的理论知识融入到学生完成的典型工作任务中，真正要做到“做中学”，要重视课程本身与企业的关联，要做到课程为企业服务，另外，课程本身中的内容还要与时俱进，跟得上社会发展。

数据库设计方案6

一、何为数据库

概括来说，数字出版产品种类主要包括数据库、电子书、App、音视频、动漫、在线服务等。在专业出版领域，最为常见和成熟的是数据库和电子书，这两者是同一内容针对不同用户需求而表现出来的不同形态。

数据库是关于某一类特定内容的集合体，海量资源、注重检索是数据库的两大特征，适用于专业内容，尤其是科学、技术和医学内容。数据库产品参考性强、具有工具性特征，是设计产品时要考量的核心要素。数据库产品的销售以机构用户为主，个人用户是未来发展的潜在市场。

二、数据库产品的结构

数据库产品的结构主要包括支撑层（搜索引擎、电子商务、版权保护、管理系统等）、资源层（资源描述、加工标引、词库分类）、功能层（内容浏览、分类导航、精准检索、知识关联）和用户层（知识服务、个性化服务）。

设计产品的最终目的是满足用户需求、提供良好用户体验。对于数据库产品而言，以上四层结构的设计保障了最终目标的实现。在海量内容的基础上，依靠有序的资源组织，借助专业词库、搜索引擎、内容挖掘等基础支撑，快速查找出用户需求的内容，满足查询参考的需要，在实现用户价值的同时实现产品价值。图1为数据库产品的结构图：

三、数据库产品的出版流程

数据库产品的出版，从设计到实现一般需经历6个核心环节：需求调研、资源调研、功能设计、资源加工、产品研发和运营管理。随着用户需求变化、资源增加和技术升级不断螺旋上升、迭展，从而形成一个循环发展的过程。

下面以人卫社的西医图书数据库为例，简述数据库产品的出版过程。

在需求调研阶段，从用户对医学图书的需求特征入手，明确用户的核心需求，即解决临床实际问题、准确定位查询内容。

在资源方面，人卫社出版的医学图书品种多、专业覆盖全面、内容权威，基本可以满足临床工作需求，具备构建医学数据库的基础条件。

在功能设计上，西医图书数据库在产品设计时明确了功能需求，有明晰的内容组织架构，能提供用户所熟悉的导航浏览路径；能够快速精准的检索；从简单的图书内容服务向知识服务转变；针对不同用户实现个性化服务。

在资源加工方面，所有功能的实现都要从资源加工做起，精准检索和知识服务离不开资源的深度标引。

在关键的产品开发阶段，为了解决开发人员与产品设计人员的知识背景壁垒，建立相应项目组共同工作，定期召开例会，反复沟通详细设计。尤其是一些核心功能的开发，产品设计人员提前介入，及时测试，做到问题早发现早纠正。数据库产品的开发，工作量大、功能点多，从底层架构到前端UI设计都需要切实到位，才能保证质量和开发进度。

最后是产品运营管理阶段，需要以产品设计人员为核心，协调市场销售人员、客户服务人员和技术开发人员，及时响应用户需求，形成产品迭展的机制。

四、以内容资源为基础的产品布局

在内容资源加工和管理的基础上，需要考虑多维度的产品，构建出成体系的产品布局，如此才能真正体现出内容资源的内在价值。

数据库设计方案7

引言

计算机技术中数据库是最重要的研究方向之一，随着日趋应用复杂化，传统的数据库不足已逐渐被显露出来，而面向对象技术的数据库将成为新一代数据库的发展方向。

1、关系数据库中的优势

面向对象是一种认识方法学，也是一种新的程序设计方法学。把面向对象的方法和数据库技术结合起来可以使数据库系统的分析、设计最大程度地与人们对客观世界的认识相一致。

面向对象技术利用对象、类等技术手段可以满足对一些领域数据库的特殊需求，与关系型数据库相比，面向对象技术的优势主要体现在以下几个方面。

1.1 支持复杂的数据模型。传统的关系型数据库不能支持复杂的数据模型，例如：文本、图像、声音、动画、图像等数据，其缺乏对这些数据信息的描述、操纵和检索能力。而面向对象技术具有这些方面的优势，面向对象技术应用到数据库领域后，对象的使用就可以满足对这些类型数据的相关操作。

1.2 支持复杂的数据结构。传统的关系型数据库不能满足数据库设计的层次性和设计对象多样性的需求，关系型数据库中的二维表不能描述复杂的数据关系和数据类型，而面向对象技术中的对象可以描述复杂的数据关系和数据类型。

1.3 支持分布式计算和大型对象存储。面向对象技术中对象、封装、继承等方法的应用可以支持分布式计算，并且支持独立于平台的大型对象存储。

1.4 更好地实现数据的完整性。面向对象数据库支持复杂的数据结构和操作的约束、触发机制，从而可以更好地实现数据的完整性。

2、面向对象技术应用在关系数据库中的实现方法

由于计算机网络、多媒体技术、CAD/CASE等新型数据库应用的需要，数据库领域开始借助面向对象技术来满足这些需要。面向对象技术借助对象、封装和继承机制可以实现对复杂对象和复杂数据模型的支持，将面向对象技术应用于数据库是解决当今许多新型数据库应用中遇到的问题的好办法，虽然面向对象技术和数据库的结合沿着三个方向发展，当前多数数据库生产商都在研发如何将面向对象技术应用到关系数据库中。将面向对象技术应用到关系数据库中可以有两种方式。

2.1 把面向对象技术中的对象作为关系数据库系统中的一种新的数据模型。关系表中的属性值包含对象指针，对象数据的操作在关系数据库之外进行。把面向对象数据模型(ODM)和关系数据模型(RDM)结合起来，对荚系数据库管理系统进行扩充，但对象查询功能受到一定的限制。

2.2 把面向对象接口添加在关系数据库中。在关系数据库系统中增加一个对象到关系转换器，将上层的面向对象模式转化为关系存储模式，存放到关系数据库中。这样，在面向对象的数据库中关系存储模型位于底层。数据库用户可以利用标准的面向对象数据库语言进行查询处理，用户输入的面向对象数据库语言被转换成关系数据库语青，从而对底层的关系存储模式进行查询等处理，同时将操作结果按照对象方式返回给用户。这种实现方式使得数据库管理系统存实现关系模型和面向对象模型之间的模型转换时需要一定的开销，执行效率比直接面向对象数据库要低一些，但这种扩充方式实现比较简单。

面向对象技术通过映射接口和关系数据库相结合，面向对象数据库强调的是对象的属性、方法和对象间的关系。设计这种类型的数据库需要理解对象到关系数据库表的映射方法。这种映射方法通过将对象类生成为 SQL 语言中的数据定义语言(DDL)来将对象转换成一个好的概念层的数据模型(DDL)。

3、面向对象关系数据库系统的应用实例

3.1 系统构想。设想这个是物流信息 MIS 系统。该 MIS 系统有几种验证方法：（1）通过使用的和选择的物流公司。如果其在其业务的IP段的话，就认为是在物流公司上网，可认为是管理人员，将自动通过注册请求，系统发激活邮件；（2）不符合第一种情况的话，看选择的注册方式如果是使用 IP 电话的话去根据选择的物流公司看填写的 IP 电话是否符合所在区域的 IP 段，如果符合的话，系统发激活邮件；（3）选择物流公司邮箱注册，根据选择的物流公司和他填写的邮箱，如果域名符合就认为注册人为合法客户，系统发激活邮件；（4）选择其他方式，通过人工方法去确认注册者的合法性。以上是用户注册的过程，注册成功后，用户通过激活账户的链接，激活自己的账户，然后登陆，登陆成功后就可以使用注册用户可以使用的所有功能。管理员除可以拥有所有注册用户可以使用的功能外，还可添加物流公司及运单信息；编辑公司所在的 IP 段，查看所有用户的状态，进行活动管理，即添加、编辑活动，设定活动规则。应用系统需要响应用户的操作；另应用系统还需要给出各种各样的排行；需要按照规则确定活动的获奖者等：需要记录用户的操作，以确定用户的积分。

3.2 数据库部署。整个系统分为三层，客户层、业务逻辑层及数据访问层，选择 sqlserver2000 作为数据库。项目使用开发平台，用 c#作为开发语言，相应的使用 IIS6.0 作为Web 服务器。本系统的两种角色注册用户和管理员用户的问题，在上面的类结构设计时，让管理员继承的注册用户类，这样管理员就自然的拥有注册用户可以使用的所有权限，而它本身还可以拥有自己的权限，对物流公司的管理，对运单、货物及注册用户的管理。在页面类设计时采用这样的设计来确保使用页面的权限问题。设计三个类 BasePage、BasePageFor1.0gin、BasePage-ForAdmin，这三个类都继承自 System.Web.UI．Page 重载了 Ren-der 方法，这样就可以为同一级别的页面绘制相同的导航条，使页面的风格统一化；BasePage 类来作为未注册用户可以浏览的页面的基类，BasePageForLogin 类作为只有注册用户才可以浏览页面的基类，BasePageF0rAdmin 类作为只有管理员才可以浏览页面的基类。然后就可以在这些类的 render 方法中进行统一的权限设置及出错管理。

4、总结

根据目前计算机技术的走向，如今的数据库技术已不能满足计算机各个领域的需求，然而面向对象技术却很好的应用到现有的数据库中，其和数据库技术的结合应用已日趋被凸显出来。伴随着面向数据库技术的日益完善与成熟，它的影响必定更加深远，应用也将越来越广泛化。

数据库设计方案8

《数据库开发》是计算机专业的一门核心课程，通过本课程的学习，学生将能够进行初步的需求分析，根据分析结果设计数据库的概念结构模型和逻辑结构模型，并能够根据物理结构模型进行数据库实施和简单数据库应用系统的开发。本课程实践性非常强，注重培养学生的动手能力。所以，设计课程过程中，应该更加注重课程本身的实用性，更加注重课程内容本身与企业岗位的相结合。

《数据库开发》课程设计主要经历了企业调研、课程标准开发、课程方案设计等几个阶段。下面就分别说明一下课程设计的每个阶段。

1 《数据库开发》课程企业调研

进行企业调研是课程建设要进行的第一步，只有进行了充分的企业调研才能培养出满足社会和企业需求的合格人才。才能根据需求进行课程的设计，这样才能使学校的课程更加适合企业，更加适合社会。为此，我们的项目团队到企业进行了实地调研，我们获取到了企业对于学生的需求和对于课程设置方面的建议。

本门课程在进行企业调研之前已经根据之前的教学经验设置了本门课程的任务，具体任务设置如下：

任务1 数据库分析与设计

任务2 系统前台页面设计

任务3 数据库实现

任务4 系统后台实现

任务5 数据库维护

通过与企业专家进行研讨，最终获取来自企业关于《数据库开发》课程设计的建议。具体建议如下：

任务1 教学要求及建议：

①数据库基本概念和知识简单带过，达到了解的程度即可。

②需求分析难度较高，不建议让学生进行整个系统的需求分析，可以编写需求规格说明书的部分内容。

③进行数据库概念结构设计时，可以先画出系统的各个部分的E_R图，最后在将整个系统的E_R图画出来。

④可以使用PowerDesigner软件进行数据库的概念结构设计和物理结构设计。

⑤这部分内容比较难，需要多练习，可以适当多加一些课时。

任务2 教学要求及建议：

①本部分内容是对于之前所学网页设计和JSP的内容进行熟悉，可以以学生做为主。

②进行分小组教学，小组内进行角色划分，充分发挥团队的力量。

③因为是之前的知识可以适当减少课时。

任务3教学要求及建议：

①对于数据库管理软件可以选择相对比较容易上手的，如SQL Server、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 结论

由上面的内容不难看出，《数据库开发》课程的设计或者是其他技术类课程的设计，都应该注重实践，减少课程理论知识的讲解，将课程的理论知识融入到学生完成的典型工作任务中，真正要做到“做中学”，要重视课程本身与企业的关联，要做到课程为企业服务，另外，课程本身中的内容还要与时俱进，跟得上社会发展。

数据库设计方案9

一、行业分析以及人才培养目标

在当今这个信息爆炸的时代，人们越来越为在浩如烟海的资料中寻找有用信息而烦恼。特别是随着网络和电子商务的发展，面对越来越多的信息和数据，需要对其进行妥善保存及有效管理，这都需要大量的数据库管理员。随着信息系统数据库应用的重要性日益凸显，对从事数据库系统维护和数据库开发的技术人员的需求与日俱增，对其专业能力的要求也不断提高。

根据廊坊职业技术学院（以下简称“我院”）计算机科学与工程系计算机应用技术（软件开发方向）专业的人才培养目标，需要培养具备较强的软件开发、管理、维护等方面的能力，使学生成为精操作、能实践、懂管理、会维护的高素质高技能应用型人才。这些学生所面向的工作领域主要有：软件开发、软件运行维护、网站开发和数据库管理与维护等。这些岗位都需要具备数据库的相关知识和操作能力，因此数据库课程是本专业的基础课程。

二、课程建设的性质、定位与目标

数据库课程是一门专业基础课程。它的前导课是“计算机导论”“程序设计基础”，前导课为本门课程奠定了计算机基础操作能力和基础程序设计能力，它是“Web应用开发”“综合实训”等后续课程在后台数据库开发、管理、维护方面能力培养的重要途径，数据库课程为专业培养目标的实现起到了承上启下的作用。

数据库课程的总体目标是掌握数据库的理论知识，具备数据库的实际操作能力以及培养数据库管理的职业素质。具体来说，包括知识目标、能力目标和素质目标，其中知识目标是了解掌握数据库的原理等理论知识；能力目标是建立、管理和维护数据库；素质目标是通过小组学习形成团队意识，通过维护数据库安全，形成不恶意破坏数据库数据，不危害他人数据库的良好职业道德。

三、课程建设的理念与思路

高等职业教育培养什么人和怎样培养人，这是一切课程建设的基础。高职教育是培养生产一线的高技能应用型人才的教育。高职教育必须与岗位结合，必须与真实的工作任务和真实的生产过程相结合。数据库课程开发建设的指导思想是：以校企合作为基础，跟进主流技术，改革课程内容。以我院计算机科学与工程系为例，本系一直与相关计算机科技企业合作，根据技术发展，企业需要改革相关课程内容，本门课程经历了从最初的VFP到SQL SERVER到ORACLE再到MYSQL＼ORACLE的三次变革，适应了软件开发行业对数据库技术的要求。

课程内容选取和内容组织安排以专业的培养目标、服务领域、课程性质为依据，以岗位能力为核心，进行课程定位。通过对目前计算机行业，特别是一些网络公司的广泛调研，根据企业对技能型人才在素质和技能方面的要求，对本门课程的培养目标进行了重新定位。通过本门课程的学习，使学生具有较强的岗位能力，使学生的团队协作能力、收集处理信息能力、分析和解决问题的能力等各方面的培养都得到加强。专业技能达到能够进行分析、设计、开发和管理数据库的培养目标。

教学模式及教学方法设计的总体思路是整合理论，突出实践，实施任务驱动教学。对理论教学内容进行合理的整合和更新。将学术为主而在实际设计开发中无用的内容进行了大胆删减。同时将网络数据库的实践开发技术，如整体设计建设一个网络数据库纳入到教学内容中。实践教学内容由原来的了解认识已有的数据库改为设计开发新的数据库，实施任务驱动教学，强调动手，重视实训，充分体现了实践教学与社会需求的结合。

四、课程面对的学生基础及其智能特点分析

本课程所面对的基本学情是：学生的学习态度大都比较端正，其中约15%的学生（主要是职高对口生）相关知识基础好，在高中阶段系统地学习过数据库，有良好的学习方法，但对再次学习数据库兴趣一般；65%的学生，基础一般，对数据库的接触了解不多，但有一定的学习兴趣；大概20%的学生，基础差，不仅对数据库完全不了解，先修课程如“程序设计基础”等也没学好，几乎没有学习方法，对学习和程序设计看起来很相似的数据库没有兴趣。

通过学情分析，得出学生在学习过程中遇到的困难主要分为三类：基础好、学过数据库的学生在学习简单知识时，感觉听课没有热情，操作没有动力；大部分课程，大部分学生在听课时都能听懂，但自己动手时又往往想不到如何运用学到的知识，操作大都困难；基础不好的学生面对难度较大的内容，听课时产生畏难情绪，操作时不敢下手。

针对学情以及课程特点，在教学过程中我们指导学生采用以下学法：当课程难度较小时，为激发学生的学习热情，引导学生采取一题多解以及给自己出提高题，争取自己难倒自己的学习模式，即多样求解，自我设计；当课程难度适中时，为解决学生能懂不能做的情况，引导学生加强操作，边做边探索，也可与其他同学多交流，把别人的知识真正变成自己的，即自主探索，合作交流；当课程难度较大时，为便于理解，以联系实际学习，化难为简，与学生交流互动，启发学习，即联系实际，交互启发。

五、课程内容的选取以及教学组织安排

本课程内容选取立足于学习与工作的一致性，学习对未来工作的适应性，以工作任务整合、设计学习任务。参照企业的要求以及相关培训资料来进行课程教学，以校企合作为依托，跟进主流技术。

通过课程组教师深入、系统的分析，将教材中的章节重新编排，将教学内容总体安排为：数据库整体概述、Oracle SQL和PL/SQL三大单元。其中，数据库整体概述单元要求学习了解数据库发展历史，熟悉数据库开发环境，安排8学时；Oracle SQL单元要求学习掌握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.任务驱动，贯穿始终。课程内容贴近实际，整个实训操作以一个典型的数据库系统为例展开，按实际工作任务，以工作任务为导向，整合和优化教学内容，内容新颖，实用性强。

数据库设计方案10

1、课程指导思想

传统的课程内容陈旧而死板，侧重知识的罗列，实践案例少，并且与实际工作应用脱离，提不起学生兴趣。结合“sql数据库设计”这门课程的实际情况，我们的研究思路及重点是“培养学生的实际操作能力”，具体如下：

一是教学目标重心迁移，即从理论知识的存储转向职业能力的培养，导致教学方法逐渐从“教”法向“学”法转移，实现基于“学”的“教”。

二是教学内容重心迁移，即从知识的罗列、灌输转向动手操作、边做边学，利用项目案例，根据工作过程和知识点分布将其分解成若干个可操作性强的小项目，导致教学内容逐渐从“理论知识”向“实践应用”转移，实现基于“技能”的“传授”。

2、课程采用的教学方法

为培养学生的动手操作能力，在教学上，采用“项目”教学法，教师选取一个网站系统的数据库项目，教师分析和演示项目，然后学生对项目进行讨论；接着正式实施项目；然后演示项目结果，由学生阐述项目机理，教师总结归纳；最后由教师对学生的作品进行评估，并补充相关的拓展内容。通过采用项目教学法，让学生掌握数据库设计的方法，同时也学到了对应的技能点，从而将知识点融入项目训练中。与传统的教学方法相比，项目驱动教学法能更大地激发学生的学习兴趣和求知欲望，充分调动学生的学习积极性和主动性，从而培养学生自主学习、分析问题、解决问题的能力和协作、创新、探索的精神。

教师在项目教学中主要起引导作用，首先教师讲解项目背景，引入项目要求，然后由学生讨论及上机独立完成。通过这样的方法，学生在实践中思考的问题越多，学到的知识也就越多，对学习的兴趣就越浓厚，动手能力也从原来的照学变成了自主动手，培养学生的自学能力、创造能力，而这是当今社会最需要的。只有具有自学、创造能力的人才，才能在当今这个信息无限丰富的社会中立足，并能充分利用信息资源和技术，创造性地完成工作。

在实训过程中，教师充分体现学生的自主性和主体性，随时巡视，对学生解决不了的问题详细指导，以体现老师解惑的作用。在实训结束时，教师对项目及时点评，指出出现的问题及解决办法，总结所学技能点，从而巩固所学知识。

3、课程设计

本课程采用项目教学方式，以学生选课系统数据库项目为案例，课程共设计了十个项目，根据工作过程为导向设置了项目的完成顺序；同时依据各个项目涉及的知识点难度，又把项目划分了两个阶段。在本门课的教授中，让学生逐步掌握技能，最终使学生具备做数据库项目的能力。教师主要对学生进行方法上的指导为主，进而让学生进行实践。《sql数据库设计》课程内容组织如下图所示：

学生通过对上面所列的各个项目的操作练习，层层推进，逐步理解与掌握课程中操作要点，使学生最终能制作出综合数据库项目作品，达到企业要求。

4、课程评价设计

作为一门操作性和应用性非常强的课程，本课程的考核方式如果只取决于期末成绩，会使学生在平时的学习中不重视实践操作，只会在期末时突击完成任务。另外，传统考试中，以笔试为主，主要考察学生对书本知识的记忆，不利于扩大学生的知识面，忽视了对学生独立思考能力、知识的运用能力、创新能力以及其他素质的培养。

所以，在这门课的考核方式上，要把上述因素考虑进去，在期末成绩之外，平时表现也要作为考核总成绩的组成部分。因此，本课程的考评方式采用中间评价和期末评价两者综合的评价方式。中间评价占40%，期末评价占60%。

中间评价：主要由考勤、课堂任务考查、课后作业三部分组成。学生是否按时上课是学习态度问题，通过考勤登记了解学生的到课情况。在课堂项目考查中，老师检查学生每次课完成任务情况，对其完成情况进行评分。课后作业作为课堂所学技能的巩固和拓展，老师将每次课后作业收集，并进行打分和点评。每个项目的考核评价如下表：

期末评价：对学生进行综合项目评价，要求学生自行分组，在期末制作完成一个信息系统的数据库项目（如人才招聘系统、酒店管理系统等）。期末项目完成后，分组进行项目的展示与讲解：用3-5分钟的时间对本组的所做的项目进行展示与讲解。具体考核标准为：

在课堂中对《sql数据库设计》课程通过应用上面的项目教学方法进行教学，教学效果良好，学生的动手能力得到了很大提高，实现了教育部提出的高职高专教育要培养可持续发展的“技术型”人才的培养目标。学生的自主探索能力及自学能力、创造能力得到提高，在课程结束时学生能制作出数据库项目作品，适应企业的需要。

数据库设计方案11

一、数据库是信息系统的核心和基础技术，是计算机学科领域中发展最为迅速的重要分支

其技术在各行各业中已得到广泛应用，在财务会计、生产物资、图书资料、科研项目、生产调度、经营计划、财政税收、银行帐目、人事档案等各个部门，已经建立了成千上万个信息系统，和我们的工作、学习、生活紧密相连，密不可分。在世界已进入信息化社会的今天，数据库的建设规模，数据库信息的多少和使用频度，已成为衡量一个国家信息化程度的重要标志。因此在职专信息技术教育课中开设数据库和程序设计知识的学习是十分必要的。在职专阶段让学生学习程序设计初步，是为了使学生初步学习结构化程序设计的基本思想和基本方法，培养学生的分析能力和逻辑思维能力，培养学生的创新精神。通过对这部分知识的学习，使学生初步掌握相关的基础知识，培养他们的信息意识，使他们在思想认识上跟上迅猛发展的信息化世界。同时通过对数据库知识的学习，可以开拓学生的视野，使他们认识到计算机并不是只能做文字录入和文字处理工作，也不光是上上网，收发电子邮件。用计算机来科学地保存和管理大量的、复杂的数据，进行大量的信息处理，已经成为计算机应用的一个十分重要的方面。学习数据库和程序设计初步知识后，指导学生用所学的知识去解决他们身边的数据处理问题，可以极大地激发学生的学习兴趣，培养他们的应用能力和创造能力，提高学生的整体素质。因此职专阶段信息技术课中，数据库和程序设计部分的内容应放在比较重要的位置上。

二、数据库管理系统种类繁多，比较流行的有dBASE、FoxBASE、FoxPro、Visual FoxPro等几种

那么，在职专阶段，学生应该学习哪一种系统比较适合呢？有的教材选用dBASE系统，有的教材选用FoxBASE系统，也有选用FoxPro系统的。笔者认为选用FoxPro系统较为适合。笔者参与编写的梅州市信息技术教育课教材（职专第二册）数据库和程序设计部分，就选用了FoxPro 2.5系统。这是因为从数据技术的发展过程来看，尽管dBASE、FoxBASE曾经在全球风行一时，但相对FoxPro、Visual FoxPro，就显得有些过时了。dBASE系统运行速度慢，人机界面差，命令和函数有限，无编译程序；FoxBASE比dBASE稍好一些，但人机界面差，无真正的编译功能等。因此，当运行速度更快、功能更加强大、具有真正的编译能力、人机界面良好、可采用菜单驱动的FoxPro系统问世后，还把dBASE、FoxBASE作为数据库技术的典型教材来学习，显然是不合适的。相对于FoxPro来说，Visual FoxPro更为先进，为什么又不选用Visual FoxPro系统呢？这是因为Visual FoxPro系统是在Windows平台上运行的软件，对计算机硬件要求较高，目前有许多学校的硬件条件还达不到要求。FoxPro系统在技术性能上，恰好能承上启下，FoxPro系统完全兼容dBASE、FoxBASE的操作，和最新流行的Visual FoxPro也有很大的兼容性，在FoxPro 2.5环境下设计的程序和数据库，不经修改就可直接在Visual FoxPro下运行，并支持流行的SQL语言，支持多用户和网络技术。FoxPro能在大部分486、586单机或网络上运行，目前绝大多数中学的计算机硬件条件能够达到这个要求。因此笔者认为，职专阶段信息技术课的数据库部分选用FoxPro 2.5系统最为适合。

程序设计初步也是职专阶段信息技术课的必学内容之一。在有的教科书中，这部分知识往往选用BASIC或PASCAL语言。这样的安排，固然有其好的一面，但因其是与数据库系统完全不同的两种语言，作为职专阶段的学生，在有限的学时内要学习两种计算机语言，而这两种语言又缺乏一定的连贯性，必然是有困难的，结果会造成两个部分都学不好。笔者认为在程序设计初步这部分内容中，同样可以选用FoxPro来进行学习。职专学生在学习了FoxPro系统数据库知识后，接着就运用FoxPro来学习程序设计基础知识具有许多优点。因为FoxPro不仅是一种优秀的数据库系统，其本身也是一种高级程序设计语言，用它同样能够设计出用PASCAL语言设计的程序，用FoxPro设计出来的程序同样能够符合结构化程序的要求。而且在学习过程中，可以随时和前面学习到的数据库知识联系起来，使其更具有实用性，更能激发学生的学习兴趣，做到数据库知识和程序设计知识前后贯通，互相呼应，更有利于学生全面掌握数据库知识和程序设计基础知识。

三、由于数据库和程序设计初步内容的理论性较强，学生在学习这部分知识时往往感到难度较大

要搞好这部分内容的教与学，笔者认为必须在以下几个方面去下功夫：

密切联系实际，激发学生的学习兴趣

数据库设计方案12

1研究背景

数据库原理及应用课程一般包含数据库原理与数据库应用开发两个部分的内容。原理部分以数据库设计方法为目标，重点讲述数据库的基本概念、基本原理以及基本技术；应用部分以现实需求为基础，应用数据库设计方法，在数据库管理系统支持下，采用程序设计语言实现应用系统的详细过程。数据库课程的教学目标就是要求学生掌握数据库设计方法，同时掌握数据库应用系统的开发过程。但传统的教学内容主要以原理为核心，较少涉及数据库系统的应用，教学过程较为抽象，缺乏直观性，学生在学习过程中很难深入理解这些原理。因此，必须大力加强数据库应用实践教学，使“原理”与“应用”并重，用“应用”带动和强化“原理”内容，用“原理”指导“应用”的教学效果。

结合我院数据库原理及应用国家精品课程建设，我们已经建立了“数据库原理及应用”的教材体系[1]，并建设了相应的实验体系、考试体系以及网络课程等。在实际的教学过程中，为适应新的教学需求，改变重原理轻实践的状况，我们不断对实验体系进行改进，并应用于实践教学中，不断改革数据库实践教学，取得了良好效果。

2课程特点

数据库原理及应用是一门兼有理论和实践的综合性课程。它不仅要求学生掌握课堂理论知识，更重要的是，通过大量的实践教学，使学生能够结合一种数据库管理系统，利用程序设计语言，设计出一个小型的数据库应用系统。基于这样的要求，该课程就不仅仅是单一的课堂理论教学，而应该是一个完整的集理论教学和实践于一体的教学体系。图1列举了课程的内容体系。

数据库原理及应用课程的内容体系分为3个部分，分别为数据库原理、数据库管理系统DBMS以及面向对象的程序设计语言。因此，数据库课程教学必须与这3部分内容相适应，将基础知识讲授、上机操作等方式作为课程内容的支撑系统。使学生掌握数据库设计的理论方法，在某种数据库管理系统的支持下，用面向对象的程序语言完成数据库应用系统的设计。

可见，在数据库课程的教学过程中，理论课与实践课必须齐头并进。理论必须通过实践来贯彻，而实践课又要建立在理论课的基础之上，过去那种重理论轻实践的思想已经不能适应新的人才培养目标。在数据库原理的理论课讲授中，我们采用了多层次、多环节的案例驱动导学模式，促使学生结合案例理解数据库设计的思想。并通过搭建内容合理、与课程内容相配套的实验体系加强学生的实践能力与自主学习能力。

3实践教学改革

在多年的教学过程中，我们不断改进教学方法，对实践的要求不断加强。结合国家精品课程的建设任务，我们对数据库课程的实践教学也进行了相应改革。从过去的附属式实验课到与课程内容相配合的跟随式实验，再到结构化实验，我们在实践教学的要求、方法及手段上都进行了大力改进。

3.1附属式实践教学

附属式实践教学就是将实践课作为理论课的附属，在理论课结束后，集中安排一部分课时上机，进行数据库的实践[2]。对于本科60学时的数据库原理及应用课程，通常安排课内上机10学时，课外上机10学时。上机课一般选用Access或Visual Foxpro这两种数据库管理系统，因为其简单易用，上手快，不需要花费太多时间去摸索复杂的软件系统。上机时，学生以小组为单位，每个学生独立上机，并进行小组内讨论，以每个小组选定的一个信息管理系统的课题为内容，在数据库管理系统的环境下，进行数据库设计、表设计、SQL查询设计以及应用程序的表单报表等设计。通常将20学时的上机课统一安排，2个学时一次课，一次课完成一个目标，最后每个小组分别完成一个数据库信息管理系统应用项目的开发，并提交一份实验报告，描述整个系统设计实现的过程。

附属式实践教学有利于学生集中精力，在短时间内结合理论知识，进行数据库系统的开发设计。但由于其不能主动结合理论知识，在实践过程中，容易造成理论与实践的脱节。学生上实验课时，对数据库管理系统较为陌生，对实验课的总体要求感觉难度较大，也没有编程语言的前序学习基础。因此，除少数自学能力较强的学生能够按时按要求完成实验课程，并通过实验课进一步掌握了理论知识，达到理论与实践相统一的效果外，大多数学生没有深刻理解和掌握数据库原理及应用课程的教学要求。

3.2跟随式实践教学

跟随式实验指实验课紧紧跟随着理论课的进度而开设，选用的数据库管理系统为SQL Server 2005。在数据库原理课程的教学中，用一个学生容易熟悉的大案例――教学管理系统开展，有顺序地介绍数据库的基本概念、关系代数、SQL语言、关系数据库模式设计方法、数据库应用系统设计以及数据库的保护技术等内容[3]。我们选用由李俊山教授等编写、清华大学出版社于2009年出版的教材《数据库原理及应用(SQL Server)》[1]及配套教材《数据库原理及应用(SQL Server 2005)教学指导与习题解答》。通过深入理解数据库课程的特点，制定了数据库实践课程的内容，分成5个实验，如表1所示。

表1中列举的实验内容跟随着理论课的进度开设。当学完相应的理论课内容后，就立刻安排一次实验课，以利于知识的保鲜和巩固。在学习完数据库的基本概念后，安排一次集中上机操作，内容是“认识SQL Server”，教师通过演示SQL Server的安装过程以及软件模块，并结合科研成果，展示一个在SQL Server下开发的数据库应用系统，让学生对数据库有一个感性认识，结合理论内容，初步了解数据库的概念含义。在学习了关系模型后，学生就可以进行“数据库的基础操作”的实验了。数据库的基础操作实验包括建立数据库、建表等内容，直观地让学生了解关系模型的二维表格形式表示的形态和建立方法。交互式SQL语言实验课是在学生学习了关系数据库语言SQL的理论知识后进行的，通过交互式方式，在SQL Server中完成表和视图的定义、数据的查询以及数据更新操作。完整性控制和恢复实验的目的是让学生对SQL Server中表的完整性和数据恢复有直观感受，能够独立地根据需要设置数据库完整性控制，并理解数据库恢复的重要性。最后，在理论课结束后，再进行一个数据库应用系统设计的大实验，相当于课程设计。

跟随式实验是对附属性实验的改革，它解决了附属性实验理论与实践容易脱节和遗漏的缺点，使学生对知识现学现用，容易理解，兴趣较高。在近几年的教学中，我们采用跟随式实验，学生的实践能力得到了明显提高。但跟随式实验没有考虑到学生运用程序设计语言开发数据库应用系统的困难，在数据库应用系统设计的大实验中，往往完成得较粗糙。

3.3结构化实践教学

结构化实践教学是将数据库原理及应用课程分成3个部分，分别为数据库原理40学时的理论课、面向对象程序设计20学时和数据库课程设计20学时，如表2所示。

其中，数据库原理为理论课，讲述数据库设计的基本理论。面向对象的程序设计课为实践课，通常安排在机房上课，一人一机。考虑到开发数据库的支持性与面向对象程序设计的通用性，选择PowerBuilder程序设计语言作为编程语言。课程设计课也是在机房上课，主要内容分为两部分，一为学习SQL Server或Oracle数据库管理系统，第二为课程设计。教师准备8～10个数据库课程设计课题，一般选择较为实用、贴近生活、学生容易理解的课题，比如学生成绩管理系统、图书管理系统、工资管理系统等。学生分成3～4人的小组，每组选择一个课题。学生从数据库设计规划、系统需求分析、概念结构设计、逻辑结构设计，再到物理结构设计，最后结合程序设计语言完成数据库应用行为设计。

结构化实验教学与数据库课程内容体系模式相一致，能够较好地解决在数据库理论知识与实践内容学习中的脱节问题，大大提高了学生采用数据库设计思想，结合程序设计语言进行数据库开发的能力。通常在学习了数据库原理及应用结构化教学内容后，绝大部分学生都能深刻理解数据库的设计过程，通过小组合作解决问题，提高自主学习能力，并能够独立完成一个小型数据库应用系统的开发。

4考核方法与教学效果分析

按照结构化实践教学的过程，我们对学生成绩考核方法也进行了相应改革。考核分为3个部分，分别为数据库原理的笔试考核、程序设计能力考核以及课程设计考核。在原理的笔试考核中，并不单纯以期末理论考试为评分依据，还融入了平时成绩以及课堂实践的考核。成绩标准为笔试成绩(50%)+单元测试成绩(40%)+平时表现成绩(10%)。程序设计课程用考查方法检验成绩，即上机考试，按照完成的既定程序设计科目给分。课程设计的成绩评定也分为3个部分，分别为程序演示(50%)+课程设计报告(30%)+答辩(20%)，按小组评定成绩。通过多角度全方面考核，根据学生掌握知识和实际付出的努力情况进行成绩评定，有助于教师掌握学生对知识的理解和熟练应用程度，还可以正确反映学生实际学习情况。

通过结构化实践教学，该课的教学效果显著提高。在近3个学期的数据库课程教学中，数据库原理及应用三个阶段的课程成绩中，综合成绩在80分以上的人数比例占到了35%，较之过去的20%有了大幅度提高。成绩在70～80分之间的人数比例占到45%，较过去的30%也提高了很多。不及格率由过去的10%下降到了3%左右。学生在学习完数据库原理及应用结构化课程体系后，在毕业设计以及程序设计比赛中都体现出了较强的能力。

5结语

数据库原理及应用是一门理论性和实践性都较强的课程，只有加强实践教学的训练，理论知识才能得到有效巩固。在多年的教学过程中，我们不断对实践环节进行改革与探索，加强实践教学，通过专门开设课程设计这门课，让学生在完成一个有分量的课题作业的过程中，多练习、自己学，在做中学。实践表明，数据库原理及应用课程的实践教学改革，提高了学生的学习兴趣，培养了学生使用数据库原理和方法解决实际问题的能力，提高了学生的分析、归纳、设计和编程的能力，加强了学生自主学习和实际动手能力，提高了学生团队合作以及研究创新能力。

随着计算机科学的不断发展，数据库技术也在不断的发展中。随着教学内容的不断更新，我们除了在教材建设方面下功夫，教学方法也需要不断改革和创新。因此，我们将根据学生情况，及时总结教学经验，调整教学方法，设计实践教学环节，注意教学节奏，结构化分阶段地进行实践教学，使数据库原理及应用课程的整个实践教学更加合理、完善。

数据库设计方案13

考虑性能的时机

考虑应用程序和数据库各自不同的性能特征的时间，是在对这些应用程序和数据库进行设计的初始阶段，即开发过程的一开始。对你的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的代码经过了优化。如果记录是固定长度的，那么它就永远不需要从原来存储的页中被移动出来。然而，可变长度的记录可能增长到不再适合原来页的长度，因此它也就必须被移动到另一页。无论何时记录被顺序访问，都一定会出现一个额外的参考页。DB2 UDB V8中的一个新特性就是当你不确定未来的数据长度增长情况时，允许你根据需要改变列的尺寸，这样你就可以不再需要创建可变长度的记录。

每页中记录的数量也是需要考虑的内容。DB2提供了一些有关页尺寸的选项，例如4 KB, 8 KB, 16 KB和32 KB 。比较好的起点是选择默认的4KB，特别是当行的尺寸相对较小，或者是对数据的访问比较随机的情况下。然而，在一些情况下，也需要考虑较大的页尺寸。如果表中单个行的长度超过4KB，那么你就需要使用大一些的页尺寸，因为DB2不支持跨行的记录。

还有另一种情况是，当固定记录的总长度比二分之一的页（4KB）稍大一些的时候，一页中就只能放置一个记录。另外一种类似的情况是，固定记录的总长度略长于三分之一页、四分之一页，等。这样的设计不仅会浪费DASD空间，还会导致很多的DB2操作消耗更多的资源。因此，对于上面描述的记录而言，你需要考虑使用较大的页尺寸，这样就会相对地少浪费一些空间。

另外一些可能的页尺寸为8 KB, 16 KB和 32 KB。页的尺寸并不在创建表（CREATE TABLE）的语句中直接写明。相反，表中页的尺寸是由分配给包含这个表的表空间的缓冲池中的页尺寸决定的。要获得更详细的信息，你可以参考DB2 SQL 手册中有关创建表空间（CREATE TABLESPACE）语句的内容。

非标准化考虑事项

逻辑数据模型是数据的一个理想描述。物理数据模型则是数据在现实世界的实现。标准化只集中在数据的内涵上面，而不考虑可能访问数据的应用程序的性能需求。数据库设计的充分标准化会带来性能的挑战。

有关此类性能问题的一个非常常见的例子就是连接操作。通常情况下，标准化过程的结果是给各个独立的表赋予相互关联的信息。应用程序需要从这些表中访问数据。关系数据库提供了使用SQL语句来从多于一个的表中通过连接多个表去访问信息的能力。取决于表的数目和它们各自的尺寸，连接操作可能会消耗非常多的资源和时间。

因为在I/T中有如此多的事情需要考虑，于是出现了一个折中的想法。对那些包含被频繁访问列的多个表中的数据保存副本，与连接表的性能相比，成本高还是低呢？在逻辑数据库设计过程中，对你的数据模型尽量的执行标准化，之后再对其进行一定程度的非标准化，也许是进行潜在性能优化的一个选项。如果你决定进行非标准化了，要确保从头到尾地记录了文档：对某些细节的描述、执行非标准化步骤之后的推理，等。

设计较大的表

访问很大的DB2表需要消耗相当多的资源：CPU，内存，I/O。当设计大表的时候，用户需要做的两件最重要的事情就是：

实现分区

创建有用的索引

以上两个问题将在下面进行详细讨论。

使用分段或者分区表空间

如果数据中包含了LOB，那么用户就必须创建LOB表空间。对于非LOB的数据，通常的选择是分段或者分区表空间，具体选择哪一个在很大程序上取决于你要存储的数据量，同时还需要考虑相关应用程序需求的数据访问类型。不太推荐使用单一的表空间。

分段表空间比单一的表空间具有更多的性能优势，如下所示：

对于包含多于一个表的表空间，当DB2在一个表上获得锁定时，那个锁定不影响其他表分段的访问。

当DB2扫描一个表时，只访问与那个表相联系的分段。此外，空分段的页不会被取出。

如果一个表被清除了，不需要执行REORG实用工具集，它的分段就立即在COMMIT点上变成可再次使用的状态。

如果一个表中的所有行被删除了（被称为块删除），不需要执行REORG实用工具集，所有的分段都立即在COMMIT点上变成可再次使用的状态。

块删除操作起来更加有效，并且书写相当少的记录信息。

COPY（复制）实用工具集不复制由于块删除或者表清除所造成的空页。

当表达到一个特定的尺寸，它们的可管理性和性能都可以通过分区表空间获得改善。如果你想获得这方面的进展，在设计和创建时，以分区的形式定义表空间是一个明智的做法。分区表空间的一些潜在优势列举如下：

并行性：你可以利用三种类型的并行性，它们目前正应用于DB2 UDB。DB2 V3引入了查询并行性（多个I/O路径）。DB2 V4则实现了CP并行性（多CP之上的多任务）。DB2 UDB V5更是引入了系统查询并行机制（多个DB2数据共享群之上的多任务）。DB2的发展进化，显著提高了DB2应用程序处理分区表空间的并行处理能力。由于CPU时间的增加，这些查询所消耗的时间也显著的减少了。

在数据的一部分上工作：分区表空间允许DB2应用程序一次运行数据的一个分区，因而使其能够同时运行另外分区上的另外的工作或者应用程序。以同样的方式，你可以将块UPDATE（更新）、DELETE（删除）或INSERT（插入）操作分解为独立的工作。除增加了可用性之外，这一技术也为完成这类DB2工作减少消耗的时间提供了可能。

更快的访问被频繁访问的数据：如果分区索引能够将更多的频繁访问的行从剩余的表中分离出来，然后将那些数据置于一个它自己的，并且应用更高速DASD设备的分区之内。

一般而言，表越大，就越应该将其创建为一个分区的表。但是也有一些实际例子表明为小表创建分区表空间是有利的。当查找表用于连接其他大分区表空间时，通过将查找表分区，你能够使并行性在连接中最大化。

当你在连接谓词中利用分区方法时，需要考虑一个决定性的因素。被连接在分区方法上的表应该具有相同的分区数，并且应该设定为相同的值。

数据压缩 DB2提供了压缩表空间或分区内数据的功能。通过指定CREATE TABLESPACE（创建表空间）语句中的 COMPRESS YES（压缩许可）选项，之后在表空间上同时执行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资源。

数据库设计方案14

载入大表

在处理大批量数据时，将数据初始载入表中可能会对系统性能产生挑战。为了在载入过程中实现并行性，你可以手动创建多个LOAD作业，每个分区建一个；或者作为另一个选择，你可以在一个LOAD程序中载入多个分区。每个分区都延伸至I/O子系统，这种方式可以更容易地实现最理想的并行性。

为了使性能最优化，在LOAD语句中指定SORTKEYS参数也很重要。这个参数指示DB2将索引方法传递给内存中的分类程序，而不是将关键字写入或者再次读取DASD上的排序任务文件。SORTKEYS也能够实现载入和分类之间的交迭，因为分类是作为一个独立的任务运行的。

还有一些关于载入大表的额外的建议，如下：

一次LOAD一个表。

如果可能的话，为你预期的任务赋予较高的优先级，来获得最高的消耗时间。

在系统综合体上分配工作。

将二级索引分解为小段，以便获得并行性（见PIECESIZE内的讨论）。

在数据的初始载入过程中，指定LOG NO（用于防止记录日志，它耗费了相当多的资源），在成功载入数据之后运行一个图像复制。

自由空间考虑事项

分配自由空间的主要目的，是为了将数据行保存在相同的物理序列中作为群集索引，这样一来将减少需要重新组织数据的频率。此外，较好的行聚簇将导致更快的读取访问和更快的行插入。但是，自由空间的过度分配又将导致DASD空间的浪费、每一个I/O传输的数据较少、缓冲池的利用效率较低，以及需要扫描更多的页。

表空间和索引中的自由空间分配，由CREATE或ALTER TABLESPACE和CREATE或ALTER INDEX 语句中的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值。通过设定REORG TABLESPACE中的INDREFLIMIT和REPORTONLY选项，你就能够在更新后的DB2表中监视紊乱的数量和速度。

插入一个热点：这是表具有很频繁的插入活动的情况，这种插入活动集中在一个位置（或多个位置），而不是正好处于表的末端。这可能是要应付的最困难的种类。试着增加PCTFREE的数值。如果插入保持在开头的段，行也不是很长，几行可以存储在同一页之内。FREEPAGE是在这种情形下另外的一个考虑。有必要严密监视表变乱有多么快，这样就可以在性能显著下降之前运行REORG。

索引设计考虑事项 索引是一个DB2对象（独立的VSAM数据集），它是从相应表中的一个或更多列中摘录出来的一系列有规则的条目。很多DB2专家主张为一个表空间建立恰当的索引，这也许是将访问DB2数据应用程序的性能最优化的惟一最有效的方法。几年前，在I/T中DASD的成本和空间是一个更重要的考虑因素。随着技术的发展，通过以特大硬盘为代价，加上更多索引（或增加现有索引的列）来减少I/O的折中方法，在这几年里越来越具吸引力。索引主要的性能优势表现在：

为表中被请求的数据行提供直接指针

消除了排序，如果结果集的请求顺序与索引相匹配的话

避免了必须读取数据行，如果被请求的列全部包含在索引条目中的话

分区索引

当在DB2 UDB V7中创建分区表空间时，DB2依照CREATE INDEX语句中的PART子句将分区中的数据进行划分。那个索引则成为所谓的分区索引，这种分区方法被称为受控索引分区。为了对索引进行分区，建议你选择不易改变的关键列。对这些列的更改可能使得一个行从某一分区移动到另外一个分区，从而导致性能下降。

受控表分区是DB2 V8的一个重要的特征。现在，当创建分区表时，分区界限的确定由CREATE TABLE语句代替了原来的CREATE INDEX。在受控索引分区中，分区表的、分区索引和聚簇的概念全都结合在一起。而对于受控表分区，这三个概念是独立的。这就增加了灵活性，允许你去考虑更有潜力的设计方法；并且也因此增加了改善DB2数据库及其应用程序性能的可能性。

构建索引的时机

CREATE INDEX（创建索引）

CREATE INDEX语句使用户具有了这样的能力：立即构建索引，或者将构建推迟到更加方便的时间。如果你立即构建索引，将会对表空间进行扫描，这会占用相当长的时间。通过设定DEFER，你可以推迟索引的构建。

无论什么时候，只要可能，在最初载入一个表之前创建表上的所有索引，因为LOAD实用工具集构建索引比CREATE INDEX过程更加有效。如果你需要在已存在（并且有很多数据）的表上创建一个索引，那么可以使用DEFER语句。稍后，你就可以用REBUILD INDEX实用工具集，它和LOAD实用工具集一样，是一种更加有效的填充索引的方法。

PIECESIZE（片段尺寸）

DB2 UDB V5引进了一个新特征，它给了你一定的灵活性，从而可以将非分区索引（NPI）分解为小段，并且控制组成索引空间的多个数据集的大小。分段的这种用法能够使一个NPI的索引页展开为多个数据集。

片段的尺寸由CREATE或ALTER INDEX语句中的关键字PIECESIZE确定。PIECESIZE的值必然是两个强制值中的一个，其变动范围为最小256KB到最大64GB。常规表空间的默认值为2GB，大的表空间默认值是4GB。如果你的NPI有可能显著增长，那么选择相对较大的表空间。同样，在确定首要和次要的空间分配数值（CREATE INDEX语句的PRIQTY和SECQTY选项）时，记住PIECESIZE的值。

利用这一选项，可以通过发挥并行性来改善NPI的扫描性能。另一个优势是可以减少读取或更新过程中的I/O冲突。通过设定较小的PIECESIZE值，你可以创建更多的片段，因而对片段的位置有更好的控制。将片段置于独立的I/O路径，可以减少了访问NPI所需的SQL操作的冲突。

理想的索引

通过检查一个应用程序中的SQL语句，你可以建立一个假想的完美的索引。

首先，索引所包括的所有列都是WHERE子句，这使得索引的审查可以用于将不合格的行拒于结果集之外。将这些列放在索引的开始。当在SQL语句上执行EXPLAIN时，这会使得MATCHCOLS的价值最大化。

其次，确保索引以适当的顺序含有这些列(依照ORDER BY子句)，从而可以避免进行排序。这可以在执行EXPLAIN时，通过检查PLAN_TABLE的所有不同的SORT*列来验证。

最后，如果可能的话，将所有的列包含在索引的SELECT中，这样就不需要访问表中的行了。索引条目可以提供所有的请求数据。这将在EXPLAIN中以INDEXONLY = Y的方式表现出来。

在很多情况下，实现如此理想的索引的代价太大了，或者说是不切合实际的，甚至是不可能实现的，因为所涉及的列的数量太大了。组成一个索引的列的数目在体系结构方面有限制，并且对于一个索引条目的总长也有限制（尽管这些限制实际上允许相当大的索引条目尺寸和灵活性）。此外，这也是出于索引维护成本的考虑。建立理想的索引可使查询性能获得极大提高，但是对于SQL写入DB2数据库（INSERT、UPDATE或DELETE）就有消极的影响。因此，你应该经常选择实现只包含WHERE和ORDER BY语句中涉及的列的索引。

并行处理的考虑事项

几年来，通过实现了并行处理的各种方法，DB2在数据访问方面的性能获得了改进。为了改进数据密集型只读查询的性能，DB2 V3引进了查询I/O并行机制。在这种类型的并行性中， DB2充分利用了可用的I/O带宽，并使分区表空间中成为可能。利用这种方法，DB2使得一个查询中的多个并发I/O请求可同时进行，并在多个数据分区中执行了并行的I/O处理。这代表性地使得I/O绑定查询所耗费时间的显著降低，同时出现了CPU时间的较小增长。

DB2 V4引入了另外的并行性技术，称为查询CP并行性。该方法将并行处理扩展至处理密集型的查询。用该方法，单个查询可使DB2生成数个任务，并行执行数据访问。对于这种类型的并行性，分区表空间显示出最佳的性能提升。

DB2 UDB V5通过引进综合系统查询并行性，更进一步地扩展了并行处理。当查询CP并行性在DB2子系统中为某个查询使用了多个任务时，该方法使得DB2数据共享群中的所有成员能够处理一个单一的查询。主要为只读形式的I/O密集型和处理密集型查询可以从这种类型的并行性中获益。

并行访问的授权

在DB2环境下使系统获得并行性能力有一定的难度。首先，在DB2子系统级别，并行访问由安装面板DSNTIP4控制。DSNTIP4上的MAX DEGREE 选项决定并行性的最大程度（并行任务的最大数目）。默认值为0，意味着对于DB2可调用的并行性程度没有上限。我建议你估计虚拟存储容量，以及你的z/OS环境限制，还应根据需要调整该参数，因此DB2将不会创建超过你的虚拟存储容量可以应对的并行任务。

通过BIND PLAN和BIND PACKAGE命令的DEGREE选项，你能够控制DB2是否使用并行处理。设定DEGREE(1)阻止并行处理，而DEGREE(ANY)允许并行处理。为了获得进一步的灵活性，动态SQL允许在一个计划或包内更改该选项，通过SET CURRENT DEGREE语句即可实现，SET CURRENT DEGREE语句用于控制某个寄存器中的数值。

当一个计划或包与DEGREE(ANY)绑定，或者CURRENT DEGREE寄存器设定为ANY时，DB2优化器考虑并行性是否是可能的，从而获得最有效的最终计划。如果并行性是不可能的，那么将会选择下一个允许并行性的最有效的最终计划。

限制分区扫描 限制分区扫描是允许DB2在分区表空间中限制数据扫描的一种方法。根据SQL谓词的值，DB2能够决定最低和最高的分区，这可能包含了被SQL语句所请求的表的行，之后便将数据扫描限制在分区的范围内。为了使用该技术，SQL必须提供一个在分区索引的第一个关键列上的谓词。

数据库设计方案15

并行性建议

为了使并行处理的性能最优化，需要考虑以下事项：

尽可能均匀地对表空间进行分区，因为并行性程度会受到数据不均匀的影响。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为你提供了改进缓冲池性能的额外灵活性。关于这些阈值的进一步详细讨论见DB2 SQL参考手册的2.7.4部分。

缓冲池的合适大小

缓冲池尺寸的指定取决于可用的存储量（包括中央部分和扩展部分）。我建议你分析一下缓冲池分配，并且增加它的尺寸直到再也没有由于增加的分配而产生的额外吞吐量，或是MVS分页速率到达不可接受的程度。这将通过逐渐增加的VPSIZE来实现，只要DASD I/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应用程序提供最优化的性能。

以上就是“数据库管理系统设计方案范文”的相关内容啦。数据库设计是数据库系统中非常重要的一环，它可以提高数据的可靠性、安全性和可维护性，从而满足用户的需求，保证数据库系统的稳定运行。