Em primeiro lugar, não sou um DBA, sou um engenheiro de software e tenho construído aplicativos que são baseados em banco de dados durante toda a minha carreira. Uma das coisas de que me lembro (talvez incorretamente) é que, ao projetar o ERD, você leva em consideração o mundo real, pois serve como contexto para o seu design.
Tenho uma situação em que temos o conceito de cliente, que pode ter dois e apenas dois números de telefone. Um cliente também pode ter de zero a vários endereços, e cada endereço pode ter apenas dois números de telefone (e um sinalizador indicando se o número é um número de celular). Os números de um endereço seriam usados apenas para entrar em contato com alguém naquele endereço específico, enquanto os números do cliente são usados para entrar em contato com o cliente (cujo endereço pode não estar no sistema).
O design que criei foi ter um Phone1 Phone2 como colunas na tabela de clientes, bem como na tabela de endereços. Outros sugeriram que esse não é um bom design e que eu deveria ter criado uma tabela PhoneNumber (não tenho certeza de como eles estavam sugerindo que eu relacionasse os números com os outros registros).
Certamente, posso ver que isso também é válido, mas ainda preciso ter Phone1Id e Phone2Id na tabela de clientes e endereços ou ter algo na tabela Phone que me diga qual registro possui o número. O problema que tenho é que obviamente torna a lógica do aplicativo mais complexa, pois agora preciso adicionar, remover ou atualizar o registro na tabela de telefones em vez de apenas apagar ou anular o valor nas respectivas tabelas.
Meu design também é aceitável? É preferível um ou outro? Ou ambos são igualmente válidos?
A brigada antinulo insistiria para que você normalizasse ainda mais para criar a tabela PhoneNumber sugerida. O pessoal prático consideraria seu projeto original perfeitamente aceitável. Estou no último campo.
Normalize até doer, desnormalize até dar certo .
Além do argumento fundamentado de Mark Storey-Smith e Damir Sudarevic, gostaria de acrescentar dois pontos que acho importante ter em mente.
Eu nunca digo nunca (bem, quase nunca)
Minha política sobre nunca é que, se foi imaginado, é inevitável em algum momento. Não acredite quando os usuários lhe disserem que algo nunca acontecerá. Para seus propósitos, isso significa que você precisa pensar sobre a probabilidade e a seriedade de uma mudança em seu design em relação aos números de telefone. Todo design é sobre fazer compromissos informados. Faça o que faz sentido, levando em consideração o risco envolvido caso os requisitos mudem.
A normalização é vital - a menos que não seja
A menos que você tenha um bom motivo para não fazê-lo, seu primeiro instinto deve ser sempre normalizar seu esquema. Isso ocorre porque a normalização é uma ótima regra prática para impedir que você crie problemas de consistência de big data e manutenção de código para si mesmo.
Há razões para desnormalizar. Um grande problema é relatar o desempenho ao ler dados estáticos. Outra razão pela qual você pode considerar a desnormalização é se os dados em questão não forem significativos para o seu sistema . O que quero dizer com isso? Os dados que precisam ser interpretados pelo seu sistema são significativos. Os dados que acompanham o passeio, mas não são lidos, manipulados ou interpretados pelo seu software, não são especialmente significativos. Dados que não são significativos são muito menos arriscados quando se trata de consistência.
Para fins práticos no seu caso, se o seu sistema usa números de telefone para um sistema IVR, isso é bastante significativo. Se, por outro lado, a única coisa para a qual os números de telefone serão usados é para um usuário lê-los na tela uma vez na lua azul, então talvez você possa se dar ao luxo de ser um pouco "desleixado".
O estranho é que você está vinculando esses telefones ao endereço, ao contrário do cliente. Portanto, se o endereço for conhecido, os telefones serão armazenados em uma tabela; caso contrário em outro lugar.
Então, se você acha que existem dois tipos de telefones -- um tipo pertence ao prédio e o outro ao cliente; então sua solução está OK.
Se você acha que um telefone pertence a um cliente (pessoa ou organização), provavelmente deveria reconsiderar.