design-data-model

Start from verified persistence scenarios describing pre-state, business events, decisions, and results. Extract which facts must be recorded and who needs them, then choose a modeling method and place facts into logical tables, finishing with BDD scenarios showing Before/After table states.

Use an event log as the source of truth only when multiple meaningful business events exist and their order, history, cancellation, or correction must be explained later. If history is unused, current state suffices; if past values of settings are queried, use valid-time history instead.

Two inputs are mandatory: the corresponding business knowledge document and inspected persistence scenarios with confidence levels (confirmed, assumed, unknown). Without them the design does not start; tables, APIs, screens, or existing DDL alone are not accepted as substitutes.

Avoid NULL when a missing value hides distinct business meanings like unset, not applicable, or cancelled. Express those differences as named states, relationships, or event types. NULL is acceptable only when the missing meaning is single, unambiguous, and never drives business decisions.

No. Physical concerns such as RDBMS product choice, DDL, indexes, partitioning, isolation levels, schema migration, and performance measurement are explicitly out of scope. The skill finalizes logical tables, columns, business keys, relationships, and constraints only.

If required inputs are missing entirely, the process stops and reports what is needed. If only some elements are uncertain, it proceeds by marking them as hypotheses with their rationale in the document and listing open questions in an undecided section.