Real World Information Modelling: Naming

Despite the growing maturity of our industry, there are some mistakes that seem to be repeated by each new generation of developers.

We have good technical standards for how we document our information structure – from good old Entity-Relationship diagrams through to the UML. There are even some attempts to provide general guidance on information modelling – the Nebulon Archetypes aka Colour Modelling are one good example – but in too many ways the lessons learnt by one generation of modellers are left for the next to learn anew.

In this post, I hope to convey one lesson that I’ve learnt, in the hope that your mistakes will be novel ones.

Naming

Consider how to capture the simple details of a person’s name. Most modellers or developers will quickly put together a structure like the one shown here.

At first glance, this looks reasonable – it will certainly handle a lot of cases, so isn’t this sufficient? Depending on the system you’re developing it might be – but if you’re going to be dealing with the public, you’ll soon find that many people are rather attached to other parts of their name, often reflecting family history or honours bestowed.

William Henry Gates III (Founder of Microsoft)

Sir Winston Leonard Spencer-Churchill (Prime Minister of the United Kingdom)

Sir Edmund Percival Hillary (Conqueror of Mount Everest)

We can quickly amend our design by adding some additional fields. With this structure, we can readily capture all the parts of one person’s name – so our job is done.

Or is it?

It turns out that the very idea of a first name and a last name is somewhat parochial, one that originates in part with the western cultures emphasis on individuals.

In contrast, other cultures, including many Asian ones, place higher emphasis on the family than on the individual. This often goes as far as giving the family name before the individuals.

Some examples…

Jacky Chan (Martial Arts Actor) born Chan Kong Sang

Masi Oka (Actor, Digital Effects Artist) born Oka Masayori

A system dealing in purely local matters – one which will never need to deal with foreigners or immigrants, or the children of same – doesn’t need to have support for different traditions of naming.

But how realistic is this? We’re living in a 21st century world where most of our systems have a global reach, and where the population is increasingly mobile.

I contend that our systems need to be designed with a global reach in mind.

The question becomes: How do we capture a person’s name in a culturally agnostic fashion?

Here’s my suggestion…

FullName is the person’s full name, as it would normally be written.

KnownAs is the name used to address the person during normal day to day activities

OrderKey is a separate key used for sorting records into alphabetical order

This structure has some interesting characteristics.

• Capturing name as a single field, allows users to enter names as they should be written, instead of forcing names to be broken into our arbitrary structure.

• Splitting out the persons common name as a separate field allows the system to properly capture nicknames, anglicized and alternate names. Some examples include Kathryn who prefers to be called Kate; Chan Kong Sang, known as Jacky (Chan); Tania Susan Woods, preferring Susan instead of Tania.

• Storing OrderKey as a distinct field allows for names to be sorted in the way we expect – instead of the way the machine normally provides. For example, the family name McDonald should be sorted as MacDonald, and St. James should be sorted as Saint James.

In this article, we’ve seen how using a different information structure can easily capture the information we need in a form that is not only useful, but respectful of the people whom the information represents.