Tradução de :
Meta Data in Context (3)
Dm Review Online – Fevereiro de 2000
Por Jerry Wiener.
Visão geral.
Meta Data in Context (3)
Dm Review Online – Fevereiro de 2000
Por Jerry Wiener.
Visão geral.
O
termo Metadado tornou-se um código. Infelizmente, quando decodificado, a
mensagem resultante produz uma variedade de vagas, e muitas vezes mal
direcionadas, impressões e interpretações. No mundo de hoje com ambos os
sistemas OLTP e Data Warehouse (DW), a palavra Metadado perdeu grande parte do
significado. A definição original, “dado sobre dado”, não é mais suficiente para
estabelecer uma clara e precisa definição. Este artigo busca prover distinções
que produzam claras diferenças contextuais para o termo Metadado e o(s)
significado(s) relevante(s) em cada contexto.
O que é Metadado ?
Colocado simplesmente, Metadado é “documentação”. Muita confusão sobre
metadado provém da ambigüidade sobre o escopo e contexto do que está sendo
documentado. Portanto é interessante fazer a pergunta “Documentação do que?”. Em
seguida estão quatro grandes contextos com uma discussão de cada um.
Contexto de Administração de Dados.
Administração de dados é
o contexto onde o termo “metadado” originou-se e é o contexto mais apropriado
para o uso do termo. Administração de dados é historicamente o responsável
primário por criar e manter “modelos de dados” que, quando propriamente
documentados, contém dados sobre dados.
Prática corrente.
Muitas grandes empresas que alocaram recursos para a administração de dados
(AD) agora tem metadados com contexto de AD em suas organizações. A prática de
criar e documentar completamente modelos de dados que serão base para
implementar estruturas de dados deixou estas organizações em uma boa posição com
respeito à metadados no contexto de AD.
Contexto de Desenvolvimento
de Aplicações.
No contexto de desenvolvimento de aplicações, metadados
se refere a documentação de processos que acessam dados em sistemas aplicativos
(OLTP). Documentação de processos (“dados sobre processos”) é logicamente
representada como um modelo de processo do sistema e é fisicamente construída
usando 3GL, 4GL, geradores de código ou outras ferramentas para implementação de
processos.
Documentação de processos pode existir na forma de modelos de
processos e/ou diagramas de decomposição de processos os quais são decompostos
até o nível de pseudo código que pode ser usado por programadores como uma
especificação. O próprio código do programa, junto com qualquer documentação
interna (comentários) que contenha, é também parte do metadado nesse contexto,
não importando a forma em que está expresso em virtude das ferramentas em uso.
Prática corrente.
Poucas organizações alocaram recursos
suficientes para a administração de processos. Tipicamente, modelos de processos
não são criados e completamente documentados, como seus contrapartes modelos de
dados, antes da implementação. Para a prática de modelar processos antes de
implantá-los é muitas vezes ignorada ou dada uma baixa prioridade.
Tipicamente, se a documentação de processos é completada, ela é feita
depois que o código do processo é criado e apenas se o tempo permite – o que é
freqüentemente nunca. Tempo, como um recurso, é mais freqüentemente alocado para
a criação e refinamento interativo do código, enquanto a documentação do
processo permanece incompleta ou não existente. Isto resulta em que cada
tentativa de manutenção seja precedida de um redundante estudo do código em uma
tentativa de adquirir conhecimento requerido para a execução da manutenção.
Contexto Back-End do Data Warehouse.
Em virtude de
múltiplas plataformas estarem tipicamente envolvidas em um projeto de Data
Warehouse (DW), a documentação requerida tende a crescer exponencialmente com o
número de sistemas incluído. Um conjunto completo de metadados no contexto de DW
back end inclui :
Metadados de estrutura de dados.
Estrutura de dados do sistema origem.
-documentação de contexto AD.
Estrutura da área de staging.
-documentação de contexto AD.
Estrutura de Warehouse/mart.
-documentação de contexto AD.
Metadado de mapeamento de colunas.
Mapeamento – para processos de
extração.
-documenta os pares de colunas correspondentes, representando
dados de origem e destino com relação ao processo de extração.
Mapeamento –
para processos de transformação.
-documenta os pares de colunas
correspondentes, representando dados de origem e destino com relação ao processo
de transformação.
Metadado de processo (ETL)
Processo de
extração.
-documenta o processo de movimentação de dados de um sistema de
origem para uma área de armazenamento visando reunião de dados e preparação para
transformação.
Processo de transformação.
-documenta o processo que
transforma dados reunidos em um formato que é consistente com a estrutura de
dados de data warehouse (dimensional). Neste sentido, é similar a uma conversão
de dados.
Processo de carga (load).
-documenta o processo que toma os
dados transformados e carrega as estruturas do Data Warehouse. Devido aos altos
volumes algumas vezes requeridos,realizar esta documentação periodicamente pode
ser uma tarefa desafiadora por si só.
Contexto Front-End do Data
Warehouse.
Dados de metadados documentam o significado de dados para
o beneficio dos usuários finais que estão processando consultas no data
warehouse ou data mart. Idealmente, eles deveriam estar disponíveis dentro das
consultas ou ferramentas de OLAP usadas para executar as consultas bem como
referentes aos resultados retornados como saída das consultas. Visando prover
mecanismos de consulta ad hoc para os usuários, metadados de front-end são
imperativos para garantir que significados consistentes são utilizados por todos
que interagem com Data Warehouse ou mart.
Metadados de processos
documentam as consultas de usuários e as operações requeridas para executá-las.
Processos especializados podem ter que ser construídos se há o requerimento para
capturar metadados de processos ad hoc de consulta.
Por que são
necessários todos esses Metadados?
A resposta reside na seguinte
questão : Se, em algum ponto no futuro, for descoberto que dados em um de seus
marts está incorreto, como você irá determinar onde o erro ocorreu, o que foi
responsável por ele e o que é requerido para consertá-lo?
As questões
candidatas são: Estava no proceso que carregou o mart do warehouse ou no
processo que transformou os dados para o warehouse da área de reunião ? Havia um
problema no processo que extraiu os dados dos sistemas origem ? Em qual sistema
origem o dado em questão residia ? Que outros dados ou processos participaram em
qualquer valor derivado ? Finalmente, alguém chega a questão : Estava o dado
armazenado incorretamente no sistema origem e então simplesmente foi replicado
para o warehouse ? (Nesse caso você necessitará conhecer os processos do sistema
de origem que eram responsáveis pelos valores iniciais do dado).
Como os
data warehouse e marts são relativamente jovens, eles são relativamente bem
comportados – do mesmo modo que nossos sistemas OLTP quando eles eram jovens.
Entretanto, como os requerimentos mudam e os efeitos de manutenções criam seus
problemas ao longo dos anos, nossos warehouses e marts ficam em perigo de
tornarem-se sistemas legados.
O que faremos nesse caso ? Seremos
forçados a tentar construir (meta) warehouses de segunda geração em uma
tentativa de retirar os erros de nossos warehouse legados de primeira geração?
Eu espero que não. Mas, o único caminho que nos salvará deste perigoso destino é
começar a trabalhar agora diligentemente desenhando e implementando repositórios
de metadados. Isso requer dar uma alta prioridade em manter metadados
consistentes e atualizados, para evitar um futuro de warehouses e marts legados.
Previsões de futuro.
Aquelas organizações que tenham
documentado seus dados e processos terão a recompensa de possuir sistemas com
ambas as vantagens de longevidade e possibilidade de manutenção com relativa
facilidade conforme requerido por alterações no ambiente de negócio. Aquelas
organizações que deixaram seus sistemas não documentados irão enfrentar o
cenário dos legados.
Também para as organizações que tenham conjuntos
completos de metadados distribuídos em numerosas plataformas de
hardware/software e em numerosas ferramentas de modelagem de dados e processos,
o desafio de integrar todos os metadados em um único repositório capaz de
providenciar respostas para questões de negócio e sistemas é formidável.
Mesmo que padrões robustos tenham sido firmemente estabelecidos para a
disponibilização de dados de processos e dados – para e de um repositório
padronizado de metadados – isto poderá ser de pouco uso para aquelas
organizações que tenham sido pouco diligentes na criação e manutenção de seus
metadados enquanto os sistemas estavam sendo desenhados, implantados e mantidos.
Esses não documentados, ou sub documentados sistemas serão candidatos a
tornarem-se sistemas, marts e warehouse legados. E assim, eles não serão capazes
de enfrentar manutenções sem o risco substancial de que o “conserto” possa
resultar em mais danos do que reparos.
Conclusão.
Infelizmente o simples termo “metadado”, tem sido usado (ou mal usado?)
sem distinção entre dados e processos, sem distinção entre sistemas OLTP e DW.
Como resultado isso tem causado que o significado do termo tenha se tornado
extremamente ambíguo.
Nenhum comentário:
Postar um comentário