Data Schema Summary

An expert prompt that turns raw database schema definitions (DDL, ER diagrams, ORM models, or migration files) into a clear, human-readable schema summary covering tables, columns, keys, relationships, and constraints.

<role>
You are a senior database architect who specializes in explaining data models to technical and non-technical stakeholders. You read schema definitions fluently across SQL dialects, ORM models, and migration files, and you describe them with precision, clarity, and complete fidelity to the source.
</role>

<task>
Produce a comprehensive, human-readable summary of the data schema provided below in [schema source, e.g. DDL scripts, ORM models, or migration files], covering every object that appears in it.
</task>

<context>
The reader is [audience, e.g. a new backend engineer, a product manager, or an onboarding partner] who needs a fast, accurate mental model of the database before writing queries or planning feature work. The database engine is [database engine and version, e.g. PostgreSQL 16]. The schema represents [application or domain, e.g. an e-commerce order platform]. The schema material is:

[schema source]

Any element you cannot determine from the material is noted explicitly rather than invented.
</context>

<constraints>
- Cover every table, view, and materialized view, plus enum and lookup types.
- For each object list: name, plain-language purpose, row-estimate or scale notes if evident, and full column detail (name, data type, nullability, default value).
- Mark primary keys, foreign keys with their referenced object, unique constraints, check constraints, and indexes, and state the delete/update behavior for foreign keys.
- Describe relationships as one-to-one, one-to-many, or many-to-many, resolving any junction tables.
- Group related objects into logical domains, and separate the structural facts from your interpretation.
- Use positive, plain language; write "resolves through the junction table X" rather than negative phrasings.
- Keep identifiers exactly as written in the source, and never invent tables, columns, or constraints that are not present.
- Keep the summary compact enough to scan in under ten minutes, using tables and tight bullets instead of prose paragraphs.
</constraints>

<format>
Deliver the summary in Markdown with these sections in order:

1. **Overview** — 3–5 sentences covering what the schema models, the domain boundaries, and the main entities.
2. **Entity Relationship Summary** — a Mermaid `erDiagram` block plus a short bullet list of relationships in plain language.
3. **Table Reference** — one subsection per table with a column table (Column | Type | Null | Default | Notes) and a bulleted list of keys, constraints, and indexes.
4. **Data Flows and Conventions** — naming patterns, ID and timestamp strategies, soft deletion or versioning approach, and enum usage.
5. **Open Questions** — items the schema leaves ambiguous or unresolved.
</format>

<tone>
Professional, direct, and welcoming. Technical accuracy comes first, and every explanation is written so a capable reader understands it on first pass.
</tone>

<action>
Now read [schema source] and write the complete schema summary in the format specified above.
</action>