- Design Your Data Model Guide Part 3
- Step 7: Prioritize
- Step 8: Largest Group
- Step 9: Iterate
- Step 10: Validate
- Step 11: Next Steps
Design Your Data Model Guide Part 3
Step 7: Prioritize
The first step in the design process is to use the Thing-Component Matrix to identify and prioritize groups of Components that are shared across multiple Things. These groups will be prioritized by number of shared Components, from highest to lowest, enabling is to break out the most commonly used groups of Components and package them into reusable pieces.
Let’s examine our example Thing-Component Matrix to identify and prioritize groups.
In the table below, we have done this and recognized that there are FOUR groups.
NOTE: Each item in our unique Thing-Component Matrix would also count as a group on its own. This can be dealt with almost separately from our process, though, because there is no overlap between different Things. The "Templates for Unique Components" and "Adding Components Directly to Things" sections in the Iterate step of this guide covers these "one-offs."
Step 8: Largest Group
The base building block we use most often is the Thing Template. To start the design process, the first step is to create a Thing Template for the largest Component group. Applying this to our Smart Factory scenario, we'll take the largest group ("Group 1") and turn it into a Thing Template using the Entity Relationship Diagram schematic.
Since every item on our production line shares these Components, we will name this Thing Template Line Asset.
Now, let's build this using our Entity Relationship Diagram.
The result is a ThingWorx Thing Template with five Properties, one Event, and one Subscription.
Step 9: Iterate
Once an initial base template has been created for the largest group, the rest of the groups can be added by selecting the appropriate entity type (Thing Template, Thing Shape, or directly-instantiated Thing).
The following Entity Decision Flowchart explains which entity type is used in which scenario:
Now that we have established our "Line Asset" Thing Template for our largest group, the next step is to iterate through each of our remaining groups. Following the flowchart, we will identify what entity type it should be and add it to our design.
Group 2 - "System Connector"
The second group represents connectors into both of our internal business systems. We will call them System Connectors.
If we look at Group 2 versus our "Largest Group" Thing Template, we can see that there is no overlap between their Components. This represents the third branch of the Entity Decision Flowchart, which means we want to create a new Thing Template.
Following this rule, here is the resulting template:
Group 3 - "Hazardous Asset"
The third group represents line assets that require emergency shutdown capabilities because under certain conditions, the machinery can become dangerous.
We will call these Hazardous Assets.
If we look at our two previous Thing Templates, we can see that there is full overlap of these Components with our previous largest group, the "Line Asset" Thing Template.
This represents the fourth branch of the Entity Decision Flowchart, which means we want to create a CHILD Thing Template.
Following this rule, here is the resulting Thing Template:
Group 4 - "Inventory Manager"
The fourth group represents line assets that keep track of inventory count, to ensure the number of assembled-products is equal to the number of checked-products for quality.
If we look at our existing Thing Templates, we can see that there is some overlap of the Components in our "Hazardous Asset" and "Line Asset" Thing Templates.
This represents the second branch of the Entity Decision Flowchart, which means we want to create a Thing Shape.
Following this rule, here is the resulting Thing Shape:
Templates for Unique Components
Now that we have handled all our shared component groups, we also want to look at the unique component groups. Since we have already established that each group in our Unique Thing-Component Matrix does not share its Components with other Things, we can create Child Thing Templates for these line assets.
NOTE: Refer to the finished design at the bottom to reference all of the inherited Thing Templates and Thing Shapes for these Child Thing Templates.
Adding Components Directly to Things
In many cases, we will have Components that only exist for a single Thing. This frequently occurs when there will be only one of something in a system. In our case, we will only need one "System Connector" for each of the Maintenance System and the Production Order System.
Instantiate Your Things
At this point, the Data Model is fully built. All we need to do now is instantiate the actual Things which represent our real-world machines and digital-connections.
Step 10: Validate
The final step of the model breakdown design process is validation through instantiation.
This is the process by which we take our designed Thing Templates / Thing Shapes / Things and actually create them on the ThingWorx platform to ensure they meet all of our requirements.
This is done by tracing back through the chain of inheritance for all the Things in the data model to ensure they contain all of the required Components from the Thing-Component Matrix.
Once we have verified that each Thing contains all of its requirements, the data model is complete.
Using this technique on each of your Things, you can explicitly prove that all of the requirements have been met.
Step 11: Next Steps
Congratulations!
You've successfully completed the Design Your Data Model Guide covering the first three steps of the proposed data model design strategy for ThingWorx.
This guide has given you the basic tools to:
- Create user stories
- Identify endpoints in your system
- Break down your data model using an Entity Relationship Diagram
- Decide when to use Thing Templates vs. Thing Shapes vs. directly-instantiated Things
The next guide in the Design and Implement Data Models to Enable Predictive Analytics learning path is Data Model Implementation.
