CUPO Initiation aux bases de données

Chapitre 1 : Système d’information

I. Généralités sur les bases de données
1. Notion de base de données
Une base de données est définie comme étant un ensemble de données organisé en vue de
son utilisation par des programmes correspondant à des applications distinctes, et de
manière à faciliter l’évolution indépendante des données et des programmes.
Une base de données est un ensemble structuré d'informations non redondantes dont
l'organisation est régie par un modèle de données.
Une base données a les caractéristiques suivantes :
- une base de données unifie la structuration et la mémorisation des informations grâce
à un modèle (ou schéma) unique et cohérent des données ;
- ce modèle unique de données ne doit pas être lié à une application spécifique qui en
figerait la structure et doit être suffisamment général pour s’adapter à toutes les
situations particulières (d’où la nécessité dans la conception d’une base de données
d’une analyse globale et prospective des besoins).
- dans une base de données, les données sont décrites indépendamment des
programmes (ou traitements) qui les utilisent. Il doit être possible de modifier les
programmes appliqués sans avoir à redéfinir les données.

Il existe trois types de modèles de bases de données, les modèles hiérarchiques, les modèles
en réseaux et les modèles relationnels. Le modèle hiérarchique est le plus ancien ; dans ce
modèle, l’organisation des données repose sur une structure arborescente (on peut faire
l’analogie avec la gestion des fichiers sur un ordinateur) : chaque information n’a qu’un seul
supérieur hiérarchique et n’est accessible qu’à partir d’un point unique (la racine). Le
deuxième modèle est le modèle en réseaux (modèle CODASYL). Chaque information peut
être associée à plusieurs autres (plusieurs « supérieurs hiérarchiques ») et servir de point
d’entrée (il n’y a plus d’informations privilégiées), les relations entre les données étant
stockées dans la base avec les données (on peut faire l’analogie avec les liens hypermédias).
Dans le modèle relationnel, les informations sont stockées dans des tables qui sont reliées
entre elles par des relations. L’interrogation de la base de données se fait à l’aide de requêtes,
ces requêtes étant écrites à l’aide d’un langage commun à la plupart des système de gestion
de base de données SGBD : le SQL (Structured Query Language).

2. Notion de système de gestion de base de données (SGBD)

Un SGBD est un logiciel qui joue le rôle d'interface entre les utilisateurs et la Base de
Données. Un SGBD permet de décrire, manipuler et interroger les données d'une Base de
Données. Il est chargé de tous les problèmes liés aux accès concurrents, à la sauvegarde et la
restauration des données. Il doit de plus veiller au contrôle, à l'intégrité et la sécurité des
données.

La majorité des bases de données sont construites sur le modèle relationnel d’où le SGBDR.
Un SGBDR dispose d'un langage ensembliste pour la définition et la manipulation de
données. C'est un langage descriptif qui vise à faciliter la formulation des requêtes par
l'utilisateur en le déchargeant des tâches de programmation. L'utilisateur définit dans ce
langage un critère de sélection en fonction de ses besoins d’information. Il appartient ensuite

Dr SAWADOGO
Page 1
 CUPO Initiation aux bases de données

au système de bases de données d'effectuer la recherche dans la base et de produire une table
résultat.
Il existe plusieurs SGDBR. Nous allons utiliser ici le logiciel Access comme SGBD. Ce
logiciel permet une conception aisée de bases de données de "petite" taille avec un nombre
restreint d’utilisateurs. Il est à noter que plusieurs autres SGBDR plus performants (mais
également plus complexes) existent par ailleurs. On peut citer notamment Oracle, SQL
Server, Paradox, MySQL, PostgreSQL parmi beaucoup d’autres.

3. Base de données et tableur

Une erreur, fréquemment commise, consiste à confondre une base de données avec un tableur.
Même si les tables d'une base de données se présentent en lignes et colonnes, comme dans un
tableur, il y’a une grande différence entre une base de données et un tableur. Le tableau
suivant, résume les principales différences entre une base de données et un tableur.

Différences sur... Tableur Base de données

Utilisation principale Calculs Gestion et traitement des

données

Structuration des données Aucune Structuration et cohérence

forte

Contrôles d'intégrité des Aucuns Vérification stricte des

données valeurs possibles de chaque
donnée

Accès aux données Mono utilisateur Multi utilisateurs

Confidentialité des données Aucun contrôle Vérification des droits

d'accès de chaque utilisateur

Taille des données - Une table - Plusieurs tables

- Quelques dizaines de lignes - Plusieurs milliers de lignes
par table

Traitement sur les données Quantitatifs Qualitatifs et quantitatifs

Interrogations des données Réalisée par des procédures Langage "universel" : SQL
spécifiques

II. Conception d’une base de données

Pour concevoir une base de données relationnelle, il existe différentes méthodes la plus
utilisée étant la méthode Merise.

Dr SAWADOGO
Page 2
 CUPO Initiation aux bases de données

La méthode Merise considère quatre phases dans la création d’une base de données :
1. La phase d’analyse : cette phase, qui ne sera pas étudié dans ce document, est une
phase essentielle qui consiste à :
• étudier l’existant : y a-t-il un système qui gère déjà tout ou partie de
l’information, qu’il s’agisse d’un logiciel ou d’un ensemble de documents papiers
? Comment ces informations sont elles stockées ? Quelles sont les informations
stockées ? Que manque-t-il ? Qu’est ce qui convient ou ne convient pas aux
utilisateurs ?
• interroger les futurs utilisateurs : qu’attendent-ils du futur SGBD ? Quelles sont
les opérations qu’ils désirent automatiser ?
• recueillir les informations existantes, étudier les divers liens qui peuvent exister
entre ces informations, mettre en évidence les règles de gestion employées…
2. La phase conceptuelle : elle consiste à représenter l’organisation des données de manière
générale. Elle aboutit à la création du modèle conceptuel des données (MCD) dans
lequel les données sont représentées sous forme d’entités liées entre elles par des relations.
3. La phase logique ou organisationnelle : dans cette phase, la base de données est
représentée sous une forme logique plus proche de sa représentation réelle au sein du
SGBD : les informations sont représentées uniquement sous forme de tables au sein
d’un modèle logique des données (MLD).
4. La phase physique ou opérationnelle : elle consiste à construire réellement la base de
données au sein du SGBD (ici Access). Cette partie ne sera pas décrite dans cette section,
mais dans les suivantes.

1. Le modèle conceptuel de données

Un modèle de données est un formalisme permettant de décrire les données intervenant dans
un système d’informations et les liens existant entre ces informations de façon claire, simple,
complète et non ambiguë. Le Modèle Conceptuel de Données (MCD) que nous allons
construire contient deux éléments principaux : les entités et les relations.
Un ensemble d’informations se rapportant à un même thème est appelé entité ou individu.
Par exemple toutes les informations relatives aux clients d’une société forment l’entité
« Client ».

Chaque entité est caractérisée par des types de données appelées propriétés. Par exemple
numClient, nom, prenom, sommeDue, sont des propriétés de l’entité « clients ».

Chaque propriété peut prendre des valeurs.

Ex : « Ouedraogo » est une valeur prise par la propriété «Nom», « Moussa » est une valeur
prise par la propriété « prenom ».

L’ensemble des valeurs prises par un élément d’une entité s’appelle une occurrence.

L’identifiant est une propriété principale qui permet d’identifier sans ambiguïté une
occurrence. La propriété choisie ne doit en aucun cas prendre deux fois la même valeur. Les
valeurs des autres propriétés peuvent, par contre, se retrouver plusieurs fois.

Ex : « numImmatriculation » est l’identifiant de l’entité « voitures ».

Dr SAWADOGO
Page 3
 CUPO Initiation aux bases de données

Une relation est un lien possible qui relie deux entités. Elle correspond à une association
perçue dans le réel entre deux entités.

Par exemple, si un employé peut être affecté à un entrepôt, il y aura une relation "affectation"
entre l’entité entrepôt et l’entité "employé". Cela ne signifie pas nécessairement qu’il y aura
affectation pour chacun des employé, juste qu’il est possible qu’un employé soit affecté à un
entrepôt. Une relation peut éventuellement être reliée à plus de deux entités et peut avoir
certaines propriétés. La construction du MCD passe par les étapes suivantes.

a. Repérage des entités

La première étape consiste à identifier les entités du problème. Dans la description de la

situation à informatiser les entités correspondent souvent aux noms. Ce que l’on considère
comme entité est un type général.
Exemple : Soit le problème suivant :
Une société qui vend des produits veut informatiser la gestion des commandes de ses clients.
Chaque commande d’un client peut comporter plusieurs produits différents.
Les entités du problème sont :
• l’entité "produits" : un produit commercialisé par la société ;
• l’entité "clients" : une personne qui achète des produits à la société ;
• l’entité "commandes" : une liste de produits commandés par un client à la société.

b. Construction des entités, choix des propriétés.

L’étape suivante correspond à la construction des entités. On commence par donner un nom à
chacune des entités. Il faut ensuite rechercher les propriétés (ou attributs) de ces entités.
Chacune des propriétés d’une entité prend une valeur parmi une variété de valeurs possibles
(le domaine de l’attribut). Une propriété peut être obligatoire ou facultative. On devra garder à
l’esprit les points suivants :
 toute propriété est élémentaire. Elle n’est pas la composition d’éventuelles propriétés
plus petites : plutôt qu’une propriété unique adresse, il est préférable d’avoir des propriétés
rue, code postal, ville, pays etc..
 toute entité doit posséder une propriété particulière appelée sa clé (ou identifiant).
Une clé doit caractériser de manière unique chaque occurrence de l’entité.
L’identifiant d’une entité est une propriété de l’entité telle qu’à chaque valeur de la
propriété corresponde une et une seule occurrence de l’entité.
Par exemple, le nom de famille d’un étudiant ne peut pas être considéré comme une
clé d’une entité "personne" puisque deux personnes peuvent avoir le même nom de
famille. Le numéro de la carte d’identité est par contre tout à fait acceptable. Il vaut
mieux éviter les identifiants trop longs (on préférera un code de quelques chiffres à un
intitulé d’une vingtaine de lettres par exemples).
Une « bonne » clé ne doit pas comprendre un sous-ensemble qui pourrait lui même
être une clé (notion de minimalité).
 si aucune des propriétés "naturelles" ne peut servir de clé, on en rajoute une
artificiellement (par exemple "CodeProduit" ou "IdClient").
 Chaque propriété ne doit dépendre que d’une seule entité.

Une entité se représente ensuite graphiquement sous la forme d’une boîte dans laquelle on
indique en titre le nom de l’entité suivi de toutes ses propriétés. On indique d’une manière
particulière l’identifiant.

Dr SAWADOGO
Page 4
 CUPO Initiation aux bases de données

Les entités d’une base de données sont généralement représentées par des rectangles. A
l’intérieur de ces rectangles on place les propriétés de chaque entité. Pour distinguer
l’identifiant des autres propriétés, on le souligne ou on le met en gras.

Entité A

IdentifiantA
Propriété 1
Propriété 2
….

Exemple : Dans l’exemple de la gestion des commandes de la société, on peut construire

les entités suivantes (les propriétés sont indiquées après le nom de l’entité, l’identifiant est en
gras) :
• Clients (IdClient, nom, prénom, BP, ville, pays, tél, email…)
• Produits (CodeProduit, libellé, prixHT, quantité en stock …)
• Commandes (NumCommande, date, mode de paiement…)

c. Construction des relations

L’étape suivante consiste à énumérer toutes les relations possibles entre entités. Les entités
sont unies par des relations. Si une relation a une chance d’apparaître (et de nous intéresser),
alors on doit la considérer dans le MCD. On parle également parfois d’association. Les
associations sont définies en utilisant un verbe d’action, par exemple « acheter », « payer ».
Entre une table « patients » et « médecins », on aura l’association « soigner ».
Une relation se représente généralement de la manière suivante :

d. Choix des cardinalités

Chaque association est caractérisée par un nombre minimum et maximum de relations, appelé
cardinalités. On distingue plusieurs relations :

- zéro à plusieurs, notée (0,n) ou 0 :n

- zéro à un, notée (0,1) ou 0 :1

- un à plusieurs, notée (1,n) ou 1 :n

- un à un, notée (1,1) ou 1 :1

- plusieurs à plusieurs, notée (n,n) ou n :n

Dans une relation classique (i.e. entre deux entités), quatre cardinalités sont à déterminer.

Dr SAWADOGO
Page 5
 CUPO Initiation aux bases de données

Entité A Entité B

IdentifiantA min A :max A min B :max B IdentifiantB

Propriété 1 Relation Propriété 1
Propriété 2 Propriété 2
…. ….

 minA est le nombre minimal de fois où une occurrence de l’entité A participe à une
relation du type considéré. Il s’agit en général de 0 ou 1.
 maxA est le nombre maximal de fois où une occurrence de l’entité A participe à la
relation. Il s’agit en général de 1 ou n (n pour plusieurs fois, ou un nombre quelconque
de fois).
 minB et maxB fonctionnent de la même manière, mais en considérant l’entité B.

Par exemple, entre les entités « médecins » et « patients », on a les cardinalités suivantes :

 un médecin peut avoir un ou plusieurs patients, la relation « médecins », « patients »

aura donc la cardinalité (1,n)
 un patient n’est soigné que par un médecin (en général), on aura donc la cardinalité
(1,1) dans la relation « patients », « médecins ».

Exemple : Dans l’exemple de la gestion des commandes de la société, les cardinalités sont
les suivantes :
Dans la relation « Clients passe Commandes », pour l’entité Clients la cardinalité minimale
est 0 (si l’on considère que le fichier clients contient des « clients » qui n’ont encore
jamais passé de commandes) et la cardinalité maximale est n (un client peut passer
plusieurs commandes !). Dans cette même relation, pour l’entité Commandes la cardinalité
minimale est 1 (une commande est obligatoirement passée par un client !) et la
cardinalité maximale est 1 (une commande ne peut être passée par deux clients différents
!).
Dans la relation « Commandes comporte Produits », pour l’entité Commandes la cardinalité
minimale est 1 (une commande comporte au moins un produit) et la cardinalité
maximale est n (puisqu’une commande peut comporter plusieurs produits différents).
Dans cette même relation, pour l’entité Produits la cardinalité minimale est 0 (si l’on
considère que le fichier produits contient des produits qui n’ont encore jamais été commandés
!) et la cardinalité maximale est n (un produit peut figurer dans plusieurs commandes
différentes).

Le MCD complet est donc :

Dr SAWADOGO
Page 6
 CUPO Initiation aux bases de données

Remarques :

Quelques points particuliers sont à garder à l’esprit lors de la réalisation d’un MCD.
• Un identifiant est obligatoire pour chaque entité.
• Il ne doit pas y avoir de redondance d’informations : une information quelconque ne doit pas
être représentée plus d’une fois dans le MCD.
• Évitez autant que possible les relations entre plus de deux entités. Souvent, il est possible
de remplacer la relation par une entité.
• Restez dans la mesure du possible avec des cardinalités de valeurs 0, 1 ou n.

2. Modèle Logique de Données (MLD)

Une fois le MCD construit, l’étape suivante dans la conception de la base de données consiste
à concevoir le modèle logique de données, ou MLD. Ce MLD montre l’organisation des
données sous forme de tables et est très proche de la manière dont les données vont être
effectivement organisées dans Access. L’étape de transformation du MCD en MLD est assez
simple et passe par trois étapes suivantes.

a. Transformation des entités en tables

La première étape consiste à transformer toutes les entités du MCD en tables du MLD. Cette
transformation est directe : il suffit de recopier les entités. Il s’agit essentiellement d’un
changement de vocabulaire :
- une entité devient une table,
- une propriété devient un champ,
- un identifiant devient une clé primaire,
- une occurrence d’une entité devient un enregistrement de la table.
A noter toutefois qu’il est essentiel qu’il n’y ait pas deux tables qui aient le même nom.
Exemple : la première partie de la construction du MLD de la société est directe. Il suffit de
recopier les entités.

Dr SAWADOGO
Page 7
 CUPO Initiation aux bases de données

Clients
IdClient Commandes
Nom NumCommande
Prénom Date
…. Mode de paiement
….

Produits
CodeProduit
Libellé
PrixHT
Quantité en stock
….

b. Transformation des relations du MCD

L’étape suivant consiste à transformer les relations du MCD en liens du MLD. Deux grands
cas peuvent se présenter.
Premier cas : Une des branches de la relation a une cardinalité maximale de 1 (1:1 ou 0:1)
la transformation de la relation se fait de la manière suivante :
• On ramène dans la table correspondant à l’entité "du côté du 1:1" (ou du 0:1) la clé
primaire de l’autre table ainsi que toutes les éventuelles propriétés de la relations.
• On lie la clé primaire ainsi importée avec la clé primaire de la deuxième table.
• Si la relation contenait des propriétés, celle-ci se retrouve également importées du côté
du 1:1.

A noter que la clé importée (ici IdentifiantB qui se retrouve dans table A) ne devient pas une
clé de la table : c’est une propriété comme une autre. Notons aussi que le lien se fait entre

Dr SAWADOGO
Page 8
 CUPO Initiation aux bases de données

champs (on relie IdentifiantB à IdentifiantB) et non pas, comme dans le MCD, entre les
tables.
Par exemple dans une société autorisant la polygamie mais interdisant la polyandrie,

Deuxième cas : les deux branches de la relation ont une cardinalité maximale de n (1:n ou
0:n). Dans ce cas, la relation du MCD se transforme en une table du MLD :
• On crée une nouvelle table correspondant à la relation. Cette table contient toutes les
éventuelles propriétés de la relation.
• On intègre à cette table les clés primaires des entités impliquées dans la relation.
• On relie les clés primaires des tables avec les clés importées dans la nouvelle table.
• On choisit enfin la ou les clés primaires de la nouvelle table. L’idée générale est que
chaque occurrence de cette entité doit pouvoir être identifiée de manière unique par
ses clés primaires. Cela revient en général à choisir comme clé primaire l’ensemble
des clés importés des autres tables.

c. Suppression des tables inutiles

Dr SAWADOGO
Page 9
 CUPO Initiation aux bases de données

La dernière étape consiste simplement à supprimer les tables inutiles. En général (mais pas
toujours), une table qui ne contient qu’un seul champ (sa clé) est inutile : elle ne nous apporte
aucune information. L’exemple le plus classique est une entité de type "date".

Exemple : Le MLD correspondant à l’exemple de la société qui veut informatiser la gestion

de ses commandes :

En résumé

1. les entités sont transformées en tables (sans modification)

2. les relations sont transformées en fonction de leurs cardinalités :
• une relation de type ?:1 - ?:n entre une entité A et une entité B se traduit par une
importation de la clé primaire de l’entité B dans la table de A, et on ajoute un lien entre les
deux clés,
• une relation de type ?:n - ?:n ) se transforme en table dans laquelle on retrouve les clés
primaires de A et B.
3. les tables inutiles sont supprimées : il s’agit essentiellement des tables à un seul champ
(leur clé).

Dr SAWADOGO
Page 10