Dans quel cas et comment utiliser à la fois UML et MERISE pour une BD

Bonjour à tous,

1)J'aimerais savoir dans quel cas utiliser à la fois UML et MERISE pour concevoir une base de données BD?
2) Si cela est possible comment les utiliser lors de la conception d'une même BD?

Merci.

nkm a écrit :
Bonjour à tous,

1)J'aimerais savoir dans quel cas utiliser à la fois UML et MERISE pour concevoir une base de données BD?
2) Si cela est possible comment les utiliser lors de la conception d'une même BD?

Merci.

Et l'eau,

Tu es dans la bonne direction . Avec l'UML 2.0, tu peux tout modéliser. Avec Merise, tu te cantonnes aux base de données. Le mieux est de connaître les 2. Merise est long à se fader mais c'est simple au final (c'est de la logique) et je te conseille de commencer par là. Pour l'UML, c''est simple aussi et il va te servir par la suite. Cependant, si tu ne connais pas bien le principe d'une base de données relationnelle (la clef et rien que la clef), tu vas vite faire des bêtises et Edgar F. Codd te fera les gros yeux !
Modifié par niuxe (09 May 2018 - 16:41)

Utilise UML si tu veux représenter les entités objets d'un point de vue "métier". Et MERISE, si tu souhaites représenter une base de données relationnelle d'un point de vue "tables".

Rien ne t'oblige à enregistrer une liste de clients et de contrats dans une base de données SQL. Si tu souhaites expliquer à quelqu'un que ton application gère une liste de clients, de contrats et leurs relations, tu vas plutôt le représenter en UML d'abord.
Si tu décides de stocker ces listes dans un ou plusieurs fichier(s) XML, JSON, CSV, ou dans tout autre système de stockage non SQL, alors MERISE ne te sert à rien.

Par contre, si tu as décidé d'utiliser une base de données SQL alors tu peux être amener à la représenter en MERISE pour décrire les différentes tables de ta base. Ça a du sens, si tu souhaites, par exemple, déboguer un problème de clés étrangères (propres aux bases de données relationnelles).

Nota bene : les systèmes d'ORM (Object Relational Mapping) tels que Doctrine en PHP et Hibernate en Java génèrent leur propre modèle SQL en fonction des entités métier. De ce fait, lorsqu'on utilise un ORM, à moins de partir d'une base de données déjà existante, faire soi-même un MERISE est une pure perte de temps car c'est l'ORM qui décide des tables à créer, de leurs noms, des types utilisés, etc.
Modifié par Charlycoste (10 May 2018 - 12:44)

Charlycoste a écrit :
faire soi-même un MERISE est une pure perte de temps car c'est l'ORM qui décide des tables à créer, de leurs noms, des types utilisés, etc.

Et c'est comme ça qu'on retrouve des projets casseroles.... Le truc est facilement maintenable puisque le dev a fait QUE de la merde.... Tu te retrouves à faire des charrettes pour une petite évolution parce que tu dois reprendre ou patcher (encore pire) les merdes de l'autre.

Ce que tu dis n'est pas de l'ordre de l'ORM mais de Migration. Et cet outil (Migration), on le paramètre....
Flask
Django
CakePHP
Laravel
Symfony
etc.

Merise est accès aux base de données alors que l'UML est plutôt générique/généraliste. D'ailleurs, la représentation objet que fait un ORM n'est qu'une "déviance".

De toute manière, Merise et UML sont à apprendre afin de faire du bon taf.
Merise pour les base de données
UML pour la POO et par extension une représentation de la base de données.
Modifié par niuxe (10 May 2018 - 14:36)