Se uma tabela com uma chave substituta tiver uma coluna conhecida por ter valores únicos não nulos (por exemplo, SSN), ela viola a 3NF?

Uma relação R está na terceira forma normal se todo atributo não primo de R é não transitivamente dependente de cada chave candidata de R

EFCodd, 1971, Normalização adicional do modelo relacional de banco de dados

Está implícito na definição de uma relação que uma relação deve ter pelo menos uma chave. Nada sobre 3NF ou qualquer outra Forma Normal exige que uma relação tenha apenas uma chave.

Infelizmente, os livros sobre design e normalização de banco de dados têm exemplos abundantes de relações com apenas uma única chave e poucos exemplos com mais de uma chave. Isso me parece estranho, visto que várias chaves parecem ser uma prática muito comum atualmente. A escassez de exemplos práticos na literatura não acadêmica parece ser uma causa de confusão sobre o papel das chaves no projeto de banco de dados. Outra causa de confusão é o popular mnemônico "nada além da chave". Essa frase geralmente é atribuída a Bill Kent, mas não é uma definição precisa de 3NF.

Pelo que entendi, a terceira forma normal (3NF) basicamente significa que deve haver exatamente uma chave.

No. 2NF, 3NF e Boyce Codd Normal Form (BCNF) lidam com dependências funcionais . Uma tabela em 2NF significa que não há dependências de chave parciais onde uma coluna não-chave depende de algum subconjunto adequado de uma chave de várias colunas. Tabelas como a do nosso exemplo já estão em 2NF, pois cada chave candidata é uma única coluna. Uma tabela em 3NF significa que cada coluna não-chave também não depende funcionalmente de alguma outra coluna não-chave e, portanto, cria uma dependência transitiva. Não importa se há uma ou cem chaves candidatas. Na verdade, é BCNF, não 3NF, que é a forma normal "final" em relação às dependências funcionais. Isso ocorre porque uma tabela pode estar na 3NF e ainda não estar na BCNF, pois pode haver várias chaves candidatas que se sobrepõem. Assim, quando usamos o termo 3NF para significar "totalmente normalizado" em relação às dependências funcionais, o que realmente queremos dizer é BCNF.

Se uma tabela com, digamos, uma coluna de id de auto-incremento também tiver uma coluna conhecida por ser única e não nula, por exemplo, número do seguro social, essa outra coluna pode ser usada como a chave.

Não só poderia, como deve ser, se quisermos garantir que os dados armazenados no banco de dados permaneçam consistentes com as regras que identificamos no mundo real!

Ignorando questões práticas/comerciais (por exemplo, risco de segurança/privacidade ao passar SSN como uma chave/FK), de um aspecto estritamente de design de esquema, tal tabela não estaria em 3NF porque existem efetivamente 2 chaves?

Conforme explicado acima, se a tabela está ou não em 3NF (ou mais importante BCNF) é ortogonal a quantas chaves candidatas ela contém.

A resposta variaria se houvesse uma chave exclusiva na outra coluna? Em caso afirmativo, por quê?

Não, simplesmente porque determinar se a tabela está ou não na 3NF não tem nada a ver com quantas chaves candidatas ela possui. Em vez disso, tem tudo a ver com garantir que todas as colunas não-chave sejam totalmente dependentes funcionalmente dessas chaves candidatas.

Mas isso traz um ponto interessante. Observe que uma chave exclusiva quando definida como uma restrição em um DBMS não é o mesmo que um identificador exclusivo definido como uma regra de negócios em um modelo de negócios conceitual. Talvez em nosso mundo sempre saibamos o SSN da pessoa e, portanto, sirva como uma chave candidata para uma pessoa, e talvez também introduzamos uma chave substituta no esquema lógico que chamamos de Person Id . Nosso modelo de negócios inclui a regra de que o SSN é um identificador exclusivo de uma pessoa em nosso mundo. Isso implica uma dependência funcionalde todos os atributos descritivos neste atributo de identidade. Essa regra não muda só porque esquecemos ou optamos por não informar o SGBD. É exatamente por isso que é vital que a restrição seja declarada - para que o SGBD possa garantir que os dados armazenados sejam consistentes com as regras do modelo de negócios! Se não criamos essa restrição exclusiva no SSN, agora podemos criar inadvertidamente mais de uma linha para a mesma pessoa com o mesmo SSN; cada linha tendo um ID de pessoa diferente!

Uma excelente cartilha sobre esses tópicos é o Practical Database Foundation Series de Fabian Pascal e o Database Design and Relational Theory de Chris Date , do qual esta resposta é derivada. Embora cada artigo de Fabian seja uma leitura obrigatória, o documento nº 1 (que define claramente a diferença entre os níveis conceitual, lógico e físico) e o documento nº 4 (que define claramente os vários tipos de chaves) tratam especificamente dessa questão. Da mesma forma, todo o livro de Chris é uma leitura obrigatória, enquanto a Parte II é a seção dedicada à normalização com relação à dependência funcional.

Como a questão é baseada na interpretação de uma regra, devemos primeiro olhar para essa informação vinculada, que é (grifo meu):

2. todos os atributos em uma tabela são determinados apenas pelas chaves candidatas dessa tabela e não por quaisquer atributos não primos.

Acho que a confusão é resultado da má interpretação do termo "chaves candidatas". Pode haver várias chaves candidatas em uma tabela. É por isso que temos termos modificadores para especificar ainda mais neste grupo: Primário e Alternativo. Se as tabelas pudessem ter uma, e apenas uma, chave, então o termo Chave "Primária" seria enganoso e deveria ter sido chamado de outra coisa (talvez "Pai" ou "Origem" ou "Identificação", etc). Mas "Primária" implica que pode haver chaves "secundárias", e essas são chamadas de chaves "Alternativas".

Chaves alternativas são indicadas em modelos físicos por meio de uma Restrição Exclusiva ou Índice Exclusivo. Também deve ser notado que ambos os tipos de Chaves Candidatas (Primárias e Alternativas), podem ser referenciadas por Chaves Estrangeiras (mesmo que geralmente não se faça/não se deva fazer tal coisa sem uma boa razão!).

A resposta variaria se houvesse uma chave exclusiva na outra coluna? Em caso afirmativo, por quê?

Não, porque é uma questão de modelagem física versus lógica. Você pode ter uma tabela que tenha um IDENTITYcampo, mas ainda nenhuma chave primária definida. A tabela e seus dados podem facilmente estar na 3FN, mesmo que o modelo físico não imponha isso. Essa distinção é semelhante a se as chaves estrangeiras são ou não definidas. Você pode certamente JOIN tabelas, e não ter registros órfãos, quer quaisquer PKs/FKs tenham sido definidos ou não. E os dados podem estar 100% corretos sem essas construções. Mas ter os PKs e FKs definidos é a diferença entre Integridade Referencial (lógica) e Integridade Referencial Declarativa (física). Ter as restrições no modelo físico simplesmente ajuda a impor as regras do modelo lógico.

Com relação ao SSN (" Número do Seguro Social " para quem não está familiarizado com esse acrônimo), sendo uma Chave Alternativa e tendo um Índice/Restrição Único:

Eu recomendaria não considerar um SSN como uma chave alternativa e colocar uma restrição ou índice exclusivo nele, mesmo que seja comum fazê-lo (o SSN é frequentemente considerado uma chave "Natural" - uma que existe no mundo real) . Há duas razões principais:

1. Precisão: Na maioria das vezes, esses valores são inseridos em um sistema por alguém que preenche um formulário, seja em papel ou online. As pessoas cometem erros ao fazer a entrada de dados o tempo todo, especialmente se a fonte for um formulário de papel que está sendo inserido por alguém lendo a caligrafia desleixada de outra pessoa (como a minha, que é quase ilegível).

   Mesmo que os dados venham de outro sistema, você pode ter certeza de que o sistema de origem validou a informação? Você pode ter certeza de que não houve um bug na exportação de dados? E se houver um bug na importação de dados?

2. Singularidade: Mesmo que a principal Administração da Previdência Social nunca tenha emitido uma identidade duplicada, isso não significa que a duplicação não tenha ocorrido. Além dos problemas de roubo de identidade, lembro-me de ouvir alguém anos atrás que trabalhava como DBA para o Departamento de Receita do estado (acredito) e que tinha que lidar com os benefícios da Previdência Social, como eles estavam tendo "problemas" lidando com o que era um prática mais antiga de reatribuir o SSN de uma pessoa falecida ao cônjuge sobrevivente (geralmente a viúva) para que seja mais fácil para o cônjuge sobrevivente continuar recebendo os pagamentos de benefícios. Tenho certeza de que essa prática foi encerrada há algum tempo, mas os dados "duplicados" ainda estavam no sistema.