O sucesso no desenvolvimento de um Data Warehouse (DW) bem modelado depende da escolha correta das estratégias a serem adotadas, de forma que sejam adequadas às características e as necessidades específicas do ambiente onde será implementado. Existe uma grande variedade de abordagens para o desenvolvimento de um DW. São elas: modelagem entidade-relacionamento, modelagem multidimensional e modelagem de dados corporativos. Uma modelagem correta do DW leva o usuário a ter uma garantia da confiabilidade dos dados e uma maior qualidade nos resultados obtidos.

Autores: Erika Maria Teixeira Araújo e Mônica de Lourdes Souza Batista

Qualidade na Modelagem dos Dados de um Data Warehouse

O contexto no qual as empresas estão inseridas atualmente demanda das organizações uma capacidade de analisar, planejar e reagir rápido para poder acompanhar ou superar as exigências dos clientes e à ameaça da concorrência. Para que isto seja possível, é necessário que a organização tenha disponível, quando necessários, as informações que constituem a base para obtenção de vantagens competitivas e maior fidelidade dos clientes.

A todo o momento uma grande quantidade de informações sobre os mais variados aspectos dos negócios da empresa é gerada e armazenada, passando a fazer parte da sua base de conhecimento.

É importante ter um padrão e fazer a escolha correta da modelagem a ser usada. Serão abordadas nesse artigo: Modelagem Entidade-Relacionamento, Modelagem Multidimensional e Modelagem de Dados Corporativos.

Questões que devem ser observadas na Modelagem de Dados

Para KIMBALL (1998), deve-se observar alguns aspectos durante a fase de elaboração da modelagem dos dados de um DW para que as consultas não produzam resultados incorretos, pois estas consultas servirão de base para as tomadas de decisões das empresas. Deve-se tomar cuidado para que o processamento analítico não se torne muito lento ou até mesmo impossível de ser executado.

Algumas questões a serem observadas na visão de KIMBALL (1998):

  • atributos semi-aditivos e não aditivos. O primeiro refere-se àqueles que só podem ser adicionados ao longo de algumas dimensões, o que restringe o número de consultas apenas àquelas dimensões em que o fato pode ser adicionado. Já os não aditivos são aqueles que não podem ser adicionados a qualquer dimensão: para este tipo só pode resumir registros através de contagens ou então consultar um a um. Uma operação não aditiva pode ser computada em qualquer plano da tabela de fatos (BOX 1).

    BOX 1. Tabela de Fatos
    É a tabela que fica no centro da estrela rodeada pelas tabelas auxiliares chamadas de tabelas dimensões. Na tabela de fatos são armazenadas as chaves primárias das tabelas dimensões e sempre é guardado um histórico nesta tabela).

    Não se deve adicionar o atributo semi-aditivo ao longo das dimensões da tabela fatos: deve-se limitar assim as operações válidas.

  • dimensões descaracterizadas: normalmente correspondem a números de pedidos, números de fatura, etc., ou seja, chaves de dimensão sem uma tabela correspondente em tabelas de fatos em que o registro da mesma é o documento propriamente dito ou uma linha de item do documento.
  • dimensões derivadas que suportam agregações: é de fundamental importância que seja construída a tabela de fatos derivados em vários níveis superiores de detalhe para melhorar o desempenho das consultas. De acordo com, KRATZ (2007) existem diversas formas de agregações no DW, sendo as mais comuns:
    a) cumulativa simples: as transações diárias são transportadas do ambiente operacional e resumidas em forma de registros no DW. O resumo pode ser feito por qualquer área de interesse, segundo a qual o DW esteja organizado;
    b) resumo rotativo: os dados passam do ambiente operacional para o DW, como mencionado anteriormente. A diferença está na forma como é realizada a agregação;
    c) dimensões grandes: não se deve desmembrar as dimensões, mesmo que elas sejam extensas, pois poderá causar um desempenho limitado;
    d) dimensões de modificações lentas: o DW deve representar de forma concreta o histórico passado, por isso não se pode considerar que as entidades não se modificam ao longo do tempo;
    e) tabela de fatos sem fatos: alguns processos que são representados no DW produzem tabelas de fatos semelhantes às tabelas que foram construídas, mas que não contém fatos mensuráveis.

Modelagem de Dados Entidade-Relacionamento

O modelo entidade-relacionamento (Figura 1) é uma ferramenta de modelagem usada para definir informações que serão necessárias a um modelo de dados baseado em entidades e relacionamentos (LOBO, 2007).

O modelo de entidade-relacionamento é representado por um diagrama ER (Entidade-Relacionamento) e utiliza três símbolos gráficos:

  • entidade representa as coisas importantes em uma organização;
  • atributos, que são as propriedades das entidades; e relacionamento, que é quando uma entidade está relacionada a uma ou mais entidades (MACHADO,2006).

exemplo de modelo entidade-relacionamento

Figura 1. Exemplo de Modelo Entidade-Relacionamento. Fonte: Cougo, 1997.

A abordagem ER é composta de uma técnica de diagramação e de um conjunto de conceitos que devem ser entendidos e respeitados. A técnica de diagramação utilizada é bastante simples e serve como meio de representação dos próprios conceitos por ela manipulados. É utilizado um retângulo para representar as entidades, um losango para representar os relacionamentos e balões para indicar e alocar atributos (COUGO, 1997).

O modelo de ER é bastante simples e objetivo, por isso, a abordagem ER possui muita flexibilidade e adaptabilidade. Mas ao contrário do que possa parecer essa é a maior qualidade do modelo (COUGO,1997).

Entidades

A entidade é definida como aquele objeto existente no mundo real, com uma identificação diferente e que possui significado próprio (MACHADO,2006).

Segundo MACHADO (2006), uma pessoa, um lugar ou um evento podem ser definidos como entidades, pois representam classes de objetos, que são coisas do mundo real e podem ser observadas e classificadas por suas propriedades e características.

Para identificar e reconhecer um objeto como uma entidade pode-se observar cinco grupos de elementos: as coisas tangíveis, as funções exercidas por elementos, eventos ou ocorrências, interações e especificações (COUGO, 1997).

É de extrema importância o nome que é dado a uma entidade para facilitar o seu entendimento e a comunicação na modelagem. A nomenclatura semântica que representa as características e o escopo da entidade é o critério a ser utilizado para uma entidade (MACHADO, 2004).

Relacionamentos

O relacionamento é representado através de linhas que ligam duas entidades em um diagrama ER (MACHADO, 2004).

Uma entidade pode se relacionar com diversas outras entidades, independente do seu relacionamento ser entre instâncias de objetos de diferentes tipos, como, por exemplo, relacionar Pessoa com Carro, ou entre instâncias de um mesmo tipo de objeto, por exemplo, um auto relacionamento de Vigilante (COUGO, 1997).

Atributos

Os atributos descrevem as características de propriedades de uma entidade (MACHADO, 2004). Para COUGO (1997), ao se observar um objeto em um ambiente, na verdade, estão sendo reconhecidos os elementos identificados através de suas características próprias. Estas características, inerentes a cada um desses objetos serão, em princípio, comuns a todos os objetos, ou elementos individualizados, pertencentes a um mesmo conjunto.

Desta forma, ao observar um objeto que passa pela rua a nossa frente, seremos capazes de, em um primeiro momento, definir que o objeto visto é um “carro” e não uma “pessoa”. Este tipo de reconhecimento é realizado a partir da verificação de uma série de características para as quais atenderemos e julgaremos. É através das características particulares de cada objeto é que conseguimos identificar cada um (COUGO, 1997).

O nome de um atributo deve ser único em uma entidade. Por exemplo, denominando um atributo de data_1 ou data_2 não está clara sua semântica, ou seja, o que este atributo representa. Por outro lado, colocar data_do_pedido fica claro, referindo- se à emissão de um pedido (MACHADO, 2004).

Agregação

A modelagem de sistemas usa o termo agregação com os mais variados significados. Porém, o conceito lançado pela modelagem de dados refere-se à visão de um par de entidades relacionadas com cardinalidade de muitos para muitos (MACHADO, 2004).

MACHADO (2004) chama a atenção para a existência de dependências entre os fatos, onde um fato somente acontece após a existência do outro fato, mas isso não é possível demonstrar em um diagrama de ER.

Modelagem de Dados Multidimensional

Para MACHADO (2004), a modelagem de dados multidimensional é mais fácil e mais simples de ser entendida do que a modelagem de dados de entidade-relacionamento. Mas ele deixa claro que é um conceito novo e ainda não tem a firmeza em seus detalhes de técnicas de desenvolvimento para sistemas analíticos como o modelo de entidade-relacionamento.

Modelagem multidimensional é uma técnica de concepção e visualização de um modelo de dados de um conjunto de medidas que descrevem aspectos comuns de negócio. Sua utilização ajuda na sumarização e reestruturação dos dados e apresenta visões que suportam a análise dos valores destes dados (MACHADO,2004).

De acordo com OLIVEIRA (2002), um banco de dados multidimensional não armazena os dados como registros em tabelas, mas sim em arrays multidimensionais, possuindo um número fixo de dimensões.

Três elementos básicos compõem o modelo multidimensional: (MACHADO, 2004)

  • Fatos: é uma coleção de itens de dados composta de medidas utilizada para analisar o processo de negócio de uma empresa, refletindo assim a evolução dos negócios do dia a dia. Esse conceito é implementado em tabelas denominadas tabelas de fato (fact tables) e representado por valores numéricos;
  • Dimensões: são os elementos que participam de um fato e que determinam o contexto de um assunto de negócios. As dimensões podem ser compostas por membros que podem conter hierarquias. Membros são as possíveis divisões ou classificações de uma dimensão. Por exemplo, a dimensão tempo pode ser dividida nos seguintes membros: ano, trimestre e mês; e a dimensão localização em: cidade, estado e país;
  • Medidas (variáveis): são os atributos numéricos que representam um fato, ou seja, o desempenho de um indicador de negócios relativo às dimensões que participam desse fato. Uma medida é determinada pela combinação dessas dimensões e estão localizados como atributos de um fato. Por exemplo, o valor em reais das vendas, o número vendido de unidades de produtos e a quantidade em estoque.

Os modelos multidimensionais tiram proveito de relações inerentes aos dados, para gerar estes em matrizes multidimensionais chamadas cubos de dados. Porém, o número de dimensões, quando maior que três, sugere um hipercubo. Como a visualização gráfica de um hipercubo é difícil, a literatura utiliza geralmente como referência apenas o cubo.

O modelo de dados multidimensional é caracterizado por valores, geralmente contínuos, distribuídos em uma ou mais dimensões, como por exemplo, o total de vendas de um produto agrupado por mês e por loja. Para um produto, em um determinado mês e uma loja específica existe apenas um total de vendas. Pode-se imaginar estes dados através de um cubo tridimensional onde uma dimensão representa os produtos, a outra representa as lojas e a terceira representa o mês/ano. Um exemplo pode ser visto na Figura 2, onde 253 é a quantidade vendida (medida) do produto 40, no mês 01/2003 da loja 1.

cubo tridimensional

Figura 2. Cubo Tridimensional com o Total de Vendas. Fonte: CAMPOS, 2005.

Modelagem de Dados Corporativos

INMON (1997) recomenda a utilização do modelo de dados corporativo para construir um DW, pois este modelo possui todos os atributos necessários para registrar as informações dos sistemas operacionais da empresa.

De acordo com INMON (1997), para utilizar o modelo de dados corporativo tem-se que fazer um considerável número de alterações dos dados. Para tal, INMON (1997) fornece alguns passos que podem ser seguidos, não se esquecendo de que o fundamental é que as decisões de transformação devem ser tomadas levando-se em consideração os requisitos específicos da empresa (GOMES, SILVA e ALBUQUERQUE, 2007):

  • remoção dos dados puramente operacionais: consiste na remoção dos dados usados apenas em ambientes operacionais como, mensagem, descrição e status, pois estes normalmente não são utilizados no processo de tomada de decisão. Também se deve levar em conta o custo para gerenciar grandes volumes de dados.
  • adição de um elemento de tempo na estrutura da chave: deve-se adicionar um elemento de tempo as chaves das tabelas, se estas não tiverem. Como por exemplo, a chave é a identificação do consumidor, pois mais tarde os dados do consumidor podem sofrer alterações e assim ficará fácil descobrir qual consumidor teve os dados alterados;
  • introdução de dados derivados: adiciona-se dados derivados que serão usados habitualmente mas de forma que estes dados só sejam calculados uma única vez. Assim ocorre uma redução no processamento que deve ser feito para acessar os dados derivados ou sumarizados;
  • transformação de relacionamentos entre dados em artefatos dos dados: os relacionamento encontrados nas modelagens clássicas assumem que há um e somente um valor de negócio no relacionamento. O DW tem característica de armazenar dados históricos, possuindo muitos valores para um dado relacionamento entre duas tabelas. Sendo assim, a melhor maneira de representar o relacionamento entre duas tabelas no DW é através dos artefatos;
  • acomodação dos diferentes níveis de granularidade: o nível de granularidade do sistema transacional pode ser o mesmo do DW ou não. Alterando o nível de granularidade o modelo de DW também sofre alteração na sua representação;
  • união dos dados comuns de diferentes tabelas: considera a possibilidade de combinar duas ou mais tabelas do modelo corporativo em uma única tabela do modelo de DW;
  • criação de arrays de dados: o modelo corporativo normalmente é normalizado e existem grupos repetitivos que não é permitido, mas há situação no ambiente de DW que podem haver grupos repetidos de dados. As condições para a existência destes são: quando o número de ocorrências do dado é previsível, quando a ocorrência do dado é relativamente pequena (em termos de tamanho fixo), quando as ocorrências do dado geralmente são usadas juntas e por fim quando o padrão de inserção e remoção dos dados é estável.

Há várias vantagens em se utilizar esta abordagem. Uma delas, é que não tendo registros individuais para cada mês, uma certa quantidade de espaço é economizada. Além disso, o índice no modelo corporativo requer 12 entradas para cada entrada no modelo do DW. Outra vantagem é a possibilidade de organizar todas as ocorrências anuais dos dados em uma única localização física, criando a possibilidade de um aumento de performance. Obviamente, esta melhoria de performance está condicionada ao SGBD em questão, a organização física dos registros dentro deste, e outros (GOMES, SILVA, ALBUQUERQUE, 2007).

A Importância da Modelagem de Dados para Garantir a Qualidade

A modelagem de dados é um modo eficiente de entender os dados. O seu propósito é prover um registro apurado de alguns aspectos do mundo real para um contexto particular. Através da modelagem, o projetista do banco de dados pode eliminar redundâncias, que representam algumas das fontes de informações inconsistentes e podem levar a sistemas ineficientes (COUGO, 1997).

Um modelo de dados é uma coleção de conceitos que podem ser utilizados para descrever um conjunto de dados e as operações para a sua manipulação (BATINE, CERI, NAVATHE, 1992). A não utilização de um modelo implica em um crescimento desorganizado das aplicações, promovendo altos custos, esforços para a manutenção e dificuldades no crescimento de uma aplicação. O modelo permite ao usuário um melhor entendimento do negócio, com a vantagem de facilitar a visualização das consequências de qualquer ação dentro do ambiente e o impacto de qualquer mudança sobre o mesmo (DEVLIN, 1997). Ele representa a definição, caracterização e relacionamento dos dados em um determinado ambiente. Um dos diagramas mais empregados na modelagem de dados é o Diagrama de Entidade e Relacionamento (DER).

A modelagem deve sempre que possível levar em consideração a possibilidade de futuras implementações nas organizações. A capacidade de reconhecer antecipadamente estas necessidades dependerá em grande parte da experiência e conhecimento da equipe de desenvolvimento em relação às necessidades da organização. A modelagem deve levar em consideração aspectos como: aquisição dos dados; arquivamentos dos registros de dados; padronização dos dados; comunicação e integração; armazenamento e recuperação das informações e análise dos dados para levantamento (WEN, 2007).

Este artigo abordou o desenvolvimento de uma modelagem de dados multidimensional em diversas formas mostrando as características, vantagens e desvantagens de cada uma. Trouxe ainda a importância da modelagem de dados para garantir a qualidade dos dados.

Referências

  • CAMPOS, R. A., Qualidade de dados em Data Warehouse. TCC (Graduação em Bacharelado em Sistemas de Informação). Centro de Ensino Superior de Juiz de Fora, Juiz de Fora, 2005.
  • BATINI, C.; CERI.; NAVATHE, S. B. Conceptual database design: an entity-relationship approach. Califórnia: The Benjamin/Cummings Publishing Company, 1992. 470 p.
  • COUGO, P. Modelagem conceitual e projeto de bancos de dados. Rio de Janeiro: Campus, 1997.
  • DEVLIN, Barry. Data Warehouse from architecture to implementation. Massachusetts: Addison-Wesley, 1997. 432 p.
  • GOMES, Elaine Carneiro; SILVA, Érica Marques da; ALBUQUERQUE, Michele de. Construindo um Data Warehouse. Disponível em: <http://www.datawarehouse.hpg.ig.com.br/>. Acesso em: 02 ago. 2007.
  • INMON, W. H. Como construir o Data Warehouse. Rio de Janeiro: Campus, 1997.
  • Kimball, R. Data Warehouse Toolkit. Makron Books, Rio de Janeiro: Campus, 1998.
  • KRATZ, L.G., et al. Data Warehouse: a experiência da ANVISA. Disponível em: . Acesso em: 02 ago. 2007.
  • LOBO, A. Modelagem de um estudo de caso utilizando a ferramenta entidade/relacionamento, baseada no modelo de Peter Chen. Disponível em: . Acesso em: 21 abr. 2007.
  • MACHADO, F.N.R. Projeto de Data Warehouse: Uma visão multidimensional, São Paulo: Érica, 2004.
  • MACHADO, F.N.R. Tecnologia e projeto de Data Warehouse. São Paulo: Érica, 2006.
  • OLIVEIRA, M. P. J.; EDELWEISS, N.; RIBEIRO, P. F. H. C. Sistema distribuído para intercâmbio de dados de saúde - SIDI. Disponível em: . Acesso em: 12 ago. 2007.
  • WEN, L.C., Informatização eficiente. Disponível em: . Acesso em: 08 ago. 2007.

Saiba mais sobre Data Warehouse;)