Gerenciando dados de uma universidade

Olá, Alexander! Como vai?

Parabéns por encarar esse "Mão na massa" e estruturar o esquema de tabelas para o banco de dados da universidade!

A modelagem de dados e a aplicação das formas normais (especialmente quando avançamos para as regras da Forma Normal de Boyce-Codd, 4ª e 5ª FN) exigem muita atenção para evitar problemas de redundância e anomalias de atualização.

Analisando a sua estrutura atual, você criou três tabelas bem definidas (TabelaProfessores, TabelaDepartamentos e TabelaCursos). No entanto, se formos aplicar as regras estritas de modelagem relacional para o cenário de uma universidade real, existem dois pontos críticos no seu design de chaves estrangeiras (FK) que podem gerar inconsistências de dados ou travar o funcionamento do sistema.

Vamos analisar onde estão esses gargalos e como ajustar o seu esquema.

Os Dois Problemas Estruturais da Modelagem Atual

1. O Loop de Dependência (Departamento vs. Professor)

Repare que na sua TabelaDepartamentos, você colocou a coluna id_chefedepartamento como uma chave estrangeira (FK). Essa FK certamente aponta para o id_professores da tabela de cima.

Até aí, tudo bem! O problema é que, na TabelaCursos, você vinculou o curso tanto a um departamento quanto a um professor de forma direta:

• id_professor(FK)
• id_departamento(FK)

O risco: Do jeito que está modelado, um curso pode ser cadastrado apontando para o Departamento de Matemática (id_departamento), mas o professor associado a esse mesmo curso (id_professor) pode ser do Departamento de História! Isso gera uma quebra na integridade dos dados, pois o banco de dados permite que um professor lecione um curso fora do departamento dele sem qualquer controle.

2. A Relação de Cardinalidade (Um professor pode lecionar mais de um curso?)

Ao colocar id_professor(FK) diretamente dentro da TabelaCursos, você está determinando que um curso pertence a apenas um professor. No mundo universitário, isso costuma ser verdade para disciplinas específicas, mas e se o curso for grande e tiver vários professores dividindo as turmas? Na modelagem atual, o banco de dados proibiria um segundo professor de fazer parte daquele curso.

Como Ajustar o Modelo para Respeitar as Formas Normais

Para limpar as redundâncias e garantir que as dependências funcionais sejam tratadas corretamente (o foco do capítulo sobre FNBC e 4ª FN), o ideal é criar uma estrutura em cascata lógica: O Professor pertence a um Departamento $\rightarrow$ O Curso pertence a um Departamento $\rightarrow$ Uma quarta tabela une os Professores aos seus respectivos Cursos.

Veja abaixo o esquema corrigido e otimizado:

1. TabelaDepartamentos

Guarda os dados do departamento e quem é o chefe atual.

• id_departamento (PK)
• NomeDepartamento
• id_chefedepartamento (FK apontando para Professores)

2. TabelaProfessores

Cada professor é alocado obrigatoriamente em um departamento da universidade.

• id_professor (PK)
• NomeProfessor
• id_departamento (FK apontando para Departamentos)

3. TabelaCursos

Os cursos da faculdade pertencem à grade de um departamento específico. Note que removemos a FK do professor daqui para limpar a redundância.

• id_curso (PK)
• NomeCurso
• id_departamento (FK apontando para Departamentos)

4. Tabela_Cursos_Professores (Tabela de Associação - Transforma em 4ª FN)

Para resolver o problema de um professor lecionar em vários cursos e um curso ter vários professores (relação de Muitos para Muitos), criamos uma tabela intermediária.

• id_curso (FK)
• id_professor (FK)
• A união dessas duas colunas pode formar uma Chave Primária Composta (PK).

Por que essa mudança é importante?

Ao adotar essa estrutura, você elimina qualquer chance de anomalia. Se você precisar saber de qual departamento é o curso de um professor, o banco de dados resolve isso fazendo um cruzamento de tabelas (JOIN), em vez de você ter que digitar o código do departamento manualmente em múltiplos lugares.

Você está no caminho certo estudando tópicos avançados de normalização! Ajustar essas amarrações de chaves estrangeiras é o que diferencia um banco de dados lento e frágil de um sistema corporativo seguro e veloz. Continue firme nos exercícios!

Espero que possa ter lhe ajudado!