Base de Données

Floriane Riga
INTRODUCTION À LA MODÉLISATION ET
AUX BASES DE DONNÉES
STRUCTURE
EXAMEN
Floriane Riga
COMMENT DEVENIR ACTEUR DU DEVELOPPEMENT DIGITAL ?
à O1 Savoir interagir avec les informaticiens

- le gestionnaire a besoin de systèmes informatiques adaptés à ses attentes
- le gestionnaire délègue la construction de ces systèmes aux spécialistes informaticiens
à Le gestionnaire doit connaître la démarche de développement Chap 1 :

- pour être proactif prendre dans le développement de systèmes La gestion de projet
informatique
à Le gestionnaire doit formuler précisément ses exigences
- pour les transmettre aux informaticiens qui ne connaissent pas Chap 2 : Représentation
nécessairement le métier ni les processus d'affaires des exigences
à O2 : Maitriser les technologies des bases de données

- le gestionnaire a besoin de gérer les données et l'information avec un maximum d'autonomie
à Le gestionnaire doit pouvoir stocker et exploiter les données structurées de Chap 3 :

l'entreprise Bases de données
à Le gestionnaire doit pouvoir produire de la connaissance à partir de masses
de données Chap 4 :
Aide à la décision
2
Floriane Riga
TABLE DES MATIERES
Structure ......................................................................................................................................... 1
Examen ........................................................................................................................................... 1
Comment devenir acteur du développement digital ? ..................................................................... 2
1. Chapitre 1 : La gestion de projet informatique......................................................................... 5
1.1. Notion de projet informatique ........................................................................................ 5
1.2. Processus de développement de logiciel ......................................................................... 6
1.3. Exemples de processus de développement de logiciel ..................................................... 7
1.3.1. Processus en cascade ...................................................................................................................... 7
1.3.2. Unified Process (UP)........................................................................................................................ 8
1.3.3. Agile ................................................................................................................................................ 8
1.4. Acteurs d’un projet : Quels sont les grands acteurs qui interviennent dans un projet
informatique? ........................................................................................................................... 10
1.5. Conclusion .................................................................................................................... 10
1.6. Questions d’examen ..................................................................................................... 11
2. Chapitre 2 : Représentation des exigences ............................................................................ 12
2.1. Modélisations de systèmes informatiques .................................................................... 12
2.1.1. Exigence ........................................................................................................................................ 12
2.1.2. Formes des exigences ................................................................................................................... 12
2.1.3. Un bon langage ? .......................................................................................................................... 13
2.1.4. Dimensions de la modélisation ..................................................................................................... 13
2.2. Diagramme de cas d’utilisation ..................................................................................... 14
2.2.1. Cas d’utilisation et acteur ............................................................................................................. 15
2.2.2. Hierarchie d’acteurs ...................................................................................................................... 15
2.2.3. Structuration des cas d’utilisation ................................................................................................ 16
2.2.4. Spécification des cas d’utilisation ................................................................................................. 17
2.2.5. Démarche de construction............................................................................................................ 18
2.2.6. Erreurs fréquentes ........................................................................................................................ 19
2.2.7. Exemple......................................................................................................................................... 20
2.2.8. Questions examen ........................................................................................................................ 23
2.3. Diagramme d’activité .................................................................................................... 24
2.3.1. Action et flux de contrôle.............................................................................................................. 24
2.3.2. Nœud ............................................................................................................................................ 25
2.3.3. Partition ........................................................................................................................................ 27
2.3.4. Flux d’objet, interruption et zone d’expansion ............................................................................. 29
2.3.6. Exemple......................................................................................................................................... 31
2.3.7. Questions d’examen ..................................................................................................................... 34
2.4. Diagramme entité/association ...................................................................................... 36
2.4.1. Entité ............................................................................................................................................. 36
2.4.2. Association .................................................................................................................................... 37
2.4.3. Attribut.......................................................................................................................................... 38
2.4.4. Généralisation/spécialisation........................................................................................................ 40
2.5. Notations ...................................................................................................................... 45
2.6. Conclusion .................................................................................................................... 45
3
Floriane Riga
3. Chapitre 3 : Bases de données ............................................................................................... 46

3.1. Définitions et applications ............................................................................................ 46
3.2. Architectures ................................................................................................................ 48
3.2.1. Architecture Logique ..................................................................................................................... 48
3.2.2. Architecture client serveur ........................................................................................................... 49
3.2.3. Architecture à 3 tiers .................................................................................................................... 50
3.3. Sécurité des bases de données ...................................................................................... 51
3.3.1. Gestion des transactions ............................................................................................................... 52
3.3.2. Contrôle d’accès............................................................................................................................ 52
3.4. Modèle relationnel ....................................................................................................... 53
3.4.1. Table.............................................................................................................................................. 53
3.4.2. Contrainte d’intégrité ................................................................................................................... 56
3.5. Principes de génération d’un schéma et d’une BD relationnels...................................... 57
3.6. Langage SQL .................................................................................................................. 57
3.6.1. Sélection sur une seule table ........................................................................................................ 59
3.7. Big Data ........................................................................................................................ 76
3.8. Exercices ....................................................................................................................... 76
3.8.1. Création de bases de données avec Microsoft Access.................................................................. 77
3.8.2. Requêtes SQL sur des données de gestion du personnel ............................................................. 77
3.8.3. Requêtes SQL sur des données de gestion commerciale .............................................................. 77
3.8.4. Requêtes SQL sur des données d’annonces.................................................................................. 77
4. Chapitre 4 : Aide à la décision................................................................................................ 78
4.1. De la décision à la Business Intelligence ........................................................................ 78
4.2. Data Warehouse ........................................................................................................... 78
4.3. Analyse descriptive avec les techniques OLAP ............................................................... 78
4.4. Schéma de Data Warehouse ......................................................................................... 78
4.5. Visualisation ................................................................................................................. 78
4.6. Data Mining .................................................................................................................. 79
4.7. Exercices ....................................................................................................................... 79
5. Microsoft Access ................................................................................................................... 79
5.1. création d’une base de données.................................................................................... 79
5.2. Création de requêtes..................................................................................................... 83
5.3. Création de formulaire .................................................................................................. 88
5.4. Création d’état .............................................................................................................. 95
5.5. Questions d’examen ..................................................................................................... 99
4
Floriane Riga
1. CHAPITRE 1 : LA GESTION DE PROJET INFORMATIQUE
- Définition 1 : Système d’information d’une organisation1 : est l’ensemble des ressources mises
en œuvre pour créer, collecter, stocker, traiter, diffuser
et sécuriser (gérer au sens large) l’information.
- Définition 2 : Système informatique : est un sous-
ensemble du système d’information dédié au
traitement de l’information digitale.
- Définition 3 : Domaine d’application : d’un système
informatique désigne la partie de monde qui interagit
avec ce système. Ex : une entreprise, un club de sport,
un métier, un département, etc.
o Développer un système est difficile.
- Processus de développement d’un logiciel :
Ingénierie logicielle Propose Processus de développement Guide Projet de développement
2
1.1. NOTION DE PROJET INFORMATIQUE
- Définition 4 : Un projet : est un effort délimité dans le temps pour fournir un livrable unique
dans un délais et un budget fixé.
- Le triangle des contraintes du projet3 : Il est souvent
difficile de respecter intégralement toutes les
contraintes d’un projet et on est donc obligé de mettre
la priorité sur l’une ou l’autre de ces contraintes.
- On parlera souvent de projets dont le livrable est le
programme informatique. Le domaine d’application
sera les entreprises/les métiers de gestion.
à Les 4P d’un projet informatique4 :
o Le livrable/le Produit : majoritairement du logiciel. Il y a aussi du matériel, de
l’infrastructure matérielle qui se cache derrière ou bien de la documentation et des
phases de test ;
o Personne (pour qui le produit est réalisé) : Pour qui le produit est réalisé. Les
spécialistes du domaine d’application/métier qui connaissent bien le fonctionnement
de l’entreprise/les utilisateurs finaux sont amenés à interagir avec les spécialistes
informaticiens/de la technologie de l’information et de la communication. Les
spécialistes TIC doivent construire le système alors que les spécialistes métier ont la
responsabilité d’exposer leurs attentes aux informaticiens ;
o Projet : Le développement d’un produit/logiciel/matériel. Gérer un budget, planifier les
tâches.
1
Figure : slide introductive
2
Figure 1-1 : Processus de développement de logiciel : pg 2
3
Figure 1-2 : Triangle des contraintes et exemples de projets : pg 3
4
Figure 1-3 : Les 4P d’un projet informatique : pg 4
5
Floriane Riga
o Processus : pour mener à bien un projet. Organiser le

projet dans le temps (phasage), déterminer qui fait
quoi, qui fournit des recommandations concrètes pour
mener à bien un projet de développement.
1.2. PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL
- Définition 5 : 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 (IEEE à Institute of Electrical and Electronics Engineers).
o Le processus de développement se compose d’un phasage (une organisation générique
dans le temps) et un ensemble d’activité, de choses à faire qui prennent place au sein
des différentes phases du projet. Nous allons détailler les différentes phases et les
« best practices » des processus de développement de la littérature.
- Les phases génériques6 :

o Comprendre : Le domaine d’application, les attentes des utilisateurs
o Planifier : Les informaticiens, en collaborant avec les utilisateurs,
vont imaginer une solution possible pour répondre aux attentes Comprendre
d’automatisation des utilisateurs. On va identifier les taches à
réaliser au sein du projet et les planifier dans le temps.
o Exécuter : Produire le délivrable, écrire les
programmes informatiques, construire les bases de Évaluer Planifier
données.
o Évaluer : Vérifier qu’il est bien conforme aux exigences
initiales. Si jamais on constate des défauts majeurs, on peut
Exécuter
recommencer un nouveau cycle. C’est très souvent le cas dans
l’informatique où on apprend des erreurs passées pour améliorer
sans cesse le système existant. C’est cette boucle qu’on retrouve entre « Évaluer et
Comprendre ».
5
Figure 1-4 : Phases et activités d’un processus de développement : pg 5
6
Figure 1-5 : Les phases génériques de l’ingénierie : pg 6
6
Floriane Riga
- Les activités techniques

o Contribuent au livrable : Elles contribuent à créer le délivrable du projet
o Exigences : Gestion des exigences des utilisateurs
o Conception : d’une solution qui répond à ces exigences
o Construction : du système
o Déploiement : transmettre le système terminé dans les mains de l’utilisateur
o Etc.
- Les activités managériales (gestion de projet) :
o Soutiennent les activités techniques
o Planification (gestion de l’agenda)
o Gestion des équipes
o Budget
o Etc.
- Exemples de bonnes pratiques :
o Donner de la valeur : chaque programme qu’on construit, chaque écran qu’on
développe doit apporter de la valeur auprès de l’utilisateur, ça doit être démontré.
o Garder le système simple : Éviter les usines à gaz. Trop souvent, les utilisateurs veulent
tout automatiser tout de suite en s’imaginant que l’informatique va faire des miracles
en développant des systèmes très élaborés, très coûteux pour traiter quelques cas
particuliers qui pourraient faire l’objet d’un traitement manuel.
o Intégrer la flexibilité : Un système informatique évolue car l’entreprise évolue, les
besoins de ses consommateurs aussi, donc il faut concevoir dès le départ pour qu’ils
intègrent le plus de flexibilité possible.
1.3. EXEMPLES DE PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL
1.3.1. PROCESSUS EN CASCADE

Chaque phase porte sur une activité. La sortie d’une phase constitue l’entrée de la phase
suivante. Cerner les exigences et construire une solution. Construite à Tester à Déployer le
système.
Inconvénients :
o Exprimer l’ensembles des exigences au début du développement ce qui est très difficile
à faire car les utilisateurs ont beaucoup de mal à être complet et précis sur les exigences
d’un logiciel qui est immatériel.
o La complexité : Rien n’est fait pour découper la construction du système en modules
pour repasser sur une partie du système qui serait particulièrement délicate à
construire.
o Gestion du changement : rien n’est prévu pour intégrer le changement. Les exigences
pourraient évoluer pendant le processus mais rien n’est prévu pour modifier ces
exigences.
o Lourdeur des tests : Concentré en fin de construction du
système ce qui amène les utilisateurs à recevoir
l’ensemble du système dans un mode bing bang et puis
réaliser l’ensemble des tests ce qui peut paraître
comme étant une tâche extrêmement lourde.
7
Floriane Riga
1.3.2. UNIFIED PROCESS (UP)

On découpe le projet de développement en 4 grandes phases/saisons du logiciel. Il est itératif8
car des ensembles de tâches ne peuvent être répétés et incrémental 9 car le système est
construit et livré partie par partie.
1.3.2.1. Inception : cerner la portée du système
1.3.2.2. Élaboration : la création/planification d’une solution
1.3.2.3. Construction : réalise le système
1.3.2.4. Transition : la transition vers les utilisateurs
Les phases sont organisées en Itérations (découpé en sous-systèmes).

Chacune des activités se localise de manière continue et plus ou moins concentrée sur les
différentes phases comme le montre le graphique.
10
1.3.3. AGILE
- à Agile Manifesto : Repose sur des principes génériques repris dans un manifeste. Dans ce
manifeste, les concepteurs de la méthode agile mettent l’accent sur la collaboration,
l’interaction, la responsabilisation des personnes. L’humain est au cœur de la démarche. Agile
demande aussi du pragmatisme et de la flexibilité qui intègre par essence le changement.
- On y retrouve :
o Des interactions entre les personnes plutôt que des processus et outils
o Des collaborations plutôt que contrats
o Du logiciel plutôt que de la documentation
o De l’adaptation plutôt qu’un plan figé
- Exemple : Scrum :
o Les flèches représentent l’évolution dans le temps
o Dans scrum, le développement est organisé en itération. Une « itération » = un « sprint
».
o Lors d’un sprint, on traite une partie des exigences de l’utilisateur, ce qu’on appelle un
« sprint backlog ».
o Le sprint backlog va puiser dans un réservoir d’exigences complet qu’on appelle le
« product backlog ».
7
Figure 1-6 : Les phases du processus en cascade : pg 8
8
Répétitif
9
Décrire un ajout par palier, petit à petit, afin d'être certain que chaque valeur ajoutée apporte une amélioration
sans créer de dysfonctionnement.
10
Figure 1-7 : Les phases du UP : pg 9
8
Floriane Riga
o Chaque sprint est sensé produire une partie du livrable. Un « livrable incrémental est
un sous-système du « système informatique ».
o Scrum prévoit toute une série d’interactions entre les acteurs du projet (aspect humain,
collaborations importants pour Agile). Exemple : les mêlées quotidiennes de chaque
sprint durant lesquels l’équipe de projet se tient debout pendant 15 minutes et fait part
du travail réalisé la veille, du travail à réaliser le jour-même et des problèmes rencontrés.
o Des rétrospectives du sprint sont aussi organisées. Ce sont des retours d’expérience
dont l’objectif est d’améliorer la manière dont les prochains sprint vont se dérouler.
o Réunion de planification du sprint : identifier les exigences qui vont être traitées et les
actions à réaliser pour traiter ces exigences
o La revue du sprint : évalue le résultat, le livrable incrémental d’un sprint.
11
o Rôles :
• Product owner/le représentant utilisateur : dont la responsabilité est de
gérer/déterminer les exigences à Gérer le product backlog.
• Development Team : contribuent à créer le logiciel.
• Scrum master/chef d’orchestre/facilitateur : soutient tous les acteurs dans
l’application de scrum et qui n’a pas réellement un rôle d’autorité ou de chef
de projet mais plutôt une responsabilité de soutient, de motivation,
d’encouragement.
11
Figure 1-8 : L’organisation du processus Scrum : pg 10
9
Floriane Riga
1.4. ACTEURS D’UN PROJET : QUELS SONT LES GRANDS ACTEURS QUI INTERVIENNENT
DANS UN PROJET INFORMATIQUE?
Peu importe le projet informatique, il met en relation toute une série d’acteurs, de cultures et
de métiers différents.
Utilisateurs Informaticiens
(spécialistes (spécialistes des Sponsor
métier) TIC)
Utilisateur Chef de
Décideur
final projet
Business
analyst
Développeur
Expert
12
o Utilisateur = Key user : représente la communauté de l’ensemble des utilisateurs. C’est

par exemple le product owner dans le contexte scrum.
o On fait également collaborer des informaticiens/spécialistes des technologies digitales
mené par un chef de projet. Il assume principalement les activités managériales du
projet et gère les aspects humains, financiers et logistiques. Il doit tout mettre en
œuvre pour permettre aux membres du projet d’accomplir leurs tâches dans les
meilleures conditions.
o Le Business analyst : jouer l’interface entre les spécialistes métier et les spécialistes TIC.
o Les développeurs : produisent le logiciel.
o Les experts ponctuels : par exemple en sécurité.
o Le sponsor : décide du bien-fondé du projet et fournissent les fonds et les ressources
pour mener à bien le projet.
1.5. CONCLUSION
- Enjeu pour le gestionnaire :

o Bonne collaboration (transfert de connaissance métier)
o Compréhension des processus de développement (pour bien interagir avec les
informaticiens)
- Défis :
o Gestion de la complexité lié à l’importance de la demande des utilisateurs
o La gestion continue du changement
o L’importance de la dimension humaine dans un projet de développement
12
Figure 1-9 : Principaux acteurs d’un projet informatique : pg 11
10
Floriane Riga
1.6. QUESTIONS D’EXAMEN
Technologie
11
Floriane Riga
2. CHAPITRE 2 : REPRÉSENTATION DES EXIGENCES
2.1. MODÉLISATIONS DE SYSTÈMES INFORMATIQUES
2.1.1. EXIGENCE
- Le problème : intégrer les spécificités métier
o Pas de prêt à porter : un même logiciel ne peut pas convenir à toutes les entreprises.
o C’est important pour que les entreprises sachent développer un avantage concurrentiel.
o Il faut que les attentes soient explicitées sous forme d’exigences et ces exigences
doivent être transmises aux informaticiens.
- Définition 6 : Exigence : Énoncé d’une capacité que doit posséder le système à construire pour
répondre à un objectif donné. Une exigence peut également être une contrainte que le système
doit respecter.
o Toutes ces exigences sont canalisées par une discipline appelée l’ »ingénierie des
exigences » qui compète l’ingénierie logicielle en couvrant les phases en amont du cycle
du développement de logiciel.
- Responsabilités du gestionnaire :
o Doit être capable de formuler ses exigences car c’est lui qui est le mieux placé pour
comprendre le business
o Transmettre les exigences aux informaticiens
2.1.2. FORMES DES EXIGENCES

- Le langage naturel libre comme le français
o Ex. : les articles du catalogue sont accessibles aux clients
o Ils sont accessibles mais
§ le langage est soumis à interprétation car il est très riche, donc ambigüe ;
§ les utilisateurs s’imaginent parfois que les interlocuteurs connaissent déjà une
partie du business et donc il y a des choses qu’ils n’explicitent pas : silence ;
§ À l’inverse, il y a des utilisateurs qui peuvent formuler des informations qui
n’ont rien à voir avec le traitement de l’information : bruit ;
§ Contradiction : surgissent surtout lorsque les spécifications sont rédigées par
plusieurs utilisateurs ;
§ Redondance : problème général dans la rédaction de contenus. Si on ne
détecte pas ce fac-similé, on risque de dupliquer inutilement certains de ce
développements.
- Le langage naturel structuré : Pour palier certaines difficultés, les méthodes (Agile
essentiellement) ont proposé de formuler les exigences de manière structurée avec des « user
stories ». Dans une user story, on spécifie :
o qui on est : en tant que client ;
o ce que l’on souhaite : je veux pouvoir accéder au catalogue des articles ;
o l’objectif poursuivi par l’exigence : pour choisir celui qui répond à mes attentes.
C’est un progrès par rapport au langage naturel libre (où la forme des phrases n’est pas imposée)
mais on retrouve quand même quelques biais du langage naturel.
- Le langage graphique : Il existe un standard de langage graphique qui s’appelle « Unified
Modeling Language » (UML) : reprend toute une série de langages graphiques dans lequel on
peut enfermer l’utilisateur pour plus de rigueur.
12
Floriane Riga
Exemple de langage Exemple de formulation
Langage naturel libre Les articles du catalogues sont accessibles aux clients.
Langage naturel structuré En tant que client, je veux pouvoir accéder au catalogue des
articles pour choisir celui qui répond le mieux à mes attentes.
Langage graphique
Accéder au catalogue d’articles
Client
13
2.1.3. UN BON LANGAGE ?

- Quel est le meilleur langage à utiliser pour expliciter les exigences ? ça dépend essentiellement
du problème, du profil des utilisateurs. Pour ce faire, nous pouvons détailler ces trois langages
sous 3 critères :
o Expressivité : dans quelle mesure le langage peut exprimer une large variété de
situations ? ;
o Accessibilité : dans quelle mesure l’effort à fournir pour comprendre et formuler des
exigences dans tel ou tel langage est-il élevé ou non ? ;
o Formalisme : le degré de formalisme, de précision, d’automatisation possible de
l’interprétation de ce langage.
Exemple de langage Expressivité Accessibilité Formalisme

Langage naturel libre *** *** -
Langage naturel structuré ** *** *
Langage graphique ** ** **
14
- Selon ces critères, on remarque que le langage graphique est relativement expressif,
relativement accessible et qu’il obtient un degré de formalisme ce qui permet d’être
partiellement interprété par des machines et exempt d’ambigüité.
2.1.4. DIMENSIONS DE LA MODELISATION

- Quel que soit le langage utilisé pour spécifier les exigences, on s’inscrit dans une démarche de
modélisation : on construit une vision à priori du futur système avant qu’il n’existe.
- Dans cette modélisation, on doit traiter plusieurs dimensions qui sont interconnectées :
o Spécifier les structures de données que le futur système va devoir prendre en charge.
Quels sont les types de données à considérer ? Ex : des données sur les clients, sur un
article, un numéro d’article, un libellé, etc.
o Dimension fonctionnelle : Quelles sont les traitement/fonctions à réaliser sur ces
structures de données ? Ex : Quelles vont être les actions qui vont se succéder pour
créer une nouvelle commande ?
o Ces différents traitements s’enchaînent dans le temps selon une logique qui est décrite
selon l’aspect dynamique du système. La dynamique du système explicite l’évolution
de son comportement au cours du temps, donc l’enchaînement des différentes actions
et les évènements qui déclenchent ces séquences d’action.
13
Tableau 1 : exemples de représentations des exigences : pg 16
14
Tableau 2 : caractéristiques de différents langages de spécification : pg 17
13
Floriane Riga
o L’interface du système : Comment ce système va-t-il interagir avec des acteurs humains
et/ou d’autres systèmes ?
15
2.2. DIAGRAMME DE CAS D’UTILISATION
Quelles sont les utilisations d’un système ?
- Définition 7 : Diagramme de cas d’utilisation : recense et décrit les scénarii 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/ pour réaliser toute une série de choses qui
leur apporte de la valeur.
- Du point de vue des utilisateurs, le système est vu comme une boîte noire. Il ne s’agit pas de
discuter de techniques ou d’implémentation mais de fonctionnalités. Le diagramme capte
l’ensemble des exigences du futur système.
- Responsabilités du gestionnaire : fixer/délimiter les fonctions à automatiser en fonction de la
valeur qu’elles peuvent apporter. Ça implique aussi de trouver un consensus portant sur
certaines fonctions qui ne seront pas automatisées, qui seront en dehors du système. à Apport
de valeur ajoutée !
15
Figure 2-1 : dimensions du logiciel : pg 19
14
Floriane Riga
16
2.2.1. CAS D’UTILISATION ET ACTEUR

- Les deux briques de base lors d’un diagramme de cas d’utilisation sont les cas d’utilisation et
les acteurs.
- Définition 8 : Un cas d’utilisation : représente une fonctionnalité qui apporte de la valeur à
l’utilisateur.
Rechercher Passer une Déposer une

un article commande plainte
17
- Définition 9 : Un acteur : est une entité extérieure au système et interagit avec le système (en
invoquant l’exécution d’un cas d’utilisation).
2.2.2. HIERARCHIE D’ACTEURS
Désignation
Cas d’utilisation
18
Acteur
o Bonhomme = Acteur
o Ovale = cas d’utilisation
16
Figure 2.2 : exemples de diagramme de cas d’utilisation ; d’entité/association ; d’activité : pg 20
17
Figure 2-3 : exemples de cas d’utilisation : pg 21
18
Figure 2-4 : notation des diagrammes de cas d’utilisation : pg 22
15
Floriane Riga
o Barre = connexion qui relie un acteur à un cas d’utilisation

o Rectangle = on délimite le système de son environnement (dans le cas d’utilisation).
Dans le rectangle qui représente le système, on va représenter tous les cas
d’utilisation
19
o Les acteurs peuvent être imbriqués dans des hiérarchies d’acteurs : nous avons un
internaute qui, par exemple, qui peut utiliser un système de forum pour poster un
message sur ce forum.
20
o Cas particulier de l’internaute : le modérateur. C’est un acteur qui spécialise

l’internaute et qui hérite de tout ce que l’internaute peut faire.
o La flèche va de l’acteur le plus particulier vers l’acteur le plus général (notion de
catégorie). Le modérateur peut utiliser le système pour modérer le forum mais il
hérite également de toutes les utilisations de l’internaute. Donc il peut utiliser le
système pour poster un message sur le forum.
21
2.2.3. STRUCTURATION DES CAS D’UTILISATION

- Très souvent, on constate des comportements communs dans différents cas d’utilisation.
- Pour éviter des comportements communs, on peut créer des cas appelés par d’autres cas
(appelant) qui factorisent ce comportement commun.
o La première manière de connecter un cas appelant à un cas appelé est la relation
include.
19
Vidéo 2B, 05:23
20
Figure 2-5 : généralisation d’acteurs : pg 22
21
Figure 2-6 : Participation multiple et généralisation: pg 23
16
Floriane Riga
§ La cas appelant va s’interrompre à un certain moment de son exécution pour

dévier l’exécution vers le cas appelé.
o Une alternative à cette première manière est l’appel sous condition. Dans la relation
extend, le cas est appelé uniquement si une condition est vérifiée lors du déroulement
du cas appelant. On connecte donc le cas appelé et appelant par une relation externe
qui va, cette fois-ci, du cas appelé vers le cas appelant (contraire de include). On prend
également l’habitude d’indiquer la
condition pour que l’appel puisse se faire.
22
2.2.4. SPÉCIFICATION DES CAS D’UTILISATION

- Il ne suffit pas d’identifier les cas d’utilisation pour déduire toutes les facilités à implémenter au
niveau d’un logiciel. On va donc identifier les cas mais aussi décrire en détail chaque cas
d’utilisation en spécifiant quelques rubriques comme les acteurs, les objectifs, la description du
cas.
23
- Ensuite, on peut préciser un scénario d’utilisation/scénarii où on va stimuler un jeu de stimuli et

de réponses en provenance respectivement de l’acteur et du système.
- Ex ci-dessous : le cas est initié lorsque le client arrive à la caisse avec son article. Celui-ci est
scanné. Le système va répondre en déterminant le prix de l’article et en rajoutant de
l’information relative à la transaction de vente en cours. Et ainsi de suite.
22
Figure 2-7 : notation des relations entre cas d’utilisation : pg 23
Figure 2-8 : exemples de relations entre des cas d’utilisation : pg 24
23
Vidéo 2B, 09:07 (précisé en langage naturel)
17
Floriane Riga
24
2.2.5. DÉMARCHE DE CONSTRUCTION

1. Identifier les acteurs principaux : ceux qui recueillent le plus de valeurs, qui sont les
cibles principales du système.
2. Identifier les cas d’utilisation principaux : pour ces acteurs.
3. Identifier les acteurs et cas secondaires : les acteurs qui ne sont pas les premiers
bénéficiaires , les premières cibles du système (ex : un administrateur d’une
plateforme).
4. Détailler les scénarii standards et les alternatives : détails précisant les scénarios de
déroulement de chacun des cas.
5. Structurer les cas d’utilisation : Dans le cas où des comportements communs sont
identifiés, structurer les cas d’utilisation en factorisant les comportements communs
avec des appels include ou extend.
à Cf. exemple PetShop Top

o Vente comptoir : le client particulier et l’employé participent ensemble
o Si paiement par carte : appel avec le extend vers un cas d’utilisation « paiement par
carte ».
Le client professionnel : est une catégorie du client particulier, il peut faire tout ce que
le client particulier est capable de faire avec le système
mais en plus de cela, il peut réaliser une commande web
avec un appel systématique vers le paiement par carte.
o Le magasinier : est un acteur plus général que le
caissier, il a accès au système pour préparer une
commande, facturer et réassortir le stock.
25
24
Vidéo 2B, 09:07 (précisé en langage naturel)
25
Figure 2-9 : hiérarchie d’acteurs chez PetShop Top : pg 27
18
Floriane Riga
o Le délégué commercial : est un acteur secondaire qui utilise accessoirement le système

pour arranger les rayons.
Cas d utilisation principaux

’
secondaire
Acteurs et
cas
s
26
2.2.6. ERREURS FRÉQUENTES

- Éviter un niveau de détail trop poussé dans le décomposition factionnelle lors de la création d’un
cas d’utilisation. Créer un virement est pertinent, ensuite le décrire à travers un scénario (pour le
cas d’utilisation « créer un virement »).
- Éviter la modélisation de workflows : Ne pas représenter la dynamique du système en enchaînant
les cas d’utilisation avec des relations include. L’include est là pour faire des appels de
comportement factorisés, pas pour représenter des séquences d’utilisation dans le temps. à Éviter
des enchaînements de cas comme celui ci-dessous.
（ contre-
exemple）
27
26
Figure 2-12 : diagramme de cas d’utilisation pour PetShop Top : pg 28
27
Tableau 3 : exemples d’erreurs à éviter au niveau des diagrammes de cas d’utilisation : pg 29
19
Floriane Riga
2.2.7. EXEMPLE
- Exigence 128 : Un internaute peut consulter le catalogue des objets disponibles et éventuellement
lancer une recherche sur ce catalogue.
- Exigence 229 : Quand un internaute souhaite louer un objet, il doit s’enregistrer sur la plateforme
avant sa première location.
o On a enregistré auprès de l’internaute un nouveau cas d’utilisation qui s’appelle
« s’enregistrer ».
- Exigence 330 : Une fois enregistré, l’internaute peut, après s’être identifié, réserver un objet et le
louer. Il peut aussi commenter un objet qu’il a recherché. Il devra procéder à un paiement lors de
la réservation (acompte) et de la location (solde).
o L’internaute n’est plus n’importe quel internaute étant donné qu’il est déjà inscrit
et qu’il doit maintenant s’identifier. Il devient un locataire (acteur qui peut réaliser
tout ce que l’internaute peut faire). NB : on va de l’internaute spécialisé (locataire ;
il détient au minimum, les mêmes possibilités que l’internaute généralisé) vers
l’internaute généralisé. L’internaute ne peut pas louer des objets tant qu’il n’est pas
inscrit, alors que le locataire qui est inscrit, le peut.
o Include : Il faut Y pour X : X -----> Y (la phrase ne suit pas le sens de la flèche qui va
de gauche à droite)
Ou : Si tu veux X, alors du doit Y (suit le sens de la flèche qui va de gauche à droite)
o Extend : Si tu veux Y, alors X : X <------ Y (suit le sens de la flèche qui va de droite à
gauche)
28
Pg 30
29
Pg 30
30
Pg 31
20
Floriane Riga
- Exigence 431 : 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 commenter un objet après l’avoir posté sur la plate-forme.
o Comme le locataire, le propriétaire doit être identifié pour accéder à toutes ces
facilités. On va créer un nouveau rôle intermédiaire, l’utilisateur identifié avec deux
spécialisations : le locataire et le propriétaire. Le propriétaire peut spécifiquement
poster un objet, ce que le locataire ne peut pas faire. Par contre, comme le locataire,
il peut commenter un objet. Rappel, toutes les utilisations définies au niveau d’une
généralisation sont implicitement héritées par les spécialisations. Le commentaire
posté par le propriétaire peut se faire directement ou éventuellement lors du
déroulement du cas : « poster un objet »à représentés par la relation extend (s’il
y a des commentaires à formuler).
31
Pg 30
21
Floriane Riga
- Exigence 5 32 : Tout comme le locataire, le propriétaire doit s’enregistrer sur la plateforme, et

s’identifier quand il accède à toutes ses fonctions.
- Exigence 633 : L’administrateur de la plateforme gère les catégories servant à classifier les
objets et modère les commentaires sur les objets.
o On va créer un nouvel acteur avec deux cas d’utilisation : gestion des catégories et
modération des commentaires. NB : implicitement, l’administrateur devra aussi
s’identifier au niveau du système pour accéder aux facilités.
32
Pg 32
33
Pg 32
22
Floriane Riga
2.2.8. QUESTIONS EXAMEN
23
Floriane Riga
2.3. DIAGRAMME D’ACTIVITÉ
- Définition 10 : Un diagramme d’activité : Décompose une fonction attendue d’un système

informatique en actions (détailler la mécanique d’une fonction). Il montre comment ces
actions s’enchaînent (enchaînement d’actions) dans le temps et comment elles se
transmettent de l’information (l’une vers l’autre).
o Les diagrammes d’activité ne s’intéressent pas à la mécanique interne du système
informatique. Ly système est comme une boîte noire dont on essaie de décrire les
effets.
o Les diagrammes d’activité sont là pour capter une certaine forme d’exigence,
essentiellement les traitements et la dynamique à quels sont les modifications à
réaliser sur les données et dans quel ordre ces modifications doivent avoir lieu.
o Représenter un activité.
o Formalisme assez important pour le gestionnaire (cfr. Responsabilités du
gestionnaire)
- Définition 11 : Activité : est un graphe orienté dont les nœuds représentent ses composants,
comme des actions ou des nœuds de contrôle. Un nœud est une action = nœud de contrôle.
Ces différents nœuds sont connectés par des flèches ou des flux de contrôle ou des flux
d’objets.
o Un flux de contrôle provoque l’exécution d’un nœud qui est à la destination du flux.
o Un flux d’objets apporte en plus du contrôle, le transport d’informations.
o Détailler les fonctions à automatiser (grâce au formalisme du diagramme d’activité),
permet d’aller dans le détail, dans toutes les finesses du processus.
o Prévoir tous les comportements possibles y compris les comportements
exceptionnels de la fonction qu’on souhaite décrire (ex : l’article n’est pas reconnu
lors du scan, le client n’a pas assez de liquide ou de crédit sur sa carte pour régler
la vente). Toutes ces circonstances anormales doivent être intégrées dans la
description de la fonction pour permettre au système d’être robuste pour pouvoir
agir et fonctionner de manière saine, même dans des circonstances un petit peu
exceptionnelles.
2.3.1. ACTION ET FLUX DE CONTRÔLE

- Définition 12 : Action : représente une étape indivisible d’une activité. En général, une
action a lieu au même moment et au même endroit. Certaines actions peuvent être prise
en charge par le système informatique (automatisée ou non), à ce moment-là, l’action
consomme des données ou agit sur les données en modification. D’autres actions peuvent
être prises en charge par des acteurs humains (automatisée ou non).
o Exemples d’actions :
Rechercher un Passer un Préparer une

article examen commande
§ Une action est représentée par un rectangle aux coins arrondis

- Spécifier une action n’est pas toujours suffisant pour permettre à l’informaticien une
implémentation complète. C’est pourquoi, pour la plupart des actions, on va proposer des
postconditions pour décrire l’effet de l’action sur les données notamment.
o Exemple : Quel est l’effet de l’action préparer une commande ; qu’est-ce qu’on
peut affirmer comme étant vrai après l’exécution de cette action ? Les quantités
des articles commandés sont diminués (exemple d’une action sur les données).
24
Floriane Riga
- Définition 13 : Flux de contrôle : représente une transition entre deux actions/une action
prédécesseur vers une action successeur. 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/ on
a donc une sémantique de déclanchement qui explicite le fait que la fin d’une action
provoque le début d’une autre action.
- Exemple :
o flux de contrôle = Flèche allant du prédécesseur vers le successeur
o La fin de la préparation de la commande enclenche l’expédition de cette dernière.
Préparer une Expédier une
commande commande
- Une activité décrit le déroulement d’un processus dans le temps. Il est donc naturel de
mentionner le début et la fin de l’activité.
o UML a prévu deux symboles :
§ Un cercle plein pour marquer le début de l’activité
§ Un cercle plein entouré d’un autre cercle pur marquer la fin de l’activité.
o Par convention, nous n’utiliserons qu’un seul nœud de début et qu’un seul nœud
de fin d’activité pour un même diagramme d’activité.
o NB : UML permet d’avoir plusieurs nœuds de fin et de début mais nous n’utiliserons
pas cette facilité.
34
2.3.2. NŒUD
- Définition 13 : Le nœud de contrôle : organise des flux d’exécution d’une activité au-delà
des enchaînements séquentiels.
- Le nœud de décision permet de choisir une action qui va succéder à une autre.
o Il est représenté par un losange.
o Le nœud de choix a typiquement un flux rentrant et un nombre indéterminé de flux
sortants (dans l’exemple : 2 flux sortant).
o Chaque flux sortant est assorti d’une condition de garde qui doivent être
mutuellement exclusives.
o L’action qui sera enchaînée après la décision sera celle pour laquelle la condition
de garde est vérifiée. Par exemple : l’action « Évaluer une demande de crédit » sera
suivi de l’action « accorder le crédit » si la condition de garde « client solvable » est
vérifiée. Par contre, si c’est la condition de garde « client insolvable » qui est
vérifiée, alors c’est l’action « refuser le crédit » qui sera exécutée. à Enchainement
d’une action OU d’une autre suite à la décision.
34
Figure 2-26 : notation et exemple de flux de contrôle, pg 42
25
Floriane Riga
Action 1
(Condition de)
garde 1
Action 3
(Condition de)
garde 2
Action 4
35
- Le nœud de fusion (losange) comporte plusieurs flux rentrant qui peuvent chacun
déclencher à eux-seuls un flux sortant. L’une ou l’autre action peut chacun déclencher
l’action sortante.
36
- Avec le nœud de jointure (représenté par une barre), on a plusieurs flux rentrant et un seul
flux sortant. Tous les flux rentrant doivent être réalisés pour enclencher le flux sortant.
37
35
Figure 2-27 : notation et exemple de nœud de choix, pg 43
36
Figure 2-28 : notation et exemple de nœud de fusion, pg 43
37
Figure 2-29 : notation et exemple de nœud de jointure, pg 44
26
Floriane Riga
- Le nœud de bifurcation (fork) : Un seul flux entrant peut enclencher, en parallèle, plusieurs
flux sortant.
38
2.3.3. PARTITION
- Partition :
o Construction optionnelle des diagrammes d’activité.
o Localisation des actions ou d’une partie des actions de l’activité.
o Par exemple : toutes les actions réalisées dans le couloir back office (voir schéma),
seront exécutées au sein du back office.
o On peut combiner des partitions verticales avec des partitions horizontales.
o N’influence en rien les flux d’exécution d’actions. C’est simplement une localisation
de la documentation de l’acteur qui prend en charge l’exécution des actions.
39
38
Figure 2-30 : notation et exemple de nœud de bifurcation, pg 44
39
Figure 2-31 : notation de partition, pg 45
27
Floriane Riga
- Exemple :
40
o NB : Lancement de flux parallèles + récupération de ces mêmes flux est assez

courant (voir les deux barres).
41
o NB : Pour chaque action, on ne peut jamais avoir qu’un seul flux rentrant et un seul
flux sortant.
40
Figure 2-32 : exemple de diagramme d’activité pour traiter une commande, pg 45
41
Vidéo 2D : 05:04
28
Floriane Riga
o À la suite de l’action « ajouter un article », on boucle sur cette même action

jusqu’au moment où on ne souhaite plus en rajouter, et donc au moment où la
condition de garde « pas d’autres articles » est vérifiée.
2.3.4. FLUX D’OBJET, INTERRUPTION ET ZONE D’EXPANSION

2.3.4.1. FLUX D’OBJET
- Un flux d’objet est très comparable aux flux de contrôle. Si ce n’est qu’en plus de déclencher
des action, un flux d’objet véhicule de l’information entre les actions. Ces informations, en
UML, portent le nom d’objet et peuvent avoir un statut qui peut être modifié par les
différentes actions par lesquelles cet objet transite.
42
o Le flux d’objets est représenté par un rectangle.

o Très intéressant pour décrire le cycle de vie de certains objets (comme une
commande ou en objet en cours de fabrication).
2.3.4.2. ZONE INTERRUPTIBLE ET INTERRUPTION

- Zone. Interruptible :
o Autre facilité. Elle peut interrompre un ensemble d’actions qui sont reprises dans
une zone interruptible
43
42
Figure 2-33 : exemple de flux d’objets, pg 46
43
Figure 2-34 : exemple de zone interruptible, pg 47
29
Floriane Riga
o Zone interruptible représentée par une région délimitée par des pointillés
o On veut représenter qu’à n’importe quel moment de cette zone interruptible, on
peut interrompre le processus et réaliser autre chose que ce qui était prévu dans
la suite de l’exécution de la zone interruptible.
o Pour cela, on doit représenter un évènement qui marque l’interruption des actions
de la zone interruptible (« abandon »). Lorsque ça survient, Ce sont les actions
pointés par l’évènement qui prend le relais.
§ Dans l’exemple, si abandon, on annule la commande et on termine
l’activité.
44
44
Figure 2-35 : exemple d’erreurs dans un diagramme d’activités, pg 48
30
Floriane Riga
- Ne jamais mentionner le nom d’un acteur/département qui réalise une action comme étant
une action (« vendeur »).
- Ne pas mentionner des conditions de garde d’un nœud de décision comme étant des
actions (« si montant >< à 1000/1200 »). Ils doivent être mentionnés sur les flux de contrôle
(flèches) sortant du nœud de décision.
- Les conditions de garde sortant d’un même nœud doivent être mutuellement exclusives
(1000 ≠ 1200).
- Toujours avoir un flux entrant et sortant de chacune des actions (« accorder une
réduction »).
- Toujours bien indiquer le sens des flèches.
2.3.6. EXEMPLE
Commande Web
- 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
correspondant à un sport, comme une rubrique tennis ou une rubrique jogging.
45
- 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.
o On retrouve une première boucle qui nous permet d’exécuter autant de fois qu’on
le souhaite « choisir article », encore faut-il compléter cette solution pour pouvoir
sortir de cette boucle.
46
- Exigence 3 : L’internaute peut naviguer vers d’autres rubriques pour sélectionner d’autres
articles à commander.
45
Figure 2-36 : commande web - identification, pg 49
46
Figure 2-37 : commande web- choix d’article, pg 49
31
Floriane Riga
o NB : pour n’importe quel nœud, on peut avoir autant de nœuds entrants et sortants
que l’on souhaite.
47
- 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.
o Dans un premier temps : option « déjà identifié » :
48
47
Figure 2-38 : commande web- changement de rubrique, pg 50
48
Figure 2-39 : commande web- clôture de transaction, pg 51
32
Floriane Riga
o Dans un second temps : rajouter l’option « pas identifié » :
49
49
Figure 2-40 : commande web- clôture avec identification, pg 52
33
Floriane Riga
2.3.7. QUESTIONS D’EXAMEN
34
Floriane Riga
35
Floriane Riga
2.4. DIAGRAMME ENTITÉ/ASSOCIATION
- On a, jusqu’ici, parlé de traitements : ils peuvent agir sur les données. Les données peuvent
être modifiées, supprimées, etc. par les différentes actions qui s’enchaînent au cours des
traitements.
o Structure : rouge
o Données brut : bleu
o Ces grappes de données peuvent avoir des correspondances/connexions entre
elles.
- Définition 15 : Diagramme Entité/Association (DEA) : décrit les structures des données
utiles (qui sont pertinentes) pour l’utilisateur. Il spécifie la nature des liens (représente les
connexions) entre les données ainsi que les contraintes qui conditionnent leur validité (qui
vont contribuer à la qualité des données).
o Exemple : spécifier que le salaire d’un employé doit se trouver dans une fourchette
donnée.
o Relève de la partie structurelle des exigences (Système logiciel à Structures,
Interfaces, Fonctions, Dynamique : pg 19)
o Être attentif à bien représenter les structures de données utiles pour son entreprise.
o En informatique, poids important sur la gestion des données :
§ Faire l’inventaire des types de données.
o Penser à toutes les données indispensables pour mener à bien les processus
d’affaires au jour le jour.
o Anticiper tout ce qu’il souhaite produire comme tableaux de bord, indicateur de
performance pour l’aide à la décision (chap. 4).
2.4.1. ENTITE
- Définition 15 : Entité : représente un ensemble d’objets du domaine d’application qui
présentent des caractéristiques semblables (ensemble d’objets du monde réel auxquels on
souhaite garder une trace dans un futur système informatique).
o Ils ont la même nature
o Représenter ces objets au travers d’une entité
o Les différences deviennent des instances des entités.
36
Floriane Riga
50
- Lors de la construction d’une entité, il y a une démarche d’abstraction = de simplification.

On va volontairement éviter de représenter des détails qui sont jugés « inutiles ».
o Dans cet exemple : sélection de 4 caractéristiques.
o Focus sur la classe/la famille d’objets (voiture).
2.4.2. ASSOCIATION
- Définition 15 : Une association : binaire (qui connecte deux entités) schématise une
correspondance entre deux entités, et représente l’ensemble des liens entre ces instances.
o Chacun des liens est une instance de cette association.
51
- Cardinalité : Sur chaque arque connectant une entité et une association, on a mentionné
un tandem de cardinalité : cardinalité minimale & cardinalité maximale.
o Exemple : pour une personne donnée, combien de villes connectées au minimum
et au maximum ?
52
o On peut connecter une personne à minimum une ville (valeur de la cardinalité

minimale à gauche) et au maximum une ville (valeur de cardinalité maximale à
droite) à Cfr. encadré bleu.
o À l’inverse, le nombre de connexions minimales que l’on peut faire d’une ville vers
une personne est de 0 (valeur à gauche) et la valeur maximale (à droite) n’est pas
50
Figure 2-46 : un exemple d’entités et de ses instances : pg 58
51
Figure 2-47 : exemple d’association binaire : pg 59
52
Vidéo 2E : 07:23
37
Floriane Riga
connue et est donc représentée par une inconnue de valeur « N » à Cfr. encadré
orange.
o La cardinalité minimale doit être ≤ à la cardinalité maximale :
§ Min : entier (0 compris)
§ Max : entier (0 exclus), N (indéterminé)
§ Contrainte
- Association entre deux mêmes entités (personne & villes):
o Connectées par plusieurs associations : entretenir, entre des personnes et des villes,
des liens de différente nature comme l’habitation ou le lieu de travail.
o Les arcs d’une association (« est un habitant », « a des citoyens ») peuvent être
libellées avec du texte libre pour mieux documenter le rôle d’une instance dans la
participation dans une association.
53
- Association cyclique :
o Des produits sont eux-mêmes connectés à d’autres produits selon une sémantique
de kits.
o Dès qu’on veut représenter des liens entre des instances de même nature (produits,
personnes, sociétés), ces liens peuvent être matérialisés par une association
« symétrique » ou « réflexive » qui connecte une entité à elle-même.
54
- Association ternaire/d’ordre supérieur à 2/n-aire : qui connecte plus de 2 entités
55
2.4.3. ATTRIBUT
- Définition 15 : 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.
- 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.
o Exemple classique : adresse à rue, numéro, code postal, etc.
53
Figure 2-48 : exemple d’association avec rôles et attributs : pg 60
54
Figure 2-49 : exemple d’association cyclique : pg 61
55
Vidéo 2E : 11:02
38
Floriane Riga
56
o Dans l’exemple ci-dessus, on voit que l’adresse est composée de différents attributs
– des attributs composant – qui sont légèrement indentés par rapport aux
composites (rue, numéro, etc.). ça permet de représenter une
structuration/hiérarchie dans les différents attributs d’une entité.
- Certains attributs jouent le rôle d’identifiant. C’est une valeur qui permet de distinguer une
instance d’une entité d’une autre.
o Dans le cas de l’entité « client », l’attribut « numéro » est unique et joue le rôle
d’identifiant.
o Un identifiant peut être composé de plusieurs attributs, comme l’entité « article ».
Nous aurons besoin de la valeur de deux attributs (famille et numéro) pour
retrouver une instance d’articles parmi d’autres.
o Parfois, le domaine d’application ne fournit pas d’identifiant claire. Pourtant, cette
identification est très importante, notamment pour la réalisation d’une base de
données.
§ Rajout d’un attribut un peu artificiel : identifiant technique. Ses valeurs
permettront de retrouver une instance parmi d’autres.
- Nous retrouvons la notion de cardinalité chez les attributs. Les cardinalités d’attribut
déterminent le nombre minimum et maximum de valeurs pour cet attribut, pour une
instance donnée.
o Dans le cas de l’attribut téléphone, nous avons une cardinalité de minimum de zéro
(on pourrait avoir minimum 0 valeurs, pour le téléphone, pour une instance
donnée). Cardinalité maximum = 5
o Si attribut minimum = 0 à facultatif
o Si attribut > 0 à obligatoire
o Attribut mono valué à Maximum = 1
o Attribut multi valué à Maximum > 1 (N valeur)
o Par défaut, les cardinalités sont évaluées à (1;1) à cas le plus fréquent à mono
valué et obligatoire.
- Domaine : ensemble de ses valeurs permises
o On peut spécifier pour un attribut donné, un ensemble de valeurs qui sont
autorisées à l’utilisateur, c’est ce qu’on appelle un domaine. C’est un exemple de
contrainte d’intégrité.
o Exemple : pour un attribut salaire, on pourrait tolérer que les valeurs comprises
dans une certaine fourchette à (500,10000). On attribuera, pour cet attribut
« salaire », un domaine.
- Attribut dérivé : certains attributs peuvent être calculés à partir des valeurs d’autres
attributs.
o Exemple : prix TVAC = prix HTVA*(1+taux TVA)
56
Figure 2-50 : exemple attributs, de cardinalités d’attributs et d’attributs composites : pg 62
39
Floriane Riga
2.4.4. GÉNÉRALISATION/SPÉCIALISATION
- Les trois entités recouvrent des concepts assez proches. Elles ont toute une série d’attributs
en commun (nom, numéro, prénom). Pourquoi ? Car ces trois entités (client, prospect et
employé) sont des déclinaisons d’un concept plus général, ce sont des personnes.
o On peut mentionner ce concept plus abstrait à travers une structure de
généralisation/spécialisation, représentée par un triangle, et qui connecte une
entité plus générale (personne) vers des entités plus spécifiques.
o Généralisation : aller du plus spécifique vers le plus général.
o Redondance au niveau des caractéristiques : numéro, nom, prénom. Avec le
mécanisme de généralisation/spécialisation, il est possible de le mentionner
qu’une seule fois en les définissant au niveau de l’identité personne et en
implémentant, de manière implicite, un mécanisme d’héritage : toutes les
propriétés de « personne » seront héritées par les « clients, prospects et
employés ».
o Les entités les plus personnalisées sont perçues comme des catégories de l’entité
la plus générale. Client/prospect/employé sont des catégories de personne.
57
- Définition 19 : 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égories. Les caractéristiques
de cette entité sont héritées par les entités les plus spécifiques.
o Construction bottom-up : partir d’une spécialisation pour les abstraire en une
généralisation.
o Construction top-down : partir d’une entité générale qu’on détaille/raffine en
différentes spécialisations. Exemple :
58
57
Figure 2-52 : exemple de généralisation : pg 64
58
Figure 2-54 : exemple de spécialisation : pg 65
40
Floriane Riga
- Les deux propriétés de la généralisation/spécialisation :

o Y aurait-il des personnes qui ne seraient ni des clients, ni des prospects, ne des
employés ?
§ Oui : généralisation/spécialisation partielle
§ Non : généralisation/spécialisation totale à chaque instance de personnes
sera l’instance d’au moins une spécialisation.
o Une même personne peut-elle être reprise dans plusieurs catégories ?
§ Oui : les catégories se recouvrent : la généralisation/spécialisation est avec
recouvrement.
§ Non : généralisation/spécialisation disjointe. Elles sont cloisonnées, sans
intersections.
o On formule les propriétés de la généralisation/spécialisation tout près du triangle
(encadré gris). Dans cet exemple on retrouve les propriétés « total et disjoint », ce
sont les cas les plus fréquents.
59
59
Figure 2-53 : exemple de l’héritage : pg 64
41
Floriane Riga
- Exemple n°1 :
o Des séminaires sont organisés sous forme de sessions qui se déroulent à une
certaine date. Une session est animée pour un ensemble de participants. Une
session est reliée à des locaux et un séminaire est animé par 1 ou plusieurs
conférenciers.
o Les conférenciers et les participants sont des catégories de personnes. Une même
personne peut être conférencier et participant (propriété de recouvrement).
- Exemple n°2 :
60
o Généralisation/spécialisation multi niveaux.

o Les articles peuvent être spécialisés en Food et non-Food. Les articles Food peuvent
être spécialisés en épicerie, frais et surgelé, etc.
o Attention, pour être complet, il FAUT spécifier les propriétés de la
généralisation/spécialisation.
60
Figure 2-56 : exemple d’arbre de généralisation/spécialisation : pg 66
42
Floriane Riga
- Exemple n°3 : Autre situation particulière
61
o Des personnes connectées à des villes selon deux associations. Rien n’empêche
d’avoir autant d’association qu’on souhaite entre deux mêmes entités (habite &
travaille).
o NB : On peut (option) libeller les arcs qui connectent les entités à l’association dans
une volonté de pédagogie de documentation.
- Exemple n°4 : Associations symétriques
62
o Un produit est associé à lui-même dans une composition de kit. Ça veut donc dire
que plusieurs produits peuvent rentrer dans la composition d’un autre produit (kit).
Mais ces produits qui rentrent dans la composition d’autres produits sont eux-
mêmes des produits. On se retrouve dans une situation particulière où une entité
est associée à elle-même.
61
Vidéo 2F : 08:06
62
Vidéo 2F : 08:43
43
Floriane Riga
- Stock : « numStock » devrait être définit comme identifiant de cette identité Stock
- Détail commande : pas d’identifiant déclaré à rajouter un identifiant technique
- La cardinalité d’ « article » vers « pour » : qui devrait être de 0-N étant donné qu’on peut
retrouver le même article dans plusieurs commandes/ un même article peut être repris
plusieurs fois dans un détail de commande.
- Triangle généralisation/spécialisation : oublié de mentionner les propriétés
- Brico : redéfinit les attributs « modèle » et « quantité en stock » qui sont pourtant hérités
au niveau d’ « article » .
- Employé/Facture : généralisation/spécialisation problématique étant donné que ni les
employés ni les factures sont une catégorie de commandes.
- NumCli dans « commande » : veut probablement mentionner le fait qu’une commande est
liée à un client mais pas correct car l’association « passe » exprime le lien entre une
commande et un client.
44
Floriane Riga
2.5. NOTATIONS
- Une entité est représentée dans un rectangle à coins carrés

- Les attributs composent l’entité
- L’identifiant est un attribut souligné
- On peut spécifier entre crochet, derrière un attribut, une paire de cardinalité indiquant le
minimum et maximum
o Par défaut, 1-1
- L’attribut composite peut être représenté en indentant ses attributs composant
- Les entités sont connectées par des associations qui peuvent elles-mêmes avoir des
attributs
o Chaque arc connectant les entités aux associations doivent être assorties à une
paire de cardinalité (min-max)
- Les entités peuvent être spécialisées avec des mécanisme de généralisation/spécialisation
(triangle)
o Spécifier les propriétés de ce mécanisme en choisissant entre :
§ Total ou partiel (toutes la catégorie représentée)
§ Disjointe ou recouvrement (plusieurs fois le même élément de la
catégorie ?)
2.6. CONCLUSION
- 3 langages de modélisation graphique

o Diagramme de cas d’utilisation : représente les acteurs qui vont interagir avec le
système + scénarii d’utilisation. Souvent utilisé en début de projet car il propose
une découpe des fonctionnalités. Il débarrasse de tout détail technique. C’est dirigé
vers les fonctionnalités (le « quoi »).
o Diagramme d’activité : porte sur la modélisation des processus (automatisation ou
non). Détailler les processus annoncés par les cas d’utilisation. Décomposer des
enchaînements complexes d’actions.
o Diagramme E/A : décrire les structures de données utiles pour les utilisateurs.
Aspect informationnel du futur système. Les managers y répertorie les données qui
font l’objet de traitements spécifiés par les cas d’utilisation.
45
Floriane Riga
3. CHAPITRE 3 : BASES DE DONNÉES
3.1. DÉFINITIONS ET APPLICATIONS
- Omniprésence des BDD

- Les entreprises sont amenées à gérer beaucoup d’informations. Une partie d’entre elles
sont numériques. Dans ces données numériques, on va identifier une catégorie particulière :
o Les données structurées : répond à un schéma/organisation régulière. Par exemple :
tous les clients d’une entreprise auront toujours, au niveau de l’ordonnée, les
mêmes caractéristiques (nom, email, adresse, num TVA). C’est ce qu’on désigne
par des données structurées et c’est l’objet d’une base de données : stocker un très
grand nombre de données structurées.
o Le système informatique : gère les données numériques. Un composant de ce
système informatique, système de gestion de bases de données, va gérer ces
données structurées.
63
- Définition 21 : Une base de données : est une collection de données essentiellement

structurées. Les BDD peuvent stocker de plus en plus de données avec peu/pas de structure
(textes/images).
o Réalise une intention de centralisation : au sein d’une entreprise, on va vouloir
réaliser une BDD unique dans laquelle seront reprises toutes les données
structurées. Sans cette centralisation, on risque d’avoir une multiplication des
versions des mêmes données avec des problèmes de MAJ importants.
o La centralisation implique que la BDD va être accédée/partagée par tous les
collaborateurs d’une entreprise. à Multi utilisateurs avec comme corolaire, un
impératif de contrôle d’accès.
o Pour décrire les structures des données d’une BDD, on a besoin de rédiger un
schéma de données exprimé dans un langage particulier, le modèle correspondant.
63
Figure 3-1 : systèmes et catégories de données : pg 82
46
Floriane Riga
- Définition 22 : Un modèle de données: est ensemble de constructions générique 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 23 : 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.
- Une BDD contient donc deux choses :

o Les données brutes : Nom, prénom, fonction, etc.
o Le schéma : caractérise les données brutes en spécifiant le nom des colonnes et le

type de données.
o Conclusion :
- Pour interagir avec la base de données (ensemble de zéros et de uns), il faut du logiciel. Ce
logiciel, c’est un système de gestion de bases de données (SGBD).
47
Floriane Riga
- Définition 24 : Un système de gestion de bases de données (SGBD): est un ensemble de

composants (2 composantes citées ci-dessus) 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. (autoriser
certains utilisateurs à accéder à certaines données).
o Exemple des fonctions :
§ Créer une BD
§ Manipuler les données (CRUD : Create, Read, Update & Delete)
§ Créer des comptes utilisateurs et des accès (sécurité)
§ Gérer des accès concurrents (situation où plusieurs utilisateurs veulent
interagir en même temps avec les mêmes données)
§ Récupération sur incident (repartir avec des données saines même en cas
de crash disc)
- Applications : deux grandes catégories d’application
o Informatique transactionnelle (systèmes transactionnels) :
§ Supporter l’automatisation des processus d’affaire au quotidien
• Exemple : garder des traces des transactions commerciales d’une
entreprise en stockant en temps réel les données de vente, les
modifications de clients, les mouvements de stock
§ Les BD offrent des services de persistance (stock) au programme
d’application en stockant les données produites par différents
programmes d’application (GRH, vente, etc.)
§ Les BDD sont utilisées selon un mode technique bien particulier : OLTP (On
Line Transaction Processing)
o Informatique décisionnelle (systèmes d’aide à la décision) :
§ Analyser des gros volumes de données consolidés afin de tracer des
connaissances/informations utiles afin de guider le gestionnaire dans son
processus de décision
§ Utilisation des BDD pour consolider et stocker toutes les données qu’on
souhaite utiliser (Data Warehouse)
§ Mode OLAP: On Line Analytical Processing
3.2. ARCHITECTURES
- Système informatique : système complexe (nombreux serveurs, postes clients, etc.)

o composé de modules dont le SGBD
- SGBD est lui-même complexe
o composition interne à détailler
- Définition 25 : L’architecture : sert à décrire l’organisation d’un système en différents
composants ainsi que leurs interactions.
o Explicite la manière dont les composants interagissent les uns avec les autres.
3.2.1. ARCHITECTURE LOGIQUE

o Nous savons que la base de données est constituée d’un schéma et de données qui
régissent cette base de données.
o Une base de données est traitée par un logiciel qui s’appelle SGBD
§ Maîtriser le langage SQL pour actionner le système
§ Avec le SQL, on peut manipuler les données, les schémas
48
Floriane Riga
64
o L’utilisateur peut directement envoyer des instructions SQL au SGBD (exemple :

afficher la liste de tous les clients habitant à Bruxelles).
o D’autres utilisateurs, ne souhaitant pas actionner le SGBD directement en
connaissant le SQL, peuvent utiliser des programmes d’applications
§ Ces programmes vont offrir une interface aux utilisateurs confortable. Ils
vont générer des instructions SQL à destination du SGBD.
§ Ça offre de la facilité aux utilisateurs mais moins de flexibilité car le système
les enferment dans ce qu’ils savent faire.
3.2.2. ARCHITECTURE CLIENT SERVEUR

- Met en jeu deux parties : le client et le serveur
o Le client va emmètre une requête à destination du serveur. Le serveur va répondre
à la requête en réalisant un certain traitement et en renvoyant un résultat au client.
o Distribution du traitement sur 2 composants : client & serveur :
§ Le client prend en charge l’interface homme-machine (le pilotage du client,
le dessin des écrans) et le traitement local de certaines données
§ Le serveur va gérer la persistance (stockage), les instructions SQL, le
contrôle d’accès, etc.
§ Cette informatique collaborative permet de mieux gérer la complexité des
traitements à mettre en œuvre au niveau du système informatique dans sa
globalité.
65
64
Figure 3-3 : architecture d’une BD et d’un SGBD : pg 86
65
Figure 3-4 : fonctionnement de l’architecture client-serveur : pg 87
49
Floriane Riga
o Apports :
§ Autonomie du gestionnaire : rapatrier des données qui sont stockées dans
une BDD pour les exploiter à des fins personnelles : analyses, prédictions,
publipostage
3.2.3. ARCHITECTURE À 3 TIERS

- Déployée dans l’internet
- 3 composants :
o Client web : simple terminal sur lequel fonctionne un navigateur. Il est connecté sur
l’internet tout comme les serveurs web avec lesquels il va interagir
o Serveur web
o Serveurs BD : qui peuvent interagir avec les serveurs web
- Fonctionnement :
o Le client web va émettre une requête à l’intention des serveurs webs
o Ceux-ci vont rentrer en communication avec un/des serveurs BD en leur envoyant
des requêtes SQL à exécuter
o Le serveur BD va renvoyer des réponses à relatives à l’exécution des requêtes vers
les serveurs web
o Un de ces serveurs (le serveur d’application) aura la responsabilité de récupérer
les données, de les traiter et de les mettre en forme pour produire un résultat sous
forme de page web à remettre au client.
- Dans cette architecture collaborative, on réparti le traitement sur trois composants à
distribution des traitements selon différentes couches.
o Serveurs BD : Couche données/gestion de la persistance (stocks)
o Serveurs web : couche traitement : réalise toute la logique applicative du système
o Client : couche présentation : affichage de pages web
- Avantages :
o Un simple navigateur web permet de réaliser plein d’applications différentes
(gestion de stocks, commandes à partir d’un navigateur qui fonctionne à travers un
smartphone, une tablette, un ordinateur).
o Ca apporte beaucoup d’ubiquité66 et d’indépendance par rapport à leur terminal
de travail
o Permis de développer massivement l’économie digitale : commerce électronique
o Utilisé aussi bien pour gérer le front office et le back office des applications
67
66
Capacité d'être présent en plusieurs lieux à la fois
67
Figure 3-5 : architecture à trois tiers : pg 89
50
Floriane Riga
3.3. SÉCURITÉ DES BASES DE DONNÉES
- Sécurité :
o Ampleur inouïe de la digitalisation de notre vie privée et professionnelle
o Systèmes d’informations et BDD des entreprises deviennent accessibles sur
internet
o Ces BDD contiennent des informations/données personnelles sur des clients, la
santé, le coût de revient sur les produits
o Ces patrimoines d’informations intéressent les cybercriminels car ils peuvent en
tirer un certain profit
o Les régulations émergent à RGPD (règlement général sur la protection des
données à caractère personnel) qui tente d’influencer dans le bon sens les acteurs
de la sécurité des systèmes informatiques
- Définition 26 : La sécurité des données : consiste à respecter au minimum trois propriétés :

o La confidentialité : qui signifie que les données sont accessibles exclusivement aux
utilisateurs autorisés ;
o L’intégrité : qui garantit le maintien du caractère correcte et complet des données.
Une donnée ne peut être modifiée ou supprimée que par les utilisateurs autorisés ;
o La disponibilité : qui assure que les données restent accessibles aux utilisateurs.
- 2 des techniques pour sécuriser les données :
o Les transactions
o Les modèles de contrôle d’accès
o NB : il en existe d’autres tel que le chiffrement, les antivirus, etc.
51
Floriane Riga
68
3.3.1. GESTION DES TRANSACTIONS

- Définition 27 : Une transaction : reprend un ensemble d’opérations à réaliser sur les
données (lecture, modification, effacement d’une donnée) et correspond à une seule unité
logique de traitement du point de vue de l’utilisateur.
o Exemple : lorsqu’un comptable débite un compte, en crédite un autre et enregistre
l’écriture comptable dans un journal, cela constitue une unité logique et indivisible
o Les système de gestion de BDD sont capables d’exécuter, en même temps, un très
grand nombre de transactions
o Permet une utilisation multi-utilisateurs des BDD avec des données partagées et un
travail collaboratif
- Les transactions doivent respecter 4 propriétés qui sont reprises par ACID :
o Atomicité : toutes les actions doivent être exécutées par le SGBD à Tout ou rien
o Consistance : force le SGBD à respecter les contraintes d’intégrité lorsqu’il exécute
une transaction
o Isolation : garantit qu’il n’y a pas d’interférences mutuelles entre des transactions
concurrentes (ne peut pas modifier des données qui sont en cours de modification
dans une autre transaction sinon problème d’intégrité)
o Durabilité : garantit l’effet permanent des modifications d’une BDD suite à
l’exécution d’une transaction, même s’il se passe des évènement grave comme des
crash disc ou bien un incendie dans des salles de serveurs.
3.3.2. CONTRÔLE D’ACCÈS

- Définition 28 : Un contrôle d’accès : est un mécanisme assurant la définition et la
vérification des autorisations à un utilisateur pour traiter les données d’une BDD. (Quels
utilisateurs peuvent accéder à quelles données et selon quel mode ?)
o Étapes de l’accès aux données :
§ Identification/authentification à Prouver notre identité en fournissant un
mot-de-passe
§ Reçoit une autorisation de la part du système qui va permettre d’accéder
à certaines données
o Enjeu pour le gestionnaire :
§ Implémenter la sécurité
68
Figure 3-6 : exemples de questionnement à propos de la sécurité des BD : pg 90
52
Floriane Riga
Exprimer techniquement des autorisations qui sont le reflet des exigences

§
métier
- Deux grands modèles d’accès :
o DAC (discretionary Access Control) à modèle d’accès discrétionnaire
§ Tout ce qui n’est pas autorisé est interdit
§ Celui qui autorise l’utilisateur d’accéder à telle ou telle donnée est le
propriétaire de ces données
§ Problème du modèle : si on a beaucoup d’utilisateurs et beaucoup de

données différentes, il faudra accorder un grand nombre d’autorisations
(très lourd)
o RBAC (Role-Based Access Control)
§ Idem mais autorisations conférées à des rôles
§ Un utilisateur peut hériter de rôles (et de ses autorisations)
§ Ça réduit le nombre d‘autorisations à déclarer
§ Impact : correspondances entre les rôles définit dans une BDD et les
fonctions d’une entreprise à Correspondance business - technique
3.4. MODÈLE RELATIONNEL
3.4.1. TABLE
- Définition 29 : Une table : contient les données d’un ensemble d’objets similaires du
domaine d’application (toutes les données concernant des étudiants, des produits, etc.).
Les colonnes de la table correspondent aux caractéristique de ces objets, tandis qu’une
ligne reprend les données d’un même objet.
o Il n’y a pas de relation d’ordre au niveau d’une table (même si on peut demander à
un SGBD de trier des données sur l’une ou l’autre colonne à n’importe quel
moment)
69
o Colonne :
§ Nom de la contrainte
§ Type de données : caractère, de la date, du numérique
§ Contraintes : qui correspondent aux données enregistrées dans cette
colonne
69
Figure 3-7 : exemple d’une table EMPLOYE : pg 93
53
Floriane Riga
§ Absence de valeur = valeur NULL

• Ambigüe : la donnée peut ne pas être pertinente ; la prime n’a pas
lieu d’être pour Peeters ; on ne dispose pas de cette valeur et on
ne peut pas l’enregistrer dans la BDD
§ Numéro d’employé : joue le rôle d’identifiant ou de clé primaire. Cette
colonne permet de distinguer un employé d’un autre. Ça implique donc
une clé primaire :
- Définition 30 : La clé primaire : d’une table est une colonne ou une collection de colonnes
dont les valeurs identifient univoquement (sans ambiguïté) une ligne de la table.
o On peut avoir, dans une table, plusieurs clés primaires candidates (numéro interne
d’un employé, numéro d’identification national, etc.). On va choisir qu’une seule
clé primaire parce qu’il n’y en a qu’une seule retenue par table, et les clés primaires
candidates qui n’auront pas été retenues seront des clés secondaires.
o Les clés primaires et secondaires sont assorties de 2 contraintes :
§ L’unicité : toutes les valeurs d’un identifiant doivent être uniques
§ Non NULL : on doit fournir une valeur pour toutes les lignes au niveau de
la clé primaire
- Travailler avec une telle structure (voir ci-dessus), n’est pas terrible car :
o Il y a plein de redondances dans cette table :
§ La localisation du département de production, Wavre, est répétée pour
tous les employés de ce département (4x)
§ Problème de MAJ à si déménagement, il faut modifier la localisation pour
tous les employés ce qui est assez lourd
§ Comment faire pour représenter un département qui n’aurait aucun
employés (qu’on vient de créer) ? Ça manque de naturel
- Solution :
o Exploser cette table en 2 tables
o La colonne NumDep de la table employé à un statut très particulier, puisqu’elle fait

référence à une clé primaire d’une table étrangère, c’est une clé étrangère.
54
Floriane Riga
- Définition 31 : Une clé étrangère d’une table : est une colonne ou une collection de
colonnes dont les valeurs font référence aux valeurs de la clé primaire d’une autre table.
o Les correspondances entre des employés et des départements (voir tableau)
suivent une logique de 1 à plusieurs (voir flèche bleue) à Pour 1 département, on
peut connecter plusieurs employés
o Dans le modèle relationnel, on peut représenter des correspondances de 1 à 1
(nous ne le développerons pas) ; de 1 à plusieurs (comme c’est le cas ici) ; mais pas
de plusieurs à plusieurs
- Dans la suite, nous allons représenter les schémas, de 1 à plusieurs (one to many), comme
suit :
70
o Rectangles qui reprennent les noms des tables ainsi que leurs colonnes respectives
o Des correspondances entre tables indiquées par des flèches entre ces différentes
tables
o Les clés primaires seront soulignées et les clés étrangères seront écrites en italique
- Les correspondances de plusieurs à plusieurs (many to many) :
o Exemple avec des commandes qui peuvent porter sur plusieurs articles et des
articles qui, eux-mêmes, peuvent porter sur plusieurs commandes
o On fait donc face à une correspondance de plusieurs à plusieurs qui n’est pas
directement supporté par les BDD relationnelles.
§ Rajouter une table de lien (ligne de commande) qui contiendra 2 clés
étrangères (NUMCOM & NUMART) qui feront respectivement référence
aux tables commande et articles
§ à Décomposer 1 correspondance de plusieurs à plusieurs en 2
correspondances de 1 à plusieurs
71
70
Figure 3-8 : exemple de correspondance de 1 à plusieurs : pg 94
71
Figure 3-9 : exemple de correspondance de plusieurs à plusieurs : pg 95
55
Floriane Riga
§ La commande 2016/21 porte donc sur les articles 1, 3 et 4. Pour une même
commande, on retrouve plusieurs articles
§ À l’inverse, le même article (par exemple : article 4) peut être repris dans
plusieurs commandes
3.4.2. CONTRAINTE D’INTÉGRITÉ

- Le modèle relationnel subit toute une série de contraintes d’intégrité72 qui contribuent à la
qualité et la sécurité des données. Exemples :
o Un utilisateur maladroit enregistre une valeur aberrante au niveau de la clé
étrangère. Il enregistre la valeur 73 pour un département alors qu’il n’y a pas de
valeur 73 dans cette table de départements à il faut mettre en place une
contrainte d’intégrité référentielle qui va systématiquement vérifier la bonne
correspondance entre les valeurs d’une clé étrangère par rapport à la valeur d’une
clé primaire.
o Un utilisateur maladroit oublie d’enregistrer le nom pour un employé. Là non plus,
ça n’a pas de sens. La valeur du nom est obligatoire pour tous les employés : on
peut donc spécifier au niveau d’une colonne une contrainte de non-nullité pour
forcer l’utilisateur à enregistrer une donnée dans une colonne dite « non-nulle ».
o On enregistre une valeur de -1500 pour le salaire de Somville. C’est une erreur qui
peut être évitée en spécifiant, toujours au niveau d’une colonne, une contrainte de
domaine qui va forcer l’utilisateur à enregistrer des valeurs comprises dans une
fourchette de données spécifiées par la contrainte de domaine.
o On peut spécifier, au niveau d’une colonne, une contrainte d’unicité : c’est-à-dire
qu’on doit intégralement retrouver des valeurs différentes. On la retrouve
systématiquement dans une clé primaire (qui sert à identifier) mais également dans
d’autres colonnes.
§ Si nous ne nous trouvons pas dans une clé primaire, l’unicité tolère la nullité
mais toutes les valeurs non-NULL doivent être, elles, de valeurs différentes.
72
qui garantit le maintien du caractère correcte et complet des données. Une donnée ne peut être modifiée ou
supprimée que par les utilisateurs autorisés.
56
Floriane Riga
3.5. PRINCIPES DE GÉNÉRATION D’UN SCHÉMA ET D’UNE BD RELATIONNELS
- /
3.6. LANGAGE SQL
SUR UNE TABLE

- Rappel : le langage privilégié pour manipuler une BDD avec un système de gestion de BDD
(SGBD), c’est le SQL. Un utilisateur peut, s’il maîtrise ce langage, exploiter une BDD en toute
indépendance, sans l’aide d’un informaticien. D’autres utilisateurs vont passer par
l’intermédiaire de programmes d’utilisation qui vont eux-mêmes générer les instructions
SQL à leur place.
- Définition 32 : 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.
o C’est un standard : si un utilisateur maîtrise le langage, il pourra utiliser tous les
SGBD qui respectent ce standard (grande majorité), ce qui est un avantage.
o Il est déclaratif : l’utilisateur doit annoncer le résultat qu’il souhaite obtenir et c’est
la machine (le SGBD) qui va déterminer le meilleur chemin à suivre pour obtenir le
résultat escompté
- Pour structurer le SQL, on l’a divisé en sous-langages :
o Data Definition Language (DDL) : reprend les instructions pour créer les objets du
schéma de la base de données
57
Floriane Riga
§ Dans l’exemple ci-dessus, on retrouve la table « employé » qui a une

première colonne comportant une chaîne de caractères de maximum 10
positions et qui jouera le rôle de clé primaire (PRIMARY KEY)
§ Dans un schéma de BDD, on peut créer toutes sortes d’objets en dehors

des tables : par exemple des vues : ce sont des tables immatérielles crées
sur des requêtes SQL qui permet de mieux contrôler les accès aux données
et de cacher une certaine complexité du schéma aux utilisateurs.
§ Création d’un nouvel objet : VUE_GRH
§ Se manipule comme une table mais qui est en réalité un accès à une table
à travers une instruction SQL « select »
o Data Control Language (DCL) : Créer des utilisateurs. Avec l’instruction grant, on.
Peut autoriser l’utilisateur à accéder aux différents objets de la BDD.
§ Dans cette manipulation, on autorise l’utilisateur James à accéder à la table.

Employé pour réaliser des sélections de données.
o Data Manipulation Language (DML) : On peut agir sur les données proprement
dites.
§ Par exemple, l’insertion insert permet de rajouter des lignes dans une table
§ Effet de l’exemple : ajouter une nouvelle ligne dans la table. Employé qui
va comporter l’élément entre parenthèses
§ Select : on peut rechercher des données dans une table

§ Dans ce cas-ci, on demande un affichage de deux colonnes (nom et salaire)
à partir d’une table sur les employés
58
Floriane Riga
§ Update : permet de modifier les données : ex : en augmentant le salaire

des employés de 10%
§ Delete : on peut supprimer des lignes dans une table : ex : supprimer toutes
les lignes des employés où la condition est satisfaite à NumDep =1
3.6.1. SÉLECTION SUR UNE SEULE TABLE

- Attention, pour réaliser une requête sur une BDD, il faut disposer du schéma de la BDD
o Nous allons travailler avec un schéma contenant deux tables : « employé et
département »
INSTRUCTION SELECT
- Syntaxe simplifiée :
o 2 clauses obligatoires:
§ Select : indiquer les colonnes qui doivent faire partie du résultat
§ From : spécifier la/les tables(s) d’où proviennent les colonnes à afficher
o 2 clauses optionnelles:
§ Where: indiquer des conditions pour filtrer les lignes à afficher
§ Order by: spécifier les colonnes qui vont jouer le rôle de clé de tri dans
l’affichage de résultats
o Exemple :
§ On affiche une colonne (nom) en provenance de la table « employé »
§ Le deuxième précise qu’on affiche toutes les colonnes (*) de la table
« employé »
59
Floriane Riga
TRI
- Par défaut, le résultat d’une instruction SQL n’est pas ordonné
o Order By : forcer le tri de colonne (sur le nom par exemple)
o Dans ce deuxième exemple, on a placé deux clé de tri derrière order by :

§ Premier tri sur la fonction
§ Et puis pour tous les employés ayant la même fonction, on va faire un tri
secondaire sur le nom
§ NB : par défaut, l’ordre de tri est ascendant, on doit donc indiquer le mot
clé « descending » ou bien « desc » afin de renverser vers une
descendance ; pour croissance (ascending) à asc (par défaut)
§ Résultat :
60
Floriane Riga
61
Floriane Riga
LIGNES DUPLIQUÉES
o Avec Select Fonction From Employé, on va afficher toutes les valeurs des fonctions
pour tous les employés de la table employé
§ La valeur d’une fonction sera renvoyée autant de fois qu’il n’y a d’employés
au sein de cette fonction
o Si on veut obtenir des valeurs différentes d’une ligne de résultats, il faut placer
derrière « select » le mot « distinct »
§ Select distinct fonction va afficher les occurrences uniques des fonctions
§ NB : l’unicité se joue sur la ligne et pas la colonne
62
Floriane Riga
CONDITIONS DE SÉLECTION
CONDITIONS DE SÉLECTION
- Très souvent, on va vouloir filtrer les lignes d’une table avec un condition where. Se
compose comme suit :
o Mot clé where suivit de 3 éléments :
§ Un opérateur (=)
§ Deux opérants de part et d’autre de l’opérateur
• À gauche, une colonne, la fonction
• À droite, un argument de type texte : « manager ». Attention,
l’argument de type texte doit être délimité par des guillemets. Ça
permet de faire la différence entre un argument de type texte et
le nom d’une colonne ou d’une table
o Le résultat filtre les lignes d’une table
- Notations :
o Égal : =
o Plus grand que : >
o Plus grand ou égal à : >=
o Plus petit que : <
o Plus petit ou égal à : <=
o Différent de : !=
- Opérateur like :
o Il peut être combiné avec deux symboles :
§ % : Chaîne de caractères de longueur quelconque
§ _ : symbolise une position, un caractère quelconque
o Exemple : Fonction like « %eur » à filtre les fonctions qui commencent par
n’importe quoi et qui termine par eur :
63
Floriane Riga
- Is null : permet de retrouver des valeurs dans une colonne

o Exemple : « PRIME is null » colonne avec que les employé dont la prime a une
valeur nulle :
o Existence de prime is not null

- A between X and Y: rechercher des valeurs dans une fourchette de valeurs
o Exemple : Salaire between 4000 and 6000
o Indique le nom des employé dont le salaire se situe dans la fourchette
précédemment indiquée
- A in (X, Y)
o La liste de valeurs qui suit « in » doit être placée entre parenthèses, chaque valeur
étant séparée de la suivante par une virgule
o Exemple : Numdep in (1,3) : les numéros de département doivent soit avoir la
valeur 1 soit la valeur 3
64
Floriane Riga
COMBINAISON DE CONDITIONS DE SÉLECTION

- Un select SQL peut combiner plusieurs conditions de sélection
o Les deux conditions sont combinées par un « or » / « ou » logique
o Le résultat va reprendre les lignes qui satisfont un des deux critères ou les deux
conditions simultanément
- Les conditions de sélection peuvent être combinées

par un « et »/ « and » logique
o Le résultat va reprendre les lignes qui satisfont simultanément aux conditions de
sélection connectées par le « and »
- On peut combiner davantage que 2 conditions de sélection
65
Floriane Riga
o Exemple : 4 conditions de sélection
o NB :
§ On prend en compte l’ordre des opérations
§ On peut utiliser le
• « not » : pour nier la condition de sélection qui suit
• « 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
DONNÉES DÉRIVÉES
- 2 colonnes de la table employés + une colonne virtuelle/dérivée de la table employé

o Résulte du calcul du bonus de 25% du salaire
o Le résultat de cette instruction nous montre une colonne supplémentaire qui a
comme nom « BONUS » car, dans l’instruction, on a utilisé la technique des alias
pour déterminer un nom de colonne lors de l’affichage des résultats
§ Technique consiste à faire suivre une expression ou une colonne existante
du mot clé « as » suivi du libellé de la colonne
§ On peut l’utiliser pour changer le nom « Salaire » en appliquant « Select
SALAIRE as REMUNERATION » par exemple
- Le SQL permet de formuler des expressions qui combine des :
o Colonnes
o Opérateurs
o Fonctions
o Ces expressions permettent de construire àcolonne dérivée, clé de tri, condition
de sélection, etc.
§ Exemples d’utilisation de fonctions :
§ Fonction extract : permet d’extraire une partie d’une date

§ Fonction ifnull : sert à transformer les valeurs null d’une colonne passée en
arguments
66
Floriane Riga
AGRÉGATION 73
- On peut ressortir des données agrégées à partir de tables en combinant le résultat de
plusieurs lignes pour obtenir un résultat agrégé
o Demander via le SQL de calculer la moyenne/somme/max /min/etc. des salaires de
tous les employés via une table employé
- Différentes fonctions d’agrégation :
o Select count(*) as NBR_EMPLOYES from EMPLOYE : a pour effet de compter le
nombre de lignes dans une table
o Select avg (Salaire) as SALAIRE_MOYEN from EMPLOYE : calcul le salaire moyen
(average)
o Select max(SALAIRE) – min(SALAIRE) as ECART_MAX from EMPLOYE : calcul le plus
grand écart de salaires
o à Variation : insérer « distinct » avant l’argument, ce qui permet de compter le

nombre d’occurrences différentes dans une colonne
o Group by : produire des résultats agrégés pour des groupes de lignes qui
correspondent à un critère de sélection
§ Regroupé les employés par valeur identique (numéro de département)

§ Calcul des données agrégées par groupe (total salaire, nombre d’employés)
§ Comment faire ?
73
Réunion d’éléments distincts en un tout homogène
67
Floriane Riga
§ Group by Numdep : effet : produire différents groupes (en num de

départements)
§ Ensuite, agréger pour des valeurs des groupes
HAVING
- La close having :
o Suit la close group by
o Il est possible d’appliquer un filtre ou une condition sur les données agrégées
o On a posé la condition telle que les salaires supérieurs/égaux à 2500 seront les seuls
pris en compte
68
Floriane Riga
WHERE
- Une même instruction SQL peut combiner à la fois un where et un having
o Le where va filtrer les lignes avant le regroupement
o Le having va appliquer une condition de sélection sur les données agrégées après
le regroupement
o Ordre à where, group by, having
69
Floriane Riga
VALEURS NULL
!! Attention !!
- Une expression calculée sur une valeur null renverra toujours une valeur null
o Somme des salaires et des primes : si la prime à une valeur nulle, la somme sera
null
- Attention aussi aux fonctions d’agrégation : si on applique sum/min/max/avg à un
ensemble vide à Null
- Le comptage d’un ensemble vide va renvoyer à 0 et pas null
TP - EXERCICES
select NOM
from employe
where SALAIRE > 6000
70
Floriane Riga
select NOM, FONCTION, SALAIRE, SALAIRE *0.174 as BONUS

from employe
order by FONCTION asc, SALAIRE asc
select NUMDEP, count(*) as NBR_EMPLOYES

from employe
group by NUMDEP
74
Attention, la prof s’est trompée et a calculé 110% au lieu de 10% (*1,1)
71
Floriane Riga
select NUMDEP
from employe
group by NUMDEP
having count(*) >= 5
Variante: pour afficher la colonne NUMDEP ET NBR_EMPLOYE :
select NUMDEP, count(*) as NBR_EMPLOYES
from employe
group by NUMDEP
select NUMDEP
from employe
where salaire > 4000
group by NUMDEP
select NOM, CODEPOSTAL, URL

from client
where CODEPOSTAL like "B%" and url is not null
order by NOM asc
72
Floriane Riga
select *
from client
where (ville in ("Namur", "Bruxelles") and remise > 10)
or (remise = 0 and Numemp = 3298)
order by remise desc, nom
select count(distinct numcom) as Nombre_COMMANDES,

count(distinct numart) as Nombre_ARTICLES,
sum(PRIXVENTE * QUANT) as CA
from lignecom
SUR PLUSIEURS TABLES

- Lorsqu’on veut reprendre des données de 2 tables différentes
o On crée des sous requêtes : par exemple une requête par table et on les assemble
(technique des sous-requêtes)
o On a donc une requête principale qui intègre une sous-requête comme opérante
d’un critère de sélection
o Elles correspondent par clé primaire et clé étrangère
73
Floriane Riga
- Il est possible d’adresser la même table dans la requête principale et dans la sous-requête
o Dans ce cas-ci, on va afficher la liste des employés dans le numéro de département
est celui d’un autre employé
o Le but est d’afficher toutes les personnes ayant le même NUMDEP que Pirlot
- On affiche le nom des employés dont le salaire est supérieur à la moyenne des salaires de
tous les employés de ma table employé
- On veut relier deux tableaux qui sont reliés via deux intermédiaires : on va devoir imbriquer
3 niveaux de sous-requêtes, chaque requête étant reliée au niveau supérieur sur base d’une
égalité clé primaire/clé étrangère
o On prend la table via laquelle on doit afficher la colonne : clients filtrés par des
commandes qui vont être filtrées par des lignes de commandes qui vont être
filtrées par rapport à des lignes de la table article qui correspondent à une condition
de sélection : groupe = vtt
- Jointure interne :
o Le principe de la jointure est de mentionner derrière la clause from non plus 1 table
mais deux tables voir plus
74
Floriane Riga
o Indiquer que l’instruction SQL va attaquer 2 tables jointes (employé et

département)
o Indiquer une clause de jointure « on »
o Ici, la clé primaire de la table employe et la clé étrangère correspondante de la table
département à NUMDEP
§ Pour lever l’ambiguïté de l’appartenance d’une colonne à une table, il faut
préfixer le nom de cette colonne par le nom de la table à laquelle elle
appartient et un point
§ On est dans le cas d’une jointure interne car seul les lignes qui ont des
correspondances dans la table jointe sont affichées
§ Geldorf (directeur) n’avait pas de département donc pas affiché
- Jointure externe : Il est possible d’afficher toutes les lignes d’une table, mêmes celles qui
n’auraient pas de correspondance dans la table jointe
o On rajoute devant le mot clé join deux mots clés « left outer » pour afficher
complètement la table qui est à gauche du mot clé join
o L’emplacement de EMPLOYE et de DEPARTEMENT est arbitraire et peut être
échangé
o Si on souhaite afficher l’entièreté des lignes de la table département (y compris les

départements pour lesquels il n’y aurait aucun employé) on tapera alors « right
outer join »
75
Floriane Riga
- Jointure sur 4 tables

o Si on souhaite afficher des colonnes de la table client et article , il est possible de
construire une instruction SQL qui va joindre les 4 tables
o On va d’abord joindre les tables clients et commandes sur base d’une égalité clé
primaire et étrangère
o Ce bloc va être vu comme un membre de gauche d’une seconde jointure à la table
lignecom (toujours sur base d’une égalité clé primaire-étrangère)
o On reproduit le même mécanisme avec la dernière table (articles) qui va joindre un
bloc constitué de la table client, commande, lignecom jointent, et de la table article
qui est jointe à la table précédente d’une égalité clé primaire-étrangère
o On ne fait que traduire mécaniquement des correspondances clés primaires et clés
étrangères
3.7. BIG DATA
3.8. EXERCICES
76
Floriane Riga
3.8.1. CRÉATION DE BASES DE DONNÉES AVEC MICROSOFT ACCESS
3.8.2. REQUÊTES SQL SUR DES DONNÉES DE GESTION DU PERSONNEL
3.8.3. REQUÊTES SQL SUR DES DONNÉES DE GESTION COMMERCIALE
3.8.4. REQUÊTES SQL SUR DES DONNÉES D’ANNONCES
77
Floriane Riga
4. CHAPITRE 4 : AIDE À LA DÉCISION
4.1. DE LA DÉCISION À LA BUSINESS INTELLIGENCE
4.2. DATA WAREHOUSE
4.3. ANALYSE DESCRIPTIVE AVEC LES TECHNIQUES OLAP
4.4. SCHÉMA DE DATA WAREHOUSE
4.5. VISUALISATION
78
Floriane Riga
4.6. DATA MINING
4.7. EXERCICES
5. MICROSOFT ACCESS
5.1. CRÉATION D’UNE BASE DE DONNÉES
- BD Access = fichiers .accdb contenant :

o tables
o requêtes : interrogations ou de modifications (requêtes actions)
o formulaires : écrans personnalisés
o états : layouts de sorties papier
o macros et modules : outils de programmation
- Une BDD est organisée sous la forme d’une ou plusieurs table(s)
- Pour créer un fichier, cliquer sur BDD vide et insérer un nom .accdb + emplacement
- Pour avoir un visibilité : cliquer sur les deux sections « tous les objets » dans la colonne de
gauche
- Création d’une table :
o Tout d’abord, fermer l’onglet ouvert au milieu puis « Créer » à « Création de
table » ou « Affichage »
- Structure d’une table :
79
Floriane Riga
o Création des champs (colonnes)

o Créations des enregistrements (lignes)
- Les types de données dans une table sur MS Access

o Texte court: type par défaut. Peut contenir jusqu’à 255 caractères. À utiliser pour
les données texte court ou des chiffres qui ne nécessitent pas de calcul (comme le
numéro de téléphone).
o Texte long: Peut contenir jusqu’à 65 535 caractères. Utilise plus de mémoire pour
le stockage. Pour les données texte longs.
o Numérique:(4 octets) Pour stocker des nombres compris entre -2^31 à 2^31-1. Si
on a des chiffres et des lettres, alors le type Texte est conseillé. Ex: +32478259612
(type Texte court est recommandé)
o Grand nombre: (8 octets) stocke une valeur numérique non monétaire entre -2^63
et 2^63-1.
o Date/Heure: Pour les dates.
o Monétaire: Pour les montants dans une monnaie particulière ou un affichage
spécial.
o NuméroAuto: Pour les champs qui s’auto-remplissent eux-mêmes par un numéro
unique. Utile pour les clés primaires. Attention aux clés étrangères qui devront être
en numérique si sa relation de la clé primaire est en numéroAuto. (ex: matricule
étudiant)
o Oui/Non: Pour les champs à 2 valeurs possibles (oui/non, vrai/faux, on/off,
homme/femme).
o Objet OLE*1 : Pour stocker des données externes, comme les images ou documents.
o Lien hypertexte*1: Pour les liens vers l’adresse mail ou page internet
o Pièce jointe*1: objet à lier
o Calculé: si la valeur devra être le résultat d’un calcul sur base d’un enregistrement
spécifique. Ex: calculer l’âge actuel de la personne (date système - date de
naissance)
80
Floriane Riga
o Assistant liste de choix*1...: Pour sélectionner une liste déroulante contenant des
valeurs d’une autre table.
- Insérer le nom + type + (description)
o Eviter les noms trop génériques et les caractères spéciaux
- Sélectionner la clé primaire : clic droit sur l’extrême gauche de la ligne à Symbole d’une
clé
- Enregistrer : Ctrl/Cmd +S ou Fichiers + Enregistrer
o Donner un nom explicite à la table créée
- Insérer des contraintes / Propriétés
o De nullité (valeur obligatoire) : modifier « Null interdit : non » en « Null interdit :
oui »
o Espace = valeur : modifier « chaîne vide autorisée : ouià non »
o Modifier le format de Dates/Heure est possible :
o Règle de validation :
o Rajouter une fonction qui précise « <Date () » à La date de naissance est valide si
elle est inférieure à la date actuelle (la personne ne peut pas être née le jour même
ou le jour suivant).
81
Floriane Riga
o Masque de saisie :
§ Exemple : code postal à limiter à 4

o Assistant liste de choix (bas de la liste) :
§ Sélectionner « je taperai les valeurs souhaitées » + « suivant »
§ Indiquer la largeur de colonnes + laquelle/lesquelles on sélectionne
§ à « Terminer » : on s’arrête là
§ à « Suivant »
• Rajouter le nouveau champ
• Cocher « autoriser plusieurs valeurs » ou non
• « Terminer »
§ Conclusion : au nouveau a été rajoutée (dans ce cas-ci : « Salaire »)
• Exemple : pour rajouter le genre
o Liste de choix
o Je taperai les valeurs
o Définir les valeurs : « homme » et « femme »
o Limiter à la liste (propre à cette liste-là)
o Ne pas cocher « autoriser plusieurs valeurs » car on ne
peut pas être un homme et une femme
82
Floriane Riga
- Pour créer une relation entre deux tables :

o Cliquer sur « outils de base de données »
o Dans le ruban, cliquer sur le bouton « relations »
o Sélectionner les deux tables, dans la boite de dialogue, à l’aide de la touche contrôle
+ Ajouter + Fermer
o Glisser la clé primaire du premier tableau dans le champ relatif du deuxième
tableau
o Sélectionner les trois cases :
§ Intégrité référentielle (éviter de saisir une commande pour un client qui
n’existe pas)
§ MAJ + effacer en cascade : lorsque nous opérons une modification sur une
donnée d’un client, toutes ses commandes liées seront automatiquement
modifiées/supprimées par rapport à ce client
§ Signification du symbole ci-dessous :
• Un client peut effectuer une infinité de commandes mais une
commande peut être liée qu’à un seul et unique client
- Insérer des enregistrements :

o Affichage à Mode feuille de données
o Double clique gauche sur la table employé (colonne de présentation à gauche)
o On commence par le champ « Nom » car le champ « matricule », qui est une clé
primaire servant à identifier est en NumAuto à il se remplit automatiquement
5.2. CRÉATION DE REQUÊTES
- Terme commun en anglais : Query

- Sert à localiser, analyser et modifier des données dans la base de données relationnelle
- Langage commun pour écrire des requêtes : SQL (Structured Query Language »
- Les types de requêtes
83
Floriane Riga
o Les requêtes de sélections

§ Simples : on se base sur une table
§ Tables multiples : on se base sur plusieurs tables
§ Paramétrées : interaction avec l’utilisateur où on lui demande certaines
données
§ Groupage : fonctions de regroupement (regrouper des employés avec
certaines caractéristiques
- Définition des critères de sélection
o Et : « and »
o Ou : « or »
o Égal : =
o Différent : <>
o Inférieur : <
o Supérieur : >
o Inférieur ou égal : <=
o Supérieur ou égal : >=
§ Exemple: on veut afficher le numéro de matricule, nom et salaire des
employés qui gagnent entre 5000 (non compris) et 11000 (non compris)
dans leur salaire en SQL :
• Sélectionner le numéro de l’employé
• Aller dans « créer » + « création de requête »
• Ajouter la table « employé » par exemple
• Cocher toute les tables dans l’affichage
• Sélectionner « exécuter » à droit de « affichage »
84
Floriane Riga
- La requête sous forme de SQL :

o Affichage
o Mode
o Cette fenêtre affiche le code SQL de la requête définie précédemment

- Données dérivées non éditables :
o Pour afficher des données dérivées non éditables, comme une prime calculée
comme valant 120% (=>salaire*(1+0,2)) du salaire
o On ouvre le fenêtre des requêtes existante et on y appose manuellement un
nouveau champ à Prime:[Salaire]*1,2 à ce qui indique que la prime est relative
au salaire dont il faut reprendre les données et les multiplier par 1,2
o Sauvegarder en donnant un nom à votre requête et Exécuter
85
Floriane Riga
o Résultat
- Requête paramétrée :
o Les lister selon un métier/une fonction par exemple :

o Créer à Création de requête à insérer la table à Sélectionner Numéro, Nom,
Fonction.
o Critères : [Entrer une valeur pour la fonction]
o On sauvegarde
o On exécute : ouverture d’un tableau de bord qui nous demande d’entrer une
certaine valeur à on inscrit « directeur » (exemple), on valide et on obtient le
résultat
- Groupage : fonction de regroupement
o S’écrit toujours avec le nom de la fonction, entre une ouverture et fermeture de
parenthèse
o Créer, création de requête, ajouter la table voulue (tableau de droite), sélectionner
les champs voulus
o Sélectionner le bouton « Totaux » représenté par le signe Sigma dans la barre de
modification « créer »
o Ensuite, au niveau des opérations dans le tableau de modification des requêtes (au-
dessus des sélections et des critères), sélectionner l’option désirée (Min, Max,
Somme, Moyenne, Regroupement à par défaut, compte à Compter le nombre
de personnes par exemple, etc. à voir tableau bleu ci-dessous)
86
Floriane Riga
- Requêtes multitables :
o Il est possible de réaliser des requêtes sur plusieurs tables de manière simultanée
o Sélectionner deux tables (dans le tableau de droite)
o Sélectionner les champs désirés

o Sauvegarder + exécuter
o Si on veut modifier la requête en donnant plus de caractéristiques : clique gauche
sur la requête + mode création
§ Nom + Département à = « vente » (toujours entre «» les enregistrements)
§ Tri croissant ou décroissant + exécute + sauvegarde
87
Floriane Riga
5.3. CRÉATION DE FORMULAIRE
- Formulaire : avec une table (employé) :
- Créer un formulaire
o Créer
o Assistant formulaire
§ On peut en créer sur la base de tables ou de requêtes
88
Floriane Riga
o Choix d’affichage :
§ La partie gauche de la fenêtre vous donne une image du type de
présentation.
• L'option Colonne simple: chaque champ apparait sur une ligne
distincte avec, à sa gauche, une étiquette.
• L'option Tabulaire va afficher les champs l’un à côté de l'autre avec
adaptation de l’affichage par MS-ACCESS.
• L'option Feuille de données va afficher les champs de la même
manière que lors de l'entrée des données dans une table.
Remarque: cette option n'est pas pratique si l'utilisateur ne
connaît pas tous les champs.
• Le mode Justifié va afficher les champs l'un à coté de l'autre sauf
que l’option ne réduira pas la taille des champs. Il va afficher les
autres champs en dessous.
o Résultat
89
Floriane Riga
- Formulaire : Maître/détails formulaire

o 2 groupes de données coordonnées
§ Groupe de données maître : département
§ Groupe de données de détail : personnes relatives à ce département
o On peut ajouter, modifier, supprimer des départements/personnes dans un
formulaire maître/détail
o Comment ?
§ Choisir la source du formulaire
§ Choisir le maître et le détail
§ Choisir la manière dont les champs seront affichés
§ Donner un titre aux formulaires
90
Floriane Riga
o Résultat
- Formulaire : Boutons de commande

o Les boutons de commande permettent de facilement accéder à des options qui
affectent les enregistrements, les formulaires, les états, et l’application. Par
exemple: bouton pour ajouter un nouveau enregistrement, pour imprimer le
formulaire, ou pour quitter l’application, ...
o Access offre une série d’options prédéterminées pour faciliter la création de
boutons de commande.
o Pour l’utiliser, appuyez sur le bouton sur la barre d’outils.
91
Floriane Riga
92
Floriane Riga
o Choisir « Employé » et cliquer sur Suivant
o Choisir le type d’affichage du bouton: avec un texte ou une image, puis Suivant
93
Floriane Riga
o Sélectionner ensuite « mode formulaire » en haut à gauche dans la barre d’outil
94
Floriane Riga
5.4. CRÉATION D’ÉTAT
- Un état : est une représentation des enregistrements de la base de données qui est mise
sur papier. On peut trier et regrouper l'information sur des champs pertinents.
- Créer un état : Cliquer dans l’onglet Créer et choisir Assistant État
95
Floriane Riga
- Choisir les champs de l’état
o Département: nom et localisation

o Sélectionnez les champs et l’ordre dans lequel vous voulez qu’ils apparaissent
dans l’état
o Cliquez sur le bouton Suivant
- Sélectionner le lay-out
- Sélectionner la table que l’on veut + suivant
- Regroupement
o En option, si vous voulez regrouper les enregistrements sur un champ en
particulier, vous pouvez aussi faire des regroupements à l'intérieur de
96
Floriane Riga
regroupements.
o Si vous ne voulez pas regrouper en niveau, alors vous pouvez laisser tel quel.
- Tri sur les enregistrements

o Trier selon un ou plusieurs ordres de manière croissante ou déécroissante
o Sélectionner le nom de employé + Suivant
97
Floriane Riga
o Choisir la manière d’affichage de l’état
o Choisir le titre de l’état

o Résultat
- On peut le personnaliser en lui rajoutant des couleurs, boutons, etc.

o Aller dans création (version 2016) ou création + outils (2019)
o Clic droit sur l’entête de page pour changer de couleur (police, arrière-plan, etc.)
o Résultat : clic sur affichage + mode état
98
Floriane Riga
5.5. QUESTIONS D’EXAMEN
99
Floriane Riga
100
Floriane Riga
Opération de regroupement puis sélectionner
- Somme pour salaire

- Compte pour numemp
- Regroupement pour fonction
101
Floriane Riga
- Réponse D : Il peut y avoir une infinité de matricules (d’employés) pour un seul

département OU un seul département peut contenir une infinité de matricules. (regarder
en fonction des clés primaires).
o Pour être enregistré dans le système, un département doit contenir au moins 1
employé.
102

Base de Données

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Base de Données

Transféré par

Droits d'auteur :

Formats disponibles

Floriane Riga

COMMENT DEVENIR ACTEUR DU DEVELOPPEMENT DIGITAL ?

à O1 Savoir interagir avec les informaticiens

à Le gestionnaire doit connaître la démarche de développement Chap 1 :

à O2 : Maitriser les technologies des bases de données

à Le gestionnaire doit pouvoir stocker et exploiter les données structurées de Chap 3 :

TABLE DES MATIERES

3. Chapitre 3 : Bases de données ............................................................................................... 46

1. CHAPITRE 1 : LA GESTION DE PROJET INFORMATIQUE

1.1. NOTION DE PROJET INFORMATIQUE

o Processus : pour mener à bien un projet. Organiser le

1.2. PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL

- Définition 5 : Ingénierie logicielle : est l’application d’une

- Les phases génériques6 :

- Les activités techniques

1.3. EXEMPLES DE PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL

1.3.1. PROCESSUS EN CASCADE

1.3.2. UNIFIED PROCESS (UP)

Les phases sont organisées en Itérations (découpé en sous-systèmes).

o Utilisateur = Key user : représente la communauté de l’ensemble des utilisateurs. C’est

- Enjeu pour le gestionnaire :

1.6. QUESTIONS D’EXAMEN

2. CHAPITRE 2 : REPRÉSENTATION DES EXIGENCES

2.1. MODÉLISATIONS DE SYSTÈMES INFORMATIQUES

2.1.2. FORMES DES EXIGENCES

Exemple de langage Exemple de formulation

2.1.3. UN BON LANGAGE ?

Exemple de langage Expressivité Accessibilité Formalisme

2.1.4. DIMENSIONS DE LA MODELISATION

2.2. DIAGRAMME DE CAS D’UTILISATION

Quelles sont les utilisations d’un système ?

- Définition 7 : Diagramme de cas d’utilisation : recense et décrit les scénarii d’utilisation du

2.2.1. CAS D’UTILISATION ET ACTEUR

Rechercher Passer une Déposer une

2.2.2. HIERARCHIE D’ACTEURS

o Barre = connexion qui relie un acteur à un cas d’utilisation

o Cas particulier de l’internaute : le modérateur. C’est un acteur qui spécialise

2.2.3. STRUCTURATION DES CAS D’UTILISATION

§ La cas appelant va s’interrompre à un certain moment de son exécution pour

2.2.4. SPÉCIFICATION DES CAS D’UTILISATION

- Ensuite, on peut préciser un scénario d’utilisation/scénarii où on va stimuler un jeu de stimuli et

2.2.5. DÉMARCHE DE CONSTRUCTION

à Cf. exemple PetShop Top

o Le délégué commercial : est un acteur secondaire qui utilise accessoirement le système

Cas d utilisation principaux

2.2.6. ERREURS FRÉQUENTES

- Exigence 5 32 : Tout comme le locataire, le propriétaire doit s’enregistrer sur la plateforme, et

2.2.8. QUESTIONS EXAMEN

2.3. DIAGRAMME D’ACTIVITÉ

- Définition 10 : Un diagramme d’activité : Décompose une fonction attendue d’un système

2.3.1. ACTION ET FLUX DE CONTRÔLE

Rechercher un Passer un Préparer une

§ Une action est représentée par un rectangle aux coins arrondis

o NB : Lancement de flux parallèles + récupération de ces mêmes flux est assez

o À la suite de l’action « ajouter un article », on boucle sur cette même action

2.3.4. FLUX D’OBJET, INTERRUPTION ET ZONE D’EXPANSION

o Le flux d’objets est représenté par un rectangle.

2.3.4.2. ZONE INTERRUPTIBLE ET INTERRUPTION

2.3.5. ERREURS FRÉQUENTES

- Exigence 2 : Au sein d’une rubrique, l’internaute sélectionne un ou plusieurs articles à

o Dans un second temps : rajouter l’option « pas identifié » :

2.3.7. QUESTIONS D’EXAMEN

2.4. DIAGRAMME ENTITÉ/ASSOCIATION