Solucionado
Pelo o que entendi da 2 forma normal é isso. Não se pode ter campos(colunas) que não sejam dependentes da tabela que está contida, o melhor a se fazer é remover esses campos e criar uma tabela para ela e por o referencial desta nova tabela na antiga tabela.
É isso /?
Oi Thiago, ao meu ver, isso é a primeira forma formal que fala sobre atomicidade dos dados. A segunda forma normal fala sobre dependência funcional onde um campo não pode depender somente de parte da chave, neste caso sim, a solução é separar em uma outra tabela.
Boa parte das soluções é a mesma, o desafio é planejar bem essas relações.
Não entendi o que você disse com "onde um campo não pode depender somente de parte da chave"
Algumas tabelas requerem por exemplo duas chaves estrangeiras formando sua chave primeira. Uma forma fácil de ver é um ecommerce, onde na tabela compras eu preciso do ID do usuário e o ID do carrinho de compras por exemplo. As duas chaves juntas formam uma nova chave primária.
Pelo que vi da segunda forma, você não pode ter nessa tabela por exemplo, o nome do usuário que fez a compra, por que? Por que ela depende apenas do ID do usuário. Você também não pode ter o ID de um produto comprado, por que ela só depende do ID do carrinho em si. Então teríamos na prática
1 tabela usuários. 1 tabela carrinho 1 tabela produtos 1 tabela compras 1 tabelas carrinho_produtos
Dá pra imaginar os relacionamentos?
Acho que deu sim, valeu