OpenBOM Data Management

Explore, learn and understand the advanced data management foundations in your OpenBOM account

Overview

This article is an advanced overview of OpenBOM data management. Please read OpenBOM Basics first before reading this help article.

OpenBOM data management architecture is multi-tenant. The data organization is flexible and allows changes to data in real time. The administration of rights is distributed based on the access levels – public, company, team, and user levels.

OpenBOM is using polyglot persistence data architecture. It includes the use of multiple databases to store and manage data such as MongoDB, Neo4j, Elastic and other databases.

Multi-Tenant Architecture

OpenBOM has five different access levels: site (e.g. openbom.com), public, company, team, and user levels.

Site access is top-level in the hierarchy and provides access to all platform functions. The site is managed by site administrators. For enterprise subscriptions, the customer has access to site administration. For a multi-tenant organization, site access is restricted to OpenBOM administrators and DevOps administration. The public data level is available to all OpenBOM users of the specific OpenBOM site. It includes a set of predefined system properties and public property definitions and templates. The company, Team, and User – are custom access layers managed by subscriptions. You can create a user by registering for OpenBOM online (openbom.com). Team and Company levels are managed by Team/Company Administrator Roles. Each Administrator of their own Team or Company has tools to create users and manage their access rights.

Property, Property Types, and Property Tables

The basic data element of OpenBOM is a property. There are predefined data properties in OpenBOM: Text, Number, List, Multi-selection List, Date, Currency, Reference, and Image. Read more about properties here

OpenBOM defines properties in property tables. There are public and private properties in OpenBOM. Public property definition can be used by any user (like a template). Privately defined properties are organized using private property tables and limited to a specific account. Access to private property tables is restricted to user, team or company (based on the way each property table is defined). Read more about public and private properties here

If you use OpenBOM Team or Company plan the best practice is for the admin to create a property table with all properties you plan to use by the team. The property table defined by the admin is automatically shared with all team/company users.

Data Types and Objects (Tables)

The foundational element of OpenBOM data architecture is the data type (class). The data type defines the data elements, unique IDs, relationships, and specific behaviors of each data type. The simplest example of a data type is a table with properties, unique ID, and functions. The data type organization is flexible and can allow adding properties in real time.

OpenBOM has predefined data types available for users of all levels. Administrator can create custom object types for different needs (eg. manage requirements, tasks, projects, etc.) Read more about in our documentation about Custom Object Types.

Data Identification and Unique IDs

Each data type in OpenBOM defines the ID used to uniquely identify data records. You can see the list of IDs used in predefined data types below.

Predefined Data Types

These are predefined data types currently available in OpenBOM:

Bill of materials (BOM)
Items (Catalogs)
Vendors
Order BOMs
Purchase order
Change request
Others (see the new data types enabled including custom objects)

You can access data objects of specific data types from OpenBOM user interface.

Table of IDs:

BOM – Part number
Items – Part number
Vendors – Vendor number
Order BOM – Part number
Purchase Order – Number
Change Request – CR number

Part Number Uniqueness

Part number is a unique identifier of items in the OpenBOM data model. It is used for all relationships. The uniqueness of part numbers is managed on 2 different levels: Catalog and Company.

Relationships

Engineering and manufacturing data is highly structured. Therefore, relationships are extremely important in OpenBOM data organization. OpenBOM is using graph databases to organize and manage relationships. OpenBOM has predefined and custom data relationships.

Predefined Relationships

There are three main predefined relationship types in OpenBOM. These relationships are the foundation of the product information model in OpenBOM:

Reference-instance relationships
Structure (parent-child relationship)
References

Read more about the OpenBOM reference instance model here (https://help.openbom.com/get-started/understand-openbom/)

Reference-Instance Relationships

The fundamental element of the product and bill of materials organization is relationships between an item (e.g. part) and instances of the part. Think about an item as an abstract product element that can be a standard or engineering part (e.g. screw, resistor, wheel, engine, etc.). An instance is created when an item is inserted in a specific bill of materials.

Structures and Parent-Child Relationships

OpenBOM has a mechanism of automatic parent-child relationship management based on part numbers defined for each item. This mechanism automatically creates parent-child relationships based on BOM part numbers and part numbers of items included in each bill of materials. In such a way, OpenBOM allows the organization of product structures of infinite depth. There is no limit to the number of levels in the bill of materials.

Reference Properties

A generic mechanism of links between different elements of data in OpenBOM can be organized using reference property. Each reference property contains a link to another resource (via URL). This resource can be an OpenBOM data type (e.g. BOM) or a specific external resource (e.g. Part Catalog URL) Learn more about reference properties in this property types article.

Custom Relationships

OpenBOM is managing multiple custom relationships between data elements to manage data. For the moment custom relationships between data elements are restricted to OpenBOM internal use. In the future releases of OpenBOM, the custom relationships will be exposed to administrators and public APIs.

Changes and Revision Management

OpenBOM provides an embedded mechanism to track changes and revision control for parts and bills of materials. It includes changing history for all data types and a special revision mechanism.

Change History

Each data type in OpenBOM automatically collects a history of changes for each operation in OpenBOM (e.g. add a property, add an item, change property, etc.). The information is available to all users of the system based on the access right.

Revisions

A special revision mechanism allows creating immutable data type records (e.g. BOM revisions) to store an entire data object history (snapshots). This way the BOM revision mechanism allows us to save snapshots of BOMs automatically, number them (1,2,… n) and provide access to these revisions and their history at any time.

Revision and Graph Data Representation

The following diagram shows you the simple data structure in OpenBOM graph of relationships and how revisions applied to this model. This is the product structure (with no revisions yet)

This is the graph model with revisions:

Multilevel Revision Mechanism

OpenBOM supports automatic revision-based relationships based on parent-child relationships, which allows you to track usage of a specific BOM revision in parent assemblies. For the moment [06/2020], OpenBOM automatically connects the latest revision of a BOM to its parent when a new parent BOM revision is created.

To learn more about the revisioning process in OpenBOM, check out this webinar.

Business Logic and BOM Synchronizations

Special product information and business logic are provided in OpenBOM to support relationships between some data types and data elements. It includes real-time synchronization between different predefined data types and data elements.

Multiple BOMs and Synchronization

There is a special relationship between the bills of materials and order BOMs. To understand these relationships first check OpenBOM’s introduction to the process.

OpenBOM can automatically create order (planning) BOMs based on each selected bill of materials. The process of creation includes quantity rollup (flattened BOMs) combined with the mechanism of inventory control to calculate required and gap quantities for each part. Check more about how it works here.

OpenBOM automatically updates order BOMs based on the changes made in the bill of materials in such a way that the order BOM can merge changes done in the bill of materials.

Order BOM and Purchase Orders

Purchase order data type holds are a predefined static data set created from the order BOM to represent a list of parts that needs to be provided for an order BOM filtered for a specific vendor. Read more about it here

User-Defined Views

A user-defined view is a mechanism to support a specific visualization of data types in OpenBOM. Think about it as a “lense” that can allow you to see a subset of information from a specific data type.

Currently, OpenBOM supports user-defined views to be applied to the following data types:

Bill of materials
Order BOMs
Catalogs

Team View Access

To provide multi-user data access in teams and companies, OpenBOM can restrict access to the data in data types using a specially assigned Team View mechanism. This mechanism allows restricting access of users to the set of user-defined views.