2.4 数据库标准与过程
想要有效地使用新安装的DBMS，必须开发使用数据库的标准和过程。研究表明，相比标准化较低的公司，那些高标准化的公司可以将用于支持终端用户的成本降低35%甚至更多。
必须开发使用数据库的标准和过程。
标准是用于确保数据库环境的一致性和有效性的常见做法，如数据库命名约定。程序是定义好的、步进式的指示，用于指导处理具体事件的事务，如灾难恢复计划。未能实现数据库标准和过程会使数据库环境变得混乱且难以管理。
DBA应当开发数据库标准和过程，以此作为企业范围内IT标准和过程的组成部分。它们要么以纸质文件的形式集中存放，要么以电子格式存储于网上，或者两种形式都有。针对特定的DBMS产品，一些供应商还提供了“罐装的”标准和过程。
2.4.1 数据库命名约定
即将部署的首要标准之一是一组数据库对象命名的指南。没有标准的数据库对象命名约定，就难以正确识别数据库对象，并进行适当的管理任务。
数据库对象命名标准的制订应结合企业的所有其他IT命名标准。在所有情况下，数据库命名标准的制订应与数据管理部门（如果存在）合作，并且，只要可能，它应与其他的IT标准和平共存，但不能以危害数据库环境为代价。许多企业有命名文件的实践约定，但协调数据库对象可能需要特定格式的数据库文件名，却与实践标准不符（详见图2-7）。因此，命名数据库文件对于现有的实践标准来说是个例外。
确保创建并发布适用于所有数据库对象（在企业所使用的每个DBMS内都可以创建）的命名标准。多数DBMS支持的数据库对象的一个基本列表包括数据库、表、列、视图、索引、约束、程序、用户自定义数据类型、用户自定义函数、触发器和存储过程。然而，这个列表还不完整，因为每个DBMS针对具体的操作还会使用其他的数据库对象。例如，DB2使用计划和存储组；Oracle使用数据库链接和集群；SQL Server使用文件组和规则（详见“非标准数据库对象实例”）。
确保创建适用于所有数据库对象的命名约定。
数据库命名标准的设计应尽量减少跨环境的名称变更。例如，将“T”嵌入名称“test”和将“P”嵌入“production”都是不明智的。尤其重要的是对用户可见的数据库对象如列、表、视图更要避免使用此种做法。名称变更最小化使数据库从一个环境到另一个环境的迁移变得简单。有种情况也是可能的，即所有的数据库对象具有相同的名称，只是将每个环境分配到不同的实例或子系统。该实例或子系统的名称（而不是数据库对象的名称）将用于区分环境。
减少跨环境的名称变更。
非标准数据库对象实例
除非你使用所有三种数据库：DB2、Oracle和SQL Server，否则你可能对那些针对某一种数据库系统的数据库对象不熟悉。鉴于此，这里给本章提到的数据库对象进行了简单的定义。
DB2：
计划与DB2的应用程序相关，是指在该程序中包含SQL的绑定访问路径详细信息的数据包。
存储组是一个数据库对象，用于关联磁盘存储和DB2表空间。
Oracle：
数据库链接是一个数据库中的模式对象，使你可以访问另一个数据库中的对象。
集群由一组共享相同的数据块的表组成。这些表组合在一起因为它 们有着共同的列，且它们常一起使用。
SQL Server：
为便于分配和管理，数据库对象和文件可以在文件组中组合在一起。
规则是一种独立的、可以附加到列的数据库约束。Microsoft公司已经表示，在未来的SQL Server版本中将会删除规则。
在大多数情况下，对于那些没有被典型终端用户访问的对象，可以提供一种方法来区分数据库对象的类型。例如，索引以“I”或“X”开头，而数据库以“D”开头。但是，正如前面所提到的，这种做法对于表和类似的对象是不合适的。
一般情况下，不要对终端用户访问的对象名称施加不必要的限制。关系数据库讲究的是用户友好。一个严格的数据库命名约定（如果制定的不合乎逻辑）可能与有用且有效的数据库环境背道而驰。一些企业对数据库表的长度任意限制，比如，限制为8字节，而DBMS可以支持多达128字节的表名。对数据库表名的长度施加限制没有任何实际的原因。
在合理的范围内，表名应尽可能具有描述性。此外，只要DBMS支持所有DBMS支持的“类表”对象都应使用相同的命名约定，如视图、同义词、别名。每个对象基本上都与行和列一样，是可存取的数据集。因此，对每个对象制定单独的命名约定没有什么实际价值。使用这种方法，那些操作与表类似的数据库对象，将同样具有描述性的名称。对象的类型通常可以通过查询DBMS的系统目录或数据字典确定。
避免对表名进行编码使其变短。
另外一种应避免的任意命名约定是对表名进行编码使其变短。表的名称应包括2～3字节的应用识别前缀，后跟一个下划线，然后是一个明确的、对用户友好的名字。例如，人力资源系统中，一个好的表名需要包含雇员的信息HR_EMPLOYEE。有多个应用程序用到该表时，也不应将应用识别前缀从表的名称中删除。
还需要注意的是，有些数据库对象的名称在某些情况下将会外部化。例如，一旦约束被违反，大多数的DBMS都会选择将约束名称外部化。约束的类型多种多样（触发器、唯一约束、参照约束、检查约束），每一种都可以命名。跨环境保持名称一致可以使得错误信息也一致，如果DBMS在开发、测试、集成、生产环境中都报了同样的错误信息，那么调试和修正错误就比较容易。
标准缩写
尽管应尽可能使数据库对象的名称为英语，但是也不可避免地会遇到需要使用缩写的情况。只有当完整的名称太长，对象名称看起来很笨拙或比较难记时，才可以使用缩写。例如，如果“ORG”是“organization”的标准缩写，就不要使用变体“ORGZ”。使用标准的缩写将最大程度地减少拼写错误，并且使用户更容易记住数据库对象的名称。长期于此，可以使数据库的对象更容易理解。
建立标准缩写列表。
2.4.2 其他数据库标准和过程
数据库命名标准虽然重要，也需要制定和维护其他类型的数据库标准。要为企业所使用的每个DBMS都制定一套综合的标准和过程。数据库标准虽然可以从头做起，但还有其他潜在的、更简单的方法来构建标准库。那些可以根据用户需求进行修改的基本标准，可以从出版商或软件供应商那里购买，或者可以通过用户组和会议，在社区收集大家所建议的标准。
这些标准无论是购买的、自己想出来的，还是从用户组或委员会得到的，都应涵盖以下几个方面。
角色和职责
DBMS的成功运行需要多名熟练的技术人员和业务专家的共同协调管理工作。应该制定出数据库管理及管理职能的矩阵文件，详细列出每一种支持任务以及分别由谁来提供支持。矩阵文件可以是部门级别的、工作描述级别的，甚至是个人名义的。表2-4给出了实例矩阵，其中“X”表示参与这一过程，而“P”表示主要的职责。
当然，你可以创建任何任务，只要你认为它有必要出现在角色与职责矩阵中。你所需的任务可能比示例中的多，也可能少。例如，你可能希望将存储过程的开发、测试、管理进行区分，所以分别为这三者创建不同的任务种类，并相应地将支持需求进行分解。
不管角色与职责矩阵的最终格式如何，一定要保证它的准确性并包含最新的DBMS功能和任务。最新的矩阵可以更容易地定义企业内的角色，并能有效地分配数据库相关的工作量。
沟通标准
你也可以选择为团队或具体人员之间制定具体的标准。例如，在新的DBMS版本安装过程中，你可能想记录DBA团队如何以及何时与系统编程团队沟通。
制定强大的沟通标准可以简化DBA在不可避免的停机时间的工作，停机由于系统、应用程序，甚至硬件错误而导致。例如，考虑采用一种标准，在故障排除和紧急修复过程中DBA可仅与经理沟通。既让经理知晓，同时也让DBA可以避开愤怒的用户、帮助服务台等的电话骚扰。经理可以随时给外部通报状态，而DBA可以专注于故障排除并使系统恢复正常运作。
数据管理标准
如果你的企业有DA团队，他们应制定出一套基本的数据管理标准指南来概述他们的工作职责范围。如果没有DA团队，则一定要在DBA标准中适当地包含DA标准。
在DBA标准中适当地包含DA标准。
数据管理标准应包含以下几项：
清晰地描述企业整体的数据策略，包括其对企业的重要性。
建立数据所有权和管理权的准则。
数据创建、数据所有权和数据管理权的规则。
元数据管理政策。
概念和逻辑数据建模指南。
有关创建企业数据模型的企业目标。
创建并维护逻辑数据模型的职责。
工具使用指南以及数据模型创建、存储、维护的说明。
企业的数据共享政策。
物理数据库偏离逻辑数据库时的记录说明。
数据管理与数据库管理的沟通指南，以确保数据库的有效创建与使用。
数据库管理标准
应建立一套基本的数据库管理标准用以确保DBA的工作可以不断获得成功。该标准要作为DBA提供服务和用于支持数据库环境的具体方法的指导。例如，制定的标准可以概述说明创建一个新的数据库或更改已有的数据库需要如何提出申请，并指定哪些类型的数据库对象和DBMS功能更受青睐，以及在何种情况下要避免使用它们。标准还可以建立备份和恢复程序（包括灾难恢复计划）并交流用于将逻辑数据模型转换为物理数据库的方法。另外一套涵盖数据库性能监控和调优的DBA标准可能对记录解决性能问题的过程很有用。
DBA标准要作为支持数据库环境具体方法的指导。
虽然该DBA标准对DBA人员将是最有用的，但是应用程序开发人员也需要通过它们学习如何更好地与DBA人员一起工作。此外，DBA标准所记录的任何性能调优的技巧都应与编程人员共享。了解DBMS细微差别和DBA角色的应用程序编程人员越多，DBA与开发人员之间的工作关系将更融洽（最终导致数据库环境更高效）。
系统管理标准
再次说明，只有当你的企业将SA与DBA的工作分离时，才需要系统管理标准或系统编程标准。需要系统管理标准与需要DBA标准的许多理由都是相同的。SA标准可能包括：
DBMS安装和测试程序。
升级政策和程序。
错误修复和维护实践。
变更即将发生时，要通知的部门清单。
接口的考虑。
DBMS存储、使用和监控程序。
数据库应用程序开发标准
数据库应用程序的开发与典型的程序开发有所不同，编写访问数据库的程序时，你应记录下有关开发的那些特殊考虑。数据应用程序开发的标准应作为企业任何标准应用程序开发过程的附属。该套标准应包括：
描述出数据库访问与平面文件访问的不同之处。
SQL编码标准。
SQL性能技巧与技术。
程序的准备过程和将SQL嵌入应用程序的方式指南。
SQL语句与错误代码的解释。
参考其他有用的有关远程处理监控程序、编程语言以及一般的应用程序开发标准的编程材料。
数据库安全标准
DBA团队通常申请并管理DBMS的安全。然而，在一些企业中，企业数据安全单元掌握着DBMS的安全。用于概述必要的标准和管理数据库安全过程的资源应包括以下信息：
在一些特定类型的情况下应授予何种权利的详细说明，例如，如果一个程序正迁移到生产环境，那么必须授予该程序何种DBMS权力，它才能在生产环境成功运行。
有关任何特殊过程的文档或治理（与合规性）相关的请求所需的文档。
有关谁可以批准何种类型的数据库授权请求的明确清单。
任何用于连接DBMS安全和操作系统安全产品的接口信息。
使用SQL GRANT语句的WITH GRANT OPTION子句以及级联REVOKES如何处理的政策。
通知请求者数据库安全已授予的过程。
解除那些退休、调动、解雇的雇员的授权的过程。
概括用于管理数据库安全的一些必要标准和过程。
概述必要的标准和管理数据库安全过程。
应用程序的迁移与调整过程
正如前面所讨论的，支持数据库应用程序最少也需要两种环境：测试环境和生产环境。而一些企业还会建立多种环境用以支持开发生命周期的不同阶段，包括：
单元测试，用以开发和测试个人程序。
集成测试，用以测试个人程序如何互操作。
用户接受性测试，在生产环境之前的终端用户测试。
质量保证，用以发现程序错误。
教育，用以培训终端用户该应用程序系统的工作方式。
当存在多个环境时，就需要将数据库对象和程序从一个环境迁移到另一个环境。还需要具体的指南以有利于各个环境使用的方式来实现迁移。例如，每个环境所需的数据容量是多少？测试时如何保证数据的完整性？到底应迁移数据，还是仅调整数据库结构？目标环境中已有的数据该如何处理（应保持，还是用新数据覆盖）？应制定综合的迁移过程才可能解决这些问题。
需要将数据库对象和程序从一个环境迁移到另一个环境。
该迁移和调整过程应记录任何的数据库对象或程序从一个环境迁移到下一个环境所需的信息。至少是迁移的请求者会需要这些信息，如对象何时以及为何要进行迁移，迁移需要得到谁的批准？为确保迁移的成功，DBA应记录用于迁移的方法和验证迁移的步骤。
设计审查指南
所有的数据库应用程序在开发的各个阶段都应经受得起设计审查。设计审查非常重要，它可以保证应用程序的设计、结构和性能的正确性。它可以采取的方式也是多种多样的，第6章提供了综合讨论。
操作支持标准
操作支持被视为IT企业的一部分，用于监视数据库环境并确保应用程序都按照预定计划运行。要想有效地管理数据库环境，必须提供足够的操作支持。提供操作支持的人员通常处于抵御系统问题的最前线，程序失败、硬件失败以及其他问题都是由操作支持人员首先发现，然后才让专家来解决的。
操作支持确保应用程序按照预定计划运行。
应制定标准用以确保那些提供操作支持的人员能够理解数据库应用程序的特殊需求。只要有可能，提供操作支持的全体人员应进行培训，以求在不需要DBA的情况下也可以解决简单的数据库相关的问题，因为通常使用DBA的代价是比较昂贵的。