Discussion :

[LhIaScZkTer]

Bonjour à tous,

Je suis entrain de modéliser une base de données permettant de recenser les fuites se trouvant sur le réseau gazier. J'ai isolé une partie de mon modèle à laquelle je n'arrive pas donner une représentation satisfaisante. Cette partie concerne le matériel, le matériau et le diamètre, un petit exemple sera plus parlant et permettra de situer le sujet.

J'ai des fuites qui se trouve sur le réseau. Lors du constat de la fuite le technicien relève le type de matériel, le diamètre du matériel et le type de matériau du matériel. Donc dans une fuite on pourrait avoir pour matériel, une vanne, pour le diamètre, 90, et enfin pour le matériau, de l'acier. Jusqu'ici tout vas pour le mieux.

Là où ça se gatte c'est que le matériel peut être composé de plusieurs matériaux et que chaque matériau a des dimensions qui lui sont propres. C'est-à-dire, par exemple, que pour le matériau acier les diamètres disponible seront de par exemple 50 à 90 et pour la fonte ductile, les diamètres disponible seront de 20 à 40.

Donc si je m'en réfère à cette énoncé j'obtiens à première vue quelque chose du genre :

[MATERIEL]----1,N----(Est_composé_du)----1,N----[MATERIAU]----1,N----(Possède)----1,1----[DIAMETRE]

Dans cette représentation ce qui me pose problème est que je ne vois pas comment est que je ne vois pas comment créer la relation avec l'entité Fuite. J'ai un MCD fantaisiste qui s'approcherait de ce que je souhaite faire. Le problème est qu'il ne respecte plus la règle, un diamètre n'est disponible que pour un type de matériau. Voici le MCD fantaisiste, ne pas faire attention à l’orthographe de fuite (phuite), ni au verbe choisi



Sinon, la représentation suivante pourrait tout à faire satisfaire la règle énoncée étant donné que diamètre est un sous-ensemble de Matériau, il y a donc une dépendance fonctionnelle entre diamètre et matériau :



Qu'en pensez-vous ?

Merci à tous pour votre aide.

[fsmrel]

Bonsoir LhIaScZkTer,


Avec votre 2e MCD vous n’êtes pas loin du but, sinon que d’une part la cardinalité 0,1 est à remplacer par 1,1 et d’autre part que du point de vue théorique, votre ternaire doit être décomposée en 2 binaires, du fait des dépendances fonctionnelles :

FUITE -> MATERIEL

FUITE -> DIAMETRE

Maintenant, vous pouvez préférer qu’une fuite fasse référence à une paire {MATERIEL, DIAMETRE} réputée légale, auquel cas vous pouvez transformer l’association-type SE COMPOSE en entité-type (que je nomme MATERIEL_DIAMETRE ci-dessous).

Notez la mise entre parenthèses de certaines cardinalités 1,1, façon qu’on a avec PowerAMC de signifier que MATERIEL_DIAMETRE est une entité-type faible (weak), qui n’a d’existence qu’au travers d’entités-types plus fortes (regular), savoir MATERIEL et DIAMETRE : on dit que l’entité-type MATERIEL_DIAMETRE est identifiée relativement à MATERIEL d’une part et DIAMETRE d’autre part.


MCD




MLD dérivé

[Richard_35]

Bonjour LhIaScZkTer et Fsmrel,

Je me permets de m'immiscer, Fsmrel...

A l'étude de l'énoncé de LhIaScZkTer, le MCD serait plutôt :



A, car

le technicien relève le type de matériel, le diamètre du matériel

B, car

C'est-à-dire, par exemple, que pour le matériau acier les diamètres disponible seront de par exemple 50 à 90 et pour la fonte ductile, les diamètres disponible seront de 20 à 40.

En résumé, si j'ai bien tout compris, le matériel a un et un seul diamètre, mais il est composé de un ou plusieurs matériaux qui, eux, ont des tranches de diamètres paramétrées.

Quelle est donc la problématique précise ?
Quel est le contrôle de cohérence à prévoir entre tous ces diamètres ?

[LhIaScZkTer]

Bonjour Messieurs et merci pour vos réponses,

Je vais commencer par te répondre Richard_35, mais déjà merci encore pour ton aide. Sans doute la logique de ma phrase a été mal énoncée.

Imaginons que pour matériel j’ai deux types matériels disponibles qui sont les siphons et les vannes.

Chacun de ces matériels peut être fait de plusieurs types de matériaux, c’est-à-dire, un siphon peut être constitué de plastique, d’acier, de fonte ductile, mais la vanne peut être constituée des mêmes matériaux. (le modèle de fsmrel répond à cette contrainte)

Chaque matériel sera disponible en plusieurs matériaux, donc on pourra avoir une vanne en plastique, acier etc.

Enfin il y aura des diamètres spécifiques pour chaque type de matériau, la fonte ductile ne sera disponible que de 20 à 40 et l’acier de 50 à 90, mais l’acier ne pourra pas être plus petit que 50 ni plus grand que 90. (le modèle de fsmrel répond aussi à cette contrainte)

Cependant, toutes les tailles disponibles pour chaque matériau seront référencées, car elles sont toutes standardisées. Donc je peux avoir pour l’acier les diamètres suivant 50, 60, 65, 80 et 90, mais pas 70, car le 70 pourrait être pour du plastique. Par exemple je peux avoir une vanne ou un siphon avec un diamètre de 60 en acier.

La problématique précise, au final, est que l’application propose un mode de saisie assez libre. De plus, l’application ressortira des statistiques qui viendront alimenter des statistiques effectuées au niveau national, qui correspondront, par exemple, au nombre de fuite ayant un diamètre inférieur à 80, classée par matériau et par type de fuite. Enfin, bien que rien n’ait été décidé on peut imaginer, lors de la saisie, une liste déroulante avec les matériels et une liste avec les diamètres classée par famille de matériau dans le style html du terme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
<select>
   <optgroup label="Acier">
      <option>50</option>
      <option>60</option>
      <option>90</option>
   </optgroup>
   <optgroup label="Fonte ductile">
      <option>20</option>
      <option>25</option>
      <option>30</option>
      <option>40</option>
   </optgroup>
</select>

fsmrel, merci beaucoup pour ta réponse, elle me plait énormément et satisfait tout à fait à la problématique posée. J’ai juste une petite question qui subsiste. Dans ce modèle, si j’ai une fuite non constatée, c’est-à-dire après la mesure négative de concentration de gaz dans l’air, le technicien ne va pas relever de données concernant le matériel. Donc, l’entité FUITE ou plutôt la table FUITE aura DiametreId et MaterielId à NULL, ce n’est pas top, qu’en penses-tu ?

Enfin, ce propos est hors sujet, mais fsmrel, je suis toujours impressionné par la qualité et la précision de tes réponses et à ce que tu apportes à la communauté. Tes réponses sont de vrais cours à elles seules et souvent elles donnent lieu à des débats passionnés et passionnants que j’ai toujours plaisir à lire. J’avoue que j’aurais eu beaucoup de plaisir à être un de tes disciples.

Merci encore pour vos encore pour vos réponses.

[Richard_35]

Intéressant sujet...

Effectivement, LhIaScZkTer, tes explications changent tout : j'ai mal interprété le terme "composer".

Je me demande, néanmoins, et sauf le respect que je lui dois, si le schéma de Fsmrel n'est pas incomplet, notamment cette partie :



En effet, un matériau (plastique, par exemple) ne peut pas être rattaché, directement, à un diamètre : il faut passer par le matériel.

Suggestion :



Toujours, si j'ai bien tout compris...

[fsmrel]

Bonsoir,

Dans ce modèle, si j’ai une fuite non constatée, c’est-à-dire après la mesure négative de concentration de gaz dans l’air, le technicien ne va pas relever de données concernant le matériel. Donc, l’entité FUITE ou plutôt la table FUITE aura DiametreId et MaterielId à NULL, ce n’est pas top, qu’en penses-tu ?

J’en pense que c’est carrément peccamineux ! Et les tribunaux relationnels sont très sévères à ce sujet...

Allez ! On va dire qu’il y a des fuites dont certaines sont constatées, et pour ça on peut mettre en route la spécialisation. Toutes les fuites sont recensées dans la table FUITE. Si une fuite non constatée passe à l’état constatée, c’est seulement à ce moment-là qu’elle fera l’objet d’une ligne dans la table TABLE FUITE_CONSTATEE.

MCD





MLD




Code SQL

TABLE MATERIAU

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
CREATE TABLE MATERIAU (
   MateriauId           Int                  Not null,
   CONSTRAINT MATERIAU_PK PRIMARY KEY (MateriauId)
) ;

TABLE MATERIEL

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
CREATE TABLE MATERIEL (
   MaterielId           Int                  Not null,
   CONSTRAINT MATERIEL_PK PRIMARY KEY (MaterielId)
) ;

TABLE DIAMETRE

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE TABLE DIAMETRE (
   DiametreId           Int                  Not null,
   MateriauId           Int                  Not null,
   CONSTRAINT DIAMETRE_PK PRIMARY KEY (DiametreId),
   CONSTRAINT DIAMETRE_MATERIAU_FK FOREIGN KEY (MateriauId)
      REFERENCES MATERIAU (MateriauId)
) ;

TABLE MATERIEL_DIAMETRE

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CREATE TABLE MATERIEL_DIAMETRE (
   MaterielId           Int                  Not null,
   DiametreId           Int                  Not null,
   CONSTRAINT MATERIEL_DIAMETRE_PK PRIMARY KEY (MaterielId, DiametreId),
   CONSTRAINT MATERIEL_DIAMETRE_MATERIEL_FK FOREIGN KEY (MaterielId)
      REFERENCES MATERIEL (MaterielId),
   CONSTRAINT MATERIEL_DIAMETRE_DIAMETRE_FK FOREIGN KEY (DiametreId)
      REFERENCES DIAMETRE (DiametreId)
) ;

TABLE FUITE

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
CREATE TABLE FUITE (
   FuiteId              Int                  Not null,
   CONSTRAINT FUITE_PK PRIMARY KEY (FuiteId)
) ;

TABLE FUITE_CONSTATEE

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE TABLE FUITE_CONSTATEE (
   FuiteId              Int                  Not null,
   MaterielId           Int                  Not null,
   DiametreId           Int                  Not null,
   CONSTRAINT FUITE_CONSTATEE_PK PRIMARY KEY (FuiteId),
   CONSTRAINT FUITE_CONSTATEE_FUITE_FK FOREIGN KEY (FuiteId)
      REFERENCES FUITE (FuiteId) ON DELETE CASCADE,
   CONSTRAINT FUITE_CONSTATEE_MATERIEL_DIAMETRE_1 FOREIGN KEY (MaterielId, DiametreId)
      REFERENCES MATERIEL_DIAMETRE (MaterielId, DiametreId)
) ;

Cela vous convient-il ?

[LhIaScZkTer]

Bonjour et merci encore pour vos contributions,

Richard_35, le modèle que tu proposes est tout à fait correct, si on ajoute la spécialisation comme décrite par fsmrel, cependant c'est une question de point de vue. L'énoncé que les techniciens ont fait par rapport à la relation matériau diamètre est la représentation exacte de fsmrel.

J'avoue que ta solution avec la spécialisation de fsmrel me plait énormément et j'ai du mal à choisir entre les deux.

Le problème actuel, fsmrel, est que la représentation graphique que tu as produit avec ton outil de de modélisation, je n'arrive pas à le reproduire avec JMerise (que je découvre) et de mémoire, mais je n'en suis pas sûr, avec Open ModelSphere il n'est non plus pas possible. Je vais devoir retoucher massivement le code généré.

Je vais poster mon modèle final en fin de journée.

Merci à vous pour votre aide

[Richard_35]

Bonjour LhIaScZkTer et Fsmrel,

La partie que je trouve étrange est celle-ci (mais, peut-être, ai-je tort) :



En données, cela donnerait :

Materiau

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
IdMateriau Nom
1          Plastique
2          Acier
3          Fonte

Diametre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
IdDiametre Diametre IdMateriau
1          10       1
2          10       2
3          50       2
4          40       3

signifiant :

• le plastique, tout matériel confondu (que ce soit une vanne, un siphon, ou autre), accepte le diamètre 10 ;
• l'acier, tout matériel confondu (que ce soit une vanne, un siphon, ou autre), accepte le diamètre 10 et de 50 ;
• la fonte, tout matériel confondu (que ce soit une vanne, un siphon, ou autre), accepte le diamètre 40.

==> cela me paraît bizarre de lier des matériaux à des diamètres acceptés, et non pas des couples {matériel, matériaux}. Mais bon, toi seul connaît le métier.

En aparté, les même diamètres pourraient être externalisés afin d'éviter de les répéter.

La balle est dans ton camp, LhIaScZkTer...

PS : dans JMerise :

• pour obtenir (1,1), il faut cocher "lien relatif" dans la fenêtre de propriété du lien ;
• pour l'héritage, il faut lier l'entité fille à l'entité mère, sans passer par une association.

[LhIaScZkTer]

Rebonjour Messieurs,

Richard_35, effectivement tu as tout à fait raison, la logique voudrait que la modélisation soit représentée sous cette forme. Cependant, les techniciens m'ont assurés (certifiés, affirmés) qu'il ne pouvait pas y avoir 2 diamètres semblables, donc l'acier et le plastique ne peuvent pas partagé, comme tu l'énonces, le diamètre 10. Je crois que ton argument est tout à fait juste et demande investigation, je vais essayer de tirer les verres du nez des techniciens.

Effectivement, le lien relatif j'avais trouvé et l'héritage aussi, sauf que pour l'héritage tous les attributs se trouvant dans l'entité parent se retrouvent (automatiquement et physiquement) dans l'enfant et c'est pas trop l'effet voulu

Merci encore pour votre aide.

[Richard_35]

donc l'acier et le plastique ne peuvent pas partagé, comme tu l'énonces, le diamètre 10

==> OK. Donc, dans la fiche de signalement de la fuite (entité FUITE), il n'y a donc même pas besoin de faire saisir le matériau du matériel concerné, la saisie du diamètre suffirait puisque, à 1 diamètre ne correspond qu'1 et 1 seul matériau. Le matériau pourrait s'afficher "pour information".

sauf que pour l'héritage tous les attributs se trouvant dans l'entité parent se retrouvent (automatiquement et physiquement) dans l'enfant et c'est pas trop l'effet voulu

==> c'est vrai et c'est un problème. Mais, je n'utilise JMerise que pour la facilité de création du MCD : je ne me sers, ni du MLD, ni du SQL générés.

[LhIaScZkTer]

Voici le MCD à son état actuel.

Est-ce que cela vous dérange si je vous cite dans mon MCD ? Je n'ai pas pour habitude de m'attribuer tout le mérite d'un travail fourni à plusieurs.

Je changerai le modèle, si les techniciens se rallient à ta proposition Richard_35.

Richard_35, exact, le matériau ne sera là que "pour information".

Merci beaucoup pour votre contribution

Semaine de boulot enfin finie

Bonne fin de soirée.

[Richard_35]

Est-ce que cela vous dérange si je vous cite dans mon MCD ?

==> pas de problème, pour ma part. Mais ce n'est pas réellement nécessaire.

Je n'ai pas pour habitude de m'attribuer tout le mérite d'un travail fourni à plusieurs.

==> le but du forum est d'aider, surtout pas de tirer un quelconque mérite. Une discussion résolue à la satisfaction de l'utilisateur nous suffit amplement .

[fsmrel]

Bonsoir,


Je ne connais pas l’outil que vous utilisez, JMerise, mais dans l’utilisation que vous en faites je relève quand même des manquements par rapport à la Méthode Merise elle-même. L’outil semble permettre l’utilisation de l’identification relative en ayant repris le symbolisme de PowerAMC (cardinalités 1,1 mises entre parenthèses). Dans ces conditions, les attributs materielID et diametreid n’ont pas à être repris dans l’entité-type MATERIEL_DIAMETRE, c’est une redondance, puisque, si l’outil est conforme à Merise, lors du passage au MLD ces attributs seront hérités des entités-types MATERIEL et DIAMETRE :



En vertu de quoi, lors de la dérivation on doit retrouver le MLD tel que je l’ai proposé en son temps ici :



Concernant la spécialisation :

Si vous spécialisez, alors quelle que soit la technique utilisée, une fuite peut être une fuite constatée, mais pas un ensemble de fuites constatées, en conséquence de quoi la patte connectant les entités-types FUITE et FUITE_CONSTATEE doit être porteuse d’une cardinalité maximale non pas N, mais 1. En outre, FUITE_CONSTATEE doit être identifiée relativement à FUITE, et l’attribut fuiteid ne doit donc plus figurer dans (l’en-tête de) FUITE_CONSTATEE :



Et bien sûr cela vaut pour les spécialisations successives de FUITE, c'est-à-dire jusqu’à CARTE_SCHEMATIQUE.


Bonne route !

[LhIaScZkTer]

Bonjour fsmrel,

Merci encore pour ton intervention. Oui, tu as tout à fait raison.

Malheureusement cette outil, que j'utilise pour la première fois, en vue de le tester, ne permet pas de laisser des entités vide. Il demande obligatoirement qu'un attribut clé soit défini pour une entité. Dans le cas de la spécialisation pour fuite et fuite_constatee à savoir : [fuite]----0,1----()----(1,1)----[fuite_constatee] , je suis obligé de mettre une clé primaire dans fuite_constatee sinon le programme ne génère pas le MLD.

Donc, si je rajoute une clé primaire pour fuite_constatee, lors de la génération du MPD j'aurais un résultat tout à fait indésirable qui sera comme suit :
fuite : idFuite, #fuite_constatee
fuite_constatee : idFuiteConstatee, #idFuite

Voilà pourquoi j'ai opté pour l'erreur dont tu fais mention, car lors de la génération du MPD je n'aurais plus qu'à corriger, à la main, les entités dérivées. Je sais, ce n'est pas propre, ni correcte, malheureusement c'est l'outil qui me l'impose, d'où mon commentaire dans le modèle qui dit de faire attention

Sinon, cet outil est très bien, j'aime beaucoup même si on est vite limité, comme on peut le voir dans mon cas. Il y a pas mal d'améliorations à faire, mais il a de l'avenir et je crois même que c'est un membre de DVP qui le développe. Il est vrai que j'aurais peut-être pas dû l'utiliser dans un projet réel, mais je m'en accommode.

Merci encore pour ton aide et bon dimanche

[fsmrel]

Bonsoir LhIaScZkTer,

Dans le cas de la spécialisation pour fuite et fuite_constatee à savoir : [fuite]----0,1----()----(1,1)----[fuite_constatee] , je suis obligé de mettre une clé primaire dans fuite_constatee sinon le programme ne génère pas le MLD.

Malgré l'identification relative ? Si tel était le cas, l’outil commettrait un contre-sens, puisque par définition l'identifiant de FUITE_CONSTATEE est composé de l'identifiant de FUITE, et lui seulement puisque la cardinalité maximale portée par la patte connectant les deux entités-types est 1...

Mais bon, le tout est d'être d'équerre au niveau SQL.

[LhIaScZkTer]

Bonjour fsmrel,

Tout comme St. Thomas je ne crois que ce que je vois. Donc voici un exemple à en faire tomber la culotte jusqu'au cheville.

L'encadré en haut de l'image représente l'erreur générée lors du passage au MLD


Lorsque j'ajoute une clé primaire à l'entité culotte voici le résultat. Evidemment à la base je n'en voulais pas de cette clé primaire culotteId


C'est dans ces cas là qu'on remarque la formidable capacité d'adaptation de l'être humain.

Bonne journée

[fsmrel]

Hello LhIaScZkTer,


On va dire que c’est un modèle Dagobert

Pour remettre les choses à l’endroit, à titre de curiosité et pour le jour où, voici un MCD selon OMS (Open ModelSphere) :



OMS permet de spécialiser FUITE, mais je n'y arrive pas, c’est tordu et non documenté...

MLD produit par l’outil :




Voici aussi le MLD produit avec MWB (MySQL Workbench) :




MWB ne propose pas de modéliser au niveau MCD, mais ça n’est pas franchement fondamental (ceci n'engage que moi, après quarante années de modélisation des bases de données)...


Tout comme pour MS SQL Server :




Il y a encore DB-MAIN :



Avec pour MLD :



(Tout ça dans la série « les gratuits »...)

N.B. Votre outil crée un cycle entre FUITE et FUITE_CONSTATEE : OMS en fait autant (tout comme PowerAMC du reste), et il faut gommer ce cycle à la main : ces outils veulent sans doute ignorer que FUITE_CONSTATEE est fondamentalement une application de FUITE_CONSTATEE dans FUITE. Sic transit (en français : bof...)

Incidemment, quel est votre SGBD ?

[LhIaScZkTer]

Bonjour fsmrel,

Merci encore pour le temps que tu consacres à mon cas.

Le SGBD qui est utilisé est MySQL. J'utilise OMS et MWB (cf ta réponse pour les abréviations ).

J'adore OMS et l'utilise au boulot, mais pour certaines choses il faut faire des milliers de manips pour rien. Il faut également installé un plugin pour la génération du MPD.

MWB, je l'utilise également au boulot. La rétro-conception, l'interface et les fonctionnalité sont vraiment super. Mais, comme tu le dis, on travaille directement dans le MLD. Je préfère partir sur la base d'un MCD, car je n'ai pas assez d'expertise dans le domaine, le cas de ce sujet de discussion est flagrant. Sans parler qu'à chaque fois je me mélange les pinceaux avec la notation merise et uml (concernant les cardinalités)

Par contre, DB-MAIN, je crois que je vais le tester, j'ai vu qu'il propose aussi la génération du MPD. Merci beaucoup, je me réjouis de le tester, si ça se trouve, si le logiciel est complet on utilisera plus que ça.

Enfin, je remarque en toute fin de ton commentaire une référence au mathématique. N'as-tu jamais eu envie de rédiger un article concernant la théorie des ensembles avec fonctions, relations, relations d'ordre, etc, mais avec le pendant patatoïde (diagramme de Venn), Entité-Relation voir même avec des exemples SQL ? Je pense qu'au final il serait plus simple d'ingurgiter la dose mathématique par une représentation facile à retenir et enfin, d'avoir un raisonnement mathématique dans la conception de bases de données, qui se ferait plus naturellement.

J'avoue, je crois un peu au Père-Noël
Je me serai volontiers lancé dans une telle entreprise, mais j'ai pas assez de connaissance en math ni une expérience éprouvée en modélisation de base de données.

Bonne journée

[fsmrel]

Bonsoir LhIaScZkTer-au-nom-imprononçable,

J'adore OMS et l'utilise au boulot, mais pour certaines choses il faut faire des milliers de manips pour rien.

OMS¹ est la version gratuite de Silverrun, AGL québécois, qui à l’origine se situait au niveau logique (au sens merisien du terme pour faire court). Si Open ModelSphere permet de faire des MCD à la Merise, c’est parce qu’il y a vingt ans l'éditeur canadien voulait vendre Silverrun à une banque on ne peut plus française, mais qui avait posé ses conditions : pouvoir travailler avec des MCD bourrés de patatoïdes (culture merisienne oblige). Le spécialiste québécois avec qui j’avais travaillé pour cette banque avait trouvé bizarre cette volonté de couche supplémentaire, mais bon... J’ai donc utilisé Silverrun chez le banquier, mais — paradoxe ! — directement au niveau MLD, car je ne voulais pas perdre de temps.

Concernant les « manips pour rien », si OMS demande par exemple qu’on procède à la génération des clés étrangères au stade MLD alors qu’il pourrait le faire de lui-même, c’est peut-être du fait de cette surcouche originellement à l’intention des Français (mais la version payante le fait-elle peut-être d’office ?)

Je préfère partir sur la base d'un MCD, car je n'ai pas assez d'expertise dans le domaine.

C’est à double tranchant, car certains problèmes relativement faciles à résoudre au stade MLD (par exemple avec MWB) sont délicats à traiter avec un MCD (CIF, contraintes de chemin, d’inclusion, j’en passe et des meilleures), et la moitié du temps je me plante...

Pour ma part, je modélise d’abord au niveau relationnel (au sens de la théorie relationnelle). Un bon exemple, propre à semer la panique, est celui de la réservation de salles pour des cours, dès lors que l’on veut représenter dans le MCD les contraintes empêchant le surbooking et la bilocation. Voyez par exemple la discussion dans laquelle j’ai proposé un MCD qu’un merisien normalement constitué pourrait considérer comme plutôt tordu, et dont je n’ai du reste pas encore complètement vérifié la validité. Néanmoins, ce MCD n’est jamais que la rétroconception de contraintes assez faciles à exprimer dans le cadre de la théorie relationnelle, pour peu que l’on connaisse la théorie des dépendances fonctionnelles dont je traite en partie ici.

DB-MAIN, je crois que je vais le tester.

L’outil est un peu déroutant au départ et il y a intérêt à commencer par lire les divers tutos, mais il permet de traiter des contraintes au niveau MCD de façon beaucoup plus satisfaisante que ne le fait Merise. Voyez ici la discussion dans laquelle je montre comment avec DB-MAIN on fait l’économie des CIF et autre DF merisiennes, notamment l’exemple des courses hippiques où il s’agit d’interdire qu’un jockey monte deux chevaux dans la même course, qu’un cheval soit monté en même temps par deux jockeys, etc. ! Les forumeurs essaient de s’en sortir avec Merise, sans les CIF, mais ils reconnaissent qu’ils s’embourbent.

Je pense qu'au final il serait plus simple d'ingurgiter la dose mathématique par une représentation facile à retenir et enfin, d'avoir un raisonnement mathématique dans la conception de bases de données, qui se ferait plus naturellement.

J’y ai fait allusion ci-dessus : la clé est fournie avec la théorie des dépendances fonctionnelles. Je développerai peut-être tout cela de A à Z. Pour Noël ?

__________________________________________

¹ Rien à voir avec le fameux OMS (Отдел международной связи) actif jusqu’en 1943, date de la dissolution du Kominterm du désopilant Manou !