A data dictionary is your schema written out as a document instead of drawn as a diagram. Schemity exports one from the export menu in three formats: HTML to print or share, Markdown to commit next to your code, and Excel to filter and sort. Every format lists each entity with its columns, types, keys, nullability, defaults, and descriptions, then its constraints and indexes, then every relationship with its cardinality and ON DELETE / ON UPDATE rules, then the notes from your legends. It ends with a coverage report of which entities and fields still have no description. It is written for someone who will never open Schemity: an auditor, a compliance reviewer, or the engineer who inherits the database.
How do I export a data dictionary?
Open the export menu and choose Data dictionary (HTML), Data dictionary (Markdown), or Data dictionary (Excel), then pick where to save the file. The suggested file name ends in -dictionary, for example billing-dictionary.html.
The export covers the view you are in. From the main diagram it documents the whole schema. From inside a context view it documents only that view’s entities, the document says which context view it covers, and the context view’s own description comes first in the notes. So you can hand the payments team a dictionary of the payments context without the rest of the schema.
A diagram with no entities exports nothing.
What does the data dictionary contain?
All three formats are built from the same document, so they always agree about the schema:
- Header - diagram name, database type, scope (whole diagram or one context view), generation time, and entity, field, and relationship counts.
- Entities - sorted by name. Each one lists its description, primary key, and a field table: name, type, key (
PK,FK, or both), nullable, unique, default, and description. - Constraints - unique constraints, check constraints, and indexes, together as one “rules on this table” block per entity.
- Relationships - each foreign key as
table(field)totable(field), with cardinality (1:1, 1:N, N:N) and its ON DELETE and ON UPDATE actions. - Notes - the name and description of every legend, and of the context view when you export from one. This is where the domain reasoning goes that the schema itself cannot hold.
- Documentation coverage - described below.
Types are printed as you designed them, not converted to generic names: NVARCHAR(50) stays NVARCHAR(50) and NUMERIC(10,2) keeps its precision, because the reader wants the type their DBA will see. PostgreSQL enum columns show their allowed values inline, as ENUM(draft, sent, paid).
Are database views included?
Yes. Database views and materialized views appear in the dictionary, labelled as views. The SQL, DBML, and Mermaid exports leave views out because those formats describe tables you can create. A dictionary is read by someone checking what exists, and a document that quietly skipped half the schema would be worse than none.
What is the documentation coverage report?
The dictionary closes by counting how many entities and fields have a description, for example “38 of 42 entities and 211 of 356 fields carry a description”, and then lists the ones that do not. It reports the numbers and names; it does not judge whether they are a problem.
The list only names what you can fix. A view’s own description is stored in the diagram, so an undocumented view is listed. Its columns come from the database and cannot be edited in Schemity, so they are counted but never listed as missing.
Descriptions live in the diagram and never reach the database, so documenting a column produces no migration. Column comments already in a PostgreSQL or MySQL database are imported as descriptions when you reverse-engineer it, so a well-commented schema starts with good coverage.
What is in the Excel workbook?
The Excel export is a six-sheet workbook: Overview, Entities, Fields, Constraints, Relationships, and Notes. Every sheet is always there, even when empty, so a spreadsheet or script built on top of one export still works on the next. Counts are written as numbers rather than text, so they sum and sort.
Which format should I use?
- HTML - one self-contained file for a reviewer to open, read, or print. Each entity has its own anchor you can link to.
- Markdown - commit it next to the JSON diagram so schema documentation changes show up as readable diffs in the pull request.
- Excel - for audits and compliance checks, where someone filters every nullable column or every ON DELETE CASCADE.
Is the data dictionary available in Schemity Lite?
No. The data dictionary is a desktop app feature. It is not available in the browser version or after a trial expires.
Next
Raise your coverage by adding descriptions to entities and legends - see Legends & Annotations.