Discussion :

[sudtek]

Bonjour à tous ,
Dans le cadre d’un projet scolaire je dois étudier et mettre en œuvre un système de suivi de notes et absences d’élèves de diverses sections pour mon iut cela requiert entre autres de calculer les moyennes, les ECTS cumulés, prendre en compte les équivalences mais aussi les heures des profs .... On ne pas donner de cahier des charges écrit bien défini hormis une feuille très sommaire du minimum attendu et quelques indications orales entre deux portes sur ce que l’on voulait obtenir. Mon but donc et de fournir au responsable une version sous ACCES qu’il validera puis je porterai la version une validée sur un SGBD tiers en lui ajoutant un interface de gestion.

Après avoir pris en compte les divers besoins et extrapoler j’ai pondu plusieurs MCD et j’ai enfin une ébauche. Néanmoins n’ayant jamais fait de MCD aussi conséquent je manque de recul … Du coup comme je bagarre depuis pas mal de temps avec un point particulier et j’aurais aimer avoir votre avis. J’ai réalisé ce dernier avec le soft analyseSI car il est simple et ne mâche pas le travail ce qui est plus pratique pour apprendre mais la j’avoue humblement que je coince …

Mon PB ce situe sur la table LISTEENSEIGNEMENTS je ne suis pas certain du bon choix de conception ! Je souhaiterai générer une clef primaire dans la liste des enseignements (LISTEENSEIGNEMENTS) quand l’utilisateur associe un N°module à une UE dans COMPOSER_1 ou fait une màj quand on modifie COMPOSER_1 et que l’on rajoute par exemple une catégorie à un N°module exemple un TP, TD.

…. pour obtenir le MLD suivant :

LISTEENSEIGNEMENTS (anneUniversitaire, IDUE, N°MODULE, CODECATEGORIE)
donnerait la table LISTEENSEIGNEMENTS*:
|anneUniversitaire | IDUE | N°MODULE | CODECATEGORIE|
2012 3 1 CM
2012 3 1 TD
2013 5 2 TP
…. … ... …


COMPOSER_1 ( anneUniversitaire ,IDUE , N°MODULE)
donnerait la table composer_1*:
|anneUniversitaire | IDUE |N°MODULE |
2012 3 1
2012 3 1
2013 5 2
…. … …

COMPOSER_2 (anneUniversitaire, CODECATEGORIE, N°MODULE ,volumeHoraireMC)
donnerait la table composer_2*:
|anneUniversitaire | N°MODULE | CODECATEGORIE| volumeHoraireMC |
2012 1 CM 12,5
2012 1 TD 20,4
2013 2 TP 15,0
…. … … …


J’ai donc eut dans l’idée de relier l’entité LISTEENSEIGNEMENTS aux associations COMPOSER_1 & COMPOSER_2 avec une relation 1,1 mais de mémoire dans un MCD on ne «*tire*» pas les clefs primaires des entités pères qui sont associées avec cette association. Sachant que COMPOSER_1&2 deviennent des tables à part entière quand on passe au MLD j’ai trouvé cela tentant surtout que Acces ne semble pas choquer si l’on active l’integrité referencielle + màj en cascade cela ne le choque pas néanmoins cela ne me paraît pas en accord avec les bonnes pratiques pour faire un MCD*!?

Je pense que la bonne pratique voudrait que je relie par des associations distinctes l’entité LISTEENSEIGNEMENTS aux entités anneUniversitaire, IDUE, N°MODULE, CODECATEGORIE avec des cardinalités 1,1 et faire une requête d’union entre COMPOSER_1 & COMPOSER_2 faisant une mise à jour automatique de l’entité LISTEENSEIGNEMENTS*? Entité qui me servira pour gérer les profs et les notes & absences des élèves.

Vous trouverez ci-joins*:
- mon MCD original ou LISTEENSEIGNEMENTS n’est pas relié.
- la source de mon MCD pour le soft analyseSI.
- la solution qui me semble la plus proche des bonnes pratiques de mise en oeuvre d’un MCD.
- Le fichier Acces.

Notes pour la compréhension*: J’ai fait en sorte que l’utilisateur puisse créer des UES (unités d’enseignements) & les N°modules à partir de gabarits pour éviter les PB de saisie d’où la LISTEUES & la LISTEMODULES dans laquelle l’utilisateur peut piocher.
J’ai également intégrer une notion d’année dans les UES et les N°MODULES pour filtrer plus facilement et éviter que l’on associe une UE dispensée en 2012 et une en 2010 car les classes n’ont pas forcement le même cursus d’une année sur l’autre et toutes les classes n’ont pas le même style de formation ex une année spéciale fait tous le programme en 1an en formation continue, d’autres en 2 les formations du soir en 3 et il y a mêmes des cours à la carte dans certains cas. Du fait le NUMANNE qui correspond à l’année à laquelle appartient une UE ou un module n’est là qu’a titre indicatif pour que l’humain qui compose l’UE se repéré ce n’est pas un critère de filtrage car une année spéciale fera de la crypto de seconde année dés la 1er année.

En vous remerciant pour votre aide et vos observations constructives.

[fsmrel]

Bonsoir sudtek,


Je n’ai qu’Access 2003, donc je ne peux pas ouvrir votre fichier "BD TEST V10_7E (1).accdb".

En attendant, vous proposez le MLD suivant, lequel est visiblement juste du point de vue de la sémantique et de la théorie relationnelle, à ceci près qu’on ne sait pas si les clés candidates sont seulement des surclés, mais on pourra s’occuper de cela plus tard :

LISTEENSEIGNEMENTS (anneUniversitaire, IDUE, N°MODULE, CODECATEGORIE)
donnerait la table LISTEENSEIGNEMENTS*:

anneUniversitaire    IDUE    N°MODULE    CODECATEGORIE
2012                    3           1    CM 
2012                    3           1    TD 
2013                    5           2    TP
              ...     ...         ...    ... 

COMPOSER_1 ( anneUniversitaire ,IDUE , N°MODULE)
donnerait la table composer_1*:

 
anneUniversitaire    IDUE    N°MODULE
2012                    3           1
2012                    3           1
2013                    5           2
...                   ...         ... 

COMPOSER_2 (anneUniversitaire, CODECATEGORIE, N°MODULE ,volumeHoraireMC)
donnerait la table composer_2*:

anneUniversitaire    N°MODULE    CODECATEGORIE    volumeHoraireMC
2012                        1    CM                          12,5
2012                        1    TD                          20,4
2013                        2    TP                          15,0
...                       ...    ...                          ... 

Permettez-moi de renommer COMPOSER_1, COMPOSER_2, LISTEENSEIGNEMENTS respectivement en MAU, MAC et MACU. Graphiquement, le MLD équivalent est le suivant (avec l’AGL PowerAMC). Les couleurs sont là uniquement pour attirer l’attention :



Où les symboles « <pk> », « <fk> » signalent respectivement l’appartenance des noms des attributs à des clés primaires et/ou étrangères.

Le problème est que vous ne pouvez pas obtenir ce résultat (valide) de façon mécanique à partir d’un MCD Merise ou d’un diagramme de classes UML, il faut procéder à des modifications manuelles. Quoi qu’il en soit, c’est ce MLD qui fait foi et qui doit servir pour la déclaration des tables au stade SQL.

Votre diagramme « enrichi » avec les associations sol_1, sol_2, sol_3, sol_4 est bon pour la poubelle car trop laxiste, ces associations pouvant en effet conduire à des résultats en contradiction avec ce qui est attendu, c'est-à-dire qu’elles permettent de produire à partir de MACU (par projection) des triplets de valeurs <ModuleId, UeId, Annee> absents de MAU et des triplets de valeurs <ModuleId, CategorieId, Annee> absents de MAC.


Il y a encore pas mal de choses à dire, mais ce qui précède traite de ce qui vous préoccupe au premier chef.


N.B. Dans votre cas, MySQL Workbench vous serait incomparablement plus utile qu’AnalyseSI.

[fsmrel]

Voici la version MWB (MySQL Workbench) du MLD précédent. A noter qu’avec MWB, on modélise directement au niveau logique, ce qui simplifie énormément les choses pour produire le diagramme voulu :



Pour reprendre ce que j’ai déjà dit, reste à voir si les clés sont bien des clés candidates et pas seulement des surclés ne vérifiant pas la règle d’irréductibilité.

[sudtek]

Bonjour fsmrel ,

Je n’ai qu’Access 2003, donc je ne peux pas ouvrir votre fichier "BD TEST V10_7E (1).accdb".

Je vais voir si je peux exporter vers un version 2003 avec Acces 2007.

Permettez-moi de renommer COMPOSER_1, COMPOSER_2, LISTEENSEIGNEMENTS respectivement en MAU, MAC et MACU.

Je comprends le fait de renommer c’est plus parlant quant on travaille directement niveau logique car graphiquement il n’y a que des entités «tables».

Le problème est que vous ne pouvez pas obtenir ce résultat (valide) de façon mécanique à partir d’un MCD Merise ou d’un diagramme de classes UML, il faut procéder à des modifications manuelles. Quoi qu’il en soit, c’est ce MLD qui fait foi et qui doit servir pour la déclaration des tables au stade SQL.

Effectivement AnalyseSI m’a fait un «caca nerveux» au moment de la transformation du MCD vers le MLD quand j’ai schématisé une version précédente dans le but d’avoir une récupération des clefs étrangères d’où l’idée de faire le diagramme enrichi -> une fausse bonne idée.

Votre diagramme « enrichi » avec les associations sol_1, sol_2, sol_3, sol_4 est bon pour la poubelle car trop laxiste, ces associations pouvant en effet conduire à des résultats en contradiction avec ce qui est attendu, c'est-à-dire qu’elles permettent de produire à partir de MACU (par projection) des triplets de valeurs <ModuleId, UeId, Annee> absents de MAU et des triplets de valeurs <ModuleId, CategorieId, Annee> absents de MAC.

Sous Acces se problème était effectivement mis en évidence du coup j’avais contourné en filtrant via une requête d’union entre MAU u MAC mais ce poser à lors la problème de màj en cascade … votre solution et plus univoque car on à pas le choix ou c’est présent dans la MACU ou cela n’existe pas et on ne peut pas «*lier*» des notes ou des professeurs.

N.B. Dans votre cas, MySQL Workbench vous serait incomparablement plus utile qu’AnalyseSI.

J’avoue pour l'instant avoir du mal à faire un schéma logique s’en passer par un MCD merise. En fait grâce à votre post fait je viens de réaliser qu’Acces fonctionne purement au niveau logique comme mysqlworkbench et autres … à ce propos existe t’il un logiciel gratuit qui intégré une solution MCD & MLD style MySQL Workbench mais avec cardinalité à la française style merise ? car travailler en modèle logique avec des cardinalité inversés et codifier autrement … en débutant c’est super galère sachant qu'en plus qu’il est «vivement recommandé» d’un point de vue scolaire de fournir un MCD suivi d’un MLD sous peine de subir le fouet

Si je réalise le MCD suivant*:



Techniquement pour la partie MACU c’est un MCD correct et conforme ?
Donc si le soft AnalyseSI n’est pas capable de gérer l’importation récurrentes des clefs étrangères c'est à moi de le faire lors du passage au MLD ?

reste à voir si les clés sont bien des clés candidates et pas seulement des surclés ne vérifiant pas la règle d’irréductibilité.

Hum … là il faut que je lise et relise les liens à tête reposé pour y réfléchir …

...ces associations pouvant en effet conduire à des résultats en contradiction avec ce qui est attendu, c'est-à-dire qu’elles permettent de produire à partir de MACU (par projection) des triplets de valeurs <ModuleId, UeId, Annee> absents de MAU et des triplets de valeurs <ModuleId, CategorieId, Annee> absents de MAC.

fsmrel si j’ai bien compris j’ai le même PB pour les entités ENREGISTRER ou EQUIVALENCES il faut pas les lier avec UES, MODULES & ANNEUNIVERSITAIRE mais avec MACU !

Merci fsmrel pour votre aide et vos explications !

A+

[fsmrel]

Bonsoir sudtek,

Techniquement pour la partie MACU c’est un MCD correct et conforme ?

Hélas ! non...

En effet, l’association MAU est désormais une quaternaire, à laquelle participent — sur un pied d’égalité — les entités-types MODULE, UE, ANNEE_UNIVERSITAIRE et MACU (même punition pour l’association MAC). Au niveau MLD, MAU fera l’objet d’une table avec pour clé le quadruplet :

{IdUE, N°Module, AnneeUniversitaire, IdEnseignement}

Vous ne pouvez guère faire autrement que déguiser MAU et MAC en entités-types (Même chose pour MACU puisqu’elle sera associée à PROFESSEUR par exemple). Pour illustrer cela — tout en notant que de MAU, MAC et MACU j’ai même fait des carronds, objets fantaisistes mais parlants :




Au stade du MLD, au moins les tables seront là, mais il y aura une grande réorganisation à prévoir dans les attributs et les clés pour obtenir un MLD conforme à celui que j'ai précédemment proposé.


A propos de quaternaire

Dans votre MCD, l’association ENREGISTRER est une quaternaire qui, au niveau MLD, fera l’objet d’une table avec pour clé le quadruplet :

{IdEleve, IdClasse, IdUE, AnneeUniversitaire}

L’élève Raoul pourra donc faire partie de plus d’une classe au cours de la même année universitaire. Est-ce bien ce que vous voulez ?

Travailler en modèle logique avec des cardinalités inversées et codifier autrement … en débutant c’est super galère.

Vous pouvez effectivement être troublé par l’inversion apparente des cardinalités, mais ceci est dû au fait que dans le MCD la lecture des cardinalités est arrêtée par un « rond » tandis qu’elle est arrêtée par un « carré » dans le MLD :



Dans le cas du MCD, le contact de l’UE avec les MAU est indirect, un rond les sépare. Une UE participe N fois à l’association, question : mais avec qui ? On va voir de l’autre côté du miroir : Ah ? ce sont N MAU...

Dans le cas du MLD, l’UE est en contact direct avec les N MAU.

Quand on lit le MCD, mentalement il faut se poser la question : combien de fois l’UE participe-t-elle à l’association ? Alors qu’en lisant le MLD, la question est : avec combien de MAU l’UE est-elle en contact direct ?

De toutes façons, si un jour vous êtes amené à réaliser des diagrammes de classes UML, vous n’aurez pas le choix, ça sera :




N.B. Les losanges marquent une relation de composition, inférée de l’identification relative merisienne.


A suivre...

[fsmrel]

Suite,

existe t’il un logiciel gratuit qui intégré une solution MCD & MLD style MySQL Workbench mais avec cardinalité à la française style Merise ?

Vous avez Open ModelSphere (OMS) qui est très bon pour faire des MCD, il prend en compte l’identification relative et la généralisation/spécialisation. Mais au niveau MLD, c’est « un peu » la galère, car lorsqu’il s’agit de produire le code SQL, OMS a souvent des vapeurs et on a un mal de chien à lui faire cracher à quelque chose de complet (en fait sans explication de sa part en ce qui concerne ce qui ne lui plaît pas, alors qu’il signale qu’il n’a trouvé aucune erreur quand on lui demande de vérifier le MLD). Par ailleurs, au niveau MLD la représentation en OMS est du même genre que celle de MWB.

Côté MCD, voilà ce que ça donne :



Vous pouvez à l’occasion jeter un coup d’œil chez Maeho (qui a fini par craquer...)


A OMS je préfère DB-MAIN, un peu déroutant au départ, mais avec lequel on s’énerve beaucoup moins quand on a pigé son mode de fonctionnement (bien expliqué dans la doc, à lire avec attention !)


MCD avec DB-MAIN :



MLD



Avec ce genre de MLD, il n’y a plus de cardinalités, elles sont représentées sous forme textuelle dans les boîtes. Serait-ce moins « galère » pour vous ?


A suivre...

[fsmrel]

Ssi j’ai bien compris j’ai le même PB pour les entités ENREGISTRER ou EQUIVALENCES il faut pas les lier avec UES, MODULES & ANNEUNIVERSITAIRE mais avec MACU !

Peut-être, tout dépend des règles de gestion... Quelles sont-elles en l’occurrence ?

[sudtek]

Vous ne pouvez guère faire autrement que déguiser MAU et MAC en entités-types (Même chose pour MACU puisqu’elle sera associée à PROFESSEUR par exemple). Pour illustrer cela — tout en notant que de MAU, MAC et MACU j’ai même fait des carronds, objets fantaisistes mais parlants

OK votre dessin me rassure car un moment quand j’ai vu la clef PK MODULEID de MACU être forgé de clefs secondaire qui semblé tirés / descendues de façon récurrentes alors que ce n’est pas autorisé pour un MCD j’avais cru que mon prof m’avait raconté de la «charbonille» (pourtant c’est pas son style) … mais vos carronds expliquent bien et confirment le MLD et le fait que mon prof ne m’a pas menti ! Votre "maquillage" consiste en fait à subdiviser et préciser les relations.

A propos de quaternaire
Dans votre MCD, l’association ENREGISTRER est une quaternaire qui, au niveau MLD, fera l’objet d’une table avec pour clé le quadruplet :
{IdEleve, IdClasse, IdUE, AnneeUniversitaire}
L’élève Raoul pourra donc faire partie de plus d’une classe au cours de la même année universitaire. Est-ce bien ce que vous voulez ?
…

Ssi j’ai bien compris j’ai le même PB pour les entités ENREGISTRER ou EQUIVALENCES il faut pas les lier avec UES, MODULES & ANNEUNIVERSITAIRE mais avec MACU !
Peut-être, tout dépend des règles de gestion... Quelles sont-elles en l’occurrence ?

Exemple un étudiant peut se retrouver dans une classe de seconde année par exemple et repasser les examens, TP ou TD d’une partie des cours de l’année 1 ou 2 s’il n’a pas eut certains modules*; mais je pense que vous soulevez un point important fsmrel car si un étudiant fait partie de plus d’une classe pour une année universitaire cela va fausser les effectifs de classe d’un point de vue administratif … faute de consigne arrêtée pour les règles de gestion mais connaissant un peut le système interne c’est la raison qui me faisait penser que ENREGISTRER devrait être lié avec la liste des enseignements MACU deplus n’arrivant pas à me sortir de mon pb précédent j’avais «*tapé en touche en la reliant à UES*» ... Donc si ENREGISTRER et lié à MACU on évite d’enregistrer un élevée à une UE qui existe mais qui ne sera pas forcement enseigné cette année universitaire là et on est certains de réinscrire l’élèves à des modules qu’il a raté et qui sont bien dispensé l’année courante. Idem pour l’équivalence on peut ainsi neutraliser partiellement une UE module par module en etant certain qu’ils sont dispensés dans l’année courante ou l’élèves et inscrit.

De toutes façons, si un jour vous êtes amené à réaliser des diagrammes de classes UML, vous n’aurez pas le choix, ça sera :



N.B. Les losanges marquent une relation de composition, inférée de l’identification relative merisienne.

En fait sous forme Uml on obtient plus d’information car si je me référé à http://uml.developpez.com/cours/ je constate que l’on peut traduire la partie verte en:

Une MAU est une composition de UE → si je détruit une UE donné tout les MAU composer de cette UE disparaissent , une UE compose une ou plusieurs MAU ? En indiquant qui hérite de quoi le schema UML permet d’être plus précis / moins ambigu que la version du schéma en MCD !?

Avec ce genre de MLD, il n’y a plus de cardinalités, elles sont représentées sous forme textuelle dans les boîtes. Serait-ce moins « galère » pour vous ?

Si je comprend bien la flèche indique qui hérite de quoi et pointe de façon bien moins univoque que le MCD base ! C’est DBMAIN qui à généré ce MLD ? D’après le MCD DBMAIN je constate qu’il faut être plus «carré» pour faire son MCD avec ce soft mais au moins cela invite à se poser des questions pendant la réalisation je pense qu’a long terme c’est plus payant que les softs trop permissifs ! Je vais le télécharger, lire la doc. Dans le cadre de ce projet scolaire je vais finir le mcd avec le soft en cours cela ferait beaucoup de nouveautés en cours de route je vais tester DBMAIN pour un petit projet de test perso. Merci pour le comparatif des softs je suis persuadé que cela va en intéresser plus d’un !

Merci fsmrel pour tous ces renseignements cela me permet de clarifier pas mal de choses sur les MCD et les MLD avoir le point de vue de professionnels expérimentés et franchement c'est un plus quand on ne fait pas des TP scolaires triviaux. La partie conception est pour moi en informatique la partie la plus difficile et souvent négligé par les élèves qui veulent «pondre du code»; pour ma part la partie conception est la partie immergé de l’iceberg et donc c’est celle qui je pense doit mériter le plus temps et d’attention car tout le projet repose dessus.

A+

[fsmrel]

Bonsoir sudtek,

J’ai vu la clef PK MODULEID de MACU être forgé de clefs secondaire qui semblé tirés / descendues de façon récurrentes alors que ce n’est pas autorisé pour un MCD

Hum... Si vous parlez de clés, c’est que vous êtes dans le contexte du MLD. Dans un MCD c'est-à-dire en Merise, il n’y a pas de clés mais des identifiants (même si nombreux sont ceux qui font la confusion). Plus généralement, le vocabulaire dont vous vous servez doit être celui du contexte (MCD, MLD), sinon votre interlocuteur risque d’être déboussolé.

Qu’appelez-vous « clé secondaire » ? Il faudrait que vous illustriez par l’exemple. Qu’entendez-vous par « tirer / descendre de façon récurrente » ? Peut-être « hériter » ? Si c’est le cas, l’héritage fonctionne pour un MCD, par exemple dans le cas de l’identification relative dont je touche un mot :

Selon cette technique, dans le cas général, l’identifiant d’une entité-type E est un ensemble I (au sens de la théorie des ensembles) composé de deux éléments : l’identifiant d’une entité-type P dite informellement « parente » de E et d’une propriété de E (E étant considérée comme « enfant » de P). On peut étendre le principe : au moins une parente de E et 0 à plusieurs attributs de E. Par exemple, l’identifiant de MAU est le triplet :

{R_1.MODULE, R_2.UE, Annee}

Triplet dans lequel :

— R_1.MODULE symbolise l’héritage par MAU de l’identifiant de MODULE par le canal de l’association R_1 ;
— R_2.UE symbolise l’héritage par MAU de l’identifiant de UE par le canal de l’association R_2 ;
— Annee est un attribut de MAU.

Même principe pour MAC qui a pour identifiant {R_3.MODULE, R.CATEGORIE, Annee} :





A son tour l’identifiant de MACU est la paire :

{R_4.MAU, R5_MAC}

Paire dans laquelle :

— R_4.MAU symbolise l’héritage par MACU de l’identifiant de MAU par le canal de l’association R_4 ;
— R_5.MAC symbolise l’héritage par MACU de l’identifiant de MAC par le canal de l’association R_5.

On infère que MACU hérite par transitivité des identifiants de MODULE, UE et CATEGORIE. C’est bien ce que confirme le MLD « brut » produit par DB-MAIN :




En conséquence et pour répondre à votre question :

C’est DBMAIN qui à généré ce MLD ?

DB-MAIN n’a aucune raison de produire de lui-même le MLD que j’avais présenté. En effet, en l’état rien ne lui permet de deviner qu’il existerait une hypothétique contrainte (dite contrainte de chemin) selon laquelle les paires d’attributs {Module, Annee} devraient prendre les mêmes valeurs au sein de MACU qui associe MAU et MAC, aussi est-ce à moi de prendre le relais en modifiant la structure de MACU pour rendre effective cette contrainte qui jusqu’ici n’a été formulée que dans le dossier de conception (qui doit exister et contenir l'ensemble des règles de gestion des données, sinon !)
J’aimerais pouvoir exprimer cette contrainte de chemin dès l’étape MCD, mais cela conduirait peut-être à une extension du métamodèle de DB-MAIN.

Quoi qu’il en soit, hors AGL, exprimons de façon formelle cette contrainte mettant en jeu les attributs de l’en-tête de MACU. Dans la langue du Relationland, cela se traduit par l’égalité des projections de MACU sur R_4_ModuleId et R_4_Annee d’une part, et sur ModuleId et Annee d’autre part :

Code D :

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

1
2
CONSTRAINT CX_MACU_01
    MACU {R_4_ModuleId, R_4_Annee} = MACU {ModuleId, Annee} ;

Ce qui veut dire que dans l’en-tête de MACU, les attributs R_4_ModuleId et ModuleId sont redondants ainsi que les attributs R_4_Annee et Annee. Concrètement, pour supprimer la redondance, la transformation à laquelle j’ai procédé manuellement suffit :




Vous pouvez parcourir (entre autres) la discussion ici pour juger de l’intérêt de l’identification relative par rapport à l’identification absolue.

Une MAU est une composition de UE

Une UE est composée de 1 à N MAU et un MAU est un composant d’une UE (le losange est normalement du côté du composé aka classe composite). Attention, les cardinalités ULM (multiplicités) se lisent dans le sens contraire de celles de Merise.

si je détruis une UE donné tout les MAU composer de cette UE disparaissent, une UE compose une ou plusieurs MAU ?

En vertu de la relation de composition, si on supprime une UE, tous les MAU qui en font partie sont aussi supprimés. A l’inverse, la suppression d’un MAU n’entraîne pas celle de l’UE dont il est un élément.

Cela dit, la relation de composition ne s’impose pas car en théorie un composant n’est pas partageable, même si on argue que la classe UE peut être considérée comme un ensemble dont MAU serait un sous-ensemble, mais cela vaut aussi pour la classe MODULE considérée comme ensemble dont MAU serait aussi un sous-ensemble : MAU serait alors l’intersection des ensembles UE et MODULE. Pour couper court à toute discussion sur le partage des composants, on peut préférer représenter les choses à l’aide du diagramme ci-dessous où MAU, MAC et MACU sont des classes-associations :



Le MLD dérivé de ce diagramme de classes sera identique à celui obtenu à partir des compositions.

En indiquant qui hérite de quoi le schema UML permet d’être plus précis / moins ambigu que la version du schéma en MCD !?

Attention, par rapport à un MCD selon AnalyseSI, certes, mais avec les véritables AGL, l’identification relative est disponible et elle marque que l’existence d’une entité-type est dépendante de celle d’une autre entité-type, avec verrouillage de patte, ce qui revient à la composition.

Pour reprendre le diagramme :




L’identifiant de l’entité-type MAU est comme on l’a vu le triplet {R_1.MODULE, R_2.UE, Annee} : l’identification est relative.

Avec OMS, l’identification relative est signalée par le soulignement des cardinalités 1,1 :




Avec PowerAMC (en notation Merise), on a l'équivalent en mettant les cardinalités 1,1 entre parenthèses, etc.

pour ma part la partie conception est la partie immergé de l’iceberg et donc c’est celle qui je pense doit mériter le plus temps et d’attention car tout le projet repose dessus.

Pour avoir audité des tombereaux de MCD incomplets et/ou imprécis, je confirme qu’il s’agit du point bloquant pour la réalisation des projets.

un étudiant peut se retrouver dans une classe de seconde année par exemple et repasser les examens, TP ou TD d’une partie des cours de l’année 1 ou 2 s’il n’a pas eut certains modules.

Je pense qu’il ne faut pas mélanger les problèmes. Qu’un élève fasse partie d’une seule classe au cours d’une année est une chose, mais qu’il lui manque des modules est une autre chose qu’on traitera à part, sinon il y aura prise de pieds dans le tapis.

Avant de traiter du parcours du combattant des élèves, quelques questions préalables :

Indépendamment des élèves, pour l’année en cours, quelles relations y a-t-il entre les classes et les UE ? Entre les classes les modules et les UE ?

Un élève peut-il redoubler une classe ?

[sudtek]

Bonsoir fsmrel,

Hum... Si vous parlez de clés, c’est que vous êtes dans le contexte du MLD. Dans un MCD c'est-à-dire en Merise, il n’y a pas de clés mais des identifiants (même si nombreux sont ceux qui font la confusion). Plus généralement, le vocabulaire dont vous vous servez doit être celui du contexte (MCD, MLD), sinon votre interlocuteur risque d’être déboussolé.

Qu’appelez-vous « clé secondaire » ? Il faudrait que vous illustriez par l’exemple. Qu’entendez-vous par « tirer / descendre de façon récurrente » ? Peut-être « hériter » ?

Désolé; oui effectivement je mélange facilement les deux contextes et je me suis mal exprimé en disant «J’ai vu la clef PK MODULEID de MACU être forgé de clefs secondaire qui semblé tirés / descendues de façon récurrentes alors que ce n’est pas autorisé pour un MCD» en fait conformément à votre MCD

/sudtek(enseignement)OMS_MCD.png

Je constatai que l’identifiant UEID ne se propageait pas de proche en proche dans UE puis MACU alors qu’au passage en MLD on retrouvé la clef UEID elle est présente dans UE puis par transitivité successives dans MACU; hors l’identification relative est un point que l’on a pas abordé à l’iut on est resté sur du tout petit MCD d’où l’utilisation AnalyseSI qui était largement suffisant et je ne comprenais pas comment on pouvait exprimer les dépendances du MCD en MLD … Merci fsmrel car maintenant j’ai compris les limitations du soft AnalyseSI :

Attention, par rapport à un MCD selon AnalyseSI, certes, mais avec les véritables AGL, l’identification relative est disponible et elle marque que l’existence d’une entité-type est dépendante de celle d’une autre entité-type, avec verrouillage de patte, ce qui revient à la composition.

d’où l’utilité d’utiliser un vrai «AGL» comme Dbmain pour le MCD; du coup quand le MCD sera valide je le retranscrirai sous Dbmain pour me faire la main et avoir une meilleur vu des contraintes à appliquer vis à vis des redondances avant de faire le nouveau MLD .

Vous pouvez parcourir (entre autres) la discussion ici pour juger de l’intérêt de l’identification relative par rapport à l’identification absolue.

merci pour le lien je le consulte ce weekend !

Avant de traiter du parcours du combattant des élèves, quelques questions préalables :
Indépendamment des élèves, pour l’année en cours, quelles relations y a-t-il entre les classes et les UE ? Entre les classes les modules et les UE ?
Un élève peut-il redoubler une classe ?

Jeudi soir suite à toutes vos explications sur la partie MAU MAC MACU, j’avais commencé à revoir «ma copie» car j’ai compris que j’allais avoir entre autres des problèmes liés aux projections possibles mais pas forcement présente dans mes listes ...

Je suis donc parti du principe de ce que je connais du fonctionnement de l’iut :

- Un élève saisi dans la BD n’était pas forcément affecté à une classe dés sa saisie ou chaque année suivantes ex*: les Promotion Sociale du travail PST (cours dus soir) en formation continue peuvent faire une pause de 1 à 2 ans dans la formation pour tout un tas de raison personnelles sans avoir à se justifier alors qu’un élève en formation initiale cours du jour lui n’a pas le droit de redoubler hormis dérogation et peut même finir en cours du soir.

- Certaines classes ne sont pas ouvertes tous les ans s’il y a un manque d’effectif ou de budget.

Du coup je suis partie dans l’idée de faire «*2 listes*»*:
AC_LISTECLASSES (anneUniversitaire,CODECLASSE) pour enregistrer doublets des classes existantes/ouvertes pour une année donnée .

AE_LISTEINSCRITS {anneUniversitaire,CODECLASSE,IDELEVE} pour enregistrer les élèves dans la liste des classes existantes → pas d’inscription d’élevés dans des classes fantômes.

Ainsi seul les élèves présents dans AE_LISTEINSCRITS peuvent participer à des enseignements de la MACU_LISTEENSEIGNEMENTS et obtenir des équivalences idem pour les notes.

Je peux même affecter directement plusieurs profs à une classe pour une année donnée en cas de remplacement ou de changement de prof en cour d’année.

quelles relations y a-t-il entre les classes et les UE ?

Justement au départ dans les toutes 1er versions de cer MCD j’avais dans l’idée d’affecté les UE à une classe et d’affecter les élèves au classes sauf que certains élèves n’ayant pas valider des UE de l’année N-1 doivent les repasser durant l’année N (en formation initiale)*; en formation continue c’est pire ils peuvent étaler sur 5 ans et repasser uniquement certains modules de lUE → tous les élèves appartenant à une même classe ne devant pas forcement repasser les mêmes UE ou modules en même temps … d’où l’idée de la liste d’enseignements.

D’où le MCD revue et corrigé de jeudi soir :



Merci pour fsmrel pour votre patiente et vos explications !

Cordialement sudtek.

[fsmrel]

Bonsoir sudtek,


En préambule, un retour sur les carronds.

Les associations d’associations (donc à terme les carronds) soulèvent parfois des réactions vives, car c'est tabou. En tout cas c’est un moyen d’assouplir des règles trop rigides, j’en veux pour preuve les carronds MAU, MAC et MACU. Pour faire plus sérieux, vous pouvez au besoin utiliser le terme entité-type associative à la place de carrond, à la manière de Ted Codd, fondateur du Relationland.


Cas des carronds MAC et MAU

Je ne sais pas comment votre IUT présente ses programmes, aussi ferai-je référence à ceux de l’IUT de Sceaux que j’ai récupérés sur la toile, en supposant que les principes d’organisation sont à peu près les mêmes que les vôtres. Si l’on y regarde de plus près (cf. le PDF page 5), une UE ressemble bigrement à un simple regroupement de modules et l’on pourrait considérer ceux-ci comme des entités faibles relativement aux UE ( characteristics chez Codd), ce qui permet de simplifier la modélisation :

MCD




MAU et MAC sont en l’occurrence des intermédiaires dont on peut se dispenser...

A noter que le volume horaire intègre l’entité-type MACU dont le prédicat est le suivant :

Pour l’année A et la catégorie C, le module M de l’UE U a le volume horaire V.

MLD

Certaines classes ne sont pas ouvertes tous les ans s’il y a un manque d’effectif ou de budget.

Du coup je suis partie dans l’idée de faire « 2 listes » :
AC_LISTECLASSES (anneUniversitaire, CODECLASSE) pour enregistrer doublets des classes existantes/ouvertes pour une année donnée.
AE_LISTEINSCRITS {anneUniversitaire, CODECLASSE, IDELEVE} pour enregistrer les élèves dans la liste des classes existantes → pas d’inscription d’élevés dans des classes fantômes.

Effectivement, si telle année telle ou telle classe n’est pas ouverte, il est nécessaire de définir les paires {classe, année} des classes pouvant accueillir des élèves (CLASSE_ANNEE est un carrond) :

[CLASSE]----0,N----[(CLASSE_ANNEE)]----0,N----[ANNEE]

Au fil des ans, l’élève Raoul change de classe : on pourra voir le cas de son redoublement quand les choses seront stabilisées. En tout cas, à moins d’être doué du pouvoir de bilocation, un élève ne peut pas faire partie de deux classes distinctes la même année : lors du passage au MLD, la clé primaire de la table dérivée du carrond EAK ci-dessous devra être débarrassée de l’attribut ClasseId :

[ELEVE]----0,N----[(EAK)]----0,N----[(CLASSE_ANNEE)]

Au départ dans les toutes 1res versions de ce MCD j’avais dans l’idée d’affecter les UE à une classe et d’affecter les élèves au classes sauf que certains élèves n’ayant pas valider des UE de l’année N-1 doivent les repasser durant l’année N (en formation initiale) ;

Si je comprends bien, une UE ne concerne qu’une seule classe, et si j’ai mal compris, on verra à aménager le MCD ci-dessous (UE ne concernant qu’un type de formation ? Autre scénario ?). Quoi qu’il en soit, on ne peut pas évacuer des règles de gestion comme celle-ci, ça mine les fondations. Pour le moment je pars sur la représentation suivante :

[CLASSE]----1,N----(R)----1,1----[UE]

Je n’ai pas tout suivi ce que vous avez écrit sur la notation des élèves, mais pour le moment, de façon naïve, je pars sur la représentation suivante : un carrond NOTATION connectant les carronds EAK et MACU :

[(EAK)]----0,N----[(NOTATION)]----0,N----[(MACU)]

Pour effleurer le thème des UE non validées, j’ajoute pour la forme une entité-type REBELOTE, accrochée à NOTATION, avec l’idée que si un élève est noté l’année N, REBELOTE fera référence à l’année N-1. Cela dit, ça ne répond sans doute pas au besoin, aussi faudrait-il que vous précisiez exactement les règles régissant les validations.


MCD (provisoire...)





MLD (PowerAMC)



La contrainte CK_NOTATION se lit ainsi :

La projection sur les attributs EleveId, Annee, ClasseId de la jointure naturelle de NOTATION et UE doit être incluse dans EAK.

Le but est que l’on ne note pas un élève pour des modules d’UE qui ne font partie des UE de la classe dont il fait partie au fil des années.

N.B. Dans le cas de l’IUT de Sceaux, les codes permettant d’identifier les UE les modules et les catégories sont significatifs : je suppose que vous avez un système du même genre, auquel cas il faudrait prévoir les attributs ad-hoc dans les entités-types UE, MODULE et CATEGORIE, ce que je n’ai pas (encore) fait ci-dessus.


Courage !

[sudtek]

Bonjour fsmrl et merci pour les encouragements car l'AGL c’est loin d'être trivial !!

Les associations d’associations (donc à terme les carronds) soulèvent parfois des réactions vives, car c'est tabou. En tout cas c’est un moyen d’assouplir des règles trop rigides, j’en veux pour preuve les carronds MAU, MAC et MACU. Pour faire plus sérieux, vous pouvez au besoin utiliser le terme entité-type associative à la place de carrond, à la manière de Ted Codd, fondateur du Relationland

Je prend note concernant les «entité-type ASSOCIATIVE» j’ai consulté le lien ci-dessus il faudra que j’emprunte ce bouquin à la BU car effectivement mon bouquin grand débutant sur merise ne mentionne pas cette possibilité et la déclare même comme non autorisée de mémoire ! Il est fort probable que si la plus part des formateurs l’interdisent aux débutants c’est pour éviter de se retrouver avec des MCD trop souples avec des entités-types association à toutes les sauces et l’oublie d’élagage des ID de références comme dans le cas de MACU ?

Je ne sais pas comment votre IUT présente ses programmes, aussi ferai-je référence à ceux de l’IUT de Sceaux que j’ai récupérés sur la toile, en supposant que les principes d’organisation sont à peu près les mêmes que les vôtres. Si l’on y regarde de plus près (cf. le PDF page 5),

Effectivement la page 5 de IUT de Sceaux confirme un fonctionnement proche du notre néanmoins suite à une évolution des université (autonomie des universités) les PPN (Programme Pédagogique National ) évolue de façon différente d’un université à l’autre … et cela a des répercussion sur la façon de faire la sauce en interne d’où des PPN maisons ...

une UE ressemble bigrement à un simple regroupement de modules et l’on pourrait considérer ceux-ci comme des entités faibles relativement aux UE ( characteristics chez Codd), ce qui permet de simplifier la modélisation :

Oui effectivement une UE peut être considéré comm un regroupement de modules.

... Si je comprends bien, une UE ne concerne qu’une seule classe ….

Non dans mon cas une UE peut être affectée à plusieurs classes et plusieurs années d'où :

[CLASSE_ANNE]----0,N----(R)----0,N----[AU]

Les raisons qui m’avaient fait abandonner à tord l’idée d’affecter les UE directement à des classes hormis le PB lié à comment résoudre le cas de projections vides sont les 3 cas suivantes :

cas 1: En formation initiale (le jour) les élevés «classiques» appartenant à différents groupes d’une même année exemple :
- Année1_Groupe1, Année1_Groupe2 ...Année1_GroupeN … auront obligatoirement les mêmes UE.
- Année2_Groupe1, Année2_Groupe2 ...Année2_GroupeN .… auront obligatoirement les mêmes UE.

Cas du redoublement En formation initiale : Si un élève se rate il devra finir son année il y a 99% de chance que le redoublement soit refusé et qu’il doive valider son diplôme en cours du soir avec les PST.

Si toutes les sections avaient été dans ce cas précédent affecter les UE directement à des classes était le plus pratique mais malheureusement cela se complique avec :

En formation initiale les année spéciales qui eux font l’iut en 1 an et ou le «PPN maison » et réadapté à la section d’une année sur l’autre et adapté en fonction du profil de la classe.

cas 2 : AnnéeSpéciale_Groupe1, AnnéeSpéciale_Groupe2 & AnnéeSpéciale_GroupeN n’ont pas pas forcement les mêmes UE pendant la même année universitaire car on regroupe les élèves par section d’origine et donc in fine on a pas forcement le même PPN maison d’une année sur l’autre ...
Pas de redoublement possible en AS → PST pour valider sont diplôme si échec.

Cas 3 : En formation continue avec les PST (promotion sociale du travail) sur 1 à 5 ans on a uniquement 3 groupes :

- PST1 .
- PST2 .
- PST3 .

Il n’y a que 3 groupes avec un PPN maison qui évolue d’une année sur l’autre exemple les pst1 de 2012 n’auront pas les même UE ou modules que ceux de 2013 le directeur fait sa cuisine et adapte en fonction de plein de critères (effectifs, profs dispo, élèves ...).
Les élèves de formation initiale classiques & Année Spéciale ayant «échoués» leur DUT en respectivement 2 ou 1 an fermes + les formation continue PST (adultes salariés ….) vont pouvoir (re)passer leur modules manquants sous 5 ans pour valider leurs UE et donc obtenir leur DUT en ayant cumuler les crédits (ECTS), le redoublement étant un cas quasiment inexistant en formation continue de PST; le redoublement n’a pas de sens car peut compenser les modules de l’année N avec ceux de N+1 ou N-1 sous un maximum 5 ans … ou alors après on repart à 0.

devant une telle complexité de mise en œuvre j’avais :
- abandonné l’idée de départ d’affecter les UE directement aux classes + le fait de risquer des projections vides suite à vos explications.
&

N.B. Dans le cas de l’IUT de Sceaux, les codes permettant d’identifier les UE les modules et les catégories sont significatifs : je suppose que vous avez un système du même genre, auquel cas il faudrait prévoir les attributs ad-hoc dans les entités-types UE, MODULE et CATEGORIE, ce que je n’ai pas (encore) fait ci-dessus.

abandonné d’identifier les UE par le CODEUE ex ILAO1M (voir PDF PST1) pour l’UE informatique mais utilisant l’astuce de liste qui me permet de créer une multitude d’UE customisés en piochant dans la LISTEUES pour éviter les boulettes liés au saisies. In fine l’identificateur IDUE me permet de créer à partir des identificateurs CODEUE de LISTUES toutes les variantes d’UES que l’on peut vouloir enseigner et je conserve un historique (idem pour les modules) et je limite le risque de projections vides grasse à AU.

Si j’ai bien compris vos derniers MCD / MLD fsmrel c'est vrai pour un fonctionnement d’IUT d’il y a un an mais à ce jour mon IUT fonctionne selon les variations explicités ci-dessus et je dois le réadapter. In fine vos explications m’ont permis de bien avancé et de revenir d'une autre façon a l'idée générale de départ d'affecter des unités d'enseignements à des classes mais pour des années données sans risque de projections vides. J’ai donc réadapté et revu le tout afin d’obtenir une nouvelle mouture que je pense plus proche des besoins actuels de mon IUT et votre avis m’intéresse !

NOTE : Attention j'ai modifié le nom de l'identificateur LISTEMODULES pour être cohérent avec la façon de nommer l'identificateur de LISTEUES ainsi l'identificateur IDMODULE devient CODEMODULE.



(voir PDF ci joint plus facile à consulter au besoin)

L’utilisation d’un identifiant CODEUE pour identifier une UES est donc trop limitatif si on invente de nouveau CODEUE l'administration sera perdu, j’ai besoin d’avoir des variantes issues de la liste UES d’origines qui soient parlant tout en ayant la possibilité d’affecter une ou plusieurs IDUE à aucune ou plusieurs {annéeUniversitaire,CODECLASSE} de la liste d’entité-type association de R_y7 que l'on nommera CAU :

[(CLASSE_ANNE)]----0,N----[(R_y7)]----0,N----[AU]
[(CLASSE_ANNE)]----0,N----[(CAU)]----0,N----[AU]

Pour gérer les cas particuliers d’élèves ayant des équivalences dans les UE affectés ou des modules customisés je passe par la relation porteuse d’équivalence :
[(AE_LISTEINCRITS)]----0,N----(R/équivalence)---- 0,N----[(MACU_LISTEENSEIGNEMENTS)]

La contrainte CK_NOTATION se lit ainsi :
La projection sur les attributs EleveId, Annee, ClasseId de la jointure naturelle de NOTATION et UE doit être incluse dans EAK.
Le but est que l’on ne note pas un élève pour des modules d’UE qui ne font partie des UE de la classe dont il fait partie au fil des années.

J'avoue qu'il faut que je réfléchisse sur la partie contrainte dans le cadre de votre MLD pour mieux l’appréhender ... idem pour rebelotte ...

Cordialement sudtek.

[fsmrel]

Bonjour sudtek,

Il est fort probable que si la plus part des formateurs l’interdisent aux débutants c’est pour éviter de se retrouver avec des MCD trop souples avec des entités-types association à toutes les sauces et l’oublie d’élagage des ID de références comme dans le cas de MACU ?

Je pense plutôt que les formateurs ont été formés par des formateurs qui... etc., et l'on remonte ainsi aux origines de Merise (cf. le document fondateur Ministère de l'Industrie - Mission à l'informatique - Centre technique informatique - Méthode de définition d'un système d'informations - Fascicule 4, guide pratique pour l'élaboration des modèles de données et de traitements - juin 1979). Mais on est alors dans une approche franco-française. Pour l'anecdote, il y a 17 ans, pour le compte d’une grande banque française j’ai travaillé avec les Canadiens (ignorants de Merise) qui avaient pondu Silverrun (dont est issu Open ModelSphere), AGL avec lequel on modélisait sans MCD :

Extrait du modèle de cette époque :




Les Canadiens voulaient vendre l’AGL à la banque et celle-ci fut très impressionnée par leurs brillantes démonstrations, mais la direction des études mit une condition sine qua non : qu’on puisse d’abord représenter les choses sous forme d’un MCD merisien, avec ses rectangles et ses ovales. Nos Canadiens qui n’étaient pas au courant de nos habitudes franco-françaises se grattèrent l’occiput en se demandant ce que cette représentation graphique supplémentaire pouvait bien apporter, mais les affaires sont les affaires, ils donnèrent satisfaction à la banque, développèrent l’outil propre à représenter les ovales connectant les rectangles, et l’on eut le loisir de punaiser sur le mur le MCD :




Moralité : autre pays, autres moeurs...

j’avais [...] abandonné d’identifier les UE par le CODEUE ex ILAO1M

Attention, que les choses soient claires, "ILA01M" est un code significatif, propre à faire l’objet d’un identifiant alternatif, mais certainement pas de « l’identifiant » de l’entité-type UE, rôle dévolu à IDUE.

Structure de l’en-tête de l’entité-type UE :

IDUE    CODEUR    UeNom            ECTS
   1    ILA01M    Informatique       30

L’utilisateur accède à l’UE par son code : "ILA01M" (ou son nom : "Informatique"), mais au niveau de la base de données les relations entre tables ne mettent en jeu que l’attribut IDUE.

Cette façon de procéder vaut évidemment pour les autres entités-types : MODULE, ELEVE, CATEGORIE, PROFESSEUR etc.

Selon votre MCD c’est ainsi que vous procédez, votre attribut IDUE correspond à mon attribut UeId et leur domaine de valeurs est le même. On est bien en phase ?

Si on invente de nouveau CODEUE l'administration sera perdue.

Si vous lui donne le mode d’emploi, l’algorithme pour donner des valeurs à CODEUE, elle devrait quand même s’en sortir facilement...

[...]utilisant l’astuce de liste qui me permet de créer une multitude d’UE customisés en piochant dans la LISTEUES pour éviter les boulettes liées aux saisies.

Sans avoir vérifié de visu ce que vaut cette multitude, je me méfie de ce genre d’astuce dont on peut douter de la pérennité.
Quand on a besoin de créer une UE, on la crée au moment opportun, point barre comme disait mon adjudant. Si le code ou le nom sont erronés, on les corrige sans que cela ait une incidence sur la base de données, puisqu’on ne touche alors qu’à la table UE, donc de façon très localisée.

je limite le risque de projections vides grasse à AU.

Cela semble être corrélé au thème précédent.

Je conserve un historique.

Selon votre système, le CODEUE (entité-type LISTEUES) détermine une année A. Supposons que pour l’année A, le code et le libellé vaillent respectivement "ILA01M" et "Informatique" et ne bougent pas pour l’année A+1. A partir de A+1, code et libellé valent donc "ILA01M" et "Informatique", mais comment historisez-vous le fait que pour l’année A, le code et le libellé valaient "ILA01M" et "Informatique" ? Comment les choses se passent-elles quand pour l’année A+2 le code ne change pas, tandis que le libellé est modifié en "Introduction à l’informatique" ?

Oui effectivement une UE peut être considéré comme un regroupement de modules.

Néanmoins vous n’utilisez pas l’identification relative pour le signifier, mais ça n’est pas un problème, et bien qu’il ne joue pas de rôle déterminant le carrond MAU peut faire sa réapparition.

Dans mon cas une UE peut être affectée à plusieurs classes et plusieurs années.

Soit. Dans le MCD que je fais figurer ci-dessous, le carrond KAU correspond à votre association R_y7 (je me dispense du carrond AU qui ne joue pas de rôle déterminant).

MCD




MLD




Je rappelle la présence de la contrainte CK_EMACU :

La projection sur {EleveId, Annee, ClasseId} de la jointure de EMACU et KAU doit être incluse dans EAK.

Concernant les professeurs

Selon votre MCD, un professeur peut noter des élèves de classes/années qui ne sont pas les siennes, pour des UE ou des modules qui ne le concernent pas et pour lesquels il n’a pas la compétence. Si cela est possible, soit. Sinon, je propose la modélisation suivante, selon laquelle les contraintes valant pour les professeurs s’inspirent de celles qui valent pour les élèves.

MCD




MLD




Notez la contrainte CK_PMACU selon laquelle un professeur ne peut noter que des élèves de classes dans lesquelles il intervient.


N.B. Vos diagrammes deviennent difficiles à lire : vous pouvez éviter de tout y mettre et présenter des vues séparées (cas par exemple des adresses qui jouent un rôle tout à fait secondaire, mais concourent à l'obésité du MCD )


Nom des entités-types au singulier (vs pluriel) :

Un type d’entité (ou entité-type) est une classe d’entités ayant en commun un ensemble de propriétés. Le type d’entité ELEVE symbolise l’élève-type, lequel a pour propriétés (attributs) son nom, son prénom, sa date de naissance, etc. Quant à eux, les élèves proprement dits sont les entités, les instances (ou encore les occurrences) de la classe ELEVE. Tout cela pour dire qu’un nom d’entité-type s’écrit au singulier : ELEVE mais pas ELEVES. Cela vaut pour les autres entités-types telles que MODULE, PROFESSEUR, etc.


J'espère ne pas vous traumatiser outre mesure, une fois de plus : courage !

[sudtek]

Bonjour fsmrl,
désolé ne ne pas répondre à ton post plus rapidement mais j’ai le net en wimax et je suis en limite de réception donc régulièrement ma connexion est dans les choux …

Attention, que les choses soient claires, "ILA01M" est un code significatif, propre à faire l’objet d’un identifiant alternatif, mais certainement pas de « l’identifiant » de l’entité-type UE, rôle dévolu à IDUE.

Ok sur ce point.

L’utilisateur accède à l’UE par son code : "ILA01M" (ou son nom : "Informatique"), mais au niveau de la base de données les relations entre tables ne mettent en jeu que l’attribut IDUE.

Cette façon de procéder vaut évidemment pour les autres entités-types : MODULE, ELEVE, CATEGORIE, PROFESSEUR etc.

Selon votre MCD c’est ainsi que vous procédez, votre attribut IDUE correspond à mon attribut UeId et leur domaine de valeurs est le même. On est bien en phase ?

Oui j’ai procédé de cette façon pour les entités à 3 exceptions:

- CATEGORIE qui ne prendra que 4 états ou le code est significatif, unique et parlant {CM, TD, TP, EX} pour respectivement d’écrire les cours magistraux, travaux dirigés, travaux pratiques,examens.

-CLASSE qui ne prendra qu’une douzaine de codes significatifs et uniques -> la liste des classes dont le codage est immuable {as1, as2, pst1 …}.

-CODEUE qui me sert à stocker uniquement les ref à laquelle appartiennent les UE et les modules car j’ai trouvé cela plus pratique pour regrouper et appairer dans MAU les modules avec les UEs appartenant au même idCodeUE {ILA01M, …}. Du fait j’ai modifié le MCD :

Citation:
Envoyé par sudtek:«
[...]utilisant l’astuce de liste qui me permet de créer une multitude d’UE customisés en piochant dans la LISTEUES pour éviter les boulettes liées aux saisies.»

Sans avoir vérifié de visu ce que vaut cette multitude, je me méfie de ce genre d’astuce dont on peut douter de la pérennité.
Quand on a besoin de créer une UE, on la crée au moment opportun, point barre comme disait mon adjudant. Si le code ou le nom sont erronés, on les corrige sans que cela ait une incidence sur la base de données, puisqu’on ne touche alors qu’à la table UE, donc de façon très localisée.

Citation:
Envoyé par sudtek Voir le message:«Je conserve un historique.»

Selon votre système, le CODEUE (entité-type LISTEUES) détermine une année A. Supposons que pour l’année A, le code et le libellé vaillent respectivement "ILA01M" et "Informatique" et ne bougent pas pour l’année A+1. A partir de A+1, code et libellé valent donc "ILA01M" et "Informatique", mais comment historisez-vous le fait que pour l’année A, le code et le libellé valaient "ILA01M" et "Informatique" ? Comment les choses se passent-elles quand pour l’année A+2 le code ne change pas, tandis que le libellé est modifié en "Introduction à l’informatique" ?

Hum j’ai revu la copie car en fait je me suis rendu compte en comparant vos MCD et les miens que j’avais fait une liste de liste pour les UE et les modules et que c’est difficile à gérer … bref j’ai revu la copie et suis revenu sur un système plus simple comme vous le préconisiez → créer un module ou une UE quant on en à vraiment besoin car effectivement si l’appellation d’un module ou d’une UE change d’appellation «cosmétique» style «informatique» -> «informatique générale» on peut le modifier sans impacter la BD si c’est une modification plus profonde c’est que in fine il s’agit de nouveaux modules / UEs qui impliquent la création de module(s) et/ ou d’UE(s) indépendants.

En plus j’avais commis une erreur d’interprétation dans votre MCD entre EMACU (ancienne association PARTICPER) & MACU + commis une grosse erreur sur la cardinalité de l’association participer dans mon MCD :

|EAK_INSRIT|----(0,N)------(participer)------(1,1)-------|MACU_LISTENSEIGNEMENTS| -> FAUX

|EAK_INSRIT|----(0,N)------(participer)------(0,N)-------|MACU_LISTENSEIGNEMENTS| -> VRAI

d’ou l'entité EMACU pour connecter NOTATION & REBELOTTE :

|EAK|----(0,N)---(Rx)---(1,1)----|EMACU|----(1,1)----R(y)---(0,N)-------|MACU|

J'espère ne pas vous traumatiser outre mesure, une fois de plus : courage !

Non pas le moins du monde fsmrel ! C’est même l’inverse je suis très manuel & technique et j’ai besoin de manipuler pour intégrer je préfère de loin votre méthode qui consiste à guider en m’obligeant à refaire & réfléchir N fois les choix et structures de mon MCD que celle consistant à admettre des faits et des méthodes parachutées (méthode trop souvent pratiqué à l'iut) de but en blanc que in fine je n’intègre pas et qui m’embrouillent …

Vos posts me permettent à mon rythme de revoir point par point mon MCD en essayant de comprendre au fur et a mesure et d’intégrer toute vos observations sans «pomper idiomatiquement». Vos schéma me servent de référence. Mon but est de comprendre du coup cela me prend pas mal de temps de refaire et revoir mon MCD,de porter les modifs sur Acces et faire des tests (faire et défaire c’est toujours travailler ) A ce jour j’ai comptabilisé + de 30 modèles & révision de ce MCD dans ma poubelle ...
Maintenant que je commence à avoir un un MCD et MLD acces qui me semble plus fonctionnel que mes premiers tests je constate à posteriori quand 3 schémas vous aviez déjà un MCD bien plus aboutit, votre expériences comme vous l’avez dit liée à «l’analyse des tombereaux de MCD incomplets » vous permet de façon quasiment intuitive d’arriver à un MCD fonctionnel en quelques jets là ou le débutant s’arrache les cheveux … vous méritez bien votre qualification «Expert Confirmé Sénior» et votre notation de 10 points fsmrel !

La contrainte CK_NOTATION se lit ainsi :
La projection sur les attributs EleveId, Annee, ClasseId de la jointure naturelle de NOTATION et UE doit être incluse dans EAK.
Le but est que l’on ne note pas un élève pour des modules d’UE qui ne font partie des UE de la classe dont il fait partie au fil des années.

A propos des contraintes : J’ai une question concernant les contraintes en fait je comprends que celle ci expriment ni plus ni moins que des intersections (les bon vieux patatoides) entre entités afin d’éviter des produit cartésien possibles mais vide de sens et que l’on propose à l’utilisateur desc hoix pertinents. Cependant quand j’ai consulté la documentation microsoft en ligne ils stipulent que Acces ne peut pas intégrer de contrainte notés «CONTRAINTS» de base ! ai-je bien compris la doc Microsoft ? Donc je présume que l’on doit se débrouiller sous Acces avec uniquement des requêtes pour obtenir le même résultat que la contrainte, on à pas d'autres choix ?

Nom des entités-types au singulier (vs pluriel) :

Un type d’entité (ou entité-type) est une classe d’entités ayant en commun un ensemble de propriétés. Le type d’entité ELEVE symbolise l’élève-type, lequel a pour propriétés (attributs) son nom, son prénom, sa date de naissance, etc. Quant à eux, les élèves proprement dits sont les entités, les instances (ou encore les occurrences) de la classe ELEVE. Tout cela pour dire qu’un nom d’entité-type s’écrit au singulier : ELEVE mais pas ELEVES. Cela vaut pour les autres entités-types telles que MODULE, PROFESSEUR, etc.

Merci fsmrel pour ces précisions car en fait c’est un sujet qui fait toujours débats dans ma classe ... J’ai rectifié mes schéma en conséquence et j’ai aussi revu les appellations des attributs avec le même style de notation que les variables en prog IDMODULE → idModule


MLD : Je vais essayer de porter le MCD sous mysqlworkbench.

voici le MCD complet épuré.

Cordialement SUDTEK

A+


Note : Je joins en pièces jointe le PDF MCD seul + MCD avec les références pour le futur MLD de la version V10_7L.

[fsmrel]

Bonsoir sudtek,


J’espère qu’il vous reste des cheveux... En tout cas, bel effort de présentation.


Dans tous les cas de figure il est recommandé d’appliquer le principe de Tabourier, car on ne peut jurer de rien. Les codes attribués aux classes sont comme les numéros d’immatriculation des voitures, et suite à une fantaisie imprévue d’un hurluberlu en mal d’innovation, ils peuvent bêtement changer et là encore, seule une table doit être touchée, en l’occurrence la table CLASSE.

Quant aux catégories, d’accord il n’y en a que 4 aujourd’hui, mais combien demain ? Seront-ce exactement les mêmes ? Attention, le code catégorie figure dans plusieurs tables sensibles, donc les changements de valeurs seront à surveiller de près. Le code catégorie {IdCodeCategorie} sert à l’utilisateur comme point d’entrée dans le système, il n’est que clé alternative, car ensuite c’est avec la clé primaire de CATEGORIE, appelons-la {CategorieId} que seront effectuées les jointures avec MACU, EMACU, etc. Quand on voudra présenter l’attribut IdCodeCategorie, disons à l’affichage, on le récupèrera par jointure, sans afficher {CategorieId} qui ne signifie rien pour l’utilisateur.

Concernant l’entité-type CODEUE, je ne vois pas la valeur ajoutée qu’on lui doit. Pour que je comprenne mieux ce que vous en attendez, pourriez-vous illustrer en présentant quelques UE et modules (voir un paquet !) outre ce que vous avez déjà présenté et justifiant votre choix ? Pour le moment j’en reste à MAU comme étant le catalogue, le référentiel premier des couples {UE, module}, à partir duquel en relation avec UE et MODULE on peut créer une vue que l’on peut nommer CODEUE (n’oubliez les possibilités offertes par l’algèbre relationnelle).

Quant à l’entité-type NUMANNEE, je ne vois toujours pas son intérêt, ce qui la distingue de l’année universitaire. Là encore, des exemples seront les bienvenus.

Entité-type NOTATION :



Si un seul professeur donne une note disons à un TP, alors l’attribut IdProfesseur n’intervient pas dans l’identification de NOTATION, contrairement à votre représentation. A signaler que Equivalence fait aussi partie de EMACU.


Entité-type EAK_LISTEINSCRIT

A terme, vous pourrez renommer cette entité-type en INSCRIPTION. Le terme LISTE est mal venu, puisqu’une inscription ne concerne qu'un seul élève : Si listes il y a, ce sont des listes singletons... (Même chose pour toutes les entités-types où figure le mot LISTE).


Entité-type PROFESSEUR

Identification :

J’ai une question concernant les contraintes, en fait je comprends que celle ci expriment ni plus ni moins que des intersections (les bon vieux patatoïdes) entre entités afin d’éviter des produit cartésien possibles mais vide de sens et que l’on propose à l’utilisateur des choix pertinents.

Hum... Il ne s’agit pas d’intersection, mais d’inclusion !




(EMACU JOIN KAU) {EleveId, Annee, ClasseId} doit être un sous-ensemble de EAK {EleveId, Annee, ClasseId}.

Les produits cartésiens ex aussi sont étrangers à cette affaire.

Je répète : EAK donne la composition des classes en élèves au fil des ans. Si la jointure EMACU et KAU projetée sur EleveId, Annee, ClasseId n’était pas contenue dans EAK, cela voudrait dire que la base de données serait vérolée (et ça va vite !) Les remarques faites à propos de CK_EMACU valent pour CK_PMACU.

Quand j’ai consulté la documentation microsoft en ligne ils stipulent que Acces ne peut pas intégrer de contrainte notés «CONTRAINTS» de base !

Je connais mal ACCESS. Je sais que des contraintes au sein d’une table sont possibles (par exemple contraindre une date de fin à être postérieure à une date de début). En revanche, en ce qui concerne la contrainte CK_EMACU, la norme SQL propose la contrainte CREATE ASSERTION pour la mettre en œuvre. Les SGBD SQL ne proposent pas cette instruction et il faut en passer par des triggers. Dans le cas d’ACCESS, il apparaît que ceux-ci sont fournis avec ACCESS 2010, voyez par exemple l’article ici (l’auteur n’a quand même pas l’air bien convaincu par ce qui proposé).


En tout cas, le MCD a l’air de se stabiliser, le MLD est en vue !

[sudtek]

Bonjour fsmrel,

J’espère qu’il vous reste des cheveux... En tout cas, bel effort de présentation

Merci fsmrel, en fait ce qui me rend fou c'est pour faire les tableaux dans le posts avec les balise bbcode ci-dessous tous mes tableaux exemples sont décalés ! plus de deux heure que j'essaye tout un tas de balises et c'est toujours plus destroy ... je jette l'éponge mes tableaux ressembleront à rien désolé ...

A titre d'info j'ai commencé à bidouiller le 1er tuto de DB-main et effectivement il faut bien lire la doc ! Pour le MCD sur DB-main de ce projet je vais attendre d'avoir finaliser le MCD pour essayer de porter le MCD, en tous cas merci car le style de DB-main avec les flèches me convient bien !

Dans tous les cas de figure il est recommandé d’appliquer le principe de Tabourier, car on ne peut jurer de rien. Les codes attribués aux classes sont comme les numéros d’immatriculation des voitures, et suite à une fantaisie imprévue d’un hurluberlu en mal d’innovation, ils peuvent bêtement changer et là encore, seule une table doit être touchée, en l’occurrence la table CLASSE.

Quant aux catégories, d’accord il n’y en a que 4 aujourd’hui, mais combien demain ? Seront-ce exactement les mêmes ? Attention, le code catégorie figure dans plusieurs tables sensibles, donc les changements de valeurs seront à surveiller de près.

Le code catégorie {IdCodeCategorie} sert à l’utilisateur comme point d’entrée dans le système, il n’est que clé alternative, car ensuite c’est avec la clé primaire de CATEGORIE, appelons-la {CategorieId} que seront effectuées les jointures avec MACU, EMACU, etc. Quand on voudra présenter l’attribut IdCodeCategorie, disons à l’affichage, on le récupèrera par jointure, sans afficher {CategorieId} qui ne signifie rien pour l’utilisateur.

Oui effectivement après avoir consulté les posts très instructifs "sur les répartitions d'instances de processus et threads" ou vous expliquez entre autres le PB des changements de numérotations des plaques qui devait être immuable ... et puis comme vous le dites "suite à une fantaisie imprévue d’un hurluberlu en mal d’innovation ..." -> je vais modifier ces points et jouer la sécurité !

pour les entités :

Code :

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

1
2
3
4
CLASSE : { idClasse , codeClasse , libelleClasse }

   | idClasse | codeClasse | libelleClasse |
   |	1          |	PST1	         |    promotions sociale du travail|

Code :

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

1
2
3
4
CATEGORIE : {idCategorie , codeCategorie , libelleCategorie} 

| idCategorie | codeCategorie | libelleCategorie|
	1	 CM	cours magistraux

j’en reste à MAU comme étant le catalogue, le référentiel premier des couples {UE, module}, à partir duquel en relation avec UE et MODULE

Je suis d’accord sur ce point MAU doit rester le catalogue.

Concernant l’entité-type CODEUE, je ne vois pas la valeur ajoutée qu’on lui doit. Pour que je comprenne mieux ce que vous en attendez, pourriez-vous illustrer en présentant quelques UE et modules (voir un paquet !) outre ce que vous avez déjà présenté et justifiant votre choix ? Pour le moment j’en reste à MAU comme étant le catalogue, le référentiel premier des couples {UE, module}, à partir duquel en relation avec UE et MODULE on peut créer une vue que l’on peut nommer CODEUE (n’oubliez les possibilités offertes par l’algèbre relationnelle).

ATTENTION fsmrel je me suis aperçu que dans le précédent PDF (CARRARA) j’ai omis les explications concernant la construction d’un code UE ex: IAL01 ou d’un code de module ex:ILA011 j’ai malheureusement inséré une version précédente du PDF ou je n’avais pas porté les indications du coup j’ai zappé cette info en construisant le MCD désolé ... j’ai donc apporté une petite modif au MCD pour intégrer cet oublie !

Si on se réfère au bon PDF un code UE se décompose ainsi*:
ILA01 (note: on oublie le ‘m’ de ILA01m qui est un reliquat administratif de la feuille excel).

En théorie :
- Le premier chiffre de l'index représente le semestre → ici c’est 0 car en PST il n’y a pas de semestres (on verra un peut plus loin le pourquoi du 0).
- Le second chiffre représente le rang de l'UE dans le semestre une UE de rang 1 est plus importante que de rang 2 → 1 la plus importante.
Sauf qu’en pratique d’un point de vue administratif ils réfèrent les UE avec des codes du type ILA01; ILA02 ...ILA99n → 100 codes [00..99] en interne pour l’iut serait suffisant pour coder toutes les UE sauf que c’est l’université qui impose sa norme à l’IUT → le code significatif est ILAxy ou x,y sont des chiffres de [0..9] . In fine codeUE est arbitrairement fixé par un humain, les codes UE PST sont tous de la forme ILA0y autrement dit semestre 0 alors que la formation dure de 1 à 5 ans maxi il s'agit d'un cas particulier -> pour les AS ou élevés classiques ILA0yz n’existe pas !

Pour les AS (années spéciales) comme leur enseignement dure 1 an (2 semestres) il y a uniquement des codes UE du type IAL1y à IAL2y.

Pour les élèves comme leur enseignement dure 2 ans (4 semestres) il y a uniquement des codes UE du type IAL1y à IAL4y.

Un module lui est une codification composée du code UE ex du PDF précédent : ILA01z avec z un chiffre de [0à9] qui indique le rang du module dans le semestre une UE , un module de rang 1 est plus importante qu'un de rang 2.

En fait dans la précédente version 10_7L du MCD sans CODEUE j'avais peur que l'utilisateur lors de la création ou la màj d’UE ou modules introduise fortuitement des variantes. Variantes qu’in fine dans MAU feront qu'un module appartenant par exemple à "CONNAISSANCES ET COMPETENCES GENERALES" (codeue ILA02) risque d'être lié un jour à tord avec "INFORMATIQUE" (codeUE ILA01) voir ne pourra être lié faute de codeUE sur une faute de typo ex: ILA01M & ILAO1M ,le coup du 0 <->O est un classique. Donc en obligeant l'utilisateur à "lier" à la création l'UE et le module à leur CODEUE respectifs je pensai :

- Contingenter les effets de bords entre autres liés à la case et aux pb de typo ... mais suite au cas des plaques minéralogiques je me rends compte que je déplace une partie du risque sur CODEUE "si un hurluberlu en mal d’innovation ..." me change la codification des CODEUE, pour ne pas dire que cela me pend au nez avec l'administration ... -> retour à la cas départ.

- Faciliter l’appairage des modules VS UE dans MAU, un module ne pouvant plus être associer à une UE qui n'appartient pas au même codeUE.

Donc pour m’affranchir des problèmes de codifications dans mon MCD V10_7 expérimentalement j’ai introduit CODEUE, et idCodeUE suivant les principe de tabourier ainsi c'est idCodeUE se retrouve dans MAU par identification relative et m’évite en plus une jointure dans MAU sur idCodeUE .

Code :

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

1
2
3
4
5
CODEUE : {idCodeUE , codeUE , semestreUE , rangUE , libelleCodeUE }

| idCodeUE | codeUE | semestreUE | rangUE | libelleUE |
     1     ILA    0    1    informatique

Code :

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

1
2
3
4
5
6
7
8
MODULE : { idModule , idCodeUE, libelleModule , rangModule , coef , choix , idCNU , idTypeEpreuve , idNumAnnee}

| idModule | idCodeUE| libelleModule | rangModule | coef | choix | idCNU | idTypeEpreuve | idNumAnnee |
    3     1    algo    1    3    Obl    27    1    1
.............................................................................................................
    5    1    algo     2    2    Obl    27     1    1
    6    1    algo    3    2    Obl    27    1    1

Code :

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

1
2
3
4
5
6
UE  : {idUE , idCodeUE , ects , idNumAnnee}

| idUE | idCodeUE | ects | idNumAnnee |
...............................................................
    9    1    30    1

Code :

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

1
2
3
4
5
6
MAU  : { idAnneeUniversitaire , idUE , idModule , idCodeUE }

| idAnneeUniversitaire | idUE | idModule | idCodeUE |
    2014    9    3    1
    2014    9    5    1

Pour obtenir les MCD suivants sur MAU :



& le MLD :




suite sur le prochain post car j'ai atteint le maximum de pièces jointes !

[sudtek]

Reprise du post précédent ...

En comparaison de la solution précédente voici la version V10_7M ou codeUE, semestres et rang sont integrés à UE et rang à module :

Le MCD :


MCD + MLD :

Quant à l’entité-type NUMANNEE, je ne vois toujours pas son intérêt, ce qui la distingue de l’année universitaire. Là encore, des exemples seront les bienvenus.

C'est un reliquat administratif qui aide l'administration à composer et équilibrer les modules et les UE étant donné que les classes en fonction de leurs codeClasse ne font pas l'IUT au même rythme. On peut dire que NUMANNEE alias l'année à laquelle appartiennent un module ou une UE est déconnectée de l'année universitaire. Les journées ayant un nb d'heures incompressibles du fait un AS qui fait l'iut en 1 AN doit en «*théorie*» sortir avec le même PPN qu'un élevé classique (Ex_Gx) en 2ans ou un PST en 1 à 5 ans.

Je pense que ce qui vous embrouille en fait c'est l’appellation administrative NUMANNEE qui n'est pas des plus heureuses à mon avis je lui préfère le terme niveau. Elle est juste la pour aider à différencié les modules ou UEs quasi identiques



exemple pour 2 modules d’algo :
Le module avec idModule = 1 est un module de rang* 1 de 3 eme année il appartient à une UE ILA05 du coup il se codifie en ILA051.

Le module avec idModule = 8 est un module de rang* 1 de 1er année il appartient à une UE ILA01 du coup il se codifie en ILA011.
*note : Le rang n’apparaît pas ds la copie d’écran car j’avais zappé les rangs …

Indiquer l’année permet d’éviter de mal appairer un module et une UE car l’administration à fait l’idiotie de coller le code semestres des PST à 0 pour toute la durée des études …. ce qui empêche de savoir pour l’UE quand elle est réellement dispensée en lisant uniquement le code semestre et du coup j’ai du conserver le NUMANNE pour administrativement bien appairer … de plus je laisse la porte ouverte pour basculer quand il le souhaite avec des code semestres différents de 0 en PST sans perturber la codification puisque l’on à introduit un idCodeUE.

A titre d’info voici le Trythme scolaire normal :
Ex_Gx : 1 an
AS : 2 ans
PST : 1 à 5 on constate qu’il y a bien plusieurs trimestres et pas 0 …

Si un seul professeur donne une note disons à un TP, alors l’attribut IdProfesseur n’intervient pas dans l’identification de NOTATION, contrairement à votre représentation. A signaler que Equivalence fait aussi partie de EMACU.

bien vu ... un copier coller malheureux pour idprofesseur et pour equivalence j'ai oublié de le supprimer il était bien dans EMACU -> rectifié !

Entité-type EAK_LISTEINSCRIT
A terme, vous pourrez renommer cette entité-type en INSCRIPTION. Le terme LISTE est mal venu, puisqu’une inscription ne concerne qu'un seul élève : Si listes il y a, ce sont des listes singletons... (Même chose pour toutes les entités-types où figure le mot LISTE).

→ Élimination du mot LISTE du MCD*!
→ entité-type en INSCRIPTION. Renommé*!

Entité-type PROFESSEUR Identification : Leprof est identifié par son adresse ?

... un copier coller malheureux de plus ... -> rectifié !

Je connais mal ACCESS. Je sais que des contraintes au sein d’une table sont possibles (par exemple contraindre une date de fin à être postérieure à une date de début). En revanche, en ce qui concerne la contrainte CK_EMACU, la norme SQL propose la contrainte CREATE ASSERTION pour la mettre en œuvre. Les SGBD SQL ne proposent pas cette instruction et il faut en passer par des triggers. Dans le cas d’ACCESS, il apparaît que ceux-ci sont fournis avec ACCESS 2010, voyez par exemple l’article ici (l’auteur n’a quand même pas l’air bien convaincu par ce qui proposé).

Je connais très mal Access du coup hier soir j'ai lancé pour la première fois visual studio 2010 pour essayer de réimporter un test de conversion du tuto1 de db-main voir mon post à ce propos (http://www.developpez.net/forums/d13...s/#post7473991). MVS2010 m'a l'air d'une belle usine à gaz mon pc a failli faire un malaise vu le temps de chargement sur ma petite config ... bref j'ai vu que MVS2010 intègrè une gestion SQL plus avancé qu'ACCESS mais j'ai pas été foutu de réexporter vers une bd ACCESS. Merci pour le tuyaux sur Acces 2010 je pourrai le récupérer le mois prochain avec réactivation de mon MSDNA car j'ai un serial officiel education mais pas l’ISO que j’ai oublié de telecharger avant juillet.


Concernant les contraintes demain je vais faire une compilation de vos posts y faisant références et les imprimer pour mieux appréhender le tout.

Merci pour votre patiente fsmrel*!

Cordialement SUDTEK

pièces jointes*: V10_7M VS V10_7M_Experimental



Ps: Existe t'il un moyen de faire lever le nombres limite de 5 images maxi pour les posts ?

[fsmrel]

Bonsoir sudtek,

ce qui me rend fou c'est pour faire les tableaux dans le posts avec les balise bbcode ci-dessous tous mes tableaux exemples sont décalés ! plus de deux heure que j'essaye tout un tas de balises et c'est toujours plus destroy ... je jette l'éponge mes tableaux ressembleront à rien désolé ...

En principe, si vous utilisez la balise [code] ou la balise [pre], une police COURIER, si vous vous abstenez des tabulations et si vous vous contentez d’utiliser des espaces comme ci-dessous, vous ne devriez pas avoir de problème (sinon c'est que la bureautique vous en veut...) :



=>

ClasseId....ClasseCode....ClasseNom
.......1....PST1..........Promotion sociale du travail

Et n’oubliez pas de définir la clé alternative {ClasseCode} :



=>




En toute rigueur, ci-dessous il faudrait remplacer « magistraux » par « magistral ».

idCategorie    codeCategorie    libelleCategorie 
          1    CM               cours magistraux 

Je vais essayer de parcourir le dédale de votre codification des UE et modules...


En attendant, sauf siouxerie cachée et concoctée par les administratifs, je constate que l’on en revient à peu de choses près au scénario de l’IUT de Sceaux.

Une partie racine, pour construire les codes des UE et des modules :

IdCodeUE    CodeRacineUE
       1    ILA

Les UE, faisant référence aux racines :

IdUE    IdCodeUE    Semestre    RangUE    Ects    LibelleUE 
   1           1           0         1      30    Informatique 
   2           1           0         2      15    Connaissances générales

Les modules, identifiés relativement aux UE :

IdUE    IdModule    Rang    LibelleMod      Coef    ....
   1           1       1    Algo & prog        3    ....
   1           2       2    Architecture       2    ....
   1           3       3    Outils             1    ....

A la dimension temporelle près, qu’est-ce qui ne va pas dans ce montage où "ILA" n'apparaît qu'une fois ?

[sudtek]

Bonjour fsmrel,

En principe, si vous utilisez la balise [code] ou la balise [pre], une police COURIER, si vous vous abstenez des tabulations et si vous vous contentez d’utiliser des espaces comme ci-dessous, vous ne devriez pas avoir de problème (sinon c'est que la bureautique vous en veut...) :

Merci pour l’info fsmrel oui honte à moi je l’avoue j’ai tabulé … -> prochain tableau je collerai des ‘.’ de bourrages.

et n’oubliez pas de définir la clé alternative {ClasseCode} :

J’ai découvert votre excellente publication elle m’a permis de mieux appréhender l’utilité et le principe de l’identification relative par rapport l’identification absolue. J’avoue ne pas avoir encore pu lire tout le PDF c’est une énorme mine d’information et cela fait sacré morceaux à ingurgiter, mais petit à petit je vais le lire et le relire.

P15 du pdf « ...les principales clefs alternatives celles qui sont connues par l’utilisateur sont soulignées en trait discontinue ...» La clef alternative est nommée AK pour alternative key _> ok.

Ce qui peut me donner pour CLASSE :

Code :

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

1
2
3
4
5
6
7
8
9
10
 CREATE TABLE CLASSE {
	idClasse smallint unsigned NOT NULL,
	codeClasse varchar (15) NOT NULL,
	libelleClasse varchar(30) NOT NULL,
	idTypeFormation smallint unsigned NOT NULL,
	CONSTRAINT CLASSE_PK PRIMARY KEY (idClasse),
	CONSTRAINT CLASSE_AK UNIQUE (codeClasse),
	CONSTRAINT CLASSE_AF FOREIGN KEY (idTypeFormation) REFERENCES (idTypeFormation)
	
};

Je comprends que d’un point de vue humain PST1 cela «parle» plus qu’un numéro et que codeClasse et une alternative à idClasse dans le code ci-dessus.

Ce que je ne comprends pas bien c’est du point de vue de CLASSE_ANNE :

Dois-je considérer codeClasse comme une FK au même titre que idClasse ou est-ce que la portée de codeClasse est contingenté à CLASSE ?

En quoi une vues n’est-elle pas suffisante d’un point de vue utilisateur qui mérite que l’on introduise une clef alternative ?

En toute rigueur, ci-dessous il faudrait remplacer « magistraux » par « magistral ».

Je comprends car l’identificateur idCategorie de CATEGORIE ne caractérise qu’un MACU donnée.

A la dimension temporelle près, qu’est-ce qui ne va pas dans ce montage où "ILA" n'apparaît qu'une fois ?

Effectivement comparé à la solution V10_7M il n’y a pas redondance sur le codeUE et on peut évacuer MAU → via l’identification relative on gagne de la place et on renforce la cohérence des relations. Dans V10_7M j’avais supputé que j’y gagnerai à ne pas avoir de redondance sur le codeUE en cas de màj du coup j’avais créé l’équivalent de la racine via CODEUE mais j’ai maladroitement vider UE de ses attributs (semestreUE ,
rangUE, libelleUE) et en conservant MAU …

J’ai refait le MCD +MLD que vous suggérez, effectivement en relatif cela simplifie grandement les relations et in fine on retombe à un chouia prés sur votre toute première solution mais au moins petit à petit j’appréhende mieux les raisons pour les quelles vous favorisez le système relatif à l’absolu, qui pour un débutant n’a rien de trivial.



Cordialement SUDTEK

[fsmrel]

Bonsoir sudtek,

Je comprends que d’un point de vue humain PST1 cela «parle» plus qu’un numéro et que codeClasse et une alternative à idClasse dans le code ci-dessus.

Il est un fait que codeClasse c’est pour l’utilisateur et idClasse pour (entre autres) la stabilité et la pérennité de la base de données (principe de Tabourier). Si un jour il prend fantaisie à notre hurluberlu de remplacer PST par XYZTUVA, les dégâts seront limités à une table.

Dois-je considérer codeClasse comme une FK au même titre que idClasse ou est-ce que la portée de codeClasse est contingenté à CLASSE ?

Ciel ! Si codeClasse faisait l’objet d’une clé étrangère, on ficherait par terre le principe de Tabourier... Je vous renvoie à nouveau à l’exemple du numéro Siren des entreprises, transmis par l’INSEE. L’utilisateur accède aux données de la table ENTREPRISE au moyen du Siren des entreprises, mais ensuite les promenades dans la foule des tables en relation avec ENTREPRISE se font au moyen de requêtes dans lesquelles ne figure que {EntrepriseId}, invariant.

Une valeur de la table CLASSE :

idClasse    codeClasse    libelleClasse                      idTypeFormation
       1          PST1    promotion sociale du travail 1                   3
       2          PST2    promotion sociale du travail 2                   3 

Une valeur de la table CLASSE_ANNEE, CodeClasse y est interdit de séjour :

idClasse    Annee
       1     2010
       1     2011
       1     2012
       2     2010
       2     2011
       2     2012 

Pour présenter l’équivalent à l’utilisateur :

Code SQL :

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

1
2
SELECT codeClasse, Annee
FROM   CLASSE AS x JOIN CLASSE_ANNEE AS y ON x.idClasse = y.idClasse ;

=>

codeClasse    Annee
PST1           2010
PST1           2011
PST1           2012
PST2           2010
PST2           2011
PST2           2012 

Requête que vous pouvez emballer dans une vue avec les rubans qui vont bien, à l’intention de l’utilisateur :

Code SQL :

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

1
2
3
CREATE VIEW CLASSE_ANNEE_V (codeClasse, Annee) AS
    SELECT codeClasse, Annee
    FROM   CLASSE AS x JOIN CLASSE_ANNEE AS y ON x.idClasse = y.idClasse ;

Et pour présenter le résultat ci-dessus, il suffit de coder :

Code SQL :

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

1
2
SELECT codeClasse, Annee 
FROM CLASSE_ANNEE_V ;

En quoi une vues n’est-elle pas suffisante d’un point de vue utilisateur qui mérite que l’on introduise une clef alternative ?

Je ne comprends pas ce que vous voulez dire...

petit à petit j’appréhende mieux les raisons pour les quelles vous favorisez le système relatif à l’absolu, qui pour un débutant n’a rien de trivial.

Certes, au départ l’identification relative peut dérouter, et certains vieux routiers ne veulent même pas entendre parler...


En tout cas, votre MCD évolue dans le bon sens, il a bien maigri par rapport à ce qu'il était au départ...


N.B. Pour avoir du SQL en couleur, utilisez la balise [Code=SQL].