ODS vs. Data Warehousing

O ODS (Operational Data Store) é um elemento fundamental do data warehouse empresarial proposto por Bill Inmon, para muitos considerado o pai do Data Warehousing. O ODS é uma estrutura de dados normalizada, uma base de dados normal, construída com todas as regras de integridade inerentes ao modelo de dados relacional, e que serve de transição entre o sistema transaccional e os data marts segundo o pensamento de Inmon. 

Na óptica do modelo dimensional – que é a perspectiva que sigo – o ODS é uma estrutura redundante dado que obriga a que seja desenvolvida de raiz mais uma base de dados completa (diferente do sistema transaccional e do DW) cuja única e exclusiva função é a de abastecer de dados o DW. Então ficaríamos com duas bases de dados transaccionais com a mesma função, e cuja duplicação poderia dar azo a enganos na transição para o DW. 

Em questões de segurança da informação o ODS não tem nenhuma vantagem adicional pois como o seu conteúdo é reescrito diariamente – ou em que período seja – a partir dos dados transaccionais, qualquer erro – intencional ou por incompetência – no processo de carregamento do ODS resultará na sua corrupção. 

De qualquer modo, importa ainda salientar que a informação contida no data warehouse é não-volátil, ou seja, só em casos de erro (por exemplo: nomes incorrectos de pessoas) é que há lugar a modificação dos dados armazenados. 

A única forma de corromper um DW é utilizar uma metodologia errada de carregamento: apagar tudo o que já está no DW e carregar tudo de novo em cada momento de refrescamento, o denominado método da “força bruta”. Ora, como esse método não é casuístico e só se deve utilizar uma única vez (no carregamento inicial do DW) este problema não se coloca. É nessa primeira vez que deverão ser desencadeados mecanismos de auditoria que constatarão, ou não, da conformidade da informação do DW com os objectivos delineados no projecto da sua construção. A partir dai apenas é acrescentada informação ou corrigidos erros. 

O próprio data warehouse devido à sua estrutura em forma de estrela tem as regras de integridade necessárias e suficientes para impedir que sejam carregados dados fora de contexto. 

Em tudo o mais a segurança física do DW tem que ser assegurada de acordo com as políticas de Backup e Recovery em vigor no local de instalação do DW. Devido à importância funcional do DW na empresa (órgãos intermédios e superiores de decisão) é de muito bom senso que essas políticas de seguranças sejam devidamente certificadas.

Read More

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

Processos de negócio: software

Um processo de negócio é um conjunto de actividades que utilizam pelo menos um tipo de input, e que resulta num output com relevância económica, social ou técnica para uma organização. As actividades que constituem um processo desenvolvem-se numa determinada ordem ao longo do tempo de dos espaços organizacionais.

A análise de processos de negócio é um trabalho complexo que poderá ser bastante facilitado quando se utilizam aplicações informáticas apropriadas, como é o caso, por exemplo, do BizAgi Process Modeler que tem ainda a vantagem de ser um produto de livre utilização.

Read More

Lição sobre o Modelo Dimensional

Read More

Data Warehousing - Conceitos e Modelos

Data Warehousing - Conceitos e Modelos: é um novo livro sobre as técnicas fundamentais de desenho de data warehouses na perspectiva do modelo de dados Dimensional. É o primeiro livro desta área em Português de Portugal, é da autoria de Carlos Pampulim Caldeira e foi publicado pelas Edições Sílabo.

Edições Sílabo

ISBN: 978-972-618-479-9

Read More

Qual a melhor definição para Data Marts?

Conjunto de dados desenvolvidos com suporte num esquema em estrela e que pertencem à área de publicação do data warehouse.

No passado os data marts eram concebidos como uma forma de apresentar dados unicamente agregados, i.e., sobre os quais era aplicada uma aritmética qualquer, mas isso produzia aplicações muito rígidas que conseguiam responder apenas a um conjunto muito limitado de questões.

Actualmente essa utilização caiu em desuso e os data marts são presentemente estruturas muito flexíveis, que de preferência incorporam os dados mais atómicos que se conseguem extrair de um sistema operacional, e que são apresentados ao utilizador na forma de um esquema em estrela.

Read More

O que é o data warehousing?

As empresas e outras organizações precisam de desenhar estratégias de desenvolvimento e inovação de modo a estabelecerem políticas mais flexíveis, que consigam tirar o máximo proveito das oportunidades que surgem no mercado a todos os momentos.

O caminho para o sucesso de uma organização passa pela definição das estratégias adequadas e, como tal, pela utilização de sistemas de informação especializados e especialmente desenhados para servirem de suporte às decisões dos gestores e outros decisores.

Neste contexto os sistemas de data warehousing assumem um papel vital no planeamento das actividades empresariais, pois devido ao seu formato especial produzem aplicações optimizadas que são um auxiliar precioso no momento da escolha da melhor opção de entre o leque das alternativas possíveis.

Mas, o que são de facto os sistemas de armazenamento de dados?

São aplicações construídas de raiz com o único propósito de servirem como base, ou como um instrumento de apoio, à análise dos dados sobre os quais uma organização desenvolve as suas actividades. Não poderá dizer-se o mesmo, por exemplo, de uma base de dados tradicional? Que também é um sistema que permite tomar decisões? Claro que sim, senão não seriam uma das aplicações informáticas mais utilizadas na actualidade. Nenhum gestor, ou apenas um mau gestor, iria desperdiçar recursos da sua organização para adquirir software inútil. Devido às suas características estruturais as bases de dados têm uma grande capacidade em manter íntegros, e actualizados, grandes conjuntos de dados; sujeitos no entanto a alguns constrangimentos, sobretudo na área da usabilidade. De facto, e desde que construídas com suporte em modelos de dados robustos, a integridade e a baixa redundância dos dados são os pontos fortes de uma base de dados. Mas será que permitem tomar as melhores decisões?

As capacidades que as bases de dados têm em suportarem robustos sistemas de informação tem como contrapartida, e em consequência das regras semânticas que a suportam, uma estrutura muito complexa, composta normalmente por largas dezenas, e em muitos casos centenas, de tabelas e, sobretudo, ou acrescendo ainda a essa complexidade, um largo número de associações entre essas tabelas. Ora, a combinação entre a quantidade de tabelas e a forma como se relacionam entre si produz um autêntico quebra-cabeças, indecifrável, ou só muito dificilmente compreensível, pelos utilizadores. Bem, nem por todos os utilizadores, por vezes, essa estrutura complexa ainda consegue ser perceptível aos profissionais que a desenharam e por aqueles que têm a árdua tarefa de assegurarem a sua manutenção diária. Agora, quem não a consegue compreender, e muito menos utilizar de um modo eficiente são as pessoas que mais precisam desses dados para promover o desenvolvimento das organizações: os gestores.

Read More

Diferenças mais importantes entre uma base de dados e um data warehouse

	Base de Dados	Data Warehouse
Utilizador Tipo	Informáticos / Funcionários especializados	Gestores / Administração
Domínio	Tarefas rotineiras e operacionais	Decisões estratégicas
Objecto	Transacções	Análise de dados
Estrutura de Dados	Aplicacional	Orientado a temas

Read More

O que é a matriz em bus?

A matriz em bus é, como o seu próprio nome indica, um quadro com a função primordial de servir de suporte ao desenvolvimento faseado do data warehouse .

A matriz em bus é a ferramenta utilizada para criar, documentar e comunicar a arquitectura do data warehouse. A matriz é uma tabela em que as linhas representam os processos directamente associados aos fluxos de informação no seio de uma organização. Para aplicações matriciais nunca se devem considerar processos com suporte em ambientes departamentais ou sectoriais.

As linhas da matriz em bus vão traduzir-se em data marts com suporte nas actividades fundamentais da organização, ou seja, nos seus sistemas operacionais centrais. O desenvolvimento do data warehouse deve sempre iniciar-se pelos data marts com maior dimensionalidade, também conhecidos por data marts de primeira ordem. Esta opção além de simplificar o processo de construção do data warehouse, dá ainda aos utilizadores a possibilidade de terem um acesso mais precoce à aplicação.

Read More

O que diferencia uma base de dados de um data warehouse?

O uso universal de bases de dados relacionais consolidou um conjunto de boas práticas que actualmente são respeitadas com um rigor quase religioso pela sua comunidade de utilizadores. O baixo, ou mesmo nulo, nível de redundância (repetição dos mesmos dados em mais do que um local da base de dados) é o exemplo paradigmático, e mais conhecido, de uma das regras basilares do desenho de bases de dados relacionais. Para atingir bons níveis de redundância e de integridade da informação uma base de dados é tipicamente composta por um grande número de tabelas que se encontram ligadas entre si através de campos comuns.

A exploração da informação numa base de dados é feita através da linguagem SQL (Structured Query Language). As técnicas de programação em SQL (vulgarmente designadas como queries) são complexas e, consequentemente, fora do alcance dos utilizadores das bases de dados. Desse modo, a exploração dos dados está sempre limitada a um conjunto relativamente restrito de queries pré-programadas por especialistas na matéria. E, quando o utilizador tem uma necessidade diferente das que estão previstas inicia-se um círculo vicioso em que é feito um pedido aos informáticos, esse pedido entra na “linha de montagem” das queries, e num momento no futuro o programa é, finalmente, disponibilizado ao utilizador que avaliará a sua eficácia e formatação, o que poderá provocar um feedback (neste caso negativo) que retomará todos as etapas do circuito.

Um gestor que pretenda analisar a informação de uma base de dados segundo uma perspectiva original, para tomar uma determinada decisão tem, além de ter conhecimentos de programação em SQL, a obrigação de conhecer em profundidade o esquema da base de dados, i.e., em que tabelas estão armazenados os dados que procura e a forma como essas tabelas estão relacionadas entre si. Para um mero utilizador essas tarefas são um autêntico quebra-cabeças. Penso que nenhuma organização terá qualquer proveito em perder um bom gestor e ganhar um mau programador.

Read More