Contraintes sur le modèle de base de données relationnelle

Sur la modélisation de la conception du base de données relationnelle nous pouvons imposer des restrictions telles que les valeurs autorisées à être insérées dans la relation, le type de modifications et de suppressions autorisées dans la relation. Ce sont les restrictions que nous imposons à la base de données relationnelle.

Dans des modèles comme les modèles ER, nous n’avions pas de telles fonctionnalités.

Les contraintes dans les bases de données peuvent être classées en 3 grandes catégories :

  1. Les contraintes appliquées dans le modèle de données sont appelées Contraintes implicites.
  2. Des contraintes qui s’appliquent directement dans les schémas du modèle de données, en les spécifiant dans le DDL (langage de définition de données). Ceux-ci sont appelés comme contraintes basées sur le schéma ou contraintes explicites.
  3. Contraintes non directement applicables dans les schémas du modèle de données. Nous les appelons Application based ou contraintes sémantiques.

Nous traiterons donc ici Contraintes implicites.

Principalement les contraintes sur la base de données relationnelle sont de 4 types :

  1. Contraintes de domaine
  2. Principales contraintes
  3. Contraintes d’intégrité d’entité
  4. Contraintes d’intégrité référentielle

Discutons en détail chacune des contraintes ci-dessus.

1. Contraintes de domaine :

  1. Chaque domaine doit contenir des valeurs atomiques (plus petites unités indivisibles), cela signifie que les attributs composites et à valeurs multiples ne sont pas autorisés.
  2. Nous effectuons ici une vérification du type de données, ce qui signifie que lorsque nous attribuons un type de données à une colonne, nous limitons les valeurs qu’elle peut contenir. Par exemple. Si nous affectons le type de données de l’attribut age comme int, nous ne pouvons pas lui donner des valeurs autres que le type de données int.

Exemple:
\begin{centre} \begin{tabulaire}{ |c|c|c|c|  } \hline EID & Nom & Téléphone \\ \hline \001 & Bikash Dutta & 123456789 \\ & & 234456678\\ \hline \end{tabular} \end{center}

Explication:
Dans la relation ci-dessus, Name est un attribut composite et Phone est un attribut multi-valeurs, il viole donc la contrainte de domaine.

2. Contraintes clés ou contraintes d’unicité :

  1. Celles-ci sont appelées contraintes d’unicité car elles garantissent que chaque tuple de la relation doit être unique.
  2. Une relation peut avoir plusieurs clés ou clés candidates (superclé minimale), parmi lesquelles nous choisissons l’une des clés comme clé primaire, nous n’avons aucune restriction sur le choix de la clé primaire parmi les clés candidates, mais il est suggéré d’aller avec la clé candidate avec moins d’attributs.
  3. Les valeurs nulles ne sont pas autorisées dans la clé primaire, par conséquent, la contrainte Not Null fait également partie de la contrainte de clé.

Exemple:
\begin{centre} \begin{tabulaire}{ |c|c|c|c|  } \hline EID & Nom & Téléphone \\ \hline \001 & Bikash & 6000000009 \\ \002 & Paul & 9000090009\\ \001 & Tuhin & 9234567892\\ \hline \end{tabular} \end{center}

Explication:
Dans le tableau ci-dessus, EID est la clé primaire, et le premier et le dernier tuple ont la même valeur dans EID, c’est-à-dire 01, il viole donc la contrainte de clé.

3. Contraintes d’intégrité d’entité :

  1. Les contraintes d’intégrité d’entité indiquent qu’aucune clé primaire ne peut prendre la valeur NULL, car en utilisant la clé primaire, nous identifions chaque tuple de manière unique dans une relation.

Exemple:
\begin{centre} \begin{tabulaire}{ |c|c|c|c|  } \hline EID & Nom & Téléphone \\ \hline \001 & Bikash & 9000900099 \\ \002 & Paul & 600000009\\ NULL & Sony & 9234567892\\ \hline \end{tabular} \end{center}

Explication:
Dans la relation ci-dessus, EID devient une clé primaire et la clé primaire ne peut pas prendre de valeurs NULL, mais dans le troisième tuple, la clé primaire est nulle, il s’agit donc d’une violation des contraintes d’intégrité d’entité.

4. Contraintes d’intégrité référentielle :

  1. Les contraintes d’intégrité référentielle sont spécifiées entre deux relations ou tables et utilisées pour maintenir la cohérence entre les tuples dans deux relations.
  2. Cette contrainte est appliquée par le biais de la clé étrangère, lorsqu’un attribut de la clé étrangère de la relation R1 a le ou les mêmes domaines que la clé primaire de la relation R2, alors la clé étrangère de R1 est dite faire référence ou se référer à la clé primaire de rapport R2.
  3. Les valeurs de la clé étrangère dans un tuple de relation R1 peuvent soit prendre les valeurs de la clé primaire pour un tuple dans la relation R2, soit prendre des valeurs NULL, mais ne peuvent pas être vides.

Exemple:
\begin{centre} \begin{tabulaire}{ |c|c|c|c|  } \hline EID & Nom & DNO \\ \hline \001 & Divine & 12 \\ \002 & Dino & 22\\ \004 & Vivian & 14\\ \hline \end{tabular} \end{center}

\begin{centre} \begin{tabulaire}{ |c|c|c|c|  } \hline DNO & Place \\ \hline \112 & Jaipur \\ \113 & Mumbai \\ \114 & Delhi \\ \hline \end{tabular} \end{center}

Explication:
Dans ce qui précède, le DNO de la première relation est la clé étrangère et le DNO de la deuxième relation est la clé primaire. DNO = 22 dans la clé étrangère de la première table n’est pas autorisé puisque DNO = 22
n’est pas défini dans la clé primaire de la seconde relation. Par conséquent, les contraintes d’intégrité référentielle sont violées ici

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Aller en haut