### 1.5　数据库管理、数据管理和系统管理 一些企业分别为数据的商业方面和技术方面定义了不同的角色。数据的商业方面与数据管理是保持一致的，而更多技术方面都由数据库管理员DBA掌控。并不是每一家企业都有数据管理的职位，而许多企业都将数据管理并入数据库管理了。 有时企业也将数据管理的技术方面进行分离，DBA 负责使用 DBMS，而其他角色（系统管理或系统编程）负责安装并升级 DBMS。 #### 1.5.1　数据管理 数据管理（Data Administration，DA）把数据资源管理的商业方面和用于数据管理的技术分离开。DA 存在于一家企业，与数据的实际商业用户联系更加密切。数据管理员（DA） 会更多地参与需求收集、分析和设计阶段。而 DBA 参与设计、开发、测试和运作阶段。 DA 和 DBA 的另一个有区别因素是他们工作的重点。 DA 负责以下问题： ● 确定并编写商业用户需要的数据目录； ● 概念化产品并逻辑化数据模型，准确描述业务流程中的数据元素之间的关系； ● 产生企业数据模型，它要整合所有企业 / 业务流程使用的数据； ● 为企业设置数据政策； ● 确定数据拥有者和管理者； ● 为数据的控制和使用设置标准。 总之，DA 可看作企业的首席数据官。尽管 DA 的职位和技术没什么特别的关系，但依我看来，DA 根本不是一个行政职位。实际上很糟糕，许多IT企业声称它们把数据看作公司的财产，但当你审视它们的行为时便会发现此声明的虚假。数据政策的责任常移交给一些技术专家，但他们不能专注于非技术性的、商业方面的数据管理。这些专家可以很好地保证数据的可用性、性能和可恢复性，但通常不能保证数据的质量，也不能设置公司的数据政策。 **数据管理员可看作企业的首席数据官。** 实际上，数据很少被视作真正的企业资产。看看每家企业都有的资产吧：资金、人力资源、设备和原材料，每一种都是模式化的：账户一览表、企业组织图和层次报表、建筑蓝图和办公室布局及材料账单，每一种都可跟踪、都受保护。企业还请来专业会计师确保资产账目没有任何差池。 我们能说大部分公司也这样对待数据吗？ 一个成熟的DA组织负责规划并指导整个企业的数据使用需求。这个角色围绕数据是如何记录、共享和实施的展开工作。DA 的一个很大的责任是确保将数据元素在数据字典或数据存储库中予以准确地记录。这是 DA 和 DBA 之间另外一个关键区别，DA 关注存储库，而 DBA 关注物理数据库和 DBMS。 > 此外，DA 处理元数据，这与处理数据的DBA 截然相反。元数据称作“数据的数据”， 更准确地说，元数据是对数据和业务所需要的数据的描述。数据管理负责业务和元数据策略。 这里举几个元数据的例子，它可以包括数据元素的定义，某个数据元素的业务名称，该元素的任何缩写形式，该元素的数据类型及长度。没有了元数据，数据就难以使用。 元数据为数据提供了得以理解的上下文，因此也就成为数据的信息。在许多企业，元数据没有系统地捕获和编目，而大多存在于商业用户的脑子里。元数据在系统中捕获的位置遍布文件定义中的多个程序，以及准确性参差不齐的文档中，或长时间不用的程序定义中。当然，其中一些位置在 DBMS 的系统目录中。 综合的元数据策略使得企业知道所控制的资产信息并衡量这些资产的价值。 > DA对公司数据资产的最大贡献之一是创建数据模型。概念化数据模型能够非常高水平地概括出数据需求。逻辑化数据模型为数据类型、长度、关系及基数提供了深入的细节。DA 采用标准化技术提供能够准确描述企业的数据需求的完善数据模型。 很多DBA 会把数据管理当做单纯的数据模型摒弃，因为有人要从终端用户那里获得数 据库需求。但真正的DA 的作用远不只是单纯的数据模型，而是一种面向商业管理的、为企业数据资产服务的准则。 为什么在一本关于数据库管理的书中花这么多时间来讨论数据管理呢？为数不多的企业实现并雇佣了DA。企业做得越大，越有可能设置DA 职位。然而，当一家企业里DA的角色没有确定时，DBA 就要承担数据策划与建模的职责了。 而由于以下原因，DBA 通常不能够承担 DA 所有的职责。 ● DBA 要履行许多其他技术方面的职责，这占用了他大部分的时间。 ● DBA 团队的经理一般没有行政职务使他决定策略。 ● DBA 一般不具备与商业用户有效沟通并达成共识的技巧。 ● 坦率地说，大部分的DBA 更愿意处理技术问题及与技术专家打交道，而非碰触业务问题及非技术人员。 > 当 DA 和 DBA 在企业共存时，这两个团队要非常密切地合作。当然，没有必要要求他们有共同的经理，不过若有，可能更容易促进他们的合作。无论如何，重要的是两个团队之间要有一定程度的技术交流。因为DA 永远不会像 DBA 那样了解物理数据库，而DBA 也不会像 DA 那样了解数据的业务问题，每种工作都借鉴其他工作的知识就会更有效率。 总之，企业若真正关心数据的质量、完整性和再利用时，都会安排DA 的职位。 #### 1.5.2　数据库管理 数据库管理是整本书的重点，本节就不花太多时间来定义它了。本书以后的部分会给出详细的定义。本节将快速概括当 DA 也存在时，DBA 团队所起的作用。  如图1-3 所示，DBA 管理数据而 DA 管理元数据，现在就更深入了解一下吧。 DBA 的首要职责就是理解DA构建的数据模型并能够与应用程序开发者以及其他相关技术人员讨论该模型。逻辑数据模型是DBA用来创建物理数据库的映射。DBA 要把逻辑数据模型转换成一种有效的物理数据库设计。重要的是， DBA 结合DBMS中用到的知识，根据逻辑模型创建一个有效且合适的物理数据库设计。 #### 1.5.3　系统管理 一些较大的企业会设置系统管理（SA）或系统程序设计的职位，有助于 DBMS 的实施和运行。当SA 和 DBA 共存时，SA 负责DBMS 的安装和设置。他们一般不负责数据库的设计和支持。而DBA 负责数据库，SA 负责DBMS 的安装、修改和支持。如果你不清楚这种区别，请参阅附录 A 中数据库术语的明确定义。 此外，SA 还负责IT 基础设施的实施，配置DBMS 与其他授权系统软件一起运作。SA 可能需要和其他技术人员合作来配置事务处理器、消息队列、软件、网络协议以及操作系统参数，使DBMS 有效地运行。为了开发数据库，SA 还要通过合理地设置DBMS，向DBMS 供应商申请持续维护，以及升级 DBMS 版本来确保 IT 基础设施正常运作。 为了开发数据库，系统管理员还要通过合理地设置DBMS，向DBMS 供应商申请持续维护，以及升级 DBMS 版本来确保 IT 基础设施正常运作。 与 DA 一样，SA 和 DBA 之间也要交叉培训技能。SA 永远都不会像DBA 那样了解物理数据库，但DBA 也不太可能像SA 那样懂得系统软件的安装以及它们之间深入的技术关系。 了解一些其他的知识，每种工作都能更有效地发挥它的作用。 当没有独立的 SA 团队或没有专注于 DBMS 的 SA 时，DBA 就要承担系统管理和编程的责任了。  图 1-4 中对 DA、DBA 和 SA 的职责提供了简短的描述 ### 1.6　DBA 的任务 DBA 要能胜任多种任务以保证企业的数据和数据库是有用的、可用的、有效的、正确的。任务包括：设计、性能监控及调节、保证有效性、授权的安全性、备份与恢复、保证数据的完整性，还有和公司数据有关的一切。 #### 1.6.1　数据库设计 人们认为 DBA 的首要任务就是建立设计完美的数据库。要想设计并建立合理的关系数据库，DBA 就要懂得并遵循合理的关系设计原则。他们必须要懂得相关理论及用于建立数据库的 RDBMS 的具体实施细节。设计数据库要充分理解概念的和逻辑的数据模型知识。具备建立及解释实体关系图的能力对于设计关系数据库是必不可少的。 此外，DBA 要能够把逻辑数据模型转换成物理数据库。DBA 要保证设计和实施的数据库对应用程序及使用它的客户端是有用的。 **DBA 要能够把逻辑数据模型转换成物理数据库。** 数据库设计确实是 DBA 要拥有的一项重要技能，而 DBA 的工作常与数据库设计不太相干。尽管设计最优的数据库很重要，但这只占据DBA 工作相当小的一部分。相比最初的设计和搭建数据库，DBA 在管理和调整数据库上花费的时间有可能更多。 #### 1.6.2　性能监控和调优 与 DBA 密切相关的第二种任务是性能监控和调优。但什么是数据库性能？暂且用我们 熟悉的供需概念来考虑一下吧，用户对于数据库的需求信息，DBMS 对这些需求所提供的信 息。DBMS 提供信息需求的速度就可以叫做数据库性能。但不会那么简单，有 5 种因素可以 影响数据库性能：工作负载、吞吐量、资源、优化和竞争。 对 DBMS 请求的工作负载（workload）定义了需求。这结合了在线交易、批量作业、随机查询、数据仓库、分析查询，和在任意给定时间内直接通过系统的指令。工作负载可以每天、每小时、每分钟甚至每秒钟都大幅波动。有时候工作负载是可以预估的（比如，月底大量的结算过程，或下午七点半大部分用户下班后对数据库访问减少），但其他时间不可预估。 整体工作负载对数据库性能有着重大的影响。 吞吐量定义了计算机硬件和软件的整体能力。这整合了I/O 的速度、CPU 的速度、机器的并行能力、操作系统及系统软件的效率。由系统支配的硬件和软件工具称为“系统资源”。 例如，数据库内核、磁盘空间、高速缓存控制器和微代码。 数据库性能的第四个定义元素是优化。所有类型的系统都可以优化，但在这些优化中关系查询都是独特的，主要在 DBMS 内部完成。然而还有许多其他因素有待优化（SQL 表述、 数据库参数、有效的程序设计等），从而使数据库优化程序能够创建最有效的访问路径。 当对某一特殊资源的需求（工作负载）很高时，竞争就产生了。竞争产生的条件是：两个或多个工作负载元件试图以一种冲突的方式（例如，对同一数据段进行双重更新）使用单个资源。随着竞争的增加，吞吐量随之降低。 因此，数据库性能可以定义为资源利用的优化以增加吞吐量并减少竞争，从而最大可能地处理工作负载。 每当使用数据库的应用程序遇到问题时，DBA 常常会首先被叫过来解决问题。当然， DBA不能凭空管理数据库性能。应用程序会定期与其他应用程序、系统和IT 基础设施组件 进行通信。一种有效的性能监控调整策略不止需要DBMS 专项技术，还需要数据库管理以外的知识。许多性能管理任务需要DBA 和其他技术专家共同完成，换句话说，处理性能问题真的是种企业范围的努力。 DBA 要在监控系统、数据库和应用程序性能中保持警惕，这通过自动化软件和脚本可 以尽可能地实现。轮询系统表并构建基于临界值的警报可以主动识别这类问题。当性能指标不在期望范围内时，设置的警报可以发送电子邮件给 DBA。 许多任务和能力的实现都要求DBA 要保证数据库的有效访问。 这些能力包括：建立恰当的索引，指定足够大的缓冲区和高速缓存，使数据库实现和IT 基础设施相符，对数据库和应用程序的持续监控，数据库重构，以及适应业务的改变（更多的用户、更多的数据、附加的过程、改变需求和规则）。 #### 1.6.3　保证可用性 数据和数据库的可用性常与性能密切相关，但实际上是分开考虑的。当然，如果 DBMS 处于脱机状态，性能表现将很可怕，因为没有数据能够访问。但保证数据库的可用性是个多方面的过程。 可用性的第一要素是要保持DBMS 持续运行。警惕监控与自动警报可以用来报告 DBMS 中断并要求补救措施。 个人数据库也必须维护，使得其中的数据可供应用程序和客户端调用。这样不仅需要 DBA 设计数据库，使得能以最小的中断去维护它，还要帮助设计应用程序，在需要并发访问时把冲突降到最低。 可用性的另外一个要素是要降低执行管理任务的停机时间。DBA 执行需要数据库脱机的管理任务越快，数据可用性就越强。越来越多的 DBMS 供应商和独立软件开发商（ISV）提 供不间断的实用程序，在数据库上执行它们，而应用程序通过它们对数据库进行读写。 但这些通常需要更多的技巧和前期规划才能实现。 DBA 必须了解所有这些方面的情况，并确保每个应用程序的需求都接收了正确等级水平的可用性。 #### 1.6.4　数据库安全和授权 数据库一旦设计好并部署，程序员和用户就需要访问并修改数据库中的数据。但为防止安全漏洞和不当的数据修改，只有得到授权的程序员和用户才能够访问。 DBA 的职责是要确保数据只提供给授权用户。 尽管并不尽然（详见“安全的集中化”），但DBA 不仅要与DBMS 的任意组授权功能打交道，还要通过“SQL GRANT”和“REVOKE”语句与 DBMS 内部的安全功能打交道。要为数据库环境请求的许多行为进行安全管理： ● 创建数据库对象，包括数据库、表、视图和程序结构； ● 变更数据库对象的结构； ● 访问系统目录； ● 读取并修改表中的数据； 创建并访问用户定义的功能和数据类型； ● 运行存储过程； ● 开始并停止数据库，关联数据库对象； ● 设置并修改 DBMS 参数和说明； ● 运行数据库实用程序，如 LOAD、RECOVER 和 REORG。 数据库安全也可以用其他方式强制执行，例如，创建视图以防止敏感的列与行被终端用 户和程序员查看。当外部的安全方法影响数据库安全时，DBA 也经常和这些安全方法打交道。 DBA 必须了解并能够实施影响数据库访问的任何安全方面。 **安全的集中化** 一些企业已经采取措施，将所有的安全和授权任务、政策和程序，都集中在一个IT 安全组。这并不容易实现，正因为如此，相比规模较小的企业，它多见于较大型的企业。 受到严格监管的行业可以选择集中的安全操作。此外，拥有大型计算机的企业往往比那些没有大型计算机的企业更倾向于集中安全。 要成功地将数据库安全的职责从数据库管理团队转移到一个集中的安全团队，这需要给安全人员培训数据库安全有关的技术。此外，许多商家使用的软件从DBMS 删除了一些安全操 作，并在一个更加传统的安全包（比如，大型计算机上的 RACF 或ACF2）内模仿相同的功能。 即使考虑所有这些问题，大多数的企业仍然依赖 DBA 来管理数据库安全。 #### 1.6.5　治理与合规性 确保符合行业和政府法规的要求是数据库管理的一项附加任务，至少在部署适当的控制方面。DBA 必须要与管理人员、审计人员和业务专家一起合作来了解适用他们行业的法规及处理数据的方式。 > 合规性的某些方面是关于标准的DBA 作业程序的。例如，法规可能包含执行特定安全和授权程序使用的语言、审计要求、数据备份规范和变更管理程序。然而，要确保合规可能需要严格的文档，或者更高程度的尽职调查或自动化（比如，更深层次的审计跟踪）。 合规性的其他方面，可能需要DBA 采用不同的技术、战术和技巧。例如，数据保留法规可能要求数据在使用后仍能存储在一个生产数据库中以长期保留，这就需要数据库有归档的能力； 或某些数据可能需要得到保护以免被查看，这就需要数据屏蔽，或在某些情况下设置数据加密。 DBA 不应该负责深入地理解任何法规，也不应该设置企业遵守法规的标准。然而，他们会帮助合规项目设置适当的控制及程序，特别是数据处理方面。 #### 1.6.6　备份和恢复 DBA 必须做好准备在问题发生时恢复数据。“问题”可能意味着任何系统故障或程序错误或者一场自然灾害而导致一家企业关闭。现在，大部分数据恢复是应用软件错误和人为错误导致的，硬件故障并不像从前那样普遍了。事实上，分析师的估计表明，80% 的应用程序错误是由于软件故障及人为错误。不管什么原因，DBA 必须时刻准备着尽快将数据恢复到一个可用的点。 面对一次重大停机，通常想到的第一种数据恢复是恢复到当前。数据恢复的最终结果是，该数据库被恢复到发生故障前的状态。在恢复完成之前，应用程序完全不可用。 另一种类型的传统数据恢复是时间点的恢复。时间点的恢复通常用来处理应用程序级别的问题。常规技术执行时间点的恢复将删除指定的时间点以后的所有交易带来的影响。如果在该时间范围内一些有效的交易仍然需要，就会出现时间点后的交易不能恢复的问题。 事务恢复是第三种类型的恢复，解决了传统恢复类型停机时间和有效数据丢失的弊端。 因此，事务恢复是一种应用程序恢复，即在指定时间内删除数据库中特定交易所带来的影响。事务恢复有时也称为“应用程序恢复”。 大多数技术人员认为数据恢复是为了解决硬件故障等灾害。虽然硬件故障仍时有发生， 但技术人员要做好从这样的故障中恢复的准备，当今大多数数据恢复是源于人为错误或程序自带错误。 DBA 必须准备应付所有这些类型的数据恢复。这涉及制订备份策略，以确保数据在软件、硬件或手动操作的错误事件中不丢失。策略必须适用于数据库处理，所以它必须包括数据库文件的映像副本以及数据库日志的备份/ 恢复计划。它需要考虑同样能影响数据库应用程序的任何非数据库文件的活动。 #### 1.6.7　确保数据完整性 数据库必须能够以正确的方式存储数据并且不会使数据损坏或破坏。在此过程中，DBA 需要利用 DBMS 的功能实现完整性规则。完整性的三个方面和数据库的讨论相关：物理的完整性、语义的完整性和内部的完整性。 物理问题可以使用DBMS 的功能，如域和数据类型处理。DBA 为每张表的每一列选择适当的数据类型。此操作可确保只有该类型的数据存储在该数据库中，即 DBMS 强制执行数据类型的完整性。A 列定义为整型，则该列只能包含整数。试图在定义为整型的列中存储非数字或者非整数值都将失败。 DBA 也可以使用约束来进一步划定可以存储在数据库列中的数 据类型。大多数相关的 DBMS 产品提供了以下类型的约束： ● 参照约束，用于指定定义了表之间的任意关系的列。参照约束用来实现参照完整性， 从而确保一张表的一列数据（或一组列）的所有预期的参考，相对于相同或不同表的另一列中的数据是有效的。 ● 唯一约束，确保表中的一列或一组列的值只出现一次。 ● 检查约束，用来在表中的一列或一组列中放置更复杂的完整性规则。检查约束通常使用 SQL 定义，并可以用来定义一列或一组列允许的数据值。 语义完整性更加难以控制且不易定义。DBA 必须准备要执行的策略和方法，以确保他们在数据库中存储的数据是准确的、合适的且可用的。举一个有关语义问题的例子，如数据库中的数据的质量。仅存储任何符合数据库定义的物理完整性的数据是不够的，还要有策略和方法以确保数据的质量。例如，一个客户数据库，其中 25% 的客户数据含有错误的地址或电话号码，这就是一个质量很差的数据库。没有系统的、物理的方法保证数据的准确性。数据质量要通过适当的应用程序代码、健全的商业惯例和特定的数据政策来保证。冗余是另一个语义问题，如果在整个数据库中数据元素都有冗余，DBA 应该如实记录这些问题并找出保证冗余数据同步和准确性的方法。 完整性的最后一个方面是DBMS 内部的问题。DBMS 依赖内部结构和代码来维护链接、 指针和标识符。在大多数情况下，DBMS 会很好地维护这些结构，但DBA 也需要知道这些情 况，以在 DBMS 失败时知道如何应对。在以下几个方面，内部 DBMS 的完整性是必不可少的： ● 索引的一致性。 索引是数据库表中数据的有序指针列表。如果由于某种原因，索引与数据不同步，索引访问可能无法返回正确的数据。DBA 有检查和纠正这些类型错误的工具。 ● 指针的一致性。 有时大型多媒体对象并没有和其他数据一起存储在同一个物理文件 中。因此，DBMS 需要指针类型的结构，以保持基表数据与多媒体数据同步。强调一 下，如果不遵守适当的管理程序，这些指针可能会不同步。 ● 备份的一致性。 有些DBMS 产品偶尔会接收不恰当的备份副本，实际上这些副本对恢复作用不大。关键是要识别这些情况，并采取相应改正措施。 总而言之，确保数据完整性是 DBA 的一项必不可少的技能。 ### 1.7　DBMS 版本迁移 DBA 也负责管理DBMS 的版本迁移，DBMS 产品变更相当频繁，通常每年都会有新版本发布。保持DBMS 运行和更新是一项持续的工作，将占据DBA 工作的大部分时间。要降低停机几率和减少应用程序需求变化，无论采用何种方法都必须与企业的需求相符。 保持 DBMS 运行和最新是一项持续的工作，将占据 DBA 工作的大部。 #### 多面手 数据库是现代应用程序的核心，如果 DBMS 失败，应用程序随之失败，进而整个业务 也被迫停止；如果数据库和应用程序经常失败，整个业务也可能会失败。因此数据库管理员对现代商业的持续成功至关重要。 此外，几乎 IT 基础设施的每一个组成部分都与数据库交互，当今的 IT 基础设施包括： ● 编程语言和环境，如 COBOL、Microsoft Visual Studio、C/C++/C#、Java 和 PHP； ● 软件框架，如 .NET 和 J2EE； ● 数据库和流程设计工具，如 ERwin 和 Rational Rose； ● 事务处理系统，如 CICS 和 Tuxedo； ● 应用程序服务器，如 WebSphere、JBoss、Oracle Application Server 和 EAServer； ● 消息队列软件，如 MQSeries 和 MSMQ； ● 网络软件和协议，如 SNA、VTAM 和 TCP/IP； ● 网络硬件，如网桥、路由器、集线器和布线； ● 多种操作系统，如 Windows、z/OS 和 MVS、UNIX 和 Linux，以及其他系统； ● 数据存储硬件和软件，如企业级存储服务器、Microsoft SMS、IBM DFHSM、SAN 和 NAS； ● 操作系统安全包，如 RACF、ACF2 和 Kerberos； ● 其他类型的存储硬件，如磁带机、料仓和固态存储（内存）； ● 非 DBMS 数据设置和文件存储技术，如 VSAM 和 b-tree； ● NoSQL 产品，如 Hadoop 和 MongoDB； ● 数据库管理工具以及它们如何与其他系统管理解决方案交互； ● 系统管理工具和框架，如 HP OpenView 和 CA Unicenter； ● 操作控制软件，如 batch 调度软件和作业控制子系统（Job Entry Subsystem，JES）； ● 在整个网络中实现系统软件新版本的软件分布解决方案； ● 互联网和基于 Web 的数据库和应用程序； ● C/S 开发技术（多层式、胖服务器 / 瘦客户端、瘦服务器 / 胖客户端等）； ● 面向对象和基于组件的开发技术 / 技能，如 CORBA、COM、OLE/DB、ADO 和 EJB； ● 普遍计算技术设备，如平板电脑和智能手机。 尽管要成为所有这些技术的专家不太可能，但是DBA 也应该了解这些领域的知识，以 及它们是如何关联的。更重要的是，DBA 要有那些专家的电话号码，以防任何一种相关的软件和硬件导致数据库访问或性能出问题。 ### 1.8　DBA 的类型 有些DBA 专注于逻辑设计，有些则专注于物理设计：专注于搭建系统的DBA 以及专注于维护和调整系统的 DBA；专业的 DBA 和通用的 DBA。诚然，DBA 的工作包含了许多角色。一些企业选择将DBA 的职责细分成独立的工作。当然，这大多是在较大的企业，较小的企业往往付不起请多个专业的 DBA 的费用。 还有一些公司干脆雇佣DBA 来执行所有的任务：设计、创建、归档、调整及维护公司的数据、数据库、数据库管理系统。 下面介绍一些比较常见类型的 DBA： #### 1.8.1　系统DBA 系统 DBA 专注于技术而不是业务问题。特别是在系统管理领域，系统DBA 专注于技术而不是业务问题。 典型任务主要是 DBMS 软件的物理安装和性能，包括： ● 安装新版本的 DBMS 并应用 DBMS 供应商提供的维护补丁； ● 设置并调节系统参数； ● 调节操作系统、网络和事务处理器，使它们与 DBMS 协同合作； ● 确保 DBMS 的适当存储； ● 使 DBMS 与存储设备和存储管理软件协同工作； ● 配合数据库应用程序所需要的其他技术； ● 安装 DBA 工具和实用程序。 系统DBA 很少参与数据库和应用程序的实际部署。当操作系统参数或复杂的DBMS 参数需要修改时，他们可能会参与应用程序的调优。 事实上，通常只有在企业没有真正的系统管理员或系统程序部门的情况下，系统DBA才存在。 #### 1.8.2　数据库架构师 > 一些企业为设计和部署新数据库设立了一个单独的职位，简称数据库架构师。数据库架构师只参与新的设计和开发工作，不参与搭建数据库及应用程序的维护、管理和调优工作。数据库架构师为新应用程序或者现有的应用程序设计新的数据库。 数据库架构师只参与新的设计和开发工作。 设立这样一个单独的职位是由于设计新数据库所需要的技能和维持现有的数据库运行的技能有所不同。数据库架构师的数据管理和建模技术可能比通用DBA 更专业，因为DA 技能在初始数据库设计时更加有用。 数据库架构师的典型工作包括： ● 创建逻辑数据模型（如果没有 DA 或数据建模师）。 ● 将逻辑数据模型转换为物理数据库设计。 ● 部署有效的数据库，包括物理特性、索引设计和映射数据库对象到物理存储设备。 ● 分析数据访问和修改需求，确保 SQL 的高效性以及最佳的数据库设计。 ● 为新的数据库创建备份和恢复策略。 大多数企业都不会安排单独的数据库架构师职位，而是要求DBA 兼顾新的和已有的数据库项目。 #### 1.8.3　数据库分析师 另一种常见的职位是数据库分析师。数据库分析师根本没有一个通用的定义，有时高级 DBA 称作数据库分析师，有时与数据库架构师所做工作类似，有时 DA 要扮演数据库分析师或数据分析师，有时数据库分析师只是一些企业对数据库管理员的另一种称呼。 #### 1.8.4　数据建模师 没有定义或配备DA 角色时，可能会定义一个数据建模师。数据建模师通常负责部分 DA 工作，数据建模的任务包括： ● 为开发项目收集数据需求； ● 分析数据需求； ● 设计基于项目的概念和逻辑数据模型； ● 建立企业的数据模型并随时更新； ● 与 DBA 合作，以确保他们充分了解该数据模型。 #### 1.8.5　应用程序DBA 与系统DBA 直接对比的是应用程序 DBA。应用程序DBA 专注于数据库的设计和管理， 以及对特定的一个或多个应用程序的持续支持。应用程序DBA 可能擅长编写和调试复杂的 SQL 语句，并懂得在应用程序中做数据库请求的最佳方式。他们还必须能够执行数据库的变更管理、性能调优以及DBA 的大多数其他工作。所不同的是，应用程序DBA 关注应用程序的特定子集，而非整个 DBMS 的部署和数据库环境（详见图 1-5）。  应用程序DBA 专注于数据库的设计和管理，以及对特定的一个或多个应用程序的持续支持。 并非每个企业都配备了应用程序DBA。有该职位时，通用DBA 仍需要支持数据库的整体环境和基础设施；没有该职位时，通用DBA 很可能在维护企业数据库环境的同时还要支持特定应用程序。 有人赞成配备应用程序 DBA，也有人反对。赞成的理由如下： ● 应用程序DBA 可以更好地专注于单个应用程序，这就可以更好地服务于该程序的开 发人员。 ● 应用程序DBA 常被视作开发团队不可分割的部分，因此可以更好地了解新的开发计 划以及计划的改变。 ● 因为应用程序DBA 一直从事于某些特定的应用程序，他们可以更好地把握每个应用 程序运行的状况，从而可以给开发人员更好的支持。 ● 有了对应用程序的全面了解，应用程序DBA 会更好地理解应用程序是如何影响整体 业务的。这方面的知识更有助于他们为企业提供更好的支持。 但并不是所有人都支持应用程序 DBA，反对的理由如下： ● 由于应用程序 DBA 只专注于单个应用程序，他们可能会忽视企业整体的数据需求。 ● 缺乏与集中的 DBA 团队的沟通导致技能共享减少，应用程序 DBA 会变得孤立。 ● 应用程序DBA 实现有用的程序（procedure）时，需要付出更多的努力和其他DBA 分享。 ● 应用程序DBA 以应用程序为中心，他们可能会忽视DBMS 团队交付的新特性和 功能。 一般情况下，配备了应用程序DBA，也一定要配备一个集中的DBA 团队。应用程序 DBA 虽然主要负责特定的应用程序，也应该被视作集中的DBA 团队的一员。这样将会发挥 应用程序 DBA 的正面作用，同时打消其负面作用。 #### 1.8.6　面向任务的DBA 较大的企业有时会有专注于某个特定任务的专门的DBA。但面向任务的DBA 在较小的 IT 企业里很少存在，他们整天致力于确保企业数据库的备份和恢复。 大多数企业都无法负担这种水平的 DBA，但如果可能，则能确保重要的任务都有专人处理。 #### 1.8.7　性能分析师 性能分析师是一种典型的面向任务的DBA。比其他面向任务的DBA 更常见的是，性能分析师只专注数据库应用程序的性能。 性能分析师必须了解 SQL 性能编码的细节和微妙之处，以及有能力设计数据库的性能。性能分析师在技术层面非常了解在用的DBMS，从而能够在需要时对DBMS 和系统参数作出适当的改变。 但性能分析师不应该是一个系统DBA。性能分析师能够和程序开发人员有效沟通，从而帮助他们为了得到更好的性能而相应地改变程序。 性能分析师通常是技艺精湛的 DBA 高级成员。成为一名高级 DBA 很有可能归结于他的经验以及在以往的调优工作中获得的尊重。 #### 1.8.8　数据仓库管理员 企业为了进行深入数据分析而部署数据仓库，通常会特别配备DBA 来监控并支持数据 仓库环境。数据仓库管理员必须是有能力的DBA，并且完全了解支持在线事务处理（OLTP） 的数据库与数据仓库之间的差别。 常见的数据仓库管理员的任务和需求包括： ● 使用商业智能、数据分析、查询和报表工具； ● 只读访问权限的数据库设计； ● 数据仓库的设计事务，如星型模式； ● 数据仓库技术，如联机分析处理或 OLAP（包括 ROLAP、MOLAP 和 HOLAP）； ● 数据变换和转换技能； ● 了解数据质量问题； ● 处理用于加载和卸载数据的数据格式； ● 中间件的实施和管理人员注意事项。 ### 1.9 人员配备的考虑 配备 DBA 不是一件简单的事情，有几个有待解决的重要的考虑，包括 DBA 人员的规模 和 DBA 报告结构的规模。 #### 1.9.1　需要多少DBA 最难确定的事情之一是保证企业数据库在线并高效运作的DBA 的最佳数量。许多企业都试图将DBA 人员规模降到最低，本想着人员减少了成本就降低了，但这种假设一般是不正确的。一个过度劳累的DBA 可能会犯错，而导致的停机时间和操作问题的成本远远超过 一个额外的 DBA 的薪资成本。 但确定 DBA 的最佳数量不是一门精确的科学，它取决于多种因素，包括： ● 数据库的数量。需要支持的数据库越多，数据库管理的工作就越复杂。每一个数据库都需要设计、部署、监控可用性和性能、备份以及管理。而一名DBA 能够控制的数据库数量是有限的。 ● 用户数量。随着更多的用户联机作为访问数据库应用程序的客户端，确保数据库的最 佳性能变得更加困难。此外，随着用户量的增加，问题量与调用量增加的可能性也随 之增加，进而增加了 DBA 工作的复杂性。 ● 应用程序的数量。一个单一的数据库能被多个应用程序使用，实际上，DBMS 的主 要好处之一是使数据可以在整个企业内共享。随着更多的应用程序联机，对数据库的 性能、可用性和需要的资源等方面都施加了压力，相同数量的数据库可能需要更多的 DBA 来支持。 ● 服务水平协议（SLA）。SLA 越严格，DBA 越难提供满意的服务。例如，需要1 秒响 应时间的 SLA 比需要 3 秒响应时间的 SLA 更加难以支持。 ● 可用性需求。当数据库具有可允许的计划停机时间时，数据库管理就变得更加容易， 因为一些DBA 任务要么需要中断运行，要么在中断时更加容易进行。一些考虑（诸 如要支持电子商务交易和网络），推动了对 24/7 数据库可用性的需求。 ● 停机时间的影响。数据库不可用对财务的影响越大，DBA 就越困难，因为有人会施 加压力以确保数据库更佳的可用性。 ● 性能需求。随着对数据库的访问需求变得更加面向性能、更加快速，而要求的访问也 更加频繁，DBA 变得更加复杂。 ● 应用程序的类型。企业部署各种类型的应用程序，必须要支持的应用程序的类型对需要什么DBA 服务有所影响。DBMS 和数据库对关键任务的应用程序的需求与对非关 键任务的应用程序的需求是不同的。关键任务的应用程序可能更需要持续地监控和更多的警惕，以确保其可用性。同样，OLTP 应用程序与OLAP 应用程序会有不同的特 点及管理需求。OLTP 处理事务的时间可能比OLAP 查询时间更短；OLTP 应用程序执行读取和写入操作，而OLAP 应用程序通常只有读取操作。每种应用程序都有管理挑战，都施加了不同的 DBA 程序与需求。 ● 波动性。数据库变更需求的频率是需要额外的DBA 与否的重要因素。一个很少需要 变更的静态数据库环境，与一个不稳定的、经常变更的数据库环境需要DBA 付出的 努力是不同的。遗憾的是，大多数据库和应用程序波动性水平往往会随着时间的推移发生巨大的变化。很难确定整体的数据库环境将在其生命周期内如何波动。 ● DBA 人员的经验。现有DBA 人员的技能将对是否还需要额外的DBA 产生影响。一 名技术娴熟的DBA 人员能够做到的要比一个新手团队多。且技能比经验更能决定所 需要的DBA 人员的水平。一名有两年工作经验的、非常积极的DBA 可能轻松超过 一名具有十年工作经验却筋疲力尽、无心工作的老手。 ● 开发人员的经验。从事数据库和SQL 编程的开发人员越不熟练，在开发过程、执行 复杂的SQL 任务、分析、调试、调优、确保连接性中需要DBA人员介入的就越多。 随着开发人员经验的增加，DBA 工作的复杂性也相应减少。 ● 终端用户经验。当终端用户试图通过随机SQL 语句直接访问数据库时，他们的技能 水平将直接影响 DBA 工作的复杂性。 ● DBA 工具。DBMS 供应商和为数不少的ISV 都提供自动执行DBA 任务的工具，从 而使得管理数据库变得更容易。工具的可用性越高且介入度越深，DBA 的工作将会 变得越简单。行业分析师预估一旦没有了 DBA 工具，DBA 的需求量将两倍于现在的 数目。 尽管罗列了以上复杂的问题，但要想把所有这些因素都合并成一个公式而得出需要雇佣 的 DBA 最佳数量还是非常困难的。尽管研究或许有些过时，但 META 集团 的行业分析师还是创造了一个宽松的公式计算DBA 努力的水平（Level of Effort，LOE）。公式并不严谨，但是通过六种因素得出 DBA LOE ：系统复杂性、应用程序不成熟度、终端用户水平参差不齐、 软件功能、系统可用性和人员不成熟度。通过尽可能地评估表示每种因素高或低的分值，将这些值代入公式得出一个数字，再将该数字转换成所需的 DBA 数量的预估。 * * * * * P28