UNIVERSIDADE DO SUL DE SANTA CATARINA
DANIEL LUIZ DA SILVA
ESTUDO DE CASO: ARQUITETURA DE BI PARA APOIAR O PROCESSO
DECISÓRIO DE UMA FÁBRICA DE SOFTWARE
Florianópolis
2014
DANIEL LUIZ DA SILVA
ESTUDO DE CASO: ARQUITETURA DE BI PARA APOIAR O PROCESSO
DECISÓRIO DE UMA FÁBRICA DE SOFTWARE
Trabalho de Conclusão de Curso apresentado ao Curso
de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina, como requisito
parcial à obtenção do título de Bacharel em Sistemas de
Informação.
Orientador: Prof.Aran Bey Tcholakian Morales, Dr.
Florianópolis
2014
Dedico esse trabalho a meus pais por terem
financiados meus estudos e acreditado em meu
potencial, e também porque sem eles nada
disso teria ocorrido. E minha namorada por
sempre me apoiarem momentos difíceis e
contribuir muito para meu crescimento pessoal
e profissional, sem ela eu seria uma pessoa
diferente.
AGRADECIMENTOS
Agradeço a Deus por sempre me auxiliar no meu desenvolvimento como ser
humano, a meus pais por terem financiado meus estudos e acredito sempre em mim, minha
namorada por sempre estar comigo em todos os momentos, a meu orientador Aran Bey
Tcholakian Morales, por fazer parte desse trabalho, com muita humildade, e a todos
professores da universidade que me ensinaram a fazer uma tarefa simples, porém de muita
utilidade, pensar.
“O dever da pessoa que trabalha com sistemas informação é levar a informação a
todas as pessoas, ou seja, encurtar o caminho do acesso à informação de todas as pessoas. ”
ANÔNIMO.
RESUMO
Com o passar dos anos as empresas desenvolvedoras de software, e pessoas que tem como
profissão alguma tarefa relacionada ao desenvolvimento de software, tem novos desafios para
transformar dados em informação, e informação em conhecimento. Com isso, existe a área de
engenharia de softwarede estudo que analisa o gerenciamento do desenvolvimento de
software, ou seja, como pode-se melhorar a fabricação de sistemas, afim de garantir a
satisfação do cliente. A partir desse contexto, o presente estudo tem por finalidade, analisar os
dados coletados de demandas geradas em uma fábrica de software, ou seja, gerar informação
e conhecimento para auxiliar a tomada decisão na melhoria do processo de produção de
sistemas. Para isso foi construído uma arquitetura de BI, para analisar as solicitações
(tíquetes), gerada por clientes e pela própria empresa, por meio de um sistema que gerencia
demandas. Deste modo foi elaborada a pesquisa bibliográfica, utilizando como referência os
principais autores da área de BI. O desenvolvimento desta arquitetura de BI, foi elaborado
segundo a metodologia ICONIX. Foi construído um modelo dimensional de banco de dados,
seguindo o padrão dos principais autores, apresentados na revisão bibliográfica. Foi utilizado
a ferramenta ETL Pentaho Kettle®, para realizar a extração, transformação e carga de dados,
do banco de dados relacional, para o banco de dados dimensional. Por fim, foi realizado a
montagem de gráficos, com auxílio da ferramenta Pentaho Saiuku®, que apresentam os
resultados conforme os requisitos levantados e expõem as informações encontrada desse
trabalho.
Palavras-chave: Análise de dados,Business intelligence,Data warehouse, Desenvolvimento de
Software, Sistemas de apoio a tomada de decisão.
LISTA DE ILUSTRAÇÕES
Figura 1 – Evolução do BI ................................................................................................... 20
Figura 2– Arquitetura de BI ................................................................................................. 21
Figura 3 - Processo ETL ...................................................................................................... 23
Figura 4 - Arquitetura três camadas ...................................................................................... 29
Figura 5 - Arquitetura duas camadas .................................................................................... 30
Figura 6 - Componentes do data warehouse ......................................................................... 31
Figura 7 - Tabela fato ........................................................................................................... 33
Figura 8 - Tabela dimensão .................................................................................................. 35
Figura 9 - Modelo estrela ..................................................................................................... 37
Figura 10 – Operação Drill Down ........................................................................................ 38
Figura 11 – Operação Roll Up .............................................................................................. 39
Figura 12 – Operação Drill Across ....................................................................................... 39
Figura 13 – Operação Slice and Dice ................................................................................... 40
Figura 14 – Arquitetura de BI – Solução Proposta ................................................................ 45
Figura 15 – Análise de requisitos - ICONIX ......................................................................... 48
Figura 16 – Análise de projeto preliminar ............................................................................ 49
Figura 17 – Revisão detalhada do projeto ............................................................................. 50
Figura 18 – Requisitos funcionais ........................................................................................ 53
Figura 19 – Casos de uso...................................................................................................... 54
Figura 20 – Diagrama de robustez ........................................................................................ 56
Figura 21 – UCE001 – diagrama de sequência ..................................................................... 57
Figura 22 – UCE002 – diagrama de sequência ..................................................................... 58
Figura 23 - UCE003 - diagrama de sequência....................................................................... 58
Figura 24 - etapas back-end.................................................................................................. 64
Figura 25 – Modelo entidade relacionamento ....................................................................... 65
Figura 26 - Modelo DW ....................................................................................................... 67
Figura 27 - Carga de dados DI_CATEGORIA ..................................................................... 69
Figura 28 - Carga de dados DI_PROJETO ........................................................................... 70
Figura 29 - Carga de dados DI_RESPONSAVEL_AREA .................................................... 71
Figura 30 - Carga de dados DI_STATUS ............................................................................. 72
Figura 31 - Carga de dados DI_TEMPO............................................................................... 73
Figura 32 - Carga de dados DI_TICKET .............................................................................. 74
Figura 33 - Carga de dados FT_TICKETS ........................................................................... 75
Figura 34 - Cubo OLAP ....................................................................................................... 76
Figura 35 - Horas x projetos ................................................................................................. 77
Figura 36 - horas x mês ........................................................................................................ 78
Figura 37 - Horas x semana .................................................................................................. 78
Figura 38 - Horas x dia......................................................................................................... 79
Figura 39 - Horas x categoria ............................................................................................... 80
Figura 40 - Horas x área - equipe ......................................................................................... 81
Figura 41 - Tíquete x release ................................................................................................ 82
Figura 42 - Percentual de prioridade de tíquete..................................................................... 83
Figura 43–Percentual de horas x pessoas .............................................................................. 83
LISTA DE TABELAS
Tabela 1 – Definição de atores ............................................................................................. 54
Tabela 2 – UCE001 – Importar dados com ferramenta ETL ................................................. 55
Tabela 3 – UCE003 – Criar data warehouse ........................................................................ 55
Tabela 4 - UCE003 - Analisar dados comFerramenta OLAP ................................................ 55
Tabela 5 – Tecnologias utilizadas......................................................................................... 61
LISTA DE SIGLAS
BD – Banco de Dados
BI – Business Intelligence
BPM – Business Performance Management
DM – Data Mart
DW – Data Warehouse
ERP – Enterprise Resource Planning
ETL – Enterprise Transform and Load
FK – foreign key
GUI – Graphical User Interface
ODS – OperationalDataStore
OLAP – On-line Analytic Processing
PK – Primary Key
RUP – Rational Unified Process
SGBD – Sistema de Gerenciamento de Banco de Dados
SQL - Structured Query Language
UML – Unified Modeling Language
XP – Extreme Programming
SUMÁRIO
1 INTRODUÇÃO .........................................................................................................................13
1.1 PROBLEMÁTICA ..................................................................................................................13
1.2 OBJETIVOS ............................................................................................................................15
1.2.1 OBJETIVO GERAL ..............................................................................................................15
1.2.2 OBJETIVO ESPECÍFICO ....................................................................................................15
1.3 JUSTIFICATIVA ....................................................................................................................16
1.4 ESTRUTURA DA MONOGRAFIA ........................................................................................17
2 REVISÃO BIBLIOGRÁFICA..................................................................................................18
2.1 BUSINESS INTELLIGENCE (CONCEITOS E DEFINIÇÕES) ..............................................18
2.1.1 ARQUITETURA DE BI ........................................................................................................20
2.2 ETL .........................................................................................................................................22
2.2.1 EXTRAÇÃO DE DADOS ......................................................................................................23
2.2.2 TRANSFORMAÇÃO DE DADOS ........................................................................................24
2.2.3 CARREGAMENTO DE DADOS ..........................................................................................24
2.3 DATA WAREHOUSE .............................................................................................................25
2.3.1 ABORDAGEM BILL INMON ..............................................................................................26
2.3.2 ABORDAGEM RALPH KIMBALL.....................................................................................26
2.3.3 CARACTERÍSTICAS DO DATA WAREHOUSE...............................................................27
2.3.4 OBJETIVOSDO DATA WAREHOUSE...............................................................................27
2.3.5 ARQUITETURA DO DATA WAREHOUSE .......................................................................28
2.3.5.1 Arquitetura três camadas.....................................................................................................28
2.3.5.2 Arquitetura duas camadas ...................................................................................................29
2.3.6 COMPONENTES DO DATA WAREHOUSE......................................................................30
2.3.7 MODELO DIMENSIONAL ..................................................................................................32
2.3.7.1 Tabelas fato ........................................................................................................................32
2.3.7.2 Granularidade .....................................................................................................................33
2.3.7.3 Tabelas de dimensão ...........................................................................................................34
2.3.7.4 Medidas (variáveis) ............................................................................................................35
2.3.7.5 União de fatos e dimensão ..................................................................................................36
2.4 OLAP ......................................................................................................................................37
2.4.1 DRILL DOWN ........................................................................................................................38
2.4.2 ROLL UP ................................................................................................................................39
2.4.3 DRILL ACROSS .....................................................................................................................39
2.4.4 SLICE AND DICE ..................................................................................................................40
2.4.5 PIVOT .....................................................................................................................................41
2.5 CONSIDERAÇÕES FINAIS DO CAPÍTULO .........................................................................41
3 MÉTODO ..................................................................................................................................43
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ....................................................................43
3.2 ATIVIDADES METODOLÓGICAS .......................................................................................44
3.3 ARQUITETURA DA SOLUÇÃO............................................................................................45
3.4 DELIMITAÇÕES ....................................................................................................................46
3.5 CONSIDERAÇÕES FINAIS DO CAPÍTULO .........................................................................46
4 DESENVOLVIMENTO DA SOLUÇÃO .................................................................................47
4.1 METODOLOGIA ICONIX ......................................................................................................47
4.1.1 ANÁLISE DE REQUISITOS ................................................................................................48
4.1.2 ANÁLISE DE PROJETO PRELIMINAR ............................................................................49
4.1.3 PROJETO ..............................................................................................................................50
4.1.4 IMPLEMENTAÇÃO .............................................................................................................50
4.2 PROTÓTIPO DA SOLUÇÃO..................................................................................................51
4.2.1 LEVANTAMENTO DE REQUISITOS ................................................................................51
4.2.2 CASOS DE USO ....................................................................................................................53
4.2.3 DIAGRAMA DE ROBUSTEZ ..............................................................................................56
4.2.4 DIAGRAMA DE SEQUÊNCIA ............................................................................................57
4.3 CONSIDERAÇÕES FINAIS DA MODELAGEM ...................................................................59
5 ESTUDO DE CASO EMPRESA DESENVOLVEDORA DE SOFTWARE...........................60
5.1 FERRAMENTAS E TECNOLOGIA .......................................................................................60
5.2 APRESENTAÇÃO DA ARQUITETURA DE BI.....................................................................62
5.2.1 A EMPRESA..........................................................................................................................63
5.2.2 ARQUITETURA DE BI: BACK-END ..................................................................................63
5.2.3 ARQUITETURA DE BI: FRONT-END................................................................................76
5.3 CONSIDERAÇÕES FINAIS DO CAPÍTULO .........................................................................84
6 CONCLUSÕES E TRABALHOS FUTUROS .........................................................................85
6.1 CONCLUSÕES .......................................................................................................................85
6.2 TRABALHOS FUTUROS .......................................................................................................86
APÊNDICE A – CRONOGRAMA.................................................................................................87
REFERÊNCIAS..............................................................................................................................88
13
1
INTRODUÇÃO
Visando analisar os dados de desenvolvimento de software, de uma empresa que
fabrica software para seus clientes, e com intuito de encontrar informação para apoiar a
gerência da empresa a encontrar pontos de melhora, no processo de desenvolvimento de
sistemas, será apresentado uma pesquisa, que analisa as demandas geradas por clientes da
empresa ou demandas internas relacionadas a melhoria do software.
Nos dias atuais, a valorização por informações relevantes que podem melhorar o
processo de desenvolvimento de software, é o alvo principal de funcionários que compõem a
parte estratégica da empresa, ou seja, os funcionários que ocupam cargos gerenciais dentro da
empresa, tem como meta encontrar informações relevantes que podem agregar valor ao
processo de desenvolvimento. Para que assim, a empresa seja mais competitiva no mercado
com relação a suas concorrentes, e agregue mais valor a seu produto ou serviço.
Nesse contexto, o Business Intelligence (BI), é uma ferramenta que pode auxiliar
os funcionários que compõem a parte estratégica da empresa a tomar decisões, ou seja, as
ferramentas de BI, disponibilizam recursos para as pessoas que utilizam, analisar a
performance do assunto escolhido.
Com isso, esse trabalho, visa implementar uma arquitetura de BI, para analisar as
demandas disponibilizadas por uma empresa desenvolvedora de software. Essa arquitetura é
composta pela base de dados relacional, local que será extraído os dados; a transformação
desses dados; e importação dos dados na base de dados dimensional (Data Warehouse); e a
ferramenta que analisa os dados na base dimensional.
Assim, será feito a pesquisa que analisará todos esses dados, dos últimos 5 anos
de desenvolvimento de software, e será apresentado as conclusões chegadas com essas
análises.
1.1
PROBLEMÁTICA
A fabricação de software é uma atividade intensiva em conhecimento, e requer
capital humano altamente especializado para realizar essa atividade.Conhecer o andamento do
14
processo de produção de software, é de extrema importância para a empresa desenvolvedora.
O processo de produção de software, gera as demandas para melhoria do sistema,de forma
que se forem analisadas as demandas, podem dar indícios e indicadores que permitem fazer a
gestão do processo de desenvolvimento, de forma mais adequada, para a melhora do processo
e tomar decisões baseadas em planejamento estratégico da empresa.
Nesse sentido, o principal objetivo do trabalho a alcançar é transformar os dados
brutos,extraídosdo processo de produção de um software,em informações estratégicas para
auxiliar a tomada de decisão, que for fim seja de acordo com o planejamento estratégico da
empresa.
A riqueza de informação gerada dentro da empresa pela fabricação de software,
muitas vezes,não é muito explorada, porque, ossoftwares que controlam essa fabricação, já
fazem essa análise através de relatórios específicos, porém apresentam informações restritas.
Por vez, esses relatórios induzem a pensar da mesma forma. Segundo Inmon (2001 p. 18), “A
verdade é que somente uma quantidade limitada de análise pode ser feita com a contagem
simples, sendo necessário que o analista use formas mais complexas de análise”, portanto,
para realizar uma contagem complexa de dados, podemos utilizar fatores que não são
utilizados nos relatórios apresentados nos softwares que controlam o processo de fabricação
de sistemas.
Portanto, para conseguir unir os dados brutos,gerado pelo sistema que controla o
desenvolvimento do software, e analisando as variáveis externas ao sistema que controla o
desenvolvimento, ou seja, as pessoas responsáveis por gerenciar o desenvolvimento. Com
isso, podehaver um resultado de análise complexa de dados, podendo gerar informações para
tomadas de decisão.
De acordo com o problema de organizar e analisar dados do processo de
desenvolvimento de sistemas, podemos construir umaarquiteturade BI(Business Intelligence),
para auxiliar na solução dos problemas citados, de forma que a informação seja de acesso
rápido e fácil.
15
1.2
OBJETIVOS
A seguir, são apresentados os objetivos deste trabalho em duas partes: objetivo
geral e objetivos específicos, assim, tornando explícitos os objetivos da pesquisa realizada.
1.2.1
Objetivo geral
Construir umaarquitetura de BI sobre o processo de desenvolvimento de software,
que auxilie nas decisões parasua melhora do processo.
1.2.2
Objetivo específico
Os objetivos específicos são separados em tópicos:
 entender o processo de desenvolvimento de software da empresa em
questão;
 analisar os dados brutos gerados pelo processo de desenvolvimento;
 construir uma arquitetura de BI de informações sobre o processo de
desenvolvimento de software;
 apresentar e discutir os resultados obtidos com a análise realizada
sobre a arquitetura construída.
16
1.3
JUSTIFICATIVA
Percebe-se que, emuma era quando a informação gerada é muito importante para
tomar decisão dentro da empresa, cada vez mais é investido em análises críticas que podem
ter como objetivo ajudar a empresa a encontrar resultados que descrevem o ambiente
corporativo. Para chegar ao resultado,é preciso um processo de análise de dados que possa
auxiliar a encontrar informações relevantes para empresa.
Com isso, podemos utilizar técnicas para construção da arquiteturade BI (Business
Intelligence),para realizar esse processo de análise de dados, até que os dados brutos se
transformem em informações. O BI é voltado para transformar pequenos ou grandes dados,
em informações, de acordo com o assuntoanalisado, fazendo com que cumpra as etapas de
análise de dados.
Estudar esse assunto é muito relevante para os pontos de vistas científico,
tecnológico, social, profissional e pessoal.
Para o ponto de vista científico, é importante porque é uma nova pesquisa sobre o
processo de desenvolvimento de sistemas, que apresenta dados atuais sobre desenvolvimento
de software,com isso, pode servir para outras áreas de sistemas de informação, que estudam o
processo de desenvolvimento de sistemas.
Do ponto de vista tecnológico, é importante esta pesquisa, porque se trata de
aplicações de técnicas de BI,que apresentam a junção da teoria mencionada por principais
autores da área, aplicada em um estudo de caso, de uma empresa de desenvolvimento de
software, utilizando ferramentas atuais de BI para analisar os dados.
Análise do ponto de vista social e profissional, é importante porque socializa a
informação, ou seja, esta pesquisa trata de informações que podem ser utilizadas em favor da
sociedade, com intuito de informar pessoas e empresassobrea importância de como as
informações obtidas podem servir para conhecimento da área.
Do ponto de vista pessoal, é importante para o autor, porque servirá como porta de
entrada para o mercado de trabalho na área de BI, além de ter como principal função a
satisfação de descrever o assunto com que o autor identifica-se.
17
1.4
ESTRUTURA DA MONOGRAFIA
A monografia está dividida em cinco partes. O capítulo um apresenta a
problemática, os objetivos e justifica o trabalho científico. O capítulo dois é referente à
revisão bibliográfica, realizada que apresenta as principais ideias de autores da área sobre o
assunto de BI e Data Warehouse. No capítulo três,encontra-se a metodologia de trabalho
aplicada na monografia, ou seja, os métodos que foram inseridos para realização da pesquisa.
O capítulo quatro descreve a aplicação do problema com a metodologia descrita no capítulo
anterior. O Capítulo cinco apresenta a conclusão da monografia.
18
2
REVISÃO BIBLIOGRÁFICA
Neste capítulo, serão apresentadas referências textuais de autores da área para a
compreensão de conceitos sobre o assunto abordado.
2.1
BUSINESS INTELLIGENCE (CONCEITOS E DEFINIÇÕES)
Na afirmação de Barbieri (2001, p. 34), “O conceito de Business Intelligence, de
forma mais ampla, pode ser entendido como a utilização de variadas fontes de informação
para definir estratégias de competitividade nos negócios da empresa”. Atualmente, o ambiente
que empresas estão situadas tem aumentado com a concorrência, portanto para enfrentar essa
disputa, tem-se adotadas diversas práticas para coletar dados e transformá-los em
informações. Entretanto, em alguns casos, tem-se aplicado o conceito de BI apontado por
Barbieri em que empresas estão pesquisando dados de diversas fontes e reunindo em Data
Warehouse para efetuar análises.
Como afirma Turban et. al. (2009, p. 21):
O ambiente de negócios no qual as empresas operam atualmente está se tornando
cada vez mais complexo e mutante. As empresas, privadas ou públicas, sentem
crescentes pressões forçando-as a responder rapidamente a condições que estão
sempre mudando, além de terem que ser inovadoras na maneira com que operam.
Portanto,algumas empresas têm construído BI para suprir essa necessidade de
conseguir uma resposta de maneira mais ágil e conseguir operar em situações onde a pressão
por resultados tem aumentado.
Desse modo, o BI tem-se apresentado para empresas como forma de obter as
informações de modo rápido e preciso, fazendo com que relatórios não sejam suficientes para
processar um volume de dados significante.
Na sequência,Barbieri(2009, p. 124) relata que “a organização vencedora será
aquela que entender que o que mantém uma organização competitiva é o seu ativo de
conhecimento, representado pelos seus colaboradores”. Entretanto, a utilização do BI não
19
tem-se apoiado somente em técnicas e abordagem e também em capacidade de raciocínio
humano.
Turbanet. al. (2009, p. 47) acrescenta que o BI não é uma escolha entre a empresa
e, sim, uma necessidade a que está inerente. Percebe-se que mais e mais ferramentas de BI
irão invadir o mercado para efetuar análises que podem apresentar os dados de diversos
setores.
É importante ressaltar que, no entender de Turban (2009, p.27), “O conceito
original de Sistemas de Informação Executivas foi transformado em BI”. Portanto, com essa
afirmação, tem-se entendido que BI pode ser um sistema de informação que pode executar
análises em dados ou manipulação.
Na compreensão de Turban et. al. (2009, p. 32), “O principal benefício do BI para
empresa é sua capacidade de fornecer informações precisas, quando necessário”.Podem-se
citar, como benefícios, os seguintes pontos:
 economia de tempo;
 versão única da verdade;
 melhores estratégias e planos;
 melhores decisões táticas;
 processos mais eficientes;
 economia de custos.
A seguir, a figura 1, expõe a evolução do BI na visão de Turban et. al. (2009),
exibindo os recursos que se podem integrar ao sistema de Business Intelligence. Pode-se
considerar como ferramentas de arquitetura de BI, ferramentas OLAP, Data Warehouse e
ferramentas Front-End, que serão abordados a seguir.
20
Figura 1 – Evolução do BI
Fonte: Turban et. al. (2009, p. 29).
2.1.1
Arquitetura de BI
Conforme define Turban et. al. (2009, p.28):
O BI tem quatro grandes componentes: um data warehouse (DW), com seus dadosfonte a análise de negócios, uma coleção de ferramentas para manipular e analisar os
dados no data warehouse, incluindo datamining; businessperformancemanagement
(BPM) para monitoraria e análise do desempenho e uma interface de usuário (como
o dashboard).
Na sequência, Barbieri (2011, p. 108) salienta que:
Estruturas especiais de armazenamento de informação como data warehouse (DW),
data marts (DM) e ODS (OperationalDataStore), com o objetivo de montar uma
base de recursos informacionais capaz de sustentar a camada de inteligência da
21
empresa e possível de ser aplicado aos seus negócios, como elementos diferenciais e
competitivos. Juntamente com o conceito de DW, DM e ODS, o conceito de BI
contempla também o conjunto de ferramentas de desenvolvimento de aplicações e
ferramentas de desenvolvimento de aplicações e ferramentas ETL (extração,
tratamento e carga), fundamentais para a transformação de recursos de dados
transacional em informacional.
Com a arquitetura de BI, tem-se ferramentas como aplicações que auxiliam a
manipulação de dados. É importante ressaltar que os componentes citados na figura
anteriorpodem ter funções definidas como aprovar ou não um pedido de empréstimo
(TURBAN EL. AL. 2009, p.31).
Nafigura 2,a seguir tem-se a arquitetura de BI dividida em 3 ambientes: ambiente
de Data Warehouse, ambiente de análise de negócio e Desempenho de estratégia. O
Ambiente de Data Warehouse, organiza, resume e padroniza os dados, o ambiente de
negócios acessa e manipula os dados, o desempenho de estratégia têm-se estratégias de BPM
(Business Performance Management).
Figura 2– Arquitetura de BI
Fonte: Turban et. al. (2009, p. 30).
Na compreensão de Turban et. al.(2009, p.109), “O termo processamento analítico
online(OLAP) refere a uma variedade de atividades normalmente executadas por usuários
finais em sistemas online”, portanto OLAP tem um conceito complexo, pois não se trata
apenas de um módulo de relatórios ou consultas a banco de dados. Ferramentas OLAP podem
entender como uma forma de unir análise de relacionamentos, buscar padrões e tendências e
exceções. (TURBAN ET. AL. 2009, p. 111).
22
Nas palavras de Kimball (2002, p. 3), “O data warehouse deve fazer com que
informações de uma empresa possam ser facilmente acessadas”, portanto, identifica-se o Data
Warehouse como uma parte fundamental do BI, responsável por armazenar os dados de forma
consolidada.
O DW deve ser confiável e obtido a partir de fontes confiáveis da empresa,
filtrando apenas os dados interessantes para a análise, preservando o processo de negócio. O
Data Warehouse deve ser adaptável a mudanças e seguro, porque é concebido para o dever de
guardar as informações.(KIMBAL, 2002, P.4).
Como contempla Turban et. al. (2009, p. 70), “Antes dos Data Warehouses, dos
data marts e dos softwares de BI, oferecer acesso às fontes de dados era um processo
trabalhoso e de grande porte”, com tudo, ferramentas ETL podem integrar diversas bases de
dados, e ou sistemas de informação (TURBAN EL. AL. 2009, P. 70).
As transformações e cargas podem ser consideradas como parte principal do
processo de migrações de dados.O processo de migrar o dado consiste em extraí-los,
transformá-los e carregá-los. Essa migração ocorre por meio de regras ou por combinações de
dados com outros dados. Essas funções são integradas a ferramentas ETL, que retiram os
dados de um determinado local e os armazenam em outro local (TURBAN ET. AL. 2009, P.
72).
A seguir, são apresentados conceitos de ferramentas ETL e seus processos de
migração de dados.
2.2
ETL
Em concordância com Barbieri (2001 p. 74), “Nessa etapa, deverão ser definidos
os processos requeridos de transformação do modelo Fonte para o modelo Dimensional”,
deste modo essa afirmação conceitua que ETL (Extract, Transform and Load), na tradução de
Barbieri (2001, p.74), “ETC – Extração, Transformação e Carga”, pode-se entender como a
transformação de dados.
Segundo Turbanet. al. (2009, p.71), “Um grande objetivo do data warehouse é
integrar dados de múltiplos sistemas”, entretanto,ETL pode ser qualificada como uma
tecnologia de integração de dados.(Turban et. al., 2009, p.71).
23
Parafraseando Turban et. al. (2009, p.72):
O objetivo do processo de ETL é carregar os dados integrados e limpos no
warehouse. Os dados usados nestes processos podem ser oriundos de qualquer fonte:
uma aplicação de main-frame, uma aplicação ERP, uma ferramenta de CRM, um
arquivo texto, uma planilha de Excel ou até uma fila de mensagens.
Conforme a figura 3, a seguir, pode-se identificar uma forma de realizar o
processo de ETL de forma aplicada.
Figura 3 - Processo ETL
Fonte: Turban et. al. (2009, p. 72).
2.2.1
Extração de dados
Uma etapa da extração de dados é filtrar ou limpar os dados, conforme afirma
Barbieri (2001, p.75):
Filtro de Dados: Relaciona os procedimentos e condições para se eliminar os
elementos de dados indesejáveis no modelo Dimensional. Por Exemplo, desejamos
que somente Ordens de Compras com valores totais maiores que R$: 1000,00 sejam
considerados no sistema gerencial do projeto.
Após o processo de filtrar ou limpar os dados, tem-se outro processo na
compreensão de Turban et. al. (2009, p. 73), “Todos os arquivos de entrada são gravados em
um conjunto de tabelas temporárias, criadas para facilitar o processo de carga”, em suma, esse
processo de extração de dados pode-se entender como preparação para transformação de
dados que identificamos na próximaetapa.
24
2.2.2
Transformação de dados
Para poder transformar ou corrigir os dados limpos, existem outras três etapas na
concepção de Barbieri (2001, p.75):
Integração de Dados: Define a forma de se correlacionar informações existentes em
fontes distintas, e que deverão ser integradas no sistema gerencial. Suponha que
alguns dados de fornecedor estejam no BD de fornecedores corporativo da empresa,
mas que algumas informações específicas, de interesse da área objeto do sistema
aplicado, estejam em planilhas locais. A integração dessas informações se torna
fundamental para os requisitos do sistema e deverá ser previsto nessa fase. Outro
exemplo poderia ser o caso de dados que estão codificados em um ambiente (por
exemplo, o código do fornecedor embute região) e que deverão ser decodificados a
fim de facilitar o seu uso, associando-se a ele uma informação explícita sobre região.
Condensação de Dados: Define forma de reduzir volumes de dados visando obter
informações resumidas e sumariadas. Normalmente essas sumarizações acontecem
nas dimensões dos dados, como tempo e geografia. Um exemplo seria sumarização
em termos semanais de dados diários de vendas, ou o resumo em níveis geográficos,
como por exemplo, vendas por região.
Conversão de Dados: Define os procedimentos para se transformar dados unidades,
formatos e dimensões diferentes.
Porém, uma ressalva feita por Turban et. al. (2009, p. 73), “Qualquer problema na
qualidade dos dados pertencente aos arquivos-fontes precisa ser corrigido antes que os dados
sejam carregados no data warehouse”, pode-se entender que o processo de transformação de
dados,após estarem dentro do DW,poderá ser grande.
Esse processo de transformação de dados pode ser executado por meios de
ferramentas tradicionais, como exemplo de algumas linguagens de programação como
PL/SQL, C++ ou .Net Framework, conforme. (TURBAN et al., 2009, p.73).
Após a etapa de transformar os dados pode-se ter a última etapa de ETL, carregar
os dados dentro do modelo Dimensional, que será abordado a seguir.
2.2.3
Carregamento de dados
Conforme afirma Barbieri (2001, p. 75), “Derivação de Dados: Define os meios e
fórmulas para produzir dados virtuais, a partir de dados existentes”, assim, definidos os meios
e formulas, é efetuada a carga de dados em um modelo dimensional (BARBIERI, 2001, p.
75).
25
Sobre carregamento de dados pode ser afirmado que: “O processo de
carregamento e dados em um data warehouse pode ser realizado por meio de ferramentas de
transformação de dados que fornecem uma GUI para auxiliar o desenvolvimento e
manutenção das regas de negócios”. (TURBAN et al., 2009, p.73.)
Entretanto, após a etapa de realizar a carga de dados, pode-se entender Data
Warehouse,na sessão seguinte.
2.3
DATA WAREHOUSE
Na compreensão de Barbieri (2011, p. 113), “[...] um grande depósito central de
informações empresariais tratadas, limpas e integradas, construindo inicialmente, e de onde
outros depósitos secundários (data marts ou mercados de dados) são originais e construídos”.
Nas palavras de Kimball (2002, p. 2):
Um dos bens mais preciosos de qualquer empresa são suas informações. E quase
sempre a empresa mantém esse bem de duas formas: os sistemas operacionais de
registro e o data warehouse. Em termos gerais, os sistemas operacionais são o local
em que os dados são colocados, e o data warehouse é o local a partir de onde eles
são obtidos.
Na visão de Turban et. al. (2009, p.57):
Em poucas palavras, um data warehouse (DW) é um conjunto de dados produzido
para oferecer suporte à tomada de decisões; é também um repositório de dados
atuais e históricos de possível interesse aos gerentes de toda a organização. Os dados
normalmente são estruturados de modo a estarem disponíveis em formato pronto
para as atividades de processamento analítico (p. ex. processamento analítico online
[OLAP], data mining, consultas, geração de relatórios, outras aplicações de suporte
a decisão). Portanto, um data warehouse é uma coleção de dados orientada por
assunto, integrada, variável no tempo e não-volátil, que proporciona suporte ao
processo de tomada de decisões da gerência.
Entretanto, nas abordagens de Barbieri (2011), Kimbal (2002) e Turban et. al.
(2009), pode-se identificar um conceito que converge, como um conjunto de dados para
apoiar a tomada de decisão.
26
2.3.1
Abordagem Bill Inmon
Sob o ponto de vista de Barbieri (2011, p.113), a abordagem que Bill Inmon
concentrou-se inicialmente no estilo tradicional de banco de dados, ou seja, muito próximo do
primeiro projeto de banco de dados existente, tentando resolver problemas para integração de
dados nas áreas funcionais da empresa.
Entretanto, Bill Inmon concebeu uma nova proposta denominada de DW 2.0, com
ênfase em metadados e dados não estruturados e também concebeu a ideia de armazenamento
no DW ser feito de acordo com a idade dos dados, ou seja, armazenando de forma
diferenciada os dados, como exemplo, arquivando dados com mais de cinco anos, dados com
data maior que três anos e menor que cinco, ficariam em uma região mais acessível, e dados,
com menos de três anos, ficariam no próprio DW. (BARBIERI, 2011, p. 113).
Com um estilo mais simples, Ralph Kimball é abordado com sua contribuição na
sessão seguinte.
2.3.2
Abordagem Ralph Kimball
Em concordância com autor Barbieri (2011, p. 113), a abordagem de Ralph
Kimball pode ser entendida como mais simples, com relação a abordagem de Bill Inmon. A
abordagem de Ralph Kimball é feita na metodologia star schema(esquema estrela), apontado
para projetos menores e independentes, focado em assuntos específicos, como exemplo a
criação de uma Data Marts (DM)para cada departamento dentro da empresa. Portanto, a
união desses DM pode-se entender como DW.
Após as duas abordagens de Ralph Kimball e Bill Inmon, pode-se demonstrar
algumas características do Data Warehouse na sessão a seguir.
27
2.3.3
Características do Data Warehouse
Algumas características do Data Warehousepodem ser citadas por Turban et. al.
(2009, p. 57).
Os dados são organizados por assunto, como vendas, produtos ou cliente, e
contêm apenas informações relevantes para apoiar o suporte a decisão. Como afirma Turban
et. al. (2009, p.57), “Um data warehouse difere de um banco de dados operacional no sentido
de que esses, em sua maioria, são orientados por produto e ajustados para lidar com
transações que atualizem o banco de dados”.
O data warehousedeve serintegrado aos assuntos de forma consistente, por
exemplo, não deve apresentar diferenças entre unidades de medidas.
Deve apresentar variável no tempo, ou seja, apresentar os dados de como
visualizações diárias, semanais e mensais.
Os dados, no DW, não podem ser inconsistentes, portanto após inseridos não
podem ser realizadas nenhuma modificação nos registros.
Após as características de um DW, são apresentados os objetivos que podem ser
alcançados na sessão a seguir.
2.3.4
Objetivosdo Data Warehouse
Segundo Barbieri (2001, p. 51), “A ideia, via DW, é armazenar os dados em
vários graus de relacionamento e sumarização, de forma a facilitar e agilizar os processos de
tomada de decisão por diferentes níveis gerenciais”.
Em concordância com Kimball (2002, p.3), “Antes de nos aprofundarmos nos
detalhes de modelagem e implementação, vale a pena nos concentrarmos nos objetivos
fundamentais do data warehouse”, com tudo, serão apresentados alguns objetivos do data
warehouse na visão de Kimball (2002).
Os objetivos do DW podem ser listados como:
28
 o DW tem que prover acesso facilidade para acesso às informações da
empresa;
 as informações apresentadas por o DW terão que ser consistentes;
 odata warehouse deve ser adaptado para lidar com mudanças;
 DW deve ser seguro e proteger as informações;
 o DW deve dar suporte para a tomada de decisão;
 deve ser aceito na comunidade de negócio.
O autor Kimball (2002, p.3), apresenta uma abordagem para que os objetivos
possam ser alcançados e supra essas necessidades, citadas a cima.
Com os objetivos traçados, pode-se dar início a arquitetura de Data Warehouse,
conforme sessão a seguir.
2.3.5
Arquitetura do Data Warehouse
No entender de Turban et. al. (2009, p. 62), “Há algumas arquiteturas básicas de
data warehouse. As arquiteturas de duas e de três camadas são comuns, mas, às vezes há
apenas uma camada”.
Com tudo, (TURBAN et al., 2009), divide as três camadas do DW em: o Data
Warehouse, o software que extrai e consolida os dados no DW e software responsável por
acessar e analisar os dados do DW.
Podem-se analisar, a seguir, as duasarquiteturas do DW,divididas em dois tipos,
três camadas e duas camadas.
2.3.5.1 Arquitetura três camadas
A arquitetura de três camadas tem esse nome por se tratar de três camadas que
são:o servidor de banco de dados, onde são armazenados os dados referentes ao DW, camada
29
de aplicação, onde faz a comunicação entre o servidor de banco de dados e cliente e a camada
do cliente onde são apresentados os dados. (TURBAN ET. AL., 2009).
Na figura 4,a seguir,sãoapresentadas as três camadas de forma gráfica.
Figura 4 - Arquitetura três camadas
Fonte: Turban et. al. (2009, p. 63).
2.3.5.2 Arquitetura duas camadas
Na arquitetura de duas camadas, a divisão acontece entre servidor de aplicação e
banco de dados, fisicamente no mesmo local, ou seja, o servidor de aplicação e banco de
dados ficam no mesmo local. Por tanto será apenas um servidor que irá prover os recursos
necessários para visualização na camada cliente. (TURBAN ET. AL., 2009).
Essa arquitetura oferece uma economia de hardware maior por se tratar de apenas
um servidor, porém se obtêm um DW com alto volume de dados, poderá ser prejudicial para o
desempenho do servidor. (TURBAN ET. AL., 2009).
Conforme figura 5 a seguir, é apresentada a arquitetura em duas camadas.
30
Figura 5 - Arquitetura duas camadas
Fonte: Turban et. al. (2009, p. 64).
Após apresentar sobre a arquitetura de um DW, poderá ser iniciado um tópico
sobre o entendimento dos componentes do Data Warehouse.
2.3.6
Componentes do Data Warehouse
De acordo com Kimball (2002, p. 8), “[...] precisamos considerar quatro
componentes separados e distintos, quando analisamos o ambiente de data warehouse:
sistemas operacionais de origem, data staging area, área de apresentação de dados e
ferramentas de acessos”.
Na figura 6 a seguir,encontram-se os componentes do DW proposto pelo autor
(KIMBALL, 2002).
31
Figura 6 - Componentes do data warehouse
Fonte: Kimball (2002, p. 9).
a) Sistemas operacionais de origem: “Esses são os sistemas operacionais de
registro que capturam as transações da empresa”. (KIMBALL, 2002, p. 9). Portanto, esses
sistemas são externos ao DW e têm a função de extrair os dados;
b)Data stagingarea:“A data staging areado data warehouseé tanto uma área de
armazenamento com um conjunto de processos e, normalmente, denomina-se de ETL”
(KIMBALL, 2002, p. 12), conforme abordado na sessão 2.3;
c) Apresentação dos dados: “[...] é o local em que os dados ficam organizados,
armazenados e tornam-se disponíveis para serem consultados diretamente pelos usuários,
por criadores de relatórios e por outras aplicações de análise”. (KIMBALL, 2002, p. 13).É
onde ficam armazenados os data marts de acordo com os assuntos ou áreas da empresa;
d) Ferramenta de acesso:“Por definição, todas as ferramentas de acesso de dados
consultam os dados na área de apresentação do data warehouse. É claro que a consulta é o
ponto principal do uso do data warehouse”. (KIMBALL, 2002, p.17).
Após a definição de Kimball (2002), sobre os componentes do DW, pode-se
apresentar conceitos sobre modelagem dimensional.
32
2.3.7
Modelo dimensional
Com referência a modelagem dimensional e tabelas fatos, pode-se citar a
afirmação de Kimball (2002, p. 20):
Na década de 1970, AC Nielsen e IRI usaram esses termos de modo consistente para
descrever suas ofertas de dados corporativos, que poderiam ser descritos
precisamente hoje em dia como data marts dimensionais para dados de vendas no
varejo. Muito antes de a simplicidade ser um estilo de vida, os desenvolvedores de
bancos de dados adotaram esses conceitos para simplificar a apresentação de
informações analíticas. Eles compreenderam que um banco de dados não seria usado
a menos que fosse incluído de forma simples.
Na visão de Machado (2011, p. 79):
A modelagem multidimensional é uma técnica de concepção e visualização de um
modelo de dados de um conjunto de medidas que descrevem aspectos comuns de
negócios. É utilizada especialmente para sumarizar e reestruturar dados e apresentalos em visões que suportem a análise dos valores desses dados.
Portanto, a modelagem dimensional pode ser uma forma de modelar os dados,
para que os dados fiquem de fácil acesso para manipulação e/ou extração de relatórios
(KIMBALL, 2002, p.20).
Em comum, os autores Barbieri (2001), Kimball (2002) e Machado (2011), citam
que a modelagem dimensional é composta dos seguintes itens:
 tabela fato;
 tabela de dimensão;
 medidas.
Para o melhor entendimento, os itens, citados a cima, serão abordados nas
próximas sessões.
2.3.7.1 Tabelas fato
Em concordância com Kimball (2002, p. 21), Uma tabela de fatos é a principal
tabela de um modelo dimensional em que as medições numéricas de desempenho da empresa
estão armazenadas”. A tabela fato é responsável por armazenar os dados de medição dos
processos de negócio em um único local. (KIMBALL, 2002, p.21).
33
A palavra fato pode representar uma medição de negócio. Pode-se imaginar as
vendas diárias de um mercado, em que cada dia é anotado a quantidade de produtos vendidos
e quantidade de venda em dinheiro para cada produto comercializado. Então é feito um
agrupamento por dia, produto e valor, resultando em uma linha para cada item agrupado
(KIMBALL, 2002, p.21).
A seguir, é exibida a figura 7 que representa um exemplo de tabela fato.
Figura 7 - Tabela fato
Fonte: Kimball (2002, p. 21).
Para Kimball (2002, p. 23), “Todas tabelas de fatos possuem duas ou mais chaves
estrangeiras, conforme designado na notação FK (foreign key) ”. Essa notação é apresentada
na figura 7, acima. Todavia essa chave estrangeira pode se referir a outra tabela, como
exemplo, na figura 7 Chave do Produto (FK), que pode referenciar uma tabela de produtos
que podem descrever produtos cadastros. Essa aplicação pode-se fazer para que não seja
perdido a referência do produto descrito na tabela fato. (KIMBALL, 2002, p. 23).
Citando a afirmação de Kimball (2002, p. 23), “[...] veremos que todas as
granularidades de uma tabela de fatos enquadram-se em uma destas três categorias: transação,
instantâneos periódico e instantâneos acumulados”. Podeser abordado o assunto granularidade
de tabela fato na sessão seguinte.
2.3.7.2 Granularidade
O conceito de granularidade pode ser apresentado conforme Kimball (2002, p.
37):
34
Declare o grão (nível de detalhes) do processo de negócio. Declarar o grão significa
especificar exatamente o que cada linha da tabela de fatos representa. O grão
exprime o nível de detalhes associados às medidas da tabela de fatos. Ele fornece a
resposta para a pergunta: “Como descrever uma linha específica na tabela de fatos?
”.
São exemplos de declaração de grãos:
 um item de linha individual em um ticket de vendas a varejo de um cliente
à medida que é lido por um dispositivo de varredura (scanner);
 um item de linha em uma conta recebida de um médico;
 um cartão de embarque individual para entrar no avião;
 um instantâneo diário dos níveis de estoque de cada produto em um
warehouse;
 um instantâneo mensal de cada conta bancária.
Conforme descrito por Kimball (2002), a granularidade de tabelas fato
instantâneos periódicos são para apresentar dados em períodos de tempo regulares, exemplo o
valor em venda para os produtos dividido em meses. Outra granularidade é fato de transação
que representa os dados de um acontecimento no tempo instantâneo. Fato de instantâneo
cumulativo pode representar diversas datas e múltiplos eventos.
Após o descrito sobre tabelas fatos e granularidade, poderá ser apresentado, na
próxima sessão sobre tabelas de dimensão.
2.3.7.3 Tabelas de dimensão
Como afirma Kimball (2002, p. 24), “Em um modelo dimensional bem projetado,
as tabelas dimensão possuem muitas colunas ou atributos. Esses atributos descrevem as linhas
na tabela de dimensão”. Entretanto, a tabela de dimensão está sempre acompanhada a uma
tabela fato. Elas podem ser caracterizadas por carregar os atributos da tabela fato, porém em
uma tabela dimensão (KIMBALL, 2002, p. 25).
No exemplo, a seguir, pode-se ter entendimento de vários atributos carregados em
tabelas de dimensão. Como exemplo, na figura 8, é apresentada uma tabela dimensão de um
produto, em que essa tabela pode conter atributos desse produto.
35
Figura 8 - Tabela dimensão
Fonte: Kimball (2002, p. 25).
Conforme afirmação de Kimball (2002, p. 25), “Os melhores atributos são os
textuais e os discretos. Os atributos devem ser formados por palavras reais e não por
abreviações criptografadas”.
Na concepção de Machado (2011, p. 6), “Conceitualmente são os elementos que
participam de um fato, assunto de negócios. São as possíveis formas de visualizar os dados,
ou seja, são os “por” dos dados: “por mês”, “por país”, “por produto” e “por região”“.
Após apresentar, nas sessões anteriores, sobre os assuntos tabela fato,
granularidade e tabela dimensão, pode-se apresentar a sessão de medidas, ou variáveis, como
afirma Machado (2011).
2.3.7.4 Medidas (variáveis)
Na visão de Machado (2011, p. 81), “Medidas são atributos numéricos que
representam um fato, a performance de um indicador de negócios relativo às dimensões que
participam desse fato”, é possível citar alguns exemplos de medida como: valor total das
36
vendas, quantidade de produtos vendidos, quantidade em estoque de produtos, custo da venda
e lucro obtido com venda.
Medidas podem ser entendidas como as variáveis que serão calculadas, existente
dentro da tabela fato, ou a forma que será calculada.
Na próxima sessão, será feita a união do conteúdo apresentado nas sessões
anteriores, contendo tabela fatos e dimensão, podendo ser resultado em um data warehouse.
2.3.7.5 União de fatos e dimensão
Para Barbieri (2001, p.81), “O produto final da modelagem Dimensional é a
produção de um modelo conceitual dimensional, formado por tabelas fatos e tabelas
dimensão”.
No entendimento de Kimball (2002, p. 27), “[...] a tabela de fatos formada por
medidas numéricas é associada a um conjunto de tabelas dimensão preenchidas com atributos
descritivos”.
Na compreensão Machado (2011, p. 92):
O modelo estrela é a estrutura básica de um modelo de dados multidimensional.
Sua composição típica possui uma grande entidade central denominada fato (fact
table) e um conjunto de entidades menores denominadas dimensões (dimension
table), arranjadas ao redor dessa entidade central, formando uma estrela.
A visão dos três autores, citados a cima, Barbieri (2001), Kimball (2002) e
Machado (2011), podem convergir para o mesmo modelo dimensional, ou esquema estrela,
conforme figura 9, apresentada a seguir, podendo serem visualizadas as dimensões tempo,
região, cliente, vendedor e produto, e apresentando a tabela de fato vendas.
37
Figura 9 - Modelo estrela
Fonte: Machado (2011, p. 92).
Com a compreensão de modelo dimensional, poderá ser abordado, na próxima
sessão, OLAP, responsável por apresentar os dados existentes no DW.
2.4
OLAP
OLAP, na concepção de Machado (2011, p.85), ” É o conjunto de ferramentas que
possibilitam efetuar a exploração dos dados de um data warehouse”.
De acordo com Thomsen (2002, p. 5):
Os conceitos de OLAP incluem a noção ou ideia de múltiplas dimensões
hierárquicas e podem ser usadas por qualquer um para que se pense mais claramente
a respeito do mundo, seja o mundo material da escala atômica à escala galáctica, o
mundo econômico dos micro agentes às macro economias, ou o mundo social dos
relacionamentos interpessoais aos internacionais. Em outras palavras, mesmo sem
qualquer tipo de linguagem formal, é útil apenas sermos capazes de pensar em
termos de um mundo multidimensional e com múltiplos níveis, independente da sua
posição na vida.
No entender de Turban et. al. (2009, p. 109):
O termo processamento analítico online (OLAP) se refere a uma variedade de
atividades normalmente executadas por usuários finais em sistemas online. Não há
um consenso sobre quais atividades são consideradas OLAP. Normalmente, OLAP
inclui atividades como geração de respostas de consultas, solicitação de relatórios e
gráficos ad hoc e execução dos mesmos, realização de análises estatísticas
tradicionais ou modernas e construção e apresentação visuais.
38
Basicamente os produtos de OLAP oferecem recursos de modelagem, análise e
visualização de grandes conjuntos de dados, ou para sistemas de gerenciamento de
banco de dados (SGBD) ou, mais frequentemente, para sistemas de data warehouse.
Os produtos oferecem também uma visão conceitual multidimensional dos dados.
A seguir, serão apresentados conceitos de operações básicas de OLAP.No
entender de Machado (2011, p. 85), “[...] são as aplicações às quais os usuários finais têm
acesso para extrair os dados de suas bases e construir os relatórios capazes de responder às
suas questões gerenciais”.
2.4.1
Drill Down
Na visão de Machado (2011, p. 86), “São as operações para movimentar a visão
dos dados ao longo dos níveis hierárquicos de uma dimensão”. Portanto, quando é utilizada
essa operação básica, aumenta-se o nível de detalhamento da informação ediminui-se o nível
de granularidade. (MACHADO 2011, p. 86).
A seguir, é apresentada a figura 10 da operação de Drill Down.
Figura 10 – Operação Drill Down
Fonte: Machado (2011, p. 87).
39
2.4.2
Roll Up
Na afirmação de Machado (2011, p. 87), “O Drill Up ou Roll Up é o contrário.
Ele ocorre quando o usuário aumenta o nível de granularidade, diminuindo o nível de
detalhamento da informação”.
A seguir, é possível visualizar a figura 11 da operação Roll Up.
Figura 11 – Operação Roll Up
Fonte: Machado (2011, p. 86).
2.4.3
Drill Across
Conforme Machado (2011, p. 88), Drill Across“Ocorre quando o usuário pula de
um nível intermediário dentro de uma mesma dimensão. Por exemplo: a dimensão tempo é
composta por ano, semestre, trimestre, mês e dia”.
A seguir, encontra-se a operação Drill Across, representado por a figura 12.
Figura 12 – Operação Drill Across
40
Fonte: Machado (2011, p. 88).
2.4.4
Slice and Dice
No entender de Machado (2011, p. 89):
São operações para realizar navegação por meio dos dados na visualização de um
cubo. Slice and Dice significa em outra forma simplista a redução do escopo dos
dados em análise, além de mudar a ordem das dimensões, mudando desta forma a
orientação segundo a qual os dados são visualizados.
A seguir, é apresentado um exemplo da operação Slice and Dice na figura 13.
Figura 13 – Operação Slice and Dice
41
Fonte: Machado (2011, p. 90).
2.4.5
Pivot
Segundo Machado (2011, p. 91), Pivot“É o ângulo pelo qual os dados são vistos
ou trocados. Na prática, corresponde à modificação da posição das dimensões em um gráfico
ou troca de linhas por colunas em uma tabela”.
2.5
CONSIDERAÇÕES FINAIS DO CAPÍTULO
No próximo capítulo, seráabordadaa proposta de solução definida por o autor,para
sanar o problema apresentado no item “1.1 Problema”, atendendo ao objetivo geral deste
trabalhado, apresentado no item “1.2.1 Objetivo geral”, e também aos objetivos específicos no
42
item “1.2.2 Objetivos específicos”,conforme os conceitos apresentados no capítulo dois da
revisão bibliográfica.
43
3
MÉTODO
A seguir, será apresentado o método aplicado a este trabalho com referências a
autores da área de ciência e método.
3.1
CARACTERIZAÇÃO DO TIPO DE PESQUISA
Do ponto de vista da natureza, este trabalho pode ser considerado de pesquisa
aplicada, na visão de Silva e Menezes (2005, p. 20), “Objetiva gerar conhecimentos para
aplicação prática e dirigidos à solução de problemas específicos,envolvendo verdades e
interesses locais”. Portanto visa a gerar conhecimento para aplicação da arquitetura de
Business Intelligence aplicada no problema específico.
A abordagem pode ser considerada pesquisa qualitativa, também, porque, na
interpretação de Silva e Menezes (2005, p.20), “Não requer o uso de métodos e técnicas
estatísticas. O ambiente natural é a fonte direta para coleta de dados, e o pesquisador é o
instrumento chave”.
Do ponto de vista dos objetivos, esta pesquisa pode ser considerada exploratória,
porque, segundo (SILVA E MENEZES 2005, p.21), contém levantamento bibliográfico e
existe um caso a ser estudado.
Os procedimentos técnicos aplicados no trabalho conforme (SILVA E MENEZES
2005, p.21), são pesquisas bibliográficas, porque foi elaborado a partir de matérias de autores
renomados da área de estudo para realizar embasamento teórico, bem como estudo de caso, já
que tem um limite definido a ser estudado.
44
3.2
ATIVIDADES METODOLÓGICAS
Para alcançar os objetivos descritos, nos itens“1.2.2-Objetivo geral-” e “1.2.2Objetivos específicos-”, o trabalho foi divido nas seguintes atividades:
a) definição do tema, definir o problema descrito, descrever objetivos a serem
alcançados e apresentar uma justificativa para o estudo de caso, conforme
conteúdo do capítulo 1;
b) elaborar pesquisa com referência dos principais autores de renome da área de
Business Intelligence, para contextualizar os assuntos aplicados e entender
conceitos que podem ser aplicados no trabalho. Esse conteúdo é apresentado no
capítulo 2;
c) caracterizar a pesquisa, definir as etapas, produzir a arquitetura para solução
proposta de acordo com o problema encontrado, apresentar as delimitações e
cronograma das atividades que o autor realizará. Esseconteúdoéapresentado no
capítulo 3;
d) apróxima etapa consiste em apresentar uma arquitetura proposta para a solução do
problema. Para isso é necessário:
 entender os dados e o problema do domínio de aplicação do sistema,que é
na área de desenvolvimento de software;
 levantar os requisitos que atendam ao problema encontrado na etapa
anterior;
 realizar a criação dos diagrama domínio, casos de uso, robustez e
sequência, de acordo com a metodologia ICONIX;
 criar um modelo dimensional de forma gráfica que atenderá o problema
encontrado, com definição de granularidade dos dados;
 efetuar a criação do banco de dados, com tabelas e campos de acordo com
o modelo dimensional (DW);
 efetuar uma adequação e limpeza dos dados para adequar-se ao modelo
dimensional;
 carregar os dados no modelo dimensional, contidos em banco de dados,
utilizando ferramentas definidas pelo autor;
45
 analisar e interpretar os dados carregados no modelo dimensional através
de ferramentas apropriadas definidas pelo autor;
 apresentar informações sobre a análise realizada na etapa anterior.
e) apresentação dos resultados obtidos com a pesquisa realizada, com base nas
análises efetuadas.
3.3
ARQUITETURA DA SOLUÇÃO
Para representação da arquitetura utilizada, foi elaborado pelo autor conforme
figura 14,a seguir, uma possível arquitetura da solução.
Figura 14 – Arquitetura de BI – Solução Proposta
Fonte: O autor.
A seguir,é apresentado a descrição de cada componente listado na figura 14 –
Arquitetura de BI.
Base de dados: conjunto de dados das demandas realizadas na organização em
projetos.
ETL (extração, carga e transformação dos dados): momento em que serão
preparados os dados da base de dados para carga no Data Warehouse.
Data Warehouse: local onde serão armazenados os dados transformados em um
modelo dimensional.
46
Análise de dados: momento em que serão realizadas análises nos dados contidos
do DW, utilizando ferramentas OLAP.
3.4
DELIMITAÇÕES
O trabalho foi delimitado com base na arquitetura de BI, proposta no item “3.3.
ARQUITETURA DA SOLUÇÃO”.
Os dados utilizados são provenientes de projetos de desenvolvimento de software
por uma organização entre os anos de 2008 e 2013.
3.5
CONSIDERAÇÕES FINAIS DO CAPÍTULO
Nesse capítulo, foi descrito o método aplicado no trabalho e tipo de pesquisa
realizado. É apresentado de como serão seguidasas atividades até o termino do trabalho e uma
possível arquitetura de solução para conseguir alcançar os objetivos propostos, nos itens
“1.2.2-Objetivo geral-” e “1.2.2-Objetivos específicos-”.
A seguir, será apresentada a realização da estrutura proposta no item “3.3.
ARQUITETURA DA SOLUÇÃO”, seguindo o as atividades descritas no item “3.2.
ATIVIDADES METODOLOGICAS”.
47
4
DESENVOLVIMENTO DA SOLUÇÃO
Neste capítulo, será apresentada uma possível solução para atender ao problema
encontrado no item “1.1. PROBLEMÁTICA”, seguindo as atividades descritas no item “3.2.
ATIVIDADE METODOLOGICA” e, de acordo com o item “3.3. ARQUITETURA DA
SOLUÇÃO”, utilizando a metodologia ICONIX.
4.1
METODOLOGIA ICONIX
De acordo com Bona (2002, p.60), “o ICONIX é um processo simplificado que
unifica conjuntos de métodos de orientação a objetos em uma abordagem completa, com o
objetivo de dar cobertura ao ciclo de vida. ”,
Na compreensão de Silva e Videira (2001, apudBONA, 2002, p. 60), eles
“apresentam o ICONIX como uma metodologia prática, intermediária entre a complexidade
do RUP (Rational Unified Process) e a simplicidade do XP (Extreme Programming) ”.
Na afirmação de Rosenberg & Scott (1999, apud BONA, 2002, p. 61), “a base do
ICONIX é responder algumas questões fundamentais sobre o software”, Conforme essa
afirmação, são utilizados técnicas UML (Unified Modeling Language) que auxiliam para
encontrar a melhor resposta. A seguir, são apresentadas as técnicas: (ROSENBERG &
SCOTT, 1999, apud BONA, 2002, p. 61), que são:
 quem são os usuários ou atores do sistema, e o que eles estão tentando
fazer, para responder essa questão é elaborado o diagrama de casos de uso;
 no “mundo real” (domínio do problema), os objetos e as associações que
existem entre eles, para responder essa questão é elaborado o diagrama de
classes de alto nível;
 entender os objetos necessários para cada caso de uso, para responder essa
questão é elaborado a análise de robustez;
 qual a iteração entre os objetos em cada caso de uso, para responder essa
questão é elaborado diagrama de sequência;
48
 como serão manipulados os aspectos de controle, para responder essa
questão é elaborado diagrama de estado;
 como na prática será construído o sistema, para responder essa questão é
elaborado o diagrama de classe de baixo nível.
Em concordância com (BORILLO, 2000, apud BONA, 2002, p. 61), pode-se
destacar três características fundamentais que a metodologia ICONIX apresenta:
 iterativo
e
incremental:
diversas
iterações
no
momento
do
desenvolvimento do diagrama de domínio e identificação do diagrama de
casos de uso;
 rastreabilidade (traceability): todos requisitos são referenciados de alguma
forma, dentro dos diagramas,identificando o impacto da alteração de um
requisito em todos os artefatos;
 metodologia UML: a metodologia oferece os diagramas de casos de uso,
sequência e colaboração e robustez.
A seguir,serão apresentado as quatro tarefas/etapas principais da modelagem
ICONIX. (ROSENBERG & SCOOT, 1999, apud BONA, 2002, p. 62)
4.1.1
Análise de requisitos
Pode-se visualizar, na figura 15, a seguir, as tarefas que compõem a análise de
requisitos, que são:
Figura 15 – Análise de requisitos - ICONIX
Fonte: Bona(2002, p. 62).
49
 modelo de domínio: responsável por identificar os objetos, relação de
agregação e relação de generalização, entre eles;
 protótipo: apresentar, se possível, os protótipos de telas de forma rápida,
para que seja identificado o modo de navegação entre telas, para que seja
possível a maior compreensão do sistema;
 casos de uso: apresentar os atores que terão ligação com os casos de uso
do sistema;
 pacote: agrupar os casos de uso;
 associação requisitos: associar requisitos funcionais aos casos de uso e aos
objetos de casos de uso, promovendo uma interação entre os diagramas
anteriores. (BONA, 2002, p. 62).
4.1.2
Análise de projeto preliminar
Na figura 16, a seguir, podem-se identificar tarefas que fazem parte da análise de
projeto preliminar, que são:
Figura 16 – Análise de projeto preliminar
Fonte: Bona (2002, p. 63).
 modelo caso de uso: apresentar os fluxos principais, fluxos alternativos
e/ou fluxos de exceções dos casos de uso;
 análise de robustez: apresentar um conjunto de objetos para cada caso de
uso;
50
 diagrama de classe: atualizar o diagrama de classe criado na etapa anterior.
(BONA, 2002, p. 63).
4.1.3
Projeto
Na figura 17, a seguir, podem-se observar as atividades eminentes à etapa de
projeto. (BONA, 2002, p. 64), que são:
Figura 17 – Revisão detalhada do projeto
Fonte: Bona (2002, p. 64)
 diagrama de sequência: responsável por identificar comportamentos do diagrama de casos
de uso, assim como as mensagens entre os objetos;
 diagrama de classe: atualizar o diagrama de classe adicionando o modelo estático;
 analisar e verificar se o projeto atende a solução proposta.(BONA, 2002, p. 64)
4.1.4
Implementação
Na afirmação de Bona (2002, p. 64):
As atividades que dão suporte a tarefa de implementação são:
utilizar diagrama de componente, se for necessário para apoiar a fase de
desenvolvimento;
escrever/gerar o código;
realizar testes de unidade e de integração;
realizar testes de aceitação do usuário.
51
A seguir, será realizada a modelagem e desenvolvimento da solução, com base na
metodologia ICONIX, apresentada na sessão anterior.
4.2
PROTÓTIPO DA SOLUÇÃO
Nesta sessão será desenvolvido o protótipo da solução propostas, utilizando a
metodologia ICONIX, entretanto, não serão apresentados os diagramas de classes e
prototipação de telas, por não se tratar de modelagem orientada a objetos.
4.2.1
Levantamento de requisitos
Seguindo a metodologia ICONIX, foram encontrados os seguintes requisitos
funcionais para a arquitetura de BI abordada:
RF001 - A arquitetura de BI deve conter um banco de dados relacional
Descrição: para elaborar a arquitetura de BI será necessário um banco de dados
relacional, com dados normalizados.
RF002 - A arquitetura de BI deve ter possibilidadede realizar carga, extração
e transformação de dados com uma ferramenta ETL
Descrição: para enviar os dados do banco relacional para Data Warehouse, será
necessário ferramenta ETL, que fará a extração, transformação e carga dos dados.
RF003 - A arquitetura de BI deve conter um Data Warehouse DW
Descrição: o DW terá, como principal função, a visualização dos dados e a
facilitação em consultas.
RF004 - A arquitetura de BI deve ter a possibilidade de realizar análise de
dados com uma ferramenta front-end– OLAP
Descrição: a análise realizada no data warehouse será feita por ferramenta OLAP.
RF005 - A arquitetura de BI deve apresentar dados da performance entre
equipes e entre pessoas referente ao total de tempo estimado e total de tempo realizado
52
Descrição: a ferramenta OLAP deverá apresentar, em um relatório, os dados de
performance entre equipes e entre pessoas, referente ao total de tempo estimado e total de
tempo realizado.
RF006 - A arquitetura de BI deve apresentar dados dos projetos realizados,
com o tempo total estimado e tempo total realizado
Descrição: a ferramenta OLAP deverá apresentar, em um relatório, os dados dos
projetos realizados, com tempo total estimado e tempo total realizado.
RF007 - A arquitetura de BI deve apresentar os dados divididos em dia, mês,
ano e semana
Descrição: a ferramenta OLAP deverá apresentar, em um relatório,os dados
divididos em dia, mês, ano e semana.
RF008 - A arquitetura de BI deve apresentar os projetos que tiveram o
tempo total realizado próximo ao tempo total estimado
Descrição: a ferramenta OLAP deverá apresentar, em um relatório, os dados de
projetos que tiveram tempo total realizado próximo ao tempo total estimado.
RF009 - A arquitetura de BI deve apresentar as pessoas que participaram
dos projetos e tiveram o tempo total estimado próximo ao tempo total realizado
Descrição: a ferramenta OLAP deverá apresentar, em um relatório, os dados de
pessoas que participaram dos projetos e tiveram o tempo total estimado próximo ao tempo
total realizado.
A seguir, pode-se identificar a figura 18 com os requisitos funcionais levantados.
53
Figura 18 – Requisitos funcionais
Fonte: O autor.
4.2.2
Casos de uso
A seguir,são apresentados os casos de uso elaborado pelo autor para arquitetura de
BI.
54
Figura 19 – Casos de uso
Fonte: O autor.
A seguir, é apresentadaa definição dos atores envolvidos nos casos de uso da
arquitetura de BI:
Tabela 1 – Definição de atores
Ator
Definição
Administrador
- responsável por fazer a extração, transformação e
carga dos dados;
- para esse ator são definidos apenas tarefas técnicas,
e não exerce nenhuma análise sobre os dados.
Analista de negócio
- responsável por realizar análise dos dados já dentro
do data warehouse, com auxílio de ferramenta
OLAP;
- para esse ator são definidas tarefas de análise do
negócio, portanto, não realiza ajustes técnicos na
arquitetura de BI.
Fonte: O autor.
55
Na próxima tabela, são apresentados os casos de usos principais que compõem a
arquitetura de BI, a eles, em especial, seus fluxos.
Tabela 2 – UCE001 – Importar dados com ferramenta ETL
UCE001 - Importar dados com ferramenta ETL
Nome
Importar dados com ferramenta ETL
Identificador
UCE001
O administrador extrai, transforma e carrega os dados no
Descrição
data warehouse
Ator primário
Administrador
Pré-condição
Existir banco de dados relacional
1 - administrador seleciona fonte de dados que deverá ser
importada;
Fluxo principal
2 - administrador efetua limpeza de dados;
3 - administrador efetua carga de dados no DW.
Fluxo alternativo
Não
Os dados do banco de dados relacional são carregados do
Pós-condição
DW
Regras de negócio
Não
Fonte: O autor.
Tabela 3 – UCE003 – Criar data warehouse
UCE002 - Criar Data Warehouse - DW
Nome
Criar Data Warehouse - DW
Identificador
UCE002
Descrição
O administrador cria o data warehouse
Ator primário
Administrador
Pré-condição
Existir banco de dados relacional
1 - administrador identifica no modelo relacional campos e
Fluxo principal
tabelas necessárias para utilizar no DW;
2 - administrador cria as tabelas do DW.
Fluxo alternativo
Não
Pós-condição
Regras de negócio
O DW é criado
Não
Fonte: O autor.
Tabela 4 - UCE003 - Analisar dados comFerramenta OLAP
UCE003 - Analisar dados comFerramenta OLAP
Nome
Analisar dados comFerramenta OLAP
Identificador
UCE003
Descrição
O analista de negócio analisa os dados do DW
Ator primário
Analista de negócio
Pré-condição
Existir banco de dados relacional
1 - Analista de negócio conecta ferramenta OLAP no data
Fluxo principal
warehouse;
2 - Analista de negócio criar as tabelas do DW.
Fluxo alternativo
Não
Pós-condição
Os dados são analisados com ferramentas OLAP
56
Regras de negócio
Não
Fonte: O autor.
4.2.3
Diagrama de robustez
A seguir, é apresentado o diagrama de robustez da arquitetura de BI.
Figura 20 – Diagrama de robustez
Fonte: O autor.
57
4.2.4
Diagrama de sequência
Nesta sessão, é apresentado o digrama de sequência dos principais casos de uso da
arquitetura de BI.
Figura 21 – UCE001 – diagrama de sequência
Fonte: O autor.
58
Figura 22 – UCE002 – diagrama de sequência
Fonte: O autor.
Figura 23 - UCE003 - diagrama de sequência
Fonte: O autor.
59
4.3
CONSIDERAÇÕES FINAIS DA MODELAGEM
Através do conceito de ICONIX, foi permitido elaborar a modelagem para a
arquitetura de BI com base na problemática do trabalho. No próximo capítulo, será descrito
sobre o estudo de caso realizado na empresa desenvolvedora de software, assim como a
solução encontrada.
60
5
ESTUDO DE CASO EMPRESA DESENVOLVEDORA DE SOFTWARE
Neste capítulo, será abordado o estudo de caso da empresa desenvolvedora de
software, por tanto será apresentado uma possível solução encontrada de como montar a
arquitetura de BI para, assim, algumas análises.
A seguir, é apresentado o item sobre as ferramentas utilizadas para o
planejamento e desenvolvimento do trabalho.
5.1
FERRAMENTAS E TECNOLOGIA
As ferramentas utilizadas do pacote Microsoft Office® foram Microsoft Excel,
Microsoft Visio e Microsoft Word, essas ferramentas foram escolhidas por se tratar das
ferramentas que o autor utiliza diariamente, por isso tem experiência e familiaridade na
utilização. As ferramentas que merecem destaque do pacote Microsoft Office® são Microsoft
Excel, porque foi utilizado para verificar se a importação dos dados está correta com relação a
integridade dos dados e Microsoft Word que foi o local onde se armazenou a descrição do
texto referente ao trabalho. Além do pacote Microsoft Office®, foramutilizadas as
ferramentas BI Server, Data Integration (Spon), Schema Workbench eSaiku, que pertencem a
Pentaho Solutions®.Pode-se dar ênfase a ferrramenta Data Integration, local em que se
realizou-se a extração, transformação e carga referente aos dados coletados sobre os tíquetes
de desenvolvimento de software, assim, como a ferramenta Saiku, local em que foram
analisados os dados após sua extração, transformação e carga. Como banco de dados
relacional foi utilizado o MYSQL, banco de dados responsável por armazenar os dados sem
tratamento dos tíquetes que a empresa forneceu para a extração dos dados. Para o DW foi
utilizado o banco de dados PostgreSQL, banco de dados em que foi realizada a carga dos
dados tratados. A utilização do PostgreSQL sucedeu-se por se tratar do banco de dados em
que o autor tem familiaridade e utiliza nos seus trabalhos acadêmicos. Foi utilizada a
linguagem SQL (Structured Query Language), linguagem para realizar consultas de análise
dos dados, utilizadas nos bancos de dados MYSQL e PostgreSQL.
61
O quadro, a seguir, apresenta as tecnologias utilizadas, que o autor utilizou por
apresentar domínio sobre as tecnologias.
Tabela 5 – Tecnologias utilizadas
Ferramentas
Uso
DB Designer Fork
Modelagem do Data Warehouse
Pentaho Data
Integration
Exportação e importação de dados, assim como
apresentação em relatório.
Enterprise Architect Modelagem casos de uso, robustez e sequência.
Excel
Auxiliar na validação de importação e exportação
Banco de dados
MYSQL
Local em que se encontra os dados no modelo relacional
Banco de dados
Postgre
Local em que se encontra o DW
SQL
Linguagem utilizada para realizar consultas no banco de
dados
62
Saiku analitycal
Visio
Ferramenta para analisar dados através de relatório. Plugin
do Data Integration Pentaho.
Ferramenta utilizada na modelagem da solução do
problema.
Windows 7
Sistema operacional que roda todas as aplicações
utilizadas.
Word
Ferramenta para realizar edição de textos.
Fonte: O autor
5.2
APRESENTAÇÃO DA ARQUITETURA DE BI
Nas sessões, a seguir, será apresentada a arquitetura de BI, back-end e front-end,
ou seja, back-end, as tarefas realizadas para construção do BI, extração de dados do modelo
banco de dados relacional, transformação dos dados e importação dos dados no DW, assim
como a construção do cubo de dados para análises.Para front-end, são realizadas as tarefas de
análise de dados através de relatórios. (KIMBALL, 2002).
63
5.2.1
A empresa
A empresa XXX, atualmente, produz soluções de telefonias e softwares para
contact centers com sede na cidade de Florianópolis – Santa Catarina.
Com aumento da demanda por suas soluções, a empresa XXX começou a ter
problemas com relação ao processo de desenvolvimento, com isso,a empresamanifestou
interesse em analisar os processos internos de desenvolvimento de software e telefonia para
encontrar os pontos de melhora no processo de produção.
O controle no processo de desenvolvimento, atualmente, é realizado através do
software gerenciador de demandas, que, transformada cada tarefa em tíquetes, ou seja,
independentemente do tipo da demanda, é aberto um tíquete que contém descrito a
necessidade do cliente para incluir no software.
Com isso, foi elaborado uma possível solução de análise de dados,
utilizandotécnicas de BI descrita no segundo capítulo, em que são apresentados a seguir.
5.2.2
Arquitetura de BI: back-end
Para ilustrar a montagem da arquitetura back-ende front-end,assim como suas
etapas, foi elaborado pelo autor uma imagem que representa as etapas para construção da
arquitetura de BI, assim como, ossoftwares utilizados para cada passo. Na próxima figura, é
exibido dois atores que serão representados por o autor que executou todos os passos.
64
Figura 24 - etapas back-end
Fonte: O autor.
A primeira tarefa, para realização da montagem da arquitetura de BI, foi extrair os
dados do sistema de gerenciamento de demandas da qual a empresa faz uso.
Com tudo, as etapas são, realizar a criação do modelo dimensional de acordo com
os requisitos coletados, com DB Designer. Executar consultas no banco de dados relacional
MYSQL, para recuperar os dados necessários utilizados na ferramentaPentaho Data
Integration. Com essas consultas montadas, o próximo passo é transformar os dados
extraídos, para realizar a carga de dados no DW. Com esses passos concluídos, a próxima
tarefa é criar o cubo de dados, com a ferramenta Pentaho Workbench, e validar os dados
extraindo-os em planilhas de Excel.
Com todas as tarefas de back-endrealizadas, exercida pelo papel do administrador,
as tarefas seguintes são exercidas pelo papel do analista, que com auxílio do sistema
operacional Windows 7, e a ferramenta Pentaho Saiku, são montados gráficos que exibem as
análises geradas. Após realizado as tarefas de back-end e front-end, é realizado a
documentação do processo de criação da arquitetura de BI, nas ferramentas Word e Visio, do
fabricante Microsoft®.
65
A seguir, o modelo de entidade relacionamento referente a esse software,extraído
do banco de dados.
Figura 25 – Modelo entidade relacionamento
Fonte: O autor.
66
A tabela ISSUES representa as demandas criadas no software, contudo ela
armazena dados como data de criação (created_on), status do tíquete (status), número do
tíquete (id), projeto pertencente (project_id), categoria do tíquete (category_id) e prioridade
(priority_id). Na tabela USERS, fica armazenado o usuário responsável por criar o tíquete
relacionando com a tabela ISSUES através do campo assigned_to_id. A tabela que armazena
informações do status do tíquete é ISSUE_STATUSES, que se relaciona a tabela ISSUES
através do status_id. A tabela PROJECTS se relaciona à tabela ISSUES através do
project_id.Nessa tabela,são armazenados os projetos existentes na empresa. A tabela
TIME_ENTRIES é utilizada para armazenar o tempo do tíquete, ou seja, para cada
intervenção do usuário no tíquete, é mencionado o tempo corrente.Esses dados são
armazenados nessa tabela juntamente com o id da tabela ISSUES. Na tabela
CUSTOM_VALUES são armazenados dados do tempo estimado de cada tíquete, ou seja,
pode-se ter uma demanda estimada pela área de banco de dados da empresa em duas horas,
porém o tempo total utilizado é armazenado na tabela TIME_ENTRIES.Essa tabela armazena
o id da tabela ISSUES, para que seja encontrada o tempo de cada tíquete estimado. Por
último, tem-se a tabela ISSUE_CATEGORIES, referente à categoria do tíquete, ou seja, pode
existir um registro na tabela ISSUES que armazena a categoria, como, exemplo, banco de
dados.
Após realizado a caracterização das tabelas utilizadas para extrair dados, é
iniciado a transformação dos dados. A seguir, é apresentado o Data Warehouse, responsável
por armazenar os dados transformados. O conceito de DW está descrito, no segundo capítulo,
assim, como os conceitos para criação dos modelos dimensionais e também conceitos de
criação da tabela fato.
67
Figura 26 - Modelo DW
Fonte: O autor.
Para criação do DW, foi utilizado o software DB Designer, descrito na sessão
anterior para modelagem dimensional.
A tabela DI_TEMPO são armazenados dados de datas existentes na criação dos
tíquetes, ou seja, são recuperados os valores de data de abertura do tíquete presentes no
modelo relacional tabela ISSUES campo created_on.Esse campo foi divido em dia, mês, ano
e semana, para que seja visualizado no relatório. Na tabela DI_PROJETO são armazenados os
nomes dos projetos.Esses nomes são encontrados no modelo relacional, tabela PROJECTS,
no campo name. Na tabela DI_TICKET são armazenados os números de cada tíquete, ou seja,
esse campo é preenchido de acordo com a tabela ISSUES, campo id do modelo relacional. Na
tabela DI_CATEGORIA são armazenados os nomes das categorias existentes, na tabela
ISSUE_CATEGORIES campo name, encontrada no modelo relacional. Na tabela
DI_STATUS
são
armazenados
os
nomes
de
cada
status
referente
a
tabela
ISSUE_STATUSES encontrada no modelo relacional, no campo name. Natabela
DI_RESPONSAVEL_AREA são armazenados os nomes e áreas dos responsáveispela
criaçãodo tíquete, referente a tabela USERS campo name do modelo relacional, em que no
68
mesmo campo foi extraído a área do responsável e nome. Na tabela fato FT_TICKETS,
foramreunidas as medidas de tempo total realizado, tempo total estimado, se pertence a
release e prioridade de abertura. As informações extraídas das tabelas CUSTOM_VALUES
são para cálculos de horas estimadas e para verificar se o tíquete pertence à release, ou não. O
tempo total realizado é obtido através da soma das horas realizadas, da tabela
TIME_ENTRIES. Por fim, a prioridade é calculada com base no campo PRIORITY_ID da
tabela ISSUES.
Para criação do modelo dimensional no banco de dados Postgre, exibido na figura
25, foram utilizados scripts SQL na opção de exportar para criação de script SQL, na
ferramenta DB Designer, que com o modelo dimensional concluído realiza a criação do
arquivo com os comandos na linguagem SQL, para ser executado no banco de dados Postgre.
Após a criação do DW, o próximo passo é efetuar a transformação e a carga de
dados. Com isso, a seguir, será apresentada a extração de dados realizada na ferramenta
Pentaho Kettle ®.
Na carga realizada, na tabela DI_CATEGORIA, foi necessário recuperar os dados
da tabela ISSUE_CATEGORIES no campo name, ordenando, em ordem alfabética, os
campos e gravando na tabela DI_CATEGORIA.
A seguir, a figura ilustra a carga da tabela DI_CATEGORIA na ferramenta
Pentaho Kettle.
69
Figura 27 - Carga de dados DI_CATEGORIA
Fonte: O autor.
A carga realizada, na tabela DI_PROJETO, foi com base na tabela PROJECTS,
selecionado o campo name, ou seja, o nome do projeto e, após, ordenando em ordem
alfabética.
A seguir, é apresentada a figura sobre a carga da tabela DI_PROJETO.
70
Figura 28 - Carga de dados DI_PROJETO
Fonte: O autor.
Na carga realizada, na tabela DI_RESPONSAVEL_AREA, é utilizado a tabela
USERS, obtendo os campos id e lastname, que tem o significado nome e área do usuário
cadastrado no banco de dados.
A seguir, é apresentada a figura sobre a carga de dados na tabela
DI_RESPONSAVEL_AREA.
71
Figura 29 - Carga de dados DI_RESPONSAVEL_AREA
Fonte: O autor.
Na
carga
realizada,
na
tabela
DI_STATUS,
é
utilizada
a
tabela
ISSUE_STATUSES, obtendo o campo name, após, ordenando-a e inserindo na tabela
DI_STATUS.
A seguir, é apresentadaa figura sobre a carga de dados na tabela DI_STATUS.
72
Figura 30 - Carga de dados DI_STATUS
Fonte: O autor.
A carga, realizada na tabela DI_TEMPO, foi obtida a partir da tabela ISSUES
com base no campo created_on, que representa a data de criação do tíquete. Para realizar a
carga e separar nos campos dia,mês,ano e semana, foi necessário utilizar as funções do banco
de dados MYSQL.Para extrair essas informações, foram utilizadas as funções year(), month(),
week() e Day(), ao qual extraí o ano, mês, semana e dia.
A seguir, é apresentada a figura sobre a carga de dados da tabela DI_TEMPO.
73
Figura 31 - Carga de dados DI_TEMPO
Fonte: O autor.
A carga de dados, da qual realizada na tabela DI_TICKET, foi obtida a partir da
tabela ISSUES com o campo id, foi realizada a extração e ordenação numérica crescente,
antes de carregar os dados na tabela DI_TICKET.
A seguir, é apresentada a figura da carga de dados da tabela DI_TICKET.
74
Figura 32 - Carga de dados DI_TICKET
Fonte: O autor.
A carga, realizada na tabela fato FT_TICKETS, foi obtida a partir das tabelas
DI_CATEGORIA, DI_PROJETO, DI_RESPONSAVEL_AREA, DI_STATUS, DI_TEMPO
e DI_TICKET e, também, as tabelas para calcular os campos mencionados anteriormente.
Após obter os campos das tabelas dimensão,são realizados agrupamentos dos dados com base
nas técnicas de ETL mencionada no segundo capítulo e carregado os dados.
A seguir, é apresentada a figura da carga de dados na tabela FT_TICKETS.
75
Figura 33 - Carga de dados FT_TICKETS
Fonte: O autor.
Após concluir a carga de dados no DW, foi realizada a montagem do cubo de
dados, seguindo os conceitos apresentados no capítulo dois, sobre OLAP.
O cubo de dados apresenta, a seguir, as dimensões de categoria, representado pela
tabela DI_CATEGORIA no DW, a dimensão de projeto representado pela tabela
DI_PROJETO no
DW,
a dimensão
responsável área,
representado
pela
tabela
DI_RESPONSAVEL_AREA no DW, dimensão status, representado pela tabela DI_STATUS
no DW, dimensão tempo, representado pela tabela DI_TEMPO no DW e dimensão ticket,
representado por a tabela DI_TICKET no DW. Assim, com as dimensões definidas, a tabela
fato FT_TICKET representa o assunto analisado. As medidas escolhidas, para analisar o
assunto, são tempo total realizado, tempo total estimado, pertence a release e prioridade do
tíquete.
A seguir, é apresentado o cubo OLAP, assim, como assunto, dimensões e medidas
analisadas.
76
Figura 34 - Cubo OLAP
Fonte: O autor.
Após realizada a apresentação da arquitetura de BI back-end, responsável por
estruturar o BI internamente, ou seja, implementação a baixo nível da lógica de negócio por o
ator administrador, conforme descrito no quarto capítulo, é iniciada a apresentação da
arquitetura de BI fron-end, parte reservada para análise dos dados obtidos com a arquitetura
de BI back-end. A segunda parte é referente às tarefas atribuídas ao analista de negócio,
conforme apresentado no capítulo quarto.
5.2.3
Arquitetura de BI: front-end
Após realizar a parte back-end da arquitetura de BI, é iniciada a próxima etapa de
análise de dados, que consiste em verificar o resultado obtido através de relatórios da
ferramenta Kettle Saiku.
A quantidade de registros no banco de dados relacional encontrada foi de 35.489
registros, ou seja, cada registro representa uma demanda aberta para resolução de alguma
necessidade do cliente ou da empresa, que se denomina de tíquete.
77
A quantidade de registros total presente no banco de dados relacional foi
importada das tabelas dimensão e fato, criadas do DW.
A partir da quantidade de registros de tíquete, é exibida, a seguir, a quantidade de
horas estimadas e quantidade de horas realizadas de cada projeto, conforme apresentado no
gráfico.
Figura 35 - Horas x projetos
Horas x projetos
60000
50000
40000
30000
20000
10000
Projeto de Londrina
Projeto YYY
Projeto SP
Projeto Tel
Projeto OK
Projeto NV
Projeto México
Projeto IM
Projeto KO
Projeto GO
Projeto EX
Projeto FI - Cliente
Projeto Contact - CLIENTE
Projeto Call
Tempo total realizado
Projeto Colombia - CLIENTE
Projeto BR
Projeto Argentina
Projeto AT - Cliente
Projeto 8
Projeto AD
Projeto - Sistemas Interno
Projeto - Gestão
Projeto - Primer CC
CLIENTE - Projeto AL
Projeto - Administrativo
0
Tempo total estimado
Fonte: O autor.
Como se pode identificar os projetos que concentram maior investimento de horas
são Projeto Colômbia – CLIENTE, Projeto - Sistemas Interno, Projeto – Gestão, Projeto AT –
Cliente e Projeto México, além disso, é identificado que o tempo estimado é menor em
relação ao tempo estimado em todos os projetos. No próximo gráfico, é identificado a mesma
tendência de tempo realizado menor que tempo estimado.
78
Figura 36 - horas x mês
Horas x mês
40.000,00
35.000,00
30.000,00
25.000,00
20.000,00
15.000,00
10.000,00
5.000,00
0,00
Tempo total realizado
Tempo total estimado
Fonte: O autor.
Nos meses de Fevereiro, Marçoe Novembro,pode-se identificar maior aumento
durante o ano em demandas em que são representados valores emtotal de horas por todos
funcionários da empresa. Além disso, é visível que a estimativa em todos os meses do ano
está abaixo da quantidade de horas realizadas. O período apresentado é de 5 anos atrás,
portanto esse somatório representa as horas referente aos últimos 5 anos agrupados por meses.
Figura 37 - Horas x semana
Horas x semana
18000
16000
14000
12000
10000
8000
6000
4000
2000
0
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53
Tempo total realizado
Fonte: O autor.
Tempo total estimado
79
No gráfico acima, é apresentada a quantidade de horas realizadas e quantidade de
horas estimadas, divididas por semanas do ano. Com isso, pode-se observar que, na sétima
semana do ano há um volume de horas realizadas maior que nas outras semanas, além de que
a quantidade de horas estimadas continua abaixo das horas realizadas.
Figura 38 - Horas x dia
Horas x dia
25000
20000
15000
10000
5000
0
1 2 3 4 5 6 7 8 9 10111213141516171819202122232425262728293031
Tempo total realizado
Tempo total estimado
Fonte: O autor.
Na figura acima,é apresentada a quantidade de horas realizadas, dividido por dia.
Com isso, pode-se compreender que se tem um tempo total realizado maior que tempo total
estimado. Observa-se também que, nos dias 2 e 8 tem maior número de horas realizadas, ou
seja, maior número de horas trabalhadas.
anteriores.
0
Tempo total realizado
Qualidade - Relatório/Consult
Qualidade - Avaliação
Projeto Metrics -…
Projeto Metrics - Ferramenta
Projeto 1
Otros
Infra - IPBX
Infra - Grabación
GP - Relatório / Consulta
GP - Modulo Gerencial WEB
DS - Relatório / Consulta
CRM - Validación / Auditoria
CRM - Relatório / Consulta
CRM - Manutenção
CRM - Mailing Strategy
CRM - Ferramenta Portal…
CRM - Exportación
CRM - Cadastros - WEB
CRM - Auditoria
CRM - Atendimento
Administrativo
80
Figura 39 - Horas x categoria
horas x categoria
70000
60000
50000
40000
30000
20000
10000
Tempo total estimado
Fonte: O autor.
Nesse gráfico exibido acima, pode-se identificar que os projetos que mais utilizam
horas são Outros, CRM – Atendimento e Projeto 1. A quantidade de horas estimadas continua
menor em comparação com horas realizadas.Essa tendência é apresentada nos gráficos
81
Figura 40 - Horas x área - equipe
Horas x área - equipe
80.000,00
70.000,00
60.000,00
50.000,00
40.000,00
30.000,00
20.000,00
10.000,00
0,00
Tempo total realizado
Tempo total estimado
Fonte: O autor.
Na figura acima, é apresentado o total de horas dividido pelas áreas da empresa.
Contudo, pode-se identificar concentração de horas na equipe de An. P, Areq (analista de
requisitos), Dir. S, Infra e S.D. Além disso, a quantidade de horas estimadas fica muito
próximo a zero. Isso acontece porque as horas estimadas, se visualizadas por área,são
menores em proporção as horas realizadas.
Após descrito sobre o tempo total estimado e tempo total realizado, dividido por
suas variáveis, são elaboradas análises com a variável tíquete.
82
Figura 41 - Tíquete x release
Tíquete x release
65,15
34,85
release
urgente
Fonte: O autor.
Na figura acima, pode-se visualizar a quantidade de tíquetes que são de release e
que não são, ou seja, os tíquetes que são de release são submetidos a um processo de
execução de tarefas em que é acordado o compromisso de entrega com cliente.Com isso, é
fechada uma quantidade de tarefas que serão realizadas e marcado data para entregar essas
tarefas. Os outros tíquetes que não são de release são urgentes, ou seja, tíquetes que
apresentam problemasou que não são planejados. Nessa visualização são apresentadas a
maioria dos tíquetes como planejados com release de 65,15% e 34,85 dos tíquetes não são
planejados de release, ou seja, são urgentes.
83
Figura 42 - Percentual de prioridade de tíquete
% prioridade de tíquete
60
50
40
30
20
10
Prioridade
5
34
37
40
43
46
124
127
130
133
136
185
188
191
194
197
200
203
206
209
212
215
218
221
224
227
0
% de tíquete
Fonte: O autor.
Nessa figura, é apresentado o percentual de tíquete com relação ao total com suas
prioridades, ou seja, cada tíquete é aberto com uma prioridade.Com isso, foi contado a
quantidade tíquetes com suas prioridades e gerado um percentual desse total, ou seja, gerado a
média ponderada e seguido de cálculo de percentual. Pode-se analisar que 51% dos tíquetes
são abertos com prioridade 46, e 25% dos tíquetes são abertos com prioridade 4.
Figura 43–Percentual de horas x pessoas
Horas x pessoas
Total de horas realizadas
Fonte: O autor.
Total de horas estimadas
84
No gráfico apresentado anteriormente, é visualizado a porcentagem de pessoas
que teve o total de horas realizadas maior que o total de horas estimadas, ou seja, todas as
pessoas que tiveram influência em tíquetes.
5.3
CONSIDERAÇÕES FINAIS DO CAPÍTULO
Neste estudo, foi possível perceber que os dados coletados não são ricos o
suficiente para apresentar dados de negociações, ou seja, valores em reais das demandas
realizadas em projetos. Contudo apresentam dados que pode ser relevante para análise de
mercado como uma empresa de pequeno porte.
A utilização do sistema por parte da empresa se intensificou nos últimos meses,
portanto, para realizar análisescom maior assertividade, é necessário acompanhamento a partir
desse estudo realizado, podendo assim encontrar padrões de comportamentos.
O banco de dados da empresa apresentou algumas inconsistências corrigidas antes
de realizar a carga de dados no DW. Essas inconsistências evidenciam a mudança do processo
de desenvolvimento de software, realizado ao longo dos anos na empresa em que o software
que armazena os dados, assim como, o banco de dados sofreu, ocasionando inconsistências
dos dados analisados.
Visando a melhorar o processo de desenvolvimento de software da organização
são sugeridos alguns pontos como adicionar risco dos projetos, ou seja, antes de iniciar o
desenvolvimento do projeto, adicionar o risco que o projeto corre, criando uma escala de
riscos.Adicionar lições aprendidas aos projetos, ou seja, as tarefas que foi concluída com
sucesso esperado e tarefas que não foram concluídas com sucesso esperado, no final resumir
como lições apreendidas.Adicionar o valor negociado no momento da criação do tíquete, ou
seja, colocar o valor negociado para desenvolver aquela demanda, com isso, irá ter
armazenado no histórico a valor negociado para cada tíquete.
No próximo capítulo, é detalhada a conclusão do trabalho e trabalhos futuros.
85
6
CONCLUSÕES E TRABALHOS FUTUROS
Nesse capítulo será exibido as conclusões sobre a pesquisa apresentada, assim
como a sugestão de trabalhofuturo.
6.1
CONCLUSÕES
Através da pesquisa bibliográfica realizada sobre o assunto de Business
Intelligencee técnicas de construção de arquitetura de BI, foi realizado a construção da
arquitetura de BI para analisar os dados da empresa desenvolvedora de software. Foi realizado
a construção do DW de acordo com as técnicas apresentadas no capítulo 2, e também de
acordo com os requisitos levantados, no capítulo três.
No presente estudo foi identificado como é realizado o processo de
desenvolvimento na empresa desenvolvedora de software, sendo assim, foi criado a
arquitetura de BI que pudesse apresentar informações recolhidas do processo de
desenvolvimento, e por fim foi apresentado por gráficos,as conclusões que apresentam
informações sobre o processo de desenvolvimento. Através dessas etapas foi atingido
osobjetivos iniciais do trabalho.
Para atingir os objetivos do trabalho foi estudadosobre a ferramentaKettle Data
Integration, que possui diversos recursos para extração, manipulação e apresentação de dados,
também foi estudado sobre o processo de desenvolvimento de software, que pode-se verificar
a situação abordada no trabalho a complexidade existente entre projetos e pessoas disponíveis
para executar as tarefas, ou seja, pessoasque executam tarefa, e prazos de entrega acordado
com clientes de demandas solicitadas ou iniciadas pela própria empresa.
Foram identificados alguns problemas para montar a arquitetura de BI, como,as
complexidades das tecnologias utilizadas e suas diferentes funcionalidades, o entendimento
do processo de desenvolvimento de software para realizar a criação da arquitetura de BI, e
inconsistências nos dados no banco de dados relacional, local que foi extraído os dados para
construção da arquitetura. E também analisar tudo o que foi produzido, apresentando dados de
acordo com os requisitos levantados.
86
Os dados apresentados após a análise por gráficos, são de extrema importância
para a empresa desenvolvedora de software, porque permite monitorar o processo de
desenvolvimento, e assim identificar se o processo de desenvolvimento possui alguma falha,
ou até mesmo se necessita de melhoria.
Com base nas afirmações acima, conclui-se que foram atingidos os objetivos
propostos no capítulo um.
A seguir, é apresentado a sugestão de trabalhos futuros que poderá ser
desenvolvido após a conclusão desse trabalho.
6.2
TRABALHOS FUTUROS
Buscando ampliar o escopo do trabalho realizado, sugere-se encontrar outra
empresa que possua o mesmo sistema de demandas utilizado por essa empresa
desenvolvedora de software, e efetuar cruzamento de dados, referente aos períodos em que foi
registrado aumento significativo de demandas, após esse cruzamento, avaliar se no mesmo
período que foi encontrado aumento das demandas existe similaridade entre as empresas.
Atualmente, a mesma empresa desenvolvedora de software, possui dados
armazenados em seu sistema de gerenciamento de colaboradores, com isso, pode-se realizar o
cruzamento de dados dos colaboradores da empresa com as demandas realizadas, e procurar
se existe algum relacionamento entre os colaboradores da empresa e demandas.
Poderá ser realizado a aplicação de algorítimos de mineração de dados, com base
nos dados analisados nesse trabalho, assim sendo, tendo como objetivo encontrar
conhecimento que até não foi encontrado nas análises com a ferramenta Saiuku.
87
APÊNDICE A – CRONOGRAMA
Atividade
1 -avaliação
Entrega obj.
2 - avaliação
Entrega Cap 1
3 - avaliação
Entrega Cap 2
4 - avaliação
Entrega Cap 3
5 - avaliação
Entrega Cap
1,2,3
6 - avaliação
Entrega Total
7 –Elaborar
Modelo
Dimensional
8 –Realizar
carga no
modelo
dimensional
9 –Analisar os
dados
carregados no
modelo
dimensional
10 –
Documentar
as tecnologias
utilizadas
11 –Realizar
as correções
no trabalho
caso
necessário
12 – entrega
da
monografia
empresa
Ago
Set
Out
Nov
Férias
Mar
Abr
Mai
Jun
Jul
88
REFERÊNCIAS
BARBIERI, Carlos. BI – Business Intelligence: Modelagem e Tecnologia. Rio de Janeiro,
Axcel Books, 2001.
BARBIERI, Carlos. BI2 – Business Intelligence: Modelagem e Qualidade. Rio de Janeiro,
Elsevier, 2011.
BONA, Cristina. Avaliação de processos de software: um estudo de caso em XP e Iconix.
2002.122 f. Dissertação (Pós-Graduação em Engenharia de Produção) - Universidade Federal
de Santa Catarina, Florianópolis, 2002.
GONÇALVES, Márcio. Extração de Dados para Data Warehouse. Rio de Janeiro, Axcel
Books, 2003.
INMON, W. R.Data Warehouse: Como transformar informações em oportunidade de
negócios. W. R. Inmon, R.H. Terdeman, Claudia Imhoff, São Paulo, Berkeley Brasil, 2001.
KIMBALL, R.. Data Warehouse toolkit: O guia completo para modelagem dimensional.
Rio de Janeiro, Editora Campus, 2002.
MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de Data Warehouse: uma visão
multidimensional. 5ª ed rev. São Paulo, Érica, 2011.
MARCONI, Marina de Andrade; LAKATOS, Eva Maria. Fundamentos da metodologia
científica. 7ª edição. São Paulo: Atlas, 2010.
MIGUEL, Paulo Augusto Cauchick. Estudo de Caso na engenharia de produção:
estruturação e recomendações para sua condução, em: Produção, v.17, n. 1, p. 216-229,
Jan/Abr. 2007.
MICROSOFT. Ajuda e instruções do Word 2003. Disponível em:
<http://office.microsoft.com/pt-br/word/default.aspx>. Acesso em: 20 Set. 2013.
OLIVEIRA, Silvio Luiz de. Tratado de Metodologia Científica: projetos de pesquisa, TGI,
TCC, monografias, dissertações e teses. 2ª edição. São Paulo: Pioneira Thomson Learning,
1999.
SERRA, Laércio. A essência do Business Intelligence. São Paulo, Berkeley do Brasil, 2002.
SILVA, Edna Lúcia da; MENEZES, Estera Muszkat. Metodologia da pesquisa e elaboração
de dissertação. 4ª Edição. Florianópolis: UFSC, 2005.
THOMSEN, Erik, OLAP: Construindo Sistemas de Informação Multidimensionais. 2ª ed.
Rio de Janeiro, Campus, 2002.
TURBAN, Efraim et al. Business Intelligence. 1. ed. Porto Alegre, Bookman, 2009.
89
UNIVERSIDADE DO SUL DE SANTA CATARINA. Pró-Reitoria Acadêmica. Programa de
Bibliotecas.Trabalhos acadêmicos na Unisul: apresentação gráfica para TCC, monografia,
dissertação e tese. Cristiane Salvan Machado et. al. (Org). 2. ed. rev. e ampl. Tubarão : Ed.
Unisul, 2008.