Bonjour,
 
J'entends souvent qu'il est très important d'optimiser le MCD avant de commencer quoi que ce soit.
 
Mais je ne comprends pas ce que cela sous entends. A part casser le plus possible les relation n-aire, je ne vois pas d'autres choses. Pourant, il doit bien exister d'autres optimisations!!!
 
Quelles sont selon vous les normes minimales qu'un MCD correctement optimisé doit respecter?
 
Merci à tous et bonne journée

a mon avis comme tu as deja dit
 
évité les relations n-aires
 
ensuite je dirais qu'évité bien entendu la redondance, sauf dans certain cas ou ça ne peux qu'accéléré la recherche par exemple (tout dépend de l'application que tu vas faire)...
 
sinon euh je ne sais pas trop...

T'es malade ?  

L'optimisation d'un MCD, c'est la phase aussi courrament appelée "dénormalisation".
 
Il s'agit, à partir d'un MCD 100% MERISE, d'arriver à un MCD sortant légèrement de la norme, afin de :
- Eviter tout ce qui est 0,1-1,1 (à banir totalement)
- Eviter tout ce qui est a,b-c,n (avec a, b et c connus), par exemple, une relation 2,2-4,n est à supprimer, en ajoutant des champs dans une des deux tables, et en supprimant l'autre. Ne pas le faire dans tous les cas cependant !
- Tenter de réutiliser une seule entité, lorsque plusieurs ont la même structure, mais contiennent des informations différentes. Par exemple, une facture et une commande ont rigoureusement la même structure, il vaut mieu utiliser une unique table plutôt que deux, en ajoutant un champs afin de différencier les informations contenues dans la table).
 
Etc.
 
Il n'y a pas de règle absolue, c'est 100% dépendant de l'utilisation de la base. Dans un premier temps, à partir de la liste de traîtements et écrans connus, tente d'écrire les requêtes permettant de faire tout ça. Ensuite, à partir de là, regarde les jointures superflues ou coûteuses (associer une facture à une commande, lorsque chacune des deux tables possède 10 000 000 de lignes, c'est très consommateur, index ou non).
Faire une table de jointure entre "personne" et "personne" afin de différencier qui est le père et qui est la mère d'un fils est inutile, il vaut mieu ajouter deux champs "père" et "mère" dans la table personne. Ceci dit, ta base sera incapable de gérer des couples homosexuels ayant adopté un enfant, bref, tout ce qui est dénormalisation doit être à prendre avec des pincettes.

Peut-tu en dire un peu plus sur les relations 0,1-1,1 à éviter ?

Les relations du style :
 
PERSONNE
ID
Nom
Prenom
 
PERMIS_DE_CONDUIRE
ID_Personne
Num_Permis
Date_Emission
Nombre_de_Points
 
Bon, ben tous les gens n'ont pas un permi de condutuire, mais au plus un seul permi. Deplus, un permi de conduire n'est attribué qu'à une et une seule personne.
Donc entre l'entité "Personne" et "Permi de conduire", il y a une relation Personne (0,1) - (1,1) Permi
 
C'est très joli tout ça. Seulement, si on laisse comme ça, imagine un état :
afficher le nombre de personne qui ont le permi de conduire (groupées par année d'attribution du permi) et une ligne pour le nombre de personnes qui n'ont pas le permi.
 
Ben bon courrage
 
Par contre, tu pètes tout ce joyeux bordel pour dénormaliser le MCD (ouais, c'est porc, mais c'est pour la bonne cause)
 
PERSONNE
ID
Nom
Prenom
Num_Permi (null)
Date_Emission_Permi (null)
Nombre_Points_Permi (null)
 
C'est pas bô. Va y avoir plein de null dans la table quand une personne n'a pas de permi.
Par contre, les requêtes comme cette que j'ai cité ci-dessus, tu les fais en une seule passe, même avec Access 2.0 ou MySQL 3.0, avec des performances infiniement meilleures.
 
C'est ça la dénormalisation/optimisation du MCD : le rendre pas beau, afin d'améliorer la mise en place du MPD.
 
Attention, parfois, ce type de modifications peut limiter l'évolutivité du MPD, à savoir que si demain tu veux gérer les personnes qui ont un permi moto, un permi poids-lourd et un permi voiture, t'es dans la merde, car la dénormalisation rend impossible la gestion de tout ça !
 
Chaque dénormalisation est donc à étudier de très près.

Ok je vois Merci pour ce brillant exposé
 
Et si on garde les deux tables PERSONNE et PERMIS, mais qu'on mette un champ num_permis dans la table PERSONNE ?

Ca marche aussi en effet (même si pour l'exemple de la requête, ça oblige tout de même à faire un union ) Seulement, tu auras aussi le problème des types de permis (A, B, etc.) à moins que tu crée une ligne "num_permis" par type de permi possible, mais là ça commence à devenir crade
 
A informations identiques, chaque besoin a sa solution différente en somme

Ok c'est cool