Discussion :

[wafiwafi]

Quand je termine un MCD, je me dirige droit vers le MLD pour décider des porteurs de clés. Au stade du MLD, je ne suis pas encore à l'implémentation et je ne dois pas encore penser au langage (pour ce dernier point C'est très très dûr).
Dans presque toutes les initiatives de modélisation, après un MCD, on va automatiquement faire le MLD, et faire la liaison instinctivement avec la notion de tables et donc, ne le nions pas, aux bases de données relationnelles avec , toujours dans notre tête, le langage sql par exemple. Cela devient une automatisation.
Franchement le rôle du MLD aurait dû, et là je vais peut être créer des débats, faire partie du MCD avec la notion de table (pourquoi pas), en tant que type abstrait et donc implémentable par tout langage.
Le schéma MCD-MLD-BASES de DONNEES- REQUETTES , spécialise la démarche de modélisation et d'implémentation.
OUI, je suis conscient de l'utilité des bases de données et de leur importance, mais je pense que pour les débutants, on devrait montrer qu'il s'agit d'une démarche mais pas la seule qui existe;oui, malheureusement c'est perçu faussement comme cela. Je peux très bien faire que du PHP ou du java... . Ce n'est pas la peine de riposter sur cette dernière phrase parce que je sais qu'on ne peut presque pas se passer des BDs.
Les BDs, pour moi, doivent constituer un choix de solution mais pas la solution..
En résumé, un MCD avec des tables en type abstrait, et là ça va choquer certains, suffirait pour passer à l'implémentation.
(Attention, toutes les personnes qui lisent cette discussion doivent se rendre compte qu'il s'agit d'un avis personnel.) et donc n'embrouille pas le lecteur et ne lui donne pas des idées fausses ou dangereuses comme utilisent certains personnes dans des discussions. Le forum est fait pour lever des ambigüités; en tout cas pour moi.
Le débat est ouvert.

[CinePhil]

J'ai du mal à comprendre ton propos alors je ne sais pas si ce que je vais écrire va alimenter ta réflexion.

Tu parles d'abord de MCD et de MLD.
Ces deux schémas font partie de la méthode Merise et sont particulièrement adaptés à la conception des bases de données relationnelles mais, sauf erreur de ma part, l'implantation physique dans un SGBD (tel que MySQL que tu cites - Au passage, je te précise que MySQL n'est pas un langage mais un SGBD qui utilise une adaptation plus ou moins fidèle à la norme du langage SQL.) n'est pas obligatoire.

Si je fais un logiciel qui gère une machine à partir d'informations obtenues via des capteurs et des positions de commutateurs, je n'ai peut-être pas besoin de stocker les informations dans une base de données. Par contre, il me semble qu'on peut aussi développer ce genre de logiciel avec la méthode Merise et les schémas qu'y rattachent, ou bien préférer utiliser le langage UML et ses schémas (use case, diagramme de classe...).

Là où je te suis assez bien, c'est sur ceci :

Dans presque toutes les initiatives de modélisation, après un MCD, on va automatiquement faire le MLD, et faire la liaison instinctivement avec la notion de tables et donc, ne le nions pas, aux bases de données relationnelles avec , toujours dans notre tête, le langage mysql par exemple. Cela devient une automatisation.

En théorie, et notamment quand on commence à faire ça à la main sur du papier avec un crayon, on peut commencer un MCD en ne représentant que les entités et les assoiactions et leurs cardinalités. C'est d'ailleurs ce que je fais ici quand j'écris des schémas du genre :
Personne -1,1----Travailler----0,n- Entreprise

En théorie toujours, on peut aussi se contenter de faire figurer dans le MCD les attributs sans préciser leur type, de même qu'on peut passer au MLD sans toujours préciser leur type.

Dans la pratique, de nos, jours, on utilise généralement un logiciel de modélisation qui va automatiser le passage du MCD au MLD puis générer le modèle physique, soit directement par connection à un SGBD, soit en écrivant les requêtes SQL de création des tables. Dès lors, si on n'a pas au préalable, dès le MCD, précisé les types de données, si on ne les a pas vérifiées au niveau MLD (si le logiciel ne le fait pas lui-même), si on n'a pas déterminé les index et vérifié les clés étrangères, on risque de se retourver avec de belles erreurs lors de l'implémentation en BDD.

A partir de là, je ne comprends plus ce que tu veux dire :

Franchement le rôle du MLD aurait dû, et là je vais peut être créer des débats, faire partie du MCD avec la notion de table (pourquoi pas), en tant que type abstrait et donc implémentable par tout langage.

MCD = entités + associations, leurs attributs et cardinalités. Eventuellement des contraintes d'exclusion ou autre.

MLD = des tables avec des noms de colonne, des clés étrangères et des flèches pour représenter les relations. Le modèle anglo-saxon le plus proche est ici le modèle Entity/relation tel qu'il existe dans MySQL Workbench.

Comme je l'ai dit plus haut, ce qui est représenté par ces schémas peut être implémenté a priori par tout langage, même si le plus approprié est le SQL pour engendrer une BDDR.

Le schéma MCD-MLD-BASES de DONNEES- REQUETTES , spécialise la démarche de modélisation et d'implémentation.
OUI, je suis conscient de l'utilité des bases de données et de leur importance, mais je pense que pour les débutants, on devrait montrer qu'il s'agit d'une démarche mais pas la seule qui existe

Qui dit le contraire ?
Les aficionados de UML apprécieront !

je sais qu'on ne peut presque pas se passer des BDs.

On utilise une BDD si on doit gérer des données persistantes. Sinon ça ne sert à rien !
Si je programme un jeu qui ne conserve que les 10 meilleurs scores, c'est un bien grand luxe d'utiliser une BDD pour ça alors qu'une simple liste dans un fichier texte est suffisant !

En résumé, un MCD avec des tables en type abstrait, et là ça va choquer certains, suffirait pour passer à l'implémentation.

J'ai toujours un peu de mal à comprendre ce que tu entends par "tables en type abstrait" mais je dirais plutôt qu'un MLD, mais complet, suffit pour passer à l'implémentation. comme il n'y a aps les clés étrangères dans un MCD, c'est insuffisant ; il va manquer des colonnes dans les tables.

[wafiwafi]

C'était une erreur d'inattention de ma part d'écrire MySQl au lieu d'écrire SQL. Je parlais des roquettes.
C'est le minimum quand même à savoir!
Je l'ai rectifiée; je poursuis donc la lecture de ton message.

[wafiwafi]

Ces deux schémas font partie de la méthode Merise et sont particulièrement adaptés à la conception des bases de données relationnelles

Justement, c'est ce qui me gène. C'est toujours une histoire de base de données. Et si on en n'a pas besoin? Tu as déjà cité des cas, cela voudrait t-il dire que je ne dois pas faire du MCD , du MLD( si tu veux) ...

Ce que je voulais dire, c'est quand on arrive à la notion de table avec les insertions des clés pour les relations. cet aspect peut être implémenté sous java par exemple (tableau, liste,arbre,...) . C'est pour cette raison que je considère la table comme un type abstrait puisqu'on n'a pas encore choisi la solution d'implémentation.

Voila ce que j'ai fais dernièrement :

J'ai réalisé un MCD pour une petite application. J'ai renseigné ce dernier sur les porteurs des clés sans me taper un autre schéma (c'est mon choix). Ensuite, j'ai écrit les classes en java avec les insertions des clés.
Et enfin, le traitement. Tout marche bien!
Mon premier message était dans ce sens.

comme je l'ai déjà dis, cette démarche reste personnelle. Mais il a fallu oser utiliser le concept MCD en dehors de merise (OUI, indirectement j'ai fais du merise).
Désolé d'avoir bousculé les habitudes. Mais renseigner un MCD me suffit pour me passer du MLD.


En ce qui concerne, les IDE, OUI cela pose problème puisqu'on n'a pas tenu compte de ce fait. Tu dois y aller à la main! ;c'est une raison de plus pour le considérer.


Au passage je disais que souvent les bases de données sont utilisées, mais je n'ai pas dis tout le temps, c'était ma pensée en tout cas. Tout le monde sait qu'il y a des applications qui ne nécessitent pas d'y faire appel
Bien à toi