Discussion :

[Taxable]

Bonjour,

Je suis loin d'être un expert en construction de base de données, je dirai que je suis novice, un grade au desses de Newbie.
J'ai tenté de suivre les conseils de fsmrel et escartefigue, notament en compillant l'exemple 'Société Audiovisuel'. Que de bon conseil !
Je me suis aperçu sur ce petit projet que mes idées aussi claire soit-elle n'ont pas résisté pas à une démarche-méthodologie rigoureuse.

Je vous livre ci-dessous le fruit de ma réflexion sur un projet de signature électronique sur une tablette Android que m'a demandé mon chef.
Je bloque sur le diagramme de Merise que j'ai dessiné avec Jmerise.

Merci de me donner une piste pour corriger ou améliorer la conception de ce projet.

Cordialement,

L’application a pour ambition de remplacer les feuilles de présences papier que nous signons à l’issue de certaines réunions, par un système de « signature électronique » en utilisant une tablette Android et un stylo électronique. Dans ce projet, la fonction de « signature électronique » désigne l’action de signer et d’écrire sur un document électronique, et de fournir un minimum d’authentification des fichiers pdf résultants. Le projet dans son ensemble : Le périmètre de cette étude porte uniquement sur la tablette Android ‘spécifiquement’ dédiée à cette application. L’opération est initiée sur une plateforme web -qui est hors périmètre de notre étude- par la saisie des dates et horaires des réunions, de la liste des participants et par l’upload d’un ou plusieurs fichiers au format PDF. Ces informations sont ensuite transférées à toutes les tablettes dédiées disponibles dans l’entreprise. Chaque participant à une réunion à a sa disposition une ou plusieurs tablettes et en choisit une indifféremment pour « signer » ses documents. Enfin, à chaque validation d’un document signé, la tablette fabrique à partir du document pdf « original » un autre document pdf « signé » et « authentifié » qui est alors transféré sur à la plateforme web. Illustrons le cas par un exemple concret : Soit une session de formation sur une journée. Un participant choisi une des deux tablettes disponible circulant dans la salle de réunion, il sélectionne son nom sur la liste des participants affichée à l’écran. Il lui est proposé un document dénommé ‘présence’ regroupant deux feuilles, l’une relatif à son heure d’arrivée et l’autre relatif à son heure de départ. Il signe la première feuille pour attester de sa présence en début de réunion. Il signera en fin de réunion, selon la même procédure, la deuxième feuille pour attester de sa présence en fin de réunion. Son collège a oublié de signer à son heure d’arrivée. Il signera les feuilles de début et de fin de réunion simultanément, en une seule opération. Il a utilisé la deuxième tablette en circulation. Chaque participant valide sa signature (bouton valider) et passe la tablette au suivant. A l’issue de la réunion, l’animateur récupère les tablettes. Il utilise une des deux tablettes. Il se rend sur un programme ‘BackOffice’ pour signaler les absents (pas de fichiers pdf « signé ») puis « clôture » le dossier de cette réunion. La tablette est disponible pour une autre réunion. - - Nous pouvons avoir le cas d’une unique tablette utilisée par deux réunions qui se tiennent en parallèle. La tablette passant d’une salle à l’autre. Quelques précisions : Base de Données La base de données utilisée par la plateforme est SqlServer de Microsoft La base de données utilisée par les tablettes est SQLite sous Android 6.0 Les deux bases de données ne sont pas reliées entre elle. Nous envisageons de ‘déverser’ des données d’un environnement vers l’autre avec les contrôles nécessaires. Les données contenues dans la base de données dans la tablette sont effacés par roulement de deux jours / J+2 (durée sujet à modification). Document, feuilles et fichier pdf Un « document » est un regroupement d’une ou plusieurs « feuilles » de présences. Une « feuille » de présence est un matérialisé par un fichier PDF (feuille = fichier pdf), un document est un regroupement de fichier PDF. Chaque participant ne signe qu’un seul document par réunion, c'est-à-dire une ou plusieurs « feuille » de présence, en une ou deux opérations. On distingue trois types de feuilles de présences : - pièce unique sous forme de tableau mentionnant le nom de tous les participants à une réunion. Dans ce cas, il y a un seul fichier-original qui sera utilisé par tous les participants de la réunion. Dans ce cas, l’unique fichier-signé est affecté à tous les participants - pièce commune (photocopie) la feuille est dupliquée puis affectée à un participant. Dans ce cas il y a un seul fichier-original qui sera ‘dupliqué’ et affecté à chaque participant. Dans ce cas, chaque fichier-signé est affecté au participant signataire. - pièce individualisée chaque feuille mentionnant le nom du participant est affecté à ce dernier. Dans ce cas il y a un autant de fichier-original qu’il y a de participant. Dans ce cas, chaque fichier-signé est affecté au participant signataire. Enfin, l’application créera aussi un dernier fichier pdf qui sera la concaténation de tous les fichiers-signé : le « document de synthèse ». Ce fichier-synthèse est associé à la réunion. Les Règles de Gestion TABLETTE : Une tablette est un appareil tactile avec un écran tactile et un stylo électronique Une tablette possède un identifiant unique (issue de la plateforme web) Une tablette possède un nom Une tablette possède des éléments de paramétrages (adresse IPort, adresse Wifi:Code, …) Une tablette possède des éléments de réglages (couleur de l’écriture, épaisseur du trait, …) TAB_01 : Une tablette contient de zéro à N prestation PRESTATION : Une Prestation est une ensemble qui regroupe plusieurs réunions (par exemple prestation = ‘formation sur Merise en trois réunions sur trois jours’) Une prestation possède un identifiant unique créé par la tablette Une prestation possède un identifiant unique (issue de la plateforme web) Une prestation possède un nom PRE_01 : Une prestation comporte une ou plusieurs réunions PRE_02 : Une prestation appartient à une et une seule tablette ( ! ou plusieurs tablette !! ) REUNION : Une réunion possède un identifiant unique créé par la tablette Une réunion possède un identifiant unique (issue de la plateforme web) Une réunion possède un nom Une réunion possède une date (une réunion se déroule sur une seule journée au plus) Une réunion possède une heure de début et une heure de fin Une réunion désigne les informations que l’on doit recueillir auprès du participant (genre, nom, adresse, date de naissance) si celle-ci sont manquantes REU_01 : une réunion appartient à une et une seule prestation REU_02 : une réunion regroupe un à plusieurs participants REU_03 : une réunion est associée à xxx ZERO* à plusieurs PDF-original (feuille unique) REU_04 : une réunion est associée à xxx ZERO* à plusieurs PDF-signé (feuille unique) REU_05 : une réunion est associée à zéro ou un fichier PDF de synthèse (ensemble des fichiers concaténés) ZERO* : CONTRAINTE : il doit y avoir au minimum UN PDF soit pour REUNION, soit pour PARTICIPANT. PARTICIPANT : Un Participant est une personne physique qui signe. (a)Un même participant qui assiste à deux réunions différentes aura deux identifiants différents. Nous ne ‘traçons’ pas les individus. Un participant possède un identifiant unique créé par la tablette Une participant possède un identifiant unique (issue de la plateforme web) Un participant possède un prénom obligatoirement Un participant possède un email obligatoirement Un participant possède des informations facultatives et/ou obligatoires (genre, nom, adresse, date de naissance) Un participant est désigné présent (par défaut) ou absent PAR_01 : un participant appartient à une et une seule Réunion(a) PAR_02 : un participant est associé à xxx ZERO* à plusieurs PDF-Original PAR_03 : un participant est associé à xxx ZERO* à plusieurs PDF-Signé ZERO* : CONTRAINTE : il doit y avoir au minimum UN PDF soit pour REUNION, soit pour PARTICIPANT. PDF : Un pdf est un fichier contenant un formulaire que doit signer le participant. Il y a un Un PDF est un fichier pdf Un PDF est désigné original ou signé ou synthèse : PDF-Original et PDF-Signé et PDF-Synthèse Un PDF-Original est issue de la plateforme web Un PDF-Signé est fabriqué par la tablette à partir d’un PDF-Original et des éléments de signature : il y a autant de PDF que de feuilles par participant et feuilles par réunion Un PDF-Synthèse est la concaténation de tous les fichiers PDF-Signé. Il n’y a qu’un seul PDF de Synthèse par Réunion Un PDF possède un identifiant unique créé par la tablette Un PDF possède un identifiant unique (issue de la plateforme web) Un PDF possède un lien qui pointe sur l’emplacement de stockage dans la tablette Une PDF possède des données d’authentification (clé public, clé privée). Il y a Obligatoirement au minimum un PDF affecté soit à REUNION, soit à PARTICIPANT PDF_01 : un PDF-Original est associé à un ou plusieurs participants /ou PDF_02 : un PDF-Original est associé à une et une seule réunion PDF_03 : un PDF-Signé est associé à un ou plusieurs participants /ou PDF_04 : un PDF-Signé est associé à une et une seule réunion PDF_05 : un PDF de synthèse est associé à une et une seule réunion PDF_** : Nous n’avons pas besoin de lié un PDF-Original et un PDF-Signé, dans la mesure où le PDF-Signé est associé au Participant, qui lui-même est associé au PDF-Original RESULTAT : Le résultat est un ensemble d’indicateur qui fournit des informations sur le déroulement de la campagne de signature Un résultat est un indicateur précisant si le participant a signé chacun des fichiers PDF Un résultat est un indicateur précisant si la session de signature de la réunion est close Un résultat est un indicateur précisant si le PDF-Synthèse a été crée Un résultat est un indicateur précisant si les fichiers ont été transmis à la plateforme web RES_01 : un résultat est associé à un ou plusieurs participants RES_02 : un résultat est associé à une et une seule réunion RES_03 : un résultat est associé à une ou plusieurs fichiers PDF (Signé et Synthèse )

[escartefigue]

bonjour Taxable,

Je n'aurai pas le temps de traiter votre sujet aujourd'hui, mais en 1ère lecture je vois que vous avez modélisé une entité-type "projet" et dans les règles vous n'en parlez pas, par contre vous parlez de "prestations" notion absente du MCD.
S'il s'agit de synonymes, il faut choisir un terme unique pour éviter toute équivoque, vous préciserez seulement dans le dictionnaire de données que l'un est synonyme de l'autre.

Si c'est bien la même chose, les cardinalités avec l'entité-type "réunion" sont inversées entre les règles et le modèle

En tout cas bravo pour la présentation du contexte et l'énumération des règles

[Taxable]

Bonjour,
Merci pour votre retour ultra-rapide.
Et merci pour vos encouragement.

.. en 1ère lecture je vois que vous avez modélisé une entité-type "projet" et dans les règles vous n'en parlez pas, par contre vous parlez de "prestations" ...

En effet, projet=prestation. J'ai changé mon diagramme pour éviter toute confusion.

.. les cardinalités avec l'entité-type "réunion" sont inversées entre les règles et le modèle ...

En effet, je me mélange un peu les pinceaux entre les cardinalités et les contraintes. J'ai modifié à la fois les règles et le diagramme. Je n'en suis pas certain de son exactitude.

Bonne journée

[fsmrel]

J'ai tenté de suivre les conseils de fsmrel et escartefigue, notamment en compilant l'exemple 'Société Audiovisuel'. Que de bon conseil !

Suite à quoi vous avez réussi à exposer les règles de gestion des données : bon point pour vous.

Evidemment, vous avez constaté que suite à cela, bâtir un MCD satisfaisant n’est pas chose simple, mais sachez que nous sommes tous passés par des phases de doute, de découragement, incitant à baisser les bras (mais en levant le coude, on peut quand même se consoler !) Si un concepteur prétendait le contraire, je lui dirais que ça lui arrivera forcément, quand il voudra modéliser sérieusement.

PRE_02 : Une prestation appartient à une et une seule tablette ( ! ou plusieurs tablette !! )

Corriger : supprimer la partie qui ne va pas.

Une tablette possède un identifiant unique (issu de la plateforme web)

Un rappel important : ça n’est pas votre propre application qui maîtrise cet identifiant, en conséquence de quoi vous devez le considérer comme identifiant alternatif (secondaire diront d’aucuns) et mettre en œuvre vos propres identifiants, pour l’ensemble des entités-types. L’identifiant « web » est un point d’entrée dans votre système, mais c’est tout. Appelons-le par exemple idTabletteWeb, tandis que l’identifiant légal et légitime de l’entité-type TABLETTE sera un attribut idTablette (de type auto-incrément) sur lequel personne n’aura prise. En tout cas, la suite montre que vous avez pensé à cela.

Une prestation possède un identifiant unique créé par la tablette
Une prestation possède un identifiant unique (issu de la plateforme web)

En relation avec ce qui précède, doit-on comprendre que l’identifiant « créé par la tablette » est bien celui que j’ai nommé idTablette ?

En passant, qui dit « identifiant » dit « unique », donc vous pouvez gommer cet adjectif, « identifiant » suffit.

Contrainte d’égalité

Votre MCD comporte une contrainte d’égalité portant sur les associations A SIGNER : il faudrait justifier, expliciter les motifs de cette contrainte.

Pour mémoire, je rappelle ce que dit l’AFCET sur ce type de contrainte :




Autrement dit, chaque PDF à signer pour une réunion doit être un PDF à signer par un participant ? Chaque PDF à signer par un participant doit être un PDF à signer pour une réunion ?

Vous signalez par ailleurs : « contrainte de relation = OU ». Voulez-vous signifier qu’il faut lire non pas « = », mais « OU » ? Si oui, ce « OU » est-il, inclusif ? exclusif ?


Associations non binaires

L’association VALIDER est de degré 4 (elle a 4 pattes d’association). Telle quelle, elle signifie que la validation V concerne la réunion R, le participant P, le PDF F et le résultat S, en toute indépendance, c'est-à-dire que le participant n’a a priori rien à voir avec la réunion, le PDF et le résultat, que la réunion n’a a priori rien à voir avec le participant, le PDF et le résultat, etc. On reviendra plus tard sur ce point.


Aménagement du MCD

La patte d’association connectant l’entité-type REUNION et l’association Constituer n’est pas porteuse d’une cardinalité 1,1 mais 1,N car une réunion est constituée d’au moins un participant.




Cela dit, les PDF sont signés par les participants dans le cadre d’une réunion, aussi est-il préférable de transformer l’association Constituer en entité-type, appelons celle-ci par exemple PRESENCE (ou PARTICIPATION, ou tout autre nom qui convienne) :



Notez les parenthèses qui encadrent les cardinalités 1,1 : ce procédé dit d’identification relative (repris par JMerise), permet de faire hériter par l’entité-type PRESENCE les identifiants des entités-types REUNION et PARTICIPANT. Concrètement, cela veut dire qu’au niveau tabulaire, on aura le système suivant :

 
REUNION {rId}                        PARTICIPANT {pId}
          R1                                       P1
          R2                                       P2
          R3                                       P3
         ...                                       P4
                                                   P5
                                                  ...

PRESENCE {rId, pId}
           R1   P1
           R1   P3
           R2   P1
           R2   P4
          ...  ...

Et l’on verra plus loin l’intérêt de cette structure.

Concernant les PDF, vous avez défini une bijection entre REUNION et PDF de synthèse : REUNION phagocyte ce dernier, et à moins d’arguments montrant que cette absorption ne convient pas, pour le moment on restera là.

On peut définir une entité-type PDF de cette façon :





L’entité-type PDF est identifiée relativement à l’entité-type REUNION, ce qui permettra la propagation de l’attribut rId.

PDF_DEBUT et PDF_FIN sont des entités-types particulières, elles sont des sous-types de l’entité-type PDF : un PDF_DEBUT est un PDF, un PDF_FIN est un PDF (et un PDF est soit un PDF_DEBUT, soit un PDF_FIN). Ces sous-types héritent des propriétés de PDF et sont exclusifs (cf. la croix dans la lunule). La lunule est soulignée, ce qui traduit une contrainte de totalité : il n’y a pas d’autres sous-types que les deux évoqués. Exclusion + totalité = partitionnement (comme disait Pierre Dac « Le monde des uns n’est pas celui des autres, bien que le monde des uns et des autres soit le monde de tout le monde. »)

Exemple :

 
REUNION {rId}                        PDF {rId, fId}
          R1                               R1    1
          R2                               R1    2
          R3                               R2    1
         ...                               R2    2
                                           R3    1
                                           R3    2
                                          ...  ...

PDF_DEBUT {rId, fId}           PDF_FIN {rId, fId}
            R1    1                      R1    2
            R2    1                      R2    2
            R3    1                      R3    2
           ...  ...                     ...  ...

Vous pouvez subodorer qu’on va établir un lien entre les entités-types PDF_DEBUT et PRESENCE d’une part et PDF_FIN et PRESENCE d’autre part. Ce à quoi on pourra parvenir au niveau tabulaire :

 
PRESENCE {rId, pId}
           R1   P1
           R1   P3
           R2   P1
           R2   P4
          ...  ...


PDF_DEBUT {rId, fId}           PDF_FIN {rId, fId}
            R1    1                      R1    2
            R2    1                      R2    2
            R3    1                      R3    2
           ...  ...                     ...  ...

PRE_DEB {rId, pId, fid}       PRE_FIN {rId, pId, fid}
          R1   P1    1                  R1   P1    2
          R1   P3    1                  R1   P3    2
         ...  ...  ...                 ...  ...  ...

L’intérêt du procédé n’est pas mince, en effet il devient impossible qu’un participant signe des documents relatifs à des réunions auxquelles il n’a pas participé.

J’ai au chaud un MCD plus complet, mais je vous laisse d’abord réfléchir et faire vos observations sur ce qui précède, peut-être ai-je omis des points touchant aux règles de gestion des données (je n’ai pas tout lu point par point...) De la discussion jaillira la lumière...

Bon courage, ne baissez pas les bras !

[escartefigue]

Je vois que le sujet est entre de bonnes mains

[fsmrel]

Taxable,

Je suppose que vous êtes en train de vous poser quelques questions...

Je joins un MLD (modèle logique des données)



Avec les remarques et rappels suivants :

Le PDF original et le PDF de synthèse (~ PDF original complété) ne sont pas modélisés, dans la mesure où ils sont absorbés par l’entité-type REUNION. Au besoin, on pourra mettre une entité-type ad-hoc.

Maintenant pour parler tables :

Table PRESENCE

PRESENCE est une table « associative », ayant pour attributs rId et pId, hérités respectivement des tables REUNION et PARTICIPANT.
La table PRESENCE a pour clé {rId, pId}, ceci est symbolisé dans le MLD par le mickey « pk » (primary key).
Le mickey « fk1 » symbolise le fait que {rId} est une clé étrangère (foreign key) référençant la clé primaire {rId} de la table REUNION : chaque valeur prise par l’attribut rId de la table PRESENCE est obligatoirement une valeur prise préalablement par l’attribut rId de la table REUNION.
Le mickey « fk2 » symbolise le fait que {pId} est une clé étrangère référençant la clé primaire {pId} de la table PARTICIPANT : chaque valeur prise par l’attribut pId de la table PRESENCE est obligatoirement une valeur préalablement prise par l’attribut pId de la table PARTICIPANT.
Le mickey <pk,fk1> se lit donc ainsi : l’attribut rId appartient à la clé primaire {rId, pId} de la table PRESENCE et à la clé étrangère {rId} référençant la clé primaire {rId} de la table REUNION.
A son tour, le mickey <pk,fk2> se lit ainsi : l’attribut pId appartient à la clé primaire {rId, pId} de la table PRESENCE et à la clé étrangère {pId} référençant la clé primaire {pId} de la table PARTICIPANT.

Pour mémoire, l’utilisation des accolades « { » et « } » signifie que {rId, pId}, {rId}, {pId} sont des ensembles (de noms d’attributs) au sens de la théorie des ensembles, plus précisément des sous-ensembles de l’en-tête de la table (en-tête : ensemble des noms des attributs de la table).


Table PDF

Au niveau conceptuel l’entité-type PDF est ce qu’on appelle une entité-type faible (weak entity-type), pat opposition par exemple à l’entité-type REUNION considérée comme (plus) forte : PDF dépend viscéralement de REUNION : un PDF ne peut pas exister indépendamment d’une réunion. A noter que l’entité-type REUNION peut en même temps être considérée comme faible par rapport à une autre entité-type, PRESTATION en l’occurrence (que je n’ai pas fait figurer dans le modèle, afin de ne pas surcharger celui-ci).
Au niveau du MLD, la table PDF a pour attributs rId et fId, le 1er étant hérité de REUNION, tandis que le second complète la clé puisqu’une réunion peut faire l’objet de plus d’un PDF. La table a pour clé primaire la paire {rId, fId} et pour clé étrangère le singleton {rId}.


Table PDF_DEBUT

Comme on l’a déjà vu, au niveau conceptuel l’entité-type PDF_DEBUT est un sous-type de l’entité-type PDF. Par définition, cela veut dire qu’au niveau MLD, la table PDF_DEBUT a pour clé primaire la paire {rId, fId} héritée de PDF, paire qui est en même temps clé étrangère référençant la clé primaire {rId, fId} de la table PDF.


Table PDF_FIN

Même principe que pour la table PDF_DEBUT.


Table PRE_DEB

La table PRE_DEB joue un rôle clé. C’est une table associative, elle permet d’établir un lien entre PDF_DEBUT et PRESENCE. Comme toute association, elle hérite automatiquement des attributs composant la clé primaire {rId, fId} de la table PDF_DEBUT, ainsi que des attributs composant la clé primaire {rId, pId} de la table PRESENCE : en toute logique, la table PRE_DEB hérite de 4 attributs (c'est-à-dire deux fois de rId, une 1re fois du fait de l’association avec PDF_DEBUT, une 2e fois du fait de l’association avec PRESENCE. En renommant ses attributs pour éviter les doublons, l’en-tête de la table PRE_DEB pourrait ressembler à ceci :

{rId_pdf, fId, rId_presence, pId}

Autrement dit, on peut tricoter un PDF d’une réunion avec une présence d’un participant à une réunion qui n’a rien à voir. Mais comme en l’occurrence tel n’est pas le cas, c'est-à-dire qu’on doit vérifier {rId_pdf} = {rId_presence}, pour assurer la contrainte, il suffit de passer un coup de rasoir d’Ockham, c'est-à-dire ramener l’en-tête de la table PRE_DEB à :

{rId, pId, fId}

Et désormais le participant qui signe un PDF participe nécessairement à la réunion à laquelle est rattaché ce PDF.

Toujours pour ne pas surcharger le modèle, je n’ai considéré que le cas ou les PDF à signer par les participants sont du genre « pièce individualisée » (un seul signataire), voire « pièce commune » (cas à voir de plus près).
En l’occurrence, la clé primaire de la table PRE_DEB est la suivante (l’attribut fId n’a pas à y participer) :

{rId, pId}

Au besoin, cas du genre « pièce originale », on pourra affiner le MCD en sous-typant PDF_DEBUT en PDF_DEBUT_MONO (pdf signé par un seul participant de la réunion) et en PDF_DEBUT_MULTI (pdf signé par plus d’un participant de la réunion). A partir de là, la table PRE_DEB se dédouble en PRE_DEB_MONO et PRE_DEB_MULTI, de clé primaires :

{rId, pId} pour PRE_DEB_MONO ;

{rId, pId, fId} pour PRE_DEB_MULTI.

Table PRE_FIN

Même principe que pour la table PRE_DEB.


A suivre...

[fsmrel]

Je vois que le sujet est entre de bonnes mains

En tout cas, le sujet est intéressant

[Taxable]

Bonjour,
J'ai pris un peu de temps pour répondre, mais je vois que vous avez apporté des réponses supplémentaires,
Un grand merci à escartefigue et fsmrel pour vos contributions.


Je réponds quand même à comme suit à la première série :


* PRE_02 : Une prestation appartient à une et une seule tablette ( ! ou plusieurs tablette !! )
Corriger : supprimer la partie qui ne va pas.
*** Réponse :
Les tablettes étant interchangeables, la prestation est portée par un ensemble de tablette (qui ne se 'connaissent' pas entre elles). Donc, une Prestation appartient à une et une seule tablette


* Une tablette possède un identifiant unique (issu de la plateforme web)
Un rappel important : ça n’est pas votre propre application qui maîtrise cet identifiant, en conséquence de quoi vous devez le considérer comme identifiant alternatif
*** Réponse :
En effet, les Identifiants issues de la plateforme Web ne sont pas des identifiants pour l’application, mais un simple rappel de la valeur de l’identifiant présente dans les bases de la plateforme web. Cette valeur nous sera utile lors du rapatriement des données contenus dans la tablette vers le web. La terminologie WebIdTablette est parfaite

*Appelons-le par exemple idTabletteWeb
*** Le Préfixe pouvant prêter à confusion, je préfère la notation WebIdTablette.

*Contrainte d’égalité
Votre MCD comporte une contrainte d’égalité portant sur les associations A SIGNER : il faudrait justifier, expliciter les motifs de cette contrainte.
(…)
Vous signalez par ailleurs : « contrainte de relation = OU ». Voulez-vous signifier qu’il faut lire non pas « = », mais « OU » ? Si oui, ce « OU » est-il, inclusif ? exclusif ?
*** Réponse :
J’ai utilisé la contrainte ‘=’, car je ne savais pas comment la changer dans JMerise. Chose faite maintenant : Je l’ai remplacé ‘=’ par le symbole ‘+’ correspondant à une contrainte de partition (couverture et disjonction).
La justification de la contrainte OU Exclusif est la suivante :
Pour une Réunion composée de 1 à N Participant, il y a au minimum UN pdf-original.
Ce PDF-Original est affecté soit
- à une Réunion dans cas d’un pdf-original non personnalisé (pdf unique et commun =’’feuillle sous forme de tableau de nom’’ et ’’feuille photocopiée’’),
- à un Participant dans le cas de pdf-original nominatif (autant de pdf que de participant).
En conséquence, j’ai indiqué une cardinalité 0,N pour la relation Pdf(original)-Réunion et une cardinalité 0,N pour la relation Pdf(original)-Participant. Mais il faut une relation avec une cardinalité de 1,N pour la relation Réunion-PDF -- OU EXCLUSIF-- pour la relation Participant-PDF
Aussi, j’ai porté cette contrainte uniquement sur la relation ‘A SIGNER’ correspondant au PDF-Original, car c’est le point d’entrée. Je n’ai pas mis de contrainte sur la relation ‘SIGNER’ car la contrainte découle, à mon sens, de celle portée par la relation ‘A SIGNER’. Autrement dit, je pense que si la contrainte est respectée pour le PDF-Original, alors elle devrait être respectée pour le PDF-Signé.
Par ailleurs, je précise pour une bonne compréhension du sujet, qu’un Pdf-Original commun (un exemplaire à photocopier) est associé à une Réunion, alors que les Pdf-Signé résultant de ce Pdf-Original, seront affecté aux participants et non pas à la Réunion. Ce pdf signé devant ‘nominatif à l’issue de la signature’.


*Associations non binaires
L’association VALIDER (…) c'est-à-dire que le participant n’a a priori rien à voir avec la réunion, le PDF et le résultat, que la réunion n’a a priori rien à voir avec le participant, le PDF et le résultat, etc.
On reviendra plus tard sur ce point.
*** Réponse :
Oui même pour moi le sujet n’ai pas clair, j’avais envisagé de mettre des tables intermédiaires, mais ça faisait un peu complique, alors j’ai simplifié. Mais je crois deviner que ce problème pourra être levé avec les aménagements de MCD que vous me proposés.


* Aménagement du MCD
La patte d’association connectant l’entité-type REUNION et l’association Constituer n’est pas porteuse d’une cardinalité 1,1 mais 1,N car une réunion est constituée d’au moins un participant.
*** Réponse :
Dans ma description, j’avais indiqué « (a)Un même participant qui assiste à deux réunions différentes aura deux identifiants différents. Nous ne ‘traçons’ pas les individus. »
Par conséquent j’ai mis une cardinalité 1,1


* DIAGRAMME
Avec l’ensemble des remarques, Ainsi que les remarques du second mail, j’ai modifié le MCD comme suit.

J'espère ne pas être trop loin de la vérité.
Je trouve mon MCD plus élaboré par rapport à mon premier schéma.

Bonne journée et weekend.

[fsmrel]

Bonsoir Taxable,

Je poursuis avec mes observations et suggestions, toujours en faisant abstraction de RESULTAT : on en parlera quand le reste sera d’équerre.

Les tablettes étant interchangeables, la prestation est portée par un ensemble de tablettes (qui ne se 'connaissent' pas entre elles). Donc, une Prestation appartient à une et une seule tablette.

Le distinguo apporté par l’emploi des verbes « appartenir » et « porter » cache-t-il quelque chose justifiant cette déduction ? A défaut, bruts de décoffrage, les énoncés suivants sont contradictoires :

« la prestation est portée par un ensemble de tablettes »

« une Prestation appartient à une et une seule tablette »

Qu’en est-il ?

Le Préfixe pouvant prêter à confusion, je préfère la notation WebIdTablette.

Bien entendu, utilisez la notation qui vous convient.

Il lui est proposé un document dénommé ‘présence’ regroupant deux feuilles, l’une relatif à son heure d’arrivée et l’autre relatif à son heure de départ.

Dans les digrammes que j’ai présentés, j’ai considéré que les termes « feuille » et « PDF » étaient synonymes. Manifestement ce n’est pas le cas, ce seraient plutôt les termes « document » et « PDF » qui le sont, puisqu’un document regroupe deux feuilles. J’évacue donc les sous-entités-types PDF_DEBUT et PDF_FIN, ce qui fait que mes diagrammes ne valent plus, je remets les compteurs à zéro.

Cela dit, comment prenez-vous en compte les heures d’arrivée et de départ ? Au moyen par exemple d’attributs affectés à l’entité-type PDF ? (par parenthèses, du point de vue conceptuel, l’entité-type PDF pourrait être renommée DOCUMENT, car un PDF est un support particulier ( connotation technique) pour un document ; la notion de document se situe à un niveau d’abstraction plus élevé, mais c’est vous qui voyez...)


PDF et signature

Pour éviter les ambiguïtés, je vais distinguer vos deux associations A_SIGNER_ORIGINAL. Soit A_SIGNER_ORIGINAL_R l’association qui connecte les entités-types REUNION et PDF, et soit A_SIGNER_ORIGINAL_P celle qui connecte les entités-types PARTICIPANT et PDF.

Pour la même raison, je distingue les deux associations SIGNER. Soit SIGNER_R celle qui connecte les entités-types REUNION et PDF, et soit SIGNER_P celle qui connecte les entités-types PARTICIPANT et PDF.

Dans votre MCD précédent, l’entité-type PDF et l’association A_SIGNER_ORIGINAL_R sont connectées par une patte d’association porteuse d’une cardinalité 1,1 : ainsi, quelle que soit sa nature (original commun, original nominatif, signé commun, signé nominatif), tout document est donc signé par un intervenant (l’animateur ? Un participant ?) de la réunion à laquelle fait référence ce document (y-compris dans le cas des pièces individualisées). J’ai des doutes ! Il est étrange qu’un participant signe un document original non personnalisé...

De même, l’entité-type PDF et l’association A_SIGNER_ORIGINAL_P sont connectées par une patte d’association porteuse d’une cardinalité 1,1, on arrive à nouveau à des situations embarrassantes. Même remarque concernant les liens unissant l’entité-type PDF et les associations SIGNER_P et SIGNER_R.


A propos de la contrainte de partitionnement

Votre contrainte de partitionnement exprime effectivement la règle selon laquelle un document original à signer est associé soit à une réunion, soit à un participant, mais cette contrainte est en contradiction avec les cardinalités 1,1 portées par les pattes d’association connectant d’une part PDF et A_SIGNER_ORIGiNAL_R et d’autre part PDF et A_SIGNER_ORIGiNAL_P. Clairement, les cardinalités 1,1 que je viens d’évoquer sont à remplacer par des cardinalités 0,1. Je vous invite à examiner la figure 7.32 dans l’ouvrage de référence Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001).

Je n’ai pas mis de contrainte sur la relation ‘SIGNER’ car la contrainte découle, à mon sens, de celle portée par la relation ‘A SIGNER’. Autrement dit, je pense que si la contrainte est respectée pour le PDF-Original, alors elle devrait être respectée pour le PDF-Signé.

Eh bien non... Selon votre MCD, rien n’interdit que le même document F1 fasse référence à une réunion R1 via l’association SIGNER_R et à un participant P1 via l’association SIGNER_P. Pire, toujours selon votre MCD le participant P1 peut lui-même faire partie d’une réunion qui n’a rien à voir :

 
REUNION {rId}                   PARTICIPANT {pId}           PDF {fId} 
          R1                                  P1                  F1
          R2                                  P2                  F2

       CONSTITUER {rId, pId}
                    P1   R2
                    P2   R1

    SIGNER_R {rId, fId}              SIGNER_P {pId, fId}
               R1   F1                          P1   F1
                  

Pour remédier à tout cela, il faudra spécialiser l’entité-type PDF (voir ci-dessous), comme je l’avais fait ici.


Association CONSTITUER

Dans votre tout 1er MCD, l’entité-type PARTICIPANT et l’association CONSTITUER sont connectées par une patte d’association porteuse d’une cardinalité 1,N, ce qui, en Merise signifie formellement qu’un participant assiste à au moins une réunion, ce qui dans le cas général n’est pas aberrant.

Mais vous avez écrit « Un même participant qui assiste à deux réunions différentes aura deux identifiants différents », ce qui, en Merise, signifie qu’un participant assiste à au moins et au plus une réunion, ce qui a pour conséquence que les entités-types PARTICIPANT et PRESENCE que j’ai mises en oeuvre n’en font qu’une. Dont acte, on peut donc éliminer PRESENCE et revenir à votre 1er MCD, mais en y permutant les cardinalités :



(rId et idReunion sont synonymes, même chose pour pId et idParticipant).


Spécialisation de l’entité-type PDF

Voyez le paragraphe « Types et sous-types d’entités : spécialisation/généralisation » (page 106) dans l’ouvrage de référence Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001).

Pour respecter un maximum de contraintes au stade du MCD, le mieux est d’en passer par la spécialisation de l’entité-type PDF. Par exemple :




Je rappelle que les sous-types héritent des surtypes. Ainsi, PDF_NON_PERSONNALISE et PDF PERSONNALISE sont des sous-types de PDF et héritent des propriétés de ce dernier (y-compris l’identifiant, qu’on omet donc dans les sous-types). De même, PDF_NON_PERSONNALISE_ORIGINAL et PDF_NON_PERSONNALISE_SIGNÉ sont des sous-types de PDF_NON_PERSONNALISE (un sous-type peut jouer le rôle de surtype) et héritent des propriétés de ce dernier (donc transitivement des propriétés de PDF).

Je rappelle aussi que les sous-types sont partitionnés (cf. la croix et le souligné dans la lunule) : un document ne peut pas être à la fois personnalisé et non personnalisé, etc.

Maintenant, si les documents non personnalisés sont à attacher à une réunion, qu’ils soient originaux ou signés, on établit l’ association qui va bien :




Si pour une réunion on a au moins et au plus deux documents non personnalisés (un original et un signé), la cardinalité 1,N portée par la patte connectant l’entité-type REUNION et l’association PDF_NP_R peut être remplacée par 2,2.

La patte d’association connectant l’entité-type PDF_NON_PERSONNALISE et l’association PDF_NP_R est ici porteuse d’une cardinalité 1,1. Maintenant, vous pouvez affiner dans la mesure où, dans le cas des documents signés, la cardinalité 1,1 serait à remplacer par une cardinalité 0,1 (bien que selon votre MCD tel n’est pas le cas). Dans ces conditions, le diagramme pourrait devenir le suivant :




Ou le suivant, mais moins bétonné :





Dans les deux cas, on met en évidence une bijection entre les entités-types REUNION et PDF_NON_PERSONNALISE_ORIGINAL, ce qui veut dire que la 1re peut absorber la 2e.

Documents photocopiés

Je ne suis pas sûr d’avoir compris exactement de quoi il en retourne, donc pour le moment je ne propose rien. Quelle est votre vision précise de ces documents ?

Documents personnalisés (nominatifs)

Pour les documents nominatifs, je verrais bien quelque chose d’analogue à ce qui précède :




A suivre...


P.-S. N’hésitez pas à utiliser la balise QUOTE pour vos citations.

[Taxable]

Bonjour,
Nous avons eu une petite réunion ce jour et il y a deux petits changements qui devraient un peu nous faciliter la tâche.
- La cardinalité des entités Réunion-PDF est modifié en O,N (au lieu de 1,N). Car une Réunion peut avoir lieu sans qu’une signature ne soit exigée. Donc une réunion sans fichier pdf. La tablette permettra dans ce cas, de noter les présences : présent et absent.
- La notion de PDF de synthèse est passée à la trappe ! La raison évoquée est la suivante : une réunion pouvant utiliser deux tablettes, les participants se répartissant sur les deux tablettes. Alors, on a pour chaque tablette qu’une ‘partie’ des participants et donc un fichier de synthèse parcellaire.
La solution est donc de remonter au niveau Web l’ensemble des fichiers signés qui seront alors synthétisés en un fichier unique le fameux pdf-synthèse.

Envoyé par Taxable
Les tablettes étant interchangeables, la prestation est portée par un ensemble de tablettes (qui ne se 'connaissent' pas entre elles). Donc, une Prestation appartient à une et une seule tablette.
Le distinguo apporté par l’emploi des verbes « appartenir » et « porter » cache-t-il quelque chose justifiant cette déduction ? A défaut, bruts de décoffrage, les énoncés suivants sont contradictoires :
« la prestation est portée par un ensemble de tablettes »

« une Prestation appartient à une et une seule tablette »

Qu’en est-il ?

La réponse la plus exacte est « la prestation est portée par un ensemble de tablettes »

Envoyé par Taxable
Il lui est proposé un document dénommé ‘présence’ regroupant deux feuilles, l’une relatif à son heure d’arrivée et l’autre relatif à son heure de départ.
Dans les digrammes que j’ai présentés, j’ai considéré que les termes « feuille » et « PDF » étaient synonymes.

Oui, cette formulation est correcte, elle est conforme à ce que j’ai indiqué dans mon premier document : « Une « feuille » de présence est un matérialisé par un fichier PDF (feuille = fichier pdf), un document est un regroupement de fichier PDF. »

Manifestement ce n’est pas le cas, ce seraient plutôt les termes « document » et « PDF » qui le sont, puisqu’un document regroupe deux feuilles. J’évacue donc les sous-entités-types PDF_DEBUT et PDF_FIN, ce qui fait que mes diagrammes ne valent plus, je remets les compteurs à zéro.

Non, …

Cela dit, comment prenez-vous en compte les heures d’arrivée et de départ ? Au moyen par exemple d’attributs affectés à l’entité-type PDF ?

Oui, dans le cas où l’on a deux fichiers pdf, c’est l’administrateur de la tablette qui désigne le pdf du début et le pdf de fin.
Fonctionnellement, au départ les deux pdf ont un attribut ‘début’ (par défaut) l’animateur de la réunion peut décider de modifier (ou pas) l’attribut de l’un des deux fichiers par ‘fin’. Cette sélection se fait à la discrétion de l’animateur au regard de la teneur des documents à signer.

(par parenthèses, du point de vue conceptuel, l’entité-type PDF pourrait être renommée DOCUMENT, car un PDF est un support particulier (connotation technique) pour un document ; la notion de document se situe à un niveau d’abstraction plus élevé, mais c’est vous qui voyez...)

Pour moi PDF était le terme le plus simple et évident, mais pas tout à fait exact. Le terme le plus approprié est bien « DOCUMENT », car au niveau de la réunion il y a bien un document (regroupement de plusieurs pdf) à signer et non pas une série de pdf ....



PDF et signature

Pour éviter les ambiguïtés, je vais distinguer vos deux associations A_SIGNER_ORIGINAL. Soit A_SIGNER_ORIGINAL_R l’association qui connecte les entités-types REUNION et PDF, et soit A_SIGNER_ORIGINAL_P celle qui connecte les entités-types PARTICIPANT et PDF.

Pour la même raison, je distingue les deux associations SIGNER. Soit SIGNER_R celle qui connecte les entités-types REUNION et PDF, et soit SIGNER_P celle qui connecte les entités-types PARTICIPANT et PDF.

Dans votre MCD précédent, l’entité-type PDF et l’association A_SIGNER_ORIGINAL_R sont connectées par une patte d’association porteuse d’une cardinalité 1,1 : ainsi, quelle que soit sa nature (original commun, original nominatif, signé commun, signé nominatif), tout document est donc signé par un intervenant (l’animateur ? Un participant ?) de la réunion à laquelle fait référence ce document (y-compris dans le cas des pièces individualisées).
J’ai des doutes ! Il est étrange qu’un participant signe un document original non personnalisé...

Un fichier pdf peut être « non personnalisé » (original commun) mais comprendre une zone à renseigner ‘nom’, ‘prénom’, … que l’utilisateur complétera avec son stylo électronique. Et donc une fois signé deviendra le pdf deviendra « nominatif » (signé nominatif).
(PDF_NON_PERSONNALISE_ORIGINAL/2 se transforme en PDF_ PERSONNALISE_SIGNE)
En reprenant votre diagramme présenté plus bas, j’illustre avec des exemples les TROIS types de pdf-original que le participant pourrait signer et les DEUX types de fichiers-signés :


Par conséquent, je pense préférable d’introduire une troisième branche au diagramme, comme suit :



Aussi, dans le cadre d'une réunion. pour chaque
- PDF_NON_PERSONNALISE_UNIQUE_$$$ : il y a UN pdf original qui donne UN pdf signé pour l'ensemble des participants
- PDF_NON_PERSONNALISE_COMMUN_$$$ : il y a UN pdf original qui donne PLUSIEURS pdf signé c'est à dire autant que le nombre de participant présent.
- PDF_PERSONNALISE_COMMUN_$$$ : il y a PLUSIEURS pdf original (autant que le nombre de participant listé) qui donne PLUSIEURS pdf signé (autant que le nombre de participant présent)

Documents photocopiés
Je ne suis pas sûr d’avoir compris exactement de quoi il en retourne, donc pour le moment je ne propose rien. Quelle est votre vision précise de ces documents ?

Je voulais simplement exprimer un PDF_NON_PESONNALISE_COMMUN_ORIGINAL (voir ci-dessous).

J’ai fais l’impasse sur une partie de votre réponse (Spécialisation de l’entité-type PDF).
Je pense que les deux modifications présenté en début de post ont une incidence.

Bonne soirée.

[fsmrel]

Bonsoir Taxable,

J’ai l’impression que la mayonnaise commence à prendre, espérons qu’elle ne tournera pas trop vite...

Je pense que les deux modifications présenté en début de post ont une incidence.

Certes, mais dans la majorité des projets, les règles de gestion des données ont tendance à évoluer, toutefois il n’y a pas ici de révolution, donc je pense que tout va bien (pour le moment du moins !)

une Réunion peut avoir lieu sans qu’une signature ne soit exigée. Donc une réunion sans fichier pdf. La tablette permettra dans ce cas, de noter les présences : présent et absent.

Devez-vous modéliser la notification de la présence des participants dans le cas de ces réunions « sans PDF » ? Si oui, cela aura une incidence sur le MCD.

La notion de PDF de synthèse est passée à la trappe !
...
La solution est donc de remonter au niveau Web l’ensemble des fichiers signés qui seront alors synthétisés en un fichier unique le fameux pdf-synthèse.

Donc la patate chaude ne vous concerne plus, « C’est toujours ça d’pris, comme disait ma grand-mère »...

« Une « feuille » de présence est un matérialisé par un fichier PDF (feuille = fichier pdf), un document est un regroupement de fichier PDF. »

Si un document est un regroupement de fichiers PDF, alors l’entité-type DOCUMENT à renommer en PDF (ou FEUILLE) dans le diagramme ci-dessous car, du fait du sous-typage, il y est signifié qu’un document est un PDF non personnalisé unique, ou un PDF non personnalisé commun, ou un PDF personnalisé : merisement parlant, en aucun cas un document n’y est un regroupement de PDF.

je pense préférable d’introduire une troisième branche au diagramme, comme suit :

Bel effort ! D’accord. Toutefois, le sous-type PDF_NON_PERSONNALISE_COMMUN est ici un être hybride, du fait qu’il se comporte à la fois :

(a) Comme le sous-type PDF_NON_PERSONNALISE_UNIQUE (une réunion comporte au plus un PDF non personnalisé commun original) ;

(b) Comme le sous-type PDF_PERSONNALISE_SIGNÉ (si j’ai bien compris, chaque PDF commun est signé par un et un seul participant, et un participant en signe au plus un).

Dans ces conditions, on peut aussi envisager des variations, par exemple modéliser ainsi :




L’avantage est qu’on factorise. En effet, dans ce MCD :

— Il n’y a qu’une seule association entre les entités-types REUNION et PDF_NON_PERSONNALISE_ORIGINAL (au lieu d’une association entre les entités-types REUNION et PDF_NON_PERSONNALISE_UNIQUE_ORIGINAL, plus une association entre les entités-types REUNION et PDF_NON_PERSONNALISE_COMMUN_ORIGINAL) ;

— Il n’y a qu’une seule association entre les entités-types PARTICIPANT et PDF_PERSONNALISE_OU_COMMUN (au lieu d’une association entre les entités-types PARTICIPANT et PDF_NON_PERSONNALISE_COMMUN_SIGNÉ (que j’ai renommée PDF_COMMUN_SIGNÉ), plus une association entre les entités-types PARTICIPANT et PDF_PERSONNALISE_SIGNÉ).

La patte d’association connectant l’entité-type PARTICIPANT et l’association PDF_PAR est porteuse d’une cardinalité 0,2 : en effet, le participant P1 peut être concerné à la fois par le PDF personnalisé original F1 et le PDF personnalisé signé F2 (si j’ai bien compris).

La modélisation que je viens de présenter (sous réserve qu’elle satisfasse les règles de gestion des données, c'est-à-dire qu’elle soit fonctionnellement correcte !) a quand même un inconvénient :

Via l’entité-type PDF_NON_PERSONNALISE_ORIGINAL et l’association PDF_NP_O_R, une occurrence du sous-type PDF_NON_PERSONNALISE_UNIQUE_ORIGINAL_SIGNÉ peut faire référence à la réunion R1 et, via l’association PDF_NP_PAR, faire référence à la réunion R2, ce qui ferait désordre. Pour empêcher cette anomalie, il est préférable (de très loin) d’en passer par l’identification de l’entité-type PARTICIPANT relativement à l’entité-type REUNION (cardinalité 1,1 mise entre parenthèses) :



On pourra en reparler, une fois le MCD stabilisé et surtout lors du passage du MCD au MLD.

Le modèle que j’ai proposé fait aussi l’objet de l’alternative consistant à regrouper les sous-types qui sont en relation avec les participants (l’association PDF_PAR absorbe l’association PDF_NP_PAR) :



En passant, dans vos MCD, n’oubliez pas de faire figurer la contrainte de partitionnement XT dans les triangles de sous-typage.

Cela dit, comment prenez-vous en compte les heures d’arrivée et de départ ? Au moyen par exemple d’attributs affectés à l’entité-type PDF ?

Oui, dans le cas où l’on a deux fichiers pdf, c’est l’administrateur de la tablette qui désigne le pdf du début et le pdf de fin.
Fonctionnellement, au départ les deux pdf ont un attribut ‘début’ (par défaut) l’animateur de la réunion peut décider de modifier (ou pas) l’attribut de l’un des deux fichiers par ‘fin’.

Je ne perçois pas bien votre explication. Pour mieux m’éclairer, il serait bon que vous fournissiez les différents exemples de deux fichiers PDF pour chaque sous-type de votre MCD.

A vous revoir !

[Taxable]

Bonjour Fsmrel,
J’ai pris un peu de temps pour répondre, non pas par manque de temps, mais parce que je me suis ‘immergé’ pour essayer de comprendre les informations que vous m’avez fournis.
Je les trouve toute logique. La question que je me pose : d’où viennent ces idées ? de la pratique ou de l’apprentissage ? Pour moi, il y a une grande différence entre comprendre et faire !
Je ne perds pas ma motivation, le tunnel merise semble un peu plus long …

Devez-vous modéliser la notification de la présence des participants dans le cas de ces réunions « sans PDF » ? Si oui, cela aura une incidence sur le MCD.

Pour la gestion des présences, le sujet est plus vaste que je ne le pensais.
Je pense préférable de gérer les présences indépendamment des signatures. Dans la pratique, on pourrait avoir un participant présent, qui quitte une réunion en ‘oubliant’ de signer son (ses) pdf. L’information ‘présent’ est plus importante que l’information ‘à signer’.
Aussi, on a besoin de faire remonter la liste des présents à la partie web indépendamment des pdf, pour déclencher d’autres opérations sur la plateforme web. Je pensais au début, déduire cette liste de l’existence de pdf signé, erreur !
Par ailleurs, cela résout le cas réunion ou il y a seulement un ‘PDF_NON_PERSONNALISE_UNIQUE_ORIGINAL’ à signer. Le document généré est le PDF_NON_PERSONNALISE_UNIQUE_SIGNE qui est associé à la réunion, et aux participants. (Au passage, on peut très bien avoir par exemple 10 présents, mais que 9 signatures).

(…) merisement parlant, en aucun cas un document n’y est un regroupement de PDF.

Je viens de comprendre ! J’ai tendance superposé la syntaxe verbale de merise avec la syntaxe verbale du cas d’usage.
Oui, un ‘document’ est un ‘pdf’, sans hiérarchie, pour merise. Je renomme l’entité-type en PDF.

PDF_NON_PERSONNALISE_COMMUN est ici un être hybride, du fait qu’il se comporte à la fois :
(a)Comme le sous-type PDF_NON_PERSONNALISE_UNIQUE (une réunion comporte au plus un PDF non personnalisé commun original) ;
(b) Comme le sous-type PDF_PERSONNALISE_SIGNÉ (si j’ai bien compris, chaque PDF commun est signé par un et un seul participant, et un participant en signe au plus un).

Oups, …
Les pdf ‘original’ et ‘à signer’ ne sont pas limités en nombre, il peut y en avoir de 0 à plusieurs et de n’importe quel type.
Aussi, il est difficile de dire à l’utilisateur de la plateforme web de se limiter dans le chargement de pdf pour chaque réunion.
Les cardinalités ne me semblent pas correspondre à mon besoin fonctionnel. Je vais refaire le diagramme demain avec ce que je pense être correcte.

La patte d’association connectant l’entité-type PARTICIPANT et l’association PDF_PAR est porteuse d’une cardinalité 0,2 : en effet, le participant P1 peut être concerné à la fois par le PDF personnalisé original F1 et le PDF personnalisé signé F2 (si j’ai bien compris).

Oui vous avez bien compris.

Je ne perçois pas bien votre explication. Pour mieux m’éclairer, il serait bon que vous fournissiez les différents exemples de deux fichiers PDF pour chaque sous-type de votre MCD.

Je prépare pour demain, deux pdf de chaque type.

Bonne soirée.

[Taxable]

Bonjour fsmrel,

Pour illustrer nos discutions, je joins en image des exemples masqués de feuilles de présences que les participants doivent signer, au début ou à la fin ou au cours de la réunion;

Bonne journée

--je les supprimerai dans quelques jours--

[fsmrel]

Bonsoir Taxable,

D’où viennent ces idées ? de la pratique ou de l’apprentissage ?

L’une ne va pas sans l’autre, en tout cas pour ce qu’il en est de la modélisation. La pratique doit être précédée de l’apprentissage, c'est-à-dire de la technique, c'est-à-dire la théorie. La pratique, je l’ai acquise au fil des décennies, en modélisant, en auditant, en soignant les bases de données malades, mais j’ai surtout commencé par étudier à fond les bons auteurs, à savoir Ted Codd (sa série d’articles, à commencer par son article fondateur A Relational Model for Large Shared Data Banks), Chris Date (par exemple son ouvrage An Introduction to Database Systems), c'est-à-dire que j’ai commencé par m’appuyer sur la théorie relationnelle avant de pratiquer, et bien m’en a pris. Evidemment, j’ai ensuite lu les auteurs merisiens pour voir comment bâtir des MCD, mais Merise est surtout une méthode, et elle ne donne pas la sûreté, que fournit la théorie relationnelle. Bref, j’ai des idées, venant de mon expérience, mais je les valide, les canalise en m’appuyant sur la théorie relationnelle, et je les traduis au besoin sous forme de MCD.

Gardons à l’esprit ce que chantait le poète (merci, Georges !) :

G. Brassens :

« Sans technique, un don n’est rien qu’un’ sal’ manie... »

Je pense préférable de gérer les présences indépendamment des signatures. Dans la pratique, on pourrait avoir un participant présent, qui quitte une réunion en ‘oubliant’ de signer son (ses) pdf. L’information ‘présent’ est plus importante que l’information ‘à signer’.

L’indépendance des notions de présence et de signature est de fait importante. Si Raoul et présent mais oublie de signer, il peut y avoir du PDF en moins. Je suppose que l’entité-type PARTICIPANT comportera un attribut permettant à l’animateur de confirmer la présence ou non des participants à la réunion. Qu’en est-il ?

Les pdf ‘original’ et ‘à signer’ ne sont pas limités en nombre, il peut y en avoir de 0 à plusieurs et de n’importe quel type.

Est-ce que pour une réunion donnée, disons R1, on peut avoir à utiliser plusieurs types de PDF non personnalisés originaux, disons F1, F2, F3 (correspondant tous à l’entité-type PDF_NON_PERSONNALISE_ORIGINAL) ? Si oui, la cardinalité 0,1 portée par la patte d’association connectant l’entité-type REUNION et l’association PDF_NP_O_R sera à remplacer par 0,N, sinon on laisse comme c’est (MCD du post #11).

[fsmrel]

Je prépare pour demain, deux pdf de chaque type.

Merci Taxable !

Pourriez-vous faire précéder chaque image du nom de l’entité-type à laquelle elle correspond ? (je m’emmêle un peu en regardant ces images...)