Unify and manage your data

Schema simplification for Data Share

Learn how schema simplification shapes Reltio’s hierarchical model into a simplified format for analytics and AI workloads.

Data Sharing supports two modes for sharing data with the supported cloud data warehouses:

  • Simplified schema (OV only) — Golden record values are flattened into a predictable and query-friendly structure.
  • Hierarchical schema (All values) — All values, including non-OV, are shared in the full nested hierarchy. This preserves complete fidelity but may require custom transformations before use in BI or AI workloads.

When to use schema simplification

Schema simplification is designed for analytics and AI use cases where you need:

  • Support for OV values only

When to use hierarchical sharing

Hierarchical sharing is available when you need:

  • Complete access to all values, including non-OV
  • Direct access to the full JSON hierarchy, even if it requires downstream transformation

How attributes are represented

The following table summarizes how simple, nested, and reference attributes are shared in a simplified schema format for OV only values.

Survivorship rules determine whether each attribute is treated as a single value or a multiple value attribute. If the survivorship rule of an attribute is aggregation, the attribute will be considered as a multiple value attribute. For other survivorship rules, the attribute will be considered as a single value attribute.

Attribute typeSingle ValueMultiple Value
Simple attributeThe column stores a simple value. For example: "Reltio". It will be of the same data type as the attribute In case of an attribute having multiple OV values, only the first value based on attribute ordering is shared Column stores an Array of simple values. For example:
["Reltio","Reltio Inc."]
Nested Or Reference attribute Data is stored as an array of each instance of the Nested attribute with a maximum nested depth of two levels. For example, if Address is a nested attribute, and there are 2 addresses, then the shared data would look like:
[ { Address 1 }, { Address 2 } ] 
where Address 1 and Address 2 are nested instances of Address. Each Address instance will be further represented as a key-value pair. For example:
[ 
	{ Type: "Business Phone", Phone: "123"},
	{Type: "Work", "Phone: 456"} } 
]
Data is stored as an array of each instance of the Nested attribute with a maximum nested depth of two levels. For example, if Address is a nested attribute, and there are 2 addresses, then the shared data would look like:
 [ { Address 1 }, { Address 2 } ] 
where Address 1 and Address 2 are nested instances of Address. Each Address instance will be further represented as a key-value pair where value would be array of values. For example:
[ 
	{ Type: "Business Phone", Phone: ["123","789"] },
	{Type: "Work", "Phone: 456"} } 
]

Design choices

The simplified schema avoids approaches that make queries unstable or costly:

  • No full flattening, prevents an infinite number of columns as nested attributes evolve
  • No row explosion, prevents large multiplications of rows for entities with multi-value attributes
  • Arrays for multi-values , keep the schema consistent and predictable across changes