N°Com

advertisement
Sommaire
I. LA METHODE MERISE: INTRODUCTION ....................................................................................................... 3
I.1. LE SYSTEME D’INFORMATION DANS L’ENTREPRISE ........................................................................................ 3
I.2. Problématique ................................................................................................................................................. 4
I.3. Le but de projet ............................................................................................................................................... 4
II. Le Modèle Conceptuel de Données (MCD) ................................................................................................. 6
II.1. Les entités (des ensembles)............................................................................................................................ 6
II.2. Les attributs (des caractéristiques) ................................................................................................................ 7
II.3. Les associations (ou relations) ........................................................................................................................ 8
II.4. Les cardinalités (ou "combien" ?) ................................................................................................................... 8
II.5. Clef d'une entité (la base de la relation) ...................................................................................................... 10
II.5.a. Discussion sur la qualité d'une clef........................................................................................................ 11
II.5.b. La technique de la double clef............................................................................................................... 12
II.6. La forme des liens ..................................................................................................................................... 12
II.7. Attributs d'associations, pour aller plus loin .......................................................................................... 13
III. Le Modèle Logique de Données (MLD) .................................................................................................... 15
III.1. Tables, lignes et colonnes ............................................................................................................................ 15
III.2. Clés primaires et clés étrangères................................................................................................................. 15
III.3. Schéma relationnel ...................................................................................................................................... 16
III.4. Traduction d’un MCD en un MLDR .............................................................................................................. 16
IV. Le Modèle physique de données (MPD) .................................................................................................. 19
IV.1. Distinction entre MLD et MPD .................................................................................................................... 19
IV.2. Optimisations .............................................................................................................................................. 19
IV.3. Du MCD vers MPD ....................................................................................................................................... 19
IV.3.a. De la théorie à la pratique .................................................................................................................... 19
IV.3.b. Transformation des entités (passer de l'entité à la table) ................................................................... 20
IV.3.c. Ou placer les attributs d'association ? ................................................................................................. 22
V. Le modèle conceptuel de traitement (MCT) ............................................................................................. 24
V.1. Présentation ................................................................................................................................................. 24
V.2. Concepts manipulés, formalisme ................................................................................................................. 24
V.3. Construction du MCT.................................................................................................................................... 27
VI. Conseils divers (... et généreux pour aller plus loin) ................................................................................. 29
VI.1. Généralisation (héritage) (ramifier les espèces) ......................................................................................... 29
VI.2. Personnalisation (ou les sous-modèles) ...................................................................................................... 30
VI.3. Regroupement d'entités (un truc à connaître pour éviter la redondance) ................................................ 30
VII. Exemples de MCD pour mieux comprendre............................................................................................ 31
VII.1. Agence de location de films vidéo ............................................................................................................. 31
1
VII.2. Location d'appartements pour une agence immobilière ........................................................................... 32
VII.2. CAS NOTE.................................................................................................................................................... 33
VIII. Divers .................................................................................................................................................. 35
VIII.1. Bibliographie ............................................................................................................................................. 35
VIII.2. Références ................................................................................................................................................. 36
VIII.3. Outils de modélisation .............................................................................................................................. 36
2
I. LA METHODE MERISE: INTRODUCTION
I.1. LE SYSTEME D’INFORMATION DANS L’ENTREPRISE
L’entreprise peut être composé de en trois composantes : le système opérant, le système
de pilotage et le système d’information.
a. Le système opérant : système qui réalise toutes les tâches
d’exécution, transforme un flux physique d’entrée en un flux physique de
sortie.
Exemple : dans une usine automobile, ce sera la chaîne de montage avec
ses ouvriers.
b. Le système de pilotage : système de gestion, celui qui prend les
décisions, fixe les objectifs et les moyens de les atteindre. On peut dire
que c’est le système nerveux de l’entreprise. Il se compose par exemple
de la direction financière, direction commerciale, direction de
production,…
c. Le système d’information (SI) : sert à traiter l’information et la
véhiculer entre le système de pilotage et le système opérant. Le SI est
composé d’employés, ordinateurs, règles et méthodes etc.
Système de pilotage
Environnement
extérieur
Système d’information
Système opérant
La conception d'un système d'information n'est pas évidente car il faut réfléchir à
l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception
nécessite des méthodes permettant de mettre en place un modèle sur lequel on va
s'appuyer. La modélisation consiste à créer une représentation virtuelle d'une
réalité de telle façon à faire ressortir les points auxquels on s'intéresse. Ce type de
méthode est appelé analyse. Il existe plusieurs méthodes d'analyse, la méthode la
plus utilisée en France étant la méthode MERISE.
Le but de cette méthode est d'arriver à concevoir un système d'information. La
méthode
MERISE est basée sur la séparation des données et des traitements à effectuer en
plusieurs modèles conceptuels et physiques. La séparation des données et des
traitements assure une longévité au modèle. En effet, l'agencement des données
n'a pas à être souvent remanié, tandis que les traitements le sont plus
fréquemment.
3
Tout système d'information est composé d’une base d’information et d’un
processeur d’information qui représentent respectivement sa statique et sa
dynamique. A l’instar du Modèle Conceptuel des Données (MCD) qui schématise
les données du système d’information, le Modèle Conceptuel des Traitements
(MCT) décrit les traitements et plus précisément toutes les activités découlant des
échanges entre le domaine étudié et le monde extérieur. Il exprime donc ce que fait le domaine
sans se poser le problème de savoir qui le fait, quand et comment.
I.2. Problématique
Notre travail de recherche a pour objectif d’assurer compréhension de la
problématique de la gouvernance du système d’information : concepts, principes
et référentiels de bonnes pratiques.
La problématique de l'intégration repose sur la standardisation de données
internes à l'entreprise, mais aussi des données externes (provenant par exemple
de clients ou de fournisseurs).
Problèmes dans le système actuel
 Livraison à mauvaise adresse.
 Courrier en copies multiples.
 Obligation de rappeler à chaque communication téléphonique le nom, le
prénom, l’adresse, etc.
I.3. Le but de projet
Mise en place d’un système d’information pour gérer toutes les données
nécessaires au bon fonctionnement d’une entreprise.
 Comprendre et analyser les besoins en information de gestion.
 Dialoguer avec divers intervenants (directeur, informaticien).
 Contribuer à l’élaboration, l’implantation, l’exploitation et l’évolution du
système d’information de gestion de l’entreprise.
Ce projet a pour but d’introduire une méthodologie de conception du système
d’information en s’appuyant sur la méthode MERISE.
Pourquoi « Merise » ?
 Formaliser une réflexion.
 Discuter avec les donneurs d’ordres avec des descriptions compréhensibles
par la technique et la non-technique.
 Garder une trace compréhensible de la réflexion. Produire des documents
exploitables et synthétiques (plan du projet).
 Tendre vers une réalisation adaptée aux besoins
 Fournir des programmes structurés et donc maintenables
4
Une démarche intellectuelle à 3 niveaux :
5
II. Le Modèle Conceptuel de Données (MCD)
Le modèle entité-association est constitué de deux éléments de base :
 Les entités, qui sont des regroupements d'informations, et possèdent des
attributs (caractéristiques)
 Les associations qui sont les liens logiques entre les entités (et sont
quantifiées par des cardinalités)
II.1. Les entités (des ensembles)
Ce sont des regroupements d'informations. Les informations contenues dans les
entités (informations que l'on appelle "attributs") doivent être des informations
variables, mais communes à une même classe d'objets.
Par exemple, si l'on considère l'entité "être humain" les informations communes
aux être humains peuvent être :






le nom
le ou les prénoms
la date de naissance
le lieu de naissance
le sexe
l'adresse
etc...
On considère souvent qu'il s'agit de "classes" d'entités.
Une entité donnée peut elle-même être constituée de sous-classes.
Par exemple, un être humain donné peut habiter au même endroit qu'un autre (si
deux personnes vivent sous le même toit parce qu'ils sont mariés). Dans ce cas,
l'adresse constitue une sous-classe de l'entité "être humain", c'est à dire une
nouvelle entité à part entière.
D'un autre côté, il arrive souvent que plusieurs personnes résident au même
endroit, sans même se connaître (cas d'un immeuble collectif par exemple). Dans
ce cas on peut considérer l'adresse, comme une entité et la décrire de la manière
suivante :




Pays
Région
Département
Rue
etc...
On schématise une entité par un rectangle.
6
Exemple :
II.2. Les attributs (des caractéristiques)
Les attributs sont les caractéristiques décrivant les entités et doivent être
représentés comme une liste de mots, la plus simple possible, dans le cadre de
l'entité correspondante. On devra préciser le type des données attendues pour
chaque attribut.
Exemple :
Les types associés aux attributs sont les suivants :
D
Date
Annn
Caractères de longueur nnn
BL
Booléen (vrai / faux)
T
Temps
DT
Date Temps
N
Nombre
S
(Smallint) entier court
S
(Integer) entier
etc...
7
II.3. Les associations (ou relations)
Ce sont des liaisons logiques entre les entités.
Elles peuvent être de nature factuelle, ou de nature dynamique.
Par exemple, une personne peut acheter un objet (action d'acheter), mais si l'on
considère qu'une personne est propriétaire d'un objet, alors l'association entre
l'objet et cette personne est purement factuelle.
Les associations se représentent dans une ellipse (ou un rectangle aux extrémités
rondes), reliée par des traits aux entités qu'elles lient logiquement.
Exemple :
II.4. Les cardinalités (ou "combien" ?)
Les cardinalités, au sens arithmétique du terme, permettent de dénombrer les
éléments de l'entité d'arrivée en relation avec un élément de l'entité de départ, et
vice versa.
Exemple :
Considérons le cas de l'association "habite" et les deux entités "être humain" et
"appartement" du schéma précédent, les cardinalités minimales et maximales sont
les suivantes :


sens "être humain" vers "appartement" : 1 (minimum) et 1 (maximum)
sens "appartement" vers "être humain" : 0 (minimum) et n (maximum)
Ce qui signifie que dans cette modélisation un être humain réside dans un
appartement et un seul à la fois, mais qu’un appartement peut se trouver vide ou
être pourvu de plusieurs résidents.
Bien entendu tout être humain ne réside pas forcément dans un appartement, ce
peut être dans une maison, à l’hôtel ou à la belle étoile (SDF…). Mais il convient
de se concentrer sur ce que l’on doit modéliser et non sur l’univers entier.
8
En outre nous avons convenu qu’un même être humain ne pouvait résider dans
plusieurs appartements à la fois (notion de « résidence principale » par exemple).
On note les cardinalités de chaque côté de l'association, sur les traits faisant la
liaison entre l'association et l'entité.
Dès cet instant, on peut en déduire le type de relation parmi les types suivants : :
1/1, 1/n ou n/1 ou encore n/m.
Ici c’est une relation de type 1,n.
Pour déduire le type d’une relation, il suffit de récupérer les cardinalités maximales
des deux côtés de l’association, sans tenir compte de leur valeur exacte.
On peut s’y aider à l’aide des diagrammes de Wen et des notions de
mathématiques ensemblistes, bien connus de ceux qui ont pratiqués les maths
modernes dès leur plus jeune âge...
Entrent alors en jeu les notions de bijection, interjection, surjection...
Attention ! Des relations différentes entre mêmes entités peuvent posséder des
cardinalités différentes; c'est même souvent le cas.
9
Exemple :
La relation « loue » est de type n:m.
La relation « réside » est de type 1:n.
La relation « possède » est de type n:m.
II.5. Clef d'une entité (la base de la relation)
C'est un attribut (ou un ensemble d'attributs) qui permet (tent) de distinguer un
élément de l'entité de manière unique et sans aucune ambiguïté par rapport à
l'ensemble des autres éléments, et à l'univers de tous les éléments qui peuvent
entrer un jour ou l'autre dans cette entité.
Par exemple la clef de l'entité "être humain" pourrait être le nom. Mais comme le
cas d'homonymie est assez fréquent, surtout lorsque l'on manipule des fichiers
volumineux, alors cet attribut constitue une mauvaise clef en général.
En revanche, il n'est pas impossible que la clef d'une entité soit composée de
plusieurs attributs. Par exemple, la clef de l'entité "être humain" pourrait être le
nom et le prénom. Cependant il n'est toujours pas impossible d'avoir deux
perosnnes dont le nom et le prénom soient identiques...
On note qu'un attribut est une clef en le soulignant dans le schéma entité
association. Si c'est une clef composée, alors plusieurs entités seront soulignées.
Exemple :
10
On voit ici que dans le cas de l'entité "appartement" tous les attributs sont utilisés
pour composer la clef. Cette clef naturelle n'étant pas pratique, il est plus
judicieux de créer un nouvel attribut qui servira expressément de clef à
l'association.
Pour l'entité "être humain, on pourrait se servir du numéro de sécurité sociale
(plus exactement du numéro INSEE) , comme clef de l'entité. En revanche, pour
ce qui est de l'entité "appartement" il est conseillé de créer un nouvel attribut clef
qui serait, par exemple, un numéro.
Exemple :
Pour une entité de type « Voiture » il pourrait être fait usage de l’immatriculation
du véhicule comme clef de l’entité.
MAIS... lisez attentivement ce qui suit !
II.5.a. Discussion sur la qualité d'une clef
De manière générale il convient de limiter les clefs composées. Chaque fois que
l'on aura le choix entre la création d'une clef numérique, et une clef naturelle mais
composée, il sera préférable de créer une clef numérique, à de très rares
exceptions près.
En effet les SGBDR sont plus « à l’aise » lorsqu’ils ont à manipuler des clefs
purement numérique. De plus une clef est un concept purement informatique.
Par exemple le n° de sécurité sociale est une mauvaise clef en générale : un
individu étranger qui arrive sur le sol français est doté d’une immatriculation
provisoire et ne connaît son numéro définitif que plusieurs mois après avoir rempli
les conditions requises par l’administration.
Par exemple l’immatriculation d’un véhicule est une mauvaise clef : en effet, du
fait de la fiscalité sur les véhicules à moteur (et en particulier les vignettes), les
sociétés n’hésitent pas à faire immatriculer leur parc de véhicules dans le
département où les taxes sont les moins élevées (le 51). Cette immatriculation
peut donc être amenée à changer.
Or toute clef évolutive est un danger pour le système informatique : si la valeur de
la clef change, nous verrons qu’il faut la modifier dans tous les fichiers dans
laquelle elle est référencée. Il est vrai que certains SGBDR autorise
automatiquement ce genre de manœuvre, mais cette automatisation très
contraignante pénalise lourdement le fonctionnement du SGBDR.
11
On veillera donc à prendre une clef totalement indépendante des attributs
ordinaires de l’entité.
De plus une clef a intérêt à être la plus courte possible afin que son stockage soit
limité à quelques octets dans les fichiers et donc le temps de recherche le plus
rapide possible.
Le plus simple consiste donc à introduire dans le descriptif de l’entité une clef
strictement « informatique » qui se résumera en général à un numéro (entier
long) que l’on pourra incrémenter automatiquement.
Parfois, il arrive qu’une clef ait été créée spécifiquement pour les besoins des
systèmes informatiques. C’est en particulier le cas des indicatifs téléphoniques (33
pour la France) ou des code de pays (F pour France). Dans ce dernier cas on devra
alors utiliser la clef commune, comme clef de l’entité.
II.5.b. La technique de la double clef
Une technique éprouvée consiste à introduire une double clef dans toutes les
tables : la clef « informatique » et une clef « utilisateur ».
La clef informatique est l’index primaire de la table et doit posséder les
caractéristiques suivantes :







purement numérique (par exemple un entier long)
unique bien entendu
obligatoire
sans mise à jour en cascade
avec intégrité référentielle
générée automatiquement
invisible pour l’utilisateur
La clef utilisateur doit être assez « souple », c’est à dire posséder dans la mesure
du possible, les caractéristiques suivantes :




Index secondaire unique
Obligatoire
Utiliser un jeu de caractère réduit s’il s’agit d’un format alpha (par exemple
les 26 lettres majuscules de l’alphabet et les chiffres de 0 à 9)
Limité à une faible taille (16/32 octets - 16 caractères maximum)
La présentation des données devant toujours s’effectuer suivant l’ordre établis par
la clef utilisateur à défaut d’autre spécification.
II.6. La forme des liens
La plupart des associations sont de nature binaire, c'est à dire composées de deux entités
mise en relation par une ou plusieurs associations.
C'est le cas par exemple de l'association "est propriétaire" mettant en relation "être humain" et
"appartement".
12
Cependant il arrive qu'une association concerne plus de deux entités (on dit alors qu'il s'agit
d'association "n-aires").
Exemple :
Mais dans ce cas il y a de grandes difficultés pour exprimer les cardinalités.
On aura tout intérêt à essayer de transformer le schéma de manière à n'obtenir que des
associations binaires.
Exemple :
II.7. Attributs d'associations, pour aller plus loin
Il arrive parfois que l'on soit obligé de munir d'attributs des associations.
considérons par exemple, que nous voulons modéliser les relations existant entre les entités
"client", "commande" et "article" :
Exemple :
13
Mais comment dans ce schéma introduire l'attribut "quantité" et plus encore l'attribut
"réduction" dont on voudrait qu'il puisse s'appliquer à chacun des articles d'une commande de
manière différente ?
En effet si l'on introduit l'attribut quantité à l'entité COMMANDE, chaque ligne de la commande
se verra dotée de la même quantité...
D'autre part si l'on introduit l'attribut quantité à l'entité ARTICLE alors chacun des article se
verra doté de la même quantité quelque soit la commande...
La solution est de pourvoir l'association "composée" des attributs "quantité" et "réduction" :
Il arrive dans certains cas que l'attribut "date" soit d'une importance capitale, notamment dans
les applications SGBDR portant sur la signature de contrats à échéance ou dans la durée
(assurance par exemple).
Il n'est pas rare alors que le seul attribut "date" constitue à lui seul une entité.
Exemple :
On appelle alors cela une entité temporelle. Une entité temporelle possède souvent un seul
attribut, mais dans le cas ou elle possède plusieurs attributs (année, mois, jour, heure, minute,
seconde...), l'ensemble de ces attributs constitue alors la clef de l'entité.
Mais dans ce cas on peut aussi retirer cette entité et introduire la date en tant qu'attribut de
l'association "souscrit".
14
III. Le Modèle Logique de Données (MLD)
Après la modélisation avec le MCD (Entité- Association), on peut le traduire
en différents systèmes logiques et notamment les bases de données relationnelles
qui proposent une vision plus concrète pour modéliser la situation.
Avant l’apparition des systèmes de gestion de base de données (SGBD), les
données s´étaient stockées dans des fichiers binaires et gérées par des
programmes exécutables (développes en Basic, Cobol ou Dbase…) Mais la
maintenance des programmes (en cas de modification de la structure des
données, notamment) était très problématique.
Sont alors apparus les SGBD hiérarchiques dans lesquels les données sont
organisées en arbre (IMS- DL1 d’IBM, par exemple), puis les SGBD réseaux dans
lesquels les données sont organisées selon un graphe plus général (IDS2 de Bull,
par exemple).
Ces deux types de SGBD sont dits navigationnels car on peut retrouver
l’information à condition d’en connaître le chemin d’accès.
Aujourd’hui, ils sont largement remplacés par les SGBD relationnels (SGBDR)
avec lesquels l’information peut être obtenue par une requête formulée dans un
langage quasiment naturel (le langage SQL pour Structured Query Langage).
Parmi les SGBDR les plus répandus nous trouvons Oracle, SQL Server et DB2.
III.1. Tables, lignes et colonnes
Lorsque des données ont la même structure (comme par exemple, les
renseignements relatifs aux clients), on peut les organiser en table dans laquelle
les colonnes décrivent les champs en commun et les Lignes contiennent les
valeurs de ces champs pour chaque enregistrement
N°Stagiaire
1
2
3
Nom
Hassani
Masoudi
Rami
Prénom
Wafae
Ahmed
Hassan
Ville
Fès
Casa
rabat
III.2. Clés primaires et clés étrangères
Les lignes d’une table doivent être uniques, cela signifie qu’une colonne (au
moins) doit servir à les identifier. Il s’agit de la clé primaire de la table.
L’absence de valeur dans une clé primaire ne doit pas être autorisée.
Autrement dit, la valeur vide (NULL). De plus, la valeur de la clé primaire d’une
ligne ne devrait pas, en principe, changer au cours du temps.
Par ailleurs, il se peut qu’une colonne Colonne1 d’une table ne doive contenir
que des valeurs prises par la colonne Colonne2 d’une autre table (par exemple, le
numéro du client.) La Colonne2 doit être sans doublons. On dit alors que la
Colonne1 est clé étrangère et qu’elle référence laColonne2
15
Par convention, on souligne les clés primaires et on fait précéder les
clés étrangères d’un dièse # dans la description des colonnes d’une
table:
Clients (numéro_client, nom client, prénom, adresse client)
Commandes (numéro_commande, date de commande, #numéro client (non vide))
III.3. Schéma relationnel
On peut représenter les tables d’une base de données relationnelle par un
schéma relationnel dans lequel les tables sont connecteur.
Commandes
Clients
numéro_commande
numéro_client
Date de commande
Nom client
#numéro client
Prénom
Adresse client
III.4. Traduction d’un MCD en un MLDR
Pour traduire un MCD en un MLDR, il suffit d’appliquer cinq règles.
Règle 1 : toute entité devient une table dans laquelle les attributs
deviennent les colonnes. L'identifiant de l'entité constitue alors la clé primaire de
la table.
Par exemple, l'entité articles devient la table :
Articles (numart , désignation, prix unitaire)
Articles
numArt
Désignation
Prix unitaire
Règle2 : une association binaire de type 1:n disparaît, au profit d'une clé
étrangère dans la table côté 0,1 ou 1,1 qui référence la clé primaire de l'autre
table. Cette clé étrangère ne peut pas recevoir la valeur vide si la cardinalité est
1,1.
16
Exemple: l'association livrer [Traduction d'une association de type1:n]
Fournisseurs (N° fournisseur, nom contact, N°téléphone)
Livraisons (N° livraison, date de livraison, nom livreur, # N°fournisseur (non vide))
Fournisseurs
Livraisons
N° fournisseur
Nom contact
N° livraison
1,n
Livrer
N°
téléphone
1,1
Date de livraison
Nom livreur
N°fournisseur
T
r
a
d
u
c
t
i
o
n
Livraisons
Fournisseurs
N° fournisseur
N° livraison
Nom contact
Date de livraison
N°
téléphone
Nom livreur
#N°fournisseur
Il ne devrait pas y avoir d'attribut dans une association de type 1:n, mais s’il en
reste, alors ils glissent vers la table côté 1.
Règle 3: une association binaire de type n:m devient une table
supplémentaire (parfois appelée table de jonction, table
de
jointure ou table d'association) dont la clé primaire est composée de deux clés
étrangères (qui référencent les deux clés primaires des deux tables en
association). Les attributs de l'association deviennent des colonnes de cette
nouvelle table.
Exemple: l'association concerner est traduite par la table supplémentaire lignes de
commande:
Lignes de commande (#N◦ commande, #N◦article, quantité commandée)
Commandes
Articles
N°Comm
Concerner
Numéro article
Date Comm
Quantité
Désignation
Prix unitaire
T
r
a
d
u
c
t
i
o
n
Cmds
N°Com
Date
Comm
LignesCom
#N◦ comm
Articles
Num_article
#N◦article
Désignation
Quantité
Prix unitaire
Règle 4 : 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é en plus d'une
éventuel le contrainte de non vacuité.
S'il existe au moins un côté de cardinalité 0,1. C’est alors dans la table du côté opposé que
doit aller la clé étrangère. Si les deux côtés sont de cardinalité 0,1 alors la clé étrangère peut être
placée indifféremment dans l'une des deux tables.
17
Exemple: l'association diriger est traduite par:
Services (N°service, nom service, #N° employé (non vide, unique))
Employés (N°employés, nom)
Employés
Services
N°employés
N°service
Nom
1,0
T
r
a
d
u
c
t
i
o
n
Nom service
Diriger
1,1
#N° employé
Employés
Services
N°employés
N°service
Nom
Nom service
#N° employé
Règle 5 : 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 des colonnes de cette nouvelle table.
Exemple: l'association projeter: Projections(#N°film, #N°salle, #N°créneau, tarif)
Projeter
Salles
Créneaux horaires
N° salle
N°créneau
Projeter
Date
Heure début
Créneaux horaires
1,1
0,n
N°créneau
Capacité
Date
Hdébut
Tarif
Salles
#N° salle
N° salle
#N° film
Capacité
#N°créneau
Tarif
1,n
Films
N° film
Films
T r a d u c t i o n
N° film
Titre
Titre
Durée
Durée
18
IV. Le Modèle physique de données (MPD)
Un modèle physique de données est l'implémentation particulière du modèle logique de
données par un logiciel.
IV.1. Distinction entre MLD et MPD
La traduction d'un MLD conduit à un MPD qui précise notamment le stockage de chaque
donnée à travers son type et sa taille (en octets ou en bits). Cette traduction est également
l'occasion d'un certain nombre de libertés prises par rapport aux règles de normalisation afin
d'optimiser les performances du système d'information.
La traduction d'un MLD relationnel en un modèle physique est la création (par des
requêtes SQL de type CREATE TABLE et ADD CONSTRAINT) d'une base de données
hébergée par un SGBD relationnel particulier. Il peut s’agir d'une base Oracle, d'une base SQL
Server, d'une base Access…, par exemple. Le fait que tous les SGBDR reposent sur le même
modèle logique (le schéma relationnel) permet à la fois la communication entre des bases
hétérogènes et la conversion d'une base de données d'un SGBDR à l'autre.
IV.2. Optimisations
L'optimisation des performances en temps de calcul se fait toujours au détriment de
l'espace mémoire consommé. Dans le pire des cas, réduire les temps de réponse consiste à
dénormaliser volontairement le système d'information, avec tous les risques d'incohérence et
les problèmes de gestion que ce la comporte.
Pour les bases de données relationnelles, l'optimisation qui vise à accélérer les requêtes peut
passer:
 L'ajout d'index aux tables (au minimum sur les colonnes clés primaires et clés
étrangères); ces index consomment de l'espace mémoire supplémentaire, mais la base de
données reste normalisée;
 l'ajout de colonnes calculées ou de certaines redondances pour éviter des jointures
coûteuses (au- quel cas la base est dénormalisée); il faut alors veiller à ce que la cohérence
entre les colonnes soit respectée, soit par l'utilisation de déclencheurs, soit dans les
applications clientes du système d'information;
 la suppression des contraintes d'unicité, de non vacuité ou encore de clé étrangère
(auquel cas, l'intégrité des données doit être assurée par le code client du système
d'information).
IV.3. Du MCD vers MPD
IV.3.a. De la théorie à la pratique
Ce que nous venons de voir concerne l'analyse conceptuelle des données, c'est à dire un
niveau d'analyse qui s'affranchi de toutes les contraintes de la base de données sur lequel va
reposer l'application. Une fois décrit sous forme graphique, ce modèle est couramment appelé
MCD pour "Modèle Conceptuel des Données".
19
Dès lors, tout MCD peut être tansformé en un MPD ("Modèle Physique des Données") c'est à
dire un modèle directement exploitable par la base de données que vous voulez utiliser...
Tout l'intérêt de cet outil d'analyse est de permettre de modéliser plus aisément les relations
existant entre les entités et d'automatiser le passage du schéma muni d'attributs aux tables de
la base de données pourvues de leurs champs.
Voici maintenant les règles de base nécessaire à une bonne automatisation du passage du
MCD au MPD :
IV.3.b. Transformation des entités (passer de l'entité à la table)
Règle n°1 : toute entité doit être représentée par une table.
o Relation de type 1:1 (la voix de la simplicité)
Règle n°2 : Dans le cas d'entités reliées par des associations de type 1:1, les tables
doivent avoir la même clef.
Exemple :
NOTA : on aurait pu choisir l'autre clef comme clef commune, à savoir le n° d'appartement.
20
Bien que certains systèmes proposent une autre solution :
Dans ce cas une étude approfondie de la solution à adopter est nécessaire, mais ce type de
relation est en général assez rare et peu performante...
o Relation de type 1:n (maître et esclave)
Règle n°3 : Dans le cas d'entités reliées par des associations de type 1:n, chaque table
possède sa propre clef, mais la clef de l'entité côté 0,n (ou 1,n) migre vers la table côté
0,1 (ou 1,1) et devient une clef étrangère (index secondaire).
Exemple :
o Relation de type n:m (plusieurs à plusieurs)
Règle n°4 : Dans le cas d'entités reliées par des associations de type n:m, une table
intermédiaire dite table de jointure, doit être créée, et doit posséder comme clef
primaire une conjonction des clefs primaires des deux tables pour lesquelles elle sert
de jointure.
21
Exemple :
IV.3.c. Ou placer les attributs d'association ?
Règle n°5 : Cas des associations pourvues d'au moins un attribut :



si le type de relation est n:m, alors les attributs de l'association deviennent des
attributs de la table de jointure.
si le type de relation est 1:n, il convient de faire glisser les attributs vers l’entités
pourvue des cardinalités 1:1.
si le type de relation est 1:1, il convient de faire glisser les attributs vers l’une ou
l’autre des entités.
Pour synthétiser toutes ces règles, voici un exemple de modélisation d'une application. En
l'occurrence il s'agit d'un service commercial désirant modéliser les commandes de ses
clients.
22
Exemple :
23
V. Le modèle conceptuel de traitement (MCT)
V.1. Présentation
Le mct est une représentation schématique de l activité de l entreprise indépendamment des
choix d’organisation et des moyens d’exécution (le quoi faire).
Le MCD donne une vision statique de l’entreprise, le MCT donne une vision dynamique de
l’entreprise. Le MCT répond à la question Quoi ? C.-à-d. exprime ce qu’il faut faire sans
préciser ni quand ni comment le faire.
Le point de départ de l’élaboration du MCT est le graphe de flux ou la matrice des flux.
On utilisera un formalisme manipulant les concepts :
 D’événements : fait déclenchant une ou plusieurs actions,
 D’opérations : ensemble d’actions non interrompues,
 De processus : enchaînement d’opérations dont les actions sont incluses dans un
même domaine d’activité,
 De résultat : produit de l’exécution d’une opération,
Auxquels on associe des règles de synchronisation et d’emissions que nous allonsétudier
maintenant.
V.2. Concepts manipulés, formalisme
a. Evénement : Fait réel dont la venue a pour effet de déclencher l’exécution
d’une ou de plusieurs actions. (un événement informe le SI qu’il se passe
quelque chose et qu’il faut réagir).
Exemple : arrivée d’une commande, demande d’inscription.
On distingue les types d’événements suivants :
 Evénement externe : déclencheur externe.
Exemple : Demande de promotion (déclenche le processus).
Promotion accordée (résultat de processus).
 Evénement interne : Résultat d’une opération et déclenche une autre.
Schématisé de la manière suivante :
Evénement
Exemple : dossier ouvert
b. Opération : Ensemble d’actions définies par les RG en réaction à un ou
plusieurs événements, non interrompues c.à.d non soumis à l’attente de
nouveaux événements.
Une opération est constitués de +eurs actions qui st exécutable sans interruptions
24
Elle est déclenchée pour la sollicitation d un événement et fournir des résultants.
Exemple : l’opération préparation d’une commande regroupe les actions non
interrompues suivantes :
 Détermination des produits et des quantités à commander.
 Choix du fournisseur.
 Rédaction d’un bon de commande.
Une opération produit en sortie de nouveaux événements.
Schématisé de la manière suivante :
Num op
Operation
Action 1
Action 2
……
c. Synchronisation : la synchronisation d’une opération est une condition sur
les événements déclenchant l’opération.
Cette condition peut porter sur :
 La valeur de propriété de l’événement exemple : date = 25 du mois.
 Le nombre d’occurrence de l’événement exemple : 4 pièces.
Elle peut aussi comporter une partie logique utilisant les opérateurs Et, Ou et Non.
Si l’opération est déclenchée sans aucune condition, on dit qu’elle est sans attente.
Schématisé de la manière suivante :
Opération
d. Règle d’émission : les règles d’émission traduisent les règles de gestion à
laquelle est soumise l’émission des résultats d’une opération.
Les règles d’émission sont généralement de type :
 OK, non OK
 Ou bien indiquées au bas de l’opération avec leurs libellés.
25
Schématisé de la manière suivante :
Num op
Operation
Actions
OK
Non OK
e. Processus : Dans le cas ou le MCT est compliqué, on le décompose en
processus.
Un processus est un enchaînement d’opérations incluses dans un même domaine
d’activité. Il faut réaliser autant de MCT qu’il y a de processus dans l’entreprise.
f. Résumé de formalisme de MCT
Evt2
Evt1
Evt3
Synchronisation
(A et B) ou (B et C) ou (C et non A)
(Nbocc de A = 3) et (Nbocc de B = 2)
(valeur de Evt1=…)
Num opération
Opération
Action 1
Action 2
.
.
Règle1
Règle2
.
Evt4
Résultat1
Exemple : Dans une société de demande de promotion sont traités selon les RG suivantes :
RG1 : toute demande de promotion doit subir un examen préalable pour déterminer si elle est
recevable ou non.
26
RG2 : l’examen de dossier d’une demande recevable ne peut se faire qu’après rapport du
supérieur hiérarchique.
RG3 : après examen du dossier, la promotion est accordée ou refusée.
MCT correspondant :
Demande de
promotion
Evénement externe
Pas d’attente
Opération
Examen préalable
OK
Evénement
interne
intermédiaire
Non OK
Dossier ouvert
Règles d’émission
Rejet
Rapport
A
Evénement interne
(résultat)
Evénement externe
B
Synchronisation
A et B
Opération
Examen Dossier
OK
Non OK
Promotion
accordée
Règles d’émission
Promotion
refusée
Evénement résultat
V.3. Construction du MCT
g. Mécanisme de construction du modèle
 Etablir les RG
 Construire le graphe de flux (ou matrice de flux)
 Ordonnancer les flux d’informations sélectionnés en partant du flux qui
déclenche le processus
27
 Identifier les processus si cela est nécessaire
 Etablir le MCT brut par processus.
Tout flux du graphe de flux devient un événement du MCT
Il faut penser éliminer les traitements redondants.
h. Description des événements et des opérations
Parallèlement au schéma du MCT, on établit :
 Une description des événements qui précise :
-
le nom de l’événement
exemple : commande client
-
sa nature
exemple : externe
-
ses propriétés
exemple : code client, produit commandé
 Une description des opérations qui précise :
-
le processus correspondant
-
la définition de l’opération
-
les événements qui la déclenchent
-
les événements émis
-
les règles d’émission
-
les actions sur la base
i. Règles de vérification du MCT
R1 : Un processus doit être déclenché par un événement externe.
R2 : Un événement externe.
R3 : Un événement interne est le résultat d’une opération.
R4 : Une synchronisation doit toujours pouvoir se réaliser.
R5 : L’ensemble des règles d’émissions d’une opération doit être complet et disjoints.
R6 : Le MCT ne doit présenter de cycles c.à.d l’événement final ne doit pas générer à
nouveau le processus.
R7 : Si une synchronisation porte sur la valeur d’une propriété, cette propriété doit être
portée par l’événement participant à la synchronisation.
R8 : Une même RG ne doit pas se trouver dans deux actions différentes.
R9 : Une opération est toujours rattachée à un processus.
R10 : Une règle d’émission peut activer un ensemble d’événements.
R11 : Une opération est toujours activée par un ensemble d’événements via une
synchronisation.
28
VI. Conseils divers (... et généreux pour aller
plus loin)
VI.1. Généralisation (héritage) (ramifier les espèces)
Dans le schéma ci-dessous, les entités "Personne physique" (des êtres humains) et
"Personne morale" (des sociétés, associations, collectivités, organisations…) sont
généralisées dans l'entité "Propriétaire".
On dit aussi que l'entité "Propriétaire" est une entité parente et que les entités "Personne
morale" et "Personne physique" sont des entités enfants, car il y a une notion d’héritage...
Exemple :
Par exemple une entité "Etre humain" est une généralisation pour toute entité faisant appel à
une personne, comme les entités "Etudiant", "Client", "Artiste", "Souscripteur", "Patient",
"Assujetti"...
On les appelle aussi "entités-génériques".
Certains ateliers de modélisation représentant les données sous la forme d’entités «
encapsulés ».
29
Exemple :
VI.2. Personnalisation (ou les sous-modèles)
Une personnalisation est un regroupement dans une super entité de plusieurs entités munies
d'une ou de plusieurs associations.
Par exemple, une compagnie d'aviation proposant des vols peut modéliser le planning des
pilotes par le schéma suivant :
VI.3. Regroupement d'entités (un truc à connaître pour éviter la redondance)
Comme toute technique, le schéma entité-association possède des limites et des contraintes
que seuls l'expérience et le bon sens peuvent permettre d'éliminer.
Il arrive parfois que certaines entités apparaissent comme redondantes. Dans ce cas, et pour
gagner de la place en matière de stockage de l'information, il convient de regrouper ces
entités dans une seule et même table du SGBDR en ajoutant un champ supplémentaire à
cette table de manière à permettre de distinguer les entités du schéma théorique.
Par exemple si l'on désire modéliser une gestion de compact-disc on peut créer une entité
"Compositeur" et une entité "Interprète". Mais on constate qu'une grande majorité de
30
compositeurs sont leurs propres interprètes, ce qui signifie qu'une même personne peut se
trouver présente dans les deux entités. Pour résoudre ce problème il suffit de construire une
seule table pour les deux entités (par exemple une table "MUSICIEN") et d'y ajouter un champ
permettant de distinguer le type de "musicien" : compositeur ou interprète ou les deux.
VII. Exemples de MCD pour mieux
comprendre
VII.1. Agence de location de films vidéo
Lors de la réalisation de la base de données, les entités RÉALISATEUR et ACTEUR peuvent
être regroupées en une seule table car il y a un nombre non négligeable de réalisateurs qui
31
sont acteurs, et vice-versa. Dans ce cas, un champ d'un seul caractère permettra de faire la
différence entre un réalisateur pur, un acteur pur et un acteur réalisateur.
Notez aussi les cardinalités entre les entités ACTEUR et FILM, en effet, un film d'animation ne
possède aucun acteur.
Dans l'entité EXEMPLAIRE figure un attribut "dispo" permettant de savoir si l'exemplaire n°X
d'un film est disponible ou en cours d'emprunt.
VII.2. Location d'appartements pour une agence immobilière
NOTA : pour simplifier l'écriture, ne figurent dans ce schéma que les attributs clefs ou les
attributs d'associations.
32
VII.2. CAS NOTE
Soit la liste des données recensées dans un établissement scolaire et présentées par ordre
alphabétique :









Adresse de l’élève
Matière enseignée
Nombre d’heures
Nom de la classe
Nom de l’élève
Nom du professeur
Note
Numéro de salle
Prénom de l’élève
Règles de gestion :
A chaque classe est attribuée une et une salle de cours
Chaque matière n’est enseignée que par un et un seul professeur
Pour chaque classe et chaque matière est défini un nombre fixe d’heures de cours
A chaque élève est attribuée une seule note par matière
L’établissement gère les emplois du temps des professeurs et des élèves ainsi que le contrôle
de connaissances.
33
Cas NOTE (MCD et MPD)
Elève
appartient
1,1
id_élève
Nom
Prénom
Adresse
a pour note
0,n
note
1,n
Classe
id_salle
classe
0,n
a pour matière
1,n
1,n
nbre heures
Matière
id_matière
matière
1,1
est enseignée par
1,n
Professeur
id_prof
professeur
Elève
id_élève
id_salle
Nom
Prénom
Adresse
appartient
a pour note
lien_35
id_élève
id_matière
note
lien_36
Classe
id_salle
classe
lien_29
a pour matière
id_salle
id_matière
nbre heures
lien_30
Matière
id_matière
id_prof
matière
34
est enseignée par
Professeur
id_prof
professeur
VIII. Divers
VIII.1. Bibliographie
Les trois livres "historiques" (le "vert", le "bleu" et le "rouge") qui décrivent précisément la
méthode:



Hubert Tardieu, Arnold Rochfeld, René Colletti (1983). La méthode Merise - Tome 1
Principes et outils. Editions d'organisation (Paris) : 328 p. ISBN 2-7081-1106-X.
Hubert Tardieu, Arnold Rochfeld, René Colletti, Georges Panet, Gérard Vahéee (1985). La
méthode Merise - Tome 2 Démarches et pratiques. Editions d'organisation (Paris) : 460
p. ISBN 2-7081-0703-8.
Arnold Rochfeld, José Morejon (1989). La méthode Merise - Tome 3 Gamme opératoire.
Editions d'organisation (Paris) : 264 p. ISBN 2-7081-1057-8.
Il est juste aussi d'associer à cette bibliographie minimale, le livre très accessible d'un des
créateurs de la méthode, qui historiquement, a suivi son chemin de son côté

Yves Tabourier (1986). De l'autre côté de Merise. Editions d'organisation (Paris)
Sur Merise/2, on consultera également :












Georges Panet, Raymond Letouche (1994). Merise/2 - Modèles et techniques avancées.
Editions d'organisation (Paris) : 366 p. ISBN 2-7081-1653-3.
La méthode MERISE, principes et outils (Tome 1 & 2) - TARDIEU, ROCHFELD,
COLLETTI - Les éditions d'organisation 1986
Conception de bases de données : du schéma conceptuel au schéma physique GALACSI - Dunod 1989
Modélisation dans la conception des systèmes d'information - ACSIOME - Masson 1990
Apprendre et pratiquer MERISE - J. GABAY - Masson 1993
Maîtriser les bases de données – Georges GARDARIN – Eyrolles 1993
Concepts fondamentaux de l’informatique – Alfred AHO, Jeffrey ULLMAN – Dunod 1993
Bases de Données et Modèles de Calcul - Outils et Méthodes pour l’Utilisateur - Jean-Luc
HAINAUT - InterEditions 1994
MERISE, vers une modélisation orientée objet – José MOREJON – Les Editions
d’Organisation 1994
AMC*Designor, mise en œuvre de MERISE – Gilles GUEDJ – Eyrolles 1996
Introduction aux bases de données, 6e édition– Chris J. DATE – Thomson International
Publishing 1998
De UML à SQL - Christian SOUTOU - Eyrolles 2002
35
VIII.2. Références
1. ↑ Jean-Baptiste Waldner, CIM, les nouvelles perspectives de la production,
Paris, Bordas, coll. « Dunod informatique », 1990, broché, 165 p. (ISBN 2-04-0198202 et 978-2-04-019820-6)
2. ↑ Michel Diviné (préf. Hubert Tardieu, ill. Pierre Legué), Parlez-Vous Merise ?, Les
Éditions du phénomène, 1994, eBook, 258 p.
VIII.3. Outils de modélisation
DataBase Design
Studio de Chili
Source Software
http://www.chillisource.com/
DeZign for
DataBases de
Datanamic
http://www.datanamic.com/
ERWin de
Computer
Associates
http://www3.ca.com/Solutions/Product.asp?ID=260
Mega Suite de
http://www.mega.com/
Mega International
PowerDesigner de
PowerSoft (ex
http://www.sybase.com/products/enterprisemodeling/powerdesigner
AMC*Designor)
RoboCase de DB
http://www.dblogic.com/
Logic Inc
Visible Analyst de
Visible Systems
http://www.visible.com/Products/Analyst/overview.html
Corporation
Win'Design de
Cecima
http://www.win-design.com/fr/index.htm
xCase de
Resolution
http://www.xcase.co.il/
DataArchitect de
http://www.thekompany.com/products/dataarchitect/
36
theKOMPANYcom
Rational Rose de
http://www.rational.com/
Rational Software
Studio 2 de
CaseStudio
http://www.casestudio.com
ER Studio de
Embarcadero
http://www.embarcadero.com/
Visio de Microsoft
(ex infomodeler de http://www.microsoft.com/office/visio/
Synactics)
Silverrun de
Magna solutions
http://www.silverrun.com/
System Architect
de Popkin
http://www.popkin.com/products/sa2001/systemarchitect.htm
Designer 2000
d'Oracle (mono
base)
http://www.oracle.com/ (???)
Casewise
http://www.casewise.com/
QuickUML de
Excel (Linux et
Windows) de
Excel Software
http://excelsoftware.com/quickumllinuxnews100.html
MacA&D /
WinA&D de Excel http://excelsoftware.com/richdatamodel.html
Software
Select d'Aonix
http://www.aonix.com/
37
Téléchargement