在数据库设计过程中要注意哪些问题？

DB2数据库的性能与稳定性直接跟数据库对象的多少、大小有关。如果对象很少，不复杂，那么就算不怎么规划，也能够达到比较高的性能。如果对象数据比较多、比较大的话，那么就需要在数据库设计之前好好的规划，否则会在很大程度上影响数据库的性能与稳定性。

一、选择合适的语言与数据库字符集。

在企业中部署数据库的时候，首先需要在 *** 作系统上安装数据库。而在安装数据库的时候，需要选择安装的语言环境。即是以中文状态下安装数据库还是以英文状态安装数据库。如在启动安装程序的时，可以利用/i language选项来指定安装过程中所采用的语言。到目前为止，DB2数据库已经支持很多种语言。那么数据库在安装过程中，该采用什么语言呢？笔者建议，只要数据库管理员有一点英语基础，最好能够采用英文语言环境来进行安装。虽然说现在DB2数据库的中文语言环境已经设计的比较完善，但是笔者仍然担心其有一些不知名的漏洞。为此笔者在安装DB2数据库的时候，基本上都采用的是英文语言环境来进行安装。即将语言设置为“EN”，表示英文。提高DB2数据备份与恢复的效率。

另外如果DB2 数据库中要保存英文以外的数据，或者说用户会使用不同的字符集访问数据库时，还需要在数据库安装过程中选择特定的数据库字符集。DB2数据库中的所有字符数据，包括数据字典中的数据，都是存储在数据库字符集中的。如果用户使用不同的字符集访问数据库时，数据库管理员就需要选择包含所有这些用户的字符集的超集。只有如此，才能够确保系统能够很方便的使用替代字符完成字符的转换，从而提高数据库的性能。如果用户选择的字符集不对，有可能会出现一些莫名其妙的问题。如一次用户在安装数据库过程中，没有选择合适的字符集。虽然在使用的过程中，其存储中文字符没有问题。但是当对数据库采取还原 *** 作时，却发现还原后的数据库中有些原来是中文字符的地方，尽然出现了乱码。这主要就是没有选择合适的字符集惹的祸。有时候如果字符集选择不当的话，从外部数据源(如Excel表格)导入数据的时候，中文数据也会无法顺利导入。所以，数据库管理员在安装数据库的时候，需要根据实际企业，来选择合适的字符集。

二、评估数据库对象的大小、数量。

DB2数据库的性能与稳定性直接跟数据库对象的多少、大小有关。如果对象很少，不复杂，那么就算不怎么规划，也能够达到比较高的性能。如果对象数据比较多、比较大的话，那么就需要在数据库设计之前好好的规划，否则会在很大程度上影响数据库的性能与稳定性。其实DB2 数据库就好像一个仓库，数据库中的对象(如索引、数据表、表空间)等等就好像仓库中的货物。如果货物比较少，那么随便放放，仓库都显得很空旷。货物寻找起来也会很方便。但是如果货物数量比较多、比较大，就必须要对其存储空间进行合理规划。只有如此才能够让仓库的空间利用率达到最佳状态。并且货物的存放有序，在查找起来也特别的方便。笔者这里就以仓库管理为例，说话该如何做好数据库对象大小、数量等方便的评估，以及他们对于数据库性能与稳定性的影响。

1、根据对象大小来规划存储空间。在仓库货物的摆放上，要根据货物的大小来规划存储空间。或者说要首先防止大的货物。只有如此空间的利用率才会最高。其实在规划DB2对象的时候，也是如此。如某些表可能会包含的记录比较多，属于大表。此时数据库管理员就需要考虑，是否将其放置在一个独立的表空间或者硬盘空间上，以提高数据 *** 作的性能。大表所对应的索引往往也是比较大的。为此在硬件条件允许的情况下，将索引表与数据表分别存放在不同的硬盘上，可以提高数据库的性能。而对于一些比较小的对象(如数据表)，可以将它们存放在一个表空间中。其实这个表空间就好像仓库中的一个个纸盒子。将小的对象放入到这个“纸盒子”中，不但不占空间，而且也容易管理。

2、根据对象的使用频率来规划存放空间。在仓库中摆放物品的时候，往往会把近期就要用到的货物或者频繁需要用到的东西放在仓库门口或者容易拿到的地方。如此在拿这些货物时就会比较便捷，也不会对其他货物产生影响。对于DB2数据库中的对象来说，也是这么一回事。可以将那些访问量比较大的对象，如索引、数据表，存放在性能比较好的硬盘上或者单独的硬盘中。此时访问这些数据，就不会与其它对象产生I/O冲突， *** 作起来速度就会比较快。而将不怎么用到的对象，存放在一起。由于他们不怎么被用到，所以即使存放在性能比较低的硬盘上，其对数据库性能产生的负面影响也是非常有限的。 在DB2数据库里面如何更新执行计划

3、根据类别来存放数据库对象。在仓库中存放货物的时候，还会对其进行分类。然后根据类别来进行存放。这有利于货物的管理与检索。其实在数据库对象存储空间设计时，也需要考虑这个因素。如现在应用软件在设计的时候，很多都是根据模块来设计。那么在数据库对象设计时，也需要根据这个模块来设计存储的空间。如将同一个模块的数据库对象存放在同一个表空间内。不过这可能会跟上面的两个建立相违背。此时最好是在对象的命名上做文章。如可以根据模块的不同，分别给数据库对象取一个相同的前缀或者后缀。如即使同一块模块要用到多个表空间，此时就可以给表空间一个相同的前缀。如此在管理数据库对象的时候，根据表空间的前缀就可以判断其所属的模块了。如果再加上一个后缀来表示其数据库对象的分类，那么就更合理了。为此在管理数据库对象的时候，要执行分类管理。不仅要从技术上对其进行分类，如分为索引、数据表、关键字等等。还需要从功能上进行分类，如按应用程序的模块来进行分类等等。

三、设计好数据库备份与还原的方案。

在数据库交付生产使用之后，往往需要进行大量的测试。但是在测试过程中往往又会产生很多的垃圾数据。可是交给企业应用的，肯定是一个干净的数据库系统。为此在数据库设计的时候，就需要想好如果减少测试过程中的垃圾数据。或者采取什么样的方式来实现在交互时自动清除垃圾数据的机制。

一般来说，想要一个数据库备份与还原的方案，减少数据库测试所产生的垃圾数据。如现在在给企业部署数据库的时候，往往是先安装一个干净的数据库系统。当然字符集这些需要预先设置好。然后再利用数据库还原功能将预先定义好的数据库模型还原出来。

另外有些时候需要两个方案互为补充。如在数据库初始化的过程中，采用数据库还原的方式来创建数据库对象。但是在应用软件升级的时候，由于此时已经有了用户的数据，为此不能够在使用数据库还原的方法。而是通过应用程序来执行某些SQL代码，来调整或者增加部分数据库对象。无论采用哪一种方式，需要遵循的一个原则就是在给企业创建数据库对象时要最大限度的减少测试。而要做到这一点，就是需要先在测试服务器上创建对象并测试对象可用。然后直接将相关的SQL代码在投入使用的数据库服务器上执行。

5.2.2.1 数据库

根据该系统的开发需求，按照数据库的功能和作用将其分为风险查询类、风险评价类、系统管理类三大类（萨师煊等，2000）。主要数据见表5.5。

表5.5 海外油气与金属矿产资源开发风险管理系统的主要数据表

续表

5.2.2.2 数据仓库

油价数据来源于美国能源部（DOE）下属的能源信息署（EIA）网站、中石油（CNPC）网站和《华尔街日报》（WSJ）网站提供的油价数据，油价序列本身就是一个不规则的时间序列，油价数据具有以下几个特点。

（1）数据的一致性差

油价数据格式多样，存在数据冗余，主要体现在：使用的数据格式均不相同，并且各个子系统相对独立。在网站单独作用的情况下，一般都没有问题，但要将这些不同系统或不同时期的数据集中起来综合利用，就可能出现数据不齐全、不一致或重复的现象。

（2）数据存放的分散

油价数据来源多，缺乏统一管理，没有一种相应的网页数据自动化抓取 *** 作实现数据的本地化 *** 作过程。

（3）数据资源开发不充分

大容量数据导致对数据资源的开发利用不充分，缺乏对获取的数据如各分析机构制定的期货合约元数据进行各种深层次分析、综合、提炼、挖掘和展现的应用，因此很难对丰富的统计数据资源进行二次开发利用。

根据油价数据中所包含的油气产品种类、油气产品合约制定日期、油气产品的价格类型、不同市场下油气产品价格的差异等，能够加深对油价走势的了解。油价的这种与时间相关性、不可修改性，以及集成的性质，使得我们采用多种角度对原始数据进行理解，并真实反映其特性，也让我们发现使用一种整合的技术对油价进行精确预测十分必要。

数据仓库的构建流程如图5.13所示由下至上逐步实现。

图5.13 数据仓库构建流程

1）数据源。

A.数据源的复杂性。数据分散在数据库管理系统、电子表格、电子邮件系统、电子文档甚至纸上。系统中要求采集的3个数据源中，EIA 网站存储在网页上的油价相关事件更新较慢，虽然提供了各市场日、周、月、年的油价数据下载，但是下载完成之后的表格字段格式时常发生变化，这为实现自动获取数据并下载到本地自动入库的要求增加了难度；中石油网站数据除上述只显示3条数据之外，网站上会将访问流量过大的IP地址列入黑名单使其不能继续下载到本地进行保存，为这些数据建立统一的模型将会耗费很大精力。

B.数据的有效性。由于存在经验局限，如何处理数据的空值、不同时间间隔时间字段格式，入库时应注意的问题等，如果应用程序没有检验数据的有效性，会对数据多维显示产生极大影响，因此也归结为数据源数据质量问题。

C.数据的完整性。数据源上的数据并不那么明显或者容易获得。油价是高度敏感的数据，因此各个网站虽然提供了各个油品交易市场的日、月或年数据，但是完整性并不能充分保证，根据企业政策的不同，有时对要获得的数据，需花费大量精力。为此，要对不同的数据源进行建库，以保证所获数据的完整性。

2）数据处理。

高效的多维数据集展示离不开底层数据源数据的精确获取，或者叫做数据理解和数据清洗。于是系统在基于元数据获取、加工、入库和多维数据集展示上实现预期的要求。

A.ETL。该功能是整个油价数据仓库的核心之一，主要功能是按照事先定义的数据表对应关系从相关系统表中抽取数据（Extraction），经过数据清洗和转换（Transform）,最终把正确的数据装载到数据仓库的源数据中（Load），作为以后应用的基础。

B.数据转换。该功能是在数据抽取过程中按照定义的规则转换数据，避免了数据在分析时的多样性，保证数据一致性。

C.数据集成。该功能主要是把油价信息数据仓库系统的源数据，按照事先定义的计算逻辑以主题的方式重新整合数据，并以新的数据结构形式存储。

3）数据存储。

星型模型（星型架构）是数据仓库开发中多维展现重要的逻辑结构，构成星型模型的几个重要特征是：维、度和属性，在实际应用中表示为事实表和维度表。在油价数据中，各市场的期现货价格表为数据仓库的事实表，油品类型、合约规定日期等为维度表。

油价数据仓库星型模型的设计方案如下：

A.事实表。数据库表中EIA的期现货价格表（包括日、周、月、年表）作为数据仓库中的事实表，根据不同时间维度构成多个星型模型，即星座模型。这些价格表中以市场编号、油气产品类型、期货合约日期、价格单位度量衡编号作为主键和外键与其他维度表相连，形成多维展示联动的基础，以油价数据和其他事实数据为记录数据，作为主要输出结果。

B.维度表。根据市场、油品、价格数据、度量衡和事件类型作为油气数据仓库中多维分析的角度和目标。

图5.14以EIA的日期货数据表作事实表为例，构建星型模型，其他不同时间维度的模型结构图与此图基本相同。

图5.14 以EIA数据为例的日期货价格星型模型

以星型模型设计为基础，完善数据存储中 *** 作型数据存储（ODS）的原型设计，提供DB-DW之间中间层的数据环境，可实现 *** 作型数据整合和各个系统之间的数据交换。

---