本节书摘来自华章社区《DBA修炼之道：数据库管理员的第一本书》一书中的第1章，第1.5节数据库管理、数据管理和系统管理，作者（美）Craig S. Mullins，更多章节内容可以访问云栖社区“华章社区”公众号查看
1.5 数据库管理、数据管理和系统管理
一些企业分别为数据的商业方面和技术方面定义了不同的角色。数据的商业方面与数据管理是保持一致的，而更多技术方面都由数据库管理掌控。并不是每一家企业都有数据管理的职位，而许多企业都将数据管理并入数据库管理了。
许多企业都将数据管理并入了数据库管理。
有时企业也将数据管理的技术方面进行分离，DBA负责使用DBMS，而其他角色（系统管理或系统编程）负责安装并升级DBMS。
1.5.1 数据管理
数据管理（Data Administration，DA）把数据资源管理的商业方面和用于数据管理的技术分离开。DA存在于一家企业，与数据的实际商业用户联系更加密切。DA团队负责理解商业词汇并将其转换成逻辑数据模型。回到前面所说的应用程序开发生命周期，数据管理员（DA）会更多地参与需求收集、分析和设计阶段。而DBA参与设计、开发、测试和运作阶段。
DA和DBA的另一个有区别因素是他们工作的重点。DA负责以下问题：
确定并编写商业用户需要的数据目录；
概念化产品并逻辑化数据模型，准确描述业务流程中的数据元素之间的关系；
产生企业数据模型，它要整合所有企业/业务流程使用的数据；
为企业设置数据政策；
确定数据拥有者和管理者；
为数据的控制和使用设置标准。
总之，DA可看作企业的首席数据官。尽管DA的职位和技术没什么特别的关系，但依我看来，DA根本不是一个行政职位。实际上很糟糕，许多IT企业声称它们把数据看作公司的财产，但当你审视它们的行为时便会发现此声明的虚假。数据政策的责任常移交给一些技术专家，但他们不能专注于非技术性的、商业方面的数据管理。这些专家可以很好地保证数据的可用性、性能和可恢复性，但通常不能保证数据的质量，也不能设置公司的数据政策。
数据管理员可看作企业的首席数据官。
实际上，数据很少被视作真正的企业资产。看看每家企业都有的资产吧：资金、人力资源、设备和原材料，每一种都是模式化的：账户一览表、企业组织图和层次报表、建筑蓝图和办公室布局及材料账单，每一种都可跟踪、都受保护。企业还请来专业会计师确保资产账目没有任何差池。我们能说大部分公司也这样对待数据吗？
一个成熟的DA组织负责规划并指导整个企业的数据使用需求。这个角色围绕数据是如何记录、共享和实施的展开工作。DA的一个很大的责任是确保将数据元素在数据字典或数据存储库中予以准确地记录。这是DA和DBA之间另外一个关键区别，DA关注存储库，而DBA关注物理数据库和DBMS。
此外，DA处理元数据，这与处理数据的DBA截然相反。元数据称作“数据的数据”，更准确地说，元数据是对数据和业务所需要的数据的描述。数据管理负责业务和元数据策略。
这里举几个元数据的例子，它可以包括数据元素的定义，某个数据元素的业务名称，该元素的任何缩写形式，该元素的数据类型及长度。没有了元数据，数据就难以使用。比如，数字12是个数据，但是什么类型的数据呢？换句话说，12意味着什么？没有元数据我们就无从知道。考虑下面几个问题：
这是代表每年的第12个月吗？
代表某个月的第12天？
会是年龄吗？
鞋码？
是一个IQ？但愿不是如此。
其他
但是也有更多技术方面的元数据，还以刚才的数字12为例：
12是大数字还是小数字？
它的域是什么？（也就是说，12所可能表示的单个数值属于什么领域。）
数据类型是怎样的？整型还是一个“有零刻度”的十进制数？
元数据为数据提供了得以理解的上下文，因此也就成为数据的信息。在许多企业，元数据没有系统地捕获和编目，而大多存在于商业用户的脑子里。元数据在系统中捕获的位置遍布文件定义中的多个程序，以及准确性参差不齐的文档中，或长时间不用的程序定义中。当然，其中一些位置在DBMS的系统目录中。
元数据为数据提供了得以理解的上下文，因此也就成为数据的信息。
综合的元数据策略使得企业知道所控制的资产信息并衡量这些资产的价值。更多关于元数据的信息请参考第22章。
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中用到的知识，根据逻辑模型创建一个有效且合适的物理数据库设计。DBA最终的物理模型对于DA的依赖不会比DA的概念和逻辑数据模型对DBA的依赖更多。
DBA是DA团队与技术人员及应用程序编程人员之间沟通的桥梁。当然，DBA的工作大多是对基于数据库的物理设计创建的数据库以及访问这些数据库的应用程序的持续支持。有关这些职责的概述会在1.6节展开。
DBA是DA团队与技术人员以及应用程序编程人员之间沟通的桥梁。
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的职责提供了简短的描述。
