O que não se deve fazer no desenvolvimento de um DW

O que não se deve fazer no desenvolvimento de um DW
Em seguida listam-se algumas das coisas que não se deve fazer no desenvolvimento de um DW. Os elementos não estão ordenados e a importância de cada um deles depende do projecto em causa.

1. Evitar a excessiva focalização na tecnologia em si mesma. O único aspecto que interessa é os requisitos dos processos de negócio e os objectivos das organizações;
2. Desenvolver o DW sem ter o apoio de elementos de alto nível da administração da organização, pois devido à sua natureza não transaccional os níveis intermédios e baixos da hierarquia não compreendem a importância do DW;
3. Nunca ter a veleidade de querer desenvolver todo o DW de uma só vez. O único caminho para o sucesso é a construção de data marts integrados que são disponibilizados ao cliente à medida que ficam prontos;
4. Despender tempo e trabalho na tarefa inútil de estruturar o DW como se fosse uma base de dados relacional. O objectivo é conseguir uma estrutura especialmente adaptada à análise da informação e que produza interfaces amigáveis;
5. Nunca ir pelo caminho da complexificação da informação, a simplicidade é o lema do bom profissional;
6. Evitar a construção de diferentes tabelas de dimensão sobre o mesmo assunto.

Read More

Desenho da dimensão Data

Dimensão Temporal

A dimensão data é o exemplo clássico de uma tabela de dimensão empresarial com um tamanho gigantesco dado que está presente em todos os aspectos de um data warehouse. O desenho desta dimensão tem que ser devidamente avaliado de acordo com as utilizações previstas. As utilizações podem dividir-se em fáceis, moderadas e difíceis.

Fáceis

Se nos limitarmos a questões relativas a dias de per si e pusermos de lado os minutos e os segundos, as queries habituais neste caso poderão ser, por exemplo:

1.Quais são as aquisições de serviços feitas num determinado intervalo de tempo?
2. Será que a viagem alfa se realizou neste intervalo de tempo?
3. Os intervalos de tempo poderão ser definidos utilizando conceitos complexos de navegação temporal, incluindo estações do ano, períodos fiscais, dias em número ou feriados.

Para estes três exemplos é necessária uma única coluna do tipo timestamp na tabela de factos. No caso 1) a query terá que ir buscar todas as aquisições com um timestamp registado num intervalo de tempo definido pelo utilizador. Na segunda situação é seleccionado um timestamp de alfa que depois é comparado com um espaço de tempo. Para o último caso tem que obrigatoriamente utilizar-se à dimensão data que está ligada à tabela de factos por intermédio de uma chave estrangeira. Com esta ligação – básica e muito simples – é possível restringir uma data segundo um numeroso critério de descritores.

Em navegações complexas no calendário as queries tornam-se muito mais simples na presença de marcadores de inicio e de fim de período como, por exemplo, “último dia do período de Natal”. Neste caso o campo conterá um valor negativo em todos os dias exceptuando o último dia da época mencionada em que conterá uma anotação positiva. Estas marcas especiais permitem que períodos complexos dos processos de negócio sejam facilmente traduzidos em queries. Como é óbvio a utilização destes descritores implica que já não seja possível utilizar o timestamp da tabela de factos.

Moderadas

Um segundo grupo de queries temporal mais complexo inclui, por exemplo:

1. Quais são as aquisições de serviços na área de engenharia num determinado intervalo de tempo?
2. Qual foi o último trabalho como engenheiro de um funcionário num certo espaço temporal?
3. Qual é o balanço de eficiência de um processo energético num ponto temporal arbitrário?


Neste novo nível de dificuldade continuamos a assumir que os intervalos de tempo são balizados unicamente por dias. Apesar de continuar a ser possível responder aquelas questões utilizando uma única marca temporal, as queries resultantes são demasiado complexas e, consequentemente, pouco eficientes conduzindo a baixas performances das aplicações. Para responder à interrogação 3) é necessário o conjunto de todas as deficiências encontradas para a última ocorrência antes do desejado ponto temporal, o que em SQL tem que ser feito através de um sub-select embebido noutro mais geral. Além de lento é um procedimento que está em geral fora do alcance das ferramentas geradoras de código de SQL.

Para queries temporais de média e alta complexidade as aplicações poderão ser muito beneficiadas se cada linha da tabela de factos tiver associada um par de selos temporais, que indicam o início e o terminus do intervalo temporal em que ocorre uma transacção (caso das tabelas de factos de tipo transaccional) ou uma métrica agregada. A abstracção associada a este conceito é imaginar-se que uma ocorrência é um episódio com um valor constante num intervalo temporal.

A utilização de marcas temporais gémeas podem resolver as seguintes queries complexas:

1. Pesquisar quais são as aquisições em aberto com a data de início no ou antes do termo do intervalo temporal, e com a data final ocorrendo no ou após o início do período.
2. Procurar por uma única transacção com a data inicial no ou antes do fim do espaço temporal, e com a data final no ou após o término do tempo.
3. Pesquisa por uma única transacção com a data de início em ou antes de um ponto qualquer no tempo, e com a data de término em ou depois desse ponto arbitrário.


A maioria, se não todas, das queries temporais mais complexas podem ser resolvidas utilizando a cláusula between, dado que a sintaxe “value between two fields” é perfeitamente exequível. A maior desvantagem da utilização de marcas gémeas temporais é a necessidade de visitar duas vezes cada linha da tabela de factos: uma para registar a linha, e outra quando é possível fechar a data da transacção ou agregação. A ocorrência de valores not null na data de fim tem que ser devidamente acautelada para minimizar os erros no processamento da cláusula between: com o registo de uma data virtual localizada num futuro longínquo, ou utilizando uma sintaxe mais complexa no SQL.

Difíceis

Para resolver as situações mais complexas, como o registo de minutos e segundos, pode considerar-se a inclusão de quarto timestamps para cada linha da tabela de factos. Duas são campos sql-date vulgares que registam o detalhe pretendido, e as restantes são dias de calendário funcionando como chaves estrangeiras da dimensão data. Assim, é possível responder a pedidos temporais muito precisos, mas também a questões mais abrangentes como “Quais são as aquisições feitas no Dia de Natal?”.

Read More

As hierarquias nas dimensões

Caso típico da dimensão Cliente

Numa dimensão do tipo cliente podem coexistir várias hierarquias independentes entre si. A hierarquia mais evidente, e natural, é a geográfica. A organização de níveis em Portugal é freguesia, concelho e distrito. Mas, outras hierarquias existem: a do código postal que tem uma estrutura inteligente embutida; a das NUTS (Nomenclaturas de Unidades Territoriais para Fins Estatísticos - geocódigo desenvolvido pela União Europeia para referenciar as divisões administrativas dos estados membros para fins estatísticos).

A organização estrutural interna de um cliente (no caso de ser uma empresa) é outro tipo de hierarquia que pode estar presente na dimensão, ou seja, a tabela tem que incorporar da melhor forma possível a organização empresarial do cliente. Em algumas situações a definição da equipa de vendas dá origem a uma hierarquia adicional e independente das anteriores.

Uma hierarquia em condições muito particulares, quando tem uma estrutura longa e complexa, e relativamente estável, pode transformar-se numa dimensão independente. Quando o esquema em estrela tem poucas dimensões (menos de vinte) e a hierarquia é complexa pode justificar-se a criação de uma dimensão adicional dado que a exploração dos dados fica mais facilitada. Num esquema complexo (mais de vinte tabelas) a decisão mais acertada é manter as hierarquias num único local.

Nos casos em que as hierarquias de uma dimensão são divididas em tabelas independentes há quem desenhe uma tabela de ligação entre as hierarquias que contém unicamente as chaves primárias das dimensões. Mas, na realidade esse passo é desnecessário pois a associação entre as dimensões faz-se, como habitualmente, através da tabela de factos. Nunca nos devemos esquecer de que as tabelas de factos têm como função principal correlacionar as dimensões, que por natureza e definição são independentes umas das outras.

Read More

Enterprise Performance Management

EPM TV

Clive Longbottom, Research Director, Quocirca, said:

“To know how an organization is performing is a basic need, requiring full visibility of various processes and workflows across an organization, its partners and other stakeholders, as well as the correct means of monitoring and measuring how effective these variables work to a required end result. Our research shows that there remains much to be done, with disconnects between key steps and a lack of inclusion for essential stakeholders across processes.”

Read More