Document

3.2. Diretriz 2

Projete os esquemas de relação da base de modo que nenhuma anomalia esteja presente nas relações. Se houver alguma anomalia, e forem realmente necessárias, documente-as para que a equipe de programação saiba como conduzir as operações corretamente. Lembre-se: algumas regras podem ser violadas para fim de melhorar o desempenho de certas consultas e operações, ou simplesmente para simplificar a programação.

Um banco de dados não normalizado pode apresentar algumas anomalias. Por exemplo, suponha que exista uma tabela de nome PESSOAS e um campo denominado TELEFONES. Nesse campo, independentemente de quantos telefones a pessoa possua, todos esses serão registrados nesse campo. Dessa forma, se a pessoa possui três números de telefone, esses poderiam ser, hipoteticamente cadastrados como: “(61) 2233-4567; (61) 3322-0101; (61) 9988-4321”. Veja que para essa estrutura, não é possível inserir um novo número de telefone utilizando a operação de INSERT da SQL. Para inserir um novo número, é necessário alterar o conteúdo atual com uma instrução SQL de UPDATE, contemplando os números antigos e o novo número. Com isso aumentamos também a chance de erro, pois podemos acabar perdendo ou modificando indevidamente um dos números já cadastrados.

Portanto, para esse modelo, ter que acrescentar um novo dado usando uma operação de UPDATE ao invés de uma opção de INSERT é uma anomalia SQL.