@Dotie
voici quelques schémas qui permettent de comprendre plus facilement les injections, surjections et bijections
http://www.bibmath.net/dico/index.ph...injection.html
Bonjour Dotie,
On va éviter d’évoquer explicitement les injections, bijections et autres notions de la théorie des ensembles...
Restons-en aux règles de gestion, et allons-y doucement, limitons-nous pour le moment aux documents de formation.
Vous aviez écrit à leur propos :
Formalisons un peu mieux :
- Un document de formation est affecté à au moins et au plus une formation.
- Une formation est affectée à au moins et au plus un document de formation.
En conséquence de ces règles, je rappelle que j’avais effectivement écrit ceci de façon équivalente :
Cette configuration « —||————————||— » est déconseillée car source de bien des problèmes d’intégrité et pièges en tous genres pour les opérations : le mieux est qu’une table absorbe l’autre. En l’occurrence les attributs spécifiques de DOCUMENT migrent dans FORMATION, à savoir
Nom du document :
Chemin du document :
Bonjour Dotie,
On est donc d’accord en ce qui concerne les documents de formation : les données les concernant se retrouvent dans la table FORMATION (attributs formationDocNom et formationDocChemin).
Pour les attestations, je rappelle que votre représentation est la suivante (voir votre diagramme du post #15) :
[FORMATION]—||————————||—[ATTESTATION]
Cette représentation est en phase avec la règle que vous aviez énoncée :
Comme les documents de formation, les attestations sont donc absorbées par les formations, c’est-à-dire que la table FORMATION est dotée de l’attribut AttestationNomFichier (cf. le post #51) :
Pour les contrôles, je rappelle que votre représentation est la suivante (voir votre diagramme du post #43) :
[FORMATION]—||————————O|—[CONTROLE]
Cette représentation est en phase avec la règle que vous aviez énoncée :
En passant, la table TypeDocument n’a plus lieu d’être, elle doit disparaître.
Quant aux rappels :
dans votre diagramme du post #43, l’association entre les tables SESSION et RAPPEL est la suivante :
[SESSION]—||————————||—[RAPPEL]
Autrement dit l’une doit absorber l’autre...
Adoptez-vous le diagramme du post #51 ? Si quelque chose vous choque, n’hésitez pas à en parler...
Salut Fsmrel,
Merci vraiment!
J'ai recu certaines informations hier encor sur mon project qui pouront peut etre me poussez a faire certaines petites retouches sur mon modele..mais ce n'est pas sur..je dois mieux comprendre d'abord...je reviendrai vers ici au cas ou...
Ils m'ont demande d'etablir un cahier de charges foonctionnelles de ma base de donnees avant de continuer...c'est ca qui me stress depuis hier .je n'ai jamais fait ca ..au debut j'ai juste lister Fonctionnalité et performance que ma base de donnees doit avoir a la fin...une liste qu'ils ont meme encore complete(c'est pourquoi j'ai dit plus haut que peut etre ca pourra apporter certaines petites modifications sur mon modele)..la n'est meme pas le probleme..ca avancait plutot bien avec le modele...c'est cette histoire de cahier de charche la qui me stress maintenant...ils ont deja un exemple de formulaire ici qui regroupes certains points qu'il faut a tout prix traiter...je dois par exemple apporter des infos sur les points suivants:
caractéristiques physiques (Description des fonctions (par ex. langage de programmation, plate-forme, système d'exploitation))
environnement informatique(Description de l'environnement logiciel (matériel, taille de la mémoire, processeur, etc.) dans lequel le logiciel doit fonctionner. Pour l'exploitation au sein d'un réseau, divisé en serveur et client(s).)
Compatibilité(Description de la compatibilité nécessaire du logiciel (par ex. système d'exploitation, versions, bases de données)
entrées et sorties (Description des exigences : p. ex : Caractéristiques des données (par ex. numériques), plages d'entrée/sortie, limites, valeurs par défaut )
interfaces(Description des interfaces entre les systèmes logiciels et d'autres systèmes, composants logiciels, systèmes de réseau...)
alarmes (Description Alarmes, avertissements, messages utilisateur contrôlés par logiciel ...)
sécurité des données(Description des exigences : p. ex : Préservation de l'information confidentielle, authentification, autorisation, chemin des documents, intégrité de la communication)
Facilité d'utilisation de l'interface graphique (Description des exigences relatives à l'aptitude à l'emploi : par exemple Prise en charge des activités manuelles, interaction, lisibilité, restrictions pour l'utilisateur...)
Installation et réception, maintenance (Description des exigences relatives à l'application et à la maintenance du logiciel : p. ex : Installation par l'utilisateur, connexion au logiciel système existant, procédure de maintenance ....)
Panne logicielle, dysfonctionnement(Description de la configuration logicielle requise en cas de défaillance de certains modules ou fonctions, de la connexion au réseau...)
besoins en matériel (Description des exigences en matière de matériel, p. ex. écran, périphériques d'entrée, périphériques de sortie )
hmmm il ya point ou je ne sais meme pas comment commencer la recherche...je comprend que c'est necessaire de savoir tout ca tout au debut du projet..mais vraiment ..il y'a des point que jen'avait meme pas encore commence a traite...au debut jeme suis directemet lance sur mes regles de gestion et mon modele..mais le reste la je ne me suis pas fait d'idee...je ne sais pas si on peut m'aider dans ce forum sur ce point ..si non y'a il un forum ici qui traite ce genre de soucis?...merci d'avance
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.
Partager