Reltio Connect

 View Only

Reltio Data Modeling Part I

By Joel Snipes posted 07-27-2021 18:38

  


The data model is foundational to other pieces in Reltio like matching and survivorship .Let’s start this post with a look at different types of objects stored in Reltio.

At your data model’s high level, there are three types of objects:

  •       Entities - These are used to store objects such as individuals, organizations, or locations. Entities are made up of a collection of attributes. In the relational world these would be your base tables. 
  •       Relationships – Relationships are essentially a pair of Entity IDs and the relevant attributes used to describe the relationship between them. Common examples include EmployedBy, ParentOf, HasAddress. In the relational world these would be your join tables or Associative Entities
  •       Interactions – Interactions are how transactions are stored in Reltio. They used to record point-in-time transactions, such as when a customer calls in, opens an email, or pays a bill. These would be transactional tables in the relational world.
Check out the webinar on Reltio Data Model Tips and Guidelines: 


Your data model is stored in a json document called your L3 along with other supporting configurations such as match rules, cleanse rules, survivorship and more. There are two ways to retrieve your L3: through the API using postman, or through the UI via the console data modeler


Starting at the top level objects of your L3 you will find the following.:

  •     uri – stands for uniform resource identifier. This is the name of the document and will read “configuration”.
  •     schemaVersion –Version of Reltio API Configuration schema used to describe objects.
  •     description – This is an open text field used for notes about the L3. Best practice is to store details of the latest changes here.
  •     sources– This section is where you can define new data sources you would like to bring into Reltio. Once defined here you are ready to load.
  •     label– This holds a human readable description of the model in use. Often the name of the accelerator used for the implementation. 
  •     referenceConfigurationURI – holds the path to the L2 model that your L3 inherits from. L2 models are generally industry specific and are maintained by Reltio. 
  •     entityTypes – This is where your Entities, their attributes and respective data types are defined. If you are coming from a relational background think DDL. EntityType Documentation 
  •     relationshipTypes –This is where your Relationships, their attributes and respective data types are defined. Relationship Documentation 
  •     interactionTypes – This is where your Interactions, their attributes and respective data types are defined. Interaction Documentation




Q: If we’d want to make changes in a lower environment, test it out and then apply it?

A: When you’re ready to migrate, it’s a GET call from your lower environment and a PUT call to your higher environment. This moves everything – data model, cleanse, match, survivorship etc. If you want to move just a piece, you have to cut and paste it into the upper environments L3.

Q: When you’re applying a configuration change, does it affect the tenant with people logged on?

A: It depends on the change. For example, removing an attribute from the model will make it disappear from active users, potentially causing problems. If you add an attribute, it will be available to be populated if a user goes to edit.

Q: If we mess things up, is it easy to reset back to what it was?

A: There is a history command that will pull back the last 10 changes. If you broke something in your config, you can look at the history to see the time stamped last change. Grab everything in the configuration object and post it back. There are also solutions out there like Jenkins, which will automatically post the updated configuration to Reltio for you – keeping you L3 in source control is a best practice.

Q: Should we keep a copy of the config externally?

A: It’s a good idea. You have your stable state in production. Let’s say you’re messing around in DEV and you get something broken, you can always grab your config from PROD, put it back in DEV, and you’re back in a stable state. Storing backups in source control is always a good idea.

Learn More with the Reltio Community

The Reltio Community is a great place to learn more about how to use the Reltio products and connect with Master Data Management peers. Rely on the expertise of Reltio partners, customers, and technical experts.

 


#Featured
#datamodel
#Blog
0 comments
3907 views

Permalink