Developement Des SI

YAOUNDE HIGHER SCHOOL OF ECONOMICS AND
MANAGEMENT
B.P.: 12 687 Yaoundé Tél.: (237) 243 26 31 86 / 698 18 25 53 / 652 62 20
E-mail: info@ysem.education Site web: www.ysem.education
Arrêté de création No14/0140/MINSUP/SG/DDES du 14 avril 2014
Arrêté d’ouverture No15/0141/MINESUP/SG/DDES du 02 avril 2015
LICENCE PROFESSIONNELLE ELITE

EN TI
TITRE : DEVELOPPEMENT DES

SYSTEMES D’INFORMATION
MBELEN A TSANGMINA, ing
ANNEE ACADEMIQUE 2022-2023
COURS DE DEVELOPEMENT DE SI licence TI / MBELEN A TSANGMINA, ing

1
Chapitre 1 : RAPPEL SUR LA METHODE DE CONCEPTION DES
SYSTEMES D'INFORMATION
Objectifs : L'objectif de cet enseignement est double. Tout d'abord faire comprendre à des
étudiants en informatique les notions de base sur les systèmes d'information. Et ensuite
étudier et utiliser une méthodologie pour la conception de systèmes informatiques.
A la fin de ce cours, l'étudiant sera capable de :
 Comprendre les objectifs de la méthode MERISE et les différents niveaux de sa démarche,

 Connaître le vocabulaire spécifique de la méthode,
 Discerner la complémentarité des approches de type systémique et analytique,
 Savoir formaliser les modèles conceptuel et organisationnel de MERISE, identifier les
rôles et responsabilités des différents acteurs impliqués dans le processus de conception.
Prérequis : - notions de programmation Description :

Le cours commence par la définition de concepts de base utilisés dans la conception des
systèmes d'information. Il replace ceux-ci dans le contexte d'informatisation. Une méthode
d'analyse et de conception des systèmes d'information est ensuite étudiée : MERISE. D'abord
dans ses aspects fondamentaux, puis dans ses aspects les plus pratiques qui permettent de
mettre en œuvre la méthode pour des cas concrets.
Introduction Description :
Lorsqu'on parle d'informatisation, les systèmes d'information sont incontournables. Il est
normal que dans une filière qui concerne l'informatisation, les systèmes d'informations
soient largement étudiés. Étant donné l'importance du sujet, cette étude se divise en deux
parties
Ce cours constitue la première partie de l'étude des systèmes d'informations (S.I. ou I.S. :
Information System en anglais).
Il a pour principal objet de présenter la méthode MERISE, très largement utilisée dans le
monde francophone. Il commence par une brève présentation de quelques notions liées au
sujet. Il se poursuit par l'étude proprement dite de Merise. Cette étude concerne
essentiellement les modèles utilisés. MERISE étant également une démarche, celle-ci est
ensuite présentée. Le cours se termine par une étude de cas qui montre la succession d'étapes
dans la mise en œuvre de MERISE.

Sur les systèmes d'information
Description : Nous aborderons dans cette section les notions et concepts utiles nous
Permettant d'évoquer l'analyse informatique dans les termes appropriés
Concepts de base
Quelques définitions utiles.
Processus
Séquence de phénomènes dynamiques (mouvements, réactions chimiques, activités
cellulaires, opérations techniques, actions ou comportements, interactions humaines) menant à
des résultats déterminables. En analyse des systèmes : tout changement dans le temps de
matière, d'énergie ou d'information qui se produit dans le système, traitant ces variables
d'entrée et les menant aux variables de sortie.
www.mcxapc.org/static.php
Ensemble d'opérations, logiquement liées, aboutissant à certains résultats. En conception de

systèmes d'information, selon la méthode Merise, le processus se situe au niveau du modèle
conceptuel de traitement. revuesim.free.fr/index.php
Étapes ou phases de la méthode d’exécution ou de fonctionnement de quelque chose, que

ce soit dans les systèmes commerciaux ou techniques, mettant en cause les actions de plus
d’une personne, d’une unité ou d’une division. Système d’opérations dans la production de
quelque chose. Série de mesures, de changements ou de fonctions qui produisent un résultat
final. www.cchra-ccarh.ca/fr/phaseII/glossaire.asp
Information : encore appelée donnée. Elément de connaissance susceptible d'être codé pour
être conservé, traité ou communiqué.
Systèmes : Un système est un assemblage d'éléments reliés entre eux compris dans un
ensemble plus grand. En latin et en grec, le mot « système » veut dire combiner, établir,
rassembler. Un sous-système est un système faisant partie d'un autre système. Généralement,
un système est constitué de composants (ou d'éléments) organisés ensemble dans le but de
faciliter le flux d'informations, de matières ou d'énergie. ... fr.wikipedia.org/wiki/Système
Système d'information ou (information system) est un ensemble de composants de

traitement de l'information et de communication, ainsi que l'environnement dans lequel il
opèrent. (en Anglais: MIS ou Management of Information Systems).
Ensemble structuré: (1) de données, de leurs traitements et de leurs communications, décrit
à l'aide de structures, de procédures et de protocoles → dictionnaire de données (en
Anglais: DD ou Data Dictionary)
(2) de moyens techniques: Le système informatique (matériel et logiciel) et de
communication de documents ayant pour but de générer, mémoriser, traiter, transférer et
exploiter des informations dans le cadre d'objectifs définis.
Modèle : Le mot modèle synthétise les deux sens symétriques et opposés de la notion de
ressemblance, d', de représentation. En effet, il est utilisé * pour un objet dont on cherche
à donner une représentation, qu'on cherche à imiter.
(Exemple : le « modèle » du peintre, le « modèle » que constitue le maître pour le disciple). *
pour un concept ou objet qui est la représentation d'une autre (le « modèle réduit », le
« modèle » du scientifique). fr.wikipedia.org/wiki/Modèle
Un modèle est une représentation de la réalité.
Abstraction :
L'abstraction consiste à choisir, parmi l’ensemble des propriétés de plusieurs objets du monde
réel ou imaginables, un certain nombre d’entre elles pour caractériser un objet-type, ou objet
idéal, qui est ensuite plus commode à manier qu’une énumération d’objets réels, surtout si elle
est infinie. Ainsi les nombres pairs ou les nombres premiers ont un caractère d’abstraction.
Mais à vrai dire, les nombres eux-mêmes ont un caractère d’abstraction. ...
fr.wikipedia.org/wiki/Abstraction
concrétisation : phénomène inverse de l'abstraction: passe du modèle à monde réel:

concept : idée d'un objet conçu par l'esprit, permettant d'organiser les perceptions et les
connaissances.
www.unice.fr/BU/lettres/parme/glossaire.html
Un concept est une construction de l'esprit permettant de mieux saisir intellectuellement le

réel. Élément de base d'une théorie, le concept se veut une représentation abstraite d'un objet.
Personne, par exemple, n'a vu une classe sociale, car elle est un concept.
www.collegeahuntsic.qc.ca/Pagesdept/Sc_Sociales/multi/Glossaire.html
Notion d'information
En informatique, la notion de données est très utilisée. Par exemple un programme a
généralement des données sur lesquelles il travaille. On peut définir une donnée comme une
information numériques ou alphanumériques, représentées sous forme codée,
compréhensibles par la seule machine, pouvant être enregistrées, traitées, conservées et
communiquées.
En réalité, on fait une distinction entre les données et l'information. La donnée est un fait brut
non interprété tandis que l'information est porteuse de sens. On peut dire qu'une information
est un ensemble d’informations interprétées dans un contexte particulier.
Une information est un ensemble trois éléments :
Une entité : l'être, l'objet ou le concept concerné

Un attribut : un élément de la description de l'entité
Une mesure : une valeur associée à l'attribut
Une information apporte un renseignement au sujet d'une entité. Elle nous permet de
représenter une entité et de transformer cette représentation.

3
Rôle de l'information
Tout acte de la vie d'une organisation s'accompagne ou est conditionné par des informations
pour :
améliorer son fonctionnement

faciliter la prise de décision
Systèmes d'information
Une entreprise crée de la valeur en traitant de l'information, en particulier dans le cas des
sociétés de service. Ainsi, l'information possède une valeur d'autant plus grande qu'elle
contribue à l'atteinte des objectifs de l'organisation.
Un système d'Information (noté SI) représente l'ensemble des éléments participant à la

gestion, au traitement, au transport et à la diffusion de l'information au sein de l'organisation.
Une organisation (entreprise par exemple) peut être vue comme un système qui transforme les
entrées en sorties. Par exemple une usine de jus de mangue transforme les entrées qui sont des
mangues en sorties qui sont des bouteilles de jus de mangue.
Ce système peut être divisé en deux sous-systèmes :

- le système opérant constitué de la partie du système qui s'occupe effectivement de
transformer les mangues (les machines, les ouvriers, les techniciens, ...)
- le système de pilotage qui définit les objectifs de l'entreprise et s'efforce de tout mettre en
œuvre pour qu'ils soient atteints. Pour cela, il prend des décisions. Ces décisions sont prises à
partir de paramètres venant du système opérant.
C'est le système d'information qui relève ces paramètres, les traites et les transmet au système
de pilotage. Il peut être vu comme la partie qui relie les deux systèmes précédents.
Très concrètement le périmètre du terme Système d'Information peut être très différent d'une
organisation à une autre et peut recouvrir selon les cas tout ou partie des éléments suivants :
Base de données de l'entreprise,

Progiciel de gestion intégré (ERP),
Outil de gestion de la relation client (Customer Relationship Management),
Outil de gestion e la chaîne logistique (SCM - Supply Chain Management),
Applications métiers,
Infrastructure réseau,
Serveurs de données et systèmes de stockage,
Serveurs d'application,
Dispositifs de sécurité.
Pour une description plus imagée du système d'information, suivre le lien suivant :
http://fplanque.net/Blog/itTrends/2003/10/15/p403
Fonctions des systèmes d'information les systèmes d'information ont trois grandes fonctions :
La mémorisation (des informations brutes ou résultats de traitement)

Circulation : accès à la mémoire et échange entre les acteurs
Traitement : rapprochement, calcul, comparaison d'informations
A ces trois fonctions on peut en ajouter une quatrième :
collecte et saisie des informations
Classification des systèmes d'information On doit cette classification à Blumenthal. On

distingue les grandes catégories suivantes :
SICOP : Système d'Information de Contrôle Opérationnel Physique

o SICOL : Système d'Information de Contrôle Opérationnel Logistique
SICOMP : Système d'Information de Contrôle Opérationnel de
Matières Premières
SICOPR : Système d'Information de Contrôle Opérationnel de
Production
SICOPC : Système d'Information de Contrôle Opérationnel de Produits
Commercialisables
o SICOAP : Système d'Information de Contrôle Opérationnel des Actifs
Physiques
SICOIM : Système d'Information de Contrôle Opérationnel des
Installations et Matériels
SICOPI : Système d'Information de Contrôle Opérationnel de Projet
d'Investissement
SICOA: Système d'Information de Contrôle Opérationnel et Administratif

o SICOF : Système d'Information de Contrôle Opérationnel Financier
SICOC : Système d'Information de Contrôle Opérationnel de
Comptabilité
SICOT : Système d'Information de Contrôle Opérationnel de Trésorerie
o SICOM : Système d'Information de Contrôle Opérationnel Monetaire
(notamment pour la paie, la gestion des avantages et indemnités, et
l'administration du personnel)
II- Cycle de vie
Le « cycle de vie d'un logiciel » (en anglais software lifecycle), désigne toutes les étapes du
développement d'un logiciel, de sa conception à sa disparition. L'objectif d'un tel découpage
est de permettre de définir des jalons intermédiaires permettant la validation du
développement logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés, et la
vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en
œuvre.
L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé
qu'elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de
détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa
réalisation et les coûts associés.

5
Le cycle de vie du logiciel comprend généralement les activités suivantes :
Définition des objectifs, consistant à définir la finalité du projet et son inscription

dans une stratégie globale.
Analyse des besoins et faisabilité, c'est-à-dire l'expression, le recueil et la
formalisation des besoins du demandeur (le client) et de l'ensemble des contraintes.
Conception générale. Il s'agit de l'élaboration des spécifications de l'architecture
générale du logiciel.
Conception détaillée, consistant à définir précisément chaque sous-ensemble du
logiciel.
Codage (Implémentation ou programmation), soit la traduction dans un langage de
programmation des fonctionnalités définies lors de phases de conception.
Tests unitaires, permettant de vérifier individuellement que chaque sous-ensemble du
logiciel est implémenté conformément aux spécifications.
Intégration, dont l'objectif est de s'assurer de l'interfaçage des différents éléments
(modules) du logiciel. Elle fait l'objet de tests d'intégration consignés dans un
document.
Qualification (ou recette), c'est-à-dire la vérification de la conformité du logiciel aux
spécifications initiales.
Documentation, visant à produire les informations nécessaires pour l'utilisation du
logiciel et pour des développements ultérieurs.
Mise en production,
Maintenance, comprenant toutes les actions correctives (maintenance corrective) et
évolutives (maintenance évolutive) sur le logiciel.
La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du choix
d'un modèle de cycle de vie entre le client et l'équipe de développement.
Cycle de vie en cascade

Dans le cycle de vie en cascade, les étapes se succèdent dans le temps.
Chaque étape produit des documents qui sont utilisés pour en vérifier la conformité avant de
passer à la suivante. Le cycle de vie en cascade est souvent schématisé de la manière suivante
:
En utilisant le découpage définit ci-haut, on aurait ainsi le cycle de vie suivant:

© Barry W. Boehm, A Spiral Model of Software Development and Enhancement, IEE
Computer, May 1988.
Cycle de vie en V Le modèle de cycle de vie en V part du principe que les procédures de
vérification de la conformité du logiciel aux spécifications doivent être élaborées dès les
phases de conception.

7
Cycle de vie en spirale
Le cycle de vie en spirale est un modèle générique de cycle de vie évolutif qui a été proposé
par Barry W. Boehm en 1984. Ce modèle, axé sur la maîtrise et la réduction des risques, est
davantage un cadre de travail guidant la construction d'une démarche spécifique de projet,
plutôt qu'une démarche formalisée.
Chaque boucle de spirale permet :
D’identifier les objectifs propres de la boucle

Les moyens alternatifs pour atteindre les objectifs
Les contraintes de chaque alternative
Elle donne lieu au choix d'une alternative, validée par un prototype le cas échéant, et à
l'exécution de l'alternative choisie. A l'issue de la boucle, une revue des produits et des
résultats fournit une évaluation qui sert d'entrée pour la boucle suivante.
La dernière boucle est séquencée comme un cycle de vie en cascade.
Méthodes d'informatisation Une méthode d'informatisation est composée :

• des modèles : ensembles de concepts et de règles destinés à expliquer et construire la
représentation de phénomènes organisationnels
• des langages : pour élaborer les spécifications, et faciliter leur communication
• une démarche : processus pour effectuer les travaux préconisés, étape par étape
• des outils (AGL) ou techniques : pour aider à la mise en œuvre des trois composantes ci-
dessus
Une méthode est un mode d'emploi particulier d'un modèle. Elle dit comment observer les
éléments
Les avantages
L'emploi de méthodes doit permettre:
de réduire la complexité du processus d'informatisation

9
d'offrir des moyens de pilotage dans la construction du système
d'informatisation
la capitalisation des expériences et des solutions qui ont déjà fait leur preuve dans des
situations posant problème
la coordination des projets (réduire les coûts et d'augmenter la productivité dans
l'accomplissement des tâches)
la qualité de réalisation des étapes (garantie de pérennité) → tâches de d'évolution
plus
aisées
une diminution du nombre des anomalies : les corrections et la localisation se font plus
facilement ce qui implique que les tâches de maintenance sont moins onéreuses
une discipline commune au sein des équipes (définitions des rôles et des
responsabilités).
un langage commun entre les intervenants (qualité des documentations, intégration
rapide d'une nouvelle personne formée à la méthode)
III- Typologie des méthodes d'informatisation

On utilise souvent deux critères de classification de méthodes d'informatisation :
le type d'approche et les domaines d'application:
1. Type d'approche des problèmes d'informatisation:
les méthodes classiques

les méthodes cartésiennes (Exemple : SADT)
les méthodes systémiques (Exemple : MERISE)
les méthodes à objets (Exemple : UML)
2 . Les domaines d'application :

On a :
les méthodes d'élaboration de schémas directeurs (Exemple : RACINES)

les méthodes de rédaction de cahiers des charges (Exemples : AROC, MUSCADE)
les méthodes de conception des architectures techniques (Exemple : TACT)
les méthodes de conception des systèmes d'information
les méthodes de programmation
les méthodes de sécurité des systèmes (Exemple : MARION)
les méthodes de conduite des projets (Exemples : GANTT, PERT, MCP)
Classification des types Lorsqu'on évoque les méthodes d'informatisation, il existe plusieurs
manières de le faire. On distingue :
- les méthodes classiques ;
- les méthodes cartésiennes ;
- les méthodes systémiques ;
- les méthodes orientée-objet.
Nous vous présentons dans les sections qui suivent la classification des types
d'informatisation.
Méthodes classiques • Spécification du système complet
• Caractérisation de la totalité des données et traitements
Plusieurs vues :
• Entité/association → MERISE
• Fonctions → SADT ou SA/RT
INCONVENIENTS:
• Systèmes figés (évolution de l’environnement)
• Perte de la sémantique du système (buts, comportements…)
Méthodes cartésiennes
Discours de la Méthode (1637) de René Descartes
sous-titré "pour bien conduire sa raison, et chercher la vérité dans les sciences"
Quatre règles méthodologiques:

(1) Le principe du doute: tout en se défaisant des opinions toutes faites, ne
rien croire sans preuve dûment perçue par soi-même, d'où éviter la
précipitation
(2) La règle de division: pour mieux résoudre un problème, il faut le
décomposer
(3) La gradation des difficultés: aller du plus simple au plus complexe
(4) L'exhaustivité pour bien connaître un sujet
Anglo-saxonnes → approche fonctionnelle:
• décomposition hiérarchique des processus et des flux de données (ou flux
d'information)
• analyse et conception du système d'information à partir de la définition
de fonctions
• processus d'analyse et de conception
Un traitement de l'information répond aux règles de procédures de gestion pour produire des
sorties:
La démarche de travail est descendante, "top-down": part du général pour

aller vers le particulier.
Elle débute par l'identification d'une fonction globale de gestion. Toute fonction est
décomposée en sous-fonctions, et ainsi de suite, par raffinements successifs, jusqu'à ce que les
ensembles élémentaires soient intelligibles
Une représentation en arbre: les fonctions globalement perçues sont éclatées en processus
spécifiques. Les relations entre ces derniers sont également recherchées.
Programmation modulaire et décomposition fonctionnelle: S.A.D.T., J.S.D.
Méthodes systémiques
Théorie du système général. Il existe 9 niveaux de complexité
A chaque niveau, le système comporte tous les caractères du niveau inférieur
• l'objet passif et sans nécessité: niveau le plus simple de description
• l'objet actif: connu par son activité, son comportement.
• l'objet actif régulé: le système peut refuser certains comportements
possibles en fonction de son comportement précédent
• l'objet s'informe: régulation du système par l'intermédiaire de flux d'information
• l'objet décide son activité: le système a un comportement non inévitable,

11
C’est-à-dire qui est le résultat d'une décision: 2 types d'information: l'information-représentation
et l'information-décision
• l'objet actif a une mémoire: le système peut avoir besoin de la représentation d'événements
passés
• l'objet actif se coordonne: il existe au sein du système des processus de
coordination
• l'objet actif s'auto-organise: il est capable de s'adapter et d'inventer de
nouvelles organisations
• l'objet actif s'auto-finalise: le système génère ses projets, détermine ses
finalités
Méthodes orientée-objet
• Spécification comme un système ouvert
• Interface avec l’existant (communication avec l’homme)
• Caractérisation du comportement ou du but du système
• Décomposition en sous-systèmes ou objets
Plusieurs vues :
Comportement → UML
Buts → KADS
Les modèles de MERISE

A chaque niveau de la conception du système d'information, un modèle est élaboré. Il permet
de décrire le système au niveau de conception considéré.
Sachant que la communication, les données et les traitements sont examinés, on a les modèles
suivants :
Au niveau conceptuel :
Le Modèle Conceptuel de la Communication
le Modèle Conceptuel des Données (MCD)
le Modèle Conceptuel des Traitements (MCT)
Au niveau Organisationnel :
le Modèle Logique des Données (MLD)
le Modèle Logique des Traitements (MLT) ou Modèle Organisationnel des Traitements
(MOpT)
Au niveau physique :
le modèle Physique des Données (MPD ou MPhD)
le Modèle Opérationnel des Traitements (MOT ou MOpT)
Les modèles de la communication Le modèle conceptuel de la communication est
généralement le seul modèle utilisé dans ce cadre.
Les modèles de la communication Le modèle conceptuel de la communication est

généralement le seul modèle utilisé dans ce cadre.
Le Modèle Conceptuel de la Communication (MCC)

Le MCC (Modèle conceptuel de la communication) définit les flux d'informations à prendre
en compte.
La première étape de ce modèle est d'arriver à isoler le système en le délimitant.
Il s'agit donc de définir le système et les éléments externes avec lesquels il échange des flux
d'information. Ces éléments extérieurs sont appelés acteurs externes (ou partenaires).
La seconde étape consiste à découper l'organisation en entités appelées acteurs internes (ou
domaines).
Lorsque les domaines d'une organisation sont trop importants, ils peuvent être décomposés
eux-mêmes en sous-domaines.
La dernière étape est l'analyse des flux d'information, c'est-à-dire la définition des processus.
Les modèles de données

C'est la représentation schématique d'un ensemble de données relatives aux phénomènes qui
présentent de l'intérêt pour une application.
On retrouve trois niveaux de modèles de données
le modèle conceptuel de données,

le modèle logique de données, appelé aussi modèle fonctionnel de données,
le modèle physique de données
Le modèle logique des données (MLD)

le MLD reprend le contenu du MCD précédent, mais précise la volumétrie, la structure et
l'organisation des données telle qu'elles pourront être implémentées. Il s'agit du passage entre
le Modèle Conceptuel de Donnée et l'implémentation physique de la base. Par exemple, à ce
stade, il est possible de connaître la liste exhaustive des tables qui seront à créer dans une base
de données relationnelle.
Le MLD est lui aussi indépendant du matériel et du logiciel, il ne fait que prendre en compte
l'organisation des données. C'est d'ailleurs le point primordial de la modélisation : si
l'organisation des données est relationnelle (si elles sont "liées" entre elles), alors le MLD est
Relationnel et devient le MLDR, ou Modèle Logique de Donnée Relationnel.
Le MLD est une transcription ( également appelée dérivation ) du MCD dans un formalisme
adapté à une implémentation ultérieure, au niveau physique, sous forme de base de données
relationnelle ou réseau, ou autres (ex: simples fichiers ).
La transcription d'un MCD en modèle relationnel s'effectue selon quelques règles simples qui
consistent d'abord à transformer toute entité en table, avec l'identifiant comme clé primaire,
puis à observer les valeurs prises par les cardinalités maximum de chaque association pour
représenter celle-ci soit (ex: card. max 1-n ou 0-n) par l'ajout d'une clé étrangère dans une
table existante, soit (ex: card. max n-n) par la création d'une nouvelle table dont la clé
primaire est obtenue par concaténation de clés étrangères correspondant aux entités liées,
exemple :
MCD
MLD / Modèle relationnel
PAYS(code_pays)

13
USINE(id_usine,@code_pays,date_implantation)
EXPORT(@id_usine,@code_pays)
Les opérateurs de l'algèbre relationnelle ( projection, sélection, jointure, opérateurs

ensemblistes ) Langage d'interrogation de données peuvent ensuite directement s'appliquer sur
le modèle relationnel ainsi obtenu et normalisé Formes normales.
Cette démarche algorithmique ne fournit pas à ce niveau d'élément sur l'optimisation de la

durée ou des ressources nécessaires pour exécuter les traitements dans l'environnement de
production cible.
La transcription du MCD en MLD doit également être précédée d'une étape de

synchronisation et de validation des modèles de données ( MCD ) et de traitement (MCT et
MLT ), au moyen de vues . Cela afin d'y introduire les informations d'organisation définies au
MLT, d'éliminer les propriétés conceptuelles non utilisées dans les traitements ou redondantes
et enfin de vérifier que les données utilisées pour un traitement sont bien atteignables par
'navigation' entre les entités/relations du MCD.
MCD
La modèle Physique des données (MPD ou MPhD)

permet de préciser les systèmes de stockage employés. Les données qui sont stockées et
gérées dans un ordinateur le sont souvent par un système de gestion de base de données
(SGBD). Le MPD est l'implémentation du MLD dans le SGBD retenu.
Une fois le système d'information analysé et modélisé en Modèle Conceptuel de Donnée

(MCD), et après être passé par le Modèle Logique de Donnée Relationnel (MLDR), nous
arrivons au Modèle Physique de Donnée (MPD). Il s'agit maintenant de créer la base
correspondante à l'étude entamée. C'est à ce stade seulement que le système de gestion de
base de données choisie intervient.
Le SQL (Structured Query Language), ou Langage d'Interrogation Structuré, a été reconnu en

tant que norme officielle de langage de requête relationnelle.
Toutefois, les syntaxes d'extractions des données et de créations des tables varient quelques
peu d'un système de gestion de base de données à l'autre.
Le modèle physique consiste donc à ressortir le script SQL de création des tables en précisant
la longueur des champs et les différentes clés.
Ensuite il faudra évaluer le poids global de la base de données et faire une projection sur un
certains nombre d’années. Ce qui permet de tabler sur la capacité du disque requise pour
l’exploitation de la base de données pendant cette période.
Des exemples de logiciels supportant Merise sont :
AMC Designer
TRAMIS
SELECT
Les modèles des traitements

Si les modèles de données se penchent sur l'aspect statique, les modèles des traitements
s'occupent de l'aspect dynamique. Ils portent sur les "manipulations" que subissent les
données. On en distingue également trois :
- le modèle conceptuel des traitements
- le modèle organisationnel des traitements
- le modèle opérationnel des traitements
Le modèle conceptuel des traitements (MCT)

le Modèle Conceptuel de Traitement est un schéma représentant les traitements, en réponse
aux événements à traiter (par exemple : la prise en compte de la commande d'un client).
Le MCT repose sur les notions d'événement et d'opération, celle de processus en découle.
L'événement
Un événement est assimilable à un message porteur d'informations donc potentiellement de

données mémorisables (par exemple : l'événement 'commande client à prendre en compte'
contient au minimum l'identification du client, les références et les quantités de chacun des
produits commandés).
Un événement peut
déclencher une opération (ex: 'commande client à prendre en compte' déclenche

l'opération 'prise en compte commande'),
être le résultat d'une opération (ex: 'colis à expédier' suite à l'opération de 'préparation
colis' ), et à ce titre être, éventuellement, un évènement déclencheur d'une autre
opération.
L'opération
Une opération se déclenche uniquement par le stimulus d'un ou de plusieurs évènements

synchronisés
Elle est constituée d'un ensemble d'actions correspondant à des règles de gestion de niveau
conceptuel, stables pour la durée de vie de la future application (ex: pour la prise en compte
d'une commande : vérifier le code client (présence, validité), vérifier la disponibilité des
articles commandés, ...).
Le déroulement d'une opération est ininterruptible : les actions à réaliser en cas d'exceptions,
les évènements résultats correspondants doivent être formellement décrits (ex : en reprenant
l'exemple précédent, si le code client indiqué sur la commande est incorrect prévoir sa
recherche à partir du nom ou de l'adresse indiqués sur la commande, s'il s'agit d'un nouveau
client prévoir sa création et les informations à mémoriser, ...).

15
Le processus
Un processus est une vue du MCT correspondant à un enchaînement pertinent d'opérations du

point de vue de l'analyse (ex : l'ensemble des évènements et opérations qui se déroulent entre
la prise en compte d'une nouvelle commande et la livraison des articles au client).
Le modèle organisationnel des traitements (MOT) encore appelé MLT (Modèle Logique des
Traitements), il décrit avec précision l’organisation à mettre en place pour réaliser une, ou le
cas échéant plusieurs, opérations figurant dans le MCT : c’est à dire qui fait quoi, où, quand,
comment. A un MCT correspond donc généralement plusieurs MLT.
Les notions introduites à ce niveau sont le poste de travail, la phase, la tache et la procédure.
Le poste de travail
Le poste de travail décrit la localisation, les responsabilités, et les ressources nécessaires pour
chaque profil d’utilisateurs du système ( ex : client-web, responsable commercial, responsable
des stocks, etc. ).
La phase
La phase est un ensemble d’actions (CF MCT/Opération ) réalisées sur un même poste de
travail.
La phase peut être soit manuelle ( ex : confectionner des colis ), soit automatisée et intéractive
( ex : saisie d’un formulaire client ) ou automatisée batch ( ex : production et envoi de
tableaux de bord quotidiens dans les boîtes aux lettres électroniques).
La tâche
La tâche est une description détaillée d’une phase automatisée intéractive : spécification de
l’interface et du dialogue homme-machine, localisation et nature des contrôles à effectuer, etc.
La procédure
La procédure est un regroupement de phases, équivalent organisationnel des notions

d’opération et d’actions conceptuelles, mais se déroulant sur une période de temps homogène.
Des procédures d’origines non conceptuelles peuvent être rajoutées du fait des choix
d’organisation retenus ( ex : procédures d’échanges d’informations liées à l’externalisation de
certaines activités, prise en compte des questions de sécurité en cas de choix de solution Web,
... )
Le modèle opérationnel des traitements (MOT ou MOpT)
Le Modèle Opérationnel des Traitements permet de spécifier les fonctions telles qu'elles
seront ensuite réalisées par le programmeur.
Les formalismes Les modèles merise utilisent des formalismes, une manière formelle et
standard de décrire le modèle. Nous donnons dans les quelques sections qui suivent les
principaux formalismes utilisés par merise.

17
Formalisme
Pour le MCC
Diagramme de contexte
Le diagramme de contexte a pour but de représenter les flux d'informations entre

l'organisation et les acteurs externes selon une représentation standard dans laquelle chaque
objet porte un nom :
l'organisation est représentée par un rectangle

les acteurs externes sont représentés par des ellipses en pointillés
les flux d'information sont représentés par des flèches dont l'orientation désigne le sens
du flux d'information
Diagramme conceptuel de flux
Ce diagramme (appelé aussi modèle conceptuel de la communication) permet de compléter le

diagramme de contexte en décomposant l'organisation en une série d'acteurs internes. Dans ce
diagramme la représentation standard est la suivante :
Les acteurs internes sont représentés par des ellipses

les messages internes sont représentés par des flèches
Pour le MCD
Entités et classe d'entité
Une entité est la représentation d'un élément matériel ou immatériel ayant un rôle dans le
système que l'on désire décrire.
On appelle classe d'entité un ensemble composé d'entités de même type, c'est-à-dire dont la
définition est la même. Le classement des entités au sein d'une classe s'appelle classification
(ou abstraction). Une entité est une instanciation de la classe. Chaque entité est composée de
propriétés, données élémentaires permettant de la décrire.
Prenons par exemple une Ford Fiesta, une Renault Laguna et une Peugeot 306. Il s'agit de 3
entités faisant partie d'une classe d'entité que l'on pourrait appeler voiture. La Ford Fiesta est
donc une instanciation de la classe voiture. Chaque entité peut posséder les propriétés couleur,
année et modèle.
Les classes d'entités sont représentées par un rectangle. Ce rectangle est séparé en deux
champs :
le champ du haut contient le libellé. Ce libellé est généralement une abréviation pour
une raison de simplification de l'écriture. Il s'agit par contre de vérifier qu'à chaque
classe d'entité correspond un et un seul libellé, et réciproquement
le champ du bas contient la liste des propriétés de la classe d'entité
Relations et classes de relation
Une relation (appelée aussi parfois association) représente les liens sémantiques qui peuvent
exister entre plusieurs entités. Une classe de relation contient donc toutes les relations de
même type (qui relient donc des entités appartenant à des mêmes classes d'entité). Une classe
de relation peut lier plus de deux classes d'entité. Voici les dénominations des classes de
relation selon le nombre d'intervenants :
une classe de relation récursive (ou réflexive) relie la même classe d'entité
une classe de relation binaire relie deux classes d'entité
une classe de relation ternaire relie trois classes d'entité
une classe de relation n-aire relie n classes d'entité

19
Les classes de relations sont représentées par des hexagones (parfois des ellipses) dont
l'intitulé décrit le type de relation qui relie les classes d'entité (généralement un verbe). On
définit pour chaque classe de relation un identificateur de la forme Ri permettant de désigner
de façon unique la classe de relation à laquelle il est associé.
On peut éventuellement ajouter des propriétés aux classes de relation.
La cardinalité
Les cardinalités permettent de caractériser le lien qui existe entre une entité et la relation à
laquelle elle est reliée. La cardinalité d'une relation est composée d'un couple comportant une
borne maximale et une borne minimale, intervalle dans lequel la cardinalité d'une entité peut
prendre sa valeur :
la borne minimale (généralement 0 ou 1) décrit le nombre minimum de fois qu'une

entité peut participer à une relation
la borne maximale (généralement 1 ou n) décrit le nombre maximum de fois qu'une
entité peut participer à une relation
Une cardinalité 1.N signifie que chaque entité appartenant à une classe d'entité participe au
moins une fois à la relation.
Une cardinalité 0.N signifie que chaque entité appartenant à une classe d'entité ne participe
pas forcément à la relation.
Les identifiants
Un identifiant est un ensemble de propriétés (une ou plusieurs) permettant de désigner une et

une seule entité. La définition originale est la suivante :
L'identifiant est une propriété particulière d'un objet telle qu'il n'existe pas deux occurrences
de cet objet pour lesquelles cette propriété
pourrait prendre une même valeur.
Les attributs d'une classe d'entité permettant de désigner de façon unique chaque instance de
cette entité sont appelés identifiants absolus.
Le modèle conceptuel des données propose de faire précéder d'un # les identifiants (parfois de
les souligner).
Ainsi, chaque classe d'entité doit posséder au moins un attribut identifiant, et l'ensemble de
ses attributs identifiants doivent être renseignés à la création de l'entité.
Agrégation (ou identification relative)
Lorsqu'un identifiant est constitué uniquement d'attributs intrinsèques à une entité, c'est-à-dire
ne faisant référence à aucune autre entité, on le nomme identifiant absolu. Les entités
comportant des identifiants absolus peuvent être définies indépendamment des autres
occurrences d'entités, on dit que ces entités sont indépendantes.
Certaines entités ne peuvent toutefois être identifiées que par l'intermédiaire d'autres entités,
c'est la raison pour laquelle on parle d'identification relative.
On parlera par exemple de la 4ème porte au 2ème étage du bâtiment B au lieu de dire la
porte n°3451...
Ainsi, l'agrégation (appelée aussi identification relative) permet de spécifier qu'une entité est
nécessaire pour en identifier une autre.
la classe d'entité permettant d'identifier est appelée classe d'entité agrégeante

la classe d'entité identifiée est appelée classe d'entité agrégée
La représentation de ce type de relation est la suivante :

21
Pour le MCT
Le concept d'événement
Un événement représente un changement dans l'univers extérieur au système d'information,

ou dans le système d'information lui-même.
un événement externe est un changement de l'univers extérieur

un événement interne est un changement interne au système d'information
On représente un événement par une ellipse en trait plein pour les événements internes à
l'organisation, en trait pointillé pour les événements externes.
Définition d'un processus
Un processus est un sous-ensemble de l'activité de l'entreprise, cela signifie que l'activité de

l'entreprise est constituée d'un ensemble de processus. Un processus est lui-même composé de
traitements regroupés en ensembles appelés opérations.
Opération
Une opération est un ensemble d'actions exécutées par le système suite à un événement, ou à
une conjonction d'événements.
Cet ensemble d'actions est ininterruptible, c'est-à-dire que les événements ne sont pas pris en
compte (ils ne sont pas forcément ignorés pour autant) tant que l'opération n'a pas été
accomplie.
La synchronisation
La synchronisation d'une opération définit une condition booléenne sur les événements
contributifs devant déclencher une opération. Il s'agit donc de conditions au niveau des
événements régies par une condition logique réalisée grâce aux opérateurs :
OU
ET
NON
Construction du MCT
Le modèle conceptuel des traitements permet de représenter schématiquement la gestion des

événements :
Pour le MLD
Le modèle logique des données consiste à décrire la structure de données utilisée sans faire
référence à un langage de programmation. Il s'agit donc de préciser le type de données
utilisées lors des traitements.
Ainsi, le modèle logique est dépendant du type de base de données utilisé.
Le modèle relationnel
Traduction d'une classe d'entité
Chaque classe d'entité du modèle conceptuel devient une table dans le modèle logique. Les
identifiants de la classe d'entité sont appelé clés de la table, tandis que les attributs standards
deviennent des attributs de la table, c'est-à-dire des colonnes.
Traduction d'une classe de relation
Le passage du modèle conceptuel au modèle logique au niveau des classes de relation se fait
selon les cardinalités des classes d'entité participant à la relation :
Si une des classes d'entités possède une cardinalité faible :

la table aura comme attributs, les attributs de la classe ayant une cardinalité faible,
puis le (ou les) attribut(s) de relation et enfin les attributs de la seconde classe précédé
du nom de la classe
si les deux classes d'entités possèdent une cardinalité forte :
la table aura comme attributs, les attributs des deux classes de relation précédés des
noms des classes respectives, puis le (ou les) attribut(s) de relation

23
Traduction d'une classe d'agrégation
Dans le cas de la présence d'une classe d'agrégation, la classe d'entité agrégée a comme
attributs supplémentaires les attributs de la classe d'entité agrégeante
Pour le MOT
Le modèle organisationnel des traitements
Le modèle organisationnel des traitements s'attache à décrire les propriétés des traitements
non traitées par le modèle conceptuel des données, c'est-à-dire :
le temps
les ressources
le lieu
Le modèle organisationnel des traitements consiste donc à représenter le modèle conceptuel

des traitements dans un tableau dont les colonnes sont la durée, le lieu, les responsables et
ressources nécessaires à une action.
Le tableau des procédures fonctionnelles
La première étape du modèle organisationnel des traitements consiste à découper les

opérations en procédures fonctionnelles, une succession de traitements déclenchée par un
événement.
Il s'agit d'associer dans un tableau:
les procédures fonctionnelles

l'heure de début et de fin (Période)
la nature
le lieu du poste de travail
le responsable du poste de travail
les ressources du poste de travail
Période ou Temps Enchainement Nature Poste de Travail

Début Fin des Lieu Responsable Ressources
Procédures
fonctionnelles
Règles de passage du MCD au MLDR
Ces règles sont à appliquer scrupuleusement selon le cas.
1 : Une entité se transforme en une relation (table)
Toute entité du MCD devient une relation du MLDR, et donc une table de la Base de Donnée.
Chaque propriété de l'entité devient un attribut de cette relation, et dont une colonne de la
table correspondante. L'identifiant de l'entité devient la Clé Primaire de la relation (elle est
donc soulignée), et donc la Clé Primaire de la table correspondante.
<==> CLIENT (id_client, Nom_Client, Tel_client)
2 : Relation binaire aux cardinalités (X,1) - (X,n), X=0 ou X=1
La Clé Primaire de la table à la cardinalité (X,n) devient une Clé Etrangère dans la table à la
cardinalité (X,1) :
Exemple de Système d'Information (SI) :
Un employé a une et une seule société. Une société a 1 ou n employés.
Modèle Conceptuel de Donnée (MCD) :
Modèle Logique de Donnée Relationnelle (MLDR) :
EMPLOYE (id_Employe, Nom_Employe, #id_Societe)

SOCIETE (id_Societe, Nom_Societe)
Modèle Physique de Donnée (MPD), ou schéma de base :

25
3 : Relation binaire aux cardinalités (X,n) - (X,n), X=0 ou X=1
Il y a création d'une table supplémentaire ayant comme Clé Primaire une clé composée des
identifiants des 2 entités. On dit que la Clé Primaire de la nouvelle table est la
concaténation des Clés Primaires des deux autres tables.
Si la relation est porteuse de donnée, celles ci deviennent des attributs pour la nouvelle table.
S.I. :
Une commande est composée de 1 ou n produits distincts en certaine quantité. Un produit est
présent dans 0 ou n commandes en certaine quantité.
MCD :
MLDR :
COMMANDE (id_Commande, Date_commande)

PRODUIT (id_Produit, libelle)
COMPOSE (id_Commande, id_Produit, qantité)
MPD :
4 : Relation n-aire (quelles que soient les cardinalités).
Il y a création d'une table supplémentaire ayant comme Clé Primaire la concaténation des
identifiants des entités participant à la relation.
Si la relation est porteuse de donnée, celles-ci deviennent des attributs pour la nouvelle table.
S.I. :
Un étudiant parle une ou plusieurs langues avec un niveau. Chaque langue est donc parlée par
0 ou n étudiants avec un niveau. Pour chaque niveau, il y a 0 ou plusieurs étudiants qui parlent
une langue.
MCD :
MLDR :
ETUDIANT (id_Etudiant, Nom_Etudiant)

NIVEAU (id_Niveau, Nom_Niveau)
LANGUE (id_Langue, Nom_Langue)
PARLE (id_Etudiant, id_Niveau, id_Langue)
MPD :
5 : Association Réflexive.
Premier cas : cardinalité (X,1) - (X,n), avec X=0 ou X=1.
La Clé Primaire de l'entité se dédouble et devient une Clé Etrangère dans la relation
ou nouvelle table. Exactement comme si l'entité se dédoublait et était reliée par une
relation binaire (X,1) - (X,n) (Cf règle 2).
S.I. :
Prenons l'exemple d'une société organisée de manière pyramidale : chaque employé a 0 ou 1

supérieur hiérarchique direct. Simultanément, chaque employé est le supérieur hiérarchique
direct de 0 ou plusieurs employés.
MCD :

27
MLDR :
EMPLOYE (id_Employe, Nom_Employe, #id_Sup_Hierarchique)
#id_Sup_Hierarchique est l'identifiant (id_Employe) du supérieur hiérarchique direct de

l'employé considéré.
MPD :
Deuxième cas : cardinalité (X,n) - (X,n), avec X=0 ou X=1.
De même, tout se passe exactement comme si l'entité se dédoublait et était reliée par
une relation binaire (X,n) - (X,n) (Cf règle 3). Il y a donc création d'une nouvelle table.
S.I. :
Prenons cette fois l'exemple d'une organisation de type familiale : chaque personne a 0 ou n
descendants directs (enfants), et a aussi 0 ou n descendants directs (enfants).
MCD :
MLDR :
PERSONNE (id_Personne, Nom_Personne)

PARENTE (#id_Parent, #id_Enfant)
#id_Parent est l'identifiant (id_Personne) d'un ascendant direct de la personne. #id_Enfant est
l'identifiant (id_Personne) d'un descendant direct de la personne.
La table PARENTE sera en fait l'ensemble des couples (parents-enfants) présent dans cette
famille.
MPD :
6 : Relation binaire aux cardinalités (0,1) - (1,1).
La Clé Primaire de la table à la cardinalité (0,1) devient une Clé Etrangère dans la table à la
cardinalité (1,1) :
S.I. :
Dans ce centre de vacances, Chaque animateur encadre en solo 0 ou 1 groupe, chaque groupe
étant encadré par un et un seul animateur.
MCD :
MLDR :
ANIMATEUR (id_Animateur, Nom_Animateur)

GROUPE (id_Groupe, Nom_Groupe, #id_animateur)
MPD :
Ces 6 règles représentent TOUS les cas que vous pourrez rencontrer.

29
La démarche Merise Description
Merise est une méthode de conception des sytème d'information qui utilisent, comme nous
l'avons vu, un certain nombre de modèles. Mais mérise est également une démarche. La
démarche est la méthode qui organise en étape la conception d'un système d'information à
l'aide des modèles sur une période donnée. La démarche Merise passe par les étapes
successives suivantes :
1. le schéma directeur
2. l'étude préalable
3. l'étude détaillée
4. l'étude technique
5. La production
6. la qualification
7. la maintenance
Le schéma directeur
« Un schéma directeur est une opération de courte durée visant l’anticipation à moyen terme,
la prospective et la planification stratégique afin d’assurer la cohérence entre les finalités, les
stratégies, les objectifs et sa politique de mobilisation des ressources organisationnelles,
technologiques, humaines et financières. »
Appliqué à l'informatique, le schéma directeur d'une organisation a pour but de proposer un

plan d'automatisation progressive des tâches de gestion d'une entreprise, d'une
administration... c'est-à-dire des tâches bien définies dans un ensemble organisé.
Le concept de schéma directeur de l'informatique (SDI) est né dans la banque et la grande

administration face au besoin de planifier des investissements de plus en plus lourds, de
maîtriser les aspects humains liés à la modification des méthodes de travail.
Le schéma directeur de l'informatique permet d'envisager des scenarii qui portent sur les
domaines.
Un domaine est un découpage du système d'information de l'entreprise, défini dans un

schéma directeur en fonction de sa stratégie.
Par exemple, une banque peut avoir défini les domaines Gestion de clientèle, Gestion des
participations financières, Gestion de trésorerie, Gestion des Ressources Humaines, etc.
Le découpage en domaines correspond grosso modo aux grandes fonctions de l'entreprise,
hiérarchisées par ses objectifs stratégiques (centres d'intérêt).
Le schéma directeur peut se faire en plusieurs étapes.
Etape 1 : définir les objectifs et les structures de travail.
Etape2 : déterminer les composants de l'entreprise.
Etape 3 : formaliser et chiffrer les solutions.

Etape 4 : planifier les actions.
Etape 5 : définir la structure de pilotage.
Le schéma directeur donne lieu à un document appelé plan de développement
L'étude préalable
Une étude préalable s'applique à un domaine ou à une grande fonction de l'entreprise.
Également appelée: étude de faisabilité
L'objectif de cette étape est d'obtenir le descriptif complet de la nouvelle solution pour le
domaine envisagé, mais en plusieurs phases, de sorte à envisager les différentes hypothèses
possibles et à s'orienter progressivement vers la solution optimum.
Le point final de l'étude préalable est de:
* décider d'une solution type en parfaite connaissance de cause quant à sa faisabilité: coût,
rentabilité, délai, budget, moyens à mettre en œuvre, impact organisationnel, ...
* établir le cahier des charges pour la réalisation; sélectionner un sous-traitant ou un
progiciel.
Pour mener à bien une étude préalable, on part de la situation existante. L'étude préalable est
faite par des utilisateurs et des organisateurs en liaison avec la direction générale et les
informaticiens. On en distingue plusieurs étapes dont chacune est divisée en phases:
Étape 1 : Étude de l'existant

Phase 1 : Rédiger une Fiche de présentation générale du problème. Cette fiche situe le
domaine dans le système d'information, à partir du schéma directeur et de la demande de la
direction générale. Par interview de la direction générale, se faire préciser les grands objectifs
relatifs au domaine et les consigner dans une Fiche d'objectifs D.G.
Phase 2 : Procéder à des interviews des postes de travail concernés et rédiger des comptes
rendus d'interviews, en y joignant tous les documents concernés actuellement en vigueur.
S'il y a des traitement qui se font à l'aide ou par ordinateur, joindre les fiches de description
de fichiers actuels.
Phase 3 : A partir des comptes rendus, établir les documents suivants:

- le graphe de circulation actuel;
- la carte de circulation des informations du domaine ;
- le graphe des flux ;
- le MOT actuel ;
Phase 4 : à partir des documents recueillis lors des interviews, établir un dictionnaire des
données actuel pour toutes les données manipulées et épurer ce dictionnaire.
Phase 5 : a partir du dictionnaire des données, construire la structure d'accès théoriques

(SAT) en ne prenant que les données élémentaires, sans les données calculées, en listant
toutes les dépendances fonctionnelles et en éliminant les transitivités. En déduire une
représentation graphique du MCD actuel.
31
Phase 6 : Déduire les règles de gestion à partir du MCD et du MCT actuels ;
Phase 7 : à partir des comptes rendus d'interviews établir une fiche de synthèse faisant état
des points les plus épineux, des souhaits des utilisateurs, en s'efforçant de critiquer
l'organisation actuelle. Dégager de cette fiche un certain nombre d'objectifs de la "fiche
d'objectifs D.G.", établir une liste hiérarchisée de tous les objectifs sur une fiche d'objectifs
synthèse. Faire approuver celle-ci par la direction générale et par les divers responsables.
Phase 8 : étudier les interfaces avec les autres domaines (d'après la carte générale de
circulation de l'information du schéma directeur, par exemple) et les consigner dans une fiche
des interfaces.
Étape 2 : Scénarios futurs

Phase 1 : à partir de la fiche d'objectif synthèse et des règles de gestion actuelles, inventorier
les règles de gestion futures et les inscrire sur une fiche de règles de gestion futures.
A partir du MCD actuel, de la fiche des interfaces et des règles de gestion futures, établir le
MCD futur.
Phase 2 : à partir du MCT actuel et des règles de gestion futures, concevoir le MCT futur.
Phase 3 : pour chaque scénario faire l'étude organisationnelle qui donnera :

- une fiche des règles d'organisation ;
- une esquisse de MOT futur.
Faire ensuite l'étude opérationnelle (toujours par scénario) en définissant le matériel et les
logiciels nécessaires. S'il existe plusieurs sites, cette étude tient compte des aspects
spécifiques de chaque site. L'étude opérationnelle donnera lieu à :
- une fiche de configuration de matériel pour l'architecture générale et pour chaque site s'il y
en a plusieurs ;
- une liste des logiciels.
Étape 3 : Une évaluation des Scénarios

Pour chaque scénario rédiger un rapport d'évaluation du scénario comportant :
- une évaluation des coûts de :

* matériel (achat, location)
* stockage
* logiciels (programmation, achat de progiciels...)
* traitement (unités centrales, consommation d'électricité, ...)
* communication (location de lignes de transmission)
* exploitation (fournitures de consommable, entretien des locaux ...)
* maintenance (contrats de maintenance chez le constructeur)
* personnel (utilisateurs, service informatique, sous-traitant, ...)
* formation (utilisateurs, informaticiens)
- une évaluation des avantages
* quantifiables et chiffrables au plan financier (recette attendues, économies de personnel
...)
* quantifiables et non chiffrables au plan financier (diminution des temps de gestion,
simplification des procédures, ...)
* non quantifiables (rapidité des traitements, aide à la décision, image de marque,
fidélisation d'une clientèle, ...)
- une évaluation de l'impact sur l'organisation
* impact sur les postes de travail
* acceptabilité du personnel
- une évaluation de la faisabilité
* en matériels (rédiger un compte rendu de l'étude technique)
* en logiciels
*en personnel (personnel disponible, embauche, formation, sous-traitance)
- une évaluation approximative des délais
* de livraison des matériels
* de programmation des logiciels (délais rarement respectés)
* de recrutement et de formation
- une évaluation de la mise en œuvre
* cadencement du lancement des applications
* périodes transitoires
* etc.
L'étude préalable donne lieu à un document appelé dossier de choix.
L'étude détaillée
L'étude préalable ne porte que sur les processus majeurs. La description des données et des
traitements y est succincte. L'étude détaillée va décrire tous les processus composants le
fonctionnement du futur système; définir précisément les informations utilisées et
mémorisées; spécifier complètement les tâches à effectuer. Elle se déroule en plusieurs étapes:
Étape 1 : Étude générale du MOT futur

cette étude se fait en suivant les phases suivantes :
- réalisation du tableau des procédures fonctionnelles ;
- construction du diagramme d'enchaînement des procédures fonctionnelles ;
- construction du graphe de circulation.
Étape 2 : Étude poussée de chaque procédure fonctionnelle

dans cette étape, chaque procédure fonctionnelle est étudiée de manière poussée. Cela donne
lieu à :
- une fiche de description de la procédure fonctionnelle
- une description des documents éventuelle
- des tables de décision éventuelles
- une description éventuelle des états de sortie
- pour les transactions :
* des grilles d'écrans (à faire approuver par les utilisateurs concernés)
* des grilles de contrôles
* une fiche de répartition des tâches entre l'homme et la machine (à faire approuver par les
utilisateurs)
- le modèle externe non validé.
Étape 3 : Validation du MCD

Les données et les traitements ayant été étudiés de manière indépendante, la validation du
MCD permet de confronter les données aux traitements et de rendre l'ensemble cohérent.

33
Étape 4 : Passage au MLD
L'étude détaillée donne lieu, pour chaque application à un cahier des charges utilisateurs.
L'étude technique
L'étude technique est la traduction informatique des spécifications issues de l'étude

détaillée. Elle s'occupe des spécifications techniques pour la réalisation.
Les objectifs de l'étude technique sont de présenter les spécifications informatiques

nécessaires à la production du logiciel. A cet effet, elle définit complètement :
la structure de mémorisation informatique des données (fichiers ou base de données) ;

l'architecture interne du système
les procédures de sécurités
le plan de réalisation.
L'étude technique peut être menée en suivant les étapes suivantes :
Étape 1 : structuration des données
établir la description physique des données à partir du MLD (Modèle Logique des
données)
définir les clés d'accès
établir une quantification de l'activité des éléments de stockage des données
procéder à l'optimisation physique
déduire l'allocation des espaces physiques, l'organisation et le mode d'accès
décrire les dispositifs de protection d'accès et de
confidentialité Étape 2 : spécification de l'architecture interne du
système découpage des Unité Fonctionnelle (UF) en Unités de
Traitement (UT)
découper chaque UF en UT
découpage des UT en modules
découper chaque UT en modules

établir la liste des Entrées/Sorties pour chaque module
établir la liste des données utilisées ou échangées
établir une description pour chaque module sous forme d'algorithmes ou
d'organigramme
déterminer les jeux d'essai à élaborer répondant aux exigences de la qualité
terminer de concevoir les Entrées/Sorties
définir les spécifications des écrans ainsi que les dialogues associés
définir les formats détaillés et les spécifications des sorties
établir une liste des entrées/sorties pour chaque UT
Étape 3 : les procédures techniques de sécurité

contrôle des données :
description des caractéristiques liées aux contrôles des
données sécurité et confidentialité :
description des mécanismes relatifs à la sécurité et à la confidentialité des données

description les procédures de reconstitution des supports de données, de redémarrage
et de sauvegarde
Étape 4 : planification de la réalisation
réaliser le planning pour les phases suivantes
L'étude technique donne lieu à un cahier des charges technique.
La production
La production consiste en l'écriture effective des programmes dans le langage approprié, à la

génération des fichiers ou des bases de données et aux tests. La production du logiciel doit
permettre de faciliter la maintenance future.
Ses objectifs sont :
la production du logiciel conforme aux spécifications de l'étude technique

de tester techniquement le logiciel de manière qu'il soit prêt à être livré aux utilisateurs
La production du logiciel peut se faire en suivant les étapes suivantes :
Étape 1 : programmation de l'application
durant laquelle il faudra :
intégrer les normes et standards de programmation
organiser l'environnement de programmation
définir une organisation pour permettre la gestion de l'environnement de

programmation (matériel, temps machine, ..)
coder les modules
transformer les spécifications techniques des modules en code source

vérifier et mettre au point le code source
corriger les défauts et erreurs
constatées préparer les jeux d'essai
définir les jeux d'essai

préparer les données en vue des tests unitaires et d'enchainement de modules

35
Étape 2 : tests, mise au point
tests unitaires
chaque module écrit, correspondant à une Unité de Traitement, doit faire l'objet d'un
premier test à partir du jeu d'essai
tests d'intégration
ces tests doivent permettre de vérifier le bon fonctionnement de l'ensemble du

logiciel.
Ils sont généralement effectués par le responsable technique du projet.
La production donne lieu à un dossier de réalisation.
La mise en service
L'objectif principal de la mise en service est de rendre opérationnel le système d'information.

Elle consiste à installer l'ensemble du logiciel développé et à mettre l'ensemble du SI au
service des utilisateurs. Elle permet de conclure l'ensemble du cycle conception-
développement.
Son objectif principal est de mettre en place tous les moyens nécessaires à la réception et au
lancement du nouveau SI
La mise en service se déroule en deux étapes:
Étape 1 : l'installation
elle a pour but de livrer le logiciel aux utilisateurs et de préparer le démarrage de

l'exploitation. Elle comprend :
la commande, l'installation, le contrôle et la réception du matériel ;

la mise en place des procédures nouvelles liées aux changements d'organisation ;
l'organisation et le déroulement de la formation des utilisateurs et des exploitants ;
l'exécution des jeux d'essai utilisateurs ;
l'appréciation de la conformité des résultats ;
la réception provisoire.
Étape 2 : la mise en exploitation
elle consiste en :
l'exploitation en grandeur réelle du nouveau système

le lancement progressif du nouveau système en parallèle au système existant si
possible
le fonctionnement en vrai grandeur pendant une période déterminée
le bilan de l'exploitation
la réception définitive du produit
Elle donne lieu au dossier d'exploitation et au manuel utilisateur.
La maintenance
La maintenance est définie selon BOEHM comme l'ensemble des opérations de modification
d'un logiciel opérationnel laissant intactes ses fonctionnalités de base. Elle consiste en la
rectification des anomalies, les améliorations et les évolutions.
Ses objectifs sont :
maintenir le système en fonctionnement ;

rectifier les anomalies de fonctionnement et prendre en compte les demandes
d'évolution ;
établir un scénario de développement des versions ;
planifier les corrections apportées au système pour minimiser les coûts d'intervention ;
s'assurer du bon fonctionnement des nouvelles révisions avant tout nouvelle mise en
exploitation ;
procéder à cette mise en exploitation après l'accord des parties prenantes ;
assurer un bonne gestion des différents configurations du logiciels par la tenue à jour
de la documentation du système.
Il existe plusieurs niveaux, catégories et formes de maintenance.
Parmi les niveaux et catégories, on a : la maintenance corrective ; la maintenance adaptative

; la maintenance perfective et la maintenance préventive.
La maintenance corrective ne porte que sur le logiciel développé. Elle ne remet pas en cause
les modèles de données ou de traitements. Elle consiste en la correction des erreurs du
logiciel. Elle représente souvent 17 à 20 % du temps de maintenance.
La maintenance adaptative est liée à l'environnement du logiciel (contexte d'utilisation du

logiciel, génération des ordinateurs, exploitation logiciel sur des matériels distincts ...). Elle
peut faire évoluer le MCD et le MCT. Elle représente 18 à 25 % du temps de maintenance.
La maintenance perfective consiste à améliorer le fonctionnement du logiciel. Elle peut

entraîner une remise en question des modèles physiques et du MOT. C'est la catégorie de
maintenance la plus fréquente (environ 60 %).
La maintenance préventive a pour objectif de diminuer le nombre d'opérations de

maintenance pour en diminuer le coût. Elle n'est vraiment possible que si certaines conditions
sont réunies :
le système est développé dans un esprit de maintenance ultérieur ;

le système est continuellement amélioré pour faire face et intégrer les nouvelles
technologies ;
le système est maintenu en pensant à la maintenance ultérieure.

37
Chapitre. II: CONCEPTION ET IMPLEMENTATION DES BASES DE DONNEES:
II 1- Le Modèle Entités-Associations
II 1.1 Éléments constitutifs du modèle entités-associations

La représentation du modèle entités-associations s’appuie sur trois concepts de base :
– l’objet ou entité,
– l’association,
– la propriété.
L’objet est une entité ayant une existence propre. L’association est un lien ou relation entre
objets
sans existence propre. La propriété est la plus petite donnée d’information décrivant un objet
ou une association.
 Entité
Fig. 2.1 – Représentation graphique d’un exemple de type-entité., l, la Nissan qui se trouve dans
mon garage, etc.
Type-entité- Un type-entité désigne un ensemble d’entités qui possèdent une sémantique et des
propriétés communes.
Les personnes, les livres et les voitures sont des exemples de type-entité. En effet, dans le cas
d’une personne par exemple, les informations associées (i.e. les propriétés), comme le nom et le
prénom, ne changent pas de nature. Une entité est souvent nommée occurrence ou instance de
son type-entité.
La figure 2.1 montre la représentation graphique d’un exemple de type-entité (Personne) sans
ses propriétés associées. Les type-entité Personne, caractérisé par un nom et un prénom, et
Voiture, caractérisé par un nom et une puissance fiscale, ne peuvent pas être regroupés car ils ne
partagent leurs propriétés (le prénom est une chaîne de caractères et la puissance fiscale un
nombre). Les type-entité Personne, caractérisé par un nom et un prénom, et Livre, caractérisé un
titre et un auteur, possèdent tous les deux attributs du type chaîne de caractères. Pourtant, ces
deux type-entités ne peuvent pas être regroupés car ils ne partagent pas une même sémantique :
le nom d’une personne n’a rien à voir avec le titre d’un livre, le prénom d’une personne n’a rien
à voir avec un auteur. Par abus de langage, on utilise souvent le mot entité en lieu et place du
mot type-entité, il faut cependant prendre garde à ne pas confondre les deux concepts.
2.2.2 Attribut ou propriété, valeur
Fig. 2.2 – Représentation graphique d’un exemple de type-entité comportant trois attributs
Attribut, propriété- Un attribut (ou une propriété) est une caractéristique associée à un type-
entité ou à un type-association.
Exemples d’attribut : le nom d’une personne, le titre d’une livre, la puissance d’une voiture.
-valeur- Au niveau du type-entité ou du type-association, chaque attribut possède un domaine
qui définit l’ensemble des valeurs possibles qui peuvent être choisies pour lui (entier, chaîne de
caractères, booléen, . . .). Au niveau de l’entité, chaque attribut possède une valeur compatible
avec son domaine.
La figure 2.2 montre la représentation graphique d’un exemple de type-entité (Personne) avec
trois attributs.
Règle 2.5 Un attribut ne peut en aucun cas être partagé par plusieurs type-entités ou type-
associations.
Règle 2.6 Un attribut est une donnée élémentaire, ce qui exclut des données calculées ou
dérivées
Règle 2.7 Un type-entité et ses attributs doivent être cohérents entre eux (i.e. ne traiter que
d’un seul
sujet).
Par exemple, si le modèle doit comporter des informations relatives à des articles et à leur
fournisseur, ces informations ne doivent pas coexister au sein d’un même type-entité. Il est
préférable de mettre les informations relatives aux articles dans un type-entité Article et les
informations relatives aux fournisseurs dans un type-entité Fournisseur. Ces deux type-entités
seront probablement ensuite reliés par un type association.
2.2.3 Identifiant ou clé
Fig. 2.3 – Représentation graphique d’un exemple de type-entité comportant quatre

attributs
dont un est un identifiant : deux personnes peuvent avoir le même nom, le même prénom et le
même âge, mais pas le même numéro de sécurité sociale.
Identifiant : Un identifiant (ou clé) d’un type-entité ou d’un type-association est constitué par
un ou plusieurs de ses attributs qui doivent avoir une valeur unique pour chaque entité ou
association de ce type.
Il est donc impossible que les attributs constituant l’identifiant d’un type-entité (respectivement
type-association) prennent la même valeur pour deux entités (respectivement deux associations)
distinctes. Exemples d’identifiant : le numéro de sécurité sociale pour une personne, le
numéro d’immatriculation pour une voiture, le code ISBN d’un livre pour un livre (mais pas
pour un exemplaire).
Règle 2.9 Chaque type-entité possède au moins un identifiant, éventuellement formé de

plusieurs attributs.
Ainsi, chaque type-entité possède au moins un attribut qui, s’il est seul, est donc forcément
l’identifiant.
Dans la représentation graphique, les attributs qui constituent l’identifiant sont soulignés et
placés en tête (cf. figure 2.3).
2.2.4 Association ou relation

Association- Une association (ou une relation) est un lien entre plusieurs entités.
Exemples d’association : l’emprunt par l’étudiant Tanko du 3e exemplaire du livre « Maîtrisez
SQL ».
Les associations ne sont généralement pas représentées graphiquement
Fig. 2.4 – Représentation graphique d’un exemple de type-association liant deux type-entités.

39
Type-association- Un type-association (ou un type-relation) désigne un ensemble de relations
qui possèdent les mêmes caractéristiques. Le type-association décrit un lien entre plusieurs
type-entités. Les associations de ce type-association lient des entités de ces type-entités.
Comme les type-entités, les type-associations sont définis à l’aide d’attributs qui prennent leur
valeur dans les associations.
Règle 2.12 Un attribut peut être placé dans un type-association uniquement lorsqu’il dépend
de toutes
les entités liées par le type-association.
Un type-association peut ne pas posséder d’attribut explicite et cela est relativement fréquent,
mais on verra qu’il possède au moins des attributs implicites.
Exemples de type-association : l’emprunt d’un livre à la bibliothèque.
Une association est souvent nommée occurrence ou instance de son type-association.
La figure 2.4 montre la représentation graphique d’un exemple de type-association.
participant- Les type-entités intervenant dans un type-association sont appelés les participants
de ce type-association.
Collection- L’ensemble des participants d’un type-association est appelé la collection de ce
type-association.
Cette collection comporte au moins un type-entité (cf. section 2.3.2), mais elle peut en contenir
plus, on parle alors de type-association n-aire (quand n = 2 on parle de type-association binaire,
quand n = 3 de type-association ternaire, . . .).
2.2.5 Cardinalité
Fig. 2.5 – Représentation graphique des cardinalités d’un type-association. Dans cet exemple
pédagogique, on suppose qu’un livre ne peut posséder qu’un auteur.
Cardinalité- La cardinalité d’une patte reliant un type-association et un type entité précise le
nombre de fois minimal et maximal d’interventions d’une entité du type-entité dans une
association du type association. La cardinalité minimale doit être inférieure ou égale à la
cardinalité maximale.
Exemple de cardinalité : une personne peut être l’auteur de 0 à n livre, mais un livre ne peut être
écrit que par une personne (cf. figure 2.5).
Règle 2.18 L’expression de la cardinalité est obligatoire pour chaque patte d’un type-
association.
Règle 2.19 Une cardinalité minimal est toujours 0 ou 1 et une cardinalité maximale est
toujours 1 ou n.
Ainsi, si une cardinalité maximale est connue et vaut 2, 3 ou plus, alors nous considérons
qu’elle est indéterminée et vaut n. En effet, si nous connaissons n au moment de la conception, il
se peut que cette valeur évolue au cours du temps. Il vaut donc mieux considérer n comme
inconnue dès le départ. De la même manière, on ne modélise pas des cardinalités minimales qui
valent plus de 1 car ces valeurs sont également susceptibles d’évoluer. Enfin, une cardinalité
maximale de 0 n’a pas de sens car elle rendrait le type-association inutile.
Les seuls cardinalités admises sont donc :
0,1 : une occurrence du type-entité peut exister tout en étant impliquée dans aucune
association et peut être impliquée dans au maximum une association.
0, n : c’est la cardinalité la plus ouverte ; une occurrence du type-entité peut exister tout en
étant impliquée dans aucune association et peut être impliquée, sans limitation, dans plusieurs
associations.
1,1 : une occurrence du type-entité ne peut exister que si elle est impliquée dans exactement
(au moins et au plus) une association.
1, n : une occurrence du type-entité ne peut exister que si elle est impliquée dans au moins une
association.
Une cardinalité minimale de 1 doit se justifier par le fait que les entités du type-entité en
questions ont besoin de l’association pour exister. Dans tous les autres cas, la cardinalité
minimale vaut 0. Ceci dit, la discussion autour d’une cardinalité minimale de 0 ou de 1 n’est
intéressante que lorsque la cardinalité maximale est 1. En effet, nous verrons que, lors de la
traduction vers un schéma relationnel (cf. section 3.1.3), lorsque la cardinalité maximale est n,
nous ne ferons pas la différence entre une cardinalité minimale de 0 ou de 1.
2.3 Compléments sur les associations
2.3.1 Associations plurielles
Fig. 2.6 – Exemple d’associations plurielles entre un type-entité Personne et un type-entité

Livre.
Sur ce schéma, un type-association permet de modéliser que des personnes écrivent des livres et
un autre que des personnes critiquent (au sens de critique littéraire) des livres.
Deux mêmes entités peuvent être plusieurs fois en association (c’est le cas sur la figure 2.6).
2.3.2 Association réflexive
Fig. 2.7 – Exemple d’associations réflexives sur le type-entité Personne. Le premier type
association permet de modéliser la relation parent/enfant et le deuxième type-association la
relation de fraternité.
Type-association réflexif- Un type-association est qualifié de réflexif quand il matérialise une
relation entre un type-entité et lui-même (cf. figure 2.7)
2.3.3 Association n-aire (n > 2)
Ce type-association met en relation n type-entités. Même s’il n’y a, en principe, pas de limite
sur l’arité d’un type-association, dans la pratique on ne va rarement au-delà de trois.
Exemple d’association n-aire inappropriée

41
Fig. 2.8 – Exemple de type-association ternaire inapproprié.
Le type-association ternaire Contient associant les type-entités Facture, Produit et Client

représenté sur la figure 2.8 est inapproprié puisqu’une facture donnée est toujours adressée au
même client. En effet, cette modélisation implique pour les associations (instances du type-
association) Contient une répétition du numéro de client pour chaque produit d’une même
facture.
La solution consiste à éclater le type-association ternaire Contient en deux type-associations
binaires comme représenté sur la figure 2.9.
Décomposition d’une association n-aire
La figure 2.10 nous montre un exemple de type-association ternaire entre les type-entités
Créneau horaire, Salle et Film. Il est toujours possible de s’affranchir d’un type-association n-
aire.
Fig. 2.9 – Type-association ternaire de la figure 2.8 corrigé en deux type-associations binaires
Fig. 2.10 – Exemple de type association ternaire entre des type-entités Créneau horaire, Salle et
Film.
(n > 2) en se ramenant à des type-associations binaires de la manière suivante :
– On remplace le type-association n-aire par un type-entité et on lui attribue un identifiant.
– On crée des type-associations binaire entre le nouveau type-entité et tous les type-entités de la
collection de l’ancien type-association n-aire.
– La cardinalité de chacun des type-associations binaires créés est 1; 1 du côté du type-entité
créé (celui qui remplace le type-association n-aire), et 0; n ou 1; n du côté des type-entités de la
collection de l’ancien type-association n-aire.
La figure 2.11 illustre le résultat de cette transformation sur le schéma de la figure 2.10.
L’avantage du schéma de la figure 2.11 est de rendre plus intelligible la lecture des cardinalités.
Il ne faut surtout pas le voir comme un aboutissement mais comme une étape intermédiaire
avant d’aboutir au schéma de la figure 2.10 (cf. règle 2.27). Ainsi, le mécanisme, que nous
venons de détailler ci-dessus, de passage d’un type-association n-aire (n > 2) à un type-entité et
n type-associations binaires est tout à fait réversible à condition que :
– toutes les pattes des type-associations binaires autour du type-entité central ont une cardinalité
maximale de 1 au centre et de n à l’extérieur ;
Fig. 2.11 – Transformation du type-association ternaire de la figure 2.10 en un type-entité et

trois type-associations binaires.
– les attributs du type-entité central satisfont la règle de bonne formation des attributs de type-
association (cf. section 2.5.2).
Détection d’une erreur de modélisation par décomposition d’une association n-aire
Passer par cette étape intermédiaire ne comportant pas de type-association n-aire (n > 2) peut,
dans certains cas, éviter d’introduire un type-association n-aire inapproprié. Imaginons par
exemple un type-association ternaire Vol liant trois type-entités Avion, Trajet et Pilote comme
représenté sur la figure 2.12.
La transformation consistant à supprimer le type-association ternaire du modèle de la figure
2.12 produit le modèle de la figure 2.13. Ce modèle fait immédiatement apparaître une erreur de
conception qui était jusque-là difficile à diagnostiquer : généralement, à un vol donné sont
affectés plusieurs pilotes (par exemple le commandant de bord et un copilote) et non pas un seul.
Le modèle correct modélisant cette situation est celui de la figure 2.14 où le type-entité Vol ne
peut être transformé en un type-association ternaire Vol comme sur la figure 2.12.
Fig. 2.12 – Modèle représentant un type-association ternaire Vol liant trois type-entités Avion,
Trajet et Pilote.
Fig. 2.13 – Transformation du type-association ternaire de la figure 2.12 en un type-entité et

trois type-associations binaires.
43
Fig. 2.14 – Modèle de la figure 2.13 corrigé au niveau des cardinalités
2.4 Règles de bonne formation d’un modèle entités-associations

La bonne formation d’un modèle entités-associations permet d’éviter une grande partie des
sources d’incohérences et de redondance. Pour être bien formé, un modèle entités-associations
doit respecter certaines règles et les type-entités et type-associations doivent être normalisées.
Un bon principe de conception peut être formulé ainsi : « une seule place pour chaque fait ».
Bien que l’objectif des principes exposés dans cette section soit d’aider le concepteur à obtenir
un diagramme entités-associations bien formé, ces principes ne doivent pas être interprétés
comme des lois. Qu’il s’agisse des règles de bonne formation ou des règles de normalisation, il
peut exister, très occasionnellement, de bonnes raisons pour ne pas les appliquer.
2.4.1 Règles portant sur les noms
Règle 2.21 Dans un modèle entités-associations, le nom d’un type-entité, d’un type-
association ou d’un attribut doit être unique.
Fig. 2.19 – La présence des deux type-entités Enseignant et Etudiant est symptomatique d’une
modélisation inachevée. A terme, ces deux type-entités doivent être fusionnés en un unique
type-entité Personne. Référez-vous à la règle 2.25 pour plus de précisions concernant cette
erreur
de modélisation
Lorsque des attributs portent le même nom, c’est parfois le signe d’une modélisation
inachevée (figure2.19) ou d’une redondance (figure 2.20). Sinon, il faut simplement ajouter au
nom de l’attribut le nom du type-entité ou du type-association dans lequel il se trouve (figure
2.21).
Il faut toutefois remarquer que le dernier cas décrit n’est pas rédhibitoire et que les SGDB
Relationnel s’accommodent très bien de relations comportant des attributs de même nom.
L’écriture des requêtes sera tout de même plus lisible si les attributs ont tous des noms
différents.
Fig. 2.21 – Dans cette situation, les deux attributs Adresse doivent simplement être renommés en
Adresse client et Adresse fournisseur. Il en va de même pour les deux attributs Nom.
2.5.2 Règles de normalisation des attributs
Règle 2.22 Il faut remplacer un attribut multiple en un type-association et un type-entité
supplémentaires.
Fig. 2.22 – Remplacement des attributs multiples en un type-association et un type-entité et

décomposition des attributs composites.
En effet, les attributs multiples posent régulièrement des problèmes d’évolutivité du modèle.
Par exemple, sur le modèle de gauche de la figure 2.22, comment faire si un employé possède
deux adresses secondaires ou plusieurs numéros de portable ?
Il est également intéressant de décomposer les attributs composites comme l’attribut Adresse
par exemple. Il est en effet difficile d’écrire une requête portant sur la ville où habitent les
employés si cette information est noyée dans un unique attribut Adresse.
Règle 2.23 Il ne faut jamais ajouter un attribut dérivé d’autres attributs, que ces autres
attributs se trouvent dans le même type-entité ou pas.
En effet, les attributs dérivés induisent un risque d’incohérence entre les valeurs des attributs
de base et celles des attributs dérivés. La figure 2.23 illustre le cas d’un attribut Montant total
dans un type-entité Commande qui peut être calculé à partir des attributs Quantité du type
association Contenir et Prix unitaire du type-entité Article. Il faut donc supprimer l’attribut
Montant total dans le type-entité Commande. D’autres attributs dérivés sont également à éviter
comme l’âge, que l’on peut déduire de la date de naissance et de la date courante. Il faut
cependant faire
Fig. 2.30 – Même si toutes les cardinalités maximale sont de 1, il vaut mieux conserver le type-
association Etre.
Règle 2.29 Il faut veiller à éviter les type-associations redondants. En effet, s’il existe deux
chemins pour se rendre d’un type-entité à un autre, alors ces deux chemins doivent avoir deux
significations ou deux durées de vie distinctes. Dans le cas contraire, il faut supprimer le chemin
le plus court puisqu’il est déductible des autres chemins.
Par exemple, dans le modèle représenté sur la figure 2.31, si un client ne peut pas régler la
facture d’un autre client, alors le type-association Payer est redondant et doit purement et
simplement être supprimé du modèle (cf. figure 2.32). On pourra toujours retrouver le client qui
a effectué un règlement en passant par la facture correspondante. Par contre, si un client peut
régler la facture d’un autre client, alors c’est la règle 2.27) qu’il faut appliquer : on remplace le
type-entité Règlement par un type-association Régler (cf. figure 2.33)

45
Fig. 2.31 – Si un client ne peut pas régler la facture d’un autre client, alors le type-association
Payer est inutile.
Fig. 2.32 – Solution au problème de la redondance du type-association de la figure ( 2.31)
Fig. 2.33 – Dans le modèle de la figure 2.31, si un client peut régler la facture d’un autre
client, il faut remplacer le type-entité Règlement par un type-association Régler.
2.5.4 Normalisation des type-entités et type-associations

Introduction
Les formes normales sont différent stades de qualité qui permettent d’éviter la redondance,
source d’anomalies. La normalisation peut être aussi bien effectuée sur un modèle entités
associations, où elle s’applique sur les type-entités et type-associations, que sur un modèle
relationnel.
Il existe 5 formes normales principales et deux extensions. Plus le niveau de normalisation
est élevé, plus le modèle est exempte de redondances. Un type-entité ou un type-association en
forme normale de niveau n est automatiquement en forme normale de niveau n - 1. Une
modélisation rigoureuse permet généralement d’aboutir directement à des type-entités et type
associations en forme normale de Boyce-Codd.
Nous avons décidé de présenter deux fois cette théorie de la normalisation :
– Une première fois, dans le cadre du modèle entités-associations (la présente section
2.5.4). en privilégiant une approche plus intuitive qui n’introduit pas explicitement la notion de
dépendance fonctionnelle (et encore moins les notions de dépendance multi valuée et de
jointure). Nous nous arrêterons, dans cette section, à la forme normale de Boyce-Codd.
– Puis une seconde fois, dans le cadre de modèle relationnel (section 3.2), en privilégiant
une approche plus formelle s’appuyant sur la définition des dépendances fonctionnelle, multi-
valuée et de jointure. Nous irons alors jusqu’à la cinquième forme normale.
Première forme normale (1FN)
Fig. 2.34 – Exemple de normalisation en première forme normale.
- Première forme normale (1FN)- Un type-entité ou un type-association est en première

forme normale si tous ses attributs sont élémentaires, c’est-à-dire non décomposables.
Un attribut composite doit être décomposé en attributs élémentaires (comme l’attribut
Adresse sur la figure 2.34) ou faire l’objet d’une entité supplémentaire (comme l’attribut
Occupants sur la figure 2.34. L’élémentarité d’un attribut est toutefois fonction des choix de
gestion. Par exemple, la propriété Adresse peut être considérée comme élémentaire si la gestion
de ces adresses est globale. Par contre, s’il faut pouvoir considérer les codes postaux, les noms
de rues, . . ., il convient d’éclater la propriété Adresse en Adresse (au sens numéro
d’appartement, numéro et nom de rue, . . .), Code postal et Ville. En cas de doute, il est
préférable (car plus général) d’éclater une propriété que d’effectuer un regroupement.
- Deuxième forme normale (2FN)
Fig. 2.35 – Exemple de normalisation en deuxième forme normale. On suppose qu’un même
fournisseur peut fournir plusieurs produits et qu’un même produit peut être fourni par différents
fournisseurs.
- Deuxième forme normale (2FN)

Un type-entité ou un type-association est en deuxième forme normale si, et seulement si, il est
en première forme normale et si tout attribut n’appartenant pas à la clé dépend de la totalité de
cette clé.
Autrement dit, les attributs doivent dépendre de l’ensemble des attributs participant à la clé.
Ainsi, si la clé est réduite à un seul attribut, ou si elle contient tous les attributs, le type-entité ou
le type-association est, par définition, forcément en deuxième forme normale. La figure 2.35
montre un type-entité Article décrivant des produits provenant de différents fournisseurs. On
suppose qu’un même fournisseur peut fournir plusieurs produits et qu’un même produit peut être
fourni par différents fournisseurs. Dans ce cas, les attributs Produit ou Fournisseur ne peuvent
constituer un identifiant du type-entité Article. Par contre, le couple Produit/Fournisseur
constitue bien un identifiant du type-entité Article. Cependant, l’attribut Adresse fournisseur ne
dépend maintenant que d’une partie de la clé (Fournisseur). Opter pour une nouvelle clé
arbitraire réduite à un seul attribut N˚ article permet d’obtenir un type-entité Article en deuxième
forme normale. On va voir dans ce qui suit que cette solution n’a fait que déplacer le problème.
- Troisième forme normale (3FN)

Fig. 2.36 – Exemple de normalisation en troisième forme normale. Dans cet exemple,
l’attribut Adresse fournisseur dépend de l’attribut Fournisseur.
47
-Troisième forme normale (3FN)- Un type-entité ou un type-association est en
troisième forme normale si, et seulement si, il est en deuxième forme normale et si tous ses
attributs
dépendent directement de sa clé et pas d’autres attributs.
Cette normalisation peut amener à dés imbriquer des type-entités cachées comme le montre la
figure 2.36.
Un type-entité ou un type-association en deuxième forme normale avec au plus un attribut qui
n’appartient pas à la clé est, par définition, forcément en troisième forme normale.
2.5 Élaboration d’un modèle entités-associations

2.6.1 Étapes de conceptions d’un modèle entités-associations
Pour concevoir un modèle entités-associations, vous devrez certainement passer par une
succession d’étapes. Nous les décrivons ci-dessous dans l’ordre chronologique. Sachez
cependant que la conception d’un modèle entités-associations est un travail non linéaire. Vous
devrez régulièrement revenir à une étape précédente et vous n’avez pas besoin d’en avoir
terminé avec une étape pour commencer l’étape suivante
Recueil des besoins – C’est une étape primordiale. Inventoriez l’ensemble des données à
partir des documents de l’entreprise, d’un éventuel cahier des charges et plus généralement de
tous les supports de l’information. N’hésitez pas à poser des questions.
Tri de l’information – Faites le tri dans les données recueillies. Il faut faire attention, à ce
niveau, aux problèmes de synonymie/polysémie. En effet, les attributs ne doivent pas être
redondants. Par exemple, si dans le langage de l’entreprise on peut parler indifféremment de
référence d’article ou de n˚ de produit pour désigner la même chose, cette caractéristique ne
devra se concrétiser que par un unique attribut dans le modèle. Inversement, on peut parler
d’adresse pour désigner l’adresse du fournisseur et l’adresse du client, le contexte permettant de
lever l’ambiguïté. Par contre, dans le modèle, il faudra veiller à bien distinguer ces deux
caractéristiques par deux attributs distincts. Un autre exemple est celui d’une entreprise de
production fabricant des produits à destination d’une autre société du même groupe. Il se peut
que dans ce cas, le prix de production (i.e. le coût de revient industriel) soit le même que prix de
vente (aucune marge n’est réalisée). Même dans ce cas où les deux caractéristiques sont
identiques pour chaque entité (prix de production égale prix de vente), il faut impérativement les
scinder en deux attributs au niveau du type-entité Produit. Sinon, cette égalité factuelle
deviendrait une contrainte imposée par le modèle, obligeant alors l’entreprise de production à
revoir son système le jour où elle décidera de réaliser une marge (prix de production inférieure
au prix de vente).
Identification des type-entités – Le repérage d’attributs pouvant servir d’identifiant permet
souvent de repérer un type-entité. Les attributs de ce type-entité sont alors les attributs qui
dépendent des attributs pouvant servir d’identifiant. Attention, un même concept du monde réel
peut être représenté dans certains cas comme un attribut et dans d’autres cas comme un type-
entité, selon qu’il a ou non une existence propre. Par exemple, la marque d’une automobile peut
être vue comme un attribut du type-entité Véhicule de la base de données d’une préfecture mais
aussi comme un type entité Constructeur automobile dans la base de données du Ministère de
l’Industrie. Lorsqu’on ne parvient pas à trouver d’identifiant pour un type-entité, il faut se
demander s’il ne s’agit pas en fait d’un type-association. Si ce n’est pas le cas, un identifiant
arbitraire numérique entier peut faire l’affaire.
Identification des type-associations – Identifiez les type-associations reliant les type-entités
du modèle. Le cas échéant, leur affecter les attributs correspondant. Il est parfois difficile de
faire un choix entre un type-entité et un type-association. Par exemple, un mariage peut être
considéré comme un type-association entre deux personnes ou comme un type-entité pour lequel
on veut conserver un numéro, une date, un lieu, . . ., et que l’on souhaite manipuler en tant que
tel. Étudiez également les cardinalités des type-associations retenus. Lorsque toutes les pattes
d’un type-association portent la cardinalité 1; 1, il faut se demander si ce type-association et les
type-entités liés ne décrivent pas en fait un seul type-entité (cf. règle 2.29).
Vérification du modèle – Vérifiez que le modèle respecte bien les règles que nous avons
énoncés et les définitions concernant la normalisation des type-entités et des type-associations.
Le cas échéant, opérez les modifications nécessaires pour que le modèle soit bien formé.
Remarque : pour faciliter la lecture du schéma, il est assez courant de ne pas y faire figurer
les attributs ou de ne conserver que ceux qui font partie des identifiants. Les attributs cachés
doivent alors absolument être spécifiés dans un document à part
2.6.2 Conseils divers
Concernant le choix des noms
Pour les type-entités, choisissez un nom commun décrivant le type-entité (ex : Étudiant,
Enseignant, Matière). Certain préfèrent mettre le nom au pluriel (ex : Étudiants, Enseignants,
Matières). Restez cependant cohérents, soit tous les noms de type-entité sont au pluriel, soit ils
sont tous au singulier. Pour les type-association, choisissez un verbe à l’infinitif, éventuellement
à la forme passive ou accompagné d’un adverbe (ex : Enseigner, Avoir lieu dans). Pour les
attributs, utilisez un nom commun au singulier éventuellement accompagné du nom du type-
entité ou du type-association dans lequel il se trouve (ex : nom de client, numéro d’article).
Concernant le choix des identifiants des type-entités
Évitez les identifiants composés de plusieurs attributs (comme, par exemple, un identifiant
formé par les attributs nom et prénom d’un type-association Personne) car :
– ils dégradent les performances du SGBD,
– mais surtout l’unicité supposée par une telle démarche finit généralement, tôt ou tard, par
être démentie !
Évitez les identifiants susceptibles de changer au cours du temps (comme la plaque
d’immatriculation d’un véhicule).
Évitez les identifiants du type chaîne de caractère. En fait, il est souvent préférable de choisir
un identifiant arbitraire de type entier pour les type-entités. Cet identifiant deviendra une clé
primaire dans le schéma relationnel et le SGBD l’incrémentera automatiquement lors de la
création de nouvelles instances. L’inconvénient de cette pratique est qu’il devient possible de se
retrouver avec deux instances du type-entités représentant le même objet mais avec deux
numéros différents. Malgré cette inconvénient, cette politique de l’identifiant reste largement
avantageuse dans la pratique et permet, en outre, de s’affranchir (en la satisfaisant
automatiquement) de la deuxième forme normale (cf. section 2.5.4).
Bien distinguer les concepts de données et de traitements
La modélisation conceptuelle de données exclut la représentation des traitements futurs sur
ces données. Toutefois, elle nécessite la connaissance de ces traitements pour prévoir les
données élémentaires indispensables à ceux-ci. En conséquence, il existe une confusion
fréquente entre les concepts de données et de traitements. Par exemple, la facturation est un
traitement qui nécessite de connaître toutes les caractéristiques d’une commande. Par contre, la
facturation ne se traduit ni par un type-entité, ni par un type association dans le schéma entités-
associations

49
II 2- MODELE RELATIONNEL
.2.1 Introduction aux contraintes d’intégrité

Soit le schéma relationnel minimaliste suivant :
– Acteur(Num-Act, Nom, Prénom)
– Jouer(Num-Act, Num-Film)
– Film(Num-Film, Titre, Année)
Contrainte d’intégrité de domaine

Toute comparaison d’attributs n’est acceptée que si ces attributs sont définis sur le même
domaine. Le SGBD doit donc constamment s’assurer de la validité des valeurs d’un attribut.
C’est pourquoi la commande de création de table doit préciser, en plus du nom, le type de
chaque colonne.
Par exemple, pour la table Film, on précisera que le Titre est une chaîne de caractères et
l’Année une date. Lors de l’insertion de n-uplets dans cette table, le système s’assurera que les
différents champs du n uplet satisfont les contraintes d’intégrité de domaine des attributs
précisées lors de la création de la base. Si les contraintes ne sont pas satisfaites, le n-uplet n’est,
tout simplement, pas inséré dans la table.
Contrainte d’intégrité de table (ou de relation ou d’entité)
Lors de l’insertion de n-uplets dans une table (i.e. une relation), il arrive qu’un attribut soit
inconnu ou non défini. On introduit alors une valeur conventionnelle notée NULL et appelée
valeur nulle.
Cependant, une clé primaire ne peut avoir une valeur nulle. De la même manière, une clé
primaire doit toujours être unique dans une table. Cette contrainte forte qui porte sur la clé
primaire est appelée contrainte d’intégrité de relation.
Tout SGBD relationnel doit vérifier l’unicité et le caractère défini (NOT NULL) des
valeurs de la clé primaire.
Contrainte d’intégrité de référence
Dans tout schéma relationnel, il existe deux types de relation :
– les relations qui représentent des entités de l’univers modélisé ; elles sont qualifiées de
statiques, ou d’indépendantes ; les relations Acteur et Film en sont des exemples ;
– les relations dont l’existence des n-uplets dépendent des valeurs d’attributs situées dans
d’autres relations ; il s’agit de relations dynamiques ou dépendantes ; la relation Jouer en est un
exemple.
Lors de l’insertion d’un n-uplet dans la relation Jouer, le SGBD doit vérifier que les valeurs
Num-Act et Num-Film correspondent bien, respectivement, à une valeur de Num-Act existant
dans la relation Acteur et une valeur Num-Film existant dans la relation Film.
Lors de la suppression d’un n-uplet dans la relation Acteur, le SGBD doit vérifier qu’aucun n-
uplet de la relation Jouer ne fait référence, par l’intermédiaire de l’attribut Num-Act, au nuplet
que l’on cherche à supprimer. Le cas échéant, c’est-à-dire si une, ou plusieurs, valeur
correspondante de Num-Act existe dans Jouer, quatre possibilités sont envisageables :
– interdire la suppression ;
– supprimer également les n-uplets concernés dans Jouer ;
– avertir l’utilisateur d’une incohérence ;
– mettre les valeurs des attributs concernés à une valeur nulle dans la table Jouer, si
l’opération est possible (ce qui n’est pas le cas si ces valeurs interviennent dans une clé primaire)
;
2.2 Créer une table : CREATE TABLE
Une table est un ensemble de lignes et de colonnes. La création consiste à définir (en fonction
de l’analyse) le nom de ces colonnes, leur format (type), la valeur par défaut à la création de la
ligne (DEFAULT) et les règles de gestion s’appliquant à la colonne (CONSTRAINT).
Création simple
La commande de création de table la plus simple ne comportera que le nom et le type de
chaque colonne de la table. La syntaxe est la suivante :
CREATE TABLE nom_table (nom_col1 TYPE1, nom_col2 TYPE2, ...)
Les types de données
Les types de données peuvent être :
INTEGER : Ce type permet de stocker des entiers signés codés sur 4 octets.
BIGINT : Ce type permet de stocker des entiers signés codés sur 8 octets.
REAL : Ce type permet de stocker des réels comportant 6 chiffres significatifs codés sur 4
octets.
DOUBLE PRECISION : Ce type permet de stocker des réels comportant 15 chiffres
significatifs
codés sur 8 octets.
NUMERIC [(précision, [longueur])] : Ce type de données permet de stocker des données
numériques à la fois entières et réelles avec une précision de 1000 chiffres significatifs.
Longueur précise le nombre maximum de chiffres significatifs stockés et précision donne le
nombre maximum de chiffres après la virgule.
CHAR (longueur) : Ce type de données permet de stocker des chaînes de caractères de
longueur fixe. Longueur doit être inférieur à 255, sa valeur par défaut est 1.
VARCHAR (longueur) : Ce type de données permet de stocker des chaînes de caractères de
longueur variable. Longueur doit être inférieur à 2000, il n’y a pas de valeur par défaut.
DATE : Ce type de données permet de stocker des données constituées d’une date.
TIMESTAMP : Ce type de données permet de stocker des données constituées d’une date et
d’une
heure.
BOOLEAN : Ce type de données permet de stocker des valeurs Booléenne.
MONEY : Ce type de données permet de stocker des valeurs monétaires.
TEXT : Ce type de données permet des stocker des chaînes de caractères de longueur variable.
Création avec Insertion de données

On peut insérer des données dans une table lors de sa création par la commande suivante :
CREATE TABLE nom_table [(nom_col1, nom_col2, ...)] AS SELECT ...
On peut ainsi, en un seul ordre SQL créer une table et la remplir avec des données provenant
du résultat d’un SELECT. Si les types des colonnes ne sont pas spécifiés,
ils correspondront à ceux du SELECT. Il en va de même pour les noms des colonnes. Le
SELECT
51
peut contenir des fonctions de groupes mais pas d’ORDER BY (cf. section 4.7.2 et 4.5.6) car les
lignes d’une table ne peuvent pas être classées.
2.3 Contraintes d’intégrité

Syntaxe
A la création d’une table, les contraintes d’intégrité se déclarent de la façon suivante :
CREATE TABLE nom_table (
nom_col_1 ty pe_1 [CONSTRAINT nom_1_1] contrainte_de_colonne_1_1
[CONSTRAINT nom_1_2] contrainte_de_colonne_1_2
... ...
[CONSTRAINT nom_1_m] contrainte_de_colonne_2_m,
nom_col_2 type_2 [CONSTRAINT nom_2_1] contrainte_de_colonne_2_1
[CONSTRAINT nom_2_2] contrainte_de_colonne_2_2
... ...
[CONSTRAINT nom_2_m] contrainte_de_colonne_2_m,
...
nom_col_n type_n [CONSTRAINT nom_n_1] contrainte_de_colonne_n_1
[CONSTRAINT nom_n_2] contrainte_de_colonne_n_2
... ...
[CONSTRAINT nom_n_m] contrainte_de_colonne_n_m,
[CONSTRAINT nom_1] contrainte_de_table_1,
[CONSTRAINT nom_2] contrainte_de_table_2,
... ...
[CONSTRAINT nom_p] contrainte_de_table_p
)
Contraintes de colonne
Les différentes contraintes de colonne que l’on peut déclarer sont les suivantes :
NOT NULL ou NULL : Interdit (NOT NULL) ou autorise (NULL) l’insertion de valeur NULL
pour cet attribut.
UNIQUE : Désigne l’attribut comme clé secondaire de la table. Deux n-uplets ne peuvent
recevoir des valeurs identiques pour cet attribut, mais l’insertion de valeur NULL est
toutefois autorisée. Cette contrainte peut apparaître plusieurs fois dans l’instruction.
PRIMARY KEY : Désigne l’attribut comme clé primaire de la table. La clé primaire étant
unique, cette contrainte ne peut apparaître qu’une seule fois dans l’instruction. La définition
d’une clé primaire composée se fait par l’intermédiaire d’une contrainte de table. En fait, la
contrainte PRIMARY KEY est totalement équivalente à la contraite UNIQUE NOT NULL.
REFERENCES table [(colonne)] [ON DELETE CASCADE] : Contrainte d’intégrité
référentielle pour l’attribut de la table en cours de définition. Les valeurs prises par cet
attribut doivent exister dans l’attribut colonne qui possède une contrainte PRIMARY KEY ou
UNIQUE dans la table table. En l’absence de précision d’attribut colonne, l’attribut retenu est
celui correspondant à la clé primaire de la table table spécifiée.
CHECK (condition) : Vérifie lors de l’insertion de n-uplets que l’attribut réalise la condition.
DEFAULT valeur : Permet de spécifier la valeur par défaut de l’attribut.
Contraintes de table
Les différentes contraintes de table que l’on peut déclarer sont les suivantes :
PRIMARY KEY (colonne, ...) : Désigne la concaténation des attributs cités comme clé
primaire de la table. Cette contrainte ne peut apparaître qu’une seule fois dans l’instruction.
UNIQUE (colonne, ...) : Désigne la concaténation des attributs cités comme clé secondaire de la
table. Dans ce cas, au moins une des colonnes participant à cette clé secondaire doit permettre
de distinguer le n-uplet. Cette contrainte peut apparaître plusieurs fois dans l’instruction.
FOREIGN KEY (colonne, ...) REFERENCES table [(colonne, ...)]
[ON DELETE CASCADE | SET NULL] : Contrainte d’intégrité référentielle pour un
ensemble d’attributs de la table en cours de définition. Les valeurs prises par ces attributs
doivent exister dans l’ensemble d’attributs spécifié et posséder une contrainte PRIMARY
KEY ou UNIQUE dans la table.
CHECK (condition) : Cette contrainte permet d’exprimer une condition qui doit exister entre
plusieurs attributs de la ligne. Les contraintes de tables portent sur plusieurs attributs de la
table sur laquelle elles sont définies. Il n’est pas possible de définir une contrainte d’intégrité
utilisant des attributs provenant de deux ou plusieurs tables. Ce type de contrainte sera mis en
œuvre par l’intermédiaire de déclencheurs de base de données (trigger, cf. section ??).
Complément sur les contraintes
ON DELETE CASCADE : Demande la suppression des n-uplets dépendants, dans la table en
cours de définition, quand le n-uplet contenant la clé primaire référencée est supprimé dans la
table maître.
ON DELETE SET NULL : Demande la mise à NULL des attributs constituant la clé étrangère
qui font référence au n-uplet supprimé dans la table maître. La suppression d’un n-uplet dans
la table maître pourra être impossible s’il existe des n-uplets dans d’autres tables référençant
cette valeur de clé primaire et ne spécifiant pas l’une de ces deux options.
42.4 Supprimer une table : DROP TABLE
Supprimer une table revient à éliminer sa structure et toutes les données qu’elle contient. Les
index associés sont également supprimés. La syntaxe est la suivante :
DROP TABLE nom_table
2.5 Modifier une table : ALTER TABLE
Ajout ou modification de colonne
ALTER TABLE nom_table {ADD/MODIFY} ([nom_colonne type [contrainte], ...])
Ajout d’une contrainte de table
ALTER TABLE nom_table ADD [CONSTRAINT nom_contrainte] contrainte La syntaxe de
déclaration de contrainte est identique à celle vue lors de la création de table. Si des données
sont déjà présentes dans la table au moment où la contrainte d’intégrité est ajoutée, toutes les
lignes doivent vérifier la contrainte. Dans le cas contraire, la contrainte n’est pas posée sur la
table.
Renommer une colonne
53
ALTER TABLE nom_table RENAME COLUMN ancien_nom TO nouveau_nom
Renommer une table
ALTER TABLE nom_table RENAME TO nouveau_nom
2.6 Modifier une base – Langage de manipulation de données (LMD)

2.63.1 Insertion de n-uplets : INSERT INTO
La commande INSERT permet d’insérer une ligne dans une table en spécifiant les valeurs à
insérer. La syntaxe est la suivante :
INSERT INTO nom_table(nom_col_1, nom_col_2, ...)
VALUES (val_1, val_2, ...)
La liste des noms de colonne est optionnelle. Si elle est omise, la liste des colonnes sera
par défaut la liste de l’ensemble des colonnes de la table dans l’ordre de la création de la
table. Si une liste de colonnes est spécifiée, les colonnes ne figurant pas dans la liste auront la
valeur NULL. Il est possible d’insérer dans une table des lignes provenant d’une autre table.
La syntaxe
est la suivante :
INSERT INTO nom_table(nom_col1, nom_col2, ...)
SELECT ...
Le SELECT (cf. section 4.5 et 4.7) peut contenir n’importe quelle clause sauf un ORDER BY
(cf.
section 4.5.6).
2.362 Modification de n-uplets : UPDATE
La commande UPDATE permet de modifier les valeurs d’une ou plusieurs colonnes, dans
une ou plusieurs lignes existantes d’une table. La syntaxe est la suivante :
UPDATE nom_table
SET nom_col_1 = {expression_1 | ( SELECT ...) },
nom_col_2 = {expression_2 | ( SELECT ...) },
...
nom_col_n = {expression_n | ( SELECT ...) }
WHERE predicat
Les valeurs des colonnes nom_col_1, nom_col_2, ..., nom_col_n sont modifiées dans
toutes les lignes qui satisfont le prédicat predicat. En l’absence d’une clause WHERE, toutes
les lignes sont mises à jour. Les expressions expression_1, expression_2, ..., expression_n
peuvent faire référence aux anciennes valeurs de la ligne.
2.6.3 Suppression de n-uplets : DELETE
La commande DELETE permet de supprimer des lignes d’une table. La syntaxe est la
suivante :
DELETE FROM nom_table
WHERE predicat
Toutes les lignes pour lesquelles predicat est évalué à vrai sont supprimées. En l’absence de
clause WHERE, toutes les lignes de la table sont supprimées
Bibliographie
Guézélou, P. (2006). ModÉlisation des donnÉes : Approche pour la conception des bases des
données. (http ://philippe.guezelou.free.fr /mcd /mcd.htm).
Hernandez, M. J. & Viescas, J. L. (2001). Introduction aux requêtes SQL. Eyrolles.
Kauffman, J., Matsik, B. & Spencer, K. (2001). Maîtrisez SQL (Wrox Press, Ed.). CampusPress.
Labbé, C. (2002). Modéliser les données. Pratiko.
Marre, D. (1996, January). Introduction aux systèmes de gestion de bases de données. Support de
cours.
Petrucci, L. (2006). Base de données. Présentation projettée et travaux dirigés. (IUT GTR
Villetaneuse)
Saglio, J.-M. (2002). Dominante informatique : Module bases de données. (http ://
www.bd.enst.fr/ dombd.html ).
SQL Anywhere Studio. (2005a). ASA - Guide de programmation : Programmation avec
Embedded
SQL. (http :// www.ianywhere.com/ developer/ product_manuals/ sqlanywhere/ 0901/ fr/
html/ dbpgfr9/ 00000171.htm).
SQL Anywhere Studio. (2005b). ASA - Guide de programmation : Utilisation de SQL dans les
applications. (http :// www.ianywhere.com/ developer/ product_manuals/ sqlanywhere/ 0901/ fr/
html/ dbpgfr9/ 00000018.htm).
Szulman, S. (2005). Base de données et SGBD. Présentation projettée. The PostgreSQL Global
Development Group. (2005). Documentation PostgreSQL 7.4.7. (http ://
traduc.postgresqlfr.org/ pgsql-fr/ index.html)
Webographie
fdigallo.online.fr/cours/merise.pdf
www.commentcamarche.net/.../affich-1081964-cours-et-exercices-merise
merise.developpez.com/
www.scribd.com/doc/7472422/Cours-de-Merisety » »

55

Developement Des SI

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Developement Des SI

Transféré par

Droits d'auteur :

Formats disponibles

YAOUNDE HIGHER SCHOOL OF ECONOMICS AND

LICENCE PROFESSIONNELLE ELITE

TITRE : DEVELOPPEMENT DES

MBELEN A TSANGMINA, ing

ANNEE ACADEMIQUE 2022-2023

COURS DE DEVELOPEMENT DE SI licence TI / MBELEN A TSANGMINA, ing

A la fin de ce cours, l'étudiant sera capable de :

 Comprendre les objectifs de la méthode MERISE et les différents niveaux de sa démarche,

Prérequis : - notions de programmation Description :

COURS DE DEVELOPEMENT DE SI licence TI / MBELEN A TSANGMINA, ing

Quelques définitions utiles.

Ensemble d'opérations, logiquement liées, aboutissant à certains résultats. En conception de

Étapes ou phases de la méthode d’exécution ou de fonctionnement de quelque chose, que

Système d'information ou (information system) est un ensemble de composants de

concrétisation : phénomène inverse de l'abstraction: passe du modèle à monde réel:

Un concept est une construction de l'esprit permettant de mieux saisir intellectuellement le

Une entité : l'être, l'objet ou le concept concerné

COURS DE DEVELOPEMENT DE SI licence TI / MBELEN A TSANGMINA, ing

améliorer son fonctionnement

Un système d'Information (noté SI) représente l'ensemble des éléments participant à la

Ce système peut être divisé en deux sous-systèmes :

Base de données de l'entreprise,

La mémorisation (des informations brutes ou résultats de traitement)

A ces trois fonctions on peut en ajouter une quatrième :

collecte et saisie des informations

Classification des systèmes d'information On doit cette classification à Blumenthal. On

SICOP : Système d'Information de Contrôle Opérationnel Physique

SICOA: Système d'Information de Contrôle Opérationnel et Administratif

II- Cycle de vie

COURS DE DEVELOPEMENT DE SI licence TI / MBELEN A TSANGMINA, ing

Définition des objectifs, consistant à définir la finalité du projet et son inscription

Cycle de vie en cascade

En utilisant le découpage définit ci-haut, on aurait ainsi le cycle de vie suivant:

COURS DE DEVELOPEMENT DE SI licence TI / MBELEN A TSANGMINA, ing

D’identifier les objectifs propres de la boucle

La dernière boucle est séquencée comme un cycle de vie en cascade.

Méthodes d'informatisation Une méthode d'informatisation est composée :

de réduire la complexité du processus d'informatisation

COURS DE DEVELOPEMENT DE SI licence TI / MBELEN A TSANGMINA, ing

III- Typologie des méthodes d'informatisation

1. Type d'approche des problèmes d'informatisation:

les méthodes classiques

2 . Les domaines d'application :

les méthodes d'élaboration de schémas directeurs (Exemple : RACINES)

Quatre règles méthodologiques:

La démarche de travail est descendante, "top-down": part du général pour

COURS DE DEVELOPEMENT DE SI licence TI / MBELEN A TSANGMINA, ing

Les modèles de MERISE

Les modèles de la communication Le modèle conceptuel de la communication est

Le Modèle Conceptuel de la Communication (MCC)

Les modèles de données

On retrouve trois niveaux de modèles de données

le modèle conceptuel de données,

Le modèle logique des données (MLD)

MLD / Modèle relationnel

COURS DE DEVELOPEMENT DE SI licence TI / MBELEN A TSANGMINA, ing

Les opérateurs de l'algèbre relationnelle ( projection, sélection, jointure, opérateurs

Cette démarche algorithmique ne fournit pas à ce niveau d'élément sur l'optimisation de la

La transcription du MCD en MLD doit également être précédée d'une étape de

La modèle Physique des données (MPD ou MPhD)

Une fois le système d'information analysé et modélisé en Modèle Conceptuel de Donnée

Le SQL (Structured Query Language), ou Langage d'Interrogation Structuré, a été reconnu en

Des exemples de logiciels supportant Merise sont :