SOUZA, R., BAX, M.P. “Modelagem Estratégica
de Dados: Normalização Versus ‘Dimensionalização’ ”. In: Anais KMBrasil,
SP, 2003.
MODELAGEM ESTRATÉGICA DE
DADOS:
NORMALIZAÇÃO VERSUS “DIMENSIONALIZAÇÃO”
Roberto Souza
Marcello Peixoto Bax
Roberto Souza
Marcello P. Bax
Resumo
Na busca por informações que apóiem decisões
estratégicas, as corporação devem atentar ao optar por soluções de armazéns de dados
(data
warehouse ) que afirmam ter a “bala de prata”. Muitas
delas, que se dizem implantadas em poucas semanas, não garantem a flexibilidade
necessária e não realizam adequadamente as tarefas de limpeza e integração dos
dados corporativos. Em geral, o que se obtêm ao final do processo de modelagem
é uma gigantesca “massa de dados” inconsistente que pode acarretar em erros de
avaliação estratégica com perdas consideráveis para as corporações. Este artigo
discute o processo de modelagem de dados na construção de armazéns ( warehouses ) através de
análise crítica e comparativa de duas abordagens ao problema de modelagem de
dados. Serve
de pano que
tem como pano de fundo para a discussão o debate teórico entre dois
dos principais autores da área, e suas respectivas abordagens abordagens
ao problema de modelagem de dados.
Palavras-c Chave:
data warehouse, armazéns de dados, modelagem de dados,
sistemas de apoio à decisão, Sistemas OLAP.
In the search for
information that supports strategic decisions, the corporation must attempt
when opting to solutions of data warehouses that affirm to have the silver
bullet. Many of them, said to be implanted in few weeks, do not guarantee the
necessary flexibility and they adequately do not carry through the tasks of
cleanness and integration of the corporative data. In general, what is gotten at the end of
the modeling process is a gigantic and inconsistent data mass that can bring errors of strategic
evaluation with considerable losses for the corporations. This article argues
the process of data modeling in the construction of data warehouses through
critical and comparative analysis of two common approaches to the problem of data modeling. Serving as
a background the
article presents the theoretical debate between two of the main
authors in the area, and its
respective approaches to the
problem.
Keywords: data warehouse, data modeling,
decision support systems, OLAP systems.
INTRODUÇÃO
Evento internacional sobre Inteligência Empresarial, na cidade de São Paulo em 2002, discutiu os últimos avanços sobre data warehouse. Dois pesquisadores participaram do evento: Bill Inmon e Sean Kelly. O primeiro é considerado o “pai do data warehouse”, tendo publicado os primeiros artigos e livros sobre o tema; o segundo é considerado uma nova referência na área, autor de recentes livros sobre o assunto.
Os dois pesquisadores, ao lado de Ralph Kimball, são apontados como os três grandes líderes intelectuais desta recente tecnologia. No congresso principal do evento referido acima, S. Kelly defendeu o uso de soluções prontas de data warehouse para o suporte a decisões estratégicas como a melhor e mais viável alternativa a ser seguida por qualquer corporação interessada em melhorar seus processos decisórios.
Como se sabe, nos anos 90 houve grande expansão dos sistemas
integrados de gestão empresarial (ERP´s), com seus modelos transacionais,
infra-estrutura e ferramentas para automação do ambiente operacional
corporativo. Diversas aplicações se firmaram como soluções neste campo, tais como:
SAP, J.D. Edwards, BAAN, entre outros[i].
Como se sabe,
estas aplicações sSão soluções que vêm do fornecedor com
aproximadamente 60% dos processos pré-definidos e 40% personalizáveis. A grande
base instalada que
comprova e o relativo sucesso dessas soluções
vêm fortalecendo a crença de que estratégia análoga deve também ser apropriada,
e pode ser aplicada à modelagem de warehouses.
Seguindo exatamente essa idéia, S. Kelly defende
um modelo genérico, teoricamente personalizável para implantação de data
warehouse. Assim como nos existe para os sistemas de gestão
empresarial, para o autor existiria um modelo genérico adaptável a virtualmente
qualquer corporação, capaz de fornecer asas informações úteis para o
suporte a decisões. Para argumentar em favor da idéia o autor se apóia no menor
tempo de implementação, já que boa parte do modelo é adquirida pronta, e seu
efeito positivo no
cálculo do retorno do investimento.
Conforme se pôde notar da participação no evento citado
acima e da leitura dos artigos referenciados, existe uma grande diferença
fundamental nas
abordagens de modelagem de warehouses presentes no discurso dos dois
autores, S. Kelly e B. Inmon. Inspirado em um debate
entre os dois autores no congresso
anteriormente citado, este artigo tem o objetivo de discutir o alto grau
de normalização visando flexibilidade e consistência do warehouse
defendida por Inmon, versus a desnormalização das dimensões para
satisfazer consultas ad-hoc: estratégia defendida por Kelly e nomeada
“dimensionalization”. Todos estes conceitos são explicados na seqüência deste
documento, na Seção 3. Em seguida, na Seção 4 o artigo coloca em perspectiva o
conceito de dimensionalization visando nível de serviço, versus o
conceito de normalização buscando flexibilidade no processo de modelagem.
Finalmente, na Sessão 5, serão feitas algumas considerações à guisa de conclusãofinais.
SUPORTE À TOMADA DE DECISÕES ESTRATÉGICAS
Após décadas implantando sistemas transacionais, voltados
para automatizar processos operacionais, as corporações acreditaram que estariam
construindo, em paralelo, também uma fundação sólida para suas necessidades
futuras relativas à geração de informações estratégicas de apoio a processos
decisórios. O fato é que esse benefício, que se espera adjacente,
não virá sem uma reflexão teórica mais profunda e específica sobre como
organizar os dados de forma a poder explorá-los no apóio à tomada de decisões
estratégicas.
Vários fatores desencadearam, no início dos anos 90, o
esforço teórico/prático para o desenvolvimento do conceito de data warehouse, dentre os quais cita-se:
- a falta
de integração entre as diversas aplicações transacionais que acumulavam dados;
- a
inexistência de dados históricos, passíveis de apoiar decisões futuras;
- a
modelagem tradicional, excessivamente voltada para manipulação de transações
atômicas;
- e ainda a
dificuldade de transição entre as diversas tecnologias de banco de dados.
Juntos esses e outros fatores não impediram a construção de ambientes mais eficientes do ponto de vista operacional, porém eles continuam a dificultar o processo de extração de informações úteis no apoio à tomada de decisões estratégicas. Dificuldades ainda persistem nesse campo.
Buscando apoiar os processos de tomada de decisões estratégicas, verificou-se que a flexibilidade no acesso aos dados (ou flexibilidade da informação) é um aspecto crucial a ser considerado. Ou seja, na implementação de um data warehouse os dados devem servir de origem para qualquer consulta gerencial que possa ser desejada, pelos diversos sistemas ou setores da corporação, evitando inconsistências causadas por replicações dos mesmos.
Além da flexibilidade, outro aspecto importante (para a
construção de um warehouse) é o grande esforço necessário para
extrair, transformar e integrar dados oriundos dos chamados “sistemas legados”,
normalmente presentes e espalhados por toda a empresa. A tarefa de integração
pode ser tão complexa, que muitos se curvam diante dela e
partem para soluções não integradas – vem daí, em parte, a
crença de que data marts isolados são suficientes, prescindindo de um modelo
corporativo global. Porém, após a construção de um pequeno número de data
marts isolados, diversos inconvenientes serão notados:
- esforços e custos duplicados para extração de dados comuns;
- potencial redundância e conseqüente inconsistência de dados e informações;
- integração precária entre representações de diversos modelos isolados; dentre outros.
Talvez a principal razão da grande aceitação do conceito de data warehouse seja o fato deste último possibilitar o suporte a decisões de toda a corporação através de metodologia estruturada e rigorosa, até então inexistente. O escopo destas decisões pode ser bem focado e direcionado a um determinado assunto, ou pode ser amplo e envolver mudanças substanciais nas estratégias da corporação.
CONCEITOS BÁSICOS EM MODELAGEM DE DADOS
Normalização
Normalização é o processo de organização de dados em um banco de dados. Isto inclui a criação de tabelas e o estabelecimento de relacionamentos entre elas de acordo com regras formuladas para proteger os dados e tornar o banco de dados mais flexível, eliminando dois aspectos: redundância e dependência inconsistente.
Redundância consiste em desperdício de espaço em disco e traz problemas de manutenção. Um dado existente em mais de um lugar requer que o mesmo seja modificado exatamente da mesma maneira em todas as localizações. Uma mudança de endereço de cliente é muito mais simples se o dado é armazenado apenas na tabela de clientes e em nenhum outro lugar no banco de dados.
A pesquisa na tabela de clientes procurando por um endereço de um cliente específico é intuitiva, mas não faz sentido pesquisar na tabela de clientes buscando o salário do empregado que costuma atender àquele cliente em particular. O salário do empregado é relacionado, ou é dependente, do empregado e desta forma deve estar armazenado na tabela de empregados. Dependências inconsistentes podem dificultar o acesso aos dados.
Existem algumas regras para normalização de bancos de dados. A cada regra é dado o nome Forma Normal. Se a primeira regra é observada, o banco de dados é considerado na “primeira forma normal”. Se as primeiras três regras são observadas, o banco de dados é considerado na “terceira forma normal”, e assim sucessivamente.
A exemplo de muitas regras, modelos e especificações formais, cenários reais nem sempre permitem conformidade perfeita. Em geral, normalização requer objetos adicionais e alguns consideram este fato indesejável. Em uma aplicação transacional, às vezes pode-se conseguir uma melhor performance com a violação de algumas das regras de normalização. Ao se decidir por fazê-lo e comprometer o modelo, é necessário garantir que as aplicações que acessam o banco de dados tratem todos os problemas possíveis como a redundância e dependências inconsistentes. É necessário também ter em mente que um modelo não normalizado tem sua evolução dificultada à medida que ocorrem alterações nos requisitos do ambiente.
Armazém de dados (Data Warehouse)
Um data warehouse é uma coleção de dados usada no suporte ao processo de decisão gerencial com as seguintes características: orientada por assuntos (ao assunto); integrada; variável no tempo; não volátil.
Dados brutos destinados ao data warehouse vêm quase sempre de ambientes não integrados (freqüentemente antigos sistemas legados). O data warehouse é um repositório de dados fisicamente separado dos sistemas transacionais operacionais mesmo que os dados do data warehouse sejam gerados a partir de dados extraídos do ambiente operacional.
O objetivo de um data warehouse é permitir o fácil acesso a dados consistentes para proporcionar melhores decisões estratégicas.
Armazém de dados focados em assunto (Data Mart)
Um data mart contém um subconjunto dos
dados corporativos de interesse a um grupo específico de usuários. Este subconjunto
de dados pode ser extraído de um ou mais sistemas operacionais, podem ser dados
de origens externas à corporação, ou dados extraídos de um data warehouse
corporativo. A principal diferença entre um data warehouse corporativo e um data mart é o fato de que um data mart
contém uma porção dos dados corporativos e tem tendência à sumarização dos
dados, enquanto um data warehouse contém a visão geral
dos dados corporativos detalhados.
Vários data marts podem ser construídos a
partir de um data warehouse,
cada qual atendendo os requisitos por consultas e por desempenhoperformance
de um respectivo setor da corporação. Esta é a solução ou estratégia mais
defendida pelos teóricos a favor da normalização, que, promovendo a
flexibilidade de modelagem, proporciona uma melhor
manutenção evolutivação do projeto.
Outra opção seria a construção de modelos distintos de data marts
para cada setor de uma corporação, sem a existência de
uma modelagem global dos dados corporativos. Embora esta opção possa parecer mais
sedutora para muitos, é necessária extrema cautela para não produzir modelos
isolados e inconsistentes – o que geralmente acontece quando não se tem
inicialmente um modelo corporativo integrado e consolidado.
EsquemaModelo
em Estrela (Star Schema)
Um star schema ou esquema em estrela, é um modelo
relacional com uma “tabela de fato” e muitas “tabelas
de dimensão”. A tabela de fato contém uma ou várias colunas numéricas que medem
o desempenho de um dado aspecto do negócio tratado. Estas
colunas numéricas podem representar unidades vendidas, custo unitário, valor de
venda, horas trabalhadas, entre outros. Os fatos normalmente são numéricos, com
o objetivo de fornecer avaliações de desempenho de uma corporação com dados
agregados, obtidos através de médias, somas, máximos, mínimos e contadores.
As tabelas de dimensão descrevem os fatos. Sendo o fato o valor de venda de um produto, existiriam dimensões como: cliente, vendedor, produto, tempo, loja, entre outras.
A maioria das dimensões é hierárquica. Uma dimensão Tempo, por exemplo, pode ser agregada em diferentes níveis hierárquicos: em horas, dias, semanas, meses, trimestres e anos. A dimensão Produto pode ser agregada em departamento, categoria, subcategoria, etc., de acordo com os níveis de detalhamento de análise desejados.
Consultas ad-hoc
São consultas criadas pelos usuários do data warehouse.
São geralmente consultas feitas através de ferramentas que acessam diretamente
do banco de dados, expondo as suas tabelas. Como nem todas as consultadas são
previstas durante a concepção dos modelos em estrela, consultas ad-hoc
podem não apresentar bom desempenho em termos de tempo de execuçãoa
performance. Em geral Eessas consultaslas
podem
não terem
sidoforam
consideradas na otimização do modelo, assim não sendoforam criados objetos
como índices que as otimizeariam. Em uma consulta ad
hoc atributos de várias tabelas contendo grande número de
registros podem ser selecionados resultando numa operação de junção (em SQL,
conhecido como um join entre tabelas)
pesada e não otimizada sobre o banco de dados.
Nível
de Serviço
Em toda aplicação transacional existe um fator técnico crucial que define o desempenho esperado do sistema no ambiente operacional, em termos de tempo, este fator é chamado “nível de serviço”. Um exemplo de atendimento a determinado nível de serviço seria, por exemplo, garantir que uma determinada transação, como a venda de um produto, não poderia demorar mais do que um décimo de segundo. Ou ainda, garantir que a extração do saldo bancário de um correntista não poderia levar mais do que cinco segundos.
Dimensionalização (Dimensionalization)
Nome dado por Sean Kelly ao conceito de se projetar o data warehouse trabalhando-se com
tabelas de dimensão apenas na segunda forma normal. Desta forma atributos não
dependentes da chave primária serão armazenados na própria tabela, sem a
criação de uma nova tabela para acolhe-los. Assim, Ggrupos de
atributos que se aplicam a mais de um registro na tabela de dimensão
permanecerão na mesma tabela ocasionando redundância de dados(precisaria
detalhar mais esse conceito, estendendo este parágrafo).
O objetivo desta tática é eliminar o número de junções de
tabelas que seriam necessários para satisfazer consultas ad hoc em relação ao um modelo
normalizado, tornando assim o modelo mais apto pronto para
suportar tais consultas, embora menos normalizado.
Existe um consenso em se admitir uma certa tolerância sobre
a desnormalização das dimensões na construção de data marts. Assim o conceito de dimensionalização,
trata-se de estender esta idéia à
construção do data warehouse corporativo
com a justificativa de que nem todas as consultas poderiam ser previstas na
construção dos diversos data marts.
DIMENSIONALIZATION PARA NÍVEL DE SERVIÇO VERSUS A FLEXIBILIDADE DA NORMALIZAÇÃO
Em seu discurso no congresso citado, defendendo o uso de soluções prontas para a implantação de data warehouse:
“Quem optaria hoje por criar todo um
sistema de gestão financeira para uma corporação?”, Kelly contava com o
conhecimento da platéia sobre os produtos existentes voltados para gestão
empresarial. Como ninguém se manifestou, ele continuou: “Então o que os faz pensar que deveriam escrever um sistema de suporte
a decisões?”.
Kelly afirmou que era necessário repetir no ambiente de data warehouse o que empresas como a SAP e outras fizeram no mundo da gestão de processos empresariais. Ele foi um dos idealizadores e desenvolvedor do Industry Warehouse Studios (IWS), hoje comercializado pela Sybase. O IWS é uma das fortes soluções disponíveis no mercado com este objetivo. As principais características do produto apontadas pela Sybase e defendidas pela teoria de Sean Kelly são:
·
sSuporte a
consultas efetuadas diretamente no data warehouse sem a necessidade de
uma arquitetura em duas camadas com data marts construídos após o data warehouse;
·
uUso de um modelo
pré-definido de data warehouse reduzindo o tempo de
projeto com atributos empresariais e granularidade previamente projetados,
implementados e reutilizáveis;
·
Pprojeto
do modelo desenvolvido continuamente por especialistas e testado em diversas
corporações com o passar dos anos.
Kelly expõe o seguinte gráfico sobre o uso deste tipo de solução genérica, versus o desenvolvimento do data warehouse.
FIGURA 1 - Evolução em termos de tempo das consultas ao DW.
Nota-se que a disponibilização de consultas ad hoc ao data warehouse como ponto de partida da utilização da solução pré-definida é um dos pilares de sustentação da teoria definida por Kelly a favor de soluções prontas. Isto tornaria possível a quase imediata implantação da solução e possibilitaria o rápido retorno do investimento, criando a imagem de um projeto rapidamente bem-sucedido.
Porém,
pode-se argumentar que Aa representação da evolução no tempo dos
tipos de consultas tal
como exposta por S. Kelly, e retratada na figura anterior, não é
necessariamente correta: um procedimento deo
acompanhamento das consultas ad hoc realizadas, visando
rastreá-las parae
construir mecanismos para melhor disponibilizar e otimizar as novas informações
necessárias devepode ser realizado no ambiente com DW
próprio. Isto O que certamente reduziria
consideravelmente a inclinação da curva “dw próprio”. Este ganho é considerado,
sendo simplesmente parte da evolução natural da solução
corporativa com “dw próprio”.
Como a solução proposta por S. Kelly se sustenta em sua
rápida aceitação através daspelo ganho com as
consultas ad hoc, é necessário que as mesmas
tenham uma boa performance. Para suportar bem este tipo de consulta é proposto
um modelo com “dimensionalization”,
termo novo escolhido
pelo autor supostamente pela recusa em dizer explicitamente que as tabelas de
dimensão do data warehouse foram
desnormalizadas, comprometendo a consistência e a flexibilidade do modelo
corporativo.
Em uma
aplicação transacional existe um fator crucial que define a performance
esperada do
ambiente operacional – o chamado nível de serviço. Um exemplo disto
seria definir que
uma determinada transação como a venda de um produto não poderia demorar mais
do que um décimo de segundo, ou a
extração do saldo bancário de um correntista não poderia levar mais do que
cinco segundos.
Acordos determinando faixas para nível de serviço (ver definição na Seção 3.6) existem no ambiente transacional operacional, mas não deveriam necessariamente se aplicar ao ambiente de data warehouse, tendo em vista que este ambiente tem como principal objetivo atender consultas variáveis de qualquer setor da corporação.
Por
outro lado, poderia-se
argumentar que aA desnormalização do data warehouse
compromete a qualidade de seu modelo e introduz inconsistência nos dados.
Alterações no projeto, nos dados, nos requisitos de usuário ou no escopo do
projeto são prejudicados ao se optar por este caminho. Vários projetos têm
fracassado com o passar dos anos por estes motivos.
Em The Enterprise Data
Warehouse and Data Mart Debate, Nagraj Alur afirmadiz:
“Várias soluções de suporte a decisão estratégica como o Information Center da IBM focaram em disponibilizar consultas ad hoc
para usuários ou desenvolvedores ao invés de fornecer uma visão corporativa que
somente seria obtida através de um modelo apropriado e normalizado. Isto tem
levado a duplicação de esforços na implantação e evolução da solução dentro de
diversas corporações o que traz aumento de custos e inconsistência nas
informações”. O que inicialmente poderia ser vendido comoera um
projeto bem sucedido com rápido e elevado retorno de investimento, acaba por se
tornargerar
um ambiente inconsistente, com informações não confiáveis, com alto custo de
evolução ou mesmo incapaz de evoluir para acompanhar as necessidades da
corporação. Além
disso Éé freqüente um cenário resultante no qual
existe a necessidade de se duplicar os processos de extração de dados para
popular diversos modelos inconsistentes e isolados.
Um data warehouse
deve ter dados históricos, ser normalizado, sua granularidade deve ser adequada
para atender aos diferentes níveis de análise, e deve responder não apenas às
consultas numéricas, mas também às mais diferentes consultas textuais
possíveis. Esta flexibilidade somente será atingida com um modelo dotado de nível de
normalização adequado.
Para atender com performancedesempenho
adequadao às diversas consultas numéricas, onde
muitas vezes se impõe determinadoum nível
de serviço, Inmon recomenda a construção de data marts. Esta medida garante a
flexibilidade e preserva
a consistência do modelo corporativo assim como sua evolução com o passar
do tempo.
CONSIDERAÇÕES FINAIS
No atual contexto de acirrada concorrência e
competição global, oO processo de análise estratégica deve seré
algo passível deque
evoluçãoi
no tempo de forma
extremamente dinâmica. Tal processo não devendo, nunca
estacionar, ou ser consideradondo como
um projeto fechado e concluído. Em todos os ramos de atividade
existe uma contínua busca por eficiência, qualidade e lucratividade com uma
constante evolução dos requisitos corporativos aplicados sobre o data
warehouse.
A flexibilidade é um dos pilares fundamentais do data
warehouse
e somente será garantida através de um modelo corporativo adequado e
normalizado.
Quando se avalia a possibilidade
de optar pela aquisição
de modelos pré-definidos versus
optar pela análise e desenvolvimento de soluções corporativas alguns aspectos devem ser
considerados,
tais como: a flexibilidade, o tempo de análise e criação do modelo, o
tempo de implantação da solução, o custo total do projeto, o retorno do
investimento, entre outros aspectos. Não se deve dar ênfase ou descartar-se nenhum fatordesses aspectos
no momento da decisão.
Por
outro lado, Oo histórico da implementação de sistemas de
gestão empresarial pré-definidos prontos é vasto: existem ótimos exemplos de
sucesso e também retumbantes exemplos de fracasso. Muitas corporações se
adaptam bem e conseguem personalizar o modelo adquirido com sucesso, mas várias
outras vivem a experiência descrita como similar a de uma pessoa que “compra um chapéu como o primeiro passo para
depois verificar se ele se encaixa em sua própria cabeça” -– certamente o que é
necessário para tornar a cabeça de alguém compatível com determinado chapéu
poderá ser tão traumático quanto
as tarefas necessárias para tornar a cabeça de alguémos processos
decisórios de uma organização compatível com determinado chapéumodelo estratégico pré-definido. São
experiências que podem ser muitas vezes extremamente
dolorosas e traumáticas. Traumas semelhantes podem seresses sofridos
em iniciativas de implantação de soluções inadequadas para a análise
estratégica das
organizações.
À
guisa de conclusão pode-se afirmar que, Nna busca por
informações estratégicas, é necessário estar atento para não optar por soluções
que dizem ter a “bala de prata”. Aqui mesmo no Brasil existem vários
fornecedores de soluções de análise que se dizem implantadas em poucas semanas.
Estas soluções às
vezes mais
rápidas e “mais
baratas”não dificilmente têm podem garantir a
flexibilidade necessária e não realizarm
adequadamente as tarefas de limpeza e integração de dados necessários a
constituição de um bom modelo de data warehouse. Com tais solução oO
que se obtêm geralmente
no final é uma massa de dados inconsistente que por muitas vezes pode
acarretar em um erro de avaliação estratégica gerando perdas enormes a uma
corporação.
NOTAS
E REFERÊNCIAS BIBLIOGRÁFICAS
ALUR, N. The Enterprise Data Warehouse and Data Mart Debate [online] Disponível na Internet via WWW. URL: http://www.dbaint.com/pdf/v10n22.pdf. Arquivo consultado em junho de 2002.
DATE, C.
J. A Guide to THE SQL Standard, ADDISON-WESLEY, 1997
Inmon, W.
H. Building the data warehouse, John Wiley & Sons, Inc., New York, 1997
________. Hackthorn, D. Richard Using the Data
Warehouse, John Wiley & Sons, Inc., 1994
ROGERS, C. Intangible ROI Benefits Using Idustry Warehouse Studios [online] Disponível na Internet via WWW. URL: http://www.sybase.com/content/1008960/iws_wp_l01296.pdf. Arquivo consultado em junho de 2002.
WINSBERG, P. Modeling the Data Warehouse and Data Mart [online] Disponível na Internet via WWW. URL: http://www.evaltech.com/wpapers/dwmodel.pdf. Arquivo consultado em junho de 2002.