If you're designing your Reltio data model and trying to decide between standard relationships and reference attributes, this one's for you. In Reltio, reference attributes offer a powerful mechanism to model relationships between entities while exposing select relationship or related-entity data directly within the referencing entity. However, like any design choice, they come with their own trade-offs.
This post outlines the key advantages and drawbacks of using reference attributes in Reltio to help architects and data stewards make informed decisions.
✅ Pros of Using Reference Attributes
1. Faster Read Performance
Without reference attributes, you'd typically use connections or searchConnections endpoints for traversing connected entities, which can be slower. With reference attributes, the attributes of both the relationship and the related entity are persisted directly on the referencing entity. This means you get all the information in a single, much faster Get /Entities API call.
2. Improved Match Rule Flexibility
The attributes brought in via reference attributes can be directly used in match rules, enabling richer and more accurate match logic that spans across related entities.
3. Enhanced Search Capabilities
Reltio's out-of-the-box UI doesn't support searching based on relationship attributes. Reference attributes bridge this gap by exposing those attributes at the entity level, making them searchable through the standard search interface.
4. Simplified Data Loads
Reference attributes simplify the data loading process by allowing the creation or update of two entities and their connecting relationship via a single API call. This is especially useful during bulk ingestion or real-time integration scenarios.
5. Improved User Experience
Instead of requiring users to click through to another entity’s profile, the referenced attributes can be shown inline on the current profile. This reduces friction and improves visibility of connected data.
6. More Flexible Relationship Management
Reference attributes allow the ability to change the start/end object of the same relational crosswalk type/value. Relationship loads would throw an error.
❌ Cons of Using Reference Attributes
1. Unwanted Event Propagation
Updates to a referenced entity trigger ENTITY_CHANGED events on all referencing entities. In event-driven architectures, this can create noisy or unnecessary updates and slow down downstream consumers of change events.
2. Disconnect Between UI and Backend
Deleting a reference attribute does not delete the underlying relationship. This may lead to confusion for users who expect a full unlinking of entities when the reference is removed.
3. Write Performance Overhead
Writes involving reference attributes can be 10–15% slower, due to the additional overhead of maintaining synchronization between entities and their references. This is a trade-off to consider, especially for write-heavy operations
4. Lack of DVF Support
As of today, Data Validation Framework (DVF) rules cannot be applied to reference attributes. This limits the enforcement of data quality checks at the API or UI level for these fields.
5. Search and Save Latency with High Volume
Entities with a large number of reference attributes may experience higher latency during search and save operations, compared to entities that use fewer or no reference attributes.
6. Reduced MatchFieldURI Efficiency
When relevant attributes are spread across both the entity and the relationship, the ability to de-duplicate multiple values (like MatchFieldURI) cannot be leveraged effectively. This can complicate data quality efforts for certain scenarios.
Final Thoughts
Reference attributes in Reltio offer a compelling way to expose and utilize relationship data without complex traversal or UI interactions. They’re particularly effective for optimizing read performance and improving usability. However, these benefits come at a cost, particularly in write performance, event management, and data modeling complexity.
As with any design decision in MDM, whether to use reference attributes should be context-driven, based on your performance needs, integration patterns, and user experience goals.
Have you encountered other nuances with reference attributes? Share your experiences in the comments or reach out to continue the conversation.
#Blog
#Featured