读DAMA数据管理知识体系指南13数据架构范例

1. 数据存储与操纵

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. 业务驱动因素

2.1. 数据存储与操纵活动对于依靠数据的企业来说非常关键
2.2. 重要驱动因素是业务连续性

• 2.2.1. 如果某个系统不可用，企业运营可能受到损害，甚至完全停止运营
  
• 2.2.2. 为IT运营提供可靠的数据存储底子设施，可以最大幅度降低业务中断的风险
  

3. 目标

3.1. 在整个数据生命周期中管理数据的可用性
3.2. 确保数据资产的完整性
3.3. 管理数据生意业务事件的性能
4. 指导原则

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. 数据库术语

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. 数据生命周期管理

6.1. DBA是所有数据库变更的羁系人
6.2. DBA应该采用一种可控制、可记录、可审计的流程，将应用步伐的数据库变更实施到QA情况和生产情况中
6.3. 流程通常由主管批准的服务申请或变更申请来启动
6.4. DBA应该有一个回退计划，在变更出现异常的情况下可以撤销变更
6.5. 贯穿数据设计、实现到利用（任何系统存储、处理和检索数据）的整个数据生命周期，DBA都有责任维护和确保数据的准确性和一致性
6.6. 数据生命周期管理包括为数据的获取、迁移、保留、过期和处置举行的实施计谋和过程
6.7. 稳妥的做法是预备好检查表，确保所有的任务都能高标准、高质量的完成
7. DBA

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. 数据架构范例

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. 联邦数据库

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. 非联邦数据库系统

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

11.1. 属于一种联邦数据库，用于安全管理金融生意业务
11.2. 能用来举行合同管理或健康信息交换
11.3. 区块链数据库有两种结构范例：单条记录和块
11.4. 区块内的生意业务信息也不再会发生变革

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。