Cette question montre que vous ne comprenez pas parfaitement les relations entre les entités (aucune impolitesse n'est prévue). Dont il existe quatre (techniquement seulement 3) types ci-dessous :
One to One One to Many Many to One Many to Many
En tête-à-tête (1:1) : Dans ce cas, un tableau a été divisé en deux parties afin de respecter la normalisation, ou plus généralement le principe ouvert fermé.
Normalisation Conformité :vous pouvez avoir une règle métier selon laquelle chaque client n'a qu'un seul compte. Techniquement, vous pourriez dans ce cas dire que le client et le compte pourraient tous être dans la même table, mais cela enfreint les règles de normalisation, donc vous les divisez et faites un 1:1.
Principe d'ouverture-fermeture conformité :une table de clients, peut avoir un identifiant, des noms et prénoms et une adresse. Plus tard, quelqu'un décide d'ajouter une date de naissance et avec elle la possibilité de calculer l'âge avec un tas d'autres champs indispensables. Il s'agit d'un exemple trop simplifié d'un à un, mais vous en obtenez l'utilisation principale pour étendre votre base de données sans casser le code existant. Une grande partie du code écrit (malheureusement) est étroitement liée à la base de données, de sorte que les changements dans la structure d'une table cassent le code. L'ajout d'un 1:1 comme celui-ci étendra le tableau pour répondre aux nouvelles exigences sans modifier l'original, permettant ainsi à l'ancien code de continuer à fonctionner normalement et au nouveau code d'utiliser les nouvelles fonctionnalités de la base de données.
L'inconvénient de la normalisation et de l'extension des tables utilisant des relations 1:1 de cette manière est la performance. Souvent, sur des systèmes très utilisés, la première cible pour augmenter les performances de la base de données est de dénormaliser et de combiner ces tables en une seule table, et d'optimiser les index, supprimant ainsi le besoin d'utiliser des jointures et de lire à partir de plusieurs tables. La normalisation / dénormalisation n'est ni une bonne ni une mauvaise chose, car cela dépend des besoins du système. La plupart des systèmes commencent généralement par revenir en arrière lorsque cela est nécessaire, mais ce changement doit être effectué avec beaucoup de soin, comme mentionné, si le code est étroitement couplé à la structure de la base de données, cela entraînera presque certainement l'échec du système. c'est-à-dire que lorsque vous combinez 2 tables, l'une cesse d'exister, tout le code qui inclut cette table désormais inexistante échoue jusqu'à ce qu'elle soit modifiée (en termes de base de données, imaginez connecter des relations à l'une des tables dans le 1:1, lorsque vous supprimez ces tables , cela rompt les relations et la structure doit donc être considérablement modifiée pour compenser. Malheureusement, de telles mauvaises conceptions sont beaucoup plus faciles à repérer dans le monde de la base de données que dans le monde du logiciel dans la plupart des cas et vous ne remarquez généralement pas que quelque chose s'est mal passé dans le code jusqu'à ce que tout s'effondre) à moins que le système ne soit correctement conçu avec séparation des préoccupations à l'esprit.
C'est ce qui se rapproche le plus de l'héritage dans la programmation orientée objet. Mais ce n'est pas tout à fait pareil.
Un à plusieurs (1:M) / Plusieurs à un (M:1) : Ces deux relations (c'est pourquoi 4 deviennent 3) sont les types de relations les plus populaires. Ils sont tous les deux du même type de relation, la seule chose qui change est votre point de vue. Un exemple Un client a plusieurs numéros de téléphone, ou alternativement, plusieurs numéros de téléphone peuvent appartenir à un client.
Dans la programmation orientée objet, cela serait considéré comme de la composition. Ce n'est pas un héritage, mais vous dites qu'un élément est composé de plusieurs parties. Ceci est généralement représenté par des tableaux / listes / collections, etc. à l'intérieur des classes, par opposition à une structure d'héritage.
Plusieurs à plusieurs (M:M): Ce type de relation avec la technologie actuelle est impossible. Pour cette raison, nous devons le décomposer en deux relations un à plusieurs avec une table "d'association" les joignant. Le côté plusieurs des deux relations un à plusieurs se trouve toujours dans la table des associations/liens.
Pour votre exemple, la personne qui a dit que vous avez besoin de plusieurs à plusieurs a raison. Parce qu'un deux à plusieurs est effectivement une relation plusieurs (c'est-à-dire plus d'un) à plusieurs. C'est la seule façon de faire fonctionner votre système. Sauf si vous avez l'intention de faire des recherches dans le domaine du calcul relationnel pour trouver un nouveau type de relation qui permettrait cela.
De plus, pour de telles relations (m2m), vous avez deux choix, soit créer une clé composée dans la table de l'éditeur de liens afin que la combinaison de champs devienne une entrée unique (si vous êtes intéressé par l'optimisation de la base de données, c'est le choix le plus lent, mais prend moins d'espace). Alternativement, vous créez un troisième champ avec une colonne d'identifiant générée automatiquement et en faites la clé primaire (pour l'optimisation de la base de données, c'est le choix le plus rapide, mais prend plus d'espace).
Dans votre exemple spécifiquement ci-dessus...
Il s'agirait d'une relation plusieurs à plusieurs avec la table des numéros de téléphone en tant que table de liaison entre les entreprises et les utilisateurs. Comme expliqué, pour vous assurer qu'aucun numéro de téléphone ne se répète, il vous suffit de le définir comme clé primaire ou d'utiliser une autre clé primaire et de définir le champ du numéro de téléphone sur unique.
Pour ce genre de questions, tout dépend de la façon dont vous les formulez. Qu'est-ce qui vous rend confus à ce sujet et comment vous surmontez cette confusion pour voir la solution est simple. Reformulez le problème comme suit. Commencez par demander si c'est un face à face, si la réponse est non, passez à autre chose. Demandez ensuite s'il s'agit d'un un à plusieurs, si la réponse est pas de mouvement. La seule autre option restante est plusieurs à plusieurs. Attention cependant, assurez-vous d'avoir bien réfléchi aux 2 premières questions avant de poursuivre. De nombreuses personnes inexpérimentées dans les bases de données compliquent souvent les problèmes en définissant un à plusieurs comme plusieurs à plusieurs. Encore une fois, le type de relation le plus populaire est de loin un à plusieurs (je dirais 90 %) avec le plusieurs à plusieurs et un à un se partageant les 10 % restants 7/3 respectivement. Mais ces chiffres ne sont que mon point de vue personnel, alors ne les citez pas comme des statistiques standard de l'industrie. Mon point est de s'assurer que ce n'est certainement pas un à plusieurs avant de choisir plusieurs à plusieurs. Cela en vaut la peine.
Alors maintenant, pour trouver la table de liaison entre les deux, décidez quelles sont vos tables principales et quels champs doivent être partagés entre elles. Dans ce cas, les tables entreprise et utilisateur doivent toutes deux partager le téléphone. En conséquence, vous devez créer une nouvelle table téléphonique comme lieur.
L'alarme d'avertissement de malentendu devrait s'afficher dès que vous décidez qu'aucun des 3 ne fonctionne pour vous. Cela devrait suffire à vous dire que vous ne formulez tout simplement pas correctement la question de la relation. Vous vous améliorerez au fil du temps, mais c'est une compétence essentielle et devrait vraiment être maîtrisée dès que possible pour votre propre santé.
Bien sûr, vous pouvez également accéder à une base de données orientée objet qui autorisera une gamme d'autres relations appelées relations "hiérarchiques". C'est très bien si vous envisagez de devenir programmeur aussi. Mais je ne le recommanderais pas car cela vous fera mal à la tête lorsque vous commencerez à trouver des moyens de combiner les différents types de relations. Surtout étant donné qu'il n'y a pas grand besoin puisque presque toutes les bases de données dans le monde se composent uniquement de ces 3 types de relations à moins qu'elles ne soient quelque chose de super spécial.
J'espère que c'était une réponse raisonnable. Merci d'avoir pris le temps de le lire.
