9 C 8213 D 79619

Analyse et Conception des
Systèmes d’Information
Soror SAHRI
soror.sahri@parisdescarets.fr
1
Informations pratiques
l  Cours
l  Soror Sahri
l  TDs
l  Soror Sahri
l  Nicoleta Rogovschi
l  Volume horaire
l  1h30 cours x 12 + 2h TDs x 12
l  Sources du cours
l  Ingénierie des SI : Merise, D. Nanci & B. Espinasse
2
Objectifs
Analyse et Conception des Systèmes d’Information (ACSI)
Analyse
Processus d’examen de l’existant
Conception
Processus de définition de l’application future
Systèmes d’Information
Ensemble de moyens et de méthodes se rapportant au traitement
de l’information d’une organisation
Objectifs
l  Comprendre les enjeux des systèmes d’information
l  Connaître les techniques de modélisation des SI
l  Apprendre des méthodes de conception des SI 3
§  Approfondir la méthode MERISE

Objectifs
l  on s'ʹintéresse en général à un domaine d'ʹactivité de
l'ʹentreprise :
§  ventes,
§  production,
§  logistique,
§  finances,
§  RH …
l  on prend en compte les besoins des utilisateurs,
l  on définit le problème à résoudre : fonctionnalités à offrir
et qualités a[endues.
Objectifs
on définit une solution informatique :
-‐‑ structuration des données,
-‐‑ organisation des traitements,
-‐‑  définition des postes de travail,
-‐‑  choix techniques : matériels, langages de
programmation, logiciels de gestion de
données (SGBD)…
Démarche « très théorique »
analyse du problème conception de la solution

réalisation du système
Difficulté de l’ACSI
Mythes
l  L’utilisateur connaît son métier et exprime ses besoins.
l  L’informaticien professionnel analyse les besoins puis développe une
application.
Utilisateur pro + informaticien pro =
application qui répond aux besoins…
Réalités
l  Besoins définis par plusieurs personnes (écarts)
l  pas forcément clairs, évolutifs…
l  L’informaticien est un pro de l’informatique, pas du métier pour lequel il
conçoit.
l  Il peut se « tromper » dans ce qu’il comprend

Besoins pas toujours bien définis + informaticien qui ne connaît pas le
métier = application forcément « imparfaite » …
Pas une démarche linéaire
l  Pas une démarche linéaire :
« analyse → conception → réalisation »
l  Un recueil des besoins exhaustif dès le départ n’est pas réaliste
dans les cas complexes.
Analyser Concevoir Réaliser
ACSI
…. mais une démarche « itérative »

Processus de développement itératif et travail d’analyse itératif sur le terrain :
4-
1- Poser des Soumettre son
questions Travail
Quoi? Pourquoi? Comprendre
Comment? Qui? le métier
… Accepter les
changements
2 - Analyser les
réponses 3 – Modéliser
Cohérentes? But? Lecteurs?
Complètes? Notation?
Suffisantes? …
Quelques concepts
Système d’information
Entreprise Utilisateurs
Domaine d’étude
Besoins Méthode Analyse
Système informatique
9
Quelques concepts
Entreprise Entreprise
Domaine d’étude
Analyse
Besoins
Méthode Système
d’information
Utilisateurs Utilisateurs
10
Système d’Information
Définitions
l  Un SI est l’ensemble des moyens techniques et humains et des méthodes qui
perme[ent le traitement des informations au sein d’une organisation et dans
ses rapports à son environnement.
l  Un SI est un ensemble d’éléments, matériels ou pas, en interaction entre eux,
transformant des éléments d’entrée en éléments de sortie.
Eléments en entrée Système Eléments en sortie
Exemple
l  Une entreprise qui commercialise des produits
l  En entrée: des produits achetés, des commandes, les paiements des clients
l  En sortie: des produits vendus, des factures, les paiements des fournisseurs
11
l  Contexte : Une entreprise est décomposée de trois sous-‐‑systèmes:
l  Un système de pilotage (ou de décision) qui définit les objectifs,
contrôle et prend les décisions
l  États statistiques, historiques, décisions, plan…
l  Un système opératoire qui réalise les tâches

l  Gestion de production et des stocks, facturation, compatibilité…
l  Un système d’information qui sélectionne les informations pertinentes

dans le système opératoire, les traite pour fournir des informations
synthétiques au système de décision qui peut alors renvoyer des
directives vers son système opératoire.

12
Entreprise/Organisation
Système de Décision

Environnement
réfléchi, décide, contrôle

Système Flux de décisions
de pilotage
Demande et
restitution Information
d’information de décision
Flux d’informations
Système d’Information SI
mémorise, traite, diffuse
Demande et
collecte Information
d’information de représentation
Flux
Système physiques
opérant
Flux entrant Système Opérant Flux sortant
transforme, produit
13
l  Une partie du SI peut être informatisée
l  Ce système informatisé prend appui sur un système
informatique composé de matériel et de logiciel de base


Système informatisé
14
Caractérisation « informatique » d’un SI
S.I.
infrastructure
(distribuée)
base(s) de applications
données
règles d’usage, de validation, de sécurité, de suivi et
d’évolution…
Algorithmique Programmation
Bases de données Interfaces utilisateurs
Réseaux et systèmes Systèmes distribués

≠
Un système d’information Un système informatique

Met en œuvre
Un Système
L’organisation
d’Information
Qui sont mis à
la disposition de
Des ressources
informatiques
Des ressources
humaines
D’autres
ressources: tél...
16
l  Le fonctionnement d’un SI suppose :
l  Le stockage des informations
l  Données
l  La définition des procédures agissant sur les informations stockées
l  Traitements
Aspects d’un SI
l  Statique : Mémoire de l’organisation
l  Enregistrement des faits : base d’information
l  Enregistrement des structures de données, etc.
l  Dynamique :
l  Mise à jour des données
l  Changement des règles, structures et contraintes de l’univers extérieur
17
Système d’Information : Problématique
l  Champ d’application très vaste dû à la variété des systèmes :
l  Bureautique, informatique de gestion, informatique scientifique, imagerie,
etc.
l  Compléxité intrinsèque des S.I. :
l  Utilisation de nombreuses techniques pour la modélisation des systèmes
(théorie des BD, les LP, les automates, etc)

Besoin de méthodes pour la construction d’un SI

18
Système d’Information : Problématique
l  Vue « réaliste » d’un SI : complexité
l  Grand nombre de métiers, d’échanges, de données, d’applications, de serveurs…
Système d’Information : Méthode
l  Une méthode définit un processus d’informatisation, possède

un champ d’étude et décrit une démarche à suivre
l  Une méthode
l  S’appuie sur des concepts théoriques
l  Aide à la mise en place d’un langage commun au sein de
l’organisation
l  Doit perme[re une meilleure communication entre tous les
partenaires

20
Composants d’une méthode de construction d’un S.I.
Démarche Modèles
Méthode de
construction
d’un S.I.
Outils et techniques langages
21
Composants d’une méthode

l  Démarche
l  Processus à suivre pour effectuer les travaux demandés. Elle est
découpée en étapes.
l  Modèles
l  Ensemble de concepts et de règles destinés à expliquer et à
construire la représentation de phénomènes organisationnels
l  Langages
l  Destinés à spécifier et à simplifier la communication
l  Outils et techniques
l  Aide à la mise en œuvre des modèles, des langages et de la
démarche. 22
La notion de modèle
l  Au centre de la démarche d’ACSI
l  Modèle = représentation simplifiée d’une réalité sur
laquelle on veut être renseigné.
l  S’exprime avec un ensemble de concepts dotés de règles
d’utilisation et de notations (souvent graphiques).
l  En ACSI les modèles servent à :
l  communiquer : vérifier que l’analyste a bien compris les
utilisateurs grâce à des modèles du problème (modèles

d’analyse)
l  préparer la réalisation : grâce à des modèles de la solution
(modèles de conception).

Un modèle…
La réalité ?
But ?
Lecteurs ?
Notation ?
Autant de modèles que de buts, de lecteurs, de
notations … de modélisateurs.
Modèle pour touriste
même
réalité
Modèle pour technicien

Bonnes pratiques
l  Décrire d’abord les grandes lignes de ce qu’on a
compris.
l  Faire valider ce qu’on pense avoir compris
l  modéliser = apprendre en se posant des questions
l  Détailler ensuite les modèles.
l  Faire valider de manière itérative.
26
Qualités pour devenir un bon analyste-‐‑concepteur
l  Décrire d’abord les grandes lignes de ce qu’on a compris.
l  qualités relationnelles
l  écoute, travail en équipe
l  ténacité et rigueur

l  synthétiser ce qui est important, ne pas se noyer dans les
détails, fuir « l’à-‐‑peu-‐‑près », accepter les remises en
cause…
l  créativité
l  pas de rece[es toutes faites

Métiers difficiles mais plus valorisants et mieux payés :
l  analyste, chef de projet, architecte SI, consultant ...
Quelques méthodes
l  MERISE
l  Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprises
l  AXIAL
l  Analyse et Conception des Systèmes d’Information Assistés par Logiciels
l  SSADM
l  Structured Systems and Design Method
l  SADT
l  Structured Analysis and Design Techniques
l  OOA
l  Object-‐‑Oriented Analysis
l  OMT
l  Object Modeling Technique
28
MERISE
29
MERISE : Historique
l  Approche ancienne :

l  Merise date des années 1978 et 1979. Elle résulte d’une
demande du ministère de l’Industrie (en 1977) qui
souhaitait obtenir une méthode de conception de système
d’information.
l  Origine :
l  Ce sont le Centre Techniques de l’Equipement et le Centre
d’Etudes techniques de l’Equipement qui sont à l’origine de
ce[e méthode.
30
MERISE : Définition
MERISE :
l  Méthode d’Etude et de Réalisation Informatique pour
les Systèmes d’Entreprises
l  Méthode Eprouvée pour Retarder Indéfiniment la Sortie
des Etudes
l  MEthode pour Rassembler les Idées Sans Effort
31
MERISE : Définition
l  Merise est une méthode d’analyse et de conception

l  Analyse : Etude du problème
l  Etudier le système existant
l  Comprendre les besoins : diagnostiquer
l  En déduire le niveau conceptuel : donner une vision fonctionnelle
du système
l  Conception : Etude de la solution
l  Proposer de nouvelles solutions organisationnelles
32
MERISE : La démarche
l  La démarche de construite d’un SI doit être conduite suivant trois axes (les
cycles) :
l  Cycle de vie : échelle de temps
l  On sait dans quel ordre on fait les choses
l  Cycle d’abstraction : à 3 niveaux
l  On sait dans quelle logique on doit travailler
l  Cycle de décision : choix organisationnels et techniques
l  On sait ce qu’on doit décider à chaque étape
33
l  Cycle de vie
l  Démarche d’informatisation : succession de
phases contrôlables par l’organisation
(planning, échéances, moyens humains…).
l  Se situe sur une échelle de temps qui va du
point de départ à l’exploitation du système, en
passant par sa naissance, sa maturité et sa
maintenance
l  Cycle de décision
l  Représente l’ensemble des choix à faire durant
le déroulement du cycle de vie.
l  Ces décisions fixent :
l  Les objectifs organisationnels et techniques, les
priorités de développement, les ressources allouées
au projet, la mise en place et le suivi de plannings
d’avancement.
l  Les décisions sont prises hiérarchiquement
34
l  Cycle d’abstraction
l  Niveau conceptuel :
l  Quoi ?
l  Niveau Organisationnel :
l  Qui ? Quand ? Où ?
l  Niveau Logique :
l  Avec quoi ? Quels outils ?
l  Niveau Physique
l  Comment ?
35
MERISE : Cycle d’abstraction
Exemple
l  Niveau conceptuel :
l  Un client effectue une demande de service à la compagnie pour assurer
son véhicule, la compagnie lui propose un devis
l  Niveau Organisationnel/Logique :
l  Un client effectue une demande de service à l’agence de son choix, par
courrier, pour assurer un véhicule. Un agent de service concerné, si le
client est solvable, prend contact par téléphone pour une visite à domicile
afin d’examiner plus précisément ses besoins et établir un devis.
l  Niveau Physique
l  Le fichier central inter assurances est accessible par Internet.
Les agences sont connectées au siège de la compagnie. Chaque agence
dispose d’un PC et peut traiter ses données en local grâce à ACCESS
36
Le niveau conceptuel
l  Décrire le QUOI indépendamment de toute contrainte

d’organisation ou technique.
l  Définir les activités, les données, … indépendamment des
aspects organisationnels et techniques.
Exemples
l  Faire la pré-‐‑facturation ou de la post-‐‑facturation
l  Une commande client pourra être livrée en plusieurs fois,
chaque livraison donnant lieu à une facture.
l  Les invariants du point de vue des données : contrats, clients, etc.
l  Les invariants du point de vue des traitements : signer un
contrat, éme[re une facture, etc. 37
Le niveau organisationnel/logique
l  Exprimer les choix organisationnels de ressources

humaines et matérielles
l  Définir indépendamment des moyens de traitement et
de stockage de données actuels et futurs
l  La répartition géographique et fonctionnelle des sites de
traitements
l  Le mode de fonctionnement : temps réel / temps différé
l  La répartition du travail homme/machine
l  Les postes de travail
l  Etc.
38
Le niveau organisationnel/logique
l  Le schéma logique est la traduction du schéma conceptuel selon
un modèle existant (hiérarchique-‐‑réseau-‐‑relationnel).
l  Ces schémas sont totalement indépendants de la technologie
utilisée.
Exemples
l  La facturation sera décentralisée dans les agences
l  Réaliser telle partie par la machine, laisser l’autre partie pour un traitement
manuel.
l  Créer un type de poste de travail ( agent de saisie, etc)
Exemples d’éléments organisationnels

l  Un document (rapport d’activité, tableau de bord, etc)
l  La sécurité
l  La date 39
Le niveau physique
l  Le COMMENT FAIRE. Le logiciel de développement

ainsi que le type du matériel qui sera utilisé sont choisis
l  Répond aux besoins des utilisateurs sur les aspects
logiciels et matériels.
l  Définir complètement :
l  Les fichiers, les programmes
l  L’implantation physique des données et des traitements
l  Les ressources à utiliser
l  Les modalités de fonctionnement
40
L’approche Données/Traitements
l  Pour étudier et développer l’informatique d’une

organisation, il est nécessaire de connaître :
l  Ses échanges internes et externes
l  Comment elle réagit à une sollicitation externe
l  Quelle est la structure des informations qu’elle utilise
l  Merise décrit ce[e connaissance sous la forme de trois
découpages :
l  Communication
l  Traitement
l  Données
41
L’approche Données/Traitements
l  Communication :
l  Etude des échanges entre les composants de l’organisation
l  Traitements :
l  Etude des évènements
l  Indépendance entre les domaines
l  Données
l  Etude du vocabulaire de l’organisation
l  Intégration des domaines : vue globale
42
Courbe de soleil
43
Les modèles MERISE
Données Traitements
Niveau Conceptuel
Quoi
MCD MCT
Qui Niveau Organisationnel/Logique
Quand
Où MLD MOT
Niveau Opérationnel/Physique
Comment
MPD MPT
44
Modélisation Conceptuelle des données
l  Modèle E/A

l  Concepts et règles de modélisation
l  Démarche de construction d’un modèle E/A
45
Modèle Entité/Association
l  Il s’agit d’un modèle conceptuel de MERISE et de AXIAL
l  Il permet d’exprimer l’ensemble des informations que l’on veut
prendre en compte dans un système d’information
l  La solution est basée sur un formalisme de représentations
l  Guider le raisonnement du concepteur
l  Obliger à respecter des normes
l  Utiliser un langage commun
l  Le résultat est un schéma conceptuel de données clair, cohérent,
complet et normalisé
l  Ce résultat est indépendant des considérations techniques ou
organisationnelles 46
Modèle Entité/Association
Une bibliothèque
Organisation
Les livres avec leur référence, leur titre et leur auteur
Les abonnés avec leur nom et leur adresse
Les emprunts de livre par les abonnées Modèle Conceptuel de Données
L564 Les misérables V. Hugo

Base de
R876 Germinal E. Zola données
47
Concepts et règles de modélisation
l  Les principaux concepts du modèle E/A sont :
l  Entité
l  Association
l  Propriétés
l  Contraintes d’intégrité
l  Le modèle E/A identifie, décrit et modélise les entités et les
associations à l’aide d’une représentation graphique
Entités

Abonné
Livre

Emprunt
nom 0,n 0,n référence
adresse Titre
1er auteur
48
Propriétés
Association
Propriété
l  Une propriété est une donnée élémentaire qu’on perçoit sur une entité et sur
une association
l  Exemple
l  Les abonnées ont les propriétés suivantes : nom, adresse, date de naissance, etc.
l  Chaque propriété ne peut avoir une occurrence qu’une seule fois.
l  Exemple
l  Nom d’abonné : Dupond, Durand, Martin.
l  Nom d’auteur : Hugo, Zola.
l  Une propriété se décrit par tout ou partie des éléments suivants :
l  Définition : ce qu’elle représente et son intérêt dans le contexte
l  Domaine de valeur : quantité, nombre , date, etc.
l  Longueur : nombre de caractères
l  Caractéristiques complémentaires :
l  Obligatoires ou facultative ; naturelle ou calculée; élémentaire, décomposable ; normée : en interne ou
49
par des organismes officiels (n° INSEE)

Entité
l  Une entité est un élément ou un objet concret ou abstrait du monde réel qui
existe.
Bibliothèque réelle Modèle conceptuelle : Entité
Dupond Abonné

Martin
Durand
l  Une occurrence d’une entité est représentée par l’ensemble de valeurs de
ce[e entité. Dupond

Abonné
Martin

Durand

50
l  Formellement, une entité est définie par son nom et l’ensemble
des propriétés qui la définissent.
l  Une entité doit disposer d’une propriété particulière qui jouera
le rôle d’identifiant de l’entité.
l  Un identifiant définit d’une manière unique les occurrences
d’une entité
Exemple
l  N° INSEE pour l’entité ABONNE
l  À chaque numéro INSEE, correspond une seule valeur de l’ensemble :
nom, prénom, âge, etc.
51
Règles d’identification
l  Plusieurs types d’identifiant
l  Identifiant simple naturel (nom d’un pays) ou artificiel (n° client)
l  Identifiant composé (n° sécurité sociale)
l  Identifiant relatif comprenant des propriétés n’appartenant pas à l’entité à
identifier
l  Un identifiant doit être :
l  univalué : une occurrence entité correspond à une valeur de l’identifiant
l  Discriminant : une valeur de l’identifiant correspond à une occurrence de
l’entité
l  Stable
l  Minimal (pour les identifiants composés)
52
Entité : Règles de vérification
l  Une entité a un seul identifiant
l  Une entité a au moins une propriété
l  Une information ne peut être que dans une seule entité.
Pour être dans ce[e entité, elle doit dépendre de l’identifiant.
l  Une entité participe a au moins une association
53
Association
l  Une association modélise un ensemble de liens logiques de même
nature entre deux ou plusieurs occurrences d’entités, ayant intérêt
significatif pour le système à représenter.
l  Une association n’existe qu’à travers les entités qu’elle relie.
l  Chaque occurrence d’une association doit pouvoir être distinguée des
autres occurrences de la même association.
l  On désigne en général une association par le nom d’un verbe.
l  Verbe à l’infinitif : appartenir, concerner
l  La forme passive et active permet d’orienter la lecture de l’association.
54
Exemple
l  L’association Emprunt entre les entité Abonné et Livre.R876

Livre
Abonné
Emprunt
nom référence
adresse Titre
1er auteur
l  Occurrences :

Livre
Abonné
Emprunt

Dupont L564
Paris Les Misérables
V. Hugo Livre
Abonné
Emprunt

Martin R876
Lyon Germinal
E.Zola
55
l Une association peut avoir des propriétés.
Exemple

Livre
Abonné
Emprunt
nom référence
adresse Date emprunt
Titre
1er auteur
Une association a pour identifiant la concaténation des identifiants des

l 
entités qu’elle relie.
Exemple
l  L’association Emprunt a pour identifiant nom et référence.
56
l  On distingue différents types d’association :
l  Les associations binaires : qui associent 2 entités
l  Exemple : ENSEIGNANT Noter COURS
l  Les associations n-‐‑aires : qui associent plus de 2 entités
l  Exemple : ENSEIGNANT Noter COURS

MATIERE
l  Les associations réflexives: qui associent les occurrences de la même entité
l  Exemple : CLIENT Parrainer
57
Les cardinalités
l  Une cardinalité caractérise la participation d’une entité à une
association.
l  Elle représente le nombre d’occurrences d’une association pour chaque
occurrence d’entité qu’elle relie.
l  On distingue :
l  La cardinalité minimale : donne le nombre minimum de participations de
chacune des occurrences d’une entité à une association
l  La cardinalité minimale est égale à 0 ou 1 :
§  0 s’il existe une occurrence de l’entité ne participant pas à l’association
§  1 si toute occurrence de l’entité participe à l’association
l  La cardinalité maximale : donne le nombre maximum de chacune des occurrences
d’une entité à une association
l  La cardinalité maximale est égale à 1 ou tout nombre fixé (2,3…) ou à n.
58
Exemple
l  Un cours est enseigné par au moins un enseignant (1,…) ou par plusieurs
enseignants (..,n).

Cours
Enseignant
Enseigner
nom 0,n 1,n Numéro cours
Prénom Titre cours

Age

l  Un enseignant peut n’enseigner aucun cours (0,..) ou plusieurs cours (..,n).
59
Les contraintes d’intégrité
l  Une contrainte d’intégrité (CI) est définie comme une assertion qui doit
être vérifiée par des données à des instants déterminés.
l  Une CI permet de spécifier des propriétés sémantiques du réel perçu
qui ne sont pas exprimables avec le modèle E/A.
l  les contraintes sur les propriétés
l  Les contraintes sur les cardinalités
60
Contraintes sur les propriétés
l  Les contraintes liées aux propriétés correspondent à des
contrôles à assurer pour vérifier l’intégrité des données et la
cohérence par rapport au système à représenter
l  Les contraintes de valeur
l  C’est l’ensemble des valeurs que peut prendre une propriété :
§  Domaine de valeurs
§  Contraintes statiques : en fonction de la prise par d’autres propriétés
§  Contraintes dynamiques : lors d’un changement d’état du SI
l  Les dépendances fonctionnelles
61
Contraintes sur les propriétés (suite)
Exemples
l  Les contraintes de valeur
l  Domaine de valeurs
l  les valeurs possibles de l’état civil sont : célibataire, marié, divorcé, séparé, veuf
l  Contraintes statiques
l  date d’ouverture de compte inférieure ou égale à la date du premier mouvement
l  Contraintes dynamiques
l  la valeur de l’état civil peut devenir divorcé si la valeur précédente était marié ou séparé
l  Les dépendances fonctionnelles

l  À numéro tiers correspond un seul nom du tiers
l  À numéro de compte correspond une seule valeur type de compte
62
Contraintes d’intégrité fonctionnelle CIF
Une CIF entre deux entités exprime le fait que l’identifiant de la
l 
première détermine une occurrence de la deuxième.
Exemple
l  Un véhicule appartient à une seule personne.
l  Si on connait le matricule du véhicule, on peut savoir toutes les informations nécessaires sur
son propriétaire
l  Une commande est passée par un et un seul client
l  Si on connait le numéro de la commande, on peut déterminer les informations sur le client qui
l’a passée
63
Les règles de validation d’un modèle E/A
Règle 1
Toutes les propriétés doivent être élémentaires (non décomposables)
Règle 2
Chaque objet doit posséder un identifiant et un seul.
Règle 3
Les propriétés d’un objet autres qu’un identifiant doivent être en
dépendance fonctionnelle monovaluée de cet identifiant
Exemple NumMatricule détermine NomSalarié et Num Matricule multidétermine Diplôme

SALARIE
SALARIE

DIPLOME
Obtenir
Num matricule Num matricule 0,n 0,n Libellé Diplôme
Niveau
Nom Salarié Nom Salarié

…… ……
64
Diplôme
Règle 4
Une propriété ne peut qualifier qu’une seule entité ou qu’une seule
association
Exemple
La propriété Adresse Client ne peut être présente à la fois dans l’entité CLIENT et
l’entité FACTURE

CLIENT FACTURE

Correspond
Num Facture
Num Client 0,n 1,1 Date Facture

Nom Client …..
…… Adresse Client
Adresse Client
Redondance
65
Règle 4 (suite)
Une propriété ne peut s’appeler Adresse dans CLIENT et FACTURE. Si c’est
le cas, il faut les renommer Adresse Client et Adresse Facture.
Exemple

CLIENT FACTURE

CLIENT FACTURE

Num Facture Num Facture
Num Client Date Facture Num Client Date Facture
Nom Client ….. Nom Client …..
…… Adresse …… AdresseFacture
Adresse Adresse Client

66
Règle 5
La dépendance fonctionnelle transitive doit être écartée
Exemple

CLIENT
CATEGORIE

CLIENT
Num Client Appartient
Num Client 1,1 0,n Code Catégorie
Nom Client
……
Nom Client Intitulé
…… Taux Remise
Catégorie Client

Taux Remise
Num Client détermine Catégorie Client

Catégorie client détermine le taux de remise
Num Client détermine Taux de remise
67
Règle 6
Pour chaque occurrence d’une association, il doit exister une et une seule
occurrence de chacune des deux entités liées
Exemple : Un article est fourni et stocké dans un emplacement
Dans le cas où certains articles proposés par les fournisseurs ne seraient pas en stock, la règle 6
n’est pas respectée. La règle de gestion est donc composée en : un article est fourni par un
fournisseur ET un article est stocké dans un emplacement

ARTICLE
ARTICLE
0,n Fournir

Num Article Num Article
Désignation Désignation

0,n
0,n FOURNISSEUR 0,n FOURNISSEUR

EMPLACEMENT
EMPLACEMENT
Adresse Num Fournisseur Adresse Num Fournisseur
0,n Stocker
0,n Nom Fournisseur 0,n Stocker
Nom Fournisseur
Surface Quantité Surface Quantité
…… ….. …… …..
Mode Stockage Adr Fournisseur Mode Stockage Adr Fournisseur
68
Règle 7
Les propriétés d’une association doivent dépendre de la totalité de
l’identifiant de l’association.
Exemple

EMPLOYE
EMPLOYE

Num Employe
Num Employe
Nom
Nom

1,n
BATIMENT
SERVICE
1,n
BATIMENT SERVICE

1,n
Nom Service
Affecter 1,n Nom Bâtiment
Nom Service Affecter
1,n Nom Bâtiment
Date début Budget 1,n Date début

Budget Date fin
Date fin

Prime pédagogique

1,n Prime
1,n

Prime pédagogique

69

Démarche de construction d’un modèle E/A
But : obtenir une représentation du système à développer

l  Deux approches pour la construction d’un modèle E/A
l  L’approche ascendante
l  L’approche descendante
70
Approche ascendante
l  L’approche ascendante se déroule en plusieurs étapes :

l  Recueillir des informations utiles
Analyse des besoins
l  Expliciter clairement les règles de gestion
l  Etablir la liste des propriétés
l  Construire le dictionnaire de données
l  Construire le graphe des dépendances fonctionnelles Conception du MCD
l  Etablir le modèle conceptuel de données
71
Approche ascendante
Exemple : Cas de gestion des commandes et des factures
Recueillir des informations utiles
l  Rassembler des exemplaires des différents documents et fichiers en usage
Expliciter des règles de gestion
l  Règle 1: Le client peut passer une ou plusieurs commandes ou aucune commande
l  Règle 2 : Une commande peut concerner un ou plusieurs produits
l  Règle 3 : Une commande est passée par un représentant qui n’est pas toujours le même pour un client
donné
Identifier les propriétés
l  Numéro bon
l  Date de la commande
l  Nom client
l  Numéro client
l  Adresse client
l  Nom du représentant
l  Numéro représentant
l  Référence du produit
l  Quantité achetée
l  Désignation du produit
l  Prix unitaire 72
l  Montant d’une ligne
l  Total commande
Approche ascendante
Construction du dictionnaire de données
l  Un dictionnaire de données est une structure qui rassemble l’ensemble des
données relatif à un sujet
l  Le but d’un dictionnaire de données est de recenser, structurer et donner une
première analyse des informations du sujet
l  L’origine des informations provient de :
l  Description de l’activité
l  Description des objectifs
l  Analyse des documents utilisés
l  Les interviews
l  Les fichiers existants
73
Approche ascendante
Construction du dictionnaire de données
l  Exemple
74
Approche ascendante
Construction du graphe de dépendances fonctionnelles
l  Dépendance fonctionnelle
l  Soient a et b deux propriétés quelconques. b dépend de a (on note a→b) si chaque
valeur de a détermine de manière unique la valeur de b
Exemple
l  Numéro Client → Nom Client
l  Numéro Client →Adresse
l  Numéro Client → Numéro Produit
l  Graphe de dépendances fonctionnelles

l  Un graphe qui permet de visualiser les dépendances fonctionnelles est appelé
graphe de dépendances fonctionnelles (GDF).
75
Approche ascendante
Construction du graphe de dépendances fonctionnelles (suite)
l  Etapes de construction d’un GDF
l  Extraction du dictionnaires de données de toutes les propriétés qui ne sont ni
calculées ni concaténées (Règle de validation n° 1)
l  Suppression de Adresse, Montant et Total
l  Construction du GDF
NBON
REFPRO
QTE
NCLI
DATE NREP
DESIGN PU
NOMREP NOMCLI RUECLI VILLECLI
76
Approche ascendante
Construction du graphe de dépendances fonctionnelles (suite)
l  Etapes de construction d’un GDF
l  S’il reste des propriétés isolées, on cherche des DF qui conduisent à des
propriétés à partir de propriétés concaténées
NBON
REFPRO
QTE
DATE NREP NCLI
DESIGN PU
NOMREP NOMCLI RUECLI VILLECLI

l  On élimine les DF obtenues par transitivité
l  NBON → NOMREP est une DF obtenue par transitivité
NBON
REFPRO
QTE
DATE NREP NCLI
DESIGN PU
NOMREP NOMCLI RUECLI VILLECLI 77

Approche ascendante
Réalisation du MCD
l  Les arcs terminaux obtenus à partir des propriétés élémentaires définissent les
entités
l  Entités COMMANDE, REPRESENTANT, PRODUIT, CLIENT
l  Les origines des arcs sont les identifiants
l  COMMANDE(NBON), REPRESENTANT(NREP), PRODUIT(REFPRO),
CLIENT(NCLI)

COMMANDE
PRODUIT
NBON
Date REFPRO
DESIGN
QTE
PU

REPRESENTANT
CLIENT
NCLI
NREP NOMCLI
NOMREP RUECLI
VILLECLI

78
Approche ascendante
Réalisation du MCD
l  Les arcs restants me[ent en évidence les associations
l  L’association PASSE, OBTIENT et COMPOSE
l  Les propriétés non isolées restantes sont affectées à des associations
l  QTE est affectée à l’association COMPOSE
l  Les propriétés isolées doivent constituer des entités isolées

COMMANDE
1,n PRODUIT
NBON
COMPOSE
0,n
Date QTE REFPRO
DESIGN
1,1
1,1 PU

OBTIENT PASSE

0,n 0,n

REPRESENTANT
CLIENT
NCLI
NREP NOMCLI
NOMREP RUECLI
79
VILLECLI

Approche descendante
l  L’approche descendante se déroule en plusieurs étapes :
l  Recueillir des informations utiles Analyse des besoins
l  Expliciter clairement les règles de gestion
l  Structuration Conception du MCD
80
Recueil des informations utiles
l  Consiste à recueillir, auprès des utilisateurs, les informations utiles.
l  L’utilité d’une information se mesure en examinant les objectifs
assignés au système
Entrées
Questions Sorties
Réponses
En règle général, le système doit produire des documents

en réponse à la fourniture d’informations
81
Structuration
l  Consiste à me[re en évidence les entités en regroupant les informations par
affinité
Recueil des informations Structuration
info1 Entité A
info2 Info1
Entité B
Info2
info3 info3 Info5
info4 Info6
info5 info4
info6
Une fois positionnée dans une entité, une information

n’est plus disponible pour décrire une autre entité 82
Structuration (suite)
l  Me[re en évidence les associations porteuses d’informations
l  Les informations qui ne sont pas regroupables dans une entité sont des informations
indépendantes qui sont placées dans des associations
(Entité A, Entité B)

Entité A
Info1
Entité B
Info2
info3 Info5
Info6
info4
83
Normalisation
l  Une fois structurées, on obtient un schéma conceptuel de données formé
d’un ensemble d’entités décrites à l’aide de propriétés, et reliées entre elles
par des associations
l  La normalisation consiste à vérifier que certaines règles de « bonne qualité »
sont respectées.
l  Trois séries de contrôle :
l  Les propriétés
l  La structuration
l 
Les cardinalités
84
Normalisation
Normalisation des propriétés
l  Chaque propriété est unique
l  Chaque propriété est bien localisée
l  Chaque propriété a un nom significatif
l  Eviter les redondances évidentes ou cachées

Produit

Produit

Tarif
Prix1 1,n coûte
Prix2 code
prix

Client Prospect Personne

Code personne
Code client Code prospect
Type (C,P)
Nom client Nom prospect
Nom personne
85
Normalisation
Normalisation des associations
l  Vérifier l’unicité des noms d’association
l  L’absence d’associations fantôme
l  La non redondance des chemins
l  La non décomposabilité
Exemple
Association fantôme E1 E2
1,1
A 1,1

1,1
E3

l  Une occurrence de E1 n’est liée qu’à une seule occurrence de E2 et de E3 : E1, E2 et E3
sont une seule et même entité et A n’a pas lieu d’être. 86
Normalisation
Exemple (suite)
Suppression de la redondance des chemins
E1 E2 E1 E2
A 1,1 A 1,1

1,1

C C

B 1,1 E3 B E3

Division
Salarié
0,n 1,1
travaille
Tous les salariés occupent un bureau situé dans
0,n 1,1

le département dans lequel ils travaillent
occupe

Situé dans
1,1 Bureau
0,n 87

Les extensions MERISE
88
Spécialisation/Généralisation
Spécialisation simple
l  La spécialisation simple permet de modéliser, dans l’ensemble
des occurrences d’une entité, des sous-‐‑ensembles d’occurrences
présentant des spécificités
l  Ces spécificités peuvent porter sur des propriétés ou des
relations
Exemple
l  Un assuré peut être une entreprise, un particulier ou les deux.
l  On distingue 3 entités : ASSURE, ENTREPRISE et PARTICULIER
l  Un assuré a les propriétés N° Assuré, Nom, Adresse, Type et Téléphone
l  Un assuré particulier a en plus une profession et une classe d’âge
l  Une entreprise a un N° SIREN et une forme juridique
89
Spécialisation simple

Spécialisation multiple
90
Contraintes sur spécialisation
l  Elles expriment les participations des occurrences de l’entité
sur-‐‑type aux entités sous-‐‑types
Types de contraintes
l  Pas de contraintes
§  Un assuré peut être particulier, entreprise, ni particulier ni entreprise, ou les
deux à la fois
l  Exclusivité
§  Un assuré peut être soit particulier soit entreprise, soit ni particulier ni
entreprise mais pas les deux à la fois
l  Totalité
§  Tout assuré est un particulier, entreprise ou les deux
l  Partition
91
§  Tout assuré est soit une entreprise soit un particulier
Spécialisation à sur-‐‑types multiples
C’est une notion proche de la notion de l’héritage multiple
l 
Exemple
l  Etudiant salarié
92
Généralisation
l  La généralisation est un processus de modélisation perme[ant de rassembler
dans une même entité toutes les propriétés communes, et de garder les
propriétés spécifiques dans les entités spécialisées
l  Le concept d’héritage consiste à transme[re les propriétés de l’entité super
type vers les entités sous types
l  Les entités sous types peuvent avoir leur propre identifiant
93
Restrictions et sous types d’associations
Exemple
l  On dispose de trois entités : EMPLOYE, CHEF_PROJET et PROJET.
l  CHEF_PROJET étant un sous type de EMPLOYE. A l’entité PROJET peuvent être
affectés des employés via une association Travailler. Plusieurs employés peuvent
travailler sur un même projet mais à un projet est affecté un et un seul chef de projet
l  Pour l’entité CHEF_PROJET, il a y modification des cardinalités de l’association
Travailler.
l  On introduit une nouvelle association Gérer entre CHEF_PROJET et PROJET
en notant bien que c’est une spécialisation de l’association Travailler
94
Notions complémentaires
Contraintes intra-‐‑association
l  On ne peut pas toujours représenter avec les cardinalités les contraintes d’intégrité
fonctionnelles CIF
l  Une CIF sur une association binaire
l  Une CIF sur une association ternaire
95
Contraintes inter-‐‑associations
l  Les contraintes inter-‐‑associations expriment les conditions entre deux ou plusieurs
associations
l  Contraintes sur la participation d’une entité à plusieurs associations
96
Exclusivité de participation d’une entité à plusieurs relations
l Deux (ou plusieurs) associations au départ d’une entité peuvent avoir des existences,
en termes d’occurrences, mutuellement exclusives. On l’exprime par une contrainte X.
Exemple
l  Si une occurrence de l’entité ARTICLE participe à l’association Acheter, elle ne peut pas
participer à l’association Approvisionner et réciproquement.
97
Simultanéité de participation d’une entité à plusieurs relations
l Toute occurrence de l’entité participe de façon simultanée à deux (ou plusieurs)
associations. On l’exprime par la contrainte S.
Exemple
l  Toute occurrence de l’entité COMMANDE participant à l’association Passer participe simultanément à
l’association Porter
98
Totalité de participation d’une entité à plusieurs relations
l Toute occurrence de l’entité participe au moins à l’une des associations.
On l’exprime par T.
Exemple
l  Tout véhicule est au minimum relié soit à un contrat par l’association Couvrir, soit à un sinistre par
l’association Impliquer, soit les deux.
99
Totalité et exclusivité de participation d’une entité à plusieurs relations
Exemple
l  Une entité COMMANDE participant à deux associations Passer et Provenir, toute
occurrence de COMMANDE participe soit à l’association Passer, soit à l’association
Provenir.
100
Inclusion de participation d’une entité à plusieurs relations
Exemple
l  Si une occurrence de l’entité PERSONNE participe à l’association Souscrire, elle
participe à l’association Effectuer mais pas réciproquement.
101
Modélisation du temps
l  Modélisation de propriétés à valeurs calendaires
l  Date de naissance, date de livraison…sont représentées dans un schéma par des propriétés
DATE
FACTURE

FACTURE

1,1 échoir
0,n NuméroFacture
NuméroFacture Date Date échéance

déconseillé

préférable
l  Modélisation de séries chronologiques

l  Le chiffre d’affaires mois par mois des clients
l  La température quotidienne d’un pays

MOIS

CLIENT

0,n
a_obtenu

Montant_CA
0,n Nom Mois
Numéro Client Année
102

Modélisation du temps
l  Historisation de propriété
l  Conserver les valeurs antérieures d’une propriété pour chaque occurrence de l’entité ou l’association
l  Historique des salaires d’un employé
HISTO-‐‑SALAIRE

EMPLOYE
0,n A_abtenu
1,1
Num Employé salaire JJ MM AA

l  Historisation d’une entité ou d’association
l  Conserver l’ensemble des valeurs antérieures de toutes les propriétés de l’entité ou de l’association

EMPLOYE (H)

Num Employé
Nom Employé
103
Adresse
Identification relative
l  Un identifiant relatif est utilisé pour une entité dont l’existence dépend totalement
d’une autre entité

CHAMBRE
HOTEL
NumChambre
Num Hotel 1,n Comporte
1,1 Surface Entité faible
Catégorie

Type
Adresse Nbr lits

104
Modélisation Logique
de Données Relationnelle
105
Modélisation Logique de Données
l  La modélisation logique des données est une représentation des données,
issue de la modélisation conceptuelle des données.
l  Elle est exprimée dans un formalisme général et compatible avec l’état de
l’art technique, et tient compte des aspects coût/performance liés aux
traitements.
l  L’élaboration du modèle logique de données (MLD) consiste à :
l  Transformer le MCD en un MLD exprimé dans un formalisme logique adapté au
SGBD envisagé
l  Quantifier en volume le modèle logique
l  Valoriser l’activité générée par les modèles externes associés aux traitements
l  Effectuer une optimisation générale
106
Modèles de Données
l  Plusieurs modèles (ou formalismes) théoriques de bases de données sont
disponibles pour représenter le MLD :
l  Modèle hiérarchique
l  Modèle réseau (ou CODASYL)
l  Modèle relationnel
l  Modèle orienté objet
107
Modèle hiérarchique
l  Les données sont organisées selon une arborescence
l  Concepts
l  Nœuds de l’arbre : entités
l  Chemins entre les nœuds : liens entre les objets
l  Les liens sont exclusivement de type 1:N
108
Modèle réseau
l  Concepts
l  Les articles : définition des entités
l  Les ensembles : association entre un article propriétaire et n articles membres
l  Un modèle réseau peut être représenté par un graphe des occurrences :
l  Les nœuds : articles
l  Les arcs : ensembles
l  Les arcs ont les noms des ensembles et sont orientés du propriétaire vers les membres.
l  Le modèle privilégie les liens 1:N et permet une représentation symétrique des liens N:M
109
Modèle relationnel
l  Concepts
l  Tables : sous-‐‑ensemble du produit cartésien de plusieurs domaines
l  Chaque élément de la table est appelé n-‐‑uplet ou tuple
l  Chaque tuple est composé de plusieurs atributs
110
Modèle orienté objet
l  Concepts
l  Les objets : structures et méthodes
l  Les classes : description de schéma, collection d’objets
l  Identité d’objet
l  Héritage
111
Modèles Logique de Données Relationnel
l  Défini par E.F. Codd en 1970 à IBM
l  Bases théoriques
l  Concepts issus de la théorie des ensembles
l  Algèbre relationnelle perme[ant de définir une collection de relations
l  Notions fondamentales
l  Domaines
l  Relations
l  A[ributs
l  Clés primaires et clés étrangères
l  Tuples (ou n-‐‑uplet)
112
Modèle Logique de Données Relationnel
l  Un domaine est un ensemble de valeurs caractérisé par un nom (entiers, dates, etc)
l  Une table (ou relation) est un sous-‐‑ensemble du produit cartésien de plusieurs
domaines
l  Les colonnes sont les a^ributs et les lignes sont les tuples
l  L’ordre des colonnes est sans importance
l  Un a[ribut prend ses valeurs dans un domaine
l  Plusieurs colonnes peuvent appartenir à un même domaine
l  On associe un nom à chaque colonne

Exemple
113
Clé primaire
l  Un ou plusieurs a[ributs perme[ent d’identifier de façon unique chaque tuple
de la table. Il s’agit de la clé primaire
l  La clé primaire d’une table est l’ensemble minimal d’a[ributs dont la
connaissance des valeurs permet d’identifier un tuple unique de la table
considérée
l  Tout a[ribut participant à la clé primaire est non NULL (NULL = valeur indéterminée)
l  La valeur de la clé primaire d’une ligne ne devrait pas changer au cours du temps
l  La clé primaire est dite simple si elle est constituée d’un seul a[ribut et composée dans le cas
contraire

114
Clé étrangère
l  Une clé étrangère est un sous groupe d’a[ributs qui doit apparaitre comme clé dans une
autre table
l  Une même table peut avoir plusieurs clés étrangères mais une seule clé primaire
(éventuellement composée de plusieurs colonnes)
l  Une clé étrangère peut être composée (c’est le cas si la clé primaire référencée est composée)
l  Implicitement chaque colonne qui compose une clé primaire ne peut pas recevoir la valeur
vide (NULL interdit)
115
Règles de passage d’un MCD à un MLDR
l  Notations
l  On dit qu’une association binaire (entre deux entités ou réflexive) est de type :
l  1,1 (un à un) si aucune des 2 cardinalités maximales n’est n
l  1,n (un à plusieurs) si une des 2 cardinalités maximales est n
l  n,m (plusieurs à plusieurs) si les 2 cardinalités maximales sont n
116
Règle 1
l  Toute entité devient une table dans laquelle les propriétés deviennent les colonnes.
l  L’identifiant de l’entité constitue alors la clé primaire de la table.
Règle 2
l  Une association binaire de type 1,n disparaît, au profit d’une clé étrangère dans la table coté
0,1 ou 1,1 qui référence la clé primaire de l’autre table. Ce[e clé étrangère ne peut pas
recevoir la valeur vide si la cardinalité est 1,1

117
Règle 3
l  Une association binaire de type n,m devient une table supplémentaire (table de jonction)
dont la clé primaire est composée des deux clés étrangères.

118
Règle 4
l  Une association binaire de type 1,1 est traduite comme une association binaire de type 1,n sauf
que la clé étrangère se voit imposer une contrainte d’unicité (ce[e contrainte d’unicité impose à
la colonne correspondante de ne prendre que des valeurs distinctes).

119
Règle 5
l  Une association non binaire est traduite par une table supplémentaire dont la clé primaire est
composée d’autant de clés étrangères que d’entités en association. Les attributs de l’association
deviennent les colonnes de cette nouvelle table.

120
Passage d’un MCD à un MLDR
Association réflexive
l  Lorsqu’une association est réflexive (*,n)-‐‑(*,1), on duplique la clé de la relation avec un nom
différent.

EMPLOYE

1,1
EMPLOYE
Matricule
Matricule
Est-‐‑ Nom
Nom chef Prénom
Prénom
Date embauche
Date embauche 0,n #Matricule_chef

l  Lorsqu’une association est réflexive (*,n)-‐‑(*,n), on créé une relation de lien ayant comme clé
une clé composée de deux fois l’identifiant de l’entité.

TRAVAIL 0,n TRAVAIL DECOMPOSE

Num travail Num travail Num travail
décomposé
Numtravailensemble
Désignation Désignation
Durée Durée
0,n
121
Passage d’un MCD à un MLDR
Spécialisation
l  Solution 1 : On exprime les sous types par des relations spécifiques,
correspondant à des associations (0,1) – (1,1)
l  Solution 2 : On duplique la totalité du contenu du sur-‐‑type dans les sous
types associés
l  Solution 3 : On duplique la totalité du contenu du sur-‐‑type dans les sous
types associés et on supprime le sur-‐‑type
l  Solution 4 : On transfère la totalité des sous types dans la table
correspondant au sur-‐‑type
Généralisation
l  Les sous types ont leurs propres identifiants.
l  Seules les transformations des solutions 1 et 2 (de la spécialisation) sont possibles
122
Exemple : voir tableau

123
Modélisation Physique
de Données
124
Modélisation Physique des données
l  Il s’agit de la formalisation opérationnelle des données
l  Spécifier comment seront réalisés les éléments du système
l  Modèle Physique des Données

Base de données relationnelles
l  Une bases de données relationnelles est un ensemble de relations

125
Modélisation Physique des données
l  La représentation standard d’une base de données relationnelle est le mode
formel :
l  Exemple
FILM(NoIdentification, NoDistributeur, Titre, AnnéeProduction, Durée, Producteur,Réalisateur, Genre)
ACTEUR-‐‑FILM(NomActeur, NoIdentification)
DISTRIBUTEUR(NoDistributeur, Nom, Adresse, Rachat)
CASSETTE(NoSérie, NoIdentification, Format)
CASSETTE-‐‑LOUÉE(NoSérie, NoBon, DateRetour)
BON-‐‑LOCATION(NoBon, NoClient, DateLocation)
CLIENT(NoMembre, Nom, Adresse, NoTél, NoCarteCrédit, MontantDépôt)
l  Une dernière étape avant l’implémentation perme[ra d’optimiser la base de
données : la normalisation
126
Exemple d’anomalies sur un modèle relationnel
l  Les principales anomalies rencontrées sont les suivantes :

l  Anomalie de mise à jour : si on doit changer une information redondante, par exemple la
durée du film, il faut changer ce[e information dans plusieurs tuples.
l  Anomalie de suppression : si un ensemble de valeurs devient vide, on peut perdre d'ʹautres
informations par effet de bord. Par exemple, si on supprime "ʺle vent se lève"ʺ, on perd comme
information que Cillian Murphy est un acteur.

Solution
127
Normalisation et Décomposition
Normalisation
l  L'ʹétude de la normalisation des relations obtenues a pour objectif
de vérifier la non redondance de données dans notre système
d'ʹinformations, et ainsi éviter certaines anomalies de stockage
dans la future implantation d'ʹune base de données.
l  Plusieurs formes normales (FN) existent :
l  1FN
l  2FN
l  3FN
l  FN de Boyce-‐‑Codd

128
Formes normales
Première forme normale (1FN)

l  Une relation est en première forme normale (1FN) si chacun de ses a[ributs
contient une valeur atomique.
l  On parle d'ʹa[ributs de relation monovalués.
l  La démarche à suivre est la suivante :
l  Sortir le groupe répétitif de la relation initiale
l  Transformer le groupe répétitif en relation, rajouter dans la clé de ce[e nouvelle relation
la clé primaire de la relation initiale
129
Formes normales
Deuxième forme normale (2FN)

l  Une relation est en deuxième forme normale (2FN) si :
l  elle est en première forme normale.
l  les a[ributs n'ʹappartenant pas à la clé primaire ne dépendent pas fonctionnellement d'ʹune
partie de la clé.
l  Les a[ributs non-‐‑clés sont en dépendance fonctionnelle pleine avec la clé.
l  Le processus est le suivant :

l  Regrouper dans une relation les a[ributs dépendant de la totalité de la clé primaire et conserver ce[e clé pour
ce[e relation
l  Regrouper dans une autre relation les a[ributs dépendant d’une partie de la clé, et faire de ce[e partie de clé la
clé primaire de la nouvelle relation
130
Formes normales
Troisième forme normale (3FN)

l  Une relation est en troisième forme normale (3FN) si:
l  elle est en 2FN
l  tout a[ribut non clé ne dépend pas fonctionnellement d'ʹun autre a[ribut non clé.
l  tous les a[ributs non-‐‑clés sont en dépendance fonctionnelle directe avec la clé.
l  Il s’agit donc d’éliminer les dépendances transitives au sein d’une relation. La
démarche est la suivante :
l  Conserver dans la relation initiale les a[ributs dépendant directement de la clé
l  Regrouper dans une relation les a[ributs dépendant transitivement. L’a[ribut de transition
reste dupliqué dans la relation initiale, et devient la clé primaire de la nouvelle relation
131
Formes normales
Forme normale Boyce-‐‑Codd

l  Une relation est en forme normale Boyce-‐‑Codd si:
l  Elle est en 3FN
l  Tout a[ribut n’appartenant pas à une clé dépend de ce[e clé entièrement et aucun a[ribut de
la clé ne dépend d’un autre a[ribut.
Ensemble. des a[ributs-‐‑clés
x x x x
x x x x
x x x
x x x x
x
x x
ensemble des attributs non clés

Cette dépendance concrétise le fait
que la relation n’est pas en
3FNBCK.
132
Formes normales
Résultat final de l‘exemple
133
Formes normales
l  Les trois premières formes normales sont les plus utilisées. Le processus de
normalisation cherche le plus souvent à obtenir des relations en troisième
forme normale.
l  Il existe certes des processus automatisés qui vont au-‐‑delà et produisent des
relations encore plus « pures » (avec 4FN et 5FN).
l  Le processus de normalisation fait intervenir des mécanismes qui agissent sur
un ensemble réduit de dépendances. Ce[e réduction est obtenue par
dérivation, par application de règles de transformation.
l  PRINCIPE : on enlève toute dépendance que l’on peut retrouver en
appliquant une série de règles de dérivation.
l  CONTRAINTE : on garde toute dépendance qui permet de retrouver une
dépendance qui a été enlevée en accord avec le principe précédent.
134
Approche de décomposition
l  On peut produire un schéma relationnel à partir de contraintes,

les principales étant les dépendances fonctionnelles.
l  Approche de décomposition

Principe
l  A partir d’une relation composée de tous les a[ributs, décomposer ce[e
relation en sous-‐‑relations sans anomalie
l  Processus de raffinement successif devant aboutir à isoler les entités et
associations du monde réel
l  Obtenir une décomposition sans perte à partir d’une bonne compréhension
des propriétés sémantiques des données
135
Algorithme de décomposition
l  La procédure de décomposition ou de normalisation est :

l  Utiliser en entrée un graphe C de DF
l  Editer les a[ributs isolés dans C
l  Réduire C
l  Tant qu’une DF n’inclut pas tous les a[ributs, faire :
§  Rechercher le plus grand ensemble d’a[ributs X tels que X → A1, …., X → An
§  Editer la relation R(X, A1, A2, ….., An)
§  Eliminer les DF figurant dans R de C
§  Réduire C
l  Editer la relation composée de tous les a[ributs restants
Exemple
l  Voir tableau
136
Quelques opérateurs de manipulation des données
l  L'ʹUNION de deux relations (définies sur les mêmes domaines) fournit une nouvelle relation qui
contient tous les n-‐‑uplets des deux relations initiales.
l  L'ʹINTERSECTION de deux relations (ayant mêmes domaines) fournit une nouvelle relation qui
contient les n-‐‑uplets communs aux deux relations initiales.
l  La DIFFERENCE de deux relations (ayant mêmes domaines) fournit une nouvelle relation qui
contient les n-‐‑uplets de la 1ère qui ne se trouvent pas dans la 2ème.
l  La PROJECTION d'ʹune relation (opérateur unaire) fournit une nouvelle relation définie pour les
seuls a[ributs demandés.
l  La SELECTION d'ʹune relation (opérateur unaire) fournit une nouvelle relation restreinte aux n-‐‑
uplets qui respectent une proposition logique formulée à l'ʹaide d'ʹopérateurs de comparaison et /
ou d'ʹopérateurs logiques.
l  La JOINTURE de deux relations (ayant un a[ribut commun) fournit une nouvelle relation
concaténant deux à deux les n-‐‑uplets des deux relations initiales ayant même valeur pour
l'ʹa[ribut commun.

137
Rétro-‐‑Conception
138
Pourquoi la rétro-‐‑conception
l  But
l  Passer d’un schéma relationnel à un schéma Entité-‐‑Association équivalent
l  Pourquoi ?
l  Analyse n’a pas été faite ou a été perdue
l  Comment ?
l  Appliquer les étapes de transformation « à l’envers »
l  Remarque
l  Ne fournit pas une solution unique (perte d’information sur le schéma
relationnel par rapport au schéma E/A)
139
Principes de la rétro-‐‑conception
l  Appliquer à l’envers les étapes de traduction :

l  Une relation ne possédant pas de clé étrangère au sein de sa clé :
l  Une entité
l  Une relation dont la clé comprend une clé étrangère et une clé "ʺlocale"ʺ :
l  Un ensemble d'ʹentité faible par rapport à l'ʹensemble d'ʹentité correspondant à la
clé étrangère
l  Une relation possédant une clé étrangère à l'ʹextérieur de sa clé :
l  Une entité plus association monovaluée vers l'ʹentité correspondant à la clé
étrangère
l  Une relation dont la clé est intégralement composée de clés étrangères :
l  Une association multivaluée entre les ensembles d'ʹentités correspondant
aux clés étrangères
140
Modélisation Conceptuelle
de Communication
141
Modèle conceptuel de communication
l  Le modèle conceptuel de communication (MCC), représente les systèmes

fonctionnels externes et internes à l’entreprise.
l  A chaque fonction correspond un objectif de l’entreprise.
l  Les échanges d’informations entre ces fonctions sont répertoriées et les informations
recensées.
l  La première étape de ce modèle est d'ʹarriver à isoler le système.
l  Il s'ʹagit donc de définir le système et les éléments externes avec lesquels il échange des flux
d'ʹinformation. Ces éléments extérieurs sont appelés acteurs externes.
l  La seconde étape consiste à découper l'ʹorganisation en entités appelées acteurs internes.
l  La dernière étape est l'ʹanalyse des flux d'ʹinformation, c'ʹest-‐‑à-‐‑dire la définition des processus.
142
Acteurs
l  Un acteur est représenté par un cercle libellé par le nom de l’acteur
l  L’acteur représente une unité active intervenant dans le
fonctionnement d’un système opérant.
l  Il peut être stimulé par des flux d’information
l  Il peut transformer et éme[re des flux d’information
l  Un acteur « fait quelque chose », il est actif
l  Exemple
l  Service comptabilité, Guichet ...
l  Un acteur est un rôle plutôt qu’une personne physique
l  Exemple
l  « Direction » et pas « Jean-‐‑Claude »
l  Il peut être pertinent de modéliser séparément deux fonctions assumées
par une même personne physique
l  On distingue les acteurs internes et externes 143
Flux d’information
l  Un flux d’information est représenté par une flèche entre deux
acteurs, étiquetée par le nom du flux
l  Echange d’informations entre deux acteurs
l  Exemple
l  documents, appels téléphoniques, données informatiques
144
Acteurs externes
l  Eléments externes avec lesquels le système échange des flux
d’information
l  Exemple
l  clients, fournisseurs...
145
Acteurs internes
l  Acteurs faisant partie du système d’information étudié

l  Ex : guichet, service informatique...
l  Si le système est complexe, on peut considérer un acteur interne
comme un sous-‐‑domaine et détailler ce sous-‐‑domaine dans un
nouveau MCC
146
Modélisation Conceptuelle
des Traitements
147
Modèle conceptuel de traitement (MCT)
l  Le MCT représente formellement les activités exercées par le

domaine
l  Il repose sur la prise en compte des échanges (flux) du domaine
avec son environnement
l  Il s’effectue en faisant abstraction de l’organisation et des choix
technologiques

La définition des interactions du domaine avec son environnement
prime sur la manière dont on assurera ces activités

l  Le résultat est un modèle conceptuel de traitements (MCT) clair,
cohérent, complet, fidèle et normalisé
148
MCT et MCC
l  Le MCT est un « zoom » sur le MCC

l  Dans les MCC, on représente les messages échangés entre
acteurs
l  Dans les MCT, on représente comment un acteur de
l’organisation réagit quand il reçoit ce message et quelle
opération il effectue
149
Modèle conceptuel de traitement
l  Une administration qui gère des demandes de promotion
l  Toute demande de promotion doit subir un examen

préalable perme[ant de déterminer si elle est recevable ou
non
l  L’examen du dossier d’une demande recevable ne peut se
faire qu’après rapport du supérieur hiérarchique
l  Après examen du dossier par l’autorité compétente, la
promotion sera accordée ou refusée
l  Les différents programmes informatiques de l’activité de

gestion des promotions
150
151
Exemple
152
Exemple : Passage du MCC au MCT
153
Principe général

154
l  Le MCT exprime ce qu’il faut faire, mais n’indique pas qui doit le
faire ni quand le faire ni où le faire (niveau organisationnel)
l  Le MCT traduit les règles de gestion du domaine étudié
l  Les principaux concepts utilisés sont :
l  L’événement / Le résultat
l  L’Opération -‐‑ La synchronisation
l  Le processus
l  L’utilisation d’un formalisme graphique
155
l  Le domaine
l  L’acteur
l  L’événement / Le résultat-‐‑message
l  L’opération
l  La synchronisation
l  Les conditions d'ʹémission
l  Le processus
156
Le domaine
l  A chaque finalité de l’entreprise est associé un domaine d’activité
l  la gestion commerciale, la gestion de la production, la gestion des ressources humaines…
l  Chaque domaine d’activité est décomposée en plusieurs fonctions
l  la gestion des ressources humaines :
l  la paie des personnels ou le déroulement de carrière
l  On représente le domaine d’activité par un diagramme de flux
l  Un flux est la représentation de l’échange d’informations entre deux activités, ou entre une
activité et un partenaire extérieur à l’entreprise
157
Le domaine
158
L’acteur
l  Un acteur est une entité organisationnelle identifiable par les

missions qu’il remplit dans le cadre du champ d’étude défini
l  Exemple 1
l  L’employé dans le domaine de la gestion des promotions
l  Exemple 2
l  L’abonné dans le domaine de la gestion des prêts de bibliothèque
159
L’évènement
l  Les flux reçus et émis par le domaine sont modélisés par des évènements
l  Un événement est la représentation d’un fait nouveau pour le S.I.
l  C’est un déclencheur d’une réaction du S.I.
l  Un évènement est accompagné d’un message, qui correspond à l’ensemble
d’informations associées au fait nouveau
160
L’évènement
événement
Il y a une facture qui vient
E1 E2 d’arriver
E3
a b c
facture
Maison PHILDEX Nantes, le 18 mai 2003
OPERXY FACTURE
message Frais de port

Total à payer
associé à E3 En votre aimable règlement.
161
L’évènement
l  Dans un MCT, on ne représente que des types d’événement
l  les évènements externes, les évènements internes et les évènements temporels
l  Un évènement temporel représente des échéances (fin de mois, chaque
jour...)
l  Un évènement externe provient de l’extérieur du champ de l’étude
(domaine)
l  Contenu du message : uniquement des informations extérieures
162
L’évènement
l  Un évènement interne est généré par le traitement du domaine
l  Deux cas possibles :
l  Vers l’extérieur du domaine
l  Vers une autre opération (chaînage interne)
l  Contenu du message : enrichi par la base d’information du domaine
externe
OPERXY
OPERYZ
interne
163
L’opération
l  L’opération décrit le comportement du domaine étudié et de son
S.I. par rapport à la survenance d’événements
l  Elle est déclenchée par la survenance des occurrences
d’événements, ou de plusieurs événements et/ou des états
préalables à l’opération
l  L’exécution de l’opération comprend l’ensemble des activités (ou
fonctions ou actions) que le domaine effectue à partir des
informations fournies par l’événement et de celles déjà connues
dans la mémoire du SI
l  L’opération est ininterruptible
l  Elle se déroule sans a[ente d’aucun nouveau événement
164
L’opération
Exemple
165
Le résultat
l  Le résultat est un évènement émis en sortie d’une opération
l  Il s’agit donc d’un évènement interne, qui peut éventuellement participer
au déclenchement d’une opération ultérieure
l  Le résultat est un message sortant du domaine en direction d’un
acteur externe ou d’un domaine connexe
166
Le synchronisation
l  La synchronisation est une condition préalable au déclenchement

de l’opération
l  Elle se traduit par une expression logique s’appliquant sur la
présence (ou l’absence) des occurrences d’événements et/ou des
états préalables à l’opération
l  Si la condition est vérifiée, l’opération peut démarrer et les
occurrences déclencheuses sont consommées par l’opération
l  Si la condition est non vérifiée, la synchronisation et les
occurrences d’événements présentes restent en a[ente jusqu’à ce
qu’elle soit vérifiée
167
Conditions d’émission
l  L’émission des résultats est soumise à des conditions traduites

par des expressions logiques
l  Plusieurs résultats de nature et destination différentes, ainsi que
plusieurs états d’objets différents peuvent être émis par une
même condition
l  L’ expression des conditions d’émission peut être considérée
comme vraie ou fausse à n’importe quelle étape du déroulement
de l’opération et plusieurs peuvent avoir la valeur «vraie» à
l’issue d’une opération
168
Le processus
l  Le processus est un enchaînement d’opérations qui concourent à

un même but, c-‐‑à-‐‑d à l’élaboration d’un ou plusieurs résultats en
réponse d’un ou plusieurs événements extérieurs au domaine
l  Il représente un sous-‐‑ensemble du domaine étudié dont les
événements initiaux et les résultats finaux délimitent un état
stable du domaine
l  Exemple
l  La gestion de bibliothèque
l  La gestion des abonnés
l  La gestion des prêts de livre
l  La gestion des achats
169
La démarche de construction d’un MCT
Les étapes de la démarche sont :

1. Déterminer le champ de l’étude
l  Définition du domaine étudié (Gestion de….)
l  Identifier les acteurs extérieurs
2. Identifier les principaux processus du domaine étudié
3. Relever et ordonnancer les flux d’informations
l  Recenser les flux entre domaine et acteurs extérieurs
l  Rechercher les relations de précédence
4. Découper chaque processus en opérations
5. Décrire chaque opération avec sa synchronisation, ses fonctions et
ses conditions d’émission
170
Exemple
l  Cas de « la Quincaillerie de la gare »
l  Identification des acteurs
l  Les acteurs internes : Magasin, Service des achats
l  Les acteurs externes : Fournisseur, Comptabilité
l  Identification des flux échangés entre les acteurs
171
l  Élaboration du graphe d’ordonnancement des flux
172
l  Élaboration du MCT
173
l  Élaboration du MCT (suite)
174
Vérification du MCT
l  Un acteur émet au moins un événement, ou reçoit au moins un
résultat
l  Un événement externe provient d’au moins un acteur
l  Un résultat provient d’au moins une opération
l  Tout résultat a au moins une destination : un acteur ou une
opération
175
Validation du MCT
l  Une expression logique associée à une synchronisation ou à

l'ʹémission d’un résultat ne peut être toujours fausse
l  Contrôler un fonctionnement cyclique
l  S’assurer que tout résultat ou état du MCT peut être produit
l  Analyser les situations de conflit
l  Un événement ou un résultat contribue à plusieurs synchronisations ou
est destiné à plusieurs acteurs
176
Affinage du MCT
l  Élimination des traitements redondants
177
Spécification du MCT
Le M.C.T. doit être composé

l  d’une ou de plusieurs représentations graphiques
l  Le modèle général des processus
l  Par processus, un schéma d’enchaînement des opérations d’une description textuelle
comprenant pour chaque opération :
l  une description succincte
l  la liste des événements contributifs et du message associé
l  la liste des états préalables à l’opération
l  les conditions de la synchronisation
l  les fonctions de l’opération
l  les résultats produits et les messages associés
l  les états résultants
l  les conditions de production de ces résultats
178
Spécification du MCT
l  Une description type d’opération

179
Modélisation Organisationnelle
des Traitements
180
Modèle Organisationnel des Traitements (MOT)
l  Le Modèle Organisationnel des Traitements (MOT) décrit

l’organisation des traitements du système étudié. Il consiste à
répondre aux questions suivantes :
l  Qui fait quoi ? Avec quelles ressources ?
l  Quand fait-‐‑on les traitements ?
l  D'ʹoù exécute-‐‑t-‐‑on les traitements ?
l  Le MOT représente les « opérations » du MCT sous une forme
détaillée, puisque l'ʹorganisation interne de l'ʹentreprise est ici
prise en compte.
l  Chaque opération du MCT se trouve donc subdivisée en
« procédures fonctionnelles » (PF) qui sont, elles aussi,
initerruptibles.
181
Modèle Organisationnel de Traitement (MOT)
MOT = MCT + lieu + moment + nature

l  Lieu
l  Qui exécute ? Acteurs (MCC)
l  Moment
l  Quand exécute-‐‑t-‐‑on l’opération ?
l  fréquence (jour, mois,…), dates au plus tôt et au plus tard, temps moyen
l  Nature
l  Manuelle
l  Automatique ou Différé
l  Temps Réel ou Interactive ou Conversationnel
182
Concepts de base
l  Un poste de travail est une entité physique comprenant des ressources sur un
lieu donné.
l  Les ressources d’un poste de travail sont les moyens matériels et humains
dont le poste doit être muni pour qu’une tâche puisse y être exécutée.
Ce sont essentiellement :
l  les intervenant
l  les moyens d’entrée et de sortie informatiques
l  les moyens de traitement des données (ordinateurs, micro, etc. …)
l  les logiciels
l  les ensembles de données stockées utilisées
l  Une procédure (ou procédure fonctionnelle, PF) est un ensemble logique de
tâches exécutées consécutivement par un poste de travail . Elle est
ininterruptible
l  Une tâche est une unité élémentaire de traitement. Elle résulte de la décomposition
organisationnelle de l'ʹopération conceptuelle. Elle est effectuée par un poste de travail.
183
Concepts de base
l  La périodicité (ou fréquence) est la période d’exécution d’une tâche sur un
poste de travail. Ce[e indication répond à la question QUAND ?
l  La périodicité définit l’instant (aléatoire, périodique régulier, périodique irrégulier, plage de
temps, calendaire, etc.…) de déclenchement d’une tâche.
l  Les acteurs (ou intervenants) sont les personnes exécutant une procédure et
faisant partie d’un poste de travail.
l  Le degré d’automatisation est l’information qui décrit la nature de la tâche.
L'ʹexécution d'ʹune tâche utilise des ressources humaines et informatiques. On
distingue, pour exécuter une tâche, la manière :
l  manuelle : le traitement est réalisé par une ressource humaine
l  conversationnelle : l'ʹexécution de la tâche est réalisée par un dialogue entre l'ʹhomme et la
machine grâce à une interface homme-‐‑machine (IHM). On parle aussi de tâche interactive ou
en temps réel
l  automatique : l'ʹexécution de la tâche est réalisée grâce à l'ʹinformatique seule par une procédure
automatisée et autonome. On parle de procédure en temps différé ou de procédure batch
184
Correspondance entre MCT et MOT
Agrégation d’opérations en une procédure
B C
A B C
B ou C
B ou C
Opération 1
•  Action 1
A D PF •  Action 2
A et D
Opération 2
Résultat
Résultat
Niveau Conceptuel Niveau Organisationnel
185
Composition d’une opération en plusieurs procédures
PF1
Opération 1
PF2

l  Pour quels raisons doit on décomposer :
l  La tâche (ou action) doit être effectuée de plusieurs façons différentes
§  Manuel, temps réel ou différé
§  A chaque nature de travail correspond une procédure différente
l  Changement de lieu, de personne (poste de travail)
l  Introduction d’un évènement spécifique au niveau organisationnel : délai
186
Correspondance Opération/Procédure
l  Chaque opération est effectuée dans un seul poste de travail, avec une seule nature de
traitement. Il ne lui correspond qu’une seule procédure
Opération 1 PF1 Procédure 1
187
Démarche de passage du MCT au MOT
l  On étudie pour toutes les actions d’une opération du MCT :
l  Lieu du traitement : si plusieurs lieux existent, l’opération devra être
découpée en autant de procédures
l  Chronologie : si des actions ne peuvent se dérouler consécutivement, il y
aura lieu de faire plusieurs procédures
l  Nature ou type : différée, manuelle, temps réel
188
Etapes de construction d’un MOT
Les étapes de la construction d’un MOT sont :

l  Décomposer les opérations du MCT en sous-‐‑opérations appelées
procédures fonctionnelles
l  Affecter et localiser chaque procédure
l  Détailler l'ʹanalyse de chaque procédure
l  Définir l'ʹenchaînement des procédures
189
Décomposition des opérations du MCT

l  Pour chaque opération du MCT, il faut au préalable vérifier l’exhaustivité du
recensement des tâches.
l  Regrouper les tâches de l’opération en procédures. Il s’agit de veiller au
respect des trois unités : lieu, temps, nature de traitement
l  Exemple
l  L'ʹopération Ouvrir_dossier peut être décomposée en les procédures
suivantes :
l  vérifier la déclaration (assuré connu, circonstances bien décrites ...)
l  l'ʹignorer ou lui affecter un numéro de dossier
l  enregistrer les informations nécessaires dans la base
l  désigner un expert pour le nouveau dossier
l  transme[re le dossier à l'ʹexpert 190
Identification des procédures

l  Il s’agit, tout particulièrement, de spécifier pour chaque
procédure son type et son poste de travail.
l  Pour chaque procédure sont fournis :
l  Un nom
l  Un mode de réalisation (manuelle, automatisée totalement ou
partiellement, interactive, différée ...)
l  Une localisation (où?)
l  Une affectation (qui?)
l  Une fréquence d'ʹactivation
191
Identification des procédures (suite)

l  Exemple
192
Analyse détaillée des procédures

l  Décrire :
l  les événements ou données nécessaires au déclenchement de la procédure
et les résultats qu'ʹelle produit
l  les traitements effectués et les actions réalisées sur la base
l  les supports des données et des résultats (formulaire papier, écrans de
dialogue etc.)
193
Enchaînement des procédures

l  Exemple de formalisme du MOT
Temps Enchaînement des procédures Nature Poste
date début Date de dossier

inscription début
et
déposé Manuelle Guichet

PF1 Vérifier dossier
5'ʹ
erreur correct
dossier dossier
incomplet complet

TR Guichet

PF2 saisie élts dossier
3'ʹ toujours

dossier
enregistré
Manuelle Guichet
PF3 écriture n° inscript.

3'ʹ classement par couleur

toujours
194
dossier
trié
l  Il est intéressant, pour la compréhension du MOT, d'ʹindiquer le
support du flux d'ʹinformations ou de l'ʹévénement mentionné :
l  Pour les tâches issues de procédures TR (temps réel), il faut décrire des
écrans
l  Pour les tâches éditant des états, décrire les maque[es d’états
l  Pour les tâches automatique, il faut donner les segments de données
accédés en consultation, modification, ajout ou suppression et préciser les
critères d’accès.
l  Ce[e étape est formalisée par une fiche descriptive pour chaque
PF.
l  Les fiches descriptives peuvent être aussi créées pour les postes
de travail.
195
l  Exemple d’une fiche descriptive d’un PF
n° procédure : PF6
Libellé : Saisie note
Nature : TR
Evénements traités : " retour dossier noté "
Evénements résultants : " notes saisies "
Volume : 2 000 * 2 j = 4 000
Durée : 3' * 4 000 = 12 000' = 200 h
Actions sur la BD : Segment dossier en MAJ 196
Segment Enseignant en MAJ

Conclusion
l  Le MOT cerne l'ʹactivité de chaque poste de travail (informatique ou non), et
de chaque service, en tenant compte du "ʺplanning"ʺ, du type de ressources
(manuel, automatisé), du type de support (document écrit, magnétique etc.)
l  Ce[e représentation est donc détaillée et très concrète, et les symboles
graphiques utilisés peuvent être influencés par le contexte.
l  Les fiches descriptives qui doivent accompagner chaque PF détaillent les
règles de synchronisation et d'ʹémission. Elles constituent donc une première
ébauche des algorithmes essentiels pour les PF appelées à être informatisées
197
Inscription à un établissement Universitaire : Exercice MOT
Consignes d ’organisation : Informatique centralisée . à faire :

Travail
- tableau de détermination des procédures
l  . Les candidats déposent les dossiers à un guichet de - M.O.T.
réception qui vérifie leur contenu et les enregistrent sous un - Fiche descriptive de la PF « saisie des notes »
numéro d ’inscription s ’ils sont complets. Il transmet tous les
soirs les dossiers à chaque département ( tri par couleur de
la chemise ).
MCC Dossier déposé
l  Tous les matins le secrétariat de chaque département
Refus notifié
reçoit les dossiers et les répartit par paquet de dix. Ceux-‐‑ci
sont ventilés vers les enseignants qui ont deux jours pour les Avis d ’admissibilité envoyé
examiner et donner une note. Le secrétariat saisit alors
Avis d ’admission définitif
chaque note , puis ventile les dossiers vers d ’autres Inscription
enseignants de façon à obtenir une deuxième notation qui est Candidat
à son tour saisie.
à un Collante reçue
établissementDemande d ’inscription déposée
l  Chaque fin de semaine pour les dossiers possédant 2
notes , la moyenne est calculée et un écart supérieur de 2 universitaire
Avis d ’inscription envoyé
points entre les deux notes fait sortir les dossiers en
anomalie. Celui-‐‑ci doit être examiné de nouveau jusqu’à Dossier refusé déposé trop tard
obtenir un consensus.

dossier Avis
l  A la date de clôture des dossiers , le secrétariat envoie les Refus déposé
notifié admissibilité
réponses aux candidats : ceux qui ont une moyenne envoyé
supérieure à 10 reçoivent une letre d ’admissibilité , les
autres une letre de refus. Les candidats déjà bacheliers ayant dossier
la moyenne reçoivent une letre d ’admission définitive ( = refusé Collante
demande d’inscription ). reçue
ou
Graphe de Précédence
l  Les candidats admissibles apportent leur « collante » au Avis
secrétariat qui enregistre leur réussite au bac et leur donne Evénements temporels d ’admission
définitive
une demande d ’inscription portant le même numéro que le D1 : date début période dépôt dossier
D2 : date fin période dépôt dossier
dossier. D3 : date clôture inscriptions
l  Les candidats doivent alors payer leurs droits à la caisse avis demande
d ’inscription d ’inscription
de l ’établissement et y déposer leur demande d ’inscription
envoyé déposée
correctement remplie. Leur inscription est alors définitive
Dossier
Date de déposé
Exercice MOT : début
Inscription Universitaire
et
Examen dossiers
avis
accepté admissibilité
date collante
TJ clôture
refusé
bac bac
et
dossier
refusé
date Admission
refus définitive
notifié
toujours
avis admission
définitive
demande Date de
inscription clôture
inscription
et
et
clôture
inscription inscriptions
toujours
toujours
avis
candidat
d'ʹ inscription
forclos

9 C 8213 D 79619

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

9 C 8213 D 79619

Uploaded by

Copyright:

Available Formats

Analyse et Conception des

§ Approfondir la méthode MERISE

Démarche « très théorique »

analyse du problème conception de la solution

Analyser Concevoir Réaliser

Besoins Méthode Analyse

Eléments en entrée Système Eléments en sortie

l Un système opératoire qui réalise les tâches

l Un système d’information qui sélectionne les informations pertinentes

Système de Décision

réﬂéchi, décide, contrôle

Bases de données Interfaces utilisateurs

Réseaux et systèmes Systèmes distribués

Besoin de méthodes pour la construction d’un SI

l Une méthode déﬁnit un processus d’informatisation, possède

Composants d’une méthode de construction d’un S.I.

Outils et techniques langages

Composants d’une méthode

utilisateurs grâce à des modèles du problème (modèles

(modèles de conception).

Modèle pour touriste

Modèle pour technicien

l ténacité et rigueur

l Approche ancienne :

l Merise est une méthode d’analyse et de conception

l Décrire le QUOI indépendamment de toute contrainte

l Exprimer les choix organisationnels de ressources

Exemples d’éléments organisationnels

l Le COMMENT FAIRE. Le logiciel de développement

l Pour étudier et développer l’informatique d’une

l Modèle E/A

L564 Les misérables V. Hugo

par des organismes oﬃciels (n° INSEE)

Une association a pour identiﬁant la concaténation des identiﬁants des

l Les dépendances fonctionnelles

Num Client détermine Catégorie Client

l L’approche ascendante se déroule en plusieurs étapes :

l Graphe de dépendances fonctionnelles

l Construction du GDF

NOMREP NOMCLI RUECLI VILLECLI

NOMREP NOMCLI RUECLI VILLECLI

NOMREP NOMCLI RUECLI VILLECLI 77

En règle général, le système doit produire des documents

Une fois positionnée dans une entité, une information

(Entité A, Entité B)

l Une CIF sur une association ternaire

l Modélisation de séries chronologiques

l Modèle hiérarchique

l Modèle réseau (ou CODASYL)

l Modèle relationnel

l Modèle orienté objet

Modèle orienté objet

l Les principales anomalies rencontrées sont les suivantes :

Première forme normale (1FN)

Deuxième forme normale (2FN)

l Le processus est le suivant :

Troisième forme normale (3FN)

Forme normale Boyce-­‐‑Codd

Ensemble. des a[ributs-­‐‑clés

ensemble des attributs non clés

Résultat ﬁnal de l‘exemple

l On peut produire un schéma relationnel à partir de contraintes,

l La procédure de décomposition ou de normalisation est :

§  Approfondir la méthode MERISE

l  Un système opératoire qui réalise les tâches

l  Un système d’information qui sélectionne les informations pertinentes

l  Une méthode déﬁnit un processus d’informatisation, possède

l  ténacité et rigueur

l  Approche ancienne :

l  Merise est une méthode d’analyse et de conception

l  Décrire le QUOI indépendamment de toute contrainte

l  Exprimer les choix organisationnels de ressources

l  Le COMMENT FAIRE. Le logiciel de développement

l  Pour étudier et développer l’informatique d’une

l  Modèle E/A

l  Les dépendances fonctionnelles

l  L’approche ascendante se déroule en plusieurs étapes :

l  Graphe de dépendances fonctionnelles

l  Construction du GDF

l  Une CIF sur une association ternaire

l  Modélisation de séries chronologiques

l  Modèle hiérarchique

l  Modèle réseau (ou CODASYL)

l  Modèle relationnel

l  Modèle orienté objet

l  Les principales anomalies rencontrées sont les suivantes :

l  Le processus est le suivant :

Forme normale Boyce-‐‑Codd

Ensemble. des a[ributs-‐‑clés

l  On peut produire un schéma relationnel à partir de contraintes,

l  La procédure de décomposition ou de normalisation est :

l  Appliquer à l’envers les étapes de traduction :

l  Le modèle conceptuel de communication (MCC), représente les systèmes

l  Acteurs faisant partie du système d’information étudié

l  Le MCT représente formellement les activités exercées par le

l  Le MCT est un « zoom » sur le MCC

l  Une administration qui gère des demandes de promotion

l  Toute demande de promotion doit subir un examen

l  Les diﬀérents programmes informatiques de l’activité de

l  Un acteur est une entité organisationnelle identiﬁable par les

l  La synchronisation est une condition préalable au déclenchement

l  L’émission des résultats est soumise à des conditions traduites

l  Le processus est un enchaînement d’opérations qui concourent à

l  Élaboration du graphe d’ordonnancement des ﬂux

l  Élaboration du MCT

l  Élaboration du MCT (suite)

l  Une expression logique associée à une synchronisation ou à

l  Élimination des traitements redondants

l  Une description type d’opération

l  Le Modèle Organisationnel des Traitements (MOT) décrit

l  Détailler l'ʹanalyse de chaque procédure

l  Déﬁnir l'ʹenchaînement des procédures