Mostrando postagens com marcador Metadados. Mostrar todas as postagens
Mostrando postagens com marcador Metadados. Mostrar todas as postagens

domingo, 5 de agosto de 2012

Business Intelligence - Uma Estrutura de Referência (Framework) para Construção

Publicação original = Fórum SBGC-TIC   20/2/2006 11:05 PM


Indice

1---Introdução 
2---Visão Geral 
3---Modelo Informacional 
3.1-Definição 
3.2-Áreas de Decisão 
3.3-Níveis Organizacionais 
3.4-Exemplos de Questões Organizacionais para Gestão 
4---Modelos de Gestão 
4.1-Definição 
4.2-Dimensões de Analise 
4.3-Fatos ou Indicadores 
4.4-Balanced Scorecard - Estrutura de Referência (Framework) para construção de Modelos de Gestão 
5---Modelo Multidimensional 
5.1-Definição 
5.2-Tabelas de Fatos 
5.3-Tabelas de Dimensões 
5.4-Exemplos 
6---Extração, Transformação e Carga de Dados (ETL) 
6.1-Definição 
6.2-Área de Disponibilização de Dados (Data Staging) 
6.3-Armazém de Dados Operacionais (Operational Data Storage) 
7---Modelos Analíticos ou Gerenciais 
7.1-Definição 
7.2-Exemplos 
8---Metadados 
8.1-Definição 
8.2-Metadados Técnicos 
8.3-Metadados de Negócio 
9---Glossário 
10--Siglas 
11--Referências na Internet 

1 Introdução

Este documento demonstra minha visão do que é e como se contrói uma solução de Inteligência de Negócio (Business Intelligence) que sirva de suporte aos processos de decisões de uma organização. 

O processo está representado abaixo, na Visão Geral, e explicado nos demais itens do documento. 

Inclui uma série de termos, e seus respectivos conceitos, que julgo necessários ao entendimento do processo de especificação e construção de uma solução de Inteligência de Negócios. 

O objetivo é propor uma Estrutura de Referência (Framework) que sirva de base a este processo de especificação e construção. 

Procuro, também, comparar o processo proposto com o processo de especificação e construção de soluções de automação de processos operacionais da organização, normalmente citados como sitemas operacionais ou legados, na literatura sobre Inteligência de Negócio (Business Intelligence). 

Este documento resume minha experiência pessoal e as pesquisas realizadas sobre o assunto. Sendo assim as informações aqui organizadas também são frutos da convivência profissional ou intelectual com várias pessoas que também se interessam pelo assunto. 

Agradeço qualquer comentário ou contribuição que permita enriquecer o texto, contribuindo para a sua clareza e evolução. 

2 Visão Geral

Vide "Modelo genérico de BI_20060214.gif" abaixo.



3 Modelo Informacional

3.1 Definição

Representa as necessidades de informações que deverão ser atendidas pela solução de Inteligência de Negócio (Business Intelligence) que será desenvolvida. 

Identifica as preocupações e focos de investigação que os Gestores explorarão, com base nos dados operacionais e do ambiente da Organização, para tomar as decisões que esta solução deverá suportar.  

3.2 Áreas de Decisão

Identificam os Focos de Gestão de cada um dos Gestores que deverão ser atendidos pela solução. 

Exemplos: Marketing, Orçamento, Gestão Operacional, Gestão de Aprendizagem 

3.3 Níveis Organizacionais

Identifica os horizontes temporais de decisão que a solução deverá atender. Geralmente um ou mais dentre os seguintes: 

Diretoria – a solução deverá suportar a tomada de decisões estratégicas, ou de longo prazo 

Média Gerência – as decisões suportadas atenderão necessidades táticas associadas ao cumprimento de objetivos de médio prazo 

Gestão Operacional – a solução será utilizada para acompanhar as ocorrências do dia a dia da Organização. 

3.4 Exemplos de Questões Organizacionais para Gestão

Quantos clientes compraram um determinado Produto no último mês, trimestre, semestre ou ano ? E no período correspondente anterior ? 

Os Clientes que compram um determinado tipo de Produto ou Serviço normalmente adquirem que outros Produtos ou Serviços ? 

Qual a relação entre Satisfação com o Atendimento e o tipo de formação do Atendente ? 

Qual a relação entre Produtividade e o nível educacional, ou tipo de formação, do Colaborador ? 

Qual é o Fator de Inovação de cada Unidade Organizacional (Receita de Novos Produtos ou Serviços / Receita Total da Unidade Organizacional) ? 

4 Modelos de Gestão

4.1 Definição

Conjuntos de Fatos ou Indicadores e as Dimensões em que estes Fatos ou Indicadores deverão ser analisados para proporcionar uma visão de situações ocorridas ou tendências de comportamento de áreas da organização ou de seu ambiente de operação. São derivados do Modelo Informacional. 

As visões obtidas servirão de base para a tomada de decisões sobre alterações de processos, iniciativas de reação a mudanças de resultados ocorridas ou previstas, criação de novos produtos ou serviços para atender oportunidades identificadas no ambiente operacional da organização. 

Os Modelos de Gestão representam o escopo que a solução de Inteligência de Negócio deve atender. Difere da abordagem para Sistemas Operacionais, onde o escopo da solução é dado pelas Funcionalidades que a aplicação desenvolvida deve automatizar. 

4.2 Dimensões de Analise

São as formas de classificação e seleção dos valores registrados para Indicadores que representam situações do ambiente organizacional que se deseja analisar. 

Exemplos: Tempo (Mês, Trimestre, Semestre, Ano), Estrutura Organizacional (Filial, Gerência Regional, Divisão, Empresa, Corporação), Segmento de Cliente, Área Geográfica (pode ser baseada no CEP), Tipo de Produto ou Serviço. 

4.3 Fatos ou Indicadores

Valor Medido ou Atribuído que representa uma ocorrência no ambiente Organizacional, ou Índices calculados com base nestes Valores Medidos ou Atribuídos. Podem ser obtidos partindo de dados extraídos dos sistemas operacionais da organização ou de dados capturados do ambiente externo da Organização. 

Exemplos: 

Valor de uma Venda para um Cliente 

Produtividade = Quantidade Produzida / Horas Trabalhadas 

Eficiência Operacional = Faturamento / Soma dos custos fixos e variáveis de uma Unidade Organizacional que produziu o Faturamento 

Classificação: Posição relativa de uma Unidade Organizacional em um conjunto de Unidades Organizacionais, com base em um Indicador escolhido. Por exemplo: as dez melhores e as dez piores, segundo algum critério de classificação. 

4.4 Balanced Scorecard - Estrutura de Referência (Framework) para construção de Modelos de Gestão

Considero que o Balanced Scorecard, que pode ser traduzido como Indicadores Balanceados de Desempenho, pode ser usado como Estrutura de Referência para auxiliar no processo de definição de Modelos de Gestão da Organização. 

O BSC defende a identificação de um conjunto pequeno de Indicadores que permitam expressar os objetivos estratégicos da Organização e que sejam passíveis de desdobramento em Indicadores de performance para os vários níveis organizacionais, permitindo a cada Unidade Organizacional e, no limite, a cada Colaborador, entender e ser avaliado por sua contribuição para a obtenção dos objetivos estratégicos definidos. 

Esta metodologia defende que a escolha de Indicadores para a gestão de uma Organização não deve ser restrita a informações econômicas ou financeiras. Assim como não é possível pilotar com base apenas no indicador de velocidade de um avião, indicadores financeiros não são suficientes para garantir que a empresa está caminhando na direção correta. Para tanto o BSC defende a definição de Indicadores que contemplem quatro perspectivas: financeira, mercadológica, performance dos principais processos operacionais e aprendizado / inovação. 

Esta metodologia de definição de Modelos de Gestão foi criada pelos professores Robert Kaplan e David Norton, da Harvard Business School, em 1992 e vem sendo aplicada com sucesso no mundo inteiro em centenas de organizações do setor privado, público e em organizações não-governamentais.


5 Modelo Multidimensional

5.1 Definição

Estrutura de organização de dados que facilita o cálculo e a seleção das informações necessárias para atender as análises de um ou mais Modelos de Gestão. 

5.2 Tabelas de Fatos

Contém os valores dos Fatos ou Indicadores registrados ou calculados para cada conjunto de valores das Dimensões de Análise. 

Exemplo: Para um Produto ou Serviço, em um Período de Tempo, em uma Unidade Organizacional, em um Segmento de Clientes e em uma Região Geográfica, teremos os valores de quantidade de vendas, receita de vendas, despesa de vendas, quantidade de reclamações de clientes, quantidade de devoluções 

5.3 Tabelas de Dimensões

Contém os atributos de cada valor das Dimensões de Análise. 

Exemplos: 

Produto ou Serviço – descrição, preço, familia de produtos 

Unidade Organizacional - nome, nome do Gerente, endereço, CEP 

Segmento de Clientes – nome do segmento 

Região Geográfica – Bairro, Cidade, Estado, País 

5.4 Exemplos

Abaixo são apresentados exemplos de modelo de dados Relacional, usados em Sistemas Operacionais e de Modelo de Dados Dimensional, usados em soluções de Inteligência de Negócio (Business Intelligence). O objetivo é apresentar as diferenças de estruturação de dados para os dois tipos de soluções. 

No caso está simulado um modelo de Data Mart com Dados, Fatos e Indicadores relacionados à Cobrança Bancária de Títulos. 


 O Modelo de Classes Operacional ou Transacional é o mais adequado para suportar as transações do ambiente operacional da organização.


O Modelo de Dados Dimensional ou Gerencial é o mais adequado para suportar as consultas sobre grandes volumes de dados, do ambiente de análise gerencial da organização. 

A construção de um Modelo de Dados Dimensional ou Gerencial é feita através de um processo de Extração, Transformação e Carga (ETL), a partir dos dados disponíveis no Modelo de Classes Operacional ou Transacional. 

O processo ETL pode ser construído manualmente ou utilizando-se de ferramentas tais como BW (SAP), Cognos, Informatica, MicroStrategy, dentre outras. 

A disponibilidade de um Modelo de Dados Dimensional ou Gerencial, adequado aos focos de análise preferidos pelos gestores da organização, permite a construção de Modelos de Análise utilizando-se de ferramentas para Processo de Análise On Line (OLAP) disponíveis no mercado.




6 Extração, Transformação e Carga de Dados (ETL)

6.1 Definição

Conjunto de rotinas e operações aplicadas às bases de dados dos Sistemas Operacionais, para produzir os conteúdos do Modelo Multidimensional, definido a partir das necessidades de um ou mais Modelos de Gestão.

O processo ETL pode ser construído manualmente ou utilizando-se de ferramentas tais como BW (SAP), Cognos, Informatica, MicroStrategy, dentre outras.

6.2 Área de Disponibilização de Dados (Data Staging)

Área em que serão disponibilizados os dados dos Sistemas Operacionais que representam os Eventos de Negócio que serão utilizados por um ou mais Modelos de Gestão. Com isto evita-se que vários processos de extração de dados concorram com a operação normal dos sistemas transacionais da Organização. Será nesta área que os vários processos de ETL obterão os dados que necessitem.

6.3 Armazém de Dados Operacionais (Operational Data Storage)

Conjunto, organizado e integrado, de dados extraídos e mantidos sincronizados com suas origens nos sistemas operacionais da Organização. Atende necessidades de análises para gestão de curto prazo, geralmente trinta a sessenta dias, envolvendo informações de mais de um sistema operacional.


7 Modelos Analíticos ou Gerenciais

7.1 Definição

Conjunto de apresentações construídas a partir dos dados disponíveis nos Modelos Multidimensionais, visando atender necessidades dos Modelos de Gestão que a solução atende.

Alguns tipos de análises que podem ser construídas:

Detecção de Exceções em Processos ou Cartas de Controle de Processos

Análises Ad-hoc

CRM analítico

Mineração de Dados (Data Mining)

Processos de Análise On Line (OLAP)

7.2 Exemplos


Alguns exemplos de Modelos de Análise possíveis, para o caso de Cobrança Bancária de Títulos (*):

Análises 20-80, ou seja, os 20% que produzem 80% do valor da variável de análise escolhida do Modelo (Cedentes, Diretorias Regionais, Gerências Regionais, Agências, Regiões Geográficas) para períodos de tempo selecionados.

Os dez mais e os dez menos (Cedentes, Diretorias Regionais, Gerências Regionais, Agências, Regiões Geográficas) para períodos de tempo selecionados.

Mapas de áreas geográficas coloridas conforme os valores da variável (*) de análise selecionada do Modelo. Inclusive com possibilidade de “fazer zoom” em uma dada região geográfica e visualizando as sub-regiões coloridas segundo o mesmo padrão de cores (Drill down e Drill up)

Comparações entre períodos de tempo selecionados (trimestres, semestres, etc.) para detecção de sazonalidades ou análises de performance de indicadores sem a contaminação desta sazonalidade.


(*) Para qualquer dos valores disponíveis na Tabela Fato do Modelo de Dados Dimensional ou Gerencial, ou Indicador Chave de Processo (KPI) calculado a partir destes valores disponíveis.


8 Metadados

8.1 Definição

Conjunto de informações que permitem compreender o significado, conteúdo e situação dos dados e informações presentes em uma Organização.

8.2 Metadados Técnicos

Representam informações sobre estruturas de dados, definições de rotinas e processos organizacionais, diários de execução de rotinas operacionais ou de extração, transformação e carga de dados e seus resultados.

Incluem:
Dicionários de Dados, com Nome, Formato, Tipo e Tamanho dos atributos das bases de dados,

Especificações de Programas de Computadores ou de Regras de Transformações efetuadas em dados extraídos dos Sistemas Operacionais para compor Modelos Multidimensionais,

Logs de execução de rotinas.

8.3 Metadados de Negócio

Representam conceitos de negócio ou fórmulas e métodos de obtenção de Indicadores usados em um ou mais Modelos de Gestão ou Sistemas Operacionais.

9 Glossário

Ad-hoc – questão ou análise a ser resolvida e que não foi préviamente definida.

Business Intelligence – Inteligência de Negócio: Conjunto de Modelos de Gestão e Capacidades de Análise que permitem a uma Organização compreender e reagir eficazmente aos desafios e oportunidades presentes em seu ambiente de atuação.

Customer Relationship Management – Gestão do Relacionamento com o Cliente: Conjunto de Modelos de Gestão, Capacidades de Análise e Ações que permitem a uma Organização melhorar o relacionamento com seus clientes, facilitando o cumprimento das Metas e Objetivos da Organização.

Data Mining – Exploração de Dados: Conjunto de Modelos e Capacidades de Análise que permitem a identificação de padrões e tendências através de tratamentos automatizados de grandes volumes de dados sobre a operação e o ambiente da Organização.

Decision Support System – Sistemas de Suporte a Decisão: sistemas que disponibilizam alertas e indicadores que são utilizados nos processos de tomada de decisão da Organização.

Drill Down - O Drill Down ocorre quando o usuário aumenta o nível de detalhe da informação, diminuindo o grau de granularidade.

Drill Up - É o contrário do Drill Down, ele ocorre quando o usuário aumenta o grau de granularidade, diminuindo o nível de detalhamento da informação.

Executive Information System – Sistemas de Informações Executivas: sistemas que permitem visões macro de resultados e tendências do conjunto de processos de uma organização. Geralmente produzem relatórios de uma página ou indicadores em painéis de controle, demonstrando os principais Indicadores de toda a Organização.

Management Information System – Sistemas de Informações Gerenciais: sistemas que permitem acompanhar e avaliar os resultados de processos de uma Organização.

On Line Analytical Process – Processo de Análise On Line: Capacidade de combinar dados de uma estrutura de dados disponível para obter diferentes análises cuja utilidade é avaliada após sua produção.

Operational Data Storage – Armazém de Dados Operacionais: conjunto, organizado e integrado, de dados extraídos e mantidos sincronizados com suas origens nos sistemas operacionais da Organização. Atende necessidades de análises para gestão de curto prazo, geralmente trinta a sessenta dias, envolvendo informações de mais de um sistema operacional.


10 Siglas

BI – Business Intelligence

CRM - Customer Relationship Management

DSS – Decision Support System

EIS – Executive Information System

ETL - Extração, Transformação e Carga (Loading)

MIS – Management Information System

ODS - Operational Data Storage

OLAP - On Line Analytical Process

11 Referências na Internet


http://www.dmreview.com/ - Business intelligence, data warehousing and analytics editorial

http://www.dmreview.com/authors/author_sub.cfm?AuthorID=30609 - Customer Intelligence - Larry Goldman

http://www.dwbrasil.com.br/ - Artigos em português sobre Inteligência de Negócio

http://www.inmoncif.com/home/ - Corporate Information Factory e Government Information Factory - Frameworks para soluções de Inteligência de Negócio

http://www.ralphkimball.com/html/articles.html - Kimball Group Data Warehouse Training Articles

http://www.bscol.com/ - Balanced Scorecard Collaborative - driving breakthrough results

http://www.symnetics.com.br/news/default.asp - BSC - Symnetics - Brasil - Biblioteca Virtual – Artigos

Inteligência de Negócios: O que é este dado? Apresentação para usuário final de Metadados

Publicação original = Fórum SBGC-TIC  13/6/2006 7:58 PM



Tradução de: 
Business Intelligence: What is This Data? End User Presentation of Meta Data. Dm Review Online – Outubro de 2000 
Por Jonathan Wu. 

Um número crescente de nossos clientes está perguntando, “O que é este dado?” Certamente, as aplicações de Inteligência de Negócios (BI) que eles estão usando estão provendo dados, mas eles querem sentir-se confortáveis com a origem do dado, com as regras de negócio que foram usadas para manipulá-los e querem o contexto no qual a descrição dos elementos de dados faz sentido. 

Nestas situações, nossos clientes estão perguntando a respeito da apresentação de Metadados para usuários finais. Definido simplesmente, metadado é a definição do dado. Existem dois níveis primários de metadado : as camadas administrativa e de usuário final. 

A camada administrativa de metadados relaciona-se a aplicação e a configuração das bases de dados que são armazenadas em entidades em gerenciadores de BD. Enquanto esta é uma camada importante, a camada de usuário final de metadado é onde aparece a maioria das questões e diferenças de opinião. A tabela abaixo procura definir e classificar os vários níveis de metadados para usuários finais. 


Enquanto estes níveis definem a transformação de dados de suas origens até um relatório, a complexidade de cada nível pode ter um impacto significativo na definição do dado. Note que nem todos os níveis de metadados de usuário final são encontrados por um individuo usando uma aplicação de B.I. Níveis 1-3 são relativos à guarda em armazém de dados (Data Warehousing) da informação, no caso de um individuo sem acesso a um Data Warehouse pode-se encontrar apenas os níveis 0, 4 e 5 quando extraindo dados diretamente de um sistema de origem. 

Dado de Sistema de Origem.

Em cada sistema transacional, um usuário do sistema deve introduzir dados. Por exemplo, um representante de vendas introduz informações sobre um produto que foi vendido a um cliente em uma aplicação de entrada de pedidos. A informação introduzida pelo representante de vendas é aceita pela aplicação e armazenada em uma base de dados. Os elementos de dados da informação relacionados à transação de vendas podem incluir o nome do cliente, endereços de entrega e faturamento, termos da transação, produto adquirido, quantidade vendida, preço de venda e descontos. 

Dado Extraído.

Assumindo que uma organização tem múltiplos sistemas transacionais e o desejo de armazenar o dado, migrando-o dos sistemas origem para uma base de dados operacional (Operational Data Store) ou um armazém de dados (Data Warehouse) vinculando a identificação do sistema origem de onde o dado foi recebido. Por exemplo, informações de cliente são extraídas das aplicações entrada de pedidos e gerenciamento de relacionamento com clientes (CRM) para uma única base de dados usada como uma base de dados operacional (Operational Data Store) ou um armazém de dados (Data Warehouse). Os elementos de dados da informação relativa ao cliente podem incluir o nome do cliente, número de identificação de pagamento de taxas, tipo do cliente, nome do contato, endereço e número de telefone de cada sistema de origem. 

Dado Padronizado (Cleansed).

Depois do dado ter sido migrado para uma base de dados central, uma rotina de cleansing pode ser aplicada para padronizar o formato do dado e validar sua qualidade. Por exemplo, informações de cliente podem ter sido extraídas de diversos sistemas de origem. Como parte do processo de cleansing, o dado deve ser padronizado e eliminadas as redundâncias. Com um de nossos clientes, nós notamos que um único nome de cliente foi definido em cada um dos sistemas de origem e que a redundância não foi eliminada até a execução do processo de cleansing. Neste exemplo, imagine um cliente com os seguintes nomes únicos definidos : base consulting group, Base Consulting Group, BASE Consulting Group e BASE Consulting Group, Inc. O processo de cleansing deveria eliminar a redundância, padronizar o formato e validar o dado até que um nome de cliente deveria restar : BASE Consulting Group, Inc. 

Dado Transformado.

Regras de negócio e definições são usadas para transformar os dados padronizados em informação significativa. Por exemplo, renda pode ser definida como a quantidade vendida multiplicada pelo preço de venda menos qualquer desconto. Esta transformação de dado deriva um novo elemento de dado dos dados criados pelo(s) sistema(s) de origem. Definir as regras de negócio tanto quanto obter aceitação das definições pode ser desafiador, e este é o ponto em que encontramos maiores dificuldades quando tentando obter consenso. 

Dado de Inteligência de Negócio.

Muitas aplicações de BI podem acessar dados de uma variedade de fontes incluindo bases de dados, arquivos ASCII ou planilhas. Adicionais transformações ou formatações de dados podem ser indicadas pela aplicação de BI. Por exemplo, um elemento de dado chamado segment1 que contém informação sobre número de ordem de compra pode ser formatado e renomeado para PO Number. Da perspectiva do usuário final o elemento de dado é chamado PO Number, mas seu nome na base de dados é segment1, que não dá ao usuário uma descrição compreensível do tipo de dado associado com ele. 

Dado de Relatório.

Dentro de um relatório, o dado pode ser derivado para aumentar a significação da informação. Logo, este é o último nível de metadado dentro da camada de usuário final. Dado derivado neste nível tipicamente refere-se a cálculos tais como subtotais e grandes totais ou operações condicionais tais como, “Se margem (%) >= 50% então ‘Produto de Alta Lucratividade’ é listado na coluna próxima da margem (%).” 

Sumário.

Quando os usuários tomam tecnologias de BI para analises e elaboração de relatórios, eles querem saber o que o dado é para que possam colocá-lo no contexto apropriado. Compreendendo os vários níveis de metadados de usuário final, os usuários podem enriquecer a metamorfose dos dados da origem até o relatório. 


Metadado & Gerenciamento do Conhecimento : Mitos sobre Repositório de Metadados.

Publicação original = Fórum SBGC-TIC  13/6/2006 9:17 PM


Tradução de :
Meta Data & Knowledge Management : Meta Data Repository Myths
Dm Review Online – Março de 2002
Por David Marco.

Enquanto a industria de repositórios de metadados continua a crescer, também crescem os mitos e incompreensões em torno deste segmento de mercado. Este mês, eu irei tratar os mitos mais comuns e estabelecer os dados corretos.

Mito 1 : Metadados existe apenas em ferramentas e são utilizados apenas para interoperabilidade dessas ferramentas.

Antes de tratar esse mito vamos rever a definição de metadado. Metadado é : Todo dado físico (contido em software e várias mídias) e conhecimento (mantido por funcionários e várias mídias) de dentro e de fora da organização, contendo informações sobre dados físicos da companhia, industria, processos técnicos e processos de negócio.(1)

Esta definição de metadado pode ser traduzida para uma palavra: conhecimento. Metadado captura eletronicamente o conhecimento, tanto técnico quanto de negócio, que existe em nossas companhias.

Quando revisamos onde o conhecimento existe dentro de nossas companhias, fica claro que a vasta maioria do conhecimento está armazenada na mente dos funcionários. (veja Figura 1)

Figura 1 : Onde está armazenado o conhecimento corporativo? 





Claramente, metadado é muito mais do que existe em uma ferramenta. Essa má conceituação utiliza uma visão limitada de metadados técnicos e ignora completamente os metadados de negócio. Todo bit de metadados de negócio é mais importante e quase sempre mais rentável. Como profissionais de T.I., nós necessitamos compreender e aprender como capturar, manter e disseminar metadados de negócio. 

Eu não quero criar qualquer mal entendido, as ferramentas de software armazenam uma grande quantidade de valiosos metadados. Ferramentas de extração, transformação e carga (ETL) (por ex. : Ascential, Informática), ferramentas de modelagem de dados (por ex. : Erwin), gerenciadores de bancos de dados relacionais (por ex. : Oracle, DB2, MS SQL Server) e ferramentas de inteligência de negócios (por ex.: Business Objects, Cognos) todas tem valiosos metadados técnicos que são comumente armazenados em repositório. 

Um mal entendido relacionado é acreditar que o único propósito de metadados é possibilitar ferramentas se comunicarem entre si (interoperabilidade de ferramentas). De fato, padrões de metadados (por ex. : Object Management Group´s Common Warehouse Metamodel) sempre colocam um foco significativo na interoperabilidade de ferramentas. Uma vez mais, interoperabilidade de ferramentas é importante, entretanto é apenas uma peça do escopo completo de gerenciamento de metadados. 

Mito 2 : Repositórios sempre requerem um grande esforço de desenvolvimento de T.I.

Esta má percepção é tão comum para iniciativas de Data Warehouse quanto é para projetos de repositórios de metadados. Quase sempre corporações enfocam suas iniciativas em repositório de metadados do ponto de vista do que eles “podem” capturar ao invés do que eles “deveriam” capturar. Uma companhia deve decidir, usando objetivos de negócio e técnico, o que estão buscando conseguir ao construir um repositório de metadados empresarial. Então eles deveriam tomar um subconjunto desses objetivos e construir o repositório de uma maneira iterativa para alcançar esses objetivos. 

Um bom repositório de metadados é melhor construído iterativamente. Não me compreendam mal : não estou desaconselhando a construção de um repositório para toda a empresa, com todas as funcionalidades que suportem todos os sistemas de uma companhia. Simplesmente significa que a maior probabilidade de sucesso vem da implementação de um repositório de metadados em uma iniciativa por fases. Para nossos clientes de repositórios, eu sempre objetivo ciclos de projetos de seis a nove meses. Usando a primeira iteração como uma oportunidade para treinar a corporação, serão colocadas as bases para maiores e melhores implantações futuras. 

Mito 3 : Uma arquitetura centralizada armazena todos os metadados de forma centralizada.

Existe uma crença de que ao usar o termo repositório central de metadados isso significa que todos os metadados deveriam ser armazenados centralmente. Essa crença é o equivalente de acreditar que o Data Warehouse deveria armazenar todos os dados da corporação. Essa impressão não poderia estar mais distante da verdade. Apenas os metadados necessários para atender os requerimentos definidos de negócio deveriam ser armazenados centralmente. Por exemplo, regras de negócio e definições de negócio são metadados críticos que obviamente deveriam ser armazenados de um modo centralizado. Por outro lado, se não existe necessidade de armazenar metadados específicos, eles podem permanecer em suas fontes correntes. 

Compreendendo esses mitos irá ajudá-lo a construir um repositório de metadados de sucesso que proverá sua companhia com uma vantagem competitiva. 

Referência 

(1) Marco, David. Building and Managing the Meta Data Repository, John Wiley & Sons, 2000.

Metadado em Contexto.

Publicação original = Fórum SBGC-TIC  13/6/2006 8:32 PM

Tradução de :
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.

Metadados – Conceitos da SocInfo

Publicação original = Fórum SBGC-TIC  13/6/2006 9:40 PM

Programa Sociedade da Informação (SocInfo)
Ministério da Ciência e Tecnologia (MCT)
SAS, Quadra 5, Lote 6, Bloco H, 8º andar
CEP 70070-914, Brasília – DF, Brasil
http://www.socinfo.org.br/


Metadados são dados que descrevem outros dados, em uma definição sem maior rigor técnico. Por exemplo,em um formulário qualquer que tenha sido preenchido com os dados de um indivíduo, há tipicamente, em cada campo do formulário, uma informação explicitando que tipo de dado deve ser ali escrito: por exemplo, “NOME COMPLETO”, “ENDEREÇO” etc. Essa informação é um metadado. 

A ideia de metadados sugere alguns desdobramentos. 

Por exemplo: 

• o formulário preenchido constitui na realidade um arquivo de dados em dois níveis: o dos dados propriamente ditos e o dos metadados; 

• nesse arquivo em dois níveis, pode-se também ver cada metadado como um “rótulo” (tag) descritivo do dado que lhe corresponde. 

O conceito de metadados tem adquirido importância crescente, na medida em que mais e mais conteúdos completos são armazenados em computadores e transmitidos via redes: informações cartográficas, grandes bases de dados em textos livres em diversas línguas etc. 

O processamento adequado dessas grandes massas de dados passa pelo processamento dos metadados entremeados aos dados, que impõem estrutura e inteligibilidade aos mesmos. O Capítulo 7 - P&D, Tecnologias-chave e Aplicações descreve uma ação concreta sugerida pelo Programa para padronizar metadados para aplicações de Governo. 

Metadados
Dados a respeito de outros dados, ou seja, qualquer dado usado para auxiliar na identificação, descrição e localização de informações. Trata-se, em outras palavras, de dados estruturados que descrevem as características de um recurso de informação.

Metadados - Produzindo conhecimento em TIC

Publicação original = Fórum SBGC-TIC 13/6/2006 7:49 PM


As mensagens em resposta à esta contém traduções minhas de artigos do site http://www.dmreview.com/ sobre Metadados. Estas traduções são de 2002, logo os arquivos originais, em inglês, podem não estar mais disponíveis. 

Os textos discutem a importância crescente da documentação de sistemas e informações das organizações (metadados), incluindo modelos de dados e documentações de processos. 

Metadados compõem o conhecimento explícito. Abaixo algumas definições sobre tipos de conhecimento. 

TIC - Tecnologias de Informação e Comunicação

At. 
Claudio 


Conhecimento explícito

Conhecimento explícito é aquele que pode ser exteriorizado por palavras, imagens, ou qualquer outro veículo de transmissão de experiências sem a interação entre pessoas. Presente nos livros, manuais, bases de dados e de informações, registros de participações em fóruns de discussão WEB, etc. 

Conhecimento tácito.

De uma forma simplificada, conhecimento tácito é aquele que não pode ser exteriorizado por palavras. Calado, silencioso.Não expresso; subentendido, implícito, que, por não ser expresso, se deduz de alguma maneira. (http://pt.wikipedia.org/wiki/Conhecimento_t%C3%A1cito) 

Conhecimento tacito se constrói por meio da vivencia coletiva, desenvolvimento de visoes de mundo, capacidade de interpretacao do ambiente, empatia para poder se colocar verdadeiramente no lugar do outro, etc. (José Claudio C. Terra) 

Conhecimento (Origem: Wikipédia, a enciclopédia livre)

O conhecimento inclui, mas não está limitado, às descrições, hipóteses, conceitos, teorias, princípios e procedimentos que são ou úteis ou verdadeiros. O estudo do conhecimento é a epistemologia. 
O conhecimento distingui-se da mera informação porque está associado a uma intencionalidade. Tanto o conhecimento como a informação consistem de declarações verdadeiras, mas o conhecimento pode ser considerado informação com um propósito ou uma utilidade. 

O conhecimento, não pode ser inserido em um computador por meio de uma representação, pois neste caso seria reduzido a uma informação. Assim, neste sentido, é absolutamente equivocado falar-se de uma "base de conhecimento" em um computador. No máximo, podemos ter uma "base de informação", mas se não é possível processá-la no computador e transformar seu conteúdo, e não apenas a forma, o que nós temos de fato é uma tradicional base de dados. 
Associamos informação à semântica. Conhecimento está associado com pragmática, isto é, relaciona-se com alguma coisa existente no "mundo real" do qual temos uma experiência direta. 

O conhecimento pode ainda ser apreendido como um processo ou como um produto. Quando nos referimos a uma acumulação de teorias, ideias e conceitos o conhecimento surge como um produto resultante dessas aprendizagens, mas como todo produto é indissociável de um processo, podemos então olhar o conhecimento como uma atividade intelectual através da qual é feita a apreensão de algo exterior à pessoa.