Lorsque l'on utilise un SGBD relationnel, une modélisation incorrecte des données peut avoir des conséquences importantes sur la pertinence des résultats produits.
Nous nous intéresserons ici à deux problèmes qui peuvent apparaître lorsque la modélisation n'a pas été effectuée de manière suffisamment rigoureuse :
- Problèmes d'interrogations lorsque le schéma des données n'est pas en 3 FN
- Modélisation d'une structure de type tableau de données
1-Interrogations sur un schéma qui n'est pas en 3 FN
L'interrogation des bases de données relationnelle est réalisée essentiellement à l'aide du langage SQL. Ce langage implémente 2 opérateurs fondamentaux :
- La projection : permets de sélectionner les colonnes de relations
- La jointure : permets de réunir les colonnes de différentes relations
La projection peut être vue comme un opérateur de découpage (décomposition) des relations, et la jointure comme un opérateur de recomposition (collage) des relations.
De manière imagée, considérons qu'une feuille de papier est une relation. Le découpage de cette feuille en bandes verticales (projection) puis le collage (jointure) des bandes découpées doit permettre, logiquement, de reconstruire la feuille de papier (la relation) dans son état initial.
Ce résultat qui paraît évident ne l'est pas si les relations qui composent la base de données ne sont pas dans une structure correcte.
Prenons par exemple le document suivant qui regroupe des informations sur des clients.
| CLIENTS | Numcli | Nomcli | Adresse | Dept | Lbdept | Région |
| 1 | Dupont | 11 rue du Bois | 33 | Gironde | Aquitaine | |
| 2 | Martin | 14 avenue Leclerc | 33 | Gironde | Aquitaine |
Supposons que la modélisation de ce document conduit à créer les deux relations suivantes :
R1(Numcli, Nomcli, Dept)
R2(Dept, Lbdept, Région, Adresse)
R1 est la projection de CLIENTS sur les attributs Numcli, Nomcli, Dept
R2 est la projection de CLIENTS sur les attributs Dept, Lbdept, Région, Adresse
| R1 | Numcli | Nomcli | Dept | R2 | Dept | Lbdept | Région | Adresse | |
| 1 | Dupont | 33 | 33 | Gironde | Aquitaine | 11 rue du Bois | |||
| 2 | Martin | 33 | 33 | Gironde | Aquitaine | 14 avenue Leclerc |
Si l'on fait une jointure de R1 et R2 sur l'attribut qu'elles ont en commun (Dept), on devrait logiquement retrouver la relation CLIENTS.
Or le résultat de la jointure est le suivant :
| R1 x R2 | Numcli | Nomcli | Dept | Lbdept | Région | Adresse |
| 1 | Dupont | 33 | Gironde | Aquitaine | 11 rue du Bois | |
| 1 | Dupont | 33 | Gironde | Aquitaine | 14 avenue Leclerc | |
| 2 | Martin | 33 | Gironde | Aquitaine | 11 rue du Bois | |
| 2 | Martin | 33 | Gironde | Aquitaine | 14 avenue Leclerc |
Cela signifie que si les relations R1 et R2 étaient implantées telles quelles dans un SGBD, la requête SQL de jointure donnerait des résultats sans rapport avec la réalité...
Ce comportement anormal (décomposition avec perte d'informations), provient du fait que R2 n'est pas en 3 FN.
En effet, les DF élémentaires et directes (voir : normalisation des relations) qui relient les différents attributs sont les suivantes :
Numcli -> Nomcli, Adresse, Dept
Dept -> Lbdept, Région
Il en découle que nous avons les relations en 3 FN suivantes :
CLIENT(Numcli, Nomcli, Adresse, Dept)
DEPARTEMENT(Dept, Lbdept, Région)
On vérifiera aisément que la jointure de CLIENT et DEPARTEMENT redonne bien la relation CLIENTS d'origine. La décomposition de CLIENTS en 2 relations CLIENT et DEPARTEMENT se fait donc sans perte d'informations.
Une modélisation incorrecte (relations qui ne sont pas en 3 FN) peut donc avoir des répercussions significatives sur la pertinence des résultats produits.
2-Modélisation de tableaux
De nombreux utilisateurs sont souvent déroutés par l'approche base de données. Ils ne trouvent pas, en effet, de structure permettant l'implantation directe d'un tableau de données déjà rempli comme cela est possible dans des logiciels spécialisés de type SAS, Minitab, Excel ou autres outils quantitatifs.
La modélisation d'un tableau dans une base de données est réalisée par l'implantation d'une relation (table) dont la clé est constituée par l'ensemble des indices du tableau et la propriété est la valeur associée à chaque combinaison des indices.
Si l'on considère un tableau T, constitué de i indices (i1, i2...), avec pour chaque combinaison des indices la valeur V la relation en 3 FN qui permet de modéliser T est la suivante :
T(i1, i2,..., V)
Cette structure associe à chaque case du tableau la valeur correspondante. Par exemple, pour un tableau de contingence comportant 10 lignes et 5 colonnes, la structure implantée dans la base de données comportera 50 (10*5) lignes.
Bien que les SGBD ne soient pas conçus pour implanter directement des tableaux de données, de nombreux SGBD (Oracle, MySQL, Firebird...) ont ajouté des fonctions permettant de travailler avec des tableaux. Il devient alors possible de définir des tableaux de données directement dans le SGBD.
Toutefois l'interrogation portant sur des données de type tableaux ne peut être faite directement avec SQL et doit se faire par le biais d'un langage de programmation, les "procédures stockées" dans le cas de Firebird.
Exemple
Nous prendrons pour exemple la gestion d'employés d'une entreprise. Pour chaque employé on veut pouvoir stocker les informations suivantes :
Son numéro d'employé, son nom, sa date de naissance, ainsi que les langues, autres que sa langue naturelle, qu'il connaît (de 1 à 5) et le niveau de maîtrise qu'il a de chaque langue : débutant, confirmé, expert.
1-Utilisation de tableaux
Les attributs Langue et Niveau seront décrits comme des tableaux pouvant contenir de 1 à 5 éléments. En utilisant, par exemple, le formalisme du SBGD Firebird, nous aurions une relation (table) de la forme suivante :
EMPLOYE(Numemp, Nomemp, Dtnaiss, Langue[1..5], Niveau [1..5])
Remarques
-Même si l'employé ne connaît pas d'autres langues que sa langue naturelle les attributs Langue et Niveau seront réservés 5 fois.
-Si un employé maîtrise plus de 5 langues, l'information ne pourra pas être enregistrée.
-Pour afficher les langues, et le niveau en langue de chaque employé il faut utiliser un langage de programmation qui va réaliser une itération sur les valeurs possibles des attributs Langue et Niveau.
Pour traiter ce dernier point il faut utiliser, par exemple avec Firebird, une procédure stockée du style suivant :
DECLARE VARIABLE i INTEGER;
BEGIN
i = 1;
WHILE (i <= 5) DO
BEGIN
SELECT langue[:i], Niveau[:i] FROM EMPLOYE
WHERE (Numemp=:code)
INTO :languages, :niveaux;
IF (languages = ' ') THEN languages = 'NULL';
i = i +1;
SUSPEND;
END
END
2-Modélisation sans tableaux
Dans cet exemple, l'utilisation de tableaux peut facilement être évitée. L'usage de tableaux relève d'une modélisation incorrecte. Il suffit en effet, pour traiter cet exemple, de définir les 2 relations (tables) en 3 FN suivantes :
EMPLOYE(Numemp, Nomemp, Dtnaiss)
LANGUES(Numemp,Langue, Niveau)
Remarques
Avec cette modélisation :
-Si l'employé ne connaît pas d'autres langues que sa langue naturelle, aucune ligne ne figurera dans la table LANGUES pour l'employé.
-Si un employé maîtrise plus de 5 langues, l'information peut être enregistrée sans problème.
-Pour afficher les langues, et le niveau en langue, de chaque employé il suffit de faire une requête SQL qui réalise une jointure entre EMPLOYE et LANGUES sur l'attribut Numemp, pour avoir l'information désirée.
Conclusion
L'utilisation de tableaux, même si elle est possible avec un SGBD, doit être évitée. Une modélisation correcte permet, le plus souvent, de s'affranchir d'utiliser des tableaux.