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