database management system
Enable an AI agent to recognise a database management system, assess its ability to manage data reliably, and determine which operations are supported, authorised and safe in its current state.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex + Grok
Purpose and description
Enable an AI agent to recognise a database management system, assess its ability to manage data reliably, and determine which operations are supported, authorised and safe in its current state.
Software that owns one or more databases and gives applications languages and services for schema definition, query and update, concurrent multi-user access, integrity enforcement, authorization and crash recovery, so that durable shared data can be used without each program implementing storage, isolation or restart itself.
It can be Inspect implementation identity, enabled capabilities and deployment configuration through permitted interfaces.; Create or alter supported database objects after checking compatibility, privileges and migration effects.; Read or modify data using supported operations with explicit transaction and visibility requirements.; Diagnose query behaviour, contention, replication condition and resource constraints.; Perform authorised backup, restore or failover operations after checking prerequisites and recovery evidence.; Adjust DBMS configuration or coordinate upgrades after assessing availability and compatibility effects..
Distinguishing features
It supplies mechanisms for creating or managing databases and mediating access to their contents; a database itself is the managed collection.
It interprets data operations using a declared data model or access abstraction; a filesystem alone primarily exposes files and directories.
It governs data visibility, modification or coordination according to defined semantics; a passive file-format specification does not execute those rules.
It can be identified separately from applications that use it, including when supplied as an embedded library without a standalone server.
For a managed database service, its DBMS capabilities can be separated from surrounding provisioning, billing and infrastructure services.
Scope
+ DBMS product, edition, version and deployment identity
+ Supported data models, database objects and access interfaces
+ Query execution, concurrency, transaction and consistency behaviour
+ Persistence, recovery, replication and availability mechanisms
+ DBMS-enforced access controls and administrative boundaries
+ Operational health, capacity constraints and permitted maintenance actions
- Business meaning, ownership and quality of particular datasets
- Application workflows, business rules and application-side data access code
- Physical servers, storage devices and network infrastructure as independent assets
- Organisation-wide identity governance and security policy
- Enterprise data architecture, analytics pipelines and reporting products
- Commercial contracts and provider organisation management
Characteristics
- Identity level
- product family | versioned distribution | configured deployment Prevents product-level capabilities from being mistaken for enabled or observed deployment behaviour.
- Implementation identity
- References to product, edition, version, build and extensions Capabilities, compatibility and maintenance choices can depend on the exact implementation.
- Supported data models
- Set of declared models, such as relational, document, key-value, graph or other Determines which structures and operations the system can represent directly.
- Execution form
- embedded | server | distributed system; managed-service exposure recorded separately Determines process ownership, connection boundaries and available administrative control.
- Transaction scope
- Implementation-specific supported atomicity boundaries and exclusions Determines which changes can succeed or fail as one unit.
- Read visibility contract
- Documented isolation or consistency modes, scoped by operation and configuration Determines which concurrent or replicated changes an agent may observe.
- Acknowledgement durability
- Configured acknowledgement conditions and covered failure scenarios A successful write response does not establish survival under every possible failure.
- Operational mode
- unknown | starting | available | degraded | recovering | unavailable; read/write restrictions recorded separately Constrains which data operations and maintenance actions can currently proceed.
- Operation latency
- Milliseconds, with operation class, percentile, workload and observation window Supports assessment of responsiveness without treating incomparable workloads as equivalent.
- Capacity headroom
- Remaining bytes, connections or other named resource units, with limit and timestamp Helps identify resource exhaustion that could block queries, writes or recovery.
- Effective administrative authority
- Principal-to-operation permissions scoped to DBMS resources Separates technically supported actions from actions the current agent may perform.
Also called
+1
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 7 bundles · 13 layers · 20 findings · 32 questions.
DBMS identity and boundaries Establishes which DBMS is being described and where its data-management responsibilities begin and end.
An agent must distinguish a product claim from the capabilities and condition of an actual DBMS deployment.
Implementation and capabilities
Identifies the implementation and the evidence for its available features.
Versioned capability profile
Records product, edition, version and extensions while separating supported features from enabled features.
- Which product, edition, version, build and extensions identify this DBMS? definition
- Which documentation or direct inspection establishes whether each relevant capability is supported and enabled? provenance
Deployment and control boundary
Locates the DBMS within embedded, server, distributed and managed-service arrangements.
Managed system boundary
Identifies the components constituting this DBMS and the division of administrative responsibility.
- Which libraries, processes or coordinated nodes constitute this DBMS, and which databases does it manage? boundary
- Which controls belong to the DBMS operator, host application or service provider? boundary
Data model and access Describes how the DBMS represents managed data and accepts operations on it.
An agent needs to know which data structures and interfaces are valid before attempting inspection or modification.
Database object semantics
Captures supported data abstractions, namespaces and integrity mechanisms.
Representation and integrity
Records supported object types and which structural or integrity rules the DBMS actually enforces.
- Which data models, object types, namespaces and type rules does this configuration support? definition
- Which constraints does the DBMS enforce, and which require application-side enforcement? boundary
Operation interfaces
Captures supported languages, protocols and client interaction requirements.
Request and result contract
Records how clients submit operations and interpret results, errors and interrupted requests.
- Which query languages, APIs, protocols and client versions are supported for the required operations? definition
- How can an agent determine whether an interrupted request completed, and when is retrying it safe? action
Transactions and visibility Defines the boundaries of coordinated changes and the visibility of concurrent or replicated updates.
Correct agent decisions depend on the actual guarantees attached to reads and writes, rather than assumptions about the DBMS category.
Atomic change boundaries
Captures transaction scope, commit behaviour and partial-failure possibilities.
Transaction contract
Records which operations can be grouped atomically and how their outcomes are established.
- Which records, objects, databases or partitions can participate in one atomic change, and which operations are excluded? boundary
- How should an agent handle aborts, deadlocks or an unknown commit outcome without duplicating effects? action
Concurrent and replicated reads
Captures isolation, consistency and read-routing effects.
Read observation guarantees
Records what an operation may observe under the selected session, transaction and replica settings.
- Which isolation or consistency guarantees apply to this operation, and which anomalies remain possible? definition
- Which settings or routing choices are required when an agent needs to observe its own preceding write or a sufficiently fresh value? action
Persistence and recovery Describes the survival of acknowledged changes and the evidence that service and data can be recovered.
An agent must distinguish successful execution, durable storage, replication and recoverable backups.
Write survival
Captures persistence mechanisms and the failure assumptions behind write acknowledgements.
Durability and failure contract
Records how logging, persistence and replication settings affect survival of accepted writes.
- What must happen before a write is acknowledged under the active configuration? definition
- Which process, host, storage or replica failures are covered by that acknowledgement contract? boundary
Restoration and service continuity
Captures backup usability, restore procedures and failover prerequisites.
Verified recovery options
Records available recovery paths, their dependencies and evidence from actual recovery exercises.
- What restore or failover exercise establishes the recoverable point, elapsed recovery time and integrity of the result? provenance
- Which backups, logs, keys, compatible versions and coordination steps are required before recovery or failover can proceed? action
Access and data protection Captures DBMS-enforced authority, isolation and protection of managed data.
An agent needs effective permissions and protection boundaries to decide which data and administrative operations it may perform.
Principal and privilege enforcement
Describes authentication, effective privileges and resource-level restrictions.
Effective operation authority
Records which authenticated principal is acting and how its effective privileges are determined.
- Which principal, active roles and execution context determine the agent's effective privileges? definition
- Which database, object, row, field or administrative restrictions govern the proposed operation? action
Protection and audit boundaries
Describes encryption coverage, isolation limits and evidence of data access or administrative changes.
Protected data paths
Records protection across DBMS interfaces and storage paths, including gaps and external dependencies.
- Which client connections, stored data, logs, temporary data and backups are protected, and who controls the required keys? boundary
- Which enabled audit records establish data access or administrative changes, and what activity is omitted? provenance
Operation and change readiness Connects observed DBMS condition to workload handling and maintenance decisions.
A DBMS can remain reachable while contention, exhausted resources or incompatible changes make particular operations unsafe or ineffective.
Workload health and capacity
Captures evidence of useful service, bottlenecks and remaining operating capacity.
Workload-specific operating condition
Records health against identified workloads using latency, failures, contention and resource measurements.
- What are the observed latency, throughput and error rates for the relevant operation classes over a stated interval? measurement
- Which query plans, waits, locks, replication delays or resource limits explain current degradation or constrain additional load? measurement
Maintenance and compatibility
Captures prerequisites and consequences of structural, configuration and version changes.
Safe change envelope
Records whether a proposed change requires blocking, restart, data rewriting or coordinated client and replica updates.
- Will the proposed schema, index, configuration or version change require locks, a restart, data rewriting or temporary extra capacity? action
- What compatibility evidence, validation steps and supported reversal or recovery path are required before applying the change? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Kinds and varieties
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Relational SQL DBMS (row-store OLTP)
- Columnar analytic / MPP warehouse DBMS
- Document-oriented DBMS
- Key-value store
- Wide-column (column-family) DBMS
- Graph DBMS
- Time-series DBMS
- Vector / embedding DBMS
- Which of these kinds and varieties hold for the sense of database management system this model covers, and on what evidence? provenance
Identifiers and schemes
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Wikidata - Q176165 - Item for the class 'database management system'; the stored collection is Q8513.
- CPE 2.3 - cpe:2.3:a:<vendor>:<product>:<version>:*:*:*:*:*:*:* - Names a specific DBMS product release, not the class.
- ISO/IEC 2382 - term 'database management system' in the IT vocabulary - Defines the term in the ISO information-technology vocabulary; not a product code.
- Which of these identifiers and schemes hold for the sense of database management system this model covers, and on what evidence? provenance
Standards and regulation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- ISO/IEC 9075 (SQL) - ISO/IEC JTC 1/SC 32
- ISO/IEC 9075-3 Call-Level Interface (CLI) - ISO/IEC JTC 1/SC 32
- W3C SPARQL - World Wide Web Consortium (RDF/graph query stores)
- PCI DSS (esp. stored-cardholder-data, access control, logging) - PCI Security Standards Council
- GDPR (lawful processing, security of processing, including databases holding personal data) - European Union
- NIST SP 800-53 (AU, AC, SC, SI controls as applied to database systems) - NIST
- Common Criteria / NIAP protection profiles for database management systems - CCRA / NIAP
- Which of these standards and regulation hold for the sense of database management system this model covers, and on what evidence? provenance
Real-world use
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Online transaction processing behind banking, retail checkout, booking and ERP/CRM applications.
- Cloud managed instances (for example Amazon RDS, Cloud SQL, Azure SQL) used as the system of record for web and mobile backends.
- Embedded engines such as SQLite inside browsers, mobile apps and desktop software, often unnoticed by the end user.
- Analytic warehouses and columnar engines feeding BI dashboards and batch reporting.
- Operational stores for session state, catalogs, content, telemetry and scientific collections, including replicas used for failover and read scale-out.
- Which of these real-world use hold for the sense of database management system this model covers, and on what evidence? provenance
Typical measurements
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- OLTP query latency (point lookup / short transaction) - 0.1-100 - ms
- Transaction throughput - 10^2-10^6 - transactions/s
- On-disk data volume - 1-10^7 - GB
- Replication lag (asynchronous replicas) - 0-60 - s
- Service availability target - 99.9-99.999 - %
- Concurrent client sessions - 10-100000 - connections
- Which of these typical measurements hold for the sense of database management system this model covers, and on what evidence? provenance
Failure modes and hazards
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Crash or power loss with WAL/fsync misconfiguration, causing committed work to vanish or the catalog to disagree with heap/index pages.
- Split-brain after network partition, producing divergent replicas and silent lost or duplicated writes.
- Undetected page corruption or index damage that surfaces only on a later query or restore.
- Deadlocks, lock convoys and table-level migrations that stall writers in production.
- Resource exhaustion from an unbounded query, connection-pool leak or thundering herd after failover.
- Authorization failure: overly broad DBA roles, stolen credentials, or SQL injection through the query language.
- Backup that cannot be restored (missing WAL for PITR, untested dumps, encryption-key loss).
- Ransomware or destructive DROP/TRUNCATE against the live store.
- Which of these failure modes and hazards hold for the sense of database management system this model covers, and on what evidence? provenance
Regional variation
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Query language and operations practice split by dialect: Microsoft T-SQL, Oracle PL/SQL, PostgreSQL/SQL-standard, MySQL/MariaDB.
- Acronyms differ by language: English DBMS, French SGBD, German DBMS/DBVS; older English also used 'data base'.
- European public-sector procurement often prefers PostgreSQL; US commercial practice is dominated by hyperscaler managed SQL and proprietary engines.
- China's Xinchuang localization drives domestic engines (Dameng, Kingbase, OceanBase, GaussDB/openGauss) in government and state-owned systems.
- Mainframe hierarchical and relational engines (IMS, Db2 for z/OS) remain material in banking and government in the US, Japan and parts of Europe.
- Which of these regional variation hold for the sense of database management system this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Database - The database is the stored collection of data and catalog; the DBMS is the software that defines, protects and serves it.
- File system - A file system stores byte streams and directories; a DBMS adds a typed schema, a query language, multi-row atomicity, and crash recovery across related records.
- Cache (for example Redis used only as a cache) - A cache is allowed to drop or rebuild data; a DBMS is the system of record and is judged on durability and recoverability.
- Search engine / inverted index - A search index is optimized for ranked retrieval and eventual consistency; a DBMS is optimized for exact query, constraints and (usually) transactional update.
- Spreadsheet - A spreadsheet is an interactive grid for a single user or small group; a DBMS is a concurrent, authorized service with a declared schema and recovery.
- Message broker / log - A broker moves or records event streams; a DBMS answers ad hoc queries over current (and often historical) state under integrity constraints.
- Which of these neighbouring kinds and how to tell them apart hold for the sense of database management system this model covers, and on what evidence? provenance
Sources
- A Relational Model of Data for Large Shared Data Banks - The relational data model that still defines the dominant DBMS kind, and the split between a stored database and the software that manages it.
- ISO/IEC 9075 Information technology - Database languages - SQL - The international standard language and conformance surface for relational DBMS products; issued by ISO/IEC JTC 1/SC 32.
- Principles of Transaction-Oriented Database Recovery - ACID transaction properties, write-ahead logging, and crash-recovery duties that distinguish a DBMS from a file or cache.
- Database System Concepts - Standard architecture (storage engine, catalog, query planner, concurrency control, recovery) and the practical kinds used in teaching and industry.
- Wikidata item Q176165 (database management system) - The public identifier for the class, as distinct from Q8513 (database), the stored collection.
What the second pass must settle
- Does this registry entry primarily denote DBMS software products, configured running systems, or both, and how should that interpretation align with its PHY / PHY.OBJ placement?
- Where should the registry draw boundaries between a DBMS and specialised systems such as persistent caches, search engines and stream-processing stores?
- Which shared vocabulary can express transaction, consistency and durability guarantees across DBMS families without implying equivalence between differently scoped guarantees?
- How should managed-service control restrictions and provider-only operational evidence be represented when the underlying DBMS cannot be inspected directly?
- What evidence freshness and recovery-test coverage are sufficient for an agent to treat operational or recoverability claims as actionable?