Conception Des SI (SAYOUTI)

Conception des systèmes d’information
Plan :
1. Introduction
 Génie logiciel
 Pourquoi Analyser, Concevoir et Modéliser?
 Cycle de vie d’un logiciel
 Système d’information dans l’entreprise
 Méthode MERISE
2. Niveau conceptuel
 Modèle Conceptuel de données (MCD)
 Modèle Conceptuel de Communication (MCC)
 Modèle Conceptuel de traitement (MCT)
3. Niveau logique
 Modèle logique de données (MLD)
4. Niveau organisationnel
 Modèle Organisationnel de Données (MOD)
 Modèle Organisationnel de Traitement (MOT)
5. Niveau physique
 Modèle Physique des Données (MPD)
6. Introduction à l’UML
Professeur. Adil SAYOUTI

Introduction
- Objectif
o Ce Cours a pour objectif de permettre à l’ingénieur de concevoir

et modéliser un système d'information.
o Il vise aussi à ce que l’ingénieur soit capable de lire et analyser

un cahier des charges en vue de créer un dossier de spécification
pour le projet à réaliser ou l’application à développer.
o Analyse : processus d'examen de l'existant.

o Analyse des besoins : LE QUOI?
o Conception : processus de définition de la future application

informatique : LE COMMENT?
o Modèle : représentation schématique de la réalité.
o Systèmes d'Information : ensemble des moyens (humains et

matériels) et des méthodes se rapportant au traitement de
l'information d'une organisation.
2
Introduction
- Génie logiciel
o Définition : Ensemble de méthodes, techniques et outils dédiés à

la conception, au développement et à la maintenance des
systèmes informatiques.
o Système : ensemble d'éléments en interaction dynamique, dont

les éléments sont organisés et coordonnés en vue d'atteindre un
objectif, qui évolue dans un environnement.
o Système informatique : Un ensemble d’éléments qui sont

organisés pour accomplir un but prédéfini par un traitement de
l’information. Il Utilise des : logiciels, matériels, personnes, bases
de données, documentation, procédures (étapes qui définissent
comment utiliser les éléments du système).
3
Introduction
- Génie logiciel
L'objectif du génie logiciel est d'optimiser le coût de

développement du logiciel. L'importance d'une approche
méthodologique s'est imposée à la suite de la crise de l'industrie du
logiciel à la fin des années 1970. Cette crise de l'industrie du logiciel
était principalement due à :
• l'augmentation des coûts ;

• les difficultés de maintenance et d'évolution ;
• la non-fiabilité ;
• le non-respect des spécifications ;
• le non-respect des délais.
Remarque :
Echéance : Atteindre la fin d'un délai qui avait été prévu pour la
réalisation d’une application ou projet. 4
Introduction
- Génie logiciel
Pour apporter une réponse à tous ces problèmes, le génie logiciel
s'intéresse particulièrement à la manière dont le code source d'un
logiciel est spécifié puis produit. Ainsi, le génie logiciel touche au
cycle de vie des logiciels :
o Étude de faisabilité
o Analyse des besoins :
o Besoins fonctionnels,
o Besoins non fonctionnels,
o Conception,
o Développement (Codage),
o Tests unitaires
o Intégration et tests
o Livraison
o Maintenance
5
Introduction
-Etude de faisabilité
Étude de faisabilité
o Faisabilité économique
o Faisabilité technique
– Risques de développement
– Disponibilité des ressources
– Technologie nécessaire
o Faisabilité légale
o Étude de faisabilité : aspects économiques
Analyse du rapport Coût/Bénéfice :
– Coût du système
– Bénéfices mesurables (en DH )
– Bénéfices non mesurables
• meilleure conception
• meilleures décisions marketing
• satisfaction accrue du client
L’analyse Coût/Bénéfice est souvent le moyen d’obtenir le feu
6
vert de la direction.
Introduction
- Analyse des besoins
Analyse des besoins
o Définition des besoins à différents niveaux d’abstraction :
– Besoins de l’utilisateur
– Besoins des composants
o Définition du système à réaliser avec le point de vue de l’utilisateur
et/ou du client
o Analyse des besoins : LE QUOI
o Conception : LE COMMENT
Le processus d’analyse
Processus de découverte, de raffinement, de modélisation et de
spécification
• Les utilisateurs/clients et les développeurs ont des rôles actifs
• Les utilisateurs ne sont pas satisfaits par un système bien conçu et
bien implémenté
Les utilisateurs veulent des systèmes qui satisfont leurs besoins 7

Introduction
o Fournir le livrable qui correspond à la commande passe par une

bonne compréhension de la demande client et de son
environnement technique.
o Pour cela, le chef de projet logiciel doit s'approprier le contexte,

les objectifs, les enjeux et les contraintes du système
d'information, recueillir et reformuler les besoins en
développement des différentes parties prenantes. Sa force sera
de proposer et de mettre en place la solution en adéquation avec
les besoins identifiés.
8
Introduction
o les parties prenantes de l’entreprise regroupent l’ensemble de
ceux qui participent à sa vie économique (salariés, clients,
fournisseurs, actionnaires), de ceux qui observent l’entreprise
(syndicats, ONG), et de ceux qu’elle influence plus ou moins
directement (société civile, collectivité locale). Les parties
prenantes sont toutes les personnes ayant un intérêt dans les
activités de l’entreprise.
9
Introduction
o Cette analyse au début du projet informatique permet de préparer

tranquillement (calmement) le lancement de celui-ci pour piloter
et superviser les étapes d’avancement de l’intégration de la
solution informatique.
10
Introduction
- Analyse
o Bases de la communication
o Ecouter le client
o Préparer les réunions
– Connaissance du client et des contacts
– Lecture des documents disponibles
– Penser aux objectifs de la réunion
– Penser aux problèmes
– Être à l’heure
o Compréhension minimale du problème :

– Qui est derrière la demande de cette réalisation ?
– Qui va utiliser la solution proposée ?
– Y-a-t-il des contraintes ? Des problèmes de performance ?
Une bonne analyse

• Objectif premier : Maximiser la satisfaction des utilisateurs et des clients 11
Introduction
- Analyse
Une bonne analyse
o Objectif premier : Maximiser la satisfaction des utilisateurs et des clients
o En tenant compte de 3 types de besoin
– Normaux : besoins explicitement établis
– Attendus : implicites, pas exprimés mais nécessaires
– Excitants : allant au delà des espérances des clients
Indications à suivre
o Comprendre le problème avant de commencer à créer la
spécification des besoins
– Ne pas résoudre le mauvais problème
o Développer des prototypes des interfaces utilisateurs (IHM)
– Les interfaces utilisateurs déterminent souvent la qualité…
o Noter et tracer l’origine et les raisons d’un besoin
o Utiliser des vues multiples sur les besoins
– Réduit les risques de rater quelque chose
o Classer les besoins par priorité 12
Introduction
- Cahier des charges
Le cahier des charges
o Première étape de l’expression du besoin

o Description globale des fonctions d’un nouveau produit ou des
extensions à un produit existant
• Énoncé du problème à résoudre
• Liste des fonctions de base
• Caractéristiques techniques
• Priorités de réalisation
• Facteurs de qualité
o Il doit être validé par le client et/ou l’utilisateur
o Il est la base du contrat entre clients et développeurs
o Le cahier des charges est un document technique,

sans considération économique
– sauf si on lui adjoint un plan de projet
13
Introduction
- La spécification des besoins
La spécification des besoins
o La spécification des besoins doit décrire sans ambiguïté le logiciel à

développer.
o Elle est constituée d’un ensemble de documents et de modèles.
o Toutes les personnes impliquées dans le projet doivent avoir accès à la
spécification des besoins.
o L’énoncé d’un besoin exprime un comportement ou une propriété que le
système doit respecter.
o Chaque énoncé doit traduire la présence d’un comportement très
spécifique
14
Introduction
- Besoins fonctionnels/non fonctionnels
Besoins fonctionnels
o Les besoins fonctionnels expriment une action que doit effectuer le

système en réponse à une demande (sorties qui sont produites pour un
ensemble donné d’entrées)
o Exemple : Le système doit produire automatiquement un rapport de
synthèse des ventes hebdomadaires.
Besoins non fonctionnels

- Besoin d’utilisabilité
- Besoins de performance
- Besoins de disponibilité/fiabilité
- Besoins de sécurité
- Besoins matériels
- Besoins de déploiement
15
Introduction
- Besoins fonctionnels/non fonctionnels
Besoins non fonctionnels

- Besoin d’utilisabilité
font référence aux aspects généraux de l’interface utilisateur
- Besoins de performance
décrivent les performances d’exécution du système, généralement en
termes de temps de réponse.
- Besoins de disponibilité/fiabilité
exigence de disponibilité 24/24, 7/7 sauf période de maintenance
- Besoins de sécurité
Toute information confidentielle fournie par les clients via l’Internet sera
cryptée avec le système XYZ ou par l’algorithme, la méthode….ABC..
- Besoins matériels
définissent les configurations matérielles minimales nécessaires au
fonctionnement du système
- Besoins de déploiement
décrivent la façon dont l’application sera livrée à l’utilisateur final 16
Introduction
- Qualité du logiciel
En génie logiciel, divers travaux ont mené à la définition de la

qualité du logiciel en termes de facteurs, qui dépendent, entre
autres, du domaine de l'application et des outils utilisés. Parmi ces
derniers, nous pouvons citer :
• Validité :
aptitude d'un produit logiciel à remplir exactement ses fonctions,
définies par le cahier des charges et les spécifications.
• Fiabilité ou robustesse :
aptitude d'un produit logiciel à fonctionner dans des conditions
anormales.
• Extensibilité :
facilité avec laquelle un logiciel se prête à sa maintenance, c'est-à-
dire à une modification ou à une extension des fonctions qui lui sont
demandées.
17
Introduction
• Réutilisabilité :
aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de
nouvelles applications.
• Compatibilité :
facilité avec laquelle un logiciel peut être combiné avec d'autres
logiciels.
• Efficacité :
Utilisation optimale des ressources matérielles.
• Portabilité :
facilité avec laquelle un logiciel peut être transféré sous différents
environnements matériels et logiciels.
• Vérifiabilité :
facilité de préparation des procédures de test.
18
Introduction
• Intégrité :
aptitude d'un logiciel à protéger son code et ses données contre des
accès non autorisés.
• Facilité d'emploi :
facilité d'apprentissage, d'utilisation, de préparation des données,
d'interprétation des erreurs et de rattrapage en cas d'erreur
d'utilisation.
19
Introduction
- Pourquoi modéliser?
• Un modèle est une représentation abstraite et simplifiée, d'une

entité du monde réel en vue de le décrire, de l'expliquer ou de le
prévoir.
• Un modèle permet de réduire la complexité d'un phénomène en
éliminant les détails qui n'influencent pas son comportement de
manière significative. Il reflète ce que le concepteur croit important
pour la compréhension et la prédiction du phénomène modélisé.
Exemples de modèles :
• Modèle météorologique, modèle économique, modèle
démographique Modèles prédictifs
• Plans (exemple : la construction d'un immeuble) Modèles
conceptuels
20
Introduction
• Modéliser un système avant sa réalisation permet de mieux
comprendre le fonctionnement du système. C'est également un
bon moyen pour maîtriser sa complexité et d'assurer sa cohérence.
• Un modèle est un langage commun, précis, qui est connu par

tous les membres de l'équipe et il est donc, un bon moyen pour
communiquer. Cette communication est essentielle pour aboutir à
une compréhension commune d'un problème donné.
• Dans le domaine de l'ingénierie du logiciel, le modèle permet de

mieux répartir les tâches et d'automatiser certaines d'entre elles.
C'est également un facteur de réduction des coûts et des délais.
• Par exemple, les plateformes de modélisation savent maintenant

exploiter les modèles pour faire de la génération de code (au moins
au niveau du squelette)
21
Introduction
• Le modèle est indispensable pour assurer un bon niveau de

qualité et une bonne maintenance. En effet, une fois mise en
production, l'application va devoir être maintenue, probablement
par une autre équipe, pas nécessairement la même que celle ayant
créé l'application.
• Le choix du modèle a donc une influence capitale sur les solutions

obtenues. Les systèmes non triviaux (ne sont pas simples) sont
mieux modélisés par un ensemble de modèles indépendants. Selon
les modèles employés, la démarche de modélisation n'est pas la
même.
22
Introduction
- Cycle de vie d’un logiciel
• Le cycle de vie d'un logiciel, désigne toutes les étapes du développement

d'un logiciel, de sa conception à sa mise en production. L'objectif d'un tel
découpage est 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.
Le jalon est un livrable lié à une date.
• 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
23
Introduction
Le cycle de vie du logiciel comprend généralement au minimum les étapes

suivantes :
• 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, puis l'estimation de la
faisabilité de ces besoins ;
• Spécifications ou 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
Cette étape consiste à définir précisément chaque sous-ensemble du logiciel ;
• Codage (Implémentation ou programmation)
C'est la traduction dans un langage de programmation des fonctionnalités
définies lors de la phase de conception
24
Introduction
• Tests unitaires
ils permettent de vérifier individuellement que chaque sous-ensemble du
logiciel est implémenté conformément aux spécifications ;
• Intégration
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
vise à produire les informations nécessaires pour l'utilisation du logiciel et pour
des développements ultérieurs (guide utilisateur et guide technique)
25
Introduction
• Mise en production
c'est le déploiement sur site (emplacement géographique) du logiciel ;
• Maintenance
elle comprend 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épendent du choix d'un modèle de cycle de vie entre le client et
l'équipe de développement. Le cycle de vie permet de prendre en compte,
en plus des aspects techniques, l'organisation et les aspects humains.
26
Introduction
- Modèle en cascade
• Dans ce modèle, le principe est très simple :

chaque phase se termine à une date
précise par la production de certains
documents ou logiciels. Les résultats
sont définis sur la base des interactions
entre étapes, ils sont soumis à une revue
approfondie et on ne passe à la phase
suivante que s'ils sont jugés
satisfaisants.
• L'inconvénient majeur du modèle de cycle

de vie en cascade est que la vérification
du bon fonctionnement du système est
réalisée trop tardivement : lors de la
phase d'intégration, ou pire, lors de la
mise en production
27
Introduction
- Modèle en cascade
• Avantages
– Adapté aux logiciels ou les exigences sont bien connues et non sujettes à
modification
 Fonctionnalités/attentes utilisateurs
 Technologies utilisées
– Fonctionne très bien quand la qualité est plus importante que les coûts/délais
• Limites
– la vérification du bon fonctionnement du logiciel est réalisée trop tardivement
– Fort coût de correction des erreurs si elles sont découvertes tardivement
– Ne contient pas d’activités d’analyse de risque
– Ne gère pas explicitement les changements des spécifications
• Quand l’utiliser?
– Quand les besoins sont connus et stables
– Quand la technologie à utiliser est maîtrisée
• Exemples:
• Création d’une nouvelle version d’un produit existant
• Portage d’un produit sur une nouvelle plateforme 28
Introduction
- Modèle en V
e plus utilisé.
• Il s'agit d'un modèle en cascade dans lequel le développement du logiciel
et des tests sont effectués de manière synchrone.
• Le principe de ce modèle est que toute description d'un composant est
accompagnée de tests qui permettront de s'assurer qu'il correspond à sa
description.
• Ce modèle souffre toujours du problème de la vérification trop tardive du
bon fonctionnement du système.
29
Introduction
- Modèle en V
• Avantages
– Force la documentation: une phase ne peut se terminer avant qu’un
document ne soit validé
– Le test est inhérent à chaque phase
• Les limites
– la vérification du bon fonctionnement du logiciel est réalisée trop
tardivement : Très couteux si les erreurs sont constatées
– Ne marche que si les exigences sont stables et le problème est connu
– Ne contient pas des activités d’analyse de risque
– Ne gère pas explicitement les changements des spécifications
– Quand le logiciel à développer à de très hautes exigences de qualité
– Quand les besoins sont connus à l’avance
– Les technologies à utiliser sont connues à l’avance
30
Introduction
- Modèle en spirale
• Ce modèle met l'accent sur l'activité d'analyse des risques : chaque cycle
de la spirale se déroule en quatre phases :
1. Détermination, à partir des résultats des cycles précédents, ou de

l'analyse préliminaire des besoins, des objectifs du cycle, des
alternatives pour les atteindre;
2. Analyse des risques, évaluation des alternatives et, éventuellement
maquettage ;
3. Développement et vérification de la solution retenue, un modèle
« classique » (cascade ou en V) peut être utilisé ici ;
4. Revue des résultats et vérification du cycle suivant.
• L'analyse préliminaire est affinée au cours des premiers cycles. Le modèle

utilise des maquettes exploratoires pour guider la phase de conception du
cycle suivant. Le dernier cycle se termine par un processus de développement
classique
31
Introduction
Conception et
Spécification des
résolution des
contraintes et
problèmes
objectifs
1 Cycle 2
Cycle 1
1 2 2
4 3
3
4
Prévision de la phase Développement,

suivante vérification
32
Introduction
• Avantages
• Identification des risques, impacts minimaux des risques sur le logiciel
• Fonctions critiques développées en premier
• Feedback rapide du client
• Une évaluation continue du logiciel
• Les limites
• L’évaluation des risques peut prendre beaucoup de temps
• Le modèle est très complexe
• La spirale peut s’éterniser
• Quand le prototypage est exigé
• Quand le risque est considérable
• Quand les spécifications ne sont pas stables
• Quand le produit implique de la recherche et de l’investigation
33
Introduction
- Modèle par incrément
o Dans les modèles par incrément, un seul ensemble de composants est

développé à la fois : des incréments viennent s'intégrer à un noyau de
logiciel développé au préalable. Chaque incrément est développé selon
l'un des modèles précédents.
o Les noyaux, les incréments ainsi que leurs interactions doivent donc être
spécifiés globalement, au début du projet. Les incréments doivent être
aussi indépendants que possible, fonctionnellement, mais aussi sur le plan du
calendrier du développement.
o Les premiers incréments peuvent être des maquettes (jetables s’il s’agit juste
de comprendre les besoins des utilisateurs) ou des prototypes (réutilisables
pour passer au prochain incrément en les complétant et/ou en optimisant leur
implantation).
34
Introduction
• Architecture évolutive
– Découpage fonctionnel en sous ensemble
– Développement des sous-ensembles par incrément
– (un incrément= 1 version). La première version constitue le noyau
– Les versions suivantes s’appuient sur l’existant et étendent l’architecture
35
Introduction
 Architecture stable
– La première version fournit une enveloppe complète
– Chaque nouvelle version fournit un ou plusieurs sous système en
respectant l’architecture
36
Introduction
 Avantages
– Une première version du logiciel est fournie rapidement
– Les clients peuvent ajouter des exigences à tout moments
– Chaque développement est moins complexe et donne un produit fonctionnel
– Possibilité de livraisons et de mises en service après chaque incrément
– Le client intervient à la fin de chaque incrément, il entre en relation avec le
produit très tôt
 Limites
– Architecture stable: Réalisation trop complexe; difficile de concevoir une
architecture stable dès le début
– Exige une vision sur le produit fini pour pouvoir le diviser en incréments
– Difficulté de définir le nombre d’incréments
– Incréments réutilisables inadaptés
37
Introduction
 Quand l’utiliser?
– Quand la plupart des spécifications sont connus à l’avances et vont être

sujettes à de faibles évolutions
– Quand on veut rapidement un produit fonctionnel
– Pour des projets de longues durées
– Pour des projets impliquant de nouvelles technologies
38
MERISE
Système d’Information
o La conception d'un système d'information n'est pas évidente car il faut réfléchir
à l'ensemble de l'organisation que l'on doit mettre en place. La phase de
conception nécessite des méthodes permettant de mettre en place un modèle
sur lequel on va s'appuyer.
o La modélisation consiste à créer une représentation virtuelle d'une réalité de

telle façon à faire ressortir les points auxquels on s'intéresse. Ce type de
méthode est appelé analyse. Il existe plusieurs méthodes d'analyse, la
méthode la plus utilisée en France étant la méthode MERISE (Méthode
d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise).
o Le but de cette méthode est d'arriver à concevoir un système d'information. La

méthode MERISE est basée sur la séparation des données et des traitements
à effectuer en plusieurs modèles conceptuels et physiques. La séparation des
données et des traitements assure une longue durée de vie au modèle. En
effet, l'agencement des données n'a pas à être souvent modifié (révisé), tandis
que les traitements le sont plus fréquemment.
39
MERISE
Système d’Information
o La méthode MERISE date de 1978-1979, et fait suite à une consultation

nationale lancée en 1977 par le ministère de l'Industrie dans le but de choisir
des sociétés de conseil en informatique afin de définir une méthode de
conception de systèmes d'information. Les deux principales sociétés ayant mis
au point cette méthode sont le CTI (Centre Technique d'Informatique) chargé
de gérer le projet, et le CETE (Centre d'Etudes Techniques de l'Equipement)
implanté à Aix-en-provence.
40
MERISE
Système d’information dans l’entreprise
o L’entreprise est un système complexe dans lequel transitent de très nombreux

flux d’informations. Sans un dispositif de maîtrise de ces flux, l’entreprise peut
très vite être dépassée et ne peut plus fonctionner avec une qualité de service
satisfaisante.
o L’enjeu de toute entreprise industrielle ou de services consiste donc à mettre

en place un système destiné à collecter, mémoriser, traiter et distribuer
l’information.
o Ce système d’information assurera le lien entre deux autres systèmes de

l’entreprise : système de pilotage et le système opérant
41
MERISE
o Le système de pilotage décide les actions à exécuter par le système opérant

en fonction des objectifs et des politiques de l’entreprise.
o Le système opérant englobe toutes les fonctions liées à l’activité propre de
l’entreprise : facturer les clients, régler les salariés, gérer les stocks, …
42
MERISE
43
MERISE
Architecture d’un système d’information
o Le système d’information doit décrire (ou représenter) le plus fidèlement

possible le fonctionnement du système opérant. Pour ce faire, il doit
intégrer une base d’information dans laquelle seront mémorisés la description
des objets, des règles et des contraintes du système opérant. Cette base subit
des évolutions.
o Le système d’information doit être doté d’un mécanisme (appelé processeur

d’information) destiné à piloter et à contrôler ces changements.
44
MERISE
Architecture d’un système d’information
o Le processeur d’information produit des changements dans la base

d’information à la réception d’un message. Un message contient des
informations et exprime une commande décrivant l’action à entreprendre dans
la base d’information.
o L’architecture présentée ci-dessus induit une double conception :
• Celle de la base d’information (aspect statique),
• Celle du processeur de traitement (aspect dynamique).
o Pour aider le concepteur dans ces deux tâches, la méthode Merise propose
un ensemble de formalismes et de règles destinées à modéliser de manière
indépendante les données et les traitements du système d’information.
45
Présentation de la méthode Merise
• Pour la méthode MERISE, la conception des systèmes

d’information (SI) est réalisée selon la démarche suivante :
46
o Le schéma directeur : dont le rôle est de définir, de manière

globale, la politique d’organisation et d’automatisation du système
d’information. Pour ce faire, il est nécessaire de répertorier
l’ensemble des applications informatiques existantes à modifier et
à développer.
o Pour rendre contrôlable et modulable ce développement, il est

nécessaire de découper le système d’information en sous-
ensembles homogènes et relativement indépendant. Ces sous-
ensembles sont appelés domaines. Par exemple, on peut
trouver le domaine « comptabilité », le domaine « Personnel »...
o Les résultats attendus à la fin de cette étape sont une définition

précise des domaines, une planification du développement de
chaque domaine et un plan détaillé, des applications qui doivent
être réalisées.
47
o L’étude préalable (par domaine) : doit aboutir à une présentation

générale du futur système de gestion (modèles de données et de
traitements) en indiquant les principales novations par rapport au système
actuel, les moyens matériels à mettre en œuvre, les bilans coût – avantage.
Cette étude est réalisée en quatre phases :
• Une phase de recueil : analyser l’existant afin de cerner les
dysfonctionnements du système actuel.
• Une phase de conception : pour objectif de formaliser et hiérarchiser les
orientations nouvelles en fonction des critiques formulées sur le système
actuel et d’autre part des politiques et des objectifs de la direction générale.
• Une phase d’organisation dont l’objectif est de définir le système futur au
niveau organisationnel : qui fait quoi ?
• Une phase d’appréciation dont le rôle est d’établir les coûts et les délais
des solutions définies ainsi que d’organiser la mise en œuvre de la
réalisation. A cet effet un découpage en projets est effectué.
48
o L’étude détaillée (par projet) consiste d’une part à affiner (amèliorer) les
solutions conçues lors de l’étude préalable et d’autre part à rédiger, pour
chaque procédure à mettre en œuvre, un dossier de spécifications détaillé
décrivant les supports ainsi que les algorithmes associés aux règles de
gestion… A l’issue de cette étude, il est possible de définir le cahier des
charges ainsi que le fonctionnement détaillé du futur système, du point de
vue de l’utilisateur.
o La réalisation (par application) l’objectif est l’obtention des programmes
fonctionnant sur un jeu d’essais approuvés par les utilisateurs.
o La mise en œuvre se traduit par un changement de responsabilité:
l’équipe de réalisation transfère la responsabilité du produit à l’utilisateur.
Cette étape intègre en particulier la formation des utilisateurs. Après une
période d’exploitation de quelques mois, la recette définitive de l’application
est prononcée.
o La maintenance consiste à faire évoluer les applications en fonction des
besoins des utilisateurs, de l’environnement et des progrès technologiques.
49
Merise
Cycles d’abstraction de conception des SI
La conception du système d'information se fait par étapes, afin d'aboutir à un

système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de
valider une à une chacune des étapes en prenant en compte les résultats de la phase
précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la
concordance entre données et traitement afin de vérifier que toutes les données
nécessaires aux traitements sont présentes et qu'il n'y a pas de données inutiles.
Cette succession d'étapes est appelée cycle

d'abstraction pour la conception des systèmes d'information.
50
Merise
o L'expression des besoins aboutit au MCC (Modèle conceptuel de la

communication) qui définit les flux d'informations à prendre en compte.
o L'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des

données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et
les contraintes à prendre en compte.
o Le modèle organisationnel consiste à définir le MLD (Modèle logique des

données) qui représente un choix logiciel pour le système d'information et le
MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à
l'environnement (organisationnel, spatial et temporel).
o Le modèle physique reflète un choix matériel pour le système d'information.
51
Merise
La méthode Merise préconise trois niveaux d’abstraction :
o Le niveau conceptuel qui décrit la statique et la dynamique du système

d’information en se préoccupant uniquement du point de vue du gestionnaire.
Niveau Conceptuel :
• Ce qu’il faut faire ;
• Quoi ?
o Le niveau organisationnel (logique) décrit la nature des ressources qui sont

utilisées pour supporter la description statique et dynamique du système
d’information. Ces ressources peuvent être humaines et/ou matérielles et
logicielles.
• Niveau organisationnel :
- La manière de faire ;
- Pour les traitements.
• Niveau logique :
- Choix des moyens et ressources ;
52
- Pour les données.
Merise
o Le niveau opérationnel dans lequel on choisit les techniques d’implantation

du système d’information (données et traitements).
• Niveau physique :
- Les moyens de le faire ;
- Comment ?
53
- Le niveau conceptuel
Exprime les choix fondamentaux de gestion.
Définit
• Des activités
• Des choix de gestion
• Des informations
Indépendamment
• Des aspects organisationnels
• Des aspects techniques de mise en œuvre
Du point de vue
• Des traitements: objectif, résultat, règle de gestion, enchaînement
• Des données: signification, structure, liens
55
- Le niveau organisationnel
Exprime les choix organisationnels de ressources humaines et

matérielle
Définit:
– La répartition géographique et fonctionnelle des sites de travail (du
point de vue des données et des traitements)
– Le mode de fonctionnement : temps réel ou temps différé.
– La répartition du travail homme/machine (degré et type
d’automatisation)
– Les postes de travail et leur affectation,
– La volumétrie des données
– La sécurité des données
• Indépendamment des moyens de traitement et de stockage de
données actuels ou futurs
• Les opérations conceptuelles vont être décomposées au niveau
organisationnel en une ou plusieurs opérations organisationnelles 56
- Le niveau logique
• Exprime la forme que doit prendre l’outil informatique pour être

adapté à l’utilisateur, à son poste de travail
• Indépendamment de l’informatique spécifique, des langages de
programmation ou de gestion des données
• Décrit
– Le schéma de la base de données (relationnel, hiérarchique ou
réseau)
– La répartition des données sur les déférentes unités de stockage
– Les volumes par unité de stockage
– L’optimisation des coûts induits par le mode de gestion
57
- Le niveau physique
• Traduit les choix techniques et la prise en compte de leurs

spécificité
• Répond aux besoins des utilisateurs sur les aspects logiciels et
matériels.
• Déﬁnit complètement:
– Les ﬁchiers, les programmes
– L’implantation physique des données et des traitements
– Les ressources à utiliser, les modalités de fonctionnement
58
- Les modèles
60
Le niveau conceptuel
 Modèle Conceptuel de données (MCD)
 Modèle Conceptuel de Communication (MCC)
 Modèle Conceptuel de traitement (MCT)
Modèle conceptuel de données (MCD)
La problématique des données
• Il ne suffit pas de s’intéresser au nom et aux propriétés des données :

type, longueur, valeurs.
• Il faut s’intéresser à la donnée elle-même, ses sens et ses usages.
• Exemple: sens du mot « client »
Libellé FR Sens
Client Correspond à la personne donneur d’ordre
Client de
Désigne la personne destinataire des factures
facturation
Client payeur Désigne la personne qui paye les factures
63
La problématique des données

 Il faut aussi se poser des questions sur la qualité des données existantes et
les exigences de qualité.
Contradiction Hors nomenclature
(pb de cohérence) (pb de conformité et Incohérence
d’intégrité)
Date Code
n°ss Nom Prénom sexe Adresse Ville Téléphone
naissance Postal
3, rue de la
171046734543621 Dupond Albert 10/04/1971 F 99999 Strasbourg 01 32145678
gare
Rue des
268065415498494 Durant Lise 18/06/1968 F 54000 Nancy 0345762345
Lilas
0345762345
268065415498494 Durant Lisa 18.06.1968 F 54000 Null
Erreur de Format
(pb de conformité)
Doublon Pb d’intégrité
Erreur de saisie (pb Absence de valeur 64
(pb d’unicité) référentielle
d’exactitude) (pb de complétude)
Objectif du MCD
Ecrire de façon formelle les données d’une base de données. Il s'agit

donc d'une représentation des données, facilement compréhensible,
permettant de décrire la base de données à l'aide d'entités.
 Il est à la base de tous les SGBD dits relationnels (MySQL,

SQL Server Oracle, DB2…) qui sont les plus utilisés
actuellement dans les entreprises.
 Il est généralement représenté à l’aide du formalisme «entités-

associations » sous la forme de :
ENTITES, ASOCIATIONS et PROPRIETES.
65
Entité
Concept concret ou abstrait (un fait, un moment…) identifié du
monde réel caractérisé par un nom et une liste de propriétés.
 Une entité concrète possède une existence physique : client,

équipement, et produit
 Une entité abstraite a une existence conceptuelle : une transaction,
un tarif, l’annulation d’un vol d’avion
 Exemples
 Le client Jean Dupond est une entité concrète
 La commande COM0001 est une entité abstraite
 L’entité Personne(nom, prénom), et l’entité Voiture(nom , puissance
fiscale) ne peuvent pas être groupés en une même entité car ils ne
partagent pas leurs propriétés
.
Client
L’ entité se représente par un cadre contenant

66
le nom de l’entité
Attribut (Entité)
Propriété d’une entité ou d’une association caractérisée par un nom et
un type élémentaire.
 Est un élément d’une entité :
– a un nom unique,
– permet de mémoriser une valeur,
– doit avoir un sens (donc une valeur) pour chacune des occurrences de l’entité.
 Exemple
Client Entité
N_client
Nom Propriétés
Prénom
Représentation graphique d’une entité comportant trois propriétés
67
Règles concernant les attributs
Règle 1
Une propriété ne peut en aucun cas être partagé par plusieurs
entités/associations.
Règle 2
Une propriété est une donnée élémentaire, ce qui exclut des
données calculées ou dérivées.
Règle 3
Une entité et ses propriétés doivent être cohérents entre eux (i.e. ne
traitent qu’un seul sujet).
68
Occurrence: entité
Elément particulier d’une entité, identifiable de façon unique (instance)
 Deux occurrences de l’entité ne peuvent pas avoir la même valeur d’identifiant.
 Exemple
L’entité client1 dont le N° est 06464M est une

occurrence de l’entité client
Client 1 Client 2
064646M 012646M
Dupont Revaud
Frank jerome
23 BD zola 2 BD alpha
69
Identifiant: entité
Attribut ou groupe d’attributs permettant d’identifier chaque

occurrence d’une entité.
Règle 4
Chaque entité possède au moins un identifiant, éventuellement
formé de plusieurs propriétés.
 Exemple
Client
N°client Identifiant
Nom simple
Prénom
Adresse
70
 identifiant : entité (suite)
 Il existe 2 types d’identifiants: simple et composé
 Un identifiant est simple s’il est formé d’une seule propriété.

 Un identifiant est composé s’il est formé de plusieurs propriétés,
 Exemple:
 Entité avec identifiant composé
Appartement
N°Appt Identifiant
Adresse composé
Superficie
71
 Dictionnaire de données
 Un dictionnaire de données définit les informations, entités et propriétés de
l'entreprise, et en les gérant au sein d'un MCD
 Les dictionnaires de données assurent la cohérence d'utilisation en

fournissant une définition unique pour toutes les données utilisés dans
l'entreprise. Ils sont utilisés pour standardiser le contenu, le contexte et la
définition des données ainsi que pour assurer la cohérence et la réutilisabilité.
72
 Dictionnaire de données
 Il s'agit de recenser les différentes données, sachant que l'on distingue 3
types de données :
1. Données élémentaires :
Elles ne sont pas obtenues par calcul à partir d'autres données.
Exemple : On donne la quantité, le prix de l'article, calculer le coût total. La
quantité et le prix sont des données élémentaires
2. Données calculées:
Elles résultent d'un calcul effectué à partir d'autres données.
Exemple : Le coût total est une donnée calculée (= qte * prix unitaire ).
3. Données paramètres:
C'est une donnée qui ne prend qu'une unique valeur.
Exemple : L'entreprise s'appelle PVF. La donnée nom de l'entreprise est une
donnée qui ne prend qu'une seule valeur : PVF. Il s'agit donc d'une donnée
paramétrable.
73
 Dictionnaire de données (exemple)

Définit pour chaque donnée son type, sa nature ( élémentaire, calculée,
paramètre), sa description et les règles de calcul concernant les données
calculées )
74
Association
Lien logique entre entités dont le type est défini par un verbe et une
liste éventuelle de propriétés
 On appelle collection de l’association l’ensemble des entités qu’elle relie.
Règle 5
Une propriété peut être placée dans une association uniquement
lorsqu’il dépend de toutes les entités liées par l’association.
75
 Association : exemple
Nom de l’association
Client Commande
N°client Effectuer N°Commande
Nom Date Date livraison
Prénom Commande Total commande
Adresse
Extrémités de
l’association
collection de
l’association
76
 Association : identifiant
 Il est implicite !
– C’est un ensemble composé des identifiants de la collection de l’association.
Règle 6
La concaténation des identifiants des entités liés à une
association constitue l’identifiant de cette association (cet
identifiant n’est pas mentionné sur le modèle (il est implicite).
 Exemple:
– l’identifiant de l’association « effectuer » est le couple (N° client, N° commande)
Client
Commande
N°client Effectuer N°Commande
Nom Date Commande
Prénom Date livraison
Adresse Total commande
77
 Association : cardinalités (1)

Contrainte inscrite à chaque extrémité d’une association comportant un
couple de valeurs (min-max) qui établit, pour chaque entité de
l’association, le nombre minimum et maximum d’occurrences d’une
association auxquelles elle peut participer
 Exemple
– Un client peut effectuer de 0 à n commande, mais une commande ne
peut être effectuer que par un seul client
Source Sens de lecture Destination

Client Commande
N°client (0,n) Effectuer (1,1) N°Commande
Nom Date Commande
78

Règle 7&8
Règle 7: L’expression de la cardinalité est obligatoire pour chaque
patte d’une association
Règle 8: Une cardinalité minimal est toujours 0 ou 1, et une cardinalité
maximale est toujours 1 ou n
 Remarques
– Une cardinalité maximale de 0 n’a pas de sens
– Si une cardinalité maximale est connu et vaut 2, 3 ou plus, alors nous
considérons qu’elle est indéterminée et vaut n
– Les cardinalités minimales qui valent plus de 1 sont modélisées par 1
 Les seules cardinalités admises sont:

cardinalités signification
0,1 Au plus un
1,1 (ou 1) Un seul
0,n (ou *) Un nombre indéterminé
1,n Au moins un
79
Une extrémité sans contrainte aura

pour cardinalité (0,n)
Client Commande
Nom Date Commande
80
Client Commande
Nom Date Commande
 Sur l’extrémité client, le 0 signifie que le client peut ne pas être reliée à la commande
lors de sa création.
 Le 1 en minimum de l’extrémité commande signifie qu’en aucun cas on ne peut créer

une occurrence de l’entité commande sans la relier en même temps à une occurrence
de l’entité client…Cette dernière doit donc avoir été créée avant !
81
 Occurrence d’une association

Une occurrence d’une association relie une seule occurrence de chacune des
entités participant à l’association
 Exemple:
 Le client 1 effectue la commande 1
 Le client 2 effectue la commande 2
 La commande 1 est effectuée par le client 1
 La commande 2 est effectuée par le client 2
Client Commande
Nom Date Commande
82
 Règles absolues!! (1)
Une association binaire de cardinalité minimale et

maximale égale à un ne peut en aucun cas porter de
propriétés !
Entité1 Entité2
N°Entité 1 (0,n) Association (1,1) N°Entité 2
Nom Entité 1 Nom Entité 2
Prénom Entité 1 Attribut Prénom Entité 2
etc etc
Faux
83
 Règles absolues!! (2)
Une association binaire ne peut en aucun cas porter

des cardinalités 1,1 des deux extrémités !
Entité1 Entité2
N°Entité 1 (1, 1) Association (1,1) N°Entité 2

Nom Entité 1 Nom Entité 2
Prénom Entité 1 Prénom Entité 2
etc etc
Faux
84
 Les associations plurielles
Deux mêmes entités peuvent être plusieurs fois en associations
Personne Livre
(0,n) Être l’auteur (1,n)
Nom Titre
Prénom Editeur
Adresse (0,n) Avoir critiqué (0,n)
85
 Les associations réflexives
Une association réflexive est une association reliant des

occurrences de la même entité
Parent
Personne
(0,n) Être parent
N°
Nom
Prénom Enfant
Adresse
(1,n)
86
 Les associations ternaires
Une association ternaire est une association qui décrit un

lien sémantique entre trois entités
A (0,n) (0,n)
Association B
idA
idB
(0,n)
C
idC
87
Créneau horaire Salle

(0,n) Projeter (1,n)
N° Créneau N° Salle
Date Capacité
Heure de début
(0,n)
Film
N° Film
Titre
Durée
88
 Les associations ternaires: décomposition
 On remplace l’association ternaire (ou n-aire) par une entité et on lui attribut
un identifiant
 On crée des associations binaires entre la nouvelle entité et toutes les

autres entités de la collection de l’ancienne association
 La cardinalité de chacune des associations binaires crées est 1,1 du côté

des entités créé et 0,n ou 1,n du côté des entités de la collection de
l’ancienne association
89

Créneau horaire Salle
N°créneau N°Salle
0,n 1,n Capacité
Date
H de début Projeter
0,n
Créneau h
Film Projection 1,1 Avoir lieu 0,n
dans N°créneau
N°Film N°projection
Titre Date
Tarif
Durée Heure de début
1,1
Salle
Concerner Film
N°Salle
Capacité N°Film
0,n Titre
Durée
90
Contraintes intra-relations (CIF)
 Relation binaire
Une voiture n’appartient qu’à une personne
Voiture Personne
(1,1) Appartenir (0,n)
Immatriculation CIN
Modèle
Soit voiture personne

Une contrainte d’intégrité fonctionnelle (CIF) se définit par le fait que l’une
des entité participant à l’association est complétement déterminée par la
connaissance d’une ou plusieurs autres entités participant dans cette même
association
Représentation
Voiture flèche Personne

(..,1) Appartenir
91
 CIF sur une relation binaire

 Représentation graphique des CIF
 Exprime qu’à partir d’une occurrence d’une entité, lui correspond (au plus)
une seule occurrence de l’autre entité
- La cardinalité maximum = 1
- Et l’existence d’une dépendance. Ces relations seront couramment appelées
relations binaires fonctionnelles
92

 Exemple
- 1 membre du personnel est affecté à 1 seul établissement (affecter ne renvoie

qu’une valeur)
- La flèche traduit ici une dépendance de Personnel envers Etablissement
- La flèche n’indique donc pas un sens de lecture mais le sens de la dépendance
93

 Exclusivité de participation d’une entité à plusieurs relations:
– Exemple:
– un article peut être acheté chez des fournisseurs ou approvisionné par des
UNITES; il ne peut être à la fois acheté et approvisionné
– Par rapport à ARTICLE, acheter et approvisionner sont mutuellement exclusives
94

 Totalité de participation d’une entité à plusieurs relations (ou inclusif):
– Exemple:
Tout VEHICULE est au minimum relié soit à un CONTRAT par relation COUVRIR,
soit à un SINISTRE par la relation IMPLIQUER, soit les deux:
95

 Simultanéité de participation d’une entité à plusieurs relations (ET logique):
– Exemple:
une commande portant sur des ARTICLEs est obligatoirement passée par un client et
réciproquement
96

 Inclusion de participation d’une entité à plusieurs relations:
– Exemple:
Une personne qui effectue un PRÊT doit avoir souscrit un ABONNEMENT
Par rapport à l’entité PERSONNE, la relation EFFECTUER est

incluse dans la relation SOUSCRIRE
97

 Contraintes d’inclusion de relations sur d’autres relations:
– Exemple:
Tout professeur qui enseigne une matière à une classe donnée, est qualifié pour
cette matière. On a ici une contrainte d’inclusion de la relation ENSEIGNER sur la
relation QUALIFIER, que l’on modélisera de la façon suivante:
Par rapport aux entités MATIERE et PROFESSEUR, la relation

ENSEIGNER est incluse dans la relation QUALIFIER
98
– A retenir
99
 CIF sur une relation n-aire

 CIF n’englobant pas la totalité de la collection:
– Un cours ne peut pas avoir lieu que dans une seule salle
– Courssalle
– L’enseignant n’étant pas compris dans cette contrainte peut faire plusieurs cours
dans la même salle
– 2 cours dans 2 salle différentes
– Mais dans tous les cas 1 seule salle pour 1 cours
100
 CIF sur une relation n-aire (décomposition)

 CIF n’englobant pas la totalité de la collection:
– L’affectation de la salle est indépendante de l’enseignant
– On peut décomposer « faire cours » en « assurer le cours » et « trouver une
salle » pour le cours
101
 Décomposition par dépendance fonctionnelle

 Avant décomposition
DF: chaque ENTREPRISE n’effectue qu’un TYPE DE TRAVAUX
 Après décomposition
102
 Décomposition par cardinalité 1,1

 Une cardinalité maximale de 1 dans une relation implique, par définition, des
dépendances fonctionnelles
103
 Décomposition par cardinalité 0,1

 Dans le cas d’une cardinalité (0,1), nécessité de rajouter une contrainte de

simultanéité
104
Conceptuel de données (MCD)
- Types et sous types: spécialisation/généralisation
 L’héritage
 S’impose dans 2 cas :

 Spécialisation : permet de modéliser dans l'ensemble des occurrences
d'une entité, des sous-ensembles (appelées entités sous-types) présentant
des spécificités.
 Généralisation : ayant identifié 2 entités fortement similaires on crée une
entité qui factorise les propriétés communes.
Entité générique
Liste des propriétés
communes
Entité spécifique
Liste des propriétés
spécifiques
105
Modèle Conceptuel de données (MCD)
 Spécialisation simple
 Permet de modéliser, dans l’ensemble des occurrences d’une entité, des
sous-ensembles d’occurrences présentant des spécificités
 Ces spécificités peuvent porter sur des propriétés, des relations ou des
appellations
 L’entité sous-type hérite de toutes les propriétés de l’entité sur-type y
compris de son identifiant
 Spécialisation simple (exemple)

 Un assuré peut être une entreprise, un particulier ou les deux
 On distingue trois entités : ASSURE, ENTREPRISE, PARTICULIER
 Un assuré a les propriétés N°assuré, Nom, Adresses, CP, Ville et Téléphone
 Un assuré particulier a en plus une profession et une classe d’âge
 Une entreprise a un N°SIREN et une forme juridique.
107
 Contraintes sur spécialisation
 Expriment les participations des occurrences de l’entité sur-type aux entités

sous-types
 Types de contraintes :
 Pas de contraintes
 Exclusivité
 Totalité
 Partition
108

 Pas de contraintes, un assuré peut être particulier, entreprise, ni particulier
ni entreprise, ou encore les deux à la fois
 X : Exclusivité, un assuré peut être soit entreprise, soit particulier, soit ni

entreprise ni particulier mais pas les deux à la fois
 T : Totalité, tout assuré est un particulier, une entreprise, ou les deux
109
 XT : Partition, tout assuré est soit entreprise, soit particulier
 Exemple
110
 Exemple
111
 Spécialisation sur types multiples
 Notion proche de la notion de l’héritage, permet d’exprimer la situation

suivante
 Représentation graphique
112
- Types et sous types: spécialisation/généralisation Modèle
 Généralisation
 Les entités sous-types préexistent
 Leur identification est indépendante de celle de l'entité sur-type
 Généralisation= mise en facteurs communs de propriétés
 Processus de perception qui va du particulier au général
113
- Types et sous types: spécialisation/généralisation Modèle
 Restriction et sous types d’associations
 Concernent la restriction de relations à des sous-types d’entités
 Exemple :
 on dispose de trois entités : EMPLOYE, CHEF_PROJET, et PROJET
 CHEF_PROJET étant un sous-type de EMPLOYE.
 A l’entité PROJET, peuvent être affectés des EMPLOYES (via une association travailler)
 Plusieurs employés peuvent travailler sur un même projet, mais à un projet est affecté un
seul chef de projet
 pour l’entité CHEF_PROJET, il y a une modification des cardinalités de l’association
travailler.
 Un projet est gérée par un seul CHEF_PROJET, l’association gérer est une spécialisation de
l’association travailler
114
Entités A retenir….
Règle 1 Toute entité présente dans un MCD doit obligatoirement comporter un

identifiant
Règle 2 Pour chaque occurrence d’une entité, chaque attribut ne peut prendre
qu’une valeur
Règle 3 Un attribut ne peut en aucun cas être partagé par plusieurs entités/associations
Règle 4 Un attribut est une donnée élémentaire, ce qui exclut des données calculées ou
dérivées
Règle 5 Deux occurrences de l’entité ne pourraient avoir la même valeur pour leur
identifiant
115
Associations
A retenir….
Règle 6 Un attribut peut être placé dans une association uniquement lorsqu’il dépend
de toutes les entités liées par l’association
Règle 7 La concaténation des identifiants des entités liés à une association constitue
l’identifiant de cette association (cet identifiant n’est pas mentionné sur le
modèle (il est implicite).
Règle 8 L’expression de la cardinalité est obligatoire pour chaque patte d’une

association
Règle 9 Une cardinalité minimal est toujours 0 ou 1 est une cardinalité maximale est
toujours 1 ou n
Règle 10 Une association binaire de cardinalité (1,1) ne peut en aucun cas porter de
propriétés !
Règle 11 Une association binaire ne peut en aucun cas porter des cardinalités 1,1 des
deux extrémités !
116
 Règles portant sur les noms
Dans un modèle entités-associations, le nom d’une entité, d’une

association, ou d’un attribut doit être unique
Enseignant Etudiant Personne
N° Enseignant N° Etudiant Fusionner N° Personne

Nom Nom Nom
Prénom Prénom Prénom
Client Facture
N° client Correspondre N° Facture
0,n 0,n
Nom Date
Prénom Adresse de facturation
Adresse de facturation
117
 Règles de normalisation des attributs

un attribut multiple doit être remplacé par une association et une entité
supplémentaires
Employé Adresse
1,n N°adresse
N° Employé
Nom Code postal
Employé Habiter Ville
Prénom Normaliser
Adresse principale
N°Employé 1,n
Adresse secondaire
Nom
N° tél domicile principale
Prénom
N° tél domicile
secondaire 1,n
N° portable Num tél
Posséder
N°num tél
1,n
type
118
 Règles de normalisation des attributs
Un attribut est une donnée élémentaire, ce qui exclut des données

calculées ou dérivées
Commande Article
N° commande 0,n Contenir 0,n N° Article

Date Quantité Désignation
Montant total Prix unitaire
119
 Règles de fusion/ suppression entités/associations
Il faut factoriser les entités quand c’est possible
Généraliste Dentiste Ophtalmologue
N°généraliste N°dentiste N°Ophtalmologue

Nom Nom Nom
Prénom Prénom Prénom
Adresse Adresse Adresse
Médecin
N°médecin
Nom
Prénom
Adresse
Spécialité 120

Il faut factoriser les entités quand c’est possible, mais l’introduction
d’un attribut supplémentaire n’est pas toujours nécessaire
Ecrivain
Ecrire
N°Ecrivain 0,n Ecrire
Nom
Prénom 0,n 0,n
Adresse
Personne Livre
Abonné 0,n N°Personne N°Livre

Nom Titre
0,n
Livre Prénom Editeur
N°Ecrivain
Emprunter Adresse
Nom N°Livre
0,n
Prénom 0,n 0,n
Titre
Adresse Editeur Emprunter
121

Il faut factoriser les associations quand c’est possible
Joueur de Tennis Joueur de Tennis

N°joueur
Nom N°joueur
0,n Prénom 0,n Nom
Genre Prénom
Classement Genre
Classement
0,n
0,n 0,n
Jouer
Jouer en tant Jouer en tant Jouer en tant Jouer en tant Type
que joueur 1 que joueur 2 que coéquipier que coéquipier
1 2
1,1 0,1 1,n
Match de Tennis
Match de Tennis
N°Match
1,1 0,1
N°Match Type
Type
122

Il faut aussi se poser la question de l’intérêt de l’association quand les
cardinalités maximale sont toutes de 1
Fournisseur
N°fournisseur
Nom 1,1
Prénom
Adresse Fournisseur
Travailler chez Fusionner N°fournisseur

Nom
Prénom
Contact Adresse
Nom contact
N°contact
1,1 N°tél contact
Nom contact
N°tél contact
123
 Spécialisation: Exemple
• La bibliothèque universitaire offre à ses adhérents la possibilité d’emprunter
des livres, des périodiques, etc
• Les adhérents de la BU sont soit des étudiants, soit des enseignants. Tous
les adhérents ont un numéro, un nom, un prénom, une adresse et un
numéro de téléphone
• Un adhérent enseignant a en plus la structure à laquelle il appartient (un
laboratoire, un département, etc), l’adresse de son bureau et enfin le
numéro de téléphone de son bureau. Un adhérent étudiant a une filière et
une année d’études
• Tous les documents de la bibliothèque ont un numéro, un titre et un éditeur.
Les livres ont comme propriétés supplémentaires le nom de l’auteur et le
nombre de pages
• Les dictionnaires sont comme propriétés supplémentaires le nombre de
définitions. Les périodiques ont comme propriétés supplémentaires le
nombre total d’auteurs
• Les thésards peuvent être à la fois étudiants et enseignants.
• Modélisez !!
124
Niveau conceptuel
Modèle Conceptuel de Communication (MCC)

Modèle conceptuel de communication (MCC)
 Représente, au niveau conceptuel, les échanges d’information entre

les acteurs
 Première étape d’une étude de l’existant, pour modéliser les habitudes de
travail dans l’organisation concernée :
 Délimiter le domaine étudié ;
 Réduire la complexité en identifiant des sous problèmes traités individuellement ;
 Identifier les acteurs externes et internes ;
 Modéliser les échanges d’informations entre les différents acteurs.
126
 Organisation: Etape 1
– 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).
127
 Organisation: Etape 2
– 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.
128
 Acteur
– Représenté par un cercle libellé par le nom de l’acteur
– L’acteur représente une unité active intervenant dans le fonctionnement

d’un système opérant. Il peut :
• Etre stimulé par des flux d’information ;
• Transformer et émettre des flux d’information
– Un acteur « fait quelque chose », il est actif

• Ex : Service comptabilité, Guichet ...
– Un acteur est un rôle plutôt qu’une personne physique (« Direction » et

pas « Jean-Claude »)
• Il peut être pertinent de modéliser séparément deux fonctions assumées par
une même personne physique.
– On distingue les acteurs internes et externes.
129
 Acteurs internes
– Acteurs faisant partie du système d’information étudié.
– Exemple : guichet, service informatique...
– Si le système est complexe, on peut considérer un acteur interne comme

un sous domaine et détailler ce sous-domaine dans un nouveau MCC.
130
 Acteurs externes
– Eléments externes avec lesquels le système échange des flux

d’information.
– Exemple : client, fournisseur…
131
 Flux d’information
– Représenté par une flèche entre deux acteurs, étiquetée par le nom du
flux.
– Echange d’informations entre deux acteurs.
– Exemple : documents, appels téléphoniques, données informatiques…
132
 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 port 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.
133
 Diagramme conceptuel de communication

– Ce diagramme (appelé aussi modèle conceptuel de flux) permet de
compléter le diagramme de contexte en décomposant l'organisation en
une série d'acteurs internes.
– Les acteurs internes sont représentés par des ellipses,
– Les messages internes sont représentés par des flèches.
134
 Exemple
– Gestion des sinistres dans une société d’assurance. A l’arrivée d’une
déclaration de sinistre, on l’examine. Si la déclaration est recevable, on
demande l’avis d’un expert, sinon on notifie le refus à l’assuré. Au retour
de l’expertise et après réception de la facture du garage, on calcul le
montant du remboursement et on envoie le chèque au client.
– Liste des acteurs : société d’assurance (int), client/assuré(ext),

expert(ext, garage(ext)
– Liste des flux : déclaration, demande, avis, facture, refus, avis expert,
chèque
135
 Exemple
136
 Exemple
 Lorsque le graphe comporte plusieurs acteurs internes on regroupes parfois
tous ces acteurs en une même entité (correspondant au SI à étudier) et on ne
garde que les flux en entrée et en sortie. C’est le graphe de flux contextuel.
137
 Exemple
 A partir du graphe contextuel on peut lister tous les événements en entrée du
système (arrivée d’un flux sur un acteur interne) et tous les événements en
sortie (départ d’un flux sur un acteur interne vers un acteur externe). C’est
important pour caractériser le domaine d’études et pour la suite de l’analyse
 Exemple:
 Evénement en entrée: arrivée d’une déclaration, d’un avis d’expert, d’une

facture garage
 Evénement en sortie: production d’un refus, d’un chèque, d’une demande

d’avis
138
 Remarques
 On ne s’intéresse ni à l’ordonnancement des flux ni aux activités des acteurs.
On fait abstraction de ces « détails »(pour le moment!)
 Les flux entre acteurs externes sont ignorés
 On se limite aux flux informationnels en ignorant les flux matériels . (ex. dépôt
du véhicule)
 Les flux sont point à point. Un document transmis à 2 destinataires donne 2

flux
 Entre deux acteurs, il peut y avoir plusieurs flux dans le même sens s’ils sont
non simultanés, s’ils sont simultanés
 Un autre domaine du SI est considéré comme un acteur externe

(interne/externe est relatif au domaine d’étude)
139
Niveau conceptuel
Modèle Conceptuel de Traitement (MCT)

Modèle conceptuel de Traitement (MCT)
 Décrit le fonctionnement du SI d’une organisation au niveau conceptuel: on fait

abstraction des contraintes d’organisation et techniques; on ne décrit que les
règles fondamentales de gestion (les invariants, « le métier » de
l’organisation). Description la plus stable
 Exemple
 Les demandes d’ouverture du compte bancaire doivent suivre les règles de gestion
suivantes:
 Règle1: Toute demande d’ouverture de compte doit faire l’objet d’un examen
préalable
 Règle 2: L’accord définitif d’ouverture ne peut être donné qu’après avis de la

banque de France
141
 Exemple
Ce découpage est une règle de gestion et pas un simple choix

d’organisation de travail
142
 Les concepts du MCT
 Le fonctionnement du SI est décrit par l’enchainement d’opérations:
 Déclenchées selon certaines conditions de synchronisation (et, ou, …)
 Portant sur des événements contributifs (internes ou externes)
 Et produisant d’autres événements résultats (internes ou externes)
143
 Notation graphique
Les acteurs sont facultatifs

144
 Evénement contributif externe
 C’est un stimulis pour le SI qui provoque une réaction. Il doit être détectable
par le SI
 C’est un message c’est-à-dire un ensemble de données qui sont associés à

un nouveau fait
 Opération
 Suite d’actions sans attente d’événement extérieur (« non interruptible »)
 Déclenchée par un ou plusieurs événements contributifs internes ou externes
 Produit des événements résultats internes ou externes, conditionnées par des

règles d’émission
145
 Les actions sont constituées:
 Des traitements appliqués aux données en entrée selon certaines règles
 Des tâches de consultation et de mise à jour d’une base d’informations

accessible.
 Synchronisation
 Condition exprimée sur les événements contributifs, qui détermine le

déclenchement d’une opération.
 S’exprime sous la forme d’une proposition logique utilisant des « et » et des

« ou « (on évitera un maximum le « non », les non-événements n’étant pas
toujours détectables par le SI)
 Exemple: a ou (b et c)
146
 Règles d’émission
 Elle caractérisent les résultats possibles de l’opération
 Ex.
 Les conditions d’émission des résultats d’une opération ne sont pas

nécessairement exclusives (un résultat peut être émis par deux règles
d’émission distinctes)
 Les conditions d’émission portent souvent sur des cas d’anomalies (ex: une
rupture de stock)
147
 Types d’événement
 Evénement contributifs externes: proviennent de l’univers extérieur, sont

traités par une opération conceptuelle (ex. arrivée d’un flux d’entrée, date de
déclenchement)
 Evénements contributifs internes: générés par une opération conceptuelle,

contribuent au déclenchement d’une autre opération (état intermédiaire du SI
ou état d’attente)
 Evénements résultats: générés par une opération conceptuelle et destinés à

l’univers extérieur (résultats externes) ou à d’autres opérations (résultats
internes)
148
 Construction du MCT
 Jeton=occurrence d’événement
 Quand la synchro devient vraie l’opération est exécutée. Un jeton et retiré de

chaque entrée qui rend vraie la proposition et ajouté sur les sorties choisie (s)
 On peut indiquer un nombre de jetons>1 à retirer ou à ajouter entre () à côté

des arcs
Réfléchir en ces termes aide à construire des modèles « propres »

149
 Construction du MCT
 Etape 1: Lister les acteurs et les flux
 Etape 2: Etablir le graphe des flux (complet et contextuel)
 Etape 3: A partir du graphe des flux, établir la liste de tous les événements en
entrée et en sortie du SI
 Etape 4: construire le MCT
 Tout événement en entrée se retrouve en entrée d’une opération; il existe

d’autres événements en entrée (ex: des dates conceptuelles)
 Tout événement en sortie est produit par une opération
 Le découpage en opérations est guidé par les règles de gestion
150
 Exemple: Facturation
151
 Exemple: Gestion des sinistres
152
 Des schémas de base (1)
153
 Des schémas de base (2)
154
 Des erreurs de modélisation classiques

 Règles d’émission : elles doivent
– Etre mutuellement exclusives : deux règles de la même opération ne peuvent pas
être vraies en même temps ;
– Couvrir tous les cas possibles.
 Ne pas répéter les actions et les événements résultants ;
 Problèmes de synchronisation
– Il faut simplifier les synchronisations.
 Problèmes structurel
– Il faut éviter les chaînes d’opérations et les événements internes.
155
 Des erreurs classiques
Les conclusions sont déjà dans les hypothèses. La condition

d’émission doit décrire les résultats possibles du traitement des
entrées
156

 Dans un magasin, on encaisse le montant dû par le client lors de son passage
en caisse. Pour certains gros clients dits « clients en compte », le paiement
est différé. Le caissier envoie un avis de débit au service comptable
Contradiction entre événement

d’entrée et condition de sortie
157

 Si le propriétaire du véhicule est connu, son accord pour la destruction est
nécessaire, sinon on peut s’en passer
Synchronisation logiquement incorrecte
158
Niveau logique
Niveau logique
Modèle Logique de Données (MLD)

1. Terminologie
2. Schéma relationnel d’une BD
3. Règles d’intégrité structurelle
4. Dépendances fonctionnelles
5. Normalisation
Modèle logique de données (MLD)
 Le Modèle Logique des Données (MLD) est une étape intermédiaire

pour passer du modèle E/A, qui est un modèle sémantique, vers une
représentation physique des données : fichiers, SGBD hiérarchique,
SGBD réseau, SGBD relationnel.
 Nous nous limitons au seul MLD relationnel, qui prépare le passage

aux SGBD relationnels.
-Terminologie
 Tables
 Lorsque les données ont la même structure (par ex. renseignement
relatifs à un client), on peut alors les organiser en tables dans
lesquelles:
– Les colonnes décrivent les champs en commun
– Les lignes contiennent les valeurs de ces champs pour chaque enregistrement
 Exemple
N° Client Nom Prénom Adresse

1 Durand Marie 2, rue la Paix
2 Motte Pierre 7, rue Cler
… … … …
-Terminologie
 Tables, lignes, colonnes

Relation
Considérant N ensembles E1, E2,…En. Tout sous-ensemble du produit cartésien des N

ensembles, noté E1 X E2 X…X En, constitue une relation
 Une table est une relation comportant des lignes (tuples) et des
colonnes
 Exemple:
 E1  a, b et E2  c, d  , sont deux ensembles
 le produit cartésien est: E1  E2  (a, c), (a, d ), (b, c), (b, d )
 l’ensemble R1  (a, c), (a, d ) est un sous ensemble de E1  E2 il
constitue une relation.
E1 E2 R1
 Les éléments de la relation sont appelés des tuples.
a c
a d
b c
b d
-Terminologie
 Attribut, et domaine
Attribut
Colonne d’une relation caractérisée par un nom
Domaine
Ensemble des valeurs admises pour un attribut. Il établit les valeurs

acceptables dans une colonne
 Exemple :
– Domaine= {Entier, réel, booléen, caractère}
-Terminologie
 clef primaire
 Les lignes d’une table sont uniqueil existe au moins une colonne
qui sert à identifier les lignes: il s’agit de la clef primaire de la table
 Les propriétés et conventions requises

– La valeur vide (NULL) est interdite
– La valeur de la clef primaire d’une ligne ne devrait pas changer au cours du
temps
– On souligne les clefs primaire dans un MLD
-Terminologie
 clef primaire
clef primaire
Ensemble minimal de colonnes qui permet d’identifier de manière unique chaque

tuple dans une table (primary key)
 une clef primaire est simple si elle est composée d’une seule
colonne
 Une clef primaire composée peut être constituée de deux colonnes

ou plus
 Exemple
– Client (N°, Nom, prénom, adresse)
– Appartement( N°, adresse, superficie)
-Terminologie
 clef étrangère
clef étrangère
une ou plusieurs colonnes dans une table qui a pour but d’assurer une liaison
entre deux tables. La clef primaire de la première table est dupliquer dans la
deuxième. On l’appelle aussi clef externe (Foreign key)
 Convention:
– On fait précéder par # la clef étrangère
 Exemple
Clients Commandes
N° client N° commande
Nom client Date commande
Prénom client # N° client
Adresse client
-Terminologie
 Tables, lignes, colonnes, attribut, et domaine
Modèle relationnel Modèle conceptuel

Table/relation Entité
Ligne/tuple Occurrence d’entité
Nom de colonne Attribut d’entité

clef primaire/ étrangère identifiant
-Terminologie
Remarques
Rq1: Une même table peut avoir plusieurs clefs étrangères mais une
seule clef primaire(éventuellement composée de plusieurs
colonnes)
Rq2: Une clef étrangère peut aussi être primaire (dans la même table)
Rq3: Une clef étrangère peut être composée (c’est le cas si la clef
primaire référencée est composée)
Rq4: Implicitement chaque colonne qui compose une clef primaire ne

peut pas recevoir la valeur NULL
Rq5: Si une clef étrangère ne doit pas recevoir la valeur NULL, alors il
faut le préciser dans la description des colonnes
-Schéma relationnel d’une BD
 Schéma relationnel
– Les tables sont appelées relations
– Les liens entre les clefs étrangères et leur clefs primaires sont symbolisés par un
connecteur
 Entité
Règle
Toute entité (dans un MCD) devient une table (dans un MRD) dans laquelle les
attributs deviennent les colonnes et l’identifiant de l’entité constitue la clef primaire
de la table
Client
se traduit par
Codcli
Nomcli
Adrcli
Entité Client (codcli, nomcli, adrcli)

Table
 Association binaire 1/1- 0/1

se traduit en ajoutant une clef étrangère (identifiant de l'entité de cardinalité
(0,1) ) à la table provenant de l'entité dont la cardinalité est (1,1).
toujours un seul employé

Employé Département
numemp 0,1 1,1 nudep
nomemp
dirige nomdep
se traduit
par
Employé Département
numemp nudep
nomemp #nuemp
Employé (nuemp, nomemp) nomdep
Département (nudep, nomdep, #nuemp)
 Association binaire plusieurs à plusieurs
se traduit par une nouvelle table dont la clef primaire est composée des
identifiants des deux entités. Les éventuelles propriétés de l'association
deviennent les attributs de cette table.
Skieur Compétition
Nomski
0,n Classer 0,n
refcomp
spécialité rang datcomp
se traduit par
Classer ( #nomski, refcomp, rang)
 Association binaire un à plusieurs
Employé
Magasin
N° Employé
N°Agence
1.n Embaucher 1.1 Nom Employé
N° civique
Prénom employé
Rue
Salaire employé
Ville
Code postal
Employé
Magasin
N° Employé
N°Agence
Nom Employé
N° civique
Prénom employé
Rue
Salaire employé
Ville
Code postal #N° Agence
 Association binaire (0,1)(0,1)
Entité-association
Entreprise
Salarie
N° Entreprise
N°Salarie
(0,1) Est directeur (0,1) NomE
NomS
Adresse
Prenom
On duplique la clé d’une des tables dans l’autre

Modèle relationnel
SALARIE(N°Salarie, NomS, PrenomS,#N°Entreprise)
Ou
Entreprise(N°Entreprise, NomE, Adresse,#N°Salarie)
 Association n-aire (n>2)

on crée une table ayant pour clef primaire les identifiants des différentes
entités de l'association. Les éventuelles propriétés de l'association
deviennent les attributs de la table.
Classe
No_classe
0,n
Matière
0,n Assure 0,n Professeur
No_matiere
codsalle No_prof
se traduit par
Assure ( #no_classe, no_matiere, no_prof, codsalle)
 Association réflexive
Personne
N°matricule
Nom 0..*
Epouse Se marier
Prénom
Date mariage
0..*
Personne Se marier
N°matricule
#N° matricule 1 , #N° matricule 2
Nom
Date mariage
Prénom
 L’héritage
 L’héritage est traduit de 3 façons dans le modèle logique
E1
P1
P2
ES1 ES2
PS1 PS2
 L’héritage
 Première possibilité :
 intégration des sous-types dans la relation sur-type (les sous-types
disparaissent). Avec un tel principe les propriétés spécifiques à chacun des
sous-types ne seront pas valorisées pour certaines occurrences de la
relation sur-type.
E1
P1
P2
E1 (P1,P2, PS1, PS2)
ES1 ES2
PS1 PS2
 L’héritage
• Seconde possibilité :
• Intégration des propriétés figurant dans le sur-type dans tous les sous types
(le sur-type disparaît). Cette solution entraîne une redondance importante
des données du sur-type si il n’y a pas exclusion entre les sous-types.
E1
P1
P2
ES1 (P1, P2, PS1)
ES2 (P1, P2, PS2)
ES1 ES2
PS1 PS2
 L’héritage
• Troisième possibilité :
• Conservation de l’entité sur-type et des entités sous types. Dans chacune
des relations sous-types, l’identifiant de l’entité sur-type est intégré. Il
• est à la fois clé primaire de la relation et clé étrangère par rapport à l’entité
sur-type..
E1
P1
P2
ES1 (P1, P2, PS1)
ES2 (P1, P2, PS2)
ES1 ES2
PS1 PS2
Il est important de noter que quelque soit la solution adoptée, toute la puissance
portée par le concept d’héritage est perdue dans le modèle relationnel.
 L’héritage
• Exemple: Première possibilité
Exemple d’occurrences :
Personnel Internes
Numéro 1 - Annick Lassus (14/06/1999)
Nom 2 – Armelle Mundubeltz (20/09/2000)
Prénom Extérieur
3 – Bernadette Chaulet (CAP GEMINI)
Extérieur Interne
SSII DateEmbauche
PERSONNEL (Numéro, Nom, Prénom, SSII, DateEmbauche)
num Nom Prénom SSII DateEmbauche

1 Lassus Annick 14/06/1999
2 Chaulet Armelle 20/09/2000
3 undube Bernadette CAP GEMINI
 L’héritage
• Exemple: Seconde possibilité .
Personnel Internes
Prénom Extérieur
Extérieur Interne
SSII DateEmbauche
EXTERIEUR(Numéro, Nom, Prénom, SSII) INTERNE (Numéro, Nom, Prénom, DateEmbauche)
num Nom Prénom SSII num Nom Prénom dateEm

3 undube Bernadette CAP … 1 Lassus Annick 4/6/199
2 Mundub Armelle 2/9/2000
 L’héritage
• Exemple: Troisième possibilité
Personnel Internes
Prénom Extérieur
Extérieur Interne PERSONNEL (Numéro, Nom, Prénom)

SSII DateEmbauche num Nom Prénom
1 Lassus Annick
2 Mundub Armelle
INTERNE (Numéro#, DateEmbauche) 3 Chaulet Bernadette
num dateEm
EXTERIEUR (Numéro#, SSII)
1 4/6/199
2 2/9/2000 num SSII
3 CAP …
-Règles d’intégrité structurelles
 Les règles d’intégrité sont les règles que doivent vérifiés les données
contenues dans une base de données. Ces règles sont inhérentes au modèle
de données
 On distingue plusieurs règles structurelles correspondant au concepts:

– Entité
– Domaine
– Clef (contrainte référentielle)
Contrainte
d’entité
Contrainte imposant que toute relation possède une clef primaire et tout
attribut participant à cette clef primaire est non nul
 Valeur nulle: valeur conventionnelle introduite dans une relation pour

représenter une information inconnue ou inapplicable
Contrainte de
Domaine
Contrainte imposant que la colonne d’une relation doit comporter des valeurs
vérifiant une assertion logique
 L’ assertion logique est l’appartenance à une plage ou liste de valeurs:

 Exemple:
– Le domaine des salaires mensuels qui sont des réels compris entre 900 et 3000€
– L’âge d’une personne est compris entre 1 et 150
Contrainte référentielle (clef étrangère)
Contrainte d’intégrité portant sur une relation R1, consistant à imposer que
la valeur connue d’un groupe d’attributs apparaisse comme valeur de clef
dans une autre relation R2
Lors d'une insertion d’une valeur dans une relation, la valeur des attributs
doit exister dans la relation référencée
Exemple:
– Insertion : Commande
– Contrainte: le client correspondant doit exister
Lors d'une suppression dans la relation référencée , les tuples référençant
ne doivent pas exister
– Exemple: la suppression d’un client entrainera la vérification qu’aucun client ne
référence une commande
Clients
Commandes
N° client
Nom client N° commande
Prénom client Date commande
Adresse client # N° client
Spécialisation
 Solution 1 : Duplication des attributs du surtype dans les sous types
associés
Entité-association
Modèle relationnel
PERSONNE(n°personne,nom, age)
ETUDIANT(n°personne,niveau, nom, age)
ENSEIGNANT(n°personne, grade,nom,age)
 Respecte la logique
 Gestion des duplicatas
 Utilisation des triggers pour propager les modifications d’une entité à une autre
Spécialisation
 Solution 2 : On duplique la totalité du contenu du surtype dans les sous
types associés et on supprime les surtypes
Modèle relationnel
ETUDIANT(n°personne,niveau, nom, age)

ENSEIGNANT(n°personne, grade,nom,age)
 Simplifie la traduction
 Redondance des données
Spécialisation
 Solution 3 :
Entité-association Modèle relationnel
PERSONNE(n°personne, nom, âge)

ETUDIANT(n°personne,niveau)
ENSEIGNANT(n°personne, grade)
 Respecte la logique
 Manipulation des clés
Spécialisation
 Solution 4 : Fusion de toutes les informations et ajout d’une propriété
pour identifier le type
Modèle relationnel
 Simplifie la traduction
 Nécessite de gérer le fait que les attributs peuvent être nuls
 Solution utilisable quand les entités spécialisées ne comportent pas beaucoup
d’attribut
Généralisation
Entité-association
 Dans la généralisation les sous types ont leurs propres identifiants

Modèle relationnel
TIERS(n°tiers, raison sociale, adresse_administrative)

CLIENT(n°client, adresse Livraison, #n°tiers)
FOURNISSEUR(n°fournisseur, délai de livraison, #n°tiers)
 Création d’un clé étrangère unique dans les entités sous types
-Dépendances fonctionnelles
 Modèle relationnel de données normalisé
 Un schéma relationnel normalisé doit répondre aux exigences minimales
suivante:
– Non redondance : un attribut n’appartient qu’une seule relation
– Cohérence : les attributs qui décrivent le même objet appartiennent à la même table
et dépendent chacun fonctionnellement et totalement de la clef primaire de la table
 On mesure la qualité d’une relation par son degré de normalisation:
– La première forme normale, notée 1FN
– La deuxième forme normale notée 2FN
– La troisième forme normale, notée 3FN
– Forme normale de Boyce Codd, noté FNBC, etc
 Dépendances fonctionnelle entre deux attributs
Un attribut B dépend fonctionnellement de l’attribut A, noté AB, si à

une valeur de A correspond à une et une seule valeur pour B. On dit que
A détermine B
 Plusieurs attributs peuvent apparaitre dans la partie gauche d’une DF : {A,

B,C}D
 Plusieurs attributs peuvent apparaître dans la partie droite d’une DF. Dans
ce cas, il convient de considérer chaque DF en gardant la partie gauche et
en faisant intervenir un seul attribut dans la partie droite
 Exemple de dépendances fonctionnelles
1. (numPilote, jour)  nbHeuresVol est une DF, car à un couple (numPilote,

jour) Correspond au plus un nombre d’heures de vol
2. numPilote(nomPilote, fonction) ↔ numPilotenomPilote et numPilote
fonction, qui sont deux DF.
3. NomPilotefonction est une DF s’il n’y a pas d’homonymes dans les la BD
des pilotes.
4. fonctionnomPilote n’est pas une DF, car à une fonction donnée
correspondent éventuellement plusieurs pilotes
 Dépendances fonctionnelles élémentaires
Une DF (a,b)c est élémentaire si ni ac, ni bc ne sont des DF
 Exemples
– RefProduitLibProduit est élémentaire
– (NumFacture, RefProduit)QtéFacturé est élémentaire (ni la référence produit seule, ni
le numéro de facture seul permettent de déterminer la quantité)
– (NumFacture, RefProduit)LibProduit n’est pas élémentaire puisque la référence du
produit suffit à déterminer le libellé
 Dépendances fonctionnelles directes
Une DF ac est directe si elle n’est pas déduite par transitivité, c’est-
à-dire s’il n’existe pas de DF ab et bc
 Exemple
Considérons Les dépendances fonctionnelles (1) directe

a b
N°FactureN°Représentant et ,
N°ReprésentantNomReprésentant (3) indirecte (2) directe
 N°FactureN°Représentant est une DF directe c
N°ReprésentantNomReprésentant est une DF directe

N°FactureNomReprésentant n’est pas une DF directe
puisqu’elle obtenue par transitivité
1.3. Modèle logique de données (MLD): Dépendances fonctionnelles
 Dépendances fonctionnelles: axiomes d’Armstrong
Réflexivité
Si b est un sous-ensemble de a alors ab est une DF.

Augmentation
Si ab est une DF, alors (a, c)(b, c) est une DF.
Transitivité
Si ab et bc sont des DF, alors ac est une DF.
Union
Si ab et ac sont des DF, alors a(b, c) est une DF.
Pseudo-transitivité
Si ab et (b, c)d sont des DF, alors (a,c)d est une DF.
Décomposition
Si a(b, c) est une DF, alors ab et ac sont des DF.
 Dépendances fonctionnelles: fermeture, couverture minimale
Fermeture
La fermeture F+ d’un ensemble de DF, F est l’ensemble des DF que l’on peut
obtenir par applications successives des axiomes d’Armstrong.
 Exemple:
– AB et BC donc AC
– BC donc (B,D)(C,D) (essentiellement la transitivité et pseudo-transitivité)
Couverture minimale
Sous-ensemble minimum de DF élémentaires permettant de générer toutes les
autres.
 Autre définition
– Ensemble minimum de dépendances, équivalent à la fermeture transitive
• peut ne pas être unique
 Graphe des Dépendances fonctionnelles
 Pour chaque relation il faut recenser toutes ses DF élémentaires, on les

représente sous forme d’un graphe orienté : « Graphe minimum des DF de
la relation »
 Une relation peut avoir plusieurs graphes minimum. Ils sont alors
équivalents
Exemple de graphe minimum: Exemple de graphe non

minimum:
R( A, B, C, D, E)
E->A, E->B, E->C, E-
>D C->D
E->D est déduite de E->C et

C->D, Il faut supprimer E-
>D du graphe
 Exemple de Graphe des Dépendances fonctionnelles
 LivraisonTot (N°f, adrF, N°p, typeP, qté)
 N°fadrF : l’adresse d’un fournisseur ne dépend que du fournisseur
 N°p  typeP : le type d’un produit ne dépend que du produit
 (N°f, N°p)  qté : la quantité totale livrée dépend du produit et du fournisseur
Graphe minimum de DF de la relation LivraisonTot

 Dépendances fonctionnelles et identifiants

 Le graphe minimum des DF permet de trouver les identifiants de la relation
 L’identifiant de la relation est l’ensemble (minimal) des nœuds du graphe

minimum à partir desquels on peut atteindre tous les autres nœuds (via les
DF)
 Exemple:
 R(A, B, C, D, E) vérifiant les hypothèses: E->A, E->B, E->c, c->D
E est l’identifiant de R
 Dépendances fonctionnelles et identifiants: exemple
 R (A, B, C, D, E, F, G)
 (F, G) est l’identifiant de R

 Dépendances fonctionnelles multivaluée (DM)
Soit une relation R(X, Y, Z), il existe une dépendance multivaluée X-- >> Y, si à
toute valeur de X correspond un ensemble de valeur de Y qui est totalement
indépendant de Z
 Propriété
 S’il existe la DM X-- >>Y alors il existe aussi X-- >>Z. On note : X-- >>Y|Z
 Remarque
 DF est un cas particulier de DM
Exemple
 La relation cours (nomC, prof, livre) contient une DM : nomC-- >>Prof| livre
 Dépendances fonctionnelles multivaluée (DM) : un autre exemple
 Soit la relation Catalogue( N° Article, Taille, Couleur)
 Hypothèse: il existe toutes les tailles et toutes les couleurs pour chaque
article.
Catalogue
N° Article Taille Couleur
Du faites des hypothèses, il existe une
1 38 Noir
DM :
1 40 Noir
N°Article-- >>Taille|Couleur
1 42 Noir
1 44 Noir
Chaque article existe pour chaque taille
1 38 Bleu
et toutes les couleurs et chaque article
existe pour chaque couleur et chaque 1 40 Bleu
taille. 1 42 Bleu
1 44 Bleu
-Normalisation
 Première forme normale: 1FN
Une relation est 1FN si tous ses attributs sont atomiques (ne sont pas
décomposables)
ncomp compagni nomPilote sexe typeAvion immat nbHeures

e Vol
1 Air-France Bidal F CRJ F-CLAR 600
1 Air-France Bidal F A320 F-ROMA 345
1 Air-France Bidal F A320 F-GLDX 120
2 Quantas SanFilippo G A330 F-STEF 7500
2 Quantas SanFilippo G A330 F-GLDX 250
2 Quantas Soutou G A340 F-ABDL 2500
 Les tables relationnelles sont nativement toutes en 1FN, car les attributs de
type tableau ne sont pas autorisés au niveau de la BD
-Normalisation
 Deuxième forme normale: 2FN
Une relation est en 2FN si elle est en 1FN, et si chaque colonne qui ne fait pas
partie d’une clef primaire dépend de la clef primaire
 Autrement dit, une table est en 2FN si

– Elle est en 1FN
– Une des 3 conditions suivantes est vérifiée
• La clef primaire n’est formée que d’une seule colonne (un attribut)
• La clef primaire contient toutes les colonnes de la table
• Si la clef primaire a plus d’une colonne, une dépendance fonctionnelle ne
doit jamais exister entre une partie de la clef et une autre colonne de la table
 Exemples:
 La relation Fournisseur (NF, NomProduit, NomF, Adresse, Tel, Prix) n’est pas en
2FN. La clef primaire est (NF, NomProduit) et NomF dépend d’une partie de la clef
(NFNomF)
-Normalisation
 Comment normaliser 2FN?

 Pour passer de la 1FN à la 2FN, il faut diviser chaque table ne satisfaisant
pas les critères en deux tables distinctes :
– Créer une nouvelle table ayant pour clef la partie de la clef primaire dont dépend
le ou les attributs, ainsi que ces attributs eux-mêmes.
– Éliminer ces attributs (ceux qui ne font pas partie de la clef) de la table originale
Exemple
– TÉLÉVISION (Marque, Modèle, ModeSon, Résolution)
– Il y a donc une DF entre "Modèle" et "ModeSon", ainsi qu’entre "Modèle" et
"Résolution"
– Il faudra donc diviser cette table en deux de la façon suivante :
– TÉLÉVISION (Marque, Modèle)
– MODÈLETV (Modèle, ModeSon, Résolution)
-Normalisation
 Comment normaliser 2FN? (un autre exemple)
 Soit la relation LivraisonTot (N°f, N°p, adrF, typeP, qté)

 Le graphe minimum correspondant :
 La relation n’est donc pas en 2FN (N°f->adrF && N°p->typeP)

 Il faudra diviser la table en 3 tables
 R1(N°f, adrF)
 R2(N°p, typeP)
 R3( N°f, N°p, qté)
-Normalisation
 Troisième forme normale: 3FN
Une relation est en 3FN si elle respecte la deuxième forme normale et si les
DF entre la clef primaire et les autres colonnes sont directes
 Autrement dit, une table est en 3FN si

– Elle est en 2FN
– Aucune colonne ne faisant pas partie de la clef primaire ne dépend d’une autre
colonne ne faisant pas partie non plus de la clef primaire
• Les dépendances fonctionnelles entre deux colonnes ordinaires (ne faisant pas
partie de la clef) sont interdites
B, C OK A, B, C
-Normalisation
 Comment normaliser 3FN?
 Pour passer de 2FN à 3FN, il faut
– Diviser chaque table ne satisfaisant pas ce critère en deux tables. La nouvelle
table aura comme clef la colonne dont provient la dépendance et comme
colonnes, celles qui en dépendent.
– Éliminer les colonnes dépendants de la table originale. La clef de la nouvelle

table demeure dans l’ancienne en tant que clef étrangère
Exemple
VOITURE (NV, marque, type, puissance, couleur)
 Cette table n’est pas en 3FN car Typemarque, puissance. Il faut donc
décomposer cette table en deux.
– VOITURE (NV, type, couleur)
– Modèle(Type, Marque, puissance)

-Normalisation
 Comment normaliser 3FN? (un autre exemple)
 Soit la relation Fournisseur(N°fourn, ville, pays)

 Le graphe minimum correspondant
 La relation Fournisseur n’est pas en 3FN

car ville->pays
3F
N
 La relation doit être décomposée en
 F(N°fourn, ville)
 G(ville, pays)
1.3. Modèle logique de données (MLD): Normalisation
 Forme normale de Boyce-Codd (FNBC)

Une relation est en FNBC si :
- elle est en 1FN, et
- si toutes les sources complètes de DF (la partie gauche de la DF) sont
identifiants (candidats)
 Ou alors,
 une relation est FNBC si
 elle est FN3,
 aucun attribut, ne dépend d’un attribut non clef
R(A, B, C)
-Normalisation
 Forme normale de Boyce-Codd (FNBC) (Définition 2)
une relation est en forme normale de Boyce-Codd si les seules sources de

dépendances fonctionnelles sont les clés candidates.
 Ceci implique que,

 la relation est en troisième forme normale mais une relation peut être en
troisième forme normale sans être dans la forme normale de Boyce-
Codd.
Ceci peut arriver

 que si deux clés candidates se chevauchent (ont en commun une ou
plusieurs attributs) et qu'une partie d'une des clés candidates dépend
d'un attribut qui appartient à l'autre clé candidate.
-Normalisation

 Exemple1
– Soit la relation R (N°_F , Produit, Adresse_F, Prix), avec comme
ensemble de dépendances fonctionnelles
• DF1 : N°_F  Adresse_F ;
• DF2 : (N°_F ,Produit ) Prix.
Cette relation n'est pas en FNBC, car dans la DF1, la partie

gauche N°_F n'est pas une clef entière.
– Le relation peut être décomposé en deux tables:

La décomposition est sans perte de
• R1( N°_F , Adresse_F ) dépendance fonctionnelle et sans perte
• R2( N°_F, Produit, Prix) d’information.
-Normalisation
 Exemple2
Considérons la relation suivante: Cours (Matiere, Classe, Professeur)
o complétée par les règles de gestion suivantes:

• un professeur n'enseigne qu'une seule matière,
• une classe n'a qu'un seul enseignant par matière
o desquelles on déduit les DF suivantes:

 DF1: Matière, Classe  Professeur
 DF2: Professeur  Matière
Cette relation est en 3NF, mais pas en FNBC à cause de la DF2
Cours (Matiere, Classe, Professeur)

-Normalisation
 Exemple2 : suite
 On pourrait alors décomposer la table (Matiere, Classe, Professeur) en 2

tables:
 Spécialité (Professeur, Matière)
 Enseignant (Classe, Professeur)
 Remarque : la première DF (DF1: Matière, Classe  Professeur) est perdue.

-Normalisation
 Exemple3: forme de Boyce Codd
 Soit la relation Place( N°Etudiant, Matière, Rang) vérifiant les

hypothèses suivantes:
 DF1: (N°étudiant, Matière)Rang
 DF2: (Matière, Rang)N°Etudiant
 2 identifiants candidats (N°étudiant, Matière) ou (Matière, Rang)
 Place est en 3FN, et en FNBC.

-Normalisation
 Algorithmes de décomposition des DFs

 Plusieurs algorithmes pour décomposer selon les DF
 Algorithme 1 (d'après Heath)
 R (A1, A2, A3, … An)
 Tant qu'il existe une DF élémentaire non déduite faire :
 Soit Ai  Aj la DF
 Soient Ak,… Al les autres attributs qui dépendent directement de Ai :
Ai  (Aj, Ak, …Al)
 Remplacer R par
 R1 (Ai, Aj, Ak, … Al)
 R2 (Ai, attributs de R autres que Aj, Ak, …Al)
 Recommencer l'algorithme pour R1 et R2

-Normalisation

 Algorithme 1 : exemple R( F, G, A, B, C, D, E, H)
 Avantage
– relations en FNBC
 Inconvénients
– dépend de l'ordre selon lequel les DF sont traitées
– peut perdre des DF
– peut trop décomposer
-Normalisation

 Algorithme 2 (à partir des sources de DF)
 R (A1, A2, A3, … An)
 Tant qu'il existe une source de DF élémentaire non déduite faire :

 Choisir si possible une source dont toutes les cibles sont des extrémités
terminales du graphe
 Soient Ai la source et Ai(Aj, Ak,… Al) les DF
 Créer la relation Ri (Ai, Aj, Ak, … Al)
 Supprimer les attributs Aj, Ak, …Al de R
 Si aucune des relations Ri ne contient un identifiant de R alors ajouter la

relation : R0 (un identifiant de R)
-Normalisation

 Algorithme 2 : exemple R( F, G, A, B, C, D, E, H)
 Avantages
– relations en FN3
– ne perd pas de DF
– ne perd pas d'information
 Inconvénient
– peut trop décomposer
-Normalisation
 La 4ème forme normale (4FN)
La 4FN permet de séparer des faits multivalués indépendants qui auraient été
réunis dans une même relation
 Définition : R est en 4FN si :

– elle est en 1ère FN, et
– si toute DF ou DM de R a pour source un identifiant entier de R
 Remarque : 4FN implique FNBC
 Autre définition : R est en 4FN si elle est en FNBC et ne contient pas

de DM
-Normalisation
 Décomposition de la 4ème forme normale (4FN)
 Théorème de Heath n°2

 Si R(X, Y, Z) contient la DM X-->>Y|Z
 alors R est décomposée en :
 R1 = p[X,Y]R et
 R2 = p[X,Z]R
 (la décomposition est sans perte d'information).
 Exemple : Cours (nomC, prof, livre) est décomposé en :
– CoursProf (nomC, prof) 4FN

– CoursLivre (nomC, livre) 4FN
Le niveau organisationnel
Le niveau organisationnel
 Modèle Organisationnel de Données (MOD)
 Modèle Organisationnel de Traitement (MOT)
Modèle organisationnel de données (MOD)
 La modélisation organisationnelle des données prend en compte des

éléments relevant de l’utilisation des ressources de mémorisation :
 Choix des informations à mémoriser informatiquement.
 Quantification des informations à mémoriser (volume et durée de vie).
 Répartition des données informatisée entre unités opérationnelles

 Choix des informations à mémoriser

 Il s’agit de distinguer, à partir des informations formalisées sur le MCD,
celles qui devront être mémorisées informatiquement dans le système
d’information informatisé (SII).
 Exemple
 soit une entreprise de livraison constituée d'un siège social, d'un entrepôt
et d'agences. Le siège qui s'occupe de tous les clients et de toutes les
factures aura le modèle général comme vue externe.
MOD siège
 Exemple (suite)
 L'entrepôt ne s'occupe que de la livraison à partir des ventes et possède
un modèle sans contrat ni facture.
MOD site 1 Entrepôt

 Exemple (suite)
 Une agence n'effectue que les livraisons et les factures et a un modèle
sans contrat.
MOD site 2 Agence

 Un site comprendra le modèle commande et facture et l'autre le modèle
commande et livraison. L'organisation des données n'est pas par sous-
ensembles cohérents du modèle principal tels que modèle contrat,
modèle facture ou modèle livraison. Le découpage organisationnel est
réalisé à partir des individus basés sur un site précis
 Quantification des information à mémoriser

 La quantification prend en compte deux notions :
 Le volume : taille et nombre de chaque élément.
 La durée de vie : statistiques sur le nombre minimum, maximum et

moyen d’occurrences concrètes pour chaque entité et chaque
association. Par exemple on remplacera la cardinalité 1,n par 1,50 si on
estime que la valeur maximum ne dépassera pas 50 ou bien donner une
cardinalité moyenne.
 Répartition des données informatisées

 On va analyser au niveau du MOD la répartition concrète des données
entre les unités opérationnelles de l’entreprise. Dans le cas des données
non informatisées, il faudra préciser leur localisation. Dans le cas des
données informatisées, on va préciser les droits des différents utilisateurs
(les acteurs du MOT). Ces droits peuvent être :
 Lecture
 Écriture
 Création
 Suppression
Chacun de ces droits s’appliquant aux entités, aux attributs, aux

associations et à leurs occurrences.
Modèle organisationnel de traitement (MOT)
 Point de départ
 Les règles de gestion définies dans le nouveau MCT

 Les nouvelles règles d’organisation: Qui?
 Quel poste de travail assure le traitement
 Contraintes de temps dues à l’organisation Quand?
 Traitement manuel ou automatisé Comment?
 Procédure
 Chaque opération conceptuelle du MCT est décomposée en un
ensemble de phases
 Phase
 Ensemble de tâches dont l’enchainement est « non interruptible »

compte tenu de l’organisation mise en place. Toutes les tâches d’une
phase se déroulement:
 Sur un même poste de travail (unité de lieu)
 À un moment déterminé(unité de temps)
 Avec des moyens homogènes – manuel / automatique (unité d’action)
 Exemple
 Chaque jour à 16h le secrétariat exécute la phase saisie du dossier
de candidature
 Liste des tâches: 1) saisie des données, 2) m.à.j du fichier
informatique ‘candidatures’, 3) classement du dossier papier
 Le poste de travail est caractérisé par :
 Une fonction à assurer (gestion des stocks….)
 Un lieu géographique
 Un ensemble de moyens/ressources (personnel, matériel)
 La nature du traitement
 Manuel
 Conversationnel (traitement unitaire immédiat),
 Par lots ou batch (traitement différé d’un lot de données).
 La période d’exécution: des contraintes de temps dues à
l’organisation sont introduites (date, duré….).
Ex: chaque jour à 17h, édition des factures.
 Evénement : en plus des événements conceptuels on ajoute les

événements organisationnels
 Événement de déclenchement de phase
Ex. date d’exécution d’une tâche
 Événements internes traduisant des liens entre phases (événements

intermédiaires, états d’attente)
Ex: dossier de saisi
 Autres concepts (synchronisations, règles d’émission): identiques au

MCT; prennent en compte les règles d’organisation
 MOT (Schéma des phases)

 Exemple : Gestion des sinistres dans une assurance

A l’arrivée d’une déclaration d’accident, le responsable du service de
gestion des sinistres décide de la recevabilité et note son avis sur la
déclaration. Il transmet la déclaration annotée au secrétariat du service
qui saisit les éléments essentiels sur ordinateur.
En fin de journée, on édite les demandes d’expertise et les notifications

de refus
Au retour de l’expertise, quelques jours plus tard, on enregistre sur un

terminal la réponse de l’expert. On classe la réponse dans un dossier
assuré
Au retour de la facture du garage, on vérifie si le rapport de l’expert est
arrivé; on enregistre la facture et on édite immédiatement la chèque
destiné au client
 Tableau de décomposition en phases

 Tableau de décomposition en phases

 Fiche de description des phases

 A retenir…
MOT= MCT + lieu + moment + nature
• Lieu:
– Qui exécute? Acteurs (MCC)
• Moment
– Quand exécute-t-on l’opération?
– Agencement temporel
• Nature
– Manuelle
– Automatique
– Interactive
Niveau physique
Modèle Physique des Données (MPD)

Niveau physique
– Définition des schémas
– Manipulation des données
– Contraintes d'intégrité
Niveau physique
 Définition des schémas: création de tables

Syntaxe1:  Syntaxe2:
CREATE TABLE <nom table> CREATE TABLE <nom table>
<colonne1> <format1> [option1], <colonne1> <cononne2>… as <requête>
<colonne2> <format2> [option2],
…
Format Type
Valeur numérique INT, NUMBER(x) , NUMBER(x,y)
Chaîne de caractère CHAR(n), VARCHAR2(n)
date DATE
Texte de longueur inconnu long
Niveau physique

Syntaxe1:  Syntaxe2:
CREATE TABLE <nom table> CREATE TABLE <nom table>
<colonne1> <format1> [option1], <colonne1> <cononne2>… as <requête>
…
Option Signification
NOT NULL obligation de donner une valeur
UNIQUE Interdit deux même valeurs pour la même colonne
PRIMARY KEY Clé primaire

REFERENCES <table>(col) Clé étrangère, établit une relation avec une autre
table via sa clé primaire
CHECK(condition) Émet une condition sur une colonne
DEFAULT Définit une valeur par défaut
Niveau physique

 CREATE TABLE EDITEURS
(NumEditeur NUMBER (5) PRIMARY KEY,
Nom CHAR(10)NOT NULL,
Prénom CHAR(10));
 CREATE TABLE OUVRAGES
( Numouvrage Number(5)PRIMARY KEY,
Titre CHAR(30),
NumEditeur Number(5)REFERENCES EDITEURS(NumEditeur),
NbExemplaire Number(3) CHECK (NbEXemplaire>0) );
 CREATE TABLE UNEXP
As select *FROM OUVRAGES WHERE NbExemplaire=1
Niveau physique
 Modification des schémas: Alter table

• Ajout d’attributs : syntaxe
ALTER TABLE <nom table>
ADD ( <colonne1> <format1> [option1],
…);
• Exemple :
ALTER TABLE Auteurs ADD (Nationalité char(10) NOT NULL);
• Modification d’attributs: syntaxe
ALTER TABLE <Nom table>
MODIFY < colonne1 > <nouveau format>;
• Exemple:
ALTER TABLE Auteurs MODIFY Nationalité char(100);
on ne peut pas diminuer la longueur d’une

colonne contenant déjà des valeurs
Niveau physique
 Modification des schémas: Alter table
ADROP, RENAME TO, DESC
Suppression d’une table : DROP TABLE

Exemple : DROP TABLE nom_table;
Renommer une table : RENAME TO

Exemple :
ALTER TABLE nom_table RENAME TO nouveau_
nom_table ;
Afficher le contenu d’une table : DESC

Exemple : DESC nom_table;
Niveau physique
 Contraintes d’intégrités
• Contraintes des attributs:

NOT NULL : obligation de donner une valeur
DEFAULT valeur par défaut
CHECK (condition) : contrainte sur la valeur de la colonne
UNIQUE: unicité
• Contraintes de clés primaires

PRIMARY KEY : clé primaire
• Contraintes référentielles(clé étrangères)

FOREIGN KEY : clé étrangère

Niveau physique
• Contraintes des attributs:

CREATE TABLE personne (
num NUMBER PRIMARY KEY,
nom VARCHAR2 (15),
prenom VARCHAR2 (15),
Pays VARCHAR2 (20) DEFAULT ‘Canada‘
ville VARCHAR2 (20) CHECK (ville IN
Montréal','Laval','Saint-Jérôme'))

Niveau physique
• Contraintes de clés primaire:

CREATE TABLE Produit (
codeProduit NUMBER CONSTRAINT pk1 PRIMARY KEY,
NomProduit VARCHAR2(20) NOT NULL,
description VARCHAR2 (30)
);
CREATE TABLE Medecin (

NumMedecin NUMBER(3) PRIMARY KEY,
NomMedecin VARCHAR2(20) NOT NULL,
LaSpecialite VARCHAR2(20) NOT NULL
);
Niveau physique
• Contraintes de clés primaire:

CREATE TABLE Examen(
NumMedecin NUMBER(3),
NSS NUMBER(3),
DateExamen date,
PRIMARY KEY(NumMedecin, NSS, DateExamen)
);
CREATE TABLE Resultat(

NumEtudiant NUMBER(10,0),
codeCours VARCHAR2(10),
Note NUMBER(5,2),
CONSTRAINT pk2 PRIMARY KEY(NumEtudiant,codeCours)
);
Niveau physique
• Contraintes référentielles ( clés étrangères):

create table Patient(
NSS NUMBER (3) PRIMARY KEY,
NomPatient VARCHAR2 (20) NOT NULL,
Adresse VARCHAR2 (20) NOT NULL,
NumMedecinTraitant NUMBER (3) references Medecin(NumMedecin)
);
create table Service(

CodeService NUMBER (3) PRIMARY KEY,
NomService VARCHAR2 (20) NOT NULL,
ChefDeService NUMBER (3) references Medecin
(NumMedecin),
NbLits NUMBER(3) check ( NbLits>1),
Batiment VARCHAR2 (15)
);
Niveau physique
• Contraintes référentielles ( clés étrangères):
CREATE TABLE programme (

codePrg VARCHAR2(3) CONSTRAINT pk3 PRIMARY KEY,
nomProg VARCHAR2(20)
);
CREATE TABLE etudiants (

NumAd NUMBER CONSTRAINT pk4 PRIMARY KEY,
Nom VARCHAR2(20),
Prenom VARCHAR2(20),
codePrg VARCHAR2(3),
CONSTRAINT fk1 FOREIGN KEY(codePrg) REFERENCES programme (codePrg)
);
Niveau physique
• Ajout de contraintes
ALTER TABLE Client ADD CONSTRAINT NC_pk PRIMARY KEY (NC);

ALTER TABLE Achat ADD CONSTRAINT NC_FK FOREIGN KEY (NC)
REFERENCES Client(NC);
ALTER TABLE Client ADD CONSTRAINT check_NC CHECK (NC IN (1, 2,3));
ALTER TABLE Client ADD CONSTRAINT NC_unique unique(NC);
• Suppression de contraintes
ALTER TABLE Appt DROP CONSTRAINT CLE_APPT;
• Suppression de contraintes référentielles

DROP TABLE Achat CASCADE CONSTRAINTS : Permet la suppression de toutes les
contraintes d’intégrité référentielles faisant référence à la clé primaire de la table
supprimée
Introduction à l’UML
Diagramme de classe
• UML (Unified Modeling Language) :
• •autre langage de modélisation
• langage dédié à l'objet
• •plusieurs types de diagramme, dont un utile en bases de données :
• le diagramme de classes
 Lien traduction entre UML et Merise
UML
Merise
Classe
Entité
Identifiant
Attribut 1 Attribut 1
Attribut 2 Attribut 2
… …
Méthodes
 Lien traduction entre UML et Merise: association
UML
Merise
Méthodes
 Lien traduction entre UML et Merise: association
UML
Merise
Lien vers 0 ou 1 : 0,1 Lien vers 0 ou 1 : 0..1

Lien vers 1 : 1,1 Lien vers 1 : 1
Lien vers 0 ou plusieurs : 0,n Lien vers 0 ou plusieurs : *
Lien vers 1 ou plusieurs : 1,n Lien vers 1 ou plusieurs : 1..*
Méthodes
 Lien traduction entre UML et Merise: cardinalités
UML
Merise
Méthodes
 Lien traduction entre UML et Merise: cardinalités
UML
Merise
Méthodes
 Les plus d’UML: agrégation

Association particulière dans laquelle l’une des entités décrit un tout alors que
l’entité associée décrit des parties. L’entité qui représente les tout est appelée
composite, l’entité qui représente une partie du tout est appelée composant.
 Propriétés de l’agrégation
– A « contient » des instances de B
– La suppression de A n’implique pas la suppression de B
– L'élément agrégé peut être partagé agrégation
 Exemple:
A B
Enseignant
N° Enseignant
Méthodes
Agrégat
Equipe de recherche Département •L’enseignant est un composant d’une (ou

Nom équipe plusieurs) équipe de recherche
Nom Dept
Thématique
• La disparition d’une équipe de recherche
n’entraine pas la disparition d’un enseignant
 Les plus d’UML: composition

Une forme forte d’agrégation avec le composé qui à chaque moment a une possession exclusive des
parties. Le temps de vie des parties coïncide avec celui du composé
Remarque 1:Dans une

Commande composition, la multiplicité du
N°Commande Composite côté du composite est toujours à
Date Commande 1, car un composant doit
Date livraison appartenir à un seul et un seul
composite
Total commande Remarque 2: la création d’une
1 occurrence d’un composant
exige la présence d’un
1,n composite pour s’y associer.
Ligne de commande Composant Remarque 3 : la fin de vie d’une
occurrence de composite
N°lig commande entraîne en cascade la fin de vie
de toutes les occurrences des
composants associés.
 Association: héritage
• L’association d’héritage est employée d’abord pour assurer le respect d’une règle de
modélisation appelée la règle d’homogénéité.
Tous les attributs d’une entité sont pertinents à cette entité et éventuellement tous doivent
posséder une valeur.
 Contre exemple
– Remarque 1: Transgression de la règle d’homogénéité
– Remarque 2: Certains employés ne sont pas syndiqués, notamment les employés
cadres
– Remarque 3: les occurrences de l’entité représentant des employés non syndiqués ne
pourront avoir de valeur pour No_syndiqué et Taux _cotisation_syndicale
Employé
No matricule
Nom
Prénom
No_syndiqué
Taux _cotisation_syndicale
 Exemple : Héritage et respect de la règle d’homogénéité

– Remarque 1: L’entité Employé_syndiqué est une sorte d’entité Employé et qui hérite de tous les
attributs de Employé
– Remarque 2: Toute occurrence de Employé possède une valeur pour chacun de ses 3 attributs.
– Remarque 3: Dans le cas de Employé_syndiqué chaque Occurrence possède une valeur pour les
5 attributs
Employé
No matricule
Nom
Prénom
Employé
Employé_syndiqué
No_syndiqué
Type d’association qui définit la structure d’une entité en fonction d’une autre.
Une entité appelée le supertype identifie les attributs communs, une autre
précise les attributs spécifiques à un sous-type de la première ; le sous-type
hérite à la fois des attributs, dont l’identifiant, et des associations de son supertype
 Exemple : L’héritage porte sur les attributs et les associations

– Remarque 1: L’entité Employé_syndiqué hérite des attributs de Employé, elle hérite aussi de
l’association avec Poste
– Remarque 2: Un employé_syndiqué est une sorte d’employé et tout employé occupe un poste.
– Remarque 3: Employé syndiqué est un sous-type de l’entité Employé
Employé
No matricule
Nom
Prénom
Employé_syndiqué
No_syndiqué
Diagramme de cas d’utilisation

 Diagramme de cas d’utilisation

Avant de développer un système, il faut savoir précisément à quoi il devra
servir, c.à.d à quels besoins il devra répondre.
 Modéliser les besoins permet de :

 Faire l’inventaire des fonctionnalités attendues
 Organiser les besoins entre eux, de manière à faire apparaitre des relations
(réutilisation possibles,…)
 Avec UML, on modélise les besoins au moyen de digrammes de cas
d’utilisation.
270

 Un cas d’utilisation est un service rendu à l’utilisateur, il implique
des séries d’actions élémentaires.
 Notation:
 Un cas d’utilisation est déclenché par un événement extérieur au

système appelé événement initiateur
 Un cas d’utilisation possède un nom: celui de la fonctionnalité du
système qu’il prend en charge
 Un cas d’utilisation met en œuvre un dialogue entre le système et
l’entité à l’origine de l’événement initiateur.
Un cas d’utilisation est l’expression d’un service réalisé de bout en bout, avec
un déclenchement, un déroulement et une fin, pour l’acteur qui l’initie.
271
 Diagramme de cas d’utilisation: Description d’un cas

d’utilisation
 Le diagramme de cas d'utilisation décrit les grandes fonctions
d'un système du point de vue des acteurs, mais n'expose pas de
façon détaillée le dialogue entre les acteurs et les cas d'utilisation.
 Un simple nom est tout à fait insuffisant pour décrire un cas

d'utilisation.
Chaque cas d'utilisation doit être documenté pour qu'il n'y ait
aucune ambiguïté concernant son déroulement et ce qu'il recouvre
précisément.
272

 Un acteur est une entité extérieure au système modélisé, et qui
interagit directement avec lui
 Notation:
 L’acteur est à l’origine des événements initiateurs reçus par le

système
 L’acteur dialogue par la suite avec le cas d’utilisation dont il est
l’initiateur
 L’acteur possède un nom: celui du rôle qu’il joue lors de son
interaction avec le système
 L’acteur n’est pas forcément humain. Il peut s’agir:
o D’un autre système
o D’un équipement
273
 Diagramme de cas d’utilisation : Identification des acteurs

 Exemple
o « Pierre utilise le système pour gérer son agenda »
o « philippe utilise aussi le système pour gérer son agenda. Mais philippe est
aussi autorisé à administrer le système »
 Pierre n’est pas un acteur du système, philippe n’est pas un acteur

du système
 Le rôle « utilisateur » est un acteur du système
 Le rôle « administrateur » est un acteur du système
Ne pas confondre personne physique et rôle

Une personne peut très bien assumer plusieurs rôles et
réciproquement
274
 Diagramme de cas d’utilisation: Acteurs principaux et

secondaires
 L’acteur est dit principal pour un cas d’utilisation lorsque l’acteur
est à l’initiative des échanges nécessaires pour réaliser le cas
d’utilisation.
 Les acteurs secondaires sont sollicités par le système alors que le

plus souvent, les acteurs principaux ont l’initiative des interactions.
275
 Diagramme de cas d’utilisation: Relations entre acteurs

 Une seule relation possible: la généralisation/ spécialisation
276
 Diagramme de cas d’utilisation :Acteurs et cas d’utilisation

 L’interaction entre cas d’utilisation et acteur est représentée par
une association, éventuellement orientée vers le sens de
l’interaction
 Une seule association est utilisée pour représenter l’ensemble
des événements échangés
 L’association peut comporter des cardinalités
277
 Diagramme de cas d’utilisation :Dépendance entre cas

d’utilisation
 Il existe 3 types de dépendance entre cas d’utilisation:
o Les dépendances d’utilisations (ou d’inclusion):
mise en facteur de séquences d’événement communes
o Les dépendances d’extension :
Externalisation de séquences d’événement exceptionnelles
o Les dépendances de généralisation:
Généralisation/spécialisation de cas d’utilisation
278
 Diagramme de cas d’utilisation : Dépendances d’inclusion

 Indique qu’un cas d’utilisation utilise systématiquement et
intégralement une séquence d’activités décrite dans un autre cas
d’utilisation
 Est représentée par une flèche pointillée étiquetée « include »,
pointant vers le cas d’utilisation utilisé
Cas d’utilisation 1
« include »
Acteur 1
Le cas d’utilisation 1 utilise systématiquement le cas d’utilisation 2
279
 Diagramme de cas d’utilisation :Dépendances d’inclusion

 Quand un cas est trop complexe (faisant intervenir un trop grand
nombre d’actions), on peut procéder à sa décomposition en cas
plus simples.
280
 Diagramme de cas d’utilisation :Dépendances d’inclusion

 On peut factoriser des comportements utiles à plusieurs cas
d’utilisations
281
 Diagramme de cas d’utilisation :Dépendances d’extension

 Indique qu’un cas d’utilisation utilise facultativement ou sous
certaines conditions une séquence d’activités décrite dans un
autre cas d’utilisation
 Est représentée par une flèche pointillée étiquetée « extend »,
pointant vers le cas d’utilisation étendu
« extend »
Utilisateur
Le cas d’utilisation 2 est une extension du cas d’utilisation 1

282
 Diagramme de cas d’utilisation : Dépendance de

généralisation
 Indique qu’un cas d’utilisation est une spécialisation d’un autre
cas d’utilisation
 Est représentée par une flèche « d’héritage » pointant du cas
d’utilisation spécialisé vers le cas d’utilisation le plus général
Acteur 1
Le cas d’utilisation 2 est une spécialisation du cas d’utilisation 1
283
 Diagramme de cas d’utilisation : Dépendance de

généralisation
 Le paiement par carte bancaire est un cas particulier de paiement
 Un virement est une sorte de paiement
 La flèche pointe vers l’élément général.

 Cette relation de généralisation/spécialisation est présente dans la
plupart des diagrammes UML et se traduit par le concept d’héritage
dans les langages orientés objet.
284
Pr.Imane DAOUDI
 Diagramme de cas d’utilisation : Dépendance de généralisation

 Permet de factoriser un comportement commun à un ensemble de cas
d’utilisation proches
 Le cas d’utilisation le plus général est dit abstrait si seuls les cas d’utilisation
spécialisés sont exécutables
Retirer argent
Retirer argent
avec ticket
Utilisateur <<Abstract>>
Ouvrir compte
Ouvrir compte Ouvrir compte

chèque épargne
285
TD n°2
286
Pr.Imane DAOUDI

Conception Des SI (SAYOUTI)

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

Conception Des SI (SAYOUTI)

Transféré par

Droits d'auteur :

Formats disponibles

Conception des systèmes d’information

Professeur. Adil SAYOUTI

o Ce Cours a pour objectif de permettre à l’ingénieur de concevoir

o Il vise aussi à ce que l’ingénieur soit capable de lire et analyser

o Analyse : processus d'examen de l'existant.

o Conception : processus de définition de la future application

o Modèle : représentation schématique de la réalité.

o Systèmes d'Information : ensemble des moyens (humains et

o Définition : Ensemble de méthodes, techniques et outils dédiés à

o Système : ensemble d'éléments en interaction dynamique, dont

o Système informatique : Un ensemble d’éléments qui sont

L'objectif du génie logiciel est d'optimiser le coût de

• l'augmentation des coûts ;

Les utilisateurs veulent des systèmes qui satisfont leurs besoins 7

o Fournir le livrable qui correspond à la commande passe par une

o Pour cela, le chef de projet logiciel doit s'approprier le contexte,

o Cette analyse au début du projet informatique permet de préparer

o Compréhension minimale du problème :

Une bonne analyse

Le cahier des charges

o Première étape de l’expression du besoin

o Le cahier des charges est un document technique,

La spécification des besoins

o La spécification des besoins doit décrire sans ambiguïté le logiciel à

o Les besoins fonctionnels expriment une action que doit effectuer le

Besoins non fonctionnels

Besoins non fonctionnels

En génie logiciel, divers travaux ont mené à la définition de la

• Un modèle est une représentation abstraite et simplifiée, d'une

• Un modèle est un langage commun, précis, qui est connu par

• Dans le domaine de l'ingénierie du logiciel, le modèle permet de

• Par exemple, les plateformes de modélisation savent maintenant

• Le modèle est indispensable pour assurer un bon niveau de

• Le choix du modèle a donc une influence capitale sur les solutions

• Le cycle de vie d'un logiciel, désigne toutes les étapes du développement

• L'origine de ce découpage provient du constat que les erreurs ont un

Le cycle de vie du logiciel comprend généralement au minimum les étapes

• Analyse des besoins et faisabilité

• Qualification (ou recette)

La séquence et la présence de chacune de ces activités dans le cycle de

• Dans ce modèle, le principe est très simple :

• L'inconvénient majeur du modèle de cycle

1. Détermination, à partir des résultats des cycles précédents, ou de

• L'analyse préliminaire est affinée au cours des premiers cycles. Le modèle

Prévision de la phase Développement,

o Dans les modèles par incrément, un seul ensemble de composants est

– Quand la plupart des spécifications sont connus à l’avances et vont être

– Quand on veut rapidement un produit fonctionnel

– Pour des projets de longues durées

– Pour des projets impliquant de nouvelles technologies

o La modélisation consiste à créer une représentation virtuelle d'une réalité de

o Le but de cette méthode est d'arriver à concevoir un système d'information. La

o La méthode MERISE date de 1978-1979, et fait suite à une consultation

o L’entreprise est un système complexe dans lequel transitent de très nombreux

o L’enjeu de toute entreprise industrielle ou de services consiste donc à mettre

o Ce système d’information assurera le lien entre deux autres systèmes de

o Le système de pilotage décide les actions à exécuter par le système opérant

o Le système d’information doit décrire (ou représenter) le plus fidèlement

o Le système d’information doit être doté d’un mécanisme (appelé processeur

o Le processeur d’information produit des changements dans la base

• Pour la méthode MERISE, la conception des systèmes

o Le schéma directeur : dont le rôle est de définir, de manière

o Pour rendre contrôlable et modulable ce développement, il est