Upload
vuongminh
View
214
Download
0
Embed Size (px)
Citation preview
I
UNIVERSIDADE DO VALE DO ITAJAÍ
Ivo José Soares Junkes
SISTEMA DE APOIO GERENCIAL BASEADO EM OLAP APLICADO NA JUNIOR INDÚSTRIA E COMERCIO LTDA.:
Área de Sistema de Informação
Florianópolis (SC) 2006
ii
Ivo José Soares Junkes
SISTEMA DE INFORMAÇÃO GERENCIAL BASEADO EM OLAP
APLICADO NA JUNIOR INDUSTRIA E COMERCIO LTDA.: Área de Sistema de Informação
Trabalho de conclusão de curso apresentado como requisito parcial para obtenção do título de bacharel em Ciências da Computação na Universidade do Vale do Itajaí, centro de educação São José.
Prof. Msc.. Luiz Eduardo Perfeito Nunes
Florianópolis (SC) 2006
iii
RESUMO
Este trabalho teve por objetivo desenvolver um projeto de Sistemas de Apoio à Decisão Baseado em OLAP, com aplicação prática na empresa JUNIOR Indústria e Comercio. O trabalho utilizou conceitos de sistemas de informação e tecnologia OLAP aplicados em um banco de dados multidimensional, permitindo ao usuário/gestor elaborar e executar consultas de uma maneira simples. O projeto foi focado na área considerada mais importante pela empresa para tomada de decisão, a área comercial, utilizando informações geradas por meio da grande quantidade de dados obtidos diariamente, que, muitas vezes, são desperdiçados devido à falta de uma ferramenta adequada para transformá-los em informação. Os dados relacionais digitados serão exportados diariamente, conforme modelagem para um banco multidimensional. O acesso às consultas pré-formatadas foi feito por meio do banco multidimensional. Na fundamentação teórica deste trabalho, foram vistos conceitos de sistemas, banco multidimensional e Data Mart, que deram subsídios para a realização e modelagem dos Sistemas de Apoio à Decisão Baseado em OLAP da JUNIOR.
Palavras-chave: OLAP. Multidimensional, Data Mart, Cubo.
iv
ABSTRACT
This work has for objective to create a project of systems of support the decision based on olap with application practises in company JUNIOR Industria e Comercio LTDA. The work will use concepts of information systems and technology olap applied in a multidimensional data base, allowing the user to elaborate and to execute consultations in a simple way. The project will be acting in the area considered more important for the company for decision taking, the commercial area, using information generated through the great amount of gotten data daily that, many times, are wasted due to lack of an adjusted tool to transform them into information. The typed relationary data daily will be exported daily in agreement modeling to a multidimensional bank. The access the formatted consultations daily pay will be made by means of the multidimensional bank. In the theoretical recital of this work concepts of systems, multidimensional bank and mart date will be seen that will give to subsidies for the accomplishment and modeling of the systems of support the decision based on olap of the JUNIOR.
v
LISTA DE FIGURAS
FIGURA 1 – COMPONENTES DE UM SISTEMA.............................................................. 19
FIGURA 2 - CLASSIFICAÇÃO DOS PROBLEMAS DE DECISÃO.................................... 22
FIGURA 3 - DIAGRAMA DOS NÍVEIS HIERÁRQUICOS DA INFORMAÇÃO ............. 28
FIGURA 4 – MODELO DE DATA WATREHOUSE........................................................... 32
FIGURA 5 – NÍVEIS DE GRANULARIDADE .................................................................... 34
FIGURA 6 – TABELA DE FATO E DIMENSÕES............................................................... 38
FIGURA 7 – DIMENSÃO E NÍVEL ..................................................................................... 39
FIGURA 8 – CUBO COM AS DIMENSÕES PRODUTO TEMPO E VENDAS...... 40
FIGURA 9 – EXEMPLO DE OPERAÇÃO ROLL UP.............................................. 42
FIGURA 10 – EXEMPLO DE OPERAÇÃO DRILL DOWN.................................... 43
FIGURA 11 – EXEMPLO DE OPERAÇÃO SLICE.................................................. 44
FIGURA 12 – EXEMPLO DE OPERAÇÃO DICE................................................... 44
FIGURA 13 – MODELO INTEGRADO DE INFORMAÇÕES .......................................... 56
FIGURA 14 – METODOLOGIA PARA SISTEMA DE INFORMAÇÃO .......................... 57
FIGURA 15 – COMPONENTES DA FASE DE PLANEJAMENTO................................... 57
FIGURA 16 – OBJETIVOS DA FASE DE PLANEJAMENTO .......................................... 59
FIGURA 17 – OBJETIVOS DA FASE DE PROJETO ............................................... 64
FIGURA 18 – FASE DE IMPLEMENTAÇÃO ......................................................... 65
FIGURA 19 – MODELO GERAL PROPOSTO.......................................................... 68
vi
FIGURA 20 – ORGANOGRAMA FUNCIONAL DO SISTEMA.............................. 71
FIGURA 21 – USE CASE GENÉRICO ............................................................................... 73 FIGURA 22 – DESENVOLVIMENTO ............................................................................... 74 FIGURA 23 – ADMINISTRAÇÃO DO SISTEMA ............................................................ 74 FIGURA 24 – CONSULTAS DO SISTEMA ...................................................................... 75 FIGURA 25 – SHEDULE .................................................................................................... 75 FIGURA 26 – DTS DESENVOLVIDO PARA A JUNIOR ................................................ 76 FIGURA 27 – LIMPAR TABELA ...................................................................................... 76 FIGURA 28 – CUBO JUNIOR.............................................................................................. 81 FIGURA 29 – CONSULTA PREÇO MÍNIMO..................................................................... 82 FIGURA 30 – CONSULTA CRÉDITO................................................................................. 82
vii
LISTA DE ABREVIATURAS
DOLAP Database OLAP e Desktop OLAP DSS Decisions Support Services DTS Data Transformation Services ER Entidade-Relacionamento HOLAP Hybrid OLAP HTML Hypertext Markup Language MOLAP Multidimensional OLAP MROLAP Mobile and Remote OLAP OLAP On-Line Analytical Processing ROLAP Relational OLAP SAD Sistema de Apoio à Decisão SIGBO Sistema de Apoio Gerencial Baseado em OLAP SADBO Sistema de Apoio a Decisão Baseado em OLAP SGBD Sistema Gerenciador de Banco de Dados SGBDM Sistema Gerenciador de Banco de Dados Multidimensional SGBDR Sistema Gerenciador de Banco de Dados Relacional SI Sistemas de Informações SIE Sistemas de Informações Executivas SIG Sistemas de Informações Gerenciais SQL Structured Query Language TCC Trabalho de Conclusão de Curso UNIVALI Universidade do Vale do Itajaí WOLAP Web OLAP BD Banco de Dados TI Tecnologia da Informação BI Business Intelligence EIS Sistemas de Informação Executiva
8
SUMÁRIO
1. INTRODUÇÃO 04 1.1 CONTEXTUALIZAÇÃO 04 1.2 PROBLEMA 05 1.3 JUSTIFICATIVA 05 1.4 PLANO DE TRABALHO 06
1.5 CRONOGRAMA 11 1.6 OBJETIVOS 12 1.6.1 Objetivo geral 12 1.6.2 Objetivos específicos 12
1.7 ESTRUTURA DO TRABALHO 13 2. CARACTERIZAÇÃO DA EMPRESA 14 2.1 HISTÓRICO 14 3. FUNDAMENTAÇÃO TEÓRICA 16 3.1 SISTEMAS DE INFORMAÇÃO 17 3.1.1 Sistemas de apoio às operações 19 3.1.2 Sistemas de apoio gerencial 20 3.2 PROCESSO DE TOMADA DE DECISÃO 20 3.3 BUSSINESS INTELLINGENCE 26 3.4 ESTRUTURA DOS BANCOS DE DADOS 29 3.4.1 Estrutura multidimensional 29 3.4.2 Armazéns de dados 30 3.4.3 Características de um Data Warehouse 33 3.4.4 Granularidade e particionamento 34 3.4.5 Data Mart 35 3.5 MODELO MULTIDIMENTSIONAL 37 3.5.1 Fatos e medidas 38 3.5.2 Dimensões 39 3.5.3 A Visualização de um modelo multidimensional 40 3.5.4 Agregação 41 3.5.5 Operação básica de OLAP 42 3.6 OLAP - ON-LINE ANALYTICAL PROCESSING 44 3.6.1 Exemplos de OLAP 45 3.6.2 Requisitos funcionais para OLAP 46 3.7 MICROSOFT SQL SERVER 48 3.7.1 DSS - Decisions Support Services 49 3.7.2 Assistentes do DSS 50 3.7.3 Componentes do DSS 51 4. PLANEJAMENTO 52 4.1 DIAGNÓSTICO PREVIO ÁREA DE INFORMÁTICA 53 4.2 DIAGNÓSTICO PRÉVIO DA ÁREA COMERCIAL 53 4.3 DIAGNÓSTICO PRÉVIO DA ÁREA ESTRATÉGICA 54
9
5. DESENVOLVIMENTO DO SISTEMA PROPOSTO 56 5.1 INTRODUÇÃO 56 5.2. METODOLOGIA DE DESENVOLVIMENTO 56 5.3 ESPECIFICAÇÃO TECNOLÓGICA ENVOLVIDA 66 5.3.1 Níveis de segurança 68 5.3.2 Carga de dados 68 5.3.3 Resultados esperados 69 5.4 ANÁLISE FUNCIONAL 70 5.4.1 Introdução 70 5.4.2 Organograma funcional do sistema 71 5.4.3 Análise dos riscos 5.4.4 Diagramas de caso de uso 5.4.5 Estrutura do DTS 76 5.4.6 Dimensões e consultas modeladas para o cubo JUNIOR 81 6. CONSIDERAÇÕES FINAIS 83
ANEXO I – QUESTIONARIO GESTORES 85
ANEXO II – TABELAS UTILIZADAS 86
REFERÊCIAS BIBLIOGRÁFICAS 96
10
1. INTRODUÇÃO
1.1 CONTEXTUALIZAÇÃO
Há alguns anos, já está consolidado nas grandes corporações o armazenamento dos dados da
empresa através de Banco de Dados (BD), os quais, na maioria das vezes, servem somente
como apoio ao trabalho operacional da empresa, não sendo aproveitado o registro histórico
das informações para uso na estratégia e tomada de decisão da empresa. (DWINF 2005)
Os gerentes e diretores, nessa situação, tomam suas decisões baseados em suas intuições
executivas, sem considerar a evolução da empresa registrada nos dados de seus sistemas. De
acordo com uma pesquisa realizada pela Aspect International Consulting (1997), 88% (oitenta
e oito por cento) dos diretores de empresa consultados admitem que dedicam 75% (setenta
cinco por cento) de seu tempo a tomadas de decisão apoiadas em análises subjetivas, sendo
que 100% (cem por cento) deles têm acesso a computadores. Inúmeros motivos podem levar a
esse desperdício. Por exemplo, o uso de sistemas diferentes por cada setor da empresa, o que
dificulta o cruzamento de informações e a consistência das mesmas. Outro motivo seria o fato
desses sistemas estarem focados, na maioria dos casos, para uso do operacional e não estarem
preparados para responder as questões gerenciais de cada empresa. Mesmo quando todas as
informações da corporação estão centralizadas em um único Banco de Dados, o enorme
volume de dados dificulta a análise dos mesmos.
Percebendo esse problema o conceito de Data Warehouse (DW) foi introduzido, visando
filtrar os dados e organizá-los em um outro Banco de Dados (BD), paralelo ao já utilizado
pela empresa. Neste outro BD, os dados corporativos são organizados para atender as
necessidades dos gerentes e diretores da empresa. Esse processo de organização dos dados
ocorre com novos métodos de armazenamento, estruturação e novas tecnologias para geração
e recuperação das informações. Segundo Kimball (1998), DW é um conjunto de ferramentas e
técnicas de projeto, que, quando aplicadas às necessidades específicas dos usuários e aos
bancos de dados específicos, permitirá o planejamento e construção de um DW. Essas novas
tecnologias já estão bem consolidadas no mercado na forma de diversas ferramentas para
cumprir todas essas etapas.
11
Como se relatou, a ferramenta utilizada na administração do Banco de Dados é o Microsoft
SQL Server, que apresenta suporte a OLAP (On-Line Trasaction Processing – Processamento
de Transações On-Line). OLAP será um dos conceitos estudados e implementados durante a
realização deste projeto. Segundo O´Brien (2001), OLAP é a capacidade dos sistemas de
apoio à decisão em permitir aos usuários manipular e examinar de forma interativa grande
quantidade de dados detalhados e consolidados a partir de várias perspectivas. Segundo
Pereira (1999), a aplicação de técnicas OLAP pode constituir um conjunto de atividades de
consulta e apresentação de dados provenientes do DW.
1.2 PROBLEMA
A JUNIOR, por ser uma empresa atuando em um mercado extremamente competitivo,
necessita tomar decisões, principalmente na área comercial, de forma rápida e o mais
confiável possível. Atualmente, as decisões são tomadas baseadas em relatórios relacionais
retirados do Sistema de Gestão MICROSIGA. Este processo é lento e burocrático, impedindo
os executivos de tomarem suas decisões baseadas em relatórios específicos ou dinâmicos.
Sendo assim este trabalho teve por objetivo desenvolver um sistema de informações baseado
nestas necessidades e focado na área comercial aonde o gestor verificará as informações
necessárias para a administração da área comercial , acessando o excel como ferramenta de
usuário.
1.3 JUSTIFICATIVA
Este trabalho se justifica em nível de Trabalho de Conclusão de Curso para o Curso de
Ciência da Computação por se tratar do estudo e implementação de conceitos de DW, DM
entre outros, que fazem parte das necessidades de grande parte das corporações que procuram
vantagens competitivas para melhorar ou assegurar um bom desempenho frente seus cliente e
ou concorrentes. Durante a execução deste trabalho, algumas tecnologias e ferramentas de
grande importância serão revisadas e estudadas como, por exemplo, MS SQL Server,
tratamento de dados, administração de BD entre outros. O desenvolvimento de um Data Mart
focado no comercial da empresa será de grande importância para análise em busca da
minimização de problemas e na geração de informações que auxiliam os gestores no processo
de tomada de decisão.
12
1.4 PLANO DE TRABALHO
Este projeto de pesquisa foi executado em cinco etapas: (1) estudo, (2) modelagem,
(3) desenvolvimento, (4) validação e (5) documentação. As etapas de estudo e de modelagem
serão efetivadas no TCC I, sendo que as etapas de desenvolvimento, validação e
documentação foram efetivadas no TCC II.
Etapa 1: Estudo. Durante essa etapa serão estudados os conceitos envolvidos no projeto e alguns exemplos de projetos já implementados a respeito de DW.
A t i v i d a d e 1.1 Descrição Estudar os conceitos e exemplos relacionados
à área Descrição do recurso Qtd.Recursos
necessários • Microcomputador PC com acesso à Internet 01
Pré-requisitos • Nenhum
Metodologia O estudo dos conceitos será feito através de livros de autores especializados no assunto e artigos científicos encontrados em anais de eventos e/ou sites da Internet. A mesma dinâmica será usada para buscar estudos de casos na área. Somente serão utilizadas informações de procedência segura e que apresentem características e qualidade necessárias para tanto.
Indicador físico Documento textual com os conceitos estudados. Duração 08 semanas Etapa 2: Modelagem. Esta etapa procura levantar os dados técnicos necessários para o Desenvolvimento do projeto, criando um modelo conceitual do mesmo.
A t i v i d a d e 2.1 Descrição Identificar as necessidades de informações
executivas para tomada de decisão Descrição do recurso Qtd.Recursos
necessários • Microcomputador PC com acesso à Internet 01
Pré-requisitos • Atividade 1.1
Metodologia Através de entrevistas com os gerentes e diretores da empresa serão definidas as necessidades executivas que devem ser respondidas pelo DM.
13
Indicador físico Documento textual com as informações colhidas e as necessidades definidas.
Duração 02 semanas A t i v i d a d e 2.2 Descrição Construir o Modelo Dimensional, baseado em
tecnologia OLAP Descrição do recurso Qtd.Recursos
necessários • Microcomputador PC • Microsoft SQL Server 2000 ou superior
01 01
Pré-requisitos • Atividade 2.1
Metodologia Definir a granularidade dos dados, as tabelas de dimensão e os fatos que darão suporte as informações gerenciais definidas na Atividade 2.1.
Indicador físico Documento textual com as informações desenvolvidas. Duração 04 semanas A t i v i d a d e 2.3 Descrição Identificar as fontes de dados
Descrição do recurso Qtd.Recursos necessários • Microcomputador PC
• Microsoft SQL Server 2000 ou superior 01 01
Pré-requisitos • Atividade 2.2
Metodologia Identificar as tabelas do sistema MICROSIGA que serão utilizadas no DM e descrição dos dados contidos nelas.
Indicador físico Documento Textual com as informações pesquisadas. Duração 02 semanas Etapa 3: Desenvolvimento. Esta etapa visa a busca dos dados, adequação dos dados e a carga dos mesmos no DM. Sucintamente, aqui serão executados os processos estudados para se chegar ao modelo final que será validado na próxima etapa.
14
A t i v i d a d e 3.1 Descrição Implementar o Modelo Físico do DM
Descrição do recurso Qtd.Recursos necessários Microcomputador PC
• Microsoft SQL Server 2000 ou superior 01 01
Pré-requisitos • Atividade 2.3
Metodologia Construção, através do SGBD SQL Server, das tabelas que representam as dimensões e os fatos do Modelo Dimensional.
Indicador físico Apresentar Modelo Físico. Duração 04 semanas A t i v i d a d e 3.2 Descrição Preparar a área de transição de dados
(Extração, Transferência, Carga) Descrição do recurso Qtd.Recursos
necessários • Microcomputador PC • Microsoft SQL Server 2000 ou superior
01 01
Pré-requisitos • Atividade 3.1
Metodologia Nessa etapa são realizadas atividades de preparação dos dados para o DM, onde são aplicadas técnicas de extração, transformação e limpeza de dados mapeados do sistema BSB. Serão também definidas regras de carga dos dados no DM.
Indicador físico Área de transição de dados criada e as regras construídas. Duração 04 semanas A t i v i d a d e 3.3 Descrição • Executar os processos de carga e testes do modelo
dimensional Descrição do recurso Qtd.Recursos
necessários • Microcomputador PC • Microsoft SQL Server 2000 ou superior
01 01
Pré-requisitos • Atividade 3.2
Metodologia Implementar o processo de carga dos dados no DW estudado na atividade 2.3 e realizar testes de validação do modelo dimensional.
Indicador físico Exibição dos dados carregados no DM. Duração 04 semanas
15
A t i v i d a d e 3.4 Descrição • Construir as consultas ao DM
Descrição do recurso Qtd.Recursos necessários • Microcomputador PC
• MS Excel 01 01
Pré-requisitos • Atividade 3.3
Metodologia Construção das consultas para apresentar respostas às necessidades executivas, inicialmente, a serem apresentadas no MS Excel, por ser uma ferramenta padrão na empresa para visualização de informações gerenciais.
Indicador físico Apresentação do ambiente para realizar as consultas gerenciais. Duração 07 semanas Etapa 4: Validação. Esta etapa realiza experimentação e testes sobre a solução proposta, com
o objetivo de eliminar os erros existentes em sua modelagem ou desenvolvimento.
A t i v i d a d e 4.1 Descrição • Validar consultas pelos gestores
Descrição do recurso Qtd.Recursos necessários • Microcomputador PC
• MS Excel 01 01
Pré-requisitos • Atividade 3.3
Metodologia Apresentar o sistema aos gestores, mostrar o método de interatividade com o mesmo e validar se está atendendo as suas expectativas.
Indicador físico Documento Textual descrevendo a opinião dos gestores com algumas consultas realizadas.
Duração 04 semanas Etapa 5: Documentação. Esta etapa visa deixar registrado todo o processo pertinente à
pesquisa científica, desde a descrição do problema, a proposta de uma solução (modelagem),
o desenvolvimento dessa solução, os testes e validação da solução e os resultados finais. A
documentação deve permitir a outros pesquisadores reproduzir a solução e realizar os mesmos
experimentos e testes feitos para sua validação.
16
A t i v i d a d e 5.1 Descrição Redigir o texto do TCC I
Descrição do recurso Qtd.Recursos necessários • Microcomputador PC 01
Pré-requisitos • Nenhum
Metodologia A redação do TCC I se dará ao longo de todo o primeiro semestre de trabalho, através das produções textuais que são os indicadores físicos das atividades já planejadas. O texto final deve estar conciso, claro, bem apresentado e com boa cadência. O objetivo do TCC I é definir bem o tema/problema de pesquisa, justificar sua importância e abrangência e fornecer o referencial.
Indicador físico • Documento textual do TCC I a ser apresentado à banca avaliadora
Duração 04 meses
A t i v i d a d e 5.2 Descrição Redigir o texto do TCC II
Descrição do recurso Qtd.Recursos necessários • Microcomputador PC 01
Pré-requisitos • Etapas de estudo (1) e modelagem (2)
Metodologia A redação do TCC II se dará ao longo de todo o segundo semestre de trabalho, através das produções textuais que são os resultados das atividades já planejadas. O texto final deve estar conciso, claro, bem apresentado e com boa cadência. O objetivo do TCC II é documentar o desenvolvimento da solução proposta, de forma que possa ser reproduzida por outros pesquisadores, deve apresentar a verificação e validação do projeto, e finalmente os resultados alcançados e as conclusões tiradas.
Indicador físico • Documento textual do TCC II a ser apresentado à banca avaliadora
Duração 04 meses
Recursos necessários:
Os recursos necessários à correta execução deste projeto de pesquisa são listados a seguir:
17
Recursos de Hardware: td Disp Local Descrição Q
Microcomputador PC para desenvolvimento, testes e simulações. Configuração mínima: P4, 1.9 MHz, 256MB
AM, 40GB HD, 10/100Eth 01 SIM JUNIOR
R
Recursos de Software: Q Descrição td Disp Local
Ferramentas diversas para desenvolvimento/pesquisa: MS 01 SIM JUNIOR Office, navegador web. Sistema Operacional Windows 2003 Server 01 SIM JUNIOR Microsoft SQL Server 2000 01 SIM JUNIOR
Recursos humanos: ição Q Descr td Disp Local
Gestores da empresa JUNIOR 2 SIM JUNIOR
1.5 CRONOGRAMA
xidade das atividades, bem como o
prazo de cumprimento do TCC estabelecido pelo Curso.
smas, e colchetes indicam uma possível
flexibilidade no prazo de execução de uma atividade.
C a d olvim ra o Tidade 03 / 06 04 / 06 05 / 06 06 / 06
O cronograma de desenvolvimento deste projeto de pesquisa segue o plano de pesquisa
apresentado, e considera os requisitos, recursos e comple
O cronograma de desenvolvimento é separado em duas grandes etapas distintas, o TCC I e o
TCC II, sendo apresentado a seguir. No cronograma, uma seta entre duas atividades indica a
necessidade de precedência (pré-requisito) entre as me
ronogram e desenv ento pa CC I Ativ 07 / 061.1 x X x x x x x x x X x x x x x x x X x X 2.1 2.2 2.3 5.1
1.1 Estudar os conceitos de Data Warehouse, Data Mart, Sistemas de Apoio a Decisão, OLAP, Área de Negócios das empresas;
18
2.1 Identificar as necessidades de informações executivas para tomada de decisão;
2.2 Construir o Modelo Dimensional, baseado em tecnologia OLAP;
2.3 Identificar as fontes de dados;
Cronograma de desenvolvimento para o TCC II Atividade 08 / 06 09 / 06 10 / 06 11 / 06 12 / 06 3.1 x x x x x x x X x X x x X X X x x X x x 3.2 3.3 3.4 4.1 5.2
3.1 Implementar o Modelo Físico do DM;
3.2 Preparar a área de transição de dados (Extração, Transferência, Carga);
3.3 Executar os processos de carga e testes do modelo dimensional;
3.4 Construir as consultas ao DM;
4.1 Validar as consultas pelos gestores;
5.1 Documentar o Projeto. 1.6 OBJETIVOS
1.6.1 Objetivo geral
Desenvolver uma ferramenta de apoio a decisão baseada na tecnologia OLAP para a área
comercial da JUNIOR.
1.6.2 Objetivos específicos
• Estudar os conceitos de Data Warehouse, Data Mart, Sistemas de Apoio a Decisão,
OLAP;
• Estudar diferentes estilos de tomada de decisão;
• Identificar as fontes de dados;
19
• Executar os processos de carga e testes do modelo dimensional;
• Construir as consultas ao DM e
• Validar as consultas pelos gestores;
1.7. ESTRUTURA DO TRABALHO
Este TCC I está divido em quatro capítulos: Introdução, Fundamentação Teórica, Projeto e
Considerações Finais.
A Introdução apresenta uma descrição do contexto, motivação e justificativa do projeto, os
objetivos gerais e específicos, a metodologia e a estrutura do trabalho.
Na Fundamentação Teórica são descritos os conceitos necessários para a realização do
projeto. Neste capítulo, também são apresentadas as principais características que o projeto
deve apresentar.
O Projeto especifica a modelagem do sistema, através da análise funcional e de dados
envolvidos no projeto. Apresenta também a metodologia para a realização do TCC II.
O último capítulo, Considerações Finais, apresenta alguns tópicos relativos á montagem dos
cubos que ainda serão analisados e desenvolvidos durante o TCC II.
20
2. CARACTERIZAÇÃO DA EMPRESA
A JUNIORGPL Tecnologia, compete num mercado global de tecnologia de ponta e destaca-
se a cada dia de forma expressiva no segmento de sistemas para o condicionamento de energia
elétrica. Com sua fábrica instalada em São josé/SC, a empresa é detentora de um amplo Know
How em no-breaks, retificadores, inversores, conversores, fontes e estabilizadores.
A empresa catarinense tem sua posição de destaque consolidada também pelos investimentos
maciços em sistemas de manufatura, distribuição e atendimento, para o lançamento de
produtos cada vez mais inovadores. Tudo isso com o objetivo de atender, da melhor forma, as
necessidades e expectativas dos clientes.
A JUNIORGPL Tecnologia prima pelo compromisso nas relações comerciais plenas e
duradouras com clientes, parceiros e colaboradores, dominando e se responsabilizando por
todas as etapas das operações, abrangendo desenvolvimento, produção, comercialização e
assistência técnica.
2.1 HISTÓRICO
1988 - Início das atividades da JUNIOR Equipamentos Eletrônicos com a venda e assistência
técnica de equipamentos de condicionamento de energia elétrica. Surge a primeira empresa do
grupo JUNIOR.
1991 - A empresa passa a atuar também na área de engenharia elétrica/eletrônica, automação
bancária e terceirização de serviços de infra-estrutura.
1993 - Inauguração da sede própria em Campinas (São José) com 1050m².
1995 - Início das atividades da JUNIOR Indústria e Comércio, com a produção de
estabilizadores e no-breaks de pequeno porte.
1996 - Desenvolvimento e lançamento do Laboratório Didático Móvel. Nasce a
AUTOLABOR.
1997 - Firma acordo técnico com uma empresa americana para representação técnica no
Brasil e países do mercosul de equipamentos para sistemas de TV a cabo. Assim surge a
21
ECS.
Inauguração da 1º fase do complexo industrial em São José com 1500m² de um total previsto
de 6000m². - Prêmio catarinense de Design
1998 - A JUNIOR Indústria e Comércio inicia processo de expansão para os demais Estados
do Brasil, estruturando redes para comercialização e assistência técnica, culminando com a
inauguração de sua primeira filial em São Paulo.
1999 - Certificação ISO 9001. Inicia a comercialização de fontes para redes de Televisão a
cabo (HFC) e firma parceria com grandes empresas de turn Ky para distribuição dos produtos.
- Certificado Gestão do Design.
2000 - Inauguração da nova sede administrativa, 2º fase do complexo industrial. Domina o
mercado brasileiro de fontes e inicia programa de exportação.
2001 - Conquista o primeiro lugar em exportações de no-breaks, exportando seus produtos
para Argentina, Uruguai e Bolívia.
2002 - Apresenta ao mercado uma linha completa de no-breaks para uso externo, voltados
para aplicação em sistemas de telecomunicações e controle de tráfego. Adquiri uma fábrica de
transformadores e consolida seu sistema de qualidade, com a atualização do certificação da
ISO 9001 revisão 2000. - Certificado de Mérito Ambiental
2003 - Firma contrato de OEM com o maior fabricante de centrais telefônicas de pequeno
porte da América Latina e contrato de fornecimento na modalidade "guarda-chuva" com a
maior empresa de telecomunicações do Brasil. Promove o lançamento da Linha de no-breaks
Office e inicia as exportações para o Chile.
2004 - Consolida sua presença nos mercados Argentino, Boliviano e Chileno. Firma contrato
na Argentina com a maior operadora de TV a cabo da América Latina.
Adquiri a empresa GPL Eletro-Eletrônica S.A., empresa com mais de 25 anos de tradição no
fornecimento de no-breaks trifásicos, inversores, retificadores e conversores de frequência.
Nasce a JUNIORGPL Tecnologia. Inicia o processo de ampliação de seu complexo
industrial.
22
3. FUNDAMENTAÇÃO TEÓRICA
Na fundamentação teórica deste projeto busca-se dar embasamento aos conceitos, requisitos e
tecnologias necessárias para o desenvolvimento do SADBO (Sistema de Apoio á Decisão
Baseado em tecnologia OLAP). Para isso, foram selecionados como temas principais da
fundamentação os assuntos: Sistemas de Informação e Tomada de Decisão como Ferramentas
de Gestão, Estruturas dos Bancos de Dados, Modelo Multidimensional, OLAP e Microsoft
SQL Server. Os temas escolhidos são fundamentais para o desenvolvimento do sistema e
foram analisados com base nas suas aplicações para o SADBO.
No primeiro tema, Sistemas de Informação e Tomada de Decisão, apresentam-se os conceitos
necessários para o entendimento do conceito de sistemas de informação. Apresentam-se,
também, os conceitos e características dos sistemas de informação gerencial e sistemas de
apoio à decisão.
No segundo tema, Estruturas dos Bancos de Dados, são expostos os conceitos de bancos
relacionais e multidimensionais, enfatizando a estrutura multidimensional que será utilizada
no desenvolvimento deste projeto. Nesta seção, apresentam-se também os conceitos de data
warehouse e data mart e a importância desses conceitos para o projeto.
No terceiro tema, Modelo Multidimensional, são tratados os passos necessários para a
modelagem dos dados de um banco multidimensional. Na seção, incluem-se os conceitos de
cubos, hipercubos, fatos, medidas, dimensões, agregações e suas respectivas importâncias
para o sistema.
No quarto tema, OLAP, conceitua-se o termo OLAP, mostrando quando uma solução pode
ser considerada OLAP, quais os tipos de tecnologia OLAP existentes e os requisitos
funcionais de uma solução OLAP.
No quinto tema, Microsoft SQL Server, mostram-se as vantagens deste gerenciador de banco
de dados na implementação de bancos multidimensionais e apresenta-se a ferramenta DSS,
um assistente para a implementação de data warehouse e data marts.
23
3.1 SISTEMAS DE INFORMAÇÃO
Nesta seção da fundamentação teórica, abordam-se os conceitos necessários para classificar o
SADBO( Sistema de Apoio a Decisão Baseado em OLAP) como um sistema de informação e
identificar as informações possíveis de serem obtidas com esse sistema.
Os processos decisórios sustentados por Gestão por Resultados, onde Etzioni (1989) observa
que a grande quantidade de informações que os executivos recebem atualmente não refletem
em resultado para uma maior compreensão dos assuntos sobre os quais devem decidir.
Por esse motivo e, também, porque o comportamento dos executivos é mais informal do que
as teorias administrativas supõem (MINTZBERG; QUINN, 2001), questiona-se e investiga-
se, hoje, a eficácia dos Sistemas de Informações Gerenciais e sua efetiva capacidade de
otimizar o desempenho das organizações.
A construção de sistemas de apoio à gestão se dá pela análise da dinâmica organizacional na
perspectiva de seus atores intervenientes, e são esses que darão sentido à informação e não
somente a seus atributos técnicos.
Os profissionais de negócios se vêem constantemente á frente de tecnologias e conceitos que
nem sempre são fáceis de serem absorvidos, pois muitas vezes não possuem conhecimento
técnico na área de informática. Para O' BRIEN (2001), estes usuários devem concentrar seus
esforços em cinco áreas de conhecimento:
• Conceitos básicos. Conceitos comportamentais, técnicos e administrativos fundamentais
sobre os componentes e papéis dos sistemas de informações.
• Tecnologia da informação. Os principais conceitos, avanços e questões gerenciais na
tecnologia da informação.
• Aplicações empresariais. As principais utilizações dos sistemas de informação para as
operações, administração e vantagem competitiva de um empreendimento, incluindo e-
commerce e colaboração, utilizando a Internet, intranets e extranets.
• Processos de desenvolvimento. Como os profissionais de negócios ou especialistas em
24
informação planejam, desenvolvem e implementam os sistemas de informação para
atender as oportunidades de e-business e
• Desafios gerenciais. Os desafios de administrar de forma efetiva e ética as tecnologias,
estratégias e a segurança.
Segundo O' BRIEN (2001), um sistema de informações consiste em cinco recursos principais:
pessoas, hardware, software dados e redes. Afirma, também, que é possível identificar esses
cinco componentes em ação em qualquer tipo de sistema de informação presente no mundo
real. Abaixo apresentam-se exemplos de recursos e produtos destes componentes:
Recursos Humanos
Especialistas – analistas de sistemas, programadores, operadores de computador
Usuários Finais – todos os demais que utilizam sistemas de informação
Recursos de Hardware
Computadores, monitores de vídeo, unidades de disco magnéticos, impressoras
Mídias – formulários de papel, cd’s, dvd’s
Recursos de Software
Programas – programas de sistemas operacionais, programas de planilha eletrônica
Procedimentos – procedimentos de entrada de dados, procedimentos de correção de erros
Recursos de Dados
Descrição de produtos, cadastro de clientes, arquivo de funcionários,
Recursos de redes
Meios de comunicação, acesso a rede e software de controle.
Produtos de Informação
Relatórios administrativos e documentos empresariais utilizando texto e demonstrativos
gráficos.
25
Ambiente Recursos Componentes Objetivos Humanos
Funções Procedimentos Gestão
FIGURA 1 – COMPONENTES DE UM SISTEMA fonte: adaptado de REZENDE (2000)
A figura 1 apresenta exemplos de recursos e produtos dos componentes de um sistema.
Segundo O' BRIEN (2001), os sistemas de informações podem ser classificados ora como sistemas de apoio às operações, ora como sistemas de apoio gerencial.
Abaixo descreve-se as duas classificações de sistemas de informação.
3.1.1 Sistemas de apoio às operações
Os sistemas de apoio às operações não abastecem as necessidades dos gerentes, eles servem
para produzir informações das operações transacionais, eles abastecem os bancos de dados.
Para BRIEN (2001), os sistemas de apoio às operações podem ser divididos em sistemas de
apoio de processamento de transações, sistemas de controle de processos e sistemas
colaborativos.
• Sistemas de apoio de processamento de transações. Processam dados resultantes de
transações empresariais, atualizam banco de dados e produzem documentos empresariais;
• Sistemas de controle de processos. Monitoram e controlam processos industriais e
• Sistemas colaborativos. Apóiam equipes, grupos de trabalho, bem como comunicações e
colaboração entre e nas empresas.
26
3.1.2 Sistemas de apoio gerencial
Os Sistemas de Apoio Gerencial (SAG) são conceituados por O' BRIEN (2001) como
“aqueles que se concentram em fornecer informação e apoio aos gerentes em sua tomada de
decisão eficaz. A tarefa desempenhada por estes sistemas é um tanto complexa”.
Segundo O' BRIEN (2004), os sistemas de apoio gerencial podem ser divididos em três:
Sistemas de informação gerencial, Sistemas de apoio à decisão e Sistemas de informação
executiva.
• Sistemas de informação gerencial. Fornecem informações na forma de relatórios e
demonstrativos pré-estipulados para os gerentes;
• Sistemas de apoio à decisão. Fornecem apoio interativo para o processo de decisão dos
gerentes e
• Sistemas de informação executiva. Fornecem informações críticas elaboradas
especificamente para as necessidades de informação dos executivos.
3.2 PROCESSO DE TOMADA DE DECISÃO
Galbraith e Lawler (1995) concluem que a velocidade na tomada de decisão é particularmente
crítica nos ambientes nos quais os produtos têm uma rotatividade rápida e nas empresas de
serviços nas quais os clientes exigem atendimento imediato. As organizações, que dão poder
especial aos escalões inferiores, podem reagir mais rapidamente às mudanças ambientais e às
mudanças nas exigências dos clientes do que aquelas que são orientadas para o controle.
A forma como as organizações lidam com a informação tem sido considerada, hoje, um dos
principais instrumentos para aumento da velocidade nos processos de tomada de decisão. A
velocidade gerada pela integração das informações no SIGBO demanda das corporações e de
seus administradores novas posturas em relação à elaboração e execução dos atos decisórios.
A agilidade nas tomadas de decisões torna-se mais que fundamental, é responsável pela
sobrevivência de algumas empresas que atuam num mercado competitivo e que vivem de
inovações. Por meio das tecnologias de comunicação e informação foram criadas soluções
para a otimização das etapas de tomadas de decisão das empresas, desde a fase de
27
planejamento até o pleno desenvolvimento do projeto (GALBRAITH e LAWLER, 1995).
Drucker (2001) considera que os executivos eficazes não tomam muitas decisões,
concentram-se no que é importante. Tentam tomar as poucas decisões importantes no nível
mais alto do entendimento conceitual. Procuram localizar o que é invariável em uma situação,
pensar no que é estratégico e genérico, em vez de “resolver problema”. Querem saber do que
trata a decisão e quais as realidades subjacentes que ela tem que satisfazer. Querem impactos,
em vez de técnicas. A decisão eficaz é por si só baseada no mais alto nível do entendimento
conceitual, o compromisso com a ação deve estar o mais próximo possível da capacidade das
pessoas encarregadas em cumpri-la. Executivos eficazes sabem que a tomada de decisão tem
seu próprio processo sistemático e seus próprios elementos claramente definidos.
O conceito de decisão está bastante relacionado à solução de problemas (análise de
problemas). Para STRYKER (2001), problema é o desvio de algum padrão ou desempenho
desejado; a decisão é uma escolha do melhor caminho para corrigir a causa de um problema, e
todo problema tem somente uma causa; e o processo de gradação, partindo de um problema
até sua causa, a qual, por sua vez, pode ser também um problema a ser resolvido.
Sem uma especificação precisa e análise cuidadosa, apenas um exercício inútil de adivinhação
e sorte poderia ter chegado à explicação provável do problema. Cabe, ainda, discutir que as
análises tradicionais de sistemas gerenciais pautam-se, como cita STRYKER (2001), em
desvio de padrão ou desempenho, este resultado não necessariamente enquadra-se como
problema. Porém, poderá ser um resultado acima dos padrões estabelecidos, que neste caso
poderá ser uma oportunidade.
Portanto, leva-se tempo para transformar os hábitos de raciocínios de um gerente em uma
abordagem sistemática de análise de problemas. Um modelo de informações gerenciais, que
demonstre o processo de decisão da organização, vem facilitar o gestor na dinâmica de
solução dos diversos problemas e níveis de decisão. Assim, quanto aos tipos de problemas,
sob o ponto de vista da tomada de decisão, podem ser classificados em três categorias:
problemas estruturados, semi-estruturados e não-estruturados (TURBAN e ARONSON,
1998).
Um problema é considerado estruturado ou bem definido se sua definição e fases de operação
para chegar aos resultados desejados estiverem claros e sua execução repetida for sempre
28
possível. Os problemas semi-estruturados são problemas com operações bem conhecidas, mas
que contêm algum fator ou critério variável que pode influir no resultado. Nos problemas não-
estruturados, tanto os cenários, como o critério de decisão, não estão fixados ou conhecidos a
priori.
Além disso, a decisão sobre qualquer um dos três tipos de problemas (estruturados, semi-
estruturados ou não-estruturados) pode ser diferenciada por nível de decisão: estratégico (em
geral, decisão para dois a cinco anos); tático (decisão para alguns meses a até dois anos);
despacho ou liberação (decisão para algumas horas ou alguns dias) (SHIMIZU, 2001).
Existem superposições entre tipos de problemas e os níveis de decisão, mas a
responsabilidade de decisão cabe a grupos distintos de decisores (Figura 2).
FIGURA 2 - CLASSIFICAÇÃO DOS PROBLEMAS DE DECISÃO.
CCOONNFFLLIITTOO DDEE OOBBJJEETTIIVVOOSS EE AAMMBBIIGGÜÜIIDDAADDEE
IINNCCEERRTTEEZZAA
MMOODDEELLOO RRAACCIIOONNAALL RREEGGRRAASS EE RROOTTIINNAASS
BBEEMM EESSTTRRUUTTUURRAADDAASS MMOODDEELLOO PPOOLLÍÍTTIICCOO
OOBBJJEETTIIVVOOSS MMÚÚLLTTIIPPLLOOSS EE CCOONNFFLLIITTOOSS DDEE IINNTTEERREESSSSEE
MMOODDEELLOO PPRROOCCEESSSSUUAALL MMÚÚLLTTIIPPLLOOSS CCEENNÁÁRRIIOOSS,,
OOBBJJEETTIIVVOOSS EE AALLTTEERRNNAATTIIVVAASS PPRROOCCEESSSSOO SSEEMMII--
EESSTTRRUUTTUURRAADDOO OORRIIEENNTTAADDOO AA OOBBJJEETTOO
MMOODDEELLOO AAMMBBÍÍGGUUOO PPRROOBBLLEEMMAA AANNÁÁRRQQUUIICCOO
IIMMPPRREECCIISSOO ((FFUUZZZZYY))
MMAALL FFOORRMMUULLAADDOO
Fonte: Adaptado de CHOO, C. W. The knowing organization. Oxford: Oxford University Press, 1998. As classificações de problemas de decisão passam por representação em modelos. O
entendimento de modelo para o estudo define-se como um processo de racionalização e
simplificação de uma realidade. Então, modelo não é um mapa da realidade, mas modelos
permitem mapear realidade (MURAKAMI, 2003).
Modelo Racional - Decisão com certeza; Decisão com otimização; Decisão que usa
heurísticas e meta-heurísticas; Decisão na Administração da Produção; Decisão em
planejamento de cadeia de suprimentos.
29
Modelo Processual - Decisão em situação de incerteza ou risco; Decisão que usa
processos estocásticos.
Modelo Político - Decisão com incerteza, múltiplos objetivos e múltiplos cenários;
Decisão com competidor ou com conflito: Teoria do Jogo, Jogo de Guerra e Jogo de
Empresas Virtuais; Decisão em Portifólio de Ações; Decisão em Problemas da TI.
Modelo Ambíguo - Modelo da Lata de Lixo: decisão por vista grossa e por passagem;
Decisão pelo voto; Decisão que usa Sistemas Especialistas Difusos.
O posicionamento do Modelo de Informações em estudo nessa pesquisa, diante da
classificação dos problemas decisão, enquadra-se nos conceitos do Modelo Racional. Ainda,
esses modelos são sustentados por um processo de tomada de decisões estruturado, onde
Drucker (2001) define as seguintes etapas envolvidas no processo de tomada de decisões:
1. Classificar o problema - O responsável pela tomada de decisões eficazes pergunta: esse é
um sintoma de uma desordem fundamental ou um acontecimento isolado? O que for
genérico precisa ser respondido por uma regra, um princípio. E acontecimentos
excepcionais só podem ser encarados como tal, e à medida que aparecem.
2. Definir o problema – Uma vez que um problema tenha sido classificado como genérico ou
único, é normalmente muito fácil de definir. “de que se trata?”, “o que é pertinente aqui?”,
“qual é a explicação para essa situação?” Questões como essas são familiares, mas
somente os verdadeiros tomadores de decisão eficazes estão atentos para o fato de que o
perigo, nesta etapa, não é a definição incorreta; é aquela definição plausível, mas
incompleta. Há apenas uma garantia para não se tornar prisioneiro de uma definição
incompleta: checá-la novamente e mais uma vez em relação a todos os fatos que possam
ser observados, e descartar uma definição no momento em que ela deixar de abranger
qualquer um deles. Finalmente, voltam e repensam os problemas sempre que identificam
algo atípico, quando se deparam com fenômenos inexplicados, ou quando o curso dos
acontecimentos se desvia, mesmo que em detalhes das expectativas.
3. Especificar a resposta ao problema - Definir as especificações que a decisão tem que
consumar. Quais são os objetivos que a decisão tem que alcançar? Quais as metas
mínimas que deve obter? Quais são as condições que ela tem que satisfazer? Em ciência,
essas condições são conhecidas como “condições-limite”. Uma decisão, para ser
30
eficaz, precisa satisfazer às condições-limite.
4. A decisão - Decidir o que é “certo”, em vez do que é aceitável, de modo que atenda às
condições-limite;
5. A ação - Incorporar à própria decisão a ação, para que ela seja cumprida;
6. O feedback - Testar a validade e a eficácia da decisão em relação ao rumo verdadeiro dos
acontecimentos. A monitoração e a transmissão das informações têm de vir embutidas na
decisão para facilitar verificações contínuas, diante dos reais acontecimentos, das
expectativas que estão por trás das decisões. Os tomadores de decisão precisam de
informação organizada como feedback, eles precisam de relatórios e de estimativas.
Afirma, ainda, Drucker (2001), que a tomada de decisão é apenas uma das tarefas de um
executivo. Geralmente, consome uma pequena fração do seu tempo. Mas tomar as decisões
importantes é tarefa específica dos executivos. Somente um executivo toma esse tipo de
decisão.
Um executivo eficaz toma essas decisões como um processo sistemático com elementos
claramente definidos e em uma seqüência de etapas distinta. Na verdade, esperar que ele tome
decisões significativas e de impacto positivo na organização como um todo, seu desempenho
e seus resultados, caracteriza o executivo eficaz.
Na abordagem de Russo e Schoemaker (1993), quanto aos elementos do processo de tomada
de decisão, dividem em quatro elementos principais, onde os mesmos afirmam que todo bom
tomador de decisões deve conscientemente ou não, passar por cada uma deles, ou seja:
1. Estruturar – definir o que deve ser decidido e determinado que critérios o fariam preferir
uma opção em relação à outra;
2. Colher informações – procurar fatos reconhecíveis como estimativas razoáveis sobre os
“não-reconhecíveis”, necessários para tomar a decisão;
3. Conclusões – uma estruturação perfeita e boas informações não garantem uma decisão
correta. As pessoas não podem tomar conscientemente boas decisões usando critérios
intuitivos, mesmo tendo dados excelentes;
4. Aprender com feedback – manter o acompanhamento daquilo que se esperava
31
que acontecesse, resguardando-se sistematicamente das explicações egoístas e
assegurando-se de rever as lições produzidas pelo feedback na próxima vez que surgir
uma decisão semelhante.
O que se destaca nessa abordagem em relação às demais são os elementos de estruturação e o
aprendizado com o processo de feedback.
Hammond (1998), ressaltam “as armadilhas ocultas na tomada de decisão”. Ou seja, as más
decisões geralmente podem ser explicadas pela maneira como as decisões são tomadas. Onde
as alternativas não estão claramente definidas, a informação correta não foi conseguida, os
custos e benefícios não avaliados com precisão. Mas às vezes a falha não está no processo de
tomada de decisão, mas sim na mente do responsável pela tomada de decisão. A maneira pela
qual o cérebro humano funciona pode sabotar as escolhas que fizemos. John Hammond,
Ralph Keeney e Howard (1998) examinam oito armadilhas psicológicas que são
particularmente possíveis de afetar o modo como tomamos decisões de negócios, são elas:
1. Armadilha da ancoragem leva-nos a atribuir um peso desproporcional à primeira
informação que recebe-se;
2. Armadilha do status quo impele-nos a manter a situação atual – mesmo quando existem
alternativas melhores;
3. Armadilhas dos fundos perdidos nos levam a perpetuar erros do passado;
4. Armadilha da confirmação das evidências faz com que procuremos informações para
sustentar uma preferência já existente e para descartar informações contraditórias;
5. Armadilhas do enquadramento ocorrem quando se descreve de forma inapropriada um
problema, minando o processo de tomada de decisão;
6. Armadilha da confiança excessiva faz com que superestimemos a exatidão de nossos
prognósticos;
7. Armadilha da prudência torna-nos supercautelosos ao fazer avaliações sobre
acontecimentos incertos; e,
8. Armadilha da recordação leva-nos a atribuir pesos indevidos aos acontecimentos recentes
32
mais impressionantes.
A melhor proteção contra as armadilhas psicológicas – isoladamente ou combinadas – é a
prevenção. Ou seja, não negligenciar a existência dessas armadilhas no contexto das decisões.
Pois, esses fatores poderão influenciar no uso de um modelo de informação focado para o
processo de decisão. Uma forma coerente de se proteger e tomar decisões sem a preocupação
das armadilhas psicológicas é utilizar ferramentas de BI (Business Intelligence) que baseadas
em informações técnicas e exatas podem ajudar o executivo a tomar decisões calçado em
bases sólidas.
3.3 BUSINESS INTELLIGENCE
A história do Business Intelligence, segundo Serra (2002), teve início na década de 70,
quando alguns produtos de BI foram fornecidos para os executivos. O problema destes
produtos era que exigiam muito esforço de programação, além de não disponibilizar
informação em tempo hábil nem de forma flexível, além de um custo elevado de implantação.
O’Brien (2001) amplia a discussão, e considera que sistemas de informações para aplicações
gerenciais combinam os trabalhos teóricos: de ciência da computação, ciência da
administração e pesquisa operacional com uma orientação prática para construção de sistemas
e aplicações. Ainda, o autor ressalta a adoção de questões de comportamento, levantadas pela
sociologia, economia e psicologia.
Portanto, o conceito de BI em síntese, passa pelo desafio da disponibilização de ferramentas e
dados, para que o nível gerencial de uma organização possa detectar tendências e tomar
decisões eficientes no tempo correto.
Assim, Laudon e Laudon (1999) destacam que a revolução do conhecimento e da informação
começou na virada do século XX e evolui gradativamente. Os autores observam que com o
crescimento da economia da informação, vem ocorrendo um declínio no número de
trabalhadores rurais e de operários de fábricas. E paralelamente, ocorre aumento dos
trabalhadores de escritório, que produzem valor econômico usando conhecimento e
informação. Ou seja, conhecimento e informações estão se tornando à base para novos
serviços e produtos.
A tendência da mudança do perfil do trabalhador tem ampliado o escopo de sistemas de
33
informação, conforme apresenta o Quadro 1.0. Observa-se que com a evolução do tempo, os
sistemas de informação passaram a ter um papel de maior apoio nas organizações. Assim,
expandindo-se de um papel mais técnico inicialmente para afetarem o controle e o
comportamento administrativo, impactando mudanças sobre os usuários finais e gerentes de
uma organização.
PPEERRÍÍOODDOO CCAARRAACCTTEERRÍÍSSTTIICCAASS DDOOSS SSII PPAAPPEELL DDOOSS SSII NNOOSS NNEEGGÓÓCCIIOOSS
1950 a 1960
Processamento de Dados (ênfase Mudanças Técnicas)
Sistemas de Processamento Eletrônico de Dados - Processamento de transações, manutenção de registros e aplicações contábeis tradicionais.
1960 a 1970
Relatórios Administrativos (ênfase Controle Gerencial)
Sistemas de informação gerencial - Relatórios administrativos de informações pré-estipuladas para apoio a tomada de decisão.
1970 a 1980
Apoio à Decisão (ênfase Controle Gerencial)
Sistemas de Apoio à Decisão - Apoio interativo e ad hoc ao processo de tomada de decisão gerencial.
1980 a 1990
Apoio Estratégico ao Usuário Final (ênfase Atividades Institucionais Essenciais)
Sistemas de computação do usuário final – Apoio direto à computação para a produtividade do usuário final e colaboração de grupos de trabalho. Sistemas de informação executiva (EIS) – Informações críticas para a alta administração. Sistemas especialistas – Conselho especializado baseado no conhecimento para os usuários finais. Sistemas de informação estratégica – Produtos e serviços estratégicos para vantagem competitiva.
a partir de 1990
Empresa e Conexão em Rede Global (ênfase Atividades Institucionais Essenciais)
Sistemas de informação interconectados – Para o usuário final, a empresa e a computação, comunicações e colaboração interorganizacional, incluindo operações e administração globais na Internet, intranets, extranets e outras redes empresariais e mundiais.
Quadro 1.0: Evolução do Papel dos Sistemas de Informação nos Negócios. Fonte: Adaptado de Laudon e Laudon (1999) e O’Brien (2001).
As organizações impulsionadas pelos avanços tecnológicos e novas necessidades passam a
desenvolver um novo tratamento da informação, onde Barbieri (2001) destaca as abordagens:
Gerência do Conhecimento (KM - Knowledge Management), que objetiva estabelecer
uma aproximação integrada e colaborativa para capturar, criar, organizar e usar todos os
ativos de informação da empresa. O BI é mais compartimentada, objetiva e focada em
estruturas definidas. Já o KM trabalha o ativo de informações, independentemente a sua
forma, estrutura e domínio (em suma, ênfase nos documentos);
Inteligência Competitiva (CI – Competitive Intelligence), cuja idéia básica é explorar
informações detalhadas sobre concorrentes e o mercado, buscando a atração do cliente
para sua corporação. De forma simples, pode-se entender CI como um BI aplicado ao
mundo fora das fronteiras empresariais, focado em informações textuais e factuais a
respeito dos movimentos do mercado e dos concorrentes.
Desta forma, o processo de inteligência segue os níveis hierárquicos, conforme a Figura 3.
34
Assim é nesse cenário de dados e novas estirpes (informações e conhecimentos), trabalhadas
interna e externamente na empresa através de redes corporativas, que o processo de decisão se
fundamenta, ou seja, voltado para inteligência apoiando a vantagem competitiva.
Ou seja, voltado para inteligência apoiando a vantagem competitiva.
VVAANNTTAAGGEEMM
CCOOMMPPEETTIITTIIVVAA
Elaboração
Aprendizagem
Experiência
DDAADDOOSS
IINNTTEELLIIGGÊÊNNCCIIAA
SS ÍÍ NN TT EE SS EE
CCOONNHHEECCIIMMEENNTTOO
AANNÁÁLL II SSEE
IINNFFOORRMMAAÇÇÃÃOO
PP RR OO CC EE SS SS AA MM EE NN TT OO
FIGURA 3: DIAGRAMA DOS NÍVEIS HIERÁRQUICOS DA INFORMAÇÃO.
Fonte: Adaptado Herring apud Wanderley (1999) e Moresi (2000).
A inteligência é o resultado de um processo que começa com a coleta de dados. Esses dados
são organizados e transformados em informação, que, depois de analisada e contextualizada,
transforma-se em inteligência. Esta, por sua vez, aplicada a processos de decisão gera
35
vantagens competitivas para a organização. Os dados são armazenados e estruturados em
ferramentas denominadas banco de dados.
3.4. ESTRUTURAS DOS BANCOS DE DADOS
Neste ítem abordam-se as principais diferenças entre a estrutura relacional de um banco de
dados e a estrutura multidimensional. Por tratar-se de uma estrutura complexa e fundamental
para a realização deste projeto, aborda-se a estrutura multidimensional com um pouco mais de
profundidade, mostrando-se os detalhes necessários para a implementação deste tipo de
estrutura.
Desde a introdução dos bancos de dados relacionais, os analistas estão acostumados a
construir bancos de dados normalizados para sistemas operacionais/transacionais,
decompondo os dados no seu menor nível, evitando assim a duplicidade da informação, ou
seja, o foco da normalização é a eficiência do armazenamento. Quando se trata de data
warehouse é necessária uma mudança na forma de modelar os dados, uma vez que, o objetivo
passa a ser a performance das consultas, isto é, o acesso e recuperação dos dados.
O modelo relacional, também conhecido como modelo ER (Entidade-Relacionamento), é a
mais popular estrutura de bancos de dados. O’Brien (2001) explica que, neste modelo, todos
os elementos dos dados dentro do banco de dados são armazenados na forma de tabelas
simples. Os pacotes de sistemas de gerenciamento de bancos de dados baseados no modelo
relacional podem vincular elementos de dados de várias tabelas para fornecer informações
para os usuários. Esta estrutura de dados é bastante propícia para solucionar problemas de
espaço em disco e também de performance.
A questão fundamental é que as novas tecnologias de consulta e análise de dados requerem
recursos que a estrutura relacional não podem oferecer.
3.4.1 Estrutura multidimensional
A estrutura multidimensional de bancos de dados, que também pode ser chamada apenas de
estrutura dimensional, é uma variação do modelo relacional que utiliza estruturas
multidimensionais para organizar os dados e expressar as relações entre os dados. É possível
visualizar as estruturas multidimensionais como cubos de dados e cubos dentro de cubos de
36
dados. Cada face do cubo é considerada como uma dimensão dos dados (O’BRIEN, 2001).
Para Kim (1995), não existem segredos ou soluções mágicas para que se converta um modelo
ER em um modelo dimensional. O gerenciador de banco de dados utilizado no modelo
dimensional é bastante diferente do tradicional que gerencia modelos ER, sendo que no
primeiro são facilitadas a navegação e as consultas. O número de tabelas é reduzido pelo fato
de existirem dimensões ligadas a uma tabela de fatos central, logo o gerenciador pode
trabalhar com um número menor de chaves.
Kim (1995) cita ainda, que é útil ter uma análise de ER antes de embarcar em um projeto
dimensional porque a equipe de data warehouse entenderá melhor os dados desta forma.
Porém, a equipe tem que fixar à parte o diagrama ER durante o processo de projeto do data
warehouse porque a modelagem dimensional tem que proceder de uma perspectiva de
usuário, em lugar de uma perspectiva de dados.
O’Brien (2001) cita uma vantagem dos bancos de dados multidimensionais:
“Um dos maiores benefícios dos bancos de dados multidimensionais é que eles são uma maneira compacta e inteligível de visualizar e manipular elementos de dados que possuem muitas inter-relações. Por isso, os bancos de dados multidimensionais se tornaram a estrutura mais popular para os bancos de dados analíticos que suportam aplicações OLAP, nas quais se esperam respostas rápidas para consultas comerciais complexas” (O’BRIEN, 2001).
3.4.2 Armazéns de dados
Segundo Laudon e Laudon (1999) , um grande problema que as empresas enfrentam é o
armazenamento de dados em muitos sistemas diferentes, o que a gera a incapacidade de
proporcionar uma visão consolidada de informações utilizáveis por toda a empresa. Para ele, a
solução para este problema é construir um armazém de dados (data warehouse).
Para Petkovic (1999), o Data Warehouse é um armazém de dados em que os usuário finais
podem executar consultas ad-hoc e relatórios para analisar dados existentes, sendo que as suas
propriedades mais importantes são:
• Operações de gravação (carga) periódicas com consultas baseadas em um grande
número de linhas;
• Pequeno número de usuários e
37
• Tamanho grande de dados armazenados em um banco de dados.
Laudon e Laudon (1999) , complementa com a seguinte afirmação:
“Um armazém de dados é um banco de dados que consolida dados extraídos de diversos sistemas de produção e operacionais em um grande banco de dados que pode ser utilizado para relatórios e análises gerenciais. Os dados dos sistemas de processamento das principais transações da organização são reorganizados e combinados com outras informações, inclusive dados históricos, de modo que possam ser usados para a tomada de decisões e análise gerenciais” (LAUDONE LAUDON, 1999).
Machado (2000) corrobora esta idéia, afirmando que um data warehouse representa uma
grande base de dados, capaz de integrar, de forma concisa e confiável, as informações de
interesse para a empresa, que se encontram espalhadas pelos sistemas operacionais e em
fontes externas, para posterior utilização nos Sistemas de Apoio à Decisão.
Laudon e Laudon (1999) explica que os data warehouse muitas vezes dispõem de recursos
para remodelar os dados. Um banco de dados relacional permite visões em duas dimensões,
como vendas por região. Uma visão multidimensional de dados permite que os usuários
vejam os dados em mais de duas dimensões (vendas por região por trimestre, por exemplo). A
Figura 4 apresenta uma representação de um data warehouse.
38
FIGURA 4 - MODELO DE DATA WAREHOUSE
Fonte: Adaptado de Machado (2000)
A FIGURA 4, apresentada anteriormente, mostra como os dados de um data warehouse
devem ser cuidadosamente montados a partir de diferentes origens. Segundo Petkovic (1999),
os dados extraídos são convertidos para um esquema intermediário e movidos para uma área
de trabalho temporária. Para a extração dos dados, são necessárias ferramentas que extraiam
exatamente os dados que devam ser armazenados no data warehouse. No próximo passo, a
limpeza dos dados garante a integridade daqueles que serão armazenados no banco de dados
alvo. A limpeza deve ser feita em entradas incorretas nos campos de dados. O último passo
envolve um processo de validação que especifica os dados de acordo com a maneira pela qual
o usuário final deverá vê-los e acessá-los.
Petkovic (1999) explica que, além de ter carregamento de dados executados em intervalos
regulares (normalmente, diariamente), os data warehouse são de somente leitura. Os dados
são reunidos de diferentes fontes, limpos (tornados coerentes) e carregados em um banco de
39
dados chamado data warehouse ou data mart (que será explicado na próxima seção).
Petkovic (1999) afirma ainda que, como os sistemas de data warehouse são usados para obter
informações, o número de usuários que utilizam simultaneamente tal sistema é relativamente
pequeno. No entanto, como os data warehouse devem controlar dados históricos (os sistemas
de data warehouse fazem comparações entre dados reunidos em diferentes períodos de
tempo), o volume de dados armazenados é muito grande (Alguns contêm até 500GB ou mais).
Além disso, como os data warehouse devem abranger a empresa, normalmente a
implementação leva de dois a três anos.
3.4.3 Características de um Data Warehouse
Segundo Inmon (1997), Data Warehouse é um conjunto de dados baseados em assuntos,
integrado, não-volátil, e variável em relação ao tempo e de apoio às decisões gerenciais. De
acordo com Oliveira (1998) estas características poderão ser descritas de forma mais
detalhada:
a) Orientados por assunto: os dados devem se orientar para os maiores assuntos da
organização, como por exemplo: clientes, produtos, atividades, contas. O DW é criado
baseando-se em algum tema específico que a empresa precisa analisar. Estes assuntos
podem ser subdivididos para uma melhor compreensão ou diminuir a complexidade;
b) Integrados: segundo Oliveira (1998), o DW recebe os dados de um grande número de
fontes. Cada fonte contém aplicações, que tem informações que são incompatíveis com
aplicações encontradas em outras fontes. O filtro é a tradução necessária para
transformar as muitas fontes de dados consistente em uma base, este processo de
extração é chamado de integração. Pode-se tomar como exemplo o dado sexo. Enquanto
um determinado sistema do financeiro armazena sexo Masculino como 1 e Feminino
como 2, um outro sistema do faturamento na mesma empresa pode armazena-los como
M e F. Faz-se necessário, portanto, integrá-los conforme um dos dois modos;
c) Não-voláteis: define que os dados no sistema operacional são manipulados e acessados
um de cada vez. Já em um DW é diferente, os dados são carregados e acessados em
massa, e as atualizações ocorrem de tempos em tempos;
d) Histórico: Os dados do sistema operacional podem ou não conter algum elemento de
tempo, já para o DW, o elemento tempo é fundamental. Enquanto em sistemas
operacionais, os dados permanecem por um curto prazo de tempo, um DW armazena
40
informações de vários anos (5 a 10 em média). Este histórico é que possibilita uma
análise gerencial do comportamento do negócio.
3.4.4 Granularidade e particionamento
Segundo Oliveira (1998), granularidade envolve o nível de detalhe para sumarização de cada
unidade de dado. Mais detalhe é caracterizado por um baixo nível de granularidade, enquanto
menos detalhes caracteriza um alto nível de granularidade. A decisão sobre o nível de
granularidade afeta tanto o volume de dados contido no DW, quanto o tipo de pesquisa que
pode ser respondida.
Em um projeto de DW com um baixo nível de granularidade, pode-se responder a qualquer
consulta, contudo será necessário a utilização de uma grande quantidade de recursos para
armazenar e percorrer todos os registro até atingir a resposta solicitada. Em um DW com um
nível mais alto de granularidade, são necessários bases de dados menores, sem contar a
redução de tempo e processamento para atender determinada solicitação. Porém, à medida
que o nível de granularidade aumenta, há uma diminuição da possibilidade de utilização dos
dados para atender às consultas, fato que pode ser verificado na figura 5. No entanto, no
ambiente de DW é mais comum ocorrer a utilização de uma visão de conjunto dos dados,
pois, dificilmente um evento isolado é examinado.
41
FIGURA 5 – NÍVEIS DE GRANULARIDADE Fonte: INMON (1997)
Quando uma organização possui grandes quantidades de dados no DW, faz sentido pensar em
dois (ou mais) níveis de granularidade. De acordo com Inmon (1997), com a criação de dois
níveis de granularidade é possível atender a todos tipos de consultas, pois a maior parte do
processamento analítico dirige-se aos dados levemente resumidos que são compactos e de
fácil acesso. Para ocasiões em que um maior nível de detalhe deve ser investigado, existe o
nível de dados históricos. O acesso aos dados do nível histórico é caro, incômodo e complexo,
mas caso haja necessidade de alcançar esse nível de detalhe, ele existirá.
Segundo Inmon (1997), depois da granularidade o particionamento é a questão mais
importante em um projeto de DW. Refere-se à repartição dos dados em unidades físicas
separadas que podem ser tratadas independentemente
De acordo com Oliveira (1998), quanto menores as unidades físicas, mais rápido o acesso.
Uma unidade de dado é única para cada partição. Particionamento é acompanhado da
aplicação dos seguintes critérios: data, linha de negócios, geografia, unidade organizacional e
todos os anteriores. Inmon (1997) acrescenta que no DW, as questões referentes ao
particionamento de dados não enfocam a necessidade de o particionamento ser feito ou não,
mas como ele deve ser feito.
3.4.5 Data Mart
Devido às desvantagens da implementação de um data warehouse, muitas empresas começam
com uma solução menor, chamada de data marts.
Machado (2000) explica que os Data Marts são subconjuntos de dados de um data
warehouse. Nesta arquitetura, os dados do data mart são direcionados a um departamento ou
a uma área específica do negócio.
Para Petkovic (1999), os data marts são armazenamentos de dados que incluem todos os
dados departamentais, portanto, permitem aos usuários acessar dados relativos apenas a uma
parte de sua organização. Por isso, um data mart tem várias vantagens em relação a um data
42
warehouse:
• Área de aplicação mais restrita;
• Tempo de desenvolvimento e custo menores;
• Manutenção de dados mais fácil;
• Desenvolvimento de baixo para cima (Bottom-Up).
Petkovic (1999) afirma ainda que, o tempo gasto no desenvolvimento de um data mart é, em
média, de três a cinco meses. Por esses motivos, o desenvolvimento de um data mart é
preferido, especialmente se esse for o primeiro projeto de data warehouse de uma
organização.
Dentre vários tipos de implementação das arquiteturas dos data marts, Machado (2000)
também cita a implementação de um data mart no modelo Bottom-Up:
“Este tipo de implementação permite que o planejamento e o desenho dos Data Marts possam ser realizados sem esperar que seja definida uma infra-estrutura corporativa para Data Warehouse na empresa. Essa infra-estrutura não deixará de existir, só que ela poderá ser implementada incrementalmente conforme forem sendo realizados os Data Marts” (MACHADO, 2000).
Petkovic (1999) explica que, se uma organização projetar e desenvolver vários data marts,
será possível unificá-los em um grande data warehouse.
Machado (2000) ressalta que um dos grandes problemas desta implementação é a falta de um
gerenciador que garanta padrões únicos de metadados(responsáveis pela definição das
estruturas e dos processos de transformação desejados), mesmo com a independência dos data
marts:
“A dificuldade em garantir essa padronização é responsável pela falha na elaboração incremental do Data Warehouse. Podem ocorrer redundâncias de dados e inconsistências entre os Data Marts, que podem ser minimizadas por um planejamento, monitoração e estabelecimento de regras de desenvolvimento (metodologias). Com uma estrutura de múltiplos Data Marts, o processo de extração pode tornar-se crítico na interferência junto aos sistemas transacionais” (MACHADO, 2000).
Machado (2000), lembra da importância de escolher o tipo correto de implementação:
“A abordagem da implementação escolhida é uma decisão que pode causar dramáticos impactos quanto ao sucesso de um projeto de Data Warehouse.
43
Muitas variáveis afetam a escolha da implementação e arquitetura, entre elas o tempo para a execução do projeto, o retorno do investimento a ser realizado, a velocidade dos benefícios da utilização das informações, a satisfação do usuário executivo e os recursos necessários à implementação de uma arquitetura” (MACHADO, 2000).
Petkovic (1999) explica que como o desenvolvimento de data warehouse tem por base as
consultas que operam em um grande volume de dados, que não são simples e levam grandes
períodos de tempo para serem implementados, tabelas altamente normalizadas não são
convenientes para o projeto de data warehouse, pois o objetivo desses sistemas é
significativamente diferente, ou seja existem poucas transações concorrentes, e cada transação
acessa um número muito grande de registros. Assim, Petkovic (1999) afirma que, os data
warehouse não podem usar o modelo ER, pois este é usado para projetar bancos de dados que
não sejam redundantes. O modelo lógico usado para o projeto de data warehouse é chamado
de modelo dimensional (ou multidimensional).
3.5 MODELO MULTIDIMENSIONAL
Nesta seção, aborda-se os passos necessários para a modelagem multidimensional dos dados,
outro ponto fundamental para o desenvolvimento do SIGBO. Mostra-se também, como este
modelo pode ser apresentado e as operações que ele deve oferecer.
Petkovic (1999), comenta a grande diferença entre a modelagem ER e a modelagem
multidimensional:
“Em contraste com os bancos de dados operacionais que usam modelos ER para seu projeto, o projeto dos data warehouse é melhor realizado usando-se um modelo dimensional. Esses dois modelos apresentam diferenças significativas: se você já estiver familiarizado com o modelo ER, a melhor maneira de aprender e usar o modelo dimensional será esquecer tudo sobre o modelo ER e começar o modelagem desde o início” (PETKOVIC, 1999).
Petkovic (1999) explica que, na modelagem multidimensional, todo modelo é composto de
uma tabela que armazena medidas e várias outras que descrevem as dimensões. A primeira é
chamada de tabela de fatos e as últimas, tabelas de dimensão.
Machado (2000) corrobora essa idéia, afirmando que um modelo multidimensional possui três
elementos básicos: Fatos, Dimensões e Medidas.
44
Petkovic (1999) explica que, cada tabela de dimensão normalmente tem uma chave primária
de uma parte e vários outros atributos que descrevem detalhadamente essa dimensão. Por
outro lado, a chave primária da tabela fato é a combinação das chaves primárias de todas as
tabelas da dimensão. Por esse motivo, a chave primária da tabela de fato é constituída de
várias chaves estrangeiras (o número de dimensões também especifica o número de chaves
estrangeiras na tabela de fato).
3.5.1 Fatos e medidas
Segundo Machado (2000), em um modelo multidimensional, fato é uma coleção de itens de
dados, composta de dados de medidas e de contexto. Cada fato representa um item de
negócio, uma transação de negócio ou um evento de negócio, e é utilizado para analisar o
processo de negócio de uma empresa. Um fato é evolutivo, muda suas medidas com o tempo,
podendo ser sempre questionado sobre esta evolução ao longo de um espaço de tempo.
Para Petkovic (1999), outra diferença na natureza dos dados em uma tabela de fato e nas
tabelas de dimensão correspondentes é que a maioria das colunas da primeira são numéricas e
aditivas, pois tais podem ser usados para executar os cálculos necessários. Por outro lado, as
colunas de tabelas dimensão são strings que contêm descrições textuais da dimensão.
Medidas são os atributos numéricos que representam um fato, representam à performance de
um indicador de negócios relativo às dimensões que participam desse fato. Uma medida é
determinada pela combinação das dimensões que participam de um fato, e estão localizadas
como atributos de um fato (MACHADO, 2000).
A figura 6 demonstra um exemplo de uma tabela de fato com suas ligações as devidas
dimensões.
45
FIGURA 6 – TABELA DE FATO E DIMENSÕES Fonte: RUBINI (1999)
3.5.2 Dimensões
Uma dimensão pode ser qualquer visão do negócio que faça sentido para sua análise, como
produto, departamento ou tempo. Este modelo de dados multidimensional simplifica para os
usuários o processo de formular pesquisas ou "queries" complexas, criar relatórios, efetuar
análises comparativas, e visualizar subconjuntos (slice) de maior interesse.
As dimensões são agrupadas em hierarquias, cada hierarquia possui níveis e cada nível possui
atributos.
Dentro de cada dimensão de um modelo OLAP, os dados são organizados em uma hierarquia
que define diferentes níveis de detalhe. Por exemplo, dentro da dimensão tempo, você poderá
ter uma hierarquia representando os níveis anos, meses, e dias. Da mesma forma, a dimensão
região poderá ter os níveis país, região, estado e cidade. Assim, um usuário visualizando
dados em um modelo OLAP irá navegar para cima (drill up) ou para baixo (drill down) entre
níveis para visualizar informação com maior ou menor nível de detalhe sem a menor
dificuldade.
A Figura 7 demonstra um exemplo de uma dimensão dividida em vários níveis, como por
exemplo o município dentro da dimensão estado.
FIGURA 7 – DIMENSÃO E NIVEL
Como querem ver as informações?
46
Dimensões:
Data Competência (Total Período, Ano, Trimestre, Mês, Dia)
Procedimento (Total Procedimento, Procedimento)
Fonte Pagadora (Total Fonte Pagadora, Grupo, Fonte Pagadora)
3.5.3 A Visualização de um modelo multidimensional (Cubo)
Modelos Multidimensionais são freqüentemente representados na forma de um cubo. Cada
face do cubo representa uma dimensão da empresa e cada célula contém os dados. O dado é
armazenado de forma que possa ser facilmente sumarizado através de uma estrutura
específica da empresa ou o relacionamento de várias estruturas da empresa (dimensões).
Cubo é um conjunto estruturado de dimensões, hierarquias, níveis e membros.
FIGURA 8 – CUBO COM AS DIMENSÕES PRODUTO TEMPO E VENDAS
Uma base de dados Multidimensional é freqüentemente construída a partir de uma base de
dados relacional (Data Warehouse).
Fatiar o cubo é uma outra forma de falar que o modelo está sendo pesquisado.
Petkovic (1999) explica que os sistemas de data warehouse oferecem suporte a diferentes
47
tipos de armazenamento de dados. Alguns desses tipos têm por base uma banco de dados
multidimensional, que também é chamado de cubo.
“Um cubo é um subconjunto de dados de um data warehouse, que pode ser organizado em estruturas multidimensionais. Para definir um cubo, primeiro você seleciona uma tabela de fato no esquema dimensional e identifica as colunas numéricas de interesse dentro dela. Então você seleciona as tabelas de dimensão que fornecem descrições para o conjunto de dados a ser analisado” (PETKOVIC, 1999).
O cubo é a representação mais popular de um modelo dimensional. No entanto, Machado
(2000) explica que usualmente, um modelo dimensional consiste de mais de três dimensões e
isto é definido como um hipercubo. Visualizar graficamente um hipercubo é muito difícil,
desta forma utiliza-se a referência a cubo para qualquer modelo multidimensional.
Thomsen (2002) lembra que, a noção de um hipercubo é fundamental para o entendimento do
software multidimensional que utiliza hipercubos da mesma forma que as planilhas usam
pastas de trabalho e os bancos de dados usam tabelas. Toda navegação, relatórios e análise são
feitas em termos de hipercubos.
3.5.4 Agregação
Petkovic (1999) explica que os dados são armazenados na tabela de fato em sua forma mais
detalhada, portanto, os relatórios correspondentes podem fazer uso deles. Por outro lado, uma
consulta típica em uma tabela de fato busca milhares ou mesmo milhões de linhas por vez e, a
única operação útil em tal volume de linhas é aplicar uma função agregada (soma, máximo,
média).
Machado (2000), complementa essa idéia afirmando que cálculos simples, como totais de
vendas e médias aritméticas, já são previstas pelo banco de dados multidimensional ao
processar as informações, conforme a configuração da estrutura de dados que for modelada.
O número de agregações em um SGBDM (Sistema Gerenciador de Banco de Dados
Multidimensional) é uma função que depende proporcionalmente do número de dimensões e
dos níveis de hierarquias, os quais influem mais diretamente no volume de dados que teremos
no nosso servidor (MACHADO, 2000).
Machado (2000) lembra ainda que, ao ascender em uma hierarquia dentro de um SGBDM
qualquer, os valores estarão cada vez mais agregados. Sendo assim, um banco de dados
48
multidimensional é composto por um grande conjunto de células com valores referentes aos
cruzamentos de dimensões e medidas. Uma pequena célula de um cubo, por exemplo, poderá
ter o valor de venda para a Região Sul, Vendedor X, dia 22/07/96, Produto 9, Valor de Venda
Bruta.
3.5.5 Operação básica de OLAP
Machado (2000) explica que, assim como para um modelo ER temos que conhecer as
operações básicas de álgebra relacional, no modelo de dados multidimensional temos as
operações OLAP. São quatro operações que o modelo deve suportar: Drill Down, Roll Up,
Slice e Dice.
Machado (2000) afirma que, Drill Down e Roll Up são operações para movimentar a visão do
usuário dos dados ao longo dos níveis hierárquicos de uma dimensão. Com a capacidade de
Drill Down o usuário pode navegar do nível mais alto até o dado mais detalhado. Enquanto
que, com a capacidade Roll Up, o usuário pode navegar do nível mais detalhado até o mais
alto nível de sumarização de dados. Exemplos de Roll Up e Drill Down são apresentados
respectivamente na FIGURA 9 e na FIGURA 10.
FIGURA 9. EXEMPLO DE OPERAÇÃO ROLL UP
49
Fonte: Adaptado de Machado (2000)
FIGURA 10. EXEMPLO DE OPERAÇÃO DRILL DOWN Fonte: Adaptado de Machado (2000)
Slice e Dice são operações para realizar navegação por meio dos dados na visualização de um
cubo. Slice é a operação que corta o cubo, mas mantém a mesma perspectiva de visualização
dos dados. Enquanto que Dice, é a mudança de perspectiva de visão (MACHADO, 2000).
Exemplos de Slice e Dice são apresentados respectivamente na FIGURA 11 e na FIGURA 12.
50
FIGURA 11. EXEMPLO DE OPERAÇÃO SLICE – FATIAMENTO DE UM CUBO
FIGURA 12. EXEMPLO DE OPERAÇÃO DICE Fonte: Adaptado de Machado (2000)
3.6 OLAP – ON-LINE ANALYTICAL PROCESSING A necessidade de receber um grande número de dados de um grande banco de dados são os
motivos de existir o OLAP (não é um aplicativo, é uma arquitetura de aplicação).
Quando temos a necessidade de um sistema multidimensional precisamos de um OLAP. É
51
uma forma diferenciada de armazenamento dos dados privilegiando a performance e a
flexibilidade de consultas.
Em um modelo de dados OLAP, a informação é conceitualmente organizada em cubos que
armazenam informações, por exemplo, um cubo contendo informações de vendas poderá ser
composto pelas dimensões tempo, região, produto, cliente e medidas. Medidas seriam valor
de venda, unidades vendidas, custos, margem, etc.
O termo OLAP (On-Line Analytical Processing) possui vários significados. Esta variedade de
significados se deve ao fato de que os principais elementos presentes no OLAP são
manifestáveis em diversas camadas de tecnologia, desde armazenamento e acesso até as
camadas de linguagem.
Segundo Thomsen (2002), é possível diferenciar conceitos OLAP, camadas de produtos
OLAP e produtos OLAP completos:
• Camadas de produtos OLAP normalmente residem em cima dos bancos de dados
relacionais e geram SQL como saída da combinação. O armazenamento e o acesso aos
dados são tratados pelo banco de dados
• Produtos OLAP completos precisam incluir um compilador e métodos de armazenamento
e acesso, são otimizados para acesso a dados e cálculos rápidos, sendo usados para
modelagem descritiva de dados, derivada de sistemas de suporte à tomada de decisão.
3.6.1 Exemplos de OLAP
É possível encontrar variantes para o termo OLAP, normalmente é acrescentada uma
consoante na frente do termo para classificar a ferramenta quando à sua arquitetura.
Thomsen (2002) afirma que os usuários originais das variações do termo OLAP foram
empresas que estavam vendendo camadas de produtos OLAP em cima dos sistemas de banco
de dados relacional, elas emitiam SQL ao banco de dados em resposta à entrada do usuário,
oferecendo somente capacidades secundárias de cálculo OLAP, utilizando o termo ROLAP
(Relational OLAP). Assim, os vendedores não ROLAP, passaram a ser rotulados como
MOLAP, para indicar OLAP Multidimensional. Desde então, surgiram os termos DOLAP
(usado para Desktop OLAP e Database OLAP), HOLAP (Hybrid OLAP), WOLAP
52
(Web OLAP) e MROLAP (Mobile and Remote OLAP).
“A maioria das organizações precisa de alguma mistura de capacidades que, se precisasse de uma qualificação por letra, seria HOLAP. Mas, como qualquer conhecimento apropriado de OLAP distinguiria entre a linguagem ou aspectos lógicos do OLAP e sua implementação física, tal conhecimento apropriado do OLAP revela que, fisicamente, ele pode ser de qualquer espécie. Assim, o conceito do H já está incluído nas características físicas do OLAP e nenhuma espécie de letra adicional é necessária” (THOMSEN, 2002).
Para O’Brien (2001), o OLAP fornece respostas rápidas para consultas complexas colocadas
por gerentes e analistas, permitindo a análise e manipulação interativa de enormes
quantidades de dados detalhados e consolidados a partir de múltiplas perspectivas, utilizando
sistemas de informação gerencial, apoio à decisão e sistemas de informação executiva.
A grande vantagem das soluções que utilizam OLAP é que o usuário não precisa ter
conhecimento técnico sobre o modelo de dados ou da linguagem de consulta para produzir a
informação desejada, o acesso aos dados passa a ser transparente. O usuário tem apenas que
lidar com os termos do negócio ao qual ele já está habituado (Leitão, 2000).
3.6.2 Requisitos funcionais para OLAP
Uma solução para ser considerada como OLAP, deve possuir alguns requisitos, que Thomsen
(2002) definiu da seguinte maneira:
“Os requisitos centrais, raiz, necessários ou mínimos no lado lógico, incluem suporte para múltiplas dimensões, hierarquias, fórmulas dimensionais e a separação de estrutura de dados e representação. Fisicamente, o principal requisito é velocidade suficiente para oferecer suporte à análise ocasional. Qualquer linguagem ou produto que não aceite pelo menos esses requisitos não pode, com seriedade, ser classificado como oferecendo suporte a OLAP” (THOMSEN, 2002).
Principais Requisitos Lógicos: Thomsen (2002) explica que, o reconhecimento de que
vivemos em um mundo caracterizado por conjuntos altamente multidimensionais de
subsistemas em interação, cada qual com muitos níveis de dados, detalhe, realidade ou
abstrações, é uma percepção fundamental. A capacidade das ferramentas OLAP de
modelarem com eficiência essa complexidade é uma de suas contribuições fundamentais, por
isso o modelo deve possuir uma estrutura dimensional rica com referência hierárquica.
Necessita de uma especificação eficaz de dimensões e cálculos, pois a maior parte das
informações importantes a serem colhidas resulta da comparação inteligente entre razões e
53
tendências deduzidas com o tempo e outras dimensões. Em um sistema OLAP, os cálculos
precisam ser tão simples de se definir quanto de dizer. Para oferecer funcionalidade OLAP
verdadeira, a ferramenta precisa conter uma linguagem de cálculo sofisticada (THOMSEN,
2002).
Para Thomsen (2002), flexibilidade é outro componente crucial da funcionalidade OLAP.
Existe visualização flexível, definição flexível e interface flexível. Os sistemas precisam ser
flexíveis em todas essas maneiras.
• A flexibilidade da visualização significa que o usuário pode escolher facilmente ver
informações na forma de gráficos, matrizes ou diagramas. O usuário pode selecionar
como a informação é mapeada para o formato de visualização;
• Em termos de definições, quem tiver a autoridade relevante deverá ser capaz de mudar
os nomes dos descritores, a formatação dos números e as definições de fórmulas, os
gatilhos para processos automáticos ou o local dos dados de origem sem incorrer em
qualquer penalidade indevida.
• A flexibilidade ou facilidade de uso da interface, que afeta a capacidade do usuário de
definir rapidamente o que ele deseja fazer. Não há vantagem em se ter um sistema
rápido e poderoso se o usuário não puder entender o que ele está dizendo. Para atrair o
usuário é necessário que o sistema seja amigável.
Necessita de separação de estrutura e representação. Ter essa separação significa que os
modos de exibição podem ser reorganizados por um usuário final sem que se façam quaisquer
mudanças estruturais nos dados (THOMSEN, 2002).
Principais Requisitos Físicos: Thomsen (2002) afirma que, velocidade é um componente
crucial do OLAP. Significa manter a linha de pensamento. OLAP precisa oferecer suporte a
consultas analíticas ocasionais, algumas delas podendo exigir cálculos realizados no ato.
“O desafio hoje é que os sistemas ofereçam um tempo de resposta muito rápido para pedidos de acesso e cálculo, enquanto trabalham com grandes conjuntos de dados em um ambiente multiusuário distribuído em uma rede. Algumas ferramentas oferecem isso pré-calculando todas as agregações. Mesmo que alguém pudesse armazenar todos os resultados pré-calculados, o aumento no tamanho do banco de dados pode realmente impedir quaisquer ganhos feitos ao tempo de resposta da consulta por meio do pré-cálculo. Para que haja um acesso com o máximo de eficiência, as ferramentas precisam oferecer a combinação certa de resultados pré-calculados e calculados no momento da consulta” (THOMSEN, 2002).
54
Thomsen (2002) não considera que o suporte para multiusuário seja um requisito necessário,
mas acha importante destacar este recurso devido à preponderância de servidores OLAP e à
praticidade do suporte multiusuário.
3.7 MICROSOFT SQL SERVER
Existem várias ferramentas que podem ser utilizadas para construção de cubos e
armazenamento de dados, porém para este trabalho de conclusão de curso será visto apenas o
SQL SERVER, pois será a ferramenta utilizada para armazenagem dos dados já modelados e
construção dos cubos na empresa JUNIOR.
Neste ítem, enfatiza-se a importância do SQL Server dentro do SIGBO. Mostram-se as
vantagens da utilização deste gerenciador de banco de dados em um sistema
multidimensional.
Petkovic (1999) explica que o SQL Server é um SGBDR (Sistema de Gerenciamento de
Banco de Dados Relacional) para computação cliente-servidor distribuída. Assim como todos
os outros sistemas de gerenciamento de banco de dados, ele fornece os seguintes recursos:
• Uma variedade de interfaces com o usuário;
• Independência física dos dados;
• Independência lógica dos dados;
• Otimização de consulta;
• Integridade de dados;
• Controle de concorrência;
• Backup e recuperação e
• Segurança e autorização.
Petkovic (1999) ressalta ainda, que as vantagens mais importantes do Microsoft SQL Server
em relação a outras ferramentas existentes no mercado são:
• O SQL Server funciona como uma extensão natural do Windows;
• O SQL Server é relativamente fácil de gerenciar, através do uso de um ambiente de
55
computação gráfico para quase todas as tarefas de sistema e administração de banco de
dados;
• O SQL Server usa serviços do Windows NT para fornecer recursos de bancos de dados
novos ou ampliados, como o envio e recebimento de mensagens e o gerenciamento de
segurança de login;
• O SQL Server é fácil de usar;
• O SQL Server pode passar de um laptop móvel para sistemas de multiprocessamento
simétrico e
• O SQL Server fornece recursos de armazenamento de dados que até então estavam
disponíveis apenas no Oracle e em outros sistemas mais caros.
3.7.1 DSS - Decisions Support Services
Petkovic (1999) explica que, é necessário diferenciar os sistemas usados para objetivos
operacionais (sistemas que exigem acesso rápido e transações curtas) dos sistemas usados
para objetivos analíticos (sistemas que usam operações de recuperação complexas em bancos
de dados enormes), pois essas duas tarefas não podem ser conseguidas da melhor forma
usando-se apenas um servidor de banco de dados. Por essa razão, o SQL Server (a partir da
versão 7) vem com os MS Decision Support Services (DSS). Assim, o SQL Server pode ser
usado para objetivos operacionais, enquanto os DSS são usados para objetivos analíticos.
Segundo Petkovic (1999), todos os componentes do DSS podem ser divididos em três grupos:
• MS Excel;
• Extensões SQL concernentes ao DSS
• Software-cliente de terceiros.
Petkovic (1999) explica que o SQL Server oferece algumas extensões para a declaração
SELECT que podem ser usadas especialmente para operações de apoio à decisão. Essas
extensões são:
• Operador CUBE;
• Operador ROLLUP e
56
• Cláusula TOP n.
Os dois operadores, CUBE e ROLLUP, são usados para incluir linhas de resumo no
resultado de uma declaração SELECT com a cláusula GROUP BY. A cláusula TOP n
fornece a recuperação das n primeiras linhas de um resultado de consulta (normalmente
classificado por meio de alguns critérios).
A cláusula GROUP BY define uma ou mais colunas como um grupo, de modo que todas as
linhas dentro de qualquer grupo tenham os mesmos valores dessas colunas. O operador CUBE
introduz linhas adicionais, chamadas linhas de resumo, no resultado de uma declaração
SELECT. Uma linha de resumo GROUP BY é retornada para cada combinação possível de
grupo e subgrupo no resultado (PETKOVIC, 1999).
Petkovic (1999) explica que, em contraste com o operador CUBE, que retorna cada
combinação possível de grupos e subgrupos, a hierarquia de grupo usando-se o operador
ROLLUP é determinada pela ordem em que o agrupamento das colunas é especificado.
3.7.2 Assistentes do DSS
Petkovic (1999) relata que o DDS oferece assistentes para quase todas as tarefas executadas
durante o projeto e a implementação de um data warehouse ou data mart. O Cube Wizard,
por exemplo, é usado para criar um cubo multidimensional no qual os dados agregados são
armazenados, enquanto o Dimension Wizard permite que sejam criadas tabelas de dimensão
compartilhadas ou privativas (As dimensões compartilhadas podem ser usadas por qualquer
cubo existente no sistema).
Petkovic (1999) explica ainda que, em contraste com a maioria dos outros servidores de data
warehouse, o DSS permite a utilização do modo de armazenamento mais adequado para um
sistema de data warehouse específico, possibilitando escolher entre MOLAP, ROLAP e
HOLAP.
Conforme já explicado na Seção 3.6.1 MOLAP é usado para armazenar dados de base e todas
as agregações em um cubo multidimensional, oferecendo o melhor desempenho para
consultas ad hoc. O ROLAP armazena todos os dados em tabelas relacionais, reduzindo assim
o volume de dados. Se os dados de base e todas as agregações forem separadas para que os
primeiros sejam armazenados em tabelas relacionais e as últimas, no cubo multidimensional,
57
o tipo de armazenamento será chamado HOLAP.
3.7.3 Componentes do DSS
Petkovic (1999) explica que o DSS possui três componentes que são usados para diferentes
propósitos:
• Repositório;
• OLAP Manager;
• Data Transformation Services (DTS).
Um repositório, segundo Petkovic (1999), é um armazenamento de dados (normalmente um
banco de dados) que contém informações a respeito de vários grupos de interesse para o
próprio sistema (essas informações são chamadas metadados). No caso do DSS, as
informações são armazenadas em um banco de dados relacional.
Os metadados constituem-se no principal recurso para a administração dos dados e assumem
uma maior impotância no ambiente de Data Warehouse. Em um ambiente operacional, os
metadados são importantes para o desenvolvedores e administradores do banco de dados. Por
outro lado, o ambiente de apoio à tomanda de decisão é bastante distinto, sendo que nele os
analistas de dados procuram por fatos não usuais. Seus usuários precisam examinar seus
dados e, para isso, devem conhecer sua estrutura e significado.
O OLAP Manager, segundo Petkovic (1999), é uma ferramenta que fornece uma interface
interativa para acessar os dados do DSS e o repositório. Os administradores de sistema e os
usuários finais podem usar o OLAP Manager para definir os bancos e dados e as origens dos
dados, definir e editar dimensões e gerenciar a segurança do servidor.
Petkovic (1999), relata também, que o DSS oferece o Data Transformation Services (DTS),
onde é possível extrair dados de diferentes origens de dados (como bancos de dados Access,
Oracle, SQL Server e arquivos de texto), transformá-los e carregá-los em um data warehouse:
“O DTS é a ferramenta de escolha para uma fase inicial do processo de construção de data warehouse, chamada de fase de consolidação dos dados. Nessa fase, os dados são extraídos de diferentes origens e convertidos para um esquema intermediário. Depois disso, os dados são limpos, isto é, todos os dados extraídos são verificados e os formatos e tipos diferentes dos mesmos dados são unificados. Finalmente, eles são verificados para ver se atendem aos requisitos já existentes” (THOMSEN, 2002).
58
4. PLANEJAMENTO
O levantamento de dados efetuado para o presente TCC buscou fundamentalmente analisar a
sistemática atual de trabalho da empresa e, mais especificamente, do Departamento Comercial
da JUNIOR, identificando critérios, regras de negócios, procedimentos utilizados, fluxo de
informações interno, documentos utilizados, forma de relacionamento entre si no tocante à
troca de informações, bem como as principais necessidades e dificuldades hoje existentes para
um melhor desempenho de suas funções.
O levantamento foi executado através de visitas às instalações e entrevistas junto aos diversos
setores, procurando identificar os principais objetivos e metas estratégicas da JUNIOR e o seu
impacto sobre os sistemas de informações existentes.
As áreas/funções envolvidas no levantamento foram:
Diretoria
Gerência de Vendas
Vendas Representantes
Gerência Administrativa/Financeira
Gerência Técnica
Informática
A elaboração deste planejamento deu-se com base nas informações obtidas junto aos usuários
consultados. Os resultados apresentados são estimativas compiladas a partir da adequação das
necessidades identificadas na JUNIOR, com soluções comumente encontradas no mercado de
informática. Com o desenrolar da execução deste planejamento, diversos fatores,
principalmente de ordem cultural, financeira e comercial, poderão resultar em desvios
positivos ou negativos da referência central, razão pela qual a revisão deverá ser permanente.
59
4.1 DIAGNÓSTICO PRÉVIO ÁREA DE INFORMÁTICA
* QUANTO AOS HARDWARES UTILIZADOS
- 2 servidores (1 servidor ORACLE e 1 servidor SQL SERVER)
- 38 estações de trabalho, assim segmentados:
- Fábrica - 06 microcomputadores.
- Escritório – 32 microcomputadores.
- Impressoras:
- 8 deskjet.
- 2 matriciais.
* QUANTO AOS SOFTWARES BÁSICOS UTILIZADOS - Controlador operacional de rede – Windows 2003 SERVER; - Softwares de apoio: MS-EXCEL (Planilha Eletrônica que será utilizada como ferramenta de navegação do usuário). - B. Dados ORACLE (banco relacional no qual estão inseridas as informações pelo usuário nas operações diárias da empresa, como nota fiscal, contas a pagar, contas a receber e outras) - B. Dados SQL SEVER (banco que receberá a carga do banco relacional ORACLE e fará a conversão para OLAP) - Sistema de Gestão MICROSIGA (sistema de gestão empresarial utilizada para realizar as
funções da área comercial)
4.2 DIAGNÓSTICO PRÉVIO DA ÁREA COMERCIAL
- Gerência de Vendas necessita de informações mais ágeis de Análise de Crédito, PCP e
Produção para Gestão Comercial (tomada de decisões e negociação com clientes).
- Alguns pontos identificados como gargalo no fluxo do Processo Comercial:
• Digitação dos Pedidos;
60
• Avaliação de Crédito;
• PCP/ Produção.
- Acompanhamento dos tempos de entrega dos pedidos.
- As informações sobre acompanhamento de vendas (Rentabilidade, Preço Médio) não estão
disponibilizadas em tempo hábil para decisões, ocorrendo após os fatos acontecidos.
- Representantes:
• Falta de comprometimento quanto às especificações dos produtos;
• Envio de pedidos de venda com informações incompletas.
4.3 DIAGNÓSTICO PRÉVIO DA ÁREA ESTRATÉGICA
Alguns pontos devem ser considerados quantos aos aspectos estratégicos/gerenciais da
organização, que foram observados, como segue:
• Os Sistemas de Informações Gerenciais, voltado para a alta administração e gerências
intermediárias, são basicamente elaborados de modo manual, buscando-se seus dados de
relatórios estáticos no Sistema de Gestão Microsiga.
• Observa-se que os dados oriundos dos sistemas informatizados sofrem alguns ajustes e
complementações, o que caracteriza deficiência de seus sistemas, que podem não ser
confiáveis. Portanto, para este trabalho, buscou-se modelar os dados já considerados
confiáveis, como notas de entrada, notas de saída, notas de devoluções, comissões pagas e
outras, garantindo a veracidade das informações.
• O problema atual, que resulta no objetivo deste trabalho, é o fato de existirem diferenças
entre os relatórios relacionais do MICROSIGA e os relatórios montados manualmente para a
gerência. Portanto, os dados gerenciais têm de possuir a mesma origem dos relatórios
relacionais.
• Devido à crescente necessidade de agilidade das informações, principalmente na área de
61
decisões das organizações, é fundamental que os dados sejam únicos e confiáveis,
provenientes diretamente dos sistemas, para que as empresas sejam competitivas num
mercado cada vez mais acirrado.
62
5. DESENVOLVIMENTO DO SISTEMA PROPOSTO
5.1 INTRODUÇÃO
Neste capítulo descreve-se toda a metodologia utilizada no desenvolvimento do sistema de
informação. Na primeira seção, contextualizam-se as fases de desenvolvimento, a
especificação tecnológica envolvida, os resultados esperados e algumas considerações
realizadas. A segunda e terceira seções apresentam, respectivamente, a modelagem funcional
do sistema e a modelagem entidade-relacionamento. Finalizando este capítulo, o sistema de
apoio à decisão é apresentado. Será feito uma referencia da parte teórica juntamente com a
parte pratica para facilitar o entendimento acadêmico.
5.2 METODOLOGIA DE DESENVOLVIMENTO
Conforme FURLAN (1994), a metodologia para desenvolvimento e elaboração de um sistema
de informação, apresentada na Figura 13, é composta pelas seguintes fases e estágios:
Planejamento, Projeto e Implantação.
FIGURA 13. METODOLOGIA PARA SISTEMA DE INFORMAÇÃO. Fonte: Furlan (1994).
Planejamento
A fase de planejamento tem por objetivo definir conceitualmente o sistema de informação por
meio da identificação das necessidades de informação e do estilo decisório do Executivo,
63
bem como da estrutura básica do sistema e do protótipo preliminar de telas, conforme
demonstrado na Figura 14.
FIGURA 14 : COMPONENTES DA FASE DE PLANEJAMENTO. Fonte: Furlan, (1994).
Esta fase é composta por cinco estágios, os quais podem ser observados na Figura 15: FIGURA 15: OBJETIVOS DA FASE DE PLANEJAMENTO.
Fonte: Furlan, (1994)
Estágio I
- Organização do Projeto: A equipe de trabalho foi treinada nas técnicas de levantamento de
dados e análise dos fatores críticos de sucesso, nas quais foram identificadas quais
informações os Executivos já recebem, por meio de questionário específico identificado no
anexo 01 deste trabalho. As tarefas deste estágio foram: estabelecer a equipe de trabalho;
conduzir reunião de abertura de projeto; anunciar o projeto à empresa; iniciar o levantamento
das informações que os Executivos recebem; finalizar o plano de trabalho; levantar as
64
necessidades dos sistemas e bases de dados que serão trabalhadas em duas etapas, a base
relacional para a qual será utilizado o banco de dados ORACLE e a base multidimensional
para a qual será utilizado o banco de dados SQL SERVER. Este estagio foi desenvolvido para
esta trabalho de conclusão de curso conforme reuniões destacadas no item 3.0,
fundamentação teórica.
Estágio II
- Definição de Indicadores: É neste estágio que o Executivo foi entrevistado individualmente
para pudesse ser identificado seus objetivos, fatores críticos de sucesso e necessidades de
informação em seguida, efetuada a documentação para submeter os resultados à revisão.
Antes das entrevistas, conduziu-se uma sessão de planejamento, a fim de rever os
procedimentos e, traçar uma linha mestra de ação. As tarefas deste estágio são: conduzir o
planejamento da pré-entrevista; conduzir entrevistas aos Executivos; revisar e documentar
entrevistas; obter aprovação da diretoria. Este estagio foi desenvolvido para esta trabalho de
conclusão de curso conforme destacado abaixo:
Premissas das Soluções
Consideram-se algumas premissas básicas, que servirão de norte para as soluções descritas a
seguir:
a) As soluções de informática devem ser independentes do crescimento e evolução da
empresa e de suas transações;
b) O objetivo das soluções é garantir um maior automatismo, reduzindo o volume operacional
manual;
O Modelo Integrado De Informações - Junior
A seguir, apresentam-se as características de integrações e algumas funções chaves do sistema
de gestão de empresas Microsiga, que foram implantadas na JUNIOR em março de 2002,
passando por acertos e ajustes, tendo seus dados mais confiáveis a partir do inicio de 2004,
portanto a empresa já esta apta para implantar uma ferramenta de apoio a decisão, pois já
possui um histórico no banco de dados.
Neste trabalho foi abordada apenas a área comercial, cabendo registrar que seria
65
recomendável implementar futuramente, no sistema de informações modelado neste trabalho,
todas essas áreas, com vistas a obter um diferencial para a JUNIOR.
O modelo Integrado de Informações, proposto a seguir, visa atender tanto o nível operacional
como os níveis Gerencial e Diretivo, com informações que possibilitam uma administração
com maior eficiência, integração, dinamismo e economicidade. Porém, para este trabalho de
conclusão de curso, serão focadas apenas a área comercial e suas variâncias, destacadas
ANÁLISE DECRÉDITO
ADMINISTRAÇÃODE VENDAS
ESTATÍSTICASDE VENDAS ENGENHARIA
PLANEJAMENTODE PRODUÇÃO
PLANO MESTREDE PRODUÇÃOFATURAMENTO
COMPRAS
CONTAS ARECEBER
CONTABILIDADEFISCAL
ESTOQUEMATÉRIA PRIMAE COMPONENTES
CONTABILIDADEPATRIMONIAL
FLUXO DECAIXA
CONTABILIDADEGERAL
CONTROLEDE CUSTOS
CONTROLEDE PRODUÇÃO
ESTATÍSTICASDE PRODUÇÃO
ADMINISTRAÇÃORECURSOSHUMANOS
FOLHA DEPAGAMENTO
CONTAS APAGAR
1
2
1
2
OUTROSINSUMOS
3
COMISSÕES
REPRESENTANTES
3
4
44
FABRICAÇÃO(CLP’s,Cod.Barra,Máq.Inteligentes)
LABORATÓRIO
EXPEDIÇÃO/PLANO
EMBARQUE
MANUTENÇÃOINDUSTRIAL
5
5
FIGURA 16 – MODELO INTEGRADO DE INFORMAÇÕES
O Sistema Proposto Atende Os Seguintes Requisitos Funcionais:
Gestão de Vendas
O processo de gestão de vendas constituído diretamente pelo sistema de controle de pedidos,
apóia-se no crédito, nos clientes, no faturamento, no estoque de peças em disponibilidade e
nas estatísticas. Clientes esta vinculado ao faturamento e crédito são ações baseadas nesse
66
cliente. O importante é que todas as informações necessárias para a gestão das vendas estejam
permanentemente disponíveis e atualizadas a todos os usuários do processo.
Deverá também permitir consultas consolidadas que demonstrem eventuais anomalias no
atendimento, além de estatísticas mensais sobre o comportamento geral das vendas. A carteira
de pedidos está nas regras de negócios, gerando informações sobre os cancelamentos, de
maneira a qualificar a atividade do setor de crédito e automatizar esse controle por ocasião do
faturamento.
* Faturamento
O sistema de faturamento da JUNIOR esta totalmente integrado à carteira de pedidos de
vendas e ao sistema de contas a receber. Desta forma, as regras de negócio destacadas nas
reuniões com os gestores define que um cliente que possua mais de dois títulos em atraso tem
suas novas vendas bloqueadas, excetuando se ocorrer um aval do gerente comercial, portanto
estas aprovações tem de estar em destaque nas consultas do sistema de informação.
Características Dos Sistemas De Vendas
De acordo com o estudo e levantamentos efetuados, observa-se que a sistemática das
operações de vendas segue as características citadas abaixo:
a) O representante, através de sua estação de trabalho, envia o pedido de venda por e-mail,.
citando valores, condições de pagamento, quantidades, códigos de clientes e código dos
produtos identificados através de tabela de preço regularmente atualizada. O pedido de venda
será digitado no sistema MICROSIGA por um funcionários da empresa JUNIOR;
b) O sistema, através de dispositivos internos previamente definidos, faz a avaliação de
crédito do cliente e o autoriza se estiver dentro dos limites aceitáveis, em caso negativo,
repassa à área Financeira para tratamento específico;
c) A equipe interna da JUNIOR verifica se o produto está previamente definido e avisa o
Representante para confirmar especificação. Caso seja produto novo, transfere à área de
desenvolvimento para sua especificação;
d) O MICROSIGA submete o pedido à avaliação para verificar se a data de entrega do
produto está dentro da capacidade de produção da fábrica, considerando as ordens já
67
colocadas, caso contrário, sugere novo prazo;
e) Superados todos estes quesitos, o sistema submete o pedido para planejamento da produção
e fabricação;
f) O MICROSIGA pode, automaticamente, emitir um e-mail ao cliente, confirmando as
condições acordadas e o prazo de entrega, bem como emiti-lo no momento do embarque.
Processo: Autorização de Crédito
a) Este módulo possibilita a JUNIOR manipular informações de Avaliação de Crédito,
permitindo ao sistema liberar pedidos de clientes automaticamente, desde que o cliente e o
pedido atendam a parâmetros pré-definidos pela empresa;
b) Somente serão avaliados manualmente pela área financeira aqueles pedidos e clientes que
fujam às regras pré-estabelecidas
Estágio III
- Análise de Indicadores: O objetivo deste estágio foi normalizar as informações levantadas
durante as entrevistas individuais dos executivos a fim de obter uma lista consolidada de
objetivos, fatores críticos de sucesso, problemas e necessidades de informação. Esta lista é
transformada numa matriz de inter-relacionamento entre os indicadores de desempenho e os
respectivos objetos de interesse dos Executivos. As atividades deste estágio são: consolidar
objetivos, fatores críticos de sucesso e necessidades de informação; classificar objetivos e
fatores críticos de sucesso; conectar fatores críticos de sucesso aos objetivos e às necessidades
de informação; classificar necessidades de informação. Para este trabalho de conclusão de
curso as análises foram feitas conforme destacado abaixo:
Quanto á disponibilidade de Informações
A política básica é de que o computador esteja voltado ao usuário das informações e, para tal,
os sistemas e seus dados deverão ser um importante veículo para se conseguir uma adequada
distribuição de informações nos vários níveis organizacionais da JUNIOR.
Os sistemas atualmente em uso pela JUNIOR, via de regra, contemplam as necessidades de
nível operacional, não levando em conta as chamadas necessidades de uso Gerencial e
Diretivo. Estas informações podem ser caracterizadas em dois níveis distintos: no
68
primeiro nível se inserem as de caráter estatístico, com dados consolidados que apresentam a
característica de serem de emissão ou consulta periódica (normalmente mensais), podendo ser
previamente definidas e estruturadas, sofrendo poucas variações ao longo do tempo e sendo
pouco afetadas por mudanças externas. No segundo nível, aparecem as necessidades de
consultas não estruturadas, eventuais, bastante diversificadas ao longo do tempo e bastante
dependentes das condições do momento. Para estas, o tratamento é bem diferenciado das
anteriores, pois não há como defini-las previamente, exigindo que se coloquem, à disposição
de seus usuários, ferramentas que lhes permitam manipular adequadamente tais necessidades,
acessando as Bases de Dados e obtendo respostas a seus questionamentos.
Outra questão a ser levada em conta é a que se refere ao nível de acesso às informações e
autorizações para a execução de determinados processamentos. Somente uma definição clara
e formal destes aspectos é capaz de evitar processamentos inúteis e onerosos para a empresa
sem que esta mantenha o controle e mesmo tenha conhecimento de que isto ocorre.
Quanto ao sistema de Informações Gerenciais
Com a evolução dos sistemas operacionais para um ambiente de banco de dados integrado e
com a crescente utilização de microcomputadores pelas diversas áreas da Empresa, a JUNIOR
possui condições favoráveis à implantação de um sistema de informações gerenciais que
pressupõe a utilização do "processamento cooperativo", ou seja, interligação total entre
microcomputadores e equipamentos centrais/servidores.
Desta forma, é chegada à hora de nutrir de informações os Gerentes e Diretores da Empresa,
cuja tarefa maior é a de controlar lucros e outras medidas de desempenho. Mas como realizar
estes objetivos sem perder de vista cada aspecto das operações sob seu controle, localizando
problemas ou oportunidades e adotando medidas mais adequadas? A resposta pode ser dada
pela informática, a serviço dos níveis estratégicos da JUNIOR.
A função básica de um EIS é de entregar as informações vitais, no momento oportuno, a
quem necessita dela para tomar uma decisão, pois informação que não pode ser acessada de
forma prática e rápida é inútil. Neste caso específico, informação trata de dados financeiros,
tendências, relatórios de exceção, comentários da gerência, índices operacionais chaves,
resumos dos principais cálculos, relatórios de controle de qualidade, números de participações
no mercado e informações sobre concorrentes.
69
O EIS da JUNIOR deverá estar calcado sobre quatro pontos básicos, a saber:
a) Análise de Resultados consolidados em vários níveis de detalhe, permitindo o grau de
agregação necessário a cada Executivo;
b) Análise de Tendências, permitindo ao Executivo verificar para qual direção os dados estão
se movendo;
c) Consultas de Exceção, permitindo a personalização dos dados de acordo com necessidades
individuais;
Estágio IV
- Consolidação de Indicadores: neste estágio foi realizada uma revisão dirigida com o grupo
de executivos entrevistados para rever os objetivos, fatores críticos de sucesso, problemas e
necessidades de informação, assim como confirmar a classificação desses objetivos. As
atividades deste estágio são: conduzir sessão de revisão dirigida; revisar fórmulas de controle
de exceção; revisar documento da sessão de revisão dirigida; Este estágio foi desenvolvido
para esta trabalho acadêmico conforme as reuniões destacadas no item 7.4
Estágio V
- Desenvolvimento de Protótipos: são realizadas as atividades de construção de consultas e
estruturas de navegação do sistema; é construído um protótipo para que os executivos possam
ter uma visão mais próxima possível do que será o sistema. As tarefas deste estágio são:
desenvolver protótipo; desenhar estrutura de drill-down; obter aprovação do protótipo. Este
estagio foi desenvolvido para esta trabalho acadêmico conforme as reuniões destacadas no
item 7.0
Projeto
Se a fase de planejamento teve como escopo a determinação de especificações do sistema sob
o enfoque das necessidades do usuário, a fase de projeto definiu a solução técnica para
implementar o projeto conceitual concebido. De um modo prático, foi definida, nesta fase, a
arquitetura tecnológica a ser adotada; foi escolhida a ferramenta de software; planejados os
critérios de integração e transferência de dados; modelada a base de dados do SI, sendo
detalhados os atributos das tabelas a serem criadas e consultas de arquivos a serem acessados.
70
Esta fase pode ser mais bem vista na Figura 17.
FIGURA 17: OBJETIVOS DA FASE DE PROJETO Fonte: Furlan (1994).
Esta fase é composta por três estágios, sendo que, no primeiro deles, é feita a decomposição
de indicadores; no segundo, é feita a definição da arquitetura tecnológica; e, no último
estágio, é onde ocorre o planejamento da implementação.
Na decomposição dos indicadores, atividades são envolvidas para detalhamento técnico dos
indicadores e modelagem da base de dados do SI, que suportará o atendimento das
necessidades de informação dos Executivos. É feita uma especificação de fontes para a
necessidade de informação, classificadas na fase anterior. Por meio dessa especificação,
identificam-se os sistemas e bases de dados que devem ser acessados para suprir as
necessidades de informação identificadas.
As tarefas deste estágio são: definir atributos das telas; identificar interfaces e racionalizar
fluxos de informação, definir fontes de informação; definir atualização das bases de dados;
modelar bases de dados SI.
Na definição da arquitetura tecnológica, as atividades visam implementar o sistema, sendo
determinada a localização física das bases de dados e a definição de parâmetros, como
investimentos necessários e instalações.
As tarefas deste estágio são: elaborar cenários alternativos; analisar cenários; definir
arquitetura de hardware e software; analisar viabilidade técnica e econômica; escolher a
melhor solução de arquitetura tecnológica.
No planejamento da implementação, busca-se determinar os recursos necessários para o
desenvolvimento da aplicação do SI. São planejados, além do cronograma de construção do
71
sistema, os seus demais requisitos, tais como instalação, criação das bases de dados e
realização de testes.
As tarefas deste estágio são: definir recursos necessários para o desenvolvimento do SI;
estabelecer cronograma de trabalho; definir base de dados de teste; obter aprovação dos
recursos e investimentos necessários.
Implementação
A última fase da metodologia de desenvolvimento de um SI é a implementação do mesmo,
cujas etapas podem ser vistas na Figura 18 e estão descritas a seguir:
FIGURA 18: FASE DE IMPLEMENTAÇÃO Fonte: Furlan (1994).
1. Construção dos Indicadores: As atividades desta etapas são mais técnicas. Nela foram
realizadas as etapas descritas no item 7.4 deste trabalho, com base nas informações da fase
de planejamento, definiram-se os indicadores necessários para realizar as consultas
propostas pelos gestores que são faturamento, quantidade, preço mínimo e crédito. Estes
indicadores tem de estar associados às dimensões de cliente, produto e vendedor para que
as informações necessárias para a tomada de decisão estivessem disponíveis e os mesmos
pudessem criar análises interligando estas dimensões e estes indicadores aproveitando-se
das vantagens que a criação de um cubo proporciona, sem ficar restrito aos relatórios
estáticos. Para que isto fosse possível utilizou-se como tabela de fato a tabela de
faturamento do sistema MICROSIGA, nela obteve-se todas as informações necessárias
para se construir o DTS conforme demonstrado abaixo, gerando a carga das informações
solicitadas pelos gestores, após a carga de dados inicial e a parametrização do DTS para
gerar cargas automáticas diariamente. Após utilizou-se a ferramenta do SQL Analysis
Manager para a construção do cubo e o processamento do mesmo permitindo que as
informações pudessem ser utilizadas por uma ferramenta de análise que neste caso foi
72
escolhido o EXCEL.
2. Instalação de Hardware e Software: Na parte definida como Hardware todos os
servidores já estavam instalados e configurados portanto não houve necessidade de
nenhuma intervenção. Na parte definida como software operou-se com três sistemas: o
banco de dados ORACLE que já estava instalado e funcionando perfeitamente por fazer
parte do MICROSIGA, o SQL SERVER que foi a ferramenta escolhida para montar e
armazenar o cubo desenvolvido para a JUNIOR, foi instalado e configurado para a
realização deste trabalho, o excel já estava instalado e devidamente configurado para as
necessidades dos gestores.
3. Treinamento e Implementação: É neste estágio que o sistema se torna disponível para os
Executivos e é incorporado ao seu cotidiano. Como o Excel foi a ferramenta escolhida para a
utilização e criação das análises gerados pelo cubo, não houve necessidade de treinamento,
pois os gestores já estavam acostumados com o manuseio da mesma.
5.3 ESPECIFICAÇÃO TECNOLÓGICA ENVOLVIDA
Este sistema de informação é uma abordagem de gerenciamento integrado, permitindo a
JUNIOR, não importando o grau de sua complexidade ou o seu tamanho, aplicar efetivamente
suas habilidades e alcançar seus objetivos estratégicos, constituindo-se em um importante
avanço na transformação da estratégia em ações, tornando a organização eficaz. Portanto, as
informações devem estar disponíveis no exato momento em que o gestor necessitar.
Optou-se durante a fase de planejamento pela utilização do aplicativo EXCEL, devido à
facilidade de utilização, à empresa já possuir este aplicativo instalado, e os Executivos já
possuírem habilidade em sua utilização.
O Sistema de Informação foi subdividido em etapas. As informações necessárias para a
composição de cada uma das perspectivas desejadas são:
1. Objetivos Estratégicos: Os gestores esperavam que com a construção do sistema de
informação pudessem verificar seus dados com segurança, confiança, agilidade, acesso via
internet, e com a possibilidade de gerar análises sem a necessidade de um programador,
gerenciando a empresa de qualquer parte do mundo;
73
2. Indicadores: descrevem as indicações de que um resultado foi alcançado. Os objetivos
confiança, agilidade, possibilidade de gerar análises sem a necessidades de um programador
foram alcançados, porém com a decisão de utilizar o Excel, a utilização da internet não foi
alcançada, ficando este item para uma próxima etapa;
3. Metas: descrevem as medidas dos indicadores. Para se conseguir as consultas desejadas
pelos gestores nas reuniões estratégicas utilizou-se as medidas faturamento, quantidade ,
preço mínimo e crédito;
4. Alinhamento Estratégico: verificam se as ações tomadas estão alinhadas à estratégia
empresarial. Todas a modelagem realizada no banco e a construção do cubo tiveram como
base as reuniões com os gestores, e após a conclusão do trabalho e apresentado aos gestores
verificou-se que as analises almejadas poderiam ser alcançadas.
Portanto, o Sistema de Informação foi formado por objetivos, metas, indicadores e
alinhamento estratégico. O modelo proposto foi baseado no levantamento realizado
juntamente com a diretoria da empresa. Cada um desses itens deverá ser aprovado pela
diretoria e divulgado aos seus colaboradores.
A visão geral do modelo proposto pode ser visto na Figura 19.
74
FIGURA 19: MODELO GERAL PROPOSTO
JUNIOR
metas
iniciativas Indicadores (Quantidade e
objetivo
ORACLE SQL SERVER OLAP
5.3.1 Níveis de segurança
A segurança do sistema será realizada via recursos do SQL SERVER. Este ambiente oferece
os controles de acesso a usuários, senhas e permissões.
O ambiente disponibiliza uma área onde o usuário realiza login no sistema, acessando a tela
de entrada do aplicativo ou, se pertencer ao grupo dos administradores, acessando um
ambiente para administração do sistema.
5.3.2 Carga de dados
A carga inicial dos dados do sistema foi realizada baseada nas reuniões e necessidades dos
diretores e alinhada com o planejamento estratégico. Neste trabalho serão realizadas,
primeiramente, somente as cargas relativas à área comercial. Assim, as entrevistas e
necessidades que foram realizadas, priorizam os responsáveis desta área.
A integração com o sistema de gestão da empresa foi realizada através da importação dos
dados do banco de dados ORACLE diretamente para o SQL, que, através da ferramenta DTS,
75
permite esta carga sem transformações em arquivos textos.
Para obter os resultados esperados verificados nas reuniões com os gestores foram realizadas
as cargas baseadas nos seguintes aspectos:
A tabela de fato é alimentada basicamente por informações da tabela de faturamento que
possuem dados como número da nota, quantidade de produto vendida, valor unitário faturado
e data de emissão da nota, informações necessárias para alimentar os indicadores base que
foram definidos nas reuniões - o indicador intermediário “valor mínimo” será conseguido
através da tabela de preço informada no pedido de venda, e o indicador “preço médio mensal”
será um indicador calculado com base no preço faturado do produto em um determinado mês,
indicador “comissão” será calculado pelo percentual informado de comissão e o valor unitário
de cada produto.
Na tabela de faturamento, consegue-se o vínculo com o cliente, com o produto vendido, com
a condição de pagamento utilizada, com o vendedor que realizou a venda e seu percentual de
comissão. Com estas informações, monta-se as dimensões base necessárias para montar as
consultas desejadas pelos gestores. As dimensões de crédito, estado, município serão obtidas
através da tabela de cliente, e as dimensões de grupo e família serão obtidas através da
dimensão produto.
As cargas deverão ser sempre completas desde o inicio do ano pré-definido, que em reuniões
optou-se por ano base 2003, pois a partir deste ano base a empresa já possui informações mais
confiáveis em seu banco de dados. O risco de fazer cargas incrementais seria que estas não
abordariam eventuais exclusões de notas.
5.3.3 Resultados esperados
O propósito deste trabalho é atender às bases fundamentais de montagem de um
DATAWAREHOUSE relacionadas com conceitos modernos de ferramentas de BI abordados
na revisão bibliográfica deste projeto, contemplando um espectro de formas de gerenciamento
e tecnologias que podem ser aplicadas no âmbito empresarial.
76
5.4 ANÁLISE FUNCIONAL
5.4.1 Introdução
A análise do sistema foi realizada utilizando-se a notação UML (Unified Model Language). A
UML é uma linguagem gráfica para visualização, especificação, construção e documentação
de artefatos de sistemas de software (BOOCH, 2000). A UML proporciona uma forma padrão
para a preparação de planos de arquitetura de projetos, incluindo aspectos conceituais, tais
como processo de negócios e funções do sistema, além de itens concretos como as classes,
banco de dados e componentes de software reutilizáveis. Nesta etapa de modelagem foram
identificadas as funcionalidades do sistema de informação executivo.
O propósito deste sistema é desenvolver um aplicativo utilizando a ferramenta Excel onde a
empresa possa acompanhar o alinhamento da estratégia, através dos indicadores, objetivos,
metas e planos de ação. O sistema permitirá flexibilidade quanto ao número de indicadores,
dimensões e níveis.
Este projeto está subdividido nos seguintes subsistemas:
1. Cadastro e alimentação dos dados;
2. Visualização gráfica;
3. Visualização personalizada;
4. Fluxo do sistema
5. Controle de acesso;
Os usuários que utilizarão o sistema serão somente os gestores da empresa. Para uma maior
segurança, cada colaborador terá um login, que lhe dará determinados privilégios no sistema
estabelecidos pelo Administrador.
77
7.4.2 Organograma funcional do sistema
Uma visão geral dos subsistemas e suas principais funcionalidades representadas em um
organograma são apresentadas na figura 20.
FIGURA 20 - ORGANOGRAMA FUNCIONAL DO SISTEMA
Pode-se descrever cada item do organograma como:
1 - Dados: Este subsistema possuirá os procedimentos para o cadastramento (inclusão,
exclusão e alteração) dos dados do aplicativo, para a realização da carga inicial do sistema e
para sua alimentação periódica que serão sempre cargas completas.
1.1 - Carga Inicial: Processo de implantação do sistema, no qual será realizada uma
importação dos dados existentes no sistema de gestão.
78
1.2 - Alimentação: Processo de realimentação periódica dos dados que possuírem
integração com o banco de dados relacional Oracle.
1.3 - Cadastro Usuário: O usuário com privilégio de administrador do sistema irá efetuar o
cadastro dos colaboradores da empresa. Será cadastrado o nome do usuário, senha e privilégio
de acesso.
2 - Consulta Personalizada: Este subsistema possuirá as consultas realizadas pelo
próprio usuário
2.1 - Por metas: Neste relatório o usuário poderá analisar as metas, verificando se foram
atingidas de forma top-down a empresa, os gerentes e os vendedores.
2.2 - Por Produto: Neste relatório o usuário poderá analisar todos os produtos vendidos em
um determinado período de tempo verificando por ranking quais produtos representam o
maior faturamento da empresa.
2.3 - Por valores: Neste relatório o usuário poderá verificar as consultas de vendas menores
que o preço mínimo, que, de acordo com o modelo de negócio, não são aceitas.
3 - Notificação do Sistema: Este subsistema possuirá os procedimentos relacionados as
regras de negócio existente na empresa, ou seja, dependendo dos números apontados nos
indicadores, o sistema assume um determinado comportamento, enviando um e-mail para o
responsável da área (diretoria ou presidência).
3.1 - Por preço mínimo: De acordo com as regras de negócio, os vendedores não podem
realizar mais de duas vendas abaixo do preço mínimo por mês. Caso isto aconteça, o sistema
informará com sim nas consultas.
3.2 - Por crédito do cliente: De acordo com as regras de negócio, as vendas não poderão
ser realizadas vendas acima do crédito pré-aprovado para o cliente. Caso isto aconteça, o
sistema informará como sim nas consultas.
5.4.3 Análise dos Riscos
Em relação à interface e funções, os riscos serão minimizados com a adoção de alguns
procedimentos: problemas com a queda do Banco de Dados ou falha na comunicação
79
resultarão na saída do sistema de funcionamento, representando um risco a tomada de decisão.
O processo do negócio também apresentará baixo risco, pois toda a logística da empresa será
aproveitada.
5.4.4 Diagramas de caso de uso
Conforme Furlan (1998), os diagramas de caso de uso apresentam-se como uma forma para
descrever uma visão externa do sistema, apresentando suas interações com o mundo exterior.
Os diagramas de caso de uso apresentam uma visão macro do sistema, representando uma
visão de alto nível de funcionalidade, mediante os diferentes tipos de requisições dos usuários.
O diagrama de casos de uso descreve as ações do usuário sob o sistema, bem como os
requisitos funcionais associados.
Os principais casos de uso do sistema estão representados nas figura 21 a 25.
FIGURA 21 – USE CASE GENÉRICO A figura 21 representa todos os processos do sistema, os atores envolvidos e as etapas para o desenvolvimento e manutenção do sistema.
80
FIGURA 22 – DESENVOLVIMENTO A figura 22 representa as etapas necessárias para o desenvolvimento do sistema.
FIGURA 23 – ADMINISTRAÇÃO DO SISTEMA
A figura 23 representa as permissões do ator Administrador
81
FIGURA 24 – CONSULTAS DO SISTEMA
A figura 24 representa as permissões do ator Usuário
FIGURA 25 – SHEDULE
A figura 25 representa as atividades dos atores SQL SERVER e Oracle.
82
5.4.5 Estrutura do DTS
DTS
FIGURA 26 – DTS DESENVOLVIDO PARA A JUNIOR
LIMPAR TABELA
FIGURA 27 – LIMPAR TABELA Conforme informado previamente pelos gestores, as notas podem ser deletadas a qualquer
momento pela equipe de faturamento, sem respeitar uma data especifica, portanto definiu-
83
se por realizar sempre a carga total, conforme demonstrado abaixo.
PARA GERAR A DIMENSÃO PRODUTO FOI REALIZADO O SEGUINTE SQL:
SELECT produto.B1_COD, produto.B1_DESC, NVL(TRIM(produto.B1_GRUPO),
'9999') AS GRUPO, NVL(TRIM(produto.B1_FAM), '99') AS FAMILIA, SUM
(estoque.B2_QATU - estoque.B2_RESERVA)
AS ESTOQUE_DISPONIVEL
FROM ADM_SIGA.SB1010 produto,
ADM_SIGA.SB2010 estoque
WHERE produto.B1_COD = estoque.B2_COD
AND (produto.D_E_L_E_T_ <> '*') AND (estoque.D_E_L_E_T_ <> '*')
GROUP BY produto.B1_COD, produto.B1_DESC, NVL(TRIM(produto.B1_GRUPO),
'9999'), NVL(TRIM(produto.B1_FAM), '99')
PARA GERAR A DIMENSÃO GRUPO FOI REALIZADO O SEGUINTE SQL:
SELECT BM_GRUPO, BM_DESC
FROM ADM_SIGA.SBM010
WHERE D_E_L_E_T_ <> '*'
UNION ALL
SELECT '9999', 'OUTROS'
FROM DUAL
PARA GERAR A DIMENSÃO GRUPO FOI REALIZADO O SEGUINTE SQL:
SELECT ZZ1_CODIGO, ZZ1_DESCRI
84
FROM ADM_SIGA.ZZ1010
WHERE (D_E_L_E_T_ <> '*')
UNION ALL
SELECT '99', 'OUTROS'
FROM DUAL
PARA GERAR A DIMENSÃO CLIENTE FOI REALIZADO O SEGUINTE SQL:
SELECT A1_COD, A1_LOJA, A1_NOME, A1_CGC, A1_PESSOA, A1_EST,
A1_TEL, A1_CONTATO, A1_EMAIL
FROM ADM_SIGA.SA1010
WHERE D_E_L_E_T_ <> '*'
UNION ALL
SELECT '999999'
A1_COD, '99' A1_LOJA, 'INDEFINIDO' A1_NOME, '' A1_CGC, '' A1_PESSOA,
'' A1_EST, '' A1_TEL, '' A1_CONTATO, '' A1_EMAIL
FROM DUAL
PARA GERAR A DIMENSÃO GERENTE FOI REALIZADO O SEGUINTE SQL:
SELECT A3_COD, A3_NOME
FROM ADM_SIGA.SA3010
WHERE
A3_COD IN
(SELECT DISTINCT A3_GEREN
85
FROM ADM_SIGA.SA3010
WHERE D_E_L_E_T_ <> '*') AND D_E_L_E_T_ <> '*'
UNION ALL
SELECT '900000', 'INDEFINIDO'
FROM DUAL
PARA GERAR A DIMENSÃO VENDEDOR FOI REALIZADO O SEGUINTE
SQL:
SELECT A3_COD, A3_NOME, A3_TEL, A3_EMAIL,
NVL(TRIM(A3_GEREN),'900000')
FROM
ADM_SIGA.SA3010
WHERE (D_E_L_E_T_ <> '*')
UNION
ALL
SELECT '900000', 'INDEFINIDO', '', '', '900000'
FROM DUAL
PARA GERAR A FATO FOI REALIZADO O SEGUINTE SQL:
SELECT ADM_SIGA.SD2010.D2_COD, ADM_SIGA.SD2010.D2_QUANT,
ADM_SIGA.SD2010.D2_TOTAL AS D2_TOTAL,
ADM_SIGA.SD2010.D2_PRUNIT AS PRECO_MIN,
ADM_SIGA.SD2010.D2_PRUNIT
* ADM_SIGA.SD2010.D2_QUANT AS MIN_TOT,
86
ADM_SIGA.SF2010.F2_CLIENTE, ADM_SIGA.SF2010.F2_LOJA,
ADM_SIGA.SF2010.F2_EMISSAO,
NVL(TRIM(ADM_SIGA.SF2010.F2_VEND1), '999999')
AS F2_VEND1, NULL AS QTD_DEVOL, NULL AS DEVOLUCAO,
DECODE(SIGN(ADM_SIGA.SD2010.D2_PRCVEN - ADM_SIGA.SD2010.D2_PRUNIT),
0, 1, 1,
1, - 1) AS IND_PRCMIN
FROM
ADM_SIGA.SD2010, ADM_SIGA.SB1010, ADM_SIGA.SF2010,
ADM_SIGA.SC5010,
ADM_SIGA.SF4010
WHERE ADM_SIGA.SD2010.D2_COD = ADM_SIGA.SB1010.B1_COD
AND ADM_SIGA.SD2010.D2_FILIAL = ADM_SIGA.SF2010.F2_FILIAL AND
ADM_SIGA.SD2010.D2_DOC = ADM_SIGA.SF2010.F2_DOC
AND ADM_SIGA.SD2010.D2_SERIE = ADM_SIGA.SF2010.F2_SERIE AND
ADM_SIGA.SD2010.D2_CLIENTE = ADM_SIGA.SF2010.F2_CLIENTE
AND ADM_SIGA.SD2010.D2_LOJA = ADM_SIGA.SF2010.F2_LOJA AND
ADM_SIGA.SD2010.D2_FILIAL = ADM_SIGA.SC5010.C5_FILIAL
AND ADM_SIGA.SD2010.D2_PEDIDO = ADM_SIGA.SC5010.C5_NUM AND
87
ADM_SIGA.SD2010.D2_TES = ADM_SIGA.SF4010.F4_CODIGO
AND (ADM_SIGA.SF4010.F4_DUPLIC = 'S') AND (ADM_SIGA.SF2010.D_E_L_E_T_
<> '*')
AND (ADM_SIGA.SD2010.D_E_L_E_T_
<> '*') AND (ADM_SIGA.SC5010.D_E_L_E_T_ <> '*') AND
(ADM_SIGA.SF4010.D_E_L_E_T_
<> '*') AND
(ADM_SIGA.SB1010.D_E_L_E_T_
<> '*')
5.4.6 Dimensões e consultas modeladas para o cubo JUNIOR
FIGURA 28 – CUBO JUNIOR Consultas realizadas pelo usuário
88
FIGURA 29 – CONSULTA PREÇO MÍNIMO Nesta consulta é verificado conforme documentado nas regras de negócio as vendas que tiveram seu preço de venda abaixo do preço mínimo estabelecido pela empresa, estes valores estão destacados no item regra preço mínimo igual a sim
FIGURA 30 – CONSULTA CRÉDITO Nessa consulta é verificado, conforme documentado nas regras de negócio, as vendas que
tiveram seu preço de venda acima do previsto no cadastro do cliente que indica o crédito de
cada cliente, ou seja, qual o máximo possível a ser vendido para este cliente.
89
6. CONSIDERAÇÕES FINAIS
O SADBO foi desenvolvido utilizando o conceito de data mart e construção de cubos, devido
a sua menor complexidade em função do prazo curto para a implementação do sistema e o
fato deste ser o primeiro projeto envolvendo OLAP, que será desenvolvido para a empresa
JUNIOR Indústria e Comércio Ltda.
A necessidade e a decisão de desenvolver este TCC, focado em tomada de decisão junto a
empresa JUNIOR, foram levadas em conta, principalmente, pelo fato da Empresa já possuir
há quatro anos um sistema de gestão (MICROSIGA), que ocasionou altíssimos investimentos
e gerou ganhos muito pequenos em relação ao investimento, ocasionando descrédito em
relação a investimentos em sistemas.
Na verdade, observou-se que o grande questionamento e o grande desejo dos gestores eram,
principalmente, relacionados à informação, acreditando-se tratar-se de um problema não só
dessa Empresa mas da maioria das empresas que investem verdadeiras fortunas em sistemas
de gestão e não conseguem dimensionar o ganho deste investimento. A maioria dos sistemas
de gestão de pequeno a médio porte tem sua parte de relatório extremamente fraca e estática,
gerando informações fracas e de difícil leitura. O resultado é que os relatórios do Microsiga
tinham que ser transferidos manualmente para o Excel e estruturados de uma forma que o
gestor necessitaria, porém, novamente, o relatório permanece estático, além de consumir
várias horas de um funcionário.
Dessa forma, o sistema de gestão está fazendo a sua parte, que é operacionalizar a empresa e
integrar as diversas áreas (compras, produção, financeiro, etc,). A falta de informação, embora
crítica, não é o foco dos sistemas de gestão, porém eles abastecem com riquíssimas
informações os bancos de dados. A dificuldade está em transformar esse verdadeiro tesouro
de informações em algo agradável, simples e dinâmico para os gestores, de forma que eles
possam fazer o que realmente é o seu foco, gerir a empresa e não decifrar dados.
Além de ser um trabalho de pesquisa/desenvolvimento para a conclusão de curso, o objetivo
foi iniciar o conceito de sistemas de informações dentro da empresa, com baixos custos de
investimento. Como o SQL utilizado foi o MSDE, que é gratuito e apresenta algumas
limitações que não impediriam a realização do trabalho, e a ferramenta de consulta utilizada
90
ter sido o Excel, que a maioria das empresas já possuem, a Empresa não precisou fazer
nenhum investimento inicial em software.
Nas primeiras demonstrações do produto já se pode perceber o entusiasmo por parte dos
gestores, mesmo sem a vantagem da internet. Consultas que levavam horas para serem
elaboradas e, ao final, já estavam desatualizadas, puderam ser confeccionadas pelo próprio
gestor em segundos.
Verificou-se que o Excel 2003, como ferramenta de consulta a cubos, possui algumas
limitações e dificuldades, porém ele já agregou grandes avanços na empresa, principalmente
cultural de utilização de ferramentas de BI. Com o sucesso do trabalho surgiu a necessidade
de explorar novas ferramentas de mercado e implementar novos cubos na área financeira e de
produção.
91
ANEXO 1
QUESTIONÁRIO GESTORES Foi entregue este questionário aos seguintes gestores: Carlos Aragão (Presidente) Eloir (Diretor Comercial) Roberto (Gerente de produção) Sandro (Supervisor comercial)
1) Quais as rotinas periódicas que são utilizadas para decisão na área comercial 2) Quais os indicadores mais importantes na empresa para tomada de decisão?
3) Quais as informações mais importantes dos concorrentes necessárias para tomadas de
decisão, sobre um negocio especifico e sobre as vendas de forma geral?
4) Quais mix de produtos de maior faturamento?
5) Quais itens de despesas comerciais mais representativos?
6) Quais são os clientes mais representativos e quais as diferenças de ações especificas para eles?
7) Quais fornecedores mais representativos?
8) Quais negócios com maior rentabilidade?
9) Quais são as metas de participação de mercados a serem atingidas?
92
ANEXO 2
TABELAS UTILIZADAS PARA A CARGA
93
94
95
96
97
98
99
100
101
102
REFERÊNCIAS BIBLIOGRÁFICAS
ALMEIDA, L.B. Sistemas de informações de gestão econômica. São Paulo: Atlas, 1999.
BEUREN, I. M. Gerenciamento da informação: um recurso estratégico no processo de gestão empresarial. São Paulo: Ed Atlas, 1998.
CHOO, C. W. The knowing organization. Oxford: Oxford University Press, 1998.
DRUCKER, Peter. Sociedade Pós-Capitalista. São Paulo: Pioneira, 1993. Coleção Novo Umbrais. Trad. Nivaldo Montingelli Jr. 186 p.
ETZIONI, Amitai. Organizações modernas. 8ª. Ed. São Paulo: Pioneira 1989.
FURLAN, J. D.; IVO, I. M.; AMARAL, F. P. Sistema de informação executiva. São Paulo: Makron Books, 1994.
GALBRAITH, Jay R; LAWER, Edward. Organizando para competir o futuro. 1995.
Wikipedia. Data Mart. Disponível em <http://pt.wikipedia.org>.Acessado em 16/08/2006.
HAMMOND, J. S.; KEENEY, R. L.; RAIFFA, H. The hidden traps in decision making. Harvard Business Review, Boston, v.76, n. 5, p. 47-58, sep./oct. 1998.
INMON, W.H. Como Construir o Data Warehouse. Rio de Janeiro: Editora Campus, 1997.
INFOBRAS: projetos e sistemas. 2004. Disponível em: <http//www.escelsanet.com.br/ usuarios/infobras/DataWarehouse.html>. Acesso em: 7 ago. 2004.
INMON, W. H. (1997). Como Construir o Data Warehouse. Rio de Janeiro, Campus.
KIM, R. Data warehouse toolkit. São Paulo: Makron Books, 1995.
KIMBALL, R. (1998). Data Warehouse Toolkit. São Paulo, Makron Books.
LEITÃO, C. N. Construção de aplicações com o uso de ferramentas OLAP: artigo científico. [2000]. Disponível em: <http://genesis.nce.ufrj.br/dataware/DataWarehouse/Proj_Finais/ Claudia_Nolla/Projeto%20Final.pdf > Acesso em 8 set. 2004.
LAUDON, K.; LAUDON, J. Sistemas de informação. Rio de Janeiro: Livros Técnicos e Científicos S.A., 1999.
MACHADO, F. N. R. Projeto de data warehouse – uma visão multidimensional. São Paulo: Érica, 2000.
MCLEOD, JR. Sistemas de informações gerenciais. São Paulo: Makron Books, 1993.
MINTZBERG, Henry; QUINN, JAMES A. O' BRIEN. O processo da estratégia. 3 ed. Porto Alegre: Bookman, 2001.
103
MOSIMANN, C. P.; ALVES, O. C.; FISCH, S. Controladoria: seu papel na administração de empresas. Florianópolis: UFSC, 1993.
MURAKAMI, Milton. Decisão estratégica em TI: estudo de caso. 2003. Tese (Doutorado em Administração) – Faculdade de Economia, Administração e Contabilidade, Universidade de São Paulo, São Paulo, 2003.
O’BRIEN, J. A. Sistemas de informação e as decisões gerenciais na era da Internet. São Paulo: Saraiva, 2001.
OLIVEIRA, D. P. R. Sistemas de informações gerenciais: estratégicas, táticas e operacionais. São Paulo: Atlas, 1992.
PETKOVIC, D. SQL Server 7 – Guia prático. São Paulo: Makron Books, 1999.
RCI: business intelligence integrator. 2004. Disponível em: <http//www.rci.com.br>. Acesso em: 21 ago. 2004.
REZENDE, Denis Alcides; ABREU, Aline França de. Tecnologia de informação aplicada a sistemas de informação empresariais. São Paulo: Atlas, 2000.
RUBINI, Eduardo R. C. OLAP – Transformando dados em informações estratégicas. Curitiba, [1999]. Disponível em: <http://www.treetools.com.br/artigos/warehouse.htm>. Acesso em: 16/03/2002.
SIA: sistemas de informática e automação. 2004. Disponível em: < http://www.sia.com.br/tm1/ indexolap.htm>. Acesso em: 4 ago. 2004.
SINGH, H. Data warehouse. São Paulo: Makron Books, 2001.
STAIR, R. M. Princípios de sistemas de informação: uma abordagem gerencial. Rio de Janeiro: Livros Técnicos e Científicos, 1998.
SPRAGUE JR, R. H. Estrutura para o desenvolvimento de apoio a decisão. Rio de Janeiro: Campus, 1991.
SHIMIZU, Tamio. Decisão nas organizações: introdução aos problemas de decisão encontrados nas organizações e nos sistemas de apoio a decisão. São Paulo: Atlas, 2001.
SERRA, J. América Latina: ensaios de interpretação econômica. Rio de Janeiro: Paz e Terra, 1976.
STRYKER, P. Você pode analisar este problema? In: Harvard business review: tomada de decisão. Rio de Janeiro: Campus, 2001. p. 93-106.
THOMSEN, E. OLAP – Construindo sistemas de informações multidimensionais. Rio de Janeiro: Campus, 2002.
TURBAN, E.; ARONSON, J. E. Decision support systems and intelligent systems. 5. ed. Englewood Cliffs: Prentice Hall, 1998
104
ASSINATURAS
______________________________________ Acadêmico: Ivo José Soares Junkes
___________________________________________________ Professor Orientador: Mest. Luiz Eduardo Pefeito Nunes