[ãÍÈ ÈáÇÏå]

ÇáãÔÇÑßÉ ÇáÃÕáíÉ ßÊÈÊ ÈæÇÓØÉ kakaiove

ÃÑÌæß ÃÎí ÃäÇ ÃÑíÏ ÈÍË Íæá ØÑíÞÉ ãæÑíÒ íßæä ÔÇãá æ ßÈíÑ æÔßÑÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇÇ

Qu'est-ce que MERISE ?

MERISE est une méthodologie à laquelle beaucoup d'outils de développement informatique s'affilient et pour laquelle cette affiliation s'avère généralement restrictive voire incorrecte.
Cette page n'a pas la prétention de faire une description précise de MERISE mais d'en faire le survol de manière à ce qu'elle puisse servir de présentation (forcément succincte) à ceux, informaticiens ou non, qui pourraient y être confrontés.
Présentée souvent comme une méthode d'analyse informatique, MERISE est surtout une démarche (certains parlent "d'état d'esprit ") pour l'établissement de système d'information et en cela MERISE sort du domaine de l'informatique pour s'intéresser à la gestion même de l'organisation concernée.
I. Démarche

MERISE propose une véritable démarche de fabrication d'un SI qui consiste à traiter un projet informatique en s'appuyant sur trois notions fondamentales:

• Vie du projet : Les étapes.

• Suivi du projet : Les choix, les points de validation des étapes.

· Formalisation du projet : l'abstraction des différentes étapes.
1. Schéma directeur2. Etude préalable3. Analyse détaillée4. Analyse technique5. Réalisation6. Maintenance 1. Etablissement du schéma directeur

Le schéma directeur fixe les grandes orientations :

• Choix d'organisations : Définition du SI.

• Choix stratégiques :
  • Matériels.
  • Logiciels.
  • Architectures.
  • Définition du SAI.

L'établissement du schéma directeur est une tâche permanente qui est alimentée par les différentes études des différents projets ainsi que par l'évolution des techniques et organisations.
2. L'étude préalable

· Référencer les moyens existants.
· Audit des différents acteurs de l'organisation pour définir les limites du système existant et leurs souhaits concernant le système futur.
· Synthétiser les besoins du système futur en se basant sur l'existant et les souhaits des différents intervenants. On peut utiliser pour cela une Modélisation Conceptuelle de Communication MCC qui permet de représenter les flux d'informations circulant entre les différents acteurs ou postes de travail.
· Au regard de cette ébauche du système futur, proposer divers scénarios. Chaque scénario doit mentionner les éléments suivants :
o Matériels nécesSAIres.
o Logiciels nécessaires .
Grands ensembles d'informations et principaux traitements retenus pour l'automatisation (MCT et éventuellement ébauche du MCD).
Le passage à l'étape suivante nécessite que l'un des scénarios proposés par l'étude préalable soit retenu. Ce choix est établi sur les critères suivants :
COUTS

Investissement Initial, Formations, Maintenance évolutive et Maintenance corrective.

LIMITES

Estimation des gains.
Capacités d'évolutions.

IMPACTS

Impact sur l'organisation existante.

DELAIS

De mise en œuvre du scénario et de mise en exploitation.

FAISABILITÉ

Points en suspens à lever durant l'analyse détaillée ou l'analyse technique. Risques et solutions de remplacement.
3. L'analyse détaillée

• Etablissement du MCD.

• Etablissement du MOT.

• Description des traitements :
  • Enchaînement des traitements.
  • Description des procédures fonctionnelles :
    • Tables de déciSIon.
    • Définition des écrans.
    • Définition des états.
    • Liens avec le MCD.
• Formalisation du dictionnaire des données et validation du MCD vis-à-vis des traitements :
  • Liste des entités types.
  • Liste des relations types.
  • Liste des propriétés.

· Etablissement du MLD.
4. L'analyse technique

L'analyse technique a pour but de préparer la réalisation. Elle doit lever les dernières contraintes et établir les choix qui orienteront la réalisation.
L'analyse technique doit indiquer comment les traitements et données décrits par l'analyse détaillée seront réalisés.

• Etablissement du MPD.

· Etablissement du MOPT.
5. La réalisation

• La programmation.

• Les tests.

· La mise en exploitation.
6. La maintenance

La maintenance est de deux types.

• La maintenance corrective qui a pour but la correction d'une anomalie :
  • Erreur de conception : elle est due à une incohérence dans l'analyse et nécessite de revoir cette dernière.
  • Erreur de réalisation : elle est due à une mauvaise compréhension ou un oubli lors de la réalisation.

· La maintenance évolutive : modifications impliquées par une évolution de l'organisation.
II. Système d'Information S.I.

Le système d'information ( SI ) est le domaine dans lequel MERISE s'applique. Le SI est composé des moyens (humains et techniques) nécessaires au stockage et au traitement de l'information d'une organisation. Le système physique correspond aux moyens de production (humains et techniques) de l'organisation.

Le schéma ci-dessus est utile pour présenter les types d'informations transitant au sein de l'organisation.
La première étape de la démarche est de savoir dans quelles mesures certaines parties du système d'information ( SI ) peuvent être automatisable, c'est à dire découvrir dans quelles mesures l'informatique peut apporter un gain de productivité, de fiabilité ou de qualité au SI. L'ensemble de ces parties est appelé le Système Automatisé d'Information.
III. Système Automatisé d'Information S.A.I.

Le SAI est un sous-ensemble du système d'information ( SI ) dont les événements ou informations en entrée permettent de déterminer par programmes les événements ou informations conséquents.

L'intérêt de ce schéma est de présenter les grands ensembles de traitements et d'informations qui seront manipulées par le S.A.I.
Le S.A.I. peut être décomposé en sous systèmes. Ces derniers pouvant être peu dépendants :

ou fortement dépendants car ils peuvent partager le même système de conservation des informations :

IV. Abstraction

Il s'agit avant tout avec MERISE de formaliser des notions complexes qui sont difficilement utilisables sous leur forme finale (Programmes informatiques, fichiers de données...). Pour cela on utilise diverses étapes progressives durant lesquelles on ne s'intéresse qu'à certains aspects de cette formalisation :

Formalisation Conceptuelle :

A pour but la formalisation des données et traitements nécessaires au SI sans aborder les aspects d'organisation. Il s'agit d'apporter la réponse à la question : QUOI ?

Formalisation Organisationnelle:

A pour but d'apporter à la formalisation conceptuelle les notions de temps, de lieux et d'acteurs, soit répondre aux questions : QUAND ? OU ? et QUI ?

Formalisation Opérationnelle:

A pour but de définir les solutions techniques répondant aux besoins soulevés lors des étapes précédentes. Il s'agit de répondre à la question : COMMENT ?
1. Formalisation conceptuelle

La formalisation conceptuelle est l'étape la plus importante d'un projet informatique. Elle a pour but de fixer les choix des informations et traitements à manipuler dans le SI (à défaut de décrire complètement ce dernier). Pour ne s'attacher qu'à cette étape primordiale l'organisation dans laquelle ces informations et traitements seront utilisés n'est pas étudiée ici.
On utilise deux méthodes de formalisation :
Ø Modèle conceptuel des données ( MCD )

Ø Modèle conceptuel des traitements ( MCT )

a. Modèle conceptuel des données ( MCD )

Le MCD est l'élément le plus connu de MERISE et certainement le plus utile. Il permet d'établir une représentation claire des données du SI et définit les dépendances fonctionnelles de ces données entre elles.
Les éléments utilisés pour la formalisation d'un MCD sont les suivants :
Entité Type
Définition d'entités (objets physiques ou abstraits) ayant des caractéristiques comparables.

Relation Type

Définition d'une Association liant plusieurs Entités Types. Signification d'un lien entre deux ou plusieurs types d'objets.

Propriété Type

Définition d'une caractéristique d'un objet ou d'une association. Une propriété Type est elle-même caractérisé par un type (Chiffre ou Texte ...) et une longueur. L'ensemble des propriétés types du MCD compose le dictionnaire des données.

Identifiant

Propriété Type ou concaténation de Propriétés Types permettant de distinguer une entité parmi toute les autres dans une Entité Type.

Cardinalité minimum

Nombre minimum de fois où une entité est concernée par l'association.
0 indique que les entités ne sont pas obligatoirement concernés par l'association.

Cardinalité maximum

Nombre maximum de fois où une entité est concernée par l'association.
N signifie plusieurs fois sans préciser de nombre.
Ce nombre ne peut être égal à 0.

ë Représentation

ë Exemple
Comme rien ne vaut un bon exemple, voyons celui d'un club de Parapente (n'oublions pas que nous sommes sur l'île de la REUNION) qui souhaite gérer les parapentes qu'il loue à la journée aux membres du club d'une part et d'autre part, suivre le palmarès (vols) de ces mêmes membres (On considère que le SI du club de parapente se restreint à ces deux seuls éléments) :

Le MCD permet d'exprimer graphiquement des règles de gestion qui correspondent aux contraintes d'intégrités des données. Dans l'exemple, ces contraintes d'intégrités sont les suivantes :
· Chaque PARAPENTE du club est obligatoirement d'un et d'un seul MODELE DE PARAPENTE. La représentation entre parenthèses des cardinalités 1,1 est une extension de la représentation usuelle et s'appelle lien identifiant C'est-à-dire ici que le modèle de parapente est un élément permettant d'identifier le parapente.
· Les PILOTES du club ne sont pas obligés de prendre pour une journée un parapente du club mais Sinon ils peuvent louer plusieurs fois un parapente du club : 0,N. Un parapente du club n'est pas forcément proposé à la ******** mais Sinon il peut être loué plusieurs fois : 0,N.
· Un vol (caractérisé ici par l'association VOL) nécessite un PILOTE, un SITE DE DECOLLAGE, un SITE D'ATTERRISSAGE et un MODELE DE PARAPENTE. SI l'une de ces quatre entités est inconnue, le vol ne peut être enregistré.
· Un PILOTE du club doit obligatoirement avoir au moins un vol : 1,N. La cardinalité minimum 1 Signifie que la raison pour laquelle un pilote est enregistré ici est avant tout de connaître ces vols (Un pilote qui n'a jamais volé n'est pas un pilote).
· Un SITE DE DECOLLAGE, un SITE D'ATTERRISSAGE, ou un MODELE DE PARAPENTE n'est pas forcément concerné par un vol d'un des membres du club mais SInon peut l'être plusieurs fois : O,N. Ce point est important, car il Signifie que le but premier de ces trois entités n'est pas de connaître les caractéristiques des vols des pilotes du club. Il peut y avoir des modèles de parapentes qui ne sont jamais utilisés par des membres du club ou des sites sur lesquels aucun membre ne vole jamais mais que l'on souhaite enregistrer dans le SI pour pouvoir les consulter.
ë Règles de gestion
Hormis les règles de gestion définies au sein des contraintes d'intégrités représentées par le Schéma, on distingue :
Contraintes statiques

Forme ou Ensemble des valeurs d'une propriété.
Exemple : Le poids d'un pilote doit être compris dans la fourchette poids minimum, poids maximum autorisé par le MODELE DE PARAPENTE du PARAPENTE qu'il loue au club.

Contraintes dynamiques

Indiquent les restrictions lors de l'évolution du SI.
Exemple : Le niveau d'un pilote ne peut baisser.






ë Règles à suivre pour l'établissement d'un MCD
Normalisation

1ere forme Normale

Chaque entité doit disposer d'un identifiant qui la caractérise de manière unique.
Le numéro de licence est unique pour chaque PILOTE

2eme forme Normale

Les propriétés d'une entité ne doivent dépendre que de l'identifiant de l'entité et non d'une partie de cet identifiant. Un identifiant peut être composé de la concaténation de plusieurs propriétés.

3eme forme Normale

Les propriétés d'une entité doivent dépendre de l'identifiant de l'entité de manière directe.
Exemple : SI l'on rajoutait dans l'entité PILOTE une propriété " Description du Niveau " cette normalisation ne serait pas respectée car la Description du Niveau est directement dépendante du Niveau et non du " numéro de licence ".

Forme Normale de BOYCE-CODD

Pour les identifiants composés de plusieurs propriétés, ces dernières ne doivent pas être dépendantes d'une autre propriété de l'entité.

Normalisation des relations

Les propriétés des relations doivent dépendre de tous les identifiants des entités associées.

Décomposition des relations

Les relations dont le nombre d'entités associé est trop important (supérieur à 3) doivent être décomposées en plusieurs relations.
Cette décomposition ne peut se faire qu'à la condition d'avoir une cardinalité minimum égale à 1.

b. Modèle conceptuel des traitements ( MCT )

Moins utilisé et plus difficile à mettre en œuvre que le MCD, le MCT permet de formaliser les traitements en fonction des événements extérieurs sans s'intéresser à l'organisation qui régira ces traitements
Les éléments utilisés pour la formalisation d'un MCT sont les suivants :
Evénement
Interne ou Externe au SI il s'agit d'un déclencheur pour le lancement d'une opération ou le résultat d'une opération à destination du monde extérieur.
Synchronisation
Règle indiquant les événements et l'enchaînement de ces derniers nécessaires au lancement d'une opération. Il s'agit d'une expression logique composée essentiellement de OU et de ET
Opération
Liste des actions à réaliser SI la synchronisation associée est réalisée. L'ensemble des actions de l'opération s'exécute sans interruption ni attente d'événement.
Emission
Expression logique indiquant selon le résultat de l'opération quels événements internes au SI sont créés.

ë Représentation

ë Exemple
Reprenons l'exemple du club de parapente et attachons nous à définir les traitements qui concernent la ******** du parapente :

2. Formalisation organisationnelle

a. Modèle Organisationnel des traitements ( MOT )

Le MOT est issu du MCT, dont il reprend la représentation de base, et surtout de l'organisation choisie à la fin de l'étude préalable.
La représentation du MOT utilise un tableau dont les colonnes sont les intervenants, acteurs et lieux, et où les lignes apportent la notion de temps :

Par ailleurs on étend la notion d'événement du MCT à la notion de flux d'informations et on décompose les opérations du MCT en procédures fonctionnelles.
Il est intéressant, pour la compréhension du MOT, d'indiquer le support du flux d'informations ou de l'événement mentionné :

ë Exemple
Reprenons l'exemple de l'école de parapente en nous intéressant à nouveau aux traitements décrits dans le MCT. Nous considérons donc que l'étude préalable est terminée et nous entamons l'analyse détaillée.
Des choix ont été faits concernant les investissements à faire et l'organisation à mettre en place pour le système futur.
Considérons que le scénario retenu indique que le traitement de ******** d'une voile concerne deux intervenants de l'organisation :

• Le secrétariat du club qui est équipé d'un terminal informatique.
• Le matériel pour lequel aucun équipement informatique n'est prévu.

Notons ici que si le matériel était équipé d'un terminal informatique le MOT suivant serait très différent :

L'étape suivante consiste à détailler les procédures fonctionnelles.
b. Procédures fonctionnelles

Eléments à définir pour chaque procédure fonctionnelle :

• Description de la procédure fonctionnelle :
  • Type (saisie, Consultation, Manuelle, Batch ....).
  • Description.
  • Liste des Flux Entrants.
  • Liste des Flux Sortants.

o Table de décision du déclenchement de la procédure fonctionnelle.

• Description des écrans s'il y a lieu :
  • Présentation de l'écran.
  • Description des éléments de l'écran.

o Règles de gestion de l'écran.

• Description des états s'il y a lieu :
  • Présentation de l'état.

o Description des éléments de l'état.

• Description des vues de la procédure fonctionnelles sur le MCD :
  • Entités et associations nécessaires à la procédure fonctionnelle :
    • Type d'accès (Création, Consultation, Modification, Suppression).
    • Critères de recherche.
    • Propriétés utilisées.

o Cette étape est importante, car elle doit permettre de vérifier et compléter le MCD. Il s'agit ici d'établir le lien entre les traitements et les données qui ont été étudiées séparément lors de la formalisation conceptuelle.
ë Exemple :
Détaillons ici la procédure fonctionnelle présentée dans l'exemple du MOT "Vérif Fiche Pilote & Recherche de la voile demandée".
Type

Saisie

Description

• Recherche des informations du pilote
• En fonction des informations du pilote, recherche des voiles répondant aux caractéristiques niveau et poids et qui seront disponibles à la date demandée par ce dernier.

Flux entrants

• Nom et Prénom du pilote. (oral)
• Date souhaitée pour la réservation. (oral)

Flux sortants

• Enregistrement de la réservation de la voile par le pilote. (base de données)
• Bordereau de réservation. (imprimé)

Déclenchement

Le déclenchement du traitement est manuel en réponse à une demande de réservation. Ce déclenchement doit suivre les règles suivantes

• Pour une réservation de voile : la date de réservation doit être supérieure à la date du jour.
• Pour une demande de voile suite à un refus d'une autre voile déjà réservée la date peut être égale à la date du jour.

Ecran de recherche

Vue de l'écran sur le MCD

• Entité Pilote en consultation :
  • Nom du pilote : Premier critère de recherche.
  • Prénom du pilote : Deuxième critère de recherche.
  • Numéro de licence : Identification du pilote à transmettre à l'écran de réservation pour le pilote sélectionné dans la liste.
  • Date de naissance : A afficher dans la liste pour la sélection du pilote.

Ecran de réservation

Paramètre d'entrée : Numéro de licence d'un pilote.
Vue de l'écran sur le MCD

• Entité Pilote en consultation pour la recherche et la réservation :
  • Numéro de licence : Critère de recherche associé au paramètre d'entrée.
  • Nom du pilote : A afficher dans le champ " Pilote ".
  • Prénom du pilote : A afficher dans le champ " Pilote ".
  • Poids du pilote : A afficher dans le champ " Poids ".
  • Niveau du pilote : A afficher dans le champ " Niveau ".

• Entité Modèle de parapente en consultation pour la recherche :
  • Niveau : Critère de recherche supérieur ou égal au champ " Niveau ".
  • Poids minimum : Critère de recherche inférieur ou égal au champ " Poids ".
  • Poids maximum : Critère de recherche supérieur ou égal au champ " Poids "
  • Nom (Modèle de parapente) : Identifiant nécessaire à l'association Est de type. A afficher dans la liste de l'écran.

• Association Est de type en consultation pour la recherche :
  • pour rechercher les Parapentes qui ont pour modèle un Modèle de parapente répondant aux critères du pilote (voir ci-dessus).

• Entité Parapente en consultation pour la recherche et la réservation :
  • Numéro : Identifiant nécessaire aux associations Est de type et Utilise. A afficher dans la liste de l'écran.

• Association UTILISE en consultation pour la recherche:
  • Date d'utilisation : Recherche des parapentes qui sont libres à la date saisie dans le champ " Date de réservation ".

• Association UTILISE en création pour la réservation :
  • Date d'utilisation : renseignée avec le champ " Date de réservation ".

Bordereau de réservation

Cet état est lié à l'écran de réservation.

Champs renseignés automatiquement :

• Date de la demande : Date du jour.
• Date de réservation : Date saisie dans le champ " Date de réservation ".
• Pilote : Informations affichées dans le champ " Pilote ".
• Numéro de licence : Paramètre d'entrée de l'écran de réservation.
• Poids (du pilote): Information affichée dans le champ " Poids ".
• Niveau : Information affichée dans le champ " Niveau ".
• Parapente : Propriété " Modèle de parapente " du Modèle de parapente lié au Parapente choisi dans la liste de l'écran de réservation.
• Numéro : Propriété " Numéro " du Parapente choisi dans la liste de l'écran de réservation.
• Poids (minimum) : Propriété " Poids minimum " du Modèle de parapente lié au Parapente choisi dans la liste de l'écran de réservation.
• Poids (maximum) : Propriété " Poids maximum " du Modèle de parapente lié au Parapente choisi dans la liste de l'écran de réservation.
• Niveau minimum : Propriété " Niveau minimum " du Modèle de parapente lié au Parapente choisi dans la liste de l'écran de réservation.

c. Modèle Logique des données ( MLD )

Le MLD ajoute au MCD la notion d'organisation. Le MLD indique donc comment les données seront organisées.
Cette formalisation nécessite de connaître les moyens disponibles pour la manipulation des données :

• Base de données navigationnelles.
• Base de données relationnelles.
• Fichiers indexés.

· ....
Nous ne traiterons ici que de la formalisation du MLD appliquée à une base de données relationnelle.

• Les entités types du MCD sont converties en tables dans le MLD.

· Selon les cardinalités, les associations types du MLD sont converties en tables ou supprimées (voir ci-dessous).
ë Schéma de conversion du MCD en MLD.

Les propriétés en gras indiquent :

• L'identifiant d'une entité (MCD).

· La clé primaire d'une table (MLD).
Les propriétés soulignées indiquent :

• L'identifiant d'une entité (MCD).

· Une rubrique d'une table qui ne peut être nulle (MLD).
Relation dont les cardinalités maximales sont supérieure à 1.

· L'association type B est devenu une table esclave des tables issues des entités types A et C.
Relation 0,1 - 0,N ou 0,1 --- 1,N

· L'association type B est supprimée et ses propriétés types deviennent des rubriques de la table issue de l'entité type C (celle qui a les cardinalités 0,1).
· La table C est esclave de la table A. Mais cet esclavage n'est pas absolu car la rubrique " Identifiant 1 " peut être nulle. Selon l'association type B, la table C n'est pas obligatoirement liée à la table A : (0 , 1 ).
Relation 1,1 - 0,N ou 1,1 --- 1,N

· L'association type B est supprimée et ses propriétés types deviennent des rubriques de la table issue de l'entité type C (celle qui a les cardinalité 0,1).
· La table C est esclave de la table A. Cet esclavage est absolu car la rubrique " Identifiant 1 " ne peut être nulle. Selon l'association type B, la table C est obligatoirement liée à la table A : (1 , 1 ).
ë Exemple

MLD de l'exemple présenté dans le MCD

3. Formalisation opérationnelle

La formalisation opérationnelle consiste à spécifier comment seront réalisés les éléments du projet. C'est une formalisation propre aux informaticiens et qui ne concerne qu'eux.

• Pour les traitements, on s'intéresse à la structure interne des applications qui sont à réaliser.

· Pour les données, on part du MLD pour préciser l'organisation interne de la gestion des données.
On utilise deux méthodes de formalisation :
ë Modèle Physique des données ( MPD )
ë Modèle OPérationnel des traitements ( MOPT)
a. Modèle Opérationnel des traitements ( MOPT )

Le MOPT s'intéresse à la structure interne de toutes les applications du projet. Son objectif est la préparation du développement :

• Définir les normes de développement, si celles-ci n'appartiennent pas déjà au schéma directeur.
• Décomposer chaque application en modules techniques :
  • Définir les données internes au module technique.
  • Définir les traitements du module technique (Procédures, fonctions) :
    • Présentation du traitement technique.
    • Appel du traitement technique.
    • Informations en entrée.
    • Informations en sortie.
    • Résultat.
    • Données internes au traitement technique.
    • Description du traitement technique (pseudo-code, algorithme ...).

· Définir le cahier des tests.
Le MOPT est fortement dépendant des outils de développement choisis lors de l'étude préalable. Notons ici l'impact des Ateliers de Génie Logiciel (AGL) dont le but initial est d'optimiser la gestion du code de programmation pour la réalisation et surtout la maintenance.
Deux démarches existent concernant les spécifications internes d'une application :

Analyse descendante

Il s'agit de la démarche la plus communément utilisée et la plus naturelle, car elle consiste à décomposer le résultat que l'on souhaite obtenir en éléments de plus en plus petits.

Analyse ascendante

Il s'agit d'une démarche plus ambitieuse, nécessitant un investissement initial important. Apparus avec les langages objets, cette démarche a pour but de définir les éléments de base en premier puis de constituer les éléments qui utiliseront ces éléments de base et cela jusqu'au résultat souhaité.
La question que l'on se pose en début de démarche est alors :
" De quoi vais-je avoir besoin pour faire mon application ?"
Il s'agit donc de prévoir tous les outils qui seront nécessaires à la réalisation de l'application puis de constituer cette dernière avec ces outils. Le but avoué de cette démarche est de réaliser des éléments qui soient indépendants de l'application, ceci de manière à pouvoir être réutilisés pour d'autres applications.
On parle alors d'analyses orientées objet.
Cette démarche ne nécessite pas l'utilisation d'un langage objet bien que cela soit préférable. D'autre part, le fait de programmer avec un langage objet n'assure pas d'avoir une démarche ascendante.

b. Modèle Physique des données ( MPD )

Le MPD prépare le système de gestion des données.
Nous ne traiterons ici que de la formalisation du MPD appliquée à une base de données relationnelle.
Le MPD s'intéresse à l'optimisation de la gestion des données en fonction de l'outil choisi pour cette gestion et surtout en fonction des traitements qui utilisent ces données (Vue des procédures fonctionnelles). Des choix parfois contradictoires vis à vis du MCD sont à faire car il s'agit d'être pragmatique.

• Définir la place nécessaire à chaque table.
• Définir l'implantation physique de la base de données sur les disques, les serveurs disponibles ...
• Optimiser les temps d'accès à l'information :
  • Accepter les redondances d'informations qui permettent de diminuer sensiblement le nombre de tables concernés par une requête.
  • Utilisation de clés numériques.
  • Création d'index pour les critères de recherche.