Logical Data Modelling: Entities

Welcome to the first blog in a series on various Data Modelling techniques for producing Logical Data Models. We will start with the basics and explore progressively more advanced topics. The practical examples will be applied to a topic close to my heart: Charlton Athletic Football Club (CAFC).

Logical Data Models are synonymous with ‘Enterprise Relationship Data Models’ or ‘Normalised Data Models’. For the purpose of this series I will commonly refer to them as Logical Data Models.

The Logical Data Model defines all of the Enterprise data required by an organisation, providing it with the foundations to succeed.
In order for an organisation to run optimally, they must understand its data and have a shared understanding of its meaning across the organisation.

This understanding should come from what is defined and communicated using Data Models. The Logical Models serve as the backbone to this unified understanding of the organisation’s data.

These models can form a foundation for: implementing normalised physical models, denormalised models (often in the form of a dimensional model) or being a key material for data migrations.

From my experience, data migrations often suffer from there being no enterprise-wide view of all the data required by a business, leading to a fear of deprecating legacy solutions if it is not fully understood what data a business needs to operate.

After reading this blog series I recommend reading The Data Model Toolkit by Dave Knifton, which served as a key source of inspiration for this series. You’ll find some of the concepts in the blog series are explored in more detail, while other completely new concepts are introduced.

This first blog aims to introduce some of the building blocks required to start defining our Logical Data Models.

Entities are ‘significant things’ about which the Data Model needs to capture data.

Many entities are concrete and physical, whereas others are abstract and may not be so obvious.

Using CAFC, concrete examples include staff, stadium, and equipment whilst more abstract examples include a football season or a team’s momentum.

Notice here that Entities are visualised as round-cornered boxes and described in the singular.

The primary purpose of our Data Models is to serve as a communication tool. Hence, the naming of an Entity is of the utmost importance.

The importance of the naming convention holds true for all constituent parts of our Data Models that we will explore in the series.

When defining entities, watch out for contradictions to the singular naming convention, for example:

At first glance, the following Entity names may appear interchangeable:

At first glance, the following Entity names may appear interchangeable:

But these represent subtly different things, and influence the way that each is thought about in the context of the organisation. Choose the name that most accurately reflects the Entity’s meaning in the model.

An Entity can be supplemented with the use of synonyms.

Record synonyms if:

The third point is likely given the importance of future proofing your logical Data Models.
One way to future proof your logical models is by focusing on business functions rather than processes.

The theory behind this is that today’s business processes may not be optimal and also might not exist in 5 years’ time.

Whereas, its core business functions are abstracted definitions of the activities organisations should carry out now and in the future.

This layer of abstraction may give rise to abstracted entities that require the use of synonyms. An example of this would be recording an Entity as ‘Communication Channel’ rather than ‘Email’.

If the different names don’t match any of the synonymous criteria, then you need to decide if they really are different ‘things’ and hence need to be recorded as different Entities. Providing synonyms therefore serves as a possible way to discover new Entities.

As with all parts of the model, the name of an Entity is not set in stone, it might be that when you come to understand your data more finely, a new name is needed.

After establishing an Entity’s name, you need to define a description. The description must be concise, and worded in a way that key stakeholders can agree and understand. Its description can also be supported by a number of examples and a more abstract Entity name can be supported by concrete things from which the Entity has been abstracted.

Recording the nouns found in communications and documentation is often used to help start the Data Modelling process by starting to define the significant Entities. Consider an Organisation Entity. At first glance, this could seem quite straightforward i.e. any company we do business with.

Consider an Organisation Entity.

At first glance, this could seem quite straightforward i.e. any company we do business with. However, there are many different types of organisations. For instance, suppliers of our kits, charities or authorities such as the police who will be involved in matchdays.

Starting to dig deeper into the initial high-level entities will get you thinking about the lower-level details and how to best go about modelling these.

As discussed, adding synonyms to an Entity can also uncover some additional Entities.

The next blog will continue exploring the building blocks required to start building out our Logical Data models, by looking at how we can enrich our Attributes with characteristics.