Vamos conversar um pouco sobre escopo e granularidade dentro do contexto da modelagem multidimensional.
ESCOPO
A experiência e o conhecimento do analista de SAD sobre o negócio é fundamental para a correta definição do escopo de um projeto de DW.
É imprescindível ter uma visão do que é importante para o negócio, ou melhor, saber que informação será necessária extrair dos dados armazenados no DW para que a organização obtenha algum conhecimento novo e a partir deste ponto os gestores possam tomar as decisões mais acertadas.
Vale lembrar que cada projeto é único e portanto deve ser analisado individualmente e que muitas variáveis influenciam as decisões, por exemplo: tempo para implantação, custo, capital humano e recursos tecnológicos disponíveis, etc. Estes dentre outros fatores influenciarão na escolha de um dos dois paradigmas que envolvem os projetos de DW que são as propostas de Inmon e Kimball.
Inmon propõe que o projeto do DW deve partir do DW corporativo para depois desmembrar nos DM departamentais com isto ganha-se na consistência dos dados armazenados mas o tempo para a obtenção de resultados práticos aumenta, em contrapartida Kimball propõe o caminho inverso, partir de DM departamentais para o DW corporativo buscando observar à consistência das informações, neste processo os resultados aparecem mais rapidamente porém o risco de inconsistência aumenta.
O bom senso entre as pessoas envolvidas sempre deve ser levado em conta no momento da decisão do projeto, para se buscar um equilibrio entre o melhor dos dois mundos.
GRANULARIDADE
Durante o desenho da solução o analista de SAD define quais métricas serão armazenadas nas tabelas fatos e quais parametros serão armazenados nas tabelas dimensões, observe a figura abaixo.
A definição correta da granularidade de uma tabela fato implica no desempenho das consultas OLAP, tomando como base o modelo proposto imagine os seguintes cenários:
É de se concordar que o volume de dados armazenados na tabela fato na última situação poderá chegar a bilhões de registros, podendo impactar no desempenho das consultas que não necessitem de um detalhamento maior.
Nestes casos uma alternativa é quebrar a tabela fato em domínios menores, onde além de uma tabela com o nível máximo de detalhes existiriam outras tabelas sumarizadas por cidade ou estado por exemplo.
No geral para granularidades distintas teremos tabelas fatos distintas.
Participe! Registre seu comentário abaixo e vamos construir o conhecimento juntos.
ESCOPO
A experiência e o conhecimento do analista de SAD sobre o negócio é fundamental para a correta definição do escopo de um projeto de DW.
É imprescindível ter uma visão do que é importante para o negócio, ou melhor, saber que informação será necessária extrair dos dados armazenados no DW para que a organização obtenha algum conhecimento novo e a partir deste ponto os gestores possam tomar as decisões mais acertadas.
Vale lembrar que cada projeto é único e portanto deve ser analisado individualmente e que muitas variáveis influenciam as decisões, por exemplo: tempo para implantação, custo, capital humano e recursos tecnológicos disponíveis, etc. Estes dentre outros fatores influenciarão na escolha de um dos dois paradigmas que envolvem os projetos de DW que são as propostas de Inmon e Kimball.
Inmon propõe que o projeto do DW deve partir do DW corporativo para depois desmembrar nos DM departamentais com isto ganha-se na consistência dos dados armazenados mas o tempo para a obtenção de resultados práticos aumenta, em contrapartida Kimball propõe o caminho inverso, partir de DM departamentais para o DW corporativo buscando observar à consistência das informações, neste processo os resultados aparecem mais rapidamente porém o risco de inconsistência aumenta.
O bom senso entre as pessoas envolvidas sempre deve ser levado em conta no momento da decisão do projeto, para se buscar um equilibrio entre o melhor dos dois mundos.
GRANULARIDADE
Durante o desenho da solução o analista de SAD define quais métricas serão armazenadas nas tabelas fatos e quais parametros serão armazenados nas tabelas dimensões, observe a figura abaixo.
 |
| Fonte: http://hub05.neogrid.com.br/Docs/help/pt_BR/release_notes.htm |
A definição correta da granularidade de uma tabela fato implica no desempenho das consultas OLAP, tomando como base o modelo proposto imagine os seguintes cenários:
- Poucas lojas e pouca abrangência (poucos CEP´s);
- Muitas lojas e pouca abrangência (poucos CEP´s);
- Poucas lojas e abrangência nacional;
- Muitas lojas e abrangência nacional;
É de se concordar que o volume de dados armazenados na tabela fato na última situação poderá chegar a bilhões de registros, podendo impactar no desempenho das consultas que não necessitem de um detalhamento maior.
Nestes casos uma alternativa é quebrar a tabela fato em domínios menores, onde além de uma tabela com o nível máximo de detalhes existiriam outras tabelas sumarizadas por cidade ou estado por exemplo.
No geral para granularidades distintas teremos tabelas fatos distintas.
Participe! Registre seu comentário abaixo e vamos construir o conhecimento juntos.
ótimo! Gostei Muito
ResponderExcluir