Estou tentando obter uma versão definitiva do que é a primeira forma normal. Tudo o que leio tem um giro um pouco diferente.

Muitas autoridades, como Data, dizem que, por definição, uma relação está sempre na Primeira Forma Normal, enquanto outras fornecem uma lista de requisitos. Isso significa que existem de zero a muitos requisitos para 1NF.

Suponho que a diferença é que entre tabelas e relações: tabelas podem ser uma bagunça completa, enquanto um relacionamento segue certas restrições. O fato de uma relação ser representada como uma tabela no SQL cria certa confusão.

Estou focando especificamente no 1NF no que se refere aos bancos de dados SQL. A questão é: quais propriedades são necessárias para garantir que uma tabela esteja na primeira forma normal?

Muitas autoridades sugerem que, se uma tabela representa uma relação , ela já está no 1NF. Isso leva a definição de 1NF de volta à definição de uma relação.

Aqui estão algumas propriedades de uma tabela no 1NF:

• A ordem das colunas é insignificante [1]
• Ordem das linhas é insignificante
• Todas as linhas têm o mesmo comprimento (ou seja, os dados da linha correspondem aos cabeçalhos das colunas)
• Não há linhas duplicadas (isso pode ser garantido usando uma chave primária substituta, mas a própria PK não é necessária)
• Não há colunas repetidas
• Cada coluna contém um único valor (atômico)

[1] Tecnicamente, os atributos não são ordenados, mas em uma tabela, os dados da linha devem estar na mesma ordem que os cabeçalhos das colunas. No entanto, a ordem real é insignificante.

Em vários dados :

O conceito de dados atômicos é que um item não pode ser mais dividido. Esse conceito foi qualificado de que, embora tecnicamente tudo possa ser decomposto ad nauseum , os dados em questão não podem ser praticamente decompostos, dependendo de como os dados serão usados.

Por exemplo, um endereço completo ou um nome completo normalmente deve ser discriminado ainda mais, mas os componentes, como o nome ou o nome da cidade, provavelmente não devem ser discriminados, apesar do fato de que podem ser cadeias de caracteres.

No que diz respeito à repetição de colunas, é uma coluna de design ruim ter quase repetições de colunas, como phone1, phone2etc. Em geral, dados repetidos indicam a necessidade de uma tabela relacionada adicional.

Dependência

Não deve haver nenhum relacionamento entre linhas, exceto se elas estiverem em conformidade com os mesmos cabeçalhos.

Também não deve haver relação entre colunas, mas acredito que esse seja o assunto de formas normais mais altas.

A pergunta é: quanto do exposto está na definição de 1NF? O bit de linhas independentes também entra nele?

Preliminares

A definição de forma normal (que, a partir da apresentação de "Normalização adicional do modelo relacional de banco de dados" em 1971, é conhecida como primeira forma normal ) e a definição do próprio paradigma relacional foram publicadas em 1970 no artigo científico que forneceu uma forte base para a prática de administração de banco de dados, ou seja, “Um Modelo Relacional de Dados para Grandes Bancos de Dados Compartilhados” (RM por brevidade) criado pelo Dr. EF Codd , que é um destinatário do Turing Award e a autoridade em relação à estrutura relacional.

Sim, há muitas explicações, interpretações, exposições, desvios e opiniões sobre o texto do Dr. Codd, mas eu pessoalmente prefiro manter a fonte original e sugiro que você a analise por si mesmo para poder tirar suas próprias conclusões.

Certamente eu não entendo o RM na íntegra, mas o que eu entendo dele me permite apreciar sua excelência, visão, intenção e escopo e, embora décadas depois se note que há algumas pequenas imprecisões, elas não reduzem, de qualquer forma, sua genialidade e elegância. Em seu campo, o RM resistiu ao teste do tempo de uma maneira única e permanece incomparável.

O ato de enfatizar as imprecisões acima mencionadas seria - usando um termo de caridade - injusto porque, vendo-o de uma distância considerável, esse material seminal exigia alguns refinamentos e extensões, sim, mas o corpo principal da obra era sólido como rocha. muita concepção (e, de fato, o Dr. Codd fez a maioria - se não todos - de tais refinamentos e extensões).

Continuo relendo o RM constantemente, a fim de fortalecer minha compreensão dessa fonte excepcional de conhecimento (e minha estima por ele continua crescendo a cada releitura); o objetivo é ficar sobre os ombros dos gigantes.

Relações e tabelas

É importante observar que, como as relações são recursos abstratos , o Dr. Codd imaginou a utilidade de representá-los em forma de tabela (ele inicialmente usou o termo "representação de array", mas posteriormente utilizou "table" ou "r-table"), para que os usuários, designers e administradores de um banco de dados relacional (RDB) podem abordá-los de maneira mais familiar ou concreta . Portanto, no contexto de uma implementação de RDB, é válido usar a tabela como um atalho para a relação, desde que essa tabela represente uma relação real. Esse recurso é - embora óbvio - bastante significativo porque, antes de avaliar se uma tabela representa ou não uma relação que está de acordo com a primeira forma normal (1NF), ela deve representar, precisamente, uma relação.

O RM naturalmente contém as qualidades que uma tabela deve ter para determinar se de fato representa uma relação, mas vou oferecer uma interpretação informal e despretensiosa sobre elas aqui (outra, sim!):

• Ele deve ter um nome (cada relação específica em uma estrutura de banco de dados deve ser diferenciada das demais).
• Cada uma de suas linhas deve representar exatamente uma tupla da relação pertinente.
• A ordem de suas linhas não é importante.
• Cada uma de suas colunas deve ter um nome que represente exatamente o significado de um domínio da relação em questão, e esse nome deve ser diferente dos nomes das demais colunas da tabela (uma coluna deve ser diferenciada exclusivamente e deve conter um significado distinto e, sim, o papel desempenhado por um modelador de banco de dados e pelos especialistas em negócios para definir cada domínio de significância com precisão é primordial)
• A ordem de suas colunas não tem significado.
• Todas as suas linhas devem ter o mesmo número de colunas.
• Ele deve ter pelo menos uma coluna, ou uma combinação de colunas, que identifique exclusivamente cada uma das tuplas representadas por linhas; dessa maneira, todas as linhas devem ser diferentes (sim, isso enfatiza a importância de ter pelo menos uma KEY declarada e, quando houver duas ou mais KEYs, uma deve ser definida como PRIMARY com base em razões pragmáticas, enquanto o restante pode ser considerado ALTERNATIVO, mas sim, antes de tomar a decisão, cada uma das CHAVES era “candidata” a uma definição como PRIMÁRIA).

Ter uma tabela que de fato represente uma relação é fundamental, pois, quando sofre operações de manipulação de um tipo relacional, o resultado é, novamente, uma tabela que representa uma relação. Desta maneira, o comportamento da referida tabela é previsível .

Domínios atômicos (colunas)

Nas primeiras seções da RM, o Dr. Codd apresenta várias amostras de relações para introduzir alguns conceitos; portanto, para compreender o significado do domínio atômico , comecemos com o seguinte trecho da RM que detalha alguns pontos pertinentes:

Até o momento, discutimos exemplos de relações que são definidas em domínios simples - domínios cujos elementos são valores atômicos (não comparáveis). Valores não atômicos podem ser discutidos dentro da estrutura relacional. Assim, alguns domínios podem ter relações como elementos. Essas relações podem, por sua vez, ser definidas em domínios não simples, e assim por diante.

Dessa maneira, pode-se dizer que cada uma das relações expositivas mencionadas acima se encaixa em um de dois tipos, digamos o tipo A ou o tipo B :

• Tipo A agrupa apenas relações (tabelas) que são estruturadas com domínios (colunas) que contêm valores exclusivamente simples em cada uma das suas tuplas (linhas), ou seja, esses domínios (colunas) não contêm relações (tabelas) como valores, que em esse contexto significa que os valores são atômicos porque não podem ser decompostos sucessivamente em novas relações (tabelas). Portanto, as relações dessa classe são as que são normalizadas , ou seja, elas atendem ao 1NF, sua forma é desejável.

• O tipo B é integrado exclusivamente por relações (tabelas) que possuem um ou mais domínios (colunas) que mantêm relações como valores em cada respectiva tupla (linha) e isso significa que esses valores são não atômicos, pois podem ser posteriormente divididos em novas relações (tabelas), ou seja, são decomponíveis . Assim, as relações desse tipo não são normalizadas, ou seja, infringem a 1NF, estão em uma forma indesejável.

Normalização

O Dr. Codd apresenta a seção sobre normalização no RM com o seguinte parágrafo:

Uma relação cujos domínios são todos simples pode ser representada no armazenamento por uma matriz bidimensional homogênea da coluna do tipo discutido acima. Alguma estrutura de dados mais complicada é necessária para uma relação com um ou mais domínios não simples. Por esse motivo (e outros a serem citados abaixo), vale a pena investigar a possibilidade de eliminar domínios não simples. De fato, existe um procedimento de eliminação muito simples, que chamaremos de normalização.

Então ele continua mostrando:

1. Um grupo de relações em que uma não é normalizada (possui domínios que contêm relações como valores, ou seja, são não atômicas; ou seja, não são simples)

2. Um grupo de relações que são normalizadas (ou seja, que foi decomposto; ou seja, um que relaciona domínios valorizados foram divididos em simples, o que significa que são atômicos)

E então ele descreve o procedimento para obter relações normalizadas das não-normalizadas.

A esse respeito, as relações que ele empregou para ilustrar um exercício de normalização e a própria descrição do exercício são bastante claras, e recomendo novamente que você as analise (e também espero que isso incentive alguns leitores a se envolverem com o texto).

Sucessivamente, ele indica:

Outras operações de um tipo de normalização são possíveis. Estes não são discutidos neste documento.

E as referidas operações, isto é, a segunda e a terceira forma normal (2NF e 3NF) são realmente detalhadas em “Normalização Adicional do Modelo Relacional de Base de Dados” e, como mencionado acima, após a apresentação (e a posterior impressão e publicação) deste documento , a forma normal original ficou conhecida como primeira forma normal.

Como um praticante pode observar, ter relações não normalizadas (tabelas) introduz (quase sempre desnecessariamente) a convolução nas implementações de RDB.

Uma relação que satisfaça 1NF facilita a definição de restrições e operações de manipulação de dados que podem ser implementadas por meio de uma sub-linguagem de dados menos complexa do que a exigida para relações não normalizadas (tabelas), como o Dr. Codd aponta nas seguintes linhas:

A adoção de um modelo relacional de dados, como descrito acima, permite o desenvolvimento de uma sub-linguagem universal de dados com base em um cálculo de predicado aplicado. Um cálculo de predicado de primeira ordem é suficiente se a coleção de relações estiver na forma normal. Essa linguagem forneceria um parâmetro de poder lingüístico para todas as outras linguagens de dados propostas e seria ela própria uma forte candidata a incorporar (com modificação sintática apropriada) em uma variedade de linguagens host (orientada a programação, comando ou problema). [...]

[...]

A universalidade da sub-linguagem dos dados reside na sua capacidade descritiva (não na sua capacidade de computação).

A perplexidade

Do meu ponto de vista, a confusão surgiu devido a (a) excesso de interpretações, explicações, etc., acima mencionado, sobre 1NF e a própria RM, e por causa (b) de novas tentativas de redefinir 1NF que afirmam ter relações com domínios que mantêm valores que, por sua vez, são compatíveis com 1NF, desde que sejam um valor único para cada tupla correspondente.

Minha opinião sobre seus outros pontos

Não deve haver nenhum relacionamento entre linhas, exceto se elas estiverem em conformidade com os mesmos cabeçalhos.

Não sei se entendi corretamente a intenção dessa declaração, mas, além de obedecer aos mesmos cabeçalhos, deve haver uma conexão entre as (tuplas) linhas de uma relação (tabela), pois cada uma delas deve ser uma afirmação sobre uma ocorrência específica do tipo de entidade específico (definido em termos do contexto de negócios de interesse) que a relação (tabela) deve representar.

Também não deve haver relação entre colunas, mas acredito que esse seja o assunto de formas normais mais altas.

Também não sei se estou interpretando adequadamente o significado dessa afirmação, mas, de fato, e de acordo com minha resposta ao aspecto anterior, também deve haver uma relação entre os domínios (colunas) de uma relação (tabela) , e é exatamente por isso que é uma relação (a estrutura essencial do modelo relacional e de uma implementação concreta do RDB).

Para exemplificar, com relação à relação hipotética (tabela)

• Salary (PersonNumber, EffectiveDate, Amount)

a tupla (linha)

• Salary (x, y, z)

transmitiria o significado

• The Salary payed to the Person identified by PersonNumber x, on EffectiveDate y corresponds to the Amount of z

Portanto, cada tupla (linha) da Salaryrelação (tabela) deve se encaixar na estrutura da asserção mostrada acima, e a diferença seria a substituição dos valores pertinentes do domínio (coluna), mas deve existir uma relação entre (a) todos os Salarydomínios (colunas) e também entre (b) todos os seus valores correspondentes em relação a cada tupla (linha); tal relacionamento é indispensável.

Formas normais mais altas (2NF e 3NF) são úteis para se livrar de dependências funcionais entre domínios (colunas) de uma relação (tabela), elas ajudam a evitar conexões indesejáveis entre domínios (colunas), pois as conexões indesejáveis permitem a introdução de anomalias de atualização . Tanto o 2NF quanto o 3NF são úteis para testar a solidez da estrutura das relações (tabelas) em uma determinada implementação de RDB.

Uma ilustração. Pegue uma sequência de texto que contenha um endereço típico dos EUA:

"123 Cornhusk Rd., South Succotash, NY 12345"

Escrever uma consulta para encontrar todos os residentes da Cornhusk Road ou um determinado morador da cidade de South Succotash ou do estado de Nova York seria uma tarefa assustadora. Especialmente quando você tem as seguintes seqüências de caracteres nos dados:

"123 Cornhusk Road, South Succotash, NY 12345"
"123 Cornhusk Rd., South Succotash, New York 12345"
"123 Cornhusk, South Succotash, NY 12345"
"123 Cornhusk Rd., SOUTH SUCCOTASH, NY 12345"

Cada um deles especifica o mesmo endereço real (e isso nem considera erros ortográficos prováveis, como "Succatash"), mas escrever o algoritmo para compará-los com sucesso é algo que eu NÃO gostaria de dedicar nos meus últimos anos restantes na Terra.

Digite o primeiro formulário normal. Não vou entrar em detalhes de como isso é feito, basta considerar um formulário comum, como visto na maioria dos bancos de dados:

create table Addresses(
  ...
  Street  varchar,
  City    int        references Cities( ID ),
  State   char( 2 )  references States( ID ),
  Zip     int
  ...
);

Esta não é uma normalização completa. Por exemplo, você pode dividir ainda mais a Street em StreetNum e StreetName, mas isso é suficiente para uma ilustração simples e é realmente o ponto em que o processo de normalização é realizado na vida real. Ainda existe um pequeno problema em encontrar todos os moradores de Cornhusk Road, mas se você procurasse na rua o substring "Cornhusk" e houvesse uma cidade chamada Cornhusk em algum lugar, pelo menos isso não causaria confusão.

O problema com a definição fornecida por Date et al. É que eles não conseguem olhar dentro de um pedaço de dados e considerar o significado desses dados. Não que eu os culpe particularmente, pode ser bastante difícil.

Portanto, precisamos pegar uma "sequência de caracteres" e transformá-la em um "endereço". Mas apresentar uma definição abrangente de endereço não é tão simples quanto parece. Especialmente ao trabalhar com endereços em mais de um país.

Primeiro, corrigimos o contexto. Nada tem significado sem contexto. Nosso contexto aqui é o endereço . Nesse contexto, podemos ver partes dos dados que têm significados específicos, como Rua , Cidade , etc. Atribuímos a cada significado um campo separado.

A parte difícil é que dados, como palavras, podem ter significados diferentes para pessoas diferentes ou algumas pessoas podem ver um significado onde outras não. Pode ser um projeto só para si e requer uma grande dose de esforço cooperativo. Mas é um elemento crítico no bom design do banco de dados.

O ponto da normalização é eliminar ou pelo menos minimizar dados anômalos . Considere o fato de que, na tabela acima, pode ser inserido um código de cidade ou CEP que não existe no estado selecionado. Ou entrou uma rua que na verdade não existe na cidade selecionada. Ah, mas agora estamos entrando na segunda e na terceira forma normal e esse é outro tópico.

Pense no 1NF como uma introdução ao conceito matemático de relações, em vez de uma estrutura de dados específica ou conjunto fixo de regras. Estruturas matemáticas como relações podem ser representadas de diferentes maneiras - as tabelas são apenas uma das maneiras mais convenientes. Ao usar tabelas, existem restrições para garantir que elas representem claramente as relações pretendidas e que as operações nas tabelas sejam logicamente válidas em relação às relações representadas.

Quando dizemos que a ordem e a duplicação de colunas e linhas são insignificantes, isso garante que todas as informações significativas sejam registradas como valores na tabela e acessíveis às nossas consultas, e não codificadas na apresentação da tabela. Embora poucos autores, se houver, tenham proibido explicitamente o uso de cores em tabelas, a compreensão do objetivo das restrições acima nos levaria a excluir da mesma forma o uso de cores de apresentação significativas para que valores significativos de cores tenham que ser explicitamente registrados. A data e outros autores também substituem os identificadores de linha ocultos pelo mesmo motivo.

O conceito de atomicidade é garantir que toda a estrutura significativa seja expressa como relações, para que possamos analisar dependências em todos os nossos dados e evitar anomalias, e para que toda a estrutura significativa seja uniformemente acessível às operações relacionais. Os valores compostos não são inválidos, mas exigem que os operadores específicos do domínio sejam descompactados, o que aumenta a complexidade e podem introduzir redundância. Obviamente, na prática, alguns tipos simples de compostos e operadores associados são convenientes e ajudam a aumentar a compactação e a expressividade das consultas, mas isso não contradiz a teoria.

Dependências de linha, como dependências com vários valores, não violam 1NF, mas, como dependências entre colunas, são objeto de formas normais mais altas. Quase repetindo colunas como phone1,phone2 etc não violam 1NF, mesmo que sejam de design ruim.

A definição e explicação da WikiPedia sobre 1NF, acho que é muito boa. - joanolo

Expandindo uma frase no artigo da Wikipedia:

Visto como números de telefone, o texto não é atômico

Isso pode ajudar você a entender por que há tanta confusão. Se este é apenas um pedaço de texto, então é atômico. Mas se é visto como números de telefone, não é atômico. Date e outros contornam esse problema. Tem a ver com o que os dados significam. Quando você analisa o assunto, precisa entender o que os dados significam.

Se há algum motivo para detalhá-lo é relevante para a questão de saber se a primeira forma normal foi cumprida. O objetivo do 1NF é fornecer acesso com chave a todos os dados. Mas se o que você recupera via acesso com chave possui subestrutura, não possui acesso com chave à subestrutura. - Walter Mitty

"1NF" é usado para significar várias coisas diferentes , muitas das quais são simultaneamente absurdas e comuns. Veja minha resposta para "Normalização no sistema de gerenciamento de banco de dados" , incluindo seus links. Uma delas é a minha resposta para "O que é atomicidade em dbms" . (Ambos no Stack Overflow.) - philipxy

_{Resposta do wiki da comunidade criada a partir dos comentários deixados na pergunta}