FACULDADE DE TECNOLOGIA DE SO JOS DOS CAMPOS

FELIPE GUSTAVO DE SOUSA ISSA

ESTUDO COMPARATIVO ENTRE BANCO DE DADOS

RELACIONAIS E BANCO DE DADOS NoSQL
NA UTILIZAO POR APLICAES DE BUSINESS INTELLIGENCE

SO JOS DOS CAMPOS

2011

FELIPE GUSTAVO DE SOUSA ISSA

ESTUDO COMPARATIVO ENTRE BANCO DE DADOS

RELACIONAIS E BANCO DE DADOS NoSQL
NA UTILIZAO POR APLICAES DE BUSINESS INTELLIGENCE
TRABALHO

DE

GRADUAO

APRESENTADO FACULDADE DE
TECNOLOGIA DE SO JOS DOS
CAMPOS,

COMO

PARTE

DOS

REQUISITOS NECESSRIOS PARA A

OBTENO

DO

TTULO

DE

TECNLOGO EM BANCO DE DADOS.

Orientador: Fernando Masanori Ashikaga

SO JOS DOS CAMPOS

2011

FELIPE GUSTAVO DE SOUSA ISSA

ESTUDO COMPARATIVO ENTRE BANCO DE DADOS

RELACIONAIS E BANCO DE DADOS NoSQL
NA UTILIZAO POR APLICAES DE BUSINESS INTELLIGENCE

TRABALHO

DE

GRADUAO

APRESENTADO FACULDADE DE
TECNOLOGIA DE SO JOS DOS
CAMPOS,

COMO

PARTE

DOS

REQUISITOS NECESSRIOS PARA A

OBTENO

DO

TTULO

DE

TECNLOGO EM BANCO DE DADOS.

________________________________________________________________
CARLOS AUGUSTO LOMBARDI GARCIA
________________________________________________________________
JULIANA FORIN PASQUINI MARTINEZ
________________________________________________________________
FERNANDO MASANORI ASHIKAGA

___/___/___
DATA DE APROVAO

O nico lugar aonde o xito chega antes do trabalho no dicionrio.

Vidal Sassoon

AGRADECIMENTOS
Agradeo a minha famlia, que sempre me apoiou nos momentos difceis, aos
professores, sempre dedicados sua misso de educar, e aos amigos e colegas de
curso, que estiveram comigo nos ltimos trs anos.

II
RESUMO

Bancos de dados so amplamente utilizados em diversas reas da sociedade. Eles

so parte essencial do controle do negcio de diversas empresas, pois elas possuem
grandes quantidades de dados financeiros e estratgicos sobre seus clientes e
colaboradores, e estes dados precisam ser gravados de alguma forma.
Conforme as empresas aderem informatizao, a quantidades de dados
armazenados tende a crescer, e com isso o desempenho das aplicaes de banco de
dados tende a cair. Existem novos modelos de bancos de dados, que foram criados com
o intuito de resolver estes problemas, e um desses novos modelos o NoSQL.
Este trabalho tem como objetivo fazer um estudo comparativo entre banco de dados
Relacionais e NoSQL, e identificar qual mais adequado para utilizao em uma
aplicao de BI (Business Inteligence).
Palavras Chave: banco de dados colunar, banco de dados relacional, estudo
comparativo, NoSQL.

III
ABSTRACT

Databases are largely used in several areas of the society. They are an essential part
of many companies, because they have a large amount of financial and strategic data
about their clients and employees, and this data need to be saved somehow.
As the companies goes into informatization, the amount of data they store grow up,
and the performance of the database applications tends to decrease. There are new
model of databases, that were created in order to solve this problems, and one of this
models is the NoSQL.
This paper has the objective of doing a comparative study between relational and
NoSQL databases, and to identify witch on is more suitable for a Business Intelligence
Aplication.
Keywords: column oriented databases, relational databases, comparative study,
NoSQL

IV
LISTA DE ABREVIATURAS E SIGLAS

ACID - Atomicidade, Consistncia, Isolamento e Durabilidade

API - Application Programming Interface (Interface de Programao de Aplicaes)
BI - Business Intelligence
DW - Data Warehouse
GPL - General Public License
SGDB - Sistema Gerenciador de Banco de Dados
MB - Megabyte
Modelo ER - Modelo Entidade Relacionamento
SQL - Structured Query Language (Linguagem de Consulta Estruturada)
TB - Terabyte
TI - Tecnologia da Informao
NoSQL Modelos de dados distintos do modelo relacional

V
NDICE DE FIGURAS

Figura 1 - Alguns dos principais SGDBs em uso ............................................................. 6

Figura 2 - A mesma informao armazenada em diversos arquivos ................................ 7
Figura 3 - Esquema do banco de dados de uma instituio bancria ............................ 12
Figura 4 - Um esquema normalizado ............................................................................. 13
Figura 5 - Tabelas que representam a tabela 3de forma normalizada ............................ 16
Figura 6 - Tabela Key/Value .......................................................................................... 19
Figura 7 - Um documento............................................................................................... 20
Figura 8 - Pentaho .......................................................................................................... 26
Figura 9 - Pentaho .......................................................................................................... 26
Figura 10 - Modelo dimensional do data warehouse...................................................... 31
Figura 11 - Comparativo do desempenho na primeira querie ........................................ 39
Figura 12 - Grfico comparativo do desempenho da segunda querie ............................ 40
Figura 13 - Grfico comparativo do desempenho na terceira querie ............................. 41
Figura 14 - Grfico comparativo do desempenho na quarta querie ............................... 42
Figura 15 - Comparativo do uso de memria na primeira querie................................... 46
Figura 16 - Comparativo do uso de memria na segunda querie ................................... 47
Figura 17 - Grfico comparativo do uso de memria na terceira querie ........................ 48
Figura 18 - Comparativo do uso de memria na quarta querie ...................................... 49
Figura 19 - Comparativo da alocao dos dados em disco ............................................ 50
Figura 20 - Anlise comparativa do desempenho com 1000MB de memria total ....... 52
Figura 21- Quantidade de memria livre durante a execuo dos testes com 1000MB de
memria total .................................................................................................................. 53
Figura 22 - Anlise comparativa do desempenho com 500MB de memria total ........ 54
Figura 23- Quantidade de memria livre durante a execuo dos testes com 500BM de
memria total .................................................................................................................. 55

VI
NDICE DE TABELAS

Tabela 1 - Tabela Relacional Alunos ............................................................................. 10

Tabela 2 - Tabela aluno com as linhas desordenadas ..................................................... 11
Tabela 3 - Tabela de livros no normalizada.................................................................. 15
Tabela 4 - Diferena entre sistemas operacionais e analticos ....................................... 25
Tabela 5 - Anlise comparativa do desempenho na primeira querie .............................. 38
Tabela 6 - Anlise comparativa do desempenho na segunda querie .............................. 39
Tabela 7 - Anlise comparativa do desempenho na terceira querie ............................... 41
Tabela 8 - Anlise comparativa do desempenho na quarta querie ................................. 42
Tabela 9 - Anlise comparativa do uso de cpu na primeira querie................................. 43
Tabela 10 - Anlise comparativa do uso de cpu na segunda querie ............................... 44
Tabela 11 Anlise comparativa do uso de cpu na terceira querie ............................... 44
Tabela 12 - Anlise comparativa do uso de cpu na quarta querie .................................. 45
Tabela 13 - Anlise comparativa do uso de memria na primeira querie ...................... 46
Tabela 14 - Anlise comparativa do uso de memria na segunda querie....................... 46
Tabela 15 Anlise comparativa do uso de memria na terceira querie ....................... 48
Tabela 16 - Anlise comparativa do uso de memria na quarta querie .......................... 49
Tabela 17 - Anlise comparativa da alocao em disco ................................................. 50
Tabela 18 - Anlise comparativa do desempenho com 1000MB de memoria total ....... 51
Tabela 19 Anlise comparativa da memria livra com 500MB de memria total ...... 52
Tabela 20 Anlise comparativa do desempenho com 500MB de memria total ........ 53
Tabela 21 Anlise comparativa da memria livre com 500mb de memria total ....... 54

VII
SUMRIO

Introduo ................................................................................................. 1
1.1

Motivao .......................................................................................................... 1

1.2

Problema ............................................................................................................ 2

1.3

Proposta de soluo ........................................................................................... 2

1.4

Organizao do Trabalho ................................................................................... 3

Reviso de literatura de banco de dados. .................................................. 4

2.1

Definio ............................................................................................................ 4

2.2

Aplicaes do sistema gerenciador de banco de dados ..................................... 5

2.3

Finalidade dos sistemas de banco de dados ....................................................... 6

2.4

Modelo de Dados ............................................................................................... 8

2.4.1

Modelo Relacional ...................................................................................... 8

2.4.2

Modelo de entidade / relacionamento ......................................................... 9

2.4.3

Modelo de dados orientado a objetos ......................................................... 9

2.5

Bancos de dados Relacionais ............................................................................. 9

2.5.1

Estrutura bsica......................................................................................... 10

2.5.2

Chaves ...................................................................................................... 11

2.5.3

Normalizao ............................................................................................ 12

2.5.4

ACID ........................................................................................................ 14

2.6

Banco de Dados Orientados a objetos ............................................................. 14

2.6.1
2.7

Banco de dados NoSQL ................................................................................... 17

2.7.1

Armazenamento Key/Value ..................................................................... 18

2.7.2

Armazenamento de documentos............................................................... 19

2.7.3

Armazenamento de grandes colunas ........................................................ 20

2.7.4

Bancos de dados Orientados a coluna ...................................................... 21

Business Intelligence .............................................................................. 22

3.1

Business Intelligence ....................................................................................... 22

3.2

Definio .......................................................................................................... 23

3.2.1
3.3
4

Tipos de dados complexos........................................................................ 15

Objetivos de uma aplicao de BI ............................................................ 24

Pentaho............................................................................................................. 25
Ferramentas Utilizadas............................................................................ 27

VIII
4.1

Mysql ............................................................................................................... 27

4.2

LucidDB........................................................................................................... 28

4.3

Apache JMeter ................................................................................................. 28

4.4

Monitor de Desempenho do Windows ............................................................ 28

4.5

Oracle Virtual Box ........................................................................................... 29

Proposta de soluo................................................................................. 30
5.1

Sistemas Gerenciadores de Banco de dados utilizados para estudo ................ 30

5.2

Definio da aplicao analisada ..................................................................... 30

5.2.1

Definio do modelo de dados ................................................................. 31

5.3

Definio do ambiente de teste ........................................................................ 32

5.4

Definio dos testes ......................................................................................... 32

5.5

Definio dos critrios analisados ................................................................... 33

5.5.1

Desempenho ............................................................................................. 33

5.5.2

Utilizao de CPU .................................................................................... 34

5.5.3

Uso de memria ........................................................................................ 34

5.5.4

Alocao das tabelas em disco ................................................................. 34

5.5.5

Desempenho utilizando menor quantidade memria RAM ..................... 34

5.6

Definio dos softwares utilizados .................................................................. 35

5.6.1

Apache JMeter .......................................................................................... 35

5.6.2

Monitor de desempenho do Windows ...................................................... 35

5.6.3

Oracle Virtual Box.................................................................................... 36

Resultados Encontrados .......................................................................... 37

6.1

Resultados Encontrados ................................................................................... 37

6.1.1

Anlise comparativa do desempenho ....................................................... 37

6.1.2

Anlise comparativa da utilizao de CPU .............................................. 43

6.1.3

Anlise comparativa da utilizao de memria ........................................ 45

6.1.4

Anlise comparativa da alocao das tabelas em disco ............................ 50

6.1.5

Desempenho utilizando menos memria RAM........................................ 51

Consideraes finais ............................................................................... 56

7.1

Contribuies e Concluses ............................................................................. 56

7.2

Trabalhos Futuros ............................................................................................ 57

Referencias Bibliogrficas ...................................................................... 58

Apndice ................................................................................................. 61
9.1

Apndice 1: Tabelas do modelo de dados ....................................................... 61

IX
9.2

Apendice 2: Scrips das buscas efetuadas nos bancos de dados ....................... 62

1
1

Introduo

1.1

Motivao

A utilizao de sistemas computadorizados aumentou consideravelmente a

quantidade de informao que as companhias possuem, dados estes que vo desde
informaes sobre seus clientes, como histrico de compras, pginas da web acessadas,
preferncias e dados da empresa, como controle de estoque, controle do sistema de
recursos humanos, financeiro e controle da produo (Leavitt, 2010).
Grandes empresas da rea de tecnologia da informao, como o caso da
Google, precisam lidar com enormes quantidades de dados diariamente. Estima-se que,
no ano de 2009, cerca de 20 Petabytes (1024 Terabytes, que podem ser utilizados para
armazenar 13.3 anos de contedo de vdeo de alta definio) de informao fossem
processados diariamente pela Google. Estimativas apontam que seria possvel
armazenar todo o conhecimento escrito da humanidade (a partir do incio da escrita, em
todas as lnguas) em 50 petabytes, e apenas uma empresa de tecnologia responsvel
pelo processamento de 2/5 desta quantidade de dados (HLIP, 2009).
O Ebay, empresa americana de comrcio eletrnico, possui um Data Warehouse
(DW) de 5 petabytes, que utilizado para armazenar dados sobre seus clientes, produtos
e as transaes realizadas em sua plataforma (Teradata, 2008).
Para armazenar esta grande quantidade de informao, necessrio um banco de
dados que alm de possuir grande capacidade de armazenamento, consiga desempenhar
suas funes sem perda de desempenho.
A rede de relacionamentos Twitter, onde os usurios se comunicam com
mensagens de at 140 caracteres, recentemente anunciou que ir migrar sua base de
dados de Mysql para o banco de dados Cassandra, um banco de dados NoSQL. Um dos
motivos que levaram a troca do banco de dados foi a dificuldade de administrar a base
de dados, que est em constante crescimento (Mynosql, 2010).
Para auxiliar a visualizao de todos estes dados, sistemas de Business
Intelligence (BI) analisam as informaes armazenadas e, utilizando-se de anlise
computadorizada, fornecem concluses desse processo de modo a facilitar a
compreenso humana, utilizando grficos e outras ferramentas de resultados interativos.

2
Os bancos de dados relacionais dominaram o mercado de armazenamento de
dados por muitos anos. Atravs das propriedades ACID (Atomicidade, Consistncia,
Isolamento, Durabilidade), que ser explicada adiante, oferecem um ambiente de
armazenamento favorvel a pequenas e mdias empresas. Com o crescimento da
quantidade de dados armazenados no banco, se faz necessrio distribuir a base de dados.
Os bancos relacionais no esto bem preparados para esta distribuio, e perdem
desempenho no tratamento de requisies do usurio. A rede social Facebook, por
exemplo, utiliza para o seu datawarehouse um banco que no relacional. O volume de
dados que esta aplicao gera diariamente de aproximadamente 15 Terabytes
(CPMBC, 2009; FHH, 2009).
Enquanto bancos de dados relacionais armazenam os dados linha por linha em
disco, um banco de dados colunar, por exemplo, armazena os dados por colunas,
fazendo com que apenas os dados necessrios sejam lidos, e no todos os dados no
banco (MT10AADW, 2010). O maior banco comercial existente, da Google, tambm
colunar, denominado Bigtable.

1.2

Problema

Identificar, entre a metodologia relacional e a colunar, qual mais adequada

para utilizao por uma aplicao de Business Inteligence (BI).

1.3

Proposta de soluo

Fazer um estudo comparativo entre banco de dados Relacionais e NoSQL, e

identificar qual mais adequado para utilizao em uma aplicao de BI.

3
1.4

Organizao do Trabalho

Este Trabalho est organizado da seguinte forma:

Captulo 2: Reviso de literatura de banco de dados
Captulo 3: Reviso de literatura de Business Intelligence
Captulo 4: Ferramentas utilizadas
Captulo 5: Proposta de soluo
Captulo 6: Resultados e concluses encontrados
Captulo 7: Consideraes finais
Captulo 8: Referncias bibliogrficas.

4
2

Reviso de literatura de banco de dados.

Este captulo apresentar a definio de banco de dados, seu funcionamento, os

modelos de armazenamento de dados, e apresentao dos principais modelos de bancos
de dados.
Este captulo est organizado como segue: A seo 2.1 define o conceito de
banco de dados, a seo 2.2 apresenta as aplicaes de um sistema gerenciador de banco
de dados, a seo 2.3 lista as finalidades do sistema de banco de dados, a seo 2.4
apresenta os modelos de dados. A seo 2.5 se destina a explicar os conceitos bsicos de
bancos de dados Relacionais, a seo 2.6 apresenta os banco de dados Orientados a
Objetos, e a seo 2.7 destina-se a introduzir os bancos de dados NoSQL.

2.1

Definio

Um banco de dados pode ser definido como uma coleo de dados que possuem
um relacionamento entre si. Para que este conjunto de dados seja considerado um banco
de dados, necessrio que algumas regras sejam observadas:

Ser um conjunto de dados com um significado no contexto. Uma

disposio desordenada de dados no pode ser considerada um banco de dados.

Sua finalidade o armazenamento de dados para um propsito

especfico. Deve possuir um conjunto pr definido de usurios e aplicaes.

Representa um aspecto do mundo real, tambm chamado de minimundo,

onde qualquer alterao no minimundo ir refletir nos dados armazenados no banco

(MACHADO, 2008).
Os sistemas de gerenciamento de banco de dados (SGBD) so projetados para
lidar com grandes quantidades de informaes. Dentre suas funes, se destacam a
definio de estruturas de armazenamento de dados, mecanismos de controle de acesso
aos dados, manipulao de informaes, compartilhamento de dados entre diversos
usurios e certificar que os dados se mantenham ntegros (SILBERSCHATZ, 2006).

5
2.2

Aplicaes do sistema gerenciador de banco de dados

Bancos de dados so amplamente utilizados em diversas reas da sociedade.

Seguem alguns exemplos de empresas e a finalidade para o qual o banco de dados
utilizado:
Linhas areas: reservas e informaes de horrios, armazenamento de

informaes sobre os vos, aeronaves, funcionrios, clientes e fornecedores. As

empresas areas foram umas das primeiras a utilizar banco de dados distribudos entre
vrias localidades;
Finanas: armazenar informaes sobre valores imobilirios, vendas e

compras de instrumentos financeiros (aes, ttulos, crditos, dvidas, etc). Tambm

para armazenar informaes de instituies bancrias, seus clientes e movimentaes de
suas contas;
Indstria: para gerenciamento de cadeia de suprimentos, controle da

produo em suas unidades, estoque de itens em armazns e lojas, alm de controle dos
setores de recursos humano e financeiro;
Transaes de carto de crdito: registrar e controlar compras com

cartes de crdito e gerao de faturas mensais.

Como mostra a listagem anterior, os bancos de dados so parte essencial do
controle do negcio de diversas empresas, motivo pelo qual as empresas fornecedoras
de sistemas de banco de dados esto entre as maiores empresas do mundo, como a
Oracle, que possui os bancos de dados Oracle e Mysql, e fazem parte da linha de
produtos

de

empresas

mais

diversificadas,

como

Microsoft

IBM

(SILBERSCHATZ, 2006).
A figura 1 mostra os principais sistemas gerenciadores de banco de dados
existentes atualmente.

FIGURA 1- ALGUNS DOS PRINCIPAIS SGDBS EM USO

2.3

Finalidade dos sistemas de banco de dados

Os sistemas de banco de dados surgiram como opo aos mtodos antigos de

gerenciamento de dados em computadores. Nos sistemas antigos, os dados eram
armazenados em arquivos do sistema operacional, que era responsvel por criar um
ambiente para acesso, manipulao e controle destes arquivos.
Para cada interao que fosse efetuada entre o sistema e o arquivo era necessrio
executar um programa especfico do sistema operacional que fornecia aquela funo.
Conforme funcionalidades eram adicionadas ao banco de dados (novas regras de
negcio), a criao de novos programas era necessria para lidar com estas requisies
(SILBERSCHATZ, 2006).
O armazenamento de informaes em um sistema de arquivos apresenta diversas
desvantagens, dentre as quais se destacam:

Redundncia e inconsistncia de dados: como a manuteno do sistema

efetuada por diversos programadores, cada um utiliza uma metodologia e,

conseqentemente, os vrios arquivos onde os dados so armazenados possuem
estruturas diferentes. Alm disso, a mesma informao pode estar armazenada em mais
de um arquivo, como mostra a figura 2, onde a informao do produto fica armazenada
no arquivo do sistema de produo, no sistema de vendas e no sistema de compras. Essa
redundncia de dados pode levar a divergncia, visto que no h nenhum mecanismo
que controle se ambos os registros possuem o mesmo valor, alm do custo de
armazenamento que esta informao duplicada possui.

FIGURA 2 - A MESMA INFORMAO ARMAZENADA EM DIVERSOS ARQUIVOS

Dificuldade de acesso a dados: ambientes de armazenamento de arquivos

no foram criados para executar tarefas de banco de dados, como extrao de uma
determinada informao de um determinado arquivo. Para cada necessidade de consulta
ao sistema de dados necessrio que o programador escreva uma aplicao para efetuar
esta busca, o que torna a recuperao de dados uma tarefa difcil.

Problemas de integridade: os valores armazenados no banco de dados

devem ser condizentes com a regra de negcio do cliente. Por exemplo, em uma
aplicao que controla as vendas de uma loja, a quantidade vendida de um item e o
saldo deste item no podem assumir valores negativos. Para que esta condio seja
cumprida, necessrio que um cdigo de verificao seja includo na aplicao. Porm,
quando novas regras de negcios so adicionadas, difcil mudar os programas para
implement-las, principalmente se as novas regras envolvem itens que possuem regras
distintas das j existentes (SILBERSCHATZ, 2006).

Anomalias no acesso concorrente: para favorecer o desempenho das

aplicaes, os sistemas de banco de dados devem oferecer acesso concorrente aos dados
armazenados. Porm, com esta funcionalidade, possvel que a interao das aes
concorrentes levem os dados a um estado de inconsistncia. Considere uma aplicao
bancria. Ao checar o saldo, a aplicao verifica que o saldo atual R$100,00. Quase
simultaneamente, duas operaes de cobrana so efetuadas nesta conta, sendo a

8
primeira cobrana no valor de R$80,00 e a segunda de R$50,00. Considerando que a
operao de cobrana consiste em checar o saldo, diminuir o valor cobrado e salvar o
novo saldo da conta, a execuo das operaes ir deixar o registro com um valor
inconsistente (R$20,00 ou R$50,00 de saldo, dependendo de qual terminar sua execuo
por ltimo).

Problemas de atomicidade: Os sistemas de computadores esto sujeitos a

falhas, como qualquer outro dispositivo. Considere um programa bancrio que efetue a
transferncia de R$100,00 de uma conta A para uma conta B. Se ocorrer uma falha
durante este procedimento, possvel que o valor transferido fosse retirado da conta A,
porm no creditado na conta B. Os sistemas de banco de dados devem ser capazes de
oferecer operaes atmicas, isto , deve ocorrer em sua totalidade ou no ocorrer.
difcil garantir a atomicidade de operaes em um sistema de arquivos.
Estas e outras dificuldades impulsionaram o desenvolvimento de sistemas de
banco de dados, para resolver as dificuldades anteriormente citadas e oferecer o
ambiente ideal para armazenamento de dados (SILBERSCHATZ, 2006).

2.4

Modelo de Dados

O modelo de dados de um Banco de dados a forma de descrever os dados, seus

relacionamentos, sua semntica e restries de consistncia. O modelo de dados
descreve o projeto do banco nas formas fsica, lgica e de view (SILBERSCHATZ,
2006).

2.4.1 Modelo Relacional

Este modelo utiliza tabelas para representar os dados e os relacionamentos

existentes entre as vrias instncias destas tabelas. Cada tabela possui diversas colunas,
que so os atributos desta entidade que sero armazenados.
O modelo de dados relacional o modelo de dados mais utilizado, e a grande
maioria dos SGDBs atuais baseada no modelo relacional (SILBERSCHATZ, 2006).

9
2.4.2 Modelo de entidade / relacionamento

Este modelo baseado na filosofia de que o banco de dados baseado em uma

percepo do mundo real, que formado por vrios objetos bsicos, as entidades, e os
relacionamentos existentes entre estas entidades (SILBERSCHATZ, 2006).
Cada alterao nos atributos deste objeto no mundo real ir ocasionar em uma
alterao nos dados armazenados no banco de dados, pois o dado armazenado a
representao, em bits, daquele objeto, e deve sempre possuir os dados mais atualizados
(MACHADO, 2008).

2.4.3 Modelo de dados orientado a objetos

Este modelo pode ser visto como um modelo ER (Entidade / Relacionamento)

mais avanado. Ele adiciona ao modelo ER as funes de encapsulamento, mtodos
(funes) e identidade de objeto (SILBERSCHATZ, 2006).

2.5

Bancos de dados Relacionais

Os bancos de dados relacionais utilizam a metodologia de prover um meio de

descrever o dado apenas com sua estrutura natural, isto , sem impor estruturas
adicionais com propsitos de otimizao computacional. Outra vantagem desta
abordagem a boa fundamentao em consistncia de relacionamentos e redundncia
de dados (CODD, 1970).

10
2.5.1 Estrutura bsica

Um banco de dados relacional formado por vrias tabelas, cada uma com um
nome nico atribudo. Considere a tabela Alunos (tabela 1). Ela possui 4 cabealhos de
coluna: Matrcula, Nome aluno, Curso e Telefone. Segundo a normatizao do modelo
relacional, chamaremos estes cabealhos de atributos. Para cada atributo, h um
conjunto de valores que so permitidos de serem armazenados nesta coluna. Este
conjunto chamado de domnio desse atributo.
Para o atributo Nome Aluno, por exemplo, o domnio do atributo o conjunto de
todos os alunos que fazem parte da instituio que registra seus alunos nesta tabela, j
para o atributo Matrcula, o domnio do campo o nmero de registro deste aluno na
instituio, o atributo Curso possui como domnio os nomes dos cursos que a instituio
ministra e, para o atributo, Telefone o domnio o conjunto de valores que representa o
telefone da residncia dos alunos desta instituio. Qualquer linha desta tabela precisa
consistir em um conjunto de 4 elementos (a1, a2, a3 e a4), onde a1 a Matrcula (e est
no domnio D1), a2 o Nome do aluno (e est no domnio D2), a3 o nome do curso
(domnio d3) e a4 o nmero do telefone (que est no domnio D4) da entidade
representada.

Portanto, todo registro de alunos conter apenas subconjuntos dos

conjuntos possveis para cada atributo da tabela. Portanto, conta um subconjunto de:
D1 x D2 x D3 x D4
Em geral, uma tabela de N atributos um subconjunto de:
D1 x D2 x ... x Dn-1 x Dn
Matrcula

Nome do Aluno

Curso

Telefone

312412

Joo da Silva

Letras

3531-1345

312413

Maria de Sousa

Fsica

3412-5312

312414

Rita de Cssio

Matemtica

1324-1224

312415

Jos dos Santos

Fsica

6124-8972

312416

Paulo Nascimento

Computao

3551-6377

TABELA 1 - TABELA RELACIONAL ALUNOS

A disposio das linhas em uma tabela irrelevante, pois uma tabela um

conjunto de registros. Portanto, quer os registros estejam listados em ordem, como na
tabela 1, ou estejam desordenadas, como na tabela 2, ambas as tabelas so idnticas,
visto que possuem os mesmos registros.

11
Matrcula

Nome do Aluno

Curso

Telefone

312413

Maria de Sousa

Fsica

3412-5312

312414

Rita de Cssio

Matemtica

1324-1224

312416

Paulo Nascimento

Computao

3551-6377

312415

Jos dos Santos

Fsica

6124-8972

312412

Joo da Silva

Letras

3531-1345

TABELA 2 - TABELA ALUNO COM AS LINHAS DESORDENADAS

exigido que, para todos os registros da tabela, os domnios dos atributos sejam
atmicos. Para que um domnio seja considerado atmico ele deve ser formado apenas
por elementos indivisveis. Por exemplo, o conjunto dos nmeros inteiros um domnio
atmico, porm o conjunto de todos os conjuntos de nmeros inteiros no atmico,
pois o subconjunto composto por diversos nmeros inteiros. Esta exigncia
necessria pois, apesar de Nome do Aluno e Curso serem ambos armazenados como
conjunto de caracteres no esquema fsico (armazenamento em arquivo), no nvel lgico
(onde so representadas as tabelas) a lgica do negcio impe que o Nome do Aluno e o
nome do curso sejam de conjuntos distintos (SILBERSCHATZ, 2006).

2.5.2 Chaves

preciso ter um modo de identificar como as linhas dentro de uma tabela so

identificadas e distinguidas umas das outras. Essa identificao feita utilizando seus
atributos, ou seja, os valores de um registro precisam ser criados de modo que possam
identificar unicamente aquela linha da tabela. Em outras palavras, nenhuma linha em
uma tabela pode ter todos os valores para todos seus atributos.
O termo chave primria utilizado para identificar o atributo que foi escolhido
pelo projetista do banco de dados para identificar unicamente os registros que so
armazenados em uma determinada tabela. Uma chave propriedade de toda a tabela, e
no de um registro em especfico. Nenhum registro pode ter o mesmo valor no atributo
chave primria de uma determinada tabela do banco de dados.
Os atributos chaves devem ser selecionados com cuidado. O nome de uma
pessoa nunca deve ser utilizado como atributo chave, pois podem existir mais de uma
pessoa que possui aquele nome. Os identificadores nicos devem nunca ou raramente

12
mudar, o que torna o endereo de uma pessoa uma m escolha de atributo chave,
diferentemente dos identificadores normalmente gerados pelas empresas para identificar
os registros, que dificilmente sero alterados.
Um esquema de tabela t1 pode ter entre seus atributos a chave primria de outra
tabela, digamos t2. Este atributo chamado de chave estrangeira de t1, referenciando t2.
Por exemplo, no esquema da Figura 3, o atributo nome_agncia na tabela conta uma
chave estrangeira desta tabela, que referencia a outra tabela do esquema, a agncia. Em
qualquer conjunto de registros do banco de dados, para cada linha existente na tabela
conta, necessrio que nome_agencia possua uma referncia a um registro vlido da
tabela agncia (SILBERSCHATZ, 2006).
Na figura 3, representado um esquema de uma instituio bancria. As chaves
primrias de cada entidade so apresentadas antes dos outros atributos, na caixa cinza.

FIGURA 3 - ESQUEMA DO BANCO DE DADOS

DE UMA INSTITUIO BANCRIA (SILBERSCHATZ,2006)

2.5.3 Normalizao

Um mtodo que deve ser considerado ao planejar um banco de dados relacional

um processo conhecido como normalizao. Ele tem por objetivo gerar um esquema
de tabelas que permita armazenar informaes sem redundncia desnecessria, ao
mesmo tempo permitindo recuperar informaes facilmente.
Para entender a necessidade da utilizao deste processo durante a criao do
esquema do banco de dados, discutiremos o que pode acontecer de errado no projeto. A

13
propriedade indesejvel que um projeto de banco de dados pode ter a repetio
desnecessria de informaes.
Considere que o Aluno Joo da Silva, da figura 4, se matricule para um novo
curso na instituio de ensino e uma nova matrcula seja gerada para registro deste novo
aluno no curso. desejvel que no aja repetio de informaes no projeto do banco
de dados, pois isto aumenta o custo de armazenamento e dificulta a tarefa de atualizao
dos dados. Suponha que o nmero do telefone deste aluno seja alterado. Esta alterao
deve refletir nas duas linhas, sendo mais custosa nesta tabela do que em uma tabela
normalizada.
Aplicando a normatizao a este projeto, o atributo curso fica independente do
registro do aluno, evitando a repetio de informaes desnecessrias, conforme mostra
a figura 4. Nota-se que os dados representados so os mesmos (com adio do registro
do novo curso do aluno 312412), porem sem a duplicao desnecessria de dados
(SILBERSCHATZ, 2006).

FIGURA 4-UM ESQUEMA NORMALIZADO

14
2.5.4 ACID

Uma parte importante dos bancos de dados relacionais a propriedade ACID,

que faz parte de seu ncleo. ACID um acrnimo derivado da primeira letra das
seguintes propriedades: Atomicidade, Consistncia, Isolamento e Durabilidade.
Atomicidade a capacidade do banco de dados permitir que as operaes sejam
efetuadas com sucesso no banco de dados, ou nenhuma delas ser efetuadas.
Consistncia a propriedade que garante que as transaes isoladas (sem
qualquer outra transao executando simultaneamente) preserva a consistncia do banco
de dados.
Isolamento a propriedade que garante que caso duas transaes sejam
executadas simultaneamente, o sistema deve garantir que cada transao seja executada
sem estar ciente das outras transaes existentes no sistema.
A durabilidade garante que aps uma transao ser completada com sucesso, as
mudanas que ela efetuou no banco de dados persistem, mesmo em caso de falha no
sistema (SILBERSCHATZ, 2006).

2.6

Banco de Dados Orientados a objetos

Bancos de dados relacionais se provaram bastante adequados para aplicaes

empresariais, principalmente no ramo bancrio. Entretanto, ele no adequado para
todos os tipos de aplicaes. Novas aplicaes, que envolvem modelagem complexa de
dados (que no se adaptam bem a modelagem em tabelas), agora requerem servios que
normalmente so associados com sistemas de bancos de dados: persistncia, transaes
atmicas, controle de acesso, estabilidade de dados, etc.
Para exemplificar, considere uma aplicao utilizada por uma empresa
aeronutica. A aplicao auxilia tanto na especificao quanto na parte de design das
aeronaves. Objetos fsicos no se adaptam bem a modelos tabulares, ou modelos
relacionais. Em particular, uma aeronave requer muitas partes duplicadas, e cada uma
necessitaria de um identificador nico para ser armazenado em um modelo relacional.
Alm disso, as relaes representando partes diferentes da aeronave que so

15
praticamente similares iriam requerer esquemas independentes e separados. Finalmente,
o design completo requer centenas de milhares de partes e acesso direto a cada parte
deste design se torna impraticvel.
Bancos de dados orientados objetos so uma tentativa de resolver estas
dificuldades (assim como outras), e ainda manter as vantagens dos sistemas de banco de
dados. Em uma entidade composta de vrias partes possvel ter acesso direto a um de
seus componentes, ao invs de associar explicitamente um identificador nico a cada
uma de suas partes e criar uma tabela extra de relacionamento. Alm disso,
programadores podem manipular entidades do banco de dados em qualquer nvel de
abstrao, atravs da extenso dos tipos de dados conhecidos pelo banco. Isso
importante pois significa que o programador no necessita transformar o tipo de dado da
aplicao para facilitar sua persistncia no banco (HOROWITZ, 1991).

2.6.1 Tipos de dados complexos

Considere, por exemplo, uma aplicao para biblioteca, onde as seguintes

informaes so armazenadas para cada um dos livros:

Titulo

Lista de Autores

Editora

Conjunto de palavras-chaves

Considerando os atributos acima, alguns possuiro domnios no atmicos.

Autores: Um livro pode ter mais de um autor, que seria representado por

um array (uma lista).

Conjunto de palavras-chaves: Quando um conjunto de palavras chaves

armazenado para um livro, esperado que seja possvel recuperar todos os livros que
compem determinado tema (palavra-chave).
Ttulo

Autor

Editora

Conjunto Palavras Chaves

Compiladores

[Smith, Jones]

tica

[anlise, programao]

Redes

[Jones, Frick]

Globo

[internet, web]

TABELA 3 - TABELA DE LIVROS NO NORMALIZADA

16
A tabela 3 representa a tabela com os dados dos livros desta biblioteca. Para
simplificar, consideraremos que o nome do livro nico e capaz de identificar cada
registro da tabela, sendo a chave primria da mesma.

FIGURA 5- TABELAS QUE REPRESENTAM A

TABELA 3DE FORMA NORMALIZADA

A figura 5 mostra o modelo do banco de dados normalizado. Embora ele possa

ser representado sem a utilizao de tabelas alinhadas, o uso dessas relaes leva a um
modelo mais fcil de entender. O usurio ou o programador de um sistema de
recuperao de informaes pensam no livro como sendo um objeto que possui
conjunto de autores, como o modelo da tabela 3, no como o modelo normalizado da
figura 5. O projeto normalizado exige que as consultas usem junes de vrias relaes,
enquanto o projeto no normalizado torna muitos tipos de consultas mais fceis
(SILBERSCHATZ, 2006).

17
2.7

Banco de dados NoSQL

O termo NoSQL foi utilizado pela primeira vez no ano de 1998, por Carlo
Strozzi, para identificar bancos de dados de cdigo aberto que no possuam interface
SQL (linguagem universal de manipulao de dados, utilizada pelos bancos de dados
relacionais). Este novo conceito totalmente distinto do modelo relacional, e seria mais
apropriadamente chamado de NoRelacional, porm o nome NoSQL, adotado, possui um
efeito melhor (NVRSDQEF, 2010).
Bancos de dados no relacionais, incluindo hierrquicos, grficos e orientados a
objetos esto em uso desde os anos 60. Entretanto, novos tipos de bancos de dados no
relacionais esto sendo desenvolvidos, como os bancos colunares. Diferentes bancos de
dados NoSQL tem diferentes abordagens, porm o que todos eles possuem em comum
que no so relacionais. A principal vantagem de um tipo de dados no relacional que,
diferente da abordagem tradicional, eles lidam bem com dados desestruturados, tais
como emails, dados multimdia e dados provenientes de mdias sociais (Leavitt, 2010).
Alm disso, a necessidade de melhorar o desempenho dos bancos de dados, e
diminuir os custos de armazenamento e processamento de informaes impulsionaram o
desenvolvimento desta nova metodologia de banco de dados. O NoSQL lida bem com
distribuio horizontal, ou seja, consegue ser distribudo entre vrias estaes para
armazenamento de maiores quantidades de dados, e estes novos servidores no precisam
ser de alto desempenho (NVRSDQEF, 2010).
Esta nova abordagem principalmente utilizada por empresas da web 2.0, com
quantidades gigantescas de dados e infra-estrutura, como a Google e a Amazon. Eles
desenvolveram Big Table e Dynamo, ambos bancos de dados NoSQL (Leavitt, 2010).
De fato, um dos grandes utilizadores desta metodologia a Google, que utiliza
computadores de pequeno e mdio porte para armazenagem e distribuio de dados,
com utilizao mais eficiente dos recursos e mais econmica.
O armazenamento de dados destes bancos evoluiu conforme a necessidade da
aplicao, com diferentes modelos de dados e capacidades. Os elementos bsicos
podem ser considerados objetos, documentos ou registros. Apesar dessas
variaes, podemos considerar como essncia deste sistema:

A no existncia de um esquema pr definido. Os dados podem possuir

qualquer nmero de atributo de qualquer tipo. A falta de um esquema global facilita o

18
desenvolvimento de um banco de alta disponibilidade, pois no necessrio desativar o
banco para efetuar alteraes no esquema.

Estes sistemas possuem uma API (Interface de Programao de

Aplicaes) de buscas simples, o que, diferente dos bancos relacionais, encoraja buscas
simples, sem necessidade de grandes unies de tabelas.

A escalabilidade proporcionada pelos ns da rede. Diferente dos bancos

de dados relacionais, que utilizam as propriedades ACID, bancos NoSQL promovem

uma consistncia eventual, ou garante a consistncia dentro de um nico objeto (ou
documento ou registro).

Esta metodologia tambm permite alta disponibilidade, que necessria

para fazer com a que a escalabilidade entre diversas mquinas seja utilizvel. Isto
alcanado atravs da identificao de falhas e de recuperao utilizando cpias de ns
espelhos.
A escalabilidade destes bancos tem seu preo: a aplicao deve poder operar
com menores nveis de consistncia garantida, sem transaes que afetem vrios
registros. Estes bancos de dados so populares entre aplicaes da web 2.0 pois estes
programas normalmente operam com baixa (se houver) necessidade de consistncia,
sendo possvel o suporte a deciso com dados mais antigos (Cattel, 2010).
Os bancos de dados NoSQL so subdivididos pelo seu ncleo, ou seja, como ele
lida com as informaes que armazena. Os principais tipos de ncleo so: Key/Value
Store, Document Store e Wide Columns Store (NVRSDQEF, 2010).

2.7.1 Armazenamento Key/Value

Este modelo de armazenamento de dados considerado o mais simples, o

conceito de uma chave e um valor que armazenado por esta chave. Devido a sua
simplicidade, o modelo que possuir maior escalabilidade (NVRSDQEF, 2010).
Esta abordagem pode ser considerada um HashTable gigante (um mapa ou
dicionrio, dependendo da linguagem de programao). As buscas podem ser efetuadas
apenas pelo valor da chave (WCS, 2010).

19
O banco de dados SimpleDB, da Amazon, uma implementao desta
metodologia. Ele prove funes de indexao de informaes e buscas na web 2.0. Ele
possui uma interface simples para persistncia de dados e acesso (Leavitt, 2010).

FIGURA 6- TABELA KEY/VALUE (TERMEHCHY,2010)

Na figura 6 podemos observar um exemplo de tabela Key/Value. Este modelo de

banco de dados bastante utilizado para aplicaes para grandes aplicaes de Web
Service. As chaves (Keys) so nicas, e cada uma aponta para um conjunto de valores
(Termehchy, 2010).

2.7.2 Armazenamento de documentos

Este modelo armazena e organiza os dados como uma coleo de documentos,

ao invs de tabelas estruturadas, com campos e valores predefinidos para cada registro.
Com este tipo de banco de dados, o programador livre para adicionar quantos campos
forem necessrios de qualquer comprimento ao documento (WCS, 2010).
As buscas em modelo de armazenamento de documentos podem ser efetuadas
pelo valor de suas chaves ou por qualquer um dos valores contidos dentro de seu
documento, como buscas por XPath ou mtodos query by example (WCS, 2010).
O banco de dados CouchDB, da Apache Software Foundation, um exemplo
desta metodologia, escrito em Erlang e open source, que pode ser acessado por qualquer
browser (Leavitt, 2010).

20

FIGURA 7- UM DOCUMENTO (SIEERA,2004)

A figura 7 demonstra uma rede de metr e um documento utilizado para buscas

de rotas nesta rede. Nota-se que cada atributo possui a tag inicial e final. Todo o
documento fica entre a tag inicial <Subway> e a tag final </Subway> (Sieera, 2004)

2.7.3 Armazenamento de grandes colunas

Este tipo de armazenamento baseado no documento BigTable: A distributed

Storage System for Structured data(Chang, 2006). Vrios projetos, alm do prprio
BigTable, implementam este conceito. Estes bancos de dados suportam um grande
nmero de colunas por linhas, permitindo buscas pelos valores das colunas, colunas que
contm lista de valores e/ou sub-colunas e linhas com variveis de coluna (WCS, 2010).
Esta metodologia tem como principal banco o Big Table, da Google. Vrias
aplicaes desta companhia utilizam seu banco de dados NoSQL para armazenar seus
dados. Dentre estas aplicaes, destaca-se o Google Analytics, um programa que tem

21
como finalidade auxiliar webmasters a analisar o acesso a seu website. Atravs desta
ferramenta, o webmaster consegue inferir diversos dados a respeito dos visitantes do
website. Duas das principais tabelas utilizadas por esta aplicao utilizam banco de
dados NoSQL: A tabela de clicks brutos (raw click table) e a tabela de sumrio, que
juntas possuem aproximadamente 220TB de informaes so armazenadas com este
modelo de dados criado pelo Google (Chang, 2006).

2.7.4 Bancos de dados Orientados a coluna

Em uma arquitetura orientada a colunas, o valor de cada coluna (atributo)

armazenado em seqncia, aumentando a performance da leitura de uma nica coluna.
Com este modelo de armazenamento, o banco de dados carrega em memria apenas os
valores das colunas que sero utilizados, evitando preencher a memria com dados que
no sero utilizados.
H duas formas que os bancos de dados colunares podem utilizar CPU para
diminuir a utilizao do disco rgido. Primeiro, eles podem codificar os dados para uma
forma mais compacta (transformar os dados em bytes, ao invs de armazena-los em sua
forma nativa). Em segundo lugar,em um armazenamento colunar, mais simples para
comprimir N valores, cada um de um tamanho K bits, em um espao N * K bits
(Stonebraker, 2005).

22
3

Business Intelligence

Este captulo apresentar a definio de Business Intelligence, o objetivo dessa

aplicao e ir fazer uma breve introduo sute de BI Pentaho.
Este captulo est organizado como segue: A seo 3.1 introduz o conceito de
Business Intelligence, a seo 3.2 define uma aplicao de BI e a seo 3.3 apresenta o
aplicativo Pentaho.

3.1

Business Intelligence

Na ultima dcada a rea de Tecnologia da Informao (TI) ganhou grande

importncia nas empresas, a ponto de alguns especialistas estimarem que
aproximadamente metade do capital aplicado pelas empresas tem como destino o
departamento de TI. O crescimento de grandes empresas deste setor, tal como SAP,
Oracle, Microsoft, IBM, Cisco e Dell, entre outras, comprova o grande investimento das
companhias neste setor.
Grande parte deste investimento foi destinado a sistemas que permitam o
controle das operaes dirias, e a gerao de relatrios mais freqentes e volumosos.
Estes sistemas tornam estas empresas ricas em dados, porm pobres em informao. Em
outras palavras, apesar de possurem uma grande base de dados, falta a estas
companhias ferramentas para tornar estes dados em informaes teis, necessrias para
melhorar a produo e aumentar os lucros da companhia.
Business Intelligence (BI) a resposta a esta necessidade. Quando bem
implementado, aplicaes de BI tem um enorme potencial para aumentar a renda e
melhorar o controle da companhia sobre si mesma, atravs das informaes
armazenadas (WILLIAMS, 2007).

23
3.2

Definio

Business Intelligence pode ser definido como um conjunto de modelos

matemticos e mtodos de anlise que atravs da anlise sistemtica de dados, resulta
em informaes e conhecimento til na tomada de deciso (VERCELLIS, 2009).
BI combina produtos, tecnologias e mtodos para organizar informaes chaves
que os gerentes necessitam para melhorar os lucros e o desempenho. Mais amplamente,
BI a inteligncia e anlise de negcios dentro do contexto dos processos chaves que
levam a decises e aes que resultam em um melhor desempenho para a empresa. Isto
envolve informaes de mercado e anlise que :

Utilizada em um contexto dos processos empresariais chaves;

Suporta deciso e comportamento;

Levam a melhores desempenhos dos negcios.

Para empresas, o foco primrio o aumento de receitas e/ou reduzir custos,

atravs da melhora da performance e aumento do lucro. Para o setor pblico, o foco
primrio servir aos cidados, lidar com suas restries e usar os recursos disponveis
sabiamente para servir aos objetivos do governo (WILLIAMS, 2007).
As metodologias de BI so interdisciplinares e amplas, abrangendo diversos
domnios de aplicaes. Elas se preocupam com a representao e organizao do
processo de tomada de deciso; com a coleta e armazenamento de dados com o
propsito de facilitar o processo de deciso; com modelos matemticos para otimizao
e minerao de dados, alm de auxiliar operaes de busca e de estatsticas; e
finalmente, esto ligadas a diversos domnios de aplicao, tal como marketing,
logstica, finanas, servios, e administrao pblica (VERCELLIS, 2009).
Estas aplicaes tendem a promover uma abordagem racional e cientfica para o
gerenciamento de companhias e organizaes complexas. Mesmo o uso de planilhas
eletrnicas, tais como o Microsoft Excel, para avaliao dos efeitos resultantes na
variao da taxa de desconto, apesar de sua simplicidade, requer na parte de toma de
deciso uma representao bsica dos fluxos financeiros (VERCELLIS, 2009).
Uma aplicao de BI oferece informaes de tomada de deciso e conhecimento
derivado de processamento de dados, atravs da aplicao de modelos matemticos e
algoritmos. Em alguns casos, estas aplicaes podem consistir apenas de clculos totais

24
e porcentagens, enquanto anlises mais desenvolvidas fazem o uso de modelos
avanados de otimizao, aprendizagem indutiva e previso (VERCELLIS, 2009).
Os usurios de uma aplicao de BI observam o desenvolver da companhia. Eles
contabilizam, atravs da ferramenta, o nmero de vendas por semana, comparam estas
vendas com as das semanas anteriores, observam as tendncias dos consumidores e suas
reclamaes. Usurios de um DW (Data Warehouse) praticamente no lidam com dados
isolados (uma nica linha de registro do banco). Na verdade, seus questionamentos
normalmente fazem com que centenas de milhares de linhas de uma tabela sejam
buscadas e compactadas em um conjunto de respostas. Alm disso, os questionamentos
que so feitos ferramenta esto mudando constantemente (KIMBALL, 2002).

3.2.1 Objetivos de uma aplicao de BI

Os objetivos que devem ser alcanados com a implantao de uma aplicao de

BI na empresa so:

Tornar a informao da organizao de fcil acesso. O contedo da

aplicao de BI deve ser de fcil entendimento, de modo que o usurio consiga

compreender os dados que constam na ferramenta, no apenas o desenvolvedor
(KIMBALL, 2002).

A informao deve ser apresentada consistentemente. As informaes

disponibilizadas na aplicao devem vir de vrias fontes dentro da mesma organizao,

ser compactada e disponibilizada aos usurios apenas quando for de utilidade para o
mesmo (KIMBALL, 2002).

A aplicao deve ser adaptativa e preparada para mudanas. As

necessidades do usurio, do negcio, da companhia esto sujeitas a alterao com o

passar do tempo. A aplicao deve ser projetada de modo a estar preparada para estas
mudanas necessrias para adaptar a aplicao necessidade da empresa (KIMBALL,
2002)

As informaes devem ser armazenadas em um ambiente seguro. A

aplicao deve controlar o acesso a informaes confidencias da companhia, e permitir

25
que apenas usurios devidamente autorizados possuam acesso aos dados crucias da
empresa (KIMBALL, 2002)
Como ilustrado anteriormente, aplicaes de auxlio a deciso precisam alm de
auxiliar na parte estratgica do negcio, gerar informaes em um tempo hbil, alm de
garantir que estas informaes apenas estejam disponveis aqueles que necessitem
utiliz-la.
Operacional

Analtico

Propsito

Executar um processo

Avaliar um processo

Estilo iterao

Insert, update, delete, query

Query

Escopo iterao

Transao individual

Agregao

Padro query

Previsvel e estvel

Imprevisvel

Foco temporal

Atual

Atual e histrico

Otimizao

Update concorrente

Query

Projeto

ER na 3FN

Star Schema ou Cubo

Conhecido como

OLTP

Data Warehouse

TABELA 4 - DIFERENA ENTRE SISTEMAS OPERACIONAIS

E ANALTICOS (ADAMSON, 2010)

A tabela 4 mostra que, enquanto sistemas cujo objetivo o suporte a operao se

focam na execuo de um processo, baseando-se principalmente em transaes
individuais, sistemas analticos tem como propsito avaliar um processo, e esta
avaliao feita principalmente utilizando-se a agregao. Esta mudana de paradigma
abre oportunidades para diferentes modelos de dados serem utilizados pelo sistema de
BI (Adamson, 2010).

3.3

Pentaho

Pentaho uma poderosa suite de BI que oferece diversas ferramentas: anlise de

dados, gerao de relatrios, minerao de dados entre outras. Esta aplicao de BI
open source, ou seja, seu uso gratuito e os desenvolvedores so livres para estudar e
modificar seu cdigo fonte (Bouman, 2009).

26

FIGURA 8- PENTAHO

FIGURA 9- PENTAHO

Conforme pode ser observado nas figuras 8 e 9, a utilizao de uma aplicao de

BI fornece, por meio de ferramentas grficas, meios da equipe estratgica da empresa
compreender os dados armazenados e tomar decises importantes a respeito do
planejamento futuro.

27
4

Ferramentas Utilizadas

Este captulo tem como objetivo apresentar as ferramentas que sero utilizadas
durante a execuo dos testes comparativos.
Este captulo est organizado como segue: a seo 4.1 apresenta o banco de
dados relacional Mysql, a seo 4.2 apresenta o banco de dados colunar LucidDB, a
seo 4.3 apresenta o software para medio de desempenho JMeter, a seo 4.4
apresenta o software Medidor de desempenho do Windows e a seo 4.5 apresenta o
software de virtualizao Oracle Virtual Box.

4.1

Mysql

A verso 5.5 do Mysql introduziu uma arquitetura com melhorias de

desempenho e de escalabilidade. Estas so algumas das melhorias que foram
disponibilizadas a partir desta verso:

Melhoria de desempenho em ambientes Windows

Melhoria do controle de concorrncia de threads

Controle da taxa de I/O (Escrita / Leitura) global das threads

Controle do uso de alocao de memria do sistema operacional

Grande parte das melhorias que ocorreram na arquitetura do Mysql tem como
objetivo uma performance mais transparente e ganhos de escalabilidade em plataformas
heterogenias,

especificamente

em

hardwares

multi-CPU/core,

arquiteturas

de

processamento paralelo (WNM, 2011).

O SGDB relacional Mysql, que de propriedade de Oracle, foi escolhido por ser
um dos bancos de dados mais utilizados no mundo, devido a sua alta performance,
confiabilidade e facilidade de uso, alm de este banco de dados ser compatvel com
mais de 20 plataformas de software, incluindo Linux, Windows, Mac Os, Solaris, entre
outros (Mysql, 2011).

28
4.2

LucidDB

LucidDB , at o presente momento, o primeiro e nico banco de dados de

cdigo aberto construdo especificamente para ser utilizado por aplicaes de Business
Intelligence e Data Warehousing. Seus componentes foram construdos com os
requerimento de alta performance, flexibilidade, e um sofisticado processo de buscas
(LucidDB, 2011).

4.3

Apache JMeter

Apache JMeter uma ferramenta open source disponibilizada pela Apache

Foundation, e seu objetivo efetuar testes de comportamento e performance em
aplicaes. Ele pode ser utilizado para testes em recursos dinmicos e estticos
(arquivos, servlets, objetos Java, Bancos de dados, etc) (JMeter, 2011).
Este aplicativo ser utilizado pois open source e ser um dos softwares mais
utilizados para anlise de aplicaes.

4.4

Monitor de Desempenho do Windows

O Monitor de Desempenho do Windows um snap-in do Console de

Gerenciamento Microsoft (MMC) que fornece ferramentas para analisar o desempenho
do sistema. A partir de seu console, pode-se monitorar o desempenho de aplicativo e
hardware em tempo real, personalizar que dados deseja coletar nos logs, definir limites
para alertas e aes automticas, gerar relatrios e exibir os dados do desempenho
passado de vrias maneiras.
O Monitor de Desempenho do Windows combina varias funcionalidades, tais
como incluir Logs e Alertas de Desempenho, Supervisor de Desempenho de Servidor e
Monitor de Sistema. Ele fornece uma interface grfica para a personalizao dos
Conjuntos de Coletores de Dados e Sesses de Rastreamento de Eventos (Microsoft,
2011).

29
Este software ser utilizado visto que nativo do Windows, e o mesmo possuir
todas as funcionalidades que sero necessrias para anlise das aplicaes durante o
teste.

4.5

Oracle Virtual Box

VirtualBox um produto de virtualizao que pode ser utilizado para fins

corporativos ou pessoais. Alem de ser uma ferramenta com diversas funcionalidades e
um produto de alta performance, atualmente a nica soluo profissional que
disponibilizada gratuitamente sobre a licena GPL (General Public License)
(VirtualBox, 2011).
Este software de virtualizao foi escolhido pois o mesmo gratuito, e possui
uma interface simples e prtica, principalmente para configurao do ambiente virtual.

30
5

Proposta de soluo

Este captulo tem como objetivo definir quais critrios sero considerados na
comparao entre os bancos de dados relacionais e NoSQL, e explic-los.
Este captulo est organizado como segue: A seo 5.1 define os Sistemas
Gerenciadores de Banco de dados utilizados para estudo, a seo 5.2 define a aplicao
analisada, a seo 5.3 apresenta o ambiente de teste, a seo 5.4 define os testes que
sero efetuados, a seo 5.5 apresenta os critrios que sero analisados em cada teste, e
a seo 5.6 Definio dos softwares utilizados para execuo e coleta de dados durante
os testes.

5.1

Sistemas Gerenciadores de Banco de dados utilizados para estudo

Para realizao do estudo comparativo entre banco de dados relacionais e

NoSQL na utilizao por aplicaes de Business Intelligence, foram selecionados dois
SGDBs: os banco de dados relacional Mysql e o banco colunar LucidDB.
Ser utilizada a ltima verso estvel de cada um dos bancos de dados, a saber:
Mysql verso 5.5.9 e LucidDB verso 0.9.3.

5.2

Definio da aplicao analisada

Ser utilizada a aplicao WCM (World Class Movies), uma aplicao de

licena GPL para execuo dos testes comparativos entre os bancos de dados.
A aplicao WCM uma aplicao fictcia criada pela equipe do Pentaho para
demonstrao do sistema. Por ter uma grande base de dados e que contempla dados de
todo o processo de venda de um produto, esta aplicao ser utilizada para efetuar o
teste comparativo entre os bancos de dados.
A WCM uma empresa de locao e venda de DVDs, cujo mercado formado
pelas mais diversas classes sociais e faixa etrias. O sistema de locao / venda

31
inovador, pois a transao considerada uma locao caso o cliente devolva o filme
aps um perodo de tempo determinado, porm se ultrapassar este perodo considerada
como uma venda.
A empresa iniciou suas atividades em Abril de 2000, e os dados de transaes
contemplam dados de todos os portais que fazem parte da aplicao. Alm dos dados de
vendas, a WCM tambm possui dados bsicos sobre os filmes, como gnero, dados dos
atores e diretores dos filmes (Bouman, 2009).

5.2.1 Definio do modelo de dados

Ser utilizado o modelo de dados do Data Warehouse da prpria WCM para

execuo dos testes comparativos. A Figura 10 mostra o diagrama entidade
relacionamento das tabelas utilizadas. Os atributos das tabelas foram omitidos, visto que
algumas tabelas possuem mais de 100 atributos. No Apndice 1 h uma explicao
sobre as tabelas que compem este modelo de dados.

FIGURA 10 - MODELO DIMENSIONAL DO DATA WAREHOUSE

32
5.3

Definio do ambiente de teste

Os testes sero efetuados em um Notebook DELL, com as seguintes

configuraes:

3Gb de Memria RAM

Processador Pentium Dual Core T4200 2.00GHz

120GB HD

Sistema operacional Windows 7 Professional

Para garantir condies idnticas de testes para ambos os bancos de dados, a

execuo dos testes ser efetuada em mquinas virtuais, e cada mquina virtual ter a
seguinte configurao:

Sistema operacional Windows XP Service Pack 2

10Gb de HD.

1.5Gb de memria RAM.

Em cada mquina virtual sero instalados apenas os softwares bsicos

necessrios para execuo dos testes e funcionamento do banco de dados sendo
analisado. Ser executado o script de insero de dados da empresa WCM em ambos os
bancos de dados. No haver nenhuma otimizao de dados nas tabelas, ou seja, as
tabelas sero criadas apenas com seus atributos comuns, sem adio de nenhum ndice.
As imagens podem ser disponibilizadas para futuros trabalhos baseados no presente
estudo.

5.4

Definio dos testes

Sero efetuados 4 queries (buscas) na base de dados, e cada uma destas buscas
ser repetida 200 vezes, e ser utilizado para comparao a mdia dos resultados. As
buscas que sero efetuadas iro simular consultas que podem ser efetuadas por um
usurio comum de um sistema de Business Intelligence.

33
Os testes sero efetuados seqencialmente, ou seja, a segunda busca s iniciar
aps a busca anterior ter sido executada 200 vezes, e assim sucessivamente at o final
do teste.
Durante a execuo de cada querie sero coletados os dados necessrios para
posterior anlise dos critrios definidos na seo 5.4.
Sero efetuadas as seguintes buscas no banco de dados:

Qual gnero de filme gerou mais receitas no ano de 2008?

Como o lucro est evoluindo com o tempo?

Qual horrio do dia os consumidores fazem mais locaes?

Quo efetivas foram as promoes no ano de 2008?

No apndice 2 pode ser encontrado o script utilizado para execuo das buscas
acima em ambas as bases de dados.

5.5

Definio dos critrios analisados

Durante a busca, sero coletados dados para anlise e comparao dos bancos de
dados de acordo com os critrios que seguem.

5.5.1 Desempenho

Para comparao do desempenho, ser considerado o tempo mnimo, mximo e

a mdia do tempo necessrio para as aplicaes obterem os dados solicitados. Ser
considerado o banco de dados com melhor performance aquele que possuir o menor
tempo mdio de resposta.

34
5.5.2

Utilizao de CPU

Para comparao da utilizao de CPU, ser considerado a % de utilizao do

processador durante o processamento da requisio. Ser considerado o banco de dados
com o melhor uso de CPU aquele que utilizar a menor % de ciclos da CPU para
processar a querie.

5.5.3 Uso de memria

Para comparao do uso de memria, ser considerada a quantidade de memria,

em MB, livre durante o processamento da requisio. Ser considerado o banco de
dados com o melhor uso de memria aquele que a utilizar em menor quantidade durante
o processamento da requisio.

5.5.4 Alocao das tabelas em disco

Para comparao da alocao em disco, sero executadas queries nos metadados

(dados sobre dados dos bancos de dados), a fim de se determinar o espao em disco
utilizado para armazenar os dados. Ser considerado o banco de dados com melhor
alocao em disco aquele que utilizar a menor quantidade para armazenamento das
tabelas.

5.5.5 Desempenho utilizando menor quantidade memria RAM

Sero realizados dois testes adicionais para verificao do comportamento dos

bancos de dados com diferentes quantidades de memria RAM disponvel. No primeiro
teste, a quantidade de memria total ser de 1000mb, enquanto que no segundo a

35
quantidade total ser de 500mb. Neste teste sero efetuadas apenas 100 buscas da
primeira querie (Gnero com maior receita em 2008), para verificar se houve alguma
diferena no desempenho e na quantidade de memria livre (em % do total) em relao
ao teste original, onde as mquinas possuam 1500mb de memria total.

5.6

Definio dos softwares utilizados

Durante a execuo dos testes, sero utilizados os softwares que seguem para
coleta de dados para posterior anlise comparativa entre os SGDBs escolhidos.

5.6.1 Apache JMeter

Ser programado no JMeter para que cada uma das queries sejam executadas
200 vezes simultaneamente via JDBC. O JMeter ir salvar os dados de desempenho de
cada querie em um arquivo de log, para anlise posterior.

5.6.2 Monitor de desempenho do Windows

O Aplicativo monitor de desempenho do Windows ser utilizado para salvar os

dados referentes utilizao de CPU e memria durante a execuo dos testes.
O monitor de desempenho ser programado para obter a % de utilizao da CPU
e a quantidade (em megabytes) de memria livre no sistema a cada 15 segundos. Os
dados obtidos sero armazenados em um arquivo de log para posterior anlise.

36
5.6.3 Oracle Virtual Box

Ser utilizado o Aplicativo Oracle VirtualBox para criao dos ambientes

virtuais onde sero realizados os testes definidos anteriormente.

37

Resultados Encontrados

Este captulo tem como objetivo apresentar os resultados encontrados na anlise

comparativa dos sistemas de banco de dados relacional e NoSQL na utilizao por uma
aplicao de Business Inteligence.
Este captulo est organizado como segue: A seo 6.1 apresenta os resultados
encontrados durante a execuo dos testes.

6.1

Resultados Encontrados

Aps a execuo das queries em ambas as bases de dados, foram encontrados os

seguintes resultados.

6.1.1 Anlise comparativa do desempenho

Os itens que seguem mostram os resultados encontrados durante a anlise

comparativa do o desempenho das aplicaes durante a execuo dos testes. Neste
critrio foi analisado o tempo mnimo necessrio para o banco de dados fornecer o
resultado esperado, o tempo mximo necessrio para o banco de dados retornar os dados
e o tempo mdio necessrio para os banco de dados enviarem os dados solicitados.
Todos os resultados apresentados esto em Milissegundos.
A diferena entre os valores apresentados foi calculada utilizando-se a seguinte
frmula: (Resultado com maior tempo / resultado com menor tempo) -1.

38
6.1.1.1 Gnero com maior receita em 2008

Na anlise comparativa de desempenho da primeira querie, foram obtidos os

resultados que podem ser observados na tabela 5.
Tempo

Tempo

Tempo

Mnimo

Mximo

Mdio

Mysql

23569

33033

25312

LucidDB

3851

4669

4014

Diferena

512,02%

607,50%

530,67%

TABELA 5 - ANLISE COMPARATIVA DO DESEMPENHO NA PRIMEIRA QUERIE

Conforme pode ser observado na tabela 5 e na figura 11, o banco de dados

LucidDB possui um desempenho superior que seu adversrio, o banco de dados Mysql,
em todas as queries efetuadas, em todos os quesitos. No tempo mnimo, ou seja, o
melhor desempenho do banco de dados, a diferena entre os softwares analisados chega
a ser superior a 500%. Nos campos tempo mximo (o pior desempenho do banco de
dados para obteno do resultado), a superioridade do banco de dados LucidDB para
apresentao dos resultados ainda maior, visto que h uma diferena de 600% entre os
bancos de dados.
J no tempo mdio, que leva em conta uma mdia simples (soma-se todos os
resultados e divide-se por 200), nota-se que, em mdia, a diferena entre os sistemas
chega a 530%, que uma quantia considervel, visto que esperar 25 segundos para se
obter um relatrio uma quantia de tempo muito grande, enquanto que a espera mdia
de 4 segundos j aceitvel.
A figura 11 mostra os resultados da tabela 5 em forma de grfico, para melhor
anlise dos resultados apresentados.

39

FIGURA 11 - COMPARATIVO DO DESEMPENHO NA PRIMEIRA QUERIE

Conforme pode ser observado na figura 11, a performance do banco de dados

LucidDB manteve-se praticamente constante ao longo do tempo, enquanto a
performance do Mysql foi bastante instvel, havendo picos onde o resultado era
apresentado com mais lentido.

6.1.1.2 Evoluo do lucro

Os dados coletados durante a execuo da segunda querie podem ser observados

na tabela 6.
Tempo

Tempo

Tempo

Mnimo

Mximo

Mdio

24748

27128

25549

LucidDB 2233

2774

2338

Diferena 1008,28%

877,94%

992,72%

Mysql

TABELA 6 - ANLISE COMPARATIVA DO DESEMPENHO NA SEGUNDA QUERIE

40

FIGURA 12 - GRFICO COMPARATIVO DO DESEMPENHO DA SEGUNDA QUERIE

Analisando os dados que compem a tabela 6 e da figura 12, podemos observar

que o desempenho do banco de dados LucidDB foi novamente superior ao de seu
adversrio, o Mysql. O menor tempo do sistema NoSQL foi mais de 1000% mais lento
que seu adversrio, e no maior tempo houve uma diferena de 877% entre as
performances.
No tempo mdio, que contempla o resultado das 200 buscas efetuadas, a
performance do LucidDb foi 990% superior ao Mysql, apresentando um tempo mdio
de 2338 ms, contra um tempo mdio de 25549 ms.
Novamente observamos que o desempenho do banco de dados LucidDB foi
praticamente constante ao longo do tempo, e que o desempenho do Mysql foi mais
constante durante esta busca, se comparado com o resultado que este banco obteve no
item 6.1.1.1.

6.1.1.3 Horrio com maior nmero de locaes

Seguem, na tabela 7 e na figura 13, os dados referente a anlise de performance

de ambos os bancos de dados durante execuo da terceira querie.

41
Tempo

Tempo

Tempo

Mnimo

Mximo

Mdio

29820

37518

30512

LucidDB 2273

3999

2402

Diferena 1211,92%

838,18%

1170,45%

Mysql

TABELA 7 - ANLISE COMPARATIVA DO DESEMPENHO NA TERCEIRA QUERIE

FIGURA 13 - GRFICO COMPARATIVO DO DESEMPENHO NA TERCEIRA QUERIE

Conforme podemos observar na tabela 7 e na figura 13, o desempenho do banco

de dados LucidDB foi novamente superior ao seu adversrio, o banco de dados Mysql.
Nos trs requisitos (Tempo mnimo, Tempo mximo e Tempo mdio), a
performance do banco de dados NoSQL foi significativamente superior ao banco de
dados relacional, obtendo diferenas significativas (1211%,

838% e 1170%,

respectivamente).

6.1.1.4 Efetividade das promoes

Na tabela 8 e na figura 14, podem ser observados os dados de desempenho dos

bancos de dados durante a ltima querie.

42
Tempo

Tempo

Tempo

Mnimo

Mximo

Mdio

16825

19264

17300

LucidDB 2494

5192

2599

Diferena 574,62%

271,03%

565,65%

Mysql

TABELA 8 - ANLISE COMPARATIVA DO DESEMPENHO NA QUARTA QUERIE

FIGURA 14 - GRFICO COMPARATIVO DO DESEMPENHO NA QUARTA QUERIE

Conforme pode ser observado na tabela 8 e na figura 14, apesar de a diferena

entre os bancos de dados em ambos os requisitos serem menores nesta querie que nas
trs buscas anteriores, o banco de dados NoSQL ainda possui uma grande vantagem
sobre o banco relacional.
Os tempos mnimo e mdio de busca do LucidDB ainda so significativamente
superiores que o do banco Mysql, porem a diferena entre o tempo mximo, embora
ainda seja superior (271% de diferena), a diferena mais acentuada do que aquela que
foi identificada nas queries anteriores (607%, 877% e 838% respectivamente).
A anlise do grfico que contempla todos os resultados mostra que apenas as
primeiras buscas do LucidDB ficaram fora do padro de tempo apresentado, enquanto o
banco de dados Mysql obteve sua performance mais constante nesta querie do que nas
trs anteriores, embora tenha um pico entre as queries 64 e 73.

43
6.1.2 Anlise comparativa da utilizao de CPU

Os itens a seguir mostram os resultados encontrados durante a anlise

comparativa da utilizao de CPU pelas duas aplicaes durante a execuo dos testes.
Neste critrio foi analisado apenas o uso mdio de CPU dos processos.
A diferena entre os dados analisados foi calculada utilizando-se a seguinte
formula: Maior utilizao de CPU Menor utilizao de CPU.

6.1.2.1 Gnero com maior receita em 2008

A tabela 9 mostra os resultados encontrados referente ao uso de CPU na primeira

querie.
Mdia
Mysql

99,94%

LucidDB 99,98%
Diferena 0,04%
TABELA 9 - ANLISE COMPARATIVA DO USO DE CPU NA PRIMEIRA QUERIE

Conforme podemos observar na tabela 9, a utilizao de CPU por ambas as

aplicaes praticamente idntica, a diferena (0,04%) praticamente nula.
Analisando este grfico podemos notar que o processador o elemento limitante
nas buscas em ambos os bancos de dados.

6.1.2.2

Evoluo do lucro

Na tabela 10, podemos observar a utilizao mdia de CPU durante a execuo dos
testes.

44
Mdia
Mysql

100,00%

LucidDB 100,00%
Diferena

0,00%

TABELA 10 - ANLISE COMPARATIVA DO USO DE CPU NA SEGUNDA QUERIE

Conforme observamos na tabela 10, a utilizao de CPU de ambos os sistemas de

banco de dados foi idntica nesta busca, sem distino do modelo de dados utilizado.

6.1.2.3

Horrio com maior nmero de locaes

Na tabela 11 podemos observar os dados de uso de CPU durante a execuo da

terceira querie.
Mdia
Mysql

100,00%

LucidDB 100,00%
Diferena

0,00%

TABELA 11 ANLISE COMPARATIVA DO USO DE CPU NA TERCEIRA QUERIE

Conforme podemos observar na tabela 11, a utilizao de CPU de ambos os

sistemas de banco de dados foi idntica nesta busca, sem distino do modelo de dados
utilizado.

6.1.2.4

Efetividade das promoes

Na tabela 12, podemos observar as dados referente a utilizao de CPU na quarta

querie.

45
Mdia
Mysql

99,98%

LucidDB 100,00%
Diferena

0,02%

TABELA 12 - ANLISE COMPARATIVA DO USO DE CPU NA QUARTA QUERIE

Conforme podemos observar na tabela 12, nesta querie houve uma pequena
diferena na utilizao de CPU (0,02%) entre os bancos de dados, porem esta diferena
praticamente inexistente, e no podemos concluir nada com base apenas nela.

6.1.3

Anlise comparativa da utilizao de memria

Os itens que seguem mostram os resultados encontrados durante a anlise

comparativa da utilizao de memria pelos bancos de dados NoSQL e relacional
durante a execuo dos testes. Neste critrio foi analisada a quantidade de memria
livre. Foram coletados os seguintes dados: quantidade mnima de memria livre,
quantidade mxima de memria livre e mdia da quantidade de memria livre durante a
execuo dos testes.
A diferena entre os dados analisados foi calculada utilizando-se a seguinte
frmula: (resultado com maior utilizao de memria / resultado com menor utilizao
de memria) - 1.

6.1.3.1

Gnero com maior receita em 2008

A tabela 13 apresenta os dados referente a quantidade livre durante a execuo da

primeira querie.
Menor

Maior

Mdia

LucidDB

557

707 593,3333

Mysql

860

1013 917,1543

Diferena 54,40% 43,28%

54,58%

46
TABELA 13 - ANLISE COMPARATIVA
DO USO DE MEMRIA NA PRIMEIRA QUERIE

FIGURA 15 - COMPARATIVO DO USO DE MEMRIA NA PRIMEIRA QUERIE

Conforme podemos verificar na tabela 13 e na figura 15, a quantidade de memria

livre durante a execuo do teste do banco de dados Mysql maior do que a quantidade
de memria livre durante a execuo do banco de dado adversrio, o LucidDB.
Podemos notar que, em mdia, o banco de dados Mysql possui 54% a mais de
memria livre que o banco de dados NoSQL.

6.1.3.2

Evoluo do lucro

A tabela 14 apresenta os dados referentes ao uso de memria durante a segunda

querie pelas aplicaes.
Menor

Maior

Mdia

LucidDB

574

604 589,7188

Mysql

837

893 873,3578

Diferena 45,82% 47,85%

48,10%

TABELA 14 - ANLISE COMPARATIVA DO USO DE MEMRIA NA SEGUNDA QUERIE

47

FIGURA 16 - COMPARATIVO DO USO DE MEMRIA NA SEGUNDA QUERIE

Conforme podemos verificar na figura 16 e na tabela 14, a quantidade de memria

livre durante a execuo do banco de dados relacional maior que a de seu adversrio,
o banco de dados NoSQL.
Verificamos que, em mdia, o banco de dados Mysql aloca 48% a menos de
memria que o banco LucidDB, deixando esta memria disponvel para outros
aplicativos. Podemos observar na figura 16 que diferena entre os bancos constante,
tanto no menor uso, quanto no maior e na mdia.

6.1.3.3

Horrio com maior nmero de locaes

A Tabela 15 apresenta os dados comparativos entre os bancos de dados LucidDB e

Mysql durante o teste comparativo.

48
Menor

Maior

Mdia

LucidDB

556

571 567,3125

Mysql

857

893 874,5577

Diferena 154,14% 156,39% 154,16%

TABELA 15 ANLISE COMPARATIVA
DO USO DE MEMRIA NA TERCEIRA QUERIE

FIGURA 17 - GRFICO COMPARATIVO DO USO DE MEMRIA

NA TERCEIRA QUERIE

Conforme podemos observar na tabela 15, novamente observamos que o banco de

dados relacional possui uma quantidade maior de memria disponvel que seu
adversrio, conforme tendncia observada nos itens 6.1.3.1 e 6.1.3.2.
A anlise da figura 17 mostra que a diferena de memria disponvel se mantm
constante nos 3 critrios observados (menor, maior e mdia).

49
6.1.3.4

Efetividade das promoes

A tabela 16 e a figura 18 mostram os dados referente a quantidade de memria

disponvel na ultima querie.
Menor

Maior

Mdia

LucidDB

547

560

Mysql

818

893 871,4701

Diferena 49,54% 59,46%

555,2
56,97%

TABELA 16 - ANLISE COMPARATIVA DO USO DE MEMRIA NA QUARTA QUERIE

FIGURA 18 - COMPARATIVO DO USO DE MEMRIA NA QUARTA QUERIE

Conforme podemos observar na Tabela 16, o banco de dados Mysql possui uma
maior quantidade de memria disponvel durante sua execuo, conforme tendncia j
observada anteriormente.
A figura 18 nos mostra que, novamente, a diferena entre a quantidade de memria
disponvel durante a execuo dos testes entre os bancos de dados se manteve
praticamente constante nos 3 critrios analisados.

50
6.1.4

Anlise comparativa da alocao das tabelas em disco

A tabela 17 apresenta os dados referente a anlise comparativa da uso de disco para

alocao dos dados de ambos os SGDBs. Os dados apresentados encontra-se em
MegaBytes (MB).
A diferena entre o tamanho das tabelas foi calculada utilizando-se a seguinte
formula: (Tabela com maior tamanho / Tabela com menor tamanho) -1.
Tamanho Total das tabelas
(MB)
Mysql

251,74

LucidDb

145,65

Diferena

72,84%

TABELA 17 - ANLISE COMPARATIVA DA ALOCAO EM DISCO

FIGURA 19 - COMPARATIVO DA ALOCAO DOS DADOS EM DISCO

Conforme podemos observar na tabela 17 e na figura 19, o banco de dados

LucidDB utiliza melhor o disco para alocao dos dados, visto que o banco de dados
Mysql utiliza 72% a mais de espao em disco para alocar os mesmos dados.

51
6.1.5

Desempenho utilizando menos memria RAM

A diferena entre os tempos foi calculada utilizando-se a mesma formula utilizada

anteriormente, na seo 5.1.1 (Resultado com maior tempo / resultado com menor
tempo) -1.

6.1.5.1

Anlise comparativa do desempenho dos bancos com 1000mb de

memria total

A tabela 18 mostra os dados de desempenho dos bancos de dados quando a memria

total do sistema foi reduzida para 1000MB.
Mxima Mnima Mdia
LucidDB 16761

3581

4170

Mysql

23466

24602

28840

Diferena 72,07%

555,29% 589,98%

TABELA 18 - ANLISE COMPARATIVA

DO DESEMPENHO COM 1000MB DE MEMORIA TOTAL

Conforme podemos observar, ambos os bancos de dados tiveram uma piora em sua
performance mxima (4669 e 33033 anteriormente, para os bancos LucidDB e Mysql,
respectivamente).
A figura 20 mostra a evoluo do tempo de resposta ao longo da execuo das
queries. Podemos notar que aps a primeira busca, o tempo de resposta diminui
significativamente e comparvel ao resultado obtido utilizando 1500MB de memria
RAM.

52

FIGURA 20 - ANLISE COMPARATIVA DO DESEMPENHO

COM 1000MB DE MEMRIA TOTAL

6.1.5.2

Anlise comparativa da quantidade de memria livre com 1000mb

de memria total

A tabela 19 mostra os dados referente a quantidade de memria livre(em MB)

obtidos durante a execuo do teste.
Mxima

Mnima

Mdia

LucidDB

342

149

189

Mysql

600

504

546

Diferena 75,44%

238,26% 188,86%

TABELA 19 ANLISE COMPARATIVA

DA MEMRIA LIVRA COM 500MB DE MEMRIA TOTAL

Conforme podemos observar na tabela 19, durante a execuo dos testes pelo banco
de dados Mysql, a quantidade de memria livre maior que a quantidade de memria
livre durante a execuo dos testes no banco LucidDB, conforme tendncia j observada
no item 6.1.3.
A figura 21 nos mostra a diferena entre os bancos de dados graficamente,
ilustrando a grande diferena que existe entre os bancos na utilizao de memria.

53

FIGURA 21- QUANTIDADE DE MEMRIA LIVRE

DURANTE A EXECUO DOS TESTES COM 1000MB DE MEMRIA TOTAL

6.1.5.3

Anlise comparativa do desempenho dos bancos com 500mb de

memria total

A tabela 20 apresenta os dados de desempenho dos bancos de dados quando a

memria foi diminuda para 500MB.
Mxima
LucidDB

30479

Mysql

30961

Mnima
3564

Mdia
4213,15

24104 25366,99

Diferena 101,58% 676,32% 602,09%

TABELA 20 ANLISE COMPARATIVA
DO DESEMPENHO COM 500MB DE MEMRIA TOTAL

Conforme podemos observar na tabela 20, o tempo mximo de resposta do banco

de dados LucidDB teve um aumento considervel, enquanto o tempo mximo do Mysql
sofreu pouca alterao. O tempo mnimo e a mdia de cada banco de dados no
sofreram diferenas significativas.

54

FIGURA 22 - ANLISE COMPARATIVA DO DESEMPENHO

COM 500MB DE MEMRIA TOTAL

Conforme podemos observar na figura 22, o tempo inicial do banco LucidDB foi
superior ao banco de dados Mysql com esta quantidade de memria disponvel ,porem
nas outras buscas os resultados apresentados foram semelhantes a aqueles apresentados
anteriormente.

6.1.5.4

Anlise comparativa da quantidade de memria livre com 1000mb

de memria total

A tabela 21 mostra os dados referente a quantidade de memria livre (em MB)

obtidos durante a execuo do teste.
Mxima
LucidDB
Mysql

Mnima

Mdia

45

20

192

75

118

Diferena 426,67% 3750,00% 602,41%

TABELA 21 ANLISE COMPARATIVA
DA MEMRIA LIVRE COM 500MB DE MEMRIA TOTAL

55
Conforme podemos observar na tabela 21, a quantidade de memria livre durante a
execuo dos testes no banco de dados LucidDB inferior a quantidade de memria
livre durante a execuo do banco relacional, em todos os critrios comparados.
A figura 23 mostra a diferena encontrada na tabela 21 graficamente. Conforme
podemos observar, a diferena do uso de memria entre os bancos muito grande,
conforme j observado anteriormente (itens 6.1.3 e 6.1.5.2)

FIGURA 23- QUANTIDADE DE MEMRIA LIVRE DURANTE A EXECUO DOS

TESTES COM 500BM DE MEMRIA TOTAL

56
7

Consideraes finais

Este trabalho efetuou a anlise comparativa de banco de dados relacionais e NoSQL

na utilizao por aplicaes de Business Intelligence.
Este captulo est dividido como segue: A seo 7.1 apresenta as contribuies e
concluses e a 7.2 apresenta os trabalhos futuros.

7.1

Contribuies e Concluses

As contribuies deste trabalho so:

a) Estudo comparativo do desempenho dos bancos de dados LucidDB e Mysql
com diferentes quantidades de memria RAM disponveis, durante
consultas utilizadas por aplicaes de Business Intelligence.
b) Comparao da utilizao de CPU pelos bancos de dados LucidDB e Mysql
durante consultas utilizadas por aplicaes de Business Intelligence.
c) Comparao da quantidade de memria utilizada pelos bancos de dados
LucidDB e Mysql durante consultas utilizadas por aplicaes de Business
Intelligence.
d) Comparao do espao em disco utilizado pelos bancos de dados Mysql e
LucidDB para alocao dos mesmos dados.
A partir destas contribuies, pode-se concluir que:
a)

O banco de dados LucidDB apresenta um melhor desempenho que o

banco de dados Mysql no caso de teste estudado.

b)

O banco de dados Mysql utiliza uma menor quantidade de memria

RAM que o banco de dados LucidDB, e que ambos trabalham bem com pouca
memria.
c)

Ambos os bancos de dados utilizam a capacidade mxima de CPU

disponvel, no havendo diferena nesse quesito.

d)

O banco de dados LucidDB armazena os dados em disco de forma mais

eficiente, pois possui uma menor alocao de disco para os mesmos dados.

57
As seguintes experincias foram obtidas:
a)

Criao e configurao de ambiente virtual.

b)

Instalao, configurao e utilizao de um banco de dados sem interface

grfica (LucidDB)
c)

7.2

Utilizao dos metadados dos bancos de dados Mysql e LucidDb

Trabalhos Futuros

As contribuies alcanadas com este Trabalho no encerram as pesquisas

relacionadas a comparao de bancos de dados Relacionais e NoSQL, mas abrem
oportunidades para alguns trabalhos futuros:
a) Comparao de outras bases de dados
b) Comparao utilizando um hardware mais potente
c) Comparao do banco de dados NoSQL na utilizao em aplicaes que
no seja de Business Intelligence.
d) Comparao dos bancos em outros sistemas operacionais (Linux, Solaris)

58
8

Referencias Bibliogrficas

Bouman, R.; Dongen, J. V. Pentaho Solutions.

WileyPublishing,Inc, 2009. ISBN 978-0-470-48432-6.

1st.

ed.

Indianapolis:

WCS: Wide-Columns-Sore. 2010. Disponvel em: <http://bluesoft.wordpress.com/tag/

wide-columns-store/>. Acesso em: 24 maio. 2011.
Cattel, R. Relational Databases, Object Databases, Key-Value Stores, Document Stores,
and Extensible Record Stores: A Comparison. ODBMs. 2010. Disponvel em
<http://www.odbms.org/download/Cattell.Dec10.pdf>. Acesso em: 12 jun. 2011.
Chang, F; Dean, J; Ghemawatt, S; Hsieh, W C B;, Deborah A. W. M; Chandra, T;
Fikes, A Gruber, R. E. Bigtable: A Distributed Storage System for Structured Data,
2006. - OSDI '06 Proceedings of the 7th USENIX Symposium on Operating Systems
Design and Implementation - Volume 7
Codd, E. F. A relational model of data for large shared data Banks. Comunications of
the ACM, v.13, e.6, Junho 1970.
CPMBC: Cloudera presents the MapReduce bull case. 2009. Disponvel em:
<http://www.dbms2.com/2009/04/15/cloudera-presents-the-mapreduce-bull-case/>.
Acesso em: 24 maio. 2011.
FHH:
Facebook,
Hadoop,
and
Hive.
2009.
Disponvel
em:
<http://www.dbms2.com/2009/05/11/facebook-hadoop-and-hive/>. Acesso em: 24 maio
2011.
HLIP:
How
Large
Is
a
Petabyte.
2009.
Disponvel
<http://gizmodo.com/5309889/what-is-a-petabyte/>. Acesso em: 24 maio. 2011.

em:

Horowitz, M. L. An Introduction to Object-Oriented Databases and Databases Systems,

1991. Disponvel em: <http://reports-archive.adm.cs.cmu.edu/anon/itc/CMU-ITC103.pdf>. Acesso em: 24 maio. 2011.
JMeter, 2011. Disponvel em: <http://jakarta.apache.org/jmeter/>. Acesso em: 17 jul.
2011.

59

Kimball, R.; Ross, M. The Data WareHouse Toolkit. 2 Edio. New York: Wiley
Computer Publishing, 2002. ISBN 0-471-20024-7.
Leavitt, N. Will NoSQL Databases Live Up to Their Promise? 2010. Computer, 12.
ISSN: 0018-9162, pg. 12 14
LucidDB, 2011. Disponvel em <http://www.luciddb.org/>. Acesso em: 24 maio. 2011.
Machado, F. N.R. Banco de dados: Projeto e implementao. Brasil: Editora Erica,
2008. ISBN 978-85-365-0019-5.
Microsoft,
2011.
Disponvel
em
<http://technet.microsoft.com/ptbr/library/cc749154(WS.10).aspx/>. Acesso em: 17 jul. 2011.
Mynosql. 2010. Disponvel em <http://nosql.mypopescu.com/post/407159447/
cassandra-twitter-an-interview-with-ryan-king/>. Acesso em: 24 maio, 2011.
Mysql, 2011. Disponvel em; <http://www.mysql.com/why-mysql/white-papers/>.
Acesso em: 24 maio. 2011.
NVRSDQEF: NoSQL, voc realmente sabe do que estamos falando?, 2010. Disponvel
em
<http://imasters.com.br/artigo/17043/
bancodedados/nosql_voce_realmente_sabe_do_que_estamos_falando/>. Acesso em: 24
maio. 2011.
Sieera, J. L; Fernndes-Valmayor, A.; Fernndes-Majon, B.; Navarro, A.. ADDS: A
Document-Oriented Approach for Application Development. Journal of Universal
Computer Science, Volume 10, pages 1302-1324, 2004.
Silberschatz, A.; Korth, H.. F., Sudarshan, S. Sistema de banco de dados, Rio de
Janeiro: Editora Elsevier, 2006. ISBN: 978-85-352-1107-8.
Stonebraker, M.; Abadi, D. J.; Batkin, A.; Chen, X; Cherniack, M.; Ferreira, M.; Lau,
E.; Lin, A.; Madden, S.; ONeil, E.; ONeil, P.; Rasin, A.; Tran, N.;Zdonik, S. C-Store:
A Column-oriented DBMS. 2005 - VLDB '05 Proceedings of the 31st international
conference on Very large data bases. ISBN:1-59593-154-6

60
MT10AADW: My Top 10 Assertions About Data Warehouses, 2010. Disponvel em
<http://cacm.acm.org/blogs/blog-cacm/98136-my-top-10-assertions-about-datawarehouses/fulltext/> Acesso em: 24 maio. 2011.
Teradata,
2008.
Disponvel
em:
<http://www.teradata.com/t/newsrelease.aspx?id=6375/>. Acesso em: 24 maio. 2011.
Termehchy, A.; Winslett, M. Keywords Search Over Key-Value Stores. ACM, 2010.
ISBN: 978-1-60558-799-8.
Vercellis, C. Bussiness Intelligence: Data mining and Optimization for Decision
Making, 1 Edio. John Wiley & Sons Ltd, 2009. ISBN978-0-470-51138-1
VirtualBox, 2011. Disponvel em: <http://www.virtualbox.org/> Acesso em 10 jul.
2011.
Williams, Steve. Williams, Nancy. The profit impacto of Business Intelligence.
Morgan Kaufmann Publishers, 2007. ISBN-13:978-0-12-372499-1
WNM: Whats New in MySQL 5.5: Performance and Scalability. Disponvel em
<http://www.mysql.com/why-mysql/white-papers/mysql-wp-whatsnew-mysql-55.php>
Acesso em: 10 jul. 2011.

61
9

9.1

Apndice

Apndice 1: Tabelas do modelo de dados

Tabela dim_time: a tabela dimensional que possui os registros com todas as horas
existentes em um dia.
Tabela dim_date: a tabela dimensional que possui os dados de datas (sem hora),
que alem de possuir a data em si, possui dados adicionais, como se feriado, se final
de semana, o ano fiscal, etc.
Tabela dim_customer: a tabela dimensional onde so armazenados os dados dos
consumidores da aplicao.
Tabela dim_order_status: a tabela dimensional que armazena os possveis estados
dos pedidos dos clientes.
Tabela dim_promotion: a tabela dimensional que armazena os dados referentes as
promoes criadas pela empresa WCM.
Tabela dim_warehouse: a tabela dimensional onde ficam armazenados os dados
sobre os armazns da WCM.
Tabela dim_website: a tabela dimensional onde ficam armazenados os dados
sobre os vrios sites que compem a aplicao WCM.
Tabela dim_dvd_release: a tabela dimensional onde ficam armazenados os dados
sobre os DVDs que so comercializados pela WCM.
Tabela dim_demography: a tabela dimensional que relaciona o grupo
demogrfico que um determinado cliente faz parte. Exemplo: entre 15 e 20 anos de
idade, do sexo masculino e que ganha

entre 10.000 e 20.000 dolres por ano (este

um registro da tabela). utilizada para separar os clientes em grupos.

Tabela dim_zipcensus: a tabela dimensional que armazena os dados dos cdigos
postais (os ceps dos clientes) e os dados de localizao destes locais.
Tabela fact_orders: a tabela onde ficam armazenados os dados das
locaes/compras dos clientes, e o contexto (dimenses) que estas compras ocorreram.

62
9.2

Apendice 2: Scrips das buscas efetuadas nos bancos de dados

Seguem abaixo as questes que o bancos de dados deveriam responder e os scripts

utilizados para execuo das mesmas:
Qual gnero de filme gerou mais receitas no ano de 2008?
select sum(fo.revenue), ddr.dvd_release_genre, dd.year4
from fact_orders fo, dim_dvd_release ddr, dim_date dd
where fo.local_order_date_key=dd.date_key and
fo.dvd_release_key=ddr.dvd_release_key and dd.year4='2008'
group by dd.year4, ddr.dvd_release_genre;
Como o lucro est evoluindo com o tempo?
select sum(fc.revenue), dd.year4 from fact_orders fc, dim_date dd
where fc.local_order_date_key=dd.date_key
group by dd.year4
order by dd.year4;
Qual horrio do dia os consumidores fazem mais locaes?
select sum(fc.revenue), dt.time_hour from fact_orders fc, dim_time dt
where fc.local_order_time_key=dt.time_key
group by dt.time_hour
order by dt.time_hour;
Quo efetivas foram as promoes no ano de 2008?
select sum(fc.revenue), dp.promotion_key
from fact_orders fc, dim_promotion dp, dim_date dd
where fc.promotion_key=dp.promotion_key
and fc.local_order_date_key=dd.date_key
and dd.year4='2008'
group by dp.promotion_key
order by dp.promotion_key;