Gestion de la bibliothèque du département Génie Civil

Introduction

Le département Génie Civil est l’un des rares départements de l’Ecole Polytechnique de
Masuku ayant en son sein une bibliothèque. Elle possède un patrimoine très varié de
documents, entre autres des ouvrages, des rapports de stage des techniciens supérieurs ainsi
que les mémoires de stage des ingénieurs.

La gestion efficace et durable de ce patrimoine, profitant aussi bien aux enseignements qu’aux
étudiants dudit département, est donc indispensable et nécessaire. Ce qui conduira à la
réalisation d’une Base de Données.

C’est dans ce cadre que s’inscrit ce projet tutoré, dont le but est de concevoir une Base de
Données et une interface permettant de l’a gérer.

Après l’étude de la conception d’une base de données en général, nous nous pencherons en
particulier sur celle de la base de données de ladite bibliothèque.

Rapport de projet tutoré 1

 Gestion de la bibliothèque du département Génie Civil

CHAPITRE 1 : PRINCIPES FONDAMENTAUX DE LA CONCEPTION D’UNE BASE DE DONNEES

La conception d’une base de données commence par la définition du système à étudier. C’est
un élément fini dont le périmètre constitue la frontière qui le sépare de son environnement.
Il reçoit de son environnement des flux d’informations entrantes, qu’il va traiter et les
retourner ensuite sous formes de flux d’informations sortantes. Sans un dispositif de
maîtrise de ces flux, le système peut très vite être dépassé et ne plus fonctionner avec
une qualité de service satisfaisante (DI GALLO, 2001). D’où la nécessité de les stocker et de
les traiter au sein d’une Base de Données.

Le choix de la méthode d’analyse est l’étape suivante, après la définition du système. Pour ce
projet, nous choisirons la méthode MESIRE (cf. I)

I. Méthode MERISE

MERISE est un acronyme signifiant Méthode d’Étude et de Réalisation Informatique par les S
ous-Ensembles ou pour les Systèmes d’Entreprise.

Nous devons la création, l’étude et la mise en place de cette méthode à une équipe
de chercheurs et d’ingénieurs aixois (Jean-Louis le Moigne, Hubert Tardieu, Dominique Na
ncy, Henry Heckenroth, Daniel Pasco, Bernard Espinasse) qui en posèrent les bases dans le m
ilieu des années 1970. (BAPTISTE)

MERISE est née vers 1978-1979, à la suite d'une vaste consultation lancée en 1977 par le
ministère français de l'Industrie. Le but était de mettre au point une méthode de troisième
génération de conception-réalisation de systèmes d'information (Introduction à la méthode
Merise).

Les deux principales sociétés ayant mis au point cette méthode sont le CTI (Centre
Technique d'Informatique) chargé de gérer le projet, et le CETE (Centre d'Etudes
Techniques de l'Equipement) implanté à Aix-en-Provence (DI GALLO, 2001).

Rapport de projet tutoré 2

 Gestion de la bibliothèque du département Génie Civil

Aujourd'hui, MERISE est largement utilisée dans le monde. Plusieurs logiciels de

développements (comme WINDEV de la société PC SOFT) ont été conçus autour de cette
méthode.

MERISE se caractérise par :

 Une approche systémique ;

 Une séparation des données (statiques) et des traitements (dynamiques) ;
 Une approche par niveaux.

Le côté dynamique, les traitements, ne seront pas abordé dans ce projet étant donné qu’il
s’agit de la conception d’une Base de données.

Enfin, la méthode MERISE permettra de mettre successivement en exergue les niveaux

suivants :

 Modèle Conceptuel de Données (MCD) ;

 Modèle Logique de Données Relationnelles (MLDR ou MLD) ;
 Modèle Physique correspondant (MPD).

II. Modèle Conceptuel de Données

Avant de réfléchir à un schéma relationnel d’une application, il est important de modéliser le

problème posé indépendamment d’un quelconque logiciel de programmation : c’est le but de
cette partie. Ceci laissera le choix aux différents utilisateurs de traduire le modèle dans le
langage de programmation voulu. Pour se faire, il y a plusieurs étapes importantes à suivre.

1. La description du système

L’étape primordiale est de décrire le système ainsi que les liens existant avec son
environnement. Il s’agit d’écrire de façon formelle les données ou flux d’informations en
utilisant des phrases simples et correctes (sujet + verbe + compléments d’objet. L’utilisateur

Rapport de projet tutoré 3

 Gestion de la bibliothèque du département Génie Civil

doit pouvoir identifier dans cet énoncé, les différents éléments caractéristiques d’un MCD :
Entité, Attributs, Identifiant, Association et Cardinalité.

La grande difficulté ici est de faire abstraction de tout reflexe de programmation, à ce stade
c’est l’indépendance totale du matériel et du logiciel qui doit s’exprimée.

2. L’entité

Une entité est la représentation d’un élément matériel ou immatériel ayant un rôle dans le
système à décrire (DI GALLO, 2001). Elle est caractérisée par un nom (NOM_ENTITE), des
attributs (cf. 3) dont elle doit en avoir au moins un (1) et des élémenst ou occurrences. Pour
qu’une entité soit valide, elle doit posséder deux (2) occurrences au minimum.

NOM_ENTITE

Figure 1 : Représentation d’une entité.

3. Les attributs

Un attribut (ou propriété ou rubrique) est une information élémentaire, c’est-à-dire non
déductible d’autres informations, qui présente un intérêt pour le système étudié. Chaque
valeur prise par un attribut est appelée occurrence. Toutes les propriétés permettant de
décrire clairement le système doivent être prises ne considérations, chacune identifiant par
un nom qui doit être le plus explicite possible.

En outre, l’identification de chaque propriété consiste à garantir une bijection entre

l’ensemble des noms et l’ensemble des propriétés à gérer. On devra donc exclure les
synonymes qui correspondent à deux noms différents pour identifier la même propriété et les
polysèmes qui représentent deux propriétés différentes ayant le même nom (DI GALLO, 2001).
L’apparution d’une propriété doit obéïr au principe de non redondance.

Rapport de projet tutoré 4

 Gestion de la bibliothèque du département Génie Civil

NOM_ENTITE
- Attribut 1
- Attribut 2
- Attribut 3
- …

Figure 2 : Représentation d’une entité avec ses attributs.

4. L’identifiant

Chaque individu d’une entité doit être identifiable de manière unique. C’est pourquoi les
entités doivent posséder un attribut sans doublon, l’identifiant (GRUAU, 2003). Il peut être
une référence interne, un code, ou plus généralement un nombre entier. Cette propriété est
soulignée afin de mettre en évidence son rôle d’identifiant (Introduction à la méthode
Merise). La connaissance d’une valeur de l’identifiant permet de connaître les valeurs des
autres attributs, on ainsi un ensemble appelé occurrence d’entité.

NOM_ENTITE
- Identifiant
- Attribut 2
- Attribut 3
- …

Figure 3 : Représentation d’une entité avec ses attributs dont un identifiant.

5. L’association

La simple transposition de l’énoncé décrivant le système nous permet d’identifier les

différentes entités, à savoir les sujets et compléments d’objet. Tandis que l’association sera la
relation qui lie ces entités, notamment les verbes. Un verbe à l’infinitif suffit pour désigner
une association. Elle peut aussi avoir des attributs, dans ce cas elle est dite porteuse. Il existe
plusieurs types d’association, il sera nommé ici que les plus courantes :

Rapport de projet tutoré 5

 Gestion de la bibliothèque du département Génie Civil

 Association flexible, lorsque l’entité est relation avec elle-même ;

 Association binaire, dans le cas de deux entités en relation ;
 Association ternaire, pour trois entités en relation.

Associer

- Attribut 1
- Attribut 2
- ...

Figure 4 : Représentation d’une association.

6. La cardinalité

La cardinalité est le nombre de possible d’interactions entre les entités liées. C’est un couple
d’entiers naturels de type (m, M), où m désigne la cardinalité minimale et prenant la valeur 0
ou 1 ; tandis que M désigne la cardinalité maximale et prenant la valeur 1 ou n (𝒏 ≥ 2) .

Si la cardinalité est connue et vaut 2, 3, etc, on considère quand même qu’elle est
indéterminée n, de telle sorte qu’on ne puisse avoir que des cardinalités 0, 1 ou n.

Après avoir défini et recensé tous ces éléments, nous pouvons alors construire le MDC
correspondant qui n’est rien d’autre qu’un schéma recapitulatif de ces différents éléments.

NOM_ENTITE1
NOM_ENTITE2
- Identifiant1
- Identifiant2
- Attribut 2 1, n 0, 1 - Attribut 2
- Attribut 3 Associer
- Attribut 3
- … - Attribut 1 - …
- Attribut 2
- …

Figure 5 : MCD constitué d l’association de deux entités, avec les cardinalités correspondantes en rouge. Ces
valeurs sont à titre indicatif.

En résumé, la construction d’un MCD répond à un certaines règles de normalisation. Elles sont
les suivantes :

Rapport de projet tutoré 6

 Gestion de la bibliothèque du département Génie Civil

 1ere forme Normale : Chaque entité doit disposer d'un identifiant qui la caractérise de
manière unique ;
 2eme forme Normale : Les propriétés d'une entité ne doivent dépendre que de
l'identifiant de l'entité et non d'une partie de cet identifiant. Un identifiant peut être
composé de la concaténation de plusieurs propriétés ;
 3eme forme Normale : Les propriétés d'une entité doivent dépendre de l'identifiant de
l'entité de manière directe ;
 Forme Normale de BOYCE-CODD : Pour les identifiants composés de plusieurs
propriétés, ces dernières ne doivent pas être dépendantes d'une autre propriété de
l'entité ;
 Normalisation des relations : Les propriétés des relations doivent dépendre de tous les
identifiants des entités associées ;
 Décomposition des relations : Les relations dont le nombre d'entités associé est trop
important (supérieur à 3) doivent être décomposées en plusieurs relations.
Cette décomposition ne peut se faire qu'à la condition d'avoir une cardinalité minimum
égale à 1.

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

La construction d’un MCD a permis de décrire le plus fidèlement possible les réalités du
système étudié. Cependant, cette description ne peut être directement traitée et accepter par
un système informatique. D’où la nécessité de la traduire dans un langage proche de celui
d’un système informatique, ceci conduit au Modèle Logique de Données. Il sera abordé dans
cette partie le modèle relationnel, sachant qu’il en existe deux autres qui sont les modèles
hiérarchique et réseau.

La traduction d’un MCD en MLD, dans le cas du modèle relationnel, doit se faire en suivant
cinq règles.

Règle 1 : toute entité devient une table dans laquelle les attributs deviennent des colonnes.
L’identifiant de l’entité constitue alors la clé primaire de la table.

Rapport de projet tutoré 7

 Gestion de la bibliothèque du département Génie Civil

Par exemple, l’entité NOM_ENTITE de la figure 2 devient :

NOM_ENTITE (Identifiant, Attribut 2, Attribut 3, ...)

Règle 2 : dans le cas de deux entités reliées par une association de type 1 : 1, on ajoute aux
deux tables une clé étrangère vers la clé primaire de l’autre. Les attributs de l’association sont
alors repartis vers l’une des deux tables.
La relation entre les entités NOM_ENTITE1 et NOM_ENTITE2 est traduite comme suit :
NOM_ENTITE1 (Identifiant1, Attribut 2, Attribut 3, #Identifiant2, ...)
NOM_ENTITE1 (Identifiant2, Attribut 2, Attribut 3, #Identifiant1, ...)

NOM_ENTITE1 NOM_ENTITE2
- Identifiant1 - Identifiant2
- Attribut 2 - Attribut 2
- Attribut 3 - Attribut 3
- #Identifiant2 - #Identifiant1
- … - …

Figure 6 : Traduction d’une relation de type 1 :1.

Règle 3 : dans le cas de deux entités reliées par une association de type 1 : n, l’identifiant de
l’entité côté (0, n) ou (1, n) devient une clé étrangère vers la clé primaire de la table côté (0,
1) ou (1, 1). Les attributs de l’association glissent vers la table côté (0, 1) ou (1, 1).
L’exemple précédent peut être adapté comme suit :
NOM_ENTITE1 (Identifiant1, Attribut 2, Attribut 3, ...)
NOM_ENTITE1 (Identifiant2, Attribut 2, Attribut 3, #Identifiant1, ...)

NOM_ENTITE1 NOM_ENTITE2
- Identifiant1 - Identifiant2
- Attribut 2 - Attribut 2
- Attribut 3 - Attribut 3
- … - #Identifiant1
- …

Rapport de projet tutoré 8

 Gestion de la bibliothèque du département Génie Civil

Figure 7 : Traduction d’une relation de type 1 : n, où NOM_ENTITE1 est du côté (0, n) ou (1, n), tandis que
NOM_ENTITE2 est du côté (0, 1).

Règle 4 : une association entre deux entités et de type n : m est traduite par une table
supplémentaire (parfois appelée table de jointure) dont la clé primaire est composée de deux
clés étrangères vers les clés primaires des deux tables en association. Les attributs de
l’association deviennent des colonnes de cette table.
Dans ce cas d’espèce, la traduction est :
NOM_ENTITE1 (Identifiant1, Attribut 2, Attribut 3, ...)
Associer(#Identifiant1, #Identifiant2, Attribut 3, …)
NOM_ENTITE2 (Identifiant2, Attribut 2, Attribut 3, #Identifiant1, ...)

NOM_ENTITE1 Associer NOM_ENTITE2

- Identifiant1 - #Identifiant1 - Identifiant2
- Attribut 2 - #Identifiant2 - Attribut 2
- Attribut 3 - Attribut 3 - Attribut 3
- … - … - …

Figure 8 : Traduction d’une relation de type n : m.

Règle 5 : une association entre trois entités ou plus est traduite par une table supplémentaire
dont la clé primaire est composées d’autant de clés étrangères que d’entités. Les attributs de
l’association deviennent des colonnes de cette table.
Dans ce cas d’espèce, la traduction est :
NOM_ENTITE1 (Identifiant1, Attribut 2, Attribut 3, ...)
Associer(#Identifiant1, #Identifiant2, #Identifiant3, Attribut 4, …)
NOM_ENTITE2 (Identifiant2, Attribut 2, Attribut 3, ...)
NOM_ENTITE3 (Identifiant3, Attribut 2, Attribut 3, ...)

Rapport de projet tutoré 9

 Gestion de la bibliothèque du département Génie Civil

NOM_ENTITE1 NOM_ENTITE2
- Identifiant1 - Identifiant2
- Attribut 2 - Attribut 2
- Attribut 3 - Attribut 3
- … - …

Associer
- #Identifiant1
- #Identifiant2
- #Identifiant3
NOM_ENTITE3 - Attribut 4
- Identifiant3 - …
- Attribut 2
- Attribut 3
- …

Figure 9: Traduction d’une relation entre trois entités.

IV. Modèle Physique de Données (MPD)

Bien que certains outils (PowerAMC notamment) considèrent que le MPD et le MLD
représentent la même chose, c’est faux. Le MPD est une implémentation particulière du MLD
pour un matériel, un environnement et un logiciel donné.

Notamment, le MPD s’intéresse au stockage des données à travers le type et la taille (en octets
ou en bits) des attributs du MCD. Cela permet de prévoir la place nécessaire à chaque table
dans le cas d’un SGBDR (Système de Gestion des Base de Données Relationnelles).

Le MPD tient compte des limites mat´erielles et logicielles afin d’optimiser l’espace consommé
et d’optimiser le temps de calcul (qui repr´esentent deux optimisations contradictoires). Dans

Rapport de projet tutoré 10

 Gestion de la bibliothèque du département Génie Civil

le cas d’un SGBDR, le MPD définit les index et peut être amené à accepter certaines
redondances d’information afin d’accélérer les requêtes. (GRUAU, 2003).

Conclusion partielle

La méthode MERISE est simple à utiliser, c’est son avantage premier. Elle demande néanmoins
de l’attention à l’utilisateur, notamment dans la construction du MCD qui est la base de la
résolmution du problème à traiter. Une mauvaise analyse de la situation produit un mauvais
MCD, ce qui peut compliquer la traduction dans les niveaux suivants.

Rapport de projet tutoré 11

 Gestion de la bibliothèque du département Génie Civil

CHAPITRE 2 : APPLICATION A LA BIBLIOTHEQUE DU DEPARTEMENT GENIE CIVIL

Il s’agit de cette partie d’application les principes fondamentaux de la conception d’une base
de données vus au chapitre précédent à un système bien défini. Dans le cas d’espèce, le
système étudié est la bibliothèque du département Génie Civil.

Il est rappelé que la méthode d’approche utilisée est la méthode MERISE.

I. Modèle Conceptuel de Données

1. La description du système

Le département Génie Civil a en son sein une bibliothèque.

Dans cette bibliothèque, il y est rangés des ouvrages, des rapports de stage des techniciens
supérieurs et les mémoires de stage des ingénieurs.
Les différents documents sont classé dans chaque rayon en fonction de la matière ou de la
discipline d’étude. Ces documents sont écrits par des auteurs et ont si possible une maison
d’édition et possible une collection.
Les étudiants et enseignants empruntent des documents.
La durée limite d’emprunt est d’une (2) semaines pour les étudaints ; depassé ce délai,
l’étudiant est pénalisé. Il doit faire un mois avant d’emprunter à nouveau.
Chaque étudiant est inscrit au département pour filière bien précise. Il y a deux filières : le
cycle court (cycle technicien supérieur) et le cycle long (cycle ingénieur).

2. Les entités

Dans la description précédente, les entités qui en ressort sont :

 ETUDIANT ;
 ENSEIGNANT ;
 DOCUMENT ;
 AUTEUR ;
 EDITEUR;
 COLLECTION ;
 FILIERE ;

Rapport de projet tutoré 12

 Gestion de la bibliothèque du département Génie Civil

 RAYON ;
 DISCIPLINE.

3. Les attributs

Les attributs sont listés dans chaque entité considérées. L’identidiant de l’entité est toujours
sousligné. On obtient donc :

ETUDIANT ENSEIGNANT

1 - 1
IdENSEIGNANT
- IdETUDIANT
- Nom - Nom
- Prénom - Prénom
- Date de naissance - Date de naissance
- Téléphone - Téléphone
- Résidence - Résidence

DOCUMENT AUTEUR
- IdDOCUMENT 1
- IdAUTEUR
- Titre
- Nom
- Type
- Prénom
- Pseudo
EDITEUR
- Date de naissance
- IdEDITEUR - Nationalité
- Nom - Langue d’écriture
- Ville - Date de décès

COLLECTION FILIERE
- IdCOLLECTION - IdFILIERE
- Nom - Nom

RAYON DISCIPLINE
1 1
- NumRAYON - IdDISCIPLINE
- Nom - Nom

Rapport de projet tutoré 13

 Gestion de la bibliothèque du département Génie Civil

4. Les associations
La description du système permet de noter les associations suivantes :

Rapport de projet tutoré 14