Data Dictionary overview
Once standard words and domains are registered, typing a column logical name in the ERD fills in the physical name and the type. This page explains what a domain and a dictionary are, and the order in which you use them.
What a data dictionary and a domain are
A data dictionary is a list of the names used in a database and what they mean: which term is written with which abbreviation, and what that term refers to, agreed on in advance across the organization. Data modeling usually splits it into three things.
| Concept | Common definition | Example |
|---|---|---|
| Standard word | The smallest unit a name is built from, pairing an official term with its abbreviation. | Customer = CUST, Order = ORD, Datetime = DTM |
| Standard term | The table and column names actually in use, assembled from standard words. | Order datetime = ORD_DTM |
| Domain | A name given to the type rules shared by values of the same nature. | Amount = DECIMAL(15,2), Flag = CHAR(1) |
A domain is an old idea in the relational model, where it means the set of values an attribute may take. In practice it is used as a reusable bundle of type, length, scale, nullability and default value. Standard words unify the names; domains unify the types those names carry.
When the same meaning is written differently by different people (customer number, cust_no, customer_id, cst_num), one value ends up scattered across systems under different names and different types. That is where the cost of integration, querying and migration comes from, and why public data standards and in-house DA guidelines ask for this list first.
Attaching domains to words: the NeoSQL difference
The three lists are usually kept separately, and which term uses which domain is lined up by hand in a spreadsheet. NeoSQL attaches the domain to the word itself in the dictionary, and that is the biggest difference from other tools. Once the word for datetime carries a DATETIME domain, reading that word out of a logical name settles the name and the type at the same time, instead of applying the naming standard and the type standard in two separate passes.
NeoSQL keeps these three in two kinds of asset. Domains live in a domain asset, while standard words and the combination rules live in a dictionary asset. Standard terms are not managed as a separate list: they are either assembled from the logical name (combination type) or accepted only on an exact match with a registered term (exact type).
What it solves
Instead of keeping a naming standard document open beside you and copying abbreviations by hand, the naming rules move into the design screen. Type Order date as the column logical name and the physical name ord_dtm is built, while the domain attached to the trailing word fills in type, length and nullability.
The table below shows what a combination-type dictionary produces from a logical name.
| Logical name | Generated physical name | Applied domain |
|---|---|---|
| Order datetime | ord_dtm | Datetime · DATETIME |
| Customer number | cust_no | Number · VARCHAR(20), suggested |
| Use flag | use_yn | Flag · CHAR(1) |
The physical name is assembled from the abbreviations registered in the dictionary. Letter case follows the DBMS policy, so it lands as ORD_DTM on Oracle and ord_dtm on PostgreSQL, exactly as if you had typed it.
Two ways a dictionary reads names
A dictionary reads logical names in one of two ways. You choose it when the asset is created, and the behavior on screen follows from that choice.
| Aspect | Combination | Exact |
|---|---|---|
| How it reads | Reads registered words longest first and joins their abbreviations into a physical name. | Uses an abbreviation only when the whole logical name matches one registered term exactly. Nothing is combined from parts. |
| Example | Order datetime = Order (ORD) plus Datetime (DTM), giving ord_dtm | The compound term itself must be registered to produce cust_ord. Having the two parts registered separately is not enough. |
| Where the domain comes from | The domain on the trailing word of the combination becomes the candidate. With several candidates it is only suggested. | The domain on the matched term is the candidate. There is exactly one word, so there is exactly one candidate. |
| When it cannot read the name | Puts only the parts it read into the physical name and marks the characters it could not. | Produces no physical name and marks the whole logical name as unregistered. |
| Typing assistance | No suggestion list, because several words are being joined and the boundary of what you are typing cannot be known. | Suggests registered terms as you type, and picking one settles the physical name and the domain together. |
If you already work from a word-level naming standard, combination is the right fit. If only settled terms from a company-wide glossary may be used, choose exact.
The match type is fixed when the asset is created and is not changed later. A connection pins a single dictionary, so if you need both ways, create separate dictionaries and pin them per connection.
Domains and dictionaries in NeoSQL
A data dictionary is made of two kinds of asset. They are independent, so using only one is fine.
| Kind | What it holds | What it does |
|---|---|---|
| Domain | A bundle of physical column attributes: type, length, scale, nullability, default value, auto increment | Assigning a domain to a column writes those values onto the column |
| Dictionary | Standard words and abbreviations together with the domain attached to each word, plus synonyms, forbidden words, related words, antonyms and similar words | Reads a logical name to build the physical name, and applies or suggests the domain attached to the word it read |
A dictionary can pin one domain pack so its words have domains to point at. In that case the connection domain slot is locked to the pack the dictionary uses.
The order of work
Create the asset
Open Data Dictionary in the top menu and go to Data dictionary management to create a domain or a dictionary.
Fill in entries
Register domains and words in the grid, or upload them all at once from Excel.
Save, then publish
Edits are a draft. Save and publish before the asset can be pinned anywhere else.
Pin to a connection
In the connection settings, open the Data Dictionary tab and choose the domain, the dictionary and the version to use.
Use it in the ERD
Type a column logical name and the physical name and domain are filled in.
Availability and scope
- The data dictionary is available on the Free plan with no time limit.
- On desktop you can create device-local assets without signing in and use them in local projects. Device-local assets have no publish, version or member concept.
- A local project can only pin official packs and assets stored on this device. Account assets do not appear in the list even while you are signed in.
- An account project can pin official packs, public assets, and assets you own or co-edit.
Good to know
- A logical name is metadata unrelated to DDL. Typing one on a column that already exists in the database does not rename it or change its type.
- Domain values are copied onto the column rather than referenced, so ERD rendering and DDL generation keep working even if the asset is no longer reachable.
- Pinning is per connection, so a production connection and a new project can follow different standards.
- A pin points at one specific version. A newly published version is not picked up automatically.