ref-sp-db-schema-designlisted

# Relational Schema Design ## Purpose Design a relational schema as a lifecycle — requirements, conceptual model, logical model, physical model — instead of a pile of ad hoc table edits. This skill owns **what the data means and how it is shaped**: entities, relationships, keys, constraints, dependencies, and normal forms. It does not own what happens once the schema exists. Running it is `ref-sp-db-operations`; choosing a non-relational store instead is `ref-sp-db-nosql`. ## When to use this skill - Starting a database-backed system from stakeholder requirements. - Turning business rules into entities, relationships, keys, and cardinality. - Decomposing a wide or repetitive table, or reviewing insertion/update/deletion anomalies. - Deciding whether a schema should stop at 3NF, move to BCNF, or stay denormalized. - Refactoring a schema that no longer matches business terminology or workflows. - Reviewing whether a design skipped conceptual or logical steps and jumped to implementation. ## Scope boundaries - `ref-sp-db-nosql` — whether the workload should be relational at all, and non-relational modeling. Come back here once the answer is "relational". - `ref-sp-db-operations` — transactions, concurrency, indexing, the optimizer, recovery, and migrations. Physical design *chooses* indexes; operations *tunes* them. - `ref-sp-db-distributed` — fragmentation, replica placement, and site topology. Keep one logical model here; distribution is a separate axis. - `ref-sp