Metodologia segundo Cavero

O trabalho desenvolvido por Cavero et al. (2002, 2003) propõe uma metodologia para o projeto de DW através da modelagem conceitual, propondo a utilização do paradigma multidimensional durante a fase de projeto e manutenção, integrado com a metodologia de desenvolvimento de software. A proposta baseia-se no modelo conceitual ER e nos requisitos do usuário.

O modelo aborda sete etapas no desenvolvimento do processo, descritas a seguir:

Etapa 1: obter a estrutura preliminar de subcélulas

Inicialmente a metodologia visa obter um esquema preliminar, que corresponde à definição do negócio a ser modelado. Nesta etapa podem ser analisadas diferentes fontes de dados e os requisitos dos usuários. Se existe um esquema conceitual ER, podem ser usadas entidades ou atributos dos relacionamentos n:n para gerar esta estrutura preliminar de subcélulas.

Cada estrutura de células é composta de subestruturas, chamadas estruturas de subcélulas e seus métodos. Cada estrutura de subcélula consiste de um atributo de síntese e um conjunto de funções de síntese que representam como os dados operacionais serão processados para obter os dados sumarizados.

Etapa 2: obter as dimensões preliminares

O próximo passo é detectar as dimensões que irão fazer parte do esquema, ou seja, os valores que podem ser agregados. Nesta etapa, os usuários devem considerar dimensões de modo geral, sem detalhar os atributos multidimensionais hierárquicos. Uma dimensão é constituída de atributos multidimensionais.

Etapa 3: obter as hierarquias preliminares

Neste ponto já existe um esquema preliminar, com um conjunto de estruturas de subcélulas definidas em algumas dimensões. Portanto, agora é necessário identificar de maneira mais precisa as dimensões e suas hierarquias. Deve-ser identificar cada dimensão, descrevendo suas hierarquias de agregação. Porém, ainda não é necessário detalhar domínios das dimensões para cada agregação. Nesta etapa novas dimensões podem ser detectadas, como a dimensão Tempo.

As hierarquias são definidas a partir dos esquemas conceituais do banco de dados operacional, observando os atributos, entidades e seus relacionamentos.

Etapa 4: refinar as hierarquias

A próxima etapa compõe-se do refinamento das hierarquias obtidas na etapa anterior. Este refinamento consiste em um detalhamento dos atributos multidimensionais das hierarquias. Novos atributos podem ser detectados, assim como convertidos em atributos de descrição. Devem ser definidos os domínios para cada atributo, assim como os domínios das agregações de hierarquias devem ser detalhados, com suas respectivas funções.

Os domínios de descrição são usados para representar os atributos de descrição que representam informação complementar sobre os atributos multidimensionais.

Uma agregação consiste de uma função agregação e dois domínios de dimensão, sendo um deles o original e o outro o destino. Uma hierarquia é um grupo de domínios de agregação, representada por um gráfico onde cada nó representa um domínio de dimensão, e cada arco representa uma função de agregação.

Etapa 5: obter a estrutura detalhada de subcélulas

Neste instante já se observa que estão completamente definidas as dimensões e suas hierarquias, portanto, deve-se detalhar as estruturas das subcélulas. Para cada estrutura de subcélula especificam-se seus atributos e funções de sumarização, em que usualmente são utilizadas a função SUM.

Atributos sumarizados da tabela Fatos são definidos como domínios quantitativos nos quais podem ser aplicadas operações matemáticas e domínios booleanos, usados para indicar a existência ou não de informação.

Etapa 6: obter o esquema Fatos

Nesta etapa agrupam-se as estruturas de subcélulas em estruturas de células para formar esquemas Fatos. Cada estrutura célula pertence a um esquema Fatos e cada esquema Fatos possui dimensões associadas. Portanto, devem ser detectadas estruturas de subcélulas que puderem ser agrupadas em um único esquema Fatos.

A chave primária da tabela Fatos é composta das chaves estrangeiras das tabelas de dimensão. Todo atributo sem função de sumarização é transformado em colunas da tabela Fatos, caso contrário, cada função é transformada em uma coluna que irá armazenar o resultado do dado operacional sumarizado.

Etapa 7: verificar e validar o esquema multidimensional

Nesta etapa assegura-se que o esquema conceitual esteja completo, ajustado aos requisitos do usuário e critérios pré-definidos de qualidade. Outras verificações

devem ser feitas, como a disponibilidade de dados nas fontes de dados.

A utilização de uma metodologia tradicional de desenvolvimento de projetos proposta por Cavero et al. (2003) também é proposta por Prakash e Gosain (2003), que representam as etapas e resultados esperados para cada uma delas no quadro 8, adaptando os resultados para o ambiente da modelagem multidimensional.

Etapa Resultado

Levantamento de requisitos Objetivos e hierarquias de decisão.

Projeto conceitual Fatos, dimensões, agregações, metadados, dados históricos.

Projeto lógico Representação em DDL do pacote DW a ser usado.

Projeto físico Layout físico do DW.

Fonte: Adaptado de Prakash e Gosain (2003).

A metodologia utiliza o modelo de dados multidimensional no projeto conceitual. Para o projeto lógico e físico, podem ser usados o modelo de dados multidimensional ou o relacional. No projeto conceitual são representados os requisitos do usuário de maneira similar ao modelo ER. Sistemas OLTP e requisitos obtidos dos usuários são as principais entradas do esquema conceitual.

A metodologia é fundamentalmente focada na modelagem de dados e não considera os aspectos funcionais do desenvolvimento.

No trabalho apresentado no ano seguinte (Cavero et al., 2003), os autores colocam sua proposta baseada nas metodologias tradicionais de desenvolvimento de software, com as etapas de análise, projeto e implementação. Esta metodologia segue as etapas anteriormente estabelecidas para definir o projeto conceitual, utilizando os conceitos de Fatos, Dimensões e Hierarquias. No projeto lógico e físico, pode-se utilizar o modelo relacional ou multidimensional.

A figura 16 mostra um exemplo do esquema gráfico final proposto na metodologia, representando respectivamente as fases de análise, projeto e implementação: Information System Analysis (ASI), Design (DSI) e Construction (CSI).

Esta metodologia assemelha-se ao trabalho desenvolvido por Hüsemann et al. (2000), que propõe um modelo de processo do projeto de um DW similar ao processo tradicional de projeto de banco de dados, colocando o modelo em quatro fases seqüenciais:

• Fase de análise de requisitos e especificação: o modelo operacional ER envia informações básicas para determinar o potencial da análise multidimensional. Nesta fase, os responsáveis pelo negócio selecionam estrategicamente atributos relevantes do banco de dados operacional e especificam a finalidade para usá-los como dimensões e/ou medidas. • Fase de projeto conceitual: transforma a especificação de requisitos de

negócios semiformal em um esquema conceitual multidimensional formalizado. A formalização resulta em um esquema multidimensional gráfico, que abrange o esquema Fatos com suas Medidas e as hierarquias de Dimensão.

• Fase de projeto lógico: o esquema conceitual é convertido em um esquema lógico, gerado de acordo com as regras de transformação que se referem apenas aos diagramas conceituais desenvolvidos e restrições resumidas.

• Fase de projeto físico: implementação do esquema lógico com as respectivas propriedades individuais do objetivo do sistema de banco de dados, incluindo as técnicas de otimização física, bem como os ajustes específicos para as aplicações OLAP, como a desnormalização relacional das tabelas Dimensão.

Figura 16 - Exemplo da metodologia proposta. Fonte: Cavero et al. (2003, p. 196).

Expert users (business analysts, specialists,...) Existing DB (ER conceptual schemes)

Conceptual schems (using IDEA model) Relational with multidimensional issues logical scheme Pure multidimensional logical scheme Data Warehouse (MOLAP) Data Warehouse (MOLAP) Conceptual modeling Transformation into a multidimensional

model (MOLAP) Transformation into

a relational model (ROLAP) Construction

ASI-MD

DSI-MD

CSI-MD