Discussion :

[MacFly58]

Bonjour,

si dans le cas de la ligne de facture je considère celle-ci plutôt comme une entité faible, ça ne me gêne pas que mon voisin la considère comme une entité associative.

Je termine la phrase de FsmRel en apportant une petite précision qui sera peut être utile pour certains.

"ça ne me gêne pas que mon voisin la considère comme une entité associative dans le MCD, car notre schéma relationnel (le MLD) sera identique, tout comme la sémantique de nos MCD."

[fsmrel]

Bonsoir,

Je termine la phrase de FsmRel en apportant une petite précision qui sera peut être utile pour certains.
"ça ne me gêne pas que mon voisin la considère comme une entité associative dans le MCD, car notre schéma relationnel (le MLD) sera identique, tout comme la sémantique de nos MCD."

Valeureux MacFly, permettez-moi d’apporter une nuance.

Au préalable, voici une anecdote concernant le grand lexicographe Emile Littré. Je cite Claude Gagnière (Pour tout l’or des mots, collection Bouquins, Editions Robert Laffont) :

« Un jour, madame Littré ouvre par hasard la porte d'une chambre et découvre son mari couché avec la bonne :
— Oh ! Comme je suis surprise ! s'écrie-t-elle.
— Erreur, madame ! Vous êtes étonnée, c'est nous qui sommes surpris ! »

Nuance !


Si votre propos est de signifier que quel que soit le MCD (association entre entités-types ou identification relative) le MLD sera le même, il faut nuancer, apporter une précision. En effet, la composition des en-têtes des tables issues de la dérivation, ainsi que la composition de leurs clés ne sont pas exactement les mêmes.


Exemple

1) MCD avec association (Power AMC V11) :



2) MLD correspondant :


Il est évident que dans le cadre d’une rétro-conception, partant du MLD, Power AMC reproduit exactement le MCD initial.


3) MCD avec identification relative (LOT_TIERS est entité-type faible relativement à MODELE) :


4) MLD correspondant :



Là encore, dans le cadre d’une rétro-conception, partant du MLD, Power AMC reproduit exactement le MCD dont il est issu (à ceci près que si l'on définit la clé alternative {ModeleId, LotId, TiersId}, la rétro-conception du MLD en MCD donne n'importe quoi, mais l'AGL est par construction dépassé...)


Cela dit, si l'on zoome dans les structures, le schéma relationnel (MLD) — donc la sémantique qu’il porte — n’est pas strictement le même selon qu’il traduit une dépendance entre entité-type forte et entité-type faible ou bien une relation classique du MCD.

Pour reprendre le schéma créé avec MySQL Workbench, il est bien de type relationnel et non pas conceptuel au sens classique du terme, puisque par exemple les attributs composant les clés étrangères figurent explicitement dans LOT_TIERS (qui est ici une table) :



A nouveau, par rétro-conception, LOT_TIERS ferait l’objet soit d’une association-type soit d’une entité-type (faible).

Je répète donc que, quel que soit le choix du concepteur pour qualifier LOT_TIERS (MCD avec association-type ou entité-type faible), la différence au niveau MLD n’est pas très sensible (tout devient table), mais elle existe quand même. Drake a préféré l’approche entité-type faible, mais en contrepartie, pour que l’intégrité des données soit respectée, il devra mettre en œuvre une clé alternative pour le triplet {ModeleId, LotId, TiersId} (cf. les trois petites clés bleues dans le diagramme).


Histoire vécue (que j’ai déjà racontée une fois ou deux chez DVP) :

Je me souviens des soucis qu’avait un concepteur dans une banque. Celui-ci avait modélisé une opération sur titre sous forme d’association-type entre un titre, un trader, un broker, une place cotation, etc. Tout allait bien, mais patatras ! l’utilisateur s’était piqué de connaître la modélisation et avait exigé que cette opération fasse l’objet d’une entité-type. J’ai expliqué au concepteur — qui avait très mal dormi à cause de cette histoire... — que le client était roi et qu'en l'occurrence il pouvait se plier à sa vision (après tout légitime) des choses. En effet, que l’opération soit représentée sous forme de carré ou de rond, peu importe car, comme dit MacFly, par dérivation du MCD en MLD, on produit des tables et le résultat est le même, mais c'est à un changement près de la structure de l’en-tête de la table et de la composition de la clé primaire (sans oublier la nécessité de définir une clé alternative eu égard à l’intégrité des données). Au fait, pourquoi l’utilisateur avait-il exigé que l’opération sur titre fasse l’objet d’une entité ? Tout simplement pour des raisons émotionnelles, car à l’époque, les titres furent dématérialisés, les papiers réduits à l’état de confettis ou de cendres, mais l’utilisateur en manque — un peu comme le manchot a mal à son bras manquant — sentait toujours son carnet à souches dans sa poche, et ce carnet n’avait pour lui rien d’une relation...

L'histoire ne dit pas si, à l'instar de M. Littré, le manchot manipule le béton à la tonne...

[MacFly58]

C'est effectivement une grosse nuance, je retire donc mon idée !

... mais je ne manquerai pas de revenir émettre des idées loufoques, qui permettent au moins à une personne de progresser en modélisation

[drakuncorp]

Bonjour a tous,
tres passionnante discussion, FSMEREL j'ai parcouru les liens du post n° 60 http://www.developpez.net/forums/d11...e/#post6475424 qui m'ont beaucoup aider sur l'identification relative.

Pour la table OPER_REPARATION je ne pense pas qu'un tiers procède à un changement d'un matériel de ce type vu que ceci peut être effectué en interne.Quand meme c'est une table qui a sa raison d’être (on la garde) mais
Une ambiguïté se pose sur cette dernière, le MaterielId qui s'y trouve est référencé à quelle table: REPARATION ou COMPOSANT_OPER
ma logique me dit qu'elle provient de RÉPARATION.

Et quand es ce que l'insertion est elle effectué dans cette table ( OPER-RÉPARATION) car la valeur de l'attribut "operseq" doit exister.
Un détail sur cela me serait d'un grand aide.

Et merci à vous

[fsmrel]

Bonsoir Drake,


Je vous cite à nouveau :

C'est le matériel complet qui par chez le tiers.

Donc si le disque dur du DX2000MT identifié dans la table MATERIEL par MaterielId = 'mat1' tombe en panne, c’est bien le tiers qui procède au changement du disque (en l'occurrence m5), vous ne le faites pas en interne. Je ne comprends donc pas ce que vous dites ici :

Pour la table OPER_REPARATION je ne pense pas qu'un tiers procède à un changement d'un matériel de ce type vu que ceci peut être effectué en interne.

J’aimerais donc que vous nommiez le matériel dont vous faites mention. Le mieux serait d’utiliser les noms que j’ai fournis dans mon exemple. En voici une version dans laquelle les traits en rouge indiquent quels attributs sont utilisés pour savoir de quel matériel (ou composant) il s’agit :

Une ambiguïté se pose sur cette dernière, le MaterielId qui s'y trouve est référencé à quelle table: REPARATION ou COMPOSANT_OPER
ma logique me dit qu'elle provient de RÉPARATION

1) La relation entre OPER_REPARATION et COMPOSANT_OPER est identifiante, donc l’attribut MaterielId participe nécessairement à la fois à la clé primaire {MaterielId, OperSeq} de OPER_REPARATION et à la clé étrangère {MaterielId, OperSeq} de OPER_REPARATION (dans sa référence à COMPOSANT_OPER).

2) La relation entre OPER_REPARATION et REPARATION n’est pas identifiante, mais du fait du lien entre ces deux tables, OPER_REPARATION a une clé étrangère {MaterielId, PanneSeq, TiersId} référençant REPARATION.

Conclusion : MaterielId participe aux deux relations. Ainsi, quand il est expédié chez le tiers t1 le matériel mat1 figure dans la table REPARATION (MaterielId = 'mat1', PanneSeq = 1), quand il revient (réparé), comme on sait quel est le composant qui a été changé (ou les composants, ce qui est le cas dans l’exemple, à savoir le remplacement de m5 par m7, et le remplacement de m9), on met à jour la table COMPOSANT_OPER (MaterielId = 'mat1', suppression du composant m5 (OperSeq = 2) et ajout de m7 (OperSeq = 3)), puis la table OPER_REPARATION (MaterielId = 'mat1', OperSeq = 2 et OperSeq = 3, PanneSeq = 1 ; même principe pour m9).


Clés étrangères de la table OPER_REPARATION :

[drakuncorp]

Bonjour,
C'est juste que je me disais qu'on ne vas pas quand même envoyé le DX2000MT chez le réparateur (tiers) sans au moins faire un premier diagnostique.
Si on s’aperçoit que le disque aussi est en panne et qu'on a des disque de récupération sur des machines Hors service, mieux vaut les remplacement et en profiter ainsi pour réduire les dépenses.

[fsmrel]

Bonsoir Drake,

C'est juste que je me disais qu'on ne vas pas quand même envoyé le DX2000MT chez le réparateur (tiers) sans au moins faire un premier diagnostique.
Si on s’aperçoit que le disque aussi est en panne et qu'on a des disque de récupération sur des machines Hors service, mieux vaut les remplacement et en profiter ainsi pour réduire les dépenses.

On est bien d’accord et ceci confirme ce que vous aviez écrit précédemment :

une panne peut se réparer en interne ou peut ètre envoyé chez un TIERS pour réparation.

Si donc le matériel mat45 tombe panne, vous le signalez dans la base de données (table MATERIEL, attribut MaterielId = 'mat45', attribut EtatId = 'panne'), vous notez la date à laquelle la panne a été prise en compte (table PANNE, attribut MaterielId = 'mat45', etc.) Désormais vous avez tout le loisir de faire un diagnostic. Si vous estimez que vous pouvez vous-même effectuer la réparation, à savoir le remplacement du disque dur par un de ceux que vous avez en stock (par exemple, le PC identifié par mat21 est au rebut (EtatId = 'rebut' et est doté du disque qui convient), vous vous contentez de mettre à jour la table COMPOSANT_OPER, tandis que les tables REPARATION et OPER_REPARATION resteront hors du coup.

Le 14 juillet 2011, le matériel mat21 a été mis au rebut (l’UC et la mémoire sont en rideau, et les devis pour réparation sont trop élevés). Ce fait est consigné dan la table PANNE.

Le 30 janvier 2012, le matériel mat45 tombe en panne. Un diagnostic interne montre que c’est le disque dur. Ce disque est d’origine parce que la jointure des tables COMPOSANT_OPER, MODELE_MONO et TYPE_MATERIEL n’a rien qui concerne mat45 en termes de disque dur. La jointure des tables MODELE, MODELE_COMPOSITION et MODELE_MONO montre que le disque dur est un WD Scorpio.

Il s’agit maintenant de rechercher un disque de remplacement. Dans l’état de la structure de la base de données, on sait quels matériels sont susceptibles d’être dépouillés de leur disque dur (table MATERIEL, attribut EtatId = 'rebut') et c’est à vous de rechercher un tel disque en fouillant parmi ces matériels au rebut qui sont à la cave (c’est peut-être l’occasion d’étudier l’opportunité et la faisabilité de la mise en œuvre d’une table des composants disponibles, encore montés sur les PC, ou démontés, scénarios à étudier). Si donc en trifouillant vous avez trouvé un PC au rebut, disons mat21 (on suppose ici que les PC au rebut ne sont pas désossés), et possédant un disque qui va bien (par exemple un Knt80), on le récupère et, bien que ça ne soit pas une nécessité, on met à jour en conséquence la table COMPOSANT_OPER, ça peut toujours servir (MaterielId = 'mat21', ComposantModeleId = 'm5', DateOperation= '2012-01-30', TypeOper = 'suppr').

Ceci fait, on met à jour la table COMPOSANT_OPER en ce qui concerne mat45, en supposant qu’il a été dépanné rapidement : DateOperation = '2012-01-30', remplacement du disque en panne par le disque récupéré.


Etat de la base lors du dépannage interne :



Une fois les opérations terminées et les vérifications effectuées, l'état de mat45 peut repasser à "OK" (table MATERIEL).

Si vous avez des scénarios alternatifs, n'hésitez pas à les proposer (de façon détaillée).

[drakuncorp]

Bonjour, FSMREL
c'est toujours un plaisir de vous lire vu le détails est toujours au rendez-vous dans vos commentaires. Bon bref...

Le scénario de la réparation interne est parfait et mieux je n'avais pas pensé à la table composant disponible(récupéré) car avec la table LOT on peut avoir les composant disponible(neuve) vu qu'on peut commander un lot de barrette ou de disque dur etc .....

Mais vous parlez de devis de réparation trop élevés je ne vois pas comment gérer cela dans ce modèle.

scénario d'intervention externe
En générale si un PC est expédié en réparation, c'est la carte mère qui doit avoir quelques soucis.Le coût de cette réparation risque d'être corsé. Ainsi la réparation sera annulée.Pour dire simplement qu'en générale ce sont soit les imprimantes ou les écran qui sont souvent expédier en réparation.
Sachant cela , la table OPER_REPARATION n'a plus d'utilité.

Dans la table matériel j'ai ajouté un attribut (Verrou) qui a pour but de verrouiller le matériel qui subit une intervention.
C'est à dire lors d'un mouvement (bon d'entrée ou de sortie) le matériel concerné ne doit subir aucun autre mouvement jusqu'à la fin de celle ci.
es ce que cet attribut fera l'affaire ?

une dernière, même si je suis pas la comptabilité , comment pourrai je faire pour avoir les dépenses annuelles du parc ce qui permettra avec des chiffres de défendre les projets concernant le parc pour le budget de l'anne N+1.

Merci à vous et bon week end.

[GauguinLeFelin]

Bonjour,
Puis-je savoir avec quel logiciel avez-vous généré ces diagrammes?

merci D'avance

[drakuncorp]

Bonjour LEFELIN

c'est MYSQL WORKBENCH http://www.mysql.fr/downloads/workbench/

http://www.mysql.fr/downloads/workbench/

Bonne chance

[drakuncorp]

Je remercie tout ceux qui ont à intervenir sur cette discussion en particulier Mr F MREL qui m'a assisté du début jusqu'à la fin.

Merci à tous.