A colega Tássia deu uma excelente introdução, entretanto, a interpretação ainda está incompleta.
Seria interessante confrontar seu comentário com essa questão com:
http://www.questoesdeconcursos.com.br/imprimir?qt=50286
Veja que na questão acima, CPF depende só de CODIGO_C na tabela vendas e mesmo assim está na terceira forma normal, ou seja, também está na segunda forma normal. Então, reformulando o seu comentário eu coloquei em negrito um acréscimo que considero importantíssimo e merece destaque.
" Um esquema de relação R está na segunda forma normal se todo atributo não primário(ou seja, não pode ser chave candidata) A em R tem dependencia funcional TOTAL DA CHAVE PRIMÁRIA".
Eu faço este acréscimo pois algumas pessoas podem ler seu comentário e interpretar chave como chave primária e, na verdade, o mais correto seria chave candidata.
Abraço
Definição
'Uma tabela está na 1FN, se e somente se, todos os valores de colunas em uma tabela forem atômicos.'
(note que relacionamentos, como definidos acima, estão necessariamente na 1FN)
Uma relação está na 1FN quando todos os atributos da relação estiverem baseados em um domínio simples, não contendo grupos ou valores repetidos[1] .
Definir relações NFNF
como transformar relações NFNF (também chamadas relações UNF) em relações 1FN
como transformar as restrições chave de relações aninhadas
como transformar as dependências funcionais de relações aninhadas
Passagem à 1FN
Gerar uma única tabela com colunas simples
Chave primária: id de cada tabela aninhada
Exemplo
Projetos(codp, tipo, descrição, code, nome, categ, salário, data_início, tempo_aloc)
Outra forma de identificar se a tabela não está na 1FN é verificando se existe tabela aninhadas, ou seja, mais de um registro para uma chave primária.
Observe o exemplo:
Considere um Pedido número 00001, para este pedido se observarmos o formulário em papel teremos muitos campos a considerar, contudo usaremos apenas alguns para facilitar o entendimento.
PEDIDOS = {COD_PEDIDO + CLIENTE + VENDEDOR + ATENDENTE + PRODUTO + QUANT + VALOR}
Neste momento devemos idealizar o pedido número: 00001 e efetuar os seguintes testes:
{COD_PEDIDO | CLIENTE | VENDEDOR | ATENDENTE | PRODUTO | QUANT | VALOR}
{00001 | "DOUGLAS TYBEL"| "MARCO"| "JOAO" | "TENIS " | "1" | "50.00"}
{00001 | "DOUGLAS TYBEL"| "MARCO"| "JOAO" | "SANDALIA" | "2" | "80.00"}
{00001 | "DOUGLAS TYBEL"| "MARCO"| "JOAO" | "CARTEIRA" | "1" | "35.00"}
Observe que para os dados do pedido 00001 lançados acima, apenas os atributos que estão em negrito SÃO ÚNICOS, pois não se diferem. Os demais atributos mudam, não cumprindo a 1FN onde os atributos devem ser atômicos, quer dizer únicos.
Para testarmos um dos atributos e ter certeza que este é atômico, podemos efetuar uma pergunta conforme o exemplo abaixo:
Podemos ter outro cliente para o pedido 00001 ? = Não. Podemos ter apenas 1 cliente por pedido, sendo assim este atributo é atômico único para 1 pedido.
Podemos ter outro vendedor para o pedido 00001 ? = Não. Podemos ter apenas 1 vendedor por pedido.
Podemos ter outro produto para o pedido 00001 ? = Sim. Podemos ter vários produtos para um pedido, sendo assim, os campos aninhados devem ser extraídos para outra tabela.