Qu'est-ce qu'une relation un-à-un dans la modélisation des données ? Comment implémentez-vous cette relation dans une base de données ? Les exemples de cet article répondront à ces questions.
Il existe trois types de relations entre les entités (tables) dans la modélisation des données :
- Relations un-à-plusieurs (également notées 1:M).
- Relations plusieurs-à-plusieurs (M:N).
- Relations individuelles (1:1).
Le type de relation le plus courant est une relation un-à-plusieurs, dans laquelle un enregistrement d'une entité peut être référencé par plusieurs enregistrements d'une autre entité. Un autre type courant est une relation plusieurs à plusieurs. Ce type de relation n'est utilisé que dans les modèles de données logiques. Dans une base de données physique, il doit être implémenté en utilisant des relations un-à-plusieurs et une table de jonction.
Dans cet article, nous aborderons le troisième type de relations :la relation un à un . Il s'agit du type de relation le moins courant dans un modèle de données. Nous donnerons des exemples de relations biunivoques, montrerons la notation des relations biunivoques dans un diagramme ER et discuterons des relations biunivoques dans la pratique.
Exemples de relations individuelles
Tout d'abord, qu'est-ce qu'une relation un à un ? C'est une relation où un enregistrement dans une entité (table) est associé à exactement un enregistrement dans une autre entité (table).
Voyons quelques exemples concrets de relations un à un :
- Pays - capitale :Chaque pays a exactement une capitale. Chaque capitale est la capitale d'exactement un pays.
- Personne :ses empreintes digitales . Chaque personne a un ensemble unique d'empreintes digitales. Chaque ensemble d'empreintes digitales identifie exactement une personne.
- E-mail - compte utilisateur . Pour de nombreux sites Web, une adresse e-mail est associée à exactement un compte utilisateur et chaque compte utilisateur est identifié par son adresse e-mail.
- Conjoint - conjoint :Dans un mariage monogame, chaque personne a exactement un conjoint.
- Profil utilisateur - paramètres utilisateur . Un utilisateur dispose d'un ensemble de paramètres utilisateur. Un ensemble de paramètres utilisateur est associé à exactement un utilisateur.
Pour plus de clarté, comparons ces exemples avec des relations qui ne sont pas univoques :
- Pays - ville : Chaque ville se trouve dans exactement un pays, mais la plupart des pays ont de nombreuses villes.
- Parent - enfant :Chaque enfant a deux parents, mais chaque parent peut avoir plusieurs enfants.
- Employé - gestionnaire : Chaque employé a exactement un superviseur ou responsable immédiat, mais chaque responsable supervise généralement plusieurs employés.
Dénoter une relation un-à-un dans un diagramme ER
Une relation biunivoque dans un diagramme ER est désignée, comme toutes les relations, par une ligne reliant les deux entités. La cardinalité "une" est désignée par une seule ligne droite. (La cardinalité "plusieurs" est indiquée par le symbole de la patte d'oie .)
La relation un à un entre le pays et la capitale peut être notée comme suit :
Les droites perpendiculaires signifient "obligatoire ”. Ce diagramme montre qu'il est obligatoire pour une capitale d'avoir un pays et qu'il est obligatoire pour un pays d'avoir une capitale.
Une autre possibilité est que l'un ou les deux côtés de la relation soient facultatifs . Un côté facultatif est indiqué par un cercle ouvert. Ce diagramme indique qu'il existe une relation biunivoque entre une personne et ses empreintes digitales. Une personne est obligatoire (les empreintes digitales doivent être attribuées à une personne), mais les empreintes digitales sont facultatives (une personne peut ne pas avoir d'empreintes digitales attribuées dans la base de données).
Relations un à un dans une base de données physique
Il existe plusieurs façons d'implémenter une relation un-à-un dans une base de données physique.
Clé primaire comme clé étrangère
Une façon d'implémenter une relation un-à-un dans une base de données consiste à utiliser la même clé primaire dans les deux tables. Les lignes avec la même valeur dans la clé primaire sont liées. Dans cet exemple, la France est un country avec l'id 1 et sa capitale est dans le tableau capital sous id 1.
country
| identifiant | nom |
|---|---|
| 1 | France |
| 2 | Allemagne |
| 3 | Espagne |
capital
Techniquement, l'une des clés primaires doit être marquée comme clé étrangère, comme dans ce modèle de données :
La clé primaire dans la table capital est également une clé étrangère qui fait référence à la colonne id dans la table pays . Depuis capital.id est une clé primaire, chaque valeur de la colonne est unique, de sorte que la capitale peut référencer au plus un pays. Il doit également faire référence à un pays - il s'agit d'une clé primaire, elle ne peut donc pas être laissée vide.
Clé étrangère supplémentaire avec contrainte unique
Une autre façon d'implémenter une relation un-à-un dans une base de données consiste à ajouter une nouvelle colonne et à en faire une clé étrangère.
Dans cet exemple, nous ajoutons la colonne country_id dans le tableau capital . La capitale avec id 1, Madrid, est associé au pays 3, Espagne.
country
| identifiant | nom |
|---|---|
| 1 | France |
| 2 | Allemagne |
| 3 | Espagne |
capital
| identifiant | nom | country_id |
|---|---|---|
| 1 | Madrid | 3 |
| 2 | Berlin | 2 |
| 3 | Paris | 1 |
Techniquement, la colonne country_id doit être une clé étrangère référençant l'id colonne de la table country . Puisque vous voulez que chaque capitale soit associée à exactement un pays, vous devez faire en sorte que la colonne de clé étrangère country_id unique.
Les relations individuelles en pratique
Peu de relations individuelles durent
Les relations un à un sont le type de relation le moins fréquent. L'une des raisons à cela est qu'il existe très peu de relations individuelles dans la vie réelle. De plus, la plupart des relations biunivoques ne sont biunivoques que pendant un certain temps. Si votre modèle inclut une composante temporelle et capture l'historique des modifications, comme c'est très souvent le cas, vous aurez très peu de relations individuelles.
Une relation monogame peut se rompre ou l'un des partenaires peut mourir. Si vous modélisez la réalité des relations monogames (telles que les mariages ou les unions civiles) au fil du temps, vous devrez probablement modéliser le fait qu'elles ne durent qu'un certain temps.
On pourrait penser qu'une personne et ses empreintes digitales ne changent jamais. Mais que se passe-t-il si la personne perd un doigt ou si le doigt est gravement brûlé ? Leurs empreintes digitales pourraient changer. Ce n'est pas un scénario très fréquent; néanmoins, dans certains modèles, vous devrez peut-être en tenir compte.
Même quelque chose d'apparemment aussi stable que les pays et leurs capitales changent avec le temps. Par exemple, Bonn était la capitale de l'Allemagne de l'Ouest (Bundesrepublik Deutschland) après la Seconde Guerre mondiale, lorsque Berlin faisait partie de l'Allemagne de l'Est. Cela a changé après la réunification allemande; la capitale de l'Allemagne (Bundesrepublik Deutschland) est maintenant Berlin. Que vous deviez ou non en tenir compte dépend de la réalité de votre entreprise et de l'application sur laquelle vous travaillez.
Un scénario 1:1 réalisable :parties facultatives du tableau
Je peux penser à un scénario réalisable pour une véritable relation un-à-un :les parties facultatives d'une table. Imaginez que vous ayez la table user avec les données de l'utilisateur. Le tableau contient des informations générales sur l'utilisateur, telles que les noms, les adresses e-mail et les dates d'inscription des utilisateurs. Il contient également des paramètres utilisateur, tels que le thème de couleur ou la connexion automatique pour cette application. Cependant, la plupart des utilisateurs n'ont pas de paramètres utilisateur ; ils utilisent les paramètres par défaut.
user
| identifiant | nom | courriel | date_d'inscription | thème | connexion automatique |
|---|---|---|---|---|---|
| 1 | Nathanaël Talbot | [email protected] | 2020-12-12 | sombre | vrai |
| 2 | Talitha Yates | [email protected] | 2020-12-14 | ||
| 3 | Markus Weir | [email protected] | 2020-12-15 | lumière | faux |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Église Maurice | [email protected] | 2020-12-20 | ||
| 6 | Arwa Valdez | [email protected] | 2020-12-21 |
Il y a beaucoup de champs vides dans ce tableau. Vous pouvez diviser le user table en deux tables :user et user_settings , qui contient des informations sur les paramètres des utilisateurs pour ceux qui ont choisi de les sélectionner.
user
| identifiant | nom | courriel | date_d'inscription | thème | connexion automatique |
|---|---|---|---|---|---|
| 1 | Nathanaël Talbot | [email protected] | 2020-12-12 | sombre | vrai |
| 2 | Talitha Yates | [email protected] | 2020-12-14 | ||
| 3 | Markus Weir | [email protected] | 2020-12-15 | lumière | faux |
| 4 | Nathalie Hays | [email protected] | 2020-12-18 | ||
| 5 | Église Maurice | [email protected] | 2020-12-20 | ||
| 6 | Arwa Valdez | [email protected] | 2020-12-21 |
user_settings
| user_id | thème | connexion automatique |
|---|---|---|
| 1 | sombre | vrai |
| 3 | lumière | faux |
Le fractionnement des données en deux tables rend l'interrogation des tables plus complexe :vous devez joindre les données des deux tables. D'autre part, l'utilisateur principal table est plus simple à gérer.
En savoir plus sur les relations de base de données
Une relation un-à-un est une relation dans laquelle un enregistrement d'une table est associé à exactement un enregistrement d'une autre table. Ce type de relation est rare dans la vraie vie. Si vous incluez le temps dans votre modèle de données, de nombreuses relations un à un deviennent des relations un à plusieurs ou plusieurs à plusieurs. Le scénario le plus courant pour utiliser une relation un-à-un dans une base de données consiste à diviser une table en deux :l'une avec des colonnes obligatoires, l'autre avec des colonnes facultatives.
Si vous avez aimé cet article, consultez d'autres articles sur les relations un-à-plusieurs et plusieurs-à-plusieurs sur notre blog.
Si vous êtes un étudiant qui suit des cours de base de données, assurez-vous de créer un compte académique gratuit dans Vertabelo, notre outil de dessin de diagramme ER en ligne. Vertabelo vous permet de dessiner des diagrammes ER logiques et physiques directement dans votre navigateur. Il prend en charge PostgreSQL, SQL Server, Oracle, MySQL, Google BigQuery, Amazon Redshift et d'autres bases de données relationnelles. Essayez-le et voyez comme il est facile de commencer !
