Le modèle de données relationnel a été développé en 1970 par le mathématicien E.F. Codd et écrit à l'aide de la théorie des ensembles. Ce modèle sert de base aux bases de données relationnelles.
Pour tenir compte de toutes les informations pertinentes dans un système de base de données, il est utile de décrire le domaine d'application et les objets nécessaires. L'outil graphique le plus connu et le plus utilisé à cet égard est le "modèle entité-relation" (MER) appelé aussi
"modèle entité-association" (MEA) qui illustre tous les éléments d'un système de base de données relationnel et présente les rapports entre eux.
Dans la terminologie des bases de données, une "relation" est une "table" et donc une
construction de colonnes et de lignes. Dans le domaine des bases de données, une relation ne désigne donc pas, par définition, une liaison.
Les données sont enregistrées dans une table. Elle représente les informations à gérer (ci-dessous une table typique de MS Access):
Une table est constituée de colonnes, également appelées "champs" ou "attributs". Les lignes de la table contiennent des "enregistrements" ou "uplets". Tous les enregistrements d'une table ont une structure identique.
La structure d'une table est également appelée son "schéma". Les divers systèmes de base de données (ex. MS Access, dBase ou Paradox) disposent de différents formats de table, dont dépendent les conventions de noms des tables et des champs et les types de données de champs.
Définitions:
D1. Une "entité" (ou "enregistrement" donc) peut être un objet, un concept ou une personne. Les entités se distinguent les unes des autres par leurs propriétés.
D2. Un ensemble d'entités est un rassemblement d'entités avec des propriétés identiques et correspond à une "table".
Remarque: lLrs de la création d'une base de données réfléchissez d'abord aux entités et donc aux ensembles d'entités qu'elle doit contenir.
D3. Une "relation" est une "liaison d'entités". Les relations se distinguent les unes des autres par leurs propriétés.
Le type de relation décrit les rapports numériques entre les différents éléments par exemple: combien d'enregistrements de la table "Collaborateur" ont été attribués à un enregistrement de la table "Département" ? Le type de relation est généralement défini par les mentions suivantes:
0 – Pas d'attribution 1 – Une seule attribution n,m – Plusieurs attributions
Les relations sont représentées par des lignes de connexion dans le modèle ER: la relation est décrite par un symbole et la "cardinalité" est ajoutée en fin de ligne.
D4. Les "propriétés ou "attributs" caractérisent une entité, un ensemble d'entités, une relation ou un ensemble de relations.
D5. Les propriétés sont données par les "noms des champs de données" d'une table.
D6. Un "domaine de définition" indique la plage de valeurs autorisées pour une propriété.
Exemple: une entreprise englobe des collaborateurs, des départements et des projets. Une base de données relationnelle doit être créée pour gérer toutes les informations et tous les événements. Dans l'illustration suivante, tous les éléments de la base de données et leurs relations sont rassemblés:
Tous les résultats et informations peuvent être répartis en trois ensembles d'entités:
Département, Collaborateur et Projets.
Deux relations sont distinguées entre les ensembles d'entités: un département se compose de collaborateurs, qui travaillent sur des projets.
Étant donné qu'un département comprend plusieurs collaborateurs, mais qu'un
collaborateur n'appartient qu'à un département, il s'agit d'une relation un à plusieurs. Dans ce cas, il est nécessaire d'insérer le champ de clé (primaire) de la table primaire
(Département) dans la clé (étrangère) de la table étrangère (Collaborateurs) N°
Département.
Plusieurs collaborateurs peuvent travailler sur plusieurs projets. Il s'agit d'une relation donc d'une relations plusieurs à plusieurs.
Les ensembles d'entités Département, Collaborateurs et Projets possèdent certaines propriétés. Par exemple, l'ensemble d'entités Projets possède les propriétés N° Projet et Description. La propriété N° Projet identifie exactement une entité ou un enregistrement et est donc choisie comme clé primaire.
Une relation plusieurs à plusieurs nécessite un autre ensemble d'entités, appelé "table de transition" car l'association entre les collaborateurs et les projets n'est pas identifiable. Le nouvel ensemble d'entités comprend au moins les champs de clé des deux ensembles d'entités qui composent la relation plusieurs-à-plusieurs.
Pour obtenir une description compacte des entités, attributs et champs de clé, vous pouvez utiliser la forme textuelle suivante. Elle commence par le nom de l'entité (table), suivi, entre parenthèses, des attributs (champs), les champs de clé primaire étant soulignés.
DEPARTEMENT (N° Département, Description)
COLLABORATEURS (N° Personnel, Nom, Prénom, N° Département) PROJETS (N° Projet, Description)
EVALUATION_PROJET (N° Projet, N° Personnel, HeuresTravail)
3.6 Normalisation
La répartition des données dans des tables relationnelles peut entraîner des erreurs lors de la modification, de l'insertion et de la suppression de données et ainsi générer des redondances et incohérences des données. Ces erreurs sont également appelées "anomalies".
Par exemple, chaque collaborateur est associé avec son département et ses données de projet selon la table ci-dessous:
Toutes les données sont enregistrées dans une seule table. Les problèmes suivants surviennent lors de la modification, de l'insertion et de la suppression de données:
1. Lorsque vous insérez un nouveau collaborateur qui n'a travaillé sur aucun projet, des champs de données sont laissés vides, ce qui gaspille de l'espace disque. Des
problèmes de traitement peuvent également survenir en cas de requêtes, ex. lorsqu'un collaborateur travaille sur plusieurs projets en même temps. Ils figurent tous dans un champ N° Projet et doivent faire l'objet d'une opération supplémentaire. Une requête ne peut porter que sur tout le contenu d'un champ ou une partie de celui-ci.
2. Lorsque vous supprimez un collaborateur, vous devez également supprimer les données du projet correspondantes. Des données sont alors perdues.
3. Lorsque la dénomination d'un projet a été modifiée, par exemple, Enquête des clients est remplacé par Étude de marché, tous les enregistrements contenant cette valeur doivent être modifiés (si plusieurs collaborateur y travaillent bien sûr !)
Le processus de normalisation permet notamment de résoudre les problèmes susmentionnés.
Pour ce faire, les données des tables doivent respecter certaines règles. Le résultat de l'application de ces règles est appelé "forme normale" des tables.
Lors du processus de normalisation, les données sont réparties sur plusieurs tables. Les différentes étapes du processus de normalisation sont désignées sous le nom de formes normales: première, deuxième, troisième et quatrième formes normales.
La structure des données de l'exemple ci-dessus est appelée "non normalisée", car plusieurs informations sont enregistrées dans certains champs d'un enregistrement. Par exemple, le collaborateur Demus travaille sur les projets 1, 2 et 3.
Je vais ici présenter ma définition personnelle des 4 formes normales (FN) de base (étant donné qu'il n'y a pas de consensus absolu parmi tous les praticiens).
3.6.1 Première forme normale (1FN)
La première forme normale est la plus simple et souvent intuitive. Elle consiste à supprimer toutes les entrées multiples dans un champ. Chaque champ de données d'un enregistrement doit contenir une valeur maximum.
La première forme normale spécifie donc uniquement que chaque entrée d'un champ doit être indivisible (une valeur atomique soit: non composée) et en plus impose qu'il y ait au moins une clé primaire.
Cela revient donc à enlever le pluriel de certaines colonnes (seulement à N° Projets dans le cas présent):
Cela ne veut pas dire qu'une remarque sur un projet ne peut contenir qu'un mot. Si le champ contient toutefois plusieurs remarques avec des indications de date, l'entrée n'est plus automatique et peut être répartie en plusieurs champs de dates, avec textes de remarques correspondants.
Mais cette première forme normale a encore les problèmes suivants:
1. La table comprend des redondances. Des données de collaborateurs et des noms de départements et de projets apparaissent plusieurs fois.
2. La table contient les domaines indépendants suivants: collaborateurs, départements, projets.
3. Les données ne peuvent pas être identifiées de manière univoque. Par exemple, la description de certains projets ne peut être renvoyée qu'à l'aide d'un numéro personnel en plus.
3.6.2 Deuxième forme normale (2FN)
La deuxième forme normale exige que chaque champ non-clé (étrangère) contenant des doublons dépende d'une clé (primaire) simple ou combinée.
La deuxième forme normale appartient au modèle dit "modèle de normalisation de Boyce–
Codd".
Les données de la table initiale sont désormais réparties dans trois tables:
COLLABORATEURS (N° Personnel, N° Département, Nom, Prénom) DEPARTEMENT (N° Département, Désignation)
EVALUATION_PROJET (N° Projet, N° Personnel, Heures, Description)
3.6.3 Troisième forme normale (3FN)
Une table répond à la troisième forme normale lorsque tous les champs de données ne dépendent que de clés primaires par l'intermédiaire de clés étrangères dans le sens d'une maximisation du découpage.
Les deuxième et troisième forms normales appartiennet au modèle dit "modèle de normalisation de Boyce–Codd".
Par exemple le champ Description n'a rien à faire dans Evaluations_Projets puisqu'elle se répète (ou peut se répéter!).
Un autre cas classique d'erreur de troisième forme normale est de trouver dans la table Evaluations_Projets des champs Heures et Cout_Horaire et de trouver la multiplication des deux dans la même table alors que les calculs ne doivent que rarement être stockés dans la pratique.
COLLABORATEURS (N° Personnel, N° Département, Nom, Prénom) DEPARTEMENTS (N° Département, Désignation)
PROJETS (N° Projet, Description)
EVALUATIONS_PROJETS (N° Projet, N° Personnel, Heures, Description)
3.6.4 Quatrième forme normale
Pas tout les praticiens sont d'accord sur la définition de la quatrième forme normale donc voici la mienne:
La quatrième forme normale consiste à sortir les dépendances transitives cachées a priori dans des tables externes (toujours à l'aide d'une clé primaire et étrangère).
Par exemple le champ Nom à une dépendance transitive avec le N° Personnel car une collaboratrice peut très bien changer de nom par mariage. Il est donc mal venu de laisser le Nom là où il est si nous voulons plus avoir un historique utilisable de manière efficiente.
Par exemples le champ Heures à une dépendant transitive car rien ne nous dit qu'il va y avoir plusieurs estimations ou saisie du réel effectué et que dès lors il nous faut un change log (historique) des saisies.
Nous avons alors:
Remarque: Il y a même certains modèles avec une cinquième et sixième forme normale.
3.6.5 Exercice
Les données d'un magasin doivent être enregistrées dans une base de données. L'illustration suivante montre les données essentielles dans une table non normalisée. Esquissez un modèle ER pour les données indiquées:
1. Normalisez le projet de base de données (jusqu'à la troisième forme normale).
2. Créez une base de données MS Access avec votre formateur soit directement dans le logiciel lui-même avec les outils à disposition soit en utilisant SQL, MS Visio ou MySQL Workbench (votre formateur vous aidera)
3. Quelles mesures pouvez-vous prendre pour garantir l'intégrité des données ? 4. Créez les relations nécessaires. Quelles relations doivent être créées avec l'intégrité
référentielle et les mises à jour et suppression en cascade?
Remarque: N'hésitez pas à faire usage dans MS Access de l'outil Analyse (dans le menu Outils) qui va vous proposer de normaliser vos tables (voir les détails sur cet outil à la page 320)