Custos de implantação de DMs e DW

Por serem menores, os DMs possuem uma implantação mais rápida do que o DW, porém utilizam a mesma abordagem. De acordo com Sowek (2009):

o maior atrativo para implementar um Data Mart é seu custo e prazo. Segundo estimativas, enquanto um DM custa em torno de R$ 100 mil a R$1 milhão e leva cerca de 120 dias para estar pronto, um DW integral começa em torno dos R$ 2 milhões e leva cerca de um ano para estar consolidado.

Mas não existe um projeto padrão que possa ser implementado em todas as empresas. Assim, estes valores citados por Sowek e mostrados na quadro, são apenas estimativas, pois o investimento para o projeto do DW depende de cada caso.

Comparação entre implantação de DM e de DW.

	Data mart	Data warehouse
Tamanho	De 50 GB a 250 GB	Vários terabytes ou mais
Propósito	Área ou assunto específico Visão departamental	Repositório da organização Visão corporativa
Como iniciar	Bottom-up	Top-down
Controle	Departamental	Sistema de Informação
Tempo Implementação	3 a 6 meses	1 até 2 anos
Custo Implementação	De R$ 100.000 a R$ 1.000.000	Milhões de reais

Fonte: SOWEK, 2009.

 

TCO – Total Cost of Ownership.

Fonte: Biz Idea Production/Shutterstock.

De acordo com Bedi (2015), a melhor forma de analisar dados vindos de múltiplas fontes é usando um DW. Mas, independentemente do uso de data warehousing, a tecnologia tem um custo alto (TCO – Total Cost of Ownership), incluindo custos diretos e indiretos, como software, hardware, recursos humanos etc. Todos estes custos devem ser considerados antes que uma empresa inicie a implantação do DW e/ou DMs.

Ainda de acordo com o autor, os custos são assim definidos:

• Software: O software necessário para executar um DW não vem com o hardware, por isso licenças têm que ser adquiridas para atender a demanda da empresa. Mesmo começando em poucos milhares de dólares, esse custo pode subir muito. O pleno funcionamento do DW inicia-se depois da carga de terabytes de dados e o volume de dados tende a crescer. Os custos também crescem a partir do aumento do número de usuários, aquisição de mais licenças e mais servidores etc.
• Hardware: A aquisição de hardware poderoso o suficiente para suportar e executar consultas complexas resulta em altos custos. Um DW necessita de servidores para executar software especializado, espaço em data center para os servidores, hardware para armazenamento de big data, rede de computadores de alta velocidade para acesso aos dados do DW, hardware para a redundância de dados etc. Estes custos tendem a aumentar na medida em que o volume de dados e de consultas aumenta, refletindo no aumento de todos os componentes de hardware que suportam o DW.
• Pessoas: Mesmo que haja software e hardware adequados, esforços humanos são essenciais para gerir e manter o ambiente de DW. Além disso, o pessoal do departamento de TI e usuários regulares têm que ser capacitados e treinados para usar efetivamente todo o aparato. Isso implica igualmente em custos crescentes.

Em função do exposto, o TCO resultante da soma dos cursos de software, hardware e pessoas para construção de um DW pode ser muito grande. Bedi (2015), entretanto, pondera que algumas tecnologias podem contribuir para a redução de custos, como o uso de Data Warehouse as a Service (DWaaS).

DWaaS pode significar a utilização de software sob medida, pagando-se pelo uso de licenças, no modelo pay-as-you-go. Em relação ao hardware, o mesmo pode ser contratado sob demanda, de forma que passe do modelo de capital expenditure (capex) para o modelo operational expenditure (opex) baseado em taxas de uso por hora ou por mês. Desta forma, o hardware pode ser aumentado de forma elástica, sob demanda. Negócios baseados em DWaaS especializados em DW podem reduzir os custos de US$ 20 mil a US$ 40 mil dólares por terabyte para US$ 1.000 a US$ 5.000 dólares por terabyte. Com a contratação de software e hardware, os custos com pessoal também são reduzidos.

Saiba mais     

Data warehouse ou Data mart?

“Ralph Kimball é um defensor da teoria de que o DW deve ser dividido para depois ser conquistado, ou seja, que o mais viável para as empresas é desenvolver vários Data Marts para posteriormente integrá-los e, assim, chegar-se ao DW. Na sua avaliação, as empresas devem construir Data Marts orientados por assuntos. Ao final, teriam uma série de pontos de conexão entre eles, que seriam as tabelas Fato e Dimensão em conformidade. Dessa forma, informações entre os diferentes Data Marts poderiam ser geradas de maneira íntegra e segura. Kimball batizou esse conceito de Data Warehouse Bus Architeture.

Bill Inmon rebate essa teoria e propõe justamente o contrário. Na sua avaliação deve-se construir primeiro um Data Warehouse, modelando-se toda a empresa para se chegar a um único modelo corporativo, partindo-se posteriormente para os Data Marts construídos por assuntos ou departamentais. Inmon defende a ideia de que o ponto de partida seriam os CIF – Corporate Information Factory – uma infraestrutura ideal para ambientar os dados da empresa. O CIF seria alimentado pelos sistemas transacionais. A construção de um ODS- Operational Data Store seria facultativa, mas essa iniciativa ajudaria a reduzir a complexidade da construção de um DW, uma vez que todo o esforço de integração entre os sistemas transacionais da empresa seria depositado nele.”

(Fonte: <social.technet.microsoft.com>)

Data Marts

Data Mart(DM), na definição de Machado (2012, p. 45), é um subconjunto de dados do DW que permite acesso descentralizado, servindo de fonte para os dados que comporão os bancos de dados individuais, conforme pode ser visto na figura.

Data Marts e Data Warehouse.

Fonte: <slideplayer.com.br>.

Um ponto a destacar aqui é que o Data Mart pode ser tratado como um projeto-piloto para que a empresa conheça os benefícios da tecnologia antes da decisão de construir um DW.

(Fonte: MACHADO, 2012, p. 46)

Conforme vimos, o projeto do DW pode ser implementado usando uma arquitetura de DMs independentes ou integrados.

Na arquitetura independente, os DMs fornecem suporte à decisão para os grupos de usuários ou departamentos, desempenhando o papel de um DW departamental, sem foco corporativo.

Na arquitetura integrada, os DMs, apesar de serem implementados separadamente por grupos de usuários ou departamentos, são integrados ou interconectados, permitindo uma visão corporativa dos dados.

Vários tipos de implementação dos DMs nas arquiteturas independente e integrada podem ser usados. Vamos tratar aqui apenas duas destas abordagens: top-down e botton-up.

A abordagem top-down consiste em implementar os DMs a partir da implementação do DW. Neste ambiente os dados são resumidos, dimensionados e distribuídos para um ou mais DMs dependentes, como mostra a figura abaixo. Estes DMs são “dependentes” porque eles derivam todos os seus dados de um DW centralizado.

Arquitetura top-down de DMs.

Fonte: <dataprix.net>.

De acordo com Machado (2012, p. 54), as vantagens da implementação top-down podem ser assim definidas:

• Herança de arquitetura: todos os DM originados de um DW utilizam a arquitetura e os dados desse DW, permitindo uma fácil manutenção.
• Visão de empreendimento: o DW concentra todos os negócios da empresa, sendo possível extrair dele níveis menores de informações.
• Repositório de metadados centralizado e simples: o DW provê um repositório de metadados central para o sistema. Essa centralização permite manutenções mais simples do que aquelas realizadas em múltiplos repositórios.
• Controle e centralização de regras: a arquitetura top-down garante a existência de um único conjunto de aplicações para extração, limpeza e integração dos dados, além de processos centralizados de manutenção e monitoração.

Mas esta abordagem também apresenta desvantagens, e Machado (2012, p. 54) elenca como as principais:

• Implementação muito longa: os DWs são, normalmente, desenvolvidos de modo iterativo, separados por áreas de assuntos, como, por exemplo, vendas, finanças e recursos humanos. Mesmo assim, são necessários, em média, 15 ou mais meses para que a primeira área de assunto entre em produção, dificultando a garantia de apoio político e orçamentário.
• Alta taxa de risco: não existem garantias para o investimento nesse tipo de ambiente.
• Heranças de cruzamentos funcionais: é necessária uma equipe de desenvolvedores e usuários finais altamente capacitados para avaliar as informações e consultas que garantam à empresa habilidade para lidar com as mudanças de competições políticas, geográficas e organizacionais.
• Expectativas relacionadas ao ambiente: a demora do projeto e a falta de retorno podem induzir expectativas nos usuários.

Já na abordagem bottom-up os DMs são organizados de forma independente, representando determinadas áreas setoriais ou departamentos da empresa e, após sua implementação, parte-se para a construção do DW. Assim, o DW será corporativo, representando o conjunto de todos os assuntos da empresa de forma que o suporte à decisão atue em todos os níveis da organização. A figura mostra esta configuração.

Arquitetura bottom-up deDMs.

Fonte: <dataprix.net>

De acordo com Machado (2012, p. 56), as vantagens da implementação bottom-up são:

• Implementação rápida: a construção dos DMs é altamente direcionada, permitindo um rápido desenvolvimento. Normalmente, um DM pode ser colocado em produção em um período de seis a nove meses.
• Retorno rápido: a arquitetura baseada em DM com incremento demonstra rapidamente seu valor, permitindo uma base para investimentos adicionais com um nível mais elevado de confiança.
• Manutenção do enfoque da equipe: A elaboração de DMs incrementais permite que os principais negócios sejam enfocados inicialmente, sem que haja gastos no desenvolvimento de áreas que não são essenciais ao problema.
• Herança incremental: a estratégia de DMs incrementais obriga a entrega de recursos de informação passo a passo. Isso permite à equipe crescer e aprender, reduzindo os riscos. A avaliação de ferramentas, tecnologias, consultores e vendedores só deve ser realizada uma vez, a não ser que existam restrições que impeçam o reaproveitamento”.

Mas suas desvantagens, ainda segundo Machado (2012, p. 56), incluem:

• Perigo de ‘legamarts’: um dos maiores perigos na arquitetura de DW é a criação de DMs independentes. O advento de ferramentas drag-and-drop (clique e arraste) facilitou o desenvolvimento de soluções individuais de acordo com as necessidades da empresa. Essas soluções podem não considerar a arquitetura de forma global. Desse modo, os DMs independentes transformam-se em DMs legados, ou legamarts que dificultam, quando não inviabilizam, futuras integrações. Eles são parte do problema e não da solução.
• Desafio de possuir a visão de empreendimento: durante a construção dos DMs incrementais, é necessário que se mantenha um rígido controle do negócio como um todo. Esse controle requer maior trabalho ao extrair e combinar as fontes individuais do que utilizar um DW.
• Administrar e coordenar múltiplas equipes e iniciativas: normalmente, esse tipo de arquitetura emprega o desenvolvimento de DMs em paralelo. Isso pode conduzir a uma rígida administração, tentando coordenar os esforços e recursos das múltiplas equipes, especialmente nas áreas de regras e semântica empresariais.

Extract, Transform and Load (ETL)

Staging Area

De acordo com Kimball e Caserta (2004, p. 65), a decisão de se armazenar os dados fisicamente em uma staging area ou processá-los em memória depende de dois objetivos conflitantes: obter os dados das fontes para o destino tão rápido quanto possível e manter a habilidade de se recuperar de falhas sem ter que reiniciar o processo. Os autores indicam que há vantagens em se usar staging area, como: ter pontos de recuperação de dados; utilizar este repositório como backup de dados; e possibilitar a auditoria do processo de ETL.

Quando o histórico dos dados é mantido, a staging area é persistente, e quando os dados são apagados em cada carga, esta área é considerada transitória. Mas é interessante que a staging area assume uma forma híbrida, sendo composta de tabelas persistentes e transitórias.

Extract (Extração)

A extração é a primeira etapa do processo de ETL para obtenção dos dados no ambiente do DW. Consiste basicamente em ler, entender e copiar os dados necessários dos sistemas-fontes para a área de transformação de dados para utilizá-los posteriormente. O principal objetivo é recuperar todos os dados requeridos das fontes utilizando tão poucos recursos quanto for possível, sem afetar os sistemas-fontes em seu desempenho, tempo de resposta e bloqueios (KIMBALL; CASERTA, 2004).

Os dados extraídos são originados de diversas fontes independentes, que podem ser sistemas transacionais (OLTP), planilhas Excel, sistemas legados de diversos fabricantes, dentre outras.

De acordo com Dataintegration.com (2015), há algumas diferentes formas de se realizar a extração:

• Notificação de atualização: se o sistema fonte for capaz de fornecer uma notificação quando um registro for alterado e descrever esta alteração, esta é a forma mais fácil de obter dados.
• Extração incremental: há sistemas fonte que não são capazes de fornecer notificação quando uma atualização ocorre, mas conseguem identificar quais registros foram modificados e fornecer a extração de tais registros. Isso será importante em passos posteriores do ETL, quando o sistema precisar identificar as mudanças e propagá-las. O cuidado a ser tomado neste caso é que, usando extração diária, pode-se não tratar registros excluídos adequadamente.
• Extração completa: alguns sistemas fonte não conseguem identificar nenhuma mudança, desta forma a extração completa é a única maneira de obter dados destes sistemas. A extração completa requer que uma cópia da última extração seja mantida no mesmo formato e ordem para se que possa identificar as mudanças. Este processo também trata as exclusões.

Quando a extração incremental ou completa forem utilizadas, a frequência da extração é muito importante, notadamente na completa, na qual grandes volumes de itens são tratados.

Transformation (Transformação)

Após a extração dos dados, são aplicadas transformações de acordo com as regras de negócio da organização. São exemplos de transformações: geração de novas chaves; conversão de tipos; formatação de campos; definição de valores derivados; agregações; sumarizações; traduções; entre outras operações.

A integração das informações originadas de múltiplas e complexas fontes de dados também é realizada nesta fase. Grandes riscos ocorrem quando as regras de transformações e integrações não são definidas claramente, resultando em cargas de informações equivocadas, o que pode gerar consequências imprevisíveis nas próximas fases do projeto.

Para garantir a qualidade dos dados no DW, deve ocorrer, nesta fase, a limpeza dos dados que aplica regras para a unificação dos dados básicos, como:

• Unificar identificadores, como nomes e categorias de sexo expressas de diversas formas em diferentes fontes, que devem ser expressas de uma única forma;
• Converter valores nulos em padrões, como não disponível, por exemplo;
• Converter números de telefone, CEP e datas em formatos únicos padronizados;
• Validar campos de endereços e convertê-los para formatos padronizados, como ruas, avenidas, estado, cidade etc.

A figura ilustra este processo.

Exemplo de transformação e limpeza no processo de ETL.

Fonte: <player.slideplayer.com.br>.

 Load (Carga)

Para iniciar a etapa de carga, os dados devem estar no formato apropriado, com as devidas limpeza e transformação aplicadas. Esta etapa possui grande complexidade, pois é necessário considerar os seguintes fatores:

• Integridade dos dados: consiste em validar todas as chaves estrangeiras da tabela, analisando se os valores realmente existem nas tabelas de origem, que contêm a chave primária.
• Tipo de carga (incremental ou total): na carga inicial do DW é usual fazer a carga total, que contempla todos os dados oriundos do sistema-fonte. Nos processos de carga realizados posteriormente é usual que seja feita somente a carga incremental, que contempla somente os registros novos e alterados desde a carga anterior, gerando, assim, menor tempo de processamento e menor tráfego na rede.

No processo de carga dos dados pode-se utilizar um mecanismo de defesa, chamado Quality Assurance, ou Garantia de Qualidade de Dados. Este mecanismo evita que sejam carregadas massas de “lixo” para dentro das bases, como dados nulos, brancos ou inconsistentes.

Durante a etapa de carga, é necessário garantir que sua execução seja realizada corretamente, com menos recursos quanto possível. O alvo do processo de carga é geralmente uma base de dados e, para tornar o processo eficiente, é útil desabilitar quaisquer restrições e índices antes da carga e habilitá-los após o processo completo. A integridade referencial precisa ser mantida pela ferramenta de ETL para garantir a consistência.

Por ser a última etapa do ETL, após o sucesso em sua execução, o DW ou o DM ficarão disponíveis com os dados íntegros e históricos para as análises realizadas nas fases posteriores do desenvolvimento do projeto.

Ferramentas para construção e consultas a um DW

Etapas e componentes da implantação de um ambiente de apoio à decisão

O processo de criação de um ambiente que suporte adequadamente a tomada de decisões corporativas envolve a construção de um grande repositório de dados, o DW, que é realizado em diversas etapas e utiliza ferramentas de apoio específicas, que podem ser resumidas em:

1. Fontes de dados: os dados podem vir de sistemas transacionais, de ERPs (sistemas integrados de gestão), de sistemas legados ou de diversas outras fontes, como bancos de dados transacionais, planilhas e arquivos-texto.
2. ETL: os dados são extraídos das diversas fontes, transformados e carregados nos DMs e/ou no DW por meio de ferramentas especiais que realizam o processo de ETL.
3. Ferramentas OLAP: “navegam” nos dados do DW para realizar pesquisas e apresentar as informações de forma adequada aos tomadores de decisão.
4. Ferramentas de análise de big data e data mining: ferramentas para análise de big data e de mineração de dados procuram padrões ocultos, utilizando modelos matemáticos, nas coleções de dados de forma a transformá-los em informações úteis para se prever tendências e comportamentos futuros e se alcançar metas de negócios específicas. Dentre as ferramentas de data mining encontram-se as de text mining, que procuram padrões ocultos nos arquivos de textos puros, e as de web mining, que procuram os padrões em páginas da web.
5. Ferramentas de monitoramento: as ferramentas de monitoramento e visualização são mais fáceis de serem implementadas quando os dados estão armazenados em um DW. As ferramentas OLAP também podem se beneficiar do DW mostrando as informações de forma tridimensional, ou na forma de cubos.

A figura ilustra estas etapas.

Etapas para implantação de um ambiente de suporte à decisão.

Fonte: Elaborado pela autora

Nas seções seguintes, os conceitos e definições de data mart, processo de ETL, OLAP, big data, data mining, incluindo text e web mining, e ferramentas de monitoramento serão apresentados.

Extract, Transform and Load (ETL)

ETL (Extract, Transform and Load ou Extração, Transformação e Carga) é o processo de extrair os dados de uma ou várias fontes, transformá-los de alguma forma sem alterar seu conteúdo e inseri-los em outro banco de dados, que, no caso de nosso estudo, é o DW.

Os processos ETL são considerados como uma das fases mais complexas do ciclo de vida do DW, pois envolve diversas fontes de dados, transformações e critérios de qualidade que preparam os dados para o DW. Estes processos são realizados através de automatizações que podem ser programadas (scheduling) para execução diária, semanal, mensal, dentre outras possibilidades.

O ETL consiste na extração de dados dos sistemas transacionais, transformação e carga destes dados de acordo com as regras de negócio da empresa, garantindo o controle de qualidade dos dados para sua publicação e posterior uso.

(Fonte: traduzido de KIMBALL e CASERTA, 2004)

O processo de ETL para a construção de um DW pode contar ou não com uma staging area ou ODS (Operational Data Store), sendo uma decisão do projeto. De acordo com Machado (2012, p. 39), em projetos que envolvam vários tipos de bancos de dados ou diferentes plataformas nos quais as fontes de dados estejam distribuídas, a staging area torna-se muito importante para que os dados possam ser ali integrados e limpos.

A figura ilustra o processo de ETL com staging area.

Processo ETL usando staging area.

Fonte: <dbbest.com>

Arquitetura de DMs independentes

É a arquitetura normalmente sugerida pelos fornecedores de software para consulta de informações no DW, pois é isolada e agrada os usuários.

De acordo com Machado (2012, p. 51),

a arquitetura independente implica em Data Marts stand alone controlados por um grupo específico de usuários e que atende somente às suas necessidades específicas e departamentais, sem foco corporativo nenhum. Este fato faz com que não exista nenhuma conectividade desses Data Marts com outros Data Marts de outros departamentos ou áreas de negócio.

Nesta abordagem, cada departamento realiza a extração dos dados dos seus sistemas transacionais, com apoio do setor de TI. O setor de TI somente auxilia na manutenção técnica do ambiente, não sendo responsável pelo controle da implementação e do desenvolvimento do DW. Caso existam dados externos a serem utilizados, o setor de TI deve ser envolvido para orientar a adequação dos formatos de arquivos e demais aspectos técnicos.

A figura ilustra esta arquitetura.

 Arquitetura de DMs independentes.

Fonte: MACHADO, 2012, p. 52.

A arquitetura independente requer profissionais de TI especializados, mas tanto a equipe operacional quanto os recursos podem ser administrados pelo grupo responsável pelo projeto do DW ou pelo próprio departamento.

Esse tipo de arquitetura impacta pouco nos recursos de TI e geralmente sua implementação é rápida. Porém, resulta em repositórios com pouca integração corporativa, que não permite visão global da empresa.

Normalmente cada DM fica acessível apenas ao pessoal do departamento “proprietário” do DM. Machado (2012) afirma que, infelizmente, esta é uma situação muito comum no Brasil e também bastante disseminada pelo mundo, reflexo do foco de negócios de venda de produtos sugerida pelos fornecedores de software, como já dissemos.

Arquitetura de DM integrados

De acordo com Machado (2012, p. 52),

a arquitetura de Data Marts integrados é basicamente uma distribuição da implementação do DW. Apesar de os Data Marts serem implementados separadamente por grupos de trabalho ou departamentos, eles são integrados ou interconectados, fornecendo uma visão corporativa maior dos dados e informações. Neste caso, o alto nível de integração é similar ao da arquitetura global e os usuários de um departamento podem acessar e utilizar os dados de um Data Mart de outro departamento.

Essa arquitetura, comparada à arquitetura de DMs independentes, permite muitas outras funções e acesso às informações. Entretanto, a integração dos DMs aumenta muito o nível de complexidade dos requisitos do ambiente. Isso requer que o setor de TI atue de forma mais incisiva do que na arquitetura independente, ficando sob sua responsabilidade o controle e administração dos Data Marts, em um ambiente mais complexo. Em contrapartida, esta arquitetura apresenta como vantagem a ampliação da capacidade e da qualidade da visão corporativa das informações.

A figura ilustra esta arquitetura.

Arquitetura de DMs integrados.

Fonte: MACHADO, 2012, p. 53.

Arquitetura de DW

A escolha da arquitetura pode não ser prioridade no começo de um projeto de DW, pois pode ser definida ou mesmo modificada após o início da implementação. Entretanto, pode-se despender um longo tempo caso seja esta a opção inicial.

A escolha da arquitetura do DW é uma decisão gerencial do projeto, normalmente baseada em fatores relativos à infraestrutura disponível, às características do negócio (porte da empresa), ao escopo desejado, à capacitação dos empregados da empresa e, principalmente, ao orçamento disponibilizado ou projetado para o investimento.

A abordagem de implementação escolhida é uma decisão que pode causar fortes impactos quanto ao sucesso de um projeto de DW. Muitas variáveis afetam a escolha da implementação e da arquitetura, entre elas o tempo para a execução do projeto, o retorno do investimento a ser realizado, a velocidade dos benefícios da utilização das informações, a satisfação do usuário executivo e os recursos necessários à implementação da arquitetura.

A seleção de uma arquitetura determinará ou será determinada pelo local onde o DW ou os DMs serão armazenados. Há diversas opções que podem ser determinantes na definição da arquitetura, por exemplo: os DMs podem residir em uma instalação central, podem ser distribuídos em instalações remotas ou locais, podem ser administrados de forma centralizada ou independente.

A seguir apresentaremos as principais arquiteturas e exporemos sua configuração básica.

3.5.1 Arquitetura global

De acordo com Machado (2012, p. 50),

a arquitetura global é a que suporta toda ou a maior parte dos requisitos ou necessidades de um Data Warehouse integrado com grande grau de acesso e utilização das informações para todos os departamentos de uma empresa. O termo global reflete o escopo de acesso e utilização das informações na empresa e significa apenas “por toda a empresa”.

Nesta abordagem, o DW é projetado e construído com base nas necessidades da empresa como um todo, como um repositório comum de dados de suporte à decisão, acessível em toda a empresa e disponível para todos da empresa.

A arquitetura global pode ser fisicamente centralizada ou fisicamente distribuída nas instalações de uma organização.

• A centralização física é utilizada quando a organização tem sede única em um único lugar e o DW é administrado por um departamento de TI.
• A distribuição física é utilizada quando a organização tem sede e outras filiais em diversos locais físicos e os dados estão em instalações físicas diferentes. A administração também é feita por um departamento de TI.

Dizer que um departamento de TI administra o DW não significa dizer que esse departamento realiza o controle do DW. Por exemplo, na arquitetura global fisicamente distribuída o DW pode ser controlado por um outro departamento, como o de Planejamento Estratégico, que fica responsável por decidir quais dados devem ser carregados no DW, quando deve ser realizada a carga incremental ou sua atualização e quais setores e pessoas terão direito de acesso aos dados.

O departamento de TI e seus profissionais realizam a administração e a implementação do DW, notadamente porque é o TI que administra as redes de comunicação de dados da empresa e sua infraestrutura associada.

A figura abaixo ilustra os dois caminhos de utilização de uma arquitetura global para DW. No topo da figura você pode observar que o DW está distribuído em três instalações físicas, e na parte de baixo, o DW reside em uma única instalação.

Arquitetura global centralizada e distribuída.

Fonte: MACHADO, 2012, p. 51.

Os dados são extraídos de sistemas transacionais e de fontes de dados externas por processos batch, ou seja, em lote em horários de baixa das operações. Os dados são filtrados, aqueles não necessários são excluídos e a transformação é realizada visando atender critérios de qualidade e respeitar os requisitos levantados para o projeto. Após este processo, os dados são então carregados para o DW para que os usuários finais tenham acesso a eles.

Machado (2012) afirma que a arquitetura global habilita os usuários finais a utilizar visões corporativas de dados, que normalmente são requisitos de negócio, e alerta que esse tipo de arquitetura consome muito tempo de desenvolvimento e administração, e tem a desvantagem que seu custo de implementação é muito elevado.

Etapas de implantação de um DW

 O que são metadados?

O prefixo “Meta” vem do grego e significa “além de”. Assim Metadados são informações que são acrescidas aos dados e que têm como objetivo informar-nos sobre eles para tornar mais fácil a sua organização.

Os metadados têm tradicionalmente sido vistos como separados do núcleo duro da informação, ou seja, a que está relacionada com as transações de negócio. O que não quer dizer que não sejam importantes. Definições e regras de negócio, detalhes de segurança, informação de domínios, tags XML são metadados.

A sua utilização estende-se, no entanto, a outros campos além da gestão documental. Por exemplo, a tecnologia Data Warehouse consiste em extrair e consolidar dados de múltiplas fontes em uma base de dados que possa ser consultada de várias maneiras pelos usuários com ferramentas de suporte à decisão. Os metadados são, neste contexto, um instrumento essencial para a gestão do repositório e incluem informações como lista de conteúdo, origem dos dados, transformações (como filtragens ou cálculos efetuados na transferência para a localização atual), versão, modelos de dados etc.

Os metadados podem ser estruturados ou não estruturados. Exemplo de não estruturados: o índice produzido por um sistema de indexação e pesquisa em texto integral. Estruturados são, por exemplo, um sistema de classificação de arquivo ou o dicionário de dados de um SGBD. (METADADOS, 2002)

Metadados podem ser basicamente definidos como “dados que descrevem os dados”, ou seja, são informações úteis para identificar, localizar, compreender e gerenciar os dados. Quando documentamos os metadados e os disponibilizamos, estamos enriquecendo a semântica do dado produzido, agregando seu significado real, e dando suporte à atividade de Administração de Dados executada pelo produtor desse dado. No caso do IBGE, que produz dados, os metadados são fundamentais. O Sistema de Metadados do IBGE visa facilitar o acesso do público em geral às informações produzidas pelo IBGE, descrevendo seu acervo institucional. Através desse sistema é possível verificar características e documentos relacionados aos produtos do Instituto. Navegando pelos metadados, o usuário do sistema pode localizar, interpretar e acessar os dados disponíveis nos sistemas de informação do IBGE. (IBGE, 2018)

Metadados

Fonte: seekeaw rimthong/Shutterstock.

De acordo com Macedo (2011),

a limpeza dos dados é um importante aspecto da criação de um DW eficiente. Devem ser removidos certos aspectos dos dados operacionais que podem atrasar muitas consultas. O estágio de limpeza deve ser o mais dinâmico possível para acomodar todos os tipos de consulta, mesmo aquelas que requerem informações de baixo nível. Os dados devem ser extraídos de fontes de produção em intervalos regulares de tempo e concentrados de maneira centralizada, mas é importante que o processo de limpeza remova duplicações e normatize as diferenças entre os atributos dos dados.

Oliveira e Felipe (2014) afirmam que

somente após o processo de limpeza é que os dados podem ser transferidos para o DW. O DW é tipicamente um grande repositório de dados em um sistema de alta performance, do tipo SMP- Symmetric Multi-Processing ou MPP- Massively Parallel Processing, ou seja, sistemas multiprocessados ou paralelos. Somente um sistema com alto poder de computação pode garantir a eficiência do processo de implantação de um data warehousing, dada a complexidade envolvida no processamento e consultas e dada a grande quantidade de dados que geralmente a organização deseja armazenar.