Bases de donnée

Hicham BEHJA
 Plan

I. Définition d’un système d’information

II. Méthodologies et méthode de conception
III. Modèle relationnel
IV. Langage SQL
V. Langage PL/SQL
VI. TP sous Oracle
2
 Système d'Information (SI)
Toute organisation peut être considérée comme un
système traitant des flux physiques et des flux
d'informations
Un SI peut être considéré comme un ensemble de
flux d'informations, d'opérations qu'ils subissent et
de moyens mis en œuvre pour ce faire quelle que
soit la nature de ces moyens.
L'entreprise est un système ouvert sur son
environnement avec lequel il échange des flux de
produits, de personnels et d'argent impliquant tous
corrélativement des flux d'informations
3
 Système d'Information
Chacune des trois grandes catégories de flux :
produits, personnel et argent est traitée à l'intérieur du
« système entreprise » par des sous-systèmes assurant
des fonctions spécifiques.
On distingue
– les systèmes logistiques et de production
– les systèmes de marketing
– les systèmes comptable et financier
– les systèmes de contrôle et de planification stratégique
– ...
Pour chacun de ses sous-systèmes on peut mettre en
évidence les principaux SI qu'ils impliquent
4
Définir «Système d'Information»
Définir un SI : « une entreprise délicate »
– SI = Véhicule de communication de l'organisation dont il
assure l'information interne et externe. Le langage de
cette communication est constitué par les données.

– SI = Ensemble des moyens humains, matériels et

méthodes se rapportant au traitement des différentes
formes d'information rencontrées dans les organisations

– Un SI peut être constitué de procédures manuelles ou

automatisées
5
 Définition d'un système
Un système est un ensemble d'éléments :

– dotés d'une structure,

– en interaction entre eux et avec l'environnement,
– qui réalise des fonctions,
– qui transforme la matière,
– de l'énergie ou de l'information,
– qui évolue dans le temps,
– selon un objectif.

6
 SYSTEME DE PILOTAGE
Coordination, objectifs
(membres de la direction, …)

Décisions Décisions

l ’extérieur
Informations vers
Informations traitées
SYSTEME D ’INFORMATION
- Collecte
- Mémorisation
des données
- Traitement
- Transmission

FLUX Informations collectées FLUX

ENTRANT SYSTEME OPERANT SORTANT
Production, action
(ensemble du personnel exécutant)
7
Rôle d'un Système d'Information
Collecter des informations provenant :
- d ’autres éléments du système
- de l’environnement
Mémoriser des données :
-base de données
-Fichiers
-Historique, Archivage
Traiter les données stockées :
-traitements automatisables
-aide à la prise de décision
Communiquer
8
Le Cycle de Vie d'un Logiciel

1. Définition du cycle de vie

2. Étapes de la vie d’un
logiciel
3. Cycle de la cascade
4. Cycle en V
5. Cycle en Y
6. Cycle en spirale
7. Cycle par incréments

9
 Développement logiciel : un
processus complexe

Le développement de logiciel n'est pas simplement

l'écriture de programmes sur une durée variant de
quelques heures à quelques jours :

– c'est un processus beaucoup plus complexe auquel

on applique le : «diviser pour régner», qui permet
de le maîtriser en le divisant en sous-tâches
10
 Etapes de la vie d'un logiciel
La structure des logiciels suit une progression
logique
– Etude du problème (analyse conceptuelle)
– Etude d'une solution (analyse logique)
– Etude technique détaillée (design et analyse physique)
– Codage
– Tests
– Utilisation (Mise en exploitation)
– Maintenance et Evolution
Cet ensemble d'éléments se traduit par le cycle de
vie d'un logiciel 11
 Cycle de vie : définitions
Le cycle de vie d'un logiciel est la période située entre le
début de la conception et l'arrêt de l'exploitation de ce
logiciel.
« Le cycle de vie regroupe un ensemble d'activités suivant
les normes AFNOR Z 67 150. Il est envisagé à un instant
donné et va comprendre les progrès technologiques et les
contraintes organisationnelles » (A. Carlier, 1994)
Le cycle de vie d'un logiciel « correspond à l'identification
des états successifs d'une application ou d'un produit
déterminé. Il est essentiellement dynamique, évolutif et
presque toujours progressif » (A. Carlier, 1994)
12
Les différentes phases du cycle
de vie d’un développement
logiciel
Expression des besoins
Description informelle des besoins exprimés par
l’utilisateur
– Fonctionnels
Fonctionnalités attendues du système
– Techniques (pouvant déboucher sur du prototypage)
moyen d’accès (local, distant, Internet...)
temps de réponse acceptable
quantité d’informations à stocker

Produit un cahier des charges

13
 Les différentes phases du cycle de
vie d’un développement logiciel

Analyse
Description formelle du problème (Quoi)
Phase essentielle dans le cycle de vie du logiciel,
souvent négligée (à tort !) car les conséquences
d’une analyse bâclée sont toujours très coûteuses

Nécessite de bonnes connaissances métier

Exploitation de la capture des besoins nécessitant
l’implication des utilisateurs et de la maîtrise
d’ouvrage
14
 Analyse des besoins
Le but de cette activité est d'éviter de développer
un logiciel non adéquat.
Entrée: données fournies par des experts du
domaine d'application et les futurs utilisateurs
Méthodes: entretiens, questionnaires, observations
de l'existant, études de situations similaires
(sciences cognitives)
Résultat: documents décrivant

15
 Analyse des besoins
l'environnement du futur système
son rôle
son utilisation (manuel d'utilisation préliminaire)
si nécessaire, partage entre matériel et logiciel
Essentiellement au début du processus de
développement.
Faite en coordination avec les études de faisabilité
et la planification.
Peut se poursuivre durant tout le cycle de vie
(maintenance évolutive).
16
 Les différentes phases du cycle de
vie d’un développement logiciel

Conception
Recherche de solutions tenant compte de
l’Architecture technique (Comment)

2 phases
– Conception Préliminaire (ou générale)
Fusion de l’analyse des besoins fonctionnels et techniques
Définition de l’Architecture technique générale
– Conception Détaillée
Raffinage des modèles d’Analyse
Préparation au codage dans le langage cible
17
 Spécification globale
La spécification globale a pour but d'établir une
description du futur système.
Entrée: analyse des besoins + considérations techniques et
faisabilité informatique
Méthodes: SADT, SART, MERISE, ...
Résultat: modèle conceptuel
ce que doit faire le futur système; QUOI et non comment
complément au manuel d'utilisation
manuel de référence préliminaire
Souvent regroupée dans la même étape que la
spécification des besoins. Cette activité ne fait pas
apparaître de choix d'implémentation.
18
 Conception architecturale,
détaillée
Le but de la conception architecturale détaillée est
d'établir une description très proche du système à
réaliser.
Entrée: les spécifications globales + contraintes
d'implémentation
Méthodes: enrichir la description du système de détails
d'implémentation. Deux étapes:
1. conception architecturale
décomposer le logiciel en composants plus simples en
terme de fonctions et interface architecture du logiciel
et spécification des composants
19
 Conception architecturale,
détaillée
2. conception détaillée
description de chaque composant: algorithmes,
structure des données, ...
Résultat: modèle d'implémentation:
• architecture du système
• spécification des composants
• algorithmes
• modèle des données (entité-association)
• selon la nature de la conception:
Fonctionnelle: modèles par flux de données: DFD, Contexte,
AFD, structure, Petri, ...
Objets: diagrammes UML
• ...
Peut remettre en cause les spécifications globales. 20
 Les différentes phases du cycle de
vie d’un développement logiciel
Développement
Production du code associé
– les diagrammes élaborés doivent être suffisamment
complets pour que le développeur ne se pose pas de
question ayant trait à l’analyse ou à la conception
– éventuellement, utilisation d’un générateur de code
« intelligent »
attention : l’opportunité d’un générateur de code devra être
étudiée au début de la phase de Conception

Tests unitaires
– Tests « boîte blanche » des unités élémentaires de code
21
 Programmation
Cette activité consiste à passer du résultat de la conception
détaillée à un ensemble de programmes ou de composants logiciel.
Elle est la mieux outillée et maîtrisée. Dans certain cas elle peut
être totalement automatisée.
Entrée: conception détaillée + contraintes de l'environnement de
programmation
Méthodes: Dans certains cas, cette étape peut être automatisée
(génération automatique de code)
Résultat: documents décrivant:
code source
directives: compilation, liens, ...
documentation d'implémentation

22
 Les différentes phases du cycle de
vie d’un développement logiciel

Intégration
Assemblage des différents composants constituant
le système
– Vérification du respect des interfaces inter-composant
– Vérification de type « boîte blanche »

Validation
Recette du système par le client
– Vérification du respect des interfaces inter-composant
– Vérification de type « boîte noire »
23
 Validation et vérification

Le but de cette activité est de s'assurer de

l'adéquation du système produit face aux besoins
et spécifications:
- validation: spécifions-nous le bon système c'est
à dire un système correspondant aux attentes des
utilisateurs et respectant les contraintes de leur
environnement?
- vérification: le système réalisé correspond-il aux
spécifications?

24
 Validation et vérification
Entrée: documents produits par l'ensemble des
étapes précédentes
Méthodes:
- validation: revues et inspections des
spécifications, manuels, prototypes
- vérification: examens des spécifications,
programmes, preuves, tests

25
 Les différentes phases du cycle de
vie d’un développement logiciel

Exploitation
Déploiement du système
Mise en production

Maintenance
Correction des anomalies
Prise en compte des demandes d’évolutions

26
 Activités de développement
Les activités relevant du génie logiciel sont maintenant
bien définies. Nous trouvons:
– l'analyse des besoins;
– la spécification globale;
– la conception architecturale et détaillée
– Développement
– Intégration
– Validation
– Exploitation et maintenance
La spécification et la conception représentent environ
40% de l'effort dans un projet bien conduit;
la programmation représentant 15 à 20% de l'effort de
développement d'un logiciel, voire 10% selon certains
chiffres; 27
Activités de développement

la validation et vérification représentent de

l'ordre de 40% de l'effort total d'un projet;
Chaque activité utilise et produit des
documents. L'importance des activités varie
en fonction:
• du processus de développement choisi;
• de la nature du logiciel à produire.

28
Le cycle de vie en cascade
Le modèle de la cascade prévoit un certain nombre
d'étapes ou phases durant lesquelles les activités
vont se déroulées
Une étape doit se terminer à une date donnée par
la production de certains documents ou logiciels.
Les résultats de l'étape sont soumis à une revue
approfondie.
L'étape suivante n'est abordée que s'il sont jugés
satisfaisants.

29
 Le cycle de vie en cascade
Etude de faisabilité
+
Analyse des besoins

Cahier des Analyse

charges
+ Gestion
Conception de projet
+

Spécifications Réalisation Gestion

+ + du changement
Dossiers de Conception Vérification
(Générale et détaillée)
+
Gestion
de l’environnement
Code Intégration
+ +
Tests unitaires Validation

Exploitation
Produit
+
+
Doc utilisateur Maintenance

30
 Le cycle de vie en cascade
Avantages :
Définition des tâches à accomplir
Détermination des livrables à fournir
Séparation des problématiques (métier / technique)

Inconvénients :
Obligation de définir la totalité des besoins au départ
Validation fonctionnelle tardive
Code disponible tardivement dans le projet
Projets rarement séquentiels
Aucune préparation des phases de vérification

31
Le cycle de vie en cascade
Les versions actuelles de ce modèle font apparaître
la validation vérification à chaque étape.
faisabilité et analyse des besoins + validation
conception du produit, conception détaillée +
vérification
codage + test unitaire
intégration + test d'intégration + test d'acceptation
installation + test du système
Il existe de nombreux documents, normes ou
recommandations décrivant très précisément le
modèle de la cascade: IEEE, AFNOR
32
 Le cycle de vie en V
On retrouve les caractéristiques du cycle en cascade
– Phases successives
– Une activité principale et des livrables par phase
– Des activités transverses
– Remise en cause de la phase précédente

Chaque phase en amont de la production du logiciel

prépare la phase correspondante de vérification en
aval de la production du logiciel

33
 Le cycle de vie en V
Le principe de ce modèle en V, est qu'avec toute
décomposition doit être décrite la recomposition et
que toute description d'un composant est
accompagnée de ses tests (correspondance avec sa
spécification) permettant sa vérification et validation.

Le modèle en V rend explicite le fait que les

premières étapes préparent les dernières faisant
intervenir, essentiellement, vérification et validation.

34
 Le cycle de vie en V
Ce principe évite un écueil bien connu de la
spécification de logiciel: on énonce une propriété
qu'il est impossible de vérifier objectivement, une fois
le logiciel réalisé. De plus, l'obligation de concevoir
les jeux de test et leurs résultats oblige à une réflexion
et ainsi à des retours sur les descriptions en cours.
Ainsi les étapes de la branche droite du V peuvent
être mieux préparées et planifiées.
Les dépendances entre étapes sont de types:
– enchaînement et itération éventuelle du modèle de la
cascade en suivant le V (haut-bas, gauche-droite);
– une partie des résultats de l'étape de départ sont directement
utilisés par celle d'arrivée.

35
 Le cycle de vie en V
Etude de faisabilité Exploitation
+ +
Analyse des besoins Maintenance

Cahier de recettes

Analyse Validation
Cahier des
charges
Dossier
d’intégration

Conception Intégration
Spécifi-
cations

Réalisation
Dossiers de Code
Conception +
(Générale et détaillée) Tests
unitaires

Gestion de projet + Gestion du changement + Gestion de l’environnement

36
 Le cycle de vie en V
Avantages :
Préparation des phases de vérification au moment
de l’Analyse et de la Conception

Inconvénients :
Obligation de définir la totalité des besoins au
départ
Validation fonctionnelle tardive
Code disponible tardivement dans le projet
Projets rarement séquentiels

37
 Le cycle de vie en Y
Cette démarche itérative (à tout point de vue) distingue
l’étude des aspects globaux du SI de l’entreprise de ceux
spécifiques à chaque application.
La démarche préconise deux activités d’ingénierie
transverses :
– l’analyse métier qui correspond à l’étude fonctionnelle
– l’architecture technique, qui correspond à l’étude technique.
Ces deux activités enrichissent respectivement un
référentiel des processus métier de l’entreprise tenant
compte de l’urbanisme du SI et un référentiel de solutions
techniques.

38
 Le cycle de vie en Y
Cahier des charges Cahier des charges

Analyse métier Conception

Spécifi- Dossiers
cations de
Gestion Simulation Prototypage Conception
de projet des
+ spécifications
Mécanismes +
Gestion Design Patterns
du changement Codage
+
Gestion
de l’environ- Code +Tests unitaires
nement Sources +
Objets Exploitation
+ Librairies
Maintenance

Réutilisation
Composants métier

39
 Le cycle de vie en Y

Avantages :
Utilisation immédiate de toutes les compétences
Meilleure traçabilité sur l’ensemble du développement
(réutilisation des modèles d’Analyse + règles de passage)
Validation précoce des besoins
Possibilité de générer le code automatiquement
Industrialisation de la réutilisation

Inconvénients :
Obligation de définir la totalité des besoins au départ

40
 Le cycle de vie en spirale
Inventé par Boehm (Cocomo) en 1988
Le projet est découpé en N phases successives suivies
d’une dernière phase où le logiciel est intégralement
développé
Chaque phase a pour objectif la validation d’un point
technique ou fonctionnel particulier pouvant donner lieu
au développement d’une maquette
Chaque phase peut donner lieu à l’utilisation d’un cycle
en V ou en Y
Chaque phase permet d’affiner les besoins de
l’utilisateur
A chaque phase est associée une analyse de risques
pouvant remettre en cause le développement
41
 Le cycle de vie en spirale
Chaque cycle est décomposé en 4 étapes:
1. détermination des objectifs, des alternatives, des contraintes
à partir des résultats du cycle précédent et pour le premier à
partir d'une analyse préliminaire des besoins;
2. analyse des risques, évaluation des alternatives,
éventuellement prototypage;
3. développement et vérification de la solution retenue (modèle
de la cascade ou en V);
4. revue des résultats et planification du cycle suivant.

42
 Le cycle de vie en spirale
Tests

Développement Déploiement

Conception Définition des besoins

Analyse

43
 Le cycle de vie en spirale
Avantages :
Mise en œuvre d’une analyse de risques
Les besoins sont affinés au fur et à mesure
Validation fonctionnelle et technique précoces
Il est plus particulièrement adapté aux projets innovants, à risques et dont
les enjeux sont importants.
Un des intérêts du modèle en spirale est de fournir la liste des risques
majeurs encourus dans le cadre du développement d'un système
informatique.

Inconvénients :
Le cycle N ne s ’appuie pas obligatoirement sur le cycle N-1
Chaque cycle produit un composant du système intégré en phase finale
Les maquettes développées à chaque cycle ne sont pas obligatoirement
réutilisables
Risque de « spiralisation » des besoins
Nécessite une plus grande participation de la part des utilisateurs
44
 Le cycle de vie itératif et
incrémental
Le projet est découpé en N itérations successives

Chaque itération étend un noyau logiciel antérieurement

développé lors des itérations précédentes

Chaque phase peut donner lieu à l’utilisation d’un cycle en

V ou en Y

Chaque itération permet d’affiner les besoins de

l’utilisateur
45
 Le développement
incrémental
Rendre les objets de plus en plus précis
– accepter une définition floue au départ
– affiner par étapes successives

Les impacts d’un incrément doivent être maîtrisés :

– nécessité d’une gestion de configuration
– nécessité d’une gestion des changements
46
 Le processus itératif

temps passé

Itération 1 Itération 2 Itération 3 Itération 4 Prototype

fonctionnel

Capture des besoins Analyse Conception Codage

temps passé
Prototype
Itération 2 Itération 3 Itération 1 Itération 4 technique

Capture des besoins Analyse Conception Codage

47
 Modèle par incréments
Dans les modèles spirale, en V ou en cascade, il
implicite que qu'après une décomposition en
composants, ceux-ci sont développés
indépendamment les uns des autres, en parallèle
ou séquence selon les ressources disponibles.
Dans le modèle par incréments, seul un sous
ensemble est développé à la fois. Dans un premier
temps un logiciel noyau est développé, puis
successivement, les incréments sont développés et
intégrés.

48
 Modèle par incréments
Les avantages d'une telle pratique sont nombreux:
• chaque développement est moins complexe;
• les intégrations sont progressives;
• il peut y avoir des livraisons et mises en oeuvre après
chaque incrément;
• l'effort est constant dans le temps par opposition au pic
pour spécifications détaillées pour les modèles en cascade
ou en V.
Les inconvénients sont:
• la remise en cause du noyau de départ;
• celle des incréments précédents;
• ou encore l'impossibilité d'intégrer un nouvel incrément.
49
Modèle par incréments

Figure 4: Modèle par incréments

50
 Modèle par incréments
Afin de réduire ces risques, il est nécessaire
de définir les incréments au début du projet
et ce de façon globale. D'autre part, les
incréments devront être le plus indépendant
possible, aussi bien fonctionnellement qu'au
niveau de la séquence de développement.

51
 Problèmes
Imaginer des solutions méthodologiques qui
permettent

– de développer et de faire évoluer un logiciel suivant les

besoins réels des utilisateurs
– d'impliquer davantage les utilisateurs et les responsables à
tous les niveaux de management dans le processus de
décision et de développement des logiciels
– de réduire le fardeau de la maintenance et le coût de
développement

Définir des méthodologie pour le

développement du logiciel
52
 METHODOLOGIES
Ensemble des méthodes et des techniques
d'un domaine particulier

Manière de faire, procédé, méthode

Ensemble structuré et cohérent de

méthodes, guides et outils permettant de
déduire la manière de résoudre un problème

53
 Méthode (1)
« Processus discipliné qui génère un ensemble de modèles
décrivant les différents aspects d'un système logiciel, en
utilisant une certaine notation bien définie » (Booch, 94)
Ensemble de règles bien définies qui conduisent pour un
problème à une solution correcte
Une méthode a pour objet
– de décrire l'ensemble des tâches à accomplir,
– l'ordonnancement de ces tâches,
– les documents et les standards qui leur sont associées,
– afin de prendre en charge des aspects spécifiques ou une partie du
processus de développement

54
 Méthode (2)
Une méthode :
– définit la documentation à fournir à l'issue de chaque phase de
développement
– spécifie en détail les activités permettant d'atteindre un objectif
donné
– Les méthodes de développement utilisées sont nombreuses et
variées
– Elles peuvent recouvrir tout ou partie du cycle de vie et sont axées
sur une ou plusieurs approches de développement du SI
Les quatre composantes d'une méthode :
– Modèles
– Langages
– Démarche
– Outils

55
Méthode = Démarche + Formalisme

Démarche : succession d’étapes pour

– Mieux maîtriser le déroulement d’un projet
– Meilleure visibilité pour les utilisateurs sur certains résultats
intermédiaires et garantir que le résultat final sera celui attendu
Formalisme défini par:
– Un langage formel
– Un langage semi-formel généralement graphique
– Un langage naturel
Fonction :
– Représenter le monde réel tel qu’il est perçu par le concepteur
– Outil de communication entre informaticiens et utilisateurs
Constitué par un ensemble de modèles permettant d’assurer
une bonne compréhension des besoins des utilisateurs

56
 Merise
Merise : Méthode d’Études et de Réalisation Informatique
des Systèmes Évolués (1979)
80% du marché français
Trois phases: analyse (diagnostic), conceptualisation
(modélisation) et développement (Bases de données)
Modèles:
– MCC: Modèle Conceptuel de Communication
– MCD: Modèle Conceptuel de Données
– MCT: Modèle Conceptuel de Traitements
– MOT: Modèle Organisationnel de Traitements
– MLD: Modèle Logique de données
– MPD: Modèle Physique de données

57
L'expression des besoins est une étape consistant à
définir ce que l'on attend du système d'information
automatisé, il faut pour cela:
•faire l'inventaire des éléments nécessaires au
système d'information
•délimiter le système en s'informant auprès des
futurs utilisateurs
Cela va permettre de créer le MCC (Modèle
conceptuel de la communication) qui définit les flux
d'informations à prendre compte L'étape suivante
consiste à mettre au point le MCD (Modèle
conceptuel des données) et le MCT (Modèle
conceptuel des traitements) décrivant les règles et
les contraintes à prendre en compte
Le modèle organisationnel consiste à définir le
MOT (Modèle organisationnel des traitements)
décrivant les contraintes dûs à l'environnement
(organisationnel, spatial et temporel)
Le modèle logique représente un choix logiciel
pour le système d'information
Le modèle physique reflète un choix matériel pour
le système d'information

58
 Niveau conceptuel
On ne se préoccupe ni de l ’organisation ni du matériel utilisé

Il s ’agit de répondre à la question QUOI ?

Quoi faire ?
Avec quelles données
Les modèles sont
Modèle conceptuel des données
Modèle conceptuel des traitements

59
 Niveau organisationnel
On intègre les critères d ’organisation de travail
On tient compte et/ou on propose des choix d ’organisation de travail

Il s ’agit de répondre aux questions Qui? Où?

Quand?
Le modèle est :
– Modèle Organisationnel des Traitements

60
 Niveau physique
On étudie les solutions techniques

Il s ’agit de répondre à la question

comment ?
Les modèles étudiés sont :
le modèle logique des données
le modèle physique des données

61
 La démarche
Quatre étapes

Etude préalable
Etude détaillée
Réalisation
Mise en œuvre

62
 Etude préalable
Recueil des données grâce à des entretiens
cerner le projet
comprendre les besoins
identifier des concepts ( règles de gestion, règles
d ’organisation …)
proposer une première solution
proposer une évaluation quantitative et qualitative
Diagramme de flux
Dossier d ’étude préalable

63
 Etude détaillée
Décrire complètement, au plan fonctionnel
la solution à réaliser
Débouche sur un dossier de spécifications
détaillées

64
 Réalisation

Production du code informatique

Débouche sur un dossier de réalisation

65
 Le MCC
Souvent connu sous le nom de graphe des flux, c'est un outil
très simple qui permet de représenter tous les flux
d'information qu'échange le SI avec son environnement
Ce modèle ne manipule que deux concepts : l'acteur et le flux
L'acteur est soit interne au SI soit externe. On peut faire
autant de MCC que de domaines étudiés quitte ensuite à les
fusionner pour avoir une vision plus synoptique.
Le flux est soit entrant, soit sortant, d'où la flèche pour le
symboliser. Il est porteur de messages, d'informations que l'on
peut analyser. A ce stade conceptuel nous ne cherchons pas à
savoir quel est le support utilisé (voie, téléphone, courrier,
fax, EDI etc.).
66
 Exemple
Les clients font leurs demandes de livraison au
magasin.
Le magasin donne l ’ordre au transporteur d ’effectuer
la livraison.
Lorsque celle-ci est faite, le magasin en est averti par un
bon de livraison.
Il envoie alors l ’ordre de facturer au service facturation.
Celui-ci émet une facture pour le client et un double est
envoyé à la caisse.
La caisse reçoit les chèques des clients et les dépose à la
banque.
67
Recherche des acteurs et des
flux
Acteurs externes :
client,
transporteur,
caisse
banque

Acteurs internes :
facturation,
magasin

flux :
demande de livraison, ordre de livraison, bon de livraison,
ordre de facturation, facture,
chèque,
chèque à encaissement
68
 Règles de gestion
Associées au niveau conceptuel, elles
répondent à la question « QUOI ? ».
Elles décrivent les actions qui doivent être
effectuées et les règles associées à chacune
de ses actions.
Les règles de gestion représenteront les
objectifs choisis par l’entreprise et les
contraintes associées.
69
Exemple : règles de gestion

Un inventaire des stocks doit être dressé

chaque mois.
Une commande non livrable sera mise en
attente.

70
 Règles d ’organisation
Elles sont associées au niveau
organisationnel et décrivent le où, qui et
quand.
Elles traduisent l’organisation mise en place
au sein de l’entreprise afin d’atteindre les
objectifs.

71
 Exemple : Règles
d ’organisation
c ’est la secrétaire qui édite les factures
chaque fin de semaine.

72
 Le MCD
Schéma qui obéit à quelques conventions
graphique très simples et à quelques règles
de construction, peu nombreuses mais très
précises qui font la puissance et la
pertinence de cet outil
Il manipule essentiellement deux concepts :
les ENTITES et les ASSOCIATIONS.

73
 Le modèle Conceptuel des
données
Représentation graphique des données et des liens qui
existent entre chacune d ’elle.
Les concepts de base :
Entités
Propriétés
Relations
Cardinalités
Identifiants
74
Le modèle Conceptuel des données
Entité
Définition
–pourvue d ’une existence propre
–conforme aux choix de gestion de l ’entreprise

Elle peut être :

–un acteur : client, fournisseur
–un flux : livraison, commande

75
 Assuré
num
nom
Les entités
Prenom
adresse
age

Elles représentent soit une personne physique, soit une

personne morale soit une chose, soit des événements
Une entité forme un tout qui regroupe des occurrences
de même nature. Toutes les occurrences d'une entité
sont décrites par un ensemble de propriétés dont les
valeurs changent d'une occurrence à l'autre. Elle est
représentée tout simplement par un rectangle muni
d'une cartouche qui indique son nom et elle contient la
liste de toutes ses propriétés.

76
Le modèle Conceptuel des données
Propriétés
Définition :
Donnée élémentaire qui qualifie l ’entité à laquelle elle se rapporte
Caractéristiques :
– occurrence : valeur que peut prendre la propriété
– domaine de définition : ensemble des valeurs possibles
de la propriété

Une propriété peut être composée c'est à dire qu'elle renferme d'autres
propriétés plus élémentaires (identité, adresse complète, contact). Toutes
les propriétés ont un nom, et un même nom ne doit pas faire référence à
deux propriétés distinctes.

77
Le modèle Conceptuel des données
Identifiant
Définition :
Propriété ( ou ensemble de propriétés ) particulière qui
permet d ’identifier de façon unique une occurrence de
l ’entité.
Pour être identifiant, la ou le groupe de propriétés ne peut
pas prendre plusieurs fois la même valeur sur l ’ensemble
des occurrences possibles de l ’entité.
Identifiant d ’une relation : Concaténation
des identifiants des entités participant à la relation.

78
Le modèle Conceptuel des données
Identifiant

Parmi les propriétés une (ou une combinaison de 2 ou 3) joue un rôle

particulier car elle permet d'identifier à coup sur une occurrence :
c'est l'identifiant. Le plus souvent c'est un numéro, un code, une
référence etc.
Soit il existe déjà dans la réalité du SI et s'impose car il est exogène,
soit plus fréquemment il est le fruit d'une codification interne au
système qui obéit à un plan de codification plus ou moins élaboré (le
N° de prof, d'étudiant dans la promo, le code type de stage etc.).
Toute entité doit avoir un identifiant, en principe celui-ci est stable,
c'est à dire que sa valeur pour une occurrence donnée ne change pas.
Par construction il apparaît en tête des propriétés et il est souligné.

79
Le modèle Conceptuel des données
Associations
Définition :
Lien sémantique reliant un ensemble d ’entités et
présentant un intérêt pour l ’entreprise
Association porteuse :
Relation qui porte des propriétés.
Dimension d ’une association :
Association binaire :lien entre deux entités
Association ternaire : lien entre trois entités
Association n-aire : lien entre n entités
Association réflexive : lien de l ’entité sur elle-même

80
 Les associations
Ce sont elles qui mettent en relation les entités et donne à
l'ensemble la caractéristique de système. Chaque fois que
possible il est bon de les nommer par un verbe à l'infinitif car il y
a toujours plusieurs sens de lecture.
La plupart des associations sont binaires, c'est à dire qu'elles
relient deux entités. Par exemple Effectuer associe étudiant et
stage : un stage est effectué par un étudiant et ce dernier peut
effectuer plusieurs stages : les deux sens de lecture sont chacun
porteur de sens.
Pour être plus précis encore MERISE introduit les notions de
cardinalités minimales et les cardinalités maximales. Chaque
sens de lecture sera entièrement décrit lorsqu'on aura précisé le
couple (cardinalité mini, cardinalité maxi).
81
num Association

Règles de gestion:
-Un assuré peut posséder 0 ou n véhicules
-Un véhicule peut être assuré par un et un seul assuré

82
Le modèle Conceptuel des données
Cardinalités
Définition :
Quantifient le nombre d ’occurrences d ’une entité
qui participent à une occurrence

cardinalité minimale :combien

d ’occurrence au minimum? (0 ou 1)
cardinalité maximale :combien
d ’occurrence au maximum ? ( 1 ou n )

83
 Les cardinalités
(1,1)
(0,n)
(1,n)
(0,1)
Lorsque la cardinalité maximale d'un des deux
sens de lecture vaut 1 on dit alors que
l'association binaire est fonctionnelle. Elle
s'appelle aussi une dépendance fonctionnelle (DF)
ou contrainte d'intégrité fonctionnelle (CIF)
Lorsque les deux cardinalités maximales sont n
l'association binaire est non fonctionnelle

84
Démarche dans la construction
d ’un MCD
– Recherche des propriétés à gérer
– Regroupement des propriétés par entité
– Représentation des entités
– Recherche des relations
– Recherche des cardinalités
– Vérification validation du modèle

85
CONSTRUCTION DU MCD
Recherche des propriétés à gérer

– Par l ’intermédiaire d ’interview

– Par le diagramme acteur/flux
– Une donnée est caractérisée par :
Un nom
Une définition
Un domaine de définition
Une provenance
Un mode de calcul ( si donnée calculée )
Une décomposition ( si donnée non atomique )

86
CONSTRUCTION DU MCD
Dictionnaire de données

– Recense toutes les informations utiles au

système considéré.
– Formalisé par un tableau :
Nom abrégé, Description, Type, Nature,
Commentaires

87
CONSTRUCTION DU MCD
Représentation des entités

– Première ébauche du modèle conceptuel des

données ne faisant apparaître que :

entités
propriétés

88
CONSTRUCTION DU MCD
Recherche des associations

– Ecrire des phrases « en français » décrivant le

modèle : permet d ’établir des liens entre les
entités.

– Caractéristiques :
Nom
collection
cardinalité

89
CONSTRUCTION DU MCD
Recherche des cardinalités

Répondre à quatre questions :

Une occurrence de A peut être en relation avec
une occurrence de B
•combien de fois au minimum ?
•combien de fois au maximum?

Une occurrence de B peut être en relation avec

une occurrence de A
•combien de fois au minimum ?
•combien de fois au maximum?

90
CONSTRUCTION DU MCD
Règles de normalisation

– Qu ’est ce que les règles de normalisation ?

Cinq formes normales
Définies par des contraintes de dépendances

– But
Rendre le modèle le « plus propre possible »,
Limiter la redondance de données

91
 Dépendances fonctionnelles
Dans de nombreuses bases de données, le contrôle de la
redondance et la préservation de la cohérence des données sont les
plus importants auxquels est confronté le concepteur et
l’administrateur.
La redondance survient quand une information est stockée dans
plusieurs endroits. Si ce contenu est modifié, il faut le modifier au
niveau de chacune des copies. Si certaines, mais pas toutes les
copies, sont modifiées les données sont incohérentes.
Pour éviter ses écueils, cela passe par l’étude des dépendances
fonctionnelles.

92
Dépendances fonctionnelles
Définition : Une dépendance
fonctionnelle, notée DF, indique que la
valeur d'un ou plusieurs attributs est
associée à au plus une valeur d'un ou
plusieurs autres attributs.

93
Dépendances fonctionnelles (DF)
X et Y deux ( ou plusieurs) attributs de la B.D.
X Y : Y dépend fonctionnellement de X
La connaissance de la valeur de X entraîne la connaissance de la valeur de Y.
X détermine Y.
Pour une valeur de X, il existe une et une seule valeur de Y.
Si un attribut (ou un groupe d'attributs) détermine par DF tous les autres
attributs de la même relation, c'est une clé de la relation.
Exemple :
– Agence Ville
– Prêt Montant
– Id_article désignation
– (Numcom, NumLigne) Idarticle

94
Dépendances fonctionnelles
Les contraintes se classent en deux groupes
– Les contraintes sémantiques : dépendent de la signification ou de
la compréhension des attributs d’une relation
Dans une relation Personnel(Nom, Age, Salaire) aucun âge ou
salaire ne peut être négatif
– Les contraintes d’accord ou de concordance ne dépendent pas des
valeurs particulières d’un attribut d’un tulpe mais du fait que les
tulpes qui acceptent certains attributs acceptent ou non les valeurs
de certains de leurs autres attributs
Dans une relation Personnel (employé, âge, salaire, service, chef de
service) si un employé ne travaille que dans un service et que
chaque service n’a qu’un chef de service alors deux tulpes ayant la
même valeur dans la colonne chef de service on doit avoir la même
valeur dans service. On a une dépendance fonctionnelles
Les dépendances fonctionnelles sont les plus importante
contraintes de concordance ou d’agrément.

95
 Dépendances fonctionnelles
Définition d’une dépendance fonctionnelle élémentaire
– une DF, X B, est une dépendance fonctionnelle élémentaire si B est un
attribut unique, et si X est un ensemble minimum d'attributs (ou un attribut
unique).
Exemples : Dans la relation Produit, les DF :
– NP (couleur, poids) et (NP, NomP) Poids
ne sont pas élémentaires.
Mais les DF :
– NP Couleur, NP Poids, NP NomP
– NomP Couleur, NomP Poids, NomP NP
sont élémentaires.
La DF :
– (NP, NF, date) Qté
de la relation Livraison est élémentaire.

96
 Dépendances fonctionnelles
Soient W, X, Y et Z des ensembles d'attributs non vides d'une relation R. Voici
quelques propriétés remarquables:
Réflexivité
– W est une partie de X alors (X W)
Augmentation
– (W X) (W, Y X, Y)
Transitivité
– (W X et X Y) (W Y)
Union
– (W X et W Y) (W X, Y)
Pseudo-transitivité
– (W X et X, Y Z) (W, Y Z)
Décomposition
– (W X et Y une partie de X) (W Y)

97
 Première forme normale
Une relation est en première forme normale si :
– Elle possède une clé
– Tous ses attributs sont atomiques : c'est à dire n'ayant à un instant donné
qu'une seule valeur ou ne regroupant pas un ensemble de valeurs.
– Ses éléments sont indivisibles ( une seule valeur).
Si les tables relationnelles résultant de la modélisation ne sont
pas déjà en 1FN, il serait approprié de retourner à l’étape de
modélisation.
Une modélisation de qualité minimale devrait toujours être en
1FN.

Un schéma R est en 1NF Si et seulement si les

domaines de tous ses attributs sont atomiques
98
 Première forme normale
Exemple :
Clientèle = (IdClient, nom, adresse, tel)

Adresse comporte 2 valeurs : adresse et ville, d’où :

Clientèle = (IdClient, nom, adresse, ville, tel ) est en 1NF

99
 Deuxième forme normale
Une relation est en deuxième FN si :
– Elle est en 1FN
– Toutes les DF sont élémentaires par rapport à la clé
: tout attribut hors clé ne dépend pas d’une partie de
la clé

Un schéma R est en 2FN Si et seulement si

Tout attribut de R, n’appartenant pas à la clé primaire ,
est en dépendance fonctionnelle totale de la clé primaire

100
 Deuxième forme normale
Exemple
– Patient (N°patient, Date consultation, Nom)
– Nom dépend d’une partie de la clé N°patient Nom
– Le 2NF permet d’éliminer certaines redondances
Patient (N°patient,Nom)
Consultation (N°patient*,Date consultation, ordonnance)
Mais il peut rester des redondances …

101
 Troisième forme normale
Une relation est en troisième forme normale
si :
– Elle est en 2 FN
– Tout attribut hors clé est en DF directe par
rapport à la clé (pas de transitivité)

Un schéma R est en 3NF ssi

•R est en 2NF,
•Aucun attribut ne dépend transitivement de la clé
primaire, (tout attribut de R, n’appartenant pas à la clé, ne
dépend que de la clé),
102
Troisième forme normale
La 3NF permet d’éliminer des redondances, dues à des
dépendances transitives entre attributs mais elle ne suffit pas
parfois à éliminer toutes les redondances :
– Codepostal (Code, Ville, Rue)
– Les DF sont Code Ville et Ville,Rue Code
– Cette relation est en 3NF puisque aucun attribut non clé ne dépend
d’une partie de la clé ou d’un attribut non clé mais il y a des
redondances :
Code Ville Rue
54505 Vandoeuvre Aiguillette
54505 Vandoeuvre Gal Leclerc

103
 Forme de Boyce-
Boyce-Codd
(BCNF)
Une relation est en BCNF si :
– Elle est en 3 FN
– Tout attribut non clé de la relation n'est pas
source de DF vers une partie de la clé.
Ou
– Les seules DF élémentaires qu’elle comporte sont celle où une clé
détermine un attribut.
Dans l’exemple précédant :
CodeVille (Code*, Ville)
CodeRue (Code, Rue)
Sont en BCNF, mais perte de la DF Ville,Rue ->Code
Toute relation a une décomposition en BCNF sans perte d’information,
par contre, une décomposition en BCNF ne préserve pas généralement
les DF.

104
Forme de Boyce-
Boyce-Codd
(BCNF)

105
Méthode de normalisation
Il est souhaitable qu’un schéma relationnel ne comporte que
des relations en 3NF ou BCNF.
Des algorithmes de constructions permettent d’obtenir de tels
schémas. Ils sont de deux catégories :
– La méthode de décomposition :
Elle se base sur la décomposition de relations en utilisant les DF entre les
données. Cette méthode conduit à des relations en 3NF ou BCNF. Il y a 2
problèmes :
– Identification des DF et leurs exhaustivité
– Le résultat dépend de l’ordre d’application des décompositions et peut ne pas
préserver les DF
– La méthode synthétique
Elle se base sur la représentation des DF en terme de graphes (graphe et
leur couverture)

106
 Méthode synthétique
Point de départ
– L’ensemble de tous les attributs
– L’ensemble des DF entre attributs qui sont représentées dans un
graphe avec comme nœud un attribut et comme arc une DF
Ce qu’il faut faire
– Trouver la couverture minimale du graphe c’est-à-dire éliminer les
circuits ainsi que les DF non élémentaires et non directes
Résultat
– Une collection de relation en 3NF. Chaque schéma est obtenu en
prenant comme :
Clé une source de DF
Attributs, les buts des DF correspondant

107
 Exemple
Service d’immatriculation de voitures dans une préfecture
– Soient les DF suivantes :
N°Immat -> Couleur, Type, Puissance, Marque
N°Pers -> Nom, Prénom, Adresse
N°Immat -> N°Pers et Type -> Marque, Puissance
– On crée le graphe :
N°Pers N°Immat Type

Puissance
Nom Prénom Adresse Couleur
On supprime les transitivités Marque
On obtient :
Personne (N°Pers, Nom, Prénom, Adresse)
Voiture (N°Immat, Couleur, Type*, N°Pers*)
Types (Type, Puissance, Marque)
108