Isso significa que os atributos não chave devem depender apenas da chave primária, e não de outros atributos não chave. As entidades são objetos (ou conceitos) do mundo real que são representados no banco de dados. Elas podem ser pessoas, objetos físicos, eventos, transações, sistemas, entre outros. Cada entidade possui atributos, que são características que descrevem e definem a entidade.
Repetição não é o motivo para normalizar, ser canônico é. Toda vez que o mesmo conhecimento é replicado em outro lugar seu código tem que ser responsável por administrar essa réplica. É isto que deseja para seu código, ter que lidar com esse fardo? Você pode ter a mesma informação modificada em um lugar e não no outro, e você tem a mesma informação em dois estados diferentes e dependendo de quem for acessar um ou outro mostrará algo inconsistente.
Normalização – Projeto do curso
Se tivermos cadastrado no banco um cliente e tivermos o seu telefone registrado em mais de uma tabela, havendo uma alteração no seu número de telefone, teremos que fazer essa atualização em cada tabela. A tarefa se torna muito mais eficiente se tivermos seu telefone registrado em apenas uma tabela. Agora, nosso pequeno exemplo está em um nível que não pode ser decomposto ainda mais para atingir tipos de normalização de forma normal mais elevada no SGBD.
A anomalia de inserção causa repetição desnecessária de dados dentro do nosso banco de dados, ou seja, redundância. Um exemplo disso seria repetir as informações de pedido, data e cliente, todas as vezes que inserimos um novo livro em um pedido específico. Analisando a tabela de “Vendas”, percebemos que o atributo “Produto” Qual escolher: Bootcamp de programação x cursos tradicionais não é completamente dependente da chave primária “N_pedido”. O nome do produto está repetido em diferentes linhas, o que é uma indicação de que a tabela não está na Segunda Forma Normal (2FN). Normalização é o processo de estruturação do esquema de um Banco de Dados Relacional que irá remover a maioria das ambiguidades.
Chaves candidatas, superchaves e dependências funcionais
Neste caso, criamos uma nova tabela para relacionar o nome da fábrica com seu código, e também removemos as relações de dependência entre atributos que não são chaves da tabela original. Tenha em conta que existe uma dependência entre o atributo ‘nome de fábrica’ e ‘ano’ com o ‘código de fábrica’, entretanto, estes atributos não dependem da chave principal da tabela que é ‘placa’. Considere que os campos de origem e destino não têm relação direta com o campo de código, mas têm uma relação direta com o código de voo, já que são informações relacionadas a uma viagem aérea, por exemplo. Assim, podemos mover essas informações a uma nova tabela sem que os dados percam as relações originais. Esta nova tabela foi criada para poder relacionar telefones com o atributo código, que na tabela principal é a chave primária, sendo definida como chave estrangeira.
Problemas que não exigem normalização não devem ser normalizados, mas o que deve ser, quase sempre deve por um motivo básico, é necessário que uma informação seja canônica, ou seja, ela só deve existir em um lugar da sua base de dados. https://temlondrina.com.br/tecnologia/qual-escolher-bootcamp-de-programacao-x-cursos-tradicionais/ Não quer dizer que não possa haver repetição, esse é um erro comum. Eu explico isso na pergunta O DRY é para evitar redundâncias, certo? Que é um conceito mal entendido pela maioria das pessoas achando que o problema é a repetição.
