Introduction au Méthode de Conception des Systèmes d'Information Merise

(1)

PRESENTATION DE MERISE

I°/ Historique

Le projet qui a permis d’aboutir à la naissance de la méthode

MERISE a été lancé en 1977 par le Ministre de l’industrie de la France

dans le but de doter l’administration d’une méthode de conception

devant permettre à ses équipes de réussir leurs projets dans les coûts et délais prévus.

Les principaux acteurs qui alors sont intervenus sont le CETE (Centre d’Etudes Techniques de l’Equipement) d’Aix-en-Provence, un certain nombre de SSCI (Sociétés de Conseil et d’Ingénierie Informatique) et quelques universitaires.

MERISE est apparue en 1979. La naissance de MERISE marque

donc une date importante dans l’histoire du traitement de l’information. Cette naissance résulte d’une part de l’inadéquation des méthodes

comme MINOS ou CORIG aux préoccupations actuelles et de la généralisation des traitements conversationnels faisant suite aux

bouleversements technologiques des années 70 et, d’autre part, de

nombreux travaux sur les bases de données et sur « l’Approche Système »

Le nombre de SSII (Sociétés de Services et d’Ingénierie Informatique) capables de fournir des prestations autour de MERISE

ne cesse d’augmenter. Parmi celles-ci, citons quelques noms : Gamma

International, CGI, Cap Gemini Sogeti, SIS, Semagroup, Cecima, Méta Informatique, Delf et autres. Les prestations fournies sont de plusieurs types : Formation et monitorat, conception de systèmes d’information,

développement d’outils supports à MERISE.

De nombreuses directions informatiques, prenant conscience de

l’aide apportée par MERISE pour la conception de systèmes d’information et la conduite de projets, favorisent son utilisation. C’est

ainsi que MERISE a été retenue par France Télécom, les AGT, Paribas, EDF, le CEPME, la GMF, la CNAF, Rhône Poulenc, Ministère de la justice, la Banque Worms, etc.

(2)

Décembre 1976 SSCI MINISTERE DE L’INDUSTRIE UNIVERSITAIRES ADMINISTARATIONS Juin 1979 SECTEUR PRIVE 1979 / 1980

Cette méthode permet de combiner d’une manière opérationnelle de trois cycles :

CYCLE DE DECISION

CYCLE

D’ABSTRACTION CYCLE DE VIE

(3)

II°/ Cycle de décision

Ce cycle permet un dialogue et une validation permanente entre les

informaticiens, utilisateurs et décideurs.

Tout au long de l’étude et de la maintenance, des décisions sont à prendre, très générales d’abord, puis de plus en plus ponctuelles.

Les décisions globales doivent être prises par la direction générale, mais à chaque niveau chacun doit être consulté.

Les diverses décisions se prennent au vu des différents documents rédigés lors de l’avancement des travaux.

La hiérarchie MERISE des décisions à prendre est la suivante : Avant la conception :

- La durée globale du projet ? (Mois ? Années ?)

- Risque d’échec ? Lors de la conception :

- Découpage du système d’information en domaine,

- Les grandes orientations en matière de gestion, d’organisation et de solutions techniques,

- Les postes de travail,

- Les tâches par poste,

- Les procédures manuelles,

- Les procédures automatiques,

- Les états de sortie,

- Les écrans de saisie, III°/ Cycle d’abstraction

Ce cycle vise à concevoir le système d’information de chaque domaine de l’entreprise en suivant une logique de modélisation à trois niveaux : conceptuel, logique/organisationnel et physique.

Cette approche permet de bien séparer les différents types de préoccupation, chacun des trois niveaux de MERISE répondant à des préoccupations différentes.

(4)

NIVEAUX DONNEES TRAITEMENT

Conceptuel

(QUOI ? / QUE VEUT ON FAIRE ?) MCD MCT Organisationnel (QUI ? OU ? QUAND ? POURQUOI ? Et COMMENT ?) MLD MOT Opérationnel

( Avec Quels Moyens ?) MPD MopT

1°/ Le niveau conceptuel

L’objectif du niveau conceptuel est de répondre à la question QUOI ?, de comprendre l’essence du problème.

Il s’agit de trouver les règles de gestion du domaine étudié. Exemple : REGLES DE GESTION

- Un professeur ne peut donner qu’un seul type de cours.

- Un homme peut être marié avec plusieurs femmes.

- Prix Total = Prix Unitaire * Quantité

2°/ Le niveau logique / organisationnel

L’objectif du niveau logique est de répondre aux questions Qui ?, Ou ?, Quand ?, Pourquoi ?, Et Comment ?

Il s’agit de trouver les règles d’organisation du domaine étudié. Exemple : REGLES D’ORGANISATION

- Les cours de physique doivent toujours avoir lieu en salle 205.

(5)

3°/ Le niveau physique

L’objectif du niveau physique est de répondre à la question avec quels moyens ?

Les règles mises en évidence au niveau physique sont les règles techniques.

Exemple :

- Avoir un système d’exploitation permettant un mode multitraitement.

IV°/ Les étapes de MERISE (Cycle De Vie)

La méthode MERISE propose une démarche de six étapes pour automatiser un système d’information :

 Schéma directeur,  Etude préalable,  Etude détaillée,  Réalisation,  Mise en œuvre,  Maintenance, 1°/ Schéma directeur

L’objectif de cette étape est de faire le pont entre la stratégie de l’entreprise et ses besoins en terme de systèmes d’information :

- D’une part :

 Il faut nommer le chef de projet,  Définir les objectifs de l’étude,

- D’autre part :

 La normalisation de la situation existante,  Découpage du système en domaines,

Ce découpage permet d’une part de créer des groupes de travail sur des sujets distincts ayant peu de liaison entre eux, d’autre part, il permet d’aborder les problèmes communs à plusieurs directions de l’entreprise.

(6)

Voici les sept domaines de gestion d’une entreprise nationale : o Domaine des achats,

o Domaine des études,

o Domaine de la fabrication, o Domaine commercial, o Domaine du personnel, o Domaine de la qualité, o Domaine des finances,

Exemple De Découpage d’un système :

SYSTEME Entreprise qui fabrique l’équipement informatique

Domaine 1 GESTION COMPTABILITE ET FINANCIERE Domaine 2 DIRECTION (Suivi, …) Domaine 3 GESTION DES RESSOURCES HUMAINES Domaine 4 VENTES (Facturation, transport, …) Domaine 5 APRES VENTE (Maintenance) Domaine 6 FABRICATION

(Fabrication, gestion du stock)

Résultat du schéma directeur :

- La détermination des domaines et des structures,

- La planification du développement,

- Avoir un plan détaille sur les applications à réaliser,

- Quelle est la stratégie des moyens en :  Personnel (formation, embauche, …)

 Matériel (Micro-ordinateurs, Miniordinateur ou gros système)

- La stratégie des moyens logiciels (SGBD, SGF, Logiciels de gestion, logiciels techniques, …)

(7)

2°/ L’étude préalable

A la suite du schéma directeur, l’étude préalable aura pour but de reprendre domaine par domaine et d’étudier de manière plus approfondie les projets à mettre en œuvre et leur interfaçage.

SYSTEME Entreprise qui fabrique l’équipement informatique

Domaine 2

DIRECTION (Suivi, …)

Sous Domaine1 / Projet 1

GESTION DE LA SECRETARIAT

Sous Domaine2 / Projet 2

GESTION DES REUNIONS

Une étude préalable doit être courte mais néanmoins complète, c’est pourquoi, une étude préalable est réalisée sur un présentatif du domaine à automatiser. Ce sous-ensemble est sélectionné en fonction d’un certain nombre de paramètres précises.

Résultat de l’étude préalable :

Un rapport résumant les solutions proposées par l’équipe :  Solutions techniques :

 Matériels,  Logiciels,

 Solutions en moyens humaines :  Embauche,

 Formation du personnel,  Ajouter d’autres domaines,  Ajouter d’autres projets.

Ce rapport sera présenté à la direction, c’est à elle de décider de retenir une des solutions proposées ou d’arrêter le cycle de vie.

(8)

3°/ L’étude détaillée

L’étude détaillée est effectuée projet par projet et se décompose en deux phases principales :

- la conception fonctionnelle,

- la conception technique,

CONCEPTION FONCTIONNELLE

Faire le bilan de l’existant (matériels, logiciels, humains, et méthodes de travail) et, en prenant en compte les nouvelles orientations de la direction, et lui proposer d’effectuer un choix quant aux scénarios d’organisation qu’elle souhaite mettre en œuvre afin d’atteindre le futur système cible qui vient d’être fixé pour le projet en cours.

L’analyste sera amené à réaliser un cahier des charges utilisateurs. Ce cahier des charges utilisateurs doit permettre aux utilisateurs de prendre connaissance du futur système au travers des maquettes d’écrans et des états d’édition et de formuler des remarques à leur sujet ou encore à propos des contrôles fonctionnels que le futur système devra effectuer.

CONCEPTION TECHNIQUE

Cette phase a pour but d’élaborer l’architecture technique des programmes des différentes transactions ou chaînes batch et les modèles physiques de données nécessaires à leur exécution :

- Supports physiques (disquette, disque dur, bande magnétique, etc.),

- Clés d’accès,

(9)

4°/ Réalisation (programmation)

La réalisation est effectuée en trois étapes :

- Codage des programmes,

- Tests et mise au point,

- Intégration de l’ensemble des transactions. 5°/ La mise en œuvre

La mise en œuvre des applications nécessite la réalisation de l’ensemble des tâches suivantes :

 Création et initialisation des bases de données,  Installation des nouveaux matériels informatiques,

 Formation des futurs utilisateurs aux nouvelles applications,  Lancement définitif des nouvelles applications.

6°/ La maintenance

La maintenance des applications va permettre de faire vivre les applications et de mettre à niveau jusqu’à leur mort.

V°/ Les modèles de MERISE

Pour mener à bien un projet en terme de coût et délais prévus,

MERISE propose six modèles. Un formalisme graphique est généralement

associé à chacun de ces modèles.

MODELES

GRAPHIQUE

Modèle conceptuel des données

Oui

Modèle conceptuel des traitements

Oui

Modèle logique des données

Oui

Modèle organisationnel des traitements

Oui

Modèle physique des données

Non

Modèle opérationnel des traitements

Oui

L’ensemble de ces modèles recouvre les trois niveaux du cycle d’abstraction du système d’information.

(10)

Graphe de flux

Modèle conceptuel des données brut Modèle conceptuel des traitements Modèle organisationnel des traitements Les vues externes

Modèle conceptuel des données validé Modèle logique des données

Modèle logique des données optimisé

(11)

GRAPHE DE FLUX

I°/ Introduction

Le graphe de flux permet de donner un schéma général de

circulation et d’échange d’informations entre les différents intervenants du système étudié ainsi qu’avec l’environnement.

II°/ Conception du graphe de flux 1°/ Les acteurs ou intervenants

Un acteur est un agent capable d’échanger de l’information avec d’autres.

Il peut être soit interne, qui appartient au système, soit externe, qui appartient à l’environnement.

Présentation graphique :

Un acteur est représenté par un ovale.

2°/ Le flux

C’est l’échange d’informations entre les acteurs. Un flux est caractérisé par l’acteur émetteur et l’acteur récepteur.

Flux 3 Flux 4 Flux 1 flux 2 ACTEUR CLIENT ACTEUR 1 ACTEUR 2 ACTEUR 3

(12)

III°/ Etude De Cas :

On doit partir des orientations actuelles de gestion pour déterminer

les règles de gestion du futur système à mettre au place.

La situation actuelle est la suivante :

- Les commandes des clients jugés non solvables (les clients qui

ont les moyens pour payer leurs créanciers) sont refusées. (

Par le service commercial)

- Les commandes acceptées sont confrontées (au magasin) à

l’état du stock pour déterminer quels sont les manquants et

quelles sont les commandes disponibles.

- On cas de manquants, le service achat devra prendre toutes

dispositions pour réapprovisionner le stock si ce n’est pas

encore fait.

- Dés la livraison du fournisseur, les commandes devenues

disponibles subissent le même traitement que celles qui

l’étaient dés le départ (service magasin livre la marchandise

au client)

- Les commandes disponibles donnent lieu à la confection des

bons de livraisons destinés aux clients.

-

A la livraison, ceux-ci peuvent refuser la marchandise,

auquel cas il y a retour de marchandise.

- Si le client accepte la livraison, la comptabilité émet une

facture qui ne sera soldée qu’après complet règlement, les

clients qui n’ont pas réglé à l’échéance devrant recevoir une

relance. Les factures soldées sont archivées dans le service

archive.

Questions :

1- Déterminer les acteurs internes et externes.

2- Etablir le graphe de flux.

(13)

1°/ Les intervenants

Les acteurs externes :

- Client,

- Fournisseur, Les acteurs internes :

- Service commercial,

- Magasin,

- Service achat,

- Comptabilité,

(14)

2°/ Le Graphe De Flux

CLIENT COMMERCIAL MAGASIN

ACHAT FOURNISSEUR COMPTABILITE Bon De Commande Refus de la Commande Commande Acceptée Manque Réapprovisionnement Bon De Commande Livraison Règlement Facture

Marchandise + Bon Livraison

Retour Marchandise Acceptation de livraison Facture R ègl em e nt R el anc e

(15)

3°/ La Matrice de Flux

Client Service commercial

Magasin Service comptabilité

Service achat Fournisseur

Client -Bon de commande - Acceptation

- Règlement Service commercial -Refus de la commande -Commande acceptée Magasin - Marchandise - Bon de livraison - Produits manquants Service comptabilité - Facturation - Relances - Règlements - Factures Service achat -Réapprovisionnem ent - Commande produit

(16)

MODELE CONCEPTUEL DE DONNEES

(MCD)

Le modèle conceptuel de données donne une représentation statique de l’ensemble des données (documents de travail) manipulées par l’entreprise ainsi que les relations entre ces données.

Afin de délimiter le domaine sur lequel porte le MCD, l’élaboration du MCD est souvent précédée de celle du graphe des flux de données. Le graphe de flux permet souvent de mettre en évidence des individus du MCD.

II°/ Les concepts de base

1°/ Le modèle entité - relation

C’est une description selon un modèle s’articulant autour de trois concepts : entité, relation et attribut.

- Entité : une entité ou individu est la représentation dans le système

d’information d’un objet matériel ou immatériel.

- Relation : une relation est la prise en charge par le système

d’information qu’il existe une association entre des objets de l’univers extérieur.

- Attribut : un attribut est la propriété d’une entité.

Exemple 1 :

Nom Fournisseurs Adresse Fournisseurs

Les entités : Fournisseur et Produits La relation : Vent

Les attributs : Nom Fournisseurs, Adresse Fournisseur

(17)

Exemple 2 :

- Entité : Produits,

- Attributs : Code, Désignation, prix

Code Désignation Prix

Entité 1 ART001 PC PEITUM III 5600,00

Entité 2 ART005 Clavier 102 touches 300,00

Entité 3 ART002 Souris PS 2 50,00

- Entité-type : C’est un regroupement des entités de même nature.

- Occurrence : Est une entité particulière appartenant à ce type

(Exemple : ART002 Souris PS 2 50,00)

2°/ Modèle individuel

C’est une description selon un modèle graphique dérivé du modèle entité relation et s’articulant autour de trois concepts principaux :

 Concept objet : individu-type ou entité-type  Concept de relation : relation-type

 Concept de propriété : propriété-type

A°/ Individu type

C’est une classe d’objets ayant en commun un ensemble de propriétés. Exemple :

Client (Code Client, Nom client, prénom client, adresse client)

B°/ Propriété type

C’est une classification de propriété semblable de toutes les occurrences d’individus appartenant à un individu type ou de toutes les occurrences de relation appartenant à une relation type.

CLIENT Code client Nom client Prénom client Adresse client Téléphone client In d iv id u -ty p

e Nom individu type

(18)

Exemple :

Tous les clients ont une propriété semblable : Nom du client, prénom du client, adresse du client…

C°/ Relation type

C’est une association entre plusieurs entités – types.

Exemple :

D°/ Occurrence d’un type

C’est un élément unique appartenant à ce type. Exemple :

Pour l’individu type PRODUIT, je peux avoir comme occurrence l’information suivante :

CodeP : ART5487 DésigP : TIDE Moyen

E°/ Identifiant

C’est une pointe dont la valeur identifiée de façon unique une occurrence d’individu type.

Exemple :

CodeP, CodeF, CIN, …

Nom de la relation type Propriété relation type

PRODUIT CodeP DésigP FOURNISSEUR CodeF NomF PreF fournit PrixU

(19)

3°/ Les caractéristiques du modèle individuel

a°/ La dimension d’une relation type

La dimension d’une relation type est le nombre d’occurrences d’entités concernées par une occurrence de la relation type.

Dimension de cette relation est de 2.

b°/ Les fonctionnalités d’une relation type

C’est le degré de participation des occurrences d’un individu type à une relation type.

- Relation Type TOTAL

Une relation type définie sur les individus types A et B est dite totale, si chaque occurrence de A et chaque occurrence de B participe à une occurrence de la relation type.

Exemple :

Pour chaque homme de l’entité type « HOMME » on trouve une femme dans l’entité type « FEMME »

Pour chaque femme de l’entité type « FEMME » on trouve un homme dans l’entité type « HOMME »

LIVRE AUTEUR

ECRIRE

(20)

- Relation Type PARTIEL

Une relation type définie sur les individus types A et B est dite partielle, si lorsque certaines occurrences de A et/ou certaines occurrences de B peuvent ne pas participer à une occurrence de la relation type.

c°/ Les cardinalités d’une relation type

C’est le nombre de fois pour chaque occurrence d’individu type est impliqué dans les occurrences de la relation type.

- Cardinalité minimum

C’est le nombre minimum de fois ou chaque occurrence d’une entité type participe à la relation type.

- Cardinalité maximum

C’est le nombre maximum de fois ou chaque occurrence d’une entité type participe à la relation type.

Représentation Graphique

Exemple :

(1,1) : un homme est fils d’au moins et d’au plus une femme. (c’est à dire d’une femme et d’une seule)

(0,n) : une femme peut n’avoir pas d’enfants (0 enfant) ou au contraire en avoir plusieurs (n enfants)

Dans la pratique, on gère les quatres cardinalités suivantes :

(0,1) : chacune des occurrences de l’individu est reliée au plus à une occurrence de la relation.

(1,1) : chacune des occurrences de l’individu est reliée exactement à une occurrence de la relation. ENTITE TYPE 1 ENTITE TYPE 2 RELATION TYPE (min,max) (min,max)

HOMME EST FILS DE FEMME

(21)

(0,N) : chacune des occurrences de l’individu est reliée à un nombre quelconque d’occurrences de la relation.

(1,N) : chacune des occurrences de l’individu est reliée à au moins une occurrence de la relation.

d°/ Les règles de gestion

Les règles de gestion précisent les contraintes qui doivent être respectées par le modèle.

Exemple :

Dans le MCD d’une école les règles de gestion peuvent être les suivantes :

RG1 : Tout professeur enseigne en principe au moins une matière, mais

certains d’entre eux peuvent être dispensés d’enseignement en raison de leurs travaux de recherche.

RG2 : Toute matière est enseignée dans au moins une classe. RG3 : Toute classe a au moins trois enseignants.

Le MCD devient alors :

Les règles de gestion expriment les contraintes d’intégrité du modèle.

e°/ Les contraintes sur une relation

Pour définir de façon formelle une relation, la liste des attributs ne suffit pas. Il faut associer à la relation l’ensemble des contraintes qui existent sur les valeurs de ses attributs.

professeur matière

classe enseigne

0,n 1,n

(22)

Exemple :

Considérons la relation suivante :

ETUDIANT (Code, Nom, Prénom, Date_Naissance, Nationalité)

Code Nom Prénom Date_Naissance Nationalité

01 EL KASSIMI MOHAMED 21/03/1973 MAROCAINE

02 HANSALI JAMAL 01/01/1969 MAROCAINE

03 GAMBRIER MOGAN 01/12/1970 FRANCAISE

04 TITI KAMARA 07/11/1976 IVOIRIENNE

Exemples de contraintes :

- Les dates de naissances doivent être inférieures à l’année en cours.

- Le nom de l’étudiant est composé d’une suite de caractères alphabétiques.

- Le prénom de l’étudiant est composé d’une suite de caractères alphabétiques.

D’une façon pratique, le nombre des contraintes existant dans un schéma peut être grand et leur nature très différente.

- Sexe : l’attribut « sexe » prend ses valeurs dans l’ensemble {Masculin

Féminin}

- Salaire net = salaire brut – retenues + indemnités

Parfois, l’existence de la valeur d’un attribut peut être liée à la valeur d’un autre attribut.

Exemple : L’attribut nom-jeune-fille ne prendra de valeur que si le sexe est féminin.

f°/ Les dépendances fonctionnelles f.1°/ Définition

On dit que deux propriétés « A » et « B » sont reliées par une dépendance fonctionnelle :

A B

Si la connaissance de la valeur de A détermine une et une seule valeur de B. DF

(23)

f.2°/ Cas pratique

Le système d’information d’une entreprise contient essentiellement les propriétés figurant sur les bons de commande et les factures :

Document de travail : Numéro du bon : ……….. Code client : ………….. Nom du client : ……….. Adresse client : ……… Date : … /.. / …… Code représentant : ……… Nom représentant :……… COMMANDE Référence Produit Désignation Quantité commandée

Prix unitaire Montant total

Montant Total

A la suite d’interviews des différents postes de travail du système d’information existant, on rassemble des exemplaires de tous les documents utilisés ainsi que les descriptions des divers fichiers en usage actuellement.

Règle de gestion 1 : Un client peut passer une ou plusieurs

commandes ou aucune commande.

Règle de gestion 2 : Une commande peut concerner un ou plusieurs

produits.

Règle de gestion 3 : Une commande est passée à un représentant qui

n’est toujours le même pour un client donné.

Règle de gestion 4 : Chaque client se voyait attribuer un représentant

habituel.

1°/ Dictionnaire Brut. 2°/ Dictionnaire Epuré

3°/ Trouver Toutes Les Dépendances fonctionnelles. 4°/ Etablir Le Graphe De Dépendances fonctionnelles.

(24)

Dictionnaire De Données Brut

On constitue un dictionnaire des données conformément à l’exemple suivant :

Application : Gestion Des Commandes Client

DICTIONNAIRE BRUT Réalisateur : M. EL KASSIMI Mohamed

Date : 20/112001 Attributs Désignation Type Longueur Intégrité NUMB Numéro de bon de commande N 4

DATB Date du bon de commande C 10 JJ/MM/AAAA

CODC Code client N 4

NOMC Nom du client A 30

ADRC Adresse du client C 50

CODR Code du représentant N 4 NOMR Nom du représentant A 30 REFP Référence du produit AN 5 DESP Désignation produit AN 30

QTEC Quantité commandée N 3

PRXU Prix unitaire du produit N 7 9999,99

MNTP Montant produit commandé N 8 PRIXU * QTEC TOTC Montant total de la commande N 8  MNTP

Dictionnaire De Données Epuré

Règles de passage du dictionnaire de données brut au dictionnaire de données épuré :

Il faut alors éviter les cas suivants :

- Synonymes : deux signifiants pour un m^me signifié

Exemple 1 :

CODC : Code client

NUMC : Numéro de client Exemple 2 :

TVA TAXE

La solution dans ces cas, c’est qu’il faut éliminer un des deux attributs.

- Polysème : Un signifiant pour deux signifiés.

Exemple 1 :

NOM : pour nom client et pour nom fournisseur.

La solution est d’ajouter un autre attribut : NOMC : pour nom du client et NOMF pour le nom du fournisseur.

(25)

- Les attributs calculés : dans le dictionnaire épuré, il faut éliminer les attributs calculés (Un attribut calculé est un attribut qu’on peut le déduire à partir d’autres attributs)

Exemple :

MNTP = QTEC * PRXU

Application : Gestion Des Commandes Client

DICTIONNAIRE EPURE Réalisateur : M. EL KASSIMI Mohamed

Date : 20/112001 Attributs Désignation Type Longueur Intégrité NUMB Numéro de bon de commande N 4

DATB Date du bon de commande C 10 JJ/MM/AAAA

CODC Code client N 4

NOMC Nom du client A 30

ADRC Adresse du client C 50

CODR Code du représentant N 4 NOMR Nom du représentant A 30 REFP Référence du produit AN 5 DESP Désignation produit AN 30

QTEC Quantité commandée N 3

PRXU Prix unitaire du produit N 7 9999,99

Les Dépendances Fonctionnelles

L’objectif est de trouver est ce qu’il y a une relation entre les différents attributs du dictionnaire de données épuré.

Exemple 1 :

Je souhaite savoir est ce qu’il y a une dépendance fonctionnelle par exemple entre NUMB (numéro de bon de commande) et la DATB (la date du bon de commande. Est ce : DATB NUMB Ou bien NUMB DATB DF DF

(26)

Méthode :

Pour le premier cas :

Je pose la question suivante :

Est-ce que pour une seule date (DATB) existe un seul numéro de bon de commande (NUMB) ?

Non, pour une date DATB, l’entreprise peut avoir plusieurs bon de commande, donc

DATB NUMB

DATB ne peut pas déterminer le numéro de bon de commande NUMB. Pour le deuxième cas :

Je pose la question suivante :

Est-ce que pour un seul numéro de bon de commande (NUMB), on trouve une seule date de bon ?

Oui, parce que le bon est établi dans une et une seule date particulière. Donc :

NUMB DATB

NUMB détermine DATB.

Exemple 2 :

CODC NOMC

La connaissance du code client détermine une et une seule valeur de NOMC. Autrement dit, si on connaît le code client, on doit pouvoir connaître son nom et celui ci sera unique.

La réciproque est fausse. Le nom du client ne permet pas de déterminer son code, car plusieurs clients peuvent avoir le même nom.

(27)

NUMB DATB

DATB NUMB

Pour un numéro de bon, il existe une et une seule date.

Pour une date, on peut trouver plusieurs bon qui ont été établi dans cette date.

NUMB CODR

CODR NUMB

Pour un bon, il y a un et un seul code représentant. Mais pour un représentant il peut être concerner par plusieurs bons.

NUMB NOMR

NOMR NUMB

Pour un bon, on trouve un et un seul nom de représentant.

NUMB CODC

CODC NUMB

Un bon concerne un et un seul client.

Un client peut être concerner par plusieurs bon.

NUMB NOMC

NOMC NUMB

Un bon concerne un et un seul client.

Un client peut être concerner par plusieurs bon.

NUMB ADRC

ADRC NUMB

Dans un bon, il existe une et une seule adresse client. Une adresse, on peut la trouver dans plusieurs bon.

CODC NOMC

NOMC CODC

A partir d’un code client, on peut trouver le nom du client. On peut trouver plusieurs clients qui portent le même nom.

(28)

CODC ADRC

ADRC CODC

Pour un code client, on peut identifier l’adresse client.

CODC CODR

CODR CODC

Dans cette gestion, chaque client est associé à un et un seul représentant. Pour un représentant, il existe plusieurs clients.

REFP DESP

DESP REFP

A partir de la référence du produit, on peut déterminer la désignation du produit. Mais pour une désignation particulière, il peut exister plusieurs références.

REFP PRXU

PRXU REFP

Pour une référence particulière, il existe un et un seul prix unitaire. Pour un prix, on peut avoir plusieurs produits qui ont le même prix.

NUMB, REFP QTEC

NUMB QTEC

REFP QTEC

Pour un bon, il existe plusieurs quantités commandées.

Pour un produit particulier, REFP, on peut trouver que cette quantité se trouve dans plusieurs bons.

La quantité commandée, QTEC, est déterminée à partir des deux informations qui sont le numéro de bon et la référence du produit.

f.3°/ Les propriétés des dépendances fonctionnelles

L’étude mathématique des dépendances fonctionnelles dans une relation permet de donner les règles suivantes :

(29)

La réflexivité Exemple A A REFP REFP La projection Exemple Si A B, C Alors A B A C Si

REFP DESP, PRXU

Alors REFP DESP Et REFP PRXU L’augmentation Exemple Si A B Alors A, C B Si REFP DESP Alors

REFP, PRXU DESP

L’addition Exemple Si A B A C Alors A B, C Si REFP DESP REFP PRXU Alors

REFP DESP, PRXU

La transitivité Exemple Si A B et B C Alors A C Si NUMB CODC Et CODC NOMC Alors NUMB NOMC DF DF DF DF DF DF DF DF DF DF DF DF

(30)

La pseudo transitivité Exemple Si A B Et B, C D Alors A, C D Si NUMB CODC Et

CODC, NOMC ADRC Alors

NUMB ADRC

Les nouvelles dépendances obtenues ainsi à partir des propriétés sont en fait des parasites puisqu’elles sont déduites à partir d’autres.

Il faut éliminer des DF pour obtenir un ensemble minimal de dépendances. Cet ensemble s’appelle la couverture minimale.

De nombreux algorithmes ont été proposés pour la recherche de la couverture minimale. La plus utilisée est le graphe de dépendances fonctionnelles :

f.4°/ Graphe De Dépendances Fonctionnelles

Le graphe de dépendances fonctionnelles (GDF) est la représentation graphique des dépendances fonctionnelles entre les différents attributs du dictionnaire de données épuré.

NUMB

DATB CODR CODC REFP

QTEC

NOMR NOMC ADRC DESP PRXU

DF DF

(31)

- La recherche de la couverture minimale

Pour trouver la couverture minimale, il faut que toutes les dépendances fonctionnelles soient élémentaires et directes.

 Dépendance élémentaire

Une dépendance A, B --> C est dite élémentaire s’il n’existe pas des dépendances telles que : A-->C ou B -->C

Exemple 1:

NUMB, REFP QTEC

NUMB QTEC

REFP QTEC

Donc la dépendance fonctionnelle NUMB, REFP ----> QTEC est élémentaire.

Exemple 2 :

CODC, NOMC ADRC

Cette dépendance n’est élémentaire car : CODC ADRC

Graphiquement

A B

C

 Dépendances directes

Une dépendance A--->B, dans une relation R, est dite directe s’il n’existe pas d’attribut C distinct de A et B tel que A---->C et C---->B.

(32)

Exemple 1 :

NUMB NOMR

N’est pas directe car

NUMB CODR et CODR NOMR

Graphiquement

Si A

C

B

Alors, il faut éliminer A ---->B A

C B

On application les deux règles de recherche de la couverture minimale (ou la structure d’accès théorique SAT) qui sont avoir toutes les dépendances élémentaires et directes, le graphe de dépendances fonctionnelles devient :

NUMB

DATB CODR CODC REFP

QTEC

(33)

Après avoir trouver la couverture minimale, il faut marquer les clés. Règle De Recherche De La clé

Si un attribut détermine un autre, il sera considéré comme clé.

NUMB

DATB CODR CODC REFP

QTEC

Maintenant, il faut regrouper chaque clé avec les attributs qu’il détermine.

NUMB

DATB CODR CODC REFP

QTEC

g°/ Le modèle conceptuel de données (MCD)

Règles de passage du graphe de dépendances fonctionnelles au modèle conceptuel de données :

- Chaque groupe du graphe sera représenté par un individu type.

- L’intersection des groupes forme la relation.

(34)

MODELE CONCEPTUEL DE DONNEES

BONS NUMB DATB CODR CODC REPRESENT ANT CODR NOMR CLIENT CODC NOMC ADRC PRODUIT REFP DESP PRXU obtenir passer Contenir QTEC 1,1 0,n 0,n 1,1 1,0 0,n

(35)

MODELE CONCEPTUEL DES

TRAITEMENTS

(MCT)

Le modèle conceptuel des traitements (MCT) permet de mettre l’accent sur l »ensemble d’opérations réalisées au sein de l’entreprise en répondant à la question QUOI ?

La conception du modèle conceptuel des traitements se base sur le graphe de flux et les règles de gestion.

II°/ Conception du MCT 1°/ Les événements

Un événement est un fait qui provoque la réaction du système d’information.

Un événement est une action qui permet de déclencher plusieurs opérations à l’intérieur de l’organisme.

Il existe deux types d’événements :

- Evénement déclencheur,

- Evénement résultat,

EVENEMENT DECLENCHEUR

[ REACTION DU SYSTEME ]

(36)

Exemple :

Dans la gestion d’une banque :

Demande du solde

Réaction du système

Reçu du solde

2°/ Un processus

Un processus est un ensemble d’opérations qui concourent à l’élaboration d’un ou plusieurs résultats. Cet ensemble d’opérations est défini à partir des règles de gestion.

Un processus est déclenché par un événement. Processus Opération 1 Opération 2 Opération 3 Opération 4 … opération n EVENEMENT DECLENCHEUR [ PROCESSUS ] EVENEMENT RESULTAT 3°/ Opération

Une opération est un ensemble de tâches qui sont exécutées de façon

(37)

Opération Tâche 1 Tâche 2 Tâche 3 Tâche 4 … Tâche n Exemple

Calcul de la moyenne d’un étudiant – Note contrôle * 2 = N1 – Note examen * 3 = N2 – Note appréciation * 1 = N3

– Note de la matière = (N1+N2+N3)/6

Une tâche est une action unitaire réalisée dans une opération.

4°/ La synchronisation

Une synchronisation d’une opération marque le rendez-vous des événements contributifs qui doivent être arrivés avant de déclencher l’opération, selon une proposition logique (ou et de et) traduisant les règles d’activation, c’est à dire les règles de gestion que doivent vérifier les événements contributifs pour déclencher les actions.

Exemple

5°/ Les règles d’émission

Une règle d’émission permet de passer une condition sur le résultat d’une opération déclenchée par un ou plusieurs événements.

Demande du solde

Numéro du compte

(38)

Une règle d’émission peut être soit : OK : Si le résultat de l’opération est bon, OK : Sinon,

Toujours : S’il n’y a pas de condition sur l’opération.

6°/ La forme graphique du MCT

Evé1 Evé2 Evé3

(a et b) ou (a et c)

Opération

Résultat 1 Résultat 2 Résultat 3 OK OK Tjs

(39)

III°/ Etude De Cas

On doit partir des orientations actuelles de gestion pour déterminer

les règles de gestion du futur système à mettre au place.

La situation actuelle est la suivante :

- Les commandes des clients jugés non solvables (les clients qui

ont les moyens pour payer leurs créanciers) sont refusées. (

Par le service commercial)

- Les commandes acceptées sont confrontées (au magasin) à

l’état du stock pour déterminer quels sont les manquants et

quelles sont les commandes disponibles.

- On cas de manquants, le service achat devra prendre toutes

dispositions pour réapprovisionner le stock si ce n’est pas

encore fait.

- Dés la livraison du fournisseur, les commandes devenues

disponibles subissent le même traitement que celles qui

l’étaient dés le départ (service magasin livre la marchandise

au client)

- Les commandes disponibles donnent lieu à la confection des

bons de livraisons destinés aux clients.

-

A la livraison, ceux-ci peuvent refuser la marchandise,

auquel cas il y a retour de marchandise.

- Si le client accepte la livraison, la comptabilité émet une

facture qui ne sera soldée qu’après complet règlement, les

clients qui n’ont pas réglé à l’échéance devrant recevoir une

relance. Les factures soldées sont archivées dans le service

archive.

Questions :

1°/ Etablir le diagramme d’enchaînement des opérations.

(40)

 Le diagramme d’enchaînement des opérations : Cas 1 Commande client Demande refusée Cas 2 Commande client Demande acceptée Rupture en stock Remarque :

Il faut procéder de cette manière pour trouver tous les cas possible de cette situation.

EXAMEN COMMANDE

VERIFICATION DU STOCK

(41)

 Modèle conceptuel des traitements Demande client Commande en attente a ou bet c EXAMEN COMMANDE Ok Ok Demande refusée Commande acceptée a VERIFIVATION SCTOCK Ok Ok Manquant APPR A C Stock disponible FACTURATION Tjrs livraison réglement Marchandise acceptée COMPTABILISATION OK NON-OK

(42)

Suite Facture soldée ARCHIVAGE Tjrs Facture archivée Facture Non-Soldée Date échéance RELANCE Tjrs Lettre de relance Retour marchandise MAJ Du Stock Tjrs Stock MAJ

(43)

IV°/ Vérification du modèle conceptuel des traitements

Règle 1 Un événement externe ne doit pas être le résultat d’une opération. Règle 2 Un événement interne doit être le résultat d’une opération.

Règle 3 Une synchronisation doit toujours pouvoir être réalisée.

Règle 4 Une même règle de gestion ne doit pas se trouver dans deux tâches différentes.

Règle 5 Un processus (ensemble d’opérations) doit être déclencher par un événement externe.

Règle 6 Il faut présenter tous les cas possibles dans les règles d’émission. Règle 7 Le MCT ne doit pas présenter le cas suivant :

Il ne faut pas avoir un événement qui présente une situation conflictuelle (un événement qui participe dans le déclenchement de deux opérations)

(44)

MODELE LOGIQUE DE DONNEES (MLD)

Le modèle logique des données (MLD) se situe entre le modèle conceptuel de données (MCD) et le modèle physique des données. (MPD) Il représente l’univers des données décrit dans le MCD en tenant compte du type de base de données choisi : relationnel ou navigationnel.

II°/ Le Modèle Logique de Données Relationnel

1°/ La normalisation du modèle de bases de données relationnelles

La normalisation consiste, à partir d’une relation dite universelle, à faire éclater celle-ci en plusieurs tables plus réduites grâce aux formes normales, qui sont basées sur les dépendances fonctionnelles.

L’objectif de la normalisation est de limiter le nombre de redondances et les anomalies lors de la mise à jour de la base de données.

PREMIERE FORME NORMALE 1FN

Une table est dite en 1FN si chacun de ses attributs dépend fonctionnellement de la clé et est non répétitive pour une occurrence de celle-ci.

Clé1.1 Clé1.2 Attribut1 Attribut2 Attribut3

DEUXIEME FORME NORMALE 2FN

Une table est dite en 2FN si chacun de ses attributs non-clé dépend complètement de la clé.

(45)

Une table est dite en 3FN si elle est en 2FN et s’il n’a pas de dépendances fonctionnelles entre les attributs non-clé.

LA FORME NORMALE DE BOYCE-CODD (BCFN)

Une table est dite en BCFN si elle est en 3FN et si elle ne contient pas de dépendances fonctionnelles autres que celles pour lesquelles un attribut clé détermine un attribut non-clé.

Exemple :

Soit la table suivante dont la clé est composée du numéro du produit et du numéro du fournisseur

CODP NUMF NOMF DESP PRXA PRXV NUMA NOMA

- Cette table est en 1FN.

- Cette table n’est pas en 2FN car une partie de la clé peut déterminer des attributs de cette relation.

La solution est de décomposer la relation de telle sorte d’avoir la 2FN. ACHAT

CODP NUMF PRXA

PRODUIT

CODP DESP PRXV NUMA NOMA

FOURNISSEUR

(46)

- La table PRODUIT n’est pas en 3FN car un des attributs non-clé peut déterminer un autre.

PRODUIT

CODP DESP PRXV NUMA NOMA

La solution est de décomposer la table PRODUIT en deux tables : PRODUIT

CODP DESP PRXV

ACHETEUR

NUMA NOMA

2°/ Les règles de passage du MCD au MLD relationnel a°/ Cardinalité de type (1, 1) – (X, N)

Nous sommes dans les cas suivants :

- (1,1) – (0, N)

- (1,1) – (1, N)

Règle 1 : Chacun des individus du MCD devient une table relationnelle du

MLD.

Règle 2 : L’identifiant des individus du MCD devient la clef des tables

relationnelles du MLD.

Règle 3 : Les propriétés portées par les individus du MCD deviennent

attributs des tables du MLD.

Règle 4 : L’identifiant de l’individu qui a la cardinalité (X, N) devient une clé

étrangère de la table générée par l’individu ayant la cardinalité (1,1)

Règle 5 : Si la relation liant les individus est porteuse de propriétés, celles-ci

deviennent attributs de la table générée par l’individu ayant la cardinalité (1,1)

Règle 6 : La relation disparaît.

Individu 1 Clef1 Prop1.1 Prop1.2 Prop1.3 Individu 2 Clef2 Prop2.1 Prop2.2 Prop2.3 relation Propr 1,1 X,N

(47)

Nous avons finalement de schéma du MLD suivant : Individu1 ( clé1, prop1.1, prop1.2, prop1.3, propr, clé2*) Individu2 ( clé2, prop2.1, prop2.2, prop2.3)

b°/ Cardinalité de type (X, N) – (X, N)

- (0,N) – (0, N)

- (1,N) – (0, N)

- (1, N) – (1, N)

- (0, N) – (1, N)

MLD.

Règle 4 : La relation liant les individus du MCD devient une table

relationnelle du MLD. Sa clef est constituée des identifiants des individus du MCD que la relation reliait au niveau du MCD.

Règle 5 : Si la relation liant les individus est porteuse de propriétés, ces

propriétés deviennent des attributs de la table relationnelle du MLD générée. Nous avons finalement de schéma du MLD suivant :

Individu1 ( clé1, prop1.1, prop1.2, prop1.3) Individu2 ( clé2, prop2.1, prop2.2, prop2.3) Relation (clé1, clé2, propr) Individu 1 Clef1 Prop1.1 Prop1.2 Prop1.3 Individu 2 Clef2 Prop2.1 Prop2.2 Prop2.3 relation Propr (X,,N) (X,N)

(48)

c°/ Cardinalité de type (1, 1) – (X, N) – (X,N) :

- (1,1) – (0, N) – (0,N)

- (1,1) – (0, N) – (1,N)

- (1,1) – (1,N) – (0,N)

- (1,1) – (1, N) – (1,N)

MLD.

Règle 4 : L’identifiant de l’individu qui a la cardinalité (X, N) devient une clé

étrangère de la table générée par l’individu ayant la cardinalité (1,1)

Nous avons finalement de schéma du MLD suivant :

Individu1 ( clé1, prop1.1, prop1.2, prop1.3, propr, clé2*, clé3*) Individu2 ( clé2, prop2.1, prop2.2, prop2.3)

Individu3 (clé3, prop3.1, prop3.2, prop3.3) Individu 1 Clef1 Prop1.1 Prop1.2 Prop1.3 Individu 2 Clef2 Prop2.1 Prop2.2 Prop2.3 relation Propr 1,1 X,N Individu 3 Clef3 Prop3.1 Prop3.2 Prop3.3 X,N

(49)

d°/ Cardinalité de type (X,N) – (X, N) – (X,N) :

- (0,N) – (0, N) – (0,N)

- (0,N) – (0, N) – (1,N)

- (0,N) – (1,N) – (1,N)

- (1,N) – (1, N) – (1,N)

MLD.

Règle 4 : La relation liant les individus du MCD devient une table

relationnelle du MLD. Sa clef est constituée des identifiants des individus du MCD que la relation reliait au niveau du MCD.

Nous avons finalement de schéma du MLD suivant : Individu1 ( clé1, prop1.1, prop1.2, prop1.3)

Individu2 ( clé2, prop2.1, prop2.2, prop2.3) Individu3 (clé3, prop3.1, prop3.2, prop3.3) Relation (clé1, clé2, clé3, propr) Individu 1 Clef1 Prop1.1 Prop1.2 Prop1.3 Individu 2 Clef2 Prop2.1 Prop2.2 Prop2.3 relation Propr X,N X,N Individu 3 Clef3 Prop3.1 Prop3.2 Prop3.3 X,N

(50)

e°/ Exercice d’application Soit : le MCD suivant :

MODELE CONCEPTUEL DE DONNEES

Question : Traduire le MCD ci-dessus en MLD relationnel.

BONS (NUMB, DATB, CODR, CODC, CODC*, CODR*) REPRESENTANT (CODR, NOMR)

CLIENT (CODC, NOMC, ADRC) PRODUIT (CODP, DESP, PRXU) CONTENIR (NUMB, CODP, QTEC)

BONS NUMB DATB CODR CODC REPRESENTANT CODR NOMR CLIENT CODC NOMC ADRC PRODUIT REFP DESP PRXU obtenir passer Contenir QTEC 1,1 0,n 0,n 1,1 1,0 0,n

(51)

III°/ Le Modèle Logique de Données CODASYL

1°/ Les règles de passage du MCD au MLD CODASYL a°/ Cardinalité de type (X, 1) – (X, N)

- (0,1) – (0, N)

- (1,1) – (1, N)

Règle 1 : Chacun des individus du MCD devient un record en MLD.

Règle 2 : Le record propriétaire correspond à l’individu ayant la cardinalité

(X,N). L’autre est memdre.

Règle 3 : L’identifiant des individus du MCD devient la clé des records du

MLD générés par ces l’individus.

champs des records générés.

Règle 5 : Si la relation entre les individus est porteuse de propriétés, celles-ci

migrent vers le membre, c’est à dire le record qui correspond à l’individu ayant la cardinalité (X,1).

Individu 1 Clef1 Prop1.1 Prop1.2 Prop1.3 Individu 2 Clef2 Prop2.1 Prop2.2 Prop2.3 relation Propr X,1 X,N Record Propriétaire Record Membre

(52)

Nous avons finalement le schéma suivant :

b°/ Cardinalité de type (X, N) – (X, N)

Règle 1 : Chacun des individus du MCD devient un record propriétaire en

MLD.

MLD générés par ces l’individus.

Règle 4 : La relation devient un record membre.

Règle 5 : La clé du record membre généré par la relation est constituée des

identifiants des deux individus qu’elle reliait au niveau conceptuel.

Règle 6 : Si la relation est porteuse de propriétés, celles-ci deviennent des attributs du record généré par la relation.

Individu 1 Clé1 Prop1.1 Prop1.2 Prop1.3 Propr Individu 2 Clé2 Prop2.1 Prop2.2 Prop2.3 Individu 1 Clef1 Prop1.1 Prop1.2 Prop1.3 Individu 2 Clef2 Prop2.1 Prop2.2 Prop2.3 relation Propr X,N X,N Individu 1 Clé1 Prop1.1 Prop1.2 Prop1.3 Individu 2 Clé2 Prop2.1 Prop2.2 Prop2.3 relation clé1 Clé2 propr

(53)

c°/ Cardinalité de type (X,1) – (X,1)

Dans le cas de cardinalité de type (x,1)-(x,1), il n’y a pas de règles de passage systématique au MLD. Il faut étudier les cas individuellement, selon les besoins du projet.

Le cas de (1,1)-(1,1) est un cas qui ne doit normalement pas se présenter.

d°/ Résumé des cas possibles

(0,1) (1,1) (0,N) (1,N)

(0,1) A traiter Cas par cas

A traiter Cas par cas

(0,n) Propriétaire (0,1) Membre

(1,n) Propriétaire (0,1) Membre (1,1) A traiter Cas par

cas (0,n) Propriétaire (1,1) Membre (1,n) Propriétaire (1,1) Membre (0,N) (0,n) Propriétaire (0,1) Membre (0,n) Propriétaire (0,1) Membre Individu1 propriétaire Individu 2 propriétaire Relation membre Individu1 propriétaire Individu 2 propriétaire Relation Membre (1,N) (1,n) Propriétaire (0,1) Membre (1,n) Propriétaire (1,1) Membre Individu1 propriétaire Individu 2 propriétaire Relation Membre Individu1 propriétaire Individu 2 propriétaire Relation membre

e°/ Cardinalité de type (X, 1) – (X, N) – (X,N)

Individu 1 Clef1 Prop1.1 Prop1.2 Prop1.3 Individu 2 Clef2 Prop2.1 Prop2.2 Prop2.3 relation Propr X,1 X,N Individu 3 Clef3 Prop3.1 Prop3.2 Prop3.3 X,N

(54)

Règle 2 : L’individu ayant la cardinalité (X,1) devient un record membre. Règle 3 : Les autres individus deviennent des records propriétaires.

MLD générés par ces individus.

Règle 6 : Si la relation est porteuse de propriétés, celles-ci deviennent des

attributs du record membre.

Individu 3 Clé3 Prop3.1 Prop3.2 Prop3.3 Individu 2 Clé2 Prop2.1 Prop2.2 Prop2.3 Individu 1 Clé1 Prop1.1 Prop1.2 Prop1.3 propr

(55)

f°/ Exercice d’application

MODELE CONCEPTUEL DE DONNEES

Question : Traduire le MCD ci-dessus en MLD CODASYL

BONS NUMB DATB CODR CODC REPRESENTANT CODR NOMR CLIENT CODC NOMC ADRC PRODUIT REFP DESP PRXU obtenir passer Contenir QTEC 1,1 0,n 0,n 1,1 1,0 0,n PRODUIT CODP DESP PRXU BONS NUMB DATB CODR CODC CONTENIR NUMB CODP QTEC REPRESE NTANT CODR NOMR CLIENT CODC NOMC ADRC