Modernize seus modelos de dados de seguros com o MongoDB Relational Migrator
Jeff Needham, Luca Napoli, Rami Pinto Prieto14 min read • Published Feb 29, 2024 • Updated Jun 03, 2024
Avalie esse Tutorial
Nas 70e 80s, havia poucas soluções comerciais prontas para uso disponível para muitas funções principais do seguro, de modo que as seguras tiveram que construir seus próprios aplicativos. Esses aplicativos geralmente são baseados em host, o que significa que são tecnologias de mainframe. Essas plataformas legadas incluem linguagens de software como COBOL e CCS. Muitas operadoras ainda estão se esforçando para substituir essas tecnologias herdadas devido a uma confluente de variáveis, como a falta de desenvolvedores com habilidades de programação nessas tecnologias mais antigas e produtos de seguros complicados. Isso resulta em altos custos de manutenção e dificuldade em fazer alterações. Em resumo, sistemas legados são uma barra para o progresso do setor de seguros.
Se você está procurando manter e melhorar os aplicativos existentes ou lançar novos produtos e recursos no mercado, os dados presos nesses sistemas prejudicam a inovação.
Isso é particularmente verdadeiro quando pensamos nos modelos de dados que estão no centro dos sistemas de aplicativos (por exemplo, subscrição), definindo entidades e relacionamentos entre eles.
Neste tutorial, demonstraremos:
- Por que o document model simplifica o modelo de dados de um sistema de seguro padrão.
- Como o MongoDB's Relational Migrator transforma sem esforço um desajeitado esquema de tabela 21em um modelo MongoDB esguio de cinco collection.
Em última análise, isso provará que, com o MongoDB, as seguradoras lançarão novos produtos com mais rapidez, se adaptarão rapidamente às mudanças regulatórias e aprimorarão as experiências dos clientes.
Para fazer isso, vamos nos concentrar no modelo de função do Object Management Group e em como o modelo pode ser portado de uma estrutura relacional para o do MongoDB document model.
Em particular, descreveremos a refatoração de Parte no contexto de Política e Reivindicação e Litígio. Para cada um deles são fornecidos uma breve descrição, um modelo simplificado deHackolade (Entity Relationship Diagrams - ERD) e a refatoração do documento usando Relational Migrator.
Relational Migrator é uma ferramenta que permite:
- Crie um esquema MongoDB efetivo, derivado de um esquema relacional existente.
- Migre dados do Oracle, SQL Server, MySQL, PostgreSQL ou Sybase ASE para o MongoDB, enquanto transforma ao esquema de destino.
- Gere artefatos de código para reduzir o tempo necessário para atualizar o código do aplicativo.
No final deste tutorial, você aprenderá a usar o Relational Migrator para refatorar o modelo de dados relacionais do Party Role e migrar os dados para as collection do MongoDB.
Se você é mais um aprendiz visual, aqui está um vídeo que mostra todas as etapas deste tutorial
- Relational Migrator do MongoDB (versão 1.4.3 ou superior): oMongoDB Relational Migrator é uma ferramenta poderosa para ajudá-lo a migrar volumes de trabalho relacionais para o MongoDB. Baixe e instale a versão mais recente.
- PostgreSQL (versão 16 ou superior): PostgreSQL é um sistema de gerenciamento de banco de dados relacional. Ele servirá como banco de dados de origem para nossa tarefa de migração. Baixe a última versão do PostgreSQL.
- MongoDB (versão 7.0 ou superior): você precisará acessar uma instância do MongoDB com permissões de gravação para criar o novo banco de dados para onde vamos migrar os dados. Você pode instalar a versão mais recente do Servidor da MongoDB Community ou simplesmente implantar um cluster MongoDB Atlas gratuito em menos de três minutos!
Neste tutorial, vamos usar o PostgreSQL como o RDBMS para manter o esquema tabular original a ser migrado para o MongoDB. Para segui-lo, você precisará ter acesso a uma instância do servidor de banco de dados PostgreSQL com permissões para criar um novo banco de dados e usuário. A instância pode estar na nuvem, no local ou em sua máquina local. Você só precisa saber a URL, a porta, o usuário e a senha da instância do PostgreSQL de sua escolha.
Também usaremos dois aplicativos clientes PostgreSQL: psql e pg_restore. Esses aplicativos baseados em terminal nos permitirão interagir com nossa instância de servidor de banco de dados PostgreSQL. O primeiro aplicativo,
psql, permite que você digite consultas interativamente, emita-as no PostgreSQL e veja os resultados da consulta. Será útil criar o banco de dados e executar consultas para verificar se o esquema foi replicado com êxito. Por outro lado, usaremos pg_restore para restaurar o banco de dados PostgreSQL a partir do arquivo disponível no repositório GitHub.Esse arquivo morto contém todas as tabelas, relações e dados de exemplo do modelo de função de participante em um formato tabular. Ele servirá como ponto de partida em nossa jornada de migração de dados.Os pacotes padrão prontos para uso já incluirão o servidor e essas ferramentas do cliente. Recomendamos usar a versão 16 ou superior. Você pode baixá-lo no site oficial de downloads do PostgreSQL ou, se for usuário do macOS, apenas execute o comando abaixo em seu terminal.
Observação: verifique se as ferramentas de banco de dados Postgres foram instaladas com sucesso executando
psql --version e pg_restore --version. Se você vir uma mensagem de erro, verifique se o diretório contendo as ferramentas foi adicionado ao seu PATH.Primeiro, precisamos nos conectar ao banco de dados PostgreSQL.
Se for uma instância local recém-instalada com os parâmetros padrão, você pode usar
127.0.0.1 como seu host, 5432 como a porta, postgres como banco de dados e digitar whoami em seu terminal para obter seu nome de usuário padrão, se não houver outro foi especificado durante a instalação do servidor de banco de dados PostgreSQL.Depois de conectado, precisamos criar um banco de dados para carregar os dados.
Em seguida, criaremos o usuário que terá acesso ao novo banco de dados, para que não precisemos usar o usuário root no Relational Migrator. Lembre-se de alterar a senha no comando abaixo.
Por fim, preencheremos o banco de dados com o modelo Party Role, um padrão amplamente utilizado no setor de seguros para definir como pessoas, organizações e grupos estão envolvidos em acordos, apólices, sinistros, objetos seguráveis e outras entidades importantes. Isso não apenas replicará a estrutura, as relações e a propriedade da tabela, mas também carregará alguns dados de exemplo.
- Navegue até a pasta onde o arquivo é baixado usando seu terminal.
- Execute o comando abaixo no seu terminal para carregar os dados. Lembre-se de alterar o host, a porta e o usuário antes de executar o comando.
Após alguns segundos, nosso novo banco de dados estará pronto para uso. Verifique a restauração bem-sucedida executando o comando abaixo:
Você deve ver uma lista de tabelas 21 semelhante à da figura abaixo.
Se tudo parecer bem, você estará pronto para conectar seus dados ao MongoDB Relational Migrator.
Abra o aplicativo Relational Migrator e clique no botão “New Project”. Iniciaremos um novo projeto do zero, conectando-nos ao banco de dados que acabamos de criar. Clique em "Connect database," selecione "PostgreSQL" como o tipo de banco de dados e preencha os detalhes da conexão. Teste a conexão antes de continuar e, se o teste de conexão for bem-sucedido, clique em “Connect.” Se um erro “no encryption” for exibido, clique em SSL → ativar SSL.
Na próxima tela, selecione todas as tabelas 21 do esquema OMG e clique em “Next.”. Nessa nova tela, você precisará definir seu esquema inicial. Começaremos com um esquema MongoDB que corresponde ao seu esquema relacional. Deixe as outras opções como padrão. Em seguida, forneça um nome ao projeto e clique em "Done. "
Isso gerará um esquema que corresponde ao original. Ou seja, teremos uma coleção por tabela no esquema original. Este é um bom ponto de partida, mas como vimos, uma das vantagens do document model é que ele consegue reduzir essa complexidade inicial. Para isso, usaremos uma abordagem de modelagem de objetos. Vamos nos concentrar em quatro objetos de alto nível que servirão como ponto de partida para definir todo o esquema: Parte, Política, Reclamação e Litígio.
Por padrão, você verá uma visualização dividida horizontal do modelo Relacional (parte superior) e MongoDB (parte inferior). Você pode alterar o modelo de visualização no menu “View” do canto inferior esquerdo. Observe que todas as etapas a seguir no tutorial serão executadas na visualização MongoDB (MDB). Sinta-se à vontade para alterar o modo de visualização para “MDB” para uma visão de trabalho mais espaçosa.
A área de assunto da parte (figura 3.) mostra que todas as pessoas, organizações e grupos podem ser representados como "parties " e as partes podem então ser relacionadas a outros objetos principais com funções especificadas. O design de partes também fornece uma abordagem comum para descrever identificadores de comunicação, relacionamentos entre partes e identificadores legais.
Para ilustrar o processo de forma mais simples e clara, reduzimos o número de objetos e construímos um novo ERD no Relational Migrator (Figura 4). Esses modelos são implementados com mais frequência em sistemas transacionais em tempo de execução. Seu impacto e dependências podem ser encontrados em vários sistemas e domínios. Além disso, eles podem resultar em objetos de banco de dados físicos muito grandes, e os padrões centralizados de armazenamento e acesso podem ser gargalos.
As principais entidades do Partido são:
O partido representa pessoas, organizações e grupos. No esquema original, isso é representado por meio de relacionamentos um a um. Party contém os atributos comuns a todas as partes, enquanto cada uma das outras três tabelas armazena as particularidades de cada classe de parte. Essas diferenças resultam em campos distintos para cada classe, o que força os esquemas tabulares a criar novas tabelas. A flexibilidade inerente do document model permite incorporar essas informações em um único documento. Para fazer isso, siga as etapas abaixo:
- Selecione a collection "party" na visualização MDB do Relational Migrator. No momento, esta collection tem os mesmos campos que a tabela correspondente original.
- No lado direito, você verá o menu de mapeamentos (Figura 5). Clique no botão "Add", selecione "Embedded documents," e escolha "pessoa" no menu suspenso "Source table". Clique em "Save and close" e repita esse processo para as tabelas "organização" e "agrupamento".
- Depois disso, você pode remover a collection de "personalidade", "organização" e "agrupamento". Clique com o botão direito neles, selecione "Remove Entity," e confirme "Remove from the MongoDB model." Você já simplificou seu modelo original em três tabelas e estamos apenas começando.
Observando a Figura 4, podemos ver que há outra entidade que pode ser facilmente incorporada na collection de festas: endereços de localização. Nesse caso, a tabela tem um relacionamento de muitos para muitos facilitado pela tabela "party_location_address". Como uma parte pode ter muitos endereços de localização, em vez de um documento incorporado, usaremos uma array incorporada. Você pode fazer isso da seguinte maneira:
- Selecione a collection "party" novamente, clique no botão "Add ", selecione "Embedded array, " e escolha "party_location_address" no menu suspenso "Source table ". Na caixa de seleção "All fields ", desmarque o campo
partyIdentifier. Não vamos precisar disso. Os endereços estarão contidos no documento "party " de qualquer maneira. Deixe os outros campos como padrão e clique no botão “Save and close”. - Agora estabelecemos o relacionamento, mas também queremos ter os detalhes do endereço. No menu de mapeamento “party”, clique no botão “Add” novamente. Em seguida, selecione "Embedded documents, ", escolha "location_address, " e na seção "Root path ", marque a caixa que diz "Merge fields into the parent. " Isso garantirá que não tenhamos mais campos aninhados do que o necessário. Clique em "Save and close."
- Agora você pode excluir a coleção "party_location_address ", mas não excluir "location_address ", pois ela ainda tem um relacionamento existente com "insurable_object. "
Você acabou. A entidade "party " está pronta para Go. Não apenas reduzimos seis tabelas a apenas uma, mas os documentos incorporados "person, " "organization, " e "grouping " só aparecerão se essa parte for de fato uma pessoa, organização ou agrupamento. Uma coleção pode conter documentos com esquemas diferentes para cada uma dessas classes.
No início da seção, também conversamos sobre a entidade "party role ". Representa a função que uma parte desempenha em um contexto específico, como política, reivindicação ou litígio. No esquema original, esse relacionamento de muitos para muitos é facilitado por meio de tabelas intermediárias como "policy_party_role, "claim_party_role, " e "litigation_party_role ", respectivamente. Essas tabelas intermediárias serão incorporadas em outras coleções, mas a tabela "party_role" pode ser deixada de fora como uma coleção de referência por conta própria. Dessa forma, evitamos ter que atualizar um por um todos os documentos de apólice, reclamação e litígio se um dos atributos de "party role" mudar.
Vejamos a seguir como podemos modelar a entidade "policy ".
As principais entidades da Política são:
De uma perspectiva de alto nível, podemos observar que a entidade “policy” é composta pelas partes da cobertura da política e pelos acordos de cada uma das partes envolvidas com suas respectivas funções. Uma política pode ter várias partes a serem cobertas e vários acordos com partes envolvidas. Portanto, da mesma forma que o que aconteceu com os endereços de localização de partes, eles serão combinados com incorporações de array.
Vamos começar com os acordos de festa. Uma política pode ter muitas partes envolvidas e cada parte pode fazer parte de muitas políticas. Isso resulta em um relacionamento de muitos para muitos facilitado pela tabela "policy_party_role ". Essa tabela também abrange as relações entre funções e acordos, pois cada parte desempenhará uma função e terá um acordo em uma política específica.
- Na visualização MDB, selecione a coleção “policy. Clique no botão "Add ", selecione "embedded array, " e escolha "policy_party_role " no menu suspenso da tabela de origem. Desmarque o campo
policyIdentifier, deixe os outros campos como padrão e clique em "Save and close. " - Deixaremos o partido como um objeto referenciado à collection “party” que criamos anteriormente, portanto não precisamos realizar nenhuma ação adicional sobre isso. O relacionamento permanece no novo modelo através do campo
partyIdentifieratuando como chave estrangeira. No entanto, precisamos incluir os acordos. No menu de mapeamento “policy”, clique em “Add,”, selecione “Embedded document,”, escolha “agreement” como tabela de origem, deixe as outras opções como padrão e clique em “Save and close.” - Neste ponto, podemos remover as collections "policy_party_role " e "agreement. " Lembre-se de que definimos "party_role " como uma collection de referência separada, portanto, apenas ter
partyRoleCodecomo identificador na tabela de destino seja suficiente.
A seguir, incluiremos as partes de cobertura da apólice.
- No menu de mapeamento "policy ", clique em "Add, ", selecione "Embedded array, ", escolha "policy_coverage_part " como a tabela de origem, desmarque o campo
policyIdentifier, deixe as outras opções como padrão e clique em "Save and close.” - Cada parte da cobertura tem detalhes incluídos em "policy_coverage_detail". Adicionaremos isso como uma matriz incorporada dentro de cada parte da cobertura. No menu de mapeamento "policy", clique em "Add,", selecione "Embedded array,", escolha "policy_coverage_detail," e certifique-se de que o prefixo selecionado na seção "Root path" seja
policyCoverageParts. Remova os campospolicyIdentifierecoveragePartCodee clique em "Save and close." - Os detalhes da cobertura incluem "limits, " "deductibles, " e "insurableObjects. " Vamos adicioná-los! Clique em "Add " no menu de mapeamento "policy ", "Embedded Array, " escolha "policy_limit, " remova o
policyCoverageDetailIdentifier" e clique em "Save and close. " Repita o processo para "policy_deductible. " para “insurable_object, " repita o processo, mas selecione "Embedded document " em vez de "Embedded array. " - Como você pode ver na Figura 8, os objetos seguráveis têm relações adicionais para especificar o endereço e as funções desempenhadas pelas diferentes partes. Para adicioná-los, basta incorporá-los da mesma forma que fizemos até agora. Clique em "Add" no menu de mapeamento "policy", selecione "Embedded array," e escolha "insurable_object_party_role." Essa é a tabela usada para facilitar o relacionamento de muitos para muitos entre os objetos seguráveis e as funções do partido. Desmarque
insurableObjectIdentifiere clique em "Save and close." A parte será referenciada pelo campopartyIdentifier. Para simplificar, não incorporaremos os detalhes do endereço aqui, mas lembre-se de que, em um ambiente de produção, você precisará adicioná-lo de forma semelhante à que fizemos anteriormente na collection "party". - Depois disso, podemos remover com segurança as collections "policy_coverage_part, "policy_coverage_detail, " "policy_deductible, " e "policy_limit. "
Agora, devemos ter uma collection semelhante à abaixo e cinco tabelas a menos do nosso modelo original.
As principais entidades do Claim and Litigation são:
Nesse domínio, já identificamos as duas principais entidades: reclamação e litígio. Nós os usaremos como documentos de nível superior para refatorar os relacionamentos mostrados na figura 10 de uma forma mais intuitiva. Vamos ver como você pode modelar declarações primeiro.
- Começaremos a incorporar as partes envolvidas em uma reclamação com suas respectivas funções. Selecione a coleção "claim", clique em "Add" no menu de mapeamento, selecione "Embedded array," e escolha "claim_party_role" como a tabela de origem. Você pode desmarcar
claimIdentifierna lista de campos. Por último, clique no botão "Save and close". - Em seguida, integraremos o objeto segurável que faz parte do seguro. Repita a etapa anterior, mas escolha "Embedded documents" como a opção de migração da tabela e "insurable_object" como a tabela de origem. Mais uma vez, não incorporaremos a entidade "location_address " para mantê-la simples.
- Em
insurableObject, incluiremos os detalhes da cobertura da apólice, estabelecendo o vínculo entre sinistros e apólices. Adicione um novo mapeamento, selecione "Embedded array,", escolha "policy_coverage_detail" como a tabela de origem e desmarque o campoinsurableObjectIdentifier. Deixe as outras opções como padrão. - Por fim, recriaremos o relacionamento de muitos para muitos entre o litígio e a reclamação. Como teremos uma entidade de litígio separada, só precisamos fazer referência a essa entidade no documento de reclamações, o que significa que basta ter uma matriz de identificadores de litígio. Repita a etapa anterior selecionando "Embedded array," "litigation_party_role," e desmarcando todos os campos, exceto
litigationIdentifier, na lista de campos.
O modelo de reivindicação está pronto para Go. Agora podemos remover a coleção "claimPartyRole."
Vamos continuar com a entidade de contencioso. Os litígios podem ter várias partes envolvidas, cada uma desempenhando um papel específico e com uma reivindicação associada específica. Este relacionamento é facilitado através da coleção “litigation_party_role. Vamos representá-lo usando uma array incorporada. Além disso, incluiremos alguns campos no domínio da reivindicação além de seu identificador. Isso é necessário para que possamos ter um instantâneo dos detalhes da reivindicação no momento em que o litígio foi feito, portanto, mesmo que os detalhes da reivindicação sejam alterados, não perderemos os dados originais da reivindicação associados ao litígio. Para fazer isso, siga as etapas abaixo:
- No menu de mapeamento "litigation ", clique no botão "Add ", selecione "Embedded array, " e escolha "litigation_party_role " como a tabela de origem. Remova
litigationIdentifierda lista de campos e clique em "Save and Close. " - De forma semelhante, adicione detalhes da reivindicação adicionando "claim " como "Embedded document. "
- Repita o processo novamente, mas escolha "insurable_object " como a tabela de origem do documento incorporado. Certifique-se de que o prefixo do caminho raiz esteja definido como
litigationPartyRoles.claim. - Por fim, adicione “insurable_object_party_role” como “Embedded array.” O prefixo do caminho raiz deve ser
litigationPartyRoles.claim.insurableObject.
E é isso. Modelamos todo o esquema de relacionamento em apenas cinco coleções: “party, " "partyRole, " "policy, " "claim, " e "litigation. " Você pode remover o restante das coleções e comparar a original esquema tabular composto de tabelas 21 para as cinco collections resultantes.
Agora que nosso modelo está completo, só precisamos migrar os dados para nossa instância do MongoDB. Primeiro, verifique se você tem permissões do "dbAdmin " no banco de dados OMG de destino. Você pode verificar e atualizar permissões no menu de segurança do lado esquerdo do Atlas na seção “Database Access.
Depois de fazer isso, navegue até aData Migration aba " " na barra de navegação superior e cliqueCreate sync job. em " ". Você será solicitado a adicionar os detalhes do banco de dados de origem e destino. No nosso caso, estes são PostgreSQL e MongoDB respectivamente. Preencha os detalhes e clique em " "Connect em ambas as etapas até chegar àMigration Options etapa " ". Neste menu, deixaremos todas as opções como padrão. Isso migrará nossos dados para o modo de snapshot, oque significa que carregará todos os nossos dados de uma só vez. Sinta-se à vontade para verificar nossa documentação para obter mais alternativas de tarefas de sincronização .
Por fim, clique no botão “Start” e aguarde até que a migração seja concluída. Isso pode levar alguns minutos. Quando estiver pronto, você verá a marcação "Completed " no cartão do estado do snapshot. Agora você pode se conectar ao seu banco de dados no MongoDB Atlas ou Compass e verificar como todos os seus dados estão carregados no MongoDB, prontos para aproveitar todas as vantagens do document model.
Parabéns, você acabou de concluir sua migração de dados! Não simplificamos apenas o modelo de dados de um sistema de seguro padrão; modernizamos significativamente a forma como as informações fluem no setor.
Do lado técnico, o Relational Migrator do MongoDB realmente é um divisor de águas, transformando facilmente um pesado esquema de tabela 21em um modelo simples do MongoDB de cinco coleções. Isso se traduz em operações de dados mais rápidas e eficientes, tornando-se um sonho para desenvolvedores e administradores.
Do lado dos negócios, visualize a agilidade obtida — time-to-ride mais rápido para novos produtos de seguros, rápida adaptabilidade às mudanças regulatórios e experiências aprimoradas do consumidor.
O resultado final? O document model do MongoDB e o Relational Migrator não são apenas ferramentas; eles são os catalisadores de um cenário de seguros ágil e pronto para o futuro.
Se você quiser saber como o MongoDB pode ajudá-lo a se modernizar, migrar para qualquer nuvem e adotar o futuro dos seguros orientado por IA, confira os recursos abaixo. O que você construirá a seguir?
Principais comentários nos fóruns
Ainda não há comentários sobre este artigo.