Universidade Federal de Itajubá

Instituto de Matemática e Computação

COM-231 – BANCO DE DADOS II
Profª Vanessa Souza

BANCO DE DADOS II
DEFINIÇÃO DO TRABALHO PRÁTICO I
Introdução
Este documento descreve as características do Primeiro Trabalho Prático de Banco de Dados II
do curso de graduação em Ciência da Computação da Universidade Federal de Itajubá – 1º
semestre de 2019.
O trabalho consiste no consumo e disponibilização de dados obtidos por uma API de
Dados.

Objetivo
Coletar dados de uma API de Dados, modelá-los utilizando o modelo relacional, realizar a carga
e otimização do banco de dados e implementar um dashboard para apresentação desses
dados.

API de Dados
Segundo Alvarenga et al. (2011), há muitas formas de disponibilizar os dados: eles podem
ser publicados em páginas da web, podem ser expostos via uma interface de consulta
em um website, ou podem ser acessados diretamente por sistemas eletrônicos via uma
API (interface de programação de aplicativo).
Dentre essas formas, o uso de APIs (serviços web), apresenta diversos benefícios, tais como
(Kong, 2015):
 Interoperabilidade entre os sistemas, garantido escalabilidade, facilidade de uso, além
de possibilitar atualização de forma simultânea e em tempo real.
 a economia de tempo e custo dos pedidos de acesso à informação
 a possibilidade de cruzar dados de diferentes órgãos gerando novas agregações
 aumento da participação social
 estímulo a inovação
 economia de tempo e dinheiro
 melhora nos serviços governamentais
Na prática, uma API é simplesmente a exposição de uma série de ferramentas, métodos de
programação e protocolos, com o objetivo de facilitar a programação de uma aplicação1.

1
https://sensedia.com/blog/apis/o-que-sao-apis-parte-1-introducao/
 Universidade Federal de Itajubá
Instituto de Matemática e Computação
COM-231 – BANCO DE DADOS II
Profª Vanessa Souza

Portanto, uma API de Dados é um serviço web que disponibiliza dados. Para obter os dados é
preciso obedecer aos padrões definidos pela interface.

Dashboard
Vejam a definição da Wikipedia:
“O termo dashboard é utilizado para indicar um "painel de indicadores", como por exemplo, o
painel de indicadores de um automóvel (indicador de velocidade, indicador de rotações do
motor, indicador de temperatura do motor, indicador do nível do óleo etc.). Em Tecnologia da
Informação, o dashboard é uma tela, composta de uma ou mais camadas, sob a forma de um
painel, com instrumentos onde se associam variáveis a serem monitoradas além de gráficos
que mostram a evolução de variáveis, por exemplo, no tempo.”
Existem ferramentas de dashboard2, ou você pode utilizar uma linguagem de
programação para gerar o seu próprio. É importante lembrar que essa é uma disciplina de
Banco de Dados, então faz parte da avaliação, que vocês construam as consultas SQL que farão
parte do Dashboard.

Metodologia
As etapas do trabalho estão listadas na figura 1. Na primeira etapa o grupo deverá estudar o
conceito de API e escolher alguma para trabalhar. Cada grupo deve escolher uma API
diferente. Para garantir que não haverá grupos utilizando a mesma API, será criado um fórum
no SIGAA, onde os grupos deverão indicar o serviço utilizado. A preferência será por “ordem
de chegada”. Ou seja, se o seu grupo escolheu uma API que outro grupo já postou no fórum,
vocês deverão escolher outra.

2
https://www.idashboards.com/dashboard-examples/it-dashboard-example-tech/
 Universidade Federal de Itajubá
Instituto de Matemática e Computação
COM-231 – BANCO DE DADOS II
Profª Vanessa Souza

•Estudar as APIs de dados

•Escolher uma API para utilizar no trabalho, garantindo que nenhum outro grupo já está utilizando a
Etapa 1 mesma

•Estudar os dados da API e definir quais serão consumidos

•Gerar os requisitos e modelo de relatórios
•Gerar um modelo relacional a partir dos dados consumidos
Etapa 2 •Implementar o banco de dados relacional

•Desenvolver uma aplicação para consumir os dados da API

•Dar carga no banco de dados
Etapa 3 •Otimizar o banco de dados

•Estudar sobre Dashboards

•Implementar um Dashboard para a base de dados analisada
Etapa 4

•Avaliar a performance dos bancos relacional e orientado a documentos utilizando o JMeter

Etapa 5

•Reutilizar parte da aplicação implementada na Etapa 3 para popular um banco Orientado a

Documentos - MongoDB
•Adaptar o dashboard para ler os dados do MongoDB
Etapa 6 •Comparar a performance obtida na Etapa 6 com os resultados obtidos para análise de performance
com o MongoDB

•Apresentar os resultados obtidos nas etapas 3, 4, 5 e 6

Etapa 7

Figura 1 : Etapas do trabalho prático.

Na segunda etapa, o grupo fará o trabalho de engenharia reversa, ou seja, irá estudar
os dados fornecidos pela API e decidirá quais irão consumir. Em geral, cada API fornece um
conjunto enorme de dados. O grupo deverá pensar no conjunto que melhor atenderá a etapa
4, onde uma aplicação deverá ser desenvolvida sobre esse conjunto de dados. Os produtos
finais dessa etapa serão o esquema do banco de dados relacional e os requisitos dos relatórios
gerados. O SGBD é de livre escolha do grupo. Essa é uma etapa fundamental no projeto. É
preciso entender o dado e o quê é possível extrair deles. Algumas questões importantes são:
 Universidade Federal de Itajubá
Instituto de Matemática e Computação
COM-231 – BANCO DE DADOS II
Profª Vanessa Souza

a) Conhecer o processo
b) Levantar as perguntas que serão respondidas pelo dashboard
c) Levantar como o cliente gosta de visualizar as informações

Na letra a, entende-se o escopo dos dados. Aqui é importante entender a origem dos
dados. Ou seja, o processo original. É importante também saber o quanto o dado foi
manipulado. Dados muito sumarizados são ruins para este projeto porque não permitem
‘explicar’ o processo original e/ou suas consequências.
Na letra b, avalia-se aquilo que será representado pelo dashboard. Para tanto, é
necessário entender o processo original e apresentar informações que ajudem a explicá-lo.
Uma boa prática é escrever de forma literal o objetivo do painel e fazer um protótipo do
mesmo. O protótipo pode ser desenhado na mão, pensando nas funções de iteração com a
visualização3.
Na letra c, avalia-se como aquela informação que se deseja representar é melhor
representada. Pode ser gráfico de barras, de pizza, de pontos, dados tabulares, etc.
Na terceira etapa, o grupo irá implementar uma aplicação que consome os dados
dessa API. A linguagem de programação é livre. Essa aplicação deverá cumprir os seguintes
requisitos:
1. Acessar a API e fazer o download o conjunto de dados a partir de um filtro. Em
geral, as APIs retornam dados em algum formato texto (Json, XML, CSV). O
grupo pode escolher qual utilizar. A professora prefere JSON ou XML.
2. Extrair os dados do documento texto e dar carga nas tabelas do banco de
dados
É necessário baixar um alto volume de dados. O limite depende do hardware utilizado.
Baixem dados suficientes para ter uma boa amostra, mas no limite em que o banco retorne os
comandos em tempo plausível.
Com o banco parcialmente, ou totalmente populado, o grupo fará as otimizações,
como a criação de índices, definição de usuários e de privilégios no banco.
Na quarta etapa, o grupo deverá estudar sobre dashboards e escolher a forma de
implementá-lo. A linguagem é livre. Pode ser tanto utilizando linguagem de programação,
quanto utilizando alguma ferramenta específica de dashboard. O importante é que o mesmo
dashboard deverá funcionar a partir do banco relacional e do banco orientado a documentos
3
https://uxplanet.org/10-rules-for-better-dashboard-design-ef68189d734c
 Universidade Federal de Itajubá
Instituto de Matemática e Computação
COM-231 – BANCO DE DADOS II
Profª Vanessa Souza

(não ao mesmo tempo). O dashboard deve ser dinâmico, permitir o uso de filtros e de ‘cliques
na tela’.
Na quinta etapa, o grupo escolherá a consulta mais custosa do dashboard
implementado para realizar as medidas de performance nos bancos utilizando o software
JMeter4. O grupo deverá medir latência e vazão nas seguintes condições:
1. Mantém a quantidade de usuários (threads) como 1 e aumenta a quantidade
de requisições até o teste retornar erro. Esse será o número máximo de
requisições suportadas pelo banco para essa consulta.
2. Defina uma quantidade de requisições fixa e aumente a quantidade de
usuários até o teste retornar erro. Esse será o número máximo de usuários
suportados pelo banco para essa consulta.
Cada análise deverá gerar um gráfico (latência x número de requisições; latência x
número de usuários; o mesmo para a vazão).
É importante ressaltar que os SGBDs definem, por padrão, um número máximo de
requisições e usuários que podem se conectar ao mesmo tempo no banco. Esse número é
configurável. Sendo assim, o grupo deve alterar esses valores antes de iniciar os teste.
Na sexta etapa o grupo deverá modelar e popular um banco orientado a documentos
utilizando o MongoDB e atualizar a aplicação (dashboard) para ler os dados do MongoDB.
Nesta etapa a performance do MongoDB deve ser testada com JMeter e comparada ao do
SGBD Relacional.
A sétima etapa acontecerá nos dias 18 e 24 e 25 de Junho, durante as aulas, onde os
grupos apresentarão para toda a turma a aplicação e o banco desenvolvidos. A ordem de
apresentação será sorteada no início da aula do dia 18.
Nesta ocasião, o grupo deverá entregar impresso:
a) Documento com a definição/prototipação dos relatórios
b) Relatório do banco de dados
 DER, DR, definição de grupos de usuários e suas permissões, definição
de índices e justificativas, definição de views, triggers, procedures,
funções e suas justificativas, caso existam.
c) Backup do schema do banco
d) Print com o count em cada tabela
e) Backup do schema do banco orientado a documentos
f) Print com o count em cada coleção

4
https://jmeter.apache.org/
 Universidade Federal de Itajubá
Instituto de Matemática e Computação
COM-231 – BANCO DE DADOS II
Profª Vanessa Souza

g) Resultados do teste de performance

Grupos
9 grupos de 4 pessoas.
 Será aberto um fórum no SIGAA e os grupos deverão informar os participantes lá
até 12/03.

Considerações Importantes
 A análise da base de dados é FUNDAMENTAL para que vocês tenham um bom
trabalho. É MUITO IMPORTANTE que vocês estudem bem a base e pensem nos
relatórios antes de escolhê-la.
 NÃO é permitido ao grupo criar dados na base. A aplicação deve girar em torno dos
dados disponíveis.
 NÃO é permitido baixar dados completos, ou seja, arquivos com o conjunto inteiro de
dados.
 NÃO UTILIZAR A API DE DADOS IRÁ ZERAR O TRABALHO
 É praxe dos alunos deixar o teste de performance (JMeter) para o final e isso acarreta
perda de nota, uma vez que muitos grupos não conseguem executar o JMeter como
deveria. Sugiro que vocês elejam um membro do grupo para aprender usar a
ferramenta com maestria.
 PONTUAÇÃO:
o Etapa 3 : 6 pontos
o Etapa 4 : 10 pontos
o Etapa 5 : 5 pontos
o Etapa 6 : 4 pontos