Data modeling

A data model is an abstract representation of how product data on a PIM solution is connected and organized. Data models are created in a group-like structure, and on each node you can add a category group – the attributes in this group are then inherited to data models further down in the tree.

DataModeling

Designing product data models is a complex task – but it is also the single most important task for solutions with a PIM-setup, as it creates the foundation for eliminating redundancy, reduces storage requirements, improves scalability, and makes maintenance of product attributes a much simpler task. But there are many different ways to approach data modeling.

For example – if you have a Bike shop, you may want to create a data model structure like this:

Bikes – this node contains all attributes common to bikes
- Mountain Bikes – this node contains all attributes common to mountain bikes and all attributes inherited from Bikes
- Road Bikes – this node contains all attributes common to road bikes and all attributes inherited from Bikes
- Classic Bikes – this node contains all attributes common to classic bikes and all attributes inherited from Bikes
- Children’s Bikes – this node contains all attributes common to children’s bikes and all attributes inherited from Bikes

Now, some of these bikes may be electric bikes. Instead of adding a set of attributes relevant to electric bikes to either the Bikes-node or each subnode – which would add the properties to all bikes under those nodes, regardless of whether or not they are electric – you can create a second data model structure separate from the Bikes-structure:

Other Properties
- Electric Bikes – contains all attributes common to electric bikes

You can then relate products to a model under Bikes, and for each electric bike also relate them to the Electric bikes data model, and they will inherit the attributes from both data models.

You may also want to add some Brand-information to your products – if so, you can add a second data model to the Other properties-node:

Other Properties
- Electric Bikes – contains all attributes common to electric bikes
- Brand – contains attributes related to brands, e.g. name, logo, website, description, etc.

Now, this is only one way to approach the data – but there’s more than one way to skin a cat, as the saying goes. You could, for instance, create a data model structure consisting of a set of components, and then – for each bike – relate them to the data models which make up a whole bike:

Bikes – contains bike-related universal properties
Components – contains component-data models
- Engine systems
  - Engine Center
  - Engine Front
  - Engine Rear
- Gear systems
  - Gear External
  - Gear Internal
- Brake systems
  - Disc Brakes
  - Rim Brakes
  - Drum Brakes
- Frames & Forks
  - Frames
    - Frame (Full suspension)
    - Frame (Hardtrail)
    - Frame (Road)
    - Frame (Classic)
  - Forks
    - Fork (Suspension)
    - Form (Fixed)
- Wheels
  - Wheels MTB
  - Wheels Road
  - Wheels BMX
  - Wheels Classic

Using this approach, you don’t have to immediately classify a bike as a road bike or a classic bike, which is useful for some types of product portfolios and businesses, but it’s impossible to give a simple answer as to which approach is better; it depends on multiple factors such as;

How the product data is stored and organized remotely
How the customer works internally with product information
Which method for maintaining and categorizing data models is most scalable and extendable for the customer type

For each data model, you can also create data sets, which are preconfigured instances of a data model, e.g.:

A Shimano EP600 for the Engine Center data model
Shimano for the Brand data model, etc.

You can then relate a bike to the Engine center data model, and then select the Shimano EP600 data set, and the bike is one step closer to being ready for publication. This is of course especially useful on solutions where you work with a relatively fixed set of known product components.

When you data model you will need these tools:

Many setups also add completion rules to data models - they can then be inherited on any dynamic workspaces which are based on the data model.

Table of Contents

Data modeling