Artigos Banco de Dados Artigo SQL Magazine 14 - Modelagem de Data Warehouses e Data Marts – Parte II

Na primeira parte deste artigo apresentamos os conceitos básicos e um conjunto de passos que objetivam o entendimento do modelo de negócios que iremos modelar. Definimos os fatos ou métricas (o que estamos avaliando), as dimensões de negócio (como os fatos serão analisados), a granularidade das informações (nível mais baixo de detalhe) e sua hierarquia de agrupamento. Para isso, utilizamos um exemplo baseado em um modelo para a área comercial de uma rede de lojas de varejo tomando por base as possíveis necessidades de informação de um gerente comercial.

Nesta segunda parte do artigo vamos modelar um data warehouse ou um data mart que atenda estas necessidades utilizando a modelagem dimensional ou multidimensional. Este tipo de modelagem segue a chamada “escola Ralph Kimball”, introdutor do conceito do “star schema”, um esquema bastante utilizado para a modelagem de bases de dados de suporte à decisão. Apesar de ser o mais conhecido, o star schema não é o único. Existem uma série de variações incluindo uma opção normalizada deste esquema, o “snowflake”, que também iremos discutir neste artigo.

Assim, de posse das informações relevantes para o entendimento das necessidades do negócio, iniciaremos a modelagem da base de dados. A Figura 1 mostra, de forma bem simplificada, a representação das informações que iremos modelar. Estas informações foram definidas durante o primeiro artigo desta série, publicado na edição passada, onde foram apresentadas as necessidades gerenciais de uma empresa que atua na área comercial.

Representação das informações a serem modeladas no data warehouse/data mart
Figura 1. Representação das informações a serem modeladas no data warehouse/data mart

As tabelas de dimensão

A principal função de uma tabela de dimensão é reunir os atributos que serão utilizados para qualificar as consultas e cujos valores serão utilizados para agrupar e sumariar as métricas (ou fatos). Ou seja, as tabelas dimensão contêm atributos textuais que funcionam como filtros para as consultas do usuário.

Os atributos de uma dimensão podem compor uma hierarquia ou serem apenas descritivos. Em nosso exemplo, a dimensão Produto contém uma hierarquia composta pelos atributos item, linha e categoria, indicando que os itens de produto estão agrupados em linhas de produto, que por sua vez estão agrupadas em categorias de produto. Isto será bastante útil, posteriormente, durante a análise de informações pelo usuário. Podemos também incluir uma série de outros atributos descritivos que não façam, necessariamente, parte desta hierarquia, como o tipo de empacotamento (caixas com 12 unidades etc.), peso e outros que sejam relevantes para o processo de análise. Ralph Kimball sugere que as tabelas de dimensões possuam o maior número possível de atributos textuais para “enriquecer” o modelo de dados e, por conseqüência, as possibilidades de análise de informações. Podem existir, inclusive, várias hierarquias diferentes na mesma dimensão. Neste caso, porém, nomes de atributos e seus valores devem ser exclusivos para cada uma delas.

Gostaríamos de destacar que devem ser avaliados e escolhidos os atributos que sejam importantes para a análise. O data warehouse/data mart não deve ser confundindo com um grande cadastro de informações, muitas vezes repleto de dados não utilizados pelos usuários.

Um atributo muito importante da tabela dimensão é sua chave. A chave primária de uma tabela dimensão deve ser sempre um atributo único e definido pelo sistema com um valor genérico, inteiros atribuídos seqüencialmente. Por questões de desempenho, não se utilizam chaves compostas por várias partes, nem tampouco chaves concatenadas. A ordem aqui é a da simplicidade, para facilitar o acesso aos grandes volumes de dados armazenados. As chaves serão utilizadas apenas para possibilitar a junção de tabelas entre uma tabela dimensão e a tabela fato (que será o próximo tópico a ser discutido). Também não são utilizados as chaves ou identificadores provenientes de outros sistemas, como código do cliente ou código do produto.

Existem várias razões para se utilizar chaves genéricas, também chamadas de artificiais, substitutas ou surrogate keys. De acordo com Ralph Kimbal, uma das razões é que o data warehouse deve se manter isolado das regras operacionais para gerar, atualizar, excluir, reciclar e reutilizar os códigos utilizados nos sistemas transacionais. O data warehouse manterá as informações durante muito tempo (normalmente vários anos) e não pode ficar vulnerável a problemas de sobreposição de chaves, no caso de aquisição ou consolidação de dados. Outra razão é o melhor desempenho no acesso às informações. Muitas vezes, o código utilizado em um sistema transacional é um string de caracteres alfanuméricos que apresentam desempenho pior nas operações de acesso à base de dados do que as chaves genéricas, que utilizam o menor inteiro possível.

...
Quer ler esse conteúdo completo? Tenha acesso completo