Je pensais l’autre jour sur la normalisation, et il vint à moi, je ne peux pas penser un moment où il devrait y avoir une relation 1:1 dans une base de données.
Nom : SSN ? J’aurais eux dans la même table PersonID:AddressID ? Encore une fois, même table.
Je peux trouver un zillion exemples de 1:many ou plusieurs : plusieurs (avec les tables intermédiaires appropriés), mais jamais un 1:1.
Ai-je raté quelque chose d’évident ?
Une relation 1:1 indique généralement que vous avez partitionné une entité plus grande pour une raison quelconque. Souvent c'est à cause de raisons de performances dans le schéma physique, mais il peut arriver dans la logique que si une grande partie des données devrait être "inconnu" dans le même temps (dans ce cas, vous avez un 1:0 ou 1:1, mais pas plus).
Comme exemple d'une partition logique: vous avez des données à propos d'un employé, mais il y a un plus grand ensemble de données qui doivent être recueillies, si et seulement si ils choisissent d'avoir une couverture de santé. Je voudrais garder les données démographiques relatives à l'assurance de santé dans une table différente à la fois de faciliter la sécurité et de partitionnement pour éviter que transport de données dans les requêtes non liées à l'assurance.
Un exemple d'une partition physique seraient les mêmes données hébergées sur des serveurs multiples. Je peut garder la couverture de santé données démographiques dans un autre état (où le bureau des RH, par exemple) et de la base de données primaire ne peut faire un lien via un serveur lié... éviter la réplication des données sensibles à d'autres endroits, mais en le rendant accessible (en supposant ici rare) les requêtes qui en ont besoin.
Physique de partitionnement peut être utile lorsque vous avez des requêtes qui ont besoin des sous-ensembles d'une entité plus grande.
Une des raisons est la base de données d'efficacité. Avoir une relation 1:1 permet de séparer les domaines qui seront touchés au cours d'une ligne/verrou de table. Si la table a une tonne de mises à jour et le tableau b a une tonne de lit (ou a une tonne de mises à jour à partir d'une autre application), puis Une table de blocage n'affectera pas ce qu'il se passe dans le tableau B.
D'autres apportent un bon point. La sécurité peut aussi être une bonne raison, selon la façon dont les applications etc. sur le système. J'aurais tendance à prendre une approche différente, mais il peut être un moyen facile de restreindre l'accès à certaines données. Il est très facile de simplement refuser l'accès à une table dans un pincement.
La densité La relation de données peut être techniquement 1: 1, mais les lignes correspondantes ne doivent pas exister pour chaque ligne. Donc, si vous avez vingt millions de lignes et que certaines valeurs n'existent que pour 0,5% d'entre elles, les économies d'espace sont considérables si vous placez ces colonnes dans une table à faible densité de population.
Votre question peut être interprété de plusieurs façons, en raison de la façon dont vous avez formulé. Les réponses montrent.
Il peut certainement être de 1:1 les relations entre les éléments de données dans le monde réel. Pas de question à ce sujet. Le "est" une relation est généralement une à une. Une voiture est un véhicule. Une voiture est un véhicule. Un véhicule est peut-être une voiture. Certains véhicules sont des camions, dans ce cas, un véhicule n'est pas une voiture. Plusieurs réponses répondre à cette interprétation.
Mais je pense que ce que vous êtes vraiment poser est de savoir... quand 1:1 il existe des relations, devrait tables jamais être divisé? En d'autres termes, si vous avez deux tables qui contiennent exactement les mêmes touches? Dans la pratique, la plupart d'entre nous d'analyser uniquement les clés primaires, et pas d'autres touches, mais que la question est un peu différente.
Les règles de normalisation pour 1FN, 2FN, et 3FN n'a pas besoin de décomposition (splitting) un tableau en deux tables avec la même clé primaire. Je n'ai pas travaillé si mettre un schéma en FNBC, 4NF, ou 5NF peut jamais avoir deux tables avec les mêmes touches. Sur le dessus de ma tête, je suppose que la réponse est non.
Il y a un niveau de normalisation appelé 6NF. La règle de normalisation pour 6NF pouvez certainement résultat en deux tableaux avec la même clé primaire. 6NF a l'avantage sur 5NF que les valeurs NULL peut être complètement évitée. C'est important pour certains, mais pas tous, les concepteurs de base de données. Je n'ai jamais pris la peine de mettre un schéma en 6NF.
En 6NF les données manquantes peuvent se faire représenter par un omis ligne, au lieu d'une ligne avec une valeur NULL dans la colonne.
Il y a d'autres raisons que la normalisation pour le fractionnement des tables. Parfois fractionner les tables aboutir à de meilleures performances. Avec certains moteurs de base de données, vous pouvez obtenir les mêmes avantages de performance par partitionnement de la table au lieu de les diviser. Cela peut avoir l'avantage de garder la conception logique et 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 plusieurs raisons. L'un est de de différence significative dans le taux de changement des données. Certains de mes tableaux peuvent avoir des pistes de vérification, où j'ai suivi les précédentes versions de documents, si je ne soin de suivre les versions précédentes de 5 à 10 colonnes de fractionnement de ces 5 colonnes sur une table séparée avec une piste de vérification de ce mécanisme, il est plus efficace. Aussi, j'ai peut-être des enregistrements (disons pour une comptabilité app) qui sont en écriture seulement. Vous ne pouvez pas modifier les montants en dollars, ou du compte sur lequel elles ont été, si vous avez fait une erreur vous avez besoin de faire un enregistrement correspondant à écrire ajuster désactiver l'enregistrement erroné, puis créer une correction de l'entrée. J'ai des contraintes sur la table de l'application le fait qu'ils ne peuvent pas être mises à jour ou effacées, mais j'ai peut-être une couple d'attributs de l'objet qui sont malléables, ceux-ci sont conservés dans un tableau distinct, sans la restriction sur la modification. Une autre fois, je ne ce qui est dans le dossier médical des applications. Il ya des données relatives à une visite qui ne peut pas être changé une fois qu'il est signé, et d'autres données liées à une visite qui peut être modifié après la signature. Dans ce cas, je fractionne les données et de mettre un trigger sur la table verrouillée en rejetant les mises à jour de la table verrouillée lors de la signature, mais en permettant à jour les données le médecin n'est pas signer.
Une autre affiche a commenté sur 1:1 ne sont pas normalisées, je ne serais pas d'accord avec que, dans certaines situations, en particulier de sous-typage. Dire que j'ai un employé de la table et la clé primaire est leur SSN (c'est un exemple, nous allons sauver le débat à savoir si c'est une bonne clé ou pas pour un autre thread). Les employés peuvent être de différents types, disons temporaire ou permanente et s'ils sont permanents, ils ont plus de champs à remplir, comme bureau numéro de téléphone, ce qui ne devrait pas être null si le type = "Permanent". Dans une 3ème forme normale de la base de données de la colonne doit dépendre uniquement de la clé, sens de l'employé, mais il dépend en réalité de l'employé et le type, donc une relation 1:1 est tout à fait normal et souhaitable dans ce cas. Il empêche également trop clairsemée tables, si j'ai 10 colonnes qui sont normalement remplis, mais 20 colonnes supplémentaires seulement pour certains types.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
