Envoyé par fsmrel
Le mot cours peut disparaitre.
une formation peut comporter un controle d'efficacite.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Le mot cours peut disparaitre.
une formation peut comporter un controle d'efficacite.
Et votre diagramme est conforme à ce que vous avez écrit :
[FORMATION]>|--------O|--[FORMATEUR]
ca c'etait au tout debut
c'est plutot :
[SESSION]>|---------O|----[FORMATEUR]
voici a quoi ressemble mon modele actuel:
Dotie,
Je suis tout à fait d’accord, j’avais fait un mauvais copier/coller...
D’accord.
Il s’agirait donc des auto-formations, c’est-à-dire des formations sans formateur ? C’est ça ?
Si ce que je viens de postuler est avéré, les contrôles d’efficacité ne concerneraient donc que les auto-formations. Si c’est cela, s’agit-il de toutes les auto-formations ? Seulement certaines d’entre-elles ?
Qu’est-ce qu’un chemin ? Est-ce seulement du bruit ? Sinon, comment avez-vous modélisé ce concept ?
Concernant l’association entre les tables DOCUMENT et TYPE_DOCUMENT :
Vous avez utilisé le type « Identifying Relationship » pour cette association, autrement dit vous faites participer l’attribut TypeDocumentId à la clé primaire de la table DOCUMENT : un document peut ainsi faire référence à plus d’un type de document. Si un document ne peut faire référence qu’à un seul type de document, alors faites passer l’association à « Non-Identifying Relationship » (cf. « Associations de un à plusieurs », Figure 5.3).
Votre diagramme (post #43) comporte une table RAPPEL dont vous n’avez pas encore parlé. De quoi s’agit-il ? Quelle finalité ?
Dans ce diagramme, vous usez des « Identifying Relationship » de façon assez systématique, sans voir les conséquences de cette façon de procéder. Je viens d’évoquer cela avec l’association entre les tables DOCUMENT et TYPE_DOCUMENT, mais quoi qu’il en soit, réfléchissez aux conséquences que cela a dans le cas de la table SESSION : vous faites participer l’attribut FormateurId à la clé primaire de cette table, c’est-à-dire qu’une session peut donc être animée par plus d’un formateur ! Vous observerez par ailleurs que l’attribut FormateurId a été tout à fait logiquement mais indûment propagé par l’AGL dans votre table PARTICIPER ! Faites déjà passer à « Non-Identifying Relationship » l’association entre les tables SESSION et FORMATEUR (je reviendrai plus tard sur la modélisation concernant cette partie). Ce qui précède vaut évidemment pour l’association entre les tables SESSION et RAPPEL.
Bonsoir Dotie,
Hum... Il s’agit plutôt d’un bug de la version 8 du logiciel, lequel oublie d’afficher les mickeys symbolisant les clés primaires. J’avais signalé ce bug à l’éditeur il y a deux mois, mais celui-ci n’a manifestement rien fait...Pour ma part, je continue donc à utiliser la version 6.3.
Salut Fsmrel,
Il s’agirait donc des auto-formations, c’est-à-dire des formations sans formateur ? C’est ça ?
Il ne s'agit pas juste des auto-formations. Je crois que meme des formations avec formateurs peuvent avoir des controles a la fin.
Donc il y'a des formations avec controles a la fin et des formations sans controles independamment du fait que ce soit des auto-formations ou pas.
Qu’est-ce qu’un chemin ? Est-ce seulement du bruit ? Sinon, comment avez-vous modélisé ce concept ?
Au fait je pensais ici au Chemin d'acces au fichier ou se trouvera mes differents documents...en realite j'ai vraiment beaucoup de difficultes a comprendre comment faire cette partie avec les documents ,les Controles, les attestions ...
Vous avez utilisé le type « Identifying Relationship » pour cette association, autrement dit vous faites participer l’attribut TypeDocumentId à la clé primaire de la table DOCUMENT : un document peut ainsi faire référence à plus d’un type de document. Si un document ne peut faire référence qu’à un seul type de document, alors faites passer l’association à « Non-Identifying Relationship » (cf. « Associations de un à plusieurs », Figure 5.3).
Un document ne peut faire reference qu'a un seul type..je vais modifier...merci
Votre diagramme (post #43) comporte une table RAPPEL dont vous n’avez pas encore parlé. De quoi s’agit-il ? Quelle finalité ?
Au fait il faut des fonctions rappel qui pouront informer.. quand une formation doit etre faite ou bien encore qui annonce peu de temp avant la date d'une formation..bref une allerte..je me suis dis qu'il faut enregistrer a la base les dates de rappel dans la base de donnees..je ne n'ai pas plus d'idee sur cette table pour le moment..
Hum... Il s’agit plutôt d’un bug de la version 8 du logiciel, lequel oublie d’afficher les mickeys symbolisant les clés primaires. J’avais signalé ce bug à l’éditeur il y a deux mois, mais celui-ci n’a manifestement rien fait... Pour ma part, je continue donc à utiliser la version 6.3.
oui je me suis dis ca aussi vu que tu avais deja parle de ca plus haut...et la j'utilise la version 6.3 maintenant et les mickeys sont bien visible...merci
Bonjour Dotie,
Merci d’utiliser la balise quote quand vous citez vos interlocuteurs, sinon on ne sait plus qui a écrit quoi…
Il faut fixer le plus formellement possible les règles de gestion.
Par exemple quand vous écrivez ce qui suit, on comprend, mais on peut avoir encore un doute :
Pour éviter toute ambiguïté :
Un document de formation est affecté à au moins et au plus une formation
A une formation est affecté au moins et au plus un document de formation
Ce qui se traduit ainsi :
[FORMATION]—||————————||—[DOCUMENT]
Ce qui met en évidence une bijection entre FORMATION et DOCUMENT. Il n’est pas recommandé de modéliser les bijections et le plus simple est que FORMATION absorbe DOCUMENT, c’est-à-dire que le nom du document fasse partie des attributs de FORMATION :
Même principe pour le chemin du document :
Et pour les attestations, puisque vous avez écrit :
Où là encore ça sent la bijection :
Quant aux contrôles :
On n’est plus en présence d’une bijection mais d’une injection :
[FORMATION]—||————————O|—[FORMATION_CONTROLE]
Il faut donc définir une table FORMATION_CONTROLE afin de ne pas polluer la table FORMATION avec des marques NULL (le bonhomme NULL est l’ennemi des bases de données relationnelles) :
De même en ce qui concerne les formateurs, il faut empêcher le bonhomme NULL de se manifester :
En résumé, compte-tenu des bijections, injections et du bonhomme NULL :
Commence-t-on à être en phase ? Quels points vous paraissent contestables ? Quelles sont les omissions ? Vos incompréhensions ?
Salut Fsmrel,
Merci encore pour ton aide!
Je reviens d'abord sur les bijections la ...tu les lis dans un seul sens oubien? avec ma definition d'une bijection je ne vois pas trop claire sur les bijections et injections dont tu parle la..
Il y'a bijection entre la table FORMATION et DOCUMENT parcequ'un document est specifique a une et une seule formation nespa? pareil pour FORMATION et ATTESTATION et FORMATION ET CONTROLE....tu peux stp apporter un peu plus sur ca? ..merci d'avance
si je peux me permettre de m’immiscer dans cette conversation
Quelques définitions ici : https://fr.wikipedia.org/wiki/Inject...C3%A9matiques)
il y a bijection si un document est spécifique à une et une seule formation et qu'à l'inverse, pour une formation il existe un et un seul document
Il arrive parfois qu'une bijection fasse l'objet de deux tables : quand une colonne obligatoire est très volumineuse, on peut choisir de partitionner verticalement la table en isolant la colonne concernée
Mais le cas le plus général est de ne faire qu'une table
Salut,
merci beaucoup!
Au fait je crois que j'ai comprise mon probleme. Ma table DOCUMENT a la base etait supposee enregistrer pas seulement les documenets de formations proprement dit mais aussi les documents de controles et vu que a chaque formation est attribue un document de formation et peut etre un document de controle (selon si la formation necessite un controle a la fin ) d'ou ma relation entre la table DOCUMENT et FORMATION et la je ne voyais pas vraiment de bijection.
Mais je pense plutot que Fsmel a juste considere des documents de formation d'ou la bijection entre DOCUMENT et FORMATION. C'est claire maintenant pour ce cas.
En ce qui concerne la relation entre la Table FORMATION et ATTESTATION...j'ai un soucis.
.Chaque attestation est specifique a une formation
.A une formation ne peut etre attribue qu'une seule formation dans le sens ou chaque employes recoit pour chaque formation une et une seule attestation...maintenant je veux savoi si le fait que les employes recoivent des formations specifiees qui portent leurs noms ne derange pas sur le type de ta relation?...merci d'avance
Bonsoir Dotie,
Quelle est votre définition de la bijection ?
En tout cas, voici celle que j’utilise, extraite de La théorie des ensembles, par Alain Bouvier, aux Presses universitaires de France (3e édition, 1982) :
Il n’y a pas de sens de lecture à privilégier...
La définition ci-dessus fait appel à la surjectivité et à l’injectivité, en voici donc les définitions (pages 77-79 de l’ouvrage) :
En vertu des définitions précédentes, ce que vous décrivez ici correspond à une injection : puisque vous omettez de rappeler qu’une formation a un et seul document de formation, dans ces conditions on ne peut pas parler de bijection. Même chose concernant l’attestation.
Holà ! J’avais précédemment traité bien sûr des contrôles. La relation entre FORMATION et FORMATION_CONTROLE est injective, revoyez le post #51 où j’ai écrit :
« On n’est plus en présence d’une bijection mais d’une injection :
[FORMATION]—||————————O|—[FORMATION_CONTROLE]
Il faut donc définir une table FORMATION_CONTROLE afin de ne pas polluer la table FORMATION avec des marques NULL (le bonhomme NULL est l’ennemi des bases de données relationnelles) »
Bref, relisez soigneusement ce que j’ai écrit dans le post #51.
Oui Capitaine, tout en ayant en tête les pièges de la bijection, quand on passe à deux tables, cf. le billet Merise : cardinalités 1,1 ---- 1,1 => intégrité référentielle = cautère sur jambe de bois.Il arrive parfois qu'une bijection fasse l'objet de deux tables : quand une colonne obligatoire est très volumineuse, on peut choisir de partitionner verticalement la table en isolant la colonne concernée
Mais le cas le plus général est de ne faire qu'une table
Incidemment, on peut noter que l’excellent Looping ne permet pas la bijection entre entités-types (en tout cas j’ai essayé mais en vain)…
En principe, l’attestation pour un employé est obtenue par ajout des données de l’employé (cf. table EMPLOYE (nom, prénom, etc.) et table PARTICIPATION (résultat)) aux données de l’attestation définies dans la table FORMATION (attribut AttestationNomFichier) modélisée dans mon diagramme du post #51. Ceci relève des traitements et normalement n’a pas à être rendu persistant dans la base de données, à moins que vous ne le justifiiez formellement, et montriez qu’à défaut il y aurait perte d’information.
Certes, mais le cas du partitionnement vertical échappe à cette faille, car il s'agit d'une seule entité-type au niveau conceptuel, dont on fait deux tables au niveau logique (avec évidemment le même identifiant primaire), uniquement pour des raisons d'exploitation et de performances.
note : j'ai relu ce billet et curieusement je ne vois pas le commentaire de Philippe (j'ai supposé qu'il s'agissait de Cinephil). Etrange et frustrant du coup
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager