The original PostgreSQL schema represents parties through one-to-one
relationships. The party table holds the common attributes for all parties,
while the other tables store specific information for each party class. These
differences result in distinct fields for each class, which forces tabular
schemas like PostgreSQL to create new tables.
You can embed this information under a single MongoDB party document by
adding mappings for each table in the relational database.
About this Task
A Party includes the following key entities:
Party: Represents people, organizations, and groups.
Party Role: Defines the role of a Party in relation to other objects, such as:
Policy
Claim
Agreement
Litigation
Insurable Object
Communication Identity: Includes information such as the email, phone, and address for a Party.
The following image shows the Entity Relationship Diagram (ERD) for the Party domain:
Before You Begin
Refactoring the Party domain is the second step of the insurance data model example tutorial. Before you refactor the Party domain, connect to your PostgreSQL database in Relational Migrator.
Steps
Add mappings for the party_location_address table
Next to Mappings from relational tables and click Add. Since a party can have many location addresses, select Embedded array. Choose party_location_address from the Source table drop-down menu.
Under the All fields checkbox, uncheck the
partyIdentifier field and click Save and close.
Add mappings for the location_address table
To include the address information within the party_location_address
collection, click Add and select
Embedded documents. Choose location_address from
the Source table drop-down menu.
Under Advanced settings, click the Merge fields into the parent checkbox. This option ensures that the document doesn't have more nested fields than necessary.
Click Save and close.
Remove collections that are no longer needed
Now that you mapped all the necessary tables to the party collection,
you can delete the following collections from the MongoDB view of
Relational Migrator:
personorganizationgroupingpartyLocationAddress
Important
Don't delete the locationAddress collection, as it still has an
existing relationship with the insurable_object table, which we'll
add mapping rules to in a later step.
Your schema
Next Steps
After you map the Party domain, you can refactor the Policy domain. See Refactor the Policy Domain.