Logical Data Modelling: Entities Attributes

Following on from the previous blog in the series, the next building block in defining Data Models is the data characteristics that almost every Entity should have.

Continuing by following our CAFC example, we will want to record the name of each Player.

These characteristics form the information that we will need to provide when describing an individual Entity occurrence, known as the Attributes of the Entities.

Each of these Attributes in turn has their own characteristics (metadata), that allow us to specify what each Attribute means and what type of data we record in them.

This blog outlines how to specify Attributes and provides guidelines for improving Data Model quality.

Each Attribute of an Entity needs a name.

In both the Conceptual and Logical Data Model, the name should:

Verbose names reduce ambiguity and therefore make the model much easier to agree upon, digest and communicate. Steer away from abbreviations and acronyms even if you think their meaning is well known in the organisation.

Using a naming convention will ease the definition process and enforce consistency across the model.

One such naming convention follows the use of three potential elements in the name:

As examples:

Attribute names must avoid any stylistic naming conventions, as the Logical Data Model should be technology agnostic, and should not put off non-technical stakeholders.

Although Attribute names should be verbose, there is no need to include the Entity name as a prefix.

For example, if we had a Player Entity:

Player First Name

Player Last Name

Player Signed Date

Like Entities, an Attribute should have a description to fully define what it represents and include examples where appropriate.

The descriptions can also be supplemented with information explaining under what circumstances data would be recorded in it, amended or removed from it.

One of the key factors to consider when including an Attribute, is the accuracy of it over time.

For example, we may want to include the coaching staff members of rival teams.

At first, it might seem like a good idea to add two attributes to record job titles and departments.

But we always need to consider how these will be kept current. If a coach leaves the club, moves department or gets a promotion, how will that information be collected and updated in your organisation?

As soon as some types of data are captured, it starts to become stale and can reduce its usefulness or even become a hindrance.

You need to consider what each Attribute’s shelf life is and how it will be kept current, or, is it necessary to record it at all?

Only record data about ‘Base Attributes’ and never define ‘Dependent Attributes’.

A Dependent Attribute is one whose value depends on one or more other elements of data. These elements may or may not be Attributes of that Entity.

For example, instead of recording the age of a player, record the Date Of Birth. The Age is dependent on the date of birth and any point in time. Keen readers may also have noticed that Age risks becoming stale, whilst Date of Birth won’t.

Attributes must not record complex data. Each Attribute must represent only atomic values.

This means it must not consist of multiple independent elements and cannot have any internal data structure or pattern.

As a basic example, an Attribute for the name of a player shouldn’t contain ‘Darren Bent’ as this can be separated into constituent parts.

Instead, there should be a First Name and Last Name Attribute.

A big red flag for an Attribute name is it being pluralised.

For example, consider the Attribute name of Sponsors. This Attribute clearly violates this atomic rule.

Should we instead break it up into Sponsor Name 1 and Sponsor Name 2?

No. This will be made clear in future blogs.

Some Attributes will be mandatory for each Entity instance. What is really meant is; which Attributes must have values when the Entity is first created.

This blog series will use Barker Notation. The notation for this is:

When ordering the Attributes for an Entity, one option is to order the Attributes in the expected fill proportion, which will first include the mandatory Attributes.

Then the next ‘most important’ Attributes at the top. This is illustrated on the right of the below diagram.

Instead, you may want to group Attributes based upon shared purpose, and then order within these groups upon fill percentage, illustrated on the left.

Note here that I am not recommending all these Attributes belong in this Entity, it is just illustrating the point of Attribute ordering.

Bear this in mind throughout the series that each data model fragment is not necessarily following perfect Logical Data Modelling practices but used to illustrate key modelling concepts.

Attributes have their own characteristics that define them and should aid understanding.

Datatype

Attributes should have simple datatypes defined, such as:

It is important to remember that the Logical Data Model needs to be immutable and technology agnostic. Current physical implementations can be used to inform our Logical Data Models, but this should not dictate the datatypes defined in the Logical Data Model.

For example, don’t be persuaded that a specific Attribute must be Numeric because of a stakeholder or a current implementation.

Think carefully about Booleans. This records one of two states: True or False.

If the Attribute is not mandatory, then it asks the question as to whether it is truly Boolean.. what would Null represent?

Also, what appears as a Boolean now may later contain other values for example ‘Awaiting Confirmation’.

It may be worthwhile enforcing a naming standard of Boolean Attributes across your model such as

Is [Communication Sent]

Attribute size

Most Data Modelling tools will enforce lengths/precisions for number and character datatypes.

Do not spend too long worrying about the fine tuning of these sizes as details such as performance considerations are not relevant at the Logical level.

It is instead worth qualifying the size with a set number of predefined values e.g. 25, 50, 250, 4000.

Most modelling tools allow you to create domains as standard Meta Data definition templates that can then be assigned to the different Attributes within your Data Model.

For example:

Using this technique will ensure consistency across the model, and reduce the time spent worrying about tuning fine level metadata that offers little reward.

The next blog in the series will introduce the next key feature required to start building Logical Data Models: Relationships.