Discussion :

[fsmrel]

Bonsoir Drake,


Merci pour vos vœux, à mon tour je vous souhaite une bonne année 2012 et succès pour vos projets.

les tables MODELE_MONO_CAR et TYPE_MAT_CAR ne font elle pas la même chose ?
Guillaume d’Ockham :
« Pluralitas non est ponenda sine necessitate » (autrement dit, ce qui ne sert à rien : poubelle !)

Les deux tables ont des finalités distinctes.

La table MODELE_MONO_CAR est du type :

TABLE {ModeleId, CaracteristiqueId}

Et la table TYPE_MAT_CAR est du type :

TABLE {TypeMaterielId, CaracteristiqueId}

Ainsi, pour appliquer le rasoir d’Ockham, il faudrait que les modèles et les types de matériels soient assimilables, comparables, ce qui n’est pas le cas. En effet un modèle est personnalisé (DX2000MT, WD Scorpio, etc.) alors qu’un type de matériel est anonyme (imprimante, disque dur, etc.)
Ci-joint une version du diagramme où les valeurs numériques des clés sont remplacées par des valeurs symboliques. On voit bien qu’il y a une différence de niveau de compréhension, c'est-à-dire sémantique, entre les valeurs <m2, c7> (XY2540-A, 17") et <t2, c7> (Ecran, 17") figurant respectivement dans les tables MODELE_MONO_CAR et TYPE_MAT_CAR. Ceci est moins frappant lorsqu’on utilise des valeurs numériques, <2, 7> au lieu de <m2, c7> d’une part et <t2, c7> d’autre part : la ressemblance <2, 7> (cf. message ci-dessus) est purement fortuite et parfaitement trompeuse...


Attention, un rasoir, fût-il d’Ockham, ça coupe... Haec pluralitas necessaria est

Pour les pannes, on verra après.

[drakuncorp]

Bonjour,

Merci pour les voeux.

DOnc si je comprend bien :
MODELE MONO CAR se servira a lister les caractèristique d'un modele mono
et TYPE MAT CAR ceux d'un modele multi.

MODELE MONO

MODELE MULTI

récupération de la marque et du type de materiel du modele:

select ma.libmarque, m.libmodele,t.libtypemateriel, c.libcaract
from modeles m
JOIN marques ma ON ma.id = m.marques_id
JOIN modeles_mono mm ON mm.modeles_id = m.id
JOIN typemateriels t ON t.id = mm.modeles_id
JOIN modele_mono_car mmc ON mmc.modeles_id = mm.modeles_id
JOIN caracteristiques c ON c.id=mmc.caracteristiques_id
WHERE m.libmodele='XY2540-A'

cette requete est elle optimale

Et la requete pour un modele composite ?

[fsmrel]

Bonsoir Drake,

Donc si je comprends bien :
MODELE_MONO_CAR servira à lister les caractéristiques d'un modèle mono
et TYPE_MAT_CAR ceux d'un modèle multi.

On peut le dire comme ça.

Cette requête est elle optimale ?

1) Vos diagrammes ne sont pas affichés ;

2) La ligne suivante de votre requête n’est pas certainement pas valide :

JOIN typemateriels t ON t.id = mm.modeles_id

Je propose donc la requête suivante qui fait référence à mon dernier diagramme :

Code SQL :

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

1
2
3
4
5
6
7
SELECT z.MarqueNom, x.ModeleNom, t.TypeMaterielLibelle, v.CaracteristiqueLibelle 
FROM   MODELE AS x JOIN MODELE_MONO AS y ON x.ModeleId = y.ModeleId
                   JOIN MARQUE AS z ON x.MarqueId = z.MarqueId
                   JOIN TYPE_MATERIEL AS t ON y.TypeMaterielId = t.TypeMaterielId
                   JOIN MODELE_MONO_CAR AS u ON y.ModeleId = u.ModeleId 
                   JOIN CARACTERISTIQUE AS v ON u.CaracteristiqueId = v.CaracteristiqueId
WHERE  x.ModeleNom = 'XY2540-A' ;

Je ne sais pas quel sens vous donnez à « optimale », mais en tout cas la requête permet de connaître la marque du modèle (« Zigomar »), son type (« Ecran ») et la caractéristique qui va avec le type (« 17" »). En termes de performance, je ne sais pas ce qu’il en est avec MySQL que je n’utilise pas, mais avec DB2 for z/OS la requête est très satisfaisante, elle consomme environ soixante millisecondes. L’optimiseur procède ainsi :

Accès direct à la ligne concernée dans la table MODELE, à condition évidemment qu’il existe un index sur la colonne ModeleNom (libmodele dans votre requête).
Accès direct à la ligne concernée dans la table MODELE_MONO grâce à l’index défini pour la clé primaire de cette table.
Accès direct à la ligne concernée dans la table MARQUE grâce à l’index défini pour la clé primaire de cette table.
Accès direct à la ligne concernée dans la table TYPE_MATERIEL grâce à l’index défini pour la clé primaire de cette table.
Accès direct à l’index défini pour la clé primaire de la table MODELE_MONO_CAR (l’accès à la table elle-même est inutile).
Accès direct à la ligne concernée dans la table CARACTERISTIQUE grâce à l’index défini pour la clé primaire de cette table.

Avec DB2, la requête consomme environ soixante millisecondes.

A la limite, si cela modifie favorablement la stratégie de MySQL, vous pouvez changer de place la qualification « x.ModeleNom = 'XY2540-A' » :

Code SQL :

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

1
2
3
4
5
6
7
SELECT z.MarqueNom, x.ModeleNom, t.TypeMaterielLibelle, v.CaracteristiqueLibelle 
FROM   MODELE AS x JOIN MODELE_MONO AS y ON x.ModeleId = y.ModeleId AND x.ModeleNom = 'XY2540-A'
                   JOIN MARQUE AS z ON x.MarqueId = z.MarqueId
                   JOIN TYPE_MATERIEL AS t ON y.TypeMaterielId = t.TypeMaterielId
                   JOIN MODELE_MONO_CAR AS u ON y.ModeleId = u.ModeleId 
                   JOIN CARACTERISTIQUE AS v ON u.CaracteristiqueId = v.CaracteristiqueId
;

Exemple de requête pour obtenir la marque du modèle DX2000MT, son type, ses types de matériels et les caractéristiques correspondantes :

Code SQL :

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

1
2
3
4
5
6
7
8
SELECT z.MarqueNom, x.ModeleNom, t.ModeleTypeLibelle, v.TypeMaterielLibelle, w.CaracteristiqueLibelle 
FROM   MODELE AS x JOIN MODELE_MULTI AS y ON x.ModeleId = y.ModeleId
                   JOIN MARQUE AS z ON x.MarqueId = z.MarqueId 
                   JOIN MODELE_TYPE AS t ON y.ModeleTypeId = t.ModeleTypeId
                   JOIN MODELE_COMPOSITION AS u ON y.ModeleId = u.ModeleId
                   JOIN TYPE_MATERIEL AS v ON u.TypeMaterielId = v.TypeMaterielId
                   JOIN CARACTERISTIQUE AS w ON u.CaracteristiqueId = w.CaracteristiqueId  
WHERE  x.ModeleNom = 'DX2000MT' ;

Au résultat :

Code :

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

1
2
3
4
5
MarqueNom  ModeleNom  ModeleTypeLibelle  TypeMaterielLibelle  CaracteristiqueLibelle
---------  ---------  -----------------  -------------------  ----------------------
HP         DX2000MT   Unité centrale     Disque dur           250 GB
HP         DX2000MT   Unité centrale     Disque dur           5400 tr/min
HP         DX2000MT   Unité centrale     Barrette mémoire     512 MB

N.B. N’hésitez pas à utiliser la balise [Code=SQL] pour rendre vos requêtes SQL plus lisibles.

[drakuncorp]

Bonjour, FsmreL

Alors on n'est tout à fait d'accord sur cette vue,

J'ai un blocage au niveau de la conception des triggers
exemple la distance en kilomètre ne doit pas ètre inférieur à Zero

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
 
DELIMITER $$
CREATE TRIGGER verif_distance 
BEFORE INSERT ON REGIONS 
FOR EACH ROW BEGIN
IF NEW.distance < 0 THEN
raise_application_error (-20111, 'Distance doit etre supérieur a zero !') ;
END IF;
END
DELIMITER ;

Mais il semble qu'il y a une erreur dans cela.

Une question: comment je fais pour que INSERT ou UPDATE ne s'execute pas si ma condition dans BEGIN .... END n'est pas vérifier (j'ai essayé de locker la table mais impossible avec mysql je crois)

En attendant la vue PANNE -REPARATION - PIECE ,
je te souhaite une excellente journée.
Merci

[fsmrel]

Bonjour Drake,

Alors on n'est tout à fait d'accord sur cette vue

Je suppose que vous voulez dire « on est » plutôt que « on n’est »...

J'ai un blocage au niveau de la conception des triggers

Comme je vous l’ai dit, je n’utilise pas MySQL et ne puis donc pas vous dire exactement ce qui ne va pas avec votre trigger. Toutefois, après recherche sur la toile et par référence à ce qui est écrit ici, il faudrait sans doute coder :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
DELIMITER $$
CREATE TRIGGER verif_distance BEFORE INSERT ON REGIONS 
FOR EACH ROW 
BEGIN
    IF NEW.distance < 0 THEN
        raise_application_error (-20111, 'Distance doit être supérieur a zéro !') ;
    END IF;
END
; $$
DELIMITER ;

C'est-à-dire insérer le délimiteur « $$ » entre les instructions « END » et « DELIMITER ; » (cf. ligne 9).

Ne vous inquiétez pas si je suis moins actif d’ici la fin de la semaine, je vais être très occupé en dehors de l’informatique...

[drakuncorp]

Re bonjour,
Conséquence du language WEB,

D'accord et Merci

[drakuncorp]

Yep,

Voici ce que j'ai mis comme solution temporaire
Pour créer une exception lors d'une insertion , si ma condition est vérifié j'initialise un champ NOT NULL avec une valeur NULL.

La distance ne doit pas etre inférieur a 0

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
DELIMITER $$
CREATE TRIGGER verif_distance 
BEFORE INSERT 
ON REGIONS 
FOR EACH ROW 
BEGIN
    IF (NEW.distance) < 0 THEN
        set NEW.distance = NULL;
    END IF;
END; $$
DELIMITER ;

Avant insertion dans la table modele multi je vérifie si je le modele n'appartient pas à modele mono.

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
DELIMITER $$
CREATE TRIGGER modele_multi
BEFORE INSERT 
ON modele_multi
FOR EACH ROW 
BEGIN
	DECLARE NBRE INTEGER;
	SELECT COUNT(*) INTO NBRE FROM `modeles_mono` m
	WHERE m.modeles_id = NEW.modeles_id;
    IF (NBRE) >= 1 THEN
        set NEW.modeles_id = NULL;
    END IF;
END; $$
DELIMITER ;

Inversement avant insertion dans modeles_mono

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
DELIMITER $$
CREATE TRIGGER modeles_mono
BEFORE INSERT 
ON modeles_mono
FOR EACH ROW 
BEGIN
	DECLARE NBRE INTEGER;
	SELECT COUNT(*) INTO NBRE FROM `modele_multi` m
	WHERE m.modeles_id = NEW.modeles_id;
    IF (NBRE) >= 1 THEN
        set NEW.modeles_id = NULL;
    END IF;
END; $$
DELIMITER ;

[fsmrel]

Bonsoir Drake,

Une évolution des règles de gestion ?

Un MODELE_MULTI est composé d'au moins ou plusieurs MODELE_MONO.
alors pourquoi si le modele "KNT80-AA" est un disque dur de 250GB alors si je veux crée une UNITE CENTRALE qui a 250gb de DD je peux juste affecter ce modele "KNT80-AA" à mon MODELE_MULTI ( DX8000MT)

Je ne saisis pas parfaitement ce que vous écrivez. Jusqu’ici, une unité centrale a des composants non personnalisés : disque dur de 250 GB, DVD interne, etc. Ainsi, on ne sait pas si le disque dur du DX8000MT est un KNT80-AA ou un WD Scorpio.

Question : désormais, chaque élément composant un modèle multi doit-il être systématiquement un modèle mono ? Seulement parfois ? (Par exemple si vous remplacez le disque dur d’origine...)

[drakuncorp]

Bonjour, fsmrel

Je vois ou vous voulez en venir, avec ce que je propose les caracteristiques d'un modele multi seront figés et on ne pourra pas suivre les modifications de pièces effectuée sur cette dernière.

[fsmrel]

Bonsoir Drake,


Je ne vois pas les choses de la façon contraignante que vous évoquez. Mon idée est plutôt celle-ci : comme un ordinateur peut subir des changements, il pourrait être intéressant de tracer ceux-ci. Au passage, je propose que l’on simplifie la gestion de la composition des ordinateurs (par exemple du DX2000MT), en l’occurrence que les composants d’un ordinateur ne soient pas anonymes, donc que l’on établisse directement une relation entre composé et composants (MODELE_MULTI et MODELE_MONO), ce qui revient à dynamiter la table TYPE_MAT_CAR :



Si vous voyez des contre-indications, on cherchera un autre scénario...

Notez que j’ai ajouté un attribut Quantite dans l’en-tête de la table MODELE_COMPOSITION pour permettre de signifier par exemple que le modèle DX2000MT a trois barrettes mémoire identiques (Dell 512 MB en l’occurrence). A vous de voir si cela est intéressant...


Concernant les changements de composants

A l’origine, un certain DX2000MT disons mat1 (repéré dans la table MATERIEL par l’attribut MaterielId = 'mat1') est tout neuf. Ses composants sont connus par jointure des tables MATERIEL et MODELE_COMPOSITION (attribut ModeleId en l’occurrence égal à 'm1').
A la date date1, on a ajouté à mat1 une barrette mémoire Dell, puis un graveur Zigomar 16X à la date date7 ; à la date date2 on a ajouté à un autre ordinateur (disons mat2) un graveur Zigomar 16X. Ces ajouts figurent dans la table COMPOSANT_AJOUT. L’attribut Seq de cette table permet de l’identifier relativement à MATERIEL.

A la date date2, on a remplacé le disque dur (WD Scorpio de 250 GB) de mat1 par un Knt80 (250 GB, 7200 tr/min) de chez Zigomar, lequel à son tour a été remplacé à la date date3 par un WD Caviar (500 GB, 7200 tr/min).

A la date date4 on a supprimé une barrette mémoire pour mat1.



Votre avis ?


Note concernant l’identification relative

Les ajouts, remplacements et suppressions de composants sont propres à un matériel, on peut donc les identifier relativement au matériel, les numéroter 1, 2, 3, ... par rapport à mat1 ; les numéroter 1, 2, 3, ... relativement à mat2, etc. (clé primaire soulignée) :

Code :

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

1
2
3
4
5
6
7
COMPOSANT_AJOUT {MaterielId, Seq, AjoutDate, ComposantModeleId}
                 mat1          1  date1      m9
                 mat1          2  date7      m10
                 mat1          3  date11     m9
                 ...         ...  ...        ...
                 mat2          1  date2      m10
                 ...         ...  ...        ...

Pour programmer ce genre d’identification, voyez l’article de CinePhil.

Je me souviens que vous n’aimiez pas trop la présence des attributs LotId et TiesId dans la table MATERIEL : vous pouvez là aussi utiliser l’identification relative :

[drakuncorp]

Bonjour,
Wep fsmrel, pour la mise à jour du modele c'est exactement ce que je disais. car je me disais qu'il y avait une redondance coté typemateriel et caracteristiques.
C'est ce qui m'a amené à établir la relation : un MODELE multi est composé d'au moins un modele MONO.
J'ai remaqué l'attribut quantite qui réapparait et au bon endroit cette fois ci trop cool.

Pour les composants, je crois qu' il ya pas besoin de remplacement vu que cet dernier action combine la suppression et l'ajout.

Si je vous demande toutes les info ( caracteristiques ...) du DX2000MT aprés ajout et ou suppression de composant.( selon moi le disque dur par défaut de 160 GB remplacé par un de 500 GB risque d'apparaitre dans le résultat vu qu'il est lié au modele)

Pour l'identification relative , je n'ai jamais eu à le mettre mais j'ai compris le processus.




Merci,
Bonne journée à vous

[drakuncorp]

voici le schema : PANNE


un materiel peut subir 0 ou N pannes.
une panne peut se réparer en interne ou peut ètre envoyé chez un TIERS pour réparation.
Lors d'une réparation, des pièces peuvent intervenir ou pas.
Un tiers peut ne pas pouvoir réparer un materiel , mais ce meme materiel peut ètre expédier chez un autre TIERS qui pourra réparer.

Merci pour vos suggestions

[fsmrel]

Bonsoir Drake,

pour la mise à jour du modele c'est exactement ce que je disais. car je me disais qu'il y avait une redondance coté typemateriel et caracteristiques.

Il y aurait redondance dans le cas du dernier scénario (celui qui vous convient), puisqu’un, modèle multi est systématiquement composé de modèle monos. Dans le scénario précédent (plus complexe) il n’y a pas redondance, car les composants peuvent y être anonymes et donc ne pas apparaître dans les modèles monos. Mais bon, le dernier scénario vous simplifiant la vie, on ne va perdre de temps...

Pour les composants, je crois qu' il ya pas besoin de remplacement vu que cet dernier action combine la suppression et l'ajout.

Un remplacement étant équivalent à une suppression suivie d’un ajout, vous pouvez effectivement faire l’économie de la table COMPOSANT_REMPLACT, mais attention alors à assurer la cohérence, la complétude lors d’un remplacement, il faudra éviter de faire les opérations à moitié...
Si vraiment vous vous souhaitez ne pas mettre en œuvre la table COMPOSANT_REMPLACT, alors vous pouvez fondre en une seule table les tables COMPOSANT_AJOUT et COMPOSANT_SUPPR, et y définir un attribut TypeOperation prenant les valeurs « ajout », « suppr » (et « rempl » au besoin).

Si je vous demande toutes les info ( caracteristiques ...) du DX2000MT aprés ajout et ou suppression de composant.( selon moi le disque dur par défaut de 160 GB remplacé par un de 500 GB risque d'apparaitre dans le résultat vu qu'il est lié au modele)

Veuillez préciser votre pensée, je ne vois pas ce que vous voulez dire par « risque »...
De quel DX2000MT parlez-vous ? Du modèle lui-même (table MODELE) ? Dans cette hypothèse, le disque dur est un WD de 250 GB. Si vous voulez parler d’un matériel en particulier (table MATERIEL), les tables COMPOSANT_AJOUT, COMPOSANT_SUPPR (et COMPOSANT_REMPLACT le cas échéant) permettent de savoir à quelle date quel composant a été ajouté ou supprimé.


Je vais regarder la partie concernant les pannes.

[fsmrel]

Bonsoir à nouveau,

un materiel peut subir 0 ou N pannes.

On est d’accord, espérons que ce soit le moins souvent possible

La table pannes (que j’appelle pour ma part PANNE) est à identifier relativement à MATERIEL. En effet, une panne est une propriété multivaluée d’un matériel en particulier.

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

D’accord. C’est bien ce que dit votre modèle.


La table REPAR est identifiée relativement à la table pannes, c’est une bonne chose, mais il manque l’attribut (disons ReparSeq) correspondant. Par ailleurs, ne serait-il pas opportun de faire figurer la référence de la facture correspondante ? Le montant de la réparation correspond-elle au devis ?

Lors d'une réparation, des pièces peuvent intervenir ou pas.

A propos de la table PIECE : Qu’est-ce qu’une pièce ? Un fusible d’écran par exemple ? Telle que vous présentez cette table, et conformément à ce que vous écrivez, on comprend qu’il s’agit seulement des pièces entrant dans la composition d’un modèle de matériel, mais pas du matériel lui-même. Si c’est l’écran qui est fusillé, il n’y a donc pas en l’occurrence de relation entre REPAR et PIECE, c’est bien cela ?


Par ailleurs, votre table PIECE devrait être renommée, par exemple en REPAR_PIECE, et être en principe en relation avec une table PIECE comportant le libellé de la pièce (et autres éléments de référence, comme chez mon garagiste...)

Diagramme provisoire (sans les tiers) :




La suite au prochain numéro...

[fsmrel]

Bonjour Drake,


Que retient-on finalement pour les tables COMPOSANT_AJOUT, COMPOSANT_SUPPR et COMPOSANT_REMPLACT ? On conserve les trois tables ? On ne garde que les deux tables COMPOSANT_AJOUT, COMPOSANT_SUPPR ? On les fond en une seule table ?


Interventions des tiers :

Prenons le cas de la réparation à effectuer r1 relative à la panne p1 du matériel p1. p1 est envoyé chez le tiers t1 à la date d1, pour un devis proposé par t1 de 100 euros. Supposons que t1 n’arrive pas à effectuer la réparation et vous retourne le matériel à la date d2. Vous dites que m1 peut alors être envoyé chez le tiers t2. Selon votre diagramme, on ne peut pas connaître les dates d’envoi d3 et de retour d4 concernant t2 (à moins d'en passer par une réparation r2 relative à la panne p1 du matériel p1, mais votre table TIERS_REPAR n'a alors plus de raison d'être). En plus, toujours selon le diagramme actuel, le devis (ou le prix payé, peu importe) doit être le même pour t1 et t2. Est-ce bien ce qui convient ? Le devis de t2 (ou le prix payé) ne pourrait-il pas être différent de celui de t1 ? (Supposons en plus que t1 a pu changer telle et telle pièce mais pas telle et telle autre, ce dont s’est chargé t2, ou t3 si t2 n’y arrive pas non plus...) Comment connaître les dates d3 et d4 sans passer par la réparation r2 ?

[drakuncorp]

Bonjour,
Ma pensée est : je voudrais savoir comment je fais pour avoir les composants actuels d'un MATÉRIEL(après qu'il est subit des ajout suppression remplacement).

Effectivement, il serait bien de faire figurer la référence de la facture correspondante.
Par rapport à votre question (Le montant de la réparation correspond-elle au devis ?) J'attend une suggestion de votre part.( intéressant)
pour ma part je pense qu'un devis ne concerne qu'une seule panne , et qu'un devis concernant une panne est établie par un seul tiers.)

Au fait pièce = modèle mono = composants courants intervenant dans un PC ( c'est à dire: disque dur , barète mémoire , boitier alimentation, processeur, carte extension etc ....) . Je ne cherche pas à détailler minutieusement tout sur le matériel. Je crois que la table pièce ne sert pas à grande chose.

La suite attendue avec impatience......

[drakuncorp]

Bonsoir Fsmrel,
On les fond en une table.
et Nous avons ainsi :


Hum... .... la je vois que beaucoup de paramètres entre en jeu, voici le modèle que je propose:


Alors j'attend votre avis, et vos pertinentes suggestions. LFREMS

[fsmrel]

Bonsoir Drake,

je voudrais savoir comment je fais pour avoir les composants actuels d'un MATÉRIEL(après qu'il ait subit des ajouts suppressions remplacements).

Pour connaître l’état d’un matériel lors de son installation, il suffit de récupérer pour ce matériel la valeur de l’attribut LotDateReception dans la table LOT (jointure naturelle J1 des tables MATERIEL, LOT_TIERS et LOT).
Si le matériel a subi des changements, pour en connaître l’état actuel, on se sert de la date d’opération (MAX(DateOpe)) de la table COMPOSANT_OPER (jointure naturelle J2 des tables MATERIEL et COMPOSANT_OPER).
Par union des deux jointures J1 et J2, on obtient l’état actuel du matériel, qu’il ait subi ou non des changements.


Dans votre diagramme des changements, il faudrait remplacer par pour la relation entre MONO et COMPOSANT_OP (même chose pour la relation entre MATERIEL et ETAT).

Concernant les réparations :

Vous avez évacué la table PIECE : d’accord. La relation avec la table MONO a disparu : j’en déduis que c’est le matériel complet (le DX2000MT) qui part systématiquement chez le tiers chargé de la réparation et non pas seulement un de ses composants (disque dur, boîtier d’alim, etc.) C’est bien ce que vous prévoyez ?

Par rapport à votre question (Le montant de la réparation correspond-elle au devis ?) J'attend une suggestion de votre part.( intéressant)

A ce stade, c’est à votre service commercial (et/ou au comptable...) de se prononcer ; de mon côté j’ai assez de problèmes avec les devis variés (mais toujours chers) que me proposent les chauffagistes pour le remplacement de mes radiateurs et tout ça...


Vous aviez écrit :

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

Il faudrait donc remplacer par pour la relation entre PANNE et REPARATION (même chose pour la relation entre REPARATION et TIERS, car les tiers ne sont pas tous censés avoir effectué des réparations...)


Aux remarques que j’ai faites près, vos derniers diagrammes paraissent corrects.

[drakuncorp]

Bonjour FsMrel,

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

Alors il serait mieux tout simplement de ne renseigner que la référence de la facture et le montant de la réparation.

Mes derniers diagrammes sont corrects grâce à vos interventions et vos instructions....

Concernant l'identification relative, une relation du type (1,n)--------(association)----------(1,1) conduit elle à une identification relative?

Si non, alors dans quel cas utiliser une identification relative ?

Merci à Vous.

[fsmrel]

Bonsoir Drake,

Effectivement c'est le matériel complet qui part chez le tiers.

D’accord. On pourrait en rester là, mais on peut établir une relation de cause à effet. Je veux dire que si le tiers t1 a par exemple remplacé le disque dur et une barrette mémoire du PC identifié dans la table MATERIEL par MaterielId = 'mat1', alors — ne serait-ce que pour répondre à la question : « Quels sont les composants à ce jour du matériel 'mat1' ?»—, on doit avoir dans la table COMPOSANT_OPER (fusion des tables COMPOSANT_AJOUT, COMPOSANT_SUPPR et COMPOSANT_REMPLACT) une référence à la réparation effectuée par t1.

Puisque toutes les modifications apportées au PC mat1 (table COMPOSANT_OPER) ne sont pas la conséquence de réparations, on pourrait mettre en œuvre une table, appelons-la OPER_REPARATION, qui permette de répercuter les modifications apportées à mat1 et qui sont la conséquence de réparations, cette table jouant en quelque sorte le rôle de pont entre les changements et les réparations. Incidemment, il faudrait mettre en œuvre un trigger pour s’assurer que la date d’opération (attribut DateOperation de la table COMPOSANT_OPER) est égale à la date de la réparation (disons attribut ReparDateRetour de la table REPARATION).

il serait mieux tout simplement de ne renseigner que la référence de la facture et le montant de la réparation.

D’accord, mais en mettant en œuvre la table OPER_REPARATION pour prendre en compte les lignes de facture.

Concernant l'identification relative, une relation du type (1,n)--------(association)----------(1,1) conduit elle à une identification relative?
Si non, alors dans quel cas utiliser une identification relative ?

Il faut remonter à un niveau sémantique. Le père du modèle entité-relation, Peter Chen, a distingué les entités fortes (regular entities) et les entités faibles (weak entities). Même chose pour Ted Codd, père du modèle relationnel de données qui utilise les termes kernel et characteristic pour les entités fortes et faibles. Tout cela se passait dans les années soixante-dix.
Une entité forte est autonome, indépendante, par contraste avec une entité faible dont l’existence dépend de celle d’une autre entité. Par exemple, le tiers t1 est une entité forte. Une facture est une entité faible, car son existence dépend de l’existence d’un tiers. Une ligne de facture est une entité faible dont l’existence dépend en l’occurrence d’une entité qui est faible elle-même.
Cela dit, une entité faible telle qu’une ligne de facture peut être perçue comme étant plutôt une association entre une facture et un produit et faire l’objet d’une entité associative : il n’y a évidemment pas de dogme à imposer, et 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.

Pour compléter l’aspect sémantique, si l’entité-type MATERIEL est forte, je ne pourrai pas supprimer un état (table ETAT) au cas où des matériels y font référence, et la réaction serait violente (ON DELETE NO ACTION au niveau SQL).

Par contre, si on supprime un matériel (table MATERIEL), les lignes de la table COMPOSANT_OPER (entité-type faible) n’ont pas leur mot à dire et doivent mourir a priori (ON DELETE CASCADE), si par ailleurs aucune autre entité-type n’émette de veto.

Dans le contexte de Merise, l’identification relative est le plus souvent le moyen pour moi de signifier qu’une entité-type est faible.

Dans le contexte MySQL Workbench, j’ai l’équivalent de l’identification relative (cf. le diagramme ci-dessous), avec pour résultat de faire participer (au moins) la 1re colonne de la clé étrangère référençant la table « mère » à la clé primaire de la table « fille », là encore comme 1re colonne. Exemple :

La table LOT_TIERS est considérée comme « fille » de la table MODELE, l’attribut ModeleId qui compose la clé primaire de MODELE participe aussi à la clé primaire de la table LOT_TIERS et y figure en 1re position :




Voyez aussi certaines discussions à ce sujet :

La discussion avec Monkeyget, dans laquelle je suis obligé de marquer mon désaccord avec des a priori tenaces ;

Les états d’âme de knoxville ;

Les interrogations de lagra007 ;

Les offres automobilistiques de seb_perl ;

Les repas de Guelykoy ;

Etc.


Je ne sais pas si des forumeurs ont eu le courage de suivre, mais en tout cas il faut reconnaître que la modélisation ça demande patience et réflexion, ça ne se résout pas à coups de quelques clics de souris avec des outils « puissants » quoi qu'en disent les commerciaux chargés de vendre ceux-ci, et même si ça n'est pas encore gagné, on a quand même bon espoir...

Votre opinion ?