Question Pourquoi utiliser une relation 1 pour 1 dans la conception de base de données?


J'ai du mal à essayer de déterminer quand utiliser une relation 1 à 1 dans la conception de la base de données ou si cela s'avère nécessaire.

Si vous ne pouvez sélectionner que les colonnes dont vous avez besoin dans une requête, il existe un point pour diviser une table en relations 1 à 1. Je suppose que la mise à jour d'une table volumineuse a plus d'impact sur les performances qu'une table plus petite et je suis sûr que cela dépend de la quantité de table utilisée pour certaines opérations (lecture / écriture).

Ainsi, lors de la conception d'un schéma de base de données, comment prenez-vous en compte les relations 1: 1? Quels critères utilisez-vous pour déterminer si vous en avez besoin, et quels sont les avantages de ne pas en utiliser?

Merci!


17
2018-03-13 16:25


origine


Réponses:


Du point de vue logique, une relation 1: 1 devrait toujours être fusionnée en une seule table.

D'un autre côté, il peut y avoir physique considérations pour tel "partitionnement vertical" ou "fractionnement de lignes", surtout si vous savez que vous aurez accès à certaines colonnes plus fréquemment ou de manière différente que les autres, par exemple:

  • Tu pourrais vouloir grappe ou cloison les deux tables "d'extrémité" d'une relation 1: 1 différemment.
  • Si votre SGBD le permet, vous souhaiterez peut-être les placer sur différents disques physiques (par exemple, davantage de performances critiques sur un disque SSD et l’autre sur un disque dur bon marché).
  • Vous avez mesuré l’effet sur la mise en cache et vous voulez vous assurer que les colonnes «chaudes» sont conservées dans le cache, sans que des colonnes «froides» le polluent.
  • Vous avez besoin d'un comportement de concurrence (tel que le verrouillage) qui soit "plus étroit" que la ligne entière. Ceci est hautement spécifique au SGBD.
  • Vous avez besoin de sécurité différente sur différentes colonnes, mais votre SGBD ne prend pas en charge les autorisations de niveau colonne.
  • Les déclencheurs sont généralement spécifiques à une table. Bien que vous puissiez théoriquement avoir une seule table et que le déclencheur ignore la "mauvaise moitié" de la ligne, certaines bases de données peuvent imposer des limites supplémentaires à ce qu'un déclencheur peut et ne peut pas faire. Par exemple, Oracle ne vous permet pas de modifier la table dite "mutante" à partir d’un déclencheur de niveau ligne - en ayant des tables séparées, une seule peut être en train de changer pour que vous puissiez toujours modifier l’autre à partir de votre trigger (mais d'autres moyens pour contourner cela).

Les bases de données sont très efficaces pour manipuler les données, donc je ne diviserais pas la table uniquement pour les performances de mise à jour, sauf si vous avez effectué les tests de performance réels sur des quantités représentatives de données et avez conclu que la différence de performances est réellement là et suffisamment importante (par exemple pour compenser le besoin accru de jointure).


D'un autre côté, si vous parlez de "1: 0 ou 1" (et pas un vrai 1: 1), c'est une question complètement différente, qui mérite une réponse différente ...


31
2018-03-13 16:52



Séparation des tâches et abstraction des tables de base de données.

Si j'ai un utilisateur et que je conçois le système pour que chaque utilisateur ait une adresse, mais que je change de système, il me suffit d'ajouter un nouvel enregistrement à la table Address au lieu d'ajouter un nouveau tableau et de migrer les données. .

MODIFIER

Actuellement, si vous souhaitez avoir un enregistrement personnel et que chaque personne possède exactement un enregistrement d'adresse, vous pouvez avoir une relation 1 à 1 entre une table Personne et une table Adresse ou vous pouvez simplement avoir une table Personne avec les colonnes pour l'adresse.

À l'avenir, vous avez peut-être décidé d'autoriser une personne à avoir plusieurs adresses. Vous n'auriez pas à modifier la structure de votre base de données dans le scénario de relation 1 pour 1, il vous suffit de modifier la manière dont vous gérez les données qui vous reviennent. Cependant, dans la structure de table unique, vous devez créer une nouvelle table et migrer les données d'adresse vers la nouvelle table afin de créer une structure de base de données de relation 1 à plusieurs.


8
2018-03-13 16:28



Eh bien, sur papier, la forme normalisée semble être la meilleure. Dans le monde réel, c'est généralement un compromis. La plupart des grands systèmes que je connais font des compromis et ne cherchent pas à être complètement normalisés.

Je vais essayer de donner un exemple. Si vous êtes dans une application bancaire, avec un compte de 10 millions de livrets, et les transactions habituelles seront juste une requête sur le dernier solde de certains comptes. Vous disposez de la table A qui stocke uniquement ces informations (numéro de compte, solde du compte et nom du titulaire du compte).

Votre compte dispose également de 40 autres attributs, tels que l'adresse du client, le numéro de TVA et l'identifiant pour la correspondance avec d'autres systèmes figurant dans le tableau B.

A et B ont un mappage un à un.

Pour pouvoir récupérer rapidement le solde du compte, vous pouvez utiliser différentes stratégies d'index (telles que l'index de hachage) pour la petite table qui a le nom et le solde du compte.

La table qui contient les 40 autres attributs peut résider dans un espace table ou un espace de stockage différent, utiliser un type d’indexation différent, par exemple parce que vous souhaitez les trier par nom, numéro de compte, identifiant de branche, etc. 40 attributs, tandis que vous avez besoin d'une récupération rapide de votre requête de solde de compte par numéro de compte.

Avoir tous les 43 attributs dans un tableau semble être naturel, et probablement «naturellement lent» et inacceptable pour la récupération du solde d'un compte unique.


4
2018-03-13 16:38



Il est logique d'utiliser des relations 1-1 pour modéliser une entité dans le monde réel. De cette manière, lorsque davantage d’entités sont ajoutées à votre «monde», elles doivent uniquement se rapporter aux données auxquelles elles se rapportent (et pas plus).

C'est la clé, vos données (chaque table) ne doivent contenir que suffisamment de données pour décrire la chose réelle qu'elle représente et pas plus. Il ne devrait pas y avoir de champs redondants, car tout a un sens en termes de "chose". Cela signifie que moins de données sont répétées à travers le système (avec les problèmes de mise à jour que cela entraînerait!) Et que vous pouvez récupérer des données individuelles indépendamment (pas besoin de diviser / analyser les chaînes par exemple).

Pour savoir comment faire cela, vous devez rechercher "Normalisation de la base de données" (ou normalisation), "Forme normale" et "première, deuxième et troisième formes normales". Ceci décrit comment décomposer vos données. Une version avec un exemple est toujours utile. Peut-être essayer ceci Didacticiel.


3
2018-03-13 16:33



Quelques exemples de projets passés:

  • une table TestRequests ne peut avoir qu'un seul rapport correspondant. Mais selon la nature de la demande, les champs du rapport peuvent être totalement différents.
  • Dans un projet bancaire, une table Entités comprend différents types d'entités: Fonds, RealEstateProperties, Companies. La plupart de ces entités ont des propriétés similaires, mais les fonds exigent environ 120 champs supplémentaires, alors qu'ils ne représentent que 5% des enregistrements.

0
2018-03-13 16:54



Souvent, les gens parlent d'une relation 1: 0..1 et l'appellent 1: 1. En réalité, un SGBDR typique ne peut en aucun cas prendre en charge une relation 1: 1 littérale.

En tant que tel, je pense qu'il est juste de parler de sous-classement ici, même si cela nécessite techniquement une relation 1: 0..1, et non le concept littéral de 1: 1.

Un 1: 0..1 est très utile lorsque vous avez des champs qui seraient exactement les mêmes entre plusieurs entités / tables. Par exemple, les champs d'informations de contact tels que l'adresse, le numéro de téléphone, le courrier électronique, etc., qui pourraient être communs aux employés et aux clients, pourraient être divisés en une entité créée uniquement pour les informations de contact.

Une table de contacts contiendrait des informations communes, telles que l'adresse et le numéro de téléphone.

Ainsi, une table d'employés contient des informations spécifiques sur les employés, telles que le numéro d'employé, la date d'embauche, etc. Il aurait également une référence de clé étrangère à la table de contact pour les informations de contact de l'employé.

Une table client contiendrait des informations sur le client, telles qu'une adresse électronique, son nom d'employeur et peut-être certaines données démographiques telles que le sexe et / ou l'état matrimonial. Le client aurait également une référence de clé étrangère à la table de contact pour ses informations de contact.

Ce faisant, chaque employé aurait un contact, mais chaque contact n'aurait pas un employé. Le même concept s'appliquerait aux clients.


0
2017-11-10 02:12