Discussion :

[sudtek]

Bonjour fsmrel,
J’ai repris la version précédente 10_7M et suis passé à la version 10_7N suite à la suppression de MACU. J’ai profité du changement pour renommer CODEUE en CODERACINE ainsi que les attributs de cette dernière idCodeUe → idCodeRacine & codeUE → codeRacine.

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.

ok donc sur le même principe j’ai comme AK*:

CLASSE {… codeClasse ...}
CODERACINE {… codeRacine …}
CODERACINE {… codeCategorie …}

Concernant REBELOTTE & NOTATION j’ai un doute car d’un point de vue humain le fait d’utiliser des timeStamps* ne me permet pas de mieux appréhender une note donnée mais idRebelotte & idNotation caractérisent bien à elle seule leurs tables respectives. Je serais tenter d’en faire des AK !?

REBELOTTE {… idRebelotte …}
NOTATION {...idNotation ...}

*Note : L’utilisation de timeStamp est obligatoire car il y a un pb récurent entre prof et administration pour savoir qui bloque la "machine" et quand les notes ont été transmises ... le fait qu’ils se renvoient la balle systématiquement est devenu si saoulent qu’un type timeStamp devrait couper court à ce petit jeux.

… Ciel ! Si codeClasse faisait l’objet d’une clé étrangère, on ficherait par terre le principe de Tabourier...

En fait ce qui m’a fait poser cette question c’est l’id prime qui apparaît de façon identique à id d’un point de vue graphique …



Je ne comprenais pas comment vous pouviez faire la distinction entre une PK et une AK au risque d'en faire une FK mais maintenant je comprend que votre soft comme dans Dbmain fait apparaître la différences via les références et vous permet de faire la distinction entre une PK,FK,AK et ne pas importer la AK qui reste contingenter à sa table ! Mon soft simpliste lui ne me permet pas de distinguer une AK d’un PK → sur mon schéma j’ai donc surligné les AK en pointillé bleu pour pas les mélanger avec le reste du MLD ...vivement que je passe ce MCD sur dbmain !

Citation:
Envoyé par sudtek
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...

En fait je n’avais pas bien compris l’intérêt d’utiliser l’AK si on passait par une vue dont le but est de masquer la complexité de la requête mais en fait l’AK vous permet de simplifier la requête propre à la vue. Si j’avais du coder la vue j’aurai été obligé de faire une autre requête pour ressortir le tout en codeClasse à partir de idClasse ... le moins que l’on puisse dire c’est que cela n’aurait pas été optimisé contrairement à votre solution !
Vos exemples de requêtes via l’AK suivi d’une vue l’intégrant sont clairs merci fsmrel.

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

Sans votre intervention il aurait pu se passer pas mal de temps avant que j’en entende parler … pire après que les habitudes ont été prises il est très difficile de faire machine arrière … je vais voir la modélisation MCD d’un œil nouveau.

Cordialement SUDTEK

ci joint la version V10_7N MCD+MLD au format PDF

[fsmrel]

Bonsoir sudtek,

sur le même principe j’ai comme AK :
CLASSE {… codeClasse ...}
CODERACINE {… codeRacine …}
CODERACINE {… codeCategorie …}

J’ai lu CODERACINE {… codeCategorie ...}

Concernant REBELOTTE & NOTATION j’ai un doute car d’un point de vue humain le fait d’utiliser des timeStamps* ne me permet pas de mieux appréhender une note donnée mais idRebelotte & idNotation caractérisent bien à elle seule leurs tables respectives. Je serais tenter d’en faire des AK !?
*Note : L’utilisation de timeStamp est obligatoire car il y a un pb récurent entre prof et administration pour savoir qui bloque la "machine" et quand les notes ont été transmises ... le fait qu’ils se renvoient la balle systématiquement est devenu si saoulent qu’un type timeStamp devrait couper court à ce petit jeux.

IdNotation est un attribut qui permet de distinguer chaque note pour un quintuplet {Eleve, Annee, UE, Module, Categorie}, IdNotation démarre à 1 pour chaque valeur du quintuplet (application de l’identification relative) : la clé de la table NOTATION dérivée de l’entité-type NOTATION est donc le sextuplet {Eleve, Annee, UE, Module, Categorie, IdNotation}. Si vous faisiez de IdNotation une clé alternative, quelle serait la clé primaire de la table ? Par ailleurs, faire une clé de IdNotation ne servirait à rien, car la note associée n’a pas de sens prise isolément, elle ne prend son sens que par rapport au quintuplet. Quant au timestamp, pas de problème, à chaque fois qu’une note est insérée dans la table, elle est accompagnée de son timestamp :

NOTATION {Eleve, Annee, UE, Module, Categorie, IdNotation, Note, Horodatage}

C'est-à-dire :

Au cours de l’année A, dans le module M de l’UE U et dans la catégorie C, l’élève E a obtenu la note N et ceci a été consigné dans la base de données à l’instant H.

Maintenant est-ce la faute du prof ou de l'administration, la table ne le dit pas, mais comme le chargement des notes ira à toute vitesse, peut-être n'y aura-t-il plus de prises de bec ?

Je sens qu’on n’est quand même pas très loin de passer à l’examen du MLD...

N.B. N’oubliez pas vos crayons de couleur pour décolorer les codes postaux.

[sudtek]

Bonsoir fsmrel,

J’ai lu CODERACINE {… codeCategorie ...}

oups … la malédiction du copier coller a encore frappé … donc on à pour clef alternative alias AK :

CLASSE {… codeClasse ...}
CODERACINE {… codeRacine …}
CATEGORIE {… codeCategorie …}

…comme le chargement des notes ira à toute vitesse, peut-être n'y aura-t-il plus de prises de bec ? ...

Ils vont bien trouver un «autre truc» je leur fais entièrement confiance sur ce point !

… chaque note pour un quintuplet {Eleve, Annee, UE, Module, Categorie}, IdNotation démarre à 1 pour chaque valeur du quintuplet (application de l’identification relative) ...

Si on a plusieurs IdNotation qui peuvent prendre la valeur 1 pour différents quintuplets, IdNotation ne peut pas être candidate pour être une clef primaire et donc à forcerie elle peut encore moins prétendre au «titre» de clef alternative ... j’avais pas intuité cela ! du coup :

Code :

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

1
2
3
4
5
6
|..Annee..|..UE..|..Module..|..Categorie..|..Eleve..|..IdNotation..|.. valeurNote..|.. codeAbsence..|..
...2013......1.........3............4...........1............1...........10,20..........NULL......
...2013......1.........3............4...........1............2...........10,20..........NULL......
...2013......1.........3............4...........2............1...........13,00..........NULL......
...2013......1.........3............5...........2............1...........13,00..........NULL......

Je sens qu’on n’est quand même pas très loin de passer à l’examen du MLD...

Effectivement voici l'ébauche du MLD hors contraintes AGL entre les entités :

ELEVE (idEleve, nomEleve, prenom1Eleve, prenom2Eleve, datenaissance, telEleve, emailEleve, #idAdresse)

PROFESSEUR (idProfesseur, loginProfesseur, passwordProfesseur, nomProfesseur, prenomProfesseur, emailProfesseur, telProfesseur, #idAdresse)

VILLE (idVille, nomville)

CODEPOSTAL (idCodePostal)

VC (#idVille, #idCodePostal)

ADRESSE (idAdresse, adresse1, adresse2, #idCodePostal, #idVille)

CODERACINE (idCodeRacine ,codeRacine) avec codeRacine → AK

UE (idUE, semestreUE, rangUE, libelleUE, ectsUE, #idCodeRacine)

MODULE (idModule, #idUE, libelleModule, rangModule, coefModule, choixModuel, #idCNU, #idTypeEpreuve)

CNU (idCNU, libelleCNU)

TYPEEPREUVE (idTypeEpreuve, libelleEpreuve)

TYPEFORMATION (idTypeFormation, libelleFormation, modaliteFormation)

CATEGORIE (idCategorie, codeCategorie, libelleCategorie) avec codeCategorie → AK

CLASSE (idClasse ,codeClasse, libelleClasse, #idTypeFormation) avec codeClasse → AK

ANNEEUNIVERSITAIRE (idAnneUniversitaire)

MACU_ENSEIGNEMENT (#idAnneUniversitaire, #idUE, #idModule, #idCategorie, volumeHoraireMC)

EMACU_PARTICIPER (#idAnneUniversitaire ,#idUE, #idModule, #idCategorie, #idEleve, equivalence)

PMACU (#idAnneUniversitaire, #idUE, #idModule, #idCategorie, #idProfesseur, volumeHoraireMC)

NOTATION (#idAnneUniversitaire, #idUE, #idModule, #idCategorie, #idEleve, idNote, valeurNote, codeAbsence, horodatage)

REBELOTTE (#idAnneUniversitaire, #idUE, #idModule, #idCategorie, #idEleve, idRebelotte, rebeloteAnnee)

CLASSE_ANNEE (#idAnneUniversitaire, #idClasse)

PAK_AFFECTERPROF (#idAnneUniversitaire, #idProfesseur, #idClasse)

INSCRIPTION (#idAnneUniversitaire, #idEleve, #idClasse)

KAU (#idUE, idAnneUniversitaire, #idClasse)

Cordialement SUDTEK

[fsmrel]

Bonsoir sudtek,

voici l'ébauche du MLD hors contraintes AGL entre les entités

D’accord. Je n’avais pas vu la 2e page de votre PDF du 18 septembre dernier, donc quand j’ai écrit : « Je sens qu’on n’est quand même pas très loin de passer à l’examen du MLD... », en fait il était là !

Cette fois-ci j’ai examiné la 2e page de votre dernier PDF : à quelques bricoles près, tout va bien.

N.B. La 2e page du PDF suffit, ne perdez pas de temps à coder quelque chose de redondant du style :

ELEVE (idEleve, nomEleve, prenom1Eleve, prenom2Eleve, datenaissance, telEleve, emailEleve, #idAdresse)

En effet, il n’y a visiblement là aucune valeur ajoutée.

Vous parlez d’« AGL » : ne confondriez-vous pas avec « SGBD » ?

Quelques remarques :

NULL est interdit de séjour dans une base de données qui se respecte. En conséquence, la relation entre ELEVE et ADRESSE comportant une cardinalité 0,1, elle fera l’objet d’une table au stade SQL (cela vaut évidemment pour la relation entre PROFESSEUR et ADRESSE) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
ELEVE {IdEleve, NomEleve, ...}
    PRIMARY KEY {IdEleve}
    ...
 
ADRESSE {IdAdresse, adresse1, adresse2, idCodePostal, idVille}
    PRIMARY KEY {IdAdresse}
    FOREIGN KEY {idCodePostal, idVille} REFERENCES VC
 
ELEVE_ADRESSE {IdEleve, IdAdresse}
    PRIMARY KEY {IdEleve}
    FOREIGN KEY {IdEleve} REFERENCES ELEVE
    FOREIGN KEY {IdAdresse} REFERENCES ADRESSE

Table CODE_POSTAL :

Conformément au principe de Tabourier, l’attribut IdCodePostal est non significatif : il faudrait donc ajouter un attribut (faisant l’objet d’une clé alternative) pour le code postal lui-même, sinon les courriers vont être incomplets...


Table CNU : même chose, il n’y a pas d’attribut significatif pour les CNU ?

Table TYPE_EPREUVE : même remarque.

Table TYPE_FORMATION : même remarque.

Table PROFESSEUR : les professeurs n’ont pas de matricule (ou équivalent) ?

Table ELEVE : même remarque.


Table par table, on parlera aussi de l’ordre des attributs dans les clés, sur la base des traitements les plus lourds et les plus fréquents (il y va de la performance de l’application, donc de votre réputation ). En attendant, il faudrait déjà inverser cet ordre pour la clé de MATRICULE, puisque de toute manière, conceptuellement c'est une entité-type faible, identifiée relativement à UE.


Sinon, le MCD tient la route, souhaitons que votre ténacité et votre ardeur soient récompensés...

[sudtek]

Bonsoir fsmrel,

… j’ai examiné la 2e page de votre dernier PDF : à quelques bricoles près, tout va bien.

Merci fsmrel, mais j’avoue humblement que sans votre investissement ce MCD et son MLD ne seraient que l’ombres d’eux mêmes !

souhaitons que votre ténacité et votre ardeur soient récompensés...

Certains de mes collègues ont survolées nos posts et l’avancement du MCD et m’ont poliment fait comprendre que je me prenais selon eux «la tête pour rien» car comme à l’accoutumé l’IUT allait survoler 90% du travail rendu. De mon point de vue je considère ce projet et les posts de ce sujet comme importants et peut m’importe si in fine l’IUT survole mon travail. Je réalise ce projet du mieux possible pour entre autres ,capitaliser et que cela me servent d’expérience et de référentiel pour la bonne pratique de mes prochains MCD. J’estime que lorsqu’une personne et a forcerie lorsqu’il s’agit d’un professionnel avec votre expérience s’investi pour m’aider je me dois de faire de mon mieux pour lui prouver que son investissement n’a pas été vain.

N.B. La 2e page du PDF suffit, ne perdez pas de temps à coder quelque chose de redondant du style :
ELEVE (idEleve, nomEleve, prenom1Eleve, prenom2Eleve, datenaissance, telEleve, emailEleve, #idAdresse)
En effet, il n’y a visiblement là aucune valeur ajoutée.

C’est le type de présentations d’un MLD qu’attend l’IUT → je me contenterai de l’inclure dans mon rapport.

Vous parlez d’« AGL » : ne confondriez-vous pas avec « SGBD » ?

Je faisais référence à cela :

Exprimer en français : 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.
…

Je voulais dire que pour l’instant je n’ai pas encore eut le temps de me pencher sur l’expression des contraintes et du code SQL afin de créer les contraintes CK inter entités comme dans l’exemple ci-dessus.

NULL est interdit de séjour dans une base de données qui se respecte. En conséquence, la relation entre ELEVE et ADRESSE comportant une cardinalité 0,1, elle fera l’objet d’une table au stade SQL (cela vaut évidemment pour la relation entre PROFESSEUR et ADRESSE) :
[code] ELEVE {IdEleve, NomEleve, ...}
PRIMARY KEY {IdEleve}
...

ADRESSE {IdAdresse, adresse1, adresse2, idCodePostal, idVille}
PRIMARY KEY {IdAdresse}
FOREIGN KEY {idCodePostal, idVille} REFERENCES VC

ELEVE_ADRESSE {IdEleve, IdAdresse}
PRIMARY KEY {IdEleve}
FOREIGN KEY {IdEleve} REFERENCES ELEVE
FOREIGN KEY {IdAdresse} REFERENCES ADRESSE[code]

Je jure que jamais un des mes profs ne m’a parlé de cela … !

|ELEVE|----(0,1)----R----(1,N)----|ADRESSE|
idEleve ….....................................idAdresse

du coup cela reviendrait à obtenir le MCD équivalent ? :

|ELEVE|----(0,1)----R----(1,1)----|ELEVE_ADRESSE|----(1,1)----R----(1,N)----|ADRESSE|
idEleve …...................................#idEleve,#idAdresse…..................................idAdresse

(idem pour adresse et professeur !)

Table CODE_POSTAL :
Conformément au principe de Tabourier, l’attribut IdCodePostal est non significatif : il faudrait donc ajouter un attribut (faisant l’objet d’une clé alternative) pour le code postal lui-même, sinon les courriers vont être incomplets...

Et cela prémunie dans le temps d’un évolution du codePostal avec les normes européennes ...

codePostal
| idcodePostal | codePostal |
….......1...............31400......
….......2...............31500......
...

codepostal devient ainsi une AK pour codePostal !

Table CNU : même chose, il n’y a pas d’attribut significatif pour les CNU ?

je propose cette modification :
CNU
| idCNU | codeCNU | libelleCNU
…...1..........00........Pas de CNU
…...2..........27........Informatique
…...3..........25........Mathématiques
...
codeCNU devient l’AK de CNU.

Table TYPEEPREUVE : même remarque.

TYPEEPREUVE je l’avais fait selon se modèle et l’identificateur est bien conforme au principe de tabourier :

TYPEEPREUVE
| idTypeEpreuve | libelleEpreuve |
….......1..................contrôle final
….......2..................contrôle continue
….......3..................examem
…

mais peut être aurais-je du introduire un attribut codeTypeEpreuve afin d’avoir une AK plus facile à manipuler par un humain que la PK ? :

TYPEEPREUVE
| idTypeEpreuve | codeTypeEpreuve | libelleEpreuve |
….......1...........................CF..........contrôle final
….......2...........................CC..........contrôle continue
….......3...........................EX..........examem
…

Table TYPE_FORMATION : même remarque.

en fait je détecte un pb sur TYPEFORMATION j’ai oublié l’attribue codeFormation que j’ai mis dans libelleFormation et j’ai zappé les libellés ….
L’attribut modaliteFormation ne pouvant prendre que 2 valeurs j’ai choisi un type enum car cette table ne contiendrait jamais plus d’une dizaine de valeur

TYPEFORMATION (table erronée)
| idTypeFormation | libelleFormation | modaliteFormation |
….…....1...................AS....................formation initiale
….…....2...................HTO..................formation continue
.........3...................conventionné......formation continue
...

Table qui aurait du être intégré au MCD :

TYPEFORMATION
| idTypeFormation | codeFormation | libelleFormation | modaliteFormation |
….…....1......................AS..............Année spéciale........................formation initiale
….…....2......................HTO............Hors temps ouvrable.................formation continue
….......3......................CON............Conventionnée........................formation continue
….…....4......................ASA............Année spéciale en alternance.....formation initiale
...

D’après ce que vous m’avez expliqué ce n’est pas une bonne idée il vaudrait mieux les séparer en 2 entités distinctes :

|CLASSE |---(1,1)----R---(0,N)---|TYPEFORMATION |---(1,1)----R---(0,N)---|MODEFORMATION|

et modifier les entités ainsi :

TYPEFORMATION
| idTypeFormation | codeFormation | libelleFormation |
….…....1......................as...............Année spéciale
….…....2......................hto.............Hors temps ouvrable
….......3......................con.............Conventionnée
….…....4......................asa.............Année spéciale en alternance
…

TYPEFORMATION (# idTypeFormation, codeFormation, libelleFormation,#idModeFormation) et AK → codeFormation

MODEFORMATION
| idModeFormation | codeModeFormation | libelleModeFormation |
….…....1.......................fc............................formation continue
….…....2.......................fi.............................formation initiale
…

TYPEFORMATION (# idModeFormation, codeModeFormation, libelleModeFormation)
et AK → codeModeFormation

Table PROFESSEUR : les professeurs n’ont pas de matricule (ou équivalent) ?

Table ELEVE : même remarque.

Bien vu fsmrl les élèves on effectivement un matricule (N° d’étudiant) en fait je l’avais zappé car je n’en voulait pas comme PK car trop instable dasn le temps et du coup je ne l’ai pas réintégré dans l’entité …. pour les profs je l’ignore mais petite anecdote l’administration à quand même réussi à inverser les salaires de 2 professeurs homonymes de grades différents … On peut le rajouter je pense car cela doit exister mais je pense que l’administration l’a simplement omis de leur BD à moins qu’ils ventile encore les salaires à la main pour toute l’université ce qui n’est pas non plus improbable …
→ Ajout des identificateurs matriculeEleve matriculeProfesseur à leurs tables respectives.
→Je pense que matriculeEleve & matriculeProfesseur peuvent également faire de bonne clef alternatives !

Table par table, on parlera aussi de l’ordre des attributs dans les clés, sur la base des traitements les plus lourds et les plus fréquents (il y va de la performance de l’application, donc de votre réputation ). En attendant, il faudrait déjà inverser cet ordre pour la clé de MATRICULE, puisque de toute manière, conceptuellement c'est une entité-type faible, identifiée relativement à UE.

Feriez-vous référence au principe dit de «dispersion» où sauf erreur de ma part on ordonnance les attributs de la clef du plus dispersé vers le moins dispersé dans le SGBD ?

Cordialement SUDTEK

PS : Pièce jointe MCD + MLD V10_7_O au format PDF

[fsmrel]

Bonsoir sudtek,


Pendant que j’y pense, quel est votre SGBD ?

Certains de mes collègues ont survolées nos posts et l’avancement du MCD et m’ont poliment fait comprendre que je me prenais selon eux «la tête pour rien»

sudtek :




Des collègues de sudtek :




Quelqu’un qui ne leur veut pas que du bien :


Naf-Naf s’est-il vraiment pris la tête pour rien ?

Je voulais dire que pour l’instant je n’ai pas encore eut le temps de me pencher sur l’expression des contraintes et du code SQL afin de créer les contraintes CK inter entités

D’accord. Mais on a affaire à des contraintes de l'application et non pas de l’AGL (DB-MAIN, POWER AMC, etc.) ou du SGBD (DB2, SQL Server, etc.)

Il s’agit d’un point qui se traite en SQL avec l’instruction CREATE ASSERTION. Si le SGBD ne connaît pas cette instruction, alors ça sera avec l’instruction CREATE TRIGGER (l’usine à gaz, car il faut penser non seulement aux ajouts dans les tables NOTATION et UE, mais aussi aux modifications et suppressions altérant ces tables ainsi que la table EAK : ça n'est pas trivial, en plus ça peut être SGBD dépendant, mais on ne construit pas en paille...)

Je jure que jamais un des mes profs ne m’a parlé de cela … !

Et pourtant ça permet d’éviter des accidents sur le terrain des bases de données opérationnelles. Plus une entité-type est porteuse de pattes à cardinalité 0,1 et plus ça craint (j’en ai fait le constat à l’occasion d’audits que j’ai eus à faire)...

|ELEVE|----(0,1)----R----(1,N)----|ADRESSE|
idEleve ….....................................idAdresse

du coup cela reviendrait à obtenir le MCD équivalent ? :

|ELEVE|----(0,1)----R----(1,1)----|ELEVE_ADRESSE|----(1,1)----R----(1,N)----|ADRESSE|
idEleve …...................................#idEleve,#idAdresse…..................................idAdresse

Attention, j’ai montré que la clé primaire de la table ELEVE_ADRESSE est {IdEleve}, or vous l’avez définie ainsi : {IdEleve, IdAdresse}, cela voudrait dire qu’un élève peut avoir plus d’une adresse, contrairement à ce qu’exprime la cardinalité maximale 1 de votre MCD, en conséquence de quoi IdAdresse doit dégager de la clé primaire.


A noter qu’une adresse peut être celle d’un prof à laquelle n’habite pas forcément un élève : il faudrait remplacer 1,N par 0,N.

codepostal devient ainsi une AK pour codePostal !

Gagné !

De même, {CodeCNU} est une clé alternative pour la table CNU (et non pas la clé alternative, car en théorie {LibelleCNU} est aussi clé alternative).

Je vois que CodeCNU peut prendre la valeur 0 signifiant « pas de CNU » : c’est du 0,1 déguisé...

peut être aurais-je du introduire un attribut codeTypeEpreuve afin d’avoir une AK plus facile à manipuler par un humain que la PK ?

Il faut le faire (à cheval), car l’utilisateur sera content de pouvoir codifier, voire changer selon son bon plaisir les valeurs de CodeTypeEpreuve.

j’ai choisi un type enum

Ce qui n’est pas une bonne idée dans le contexte des bases de données relationnelles, si tant est que le type ENUM soit disponible (il ne fait pas partie de la théorie relationnelle et concernant SQL il est SGBD dépendant).

D’après ce que vous m’avez expliqué ce n’est pas une bonne idée il vaudrait mieux les séparer en 2 entités distinctes :

|CLASSE |---(1,1)----R---(0,N)---|TYPEFORMATION |---(1,1)----R---(0,N)---|MODEFORMATION|

Oui !

Pour la forme, je relève deux petites coquilles.
Dans :

TYPEFORMATION (#idTypeFormation, codeFormation, libelleFormation,#idModeFormation)

Le 1er dièse est en trop.

Dans :

TYPEFORMATION (#idModeFormation, codeModeFormation, libelleModeFormation)

Remplacer TYPEFORMATION par MODEFORMATION.

Attention, dans le cas des bases de données relationnelles, votre emploi du symbole «→ » peut prêter à confusion, car ce symbole est celui de la dépendance fonctionnelle. Par ailleurs, une clé est un ensemble, y-compris en ce qui concerne le nom des attributs, d’où l’emploi recommandé des accolades « { » et « } », même dans le cas des singletons, exemple : {codeModeFormation}.

Je pense que matriculeEleve & matriculeProfesseur peuvent également faire de bonne clef alternatives !

Non seulement ils peuvent, mais ils doivent !

Feriez-vous référence au principe dit de «dispersion» où sauf erreur de ma part on ordonnance les attributs de la clef du plus dispersé vers le moins dispersé dans le SGBD ?

A supposer qu’un tel principe existe (et que j'ai compris ce que vous entendez par ça), il ne vaut qu’à moitié. Par exemple, dans un système à caractère essentiellement transactionnel où l’on fait de la prise de commande intensive (par définition en temps réel) :

— Si le plus souvent on crée de nouveaux clients en même temps que les commandes qu'ils passent, on risque des verrouillages de pages de l’index (branché sur la table Client) de clé {ClientId} en utilisant l’auto-incrémentation de l’attribut ClientId (identifiant de la table CLIENT) : on peut donc être amené à éparpiller les clients dans l’espace mémoire lors de leur saisie, autrement dit éviter de les regrouper dans un « cluster ». En revanche, on a tout intérêt à regrouper dans la même page les commandes d’un client en fonction de la valeur prise par l’attribut ClientId, afin de réduire les accès disque à l’occasion de la recherche des commandes du client.

— Si au contraire on a peu de nouveaux clients mais de nombreuses commandes de la part de clients fidèles, cette fois-ci on risque des verrouillages de pages de l’index branché sur la table des commandes (j’ai vécu ça) en utilisant l’auto-incrémentation de l’attribut IdCommande (identifiant de la commande) : contrairement à ce qui se passe dans le scénario précédent, ce sont les commandes que l’on peut donc être amené à éparpiller dans l’espace mémoire lors de leur saisie, et éviter de les regrouper dans un « cluster ». En revanche, on a tout intérêt à regrouper dans la même page les lignes d’une commande en fonction de la valeur prise par l’attribut IdCommande, afin de réduire les accès disque là aussi.

En fait, tout ceci repose sur les épaules du DBA qui effectue les réglages non pas à partir de théories mais sur la base d’un prototypage ad-hoc de performances, une fois qu’il aura exigé qu’on lui fournisse les requêtes correspondant aux opérations de mise à jour et de consultation les plus sensibles.

Anyway, on y croit ! Tant pis pour le loup

[sudtek]

Bonjour fsmrel,

Sympa la BD !

D’accord. Mais on a affaire à des contraintes de l'application et non pas de l’AGL (DB-MAIN, POWER AMC, etc.) ou du SGBD (DB2, SQL Server, etc.)

Je reformule pour être sur d’avoir bien compris : La ou les contraintes de l’application que l’on constate dans le MCD doit/doivent être adapter en langage SQL ou propriétaire pour le SGBD.

j’y pense, quel est votre SGBD ?

J’ai MYSQL qui est fonctionnel comme SGBD sur mon vieux portable asthmatique et ça fonctionne; si je me reporte au post :

" l'instruction CREATE ASSERTION ... n'est pas implémenté par MySQL ni par des masses de SGBD d'ailleurs

Donc je vais devoir en passer par les triggers ...

Plus une entité-type est porteuse de pattes à cardinalité 0,1 et plus ça craint

Est-ce pour cette raison d’un point de vue relationnel :
ELEVE.................ADRESSE
| idEleve |.............| idadresse |.....
…...1............................9.............
…...2.........................NULL.......
…...3.........................NULL.......

Attention, j’ai montré que la clé primaire de la table ELEVE_ADRESSE est {IdEleve}, or vous l’avez définie ainsi : {IdEleve, IdAdresse}, cela voudrait dire qu’un élève peut avoir plus d’une adresse, contrairement à ce qu’exprime la cardinalité maximale 1 de votre MCD, en conséquence de quoi IdAdresse doit dégager de la clé primaire.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
PRIMARY KEY {IdEleve}
    ...

ADRESSE {IdAdresse, adresse1, adresse2, idCodePostal, idVille}
    PRIMARY KEY {IdAdresse}
    FOREIGN KEY {idCodePostal, idVille} REFERENCES VC

ELEVE_ADRESSE {IdEleve, IdAdresse}
    PRIMARY KEY {IdEleve}
    FOREIGN KEY {IdEleve} REFERENCES ELEVE
    FOREIGN KEY {IdAdresse} REFERENCES ADRESSE

A noter qu’une adresse peut être celle d’un prof à laquelle n’habite pas forcément un élève : il faudrait remplacer 1,N par 0,N.

OK donc :

|ELEVE|----(0,1)----R----(0,N)----|ADRESSE|
idEleve ….....................................idAdresse

deviendrait :

|ELEVE|----(0,1)----R----(1,1)----|ELEVE_ADRESSE|----(1,1)----R----(0,N)----|ADRESSE|
{idEleve}..................................{#idEleve,#idAdresse}…................................{idAdresse }

Un ELEVE a au minimum aucune ADRESSE et a au maximum une ADRESSE.
Une ADRESSE appartient au minimum à aucun ELEVE (Car elle peut être affecté à un PROFESSEUR) et appartient au maximum à un seul ELEVE.
(idem pour professeur)

Mais du coup d’un point de vue bonne pratique dois-je modifier le MCD avec le complément MCD ou puis-je me contenter de fournir une explication + le schéma équivalent de remplacement pour garder une trace et justifier l'évolution du MLD ?

Je vois que CodeCNU peut prendre la valeur 0 signifiant « pas de CNU » : c’est du 0,1 déguisé...

donc :

|MODULE|----(1,1)----(R)----(0,N)----|CNU|

CNU { idCodeCNU}
MODULE {idModule, #idCodeCNU}

mais est ce à dire que l’on obtinedrait cela ?
|MODULE|----(1,1)----(R)---(1,1)---|MODULE_CNU|----(1,1)---(R)----(0,N)----|CNU|

et ce MLD ? :
MODULE_CNU {#idModule, #idCodeCNU}

Il faut le faire (à cheval), car l’utilisateur sera content de pouvoir codifier, voire changer selon son bon plaisir les valeurs de codeTypeEpreuve.

je généralise l’idée.

Attention, dans le cas des bases de données relationnelles, votre emploi du symbole «→ » peut prêter à confusion, car ce symbole est celui de la dépendance fonctionnelle

Je comprends, je vais devoir m’en passer pour éviter les confusions.

Par ailleurs, une clé est un ensemble, y-compris en ce qui concerne le nom des attributs, d’où l’emploi recommandé des accolades « { » et « } », même dans le cas des singletons, exemple : {codeModeFormation}.

J’ai remplacé les () du post par des {} idem dans mon pré rapport*!

...En fait, tout ceci repose sur les épaules du DBA qui effectue les réglages non pas à partir de théories mais sur la base d’un prototypage ad-hoc de performances, une fois qu’il aura exigé qu’on lui fournisse les requêtes correspondant aux opérations de mise à jour et de consultation les plus sensibles.

Merci fsmrel c’est très instructif en fait on fait du tests de charges réel et orienté pour confirmer ou infirmer si la méthode choisie est adaptée.

Cordialement SUDTEK

[fsmrel]

Bonsoir sudtek,

Je reformule pour être sur d’avoir bien compris : La ou les contraintes de l’application que l’on constate dans le MCD doit/doivent être adapter en langage SQL ou propriétaire pour le SGBD.

Oui. La contrainte que j’ai fait figurer :



Est rédigée en Tutorial D (matrice des vrais langages relationnels).
Il faut donc traduire en SQL (ou autre langage si vous n’utilisez pas SQL) ce qui est rédigé en Tutorial D et, si l’on suit la norme, on fait appel à l’instruction CREATE ASSERTION. Si le SGBD ne propose pas cette instruction, il faudra en passer par l’instruction CREATE TRIGGER comme vous vous proposez courageusement de le faire, même si, comme je l’ai écrit précédemment, c’est beaucoup moins facile à coder :

l’usine à gaz, car il faut penser non seulement aux ajouts dans les tables NOTATION et UE, mais aussi aux modifications et suppressions altérant ces tables ainsi que la table EAK : ça n'est pas trivial, en plus ça peut être SGBD dépendant, mais on ne construit pas en paille...

J’ai MYSQL

Aïe !

Est-ce pour cette raison d’un point de vue relationnel :
ELEVE.................ADRESSE
| idEleve |.............| idadresse |.....
…...1............................9.............
…...2.........................NULL.......
…...3.........................NULL.......

Oui. Je me souviens d’un audit que j’avais fait chez les grands magasins Tartempion, où très vite je vis que l’entité-type ARTICLE était un soleil autour duquel dansaient (entre autres) une quinzaine d’entités-types satellites pour lesquels en guise de rayons partaient du soleil des pattes à cardinalité 0,1. Cela se traduisait par une table ARTICLE dont la vision du contenu à l’écran était celle du vide sidéral... A part la clé {ArticleId} et le libellé de l’article, pratiquement rien que du noir... Et encore, le libellé n’aurait pas eu besoin d’être présent, car redondant, recomposable au moyen d’algorithmes tordus appliqués à d’autres données de la base de données... Quoi qu’il en fut, la table ARTICLE comportait quelques centaines de milliers de lignes, valorisées seulement à peine à 10% (NULL oblige !), sans oublier la quinzaine d’index utilisés pour les clés étrangères. Exemple de satellite « bouffant » un index : ce qu’on appelait le stock national :

[ARTICLE]----0,1----(ASN)----0,N----[STOCK_NATIONAL]

Or la table STOCK_NATIONAL contenait une dizaine de lignes, nanars d’une époque très lointaine mais pouvant encore servir, sait-on jamais...

Après intervention de ma part, le MCD est, vous vous en doutez, devenu :

[ARTICLE]----0,1----(R1)----(1,1)----[ASN]----1,1----(R2)----0,N----[STOCK_NATIONAL]

Et la table ASN contenait à tout casser une trentaine de lignes, une misère...

En procédant ainsi pour les autres satellites, on fit un gain plus que substantiel en ressources (quinze index, 15 colonnes pour la table ARTICLE), on éjecta le bonhomme NULL, on rendit les traitements incomparablement plus performants, et tout ça, tout ça... Et ce genre de constat combien de fois l'ai-je fait chez mes clients !

OK donc :

|ELEVE|----(0,1)----R----(0,N)----|ADRESSE|
idEleve ….................................idAdresse

deviendrait :

|ELEVE|----(0,1)----R----(1,1)----|ELEVE_ADRESSE|----(1,1)----R----(0,N)----|ADRESSE|
{idEleve}...............................{#idEleve,#idAdresse}…..........................{idAdresse}

Un ELEVE a au minimum aucune ADRESSE et a au maximum une ADRESSE.
Une ADRESSE appartient au minimum à aucun ELEVE (Car elle peut être affecté à un PROFESSEUR) et appartient au maximum à un seul ELEVE.
(idem pour professeur)

Oui. A noter que lorsque les cardinalités 1,1 sont entre parenthèses, cela signifie (avec PowerAMC) que l’identification est relative (voyez l’association ASN ci-dessus). Le mieux serait donc que vous écriviez :

|ELEVE|----0,1----R----(1,1)----|ELEVE_ADRESSE|----1,1----R----0,N----|ADRESSE|

Où l’identification relative vaut seulement pour l’association entre ELEVE et ELEVE_ADRESSE.

Pour qu'il n'y ait pas de jaloux chez les AGL, mettez l'association R entre parenthèses, car en leur absence c'est la façon qu'a WinDesign de signifier l'identification relative...

Mais du coup d’un point de vue bonne pratique dois-je modifier le MCD avec le complément MCD ou puis-je me contenter de fournir une explication + le schéma équivalent de remplacement pour garder une trace et justifier l'évolution du MLD ?

Le MCD est plus un support de lecture vous permettant de discuter avec les utilisateurs et vous pouvez donc éviter de le surcharger, en conservant :

|ELEVE|----0,1----(ELEVE_ADRESSE)---- 0,N----|ADRESSE|

Étant entendu que de son côté le MLD est inconnu des utilisateurs, et c’est lui votre support pour causer avec le DBA : changement de chanson, cette fois-ci ELEVE_ADRESSE est bien une table. Ne pas oublier que le MLD sert à la production du script de création des tables SQL.

Je vois que CodeCNU peut prendre la valeur 0 signifiant « pas de CNU » : c’est du 0,1 déguisé...

donc :

|MODULE|----(1,1)----(R)----(0,N)----|CNU|

CNU { idCodeCNU}

MODULE {idModule, #idCodeCNU}

mais est ce à dire que l’on obtinedrait cela ?

|MODULE|----(1,1)----(R)---(1,1)---|MODULE_CNU|----(1,1)---(R)----(0,N)----|CNU|

et ce MLD ? :

MODULE_CNU {#idModule, #idCodeCNU}

Du moment que la cardinalité est 1,1 et non pas 0,1, vous pouvez légitimement au niveau SQL conserver le lien direct entre MODULE et CNU, on reste dans la logique bivalente qui prévaut depuis la nuit des temps (NULL nécessite pour sa part une logique trivalente propre à ficher la patouille).

en fait on fait du tests de charges réel et orienté pour confirmer ou infirmer si la méthode choisie est adaptée.

Attention à bien choisir les requêtes et plus généralement les traitements que vous allez expertiser tout en sachant qu’il pourra y avoir conflit entre deux requêtes, donc arbitrage de votre part pour décider de la requête à privilégier...

[fsmrel]

Hello sudtek,

No news... Les choses avancent-elles comme vous le souhaitez ?

[sudtek]

Bonjour fsmrel,

No news... Les choses avancent-elles comme vous le souhaitez ?

Oui cela avance mais petit à petit en fonction du temps de libre , une denrée rare ...

Oui. A noter que lorsque les cardinalités 1,1 sont entre parenthèses, cela signifie (avec PowerAMC) que l’identification est relative (voyez l’association ASN ci-dessus). Le mieux serait donc que vous écriviez :
|ELEVE|----0,1----R----(1,1)----|ELEVE_ADRESSE|----1,1----R----0,N----|ADRESSE|
Où l’identification relative vaut seulement pour l’association entre ELEVE et ELEVE_ADRESSE.

Ha pour le coup vous anticipez ma prochaine question qui était Comment faire la distinction entre identification relative et absolu sur le MCD ? Donc j’ai procédé de la même façon pour signaler les autres identifications relatives du MCD.

Le MCD est plus un support de lecture vous permettant de discuter avec les utilisateurs et vous pouvez donc éviter de le surcharger, en conservant :
|ELEVE|----0,1----(ELEVE_ADRESSE)---- 0,N----|ADRESSE|
Étant entendu que de son côté le MLD est inconnu des utilisateurs, et c’est lui votre support pour causer avec le DBA : changement de chanson, cette fois-ci ELEVE_ADRESSE est bien une table. Ne pas oublier que le MLD sert à la production du script de création des tables SQL.

OK donc MCD ; MLD ; SCRIPT (SQL , …).

Du moment que la cardinalité est 1,1 et non pas 0,1, vous pouvez légitimement au niveau SQL conserver le lien direct entre MODULE et CNU

OK.

J’ai apporté les diverses modifications voir PDF binder.
cette semaine je vais essayer de :
- Le porter sur ACCESS pour voir si globalement cela convient au directeur.
- Attaquer de faire le script pour mySQL.
- Continuer à rédiger et formaliser le rapport.

Mille mercis pour votre aide fsmrel !

Cordialement SUDTEK

[fsmrel]

Bonsoir sudtek,

J’ai apporté les diverses modifications voir PDF binder.

C’est du sérieux !


Remarques :

1) La patte connectant CLASSE_ANNEE à l’association avec CLASSE est porteuse d’une cardinalité 1,1 à mettre entre parenthèses (pages 1 et 2 du PDF).

2) Il y a un copier-coller à corriger (nom de table « ELEVE_PROFESSEUR ») à moins qu’un élève puisse enseigner (la modélisation, par exemple ).

3) L’association connectant INSCRIPTION et ANNEE_UNIVERSITAIRE est redondante et doit disparaître car l’année universitaire est déjà connue par l’association connectant INSCRIPTION et CLASSE_ANNEE (pages 1 et 2 du PDF).

4) Ci-dessous le lecteur est-il censé savoir que AK est l’abréviation de Alternate Key ? (même chose pour les autres abréviations figurant dans le PDF) :

ELEVE {idEleve, matricule Eleve, nomEleve, prenom1 Eleve, prenom2Eleve, datenaissance, telEleve, emailEleve, #idAdresse} avec matriculeEleve pour AK

5) Chez les joueurs de belote, « rebelote » ne comporte qu’un seul « t ». Cela dit, ce terme est plutôt familier, peut-être faudra-t-il trouver un autre nom plus sérieux...

6) Si vous en avez le temps et le courage, vous pourriez factoriser les propriétés communes aux élèves et aux professeurs (nom, prénom, téléphone, adresse, ...) et effectuer une généralisation des entités-types ELEVE et PROFESSEUR en PERSONNE (ça vous pose un concepteur...) :

MCD



Vous noterez dans ce MCD que PROFESSEUR et ELEVE ont seulement des identifiants alternatifs (EleveMatricule, ProfMatricule, Login (si 2 profs ne peuvent pas avoir le même login)) mais pas d’identifiant « primaire » puisque celui-ci est hérité de PERSONNE et sera présent au niveau MLD, en l’occurrence avec comme clé primaire {PersonneId} (rien ne vous empêche à ce stade de remplacer le nom PersonneId par IdProfesseur (table PROFESSEUR) d’une part et IdEleve d’autre part (table ELEVE)).

MLD




A suivre...

[sudtek]

Bonjour fsmrel,

1) La patte connectant CLASSE_ANNEE à l’association avec CLASSE est porteuse d’une cardinalité 1,1 à mettre entre parenthèses (pages 1 et 2 du PDF).

Oups un oublie … merci fsmrel , c’est corrigé !

2) Il y a un copier-coller à corriger (nom de table « ELEVE_PROFESSEUR ») à moins qu’un élève puisse enseigner (la modélisation, par exemple).

Non effectivement c’est pas encore le cas, c’est corrigé !

3) L’association connectant INSCRIPTION et ANNEE_UNIVERSITAIRE est redondante et doit disparaître car l’année universitaire est déjà connue par l’association connectant INSCRIPTION et CLASSE_ANNEE (pages 1 et 2 du PDF).

Une fois de plus vous anticipez ma question fsmrel … exit la relation redondante.

4) Ci-dessous le lecteur est-il censé savoir que AK est l’abréviation de Alternate Key ? (même chose pour les autres abréviations figurant dans le PDF) :
ELEVE {idEleve, matricule Eleve, nomEleve, prenom1 Eleve, prenom2Eleve, datenaissance, telEleve, emailEleve, #idAdresse} avec matriculeEleve pour AK

J’ai commencé à rédiger une partie de mon rapport ou les abréviations sont expliquées au fur et à mesure de leurs apparitions. Je n’ai pas pu le joindre en intégralité car l’export d’un googledoc au format PDF est très lourd (images au format PNG et non vectorielles). Je joindrais le PDF final qui lui sera allégé (baisse des résolutions graphiques des images) pour l’instant il n’y aura que le lien en consultation via googledoc. Le pré rapport peut être consulté en permanence via ce lien

5) Chez les joueurs de belote, « rebelote » ne comporte qu’un seul « t ». Cela dit, ce terme est plutôt familier, peut-être faudra-t-il trouver un autre nom plus sérieux...

Oui effectivement j’ai vu aussi que dans le MLD j’avais saisi « rebelooteAnne » … j’ai choisi un nom plus simple et plus parlant pour l’entité*: REDOUBLE {idRedouble , redoubleAnne}

6) Si vous en avez le temps et le courage, vous pourriez factoriser les propriétés communes aux élèves et aux professeurs (nom, prénom, téléphone, adresse, ...) et effectuer une généralisation des entités-types ELEVE et PROFESSEUR en PERSONNE (ça vous pose un concepteur...) :

Le courage c’est pas un soucis, le pb c’est que mon soft de dessein ne peut pas faire cela ... néanmoins comme je viens d’apprendre que l’on va faire du windesign bientôt je porterai le MCD factorisé dessus dés réception de la licence education du soft et j’intégrerai la nouvelle version au rapport. Ainsi j’aurai une trace de l’évolution du MCD et cela me permettra de me faire la main sur le soft windesign.

J’ai bien avancé sur le portage Acces mais j’ai des soucis purement liés a l’utilisation d’Acces. J’ai le même problème dans différentes parties du MLD lors du passage en mode données mais pour mieux illustrer mon pb j’ai extrait dans un nouveau fichier au format Acces 2003 le cas typique qui « coince » . Lorsque dans le MLD ci-dessous je désire sélectionner code postal et ville depuis ADRESSE dans VC.






Je constate que malgré le fait d’utiliser l’identification relative et avoir fixé dans VC les couples {#idCodepostal, #idVille} Acces me propose de choisir des idVille qui ne sont pas en relation avec l’idCodePostal de VC … faut il faire une requête pour lui dire de limiter la liste des propositions en fonction de l’idCodePostal sélectionné ?


Cordialement SUDTEK.

[fsmrel]

Bonsoir sudtek,


Je regarderai à tête reposée...

Juste une remarque en attendant : l'attribut idProfesseur n'a pas été propagé jusqu'à la table NOTATION, alors qu'il doit participer à la clé étrangère en relation avec PMACU (mais pas à la clé primaire de NOTATION).

A plus tard

[fsmrel]

Bonsoir sudtek,

je viens d’apprendre que l’on va faire du WinDesign

En voilà une nouvelle qu’elle est bonne !

Lorsque dans le MLD ci-dessous je désire sélectionner code postal et ville depuis ADRESSE dans VC.

Quand on exécute une instruction du genre SELECT idCodePostal, idVille FROM VC ; bien que je ne connaisse pas ses possibilités hors SQL, je suppose qu’ACCESS montre le contenu de chaque colonne sans préjuger de ce que vous voulez en faire et se met en sommeil une fois que vous avez le contrôle des opérations, en se contentant d’attendre que vous lui repassiez la main. Quand vous le réveillerez pour lui dire « Voilà, je crée une adresse en ayant renseigné tous les attributs de la table ADRESSE », ce n’est qu’à ce moment-là qu’ACCESS effectuera tous les contrôles qui lui ont été sous-traités, il s’assurera notamment que l’intégrité référentielle est bien respectée par rapport à VC : si pour une adresse vous avez choisi une paire {idCodePostal, idVille} qui n’existe pas dans VC, au hasard <75001, Toulouse>, votre tentative de création échouera. Si vous voulez qu’ACCESS ne montre que les villes en relation avec un code postal, alors il faut le réveiller dès que le code postal sera saisi, avant qu'on puisse choisir la ville.

Ça me rappelle le comportement du logiciel de musique CUBASE il y a 20 ans : quand je saisissais une note, disons une croche, dans une mesure encore vierge, avant que j’ai eu le temps de saisir la note suivante, au nom du respect de la mesure, CUBASE avait déjà complété (je dirai pollué) la mesure avec plein de silences que je devais effacer un par un, au fil de la saisie de mes propres notes. De guerre lasse, j’ai laissé tomber le poids lourd CUBASE pour un logiciel plus léger mais incomparablement plus convivial et, ce qui ne gâte rien, coûtant 10 fois moins cher.

Au cas où la façon de procéder de Via Michelin vous inspirerait pour le mode de choix de villes en fonction du code postal... :





A propos de la saisie des adresses, j’espère que la saisie ci-dessous ne concerne que vous, mais pas l’utilisateur (qui, je le rappelle, est censé ne connaître que les clés alternatives, significatives) :




En effet, vous le feriez tourner en bourrique... S’il est concerné, voici ce qu’il devrait voir (grâce à une jointure ad-hoc) :



En tout cas pour mon confort personnel et éviter de me noyer je travaille plutôt à la façon de l'utilisateur. Je pense que pour vous aussi ça serait préférable, aussi patient et persévérant que vous soyez...

[fsmrel]

Bonsoir sudtek,


En passant :

J’ai constaté que certains attributs pouvaient être marqués NULL (dont codePostal (table CODEPOSTAL) !) : à éviter, mais en revanche autoriser les chaînes de caractères vides qui permettent de rester dans la logique bivalente (nuance !)

A mon sens la table UE : le triplet (RacineUeId, UeSemestre, UeRang) est clé alternative.

Je sens comme qui dirait que vous avez le nez dans le guidon....

[sudtek]

Bonjour fsmrel,

En voilà une nouvelle qu’elle est bonne !

Je crois les doigts pour que le MLD utilise le même style que DB-main avec les flèches si non c’est pas gagné ...

Quand vous le réveillerez pour lui dire « Voilà, je crée une adresse en ayant renseigné tous les attributs de la table ADRESSE », ce n’est qu’à ce moment-là qu’ACCESS effectuera tous les contrôles qui lui ont été sous-traités, il s’assurera notamment que l’intégrité référentielle est bien respectée par rapport à VC : si pour une adresse vous avez choisi une paire {idCodePostal, idVille} qui n’existe pas dans VC, au hasard <75001, Toulouse>, votre tentative de création échouera.

Effectivement le logiciel me spécifie bien qu’il ne peut pas appairer dans ADRESSE des couples inexistants dans VC.

Si vous voulez qu’ACCESS ne montre que les villes en relation avec un code postal, alors il faut le réveiller dès que le code postal sera saisi, avant qu'on puisse choisir la ville.

Je me creuse la tête comment faire, mais après pas mal de tests force est de constater que le SQL n’est interprété qu’à la fin de la saisie d’une ligne, du coup impossible de gruger avec des requêtes ou une table temporaire VC qui ne contiendrait que les idVille appairés avec le bon idCodePostal …
La solution doit se trouver sur l’interception d’un événement en VBA … mais vu je suis pas un fan du VBA … je sais pas trop par quel bout prendre la chose ....

Ça me rappelle le comportement du logiciel de musique CUBASE il y a 20 ans : quand je saisissais une note, disons une croche, dans une mesure encore vierge, avant que j’ai eu le temps de saisir la note suivante, au nom du respect de la mesure, CUBASE avait déjà complété (je dirai pollué) la mesure avec plein de silences que je devais effacer un par un, au fil de la saisie de mes propres notes.

Je comprends bien que dans votre cas ce ne devait pas être marrant car c’est carrément de la complétion automatique, dans mon cas je propose juste de limiter les choix pour faciliter la vie de l’utilisateur.

En tout cas pour mon confort personnel et éviter de me noyer je travaille plutôt à la façon de l'utilisateur. Je pense que pour vous aussi ça serait préférable,

C’est ce que j’ai entrepris mais par contre je ne comprends pas comment vous faites pour ne pas avoir l’idCodePostal en colonne 1 ?
Sans cela mon Acces me jette, en effet les types de idCodePostal (numerique) et de l’AK codePostal (varchar) posent forcement problème. (idem pour idville) … Si j’insiste sur le coté Acces c’est que ce ‘truc’ de Microsoft est quasi incontournable et très loin d’être trivial & simple contrairement à ce que laissent entendre dire la plus part des gens.

Pour ce test au mieux j’arrive à obtenir cela :



avec 2 requêtes :



Cordialement SUDTEK

[fsmrel]

Bonsoir sudtek,

Je croise les doigts pour que le MLD utilise le même style que DB-main avec les flèches si non c’est pas gagné ...

Pas de panique. allez voir un exemple de MLD selon WinDesign : c’est on ne peut plus classique, sinon moins dépouillé qu’avec DB-MAIN.

La solution doit se trouver sur l’interception d’un événement en VBA … mais vu je suis pas un fan du VBA … je sais pas trop par quel bout prendre la chose ....

J’ai dû faire du VBA il a 20 ans, et malheureusement je ne saurais aujourd’hui être d’un bon conseil à ce propos...

C’est ce que j’ai entrepris mais par contre je ne comprends pas comment vous faites pour ne pas avoir l’idCodePostal en colonne 1 ?
Sans cela mon Acces me jette, en effet les types de idCodePostal (numerique) et de l’AK codePostal (varchar) posent forcement problème. (idem pour idville) … Si j’insiste sur le coté Acces c’est que ce ‘truc’ de Microsoft est quasi incontournable et très loin d’être trivial & simple contrairement à ce que laissent entendre dire la plus part des gens.

Heuh... Ce que j’ai montré correspond à ce qui doit être présenté à l’utilisateur. Je ne l’ai pas obtenu par formulaire ou équivalent, mais par... PAINT !

Pour ce test au mieux j’arrive à obtenir cela :
avec 2 requêtes

Je pense qu’il va falloir prendre contact avec des champions d’ACCESS, dans le forum du même nom.

[sudtek]

J’ai constaté que certains attributs pouvaient être marqués NULL (dont codePostal (table CODEPOSTAL) !) : à éviter, mais en revanche autoriser les chaînes de caractères vides qui permettent de rester dans la logique bivalente (nuance !)

Ok je comprends si l'attribut est de de type varchar mais par contre dans le cas de l'entité NOTATION l'attribut codeAbsence est de type booléen et je comptai :
- l'initialiser à NULL par défaut car habituellement on est pas absent valeurNote = note obtenue par l’élève
- FAUX si l’élevé n'a pas fourni un justificatif pour son absence valeurNote =00,00.
- VRAI si l’élevé a fourni un justificatif pour son absencevaleurNote = vide .

Dans le cas de l'attribut codeAbsence le NULL peut-il être rempalcé par vide ? ex :{ NULL ,FAUX ,VRAI } devient { ,FAUX ,VRAI }

A mon sens la table UE : le triplet (RacineUeId, UeSemestre, UeRang) est clé alternative.

... en fait sur le MCD il faut être un expert pour s'en rendre compte, c'est bien plus évident à voir sur le MLD !

Je sens comme qui dirait que vous avez le nez dans le guidon....

Non dans le clavier

[sudtek]

Bonjour fsmrel,

Heuh... Ce que j’ai montré correspond à ce qui doit être présenté à l’utilisateur. Je ne l’ai pas obtenu par formulaire ou équivalent, mais par... PAINT !

J’ai dû faire du VBA il a 20 ans, et malheureusement je ne saurais aujourd’hui être d’un bon conseil à ce propos... Je pense qu’il va falloir prendre contact avec des champions d’ACCESS, dans le forum du même nom.

J'avais commencé à consulter la section acces du site, pour voir si dans la FAQ il y aurais pas la réponse mais à l’évidence nada, la recherche par le forum à pas été fructueuse car je dois pas exprimer correctement mon PB ... je ferai un post demain juste avec la partie des entités VC ADRESSE CODEPOSTAL VILLE.

Cordialement SUDTEK

[fsmrel]

Bonjour sudtek,

dans le cas de l'entité NOTATION l'attribut codeAbsence est de type booléen et je comptai :
- l'initialiser à NULL par défaut car habituellement on est pas absent valeurNote = note obtenue par l’élève
- FAUX si l’élevé n'a pas fourni un justificatif pour son absence valeurNote =00,00.
- VRAI si l’élevé a fourni un justificatif pour son absencevaleurNote = vide .

Dans le cas de l'attribut codeAbsence le NULL peut-il être remplacé par vide ? ex :{ NULL ,FAUX ,VRAI } devient { ,FAUX ,VRAI }

Le bonhomme Null nous lance un certain nombre de défis, dont celui d’une modélisation qui tienne la route, sans concession au laxisme et au bricolage. Si une note est nécessairement comprise entre 0 et 20 et si tel élève a obtenu la note 0, cela veut dire que le correcteur a jugé que c'était mérité et rien d’autre sinon ça aurait des effets néfastes (dans les calculs de moyenne d’une classe et autres joyeusetés). Je propose que, telle le ver de terre, l’entité-type NOTATION subisse une scissiparité, qu’elle soit coupée en deux, pour tenir compte des notations authentiques d’une part et des absences de notation d’autre part.

MCD




A noter qu’à mon sens un professeur n’a pas à noter les élèves absents...


MLD

en fait sur le MCD il faut être un expert pour s'en rendre compte, c'est bien plus évident à voir sur le MLD !

Exact... Vérifiez s’il n’y a pas le même genre de coup fourré pour les modules...

je ferai un post demain juste avec la partie des entités VC ADRESSE CODEPOSTAL VILLE.

Pour être en phase avec ACCESS, vous pourriez présenter le diagramme suivant :




Histoire de me ramener au bon vieux temps, je vais consulter un bouquin sur ACCESS que j’ai conservé, mais qui date de 1993 (c'était du temps de la V1) et je suppose qu’au plan IHM les possibilités offertes y sont plus frustres qu'aujourd’hui...