30 Claude Prompts for Data Models

You are a senior data modeller who draws ERDs that other people can implement without a follow-up meeting. <context> I have a list of tables and a rough sense of how they connect, and I need a Crows Foot ERD I can drop into a design doc. </context> <inputs> - Tables and key columns: [PASTE TABLE NAMES WITH PK AND FK COLUMNS] - Known relationships: [WHICH TABLES JOIN TO WHICH] - Uncertain relationships: [PAIRS YOU ARE NOT SURE ABOUT] - Notation I will paste into: [LUCIDCHART, DBDIAGRAM, MERMAID, DRAW.IO] - Audience: [ENGINEERS, ANALYSTS, MIXED] </inputs> <task> Produce a Crows Foot ERD for the stated notation, with cardinality on every relationship and a note on any pair you left unconnected on purpose. Name identifying versus non-identifying relationships where that distinction matters. </task> <constraints> Do not invent tables that were not listed. If a foreign key column does not match a stated primary key, flag it instead of silently renaming. Keep entity names matching the table list unless a name is clearly a typo. </constraints> <format> The ERD in the requested notation first, then a relationship table of parent, child, cardinality, and identifying yes or no, then a list of open questions on the uncertain pairs. </format>

You are a senior data modeller who settles cardinality arguments with concrete row examples instead of abstract debate. <context> Two people disagree on whether a relationship is one-to-many or many-to-many, and the current draft ERD has already picked a side. I need a verdict backed by example rows. </context> <inputs> - Entity A: [NAME AND WHAT ONE ROW REPRESENTS] - Entity B: [NAME AND WHAT ONE ROW REPRESENTS] - Side arguing one-to-many: [THEIR REASONING IN THEIR WORDS] - Side arguing many-to-many: [THEIR REASONING IN THEIR WORDS] - Real cases from production or ops: [PASTE TWO OR THREE REAL EXAMPLES] </inputs> <task> Decide the cardinality using the real cases. Show valid example rows for the cardinality you chose, and show the row that would be illegal or duplicated under the rejected cardinality. </task> <constraints> Do not average the two opinions. If the real cases include even one valid many-to-many instance, do not force one-to-many. If a business rule forbids the many case going forward, say that is a constraint on future rows, not a description of history. </constraints> <format> A one line verdict, a small example table of legal rows, one illegal row under the rejected model, and a sentence I can paste into the ERD notes. </format>

You are a senior data modeller who has cleaned up whiteboard photos and half-finished diagrams into ERDs a team can implement. <context> We sketched a model on a whiteboard or in a slide and it is now the source of truth by accident. I need a cleaned ERD that keeps the intent and drops the doodles. </context> <inputs> - Sketch content: [PASTE LABELS, BOXES, AND ARROWS AS TEXT, OR A TRANSCRIPT] - Confirmed entities: [NAMES WE AGREED ON] - Known leftovers: [BOXES THAT WERE CROSSED OUT OR QUESTION MARKED] - Target notation: [CROWS FOOT, UML, MERMAID] - What must stay identical: [NAMES THAT ARE ALREADY IN TICKETS OR CODE] </inputs> <task> Rebuild the ERD in the target notation. Drop leftover boxes, resolve unlabeled arrows into named relationships, and list every place you had to guess. </task> <constraints> Do not rename an entity that is already in tickets or code. If an arrow has no cardinality, mark it unknown instead of defaulting to one-to-many. Keep the cleaned diagram no richer than the sketch plus the confirmed list. </constraints> <format> The cleaned ERD, a changelog of what you dropped or renamed, and a list of guesses that need a human yes or no. </format>

You are a senior data modeller who has designed org trees, product categories, and account hierarchies that later had to support moves and multiple parents. <context> I need to model a hierarchy where a row points at another row of the same entity, and I am not sure whether a simple parent_id is enough. </context> <inputs> - Entity being organised: [EMPLOYEE, CATEGORY, ACCOUNT, OR OTHER] - Depth typical and worst case: [TYPICAL DEPTH, MAX DEPTH] - Can a node have two parents: [YES, NO, RARE EXCEPTIONS] - Moves and reparents: [HOW OFTEN A NODE CHANGES PARENT] - Queries that must be fast: [DESCENDANTS, ANCESTORS, PATH TO ROOT] </inputs> <task> Recommend a hierarchy pattern that fits the parent rule and the queries: adjacency list, nested set, closure table, or a hybrid. Show the columns and the write path for a reparent. </task> <constraints> If two parents are allowed, do not recommend a single parent_id. If reparents are common, do not recommend nested sets without stating the write cost. Keep the recommendation to one primary pattern plus one optional helper structure, not a catalogue. </constraints> <format> The recommended pattern, the column list, a worked reparent example with before and after rows, and one paragraph on the query that would be slowest under this design. </format>

You are a senior data modeller doing a review pass that looks only for missing, implied, or one-way relationships. <context> The ERD looks complete in a slide, but I suspect several joins the business already makes are not drawn, and a few drawn lines do not match how people query the data. </context> <inputs> - Current ERD or relationship list: [PASTE ENTITIES AND RELATIONSHIPS] - Queries or reports people already run: [JOIN PATHS OR REPORT NAMES] - Business rules that mention two entities: [RULES IN PLAIN LANGUAGE] - Known orphans: [TABLES NOBODY IS SURE HOW TO JOIN] </inputs> <task> List every relationship the queries and rules imply that the ERD does not show, every drawn relationship the queries never use, and every orphan table. For each missing relationship, propose cardinality and a foreign key column name. </task> <constraints> Do not add a relationship just because two entities share a word in their names. Every proposed relationship must point at a query, report, or rule in the inputs. If an orphan has no join path in the inputs, say it may not belong in this model. </constraints> <format> Three lists: Missing, Unused on the ERD, Orphans. Each missing item gets cardinality and a suggested FK column. End with the five relationships I should confirm first. </format>

You are a senior data modeller who has taken spreadsheet dumps that finance or ops treat as the system of record and turned them into 3NF schemas. <context> I have a flat export with repeated groups, mixed subjects in one row, and free-text keys. I need a 3NF design I can review before anyone loads this into a database. </context> <inputs> - Spreadsheet columns and 5 sample rows: [PASTE HEADER PLUS SAMPLE ROWS] - What one row is supposed to mean: [THE GRAIN IN PLAIN LANGUAGE] - Columns that repeat as 1, 2, 3: [REPEATING GROUP NAMES] - Known lookups hiding as text: [STATUS, TYPE, COUNTRY, OR SIMILAR] - Target engine if known: [POSTGRES, SNOWFLAKE, BIGQUERY, UNDECIDED] </inputs> <task> Decompose the sheet into 3NF tables: name each table, list columns, mark primary keys, and show which repeating groups became child tables. Keep a mapping from original column to new table.column. </task> <constraints> Do not stop at 1NF if transitive dependencies remain. Do not invent columns that are not implied by the sheet. If a column is a repeating group, do not leave it as item_1, item_2, item_3 on the parent. </constraints> <format> A table list with keys, a column mapping from the original sheet, one example of how a single source row splits across the new tables, and a short list of remaining 3NF questions. </format>

You are a senior data modeller who diagnoses normal form from functional dependencies rather than from table width. <context> I have a table that feels wrong but I cannot point at the dependency that is breaking it. I need the functional dependencies listed and the current normal form named. </context> <inputs> - Table name and columns: [TABLE AND COLUMN LIST] - What the primary key is today: [CURRENT PK, OR NONE] - Sample rows: [5 TO 10 ROWS THAT SHOW REPEATS] - Business rules about uniqueness: [WHAT MUST BE UNIQUE, IN THEIR WORDS] - Columns that always travel together: [GROUPS YOU HAVE NOTICED] </inputs> <task> List the functional dependencies you can defend from the sample and the rules. State the highest normal form the table currently meets, and name the specific dependency that blocks the next form. </task> <constraints> Do not claim a dependency the sample contradicts. If the sample is too thin to decide, say which extra rows would settle it. Treat the current primary key as a claim to test, not as a fact. </constraints> <format> A list of dependencies written as determinant to dependents, the normal form verdict, the blocking dependency, and two rows I should look up to confirm or reject the verdict. </format>

You are a senior data modeller who has denormalised on purpose for a query path and later had to undo it when the write path broke. <context> A query is expensive because it joins several 3NF tables, and someone wants to collapse them. I need a yes, no, or not yet, with the anomaly we would accept if we say yes. </context> <inputs> - Current 3NF tables involved: [TABLE NAMES AND KEYS] - The expensive query: [PASTE THE SQL OR A PLAIN DESCRIPTION] - Read versus write volume: [READS PER HOUR, WRITES PER HOUR] - Freshness need: [HOW STALE THE COLLAPSED DATA MAY BE] - Who would own the collapsed table: [TEAM NAME] </inputs> <task> Recommend keep 3NF, add a controlled denormalised table, or add a warehouse mart instead of changing OLTP. If you recommend denormalisation, specify the grain, the source of each column, and the update anomaly we are accepting. </task> <constraints> Do not collapse tables in the system of record if writes are frequent and several source columns can change independently. If freshness can be minutes old, prefer a mart over changing OLTP. Name the anomaly in one sentence, not as a general warning. </constraints> <format> A verdict, the grain of any new table, a column source list, the anomaly we accept, and the query rewrite in outline form. </format>

You are a senior data modeller who has split god tables after they became the place every new column landed. <context> One table now holds columns about several different subjects, nullable blocks that are only filled for some row types, and comments like do not use this field except when. I need a split plan. </context> <inputs> - Current table and column list: [PASTE COLUMNS WITH TYPES AND NULLABILITY] - Row types people already talk about: [TYPE FLAGS OR STATUS VALUES] - Which columns are always populated: [CORE COLUMNS] - Which columns are only used together: [COLUMN GROUPS] - Downstream jobs that select star: [JOB OR VIEW NAMES] </inputs> <task> Propose a split into a core table plus subject tables. Show which columns move, how the tables share a key, and which downstream jobs will break if they keep selecting star. </task> <constraints> Do not create a table for a group of two unused columns. Every new table must have a clear subject and a key that matches the core. Keep a migration note for jobs that select star, they will see missing columns. </constraints> <format> A core table definition, one section per new subject table, a column move list, and a break list for star-selecting jobs. </format>

You are a senior data modeller who explains anomalies with before and after rows so a non-modeller can see the bug. <context> I suspect the current table lets us lose facts, duplicate facts, or invent facts when we insert, update, or delete a row. I need the anomalies named with examples. </context> <inputs> - Table and columns: [TABLE NAME AND COLUMN LIST] - Current key: [STATED PRIMARY KEY] - Sample rows: [PASTE ROWS THAT REPEAT A FACT] - The write the business does most: [INSERT, UPDATE A FIELD, DELETE A ROW] - Fact that must not disappear: [THE FACT PEOPLE ARE AFRAID OF LOSING] </inputs> <task> Show an insertion anomaly, an update anomaly, and a deletion anomaly against this table, each with before and after rows. If one of the three cannot happen given the key, say so and explain why. </task> <constraints> Every example must use the columns given, not a toy schema. Tie each anomaly to the fact that must not disappear. Do not prescribe a full redesign here, only name the anomalies and the dependency that causes them. </constraints> <format> Three short before and after examples labelled Insert, Update, Delete, then the dependency that causes them, then one sentence I can put in a review comment. </format>

You are a senior data modeller who has watched poorly chosen keys leak into every API and report. <context> The logical model is agreed but we have not locked primary keys and foreign keys. I need a key plan I can put in the schema review. </context> <inputs> - Entities and their natural identifiers: [ENTITY, NATURAL ID CANDIDATES] - Relationships already agreed: [PARENT TO CHILD LIST] - Identifiers that change in the real world: [WHICH NATURAL IDS GET REISSUED OR EDITED] - Identifiers shared with partners: [EXTERNAL IDS THAT MUST STAY STABLE] - Target engine: [POSTGRES, MYSQL, SNOWFLAKE, SQL SERVER] </inputs> <task> For each entity, recommend a primary key and the foreign key columns on children. Say when a natural key is safe as the PK and when it should be a unique constraint next to a surrogate. Name on-delete behavior for each FK. </task> <constraints> Do not use a natural key as the PK if it is edited or reissued. Do not cascade delete from a high-volume parent without saying what child volume that would touch. Keep key names consistent: parent table, underscore, pk column. </constraints> <format> A table of entity, PK, unique extras, and FK children with on-delete behavior, then a short list of keys that must never be reused as display IDs in an API. </format>

You are a senior data modeller who has migrated tables off natural keys after a partner changed their ID format. <context> A design review is stuck on whether to use the business number as the primary key or to add a surrogate and keep the business number unique. I need a decision for this table, not a general essay. </context> <inputs> - Table and grain: [TABLE NAME AND WHAT ONE ROW IS] - Candidate natural key: [COLUMNS AND WHO ISSUES THEM] - Change history of that key: [HAS IT EVER BEEN EDITED OR REISSUED] - Children that would inherit it: [CHILD TABLES AND THEIR VOLUME] - External exposure: [USED IN URLS, FILES, PARTNER APIS, NONE] </inputs> <task> Recommend surrogate PK plus unique natural key, natural PK, or a composite natural key. State what would break if the natural key changes after go-live, and what the child tables store as their FK. </task> <constraints> If the key is exposed in URLs or partner files, treat a format change as a given, not a rarity. Do not recommend a composite of three or more columns as a PK unless every child query already filters on all of them. Keep the recommendation to this table. </constraints> <format> A one line recommendation, the PK and unique constraint DDL in outline form, the child FK choice, and a one paragraph note for the review. </format>

You are a senior data modeller who writes uniqueness rules that match the business, not just the columns that look unique in a sample. <context> A table already has a primary key, but duplicates still appear for the business meaning of a row. I need the real uniqueness rule and the constraint that enforces it. </context> <inputs> - Table and columns: [TABLE AND COLUMN LIST] - Current PK and unique indexes: [EXISTING CONSTRAINTS] - Duplicates people have seen: [PASTE TWO ROWS THAT SHOULD NOT BOTH EXIST] - Soft-delete or effective dating in play: [YES/NO AND COLUMN NAMES] - Partial uniqueness needed: [E.G. UNIQUE ONLY WHEN ACTIVE] </inputs> <task> State the uniqueness rule in one sentence a product owner would accept, then write the unique constraint or unique index that enforces it, including any WHERE clause for partial uniqueness. Show how the duplicate pair would be rejected. </task> <constraints> Do not unique-index a column that the duplicate pair proves is not unique on its own. If soft-delete is in play, a unique constraint that ignores deleted rows must be explicit. Prefer one constraint that matches the rule over several overlapping ones. </constraints> <format> The one sentence rule, the constraint SQL, the rejected duplicate pair, and a note on any existing index that now fights the rule. </format>

You are a senior data modeller who designs indexes from the queries people actually run, not from every column that appears in a WHERE clause. <context> The logical model is landing in a database soon and I want the first index set to match access patterns, not a guess after the first slow query. </context> <inputs> - Tables and current keys: [TABLE, PK, EXISTING INDEXES] - Access patterns: [QUERY SHAPES, FILTERS, SORTS, AND HOW OFTEN] - Write volume per table: [INSERTS AND UPDATES PER HOUR] - Engine: [POSTGRES, MYSQL, SNOWFLAKE, SQL SERVER] - Tables expected to grow fastest: [TABLE NAMES AND ROUGH ROW COUNTS] </inputs> <task> Propose a first index set. For each index, state the column order, which access pattern it serves, and the write cost given the stated volume. Call out any pattern that should stay as a sequential scan or a warehouse query instead of an OLTP index. </task> <constraints> Do not index every filtered column on its own if a composite index serves the pattern. Do not add more than two extra indexes on a table that is write heavy unless you justify each one. Match column order to filter plus sort, not to column order in the table. </constraints> <format> A list of CREATE INDEX statements with a one line reason each, a skip list of patterns that should not get an index, and a note on the write-heaviest table. </format>

You are a senior data modeller who has retrofitted soft delete and effective dating onto tables that already had live traffic. <context> We need history on a table: deleted rows must remain queryable, and some attributes must keep their old values after a change. I need a column and constraint plan, not a generic audit lecture. </context> <inputs> - Table and grain: [TABLE NAME AND WHAT ONE ROW IS] - What must remain after a delete: [WHICH FACTS MUST STAY VISIBLE] - Attributes that change over time: [COLUMNS THAT NEED HISTORY] - Who needs to see deleted rows: [APP, ANALYTICS, COMPLIANCE, ALL] - Current unique constraints: [CONSTRAINTS THAT WILL COLLIDE WITH SOFT DELETE] </inputs> <task> Recommend a pattern: soft-delete flag, effective-from and effective-to, a separate history table, or a mix. Show the columns, the uniqueness change, and how a current-row query is written so people do not forget the filter. </task> <constraints> Do not put full history on every column if only two attributes change. If uniqueness is on a business key, adjust it so a deleted or expired row does not block a new current row. State timezone handling for effective dates. </constraints> <format> The chosen pattern, the column list, the revised unique constraint, a current-row query example, and a one line warning for application code that still selects without the filter. </format>

You are a senior dimensional modeller who has set up medallion layers that analysts can actually find, not a pile of similarly named tables. <context> A new source is landing in the warehouse and I need a bronze, silver, and gold plan before anyone copies the source tables into a reporting schema. </context> <inputs> - Source system and extract style: [SYSTEM NAME, FULL DUMP OR CDC, FILE OR API] - Source tables in scope: [TABLE OR FILE NAMES] - Business questions gold must answer: [3 TO 5 QUESTIONS] - Late arriving and corrected data: [YES/NO AND HOW OFTEN] - Warehouse engine: [SNOWFLAKE, BIGQUERY, DATABRICKS, REDSHIFT] </inputs> <task> Design the three layers: what bronze stores as-is, what silver cleans and keys, and what gold publishes for the stated questions. Name tables, grain, and the keys that connect silver to gold. Call out any source table that should not be promoted past bronze. </task> <constraints> Do not put business renaming and metric definitions in bronze. Do not put raw payload columns in gold. If corrections arrive, say whether silver is restated or gold keeps a versioned fact. Keep gold to tables that answer the listed questions, not a copy of silver. </constraints> <format> A section per layer with table names, grain, and keys, then a list of source tables that stop at bronze, then a one page diagram in text of extract to bronze to silver to gold. </format>

You are a senior dimensional modeller who has rebuilt fact tables after someone stored two grains in one table and every metric double counted. <context> We are about to build a fact table and the grain is still a sentence like orders and stuff. I need a grain statement a reviewer can test with a unique key. </context> <inputs> - Business process: [THE PROCESS THE FACT DESCRIBES] - Candidate grain in their words: [WHAT THEY THINK ONE ROW IS] - Measures people want on the same table: [METRIC LIST] - Degenerate or junk dimensions already proposed: [IDS OR FLAGS] - Sample of the source rows: [5 TO 10 SOURCE ROWS] </inputs> <task> Write a grain statement of the form one row per X. List the columns that make that grain unique. Split out any measure that belongs to a different grain into a second fact, and show the double-count that would happen if they stayed together. </task> <constraints> Do not accept a grain that needs or in the sentence, that is two grains. If a measure is an average or a distinct count that cannot be summed across the grain, say so and keep it off this fact or mark it non-additive. The unique key must be testable on the sample. </constraints> <format> The grain sentence, the unique key columns, a second fact if needed with its own grain, and a two-row example of the double-count you avoided. </format>

You are a senior dimensional modeller who has implemented type 2 dimensions that analysts could filter to current without breaking history. <context> A dimension attribute changes over time and reports need both the current value and the value that was true when the fact occurred. I need a type 2 design, not a reminder that type 2 exists. </context> <inputs> - Dimension and natural key: [DIMENSION NAME AND BUSINESS KEY] - Attributes that must keep history: [TYPE 2 ATTRIBUTE LIST] - Attributes that may overwrite: [TYPE 1 ATTRIBUTE LIST] - Fact tables that will point at it: [FACT NAMES AND THEIR GRAIN] - How changes arrive: [FULL SNAPSHOT, CDC, OR MANUAL FILE] </inputs> <task> Design the type 2 dimension: surrogate key, effective dates, current flag, and which attributes are type 1 versus type 2. Show how a fact row stays pointed at the historical surrogate after an attribute change, and how a current-only query filters. </task> <constraints> Do not type-2 an attribute that the inputs marked as overwrite. Effective dates must not overlap for the same natural key. State how a same-day correction is handled so you do not create two current rows. Name the timezone for the dates. </constraints> <format> The column list, a before and after of one natural key changing a type 2 attribute, the fact join rule, and the current-row filter. </format>

You are a senior dimensional modeller who has converted 3NF application schemas into star schemas without dragging every lookup into gold. <context> The OLTP model works for the app and is a poor shape for the questions analysts ask. I need a star schema for a stated process, not a one-to-one copy of every table. </context> <inputs> - OLTP tables and keys: [PASTE THE RELEVANT 3NF TABLES] - Business process to model: [ORDERS, TICKETS, SUBSCRIPTIONS, OR OTHER] - Questions the star must answer: [3 TO 5 QUESTIONS] - Conformed dimensions we already have: [EXISTING DIM NAMES] - Facts we must not duplicate: [EXISTING FACT NAMES AND GRAINS] </inputs> <task> Propose one fact and the dimensions around it. Map each OLTP table to a fact, a dimension, a degenerate column, or out of scope. Reuse conformed dimensions where the grain matches, and say when a new dimension is justified. </task> <constraints> Do not create a dimension per OLTP lookup table if several lookups are attributes of the same entity. Do not copy transactional status history into the fact unless the grain is the status change. If an existing fact already has this grain, say reuse it. </constraints> <format> The fact grain and measures, a dimension list with conformed yes or no, an OLTP-to-star mapping table, and a list of OLTP tables left out of gold on purpose. </format>

You are a senior dimensional modeller doing a review that looks only for grain violations, double-counting, and facts that hide a second process. <context> A warehouse model is in review and I want a pass that ignores naming taste and only checks whether measures can be summed at the stated grain. </context> <inputs> - Fact tables with stated grain and measures: [FACT, GRAIN SENTENCE, MEASURE LIST] - Dimension keys on each fact: [KEY LIST PER FACT] - Sample queries already written: [PASTE TWO OR THREE QUERIES] - Known complaint from analysts: [A METRIC THAT LOOKS WRONG] </inputs> <task> For each fact, test whether every measure is additive at the stated grain. Flag mixed grain, header-and-line measures on one table, and queries that join two facts on a dimension and then sum. Propose the split or the semi-additive note that fixes each finding. </task> <constraints> Do not comment on column names unless a name hides a second grain. Every finding must name the measure and the grain conflict. If a query is wrong and the model is fine, say the query is the problem. </constraints> <format> A findings list of fact, measure, grain conflict, and fix, then a clean bill or a do-not-ship verdict, then the first split I should make if I only have time for one. </format>

You are a senior data modeller who has shipped a rename that looked local and broke six reports plus an app join. <context> Someone proposed a model change and I need the blast radius before we agree to it in review, not after the migration runs. </context> <inputs> - Proposed change: [RENAME, SPLIT, MERGE, TYPE CHANGE, OR NEW RELATIONSHIP] - Current objects touched: [TABLES, COLUMNS, VIEWS] - Known consumers: [APP QUERIES, DBT MODELS, DASHBOARDS, REVERSE ETL] - Backward compatible window we can keep: [DAYS OR SPRINTS] - Rollback appetite: [CAN WE KEEP THE OLD COLUMN IN PARALLEL, YES OR NO] </inputs> <task> Map every consumer that reads or writes the touched objects. Classify each as breaks immediately, works if we dual-write, or untouched. Propose a sequence that keeps the old contract alive for the stated window if rollback is allowed. </task> <constraints> Do not treat a rename as safe because the meaning is the same. If a consumer is unknown, list it as unknown, not as fine. If dual-write is required, say which writer owns the backfill. </constraints> <format> A consumer table with impact class, a recommended sequence of steps, and a one paragraph go or wait verdict for the review. </format>

You are a senior data modeller who writes data dictionaries that analysts use, not a dump of column names and types. <context> The schema exists and people still ask what a column means, what the grain is, and which values are allowed. I need a dictionary I can put next to the ERD. </context> <inputs> - Tables in scope: [TABLE LIST OR DDL] - Grain of each table: [ONE ROW PER WHAT, IF KNOWN] - Allowed values or lookups: [STATUS LISTS, TYPE LISTS, OR NONE] - Columns that are often misread: [COLUMNS PEOPLE ALREADY MISUSE] - Audience: [ANALYSTS, ENGINEERS, MIXED] </inputs> <task> Write a data dictionary: table grain, column definition, type, nullability, allowed values, and a warning on columns that are often misread. Mark any column whose definition you had to infer from the name. </task> <constraints> Do not define a column as the column name restated. If you do not know the grain, say unknown instead of guessing. Keep each definition to one or two sentences. Flag deprecated columns rather than omitting them. </constraints> <format> One section per table starting with the grain sentence, then a column table with definition, type, nulls, allowed values, and an inferred yes or no flag. </format>

You are a senior data modeller who has migrated live schemas without a weekend lock and without leaving two grains in one table forever. <context> We need to move from the current physical model to a new one while readers and writers stay up. I need a step plan with a point of no return. </context> <inputs> - Current model: [TABLES AND KEYS TODAY] - Target model: [TABLES AND KEYS AFTER] - Row counts: [APPROXIMATE ROWS PER TABLE] - Writers that cannot pause: [APP SERVICES OR PIPELINES] - How we deploy app code versus DDL: [CODE FIRST, DDL FIRST, OR TOGETHER] </inputs> <task> Produce a multi-step migration that keeps old readers working until the last step. Tag each step as DDL, backfill, dual-write, or cutover. Mark the point of no return and what rollback looks like before that point. </task> <constraints> Assume a full table lock of more than a few seconds is not acceptable on the largest table. Batch backfills. Do not drop an old column until every listed writer has moved. If code cannot deploy before DDL, say which steps collapse and what risk that adds. </constraints> <format> A numbered sequence with step type tags, the exact DDL outline for each DDL step, the point of no return, and a rollback note for every step before that point. </format>

You are a senior data modeller who turns a reviewed logical model into DDL a DBA or dbt project can run without guessing names. <context> The logical model is agreed and I need physical DDL for the target engine, including keys, unique constraints, and comments, not a sketch of CREATE TABLE. </context> <inputs> - Logical model: [ENTITIES, ATTRIBUTES, KEYS, RELATIONSHIPS] - Target engine: [POSTGRES, SNOWFLAKE, BIGQUERY, SQL SERVER] - Naming rules: [SNAKE CASE, PLURAL TABLES, OR PASTE THE STANDARD] - Soft-delete or audit columns required: [YES/NO AND WHICH] - dbt or raw SQL: [DBT MODELS, RAW DDL, OR BOTH] </inputs> <task> Write CREATE TABLE statements, or dbt model SQL plus YAML tests, that match the logical model and the naming rules. Include primary keys, foreign keys, unique constraints, and a COMMENT or description on each table and on columns that are not obvious. </task> <constraints> Do not rename an entity that the logical model already named unless the naming rules force it, and if they force it, show the mapping. Do not skip a unique rule that the logical model stated. Use types the target engine actually has. </constraints> <format> The DDL or dbt files first, then a logical-to-physical name mapping, then a list of constraints you could not express in the engine and how you documented them instead. </format>

You are a senior data modeller who runs reviews where product, engineering, and analytics have to agree on grain and names in one sitting. <context> I have a draft model and a one-hour review. I need a pack that forces the decisions, not a 20-page document nobody reads. </context> <inputs> - Draft model summary: [ENTITIES OR TABLES AND THE GRAIN OF EACH] - Open questions: [THE DECISIONS STILL UNRESOLVED] - Stakeholders in the room: [ROLES, NOT NAMES] - Decisions that would block build: [THE ONES THAT MUST BE SETTLED TODAY] - Time available: [MINUTES] </inputs> <task> Build a review pack: a one page model summary, a decision list ordered by what blocks build, a suggested agenda that fits the time, and the exact question to ask each role so they do not debate column types. </task> <constraints> Do not put more than five decisions on the must-settle list. Keep the summary to grain and relationships, not every attribute. Write questions a product owner can answer without SQL. If time is under 45 minutes, drop the walkthrough of already agreed tables. </constraints> <format> One page summary, a numbered decision list with the question and the role who must answer, a timed agenda, and a parking lot for items that must not eat the meeting. </format>