Accueil Recherche | Plan Technique | Liens | Actualités | Formation | Emploi | Forums | Base
TUTORIEL cerig.efpg.inpg.fr 
Vous êtes ici : Accueil > Formation > Tutoriels > Bases de données relationnelles > Le schéma relationnel
        Révision : 28 décembre 2002
 
                  Les bases de données
relationnelles
                 
Chap.
précéd.
Plan du
tutoriel
Liste des
tutoriels
Chap.
suivant
 
Chapitre 6 : le schéma relationnel de la base
 
1 - Introduction
                  Nous avons vu au chapitre précédent que l'informatisation des données courantes de l'entreprise nécessite la création de plusieurs tables, reliées entre elles via des codes. Pour que le système fonctionne, il faut que les relations entre tables soient du type 1-n. Si on rencontre une relation de type n-n, on peut toujours la scinder en deux relations de type 1-n par création d'une table supplémentaire, dite table de jonction.          
On attribue généralement la paternité des premiers travaux consacrés aux BDD relationnelles à un chercheur de la compagnie IBM nommé Ted Codd. En 1970, il publia un article sur les bases de données relationnelles, au contenu très mathématique. Les méchantes langues vous diront que tous ceux qui publient sur le sujet des BDD citent cet article, mais que fort peu l'ont lu (l'auteur de ces lignes est dans ce cas).
En termes savants, Codd voulait assurer l'indépendance entre l'organisation logique des données et la technique informatique utilisée pour les stocker. En termes simples, il cherchait une méthode permettant de stocker des données (structurées) de toute nature, sans recourir chaque fois à de la programmation spécifique. Ted Codd est considéré comme le créateur de l'algèbre relationnelle (l'aspect théorique des bases de données), qui utilise la théorie des ensembles.
En 1976, P. Chen proposa le modèle entité-relation. Depuis, ce modèle est presque universellement utilisé pour établir le schéma relationnel des BDD.
Au cours des années 70, des laboratoires universitaires et des entreprises travaillèrent à mettre au point les bases de données relationnelles. A la fin des années 70, plusieurs produits arrivèrent sur le marché. A cette époque, les micro-ordinateurs étaient encore dans l'enfance, et les premiers SGBD relationnels furent implantés sur des mini-ordinateurs ou des mainframes. Progressivement, les SGBD relationnels reléguèrent aux oubliettes les SGBD hiérarchiques qui les avaient précédés. C'est également à cette époque qu'apparut le SQL, le langage de manipulation des BDD relationnelles.
Une dizaine d'années plus tard, les micros avaient acquis assez de puissance pour accueillir les SGBD relationnels. C'est alors que Microsoft introduisit la première version d'Access sur le marché. En une dizaine d'années, ce SGBD de milieu de gamme est devenu très populaire, bien qu'il reste moins connu que le traitement de texte et le tableur qui l'accompagnent dans la version professionnelle de la suite bureautique "Office".
2 - Les entités
                  Le terme "entité" est utilisé de manière générique pour désigner les données. A la grande réprobation des puristes, nous utiliserons ces deux termes comme s'ils étaient synonymes.          
Lorsqu'on veut gérer des données (structurées) par des moyens informatiques, la première opération consiste à les recenser, puis à les classer (dans la mesure du possible) par ordre d'importance décroissante. Un exemple relativement simple concerne les données que l'on trouve sur les cartes de visite, données que l'on peut utiliser pour se créer une liste de contacts, à l'échelle d'une personne, d'un service ou d'une entreprise. Ces données sont peu nombreuses, et elles se trouvent pratiquement rangées par ordre d'importance décroissante.
Le logo de l'entreprise mis à part, on trouve typiquement sur une carte de visite professionnelle :
            le nom de l'entreprise
  le nom et le prénom de la personne
  la fonction
  le contact : adresse, téléphone, fax, mail, etc.
3 - Les relations 1-1
                  Commençons par un cas simple : le nom d'une personne et son prénom sont liés de manière univoque. Nous dirons que le nom et le prénom sont liés par une relation "un à un" ou "1-1". Nous les placerons dans la même table (que nous appellerons "Personnes"), sur la même ligne, et dans des colonnes adjacentes. D'une manière générale, nous placerons dans la même table les données qui sont en relation 1-1 entre elles. Ce sera notre première règle.          
Certes, un même prénom peut être associé à des noms de famille différents, mais il ne viendrait à l'esprit de personne de se compliquer la vie pour si peu. Ce n'est pas parce que le même prénom revient toutes les 50 lignes dans une base de données qu'il faut crier à la redondance. Par ailleurs, une faute d'orthographe sur le prénom n'est pas un drame : il est peu probable que nous effectuions des recherches dans notre base de contacts en utilisant un critère basé sur le prénom.
On pourrait même songer à rassembler le nom et le prénom dans une même colonne. Cette façon de procéder est généralement considérée comme maladroite, car on n'est pas sûr de la manière dont seront saisies les informations : le nom d'abord et le prénom ensuite, ou l'inverse ? Même si une consigne est édictée, il n'est pas sûr qu'elle soit toujours respectée. Il est donc préférable de séparer les deux informations, et de les placer dans des colonnes distinctes. Cette façon de procéder est appelée l'atomisation des données. Il faut en user avec bon sens.
4 - Les relations 1-n
                  Examinons maintenant la relation qui existe entre la personne et l'entreprise. Excluons pour l'instant le cas où une personne exerce plusieurs fonctions. Nous pouvons alors construire les deux phrases suivantes :          
            une personne est employée par une seule entreprise ;
  une entreprise emploie (généralement) plusieurs personnes.
Nous avons affaire à une relation "un à plusieurs" ou "1-n" entre la personne et l'entreprise. Si nous plaçons le nom de l'entreprise dans la même table que le nom de la personne, nous créons de la redondance chaque fois que nous établissons un contact avec une nouvelle personne de la même entreprise. Nous placerons donc les personnes et les entreprises dans des tables distinctes (nous appellerons la seconde "Organismes", et non "Entreprises", parce qu'une même entreprise peut comporter plusieurs établissements ou organismes : un siège social, des usines, des agences, des filiales, etc.).
D'une manière générale, chaque fois que nous rencontrerons une nouvelle relation 1-n, nous créerons une nouvelle table. Ce sera notre deuxième règle.
De plus, nous devons indiquer au système quelles sont les personnes qui font partie d'une entreprise donnée. Nous créerons donc une relation entre les tables "Personnes" et "Organismes". En pratique, nous attribuerons un code à chaque organisme, et nous utiliserons ce code dans la table "Personnes", comme le montre l'exemple ci-dessous. Nous constatons immédiatement que nous avons eu un contact avec deux personnes (Durand Pierre et Machin Jean) travaillant pour l'organisme CQFD.
Nom Prénom Code_org
Durand Pierre 3
Chose Monique 1
Machin Jean 3
Truc Stéphanie 4
etc.
       
Code_org Organisme
1 ABCD
2 XYZ
3 CQFD
4 EFPG
etc.  
Table "Personnes" Table "Organismes"
D'une manière générale, nous recenserons toutes les relations 1-n existant entre les données, de manière à les introduire dans le SGBD. Ce sera notre troisième règle.
5 - Les relations n-n
                  L'expérience montre que l'on rencontre des personnes qui exercent dans des entreprises différentes (affiliation multiple). Le cas est même fréquent chez les cadres supérieurs, où l'on est volontiers directeur d'une usine et PDG d'une filiale. On rencontre également le cas de personnes qui partagent leur temps entre une entreprise et un établissement d'enseignement, ou une entreprise et un syndicat patronal, etc. Si nous voulons tenir compte de ces cas en évitant la redondance, nous sommes amenés à modifier les phrases précitées :          
            une personne peut être employée par plusieurs organismes (entreprise, établissement d'enseignement, syndicat patronal, association, etc.) ;
  un organisme emploie généralement plusieurs personnes.
Nous nous trouvons alors face à une relation qui semble être 1-n dans les deux sens, ce qui signifie qu'il s'agit d'une relation "plusieurs à plusieurs" ou "n-n".
Pour gérer une telle relation, il faut introduire un code dans la table "Personnes", puis créer une table supplémentaire (appelée "Affiliation"), dans laquelle on introduit les informations relatives aux couples personne-organisme, en utilisant les codes correspondants. Cette procédure est illustrée dans l'exemple ci-dessous. Nous voyons que Durand travaille pour deux organismes, CQFD et EFPG.
Nom Code_per
Durand 1
Chose 2
Machin 3
Truc 4
etc.  
       
Code_per Code_org
2 1
1 3
1 4
3 3
etc.
       
Code_org Organisme
1 ABCD
2 XYZ
3 CQFD
4 EFPG
etc.
Table "Personnes" Table "Affiliation" Table "Organismes"
Entre une personne et une affiliation, il existe une relation 1-n, de même qu'entre un organisme et une affiliation. Cet exemple nous montre, comme dans le chapitre précédent, que toute relation n-n peut être scindée en deux relations 1-n en introduisant une table supplémentaire appelée table de jonction. Ce sera notre quatrième règle.
6 - Le schéma relationnel
                  En poursuivant l'analyse des relations existant entre les données comme nous l'avons fait ci-dessus, nous dressons la liste des tables et des relations. Il est d'usage de représenter l'ensemble tables+relations dans un schéma relationnel qui se présente comme le montre l'exemple ci-dessous. Pour des raisons de simplicité, nous avons évité d'atomiser l'adresse.          
Comme vous pouvez le constater, les tables sont ici représentées de manière différente. La liste des champs s'étend verticalement sous le nom de la table, de manière à pouvoir représenter correctement les relations. Ce changement de représentation est dû au fait que nous traitons ici des problèmes de structure et non de contenu (cf. le chapitre 3).
Des annexes ont été crées pour vous aider. Le traitement correct de l'adresse fait l'objet de l'annexe 10. Le schéma relationnel complet de la liste des contacts figure dans l'annexe 11. Un autre exemple (liste de fournisseurs) est traité dans l'annexe 12.
(Ces annexes seront mises en ligne au mois de mars prochain)
7 - Conclusion
                  Dans le processus de création d'une base de données, l'établissement du schéma relationnel de la base de données représente l'étape fondamentale. Il est inutile d'aller plus loin, et de se ruer sur l'ordinateur, tant que cette étape n'est pas parfaitement maîtrisée.          
Comme vous pouvez le constater, on n'utilise pas de moyens informatiques au cours de cette étape. Il existe certes des logiciels d'aide à la création du schéma relationnel, qui rendent service dans les cas très complexes, mais les cas que vous rencontrerez nécessiteront surtout de la réflexion, de la méthode et du bon sens. Vos outils seront du papier, un crayon... et une bonne gomme !
Lorsque le schéma relationnel vous parait bon, testez-le par simulation sur papier. Suivez les relations et vérifiez que pouvez remplir les tables sans problème. Alors, mais alors seulement, vous pouvez vous asseoir devant l'ordinateur, et lancer le SGBD. Mais là encore, soyez prudent : dès que vous avez introduit une petite quantité de données, testez le système et retestez-le. Car corriger le schéma relationnel d'une BDD qui est déjà remplie de données est presque toujours une opération douloureuse.
Chapitre  précédent Plan du tutoriel Liste des tutoriels Chapitre suivant
Accueil | Technique | Liens | Actualités | Formation | Emploi | Forums | Base
Copyright © CERIG/EFPG 1996-2003
Réalisation et mise en page : J.C. Sohm