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

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 le système, tout ce que j'ai à faire est d'ajouter un nouvel enregistrement à la table D'adresses au lieu d'ajouter une toute nouvelle table et de migrer les données.

EDIT

actuellement en ce moment si vous voulez avoir un dossier de personne et chaque personne a exactement un dossier d'adresse, alors vous pourriez avoir une relation 1-à-1 entre une table-personne et une table D'adresse ou vous pourriez juste avoir une table-personne qui avait aussi les colonnes pour l'adresse.

Dans l'avenir, peut-être que vous avez pris la décision de permettre à une personne d'avoir plusieurs adresses. Vous n'auriez pas à changer la structure de votre base de données dans le scénario de la relation de 1 à 1, vous n'avez qu'à changer la façon dont vous manipulez les données qui vous reviennent. Cependant, dans la structure de table unique, vous devrez créer une nouvelle table et migrer les données d'adresse pour la nouvelle table afin de créer une meilleure pratique de 1 à plusieurs relations structure de base de données.

Bien, sur le papier, forme normalisée semble être le meilleur. Dans le monde réel, il est généralement un compromis. La plupart des grands systèmes que je connais font des compromis et n'essaient pas d'être complètement normalisés.

je vais essayer de donner un exemple. Si vous êtes dans une application bancaire, avec 10 millions de Compte passbook, et les transactions habituelles seront juste une requête du dernier solde de certains compte. Vous avez le tableau A qui stocke seulement ces informations (numéro de Compte, solde du compte, et compte nom du titulaire).

votre compte a également 40 autres attributs, tels que l'adresse du client, le numéro de taxe, id pour la correspondance à d'autres systèmes qui est dans le tableau B.

A et B ont un à un mappage.

afin de pouvoir récupérer rapidement le solde du compte, vous pouvez utiliser une stratégie d'index différente (comme l'index de hachage) pour la petite table qui a le solde du compte et le nom du titulaire du compte.

la table qui contient les autres 40 les attributs peuvent résider dans un espace de table ou de stockage différent, employer un type différent d'indexation, par exemple parce que vous voulez les Trier par nom, numéro de compte, ID de branche, etc. Votre système peut tolérer la récupération lente de ces 40 attributs, alors que vous avez besoin de récupération rapide de votre solde de Compte requête par numéro de Compte.

avoir tous les 43 attributs dans une table semble être naturel, et probablement 'naturellement lent' et inacceptable pour simplement récupérer un compte simple équilibre.

Il est logique d'utiliser 1-1 relations de modèle d'une entité dans le monde réel. De cette façon, lorsque plus d'entités sont ajoutées à votre "monde", elles ne doivent se rapporter qu'aux données auxquelles elles se rapportent (et pas plus).

c'est la clé vraiment, vos données (chaque tableau) ne devraient contenir que suffisamment de données pour décrire la chose réelle qu'elles représentent et rien de plus. Il ne devrait pas être redondants comme tous les sens en termes de la "chose". Cela signifie que moins de données sont répétées à travers le système (avec les problèmes de mise à jour qui apporteraient!) et que vous pouvez récupérer des données individuelles indépendamment (pas besoin de séparer/ analyser les chaînes par exemple).

pour trouver comment faire cela, vous devriez rechercher" Normalisation de base de données "(ou normalisation)," forme normale "et"première, deuxième et troisième forme normale". Ceci décrit comment décomposer vos données. Une version avec un exemple est toujours utile. Essayez peut-être de ce tutoriel.

Juste quelques exemples de projets antérieurs:

• une table de test 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 Entities contient différents types d'entités: Fonds, propriétés immobilières, sociétés. La plupart de ces entités ont des propriétés similaires, mais les fonds nécessitent environ 120 champs supplémentaires, alors qu'ils ne représentent que 5% de la dossier.

souvent les gens parlent d'un 1: 0..1 relation et appelez ça un 1:1. En réalité, un SGBDR typique ne peut pas supporter une relation littérale 1:1 dans tous les cas.

en tant que tel, je pense qu'il est juste d'aborder la sous-classification ici, même si cela nécessite techniquement un 1:0..1 relation, et non le concept littéral d'un 1:1.

1:0..1 est très utile quand vous avez des champs qui seraient exactement les mêmes parmi plusieurs entities/tables. Par exemple, contact champs d'information tels que l'adresse, le numéro de téléphone, le courriel, etc. cela pourrait être commun à la fois pour les employés et les clients pourrait être divisé en une entité faite purement pour les informations de contact.

une table de contact contiendrait des renseignements communs, comme l'adresse et le(S) Numéro (s) de téléphone.

ainsi, une table d'employés contient des renseignements propres à l'employé, comme le numéro de l'employé, la date d'embauche, etc. Elle aurait aussi une référence de clé étrangère de la table contact de l'employé à la contacter info.

une table de clients contiendrait des renseignements sur les clients, comme une adresse électronique, le nom de leur employeur et peut-être certaines données démographiques comme le sexe et/ou l'état matrimonial. Le client aurait aussi une référence de clé étrangère à la table de contact pour ses coordonnées.

ce faisant, chaque employé aurait une personne-ressource, mais chaque personne-ressource n'aurait pas d'employé. Le même concept s'appliquerait aux clients.