Esta pergunta mostra que você não entende completamente os relacionamentos de entidade (sem grosseria intencional). Dos quais existem quatro (tecnicamente apenas 3) tipos abaixo:
One to One One to Many Many to One Many to Many
Um para um (1:1): Neste caso, uma tabela foi dividida em duas partes para fins de conformidade com a normalização, ou mais geralmente o princípio aberto fechado.
Normalização conformidade:você pode ter uma regra de negócios de que cada cliente tenha apenas uma conta. Tecnicamente, neste caso, você poderia dizer que cliente e conta podem estar na mesma tabela, mas isso quebra as regras de normalização, então você os divide e faz um 1:1.
princípio de abrir-fechar compliance:Uma tabela de clientes, pode ter id, nome e sobrenome e endereço. Mais tarde, alguém decide adicionar uma data de nascimento e, com ela, a capacidade de calcular a idade junto com vários outros campos muito necessários. Este é um exemplo simplificado de um para um, mas você obtém o principal uso para estender seu banco de dados sem quebrar o código existente. Muito código escrito (infelizmente) é fortemente acoplado ao banco de dados, então mudanças na estrutura de uma tabela quebrarão o código. Adicionar um 1:1 como este estenderá a tabela para atender a novos requisitos sem modificar o original, permitindo assim que o código antigo continue funcionando normalmente e o novo código faça uso dos novos recursos do banco de dados.
A desvantagem da normalização e extensão de tabelas usando relacionamentos 1:1 dessa maneira é o desempenho. Muitas vezes, em sistemas muito usados, o primeiro objetivo para aumentar o desempenho do banco de dados é desnormalizar e combinar essas tabelas em uma única tabela e otimizar os índices, eliminando assim a necessidade de usar junções e ler várias tabelas. A normalização/desnormalização não é nem boa nem má, pois depende das necessidades do sistema. A maioria dos sistemas geralmente inicia a alteração normalizada de volta quando necessário, mas essa alteração precisa ser feita com muito cuidado, conforme mencionado, se o código estiver fortemente acoplado à estrutura do banco de dados, quase definitivamente fará com que o sistema falhe. ou seja, quando você combina 2 tabelas, uma deixa de existir, todo o código que inclui essa tabela agora inexistente falha até que seja modificada (em termos de banco de dados, imagine conectar relacionamentos a qualquer uma das tabelas no 1:1, quando você remover essas tabelas , isso quebra os relacionamentos e, portanto, a estrutura precisa ser bastante modificada para compensar. Infelizmente, esses designs ruins são muito mais fáceis de detectar no mundo do banco de dados do que no mundo do software na maioria dos casos e você geralmente não percebe que algo deu errado no código até que tudo desmorone), a menos que o sistema seja projetado adequadamente com separação de preocupações em mente.
É a coisa mais próxima que você pode obter de herança na programação orientada a objetos. Mas não é bem o mesmo.
Um para muitos (1:M) / Muitos para um (M:1): Esses dois relacionamentos (portanto, por que 4 se tornam 3) são os tipos de relacionamento mais populares. Ambos são o mesmo tipo de relacionamento, a única coisa que muda é o seu ponto de vista. Um exemplo Um cliente tem muitos números de telefone ou, alternativamente, muitos números de telefone podem pertencer a um cliente.
Na programação orientada a objetos isso seria considerado composição. Não é herança, mas você está dizendo que um item é composto de muitas partes. Isso geralmente é representado com arrays/listas/coleções etc. dentro de classes em oposição a uma estrutura de herança.
Muitos para muitos (M:M): Esse tipo de relação com a tecnologia atual é impossível. Por esse motivo, precisamos dividi-lo em dois relacionamentos de um para muitos com uma tabela de "associação" unindo-os. O lado muitos dos dois relacionamentos um para muitos está sempre na tabela de associação/link.
Para o seu exemplo, a pessoa que disse que você precisa de muitos para muitos está correta. Porque um dois para muitos é efetivamente um relacionamento de muitos (ou seja, mais de um) para muitos. Esta é a única maneira de fazer seu sistema funcionar. A menos que você pretenda pesquisar a área de cálculo relacional encontrar algum novo tipo de relacionamento que permitisse isso.
Também para esses relacionamentos (m2m) você tem duas opções, ou crie uma chave composta na tabela do vinculador para que a combinação de campos se torne uma entrada única (se você estiver interessado em otimização de banco de dados, esta é a escolha mais lenta, mas ocupa menos espaço). Como alternativa, você cria um terceiro campo com uma coluna de identificação gerada automaticamente e a torna a chave primária (para otimização de banco de dados, essa é a escolha mais rápida, mas ocupa mais espaço).
No seu exemplo especificamente acima ...
Esta seria uma relação de muitos para muitos com a tabela de números de telefone como a tabela do vinculador entre empresas e usuários. Conforme explicado, para garantir que nenhum número de telefone seja repetido, basta defini-lo como chave primária ou usar outra chave primária e definir o campo do número de telefone como exclusivo.
Para esse tipo de pergunta, depende realmente de como você as formula. O que está fazendo com que você fique confuso sobre isso e como você supera essa confusão para ver a solução é simples. Reformule o problema da seguinte forma. Comece perguntando se é um para um, se a resposta for não, siga em frente. A próxima pergunta é um para muitos, se a resposta for não, siga em frente. A única outra opção restante é muitos para muitos. Tenha cuidado, porém, certifique-se de ter considerado as 2 primeiras perguntas cuidadosamente antes de prosseguir. Muitas pessoas inexperientes em banco de dados muitas vezes complicam as questões definindo um para muitos como muitos para muitos. Mais uma vez, o tipo mais popular de relacionamento de longe é um para muitos (eu diria 90%) com muitos para muitos e um para um dividindo os 10% restantes 7/3 respectivamente. Mas esses números são apenas minha perspectiva pessoal, então não vá citá-los como estatísticas padrão da indústria. Meu ponto é ter certeza extra de que definitivamente não é um para muitos antes de escolher muitos para muitos. Vale a pena o esforço extra.
Agora, para encontrar a tabela do vinculador entre as duas, decida quais são suas tabelas principais e quais campos precisam ser compartilhados entre elas. Nesse caso, as tabelas da empresa e do usuário precisam compartilhar o telefone. Hense você precisa fazer uma nova tabela de telefone como o vinculador.
O alarme de aviso de mal-entendido deve aparecer assim que você decidir que nenhum dos 3 está funcionando para você. Isso deve ser suficiente para dizer que você simplesmente não está formulando a questão do relacionamento corretamente. Você vai melhorar com o passar do tempo, mas é uma habilidade essencial e deve ser dominada o mais rápido possível para sua própria sanidade.
Claro que você também pode ir para um banco de dados orientado a objetos que permitirá uma série de outros relacionamentos chamados relacionamentos "hierárquicos". Isso é ótimo se você está pensando em se tornar um programador também. Mas eu não recomendaria isso, pois vai fazer sua cabeça doer quando você começar a encontrar maneiras de combinar os vários tipos de relacionamentos. Especialmente porque não há muita necessidade, já que quase todos os bancos de dados do mundo consistem apenas nesses 3 tipos de relacionamentos, a menos que sejam algo super especial.
Espero que esta foi uma resposta razoável. Obrigado por tomar o tempo para lê-lo.
