Como o design de banco de dados ajuda a organizar professores, aulas e alunos?

Um investimento em conhecimento rende os melhores juros.

Benjamin Franklin

No mundo moderno, a educação é onipresente. Agora, mais do que nunca, desempenha um papel importante em nossa sociedade. É tão importante, de fato, que muitos de nós continuemos nossa educação bem depois de terminar a escola ou a faculdade.

Todos nós já ouvimos falar de aprendizagem ao longo da vida, educação não formal e workshops para todas as idades. Esses métodos diferem da educação formal em muitos aspectos, mas também têm coisas em comum. Há classes, lições, professores e alunos. E, assim como em um ambiente tradicional, queremos acompanhar a programação da aula, os dados de frequência e o desempenho do instrutor ou do aluno. Como podemos projetar um banco de dados para atender a essas necessidades? É o que abordaremos neste artigo.

Apresentando nosso modelo de banco de dados educacional

O modelo apresentado neste artigo nos permite armazenar dados sobre:

aulas/palestras
instrutores/palestrantes
alunos
presença na palestra
realização dos alunos/professores

Poderíamos também utilizar este modelo como horário escolar, para outras atividades em grupo (aulas de natação, oficinas de dança) ou mesmo para atividades individuais como tutoria. Ainda há muito espaço para melhorias, como armazenamento de dados de localização de aulas ou duração do workshop; abordaremos isso nos próximos artigos.

Vamos começar com nossos elementos básicos de banco de dados de Educação:as tabelas.

Os Três Grandes:Tabelas de Alunos, Instrutores e Turmas

O student , instructor e class tabelas compõem o núcleo do nosso banco de dados.

O student A tabela, mostrada acima, é usada para armazenar dados básicos sobre os alunos, mas pode ser expandida de acordo com necessidades específicas. Com exceção dos três atributos de contato, todos os atributos da tabela são obrigatórios:

first_name – o nome do aluno
last_name – o sobrenome do aluno
birth_date – data de nascimento do aluno
contact_phone – o número de telefone do aluno
contact_mobile – o número do celular do aluno
contact_mail – o endereço de e-mail do aluno
category_id – é uma referência à category Catálogo. Com essa estrutura, estamos limitados a apenas uma categoria por aluno. Isso funciona na maioria dos casos, mas em algumas situações podemos precisar de espaço para listar várias categorias. Como você pode ver, adicionar uma relação muitos-para-muitos que conecta o student tabela com a category dicionário resolve este problema. Nesse cenário, porém, precisaremos escrever consultas um pouco mais complexas para lidar com nossos dados.

Já que mencionamos isso, vamos em frente e discutir a category mesa aqui.

Esta tabela é um dicionário usado para agrupar os alunos com base em determinados critérios. O name o atributo é o único dado na tabela (além de id , a chave primária) e é obrigatório. Um conjunto de valores que podem ser armazenados aqui é o status de emprego do aluno:“estudante”, “empregado”, “desempregado” e “aposentado”. Também poderíamos usar outros conjuntos com base em alguns critérios altamente específicos, como “gosta de ioga”, “gosta de caminhada”, “gosta de andar de bicicleta” e “não gosta de nada”.

O instructor A tabela contém a lista de todos os instrutores/palestrantes da organização. Os atributos na tabela são:

first_name – o nome do instrutor
last_name – o sobrenome do instrutor
title – o título do instrutor (se houver)
birth_date – data de nascimento do instrutor
contact_phone – o número de telefone do instrutor
contact_mobile – o número do celular do instrutor
contact_mail – o endereço de e-mail do instrutor

O title e todos os três contact atributos não são obrigatórios.

O student tabela e instructor table compartilham uma estrutura semelhante, mas há outra possibilidade de organizar essas informações. Uma segunda abordagem seria ter uma person tabela (que armazena todos os dados de funcionários e alunos) e tem uma relação muitos-para-muitos que nos informa todas as funções atribuídas a essa pessoa. A vantagem mais importante da segunda abordagem é que armazenaremos dados apenas uma vez. Se alguém for instrutor em uma turma e aluno em outra, aparecerá apenas uma vez no banco de dados, mas com as duas funções definidas.

Por que selecionamos a abordagem de duas tabelas para nosso modelo de banco de dados educacional? Geralmente, alunos e instrutores se comportam de maneira diferente, tanto na vida real quanto em nosso banco de dados. Por isso, pode ser prudente armazenar seus dados separadamente. Podemos encontrar outras maneiras de mesclar as informações da mesma pessoa que aparecem em ambas as tabelas (por exemplo, par de consultas de inserção/atualização com base em um ID externo, como um número de seguro social ou número de IVA).

A class table é um catálogo que contém detalhes sobre todas as classes. Podemos ter várias instâncias de cada tipo de classe. Os atributos na tabela são os seguintes (todos são obrigatórios exceto end_date ):

class_type_id – é uma referência ao class_type dicionário.
name – é um nome curto da classe.
description – esta descrição é mais específica do que a do class_type tabela.
start_date – a data de início da aula.
end_date – a data de término da aula. Não é obrigatório porque nem sempre sabemos com antecedência a data exata de término de cada aula.
completed – é um valor booleano que denota se todas as atividades de classe planejadas foram concluídas. Isso é útil quando atingimos o end_time planejado para uma aula, mas outras atividades ainda não foram concluídas.

O class_type table é um catálogo simples, destinado a armazenar informações básicas sobre as palestras ou aulas oferecidas aos alunos. Pode conter valores como “idioma inglês (grupo)”, “idioma polonês (grupo)”, “idioma croata (grupo)”, “idioma inglês (presencial)” ou “aulas de dança”. Tem apenas dois atributos obrigatórios – name e description , ambos dispensando maiores explicações.

O class_schedule tabela contém horários específicos para palestras e aulas. Todos os atributos na tabela são obrigatórios. O class_id atributo é uma referência à class tabela, enquanto start_time e end_time são os horários de início e término dessa palestra específica.

Quem está aqui? Tabelas Relacionadas à Presença

Os attend A tabela armazena informações sobre qual aluno frequentou qual aula e o resultado final. Os atributos na tabela são:

student_id – é uma referência ao student tabela
class_id – é uma referência à class tabela
class_enrollment_date – é a data em que o aluno começou a frequentar essa aula
class_drop_date – a data em que o aluno abandonou a aula. Este atributo só terá valor se o aluno abandonar a aula antes da data de término da aula. Nesse caso, o drop_class_reason_id o valor do atributo também deve ser definido.
drop_class_reason_id – é uma referência ao drop_class_reason tabela
attendance_outcome_id – é uma referência ao attendance_outcome tabela

Todos os dados, exceto class_drop_date e drop_class_reason_id É necessário. Estes dois serão preenchidos se e somente se um aluno desistir da aula.

O drop_attendance_reason table é um dicionário que contém as várias razões pelas quais um aluno pode desistir de um curso. Tem apenas um atributo, reason_text , e é obrigatório. Um exemplo de conjunto de valores pode incluir:“doença”, “interesse perdido”, “não tem tempo suficiente” e “outros motivos”.

O attendance_outcome tabela contém descrições sobre a atividade do aluno em um determinado curso. O outcome_text é o único atributo na tabela e é obrigatório. Um conjunto de valores possíveis é:“em andamento”, “concluído com sucesso”, “concluído parcialmente” e “não concluiu a aula”.

Quem está no comando? Tabelas relacionadas ao ensino

O teach , drop_teach_reason e teach_outcome as tabelas usam a mesma lógica que o attend , drop_attendance_reason e attendance_outcome mesas. Todas essas tabelas armazenam dados sobre as atividades relacionadas ao curso dos instrutores.

O teach A tabela é usada para armazenar informações sobre qual instrutor está ensinando qual classe. Os atributos na tabela são:

instructor_id – é uma referência ao instructor tabela.
class_id – é uma referência à class tabela.
start_date – é a data em que o instrutor começou a trabalhar nessa aula.
end_date – é a data em que o instrutor parou de trabalhar naquela aula. Não é obrigatório porque não podemos saber com antecedência se o instrutor vai ensinar até a data de término da aula.
drop_teach_reason_id – é uma referência ao drop_teach_reason tabela. Não é obrigatório porque o instrutor não pode desistir da aula.
teach_outcome_id – é uma referência ao teach_outcome_reason tabela.

O drop_teach_reason table é um dicionário simples. Ele contém um conjunto de explicações possíveis por que o instrutor terminou de dar aula antes da data de término. Existe apenas um atributo obrigatório:reason_text . Isso pode ser “doença”, “mudança para outro projeto/trabalho”, “desistir” ou “outro motivo”.

O teach_outcome tabela descreve o sucesso do instrutor em um curso específico. O outcome_text é o único atributo da tabela e é obrigatório. Os valores possíveis para esta tabela podem ser:“em andamento”, “concluído com sucesso”, “concluído parcialmente” e “não concluiu a aula de ensino”.

A student_presence A tabela é usada para armazenar dados sobre a presença do aluno para uma aula específica. Podemos supor que para cada aula o instrutor notará a presença e/ou ausência de todos os alunos. Os atributos na tabela são:

student_id – é uma referência ao student tabela
class_schedule_id – é uma referência ao class_schedule tabela
present – é um booleano marcando se o aluno está presente na aula ou não

Poderíamos monitorar a presença dos alunos em uma turma específica com uma consulta como a que segue (supondo que @id_class contenha o ID da turma que queremos).

SELECT
	a.id, 
	CONCAT(a.first_name, ' ', a.last_name) AS student_name,
	a.number_total, 
	CONCAT(CONVERT(a.number_present / a.number_total * 100, DECIMAL(5,2)), '%') AS percentage,
	a.attendance_outcome
FROM
(
SELECT 
	student.id, 
	student.first_name, 
	student.last_name, 
	SUM(CASE WHEN student_presence.present = True THEN 1 ELSE 0 END) AS number_present,
	COUNT(DISTINCT class_schedule.id) AS number_total,
	attendance_outcome.outcome_text AS attendance_outcome
FROM class
	INNER JOIN attend ON class.id = attend.class_id
	INNER JOIN student ON attend.student_id = student.id
	LEFT JOIN class_schedule ON class_schedule.class_id = class.id
	LEFT JOIN student_presence ON student_presence.student_id = student.id AND student_presence.class_schedule_id = class_schedule.id
	LEFT JOIN attendance_outcome ON attendance_outcome.id = attend.attendance_outcome_id
WHERE class.id = @id_class
GROUP BY 
	student.id, 
	student.first_name, 
	student.last_name, 
	attendance_outcome.outcome_text
) a

A tabela “instructor_presence” usa a mesma lógica que a tabela “student_presence”, mas aqui queremos focar nos instrutores. Os atributos na tabela são:

instructor_id – é uma referência ao instructor tabela
class_schedule_id – é uma referência ao class_schedule tabela
present – é um valor booleano que representa se o instrutor está presente na aula ou não

Poderíamos usar a consulta abaixo para monitorar a atividade do instrutor em sala de aula:

SELECT
	a.id, 
	CONCAT(a.first_name, ' ', a.last_name) AS instructor_name,
	a.number_total,
	CONCAT(CONVERT(a.number_present / a.number_total * 100, DECIMAL(5,2)), '%') AS percentage,
	a.teach_outcome
FROM
(
SELECT 
	instructor.id, 
	instructor.first_name, 
	instructor.last_name, 
	SUM(CASE WHEN instructor_presence.present = True THEN 1 ELSE 0 END) AS number_present,
	COUNT(DISTINCT class_schedule.id) AS number_total,
	teach_outcome.outcome_text AS teach_outcome
FROM class
	INNER JOIN teach ON class.id = teach.class_id
	INNER JOIN instructor ON teach.instructor_id = instructor.id
	LEFT JOIN class_schedule ON class_schedule.class_id = class.id
	LEFT JOIN instructor_presence ON instructor_presence.instructor_id = instructor.id AND instructor_presence.class_schedule_id = class_schedule.id
	LEFT JOIN teach_outcome ON teach_outcome.id = teach.teach_outcome_id
WHERE class.id = @id_class
GROUP BY 
	instructor.id, 
	instructor.first_name, 
	instructor.last_name, 
	teach_outcome.outcome_text
) a

Agora, vamos terminar discutindo as tabelas de pessoas de contato.

Quem podemos chamar? Tabelas de pessoas de contato

Na maioria dos casos, não precisamos armazenar informações de contato de emergência (ou seja, em caso de emergência, entre em contato com essa pessoa). No entanto, isso muda quando estamos ensinando crianças. Por lei ou por costume, precisamos ter uma pessoa de contato para cada criança que estamos ensinando. Em nossas tabelas de modelos – contact_person , contact_person_type e contact_person_student – demonstramos como isso pode ser feito.

O contact_person tabela é uma lista de pessoas que estão relacionadas com os alunos. Claro, não precisamos listar todos os parentes; principalmente teremos um ou dois contatos por aluno. Esta é uma boa maneira de encontrar “para quem você vai ligar” quando o aluno precisa ou quer sair mais cedo. Os atributos na tabela são:

first_name – é o nome da pessoa de contato
last_name – é o sobrenome da pessoa
contact_phone – é o número de telefone da pessoa
contact_mobile – é o número do celular da pessoa
contact_mail – é o endereço de e-mail da pessoa

Os detalhes de contato não são obrigatórios, embora sejam muito úteis.

O contact_person_type table é um dicionário com um único atributo obrigatório:type_name . Exemplos de valores armazenados nesta tabela são:“mãe”, “pai”, “irmão”, “irmã” ou “tio”.

O contact_person_student table é uma relação muitos-para-muitos que conecta as pessoas de contato e seu tipo com os alunos. Os atributos na tabela são (todos são obrigatórios):

contact_person_id – é uma referência ao contact_person tabela
student_id – é uma referência ao student tabela
contact_person_type_id – é uma referência ao contact_person_type tabela

Pode valer a pena mencionar que essa relação muitos-para-muitos conecta três tabelas. O par de atributos contact_person_id e student_id é usado como chave alternativa (ÚNICA). Dessa forma, desativaremos as entradas duplicadas que conectam alunos individuais com a mesma pessoa de contato. O atributo contact_person_type_id não faz parte da chave alternativa. Se assim for, poderíamos ter várias relações para a mesma pessoa de contato e o mesmo aluno (usando diferentes tipos de relacionamento), e isso não faz sentido em situações da vida real.

O modelo apresentado neste artigo deve ser capaz de cobrir as necessidades mais comuns. Ainda assim, partes do modelo podem ser excluídas em alguns casos, por exemplo. provavelmente não precisaríamos de todo o segmento de pessoas de contato se nossos alunos fossem adultos. Como eu disse antes, estaremos adicionando melhorias a isso com o tempo. Sinta-se à vontade para adicionar sugestões e compartilhar sua experiência nas seções de discussão.