Discussion :

[fsmrel]

Vous allez trop vite les enfants !

Pour répondre à une première question :

Cette représentation est-elle prévue dans MERISE ?

Je pense que oui mais il vaut mieux que ce soit fsmrel qui réponde plus sûrement à cette question.

Soit...
Disons que la norme était du ressort du groupe 135 de la défunte AFCET.

Extrait du document AFCET Journée du 15 novembre 1990 - Le formalisme de données Merise : extensions du pouvoir d’expression :

[fsmrel]

Existe-t-il une référence biblio dans laquelle je peux trouver des explications complémentaires sur ces cardinalités identifiantes ?
Je me pose par exemple comme questions :
Quel est l'identifiant de l'entité TUTORAT ?

La réponse officielle est donnée de façon laconique dans le document de l’AFCET dont j’ai fait mention dans mon précédent message. Les AGL symbolisent cela à leur façon. Et tenez compte de ce que dit CinePhil.

En quel forme normal aboutissons-nous lorsque l'on exploite cette notion ?

Je reprends le MLD que j’ai proposé : la table TUTORAT respecte la cinquième forme normale (5NF).




Pour vous en convaincre, vous pouvez en guise de lemme prouver que la BCNF est respectée, puis vous servir du théorème suivant :

Si une table est en BCNF et comporte au moins une colonne non-clé (c'est-à-dire une colonne qui ne participe à aucune clé), alors cette table est en 5NF.

[fsmrel]

Quel est le terme adéquat pour définir cette notion de cardinalité "identifiante" dans MERISE ?

Concernant le terme adéquat, je dirais que l’identification relative est un moyen pour traduire la notion de propriété multivaluée, donc de composition (voir UML à ce sujet). Pour reprendre l’exemple de l’AFCET, un hôtel est composé de chambres (l’entité-type CHAMBRE est une propriété multivaluée de l’entité-type HOTEL). Si un hôtel disparaît de la base de données, les chambres qui le composent disparaissent avec, sans qu’elles puissent s’y opposer. Par contre, dans cet exemple, l’identification relative de l’entité-type HOTEL par rapport à l’entité-type STATION est contestable, car on peut établir la règle suivante :

Une station ne peut pas disparaître tant qu’on y trouve un hôtel.

Autrement dit, l'identification relative peut servir à d'autres fins que celle de la représentation des propriétés multivaluées.

Ainsi, un client de votre entreprise ne peut disparaître de la base de données tant que ce client a une ardoise (des factures non réglées), ce qui ne m’empêche pas d’utiliser l’identification relative : on peut avoir d’autres raisons pour cela. Par exemple, répercuter les enseignements tirés d’un prototypage des performances. Mais là on en est au stade où l’on pratique le yoyo de l’amélioration (optimisation in English) : répercussion sur le MCD des changements apportés au MLD en relation avec la performance des applications.

J'utilise Power AMC, mon souci est de créer un schéma indépendant des spécificités d'un outil. A mon sens un MCD devrait être compréhensible par toute personne connaissant la méthode MERISE, sans lui imposer la connaissance d'un outil en particulier.

Vœu pieux. En fonction de l’AGL que vous utilisez, vous devrez fournir une légende, comme Michelin pratique avec ses cartes. Exemple avec Open ModelSphere, tiré d’une discussion avec dxerty :



Ou pour varier les plaisirs, à propos du forum qui nous permet de correspondre :



Etc., ad infinitum...

[somnambulie]

Impec. Avec cette terminologie d'identifiant relatif j'ai pu retrouver un autre post de fsmrel :
http://www.developpez.net/forums/d33...fiant-relatif/
qui m'a beaucoup éclairé sur la question.

Je vais arrêter de chercher une solution qui n'utilise pas cette notion d'identifiant relatif, définie si j'ai bien compris dans MERISE 2.

merci !

[fsmrel]

Impec. Avec cette terminologie d'identifiant relatif j'ai pu retrouver un autre post de fsmrel :
http://www.developpez.net/forums/d33...fiant-relatif/
qui m'a beaucoup éclairé sur la question.

C'est un des deux liens que je vous ai fournis (CinePhil vous y a renvoyé lui aussi). S'il vous a éclairé, tout va bien.

Je vais arrêter de chercher une solution qui n'utilise pas cette notion d'identifiant relatif, définie si j'ai bien compris dans MERISE 2.

MERISE 2 : Oui.



Vous avez marqué la discussion comme résolue. Soit, mais vous n’êtes peut-être pas au bout de vos surprises. Vous écrivez :

Posons également qu'il existe dans la table tutorat une date de fin (DateFin), alimentée lorsqu'un tutorat prend fin.

Quand vous passerez aux développements, attention aux problèmes qui pourront survenir :

Redondance, recouvrement des périodes, prise en compte du tutorat en cours et j’en passe. Je vous renvoie au support de cours d’Hugh Darwen et prenez le temps de le lire.

Le jour où vous aurez à creuser la modélisation des données temporelles, n’hésitez pas à vous manifester.