Hélio Engholm Jr

Especializado em Engenharia de Software

Online Transaction Processing x Business Intelligence

Desde o início, os sistemas de banco de dados relacionais foram usados ​​quase exclusivamente para capturar dados de negócios primários, tais como encomendas e faturas através do processamento baseado em transações. Este foco em dados de negócio tem suas vantagens e as suas desvantagens. Uma vantagem é que o mau desempenho dos sistemas de banco de dados iniciais melhorou drasticamente, por isso hoje muitos sistemas de banco de dados pode executar milhares de transações por segundo (usando hardware apropriado). Por outro lado, o foco no processamento de transações impediu as pessoas no negócio de banco de dados de ver outra aplicação natural dos sistemas de banco de dados: usando-os para filtrar e analisar as informações necessárias de todos os dados existentes em uma empresa ou departamento.

  1. Online Transaction Processing

Desempenho é um dos principais problemas para os sistemas que são baseados em processamento de transações. Estes sistemas são chamados de processamento de sistemas on-line de transação (OLTP). Um exemplo típico de uma operação realizada por um sistema OLTP é retirar dinheiro de uma conta bancária usando uma máquina de caixa. Sistemas OLTP tem algumas propriedades importantes, tais como:

  • Operações curtas com alta taxa de transferência de dados
  • Muitos usuários, possivelmente centenas ou milhares de usuários
  • Operações contínuas de leitura e gravação baseadas em um pequeno número de linhas
  • Dados de tamanho médio que são armazenados em um banco de dados

O desempenho de um sistema de banco de dados vai aumentar se as transações nos programas aplicativos de banco de dados forem curtas. A razão é que as transações usam bloqueios para evitar possíveis efeitos negativos relacionados a concorrência. Se as operações são de longa duração, o número de bloqueios e suas durações aumentam, diminuindo a disponibilidade de dados para outras operações e, assim, seu desempenho.

Grandes sistemas OLTP geralmente têm muitos usuários que utilizam o sistema simultaneamente. Um exemplo típico é um sistema de reservas para uma companhia aérea, que deve processar milhares de pedidos de organização de viagens em um único país, ou em todo o mundo, quase que imediatamente. Neste tipo de sistema, a maioria dos usuários esperam que seus requisitos de tempo de resposta sejam cumpridos pelo sistema e o sistema estará disponível em horário de trabalho (ou 24×7, sete dias por semana).

Os usuários de um sistema OLTP executam suas instruções DML continuamente, isto é, eles usam ambas as operações de leitura e escrita ao mesmo tempo e de forma constante. Como os dados de um sistema OLTP são continuamente modificados, eles são altamente dinâmicos. Todas as operações ou resultados deles em um banco de dados geralmente incluem apenas uma pequena quantidade de dados, embora seja possível que o sistema de banco de dados deva acessar várias linhas a partir de uma ou mais tabelas armazenadas na base de dados. Nos últimos anos, a quantidade de dados armazenados em um banco de dados operacional (ou seja, um banco de dados gerenciado por um sistema OLTP) tem aumentado continuamente. Hoje, há muitos bancos de dados que armazenam vários ou mesmo dezenas de gigabytes de dados. Como você verá, essa quantidade de dados ainda é relativamente pequeno em relação aos armazéns de dados.

Business Intelligence é o processo de integração de dados em toda a empresa em um único repositório de dados a partir do qual os usuários finais podem executar consultas ad hoc e gerar relatórios para analisar os dados existentes. Em outras palavras, o objetivo do BI é manter dados que podem ser acessados ​​por usuários que fazem suas decisões de negócios, com base em análise. Estes sistemas são muitas vezes chamados de sistemas analíticos ou informativos porque, acessando dados, os usuários têm a informação necessária para a tomada das melhores decisões de negócios.

As metas de sistemas de BI são diferentes dos objetivos dos sistemas OLTP. A seguinte consulta é um típico exemplo para um sistema de BI: “Qual é a categoria de produto mais vendido para cada região de vendas no terceiro trimestre do ano de 2005?” Portanto, um sistema de BI tem propriedades muito diferentes dos listados para uma sistema OLTP na seção anterior. As propriedades mais importantes de um sistema de BI são os seguintes:

  • Periódico (carga), com consultas com base em um grande número de linhas
  • Pequeno número de usuários
  • Grande tamanho dos dados armazenados em um banco de dados

Apesar da carga de dados que é executada em intervalos regulares, normalmente diariamente, os sistemas de BI são na maior parte do tempo sistemas ready only. Portanto, a natureza dos dados em um sistema desse tipo é estático. Como será explicado em detalhes mais adiante neste artigo, os dados são coletados de diferentes fontes, limpas tornando-as consistente e carregadas em um banco de dados chamado de data warehouse ou data mart. Os dados limpos geralmente não são modificados, isto é, os usuários consultam dados usando Instruções SELECT para obter as informações necessárias sendo as operações de modificação realizadas muito raramente.

Como os sistemas de BI são usados para obter informação, o número de usuários que utilizam simultaneamente em tal sistema é relativamente pequeno em relação ao número de usuários que utilizam simultaneamente um sistema OLTP. Os usuários de um sistema de BI geralmente geram relatórios que exibem diferentes fatores sobre as finanças de uma empresa ou departamento, ou executar consultas complexas para comparar dados.

Nota: Outra diferença entre OLTP e sistemas de BI que realmente afeta o comportamento do usuário é o schedule- diária ou seja, como esses sistemas são usados ​​durante um dia. Um sistema OLTP pode ser usado sem parar se ele é projetado para tal uso, enquanto um sistema de BI pode ser usado somente assim que os dados é feita consistente e é carregado no banco de dados.

Em contraste com os bancos de dados em sistemas OLTP que armazenam apenas dados atuais, os sistemas de BI também devem acompanhar os dados históricos. Lembre-se que os sistemas de BI fazem comparações entre os dados recolhidos em diferentes períodos de tempo. Por esta razão, a quantidade de dados armazenados em um data warehouse é muito grande.

2 – Armazéns de Dados e Data Marts

Um armazém de dados pode ser definido como um banco de dados que inclui todos os dados da empresa e que podem ser uniformemente acessados ​​pelos usuários. Uma empresa geralmente tem uma grande quantidade de dados armazenados em diferentes épocas e em diferentes bancos de dados (ou arquivos de dados) que são gerenciados por SGBDs distintos. Estes SGBDs não precisam ser relacionais, algumas empresas ainda têm bancos de dados gerenciados por sistemas de banco de dados hierárquicos ou de rede. Uma equipe especial de especialistas em software analisa os bancos de dados de origem (dados e arquivos) e os converte em um arquivo de destino, o data warehouse. Além disso, os dados convertidos em um data warehouse devem ser consolidados, porque mantém a informação que é a chave para os processos operacionais da corporação.

Consolidação dos dados significa que todas as consultas equivalentes executados em cima de um armazém de dados em diferentes momentos fornecem o mesmo resultado.

A consolidação de dados em um data warehouse é fornecida em várias etapas:

  • Montagem de dados a partir de diferentes fontes (também chamado de extração)
  • Limpeza de dados (em outras palavras, o processo de transformação)
  • Garantia da qualidade de dados

Os dados devem ser cuidadosamente montados a partir de diferentes fontes. Neste processo, os dados são extraídos a partir de fontes diferentes, convertidos para um esquema intermediário e transferido para uma área de trabalho temporária. Para a extração de dados, você precisa de ferramentas que extraem exatamente os dados que devem ser armazenados no data warehouse.

A limpeza de dados garante a integridade dos dados que tem de ser armazenada na base de dados destino. Por exemplo, a limpeza de dados deve ser feita em entradas incorretas em campos de dados, como endereços, ou tipos de dados incompatíveis utilizados para definir os mesmos campos de data em diferentes fontes. Para este processo, a equipe de limpeza de dados precisa de um software especial. Um exemplo ajudará a explicar o processo de limpeza de dados de forma mais clara. Suponha que há duas fontes de dados que armazenam dados pessoais sobre os funcionários e que ambos os bancos de dados têm o atributo de Gênero. No primeiro banco de dados, este atributo é definido como CHAR (6) e os valores de dados são “feminino” e “masculino”. O mesmo atributo no segundo banco de dados é declarado como CHAR (1), com os valores de “F” e “m.” os valores de ambas as fontes de dados estão corretos, mas para a fonte de dados de destino, você deve limpar os dados, isto é, representam os valores do atributo de uma forma uniforme.

A última parte da garantia de consolidação de dados de qualidade de dados, envolve um processo de validação de dados que especifica os dados que o usuário final deve ver e acessá-lo. Devido a isso, os usuários finais devem participar ativamente deste processo. Quando o processo de consolidação de dados for concluído, os dados serão carregados no data warehouse.

Nota: Todo o processo de consolidação de dados é chamado de ETL (extração, transformação, carregamento). A Microsoft fornece um componente chamado SQL Server Integration Services (SSIS) para apoiar os usuários durante o processo de ETL.

Por sua natureza (como uma loja para os dados globais de uma empresa), data warehouses contêm grandes quantidades de dados. Alguns armazéns de dados contêm dezenas de terabytes ou mesmo petabytes de dados. Além disso, uma vez que devem abranger a empresa, a implementação geralmente leva muito tempo, que depende do tamanho da empresa. Devido a estas desvantagens, muitas empresas começam com uma solução de menor chamado de Data Mart. Data marts são repositórios de dados que incluem todos os dados no nível do departamento e, portanto, permitem que os usuários acessem os dados relativos apenas uma única parte de sua organização. Por exemplo, o departamento de marketing armazena todos os dados relevantes para o marketing em seu próprio data mart, o departamento de pesquisa coloca os dados experimentais na data mart pesquisa, e assim por diante. Devido a isso, um data mart tem várias vantagens sobre um data warehouse:

  • Área de aplicação mais estreita
  • Tempo de desenvolvimento menor e menor custo de manutenção de dados
  • Manutenção de dados mais fácil
  • Desenvolvimento Bottom-up

Como já foi dito, um data mart inclui apenas as informações necessárias para uma parte de uma organização, geralmente um departamento. Portanto, os dados que se destina a ser utilizado por uma pequena unidade de tal organização pode ser mais facilmente preparado para as necessidades do usuário final.

O tempo de desenvolvimento de um data warehouse leva em média dois anos e custa US $ 5 milhões. Por outro lado, os custos de um data mart tem valor médio de US $ 200.000, e um projeto como este leva cerca de três a cinco meses. Por estas razões, o desenvolvimento de um data mart é preferível, especialmente se ele é o primeiro projeto de BI em sua organização.

O fato de que um Data Mart contém quantidades significativamente menores de dados do que um armazém de dados ajuda você a reduzir e simplificar todas as tarefas, tais como a extração de dados, limpeza de dados e garantia de qualidade dos dados. É também mais fácil de projetar uma solução para um departamento do que para toda a organização. (Para mais informações sobre projeto de BI e um modelo dimensional, consulte a seção deste artigo.) Se você projetar e desenvolver vários Data Marts em sua organização, é possível unir todos eles em um grande armazém de dados. Este processo de baixo para cima tem várias vantagens sobre a concepção de um armazém de dados de uma só vez: primeiro, cada Data Mart pode conter tabelas de destino idênticas que podem ser unificadas em um armazém de dados correspondente. Em segundo lugar, algumas tarefas são logicamente toda a empresa, tais como a recolha de informação financeira pelo departamento de contabilidade.

Se os mercados de dados existentes serão ligados em conjunto para construir um Data Warehouse para uma empresa, um repositório global (isto é, o catálogo de dados que contém informações sobre todos os dados armazenados em fontes bem como no banco de dados de destino) é necessária.

Nota: Lembre-se que a construção de um armazém de dados, ligando data marts pode ser muito problemática por causa de possíveis diferenças significativas na estrutura e projeto de data marts existentes. Diferentes partes de uma empresa podem usar diferentes modelos de dados e têm instruções diferentes para representação de dados. Por esta razão, no início deste processo de baixo para cima, é altamente recomendável que você faça uma visão única de todos os dados que serão válidas a nível empresarial; não permitem que os departamentos de projetar dados separadamente.

3 – Data Warhouse Design Usando Modelo Dimensional

Apenas um banco de dados bem planejado e projetado irá permitir-lhe atingir um bom desempenho. Bancos de dados relacionais e data warehouses possuem uma série de diferenças que requerem diferentes métodos de projeto.

Bancos de dados relacionais são projetados usando o modelo entidade x relacionamento (ER) enquanto o modelo dimensional é usada para o projeto de data warehouses e data marts. Utilizando bancos de dados relacionais, a redundância de dados é removida através de formas normais. O processo de normalização divide cada tabela de um banco de dados que inclui dados redundantes em duas tabelas separadas. O processo de normalização deve ser concluído quando todas as tabelas de um banco de dados contêm apenas dados não redundantes.

As tabelas normalizadas são altamente vantajosas para OLTP porque, neste caso, todas as operações podem ser feitas o mais simples e da maneira mais curta possível. Por outro lado, os processos de BI são baseados em consultas que operam em uma grande quantidade de dados e não são nem simples nem curtas. Deste modo, as tabelas altamente normalizadas não atendem o projetos de data warehouses, porque o objetivo de sistemas de BI é significativamente diferente. Existem poucas transações simultâneas e cada transação acessa um número muito grande de registros. Imagine a enorme quantidade de dados que pertencem a um armazém de dados que são armazenados em centenas de tabelas. Maioria das consultas irá juntar-se dezenas de grandes tabelas para recuperar dados. Tais consultas não pode ter um bom desempenho, mesmo se você usar hardware com processadores paralelos e um banco de dados sistema com o melhor otimizador de consulta.

Os armazéns de dados não podem usar o modelo ER, porque este modelo é adequado para projetar bancos de dados com dados não redundantes. O modelo lógico usado para projetar armazéns de dados é chamado de um Modelo Dimensional.

Nota: Existe outra razão importante pela qual o modelo ER não é adequado para o projeto de data warehouses, o uso de dados em um data warehouse é desestruturado. Isso significa que as consultas são parcialmente executadas ad hoc, permitindo que usuários analisem os dados de formas totalmente diferentes. Por outro lado, os sistemas OLTP geralmente têm aplicações de banco de dados, que são codificados e, portanto, contêm consultas que não são modificados com frequência.

Na modelagem dimensional, cada modelo é composto por uma tabela que armazena as medidas e várias outras tabelas que descrevem dimensões. O primeiro é chamado de tabela de fatos e os últimos são chamados de tabelas de dimensão. Exemplos de dados armazenados em uma tabela de fatos incluem as vendas e despesas do inventário. As tabelas de dimensão geralmente incluem tempo, conta, produto e dados de funcionários. A Figura 1 mostra um exemplo de um modelo tridimensional.

Cada tabela de dimensão normalmente possui uma chave primária de parte única e vários outros atributos que descrevem de perto esta dimensão. Por outro lado, a chave principal da tabela de fato, é a combinação das chaves primárias de todos os quadros de dimensões (ver Figura 1). Por esta razão, a chave principal da tabela de verdade é composta de várias chaves estrangeiras. O número de dimensões também especifica o número de chaves estrangeiras na tabela de fatos. Como você pode ver na Figura 1, as tabelas em um modelo dimensional constroem uma estrutura na forma de uma estrela. Portanto, este modelo é muitas vezes chamado de um esquema em estrela.

Outra diferença na natureza dos dados em uma tabela de fatos e as tabelas de dimensão correspondente é que a maioria das colunas não-chave em uma tabela de fatos são numéricos e aditivo, porque esses dados podem ser usados ​​para executar cálculos necessários. Lembre-se que uma consulta típica em um armazém de dados obtém milhares ou mesmo milhões de linhas de cada vez, e a única operação útil sobre uma quantidade tão grande de linhas é a aplicação de uma função de agregação [soma, máxima ou média].

Fig 1 Art I

Figura 1 – Exemplo estrela de Modelo Dimensional.

 

Por exemplo, colunas como Units_of_product_sold, Total_sales, Profit, ou Dollars_cost são colunas típicas na tabela de fatos. Já as colunas numéricas de tabela de fatos que não construir a chave primária da tabela são chamadas de medidas.

Por outro lado, as colunas de tabelas de dimensões são sequências que contêm descrições textuais da dimensão. Por exemplo, colunas, tais como endereço, localização e nome aparecem frequentemente em tabelas de dimensão. Estas colunas são geralmente utilizadas como cabeçalhos de relatórios. Outra consequência da natureza textual de colunas de tabelas de dimensão e seu uso em consultas é que cada tabela de dimensão contém muito mais do que os índices da tabela de fatos correspondente.

A tabela de fatos geralmente tem apenas um único índice composto de todas as colunas que pertencem à chave primária da tabela. Tabela 1 resume as diferenças entre tabelas de fatos e de dimensão.

Tabela 1 Art I

Tabela 1 – Diferenças entre tabelas de Fato e de Dimesão.

Colunas de tabelas de dimensões são normalmente altamente desordenadas, o que significa que uma grande quantidade de colunas dependem umas das outras. A estrutura desnormalizada de tabelas de dimensões tem um propósito importante: todas as colunas de uma tabela desse tipo são usadas ​​como cabeçalhos de colunas em relatórios. Se a desnormalização de dados em uma tabela de dimensão não é desejável, uma tabela de dimensão pode ser decomposta em vários sub-tabelas. Isso geralmente é necessário quando as colunas de uma tabela de dimensão construir hierarquias. Por exemplo, a dimensão do produto poderia ter colunas, como Product_id, category_id e Subcategory_id que construi-se três hierarquias, com a chave primária, Product_id, como a raiz. Esta estrutura, em que cada nível de uma entidade de base é representada pelo sua própria tabela, é chamado um esquema floco de neve.  A Figura 2 mostra o esquema floco de neve da dimensão do produto.

A extensão de um esquema em estrela em um esquema floco de neve correspondente tem alguns benefícios (redução de espaço em disco utilizado, por exemplo) e uma das principais desvantagens: o esquema floco de neve requer mais operações de junção para obter informações de tabelas de pesquisa, o que afeta negativamente desempenho. Por esta razão, o desempenho das consultas com base no esquema de floco é geralmente lento. Portanto, o projeto usando o esquema floco de neve só é recomendada em alguns casos muito especializados.

Fig 2 Art I

Figura 2 – Esquema Floco de Neve.

Cubos e seus sistemas de arquiteturas de BI suportam diferentes tipos de armazenamento de dados. Alguns destes tipos de armazenamento de dados baseiam-se em uma base de dados multidimensional que é também chamado um cubo. Um cubo é um subconjunto de dados do armazém de dados que pode ser organizado em estruturas multidimensionais. Para definir um cubo, você seleciona uma tabela de fatos do esquema dimensional e identificar colunas numéricas (medidas) de interesse dentro dele. Em seguida, selecione as tabelas de dimensão que fornecem descrições para o conjunto de dados a serem analisados​​. Para demonstrar isso, considere como o cubo para análise as vendas de automóveis. Por exemplo, a tabela de fatos pode incluir as medidas Cars_sold, Total_sales e custos, enquanto os modelos de tabelas, alojamentos e Região especificar as tabelas de dimensão. O cubo na Figura 3 mostra todas as três dimensões: Modelos, regiões e Quarters.

Em cada dimensão existem valores discretos chamados membros. Por exemplo, a dimensão Regiões pode conter os seguintes membros: ALL, América do Norte, América do Sul e Europa. (O membro ALL especifica o total de todos os membros de uma dimensão.)

Adicionalmente, cada dimensão do cubo pode ter uma hierarquia de níveis que permite aos usuários fazer perguntas em um nível mais detalhado. Por exemplo, a dimensão regiões podem incluir os seguintes hierarquias de nível: País, Província, e Cidade. Da mesma forma, a dimensão Quarters pode incluir Mês, Semana e Dia como níveis de hierarquias.

Fig 3 Art I

Figura 3 – Cubo com dimensões Models, Quartes e Regions.

Nota: Cubos e bancos de dados multidimensionais são gerenciados por sistemas especiais chamados de sistemas de bancos de dados multidimensionais (MDBMS). MDBMS do SQL Server é chamado Analysis Services.

4 – Agregações

Dados são armazenadas na tabela de fatos em sua forma mais detalhada, de modo que os relatórios correspondentes podem fazer uso dele. Por outro lado, como dito anteriormente, uma consulta típica em uma tabela de fatos obtém milhares ou mesmo milhões de linhas de cada vez fazendo com que a  única operação útil sobre uma enorme quantidade de linhas como é aplicar uma função agregada (soma, máximo ou média). Este uso diferente de dados pode reduzir o desempenho de consultas ad hoc, se elas forem executadas no baixo nível de dados (atômica), porque tempo e uso intensivo de recursos cálculos serão necessários para executar cada função agregada.

Por esta razão, os dados de nível baixo da tabela de fato deverão ser sintetizados antecipadamente e armazenados em tabelas intermediárias. Por causa de suas informações “agregadas”, tais tabelas são chamadas de tabelas agregadas, e todo o processo é chamado de agregação.

Nota: Uma linha agregada da tabela de fatos está sempre associada a uma ou mais linhas da tabela de dimensão global. Por exemplo, o modelo dimensional na Figura 1 poderia conter as seguintes linhas: agregados mensais de vendas por vendedores por região e em nível de região agregados por vendedores por dia.

Um exemplo vai mostrar por que os dados de baixo nível devem ser agregados. Um usuário final pode querer começar uma consulta ad hoc que exibe as vendas totais da organização no último mês. Isso faria com que o Servidor para somar todas as vendas para cada dia no último mês. Se há uma média de 500 operações de vendas por dia em cada uma das 500 lojas da organização, e os dados são armazenados no nível da transação, esta consulta teria que ler 7,5 milhões (500 × 500 × 30 dias) linhas e construir a soma para retornar o resultado. Agora, considere o que acontece se os dados forem agregados em uma tabela que é criada usando as vendas mensais por loja. Neste caso, a tabela terá apenas 500 linhas (o total mensal para cada um dos 500 lojas) e o ganho de desempenho será dramático.

5 – Quanto Agregar?

Existem duas soluções extremas: nenhuma agregação e agregação exaustiva para cada combinação possível de consultas que os usuários precisem.

A partir da discussão anterior, deve ficar claro que a não utilização de agregação está fora de questão por causa de problemas de desempenho. O armazém de dados, sem qualquer tabela agregação, provavelmente não pode ser usada por todos como um armazenamento de dados de produção. A solução oposta também não é aceitável, por vários motivos:

  • Enorme quantidade de espaço em disco necessário para armazenar dados adicionais
  • Manutenção esmagadora de tabelas agregadas
  • Carga de dados inicial muito longa

Armazenar dados adicionais que são agregados em todos os níveis possíveis consome uma quantidade adicional de espaço em disco que aumenta o espaço em disco inicial por um fator de seis ou mais, dependendo da quantidade de espaço em disco inicial e o número de consultas que os usuários será necessário. A criação de tabelas para armazenar as agregações para todas as combinações existentes é uma tarefa árdua para o administrador do sistema. Por fim, a construção de agregação na carga inicial de dados pode ter resultados devastadores se essa carga está estimada para durar muito tempo e  não existe tempo adicional disponível.

A partir desta discussão, você pode ver que as tabelas de agregados devem ser cuidadosamente planejadas e criadas. Durante a fase de planejamento, manter essas duas considerações principais em mente ao determinar o que agrega para criar:

  • Onde os dados estão concentrados?
  • Quais  agregados melhorariam mais o desempenho?

O planejamento e criação de tabelas de agregados é dependente da concentração de dados nas colunas de tabela base. Em um armazém de dados, onde não há nenhuma atividade em um determinado dia, a linha correspondente não é armazenada em tudo. Portanto, se o sistema carrega um grande número de linhas, em comparação com o número de todas as linhas que podem ser carregados, por esta agregação coluna de tabela base melhora em muito o desempenho. Em contraste, se o sistema carrega algumas linhas, em comparação com o número total de linhas que podem ser carregadas, a agregação por esta  coluna que não é eficiente.

Aqui está outro exemplo para demonstrar a discussão anterior. Para os produtos no supermercado, apenas alguns deles (por exemplo, 15 por cento) são efetivamente vendidas em um determinado dia. Se temos um modelo tridimensional com três dimensões, produtos, armazenar e Tempo, apenas 15 por cento da combinação dos três correspondentes chaves primárias para o dia em particular e para a loja específica será ocupada. Os dados de vendas de produtos por dia, assim, ser escassa. Em contrapartida, se todos ou muitos produtos no supermercado são vendidos em um determinado dia (por causa de uma promoção especial, por exemplo), os dados de vendas de produtos diários será denso.

Para descobrir quais dimensões são escassas e quais são densas, você tem que construir linhas de todas as combinações possíveis de tabelas e avaliá-los. Normalmente, a dimensão de tempo é densa, porque há sempre entradas para cada dia. Dadas as dimensões Produto, da loja, e tempo, a combinação da loja e Tempo dimensões é densa, pois para cada dia certamente haverá dados relativos venda em cada loja. Por outro lado, a combinação da loja e do produto dimensões é escassa (pelos motivos discutidos anteriormente). Neste caso, a dimensão do produto é geralmente dispersa, porque a sua aparência em combinação com outras dimensões é escasso.

A escolha dos agregados que mais melhoram o desempenho depende dos usuários finais. Portanto, no início de um projeto de BI, você deve entrevistar os usuários finais para coletar informações sobre como os dados serão consultados, quantas linhas serão recuperadas por essas consultas e outros critérios.

6 – Armazenamento físico de um Cubo

Um sistema de processamento analítico online do tipo Cube (OLAP) geralmente utilizassem um dos seguintes três arquiteturas diferentes para armazenar dados multidimensional:

  • Relational OLAP (ROLAP)
  • Multidimensional OLAP (MOLAP)
  • Híbrido OLAP (HOLAP)

Geralmente, estes três tipos arquiteturas diferem na maneira em que eles armazenam dados em nível de folha e agregados pré-computados. (Dados de nível Folha é o melhor grão de dados que está definido no grupo de medidas do cubo. Portanto, os dados de nível de folha corresponde aos dados da tabela de fatos do cubo.)

No ROLAP, os dados pré-computados não é armazenada. Em vez disso, as consultas de acessar dados do banco de dados relacional e suas tabelas, a fim de trazer de volta os dados necessários para responder à pergunta. MOLAP é um tipo de armazenamento em que os dados de nível de folha e suas agregações são armazenados usando um cubo multidimensional.

Embora o conteúdo lógico destes dois tipos de armazenamento são idênticos para o mesmo depósito de dados e de ambas as ferramentas analíticas MOLAP ROLAP e destinam-se a permitir a análise de dados, através da utilização de dados através da utilização de um modelo de dados dimensionais, há algumas diferenças significativas entre los. As vantagens do tipo de armazenamento ROLAP são como se segue:

  • Dados não devem ser duplicada
  • Indexados (Materializados): Vistas pode ser usadas para resumos

Se os dados devem também ser armazenados numa base de dados multidimensional, uma certa quantidade de dados deve ser duplicado. Portanto, o tipo de armazenamento ROLAP não precisa de armazenamento adicional para copiar os dados de nível de folha. Além disso, o cálculo de resumos (veja a próxima seção) pode ser executado muito rapidamente com ROLAP se as tabelas de resumo correspondentes são gerados usando as visualizações materializadas.

Por outro lado, MOLAP também tem várias vantagens sobre ROLAP:

  • Aggregates são armazenados na forma de uma resposta
  • Query multidimensional é geralmente mais rápida

Usando MOLAP, muitos agregados são precomputed e armazenada em um cubo multidimensional. Dessa forma, o sistema não tem que calcular o resultado de um tal agregado cada vez que for necessário. No caso de MOLAP, o motor de banco de dados e do próprio banco de dados são geralmente otimizados para trabalhar em conjunto, de modo que a resposta da consulta pode ser mais rápido do que em ROLAP.

Armazenamento HOLAP é uma combinação de tipos de armazenamento e MOLAP ROLAP. Precomputed dados é armazenado como no caso do armazenamento MOLAP, enquanto que os dados de nível de folha é deixada na base de dados relacional. (Por conseguinte, para consultas usando sínteses, HOLAP é idêntico ao MOLAP.) A vantagem do armazenamento HOLAP é que os dados de nível em folha que não é duplicado.

7 – Dados de acesso

Dados em um data warehouse podem ser acessados por meio de três técnicas gerais:

  • Mineração de dados para gerar reports
  • OLAP
  • Data mining

Reportar é a forma mais simples de acesso a dados. Um relatório é apenas uma apresentação do resultado de uma consulta em um formato tabular. (Reportagem é discutido em detalhes no Artigo 25) Com OLAP, a analisar os dados de forma interativa; ou seja, ele permite que você para realizar comparações e cálculos ao longo de qualquer dimensão em um data warehouse.

Nota: O Transact-SQL oferece suporte a todas as funções padronizadas e construções em relação ao SQL / OLAP.

A mineração de dados é usada para explorar e analisar grandes quantidades de dados para descobrir padrões significativos. Esta descoberta não é a única tarefa de mineração de dados: usando esta técnica, você deve ser capaz de transformar os dados existentes em informação e transformá as informações em ação. Em outras palavras, não é suficiente para analisar os dados; você tem que aplicar os resultados da mineração de dados significativa e agir sobre os resultados obtidos. (. Mineração de dados, como a mais complexa das três técnicas, não serão abordados neste livro introdutório)

Conclusão

No início de um projeto de BI, a questão principal é o que construir: um armazém de dados ou um data mart. Provavelmente, a melhor resposta é começar com um ou mais data marts, que podem posteriormente ser unidas em um data warehouse. A maioria das ferramentas existentes no apoio ao mercado de BI esta alternativa.

Em contraste com os bancos de dados operacionais que usam modelos ER para o seu design, o projeto de data warehouses é melhor realizado utilizando um modelo dimensional. Estes dois modelos apresentam diferenças significativas. Se você já está familiarizado com o modelo ER, a melhor maneira de aprender e usar o modelo dimensional é esquecer tudo sobre o modelo ER e começar a modelar a partir do zero.

Após esta discussão introdutória de considerações gerais sobre o processo de BI, o próximo artigo 31 aborda a parte do servidor do Microsoft Analysis Services.




+ Artigos