Discussion :

[Kropernic]

Bonjour à tous,

Après les gifts qui m'(nous) ont occupé il y a quelques mois, voici un nouveau projet nommé "Anti Mali".

Je n'ai pas encore de MCD à faire valider (à vrai dire j'en suis encore à établir les règles de gestion) mais j'ai déjà une question alors j'ouvre cette discussion histoire de centraliser les choses.

Mais avant tout, histoire qu'on parle bien de la même chose, voici le contexte dans lequel s'intègre ce projet.

Il s'agit de répertorier à quel endroit (zone) du magasin des étiquettes ou antivols sont retrouvés pour pouvoir définir les endroits qui nécessitent qu'on y renforce la surveillance afin de limiter le risque de vols.
Il s'agit de répertorier également les articles qui sont restitués lorsqu'un voleur se fait attraper par un garde à une sortie du magasin.

Voilà pour le gros du fonctionnel. Reste encore la notion de code démo (démo pour démonstration) à définir ainsi que celle de segment.

Code démo:
Nos magasins utilisent le système de "shops in the shop". C'est-à-dire que nous louons des espaces à des fournisseurs et ils y vendent leurs articles sur lesquels nous prenons une marge. Nous appelons ces articles des "articles démo". Démo pour démonstration. Chaque article (sans tenir compte des différences de taille ou de couleur) est identifié par un code démo. Et bien sûr, comme dans tous magasins, ces articles appartiennent à un rayon (homme, femme, enfant, lingerie, etc.).
Segment:
Un segment est en fait une partie de rayon. Par exemple, le rayon femme comprend les segments chemise, jupe, pantalon, etc.

J'ai donc les règles de gestion 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.

La question :
La règle 5 comme telle, si j'ai bien intégré ce que j'ai appris au fil de mes lectures du forum, donnerait une association ternaire.
N'y a-t-il pas moyen de décomposé cette dernière en deux association binaire ?

J'apporterai bientôt un premier MCD histoire d'y voir plus clair.

EDIT : Correction de la règle 3°

[Kropernic]

Comme promis, voici un premier MCD de ce que j'ai présenté dans mon premier message.

Deux règles de gestion viennent déjà s'ajouter. La liste complète est donc :
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.

Vont encore venir s'ajouter les entités-types nécessaires (et les règles de gestions qui vont avec) pour la gestion des vols, restitution, sortie.

En attendant, je cherche donc à "simplifier" l'association ternaire DETERMINER.

[fsmrel]

Bonsoir Kropernic,


Je constate que vous ne restez pas inactif !

Je cherche donc à "simplifier" l'association ternaire DETERMINER.

L’association ternaire DETERMINER (RM dans le MCD ci-dessous) revient en fait à deux binaires, CM et CR :



Dans les deux cas, un code démo peut déterminer un rayon qui n’est pas associé à la marque du code démo, et bien sûr, vous vous demandez comment faire pour éviter cela.

On peut mettre en œuvre une contrainte d’inclusion (le graphisme ci-dessous est sans garantie, il s’agit surtout d’un mickey pour attirer l’attention) synthétisant la contrainte :

(CK1) Le code démo C ne peut figurer dans le rayon R que si la marque M déterminée par C figure elle aussi dans R.

Représentation graphique :




Plutôt que galérer avec les contraintes d’inclusion, on peut préférer transformer l’association RM en entité-type identifiée relativement à RAYON et MARQUE, et y connecter CODE_DEMO, tout en débranchant MARQUE et CODE_DEMO :




Je rappelle que, dans le cas de PowerAMC que j’utilise ici, l’identification relative fait l’objet de la mise entre parenthèses des cardinalités 1,1.


Le MLD produit par l’AGL est le suivant :



La contrainte (CK1) est bien respectée.

[Kropernic]

Bonsoir Kropernic,


Je constate que vous ne restez pas inactif !

Héhé, bien sûr que non ! Et j'espérais bien attirer votre attention

L’association ternaire DETERMINER (RM dans le MCD ci-dessous) revient en fait à deux binaires, CM et CR :



Dans les deux cas, un code démo peut déterminer un rayon qui n’est pas associé à la marque du code démo, et bien sûr, vous vous demandez comment faire pour éviter cela.

C'est exactement cela. En MLD (ou MPD ?) je vois plus ou moins comment procéder. En partant du MCD que j'ai posté, l'association entre rayon et marque donnera un table intermédiaire dont la clef primaire sera composée des clefs primaires des tables rayon et marque qui servira de clef étrangère pour la table code démo. Par contre, je galère vraiment à représenter cela au mcd. Et j'imagine que le fait que je n'arrive pas à conceptualiser cela convenablement révèle soit un manque de maitrise du concept, soit un manque de maitrise de la théorie relationnelle. Bref, j'ai encore du boulot

On peut mettre en œuvre une contrainte d’inclusion (le graphisme ci-dessous est sans garantie, il s’agit surtout d’un mickey pour attirer l’attention) synthétisant la contrainte :

(CK1) Le code démo C ne peut figurer dans le rayon R que si la marque M déterminée par C figure elle aussi dans R.

Représentation graphique :




Plutôt que galérer avec les contraintes d’inclusion, on peut préférer transformer l’association RM en entité-type identifiée relativement à RAYON et MARQUE, et y connecter CODE_DEMO, tout en débranchant MARQUE et CODE_DEMO :




Je rappelle que, dans le cas de PowerAMC que j’utilise ici, l’identification relative fait l’objet de la mise entre parenthèses des cardinalités 1,1.

Ce qui revient exactement à la solution que j'ai expliquée dans mon commentaire précédent . A défaut de PowerAMC (car pas encore de licence définitive et que ma licence d'essai à depuis longtemps expirée ), je teste donc JMerise. Qui jusqu'ici semble pas trop mal foutu et qui permet les liens relatifs. J'appliquerai donc la solution que vous proposez.

Le MLD produit par l’AGL est le suivant :



La contrainte (CK1) est bien respectée.

Et on arrive bien à un modèle logique tel que celui que j'ai décrit plus haut. J'ai donc encore du boulot mais c'est sur la bonne voie .

Merci pour votre intervention .

N.B. : Les deux jours qui viennent, je serai "malheureusement" (la formation est une bonne chose mais le projet va stagner pendant ce temps) en formation pour un nouvel outil permettant de générer des rapports nécessaires au magasin à partir des données de ventes. Je ne pourrai donc probablement plus donner de nouvelles de l'avancement avant vendredi.

[fsmrel]

Voici quelques éléments de réflexion pour meubler les moments de pause à l’occasion de votre formation...

En MLD (ou MPD ?) je vois plus ou moins comment procéder. En partant du MCD que j'ai posté, l'association entre rayon et marque donnera un table intermédiaire dont la clef primaire sera composée des clefs primaires des tables rayon et marque qui servira de clef étrangère pour la table code démo.
[...]
Ce qui revient exactement à la solution que j'ai expliquée dans mon commentaire précédent .

Hum... Utilisons par exemple PowerAMC (Why not? ). Pour reprendre votre MCD :




Voici le MLD produit par PowerAMC :



Pour PowerAMC, la clé de la table DETERMINER est le triplet {CodeDemoId, RayonId, MarqueId}, ce qui prouve en passant que le géniteur de l’AGL a oublié que la cardinalité maximale portée par la patte connectant l’entité-type CODE_DEMO et l’association DETERMINER n’est pas N mais 1. Il aurait dû prendre en compte les dépendances fonctionnelles qui sont les conséquences logiques de cette cardinalité maximale 1 :

{CodeDemoId} -> {RayonId},
{CodeDemoId} -> {MarqueId}.

D’où le MLD corrigé manuellement :




Mais de toute façon, ce MLD n’est pas satisfaisant, une fois ! En effet la paire {RayonId, MarqueId} de la table DETERMINER doit faire référence à la paire {RayonId, MarqueId} de la table ETRE_ASSOCIE, sinon la contrainte CK1 dont j’ai fait mention dans mon message précédent n’est pas garantie. Je rappelle que pour que la contrainte soit respectée, le MLD doit être le suivant (où RM est synonyme de ETRE_ASSOCIE) :




Je ne sais pas ce que JMerise vous produira comme MLD, mais de toute façon, la présence simultanée des deux tables DETERMINER et ETRE_ASSOCIE sans que la 1re fasse référence à la 2e fera que la contrainte CK1 ne pourra pas être garantie, même si, comme vous le conjecturez, la clé primaire de la table DETERMINER était la paire {RayonId, MarqueId}.


Pour le fun

La solution que je propose n’est pas forcément optimale même si elle garantit la contrainte CK1. En effet, conformément à votre MCD, j’ai bien respecté la cardinalité minimale 1 qui est portée par la patte connectant l’entité-type CODE_DEMO et l’association DETERMINER, mais quid si cette cardinalité minimale est 0 ? Pas de panique : la solution n’est pas bien compliquée, vous l’avez déjà mise en œuvre par le passé. Par exemple, on utilise la spécialisation (pour éviter une intervention manuelle dans le MLD, du moins avec PowerAMC) :



MLD :



Au stade SQL, il faudra quand même prévoir une assertion (un trigger à défaut) pour garantir la contrainte d’exclusion : un code démo ne peut pas être à la fois en rayon et pas en rayon...

Bon stage et à bientôt

[Kropernic]

Allez hop, un petit message en attendant mon taxi (je fais du co-voiturage avec mon chef jusqu'à Cologne^^)

Je ne comprends pas la signification de vos entités CODE_DEMO_EN_RAYON et CODE_DEMO_PAS_EN_RAYON.

Un code démo est en fait un code attribué pour identifier un type de marchandise d'un fournisseur dans une marque.

Si par exemple un fournisseur fourni des pantalons dans deux marques M1 et M2 différentes, il aura alors un code démo pour chacune, respectivement C1 et C2. Si à coté de ça, il fournit aussi des chaussettes de la marque M1, il aura alors un code démo C3. Le rayon ici est déterminé par le type de marchandise. Il est évident que les pantalons n'ont pas la même rayon que les chaussettes.
N.B. : Il est à noté que rayon est à prendre au sens informatif (logique) et non pas dans le sens rayon concret sur la surface de vente. A priori, rien n'empêcherait (même si ce n'est pas le cas), que des chaussettes soient vendu à côté de pantalons sur le même rayon physique. (Tiens, on retrouve la séparation entre le logique et le physique, c'est amusant)

Du coup, un code démo déterminera TOUJOURS un rayon et une marque. D'où mon incompréhension.

[fsmrel]

Bonsoir Kropernic,


Et hop, une petite réponse pour le retour de Cologne ^^

un code démo déterminera TOUJOURS un rayon et une marque.

D’accord, donc j’ en resterai à ma 1re proposition :



Cela dit, la 2e proposition correspondait au cas où au lieu de 1,1 on aurait 0,1 dans le MCD. Il s’agit d’une situation que tout le monde peut rencontrer au cours d’un travail de modélisation. Je suggère qu’en ce cas on produise un MLD du genre de celui que j’ai proposé en dernier, histoire de ne pas se faire braquer au tournant par le bonhomme Null...

Bon séjour !

[Kropernic]

Bonsoir Kropernic,


Et hop, une petite réponse pour le retour de Cologne ^^


D’accord, donc j’ en resterai à ma 1re proposition :



Cela dit, la 2e proposition correspondait au cas où au lieu de 1,1 on aurait 0,1 dans le MCD. Il s’agit d’une situation que tout le monde peut rencontrer au cours d’un travail de modélisation. Je suggère qu’en ce cas on produise un MLD du genre de celui que j’ai proposé en dernier, histoire de ne pas se faire braquer au tournant par le bonhomme Null...

Bon séjour !

Avec une vue par dessus histoire de "simplifier" les choses pour la personne qui devra accéder à tout cela j'imagine.

Sinon, j'ai continué le MCD mais JMerise semble montré ses limites. Certaines options de configuration ne sont pas prises en compte et une entité sans clef primaire n'est pas autorisée (celle qui serait identifiée relativement à rayon et marque). Du coup, je suis un peu bloqué au niveau modélisation informatique. Je pourrais toujours ressortir le papier et le crayon mais bon...

[fsmrel]

Encore debout ? ^^


Plutôt que le crayon et le papier, vous pouvez passer à MySQL Workbench, on est directement au niveau MLD, mais ça fonctionne très bien.


Bon courage...

[Kropernic]

EDIT : J'efface mon message car j'ai eu la réponse à mes questions (à force de chippoter^^).

[Kropernic]

Voici donc le MLD produit avec Mysql Workbench (voir pièce jointe).
N.B. :Vu que dans mes DB, je travaille en Anglais, j'ai dessiné le MLD avec les nom des tables et des colonnes en Anglais. Si une chose n'est pas claire, je vous ferai un plaisir de donner la traduction française.

Je reprends la liste des règles de gestions :
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.

Une 8e règle devrait venir se rajouter concernant les restitutions pour savoir de quoi il s'agit (je dois encore poser quelques questions).


En attendant, détectez-vous des incohérences dans le MLD ainsi présenté ?

[fsmrel]

Bonsoir Kropernic,


Pour la partie qu’on a travaillée (rayon / marque /code démo), c’est conforme (je ne préjuge pas de ce qu’il y a sous le capot, à savoir les index qui relèvent du MPD).

Sinon, j’observe qu’il y a peu de cardinalités minimales à 0 dans le modèle :

Par exemple, vous écrivez :

4° Un rayon peut être composé de plusieurs segments et un segment compose un rayon.

En conséquence de quoi la cardinalité portée par la patte connectant RAYON et SEGMENT devrait être 0,N plutôt que 1,N, ou à l’inverse la règle devrait être formulée par exemple ainsi :

Un rayon est composé d’au moins un segment...

Avez-vous prévu des clés alternatives pour les attributs tels que CCD_CODE, SEG_CODE (que je soupçonne d’être des clés alternatives à l’usage de l’utilisateur) ?

[Kropernic]

Bonsoir Kropernic,


Pour la partie qu’on a travaillée (rayon / marque /code démo), c’est conforme (je ne préjuge pas de ce qu’il y a sous le capot, à savoir les index qui relèvent du MPD).

Sinon, j’observe qu’il y a peu de cardinalités minimales à 0 dans le modèle :

Par exemple, vous écrivez :


En conséquence de quoi la cardinalité portée par la patte connectant RAYON et SEGMENT devrait être 0,N plutôt que 1,N, ou à l’inverse la règle devrait être formulée par exemple ainsi :

Un rayon est composé d’au moins un segment...

J'avoue avoir pris les composants dans la boîte à outils et les avoir "fourré" dans le diagramme. Je n'ai pas encore regarder comment changer une cardinalité 1 en 0.

Avez-vous prévu des clés alternatives pour les attributs tels que CCD_CODE, SEG_CODE (que je soupçonne d’être des clés alternatives à l’usage de l’utilisateur) ?

J'ai bien défini ces colonnes comme étant unique (ce qui donne un index unique derrière) mais cela ne se voit pas sur le diagramme. Y a-t-il quelque chose à faire pour le montrer ?

EDIT : Je suis en train d'éditer une relation entre deux tables et je ne vois pas comment mettre une cardinalité à 0. Les seuls cardinalités proposées sont 1 à 1 et 1 à plusieurs...
EDIT 2 (le retour) : Dans les propriétés de la relation (pas dans la boite d'édition), il y a la propriété "mandatory" que je peux mettre à 0 et cela ajoute un petit rond devant le "pied de poule". Est-ce cela ? (dire que je m'étais à peine habituer aux notations merises, voilà qu'il faut que je change)
EDIT 3 : En passant les relations en notation UML, cela devient beaucoup plus évident (car il y a des nombres à la place de symboles) et c'était bien la propriété mandatory à éditer. J'ai bien maintenant une cardinalité 1 - 0,N

[Kropernic]

Voici donc une mise à jour du MLD avec les cardinalités à 0.

Je me pose quand même une question pour la règle 3°. D'un point de vue logique, il ne me semble pas inconcevable d'avoir un rayon sans marque. On peut très bien imaginer qu'un nouveau rayon soit inventé mais qu'on n'ait pas encore de contrat avec des fournisseurs concernant les marques destinées à ce rayon. Là où je doute, c'est de savoir si c'est bien à ma DB de rendre compte de cela.

[fsmrel]

Vous allez un peu trop vite pour moi... J’étais en train de préparer une réponse, que je vous livre en l’état, et qui pourra servir de pense-bête aux forumeurs... ^^

Comment transformer une cardinalité 1,N en 0,N.

Prenons l’exemple des commandes d'articles : les articles n’ont pas forcément tous fait l’objet d’une commande. Double Cliquer sur le lien connectant ARTICLE et LIGNE_COMMANDE :



Une fois ouverte la fenêtre qui va bien :

Onglet « Foreign Key » : décocher la (bonne) case « Mandatory » (celle de gauche) :



Cas des clés alternatives

Par le truchement d’une infobulle, donc de façon fugace, on peut savoir à la volée si on a défini des clés alternatives et quelle en est la composition. Exemple (en France) du Siret des clients :



Par le truchement de l’onglet « Indexes » associé à la table : une clé alternative {ClientNoSiret} peut être mise en œuvre au moyen d’un index « UNIQUE » :



C’est moyen comme méthode, car un index est un objet du niveau MPD, mais bon, quand on n’utilise pas MySQL, histoire de regrimper au niveau MLD, dans le code SQL généré on remplacera la ligne :

UNIQUE INDEX `CLIENT_SIRET` (`ClientNoSiret` ASC) )

Par celle-ci :

CONSTRAINT CLIENT_SIRET_AK UNIQUE (ClientNoSiret)

Dans le cas des clés singletons telles que le Siret ou le numéro des commandes, on peut aussi cocheer la case UQ (onglet « Columns ») :



Je vais regarder vos derniers messages.

[fsmrel]

EDIT 2 (le retour) : Dans les propriétés de la relation (pas dans la boite d'édition), il y a la propriété "mandatory" que je peux mettre à 0 et cela ajoute un petit rond devant le "pied de poule". Est-ce cela ? (dire que je m'étais à peine habituer aux notations merises, voilà qu'il faut que je change)
EDIT 3 : En passant les relations en notation UML, cela devient beaucoup plus évident (car il y a des nombres à la place de symboles) et c'était bien la propriété mandatory à éditer. J'ai bien maintenant une cardinalité 1 - 0,N

Effectivement, vous avez d’autres possibilités de représentation.

A l’attention des forumeurs de passage : la notation utilisée par défaut pour les cardinalités est celle d’IE (Information Engineering), dite encore « patte d’oie » ou « patte de corbeau » (Crow’s foot). On peut préférer la notation UML :




Ou d’autres notations ! Par exemple, pour les habitués de Microsoft Access :



Etc.

[fsmrel]

D'un point de vue logique, il ne me semble pas inconcevable d'avoir un rayon sans marque. On peut très bien imaginer qu'un nouveau rayon soit inventé mais qu'on n'ait pas encore de contrat avec des fournisseurs concernant les marques destinées à ce rayon. Là où je doute, c'est de savoir si c'est bien à ma DB de rendre compte de cela.

Au niveau conceptuel, c’est tout le problème de la modélisation de la finalité. Autant il est certain qu’une facture est composée d’au moins une ligne, autant dans le cas des rayons c’est à débattre avec l’utilisateur : si pour lui, un rayon sans marque ça n’a pas de sens, vous utiliserez la cardinalité minimale 1. Maintenant, au niveau de la base de données on ne veut en aucun cas se retrouver avec des factures sans lignes, on mettra donc en oeuvre tous les moyens pour s’assurer de la présence d’une ligne (voire de l’ensemble des lignes tant qu’à faire) au moment de la création d’une facture. Dans le cas des rayons, si vous savez qu’on peut se retrouver avec des rayons sans marques en face, vous laissez filer, même s'il y a distorsion entre l'idéal (le conceptuel) et la réalité.

[Kropernic]

Bon, le projet est en attente d'une réunion (enfin plutot que la personne compétente pour répondre à mes questions reviennent de congé) pour pouvoir continuer. Du coup, ça a en reste là pour le moment.

Par contre, je me pose une question concernant l'entité type Zone (table T_AREA_ARE). Une zone est localisé sur un plan d'étage dont l'adresse de l'image se trouve dans l'entité type Etage. J'ai donc les coordonnées de la zone. Là où je m'interroge, c'est que la taille du plan variera en fonction de la résolution de l'écran de l'utilisateur... Du coup, les coordonnées de la zone devraient varier aussi.

Comment rendre compte de cela ? Est-ce un problème purement lié à l'applicatif ou bien faut-il en tenir compte déjà dans le MCD ?

Une solution qui me vient serait de stocker les coordonnées en pourcentage (ex : si la zone est pile au milieu du plan, ses coordonnées seraient 50 pour l’abscisse et 50 pour l'ordonnée) mais j'ai l'intuition que c'est bancale comme solution...

[Kropernic]

En attendant d'avoir des réponses à mes questions pour continuer, j'ai remis le MLD en page car j'aime bien avoir des lignes sans zig ni zag.

Et là, en contemplant ce MLD, une interrogation m'est venue :
Concernant les liens entre la table TJ_BRA_DEP_JBD et les tables T_BRAND_BRA et T_DEPARTMENT_DEP, pourquoi sont-ce des liens identifiants ? Vu ce que j'en fait, des liens non-identifiants seraient suffisants il me semble.

D'instinct, et commençant à connaître les astuces de fsmrel, ne serait-ce pas là un reste d'une association du MCD qu'on aurait "travesti" en entité pour une histoire de contrainte ?

...*vérification des messages précédents*...

Il semblerait bien que ce soit cela. Mais quand je regarde le MLD, je ne vois pas l'utilité ces liens identifiants.

Ai-je raté quelque chose ?

EDIT :

Je pense avoir trouvé une coquille...
Actuellement, il y a les règles de gestions

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.

J'ai de plus en plus l'impression que ceci n'est pas correct... Je vais devoir poser les questions adéquates mais pense qu'en fait, il faut garder la règle 6 mais que la 3 et la 7 ne sont pas 100% exacte.

En l'état, pour une marque dans un rayon, je ne peux déterminer quel est le fournisseur. Au mieux, je pourrai le restreindre à une liste de fournisseurs possibles. En conséquent, je pense que le MLD devrait être modifier comme suit avec les règles de gestion qui vont avec mais j'ai du mal à trouver des verbes qui vont bien (voir pièce jointe MLD_BIS.PNG).

Mais il ne s'agit encore que d'une intuition. Va falloir que je creuse et tire les vers du nez de certaines personnes. Cela étant, j'aimerais avoir votre avis là-dessus.

P.S.:Lors de l'édition de relation, il semble que MWB ne propage pas les nouvelles clefs étrangères. Je m'y prends mal ou bien c'est un défaut de l'applicatif ? (enfin, il est gratuit, on ne va pas trop se plaindre)

[fsmrel]

Bonsoir Krop,

Concernant les liens entre la table TJ_BRA_DEP_JBD et les tables T_BRAND_BRA et T_DEPARTMENT_DEP, pourquoi sont-ce des liens identifiants ?
[...]
Ai-je raté quelque chose ?

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.

Cela étant, j'aimerais avoir votre avis là-dessus.

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

Je m'y prends mal ou bien c'est un défaut de l'applicatif ?

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