Gestão de Metadados para Sistemas de Dados Multidecadais

O campo TRANS-AMT-CD Em um programa COBOL, está em produção desde 1981. A entrada FD o define como PIC S9(9)V99 COMP-3Um campo numérico decimal compactado com sinal, onze dígitos e duas casas decimais implícitas. Esses são os metadados técnicos. Os metadados de negócio, o que TRANS-AMT-CD realmente significa, em qual moeda é denominado, se as duas casas decimais implícitas representam centavos ou pontos-base, se um valor negativo representa um crédito ou um débito e como um valor zero deve ser interpretado, não existem em lugar nenhum no código-fonte. Existiam em um documento de especificação funcional impresso em 1981, arquivado em um arquivo e nunca mais visto. Os dois desenvolvedores que originalmente sabiam o que TRANS-AMT-CD significava se aposentaram em 2014.

Essa é a situação dos metadados que toda organização com sistemas de dados de várias décadas enfrenta, e é a situação para a qual as estruturas modernas de governança de dados não foram projetadas. Collibra, Alation, Atlan e todas as outras plataformas de catálogo de dados corporativos são excelentes em governar metadados para dados já descritos, bancos de dados em nuvem com esquemas documentados, data warehouses com semântica de coluna definida e endpoints de API com especificações OpenAPI. Elas não foram projetadas para reconstruir metadados que nunca foram formalmente capturados, que existem apenas no comportamento de programas escritos antes que o gerenciamento de metadados se tornasse uma disciplina, e que foram modificados por dezenas de desenvolvedores ao longo de quatro décadas sem que ninguém atualizasse um registro central do significado de cada campo.

A gestão de metadados para sistemas de dados com várias décadas de existência não é o mesmo problema que a gestão de metadados para sistemas modernos. Requer uma abordagem fundamentalmente diferente, que começa com a extração de metadados dos artefatos de origem, em vez da ingestão de metadados de sistemas conectados.

As três camadas de metadados legados

Para entender o problema dos metadados em sistemas com várias décadas de existência, é preciso reconhecer que, nesses ambientes, os metadados se organizam em três camadas distintas, cada uma com diferentes níveis de extração, completude e implicações de governança.

Os metadados técnicos são a camada mais facilmente extraível. Eles descrevem a estrutura física dos dados: nomes de campos, tipos de dados, comprimentos, posições dentro dos registros, especificações de precisão numérica e os relacionamentos entre os campos dentro de um layout de registro. Em ambientes COBOL, os metadados técnicos existem em artefatos de código-fonte: entradas FD definem layouts de registro, membros COPY definem estruturas de dados reutilizáveis, cláusulas SELECT definem a organização de arquivos e os métodos de acesso, e instruções DD do JCL definem os conjuntos de dados associados a cada execução do programa. Essa camada é, em princípio, legível por máquina; um analisador sintático que entende a sintaxe COBOL pode extraí-la do código-fonte, mas ela está distribuída por milhares de arquivos-fonte, em vez de centralizada em um registro de esquema.

Os metadados operacionais descrevem como os dados se movem pelo sistema: quais programas produzem quais conjuntos de dados, quais programas os consomem, em que sequência e por meio de quais transformações. Em ambientes mainframe, os metadados operacionais são distribuídos entre fluxos de tarefas JCL (que definem sequências de execução e associações de conjuntos de dados), grafos de chamadas de programas (que definem o fluxo de dados entre programas) e a configuração do agendador (que define o tempo e as dependências). Essa camada também pode ser extraída automaticamente dos artefatos de origem, embora a extração exija a compreensão não apenas de programas individuais, mas também das relações entre eles.

Metadados comerciais ou semânticos é a camada menos extraível e mais valiosa. Ela responde às perguntas que os metadados técnicos não conseguem responder: o que significa TRANS-AMT-CD O que isso significa exatamente em termos comerciais? Quais são os valores válidos para ACCT-TYPE-CD E o que cada valor significa? Qual regra de negócio determina quando? CUST-STATUS-FLG transições de A para IEssa camada existe, quando existe, em documentos de especificação, na memória do desenvolvedor, no conhecimento institucional detido por funcionários que podem já ter se aposentado e na lógica procedural de programas que impõem regras de negócio por meio de instruções IF e blocos EVALUATE, em vez de por meio de restrições de banco de dados.

O desafio dos metadados em sistemas com várias décadas de existência reside no fato de que essas três camadas foram gerenciadas de maneiras diferentes, ou sequer gerenciadas, ao longo das décadas de evolução do sistema. Os metadados técnicos foram capturados no código-fonte, mas nunca formalizados em um dicionário de dados. Os metadados operacionais estavam implícitos nos fluxos de tarefas JCL, mas nunca foram documentados como um registro de linhagem. Os metadados de negócios foram documentados nas especificações na época do desenvolvimento inicial e nunca foram atualizados conforme os sistemas evoluíam.

O problema da deriva de metadados

A cada ano que passa, um sistema com várias décadas de existência opera sem uma gestão sistemática de metadados, e a lacuna entre os metadados presentes na documentação formal e os metadados que refletem o comportamento atual do sistema aumenta. Essa discrepância ocorre por meio de quatro mecanismos:

Evolução do significado do campo. Um campo que foi definido com um único significado comercial em 1978 pode ter acumulado significados adicionais ao longo das décadas subsequentes. ACCT-TYPE-CD Pode ser que originalmente existisse uma distinção entre contas correntes e contas poupança. Ao longo de quarenta anos, códigos adicionais podem ter sido acrescentados para representar contas do mercado monetário, certificados de depósito, contas IRA e contas de garantia, cada adição documentada apenas no código do programa que lida com o novo valor do código, e não em qualquer definição de campo central. O nome e o tipo do campo permanecem inalterados; seu significado semântico, porém, tornou-se substancialmente mais complexo.

Reutilização silenciosa. Os campos são ocasionalmente reutilizados sem serem renomeados. Um campo que era usado para uma finalidade torna-se inconveniente para estender, e um desenvolvedor usa um valor anteriormente não utilizado de um campo de sinalização adjacente para codificar uma informação diferente. TRANS-FLAG-1 Agora é possível codificar três conceitos diferentes em contextos de programa distintos, distinguíveis apenas examinando quais programas leem o campo e sob quais condições. Os metadados técnicos — nome do campo, tipo, comprimento — não indicam que o campo esteja semanticamente sobrecarregado.

Acumulação de REDEFINES. Conforme discutido em contextos de análise VSAM, as cláusulas REDEFINES sobrepõem o mesmo armazenamento físico com diferentes interpretações de campo. Cada variante de REDEFINES pode ter sido adicionada em um momento diferente da história do sistema, por desenvolvedores diferentes e para diferentes finalidades de negócio. O significado semântico completo de uma hierarquia REDEFINES, qual variante se aplica em cada situação e o significado dos campos de cada variante, só pode ser reconstruído analisando todos os programas que acessam cada variante e as condições sob as quais o fazem.

Divergência de copybook. Quando um copybook COBOL padrão é modificado para atender a um novo requisito, os programas que incluíam o copybook e não foram atualizados para lidar com o novo campo podem se comportar incorretamente ou simplesmente ignorar o novo campo. Ao longo de décadas de evolução, várias versões do que é nominalmente o mesmo copybook podem existir em diferentes bibliotecas, com diferentes programas usando versões diferentes. Os metadados de um campo definido no copybook podem diferir entre os programas, dependendo da versão do copybook que cada programa inclui.

O que as ferramentas modernas de metadados não conseguem fazer pelos dados legados

O mercado de catálogos de dados corporativos atingiu um nível de maturidade significativo. Collibra, Alation, Atlan, Microsoft Purview e Informatica Axon são plataformas sofisticadas para a governança de metadados em ambientes de dados modernos. Elas se destacam em: descoberta automática de esquemas a partir de bancos de dados conectados, rastreamento da linhagem de dados em nível de coluna em pipelines ETL, manutenção de glossários de negócios com definições de termos selecionadas e exibição de métricas de qualidade de dados juntamente com os registros de metadados.

O que essas ferramentas não conseguem fazer por sistemas COBOL e mainframe com várias décadas de existência:

Não é possível conectar-se ao que não se vê. Os catálogos modernos descobrem metadados por meio de conectores, conexões JDBC com bancos de dados, integrações de API com serviços em nuvem e integrações de scanners com plataformas compatíveis. Arquivos VSAM, programas COBOL e fluxos de tarefas JCL não possuem conectores de catálogo padrão. O catálogo não consegue descobrir o que não tem como alcançar. Os dados gerenciados por esses sistemas são efetivamente invisíveis para o catálogo, o que significa que os registros de linhagem para análises em nuvem subsequentes, derivados desses dados, estão incompletos ou ausentes.

Não é possível extrair metadados que existem apenas no código. Um catálogo de dados conectado a um banco de dados DB2 pode ler o esquema do banco de dados, as definições de tabelas, os nomes das colunas, os tipos de dados e os índices. Ele não consegue ler o programa COBOL que popula a tabela DB2 para entender quais regras de negócio governam a população, quais variantes REDEFINES existem no registro de origem ou quais nomes de condição de nível 88 definem a validade semântica de cada campo. Os metadados em nível de código, a camada onde reside o significado de negócio dos dados legados, exigem análise de código, não varredura de catálogo.

Não é possível reconstruir um significado que nunca foi capturado. Mesmo com uma extração perfeita de metadados técnicos, o significado comercial de campos que nunca foram formalmente documentados não pode ser reconstruído automaticamente. Essa camada requer uma combinação de análise de código (para revelar as regras de negócio que os programas aplicam aos dados, que são indicadores do significado comercial) e revisão humana (para validar o significado reconstruído em relação ao conhecimento institucional enquanto esse conhecimento ainda existe).

A abordagem de reconstrução de metadados

Para sistemas com várias décadas de existência, nos quais os metadados formais nunca foram capturados ou se distanciaram significativamente da realidade atual, o gerenciamento de metadados requer uma fase de reconstrução antes da fase de governança. A abordagem de reconstrução extrai as camadas recuperáveis ​​e identifica as lacunas onde o conhecimento humano é necessário.

Fase 1: Extração de metadados técnicos dos artefatos de origem.

Analise cada entrada COBOL FD, membro COPY, cláusula SELECT e instrução JCL DD para produzir um inventário de metadados técnicos em nível de campo:

cobol

* Source FD entry -- technical metadata extraction target
FD  TRANSACTION-FILE
    LABEL RECORDS ARE STANDARD
    RECORD CONTAINS 200 CHARACTERS.
01  TRANSACTION-RECORD.
    05  TRANS-DATE          PIC 9(8).          *> YYYYMMDD format
    05  TRANS-TYPE-CD       PIC XX.            *> See 88-level values
        88 TRANS-PAYMENT    VALUE 'PM'.
        88 TRANS-REFUND     VALUE 'RF'.
        88 TRANS-ADJUSTMENT VALUE 'AJ'.
        88 TRANS-REVERSAL   VALUE 'RV'.
    05  TRANS-AMT-CD        PIC S9(9)V99 COMP-3.
    05  TRANS-CURRENCY-CD   PIC X(3).          *> ISO 4217
    05  TRANS-DETAIL        REDEFINES TRANS-TYPE-CD.
        10  TRANS-MERCH-ID  PIC X(12).
        10  TRANS-AUTH-CD   PIC X(6).
        10  FILLER          PIC X(84).

A partir dessa única entrada FD, a extração de metadados técnicos produz: nomes de campos, tipos de dados, comprimentos, posições e a precisão decimal compactada de TRANS-AMT-CD (9 dígitos, 2 casas decimais, com sinal), os quatro valores semânticos de TRANS-TYPE-CD conforme definido pelos nomes de condição de nível 88 e pela estrutura REDEFINES que cria duas interpretações sobrepostas dos bytes 10 a 105 do registro.

Os nomes de condição de 88 níveis são particularmente valiosos como metadados: TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL São quatro itens de vocabulário empresarial que o próprio código COBOL fornece, mais significativos do que o código subjacente. PM, RF, AJ, RV Valores que um catálogo de dados que examina o banco de dados veria.

Fase 2: Extração de metadados operacionais a partir das dependências do programa.

Construa o mapa de linhagem operacional rastreando os fluxos de dados através do grafo de dependência do programa:

• Quais programas escrevem para TRANSACTION-FILE (produtores)
• Quais programas leem de TRANSACTION-FILE (consumidores)
• Quais etapas do JCL invocam cada produtor e consumidor, e em que sequência?
• Quais conjuntos de dados e bancos de dados subsequentes recebem dados transformados de TRANSACTION-FILE

Este mapa de linhagem é o metadado operacional que as ferramentas de catálogo de dados precisam para a visualização de linhagens, mas não conseguem construir sem acesso ao código-fonte do programa e ao JCL.

Fase 3: Extração de regras de negócio como proxy de metadados semânticos.

As regras de negócio codificadas na lógica da PROCEDURE DIVISION do COBOL são representações do significado do negócio. Um programa que valida TRANS-AMT-CD Garantir que o valor esteja dentro de determinados intervalos antes do processamento fornece evidências sobre o intervalo válido do campo. Um programa que converte TRANS-AMT-CD Converter o sinal para uma unidade diferente antes de escrever para um sistema subsequente revela uma convenção decimal ou de unidade implícita.

A extração dessas regras de negócio por meio da análise de código produz um conjunto de metadados semânticos inferidos: os intervalos de validação aplicados a cada campo, as transformações que ocorrem entre a origem e o destino e as condições sob as quais diferentes caminhos de código são executados. Esses metadados semânticos inferidos são imprecisos; eles mostram o que os programas fazem com os dados, não necessariamente o que os dados deveriam significar, mas podem ser recuperados do código de uma forma que o documento de especificação original não permite.

Fase 4: Validação humana e enriquecimento semântico.

Os metadados técnicos e operacionais extraídos, juntamente com os metadados semânticos inferidos, formam a base para sessões de validação humana com especialistas da área e desenvolvedores que estão se aposentando. O objetivo é converter a semântica inferida em semântica confirmada, validando que TRANS-AMT-CD Significa o que o código sugere que significa, identificando casos em que o comportamento do código deixa de refletir o significado pretendido para o negócio e capturando o conhecimento institucional sobre o histórico da área que a análise de código não consegue recuperar.

Esta fase é limitada no tempo pela disponibilidade de conhecimento especializado na área: a cada ano que passa, mais desse conhecimento se perde com as pessoas que o detêm.

A lacuna de metadados legados na fronteira do sistema moderno

O déficit de metadados criado por sistemas com várias décadas de existência não fica restrito ao ambiente legado. Ele se propaga para os demais sistemas: todo sistema analítico, data warehouse e pipeline de aprendizado de máquina que consome dados de sistemas legados herda essa lacuna de metadados.

Um data warehouse na nuvem que recebe uma extração noturna de um arquivo plano de um programa em lote COBOL tem, em suas definições de coluna, os nomes que a equipe de engenharia de dados escolheu para as colunas ao construir o pipeline ETL. Se o campo original fosse TRANS-AMT-CD e o desenvolvedor de ETL nomeou a coluna de destino transaction_amountO data warehouse parece ter metadados completos: nome da coluna, tipo de dados e descrição do negócio adicionados ao catálogo. O que o catálogo não registra é que transaction_amount originado de TRANS-AMT-CD in TRANSACTION-FILE, que é produzido por um programa COBOL chamado TRNSRC01, que é executado em um trabalho JCL TRANSDAY todas as noites às 2 da manhã, e que aplica uma conversão de moeda específica que foi codificada em 1987 com base em uma convenção de taxa de câmbio que pode ou não ainda estar em vigor.

O registro de metadados downstream parece completo. A linhagem é interrompida no limite do legado. Qualquer carga de trabalho analítica ou de IA que dependa da compreensão da proveniência e do significado de transaction_amount Existe uma lacuna onde a verdadeira história da origem desse valor não está documentada.

A constatação da Gartner de que 60% dos projetos de IA sem suporte de dados adequados para IA serão abandonados até 2026 é, em parte, uma afirmação baseada em metadados. Modelos de IA que consomem transaction_amount Sem saber que se originou de um campo COBOL decimal compactado com uma casa decimal implícita, denominado em uma moeda que pode ter sido convertida usando uma convenção de taxa de câmbio de 1987, os modelos estão sendo treinados com dados cuja proveniência é opaca. O modelo não pode desconfiar ou se ajustar a esse contexto porque os metadados que o comunicariam não existem em nenhum catálogo ao qual o modelo ou seu pipeline de dados possam acessar.

Criando um programa de gerenciamento de metadados para sistemas legados.

Um programa de gerenciamento de metadados para sistemas de dados com várias décadas de existência possui quatro componentes que o diferenciam das implementações padrão de catálogos de dados corporativos:

Componente 1: Extração de metadados do código-fonte. Antes que qualquer ferramenta de catalogação possa gerenciar metadados legados, os metadados devem ser extraídos dos artefatos de origem onde residem. Essa extração deve abranger: entradas de descritores de arquivo (FDs) e copybooks (metadados técnicos para estruturas de dados), cláusulas SELECT (organização de arquivos e método de acesso), instruções JCL DD (associações de conjuntos de dados e características de arquivos) e nomes de condição de nível 88 (vocabulário de valores semânticos incorporado no código-fonte). O resultado é um inventário de metadados em nível de campo que pode ser carregado em um catálogo como ponto de partida para o enriquecimento de negócios.

Componente 2: Reconstrução da linhagem. A linhagem de dados para sistemas legados deve ser reconstruída a partir da análise de dependências de programas, e não do rastreamento de linhagem de ferramentas ETL. O mapa de linhagem rastreia os dados desde seu programa COBOL de origem, passando por programas de transformação intermediários, até seus consumidores finais, incluindo os processos ETL que os entregam aos sistemas analíticos modernos. Essa reconstrução preenche a lacuna de linhagem no limite do sistema legado, conectando os metadados das colunas do data warehouse na nuvem aos metadados das entradas de funções de distribuição (FD) do COBOL por meio de uma cadeia documentada de dependências de programas.

Componente 3: Enriquecimento semântico com conhecimento especializado do domínio. Os metadados técnicos extraídos fornecem a estrutura; a confirmação do significado comercial requer conhecimento especializado do domínio. O processo de enriquecimento utiliza os metadados técnicos como um estímulo estruturado para entrevistas com especialistas: “Este campo é definido como PIC S9(9)V99 COMP-3O valor é validado como não negativo em 14 programas e é convertido para uma escala diferente antes de ser gravado no banco de dados subsequente. Você pode confirmar o que ele representa e o que significa essa conversão? Essa abordagem estruturada utiliza a análise de código para maximizar o valor informativo de cada interação com especialistas, permitindo um enriquecimento mais rápido e completo do que revisões de documentação não estruturadas.

Componente 4: Integração da governança com plataformas de catálogo modernas. Após a extração, reconstrução e enriquecimento dos metadados legados, é necessário integrá-los à infraestrutura moderna de governança de metadados. Essa integração conecta o inventário de metadados legados ao catálogo de dados corporativo, fornecendo: linhagem em nível de coluna da origem COBOL ao destino na nuvem, termos do glossário de negócios vinculados às definições de campos legados e metadados de qualidade de dados para conjuntos de dados legados que preenchem a mesma estrutura de governança que os metadados do sistema moderno.

Como SMART TS XL Extrai metadados legados

SMART TS XL Aborda os dois primeiros componentes do programa legado de gerenciamento de metadados, extração de metadados do código-fonte e reconstrução de linhagem, aplicando análise estática a todo o portfólio de COBOL, JCL e copybooks.

A funcionalidade de análise estática de código examina cada entrada de FD (função de determinação), membro COPY, cláusula SELECT e definição de nível 88 em todo o portfólio COBOL, produzindo o inventário de metadados técnicos em nível de campo: cada nome de campo, tipo de dados, comprimento, especificação COMP, associação REDEFINES e nome de condição de nível 88 em cada programa e copybook no ambiente. Para um portfólio de milhares de programas COBOL, essa extração produz em horas o inventário de metadados técnicos que a documentação manual levaria anos para produzir, se é que seria possível produzi-lo completamente.

O mapeamento de dependências de aplicações constrói o mapa de linhagem operacional: cada relação programa-conjunto de dados (quais programas produzem quais conjuntos de dados e quais os consomem), cada dependência programa-programa (quais programas chamam quais outros e quais dados fluem entre eles) e cada relação JCL-programa (quais etapas de trabalho invocam quais programas e em qual sequência). Esse mapa de linhagem é a camada de metadados operacionais que preenche a lacuna entre os sistemas legados e os registros de linhagem do catálogo de dados moderno.

A funcionalidade de expansão de JCL rastreia toda a cadeia de execução de cada tarefa JCL: resolvendo referências PROC, expandindo parâmetros simbólicos e construindo os metadados operacionais completos para a produção e o consumo de cada conjunto de dados, o contexto de agendamento, as tarefas dependentes e a sequência de execução que determina as características de pontualidade e atualização de cada conjunto de dados.

A funcionalidade de busca corporativa permite consultar o inventário de metadados extraído em todo o programa de gerenciamento de metadados: encontre todos os campos definidos como COMP-3 (campos sensíveis à precisão que exigem mapeamento cuidadoso de destino), todos os programas que leem um campo específico (identificando todos os consumidores de um dado específico para enriquecimento semântico e de linhagem) e todos os nomes de condição de nível 88 que correspondem a um termo comercial específico (mapeando o vocabulário comercial para definições de campos técnicos). Essa funcionalidade de busca auxilia o processo de enriquecimento semântico, permitindo que especialistas da área encontrem todos os usos de um campo ou valor específico antes de confirmar seu significado comercial.

Para organizações que realizam modernização legada programas, SMART TS XLA extração de metadados fornece a base pré-migração: os metadados técnicos em nível de campo que as ferramentas de migração precisam para mapear os campos de origem para os esquemas de destino, a linhagem operacional que os programas de migração precisam para sequenciar corretamente as migrações de conjuntos de dados e o vocabulário semântico de 88 níveis que permite o mapeamento preciso de valores de código COBOL para definições de restrições relacionais.

A urgência da recuperação de metadados antes que o conhecimento se torne obsoleto.

O problema da reconstrução de metadados tem um prazo limite natural que não se aplica à maioria dos desafios de governança de dados: a aposentadoria dos desenvolvedores que detêm o conhecimento institucional que a análise de código não consegue recuperar. Quase um terço dos programadores COBOL se aposentará até 2030. A idade média de um engenheiro de mainframe é de 58.7 anos. Cada ano que passa sem extração sistemática de metadados e enriquecimento semântico reduz a janela de tempo em que a validação humana dos metadados recuperados é possível.

Os metadados técnicos, definições de campos, especificações de tipos, dependências de programas e linhagem de dados podem ser recuperados do código-fonte indefinidamente, desde que o código-fonte exista. Os metadados semânticos, ou seja, o significado de cada campo em termos de negócios, as decisões históricas que embasaram o projeto dos campos e as convenções implícitas que as especificações técnicas não documentam, só podem ser recuperados por pessoas que os conhecem e apenas enquanto elas estiverem disponíveis.

Um programa de gerenciamento de metadados para sistemas com várias décadas de existência, que começa com a extração técnica e prossegue para o enriquecimento semântico enquanto o conhecimento especializado do domínio ainda está disponível, produz uma base de metadados completa e recuperável. O mesmo programa, se adiado para depois que o conhecimento se torna obsoleto, produz uma base de metadados técnicos que é precisa, mas incompleta, correta quanto à estrutura dos dados, mas omissa quanto ao seu significado.

Os metadados são o mapa. Sistemas que duraram décadas o ocultaram.

A governança de dados para sistemas modernos começa com metadados que sejam atuais, acessíveis e, pelo menos, parcialmente documentados. A governança de dados para sistemas com várias décadas de existência começa com metadados distribuídos por milhares de arquivos de código-fonte, parcialmente documentados em especificações que antecedem a internet e parcialmente guardados na memória de desenvolvedores que estão se aproximando da aposentadoria.

O caminho do oculto ao governado passa por extração, reconstrução e enriquecimento, nessa ordem. Os metadados técnicos extraídos do código-fonte fornecem o inventário inicial. A linhagem operacional reconstruída a partir das dependências do programa fornece o mapa de proveniência. O enriquecimento semântico, validado por conhecimento especializado do domínio, fornece o significado comercial que torna os metadados técnicos acionáveis ​​para análises, IA e governança.

As plataformas modernas de catalogação de dados são o destino desses metadados, não o ponto de partida. Antes que o Collibra possa governá-los, o Alation possa catalogá-los e os cientistas de dados possam confiar neles, os metadados contidos em sistemas com várias décadas de existência precisam primeiro ser encontrados: nas entradas de dependências funcionais, nos copybooks, nos nomes de condições de 88 níveis e nas regras de negócio codificadas em quarenta anos de lógica de DIVISÃO DE PROCEDIMENTOS.

O mapa existe. Só precisa ser lido.