IA 875 – Sistemas Paralelos para Processamento de Informação
Prof. Ivan Luiz Marques Ricarte
1o semestre de 2000
Repositório de dados da pós-graduação
Visão do Aluno
Carlos Henrique Quartucci Forster
Cristina Enomoto
Francisco Sérgio Sambatti
931779
941377
001089
Resumo – Este artigo contém a descrição de uma possível definição da visão do aluno para o
repositório de dados da pós-graduação da FEEC. Como partes dessa descrição incluem-se um
modelo de dados do tipo entidade-relacionamento e a especificação de algumas consultas exemplo.
Além da especificação destas consultas são realizadas sugestões para sua implementação, bem
como formatos dos dados de entrada e saída e definição de interface com o usuário. Também são
feitas considerações sobre a implementação paralela eficiente.
Introdução
A criação de um repositório de dados para a pós-graduação é um tema que desperta bastante
interesse por estar diretamente relacionado com a vida de seus alunos. Explorar, particularmente, a
visão do aluno vem a permitir o levantamento de problemas em banco de dados intimamente
relacionados com esta realidade tão próxima.
Este projeto realizou-se em um número de etapas: levantamento de requisitos, modelagem de dados
e elaboração das consultas. A definição da visão do aluno para o repositório de dados da pósgraduação foi realizada com base em um levantamento das necessidades dos alunos. Elaborou-se
então um modelo de dados para esta visão a fim de contemplar as informações necessárias para o
atendimento a estes requisitos, mas objetivando-se ser genérico o quanto possível a fim de tentar
limitar ao mínimo sua utilização quando do surgimento de novas necessidades ou variantes das
abordadas. Em seguida foram especificadas consultas exemplo que enquadram-se nos interesses
dos alunos, bem como apresentou-se sugestões para sua implementação, formatos de dados de
entrada e saída e definição de interface com o usuário.
Este artigo está organizado da seguinte maneira. Descrevem-se os métodos e resultados do
levantamento de requisitos. Em seguida, o modelo de dados é apresentado e comentado. Passa-se
então a descrever as consultas detalhadamente e são abordadas algumas questões sobre sua
implementação paralela. Por fim, são apresentadas as considerações finais deste trabalho.
Levantamento de Requisitos
O levantamento de requisitos foi realizado através de contatos informais com alunos da pósgraduação da FEEC e a partir da própria experiência dos autores, onde observou-se que havia
grande interesse em informações sobre a produção científica da unidade em várias dimensões:
departamento, docente e área de pesquisa. Com relação a questões mais operacionais, sugeriu-se
uma maior facilidade para integrar as “agendas” administrativas (datas de matrícula, início e término
do calendário acadêmico, etc) com as das atividades das disciplinas e da área de pesquisa. Também
nesse sentido levantaram-se outras questões relacionadas a facilitar o dia-a-dia do aluno, como por
exemplo, uma maneira automatizada de pesquisa de preços e disponibilidade na biblioteca de livros
das disciplinas em curso.
O Modelo de Dados
O modelo de dados que originou das necessidades dos usuários é apresentado na figura 1,
utilizando-se a notação IDEF1X.
Figura 1 – Modelo ER
Especificação das consultas
Foram especificadas quatro consultas, entre as quais, três a partir das sugestões levantadas e que
não envolvem grande processamento, ou seja, são consultas mais diretas e uma objetivando realizar
“data mining”, onde potencialmente ter-se-á um consumo maior deste tipo de recurso. A seguir, são
especificadas a finalidade de cada consulta.
• Pesquisa bibliográfica
A partir das disciplinas em que o aluno está matriculado, consulta as referências bibliográficas em
suas ementas, verificando a disponibilidade destas na biblioteca. Também realiza uma pesquisa de
preços e comentários a respeito dos livros nas livrarias on line cadastradas.
• Calendário de eventos
Permitir que o aluno tenha acesso aos compromissos e eventos a ele relevantes, através de um
calendário que contém datas importantes das disciplinas cursadas, de congressos de sua área de
pesquisa e de compromissos “administrativos” (por exemplo, datas de matrícula), entre outras.
• Estatísticas de produção do corpo docente
Dados da produção de papers nas dimensões docente, departamento e área de pesquisa. Dados
sobre o tempo médio que os orientados de um determinado docente levam para defender suas
dissertações ou teses.
2
• Distribuição de probabilidades de desempenho de um aluno, baseada na correlação entre
matérias.
Determinar a distribuição de probabilidades da nota de um aluno em uma disciplina com base em seu
histórico escolar e no histórico escolar dos demais alunos que já cursaram a disciplina. Analisar a
correlação entre matérias
Consulta - Pesquisa bibliográfica
Finalidade
A partir das disciplinas em que o aluno está matriculado, consulta as referências bibliográficas
existentes constantes da ementa, verificando sua disponibilidade na biblioteca. Também realiza uma
pesquisa de preços e comentários a respeito do livro presentes nas livrarias on-line cadastradas.
Entrada
•
•
RA do aluno
Semestre
Saída
Documento em XML (de acordo com o DTD desta consulta, que encontra-se no Anexo I) que
contenha para cada disciplina que o aluno cursa no semestre, os livros utilizados como referência, e
para cada livro, sua disponibilidade na biblioteca, preço em livrarias on-line e reviews presentes
nestas.
Um exemplo de documento XML gerado pela consulta (visualizado no Internet Explorer 5.5), pode ser
visto na figura 2.
Figura 2 – Visualização XML.
3
Implementação da consulta
Tabelas utilizadas
• DISCIPLINA
Tabela extraída do banco de dados da DAC e atualizada semestralmente. Contém o código e o nome
da disciplina.
• CURSOU
Tabela extraída do banco de dados da DAC e atualizada ao final do período de matrícula. Armazena
quais alunos estão matriculados em quais turmas para cada semestre, ou seja, armazena dados
históricos.
• EMENTA_LIVRO
• LIVRO
Tabelas extraídas dos “campos” referentes aos livros utilizados na disciplina a partir do documento
XML que armazena a ementa desta. Atualizada semestralmente e armazena dados históricos.
• LIVRARIA_LIVRO
Tabela que contém o preço atual dos livros a partir de consultas realizadas as livrarias on line
presentes na tabela LIVRARIA. Estas consultas são realizadas semanalmente no início do semestre e
mensalmente no restante do ano. Não são armazenados dados históricos e a consulta as livrarias
pressupõe um padrão de documentos XML para esta troca de informações.
• REVIEW
Tabela que contém os comentários dos livros presentes nas livrarias on line cadastradas na tabela
LIVRARIA. Estas consultas são realizadas mensalmente. Não são armazenados dados históricos e a
consulta as livrarias pressupõe um padrão de documentos XML para esta troca de informações.
• BIBLIOTECA_LIVRO
Tabela que contém o número de exemplares presentes na biblioteca da Unicamp, tanto para consulta
quanto para empréstimo. Estas consultas são realizadas semanalmente e não são armazenados
dados históricos. A troca de informações com a biblioteca também é realizada através da utilização
de documentos XML.
Consulta
A consulta é composta das subconsultas:
• livros presentes na ementa das disciplinas em que o aluno está matriculado no semestre
(VisaoLivrosSemestre):
SELECT DISCIPLINA_ID, TURMA_ID, DISCIPLINA_NM, ISBN
FROM
CURSOU, EMENTA_LIVRO, DISCIPLINA
WHERE CURSOU.ALUNO_ID = aluno AND
CURSOU.SEMESTRE = semestre AND
CURSOU.TURMA_ID = EMENTA_LIVRO.TURMA_ID AND
CURSOU.DISCIPLINA_ID = EMENTA_LIVRO.DISCIPLINA_ID AND
CURSOU.SEMESTRE = EMENTA_LIVRO.SEMESTRE AND
CURSOU.DISCIPLINA_ID = DISCIPLINA.DISCIPLINA_ID
•
livros das disciplinas do semestre disponíveis na biblioteca
SELECT ISBN, LIVRO_TITULO, AUTOR, EDITORA, EDICAO,
NUM_EXEMPLARES, NUM_EXEMPLARES_DISP, DISCIPLINA_ID,
TURMA_ID, DISCIPLINA_NM
FROM
LIVRO, BIBLIOTECA_LIVRO, VisaoLivrosSemestre
WHERE LIVRO.ISBN = VisaoLivrosSemestre.ISBN AND
LIVRO.ISBN = BIBLIOTECA_LIVRO.ISBN
•
preços e reviews dos livros das disciplinas do semestre
SELECT ISBN, LIVRO_TITULO, AUTOR, EDITORA, EDICAO,
DISCIPLINA_ID, TURMA_ID, DISCIPLINA_NM,
PRECO, REVIEW
FROM
LIVRO, LIVRARIA_LIVRO, REVIEW, VisaoLivrosSemestre
WHERE LIVRO.ISBN = VisaoLivrosSemestre.ISBN AND
4
LIVRO.ISBN = LIVRARIA_LIVRO AND
LIVRARIA_LIVRO.LIVRARIA_NM = REVIEW.LIVRARIA_NM AND
LIVRARIA_LIVRO.ISBN = REVIEW.ISBN
Consulta - Calendário de eventos
Finalidade
Uma informação essencial para o aluno é ter acesso às datas importantes associadas à
Universidade. Uma aplicação extremamente útil seria a possibilidade do aluno, a partir da sua
matrícula obter todas as datas relevantes do período acadêmico, agregando informações das
disciplinas em que o aluno está matriculado (datas de avaliações, entrega de trabalhos, tópico da
aula, etc.), datas importantes para a Universidade (feriados, período de matrícula, trancamento e
alteração de matrícula, etc.) e também receber informações a respeito de teses a serem defendidas
na sua área de interesse, congressos e eventos científicos ou informações a respeito de bolsas de
pesquisa (CAPES, CNPq, FAPESP).
Para que tudo isso seja possível é necessário que estas informações estejam disponíveis. Todas
essas informações já existem hoje em algum formato, distribuídos em vários locais como pode ser
observado a seguir:
DAC
PRP
FEEC
DISCENTE
ALUNO
DISCIPLINA
SEMESTRE
CALENDÁRIO (feriados oficiais, alteração, matrícula, desistência)
CALENDÁRIO CNPq, CAPES, PIBIC, FAPESP, OUTROS
CRONOGRAMA DE CONGRESSOS E EVENTOS CIENTÍFICOS
CRONOGRAMA DAS DISCIPLINAS
ÁREAS DE PESQUISA
CALENDÁRIO DE DEFESA DE TESES M/D
CPG
CENTRO ACADÊMICO
Tabela 1 - Localização das informações nas bases operacionais
Esta aplicação poderia ter como entrada, o identificador do aluno que é o seu registro acadêmico.
Com o RA é possível identificar as disciplinas em que o aluno está matriculado e buscar as atividades
associadas a elas, além de informações específicas também seriam disponibilizadas informações de
interesse geral. De forma a restringir o que será retornado, também é interessante que o aluno
indique quais as áreas de interesse e também o período desejado.
Entrada
•
•
•
•
RA - identificador do aluno
DATA INICIAL - definem o intervalo de interesse
DATA FINAL
FILTROS – áreas de interesse
Saída
• LISTA DE EVENTOS DO PERÍODO EM UM DOCUMENTO XML
A lista de eventos agrega informações de diversos tipos, desta forma é necessário criar uma estrutura
base comum a todos eventos e que permita a identificação do evento:
Informações básicas:
DATA
( DD/MM/YYYY HH:MI:SS )
DATA_INICIO
(DD/MM/YYYY HH:MI:SS)
DATA_FIM
(DD/MM/YYYY HH:MI:SS)
TIPO
DESCRIÇÃO
DISCIPLINA
TIPO
DESCRIÇÃO
ÁREA
5
Exemplo da interface de saída:
A interface da aplicação poderia ter a seguinte aparência, onde é exibido o calendário indicando a
presença de algum evento de determinado e também o acesso a detalhes dos eventos de um dia
selecionado:
Figura 3 – Calendário de Eventos.
Figura 4 – Calendário de Eventos – Zoom.
6
Implementação da Consulta
Utilizando o nosso modelo da base de dados poderíamos obter as informações das seguintes tabelas
e relacionamentos.
Tabelas Utilizadas
• CURSOU, TURMA E ATIVIDADE
CURSOU e TURMA são tabelas básicas de informações de alunos que podem ser extraídas da base
de dados da DAC com a atualização a cada período letivo.
ATIVIDADE é uma tabela extraída a partir de um modelo de documento XML para descrever o
cronograma de cada disciplina. Deve ser disponibilizado aos professores um aplicativo XML based
para que seja possível a edição do cronograma, disponibilização na página do curso e a inserção das
informações diretamente nesta tabela.
• TESE E TESE_AREA_PESQUISA
Tabelas extraídas do banco de dados do Instituto com atualização de acordo com a inserção de
novos eventos.
• EVENTOS
Esta tabela agrega informações extraídas da DAC, CPG, CONGRESSOS, PRP, além de um tipo
DISCENTE que permite a inserção de informações associadas ao centro acadêmico e atividades
afins. A atualização das informações dependem do tipo da informação, podendo ser por período letivo
(DAC) ou por eventos (DISCENTE, CPG)
Consulta
Esta consulta é o resultado de diversas consultas, cada uma associada com um tipo diferente de
informação procurada:
Eventos Associados às Disciplinas em que o Aluno está Matriculado:
SELECT DATA_ATIVIDADE,””, TIPO, ATIVIDADE_NM,
DISCIPLINA_ID
FROM
CURSOU, TURMA, ATIVIDADE
WHERE CURSOU.ALUNO = RA AND
CURSOU.DISCIPLINA_ID = TURMA.DISCIPLINA_ID AND
CURSOU.TURMA_ID = TURMA.TURMA_ID AND
CURSOU.SEMESTRE = SEMESTRE_ATUAL AND
TURMA.SEMESTRE = SEMESTRE_ATUAL AND
ATIVIDADE.DISCIPLINA_ID = TURMA.DISCIPLINA_ID AND
ATIVIDADE.TURMA_ID = TURMA.TURMA_ID AND
ATIVIDADE.SEMESTRE = SEMESTRE_ATUAL AND
ATIVIDADE.DATA >= DATA_INICIO AND
ATIVIDADE.DATA <= DATA_FIM;
Eventos Gerais: DAC, CPG, Discente, Congressos:
SELECT DATA_INICIO, DATA_TERMINO, TIPO_EVENTO,
EVENTO_NM, ÁREA_PESQUISA_ID
FROM
EVENTOS
WHERE AREA_PESQUISA IN (ÁREAS DE INTERESSE) AND
ATIVIDADE_DATA >= DATA_INICIO AND
ATIVIDADE_DATA <= DATA_FIM;
Calendário de Defesas de Teses:
SELECT DATA_DEFESA, “”, “DEFESA”, TITULO,
ÁREA_PESQUISA_ID
FROM
TESE, TESE_AREA_PESQUISA
WHERE AREA_PESQUISA IN (ÁREAS DE INTERESSE) AND
TESE.DATA_DEFESA >= DATA_INICIO AND
TESE.DATA_DEFESA <= DATA_FIM;
7
Estatísticas de Produção do Corpo Docente
Finalidade
Esta consulta tem por objetivo informar o aluno a respeito das atividades e desempenho dos docentes
e departamentos. Com isso deseja-se ajudá-lo na escolha de seu orientador e departamento.
Entrada
Como entrada pode ser especificado ou o nome do docente ou do departamento. Para a avaliação
global da Faculdade não há necessidade de entrada. Veja a seguir o modelo de navegação proposto.
Saída
A saída consiste de diversas tabelas relacionando os departamentos e docentes com os valores que
medem seu desempenho. A apresentação pode ser feita na forma de gráficos ou de tabelas. A
legenda do gráfico deve permitir navegação entre telas quando clicada pelo mouse.
O valor de importância de uma publicação é determinado pela própria faculdade e inserido na base
de dados.
A seguir apresentam-se as consultas de forma detalhada.
No ponto de vista da faculdade:
• número de publicações por departamento
• produção científica por departamento
• desempenho por docente em cada departamento
• número de publicações da faculdade em cada área de pesquisa
Desempenho por docente em
cada departamento
Número de publicações por
departamento
DCA
DCA
DCOM
DCOM
DENSIS
DENSIS
DEMIC
DEMIC
Publicações por área de pesquisa
Produção científica por
departamento
Eletrônica embarcada
Sistemas de Controle
DCA
DCOM
Teoria de Agentes
Comunicações Móveis
DENSIS
DEMIC
Sistemas Inteligentes
0
20
40
60
80
100
Figura 5 – Estatísticas de Produção da Faculdade.
• Número de publicações por departamento é efetivamente a contagem do número de
publicações em que tenha participado pelo menos um docente do departamento.
• Produção científica por departamento é a soma do valor de importância que é atribuído às
publicações.
• Desempenho por docente em cada departamento é o valor da produção científica dividido pelo
número de docentes do departamento.
8
• Número de publicações da faculdade em cada área de pesquisa corresponde à quantidade
de artigos publicados em cada área de pesquisa que a faculdade atua. Estes números podem
influenciar a escolha do projeto de tese do aluno.
No ponto de vista do departamento
• número de publicações por docente
• produção científica por docente
DCA - número de publicações por
docente
DCA - produçao cientifica por
docente
Bart
Bart
Homer
Homer
Lisa
Lisa
Margie
Margie
Maggie
Maggie
Figura 6 – Estatísticas de Produção do Departamento.
• Número de publicações por docente é efetivamente o número de artigos publicados por cada
um dos docentes.
• Produção científica por docente é a soma da importância dos artigos publicados.
No ponto de vista de um docente:
• número de publicações
• produção científica
• duração do curso de mestrado
• duração do curso de doutorado
Nome
Matrícula
Número de publicações
Produção científica
Duração – mestrado
Duração – doutorado
Bart Simpson
12384266324274
82
119
2,5 anos
4,5 anos
Tabela 2 – Informações sobre Docente.
Implementação das consultas
Tabelas Utilizadas
• MATRICULA
Tabela que relaciona aluno, orientador e curso.
• DOCENTE
Tabela que relaciona docente, dados pessoais e departamento.
• DEPARTAMENTO
Tabela que relaciona departamento com seu nome e seus dados gerais.
• DOCENTE_AREA_PESQUISA
Tabela que associa áreas de pesquisa a docentes.
• PUBLICACAO
Tabela contendo lista de publicações e avaliação de importância das publicações.
• DOCENTE_PUBLICACAO
Tabela que relaciona publicações com autores que são docentes.
• AREA_PESQUISA
Lista de áreas de pesquisa.
9
Consulta
Exemplo da consulta de número de publicações por departamento:
SELECT
FROM
WHERE
DEPARTAMENTO_NM, Count([PUBLICACAO_ID]) AS NUMERO_PUBLIC
DOCENTE, DEPARTAMENTO, DOCENTE_PUBLICACAO
DOCENTE.DEPARTAMENTO_ID=DEPARTAMENTO.DEPARTAMENTO_ID
AND DOCENTE_PUBLICACAO.DOCENTE_ID=DOCENTE.DOCENTE_ID
GROUP BY DEPARTAMENTO_ID
Exemplo da consulta de número de publicações por docente:
SELECT
FROM
WHERE
GROUP BY
DOCENTE_NM, Count([PUBLICACAO_ID]) AS NUMERO_PUBLIC
DOCENTE, DOCENTE_PUBLICACAO
DOCENTE.DEPARTAMENTO_ID=input.DEPARTAMENTO_ID
DOCENTE_ID
Estudo Estatístico do Desempenho de um Aluno baseado no Histórico de
Notas
Finalidade
Determinar a distribuição de probabilidades da nota de um aluno em uma disciplina baseado nas
notas desse aluno em outras disciplinas e nas notas dos outros alunos em todas as disciplinas da
consulta.
Determinar correlação entre disciplinas, baseado no histórico de notas, com o objetivo de recomendar
que uma disciplina seja cursada anteriormente a outra.
Entrada
No primeiro caso, a entrada é o RA do aluno e a disciplina a ser avaliada. O sistema deve conter uma
representação da árvore de dependências entre disciplinas (a correlação entre notas das disciplinas
não pode desempenhar esta função).
No segundo caso, não há entrada, pois todo par de disciplina será avaliado.
Saída
No primeiro caso, a saída é uma tabela relacionando a nota com sua probabilidade de ocorrer,
quando for possível de se calcular, isto é, houver amostras suficientes.
No segundo caso, a saída é uma tabela de pares de disciplinas, ordenadas pelo valor da correlação
entre elas.
Implementação da Consulta
Primeiro caso
Exemplo: Achar a distribuição de probabilidades da nota de Física II de um determinado aluno,
sabendo-se suas notas de Cálculo I, Física I e Geometria Analítica. Para isso, deve-se consultar as
notas de outros alunos que fizeram essas disciplinas e aplicar a Regra de Bayes.
p( a | b, c, d ) =
p (b | a ) p ( c | a ) p ( d | a ) p ( a )
∑a ' p(b | a' ) p(c | a' ) p(d | a ' ) p(a' )
Por exemplo, supondo-se que as notas de um aluno sejam b=A, c=B e d=A, queremos a
probabilidade de a=A. Para isso, calculam-se
10
alunos com a = A ∧ b = A
alunos com a = A
alunos com a = A ∧ c = B
p( c | a ) = p( c = B | a = A) =
alunos com a = A
alunos com a = A ∧ d = A
p( d | a ) = p ( d = A | a = A) =
alunos com a = A
alunos com a = A
p( a ) =
alunos que cursaram a
p(b | a ) = p (b = A | a = A) =
e o somátório
∑
a ' ={ A, B ,C , D , E }
p ( b | a ' ) p ( c | a ' ) p( d | a ' ) p ( a ' ) .
No banco de dados, estes cálculos consistem de intensivas operações de seleção e agregação.
Segundo caso
Busca-se a correlação entre as notas de duas disciplinas x e y
r=
σ xy
σxσ y
onde
σ xy = ∑∑ ( x − µ x )( y − µ y )
y
σ
2
x
x
= ∑∑ ( x − µ x ) 2
y
x
Tabelas Utilizadas
• CURSOU, TURMA e DISCIPLINA
Estas tabelas relacionam a turma de cada semestre, a disciplina, o docente e a nota de cada aluno.
Para a realização dos cálculos acima para duas determinadas disciplinas x e y são necessários os
pares de notas de todos os alunos que as cursaram (tanto a x quanto a y). Considerando que na base
de dados existem somente os dados relativos a pós-graduação da FEEC (CURSO_ID = mestrado ou
doutorado em Eng. Elétrica) e que uma mesma disciplina não é cursada novamente no doutorado
caso já tenha o sido no mestrado, bem como a identificação de uma disciplina sendo realizada
somente pelo seu código e não pela turma, a consulta a seguir obtém todos estes pares de notas
para todas as disciplinas:
SELECT CURSOU_X.DISCIPLINA_ID, CURSOU_Y.DISCIPLINA_ID,
CURSOU_X.NOTA, CURSOU_Y.NOTA
FROM CURSOU AS CURSOU_Y, CURSOU AS CURSOU_X
WHERE CURSOU_X.ALUNO_ID=CURSOU_Y.ALUNO_ID AND
CURSOU_X.DISCIPLINA_ID < CURSOU_Y.DISCIPLINA_ID;
A restrição na cláusula WHERE CURSOU_X.DISCIPLINA_ID < CURSOU_Y.DISCIPLINA_ID é
utilizada a fim de selecionar somente as tuplas onde as disciplinas são diferentes (evitando-se os
pares formados pela disciplina com ela própria devido ao produto cartesiano realizado), bem como
eliminar a possibilidade de ter-se pares de disciplinas para um mesmo aluno do tipo (x,y) e (y,x).
11
Exemplo:
Dados da tabela CURSOU
ALUNO_ID DISCIPLINA_ID
1
1
1
2
2
2
2
2
2
3
3
1
2
4
1
3
5
7
8
20
1
2
TURMA_ID
1
3
2
4
4
1
1
1
1
1
3
SEMESTRE
1/1998
1/1997
1/2000
1/1999
2/1999
1/2000
2/1997
2/1998
1/1998
1/1998
1/1997
NOTA
10
6
8
4
5
7
9
6
7
8
5
CURSO
Mestrado Eng. Elétrica
Mestrado Eng. Elétrica
Doutorado Eng. Elétrica
Mestrado Eng. Elétrica
Doutorado Eng. Elétrica
Doutorado Eng. Elétrica
Mestrado Eng. Elétrica
Mestrado Eng. Elétrica
Mestrado Eng. Elétrica
Mestrado Eng. Elétrica
Mestrado Eng. Elétrica
Resultado:
CURSOU_X.DISCIPLINA_ID
CURSOU_Y.DISCIPLINA_ID
CURSOU_X.NOTA
CURSOU_Y.NOTA
1
1
1
1
1
1
1
1
2
3
3
3
3
5
5
5
7
7
8
2
2
3
4
5
7
8
20
4
5
7
8
20
7
8
20
8
20
20
10
8
4
10
4
4
4
4
6
5
5
5
5
7
7
7
9
9
6
6
5
5
8
7
9
6
7
8
7
9
6
7
9
6
7
6
7
7
Após este join na tabela CURSOU com relação ao atributo ALUNO_ID, são efetuados os cálculos
anteriormente descritos.
Considerações relacionadas à exploração do paralelismo
Analisando-se o processamento realizado e o volume de dados das consultas exemplo: pesquisa
bibliográfica, calendário de eventos e estatísticas de produção do corpo docente concluiu-se que
devido ao processamento realizado pela consulta ser relativamente direto, bem como o volume de
dados ser também pequeno, e considerando uma arquitetura Shared Nothing (SN) a exploração do
paralelismo não seria justificável, já que potencialmente o tempo de comunicação entre os nós iria
sobressair sobre o tempo de processamento.
12
Entretanto, as tabelas EVENTOS, DOCENTE_PUBLICACAO e PUBLICACAO (relacionadas as três
primeiras consultas especificadas) têm maior potencial de crescimento, sendo portanto recomendável
a utilização de índices nos campos utilizados nas consultas. Exemplificando, a consulta calendário de
eventos estará trabalhando em uma faixa de datas, sendo portanto de grande valia um índice nos
campos relacionados a fim de atingir uma maior eficiência na operação de seleção.
A consulta sobre correlação entre pares de disciplinas demanda a realização de um join para obter-se
os pares de disciplinas cursadas por cada aluno, sendo o resultado desta operação utilizado para o
cálculo da correlação entre cada par de disciplinas. Esta operação de join pode tirar proveito do
paralelismo (paralelismo intraoperator), sendo uma possibilidade utilizar o algoritmo parallel hash join,
onde poder-se-ia utilizar na fase de distribuição (primeira fase) uma função de hash que distribua de
uma maneira razoável os dados para os nós de processamento (analisando-se por exemplo, as faixas
utilizadas de identificadores de alunos e a relação deste com ano de ingresso – vale ressaltar que
mesmo utilizando-se uma função de hash mais adequada não resolve-se o problema do data skew),
sendo que esta distribuição é realizada por aluno, ou seja, os dados de determinado aluno estarão
certamente no mesmo nó. Já na segunda fase (em cada nó de processamento) utiliza-se uma
segunda função de hash e as tuplas das relações (no caso CURSOU como duas relações) que forem
designadas ao mesmo bucket serão testadas a fim de verificar o “casamento”, e em caso positivo
ainda testar-se a condição de seleção relacionada à disciplina. Ao final desta etapa ter-se-ão os pares
de disciplinas cursados por cada aluno, juntamente com as respectivas notas.
Estes dados estarão “espalhados” nos nós de processamento e para a realização do cálculo da
correlação (que é feito utilizando os dados de todos os alunos que cursaram determinado par de
disciplinas, ou seja, a distribuição do dados é por disciplina, e não por aluno como no join realizado),
pode-se tanto concentrá-los em algum nó e realizar todo o processamento, quanto realizar este
também de forma paralela (correndo-se o risco, pois trata-se de um processamento menos intenso,
de gastar muito tempo de comunicação o que inviabilizaria o paralelismo nesta fase em uma
arquitetura shared nothing). Uma opção para tentar utilizar paralelismo nesta etapa seria cada nó
(que participou do join e possui tuplas de resultado) enviar aos nós que ficarem responsáveis pelo
cálculo de determinados pares de disciplinas os dados referentes a estas (note-se o custo de
comunicação e de seleção de quais tuplas enviar a quais nós, já que o resultado não está ordenado).
Existem várias alternativas para distribuição dos pares de disciplinas entre os nós como sugere o
exemplo abaixo:
Considerando n=9, ou seja, a existência de 9 disciplinas, denominadas dsc1, dsc2, ..., dsc9. O cálculo
de correlação entre as disciplinas será efetuado nos seguintes pares de disciplinas:
(dsc1,dsc2)
(dsc2,dsc3)
(dsc3,dsc4)
(dsc4,dsc5)
(dsc5,dsc6)
(dsc6,dsc7)
(dsc7,dsc8)
(dsc8,dsc9)
(dsc1,dsc3)
(dsc2,dsc4)
(dsc3,dsc5)
(dsc4,dsc6)
(dsc5,dsc7)
(dsc6,dsc8)
(dsc7,dsc9)
(dsc1,dsc4)
(dsc2,dsc5)
(dsc3,dsc6)
(dsc4,dsc7)
(dsc5,dsc8)
(dsc6,dsc9)
(dsc1,dsc5)
(dsc2,dsc6)
(dsc3,dsc7)
(dsc4,dsc8)
(dsc5,dsc9)
(dsc1,dsc6)
(dsc2,dsc7)
(dsc3,dsc8)
(dsc4,dsc9)
(dsc1,dsc7)
(dsc2,dsc8)
(dsc3,dsc9)
(dsc1,dsc8)
(dsc2,dsc9)
(dsc1,dsc9)
Portanto, se fosse utilizado um nó de processamento para esta etapa do cálculo de correlação
referente a cada disciplina (um nó para cada linha da tabela acima), além do data skew que pode
haver no cálculo para cada par de disciplinas (número de tuplas), fica evidente no exemplo que terse-ia potencialmente um desbalanceamento de carga, além de uma provável má distribuição dos
dados, como sugere a tabela abaixo:
Distribuição dos dados
Disciplina
1
Disciplina
2
Disciplina
3
Disciplina
4
Disciplina
5
Disciplina
6
Disciplina
7
Disciplina
8
Disciplina
9
Nó 1
Nó 2
Nó 3
Nó 4
Nó 5
Nó 6
Nó 7
Nó 8
13
Outra possibilidade, utilizando a metade do número de nós seria:
Nó 1
Nó 2
Nó 3
Nó 4
(dsc1,dsc2)
(dsc1,dsc3)
(dsc1,dsc4)
(dsc1,dsc5)
(dsc1,dsc6)
(dsc1,dsc7)
(dsc1,dsc8)
(dsc1,dsc9)
(dsc8,dsc9)
(dsc2,dsc3)
(dsc2,dsc4)
(dsc2,dsc5)
(dsc2,dsc6)
(dsc2,dsc7)
(dsc2,dsc8)
(dsc2,dsc9)
(dsc7,dsc8)
(dsc7,dsc9)
(dsc3,dsc4)
(dsc3,dsc5)
(dsc3,dsc6)
(dsc3,dsc7)
(dsc3,dsc8)
(dsc3,dsc9)
(dsc6,dsc7)
(dsc6,dsc8)
(dsc6,dsc9)
(dsc4,dsc5)
(dsc4,dsc6)
(dsc4,dsc7)
(dsc4,dsc8)
(dsc4,dsc9)
(dsc5,dsc6)
(dsc5,dsc7)
(dsc5,dsc8)
(dsc5,dsc9)
Note-se que o tempo de resposta não foi melhorado (na verdade, piorou em “uma disciplina”),
entretanto utilizou-se a metade do número de nós, evitando-se comunicação (e a distribuição dos
dados) com mais nós. Os dados necessários em cada nó são mostrados na tabela abaixo:
Distribuição dos dados
Disciplina
1
Disciplina
2
Disciplina
3
Disciplina
4
Disciplina
5
Disciplina
6
Disciplina
7
Disciplina
8
Disciplina
9
Nó 1
Nó 2
Nó 3
Nó 4
Uma forma de melhorar o tempo de resposta e a distribuição dos dados seria utilizando 8 nós e
distribuindo o processamento desta fase da seguinte forma, ou seja, aproveitando a “idéia” acima em
um número maior de nós:
Nó 1
Nó 2
Nó 3
Nó 4
Nó 5
Nó 6
Nó 7
Nó 8
(dsc1,dsc2)
(dsc1,dsc3)
(dsc1,dsc4)
(dsc1,dsc5)
(dsc2,dsc3)
(dsc2,dsc4)
(dsc2,dsc5)
(dsc2,dsc6)
(dsc3,dsc4)
(dsc3,dsc5)
(dsc3,dsc6)
(dsc3,dsc7)
(dsc4,dsc5)
(dsc4,dsc6)
(dsc4,dsc7)
(dsc4,dsc8)
(dsc1,dsc6)
(dsc1,dsc7)
(dsc1,dsc8)
(dsc1,dsc9)
(dsc8,dsc9)
(dsc2,dsc7)
(dsc2,dsc8)
(dsc2,dsc9)
(dsc7,dsc8)
(dsc7,dsc9)
(dsc3,dsc8)
(dsc3,dsc9)
(dsc6,dsc7)
(dsc6,dsc8)
(dsc6,dsc9)
(dsc4,dsc9)
(dsc5,dsc6)
(dsc5,dsc7)
(dsc5,dsc8)
(dsc5,dsc9)
Distribuição dos dados
Disciplina
1
Disciplina
2
Disciplina
3
Disciplina
4
Disciplina
5
Disciplina
6
Disciplina
7
Disciplina
8
Disciplina
9
Nó 1
Nó 2
Nó 3
Nó 4
Nó 5
Nó 6
Nó 7
Nó 8
Observa-se, neste caso que além da potencial diminuição do tempo de resposta, também ocorre uma
potencial melhor distribuição dos dados entre os nós nesta fase, sendo que 6 destes necessitam de
dados de 5 disciplinas, um nó de 4 disciplinas e um nó de 6 disciplinas. Vale ressaltar que não há
problema de consistência nos dados replicados em mais de um nó, já que estes são somente de
leitura.
Conclusão
Conforme apresentado no trabalho, várias questões sobre bancos de dados e processamento de
informação podem ser identificadas em situações corriqueiras como no dia a dia de um aluno da
Faculdade. Um sistema com objetivo de atender as necessidades desse tipo de usuário deve ser
capaz de processar consultas complexas, que envolvem além das operações básicas de seleção,
projeção e junção, operações de agregação, consultas on line em servidores na WWW e extração de
informações de sistemas legados. Um sistema desse tipo pode vir a crescer em quantidade de dados
e/ou complexidade de consultas de maneira que surja a necessidade de utilizar paralelismo. Este
trabalho, através de seus exemplos, tenta abranger algumas destas questões.
14
Bibliografia
McGrath Sean, XML: Aplicações Práticas, Editora Campus, 1999.
Marchal Benoît , XML by Example, QUE, 2000.
Judea Pearl, Probabilistic Reasoning in Intelligent Systems, Morgan Kaufmann Publishers,1997.
15
ANEXO I
Definição de estruturas de documento XML
Documento de saída da consulta Pesquisa Bibliográfica
Estrutura do documento (DTD):
<!ELEMENT pesquisa-bibliografica (pesquisa-disciplina*)>
<!ELEMENT pesquisa-disciplina (disciplina, pesquisa-livro*)>
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
disciplina (disciplina-id, turma-id, disciplina-nome)>
disciplina-id (#PCDATA)>
turma-id (#PCDATA)>
disciplina-nome (#PCDATA)>
<!ELEMENT pesquisa-livro (livro, pesquisa-biblioteca, pesquisa-livraria)>
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
livro (isbn, autor, titulo, editora, edicao)>
isbn (#PCDATA)>
autor (#PCDATA)>
titulo (#PCDATA)>
editora (#PCDATA)>
edicao (#PCDATA)>
<!ELEMENT pesquisa-biblioteca (numero-exemplares-consulta,
numero-exemplares-emprestimo)>
<!ELEMENT numero-exemplares-consulta (#PCDATA)>
<!ELEMENT numero-exemplares-emprestimo (#PCDATA)>
<!ELEMENT pesquisa-livraria (pesquisa-preco*, pesquisa-review*)>
<!ELEMENT pesquisa-preco (livraria, preco, url-livro)>
<!ELEMENT pesquisa-review (livraria, review*)>
<!ELEMENT livraria (#PCDATA)>
<!ELEMENT preco (#PCDATA)>
<!ELEMENT url-livro (#PCDATA)>
<!ELEMENT review (#PCDATA)>
Exemplo de documento XML válido :
<?xml version="1.0"?>
<!DOCTYPE pesquisa-bibliografica SYSTEM "pesquisabibliografica.dtd">
<pesquisa-bibliografica>
<pesquisa-disciplina>
<disciplina>
<disciplina-id> IA541 </disciplina-id>
<turma-id> H </turma-id>
<disciplina-nome> Especificação de Sistemas Embutidos </disciplina-nome>
</disciplina>
16
<pesquisa-livro>
<livro>
<isbn> 467893009873 </isbn>
<autor> Daniel Gajski </autor>
<titulo> Design of Embedded Systems </titulo>
<editora> Prentice Hall </editora>
<edicao> 1 </edicao>
</livro>
<pesquisa-biblioteca>
<numero-exemplares-consulta> 3 </numero-exemplares-consulta>
<numero-exemplares-emprestimo> 2 </numero-exemplares-emprestimo>
</pesquisa-biblioteca>
<pesquisa-livraria>
<pesquisa-preco>
<livraria> Livraria Cultura </livraria>
<preco> R$ 80,00 </preco>
<url-livro> www.livcultura.com/~embedded </url-livro>
</pesquisa-preco>
<pesquisa-preco>
<livraria> Amazon </livraria>
<preco> US$ 53,00 </preco>
<url-livro> www.amazon.com/~gajski </url-livro>
</pesquisa-preco>
<pesquisa-preco>
<livraria> Bookpool </livraria>
<preco> US$ 45,00 </preco>
<url-livro> www.bookpool.com/~hardware </url-livro>
</pesquisa-preco>
<pesquisa-review>
<livraria> Bookpool </livraria>
<review> O livro </review>
<review> Encontrei </review>
<review> Recomendo a todos </review>
</pesquisa-review>
<pesquisa-review>
<livraria> Amazon </livraria>
<review> Gajski </review>
<review> Otima referencia </review>
<review> Nao recomendo a </review>
</pesquisa-review>
</pesquisa-livraria>
</pesquisa-livro>
<pesquisa-livro>
<livro>
<isbn> 46733333873 </isbn>
<autor> Daniel Gajski </autor>
<titulo> Principles of Digital Design </titulo>
<editora> Prentice Hall </editora>
<edicao> 2 </edicao>
</livro>
17
<pesquisa-biblioteca>
<numero-exemplares-consulta> 5 </numero-exemplares-consulta>
<numero-exemplares-emprestimo> 2 </numero-exemplares-emprestimo>
</pesquisa-biblioteca>
<pesquisa-livraria>
<pesquisa-preco>
<livraria> Livraria Cultura </livraria>
<preco> R$ 70,00 </preco>
<url-livro> www.livcultura.com/~dd </url-livro>
</pesquisa-preco>
<pesquisa-preco>
<livraria> Amazon </livraria>
<preco> US$ 33,00 </preco>
<url-livro> www.amazon.com/~dd </url-livro>
</pesquisa-preco>
<pesquisa-preco>
<livraria> Bookpool </livraria>
<preco> US$ 35,00 </preco>
<url-livro> www.bookpool.com/~digital </url-livro>
</pesquisa-preco>
<pesquisa-review>
<livraria> Bookpool </livraria>
<review> O livro </review>
<review> Nao recomendo a todos </review>
</pesquisa-review>
<pesquisa-review>
<livraria> Cultura </livraria>
<review> Bom livro </review>
<review> Otima referencia </review>
</pesquisa-review>
</pesquisa-livraria>
</pesquisa-livro>
</pesquisa-disciplina>
<pesquisa-disciplina>
<disciplina>
<disciplina-id> IA876 </disciplina-id>
<turma-id> H </turma-id>
<disciplina-nome> Arquiteturas Paralelas </disciplina-nome>
</disciplina>
<pesquisa-livro>
<livro>
<isbn> 10000003 </isbn>
<autor> Kai Hwang </autor>
<titulo> Advanced Computer Architecture </titulo>
<editora> McGrawHill </editora>
<edicao> 1 </edicao>
</livro>
<pesquisa-biblioteca>
<numero-exemplares-consulta> 3 </numero-exemplares-consulta>
18
<numero-exemplares-emprestimo> 2 </numero-exemplares-emprestimo>
</pesquisa-biblioteca>
<pesquisa-livraria>
<pesquisa-preco>
<livraria> Livraria Cultura </livraria>
<preco> R$ 50,00 </preco>
<url-livro> www.livcultura.com/~ps </url-livro>
</pesquisa-preco>
<pesquisa-preco>
<livraria> Amazon </livraria>
<preco> US$ 103,00 </preco>
<url-livro> www.amazon.com/~hwang </url-livro>
</pesquisa-preco>
<pesquisa-preco>
<livraria> Bookpool </livraria>
<preco> US$ 85,00 </preco>
<url-livro> www.bookpool.com/~hardware </url-livro>
</pesquisa-preco>
<pesquisa-review>
<livraria> Bookpool </livraria>
<review> Best-seller </review>
<review> Muito bom </review>
<review> Livro excelente </review>
</pesquisa-review>
<pesquisa-review>
<livraria> Amazon </livraria>
<review> Hwang e </review>
<review> Otima referencia </review>
<review> Recomendo a todos </review>
</pesquisa-review>
</pesquisa-livraria>
</pesquisa-livro>
</pesquisa-disciplina>
</pesquisa-bibliografica>
Documento de saída da consulta Calendário de Eventos
Estrutura do documento (DTD):
O resultado da consulta deve ser um lista ordenada de acordo com as datas dos eventos.
Deve-se especificar a estrutura de cada elemento da lista e também a estrutura da lista de saída.
tipo evento:
<!ATTLIST EVENTO
data_inicio CDATA
data_fim
CDATA
tipo
CDATA
descrição
CDATA
categoria
CDATA
>
#REQUIRED;
#IMPLIED;
#REQUIRED;
#REQUIRED;
#REQUIRED
tipo lista_evento:
<!ELEMENT
CALENDARIO
(EVENTO)* >
19
Documento de saída da consulta Estatísticas de Produção do Corpo Docente
Estrutura do documento (DTD):
<!—- numero publicacoes por departamento -->
<! ATTLIST numero_public_depto
DEPARTAMENTO_NM CDATA #REQUIRED;
NUMERO_PUBLIC CDATA #IMPLIED
>
<!ELEMENT tab_num_public_depto (numero_public_depto)*>
<!—- producao cientifica por departamento -->
<!ATTLIST producao_cientifica_depto
DEPARTAMENTO_NM CDATA #REQUIRED;
PRODUCAO_CIENTIFICA CDATA #IMPLIED
>
<!ELEMENT tab_producao_cientifica_depto (producao_cientifica_depto)*>
<!—- desempenho por docente por departamento -->
<!ATTLIST desempenho_por_docente_depto
DEPARTAMENTO_NM CDATA #REQUIRED;
DESEMPENHO CDATA #IMPLIED
>
<!ELEMENT tab_desempenho_por_docente_depto (desempenho_por_docente_depto)*>
<!-— numero de publicacoes por area de pesquisa -->
<! ATTLIST numero_public_area
AREA_PESQUISA_NM CDATA #REQUIRED;
NUMERO_PUBLIC CDATA #IMPLIED
>
<!ELEMENT tab_numero_public_area (numero_public_area)*>
<!-- numero de publicacoes por docente -->
<! ATTLIST numero_public_docente
DOCENTE_NM CDATA #REQUIRED;
NUMERO_PUBLIC CDATA #IMPLIED
>
<!ELEMENT tab_num_public_docente (numero_public_docente)*>
<!—- producao cientifica por docente -->
<! ATTLIST producao_cientifica_docente
DOCENTE_NM CDATA #REQUIRED;
PRODUCAO_CIENTIFICA CDATA #IMPLIED
>
<!ELEMENT tab_producao_cientifica_docente (producao_cientifica_docente)*>
<!-- dados do docente -->
<!ATTLIST dados_docente
DOCENTE_NM CDATA #REQUIRED;
PRODUCAO_CIENTIFICA CDATA #IMPLIED;
DURACAO_MESTRADO CDATA #IMPLIED;
DURACAO_DOUTORADO CDATA #IMPLIED
>
Exemplo de Saida em XML
<tab_num_public_docente>
<num_public_docente DOCENTE_NM=¨Bart¨ NUMERO_PUBLIC=¨82¨/>
<num_public_docente DOCENTE_NM=¨Lisa¨ NUMERO_PUBLIC=¨234¨/>
</tab_num_public_docente>
20