Discussion :

[jedebute_et...]

Bonjour,
Je travaille sur un exercice de modélisation conceptuelle entité-association.
Mais je pense m'être planté. D'ou ma question : une association peut-elle avoir des attributs ???
J'ai une base de données concernant une entreprise de livraison qui expédie des colis. J'ai trois entités : Client / Colis / Entreprise et deux associations : Commande / Livraison.
J'ai mis des attributs dans les associations Commande et Livraison. Par exemple dans Commande, j'ai mis l'adresse de l'enlevement. Ceci est-il possible ?
Merci de voir aide.
Nicolas

[seabs]

Bonjour,

Sans vouloir te donner des ordres, il me semble que tu devrais poster ton travail sous la forme d'un MCD et dire ce qui te pose une difficulté.

Pour ce qui est de ta question, effectivement un association peut comporter des attributs. Pour t'en dire plus, il est nécessaire de posséder plus d'éléments sauf à passer dans l'imaginaire.

Bon courage

[JPhi33]

Bonjour,

Il est toujours possible de définir des propriétés (attributs) dans les associations. Mais attention : dans le cadre de la normalisation du MCD, il faut distinguer 2 catégories d'associations.

1) Les associations de type [ A ]--x,n----( asso )----y,n--[ B ] conservent leurs propriétés.
2) Pour les associations de type [ A ]--x,1----( asso )----y,n--[ B ], la démarche de normalisation conduit à faire "migrer" les propriétés de l'association dans l'entité A.
(x et y valent 0 ou 1)

Lorsqu'on n'est plus débutant, on n'attend pas la phase de normalisation du MCD et on modélise les propriétés imputables aux associations de type 2) directement dans l'entité qui se situe du côté des cardinalités x,1.

Remarque. Dans le type 2), certains auteurs considèrent que les associations de sous-type (nommons-le 2a) :

[ A ]--0,1----( asso )----y,n--[ B ]

peuvent également conserver leurs propriétés. Cela est du au fait que l'association de type 2a se transforme en table au niveau logique alors que ce n'est pas le cas pour le type 2b :

[ A ]--1,1----( asso )----y,n--[ B ]

[allaeddine213]

salut,
pouvez vous m'expliquez pourquoi les associations hierarchique (type2) ne peuvent pas avoir de proprietés
est ce que c'est due a la normalisation?
merci d'avance.

Bonjour,

Il est toujours possible de définir des propriétés (attributs) dans les associations. Mais attention : dans le cadre de la normalisation du MCD, il faut distinguer 2 catégories d'associations.

1) Les associations de type [ A ]--x,n----( asso )----y,n--[ B ] conservent leurs propriétés.
2) Pour les associations de type [ A ]--x,1----( asso )----y,n--[ B ], la démarche de normalisation conduit à faire "migrer" les propriétés de l'association dans l'entité A.
(x et y valent 0 ou 1)

Lorsqu'on n'est plus débutant, on n'attend pas la phase de normalisation du MCD et on modélise les propriétés imputables aux associations de type 2) directement dans l'entité qui se situe du côté des cardinalités x,1.

Remarque. Dans le type 2), certains auteurs considèrent que les associations de sous-type (nommons-le 2a) :

[ A ]--0,1----( asso )----y,n--[ B ]

peuvent également conserver leurs propriétés. Cela est du au fait que l'association de type 2a se transforme en table au niveau logique alors que ce n'est pas le cas pour le type 2b :

[ A ]--1,1----( asso )----y,n--[ B ]

[fsmrel]

pouvez vous m'expliquez pourquoi les associations hierarchique (type2) ne peuvent pas avoir de proprietés
est ce que c'est due a la normalisation?
merci d'avance.

Pour ma part, je ne vois pas d'explication autre que psychologique conduisant à ce que les attributs des associations-types du genre 2b en soient expulsés. Au niveau logique, dans le cadre de la théorie relationnelle, si l'on veut respecter la sixième forme normale (6NF), on sera conduit à retricoter ce qui a été détricoté, renvoyer ces attributs dans les tables qui vont bien.

Pour mémoire :

Une table T est en 6NF si elle comporte une clé K et au plus un autre attribut A
(sous réserve que K ne comporte pas d'attribut B tel que {A}→{B} ou {B}→{A}).

[JPhi33]

Bonjour,

pouvez vous m'expliquez pourquoi les associations hierarchique (type2) ne peuvent pas avoir de proprietés
est ce que c'est due a la normalisation?

Ce n'est pas dû à la normalisation (qui est une conséquence de ce qui suit). C'est dû au fait qu'au niveau logique (MLD) une association de type 2b se transforme en lien référentiel et non pas en table or un lien ne peut pas contenir d'attribut.
Voici un exemple typique. Une ligne de commande porte sur un et un seul article pour une certaine quantité.


Le MCD :

[ LigneCommande ]--1,1----( porte_sur )----0,n--[ Article ]

- LigneCommande est identifiée par Id_LC
- Article est identifié par Id_AR
- "porte_sur" contient la propriété Quantité


Le MLD issu de ce MCD (clés soulignées, clé étrangères suffixées par #) :

LigneCommande (Id_LC, ..., Id_AR#)
Article (Id_AR, ...)

Où placer l'attribut Quantité ?
L'association (la CIF) "porte_sur" s'est transformée en lien référentiel matérialisé par la clé étrangère Id_AR dans la table LigneCommande. Il est évident que ce lien se résumant à un attribut ne peut pas "contenir" un autre attribut. Quantité trouve sa place dans la table LigneCommande.

LigneCommande (Id_LC, Quantité, ..., Id_AR#)

Si l'on procède maintenant à une rétro-conception consistant à retrouver le MCD à partir du MLD ci-dessus. L'attribut Quantité se trouvera affecté non pas à l'association mais à l'entité LigneCommande. C'est la raison pour laquelle j'ai précisé :

Lorsqu'on n'est plus débutant, on n'attend pas la phase de normalisation du MCD et on modélise les propriétés imputables aux associations de type 2) directement dans l'entité qui se situe du côté des cardinalités x,1.

(en réalité 1,1 car les cardinalités 0,1 donnent lieu à une table intermédiaire)

[ego]

Mais il ne s'agit pas de formes normales ou anormales, il s'agit du métier c'est tout.
Si on veut faire porter des attributs à une association c'est probablement que d'un point de vue métier il y a un concept à part entière que l'on a pas nommé et identifié clairement.
Si je prend l'exemple d'une personne qui travaille pour des entreprises

Personne 1,*-------->0,*Entreprise (en UML)

Si je veux faire porter les attributs "date d'embauche, type de contrat sur l'association" c'est qu'en fait j'ai raté le concept de "Contrat de travail" et là le modèle sera

Personne 1,1--------->0,*Contrat 1,*------>1,1 Entreprise

Il ne s'agit donc pas de s'embrouiller l'esprit avec de la théorie (même si ensuite cela peut aider) mais simplement de réfléchir complètement au métier

[allaeddine213]

merci jphi pour ta reponse

Bonjour,



Ce n'est pas dû à la normalisation (qui est une conséquence de ce qui suit). C'est dû au fait qu'au niveau logique (MLD) une association de type 2b se transforme en lien référentiel et non pas en table or un lien ne peut pas contenir d'attribut.
Voici un exemple typique. Une ligne de commande porte sur un et un seul article pour une certaine quantité.


Le MCD :

[ LigneCommande ]--1,1----( porte_sur )----0,n--[ Article ]

- LigneCommande est identifiée par Id_LC
- Article est identifié par Id_AR
- "porte_sur" contient la propriété Quantité


Le MLD issu de ce MCD (clés soulignées, clé étrangères suffixées par #) :

LigneCommande (Id_LC, ..., Id_AR#)
Article (Id_AR, ...)

Où placer l'attribut Quantité ?
L'association (la CIF) "porte_sur" s'est transformée en lien référentiel matérialisé par la clé étrangère Id_AR dans la table LigneCommande. Il est évident que ce lien se résumant à un attribut ne peut pas "contenir" un autre attribut. Quantité trouve sa place dans la table LigneCommande.

LigneCommande (Id_LC, Quantité, ..., Id_AR#)

Si l'on procède maintenant à une rétro-conception consistant à retrouver le MCD à partir du MLD ci-dessus. L'attribut Quantité se trouvera affecté non pas à l'association mais à l'entité LigneCommande. C'est la raison pour laquelle j'ai précisé :

(en réalité 1,1 car les cardinalités 0,1 donnent lieu à une table intermédiaire)

[fsmrel]

Bonsoir,

Une ligne de commande porte sur un et un seul article pour une certaine quantité.

[ LigneCommande ]--1,1----( porte_sur )----0,n--[ Article ]

Il n’y a pas d’absolu. La ligne de commande est ici considérée comme entité-type, mais peut tout aussi bien être considérée une association entre la commande et le produit, association porteuse de l’attribut Quantité (cf. l'ouvrage de référence De l’autre côté de Merise, d'Yves Tabourier). Il est normal qu’en transformant l'association en entité-type, celle-ci continue à être porteuse de l’attribut Quantité.

L'association (la CIF) "porte_sur" s'est transformée en lien référentiel matérialisé par la clé étrangère Id_AR dans la table LigneCommande.

Pourquoi parler de CIF ? Est-ce une nécessité ? Toujours dans De l’autre côté de Merise, Yves Tabourier se cantonne à l’emploi du mot « relation ». Quant aux contraintes, voici ce qu’il écrit (pages 88-89 de l’ouvrage) :

... de multiples problèmes d’unicité se présentent, dont les cardinalités ne peuvent rendre compte, d’où l’introduction de « contraintes de cohérence fonctionnelle » — appelées « dépendances fonctionnelles » dans (TRC84) — pour exprimer les problèmes d’unicité dans le cas de relations à plus de deux pattes...

Dans le document AFCET Journée du 15 novembre 1990 - Le formalisme de données Merise : extensions du pouvoir d’expression, aux pages 48 et 49, Yves Tabourier s’exprime une fois de plus à propos des contraintes d’unicité.

Il parle d’abord des dépendances fonctionnelles au sens du Modèle Relationnel de Données (il s’agit donc d’un concept autre que celui de (TRC84)) et notamment dans le cas des relations binaires :



(Il oublie au passage # cde → # nom client, mais on ne lui en tiendra pas rigueur...)

Il poursuit en parlant des CIF, mais pour établir, une fois de plus, des contraintes à usage des relations à plus de deux pattes.


Pour en revenir au associations-types porteuses d’attributs.

Sémantiquement parlant : chaque ingénieur de mon entreprise (une SSII) a ses attributs propres, intrinsèques, (son nom, son prénom, sa date de naissance, son numéro de sécurité sociale, etc.), alors que le chantier auquel il participe lui est extrinsèque et je ne suis pas choqué, au contraire, si la date à laquelle il a été missionné dégage dans la relation qui existe entre l’ingénieur et le chantier :



Je serais d’autant conforté qu’au niveau logique le MLD que je suis en droit d’attendre peut être de préférence le suivant :




En effet, au cours des séances de prototypage, on a pu être amené à ne pas polluer, rendre obèse la table INGENIEUR par une foule d’attributs extrinsèques du genre ChantierId et DateAffectation parce qu’au niveau conceptuel l’entité-type INGENIEUR serait en relation 1,1 avec moult autres entités-types outre CHANTIER.

Vous me direz que j’en suis à la phase d’optimisation, et c’est vrai, mais je préfère que ce soit la table AFFECTER qui soit bombardée par les UPDATE (pour parler SQL), car si les INSERT sont peu nombreux (un INSERT correspond à la naissance d'un ingénieur et à sa première affectation à un chantier), par contre les UPDATE peuvent pleuvoir à cause des affectations, et pendant ce temps-là la table INGENIEUR est inaccessible en lecture (pour des traitements qui ne sont pas concernés par ces affectations) si l’on n’a pas pris la précaution de les isoler. Vous me direz encore que les ingénieurs ne changent pas de chantier à tout bout de champ, mais dans l’univers de la cotation des titres en Bourse, on pourrait sans doute trouver des exemples de blocages inopportuns.

Vous pourrez encore me faire observer que le MLD que j’ai obtenu correspond à une dérivation d’un MCD selon lequel la cardinalité 1,1 portée par la patte connectant INGENIEUR et AFFECTER est en réalité 0,1, donc que des ingénieurs pourraient être sans affectation, horresco referens ! En fait, cette situation ne pourrait se produire que dans le cas d’un INSERT. Pour éviter cela, par le jeu des GRANT/REVOKE de la part des DBA, on forcera les INSERT à attaquer une vue, appelons-la INGENIEURV :

Code SQL :

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

1
2
3
4
CREATE VIEW INGENIEURV (IngenieurId, IngenieurNom, ChantierId, DateAffectation)
AS SELECT   x.IngenieurId, x.IngenieurNom, y.ChantierId, y.DateAffectation
   FROM     INGENIEUR AS x JOIN AFFECTER AS y 
            ON x.IngenieurId = y.IngenieurId

Et si le SGBD est infoutu de ventiler les données à l’occasion d’un INSERT tel que :

Code SQL :

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

1
2
INSERT INTO INGENIEURV (IngenieurId, IngenieurNom, ChantierId, DateAffectation) 
            VALUES ('i01', 'Albert', 'ch01', '2000-05-01') ;

Alors on sous-traitera l'opération de ventilation à un trigger ad-hoc (exemple SQL Server) :

Code SQL :

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

1
2
3
4
5
6
7
CREATE TRIGGER INGENIEUR_trigger_01 ON INGENIEURV INSTEAD OF INSERT AS
INSERT INTO INGENIEUR
       SELECT IngenieurId, IngenieurNom
       FROM   INSERTED     
INSERT INTO AFFECTER
       SELECT IngenieurId, ChantierId, DateAffectation
       FROM   INSERTED

Et si le SGBD ne sait pas appliquer un trigger à une vue, alors on se dém..., etc.

Quant aux opérations de suppression (portant seulement sur la table INGENIEUR, cela va de soi), doter la table AFFECTER d'une clé étrangère avec effet cascade fera l’affaire :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE AFFECTER
(
        IngenieurId     CHAR(04)      NOT NULL
      , ChantierId      CHAR(04)      NOT NULL
      , DateAffectation DATE          NOT NULL
    , CONSTRAINT AFFECTER_PK PRIMARY KEY (IngenieurId)
    , CONSTRAINT AFFECTER_INGENIEUR_FK FOREIGN KEY (IngenieurId) 
                 REFERENCES INGENIEUR ON DELETE CASCADE
    , CONSTRAINT AFFECTER_CHANTIER_FK  FOREIGN KEY (ChantierId)  
                 REFERENCES CHANTIER
) ;

[JPhi33]

Bonjour à tous,

@fsmrel

Il n’y a pas d’absolu.

Vous avez raison, il n'y a pas d'absolu. Néanmoins, lorsqu'une association de type -1,1--( )--x,n- est porteuse de propriétés, il est plus fréquent que ce soit une erreur de conception.

La ligne de commande est ici considérée comme entité-type, mais peut tout aussi bien être considérée une association entre la commande et le produit

Ce n'est pas faux. C'est anecdotique mais il me semble qu'il est préférable de modéliser la ligne de commande comme une entité faible de la commande, notamment pour des raisons de performance de la BdD. J'ai placé mon exemple dans ce contexte (j'aurais dû le préciser) :

[ Commande ]--1,n----( )---(1,1)-[ LigneCommande ]--1,1----( porte_sur )----0,n--[ Article ]

(les cardinalités 1,1 entre parenthèses est l'une des notations possibles pour l'identification relative)


J'aurais pu choisir n'importe quel autre exemple. En voici un (gestion de contrat de location automobile) :

[ Contrat ]--1,1----( est_souscrit )----0,n--[ Client ]

L'entité contrat contient entre autres propriétés la date d'effet du contrat. Le concepteur avait placé la propriété "date_signature_client" dans l'association "est_souscrit", ce qui est manifestement une erreur de modélisation : date_signature_client est une propriété de l'entité Contrat.

Pourquoi parler de CIF ? Est-ce une nécessité ?

Vous citez Tabourier. On peut citer Tardieu/Rochfeld/Colletti ou encore Morejon qui expliquent qu'il y a CIF lorsque la cardinalité source est 1,1 et que le lien est stable et donc non sujet à mise à jour.



Pour terminer, nul doute que la mise en lumière que vous avez effectuée de ces cas particuliers (transformation d'une association 2b en table) auront frappé les esprits et que les futurs concepteurs se poseront la question avant de transformer une telle association porteuse de propriétés.
Attention, les AGL de modélisation conceptuelle ne proposent pas ces transformations, me semble-t-il (je ne les connais pas tous).

[fsmrel]

Bonjour,

Vous avez raison, il n'y a pas d'absolu. Néanmoins, lorsqu'une association de type -1,1--( )--x,n- est porteuse de propriétés, il est plus fréquent que ce soit une erreur de conception.

Je ne dis pas non, mais dans quelles conditions y a-t-il erreur ?

J’ai émis l’hypothèse que, dans l’exemple des ingénieurs affectés à des chantiers, faire figurer la date d’affectation dans l’association-type était légitime, notamment parce que cette date ne faisait pas partie des propriétés intrinsèques de l’ingénieur, contrairement à son nom, son prénom, sa date de naissance, etc.

Au rebours, pour reprendre votre exemple de location automobile, j’ai moi aussi du mal à concevoir que la date de signature ne soit pas une propriété intrinsèque du contrat. Par ailleurs, cette date est stable et je ne vois pas pourquoi au niveau MLD on serait conduit à la faire migrer dans une table associative du genre :

[Contrat{ContratId, ...}]<-----[Signature{DateSignature}]---->[Client{ClientId, ...}]

Pour les raisons que je viens d’invoquer, la table Signature n’est pas pertinente, tandis que le MLD ci-dessous, convient parfaitement :

[Contrat{ContratId, ..., DateSignature}]---->[Client{ClientId, ...}]

Allons un peu plus loin et faisons un détour du côté de l’urbanisation. Les plus jeunes n’étant sans doute pas au courant de ce dont il s’agit, je rappelle à leur intention qu’à l’occasion des projets de taille conséquente, on urbanise, on découpe ces projets en domaines et sous-domaines, auxquels on affecte autant d’équipes chargées de concevoir puis de réaliser. Pour ma part j'ai pris l’habitude de parler de référentiels : pour tel projet ayant pour objet les cotisations des futurs retraités, il y a ainsi les référentiels PERSONNES, CONTRATS, PRODUITS, COTISATIONS, PROSPECTION, etc.

Chaque référentiel est de la responsabilité d’un chef de projets assisté de son équipe et il est (plus ou moins bien) conseillé par des spécialistes transversaux dans le genre de votre serviteur...

Quittons la société de location automobile (mais les principes restent les mêmes) pour débouler dans le SI d’une caisse de retraite, une de celles qui assurera vos vieux jours... L’équipe chargée du référentiel PERSONNES prend en charge la modélisation de sa partie et le développement des services qui vont avec. Dans le cadre de ce référentiel, une personne est soit une entreprise, un établissement de cette entreprise, un salarié de cette entreprise, un contact de cette entreprise, un employé de la caisse de retraite elle-même, un organisme administratif (tribunal administratif ou que sais-je encore), bref un bel inventaire à la Prévert avec lequel peuvent s’éclater les passionnés de la spécialisation/généralisation et de l’héritage en général.

Pour reprendre votre exemple :

[ Contrat ]--1,1----( est_souscrit )----0,n--[ Client ]

Dans le cas de la caisse de retraite, l’entité-type Contrat fait clairement partie du référentiel CONTRAT, tandis que l’entité-type Client fait partie du référentiel PERSONNES (par exemple, ça n’est pas à l’équipe chargée du référentiel CONTRATS de gérer les adresses des clients, leurs coordonnées bancaires, etc.) Quid de la date de signature du contrat ? L’équipe chargée du référentiel PERSONNES s’en soucie comme d’une guigne contrairement à l’équipe chargée du référentiel CONTRATS. Quid de l’association-type « frontière » est_souscrit ? L’équipe chargée du référentiel PERSONNES s’en soucie à nouveau comme de colin-tampon et en laisse bien entendu l’entière responsabilité à l’autre équipe.

Mais revenons-en à l’exemple des affectations des ingénieurs à des chantiers. L’équipe chargée du référentiel PERSONNES s’occupe de l’aspect administratif des ingénieurs (sans oublier leurs augmentations de salaire...) et n’est pas concernée par l’aspect opérationnel, c'est-à-dire vendre de l'ingénierie aux clients, affecter les ingénieurs à des missions sur les chantiers. Supposons qu’il existe un référentiel MISSIONS dont fassent partie les chantiers. On sait parfaitement affecter les objets : l’entité-type INGENIEUR ressortit au référentiel PERSONNES, l’entité-type CHANTIER au référentiel MISSIONS, mais quid de l’association-type AFFECTER ? C’est bien l’équipe MISSIONS qui traite, qui pilote les affectations, et l’association-type AFFECTER fait logiquement partie du référentiel MISSIONS. Pour sa part, la propriété DateAffectation suit le mouvement et n’a aucune raison de figurer dans l’entité-type INGENIEUR ; l’équipe chargée du référentiel PERSONNES considérera qu’il s’agit d’un parasite dont elle ne veut pas assurer la mise en œuvre, puisque l’équipe MISSIONS ne pourrait que consulter — dans un système urbanisé, on n'a pas directement accès aux objets dont on n’a pas la responsabilité, on doit s’adresser à qui de droit par le biais de demandes services : « A l’attention de l’équipe chargée du référentiel PERSONNES, pourriez-vous nous transmettre le code NAF du client Tartempion ? » — Ainsi, on voit mal l’équipe chargée du référentiel MISSIONS exprimer des demandes du genre : « A l’attention de l’équipe chargée du référentiel PERSONNES, pourriez-vous nous transmettre la date à laquelle nous avons affecté l’ingénieur Albert au chantier Alesia ? », « Pourriez-vous historiser l’affectation d’ALBERT au chantier Alesia pour la période [2001-01-15:2001-01-20] et l’affecter au chantier Bordeaux à compter du 2001-01-21 ? » L’équipe chargée du référentiel PERSONNES répondra évidemment que ce ne sont pas ses oignons. Autrement dit, la propriété DateAffectation n’a pas à parasiter l’entité-type INGENIEUR, c’en est bien une propriété extrinsèque.

Dans ce genre d’exercice, les objets « frontières » tels que l’association-type AFFECTER peuvent poser des problèmes pour lesquels il faudra un arbitrage de la DSI et trouver des compromis (j’ai participé à des réunions « tendues » à ce sujet...) Par exemple, dès qu’un ingénieur est embauché (ceci ressortit au référentiel PERSONNES), il faut en même temps l’affecter à un chantier (parce que c’est du reste pour cela qu’on l’a embauché) et ceci ressortit au référentiel MISSIONS. Mais qui développe le service correspondant et puisera dans le budget dont on l’a doté ? Il serait logique, qu’après arbitrage de la DSI, ce soit l’équipe chargée du référentiel PERSONNES qui devienne le sous-traitant de sa partenaire et s’y collera. A débattre...

[fsmrel]

Bonjour à nouveau,

il me semble qu'il est préférable de modéliser la ligne de commande comme une entité faible de la commande, notamment pour des raisons de performance de la BdD. J'ai placé mon exemple dans ce contexte (j'aurais dû le préciser) :

Commande ]--1,n----( )---(1,1)-[ LigneCommande ]--1,1----( porte_sur )----0,n--[ Article ]

(les cardinalités 1,1 entre parenthèses est l'une des notations possibles pour l'identification relative)

A propos de la performance de la base de données (l’objet de mon métier ), disons qu’elle sera la même si l’on part sur la représentation suivante (pour changer, je fais ici référence à Michel Diviné (Parlez-vous Merise ?, page 56), bien que le verbe Concerner qu’il emploie n’a guère de valeur ajoutée sémantiquement parlant, par exemple Composer ou quelque chose comme cela eut peut-être été plus approprié...) :

[ Commande ]--1,n---( Concerner )---0,n--[ Article ]

En effet, au niveau tabulaire, les structures seront les mêmes — à l’attribut IdLigneCommande près —, puis, en passant au niveau physique, les index qui vont bien pour la performance auront le même rendement, à epsilon près (cluster sur {IdCommande, IdLigneCommande} dans un cas, sur {IdCommande, IdArticle} dans l’autre cas).

Pour citer Rochfeld et Moréjon (La Méthode Merise, Tome 3, Gamme opératoire, page 94), disons plutôt que

« les deux modèles ne sont pas sémantiquement équivalents [...] Dans le premier modèle il est possible d’exprimer qu’il existe n rencontres entre deux occurrences précises de Commande et d’Article. Dans le second, il ne peut y avoir qu’une et une seule rencontre entre ces deux occurrences ».

J’ajouterai pour ma part que votre représentation est plus ouverte : elle permet de prendre en compte les engagements sur les lignes de commande, alors que la mienne ne le permet pas (il y aurait association d’associations). Pour en revenir à l’aspect performance, voyez la conséquence du choix entre identification relative et identification absolue.

[fsmrel]

Bonsoir,

Pourquoi parler de CIF ? Est-ce une nécessité ?

Vous citez Tabourier. On peut citer Tardieu/Rochfeld/Colletti ou encore Morejon qui expliquent qu'il y a CIF lorsque la cardinalité source est 1,1 et que le lien est stable et donc non sujet à mise à jour.

J’ai préféré ne pas citer les auteurs dont vous faites mention à cause justement du problème de stabilité des liens. Nous avons déjà parlé ici de ce problème (il y a déjà deux ans, comme le temps passe...) et de la position prise par le groupe de travail 135 de l’AFCET (dans Le formalisme de données MERISE, Extension du pouvoir d'expression. Journée d'étude organisée par le Groupe de travail 135 « Conception des systèmes d'information » (Collège AFCET-GID), Jeudi 15 novembre 1990).