Document Database Schemas Comprehensively

This skill provides expertise in documenting database schemas, specializing in clear, comprehensive, maintainable documentation for database structures across PostgreSQL, MySQL, SQL Server, Oracle, and NoSQL databases. Core documentation principles cover hierarchical structure (database to tables to columns to relationships), consistent naming and formatting conventions, both logical and physical data models, version history/changelogs, and cross-referenced links between related components. Every schema documentation includes a database overview (purpose, scope, key entities), an entity-relationship diagram, complete table definitions with column constraints, relationship documentation (foreign keys, joins, cardinality), index details for performance, and business rules/validation logic.

The standard table documentation format specifies purpose, relationships to other tables, a full column table (name, type, constraints, default, description), an indexes section explaining each index's purpose, and business rules (e.g. soft-delete convention, application-enforced format rules). Relationship documentation specifies each foreign key relationship's constraint behavior (RESTRICT vs CASCADE), cardinality, and the business rule it enforces (e.g. orders must belong to a valid user account, order items require at least one per order). Database view documentation covers purpose, base tables, the actual view definition SQL, a column table describing the aggregated/derived fields, and its intended usage (e.g. customer analytics and CRM reporting).

Data type and constraint guidance covers PostgreSQL-specific types (UUID for global identifiers, JSONB for structured document data, ARRAY for list data, ENUM for predefined value sets, TIMESTAMP WITH TIME ZONE for timezone-aware dates) with a concrete ENUM usage example defining an order_status type. NoSQL schema documentation covers a MongoDB collection example specifying purpose and a documented JSON structure with field types, required/optional status, and nested object shapes (e.g. a product catalog collection with variant and category information).

Use this skill when documenting a database schema - tables, relationships, views, or NoSQL collections - so other developers can understand the data model without reverse-engineering it from code. It is well suited to schemas complex enough to have meaningful relationships, views, or business rules worth documenting. It is not meant for trivial single-table schemas with no meaningful relationships or business logic to explain.

Input: the database schema (tables, columns, relationships, views, or NoSQL collections) to document.

Output: structured schema documentation covering table specs, relationships, views, data types, and NoSQL collection structures. Example table documentation format:

# Table: users

**Purpose**: Stores user account information and authentication data

| Column | Type | Constraints | Default | Description |
|--------|------|-------------|---------|-------------|
| id | BIGINT | PRIMARY KEY, AUTO_INCREMENT | - | Unique user identifier |
| email | VARCHAR(255) | UNIQUE, NOT NULL | - | User's email address (login) |

Documents schemas across PostgreSQL, MySQL, SQL Server, Oracle, and NoSQL databases (MongoDB); it does not connect to a specific documentation platform itself.

Database engineers and technical writers documenting schemas for team reference, and teams that need consistent, relationship-aware schema documentation rather than scattered comments in migration files.