O documento discute a arquitetura de dados para projetos de Business Intelligence, comparando modelos relacionais e dimensionais. Explica que os dados originais vêm de bancos de dados transacionais relacionais, mas para análise são movidos para um modelo dimensional com fatos e dimensões. Detalha como as dimensões podem ter hierarquias definidas para melhor apoiar consultas e relatórios.

1. PERFIL BUSINESS INTELLIGENCE
marcelokrug@gmail.com SEU PAPER PELA INTERNET Desde Março/2015 – pp15
Quando iniciamos um projeto de Business
Intelligence, uma das etapas presentes acena
para a arquitetura do armazenamento dos
dados. Os dados provenientes dos sistemas
existentes na empresa. Presentes em bases de
dados transacionais. Onde trabalhamos
necessariamente com modelos relacionais.
O BUSINESS INTELLIGENCE E A ARQUITETURA DE DADOS
Transacionais, pois procedimentos são
executados para as operações nos dados. Temos
as transações de inserção, atualização, exclusão
e consulta em registros. Atividades a todo
instante na base de dados. Acessos restritos e
evita-se ao máximo processos em simultâneo
para não haver concorrência. Não podemos
colocar em risco a base de dados operacional da
empresa.
O desenho ao lado (parte de cima), corresponde
ao que é supostamente o desenho da estrutura
de dados relacionais. Onde temos os dados
organizados em tabelas e estas relacionadas.
O que segue, corresponde ao modelo
dimensional e até muitas vezes encontramos
sendo chamado de multidimensional. Onde
após conhecer a estrutura relacional criamos
um modelo em forma de dimensões e fatos.
Que estão em volta de uma tabela
correspondente ao meu fato. Desenhamos
então uma estrutura em que o fato está em
evidência e é rodeado por tabelas que o
caracterizam, cada característica por sua vez na
sua ordem de detalhe. As informações, os
campos, das dimensões são denominados
atributos. E é muito comum haver hierarquias
definidas nas dimensões. Muitas vezes mais de
uma por dimensão. Neste nosso contexto, na
dimensão DIM_COLABORADORES, posso
facilmente criar uma hierarquia como:
- Departamento
- Chefe
- Colaborador
Ou então:
- Chefe
- Departamento
- Função
- Colaborador
Quando estamos lendo as informações a partir de uma ferramenta OLAP. As
hierarquias serão úteis e muitas regras de negócio podem já ser atendidas a
partir deste momento. Desde perfis de de segurança (acesso aos dados) até
cálculos de indicadores conforme vou percorrendo os membros de uma
dimensão.
O DBA, Data base Administrator, precisa ser seu grande amigo. O desenho de
um modelo dimensional foge daquelas belas práticas de ter tabelas para tudo.
Em uma visão muito simples e direta, quanto menos tabelas existirem no
modelo dimensional, melhor. Na base de dados relacional tenho o DBA criando
índices, foreign key, primary key. No modelo dimensional, o máximo que temos
são primary keys e particionamento de objetos (tabelas, índices). O resto fica
com o processamento da database OLAP. Preciso dizer que poucos DBAs
possuem o mesmo conhecimento para a base relacional e a dimensional.
Inicialmente porque são formas diferentes de pensar e depois que quando o
desenvolvedor atinge um certo nível de especialização, precisa saber mais da
arquitetura para tirar mais proveito.
O DBA completo hoje em dia precisa ser dimensional também. Precisa ser BI. É
o dia-a-dia que tráz as mais eficazes especializações.