Se uma tabela com uma chave substituta possui uma coluna conhecida por ter valores não nulos exclusivos (por exemplo, SSN), isso viola o 3NF?

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

Se uma tabela com uma idcoluna de auto incremento , por exemplo, também possuir uma coluna conhecida como única e não nula, por exemplo, número do seguro social, essa outra coluna poderá ser usada como chave.

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

A resposta variaria se houvesse uma chave exclusiva na outra coluna? Se sim, por quê?

Uma relação R está na terceira forma normal se todos os atributos não primos de R dependerem não transitivamente 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 no 3NF ou em 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 chave e menos exemplos com mais de uma chave. Isso me parece estranho, já que várias chaves parecem ser uma prática muito comum nos dias de hoje. 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 design de bancos de dados. Outra causa de confusão é o mnemônico popular "nada além da chave". Essa frase é geralmente atribuída a Bill Kent, mas não é uma definição precisa de 3NF.

Como a pergunta é baseada na interpretação de uma regra, devemos primeiro examinar as informações vinculadas, que são (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.

Eu acho que a confusão é resultado da interpretação incorreta do termo "chaves candidatas". Pode haver várias chaves candidatas em uma tabela. É por isso que temos termos modificadores para especificar melhor entre este grupo: Primário e Alternativo. Se as tabelas pudessem ter uma, e apenas uma chave, o termo "Chave Primária" seria enganoso e, em vez disso, deveria ser chamado de outra coisa (talvez "Pai" ou "Origem" ou "Identificação" etc.). Mas "Primário" 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-se notar que os dois tipos de chaves candidatas (principal e alternativo), pode ser referenciado por Foreign Keys (apesar de um geralmente não faria / não deve fazer tal coisa sem uma muito boa razão!).

A resposta variaria se houvesse uma chave exclusiva na outra coluna? Se sim, por quê?

Não, porque isso é uma questão de modelagem física x lógica. Você pode ter uma tabela que possui um IDENTITYcampo, mas ainda nenhuma Chave Primária definida. A tabela e seus dados podem estar facilmente em 3NF, mesmo que o modelo físico não imponha isso. Essa distinção é semelhante à definição ou não de chaves estrangeiras. Você certamente pode JOIN tabelas e não possui registros órfãos, independentemente de quaisquer PKs / FKs terem sido definidas. E os dados podem estar 100% corretos sem essas construções. Porém, ter as PKs e as FKs definidas é 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 de Seguridade Social " para aqueles que não estão familiarizados com esse acrônimo), e por ser uma Chave Alternativa e ter um Índice / Restrição Única:

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

1. Precisão: Na maioria das vezes, esses valores são inseridos no sistema por alguém preenchendo um formulário, seja em papel ou online. As pessoas cometem erros enquanto fazem a entrada de dados o tempo todo, especialmente se a fonte for um formulário em papel que está sendo digitado por alguém que lê a escrita desleixada de outra pessoa (como a minha, que dificilmente é legível).

   Mesmo se os dados vierem de outro sistema, você pode ter certeza de que o sistema de origem validou as informações? Você pode ter certeza de que não houve um erro na exportação de dados? E se houver um erro na sua importação de dados?

2. Exclusividade: mesmo que a Administração de Seguridade Social principal nunca tenha emitido um ID duplicado, isso não significa que a duplicação não ocorreu. Fora dos problemas de roubo de identidade, lembro-me de ouvir de alguém anos atrás que trabalhou como DBA para o Departamento de Receita dos estados (acredito) e que teve que lidar com os benefícios do Seguro Social, como eles estavam tendo "problemas" ao lidar com o que era um prática mais antiga de reatribuir o SSN de uma pessoa falecida ao cônjuge sobrevivo (geralmente a viúva), para que fosse mais fácil para o cônjuge sobrevivente continuar coletando os pagamentos dos benefícios. Tenho certeza de que essa prática foi encerrada há um tempo, mas os dados "duplicados" ainda estavam no sistema.

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 parciais de chave em que 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 no 3NF significa que todas as colunas que não são de chave também não dependem funcionalmente de alguma outra coluna que não seja de chave, criando, assim, uma dependência transitiva. Não importa se há uma ou cem chaves candidatas. Na verdade, é o BCNF, não o 3NF, que é a forma normal "final" em relação às dependências funcionais. Isso ocorre porque uma tabela pode estar no 3NF e ainda não no BCNF, pois pode haver várias chaves candidatas que se sobrepõem. Assim, quando usamos o termo 3NF para significar "totalmente normalizado" com relação às dependências funcionais, o que realmente queremos dizer é BCNF.

Se uma tabela com uma coluna id de incremento automático também possuir uma coluna conhecida por ser única e não nula, por exemplo, número do seguro social, essa outra coluna poderá ser usada como chave.

Não só poderia ser, mas também deve ser, se queremos 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 o SSN como uma chave / FK), de um aspecto estritamente de projeto de esquema, essa tabela não estaria no 3NF porque existem efetivamente 2 chaves?

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

A resposta variaria se houvesse uma chave exclusiva na outra coluna? Se sim, 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 sem chave sejam totalmente funcionalmente dependentes dessas chaves candidatas.

Mas isso faz abrir um ponto interessante. Observe que uma chave exclusiva quando definida como uma restrição em um DBMS não é a mesma que um identificador exclusivo definido como uma regra de negócios em um modelo de negócios conceitual. Talvez em nosso mundo sempre conheçamos o SSN da pessoa e, portanto, ela sirva como uma chave candidata para uma pessoa, e talvez também introduzamos uma chave substituta no esquema lógico que chamamos de ID da pessoa . Nosso modelo de negócios inclui a regra que afirma que o SSN é um identificador exclusivo para uma pessoa em nosso mundo. Isso implica uma dependência funcionalde todos os atributos descritivos nesse atributo de identidade. Essa regra não muda apenas porque esquecemos ou optamos por não informar o DBMS. É exatamente por isso que é vital que a restrição seja declarada - para que o DBMS 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 com um ID de pessoa diferente!

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