MySQL Tabelas de Relacionamento 1FN 2FN 3FN

[Visitante]

Bom dia! Gostaria de saber a opinião de vocês se é possível aplicar ainda mais as formas 1FN, 2FN e 3FN, se minha tabela está boa o suficiente já para construir um sistema. Bom vou explicar mais o menos como funciona.

Quero que o aluno se cadastre, após isso ele vai ter acesso aos cursos, promoções, notícias e eventos, fora o material que irá receber de cada curso cadastrado, gostaria de saber o que posso fazer a respeito também sobre o material, uma tabela separada ligada com curso e aluno?

Bom, vou mostrar a vocês a seguir como estão minhas tabelas. Por favor, quero críticas e quero melhor muito! Indiquem erros se eu apliquei e como posso melhorar... 

Desde já obrigado a todos!

Imagem 1: Mostrando Aluno, notícias, promoções e uma parte de cursos:

 

 

Imagem 2: Aluno, evento, hora, data, telefone:

 

 

 

 

Imagem 3: Mostrando modulos, hora e data de cada curso etc... 

 

 

 

 

 

 

[Sharkovisky]

Vamos lá, eu não sou um expert em banco de dados, mas posso apontar algumas coisas no seu sistema.

 

Primeiramente, eu acho que eu peguei o espírito da coisa quando se fala em relacionamento 1:N, eu percebi ali em vários momentos que você fez uma outra tabela para um relacionamento 1:N, sendo, que nesses casos, a chave primária da tabela do lado 1 do relacionamento, vai como chave estrangeira para a tabela do lado N. Exemplo a tabela Data_Promoção e Promoção, da primeira imagem. Você colocou o lado N na tabela Data_Promoção, porém você está "puxando" a chave primária da tabela do lado N, e não do lado 1, então seria melhor você inverter essa parte. 

 

Na tabela Aluno e Notícia, se você pode ligar diretamente elas, estaria só como 1:1, então não haveria a necessidade a criação de outra tabela. Mas já que esse tipo de relacionamento requer aquela pergunta: "Um aluno pode fazer várias notícias?" Sim. "Uma notícia pode ter vários alunos?" Sim também, então seria N:N, o que ocasionaria a criação de uma nova tabela, como está ali, eu não sei se tem necessidade colocar cardinalidade na ligação das tabelas com a tabela gerada por um relacionamento N:N, acredito que confunde demais.

 

E por fim, eu acredito que seja melhor você sempre fazer as chaves estrangeiras na tabela mãe, tipo Aluno, porque quando você vai tirar o relatório, apareceria se ele tem promoção e tal, essas coisas, e além disso da pra poder "viajar" entre o banco de dados, fazendo os relacionamento pra chegar em qualquer lugar, de ponta a ponta.

 

Eu acredito que para aplicar as formas normais, seja necessário você converter esse diagrama para a forma de texto: "tbAluno(...)", pois aparenta ser muito mais fácil visualizar qualquer tipo de problema no banco de dados.

[Visitante]

Bom dia Shark! Obrigado pelas orientações, mas fiquei em dúvidas em algumas partes dos seu texto... Como essa:

"Primeiramente, eu acho que eu peguei o espírito da coisa quando se fala em relacionamento 1:N, eu percebi ali em vários momentos que você fez uma outra tabela para um relacionamento 1:N, sendo, que nesses casos, a chave primária da tabela do lado 1 do relacionamento, vai como chave estrangeira para a tabela do lado N. Exemplo a tabela Data_Promoção e Promoção, da primeira imagem. Você colocou o lado N na tabela Data_Promoção, porém você está "puxando" a chave primária da tabela do lado N, e não do lado 1, então seria melhor você inverter essa parte. ", eu cheguei a fazer outra tabela por que pensei assim: "Um aluno pode se cadastrar em mais de uma promoção" (N), "Uma promoção pode conter vários alunos" (N) ai surgiu novas tabelas para filtrar melhor, mas não sei se está certo. Eu resolvi puxar o id_data_promoção na tabela Promoção pois foi assim que me ensinaram a fazer rsrsrs. Em relação a tabela mãe (Aluno) eu puxaria as chaves primárias de aluno_curso, aluno_promoção certo? Ou puxaria id_promoção direito? 

Obrigado pela atenção!