Discussion :

[Kropernic]

Bonsoir Krop,

C’est ce qu’aurait produit la dérivation classique d’un MCD ou d’un DC (diagramme de classes) en MLD. Libre à vous de remplacer la clé primaire {BRAD_ID, DEP_ID} par autre chose, néanmoins il y là une contrainte d’unicité qui doit être préservée au moyen d’une clé alternative {BRAD_ID, DEP_ID}, d’où un système en fait plus lourd.

Je ne pensais nullement à remplacer la clef primaire par autre chose que ce qu'elle n'est. Mais je me rends compte qu'en fait, je faisais p-e des liens identifiants sans le savoir. En fait, oubliez ce que j'ai dit. C'était une réminiscence de mes pratiques scolaires.

Sans des règles de gestion stabilisées, il est impossible de se prononcer, sinon qu’intuitivement le diagramme BIS a l’air sympathique...

Si déjà il a l'air sympatique, c'est bon signe

Pour ma part je n'ai pas de problème avec ça. A mon avis, la 1re hypothèse est la bonne.

Mmmh... Le problème se trouverait donc entre le clavier et la chaise...

[Kropernic]

J'en reviens aux règles de gestions.

Avant le MLD_BIS, elles étaient les suivantes :

1°Un magasin possède au moins un étage et un étage est possédé par un magasin
2°Un étage possède au moins une zone et une zone est possédée par un étage
3°Une marque est associée à au moins un rayon et un rayon est associé à au moins une marque.
4°Un rayon peut être composé de plusieurs segments et un segment compose un rayon.
5°Un code démo détermine une marque + un rayon et une marque + un rayon peut déterminer plusieurs code démo.
6°Un fournisseur fournit une ou plusieurs marques et une marque est fournie par un ou plusieurs fournisseurs.
7°Un fournisseur peut approvisionner (fournir étant déjà pris comme nom d'association...) plusieurs codes démo et un code démo est approvisionné par un fournisseur.

Avec le MLD_BIS, j'avais signalé un doute sur les règles 3, 6 et 7.

Au sens stricte, elles sont correctes. Cependant, la représentation de ces règles produisent un MLD qui ne me permet pas, pour un article précis (donc un rayon et une marque), de savoir de quel fournisseur il vient.

Concernant les nouvelles règles de gestion, même si je vois bien que le MLD_BIS est correct, j'avoue ne pas savoir comment les formuler.
La règle 6° peut rester telle qu'elle est. Par contre la 3 et la 7 devraient changer car, si je me réfère au billet de l'ami Cinéphil, leur traduction en MCD puis en MLD ne donnerait pas la représentation de MLD_BIS.

Pourtant, avec ce MLD_BIS, elles sont quand même bien respectées car, pour la règle 7°, on voit bien qu'un code démo (table CCD) n'est fourni que par un et un seul fournisseur et qu'un fournisseur peut en fournir plusieurs et il en va de même pour la règle 3°.

Que manque-t-il alors à ces règles de gestions pour permettre d'en arriver au MLD_BIS ? Je suis un peu perdu...

[Kropernic]

Allez hop, encore un peu d'ajout.

Lors d'une restitution, les informations à encoder sont les mêmes que lorsqu'on retrouve une étiquette par terre (et qu'on présume que l'article a été volé).

J'ai donc le MLD en pièce jointe.

Avec le problème évidement que j'ai deux couples de tables avec le même nom qui sera corrigé dès que j'aurai trouvé un nom adéquat et parlant. En attendant, tant que ça reste sur le graphique, on voit de quoi on parle.

Par contre, ça n'a pas l'air de déranger MWB et ça m'amuse assez car je me demande comment il s'en sort dans la soute pour généré les scripts de création de DB pour mysql ^^

[fsmrel]

Bonjour bombardier Krop,

3°Une marque est associée à au moins un rayon et un rayon est associé à au moins une marque.
6°Un fournisseur fournit une ou plusieurs marques et une marque est fournie par un ou plusieurs fournisseurs.
7°Un fournisseur peut approvisionner (fournir étant déjà pris comme nom d'association...) plusieurs codes démo et un code démo est approvisionné par un fournisseur.
Avec le MLD_BIS, j'avais signalé un doute sur les règles 3, 6 et 7.
La règle 6° peut rester telle qu'elle est.

Une proposition améliorable. Dans l’ordre :

— Un fournisseur fournit une ou plusieurs marques et une marque est fournie par un ou plusieurs fournisseurs.

— On désigne par le terme « marque fournie » une marque fournie par un fournisseur.

—Un rayon héberge une ou plusieurs marques fournies et une marque fournie peut être hébergée dans un ou plusieurs rayons.

— On désigne par « marque en rayon » une marque fournie qui est en rayon.

— Une marque en rayon fait l’objet d’au moins un code démo et un code démo désigne une seule marque en rayon.

Le verbe « héberger » pourrait être remplacé par « pourvoir », « occuper », « achalander », « accueillir », « accepter »...


A noter le prédicat du code démo :

Le code démo D désigne la marque M fournie par le fournisseur F et présente dans le rayon R.

[Kropernic]

Bonjour bombardier Krop,

C'est vrai que j'enchaîne pas mal les messages... Mais que voulez-vous... Quand on aime, on ne compte pas .

Une proposition améliorable. Dans l’ordre :

— Un fournisseur fournit une ou plusieurs marques et une marque est fournie par un ou plusieurs fournisseurs.

— On désigne par le terme « marque fournie » une marque fournie par un fournisseur.

—Un rayon héberge une ou plusieurs marques fournies et une marque fournie peut être hébergée dans un ou plusieurs rayons.

— On désigne par « marque en rayon » une marque fournie qui est en rayon.

— Une marque en rayon fait l’objet d’au moins un code démo et un code démo désigne une seule marque en rayon.

Le verbe « héberger » pourrait être remplacé par « pourvoir », « occuper », « achalander », « accueillir », « accepter »...

Ahaaaaah ! Voilà le truc. Inventer du nouveau vocabulaire qui fait bien passer l'idée pour désigner les tables de jointures. Encore une arme que j'ajoute à ma bat-ceinture .

A noter le prédicat du code démo :

Le code démo D désigne la marque M fournie par le fournisseur F et présente dans le rayon R.

Que faut-il faire de ce prédicat ? Certes cette affirmation est vraie mais après ?

Quant aux règles de gestion, voici donc la nouvelle version complète :

1°Un magasin possède au moins un étage et un étage est possédé par un magasin
2°Un étage possède au moins une zone et une zone est possédée par un étage
3°Un rayon peut être composé de plusieurs segments et un segment compose un rayon.
4°Un fournisseur fournit une ou plusieurs marques et une marque est fournie par un ou plusieurs fournisseurs. On désigne par le terme « marque fournie » une marque fournie par un fournisseur.
5°Un rayon héberge une ou plusieurs marque fournies et une marque fournie peut être hébergée dans un ou plusieurs rayons. On désigne par « marque en rayon » une marque fournie qui est en rayon.
6°Un code démo désigne une seule marque en rayon et une marque en rayon peut être désignée par un code démo.

A la lecture de la règle 6, j'ai donc un souci dans mon MLD_BIS au niveau des cardinalités. C'est corrigé est c'est en pièce jointe.

A propos des héritages, doivent-ils faire l'objet d'une règle de gestion ?
Mon instinct me réponds que oui mais bon...
Voici les règles pour les héritages (et pour les sorties que j'avais oublié):

7°Une zone peut faire l'objet de plusieurs vols et un vol a lieu dans une seule zone.
8°Un vol est soit une étiquette retrouvée, soit un antivol retrouvé.
9°Une étiquette est soit de la marchandise démo, soit de la marchandise ferme.
10°Un étage peut posséder plusieurs sorties et une sortie est possédée par un étage.
11°Une sortie peut observer une restitution et une restitution est observée par une sortie.
12°Une restitution concerne soit de la marchandise démo, soit de la marchandise ferme.

Au niveau des cardinalités des héritages, j'avais 1-1 partout. Mais étant donné que c'est toujours soit l'un, soit l'autre, j'ai remplacé par 1-0..1 partout. Ai-je bien raisonné ?

EDIT :
Et j'ai oublié celles-ci

13°Une étiquette de marchandise ferme retrouvée concerne une marque en rayon et une marque en rayon peut être concernée par une étiquette de marchandise ferme retrouvée.
14°Une étiquette de marchandise démo retrouvée concerne un code démo et un code démo peut être concerné par une étiquette de marchandise démo retrouvée.
15°Une restitution de marchandise ferme concerne une marque en rayon et une marque en rayon peut être concernée par une restitution de marchandise ferme.
16°Une restitution de marchandise démo concerne un code démo et un code démo peut être concerné par une restitution de marchandise démo.

[fsmrel]

’soir Krop,

ça n'a pas l'air de déranger MWB et ça m'amuse assez car je me demande comment il s'en sort dans la soute pour généré les scripts de création de DB pour mysql.

Nous utilisons la version gratuite de MWB qui n’a donc pas d’’état d’âme et produit une seule table, donc un résultat faux. Je suppose que la version payante ne laisse pas passer ça. En effet, voici ce qu’on lit à propos des fonctionnalités de MWB :



Mais un concepteur vigilant n’a pas de problème de validation et de toute façon SQL se chargera de le rappeler à l’ordre...

Que faut-il faire de ce prédicat ? Certes cette affirmation est vraie mais après ?

Ça vous servira quand vous ferez du relationnel dans son environnement naturel, la logique du 1er ordre...
Cela dit, chaque relvar (variable relationnelle) est décrite par son en-tête (l’ensemble des noms des attributs typés qui la composent) :

CONCESSION_CODE_CCD {CCD_ID, CCD_CODE, BRA_ID, SUP_ID, DEP_ID}

Pour simplifier, je n’ai pas fait mention pour cette relvar du type de ses attributs.
De son coté, un prédicat est un énoncé vérifonctionnel, c'est-à-dire prenant la valeur « vrai » ou la valeur « faux ». Dans un 1er temps, le prédicat donne le sens des données décrites par l’en-tête de la relvar :

Le code démo CCD_ID connu de l’utilisateur par le code CCD_CODE désigne la marque BRA_ID fournie par le fournisseur SUP_ID et présente dans le rayon DEP_ID.

Un prédicat correctement formulé montre ce que l’on a précisément compris des règles de gestion dont il est une conséquence.
Dans le cadre de la théorie relationnelle, chaque relvar (y-compris, vue) a son prédicat et la conjonction (ET, AND) de l’ensemble des prédicats représente le prédicat de la base de données. Cette fois-ci on remonte en fait à la logique du 1er ordre de Frege et je vous invite à lire l’ouvrage de C.J. Logic and Databases, The Roots of Relational Theory où tout cela est traité en plus de 400 pages et que je me refuse de synthétiser ici... Retenez qu’énoncer le prédicat d’une relvar met en évidence ce que l’on a compris de cette relvar et ça aide beaucoup pour modéliser : il y a peu, le prédicat de CONCESSION_CODE_CCD était le suivant (et aurait peut-être fait tiquer l’utilisateur) :

Le code démo CCD_ID connu de l’utilisateur par le code CCD_CODE désigne la marque BRA_ID présente dans le rayon DEP_ID.

A propos des héritages, doivent-ils faire l'objet d'une règle de gestion ?

Bien sûr ! Et le terme « est un » (Is a) est là pour ça. Mais on parle de généralisation/spécialisation plutôt que d’héritage (un sous-type hérite des propriétés de l’entité-type sont il est la spécialisation (ou la généralisation)).

j'ai remplacé par 1-0..1 partout.

C’est tout bon.

Un vol est soit une étiquette retrouvée, soit un antivol retrouvé.

Mais alors une étiquette retrouvée est un vol, même chose qu’un antivol retrouvé : attention au vocabulaire, il faut tout de suite prendre de bonnes habitudes : une étiquette et un antivol retrouvés sont des objets retrouvés.

Même chose à propos de la relation Etiquette - Marchandise : une étiquette n’est pas de la marchandise (sauf chez les marchands d’étiquettes et pour ceux qui chez vous en gèrent le stock...)

Une sortie peut observer une restitution et une restitution est observée par une sortie.

Qu'une sortie ait des yeux, c’est un peu étonnant ! Je suppose néanmoins que la restitution est un petit peu forcée ?


Cela dit, votre diagramme tient la route, je plussoie !


P.-S. Comment vont les gifts ?

[Kropernic]

’soir Krop,
Nous utilisons la version gratuite de MWB qui n’a donc pas d’’état d’âme et produit une seule table, donc un résultat faux. Je suppose que la version payante ne laisse pas passer ça. En effet, voici ce qu’on lit à propos des fonctionnalités de MWB :



Mais un concepteur vigilant n’a pas de problème de validation et de toute façon SQL se chargera de le rappeler à l’ordre...

Tout de même, je suis d'accord que c'est une version gratuite et donc qu'on n'a pas trop à se plaindre mais un simple test pour vérifier que deux tables n'ont pas le même nom, ça ne mange quand même pas de pain.

Ça vous servira quand vous ferez du relationnel dans son environnement naturel, la logique du 1er ordre...

Va falloir que je me renseigne sur ce qu'est la logique du 1er ordre ^^.

Cela dit, chaque relvar (variable relationnelle) est décrite par son en-tête (l’ensemble des noms des attributs typés qui la composent) :

CONCESSION_CODE_CCD {CCD_ID, CCD_CODE, BRA_ID, SUP_ID, DEP_ID}

Pour simplifier, je n’ai pas fait mention pour cette relvar du type de ses attributs.
De son coté, un prédicat est un énoncé vérifonctionnel, c'est-à-dire prenant la valeur « vrai » ou la valeur « faux ». Dans un 1er temps, le prédicat donne le sens des données décrites par l’en-tête de la relvar :

Le code démo CCD_ID connu de l’utilisateur par le code CCD_CODE désigne la marque BRA_ID fournie par le fournisseur SUP_ID et présente dans le rayon DEP_ID.

Un prédicat correctement formulé montre ce que l’on a précisément compris des règles de gestion dont il est une conséquence.

Ok. Donc on pourrait faire la même chose pour toutes les tables et présenté cela à l'utilisateur pour validation. J'avais tenté cela avec les règles de gestion à l'époque des gifts mais ils m'avaient regardé avec des yeux de merlans frits et se demandait ce que je leur voulais.

Dans le cadre de la théorie relationnelle, chaque relvar (y-compris, vue) a son prédicat et la conjonction (ET, AND) de l’ensemble des prédicats représente le prédicat de la base de données. Cette fois-ci on remonte en fait à la logique du 1er ordre de Frege et je vous invite à lire l’ouvrage de C.J. Logic and Databases, The Roots of Relational Theory où tout cela est traité en plus de 400 pages et que je me refuse de synthétiser ici...

J'vais regarder ce qu'il coûte. Ca pourrait être faire bonne impression dans ma bibliothèque (inexistante pour l'instant).

Retenez qu’énoncer le prédicat d’une relvar met en évidence ce que l’on a compris de cette relvar et ça aide beaucoup pour modéliser : il y a peu, le prédicat de CONCESSION_CODE_CCD était le suivant (et aurait peut-être fait tiquer l’utilisateur) :

Le code démo CCD_ID connu de l’utilisateur par le code CCD_CODE désigne la marque BRA_ID présente dans le rayon DEP_ID.

Même remarque que précédemment.

Bien sûr ! Et le terme « est un » (Is a) est là pour ça. Mais on parle de généralisation/spécialisation plutôt que d’héritage (un sous-type hérite des propriétés de l’entité-type sont il est la spécialisation (ou la généralisation)).

Déformation professionnelle. Je suis programmeur à la base ^^.

C’est tout bon.

Mais alors une étiquette retrouvée est un vol, même chose qu’un antivol retrouvé : attention au vocabulaire, il faut tout de suite prendre de bonnes habitudes : une étiquette et un antivol retrouvés sont des objets retrouvés.

Là, je ne vous suis pas. En fait, dans le jargon, il n'y a pas de terme utilisé pour désigner ce que j'ai appelé vol. L'utilisateur reçoit des antivols ou des étiquettes qui ont été retrouvés (par terre) dans le magasin avec la zone où ils ont été trouvé et il se contente d'encoder religieusement cela dans l'application (qui est une infamie faite en access pour le moment).
Du coup, j'ai donc "inventé" le terme VOL (la table THE) et je décris donc quand est-ce qu'on a un vol --> quand on retrouve une étiquette ou un antivol.

Même chose à propos de la relation Etiquette - Marchandise : une étiquette n’est pas de la marchandise (sauf chez les marchands d’étiquettes et pour ceux qui chez vous en gèrent le stock...)

Certes, une étiquette n'est pas de la marchandise. Mais il est demandé de faire la distinction entre les étiquettes qui étaient sur de la marchandise "ferme" (propre à l'entreprise) et les étiquettes qui étaient sur de la marchandise démo (proposée à la vente par un fournisseur dans un espace qu'il nous loue). D'où les tables OWN et CON. Pareil pour une restitution.

Qu'une sortie ait des yeux, c’est un peu étonnant ! Je suppose néanmoins que la restitution est un petit peu forcée ?

C'est le garde posté à la sortie qui a des yeux. *siffle*
Quand au caractère forcé de la restitution, si vous voulez dire que le garde force à rendre la marchandise, c'est bien cela. Notez que le voleur a également le choix de la payer. (En plus, je crois, d'une amende administrative et d'une visite au commissariat)

Cela dit, votre diagramme tient la route, je plussoie !

C'est pas pour dire, mais c'est quand même super gratifiant d'avoir ce genre de commentaire venant de vous .

P.-S. Comment vont les gifts ?

Pour le moment, tout va bien. Mais je dois probablement avoir encore quelques soucis car, quand la centrale fait une boulette (genre se trompe de numéro dans une commande de gifts alors que je précise bien dans l'application que c'est une action non réversible), c'est un peu la galère pour corriger le tir. Il faut supprimer la commande, les gifts-commandés, les entrées dans l'inventaire de l'entrepôt si jamais ils ont déjà réceptionné la commande et pour finir, les chèques/cartes eux-mêmes (et les lignes de la table mère qui vont avec). Et j'imagine que cela pourrait être plus ou moins automatique si j'avais les bons déclencheurs ON DELETE/ON UPDATE sur mes relations. Mais sinon, au niveau intégrité, pour le moment, c'est niquel. Juste encore des indexes à ajouter pour améliorer certaines requêtes mais j'attends d'avoir eu ma formation de DBA pour faire ça car j'ai peur de faire de la merde.

[Kropernic]

A propos de la logique de 1er ordre, je fais une rapide recherche sur google et j'ouvre le 2e lien proposé.

Résultat : Ce n'est pas la joie. Au deuxième point, je suis déjà largué. J'ai beau comprendre chaque mot un par un par, la phrase en elle-même ne me parle pas du tout . J'espère que l'ouvrage que vous avez mentionné y va plus doucement

[fsmrel]

Bonsoir Krop,

Donc on pourrait faire la même chose pour toutes les tables et présenté cela à l'utilisateur pour validation. J'avais tenté cela avec les règles de gestion à l'époque des gifts mais ils m'avaient regardé avec des yeux de merlans frits et se demandaient ce que je leur voulais.

Il faut y aller mollo, il faut que ça leur cause de façon naturelle. Si vous écrivez :

Le code démo CCD_ID connu de l’utilisateur par le code CCD_CODE désigne la marque BRA_ID fournie par le fournisseur SUP_ID et présente dans le rayon DEP_ID.

Alors je comprends qu’ils vous regardent ainsi. Vous pouvez essayer à nouveau, mais en remplaçant par du concret ce qui ressemble à des signes cabalistiques et en cachant ce qui ne les concernent pas (CCD_ID) :

Le code démo Armur-007 désigne la marque Flingues de rêve fournie par le fournisseur Volfoni Frères et présente dans le rayon Armes à feu.

En tout cas ça ne vous dispense pas de leur présenter un joli MCD avec des noms naturels pour les objets (disons les noms des tables), qui soit chargé d’émotion (d’expérience ils aiment bien !) Avec MWB ça n’est pas gagné, à moins — paradoxalement ! — de cacher les attributs au bénéfice d’énoncés qui les tricotent, comme ci-dessus. En plus, n’hésitez pas à urbaniser votre diagramme : inutile de surcharger le diagramme des vols en y montrant les fournisseurs et autres objets non concernés par les vols.

Pour urbaniser, en plus du diagramme global, créer un diagramme par thème, Marques, Vols, etc. (diagramme qui en fait est une vue) : Model > Add Diagram (Ctrl-T)




Par défaut, le nouveau diagramme est nommé « EER diagram ». Pour le renommer, par exemple en « Vols » : Model > Diagram Properties and Size... :





Pour faire apparaître les tables une par une ou par paquets, faire un drag drop de leur nom au catalogue :



=>



A noter : au fur et à mesure que les tables sont présentes, MWB se charge d’afficher les liens : l’opération de création d’un nouveau diagramme est donc rapide.

Là, je ne vous suis pas. En fait, dans le jargon, il n'y a pas de terme utilisé pour désigner ce que j'ai appelé vol. L'utilisateur reçoit des antivols ou des étiquettes qui ont été retrouvés (par terre) dans le magasin avec la zone où ils ont été trouvé et il se contente d'encoder religieusement cela dans l'application (qui est une infamie faite en access pour le moment).
Du coup, j'ai donc "inventé" le terme VOL (la table THE) et je décris donc quand est-ce qu'on a un vol --> quand on retrouve une étiquette ou un antivol.

Comme vous êtes passé à la généralisation/spécialisation, disons que VOL est un surtype. Il en va des vols comme des figures planes en géométrie : si FIGURE_PLANE est un type, c’est un surtype pour ELLIPSE (qui en est un sous-type), tout comme POLYGONE. De la même façon ELLIPSE est un surtype pour CERCLE, etc.

Il y a là une homogénéité, une cohérence dans la terminologie. Une pièce de monnaie est de forme circulaire, mais il ne viendrait à l’idée de personne de dire que PIECE_DE_MONNAIE est sous-type d’ELLIPSE, il est seulement correct de dire que le type de PIECE_DE_MONNAIE est ELLIPSE (plus précisément CERCLE pour cet exemple). Si VOL est un surtype, alors ses sous-types sont VOL_DE_CECI, VOL_DE_CELA car un vol est un vol, mais une étiquette n’est pas un vol, pas plus qu’un antivol...

Si vous tenez à la généralisation/spécialisation, alors il faudra raisonner ici en termes de généralisation. Par exemple, si on a les types ELLIPSE et POLYGONE, quel type pourrait en être la généralisation ? FIGURE_PLANE convient certainement : une ellipse est une figure plane, un polygone est une figure plane, et une figure plane peut être une ellipse ou un polygone.

« EST » (IS A) est le mot-clé à avoir présent à l’esprit dans cette alchimie, tout comme l’énoncé général : X est un Y ou un Z, ainsi que l’énoncé complémentaire : Y est un X, Y est un X. Remplaçons X par VOL, Y par ANTIVOL et Z par ETIQUETTE : ça coince, je ne sache pas comme je l’ai écrit un peu plus haut qu’un antivol puisse être un vol...

Cela dit, ne changez pas pour autant les noms de vos tables, mais souvenez-vous des polygones à l’occasion de l’élaboration d’un prochain MCD (MLD)...

Pour le moment, tout va bien. Mais je dois probablement avoir encore quelques soucis car, quand la centrale fait une boulette (genre se trompe de numéro dans une commande de gifts alors que je précise bien dans l'application que c'est une action non réversible), c'est un peu la galère pour corriger le tir. Il faut supprimer la commande, les gifts-commandés, les entrées dans l'inventaire de l'entrepôt si jamais ils ont déjà réceptionné la commande et pour finir, les chèques/cartes eux-mêmes (et les lignes de la table mère qui vont avec).

Je constate que dans votre MCD actuel (vols), vous avez pris soin d’avoir un identifiant artificiel et un identifiant naturel (respectivement BRA_ID et BRA_CODE par exemple pour la table T_BRAND_BRA des marques). Je suppose que vous n’avez pas mis ce binôme en place pour les commandes de gifts que vous évoquez ? Si c’est bien le cas, vous pourriez peut-être voir à ajouter à l’identifiant actuel (clé primaire) son jumeau qui ferait juste l’objet d’une clé alternative et dont la valeur serait la copie de celle de la clé primaire, cette clé alternative serait le point d’entrée dans le système pour l’utilisateur, et modifiable par lui (la clé primaire pour sa part lui restant bien sûr cachée, donc d’une stabilité à toute épreuve).

A propos de la logique de 1er ordre, je fais une rapide recherche sur google et j'ouvre le 2e lien proposé.

Résultat : Ce n'est pas la joie. Au deuxième point, je suis déjà largué. J'ai beau comprendre chaque mot un par un par, la phrase en elle-même ne me parle pas du tout . J'espère que l'ouvrage que vous avez mentionné y va plus doucement

J’ai refermé tout de suite ! Des choses finalement simples y sont expliquées de façon très formelle et hermétique. Un peu comme le modèle relationnel de données expliqué par certains théoriciens que j’ai beaucoup de mal à suivre : c'est pourquoi je remercie Chris Date d'avoir pris leur contre-pied et d'avoir eu le souci de la clarté et de la pédagogie, sans rien perdre en précision ! Ne vous lancez pas tout de suite dans l’ouvrage que j’ai mentionné, commencez par son célèbre (près de 800000 exemplaires vendus) et très clair An Introduction to Database Systems (8e édition).

[Kropernic]

Bonsoir Krop,

Il faut y aller mollo, il faut que ça leur cause de façon naturelle. Si vous écrivez :

Le code démo CCD_ID connu de l’utilisateur par le code CCD_CODE désigne la marque BRA_ID fournie par le fournisseur SUP_ID et présente dans le rayon DEP_ID.

Alors je comprends qu’ils vous regardent ainsi. Vous pouvez essayer à nouveau, mais en remplaçant par du concret ce qui ressemble à des signes cabalistiques et en cachant ce qui ne les concernent pas (CCD_ID) :

Le code démo Armur-007 désigne la marque Flingues de rêve fournie par le fournisseur Volfoni Frères et présente dans le rayon Armes à feu.

C'est bien ce que j'avais en tête. Quand je disais qu'ils me regardaient avec des yeux de merlans frits, c'était au sujet des règles de gestion. Elles ne contiennent pourtant rien de technique et sont formulées en Français (un peu-beaucoup redondant mais en Français quand même).

Comme vous êtes passé à la généralisation/spécialisation, disons que VOL est un surtype. Il en va des vols comme des figures planes en géométrie : si FIGURE_PLANE est un type, c’est un surtype pour ELLIPSE (qui en est un sous-type), tout comme POLYGONE. De la même façon ELLIPSE est un surtype pour CERCLE, etc.

Il y a là une homogénéité, une cohérence dans la terminologie. Une pièce de monnaie est de forme circulaire, mais il ne viendrait à l’idée de personne de dire que PIECE_DE_MONNAIE est sous-type d’ELLIPSE, il est seulement correct de dire que le type de PIECE_DE_MONNAIE est ELLIPSE (plus précisément CERCLE pour cet exemple). Si VOL est un surtype, alors ses sous-types sont VOL_DE_CECI, VOL_DE_CELA car un vol est un vol, mais une étiquette n’est pas un vol, pas plus qu’un antivol...

Si vous tenez à la généralisation/spécialisation, alors il faudra raisonner ici en termes de généralisation. Par exemple, si on a les types ELLIPSE et POLYGONE, quel type pourrait en être la généralisation ? FIGURE_PLANE convient certainement : une ellipse est une figure plane, un polygone est une figure plane, et une figure plane peut être une ellipse ou un polygone.

« EST » (IS A) est le mot-clé à avoir présent à l’esprit dans cette alchimie, tout comme l’énoncé général : X est un Y ou un Z, ainsi que l’énoncé complémentaire : Y est un X, Y est un X. Remplaçons X par VOL, Y par ANTIVOL et Z par ETIQUETTE : ça coince, je ne sache pas comme je l’ai écrit un peu plus haut qu’un antivol puisse être un vol...

Cela dit, ne changez pas pour autant les noms de vos tables, mais souvenez-vous des polygones à l’occasion de l’élaboration d’un prochain MCD (MLD)...

Il s'agit donc juste d'un terme mal choisi. Donc tant qu'on sait de quoi on parle, tout va bien j'imagine.

Je constate que dans votre MCD actuel (vols), vous avez pris soin d’avoir un identifiant artificiel et un identifiant naturel (respectivement BRA_ID et BRA_CODE par exemple pour la table T_BRAND_BRA des marques). Je suppose que vous n’avez pas mis ce binôme en place pour les commandes de gifts que vous évoquez ? Si c’est bien le cas, vous pourriez peut-être voir à ajouter à l’identifiant actuel (clé primaire) son jumeau qui ferait juste l’objet d’une clé alternative et dont la valeur serait la copie de celle de la clé primaire, cette clé alternative serait le point d’entrée dans le système pour l’utilisateur, et modifiable par lui (la clé primaire pour sa part lui restant bien sûr cachée, donc d’une stabilité à toute épreuve).

Honnêtement, le cas d'erreur que j'ai énnoncé n'est qu'anecdotique. Je préfère donc ne pas apporter de modifications à un système qui fonctionne.
D'autant plus que, j'ai deux nouveaux projets (et demi) sur les bras. Celui sur les articles volés qui nous occupe actuellement et un autre pour la gestion des droits des utilisateurs. Et il y en a un troisième mais pour lequel, c'est plus mon collègue qui s'en occupe. Je vais juste apporter mon grain de sel toute une salière lorsqu'il s'agira de valider le modèle de la DB.

J’ai refermé tout de suite ! Des choses finalement simples y sont expliquées de façon très formelle et hermétique. Un peu comme le modèle relationnel de données expliqué par certains théoriciens que j’ai beaucoup de mal à suivre : c'est pourquoi je remercie Chris Date d'avoir pris leur contre-pied et d'avoir eu le souci de la clarté et de la pédagogie, sans rien perdre en précision ! Ne vous lancez pas tout de suite dans l’ouvrage que j’ai mentionné, commencez par son célèbre (près de 800000 exemplaires vendus) et très clair An Introduction to Database Systems (8e édition).

Vous me rassurez . Je vais tenter de me procurer cet ouvrage. Cela me fera de la lecture dans le train (je commence à en avoir assez de faire des sudokus )

[Kropernic]

Hello,

Je reviens sur le sujet histoire d'être sûr de pas faire de connerie.

Je rentre directement dans le vif du sujet avec une pièce jointe sur lequel on peut voir un bout du MLD du projet.

On peut déjà constater qu'il y a eu un peu de changement côté départements avec la gestion des langues. Ce côté, pas de souci.

Là où j'aimerais une validation, c'est au niveau de la table T_CONTRAT_CTR.

Les règles de gestions concernant les contrats sont les suivantes :

1. Un contrat (de démonstration) se voit attribuer un code démo et un code démo est attribué à plusieurs contrats.
2. Un contrat concerne une "marque en rayon" (triplet {fournisseur,marque,rayon}) et une marque en rayon est concernée par plusieurs contrats.

Concernant la règle 1, il va de soi qu'un code démo n'est attribué qu'à un contrat à la fois. Mais sur la durée, il peut en avoir concerné plusieurs successivement.
Idem pour le règle 2

Du coup, l'ancienne règle de gestion, présente dans le message #25 et que je reprend ci-dessous, ne serait-elle pas obsolète ?

6°Un code démo désigne une seule marque en rayon et une marque en rayon peut être désignée par un code démo.

La marque en rayon désignée par le code démo peut être connue par l'intermédiaire du contrat.

Personnellement, je supprimerais donc la relation entre les tables T_CONCESSION_CODE_CCD et TJ_DEP_JSB_JDJ mais j'ai peur d'aller un peu vite en besogne.

Alors je demande conseil et ça me permet aussi de laisser reposer un peu schmilblik le temps d'avoir un réponse et de le réexaminer à tête reposée.

[Kropernic]

Comme je le disais dans mon message précédent, fallait laisser reposer un peu.

Ce matin, mini réunion pour valider deux ou trois truc et voilà le MLD final auquel je suis arrivé (crf. pièce jointe).

Pour l'anecdote, cette DB est destinée à interagir avec plusieurs applications qui auront chacune "leur champ d'action" sur cette dernière. Et cela m'aura appris qu'il faut (toujours) d'abord modéliser l'ensemble du sujet traiter de manière à refléter exactement la réalité plutôt que de se contenter de qui nous importe.

Pour le cas concrets, l'application de gestion des articles volés dont je réalisais le MCD/MLD et pour lequel j'ai ouvert cette discussion n'a que faire des contrats. Cependant, l'application sur laquelle mon collègue bosse (enfin là il est en vacance le bougre) et pour laquelle j'ai décidé de lui débroussailler le travail (en attendant d'avoir des données concrètes pour faire des tests sur mon appli qui est presque finie) va s'occuper de tout ce qui est contrat.

Conclusion, mon application dont le développement étant en phase terminale (y avait plus qu'à tester) va devoir être remanier (heureusement légèrement) car le schéma de la DB a changé.

[fsmrel]

Hello Krop,

La marque en rayon désignée par le code démo peut être connue par l'intermédiaire du contrat.

Personnellement, je supprimerais donc la relation entre les tables T_CONCESSION_CODE_CCD et TJ_DEP_JSB_JDJ mais j'ai peur d'aller un peu vite en besogne.

Effectivement, il ne faut pas se précipiter mais d’abord examiner les conséquences de cette suppression...

Par le biais de cette relation le code démo CD1 détermine par exemple la marque en rayon M1. Si on supprime la relation, alors il faut effectivement en passer par les contrats, mais si à une date DT1, le code démo CD1 détermine le contrat C1, lequel détermine la marque en rayon M1, a priori rien n’empêche qu’à la date DT2 (une fois C1 clos) le code démo CD1 détermine le contrat C2, lequel comme par hasard détermine la marque en rayon M2. On a donc une infraction par rapport à la règle selon laquelle le code démo CD1 détermine une marque en rayon et une seule.

Essayons autre chose. Le dernier MCD que vous envisagez est le suivant :




Remarque préalable : vu les cardinalités, vous avez établi une bijection entre les tables CONTRAT et CTR_CLOSED. Comme il y a quand même des contrats qui ne sont pas clos, il faudrait remplacer la bijection par une injection (à moins bien sûr de connaître à l’avance la date de clôture des contrats) :




Rétablissons maintenant le lien entre TJ_DEP_JSB_JDJ et T_CONCESSION_CODE_CDD (cf. votre version -1) :




Un point de détail : si la cardinalité 1..* portée par le lien branchant TJ_DEP_JSB_JDJ et T_CONTRAT_CTR est pertinente, comme on atteint au moins une occurrence de T_CONCESSION_CODE_CDD en passant par ce chemin puis par le chemin menant de T_CONTRAT_CTR à T_CONCESSION_CODE_CDD, alors la cardinalité 0..* portée par le lien branchant TJ_DEP_JSB_JDJ et T_CONCESSION_CODE_CDD devrait être 1..* lui aussi. A l’inverse, si c’est la cardinalité 0..* portée par le lien branchant TJ_DEP_JSB_JDJ et T_CONCESSION_CODE_CDD qui est pertinente, alors le lien branchant TJ_DEP_JSB_JDJ et T_CONTRAT_CTR doit être porteur d’une cardinalité 0..*.

A ce stade, permettez-moi d’utiliser des noms de tables et d’attributs avec lesquels je m’embrouille moins...





Incidemment, je suppose que l’utilisateur gère sa propre numérotation des contrats, d’où l’attribut correspondant CtrNumero qui fait évidemment l’objet d’une clé candidate (mise en évidence par le symbole de clé bleu, ajouté manuellement).

Comme vous l’avez remarqué vous aussi, il y a une redondance inter-tables mal venue : le triplet {MarqueId, FourId, RayonId} est présent à la fois dans les tables CONCESSION et CONTRAT, et il faudrait évacuer cette redondance. Avant cela, je relève une règle dont vous avez fait mention mais qui n'a pas été modélisée :

RG314 — A une date donnée, un code démo (concession) est attribué à un seul contrat.

On peut tenir compte de cette règle en mettant en œuvre une table ad-hoc, appelons-la CONCESSION_DATE :




Selon la table CONCESSION_DATE, le singleton {CtrId} est clé primaire (à un contrat n’est attribué qu’un seul code démo) et la paire {CodeDemo, DateAttribution) est clé alternative (mise en évidence par les symboles de clés rouges, ajoutés manuellement) : la règle RG314 est donc prise en compte.

Il faut observer qu’il existe les dépendances fonctionnelles :

CONTRAT -> CONCESSION_DATE -> CONCESSION -> MARQUE_EN_RAYON

Permettant de retrouver transitivement la marque pour un contrat, faisant que le lien établi ci-dessus entre CONTRAT et MARQUE_EN_RAYON est redondant et doit disparaître, en conséquence de quoi le diagramme devient :




Diagramme qui peut se simplifier ainsi du fait de la bijection entre CONTRAT et CONCESSION_DATE :






Cette approche vous convient-elle ? Quelles conséquences pour votre collègue ? (En tout cas, voilà ce que c’est que de partir en vacances...)


N.B. Un code démo D1 ne peut être attribué à un contrat C2 que s'il n'existe pas un autre contrat C1 auquel l'attribution de D1 est en cours, il faudra donc prévoir un trigger pour éviter les collisions.

[Kropernic]

Hello Krop,
Effectivement, il ne faut pas se précipiter mais d’abord examiner les conséquences de cette suppression...

Par le biais de cette relation le code démo CD1 détermine par exemple la marque en rayon M1. Si on supprime la relation, alors il faut effectivement en passer par les contrats, mais si à une date DT1, le code démo CD1 détermine le contrat C1, lequel détermine la marque en rayon M1, a priori rien n’empêche qu’à la date DT2 (une fois C1 clos) le code démo CD1 détermine le contrat C2, lequel comme par hasard détermine la marque en rayon M2. On a donc une infraction par rapport à la règle selon laquelle le code démo CD1 détermine une marque en rayon et une seule.

Mea culpa. Mea maxima culpa !

J'ai oublié de précisé que cette règle avait été précisée.

La règle disant que "un code démo CD1 détermine une marque en rayon et une seule" devient "à une date D1, un code démo CD1 détermine une marque en rayon et une seule".

Peut-être cela vous aurait peut-être donné moins de "travail". Cependant, vos messages étant toujours plein d'enseignement, je me félicite égoïstement d'avoir omis ce détail.

Essayons autre chose. Le dernier MCD que vous envisagez est le suivant :




Remarque préalable : vu les cardinalités, vous avez établi une bijection entre les tables CONTRAT et CTR_CLOSED. Comme il y a quand même des contrats qui ne sont pas clos, il faudrait remplacer la bijection par une injection (à moins bien sûr de connaître à l’avance la date de clôture des contrats) :

J'avoue avoir fait le MLD un peu à la va vite histoire de me représenter le bazar et ne pas avoir prêter attention aux cardinalités. Les cardinalités entre les contrats et les codes démos sont fausses également. La patte côté code démo devrait porter la cardinalité 0..1. J'étais décidément très fatigué hier (et je le suis encore en fait).

Rétablissons maintenant le lien entre TJ_DEP_JSB_JDJ et T_CONCESSION_CODE_CDD (cf. votre version -1) :




Un point de détail : si la cardinalité 1..* portée par le lien branchant TJ_DEP_JSB_JDJ et T_CONTRAT_CTR est pertinente, comme on atteint au moins une occurrence de T_CONCESSION_CODE_CDD en passant par ce chemin puis par le chemin menant de T_CONTRAT_CTR à T_CONCESSION_CODE_CDD, alors la cardinalité 0..* portée par le lien branchant TJ_DEP_JSB_JDJ et T_CONCESSION_CODE_CDD devrait être 1..* lui aussi. A l’inverse, si c’est la cardinalité 0..* portée par le lien branchant TJ_DEP_JSB_JDJ et T_CONCESSION_CODE_CDD qui est pertinente, alors le lien branchant TJ_DEP_JSB_JDJ et T_CONTRAT_CTR doit être porteur d’une cardinalité 0..*.

Même remarque et vous avez parfaitement raison.

A ce stade, permettez-moi d’utiliser des noms de tables et d’attributs avec lesquels je m’embrouille moins...





Incidemment, je suppose que l’utilisateur gère sa propre numérotation des contrats, d’où l’attribut correspondant CtrNumero qui fait évidemment l’objet d’une clé candidate (mise en évidence par le symbole de clé bleu, ajouté manuellement).

Sur ce point, je dois encore vérifier si les contrats ont une numérotation suivant une nomenclature spécifique. Si oui, la colonne CTR_CODE viendra s'ajouter à la table en tant que clef candidate, si non, j'utiliserais alors (si j'avais a développé l'application gérant les contrats) la colonne CTR_ID comme identifiant du contrat pour l'utilisateur également. Un numéro de contrat, tout comme une clef primaire, se doit de ne jamais changer. Il n'y a donc pas péril en la demeure. Et si d'aventures demain une huile décidait d'introduire une nomenclature spécifique l'ajout de la colonne CTR_CODE viendrait régler le problème avec soit, une valeur par défaut pour les contrats antérieur où un lot de requête approprié si cette nomenclature peut être déterminé pour les contrats antérieurs.

Je fais de même pour les dossiers de mes gifts et tout se passe à merveille.
Cela a d'ailleurs permis que l'utilisateur détecte de lui même un problème car un numéro de dossier avait "disparu". Il s'agissait en fait d'un problème de jointure dans une procédure stockée qui n'aurait probablement jamais été détecté si les dossiers avaient des numéros codifiés.

Comme vous l’avez remarqué vous aussi, il y a une redondance inter-tables mal venue : le triplet {MarqueId, FourId, RayonId} est présent à la fois dans les tables CONCESSION et CONTRAT, et il faudrait évacuer cette redondance. Avant cela, je relève une règle dont vous avez fait mention mais qui n'a pas été modélisée :

RG314 — A une date donnée, un code démo (concession) est attribué à un seul contrat.

Ah, j'avais donc apparemment déjà précisé cela. Je ne m'en souvenais plus (et je ne la retrouve pas dans mes messages précédents en ayant cherché en diagonale). Quoi qu'il en soit, la date réelle d'attribution importe peu. Ce qui compte, ce sont les dates de début et de fin de contrat.

On peut tenir compte de cette règle en mettant en œuvre une table ad-hoc, appelons-la CONCESSION_DATE :




Selon la table CONCESSION_DATE, le singleton {CtrId} est clé primaire (à un contrat n’est attribué qu’un seul code démo) et la paire {CodeDemo, DateAttribution) est clé alternative (mise en évidence par les symboles de clés rouges, ajoutés manuellement) : la règle RG314 est donc prise en compte.

Il faut observer qu’il existe les dépendances fonctionnelles :

CONTRAT -> CONCESSION_DATE -> CONCESSION -> MARQUE_EN_RAYON

Permettant de retrouver transitivement la marque pour un contrat, faisant que le lien établi ci-dessus entre CONTRAT et MARQUE_EN_RAYON est redondant et doit disparaître, en conséquence de quoi le diagramme devient :




Diagramme qui peut se simplifier ainsi du fait de la bijection entre CONTRAT et CONCESSION_DATE :



Cette approche vous convient-elle ? Quelles conséquences pour votre collègue ? (En tout cas, voilà ce que c’est que de partir en vacances...)

N.B. Un code démo D1 ne peut être attribué à un contrat C2 que s'il n'existe pas un autre contrat C1 auquel l'attribution de D1 est en cours, il faudra donc prévoir un trigger pour éviter les collisions.

A peu de chose près, on en revient donc ce que j'avais proposé. Et là, je me rends compte d'un autre oubli de ma part (décidément !).

S'il y a des contrats démos, il y a aussi des contrats fermes. Contrat qui ne sont pas modélisé pour l'instant car aucun développement n'est prévu pour ceux-là tellement ils sont anecdotiques. Néanmoins, j'avais prévu le coup en faisant hérité l'entité Concession_Code de l'entité Contrat pour le jour où il faudra modéliser les contrats.
Intégrer la colonne CodeDemoId dans la table CONTRAT suppose qu'il n'y a que des contrats démo mais vous ignoriez qu'il en était autrement.

Un code démo peut faire l'objet de plusieurs contrats (Car le fournisseur où le rayon pourrait changer. Normalement la marque non mais j'ai bien vu hier en posant mes questions que si on insiste un peu, on peut y arriver).

Toutes vos remarques ayant attiré mon attention sur des points importants et m'ayant fait y réfléchir à nouveau, je persiste dans ma modélisation.

J'espère que mes compléments d'informations vous feront pencher dans mon sens.