JOO ALEXANDRE BONIN DE MELLO

UMA PROPOSTA DE MODELO DE DADOS PARA SUPORTE AO PROCESSAMENTO TRANSACIONAL E DE APOIO INFORMACIONAL SIMULTANEAMENTE

Dissertao apresentada ao Programa de Ps-graduao em Engenharia de Produo da Universidade Federal de Santa Catarina como requisito parcial para obteno do grau de Mestre em Engenharia de Produo Orientador: Prof. Aran Bey Tcholakian Morales, Dr.

FLORIANPOLIS 2002

JOO ALEXANDRE BONIN DE MELLO

UMA PROPOSTA DE MODELO DE DADOS PARA SUPORTE AO PROCESSAMENTO TRANSACIONAL E DE DATA WAREHOUSE SIMULTANEAMENTE

Esta dissertao foi julgada aprovada para obteno de grau de Mestre em Engenharia de Produo no Programa de Ps-graduao em Engenharia de Produo da Universidade Federal de Santa Catarina

Florianpolis, 23 de maro de 2002.

____________________________ Prof. Ricardo Miranda Barcia, Ph.D. Coordenador do Programa

Banca Examinadora

Prof. Aran Bey Tcholakian Morales, Dr. Universidade Federal de Santa Catarina Orientador

Prof. Denilson Sell, Ms. Universidade Federal de Santa Catarina

Prof. Jos Leomar Todesco, Dr Universidade Federal de Santa Catarina

Prof. Oscar Ciro Lopez Vaca, Dr Universidade Federal de Santa Catarina

A minha esposa Lourdes. Aos meus filhos Victor e Murilo.

Agradecimentos Universidade Federal de Santa Catarina. Ao departamento de Engenharia de Produo e Sistemas Ao prof. Aran Bey Tcholakian Morales, pelo competente trabalho de orientao. Universidade Paranaense pelo apoio financeiro. Ao prof. Jos Leomar Todesco, prof. da disciplina de Data Warehouse, por ter despertado o interesse pelo tema. A Denilson Sell, pelas valiosas contribuies. Aos professores Srgio Rodrigues e Divair Maria Terna Gomes. Aos professores do programa de ps-graduao em Engenharia de Produo e Sistemas. A todos que contriburam, direta ou indiretamente, para a realizao desta pesquisa.

Resumo

MELLO, Joo Alexandre Bonin de. Uma proposta de modelo de dados para suporte ao processamento transacional e de data warehouse simultaneamente. 2001, 101f. Dissertao (Mestrado em Engenharia de Produo) Programa de Ps-graduao em engenharia de produo, UFSC, Florianpolis. Este trabalho prope um modelo de dados que permita o suporte ao processamento transacional e informacional simultaneamente. Este modelo voltado organizaes que no dispe de recursos para investimento em ambientes separados para aplicaes de processamento transacional e para aplicaes informacionais. No trabalho so descritos conceitos de sistemas de informao, sua classificao de acordo com a finalidade, o modelo entidade/relacionamento, o modelo dimensional e o data warehouse. A fim de se verificar a viabilidade do modelo proposto so construdos prottipos de sistemas baseados no modelo proposto, no modelo relacional e no modelo dimensional. Estes prottipos so comparados entre si de forma qualitativa e quantitativa. A anlise dos resultados dos testes demonstrou a viabilidade do modelo na situao testada, mostrando que o modelo proposto capaz de suportar tanto o processamento transacional quanto informacional e gerar uma reduo de custos pela unificao dos dois ambientes de dados (transacional e informacional) e pela eliminao da camada de data staging, necessria utilizao de data warehouses para o processamento informacional. Palavras-chave: Data Warehouse; Modelagem de Dados; Sistemas de Apoio Deciso.

Abstract

MELLO, Joo Alexandre Bonin de. Uma proposta de modelo de dados para suporte ao processamento transacional e de informacional simultaneamente. 2001, 101f. Dissertao (Mestrado em Engenharia de Produo) Programa de Ps-graduao em engenharia de produo, UFSC, Florianpolis. This paperwork has the purpose provide a data model that could support the transactional and informational process at the same time. This related to some organizations that dont have economical resources to invest ins separated environments to transactional and informational applications. In the paperwork are described concepts of information systems, it classification is according with this purpose, the entity relationship model, the dimensional model and data warehouse. In order to verify the viability of it was built some prototypes based on the model purposed, on the relational model and on the dimensional model. These prototypes are compared each other, qualitative and quantitative. The results analyzed from the tests showed the viability in that situation, proving that the sample is able to support as the transactional and informational processing and that it generates an expenses reduction through the unifying the both data environment (transactional and informational) and through the data staging elimination, necessary to the usage of data warehouse in the informational processing.

Keywords: Data Warehouse; Data Modeling; Decision Suport Systems.

vi

Sumrio
1. INTRODUO ......................................................................................................14 1.1 Apresentao ................................................................................................................ 14 1.2. Objetivos...................................................................................................................... 15 1.2.1. Objetivo Geral........................................................................................................ 15 1.2.2. Objetivos Especficos ............................................................................................. 15 1.3 Justificativa .................................................................................................................. 15 1.4 Estrutura do Trabalho ................................................................................................. 16 2. REVISO DA LITERATURA ................................................................................17 2.1 Introduo .................................................................................................................... 17 2.2 Sistemas de Informao ............................................................................................... 17 2.2.1 Classificao dos Sistemas de Informao ............................................................... 17 2.2.2 Sistemas de Processamento Transacional................................................................. 18 2.2.3 Sistemas de Informao Gerencial ........................................................................... 19 2.2.4 Sistemas de Apoio Deciso ................................................................................... 19 2.2.5 Sistemas de Informao Executiva........................................................................... 20 2.3 O Modelo Entidade/Relacionamento e os Sistemas Transacionais ............................ 21 2.3.1 Introduo ............................................................................................................... 21 2.3.2 Elementos do modelo entidade/relacionamento........................................................ 22 2.3.3 Conceitos Adicionais Respeito do Modelo Entidade/Relacionamento ................... 23 2.3.4 Consideraes Finais Respeito do Modelo Entidade/Relacionamento.................... 25 2.4 O Modelo Dimensional e o Data Warehouse............................................................... 26 2.4.1 Motivao ............................................................................................................... 26 2.4.1 Conceito .................................................................................................................. 27 2.4.2. Caractersticas de um Data Warehouse .................................................................. 28 2.4.3 Data Mart ................................................................................................................ 29 2.4.4. Arquitetura de um Data Warehouse ........................................................................ 29 vii

2.4.5 Abordagens de Implementao ................................................................................ 32 2.4.6. Estrutura de Custos de um Data Warehouse............................................................ 35 4.7 Modelagem Dimensional............................................................................................ 36 2.4.9 O modelo relacional versus Modelo Dimensional .................................................... 52 3 METODOLOGIA ....................................................................................................56 3.1 Introduo .................................................................................................................... 56 3.1 Caracterizao da Pesquisa ......................................................................................... 56 3.1.1 Problema de pesquisa .............................................................................................. 56 3.1.2 Hiptese de pesquisa ............................................................................................... 56 3.1.3 Etapas da pesquisa................................................................................................... 56 3.2 Apresentao e Anlise dos Resultados....................................................................... 57 4 O MODELO PROPOSTO.......................................................................................60 4.1 Introduo .................................................................................................................... 60 4.2. Descrio do Modelo ................................................................................................... 60 4.2. Estrutura de Custos do Modelo Hbrido .................................................................... 62 4.3. Desenvolvimento do Modelo ....................................................................................... 62 4.5. Suporte ao processamento transacional e ao data warehouse. .................................. 64 4.5.1. Baseado em assuntos .............................................................................................. 64 4.5.2. Integrado e no voltil ............................................................................................ 64 4.5.3. Varivel em relao ao tempo................................................................................. 69 4.5.4 Fornecer dados de apoio s decises gerenciais ....................................................... 69 4.6. Consideraes finais a respeito do modelo proposto.................................................. 69 5 APRESENTAO E ANLISE DOS RESULTADOS ...........................................71 5.1 Introduo .................................................................................................................... 71

viii

5.2 Descrio dos prottipos .............................................................................................. 71 5.3 Performance no processamento transacional.............................................................. 72 5.4 Performance na extrao de informaes ................................................................... 74 5.5 Redundncia de dados ................................................................................................. 75 5.6 Complexidade do cdigo-fonte da aplicao ............................................................... 76 5.7 Tamanho do Cdigo-Fonte .......................................................................................... 76 5.8 Tamanho da base de dados .......................................................................................... 77 5.9 Complexidade das consultas SQL................................................................................ 78 5.10 Consideraes finais a respeito dos resultados obtidos............................................. 78 6. CONCLUSO E ESTUDOS FUTUROS ...............................................................81 6.1 Concluso ..................................................................................................................... 81 6.2 Estudos futuros............................................................................................................. 82 7 FONTES BIBLIOGRFICAS .................................................................................83 ANEXO A SCRIPTS PARA CRIAO DO PROTOTIPO RELACIONAL .............85 ANEXO B - SCRIPTS PARA CRIAO DO PROTTIPO EM ESTRELA ..............90 ANEXO C - SCRIPTS PARA CRIAO DO PROTTIPO HBRIDO ......................93 ANEXO D SCRIPTS DE CARGA DOS CUBOS DE DECISO.............................99

ix

Lista de Figuras
FIGURA 1 - RELACIONAMENTO ENTRE ENTIDADES..........................................23 FIGURA 2 - ENTIDADE FORTE E ENTIDADE FRACA ...........................................24 FIGURA 3 - GENERALIZAO E ESPECIALIZAO ...........................................25 FIGURA 4 - UMA ARQUITETURA MULTICAMADAS PARA O DATA WAREHOUSE...........................................................................................................31 FIGURA 5 - ABORDAGEM TOP DOWN ..................................................................33 FIGURA 6 - ABORDAGEM BOTTOM UP ................................................................34 FIGURA 7 - A ARQUITETURA BUS ........................................................................35 FIGURA 8 - O CUBO DE DECISO .........................................................................38 FIGURA 9 - DRILL DOWN E ROLL UP....................................................................39 FIGURA 10 - SLICE ..................................................................................................40 FIGURA 11 - DICE ....................................................................................................40 FIGURA 12 - TABELA DE FATOS SEM FATOS .....................................................44 FIGURA 13 - HIERARQUIAS NA DIMENSO TEMPO ...........................................45 FIGURA 15 - RELACIONAMENTO MUITOS PARA MUITOS .................................49 FIGURA 16 - SNOWFLAKE DO TIPO PESQUISA ..................................................52 FIGURA 17 - SNOWFLAKE EM CADEIA ................................................................52

FIGURA 18 - SNOWFLAKE DO TIPO ATRIBUTO ..................................................53 QUADRO 1 - OLTP VERSUS DATA WAREHOUSE ...............................................54 FIGURA 19 - COMPLEXIDADE CICLOMTICA......................................................58 FIGURA 20 - UMA ARQUITETURA EM CAMADAS UTILIZANDO O MODELO HBRIDO ...................................................................................................................61 FIGURA 21 - MODELO SNOWFLAKE EM CADEIA................................................62 FIGURA 22 - MODELO HBRIDO PROPOSTO .......................................................63 FIGURA 23- UM MODELO SNOWFLAKE EM CADEIA ..........................................65 FIGURA 24 - O MODELO PROPOSTO....................................................................66 FIGURA 25 - ALTERAO DA RENDA MENSAL DE UM CLIENTE .....................67 FIGURA 26 - ALTERAO DE UM REGISTRO DE VENDA ..................................68 QUADRO 2 - CARACTERSTICAS CONCEITUAIS DO MODELO PROPOSTO EM RELAO AO DIMENSIONAL E AO RELACIONAL ..............................................70 FIGURA 27 - O PROTTIPO COM O MODELO PROPOSTO.................................73 FIGURA 28 - O PROTTIPO RELACIONAL ...........................................................74 FIGURA 29 - O PROTTIPO COM O ESQUEMA ESTRELA..................................75 QUADRO 3 - RESULTADO DA AVALIAO DOS PROTTIPOS ........................79

xi

Lista de Quadros
QUADRO 1 - OLTP VERSUS DATA WAREHOUSE ................................................54 QUADRO 2 - CARACTERSTICAS CONCEITUAIS DO MODELO PROPOSTO EM RELAO AO DIMENSIONAL E AO RELACIONAL ................................................70 QUADRO 3 - RESULTADO DA AVALIAO DOS PROTTIPOS ..........................79

xii

Lista de redues
DBMS Database Management System. Sistema de gerenciamento de bancos de dados. EIS Executive executiva OLTP On-line transaction processing. Sistemas de processamento de transaes. SAD SGBD SIG SPT Sistema de apoio deciso Sistema de gerenciamento de banco de dados Sistema de Informao gerencial Sistema de processamento transacional Information System. Sistema de Informao

xiii

14

1. INTRODUO 1.1 Apresentao

O modelo entidade/relacionamento trouxe agilidade, exatido e economia de espao de armazenamento de dados para os sistemas de processamento transacional. Esta tcnica, entretanto, revelou-se ineficiente para a implementao de sistemas informacionais, tais como de apoio deciso e sistemas de informao executiva que necessitem de grandes bases de dados. Isso ocorre devido ao grande nmero de junes entre tabelas necessrias construo de consultas mais complexas, o que degrada a performance do sistema, e complexidade do modelo para usurios finais (geralmente tomadores de deciso) que constroem suas prprias consultas utilizando-se de ferramentas apropriadas. Esta deficincia foi suprida com a utilizao de data warehouses baseados no modelo dimensional. Este modelo viabilizou a utilizao o processo de descoberta do conhecimento em grandes bases de dados. O modelo dimensional proporciona uma forma simples e eficiente de armazenamento de grandes volumes de dados para alimentao de sistemas de apoio deciso. Este modelo, entretanto, no se prope a automatizar o processamento transacional das organizaes. A utilizao do modelo entidade/relacionamento para os sistemas transacionais e do modelo dimensional para o data warehouse, destinado a suportar os sistemas informacionais, implica em duplicar a infra-estrutura de processamento de sistemas de informao, uma vez que so necessrios dois ambientes de armazenamento de dados e estes precisam ser migrados periodicamente do ambiente transacional para o data warehouse, atravs de processos de extrao, transformao e limpeza de dados. Este processo envolve custos, tornando proibitiva a sua utilizao por aquela poro das organizaes que no dispe de recursos suficientes para realizar tais investimentos. O presente trabalho prope a utilizao de um modelo de dados que possa unir as caractersticas do modelo entidade/relacionamento s caractersticas do modelo dimensional, possibilitando que as empresas retirem suas informaes estratgicas diretamente do banco de dados operacional.

15

1.2. Objetivos 1.2.1. Objetivo Geral

Investigar a viabilidade da modelagem de dados utilizando um modelo que possa unir as caractersticas do modelo dimensional s do modelo entidade/relacionamento, criando um modelo que suporte o processamento transacional e informacional.

1.2.2. Objetivos Especficos

Estudar detalhadamente as tcnicas de modelagem de dados baseadas nos modelos entidade/relacionamento e dimensional, enumerando as vantagens, desvantagens e aplicabilidade da cada um. Propor um modelo de dados que possibilite extrair informaes estratgicas, de modo eficiente, diretamente do banco de dados transacional. Validar a aplicabilidade deste modelo atravs do desenvolvimento de prottipos.

1.3 Justificativa
Em um ambiente globalizado, cada vez mais as empresas necessitam de informaes para reagir aos problemas e oportunidades de negcio que surgem no horizonte (LAUDON e LAUDON, 1999), independentemente da rea de negcio ou do porte das mesmas. Para HARRISON (1998, p 3) aumentar o capital intelectual das empresas uma necessidade competitiva (...). As organizaes que usam com eficcia a tecnologia de informaes adquirem conhecimento e velocidade para alcanar uma esmagadora superioridade nos mercados em que atuam. Os custos gerados pela duplicao dos ambientes de dados, um para o processamento transacional e outro para a extrao de informaes gerenciais, impossibilita uma grande quantidade de pequenas e mdias empresas de se beneficiar de sistemas de apoio informacional, suportados por data warehouses. O modelo de dados proposto neste trabalho oferece uma tecnologia de baixo custo

16

para a criao de modelos de dados para as organizaes de pequeno porte, que no dispem de recursos para investir em dois ambientes de dados, um para os sistemas de apoio deciso e de informaes gerenciais e outro para processamento de transaes. O modelo proposto pressupe a utilizao de um nico ambiente de dados, unindo caractersticas do modelo entidade-relacionamento ao modelo relacional, possibilitando o processamento de transaes e a extrao de informaes de apoio deciso de uma nica base de dados, capaz de suportar aplicaes de organizaes de pequeno porte, que no necessitam de grandes volumes de informao e no dispe de recursos para a duplicao de ambientes.

1.4 Estrutura do Trabalho

A dissertao est dividida em cinco partes. A primeira trata do referencial terico necessrio para a proposta do modelo hbrido de dados. Nesta parte estudada a classificao dos sistemas de informao segundo sua finalidade, o modelo entidade/relacionamento, o modelo dimensional como tcnicas para modelagem de sistemas transacionais e de apoio informacional. A segunda expe a metodologia adotada para a execuo do trabalho. Na terceira parte proposto um modelo de dados que possibilite extrair informaes estratgicas diretamente da base de dados transacional. A quarta parte apresenta os prottipos desenvolvidos e a anlise dos resultados dos testes efetuados. Finalmente so tecidas as concluses a respeito do trabalho e recomendados estudos mais aprofundados.

17

2. REVISO DA LITERATURA 2.1 Introduo

Este captulo traa um perfil dos sistemas de informao, classificando-os de acordo com sua finalidade. Uma nfase especial dada aos sistemas de processamento de transao e ao modelo entidade/relacionamento, destinado a suport-lo, ao ambiente de data warehouse e ao modelo dimensional. Dado o objetivo principal deste trabalho, que propor um modelo de dados capaz de suportar aplicaes de processamento transacional e informacional, as tcnicas de modelagem de dados, tanto para o modelo entidade/relacionamento quanto para o modelo dimensional so discutidas em detalhe, a fim de subsidiar o modelo proposto.

2.2 Sistemas de Informao

Um sistema de informaes composto de um conjunto interdependente de pessoas, estruturas organizacionais, software, hardware, processos e mtodos interligados com o objetivo de facilitar o planejamento e o controle em empresas e outras organizaes, organizando informaes de forma que estas se tornem utilizveis na coordenao do fluxo de trabalho de uma empresa. (LAUDON e LAUDON, 1998). Um sistema de informaes tem a funo de coletar, manipular, armazenar e disseminar dados e informaes pela empresa (STAIR, 1998). Os sistemas de informao transformam a informao em uma forma utilizvel, contendo informao a respeito do ambiente interno e externo da organizao, ajudando os membros da mesma a tomar decises, possibilitando mltiplas anlises e visualizaes de informaes a respeito de situaes complexas (LAUDON e LAUDON, 1998).

2.2.1 Classificao dos Sistemas de Informao

Os sistemas de informao podem ser classificados de acordo com sua finalidade. Estes podem ser classificados em sistemas de processamento transacional, sistemas de informaes gerenciais, sistemas de apoio deciso, sistemas especialistas e sistemas de informao executiva (FREITAS e

18

POZZEBOM, 2000 e FURLAN, 1994, STAIR, 1998, FALSARELLA e CHAVES, 2001). BOAR (2001), classifica os sistemas de informao em dois grandes grupos: os aplicativos do negcio e os aplicativos que analisam informaes a respeito do negcio. O primeiro grupo corresponde quelas aplicaes que processam as transaes dirias da organizao, os sistemas de processamento transacional. Para este tipo de aplicao, integridade e performance a nvel transacional e disponibilidade so requisitos imperativos. O segundo grupo so as aplicaes que analisam informaes a respeito do negcio, os sistemas informacionais. Estas aplicaes se caracterizam por bases de dados estticas ou de modificaes lentas, armazenamento de dados por um longo perodo de tempo e facilidade e performance no processo de extrao de informaes. Os sistemas de processamento transacional esto enquadrados no primeiro grupo de aplicaes, enquanto que os sistemas de informao gerencial, sistemas de suporte deciso e sistemas de informao executiva se encaixam no segundo grupo. Neste trabalho sero apresentadas as definies para sistemas de

processamento transacional, sistemas de informao gerencial, sistemas de apoio deciso e sistemas de informao executiva.

2.2.2 Sistemas de Processamento Transacional

Os sistemas de processamento transacional (SPT), atualmente chamados de OLTP (On-line transaction processing) (KIMBALL, 1998a), foram os primeiros aplicativos de computador a serem desenvolvidos na maioria das organizaes. Eles tm a tarefa de monitorar e processar as funes bsicas e rotineiras de uma organizao, tais como processamento da folha de pagamento, faturamento etc. (STAIR, 1998, LAUDON e LAUDON, 1998). Estes sistemas possuem algumas caractersticas prprias, tais como computao simples, grandes volumes de dados de entrada e sada, alto grau de repetio (LAUDON e LAUDON, 1998, STAIR, 1998), disponibilidade necessria em 100% do tempo de funcionamento da organizao, altas taxas de performance no processamento de transaes e grande complexidade no esquema conceitual da

19

base de dados, devido ao grande nmero de entidades e relacionamentos (BOAR, 2001). Como os sistemas de processamento transacional operam as tarefas bsicas e rotineiras da organizao e o relacionamento com fornecedores, clientes e governo, os fatores crticos de sucesso para este tipo de sistema so: alto grau de preciso, integridade a nvel transacional e produo de documentos em tempo hbil (STAIR, 1998, KIMBAL, 1998). Sistemas de processamento transacional podem ser utilizados para a obteno de vantagem competitiva, isto pode ser obtido utilizando-se este tipo de sistema para oferecer servios e produtos de qualidade superior aos clientes, melhor agrupamento de informaes e aperfeioamento do processo de planejamento (STAIR, 1998).

2.2.3 Sistemas de Informao Gerencial

Um sistema de informaes gerenciais (SIG) tem o propsito de fornecer informaes necessrias medio da eficincia operacional da organizao, dando nfase s necessidades gerenciais atravs de informaes resumidas, obtidas a partir da filtragem e anlise de dados altamente detalhados, extrados das bases de dados dos sistemas de processamento transacionais e de fontes externas (STAIR, 1998, FALSARELLA e CHAVES, 2001).

2.2.4 Sistemas de Apoio Deciso

Um sistema de apoio deciso (SAD) tem por finalidade dar embasamento tomada de decises referentes a problemas especficos. Este tipo de sistema geralmente utilizado quando a tomada de deciso se torna difcil sem o apoio de um sistema que fornea informaes especficas que possam dar o devido suporte tomada de deciso. Um SAD deve reconhecer que existem estilos gerenciais diferentes e tipos de decises diferentes. Isso implica em uma grande participao do usurio do SAD no seu desenvolvimento (STAIR, 1998; SPRAGHE e WATSON, 1991).

20

De acordo com STAIR (1998) um SAD deve ser capaz de manipular grandes volumes de dados, obter e processar informaes de diferentes fontes, proporcionar flexibilidade de relatrios e apresentao, possuir orientao tanto textual quanto grfica e executar anlises e comparaes complexas e sofisticadas. Adicionalmente, um SAD pode tambm tem a capacidade de encontrar solues para problemas menores atravs de abordagens de otimizao e heursticas e ainda executar anlises de atendimento de metas (STAIR, 1988).

2.2.5 Sistemas de Informao Executiva

Os sistemas de informao executiva (executive information systems EIS) oferecem um meio prtico para que executivos acessem informaes estratgicas da empresa de um modo agrupado e simplificado de acordo com suas necessidades, ajustadas ao seu estilo de trabalho (FURLAN, IVO e AMARAL, 1994). Um EIS um tipo especial de SAD destinado tomada de decises de alto nvel da organizao, oferecendo informaes estruturadas, tanto internas quanto externas a respeito de aspectos da organizao considerados fatores crticos de sucesso para a mesma (FALSARELLA e CHAVES, 2001, STAIR, 1988). Enquanto um SAD oferece apoio para decises focadas em uma rea especfica, geralmente oferecendo suporte mdia e baixa gerncia, um EIS oferece informaes consolidadas de alto nvel e anlises multidimensionais a executivos de alto nvel (GUPTA, 2001). FALSARELLA e CHAVES (2001) acrescentam ainda que um EIS deve fornecer tambm informaes detalhadas a respeito do passado, presente e perspectivas futuras a fim de auxiliar o processo de planejamento e controle da organizao, permitindo aos seus usurios navegar por diversos nveis de detalhamento da informao. O sucesso de um EIS depende no s da disponibilidade das informaes necessrias ao processo decisrio, como tambm a forma de extrao e explorao destas informaes utilizadas no momento da tomada de deciso, uma vez que diferentes tomadores de deciso necessitam de diferentes informaes e possuem estilos decisrios diferentes (FREITAS e POZZEBOM, 2000).

21

STAIR (1998) resume algumas caractersticas importantes para um Sistema de Informaes Executivas. Estas caractersticas so: facilidade de uso, manipulao de dados externos e internos, quantitativos e qualitativos, execuo de sofisticadas anlises de dados, alto grau de especializao, flexibilidade e suporte a todos os aspectos da tomada de decises (uma vez que decises que utilizam fontes externas de informaes podem ter um alto grau de incerteza). Um EIS tambm deve oferecer recursos abrangentes de comunicao, uma vez que executivos necessitam de comunicao instantnea com o ambiente interno e externo da organizao. FREITAS e POZZEBOM (2000) defendem uma mudana do foco dos sistemas de informaes executivas para sistemas de informao empresarial, onde os tomadores de deciso de todos os nveis possam se beneficiar da oferta de informaes. VOLOLINO, WATSON e ROBINSON apud FREITAS e POZZEBON (2000) definem EIS como uma tecnologia de informao para todos os usurios finais da organizao, sendo os executivos um subconjunto destes usurios, onde o suporte ajustado de acordo com as necessidades de cada classe de usurios.

2.3

Modelo

Entidade/Relacionamento

os

Sistemas

Transacionais 2.3.1 Introduo

Sistemas OLTP processam uma grande quantidade de transaes diariamente. Consistncia transacional e velocidade so requisitos imperativos neste tipo de sistema. Eles operam as atividades essenciais de uma organizao (KIMBALL, 1998a). O modelo entidade/relacionamento se aplica perfeitamente a este tipo de sistema, pois divide os dados em vrias entidades distintas, cada uma implementada em uma tabela no banco de dados (KIMBALL, 1998a). Neste tipo de modelo, as informaes so vistas sob a perspectiva de transaes atmicas (SINGH, 2001). Tcnicas de normalizao eliminam completamente a redundncia de dados, reduzindo significativamente a probabilidade de inconsistncia e aumentando a velocidade de processamento transacional, uma vez que as atualizaes do banco de dados a cada transao se resumem a uma pequena quantidade de registros por vez (KIMBALL, 1998a).

22

Este modelo foi proposto primeiramente por Peter Chen em 1976 e a partir da foi aprimorado por ele mesmo e por outros. Este modelo foi adotado por vrias ferramentas CASE, que tambm o modificaram. Atualmente no existe um padro unificado para este modelo. O que existe um conjunto de conceitos universalmente aceitos, dos quais se originam a maioria das variaes de modelo entidade/relacionamento (KROENKE, 1999).

2.3.2 Elementos do modelo entidade/relacionamento

Os principais elementos do modelo entidade/relacionamento so entidades, atributos, identificadores e relacionamentos (KROENKE, 1999):

a) Entidades
Entidade algo que pode ser identificado no ambiente de trabalho do usurio, algo que o mesmo queira localizar (KROENKE, 1999). Entidades representam classes de objetos do mundo real que podem ser observadas e classificadas segundo suas propriedades (BALLARD et al. 2001). Entidades podem ser definidas como qualquer objeto distinguvel em um banco de dados (DATE, 2000). Entidades de um mesmo tipo so agrupadas em classes de entidade. Uma ocorrncia de uma entidade chamada de instncia de entidade. Assim, o conjunto formado por todos os funcionrios de uma organizao forma a classe de entidades FUNCIONRIO (KROENKE, 1999).

b) Atributos
Atributos descrevem caractersticas das entidades. Estes atributos tambm so chamados de propriedades. O nome do funcionrio um atributo da entidade FUNCIONRIO. De acordo com a definio do modelo entidade/relacionamento, todas as instncias de uma mesma classe de entidade possuem os mesmos atributos (KROENKE, 1999).

c) Identificadores
Identificadores so atributos que identificam uma determinada instncia de entidade. Identificadores podem ser nicos ou no nicos, se forem nicos

23

identificaro uma, e somente uma instncia de entidade. Se for no nico identificar um conjunto de instncias de entidade (KROENKE, 1999).

d) Relacionamentos
Relacionamentos descrevem a interao estrutural e a associao entre as entidades de um modelo permite (BALLARD et al. ente 2001). instncias O de modelo entidade entidade/relacionamento associaes

(relacionamentos entre instncias) e associaes entre classes de entidade (relacionamentos entre classes). Relacionamentos podem possuir atributos prprios. Um atributo de relacionamento um tipo de atributo que s existe se houver um relacionamento entre entidades (KROENKE, 1999). A Figura 1 ilustra um relacionamento entre as entidades VENDEDOR e PEDIDO. Figura 1 - Relacionamento entre entidades

Vendedor

Efetua

Pedido

Fonte: Adaptado de KROENKE, D. Banco de Dados: Fundamentos, projeto e implementao. Rio de Janeiro: Livros Tcnicos e Cientficos, 1999.

2.3.3

Conceitos

Adicionais

Respeito

do

Modelo

Entidade/Relacionamento
Alguns conceitos adicionais so importantes para a compreenso do modelo entidade/relacionamento: entidades fracas, generalizao e especializao. Estes conceitos sero discutidos a seguir. O modelo entidade/relacionamento define um tipo especial de entidade chamado de entidade fraca (Figura 2). A caracterizao de uma entidade fraca se d atravs da anlise de duas caractersticas (COUGO, 1997, KROENKE, 1999): a) dependncia de existncia; b) dependncia de identificador

24

A dependncia de existncia se d quando a existncia de uma entidade A s possvel se existir uma entidade B. Dizemos ento que B uma entidade forte e A uma entidade fraca, enquanto que a dependncia de identificador se d quando o atributo identificador da entidade fraca inclui o atributo identificador da entidade forte qual o mesmo est relacionado (COUGO, 1997, KROENKE, 1999). Um relacionamento entre uma entidade forte e uma fraca sempre um relacionamento de um para muitos (DATE, 2000). Estes critrios podem ser dispensados do ponto de vista conceitual, sendo importantes no projeto lgico, onde os atributos identificadores passam a ter papel importante no endereamento de uma instncia de entidade (COUGO, 1997). Figura 2 - Entidade forte e entidade fraca
1 Funcionrio Possui n Dependente

Fonte: Adaptado de KROENKE, D. Banco de Dados: Fundamentos, Projeto e Implementao. 6a ed. Rio de Janeiro: Livros Tcnicos e Cientficos, 1999.

Quando so encontradas entidades que possuem um conjunto de atributos comum para descrev-las, podemos generaliz-las em uma nica entidade. A este processo chama-se generalizao. De outro modo, quando encontramos um grupo de atributos que no so comuns ao grupo de entidades, podemos criar diversas entidades especializadas para conter estes atributos. Este processo chamado de especializao (MACHADO, 1996). A uma entidade generalizada, d-se o nome de supertipo de entidade, enquanto que a uma especializao de entidade d se o nome de subtipo de entidade (DATE, 2000, KROENKE, 1999). A Figura 3 ilustra uma estrutura de generalizao e especializao. A derivao de uma estrutura conceitual de generalizao e especializao no nos levar diretamente ao modelo lgico. Caso todos os atributos sejam comuns, pode-se optar por implementar todas as entidades em uma nica entidade generalizada, acrescentando-se um atributo identificador. No extremo oposto, podem existir atributos que sejam especficos de cada uma das entidades especializadas. Na Figura 3, apenas a entidade PESSOA, possui os atributos Nome e Endereo, entretanto apenas a entidade INDIVDUO possui os atributos Documento de Identidade e CPF e apenas a entidade ORGANIZAO possui o atributo CNPJ,

25

neste caso, para evitar atributos com valores nulos, aconselhvel implementar cada entidade em uma tabela lgica separada. Existem casos em que se pode adotar uma soluo combinada, adotando-se as duas solues ao mesmo tempo (COUGO, 1997). Figura 3 - Generalizao e Especializao
Pessoa

Indivduo

Organizao

2.3.4

Consideraes

Finais

Respeito

do

Modelo

Entidade/Relacionamento
O modelo entidade/relacionamento destinado ao processamento de transaes. Tcnicas de normalizao eliminam completamente a redundncia de dados (KROENKE, 1999, DATE, 2000), reduzindo significativamente a probabilidade de inconsistncia e aumentando a velocidade de processamento transacional, uma vez que as atualizaes do banco de dados a cada transao se resumem a uma pequena quantidade de registros por vez (KIMBALL, 1998a). O modelo relacional tem sido utilizado como ferramenta de modelagem de dados, por fornecer uma viso dos requisitos de negcio e por servir de base para a implementao da estrutura de dados resultante (BALLARD et al. 2001). Apesar do modelo entidade/relacionamento se adaptar perfeitamente ao processamento de transaes, este modelo mostrou-se ineficiente para o processamento de sistemas de apoio deciso (KIMBALL, 1998a). Um diagrama entidade/relacionamento bastante simtrico, no sendo possvel a percepo de quais entidades so mais importantes e quais possuem atributos

26

numricos que registram as medies de fatos.

Freqentemente, os diagramas

possuem muitas entidades, tornando seu entendimento bastante difcil, tanto por parte de profissionais de desenvolvimento de aplicativos quanto por usurios finais. Esta dificuldade no entendimento do modelo informacional que o diagrama representa. Isso acaba por dificultar a construo de consultas personalizadas por parte dos usurios finais (KIMBALL, 1998a). Modelos processamento entidade/relacionamento, transacional so apesar de como serem base eficientes para para

desastrosos

aplicaes

informacionais, porque so difceis de serem entendidos pelo usurio final nem podem ser navegados de forma til pelo gerenciador de bancos de dados (KIMBALL, 1998a).

2.4 O Modelo Dimensional e o Data Warehouse 2.4.1 Motivao

A origem do conceito de data warehouse remonta ao incio dos anos 80, quando os bancos de dados relacionais tornaram-se produtos comerciais. As facilidades de extrao de dados proporcionadas pela linguagem SQL proporcionaram um aumento do interesse por ferramentas de extrao de dados direcionadas ao usurio final. Desde aquele momento, houve uma preocupao com o impacto que estas consultas causavam na performance do banco de dados dos sistemas OLTP, o que forou a utilizao de bases de dados separadas, contendo instantneos utilizados exclusivamente para o processamento de consultas e para os sistemas de suporte deciso (BALLARD et al. 2001). Desde aquela poca ficaram claras as diferenas entre as necessidades dos sistemas OLTP e dos SAD e EIS. Enquanto os sistemas OLTP necessitam de performance e exatido a nvel transacional, os SAD e EIS necessitam de performance na extrao de dados e uma grande flexibilidade nos tipos de consulta efetuados (GUPTA, 2001). Por outro lado, o aumento da capacidade dos sistemas OLTP de coletar, processar e armazenar dados ultrapassou em muito nossa capacidade de extrair conhecimento dos mesmos (SINGH, 2001), enquanto isso, o processo de

27

reestruturao das organizaes e a rapidez nas mudanas ambientais causada pela globalizao da economia, aumentaram a necessidade de respostas para uma srie de questes que afetam diretamente a forma como as pessoas conduzem seus negcios (GUPTA, 2001). Estes fatores, aliados ao aumento de poder de processamento dos computadores pessoais e dos sistemas operacionais para servidores, tais como o Windows NT e as vrias verses de Unix, a evoluo dos SGBDs e das ferramentas de consulta, geraram um ambiente propcio para a evoluo da solues baseadas em data warehouse (GUPTA, 2001).

2.4.1 Conceito
Um data warehouse o ponto central da arquitetura de processamento de informaes estratgicas para tomada de decises (KIMBALL, 1998a), fornecendo o suporte informacional para os sistemas de apoio deciso (SAD) e para os sistemas de informao executiva (EIS). O data warehouse construdo separadamente da base de dados dos sistemas OLTP sob uma perspectiva de armazenamento de informaes de longo prazo. Sua base de dados orientada por assunto, consolidada, integrada, varivel com o tempo e no voltil (INMON, 1997), fornecendo informaes precisas, completas e apoiando as necessidades de informao do usurio a fim de lidar com aspectos estratgicos de longo prazo (HARRISON, 1998), constituindo uma tecnologia de gesto e anlise de dados (SINGH, 2001). O data warehouse deve ser capaz de gerar rapidamente pequenos conjuntos de resposta baseados em uma infinidade de registros. Usurios de um data warehouse alteram constantemente o tipo de consulta efetuada, dependendo de suas necessidades. Estas consultas podem utilizar-se de centenas ou milhes de registros, causando impacto varivel na performance do banco de dados (KIMBALL, 1998a). Para BOAR (2001), o data warehouse oferece uma viso estratgica do negcio, orientada dimenso temporal, possibilitando o aprendizado com o passado, permitindo analisar o presente de forma a realizar adaptaes em tempo real e

28

possibilitando traar o futuro atravs do conhecimento antecipado das condies ambientais.

2.4.2. Caractersticas de um Data Warehouse

A definio de INMON (1997), ressalta as caractersticas principais de um data warehouse. MACHADO (2000), DOMENICO (2001) e SELL (2001), discutem estas caractersticas detalhadamente:

a) Orientao por Assunto

Orientao por assunto significa que os data warehouses agrupam as informaes por rea de interesse da organizao, em contrapartida aos sistemas de processamento transacionais, que so orientados por processos.

b) Variao no Tempo
Os data warehouses representam os resultados operacionais em um

determinado momento de tempo, isto significa que os dados de um data warehouse no podem sofrer alterao.

c) No Volatilidade
Um data warehouse possui duas operaes bsicas: carga de dados e acesso aos mesmos. Estes dados se originam dos sistemas transacionais, so transformados e purificados e em seguida carregados no data warehouse. Estes dados permanecem l at que se decida que eles no sero mais necessrios.

d) Integrao
Os dados de um data warehouse possuem um alto nvel de integrao, isto significa que inconsistncias devem ser eliminadas e que as convenes de nomes de atributo, tais como sexo, estado civil, assim como os tipos de dados so formalmente unificados, definindo assim uma apresentao nica para os dados do data warehouse, eliminando-se as possibilidades de respostas ambguas.

29

2.4.3 Data Mart

Para INMON (1997), um data mart pode ser definido como um SGBD multidimensional que fornece uma estrutura bastante flexvel de acesso dados. Enquanto o data warehouse extrai, transforma e limpa os dados dos sistemas transacionais, mantendo-os integrados em quantidades massivas e em seu nvel mais baixo, o data mart se serve destes dados, extraindo dados para um departamento ou uma rea de negcio, oferecendo flexibilidade e controle ao usurio final, pois com o data mart possvel fatiar e agrupar dados de diversas maneiras. Para KIMBALL et al. (1998b), data mart um subconjunto do data warehouse, direcionado a um departamento ou rea de negcio. Para o autor, o conjunto de todos os data marts da organizao, construdos de forma incremental, compartilhando dimenses e fatos comuns, segundo um planejamento prvio, formam o data warehouse lgico da organizao.

2.4.4. Arquitetura de um Data Warehouse

A arquitetura de um data warehouse pode ser definida como a forma de representar toda a estrutura do ambiente de dados, comunicao, processamento e apresentao disponvel para o usurio na empresa (SINGH, 2001, p. 80). SINGH (2000) prope um modelo arquitetnico multicamadas para o data warehouse. Estas camadas esto representadas pela Figura 4 a seguir.

a) Camada de Acesso Informao.

a camada atravs da qual o usurio tem acesso s informaes do data warehouse atravs de relatrios, planilhas e grficos para anlise e apresentao atravs de softwares como planilhas eletrnicas e bancos de dados desktop e ferramentas especficas para anlise dimensional e minerao de dados, que permitem que o usurio final manipule as informaes do data warehouse de forma flexvel. Esta camada representada tambm pelo hardware de acesso a informaes manipuladas.

30

b) Camada de Acesso a Dados

A camada de acesso a dados responsvel por fazer a conexo entre a camada de dados operacionais e a camada de data staging e tambm pela camada de data warehouse e a camada de acesso informao, fazendo uso extensivo da linguagem SQL. A utilizao de drivers apropriados permite o acesso a praticamente qualquer SGBDs e arquivos de dados, facilitando assim o processo de extrao de informaes dos sistemas de processamento transacionais. Esta camada composta por diferentes SGBDS, hardware, sistema operacional e protocolos de rede, a fim de proporcionar acesso transparente, independentemente da localizao e da plataforma do usurio.

c) Camada de Diretrio de Dados (Metadados)

Metadados so os dados que descrevem os dados armazenados. Esta camada permite que o usurio do data warehouse acesse seus dados de forma nica, sem que seja necessrio saber onde eles esto e em que formato esto armazenados. Segundo BRACKET, apud SELL (2001), existem basicamente dois tipos de metadados: os metadados tcnicos, utilizado pelo corpo tcnico (DBAs e desenvolvedores) para manuteno do data warehouse, e os metadados de negcio, utilizado pelos usurios finais, que fornecem uma descrio do negcio, regras e clculos de formao dos dados e outros itens que auxiliem na interpretao dos dados e informaes sobre freqncia de atualizao dos mesmos. Um problema com os metadados a padronizao dos mesmos. Existem diversos fornecedores de solues de data warehouse, cada um com sua arquitetura proprietria, o que obriga os profissionais do corpo tcnico a manter uma documentao prpria, a fim de gerenciar o data warehouse e fornecer os metadados de negcio de forma padronizada ao usurio final (KIMBALL, 1998a).

31

Figura 4 - Uma arquitetura multicamadas para o data warehouse

Application Messaging

Diretrio de Dados (Metadados)

Dados Operacionais

Acesso a Dados

Data Staging

Data Warehouse

Acesso a Dados

Acesso a Informao

Gerenciamento do Processo

Fonte: Adaptado de SINGH, H. Data Warehouse: Conceitos, Tecnologias, Implementao e Gerenciamento. So Paulo: Makron Books, 2001.

Em um ambiente de data warehouse, o metadado utilizado para fornecer informaes sobre a localizao do contedo do data warehouse, mapeando os dados medida que os mesmos so transformados do ambiente operacional para o ambiente de date warehouse, informaes respeito dos algoritmos utilizados na sumarizao dos dados, informaes sobre as estruturas dos dados, histrico sobre a extrao e transformao dos dados e estatsticas sobre a utilizao dos dados.

d) Camada de Gerenciamento do Processo

Esta camada funciona como um organizador dos diversos processos que atuam em um data warehouse para mant-lo atualizado, envolvendo todas as tarefas necessrias a construo e manuteno do data warehouse.

e) Camada Application Messaging

o sistema de transporte de dados subjacente ao data warehouse. Esta camada responsvel pelo transporte de informaes do data warehouse pela rede da empresa.

32

f) Camada de Dados Operacionais

Sistemas OLTP foram projetados para suportar transaes bem definidas e relativamente pequenas. O objetivo de um data warehouse liberar informaes que esto presas nos sistemas OLTP e mistura-las com informaes de fontes externas para que estas possam ser teis tomada de deciso. A camada de Dados Operacionais o prprio banco de dados OLTP da organizao.

g) Camada Data Warehouse (Fsica)

a camada onde esto armazenados os dados do data warehouse propriamente dito. O data warehouse pode ser apenas uma visualizao lgica ou uma cpia dos dados operacionais e dados externos livres de inconsistncias e em um formato que proporcione um acesso rpido e flexvel.

h) Camada Data Staging

Esta camada envolve todos os processos e ferramentas necessrias extrao, transformao e limpeza dos dados antes que estes passem para o data warehouse fsico. uma camada onde os dados permanecem at serem limpos e padronizados antes do processo de carga do data warehouse.

2.4.5 Abordagens de Implementao

As abordagens de implementao se referem forma como o data warehouse projetado e implementado em relao s necessidades globais da empresa. As trs abordagens de implementao descritas neste trabalho so a abordagem top-down, a abordagem bottom-up e a arquitetura BUS.

a) Abordagem Top-Down
Este tipo de abordagem foi proposta por INMON (1997) e baseia-se em um data warehouse corporativo central, baseado no modelo relacional e totalmente normalizado. O processo de extrao, transformao e carga e, conseqentemente, a rea de estgio de dados so implementados de forma nica e integrada. Este data warehouse corporativo contm todos os dados organizacionais e tem o

33

propsito de servir de base de dados para os diversos data marts departamentais implementados com base no modelo dimensional (Figura 5). Este tipo de abordagem, apesar de fornecer uma base de dados corporativa nica, homognea e totalmente integrada, traz consigo problemas relativos a altos custos de implementao e demora na apresentao de resultados (VASCONCELLOS, 1999, BALLARD et al. 2001). Figura 5 - Abordagem top down

Sistema A Ferramenta de Extrao Data Warehouse

Data Mart A

Data Mart B

Sistema B

rea de Estgio

Fonte: SELL, D. Uma arquitetura para distribuio de componentes tecnolgicos para sistemas de informaes baseados em data warehouse. Florianpolis, p.48, 2001. Dissertao (Mestrado em Engenharia de Produo) Departamento de Engenharia de Produo e Sistemas, Universidade Federal de Santa Catarina.

b) Abordagem Bottom Up
Esta abordagem se baseia na construo de data marts dimensionais independentes (Figura 6), cada qual com sua respectiva rea de estgio e processos de extrao, transformao e limpeza e metadados. O data warehouse, neste tipo de implementao composto pelo conjunto de todos os data marts construdos, formando um data warehouse incremental lgico (VASCONCELLOS, 1999, FIRESTONE, 2001, BALLARD et al. 2001). As vantagens deste tipo de abordagem so a rapidez e a simplicidade do projeto de desenvolvimento dos data marts, o que possibilita a disponibilizao dos primeiros data marts em espaos de tempo relativamente curtos. Entretanto, a falta de um processo de planejamento prvio acarreta problemas perceptveis somente a longo prazo. O processo de desenvolvimento independente acarreta inconsistncia

34

entre os metadados de cada data mart, resultando no que se convencionou chamar de legamarts, ou data marts legados (FIRESTONE, 2001). Os processos de extrao, transformao e limpeza independentes tambm acarretam nos recursos utilizados, tais como hardware e infraestrutura de redes (VASCONCELLOS, 1999, BALLARD et al, 2001). Figura 6 - Abordagem Bottom Up
rea de Estgio A

Ferramenta de Extrao A Sistema A Ferramenta de Extrao B

Data Mart A

Data Mart B

Data Warehouse

Sistema B

rea de Estgio B

Fonte: SELL, D. Uma arquitetura para distribuio de componentes tecnolgicos para sistemas de informaes baseados em data warehouse. Florianpolis, p.48, 2001. Dissertao (Mestrado em Engenharia de Produo) Departamento de Engenharia de Produo e Sistemas, Universidade Federal de Santa Catarina.

c) Arquitetura BUS
Esta arquitetura foi proposta por KIMBALL et al. (1998b), como forma de unir as vantagens da abordagem top down s vantagens da abordagem bottom up. Neste tipo de arquitetura, o data warehouse lgico e incremental formado por vrios data marts planejados e integrados. Os data marts so construdos segundo o processo de planejamento. Desta forma obtm-se um data warehouse incremental e totalmente integrado aliado a um retorno rpido do investimento mediante a construo de data marts (Figura 7). O planejamento consiste em especificar uma arquitetura global de dados com um escopo bem definido e um conjunto especfico de metas e seguir este planejamento

35

construindo data marts incrementais totalmente aderentes aos padres da arquitetura planejada. Durante o processo de planejamento so definidos dimenses comuns e fatos padronizados. As dimenses comuns so definidas em nvel atmico, ou seja, com menor gro possvel a fim de poderem ser relacionadas a qualquer tabela de fatos. Ao mesmo tempo em que so definidas as dimenses comuns, tambm so definidos os fatos padronizados. Estes fatos devem possuir a mesma nomenclatura entre os diversos data marts que formaro o data warehouse lgico e mantidos em nvel atmico. Figura 7 - A arquitetura BUS

Sistema A

Ferramenta de Extrao

Data Mart A

Data Mart B

Sistema B

rea de Estgio

Fonte: SELL, D. Uma arquitetura para distribuio de componentes tecnolgicos para sistemas de informaes baseados em data warehouse. Florianpolis, p.49, 2001. Dissertao (Mestrado em Engenharia de Produo) Departamento de Engenharia de Produo e Sistemas, Universidade Federal de Santa Catarina.

2.4.6. Estrutura de Custos de um Data Warehouse

Os custos de um data warehouse comeam nos estgios iniciais do desenvolvimento e continuam durante todo o ciclo de vida do mesmo. A estrutura de custos est distribuda entre os seguintes componentes (KIMBALL, 1998b): Licenas de hardware e software. Este item inclui todo o hardware e softtware e seus upgrades. Devem ser considerados o hardware servidor e cliente, licenas de bancos de dados, ferramentas de data staging, ferramentas de conectividade e softwares para desktop.

36

Despesas contnuas de manuteno. Considerar neste item todas as despesas de manuteno de hardware e os contratos de manuteno e suporte de software.

Desenvolvimento interno. Caso o data warehouse seja desenvolvido internamente, os custos de desenvolvimento devem ser considerados. Caso seja contratado desenvolvimento externo, deve-se considerar os custos do planejamento preliminar e acompanhamento do projeto como custos de desenvolvimento interno.

Recursos de desenvolvimento externos, se requeridos. Entram neste item todos os recursos externos contratados para o desenvolvimento do data warehouse que no se encaixam nos itens anteriores.

Despesas educacionais com o pessoal de desenvolvimento e a comunidade de usurios.

Suporte ps-implantao. Despesas com suporte ao usurio de data warehouse.

Despesas com crescimento da instalao. Devem ser consideradas neste item despesas geradas pelo aumento da populao de usurios, crescimento das bases de dados e alteraes nos requerimentos do negcio.

4.7 Modelagem Dimensional 2.4.7.1 Conceito

A modelagem dimensional, ou esquema em estrela uma tcnica de modelagem de dados voltada especialmente para a implementao de um modelo de dados que permita a visualizao de dados de forma intuitiva e com altos ndices de performance na extrao de dados (KIMBALL et al., 1998b, MACHADO, 2000). O modelo dimensional proporciona uma representao do banco de dados consistente com o modo como o usurio visualiza e navega pelo data warehouse, combinando tabelas com dados histricos em sries temporais, cujo contexto descrito atravs

37

de tabelas de dimenses (BALLARD et al., 2001, HARRISON, 1998). O modelo dimensional baseado em trs elementos: Fatos; Dimenses; Medidas.

Um fato uma coleo de itens de dados composta de dados de medida e dados de contexto. Dados de medida so as medies numricas do negcio e os dados de contexto so chaves estrangeiras apontando para cada uma das dimenses. Cada fato pode representar uma determinada transao ou evento do negcio ocorrido em um determinado contexto obtido na interseco das dimenses (KIMBALL et al., 1998b, MACHADO, 2000). Uma dimenso se refere ao contexto em que um determinado fato ocorreu, tais como perodos de tempo, produtos, mercados, clientes e fornecedores elementos que possam descrever o contexto de um determinado fato (HARRISON, 1998, MACHADO, 2000), classificando as medies ativas de uma organizao (KIMBALL, 1998a). Medidas so atributos que quantificam um determinado fato, representando a performance de um indicador em relao s dimenses que participam do fato. O contexto de uma medida determinado em funo das dimenses que participam do fato (MACHADO, 2000, KIMBAL, 1998). O modelo dimensional permite a visualizao de dados na forma de um cubo, onde cada dimenso do cubo representa o contexto de um determinado fato, e a interseco entre as dimenses representa as medidas do fato. (Figura 8). Matematicamente o cubo possui apenas trs dimenses, entretanto, no modelo dimensional a metfora do cubo pode possuir quantas dimenses forem necessrias para representar um determinado fato (MACHADO, 2000). Dimenses, fatos e medidas tero seus conceitos discutidos detalhadamente nas sees frente.

38

Figura 8 - O cubo de deciso

Fonte: MACHADO, F. N. Projeto de Data Warehouse: uma viso multidimensional. Rio de Janeiro: Editora rica, p. 66, 2000.

2.4.7.2 Navegao pelo modelo dimensional

As operaes bsicas para navegao por um modelo dimensional so drill down/roll up, drill across e slice and dice. Drill down e Roll Up (Figura 9) so operaes utilizadas para movimentar a viso verticalmente na hierarquia de uma dimenso. Atravs do drill down o usurio navega de um nvel mais alto de detalhe at um nvel mais baixo, enquanto que na operao roll up o usurio navega de um nvel mais baixo de detalhe at o nvel mais alto (BALLARD et al., 2001 MACHADO, 2000, SINGH, 2001). Para KIMBALL (1998a), efetuar drill down no significa apenas navegar verticalmente na hierarquia de uma dimenso. Significa obter e remover rapidamente cabealhos de linha de qualquer uma das dimenses da tabela de fatos.

39

Figura 9 - Drill down e roll up

Fonte: MACHADO, F. N. Projeto de Data Warehouse: uma viso multidimensional. Rio de Janeiro: Editora rica, p. 70, 2000.

Drill across combina vrias tabelas de fato que compartilham as mesmas dimenses em um nico relatrio (KIMBALL, 1998a) Slice and Dice (fatiar e girar) so operaes que permitem acessar um data warehouse por meio de qualquer uma de suas dimenses de forma igual (KIMBALL, 1998a, p. 319), ou seja, atravs destas operaes possvel navegar atravs dos dados do cubo de deciso ao longo de qualquer dimenso (SINGH, 2001). Slice (Figura 10) corta o cubo mantendo a mesma perspectiva de visualizao dos dados, permitindo que o usurio fixe a apresentao em um determinado detalhe (BALLARD et al., 2001, MACHADO, 2000 ). Dice, ou rotao (Figura 11) significa mudar a perspectiva de viso, girando o cubo e invertendo uma ou mais dimenses (BALLARD et al., 2001, KIMBALL, 1998a, MACHADO, 2000).

40

Figura 10 - Slice

Fonte: MACHADO, F. N. Projeto de Data Warehouse: uma viso multidimensional. Rio de Janeiro, p. 71-72, 2000.

Figura 11 - Dice
Volumes Pr-Pagos Masculino PR SC 30 20 Feminino 40 15 80 60 1999 Ps-Pagos Masculino Feminino 50 30

Dice
Volumes PR SC Masculino Feminino Masculino Feminino 1999 Pr-Pagos 30 40 20 15 Ps-Pagos 80 50 60 30

Fonte: MACHADO, F. N. Projeto de Data Warehouse: uma viso multidimensional. Rio de Janeiro, p. 71-72, 2000

2.4.7.3 Fatos
O objetivo de um data warehouse no armazenar informaes a respeito de documentos, tais como pedidos ou notas fiscais, mas sim informaes respeito do assunto que envolve tais documentos, tais como as vendas da organizao (MACHADO, 2000).

41

Fato tudo aquilo que pode ser representado por meio de valores mensurveis, geralmente numricos (MACHADO, 2000, KIMBAL, 1998) e que so objeto de anlise (BALLARD et al., 2001). Fatos, portanto podem ser caracterizados por algo que ocorre de forma varivel ao longo do tempo e podem ser expressos em valores mensurveis. Fatos podem ser aditivos, semi-aditivos e no aditivos (KIMBALL, 1998a, KIMBALL, 1998b): Fato aditivo aquele que pode ser adicionado a qualquer uma das dimenses. Os fatos mais teis em um banco de dados so os fatos aditivos e continuamente valorados (diferentes a cada medida), pois praticamente todas as consultas podem ser feitas sobre estes fatos. Uma tabela de fatos aditivos pode ser compactada facilmente atravs de processos de sumarizao, produzindo consultas de apenas algumas linhas a partir de tabelas extremamente extensas. Fato semi-aditivo aquele que s pode ser adicionado ao longo de algumas dimenses, o que restringe o nmero de consultas apenas quelas dimenses em que o fato pode ser adicionado. Fato no aditivo aquele que no pode ser adicionado a qualquer das dimenses. Para este tipo de fato, s se pode resumir registros atravs de contagens ou ento consulta-los um a um.

a) Representao de carteiras de produtos heterogneos

Algumas organizaes, principalmente as instituies financeiras, apresentam uma carteira de produtos bastante extensa, Neste tipo de organizao, geralmente necessrio observar os fatos de acordo com duas perspectivas: uma global e uma por linhas de produtos (KIMBALL, 1998a, KIMBALL , 1998b). Sob a perspectiva global, deseja-se visualizar toda a carteira de produtos em um nico cubo a partir de uma perspectiva de fatos comuns a toda a linha de produtos. Este tipo de soluo inviabiliza a utilizao de uma tabela de fatos para cada um dos produtos, devido ao grande nmero de tabelas consultadas para formar o cubo.

42

Neste caso a soluo criar uma nica tabela de fatos com as medidas comuns a cada um dos produtos (KIMBALL, 1998a, KIMBAL, 1998b). Sob uma perspectiva de linhas de produtos deseja-se analisar uma linha em especial, com todos os seus fatos particulares, neste caso a construo de uma tabela de fatos global incorreria na existncia de muitos valores nulos. A soluo para este tipo de problema a criao de mltiplas tabelas de fatos de acordo com as diferentes linhas de produtos (KIMBALL, 1998a, KIMBALL, 1998b). Para organizaes que possuem uma vasta carteira de produtos natural utilizar os dois tipos de soluo simultaneamente (KIMBALL, 1998a).

b) Transaes e instantneos
Existem caractersticas operacionais do data warehouse que independem do tipo de negcio em que o mesmo est inserido. Freqentemente, necessrio que existam duas verses de implementao de um determinado fato: uma representando cada transao individualmente e outra representando instantneos retirados em perodos regulares de tempo (KIMBALL, 1998a). A representao ao nvel transacional o nvel mais detalhado que se pode obter na representao dos fatos, representando, geralmente, a cada fato individualmente. a representao mais fcil de se obter na implementao do modelo dimensional e a que permite anlises mais ricas, que no podem ser obtidas a partir de fatos sumarizados (KIMBALL, 1998b). Algumas informaes mais gerais, tais como a lucratividade de uma categoria de produtos em um intervalo de tempo, so difceis, ou no podem, ser extradas a partir da sumarizao das transaes. A soluo para estes problemas a criao de tabelas de fato contendo instantneos (snapshots) retirados em determinados intervalos de tempo. Estes instantneos contm no somente a sumarizao das transaes individuais, mas tambm informaes indiretas, tais como a margem de lucro obtida no perodo (KIMBALL, 1998a).

c) Agregados
Agregados so resumos construdos a partir de fatos individuais, inicialmente por questes de performance, ou quando o ambiente dos fatos inexpressivo na menor

43

granularidade (KIMBALL, 1998a, KIMBALL, 1998b). Agregados permitem que as aplicaes antecipem os resultados a serem pesquisados pelo usurio eliminando a necessidade de se repetir clculos comumente realizados (SINGH, 2001). Mltiplos agregados podem ser construdos, representando os agrupamentos mais comuns dentro das dimenses do data warehouse a fim de aumentar a performance. A contrapartida ao aumento da performance o aumento do consumo de espao de armazenamento (KIMBALL, 1998b).

d) Tabelas de fatos sem fatos

Tabelas de fatos sem fatos so utilizadas para armazenar fatos que no podem ser associados a uma medida numrica. Tais tabelas podem ser utilizadas no rastreamento de eventos, como a freqncia dos alunos nas salas de uma escola, ou todos os elementos envolvidos em um acidente coberto por uma seguradora. Tabelas de fatos sem fatos tambm podem ser utilizadas ou para cobrir eventos que no ocorreram, como relacionar os produtos que no foram vendidos em uma determinada promoo (Figura 12) (KIMBALL, 1998a, KIMBALL, 1998b).

2.4.7.4 Dimenses
Dimenses determinam o contexto em que ocorreram os fatos. No modelo dimensional, cada dimenso est associada a um ou mais fatos, sendo estas usualmente mapeadas em entidades no numricas e informativas (BALLARD et al, 2001). Uma dimenso pode conter diversos membros e estes podem ser arranjados em hierarquias. Um membro de uma dimenso um nome nico utilizado para caracterizar um determinado dado. Por exemplo, os membros da dimenso tempo podem ser data, ano, ms, dia do ms, semana do ms, semana do ano etc. Os membros de uma dimenso podem ser arranjados em vrias hierarquias, cada hierarquia contendo vrios nveis (BALLARD et al. 2001), conforme a Figura 13. MACHADO (2000) afirma que a maioria dos fatos envolve pelo menos quatro dimenses bsicas: onde, quando, quem e o que (Figura 15). A dimenso Onde, determina o local onde o fato ocorreu (local geogrfico, filial). A dimenso Quando, a prpria dimenso tempo. A dimenso Quem, determina que entidades participaram

44

do fato (cliente, fornecedor, funcionrio). A dimenso O qu determina qual o objeto do fato (produto, servio).

Figura 12 - Tabela de fatos sem fatos

Dimensao_Tempo Chave_Tempo Data Dia_Semana Dia_Ano Numero_Semana Mes Trimestre Ano Dimensao_Produto Chave_Produto Codigo_Produto Descricao Marca Categoria Embalagem Tamanho Sabor

Fato_Frequencia Chave_Tempo Chave_Produto Chave_Loja Chave_Promocao

Dimenso_Loja Chave_Loja Id_Loja Nome_Loja Endereco Cidade Estado Regiao

Dimensao_Promocao Chave_promocao Nome_Promocao Tipo_Promocao Politica_Preco Politica_Publicidade Politica_Exibicao Tipo_Cumpom

Fonte: Adaptado de KIMBALL, R. The Data Warehouse Lifecycle Toolkit: Expert methods for designing and deploying data warehouses. New York: John Wiley & Sons Inc, 1998.

Alguns tipos de dimenso merecem ser estudadas mais profundamente devido a alguns tratamentos especiais dados a elas. A seguir apresentada uma discusso a respeito da dimenso tempo, dimenses de modificao lenta, dimenses grandes, minidimenses e dimenses sujas, dimenses muitos para muitos e chaves artificiais.

a) A dimenso tempo
Quase todo o data warehouse envolve uma srie temporal, portanto, a dimenso tempo est presente em quase todos os data warehouses. O motivo para que se crie uma dimenso tempo representar todos os intervalos de tempo necessrios ao negcio em questo, tais como perodos fiscais, temporadas, dias no teis e outras unidades de tempo necessrias ao negcio em questo (KIMBALL, 1998a, KIMBALL, 1998b).

45

Figura 13 - Hierarquias na dimenso tempo

Ano

Semestre 1

Semestre 2

Trimestre 1

Trimestre 2

Janeiro

Feverei ro

Maro

Di a 1

Ano

Semana 1

Semana 2

Semana n

Segunda

Tera

...

Domingo

Fonte: Adaptado de BALLARD, C. et al. Data Modeling Techniques for Data Warehousing. IBM Corporation. Disponvel em: <http://www.redbooks.ibm.com> Acesso em 21/06/2001.

46

Figura 14 - Dimenses comuns em um modelo dimensional

Onde Quando

Fatos

Quem

O que

Fonte: MACHADO, F. N. Projeto de Data Warehouse: Uma Viso Multidimensional. So Paulo: rica, 2000, p. 95.

b) Dimenses de modificao lenta

A maioria das dimenses se modifica lentamente ao longo do tempo. Para que se possa rastrear as modificaes que uma dimenso pode sofrer, utiliza-se um dos trs mtodos a seguir (KIMBALL, 1998b, KIMBALL, 1998a): Substituir os valores antigos do registro modificado por valores novos e, assim, perder a capacidade de rastrear o histrico da dimenso. Adicionar um novo registro dimenso com os valores novos do atributo, segmentando o histrico entre a antiga e a nova dimenso. Criar novos campos para os valores atuais e os valores antigos, mantendo o histrico da dimenso em um nico registro, mas reduzindo a capacidade de manter o histrico da dimenso.

47

c) Dimenses grandes
Existem casos em que algumas dimenses podem conter milhes de entradas, por exemplo, a dimenso cliente em uma companhia telefnica, neste caso a navegao por esta dimenso pode tornar-se demorada. Pode-se, neste caso, utilizar ndices nos atributos que sejam objetos de navegao (KIMBALL, 1998a).

d) Minidimenses
Freqentemente, os campos mais utilizados em uma dimenso grande possuem um domnio pequeno, ou seja, assumem uma pequena quantidade de valores. Em uma dimenso cliente, estes atributos podem ser atributos demogrficos, como sexo, faixa etria e classe social. Neste caso, pode-se optar pela criao de uma minidimenso separada da dimenso cliente para aumentar a eficincia da navegao (KIMBALL, 1998a).

c) Dimenses descaracterizadas
Atributos como o nmero da nota fiscal de venda, aparentemente, deveriam fazer parte da tabela de fatos. Em um banco de dados relacional, ele seria o atributo determinante do cabealho da nota fiscal. Em um banco de dados dimensional, normalmente, todos os atributos determinados pelo nmero da nota foram armazenados em dimenses prprias e faria parte da chave primria dos itens da nota. Ainda assim, pode-se utilizar este atributo para agrupar os fatos pelo documento original. Atributos deste tipo so representados como dimenses descaracterizadas, isto , chaves de dimenso sem uma dimenso correspondente (KIMBALL, 1998a).

d) Dimenses sujas
Dimenses sujas ocorrem quando uma entidade aparece diversas vezes, podendo haver ligeiras diferenas em alguns de seus atributos. Em um data warehouse bancrio, a dimenso conta, contendo atributos do correntista, uma dimenso suja, pois em caso de conta conjunta, a conta aparecer vrias vezes, uma para cada correntista (KIMBALL, 1998a).

48

e) Chaves artificiais
Utilizar uma chave candidata como chave primria de uma dimenso pode causar problemas, caso esta chave no seja absolutamente estvel ao longo do tempo. Uma modificao em uma chave de uma dimenso pode ocasionar um grande volume de mudanas nas tabelas de fato relacionadas esta dimenso. A soluo para este problema utilizar chaves artificiais absolutamente estveis ao longo do tempo. Uma chave artificial um campo inteiro e autoincremental, que aumenta a cada novo registro includo na tabela de dimenso (KIMBALL, 1998b).

f) Dimenses muitos para muitos

Na maioria dos casos, o relacionamento entre uma dimenso e a tabela de fatos um para muitos. Entretanto, podem existir casos em que um registro de um fato pode estar ligado a muitas ocorrncias de uma determinada dimenso. Um exemplo um data warehouse para hospitais, onde um nico internamento pode estar ligado a vrios diagnsticos. A soluo para este problema a mesma utilizada em um modelo relacional, ou seja, dividir o relacionamento muitos para muitos em dois relacionamentos um para muitos atravs de uma tabela ponte (ou entidade associativa) entre a tabela de fatos e a tabela de dimenso (Figura 15) (KIMBALL, 1998b).

2.4.7.5 Granularidade
A granularidade se refere ao nvel de detalhe em que sero armazenados os dados no data warehouse (BALLARD et al., 2001, KIMBALL, 1998a, INMON, 1997), quanto maior o detalhamento, mais baixo o nvel de granularidade. A granularidade afeta o volume de dados do data warehouse e, portanto, a performance na extrao de informaes. Um outro aspecto importante a possibilidade de extrao de informaes da base de dados. Quanto mais alto o nvel de granularidade menores as possibilidades de extrao de informaes (BALLARD et al., 2001, INMON, 1997). Um data warehouse pode ser implementado em nveis duais de granularidade ao longo do tempo. possvel manter as informaes mais recentes em um baixo nvel de granularidade, aumentando assim as possibilidades de extrao de informaes.

49

A medida que os dados vo ficando obsoletos, possvel resumi-los em um alto nvel de granularidade de forma a manter a performance (INMON, 1997). Opcionalmente, pode-se optar por mltiplos nveis de granularidade em um data warehouse, partindo-se inicialmente de um baixo nvel de granularidade, passando por nveis intermedirios at um alto nvel de granularidade, dependendo das necessidades de informao e do custo de mant-las no data warehouse (BALLARD et al., 2001). KIMBALL (1998b), prope que as tabelas de fato de um data mart na arquitetura bus, assim como as dimenses padro, devem estar no menor nvel de granularidade possvel, proporcionando facilidade na alimentao da base de dados e continuidade na extrao de informaes ao longo do tempo.

Figura 15 - Relacionamento muitos para muitos

Dim Diagnstico Chave_Diagnostico ... Internamento ... Chave_Diagnostico ...

Dim Diagnstico Chave_Diagnostico ...

Grupo Diagn ost ico Ch ave_Grup o_ Diagn ost ico Ch ave_Diagno st ico

Int ernam ent o ... Ch ave_Grup o_ Diagn ost ico

Fonte: Adaptado de KIMBALL, R. The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing Data Warehouses. New York: Wiley Computer Publishing, 1998.

2.4.7.6 Particionamento
O particionamento consiste em dividir os dados em unidades fsicas menores, de forma a obter uma maior flexibilidade no gerenciamento do banco de dados. O particionamento, proporciona (BALLARD et al., 2001, INMON, 1997):

50

facilidade de reestruturao e indexao e reorganizao; facilidade de recuperao; facilidade de monitoramento; escalabilidade no data warehouse; portabilidade dos elementos do data warehouse.

Os critrios para se particionar um data warehouse dependem dos requisitos do negcio e restries fsicas da base de dados. Em geral, os critrios de particionamento podem ser os seguintes (BALLARD et al., 2001, INMON, 1997): tempo; geografia; rea de negcio ou linha de produtos; unidade organizacional; qualquer combinao dos critrios acima.

2.4.7.7 Consideraes a respeito do modelo dimensional

O modelo dimensional, ao contrrio do modelo entidade/relacionamento bastante assimtrico. H sempre uma tabela de fatos central, de natureza altamente normalizada conectada diretamente a tabelas de dimenso no normalizadas. Esta estrutura proporciona simplicidade e rapidez ao processo de extrao de informaes (KIMBALL, 1998a), mas no pode ser aplicada a sistemas OLTP, devido no normalizao das tabelas de dimenso.

2.4.8 O Modelo Snowflake

O modelo snowflake incorpora tabelas dimensionais principais conectadas s tabelas de fato e tabelas dimensionais de extenso, onde so armazenadas as descries das dimenses. Estas tabelas de extenso so obtidas normalizando-se as dimenses. (BALLARD et al., 2001, HARRISON, 1998, KIMBALL, 1998a, SINGH,

51

2001). As tabelas dimensionais principais contm chaves ligando-as s tabelas de extenso. A desvantagem snowflake a necessidade de mltiplos joins em consultas SQL, caso as consultas necessitem combinar diversas dimenses, o que aumenta a complexidade da instruo e reduz o desempenho HARRISON (1998). SINGH (2001) afirma que, em caso de tabelas de fatos muito extensas, ligadas a tabelas dimensionais tambm extensas, o modelo snowflake pode melhorar a performance se houver uma reduo significativa no tamanho da tabela de dimenso. Entretanto, KIMBALL (1998a) considera o esquema estrela a nica tcnica vivel para modelagem de dados para o data warehouse. Para BALLARD et al (2001), o modelo snowflake facilita a compreenso e entendimento dos desenvolvedores, mas dificulta o entendimento por parte dos usurios finais. H tambm uma reduo do espao ocupado pelas tabelas de dimenso, entretanto, este ganho no um critrio determinante na seleo da tcnica de modelagem. Segundo HARRISON (1998), existem trs tipos bsicos de projetos snowflake: pesquisa, em cadeia e atributo.

a) Pesquisa
O modelo pesquisa utiliza uma tabela dimensional principal conectada diretamente tabela de fatos e tabelas de extenses conectadas tabela dimensional principal (Figura 16).

b) Em cadeia
O modelo em cadeia coloca as tabelas de extenso encadeadas, comeando com uma tabela dimensional principal conectada tabela de fatos (Figura 17). A prxima dimenso conectada tabela dimensional principal e assim sucessivamente at a ltima dimenso. Este modelo mantm um alto nvel de integridade de dados por que as dimenses so completamente normalizadas.

c) Atributo
O modelo atributo permite construir uma dimenso principal artificial a partir de vrios grupos de atributos dimensionais no relacionados (Figura 18).

52

Figura 16 - Snowflake do tipo pesquisa

Fonte: Adaptado de HARRISON, T. H. Intranet Data Warehouse. So Paulo: Berkeley, p. 72, 1998.

Figura 17 - Snowflake em cadeia

Fonte: Adaptado de HARRISON, T. H. Intranet Data Warehouse. So Paulo: Berkeley, p. 74, 1998.

2.4.9 O modelo relacional versus Modelo Dimensional

Enquanto o ambiente do modelo relacional o dos sistemas OLTP, o modelo dimensional destina-se a suportar os sistemas de apoio deciso. SINGH (2001) traa um quadro comparativo entre o modelo relacional e o modelo dimensional:

53

a) Transao versus Intervalo de tempo

A visualizao dos dados em um modelo dimensional feita sob a perspectiva de intervalos de tempo, consistente com os problemas globais da organizao, enquanto que o modelo relacional foca transaes atmicas processadas em um sistema OLTP.

b) Consistncia Local versus Global

A consistncia, do ponto de vista do modelo relacional, a transao em si. Uma transao de uma venda a prazo consistente se todas as informaes desta venda a prazo foram gravadas corretamente no banco de dados. A consistncia, do ponto de vista do modelo dimensional tem sua consistncia baseada nos aspectos globais da organizao. Figura 18 - Snowflake do tipo atributo

Fonte: Adaptado de HARRISON, T. H. Intranet Data Warehouse. So Paulo: Berkeley, p. 75, 1998.

c) Audit Trail versus Big Picture

O modelo relacional permite o rastreamento de transaes, tais como o histrico das faturas do carto de crdito. O modelo dimensional permite responder questes

54

normalmente relacionadas ao trabalho do conhecimento, como a possibilidade de lucro ou no de uma categoria de produtos ou oportunidades de negcio.

d) Relacionamentos explcitos versus implcitos

No modelo relacional os relacionamentos esto explcitos entre as entidades do modelo. H um relacionamento formal entre a entidade cliente e a entidade produto. No modelo dimensional estes relacionamentos esto implcitos pela existncia de intersees entre as dimenses na tabela de fatos.

e) OLTP versus data warehouse

O modelo de dados projetado para suportar o data warehouse requer uma otimizao voltada para a extrao de informaes. Neste tipo de aplicativo ocorrem poucas transaes acessando um grande nmero de registros a cada transao. Os sistemas OLTP necessitam de modelos de dados altamente normalizados, visando oferecer um alto desempenho no processamento de um grande nmero de transaes envolvendo poucos registros. A quadro 1 a seguir estabelece um comparativo entre um OLTP e um Data Warehouse. Quadro 1 - OLTP versus data warehouse Tpico/Funo Contedo dos Dados Organizao dos dados Natureza dos dados Estrutura formato dos Operacional Valores atuais Aplicao por aplicao Dinmica Data Warehouse Dados de arquivo, sumarizados e calculados reas de assunto longo da empresa ao

Esttica at a reciclagem adequada Simples; adequada para computao anlise empresarial Moderada a baixa Acessados manipulados atualizao direta e sem

dados: Complexa; para operacional Alta

Probabilidade de acesso Atualizao dos dados

Campo a campo

Uso

Processamento repetitivo Processamento analtico e altamente estruturado e altamente desestruturado

55

Tpico/Funo Tempo de resposta

Operacional Frao de segundos

Data Warehouse Segundos a minutos

Fonte: SINGH, H. S. Data Warehouse. Conceitos, Tecnologias, Implementao e Gerenciamento. So Paulo. Makron Books, 2001, p 153-154.

56

3 METODOLOGIA 3.1 Introduo

Este captulo caracteriza a pesquisa, descrevendo o problema e a hiptese de pesquisa. Em seguida descrita a metodologia utilizada para testar o modelo proposto em relao ao modelo relacional e ao modelo dimensional, a fim de verificar a viabilidade do modelo. No prximo captulo, o modelo proposto ser descrito em detalhes e no captulo 5 sero apresentados os resultados dos testes.

3.1 Caracterizao da Pesquisa

Esta pesquisa, por sua natureza, caracteriza-se como uma pesquisa aplicada, pois objetiva gerar conhecimentos para a soluo de problemas relativos extrao de informaes de bases de dados. Quanto forma de abordagem, sero explorados aspectos tanto quantitativos quanto qualitativos.

3.1.1 Problema de pesquisa

possvel reduzir os custos de um ambiente de data mart, de forma que empresas com escassez de recursos financeiros possam se beneficiar deste tipo de tecnologia?

3.1.2 Hiptese de pesquisa

A concepo de um modelo hbrido de dados, que una caractersticas do modelo entidade/relacionamento e do modelo dimensional possibilita a implementao de sistemas OLTP e data mart em uma mesma base de dados, evitando-se assim os custos da duplicao das bases de dados, uma para sistemas OLTP e outra para data warehouse e data marts.

3.1.3 Etapas da pesquisa

O presente trabalho fundamenta-se em trs etapas distintas:

57

a) Pesquisa bibliogrfica a respeito de sistemas de informao, concentrando-se em sistemas OLTP, modelo entidade/relacionamento, sistemas de apoio deciso, data warehouse e modelo dimensional. b) Proposta de um modelo hbrido de dados, que atenda tanto aos requisitos dos sistemas OLTP quanto s necessidades de extrao de dados do data warehouse. Este modelo, para ser vivel, deve suprir as necessidades de informao de empresas, que no possuem recursos para investir em dois ambientes de infraestrutura tecnolgica, um para sistemas OLTP e outro para o Data Warehouse. c) Para investigar a viabilidade do modelo hbrido, so desenvolvidos e comparados dois prottipos de sistema, um baseado no modelo entidade/relacionamento e outro baseado no modelo hbrido. Estes prottipos so comparados para se verificar a viabilidade do modelo.

3.2 Apresentao e Anlise dos Resultados

A fim de verificar a viabilidade da utilizao do modelo hbrido, os prottipos sero comparados levando-se em conta os seguintes parmetros: a) Performance no processamento transacional. Para se medir a performance no processamento transacional as bases de dados dos dois modelos so alimentadas a partir da mesma massa de dados. O tempo de carga o critrio para comparao dos dois modelos. b) Performance na extrao de informaes. Para este item utilizada a ferramenta Decision Cube do Borland Delphi. As mesmas consultas so aplicadas aos dois modelos e o tempo de resposta utilizado como parmetro de comparao. c) Redundncia de dados. O modelo de dados utilizado nos dois prottipos comparado a fim de verificar a existncia de redundncia de dados. d) Complexidade do modelo de dados. Este item comparado qualitativamente. Os modelos de dados dos prottipos so analisados

58

a fim de se comparar a complexidade dos mesmos. Esta comparao servir para se conhecer o nvel de dificuldade oferecido na montagem de consultas SQL e a dificuldade de se entender o modelo. Figura 19 - Complexidade Ciclomtica

a
R1 R2
R5

b
R3 R4

V(G) = 5

f
Fonte: PRESSMAN, R. Engenharia de Software. Rio de Janeiro: Makron Books, 1995. p. 761.

e) Complexidade do cdigo fonte da aplicao. A complexidade do cdigo fonte comparada utilizando-se a mtrica de complexidade ciclomtica. Esta mtrica foi proposta por McCABE (apud PRESSMAN, 1995 e KAN, 1995) e baseia-se no fluxo de controle de um programa (Figura 19). Um grafo de fluxo desenhado para o programa representando o nmero de caminhos independentes que o fluxo do programa pode percorrer. Cada n do grfico representa uma tarefa de processamento, que pode ser composta por uma ou mais instrues fonte. Cada seta representa um caminho a ser tomado pelo fluxo do programa. A complexidade ciclomtica (V(G)) dada pelo nmero de

59

regies do grfico. No exemplo da Figura 19, V(G)=5, pois o grfico tem cinco regies. f) Tamanho do cdigo fonte. Os programas necessrios ao

funcionamento dos dois sistemas so comparados a fim de se verificar a complexidade dos mesmos. Para tanto utilizada a mtrica de Linhas de Cdigo. g) Tamanho da base de dados. O tamanho total da base de dados nos dois modelos. h) Complexidade das consultas SQL. Sero utilizados dois critrios para medir a complexidade das consultas SQL. O primeiro a quantidade de joins necessrios ao processamento de carga do cubo de deciso. O segundo a quantidade de joins entre dimenses necessrios carga do cubo. Os joins entre dimenses so aqueles que ligam uma dimenso a outra, comumente utilizados no modelo relacional e praticamente eliminados do esquema estrela, a fim de garantir performance na execuo e simplicidade na construo das consultas.

60

4 O MODELO PROPOSTO 4.1 Introduo

O presente captulo apresenta o modelo proposto. O modelo procura unir caractersticas de suporte ao processamento transacional, obtidas do modelo entidade-relacionamento s caractersticas do modelo dimensional, de modo que o modelo suporte tanto o processamento de transaes, quanto aplicaes de apoio informacional. Este modelo tem a vantagem de eliminar os custos de duplicao dos ambientes de processamento transacional e informacional, atravs de um modelo em estrela sobreposto ao modelo entidade/relacionamento. No prximo captulo so apresentados os resultados dos testes executados com o modelo proposto em relao ao modelo relacional e ao dimensional puro.

4.2. Descrio do Modelo

O modelo utiliza uma variao do modelo snowflake em cadeia (HARRISON, 1998). Este modelo normaliza as tabelas de dimenso, criando relacionamentos entre as mesmas. A normalizao reduz o tamanho das dimenses e aumenta a cardinalidade dos relacionamentos entre dimenses e tabela de fatos. Entretanto, a recuperao de informaes exige um aumento do nmero de junes entre tabelas, devido aos relacionamentos em cascata, o que acarreta uma queda na performance do processamento sistemas de processamento informacional. A queda de performance na extrao de informaes resolvida conectando-se todas as tabelas de dimenso tabela de fatos. O processo de modelagem descrito nos prximos pargrafos. A reduo dos custos se d atravs da no utilizao de ambientes separados para processamento transacional e informacional , uma vez que ocorre a unificao das camadas de dados operacionais e de data warehouse e a eliminao das camadas de data staging e da parte da camada de acesso a dados que transporta os dados operacionais para a camada de data staging. Com base na arquitetura proposta por SINGH (2000) a Figura 20 a seguir prope um modelo conceitual de para processamento transacional e informacional utilizando o modelo hbrido. O

61

modelo acrescenta uma camada de processamento transacional, a fim de alimentar uma base de dados nica. Figura 20 - Uma arquitetura em camadas utilizando o modelo hbrido

a)

Camada de processamento transacional. Esta camada responsvel pelo processamento transacional da organizao. composta pelos sistemas de processamento transacional.

b)

Camada de acesso a dados. Faz a conexo entre o banco de dados e as camadas de processamento de transaes e de acesso a informao, composta por SGBDs e todo o hardware/software necessrios a servios de acesso a bancos de dados

c)

Camada de Banco de Dados. o prprio banco de dados implementado com base no modelo hbrido, englobando em uma nica base de dados o data warehouse e os dados dos sistemas transacionais.

d)

Camada de acesso a informao. a camada atravs do qual o usurio de sistemas informacionais tem acesso ao data warehouse.

e)

Camada de diretrio de dados. Contm os metadados tcnicos e de negcios. Como no so necessrias informaes a respeito do processo de data staging, esta camada uma camada mais fina do que a camada equivalente no data warehouse tradicional.

62 f) Camada de gerenciamento do processo. Analogamente arquitetura proposta por SINGH (2001), esta camada organiza os diversos processos que atuam tanto no processamento transacional, quanto no informacional. g) Camada application messaging. Cumpre o mesmo papel que a camada equivalente na arquitetura de SINGH (2001), ou seja, responsvel pelo transporte de dados e informaes pela rede da empresa.

4.2. Estrutura de Custos do Modelo Hbrido

Comparando-se a estrutura de custos proposta por KIMBALL (1998b) com a arquitetura em camadas proposta para o modelo hbrido, constata-se que a eliminao da camada de data staging suprime no somente os custos de duplicao dos ambientes de informtica (um para o processamento transacional e outro para o informacional), como tambm os custos da prpria camada de data staging. Estes custos envolvem o hardware para esta camada, ferramentas de data staging, licenas de bancos de dados, custos de desenvolvimento, custos com treinamento do pessoal de desenvolvimento e custos com escalabilidade do ambieente.

4.3. Desenvolvimento do Modelo

O desenvolvimento de um modelo hbrido inicia-se a partir da elaborao de um modelo snowflake em cadeia (HARRISON, 1998), mantendo-se a granularidade das tabelas de dimenso e das tabelas de fato no nvel atmico (Figura 21). As tabelas de dimenso mantm as informaes a respeito do contexto em que as transaes/fatos ocorreram, enquanto que a tabela de fatos armazena todas as transaes ocorridas no perodo. Um exemplo completo de snowflake em cadeia est ilustrado na Figura 23 Figura 21 - Modelo snowflake em cadeia

63

A utilizao do modelo snowflake em cadeia importante, pois mantm as tabelas de dimenso totalmente normalizadas. A normalizao das tabelas de dimenso garante a integridade referencial, fundamental para o processamento de transaes. A manuteno granularidade das tabelas em nvel atmico permite o armazenamento de cada transao ocorrida individualmente, permitindo a extrao de informaes em qualquer nvel de detalhe, no caso de processamento informacional e garante um rastreamento detalhado de todas as transaes no caso de processamento transacional. O prximo passo , exportar as chaves primrias das tabelas de dimenso que no se relacionam diretamente com a tabela de fatos para a mesma, gerando um aumento do nmero de relacionamentos e de chaves estrangeiras (Figura 22). Este procedimento transforma o modelo snowflake em cadeia em um modelo hbrido, capaz de suportar tanto o processamento transacional quanto informacional. A exportao de chaves estrangeiras reduz a quantidade de joins em cascata exigida pelo modelo snowflake em cadeia quando se processa a extrao de informaes. Esta alterao faz com que se obtenha um modelo em estrela baseado em minidimenses (KIMBALL, 1998a) sobreposto ao modelo snowflake, proporcionando duas vises diferentes do mesmo modelo de dados, uma para o processamento transacional e outra para o processamento informacional. Um exemplo de modelo hbrido de dados est exposto na Figura 24. Figura 22 - Modelo hbrido proposto

A exemplo do modelo dimensional, para as chaves primrias, tanto das tabelas dimensionais quanto da tabela de fatos devem ser escolhidas chaves artificiais As chaves artificiais tm a vantagem de serem absolutamente estveis ao longo do

64

tempo, facilitando assim quaisquer alteraes em chaves candidatas, suportando o processamento transacional e mantendo intacto o histrico dos fatos ocorridos ao longo do tempo. As caractersticas contidas no modelo, capazes de suportar tanto o processamento transacional quanto informacional esto descritas nas sees seguintes.

4.5. Suporte ao processamento transacional e ao data warehouse.

O modelo proposto deve preservar as caractersticas de um data warehouse e ainda suportar o processamento transacional. A seguir estas caractersticas sero discutidas sob os aspectos do data warehouse propostas por INMON (1997) e ao mesmo tempo dos sistemas de processamento transacional.

4.5.1. Baseado em assuntos

O modelo proposto suporta perfeitamente esta caracterstica, pois as tabelas de dimenso e de fatos devem ser projetadas para conter tanto informaes necessrias ao processamento transacional quanto informaes a respeito do negcio necessrias ao apoio deciso.

4.5.2. Integrado e no voltil

O modelo adapta-se perfeitamente arquitetura BUS (KIMBALL, 1998a, 1998b), que permite a construo de data marts integrados. Dimenses devem ser projetadas de forma que sejam compartilhadas por diversos data marts e as tabelas de fato devem ser projetadas de forma a eliminar qualquer inconsistncia, de forma que o sistema fornea respostas nicas para uma determinada consulta, obtendo-se assim um data warehouse lgico e incremental planejado de forma global e construdo e implantado atravs de liberaes sucessivas. Como o modelo deve suportar o processamento transacional e o de apoio deciso, necessrio um tratamento especfico no que diz respeito volatilidade dos dados. Alteraes ou excluses fsicas em registros das tabelas de fato e de dimenses no devem ser permitidas, de forma a preservar o histrico dos fatos ocorridos. A soluo para este problema a utilizao de baixas e alteraes lgicas

65

atravs da adio de registros de alterao e de baixa, da a necessidade de se utilizar chaves artificiais como chaves primrias. Figura 23- Um modelo snowflake em cadeia
DimPromocao NomePromocao TipoDePreco TipoDeAnuncio TipoDeDisplay TipoDeCupom NomeMidiaAnuncio NomeFornecedor DtaInicio DtaTermino DimEstado PkEstado SiglaEstado NomeEstado

DimCidade PkCidade NomeCidade FkEstado

DimTempo Data DiaSemana DiaNoMes DiasCorridosNoAno SamanaNoAno NumeroMes NumeroTrimestre IndicadorFeriado IndicadorUltimoDiaMes Temporada Evento FatoVendas PkVenda FkTempo FkPromocao FkProduto FkLoja NumeroCupom Receita Custo DimLoja PkLoja NomeLoja FkCidade FkPlanta

DimPlanta PkPlanta TipoPlanta DimProduto DimMarca PkMarca NomeMarca PkProduto NomeProduto TamanhoEmbala gem FkMarca FkSubCategoria FkDepartamento DimSubCategoria PkCategoria CodSubCategoria NomeSubCategoria FkCategoria CodCategoria PkCategoria CodCategoria NomeCategoria

DimDepartamento PkDepartamento NomeDepartamento

66

Figura 24 - O modelo proposto

DimPromocao NomePromocao TipoDePreco TipoDeAnuncio TipoDeDisplay TipoDeCupom NomeMidiaAnuncio NomeFornecedor DtaInicio DtaTermino FatoVendas PkVenda FkTempo FkPromocao FkProduto FkLoja FkCategoria FkSubCategoria FkMarca FkPlanta FkEstado FkCidade FkDepartamento NumeroCupom Unidades Receita Custo IdentOperacao DimEstado PkEstado SiglaEstado NomeEstado

DimCidade PkCidade NomeCidade FkEstado

DimTempo Data DiaSemana DiaNoMes DiasCorridos SamanaNoAno NumeroMes NumeroTrimestre IndicadorFeriado IdentConsolidadoSN

DimLoja PkLoja NomeLoja FkCidade FkPlanta DimPlanta PkPlanta TipoPlanta

DimMarca PkMarca NomeMarca

DimProduto PkProduto NomeProduto FkMarca FkSubCategoria FkDepartamento

DimSubCategoria PkCategoria CodSubCategoria NomeSubCategoria FkCategoria

CodCategoria PkCategoria CodCategoria NomeCategoria

DimDepartamento PkDepartamento NomeDepartamento

. As excluses nas tabelas de dimenso devem ser processadas atravs de baixas lgicas. Para tanto se utiliza o atributo data de baixa (DtaBaixa) em todas as tabelas. Para se baixar um registro de uma tabela de dimenso, basta gravar a data de baixa no atributo apropriado. Desta forma, pode-se preparar o processamento transacional para no permitir a utilizao de um registro j baixado (DtaBaixa <> NULL) e ao mesmo tempo preservar a informao histrica atravs da no eliminao deste registro. Da mesma forma, uma alterao de um registro de dimenso deve ser feita

67

mediante uma baixa lgica seguida da incluso de um novo registro. A Figura 25 a seguir ilustra o processo de alterao da renda mensal de um cliente. A alterao de um registro de uma tabela de fatos segue o mesmo princpio. Entretanto, como um fato contm atributos de medio do negcio, uma baixa ou alterao destes atributos de medio resulta em alterao nos resultados do negcio. Para que o histrico das alteraes seja preservado, alm da data de baixa, utiliza-se um atributo para identificar a operao que originou o registro (IdentOperacao) em conjunto com o atributo data de baixa (DtaBaixa). Este novo atributo deve conter os seguintes valores: Novo: para a incluso de um novo registro. Baixa: para gravao de um registro de baixa, anulando os valores do registro original. Alterao: para gravao de um registro de alterao.

Figura 25 - Alterao da renda mensal de um cliente

PkCliente CPFCliente NomeCliente 1 999999999-99 Jos da Silva Renda DtaBaixa R$ 2.500,00 Antes da alterao

PkCliente CPFCliente NomeCliente 1 999999999-99 Jos da Silva 2 999999999-99 Jos da Silva

Renda DtaBaixa R$ 2.500,00 23/01/02 R$ 3.000,00

Registro baixado Registro Alterado

Desta forma, ao se baixar um registro, grava-se a data de baixa no registro original e inclui-se um registro de baixa, com seus atributos de medio contendo valores negativos, de forma a anular os valores do registro original. Em caso de alterao, procede-se como na baixa, mas gravando-se tambm um registro de alterao com os novos valores. A Figura 26 a seguir mostra a alterao do atributo Receita um registro de venda de R$ 70,00 para R$ 75,00. Nela observa-se que uma instruo SQL select que totalize as colunas os atributos de medio, (Receita e Custo), agrupados pelo atributo Cupom retornar como resultado o valor aps a alterao (Receita = 70,00 70,00 + 75,00 = 75,00 e Custo = 100,00 100,00 + 100,00 = 100,00).

68

Figura 26 - Alterao de um registro de venda

PkVenda Cupom ... 1 123 PkVenda Cupom 1 123 2 123 3 123 ... ... ... ... Receita Custo DtaBaixa IdentOperacao Antes da alterao R$ 100,00 R$ 70,00 NOVO Receita R$ 100,00 R$ (100,00) R$ 100,00 Custo DtaBaixa IdentOperacao Alterao do custo para R$ 75,00 R$ 70,00 23/01/02 NOVO R$ (70,00) 23/01/02 BAIXA R$ 75,00 ALTERACAO

Uma forma alternativa de controlar as baixas e alteraes utilizar um atributo indicando se o registro est baixado ou no (IdnBaixadoSN = S, para registros baixados ou IdnBaixadoSN = N para registros ativos), em substituio a data de baixa. Esta opo tem a vantagem de no utilizar atributos com valores nulos, mas traz a desvantagem de no documentar a data em que o registro foi baixado ou alterado. Para a aplicao de data warehouse, importante que os dados estejam consolidados para serem consultados, isto obtido, carregando-se somente dados consolidados na base de dados do data warehouse. Como o modelo hbrido deve suportar processamento transacional, no havendo, portanto, um processo peridico de carga, utiliza-se um atributo na dimenso tempo para informar se aquela data est consolidada (IdentConsolidadoSN). Este atributo indica se a data poder ou no receber novos fatos. Este atributo pode assumir os seguintes valores: NO: Indica que os fatos relacionados a este registro de tempo ainda no esto consolidados, portanto, as consultas a este perodo podem sofrer alteraes. SIM: Indica que os fatos relacionados a este registro de tempo esto consolidados e que os sistemas de processamento transacional no podem mais atualizar informaes neste perodo. importante salientar que, diferentemente do data warehouse tradicional, onde os dados precisam passar por um processo de carga antes de serem consultados. A consulta permitida em qualquer data a qualquer momento, independentemente da data estar consolidada ou no. A diferena que, se uma determinada data no est consolidada, novos registros ainda podero ser adicionados a esta data, o que acarretar mudanas nos valores obtidos em consultas posteriores.

69

4.5.3. Varivel em relao ao tempo

Como o modelo permite o acmulo de dados ao longo de diversos perodos de tempo, no sendo alterados aps sua consolidao, o modelo pode fornecer informaes de apoio deciso em diversos perodos de tempo de forma precisa.

4.5.4 Fornecer dados de apoio s decises gerenciais

Para KIMBALL (1998a) o modelo dimensional composto por uma tabela de fatos central, conectada a diversas tabelas de dimenso. Este modelo tem a capacidade de fornecer, informaes no formato de um cubo de dados. O modelo proposto formado por uma tabela de fatos central, conectada a tabelas dimensionais normalizadas. O modelo proposto tambm conecta todas as dimenses tabela de fato e tambm dimenses entre si devido normalizao das mesmas. A Figura 24 mostra o modelo hbrido com os relacionamentos entre as tabelas de dimenso e a tabela de fatos destacados, para ilustrar sua semelhana com o esquema estrela e demonstrar a capacidade do mesmo de fornecer informaes na forma de um cubo de dados. Como as tabelas de fato so mantidas no menor nvel de granularidade possvel, as tabelas de fato podem ficar demasiadamente grandes. Para se resolver este problema, agregados podem ser utilizados de forma a reduzir a quantidade de registros lidos em uma consulta.

4.6. Consideraes finais a respeito do modelo proposto

O modelo proposto une caractersticas de suporte ao processamento transacional caractersticas de aplicaes de data warehouse. O quadro 02 a seguir resume as principais caractersticas conceituais do modelo proposto em relao ao modelo dimensional e ao modelo relacional. A reduo de custos no modelo proposto se d atravs da eliminao da camada de data staging e pela unificao dos ambientes de processamento transacional e informacional.

70

Quadro 2 - Caractersticas conceituais do modelo proposto em relao ao dimensional e ao relacional Caracterstica Proposto Dimensional Relacional Snowflake em cadeia Granularidade Mantida em Depende das Mantida em Depende das nvel atmico necessidades nvel necessidades para suportar o da aplicao. A atmico. da aplicao processamento arquitetura transacional. BUS prope Esta que a caracterstica granularidade vem da deve ser arquitetura mantida no BUS e do menor nvel modelo possvel. relacional Normalizao As dimenses Dimenses Todas as Dimenses das Dimenses devem ser no entidades devem ser normalizadas, normalizadas so normalizadas conforme o para melhorar normalizadas modelo a performance snowflake em e simplificar cadeia e o modelo modelo relacional Relacionamentos Entre as Das De acordo Entre as dimenses dimenses com as dimenses normalizadas, para a tabela regras da normalizadase conforme o de fatos e, normalizao entre a tabela modelo opcionalmente, dimensional snowflake em de principal e a cadeia e das minidimenses tabela de dimenses para fatos. para a tabela dimenses de fatos, a fim maiores de garantir performance no processamento transacional

71

5 APRESENTAO E ANLISE DOS RESULTADOS 5.1 Introduo

Neste captulo so apresentados e analisados os resultados dos testes realizados com o prottipo construdo segundo o modelo proposto, em relao ao modelo relacional e ao dimensional puro. Os testes, conforme a metodologia proposta consideram os seguintes aspectos: performance no processamento transacional; performance na extrao de informaes; redundncia de dados; complexidade do modelo de dados; complexidade do cdigo-fonte da aplicao; tamanho do cdigo-fonte; tamanho da base de dados.

Os testes foram realizados em um notebook Toshiba Satellite 2180CDT com as seguintes especificaes tcnicas: processador AMD K6-II 475 Mhz, cache L2 de 512 KB; Memria 64 MB PC100 SDRAM Disco rgido de 4,2 GB enhanced IDE

5.2 Descrio dos prottipos

Foram construdos trs prottipos de um sistema de vendas fictcio, o primeiro utilizando o modelo proposto (Figura 27) e os outros dois utilizando o modelo relacional (Figura 28) e o modelo dimensional (Figura 29), respectivamente. Como em um sistema de vendas, normalmente os cupons de venda so numerados seqencialmente, optou-se por utilizar uma chave artificial para a tabela de vendas

72

nos trs modelos. O ambiente de programao utilizado para a construo dos prottipos foi o Delphi e o banco de dados, o Interbase 6.0. Para a conexo entre o banco de dados e a aplicao foi utilizado o Borland Database Engine (BDE). A base de dados utilizada para carga dos prottipos contm dados a respeito das vendas de um supermercado fictcio, cuja tabela de fatos contm 11063 registros, e foi extrada de KIMBALL (1998a). Uma vez que as queries que carregam os cubos de deciso nos trs prottipos fazem uma varredura total da tabela de fatos e associam as tabelas de dimenso pelas chaves primrias, no foram criados ndices secundrios em nenhuma das tabelas dos trs prottipos. Os scripts de criao da base de dados e as queries para carga do cubo de deciso esto contidos nos apndices.

5.3 Performance no processamento transacional

Para a medio da performance no processamento transacional so carregados 11040 registros na tabela de fatos a respeito de vendas (tblFatoVendas) do modelo proposto e na tabela vendas (tblVendas) do modelo relacional. O modelo relacional levou 76 segundos para carregar, enquanto que o modelo proposto levou 474 segundos para carregar a base de dados. O tempo de gravao por registro foi de 0,00688 segundo por registro no modelo relacional e de 0,04293 segundo por registro no modelo proposto. Esta diferena de tempo deve-se ao fato de, no modelo proposto, existir um processo de busca das chaves estrangeiras para gravao na tabela de fatos, inexistente no modelo relacional. A diferena de tempo constatada (o modelo proposto foi 523 % mais lento no processo de carga que o modelo relacional), apesar de significativa se for considerado o tempo total, insignificante, se for considerado o tempo de gravao por registro em relao ao tempo que o usurio leva para digitar os dados referentes a um registro. Deve-se levar em conta tambm que no foram implementadas regras de negcio comumente utilizadas em sistemas de venda, tais como clculo de tributos, atualizao de nveis de estoque e outras, que, uma vez implantadas nos dois prottipos reduziriam a diferena relativa de performance entre os mesmos.

73

Figura 27 - O prottipo com o modelo proposto

Fonte: Adaptado de KIMBALL, R. Data Warehouse Toolkit. So Paulo: Makron Books, 1998.

74

Figura 28 - O prottipo relacional

5.4 Performance na extrao de informaes

Neste item o modelo proposto comparado com o modelo relacional e com o modelo dimensional puro. criada uma consulta SQL para montagem de um cubo de deciso que retorna o mesmo conjunto de dados para os trs modelos e so contados os tempos necessrios execuo da consulta. Como no modelo relacional no existem as dimenses tempo e promoo, estas no tambm no foram utilizadas no modelo hbrido e dimensional. O prottipo construdo com o modelo proposto levou 18 segundos para retornar os resultados, o prottipo dimensional levou 10 segundos, enquanto que o relacional levou 66 segundos para retornar os resultados. O modelo foi 247% mais rpido do que o modelo relacional e 80% mais lento do que o modelo dimensional, ficando o modelo proposto mais lento que o modelo dimensional, mas muito mais rpido que o modelo relacional.

75

Figura 29 - O prottipo com o esquema estrela

5.5 Redundncia de dados

Neste item analisa-se a redundncia de dados imposta pelo modelo. Como este aspecto importante apenas do ponto de vista do processamento transacional, o modelo proposto analisado apenas em relao ao modelo relacional.

76

Analisando-se o modelo relacional, constata-se que os nicos dados que redundantes so as chaves primrias, que so exportadas para as tabelas relacionadas na forma de chaves estrangeiras a fim de impor a integridade referencial. No modelo proposto, os nicos dados redundantes tambm so as chaves primrias, que so exportadas para as tabelas relacionadas na forma de chaves estrangeiras. O que ocorre em relao ao modelo relacional um aumento do nmero de chaves estrangeiras, devido ao aumento de relacionamentos imposta pelo modelo. Portanto, o nvel de redundncia nos dois modelos se equivale. Como s se utilizam chaves artificiais no modelo proposto e estas chaves so absolutamente estveis ao longo do tempo, pode-se afirmar que o aumento do nmero de chaves estrangeiras no acarreta nenhum problema de inconsistncia da base de dados devido ao aumento do nmero de chaves estrangeiras.

5.6 Complexidade do cdigo-fonte da aplicao

A mtrica utilizada para anlise da complexidade do cdigo-fonte da aplicao a de complexidade ciclomtica, proposta por MacCabe (PRESSMAN, 1995, KAN, 1995), e baseia-se no fluxo de controle da aplicao (para maiores detalhes a respeito da mtrica de complexidade ciclomtica, consultar o captulo 3, seo 3.2). Foram comparadas as complexidades do cdigo necessrias ao modelo entidade/relacionamento e ao modelo proposto. A nica diferena de codificao entre os dois modelos est no processo de manuteno da base de dados, portanto foi analisado somente este processo. Apesar do cdigo do modelo proposto ser mais extenso, ambos apresentaram um grau de complexidade igual a sete, pois o fluxo de controle do programa exatamente igual nos dois modelos. Pode-se concluir, portanto, que a complexidade do cdigo fonte no varia do modelo relacional para o dimensional.

5.7 Tamanho do Cdigo-Fonte

Na medio do tamanho do cdigo-fonte utilizou-se a contagem de linhas de cdigo, sendo comparados o modelo relacional ao proposto. O modelo relacional totalizou 342 linhas de cdigo, enquanto que o modelo proposto, totalizou 547 linhas de cdigo. O modelo proposto necessitou de um cdigo 62% mais extenso do que o

77

modelo relacional, nos prottipos testados. Esta diferena deve-se aos seguintes processos adicionais existentes no modelo proposto: O processo de alterao e de baixa de registros implementado de forma lgica e no fsica, o que obriga a existncia de processos de adio de registros de baixa, no processo de baixa de registros, neutralizando um determinado fato, e de registros de baixa e de alterao, no caso de alteraes em registros, gravando assim, um registro que neutraliza o fato e outro que altera o mesmo. Apesar de mais complexo, este procedimento tem a vantagem de preservar o histrico dos fatos, uma vez que no h a eliminao ou excluso fsica de registros, mas somente um processo de adio contnua. Caso este procedimento seja implantado no modelo relacional, o mesmo cdigo ser necessrio. O processo de busca de chaves estrangeiras implementado para buscar as chaves de todas as dimenses existentes, uma vez que elas so diretamente conectadas tabela de fatos. Nos dois modelos no foram codificadas regras de negcio comuns em um sistema de vendas real, foram codificadas somente as instrues necessrias carga das bases de dados. Uma vez codificadas estas regras de negcio, a diferena relativa entre os dois modelos se reduzir significativamente.

5.8 Tamanho da base de dados

O prottipo que utiliza o modelo dimensional puro ocupou um total de 1870 KB, o modelo relacional ocupou um total de 1552 KB e o modelo hbrido ocupou 3172 KB. O modelo hbrido, portanto, tende a ocupar mais espao do que os demais modelos individualmente: 48% mais que o modelo relacional, 58% mais que o modelo dimensional. Entretanto, o modelo proposto ocupou 7% menos espao do que a soma das bases de dados do modelo relacional e do dimensional.

78

5.9 Complexidade das consultas SQL

Para carregar o cubo de deciso utilizando o modelo dimensional, foram necessrios dois joins diretos com a tabela de fatos, o mesmo cubo de deciso necessitou de oito joins diretos com a tabela de fatos no modelo proposto. No modelo relacional foram necessrios quatro joins diretos com a tabela de fatos, mais quatro joins entre dimenses. Contando-se apenas o nmero de joins, os modelo proposto e o modelo relacional se equiparam, entretanto, no modelo relacional foram necessrios joins em cadeia, enquanto que no modelo hbrido foram necessrios apenas joins diretos com a tabela de fatos, o que simplifica a construo das consultas. A partir das exposies acima se pode concluir que o modelo dimensional mais simples do que os outros dois modelos, enquanto que o relacional o mais complexo, ficando o modelo proposto em uma posio intermediria.

5.10 Consideraes finais a respeito dos resultados obtidos

Este captulo apresentou e analisou os resultados obtidos com os testes dos prottipos construdos. Levando-se em considerao os prottipos construdos, pode-se afirmar que o modelo proposto revelou-se vivel na situao testada. O Quadro 3 a seguir, resume os resultados dos testes. A performance do modelo proposto no processamento transacional ficou aqum da performance obtida com o modelo entidade/relacionamento. Esta diferena devese ao processo de busca de chaves estrangeiras para gravao na tabela de fatos. Entretanto, levando-se em conta o tempo necessrio ao usurio digitar os dados da transao e o tempo necessrio para a gravao de um registro, pode-se afirmar que esta diferena no relevante. No que diz respeito performance na extrao de informaes, o modelo foi mais lento que o modelo dimensional, mas muito mais rpido que o modelo relacional, podendo-se afirmar que o modelo proposto se adequou mais a aplicaes de data warehouse do que o modelo relacional. A complexidade do modelo aumentou em relao ao modelo dimensional puro, mas como o mesmo apresenta uma viso em estrela da base de dados, ele mais simples que o modelo relacional na construo de cubos de deciso.

79

Quadro 3 - Resultado da avaliao dos prottipos Item Modelo Relacional Dimensional Diferena Proposto relativa Performance 0,04293 0,00688 No aplicado 523% mais lento no segundo/registro segundo/registro que o modelo processamento relacional transacional Performance 18 segundos 66 segundos 18 segundos 247% mais na extrao de rpido que o informaes modelo relacional 80% mais lento que o modelo dimensional Redundncia Somente chaves Somente chaves No aplicado No aplicado de dados estrangeiras estrangeiras Complexidade Complexidade Complexo para Simples para No aplicado do modelo de mdia para o o usurio final o usurio dados usurio final final Complexidade 7 7 No aplicado 0% ciclomtica do cdigo-fonte da aplicao Tamanho do 545 LOC 342 LOC No aplicado 62% maior que cdigo-fonte o modelo relacional Tamanho da 3172 KB 1552 1870 7% menor que o base de dados espao ocupado pelo modelo relacional e pelo dimensional juntos Complexidade Mdia Baixa Alta No aplicado das consultas SQL O cdigo-fonte do modelo proposto apresentou a mesma complexidade do modelo relacional, mas foram necessrias mais linhas de cdigo para implementa-lo. Esta diferena se deve ao processo de excluso e alterao lgica de registros e ao processo de busca das chaves estrangeiras para ligao com a tabela de fatos. Deve-se levar em conta que, se o mesmo processo de baixa e alterao lgica de registro for implementado em um modelo relacional, a diferena na quantidade de linhas de cdigo entre os dois modelos cair significativamente. Finalmente, deve-se levar em conta que no foram codificadas regras de negcio, comuns em sistemas reais, em nenhum dos prottipos implementados. A

80

codificao destas regras acarretar queda na performance do processamento transacional e aumento do tamanho do cdigo fonte, tanto no modelo relacional quanto no modelo proposto, o que reduzir a diferena relativa de performance no processamento transacional e no tamanho do cdigo fonte em ambos modelos.

81

6. CONCLUSO E ESTUDOS FUTUROS 6.1 Concluso

A globalizao gerou um ambiente onde a informao um dos principais insumos para que as organizaes possam reagir aos problemas e oportunidades que surgem no horizonte. No ambiente globalizado, utilizao eficaz da tecnologia da informao pode fazer com que as organizaes adquiram supremacia sobre a concorrncia no mercado em que atuam. neste contexto, que este trabalho prope um modelo de dados vivel nas condies testadas, capaz de suportar tanto o processamento transacional quanto o processamento informacional. O modelo proposto no se destina a substituir sistemas informacionais suportados por data warehouses com terabytes de informaes. Este modelo destina-se a suprir de informaes aquelas empresas que no possuem recursos para investir nas tecnologias necessrias a construo de data warehouses em separado para suporte aos seus sistemas de apoio deciso. O modelo proposto revelou-se vivel para a situao testada, produzindo resultados satisfatrios tanto para o processamento transacional quanto para o processamento informacional. A reduo de custos foi conseguida unificando-se os dois ambientes de dados (transacional e informacional) e, eliminando-se a camada de data-staging e todos os custos agregados a esta camada. Deve-se considerar que a camada de diretrio de dados (metadados) fica mais fina no modelo proposto, uma vez que o ambiente de banco de dados nico e no so necessrios metadados a respeito do rastreamento dos dados desde sua origem nos sistemas de processamento transacional, passando pela camada de data staging at o data warehouse. O captulo dois faz uma reviso dos conceitos de sistemas de informao, classificando-os de acordo com sua finalidade. Em seguida discutido o modelo entidade/relacionamento como modelo de dados para suporte ao processamento de transaes. Finalmente so discutidos o modelo dimensional e o data warehouse como tecnologias fundamentais para os sistemas de apoio deciso.

82

O captulo trs descreve a metodologia utilizada para a validao do modelo proposto, caracterizando a pesquisa, descrevendo a metodologia e enumerando os itens a serem analisados a fim de verificar a viabilidade do modelo proposto. O captulo quatro descreve as caractersticas do modelo proposto, comparando-o com o modelo dimensional e o modelo relacional. O captulo cinco apresenta e descreve os resultados obtidos nos testes com os prottipos construdos para o estudo de viabilidade do modelo.

6.2 Estudos futuros

Face ao risco de se aplicar um modelo de dados ainda no testado em ambientes reais, optou-se por construir prottipos de laboratrio para estudar a viabilidade do modelo proposto. Na seqncia deste trabalho, pretende-se aplicar o modelo em um sistema mais complexo e em ambiente real a fim de garantir de forma mais segura a viabilidade do modelo. Pretende-se tambm estudar formas de melhorar a performance do modelo no processamento transacional.

83

7 FONTES BIBLIOGRFICAS
BALLARD, C. et al. Data Modeling Techniques for Data Warehousing. IBM Corporation. Disponvel em: <http://www.redbooks.ibm.com> Acesso em 21/06/2001. BOAR, B. Understanding Data Warehouse Strategically. Disponvel em <http://warehouse.chime-net.org/manage/stplan/bboar1.htm>. Acesso em 01/07/2001. COUGO, P. Modelagem Conceitual e Projetos de Bancos de Dados. Rio de Janeiro. Campus, 1997. DATE, C. J. Introduo a Sistemas de Bancos de Dados. 7a ed. Rio de Janeiro: Campus, 2000. DOMENICO, J. A. Definio de um Ambiente Data Warehouse em uma Instituio de Ensino Superior. Florianpolis, 2001. 137 f. Dissertao (Mestrado em Engenharia de Produo) Departamento de Engenharia de Produo, Universidade Federal de Santa Catarina. DWBRASIL. Data Mart. Disponvel <http://www.dwbrasil.com.br/html/dmart.html>. Acesso em 01/07/2001. em

FALSARELLA, O. M. e CHAVES, E. O. C. Sistemas de Informao e Sistemas de Apoio Deciso. Disponvel em: <http://chaves.com.br/TEXTSELF/COMPUT/sad.htm> Acesso em 21/06/2001. FIRESTONE, J. M. Architectural Evolution in Data Warehousing and Distributed Knowledge Management Architecture. Disponvel em: <http://www.dkms.com/ARCHEV.html>. Acesso em 20/08/2001. FREITAS, H. e POZZEBOM, M. Caractersticas Desejveis de um EIS Enterprise Information System Rumo a Proatividade. PPGA Universidade Federal do Rio Grande do Sul. Disponvel em: <http://read.adm.ufrgs.br/read05.artigo.eis.htm> Acesso em: 10/11/2000. FURLAN, J. D.; IVO, I. M. e AMARAL, F. P. Sistemas de Informao Executiva EIS. So Paulo: Makron Books, 1994. GUPTA, V. R. An Introduction to Data Warehousing. Disponvel em: <http://system-services.com/dwintro.asp>. Acesso em 01/07/2001. HARRISON, Thomas. Intranet Data Warehouse. So Paulo: Berkeley, 1998. INMON, W. H. Como Construir o Data Warehouse. Rio de Janeiro: Campus, 1997. KAN, S. H. K. Metrics and Models in Software Quality Engineering. Massachusetts: Addison-Wesley, 1998. KIMBALL, R. Data Warehouse Toolkit. Makron Books: So Paulo, 1998a.

84 KIMBALL, R. The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing Data Warehouses. New York: Wiley Computer Publishing, 1998b. KROENKE, D. M. Banco de Dados: Fundamentos, Projeto e Implementao 6a. Edio. Rio de Janeiro: Livros Tcnicos e Cientficos, 1999. LAUDON, K. C. e LAUDON, J. P. Sistemas de Informao. Rio de Janeiro: Livros Tcnicos e Cientficos: 1998. MACHADO, F. N. R. e ABREU, M. P. Projeto de Banco de Dados: Uma Viso Prtica. So Paulo: rica, 1996. MACHADO, F. N. R. Projeto de Data Warehouse: Uma Viso Multidimensional. So Paulo: rica, 2000. PRESSMAN. R. S. Engenharia de Software. So Paulo: Makron Books, 1995. SELL, D. Uma Arquitetura para Distribuio de Componentes Tecnolgicos de Sistemas de Informaes Baseados em Data Warehouse. Florianpolis, 2001. 89 f. Dissertao (Mestrado em Engenharia de Produo) Departamento de Engenharia de Produo e Sistemas, Universidade Federal de Santa Catarina. SINGH, H. S. Data Warehouse. Conceitos, Tecnologias, Implementao e Gerenciamento. So Paulo. Makron Books, 2001. SPRAGUE, R. H. JR. e WATSON, H. J. Sistema de apoio deciso: colocando a teoria em prtica. Rio de Janeiro: Campus, 1991. STAIR, R. M. Princpios de sistemas de informao, uma abordagem gerencial. Rio de Janeiro: Livros Tcnicos e Cientficos, 1998. VASCONCELLOS, J. M. Implementando um Data Warehouse Incremental. DEVELOPERS CIO MAGAZINE, Rio de Janeiro, n.38, p. 18-20, abr. 1999.

85

ANEXO

SCRIPTS

PARA

CRIAO

DO

PROTOTIPO

RELACIONAL
/* Table: TBLCATEGORIA, Owner: SYSDBA */ CREATE TABLE TBLCATEGORIA ( PKCATEGORIA INTEGER NOT NULL, VARCHAR(10), NOMECATEGORIA ); /* Table: TBLCIDADE, Owner: SYSDBA */ CREATE TABLE TBLCIDADE ( PKCIDADE INTEGER NOT NULL, NOMECIDADE FKESTADO ); ALTER TABLE TBLCIDADE ADD FOREIGN KEY (FKESTADO) REFERENCES TBLESTADO (PKESTADO); /* Table: TBLDEPARTAMENTO, Owner: SYSDBA */ CREATE TABLE TBLDEPARTAMENTO ( PKDEPARTAMENTO INTEGER NOT NULL, VARCHAR(20), NOMEDEPARTAMENTO ); /* Table: TBLESTADO, Owner: SYSDBA */ VARCHAR(20), INTEGER NOT NULL,

PRIMARY KEY (PKCATEGORIA)

PRIMARY KEY (PKCIDADE)

PRIMARY KEY (PKDEPARTAMENTO)

86

CREATE TABLE TBLESTADO ( PKESTADO SIGLAESTADO NOMEESTADO ); /* Table: TBLLOJA, Owner: SYSDBA */ CREATE TABLE TBLLOJA ( PKLOJA INTEGER NOT NULL, VARCHAR(20), INTEGER, NOMELOJA FKESTADO INTEGER NOT NULL, CHAR(2), VARCHAR(20),

PRIMARY KEY (PKESTADO)

FKCIDADE INTEGER, FKPLANTA INTEGER, PRIMARY KEY (PKLOJA) ); ALTER TABLE TBLLOJA ADD FOREIGN KEY (FKCIDADE) REFERENCES TBLCIDADE (PKCIDADE); ALTER TABLE TBLLOJA ADD FOREIGN KEY (FKESTADO) REFERENCES TBLESTADO (PKESTADO); ALTER TABLE TBLLOJA ADD FOREIGN KEY (FKPLANTA) REFERENCES TBLPLANTA (PKPLANTA); /* Table: TBLMARCA, Owner: SYSDBA */ CREATE TABLE TBLMARCA ( PKMARCA INTEGER NOT NULL, NOMEMARCA ); VARCHAR(20), PRIMARY KEY (PKMARCA)

87

/* Table: TBLPLANTA, Owner: SYSDBA */ CREATE TABLE TBLPLANTA ( PKPLANTA INTEGER NOT NULL, NOMETIPOPLANTA ); /* Table: TBLPRODUTO, Owner: SYSDBA */ CREATE TABLE TBLPRODUTO ( PKPRODUTO INTEGER NOT NULL, NOMEPRODUTO VARCHAR(30), FKMARCA INTEGER, FKSUBCATEGORIA FKDEPARTAMENTO ); ALTER TABLE TBLPRODUTO ADD FOREIGN KEY (FKMARCA) REFERENCES TBLMARCA (PKMARCA); ALTER TABLE TBLPRODUTO ADD FOREIGN KEY (FKSUBCATEGORIA) REFERENCES TBLSUBCATEGORIA (PKSUBCATEGORIA); ALTER TABLE TBLPRODUTO ADD FOREIGN KEY (FKDEPARTAMENTO) REFERENCES TBLDEPARTAMENTO (PKDEPARTAMENTO); /* Table: TBLSUBCATEGORIA, Owner: SYSDBA */ CREATE TABLE TBLSUBCATEGORIA ( PKSUBCATEGORIA INTEGER NOT NULL, INTEGER, INTEGER, VARCHAR(10), PRIMARY KEY (PKPLANTA)

PRIMARY KEY (PKPRODUTO)

88

NOMESUBCATEBOGORIA FKCATEGORIA ); INTEGER,

VARCHAR(20),

PRIMARY KEY (PKSUBCATEGORIA) ALTER TABLE TBLSUBCATEGORIA ADD FOREIGN KEY (FKCATEGORIA) REFERENCES TBLCATEGORIA (PKCATEGORIA); /* Table: TBLVENDAS, Owner: SYSDBA */ CREATE TABLE TBLVENDAS ( PKVENDAS FKPRODUTO FKLOJA RECEITA CUSTO ); ALTER TABLE TBLVENDAS ADD FOREIGN KEY (FKPRODUTO) REFERENCES TBLPRODUTO (PKPRODUTO); ALTER TABLE TBLVENDAS ADD FOREIGN KEY (FKLOJA) REFERENCES TBLLOJA (PKLOJA); SET TERM ^ ; /* Triggers only will work for SQL triggers */ CREATE TRIGGER INSVENDAS FOR TBLVENDAS ACTIVE BEFORE INSERT POSITION 0 As Begin new.PkVendas = Gen_Id(GenPkVendas,1); End ^ INTEGER NOT NULL, INTEGER,

INTEGER, NUMERIC(15, 2), NUMERIC(15, 2),

UNIDADES INTEGER,

PRIMARY KEY (PKVENDAS)

89

COMMIT WORK ^ SET TERM ;^

90

ANEXO B - SCRIPTS PARA CRIAO DO PROTTIPO EM ESTRELA /* Table: TBLDIMLOJA, Owner: SYSDBA */ CREATE TABLE TBLDIMLOJA ( PKLOJA INTEGER NOT NULL, NOMELOJA VARCHAR(20), CHAR(2), NOMECIDADE VARCHAR(20), SIGLAESTADO PLANTA VARCHAR(20), PRIMARY KEY (PKLOJA) );
/* Table: TBLDIMPRODUTO, Owner: SYSDBA */ CREATE TABLE TBLDIMPRODUTO ( PKPRODUTO NOMEMARCA INTEGER NOT NULL, VARCHAR(20), VARCHAR(20), VARCHAR(20), NOMEPRODUTO VARCHAR(20), NOMESUBCATEGORIA VARCHAR(20), NOMECATEGORIA NOMEDEPARTAMENTO PRIMARY KEY (PKPRODUTO) ); /* Table: TBLDIMPROMOCAO, Owner: SYSDBA */ CREATE TABLE TBLDIMPROMOCAO ( PKPROMOCAO INTEGER NOT NULL,

91

NOMEPROMOCAO TIPODEPRECO TIPODEANUNCIO

VARCHAR(30), VARCHAR(20),

VARCHAR(20),

TIPODEDISPLAY VARCHAR(20), TIPODECUPOM VARCHAR(20), DATAINICIO DATATERMINO ); /* Table: TBLDIMTEMPO, Owner: SYSDBA */ CREATE TABLE TBLDIMTEMPO ( PKTEMPO INTEGER NOT NULL, DATA TIMESTAMP, VARCHAR(9), SMALLINT, DIADASEMANA TIMESTAMP, TIMESTAMP,

PRIMARY KEY (PKPROMOCAO)

DIANOMES SMALLINT, DIASCORRIDOSNOANO SEMANANOANO SMALLINT, NUMERODASEMANA MES INTEGER, NUMEROTRIMESTRE ANO SMALLINT, INDICADORFERIADO ); /* Table: TBLFATOVENDAS, Owner: SYSDBA */ CREATE TABLE TBLFATOVENDAS ( PKVENDAS FKPROMOCAO FKPRODUTO INTEGER NOT NULL, INTEGER, INTEGER, FKTEMPO INTEGER, CHAR(1), PRIMARY KEY (PKTEMPO) SMALLINT, SMALLINT,

92

FKLOJA RECEITA CUSTO );

INTEGER, NUMERIC(15, 2), NUMERIC(15, 2),

UNIDADES INTEGER,

PRIMARY KEY (PKVENDAS) ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKTEMPO) REFERENCES TBLDIMTEMPO (PKTEMPO); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKPROMOCAO) REFERENCES TBLDIMPROMOCAO (PKPROMOCAO); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKPRODUTO) REFERENCES TBLDIMPRODUTO (PKPRODUTO); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKLOJA) REFERENCES TBLDIMLOJA (PKLOJA); SET TERM ^ ; /* Triggers only will work for SQL triggers */ CREATE TRIGGER INSFATOVENDAS FOR TBLFATOVENDAS ACTIVE BEFORE INSERT POSITION 0 As Begin new.PkVendas = Gen_Id(GenPkVendas,1); End ^ COMMIT WORK ^ SET TERM ;^

93

ANEXO C - SCRIPTS PARA CRIAO DO PROTTIPO HBRIDO

/* Table: TBLDIMCATEGORIA, Owner: SYSDBA */ CREATE TABLE TBLDIMCATEGORIA ( PKCATEGORIA INTEGER NOT NULL, VARCHAR(10), NOMECATEGORIA ); /* Table: TBLDIMCIDADE, Owner: SYSDBA */ CREATE TABLE TBLDIMCIDADE ( PKCIDADE INTEGER NOT NULL, NOMECIDADE FKESTADO ); ALTER TABLE TBLDIMCIDADE ADD FOREIGN KEY (FKESTADO) REFERENCES TBLDIMESTADO (PKESTADO); /* Table: TBLDIMDEPARTAMENTO, Owner: SYSDBA */ CREATE TABLE TBLDIMDEPARTAMENTO ( PKDEPARTAMENTO INTEGER NOT NULL, VARCHAR(20), NOMEDEPARTAMENTO ); /* Table: TBLDIMESTADO, Owner: SYSDBA */ CREATE TABLE TBLDIMESTADO VARCHAR(20), INTEGER NOT NULL,

PRIMARY KEY (PKCATEGORIA)

PRIMARY KEY (PKCIDADE)

PRIMARY KEY (PKDEPARTAMENTO)

94

( PKESTADO SIGLAESTADO NOMEESTADO ); /* Table: TBLDIMLOJA, Owner: SYSDBA */ CREATE TABLE TBLDIMLOJA ( PKLOJA INTEGER NOT NULL, VARCHAR(20), INTEGER, NOMELOJA FKESTADO INTEGER NOT NULL, CHAR(2), VARCHAR(20),

PRIMARY KEY (PKESTADO)

FKCIDADE INTEGER, FKPLANTA INTEGER, PRIMARY KEY (PKLOJA) ); ALTER TABLE TBLDIMLOJA ADD FOREIGN KEY (FKCIDADE) REFERENCES TBLDIMCIDADE (PKCIDADE); ALTER TABLE TBLDIMLOJA ADD FOREIGN KEY (FKESTADO) REFERENCES TBLDIMESTADO (PKESTADO); ALTER TABLE TBLDIMLOJA ADD FOREIGN KEY (FKPLANTA) REFERENCES TBLDIMPLANTA (PKPLANTA); /* Table: TBLDIMMARCA, Owner: SYSDBA */ CREATE TABLE TBLDIMMARCA ( PKMARCA INTEGER NOT NULL, NOMEMARCA ); VARCHAR(20), PRIMARY KEY (PKMARCA)

95 /* Table: TBLDIMPLANTA, Owner: SYSDBA */ CREATE TABLE TBLDIMPLANTA ( PKPLANTA INTEGER NOT NULL, NOMETIPOPLANTA ); /* Table: TBLDIMPRODUTO, Owner: SYSDBA */ CREATE TABLE TBLDIMPRODUTO ( PKPRODUTO INTEGER NOT NULL, NOMEPRODUTO VARCHAR(30), FKMARCA INTEGER, FKSUBCATEGORIA FKDEPARTAMENTO ); ALTER TABLE TBLDIMPRODUTO ADD FOREIGN KEY (FKMARCA) REFERENCES TBLDIMMARCA (PKMARCA); ALTER TABLE TBLDIMPRODUTO ADD FOREIGN KEY (FKSUBCATEGORIA) REFERENCES TBLDIMSUBCATEGORIA (PKSUBCATEGORIA); ALTER TABLE TBLDIMPRODUTO ADD FOREIGN KEY (FKDEPARTAMENTO) REFERENCES TBLDIMDEPARTAMENTO (PKDEPARTAMENTO); /* Table: TBLDIMPROMOCAO, Owner: SYSDBA */ CREATE TABLE TBLDIMPROMOCAO ( PKPROMOCAO TIPODEPRECO INTEGER NOT NULL, VARCHAR(30), VARCHAR(20), NOMEPROMOCAO INTEGER, INTEGER, VARCHAR(10), PRIMARY KEY (PKPLANTA)

PRIMARY KEY (PKPRODUTO)

96

TIPODEANUNCIO

VARCHAR(20),

TIPODEDISPLAY VARCHAR(20), TIPODECUPOM VARCHAR(20), DATAINICIO DATATERMINO ); /* Table: TBLDIMSUBCATEGORIA, Owner: SYSDBA */ CREATE TABLE TBLDIMSUBCATEGORIA ( PKSUBCATEGORIA FKCATEGORIA ); ALTER TABLE TBLDIMSUBCATEGORIA ADD FOREIGN KEY (FKCATEGORIA) REFERENCES TBLDIMCATEGORIA (PKCATEGORIA); /* Table: TBLDIMTEMPO, Owner: SYSDBA */ CREATE TABLE TBLDIMTEMPO ( PKTEMPO INTEGER NOT NULL, DATA TIMESTAMP, VARCHAR(9), SMALLINT, DIADASEMANA INTEGER NOT NULL, VARCHAR(20), NOMESUBCATEBOGORIA INTEGER, TIMESTAMP, TIMESTAMP,

PRIMARY KEY (PKPROMOCAO)

PRIMARY KEY (PKSUBCATEGORIA)

DIANOMES SMALLINT, DIASCORRIDOSNOANO SEMANANOANO SMALLINT, NUMERODASEMANA MES INTEGER, NUMEROTRIMESTRE ANO SMALLINT, SMALLINT, SMALLINT,

97

INDICADORFERIADO );

CHAR(1),

PRIMARY KEY (PKTEMPO)

/* Table: TBLFATOVENDAS, Owner: SYSDBA */ CREATE TABLE TBLFATOVENDAS ( PKVENDAS FKPROMOCAO FKPRODUTO FKLOJA FKCATEGORIA INTEGER NOT NULL, INTEGER, INTEGER, INTEGER, INTEGER, FKTEMPO INTEGER,

INTEGER,

FKSUBCATEGORIA FKMARCA INTEGER, FKPLANTA INTEGER, FKESTADO

INTEGER, INTEGER,

FKCIDADE INTEGER, FKDEPARTAMENTO UNIDADES INTEGER, RECEITA CUSTO NUMERIC(15, 2), NUMERIC(15, 2), VARCHAR(9),

IDENTOPERACAO );

PRIMARY KEY (PKVENDAS) ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKTEMPO) REFERENCES TBLDIMTEMPO (PKTEMPO); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKPROMOCAO) REFERENCES TBLDIMPROMOCAO (PKPROMOCAO); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKPRODUTO) REFERENCES TBLDIMPRODUTO (PKPRODUTO); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKLOJA) REFERENCES TBLDIMLOJA (PKLOJA);

98

ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKCATEGORIA) REFERENCES TBLDIMCATEGORIA (PKCATEGORIA); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKSUBCATEGORIA) REFERENCES TBLDIMSUBCATEGORIA (PKSUBCATEGORIA); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKMARCA) REFERENCES TBLDIMMARCA (PKMARCA); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKPLANTA) REFERENCES TBLDIMPLANTA (PKPLANTA); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKESTADO) REFERENCES TBLDIMESTADO (PKESTADO); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKCIDADE) REFERENCES TBLDIMCIDADE (PKCIDADE); ALTER TABLE TBLFATOVENDAS ADD FOREIGN KEY (FKDEPARTAMENTO) REFERENCES TBLDIMDEPARTAMENTO (PKDEPARTAMENTO); SET TERM ^ ; /* Triggers only will work for SQL triggers */ CREATE TRIGGER INSFATOVENDAS FOR TBLFATOVENDAS ACTIVE BEFORE INSERT POSITION 0 As Begin new.PkVendas = Gen_Id(GenPkVendas,1); End ^ COMMIT WORK ^ SET TERM ;^

99

ANEXO D SCRIPTS DE CARGA DOS CUBOS DE DECISO

/* Modelo relacional /* SELECT Tblloja.NOMELOJA, Tblcidade.NOMECIDADE, Tblestado.SIGLAESTADO, Tblproduto.NOMEPRODUTO, marca.NOMEMARCA, Tbldepartamento.NOMEDEPARTAMENTO, Tblcategoria.NOMECATEGORIA, Tblsubcategoria.NOMESUBCATEBOGORIA, SUM( Tblvendas.UNIDADES ), SUM( Tblvendas.RECEITA ), SUM( Tblvendas.CUSTO ), COUNT( Tblvendas.UNIDADES ), COUNT( Tblvendas.RECEITA ), COUNT( Tblvendas.CUSTO ), COUNT( * ) COUNTALL FROM TBLVENDAS Tblvendas INNER JOIN TBLLOJA Tblloja ON (Tblloja.PKLOJA = Tblvendas.FKLOJA) INNER JOIN TBLPRODUTO Tblproduto ON (Tblproduto.PKPRODUTO = Tblvendas.FKPRODUTO) INNER JOIN TBLCIDADE Tblcidade ON (Tblcidade.PKCIDADE = Tblloja.FKCIDADE) INNER JOIN TBLMARCA Tblmarca ON (Tblmarca.PKMARCA = Tblproduto.FKMARCA) INNER JOIN TBLDEPARTAMENTO Tbldepartamento ON (Tbldepartamento.PKDEPARTAMENTO = Tblproduto.FKDEPARTAMENTO) INNER JOIN TBLSUBCATEGORIA Tblsubcategoria ON (Tblsubcategoria.PKSUBCATEGORIA = Tblproduto.FKSUBCATEGORIA) INNER JOIN TBLESTADO TBLESTADO ON (Tblestado.PKESTADO = Tblcidade.FKESTADO) INNER JOIN TBLCATEGORIA Tblcategoria ON (Tblcategoria.PKCATEGORIA = Tblsubcategoria.FKCATEGORIA) GROUP BY Tblloja.NOMELOJA, Tblcidade.NOMECIDADE, Tblestado.SIGLAESTADO, Tblproduto.NOMEPRODUTO, Tblmarca.NOMEMARCA, Tbldepartamento.NOMEDEPARTAMENTO, Tblcategoria.NOMECATEGORIA, Tblsubcategoria.NOMESUBCATEBOGORIA /* Modelo Dimensional */

100

SELECT Tbldimloja.NOMELOJA, Tbldimloja.NOMECIDADE, Tbldimloja.SIGLAESTADO, Tbldimloja.PLANTA, Tbldimproduto.NOMEPRODUTO, Tbldimproduto.NOMEMARCA, Tbldimproduto.NOMESUBCATEGORIA, Tbldimproduto.NOMECATEGORIA, Tbldimproduto.NOMEDEPARTAMENTO, SUM( Tblfatovendas.UNIDADES ), SUM( Tblfatovendas.RECEITA ), SUM( Tblfatovendas.CUSTO ), COUNT( Tblfatovendas.UNIDADES ), COUNT( Tblfatovendas.RECEITA ), COUNT( Tblfatovendas.CUSTO ) FROM TBLFATOVENDAS Tblfatovendas INNER JOIN TBLDIMLOJA Tbldimloja ON (Tbldimloja.PKLOJA = Tblfatovendas.FKLOJA) INNER JOIN TBLDIMPRODUTO Tbldimproduto ON (Tbldimproduto.PKPRODUTO = Tblfatovendas.FKPRODUTO) GROUP BY Tbldimloja.NOMELOJA, Tbldimloja.NOMECIDADE, Tbldimloja.SIGLAESTADO, Tbldimloja.PLANTA, Tbldimproduto.NOMEPRODUTO, Tbldimproduto.NOMEMARCA, Tbldimproduto.NOMESUBCATEGORIA, Tbldimproduto.NOMECATEGORIA, Tbldimproduto.NOMEDEPARTAMENTO /* Modelo hbrido /* SELECT Tbldimproduto.NOMEPRODUTO, Tbldimloja.NOMELOJA, Tbldimcategoria.NOMECATEGORIA, Tbldimsubcategoria_1.NOMESUBCATEBOGORIA, Tbldimmarca.NOMEMARCA, Tbldimplanta.NOMETIPOPLANTA, Tbldimestado.SIGLAESTADO, Tbldimcidade.NOMECIDADE, Tbldimdepartamento.NOMEDEPARTAMENTO, SUM( Tblfatovendas_1.CUSTO ), SUM( Tblfatovendas_1.UNIDADES ), SUM( Tblfatovendas_1.RECEITA ), COUNT( Tblfatovendas_1.CUSTO ), COUNT( Tblfatovendas_1.UNIDADES ), COUNT( Tblfatovendas_1.RECEITA ) FROM TBLFATOVENDAS Tblfatovendas_1 INNER JOIN TBLDIMPRODUTO Tbldimproduto ON (Tbldimproduto.PKPRODUTO = Tblfatovendas_1.FKPRODUTO) INNER JOIN TBLDIMLOJA Tbldimloja ON (Tbldimloja.PKLOJA = Tblfatovendas_1.FKLOJA) INNER JOIN TBLDIMCATEGORIA Tbldimcategoria ON (Tbldimcategoria.PKCATEGORIA = Tblfatovendas_1.FKCATEGORIA)

101

INNER JOIN TBLDIMSUBCATEGORIA Tbldimsubcategoria_1 ON (Tbldimsubcategoria_1.PKSUBCATEGORIA = Tblfatovendas_1.FKSUBCATEGORIA) INNER JOIN TBLDIMMARCA Tbldimmarca ON (Tbldimmarca.PKMARCA = Tblfatovendas_1.FKMARCA) INNER JOIN TBLDIMPLANTA Tbldimplanta ON (Tbldimplanta.PKPLANTA = Tblfatovendas_1.FKPLANTA) INNER JOIN TBLDIMESTADO Tbldimestado ON (Tbldimestado.PKESTADO = Tblfatovendas_1.FKESTADO) INNER JOIN TBLDIMCIDADE Tbldimcidade ON (Tbldimcidade.PKCIDADE = Tblfatovendas_1.FKCIDADE) INNER JOIN TBLDIMDEPARTAMENTO Tbldimdepartamento ON (Tbldimdepartamento.PKDEPARTAMENTO = Tblfatovendas_1.FKDEPARTAMENTO) GROUP BY Tbldimproduto.NOMEPRODUTO, Tbldimloja.NOMELOJA, Tbldimcategoria.NOMECATEGORIA, Tbldimsubcategoria_1.NOMESUBCATEBOGORIA, Tbldimmarca.NOMEMARCA, Tbldimplanta.NOMETIPOPLANTA, Tbldimestado.SIGLAESTADO, Tbldimcidade.NOMECIDADE, Tbldimdepartamento.NOMEDEPARTAMENTO