SYSTEME D`INFORMATION METHODE MERISE

http://www.fsjes-tanger.com
https://www.facebook.com/FSJES.SAADI
SYSTEME D’INFORMATION
METHODE MERISE
FSJES Année 2012/2013
1
http://www.fsjes-tanger.com
https://www.facebook.com/FSJES.SAADI
Notion de Système
Apparue dans les année 1970, l’analyse systémique considère
l’entreprise non plus comme une addition de services mais
comme un système
Un système est un ensembles d’éléments (des moyens Humains
, Financiers et techniques) en interrelations.
2
http://www.fsjes-tanger.com
https://www.facebook.com/FSJES.SAADI
Notion de Système d’Information SI
Le système d’Information de gestion est un ensembles
de moyens et procédures utilisés en vue de restituer
aux utilisateurs une information directement utilisable
en
bon
moment.
3
http://www.fsjes-tanger.com
https://www.facebook.com/FSJES.SAADI
SI d'une organisation
•Éléments : employés, machines, règles
•But : Stocker et traiter des informations relatives au système
opérationnel pour les mettre à disposition du système
de pilotage.
Objectifs
Variables
Essentielles
Fixe
Système Pilotage
Entrées
Système opérationnel
Sorties
4
Système D’information
A- Sous-Système OPÉRANT
 Assure le fonctionnement du système en réalisant la production physique de
l’entreprise.
B- Sous-Système De Décision (de Pilotage)
 Permet d’assigner des objectifs à l’entreprise(système) et est relié aux autres soussystèmes par des flux d’information .
 Analyser l’environnement et le fonctionnement interne de l’entreprise pour produire
des décision .
 Contrôler l’exécution des taches du sous-système opérant et assure la régulation du
système en concevant des solutions aux problèmes .
C- Sous-Système D’Information
Alimente l’entreprise en informations (d’origine interne ou à partir de l’environnement),
 Mémorise les informations, les traité et les communiqué aux autres sous-système
auxquels il est relié .
5
6
Entreprise
Système Décision
Information
décision à
mémoriser
Information
Mémoriser
Système Information
Information
Mémoriser
Information
représentation à
mémoriser
Système Opérant
Entrées
Sorties
Positionnement du Système d’information
7
Aspects du SI
Statiques : Mémoire de l'organisation
•Enregistrement des faits : base d'information
•Enregistrement des structures de données, règles, ...
Modèle des données
Dynamiques
•M à J des données
•Changement de règles, structures et contraintes de l'U. ext.
•Processeur d'informations
8
Qualités du SI
Rapidité : l’utilisateur doit obtenir l’information rapide pour réagir au
plus vite.
Fiabilité : exemple Pour commander un article il faut connaître l’état
du stock : Mise à jour Automatique du Stock.
Pertinence : l’information doit être filtrée en fonction de l’utilisateur.
9
Fonctions du SI
1- Collecte de l’information
2- Saisie de l’information sur un support (papier ou informatique)
3- Calcul et tri (exemple tri de commande par date – calcul des
factures d’un client )
4- Mémorisation en vue d’une utilisation ultérieur
5- Diffusion de l’information aux différents utilisateurs en tenant
compte de la confidentialité.
10
10
Objectif d'une méthode ?
• Exprimer clairement le cahier des charges dans un langage qui permette une
bonne spécification des besoins en étant compréhensible par l'utilisateur
•Décrire clairement le nouveau système et ses implications pour un bonne
réalisation
Méthode MERISE
Méthode MERISE
Contexte d'apparition de MERISE
1972-1975 : Création de la méthode par les chercheurs
français MOULIN, TARDIEU et TEBOUL
1976 : Il a été rendu célèbre dans le monde entier par l'américain
Peter CHEN, à la suite d'une publication intitulée "The
Entity-Relationshionship Model" (ACM, Transaction on
Database Systems)
A ce jour tous les spécialistes du domaine de l'analyse orientée
base de données se servent de ce modèle comme outil de communication
des applications SGBDR (ACCESS, PARADOX, ORACLE, SQL Server…)
11
11
Démarche de la méthode
Système d’information manuel
Expression des besoins
- Cahier de Charge
- Dictionnaire de données
Modèle conceptuel des données
Modèle logique
Modèle physique
Système d’Information automatisé
12
12
Le Modèle Conceptuel de données ( MCD )
Formalisme = Modèle Entité-Association
développé par CHEN aux U.S.A ( 1976 )
puis TARDIEU en France ( 1979 )
Exemple :
0,N
Commander
Qté commandée
COMMANDE
1,N
N° Commande
Date Commande
1,1
PRODUIT
Ref-Produit
Désignation
Prix-unitaire
Passer
commande
1,N
CLIENT
Code-Client
Nom-Client
13
Notion d’ENTITE
14
Entité = Représentation d’un objet concret ou abstrait
du S.I caractérisé par :
* des propriétés ( attributs ) : P1, P2, P3, …..Pn
* un identifiant = Propriété ( P1 ) dont les valeurs
sont discriminantes
* des occurrences ( instances ) multiples
( au moins 2 )
Etudiant
Exemple
Etudiant
Etudiant
125
N° Inscription
918
ALAMI
Nom
DAOUDI
DRISS
Prénom
MOUNIR
MAROCAINE
Nationalité
Nom Entité
P1
P2
Pn
Etudiant
235
SEBASTIEN
ALBERT
FRANCAISE
MAROCAINE
Une occurrence
d ’entité = 1 jeu de valeurs prises par les
propriétés de l’entité
15
Notion d’ASSOCIATION
Une Association traduit les liens sémantiques existant entre 2 ou
plusieurs entités du S.I et de son environnement
Elle est caractérisée par :
* des occurrences ( au moins une )
* des propriétés portées ( nombre M ) M = 0, 1, 2, 3, …
* une dimension N ( N = nombre d ’entités rattachées )
* un identifiant obtenu par concaténation des identifiants
des entités rattachées
Exemple
Véhicule
N° Immatr.
Loué par
Salarié
Matricule
Nom
N° Client
Nom
Date mise en service
Kilométrage
Client
Association binaire non
porteuse d’identifiant
(N°Immatr.+N° Client )
Affecté à
Date affect.
Adresse
Service
N° Service
Désignation
Association binaire porteuse d ’1 propriété ( Date Affect ) et d’identifiant ( Matricule.+ N° Service )
Occurrences d’association
SALARIE
SERVICE
A01
IDRISSI
SALARIE
A12
ALAMI
SALARIE
A05
RAMI
SALARIE
A09
DAOUDI
16
18/05/92
125
Comptabilité
SERVICE
11/10/91
04/03/93
124
Commercial
SERVICE
106
Magasin
* A01-125 , A12-125 et A05-106 sont des instances
de l ’association « Affecté à »
* Les instances A09 ( entité Salarié ) et 124 ( entité Service )
ne participent pas à l’association « Affecté à »
Cardinalités d ’une ASSOCIATION
17
Cardinalités = Couple de valeurs représentant la fréquence (mini et maxi )
de participation d’une occurrence d ’entité à une association )
Entité 1
i1 , j1
Entité 2
Association
i2 , j2
i1 , i2 = cardinalités mini
j1 , j2 = cardinalités maxi
Exemple
Salarié
Matricule
Service
1,N
Affecté à
Date affect.
1,8
N° Service
Désignation
Nom
Règles de gestion :
RG1 - Un salarié est affecté à un et ou pls services le long de sa carrière
RG2 - A un service , on peut affecter un à plusieurs salariés (maximum 8)
Cardinalités d ’une Association ( Interprétations )
E1
E2
E1
Assoc
Assoc
0,1
E1
1,1
Assoc
0,N
1,1
E2
E2
1,1
E1
18
E2
Assoc
1,1
0,N
Cardinalités mini :
0 : Certaines occurrences de l’entité peuvent ne pas participer à l’assoc
1 : Toute occurrence de l’entité participe obligatoirement à l’association
Cardinalités maxi :
1 : Toute occurrence de l’entité participe au plus une fois à l’association
N : Toute occurrence de l’entité peut participer plusieurs fois à l’assoc
1,N
Conclusion
* La cardinalité mini traduit la capacité d ’une occurrence à exister indépendamment
ou non des occurrences de l’association
* La cardinalité maxi traduit la capacité associative de l’association pour l’entité
considérée
19
Identifiant d’une Association
Il est obtenu par concaténation des identifiants des entités reliées par l’association
Employé
Exemple :
N° Employé
Nom Employé
Nom Employé
Adresse Client
Médecin
0,N
Visiter
Date Visite
0,N
N° Médecin
Nom Médecin
Spécialité
Téléphone
Identifiant = ( N° Employé , N° Médecin )
Occurrences de « Visiter »
N° Employé
23
12
39
42
42
42
N° Médecin
1
3
2
1
4
4
Date Visite
26/06/01
05/07/01
10/08/01
15/08/01
22/08/01
05/09/01
La dernière occurrence de l’association « Visiter » n’est
pas permise en raison de la discriminance de l’identifiant .
La duplication de l’occurrence ( 42 , 4 ) n’est pas possible !
!!!!
Question : Un employé peut-il effectuer plusieurs visites chez le même médecin à des dates différentes ?
Réponse : Ce modèle ne le permet pas même si la propriété « Date Visite » est portée par l’association « Visiter »
20
Identifiant d’une Association ( Suite )
Solution du Problème : Association ternaire
Employé
Identifiant de l’association
« Visiter » :
N° Employé
Nom Employé
Nom Employé
Adresse Client
( N° Employé , N° Médecin , Date )
Médecin
0,N
Visiter
0,N
0,N
N° Médecin
Nom Médecin
Spécialité
Téléphone
Calendrier
Date
Les triplets ( 42 , 4 , 22/08/01 ) et ( 42 , 4 , 05/09/01 ) sont maintenant des occurrences possibles de
l’association « Visiter » car elles représentent des valeurs distinctes de son identifiant .
Ce modèle permet , à l’inverse du précédent , de représenter le fait qu’un employé peut visiter le même
médecin plusieurs fois à des dates différentes .
Généralisation : Une association N-aire ( de dimension N ) possède un identifiant sous forme de
N-uplet dont les valeurs sont distinctes .
Comment interpréter les cardinalités d’une association ternaire ?
( i2 , j2 )
Exemple : Association ternaire
Employé
( i1 , j1 )
• Identification de ( i2 , j2 )
Pour un médecin fixé ( occurrence M ) , le couple de
cardinalités ( i2 , j2 ) traduit le nombre minimal
et maximal d’occurrences du couple d’entités
( Employé , Calendrier ) qui sont associées à
l’occurrence M .
Ici : ( i2 , j2 ) = ( 0 , 4 )
• Identification de ( i3 , j3 )
Médecin
Visiter
( i3 , j3 )
• Identification de ( i1 , j1 )
Pour un employé fixé ( occurrence E ) , le couple de
cardinalités ( i1 , j1 ) traduit le nombre minimal
et maximal d’occurrences du couple d’entités
( Médecin , Calendrier ) qui sont associées à
l’occurrence E .
Ici : ( i1 , j1 ) = ( 0 , 3 )
21
Calendrier
N° Employé ( N° Médecin , Date Visite )
1
1
1
3
4
4
5
( 12 , 08/05/01 )
( 10 , 15/06/01 )
( 6 , 09/06/01 )
( 10 , 02/06/01 )
( 12 , 14/06/01 )
( 10 , 14/06/01 )
( 10 , 02/06/01 )
N° Médecin ( N° Employé , Date Visite )
12
10
6
10
12
10
10
En raisonnant de même pour ( i3 , j3 ) on trouve : ( i3 , j3 ) = ( 0 , 2 )
( 1 , 08/05/01 )
( 1 , 15/06/01 )
( 1 , 09/06/01 )
( 3 , 02/06/01 )
( 4 , 14/06/01 )
( 4 , 14/06/01 )
( 5 , 02/06/01 )
Occurrences
de « Visiter »
22
Rôles dans une Association
Rôle = Notion précisant le rôle particulier joué par un ensemble d’occurrences
relatives à une entité dans une association. Les rôles sont portés sur le
schéma Entité-Association.
Exemple 1
Livrer
Nbre colis livrés
0,N
CLIENT
Code Client
Nom client
Adresse client
Dépôt
expéditeur
Dépôt
D1
D3
D1
Dépôt
destinataire
D2
D4
Dépôt expéditeur
DEPOT
0,N
Recevoir
Dépôt destinataire
Nbre colis reçus
0,N
Code dépôt
Adresse dépôt
0,N
Client Nbre colis livrés Nbre colis reçus
C6
1
C2
2
C9
2
C2
C6
-
5
4
Occurrences de l’association
« Livrer »
Occurrences de l’association
« Recevoir »
23
23
Règles de gestions
Contraintes d'intégrité du modèle (lois de l'univers réel modélisé dans le SI)
Contraintes statiques
Portent sur :
- une propriété (liste de valeurs possibles ...)
- plusieurs pptés d'une même relation ou entité
cde(no,date-cde,date-livr) avec date-cde < dte-livr
- les cardinalité
- les dépendances fonctionnelles
Contraintes dynamiques : règles d'évolution
ex: un salaire ne doit pas baisser
24
24
Exemple
RG1 : Tout enseignant enseigne en principe au moins une matière, mais certains d’entre
eux peuvent être dispensés d’enseignement en raison de leur travaux de recherche
RG2 : Toute matière est enseignée dans au moins une classe
RG3 : Toute classe a au moins trois enseignements
1,n
ENSEIGNANT
0,n
ENSEIGNE
MATIERE
3,n
CLASSE
Notion de Dépendance Fonctionnelle
Définition : 2 propriétés A et B sont en DF si la connaissance d’une
valeur de A détermine une et une seule valeur de B. On dit que A
détermine fonctionnellement B .
Formalisme :
A
( A, B, …)
A
Exemples :
B
: 1 source , 1 but
X
: plusieurs sources , 1 but
( X, Y, …)
: 1 source , plusieurs buts
N° Client
Nom Client
Nom Client
N° Client
Prénom Client
N° Client
( Réf-prod , N° Commande )
Réf-prod
( pas de DF )
( pas de DF )
Qté prod. commandée
( Libellé prod. , Prix unit. Prod. )
25
25
DEPENDANCES FONCTIONNELLES
1 - Cas d’une Entité
CLIENT
Code Client
Nom
Prénom
Code Client
Adresse
Nom
Téléphone
Prénom
Adresse
Code Client
( Nom , Prénom , Adresse , Téléphone )
Téléphone
Toutes les Propriétés d’une Entité sont en dépendance fonctionnelle directe
avec la propriété identifiante de cette Entité
26
27
DEPENDANCES FONCTIONNELLES
2 - Cas d’une Association hiérarchique ( monovaluée )
CLIENT
COMMANDE
1,1
N° Commande
PASSER
0,N
Code Client
Nom
Date Commande
Adresse
Montant
DF représentant l’assoc.
N° Commande
Code Client
Nom
Adresse
Montant
Date Commande
Occurrences de « PASSER »
N° Commande
1
2
3
4
5
6
Code Client
4
9
4
6
2
4
Téléphone
Une Association Hiérarchique est une association binaire (dimension =
2) dont l’une des pattes possède une Cardinalité Maxi égale à 1 .
Ce type d’association est toujours orienté suivant le sens de la
dépendance fonctionnelle qui relie les identifiants de ses Entités .
Remarque : La dépendance fonctionnelle Code Client --->
N°Commande
n’existe pas car un Client peut passer plusieurs commandes
( exemple du Client N° 4 )
28
28
Graphe de Dépendances Fonctionnelles
GDF = Représentation graphique de l’ensemble des DF unissant les
propriétés dans un domaine d’activité du système d’information . Ces
propriétés sont obtenues à partir du dictionnaire de données du domaine .
Exemple :
GDF du domaine « Gestion commerciale » dans une entreprise
Date
N° Client
N° Produit
Libellé
produit
N° Catégorie
Nom
Client
Adresse
Client
Tél.
Client
Libellé
catégorie
Qté prod.commandée,
Mont. ligne commande
N° fournisseur
Nom
fournisseur
Adresse
fournisseur
Prix achat
produit
Le Modèle Logique de Données Relationnel ( MLDR )
Ce modèle permet de constituer une base de données au sens logique au moyen de
tables désignées aussi sous le terme de relations .
Les Concepts du MLDR
1 ) L’attribut : C’est le plus petit élément d’information enregistré dans une base de données .
Il possède un nom et prend des valeurs dans un domaine de valeurs bien déterminé .
Exemples :
Attribut
Domaine de valeurs
N° Client
Adresse Client
Mode de paiement
Entier naturel
Alphanumérique
Liste alphabétique (Espèces,Chèque ,Traite)
2 ) La Relation : Une relation ( appelée aussi table ) est un ensemble d’attributs significativement
associés ( dont l’association a un sens au niveau du S.I ) .
Représentation d’une relation :
R ( A1, A2 , A3, …….., An ) Représentation en intention
ou Schéma de la relation
R
tuple 1
tuple 2
…….
tuple n
A1
A2
A3
…..
An
……… …….. …….. ….. ………
valeur valeur valeur ….. Valeur
…….. …….. …….. ….. ……..
…….. ……… …….. ….. ……..
Représentation en extension
( montrant les tuples de la relation )
R : Nom de la relation
A1, A2 , …., An : Attributs de la relation
29
29
Le Modèle Logique de Données Relationnel ( suite 1)
3 ) Les Contraintes d’Intégrité :
Elles représentent un ensemble de règles fondamentales dont l’application permet de garantir
la cohérence du schéma relationnel d’une base de données .
Ces règles contrôlent la cohérence des valeurs prises par :
* les attributs par rapport à leur domaine de valeurs (contrainte d’intégrité de domaine)
Exemple : Si l’attribut ‘ N° Client ’ est défini sur un domaine de valeurs numériques , il ne
peut pas contenir de lettres .
* les clés primaires des relations ( contraintes d’intégrité de relations )
L’intégrité de relation concerne les valeurs d ’une clé primaire qui doivent être uniques
( pas de doublons ) et non nulles ( toujours spécifiées ) .
* les clés étrangères des relations ( contraintes d’intégrité référentielles )
L’intégrité référentielle stipule qu’une clé étrangère ne peut prendre que les valeurs définies dans
le domaine primaire de la clé primaire à laquelle elle est associée .
30
30
Règles de passage du MCD au modèle relationnel
Le MLDR est construit à partir du MCD en appliquant des règles de transformation simples
aux entités et aux associations .
1 ) Règle 1: entité est représentée par relation ou table
ENTITE A
Identifiant Ao
Propriété A1
Propriété A2
Propriété A3
Relation ou table A
Ao A1 A2 A3
Clé
Une entité A du MCD devient la relation ( ou table ) : A ( Ao# , A1 , A2 , A3 )
31
32
32
Règle de passage du MCD au modèle relationnel
2) Règle 2 : Association multivaluée plusieurs [ 0, N ou 1, N ] à plusieurs [ 0, N ou 1, N ]
ENTITE B
ENTITE A
Identifiant Ao
Propriété A1
Propriété A2
Propriété A3
*,N
Association
Identifiant Bo
Propriété B1
Propriété B2
*,N
Représentation graphique du MLDR
Relations obtenues :
A , B et C
A ( Ao# , A1 , A2 , A3 )
B ( Bo# , B1 , B2 )
C ( Ao# , Bo# )
A
Ao #
A1
A2
A3
C Ao
#
Bo #
B
Bo #
B1
B2
Règle de passage du MCD au modèle relationnel
3) Régle 3 : Association hiérarchique Un [ 0, 1 ou 1, 1 ] à Plusieurs [ 0, N ou 1, N ]
ENTITE B
ENTITE A
Identifiant Ao
Propriété A1
Propriété A2
*,1
Association
Propriété C
*,N
Identifiant Bo
Propriété B1
Propriété B2
La clé primaire Bo # migre dans la relation A comme attribut clé étrangère ou externe .
Représentation graphique du MLDR
Relations obtenues :
A,B
A ( Ao# , A1 , A2, Bo#,C ... )
B ( Bo# , B1 , B2 , ...)
A
B
Ao #
A1
A2
Bo #
C
Bo #
B1
B2
33
33
Règle de passage du MCD au modèle relationnel
4) Règle 4 : Association hiérarchique Un [ 0, 1 ou 1, 1 ] à Un [ 0, 1 ou 1, 1 ]
ENTITE A
Identifiant Ao
Propriété A1
Propriété A2
Relations obtenues :
A,B
A ( Ao# , A1 , A2, Bo# ... )
B ( Bo# , B1 , B2 , ...)
Relations obtenues :
A,B
A ( Ao# , A1 , A2,... )
B ( Bo# , B1 , B2 ,Ao # ...)
ENTITE B
*,1
Association
1,1
Identifiant Bo
Propriété B1
Propriété B2
Représentation graphique du MLDR
A
B
Ao #
A1
A2
Bo #
Bo #
B1
B2
B
Bo #
B1
B2
Ao #
A
Ao #
A1
A2
34
34
Cas Pratique : cas de gestion de commande
Les Règles de Gestion :
• Pour les commandes :
RG1 : Un Client Passe une ou plusieurs commandes
RG2 : Une Commande ne correspond qu’à un seul Client.
•Pour les produits :
RG3 : Une Commande est composée d’un ou plusieurs Produits
RG4 : Un produit peut appartenir à plusieurs Commande.
Dictionnaire de données
1- Code Client
2- Raison Sociale
3 - Adresse du Client
4- Ville du Client
5- Téléphone du Client
6- Numéro de Commande
7- Date de la commande
8 – Référence de produit
9 - Nom du Produit
10-Prix Unitaire
11- Quantité en Stock
12- Quantité Commandée
35
35
Cas Pratique : cas de gestion de commande
4 ) Application : Schéma relationnel d’un service de gestion de Commande
Client
Code Client Raison
Sociale Adresse du
Client Ville du
Client Téléphone du
Client
Commande
1, N
1, 1
Passe
Numéro de
Commande
Date de la
commande
1, N
Produit
Référence du Produit
Nom du Produit
Prix Unitaire
Quantité en Stock
0, N
MLDR
Détails Commande
Quantité
commandée
CLIENT ( 1 # , 2, 3,4,5 )
COMMANDE ( 6 #,7, 1# )
PRODUIT (8#, 9 , 10, 11 )
DETAILS COMMANDE ( 6 #,8#, 12 )
36
36
Construction du Modèle Physique de Données MPD
Application : Schéma relationnel d’un service clientèle dans un café
Client
Code Client
Raison Sociale
Adresse du Client
Ville du Client
Téléphone du Client
Commande
Code Client= Code Client
Numéro de Commande
Date de la commande
Code Client
Numéro de Commande = Numéro de Commande
Détails Commande
Produit
Référence du Produit
Nom du Produit
Prix Unitaire
Quantité en Stock
Référence du Produit =
Référence du Produit
Numéro de Commande
Référence du Produit
Quantité Commandée
37
38
38
MODULE 2
CREATION D’UNE BASE DE DONNEES
39
39
Qu’est-ce qu’une base de données ? ( BD )
Une base de données ( BD ) est un ensemble structuré de données enregistrées avec le minimum
de redondance sur un support de stockage informatique et accessibles à plusieurs utilisateurs de
manière sélective et simultanée au moyen d’un système de gestion de base de données ( SGBD ) .
Un SGBD permet de répondre simultanément aux interrogations ( requêtes ) de plusieurs
utilisateurs exprimées sur une même base de données déployée sur un réseau informatique .
Exemple : Base de données d’une compagnie aérienne
Les requêtes sont très variées , par exemple :
- Une réservation : « Liste des passagers qui ont réservé un vol déterminé ? »
- Un équipage : « Quel est le pilote du vol Royal Air Maroc Casablanca – Londres du 15 Octobre
Départ 15 H 30 ? »
- Un appareil : « Quelle est la date de la dernière révision de l’avion N ° 97 ? »
Un Système de Gestion de Bases de Données
offre la possibilité à l’utilisateur de manipuler les représentations abstraites des données
( métadonnées ) indépendamment de leur organisation et de leur implantation sur les
supports physiques .
Fonctions principales d’un SGBD
- Décrire et organiser les données sur les mémoires secondaires
( disques, bandes magnétiques , etc… )
- Rechercher, sélectionner et modifier les données
Fonctions complémentaires d’un SGBD
- Sécurité : vérifier les droits d’accès des utilisateurs sur les données
- Intégrité : définir des règles qui maintiennent une cohérence entre les données compte tenu
de leur structure ( contraintes d’intégrité )
- Concurrence d’accès : détecter et traiter les cas où il y a conflit d’accès entre plusieurs
utilisateurs et les traiter correctement .
40
40
41
41