The data structure be behind the master data hierarchy can seem rather complex.
The master data hierarchy in Business Central is built on four data layers: master data groups, master data relations, master data item relations, and fixed master data item relations.
You set up the foundation in master data groups. Here you define the top-level code and how many sorting levels the hierarchy should have, and you specify which master data specification builds each level.
The hierarchy you see when you refresh it is calculated at runtime from the master data relations table. Each node has an entry number, and child nodes point to their parent through a parent entry number.
Master data item relations connect each item to the relation nodes above it. These are created automatically when you refresh the hierarchy. One item can refer to several entry numbers, so the same item can appear in more than one web shop.
When you manually add an item to a specific place in the hierarchy, the system stores it as a fixed relation in the fixed master data item relation table.
If you move the hierarchy outside Business Central, you use this same data structure.
The four data layers behind the master data hierarchy
You do not need to be a data master to work with the master data hierarchy, but it helps to understand what the data structure is made of. The structure has four layers, and each one has a clear job.
At the top you have the master data groups. This is the base setup. In the setup you define the top-level code and the information code, and the master data groups define the hierarchy on sorting level zero. You can create as many hierarchical levels as you want. For each sorting level you specify which master data specification the system should use to build that part of the hierarchy. This is the first setup level.
How master data relations build the hierarchy at runtime
The second layer is the master data relations. This is where you define what you see when you refresh the hierarchy without items. The hierarchy is calculated at runtime, so what you see on screen is generated from the data in this table.
A practical example: a bike shop contains mountain bikes, which contain different city bikes, and a mountain bike contains gears. All of that comes from the master data relations.
Every node in the relation table has an entry number, shown on the left-hand side. The structure works through parent references. The top level might be the web shop. From there it goes into the bike shop and the mountain bike shop, because those are the top-level nodes. If you filter on a parent entry number, you see everything that sits underneath that parent. Filter on the entry number of the mountain bike shop, for example, and you see the parts that belong to your mountain bikes.
That is why the bike shop and the mountain bike shop can contain different things. The bike shop might only contain a model, while the mountain bike shop contains different gears. It is all defined behind the scenes in the master data relations.
How master data item relations connect items to the hierarchy
When you update the master data relations, the system recreates the relations per item. When you refresh the hierarchy and look at the individual items, each item number refers to the master data relation above it.
This connection lives in the master data item relation table. For example, item number 1001 refers to entry number 120, and it also refers to entry number 187. Those two entry numbers are the two different web shops, one being the bike shop and one being the mountain bike shop. The item relations are created automatically when you refresh the hierarchy.
How fixed relations place items manually in the hierarchy
The final layer is fixed relations. When you want to add an item to a specific place in the hierarchy, for example under a city bike, the system stores it as a fixed relation in the fixed master data item relation table.
This table filters on the relation type and the relation number. If you add more items on the same level, you get more records in the table. To see all your fixed relations, you remove the filter on the relation number.
With these four layers working together, the hierarchy is built automatically every time you refresh it. And if you move the hierarchy outside Business Central, this is the data structure you should use.
Q&A
What are the four data layers in the master data hierarchy?
The four layers are master data groups, master data relations, master data item relations, and fixed master data item relations. Master data groups hold the base setup and sorting levels. Master data relations define the hierarchy itself. Master data item relations connect items to the hierarchy. Fixed master data item relations store items you place manually.
Is the master data hierarchy stored or calculated?
The hierarchy is calculated at runtime from the master data relations table. When you refresh the hierarchy, the system generates what you see from the data in that table.
How does the system know where an item belongs in the hierarchy?
Each item number refers to the master data relation above it through an entry number. This connection is stored in the master data item relation table and is created automatically when you refresh the hierarchy. One item can refer to several entry numbers, so it can appear in more than one web shop.
What happens when you add an item to the hierarchy manually?
The item is stored as a fixed relation in the fixed master data item relation table. This table filters on the relation type and the relation number. To see all fixed relations, remove the filter on the relation number.
Which data structure should you use if you move the hierarchy outside Business Central?
Use the same four-layer structure: master data groups, master data relations, master data item relations, and fixed master data item relations.