Une question!

Nous allons essayer d’apporter des éléments de réponse à la question :

« Pourquoi dois-je utiliser un SGBDR, ne peut-on pas faire plus simple?»

Contexte

• Tous les livres de la bibliothèque possèdent un numéro de livre, un titre, un ou plusieurs auteurs et un éditeur.
• Lorsqu’une personne emprunte un livre, il faut mémoriser son nom, son prénom, son numéro de téléphone, son adresse, la date de l’emprunt et la date de retour une fois ce dernier réalisé.
• Toutes les informations doivent être conservées pour garder un historique des emprunts.

Approche naïve

Votre application va devoir stocker toutes les informations mentionnées dans l’introduction (section Contexte), et de manière persistante, donc en utilisant un fichier. Quelle est la solution de stockage des données la plus naturelle venant à l’esprit ?

Supposons que nous adoptions la solution suivante :

• Nous créons un fichier texte comportant à l’origine une ligne par livre.
• Dans chaque ligne, on trouve les informations titre, auteur, éditeur, numéro du livre séparées par une tabulation.
• Quand une personne emprunte un livre, on complète la ligne du livre en question par les champs nom, prénom, téléphone, adresse et date-emprunt toujours en séparant ces informations par une tabulation.
• Lorsqu’une personne retourne un livre, il suffit d’ajouter un dernier champs date-retour sur la ligne du livre en question.
• Quand un livre est emprunté une nouvelle fois, on crée une nouvelle ligne avec toutes les informations concernant le livre et la personne qui l’emprunte.
• Bien entendu, le bibliothécaire ne ressaisit pas tout, l’application va chercher la plupart de ces informations dans le fichier.

Et maintenant...

L’application fonctionne maintenant depuis 10 ans. Le nombre de personnes inscrites à la bibliothèque est relativement constant et est de 5000 personnes en moyenne chaque année an. Un abonné emprunte en moyenne 2 livres par mois.

• Quel est, approximativement, le nombre de lignes du fichier des données ?
• Quelle est la taille approximative du fichier sachant que chaque caractère occupe 1 octet et qu’une ligne contient, en moyenne, 150 caractères ?
• Lorsqu’un abonné emprunte un livre, le bibliothécaire saisit simplement le numéro du livre et les nom et prénom de l’abonné.
  L’application se charge alors de parcourir le fichier pour rechercher les informations manquantes concernant le livre et l’abonné afin d’écrire, à la fin du fichier, la nouvelle ligne concernant l’emprunt.
  Dans le pire des cas, l’application doit parcourir tout le fichier.
  Supposons qu’un accès au fichier coûte 10ms, qu’une lecture de ligne coûte 6ms et qu’une recherche sur la ligne pour trouver le numéro du livre ou le nom et le prénom de l’abonné coûte 1ms.
  Quel est, dans le pire des cas, le temps mis par l’application pour compléter les informations saisies par le bibliothécaire ?
• Supposons qu’une personne est abonnée depuis l’origine de l’application. Elle prévient le bibliothécaire que son prénom est mal orthographié.
  Combien de lignes, approximativement, doivent être modifiées pour corriger cette erreur dans tout le fichier de données ?
• Lors de cette correction d’un prénom mal orthographié, comment distinguer les homonymes ?
• Supposons que la base de données contienne plusieurs exemplaires de deux livres distincts du même auteur, Michel Tournier, chez le même éditeur, Poche, et portant le même titre : Vendredi ou la vie sauvage. Le bibliotécaire s’appercoit que l’un des deux livres n’est pas édité par la maison d’édition Poche, mais par Broché.
  Comment corriger le problème dans la base ?
• ... etc. Une très très longue énumération de problèmes...

Affinement de la solution

Il est évident que la solution naïve décrite dans la section précédente pose de nombreux problèmes.
Elle est totalement inacceptable pour une application sérieuse bien qu’elle soit encore largement employée dans des cas de petite taille ...

Un premier affinage de la solution de la section précédente consiste à utiliser non pas un fichier unique mais quatre fichiers distincts :

• Un premier fichier est dédié au stockage des informations concernant les livres de la bibliothèque.

  N°Livre	Titre	Auteur	Éditeur

• Un second fichier est dédié au stockage des informations concernant les abonnés.

  N° Client	Nom	Prénom	Téléphone	Adresse

• Les informations stockées dans le troisème fichier vont permettre de faire la correspondance entre les deux premiers pour signifier qu’un livre donné est en cours de prêt par un abonné donné depuis une date donnée.

  N°Client	N°Livre	Date-emprunt

• Enfin, un dernier fichier va permettre de stocker l’historique des prêts. Il est similaire au troisième fichier, mais il comporte en plus une information relative à la date de retour du livre.

  N°Client	N°Livre	Date-emprunt	Date-retour

Les choses s'améliorent ! ... Mais il reste du travail.

• On constate que nous avons largement gagné en terme de redondance, très bien!
• On sépare les données concernant les livres et les clients, très bien!
• On a plus un fichier "énorme", on en a 4 plus petits
• Si on désire rechercher un client, la recherche est plus rapide, pas mal!
• On peut même distinguer des clients homonymes, magnifique!
• etc. La solution est meilleure mais...

• Et si un livre est écrit par plusieurs auteurs, comment faire la recherche du livre sur chacun des ses auteurs?
• Et pour faire une recherche sur un auteur et une maison d'édition? Bonne chance...
• En cas de conflit sur la remise d'un livre, comment vérifier rapidement qu'un livre a bien été remis?
• etc.

Que retenir?

• Redondance des données – Certains choix de conception entraînent une répétition des données lors de leur insertion dans la base. Cette redondance est souvent la cause d’anomalies provenant de la complexité des insertions. C’est, par exemple, le cas de la première organisation proposée : dès qu’un abonné emprunte un livre, il faut dupliquer toutes les information concernant l’abonné et le livre emprunté ! Au contraire, dans la deuxième solution, seuls les numéros indispensables à la distinction d’un livre et d’un abonné sont répétés dans le cas d’un emprunt.
• Incohérence en modification – La redondance de l’information entraîne également des risques en cas de modification d’une donnée car on oublie fréquemment de modifier toutes ses occurrences.
• Anomalie d’insertion – Une mauvaise conception peut parfois empêcher l’insertion d’une information, faute de connaître la valeur de tous ses champs. Pour remédier à ce problème, certains SGBD introduisent une valeur non typée qui signifie que la valeur d’un attribut est inconnue ou indéterminée. Cette valeur (appelée usuellement NULL) indique réellement une valeur inconnue et non une chaîne de caractères vide ou un entier égal à zéro. Dans la première solution proposée, insérer un nouvel abonné qui n’a jamais emprunté de livre peut poser des problèmes. Une solution serait d’insérer des champs vides (suite de tabulations consécutives) au début de la ligne.
• Anomalie de suppression – Enfin, une mauvaise conception peut entraîner, lors de la suppression d’une information, la suppression d’autres informations, sémantiquement distinctes, mais indissociables dans la modélisation adoptée. Par exemple, dans la première solution proposée, si l’on désire supprimer toutes les traces d’un livre dans le fichier de données, on fera complètement disparaître tous les abonnés qui n’ont emprunté que ce livre.
• Bien d’autres enjeux, que ceux que nous avons abordés, sont inhérents aux bases de données. Ces enjeux concernent la gestion des bases de données : indépendance physique, indépendance logique, accès aux données, administration centralisée des données, cohérence des données, partage des données, sécurité des données, résistance aux pannes, etc.

La conception des bases de données est donc un problème complexe. La gestion de ces bases constitue également un problème complexe. Or, ces deux problèmes sont extrêmement récurrents puisque les bases de données se trouvent aujourd’hui au cœur de tous les systèmes d’information.