Sémantique, identification relative et tout ça...
Bonsoir Drake,
Citation:
Envoyé par
drakuncorp
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).
http://www.fsmwarden.com/developpez_...annes_Oper.png
Citation:
Envoyé par
drakuncorp
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.
Citation:
Envoyé par
drakuncorp
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 :
http://www.fsmwarden.com/developpez_...workbench).png
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... :P
Votre opinion ?