Section 12.1: Database Technologies & DBA Roles

DAMA Certified Data Management Professional CDMP

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Overview & DMBoK Framework

1.1 CDMP Exam Details & Strategy 1.2 The DMBoK Framework 1.3 Data Management Organization & Roles

2 Chapter 2: Data Governance (Part A)

2.1 Data Governance Principles & Drivers 2.2 Operating Models & Structures 2.3 Policies, Standards, and Procedures

3 Chapter 2: Data Governance (Part B)

2.4 Data Stewardship 2.5 Governance Metrics & Implementation

4 Chapter 3: Data Modeling and Design (Part A)

Section 3.1: Conceptual, Logical, and Physical Models Section 3.2: ERD Notations & Relational Modeling Section 3.3: Normalization

5 Chapter 3: Data Modeling and Design (Part B)

3.4 Dimensional Modeling 3.5 Naming Standards & Modeling Best Practices

6 Chapter 4: Data Quality (Part A)

Section 4.1: Data Quality Dimensions Section 4.2: Data Quality Policy & Rules Section 4.3: DMAIC & DQ Improvement Lifecycle

7 Chapter 4: Data Quality (Part B)

4.4 Root-Cause Analysis & Remediation 4.5 DQ Metrics, Tools, and Reporting

8 Chapter 5: Metadata Management (Part A)

5.1 Business, Technical, and Operational Metadata 5.2 Metadata Lineage & Impact Analysis 5.3 Repository Architectures

9 Chapter 5: Metadata Management (Part B)

5.4 Standards and Semantics 5.5 Metadata Governance & Integration

10 Chapter 6: Master and Reference Data Management

6.1 Master vs Reference Data 6.2 MDM Repository Architectures 6.3 Match-Merge & Identity Resolution 6.4 Reference Data Governance & Standards

11 Chapter 7: Data Warehousing and Business Intelligence

7.1 DW Architectures: Inmon vs Kimball 7.2 Data Warehousing Storage & Load Patterns 7.3 BI Delivery & OLAP 7.4 Data Marts & Enterprise Data Warehouses

12 Chapter 8: Data Architecture

8.1 Enterprise Data Architecture & Zachman Framework 8.2 Data Flow Diagrams & Value Chains 8.3 Architecture Frameworks & Standards

13 Chapter 9: Document and Content Management

9.1 Records Management & ECM 9.2 Retention, Disposal, and E-Discovery 9.3 ARMA GARP Principles & Taxonomies

14 Chapter 10: Data Integration and Interoperability

Section 10.1: Integration Patterns & Technologies Section 10.2: Replication & Virtualization Section 10.3: Canonical Models & Integration Standards

15 Chapter 11: Data Security

Section 11.1: Security Principles: CIA Triad & Privacy Section 11.2: Access Control & Encryption Section 11.3: Security Regulations & Standards

16 Chapter 12: Data Storage and Operations

Section 12.1: Database Technologies & DBA Roles Section 12.2: Backup, Recovery, and High Availability Section 12.3: Performance Tuning & Operations

17 Chapter 13: Big Data and Data Science

13.1 Big Data V's & Technologies

18 Chapter 14: Data Ethics

14.1 DMBoK Data Ethics Framework

19 Chapter 15: Data Management Process and Maturity

15.1 Maturity Assessment Frameworks

Section 12.1: Database Technologies & DBA Roles

Key Takeaways Explain This Topic AI

Relational databases enforce strict schemas and ACID compliance, making them ideal for transaction-oriented business systems.

NoSQL database types—document, key-value, graph, and column-family stores—trade ACID constraints for scalability, flexibility, and performance under specific access patterns.

The Database Administrator (DBA) role is divided into specialized functions including Production, Development, Application, and Data Administration.

Last updated: July 2026

12.1 Database Technologies & DBA Roles

Data Storage and Operations is the DAMA DMBoK2 knowledge area that governs the physical deployment and administrative support of stored data assets. The primary objective is to balance data availability, security, cost-effectiveness, and system performance throughout the data lifecycle. To achieve this, data management professionals must possess a deep understanding of database management system architectures, NoSQL database structures, and the specialized functions of the Database Administrator (DBA).

Relational Database Management Systems (RDBMS)

The foundational technology of enterprise data storage remains the Relational Database Management System (RDBMS). Introduced by Edgar F. Codd in 1970, the relational model represents data in mathematical relations, physically realized as tables. A relational database is composed of tables containing rows (tuples) and columns (attributes), with all values stored in atomic domains.

Data integrity within an RDBMS is maintained through structural constraints:

Primary Key : A column or set of columns that uniquely identifies each row in a table. Primary keys must be unique and cannot contain null values (enforcing entity integrity).

Foreign Key : A column that establishes a link between data in two tables, referencing the primary key of another table to enforce referential integrity.

Unique Constraints : Prevents duplicate values in specific columns.

Check Constraints : Enforces domain-specific rules (e.g., age must be greater than zero).

To manage data modification and retrieval, RDBMS systems utilize Structured Query Language (SQL) as the standard programming interface. RDBMS platforms are engineered to support transactional processing by adhering to the ACID properties . These properties guarantee that database transactions are processed reliably:

ACID Property Definition CDMP Exam Focus & Technical Realization

Atomicity All operations within a transaction must complete successfully, or the entire transaction is rolled back. The 'all-or-nothing' principle. Implemented via database transaction logs (undo/redo logs) that record state changes.

Consistency A transaction must transition the database from one valid state to another, maintaining all schema constraints and rules. Schema validation, foreign keys, and unique constraints are strictly enforced before committing changes.

Isolation Concurrent execution of transactions results in a state equivalent to serial execution. Managed through locking mechanisms (shared, exclusive) and isolation levels (Read Uncommitted, Read Committed, Repeatable Read, Serializable).

Durability Once a transaction is committed, its effects are permanent and survive any subsequent system failure. Completed transactions are written to non-volatile storage and recorded in transaction logs before the commit is confirmed.

While RDBMS technologies excel at transactional consistency, they face scalability limitations. They are designed for vertical scaling (scaling up by adding CPU, RAM, or storage to a single server). When datasets grow to petabyte scale, or ingestion rates reach millions of writes per second, vertical scaling becomes financially and technologically unfeasible.

NoSQL Database Architectures

To handle web-scale data volumes, rapid ingestion, and unstructured data formats, organizations deploy Not Only SQL (NoSQL) databases. NoSQL databases relax the strict consistency constraints of RDBMS to achieve horizontal scalability (scaling out by distributing data across multiple commodity servers).

NoSQL design is heavily influenced by the CAP Theorem , formulated by Eric Brewer. The theorem states that a distributed data store can simultaneously provide at most two of the following three guarantees:

Consistency (C): Every read receives the most recent write or an error.

Availability (A): Every non-failing node returns a non-error response, without guaranteeing it contains the most recent write.

Partition Tolerance (P): The system continues to operate despite an arbitrary number of messages being dropped or delayed by the network between nodes.

In a distributed environment, network partitions (P) are inevitable. Therefore, NoSQL systems must trade off between consistency (CP systems) and availability (AP systems), often adopting the BASE model (Basically Available, Soft state, Eventual consistency).

DAMA DMBoK2 classifies NoSQL database technologies into four distinct categories:

Document Database : These systems store data in semi-structured formats, primarily JavaScript Object Notation (JSON), BSON (Binary JSON), or XML. Unlike RDBMS, document databases do not enforce a rigid schema at the database level. Instead, they use a schema-on-read model, permitting individual documents within the same collection to contain different fields. Document databases are optimal for content management systems, e-commerce catalog management, and user profile stores. Examples include MongoDB and CouchDB.

Key-Value Store : The simplest NoSQL architecture, which stores data as a collection of key-value pairs. The key is a unique identifier, and the value is an opaque blob (e.g., string, JSON, binary) that the database engine does not interpret. Key-value stores deliver ultra-low latency reads and writes because of their minimal processing overhead. They are extensively used for session state management, caching, configuration settings, and simple lookup tables. Examples include Redis and Amazon DynamoDB.

Graph Database : Designed specifically to model and traverse relationships. A graph database represents data as nodes (entities, such as people or products), edges (directed relationships between nodes, such as 'purchased' or 'friend of'), and properties (attributes key-value pairs associated with nodes or edges). Graph databases utilize 'index-free adjacency,' meaning each node contains direct physical pointers to its adjacent nodes. This eliminates the need for expensive table JOIN operations, making them ideal for fraud detection, social networks, master data lineage, and recommendation systems. Examples include Neo4j and Amazon Neptune.

Column-Family Store : Also known as wide-column stores, these databases organize data into columns rather than rows. Columns are grouped into column families, which are stored together on disk. This structure is highly optimized for sparse data (where rows have varying columns) and high-volume, write-heavy workloads. It allows write operations to be appended sequentially to memory (Memtables) and flushed to disk (SSTables), minimizing disk seek latency. They are widely used for IoT telemetry, web analytics clickstreams, and time-series data. Examples include Apache Cassandra and Apache HBase.

• Database Type Primary Data Model Schema Flexibility Typical Use Cases
• Relational (RDBMS) Tables (Rows and Columns) Schema-on-write (Strict) Financial transactions, ERP, CRM systems
• Document JSON/BSON Documents Schema-on-read (Highly flexible) E-commerce catalogs, user profile services
• Key-Value Key-Value pairs None (Value is an opaque blob) Caching, session states, real-time queues
• Graph Nodes, Edges, Properties Schema-on-read (Highly flexible) Fraud networks, social graphs, impact analysis

Column-Family Rows with columns (Wide Column) Schema-on-read (Semi-flexible) IoT monitoring, clickstream analytics

Database Administrator (DBA) Roles and Duties

Operating database systems requires specialized administrative roles. The Database Administrator (DBA) is responsible for the physical design, implementation, and operational support of database environments. DAMA DMBoK2 identifies several specialized DBA roles:

Production DBA : Focuses on operational maintenance, database availability, business continuity, and performance tuning of live production systems. Core responsibilities include installing and upgrading database engines, configuring backups, performing recoveries, monitoring system resources, applying security patches, and managing user access control.

Development DBA : Works closely with software development teams to optimize physical schema designs, write efficient SQL queries, create indexes, and test database application code before deployment to production environments.

Application DBA : Specializes in managing databases for specific third-party applications (such as SAP, Salesforce, or Oracle Financials). They handle application-specific configurations, patch applications, and schema updates provided by vendors.

Data Administrator (DA): Focuses on the logical and conceptual representation of data. Unlike DBAs who manage physical database files, hardware, and server performance, DAs manage metadata, define business data standards, create logical data models, and align data assets with data governance initiatives.

For the CDMP exam, understand this critical boundary: DBAs manage physical assets and performance (disks, memory, database files, recovery logs, indexing structures), whereas Data Administrators manage logical models and business metadata (data definitions, entity relationships, business rules, and terminology mapping).