2 eme Année-Définition en SGBD

Définition en SGBD :

LANGAGES ASSERTIONNELS :

Il existe deux types de langage de manipulation de bases de données relationnelles : les langages procéduraux et les langages assertionnels. Un langage procédural est un langage dans lequel une requête s'exprime au travers d'un enchaînement d'opérations. Dans cette catégorie, on trouve aussi bien les langages graphiques type QBE (Query By Example ) implantés dans des SGBD tels qu'Access que le langage algébrique étudié dans ce paragraphe. Par contre, un langage assertionnel est un langage dans lequel une requête contient l'expression du résultat désiré. Dans cette seconde catégorie, on peut citer le langage SQL (Structured Query Language ).

Comment gérer l’intégrité d’une base de données

Aujourd’hui je voulais écrire un petit billet sur les différentes façons de gérer l’intégrité de sa base de données.

L’intégrité dans une base de données

Avant toute chose, il est bon de rappeler à quoi correspond l’intégrité des données dans une base de données.  Je me place volontairement dans le cas des SGBD relationnels. Pour cela, rien ne vaut une petite citation made in Wikipédia :

L’une des missions d’une base de données est d’assurer à tout instant l’intégrité, c’est-à-dire la cohérence, la fiabilité, et la pertinence des données qu’elle contient.

Pour faire simple, chaque donnée contenu dans vos tables doit être pertinente et à jour ! Et cela quelque soit les manipulations faites sur votre base. Suppression, mises à jours, insertions …

Cas concret de perte d’intégrité

Prenons le cas d’un forum. Il existe une table « topic » et une table « message ». Pour lier les deux tables, on rajoute une colonne dans la table « message » faisait référence au topic auquel appartient le message.

Cependant qu’arrive-t-il quand je supprime un topic ? En effet, des messages y sont certainement liés, et si c’est le cas ils doivent être supprimés ! Dans le cas contraire on se retrouve avec des messages orphelins et l’intégrité (référentielle) de la base de données est perdue.

Problématique

C’est alors pendant la phase de conception de notre projet, que l’on doit se demander qui doit assurer l’intégrité de la base de données.

Deux solutions

A ma connaissance il existe deux moyens de faire respecter l’intégrité de votre base de données :

1. Créer une couche d’abstraction dans votre application qui gère l’intégrité : Framework avec ORM généralement.
2. Créer des contraintes d’intégrité directement dans la base de données à l’aide du SGBD.

Côté applicatif

Il est tentant pour le développeur de vouloir gérer l’intégrité de sa base directement dans son code source. En effet, on gagne en flexibilité, on pense savoir se que l’on fait, on rajoute une couche d’abstraction et puis c’est fait main donc on maîtrise tous les aspects.

On peut aussi se retrouver à utiliser un Framework qui propose de s’occuper de l’intégrité des données pour peu que vous le configuriez comme il faut. C’est tentant, la partie fastidieuse du code est déjà faite, on vous propose quelque chose de générique et bien construit, et puis essayer de le configurer vous aidera à mieux maîtriser ce Framework.

Cependant l’expérience tend à me faire dire que c’est une solution dangereuse. Il y a des risques majeurs :

• En multi-développeurs : un seul développeur oublie de configurer les contraites et c’est le drame.
• Si d’autres applications veulent accéder à la base de données, elles sont obligées elles aussi de gérer l’intégrité dans leur code et de la même façon.
• En cas de refactorisation du code, on peut supprimer des contraintes par mégarde et les tests auront du mal à le déceler.

Un des rares avantages de cette méthode est qu’elle centralise toute la partie logique/métier du projet au même endroit du projet. De plus, on évite de toucher à la base de données car pour certains ce n’est pas leur cheval de bataille.

Côté SGBD

Ici on utilise la puissance du SGBD pour qu’il garde lui même l’intégrité des données sur ses tables. Chaque SGBD a ses méthodes, mais de façon général on utilise :

• Les clefs étrangères pour faire respecter les contraintes d’intégrités référentielles.
• Les triggers : suppressions, modifications en cascade.

Tous c’est outils assurent de manière forte et pérenne l’intégrité de la base de données.

L’inconvénient majeur est qu’à chaque ajout ou modification d’une table, il faut manipuler le SGBD pour rajouter ou mettre à jour des contraintes d’intégrités. Malheureusement ce n’est pas le dada de tout le monde de passer du temps en base de données.

Cependant l’avantage est indéniable : nous n’avons plus rien à faire côté applicatif, on récupère juste le cas échéant une erreur du SGBD pour violation de contrainte. De plus en terme de maintenabilité on est tranquille en cas d’évolution du code ou de changement de développeur : le SGBD veille au grain.

Conclusion

La conclusion de cet article se résume en une seule phrase :

Gérer l’intégrité de votre base de données directement dans votre SGBD !