Tabelas fato e tabelas dimensionais fundamentos de DW Modelagem dimensional é uma disciplina de design que transpassa a modelagem relacional e a realidade de dados de texto e números (Kimball) Se comparado com a modelagem entidade/relacionamento, ou simplesmente modelagem relacional, a modelagem dimensional é menos rigorosa (permitido ao modelador mais critérios próprios na organização de tabelas). Porém é mais prático para acomodar grandes volumes de dados para consulta, e tem uma melhor performance. Em contraste com outras disciplinas de modelagem, a modelagem dimensional desenvolveu um extensivo portfólio de tecnicas para tratar situações reais. Mensurações e contexto geral A modelagem dimensional pode começar pela divisão em duas partes: mensuração e contexto. Mensurações são normalmente numéricas e repetidas. Mensurações numéricas são FATOS. Fatos são normalmente cercados por um grande contexto textual (dimensões). Fatos são muito específicas, tem atributos numéricos muito bem definidos. Em contraste, o contexto textual que cerca as tabelas fatos é mais aberto. Não é raro para o modelador adicionar contextos (dimensões) para um set de fatos durante o trabalho de implementação. Embora o modelador possa amarrar todo o contexto dentro grande lógica associada com cada fato, ele normalmente mais conveniente (e intuitivo) dividir o contexto em independentes. Quando você grava fatos (ex.: vendas de uma achará grupos de um
determinado produto em um mês), você natualmente divide o contexto em grupos: produtos, loja, tempo, cliente, caixa e diversos outros. Nós chamamos essa divisão de grupos de dimensões e assumimos informalmente que essas dimensões são independentes, ligadas a um fato (no nosso exemplo, fato VENDA). A figura abaixo dá um exemplo grosseiro de modelo dimensional para um fato venda. Na verdade, dimensões raramente são absolutamente independentes num forte senso estatístico. No exemplo acima, cliente e loja têm uma forte correlação estatística. É a decisão certa modelar CLIENTE e LOJA como dimensões separadas. simples dimensões combinadas poderiam ter 10 milhões de linhas, e o registo de um dado cliente em uma dada loja poderia ser representado mais natualmente numa tabela fato que também representasse a dimensão TEMPO. A abordagem de dimensões independentes poderia significar que todas as dimensões, como por exemplo PRODUTO e CLIENTE são independentes do fato TEMPO. Porém você deve considerar as mudanças esporádicas dessas dimensões à medida que são manipuladas. Administradores de DW devem ficar atentos para representar essas mudanças. Esta situação é aderessada pela técnica de mudanças lentas de dimensões, que postarei posteriormente nesse blog.
Chaves dimensionais Voltando ao nosso exemplo, sabendo que diversos clientes compram diversos produtos em diversas lojas, em diversos tempos diferentes, o modelador logicamente modelará uma tabela fato com diversas FK s referenciando entidades do contexto (tabelas dimensão). E entidades do contexto são cada dimensão com uma simples chave primária, embora você possa separar o desenho lógico do desenho físico, num banco dimensional tabelas fato e dimensão são tabelas explícitas. De fato numa modelagem relacional o banco tem dois níveis de design físico. No nível mais alto, as tabelas são representadas apenas com campos e chaves. No nível mais baixo, elas são representadas com a organização de bits, alocação de disco e memória etc esse design já é mais dependente de um particular SGBD (como Oracle ou SQL Server). Num contexto dimensional, uma tabela fato em um puro star schema consiste de várias FK s, cada uma referenciando uma tabela dimensão. Na figura 1 as chaves na tabela fato são nomeadas FK, e as chaves primárias nas dimensões são Pk s. Fonte: Blog saviobarr Mapa Mental de Data Warehouse - Visão Geral Mapa Mental de Data Warehouse Visão Geral
Data Warehouse - Visão Geral Arquiteturas OLAP Vejam abaixo os conceitos e a demonstração comparativas das arquiteturas OLAP quanto a desempenho, escalabilidade, investimentos e outros detalhes importantes. Conceitos iniciais Cubo de dados é uma estrutura multidimensional que expressa a forma na qual os tipos de informações se relacionam entre si. É formado pela tabela de fatos e pelas tabelas de dimensão que
a circundam e representam possíveis formas de visualizar e consultar os dados. O cubo armazena todas as informações relacionadas a um determinado assunto, de maneira a permitir que sejam montadas várias combinações entre elas, resultando na extração de várias visões sobre o mesmo tema (HOKAMA et al. 2004, p. 49). O Slice/Dice é uma das principais características de uma ferramenta OLAP. É uma operação com responsabilidade de recuperar o micro-cubo dentro do OLAP, além de servir para modificar a posição de uma informação, alterar linhas por colunas de maneira a facilitar a compreensão dos usuários e girar o cubo sempre que tiver necessidade. MOLAP Características: Arquitetura OLAP tradicional; Os dados são armazenados em cubos dimensionais, em formatos proprietários, e não em banco de dados relacionais; O usuário trabalha, monta e manipula os dados do cubo diretamente no servidor. Vantagens: Alto desempenho: os cubos são construídos para uma rápida recuperação de dados; Pode executar cálculos complexos: todos os cálculos são pré-gerados quando o cubo é criado e podem ser facilmente aplicados no momento da pesquisa de dados. Desvantagens: Baixa escalabilidade: sua vantagem de conseguir alto desempenho com a pré-geração de todos os cálculos no
momento da criação dos cubos, faz com que o MOLAP seja limitado a uma pouca quantidade de dados. Esta deficiência pode ser contornada pela inclusão apenas do resumo dos cálculos quando se construir o cubo; Investimentos altos: este modelo exige enormes investimentos adicionais como cubo de tecnologia proprietária. Termos-chave: Armazenamento dos dados em cubos dimensionais e em formato proprietário; Alto desempenho; Execução de cálculos complexos; Baixa escalabilidade; Investimentos altos. ROLAP Características: Os dados são armazenados em banco de dados relacionais; A manipulação dos dados armazenados no banco de dados relacional é feita para dar a aparência de operação Slice/Dice tradicional; Na essência, cada ação de Slice/Dice é equivalente a adicionar uma cláusula WHERE em uma declaração SQL. Vantagens: Alta escalabilidade: usando a arquitetura ROLAP, não há nenhuma restrição na limitação da quantidade dados a serem analisados, cabendo essa limitação sendo do próprio banco de dados relacional utilizado; Pode alavancar as funcionalidades inerentes do banco de dados relacional: Muitos bancos de dados relacionais já vêm com uma série de funcionalidades e a arquitetura
ROLAP pode alavancar estas funcionalidades. Desvantagens: Baixo desempenho: cada relatório ROLAP é basicamente uma consulta SQL (ou várias consultas SQL) na banco de dados relacional e uma consulta pode ser consumir muito tempo se houver uma grande quantidade de dados; Limitado pelas funcionalidades SQL: ROLAP se baseia principalmente na geração instruções SQL para consultar a base de dados relacional, porém essas instruções não suprem todas as necessidades (por exemplo, é difícil de realizar cálculos complexos utilizando SQL). Portanto, usar ROLAP é se limitar ao que instruções SQL podem fazer. Termos-chave: Alta escalabilidade; Pode alavancar as funcionalidades inerentes do banco de dados relacional; Baixo desempenho; Limitado pelas funcionalidades SQL. HOLAP Características: HOLAP tenta combinar as vantagens de MOLAP e ROLAP, extraindo o que há de melhor de cada uma, ou seja, a alta performance do MOLAP com a melhor escalabilidade do ROLAP; Para informações do tipo síntese, HOLAP utiliza cubos dimensionais para um desempenho mais rápido; Quando for necessário mais detalhe de uma informação, HOLAP pode ir além do cubo multidimensional para o banco de dados relacional utilizado no armazenamento dos
detalhes. Vantagens: Alto desempenho: os cubos dimensionais apenas armazenam síntese das informações; Alta escalabilidade: os detalhes das informações são armazenados em um banco de dados relacional. Desvantagens: Arquitetura de o maior custo: é modelo que possui o maior custo de aquisição. Termos-chave: Alto desempenho; Alta escalabilidade; Arquitetura de o maior custo. DOLAP Característica: São as ferramentas que, a partir de um cliente qualquer, emitem uma consulta para o servidor e recebem o cubo de informações de volta para ser analisado na estação cliente. Vantagens: Pouco tráfego que na rede: todo o processamento OLAP acontece na máquina cliente; Sem sobrecarregar o servidor de banco de dados: como todo o processamento acontece na máquina cliente, o servidor fica menos sobrecarregado.
Desvantagem: Limitação do cubo de dados: o tamanho do cubo de dados não pode ser muito grande, caso contrário, a análise passa a ser demorada e/ou a máquina do cliente pode não suportar em função de sua configuração. Termos-chave: Pouco tráfego que na rede; Sem sobrecarregar o servidor de banco de dados; Limitação do cubo de dados. Síntese das arquiteturas em Desempenho, Escabilidade e Custo Síntese das arquiteturas em Desempenho, Escabilidade e Custo Síntese das arquiteturas em Termos-chave
Síntese das arquiteturas em Termos-chave Mapa Mental Mapa Mental de Data Warehouse - Arquiteturas OLAP Autor: Rogério Araújo Mapa Mental de Data Warehouse
Definições Características e Um data warehouse (ou armazém de dados, ou depósito de dados no Brasil) é um sistema de computação utilizado para armazenar informações relativas às atividades de uma organização em bancos de dados, de forma consolidada. O desenho da base de dados favorece os relatórios, a análise de grandes volumes de dados e a obtenção de informações estratégicas que podem facilitar a tomada de decisão. O data warehouse possibilita a análise de grandes volumes de dados, coletados dos sistemas transacionais (OLTP). São as chamadas séries históricas que possibilitam uma melhor análise de eventos passados, oferecendo suporte às tomadas de decisões presentes e a previsão de eventos futuros. Por definição, os dados em um data warehouse não são voláteis, ou seja, eles não mudam, salvo quando é necessário fazer correções de dados previamente carregados. Os dados estão disponíveis somente para leitura e não podem ser alterados. A ferramenta mais popular para exploração de um data warehouse é a Online Analytical Processing OLAP ou Processo Analítico em Tempo Real, mas muitas outras podem ser usadas. Características
Mapa Mental de Data Warehouse - Definições e Características Orientação por assunto A orientação por assunto é uma característica marcante de um DW, pois toda modelagem será voltada em torno dos principais assuntos da empresa. Enquanto todos os sistemas transacionais estão voltados para processos e aplicações específicas, os DWs objetivam assuntos. Integração Facilmente o mais importante aspecto do ambiente de Data Warehouse é que dados criados dentro de um ambiente de Data Warehouse são integrados. SEMPRE. COM NENHUMA EXCEÇÃO. A melhor essência do ambiente de warehouse é que dados contidos dentro dos limites do warehouse estão integrados. A integração mostra-se em muitas diferentes maneiras: na convenção consistente de nomes, na forma consistente das variáveis, na estrutura consistente de códigos, nos atributos físicos consistente dos dados, e assim por diante.
Variância no tempo Segundo W.H.Inmon, os Data Warehouses são variáveis em relação ao tempo, isso nada mais é do que manter o histórico dos dados durante um período de tempo muito superior ao dos sistemas transacionais, vejamos abaixo mais algumas características. Num DW é normal mantermos um horizonte de tempo bem superior ao dos sistemas transacionais, enquanto no OLTP mantemos um histórico curto dos dados, no DW guardamos esses dados num período maior. Isso é bastante lógico porque num sistema transacional a finalidade é de fornecer as informações no momento exato, já no Data Warehouse, o principal objetivo é analisar o comportamento das mesmas durante um período de tempo maior. Fundamentados nessa variação, os gerentes tomam as decisões em cima de fatos e não de intuições. Não volatidade No DW existem somente duas operações, a carga inicial e as consultas dos front-ends aos dados. Isso pode ser afirmado porque a maneira como os dados são carregados e tratados é completamente diferente dos sistemas transacionais. Enquanto nesses sistemas temos vários controles e updates de registros, no DW temos somente inserts e selects de dados. Por exemplo, num sistema de contabilidade podemos fazer alterações nos registros. Já no DW, o que acontece é somente ler os dados na origem e gravá-los no destino, ou seja, no banco modelado multidimensional. As características do Data Warehouse levam a um ambiente que é muito diferente dos ambientes operacionais clássicos. Como a fonte de quase todos os dados do Data Warehouse é o ambiente operacional, é sempre uma tentação pensar que existe uma redundância maciça do dados entre este ambiente o e Data Warehouse. Deve-se considerar os seguintes fatos:
*Os dados são filtrados a medida que passam de um ambiente para o outro *O horizonte de tempo de dados é muito diferente do ambiente operacional para o Data Warehouse *O Data Warehouse possui dados resumidos os quais não são encontrados no ambiente operacional *Os dados sofrem uma transformação fundamental na medida em que passam para o Data Warehouse. Localização Os dados podem estar fisicamente armazenados de três formas: Num único local centralizando o banco de dados em um DW integrado, procurando maximizar o poder de processamento e agilizando a busca dos dados. Esse tipo de armazenagem é bastante utilizada, porém há o inconveniente do investimento em hardware para comportar a base de dados muito volumosa, e o poderio de processamento elevado para atender satisfatoriamente as consultas simultâneas de muitos usuários. Os distribuídos são Data Marts, armazenados por áreas de interesse. Por exemplo, os dados da gerência financeira num servidor, dados de marketing noutro e dados da contabilidade num terceiro lugar. Essa pode ser uma saída interessante para quem precisa de bastante performance, pois isso não sobrecarrega um único servidor, e as consultas serão sempre atendidas em tempo satisfatório. Armazenados por níveis de detalhes, em que as unidades de dados são mantidas no DW. Pode-se armazenar dados altamente resumidos num servidor, dados resumidos noutro nível de detalhe intermediário no segundo servidor e os dados mais detalhados (atômicos), num terceiro servidor. Os servidores da primeira camada podem ser otimizados para suportar um grande número de acessos e um baixo volume de dados, enquanto alguns servidores nas outras camadas podem ser adequados para processar grandes volumes de dados, mas baixo número de
acesso. Para mudar de nível é necessário que ocorra um dos seguintes eventos: os dados são sintetizados, arquivados ou eliminados. O processo de sintetização interage no nível mais alto de detalhamento (dados detalhados atuais) para os níveis seguintes (levemente e altamente resumidos). Quando termina determinado período de tempo (semana, mês, trimestre, ano), os dados são indexados por estes períodos e armazenados nos seus respectivos níveis de detalhamento. Para facilitar o acesso aos dados, estes devem estar sintetizados e indexados de várias maneiras. Portanto, ao mesmo tempo que ocorre o agrupamento por datas, também pode ocorrer a sintetização por grupos e subgrupos. Cada nível possui um horizonte de tempo definido para a permanência dos dados. Então o fato de os dados serem transportados para níveis mais elevados não implica na exclusão do nível anterior. Um processo denominado processo de envelhecimento ocorre quando este limite é ultrapassado, e portanto os dados podem ser transferidos para meios de armazenamentos alternativos ou passar de dados detalhados atuais para dados detalhados antigos. Credibilidade dos Dados A credibilidade dos dados é o muito importante para o sucesso de qualquer projeto. Discrepâncias simples de todo tipo podem causar sérios problemas quando se quer extrair dados para suportar decisões estratégicas para o negócio das empresas. Dados não dignos de confiança podem resultar em relatório inúteis, que não têm importância alguma, assim como uma lista de pacientes do sexo masculino e grávidos, por exemplo.
Granularidade Granularidade nada mais é do que o nível de detalhe ou de resumo dos dados existentes num DW. Quanto maior for o nível de detalhes, menor será o nível de granularidade. O nível de granularidade afeta diretamente o volume de dados armazenados no DW, e ao mesmo tempo o tipo de consulta que pode ser respondida. Fonte: Mapas e Questões Mapa Mental de Data Warehouse - OLAP Mapa Mental de Data Warehouse OLAP Mapa Mental de Data Warehouse - OLAP
Introdução ao Data Warehouse Todos nós sabemos que os bancos de dados são de vital importância para as empresas e também estamos cientes de que sempre foi difícil analisar os dados neles existentes. Hoje em dia, as grandes empresas detêm um volume enorme de dados e esses estão em diversos sistemas diferentes espalhados por ela. Assim, não conseguíamos buscar informações que permitissem tomarmos decisões embasadas num histórico dos dados. Por um outro lado, em cima desse histórico podemos identificar tendências e posicionar a empresa estrategicamente para ser mais competitiva e consequentemente maximizar os lucros diminuindo o índice de erros na tomada de decisão. Por fim, introduziu-se um novo conceito no mercado, o Data Warehouse (DW). Este consiste em organizar os dados corporativos de maneira integrada, com uma única versão da verdade, histórico, variável com o tempo e gerando uma única fonte de dados, que será usada para abastecer os Data Marts (DM). Isso permite aos gerentes e diretores das empresas tomarem decisões embasadas em fatos concretos e não em intuições, cruzando informações de diversas fontes. Isso agiliza a tomada de decisão e diminui os erros. Tudo isso num banco de dados paralelo aos sistemas operacionais da empresa. Segundo a (Aspect International Consulting, 1997), cerca de 88% dos diretores admitem que dedicam quase 75% do tempo às tomadas de decisão apoiadas em análises subjetivas, menosprezando o fato de que por volta de 100% deles tem acesso a computadores. Atualmente esse número deve ter diminuído, porque existem muitos Data Warehouses sendo utilizados.
O que é um Data Warehouse? Um Data Warehouse (ou armazém de dados, ou depósito de dados no Brasil) é um sistema de computação utilizado para armazenar informações relativas às atividades de uma organização em bancos de dados, de forma consolidada. O Data Warehouse é: Orientado a Assunto: A primeira característica de um Data Warehouse é que ele está orientado ao redor do principal assunto da organização. O percurso do dado orientado ao assunto está em contraste com a mais clássica das aplicações orientadas por processos/funções ao redor dos quais os sistemas operacionais mais antigos estão organizados. Integrado: Facilmente o mais importante aspecto do ambiente de Data Warehouse é que dados criados dentro de um ambiente de Data Warehouse são integrados. SEMPRE. COM NENHUMA EXCEÇÃO. A integração mostra-se em muitas diferentes maneiras: na convenção consistente de nomes, na forma consistente das variáveis, na estrutura consistente de códigos, nos atributos físicos consistente dos dados, e assim por diante. Não Volátil: sempre inserido, nunca excluído. Variante no Tempo: posições históricas das atividades no tempo. O data warehouse possibilita a análise de grandes volumes de dados coletados dos sistemas transacionais (OLTP). São as chamadas séries históricas que possibilitam uma melhor análise de eventos passados, oferecendo suporte às tomadas de decisões presentes e a previsão de eventos futuros. Por definição, os dados em um data warehouse não são voláteis, ou seja, eles não mudam, salvo quando é necessário fazer correções de dados previamente carregados. Os dados estão disponíveis somente para leitura e não podem ser alterados. A ferramenta mais popular para exploração de um data warehouse é a Online Analytical Processing OLAP ou Processo Analítico em Tempo Real, mas muitas outras podem ser usadas. Os data
warehouse surgiram como conceito acadêmico na década de 80. Com o amadurecimento dos sistemas de informação empresariais, as necessidades de análise dos dados cresceram paralelamente. Os sistemas OLTP não conseguiam cumprir a tarefa de análise com a simples geração de relatórios. Nesse contexto, a implementação do data warehouse passou a se tornar realidade nas grandes corporações. O mercado de ferramentas de data warehouse, que faz parte do mercado de Business Intelligence, cresceu então, e ferramentas melhores e mais sofisticadas foram desenvolvidas para apoiar a estrutura do data warehouse e sua utilização. Atualmente, por sua capacidade de sumarizar e analisar grandes volumes de dados, o data warehouse é o núcleo dos sistemas de informações gerenciais e apoio à decisão das principais soluções de business intelligence do mercado. Segundo Inmon, Data Warehouse é uma coleção de dados orientados por assuntos, integrados, variáveis com o tempo e não voláteis, para dar suporte ao processo de tomada de decisão. Kimball define assim: é um conjunto de ferramentas e técnicas de projeto, que quando aplicadas às necessidades específicas dos usuários e aos bancos de dados específicos permitirá que planejem e construam um data warehouse. O que o Data Warehouse não é Produto: O Data Warehouse não é um produto e não pode ser comprado como um software de banco de dados. O sistema de Data Warehouse é similar ao desenvolvimento de um ERP, ou seja, ele exige análise do negócio, exige o entendimento do que se quer retirar das informações. Apesar de existirem produtos que fornecem uma gama de ferramentas para efetuar o Cleansing dos dados, a modelagem do banco e da apresentação dos dados, nada disso pode ser feito sem um elevado grau de análise e desenvolvimento. A linguagem: O sistema de Data Warehouse não pode ser
aprendido ou codificado como uma linguagem. Devido ao grande número de componentes e de etapas, um sistema de Data Warehouse suporta diversas linguagens e programações desde a extração dos dados até a apresentação dos mesmos. Projeto: O sistema de Data Warehouse pode ser pensado mais como um processo. Ele também pode ser pensado como uma série de projetos menores que convergem para a criação de um único sistema de corporativo de Data Warehouse. Devido a natureza evolutiva do DW, é mais fácil aceitá-lo como um processo que está sempre em crescimento do que em um projeto com iníciomeio-fim, o que definitivamente ele parece mas não é. Modelagem: O sistema de Data Warehouse não é somente um modelo de banco de dados e não é constituído por mais de um modelo. Existe o processo todo do sistema de BI/DW que compreende todos os procedimentos de ETL, Cleansing e apresentação das informações ao usuário final. Cópia do sistema OLTP: Alguns acreditam que o sistema de Data Warehouse é somente uma cópia do sistema transacional existente na empresa. Assim como somente um modelo de dados não faz um sistema de BI/DW, uma cópia de um sistema transacional o faz menos ainda. Existem ferramentas que conseguem extrair dados dos sistemas transacionais existentes e criar relatórios a partir das informações coletadas, mas mesmo eles estão montando um pequeno conjunto de metadados e armazenando a informação em algum local. Importante saber sobre Data Warehouse Um dos maiores problemas no desenvolvimento do DW é a compreensão dos dados, onde as dimensões devem ser definidas conforme a necessidade de visualização do usuário, ou seja, é tentador pensar que a criação do DW
consiste em apenas extrair dados operacionais e inserilos no Data Warehouse. O valor de DW não está em colecionar dados e sim saber gerenciar aqueles dados sendo transformados em informações úteis. Considerando complexa a construção de um DW, faz-se necessário um amplo estudo para geração de uma metodologia a fim de se obter sucesso no empreeendimento. Além disso, é necessário saber a respeito de algumas questões que representam verdadeiro desafio na implementação de um Data Warehouse: Integração de dados e metadados de várias fontes. Qualidade dos dados: limpeza e refinamentos. Sumarização e agregação de dados. Sincronização das fontes com o Datawarehouse para assegurar a atualização. Problemas de desempenho relacionados ao compartilhamento do mesmo ambiente computacional para abrigar as bases de dados corporativas operacionais e o Data Warehouse. Armazenamento Um Data Warehouse pode armazenar grandes quantidades de informação, às vezes divididas em unidades lógicas menores que são chamadas de Data Marts. O esquema de dados mais utilizado é o Star Schema (Esquema Estrela), também conhecido como Modelagem Multidimensional. Apesar de bastante utilizado, não existe um padrão na indústria de software para o armazenamento de dados. Existem, na verdade, algumas controvérsias sobre qual a melhor maneira para estruturar os dados em um Data Warehouse. Geralmente, o Data Warehouse não armazena informações sobre os processos correntes de uma única atividade de negócio, mas sim cruzamentos e consolidações de várias unidades de negócios de uma empresa.
Modelagem Os sistemas de base de dados tradicionais utilizam a normalização, no formato de dados para garantir consistência dos dados e uma minimização do espaço de armazenamento necessário. Entretanto, frequentemente as transações e consultas em bases de dados normalizadas são lentas. Um Data Warehouse utiliza dados em formato mais de-normalizados. Isto aumenta a performance adicional, o processo das consultas torna-se mais e, como benefício intuitivo para os utilizadores comuns. Metadado O conceito Metadado é considerado como sendo os dados sobre dados, isto é, os dados sobre os sistemas que operam com estes dados. Um repositório de metadados é uma ferramenta essencial para o gerenciamento de um Data Warehouse no momento de converter dados em informações para o negócio. Entre outras coisas, um repositório de metadados bem construído deve conter informações sobre a origem dos dados, regras de transformação, nomes e alias, formatos de dados, etc. Ou seja, esse dicionário deve conter muito mais do que as descrições de colunas e tabelas: deve conter informações que adicionem valor aos dados. Tipo de Metadado Informação considerada Os metadados são utilizados normalmente como um dicionário de informações e, sendo assim, devem incluir: Origem dos Dados Todo elemento de dado precisa ter identificado, sua origem ou o processo que o gera. Esta identificação é muito importante no caso de se necessitar
saber informações sobre a fonte geradora do dado. Esta informação deve ser única, ou seja, cada dado deve ter uma e somente uma fonte de origem. Fluxo de Dados Todo elemento de dado precisa ter identificado os fluxos nos quais sofre transformações. É importante saber que dados servem de base para que processos. Formato dos Dados Todo elemento de dados identificado seu tamanho e tipo de dado. deve ter Nomes e Alias Todo elemento de dados deve ser identificado por um nome. Este nome pode ser da Área de Negócios ou um nome técnico. No caso de serem usados alias para os nomes, pode-se ter os dois. Devem existir padrões para criação de nomes e alias (ex.: convenções para abreviações), evitando assim ambigüidades. Definições de Negócio Estas definições são as informações mais importantes contidas nos metadados. Cada elemento de dado deve ser suportado por uma definição do mesmo no contexto da Área de Negócio. O método de manutenção destas informações também deve ser muito consistente, de forma que o usuário possa obter facilmente definições para as informações desejadas. Nestas definições devem ser evitadas referências a outros metadados que necessitem de uma segunda pesquisa para melhor entendimento. Regras de Transformação São consideradas como sendo as Regras de Negócio codificadas. Estas regras são geradas no momento da extração, limpeza e agrupamento dos dados dos Sistemas Operacionais. Cada regra de transformação codificada deve estar associada a um elemento de Metadado. Se mais de uma aplicação contiver a mesma regra de transformação, deverá ser garantido que estas sejam idênticas. Atualização de Dados O histórico das atualizações normalmente é mantido pelo próprio banco de dados, mas definir um elemento de metadado, indicando as datas de atualização dos
dados, pode ajudar o usuário no momento de verificar a atualidade dos dados e a consistência da dimensão tempo do Data Warehouse. Requisitos de Teste Identifica os critérios de julgamento de cada elemento de dado. Valores possíveis e intervalos de atuação. Deve conter também padrões para procedimentos de teste destes dados. Indicadores de Qualidade de Dados Podem ser criados índices de qualidade baseados na origem do dado, número de processamentos feito sobre este dado, valores atômicos X valores sumariados, nível de utilização do dado, etc. Triggers Automáticos Podem existir processos automáticos associados aos metadados definidos. Estes processos ou triggers devem estar definidos de forma que possam ser consultados por usuário e desenvolvedores, para que os mesmos não venham a criar situações conflitantes entre as regras definidas nestes processos. Responsabilidade sobre Informações Deve ser identificado o responsável por cada elemento de dados do Data Warehouse e também o responsável pela entrada de metadados. Acesso e Segurança Os metadados devem conter informação suficiente para que sejam determinados os perfis de acesso aos dados. Deve-se poder identificar que usuários podem ler, atualizar, excluir ou inserir dados na base. Deve haver, também, informações sobre quem gerencia estes perfis de acesso e como se fazer contato com o Administrador da Base de Dados. Data Marts O Data Warehouse é normalmente acedido através de Data Marts, que são pontos específicos de acesso à subconjuntos do Data Warehouse. Os Data Marts são construídos para responder prováveis perguntas de um tipo específico de usuário. Por
exemplo: um Data Mart financeiro poderia armazenar informações consolidadas dia-a-dia para um usuário gerencial e em periodicidades maiores (semana, mês, ano) para um usuário no nível da diretoria. Um Data Mart pode ser composto por um ou mais cubos de dados. Hoje em dia, os conceitos de Data warehouse e Data Mart fazem parte de um conceito muito maior chamado de Corporate Performance Management. Extração de Dados Os dados introduzidos num Data Warehouse geralmente passam por uma área conhecida como área de stage. O stage de dados ocorre quando existem processos periódicos de leitura de dados de fontes como sistemas OLTP. Os dados podem passar então por um processo de qualidade, denormalização e gravação dos dados no Data Warehouse. Esse processo geralmente é realizado por ferramentas ETL. Os Processos Warehouse de Data
Processos de Data Warehouse Sistemas operacionais de origem São os sistemas operacionais de registro ou sistemas transacionais que capturam as transações da empresa. Os sistemas de origem devem ser considerados como externos ao data warehouse porque se presume que se tenha pouco ou nenhum controle sobre o conteúdo e o formato dos dados nesses sistemas. Os sistemas de origem também são chamados Sistemas Legados ou OLTP; A data staging área É tanto uma área de armazenamento como um conjunto de processos, e normalmente denomina-se ETL (Extract Transformation Load). Data Warehouse e Data Mart A área de apresentação dos dados é o local em que os dados ficam organizados, armazenados e tornam-se disponíveis para serem consultados diretamente pelos usuários, por criadores de relatórios e por outras aplicações de análise. Essa área é tudo o que a comunidade de negócio vê e acessa através das ferramentas de acesso a dados (DB2,
ESSBASE, etc). Um data mart trata de problema departamental ou local e é definido como um subconjunto altamente agregado de dados, normalmente escolhido para responder a uma questão de negócio específica ao invés da corporação inteira; Ferramenta de acesso a dados O último componente principal do ambiente de data warehouse é a ferramenta de acesso a dados. Por definição, toda ferramenta de acesso a dados consulta os dados na área de apresentação do DW. Conclusão Através dessas novas tecnologias como o Data Warehouse, permitirá aos administradores descobrir novas maneiras de diferenciar sua empresa numa economia globalizada, deixando-os mais seguros para definirem as metas e adotarem diferentes estratégias em sua organização, conseguindo assim visualizarem antes de seus concorrentes novos mercados e oportunidades atuando de maneiras diferentes conforme o perfil de seus consumidores. Fonte: Data Warehouse por Marcell Oliveira