Business Glossary

A business glossary answers a different question than a schema does: not “what columns exist” but “what do we mean by this word?” In Sqemo it is not a document you maintain next to the model — it is the Definitions view, derived from the logical model every time you open it.

Switch the view with the selector in the toolbar: Logical · Physical · Words · Definitions · Domains. It is part of the free core and works on local files with no account.

What becomes a term

A term is a logical attribute name. If ten entities have an attribute called “Customer Number”, the glossary has one row for it, listing all ten places.

Matching trims and collapses repeated spaces and ignores case, so “Order Date” and “order date” are the same term. Spacing itself is meaningful — “Order Date” and “OrderDate” are two different terms.
Attributes derived from a foreign key are skipped, because they repeat the parent’s term. If the foreign key has a role name, that name is the term instead.
Attributes with an empty logical name are skipped.

Each row shows the term, the physical name generated for it, its domain, data type, definition, every entity it is used in, and a status column for conflicts.

Definitions live on the model

Click the definition cell and type. Saving writes the definition to every logical attribute carrying that term, so a term has one definition per ERD — that is the whole point, and it is why the definition cannot drift from one entity to the next.

Nothing new is stored: the definition is the attribute’s own description field. It travels in your .erd.json, which means it is diffable in git, readable over MCP, and included in an entity or column definition export.

The scope of a definition is the ERD. The same word can mean different things in two different models, and here it is allowed to — the model is the context.

Conflicts get flagged, not hidden

Two badges appear in the status column:

Definition conflict — attributes sharing the term carry different non-empty definitions. The row shows the first non-empty one; editing the cell unifies them all (undo works as usual).
Domain conflict — the same term resolves to a different domain or data type depending on the entity. The glossary flags it; fix it by assigning the domain in the inspector.

These are the rows to clean up before anyone asks you for a glossary document — the conflicts are the drift, made visible.

Jump to where a term is used

The Used In cell lists every entity using the term, without truncation. Click one to switch to the logical view with that entity selected and focused on the canvas.

Export for an audit

Toolbar ▸ Export ▸ Definitions CSV writes one row per term:

logicalTerm,definition,physicalName,domain,dataType,entities,conflicts

entities and conflicts are ;-separated. A row with a non-empty conflicts value is a term that still needs a decision.

There is no term import. The glossary is a view over the model, not a registry you load into — the words that generate physical names are imported in the word list, and the terms follow from the model that uses them.

Three dictionaries, one model

Sqemo keeps three: the word list (how each word becomes a physical word), the business glossary (what each business term means), and domains (the type and length a term resolves to). That split comes from ISO/IEC 11179, where a data element’s name and its definition belong to the same registry entry rather than to separate systems. For the longer argument, see Data Dictionary vs Business Glossary.

On a read-only shared link the Definitions view is visible but definitions cannot be edited.

Unlike words and domains, definitions are not locked while a project is connected to a team standard. Words and domains are a cached copy of the standard; a definition is your project’s own data, so you can keep editing it whether or not the project is linked.