Using a Common Data Model

Guidance for adhering to a Common Data Model and examples of how to create one.

What is a Common Data Model?

A Common Data Model provides a collection of standardized and expandable data schemas. These predefined schemas cover various types of data, including operational artifacts, physical artifacts, reference materials, and logs of events. By representing widely used concepts and activities, such as Work Orders and Units, these schemas make it easier to create, compile, and analyze data. This standardization helps streamline data handling across different systems.

Common Data Model in Composability

Tulip Tables play a crucial role in handling data flows and maintaining the connection between applications. They contain information that is displayed in applications and applications are creating, updating and deleting Table Records. If multiple applications are using the same tables, they can communicate with each other through tables.

When designing a solution for a given problem, defining the tables that are going to be used is one of the most importance steps. Choosing tables logically can result in a simpler, more reusable, and composable applications. If the right amount of data is stored in tables, the app builder can reduce the number of used app variables, making the application less complex and easy to customize. If the applications within a solution are using the same set of tables, the apps become interchangeable or composable, without having to redesign one or the other application.

Common Data Model Example

Tulip Tables should primarily follow the Digital Twin model, meaning tables should reflect the physical plant or shop floor as strictly as possible. Historical app data should be confined to Completion Records, ensuring tables are not used to store master data or duplicate data from Completion Records or external records.

Primary Table Types

Ideally, tables should represent physical and operational artifacts.

These tables will always include a Status field that will be regularly updated by apps.

Physical Artifacts

Physical artifacts are tangible objects in your facility or components that are used or produced during operations.

Examples:

• Inventory Items
• Units
• Locations
• Stations
• Equipment & Assets

Operational Artifacts

Operational artifacts are tangible or intangible elements or components that enable or support operations.

Examples:

• Material Requests
• Defects
• Kanban Cards
• Work Orders
• Actions

Secondary (Advanced) Table Types

The following secondary table types do not fit within a Digital Twin model and should only be considered by advanced users. You should only include Reference or Log tables once you've gone through the Solution Design process and exhausted all other options. These tables should never serve as the foundation for an app solution.

Logs

Event Logs are information that can be looked up and defines something in production. These are often found in external systems such as an ERP.

Examples:

• Notes & Comments
• Genealogy Records
• Station Activity History
• Inspection Results

References

References are shared ledgers between applications. This is similar to the concept of a completion record except that it is shared across applications and makes accessible Table Queries, Aggregations and the mutability of Tulip Tables.

Examples:

• Material Definitions
• Bill of Materials

Build your own Common Data Model

Tulip’s example Common Data Model is designed to be a starting point to build your data model. However, all processes and solutions are different and, like applications, the data model can be customized as needed.

Smaller changes include adding and removing fields from the tables. In some cases (special processes, multiple tables needed for the same use case) major changes are required. This can be done by substituting one or more tables from the downloaded data model or inserting additional tables.

Plan a Common Data Model

1. Define the physical and operational artifacts of your process
2. Find the respective tables for each artifact
3. Explore the types of data to be collected by the applications and the references that need to be used

Further Reading

• Data Storage
• Common Tulip Tables
• Best Practices for Storing Data in Tulip