Sqemo

ISO 11179 Naming Conventions: What the Standard Says, and Why It's Hard to Follow

· Updated

Open any data governance document and you will find ISO/IEC 11179 cited in the first few pages. Open the database that document governs, and you will usually find usr_id, userId, and customer_no sitting in the same schema. The gap between the citation and the schema is remarkably consistent, and it is not because the standard is wrong.

It’s because ISO 11179 describes a system that is very hard to operate by hand, and most teams adopt the citation without the system.

This post covers what the standard actually specifies for naming, the one step it deliberately does not give you, and what has to be true for a team to follow it on a real database.

What the standard specifies

ISO/IEC 11179 is a multi-part standard on metadata registries. Two parts matter for naming:

Part 5’s central idea is that a data element name is not written, it is composed from parts that come from controlled vocabularies:

So PersonBirthDate is not a name someone chose. It is Person + Birth + Date, assembled in that order because the registry says so. Ask ten people on the team to name the same data element and, if they are all drawing from the same vocabularies, you get the same name ten times.

The representation term is the part people usually miss, and it is the most useful one. It is a designation of a representation class — in practice, a small controlled list along the lines of Amount, Code, Date, DateTime, Identifier, Indicator, Measure, Name, Number, Quantity, Text, Time. Registries extend or restrict that list, but the point holds: the last word of the name tells you the shape of the value before you look at the column type.

That is why a name ending in Amount should never be a VARCHAR. The representation term is a type declaration written in business language, which means it can be checked.

The step the standard doesn’t give you

Here is the part that trips up every team that tries to apply 11179 to an actual SQL schema.

The standard names data elements in a registry. It does not name columns in your database. Customer Account Number is a conformant data element name. It is not a column name, and turning it into one requires a decision the standard does not make for you:

Customer Account Number   →   cust_acct_no?
                          →   customer_account_number?
                          →   CUST_ACCT_NUM?

Abbreviation, case, delimiter, length limits, what to do with a word nobody has abbreviated before — none of that is in Part 5, and all of it is where real schemas diverge. Two teams can both be perfectly conformant and still produce different columns for the same concept.

This is not a defect in the standard; it is scoped that way on purpose, because a metadata registry is not tied to one physical platform. But it does mean that “we follow ISO 11179” is an incomplete sentence at the database layer. The complete version needs a second vocabulary: one abbreviation per word, decided once. customer → cust, number → no, account → acct. That mapping is the bridge between a conformant data element name and a column you can actually create, and it is the artifact teams most often skip.

Once it exists, though, the physical name stops being a decision. Customer Account Number plus that word list plus a case and delimiter rule produces cust_acct_no, deterministically, for whoever is typing.

Definitions are part of the standard too

Part 4 is worth reading even if you never formally adopt it, because it turns “write a description” into something with testable rules. The requirements are about semantics rather than formatting: state what the concept is rather than what it is not, express it as a singular descriptive phrase, don’t embed the definition of a different data element inside it, and don’t be circular.

That last one is the common failure. A definition that reads “Customer Account Number: the account number of the customer” passes review in every organization I have seen and carries no information at all. Part 4 exists to make that a rule violation rather than a matter of taste.

The deeper reason Part 4 belongs next to Part 5: a name and its definition are attributes of the same registry entry. When the name lives in a modeling tool and the definition lives in a governance platform, the two drift apart, and there is no mechanism that notices — a problem we’ve written about at length in Data Dictionary vs Business Glossary.

An existence proof at national scale

If the standard sounds too heavy to actually run, it is worth knowing that a country runs it.

South Korea’s Database Standardization Guideline for Public Institutions (행정안전부고시 제2017-1호, in force since 2017) requires public-sector databases to be built against three published dictionaries, using the same decomposition the standard describes:

The common word and term sets are published as open data and audited. Whatever you think of mandating naming by decree, it settles one question empirically: the model scales past the whiteboard. Tens of thousands of columns across hundreds of institutions do get named this way.

It also demonstrates the cost, and this is the part I watched up close for years. Those three dictionaries are overwhelmingly maintained in spreadsheets, and the schema is maintained somewhere else. Every name is a manual lookup across files, every audit is a manual reconciliation, and the standard holds exactly as long as somebody keeps doing that work. When it slips, nothing tells you — the database accepts a non-conformant column exactly as happily as a conformant one.

What it actually takes

Strip away the registry vocabulary and following 11179 on a real database needs four things:

  1. A word vocabulary with abbreviations. One approved short form per word, decided once, applied everywhere.
  2. Representation terms bound to types. Amount means DECIMAL(18,2) here — write it down once instead of re-deciding per column.
  3. Names that are generated, not typed. As long as a human types the physical name, the vocabularies are advisory. Composition is the whole mechanism; typing bypasses it.
  4. A check that runs without a person. A conformant name and a drifted name look identical to the database. If nothing recomputes the expected name and compares, drift is invisible until an audit.

Points 1 and 2 are documentation problems and most teams can do them in an afternoon. Points 3 and 4 are the ones that decide whether the standard survives contact with a deadline, and they are not documentation problems at all.

Where this leaves you

If you have a small schema and a stable team, you may not need any of this — a conventional naming guide and code review will hold. The machinery earns its keep when there are more namers than reviewers, or when someone external will audit the result.

If you do need it, Sqemo is built around exactly the decomposition above: a word list with abbreviations, domains that bind a business type to a physical type, a glossary holding each term’s definition next to the name it belongs to, and physical names that are computed from all three rather than typed. Drift becomes checkable because the correct name is a function — there’s a linter in the app and a CLI that fails CI when a column stops matching what the vocabularies would produce.

One honest limit: implementing 11179’s naming decomposition is not the same as being a conformant metadata registry. A full MDR in the sense of Parts 3 and 6 involves registration authorities, administered-item lifecycles, and classification schemes that Sqemo does not model. If you are being assessed against the registry parts of the standard, this is a modeling tool that shares the structure, not a compliance product. What it does cover is the part that actually touches your schema: the names, the definitions behind them, and whether the database still agrees with both.

Sources: ISO/IEC 11179-5:2015 Naming principles · ISO/IEC 11179-4:2004 Formulation of data definitions · Representation term · 공공기관의 데이터베이스 표준화 지침 · 행정안전부 공공데이터 공통표준용어