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:
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)
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)
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.
