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.

 

 

 

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

 

         

       

 

         

 

 

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.

         

 

 

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).

 

 

 

 

 

 

 

 

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.