Litigations may have several parties involved, in which each party plays a specific role with an associated claim. Since the Claim and Litigation domains are closely related, we will embed fields in the claim domain apart from its identifier. This way, we can have a snapshot of the claim details at the time the litigation was made, so even if the claim details change, we won’t lose the original claim data associated with the litigation.
About this Task
The Litigation domain includes the following key entities:
Litigation: Claim litigation
Litigation Party Role: An associative entity which links the following entities:
Claims
Party Roles
Insurable Objects
Insurable Object Party Role: An associative entity which links the following entities:
Party
Party Roles
Insurable Objects
The relationship between litigations and parties are the facilitated through
the litigation_party_role table, which we will represent in MongoDB by using
an embedded array.
Before You Begin
Refactoring the Litigation domain is the fifth step of the insurance data model example tutorial. Before you refactor the Litigation domain, ensure that you:
Steps
Add mappings for the insurable_object_party_role table
Next to Mappings from relational tables, click Add and select Embedded array. Choose insurable_object_party_role from the Source table drop-down menu. Ensure that the Root path prefix is set to litigationPartyRoles.claim.insurableObjects.
Click Save and close.
Remove collections that are no longer needed
Now that you mapped all the necessary tables to the litigation
document, you can delete the following collections from the MongoDB view
of Relational Migrator:
agreementPartyRolelitigationPartyRoleinsurableObjectinsurableObjectPartyRolelocationAddressinsurableObjectParty
You have modeled the entire relationship schema in just five collections:
partypartyRolepolicyclaimlitigation
Next Steps
Now that you completed your model, you need to migrate the data to your MongoDB instance.