Quelques remarques :
1) Merise est effectivement une méthode ancienne. Cela ne veut pas dire qu'elle soit dépassée, vielliotte, ... Après tout, l'alphabet que nous utilisons est encore plus vieillot puisqu'il a plus de 2000 ans
2) Dans un cadre scolaire, c'est vrai que l'on applique toute la méthode Merise et que c'est très lourd.
Dans un cadre industriel, on peut largement se passer de toute la modélisation des traitements : il existe des méthodes "vieillottes et simples" de modélisation (SADT par exemple) ou des méthodes plus récentes, mais un peu plus difficile à mettre en oeuvre (UML pour ne pas le citer). On pourra se contenter au minimum du Modèle Physique des Données de Merise (MPD) précédé éventuellement du Modèle Conceptuel des Données (MCD). Personnellement, je trouve que le MCD est une perte de temps, mais il peut être utile face à des non-informaticiens.
3) Créer les tables sans schéma théorique : oui, cela peut se faire, mais dans des cas très particuliers.
- un développement de type maquette "jetable"
- un développement que tu fais tout seul dans ton coin
- un développement qui n'évoluera jamais
Dans tous les autres cas, même si le projet est simple, il est obligatoire de passer par l'étape de modélisation :
- parce qu'il est indispensable de réfléchir avant d'agir. Même si les démarches RAD alternent réflexion et codage, rien ne vaut un bon schéma pour mettre à plat tous les problèmes avant d'avoir commencé le codage (ou du moins pour dégrossir le problème).
- parce qu'un modèle est la représentation virtuelle d'objets du monde réel : la représentation virtuelle, c'est la vision de l'informaticien ; les objets réels, c'est la vision du client : comptable, commercial, fabriquant, ... Un modèle (et en particulier un modèle graphique) est le point de rendez-vous, de formalisation et de compréhension entre ce que TU as modélisé (ce que tu as compris du problème) et ce que le client connaît au quotidien (ou du moins ce qu'il pense connaître).
Exemple vécu : j'ai été appelé au secours sur un projet très simple qui foirait parce qu'il n'y a jamais eu d'explication claire entre l'informaticien et le client-comptable sur ce que recouvrait le mot "facture". Moralité : une facture = un seul type d'objet = une seule ligne de facture. Et comme il n'y avait plus le temps pour tout refaire, il a fallu monter un objet factice virtuel "super facture" pour permettre d'établir UNE facture réelle (papier) lors de l'achat d'un marteau ET d'un tournevis !
- parce que si ton modèle évolue, le temps T que tu penses avoir perdu à modéliser sera largement gagné par la suite, notamment en cas d'évolution. En effet, statistiquement, il y a 95% de chances que le modèle devienne plus complexe (on rajoute des fonctionnailités qui n'avaient pas été imaginées au départ, mais que l'utilisation de la V1 fait surgir) et si tu n'as pas une vue d'ensemble, tu cours à la catastrophe. 3 mois ou 6 mois après, on a généralement eu largement le temps d'oublier comment ça avait été fait.
Donc, si tu veux commencer :
- fais un recensement de tous les objets que tu dois modéliser (étudiants, carnet de notes, cours, professeurs, ...)
- fais un recensement des propriétés de chaque objet (nom, prénom, valeur, ...
- commence à les relier les objets entre eux (étudiants aux cours, cours aux professeurs, cours aux options, ...)
- fais lire et explique ton modèle à quelqu'un qui pourra critiquer et t'indiquer les points obscurs ou faux
