1.1. 数据存储与操作包括对存储数据的设计、实施和支持，最大化实现数据资源的价值，贯穿于数据创建/获取到处置的整个生命周期

1.2. 数据库操作支持

1.2.1. 主要关注与数据生命周期相关的活动，即从数据库环境的初始搭建，到数据的获取、备份再到处置数据

1.2.2. 还包括需要确保数据库性能状态良好

1.2.2.1. 监控和优化数据库性能对数据库支持是非常重要的

1.3. 数据库技术支持

1.3.1. 包括定义满足组织需要的数据库技术要求，定义数据库的技术架构，安装和管理数据库技术，以及解决与数据库相关的技术问题

1.3.2. 数据库管理实践可能也是数据管理实践领域最成熟的

1.4. 数据存储与操作代表了数据管理高度技术性的一面

2.1. 数据存储与操作活动对于依赖数据的企业来说非常关键

2.2. 主要驱动因素是业务连续性

2.2.1. 如果某个系统不可用，企业运营可能受到损害，甚至完全停止运营

2.2.2. 为IT运营提供可靠的数据存储基础设施，可以最大幅度降低业务中断的风险

3.1. 在整个数据生命周期中管理数据的可用性

3.2. 确保数据资产的完整性

3.3. 管理数据交易事务的性能

4.1. 识别自动化的机会并采取行动

4.1.1. 自动化数据库开发过程、开发工具和流程，缩短每个开发周期过程，可以减少错误和返工，将对开发团队的影响降至最低

4.2. 构建时就考虑重用的思想

4.2.1. 开发抽象的和可重用的数据对象并推广使用，不让应用程序与数据库模式紧耦合

4.2.2. 数据库视图、触发器、函数、存储过程、应用数据对象和数据访问层、XML和XSLT、ADO.NET类型数据集和Web服务

4.2.3. DBA应该具备评估虚拟化数据的最佳方法，最终目标是尽可能快速、容易和轻松地使用数据库

4.3. 理解并适当使用最佳实践

4.3.1. DBA应该将数据库标准和最佳实践作为需求来推广

4.3.2. 如果出现偏离标准的情况，并且偏离理由可以接受，那么DBA应该有足够的灵活性来处理这些偏差

4.3.3. 数据库标准不应该成为项目成功的威胁

4.4. 支持数据库的标准需求

4.4.1. 如果开发团队要自己写数据库更新过程或数据访问层，那么SLA应该反映出从DBA到开发团队的责任转移

4.4.2. 避免要么完全遵循，要么完全不遵循标准的做法(“all or nothing”)

4.5. 为项目中的DBA角色设置期望值

4.5.1. 在项目定义阶段就让DBA参与进来，有助于确保项目方法论贯穿整个软件开发生命周期

4.5.2. DBA可以预先理解项目需求和支持需求，通过明晰项目团队对数据团队的期望值来促进沟通

4.5.3. 在项目分析和设计阶段拥有专门的主、备DBA，有助于阐明对DBA任务、标准、工作成果和开发工作时间表的期望值

4.5.4. 项目团队还应该阐明对项目实施后的支持期望

5.1. 数据库术语是专有的、技术性的

5.2. 数据库

5.2.1. 数据库是存储数据的集合

5.2.2. 一些大型数据库也称为“实例(Instance)”或“模式(Schema)”

5.3. 实例

5.3.1. 通过数据库软件，执行对某一特定存储区域的控制访问

5.3.2. 一个组织通常使用不同的存储区域，同时执行多个实例

5.3.3. 每个实例与所有其他实例相互独立

5.4. 模式

5.4.1. 模式是数据库或实例中的数据库对象的一个子集(Subset)

5.4.2. 模式被用来将数据库对象组织成多个可管理的集合

5.4.3. 一个模式拥有一个用户以及访问该模式内容的特定访问列表

5.4.4. 模式的常见用法是将包含敏感数据的对象与普通用户群隔离，或者是在关系数据库中将只读视图与基础表隔离

5.4.5. 模式还可以表示具有相似性的数据库结构的集合

5.5. 节点

5.5.1. 一台单独的计算机作为分布式数据库处理数据或者存储数据的一个部分

5.6. 数据库抽象

5.6.1. 通用应用接口(API)通常用来调用数据库函数

5.6.1.1. ODBC(Open Database Connectivity)是支持数据库抽象的一个API示例

5.6.1.2. 一个应用可以连接到多个不同数据库，而开发者不必知道所有函数可能调用了哪些数据库

5.6.2. 优势是可移植性很强

5.6.3. 缺点是对于某些针对特定数据库的函数，就很难跨库使用了

6.1. DBA是所有数据库变更的监管人

6.2. DBA应该采用一种可控制、可记录、可审计的流程，将应用程序的数据库变更实施到QA环境和生产环境中

6.3. 流程通常由主管批准的服务申请或变更申请来启动

6.4. DBA应该有一个回退计划，在变更出现异常的情况下可以撤销变更

6.5. 贯穿数据设计、实现到使用（任何系统存储、处理和检索数据）的整个数据生命周期，DBA都有责任维护和确保数据的准确性和一致性

6.6. 数据生命周期管理包括为数据的获取、迁移、保留、过期和处置进行的实施策略和过程

6.7. 稳妥的做法是准备好检查表，确保所有的任务都能高标准、高质量的完成

7.1. 数据库管理员(DBA)是数据专业中最常见、也是最广泛被接纳的角色

7.2. 在数据存储与操作活动中承担着主导角色

7.3. 在数据安全活动及物理模型建模、数据库设计活动中也是关键的角色

7.4. DBA为开发环境、测试环境、QA环境及其他特殊数据库环境提供支持

7.5. DBA不是独立完成数据存储和操作所有相关活动的唯一角色

7.5.1. 数据管理专员、数据架构师、网络管理员、数据分析师和安全分析师也要参与数据性能、保留和恢复的规划

7.5.2. 这些团队还可以参与外部资源的数据获取和数据处理

7.6. 从专业分工来划分，DBA被分为生产DBA、应用程序DBA、过程和开发DBA

7.7. 在各个组织中，IT部门内的不同专业角色可能向不同组织汇报工

7.8. 生产DBA

7.8.1. 生产DBA可能归属于生产基础设施组或者应用维护支持组

7.8.2. 主要负责数据操作管理

7.8.2.1. 通过性能调优、监控、错误报告等活动，确保数据库的性能及可靠性

7.8.2.2. 通过建立备份与恢复机制，确保在任何意外情况下数据能够被恢复

7.8.2.3. 通过建立集群和容错机制，确保数据连续可用

7.8.2.4. 执行其他数据库维护活动，如建立数据归档机制

7.8.3. 可交付结果

7.8.3.1. 生产数据库环境

7.8.3.1.1. 支持服务器上的数据库管理系统(DBMS)实例

7.8.3.1.2. 提供足够的资源和容量，确保获得很好的性能

7.8.3.1.3. 配置适当的安全性、可靠性和可用性级别

7.8.3.1.4. 数据库系统管理员为DBMS的环境负责

7.8.3.2. 在生产环境中，控制数据库实施变更的机制和流程

7.8.3.3. 针对各种可能导致数据丢失或数据损坏的情况，建立确保数据完整、可用和恢复的机制

7.8.3.4. 建立任何可能发生在数据库或数据服务器上的错误检测和报告的机制

7.8.3.5. 提供与服务水平协议(SLA)相匹配的数据库服务，包括可用性、数据恢复及性能等

7.8.3.6. 建立伴随工作负载和数据量变化的数据库性能监控的机制和过程

7.9. 应用程序DBA

7.9.1. 应用程序DBA及过程和开发DBA有时被归并应用开发组

7.9.2. 应用程序DBA通常负责所有环境（开发、测试、QA及生产）中的一套或多套数据库，而不是指定负责管理某个环境的数据库系统

7.9.3. 应用程序DBA被当作应用支持团队不可或缺的成员

7.9.4. 专注于某个指定的数据库，可以为应用程序开发人员提供更好的支持服务

7.9.5. 应与数据分析师、建模师和架构师等密切协作

7.10. 过程和开发DBA

7.10.1. 应用程序DBA及过程和开发DBA有时被归并应用开发组

7.10.2. 过程DBA负责审查和管理数据库的过程对象

7.10.2.1. 专门开发和支持关系数据库控制和执行的过程逻辑：存储过程、触发器及用户自定义的函数(UDFs)

7.10.2.2. 确保过程逻辑是按规划进行的、可实施的、经过测试的、可共享的（可重用的）

7.10.3. 开发DBA主要关注数据设计活动，包括创建和管理特殊用途的数据库

7.10.3.1. “数据沙盒”或者数据探索区

7.10.4. 两个角色会合并成一个职位，统称为开发DBA

7.11. 网络存储管理员

7.11.1. NSA一般归属于基础设施组

7.11.2. 网络存储管理员(Network Storage Administrators, NSA)主要关注支持数据存储阵列的软硬件

7.11.3. 不同于单一的数据库管理系统，多元化的网络存储阵列系统各有不同的关注特性和监控需求

8.1. 集中式数据库

8.1.1. 集中式系统管理单一数据库

8.1.2. 集中式数据库将所有数据存放在一个地方的一套系统中，所有用户连接到这套系统进行数据访问

8.2. 分布式数据库

8.2.1. 分布式系统管理多个系统上的多个数据库

8.2.2. 分布式数据库通过扫描大量节点来快速获取数据

8.2.3. 主流的分布式数据库技术是基于普通的商业硬件服务器来实现的

8.2.4. 被设计成可横向扩展，即从一台到成千上万台服务器，而每台服务器提供本地的计算和存储能力

8.2.5. 高效能力不靠单一硬件，而是依靠数据库管理软件在服务器间复制数据来实现，因而可以让整个计算机集群提供高效的服务

8.2.6. 任何一台给定的计算机都可能会发生故障，但整个系统不太可能丧失服务能力

8.2.7. 数据位于各个计算节点上，通过集群提供高带宽的聚合数据访问能力

8.2.7.1. 文件系统和应用程序在设计上都能自动处理节点失效的情况

8.2.8. 根据组件系统的自治性分为两类

8.2.8.1. 联邦的（自治的）

8.2.8.2. 非联邦的（非自治的）

8.3. 可视化/云计算平台

8.3.1. 虚拟化（或称“云计算”）提供计算、软件、数据访问和存储服务，不要求终端用户了解提供服务系统的物理位置和相关配置

8.3.2. 云计算的概念和电网的概念非常相似，即最终用户使用电但不必了解提供电力服务的基础设施，也不必理解供电设备

8.3.3. 虚拟化可以本地部署，也可以远程部署

8.3.4. 虚拟机镜像

8.3.4.1. 云平台允许用户购买虚拟机实例，只使用一段时间

8.3.5. 数据库即服务(DaaS)

8.3.5.1. 一些云平台为用户提供DaaS服务的配置选项，无须为数据库单独购买虚拟机

8.3.6. 管理托管在云上的数据库

8.3.6.1. 数据库不是作为一项服务来提供的，而是云厂商代表应用程序所有者管理数据库

8.3.7. DBA需要与网络和系统管理员协调，建立系统的项目集成机制

8.3.7.1. 标准化/整合

8.3.7.1.1. 整合减少数据在组织里存储位置的数量，包括在一个数据中心内数据存储和处理的数量

8.3.7.2. 服务器虚拟化

8.3.7.2.1. 虚拟化技术允许将多个数据中心的设备（如服务器）进行替换或整合

8.3.7.2.2. 虚拟化减少了资金和运营成本，降低了能源消耗

8.3.7.2.3. 虚拟化技术为本地和云端的数据存储提供了更大的灵活性

8.3.7.3. 自动化

8.3.7.3.1. 包括准备、配置、修正、版本管理及合规等一系列自动化任务

8.3.7.4. 安全

8.3.7.4.1. 虚拟环境的数据安全，需要与物理设施的安全一起考虑

9.1. 数据联邦提供的数据不需要对数据源进行额外复制或持久化

9.2. 联邦数据库系统地将多个自治的数据库系统映射成一个单一的联邦数据库

9.3. 组成联邦的数据库有时是分散在不同地理位置，通过计算机网络关联在一起

9.4. 由于是数据联邦，联邦数据库并没有将真实的数据整合到一起，而是通过数据互操作性将数据联邦视为一个大型对象来管理

9.5. 联邦数据库对于类似企业信息集成、数据可视化、模式匹配和主数据管理这样异构和分布式的集成项目非常合适

9.6. 联邦数据库管理系统可以分为松耦合和紧耦合两类

9.6.1. 松耦合联邦系统需要多个组件数据库来构造他们自己的联邦模式

9.6.1.1. 用户一般是通过一种多数据库语言访问其他组件数据库系统，这会消除任何级别的地域透明性，让用户直接获知联邦模式的知识

9.6.2. 紧耦合联邦系统由组件数据库系统组成，用独立的进程构造，发布一个集成的联邦模式

9.6.2.1. 相同的模式能适用于联邦的所有部分，无须进行数据复制

10.1. 非联邦数据库系统则是将非自治的数据库集成在一起，它们被集中的数据库管理系统控制、管理和约束

11.1. 属于一种联邦数据库，用于安全管理金融交易

11.2. 能用来进行合同管理或健康信息交换

11.3. 区块链数据库有两种结构类型：单条记录和块

11.4. 区块内的交易信息也不再会发生变化