designing-database-schemas

name	designing-database-schemas
description	Process use when you need to work with database schema design. This skill provides schema design and migrations with comprehensive guidance and automation. Trigger with phrases like "design schema", "create migration", or "model database".
allowed-tools	Read, Write, Edit, Grep, Glob, Bash(psql:*), Bash(mysql:*), Bash(mongosh:*)
version	1.0.0
author	Jeremy Longshore <[e-mail]>
license	MIT
compatible-with	claude-code, codex, openclaw
tags	["database","migration","designing-database"]

Database Schema Designer

Overview

Design normalized relational database schemas from business requirements, entity-relationship diagrams, or existing application code. This skill produces PostgreSQL or MySQL DDL with proper data types, constraints, indexes, and relationships following normalization principles (3NF by default) with strategic denormalization where performance requires it.

Prerequisites

• Business domain requirements or existing application models/classes to derive schema from
• psql or mysql CLI for testing schema DDL
• Target database engine and version (determines available data types and features)
• Expected data volumes and query patterns for sizing and index decisions
• Multi-tenancy requirements (shared schema, schema-per-tenant, or database-per-tenant)

Instructions

1. Identify all entities (nouns) from the business requirements. Each entity becomes a table. List every attribute (property) of each entity and classify as required or optional.

2. Define primary keys for each table. Prefer BIGSERIAL (PostgreSQL) or BIGINT AUTO_INCREMENT (MySQL) for surrogate keys. Use UUID (via gen_random_uuid()) for distributed systems or when IDs are exposed in URLs. Natural keys are acceptable when truly immutable and unique (ISO country codes, IATA airport codes).

3. Normalize the schema to Third Normal Form (3NF):

   • 1NF: Eliminate repeating groups. Each column holds a single atomic value. No arrays in columns (unless using PostgreSQL array types intentionally).
   • 2NF: Remove partial dependencies. Every non-key column depends on the entire primary key.
   • 3NF: Remove transitive dependencies. Non-key columns depend only on the primary key, not on other non-key columns. Extract lookup tables for values that change independently.

4. Define relationships between tables:

   • One-to-many: Add a foreign key column on the "many" side referencing the "one" side. Example: orders.customer_id REFERENCES customers(id).
   • Many-to-many: Create a junction table with two foreign keys. Example: product_categories(product_id, category_id) with a composite primary key.
   • One-to-one: Add a foreign key with a UNIQUE constraint, or merge into a single table if entities are always accessed together.