La conception de 1:1 et 1:m relations dans SQL Server
Dans SQL Server 2008, comment fait-on concevoir un 1:1 et 1:m relation?
voulez-vous dire "créer" ou "design"?
Blé: Vous et votre terminologie :p
Poneys : peut-être que je formulée qu'à tort 🙂 voulez-vous dire comment concevoir une telle chose dans un schéma général, OU comment dois-je physiquement créer un constructions qui représentent ces relations?
découvrez cette réponse de 1:1, stackoverflow.com/questions/1722741/...
Blé: Vous et votre terminologie :p
Poneys : peut-être que je formulée qu'à tort 🙂 voulez-vous dire comment concevoir une telle chose dans un schéma général, OU comment dois-je physiquement créer un constructions qui représentent ces relations?
découvrez cette réponse de 1:1, stackoverflow.com/questions/1722741/...
OriginalL'auteur blade3 | 2011-02-25
Vous devez vous connecter pour publier un commentaire.
Une relation exige que le "parent" de la table (un côté) première (ou unique) Clé (PK), qui identifie de façon unique chaque ligne, et les "enfants" de la table (l'autre côté) ont une colonne de Clé Étrangère ou des colonnes, qui doivent être remplis avec des valeurs qui sont les mêmes que pour une certaine valeur de[s] de la Clé Primaire de la table parent. Si vous voulez un un-à-plusieurs (1-M) relation de Clé Étrangère doit être un attribut ordinaire (ou les colonnes) dans la table enfant qui peut répéter (il peut y avoir plusieurs lignes avec la même valeur)
Si vous voulez un-à-un match nul (1-1) relation de clé Étrangère doit lui-même être une Clé Primaire ou unique de l'index dans la table enfant qui garantit qu'il peut y avoir au plus une ligne dans la table enfant avec cette valeur.
Une relation 1-1 efficacement les partitions les attributs (colonnes) dans un tableau en deux tables. Ceci est appelé la segmentation verticale. C'est souvent fait pour sous-classement la table des entités, ou, pour une autre raison, si l'utilisation de modèles sur les colonnes du tableau indiquent que quelques-uns des colonnes doivent être accessibles de manière significative plus souvent que le reste des colonnes. (Disons une ou deux colonnes seront accessibles 1000s de fois par seconde et l'autre de 40 colonnes seront accessibles qu'une fois par mois). Partitionnement de la table de cette manière, en effet, permettra d'optimiser la structure de stockage pour ces deux requêtes différentes.
Sous-Classement. Le ci-dessus crée un 1 à zéro ou une relation, qui est utilisé pour ce qu'on appelle une sous-catégorie ou sous-type de relation. Cela se produit lorsque vous avez deux entités différentes qui partagent un grand nombre d'attributs, mais l'une des entités, des attributs supplémentaires que l'autre n'en a pas besoin. Un bon exemple peut être Employés, et SalariedEmployees. Le Employé tableau aurait tous les attributs que tous les employés partagent, et le SalariedEmployee table existerait un (1-0/1) la relation avec les Employés, avec les attributs supplémentaires (Salaire, AnnualVacation, etc.) que seulement les salariés ont besoin.
Si vous voulez vraiment une relation 1-1, puis vous devez ajouter un autre mécanisme visant à garantir que la table enfant aura toujours un enregistrement pour chaque enregistrement/de ligne dans la table parent. Généralement la seule façon de le faire est par l'exécution de la présente dans le code utilisé pour insérer des données (que ce soit dans un déclencheur, d'une procédure stockée ou d'un code à l'extérieur de la base de données). C'est parce que si vous avez ajouté des contraintes d'intégrité référentielle sur deux tables qui exigent que les lignes de toujours être à la fois, il ne serait pas possible d'ajouter une ligne à un sans violer l'une des contraintes, et vous ne pouvez pas ajouter une ligne à deux tables en même temps.
Corriger, merci
Vous pouvez utiliser un déclencheur pour forcer l'envoi d'un enregistrement à la table enfant à chaque fois qu'un parent de la table est créée. Toutefois, lorsque vous faites cela, vous ne pouvez pas appliquer not null sur la colonne, à l'exception de ceux qui sont envoyés dans le déclencheur (en général seulement le FK) ou ceux qui ont une valeur par défaut. Cela peut être bon dans certains scénarios et le mal chez les autres.
OriginalL'auteur Charles Bretana
One-to-One Relation
Dans ce cas, je ne peux jamais avoir plus d'une ligne dans la ChildTable pour un ParentTable valeur de la clé primaire. Notez que, même dans un One-to-One relation, l'une des tables est le "parent" de la table. Ce qui différencie un One-to-One relation de un-à-Plusieurs relations purement en termes de mise en œuvre est de savoir si la ChildTable de la valeur de clé étrangère est une contrainte Unique ou Primary Key.
Un-à-Plusieurs Relation
Dans ce scénario, je peux avoir plusieurs lignes dans la ChildTable pour un ParentTable valeur de la clé primaire.
ChildTable
pour chaque ligneParentTable
. Le langage SQL manque un multiple opérateur d'affectation et SQL Server ne prend pas en charge inter-tableCHECK
contraintes niCREATE ASSERTION
. Une véritable 1:1 être réalisé dans SQL Server, aujourd'hui, sans avoir recours à du code de procédure (déclencheur, procédures stockées, etc)?Vous pouvez bien évidemment créer FK contrainte sur les deux côtés de la relation dans MSSQL et de restreindre à la fois FKs être unique. Cependant, il serait une corvée pour entrer des données dans cette situation. Vous devez désactiver l'un des FKs alors que vous avez entré les données, puis de le ré-activer lorsque vous avez été fini. Cela signifie que tout processus de faire une entrée devrait avoir les autorisations pour le faire. I. e., dans la pratique, un vrai 1:1 (vs 1:0/1) est difficile à mettre en œuvre.
Et Zéro,Une À Une Relation ?
Je ne suis pas sûr de comprendre ta question. Dans la pratique, un
1:0/1
relation est difficile à mettre en œuvre. Ce qu'il faudrait que est une norme ANSI SQL fonctionnalité appelée différés les relations dans lesquelles le vérifier sur si une insertion/mise à jour viole une FK relation se fait lors de la validation au lieu d'immédiatement.OriginalL'auteur Thomas
Une relation 1:1 existe où le tableau A et B n'existent qu'une fois en ce qui concerne les unes des autres.
Exemple: Un étudiant a 1 étudiant de master record. L'étudiant serait de table et de les enregistrer dans le tableau B. tableau B contient une clé étrangère vers le dossier de l'élève dans le tableau A (et éventuellement vice-versa)
1:m relation où la table A peut être référencé ou lié par un grand nombre d'entrées dans la table B.
Exemple: Un étudiant peut prendre plusieurs livres à la bibliothèque. L'élève de nouveau serait Une table et le livre pourrait être l'entrée dans le tableau B. L'entrée dans la table B contenant une clé étrangère qui a vérifié le livre, et de nombreux livres de référence, le même élève.
OriginalL'auteur rayman86