Discussion :

[JOJO_DE_LYON]

Hello tous,

J'organise un petit débat sur la création des MCDs, suivi d'une génération de MPD.
Personnellement, je développe des applis web avec bases de données Oracle depuis plus de 6 ans, et je mets en place directement des MPDs, sans passer par la case MCD.

L'étape "Création des MCD" est pour moi une perte de temps. Mais j'aurais voulu avoir votre avis sur ce sujet.

Au plaisir de vous lire....

[fsmrel]

Bonjour Jojo,

Avant de répondre de façon plus précise, j’aimerais savoir ce que vous entendez par « mettre en place directement des MPD ».
En effet, on pourrait interpréter cela comme passer directement au codage des instructions Create Table.

Cela dit, vous postez sur le sous-forum dédié à PowerAMC : autrement dit, utilisez-vous l’outil (ou tout autre) pour d’abord construire un schéma décrivant les tables et leurs relations ? (en demandant ensuite à l’outil de produire le jeu des Create Table).

[JOJO_DE_LYON]

Effectivement, je confirme. Je travaille de cette façon.
Création d'un MPD avec description de chaque table et de leurs relations. Puis génération d'un script SQL basé sur ce schéma.

Personnellement, ce n'est pas que je trouve le MCD inutile. Quand on débute en modélisation, ça permet de bien poser les choses. Mais quand on commence à avoir un peu de "bouteille", je trouve qu'on peut passer directement à l'étape suivante. Qu'en pensez-vous?

[fsmrel]

Bonsoir Jojo,


Ma position est que le MCD et le MLD sont tous deux essentiels (en passant, le MPD a plus à voir avec la quincaillerie qu’avec les tables qui sont, je le rappelle, des ensembles à manipuler avec les opérateurs de l’algèbre relationnelle).

Cas du MCD :

Le MCD fait l’objet d’un schéma Merise, ou Entité/Relation (voire d’un diagramme de classes) indispensable dans le cadre des échanges que nous avons avec les utilisateurs ou les informaticiens qui ne sont pas des spécialistes des bases de données.
Du fait de son côté formel, le MCD est dépourvu de ces ambiguïtés qui émaillent nos phrases maladroites dans les dossiers et engendrent des quiproquos. Le MCD s’avère donc essentiel dans la communication avec les utilisateurs non-informaticiens ou avec les équipes qui analysent et développent, que ce soit pour la bonne compréhension du sujet ou pour éviter de perdre inutilement du temps. Par exemple, je me souviens de la réaction d’E.K., directeur de projets dans une grande entreprise française (environ 170000 personnes), pour qui j’avais concocté un MCD décrivant la partie du Système d’Information qui le concernait, car il n’en avait pas en sa possession. Le schéma— condensé en une page— était intentionnellement sémantisé, mais sans excès (héritage, agrégation, composition, contraintes d’inclusion/exclusion, etc.) Au bout de vingt minutes d’explications de ma part, E.K. s’était exclamé : «Mais alors, si on bougeait le lien existant entre les entités truc et machin, on se ferait des c... en or !» Le seul problème était que le projet concerné était en production depuis deux ans et que cela eut été très délicat de toucher à quoi que ce soit, car tout était emmêlé. Si E.K. avait eu un MCD dès le départ, c’eut été tout bon. Ce MCD lui aurait permis de prendre du recul et de juger de la pertinence de ce que son équipe devait réaliser.

Cas du MLD :

Quand mon interlocuteur est un DBA, je lui présente plutôt un MLD (avant que nous construisons ensemble le MPD : index et autres espaces physiques).
En effet, les termes PK et FK lui parlent de façon très précise et les tables du MLD sont celles qui figureront dans les scripts contenant les instructions Create Table. En revanche, si je lui présente un MCD (ou un diagramme de classes), il est probable que certains objets (je pense par exemple à l’entité-type Date) ne feront pas l’objet de tables, même chose pour les associations, je cherche donc à éviter qu’il perde du temps avec ça.

En première approche :

En conclusion, selon les interlocuteurs que l’on a en face de soi, on utilise un MCD ou un MLD pour travailler et échanger (je fais abstraction des traitements, c’est-à-dire des MCT et consorts, qui auront plus une incidence sur le choix des index et autres éléments permettant de booster les programmes). A mon sens, on doit disposer des deux modèles, d’autant plus quand on dispose d’outils tels que Win’Design, PowerAMC, et j’en passe, pour dériver (ou rétro-concevoir) l’un en l’autre, à quelques aménagements manuels près. Pourquoi se priver ?

Il y a le cas de ceux qui n’ont pas d’outils tels que ceux auxquels je viens de faire allusion. Il m’arrive de participer ici à certaines discussions dont les initiateurs posent des questions de niveau MCD, mais n’ont pas d’outil. Comme l’on traite malgré tout de bases de données, je n’hésite pas à utiliser un outil gratuit comme Toad Data Modeler, qui est du niveau MLD, mais avec lequel on arrive à représenter des schémas corrects.

Maintenant, j’estime que l’on passe plus de temps à produire directement un MLD qu’en passant d’abord par l’étape MCD.


Du choix du mode de représentation

Je voudrais illustrer mes propos. Dans ce qui suit, j’utilise PowerAMC. Je présente un MCD (Merise) et le MLD qui en a été dérivé.

Figure 1 - MCD (Notation Merise)

On voit clairement que l’entité-type Matiere_Produit est une généralisation des entités-types Matiere et Produit Fini.
Matiere_Premiere devrait être une spécialisation de Matiere, mais on a plutôt considéré la première comme excroissance de la seconde (une fantaisie...)
On peut noter l’emploi de l’identification relative (cardinalités (1,1) proposées par l’outil) pour signifier l’agrégation ou la composition.
Il ne faut pas longtemps à un non-initié comme E.K. pour comprendre un tel MCD. En revanche, mon DBA préférera peut-être le MLD ci-dessous, très austère, beaucoup moins parlant mais traditionnellement le suivant :

Figure 2 - MLD (notation prétendue "relationnelle")

Ce MLD peut-il remplacer le MCD dont il est issu ? Comme je viens de le dire, le DBA le préférera peut-être mais certainement pas E.K. En effet, on a perdu les cardinalités (au moins visuellement) et les notions fortes d’héritage et de composition.

Même chose, si l’on était parti du MOO suivant, dont E.K. ferait son miel : le DBA renâclerait sans doute à l’interpréter («C’est quoi, ça ?») et réclamerait le MLD austère...

Figure 3 - MOO (diagramme de classes)

Maintenant, est-il possible de produire un MLD qui ne soit pas trop austère et pouvant contenter tout le monde ? Probablement, en utilisant la notation "conceptuelle" plutôt que la notation "relationnelle" (laquelle n’a rien à voir avec le Modèle Relationnel de Données, car celui-ci ne propose aucune représentation graphique...) :

Figure 4 - MLD (notation Entité/Relation)

Mais héritage et composition ne sont toujours pas visibles à l’œil nu.

En plus du MLD, le mieux est toujours d’avoir un MCD (ou un MOO). Maintenant, si vous êtes fâché avec les ronds de Merise (symbolisant les associations), vous pouvez adopter la représentation anglo-saxonne pour votre MCD :

Figure 5 - MCD (Notation Entité/Relation)

Le symbolisme diffère singulièrement de celui de Merise, mais l’aspect sémantique est préservé : La généralisation est bien visible. Matiere_Premiere est un composant de Matiere (bien que la spécialisation eut été plus pertinente, mais le problème n’est pas là). De la même façon, Adresse est un composant d’Acheteur.

Personnellement, si je ne devais afficher au mur qu’un schéma, ça serait celui de la figure 5...


Remarques complémentaires

Il faut aussi reconnaître qu’un MCD ne peut pas prendre en compte certaines contraintes (ou alors ça devient extrêmement compliqué) : c’est le cas de l’exemple bateau des courses hippiques, dont le MLD peut être le suivant :

Figure 6 - MLD, Courses hippiques

Autant il est facile au niveau de ce MLD de définir des clés alternatives (ak1, ak2, ak3), autant cela relève de l’exploit au niveau du MCD.


Maintenant, que l’on ait un MCD ou pas, il est un point sur lequel je serai intraitable et pour lequel nos outils n’apportent pas de solution, celui de la normalisation (disons BCNF). Mais, Sahib, ceci est une autre histoire...