Dw e olap no que tange ao BD

Ezaul

Vamos primeiro falar de conceitos:

• Data Warehouse -> Seria o grande repositório de dados com as informações gerenciais da empresa. Nele não nos preocupamos em performance em sim em armazenagem. Devemos garantir que nele todos os indicadores estejam salvos usando as regras de negócio da empresa, que os conceitos estejam unificados e onde todos os indicadores gerenciais estejam lá, prontos para serem consultados. - -

• ETL: É o processo de carga do Data Warehouse. O ETL se conectará nas diversas fontes de dados origem, sejam bancos de dados operacionais, sejam planilhas, arquivos textos,d ados da web, etc etc etc. Ele vai normalizar e guardar no Data Warehouse as informações já limpas, ajustadas a regras de negócio e integras.

• OLAP: Banco de consulta. Nele teremos como única fonte uma parte do Data Warehouse, pegando indicadores somente dos departamentos. O OLAP deve privilegiar performance.

Vamos a arquitetura. Vou tirar fora o ETL pois ele é processo. Podemos usar ferramentas de ETL no mercado (ex: Integration Services da Microsoft, Informatica, Powercenter da IBM, Data Services da SAP) ou fazer nossos próprios programas, em C, Java, .NET, Python, para extrair dados e guardar no Data Warehouse

Data Warehouse. Normalmente falamos em armazena-los nos bancos de dados relacionais. Porque suportam grandes volumes, seu conhecimento é disseminado, tem um custo baixo, normalmente a empresa já usa ele para outros sistemas.

O OLAP posso te-lo em qualquer lugar. Num banco relacional ? Porque não? Mas vamos muda o nome do OLAP. Vamos chama-lo de "Data Mart". O Data Mart é um pedaço do Data Warehouse preparado para consulta.

Se o nosso Data Mart estiver guardado também no banco relacional, sem problemas (No mesmo SGBD ou em outro). Mas cuidado com a performance. As operações de pivot tão necessárias na ferramentas de BI, podem ser providenciadas pela ferramenta de visualização conectada diretamente ao Data Mart. Um exemplo muito conhecido são as tabelas dinâmicas do Excel (Pivot table).

Chamamos nossos Data Marts de OLAP quando a estrutura multimensional não está na ferramenta de visualização e sim no banco de dados. Nativamente bancos de dados relacionais não possuem estrutura matricial para fazer os pivots. Mas existem outros bancos, que não são SGBDs, que possuem uma forma diferente de armazenagem dos dados priorizando o Pivot e performance. Estes são bancos OLAPs.

O Oracle SGBD não é um OLAP. O SQL Server não é um OLAP. O DB2 não é um OLAP. Mas podem ser Data Marts. Se usa-los transfira a necessidade de Pivotear o dado para a ferramenta de consulta.

O Analysis Services é um OLAP. O Oracle Hyperion é um OLAP. O Cognus IBM é um OLAP. O Microstrategy é um OLAP. O SAP BW é um OLAP. O SAP HANNA é um OLAP. A estrutura interna destes bancos são preparadas para o BI. O Pivot dos dados são nativos. A performance é muito, mas muito mais rápida que os SGBDs.

Concluindo. Conceitualmente você pode ter o seu Data Mart no SGBD, sendo ele o mesmo ou um banco relacional diferente do DW. Mas você terá que transferir o trabalho de exploração de dados para a ferramenta de análise (Ex: Power BI da Microsoft, Tableau,, QLIK, Business Object da SAP, Cognus Dashboard da IBM). Se o Data Mart estiver em um banco OLAP não se preocupe pois o dado já estará sendo exibido com as funcionalidades de pivot. Na maioria destes bancos OLAP a linguagem de query não é o SQL (SELECT FROM TABELA) e sim o MDX (SELECT ON ROW, * ON COLUMN FROM BASE).

Att

Victorino Vila

Certo. Entendi os conceitos.

Entretanto, ainda no que concerne às arquitetura...em um cenário próximo do ideal, eu teria:

1- meu banco relacional OLTP. 2- em outra VM, meu DW. 3- nesta mesma VM do meu DW, meu banco OLAP ou meus data marts para a consulta. Neste caso, se eu tiver apenas os data marts, eles fariam o papel dos "cubos" para consulta.

Este arranjo estaria de acordo?

Se você tiver uma estrutura é legal OLTP emuma VM, DW na segunda e OLAP em uma terceira.

Se seu "Data Mart" for em banco de dados relacional ele poderia ser um "Cubo". Mas não o chamaria assim pois ele estaria em um banco relacional e este tipo de banco não teria a funcionalidade de um OLAP. Você teria que depender da ferramenta de análise para fazer a multimensionalidade.

Victorino.

Sua última mensagem suscitou mais duas dúvidas:

1- quanto à ferramenta.... Vejo ferramentas hoje como o QlikView, que nos dispensa, de termos um DW, ETL e até um cubo OLAP. Simplesmente entregamos um view de banco de dados com todas as colunas a serem cruzadas e ele faz todo esse trabalho.

Neste contexto e, desde já sei que o objetivo do curso é apresentar todos os conceitos e de forma didática, entretanto na prática se monta toda esta estrutura para BI ou estas ferramentas já estão encurtando o caminho mesmo?

2- Outra questão é referente ao DataMart... Se eu o tiver, ele faz às vezes do cubo OLAP? Ou seja, não preciso deste último? Mas pelo que noto que descreve, o OLAP seria uma estrutura muito mais robusta e adequada no tocante às consultas que se farão. Confere?

Vamos lá.

1) A resposta é sim. Algumas destas ferramentas encurtam a fase de desenvolvimento dispensando um DW. Mas isso é o que elas defendem. Na minha opinião isso é ruim. E vou explicar porque.

O objetivo deles é vender software e manter o cliente dependente de suas soluções. Logo, se você transferir para a camada de apresentação a criação das regras de negócio você dependerá deles para o resto da vida.

Por outro lado se você construir o seu DW em SGBD, normalmente, a construção do OLAP é fácil e independente se você mudar amanhã de banco OLAP o DW é mandatório. Ter o DW em um banco relacional permite facilmente troca-lo de Oracle para SQL server, para DB2 e assim por diante pois todos são padrão SQL. Use o QLIK, o Tableau e outros apenas para o propósito deles que é o de construir o Dashboard.

Se você fez o curso de Power BI da Alura verá que, ao conectar a ferramenta OLAP a aplicação toda a sua estrutura de dimensão, hierarquia, etc foi herdada. Mas, depois, tente conectar o DW em SQL Server direto a um SGBD? Verá que todo o conceito de dimensão, hierarquia, etc terá que ser parametrizada dentro da ferramenta. Você terá que dizer que PAIS - CIDADE - ESTADO é uma hierarquia, por exemplo. Agora, depois disto, imagina se você vai construir um segundo relatório. Terá que, de novo, programar estas regras.

2) OLAP é uma estrutura muito mais robusta associada a BI, a análise e a performance. E ele possui estruturas internas que o SGBD não tem. Faça o curso de MDX e você entenderá como faço queries em bancos OLAP e veja como os resultados são entregues.

Victorino.

O OLAP é algo concreto?...como um banco relacional, onde instala o software do SGBD?

Ou ele é apenas uma abstração, um conceito, uma filosofia? Como por exemplo a arquitetura ISO - que não existe de fato dentro, por exemplo, das placas de rede e roteadores.

Se não for apenas um conceito. Qual base OLAP Free open source você recomenda?

Ezaul

Todas as ferramentas OLAP são concretas. Mas temos as que realmente armazenam dados no disco e outras que são lógicas.

MOLAPS - Guardam todas as informações em disco. ROLAPS - Somente lógicas. O dado fica no tradicional RGBD mas as consultas multidimensionais são feitas em memória. HOLAP - Híbridas. Parte do dados está salvo parte lógico.

No treinamento OLAP da Alura eu sugiro baixar e instalar o Microsoft Analysis Services que vem dentro do SQL Server 2017 Developer Edition. É gratuito. O software da microsoft pode ser MOLAP, ROLAP ou HOLAP.

Numa outra linha temos o Mondriam, da Pentaho. É livre. Este é somente ROLAP.

Att

Victorino.