Discussion :

[DJMOUS]

Bonjour,

Je travaille actuellement sur le MCD de la gestion d'un centre de formation.

Le libellé est en pièce jointe? Quels sont les pièges?

Quelles sont les valeurs calculées?

Pour ma part, je vois 9 entités à savoir :

-> Stagiaire, Convocation, société, formateur, type de séminaire, session, commande, facture et planning type.

Merci pour vos réponses et votre aide.

[Soutou]

Et bien relie ces 9 entités entre elles, dispose tes attributs, trouve
un identifiant par entité, et renvoie un modèle qui fera réagir un lecteur.

[DJMOUS]

Bonjour,
Pouvez vous svp me donner votre avis sur le MCD en pièce jointe?
Merci

[DJMOUS]

Le MCD après quelques modifications...

Je vous remercie de me donner votre avis.

Cordialement.

[CinePhil]

Bonjour,
Sans avoir lu l'énoncé et un peu vite fait, quelques remarques...

1) Association "envoie"
Une convocation peut être envoyée par plusieurs sociétés ?

2) Boucles
Il y a il me semble plusieurs boucles dans ton MCD qui peuvent provoquer des incohérences de données.
Par exemple : une société A demande une inscription à une session. Cette demande est satisfaite par une commande qui génère une facture qui est envoyée à une société B !

[fsmrel]

Bonjour,

Par sécurité, je n’ouvre pas les .DOC., d’où le silence que j’ai observé.
Il faudrait que vous nous présentiez les règles de gestion des données ayant donné naissance à votre diagramme conceptuel, dessiner c’est bien mais ça ne suffit pas : on voit des noms de choses dont on subodore une signification qui n’est pas forcément celle que vous avez en tête (ANNEE par exemple). On voit des noms d’attributs (propriétés) dont on ne peut pas deviner le sens et le rôle.

Incidemment, on voit qu’une facture détermine une commande : très bien, mais une facture contient seulement une ligne de facture, ce qui est assez réducteur. Même réflexion concernant ANNEE : une année détermine une société : quel sens a alors l’entité-type ANNEE ?

Vous avez des associations-types porteuses de données alors qu’elles ont des pattes à cardinalités 1,1 : sémantiquement cela se justifie, mais les merisiens purs et durs n’aiment pas cela : si vous produisez un travail professionnel, pas de problème, si c’est un exercice scolaire, cela pourrait vous faire perdre des points.

Je passe le relais.

[DJMOUS]

Les règles de gestion sont en pièce jointe....

[fsmrel]

J'ai précisé plus haut que je n'ouvre pas les .DOC... Pourriez-vous recopier les règles dans un message ?

[DJMOUS]

Séminaire

Une société de service organise des séminaires pour des stagiaires appartenant à diverses sociétés. Les inscriptions se font toujours par l’intermédiaire de ces sociétés auxquelles les factures sont envoyées. Les cours sont dispensées par des formateurs en général extérieurs au centre.

La base de données envisagée devra permettre la mise en œuvre des applications suivantes (qu’elle devra alimenter en informations) :

 Gestion des séminaires (convocation des formateurs et des stagiaires), à l’exclusion de la gestion des salles.
 La gestion des demandes d’inscription (satisfaction de ces demandes dans la mesure du possible).
 La facturation des commandes (on entend par commande, une demande satisfaite, c'est-à-dire une inscription ferme pour une session donnée).
 Le suivi (statistique) des formateurs et des stagiaires.

Les principales règles de gestion du centre de formation sont :

 Deux séminaires de même type ne peuvent commencer à la même date.
 Toutes les sessions programmées sont bien réalisées.
 Un séminaire peut avoir lieu plusieurs fois : c’est toujours le même formateur qui assure le même type de séminaire, quelle que soit la date de la session (on considère que les problèmes de remplacement d’un formateur défaillant sont traités manuellement).
 Toutes les précautions sont prises sur les planning-types pour qu’un même formateur ne risque pas d’avoir deux séminaires à assurer en même temps.
 Une demande (d’inscription(s)) ne peut porter que sur un seul type de séminaire à la fois. Une société qui désire grouper les demandes d’inscriptions pour tout son personnel devra donc faire une demande par type de séminaire.
 Une commande ne peut porter que sur une seule session de séminaire à la fois (il ne peut exister de « commandes groupées »)
 Par contre, une même société peut effectuer, à des dates différentes, des demandes pour un même séminaire ou des commandes pour une même session.
 La convocation doit être envoyée individuellement à chaque stagiaire, elle doit faire référence à la commande dont elle est issue.
 Il doit y avoir une facture par commande.


Liste des rubriques que doit contenir la base de données (Dictionnaire de données) :
Code Intitulé
ADRFOR Adresse Formateur
ADRSOC Adresse Société
ANNSTA Année de naissance du stagiaire
CODSEM Code du séminaire
CODSOC Code de la société
COMSOC Nom du comptable de la société (facturation)
CORSOC Nom du correspondant formation de la société
CUMSOC Cumul des journée-élèves réalisées pour le compte de la société depuis le début de l'année
DATENV Date d'envoi de la convocation à un stagiaire
DATCOM Date de la commande
DATDEM Date de la demande
DATFAC Date de la facture
DATSEM Date du séminaire (session)
DURSEM Durée du séminaire (en jours)
GROFOR Groupe auquel appartient le formateur
MONFAC Montant de la facture
NBRCOM Nombre de places commandées
NBRDEM Nombre de places demandées
NBRFAC Nombre de personnes à facturer
NBRSOC Nombre de personnes employées dans la société
NBSFOR Nombre de séminaires dispensés par le formateur depuis le début de l'année
NIVFOR Niveau du formateur
NIVSEM Niveau du séminaire
NIVSTA Niveau du stagiaire
NOMFOR Nom du formateur
NOMSOC Nom de la société
NOMSTA Nom du stagiaire
NUMFAC Numéro de facture
NUMFOR Numéro de formateur
NUMSTA Numéro du stagiaire
PLASEM Nombre maximum de places offertes à un séminaire
PRISEM Prix du séminaire
PRNFOR Prénom du formateur
PRNSTA Prénom du stagiaire
RESSEM Nombre de places restantes à un séminaire

[fsmrel]

Bonsoir,


Votre association-type REÇOIT est ternaire, et signifie donc qu’un stagiaire reçoit une convocation et un formateur (sic !) : les convocations reçues par les stagiaires et celles qui sont reçues par les formateurs ne sont pas les mêmes, il doit donc y avoir deux associations-types binaires, une pour les convocations des stagiaires, une autre pour les convocations des formateurs.

Il existe la règle de gestion :

« Une commande ne peut porter que sur une seule session de séminaire à la fois »

Votre cardinalité 0,N portée par la patte connectant COMMANDE et DEMANDE SATISFAITE n’est donc pas conforme.
A l’inverse, selon votre diagramme, une session fait référence à une et une seule commande : si les stagiaires participant à une même session font partie de sociétés différentes, la ventilation des lignes de commande et de facture risque d’être intéressante...

Il y a pas mal de choses à dire, mais il est trois heures du matin.

A plus tard donc.

N.B. Si vous avez dix minutes, vous pouvez méditer l’exercice soumis par Laure94.

[fsmrel]

Bonsoir,


Si vous modélisez la finalité des choses, alors la patte connectant l’entité-type SEMINAIRE et l’association-type COMPORTE est porteuse d’une cardinalité 1,N plutôt que 0,N (tout séminaire a vocation a être suivi).

Selon votre représentation, tous les séminaires qui commencent à une date donnée sont censés commencer à la même heure :



Il est préférable que chaque séminaire ait son propre calendrier et qu’il ne commence pas forcément toujours à la même heure :



Exemples de valeurs au niveau logique (PLANNINGTYPE n’a plus d’utilité et disparaît) :

Code :

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

1
2
3
4
5
SEMINAIRE {CODSEM, ...}     DEBUTE {CODSEM,   DATE,         HEURE}
                1                        1    14/03/2011    08:30
                1                        1    07/11/2011    09:00
                1                        1    19/12/2011    09:00
                2                        2    09/11/2011    09:30

Maintenant, si l’on observe la structure de l’en-tête de l’entité-type SESSION, on voit que vous y avez fait figurer les attributs DATSEM (date de début de session) et HEUREDEBUTSESSION (heure de début de session) : il y a redondance avec le planning que l’on vient de voir : au nom du rasoir d’Ockham, soit on évacue de SESSION les attributs DATSEM et HEUREDEBUTSESSION, soit l’association-type Débute disparaît (absorbée par SESSION) : on va plutôt faire disparaître l’association-type.

De la même façon, vous dites deux fois qu’une session a lieu a telle date (attribut DATSEM de l’en-tête de SESSION d’une part, association-type Est_planifiée d’autre part) : on passe un coup de rasoir et l’association-type disparaît.

A ce stade, cette partie du diagramme devient la suivante (rappel : PLANNINGTYPE l’entité-type disparaît, ainsi que les associations-types Débute et Est_planifiée) :




Demandes d'inscription : dans la mesure où pour une session on n’a pas encore reçu de demandes d’inscription, il est préférable de remplacer la cardinalité 1,N par 0,N (patte connectant SESSION et Demande_d’inscription).

Commandes : Il existe la règle suivante

« Une commande ne peut porter que sur une seule session de séminaire à la fois »

Comme par ailleurs les sessions peuvent comporter des stagiaires venant de sociétés différentes, la modélisation devient la suivante concernant la relation entre les commandes et les sessions :



L’attribut LIGNE COMMANDE a disparu puisqu’une commande n’a finalement qu’une seule ligne dont on connaît par ailleurs les éléments (libellé, montant unitaire, quantité).

Selon votre diagramme, on ne sait pas déterminer la société qui a passé commande (CinePhil vous l’a fait remarquer) : on définit l’association-type qui va bien entre les entités-types SOCIETE et COMMANDE (PasserCommande).

Concernant la facturation, il existe la règle de gestion :

« Il doit y avoir une facture par commande. »

A noter que l’association-type Expédie est redondante puisqu’on sait l’inférer (FACTURE détermine COMMANDE qui détermine SOCIETE) : un coup de rasoir.

Le diagramme devient le suivant (pour des raisons de confort, j’ai provisoirement changé les noms des attributs et ne les ai pas tous fait figurer) :



On regardera la suite plus tard. Par mégarde, je me suis peut-être planté quelque part, mais CinePhil ou tout autre fin observateur ne manquera pas d'apporter les corrections qui s'imposent.

[DJMOUS]

Bonsoir,

J'ai mis à jour le document avec les entités STAGIAIRE, CONVOCATION et FORMATEUR.

En revanche, je ne sais pas comment modéliser le CUMSOC (Cumul des journées par élèves) qui est pour moi une valeur calculée.

Merci pour vos lumières.

[fsmrel]

Bonsoir,


Le précédent diagramme que j’ai proposé devrait être aménagé ainsi pour signifier qu’à une date donnée, pour un type de séminaire il n’y a qu’une session :


La flèche symbolise une dépendance fonctionnelle, une contrainte {SEMINAIRE, DATE} -> {SESSION} selon laquelle pour une paire <séminaire, date> il n’y a qu’une session. Par ailleurs, on reparlera du « manque d’intérêt » des cardinalités 1,1 dans le cas des associations-types ternaires (Planifier en l’occurrence).

Une solution alternative consiste à utiliser l’identification relative (symbolisée par la mise entre parenthèses de la cardinalité 1,1) et dont on reparlera :




Dans la 2e version de votre MCD, on lit ceci : une occurrence de SEMINAIRE participe au moins une fois à l’association-type Dispense et une occurrence de FORMATEUR participe exactement une fois à l’association-type Dispense :



Votre cardinalité 1,1 ne laisse planer aucun doute (c’est la vertu du formalisme employé dans les diagrammes tels que les MCD) :

(1) « Un formateur donné F1 assure toujours le même type de séminaire S1 et ne peut donc pas assurer un autre type de séminaire S2 ».

Par ailleurs, il existe la règle suivante :

(2) « C’est toujours le même formateur qui assure le même type de séminaire ».

Mais sa lecture laisse planer un doute, conséquence du style de rédaction ambigu employé par l’auteur... Si on interprète (2) ainsi :

(3) « C’est toujours F1 qui assure S1 »

Cela veut dire que S1 est la chasse gardée de F1, donc qu’un 2e formateur F2 ne peut pas assurer S1 : dans le diagramme, la cardinalité 1,N est à remplacer par 1,1.

Peut-on faire dire à (2) :

(4) « F1 assure seulement S1 » ?

C'est-à-dire, ce qui revient à (1) :

(5) « Le formateur F1 assure toujours S1 et seulement S1 ».

Je ne sais pas ce qu’en pensent les experts de Merise, mais personnellement je donne un avis négatif, et j’estime qu’un formateur peut dispenser plusieurs types de séminaires. Le diagramme revient alors à sa situation initiale :



Pour appeler un chat un chat et ne pas laisser planer de doute (séminaire est plutôt synonyme de session si l’on se réfère à cette entrée du dictionnaire : « DATSEM Date du séminaire (session) »), j’ai renommé l’entité-type SEMINAIRE en TYPE_SEMINAIRE. Si je me suis planté, merci aux autres de rectifier.
A noter que l’attribut NBSFOR a migré dans l’en-tête de l’entité-type FORMATEUR. On verra plus tard s’il peut être calculé (attention aux défaillances des formateurs...)


Convocations des stagiaires :

Selon votre diagramme, ce sont les sociétés (clientes) qui envoient les convocations aux stagiaires : en fait, c’est le centre de formation qui le fait. En plus, une règle de gestion dit que la convocation doit faire référence à la commande. Il faut donc modéliser les choses ainsi (une commande concerne au moins un stagiaire et un stagiaire a été concerné au fil du temps par au moins une commande, c'est-à-dire au moins une session) :




Le tout est qu’une convocation relative à une commande de la société S1 n’arrive pas chez un stagiaire de la société S2. Il y a une contrainte qu’on verra plus tard.


Convocation des formateurs :

Selon votre diagramme, les formateurs sont convoqués par les clients. En fait, on va conserver ainsi la trace des envois :



A une date donnée, on envoie à un formateur une convocation pour seulement une session.


N.B. Vu la règle de gestion : « Toutes les sessions programmées sont bien réalisées. », dans le diagramme conceptuel, on devrait donc remplacer la cardinalité 0,N par 1,N pour la patte connectant l’entité-type SESSION et l’association-type Demande_satisfaite.

Pour le reste, on verra plus tard. Pour pallier l'absence de certaines règles de gestion, j'ai pris des initiatives qui peuvent être rendues nulles et non avenues si de meilleures propositions sont faites.

Bonne journée et bon courage...

[fsmrel]

Bonsoir,


Avant de poursuivre, il n’est pas inutile de voir un peu ce qui se passe au stade post conceptuel, dans la soute, à savoir au niveau logique (disons tabulaire).

Allons-y pour une observation concernant l’identification des entités-types. Considérez le diagramme conceptuel suivant :



L’entité-type SOCIETE est identifiée au moyen de l’attribut CodeSociete (CODSOC dans votre diagramme). A un moment donné, il faudra produire un diagramme logique à partir du diagramme conceptuel, avant de produire le code SQL décrivant la structure des tables composant la base de données. Ce diagramme est le suivant, où les rectangles symbolisent des tables :



Lors du passage du modèle conceptuel de données au modèle logique, les entités-types SOCIETE et COMMANDE donnent lieu à des tables (SOCIETE et COMMANDE), tandis que l’association-type PasserCommande donne lieu dans l’en-tête de la table COMMANDE à un attribut CodeSociete. La flèche connectant les tables symbolise ce que l’on appelle une contrainte référentielle impliquant les deux tables. L’attribut CodeSociete joue les rôles suivants (non exclusifs d’ailleurs) :

• Concernant la table SOCIETE, cet attribut représente la clé (appelons-la clé primaire, primary key) de la table SOCIETE, clé permettant de garantir le principe d’unicité (deux lignes de la table ne peuvent pas prendre la même valeur pour l’attribut CodeSociete).
• Concernant la table COMMANDE, l’attribut CodeSociete est astreint à respecter la contrainte référentielle selon laquelle les valeurs qu’il lui est permis de prendre sont obligatoirement des valeurs prises par l’attribut CodeSociete de la table SOCIETE. L’attribut CodeSociete représente ce qu’on appelle une clé étrangère (foreign key dénomination étrange, mais due à Ted Codd, père de la théorie relationnelle).

Dans le diagramme ci-dessus, la clé primaire {CodeSociete} est symbolisée par le mickey <pk> et la clé étrangère {CodeSociete} par le mickey <fk>.

Une règle de bonne modélisation : dans la base de données, les valeurs prises par l’attribut CodeSociete de la table SOCIETE devront être fournies par le système (par exemple au moyen du mécanisme d’auto-incrémentation, lequel est proposé par tous les SGBD). Il y a deux raisons à cela : un identifiant ne doit pas être porteur de sens et il doit être invariant.

A propos de l’absence de sens, je cite l’excellent Yves Tabourier qui écrivait il y a trente ans dans le contexte Merise (De l’autre côté de MERISE page 81) :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Considérez la recommandation de Tabourier comme une règle d’or qui n’a pas vieilli (Notez au passage que le terme « propriété » utilisé par Tabourier est interchangeable avec celui d’« attribut »).

Imaginez une table des automobiles pour laquelle l’identifiant serait constitué du numéro d’immatriculation selon l’ancien système français : que faire en cas de changement de ce numéro (suite à un changement de propriétaire) répliqué dans plusieurs tables ? Que faire lors du passage au nouveau système d’immatriculation ?


A propos de l’invariance : un attribut jouant le rôle d’identifiant ne doit pas changer de valeur. Je reprends l’exemple que j’utilise invariablement, avec lequel je me situe au niveau de la base de données, car c’est là que la patate chaude atterrit et que les drames se jouent :

Les concepteurs d’un projet d’une grande banque avaient retenu le numéro Siren des entreprises pour identifier celles-ci (attribut NoSiren de l’entité-type Entreprise). Au niveau de la base de données, par le jeu des liens inter-tables (clé primaire - clé étrangère), le numéro Siren se propageait dans de nombreuses tables. Or, ce numéro est fourni par l’INSEE, lequel envoyait tous les mois les correctifs modifiant le Siren des nouvelles entreprises (10% d’entre elles à peu près). Les concepteurs en avaient tenu compte et me montrèrent le modèle correspondant à la mise à jour des tables impliquées : une usine à gaz ! J’avais fait observer que, vu le nombre de tables touchées et leur volumétrie (plusieurs millions de lignes chacune), cela pouvait faire exploser la production informatique (batchs de nuit), du fait d’une activité de mise à jour excessive et en plus, délicate à ordonnancer. Sans que j'ai eu à le leur demander, les concepteurs définirent un nouvel attribut, non porteur de sens, artificiel (non significatif) et invariant, destiné à être l’attribut servant pour la clé primaire de la table Entreprise, propagé en conséquence dans les autres tables, en lieu et place de l’attribut NoSiren. A partir de là, modifier un numéro de Siren n’impactait plus que la seule table Entreprise, les utilisateurs ayant bien évidemment toujours accès au contenu de l’attribut NoSiren, servant pour une clé alternative (et n’ayant donc pas perdu sa propriété d’unicité).
Même si on admet que la structure du numéro SIREN a peu de chances d’évoluer en tant que tel, les corrections apportées avaient de quoi ficher la zoubia dans le système.

En ce qui vous concerne, suite à tout ce qui précède, si les valeurs prises par l’attribut CodeSociete peuvent être remplacées parce que l’utilisateur peut avoir besoin d’agir ainsi, alors il faudra définir un attribut supplémentaire (appelons-le IdSociete), non porteur de sens et invariant, qui servira pour la clé primaire de la table SOCIETE, tandis que l’attribut CodeSociete fera l’objet d’une clé alternative pour que soit respectée la règle d’unicité des clés.

Diagramme conceptuel :



(ai) signifie que CodeSociete est identifiant alternatif.


Diagramme logique dérivé :


Et si d’aventure il fallait aussi prendre en compte le numéro Siren des sociétés :


La table SOCIETE aurait pour clé primaire {IdSociete} et elle aurait pour clés alternatives {CodeSociete} et {NoSiren}.

N.B. Pour des raisons historiques, une table SQL ne peut avoir qu’une seule clé qui puisse être qualifiée de primaire. Ainsi, une seule des 3 clés de la table SOCIETE serait primaire, les autres étant alors alternatives, mais cela n’est absolument pas gênant.

[Shrek92]

Bonsoir,
Je dois moi aussi faire ce devoir et je souhaiterai proposer ma réponse.
J'ai travaillé de mon côté, puis suis tombé sur ce forum et la proposition de réponse de DJMOUS, et le travail fantastique d'explication que vous faite depuis lors.

Donc ci-dessous ma proposition. Je pense avoir respecté toutes les contraintes, mais je crains de ne pas avoir respecté le formalisme de représentation.

Merci de vos précieux commentaires.
Bien cordialement

PS: voici les quelques règles de gestion supplémentaires que j'ai définies:
• Un séminaire a toujours le même nombre de place
• Une demande est soit acceptée pour le nombre de places demandées soit refusée complètement
• Quand une demande est acceptée, elle est directement transformée en commande, pour le nombre de places demandées

[DJMOUS]

En regardant l'énoncé, il ne parle pas des convocations des formateurs.

De plus, je me pose des questions sur les valeurs calculées...

[Shrek92]

Bonsoir,
L'énoncé parle bien des convocations des formateurs. "Gestion des séminaires (convocation des formateurs et des stagiaires), à l'exclusion de la gestion des salles. "

DJMOUS, dans ton schéma, je crains que le seul moyen pour être salarié d'une entreprise est qu'elle passe commande d'un séminaire...

fsmrel, je comprends pas votre analyse de la partie demande-commande. Je ne vois pas comment la relation Demande_Satisfaite permet de transformer une demande en commande.
Pour moi (je reconnais que le texte permet plusieurs interprétations...) une société peut envoyer plusieurs demandes à l'organisme de formation (c'est dans l'énoncé). Ces demandes peuvent être soit acceptées (intégralement selon la règle de gestion que j'ai défini) soit refusées (intégralement selon la règle de gestion que j'ai définie).
Je considère qu'une société peut envoyer une ou plusieurs demandes pour la même session (c'est dit dans l'ennoncé). Ces demandes sont soit acceptées soit refusée. Il faut donc que la base soit capable de stocker les demandes qui sont rejetées et qui restent à l'état de demande, mais aussi les demandes qui sont acceptées et qui deviennent commandes. Elle deviennent d'ailleurs factures aussi car l'énoncé dit qu'il y a "une facture par commande".

Je vous joins donc ma proposition de schéma corrigée par rapport à ma première contribution. Après avoir lu l'article de ce site ftp://ftp-developpez.com/cyril-gruau/ConceptionBD.pdf, je me suis rendu compte que je pouvais allèger mon MCD, qu'il manquait des clés primaires et que les cardinalités étaient fausses.

Toujours grâce à cette lecture, j'ai une meilleure idée de comment passer du MCD au MLDR, et ça m'a aidé à corriger certaines erreurs.
Le MLDR correspondant à ma proposition est le suivant:
Stagiaire (NUMSTA, NOMSTA, PRNSTA, NIVSTA, ANNSTA, ADRSTA, #CODSOC)
Société (CODSOC, NOMSOC, NBRSOC, ADRSOC, CORSOC, COMSOC)
Formateur (NUMFOR, NOMFOR, PRNFOR, NIVFOR, GROFOR, ADRFOR)
Séminaire (CODSEM, DURSEM, NIVSEM, PLASEM, PRISEM, #NUMFOR)
Session (CODSES, RESSEM)
Demande (NUMDEM, NBRDEM, DATDEM, #CODSOC, #CODSES)
Commande (NUMCOM, NBRCOM, DATCOM, #NUMDEM, #NUMFAC)
Facture (NUMFAC, DATFAC, MONFAC, #NUMCOM)
Convocation (NUMCON, DATENV)
est_une_session_de (CODSEM, CODSES, DATSEM)
Est_inscrit (NUMSTA, NUMDEM)
génère_des (NUMFAC, NUMCON)

Mon MCD est probablement toujours pas bon, mais un peu moins faux peut être...
Ce qui me pose encore problème sont les deux rubriques statistiques:
* CUMSOC: Cumul des journées-élèves réalisées pour le compte de la société depuis le début de l'année
* NBSFOR: Nombre de séminaires dispensés par le formateur depuis le début de l'année
Je ne sais pas ou les placer. Dans mon premier MCD, mon idée de faire une entité Statistique me plaisait bien, mais je n'avais pas de clé primaire. Je peux en créer une incrémentée automatiquement à chaque commande, mais je ne suis vraiment pas sûr. Alors dans cette maj, j'ai carrément enlever ces deux rubriques pour l'instant, en attendant vos remarques.
Bonne soirée!

[fsmrel]

Bonsoir,

fsmrel, je comprends pas votre analyse de la partie demande-commande. Je ne vois pas comment la relation Demande_Satisfaite permet de transformer une demande en commande.

J’avais écrit : « on regardera la suite plus tard ». Je souhaitais d’abord traiter l’aspect planning et les contraintes temporelles qui en sont la conséquence : un formateur ne peut pas animer deux sessions en même temps. Il y a là un problème important, car pas toujours facile à modéliser au niveau conceptuel.

Je n’ai donc pas encore eu le temps de traiter l’implication des demandes par les commandes, mais cela dit, votre modélisation à cet égard paraît tout à fait correcte (mise en œuvre de l’entité-type DEMANDE). Par exemple, on pourrait se poser la question : Shrek92 respecte-t-il bien la règle suivante ?

« Une commande ne peut porter que sur une seule session de séminaire à la fois. »

La réponse est affirmative, puisque dans votre diagramme une commande détermine une demande, laquelle détermine une session.

De même, la règle suivante est-elle bien respectée ?

« Une demande (d’inscription(s)) ne peut porter que sur un seul type de séminaire à la fois. »

La réponse est encore affirmative, puisque dans votre diagramme une demande détermine une session laquelle détermine un type de séminaire : une demande détermine donc transitivement un type de séminaire.

Etc.

Je continuerai à examiner votre diagramme.

Petite remarque en passant :

Vous mentionnez le concept de clé primaire : attention, il n’est pas du niveau conceptuel mais logique (justement ça serait bien de définir les clés au niveau logique...)

Il y aura quelques remarques à faire concernant votre modèle logique.

En attendant, j'envoie un pavé dans lequel je reprends le cours de mon message du 10/11/2011.

[fsmrel]

Après le break du message précédent, je voudrais reprendre le cours de mon message du 10/11/2011 et traiter du temps et des contraintes qu’il induit, de l’identification relative et de l’invariance dans le contexte de Merise.

Début d’une visite guidée (en espérant qu'il n'y a pas trop d'erreurs dans les copier/coller...) Intéressons-nous à la règle de gestion suivante :

« Toutes les précautions sont prises sur les planning-types pour qu’un même formateur ne risque pas d’avoir deux séminaires à assurer en même temps. »

C’est une variante d’une règle plus générale (qu’on pourrait élever au rang de métarègle) :

Quelqu’un ne peut pas faire deux choses à la fois.

Règle générale et informelle mais que l’on rencontre souvent, à laquelle on ne fait pas forcément attention, et qu’il n’est pas toujours facile de garantir au plan de la modélisation conceptuelle selon Merise. Par exemple, Bloups est confronté au problème de la bilocation, car selon sa modélisation, un artiste pourrait se produire en même temps dans deux salles de spectacle différentes, à l’occasion de ses tournées de concert (rechercher le mot "bilocation" dans la discussion Billetterie en ligne). Un avion peut décoller en même temps de deux aéroports, (rechercher le mot "Schrödinger" dans la discussion avec snoopo Comment utiliser un agrégat ? Dans la même course de chevaux, il est préférable qu’un jockey ne puisse pas monter deux chevaux en même temps, et/ou que deux chevaux n’y aient pas le même numéro, etc., cf. la discussion avec lazare (Courses hippiques).

S’il est compliqué d’interdire la bilocation lors de l’étape de la modélisation conceptuelle des données, on peut heureusement rattraper le coup très facilement lors de l’étape suivante (modèle logique), à condition d’avoir pris soin de noter dans ses tablettes (et tant qu’à faire sur le diagramme conceptuel, comme dans la figure 3 ci-dessous) la contrainte selon laquelle un type séminaire ne peut pas avoir lieu en même temps dans deux sessions différentes.

Dans ce qui suit, on considèrera que l’attribut CodeSeminaire de l’entité-type de l’entité-type SEMINAIRE respecte les principes d’invariance et d’absence de sens déjà mentionnés dans la discussion. Si tel n’était pas le cas, on le doublerait d’un attribut (appelons-le IdSeminaire) qui servirait d’identifiant « principal » tandis que CodeSeminaire serait ravalé au rang d’identifiant alternatif, mais ceci n’aurait strictement aucune incidence sur la modélisation.


Revenons à nos moutons et considérons à nouveau le diagramme conceptuel relatif aux relations entre les types de séminaires et les sessions (diagramme dans lequel l’entité-type SEMINAIRE devrait s’appeler TYPE_SEMINAIRE, mais ça n’est qu’un banal problème de vocabulaire) :


L’observation d’Yves Tabourier a trait au « manque d’intérêt » des cardinalités 1,1 dans les associations-types de dimension > 2 (ternaires et au-delà). Indépendamment de l’existence de la dépendance fonctionnelle {SEMINAIRE, DATE} -> {SESSION}, du fait que la cardinalité portée par la patte connectant l’entité-type SESSION et l’association-type ternaire Planifier est une cardinalité 1,1 alors cette ternaire doit logiquement être décomposée en deux binaires :




DATE étant une pseudo entité-type qui ne sert après tout que pour pouvoir représenter la ternaire, elle peut disparaître (quant à lui, l’attribut Date migre dans l’en-tête de l’entité-type SESSION sous le nom de DateSession). Le diagramme devient :




Toutefois, en supprimant la patte qui manque d’intérêt, on perd la dépendance fonctionnelle {SEMINAIRE, DATE} → {SESSION}, c'est-à-dire qu’on perd la règle de gestion selon laquelle pour une date et un type de séminaire donnés, il n’y a qu’une session. Si l’on procède à la dérivation du diagramme conceptuel en diagramme logique, on obtient ceci :



Et il faut rattraper le coup, retrouver la règle de gestion perdue : on intervient manuellement en faisant de la paire {CodeSeminaire, DateSession} une clé alternative de la table SESSION (mickey <ak>) :



On pourrait en rester là, mais on peut s’intéresser à l’étude de variations sur le thème de base. Ainsi, on a supposé que l’attribut CodeSeminaire de l’entité-type SEMINAIRE respectait les principes d’invariance et d’absence de sens, et que si ça n’était pas le cas, on définirait un attribut IdSeminaire servant d’identifiant « principal » tandis que CodeSeminaire serait ravalé au rang d’identifiant alternatif. Si à son tour, l’attribut NumeroSession de l’entité-type de l’entité-type SESSION respecte les principes d’invariance et d’absence de sens, d’accord on peut effectivement en rester là. Sinon, on doit observer qu’il y a une incidence sur la modélisation, car changer la valeur d’un numéro de session aurait des conséquences qui pourraient être gênantes, par exemple sur les commandes (à l’image du changement de numéro Siren des entreprises évoqué précédemment) : si l’attribut NumeroSession de l’en-tête de la table SESSION change de valeur pour une ligne donnée, alors il faut répercuter ce changement dans toutes les tables qui font référence à la table SESSION (table COMMANDE par exemple). Pour éviter ce genre d’opération lourde, il est plus que fortement recommandé de définir un attribut invariant et dépourvu de sens (appelons-le IdSession), qui devienne l’identifiant de l’entité-type SESSION, l’attribut NumeroSession étant alors ravalé au rang d’identifiant alternatif :





Le diagramme logique devient le suivant (où l’on n’oublie pas de faire de la paire {CodeSeminaire, DateSession} une clé alternative, symbolisée par le mickey <ak2>) :


Note concernant la décomposition de l’association-type ternaire PLANIFIER.

Pour les courageux... Revenons sur le diagramme de la figure 1. Les diagrammes des figures 2 et suivantes sont la conséquence de l’application du principe selon lequel une ternaire dont une patte est porteuse d’une cardinalité 1,1 est à décomposer en deux binaires, avec pour effet immédiat la perte de la dépendance fonctionnelle {SEMINAIRE, DATE} -> {SESSION}. Si on ne veut pas se résoudre à décomposer, on peut tenter de mettre en œuvre le diagramme conceptuel suivant :



Mais il existe maintenant une association-type R connectée à l’association-type PLANIFIER, ce qui n’est pas particulièrement merisien (à moins de passer par exemple à Merise orienté objet). On peut contourner l’obstacle en déguisant l’association-type PLANIFIER en une entité-type identifiée relativement à SEMINAIRE d’une part et à DATE d’autre part :



L’identification relative est symbolisée ici par la mise entre parenthèses de la cardinalité 1,1 (convention de l’AGL Power AMC). Au besoin je rappelle que ce type d’identification a pour effet que PLANIFIER hérite d’une part de l’identifiant de SEMINAIRE et d’autre part de celui de DATE : on a bien déguisé l’association-type PLANIFIER en entité-type.

Par voie de conséquence, la structure de PLANIFIER au niveau logique est la suivante :

Mais se posent maintenant deux problèmes au niveau logique :

1) Il y a une bijection entre les tables PLANIFIER et SESSION, ce qui est souvent sujet à débat (à cause du cycle apparaissant au niveau logique) ;

2) On devra une fois de plus prendre en compte manuellement la dépendance fonctionnelle :

Pour retrouver le diagramme de la figure 5, il faut :

Supprimer la table SESSION,
Renommer PLANIFIER en SESSION,
Renommer Date en DateSession (ce que l’on aurait pu faire au niveau conceptuel),
Faire passer la paire {CodeSeminaire, DateSession} du statut de clé primaire à celui de clé alternative,
Élever {NumeroSession} au rang de clé primaire.

Comme dit l’autre, ça fait pas mal de choses à faire, il vaut mieux laisser tomber cette approche et procéder comme illustré dans les figures 2 à 5.

Ne baissons pas les bras, il existe d’autres possibilités de modélisation... Supposons que l’utilisateur tienne à ce que le numéro de session puisse être porteur de sens et/ou être modifié (le problème est du reste plus simple à traiter si l’utilisateur ne tient pas particulièrement à ce numéro). Sémantiquement parlant, l’entité-type SESSION peut être perçue comme une propriété multivaluée de l’entité-type SEMINAIRE, elle est alors ce qu’il est convenu d’appeler une entité-type faible (weak entity chez Johnny), symbolisée par l’emploi de l’identification relative. Le diagramme conceptuel devient alors le suivant :



SequenceurSession est un nouvel attribut jouant le rôle de numéroteur relatif à CodeSeminaire, et l’identifiant de SESSION est alors défini par la paire {CodeSeminaire, SequenceurSession}. Le singleton {NumeroSession} est ravalé au rang de clé alternative, ce qui ne pose aucun problème.

Mai là encore, la paire {CodeSeminaire, DateSession} doit faire l’objet d’une clé alternative au niveau logique, et malheureusement on doit encore se résoudre à la définir à la main (il ne faudrait quand même pas perdre la règle selon laquelle un type de séminaire ne peut pas être donné deux fois le même jour...). Le diagramme logique est le suivant :


A cette occasion, regardons un exemple de valeur prise par la table SESSION (les noms des attributs composant la clé primaire {CodeSeminaire, SequenceurSession} sont soulignés, les noms des attributs composant la clé alternative {CodeSeminaire, DateSession} sont en italiques et le nom de l’attribut composant la clé alternative {NumeroSession} est en gras) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Table SESSION
   
CodeSeminaire    SequenceurSession     DateSession    NumeroSession    HeureDebut     
            1                    1     14/03/2011                 1    08:30         
            1                    2     07/11/2011                 2    09:00         
            1                    3     19/12/2011                 3    09:00
            2                    1     09/11/2011                 4    09:30
            2                    2     19/12/2011                 5    08:30 
          ...                  ...     ...                      ...    ... 

Clés : {CodeSeminaire, SequenceurSession}, {NumeroSession}, {CodeSeminaire, DateSession}

Bien noter que la numérotation de l’attribut SequenceurSession commence à 1 pour chaque type de séminaire. Une référence utile pour voir comment fonctionne l’incrémentation automatique d’un numéroteur relatif tel que SequenceurSession : l’article de CinePhil sur le sujet.

Après ces quelques variations, on conclut que si on modélise en utilisant soit les diagrammes des figures 2 à 5, soit les diagrammes de figures 12 et 13, on n’échappe pas à une intervention manuelle au niveau logique (prise en compte en l’occurrence de la dépendance fonctionnelle {SEMINAIRE, DATE} -> {SESSION}). Ceci est une conséquence du paradigme merisien “One fact, one place” : un attribut (CodeSeminaire au hasard...) ne peut pas figurer deux fois dans le diagramme conceptuel. Par contre, on est beaucoup moins gêné aux entournures au niveau logique, ce qui nous permet de rattraper le coup.

A supposer que l’utilisateur ne tienne pas à avoir la maîtrise du contenu du numéro de session, donc que ça lui soit égal que ce contenu soit invariant, on peut faire l’économie de l’attribut SequenceurSession, et le remplacer par l’attribut NumeroSession. Le diagramme conceptuel est alors le suivant :



L’attribut NumeroSession joue le rôle de numéroteur relatif à CodeSeminaire, et l’identifiant de SESSION est alors défini par la paire {CodeSeminaire, NumeroSession}.

Mais bien sûr, là encore, la paire {CodeSeminaire, DateSession} devra faire l’objet d’une clé alternative au niveau logique, ajoutée manuellement (rabâchons encore et encore qu’il ne faut pas perdre la règle selon laquelle un type de séminaire ne peut pas faire l’objet de deux sessions en même temps...). Quoi qu’il en soit, le diagramme logique correspondant est le suivant :



Le contenu (ou extension) de la table devient le suivant (en notant que les noms des attributs composant la clé primaire {CodeSeminaire, NumeroSession} sont soulignés, tandis que les noms des attributs composant la clé alternative {CodeSeminaire, DateSession} sont en italiques) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Table SESSION
   
CodeSeminaire    NumeroSession    DateSession    HeureDebut     
            1                1    14/03/2011     08:30         
            1                2    07/11/2011     09:00         
            1                3    19/12/2011     09:00
            2                1    09/11/2011     09:30
            2                2    19/12/2011     08:30 
          ...              ...    ...            ... 

Clés : {CodeSeminaire, NumeroSession}, {CodeSeminaire, DateSession}

On ne parle plus de la session <1>, de la session <2>, etc. dans l’absolu, mais de la session <1,1>, de la session <1,2>, c'est-à-dire de la 1re session du type de séminaire 1, de la 2e session du type de séminaire 2, etc., puis de la 1re session du type de séminaire 2, de la 2e session du type de séminaire 2, etc.

La session <1,1> n’a lieu qu’à une seule date, à savoir le 14 mars 2011, etc.


En fait, il est possible d’éviter une intervention manuelle au niveau logique pour assurer la dépendance fonctionnelle, il suffit de ravaler l’attribut NumeroSession au rang d’identifiant alternatif et de considérer que l’identifiant (relatif) de l’entité-type SESSION est constitué de la paire {CodeSeminaire, DateSession} :




D’où le diagramme logique dans lequel on n’a pas à intervenir :


Mais, toujours du fait des conséquences sur les commandes, il est prudent de s’assurer que la clé primaire de la table SESSION soit invariante, donc que les dates de session ne soient jamais modifiées et là rien n’est moins sûr, sauf peut-être dans les cas d’école...

Fin de la visite guidée...

Note concernant les données temporelles :

On vient de se donner beaucoup de peine pour voir différentes façons de garantir la règle de gestion :

« Toutes les précautions sont prises sur les planning-types pour qu’un même formateur ne risque pas d’avoir deux séminaires à assurer en même temps. »

Mais en réalité on ne garantit pas la règle ! En effet, on garantit seulement que pour un type de séminaire donné T1, deux sessions S1 et S2 ne peuvent pas commencer le même jour. Supposons maintenant que S1 commence tel lundi pour une durée de quatre jours : qu’est-ce qui empêche que S2 puisse commencer le lendemain ? Rien en l’état. Il faudra donc prévoir une contrainte permettant de s’assurer qu’il n’y a pas de recouvrement des périodes.

Note concernant l’outil de modélisation :

Vous utilisez AnalyseSI. Je ne sais pas où en est le développement de cet outil, mais j’avais à une époque effectué des tests et ça n’était pas brillant ! Voyez par exemple ici...

Il existe un autre outil gratuit qui fonctionne très bien, Open ModelSphere, voyez des exemples d’utilisation :

tavarlindar (Quelle technique / logiciel pour modéliser un MCD intelligent en 2010 ?)
http://www.developpez.net/forums/d96...a/#post5436291

dxerty (Type association communs).
http://www.developpez.net/forums/d89...s/#post5091059

Locus51 (gestion des adhérents).
http://www.developpez.net/forums/d90...s/#post5112835

Menas (MCD_Spécialisation/Heritage/Sous-types Open ModelSphere).
http://www.developpez.net/forums/d89...n-modelsphere/

ricounet_paris (inscription (souple) de clients).
http://www.developpez.net/forums/d95...s/#post5356557

guipe ( Gestion d'une pharmacie)
http://www.developpez.net/forums/d90...ion-pharmacie/

Etc.

Si vous n’êtes pas inféodé à Merise, vous pouvez éventuellement utiliser MySQL Workbench (gratuit), qui est du niveau logique, mais permet d’éviter les difficultés inhérentes à la modélisation conceptuelle que nous avons rencontrées ci-dessus.

[DJMOUS]

Bonsoir,

Dans la dernière version que vous trouverez ci dessous, un point me gêne dans le sens où le lien entre la commande et le formateur, la relation "convoquer pour" "ferme" mon schéma. Ne doit on pas créer une entité "Convocation" qui serait le lien avec l'entité "Stagiaire" et "Formateur".
De plus, doit on créer un lien entre la société et le stagiaire.

Il existe toujours la problématique du calcul "CUMSOC" que je n'arrive pas à positionner dans le MCD.

Que pensez vous de ce MCD? Y a t'il encore des choses à redire?

Merci de vos lumières.