That’s the Way

There are a bunch of good rules-of-thumb for defining good entities that will help you build better models. We’ll walk you through some of them below.

Rule 1: Entities are singular nouns.

This is a very simple rule that you should always follow, with no exceptions. When you create an entity, it should be a singular noun. Not Customers, but Customer. Not Condition monitoring (e.g. for a machine in a factory), but perhaps Condition measurement instead. Think of the business problem or process you are modeling in verbal form, as a story: “A customer creates an order for some products. We then dispatch the delivery to them.” Pick the nouns from this story, and you have very good candidates for entities.

Rule 2: Entities exist in the real world of the business.

This real-world rule is not always so straight-forward, but it is very important. A system or a report isn’t really what your business is about, right? Your business is about customers and products and factories, or other things like that. Focus on these real-life concepts, and avoid adding into your model the artifacts that perhaps contain information about the real world. Later in a data initiative, we might define that we need information about some part of the model presented in the form of a report or some other analytical solution. Or maybe the data needs to be stored in a system. But you need to understand the difference between defining data content (i.e. a model of real-life entities) and utilizing/storing it (i.e. a report or a system).

Rule 3: Entities are countable.

The third rule is perhaps not entirely self-evident at first, but it’s perhaps the most powerful one. Think about the occurrences or instances the concept represents: your Customer entity represents all your 15,000 customers – you don’t have to add 15,000 entities in your model! If you have an entity where there is nothing to count, you’ve likely modeled something wrong. A common mistake is to add things like process steps or abstract terms as entities. You can’t have three Analytics, nor can you count the number of Billing; these don’t even make any grammatical sense, so why would they make sense in a data model? An easy way to test this is to pick an entity and say out loud to yourself: “I have three *entities*”. Does it make any sense? Make a habit out of this, and you will soon develop an intuitive ability to avoid uncountable entities – after which you no longer need to worry about talking to yourself and getting strange looks from your colleagues!

Rule 4: Attributes are not entities.

Put this way, rule 4 seems quite obvious. Goes without saying, right? However, it’s an extremely easy mistake to make. Your business experts care deeply about KPIs and measures such as turnover, account balance, or customer satisfaction. These are nouns that constantly come up in their “story” that we told you to listen to in rule 1! To avoid modeling attributes as entities, you should ask yourself the following question: “Do these words refer to things in the real world, or are these facts that we know about some other thing?” You can easily see that “customer satisfaction” is a fact that you know about a customer, and “account balance” tells you something about an account. List these as attributes of their respective entities, but don’t promote them to separate entities. Rule 3 (countability of entities) will also help you in these cases, as surely you cannot say “I have three turnovers”!