Академический Документы
Профессиональный Документы
Культура Документы
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
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
Banca Examinadora
Prof. Aran Bey Tcholakian Morales, Dr. Universidade Federal de Santa Catarina Orientador
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.
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
15
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.
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
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.
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).
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).
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
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).
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
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).
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
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
30
31
Application Messaging
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.
32
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
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
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.
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 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.
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
Fonte: MACHADO, F. N. Projeto de Data Warehouse: uma viso multidimensional. Rio de Janeiro: Editora rica, p. 66, 2000.
39
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.
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).
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).
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
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
Fatos
Quem
O que
Fonte: MACHADO, F. N. Projeto de Data Warehouse: Uma Viso Multidimensional. So Paulo: rica, 2000, p. 95.
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).
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.
Grupo Diagn ost ico Ch ave_Grup o_ Diagn ost ico Ch ave_Diagno st 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.
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
Fonte: Adaptado de HARRISON, T. H. Intranet Data Warehouse. So Paulo: Berkeley, p. 72, 1998.
Fonte: Adaptado de HARRISON, T. H. Intranet Data Warehouse. So Paulo: Berkeley, p. 74, 1998.
53
Fonte: Adaptado de HARRISON, T. H. Intranet Data Warehouse. So Paulo: Berkeley, p. 75, 1998.
54
normalmente relacionadas ao trabalho do conhecimento, como a possibilidade de lucro ou no de uma categoria de produtos ou oportunidades de negcio.
Esttica at a reciclagem adequada Simples; adequada para computao anlise empresarial Moderada a baixa Acessados manipulados atualizao direta e sem
Campo a campo
Uso
55
Fonte: SINGH, H. S. Data Warehouse. Conceitos, Tecnologias, Implementao e Gerenciamento. So Paulo. Makron Books, 2001, p 153-154.
56
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.
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
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.
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.
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
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
66
DimTempo Data DiaSemana DiaNoMes DiasCorridos SamanaNoAno NumeroMes NumeroTrimestre IndicadorFeriado IdentConsolidadoSN
. 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.
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
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
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
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
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.
73
Fonte: Adaptado de KIMBALL, R. Data Warehouse Toolkit. So Paulo: Makron Books, 1998.
74
75
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.
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.
78
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
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.
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,
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),
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)
88
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,
UNIDADES INTEGER,
89
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
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,
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
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
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),
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)
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,
DIANOMES SMALLINT, DIASCORRIDOSNOANO SEMANANOANO SMALLINT, NUMERODASEMANA MES INTEGER, NUMEROTRIMESTRE ANO SMALLINT, SMALLINT, SMALLINT,
97
INDICADORFERIADO );
CHAR(1),
/* Table: TBLFATOVENDAS, Owner: SYSDBA */ CREATE TABLE TBLFATOVENDAS ( PKVENDAS FKPROMOCAO FKPRODUTO FKLOJA FKCATEGORIA INTEGER NOT NULL, INTEGER, INTEGER, INTEGER, INTEGER, FKTEMPO INTEGER,
INTEGER,
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
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