Mindville has joined the Atlassian family!

Jira Service Desk | 4 MIN READ

Data Modeling - Part 2: Tips and Tricks for Object Types Modeling

In this blog, we will continue to talk about data modeling in Insight from our previous blog, Data Modelling - Part 1: Distributed Object Schema Mode. This time, we’re taking it a step further and diving into the modeling of object types.

Now, we’ve talked about distributed object schemas, but the next question is this: How do we distribute objects within one schema?

Just like before, there’s no single, simple answer. That said, we do have some experience and references from multiple implementations that we want to share with you.


Object Types

First thing’s first, let’s look at object types structure.

Each object type is a container for objects, and there are no physical boundaries of how many levels you may setup. Each container (object types), regardless if it’s a child or not, can be independently configured and is capable of managing its own references to other object types.

When creating children object types, they can be configured to inherit attributes from the parent object type. This is not a default setting and can be configured manually. Although a child object type is physically a container within a larger container stack/directory, logically, each container is its independent entity.

When creating parent and children object types, the parent is often kept empty, that is without objects. We call this abstract object types.

Feel free to use "empty" object types as “data chapters" or abstract object types

What does it mean?


Parent and children object types

Let’s assume you have two root containers, Categorization and Models, as shown in the picture below.



You could, of course, fill them with objects, but that might end up being complicated and difficult to report on when you want to have more than one category level or type of model.

In other words, how can you distribute top-level objects into lower levels?

To simplify, we have updated the structure in the picture below and added both a child object type for sub-category and children object types for different models.



For the categorization, we added one child as a sub-category. In that case, we have objects in both the parent and child object types.

For the models, on the other hand, we created two children for model types and kept the parent (model) as abstract. Structuring the object types in clusters as described above makes it easier to recognize and manage by a human.

Below is another example of this where we have created several abstract object types, to show how we can categorize different types of assets into the same object schema without losing control.



There are two more tricks to adapt when designing an object type structure. The next one worth mentioning is the naming convention.


Naming convention

When we mentioned “fit for purpose” in our previous blog about object schema modeling, we also meant the jargon used within specific business areas.

The vocabulary differs between the different business areas, such as IT, marketing, HR, and others. For that reason, and because Insight can be used for anything, we kept the Insight terminology as neutral as possible, using objects instead of assets, object types and object schemas instead of CI types and CMDBs.

This way, Insight is adaptable to various processes within the business.

When naming your object types, each business area can choose the names that make sense to them and are known within their business area. At that same time, they need to take into consideration that people in other areas will have to understand the structure they build.



The last trick to consider is not related to the tool, but rather to architect's or data modelers’ practice. That is anticipation. The anticipation of growth, of upcoming needs, of revealed data collection capabilities, and more.

It’s a good practice to plan your initial structure in a way you would like to manage it for the next 3 years. You don’t need to implement it all at the same time, just keep it somewhere, as the empty schema(s) or as a documentation.

Then, copy this structure and get rid of object types and references that you cannot provision and manage at the initial stage. Next, work on providing 90% of what was planned for the initial stage. Once you have reached that goal, expand to the unknown and do the same.

Grow, garden data, and gather the fruits - The complete knowledge of your organization's assets.



In this blog, we talked about 3 tips and tricks to consider when modeling your object types.

  1. Use abstract object types
  2. Naming convention
  3. Anticipation

There are more tricks that are worth mentioning and will be addressed in our future blogs. If you have experience in modeling data in Insight, you know that it’s easy to find yourself in a complex situation where there is more than one solution to your problem.

In addition to these three tips, you will also need to consider the attributes and references you want to configure, what kind of automation you want to implement, how to link to your data source (if it’s elsewhere), and more.

Our next blog in this series will cover attributes and references to continue our journey of data modeling.


To find out more about Insight or to see the product in action, click on the link below.

Learn About Insight

Originally published Jan 21, 2020 3:00:00 AM