Base de Données PDF VF

Julie Paternotte 2020
Base de données pour la gestion

Prof: Thierry Van Den Berghe
Année 2020-2021
BDD 1
Chapitre 1: La gestion de projet informatique
Définition: Le système d’information d’une organisation est l’ensemble des ressources mises en
oeuvre pour créer, collecter, stocker, traiter, diffuser et sécuriser l’information
Certaines ressources d’un système d’information sont digitales, comme des ordinateurs, d’autres
non comme des documents papier.
Définition: Le système informatique (SI) est un sous-ensemble du système d’information qui est
dédié au traitement de l’information digitale. (domaine= métier ou entreprise ou encore
département)
Le fonctionnement des affaires implique toujours d’avantages les technologies digitales. La part
du système informatique au sein du système d’information est donc de plus en plus importante.
Le système informatique est construit pour automatiser certaines activités d’une entreprise, d’un
métier, d’un groupe d’utilisateurs, qui constituent le domaine d’application des technologies
digitales.  
 
Définition: Le domaine d’application d’un système informatique désigne la partie de monde qui
interagit avec ce système.
Afin de subvenir aux exigences des managers, les informaticiens ont recourt à plusieurs
techniques et plusieurs outils. En particulier, le développement d’un logiciel se structure comme
un projet qui suit un processus de développement défini. L’ingénierie logicielle est la discipline
qui détermine les meilleurs processus de développement possible, comme le montre l’image ci-
dessous. Un processus de développement est une démarche organisée et systématique qui aide
à déterminer les phases, les activités et les rôles d’un projet de développement.
Image: Processus de
développement de logiciel
Les projets informatiques sont menés par les informaticiens mais ils impliquent largement les
managers qui doivent collaborer avec eux pour construire un système efficient! Le manager a
donc tout avantage à connaître les approches suivies par les informaticiens pour jouer un rôle
proactif dans un projet informatique.
1. Notion de projet informatique

L’entreprise est le lieu de projets nombreux et variés, par exemple un audit, le développement
d’un nouveau produit ou l’organisation d’une campagne de publicité. Un projet vise à produire un
résultat, un produit ou un service, que l’on appelle livrable.
Définition: Un projet est un effort délimité dans le temps pour fournir un livrable unique de qualité
dans un délai et un budget fixés. (caractérisé par une date de début et une date de fin)
1.1. Résultats sous contraintes

Un projet doit déboucher naturellement sur un livrable de la meilleure qualité possible et qui
répond aux attentes, tout en respectant au minimum des contraintes de coûts et de délais. Les
BDD 2
managers de projets doivent trouver le meilleur compromis entre ces différentes contraintes et
sont parfois amenés à privilégier certaines d’entre elles.
Image: Triangle des contraintes et exemples de projets
D’autres types de contraintes peuvent s’imposer en

fonction des projets, comme des contraintes légales.
1.2. Projet informatique

Il consiste à construire un système informatique selon un processus
de développement organisé et pour répondre à une demande
exprimée pas des utilisateurs. Ce projet peut porter sur par
exemple:
- La construction de systèmes digitaux en ligne, comme la création
d’un e-shop
- Le développement d’applications back office, comme un système
de suivi des stocks sur des plateformes mobiles.
- La mise en place d’infrastructures informatiques, comme la
conversion d’un système existant vers le Cloud.
Image: Les quatre P d’un projet informatique
La nature d’un projet informatique s’explique assez bien à travers les 4 P

- Personne: un projet informatique fait intervenir de nombreux acteurs différents, dont les
spécialistes métier, qui sont essentiellement les managers utilisateurs, et les spécialistes des
technologies digitales, à savoir les informaticiens en charge de construire le système.
- Produit: La finalité première du projet est de délivre un système qui répond aux exigences
métier, mais pas seulement. Les livrables du projet reprennent aussi une documentation, des
résultats,…
- Projet: Le projet doit être planifié avant son lancement, puis différents aspects de son
déroulement doivent être suivis, comme la qualité ou le respect du budget.
- Processus: un projet se structure selon un processus qui guide les informaticiens notamment à
travers une décomposition du projet en phase et en activités.
2. Processus de développement de logiciel

Un projet informatique débouche sur plusieurs livrables, comme le matériel, le logiciel, un plan de
formation, etc. Dans le domaine de la gestion d’entreprise, le livrable le plus important est le
logiciel.
2.1. Processus et phases

L’ingénierie logicielle est la discipline qui guide les spécialiste des TIC (Technologies de
l’Information de la Communication) dans la réalisation d’un projet à l’aide de processus clairement
établis.
BDD 3
Définition: L’ingénierie logicielle est « l’application » d’une approche systématique, disciplinée et

quantifiable pour le développement, l’exploitation et la maintenance d’un logiciel »
L’organisation d’un projet en différentes phases en facilite la gestion et le contrôle. Une phase de
projet reprend un ensemble d’activités qui produisent un ou plusieurs livrables. On identifie une
phase quand la nature du travail à accomplir est cohérente à une portion du projet. Par exemple:
- une phase correspond à un accent particulier, comme la collecte des exigences auprès des
utilisateurs
- Une phase s’achève par la livraison d’une version plus ou moins aboutie du logiciel
Image: Phases et activités d’un

processus de développement
Certaines phases sont communes à tout projet d’ingénierie.

L’image ci-dessous montre l’enchainement de ces phases génériques:
- Comprendre le problème: quels sont les objectifs à atteindre et comment le projet va-t-il être
réalisé ?
- Planifier une solution: Quelles sont les tâches à
réaliser ? Qui va les assumer, et quand ?
- Exécuter le plan: Comment réaliser le plan prévu ?
Comment vérifier le bon avancement du projet ?
- Evaluer le résultat: Les résultat est-il conforme aux
attentes des utilisateurs ? Dans quelle mesure les
objectifs du projets ont-ils été rencontrés?
Image: Les phases génériques de l’ingénierie
2.2. Activités
En plus d'un phasage dans le temps, les projets de développement de logiciel sont également
décomposés au niveau des activités à réaliser au sein des différentes phases. Ces activités
peuvent être catégorisées en activités techniques et en activités managériales.
Les activités techniques sont directement liées à la réalisation des livrables. Sans vouloir être
exhaustif, on peut citer typiquement :
• la collecte et le traitement des exigences, qui consiste à comprendre les besoins des
utilisateurs et à voir dans quelle mesure un système informatique peut optimiser les processus
d'affaires existants ;  
• la conception du futur système, où les informaticiens imaginent une solution technique qui
répond aux exigences des utilisateurs;  
• la construction proprement dite du système, qui reprend notamment récriture des pro-
grammes;  
BDD 4
• le test, qui consiste à mesurer la qualité du système produit et, si nécessaire, à entreprendre
des actions correctrices ;  
• le déploiement, durant lequel le système est transmis aux utilisateurs.
Ces activités ne sont pas cloisonnées en elles. Par exemple, la conception requiert souvent
d'approfondir certaines exigences qui n'auraient pas été complètement spécifiées auparavant.
Les utilisateurs managers sont impliqués de près dans la collecte et le traitement des exigences,
les tests et le déploiement. La conception et la construction sont principalement du ressort des
informaticiens.
Les activités managériales, elles, ont trait à la gestion du projet, comme la planification ou la
gestion des équipes. Ces activités sont transversales aux différentes phases et viennent en
support aux activités techniques. Elles ne contribuent pas directement à la production des
livrables. Ces activités se retrouvent dans tous les projets, informatiques ou non, et sont bien
documentées dans la littérature dédiée à la gestion de projets. Si ces activités sont assumées par
les informaticiens, les utilisateurs managers familiarisés à la gestion de projet n'ont aucun mal à
s'y conformer, voire à y contribuer.
2.3. Bonne Pratiques

Bonnes pratiques. En plus de proposer une démarche de développement, l'ingénierie logicielle
propose de nombreuses recommandations pour produire des systèmes de qualité. En voici un
bref échantillon :
➔ Donner de la valeur aux utilisateurs. Chaque exigence exprimée doit donc être évaluée et
priorisée en fonction de la valeur qu'elle apporte. Un corollaire de ce principe est la nécessité de
construire un système qui répond réellement aux exigences des utilisateurs, ni plus ni moins. Trop
souvent, certaines fonctionnalités développées à grands frais sont peu ou pas utilisées...
➔ Garder le système simple. Une tendance naturelle des utilisateurs est de demander tout et tout
de suite, sans réflexion préalable sur les processus d'affaires qui doivent être automatisés.
Certains systèmes sont alors très complexes à utiliser et à maintenir dès leur naissance, sans parler
du coût de développement lié à leur complexité. Même si travailler à la simplification d'un
système prend du temps et s'avère paradoxalement plus difficile qu'il n'y paraît, les retours de la
simplification sont souvent appréciables.
➔ Rester ouvert au futur et intégrer la flexibilité. Les organisations ont l'obligation de réagir
rapidement dans leur environnement mouvant (concurrence, évolutions techniques, accélération
de l'apparition de nouveaux produits, etc.). Les systèmes informatiques doivent être souvent
adaptés aux nouvelles exigences des utilisateurs et doivent être pensés dès le départ pour le
changement. Concevoir des logiciels flexibles reste un défi technique pour les informaticiens,
alors que d'autres produits de l'ingénierie, comme des bâtiments ou des voitures, subissent peu
de modifications durant leur cycle de vie.
3. Exemples de processus de développement de logiciel

Il existe une variété de processus de développement qui combinent différemment les phases et
les activités. Certains processus imposent une succession strictement séquentielle des phases du
projet, alors que d'autres encouragent leur répétition à travers des itérations successives. Nous
BDD 5
nous bornerons ici à citer quelques exemples représentatifs de processus, à savoir le processus en
cascade, le Unified Process et les processus Agile
En pratique, le choix d'un processus de développement pour un projet donné sera déterminé
notamment en fonction des particularités du domaine d'application, de la taille du logiciel ou du
profil des acteurs du projet. Le processus doit alors être vu comme un cadre méthodologique
générique qu'il faut adapter en décidant des phases et des activités pertinentes pour le projet.
3.1. Processus en cascade

Processus en cascade. Ce processus historique trouve ses origines dans des projets logiciels des
années 50. Il prévoit l'enchaînement linéaire des phases de développement, qui correspondent
chacune à une même activité (Figure 1-6}. La« cascade » suggère que le livrable d'une phase
constitue l'entrée de la phase suivante. Par exemple, la phase de construction délivre un système
à valider par la phase de test.
Ce processus, bien qu'ancien, reste assez populaire et pertinent pour des projets réduits en taille
et en durée.
Exigences
Image: Les phases du processus en

cascade
Conception
Construction
Test
Déploiement
Le processus en cascade présente cependant plusieurs faiblesses qui sont prises en charge par
d'autres processus. En effet, un développement en une seule séquence est rarement réaliste pour
les raisons suivantes :
- La difficulté de cerner les exigences en une seule fois et au début du projet. En effet, imaginer
un système immatériel reste un défi difficile pour les utilisateurs. D'autres approches, comme
l'élaboration de prototypes successifs, les aident à faire émerger le système qu'ils attendent.
- La difficulté de construire des systèmes complexes en une seule fois. D'autres approches
découpent le système en sous-systèmes pour mieux maîtriser leur complexité et prévoient des
itérations pour retravailler des sous-systèmes particulièrement élaborés.
- L'instabilité des besoins dans un environnement changeant. Des modifications des exigences
peuvent intervenir même pendant la construction, qui s'étale parfois sur des années. D'autres
approches intègrent naturellement le changement et la flexibilité (ou l'agilité) dans le
développement.
- La lourdeur de concentrer les tests en fin de processus, avec le risque de découvrir fort tard des
défauts importants, pouvant même remettre le développement en cause. D'autres processus
suggèrent de se concentrer.d'abord sur les aspects les plus risqués pour les tester assez tôt,
afin de rapidement conformer la faisabilité du projet et de limiter l’investissement en cas de
problèmes bloquant.
BDD 6
3.2. Unified Process

Le UP a été proposé en 1996 par la société Rational et se veut applicable à un large éventail de
projets informatiques. Contrairement au processus en cascade qui est séquentiel, le UP est
itératif, car des ensembles de tâches peuvent se répéter, et incrémental, car le système est
construit et livré partie par partie.
Comme le montre l’image ci-dessous, le cycle de développement du UP comporte quatre
grandes phases:
lnception Elaboration Construction Transition
lt.1 lt.2 lt.1
Business modeling
Image: Les phases du UP
Exigences
Analyse et conception
Implémentation
Test
Déploiement
Temps
• Inception, qui définit la portée du projet. On va identifier les principales utilisations du  

système et estimer les coûts, les délais et les risques liés à son développement.  
• Elaboration, qui planifie le projet et décrit le futur système. On va spécifier le système à  

construire et préciser les coûts et délais.  
• Construction, qui réalise le système. On va produire et tester itérativement des versions  

successives du système jusqu'à sa maturité.  
• Transition, qui livre le système abouti aux utilisateurs et assure leur autonomie.  
Chaque phase est le lieu de différentes activités techniques reprises dans la Figure 1-7 et de
plusieurs itérations (notées« It »). UP prévoit aussi des activités managériales (appelées
disciplines de support), comme la gestion de projet ou la gestion du changement.  
3.3 Processus Agile

Le courant Agile a émergé en 2001 avec l'énoncé de ses principes fondateurs repris dans un
manifeste. Ces principes sont:
• les individus et leurs interactions sont plus importants que les processus et les outils ;
• il est préférable de livrer des logiciels opérationnels plutôt qu'une documentation exhaustive
• il faut privilégier la collaboration avec les clients-utilisateurs plutôt que la négociation
contractuelle;
• l'adaptation au changement doit l'emporter sur le suivi d'un plan figé.  
Les processus de développement Agile intègrent le fait que les besoins des utilisateurs, le  
processus de développement et le logiciel à produire émergent progressivement au cours du
projet.  
On notera l'accent mis sur la collaboration étroite entre les utilisateurs et les informaticiens avec
des feedbacks immédiats, et donc l'importance pour les managers de connaître la culture et les
approches des spécialistes informatiques.  
BDD 7
3.4. L’exemple Scrum

La méthode Scrum intègre la plupart des préceptes Agile. Un projet Scrum se compose de«
sprints» successifs d'une durée d'un mois maximum. Un sprint débouche sur un livrable
incrémental qui est soumis aux utilisateurs.  
Chaque sprint est préparé lors d'une réunion de « planification du sprint» durant laquelle on
précise son objectif (voir image ci-dessous). La « revue de sprint » est une réunion de validation
du livrable du sprint, alors que la « rétrospective du sprint » vise à valoriser l'expérience acquise et
à améliorer le processus.  
Chaque jour, les informaticiens se rencontrent pendant 15 minutes lors d'une « mêlée quotidienne
» pour exposer leurs réalisations de la veille, le travail prévu pour la journée et les éventuelles
difficultés rencontrées.  
Scrum définit plusieurs rôles. Le « Product Owner » est un spécialiste métier qui détermine une
liste d'exigences avec des priorités reprises dans un« Product Backlog ».Le« Scrum Master » est
un facilitateur qui soutient l'équipe du projet et s'assure de la bonne application du processus
Scrum.  
Rétrospective du sprint
Product
Backlog
Sprint
Planification du sprint Revue du sprint
4. Acteurs d’un projet

Un projet de développement de logiciel implique de nombreuses personnes issues de disciplines
et de cultures diversifiées, en incluant notamment ( Voir image ci-dessous):
• Des utilisateurs non informaticiens : ce sont les experts métier pour lesquels le système  
informatique est construit. Ils exposent leurs exigences en termes de traitements de don-
nées. Ils sont soit internes à l'organisation, soit externes, comme les futurs clients d'un site
de vente en ligne.  
• Les informaticiens, qui sont les spécialistes des technologies. En particulier, le business
analyst étudie les exigences des utilisateurs. Le développeur construit le système
correspondant. D'autres intervenants techniques, comme des ergonomes, des responsables
de la qualité (qualiticien), ou des experts en sécurité informatique assument des tâches
spécialisées.  
• Le sponsor, qui donne son aval au projet. Il fournit les ressources et le soutien nécessaires au
projet.  
BDD 8
Utilisateurs Informaticiens
(spécialistes (spécialistes Sponsor
métier) des TIC) Image: Principaux acteurs d’un projet informatique
l L
Utilisateur chef
final - de projet
décideur
1-
business
analyst
..... développeur 1
Un projet est pris en charge par une équipe qui

- expert exécute les activités sous la supervision d'un chef de
projet. Cette équipe inclut donc le chef de projet,
les informaticiens en charge du développement et, bien souvent, des utilisateurs clés qui
s'impliquent de manière importante dans le projet et qui représentent la communauté des
utilisateurs, comme le « Product Owner » dans Scrum.
4.1. Mission du chef de projet

Le chef de projet assume principalement les activités managériales du projet et gère notamment
les aspects humains, financiers et logistiques. Il doit tout mettre œuvre pour permettre aux
membres de l'équipe du projet d'accomplir leurs tâches dans les meilleures conditions.
Il s'agit pour lui de motiver les équipes, de gagner l'adhésion de toutes les parties et de soigner
la communication tant à l'intérieur de l'équipe de projet qu'à l'extérieur.
Le chef de projet joue un rôle déterminant dans le succès d'un projet. Quelles sont ses principales
compétences interpersonnelles ?
Leadership
• Concentrer les efforts d'un groupe de personnes sur un but commun et les amener à
travailler en équipe.
• Faire réaliser des tâches par d'autres acteurs que soi-même.
Team building
• Aider un groupe de personnes, animées par un but commun, à travailler de manière
autonome et coordonnée entre elles.
• Établir les objectifs, définir et négocier les rôles et les procédures, gérer les conflits, etc.
• Résoudre les problèmes sans blâmer un membre de l'équipe.
Motivation
• Développer un environnement favorable à la réalisation d'objectifs tout en assurant un
maximum de satisfaction de chaque membre du projet.
• Promouvoir les valeurs de satisfaction et de réalisation professionnelles, d'achèvement de
pro- grès et de reconnaissance (y compris financière).
• Élargir la variété des tâches et les responsabilités de chaque acteur.
• Conférer un certain contrôle à l'acteur sur la réalisation de ses tâches, comme l'auto-
évaluation, la planification, etc.
Communication
• Diffuser la bonne information au bon moment.
• Adapter son style de communication à son interlocuteur.
• Savoir écouter.
BDD 9
Influence
• Orienter le comportement des personnes pour obtenir leur coopération.
• Utiliser subtilement son autorité, dans une perspective de collaboration à long terme (les
enne- mis ne sont jamais utiles).
Négociation
• Composer avec des parties d'intérêts opposés pour dégager un accord ou un compromis.
• Rechercher une solution win-win, sans qu'aucune partie ne se sente lésée.  
5. Conclusion
L'ingénierie logicielle propose des processus de développement de logiciel organisés en phases
et en activités afin de guider la réalisation de projets. La gestion du projet est assumée par un
chef de projet, qui s'appuie sur un processus de développement défini. Un projet informatique
est pris en charge par l'équipe du projet qui regroupe des informaticiens et des utilisateurs.  
Le chef de projet est confronté à plusieurs défis, dont ceux-ci:  

• la complexité des systèmes à développer impose des mécanismes comme la subdivision du
système ou la répétition de certaines phases ;  
• la gestion du changement fait partie intégrante des développements informatiques et requiert

des approches spécifiques. La réponse des méthodes Agile, de plus en plus populaires en
informatique mais aussi en gestion, semble prometteuse, même si certains de leurs principes
étaient déjà sous-jacents dans des processus plus anciens
• même si le livrable du projet est technologique, la dimension humaine est primordiale et

intense, car le livrable à produire est spécifique aux exigences des utilisateurs. Les processus les
plus récents de l'ingénierie logicielle prescrivent d'ailleurs la mise en place d'une collaboration
forte et permanente entre informaticiens et utilisateurs.
Une des premières activités d'un projet informatique consiste à faire émerger les exigences du
système à construire. Il s'agit donc, pour les spécialistes métier, d'exposer ces exigences le plus
précisément possible, et pour les spécialistes informaticiens, de comprendre et de respecter ces
exigences. Pour faciliter ces échanges, le_s exigences sont souvent exprimées avec des lan-
gages ad hoc, comme ceux présentés dans le Chapitre 2. Il nous paraît donc essentiel que les
managers maîtrisent ces langages pour assurer la meilleure communication possible au sein
de l'équipe de projet.
BDD 10
Chapitre 2: La gestion de projet informatique
1. Modélisation de système informatiques

La spécification des exigences consiste à décrire les fonctions du système du point de vue de
l’utilisateur, sans rentrer dans les détails techniques liés à la réalisation du système. 
Définition: une exigence est l'énoncé d’une capacité que doit posséder Ie système à construire
pour répondre à un objectif donné, ou exprime une contrainte que le système doit respecter
Par exemple, les utilisateurs pourraient exiger d’un système qu'il soit capable de calculer les frais
de port d'une commande en fonction du pays du client, ou qu'il respecte une contrainte de
confidentialité des données personnelles du client.
1.1.Différents langages
Les exigences peuvent être formulées avec différents langages, comme illustré dans Ie:
• Ie langage naturel libre, comme Ie français ;

• Ie langage naturel structuré, qui consiste à suivre un canevas fixé pour exprimer les exigences.
Par exemple, les approches Agile ont popularisé les exigences sous forme de user stories,
dont une structure possible est :« en tant que <rôle>, je veux <fonctionnalité> afin de
<valeur>»
• les langages graphiques, qui proposent des symboles, des connecteurs, etc. pour décrire les
processus ou les données que Ie système devra prendre en charge.
Exemple de langage Exemple de formulation

1
•langage naturel libre Les articles du catalogue sont accessibles aux clients.
En tant que client, je veux pouvoir accéder au catalogue des articles
langage naturel structuré
pour choisir celui qui répond à mes attentes.
Langage graphique (cas d'utilisation Accéder au catalogue d'articles

[ Section 2.2.,1- ) -
Client
Un « bon » langage de spécification doit : 

• être suffisamment expressif pour pouvoir formuler toutes les exigences. Par exemple, un
langage trop simple ne permettra pas de spécifier des exigences complexes, un peu comme le
vocabulaire dont dispose les jeunes enfants et qui n'est pas assez étoffé pour formuler des idées
abstraites. Le langage naturel est très expressif, alors que les langages graphiques sont plus
limités ;
• être accessible à tous les acteurs du projet. Certains langages graphiques demandent un
minimum de formation pour être compris, mais davantage d'expérience pour construire des
représentations ;
• être suffisamment formel pour exprimer précisément les exigences, et éventuellement être traité
par des outils de génie logiciel, c'est-à-dire des logiciels spécialisés dans la représentation des
exigences et dans la génération automatique de logiciels.
Malheureusement, expressivité, accessibilité et formalisme ne sont pas mutuellement
compatibles. Par exemple, un langage très formel est rarement facilement accessible. L'équipe de
BDD 11
:- .,._~;. . . .~~\~t-J~"·•,:~(\.,_ -~::·;-· ' ·:,: .;
:~,i~\- êfflplè de:lang age
;fijOQ'ffiJ~ita~yrel structu ré
..- , -;-· •· i,.<' •.• ~:· _- • -... . ..
projet tentera alors de trouver Ie meilleur compromis dans le choix du langage, essentiellement
en fonction du profil des utilisateurs et de la nature du système à construire
1.2.Faiblesses du langage naturel

A priori, on serait tenté de spécifier les exigences avec le langage naturel (structuré ou non), vu
sa grande expressivité et son accessibilité. Malheureuse- ment, le langage naturel pose certains
problèmes :
• Ambiguïté : comment garantir qu'une exigence sera comprise de la même manière par tous
les acteurs? Par exemple, lorsqu'on écrit: le système doit prévoir un mécanisme de remise par
quantité et par type de clients, peut-on cumuler les deux types de remises ou non ?
• Silence : les utilisateurs ont parfois du mal à se mettre à la place d'un acteur externe qui ne
connaît pas leur métier ni leurs besoins. Ils ont donc trop souvent tendance à supposer que
certains éléments sont connus de leurs interlocuteurs et omettent de les spécifier. 
Bruit : les exigences sont censées décrire principalement ce qui touche à l'information et à son
traitement, mais elles reprennent parfois des éléments qui n'ont que très peu d'intérêt pour la
construction du système, comme le client doit laisser son animal de compagnie à l'entrée du
magasin.
• Contradictions : elles surgissent surtout lorsque les spécifications sont rédigées par plu-
• Redondance : c'est un problème général dan~ la rédaction d~ contenus. Si on ne détecte pas
qu'une même fonctionnalité est décrite plusieurs fois, on risque de dupliquer inutilement
certains des développements.
1.3.Construction de modèles graphiques (Visuel Modeling)

Pour pallier certains problèmes du langage, les informaticiens utilisent les langues graphiques
pour établir des modèles du futur système selon les exigences des utilisateurs.
En informatique, un modèle est une représentation schématique, et donc simplifiée, du système.

Par exemple, on établira des modèles pour représenter le déroulement dans le temps d'un
processus d'affaires à automatiser, ou pour décrire les données que le système devra prendre en
charge.
La notion de modèle est assez large, mais dans Ie domaine de l'ingénierie, un modèle préfigure
ce que I'on souhaite construire et joue ainsi Ie rôle de prototype. 
Un modèle facilite Ie processus de création, car il peut être plus facilement modifié que l'objet
réel qu'il représente. Par exemple, un architecte peut aisément mettre à jour Ie plan d'un
bâtiment, ce qui est plus simple que de modifier un bâtiment construit. 
Un modèle permet aussi un échange d'idées et leur évaluation entre les acteurs du
développement du système. Il aide à prendre des décisions de conception. Par
exemple, !'architecte peut présenter à ses clients plusieurs plans illustrant des options possibles
avant un choix définitif. 
Un modèle ne représente que partiellement la complexité du système et omet volontairement
des détails qui pourraient alourdir la communication et la validation du modèle. Par exemple, un
premier plan d'un bâtiment ne précise pas les matériaux utilisés.
BDD 12
1.4.Dimensions de la modélisation
La complexité des systèmes informatiques impose des stratégies de décomposition pour faciliter
leur spécification. En particulier, plusieurs modèles complémentaires sont requis pour circonscrire
les différents aspects d'un logiciel:
• Les modèles de spécification des structures de données : ils identifient des types de données
et leurs interrelations. Par exemple, un système devra gérer des données sur des clients, des
articles et des commandes. Les modèles les plus répandus sont les diagrammes de classes et
les diagrammes entité/association.
• Les modèles de spécification des traitements : ils décrivent la manière dont les données sont
créées, transformées ou exploitées. Par exemple, on exposera en détail comment créer une
commande ou comment mettre à jour un compte pour un client.
• Les modèles de spécification de la dynamique : ils précisent les séquences d'opérations per-
mises au cours du temps et les événements qui déclenchent ces séquences. Par exemple, un
évènement nouvelle commande induit la séquence suivante pour passer une nouvelle
commande. (l) créer un compte client, (2) choisir les articles et les quantités commandées, (3)
calculer les frais de livraison, et (4) calculer le total de la commande
• Les modèles de spécification d’interface: ils schématisent l’apparence et l’organisation de

l’interface homme-machine, par exemple à travers des maquettes d’écrans de saisie (mock-up)
Interfaces
Structures Quelle est la forme
Quels sant les types de données
et I' orga nisation de. I'i n;ertace
pris en charge par Ie système?
homme/mach1ne .
Système logiciel
. Dynamique
Fonctions
Quels traitements faut-il réaliser Quelles sent les séquences
de traitements
sur les types de données?
et leurs déclencheurs?
Nous nous limiterons par la suite aux modèles qui expriment les exigences vues par les
utilisateurs. D'autres modèles sont ciblés sur le travail de conception technique des
informaticiens, par exemple en représentant la structure interne du système.
1.5.Unified Modeling Language (UML)

UML reprend un ensemble de langages pour modéliser un système informatique selon ses
différentes✓dimensions et pour les différentes phases de son développement.
La version 0.8 d'UML a été publiée en 1995 par la société Rational (qui est aussi à l'origine du UP)
avec une intention de rassembler plusieurs techniques de modélisation existantes dans un
ensemble cohérent. Depuis lors, UML est devenu un standard de l'industrie informatique défini
par l'Object Management Group. Notons que UML et UP partagent la même genèse, mais le
premier propose des représentations uniquement, et le second un processus de développement.
UML et UP sont donc complémentaires.
BDD 13
L’image ci-dessous montre des exemples simplifiés de modèles dans le contexte d’une maison
d’édition. Le diagramme de cas d’utilisation (en haut à gauche) montre les principales fonction
attendues d’un système et identifie ses utilisateurs génériques. Le diagramme entité/association
(en bas à gauche) donne une idée des données qu’il faudra traiter et de leurs inter connexions. Le
diagramme d’activité (à droite) montre le fonctionnement du processus d’une saisie de
commande.
Acteur Système
Éditeu
= emp
~I '
oye Exemple de diagramme
Rechercher de cas d’utilisation, de
un client
diagramme entité/
Client existant
Expédition association et
Créer un client
Afficher les données
diagramme d’activité.
non Web
CLIENT client
AUTEUR
NumCli Valider les données
NumAuteur
Nom client
Nom
Adresse
Prénom[ 1-N] NumTVA[0-1] Sélectionner Calcul des frais
1 1 un article l - - - - - - - - - - - - t -71 de port
0-N 0-N
dp 0-N
$ 1-1
Confirmer
la commande
Afficher l'ensemble
de la commande
COMMANDE
1
PRODUIT Porte sur NumCommande Annuler
l-N Date la commande
NumProduit 0-N- Quantité
Port
Titre PrixUnitaire
Adresselivraison
DatePaiement
2. Diagramme de cas d’utilisation

Les diagrammes de cas d’utilisation aident les spécialistes du domaine d’application à exposer
aux informaticiens ce que doit faire le système sans se préoccuper de comment il doit le faire.
Leur formalisme est suffisamment simple pour qu’ils puissent être facilement compris et
interprétés par tous les acteurs du projet.
Définition: un diagramme de cas d’utilisation recense et décrit les scenarii d’utilisation du

système. Il précise quels sont les acteurs qui interagissent avec le système et ce qu’ils peuvent
réaliser avec le système pour atteindre leurs buts.
Les diagrammes de cas d’utilisation fixent les choix des utilisateurs au niveau des fonctions à
prévoir ou à exclure, et conditionnent l’ensemble du projet de développement. Ils méritent donc
une attention toute particulière, car des omissions ou des imprécisions à ce stade auront des
conséquences importantes par la suite.
La spécification d'un système commence par l'identification des exigences qui apportent une
valeur à l'utilisateur, et donc, par extension, qui délimitent le système. Par exemple, un manager
pourrait décider que le système à construire doit prévoir les traitements suivants : gestion du
catalogue de produits, gestion des données client, gestion des commandes et gestion des
livraisons. Cette liste exclut implicitement d'autres traitements du périmètre du système, comme
la comptabilité. Trouver un consensus auprès des utilisateurs sur les exigences n'est pas trivial, car
plusieurs facteurs sont à considérer, tels que la faisabilité, le retour attendu et le coût de
développement d'une exigence. Par exemple, certains utilisateurs défendront le développement
BDD 14
d'un système d'évaluation automatique des collaborateurs, et d'autres non. Voilà qui promet des
discussions animées sur la faisabilité d'une évaluation informatisée... Citons encore le cas d'une
exigence impliquant des traitements complexes mais rarement invoqués. Parfois, garder un
processus manuel peut s'avérer moins coûteux qu'une automatisation.
2.1. Cas d’utilisation

Un cas d'utilisation (use case) décrit le comportement du système du point de vue de l'utilisateur :
le système est vu comme une boîte noire dont on ignore le fonctionnement interne. L'exécution
d'un cas d'utilisation est généralement déclenchée par un acteur qui sollicite le système.
Un cas d'utilisation est représenté par un ovale, comme dans les exemples de l’image ci-dessous.
Rechercher Passer une commande Déposer

un article fournisseur une plainte
2.2. Acteur
Définition: Un acteur représente une entité extérieure au système et interagit avec le système.
Un acteur peut désigner un utilisateur humain ou un autre système, tel qu'un utilisateur , un
internaute, un modérateur du forum, ou un SI extérieur. Un acteur représente plutôt un rôle
qu'une personne particulière, ce qui évite de mentionner nominativement tous les utilisateurs du
système. Par contre, un même utilisateur peut assumer plusieurs rôles, et par exemple interagir
avec le système tantôt en tant qu'acteur internaute et tantôt en tant qu'acteur modérateur du
forum.
Un acteur peut soit stimuler le système en vue de la réalisation d'un traitement, comme un client
qui utilise une application e-banking pour passer un ordre de virement, soit simplement participer
à la fonctionnalité du système, comme le système bancaire qui reçoit le virement de
la même application
Un acteur est connecté à un cas d'utilisation par une association qui représente le fait que l'acteur
interagit avec le système dans le cadre du cas d'utilisation. Un diagramme de cas d'utilisation
reprend donc les acteurs, les cas d'utilisation et les associations entre les acteurs et les cas
(symbolisées par un segment de droite reliant un acteur et un cas). Il mentionne également une
désignation du système et indique la limite entre le système et son environnement, comme dans
l’image ci-dessous.
Désignation E-banking
Acteur Client banque
2.2.1. Hiérarchie d’acteurs

Les acteurs peuvent être structurés par des relations de généralisation: un acteur peut être défini
comme un cas particulier d'un acteur plus général. Par exemple, l'acteur modérateur peut être vu
comme un cas particulier de l'acteur internaute. Dans ce cas, les associations de l'acteur le plus
général sont implicitement héritées par l'acteur particulier. L’image ci-dessous montre la notation
d'une généralisation d'acteurs, symbolisée par une flèche partant de l'acteur particulier et
pointant vers l'acteur le plus général. Ici, le modérateur peut implicitement utiliser le système
BDD 15
pour poster un message sur le forum, car il hérite de ce cas d'utilisation en tant que cas particulier
d’internaute.
Forum
Poste un message sur un forum
Internaute
Image: Généralisation d’acteurs
f
Modère le forum
Modérateur
Si plusieurs acteurs sont connectés à un même cas d'utilisation, ils sont alors tous obligatoirement
impliqués dans son exécution. Dans l'exemple de gauche de l’image ci-dessous, un client et un
caissier participent tous deux à une vente au comptoir. Par contre, dans l'exemple de droite, le
client et le caissier héritent de l'association au cas vendre au comptoir, et donc soit le vendeur
seul soit le client seul (selfscanning) peut individuellement réaliser ce cas.
- - - , Vendre au comptoir
Client ----- Vendre au comptoir

Utilisateur
Caissier
Client Caissier
2.3. Structuration des cas d’utilisation

Parfois, des comportements identiques sont communs à plusieurs cas d’utilisation. Pour éviter de
décrire ces comportements plusieurs fois, UML propose un mécanisme de factorisation de cas
d’utilisation à travers des appels entre cas.
Deux types de relations permettent de relier les cas entre eux (image ci-dessous) :
• La relation include, qui signifie que le comportement d’un cas d'utilisation appelé est
systématiquement intégré dans un cas d’utilisation appelant. Cette relation est représentée
par une flèche pointillée dirigée vers le cas appelé.
• La relation extend, qui signifie que le comportement d'un cas d'utilisation peut éventuellement
être intégré au comportement d'un cas d'utilisation appelant si une certaine condition est vérifiée.
Cette relation est représentée par une flèche pointillée dirigée vers le cas appelant. La condition
est notée entre accolades et est préfixée du mot clé condition.
« include » ___.,,
--- --- -- -- -- --
Cas appelé
Condition: sous
{condition condition
d'extension}
BDD 16
Dans l'exemple de l’image ci-dessous, le cas d'utilisation passer une commande inclut
systématiquement le cas d'utilisation payer une commande, ce qui signifie qu'à un moment
donné de la saisie d'une commande, le client devra inévitablement la payer. Par contre, Le cas
d'utilisation changer d'adresse livraison peut étendre le cas d'utilisation passer une commande si
la condition si autre adresse est vérifiée.Notons qu'un cas d'utilisation appelé peut être invoqué
directement par un acteur, indépendamment des cas d'utilisation appelants, et un même cas
d'utilisation peut être appelé par plusieurs autres cas d'utilisation et vice versa.
E-shop
Payer
une commande
1
1
« include » 1
1
Passer
une commande
client
1
« extend »
1
t- - - - - - - - - - -
Condition:
1
1
{si autre adresse}
Changer d'adresse
livraison
2.4. Spécification des cas d’utilisation

Identifier les cas d'utilisation et les nommer constitue une première étape pour fixer les
fonctionnalités et les limites du système. Une description plus complète de chaque cas
d'utilisation est cependant nécessaire pour bien appréhender le comportement corres-
pondant. Par exemple, un cas d'utilisation peut être documenté en précisant les rubriques
suivantes :
• son nom ;
• les acteurs impliqués dans son déroulement;
• son objectif principal ;
• une description informelle du comportement ;
• un scénario qui décrit les interactions entre le système et son environnement selon un mode
conversationnel, c'est-à-dire un échange de stimuli émis par l'environnement et de réponses du
système.
Voici par exemple le détail d'un cas d’utilisation: Acheter des articles.
Nom du cas: Acheter des articles
Acteurs: Clients
Objectif: Saisir une vente et son paiement
Description :Un client se présente à la caisse pour régler ses achats. Le caissier enregistre les
articles choisis et encaisse le paiement du client. Finalement, le client quitte la caisse avec ses
articles.
BDD 17
Scénario:
Parfois, un scénario mentionnera des interactions qui ne concernent pas directement le système,
mais qui permettent de bien comprendre le processus d'affaires sous-jacent. Dans l'exemple
précédent, l'action 7. Le client donne les espèces au caissier ne concerne pas la
spécification du système, mais documente utilement le processus d'achat des articles.
UML n'impose pas une manière de décrire les cas d'utilisation. Le lecteur trouvera des recom-
mandations complémentaires dans la littérature dédiée. Par exemple, un cas d'utilisation peut
être détaillé avec les rubriques: nom, résumé, scénario de base, chemins alternatifs, points
d'extension, déclenchement, hypothèse, pré-conditions, post-conditions, règles métier
correspondantes, auteur et date.
Une première version du scénario va décrire un comportement «standard» du cas d'utilisation,

c'est-à-dire un processus au cours duquel les choses se déroulent de manière prévisible. Mais très
vite, il faudra considérer des situations plus élaborées qui dévient de ce comportement standard.
Dans l'exemple précédent, que se passe-t-il si un client achète plusieurs exemplaires du même
article? Ou encore, comment gérer les différents modes de paiement ? Ces exceptions au
déroulement standard sont spécifiées à l'aide de séquences alternatives ou conditionnelles.
Par exemple :
• séquence conditionnelle complémentaire à l'action 2,:

• si plusieurs exemplaires du même articles sont présentés ·
le caissier peut introduire une quantité acheté
• séquence alternative à l'action 7:
• si le client paye en espèce :
le client donne les espèces au caissier.
• si le client paye par carte :
le client introduit son code.
le système communique avec l'organisme de paiement et débite le compte du
client.
Un système est robuste s'il fonctionne correctement dans des conditions non standard. Le
système sera donc robuste quand toutes les exceptions seront identifiées et traitées.
BDD 18
2.5. Démarche de construction

Un diagramme de cas d'utilisation se construit progressivement et itérativement (en cohérence
avec la plupart des processus de développement récents). Les cas d'utilisation peuvent être
dérivés à partir d'une formulation des exigences en langage naturel ou identifiés directement.
Une fois la liste des cas d'utilisation stabilisée, ils sont détaillés à travers des scénarii de
plus en plus robustes, puis structurés avec des relations include et extend.
Voici un exemple de démarche de construction possible d'un diagramme de cas d'utilisation qui
est présentée à travers un exemple de magasin vendant des articles pour animaux, et dont voici
une brève description :
- PetShopTop vend de la nourriture et des accessoires pour animaux à des clients privés ou
professionnels. Deux modes de vente sont proposés : une vente au comptoir et une
commande Web pour les professionnels uniquement.
- Les magasiniers se chargent de la préparation des commandes et de la facturation. Ils
s'occupent du réassortiment du stock et tiennent la caisse.
- De temps en temps, des délégués commerciaux viennent en magasin pour organiser les
rayons.
2.5.1. Identifier les acteurs principaux.

Un acteur principal fait partie de la cible première du système, c'est-à-dire que c'est à son
intention que le système est construit. Dans l'exemple PetShopTop (image ci-dessous), ces
acteurs principaux sont:
• les clients, qui comptent une catégorie particulière : les clients professionnels ;
• les magasiniers qui, eux, peuvent se spécialiser en caissiers.
image: hiérarchie d’acteurs chez PetShopTop

Client particulier Magasinier
Î Î
=:lient professionnel Caissier
2.5.2. Identifier les cas d’utilisation principaux

Un cas d’utilisation est qualifié de principal quand il est associé à un acteur principal. L’image ci-
dessous montre les cas d’utilisation principaux pour le cas PetSHopTop.
PetShopTop
Vente comptoir
Client particulier
Caissier
Î
Préparation de commande
Client professionnel
Facturation
Magasinier
Réassort stock
BDD 19
2.5.3. Identifier les acteurs et cas secondaires

Un acteur est secondaire s’il n’est pas dans la cible première du système, et donc s’il n’utilise le
système que ponctuellement, comme l’administrateur d’un site Web. Chez PetShopTop, le
délégué commercial utilise le système sans en être le bénéficiaire principal.
~angement r a y ~
Délégue, corn mercial
2.5.4. Détailler les scénarii standard et les alternatives

Si les variations à un scénario standard sont trop nombreuses ou trop complexes, plusieurs
scénarii sont développés pour assurer la bonne lisibilité des exigences.
2.5.5. Structurer les cas d'utilisation.

Le détail des cas d'utilisation peut faire apparaître certaines répétitions d'un cas à l'autre, comme
des actions liées à l'identification d'un utilisateur. Plutôt que de répéter ces comportements
communs à plusieurs cas, on les factorise dans des cas appelés par des relations include ou
extend.
Dans l’image ci-dessous, le paiement par carte peut avoir lieu lors de la vente comptoir et a
toujours lieu lors de l'enregistrement d'une commande Web.
PetShopTop
Client particulier Condition Caissier

1
« extend » r--------
1
{si paieme t
1
par carte}
« include » :
Client professionnel
réparation de comm
Facturation
Magasinier
Arrangement rayons
Délégué commercial
Notons encore que :

• des priorités définies pour les cas d'utilisation serviront à délimiter le système, par exemple en
rejetant certains cas dont l'apport est trop faible par rapport à l'effort nécessaire pour développer
la fonctionnalité correspondante. Ces priorités tiennent compte de différents critères, comme
l'importance de l'apport de valeur pour les utilisateurs, l'importance de l'effort de développe-
ment (et donc du coût) ou la couverture d'exigences incontournables;
BDD 20
• le comportement décrit par un cas d'utilisation ne doit être ni trop limité, ni trop large. Par
exemple, des cas d'utilisation comme cliquer sur le bouton OK ou gérer le back office n'ont pas
une granularité idéale. Typiquement, un cas d'utilisation est détaillé en une à deux pages, mais il
n'y a pas de règle absolue en la matière.
2.6. Erreurs fréquentes

Même s’ils paraissent simples, les diagrammes de cas d’utilisation comportent souvent des
erreurs de conception et l’effort à produire pour leur conception est parfois sous-estimée.
Piège à éviter:
2.7. Exemple
Imaginons un projet de développement d’une plateforme de location d’objets. Son objectif est
de mettre en relation des locataires et des propriétaires qui souhaitent louer des objets, comme
des outils, des vêtements, ou des appareils photo.
On demande de déduire un diagramme de cas d’utilisation à partir d’exigences rédigées

préalablement en langage naturel libre.
Vu la disponibilité des exigences, le diagramme peut être construit itérativement en traitant
successivement chaque exigence (la démarche de construction exposée dans la Section 2.2.5
s’applique plutôt lorsque le diagramme de cas d’utilisation est établi sans disposer d’exigences
préalables sous une autre forme).
BDD 21
Voici chaque exigence et sa formulation sous la forme d’un diagramme de cas d’utilisation.
Exigence 1
un internaute peut consulter le catalogue des objets disponibles et éventuellement lancer une
recherche sur ce catalogue.
L’image ci-dessous montre un diagramme de départ avec un premier acteur principal et une
première utilisation du système.
Location d'objets
« extend »
Consulter le catalogue
_____ ï ____ _
Rechercher un objet
Internaute Condition:
{si recherche
selon des critères}
Exigence 2
Quand un internaute souhaite louer un objet il doit s’enregistrer sur la plateforme avant sa
première location.
Cette seconde exigence complète le diagramme avec un cas d’utilisation s’enregistrer, comme
dans la figure ci-dessous
Locat ion d'objets
« extend
_____ ï
»
____ _
Consulter le catalogue
Internaute Condition :
S'enregistrer {si recherche
selon des crit ères}
Exigence 3
Une fois enregistré, l'internaute peut, après s'être identifié, réserver un objet et le louer. Il peut
aussi laisser un commentaire sur un objet qu'il a recherché. Il devra procéder à
un paiement lors de la réservation (acompte) et de la location (solde).
Location d'objets
Cette exigence suggère une
catégorie particulière « extend »_
_ _ _ _ _ T" _ _ _ _
ulter le catal
d'internaute: le locataire, qui
Internaute
hérite des utilisations de Condition:
{si recherche
l'internaute, mais qui accède à selon des critères}
d'autres facilités.
------
L'identification, le paiement et la
recherche d'objet sont des
comportements communs à
Locataire
« include »'e-<~~~~~~-~~---
.....
certains cas d'utilisation et sont

donc représentés par de
------
« include », ,/ « .me 1ud e » __ - - S'identifier
nouveaux cas appelés par des

relations « include »
include dans l’image ci-contre. ---------------------
BDD 22
Exigence 4
Le système permet à un propriétaire de poster les données d'un objet qu'il met en location et, à
cette occasion, d'ajouter éventuellement des commentaires sur ses objets. Un propriétaire peut
laisser un commentaire sur un objet après l'avoir posté sur la plateforme.
L’image ci-dessous fait apparaître le propriétaire et son cas d’utilisation poster un objet. Le cas
laisser un commentaire sur un objet a été associé à un nouvel acteur (Utilisateur identifié) qui
généralise le propriétaire et le locataire (dont les cas d'utilisation spécifiques ne sont pas
représentés dans l’image).
Location d'objets
---------------- 1
1
1
1
Utilisateur identifié
Condition: 1
f \
1
{s'il y a __ -: « extend »
des commentaires
à formuler}
X
Locataire
X
Propriétaire
Poster un objet -----------------------
Exigence 5
Tout comme le locataire, le propriétaire doit s’enregistrer sur la plateforme et s’identifier pour
accéder à toutes ses fonctions.
L’utilisateur identifié hérite assez naturellement de l’internaute, et le cas d’utilisation lié au

propriétaire inclut le cas d’utilisation s’identifier.
Location d'objets
S'enregistrer
Internaute
f
1
1
.... 1
Utilisateur identifié 1
« include ;---- ........
? \
1
1
,: « extend »
/ 1
« include » / 1
/ 1
/ 1
I
/ 1
·· ~ --------------- -----~ --' I
I
I
Condition: I
Locataire Propriétaire I
{s'il y a
des commentaires
à formuler}
Exigence 6
L’administrateur de la plateforme gère les catégories servant à classifier les objets et modère les
commentaires sur les objets.
Finalement, le diagramme de cas d’utilisation de l’image rassemble les constructions précédentes

et ajoute l’acteur administrateur et ses deux cas d’utilisation.
BDD 23
Location d'objets
« extend »
Internaute
Condition :
S'enregistrer {si recherche :
selon des critères} « include » :
-----~
--- ---- --- ----
1
1
Utilisateur identifié -- ........ ........ «include» 1
.... 1
1
1
--- --- ---

1
1
1
1
1
« include »_,. .,.,.;,,,~:..---- .,, ....1 « extend »
.,, .,,
Locataire
_,..,.
_,,
_,,-" / / I
/ I
.,, .,,
« include » / ,,, _,, / I ..---------"'------,..
/
_,, ,,, / / I, Condition :
« includé
,,,
» /
/ I
1 {s'il y a des
1
_,,-" ,,, / / I commentaires
,,,"'"'« includé » ,' à formuler}
/ I
- - - -/ ~ - - - -I 1 - - - - - - - - - - - - - - - - - - -
/ I
Propriétaire / I
/ « include » I
I
I
I
Administrateur - - + - - - - - - ~
3. Diagramme d’activité
Les diagrammes d'activité décrivent les fonctions et la dynamique du futur système, c'est- à dire
l’ordre dans lequel les traitements sont réalisés. Ces diagrammes sont une des techniques
d'UML pour modéliser le comportement d'un système. En pratique, les diagrammes d'activité
sont souvent utilisés pour détailler ou reformuler le scénario d'un cas d’utilisation.
Définition: un diagramme d’activité décompose une fonction attendue d’un système informatique
en actions. Il montre comment ces actions s’enchaînent dans le temps et comment elles se
transmettent de l’information.
Les principaux composants d'un diagramme d'activité sont:

- des actions, qui décomposent la fonction (ou l'activité) visée par le diagramme
- des flux de contrôle, qui connectent les actions dans le temps selon une logique de
prédécesseur-successeur
- des flux d'objets, qui matérialisent les échanges d'information entre les actions. En UML,
l'information qui transite d'une action à l'autre prend la forme d'un objet
- des nœuds de contrôle, comme des branchements conditionnels;
- une localisation des actions pour préciser quelle entité (acteur, département, etc.) est censée
exécuter l’action.
Définition: Une activité est un graphe orienté dans les noeuds représentent ses composants,
comme des actions ou des noeuds de contrôle. Ces noeuds sont comme connectés par des flux
de contrôle ou des flux d’objets.
BDD 24
Un diagramme d'activité représente une activité.

Les diagrammes d'activité restent au niveau d'une description du système vu par l'utilisateur, en
ignorant son organisation interne. D'autres langages d'UML sont focalisés sur des aspects plus
techniques, et sortent du cadre de cet ouvrage. Notons que les diagrammes d'activité sont très
comparables au modèle BPMN (Business Process Model and Notation.
Cette section propose une version épurée des diagrammes d'activité, mais qui est suffisante pour
couvrir bon nombre de problèmes de gestion.
3.1. Action et flux de contrôle

Définition: une action représente une étape indivisible d’une activité
L’image ci-dessous montre la notation d'une action et quelques exemples.

Par essence, une action n'est pas décomposable en unités plus fines. Par contre, elle détaille une
activité de plus haut niveau, comme celle correspondant à un cas d'utilisation.
Une action peut désigner une opération exécutée par le système. Dans ce cas, elle modifie l'état
du système, par exemple en mettant à jour des données, ou elle renvoie de l'information sur l'état
du système, par exemple en produisant la liste de toutes les commandes ouvertes. Mais une
action peut également décrire un traitement pris en charge par un acteur humain ou un autre
système.
Notation Exemples
r r r r
"' "'
Action
Rechercher Passer ' Préparer
"'
un article un examen .une commande
\. \. '- \...
Spécifier uniquement le nom des actions n'est pas suffisant pour permettre aux informaticiens de
les programmer. Une technique usuelle consiste à décrire l'effet d'une action en termes de
postconditions, c'est-à-dire des affirmations qui doivent être vérifiées après l'exécution de
l’action.
Définition: un flux de contrôle représente une transition entre 2 actions. La fin de l’exécution
d’une action à l’origine du flux de contrôle déclenche l’exécution d’une seconde action située à
l’extrémité du flux.
Les flux de contrôle montrent donc les séquences d’enchaînement des actions dans le temps. Par
la suite, nous imposerons u’une même action ne peut accepter qu’un seul flux entrant et qu’un
seul flux sortant pour des motifs de simplification.
Notation Exem ple

.....
( ]
/
"
Action 1
] Flux de contrôle
{ Action 2
Préparer
une commande
-., Expédier
une commande
3.2. Noeud
Un diagramme d'activité composé uniquement d'actions et de flux de contrôle n'est pas
suffisamment expressif pour représenter des enchaînements complexes d'actions, comme des
répétitions ou des branchements conditionnels. UML prévoit donc des nœuds spéciaux pour
représenter de tels enchaînements.
BDD 25
Définition: Un noeud de contrôle organise des flux d’exécution d’une activité au-delà des
enchainements séquentiels
Début et fin d’activité image ci-dessous. Le nœud de début d'activité marque le démarrage de
l'activité. Le nœud de fin d'activité marque sa terminaison. UML permet de mentionner plusieurs
nœuds de début pour exprimer des séquences d'actions concurrentes. Par la suite, nous nous
limiterons à un seul nœud de début et un seul nœud de fin dans un même diagramme, toujours
pour des motifs de simplification.
Notation Exemple
Début Fin
Poster Interviewer Analyser les Sélectionner
une offre les candidats candidatures un candidat
d'emploi
3.2.1. Décision
Le nœud de décision (choice) exprime plusieurs alternatives possibles, dont une seule sera choisie
en fonction de conditions appelées conditions de garde. Dans la partie gauche de l’image ci-
dessous, après la terminaison de l'action 1, soit l'action 2 est exécutée si la condition garde 2 est
vraie, soit l'action 3 est exécutée si la condition de garde 3 est vraie. Un nœud de choix peut
comporter autant de flux sortants que l'on veut, du moment qu'ils sont assortis d'autant de
conditions de garde mutuellement exclusives.
Notation Exemple
Évaluer
Action 1 une demande
de crédit
Client
[garde 3] solvable Accorder
Action 3
Image: notation et exemple de noeuds de
le crédit
Client
insolvable
.( 2
Action
Refuser choix
le crédit .
3.2.2. Fusion
Le nœud de fusion (merge) enclenche un flux sortant dès qu'une action liée à un des flux entrants
dans le nœud est terminée. Dans la partie gauche de l’image ci-dessous, l'action 3 est exécutée
après la terminaison de l'action 1 ou la terminaison de l'action 2. Un nœud de fusion peut
comporter autant de flux entrants que l'on veut.
Notation Exemple
Fabriquer
Action 1
un article
Image: Notation et exemple de noeud

Acheter
Action 2 un article
à un fournisseur
de fusion
Expédier
Action 3 un article
3.2.3. Jointure
Le nœud de jointure (join) représente une conjonction synchronisée de flux. Dans la partie gauche
de l’image ci-dessous ,l'action 3 est exécutée après la terminaison de l’action 1 et la terminaison
BDD 26
de l'action 2 (les deux actions doivent être terminées).Un nœud de fusion peut comporter autant
de flux entrants que l'on veut.
Notation Exemple
Action 1 Expédier Envoyer

Action 2 la facture
les articles
Clôturer
Action 3
la commande
3.2.4. Bifurcation
Le nœud de bifurcation (fork) représente un déclenchement de flux de contrôle concurrents. Dans
la partie gauche de la Figure 2-30, l'action 2 et l'action 3 sont exécutées après la terminaison de
l'action 1. Un nœud de bifurcation peut comporter autant de flux sortants que l'on veut.
Notation Exemple
Action 1 Préparer
une commande
Expédier Envoyer
Action 2 Action 3
la commande la facture
Back office Front office

3.3. Partition
Une partition est un mécanisme de groupage des composants
d'un diagramme d'activité. Les partitions servent souvent à - QJ
CU
u
indiquer l'entité qui est en charge d'un groupe d'actions,
'-
QJ
E
E
comme un acteur ou un département. Les partitions peuvent u0
être dessinées horizontalement et/ou verticalement, comme
C
0
+-'
Vl
dans l’image ci-dessous. l9

QJ
L’image ci-dessous montre un exemple de diagramme

QJ
C'"
·.p
Vl
Client Département vente Département logistique Cl
0
.....J
Envoyer Réassortir
une commande le stock
d’activité décrivant un processus de
Stock traitement d’une commande. Les actions
Enregistrer suffisant
la commande sont réalisées soit par le client, soit par le
département vente, soit par le
Payer
la commande Préparer
la commande
département logistique. Après renvoi
d’une commande par le client, deux flux
Recevoir Expédier
d'exécution parallèles sont enclenchés: le
paiement du client et le traitement de la
la commande la commande
commande par les deux départements. En
BDD 27
cas de rupture de stock, le département logistique réassort le stock. La commande ne peut être
expédiée qu’après son paiement et sa préparation.
3.4. Flux d’objet, interruption et zone d’expansion

Les constructions présentées constituent un ensemble de base qui permet de décrire
assez simplement des activités courantes dans le domaine de la gestion. UML en prévoit
cependant bien d'autres dont quelques-unes seront brièvement présentées ci-dessous. Le
lecteur se tournera vers la littérature spécialisée pour appréhender l'ensemble des notations.
3.4.1. Flux d’objet

Un flux d'objet représente un transfert de
données entre deux actions et un flux de
Enregistrer
Expédier
la commande contrôle implicite. Un objet est caractérisé
une nouvelle par un état, et cet état peut être modifié
commande
par une action. Les flux d'objet servent,
Commande
Commande [expédiée] entre autres, à décrire le cycle de
[placée]
traitement d'une entité, comme une
Commande
[préparée]
commande, un article ou une plainte. Dans
Facturer
Valider
la commande la commande l’exemple ci-dessous, un objet est
représenté par un rectangle dont le libellé
Commande
mentionne son nom et son état (entre
Commande
[validée] [facturée] crochets). Ici, un objet commande est
transmis entre différentes actions qui
Préparer s'enchaînent en modifiant successivement
la commande
son état de placée à facturée.
3.4.2. Interruption
Une zone interruptible est une partie délimitée du diagramme d'activité qui englobe un groupe
d'actions. L'exécution d'une zone interruptible peut être arrêtée lorsqu'un événement donné se
produit. Après interruption, un flux de contrôle est dirigé en dehors de la zone interruptible pour
exécuter des actions ad hoc. Par exemple, une activité de commande en ligne peut être
abandonnée à tout moment par le client s'il quitte le site de vente. Dans ce cas, un traitement
spécifique est exécuté, par exemple pour annuler la commande qui était en cours avant
l'interruption. L’image ci-dessous illustre cette situation, en délimitant la zone interuptible par des
pointillés, et en indiquant l'événement provoquant l'interruption (abandon) par un rectangle
biseauté à droite.
3.4.3. Zone d’expansion

Une zone d'expansion est une partie délimitée du diagramme d'activité qui peut être exécutée
plusieurs fois en séquences itératives ou parallèles. L'exécution d'une zone d'expansion peut
consommer des objets entrants et produire des objets sortants. Par exemple, une zone
d'expansion englobant des actions pour traiter une demande de prêt peut être répétée autant de
fois qu'il y a de demandes à traiter.
------------------------------ ------------- --------- '
1
1
Remplir Saisir Payer 1
S'identifier le panier l'adresse la commande 1
1
1
1 d'articles de livraison 1
1 1
1 1
1 1
1 1
1 Abandon 1
1 1
---------------- - - _.,
1 J
'------------------
BDD Annuler 28
la commande

L’image ci-dessous évoque quelques erreurs communément commises dans les diagrammes
d'activité :
• des acteurs sont mentionnés en tant qu'actions, comme l'action v e n d e u r qui n'en est
pas une;
• des conditions de garde sont formulées en tant qu'actions, comme les actions si mon-
tant supérieur à l000 et si montant inférieur à 1000;
• des conditions de garde liées aux flux sortants d'un même nœud de choix ne sont pas
mutuellement exclusives. Par exemple, si montant supérieur à 1000 et si montant
inférieur à 1200 se recouvrent;
• des actions restent sans flux sortant, comme accorder une réduction.
Vendeur Créer Mentionnons encore l'omission du sens des flux, qui

une vente
rend vite le diagramme incompréhensible
Si montant Si montant
supérieur à 1 000 inférieur à 1 200
ccorder Imprimer
une réduction la facture
3.6. Exemple
Pour illustrer les digrammes d'activité, imaginons le cas d'un détaillant d'articles de sport qui
souhaite représenter un processus de prise de commande sur le Web. Le diagramme d'activité
correspondant va être construit en traitant progressivement chaque exigence d'un énoncé en
langage naturel.
Exigence 1
le système affiche une page d'accueil à partir de laquelle un internaute peut choisir une rubrique
de produits en s'identifiant éventuellement au préalable. Une rubrique correspond à un sport,
comme une rubrique tennis ou une rubrique jogging.
Pour commencer, l'internaute peut naviguer vers une rubrique de son choix après une éventuelle
identification. On a décidé de ne pas indiquer de partition vu la nature du problème, comme le
montre l’image ci-dessous.
Veut s'identifier S'indentifier
image: commande Ne veut pas

web- identification s'identifier
Afficher page accueil
Choisir
rubrique
BDD 29
Exigence 2
Au sein d'une rubrique, l'internaute sélectionne un ou plusieurs articles à commander.
Naturellement, les articles proposés sont ceux de la rubrique.
Après avoir précisé une rubrique, l'internaute peut choisir autant d'articles à commander au sein
de cette rubrique qu'il le souhaite. L’image ci-dessous indique donc une boucle sur l'action choisir
article (la boucle est indiquée sur la figure mais est hors formalisme UML).À ce stade, cette boucle
reste incomplète car il n'y a pas encore de moyen d'en sortir.
S' i ndentifier
image: commande web- choix

d’articles
Choisir Choisir
rubrique article
Exigence 3
L’internaute peut naviguer vers d’autres rubriques pour sélectionner d’autres articles à
commander. L’image ci-dessous introduit une seconde boucle pour répéter l’action choisir
rubrique.
S'indentifier
Ne veut pas
s'identifier
Choisir Choisir
rubrique article
Autre
article
Autre
rubrique
Exigence 4
Quand l'internaute a sélectionné tous les articles qu'il veut commander, et s'il ne souhaite plus
consulter d'autres rubriques, le système lui montre alors le récapitulatif de sa commande et l'invite
à s'identifier si ce n'est déjà fait. L'internaute clôture la transaction en confirmant la commande.
La sortie de la seconde boucle enchaîne sur le récapitulatif de la commande. Dans l’image ci-
dessous l'internaute clôture la transaction en cas d'identification en début de commande et
l’activité prend fin.
BDD 30
S'indentifier
Déja
identifié
Clôturer
transaction
Choisir Choisir
rubrique article
Autre
article
Autre
rubrique
Récapituler
Pas d'autre rubrique commande
Par contre, si l'internaute ne s'est pas identifié en début d'activité, il doit le faire avant de clôturer
la transaction. L’image indique qu'après l'identification:
• soit la transaction peut être clôturée si une commande est en cours de réalisation ;
• soit on est au début de l'activité et le flux d'exécution est dirigé vers les choix de rubriques et
d'articles. Pas identifié
S'indentifier
Commande
en cours
Clôturer
transaction
Choisir Choisir
rubrique article
Autre
article
Autre Pas d'autre

rubrique article
Récapituler
Pas d'autre rubrique commande
4. Diagramme entité/association
Les systèmes informatiques développés pour les métiers de gestion sont majoritairement orientés
vers les données. Le langage entité/association a pour finalité de cerner les données
nécessaires aux différents processus d’affaires.
Définition: un diagramme entité/association (E/A) décrit les structures des données utiles pour
l’utilisateur. Il spécifie la nature des liens entre les données ainsi que les contraintes qui
conditionnent leur validité
Le diagramme E/A complète les diagrammes dédiés aux traitements en précisant les données qui
font l'objet de ces traitements. Rappelons qu'un même système informatique est
BDD 31
traditionnellement décrit sous plusieurs angles complémentaires à cause de sa complexité. Les

différentes descriptions du système doivent rester mutuellement cohérentes. Par exemple, un
diagramme d'activité doit décrire des traitements qui portent sur des données décrites dans le
diagramme E/A correspondant.
4.1. Entité
Un système informatique devra bien souvent gérer de l'information à propos d'objets du domaine
d'application. Plutôt que de s'intéresser à chaque objet en particulier, on va raisonner en termes
de groupes ou de classes d'objets similaires.
Définition: une entité représente un ensemble d’objets du domaine d’application qui présentent
des caractéristiques semblables.
Les objets sont donc représentés par une entité, dont ces objets sont des instances. Par exemple,
l’image ci-dessous montre comment les objets Citroën 2CV, Fiat 600 et Ferrari F40 peuvent être
schématisés à travers une entité Voiture. Toutes les voitures sont caractérisées par un modèle, une
année, une cylindrée et un nombre de portes. Ces caractéristiques sont appelées attributs de
l'entité (cf. Section 2.4.3). Chaque instance de l'entité Voiture possède des valeurs particulières
pour ces attributs. Par exemple, l'attribut c y l i n d r é e de l’instance Citroën 2CV a comme valeur
650.
Voiture
modèle Entité
année
cylindrée
nombre de portes
Citroën 2CV Fiat 600 Ferrari F40 Instances

1948 1964 1989
650 600 4800
4 2 2
Le fait de ne retenir que certains attributs pour des objets modélisés par une entité est un cas
typique d'abstraction. Le choix de ces attributs dépend des exigences du domaine d'application.
Par exemple, le système d'information d'une entreprise va gérer, pour une personne employée,
les attributs nom, prénom, salaire, fonction, etc., alors qu'un hôpital retiendra, pour la même
personne, les attributs nom, prénom, groupe sanguin, âge, et taille.
En fait, de nombreux mécanismes d'abstraction sont implicitement appliqués pendant la
modélisation. Plus généralement, l'abstraction est un processus mental selon lequel nous
établissons une certaine perception de la réalité sans en considérer tous les détails.
De la même manière, considérer une classe d'objets plutôt que ses instances permet de se
concentrer sur les propriétés de la classe tout en ignorant les particularités de ses instances. Le
mécanisme d'abstraction à l'œuvre ici s'appelle la classification.
4.2 Association
Les objets du domaine d'application sont naturellement reliés entre eux. Les associations
représentent leurs liens.
BDD 32
Définition: une association binaire schématique une correspondance entre 2 entités, et représente
l’ensemble des liens entre leur instances.
Par exemple, considérons deux entités Personne et Ville. Le fait qu'une personne habite une ville
est modélisé par une association binaire habite, qui lie une personne à une ville et vice versa,
comme illustré par l’image ci-dessous. Un lien entre une personne et une ville est une instance de
l'association habite. Les liens d'une association vers des entités peuvent être facultativement
libellés pour une meilleure compréhension du diagramme.
....
Personne Ville
nom 1- 1 ( habite }-o-N nom

prénom code postal
I I 1
date de naissance I
I 1
1
1
1
I
1 1
I
I
1 1 est instance de
I I 1
I 1 1
I I 1
I I 1
I 1 1
I I 1
Paul 1
1
1
8
1
1
1
1
1
1
1
1
1
1
Luc
4.2.1. Cardinalités.
Les associations sont caractérisées par des contraintes portant sur le nombre d’instances
connectées par cette association. Ces contraintes sont appelées cardinalités et sont notées entre
crochets au niveau de l'arc reliant l'association à l'entité. Dans l'exemple précédent, une personne
habite dans une et une seule ville, comme Paul qui habite à Bruxelles. On indiquera alors une
cardinalité minimale (ici 1) et une cardinalité maximale (également 1) exprimant respectivement le
nombre minimum et le nombre maximum d'instances de Ville auxquelles Paul, une instance de
Personne, peut être lié via habite. Inversement, une instance de Ville est reliée à minimum aucune
instance de Personne (soit une cardinalité minimale de O), et si le maximum de connexions vers
des personnes pour une ville donnée n'est pas déterminé, on indiquera une cardinalité maximale
N.
Le nombre d'instances réellement connectées doit être compris entre la cardinalité minimale et la
cardinalité maximale. Par exemple, Paul ne peut pas habiter dans deux villes, mais B r u x e l l e s
peut compter n'importe quel nombre d'habitants.
Notons que par convention, les cardinalités placées sur l'arc reliant une entité et une association
portent sur le nombre de connexions possibles entre une même instance de cette entité et des
instances de l'autre entité connectée à l'association. Ainsi, dans la Figure 2-47, les cardinalités 1-1
entre Personne et habite répondent à la question suivante: une même personne peut être reliée à
combien de villes au minimum et au maximum ?
4.2.2. Associations entre deux mêmes entités.

Deux mêmes entités peuvent être reliées par plusieurs associations. Par exemple, on pourrait
avoir deux associations, travaille à et h a b i t e reliant chacune P e r s o n n e et V i l l e .
BDD 33
4.2.3.Attributs d’association
Une association peut être caractérisée par des attributs, au même titre que les entités. Par
exemple, s'il faut gérer le fait qu'une personne habite une ville depuis une certaine date, alors
l'association habite de l’image ci-dessous comportera un attribut date d'installation.
habite
date d'installation
Personne est un habitant a des citoyens
1-1---- --0-N Ville
nom
prénom nom
date de naissance code postal
0-N 0-N
travaille à
4.2.4. Cycle
Une association est cyclique quand elle lie une entité à elle-même, c'est-à-dire quand les
instances d'une même entité sont liées entre elles. Dans ce cas, on peut expliciter les deux rôles
joués par l'entité dans l'association cyclique. Par exemple, l’image ci-dessous représente des
produits qui sont associés à d'autres produits dans des kits. Un produit peut être le composant
de maximum un autre produit, mais un produit peut être composé d'un nombre indéterminé de
produits. Un produit entre dans la composition d'un autre produit à concurrence d'une certaine
quantité. Pour être tout à fait complet, il faudrait annexer le diagramme en précisant qu'un
produit ne peut pas être son propre composant. Comme autres exemples d'associations
cycliques, citons des personnes qui seraient reliées entre elles par un lien de subordination
hiérarchique, ou encore des sociétés liées à des sociétés filiales.
est composant de
Produit 1-1
kit
libellé
quantité
prix de vente
se compose de
0-N
Notons encore quelques précisions complémentaires sur le concept d'association.
4.2.5. Associations n-aire.

Le modèle ElA autorise des associations connectant plus que deux entités. Une association
ternaire en connecte trois, une association quaternaire quatre, et ainsi de suite. Plus
généralement, une association n-aire (n > 2) établit une correspondance entre n entités. En
pratique, les associations d'arité supérieure à 2 sont difficiles à appréhender. Dans une volonté de
simplification, elles ne seront pas utilisées par la suite.
4.2.6.Définition complète de la cardinalité minimale.

Soit une association A entre les entités E1 et E2. La cardinalité minimale de E1 dans A est le
nombre minimum de correspondances de chaque instance de El avec des instances de E2. On la
note min-card(El, A).
Les cardinalités minimales peuvent prendre toutes les valeurs entières positives, mais certaines
valeurs sont remarquables. Par exemple :
• min-card (personne, habite) = 1 signifie que toute personne doit habiter dans au moins une ville
(participation obligatoire dans l'association) ;
• min-card (personne, habite) = 0 signifie qu'une personne peut habiter dans une ville ou pas
(participation facultative dans l'association).
BDD 34
4.2.7. Définition complète de la cardinalité maximale

Soit une association A entre les entités E l et E2. La cardinalité maximale de E1 dans A est le
nombre maximum de correspondances de chaque instance de El avec des instances de E2. On
la note max-card (El, A).
Les cardinalités maximales peuvent prendre toutes les valeurs entières positives, du moment que :
max-card(E, A) >= min-card(E, A) et max-card(E, A) > O.
Certaines valeurs sont remarquables :

• max-card (personne, habite) = 1 signifie que toute personne habite au maximum dans
une ville;
• max-card (personne, habite) = N signifie qu’une personne peut habiter dans autant de
villes que l’on veut.
Certaines combinaisons de valeurs sont remarquables :

• si max-card(El, A) = 1 et max-card(E2, A) = 1, alors l’association est dite un à un;
• si max-card(El, A) > 1 et max-card(E2, A) > 1, alors l’association est dite plusieurs à plusieurs ;
• si max-card(El, A) = 1 et max-card(E2, A)> 1, alors l’association est dite un à plusieurs.
4.3. Attribut
Le concept d'attribut a déjà été introduit dans la Section 2.4.l comme étant une caractéristique
d'une entité.
Définition: un attribut modélise une propriété élémentaire d’une entité ou d’une association, et
pour laquelle les instances peuvent prendre une ou plusieurs valeurs
4.3.1. Cardinalité
Un attribut possède une cardinalité minimale et une cardinalité maximale, qui précisent
respectivement le nombre minimum et le nombre maximum de valeurs qu'il peut prendre pour
une instance donnée. Les cardinalités sont notées entre crochets derrière le nom de l’attribut.
L’image ci-dessous fournit quelques exemples représentatifs:

• l'attribut prénom [0-1] : la cardinalité minimale signifie que l'attribut peut ne pas avoir
de valeur pour une instance donnée. Il est donc optionnel. La cardinalité maximale est 1 ,
soit une seule valeur. L'attribut est dit monovalué;
• l'attribut téléphone [0-5] : il est optionnel, et sa cardinalité maximale autorise plusieurs valeurs (5
en l'occurrence). L'attribut est dit multivalué;
• l'attribut adresse [1-3] : sa cardinalité minimale est supérieure à 0, il est donc obligatoire. Il est
aussi multivalué ;
• l'attribut date de contact [0-N] est optionnel et multivalué, et sa cardinalité maximale N signifie
qu'il peut avoir autant de valeurs que l'on veut pour une instance donnée.
Par convention, les cardinalités d'un attribut prennent la valeur par défaut [l-1] quand elles ne sont
pas spécifiées.
4.3.2.Composition.
Un attribut composite est constitué d'un groupe d'attributs ayant des affinités fonctionnelles, mais
ne justifiant pas la création d'une entité. L'attribut composite offre un niveau de détail
supplémentaire dans la description de l'entité ou de l'association. Un exemple
BDD 35
classique est l'attribut adresse de l’image ci-dessous, constitué des attributs rue, numéro, code
postal, localité et pays.
Client
numéro
nom
Article
prénom[0-1]
téléphone[0-5] achète
famille
date de contact[O-N] --0-N date t---1-1--..
numéro
adresse[1-3] remise libellé
rue prix
numéro
code postal
localité
pays
4.3.3. Identifiant
En général, chaque instance d'une entité se différencie des autres par une valeur d'un attribut
identifiant Dans l’exemple de l’image ici au dessus , chaque client possède un numéro unique.
L'attribut numéro joue donc le rôle d'identifiant pour Client, ce qui est représenté en le
soulignant.
La notion d'identifiant contribue à comprendre la vraie nature d'une entité, en spécifiant précisé-
ment ce qui distingue les instances entre elles. De plus, l'identification des instances est
primordiale pour une future implémentation dans une BD relationnelle (Section 3.4) :
l’identification dans ces systèmes se fait par les valeurs, c'est-à-dire que l'utilisateur fournit lui-
même les don- nées permettant l'identification.
Le choix des identifiants n'est pas toujours aisé, surtout lorsque le domaine d'application ne
fournit pas spontanément d'identifiant naturel. Dans ce cas, on introduit des identifiants tech-
niques, c'est-à-dire sans signification réelle pour l'utilisateur, comme des numéros séquentiels.
4.3.4.Composition de l'identifiant
Un identifiant peut être composé de plusieurs attributs. Par exemple, une instance d’Article, est
identifiée par la combinaison d’une valeur de l'attribut famille et d'une valeur de l'attribut numéro.
Les deux attributs de l’identifiant sont alors soulignés.
4.3.5. Domaine
On peut également indiquer le domaine d'un attribut, à savoir l'ensemble de ses valeurs
permises. Par exemple:
• le domaine de l'attribut code postal est l'ensemble des nombres entiers compris entre 1 000 et
9 999 ;
• le domaine de l’attribut salaire est l’ensemble des nombres réels compris entre 500 et 10000.
4.3.6.Attribut dérivé 
Un attribut est dit dérivé lorsque sa valeur peut être obtenue en combinant les valeurs d'autres
attributs. Par exemple, l'âge d'une personne peut être calculé sur la base de sa date de naissance
et de la date du jour.
BDD 36
4.4. Généralisation/spécialisation
L'association constitue un premier mécanisme pour conne~ter les entités entre elles. La
généralisation/spécialisation est un second moyen de relier des entités mais avec une logique de
catégories.
Imaginons par exemple qu’une entreprise doive gérer des données sur ses clients, ses prospects
et ses employés, comme dans l’image ci-dessous.
Ces entités peuvent être généralisées par une entité Personnes, comme les montre l’image ci-
dessous. Un triangle relie les entités à généraliser vers une nouvelle entité plus générale, et qui
est connectée par un trait en gras.
Personne
Client
Employé
numéro
numéro
nom
nom
prénom Prospect prénom
date de contact[O-N]
numéro adresse
téléphone
nom salaire
prénom
consentement e-mailing
e-mail
Les entités Client, Prospect et Employé sont alors vues comme des catégories de Per- sonne, et
leurs instances sont aussi des instances de Personne.
Dans cette configuration, les attributs communs aux catégories seront« remontés» vers l'entité
plus générale, ce qui simplifie le diagramme puisqu'ils ne seront plus spécifiés qu'une seule fois,
comme dans l'exemple de l’image ci-dessous. Un mécanisme d'héritage implicite assure que
les attributs de Personne seront hérités par Client, Prospect et Employé. Cet héritage porte aussi
sur les associations et les identifiants.
Personne
numéro
nom
prénom
Client Employé
date de contact[O-N] adresse

téléphone salaire
Prospect
e-mail
L'exemple précédent a montré comment des entités semblables ont été généralisées. À l'inverse,
voyons comme une entité pourrait faire l'objet d'un raffinement en catégories plus détaillées.
BDD 37
Dans l’image ci-dessous, une entité Article apparaît en premier lieu avant d'être spécialisée en
deux catégories: Article Food et Article Non-Food. Les attributs communs aux catégories restent
au niveau de A r t i c l e , et sont implicitement hérités par les catégories, alors que les attributs
spécifiques sont placés au niveau des catégories.
Article
héritage
numéro
Article libellé
prix de vente
numéro
libellé
prix de vente
garantie
date de péremption
Article Food Article Non-Food

date de péremption garantie
catégories
Définition: La généralisation/spécialisation est un mécanisme de liaison entre une entité et

d’autres entités plus spécifiques avec une sémantique de catégorie. Les caractéristiques de cette
entité sont héritées par les entités les plus spécifiques.  
 
Notons que l'entité la plus générale est appelée généralisation, et les entités-catégories sont
appelées spécialisations, à ne pas confondre avec les mécanismes du même nom.
4.4.1.Propriétés
Une structure de généralisation/spécialisation est caractérisée par deux propriétés qui annotent le
diagramme :
• disjoint versus avec recouvrement : dans le cas disjoint, il n'existe pas d'intersection entre les
populations des spécialisations. Autrement dit, une instance ne peut pas appartenir à plus d'une
spécialisation. Par exemple, une personne ne pourrait pas être à la fois prospect et client. Dans
le cas avec recouvrement par contre, les catégories possèdent des instances en commun,
comme un employé qui pourrait aussi être client ;
• total versus partiel : dans le cas partiel, il peut exister des instances appartenant à la
généralisation, mais n'appartenant à aucune de ses spécialisations. Par exemple, il existerait des
personnes qui ne sont ni client, ni prospect, ni employé, comme des auditeurs externes. Dans le
cas total par contre, toutes les personnes sont nécessairement reprises dans au moins une des
catégories Client, Prospect ou Employé.
Par exemple, l’image ci-dessous indique que toutes les personnes sont reprises dans les
catégories, et que ces catégories n’ont pas d’intersection.
Personne
numéro
nom
prénom
Client Employé
date de contact[O-N] adresse

téléphone salaire
Prospect
e-mail
BDD 38
Plusieurs niveaux de généralisation / spécialisation sont possibles. On obtient alors des arbres de
généralisation / spécialisation, comme celui ci-dessous.
Article
héritage
numéro
Article libellé
prix de vente
numéro
libellé
prix de vente
garantie
date de péremption
Article Food Article Non-Food

date de péremption garantie
catégories
4.5. Contrainte
Définition: une contrainte d’intégrité est une propriété sue les données doivent satisfaire en toute
circonstances.
Les contraintes imposent aux utilisateurs des règles incontournables qui visent à garantir un
niveau de qualité des données. Le modèle E/A autorise plusieurs types de contraintes d'intégrité,
comme celles liées :
• à un identifiant, dont les valeurs doivent être uniques ;
• aux cardinalités d'association, qui imposent des obligations et des limites dans les connexions
entre des instances;
• aux cardinalités d'attribut, qui contrôlent le nombre de valeurs d'un attribut;
• à la généralisation/spécialisation, dont les propriétés régissent l'appartenance d'instances aux
entités spécialisées ;
• au domaine d'un attribut, qui définit un ensemble de valeurs valides pour cet attribut.
Cependant, d'autres types de contraintes d'intégrité peuvent être formulés par les utilisateurs,
sans pouvoir être exprimés par le modèle E/A, dont l'expressivité trouve ici ses
limites. Ces contraintes seront alors annexées à un diagramme E/A et formulées soit en
langage naturel, soit avec des langages formels ad hoc. Ces contraintes peuvent porter entre
autres sur:
• les valeurs des cardinalités d'association. Par exemple, on ne peut associer davantage
d'étudiants à un cours que le nombre de places disponibles dans l'auditoire où se donne le cours;
• la complétude des instances d'une entité. Par exemple, tous les codes postaux d'un pays
doivent être repris dans une entité code postal ;
• les modifications permises des données. Par exemple, on ne peut pas réduire le salaire d'un
employé.
4.6. Démarche de construction

En pratique, un digramme ElA est élaboré progressivement, par exemple en intégrant
successivement les différentes exigences des utilisateurs. Le choix de la démarche de construction
sera déterminé, comme souvent, par les particularités du domaine d’application ainsi que
l’implication et le profil des utilisateurs.
BDD 39
Une discussion détaillée sur les différentes stratégies et méthodes de construction, d’un
diagramme E/A dépasse le cadre de cet ouvrage.

Les pièges ne manquent pas dans le modèle ElA.
Tout d'abord, on restera particulièrement attentif à représenter un seul concept au sein d'une
entité. Un exemple classique est la localisation d'informations relatives à un département au
niveau d'un employé. Dans la partie gauche de l’image ci-dessous, l'entité Employé contient deux
attributs, nom département et adresse, qui décrivent le concept de département plutôt
que celui d'employé.
Cette représentation est malheureuse car il faudra spécifier la même adresse pour tous les
employés d'un même département, avec toutes les redondances que cela entraîne. Le
diagramme de la partie droite de la Figure 2-57 évite ce problème en distinguant les concepts
d'employé et de département, ce qui permet notamment la représentation naturelle d'un
département qui ne compterait aucun employé.
La transformation d'un diagramme susceptible d'amener des redondances en un diagramme sans
redondance fait partie d'une démarche plus générale de validation d'un diagramme appelée
normalisation.
Employé
matricule Employé
nom employé matricule Département
prénom nom employé r---1-1 travaille dans 0-N- nom département
fonction prénom adresse
nom département fonction
adresse
Ensuite, on évitera une application malheureuse des concepts du modèle E/A, comme dans
l’image ci-dessous
• l'utilisation du mécanisme de généralisation/spécialisation pour relier des entités qui n'ont
pas de lien de catégorie, comme Employé et Facture qui ne sont pas des catégories de
Commande;
• la mention d'un attribut faisant référence à une autre entité, comme l'attribut numCli de
Commande, qui veut indiquer erronément qu'une commande est liée à un client, ce qui est déjà
exprimé par l'association passe.
Finalement, on n'oubliera pas de mentionner complètement les identifiants, les cardinalités ou les
propriétés des structures de généralisation/spécialisation.
Client
numCli l~L~tdentifiant mar, qu~ "'+Ji--){~: nu~~~~ck )
nom
0-N 0-N
Référence
(pafse) (co+en9
1-1 1-1
vers ·le client
superflue Commande Article
numCom
date
1-N-fa'--1_1 DetailCommande
quantité 1_1.. ~pour, _ 9~_,,' d
mo èle
nümëir--,, quantité en stock
' ...
-----
' ... ----__________._
Brico Electro
.._,
le """,,
Q~antité en sto_ç:k
BDD 40
4.8. Exemple
L'exemple qui suit porte sur la construction progressive d'un diagramme E/A pour une entreprise
de formation. Chacune des exigences de l'énoncé est intégrée progressivement au diagramme en
cours.
Exigence 1
une entreprise de formation organise des séminaires pour des participants. Cette proposition a
priori anodine amène déjà plusieurs questions :
• Faut-il une entité correspondant à l'entreprise de formation? On décide que non, en
argumentant du fait que le système sera développé pour cette entreprise, mais qu'il ne faudra
pas gérer des données sur l'entreprise elle-même. De plus, il n'y aurait qu'une seule instance
pour l'entité correspondante.
• Combien de participants peuvent suivre un même séminaire ? On peut raisonnablement
supposer qu'un séminaire peut ne pas compter de participant, par exemple au moment de sa
planification, mais rien n'indique le nombre maximum de participants pour un séminaire. Ce
nombre est donc considéré comme indéterminé, et les cardinalités entre l'entité Séminaire et
l'association est donné pour sera 0-N, comme dans l’image ci-dessous.
• Un participant doit-il être rattaché à au moins un séminaire pour exister dans le système? On
peut supposer que oui, d'où la cardinalité minimale de 1 entre Participant et est donné pour.
\ Séminaire \1----Q-N--------1(est donné pou~---1 -N - -\ Participant 1
Exigence 2
un séminaire possède un intitulé unique, une durée et un prix.
Exigence 3
un participant est décrit par un email unique, un nom, un prénom et une adresse.
Ces deux propositions détaillent les attributs de Séminaire et de Participant et fournissent leurs
identifiants. Rappelons que les cardinalités par défaut de tous les attributs sont 1-1 (monovalué et
obligatoire).
Participant
Séminaire email
intitulé t----0-N--.(est donné pou~...---1-N---. nom
du rée prénom
pnx adresse
Exigence 4
un séminaire donne lieu à plusieurs sessions, chacune possédant un numéro unique et une date
de début.
Cette proposition introduit la notion de session et implique de rattacher les participants à une
session plutôt qu'à un séminaire. De toute façon, une session se rapporte à un et un seul
séminaire, et donc le lien entre participant et un séminaire peut être retrouvé indirectement.
Le calendrier des sessions impose une contrainte additionnelle qui ne peut être exprimée
directement avec le langage E/A : un participant ne peut pas être lié à des sessions qui se
chevauchent dans le temps. De telles contraintes sont habituellement annexées au diagramme.
Participant
Séminaire
Session email
intitulé ~ o - N ~ 1 - 1 - numéroSession - 0 - N ~ 1 - N - no!11
durée ~ - date de début prenom
pnx adresse
BDD 41
Exigence 5
une session d'un séminaire a lieu dans un même local, lui-même décrit par un numéro de local, un
nombre de places et plusieurs équipements éventuels.
Exigence 6
un séminaire est animé par un ou plusieurs conférenciers, dont il faut connaître le numéro unique,
le nom et le prénom.
Dans l’image ci-dessous on notera l'attribut multivalué équipement et la contrainte additionnelle
suivante : un conférencier ne peut animer plus d'une session en même temps.
Participant
Séminaire
Session email
intit,ulé '-Ü-Nfdonne lieu à"\_1-1- nu méroSession ,-Q-N-(est donné pour)--1-N- nom
duree '.F prénom
date de début
pnx adresse
o!N
animé par donné dans
Conférencier Local
numéro numérolocal
prénom nombre de places
nom équipement[O-N]
Comme les conférenciers et les participants sont des personnes, les entités correspondantes
peuvent être généralisées. Moyennant l'hypothèse qu'un conférencier peut aussi suivre des
séminaires en tant que participant, la généralisation-spécialisation sera avec recouvrement.
Attention cependant aux contraintes additionnelles que cela engendre : un participant ne peut
suivre un séminaire qu'il anime lui-même, et l'email d'un participant est unique.
L’image ci-dessous détaille la solution complète correspondante. La généralisation n'est pas
explicitement suggérée par les exigences, mais elle a du sens dans une démarche d'optimisation
du diagramme.
Personne
numéro
prénom
nom
( animé par)1 - - - - - - - -0-N - - ~ _C_o_n_fé_r_

en_c_ie_r___,~----,--------1
. , - total, recouvrement
1 lN
1
Séminaire Participant
Session
intitulé >- 0-N{donne lieu à)-1-1 numéroSession 0-N-(est donné pout)-1-N email
durée · date de début adresse
prix
0-N
donné dans
Local
numérolocal
nombre de places
équipement[O-N]
BDD 42
5. Conclusion
Nous avons présenté trois langages de modélisation graphique pour formuler les exigences des
utilisateurs et décrire le fonctionnement d'un futur système informatique de leur point de vue.
Premièrement, les diagrammes de cas d'utilisation représentent les acteurs qui vont interagir avec
le système ainsi que les scénarii d'utilisation. Ces diagrammes sont souvent utilisés en début de
projet de développement et guident les phases en aval, en suggérant une découpe des
fonctionnalités.
Pour le manager, un diagramme de cas d'utilisation est un outil simple et abordable qui fait
émerger une vue abstraite du système, c'est-à-dire débarrassée de tout détail technique. Le dis-
cours est orienté vers les fonctionnalités (le « quoi ») et non vers la manière de réaliser le système
avec les technologies digitales. Le manager peut donc se concentrer sur l’optimisation des
processus d'affaires et leur automatisation.
Deuxièmement, les diagrammes d'activité portent sur la modélisation des processus , qu’ils
fassent l'objet d'une automatisation ou non. Ils peuvent être utilisés pour détailler les processus
annoncés par les cas d'utilisation. Le manager utilisera cette technique pour décomposer des
enchaînements complexes d'actions.
Troisièmement, les diagrammes E/A décrivent les structures de données utiles pour les
utilisateurs. Ils cernent l'aspect informationnel du futur système, qui a toute son importance en
informatique de gestion. Les managers y répertorient les données qui font l’objet des traitements
spécifiés par les cas d'utilisation.
L'élaboration de ces diagrammes est une tâche délicate et créative, car il s'agit de représenter un
futur système immatériel. L'enjeu est important, car ces représentations vont conditionner la
construction proprement dite du système, et leurs défauts et manquements s’amplifieront dans la
suite du développement. Les utilisateurs et les informaticiens seront donc particulièrement
attentifs à la gestion de la qualité à ce stade, en cherchant à produire des diagrammes :
• d'un niveau d'abstraction approprié, en omettant les détails non pertinents> tout en étant
complets par rapport à leur objectif;
• compréhensibles par eux-mêmes;
• précis, et donc exempts d'ambiguïtés ou de redondances.
Sur la base des exigences des utilisateurs, les informaticiens vont développer un système
informatique adapté en mettant en action les technologies digitales. E~ informatique de gestion,
une de ces technologies, les bases de données, est particulièrement importante. Elle sera
abordée dans le prochain chapitre.
BDD 43
Chapitre 3: Base de données
1. Définitions et applications
Base de données (BD). Un système informatique est la partie du système d'information qui traite
les données numériques ou digitales. Une partie de ces données sont dites structurées, dans le
sens où elles respectent une structure régulière. Par exemple, les données concernant chaque c l i
e n t sont toutes organisées selon un même schéma reprenant un nom, une adresse, un email et
un numéro de TVA. Les données structurées sont généralement enregistrées dans une BD.
Information
Système
d'information
Données
numériques
Système
informatique
Données
structurées
SGBD
Définition : une base de données (BD) est une collection de données essentiellement structurées
Par exemple, la BD d’une entreprise de formation rassemble des données sur les formations
qu’elle propose, sur les participants qui suivent ces formations ou sur les conférenciers qui les
animent. En l’occurrence, les spécifications de données du diagramme E/A peuvent être
matérialisées par une BD correspondante et qui serait prête à enregistrer les données de
l’entreprise.
Une BD est conçue pour un groupe d'utilisateurs, généralement d'une même organisation. Elle
réalise une intention de centralisation1, visant à ne maintenir qu'une version unique des données.
Par conséquent, elle est accédé par de multiples programmes d'applications et utilisateurs qui
traitent les données qu'elle stocke.
Les systèmes informatiques gèrent d'autres types de données que les données structurées,
comme:
• les données non structurées, par exemple des images ou des tableaux de calcul, qui ne
présentent
pas ou peu de structure régulière ;
• les données semi-structurées, qui adoptent une structure partiellement régulière. Par exemple,
les ouvrages d'une même collection présentent chacun une introduction, des chapitres et une
conclusion, mais tous ne contiennent pas le même nombre de chapitres, ou certains comportent
une préface ou un glossaire. La structure de tous ces ouvrages est donc partiellement régulière.
Les données semi-structurées sont représentées avec des langages informatiques spécifiques,
comme le XML (Extensible Markup Language), très répandus pour formater les données du Web.
Les BD ont progressivement intégré ces deux types de données. D'ailleurs, certains éditeurs pro-
posent des BD spécialisées, comme des BD dédiées aux Big Data, des BD géographiques, ou des
BD documentaires.
1.1.Modèle et schéma de données

Une BD sous-entend une manière d'organiser les données selon un certain modèle. Par exemple,
les données du Tableau ci-dessous, relatives à des employés, sont rangées dans une table où
BDD 44
chaque ligne représente un employé particulier. Un modèle permet aussi d,imposer des
contraintes d'intégrité, comme: le salaire doit être
compris entre 1 000 et 20 000.
Définition: Un modèle de données est un ensemble de constructions génériques servant à décrire

l’organisation des données leurs interconnexions, les contraintes d’intégrité, voire les opérations
possibles sur les données.
Définition: un schéma de données décrit l’organisation des données pour un domaine

d’application particulier, ainsi que les contraintes d’intégrité associées.
Il faut bien distinguer modèle et schéma : le modèle fournit les briques de base pour élaborer des
représentations des structures de données, et le schéma décrit les structures particulières d'un
domaine d'application donné, tout comme le langage naturel propose du vocabulaire, une
grammaire, etc. pour formuler un texte décrivant par exemple un paysage particulier.
Ensuite, le schéma peut être vu comme un moule auquel les données doivent correspondre. Il est
lui-même enregistré dans un espace dédié de la BD appelé dictionnaire de données. Par exemple
le schéma suivant décrit la manière dont les données relatives aux employés sont structurées:
Le tableau ci-dessous montre quelques exemples de données de ce schéma. Il correspond au

modèle relationnel qui est largement répandu, et qui sera présenté en détail dans cette section.
Il existe plusieurs modèles de données ayant chacun leur objectif.

Par exemple, le modèle ElA est bien adapté pour décrire les structures de données à un niveau
conceptuel, c'est-à-dire indépendamment d'une technologie de BD particulière. Une section
précédente a présenté les diagrammes ElA qui s'inscrivent dans le modèle du même nom.
Notons encore que les représentations du domaine d'application à l'aide d'un modèle s'appellent
diagrammes ou schémas.
1.2. Système de gestion de bases de données (SGBD)

Une base de données est enregistrée dans la mémoire des ordinateurs. Encore faut-il un logiciel
spécialisé pour la manipuler.
Définition: un système de gestion de bases de données (SGBD) est un ensemble de composants

logiciels permettant principalement de gérer le schéma et les données d'une base de données, et
d'en contrôler les accès.
BDD 45
Un SGBD offre de multiples facilités, notamment pour:

• créer des BD ;
• créer, modifier, supprimer ou lire les données stockées dans une BD ;
• définir des comptes utilisateurs et contrôler leurs accès aux données et aux facilités du
SGBD;
• gérer les accès concurrents, c'est-à-dire permettre à plusieurs utilisateurs d'accéder en
même temps aux mêmes données;
• assurer une protection en cas d'incidents afin de conserver des données correctes en cas de
dysfonctionnement du système informatique.
Un SGBD offre des services de gestion de la persistance des données aux programmes
d'application. Ces derniers vont interagir avec le SGBD pour créer, lire, mettre à jour et supprimer
des données d'une BD. Techniquement, la délégation du stockage auprès du SGBD simplifie
l'écriture des programmes d'application, et donc leur coût de développement et de maintenance.
1.3.Applications
Une première utilisation générique des BD dans l'entreprise est la gestion des données
nécessaires à l'exécution des processus d'affaires routiniers. Le fonctionnement des organisations
implique en effet le stockage centralisé de données accédées par une multitude de programmes
d'application, comme ceux de l’image ci-dessous.
Dans ce contexte, les SGBD sont utilisés dans un mode transactionnel (OLTP - On Line Transaction
Processing), c'est-à-dire qu'ils fournissent aux utilisateurs des facilités de traitement des données
en temps réel.
.... :.;.;....... ·. ::::.. - ..

··- ··· ·· -- .. .
-. -- · ·-·X - . . .......
• .. ·· ··.··-.. ..
/ ·<.··:-:_.:-·:. :.:.: :.- ::.~ ... ... :
:&ifi ~il : 11:l <,;:i

Image: une BD centralise les données de différentes
applications
Les BD trouvent une seconde utilisation générique à travers les systèmes d'aide à la décision, qui
cherchent à dégager des tendances à partir de gros volumes de données pour faciliter la prise de
décision. Certaines données d'exploitation gérées par les systèmes transactionnels ou en
provenance de l'environnement de l'organisation sont importées dans des entrepôts de données.
Ces entrepôts (Data Warehouses) sont des SGBD spécialisés dans l'analyse massive de données,
et seront présentés plus en détail dans un section ultérieure.
2. Architectures
De manière générale, la notion d'architecture a trait à la décomposition d'un système complexe.
Définition: Une architecture décrit l’organisation d’un système en différents composants ainsi que
leurs interactions.
BDD 46
Plus particulièrement, un SGBD est organisé en composants, et il est lui-même un composant du

système informatique.
2.1. Architecture logique

L’image ci-dessous montre l'architecture typique d'une BD et d'un SGBD relationnels.
La BD, reprenant les données et leur schéma, est traitée par le SGBD. Les utilisateurs agissent sur
les données en commandant le SGBD de deux manières principales :
• en soumettant au SGBD des instructions exprimées dans un langage dédié, le SQL. Ce mode
d'utilisation requiert la maîtrise de ce langage et une compréhension du schéma de données,
mais permet une grande flexibilité dans les traitements ;
• en utilisant des programmes d'application spécifiquement développés pour automatiser des
traitements connus et répétitifs. Ces programmes génèrent des instructions SQL envoyées au
SGBD de manière transparente pour l'utilisateur. Ce mode d'utilisation apporte de
l'ergonomie et de la facilité d'utilisation, mais ne permet pas de réaliser des traitements qui
n'ont pas été explicitement prévus lors du développement des programmes.
Utilisateur Utilisateur Utilisateur Utilisateur
Programmes d'application
SQL
Système de gestion de base de données
Base de données
(_____
o_o_nn_e_'e_s____) (_____
sc_h_é_m_a_____]
2.2. Architecture client-serveur

Comme une BD centralise les données d'une même organisation, elle est habituellement stockée
sur une machine dédiée, appelée serveur de BD, et accédée via un réseau par les différents
postes de travail des utilisateurs (ordinateurs personnels, tablettes, etc.), appelés postes clients.
La collaboration entre un serveur de BD et des postes clients est régie par l'architecture client-
serveur de BD.
De manière générale, l'architecture client-serveur distribue les traitements entre un processus

client et un processus serveur qui s'échangent des messages, comme illustré par l’image ci-
dessous. Le processus client émet une requête à l'intention du processus serveur et se met en
attente d'une réponse. Le processus serveur exécute la requête puis renvoie une réponse au
processus client.
Client Serveur
Dans le contexte des BD, le processus serveur est un SGBD qui est exécuté par le serveur de BD,
et le processus client est un programme d'application exécuté sur un poste client d'un utilisateur.
Le poste client soumet des requêtes formulées en SQL à l'intention du serveur de BD. Les
BDD 47
réponses calculées par ce serveur sont des lignes de données et/ou des messages documentant
l'exécution de ces requêtes. Les composants de l'architecture client-serveur de BD se
répartissent le travail comme suit :
• le poste client prend en charge l'interface homme-machine (affichage, saisie, etc.) et le
traitement local des données ;
• le serveur de BD gère notamment la persistance des données, l‘exécution des requêtes SQL
(et donc le traitement de données) et le contrôle d'accès.
Pour le manager, la technologie client-serveur de BD apporte une réelle valeur car elle permet
davantage d'autonomie dans les traitements. L'utilisateur traite des données d'une BD comme il
le souhaite, et avec ses outils personnels, comme des progiciels bureautiques. Cela évite de
solliciter un informaticien pour certains traitements, avec des réductions de délais et de coût de
développement appréciables.
Par exemple, considérons le cas d'une entreprise commerciale qui gère des produits, des clients
et des commandes dans une BD centralisée au sein d'une architecture client-serveur.
Le responsable marketing réalise régulièrement des mailings ciblés sur certaines catégories de
clients. Il a sélectionné les coordonnées des clients qui n'avaient plus rien commandé depuis plus
de trois mois avec une requête SQL de son cru. Il génère alors, avec son traitement de texte,
des courriers personnalisés en fusionnant une lettre type et les résultats de
sa requête.
Quant au directeur financier, il a développé un tableau de bord des ventes avec son tableur
favori. Grâce au client-serveur, il incorpore dynamiquement dans une feuille de calcul les volumes
mensuels des ventes directement extraits de la BD.
2.3. Architecture à trois tiers

Dans l'architecture client-serveur de BD discutée ci-dessus, le poste client doit disposer d’un
programme avec des capacités de traitement. Avec l’architecture à trois tiers, le poste client ne
doit plus disposer que d’un navigateur Web, car les traitements sont délégués auprès d’un
troisième processus dédié qui complète les processus client et serveur.
De manière générale, l’architecture à trois tiers compte trois processus logiciels, souvent appelés
couches, qui collaborent en s’échangeant des messages :
• la couche présentation, qui prend en charge l'interface homme-machine;
• la couche traitement, qui gère les transformations des données ;
• la couche données, qui gère la persistance.
Dans le contexte des BD, ces trois couches sont généralement prises en charge par des machines
différentes :
• la couche présentation se matérialise par un navigateur exécuté par un poste client
«léger», ou client Web, c'est-à-dire qui ne dispose pas nécessairement de grosses capa-
cités; ,
• la couche traitement est réalisée par des programmes exécutés par des serveurs Web. En
particulier, un de ces serveurs, appelé serveur d'application, se charge d'accéder à un serveur
de BD, de traiter et de mettre en forme les données en générant des pages Weh
envoyées vers le client Web. Ces pages sont générées à la volée, c'est-à-dire lorsque le client
les demande ;
• la couche données est assumée par un SGBD exécuté par un serveur de BD.
BDD 48
L’image ci-dessous illustre les interactions typiques entre les trois tiers. Le client Web échange des
requêtes et des pages Web avec des serveurs Web à travers l'Internet. Ces serveurs Web
échangent des requêtes et des données (ou d'autres résultats d'exécution) avec un serveur de
BD.
L'architecture à trois tiers permet d'accéder à des facilités potentiellement élaborées à partir d'un
navigateur, sans installation de programme particulier sur le poste client. Ces facilités sont
accessibles moyennant une connexion à l'Internet, et donc de (presque) partout.
Pour le manager, cette architecture offre davantage d'ubiquité. L'utilisateur peut accéder à une
BD de n'importe où, à travers Internet, et à partir d'un terminal mobile, comme un smartphone.
Pour les entreprises, cette technologie a contribué à l'essor de l'économie digitale, en
informatisant leur front office et en ouvrant leur système d'information à leurs clients et leurs
partenaires d'affaires. Les applications sont innombrables, comme les magasins en ligne du
commerce électronique. Même les applications du back office, comme des logiciels de gestion
intégrés ou des logiciels comptables, sont maintenant déployées dans des architectures à trois
tiers.
Client Serveurs Serveur

Web Web BD
'------
y
___ / '------
y
___/
Couche Couche Couche

présentation traitement données
3. Sécurité des bases de données

La digitalisation croissante des affaires et de la vie privée fait que les BD contiennent des
quantités importantes de données sensibles qui doivent être soigneusement protégées. Par
exemple, des données à caractère personnel, comme celles relatives à la santé des personnes,
doivent rester strictement confidentielles. De la même manière, des données concernant des
processus de fabrication exclusifs ne doivent pas tomber dans les mains de concurrents sous
peine de perdre un avantage concurrentiel.
Les technologies digitales intègrent des mécanismes pour garantir la sécurité des données, qui se
définit comme suit dans le cadre des BD:
Définition: la sécurité des données consiste à respecter au minimum trois propriétés:

- la confidentialités, qui signifie que les données sont accessibles exclusivement aux utilisateurs
autorisés;
- l’intégrité, qui garantit le maintien du caractère correct et complet des données. Une donnée
ne peut-être modifiée ou supprimée que par des utilisateurs autorisés;
- La disponibilité, qui assure que les données restent accessibles aux utilisateurs.
BDD 49
• Qui voit les données que je crée dans une base de données?
• Quelles sont les données me concernant dont disposent
les entreprises avec lequelles j'interagis ?
• Comment être certain que mes données ne vont pas
être transmises à des tiers sans mon autorisation ?
• Les données que j'ai enregistrées dans une base de données

n'ont-elles pas été altérées ou supprimées innopinément ?
• Le contenu d'une base de données est-il conforme
à la réalité qu'elle décrit
• Puis-je accéder à une base de données quand j'en ai besoin ?

• Les temps de réponses sont-ils corrects? L'accès aux données
est-il encore possible même en cas de défaillance technique
ou d'attaque informatique ?
La sécurité informatique est devenue aujourd’hui un enjeu important pour le citoyen et pour
l’entreprise, essentiellement à cause de :
• notre dépendance croissante aux systèmes informatiques, dont nous avons de plus en plus de
mal à nous passer pour réaliser nos activités ;
• la multiplication des incidents de sécurité, et en particulier des attaques informatiques ;
• l'émergence de prescrits légaux, comme le RGPD4 (Règlement Général sur la Protection
des Données).
La suite de cette section traite de deux mécanismes importants des SGBD pour contribuer à la
sécurité : la gestion des transactions et le contrôle d’accès.
3.1 Gestion des transactions

Une BD est, par essence, partagée par plusieurs utilisateurs. Certaines entreprises comptent des
milliers de collaborateurs qui alimentent et consultent les mêmes BD simultanément, sans
compter les nombreuses applications de l’lnternet dont les BD sous-jacentes peuvent être
manipulées par un très grand nombre d’internautes.
Les SGBD doivent donc traiter l'exécution de (nombreuses) opérations simultanées entraînant la
lecture ou la modification des mêmes données. Ces opérations sont exécutées dans le cadre
d'une transaction.
Définition: une transaction reprend un ensemble d’opérations à réaliser sur les données et
correspond à une seule unité logique de traitement du point de vue l’utilisateur.
Par exemple, lors de l'inscription d'un nouvel étudiant dans la BD d'une université, un employé
administratif enregistre d’abord les données personnelles de l’étudiant, comme son nom ou sa
date de naissance, puis ses diplômes antérieurs et enfin les cours qu'il va suivre. Toutes ces
opérations sont perçues par remployé comme étant un tout cohérent et s'inscrivent dans la même
transaction.
La plupart des SGBD relationnels garantissent la bonne exécution des transactions en assurant
que:
BDD 50
• les transactions respectent les contraintes définies au niveau du schéma de données, ce qui
contribue à l'intégrité des données (propriété de cohérence);
• l’exécution parallèle de transactions simultanées produit le même état des données que si les
transactions étaient exécutées les unes après les autres. Par conséquent, les opérations réalisées
par un utilisateur ne sont pas perturbées par celles d'un autre utilisateur agissant en même
temps sur les mêmes données, ce qui contribue également à l'intégrité des don- nées
(propriété d'isolation) ;
• lorsqu'une transaction se termine avec succès, son effet sur la BD persiste en toute circonstance
et indépendamment de la survenance d'incidents, comme une panne matérielle, ce qui
contribue indirectement à la disponibilité (propriété de durabilité).
Finalement, les transactions assurent une propriété d'atomicité, signifiant que toutes les
opérations d'une même transaction sont effectivement exécutées ou qu'aucune de ces opérations
n'est exécutée. Les quatre propriétés que doivent respecter les transactions sont reprises sous
l'acronyme ACID (Atomicité, Cohérence, Isolation et Durabilité).
Du point de vue du manager, la technique des transactions permet des accès simultané aux
données et soutient donc le travail collaboratif, tout en assurant un certain niveau d’intégrité
et de disponibilité.
3.2. Contrôle d’accès

La volonté de centraliser les données d’une organisation et de les partager entre les utilisateurs
implique de contrôler précisément qui peut accéder à quelles données.
Définition: le contrôle d’accès est un mécanisme assurant la définition et la vérification des

autorisations conférées à un utilisateurs pour traiter les données d’une BD.
L’accès à une BD se déroule en 3 étapes:

1. L’identification: l’utilisateur doit déclarer qu’il est, par exemple avec un nom d’utilisateur;
2. l'authentification: l'utilisateur doit démontrer qu'il est bien celui qu'il prétend être en
communiquant un signe probant d'authentification, comme un mot de passe;
3. l'autorisation: le SGBD accorde à l'utilisateur les accès aux données pour lesquelles il dispose
d'autorisations spécifiques, comme la lecture, la modification, l'ajout ou la suppression. Souvent,
ce qui n'est pas autorisé est interdit, et tous les accès autorisés aux données doivent être
explicitement déclarés.
Plusieurs modèles et techniques de contrôle d'accès mettent en œuvre ces étapes, notamment le
modèle discrétionnaire et le modèle basé sur les rôles :
• Dans le modèle discrétionnaire (ou DAC pour Discretionary Access Control): les autorisations
sont attribuées explicitement (ou à discrétion) à chaque utilisateur par les propriétaires des
données. Cette façon de faire s'avère être lourde quand beaucoup d'utilisateurs doivent
accéder à beaucoup de données différentes, car le nombre d'autorisations à accorder devient
alors important.
• Le modèle basé sur les rôles (ou RBAC pour Role-Based Access Control) : ce modèle
fonctionne comme le modèle discrétionnaire, mais ici un utilisateur peut être associé à un ou
plusieurs rôles. Un rôle bénéficie d'un ensemble d'autorisations qui s'appliquent
automatiquement à tous les utilisateurs associés à ce rôle. Par exemple, le rôle « vendeur »
sera autorisé à accéder aux données sur les produits et les clients. En rattachant tous les
vendeurs à ce rôle, il ne faut plus définir les autorisations pour chacun des vendeurs
BDD 51
séparément, car ils héritent tous automatiquement de l'accès aux données des produits et des
clients accordés au rôle « vendeur ».
Le contrôle d'accès contribue à la confidentialité des données. La bonne compréhension des

mécanismes sous-jacents est importante pour le manager, car il est impliqué dans la définition des
rôles et des autorisations, car ce sont les exigences métier qui les conditionnent. D'ailleurs, les
rôles correspondent souvent aux fonctions définies au sein de l'entreprise.
4. Modèle relationnel
Cette section présente informelle- ment les fondements du modèle relationnel qui est le modèle
de données le plus répandu dans les SGBD du même nom.
Le modèle relationnel prescrit une organisation logique des données, des contraintes d'intégrité
et les opérations possibles sur les données. Ces dernières seront présentées à travers le langage
SQL.
4.1 Table
Le modèle relationnel range les données dans des tableaux à deux entrées appelés tables. Une
table représente un concept du domaine d'application pour lequel on souhaite gérer des
données, et correspond principalement à la notion d'entité d'un diagramme E/A.
Définition: Une table contient les données d’un ensemble d’objets similaires du domaine
d’application. Les colonnes correspondent aux caractéristiques de ces objets, tandis qu’une ligne
reprend les données d’un même objet.
Dans la table employe ci-dessous, les données d’un même employé sont placés sur une même
ligne, appelé aussi enregistrement. La structure de la table, comprenant notamment son nom et
le nom de ses colonnes, fait partie du schéma de la BD.
:,J,Q~CllON 1
2145 Geldorf directeur 2015 - 01 - 01
2378 Artois manager 7100 2015-02-01
2685 Charlet assistant 6500 2015-09-01 données
3144 Peeters monteur 4900 2016-02-01
3298 Lemoine vendeur 5000 2000 2016-06-15
Il n'y a pas de relation d'ordre entre les lignes d'une table, mais un SGBD propose des facilités
pour trier une table selon une ou plusieurs colonnes.
Dans la théorie relationnelle, que nous ne détaillerons pas, une table est appelée relation, une
colonne est appelée attribut et une ligne est appelée tuple. Une relation est une agrégation
d'attributs.
4.1.1.Propriétés des colonnes

Une colonne est caractérisée par un nom et le type des données qu'elle contient, comme des
caractères alphanumériques, des nombres ou des dates.
Si une ligne n'a pas de valeur pour une colonne, on lui attribue par convention une valeur NULL.
Par exemple, l'employé Artois n'a pas de valeur pour la PRIME dans la table ci-dessus. Une valeur
NULL est ambiguë pour l'utilisateur, car elle peut signifier que:
• la donnée n'est pas pertinente pour l'objet du domaine d'application, par exemple A r t o i s
BDD 52
n'a pas de rémunération qui inclut une prime ;

• ou bien la donnée n'est pas connue, même si elle existe dans le domaine d'application. Par
exemple,Artois a touché une prime, mais on ne connaît pas sa valeur ou elle n’a pas été
enregistrée dans la BD.
Certaines colonnes sont des clés primaires.
Définition: La clé primaire d’une table est une colonne ou une collection de colonnes dont les
valeurs identifient univoquement une ligne de la table
Il peut exister plusieurs clés primaires possibles, appelées clés candidates. Par exemple, un
employé pourrait être identifié par son matricule ou par son numéro de registre national. Dans ce
cas, on choisit une des clés candidates que l'on définit comme clé primaire, les autres clés
candidates étant appelées clés secondaires.
Les colonnes d’une clé primaire sont soumises à une double contrainte :
• elles doivent obligatoirement comporter une valeur pour chaque ligne. En d'autres termes,
les valeurs NULL ne sont pas autorisées dans une clé primaire ;
• toutes les valeurs de la clé primaire doivent être uniques.`
Par exemple, la colonne NUMEMP est la clé primaire de la table EMPLOYE dans l’image ci-
dessus.
4.1.2.Correspondance entre tables

Un schéma relationnel comporte plusieurs tables reliées entre elles par des liens logiques. Dans
l’exemple ci-dessous, des employés peuvent appartenir à un département. Dans ce cas, les
données concernant les départements sont enregistrées dans une table DEPARTEMENT, dont la
clé primaire est NUMDEP (colonne soulignée), et le numéro du département auquel un employé
est attaché est enregistré dans la colonne NUMDEP de la table EMPLOYE. Cette dernière colonne
contient donc des valeurs qui font référence à la colonne NUMDEP de la table DEPARTEMENT, et
est appelée et une clé étrangère (colonne en italique).
NUMEMP
NOM
FONCTION - - clé primaire
SALAIRE
PRIME LOCALISATION
DATECONTRAT
clé étrangère - - - NUMDEP
Définition: une clé étrangère d’une table est une colonne ou une collection de colonnes dont les
valeurs font références aux valeurs de la clé primaire d’une autre table.
La clé étrangère doit être du même type que la clé primaire correspondante, mais pas
nécessairement du même nom. Si une clé primaire est composée de plusieurs colonnes, alors la
clé étrangère correspondante sera elle aussi constituée de plusieurs colonnes.
4.1.3.Lien entre tables

Le modèle relationnel ne supporte que les correspondances suivantes entre deux tables :
BDD 53
• 1 à plusieurs. Dans l'exemple de la Figure 3-8, un employé appartient à un seul départe-

ment, et un département emploie plusieurs employés ;
• 1 à 1. Par exemple, un projet est dirigé par un seul employé, et un employé ne peut diriger
qu'un seul projet.
Comment faire alors pour représenter des liens de plusieurs à plusieurs entre deux tables, par
exemple lorsqu'une commande peut comporter plusieurs produits, et qu'un produit peut être
repris dans plusieurs commandes ?
La solution consiste à décomposer le lien de plusieurs à plusieurs en créant une nouvelle table et
deux liens de 1 à plusieurs. Dans l’image ci-dessous la table COMMANDE, dont la clé primaire
est NUMCOM, et la table ARTICLE, dont la clé primaire est NUMART, sont connectées à une
table de liens LIGNECOM dont les deux colonnes, NUMCOM et NUMART sont des clés
étrangères faisant respectivement référence aux tables COMMANDE et ARTICLE.
~---1
NUMCOM
DATECOMMANDE NUMART NOM
DATE LIVRAISON PRIX
GROUPE
L’image ci-dessous affiche une version plus détaillée, où:

• la table de liens LIGNECOM comporte deux colonnes supplémentaires caractérisant le lien
entre un produit et une commande: PRIXVENTE, qui contient le prix réel de vente, qui peut
être différent du prix catalogue (stocké dans la colonne PRIX de la table ARTICLE), et QUANT,
qui reprend la quantité commandée d'un même article au sein d'une même commande;
• la clé primaire de la table LIGNECOM est composée de ses deux colonnes clés étrangères.
Comme les valeurs d'une clé primaire sont uniques, chaque couple de valeurs des colonnes
NUMCOM et NUMART doit être unique. En l'occurrence, il est impossible d'avoir deux lignes
pour un même article dans une même commande ;
• une commande est passée par un client, dont les données sont enregistrées dans la table
CLIENT.
DATECREATION NUMART NOM

ADRESSE DATE LIVRAISON PRIXVENTE PRIX
VILLE '-------1 NUMCLI QUANT GROUPE
CODEPOSTAL
URL
REMISEMAX
Le modèle relationnel présenté ci-dessus correspond à la norme SQL2. Il est assez simple et donc
limité en expressivité, mais son implémentation par les SGBD commerciaux est stable et
performante. Ces dernières années, les BD relationnelles ont connu des évolutions dans deux
directions différentes :
• un enrichissement, avec le modèle relationnel-objet (SQL3), qui supporte des constructions
comme l'héritage entre les tables ou des correspondances directes de plusieurs à plusieurs. Son
application est cependant assez complexe ;
• une simplification, avec les technologies NoSQL (pour Not Only SQL), qui choisissent de ne pas
implémenter certaines facilités afin de gagner de la performance dans le traitement de très gros
volumes.
BDD 54
4.2 Contrainte d'intégrité

Nous savons qu'une contrainte d'intégrité exprime une propriété qui doit toujours être vérifiée
par les données d'une BD, et que le SGBD vérifie automatiquement les contraintes pour chaque
transaction. Le modèle relationnel supporte différents types de contraintes présentés ci-dessous.
4.2.1. Intégrité référentielle

L'intégrité référentielle impose qu'une valeur d'une clé étrangère doit correspondre à une valeur
existante de la clé primaire à laquelle la clé étrangère fait référence. Le respect de cette
contrainte impose les restrictions suivantes:
• il est interdit d'insérer une valeur de clé étrangère qui n'existe pas dans la clé primaire
correspondante ;
• il est interdit de modifier une valeur de clé étrangère en une valeur qui n'existe pas dans la
clé primaire correspondante ;
• il est interdit de supprimer ou de modifier une valeur d'une clé primaire s'il existe des
lignes liées qui y font référence. Cependant, des options du contrôle de l'intégrité référen- tielle
permettent soit de supprimer en cascade les lignes liées, soit de mettre une valeur
NULL dans leur colonne clé étrangère.
4.2.2.Contrainte de domaine
Les valeurs permises d'une colonne peuvent être limitées par une liste de valeurs ou des
fourchettes de valeurs autorisées. Par exemple, le domaine d'une colonne GENRE est {masculin,
féminin}, et celui d’une colonne SALAIRE est [1 000 9 500]. Notons que le domaine d'une clé
étrangère est l'ensemble des valeurs de la clé primaire de la table référencée.
4.2.3.Non-nullité
Les valeurs d'une colonne doivent être obligatoirement alimentées pour chaque ligne. Par
exemple, toutes les lignes de la table EMPLOYE doivent avoir une valeur dans la colonne NOM.
4.2.4.Unicité
Les valeurs d'une colonne doivent être toutes différentes. Par exemple, les numéros de compte
des employés sur lesquels une entreprise verse les salaires doivent tous être différents. Une
colonne avec la contrainte d'unicité peut contenir des valeurs NULL.
Pour rappel, une clé primaire combine l'unicité et la non-nullité.
Du point de vue du manager, ces contraintes contribuent à la qualité des données et donc
indirectement au bon déroulement des processus d'affaires.
Tout comme le modèle E/A, le modèle relationnel ne permet pas de formuler directement toutes
les contraintes du domaine d'application, telles que des contraintes de cardinalité, comme un
département doit compter au moins deux employés.
Par conséquent, la vérification de certaines contraintes sera prise en charge soit par des
mécanismes avancés des SGBD, comme les déclencheurs, soit par les programmes d'application.
5 Principes de génération d'un schéma et d'une BD relationnels

Les diagrammes E/A (Section 2.4) offrent un bon support pour spécifier les données qu'un
système informatique devra prendre en charge. En effet, ces diagrammes permettent de se
concentrer sur les exigences métier sans devoir traiter des aspects techniques.
Après la rédaction des exigences, les informaticiens vont poser des choix techniques et concevoir
des solutions pour satisfaire à ces exigences. Par exemple, ils vont déterminer la technologie la
BDD 55
mieux adaptée pour gérer la persistance des données. Un choix fréquent est la technologie des
BD relationnelles, mais des alternatives existent, comme des BD NoSQL ou
des systèmes de fichiers.
Ensuite, le diagramme E/A va servir à élaborer des schémas de données pour la technologie
cible. Par exemple, un schéma relationnel est d'abord généré à partir du diagramme E/A, puis
des instructions de création de ce schéma sont produites pour créer effectivement la BD, comme
dans l'exemple de la Figure 3-11.
Les mécanismes de conversion « E/A schéma relationnel instructions de création du schéma

relationnel» sont assez techniques, et ce sont les informaticiens plutôt que les managers qui sont
impliqués dans ces manœuvres. Heureusement, ils peuvent s'appuyer sur des outils de génie
logiciel pour automatiser largement leur travail.
La difficulté principale dans la génération d'un schéma relationnel à partir d'un diagramme ElA est
la limite sémantique du modèle relationnel, du moins dans sa version historique (norme SQL2). En
effet, des constructions de l'E/A, comme la généralisation/spécialisation, ne sont pas disponibles
dans le monde relationnel, et il faut transformer le diagramme E/A pour éliminer ces constructions
avant de produire le schéma relationnel.
Employé
NUMEMP
numEmp Département NOM
nom FONCTION
fonction ---0-1-(travaille dans}O-N numDep NUMDEP
nom SALAIRE
salaire NOM
localisation PRIME
prime[0-1] LOCALISATION
DATECONTRAT
dateContrat
NUMDEP
Diagramme E/A Schéma relationnel
create table DEPARTEMENT

NUMDEP numeric(2) primary key,
NOM char(S0) not null,
LOCALISATION char(S0) not null
)
create table EMPLOYE (
NUMEMP char(l0) primary key,
NOM char(S0) not null,
FONCTION char(20) not null,
SALAIRE numeric(6) not null,
PRIME numeric(6),
DATECONTRAT date not null,
NUMDEP numeric(2) foreign key references DEPARTEMENT
5.1. Génération directe

Les constructions de base de l'E/A sont facilement transposables vers le relationnel.
5.1.1.Entité
Une entité est réalisée par une table, dont l'identifiant devient la clé primaire. Dans l'exemple de
ci-dessus, les entités Employé et Département produisent les tables EMPLOYE et DEPARTEMENT,
respectivement identifiées par NUMEMP et NUMDEP. Les règles de nomenclature pour les noms
de tables et de colonnes sont libres. Par exemple, ces noms peuvent être libellés en majuscules
dans le schéma relationnel, mais ce n’est pas du tout une obligation.
BDD 56
5.1.2.Association binaire de 1 à plusieurs

Pour rappel, une association binaire dont les cardinalités maximales sont respectivement égales à
1 et supérieures à 1 est appelée association de 1 à plusieurs. Une telle association est directement
transposée en relationnel par une clé étrangère. Dans l’image ci-dessus, rassociation t ra va i LL e
dans se traduit par une clé étrangère NUMDEP au niveau de la table EMPLOYE, c,est-à-dire la
table du côté « 1 » de l'association d’origine.
5.1.3. Association binaire de plusieurs à plusieurs

Si les cardinalités maximales sont, de part et d’autre de rassociation, supérieures à 1, on crée alors
une nouvelle table reprenant des références aux clés primaires des deux tables associées. Dans
l'exemple de l’image ci-dessous, la table LIGNECOM résulte de l'association porte sur et
comprend deux clés étrangères qui font référence aux tables COMMANDE et ARTICLE.
La table LIGNECOM a un statut différent des tables COMMANDE et ARTICLE: elle ne représente
pas des objets du domaine d'application, mais des liens entre ces objets.
Le fait que certaines tables d'un schéma relationnel soient des tables de liens, et que certaines
associations soient converties en tables et pas d'autres en fonction de leurs cardinalités maxi- ·
males complique l'interprétation d'un schéma relationnel. Ceci est dû à l'incapacité des BD
relationnelles à supporter les liaisons de plusieurs à plusieurs entre deux tables, du moins dans la
norme SQL2.
Article
Commande
numCom numArt
, t· ._, _ porte sur 0-N- nom NUMART NOM
d at eC.rea . ,on .
pnx
d ate L1vra1son groupe DATE LIVRAISON PRIX
GROUPE
5.1.4.Association cyclique
L'exemple de l’image ci-dessous montre qu'un employé peut dépendre d'un autre employé qui
serait son supérieur hiérarchique, et qu'un même employé peut superviser plusieurs employés
dont il serait le manager.
dépend de
Employé 0-1
matricule lien hiérachique
nom
fonction .
supervise
0-N
L'association cyclique l i e n h i é r a r c h i q u e a comme cardinalités maximales: 1 et plusieurs.

Comme toutes les associations de 1 à plusieurs, elle s'implémente avec une clé étrangère, mais
avec la particularité que cette clé étrangère fait référence à une clé primaire de la même table.
La table correspondante EMPLOYE de la Figure 3-14 contient donc une colonne clé primaire
MATRICULE et une colonne clé étrangère REFMATRICULE qui y fait référence. 
,f[ , j .ji,~(?rtf~~j j -i~i~~~~ift\1fîZ*:f ':<~ :,:1:,;:· ,:;,,. ,REfMATRICULE
1
1 Durant vendeur 2
2 Dupond responsable vente
3 Warnant assistante commerciale 2
4 Degrève analyste
BDD 57
5.2. Génération moyennant transformation

Certaines constructions de l'E/A, comme la généralisation/spécialisation, ne sont pas supportées
par le modèle relationnel. Voici quelques exemples de situations qui nécessitent de transformer
le diagramme E/A avant de produire le schéma relationnel correspondant.
5.2.1.Attribut composite
Au minimum deux possibilités sont offertes pour transformer les attributs composites avec, pour
la première, une perte de sémantique, comme dans l'exemple de
L’image ci-dessous 
• éliminer l'attribut composite (a) et considérer tous ses composants comme
des attributs atomiques indépendants (b). La notion de composition est alors
perdue;
• isoler l'attribut composite dans une entité ad hoc (c).
5.2.2. Attribut multivalué

Une solution consiste à placer l’attribut multivalué dans une nouvelle entité, comme les emails
d’un étudiant dans l’image ci-dessous
Etudiant
Etudiant
nom Email
adresseKot[0-1] nom o-s a 1-1---+----l
email[0-5] adresseKot[0-1] email
Généralisation/spécialisation. Trois solutions sont envisageables pour transformer le diagramme

(a) de l’image ci-dessous, à savoir, et sans rentrer dans tous les détails:
• solution (b) : les liens de généralisation/spécialisation sont transformés en associations. Une
association est générée entre chaque spécialisation et la généralisation ;
• solution (c) : seule la généralisation est
conservée et les attributs des anciennes Personne
matricule
spécialisations sont replacés au niveau de Personne nom
matricule prénom
la généralisation en devenant nom
prénom 0-1 0-1
systématiquement optionnels. Un attribut ( est;rof) ( e;_:tu)
ad hoc rappelant à quelle spécialisation ~-1 1-~
appartient une instance est ajouté à la Professeur Etudiant

Professeur Etudiant matricule matricule
généralisation restante. Les cardinalités de spécialités[1-N] annéeEtude spécialités[1-N] annéeEtude
cet attribut sont fonction des propriétés de (a) (b)
la généralisation. Ici, l'attribut catégorie

contient la valeur Pou E pour indiquer si
Personne
une personne est professeur ou étudiant ; matricule
Personne Professeur Etudiant
• solution (d) : les trois entités de départ sont nom
prénom matricule matricule matricule
conservées, et les spécialisations sont spécialités[0-N]
annéeEtude[0-1]
nom
prénom
nom
prénom
nom
prénom
complétées avec les attributs hérités de la catégorie (P ou E) spécialités[ 1-N) annéeEtude
généralisation. (c) (d)
BDD 58
6. Language SQL
Rappelons que pour interagir avec un SGBD, l’utilisateur lui soumet des instructions formulées
dans un langage informatique spécialement pensé pour les BD.
Définition: Le SQL( Structured Query Language) est le langage normalisé des SGBD relationnels
pour gérer un schéma de données, traiter les données et contrôler les accès.
Pour le programmeur, le SQL est indispensable pour atteindre les données d’une BD au niveau
des programmes d’application.
Les managers ont également besoin du SQL pour manipuler eux-mêmes des BD lors d'opé-
rations quotidiennes ou pour la prise de décisions. Souvent, ils traitent des données extraites
d'une BD avec des outils bureautiques
A priori, on pourrait penser que toutes les requêtes sur les données pourraient être program-
mées à l'avance par des informaticiens, mais la pratique montre que ce n'est pas réaliste car les
besoins des managers sont changeants. La connaissance du SQL permet au manager de
s'affranchir de la dépendance à un informaticien.
Le SQL comporte de nombreuses instructions qui ont été regroupées dans différents sous-lan-
gages selon leur nature.
Data Definition Language (DDL)

Les instructions DDL agissent sur le schéma de données, comme l'instruction suivante qui crée
une table EMPLOYE avec des colonnes décrites par leur nom, leur type de données et
d'éventuelles contraintes d’intégrité:
create
DATECONTRAT date :NO'F- N:UL-~) : _- -
Par exemple, la première colonne de la table EMPLOYE est dénommée NUMEMP. Elle peut
contenir jusqu'à dix caractères alphanumériques et est définie comme la clé primaire de la table.
Data Manipulation Language (DML).

Les instructions DML permettent de peupler la BD (création, suppression et modification), et de
l'interroger. Par exemple, l'instruction update ci-dessous augmente les employés de 10 %. Plus
précisément, les valeurs d'une colonne SALAIRE sont remplacées par le résultat de la
multiplication de l'ancien SALAIRE par 1.1:
On peut aussi réaliser des requêtes pour sélectionner des données à afficher, comme avec
l'instruction select suivante qui affiche le nom et le salaire des employés:
Les requêtes de sélection de données seront traitées en détail par la suite.
BDD 59
Data Control Language (DCL).

Les instructions DCL servent essentiellement à définir des comptes d'utilisateurs et des
permissions d'accéder aux données. Par exemple, l'instruction pour créer un utilisateur JAMES
dont le mot de passe est JB007 est: 
······· ············ ············· ················ ·································· ······· · ···· ············ ·········· . .... .. ... . -· . . . .. -• . . .. . . . . . . .
Pour accorder un droit de lecture sur la table EMPLOYE à l’utilisateur JAMES, on utilise
l’instruction suivante:
Le SQL possède deux caractéristiques intéressantes: il est déclaratif et normalisé.

Langage déclaratif. Le SQL se distingue de nombreux langages de programmation qui sont
procéduraux, c'est-à-dire avec lesquels le programmeur détaille toutes les étapes nécessaires à
l'obtention d'un résultat. En SQL, l'utilisateur exprime le résultat à obtenir sans devoir spécifier la
manière de le produire.
L'exemple suivant compare une formulation déclarative et son équivalent procédural. On
comprend vite en quoi le SQL est plus concis…
Déclaratif Procédural
open table employes

declare temp number
move to fi rst record
do while not end of file
update employes if deptno = 2 0
set salaire = salaire * 1.05 temp:= current_record.salaire * 1.05
where deptno = 20 update current_record.salaire to temp
end if
go next record
end while
close employes
Langage normalisé.
Le SQL est normalisé et implémenté par la plupart des SGBD relationnels. La norme SQL est en
évolution constante6 et présente au moins trois avantages :
• la portabilité des programmes d'application. Ces programmes peuvent fonctionner avec les
différents SGBD qui respectent la norme, moyennant cependant des adaptations mineures en
pratique ;
• l'universalité des compétences acquises : les informaticiens et les utilisateurs ne doivent
maîtriser qu'un seul langage pour piloter des SGBD d'éditeurs différents ;
• une concurrence bénéfique pour les utilisateurs, car les éditeurs de SGBD doivent se
différencier par exemple sur la performance plutôt que sur les fonctionnalités qui restent
majoritairement standard.
Les SGBD commerciaux implémentent la norme SQL assez largement, même si des écarts à la
norme existent.
6.1. Selection sur une seule table

L’instruction simplifiée pour la sélection de données est la suivante:
BDD 60
Où:
• <liste de colonnes> : liste des colonnes à afficher. Le symbole* représente toutes les colonnes ;
• <nom de la table> : table contenant les colonnes à traiter ;
• < c o n d i t i o n > : expression booléenne qui permet la sélection d'enregistrements;
• order by<liste de colonnes>:liste des colonnes selon lesquelles les lignes doivent être
ordonnées (clés de tri).
Les tables de l’image ci-dessous portent sur une gestion du personnel fictive et serviront
d'exemples de données pour les prochaines requêtes. Les colonnes clés primaires sont soulignées
et la colonne clé étrangère est mise en italique.
EMPLOYE
,,
' ~ '
."'-'<;
,\.- "'' -,to,

NUMEMH-,,-, NIDM
' '
;-•
.,
' .·,-~
'. ' '

,;rrif;f~l~~ti:'-.- i-E0Ndff0N ;;SA~ Jgg~):t1:f ;ggiMJ=:·;: .
'
'~ •• -. ,.-'...,, >••- <.
2
•
: ,~
.. -.,
: 'ri~tédl)NTR/4T·-,,.<, ;,
',• __ /;,c'c'.O
,·., , < . ' --~ ,~
/~/ / ',·'~C•.·•>:« ,
,
<;: , .<'
;:f.1// p/
·NHMOEP :~•4t1!
. ~: //,- /<,-(_;,,,;,
~· ; ·':f:,~/,"',:;,: : ,, /-0'~ 0.
:?;;{Mf2
~:~;
2145 Geldorf directeur 1 1 000 2015-01-01

2378 Artois manaqer 7 100 2015-02-01 2
2685 Charlet assistant 6 500 2015-09-01 2
3144 Peeters monteur 4 900 2016-02-01 2
3298 Lemoine vendeur 5 000 2 000 2016-06-15 1
3510 Somville vendeur 4400 8 000 2016-08-01 1
3645 Goessens monteur 4 200 2016-11-15 2
3960 Marzouk manaqer 7 300 11 000 2016-12-15 1
4177 Lejeune manaqer 5 600 2017-01-15 3
4357 Atas comptable 3 500 2017-01-15 3
4901 Pornel vendeur 5 900 3 000 2017-02-01 1
5040 Ghilain desiqner 4 700 2018-04-01 2
5391 Nquven monteur 6 000 2018-04-01 2
5430 Pirlot assistant 3 400 0 2018-06-01 1
(N~~:~'~ ' ,,;',' '.<),,V,;,, ;;,, ,, ...
1 vente Bruxelles
2 production Wavre
3 finance Bruxelles
4 support Wavre
Sélection simple
L’instruction suivante sélectionne toutes les colonnes et toutes les lignes de la table EMPLOYE:
Pour n’afficher que la colonne NOM dans l’ordre alphabétique
Plusieurs clés de tris successives peuvent figurer derrière order by. Le tri s'opèrera d'abord sur les
valeurs de la première colonne de la liste, et en cas de valeurs identiques, un tri supplémentaire
aura lieu sur les valeurs de la seconde colonne et ainsi de suite. Par défaut, l'ordre de tri est
ascendant. Pour obtenir un tri en ordre descendant, il faut rajouter la clause d e s c e n ding (ou
simplement desc) derrière la colonne de tri correspondante.
Avec la requête suivante, le résultat sera trié d'abord par ordre décroissant de la fonction, puis, au
sein de chaque groupe d'employés de même fonction, par ordre croissant du nom.
BDD 61
Lignes dupliquées
La clause DISTINCT permet d’obtenir les occurrences uniques d’un seul résultat. Par exemple,
l’instruction suivante n’affiche qu’une seule fois les valeurs de la colonne FONCTION.
Le résultat de cette instruction affiche les 7 fonctions différentes occupées par les 14
collaborateurs de la table EMPLOYE
,'
f~·
FONCTION
~~~- ~~~-~-.i;"'""""...,,..-----~~
l
c.omptable
ld~gne,
dnr~cteur
manager
~ ~~-~-~=-..--:-
1
1
monteur
~- >"', :e: l4S('. •<. -
.
.... -~.,....l"l'7:+: ... ~..,.,.,,t?o/--;..,.,..~,ll"'..,..J"Jl"!r:,...,.,,._.,.,,.,..,..,.,....f
l
ii vendeur
DISTINCT s’applique au combinaisons de valeurs de toutes les colonnes sélectionnées. Par

exemple, l’instruction suivante affiche uniquement les combinaisons différentes d’une fonction
(FONCTION) et d’un département (NUMDEP)
Conditions de sélection
L’instruction suivante filtre les lignes de la table EMPLOYE sur la base d’une condition de sélection
sur la colonne FONCTION.
Les opérandes alphanumériques d'une condition sont délimités par des guillemets (ou guillemets
simples). Les opérandes numériques, eux, ne doivent pas être délimités.
Les conditions de sélection peuvent inclure :
• des opérateurs de comparaisons: =, >, >=, <, <=, != (pour« différent de »8) ;
• des opérateurs relationnels: between <valeur 1> and <valeur 2>, in (<liste de valeurs>) ;
• un opérateur de recherche de patrons : 1 i ke combiné avec le symbole %, qui remplace une
chaîne de caractères de longueur quelconque, et/ou avec le symbole _, qui remplace une
seule position ;
• des fonctions, comme CURRENT_ DATE () qui renvoie la date système;
• des opérateurs logiques: and, or, not et xor, ainsi que des parenthèses pour combiner et
grouper des conditions de sélection.
• Le Tableau 5 montre des exemples de conditions de sélection qui pourraient compléter
l'instruction suivante :
-1; - - ~ ...··Y":;';,,.~::." ... .... •..-.•.,,. ..,._.,....,..._......... .. ·.•.•.• ·.•.;. •.::·:?w::::::::···:<:::::i'.;•:·:·· .
EMPLOYE
•,.,.
·. ·-·=·-·····-
____ -;:§~15Jj'.ii:i_'1Ii;i.;,, ,
BDD 62
~fü~.ès1·2B~~~I~
-=-,--=-,-=-,,.c,.;;
. <
J9~i~ i:~fü1f~ûdi~t9'H; ~·êp~de

Plusieurs critères de sélection peuvent être combinés avec des opérateurs logiques:
• and : « et » logique, qui calcule l'intersection des lignes sélectionnées par chacun des cri-
tères, comme l'illustre l’image ci-dessous;
• or:«ou»logique, qui calcule l’union des lignes sélectionnées par chacun des critères. Une
ligne satisfaisant à plusieurs critères ne sera reprise qu'une fois;
• xor : « ou exclusif» logique, qui calcule l'union des lignes sélectionnées par chacun des critères
en excluant les intersections, à savoir les lignes qui satisfont au plus à un critère.
select*
from EMPLOYE
where SALAIRE> 5000 SALAIRE > 5000
and PRIME is null
and NUMDEP = 2
PRIME
is null
select*
from EMPLOYE
where SALAIRE > 5000
or PRIME is null
or NUMDEP = 2
Par contre, l'opérateur n o t n'a qu'un seul argument, à savoir le critère ou l'opérateur qui le suit.
Les parenthèses sont utiles pour regrouper les critères de manière à expliciter leur ordre
d'exécution. Par exemple, l'instruction suivante affiche les employés :
• qui ont un salaire supérieur à 6 000 et une prime non NULL ;
• ou qui travaillent dans le département 2 et qui ont une prime égale à NULL.
Certaines expressions en langage naturel se montrent ambiguës quand il s'agit de les convertir en
une requête SQL. Par exemple, pour afficher la liste des assistants e t des monteurs, il faudra
transposer le e t français en o r SQL.
BDD 63
Notons que dans cette dernière instruction, les deux conditions doivent être complètement
exprimées même si elles portent sur la même colonne (la formulation FONCTION = "assis-
tant" or "monteur" est erronée). Une formulation équivalente et plus compacte est
Données dérivées. Le SQL est capable de calculer des résultats dérivés à partir d'expressions
combinant des colonnes, des opérateurs et des fonctions. Les expressions définies au niveau de la
clause s e l e c t sont évaluées pour chaque ligne du résultat. Une expression peut être rebaptisée
avec le mot dé as (technique des alias). Dans l'exemple suivant, le système affiche
une colonne dérivée, baptisée BONUS, et calculée comme étant 25 % du SALAIRE:
Le résultat est le suivant :
De telles expressions peuvent figurer à plusieurs endroits de l'instruction, comme dans des
critères de sélection ou des tris.
Le SQL définit un ensemble de fonctions pour transformer les données au sein d'expressions.
Voici quelques exemples :
• extract (year from <argument>) : retourne l'année d'un argument de type date;
• power (<x>, <y>) : élève x à la puissance y;
• coalesce (<argument>,<valeur si NULL>) :renvoie une valeur non NULL précisée en second
argument si la valeur spécifiée en premier argument est NULL.
Les éditeurs de SGBD implémentent plus ou moins librement les fonctions du standard SQL. Par
exemple, le système MySQL propose la fonction i f n u l l plutôt que la fonction standard
coalesce. On se réfèrera aux documentations des SGBD pour la syntaxe détaillée de leurs
fonctions.
Voici quelques illustrations avec MySQL
Le résultat (partiel) de cette dernière instruction est:
BDD 64
Agrégation et groupage. Ces facilités sont très utilisées pour l'aide à la décision. Elles pro-
duisent des résultats agrégés comme des comptages ou des moyennes. Par exemple, la requête
suivante calcule le nombre de lignes (count (*) ) , la moyenne des salaires (avg pour average) et
l'écart entre le salaire le plus élevé (max) et le salaire le plus bas (min) de la table
EMPLOYE.
Voici le résultat :
L'expression count (colonne) retourne le nombre de valeurs d'une colonne. En ajoutant d i s t i n c

t , le système comptera le nombre de valeurs différentes de la colonne. Par exemple, la requête
suivante retourne le nombre total de valeurs dans la colonne FONCTION et le nombre de valeurs
différentes dans cette même colonne :
Le résultat est le suivant:
La clause group by regroupe les lignes ayant des valeurs identiques pour l’expression qui suit
cette clause. Des données agrégées peuvent être calculées pour chaque groupe de lignes avec
les opérateurs comme sum, count, avg, etc. Par exemple:
Le résultat affiche des données agrégées pour chaque groupe d'employés de même départe-
ment. Notons que les employés sans département (ici, un seul employé) sont repris dans un
groupe dont la valeur de NUMDE P est NULL :
Les résultats agréés peuvent faire l’objet de sélections après regroupement avec la clause having.
Par exemple, la requête suivante n’affiche que les groupes dont la somme des salaires est
supérieure à 25000
BDD 65
Rien n’empêche de stipuler une clause WHERE dans une requête de groupage. WHERE filtrera les
lignes avant l’agrégation, alors que having filtrera les résultats agrégés. Par exemple, la requête
suivante va afficher des données sur les départements comptant plus de 2 employés gagnant au
moins 5000
Cette instruction peut s'interpréter comme suit :
where group by
• Uniquement
• Uniquement les • Calcul les agrégats
• Tous les enregistrements des agrégats sélectionnés
enregistrements sélectionnées par par la clause
la clause where • Ex. : liste agrégée having
• Ex.: tous des départements
les employés • Ex. : uniquement avec la somme • Ex. : uniquement
les employés qui des salaires et la liste des
gagnent plus le nombre départements
de 5000 d'employés qui comptent plus
de deux employés
Notons finalement que plusieurs clés de groupage sont permises. Par exemple, l’instruction
suivante calcule la somme des salaires pour chaque groupe d’employés qui ont la même fonction
et le même numéro de département:
Voici le résultat :
BDD 66
Valeurs NULL. Les valeurs NULL exigent la plus grande attention dans la formulation de
requêtes. Sans rentrer dans les détails, ces valeurs NULL se propagent selon les règles (simpli-
fiées) suivantes :
• sum Imin Imax Iavg (ensemble de valeurs) = NULL si l'ensemble des valeurs à
traiter est vide, mais count (ensemble de valeurs) = 0 pour un ensemble vide;
• une expression dont un des arguments est NULL renvoie NULL.
Par exemple, l'instruction suivante renverra une valeur NULL pour TOTAL quand la PRIME est une
valeur NULL.
Par exemple, l'instruction suivante renverra une valeur NULL pour TOTAL quand la PRIME
est une valeur NULL.
Voici le résutalt partiel de cette instruction :
6.2. Sous-requête
Une fonctionnalité remarquable du SQL est la formulation de critères de sélection incluant une
sous-requête introduite par un second select.
Par exemple, pour afficher la liste des noms des départements qui emploient un a s s i s t a n t ,
on devrait a priori :
1. rechercher, à partir de la table EMPLOYE, les numéros des départements dans lesquels il y a
des assistants ;
2. utiliser le résultat de cette première requête pour afficher, dans une seconde requête sur la
table DEPARTEMENT, les noms des départements correspondants, comme le montre l’image ci-
dessous.
select NUMDEP
from EMPLOYE
ltMDEPI
where FONCTION = "assistant"
select NOM NOM

from DEPARTEMENT vente
roduction
where NUMDEP in (1, 2)
Figure 3-21: combinaison de requêtes.
Cette manière de faire n'est pas très commode. Heureusement, la technique des sous-requêtes
perm~t de combiner deux requêtes en une seule :
BDD 67
On arrive donc à sélectionner des lignes de la table DEPARTEMENT accédé par la requête
principale sur la base de critères impliquant la table EMPLOYE accédé par la sous-requête. Le
critère de sélection de la requête principale compare ici les valeurs de la clé primaire de
DEPARTMENT avec les valeurs de la clé étrangère d,EMPL0YE.
Les techniques des sous-requêtes a de nombreuses applications, comme le montrent les

quelques exemples du tableau ci-dessous
6.2.1. Sous-requêtes à plusieurs niveaux
COMMANDE (NUMCOM •... ,NUMCLI)
Ll(;NECOM (NUMCOM/ART, ... )
ARTICLE (NUMART •... GROUPE)
Figure 3-22: exemple de schéma à quatre tables.
Pour connaître les noms de clients qui ont commandé un article du groupe VTT, il faut filtrer
les clients ... dont les commandes contiennent des lignes de commande elles-mêmes liées à un
article dont le groupe est VTT :
Ici, chaque niveau de sous-requête est coordonné avec le niveau supérieur sur la base d’égalités
entre clé primaire et clé étrangère.
BDD 68
6.3. Jointure
La technique des sous-requêtes permettait déjà de manipuler plusieurs tables dans une
même instruction, mais en n’affichant que des colonnes de la table accédé par la requête
principale.
La technique des jointures autorise l’affichage de colonnes de tables différentes avec la même
instruction. Les tables accédées sont coordonnées (ou jointes) avec des conditions de jointure.
Ces dernières sont presque toujours basées sur des égalités entre clés primaires et clés étran-
gères.
6.3.1.Jointure interne
L'accès à des colonnes de tables différentes requiert de spécifier la liste de ces tables après la
clause f rom. Les colonnes de toutes les tables sont alors traitées identiquement et peuvent faire
l’objet de critères de sélection, d'expressions, de tris ou de groupages.
L'instruction suivante affiche les noms des départements et les noms des employés qui y
travaillent, triés selon ces colonnes. Elle joint les tables EMPLOYE et DEPARTEMENT avec le mot
clé join. La correspondance entre la clé primaire et la clé étrangère est exprimée par la condition
de jointure placée derrière le mot clé on. Comme la clé primaire et la clé étrangère portent le
même nom - NUMDE P - , on les préfixe du nom de la table source et d'un point pour lever
l'ambiguïté de leur appartenance à une table. La même technique s'applique aux colonnes
NOM, elles aussi présentes dans les deux tables jointes.
Le résultat est repris ci-dessous :
venté .
Cependant, seuls les employés rattachés à un département sont affichés, excluant l'employé
Geldorf qui n'est rattaché à aucun département. C'est le sens de la jointure interne, qui ne
reprend que les lignes pour lesquelles il y a une correspondance dans les tables jointes.
Précisons que des tables peuvent être jointes sur la base de n'importe quelle condition de
jointure et pouvant inclure par exemple des colonnes qui ne sont pas des clés primaires ou
étrangères, ou des opérateurs autres que l'égalité.
BDD 69
6.3.2.Jointure externe
La jointure externe inclut dans le résultat les lignes qui n'ont pas de correspondance dans les
tables jointes. Elle est exprimée par les mots clés [left I right I full] outer join. Par exemple,
l'instruction ci-dessous affiche tous les employés, y compris ceux sans département. L'expression
left outer join signifie que la table à gauche du mot j o i n sera complètement affichée.
À l'inverse, il est possible d'afficher tous les départements, y compris ceux qui ne sont pas atta-
chés à un employé, avec la formulation suivante de la jointure :
La combinaison full outer j oin inclut toutes les lignes sans correspondance en provenance des
deux tables.
6.3.3.Jointure de plus de deux tables

La jointure peut porter sur un nombre quelconque de tables. Dans la requête ci-dessous, les
quatre tables du schéma de l’image p68 sont jointes avec 3 (à savoir - 1) conditions de jointure
pour afficher les noms des clients et les noms des produits qu'ils ont commandés :
CLIENT . NOM as ,-CJ!:. s;'Ç;',~il~ NoM:-
} oinCOMMANDE on CL . -~NUMcLr
>'; join LIGNECOM on ÇO OM .NUMCOM
join ARTICLE on LIGNE,C:,O
~ ÎENT. NOM, ARTICLE. tqOM ,,
Notons encore que:

• d i s t i n c t fait en sorte que toutes les lignes du résultat soient uniques, ce qui supprime les
redondances quand le même client a commandé plusieurs fois le même article ;
• les tables CLIENT et ARTICLE sont connectées entre elles via les tables COMMANDE et
LIGNECOM, qui doivent figurer dans la clause from même si les colonnes de ces deux dernières
tables ne sont pas utilisées dans le reste de l'instruction.
6.3.4.Full outer join et union

Le full outer join n’est pas supporté par tous les SGBD, mais il peut facilement être simulé avec
l'opérateur ensembliste union.
Les opérateurs ensemblistes combinent des requêtes entre elles avec des unions (union), des
intersections (intersect) et des différences (except). Par exemple, l’instruction suivante combine
deux requêtes différentes sur la même table:
" ' t""c,f~f:1,/1I'ONCT
seJ.f;7c:: .• '·<•" · ION, SALAI RE. ·.j/··
.; rroriJ,iiEJ~·ftiliiQJt'E'.r •·
~l?E/ > .ssoo
<= 5500
BDD 70
Pour réaliser un full outer join, il suffit de réaliser l'union d'une instruction avec une jointure
externe à gauche et de la même instruction mais avec une jointure externe à droite.
6.4.Modification de données
Le SQL permet naturellement de créer, de supprimer ou de modifier des données. En pratique,
ces opérations sont souvent effectuées par l'utilisateur à travers des programmes d'application.
Cependant, les utilisateurs avertis peuvent utiliser directement le SQL pour traiter un ensemble de
données avec une seule instruction, comme augmenter les salaires de tous les
employés.
Insertion. L'instruction suivante crée des lignes dans une table existante:
Dans l'exemple qui suit, un département marketing est inséré dans la table DEPARTEMENT:
PAR'I'EMENT
,,. /~- /,
rketing", "N . -0-~
Si on ne spécifie pas une valeur pour toutes les colonnes, il faut préciser celles qui seront ali-
mentées:
Effacement. La commande de su ression de li nes est la suivante :
Par exemple, voici comment supprimer les employés du département 1 :
Modification. L'instruction update modifie les données d'une table:
L'instruction suivante change la fonction des assistants et leur attribue une prime égale à 15 %
de leur salaire :
6.5. Vue
Une vue est une table virtuelle qui résulte d'une requête sur les tables du schéma. Une vue per-
met d'offrir à l'utilisateur une perspective personnalisée sur la BD, notamment en lui masquant
l'éventuelle complexité de son schéma. Les vues peuvent aussi aider à contrôler les accès aux
données sensibles, par exemple en limitant l'accès d'un utilisateur à une vue qui ne sélectionne
que certaines données, et l'empêchant ainsi d'accéder aux données non sélectionnées par la vue.
Les vues sont exploitées exactement comme des tables hormis certaines restrictions relatives aux
mises à jour. Par exemple, l'instruction suivante crée une vue sur la table EMPLOYE
ereàte, ~±~w'~vÛE · GRH
' - EPARTEMENT.
_;;,._
NOM as ' .. . . ·. . ' - .
:IRE* 1.1 a!?
Joi:- -•«" ·. - -"- .. - -
Une vue s'utilise tout comme une table :

BDD f:ronr VUE GRH 71
Une vue n’est pas une copie de quelque donnée que ce soit, mais elle est bien recalculée à
chacune de ses utilisations en accédant aux données des tables sources.
7. Big Data
Le développement phénoménal de nos univers digitaux a fait émerger de nouvelles sources et
formes de données, telles que :
• les traces laissées par les utilisateurs humains, comme des messages postés sur les réseaux
sociaux ou des évaluations de produits ;
• les données contenues dans des historiques de navigation de sites Web, reprenant par exemple
les temps de connexion ou le pays d'origine des internautes ;
• les données générées par des équipements, comme des senseurs RFID (Radio Frequency
Identifers) , des systèmes de géolocalisation des terminaux mobiles, et plus généralement par
des objets connectés (Internet ofThings).
On les désigne par le terme Big Data, même si ce concept n'est pas encore formellement défini
et est parfois présenté comme un ensemble d'approches pour traiter des ensembles très
volumineux de données. L'analyse des Big Data est susceptible de mettre en lumière des
informations nouvelles, comme des tendances dans la consommation ou des opinions
dominantes.
Définiton: les données du Big Data sont des ensembles très volumineux de données structurées
ou non qui présentent un intérêt en termes d’analyse automatique en vue de déduire de
l’information nouvelle.
7.1. Propriétés
Les données du Big Data sont souvent caractérisées par 3 propriétés principales:
• Volume : la production annuelle est estimée à quelques dizaines de zettabytes10
• Variété : les formats des données du Big Data sont très diversifiés, incluant par exemple des
données structurées comme celles générées par des senseurs, mais aussi des-vidéos (You- Tube,
caméras de surveillance, etc.), du contenu texte (mails, tweets, etc.), etc.
• Vélocité : les données du Big Data sont produites à une fréquence élevée. Leur valeur peut
dépendre de la rapidité de leur traitement pour certains processus nécessitant une analyse en
temps réel (Streaming Analytics). En effet, certaines données doivent être exploitées rapidement
pour déboucher sur des actions immédiates, comme l'atterrissage d'un avion dont l'analyse des
données techniques de vol laisse présager une panne imminente.
7.2. Applications
Les applications du Big Data fleurissent dans tous les domaines où la digitalisation s'intensifie,
comme la médecine, la météorologie ou l'économie. L'entreprise, elle aussi, profite des
opportunités du Big Data pour améliorer sa compréhension de son environnement, de ses
clients et de son fonctionnement. Et c'est l'ensemble des fonctions de l'entreprise qui est
concerné. Par exemple:
• l'e-réputation d'une entreprise peut être mesurée à partir des commentaires et évaluations
postés sur des réseaux sociaux, et aider un responsable marketing à valoriser l'image de
l'entreprise ;
• l'activité physique des employés peut être suivie à partir des données produites par des
montres connectées. Cela peut aider un responsable du personnel à décider des programmes
de bien-être au travail;
BDD 72
• la production de produits finis peut être suivie en temps réel par le responsable de la
production en plaçant des puces RFID sur les matières premières et les produits semi-finis. Il peut
alors analyser l'évolution de la production et détecter les postes de travail qui ralentissent le
rythme de production, puis décider ensuite d'actions pour adapter la capacité des goulots
d'étranglement et harmoniser les cadences de l'ensemble de la chaîne ;
• le comportement des clients est analysé par le responsable commercial, par exemple à travers
leurs achats et les messages qu'ils postent, afin de détecter des signes avant-coureurs d'attrition ;
• le suivi de la flotte de transport peut être réalisé en temps réel par le responsable de la logis-
tique grâce aux données de géolocalisation produites par les véhicules.
7.3.Technologies spécifiques
Les SGBD traditionnels sont peu adaptés pour traiter le Big Data,
essentiellement à cause des volumes et de la variété des formats de ces données. On utilise
donc des technologies ad hoc, comme des BD avec des modèles spécifiques, comme NoSQL,
ou des techniques de traitement massivement parallèles, comme le Cloud ou les technologies
Hadoop.
Les technologies Hadoop sont Open Source. Elles ont été développées à l'origine par les grands
acteurs du Web comme Yahoo! et sont largement utilisées par Facebook, Twitter, Linkedln, etc.,
ainsi que par les éditeurs de solutions analytiques du Big Data.
Elles mettent en œuvre un environnement pour déployer des applications distribuées afin de
traiter des gros volumes dans des délais raisonnables. L'idée est d'appliquer l'adage « diviser
pour régner » tant au niveau des données que des traitements. Hadoop distribue le travail
d'analyse sur un grand nombre de machines fonctionnant en parallèle à travers un réseau. Le
nombre de ces machines, souvent localisées dans le Cloud, peut être adapté en fonction de la
charge.
Finalement, les SGBD NoSQL sont des SGBD optimisés pour de gros volumes de données. Afin
d'augmenter la vitesse de traitement, ces systèmes adoptent des modèles de données simplifiés
et non relationnels. Ils ont été épurés de certaines fonctionnalités des SGBD classiques, comme la
gestion des transactions, voire carrément le langage SQL. Ces systèmes sont prévus pour
fonctionner dans des réseaux de serveurs Cloud. Citons notamment les systèmes Big- Table
(Google), Project Voldemort (Linkedln) ou MongoDB. Là encore, les gros acteurs du Weh sont à
l'œuvre : ne trouvant pas de solution suffisamment performante pour gérer leurs énormes
volumes de données, ils ont développé leurs propres technologies, quitte à sacrifier certaines
fonctionnalités pourtant essentielles dans de nombreux domaines d'application, comme les
contrôles d’intégrité.
BDD 73
Chapitre 4: Aide à la décision
1. De la décision la Business intelligence

Les managers sont amenées à prendre des décisions à différents niveaux et selon un processus
organisé. Ils s'appuient pour cela sur un système de Business Intelligence, qui est la forme que
revêt un système d'aide à la décision dans l'entreprise.
1.1.Niveaux de décision
Gérer, c'est aussi décider. Les managers sont amenés à prendre des décisions à trois niveaux:
• Des décisions opérationnelles, essentiellement routinières et répétitives. Ces décisions sont

largement programmables, c'est-à-dire qu'elles peuvent être supportées par les systèmes
informatiques.
• Des décisions tactiques, relatives à des problèmes relativement maîtrisés et pour lesquels les
managers disposent d'une expérience et de schémas de réponse existants. Ces décisions
peuvent s'appuyer sur des systèmes informatiques, comme des modèles de prédiction, mais
restent du ressort des acteurs humains.
• Des décisions stratégiques, liées aux orientations générales de l'organisation. Ces décisions
intègrent le jugement, l'intuition, la créativité et l'expérience. Elles sont peu structurées et
faiblement automatisable. Les systèmes informatiques peuvent cependant fournir des
informations précieuses pour alimenter le processus de décision stratégique.
ex. : décision d'entrer décisions

Niveau ou de sortir de certains marchés,
stratégique non structurées
choix d'objectifs
stratégiques
;~~![==================~ ~====================~
ex. : planification
Niveau tactique de la production, élaboration
de modèles de rentabilité
ex. : recommandation
Niveau d'articles aux clients,
opérationnel réalisation d'opérations décisions
boursières programmables
1.2.Processus de décision
Les décisions sont prises suivant un processus qui s'articule sur les étapes de l’image ci-dessous
1) La détection et la compréhension d'un problème ou d'une opportunité. Par exemple, une
nouvelle molécule est développée par le département R&D d'une firme pharmaceutique. Une
décision doit être prise concernant le lancement d'un médicament basé sur cette molécule.
2) La préparation de la prise de décision : les données utiles pour la décision sont collectées,
puis analysées à travers différents modèles de calcul. Par exemple, des données concernant
des tests d'efficacité ou des estimations des coûts et de revenus vont être traitées par
différents modèles de prédiction d'efficacité, de rentabilité, etc.
3) La prise de décision et son implémentation : en fonction des résultats de l'étape précé- dente,
un choix est posé et des actions correspondantes sont réalisées. Par exemple, une entreprise
va décider du lancement d'un nouveau médicament, de son prix de vente, de son volume de
production, etc., et mettre en œuvre ce qu'elle a décidé.
BDD 74
4) Le résultat est évalué, et un nouveau cycle recommence pour encore améliorer la réponse au
problème ou à l'opportunité de départ. Par exemple, l'entreprise va évaluer le succès
thérapeutique et commercial d'un médicament. En cas de faibles performances, d'éventuelles
actions correctrices seront décidées, comme réduire le prix de vente. En cas de bons résultats,
l'entreprise va décider d'actions de développement de ses ventes à partir des données du
marché, de la concurrence, de coût de production de masse, etc
Identifier et comprendre
un problème ou
une opportunité
!
Évaluer les résultats Préparer la décision
\ /
Prendre la décision et
déployer la solution
1.3.Limites de processus de décision

Malgré tous les efforts des managers, la qualité du processus de décision est entravée pour
plusieurs raisons qui sont exposées ci-dessous.
Tout d'abord, les décideurs n'optimisent pas toujours le processus de décision. Ils se contentent
parfois d'une décision satisfaisante, mais qui n'est pas nécessairement la meilleure, ou dont on
ne peut pas démontrer qu'elle est la meilleure. Cela se produit notamment lorsque :
• les données requises pour la prise de décision sont totalement ou partiellement indisponibles ;
• les modèles pour traiter l'information sont trop complexes ou trop coûteux à développer;
• le temps disponible pour prendre la décision est limité ;
• les compétences du décideur sont limitées.
Ensuite, des données et des modèles corrects peuvent mener à de mauvaises décisions à cause
de biais introduits dans la sélection des données et des modèles. Par exemple, nous avons une
tendance naturelle à rechercher des faits qui corroborent nos propres jugements, et à négliger
des informations complémentaires qui vont à l'opposé. Ou encore, nous sélectionnons parfois
l'information en fonction de la qualité perçue de la source plutôt qu'en fonction de la qualité de
l'information elle-même.
Finalement, le processus d'une prise de décision en groupe peut induire un choix trop rapide et
peu argumenté sous la pression sociale ou par facilité. Si des décisions en groupe se justifient
pour traiter de questions complexes ou pour gagner une adhésion large, elles peuvent être
influencées par une dynamique de groupe déséquilibrée, notamment à cause d'une influence
exagérée de membres autoritaires.
1.4.Système d'aide à la décision Interface
Définition: un système d’aide à la décision est un système informatique Visualisation J

[___o_iff_u_s_io_n_ _
conçu pour faciliter la prise de décision en produisant de l’information sur

la base d’analyse de données. \.
Répertoire de connaissances
L'architecture typique d'un système d'aide à la décision inclut, comme [ Modèles de traitement
]
d'autres systèmes informatiques, des répertoires de données et de Répertoire de données
connaissances, des outils de traitement et une interface. [ Internes

J( Externes
]
BDD 75
Plus précisément, les systèmes d'aide à la décision traitent des données en provenance :
• de sources internes à l'organisation, à savoir essentiellement les systèmes transactionnels,
comme les données relatives aux achats d'un client enregistrées dans un système ERP (Enter-
prise Ressource Planning) ou un logiciel CRM (Customer Relationship Management);
• de sources externes, comme les avis postés par un client sur les réseaux sociaux à propos
des produits de l'entreprise.
Ensuite, ils mettent en œuvre des modèles de traitement qui organisent, connectent et analysent
des données pour produire des formes variées de connaissances. Les principales catégories de
modèles sont :
• les modèles d'analyse descriptive, visant la description d'un état existant et la caractérisation
des données, comme une pyramide d'âges des employés ou une distribution géographique
des ventes;
• les modèles prédictifs, visant la projection d'un état futur. Leur principe est d'induire des
valeurs futures à partir de modèles et de données connues, comme l'estimation des ventes
à venir en fonction des ventes passées ;
• les modèles prescriptifs visant la proposition d'un état souhaitable, comme l'adaptation
automatique de la tarification d'une compagnie aérienne.
Finalement, ces systèmes sont manipulés par une interface qui dispose :
• d'outils de visualisation pour présenter la connaissance produite, comme des histogrammes,
des nuages de points, ou des arbres de décision ;
• de mécanismes de diffusion de la connaissance, comme la publication de tableaux de bord
sur le Web ou l'envoi d'alertes.
Les qualités espérées d'un système d'aide à la décision sont au minimum:

• L'interactivité : les utilisateurs souhaitent des visualisations des résultats qui sont modifiables en
temps réel. Par exemple, un vendeur voudra voir un graphe de l'évolution des
ventes par année, puis le modifier pour voir les ventes par trimestre.
• La facilité d’utilisation: l’aide à la décision concerne de plus en plus de collaborateurs et doit

donc être intuitive et disponible sur des terminaux légers comme des smartphones.
• La flexibilité : les contextes, les métiers et les besoins des organisations sont d'une telle variété
qu'imaginer une solution standard et/ou figée n'est pas réaliste. Les systèmes d'aide à la
décision sont donc pensés comme des boîtes à outils proposant une panoplie de modèles de
calcul, de types de visualisations, etc. permettant de construire une solution adaptée et
évolutive pour chacun.
1.5. Business Intelligence

On trouve des systèmes d'aide à la décision dans de nombreux domaines d'application, comme
la médecine ou la physique. Dans l'entreprise, l'aide à la décision s'appelle Business Intelligence
(BI). Ce terme est assez générique et englobe notamment des technologies, des méthodes ou
des applications. Globalement, l'intention du BI est de donner aux managers un accès aisé aux
données et aux outils d'analyse pour mieux
décider et agir.
Définition: un système de Business Intelligence (BI) est un système d’aide à la décision conçu pour
le manager, et qui vise à:
BDD 76
- cerner l’état courant de l’organisation et de son environnement;

- Induire la transformation: données -> informations/connaissances -> décisions -> actions
Un système BI permet de mesurer la performance courante de l'entreprise et de la comparer

aux objectifs fixés. Par exemple, le BI produit des tableaux de bord de gestion reprenant des
indicateurs de performance, comme le chiffre d'affaires (CA) mensuel, le nombre de clients
satisfaits ou un indice de productivité des collaborateurs, ainsi que des indicateurs liés à
l'environnement, comme les parts de marché des concurrents ou des données macro-
économiques.
Toutes ces informations aident les managers à décider des actions qui vont contribuer à atteindre
les objectifs fixés.
Le système BI détermine également dans quelle mesure les objectifs sont rencontrés à la
suite des actions réalisées. Il intervient donc en amont et en aval de la décision/action, et
s'inscrit dans un cercle vertueux d'amélioration continue, où l'effet des actions est évalué
pour déboucher ensuite sur de nouvelles décisions/actions correctrices.
Conformément à l'architecture des systèmes d'aide à la décision, un système BI (Sharda, Delen, &
Turban, 2014) se décompose sans surprise en:
• un entrepôt de données (Data Warehouse) : il s'agit d'un répertoire centralisé où sont stockées
les données utilisées pour l'analyse et les résultats de traitements analytiques;
• des outils de traitements de données (Business Analytics) pour produire des informations et des
connaissances à partir de différents modèles de calcul ;
• une interface utilisateur, avec des outils de reporting et de visualisation interactive des don-
nées, de l'information et de la connaissance
2. Data Warehouse
L'analyse de données à des fins décisionnelles pose plusieurs défis techniques, dont l'accès aux
données et la performance des traitements analytiques.
En effet, les données d'une entreprise sont parfois dispersées dans plusieurs systèmes
informatiques distincts dont les schémas de données peuvent être différents. Or, certaines ana-
lyses nécessitent d'accéder à l'ensemble de ces données. Par exemple, une entreprise de la
grande distribution qui souhaite calculer l'évolution de CA total dans le temps devra intégrer les
données de chaque point de vente, et donc accéder à leur système informatique respectif, ce qui
n'est pas toujours aisé techniquement. Sans compter que les systèmes transactionnels ne
gèrent pas tous des historiques anciens, parfois bien utiles pour l'analyse.
Ensuite, les systèmes transactionnels restent limités en performance quand ils doivent traiter de
gros volumes à des fins décisionnelles, et des traitements analytiques pourraient dégrader les
temps de réponse des traitements transactionnels.
Voilà pourquoi bon nombre d'entreprises ont déployé un système BI distinct des systèmes
transactionnels, dont les données sont régulièrement transférées vers un entrepôt de données ou
Data Warehouse (DW). Le DW rassemble des données issues de plusieurs sources comme illustré
par l’image ci-dessous.
Définition: un entrepôt de données ou de Data Warehouse (DW) est une base de données qui
consolide des données à analyser à partir de différentes sources. Un DW assure la persistance
d’un système BI.
BDD 77
CA total du groupe par quadrimestre?

Distribution géographique du CA?
Classement par rapport à la concurrence?
Etc.
Data Warehouse
Banque Assurance Banque Assurance CA

branche Europe branche Europe branche USA branche USA des concurrents
2.1.Propriétés d'un DW
Un DW est une BD qui se distingue des BD transactionnelles par les propriétés suivantes :
• Un DW est orienté sujet, c'est-à-dire qu'il est conçu pour etud1er les donnees relatives à une
activité ou pour analyser certains indicateurs, comme la productivité, le CA ou la rentabilité. Par
contre, les systèmes transactionnels sont plutôt orientés processus, puisqu'ils visent
l'automatisation des processus d'affaires. Seules les données jugées pertinentes par rapport au
sujet analysé sont stockées dans le DW.
• Les données transférées dans un DW ne sont pas mises à jour. Par contre, un DW gère
l'historique des données, alors que les systèmes transactionnels sont généralement limités à un
historique récent.
• Un DW stocke, en complément des données à analyser:
o des données pré-agrégées pour une meilleure performance;
o des métadonnées, comme la source et la date de création des données au sein du DW.
• Les règles de construction du schéma du DW sont spécifiquement adaptées pour faciliter
l'analyse des données et la performance des traitements.
2.2.Architecture d'un DW
L’image ci-dessous montre comment des sources de données sont consolidées dans un DW pour
être analysées.
Gérer les transferts entre les sources et le DW est une tâche complexe assumée par trois com-
posants principaux repris dans une couche logicielle appelée couche ETL (Extract - Trans- form -
Load) :
• le moniteur, qui surveille les évolutions des données au niveau des sources. Lorsqu'une mise à
jour est détectée, le moniteur identifie les données à transférer vers le DW ;
• l'adaptateur, qui prépare l'intégration des données dans le DW en les transformant, par
exemple moyennant la conversion de différentes devises ;
• le médiateur, qui pré-agrège les données et les complète avec des métadonnées avant de les
intégrer dans le DW.
Le DW est géré assez classiquement par un SGBD. Ce dernier peut offrir certaines facilités
additionnelles, comme la réalisation de certains traitements préalables à l'analyse, tels que le
calcul de pré-agrégats. Les données sont traitées par des composants externes essentiellement.
Ces derniers réalisent du reporting, de l'analyse interactive (OLAP ou On Line Analytical
Processing ) ou encore du Data Mining.
BDD 78
SI trans.
reporting
,._ DW
J
::J
Fichiers Q)
C
+-'
CU
+-' ,._
a. ::J données
r
CU Q)
-0 +-'
OLAP
J
CU CU
,._
ETL -0
CRM -<1J
::J
Q) E agrégats
:!::'.
C
0
E
ERP métadonnées Data Mining
etc.
En pratique, le développement de la couche ETL est rarement simple, car elle doit aplanir des
différences de schémas et de formats entre des sources de données hétérogènes, mais aussi
corriger des incohérences, des manques ou des erreurs dans ces données. Certaines
transformations assurées par l'adaptateur relèvent d'ailleurs du « nettoyage » de données (data
cleaning).
Voici quelques exemples de problèmes à résoudre :

• des duplications des mêmes données au sein d'une même source ou au sein de plusieurs
sources;
• des incohérences dans l'encodage. Par exemple, les titres de personnes sont enregistrés avec
des valeurs différentes pour Monsieur, comme M, M., Mr., etc., ou pour Madame, comme Mme,
MME, Mlle , etc. Si on souhaite catégoriser des personnes selon le genre à partir du titre, des
transformations s'imposent pour uniformiser les valeurs.
2.3.Data Warehouse et Big Data

Les DW ont d'abord été conçus pour analyser des données stockées dans des BD
transactionnelles. Ces données ont une structure régulière et connue, et occupent des volumes
maîtrisables avec les SGBD traditionnels.
Plus récemment, les données du Big Data se sont invitées dans l'aide à la décision, non sans
amener de nouveaux défis techniques. En effet, le volume ou l'irrégularité de la structure des Big
Data complique la consolidation dans un DW unique supportant toutes les catégories de données
et leur traitement.
Les entreprises choisissent souvent de mettre en place des architectures complexes, combinant
par exemple une plateforme DW et une plateforme Big Data, pour rassembler ensuite les sorties
de différents sous-systèmes pour une visualisation intégrée des résultats des analyses.
3. Analyse descriptive avec les techniques OLAP

La première intention des systèmes BI est d'examiner l'état existant de l'entreprise avec des
modèles d'analyse descriptive. Par exemple, le BI va produire des rapports et des tableaux de
bord construits en agrégeant des données de la période en cours ou passée pour aider à décrire
des comportements présents ou passés.
3.1.OLTP et OLAP
La première préoccupation des éditeurs de SGBD a été de garantir une fiabilité et une
performance raisonnables pour l'exécution des transactions en temps réels. Les SGBD furent alors
pensés pour un mode de fonctionnement des BD appelé OLTP (On Line Transaction Processing)
BDD 79
qui met l'accent sur les mises à jour d'un volume contrôlé de données dans le cadre d'une
transaction, d'où l'appellation de BD transactionnelle et, par extension, de système
transactionnel.
L'avènement de l'informatique décisionnelle a poussé les éditeurs de SGBD à développer un
autre mode de fonctionnement des BD centré cette fois sur l'analyse de gros volumes, à savoir le
mode OLAP (On Line Analytical Processing). Le Tableau ci-dessous compare l'OLTP et l'OLAP.
Dans le mode OLAP, les données sont présentées sous la forme d'un hypercube, comme expliqué
ci-dessous. Techniquement, un hypercube est stocké dans un DW dont le schéma de don- nées
est spécifiquement conçu pour une analyse performante.
3.2. Hypercube de données.

Un hypercube de données est une métaphore pour visualiser les don- nées d'un DW de manière
condensée et expressive. Il matérialise l'évolution d'un phénomène à analyser selon différentes
dimensions susceptibles d'expliquer ses variations.
Concrètement, le phénomène à étudier, comme la performance commerciale ou la productivité,
prend la forme de variables, ou faits, souvent calculés à partir de fonctions d'agrégation.
Par exemple, la variable chiffre d'affaires total (CA) représente la somme des ventes et varie selon
les dimensions Temps, Géographie et Groupe de produits, comme illustré par l’image ci-dessous.
Géographie
Une valeur de la variable est calculée pour chaque
CA résultant des ventes
combinaison des valeurs des dimensions à partir des produits VTT en 2018
des données extraites des BD transactionnelles. BE - - - - - - - - - /J

pour le pays BE
,/ 1
/ /
Par exemple, le CA pour les valeurs des

('/~: ____
// / 1
/ / 1
dimensions Temps = 2018, Géographie = BE et -~ :

Groupe de produits = VTT est calculée comme la
1 1 1
1 FR 1 1
1 1 1
somme des montants des ventes de 2018 1

1
1
20117
1
12018 2019
1 équipement Temps
réalisées en Belgique pour les VTT, et vaut en 1
1 /
/
/
1 /
l'occurrence 12 6 9. 1
1 1/ /
/
/
____ J
Temps
Groupe de produits
2016 2017 2018 2019
Belgique
Un hypercube reprend toutes les valeurs
CU
France ..c possibles des variables étudiées. Par exemple,
Q.
Luxembourg C'I la Figure 4-7 montre qu'un hypercube contient

0
-CU
C,
des valeurs de CA pour:
• toutes les combinaisons de valeurs de
Temps, de Géographie et de Groupe de pro-
BDD 80
Figure 4-7: exemple de cube construit sur le CA.
d u i t s , représentées par des cellules claires;

• tous les agrégats de lignes, de colonnes, de plans et de volume, représentés par les cellules
grisées
Dans l’exemple ci-dessous, sont extraites avec une requête de jointure pour produire les données
cibles de l'analyse :
• une colonne MontantVente est calculée comme PRIXVENTE * QUANT ;
• une colonne Géographie contient le pays de la vente et est déduite de la colonne CODE
POSTAL de la table CLIENT ;
• une colonne Temps reprend l'année de la colonne DATE COMMANDE;
• une colonne GroupeProduits contient la colonne CATEGORIE de la table ARTICLE.
Ces données peuvent être insérées puis exploitées au sein d'un DW pour former par exemple :
• un plan calculant le CA à partir de la somme des valeurs de la colonne MontantVente selon les
dimensions Temps (année) en tête de colonnes, et Géographie (pays) en tête de lignes. Le CA est
calculé pour chaque combinaison de Temps et Géographie, mais aussi pour chaque colonne,
chaque ligne et pour l'ensemble du plan (affiché en grisé);
• un cube, dont chaque tranche correspond à une valeur d'une troisième dimension
G r o u p e P r o d u i t s . À nouveau, les cellules grisées contiennent tous les sous-totaux
possibles.
Données transactionnelles Plan (hypercube à 2 dimensions)
MontantVente Géo ra eProduits CA 2016 2017

100 FR BE 1020
54 FR 2018
64 FR 2018 VIT
150 FR 2018 VIT
140 FR ement
40 FR ement
480 FR ement Cube (hypercube à 3 dimensions)
120 FR ement
140 FR ement GroupeProduit=VTT
50 FR 2017 é ui ement CA 2016 2017
BE
36 FR 2018 cit
Grou
300 FR 2018 VIT
CA
200 FR
BE 270
140 BE
Grou eProduit=équi
54 BE
CA 2016 201
130 BE BE 305
60 BE 2017 cit
Des opérations comparables peuvent produire des hypercubes dont le nombre de dimensions est
supérieur à 3.
3.3. Nature d'une dimension

Une dimension peut être graduée selon différentes échelles imbriquées dans des hiérarchies. Par
exemple, la dimension Temps peut être échelonnée d'abord en années, puis en mois et enfin en
jours, soit selon une hiérarchie AnnéeVente -> MoisVente -> JourVente. Des colonnes reprennent
alors les données transactionnelles pour ces hiérarchies, comme dans l'exemple du ci-dessous.
BDD 81
Une dimension peut également recouvrir plusieurs attributs. Par exemple, la dimension Produit
peut comporter un attribut Catégories, Game et PublicCible.
Definition : un hypercube résulte du calcul des valeurs d’une ou plusieurs variables ou faits selon
les valeurs possibles de plusieurs dimensions. Une dimension peut s’exprimer selon des échelles
de granularités différentes et peut contenir plusieurs attributs.
3.4.Opérations sur un hypercube.

Un utilisateur peut visualiser un hypercube comme il le souhaite à travers différentes opérations :
• La sélection des dimensions. Par exemple, on choisit de représenter le CA selon les dimensions
Géographie et Groupe de produits, sans considérer la dimension Temps.
• Drill down: une dimension est affinée en utilisant une unité plus petite, autrement dit en
descendant dans la hiérarchie de la dimension. Par exemple, on passe d'une visualisation du CA
par année à une visualisation par mois.
• R o l l u p : à l'inverse de l'opération précédente, on visualise l'hypercube avec une dimension
de granularité moins importante, ou en remontant dans la hiérarchie de la dimension.
• S l i ce : on sélectionne une « tranche » de l'hypercube en fixant la valeur d'une ou plusieurs
dimensions. Par exemple, on fige le temps à l'année 2018 et on visualise le CA de cette année
selon les autres dimensions.
3.5.Spécification d'un hypercube

En pratique, les managers doivent indiquer aux informaticiens quelles sont les variables qui
décrivent le fait qu'ils souhaitent étudier, ainsi que les dimensions constitutives susceptibles
d'expliquer l'évolution de ce fait. Voici donc une proposition de
notation pour exprimer les dimensions :
• dimension (attribut 1, attribut 2, attribut 3, etc.) ;
• liste de valeurs d'un attribut: attribut {valeur possible 1 l valeur possible 2 I valeur possible 3 I
etc.
• hiérarchie d'attributs : détail général.
Par exemple, imaginons une BD transactionnelle d'une université reprenant des données
d'étudiants, de cours, de professeurs, d'examens, etc. Un hypercube orienté vers l'étude de la
réussite des étudiants pourrait être le suivant:
• Faits à étudier:
o moyenne des cotes obtenues;
o proportion d'étudiants avec une cote supérieure à 10/20.
• Dimensions :
BDD 82
o temps (session {janvier Ijuin I année);

o programme de cours (nom, modalité {jour Isoir}, niveau {bachelier Imaster Ispéciali-
sation});
o cours (volume{< 5 crédits I entre 5 et 10 crédits 1 >10 crédits}, langue, discipline);
o étudiant (genre {masculin, féminin}, boursier {oui Inon}, kot {oui Inon}).
4. Schéma de Data Warehouse

La manière dont les données sont organisées dans un DW est déterminée par les exigences des
utilisateurs (sous forme d'hypercube) et par des impératifs de performance.
Les schémas de DW adoptent donc des modes d'organisation qui sont assez différents de ceux
préconisés pour concevoir des BD transactionnelles. Un de ces modes est le schéma en étoile, où:
• une table centrale reprend les faits à analyser et les références vers des tables de dimensions.
On l'appelle table de faits;
• des tables de dimension incluent les attributs qui constituent la dimension ;
• des liaisons logiques entre des attributs des dimensions constituent des hiérarchies.
L’image ci-dessous montre un exemple de schéma en étoile pour un DW dont le sujet est la
performance commerciale :
• cette performance s'exprime à travers deux variables de la table de faits VENTE, qui sont
TOTAL MONTANT VENTE et TOTAL_QUANT, respectivement pour la somme des montants des
ventes et la somme des quantités vendues ;
• la performance varie selon trois dimensions, qui sont représentées par les tables TEMPS,
GEOGRAPHIE et ARTICLE. Ces tables peuvent être jointes à la table de faits VEN_TE qui
contient les dés étrangères correspondantes, à savoir DATE, CODE POSTAL et NUMART. Les
tables de dimension contiennent des attributs et des hiérarchies, comme HIERARCHIE GEO
dans la table GEOGRAPHIE. Une hiérarchie permettra des changements d'échelle dans la
visualisation des faits.
ANNEE
MOIS
JOUR
HIERARCHIE_DATE NUMART
ANNEE TOTAL_MONTANTVENTE CATEGORIE
MOIS TOTAL_QUANT SEGMENT
JOUR .._____, DA TE ARTICLE
..-----1 CODEPOSTAL HIERARCHIE_PRODUIT
NUMART CATEGORIE
CODEPOSTAL SEGMENT
VILLE ARTICLE
REGION
PAYS
HIERARCHIE_GEO
VILLE
REGION
PAYS
5. Visualisation
Les systèmes BI proposent de nombreux types de visualisation, comme des tableaux croisés, des
histogrammes, des graphiques en secteurs, et bien d'autres encore. Ces visualisations sont
souvent interactives et manipulables via des interfaces Web ou des applications mobiles. Elles
peuvent être modifiées en temps réel par l'utilisateur par exemple en appliquant les opérations
définies sur un hypercube, ou en changeant leur apparence (taille, couleurs, etc.).
BDD 83
Voici quelques illustrations réalisées avec Microsoft Power BI. L’image ci-dessous montre un
tableau reprenant le total des ventes par année et par catégorie d'articles. L'outil dispose de
commandes pour agir sur l'échelle des dimensions à partir des hiérarchies d'un DW, comme dans
le tableau d’après où les dimensions TEMPS et ARTICLE sont affinées respectivement comme
suit: mois, et segment.
VTT Total
....ANNEE I city
/
équipement
2016 I 796440 787965 l238092 2822497

~lfè:i;t[~ Eii iDiiiiiii ii iii,i .:: : :,':~ s
2018 l 1184325 1195085 1880628 4260038
Tijlit:.li l}Ciii§~i;'}ftI !ijftfili~!i]lfiii~''1,iJ62,s1$I 1
_CA
_._TE_GO
_ Rf_E--r- ty- : - - - - - , - - ~ - - , - - - - ~
ci... éa.;;i.;u;;;,iiD
~1e;.;.;m.;.;;e;;,,;.nt;,_._____ _ _....,.;.VTT.;..;..._...,..._ _ _-r-_ _--l Total
ANNEE basic excellence Total basic excellence Total basic excellence Total
12 34.645 34.128 68.773 40.100 16.840 56.940 14.151 79.150 93.301 219.014
i'P{i 458.77~ 497.358 956.128 726.100 299.120· 1.025.220 211.952 1.350.050 1.562.002 3.543.350
1 30.225 35.712 65.937 54.700 23.480 78.180 15.438 111.135 126.573 270.690
38.304: 70.28' 58.125 266.477
3 43290 48.3.30 91.620 60.725 22.160 82.885 , 16.816 111.515 128.331 302.836
·4 38.870 42.732 81.602 58.025 24.$~,, Jl~45 1'6~ 5
>J J)0510 117.115 281.862
S 40.755 39.078 79.833 64.800 26.800 . 91.600 1 17.369 100.955 118.324 289.757
38.675 39.114 77.789 67.475 ,3 08.007
7 43.355 42.408 85.763 58.100 26.760 84.860 ! 17.696 119.525 137.221 307.844
8 32~695 45.846 78.541 51.JOO 288.996
9 38350 36.540 74.890 50.975 18.040 69.015
16.071 109.720 125.791 269.696
10 33.735 41 .868 75.603 56.175 2.3.000 ·. .79.t'lS
17.981 106.720 124.701 280.279
11 41 .990 47.2 14 89.204 72.700 32.000 104.700 21 .452 129.885 151.337 345.241
12 44.850 40212 85.062 72..600 29.280 101;$80 19.1 68 126355'.. 145:.523
2018 561.795 622.530 1.184.325 846.725 348.360 1.195.085 268.533 1.612.095 1.880.628 4.260.038
1 ·-· · .. ... ?.~~5.!). •-·· 62.568 . JJ6.~1~ ... 78.1~.5 .. 25.920 1~.045. ~?!~??o:. , J 4S.085 16&042, .. 388.6C!5.
Total 1.396.525 1.540.368 2.936.893 2.127.950 880.320 3.008.270 660.937 4.019.785 4.680.722 10.625.885
La figure ci dessous montre une transformation comparable mais au niveau d’un graphique en
courbes affichant l’évolution du total des ventes par année, puis par mois à la suite d’une
commande de drill down.
CA
4,5
4,0
3,5
3,0
2,5 2018
2016 2017
(a) ANNÉE
CA
0,4M - - - - - - - - - - - - - - - - - - - - - --1r- - - - - -~
{b) ANNÉE MOIS
La Figure ci-dessous montre l'évolution de deux variables selon deux dimensions : un cercle
représente les variables montant total des ventes et quantité totale vendue, respectivement avec
le positionnement du cercle en ordonnées et sa surface. La dimension catégorie de produits est
reprise en abscisses, et la dimension pays est exprimée avec la duplication des cercles pour
chaque valeur de cette dimension (ici Belgique et France).
Les systèmes BI sont souvent utilisés pour représenter des indicateurs, comme ceux de la Figure
ci-dessous. Un indicateur montre, par exemple, la valeur courante d'une variable, différentes
BDD 84
plages de valeurs matérialisant des niveaux de performance et un pourcentage d'atteinte d'un

objectif fixé pour cette variable.
Indicateur
CA et quantités par catégories e,t années de quantité
PAYS • Hel.gique • France
3,SM ·
,....
3,0M---:-----------....:;_...:.;--_;__---:-:.,-
. w · . ..
/ 2,5 M - - - - - - - - - - - . . . , . . . . , . --;-;:-"""'7r
LLI
95,00 %
;; c(
~ 20M-
. , · -
1- Indicateur
lZ de CA
:o
. :E 1,5M---------__;_,.---'--:-:-~ ::---:;:-~-t:;
1,0M---
· -:---+--~
·o~SM-·- . "-:-;>-.. -ci_ty______•--;éq-'-u"'"';"i:::-Rè:-:m=-e=-=n::t:-
</"\V' . . ÇATEGORIE,
• .f<
.
·:.-..~•·.'':-<,.
.
,<:..;ê,:;$-.,~:,;;:, ._,:,:,-., ..,
105,00 %
{a) {b)
Les outils de visualisation sont précieux pour le manager, car ils facilitent la recherche interactive
d'informations pertinentes pour le processus de décision. Ils contribuent aussi à améliorer la
communication de l'information à l'aide de représentations adaptées.
6 Data Mining
Les techniques OLAP discutées plus haut produisent des ànalyses descriptives en proposant
principalement des représentations agrégées de gros volumes de données expliquant la situation
courante ou passée d'une entreprise.
Avec le Data Mining, il est possible d'induire par inférence d'autres formes de connaissance. En
recherchant des régularités significatives dans des données transactionnelles et/ou dans des Big
Data, on peut réaliser entre autres:
• des catégorisations automatiques d’éléments, comme la segmentation d’un groupe de per-
sonnes à partir de données comme d’âge, le niveau de revenu ou le type d’habitat;
• des modélisations de comportements, comme l’analyse de paniers d’achats pour identifier des
comportements fréquents tels que: si un client achète un ordinateur, il y a 58% de chances qu'il
achète également une imprimante;
• des prédictions de valeurs de variables, comme des niveaux futurs d'indicateurs de performance
en fonction de l’activité de l’entreprise.
Exemple. Les arbres de décision constituent une des formes de connaissance mise en évidence
par le Data Mining. Imaginons le cas d’une banque qui analyse les données relatives aux per-
sonnes auxquelles elle a accordé ou refusé des prêts. Il est
possible de déterminer quelles sont les caractéristiques de
ces personnes qui sont les plus déterminantes dans la
décision d’octroi de prêt, et de les représenter comme dans 30 .. 40
l’image ci-dessous Dans cet exemple fictif et

volontairement naïf, le prêt sera refusé aux clients âgés de 1 salarié 1 accepté \ fumeur \
30 ans ou moins et qui ne sont pas salariés, et ainsi de

suite. Cette information peut guider les collaborateurs de la
"zui ou1/ no1 ~on
refusé accepté refusé accepté
banque dans leurs décisions d’octrois. .
BDD 85
Définition. Plus généralement, les techniques de Data Mining fournissent des connaissances en
combinant différentes disciplines, parmi lesquelles l'intelligence artificielle, les statistiques et les
sciences de l'information.
Contrairement à l'OLAP, le processus de découverte du Data Mining est conduit par la machine
sous la supervision de l'utilisateur. Cette autonomie peut même être totale dans certaines
situations, ce qui en inquiète plus d'un, par exemple lorsque des opérations boursières sont
décidées par des algorithmes sans validation humaine.
De plus, le Data Mining aide à expliquer les comportements courants ou passés et à prédire des
comportements futurs en mettant en lumière des liens de causalité, alors que l'OLAP se limite à
les décrire.
6.1.Applications
Le Data Mining trouve de nombreuses applications dans les métiers de gestion,
parmi lesquelles :
• la gestion de la relation client, et notamment le contrôle de l’attrition;
• la vente de détail et la logistique, et plus particulièrement l'optimisation du stockage et du
rayonnage, ainsi que la prédiction de demandes saisonnières;
• le secteur bancaire, par exemple l'automatisation d'octrois de crédits ou la détection de fraudes;
• la gestion de la production, avec la prédiction de pannes ou la détection de défauts de
fabrication.
Le Data Mining concerne d'abord les systèmes d'aide à la décision, où les analyses OLAP sont
complétées par les résultats produits par le Data Mining. Mais l'informatique transactionnelle
profite également du Data Mining à travers l'automatisation poussée de certains processus
d'affaires.
Ainsi, des acteurs humains peuvent être remplacés par des« intelligences artificielles» qui
intègrent des techniques de Data Mining. Par exemple, les systèmes de recommandation
automatique d'articles d'un magasin en ligne se basent sur l'analyse de comportements d'achats
passés et sur un pro- filage du client pour lui suggérer des articles susceptibles de l'intéresser.
Certaines formes d'intelligence artificielle, comme les techniques de Machine Learning,
développent même des facultés d'apprentissage à partir des données. Le comportement du
système n'est alors plus déterminé uniquement par son programmeur. Une application typique
est l'interprétation automatique d'images, par exemple pour repérer des tumeurs dans des
radiographies de patients.
BDD 86

Base de Données PDF VF

Transféré par

Droits d'auteur :

Formats disponibles

Base de Données PDF VF

Transféré par

Informations du document

Description originale:

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

Base de Données PDF VF

Transféré par

Droits d'auteur :

Formats disponibles

Julie Paternotte 2020

Base de données pour la gestion

Chapitre 1: La gestion de projet informatique

1. Notion de projet informatique

1.1. Résultats sous contraintes

D’autres types de contraintes peuvent s’imposer en

1.2. Projet informatique

Image: Les quatre P d’un projet informatique

La nature d’un projet informatique s’explique assez bien à travers les 4 P

2. Processus de développement de logiciel

2.1. Processus et phases

Définition: L’ingénierie logicielle est « l’application » d’une approche systématique, disciplinée et

Image: Phases et activités d’un

Certaines phases sont communes à tout projet d’ingénierie.

Image: Les phases génériques de l’ingénierie

• le déploiement, durant lequel le système est transmis aux utilisateurs.

2.3. Bonne Pratiques

3. Exemples de processus de développement de logiciel

3.1. Processus en cascade

Image: Les phases du processus en

3.2. Unified Process

• Inception, qui définit la portée du projet. On va identifier les principales utilisations du

• Elaboration, qui planifie le projet et décrit le futur système. On va spécifier le système à

• Construction, qui réalise le système. On va produire et tester itérativement des versions

3.3 Processus Agile

3.4. L’exemple Scrum

4. Acteurs d’un projet

Un projet est pris en charge par une équipe qui

4.1. Mission du chef de projet

Le chef de projet est confronté à plusieurs défis, dont ceux-ci:

• la gestion du changement fait partie intégrante des développements informatiques et requiert

• même si le livrable du projet est technologique, la dimension humaine est primordiale et

Chapitre 2: La gestion de projet informatique

1. Modélisation de système informatiques

• Ie langage naturel libre, comme Ie français ;

Exemple de langage Exemple de formulation

Langage graphique (cas d'utilisation Accéder au catalogue d'articles

Un « bon » langage de spécification doit :

1.2.Faiblesses du langage naturel

1.3.Construction de modèles graphiques (Visuel Modeling)

En informatique, un modèle est une représentation schématique, et donc simplifiée, du système.

• Les modèles de spécification d’interface: ils schématisent l’apparence et l’organisation de

1.5.Unified Modeling Language (UML)

2. Diagramme de cas d’utilisation

Définition: un diagramme de cas d’utilisation recense et décrit les scenarii d’utilisation du

2.1. Cas d’utilisation

Rechercher Passer une commande Déposer

Acteur Client banque

2.2.1. Hiérarchie d’acteurs

Poste un message sur un forum

Client ----- Vendre au comptoir

2.3. Structuration des cas d’utilisation

2.4. Spécification des cas d’utilisation

Une première version du scénario va décrire un comportement «standard» du cas d'utilisation,

• séquence conditionnelle complémentaire à l'action 2,:

2.5. Démarche de construction

2.5.1. Identifier les acteurs principaux.

image: hiérarchie d’acteurs chez PetShopTop

• Inception, qui définit la portée du projet. On va identifier les principales utilisations du  

• Elaboration, qui planifie le projet et décrit le futur système. On va spécifier le système à  

• Construction, qui réalise le système. On va produire et tester itérativement des versions  

Le chef de projet est confronté à plusieurs défis, dont ceux-ci:  

Un « bon » langage de spécification doit : 