FACULDADE FORTIUM
SISTEMAS DE INFORMAÇÃO
MAGDIEL DOS SANTOS PEREIRA
UMA ANÁLISE COMPARATIVA DE DESEMPENHO ENTRE O SGBD MYSQL E
POSTGRESQL
Brasília-DF
2013
FACULDADE FORTIUM
SISTEMAS DE INFORMAÇÃO
MAGDIEL DOS SANTOS PEREIRA
UMA ANÁLISE COMPARATIVA DE DESEMPENHO ENTRE O SGBD MYSQL E
POSTGRESQL
Monografia apresentada à Faculdade Fortium
como requisito parcial para obtenção do grau
de Bacharel em Sistemas de Informação.
Orientador: Prof. José Wellington Cunha da
Silva
FICHA CATALOGRAFICA AKI NO VERSO
Brasília-DF
2013
MAGDIEL DOS SANTOS PEREIRA
UMA ANÁLISE COMPARATIVA DE DESEMPENHO ENTRE O SGBD MYSQL E
POSTGRESQL
Esta monografia foi julgada adequada para
obtenção do Grau de Bacharel no Curso de
Sistemas de Informação da Faculdade Fortium e
aprovada em sua forma final em 18 de Maio de
2013.
___________________________________________________________________________
Prof. Msc. José Wellington Cunha da Silva (Orientador)
___________________________________________________________________________
Prof. Wellington Moreira
___________________________________________________________________________
Prof. Edeuzane de Fátima Pereira da Silva Steinmetz
Brasília-DF
2013
Dedicatória
Dedico esse trabalho a minha família que me concedeu um alicerce forte o bastante para
superar mais uma etapa de minha vida.
Em especial a minha esposa Eliete e ao nosso presente de Deus, Maria Clara.
AGRADECIMENTOS
A Deus, por ter me concedido saúde para concluir esse trabalho com êxito.
Aos meus amigos de faculdade que de forma direta ou indireta me auxiliaram nessa
caminhada.
Aos meus pais, por terem me ensinado os caminhos da vida.
A minha esposa por ter compreendido minhas ausências nas madrugadas para que eu pudesse
concluir essa etapa importante de minha vida.
Aos amigos Diego, Helyedo e Marquinho que também contribuíram de alguma maneira para
o desenvolvimento desse trabalho.
"Se você conta com alguém que tem menos qualidades que você, isso levará à sua
degeneração. Se você conta com alguém com qualidades iguais às suas, você permanece onde
está.
Somente quando conta com alguém cujas qualidades são superiores às suas é que você atinge
uma condição sublime."
Dalai Lama
RESUMO
Esse trabalho de conclusão apresenta algumas características dos SGBDs MySQL e
PostgreSQL, além de realizar uma análise comparativa de desempenho entre eles, utilizando
os comandos de Linguagem de Manipulação de dados (DML), (insert, update, delete, select).
Para isso partiu-se da hipótese de que o SGBD MySQL possui melhor desempenho na
execução desses comandos. Os registros utilizados para alimentar as bases de dados foram
gerado com a utilização da ferramenta datagenerator, um script de código aberto escrito em
Java Script, PHP e MySQL utilizado para gerar grande massa de dados personalizados. O
teste de desempenho foi realizado em máquina virtualizada, sendo uma para cada SGBD, com
Windows 7 Home Premium 32 bits, logo após foi instalado o SGBD MySQL em uma
máquina e o PostgreSQL na outra, onde foram realizados os testes de laboratório. O
desempenho dos SGBDs foi analisado através da coleta de tempo que cada SGBD, atingiu
para concluir os testes de DML, aplicado em ambos, esses testes foram realizados 3 vezes
seguidas e logo após tirado uma média, as telas desses testes encontram nos apêndices B, C, D
e E desse trabalho, com intuito de torna-lo mais fidedigno. Esses testes foram aplicados em
uma modelagem de dados retirados de um projeto de sistema gerenciador de demandas
recebidas via email, que tem o objetivo de armazenar e distribuir demandas recebidas via
email no âmbito de uma secretaria. Ressaltando ainda que esses testes foram realizados em
ambiente controlado, e aplicados a uma modelagem de dados específica, podendo sofrer
alterações se aplicados, por exemplo, em outro sistema operacional ou mesmo em uma
máquina não virtualizada. Após a análise dos devidos testes de DML chegou-se a conclusão
de que o Banco de dados PostgreSQL é o que possui um melhor desempenho em relação ao
MySQL, levando com isso a refutação da hipótese inicialmente levantada.
Palavras-chave: MySQL. PostgreSQL. SGBD. DML. Análise. Comparativa. Desempenho.
ABSTRACT
This report presents some characteristics of the SGBDs MySQL and PostgreSQL software,
and compares their performance, utilizing the data manipulation language commands (DML),
such as insert, update, delete, select. To do this, the hypothesis that the SGBD MySQL has
better performance than the PostgreSQL in the execution of these commands was
assumed.The records used to feed the data bases were generated by using the datagenerator
tool, an open-code script written by Java Script, PHP and MySQL that generate a great mass
of personalized date.The performance test was accomplished by a virtualized machine, having
one for each SGBD, with Windows 7 Home Premium 32 Bits. Later, the SGBD MySQL was
installed in a machine and the PostgreSQL in the other and the lab tests took place. The
SGBD’s performance was analyzed by measuring the time period in which each SGBD took
to conclude the DML test. For both softwares, the average of the time periods of three
consecutive trials was taken. The screen of the trials are attached to the appendices B, C, D,
and E with the intent to make the report more complete. The data models for these tests were
taken from a project of system management of the demands received via email, with the goal
in to store and distribute on a secretary environment.It is important to emphasize that the
tests mentioned were done in a controlled environment, and applied to a specific data model,
and may change, for example, in other operational systems or even in non-virtual machines.
After the analysis of the DML tests, the conclusion reached was that the PostgreSQL’s data
base has a better performance when compared to MySQL’s data base, denying the initial
hypothesis.
Key Words: MySQL. PostgreSQL. SGBD. DML. Analysis. Comparative. Performance.
LISTA DE ABREVIATURAS E SIGLAS
ACID – Atomicity, Consistency, Isolation, Durability - Atomicidade, Consistência e
Durabilidade.
ANSI – American National Standards Institute – Organização Nacional Americana de
Padrões.
API – Application Programming Interface – Interface de Programação de Aplicativos.
DBA – Database Administrator – Administrador de Banco de Dados.
DCL – Data Control Language – Linguagem de Controle de Dados.
DDL – Data Definition Language – Linguagem de Definição de Dados.
DER – Diagrama de Entidade Relacional.
DML – Data Manipulation Language – Linguagem de Manipulação de Dados.
IPC - Interprocess communication – Comunicação Entre Processos.
MER – Modelo de Entidade – Relacionamento.
MR – Modelo Relacional.
SBD – Sistema de Banco de Dados.
SGBD – Sistema Gerenciador de Banco de Dados.
SGBDR – Sistema de Gerenciador de Banco de Dados Relacional.
SQL – Structured Query Language – Linguagem Estruturada de Consultas.
.
LISTA DE FIGURAS
Figura 1 - Arquitetura de três Esquemas ............................................................................... 21
Figura 2 - Componentes do Sistema de Banco de Dados ...................................................... 22
Figura 3 - Modelo de Entidade Relacionamento (MER) ....................................................... 24
Figura 4 - Exemplo de Relacionamento................................................................................ 25
Figura 5 - Relacionamento 1:1 ............................................................................................. 26
Figura 6 - Relacionamento 1:N ............................................................................................ 26
Figura 7 - Relacionamento N:N............................................................................................ 26
Figura 8 - Exemplo Chave Primária ..................................................................................... 27
Figura 9 - Exemplo Chave Estrangeira ................................................................................. 28
Figura 10 - Tabela Funcionário ............................................................................................ 31
Figura 11 - Tabela Terceira Forma Normal .......................................................................... 31
Figura 12 - Create Table ...................................................................................................... 34
Figura 13 - Drop Table......................................................................................................... 34
Figura 14 - Alter Table......................................................................................................... 34
Figura 15 - Select ................................................................................................................. 35
Figura 16 - Update ............................................................................................................... 36
Figura 17 - Insert ................................................................................................................. 36
Figura 18 - Delete ................................................................................................................ 36
Figura 19 - Grant ................................................................................................................. 37
Figura 20 - Revoke .............................................................................................................. 37
Figura 21 - Arquitetura MySQL ........................................................................................... 41
Figura 22 - Arquitetura PostgreSQL ..................................................................................... 45
Figura 23 - Quadro Comparativo com algumas características do MySQL e PostgreSQL .... 46
Figura 24 - Configuração do ambiente de teste ..................................................................... 51
Figura 25 - Ambiente de teste virtualizado com dois Sistemas Operacionais Windows 7 ...... 51
Figura 26 - Configuração máquina virtual com o SGBD MYSQL ........................................ 52
Figura 27 - Configuração máquina virtual com o SGBD POSTGRESQL ............................. 52
Figura 28 - Modelo Lógico .................................................................................................. 53
Figura 29 - Script de Criação das Tabelas............................................................................. 54
Figura 30 - Códigos SQL utilizados nos testes de Select....................................................... 56
Figura 31 - Códigos SQL utilizados nos testes de Update..................................................... 57
Figura 32 - Códigos SQL utilizados nos testes de Delete ...................................................... 58
Figura 33 – Fórmula para calcular a diferença percentual entre dois valores ......................... 60
LISTA DE TABELAS
Tabela 1 - Quantidade de registros inseridos na tabela TB_PERFIL_USUARIO, no SGBD
MySQL ................................................................................................................................ 60
Tabela 2 - Quantidade de registros inseridos na tabela TB_PERFIL_USUARIO, no SGBD
PostgreSQL ......................................................................................................................... 60
Tabela 3 - Diferença percentual no quesito inserção na TB_PERFIL_USUARIO, nos SGBDS
MySQL e PostgreSQL ......................................................................................................... 61
Tabela 4 - Quantidade de registros inseridos na tabela TB_SETOR, no SGBD MySQL ....... 61
Tabela 5 - Quantidade de registros inseridos na tabela TB_SETOR, no SGBD PostgreSQL . 61
Tabela 6 - Diferença percentual no quesito inserção na TB_SETOR, nos SGBDS MySQL e
PostgreSQL ......................................................................................................................... 61
Tabela 7 - Quantidade de registros inseridos na tabela TB_PRIORIDADE_DEMANDA, no
SGBD MySQL .................................................................................................................... 62
Tabela 8 - Quantidade de registros inseridos na tabela TB_PRIORIDADE_DEMANDA, no
SGBD PostgreSQL .............................................................................................................. 62
Tabela 9 - Diferença percentual no quesito inserção na TB_PRIORIDADE_DEMANDA, nos
SGBDS MySQL e PostgreSQL ............................................................................................ 62
Tabela 10 - Quantidade de registros inseridos na tabela TB_STATUS_DEMANDA, no
SGBD MySQL .................................................................................................................... 62
Tabela 11 - Quantidade de registros inseridos na tabela TB_STATUS_DEMANDA, no
SGBD PostgreSQL .............................................................................................................. 63
Tabela 12 - Diferença percentual no quesito inserção na TB_STATUS_DEMANDA, nos
SGBDS MySQL e PostgreSQL ............................................................................................ 63
Tabela 13 - Quantidade de registros inseridos na tabela TB_UF, nos SGBD MySQL ........... 63
Tabela 14 - Quantidade de registros inseridos na tabela TB_UF, nos SGBD PostgreSQL ..... 63
Tabela 15 - Diferença percentual no quesito inserção na TB_UF, nos SGBDS MySQL e
PostgreSQL ......................................................................................................................... 64
Tabela 16 - Quantidade de registros inseridos na tabela TB_USUARIO, no SGBD MySQL 64
Tabela 17 - Quantidade de registros inseridos na tabela TB_USUARIO, no SGBD
PostgreSQL ......................................................................................................................... 64
Tabela 18 - Diferença percentual no quesito inserção na TB_USUARIO, nos SGBDS MySQL
e PostgreSQL ....................................................................................................................... 65
Tabela 19 - Quantidade de registros inseridos na tabela TB_DEMANDA, no SGBD MySQL
............................................................................................................................................ 66
Tabela 20 - Quantidade de registros inseridos por lote na tabela TB_DEMANDA, no SGBD
PostgreSQL ......................................................................................................................... 67
Tabela 21 - Diferença em percentual de cada lote da tabela tb_demanda por SGBD ............. 68
Tabela 22 - Quantidade de registros inseridos na tabela TB_RESPONSAVEL, no SGBD
MySQL ................................................................................................................................ 70
Tabela 23 - Quantidade de registros inseridos na tabela TB_RESPONSAVEL, no SGBD
PostgreSQL ......................................................................................................................... 70
Tabela 24 - Diferença percentual no quesito inserção na TB_RESPONSAVEL, no SGBD
MySQL ................................................................................................................................ 70
Tabela 25 - Quantidade de registros inseridos na tabela TB_HISTORICO_DEMANDA no
SGBD MySQL .................................................................................................................... 71
Tabela 26 - Quantidade de registros inseridos na tabela TB_HISTORICO_DEMANDA, no
SGBD PostgreSQL .............................................................................................................. 71
Tabela 27 - Diferença percentual de cada lote da TB_HISTORICO_DEMANDA, por SGBD
............................................................................................................................................ 71
Tabela 28 - Quantidade de registros pertencentes a cada tabela nos SGBDs ......................... 73
Tabela 29 - Tempo total de Inserção dos dados nos SGBDS, por tabela .............................. 73
Tabela 30 – Tempo dos testes de Updates no SGBD MySQL .............................................. 76
Tabela 31 - Tempo dos testes de Updates no SGBD PostgreSQL ......................................... 76
Tabela 32 – Diferença percentual nos teste de Update .......................................................... 76
Tabela 33 – Tempo dos testes de Deletes no SGBD MySQL ................................................ 78
Tabela 34 - Tempo dos testes de Deletes no SGBD PostgreSQL .......................................... 78
Tabela 35 – Diferença percentual nos testes de Delete.......................................................... 79
Tabela 36 - Tempo dos testes de Select no SGBD MySQL ................................................... 80
Tabela 37 - Tempo dos testes de Select no SGBD PostgreSQL............................................. 81
Tabela 38 – Diferença percentual nos testes de Select .......................................................... 81
Tabela 39 - Tabela com resultado de todos os testes realizados ............................................ 85
LISTA DE GRÁFICOS
Gráfico 1- Inserção de Registros na Tabela TB_USUARIO por lotes nos SGBDS MySQL e
PostgreSQL ......................................................................................................................... 65
Gráfico 2 - Inserção de Registros na Tabela TB_DEMANDA por lotes nos SGBDS MySQL e
PostgreSQL ......................................................................................................................... 69
Gráfico 3 - Inserção de Registros na Tabela TB_HISTORICO_DEMANDA por lotes nos
SGBDS MySQL e PostgreSQL ............................................................................................ 72
Gráfico 4 - Resultado dos testes de Insert nos SGBDS MySQL e PostgreSQL ..................... 74
Gráfico 5 - Gráfico de Inserts nos SGBDS, em menor escala. .............................................. 75
Gráfico 6 - Resultado dos testes de Update .......................................................................... 77
Gráfico 7 - Resultado dos testes de Delete ............................................................................ 79
Gráfico 8 - Resultado dos testes de Consultas ...................................................................... 82
Gráfico 9 - Resultado geral dos testes realizados .................................................................. 85
SUMÁRIO
1.
INTRODUÇÃO ....................................................................................................... 15
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
TEMA ..................................................................................................................... 16
OBJETIVO GERAL............................................................................................... 16
OBJETIVOS ESPECIFICOS ................................................................................ 16
PROBLEMA ........................................................................................................... 16
HIPÓTESE ............................................................................................................. 17
JUSTIFICATIVAS ................................................................................................. 17
CONTEXTUALIZAÇÃO DA PESQUISA ............................................................ 18
ESTRUTURA DO TRABALHO ............................................................................ 18
2.
REFERENCIAL TEÓRICO................................................................................... 19
2.1
BANCO DE DADOS .................................................................................................... 19
2.1.1 Arquitetura de Banco de Dados ............................................................................... 20
2.1.2 Sistema de banco de dados....................................................................................... 21
2.1.3 Sistema gerenciador de Banco de dados - SGBD..................................................... 22
2.2
MODELO ENTIDADE-RELACIONAMENTO ................................................... 23
2.3
MODELO RELACIONAL..................................................................................... 25
2.3.1 Chaves Primárias e Chaves Estrangeiras ................................................................ 27
2.3.2 Restrições do Modelo Relacional ............................................................................. 28
2.3.3 Gerenciamento de Transações ................................................................................. 29
2.4
NORMALIZAÇÃO ................................................................................................ 29
2.4.1 Primeira Forma Normal .......................................................................................... 30
2.4.2 Segunda Forma Normal .......................................................................................... 30
2.4.3 Terceira Forma Normal .......................................................................................... 30
2.5
PADRÃO SQL ........................................................................................................ 31
2.5.1 Descrição ................................................................................................................. 32
2.5.2 Histórico SQL .......................................................................................................... 32
2.5.3 Comandos DDL ....................................................................................................... 33
2.5.3.1 Create Table ............................................................................................................ 33
2.5.3.2 Drop Table ............................................................................................................... 34
2.5.3.3 Alter table ................................................................................................................ 34
2.5.4 Comandos DML....................................................................................................... 35
2.5.4.1 Select ....................................................................................................................... 35
2.5.4.2 Update ..................................................................................................................... 35
2.5.4.3 Insert ....................................................................................................................... 36
2.5.4.4 Delete ....................................................................................................................... 36
2.5.5 Comandos DCL .......................................................................................................... 37
2.6
BANCO DE DADOS MYSQL ................................................................................ 37
2.6.1 Histórico ..................................................................................................................... 38
2.6.2 Descrição .................................................................................................................... 39
2.6.3 Características ............................................................................................................ 40
2.6.4 Arquitetura .............................................................................................................. 40
2.7
2.7.1
2.7.2
2.7.3
2.7.4
BANCO DE DADOS POSTGRESQL .................................................................... 42
Histórico .................................................................................................................. 42
Descrição ................................................................................................................. 43
Características ......................................................................................................... 44
Arquitetura .............................................................................................................. 45
3.
MATERIAL E MÉTODOS .................................................................................... 48
3.1
3.2
3.3
3.4
3.5
CLASSIFICAÇÃO DA PESQUISA ................................................................................. 48
PRINCIPAIS FONTES DE PESQUISA ............................................................................ 49
ETAPAS DA PESQUISA ............................................................................................... 49
DIFICULDADES ENCONTRADAS NA PESQUISA ........................................................... 49
AMBIENTE DE TESTE ................................................................................................ 50
4.
RESULTADOS E ANÁLISES ................................................................................ 59
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
RESULTADO ......................................................................................................... 59
RESULTADOS DOS TESTES DE INSERÇÃO ..................................................... 59
RESULTADOS DOS TESTES DE UPDATE.......................................................... 75
RESULTADOS DOS TESTES DE DELETE .......................................................... 77
RESULTADOS DOS TESTES DE SELECT .......................................................... 80
ANÁLISE ................................................................................................................ 82
ANÁLISE TESTES DE INSERÇÃO ....................................................................... 83
ANÁLISE TESTES DE UPDATE ........................................................................... 83
ANÁLISE TESTES DE DELETE ........................................................................... 84
ANÁLISE TESTE DE SELECT .............................................................................. 84
ANÁLISE GERAL................................................................................................... 84
5.
CONCLUSÃO ......................................................................................................... 87
REFERÊNCIAS ................................................................................................................. 89
APÊNDICE A – AMOSTRA DOS SCRIPTS UTILIZADOS PARA INSERÇÃO DE
DADOS NOS SGBDS ........................................................................................................ 93
APÊNDICE B – PRINT DOS INSERTS DAS TELAS DOS SGBDS MYSQL E
POSTGRESQL .................................................................................................................. 98
APÊNDICE C - PRINT DOS TESTES DE UPDATES REALIZADOS NOS SGBDS
MYSQL E POSTGRESQL.............................................................................................. 175
APÊNDICE D – PRINT DOS TESTES DE DELETE NOS SGBDS MYSQL E
POSTGRESQL ................................................................................................................ 187
APÊNDICE E – PRINT DOS TESTES DE SELECT NOS SGBDS MYSQL E
POSTGRESQL ................................................................................................................ 196
APÊNDICE F – CD COM OS REGISTROS UTILIZADOS PARA INSERÇÃO DE
DADOS NAS TABELAS ................................................................................................. 208
15
1.
INTRODUÇÃO
O tema apresentado neste trabalho é: Uma análise comparativa de desempenho entre
os bancos de dados MySQL e PostgreSQL .
Com o mercado de trabalho cada vez mais competitivo, as empresas estão sempre à
procura de inovações tecnológicas, principalmente quando se deparam com um crescimento
razoável de informações, quantidade de funcionários, clientes, entre outras atividades que
possa vir a se desenvolver na empresa. Diante desse fato, se torna indispensável à escolha de
um SGBD, que lhe forneça segurança e, principalmente, rapidez na captura dessas
informações quando necessário.
O escopo desse trabalho apresenta dois sistemas gerenciadores de banco de dados: o
MySQL, da empresa Oracle Corporation; e o PostgreSQL que diferente do MySQL não
pertence a nenhuma empresa, sendo mantido por instituições nacionais e internacionais, e
administrado pelo Grupo Global do PostgreSQL.
A análise tem como objetivo identificar alguns conceitos inerentes destes SGBDs, e
principalmente realizar o teste de desempenho, utilizando os comandos DML, através da
linguagem SQL (Structured Query Language), em um ambiente virtualizado, utilizando o
Sistema Operacional Windows 7 Home Premium 32 bits.
Aqui, o objetivo geral não é mostrar qual sistema de banco de dados é melhor em
termos absoluto, mas sim realizar um teste de desempenho entre eles, utilizando diferentes
cargas de dados, nos comandos de DML, verificando seus tempos de resposta para aferir qual
banco obteve o menor tempo na execução dos testes.
Assim, esta pesquisa partirá do seguinte problema: Qual SGBD possui melhor
desempenho na execução dos comandos DML?
A solução do problema supracitado partirá da seguinte hipótese: O SGBD MySQL
possui melhor desempenho em relação ao PostgreSQL.
O trabalho visa almejar 03 (três) objetivos específicos:
- Identificar algumas características dos bancos de dados MySQL e PostgreSQL;
- Realizar um teste de desempenho em laboratório utilizando a linguagem SQL,
quanto à execução de comandos DML (inserção, inclusão, alteração e Exclusão);
- Analisar o tempo de resposta desses comandos.
16
1.1
TEMA
O tema abordado é: Uma análise comparativa de desempenho entre os bancos de
dados MySQL e PostgreSQL, quanto à execução de comandos DML (inserção, atualização
exclusão e consultas).
1.2
OBJETIVO GERAL
Esse trabalho de conclusão tem como objetivo realizar uma análise comparativa de
desempenho entre os bancos de dados PostgreSQL e MySQL, utilizando diferentes cargas de
dados, no que diz respeito à execução dos comandos de exclusão, alteração e inserção, e
consultas, aplicados em uma modelagem de dados padronizada e utilizada em ambos SGBDs,
elaborada para controlar o fluxo de demandas recebidas vias e-mail no âmbito de uma
secretaria.
1.3
OBJETIVOS ESPECIFICOS
Os objetivos específicos são:
- Identificar algumas características dos bancos de dados MySQL e PostgreSQL;
- Realizar um teste de desempenho em laboratório utilizando a linguagem SQL,
quanto à execução de comandos DML (inserção, inclusão, alteração e Exclusão)
- Analisar o tempo de resposta desses comandos.
1.4
PROBLEMA
Quando se é elaborado um estudo com o intuito de realizar uma escolha entre dois
SGBD como MYSQL E POSTGRESQL, surge o problema: saber qual deles possui melhor
17
desempenho na realização dos comandos delete, update, insert e select, quando aplicados a
esse modelo lógico de um Sistema Gerenciador de Demandas?
Com o intuito de sanar o problema, se fez necessária à realização de uma pesquisa
que permitisse avaliar qual SGBD, possui melhor desempenho na execução dos testes de
DML.
1.5
HIPÓTESE
Para que pudesse oferecer uma solução ao problema citado no tópico anterior, de
acordo com artigo divulgado pela DEVMEDIA 2013, a vantagem do MYSQL em relação ao
PostgreSQL é a velocidade de acesso que nem sempre é perceptível, pois está na escala de
milésimos de segundos.
Este trabalho de conclusão apresenta a hipótese de que o MySQL possui melhor
desempenho em relação ao PostgreSQL, de acordo com o site divulgado no Devmedia, citado
no parágrafo anterior.
1.6
JUSTIFICATIVAS
À medida que o volume de dados e informações cresce em uma empresa, percebe-se
o quanto é importante à escolha de como armazená-las e gerenciá-las, principalmente quando
a demora de coleta dessas informações geram prejuízos ou são realizadas de maneira
incorreta, nota-se a necessidade da existência de banco de dados na empresa. (GULUTZAN,
PELZER, 2002).
Este estudo tem o intuito de auxiliar na escolha de um SGBD capaz de suprir as
necessidades do software, e que atenda um dos principais quesitos em um SGBD: o
desempenho. Surgiu-se, então, a necessidade de desenvolver esse trabalho acadêmico para
auxiliar na escolha do SGBDs (MySQL, PostgreSQL), no que diz respeito ao modelo lógico
18
utilizado, que tem a finalidade de controlar demandas recebidas via email e distribuir aquém
lhe for de direito, além de armazena-las para futuras consultas caso seja necessário.
1.7
CONTEXTUALIZAÇÃO DA PESQUISA
A pesquisa é realizada em laboratório utilizando um Notebook com sistema
operacional Windows7 Ultimate 64 bits e mais dois sistemas Operacional Windows 7 Home
Premium 32 bits, virtualizado com a utilização da ferramenta VirtualBox (versão 4.2.4) e
instalados os bancos de dados MySQL (versão 5.5) e PostgreSQL (versão 8.3.3), um em cada
máquina virtual.
1.8
ESTRUTURA DO TRABALHO
O trabalho de conclusão de curso apresenta-se divido em cinco capítulos.
No segundo capítulo será abordado o material de pesquisa utilizado na elaboração
do trabalho, onde serão apresentadas algumas características dos SGBDS MySQL e
PostgreSQL, bem como conceitos da linguagem SQL, Modelo Relacional, Normalizações,
Comandos SQL.
São descritos no terceiro capítulo, as ferramentas utilizadas para realização da
comparação entre os banco de dados MySQL e PostgreSQL.
No quarto capítulo são deparados os resultados e análises da pesquisa realizada, e
uma análise separada desses resultados, para facilitar a compreensão e por fim, uma análise
detalhada para cada teste realizado e uma geral, com o objetivo de identificar qual SGBD
obteve melhor desempenho nos testes aplicados.
O quinto capítulo por sua vez, apresenta a conclusão do trabalho realizado,
discorrendo se os objetivos relatados foram alcançados e se as hipóteses foram aceitas ou
refutadas.
19
Neste primeiro capítulo, foram listados a introdução, tema, objetivos, problemas,
hipóteses, temas, e estrutura do trabalho.
No próximo capítulo, trataremos do referencial teórico, uma parte importante da
monografia aonde será apresenta o embasamento do trabalho acadêmico.
2.
REFERENCIAL TEÓRICO
Esse capítulo apresentará os métodos utilizados para o embasamento da comparação
de desempenho realizada com os SGBDs MySQL e PostgreSQL, com consultas realizadas em
base de dados utilizando os mesmos mecanismos de consulta para ambos os SGBDS.
2.1
Banco de Dados
De acordo com Navathe e Elmasri (2005) banco de dados é uma coleção de dados
relacionados, ou seja, informações que possuem algum significado possam ser registradas e
por fim manipulados.
“De modo geral, os dados de um banco de dados – pelo menos, em um sistema de
grande porte – estarão integrados e também compartilhados. Integrados porque o
banco de dados pode ser considerado como uma unificação de vários arquivos, de
outro modo, seriam distintos, com a eliminação de qualquer redundância parcial ou
total entre esses arquivos; e compartilhados porque pode ser compartilhado entre
diferentes usuários, no sentido de que diferentes usuários podem ter acesso aos
mesmos dados, possivelmente ao mesmo tempo” (DATE, 2004).
Já para Melo (2004) banco de dados é uma coleção de dados inter-relacionados,
coerentes e com significado inerente. Segundo o mesmo autor, um banco de dados deve ser
projetado, construído, alimentados com informações que atendam as necessidades de certo
20
grupo de usuários, lhes fornecendo um resultado único, não redundante e de acordo com sua
necessidade.
2.1.1 Arquitetura de Banco de Dados
De acordo com Date (2004) a arquitetura de um sistema de banco de dados (SBD), é
dividida em três níveis:
Nível Interno ou Nível de Armazenamento é o mais próximo do modo de
armazenamento físico, e aquele que se ocupa de que maneira os dados serão armazenados
fisicamente dentro do sistema. (DATE, 2004).
Nível Externo ou Nível Lógico é o mais próximo dos usuários e se ocupa de que
maneira os dados serão vistos por usuários individuais. Abrange os esquemas externos, ou
seja, a visão do usuário, cada esquema externo é responsável pela descrição de uma parte do
banco de dados que um determinado grupo tem interesse e ocultar o restante do banco,
facilitando a visão do usuário. (DATE, 2004).
Nível Conceitual ou nível Lógico de Comunidade é o nível de simulação entre os
dois níveis, ou seja, é o nível intermediário. “Um registro conceitual não e necessariamente o
mesmo que um registro externo e nem o mesmo que um registro de armazenamento.” (DATE
2004).
Segundo Tsichritzis e Klug (1978) a arquitetura de três esquemas também conhecida
como arquitetura (ANSI) American Nacional Standards Organization – Organização
Americana de Padrões tem o objetivo de facilitar a realização e visualização das três
características importantes de abordagem no uso de banco de dados, a separação de
programas e dados (independência de dados e operação de programas), o suporte a múltiplas
visões de usuários e o uso de catálogo para armazenar a descrição de banco de dados
(esquema). A figura 1 apresenta a arquitetura de três esquemas.
21
Figura 1 - Arquitetura de três Esquemas
Fonte: (DEVMEDIA, 2012)
2.1.2 Sistema de banco de dados
De acordo com Tanenbaum (2000), um Sistema de Banco de Dados (SBD), é uma
maneira de armazenar dados e absorver informações que posteriormente poderão ser
recuperadas ou atualizadas por alguns usuários do SBD.
Segundo Date (2004) os dados de um banco de dados permanecerão integrados ou
compartilhados, integrados porque o banco de dados pode ser considerado a junção de vários
arquivos, distintos, pois elimina qualquer tipo de redundância dos arquivos, e compartilhado,
porque pode ser partilhado entre diferentes usuários de modo que permita que esses usuários
possam acessar os mesmo dados simultaneamente. “Sistema de banco de dados é um sistema
computadorizado cuja finalidade geral é armazenar informações e permitir que os usuários
busquem e atualizem essas informações quando as solicitar”. (DATE, 2004).
Conforme Cantu (2005) banco de dados pode ser definido como um conjunto de
dados relacionados, armazenados juntos sem redundância desnecessária que modela um
sistema do mundo real e pode convir para diferentes aplicações.
O SDB também deve evitar perda de dados, falhas do sistema, acesso de usuários
não autorizado e anomalia de dados. (TANENBAUM, 2000).
Os componentes de banco de dados se dividem e quatro partes, dados, hardware,
softwares e usuários, conforme figura 2. (METROPÓLE DIGITAL, 2013).
22
Figura 2 - Componentes do Sistema de Banco de Dados
Fonte: (DEVMEDIA, 2012)
Dados que devem ser integrados, ou seja, permitir que vários usuários possam
acessa-los simultaneamente; (METROPÓLE DIGITAL, 2013).
Hardware composto pela memória, dispositivos de armazenamentos (discos), ou
seja, parte física do computador na qual vai funcionar o SGBD; (METROPÓLE DIGITAL,
2013).
Software são os Sistemas Gerenciamento de Banco de Dados (SGBD), responsáveis
por atender as necessidades dos usuários e fornecer segurança e gerenciamento das atividades
em um SDB, serão instalados no hardware; (METROPÓLE DIGITAL, 2013).
Usuários são aqueles que gerenciam o banco de dados através do SGBD.
(METROPÓLE DIGITAL, 2013).
2.1.3 Sistema gerenciador de Banco de dados - SGBD
Segundo Ricarte (2008), uma das principais contribuições com o surgimento do
SGBD foi o início da separação entre os dados armazenados e a descrição da estrutura que é
feita através de esquemas, onde as restrições sobre os dados formam o modelo de dados de
um sistema.
De acordo com Navathe e Elmasri (2005), um SGBD pode ser conceituado da
seguinte forma:
23
“Um sistema gerenciador de banco de dados (SGBD) é uma coleção de programas
que permite aos usuários criar e manter um banco de dados, ou seja, um sistema de
software de propósito geral que facilita os processos de definição, construção,
manipulação e compartilhamento de banco de dados entre vários usuários e
aplicações.” (NAVATHE e ELMASRI, 2005).
Conforme Laudon e Laudon (2004), um SGBD è um software que permite que os
dados sejam controlados em um único local porem disponíveis para diversas aplicações.
Para Date (2004), SGBD pode ser considerado como um software responsável pelo
gerenciamento dos acessos realizados em um banco de dados, acesso esses que podem ser
divididos em quatro etapas:
“1. Um usuário faz um pedido de acesso usando uma determinada sublinguagem de
dados (geralmente, SQL)”.
2. O SGBD intercepta o pedido e o analisa.
3. O SGBD, por sua vez, inspeciona o esquema externo (ou as versões objeto desse
esquema) para esse usuário, o mapeamento externo/conceitual correspondente, o
esquema conceitual, o mapeamento conceitual/interno e a definição do banco de
dados armazenado.
4. O SGBD executa as operações necessárias sobre o banco de dados armazenado”
(DATE 2004).
De acordo com Date (2000), o Sistema Gerenciador de Demandas (SGBD), possui
uma dupla visão sendo a primeira de banco de dados físico onde os dados são armazenados no
banco de maneira organizada. Fazendo com que todas as requisições de acesso ao banco de
dados e manipulações de dados sejam fornecidas pelo SGBD.
Já a segunda visão, interpreta o SGDB como uma ferramenta de alto nível que está
acima da camada de hardware, e permite operações de fácil interpretação para os usuários em
uma linguagem de nível próxima a linguagem humana.
2.2
MODELO ENTIDADE-RELACIONAMENTO
Segundo (TAKAI, ITALIANO e FERREIRA, 2005), um Modelo de Entidade
Relacionamento (MER) pode ser considerado como um modelo de dados conceitual de alto
nível que é independente do SGBD, que é responsável pela representação do problema a ser
tratado.
O Modelo Entidade-Relacionamento foi fundamentado na teoria relacional de Cood
e serve para representar estruturas de dados de forma que fique mais próximo do mundo real
24
dos negócios, esse modelo é composto por três conceitos: entidades, atributos e
relacionamentos. (SILBERSCHATZ E SUDARSHAN, 2006). A figura 3 apresenta um
Modelo de Entidade Relacionamento.
Figura 3 - Modelo de Entidade Relacionamento (MER)
Fonte: (e-KNOWLEDGE, 2012).
Entidades são os objetos, as características desses objetos são os atributos e as
relações entre esses objetos são denominado de relacionamentos. (DEVMEDIA, 2012).
Ainda segundo Devmedia (2012), a evolução do MER foi aprimorada em
mecanismos de abstração, onde o conceito permite estabelecer que partes da realidade fossem
importantes para que o sistema de informações seja desenvolvido, além de determinar que
fatos relacionados à modelagem sejam importantes para realização da modelagem.
O modelo relacional foi criado em 1976 pelo Dr. Pin-Shan (Petter) Chen, sendo
determinado como uma representação conceitual abstrata de dados gerando um diagrama
denominado de Diagrama de Entidade Relacionamento DER que deve ser notórios por todos
aqueles que participaram do processo de criação do banco de dados.
O modelo relacional é uma ideia que existe na mente humana mais que não pode ser
implementado por um computador, pode ser representado através de um diagrama de entidade
relacionamento (DER) ou exposto em forma de texto através de uma linguagem formal.
(SETZER, 2005).
25
2.3
MODELO RELACIONAL
O modelo Relacional (MR) surgiu em 1970 para suprir o modelo hierárquico e de
rede. Segundo Navalhe (2005):
“O Modelo Relacional (MR) foi introduzido por Ted Codd, da IBM Research, em
1970, em um artigo clássico (Codd, 1970) que imediatamente atraiu a atenção em
virtude de sua simplicidade e base matemática. O modelo usa o conceito de relação
matemática – algo como uma tabela de valores – como seu bloco de construção
básica e tem sua base teórica na teoria dos conjuntos e na lógica de predicados de
primeira ordem.”(NAVATHE e ELMASRI, 2005).
De acordo com Neves (2002) o modelo relacional é matematicamente conciso,
completo, anti-redudante e consistente internamente além de ser mais aproveitado no mercado
comercial, pode também ser utilizado para resolver problemas diários.
Segundo Tanenbaum (2000) a tabela è considerado uma relação, as colunas de
atributo e a quantidade total desses atributos são denominadas de grau enquanto os conjuntos
de valores válidos para um determinado atributo será denominado de domínio, já as linhas
serão denominadas de tuplas e os conjuntos dessas serão as cardinalidade. A figura 4 mostra
um exemplo de um relacionamento.
Figura 4 - Exemplo de Relacionamento
ID
1
2
Cliente
Nome
Pedro
Paulo
CPF
123456
655421
ID
1
2
Hotel
Quarto Classe
Simples
2
Casal
1
O exemplo acima nota-se que o cliente Pedro ocupa o quarto simples, uma vez que
sua chave primária (1) torna-se sua chave estrangeira na tabela hotel, essa mesma lógica pode
ser aplicada para o cliente Paulo que ocupa o quarto de casal na tabela hotel.
Conforme Machado e Abreu (1995) existem quatro formas de relacionamentos:
Relacionamento 1:1 é uma relação de um campo chave de um registro de uma
determinada tabela com o campo chave de um registro de outra determinada tabela, por
exemplo, um casamento, onde um marido pode ter apenas uma esposa e uma esposa apenas
um marido. (MACHADO e ABREU 1995). A figura 5 mostra um exemplo de relacionamento
1 para 1.
26
Figura 5 - Relacionamento 1:1
Homem 1
1
Mulher
Relacionamento 1: N é um relação de um campo chave de um registro de uma
determinada tabela com o campo chave de muitos registros de outra determinada tabela, por
exemplo, um condutor pode ser dono de muitos veículos, porém um veículo pode pertencer
apenas á um condutor. (MACHADO e ABREU 1995). A figura 6 mostra um exemplo de um
relacionamento 1 para n.
Figura 6 - Relacionamento 1:N
Condutor 1
N
Veículo
Relacionamento N: N é uma relação de um campo chave de muitos registros de uma
determinada tabela com o campo chave de muitos registros de outra determinada tabela, por
exemplo, um aluno pode cursar muitas disciplinas e uma disciplina pode ser cursada por
vários alunos. (MACHADO e ABREU 1995). A figura 7 mostra um exemplo de um
relacionamento n para n.
Figura 7 - Relacionamento N:N
Aluno
N
N Disciplina
27
2.3.1 Chaves Primárias e Chaves Estrangeiras
Para estabelecer as restrições de integridade e estabelecer os relacionamentos entre as
tabelas usa- se um campo denominado chave que podem ser primárias ou estrangeiras.
O termo integridade refere-se à precisão ou correção de dados armazenados em um
banco de dados, as restrições de integridades concebem o significado dos dados. (DATE
2000).
A restrição de integridade é uma relação única e declara que nem um valor da chave
primária deverá ser nulo, para que não impossibilite na identificação das tuplas. (NAVATHE
e ELMASRI, 2005).
As chaves primárias são utilizadas para identificar uma ou mais colunas que não
possuem valores repetidos em uma determinada tabela e é definida através das chaves
candidatas, toda chave primária representa um valor e não pode ser nulo. (DATE, 2000). A
figura 8 é apresentada um exemplo de chave primária.
Figura 8 - Exemplo Chave Primária
Fonte: (E-KNOWLEDGE,
2013)
As chaves estrangeiras formam um conjunto de atributos que servem para referenciar
a chave primária de outra tabela, definir os relacionamentos em um banco de dados
relacionais, além de serem utilizadas para manter a integridade referencial do banco de dados.
Na figura 9 é apresentado um exemplo de chave estrangeira.
28
Figura 9 - Exemplo Chave Estrangeira
Fonte: (E-KNOWLEDGE,
2012)
2.3.2 Restrições do Modelo Relacional
Em um banco de dados relacional, sucedem diferentes tipos de relações, contendo
várias tuplas que se relacionam entre si de maneiras qualificadas. A relação existente entre
essa tupla em um determinado momento implicará na resposta proporcionada por um banco
de dados, normalmente ocorrem restrições ou bloqueios para os valores reais em um estado de
banco dados.
Navalhe e Elmasri (2005) trata essas restrições dividindo-as em três categorias:
Restrições baseadas em esquema, que são expressas diretamente no esquema do
modelo, geralmente por suas especificações em DDL (Data Definition Linguage);
Restrições Baseadas em Aplicações são expressas diretamente no esquema do
modelo de dados, portanto devem ser expressa e imposta pelos programas de aplicação;
Restrições Baseadas em Modelo são inerentes ao modelo de dados. (NAVATHE e
ELMASRI, 2005).
29
2.3.3 Gerenciamento de Transações
De acordo com Silberschatz e Sudarshan (2006) um SGBD deve ser capaz de
implementar mecanismos adequados para gerenciar transações e controle de concorrências e
recuperação de dados quando requisitadas pelo usuário com o objetivo de evitar que ocorram
anomalias de dados e falhas de inconsistências.
Para que a integridade de dados de um SGBD seja segura é necessária que sigas as
regras do (ACID) Atomicidade, Consistência, Isolamento e Durabilidade, essas propriedades
estão descritas abaixo: (SILBERCHATZ e SUDARSHAM, 2006).
Atomicidade todas as transações deverão ser iniciadas e finalizadas com sucesso, por
exemplo, ao sacar dinheiro em um caixa eletrônico e durante essa transação ocorre uma queda
de energia antes que você consiga sacar o dinheiro, então à atomicidade dos dados faz com
que essa transação retorne ao início, sem prejuízos ao usuário. (SILBERCHATZ e
SUDARSHAM, 2006).
Consistência é quando uma transação for concluída, todos os dados devem
permanecer em um estado consistente, acompanhando o exemplo dado em atomicidade se o
saque for concluído com o sucesso a consistência garante que somente a quantidade solicitada
pelo usuário seja debitada de sua conta. (SILBERCHATZ e SUDARSHAM, 2006).
Isolamento são modificações realizadas por transações simultâneas e devem ser
isoladas e não podem interferir em nenhuma outra transação simultânea. (SILBERCHATZ e
SUDARSHAM, 2006).
Durabilidade depois que uma transação for concluída com sucesso, as mudanças
realizadas no banco de dados persistem mesmo no caso de uma queda do sistema.
(SILBERCHATZ e SUDARSHAN, 2006).
2.4
NORMALIZAÇÃO
De acordo com Date (2004) normalização pode ser definido como um conjunto de
regras que leva à elaboração de modelos mais robustos, com menos redundância de
informação e menos dependência de elementos. Normalização é uma atividade que realiza a
verificação do modelo lógico.
30
2.4.1 Primeira Forma Normal
1ª Forma Normal (1FN) onde toda tabela possui uma chave primária e garantir que
todo atributo seja atômico, e que os atributos compostos sejam separados. Por exemplo, um
atributo endereço deve ser subdividido em seus componentes; bairro, cidade, estado, CEP
entre outros. DATE (2004).
Ainda segundo Date (2004) os atributos multivalorados devem ser separados em
outra relação. Por exemplo, o atributo telefone pode ser separado em residencial, fixo, celular,
ou podem ser criados em outra relação para que fosse possível representar um número
indeterminado de telefones.
2.4.2 Segunda Forma Normal
2ª Forma Normal (2FN) para que uma relação esteja na segunda forma normal ela
obrigatoriamente deve está na primeira Forma normal e extinguir dependências parciais e
funcionais, ou seja, todo atributo não chave da relação deverá depender por completo da
chave primária. Por exemplo, uma relação que contenha os atributos código do fornecedor,
nome do fornecedor e preço de venda e considerando que a chave primária é composta pelos
atributos código do fornecedor e código da obra. DATE (2004).
Essa relação não estará na segunda forma normal já que o nome do fornecedor
depende exclusivamente do código do fornecedor e não do código da obra, passando para
segunda forma é necessário que crie uma nova relação (fornecedor) com os campos código do
fornecedor como chave primária e nome do fornecedor, com intuito de diminuir a
redundância de informações criadas de formas indevidas. DATE (2004).
2.4.3 Terceira Forma Normal
3ª Forma Normal (3FN) para que uma relação esteja na terceira forma normal ela
obrigatoriamente deve está na segunda forma normal e extinguir dependências funcionais
31
transitivas, ou seja, todo atributo não chave deve ser mutuamente independente. Por exemplo,
uma relação que contenha os atributos matrícula do funcionário como chave primária, nome
funcionário, código do departamento e nome do departamento não estaria na terceira forma.
DATE (2004). A figura 10 mostra um exemplo de uma tabela que ainda não se encontra na
terceira forma normal.
Figura 10 - Tabela Funcionário
FUNCIONÁRIO
Matrícula _funcionário int chave primária
Nome _funcionário char (50)
Codigo_departamento int
Nome_departamento char (70)
O nome do departamento é dependente do código departamento, e não da matrícula
funcionário, se houvesse uma mudança no nome do departamento, influenciaria nas alterações
de todos os funcionários, para sanar esse problema é necessário a criação de uma relação
(departamento) contendo nome do departamento e código do departamento como chave
primária que será chave estrangeira na relação original. A figura 11 mostra o
desmembramento dos atributos e a criação da nova tabela departamento.
Figura 11 - Tabela Terceira Forma Normal
Funcionário
Codigo_funcionário int
Chave Primária
Nome_funcionário char (50)
Departamento
Codigo_departmamento int
Chave Primária
Nome_departamento char
(70)
Codigo_departamento Chave
Estrangeira
2.5
PADRÃO SQL
Foi criado em 1970 pela IBM, como parte Sistema R, quando os bancos de dados
relacionais
eram
desenvolvidos
(RAMAKRISHNAN, 2008).
e
linguagens
foram
criadas
para
manipulá-los.
32
2.5.1 Descrição
A Structured Query Language, ou Linguagem de Consulta Estrutura - SQL é tida como
“uma linguagem orientada a transformações que aceita uma ou mais relações como entrada e
produz uma relação única como saída”, Significa que a linguagem SQL e capaz de transforma em
resultado qualquer operação envolvendo tabelas em um banco de dados, e cada resultado gera um
a nova tabela com linhas e colunas de acordo com as definições estabelecidas pelo modelo
relacional. (KROENKE, 1999).
De acordo com Battisti (2006) o SQL é uma linguagem padrão de consulta criada
para realizar operações em um banco de dados e foi desenvolvida para ser independente de
hardware e software.
“Ao usar o SQL, não e necessário saber a respeito do software banco de dados ou do
hardware envolvido em uma operação. Tudo o que você precisa conhecer são os
comandos/instruções SQL padrão para solicitar informações que obrigatoriamente é
o mesmo em todos os sistemas que utilizam o SQL.” (BATITISTI 2006).
Segundo Garcia-Molina (2001) SQL é uma linguagem que surgiu para acessar um
banco de dados de forma simples baseada nos conceito do modelo relacional proposto pelo
Dr.Codd em 1970.
Conforme Oliveira (2002) a linguagem SQL tem sido um padrão tomado para
utilização em banco de dados relacionais, existem várias versões de SQL, porém sua versão
original foi desenvolvida pela International Business Machines (IBM) no laboratório de são
José na Califórnia com o nome de sequel.
2.5.2 Histórico SQL
De acordo com (NAVATHE e ELMASRI, 2005) a SQL é uma linguagem padrão de
bancos de dados relacionais, que possui comandos para realizar manipulações no banco de
dados, tais como alterações, inserções entre outros, por ser uma linguagem padrão, faz com
que o usuário não encontre dificuldades caso necessite mudar suas aplicações de um banco
para outro desde que siga os padrões e que ambos os bancos o suportem, já que os SGBD
possuem características diferentes, além de possuir funcionalidades para inserir seus
comandos disponíveis em linguagem de programação com Java,COBOL ou C++.
33
Em 1986 surgiu o primeiro padrão de linguagem SQL (Structured Query Language),
com o objetivo de padronizar a utilização, acesso e manipulação das informações no banco de
dados. (CANTU, 2005).
Esse padrão foi desenvolvido pela ANSI e ficou conhecido como SQL 86, e que
depois passaram por algumas evoluções, em 1989 tornou-se SQL 89, e em 1992 o modelo foi
definido como SQL 92.
A última versão surgiu em 1999, conhecida com versão SQL 99 trazendo uma
mudança significativa, que era a definição de padrões para banco de dados objeto relacionais.
Diante do surgimento dessas versões tornou-se necessário a criação do instituto
ANSI (American Standarts Institute), com a finalidade de estabelecer uma padronização para
linguagem SQL (MANZANO, 2008).
2.5.3 Comandos DDL
Uma DDL (Linguagem de Definição de Dados) permite ao usuário definir tabelas
novas e elementos associados. A maioria dos bancos de dados de SQL comerciais tem
extensões proprietárias no DDL. Um esquema de dado é definido por um conjunto de
definições expressas em uma linguagem de definição de dados. (NAVATHE e ELMASRI,
2005).
2.5.3.1 Create Table
O comando create table é utilizado para criar uma nova relação ou objeto (view),
com nome e especificando seus atributos e restrições iniciais, sendo que as restrições (chave
primária, estrangeira), podem ser acrescentadas posteriormente após a criação da tabela.
(NAVATHE e ELMASRI, 2011). A sintaxe deste comando é descrita a seguir na figura 12.
34
Figura 12 - Create Table
CREATE TABLE nome da tabela (
campo 1 INT,
campo 2 VARCHAR (50),
campo 3 DATE NOT NULL,
PRIMARY KEY (campo da tabela que será
definido como chave primária));
2.5.3.2 Drop Table
Esse comando serve para remover a definição da tabela ou remover um objeto (view)
do banco de dados. (NAVATHE e ELMASRI, 2011). A sintaxe deste comando é descrita a
seguir na figura 13.
Figura 13 - Drop Table
DROP (nome do objeto) =TABLE nome da tabela;
2.5.3.3 Alter table
Esse comando tem como objetivo alterar a estrutura de uma tabela, sendo possível
adicionar, remover os campos, os nomes e os formatos da coluna. Além de integridade
referencial definidas em uma tabela. (NAVATHE e ELMASRI, 2011). A sintaxe deste
comando é descrita na figura 14.
Figura 14 - Alter Table
ALTER TABLE <nome-tabela>
DROP <nome-coluna>
ADD <nome-coluna> <tipo-do-dado>
35
2.5.4 Comandos DML
São comandos de manipulação de dados designados para realizar as consultas,
inserções, exclusões e alterações em registros das tabelas através dos respectivos comandos:
Select, Insert, delete e Update.(LINHA DE CÓDIGO,2013).
De acordo com o site Diário de um DBA (2013), em algumas obras literárias o
comando select não é considerado como uma DML, e sim uma DQL Data Query Linguagem
ou linguagem de consulta de dados.
2.5.4.1 Select
É o comando mais utilizado pelo usuário, permite listar os atributos e funções a ser
recuperada, a cláusula from especifica as tabelas que serão consultadas, a cláusula where
especifica as condições para selecionar as tuplas dessas relações. (NAVATHE e ELMASRI,
2011). A sintaxe deste comando é descrita na figura 15.
Figura 15 - Select
SELECT CAMPOS (nome, login) FROM NOME DA
TABELA (aluno) WHERE CONDIÇÃO (idade =18);
2.5.4.2 Update
O comando update é empregado para alterar valores do atributo de uma ou mais
tuplas selecionados e inclui também a cláusula where para especificar quais tuplas serão
modificadas, na cláusula set são determinados quais os atributos a serem modificados e seus
novos valores. (NAVATHE e ELMASRI, 2011). A sintaxe deste comando é descrita na figura
16.
36
Figura 16 - Update
UPDATE (nome da tabela)
SET campo = (valor a ser alterado)
WHERE (campo = Valor atual);
2.5.4.3 Insert
Segundo Nvathe e Elmasri, (2011) o comando insert é utilizado para inserir uma
única tupla a uma relação, onde deve ser especificado o nome da relação e os valores a serem
atribuídos na mesma ordem em que foram especificados no comando de criação da tabela. A
sintaxe deste comando é descrita a na figura 17.
Figura 17 - Insert
INSERT INTO (nome da tabela)
VALUES (valores de cada campo, prédefinidos na criação da tabela);
2.5.4.4 Delete
O comando delete remove tuplas de uma relação, esse comando pode ser utilizado
com a cláusula where para especificar que quais tuplas devem ser deletadas. (NAVATHE e
ELMASRI, 2011). A sintaxe deste comando é descrita a seguir na figura 18.
Figura 18 - Delete
DELETE FROM (nome da tabela)
WHERE campo = (valor a ser deletado);
37
2.5.5 Comandos DCL
São comandos que permitem ao administrador de banco de dados controlarem as
autorizações de dados e as permissões dos usuários com a finalidade de definir quem tem
acesso para manipular dados dentro de um banco de dados. (ROCHA, 2013).
Grant concede permissões aos usuários para executar determinadas operações em um
banco de dados. (NAVATHE e ELMASRI, 2011). A sintaxe deste comando é descrita na
figura 19.
Figura 19 - Grant
GRANT (permissão) = SELECT, UPADATE
ON nome da tabela TO usuário;
Revoke remove ou restringe permissões concedidas aos usuários para executar
determinadas operações em um banco de dados. (NAVATHE e ELMASRI, 2011). A sintaxe
deste comando é descrita na figura 20.
Figura 20 - Revoke
REVOKE permissão SELECT,
UPDATE ON nome da tabela TO
usuário;
2.6
BANCO DE DADOS MYSQL
De acordo com Gilfillan (2003) o MySQL é um sistema de gerenciamento de banco
de dados relacional (SGBDR) com a capacidade de armazenar grande quantidade de dados de
diferentes tipos e distribuí-los, suprindo assim as necessidades de um modelo de organização.
38
2.6.1 Histórico
Conforme Infowester (2012) o MySQL foi desenvolvido na Suécia por Allan
Larsson, David Axmark e Michael widenius, que perceberam a necessidade de realizar
conexões entre tabelas já que o mSQL utilizado não atendiam suas demandas surgindo então a
primeira versão em 1996.
Já segundo Cremades (2009) o MySQL surgiu no inícios dos anos 1990 com o
objetivo de gerenciar uma base dados, no começo seu software era oferecido com uma licença
open source e vendia também seus pacotes com serviços de manutenção e suporte.
De acordo com Milani (2006) O MySQL surgiu na década de 90, desenvolvido por
Axmark, Allan Larsson e Michael Widenius, devido à necessidade de uma interface SQL
compatível com as rotinas ISAM (Indexed Sequential Access Method) – Método de
armazenamento que permite uma rápida recuperação de dados para leitura). ”o MySQL é um
servidor e gerenciador de banco de dados relacional, de licença dupla (sendo uma delas de
software livres), projetado inicialmente para ser usado com aplicações de pequeno porte”.
(MILANI, 2006).
De acordo com Oliveira o MySQL foi criado por Michael na companhia suíça
conforme descrição abaixo:
“O MySQL foi criado por Michael Widenius na companhia suíça TcX. Por volta de
1979 Michael desenvolveu um banco de dados chamado UNIREG, “sendo rescritos
em várias linguagens desde então" [YAR 99]. Em 1994, a empresa TcX começou o
desenvolvimento de aplicações baseadas na Web, tendo como base o banco
UNIREG, porém esse banco possuía muito "overhead" para obter sucesso em uma
aplicação para geração de páginas dinâmicas na Web. Então a empresa TcX
começou a procurar por outro banco o mSQL, uma ferramenta baseada em SQL mas
com características pobres não possuindo por exemplo suporte a índices, e com
desempenho inferior ao UNIREG.”(OLIVEIRA, 2013).
A aquisição do MySQL pode ser feita através do site oficial para aplicações sob
licença GPL (General Public Licence) estando disponíveis para sistemas open source (Linux,
MAC OS.) e para softwares proprietários (Microssoftware Windows.), para aplicações não
GPL, poderá ser cobrado uma pequena taxa, porém sem limite de usuários (ANDERSON,
2004).
Pertencia a empresa MySQL AB em 1995, depois foi comprada pela SUN em 2008,
e em 2009 foi vendida Para a ORACLE, que consequentemente assumiu o MySQL com a
39
condição de manter as duas licenças (open source e Comercial) até 2015. (BORBA ON
SOFTWARE, 2012).
Em 2012 a ORACLE lançou a versão 5.6 com maior desempenho e escalabilidade,
com capacidade de replicação aprimorada, segue abaixo algumas características dessa nova
versão.
“A primeira versão de desenvolvimento também traz um processo de replicação
aprimorada, fornecendo um novo crash-safe e replicação checksums, para melhorar
a integridade dos dados e detectar erros que poderiam causar danos (slave);
replicação row-based otimizada, para melhorar o desempenho de replicação e
reduzir o consumo de recursos do sistema, e tempo de atraso de replicação,
proporcionando aos DBAs mais flexibilidade e Remote Binary Log Backup,
permitindo-lhes criar backups em tempo real a partir do log binário.”
(iMasters,2013).
2.6.2 Descrição
Segundo Willians e Tahaghoghi (2007) o MYSQL é um banco de dados relacional
que utiliza a linguagem SQL como interface, e um software livre com grande facilidade de
uso e pouca exigência quanto ao uso do hardware.
O MYSQL é um banco de dados que não está disponível somente para sistemas
operacionais open source como Linux, MACos entre outros mas também para softwares
proprietário como a Microsoft Windows, já para aplicações GPl poderá ser cobrado uma
pequena Taxa, porém não há limites de usuários, upgrades e processadores. (ANDERSON,
2004).
De acordo com Wellington e Thomson (2004) o MYSQL possui um conjunto de
Application Programming Interface (API), ou Interface de programação de aplicativos, e pode
ser escrita para qualquer tipo de servidor ou sistema operacional essa API faz com o MYSQL
suporte várias linguagens de programação entre elas o C, C++ e oferece uma lista de rotinas
que podem ser chamadas de dentro de um programa para interagir com o banco de dados.
40
2.6.3 Características
O MySQL possui alguma características significativas para sua boa utilização no
cotidiano, segundo o site do PORTAL DA EDUCAÇÃO (2012) segue abaixo algumas dessas
características:
“Portabilidade;
Multithreads (maior integração com máquina com mais de um processador);
Formas de armazenamento (MyISAM, InnoDB);
Velocidade (utilização de cache em consultas indexação);
Segurança (criptografia, conexão limitada);
Armazenamento de procedimentos;
Replicação de dados entre servidores MySQL;
Capacidade (utilizando tabelas InnoDB, onde o armazenamento é feito por 1 ou mais
arquivos, é possível armazenar 65.536TB)”.(PORTAL DA EDUCAÇÃO ,2012).
Segundo o site MySQL (2005), o MySQL ainda possui suporte a integridade
referencial, transações, views, treinamento e consultoria oficial no Brasil, ferramentas gráficas
de administração, extração de dados e atualizações constantes, suporte a cluster, subselect e
stored procedure.
Possui licença GNU General Public License (Licença Pública Geral), GNU GPL ou
simplesmente GPL, significa licença livre. (DEVMEDIA, 2013).
Pode ser instalado em múltiplas plataformas entre as principais podemos citar
Windows e Linux, além de possuir uma ferramenta chamada Workbench que torna a mais
fácil e intuitivo o uso do SGBD e outra denominada Shell, que serve para receber os
comandos SQL.
2.6.4
Arquitetura
Segundo Gaudêncio (2013) a arquitetura do MySQL é dividida em três níveis, conforme
figura 21.
41
Figura 21 - Arquitetura MySQL
Fonte: (GAUDENCIO,
2013).
O primeiro nível de conexões corresponde a camada que não é exclusivamente do
MySQL, onde é baseado na arquitetura cliente servidor, por exemplo em uma linguagem de
programação é realizada a conexão com o SGBD, necessitando assim de uma autenticação.
(GAUDENCIO, 2013).
O MySQL trabalha com threads, ele entende que cada conexão corresponde a uma
thread, oferecendo suporte ao SGBD para que trabalhe com várias conexões simultâneas num
mesmo BD, através da utilização de múltiplos processos que se comunicam por meio de
memórias compartilhadas.(GAUDENCIO, 2013).
Já o segundo nível query cache ou cache de consultas e parsing é onde se localiza a
parte principal do MySQL, onde estão localizadas os códigos para interpretação de consultas,
análises, cache, otimização e todas as funções embutidas como data,hora entre outros. É
também nesse nível que fica armazenado todas as funcionalidades disponíveis pelas
ferramentas de armazenamento como views, stored procedure e triggers. (GAUDENCIO,
2013).
E por ultimo o terceiro nível onde fica localizado os motores de armazenamentos,
que são responsáveis pelo feedback das informações armazenadas no MySQL, ressaltando
que cada motor de armazenamento possui suas vantagens e desvantagens e que também não
se comunicam entre si, simplesmente respondem a pedidos do servidor. (GAUDENCIO,
2013).
42
Esses motores se comunicam com o servidor de base de dados por meio de uma API
(Application
Programming
Interface ou Interface
de
Programação
de
Aplicativos)
denominada storage engine, essa api fica incumbida de ocultar as diferenças dos motores de
pesquisa, tornando-as transparente para os níveis superiores do MySQL.(GAUDENCIO,
2013).
Na API contém funções de baixo nível para processar operações como begin
transaction” ou “fletch the row that has primary key” .(GAUDENCIO, 2013).
2.7
BANCO DE DADOS POSTGRESQL
De acordo com o POSTGRESQL GLOBAL DEVELOPMENT GROUP (2005) o
PostgreSQL pode ser considerado um Sistema Gerenciador de Banco de Dados ObjetoRelacional, pelo fato de possuir características de um SGBD relacional e por contar com
funcionalidades de orientação a objetos.
2.7.1
Histórico
O PostgreSQL é um Sistema de Gerenciamento de Banco de Dados Objeto
Relacional (SGBDOR), elaborado a partir do gerenciador de banco de dados POSTGRES, um
projeto iniciado em 1986 na Universidade da Califórnia, em Berkeley, sob a liderança do
professor Michael Stonebraker, foi patrocinado por alguns órgãos Norte-americanos dentre
eles o DARPA (Defense Advanced Research Project Agency), o ARO (Army Research
Oficce) e distribuído na versão open source. (MANZANO, 2008).
Em 1987 foi liberada a versão 1.0 disponível apenas para um pequeno grupo de
usuários, já em 1990 foi lançada a versão 2.0, com algumas melhorias e dessa maneira a
equipe do professor Stonebraker trabalhou no projeto até a versão 4.2, quando em 1994
Andrew Yu e Jolly Chen adicionaram ao programa um interpretador de linguagem SQL e
lançando em 1995 o Postgres95. (MANZANO, 2008).
43
De acordo com Manzano (2008), o programa Postgres95 na sua primeira versão foi
considerado pelo Wisconsin Benchmark de 30% 50% mais rápido que a versão anterior (4.2),
segue abaixo algumas mudanças significativas da versão Postgres95:
“inclusão de um programa de terminal interativo chamado psql;
sistema de arquivos Inversão e o sistema de regras no nível de instância
foram removidos;
foi acrescentado ao código fonte um tutorial introduzindo as funcionalidades da
linguagem SQL e do Postgres95;
subconsultas podiam ser simuladas por meio de funções SQL definidas
pelo usuário;
funções de agregação foram reimplementadas;
foi adicionado suporte à cláusula GROUP BY nas consultas;
acrescentado uma nova biblioteca cliente, a libpgtcl, para suporte a clientes baseados
no Tcl, e novos comandos Tcl ao interpretador pgtclsh para interfacear programas
GLOBAL
Tcl
com
o
servidor
Postgres95.”
(POSTGRESQL
DEVELOPMENT GROUP (2005).
Pelo fato do nome Postgres95 está associado ao ano de 1995 e com o incremento do
interpretador de linguagem SQL, em 1996 passou a ser chamado de PostgreSQL, com
algumas melhorias como: “os tipos usuais foram aperfeiçoados; flexibilidade através da
inclusão de funções como: restrição, gatilho, subconsulta e padrão no servidor”.
(POSTGRESQL GLOBAL
DEVELOPMENT GROUP, 2005).
O Grupo Global do PostgreSQL lançou a versão 9.2 maior desempenho,
escalabilidade e flexibilidade. (PostgreSQL,2013). Com caracteristísticas descritas abaixo:
“Com o PostgreSQL 9.2, os resultados da consulta podem ser devolvidos como tipos
de dados JSON. Combinado com as novas extensões do banco de dados PL/V8
Javascript e PL/Coffee, e o armazenamento opcional de chave-valor HStore, os
usuários podem agora utilizar o PostgreSQL como um banco de dados "NoSQL" de
documentos, mantendo a confiabilidade, flexibilidade e performance do
PostgreSQL.
"Suporte nativo a JSON no PostgreSQL fornece um mecanismo eficiente para
criação e armazenamento de documentos para APIs web. Nós usamos bibliotecas
cliente como jQuery para solicitar dados tabulares e em forma de árvore; e as novas
funcionalidades o tornam conveniente e fornecem vantagens de desempenho na
recuperação daqueles dados como JSON,” disse Taras Mitran, Arquiteto Sênior,
IVC Inc.”(PostgreSQL,2013)
2.7.2
Descrição
O SGBD PostgreSQL, é um sistema de gerência de banco de dados relacional
estendido a objetos ou objeto-relacional, ou seja essa sua extensão nos permiti utilizar alguns
conceitos de um banco orientado a objetos.
44
“Agora falando do PostgreSQL. Ao contrário do que lemos muitas vezes por ai, o
PostgreSQL não é um SGBD (Sistema de Gerência de Banco de Dados) Orientado a
Objetos. Ele é o que chamamos de Sistema de Gerência de Banco de Dados
Relacional Estendido ou Objeto-Relacional. Essa sua Extensão nos permite utilizar
alguns conceitos próprios de um Banco Orientado a Objetos, como por exemplo
tipos de dados definidos pelo usuário e herança. No caso da herança no PostgreSQL,
uma tabela pode herdar de nenhuma, uma, ou várias tabelas.”(DEVMEDIA,2013).
O PostgreSQL é um sistema de banco de dados, desenvolvido pelo departamento de
ciências da universidade da Califórnia, e foi pioneiro em alguns conceitos, que somente foram
disponíveis para outros bancos posteriormente.Oferece suporte a várias plataformas entre as
principais podemos destacar: Windows,Linux.
Diferente do Mysql, não pertence a uma empresa, é mantido por instituições
nacionais e internacionais, porém é administrado pela comunidade PostgreSQL Global
Development Group.
Possui a técnica avançada chamada MVCC (Multi-version Concurrency Control),
que resolve o problema de ambiente multiusuário, os locks, que fazem os usuários fiquem
aguardando a finalização de uma transação para acessa-la.
“PostgreSQL mantém a consistência dos dados usando um modelo multiversão.
Neste modelo, cada transação terá sua versão do banco de dados, estando protegidas
de acessar dados inconsistentes que poderiam ser gerados por outras transações.
Portanto, o MVCC oferece o isolamento de transações, alem de garantir que leituras
nunca aguardarão escritas e vice-versa.” (DEVMEDIA,2013).
2.7.3
Características
Segundo Neto (2003), o PostgreSQL segue o padrão SQL, uma linguagem de
interface para banco de dados, possui uma ferramenta chamada PGAdmin que torna a mais
fácil e intuitivo o uso do SGBD e outra denominada Psql que serve para receber os comandos
SQL, alem de possibilitar a manipulação de dados armazenados através de camadas OBDC
(Open Database Connectivity) e JBDC (Java Database Connectivity) ou através do acesso
nativo na linguagem C.
O PostgreSQL é um sistema gerenciador de banco de dados Objeto-Relacional
(SGBDOR), baseado no PostgreSQL, foi o precursor em vários conceitos que só se tornaram
disponível depois por outros SGBDs comerciais. (DEVMEDIA, 2012).
45
Segundo a Infowester (2012) o SGBD PostgreSQL possui recursos comum a banco
de dados de grande porte, além de ser um banco versátil gratuito e de código aberto disponível
sob uma licença BSD, possui características importantes como:
“Compatibilidade multi-plataforma, ou seja, executa em vários sistema operacionais,
como Windows, Mac OS X, Linux e outras variantes de Unix;
Compatibilidade com várias linguagens, entre elas, Java, PHP, Python, Ruby, e
C/C++;
Base de dados de tamanho ilimitado;
Tabelas com tamanho de até 32 TB;
Quantidade de linhas de até 1.6 TB ilimitada;
Campos de até 1 GB;
Suporte a recursos como triggers, views, stored procedures, SSL, MVCC, schemas,
transactions, savepoints, referential integrity e expressões regulares;
“Instruções em SQL, como indica o nome”. (INFOWESTER, 2012).
2.7.4
Arquitetura
O PostgreSQL utiliza o modelo cliente-servidor, onde o programa servidor é
denominado postgres que atende um único cliente que possuem processos do tipo pgaccess
(um cliente gráfico)e psql (um cliente em modo texto).
O processo postmaster é responsável pela implementação de um novo servidor para
cada cliente solicitando uma conexão, Os clientes podem ser executados no mesmo local ou
em computadores remotos conectados por TCP / IP. (DATAPRIX, 2012). A arquitetura do
PostgreSQL é Apresentada na figura 22.
Figura 22 - Arquitetura PostgreSQL
Fonte: (DATAPRIX, 2012)
46
O servidor PostgreSQL pode tratar várias conexões simultâneas de clientes, sendo
iniciado um processo filho para cada conexão, ou seja, a thread independente do postmaster a
partir desse o ponto o processo filho se comunica com o processo postmaster, que se
comunica com os processos filho por meio de IPC (Inter-Process communication) utilizando
variáveis globais para gerenciar ao acesso aos recursos do sistema e sem interferência do
processo original, enquanto o postmaster permanece sempre em execução por espera de novas
conexões dos clientes. (POSTGRESQL GLOBAL DEVELOPMENT GROUP, 2005).
Para finalizar esse capitulo é apresentado na figura 23 um quadro comparativo e
algumas características dos os SGBDs Mysql E PostgreSQL.
Figura 23 - Quadro Comparativo com algumas características do MySQL e PostgreSQL
Quadro Comparativo de Funcionalidades entre os SGBDs MySQL e PostgreSQL
MySQL
PostgreSQL
- Sua primeira surgiu em versão em 1995;
- Desenvolvido por Allan Larsson, David
Axmark e Michael Monty Widenius
Michael Widenius na companhia Suíça
TcX;(INFOWEST,2012);
- Pode ser instalado em múltiplas
plataformas entre as principais podemos
citar: Linux, Windows, Unix;
- Código fonte escrito em C e C++
- Compatibilidades com várias linguagens
de programação entre as principais podem
citar: PHP, Java, Python, C#, Ruby e
C/C++
- possui licença GNU General Public
License (Licença Pública Geral), GNU
GPL ou simplesmente GPL, significa
licença livre.(DEVMEDIA,2013)
- Pertencia a empresa MySQL AB em
1995, depois foi comprada pela SUN que
em 2009 foi vendida Para a ORACLE,
com a condição de manter as duas
licenças(open source,e Comercial )até
2015.(BORBA ON SOFTWARE, 2012);
- Focado na agilidade, segundo site
DEVMEDIA, atualmente é o banco mais
rápido do mercado;
-Sua última versão 5.6 foi lançada pela
ORACLE com maior desempenho e
- Sua primeira versão surgiu em 1996 6.0;
(B2BR.2013);
Desenvolvido por comunidades do mundo
inteiro, porém o projeto gerenciado pela
comunidade PostgreSQL Global Development
Group; (B2BR.2013);
- Pode ser instalado em múltiplas plataformas
entre as principais podemos citar: Linux,
Windows, Unixware,MacOSX,Solaris AIX,;
(B2BR.2013);
- É derivado do pacote POSTGRES escrito na
Universidade da Califórnia em Berkeley na
Califórnia; (B2BR.2013);
- Compatibilidades com várias linguagens de
programação entre as priincipais podem citar:
Java, PHP, Pyton, Perl; (B2BR.2013);
- Possui licença BSD (Berkeley Software
Distribution),
pode
ser
alterado,modificar,copiar ou redistribuir sem
custo de licença; (B2BR.2013);
- Não possui dono e nem empresa, é mantido
por empresas Internacionais e Nacionais como
IBM,SUN,EnterpriseBD,Grenplum,Fujitsu
entre outras,que patrocinam financeiramente
os desenvolvedores; (B2BR.2013);
Robusto: Criado para suportar grande volume;
de dados; (B2BR, 2013);
O Grupo Global do PostgreSQL lançou a
versão 9.2 maior desempenho,escalabilidade e
47
escalabilidade, com capacidade de
replicação
aprimorada
(iMASTERS,2013).
Possui
uma
ferramenta
chamada
Workbench que torna a mais fácil e
intuitivo o uso do SGBD e outra
denominada Shell, que serve para receber
os comandos SQL.
flexibilidade. (PostgreSQL,2013).
Possui uma ferramenta chamada PGAdmin
que torna a mais fácil e intuitivo o uso do
SGBD e outra denominada Psql , que serve
para receber os comandos SQL
Nesse capítulo foram tratados assuntos referentes aos Bancos de dados (MySQL e
PostgreSQL),bem como seus conceitos, características,arquiteturas e um breve histórico de
cada um deles.
Foram abordados também modelos entidade-relacionamento, modelo relacional,
chaves primárias e estrangeiras, processo de Normalizações primeira, segunda e terceira
forma normal.
Linguagem SQL, que segundo Battisti (2006), é uma linguagem padrão de consulta
criada para realizar operações em um banco de dados e foi desenvolvida para ser
independente de hardware e software.
No próximo capítulo será abordado o material e método, onde apresenta a
metodologia utilizada para desenvolvimento desse trabalho de conclusão.
48
3.
MATERIAL E MÉTODOS
Neste capítulo será tratada a classificação da pesquisa, a fundamentação das
informações, a forma como se deu a pesquisa, a coletas dos dados e a informações retiradas
dos dados coletados.
3.1
Classificação da Pesquisa
Quanto aos objetivos esse trabalho, apresenta uma pesquisa qualitativa e objetiva,
tendo em vista que tem com objetivo realizar uma análise dos resultados obtidos na pesquisa
para compreender que fatores possam influenciar na escolha de um SGBD em relação ao
outro. (PRODANOV E FREITAS,2013).
Sendo assim quanto à natureza se enquadra em uma pesquisa aplicada, porque gera
produtos ou processos com finalidade imediata, e utiliza conceitos da pesquisa básicas mais as
tecnologias existentes neste caso os SGBDs, MySQL e PostgreSQL.(PRODANOV E
FREITAS,2013)
Esse trabalho de conclusão se enquadra na categoria de pesquisa explicativa, uma
vez que tem a finalidade de apresentar fundamentos que venha a influenciar na escolha do
SGBDs MySQL ou PostgreSQL.
Já em relação aos procedimentos este trabalho se enquadra na categoria de pesquisa
bibliográfica e de laboratório, bibliográfica porque foi desenvolvido com base em materiais de
livre acesso, como livros, artigos, e de laboratório, porque foi realizado um teste de
desempenho em laboratório.
49
3.2
Principais Fontes de Pesquisa
Foram utilizados diferentes tipos de informações para realização deste trabalho
acadêmico, dentre eles destacam-se Sistema de Banco de dados escrito por Navathe e Elmasri,
PostgreSQL 8.3.0, escrito por Manzano.
Silberschatz e Sudarsham tratando do gerenciamento de transações ACID,
Introdução ao Sistema de Banco de Dados escrito por Date utilizados para as Normalizações,
Cantu falando sobre o histórico da linguagem SQL, MySQL Guia do programador escrito por
Milani e vários sites relacionados ao conteúdo do trabalho.
3.3
Etapas da Pesquisa
Primeiramente foi realizado um estudo bibliográfico, com intuito de coletar
informações sobre as ferramentas utilizadas para realização desse trabalho acadêmico, estudo
esse que se encontra no capítulo anterior.
Logo após foi utilizado um modelo de dados retirado de um sistema gerenciador de
demandas recebidas via email, constituído por 9 tabelas, e a partir dessas tabelas foram
gerados seus scripts de criação e replicados em ambos os bancos.
Para por fim realizar os testes de DML (insert, delete,update,select)nos bancos
MySQL e PostgreSQL, coletando seus tempos de resposta para depois realizar uma análise
com o objetivo de identificar qual banco obteve melhor desempenho, quando aplicado a este
modelo, com ambiente monitorado, podendo sofrer alterações se realizado em outro ambiente,
por exemplo se realizado em um sistema operacional Linux,ou em uma máquina local não
virtualizada.
3.4
Dificuldades Encontradas na Pesquisa
Ao tentar realizar a inserção dos registro foi encontrado uma dificuldade, tendo em
vista que devido ao estouro de tamanho do buffer dos SGBDs , não foi possível realizar a
50
inserção dos registros de uma só vez nas tabelas TB_DEMANDA, TB_USUÁRIO e
TB_HISTÓRICO_DEMANDA, onde foram inseridos 450, 54 e 72 mil registros
respectivamente. Sendo assim tiveram seus registros inseridos em lotes de 18.000. (XOOPS
Brasil,2013).
Apresentou o erro : “Server has gone way”, que segundo o site XOOPS BRASIL,
ocorre quando um usuário tenta inserir registro que não condizem com o banco de dados, que
não foi esse o caso.
O outro motivo é quando ao tentar inserir uma quantidade de registros superior a
capacidade do buffer do SGBD. Então ele entende que alguma coisa está errado e encerra a
conexão. Esse foi o tipo de erro encontrado nesse trabalho.(XOOPS Brasil,2013),
“Você também pode obter estes erros se você enviar uma consulta incorreta ou
muito grande ao servidor. Se mysqld recebe um pacote muito grande ou fora de
ordem. ele assume que alguma coisa saiu errado com o cliente e fecha a conexão. Se
você precisa de grandes consultas (por exemplo, se você está trabalhando com
grandes colunas BLOB), você pode aumentar o limite da consulta iniciando
o mysqld com a opção -O max_allowed_packet=# (padrão 1M). A memória extra é
alocada sobre demanda, assim o mysqld alocará mais memória apenas quando você
executar uma grande consulta ou quando o mysqld deve retornar um grande registro
de resultado!” .(XOOPS Brasil,2013).
Essa possibilidade foi comprovada, através do teste realizado em um SGBD,
instalada na máquina local do ambiente de testes da pesquisa.
Por tanto a solução aplicada para resolução desse problema foi a inserção em lotes de
18.000, que foi o tamanho máximo aceito pelo SGBD.
3.5
Ambiente de Teste
Para que fosse possível concluir uns dos objetivos específicos desse trabalho que é
realizar um teste de desempenho em laboratório utilizando os comandos DML, foi necessário
a criação de um ambiente de teste utilizando um Notebook Intel Core i3, CPU 2.40 GHz,
memória RAM de 3 GB, sistema operacional Windows 7 Professional de 64 Bits. Na figura 24
é apresentada a configuração do ambiente de teste local.
51
Figura 24 - Configuração do ambiente de teste
Então foi criado nesse notebook uma máquina virtual com 1 GB de memória RAM e
25 GB de espaço em disco e sistema operacional Windows 7 Home Premium de 32 bits,
utilizando o software VirtualBox versão 4.1.22.0 e criado um clone dessa máquina, ficando
assim com duas maquinas virtuais com as mesmas configurações. Conforme apresentado na
figura 25.
Figura 25 - Ambiente de teste virtualizado com dois Sistemas Operacionais Windows 7
A figura 26 apresenta a configuração da máquina virtual com o banco de dados
MySQL versão 5.5 já instalado.
52
Figura 26 - Configuração máquina virtual com o SGBD MYSQL
Já a figura 27 apresenta as configurações da máquina virtual clonada já com o SGBD
PostgreSQL versão 8.3 já instalado.
Figura 27 - Configuração máquina virtual com o SGBD POSTGRESQL
Logo após a criação das máquinas virtuais e instalação dos SGBD MySQL e
PostgreSQL, o próximo passo foi à utilização do modelo Lógico composto por 9
tabelas,modelo esse retirado de um projeto de sistema que tem como objetivo armazenar e
tramitar demandas recebidas via email no âmbito de uma empresa, este modelo foi
desenvolvido utilizando a ferramenta Workbench versão 5.2.43 ce . A figura 28 apresenta o
modelo lógico desenvolvido no workbench.
53
Figura 28 - Modelo Lógico
Ainda com a utilização da ferramenta workbench foi gerado um arquivo. sql com os
scripts de create table a serem utilizados na criação das tabelas nos bancos MySQL e
PostgreSQL. A figura 29 apresenta o script de criação das tabelas.
54
Figura 29 - Script de Criação das Tabelas
TB_UF
CREATE TABLE TB_UF(
ID_UF INT NOT NULL,
NOME_UF VARCHAR (45) NOT NULL,
PRIMARY KEY (ID_UF));
TB_STATUS_DEMANDA
CREATE TABLE TB_STATUS_DEMANDA(
ID_STATUS INT NOT NULL,
STATUS VARCHAR (45) NOT NULL,
PRIMARY KEY (ID_STATUS));
TB_SETOR
CREATE TABLE TB_SETOR(
ID_SETOR INT NOT NULL,
ID_UF INT NOT NULL,
NOME_SETOR VARCHAR (45) NOT NULL,
PRIMARY KEY (ID_SETOR),
CONSTRAINT FK_TB_UF FOREING KEY (ID_UF)
REFERENCES TB_UF (ID_UF));
TB_USUARIO
CREATE TABLE TB_USUARIO(
CPF_USUARIO VARCHAR (45),
ID_USUARIO INT NOT NULL,
ID_PERFIL INT NOT NULL,
ID_SETOR INT NOT NULL,
LOGIN_USUARIO VARCHAR (45) NOT NULL,
NOME_USUARIO VARCHAR (45) NOT NULL,
SENHA_USUARIO VARCHAR (45) NOT NULL,
RAMAL VARCHAR (45) NOT NULL,
PRIMARY KEY (ID_USUARIO),
CONSTRAINT FK_TB_PERFIL_USUARIO FOREING KEY
(ID_PERFIL) REFERENCES TB_PERFIL_USUARIO
(ID_PERFIL),
CONSTRAINT FK_TB_SETOR FOREING KEY
(ID_SEOR)REFERENCES TB_SETOR (ID_SETOR));
TB_PRIORIDADE_DEMANDA
CREATE TABLE
TB_PRIORIDADE_DEMANDA(
ID_PRIORIDADE_DEMANDA INT NOT
NULL,
TIPO_PRIORIDADE VARCHAR (45) NOT
NULL,
PRIMARY KEY
(ID_PRIORIDADE_DEMANDA));
TB_PERFIL_USUARIO
CREATE TABLE TB_PERFIL_USUARIO(
ID_PERFIL INT NOT NULL,
TIPO_PERFIL VARCHAR (45) NOT NULL,
PRIMARY KEY (ID_PERFIL));
TB_RESPONSAVEL
CREATE TABLE TB_RESPONSAVEL(
ID_RESPONSAVEL INT NOT NULL,
ID_USUARIO INT NOT NULL,
PRIMARY KEY (ID_RESPONSAVEL),
CONSTRAINT FK_TB_USUARIO FOREING
KEY (ID_USUARIO)
REFERENCES TB_USUARIO (ID_USUARIO));
TB_DEMANDA
CREATE TABLE TB_DEMANDA(
ID_DEMANDA INT NOT NULL,
ID_USUARIO INT NOT NULL,
ID_PRIORIDADE_DEMANDA INT NOT
NULL,
ID_RESPONSAVEL INT NOT NULL,
ID_STATUS INT NOT NUL,
DATA_HORA_CRIACAO DATETIME NOT
NULL,
DATA_HORA_CONCLUSAO DATETIME NOT
NULL,
OBSERVACAO VARCHAR (500) NOT NULL,
ASSUNTO VARCHAR (300) NOT NULL,
PRIMARY KEY (ID_DEMANDA)
,CONSTRAINT
FK_TB_PRIORIDADE_DEMANDA1 FOREING
KEY (ID_PRIORIDADE_DEMANDA)
REFERENCES TB_PRIORIDADE_DEMANDA
(ID_PRIORIDADE_DEMANDA),CONSTRAINT
FK_TB_USUARIO1 FOREING KEY
(ID_USUARIO)REFERENCES TB_USUARIO
(ID_USUARIO), CONSTRAINT
FK_RESPONSAVEL1 FOREING
KEY(ID_RESPONSAVEL) REFERENCES
TB_ID_RESPONSAVEL
(ID_RESPONSAVEL),CONSTRAINT
FK_TB_STATUS_DEMANDA1 FOREING KEY
(ID_STATUS)REFERENCES
TB_STATUS_DEMANDA(ID_STATUS));
TB_HISTORICO_DEMANDA
55
CREATE TABLE TB_HISTORICO_DEMANDA(
ID_HISTORICO INT NOT NULL,
ID_DEMANDA INT NOT NULL,
ID_RESPONSAVEL INT NOT NULL,
ID_STATUS INT NOT NUL,
NOME_HISTORICO VARCHAR NOT NULL,
DATA_HORA_CRIACAO DATETIME NOT NULL,
DATA_HORA_CONCLUSAO DATETIME NOT NULL,
OBSERVACAO VARCHAR (500) NOT NULL,
PRIMARY KEY (ID_HISTORICO) ,
CONSTRAINT FK_TB_DEMANDA2 FOREING KEY (ID_DEMANDA) REFERENCES TB_DEMANDA
(ID_DEMANDA),
CONSTRAINT FK_TB_RESPONSAVEL2 FOREING KEY (ID_RESPONSAVEL)
REFERENCES TB_RESPONSAVEL(ID_RESPONSAVEL),
CONSTRAINT FK_TB_STATUS_DEMANDA2 FOREING KEY (ID_STATUS)REFERENCES
TB_STATUS_DEMANDA(ID_STATUS));
Logo após ter criado os SGBDS em ambos os bancos, com a utilização do script
acima, a próxima etapa foi gerar uma base de dados utilizando a ferramenta datagenerator,
um script de código aberto escrito em Java Script, PHP e MySQL utilizado para gerar grande
massa de dados personalizados em vários formatos inclusive arquivo. Sql,utilizados para
inserir dados nos SGBDS.
Os dados gerados foram replicados nos dois bancos, para a inserção dos dados no
MySQL foi utilizado o workbench, já no PostgreSQL, foi utilizado o PGAdmin, formando
assim um base de dados com a mesma quantidade de registros e tipo de dados em ambos os
bancos.
Nas figuras 30, 31, 32 apresentam os comandos utilizados para realização dos testes
nos SGBDS,com os quesitos utilizados para o teste de desempenho, assim como o percentual
de diferença dos resultados obtidos entre os SGBDS MySQL e PostgreSQL.
Ressaltando que pelo fato de que os comandos de insert são de grande volume, uma
vez que a tabela TB_DEMANDA possui 450.000 mil registros, a tabela TB_USUARIO
72.000 mil e a tabela TB_HISTORICO_DEMANDA 54.000 mil, se fez necessário armazenar
esses inserts em um CD, que se encontrão no apêndice F, desse trabalho, e no apêndice A,
encontra-se apenas uma amostra dos comandos de inserção utilizados para alimentar os
SGBD.
Com o objetivo de não favorecer nem um banco de dados durante a realização dos
testes, forma tomadas algumas precações:
- Durante a realização dos testes no SGBD MySQL em uma máquina virtual, a outra
será desligada e vice versa, para que não haja interferência nos resultados.
56
-As tabelas de ambos os SGBDS, possuem índex em suas tabelas, que apesar de
consumirem muito espaço em disco, sua criação é muito útil para desempenho dos bancos de
dados.
“Os índices são criados para direcionar o otimizador de consultas na hora de
localizar os registros desejados, de acordo com o filtro informado no momento da
consulta sql para evitar um seq scan e funcionam exatamente como um índice de um
livro: diz em que página está cada conteúdo”.(BAUdeDEV.COM, 2013).
- Os comandos dos testes serão realizados 3 vezes seguidas, retirando uma Média
Aritmética Simples.
- Para cada teste realizado o computador será reiniciado;
A figura 30 apresenta os 8 comandos de select utilizados para teste consultas nos
SBGDS.
Figura 30 - Códigos SQL utilizados nos testes de Select
N°
SELECT
SELECT
U.ID_USUARIO,
H.NOME_HISTORICO,
D.DATA_HORA_CRIACAO,
D.ID_DEMANDA,
H.ID_HISTORICO,
S.ID_STATUS,
D.ID_DEMANDA
H.OBSERVACAO
FROM TB_USUARIO U
FROM TB_HISTORICO_DEMANDA H
1 INNER JOIN TB_DEMANDA D
2 INNER JOIN TB_DEMANDA D
ON U.ID_USUARIO = D.ID_DEMANDA
ON D.ID_DEMANDA = H.ID_DEMANDA
INNER JOIN TB_HISTORICO_DEMANDA H
INNER JOIN TB_STATUS_DEMANDA S
ON H.ID_HISTORICO = D.ID_DEMANDA
ON S.ID_STATUS = H.ID_STATUS
WHERE U.ID_USUARIO BETWEEN 1 AND
WHERE H.NOME_HISTORICO LIKE
56200 ORDER BY DATA_HORA_CRIACAO
'%E%' ORDER BY NOME_HISTORICO
SELECT
SELECT
3
SELECT
D.ID_DEMANDA,
S.NOME_SETOR,
D.ASSUNTO,
S.ID_SETOR,
D.DATA_HORA_CRIACAO,
U.LOGIN_USUARIO,
D.DATA_HORA_CONCLUSAO,
UF.NOME_UF,
U.NOME_USUARIO,
UF.ID_UF
CPF_USUARIO,
FROM TB_SETOR S
4 INNER JOIN TB_USUARIO U
R.ID_RESPONSAVEL
FROM TB_DEMANDA D
ON S.ID_SETOR = U.ID_USUARIO
INNER JOIN TB_USUARIO U
INNER JOIN TB_UF UF
ON D.ID_DEMANDA = U.ID_USUARIO
ON S.ID_SETOR = UF.ID_UF
INNER JOIN TB_RESPONSAVEL R
WHERE UF.ID_UF BETWEEN 1 AND 700
ON U.ID_USUARIO = R.ID_RESPONSAVEl
ORDER BY SETOR
WHERE D.ID_DEMANDA BETWEEN 50 AND
150000 ORDER BY DATA_HORA_CRIACAO
57
SELECT
SELECT
D.ID_DEMANDA,
D.DATA_HORA_CRIACAO,
U.NOME_USUARIO,
U.CPF_USUARIO,U.RAMAL,
R.ID_RESPONSAVEL,P.
ID_PERFIL,P.TIPO_PERFIL
FROM TB_DEMANDA D
5
INNER JOIN TB_USUARIO U
ON D.ID_DEMANDA = U.ID_USUARIO
INNER JOIN TB_RESPONSAVEL R
ON D.ID_DEMANDA = R.ID_RESPONSAVEL
INNER JOIN TB_PERFIL_USUARIO P
ON D.ID_DEMANDA = P.ID_PERFIL
WHERE U.ID_USUARIO <= 8000
AND U.NOME_USUARIO LIKE '%a'
ORDER BY DATA_HORA_CRIACAO
D.ID_DEMANDA,
D.DATA_HORA_CRIACAO,
D.ASSUNTO,
S.STATUS,
P.TIPO_PRIORIDADE
FROM TB_DEMANDA D
INNER JOIN TB_STATUS_DEMANDA S
6
ON S.ID_STATUS = D.ID_STATUS
INNER JOIN TB_PRIORIDADE_DEMANDA
P
ON P.ID_PRIORIDADE_DEMANDA =
D.ID_PRIORIDADE_DEMANDA
WHERE D.DATA_HORA_CRIACAO <
'2019-01-04 12:24:54'
ORDER BY TIPO_PRIORIDADE
SELECT
SELECT
F.NOME_USUARIO,
F.LOGIN_USUARIO,
F.CPF_USUARIO,
C.TIPO_PERFIL,
C.TIPO_PERFIL,
D.NOME_SETOR
7 FROM TB_USUARIO F INNER JOIN
TB_PERFIL_USUARIO CON C.ID_PERFIL =
F.ID_PERFIL INNER JOIN TB_SETOR D
ON D.ID_SETOR = F.ID_SETOR
WHERE F.ID_USUARIO BETWEEN 1879
AND 59781
D.ID_DEMANDA,D.DATA_HORA_
CRIACAO,
U.ID_USUARIO,U.CPF_USUARIO,
P.TIPO_PRIORIDADE
FROM TB_DEMANDA D INNER JOIN
TB_USUARIO U ON D.ID_DEMANDA =
8 U.ID_USUARIO INNER JOIN
TB_PRIORIDADE_DEMANDA P
ON D.ID_DEMANDA =
P.ID_PRIORIDADE_DEMANDA
AND ID_DEMANDA < 250000
ORDER BY TIPO_PRIORIDADE
A figura 31 apresenta os 6 comandos de updates utilizados para teste de alterações
nas tabelas nos SBGDS.
Figura 31 - Códigos SQL utilizados nos testes de Update
UPDATE
N°
1
UPDATE TB_USUARIO
SET NOME_USUARIO = 'MAGDIEL PEREIRA'
WHERE ID_USUARIO BETWEEN 1 AND
2
40000 AND ID_PERFIL>700
UPDATE TB_DEMANDA
SET OBSERVACAO = 'ESTOU
CONSEGUINDO'
WHERE ID_DEMANDA BETWEEN 1587
AND 2543;
58
3
5
UPDATE TB_DEMANDA
SET DATA_HORA_CRIACAO = '2013-05-04
12:15:09',ASSUNTO = 'TESTE UPDATE'
WHERE ID_DEMANDA > 400000 AND
ID_USUARIO >71500
UPDATE
UPDATE TB_USUARIO
SET SENHA_USUARIO = 'SENHA
FRACA',LOGIN_USUARIO = 'MIKE
SMITH',NOME_USUARIO
='MAGDIEL',RAMAL ='0000'
WHERE ID_USUARIO BETWEEN 1 AND
70000 AND ID_SETOR < 400
UPDATE TB_HISTORICO_DEMANDA
SET NOME_HISTORICO ='CHAMADO
ABERTO JUNTO AO SERPRO',
OBSERVACAO = 'CHAMADO ATENDIDO
4 '
WHERE ID_HISTORICO BETWEEN 38000
AND 52487
UPDATE TB_DEMANDA
SET ASSUNTO = 'SETAR SENHA HOD
',OBSERVACAO = 'PARA USUARIO MIKE'
6 WHERE ID_DEMANDA >420000 AND
ID_PRIORIDADE_DEMANDA > 590
A figura 32 apresenta os 6 comandos de Deletes para apagar dados nas tabelas nos
SBGDS.
Figura 32 - Códigos SQL utilizados nos testes de Delete
DELETE
N°
DELETE FROM TB_DEMANDA
WHERE ID_DEMANDA BETWEEN 158700
1 AND 254300 AND DATA_HORA_CRIACAO > 2
'2019-01-05 13:34:00'
AND ASSUNTO LIKE '%A'
DELETE
DELETE FROM TB_HISTORICO_DEMANDA
WHERE ID_HISTORICO_DEMANDA > =
3 35500
4
AND DATA_HORA_CONCLUSA <= '2020-0103 02:30:56'
DELETE
DELETE FROM TB_PERFIL_USUARIO
WHERE ID_PERFIL >= 1 AND TIPO_PERFIL
5 LIKE’%i’
6
DELETE FROM TB_UF
WHERE ID_UF > = 500
AND NOME_UF LIKE '%D'
DELETE FROM TB_USUARIO
WHERE NOME_USUARIO LIKE '%M'
AND ID_USUARIO BETWEEN 15087
AND 67543;
DELETE FROM
TB_HISTORICO_DEMANDA WHERE
ID_HISTORICO <= 53990 ANDA
DATA_HORA_CRIACAO <= ‘2020-01-01
03:02:40’
Neste Capítulo foi apresentada a classificação da pesquisa, principais fontes da
pesquisa, as etapas utilizadas para realização da pesquisa, bem como o ambiente de teste
utilizado para realização da pesquisa laboratorial.
59
4.
RESULTADOS E ANÁLISES
Neste capítulo estão apresentados os resultados obtidos nos testes realizados em
laboratórios com os SGBDS MySQL e PostgreSQL, bem como uma análise desses resultados
de formas individuais e uma análise geral, visando facilitar a compreensão.
4.1
RESULTADO
Nesse capítulo estão apresentados os resultados separados por comandos DML, com
o objetivo de identificar os tempos utilizados para realização de cada comando.
Vale apena ressaltar que os SGBDS, fornecem tempos em unidades de medidas de
tempo diferentes, o SGBD MySQL, em segundos e o PostgreSQL em milissegundos, que
corresponde a um milésimo de segundo. (CONVERTWORD.COM, 2013).
Surgindo a necessidade de padronizar as medidas de tempo para facilitar na análise
dos resultados. Neste trabalhou os resultados de milissegundos oferecidos pelo PostgreSQL
foram convertidos para segundo através do site CONVERTWORD.COM.
4.1.1 RESULTADOS DOS TESTES DE INSERÇÃO
Nesse capítulo será apresentado apenas às tabelas com as quantidades de registros
inseridos em cada tabela em ambos os SGBDS, lembrando que os print de inserções dos
registros das tabelas se encontram no Apêndice B desse trabalho, localizado na página 94.
Vale apena ressaltar que devido ao estouro do buffer de memória nos SGBDS, não
foi possível realizar a inserção por total dos registros, nas tabelas TB_DEMANDA,
TB_HISTORICO_DEMANDA e TB_USUÁRIO sendo assim concluída em lotes de 18.000
registros cada, gerando assim vários prints de tela dessas tabelas, surgindo à necessidade de
incluí-las no apêndice B e não no corpo do trabalho.
60
Para essas tabelas que tiveram seus registros inseridos em lotes, foi criado um
gráfico, com o intuito de visualizar as diferenças entre as inserções dos lotes, bem como uma
analise no tempo geral de inserção.
As diferenças percentuais entre os tempos de um SGBD e outro foram calculados
com a utilização da fórmula do Excel com função ABS conforme exemplo da figura 33.
Figura 33 – Fórmula para calcular a diferença percentual entre dois valores
Diferença percentual = (A2-A1)/ABS (A1) * 100
Fonte (OFFICE, 2013)
As tabelas que apresenta informações sobre a diferença percentual entre os SGBDS
foi calculada tendo como base o MySQL, então as diferenças percentuais apresentadas são do
MySQL em relação ao PostgreSQL, que teria outro resultado se calculado tendo como base o
PostgreSQL.
A tabela 1 abaixo apresenta o tempo em segundos, utilizado para inserção de dados
na tabela TB_PERFIL_USUARIO, no SGBD MySQL.
Tabela 1 - Quantidade de registros inseridos na tabela TB_PERFIL_USUARIO, no SGBD MySQL
TB_PERFIL_USUARIO
Lotes
1
Total
Banco de dados MySQL
Tempo de Inserção em
Quantidade Registros
Segundos
1010
0,561
1010
0,561
A tabela 2 apresenta o tempo em segundos, utilizado para inserção de dados na tabela
TB_PERFIL_USUARIO, no SGBD PostgreSQL.
Tabela 2 - Quantidade de registros inseridos na tabela TB_PERFIL_USUARIO, no SGBD PostgreSQL
TB_PERFIL_USUARIO
Lotes
1
Total
Banco de dados PostgreSQL
Tempo de Inserção em
Quantidade Registros
Segundos
1010
0,120
1010
0,120
A tabela 3 apresenta a diferença percentual na inserção de dados da tabela
TB_PERFIL_USUARIO, nos SGBDS MySQL e PostgreSQL.
61
Tabela 3 - Diferença percentual no quesito inserção na TB_PERFIL_USUARIO, nos SGBDS MySQL e
PostgreSQL
TB_PERFIL_USUARIO
Lotes
MySQL
PostgreSQL
Diferença Percentual
1
0,561
0,120
PostgreSQL 367,50% + rápido
A tabela 4 apresenta o tempo em segundos, utilizado para inserção de dados na tabela
TB_SETOR, no SGBD MySQL.
Tabela 4 - Quantidade de registros inseridos na tabela TB_SETOR, no SGBD MySQL
TB_SETOR
Lotes
1
Banco de dados MySQL
Tempo de Inserção em
Quantidade Registros
Segundos
927
0,351
Total
927
0,351
A tabela 5 apresenta o tempo em segundos, utilizado para inserção de dados na tabela
TB_SETOR, no SGBD PostgreSQL.
Tabela 5 - Quantidade de registros inseridos na tabela TB_SETOR, no SGBD PostgreSQL
TB_SETOR
Lotes
1
Banco de dados PostgreSQL
Tempo de Inserção em
Quantidade Registros
Segundos
927
0,081
Total
927
0,081
A tabela 6 apresenta a diferença percentual na inserção de dados da tabela
TB_SETOR, nos SGBDS MySQL e PostgreSQL.
Tabela 6 - Diferença percentual no quesito inserção na TB_SETOR, nos SGBDS MySQL e PostgreSQL
TB_SETOR
Lotes
MySQL
PostgreSQL
Diferença Percentual
1
0,351
0,081
PostgreSQL 333,33% + rápido
A tabela 7 apresenta o tempo em segundos, utilizado para inserção de dados na tabela
TB_PRIORIDADE_DEMANDA, no SGBD MySQL.
62
Tabela 7 - Quantidade de registros inseridos na tabela TB_PRIORIDADE_DEMANDA, no SGBD
MySQL
TB_PRIORIDADE_DEMANDA
Lotes
1
Banco de dados MySQL
Tempo de Inserção em
Quantidade Registros
Segundos
1015
0,401
Total
1015
0,401
A tabela 8 apresenta o tempo em segundos, utilizado para inserção de dados na tabela
TB_PRIORIDADE_DEMANDA, no SGBD PostgreSQL.
Tabela 8 - Quantidade de registros inseridos na tabela TB_PRIORIDADE_DEMANDA, no SGBD
PostgreSQL
TB_PRIORIDADE_DEMANDA
Lotes
1
Banco de dados PostgreSQL
Tempo de Inserção em
Quantidade Registros
Segundos
1015
0,120
Total
1015
0,120
A tabela 9 apresenta a diferença percentual na inserção de dados da tabela
TB_PRIORIDADE_DEMANDA, nos SGBDS MySQL e PostgreSQL.
Tabela 9 - Diferença percentual no quesito inserção na TB_PRIORIDADE_DEMANDA, nos SGBDS
MySQL e PostgreSQL
TB_PRIORIDADE_DEMANDA
Lotes
MySQL
PostgreSQL
Diferença Percentual
1
0,401
0,120
PostgreSQL 234,17% + rápido
A tabela 10 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_STATUS_DEMANDA, no SGBD MySQL.
Tabela 10 - Quantidade de registros inseridos na tabela TB_STATUS_DEMANDA, no SGBD MySQL
TB_STATUS_DEMANDA
Lotes
1
Total
Banco de dados MySQL
Tempo de Inserção em
Quantidade Registros
Segundos
1008
0,180
1008
0,180
A tabela 11 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_STATUS_DEMANDA, no SGBD PostgreSQL.
63
Tabela 11 - Quantidade de registros inseridos na tabela TB_STATUS_DEMANDA, no SGBD PostgreSQL
TB_STATUS_DEMANDA
Lotes
1
Banco de dados PostgreSQL
Tempo de Inserção em
Quantidade Registros
Segundos
1008
0,060
Total
1008
0,060
A tabela 12 apresenta a diferença percentual na inserção de dados da tabela
TB_STATUS_DEMANDA, nos SGBDS MySQL e PostgreSQL.
Tabela 12 - Diferença percentual no quesito inserção na TB_STATUS_DEMANDA, nos SGBDS MySQL e
PostgreSQL
TB_STATUS_DEMANDA
Lotes
MySQL
PostgreSQL
Diferença Percentual
1
0,180
0,060
PostgreSQL 200,00% + rápido
A tabela 13 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_UF, no SGBD MySQL.
Tabela 13 - Quantidade de registros inseridos na tabela TB_UF, nos SGBD MySQL
TB_UF
Lotes
1
Banco de dados MySQL
Tempo de Inserção em
Quantidade Registros
Segundos
827
0,270
Total
827
0,270
A tabela 14 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_UF, no SGBD PostgreSQL.
Tabela 14 - Quantidade de registros inseridos na tabela TB_UF, nos SGBD PostgreSQL
TB_UF
Lotes
1
Banco de dados PostgreSQL
Tempo de Inserção em
Quantidade Registros
Segundos
827
0,050
Total
827
0,050
A tabela 15 apresenta a diferença percentual na inserção de dados da tabela TB_UF,
nos SGBDS MySQL e PostgreSQL.
64
Tabela 15 - Diferença percentual no quesito inserção na TB_UF, nos SGBDS MySQL e PostgreSQL
TB_UF
Lotes
MySQL
PostgreSQL
Diferença Percentual
1
0,270
0,050
PostgreSQL 440,00% + rápido
A tabela 16 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_USUARIO, no SGBD MySQL.
Tabela 16 - Quantidade de registros inseridos na tabela TB_USUARIO, no SGBD MySQL
TB__USUARIO
Lotes
1
Banco de dados MySQL
Tempo de Inserção em
Quantidade Registros
Segundos
18.000
1,953
2
18.000
2,864
3
18.000
1,833
4
18.000
Total
72.000
1,973
8,623
A tabela 17 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_USUARIO, no SGBD PostgreSQL.
Tabela 17 - Quantidade de registros inseridos na tabela TB_USUARIO, no SGBD PostgreSQL
TB_USUARIO
Lotes
1
Banco de dados PostgreSQL
Tempo de Inserção em
Quantidade Registros
Segundos
18.000
2,804
2
18.000
2,313
3
18.000
2,734
4
18.000
Total
72.000
2,754
10,605
A tabela 18 apresenta a diferença percentual na inserção de dados da tabela
TB_USUARIO, nos SGBDS MySQL e PostgreSQL.
65
Tabela 18 - Diferença percentual no quesito inserção na TB_USUARIO, nos SGBDS MySQL e
PostgreSQL
TB_USUARIO
Lotes
PostgreSQL
Diferença Percentual
1,953
2,804
MySQL 30,35% + rápido
2,864
2,313
PostgreSQL 23,82% + rápido
3
1,833
2,734
MySQL 32,96% + rápido
4
1,973
8,623
2,754
10,605
MySQL 28,36% + rápido
1
2
Total
MySQL
MySQL 18,69% + rápido
O Gráfico 1 abaixo apresenta detalhes da tabela 18, onde ocorreu a inserção dos
registros na tabela TB_USUARIO,realizadas com os 4 lotes, nos SGBDS MySQL e
PostgreSQL.
Gráfico 1- Inserção de Registros na Tabela TB_USUARIO por lotes nos SGBDS MySQL e PostgreSQL
No que diz respeito à inserção dos dados na tabela TB_USUARIO, percebesse que o
MySQL obteve um melhor desempenho diante do PostgreSQL, tendo perdido apenas na
inserção do segundo lote, onde o PostgreSQL obteve um melhor resultado com um percentual
de 23,82% mais rápido que o MySQL, sendo que na soma geral dos tempos de inserção, o
MySQL obteve um melhor resultado com um percentual de 18,69% mais rápido que o
PostgreSQL.
66
A tabela 19 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_DEMANDA, no SGBD MySQL.
Tabela 19 - Quantidade de registros inseridos na tabela TB_DEMANDA, no SGBD MySQL
TB_DEMANDA
Lotes
1
Banco de dados MySQL
Tempo de Inserção em
Quantidade Registros
Segundos
18.000
5,117
2
18.000
5,458
3
18.000
4
18.000
3,025
2,263
5
18.000
2,594
6
18.000
4,437
7
18.000
6,810
8
18.000
5,417
9
18.000
21,641
10
18.000
15,712
11
18.000
15,792
12
18.000
15,983
13
18.000
18,176
14
18.000
17,024
15
18.000
15,983
16
18.000
18,267
17
18.000
27,490
18
18.000
35,681
19
18.000
17,155
20
18.000
15,722
21
18.000
17,765
22
18.000
16,454
23
18.000
16,914
24
18.000
16,414
25
18.000
15,973
Total
450.000
353,267
A tabela 20 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_DEMANDA, no SGBD PostgreSQL.
67
Tabela 20 - Quantidade de registros inseridos por lote na tabela TB_DEMANDA, no SGBD PostgreSQL
TB_DEMANDA
Lotes
1
Banco de dados PostgreSQL
Tempo de Inserção em
Quantidade Registros
Segundos
18.000
3,946
2
18.000
3,785
3
18.000
4
18.000
24,135
9,093
5
18.000
7,409
6
18.000
7,152
7
18.000
4,410
8
18.000
7,445
9
18.000
10,873
10
18.000
6,078
11
18.000
4,437
12
18.000
8,843
13
18.000
15,102
14
18.000
10,205
15
18.000
13,058
16
18.000
7,751
17
18.000
12,518
18
18.000
8,122
19
18.000
13,552
20
18.000
13,198
21
18.000
14,891
22
18.000
10,577
23
18.000
11,369
24
18.000
17,515
25
18.000
12,277
Total
450.000
257,741
A tabela 21 apresenta a diferença percentual na inserção de dados da tabela
TB_DEMANDA, nos SGBDS MySQL e PostgreSQL.
68
Tabela 21 - Diferença em percentual de cada lote da tabela tb_demanda por SGBD
TB_DEMANDA
Lotes
PostgreSQL
Diferença Percentual
5,117
3,946
PostgreSQL 29,68% + rápido
5,458
3,785
PostgreSQL 44,20% + rápido
3,025
2,263
24,135
9,093
MySQL 87,47% + rápido
4
5
2,594
7,409
MySQL 64,99% + rápido
6
4,437
7,152
MySQL 37,96% + rápido
7
6,810
4,410
PostgreSQL 54,42% + rápido
8
5,417
7,445
MySQL 27,24% + rápido
1
2
3
MySQL
MySQL 75,11% + rápido
9
21,641
10,873
PostgreSQL 99,03% + rápido
10
15,712
6,078
PostgreSQL 158,51% + rápido
11
15,792
4,437
PostgreSQL 255,92% + rápido
12
15,983
8,843
PostgreSQL 80,74% + rápido
13
18,176
15,102
PostgreSQL 20,35% + rápido
14
17,024
10,205
PostgreSQL 66,82% + rápido
15
15,983
13,058
PostgreSQL 22,40% + rápido
16
18,267
7,751
PostgreSQL 135,67% + rápido
17
27,490
12,518
PostgreSQL 119,60% + rápido
18
35,681
8,122
PostgreSQL 339,31% + rápido
19
17,155
13,552
PostgreSQL 26,59% + rápido
20
15,722
13,198
PostgreSQL 19,12% + rápido
21
17,765
14,891
PostgreSQL 19,30% + rápido
22
16,454
10,577
PostgreSQL 55,56% + rápido
23
16,914
11,369
PostgreSQL 48,77% + rápido
24
16,414
17,515
MySQL 6,29% + rápido
25
15,973
12,277
PostgreSQL 30,11% + rápido
Total
353,267
257,741
PostgreSQL 37,06% + rápido
O Gráfico 2 apresenta detalhes da tabela 21, onde ocorreu a inserção dos registros na
tabela demanda realizadas em 25 lotes de 18.000 mil registros, nos SGBDS MySQL e
PostgreSQL,
69
Gráfico 2 - Inserção de Registros na Tabela TB_DEMANDA por lotes nos SGBDS MySQL e PostgreSQL
70
No gráfico 2 é plausível verificar que o MySQL foi superior
em relação ao
PostgreSQL em apenas 6 dos 25 lotes, no 3º,4º,5º,6º,8º e 24º, sendo que seu maior percentual
foi no 3º lote onde foi superior em 87,47%
e obteve menor percentual no 24° lote sendo
superior em apenas 6,29% em relação ao PostgreSQL
Já o PostgreSQL foi superior em relação ao MySQL nos outros 19 lotes sendo que
seu maior percentual foi no 18º lote onde foi superior em 339,31%
e obteve seu menor
percentual no 20° lote, sendo superior em apenas 19,12% em relação ao MySQL.
Na análise geral de inserção de dados na tabela TB_DEMANDA, foi verificado que
na soma total dos tempos de inserções, que o PostgreSQL foi superior em relação ao MySQL
em 37,06%.
Tabela 22 - Quantidade de registros inseridos na tabela TB_RESPONSAVEL, no SGBD MySQL
TB_RESPONSAVEL
Lotes
1
Banco de dados MySQL
Tempo de Inserção em
Quantidade Registros
Segundos
710
0,230
Total
710
0,230
A tabela 23 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_RESPONSAVEL, no SGBD PostgreSQL.
Tabela 23 - Quantidade de registros inseridos na tabela TB_RESPONSAVEL, no SGBD PostgreSQL
TB_RESPONSAVEL
Lotes
1
Banco de dados PostgreSQL
Tempo de Inserção em
Quantidade Registros
Segundos
710
0,570
Total
710
0,570
A tabela 24 apresenta a diferença percentual na inserção de dados da tabela
TB_RESPONSAVEL, nos SGBDS MySQL e PostgreSQL.
Tabela 24 - Diferença percentual no quesito inserção na TB_RESPONSAVEL, no SGBD MySQL
TB_RESPONSAVEL
Lotes
MySQL
PostgreSQL
Diferença Percentual
1
0,230
0,570
MySQL 59,65% + rápido
71
A tabela 25 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_HISTORICO_DEMANDA, no SGBD MySQL.
Tabela 25 - Quantidade de registros inseridos na tabela TB_HISTORICO_DEMANDA no SGBD MySQL
TB_HISTORICO_DEMANDA
Lotes
1
Banco de dados MySQL
Tempo de Inserção
Quantidade Registros
em Segundos
18.000
324,026
2
18.000
142,615
3
18.000
Total
54.000
359,587
826,228
A tabela 26 apresenta o tempo em segundos, utilizado para inserção de dados na
tabela TB_HISTORICO_DEMANDA, no SGBD PostgreSQL.
Tabela 26 - Quantidade de registros inseridos na tabela TB_HISTORICO_DEMANDA, no SGBD
PostgreSQL
TB_HISTORICO_DEMANDA
Lotes
1
Banco de dados PostgreSQL
Tempo de Inserção
Quantidade Registros
em Segundos
18.000
27,800
2
18.000
17,205
3
18.000
Total
54.000
30,013
75,018
A tabela 27 apresenta a diferença percentual na inserção de dados da tabela
TB_HISTORICO_DEMANDA, nos SGBDS MySQL e PostgreSQL.
Tabela 27 - Diferença percentual de cada lote da TB_HISTORICO_DEMANDA, por SGBD
TB_HISTORICO_DEMANDA
Lotes
MySQL
PostgreSQL
Diferença Percentual
1
324,026
27,800
PostgreSQL 10655,61% + rápido
2
142,615
17,205
PostgreSQL 7289,16% + rápido
3
359,587
826,228
30,013
75,018
PostgreSQL 10981,04% + rápido
Total
PostgreSQL 10013,73% + rápido
O Gráfico 3 apresenta detalhes da tabela 27, onde ocorreu a inserção dos registros na
tabela TB_HISTORICO_DEMANDA realizadas em 3 lotes de 18.000 mil registros, nos
SGBDS MySQL e PostgreSQL.
72
Gráfico 3 - Inserção de Registros na Tabela TB_HISTORICO_DEMANDA por lotes nos SGBDS MySQL
e PostgreSQL
No gráfico 3 é plausível verificar que o MySQL foi inferior em todos os 3 lotes em
relação ao PostgreSQL,chegando a ser inferior em mais de 10.981% no 3º lote, em relação ao
PostgreSQL.
Na análise geral de inserção de dados na tabela TB_HISTORICO_DEMANDA, foi
verificado que na soma total dos tempos de inserções, o PostgreSQL foi superior em relação
ao MySQL em 10.013,73%.
Na tabela 28 é apresentada a quantidade de registros pertencentes a cada tabela em
ambos os SGBDS.
73
Tabela 28 - Quantidade de registros pertencentes a cada tabela nos SGBDs
TABELA
QUANTIDADE DE REGISTROS
TB_DEMANDA
450.000
TB_USUARIO
72.000
TB_PERFIL-USUARIO
1.010
TB_SETOR
927
TB_UF
827
TB_PRIORIDADE_DEMANDA
1.015
TB_HISTORICO_DEMANDA
54.000
TB_RESONSAVEL
1.010
TB_STATUS_DEMANDA
1.008
Já na tabela 29 apresenta o tempo total gasto na inserção de dados nos SGBDS, por
tabela, bem como a diferença percentual de cada SGBD.
Tabela 29 - Tempo total de Inserção dos dados nos SGBDS, por tabela
Tabela
MySQL
PostgreSQL
Diferença Percentual
TB_PERFIL_USUARIO
0,561
0,120
PostgreSQL 367,50% + rápido
TB_SETOR
0,351
0,081
PostgreSQL 333,33% + rápido
TB_PRIORIDADE_DEMANDA
0,401
0,120
PostgreSQL 234,17% + rápido
TB_STATUS_DEMANDA
0,180
0,060
PostgreSQL 200,00% + rápido
TB_UF
0,270
0,050
PostgreSQL 440,00% + rápido
TB_USUARIO
8,623
10,605
MySQL 18,69% + rápido
353,267
0,230
257,041
0,570
PostgreSQL 37,44% + rápido
TB_RESPONSAVEL
TB_HISTORICO_DEMANDA
826,228
75,018
PostgreSQL 1001,37% + rápido
1.190,111
343.665
PostgreSQL 246,30% + rápido
TB_DEMANDA
TOTAL
MySQL 59,65% + rápido
O Gráfico 4 apresenta o resultado dos tempos totais de inserção dos dados nos
SGBDs por tabela, retirados da Tabela 29.
74
Gráfico 4 - Resultado dos testes de Insert nos SGBDS MySQL e PostgreSQL
Conforme gráfico 4, retirado da tabela 29, é presumível verificar que o MySQL foi
superior em relação ao PostgreSQL, apenas nas inserções realizadas nas tabelas
TB_USUARIO e TB_RESPONSAVEL, tendo perdido nas inserções das demais tabelas,onde
o PostgreSQL obteve um melhor desempenho.
Com o intuito de facilitar a compreensão dos testes de insert, foi criado um gráfico 5,
com informações do gráfico 4, porém em uma escala menor, sendo retirado desse gráfico as
tabelas TB_DEMANDA,TB_USUARIO e TB_HISTORICO_DEMANDA por possuírem
grande quantidade de registros.
75
Gráfico 5 - Gráfico de Inserts nos SGBDS, em menor escala.
No gráfico 5 pode-se perceber melhor a superioridade do PostgreSQL em relação ao
MySQL, com exceção da tabela TB_RESPONSAVEL, onde foi inferior em 59,65%.
4.1.2 RESULTADOS DOS TESTES DE UPDATE
Nesse quesito, foi testado o tempo que cada SGBD utilizou para realização das
alterações na base de dado. Este teste foi dividido em 6 updates, cada um foi realizado 3
vezes, tirando uma média do tempo de cada alteração.
Também serão apresentados às tabelas com as quantidades de updates realizados nos
SGBDS, tempo em segundos utilizados para realizar essas alterações, assim como o
percentual de diferença entre eles. Os print dos testes de update se encontram no Apêndice C
desse trabalho, localizado na pagina 171.
A tabela 30 apresenta a quantidade de updates realizados e seus respectivos tempos
utilizados nos SGBDS MySQL.
76
Tabela 30 – Tempo dos testes de Updates no SGBD MySQL
Teste de UPDATES
Banco de dados MySQL
Upadates
Tempo utilizado em Segundos
1
1,742
2
0,371
3
17,999
4
1,322
5
2,517
6
2,991
Total
26,942
A tabela 31 apresenta a quantidade de updates realizados e seus respectivos tempos
utilizados no SGBD PostgreSQL.
Tabela 31 - Tempo dos testes de Updates no SGBD PostgreSQL
Teste de UPDATES
Banco de dados PostgreSQL
Upadates
Tempo utilizado em Segundos
1
1,212
2
12,755
3
1,632
4
1,896
5
5,588
6
10,592
Total
33,675
A tabela 32 apresenta a diferença percentual nos updates realizados nos SGBDS
MySQL e PostgreSQL.
Tabela 32 – Diferença percentual nos teste de Update
Qtd.de
Testes
1
MySQL
PostgreSQL
Diferença Percentual
1,742
1,212
PosgreSQL 43,80 % + rápido
2
0,371
12,755
MySQL 9709,40% + rápido
3
17,999
1,632
PostgreSQL 1002,65% + rápido
4
1,322
1,896
MySQL 30,27% + rápido
5
2,517
5,588
MySQL 54,96% + rápido
6
2,991
10,592
MySQL 71,76% + rápido
Total
26,942
33,675
MySQL 19,99% + rápido
77
No Gráfico 6 apresenta os resultados da média de tempo dos updates realizados nos
SGBDs , retirados da Tabela 32.
Gráfico 6 - Resultado dos testes de Update
No gráfico 6 é plausível verificar que o MySQL foi superior
em relação ao
PostgreSQL em 4 dos 6 testes, no 2º,4º,5º e 6º, tendo perdido apenas no 1º e 3º teste, onde o
PostgreSQL obteve um melhor desempenho.
4.1.3 RESULTADOS DOS TESTES DE DELETE
Nesse quesito, foi testado o tempo que cada SGBD utilizou para remover registros na
base de dado. Este teste foi dividido em 6 Deletes,cada um foi realizado 3 vezes, tirando uma
média do tempo de cada delete.
Também serão apresentado as tabelas com as quantidades de delete realizados nos
SGBDS, tempo em segundos utilizados para realizar as exclusões, assim como o percentual
78
de diferença entre eles. Os print dos testes de delete se encontram no Apêndice D, localizados
na página 183.
A tabela 33 apresenta a quantidade de delete realizados e seus respectivos tempos
utilizados no SGBDS MySQL.
Tabela 33 – Tempo dos testes de Deletes no SGBD MySQL
Teste de DELETE
Banco de dados MySQL
Deletes
Tempo utilizado em Segundos
1
3,021
0,033
14,885
4,003
0,020
9,915
31,877
2
3
4
5
6
Total
A tabela 34 apresenta a quantidade de deletes realizados e seus respectivos tempos
utilizados no SGBD PostgreSQL.
Tabela 34 - Tempo dos testes de Deletes no SGBD PostgreSQL
Teste de DELETE
Banco de dados PostgreSQL
Deletes
Tempo utilizado em Segundos
1
0,785
0,030
0,683
0,087
0,013
0,788
2,385
2
3
4
5
6
Total
A tabela 35 apresenta a diferença percentual nos deletes realizados nos SGBDS
MySQL e PostgreSQL.
79
Tabela 35 – Diferença percentual nos testes de Delete
DELETE
MySQL
PostgreSQL
1
3,021
0,785
PostgreSQL 285,05% + rápido
2
0,033
14,885
4,003
0,020
0,030
0,683
0,087
0,013
PostgreSQL 11,11% + rápido
PostgreSQL 2080,37% + rápido
PostgreSQL 4518,46% + rápido
PostgreSQL 50,00% + rápido
9,915
31,877
0,788
2,385
PostgreSQL 1158,74% + rápido
PostgreSQL 1236,55% + rápido
3
4
5
6
Total
Diferença Percentual
No Gráfico 7 apresenta os resultados da média de tempo dos deletes realizados nos
SGBDs , retirados da Tabela 35.
Gráfico 7 - Resultado dos testes de Delete
80
No gráfico 7, pode-se verificar que o MySQL não foi superior em relação ao
PostgreSQL em nenhum dos testes de delete realizados, sendo que o PostgreSQL foi superior
em todos os testes desses quesito, obtendo uma superioridade de 1236,55% em relação ao
MYSQL.
4.1.4 RESULTADOS DOS TESTES DE SELECT
Nesse quesito, foi testado o tempo que cada SGBD utilizou para realização das
consultas na base de dado. Este teste foi dividido em oito consultas, cada uma foi realizada 3
vezes, tirando uma média do tempo de cada consulta.
Também serão apresentado ás tabelas com as quantidades de select realizados nos
SGBDS, tempo em segundos utilizados para as consultas, assim como o percentual de
diferença entre eles. Os print dos testes de select se encontram no Apêndice E, localizado na
página 192.
A tabela 36 apresenta a quantidade select realizados e seus respectivos tempos
utilizados nos SGBDS MySQL.
Tabela 36 - Tempo dos testes de Select no SGBD MySQL
Teste de Select
Banco de dados MySQL
Select
Tempo utilizado em Segundos
1
1,656
2
20,673
3
0,301
4
5
0,033
0,307
6
1,055
7
0,327
8
0,327
Total
24,679
81
A tabela 37 apresenta a quantidade de select realizados e seus respectivos tempos
utilizados no SGBD PostgreSQL.
Tabela 37 - Tempo dos testes de Select no SGBD PostgreSQL
Teste de SELECT
Banco de dados PostgreSQL
Select
Tempo utilizado em Segundos
1
1,539
2
1,484
3
0,088
4
5
0,083
0,033
6
17,337
7
1,809
8
0,114
Total
22,488
A tabela 38 apresenta a diferença percentual nos select realizados nos SGBDS
MySQL e PostgreSQL.
Tabela 38 – Diferença percentual nos testes de Select
Qtd. De
Testes
1
MySQL
PostgreSQL
Diferença Percentual
1,656
1,539
PostgreSQL 7,58% + rápido
2
20,673
1,484
PostgreSQL 1292,75% + rápido
3
0,301
0,088
PostgreSQL 240,38% + rápido
4
0,083
0,033
MySQL 60,00% + rápido
5
0,033
0,307
PostgreSQL 822,00% + rápido
6
1,055
17,337
MySQL 93,92% + rápido
7
0,327
1,809
MySQL 81,92% + rápido
8
0,327
0,114
PostgreSQL 187,68% + rápido
Total
24,679
22,488
PostgreSQL 9,74% + rápido
82
No Gráfico 8 apresenta os resultados da média de tempo das consultas que foram
realizadas nos SGBDs, retirados da Tabela 38.
Gráfico 8 - Resultado dos testes de Consultas
No gráfico 8 é plausível verificar que o MySQL foi superior em relação ao
PostgreSQL em apenas 3 dos 8 testes, no 4º, 6º e 7º, sendo que nos demais testes 1º, 2º, 3º, 5º
e 8º o PostgreSQL obteve um melhor desempenho.
4.2
ANÁLISE
Nesse tópico serão apresentadas as análises individuais e uma análise geral dos
resultados deparados na pesquisa, onde foi realizado testes de DML, (insert, delete, update,
select) nos SGBDS MySQL e PostgreSQL.
83
4.2.1 ANÁLISE TESTES DE INSERÇÃO
Nesse quesito onde foi testada a velocidade com que os registros são inseridos nos
SGBDS, após a análise da tabela 29, que se encontra na pagina 69, onde é apresentado o
tempo total de inserção de dados nas tabelas, pode-se observar que o MySQL, obteve melhor
desempenho em relação ao PostgreSQL em apenas 2 das 9 tabelas, sendo elas as tabelas
TB_USUARIO e TB_RESPONSAVEL, com os resultados de 18,69% e 59,65%
respectivamente.
Sendo que nas demais tabelas o PostgreSQL superou o MySQL, sendo que seu maior
percentual foi na tabela TB_ PERFIL-USUARIO, onde foi superior em 367,50%, e obteve
seu menor percentual na tabela TB_DEMANDA, a tabela principal com 450 mil registros, em
37,54%.
No contexto geral dos inserts, pode-se constatar que o PostgreSQL apresentou
melhor desempenho em relação ao MySQL, alcançando 246,30 % na soma total para inserção
de registros em todas as tabelas.
4.2.2 ANÁLISE TESTES DE UPDATE
Nesse quesito onde foi testada a velocidade com que os registros são alterados nos
SGBDS, após a análise da tabela 32, que se encontra na pagina 72, onde é apresentado o
tempo total de alterações de registros nos SGBDS. Pode-se observar que o MySQL obteve
melhor desempenho em relação ao PostgreSQL em 4 dos 6 testes realizados, no 2º, 4º, 5º e 6º,
sendo que seu maior percentual foi no 2º teste: 9709,40%, e obteve um menor percentual no
4°teste sendo superior em apenas 30,27% .
Já o PostgreSQL foi superior em relação ao MySQL no 1º e 3º teste, sendo que seu
maior percentual foi no 3º teste onde alcançou 1002,65%, obtendo seu menor percentual no 1°
teste, com a vantagem de 43,80% .
Na análise geral dos updates realizados nos SGBDS, foi verificado que na soma total
dos tempos, que o MySQL foi superior em relação ao PostgreSQL em 19,99%.
84
4.2.3 ANÁLISE TESTES DE DELETE
Nesse quesito onde foi testada a velocidade com que os registros são apagados nos
SGBDS, após a analise da tabela 35, que se encontra na pagina 75, onde é apresentado o
tempo total de deletes realizados nos SGBDs, pode-se observar que o MySQL, não obteve
melhor desempenho em relação ao PostgreSQL, em nenhum dos testes de delete realizado,
sendo que na soma total dos testes foi inferior em 1236,55%.
Sendo assim,no contexto geral dos testes de deletes, pode-se constatar que o
PostgreSQL foi superior em relação ao MySQL.
4.2.4 ANÁLISE TESTE DE SELECT
Nesse quesito onde foi testado o tempo que cada SGBD, utilizou para recuperar
registros no SGBDS, após a análise de dados colhidos da tabela 38, que se encontra na pagina
77, onde é apresentado o tempo total dos select realizados em todos os nos SGBD, pode-se
observar que o MySQL obteve melhor desempenho em relação ao PostgreSQL em 3 dos 8
testes, no 4º,6º e 7º, sendo que seu maior percentual foi no 6º lote chegando a 93,92%, e
obteve um menor percentual no 4° lote sendo superior em 60,00% .
Já o PostgreSQL superou o MySQL no 1º, 2º, 3º, 5 e 8º teste, sendo que seu maior
percentual foi no 2º lote com 1292,75% , já o menor percentual ocorreu no 1° lote, atingindo
uma vantagem percentual de 7,58%.
Na análise geral dos selects, realizados nos SGBDS, foi verificado que na soma total
dos tempos, que o PostgreSQL foi superior em relação ao MySQL em 9,74%.
4.2.5 ANÁLISE GERAL
A tabela 39, que se encontra na pagina 81, apresenta informações realizadas em
todos os testes realizados tanto no SGBD MySQL, quanto no PostgreSQL.
85
Testes
Realizados
Select
Update
Tabela 39 - Tabela com resultado de todos os testes realizados
Tempo total para
Tempo total para
realização dos
realização dos
Diferença Percentual
comandos no SGBD comandos no SGBD
MySQL
PostgreSQL
PostgreSQL 9,74% + rápido
24,679
22,488
33,675
MySQL 19,99% + rápido
31,877
2,385
PostgreSQL 1236,56% + rápido
1.190,111
343,605
PostgreSQL 246,36% + rápido
402,153
PostgreSQL 2166,98% + rápido
26,942
delete
Insert
1.273,609
Diferença total
Conforme dados analisados na tabela 39, que contem as informações dos testes de
DML, realizados pode-se constatar que o MySQL foi superior em relação ao PostgreSQL
apenas no testes de updade, com uma vantagem percentual de 19,99%.
Já o PostgreSQL ultrapassou o MySQL nos demais testes( insert, select,delete), com
uma vantagem de percentual de 246,36%, 9,74% e 1236,56% respectivamente. Obtendo sua
maior vantagem percentual no quesito delete, com 1236,56% de superioridade em relação ao
MySQL. E a menor vantagem no quesito de select onde foi superior em apenas 9,74% em
relação ao MySQL, conforme gráfico 9 retirado da tabela 39.
Gráfico 9 - Resultado geral dos testes realizados
86
No contexto geral pode-se observar que o PostgreSQL obteve melhor desempenho
em relação ao MySQL, em 3 dos 4 testes realizados e que na soma geral, obteve uma margem
percentual de 2.166,98%.
Portanto, após análise geral dos dados, pode-se apurar a superioridade do
PostgreSQL, em relação ao MySQL, diante dos testes realizados.
Neste Capítulo foram apresentados resultados e analise desse trabalho, onde foram
apresentados os resultados dos testes de laboratórios e uma análise detalhada e geral dos
mesmos, assim como a analise de tempo realizada nos testes.
No próximo capítulo será apresentada a conclusão, onde descreve as respostas de que
se a hipótese foi aceita ou refutada, se os resultados almejados foram alcançados, bem como
uma sugestão para trabalhos futuros.
87
5.
CONCLUSÃO
Com o aumento e a procura no significativo no mercado de trabalho por um banco de
dados capaz de suprir as necessidades dos usuários, e diante da gama de bancos disponíveis,
este trabalho apresentou dois SGBDs, o MySQL e o PostgreSQL.
Foram apresentadas algumas características peculiares destes bancos, como o tempo
de resposta, no momento de execução dos comandos DML (Insert, Select, Update e delete).
Fundamentado nisso, o trabalho de conclusão realizou um teste de desempenho entre
o MySQL e o PostgreSQL, com a finalidade de saber qual tem o melhor desempenho.
Após análise da pesquisa literária e dos resultados obtidos, constatou-se que o
problema era saber qual SGBD possui melhor desempenho na realização dos comandos
delete, update, insert e select, quando aplicados a um modelo lógico retirado de um Sistema
Gerenciador de Demandas.
Esse problema foi sanado, pois mediante conclusão dos resultados apresentados,
constatou-se que nesse ambiente de teste, o PostgreSQL evidenciou um melhor desempenho
em relação ao MySQL.
A hipótese levantada neste trabalho de que o MySQL possui um melhor desempenho
em relação ao PostgreSQL foi refutada, uma vez que os resultados apresentados nesse
trabalho demonstraram que o PostgreSQL é o que possui um melhor desempenho em relação
ao MySQL.
O presente estudo exibiu 03 objetivos específicos:
O primeiro objetivo era apresentar algumas características peculiares dos SGBDs
MySQL e PostgreSQL, que foi alcançado de acordo com a pesquisa bibliográfica retiradas
dos autores Manzano,Neto,Anderson,Cremades,Gilfillan e outros.
O segundo objetivo específico, que era realizar um teste de desempenho em
laboratório utilizando a linguagem SQL, quanto à execução de comandos DML (inserção,
inclusão, alteração e Exclusão), foi almejado conforme resultados contidos nos gráficos 1 a 9.
O terceiro objetivo, que procurava analisar o tempo de respostas na execução dos
comandos DML aplicados, também foi alcançado, conforme resultados obtidos nos gráficos 1
a 9.
88
Dessa forma os objetivos específicos apresentados nesse trabalho de conclusão foram
apresentados, uma vez que a pesquisa bibliográfica apresentou algumas características
inerentes aos SGBDs MySQL e PostgreSQL. Bem como a realização de um teste de
desempenho entre os dois SGBDs, visando identificar qual possui melhor desempenho. Por
fim, realizou-se uma análise dos dados colhidos nos testes.
O objetivo geral do trabalho também foi atingido, uma vez que foi realizado o teste
de desempenho com os SGBDs MySQL e PostgreSQL, utilizando-se diferentes cargas de
dados na execução dos comandos de DML.
Logo após a análise de dados dos resultados obtidos nos testes de DML, constatou-se
que o SGBD PostgreSQL, obteve um melhor desempenho em relação ao MySQL.
Ressaltando que os testes foram realizados em ambientes controlados, e que no
ambiente de produção existem vários fatores que podem interferir no desempenho de um
SGBD, tais como a quantidade de usuários acessando-o ao mesmo tempo, a infraestrutura do
tráfego de rede, o Hardware que compõe esse ambiente, etc. Portanto, o desempenho de um
SGBD não depende unicamente dele, mais sim das condições do ambiente em que foi
realizado o teste.
Para se escolher um SGBD adequado para sua empresa ou outro fim, além de
analisar esses fatores, deve-se considerar que o melhor SGBD é aquele que atende as
necessidades do usuário da melhor maneira possível.
Para trabalhos futuros recomendaria que essa análise fosse realizada em outro
sistema operacional, de preferência o LINUX, ou mesmo em máquinas não virtualizada.
Ou que fosse aumentado o limite do -O max_allowed_packet=# que tem o tamanho
padrão de1 MB para 8 MB, para que os registros fossem inseridos de uma só vez e não em
lotes com foi realizado nesse trabalho.
89
REFERÊNCIAS
ANDERSON, Christiano. Software Livre não é Grátis! Revista Linux Magazine.
Ano I, nº1, ago. 2004, p. 94.
BATTISTI, Julio César Fabris. Noções da Linguagem SQL para consultas 2006.
Disponível em: <http://www.linhadecodigo.com.br/Artigo. aspx?id=165.> Acesso em 21 Set
2012.
BORBA
ON
SOFTWARE
O
fim
do
MySQL.
em:<http://borba.blog.br/2012/08/o-fim-do-mysql/>Acesso em 10 de Abr. 2013.
Disponível
BAÚ DE DEV.COM Para que servem os índices?. Disponível em <http://www.bau-dedev.com/banco-de-dados/utilizando-indices-em-tabelas-no-postgresql>. Acesso em 08 de
Abr. 2013.
B2BR PostgreSQL :Quem usa, o que diz a respeito? .Disponível
<http://www.slideshare.net/adorepump/postgresql-o-melhor-banco-de-dados-universo>
Acesso em 11 de Abr. 2013.
em:
CANTU, Carlos H. Firebird essencial. Rio de Janeiro: Ciência Moderna, 2005.
CONVERTWORD.COM
Milissegundo,
Tempo
Disponível
em:
<http://www.convertworld.com/pt/tempo/Milissegundo.html> Acesso em 09 de Abr. 2013.
CREMADES, Javier. Micro Poder: a força do cidadão na era digital. Editora: Senac. São
Paulo. 2009.
DATAPRIX KNOWLEDGE IS THE GOL Arquitetura PostgreSQL. Disponível em:
<http://www.dataprix.com/72-arquitectura-PostgreSQL>. Acesso em 16 de Nov 2012.
DATE, J. C. Introdução a Sistemas de Bancos de Dados. Tradução da 7a. Edição
Americana, Rio de Janeiro. Campus, 2000.
DATE, C. J. Introdução a sistemas de bancos de dados. Tradução de Daniel Vieira.
Tradução da 8º Edição Americana ed.[S.1.]: Elsevier Editora Ltda, 2004.
DEVMEDIA. Componente de um Sistema de Banco de Dados. Disponível em:
<http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649> Acesso em
23 de Set 2012.
E
DER.
Disponível
em:<http://www.devmedia.com.br/mer-e_______MER
der/14332#ixzz2CExbRDud>Acesso em 14 de Nov 2012.
90
_______Herança no PostgreSQL. Disponível em:<http://www.devmedia.com.br/heranca-nopostgresql/9182> Acesso em 23 Abr. 2013.
três
Esquemas.
Disponível
em:
_______Arquitetura
<http://www.devmedia.com.br/arquitetura-de-um-sgbd/25007 > Acesso em 23 de Set 2012.
x
MySQL.
Qual
Escolher?
Disponível
em:
http://www.devmedia.com.br/PostgreSQL-x-MySQL-qual-escolher/3923> Acesso em 18 de
Fev 2013.
_______PostgreSQL
MySQL que é você?. Disponível em <http://www.devmedia.com.br/mysql-quem-evoce/1752>Acesso em 11 de Abr. 2013.
_______
E-KNOWLEDGE.
MDR
Chave
Estrangeira Disponível em:
Acesso em 27 de Set 2012.
<http://e-reality-
database.blogspot.com/2007/12/chave-estrangeira.html>
Chave
Primária
Disponível
em:
<http://e-reality_______MDR
database.blogspot.com.br/2007/12/chave-primria.html> Acesso em 14 de Mar 2013.
_______Modelo Entidade Relacionamento - MER - Peter Chen – 1976. Disponível em:
<http://e-reality-database.blogspot.com.br/2007/09/modelo-entidade-relacionamento-mer.html>Acesso em 16
de Nov 2012.
GARCIA-MOLINA, Hector, ULLMAN, Jeffrey D. e WIDOM, Jennifer. Implementação
de sistemas de bancos de dados. Rio de Janeiro: Campus, 2001.
GAUDENCIO, Emerson S. CERTIFICAÇÃOBD.COM. BR Estruturas de Memória
Disponível
em:
<http://certificacaobd.com.br/2013/03/01/mysql-srie-de-posts-6-teoriaestruturas-de-memria/> Acesso em 25 de Mar 2013.
GILFILLAN, I. La Bíblia MySQL. 1ª Edição. ed. [S.l.]: Anaya Multimedia, 2003.
INFOWESTER
Banco
de
dados
MySQL
e
PostgreSQL
<http://www.infowester.com/postgreMySQL. php> Acesso em 15 de Nov.2012.
iMASTERS ORACLE lança a primeira versão de desenvolvimento do MySQL 5.6.
Disponível
em:<
http://imasters.com.br/noticia/oracle-lanca-primeira-versao-dedesenvolvimento-do-mysql-56/> Acesso em 11 de Abr. 2013.
KROENKE, David M. Banco de Dados: Fundamentos, Projeto e Implementação. 6ª. Ed.
Rio de Janeiro: LTC, 1999.
LAUDON, K.C.; LAUDON, J.P., 2004, Sistemas de Informação Gerenciais. 5. ed. São
Paulo, Prentice-Hall Inc.
LINHA DE CÓDIGO Programação de Banco de Dados 3 Disponível
em:<http://www.linhadecodigo.com.br/artigo/404/programacao-de-banco-de-dados-parte-3.aspx> Acesso em
12 de Mar. 2013.
91
MACHADO, F.N. R; ABREU M Projeto de Banco de Dados: Uma Visão Prática. São
Paulo: Érica 1995.
MELO, R.N; SILVA, S.D.; TANAKA, A.K., 1997, Banco de Dados em Aplicações
Cliente-Servidor. 2. ed. Rio de Janeiro, Livraria e Editora Infobook S. A, 2004.
METROPOLE
DIGITAL
Sistemas
de
Banco
de
Dados
Disponível
em<http://www.metropoledigital.ufrn.br/aulas_avancado/web/disciplinas/banco_de_dados/aul
a_01.html> Acesso em 03 de Mar. 2013.
MySQL. Anúncio publicitário. Revista Linux Magazine. Ano II, nº6, jan. 2005, p. 2.
MILANI, A. MySQL Guia do Programador. 1ª Edição. ed. [S.l.]: Novatec, 2006.
MySQL DevConnectMember Banco de dados II. OLIVEIRA, GILBERTO BRAGA
Disponivél em <http://gilbertexbom.com/bd2/ResumoBD2_3InfoT/html_mysql/mysql.html> Acesso em
28 de Mar 2013.
NAVATHE, S.; ELMASRI, R. E. Sistemas de Banco de Dados. 4ª Edição. ed. [S.l.]:
ADDISON WESLEY, 2005.
NAVATHE, S.; ELMASRI, R. E. Sistemas de Banco de Dados. 6ª Edição. ed. [S.l.]:
ADDISON WESLEY, 2011.
NETO, A.P. “PostgreSQL: Técnicas Avançadas – Versões Open Source 7.x” .2ª
ed. São Paulo: Editora Érica, 2003.
OFFICE Calcular a Percentagem. Disponivel em <http://office.microsoft.com/pt-pt/excelhelp/calcular-percentagens-HP001141712.aspx> Aceso em 22 Abr 2013
OLIVEIRA, C. H. P., SQL – Curso Prático. São Paulo, Novatec, 2002.
PORTAL DA EDUCAÇÃO. Artigos de Informática Introdução ao MYSQL Disponível
em:<http://www.portaleducacao.com.br/informatica/artigos/7725/introducao-ao-MySQL>
Acesso em 23 de Set.2012.
POSTGRESQL GLOBAL DEVELOPMENT GROUP. “Tutorial do PostgreSQL 8 /Official
Documentation”. Tradução: Halley Pacheco de Oliveira. Rio de Janeiro,
2005. Disponível em: <http://www.PostgreSQL.org/>. Acesso em 14 de Nov 2012.
POSTGRESQL Kit de imprensa do PostgresSQL 9.2 Disponível
<http://www.postgresql.org/about/press/presskit92/pt/>Acesso em 11 de Abr.2013
em
PRODANOV, C; FREITAS, E. C.Metodologia do Trabalho Cientifico: Metodologia e
Técnicas da Pesquisa e do Trablho Acadêmico.2ª Edição. Ed – NOVO HAMBURGO
FEEVALE, 2013.
92
RICARTE, Ivan Luiz Marques. Sistemas de bancos de dados. Faculdade de Engenharia
Elétrica e de Computação, Unicamp, Campinas, 2008. Disponível em :
<ftp://ftp.dca.fee.unicamp.br/pub/docs/ricarte/apostilas/mc_sbdoo.pdf > Acesso em 15 Set
2012.
ROCHA, Banco de dados Web Aula 4. Linguagem SQL.Disponivel em
<http://www.lrocha.com.br/arquivos/arquivos/BdWeb%20(PostgreSQL)/AULAS/bd_webA_
4.pdf>. Acesso em 12 de Mar. 2013.
SETZER, Valdemar W. Bancos de dados: aprenda o que são, melhore seu conhecimento,
construa os seus. São Paulo: Edgard Blücher, 2005.
SILBERSCHATZ, A. KORTH, H. SUDARSHAN, S. Sistema de Bancos de Dados. 4 ed.
São Paulo: Makron Books, 2006.
TAKAI, O. K.; ITALIANO, I. C.; FERREIRA, J. E. Introdução ao banco de Dados. São
Paulo: DCC-IME-USP, 2005.
TANENBAUM, Andrew S. Redes de Computadores. Rio de Janeiro: Campus, 2000.
TSICHRITZIS, D. & KLUG, A. (eds.). “The ANSI/X3/SPARC DBMS framework report
of the study group on database management systems”. Information Systems 3, 1978.
WELLING, L. e THOMSON, L. Tutorial MySQL Rio de Janeiro, Editora Ciência
Moderna, 2004.
WILLIANS, H. E., TAHAGHOGHI, M. M. S. Aprendendo MySQL, 1.ª Edição, Editora
Alta Books, 2007.
XOOPS
Brasil,
A.2.2.
Erro: MySQL
server
has
gone
<http://xoops.net.br/docs/mysql/manual/apas02.php> Acesso em 21 de Ma. 2013.
away
93
APÊNDICE A – AMOSTRA DOS SCRIPTS UTILIZADOS PARA INSERÇÃO DE
DADOS NOS SGBDS
Neste apêndice serão apresentados uma amostra dos registros inseridos nos SGBDS
MySQL e PostgreSQL, sendo que os demais registros estarão disponíveis em cd no apêndice
F, localizado na página 208 uma vez que ficaria inviável por exemplo, colocar os 450 mil
registros da tabela TB_DEMANDA, nesse apêndice.
94
Na figura abaixo é apresentado uma amostra dos registros inseridos na tabela
TB_PERFIL_USUARIO:
AMOSTRA DE REGISTROS INSERIDOS NA TABELA TB_PERFIL_USUARIO
INSERT INTO TB_PERFIL_USUARIO (ID_PERFIL, TIPO_PERFIL) VALUES
('1','CADASTRADOR'),
('2','ADMINISTRADOR.'),
('3','EXECUTOR'),
('4','DOLOR'),
('5','IACULIS QUIS,'),
('6','NEC URNA'),
('7','AUCTOR QUIS,'),
('8','DONEC DIGNISSIM'),
('9','CONGUE,'),
('10','SENECTUS ET'),
Na figura abaixo é apresentado uma amostra dos registros inseridos na tabela
TB_PRIORIDADE_DEMANDA:
AMOSTRA DE REGISTROS INSERIDOS NA TABELA
TB_PRIORIDADE_DEMANDA
INSERT INTO TB_PRIORIDADE_DEMANDA
(ID_PRIORIDADE_DEMANDA,TIPO_PRIORIDADE) VALUES
('1','ALTA'),
('2','MEDIA'),
('3','BAIXA'),
('4','IN'),
('5','PLACERAT. CRAS'),
('6','SED CONSEQUAT'),
('7','LIGULA CONSECTETUER'),
('8','ALIQUET'),
('9','ORCI LOBORTIS'),
('10','NULLA EGET'),
Na figura abaixo é apresentado uma amostra dos registros inseridos na tabela
TB_STATUS_DEMANDA:
95
AMOSTRA DE REGISTROS INSERIDOS NA TABELA TB_STATUS_DEMANDA
INSERT INTO TB_STATUS_DEMANDA (ID_STATUS,STATUS) VALUES
('1','EM ANDAMENTO.'),
('2','PENDENTE'),
('3','CONCLUIDA'),
('4','NEC, ELEIFEND'),
('5','FAUCIBUS'),
('6','NUNC'),
('7','NEC,'),
('8','ET NETUS');
('9','LIBERO EST,'),
('10','PORTTITOR EROS'),
Na figura abaixo é apresentado uma amostra dos registros inseridos na tabela
TB_UF:
AMOSTRA DE REGISTROS INSERIDOS NA TABELA TB_UF
INSERT INTO TB_UF (ID_UF,NOME_UF) VALUES
('1','ACRE - AC'),
('2','ALAGOAS - AL'),
('3','AMAPÁ - AP'),
('4','AMAZONAS - AM'),
('5','BAHIA - BA'),
('6','CEARÁ - CE'),
('7','DISTRITO FEDERAL - DF'),
('8','ESPÍRITO SANTO - ES'),
('9','GOIÁS - GO'),
('10','MARANHÃO - MA'),
Na figura abaixo é apresentado uma amostra dos dados inseridos na tabela
TB_USUARIO:
AMOSTRA DE REGISTROS INSERIDOS NA TABELA TB_USUARIO
INSERT INTO TB_USUARIO
(ID_USUARIO,CPF_USUARIO,ID_PERFIL,ID_SETOR,LOGIN_USUARIO,NOME_US
UARIO,SENHA_USUARIO,RAMAL_USUARIO) VALUES
('1','82710715809','199','880','JERRY OLSON','LANCE','OZK33TNK6SZ','1013'),
('2','79045868917','564','251','HARLAN PECK','TANISHA','TAL09OHG0IB','5400'),
('3','53820448562','736','75','NIGEL ROMAN','LUCIUS','BQJ35AQF8ZW','7007'),
('4','35457460408','246','113','IGNATIUS LONG','ANTHONY','FCW55WLP4IH','3830'),
('5','49582672335','370','109','TATE RANDOLPH','LAEL','DNZ46ECF4DR','0625'),
('6','40936799267','801','248','STEEL BALLARD','SAMANTHA','IDF74QEF3DE','8181'),
('7','62430816968','464','886','JOSIAH KELLER','COURTNEY','XGZ23WMN2YS','5958'),
('8','36370644793','826','515','ZANE CONRAD','YURI','LVP77WPE2CW','1394'),
('9','89489203617','453','655','ALAN TREVINO','JARROD','JSP23OGS7JV','1458'),
('10','66817973669','404','860','HU STEPHENSON','JORDEN','QPJ23UTM2GW','4860'),
96
Na figura abaixo é apresentado uma amostra dos dados inseridos na tabela
TB_RESPONSAVEL:
AMOSTRA DE REGISTROS INSERIDOS NA TABELA TB_RESPONSAVEL
INSERT INTO TB_RESPONSAVEL (ID_RESPONSAVEL,ID_USUARIO) VALUES
('1','60674'),
('2','64868'),
('3','39452'),
('4','31008'),
('5','58977'),
('6','64473'),
('7','18842'),
('8','20980'),
('9','32390'),
('10','14999'),
Na figura abaixo é apresentado uma amostra dos dados inseridos na tabela
TB_SETOR:
AMOSTRA DE REGISTROS INSERIDOS NA TABELA TB_SETOR
INSERT INTO TB_SETOR (ID_SETOR,ID_UF,NOME_SETOR) VALUES
(1,4,'RH'),
(2,2,'DILID'),
(3,5,'DIOFI'),
(4,19,'NUTRA'),
(5,9,'SECAD'),
(6,26,'COPOL'),
(7,15,'COINT'),
(8,16,'COAFI'),
(9,12,'GABIN'),
(10,6,'NTIC'),
Na figura abaixo é apresentado uma amostra dos dados inseridos na tabela
TB_DEMANDA:
97
AMOSTRA DE DADOS INSERIDOS NA TABELA TB_DEMANDA
INSERT INTO TB_DEMANDA (ID_DEMANDA, ID_USUARIO,
ID_PRIORIDADE_DEMANDA, ID_RESPONSAVEL, ID_STATUS,
DATA_HORA_CRIACAO, DATA_HORA_CONCLUSAO, ASSUNTO,
OBSERVACAO) VALUES
('1','49839','681','98','794','2019-10-12 18:27:40','2017-02-04 11:59:55','PEDE
AC','IPSUM'),
('2','54532','407','609','843','2017-10-10 23:26:35','2018-12-07
22:28:34','RUTRUM','ALIQUET'),
('3','15913','569','294','2','2014-03-07 02:43:31','2015-05-01
21:49:02','ADIPISCING.','MALESUADA VEL,'),
('4','59981','914','394','35','2013-04-29 13:11:43','2016-11-19
16:44:36','DOLOR.','FEUGIAT. LOREM'),
('5','24737','172','23','691','2013-10-14 14:17:04','2019-01-18
10:56:49','TELLUS','FACILISIS, MAGNA'),
('6','36181','121','423','708','2019-05-14 16:08:14','2016-05-31 23:34:57','VEL,','DUIS'),
('7','4312','505','706','844','2015-12-06 16:55:44','2016-06-23 12:11:22','A
PURUS.','PEDE, ULTRICES'),
('8','55130','57','696','845','2016-06-17 23:20:31','2018-10-01
03:40:12','ARCU','CURABITUR'),
('9','26636','552','214','461','2014-12-10 03:57:28','2018-11-18 22:16:02','VIVAMUS
NISI.','NEC, EUISMOD'),
('10','44829','722','502','447','2017-05-27 18:09:53','2018-11-23
14:57:05','MOLESTIE','A,'),
Na figura abaixo é apresentado uma amostra dos dados inseridos na tabela
TB_HISTORICO_DEMANDA;
AMOSTRA DE DADOS INSERIDOS NA TABELA TB_HISTORICO_DEMANDA
INSERT INTO TB_HISTORICO_DEMANDA (ID_HISTORICO, ID_DEMANDA,
ID_RESPONSAVEL, ID_STATUS, NOME_HISTORICO, DATA_HORA_CRIACAO,
DATA_HORA_CONCLUSAO, OBSERVACAO) VALUES
('1','309101','43','239','MAURIS,','2015-11-04 14:43:39','2014-06-23
16:40:28','FRINGILLA ORNARE'),
('2','107543','314','949','SED','2017-02-24 07:54:46','2016-12-02 17:46:36','ALIQUET
DIAM.'),
('3','397019','409','159','FELIS ULLAMCORPER','2017-06-10 09:48:12','2015-04-03
20:07:39','MAGNA NEC'),
('4','230727','265','721','ET MAGNIS','2019-10-28 10:55:44','2017-09-05
02:09:58','AENEAN'),
('5','330909','22','895','SCELERISQUE,','2017-04-26 02:04:16','2017-07-17
16:38:11','ODIO'),
('6','90020','451','670','MASSA.','2020-01-06 09:03:29','2018-11-20 13:18:02','QUISQUE
VARIUS.'),
('7','126590','184','121','DOLOR','2017-06-10 00:28:14','2020-04-05 02:05:08','VEL,'),
('8','214522','274','249','TINCIDUNT ADIPISCING.','2018-04-17 11:18:59','2018-11-05
01:34:57','PEDE.'),
('9','179572','43','140','TRISTIQUE SENECTUS','2016-12-13 13:03:50','2014-06-02
10:20:57','NUNC MAURIS'),
('10','331774','448','894','ARCU','2018-06-23 16:35:01','2016-12-28 17:52:54','VIVAMUS
98
APÊNDICE B – PRINT DOS INSERTS DAS TELAS DOS SGBDS MYSQL E
POSTGRESQL
Neste apêndice encontram-se prints das telas dos SGBDS mostrando o resultado dos
tempos de inserção nas tabelas assim como telas do comando select count para identificar a
quantidade de registros inseridos em cada tabela.
Vale apena ressaltar que as tabela que possuem maior quantidade de registros
tiveram suas inserções divididas em lote devido ao problema de estouro do buffer de memória
já explicado anteriormente.
99
1. MYSQL
INSERT TB_PERFIL_USUARIO
Temo utilizado para
inserção de dados na
tabela perfil_usuario
A figura acima apresenta o tempo de 0,561 segundos utilizados para inserção de
registros na tabela TB_PERFIL_USUARIO no banco de dados MySQL.
SELECT COUNT TB_PERFIL_USUARIO
Quantidade de
registros inseridos na
tabela perfil_usuario
A figura acima apresenta a quantidade de 1010 registros inseridos na tabela
TB_PERFIL_USUARIO no banco de dados MySQL.
100
INSERT TB_PRIORIDADE_DEMANDA
Temo utilizado para
inserção de dados na tabela
Prioridade demanda
A figura acima apresenta o tempo de 0,401 segundos, utilizado para inserção de
registros na tabela TB_PRIORIDADE_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_PRIORIDADE_DEMANDA
Quantidade de registros
inseridos na tabela
prioridade demanda
A figura acima apresenta a quantidade de 1015 registros inseridos na tabela
TB_PRIORIDADE_DEMANDA no banco de dados MySQL.
101
INSERT TB_SETOR
Temo utilizado para
inserção de dados na
tabela setor
A figura acima apresenta o tempo de 0.351 segundos utilizados para inserção de
registros na tabela TB_SETOR no banco de dados MySQL.
SELECT COUNT TB_SETOR
Quantidade de registros
inseridos na tabela setor
A figura acima apresenta a quantidade de 927 registros inseridos na tabela
TB_SETOR no banco de dados MySQL.
102
INSERT TB_STATUS_DEMANDA
Temo utilizado para
inserção de dados na
tabela status demanda
A figura acima apresenta o tempo de 0,180 segundos utilizados para inserção de
registros na tabela TB_STATUS_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_STATUS_DEMANDA
Quantidade de
registros inseridos na
tabela status demanda
A figura acima apresenta a quantidade de 1008 registros inseridos na tabela
TB_STATUS_DEMANDA no banco de dados MySQL.
103
INSERT TB_UF
Temo utilizado para
inserção de dados na
tabela uf
A figura acima apresenta o tempo de 0.270 segundos utilizado para inserção de
registros na tabela TB_UF no banco de dados MySQL.
SELECT COUNT TB_UF
Quantidade de
registros inseridos na
tabela uf
A figura acima apresenta a quantidade de 827 registros inseridos na tabela TB_UF no
banco de dados MySQL.
104
INSERT TB_RESPONSAVEL
Temo utilizado para
inserção de dados na
tabela responsavel
A figura acima apresenta o tempo de 0,230 segundos utilizado para inserção de
registros na tabela TB_RESPONSAVEL no banco de dados MySQL.
SELECT COUNT TB_RESPONSAVEL
Quantidade de
registros inseridos na
tabela responsavel
A figura acima apresenta a quantidade de 10 registros inseridos na tabela
TB_RESPONSAVEL no banco de dados MySQL.
105
1 º LOTE DE INSERT TB_USUARIO
Temo utilizado para
inserção de dados na
tabela usuario
A figura acima apresenta o tempo de 1,953 segundos utilizado para inserção de
registros na tabela TB_USUARIO no banco de dados MySQL.
SELECT COUNT TB_USUARIO
Quantidade de registros
inseridos no 1° lote da
tabela usuario
A figura acima apresenta a quantidade de 18.000 registros inseridos na tabela
TB_USUARIO no banco de dados MySQL.
106
2 º LOTE DE INSERT TB_USUARIO
Temo utilizado para
inserção de dados na
tabela usuario
A figura acima apresenta o tempo de 2,864 segundos utilizado para inserção de
registros na tabela TB_USUARIO no banco de dados MySQL.
SELECT COUNT TB_USUARIO
Quantidade de registros
inseridos na tabela
usuário após a inserção
do 2º lote
A figura acima apresenta a quantidade de mais 18 registros inseridos na tabela
TB_USUARIO no banco de dados MySQL, totalizando 36.000 registros.
107
3 º LOTE DE INSERT TB_USUARIO
Temo utilizado para
inserção de dados na
tabela usuario
A figura acima apresenta o tempo de 1,833 segundos utilizado para inserção de
registros na tabela TB_USUARIO no banco de dados MySQL.
SELECT COUNT TB_USUARIO
Quantidade de
registros inseridos na
tabela usuário após a
inserção do 3º lote
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_USUARIO no banco de dados MySQL, totalizando 54mil registros.
108
4 º LOTE DE INSERT TB_USUARIO
Temo utilizado para
inserção de dados na
tabela usuario
A figura acima apresenta o tempo de 1,973 segundos utilizado para inserção de
registros na tabela TB_USUARIO no banco de dados MySQL.
SELECT COUNT TB_USUARIO
Quantidade Total de
registros inseridos na
tabela usuario
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_USUARIO no banco de dados MySQL, totalizando 72 mil registros.
109
1 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 5,117 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade de registros
inseridos no 1° lote da
tabela demanda
A figura acima apresenta a quantidade de 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL.
110
2 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 5,458 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 2° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 36.000 registros.
111
3 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 3,025 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 3° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 54.000 registros.
112
4 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 2,263 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 4° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 72.000 registros.
113
5 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 2.594 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 5° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 90.000 registros.
114
6 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 4,437 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 6° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 108.00 registros.
115
7 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 6,810 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 7° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 126.000 registros.
116
8 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 5,417 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 8° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 144.000 registros.
117
9 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 21,641 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 9° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 162.000 registros.
118
10 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 15,712 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 10° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 180.000 registros.
119
11 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 15,792 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 11° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 198.000 registros
120
12 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 15,983 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 12° lote de 18.000
.
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 216.000 registros.
121
13 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 18,176 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 13° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 234.000 registros.
122
14 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 17,024 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 14° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 252.000 registros.
123
15 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 15,983 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 15° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 270.000 registros
124
16 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 18,267 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 16° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 288.000 registros.
125
17º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 27,490 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 17° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 306.000 registros.
126
18 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 355,681 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 18° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 324.000 registros.
127
19 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 17,155 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 19° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 342.000 registros.
128
20 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 15,722 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 20° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 360.000 registros.
129
21 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 17,765 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 21° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 378.000 registros.
130
22º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 16,454 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 22° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 396.000 registros.
131
23 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 16,914 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 23° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 414.000 registros.
132
24º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 16,414 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 24° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 432.000 registros.
133
25º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção de dados na
tabela demanda
A figura acima apresenta o tempo de 15,973 segundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados MySQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda.
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados MySQL, totalizando 450.000 registros.
134
1 º LOTE DE INSERT TB_HISTORICO_DEMANDA
Temo utilizado para
inserção de dados na
tabela histórico
demanda
A figura acima apresenta o tempo de 324,026 segundos utilizado para inserção de
registros na tabela TB_HISTORICO_DEMANDA no banco de dados MySQL.
SELECT TB_HISTORICO_DEMANDA
Quantidade de registros
inseridos na tabela historico
demanda após a inserção do
1° lote de 18.000
A figura acima apresenta a quantidade de 18.000 registros inseridos na tabela
TB_HISTORICO_DEMANDA no banco de dados MySQL.
135
2 º LOTE DE INSERT TB_HISTORICO_DEMANDA
Temo utilizado para
inserção de dados na
tabela histórico
demanda
A figura acima apresenta o tempo de 142,615 segundos utilizado para inserção de
registros na tabela TB_HISTORICO_DEMANDA no banco de dados MySQL.
SELECT TB_HISTORICO_DEMANDA
Quantidade de registros
inseridos na tabela historico
demanda após a inserção do
2° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_HISTORICO_DEMANDA no banco de dados MySQL, totalizando 36.000 registros.
136
3 º LOTE DE INSERT TB_HISTORICO_DEMANDA
Temo utilizado para
inserção de dados na
tabela histórico
demanda
A figura acima apresenta o tempo de 359,587 segundos utilizado para inserção de
registros na tabela TB_HISTORICO_DEMANDA no banco de dados MySQL.
SELECT TB_HISTORICO_DEMANDA
Quantidade de registros
inseridos na tabela historico
demanda após a inserção do
3° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_HISTORICO_DEMANDA no banco de dados MySQL, totalizando 54.000 registros.
137
2. POSTGRESQL
INSERT TB_PERFIL_USUARIO
Temo utilizado para
inserção de dados na
tabela perfil usuario
A figura acima apresenta o tempo de 0,120 milissegundos utilizados para inserção de
registros na tabela TB_PERFIL_USUARIO no banco de dados PostgreSQL.
SELECT COUNT TB_PERFIL_USUARIO
Quantidade de registros
inseridos na tabela Perfil
usuario
A figura acima apresenta a quantidade de 1010 registros inseridos na tabela
TB_PERFIL_USUARIO no banco de dados PostgreSQL.
138
INSERT TB_PRIORIDADE_DEMANDA
Temo utilizado para
inserção de dados na tabela
prioridade demanda
A figura acima apresenta o tempo de 120 milissegundos utilizados para inserção de
registros na tabela TB_PRIORIDADE_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_PRIORIDADE_DEMANDA
Quantidade de registros
inseridos na tabela
prioridade demanda
A figura acima apresenta a quantidade de 1015 registros inseridos na tabela
TB_PRIORIDADE_DEMANDA no banco de dados PostgreSQL.
139
INSERT TB_STATUS_DEMANDA
Temo utilizado para
inserção de dados na
tabela status demanda
A figura acima apresenta o tempo 60 milissegundos utilizados para inserção de
registros na tabela TB_STATUS_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_STATUS_DEMANDA
Quantidade de registros
inseridos na tabela
status demanda
A figura acima apresenta a quantidade de 1008 registros inseridos na tabela
TB_STATUS_DEMANDA no banco de dados PostgreSQL.
140
INSERT TB_UF
Temo utilizado para
inserção de dados na
tabela uf
A figura acima apresenta o tempo de 50 milissegundos utilizados para inserção de
registros na tabela TB_UF no banco de dados PostgreSQL.
SELEC COUNT TB_UF
Quantidade de registros
inseridos na tabela uf
A figura acima apresenta a quantidade de 827 registros inseridos na tabela TB_UF no
banco de dados PostgreSQL.
141
INSERT TB_SETOR
Temo utilizado para
inserção de dados na
tabela setor
A figura acima apresenta o tempo de 81 milissegundos utilizados para inserção de
registros na tabela TB-SETOR no banco de dados PostgreSQL.
SELECT COUNT TB_SETOR
Quantidade de registros
inseridos na tabela setor
A figura acima apresenta a quantidade de 927 registros inseridos na tabela
TB_SETOR no banco de dados PostgreSQL.
142
INSERT TB_RESPONSAVEL
Temo utilizado para
inserção de dados na
tabela responsavel
A figura acima apresenta o tempo de 570 milissegundos utilizado para inserção de
registros na tabela TB_RESPONSAVEL no banco de dados PostgreSQL.
SELECT COUNT TB_RESPONSAVEL
Quantidade de registros
inseridos na tabela
responsavel
A figura acima apresenta a quantidade de 710 registros inseridos na tabela
TB_RESPONSAVEL no banco de dados PostgreSQL.
143
1 º LOTE DE INSERT TB_USUARIO
Temo utilizado para
inserção do 1°lote na
tabela usuario
A figura acima apresenta o tempo de 2.804 milissegundos utilizado para inserção de
registros na tabela TB_USUARIO no banco de dados PostgreSQL.
SELECT COUNT TB_USUARIO
Quantidade de registros
inseridos na tabela
usuário no 1° lote de
18.000
A figura acima apresenta a quantidade de 18.00 registros inseridos na tabela
TB_USUARIO no banco de dados PostgreSQL.
144
2 º LOTE DE INSERT TB_USUARIO
Temo utilizado para
inserção do 2°lote na
tabela usuario
A figura acima apresenta o tempo de 2.313 milissegundos utilizado para inserção de
registros na tabela TB_USUARIO no banco de dados PostgreSQL.
SELECT COUNT TB_USUARIO
Quantidade total de
registros da tabela
usuário após a inserção
do 2° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_USUARIO no banco de dados PostgreSQL, totalizando 36.000 registros.
145
3 º LOTE DE INSERT TB_USUARIO
Temo utilizado para
inserção do 3°lote na
tabela usuario
A figura acima apresenta o tempo de 2.964 milissegundos utilizado para inserção de
registros na tabela TB_USUARIO no banco de dados PostgreSQL.
SELECT COUNT TB_USUARIO
Quantidade total de
registros da tabela
usuário após a inserção
do 3° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_USUARIO no banco de dados PostgreSQL, totalizando 54.000 registros.
146
4 º LOTE DE INSERT TB_USUARIO
Temo utilizado para
inserção do 4°lote na
tabela usuario
A figura acima apresenta o tempo de 2.754 milissegundos utilizado para inserção de
registros na tabela TB_USUARIO no banco de dados PostgreSQL.
SELECT COUNT TB_USUARIO
Quantidade total de
registros da tabela
usuário
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_USUARIO no banco de dados PostgreSQL, totalizando 72.000 registros
147
1 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 1°lote na
tabela demanda
A figura acima apresenta o tempo de 3.946 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
A figura acima apresenta a quantidade de 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL.
148
2 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 2°lote na
tabela demanda
A figura acima apresenta o tempo de 3.765 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 36.000.
149
3 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 3°lote na
tabela demanda
A figura acima apresenta o tempo de 24.135 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 3° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 54.000
150
4 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 4°lote na
tabela demanda
A figura acima apresenta o tempo de 9.093 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 4° lote de 18.000
figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 72.000
151
5 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 5°lote na
tabela demanda
A figura acima apresenta o tempo de 7.409 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 5° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 90.000
152
6 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 6°lote na
tabela demanda
A figura acima apresenta o tempo de 7.152 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 6° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 108.000
153
7 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 7°lote na
tabela demanda
A figura acima apresenta o tempo de 4.410 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 7° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 126.000
154
8 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 8°lote na
tabela demanda
A figura acima apresenta o tempo de 7.445 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 8° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 144.000
155
9 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 9°lote na
tabela demanda
A figura acima apresenta o tempo de 10.873 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 9° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 162.000.
156
10 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 10°lote na
tabela demanda
A figura acima apresenta o tempo de 6.078 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
Quantidade total de
registros da tabela
demanda após a inserção
do 10° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 180.000
157
11 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 11°lote na
tabela demanda
A figura acima apresenta o tempo de 4.437 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 11° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 198.000
158
12 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 12°lote na
tabela demanda
A figura acima apresenta o tempo de 8.843 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 12° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando216.000
159
13 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 13°lote na
tabela demanda
A figura acima apresenta o tempo de 15.102 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 13° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 234.000
160
14 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 14°lote na
tabela demanda
A figura acima apresenta o tempo de 10.205 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 14° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 252.000
161
15 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 15°lote na
tabela demanda
A figura acima apresenta o tempo de 13.058 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 15° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 270.000
162
16 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 16°lote na
tabela demanda
A figura acima apresenta o tempo de 7.751 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 16° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 288.000
163
17 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 17°lote na
tabela demanda
A figura acima apresenta o tempo de 12.518 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 17° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 306.000
164
18 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 18°lote na
tabela demanda
A figura acima apresenta o tempo de 8.122 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 18° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 324.000
165
19 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 19°lote na
tabela demanda
A figura acima apresenta o tempo de 13.552 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do19° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 342.000
166
20 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 20°lote na
tabela demanda
A figura acima apresenta o tempo de 13.198 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 20° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 360.000
167
21 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 21°lote na
tabela demanda
A figura acima apresenta o tempo de 14.891 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 21° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 378.000
168
22 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 22°lote na
tabela demanda
A figura acima apresenta o tempo de 10.577 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 22° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 396.000
169
23 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 23°lote na
tabela demanda
A figura acima apresenta o tempo de 11.369 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 24° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 414.000
170
24º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 24°lote na
tabela demanda
A figura acima apresenta o tempo de 17.515 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 24° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 432.000
171
25 º LOTE DE INSERT TB_DEMANDA
Temo utilizado para
inserção do 25°lote na
tabela demanda
A figura acima apresenta o tempo de 12.277 milissegundos utilizado para inserção de
registros na tabela TB_DEMANDA no banco de dados PostgreSQL.
SELECT COUNT TB_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 25° lote de 18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 450.000
172
1 º LOTE DE INSERT TB_HISTORICO_DEMANDA
Temo utilizado para
inserção do 1°lote na
tabela historico demanda
A figura acima apresenta o tempo de 27.800 milissegundos utilizado para inserção de
registros na tabela TB_HISTORICO_DEMANDA no banco de dados PostgreSQL.
SELECT TB_HISTORICO_DEMANDA
Quantidade total de
registros da tabela
demanda após a inserção
do 1° lote de 18.000
A figura acima apresenta a quantidade de 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL.
173
2 º LOTE DE INSERT TB_HISTORICO_DEMANDA
Temo utilizado para
inserção do 2°lote na
tabela demanda
A figura acima apresenta o tempo de 17.205 milissegundos utilizado para inserção de
registros na tabela TB_HISTORICO_DEMANDA no banco de dados PostgreSQL.
SELECT TB_HISTORICO_DEMANDA
Quantidade total de registros
da tabela histórico demanda
após a inserção do 2° lote de
18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 36.000
174
3 º LOTE DE INSERT TB_HISTORICO_DEMANDA
Temo utilizado para
inserção do 3°lote na
tabela historico demanda
A figura acima apresenta o tempo de 30.013 milissegundos utilizado para inserção de
registros na tabela TB_HISTORICO_DEMANDA no banco de dados PostgreSQL.
SELECT TB_HISTORICO_DEMANDA
Quantidade total de
registros da tabela
histórico demanda após a
inserção do 3° lote de
18.000
A figura acima apresenta a quantidade de mais 18.000 registros inseridos na tabela
TB_DEMANDA no banco de dados PostgreSQL, totalizando 54.000
175
APÊNDICE C - PRINT DOS TESTES DE UPDATES REALIZADOS NOS SGBDS
MYSQL E POSTGRESQL
1 MYSQL
1º TESTE DE UPDATE REALIZADO NO SGBD MYSQL
Temos utilizados para
realização dos três
updade no 1º teste
A figura acima apresenta os tempos de 1,883, 1,702 e 1,642 segundos, utilizados
para realização dos updates no 1º teste no SGBD MySQL.
2º TESTE DE UPDATE REALIZADO NO SGBD MYSQL
Temos utilizados para
realização dos três
updade no 2º teste
A figura acima apresenta os tempos de 0,691, 0,180 e 0,241 segundos, utilizados
para realização dos updates no 2º teste no SGBD MySQL.
176
3º TESTE DE UPDATE REALIZADO NO SGBD MYSQL
Temos utilizados para
realização dos três
updade no 3º teste
A figura acima apresenta os tempos de 19,588, 17,605 e 16,804 segundos, utilizados
para realização dos updates no 3º teste no SGBD MySQL.
4º TESTE DE UPDATE REALIZADO NO SGBD MYSQL
Temos utilizados para
realização dos três
updade no 4º teste
A figura acima apresenta os tempos de 1,733 0,931 e 1,302 segundos, utilizados para
realização dos updates no 4º teste no SGBD MySQL.
177
5º TESTE DE UPDATE REALIZADO NO SGBD MYSQL
Temos utilizados para
realização dos três
updade no 5º teste
A figura acima apresenta os tempos de 2,734, 2,684 e 2,133 segundos, utilizados
para realização dos updates no 5º teste no SGBD MySQL.
6º TESTE DE UPDATE REALIZADO NO SGBD MYSQL
Temos utilizados para
realização dos três
updade no 6º teste
A figura acima apresenta os tempos de 3,785, 2,644 e 2,544 segundos, utilizados
para realização dos updates no 6º teste no SGBD MySQL.
178
POSTGRESQL
No PostgreSQL cada update realizado foi retirado três prints, um para cada update
realizado,devido ao fato de não ser possível printar o histórico dos três updates.
1º UPDATE DO TESTE 1
Temos utilizado para
realização do 1° update
do teste 1
A figura acima apresenta o tempo de 2063 milissegundos utilizados para realização
do 1° update no teste 1.
2º UPDATE DO TESTE 1
Temos utilizado para
realização do 2° update
do teste 1
A figura acima apresenta o tempo de 751 milissegundos utilizados para realização do
2° update no teste 1.
179
3º UPDATE DO TESTE 1
Temos utilizado para
realização do 3° update
do teste 1
A figura acima apresenta o tempo de 821 milissegundos utilizados para realização do
3° update no teste 1
1º UPDATE DO TESTE 2
Temos utilizado para
realização do 1° update
do teste 2
A figura acima apresenta o tempo de 37754 milissegundos utilizados para realização
do 1° update no teste 2
180
2º UPDATE DO TESTE 2
Temos utilizado para
realização do 2° update
do teste 2
A figura acima apresenta o tempo de 191 milissegundos utilizados para realização do
2° update no teste 2.
3º UPDATE DO TESTE 2
Temos utilizado para
realização do 3° update
do teste 2
A figura acima apresenta o tempo de 191 milissegundos utilizados para realização do
3° update no teste 2.
181
1º UPDATE DO TESTE 3
Temos utilizado para
realização do 1° update
do teste 3
A figura acima apresenta o tempo de 4677 milissegundos utilizados para realização
do 1° update no teste 3.
2º UPDATE DO TESTE 3
Temos utilizado para
realização do 2° update
do teste 3
A figura acima apresenta o tempo de 120 milissegundos utilizados para realização do
2° update no teste 3.
182
3º UPDATE DO TESTE 3
Temos utilizado para
realização do 3° update
do teste 3
A figura acima apresenta o tempo de 100 milissegundos utilizados para realização do
3° update no teste 3.
1º UPDATE DO TESTE 4
Temos utilizado para
realização do 1° update
do teste 4
A figura acima apresenta o tempo de 3435 milissegundos utilizados para realização
do 1° update no teste 4.
183
2º UPDATE DO TESTE 4
Temos utilizado para
realização do 2° update
do teste 4
A figura acima apresenta o tempo de 1181 milissegundos utilizados para realização
do 2° update no teste 4.
3º UPDATE DO TESTE 4
Temos utilizado para
realização do 3° update
do teste 4
A figura acima apresenta o tempo de 1072 milissegundos utilizados para realização
do 3° update no teste 4.
184
1º UPDATE DO TESTE 5
Temos utilizado para
realização do 1° update
do teste 5
A figura acima apresenta o tempo de 10355 milissegundos utilizados para realização
do 1° update no teste 5.
2º UPDATE DO TESTE 5
Temos utilizado para
realização do 2° update
do teste 5
A figura acima apresenta o tempo de 2634 milissegundos utilizados para realização
do 2° update no teste 5.
185
3º UPDATE DO TESTE 5
Temos utilizado para
realização do 3° update
do teste 5
A figura acima apresenta o tempo de 3776 milissegundos utilizados para realização
do 3° update no teste 5.
1º UPDATE DO TESTE 6
Temos utilizado para
realização do 1° update
do teste 6
A figura acima apresenta o tempo de 5658 milissegundos utilizados para realização
do 1° update no teste 6.
186
2º UPDATE DO TESTE 6
Temos utilizado para
realização do 2° update
do teste 6
A figura acima apresenta o tempo de 18828 milissegundos utilizados para realização
do 2° update no teste 6.
3º UPDATE DO TESTE 6
Temos utilizado para
realização do 3° update
do teste 6
A figura acima apresenta o tempo de 7290 milissegundos utilizados para realização
do 3° update no teste 6.
187
APÊNDICE D – PRINT DOS TESTES DE DELETE NOS SGBDS MYSQL E
POSTGRESQL
MYSQL
1º TESTE DE DELETE NO SGBD MYSQL
Tempos utilizados para
realização dos três
DELETE no teste 1
A figura acima apresenta os tempos de 2,734, 3,055 e 3,275 segundos, utilizados
para realização dos DELETE no 1º teste no SGBD MySQL.
2º TESTE DE DELETE NO SGBD MYSQL
Tempos utilizados para
realização dos três
DELETE no teste 2
A figura acima apresenta os tempos de 0,050, 0,000 e 0,010 segundos, utilizados
para realização dos delete no 2º teste no SGBD MySQL.
188
3º TESTE DE DELETE NO SGBD MYSQL
Tempos utilizados para
realização dos três
DELETE no teste 3
A figura acima apresenta os tempos de 36,223, 4,466 e 3,965 segundos, utilizados
para realização do delete no 3º teste no SGBD MySQL.
4º TESTE DE DELETE NO SGBD MYSQL
Tempos utilizados para
realização dos três
DELETE no teste 4
A figura acima apresenta os tempos de 5,488, 3,876 e 2,644 segundos, utilizados
para realização do delete no 3º teste no SGBD MySQL.
189
5º TESTE DE DELETE NO SGBD MYSQL
Tempos utilizados para
realização dos três
DELETE no teste 5
A figura acima apresenta os tempos de 0040, 0,010 e 0,010 segundos, utilizados para
realização do delete no 5º teste no SGBD MySQL.
6º TESTE DE DELETE NO SGBD MYSQL
Tempos utilizados para
realização dos três
DELETE no teste 6
A figura acima apresenta os tempos de 24,396, 2,654 e 2,694 segundos, utilizados
para realização do delete no 6º teste no SGBD MySQL.
190
POSTGRESQL
1º E 2º TEMPO DE DELETE DO TESTE 1
1º Tempo utilizado
para realização do
1º delete no teste 1
2º Tempo utilizado
para realização do
1º delete no teste 1
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 2173 e o 2º
tempo de 90, utilizados para realização do 1º delete no teste 1
3º TEMPO DE DELETE DO TESTE 1
3º Tempo utilizado
para realização do
1º delete no teste 1
A figura acima apresenta o tempo de 91 milissegundos utilizados para realização do
1° delete no teste 1.
191
1º e 2º TEMPO DE DELETE DO TESTE 2
1º Tempo utilizado
para realização do
2º delete no teste 2
2º Tempo utilizado
para realização do
2º delete no teste 2
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 70 e o 2º
tempo de 10, utilizados para realização do 1º e 2º delete no teste 2
3º TEMPO DE DELETE DO TESTE 2
3º Tempo utilizado
para realização do
2º delete no teste 2
A figura acima apresenta o 3º tempo de 10 milissegundos, utilizados para realização
do 3º delete no teste 2.
192
1º E 2º TEMPO DE DELETE DO TESTE 3
1º Tempo utilizado
para realização do
3º delete no teste 3
2º Tempo utilizado
para realização do
3º delete no teste 3
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 1535 e o 2º
tempo de 220, utilizados para realização do 1º e 2º delete no teste 3
3º TEMPO DE DELETE DO TESTE 3
3º Tempo utilizado
para realização do
3º delete no teste 3
A figura acima apresenta o 3º tempo de 293 milissegundos, utilizados para realização
do 3º delete no teste 3.
193
1º E 2º TEMPO DE DELETE DO TESTE 4
1º Tempo utilizado
para realização do
4º delete no teste 4
2º Tempo utilizado
para realização do
4º delete no teste 4
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 80 e o 2º
tempo de 110, utilizados para realização do 1º e 2º delete no teste 4
3º TEMPO DE DELETE DO TESTE 4
3º Tempo utilizado
para realização do
4º delete no teste 4
A figura acima apresenta o 3º tempo de 70 milissegundos, utilizados para realização
do 3º delete no teste 4.
194
1º E 2º TEMPO DE DELETE DO TESTE 5
1º Tempo utilizado
para realização do 5º
delete no teste 5
2º Tempo utilizado
para realização do 5º
delete no teste 5
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 10 e o 2º
tempo de 20, utilizados para realização do 1º e 2º delete no teste 5
3º TEMPO DE DELETE DO TESTE 5
3º Tempo utilizado
para realização do 5º
delete no teste 5
A figura acima apresenta o 3º tempo de 10 milissegundos, utilizados para realização
do 3º delete no teste 5.
195
1º E 2º TEMPO DE DELETE DO TESTE 6
1º Tempo utilizado
para realização do 6º
delete no teste 6
2º Tempo utilizado
para realização do 6º
delete no teste 6
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 1502 e o 2º
tempo de 491, utilizados para realização do 1º e 2º delete no teste 6.
3º TEMPO DE DELETE DO TESTE 6
3º Tempo utilizado
para realização do 6º
delete no teste 6
A figura acima apresenta o 3º tempo de 370 milissegundos, utilizados para realização
do 3º delete no teste 6.
196
APÊNDICE E – PRINT DOS TESTES DE SELECT NOS SGBDS MYSQL E
POSTGRESQL
MYSQL
1º TESTE DE SELECT NO SGBD MYSQL
Temos utilizados para
realização dos três select
no 1º teste
A figura acima apresenta os tempos de 2,784, 1,472 e 0,701 segundos, utilizados
para realização dos select no 1º teste no SGBD MySQL.
2º TESTE DE SELECT NO SGBD MYSQL
Temos utilizados para
realização dos três select
no 2º teste
A figura acima apresenta os tempos de 19,177, 21,090 e 21,752 segundos, utilizados
para realização dos select no 2º teste no SGBD MySQL.
197
3º TESTE DE SELECT NO SGBD MYSQL
Temos utilizados para
realização dos três select
no 3º teste
A figura acima apresenta os tempos de 0,881, 0,011 e 0,010 segundos, utilizados
para realização dos select no 3º teste no SGBD MySQL.
4º TESTE DE SELECT NO SGBD MYSQL
Temos utilizados para
realização dos três select
no 4º teste
A figura acima apresenta os tempos de 0,090, 0,000, e 0,010 segundos, utilizados
para realização dos select no 4º teste no SGBD MySQL.
198
5º TESTE DE SELECT NO SGBD MYSQL
Temos utilizados para
realização dos três select
no 5º teste
A figura acima apresenta os tempos de 0,912, 0,010, 0,000 segundos, utilizados para
realização dos select no 5º teste no SGBD MySQL.
6º TESTE DE SELECT NO SGBD MYSQL
Temos utilizados para
realização dos três select
no 6º teste
A figura acima apresenta os tempos de 3,124, 0,020, e 0,020 segundos, utilizados
para realização dos select no 6º teste no SGBD MySQL.
199
7º TESTE DE SELECT NO SGBD MYSQL
Temos utilizados para
realização dos três select
no 7º teste
A figura acima apresenta os tempos de 0,961, 0,010, e 0,010 segundos, utilizados
para realização dos select no 7º teste no SGBD MySQL.
8º TESTE DE SELECT NO SGBD MYSQL
Temos utilizados para
realização dos três select
no 8º teste
A figura acima apresenta os tempos de 0,971, 0,010, e 0,000 segundos, utilizados
para realização dos select no 8º teste no SGBD MySQL.
200
POSTGRESQL
1º E 2º TEMPO DE SELECT DO TESTE 1
1º Tempo utilizado para
realização do 1º select no
teste 1
2º Tempo utilizado para
realização do 1º select no
teste 1
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 2163 e o 2º
tempo de 1222, utilizados para realização do 1º e 2º select no teste 1
3º TEMPO DE SELECT DO TESTE 1
3º Tempo utilizado para
realização do 1º select no
teste 1
A figura acima apresenta o 3º tempo de 1232 milissegundos, utilizados para
realização do 3º select no teste 1.
201
1º e 2º TEMPO DE SELECT DO TESTE 2
1º Tempo utilizado para
realização do 1º select no
teste 2
2º Tempo utilizado para
realização do 1º select no
teste 2
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 2067 e o 2º
tempo de 1212 utilizados para realização do 1º e 2º select no teste 2.
3º TEMPO DE SELECT DO TESTE 2
3º Tempo utilizado para
realização do 1º select no
teste 2
A figura acima apresenta o 3º tempo de 1174 milissegundos, utilizados para
realização do 3º select no teste 2.
.
202
1º e 2º TEMPO DE SELECT DO TESTE 3
1º Tempo utilizado para
realização do 1º select no
teste 3
2º Tempo utilizado para
realização do 1º select no
teste 3
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 189 e o 2º
tempo de 38, utilizados para realização do 1º e 2º select no teste 3.
3º TEMPO DE SELECT DO TESTE 3
3º Tempo utilizado para
realização do 1º select no
teste 3
A figura acima apresenta o 3º tempo de 38 milissegundos, utilizados para realização
do 3º select no teste 3.
203
1º e 2º TEMPO DE SELECT DO TESTE 4
1º Tempo utilizado para
realização do 1º select no
teste 4
2º Tempo utilizado para
realização do 1º select no
teste 4
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 140 e o 2º
tempo de 60, utilizados para realização do 1º e 2º select no teste 4.
3º TEMPO DE SELECT DO TESTE 4
3º Tempo utilizado para
realização do 1º select no
teste 4
A figura acima apresenta o 3º tempo de 50 milissegundos, utilizados para realização
do 3º select no teste 4.
204
1º e 2º TEMPO DE SELECT DO TESTE 5
1º Tempo utilizado para
realização do 1º select no
teste 5
2º Tempo utilizado para
realização do 1º select no
teste 5
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 30 e o 2º
tempo de 40, utilizados para realização do 1º e 2º select no teste 5.
3º TEMPO DE SELECT DO TESTE 5
3º Tempo utilizado para
realização do 1º select no
teste 5
A figura acima apresenta o 3º tempo de 30 milissegundos, utilizados para realização
do 3º select no teste 5.
205
1º e 2º TEMPO DE SELECT DO TESTE 6
1º Tempo utilizado para
realização do 1º select no
teste 6
2º Temo utilizado para
realização do 1º select no
teste 6
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 13776 e o 2º
tempo de 15614, utilizados para realização do 1º e 2° select no teste 6.
3º TEMPO DE SELECT DO TESTE 6
3º Temo utilizado para
realização do 1º select no
teste 6
A figura acima apresenta o 3º tempo de 22622 milissegundos, utilizados para
realização do 3º select no teste 6.
206
1º e 2º TEMPO DE SELECT DO TESTE 7
1º Tempo utilizado para
realização do 1º select no
teste 7
2º Tempo utilizado para
realização do 1º select no
teste 7
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 1532 e o 2º
tempo de 2443, utilizados para realização do 1º e 2º select no teste 7.
3º TEMPO DE SELECT DO TESTE 7
3º Tempo utilizado para
realização do 1º select no
teste 7
A figura acima apresenta o 3º tempo de 1452 milissegundos, utilizados para
realização do 3º select no teste 7.
207
1 e 2º TEMPO DE SELECT DO TESTE 8
1º Tempo utilizado para
realização do 1º select no
teste 8
2º Tempo utilizado para
realização do 1º select no
teste 8
A figura acima apresenta dois tempos em milissegundos: O 1º tempo de 251 e o 2º
tempo de 40, utilizados para realização do 1º e 2º select no teste 8.
3º TEMPO DE SELECT DO TESTE 8
3º Tempo utilizado para
realização do 1º select no
teste 8
A figura acima apresenta o 3º tempo de 50 milissegundos, utilizados para realização
do 3º select no teste 8.
208
APÊNDICE F – CD COM OS REGISTROS UTILIZADOS PARA INSERÇÃO DE
DADOS NAS TABELAS