Y at-il eu un moment où l'aide d'une base de données 1: 1 relation logique?

https://stackoverflow.com/questions/517417

21-08-2019
|

Question

Je pensais l'autre jour sur la normalisation, et il me vint, je ne peux pas penser à un moment où il devrait y avoir un 1: 1. Relation dans une base de données

Nom: SSN? Je les ai dans la même table PersonID: AddressID? Encore une fois, même table.

Je peux venir avec des exemples zillion de 1: plusieurs ou plusieurs: plusieurs (avec des tables intermédiaires appropriées), mais jamais 1: 1.

Suis-je manque quelque chose d'évident?

La solution

A 1: 1 relation indique généralement que vous avez partagé une entité plus grande pour une raison quelconque. Il est souvent pour des raisons de performance dans le schéma physique, mais il peut arriver dans le côté logique et si une grande partie des données devrait être « inconnu » en même temps (dans ce cas, vous avez un 1: 0 ou 1: 1., mais pas plus)

À titre d'exemple d'une partition logique: vous avez des données sur un employé, mais il y a un plus grand ensemble de données qui doivent être collectées, si et seulement s'ils choisissent d'avoir une couverture santé. Je garderais les données démographiques relatives à la couverture de la santé dans une autre table à la fois donner plus facile le partitionnement de sécurité et d'éviter le transport de ces données autour de requêtes non liées à l'assurance.

Un exemple d'une partition physique seraient les mêmes données hébergées sur plusieurs serveurs. Je peux conserver les données démographiques de couverture de santé dans un autre Etat (où le bureau des ressources humaines est, par exemple) et la base de données primaire ne peut créer un lien vers via un serveur lié ... en évitant la réplication des données sensibles à d'autres endroits, mais le rendant disponible pour (en supposant ici rare) les requêtes qui ont besoin.

partitionnement physique peut être utile lorsque vous avez des questions qui ont besoin des sous-ensembles cohérents d'une entité plus grande.

Autres conseils

L'une des raisons est l'efficacité de la base de données. Avoir une relation 1: 1 permet de diviser les champs qui seront affectés au cours d'une serrure ligne / table. Si le tableau A a une tonne de mises à jour et le tableau b a une tonne de lit (ou a une tonne de mises à jour d'une autre application), puis le verrouillage de la table A n'affectera pas ce qui se passe dans le tableau B.

D'autres apportent un bon point. La sécurité peut aussi être une bonne raison en fonction de la façon dont les applications etc. arrivent sur le système. Je tendance à adopter une approche différente, mais il peut être un moyen facile de restreindre l'accès à certaines données. Il est vraiment facile de refuser tout accès à une certaine table dans une pincée.

Mon entrée de blog à ce sujet.

sparseness. La relation de données peut être techniquement 1: 1, mais les lignes correspondantes ne pas exister pour chaque ligne. Donc, si vous avez vingt millions de lignes et il y a un certain ensemble de valeurs qui n'existe que pour 0,5% d'entre eux, les économies d'espace sont vastes si vous appuyez sur ces colonnes sur dans une table qui peut être faible densité de population.

La plupart des réponses de haut gradés donnent des raisons très d'accord et d'optimisation base de données utiles pour 1: 1 relations, mais je veux me concentrer sur rien « dans la nature » des exemples où 1:. 1 relations se produisent naturellement

S'il vous plaît noter une caractéristique importante de la mise en œuvre de la base de données de la plupart de ces exemples: aucune information historique est conservé sur le rapport 1: 1. Autrement dit, ces relations sont 1: 1 à un moment donné dans le temps. Si le concepteur de base de données veut enregistrer les changements dans les participants de la relation au fil du temps, alors les relations deviennent 1: M ou M: M; ils perdent leur 1: 1 nature. Avec ce compris, va ici:

"Est-A" ou supertype / sous-type ou des relations d'héritage / classification : Cette catégorie est quand une entité est un type spécifique d'une autre entité. Par exemple, il pourrait y avoir une entité des employés avec des attributs qui s'appliquent à tous les employés, puis les différentes entités pour indiquer des types spécifiques d'employés avec des attributs propres à ce type d'employé, par exemple Docteur, comptable, pilote, etc. Cette conception évite plusieurs puisque de nombreux employés nulls ne les attributs spécialisés d'un sous-type spécifique. D'autres exemples dans cette catégorie peuvent être produits comme supertype et ManufacturingProduct et MaintenanceSupply comme sous-types; Animal et supertype pour chiens et chats comme les sous-types; etc. Notez que chaque fois que vous essayez de mapper une hiérarchie d'héritage orienté objet dans une base de données relationnelle (comme dans un modèle objet-relationnel), c'est le genre de relation qui représente de tels scénarios.
relations « Boss » , comme gérant, président, président, etc., où une unité d'organisation ne peut avoir qu'un seul patron, et une personne peut être patron d'une seule unité d'organisation . Si ces règles sont applicables, alors vous avez une relation 1: 1, comme un directeur d'un département, un PDG d'une entreprise, etc. relations « patron » ne sont pas applicables uniquement aux personnes. Le même genre de relation se produit s'il n'y a qu'un seul magasin comme le siège d'une entreprise, ou si une seule ville est la capitale d'un pays, par exemple.
Certains types d'allocation des ressources rares , par exemple un employé peut être attribué qu'une seule voiture de société à un moment (par exemple un camion par camionneur, un taxi, par chauffeur de taxi, etc.). Un collègue m'a donné cet exemple récemment.
Mariage (au moins dans les juridictions où la polygamie est juridiques illégale): une personne peut être marié à une seule autre personne à la fois. Je suis cet exemple d'un manuel qui a utilisé cela comme un exemple de 1: 1. Relation unaire lorsqu'une entreprise enregistre des mariages entre ses employés
Réservations Matching : lorsqu'une réserve unique est faite et remplie comme deux entités distinctes. Par exemple, un système de location de voitures peut enregistrer une réservation en une seule entité, puis une location réelle dans une entité séparée. Bien qu'une telle situation pourrait également être conçue comme une seule entité, il peut être judicieux de séparer les entités puisque toutes les réserves sont remplies, et non toutes les locations exigent des réservations, et les deux situations sont très fréquentes.

Je répète la mise en garde que je disais plus tôt que la plupart d'entre eux sont 1: 1 relations que si aucune information historique est enregistrée. Donc, si un employé change leur rôle dans une organisation ou un gestionnaire assume la responsabilité d'un autre département ou un employé est réaffecté un véhicule ou une personne est devenue veuve et remarie, alors les participants des relations peuvent changer. Si la base de données ne stocke aucune histoire antérieure sur ces 1: 1 relations, ils demeurent légitimes 1: 1 relations. Mais si la base de données enregistre des informations historiques (telles que l'ajout des dates de début et de fin de chaque relation), puis ils à peu près tous les transforment en M:. Relations M

Il y a deux exceptions notables àla note historique: Tout d'abord, certaines relations changent si rarement que des informations historiques ne serait normalement pas être stocké. Par exemple, la plupart IS-A des relations (par exemple type de produit) sont immuables; à savoir, ils ne peuvent jamais changer. Ainsi, le point d'enregistrement historique est sans objet; ceux-ci seraient toujours mises en œuvre comme naturelles 1: 1 relations. En second lieu, le magasin de relation réservation dates de location séparément, depuis la réservation et la location sont des événements indépendants, chacun avec leurs propres dates. Étant donné que les entités ont leurs propres dates, plutôt que le 1: 1 relation elle-même ayant une date de début, ceux-ci demeureraient comme 1:. 1 relations, même si les données historiques sont stockées

Votre question peut être interprétée de plusieurs façons, en raison de la façon dont vous LIBELLEES il. Les réponses montrent.

Il peut certainement être 1: 1 relations entre les éléments de données dans le monde réel. Aucune question à ce sujet. La relation « est un » est généralement un à un. Une voiture est un véhicule. Une voiture est un véhicule. Un véhicule peut être une voiture. Certains véhicules sont des camions, dans ce cas, un véhicule n'est pas une voiture. Plusieurs réponses abordent cette interprétation.

Mais je pense vraiment ce que vous demandez est ... quand 1: 1 relations existent, doivent être divisés tables jamais? En d'autres termes, si vous avez toujours deux tables qui contiennent exactement les mêmes clés? Dans la pratique, la plupart d'entre nous Analysons que les clés primaires, et pas les autres candidats clés, mais cette question est légèrement diferent.

Les règles de normalisation pour 1NF, 2NF et 3NF jamais besoin de décomposition (séparation) une table en deux tables avec la même clé primaire. Je n'ai pas élaboré si mettre un schéma dans BCNF, 4NF ou 5NF peut toujours donner lieu à deux tables avec les mêmes touches. Du haut de ma tête, je vais deviner que la réponse est non.

Il y a un niveau de normalisation appelé 6NF. La règle de normalisation pour 6NF peut certainement entraîner deux tables avec la même clé primaire. 6NF a l'avantage sur 5NF que NULLS peuvent être complètement évités. Ceci est important pour certains, mais pas tous, les concepteurs de bases de données. Je ne l'ai jamais pris la peine de mettre un schéma dans 6NF.

Dans 6NF les données manquantes peuvent être représenter par une ligne omis, au lieu d'une ligne avec une valeur NULL dans une colonne.

Il y a des raisons autres que la normalisation pour les tables de fractionnement. Parfois, les tableaux fractionnés donnent lieu à de meilleures performances. Avec certains moteurs de base de données, vous pouvez obtenir les mêmes performances en divisant la table au lieu de diviser réellement. Cela peut avoir l'avantage de garder la conception logique facile à comprendre, tout en donnant le moteur de base de données les outils nécessaires pour accélérer les choses.

Je les utilise principalement pour quelques raisons. L'une est de différence significative dans le taux de variation des données. Certains de mes tableaux peuvent avoir des pistes de vérification où je suivi des versions précédentes de dossiers, si je me soucie seulement de suivre les versions précédentes de 5 sur 10 colonnes fractionnement de ces 5 colonnes sur une table séparée avec un mécanisme de piste d'audit, il est plus efficace. De plus, je peux avoir des documents (pour dire une application comptable) qui sont en écriture seule. Vous ne pouvez pas modifier les montants en dollars, ou le compte qu'ils étaient pour, si vous avez fait une erreur, alors vous devez faire un enregistrement correspondant à écrire ajuster officieusement incorrect, puis créer une entrée de correction. Je contraintes sur la table application du fait qu'ils ne peuvent pas être mis à jour ou supprimés, mais je peux avoir quelques attributs pour cet objet qui sont malléables, ceux-ci sont conservés dans une table séparée sans restriction sur la modification. Une autre fois que je fais est dans les applications de dossiers médicaux. Il y a des données relatives à une visite qui ne peut être changé une fois qu'il est signé sur, et d'autres données relatives à une visite qui peut être changé après SIGNOFF. Dans ce cas, je vais partager les données et de mettre un déclencheur sur la table verrouillée rejetant les mises à jour à la table verrouillée lorsque signés, mais permettant des mises à jour aux données du médecin ne sont pas en train de signer sur.

Une autre affiche a commenté 1: 1 ne pas être normalisée, je suis en désaccord avec que dans certaines situations, en particulier le sous-typage. Dire que j'ai une table des employés et la clé primaire est leur SSN (c'est un exemple, sauvons le débat sur si cela est une bonne clé ou non pour un autre thread). Les employés peuvent être de différents types, dire et temporaire ou permanente si elles sont permanentes ils ont plus de champs à remplir, comme le numéro de téléphone de bureau, qui ne devrait pas être NULL si le type = « permanent ». Dans une 3ème base de données de forme normale de la colonne doit dépendre uniquement de la clé, ce qui signifie que l'employé, mais cela dépend en fait de l'employé et le type, donc une relation 1: 1 est tout à fait normal, et souhaitable dans ce cas. Il empêche également les tables trop rares, si j'ai 10 colonnes qui sont normalement remplies, mais 20 colonnes supplémentaires que pour certains types.

Le scénario le plus courant que je peux penser est quand vous avez BLOB. Disons que vous voulez stocker de grandes images dans une base de données (généralement, pas la meilleure façon de les stocker, mais parfois les contraintes rendent plus pratique). Vous voulez généralement le blob d'être dans un tableau distinct pour améliorer les données des recherches non blob.

En ce qui concerne la science pure, oui, ils sont inutiles.

Dans les bases de données réelles, il est parfois utile de garder un champ rarement utilisé dans une table distincte: pour accélérer les requêtes en utilisant cela, et seulement ce domaine; pour éviter les serrures, etc.

Au lieu d'utiliser des vues pour limiter l'accès aux champs, il est parfois judicieux de garder des champs restreints dans une table séparée à laquelle ont accès à certains utilisateurs.

Je peux aussi penser à des situations où vous avez un modèle OO dans lequel vous utilisez l'héritage et l'arbre d'héritage doit être persisté à la DB.

Par exemple, vous avez un oiseau de classe et de poissons qui héritent de l'animal. Dans votre DB, vous pourriez avoir une table « animale », qui contient les champs communs de la classe des animaux, et la table des animaux a une à une relation avec la table des oiseaux, et une à une relation avec le poisson table.

Dans ce cas, vous ne devez pas avoir une table animale qui contient beaucoup de colonnes nullables pour tenir les propriétés de poissons d'oiseaux et où toutes les colonnes qui contiennent des données de poissons-sont définies à NULL lorsque l'enregistrement représente un oiseau.

, vous avez lieu un enregistrement dans les oiseaux-table qui a une à une relation avec l'enregistrement de la table des animaux.

1-1 Les relations sont également nécessaires si vous avez trop d'informations. Il y a une limitation de la taille d'enregistrement de chaque enregistrement de la table. Parfois, les tableaux sont divisés en deux (avec les informations les plus fréquemment interrogé dans le tableau principal) juste pour que la taille de l'enregistrement ne sera pas trop grand. Les bases de données sont également plus efficaces dans l'interrogation si les tables sont étroites.

Il est aussi un moyen d'étendre une table qui est déjà en production avec moins (perçue) risque qu'un changement de base de données « réel ». Voyant 1:. 1 relation dans un système existant est souvent un bon indicateur que les champs ont été ajoutés après la conception initiale

Dans SQL, il est impossible d'appliquer une relation 1: 1 entre les deux tables qui est obligatoire sur les deux côtés (à moins que les tables sont en lecture seule). À toutes fins utiles "1: 1" relation dans SQL signifie vraiment 1: 0 | 1

L'incapacité à soutenir cardinalité obligatoire dans les contraintes référentielles est l'une des limitations graves de SQL. contraintes « reportables » ne comptent pas vraiment parce qu'ils sont juste une façon de dire la contrainte ne soit pas appliquée de temps en temps.

Si vous utilisez les données avec l'un des ORM populaires, vous voudrez peut-être briser une table en plusieurs tables pour correspondre à votre hiérarchie d'objets.

J'ai trouvé que quand je fais un 1: 1. Relation totalement son pour une raison systémique, pas une raison relationnelle

Par exemple, j'ai trouvé que mettre les aspects réservés d'un utilisateur dans 1 table et de mettre l'utilisateur des champs modifiables de l'utilisateur dans une autre table permet d'écrire logiquement les règles sur les autorisations sur ces champs beaucoup beaucoup plus facile.

Mais vous avez raison, en théorie, 1: 1 relations sont complètement artificiel, et sont presque un phénomène. Cependant logiquement permet aux programmes et optimisations abstraire la base de données plus facile.

La plupart du temps, les dessins sont considérés comme 1: 1 jusqu'à ce que quelqu'un demande « bien, pourquoi ne peut-il être 1: beaucoup »? Les concepts Divorcing les uns des autres se fait prématurément en prévision de ce scénario commun. Personne et adresse ne se lient pas si bien. Beaucoup de gens ont plusieurs adresses. Et ainsi de suite ...

Habituellement, deux espaces d'objets distincts impliquent que l'un ou les deux peuvent être multipliées (x: nombre). Si deux objets étaient vraiment, vraiment 1: 1, même philosophiquement, il est plus d'un est-relation. Ces deux « objets » sont en fait des parties d'un objet entier.

des données étendues qui est nécessaire que dans certains scénarios. dans les applications existantes et les langages de programmation (comme RPG) où les programmes sont compilés sur les tables (donc si la table que vous avez change recompiler le programme (s)). Tag le long de fichiers peut également être utile dans les cas où vous avez à vous soucier de la taille de la table.

Le plus souvent, il est plus d'un physique que la construction logique. Il est couramment utilisé pour diviser verticalement une table pour tirer parti de la division E / S sur les périphériques physiques ou d'autres optimisations de requêtes associées à la ségrégation des données moins fréquemment consultées ou les données qui doivent être conservés plus sûr que le reste des attributs sur le même objet (SSN, salaires, etc).

La seule considération logique qui prescrit une relation 1-1 est lorsque certains attributs ne concernent que certaines des entités. Cependant, dans la plupart des cas, il y a une meilleure / façon plus normalisée pour modéliser les données par extraction d'entités.

La meilleure raison pour laquelle je peux voir pour 1: relation 1 est un sous-supertype de la conception de base de données. J'ai créé une structure de données Real Estate MLS basé sur ce modèle. Il y avait cinq sources de données différentes; Résidentiel, commercial, multifamilial, Hotels & Land.

J'ai créé une propriété appelée supertype qui contenait des données qui était commun à chacune des cinq sources de données séparées. Cela a permis très rapidement des recherches « simples » à travers tous les types de données.

créer cinq sous-types distincts stockés les éléments de données uniques pour chacune des cinq flux de données. Chaque enregistrement Supertype avait 1: 1. Relation avec le dossier SubType approprié

Si un client voulait une recherche détaillée, ils devaient choisir un type Super-Sub par exemple PropertyResidential.

A mon avis, une relation 1: 1 associe un héritage de classe sur un SGBDR. Il y a une table A qui contient les attributs communs, à savoir le statut de classe partent Chaque état de la classe héritée est mappé sur le SGBDR avec une table B avec une relation 1: 1 à une table, contenant les attributs spécialisés. Le tableau namend A contient également un champ « type » qui représente la fonctionnalité « casting »

Au revoir Mario

1: 1 relations ne font pas vraiment de sens si vous êtes dans la normalisation comme tout ce qui serait 1: 1. Serait conservé dans la même table

Dans le monde réel cependant, il est souvent différent. Vous pouvez diviser vos données pour correspondre à l'interface des applications.

Peut-être si vous avez une sorte d'objets typés dans votre base de données.

dire dans une table, T1, vous avez les colonnes C1, C2, C3 ... avec une une à une relation. Il est OK, il est sous forme normalisée. Maintenant, dire dans un T2 de table, vous avez des colonnes C1, C2, C3, ... (les noms peuvent différer, mais les types et dire le rôle est le même) avec une une à une relation aussi. Il est OK pour T2 pour les mêmes raisons que dans le T1.

Dans ce cas cependant, je vois un ajustement pour une table T3 distinct, de maintien C1, C2, C3 ... et une pour une relation de T1 à T3 et de T2 à T3. Je vois encore plus un ajustement s'il existe une autre table, avec laquelle il existe déjà un à plusieurs C1, C2, C3 ... dire à partir du tableau A à plusieurs lignes dans le tableau B. Ensuite, au lieu de T3, vous utilisez B, et ont une à une relation de T1 à B, la même pour de T2 à B, et toujours le même pour une relation multiple de a à B.

Je crois que la normalisation ne sont pas d'accord avec cela, et peut-être une idée en dehors de celui-ci: l'identification des types d'objets et déplacer des objets d'un même type à leur pool de stockage, en utilisant un pour un rapport de quelques tables, et un à plusieurs rapport de quelques autres tables.

Vous pouvez créer un à une table de relation, s'il y a un avantage de performance significative. Vous pouvez mettre les champs rarement utilisés dans la table séparée.

Il est inutile grand pour des raisons de sécurité, mais il de meilleures façons d'effectuer des contrôles de sécurité. Imaginez, vous créez une clé qui ne peut ouvrir une porte. Si la clé peut ouvrir une autre porte, vous devez sonner l'alarme. Essentiellement, vous pouvez avoir « CitizenTable » et « VotingTable ». Citoyen Un vote pour un candidat qui est stocké dans la table de vote. Si un citoyen apparaît dans la table de vote à nouveau, leur devrait être une alarme. Soyez des conseils, c'est une relation biunivoque parce que nous ne référant au champ candidat, nous référenceurs à la table de vote et la table des citoyens.

Exemple:

 Citizen Table
 id = 1, citizen_name = "EvryBod"
 id = 2, citizen_name = "Lesly"
 id = 3, citizen_name = "Wasserman"

 Candidate Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"

Ensuite, si l'on voit la table de vote comme ceci:

 Voting Table
 id = 1, citizen_id = 1, candidate_name = "Bern Nie"
 id = 2, citizen_id = 2, candidate_name = "Bern Nie"
 id = 3, citizen_id = 3, candidate_name = "Hill Arry"
 id = 4, citizen_id = 3, candidate_name = "Hill Arry"
 id = 5, citizen_id = 3, candidate_name = "Hill Arry"

On peut dire que nombre de citoyens 3 est un pantalon de menteur sur le feu qui ont triché Berne Nie. Juste un exemple.

Partout étaient deux entités entièrement indépendantes partagent une à une relation. Il doit y avoir beaucoup d'exemples:

personne <-> dentiste (! Son 1: N, de sorte que son mauvais)

personne <-> médecin (! Son 1: N, il est également faux)

personne <-> conjoint (! Son 1: 0 | 1, il est donc souvent mal)

EDIT: Oui, ce sont des exemples assez mauvais, surtout si je cherchais toujours un 1: 1, pas 0 ou 1 de chaque côté. Je suppose que mon cerveau était mal mise à feu: -)

Alors, je vais essayer à nouveau. Il se trouve, après un peu de réflexion, que la seule façon que vous pouvez avoir deux entités distinctes qui doivent (dans la mesure où le logiciel va) être ensemble tout le temps est pour eux d'exister ensemble dans la catégorisation plus. Ensuite, si et seulement si vous tombez dans une décomposition plus faible, les choses sont et devraient être séparés, mais au niveau plus élevé qu'ils ne peuvent pas vivre sans l'autre. Contexte, puis est la clé.

Pour une base de données médicales, vous pouvez stocker différentes informations sur des régions spécifiques du corps, en les gardant comme une entité distincte. Dans ce cas, un patient a une seule tête, et ils ont besoin d'avoir, ou ils ne sont pas un patient. (Ils ont aussi un cœur, et un certain nombre d'autres organes individuels nécessaires). Si vous êtes intéressé par le suivi des interventions chirurgicales par exemple, chaque région doit être une entité distincte unique.

Dans un système de production / inventaire, si vous effectuez le suivi de l'ensemble des véhicules, alors vous avez certainement envie de regarder les progrès du moteur différemment de la carrosserie de la voiture, mais il y a une relation biunivoque. Un soin doit avoir un moteur, et un seul (ou il ne serait pas une « voiture » plus). Un moteur appartient à une seule voiture.

Dans chaque cas, vous pouvez produire les entités distinctes comme un grand disque, mais étant donné le niveau de décomposition, ce serait faux. Ils sont, dans ces contextes spécifiques, des entités véritablement indépendants, bien qu'ils pourraient ne pas paraître à un niveau supérieur.

Paul.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow