Discussion :

[eigna_42000]

Bonjour,
Voici la base que j'ai créer pour la mission locale jeune où je travail(Elle va ensuite être traduit en base SQL)mais avant, je veux être sur que je ne me suis pas trompé car je ne suis pas du tout sur de ma base actuel.



Quelques explications qui peuvent être utile.
-> Une conseillère est présente dans une ville (locaux principaux). On identifie une conseillère avec ses initiales.
-> Une formation a plusieurs session (même nom mais plusieurs date de début et de fin différentes).
-> Un emploi est d'un certain type (CDD, CDD saisonnier, CDI, Contrat de pro...) chaque contrat des différents et a des dates très différentes de début et de fin.
-> l'identifiant d'un jeune est son identifiant de Pole Emploi. Le statut Pole emploi du jeune est aussi présent (Inscrit, Radié, Autres) avec la date d'inscription, de radiation...
-> Un jeune a aussi une conseillère référente unique (mais une conseillère s'occupe de plusieurs jeunes).
-> Un jeune n'est pas forcement en emploi ni en formation (possible jamais formation et emploi)
-> Plusieurs type de rendez-vous (1er accueil, Suivi, Suite d’absence...). Un jeune aura plusieurs rendez-vous au long de son accompagnement. Chaque rendez-vous est vérifier (Présent, Absence, Reporter, Annuler...)
-> Les absences sont soumises à une procédure particulière. Quand un jeune est absent la 1ère fois, on récupère date de l'absence, ensuite le jeune est contacter par téléphone mais il existe plusieurs situations de retour de l'appel (Message, Communication ok, Problème de numéro…).
-> Si le jeune a une 2ème absence, on récupère la date de la seconde absence, puis on lance une procédure appelé GL2 qui dans notre base aura pour valeur : Saisie manuelle/ PAGM/ Envoyé) la GL2 possède une date pour chaque valeur. Ensuite selon le retour de la GL2, on complète les champs abandon procédure (oui/ non) ; un champ d’informations complémentaire est présent pour toute remarque (libre) ; Alerte possède 2 valeurs : Traité /A faire

[gototog]

Il nous manque ton schema pour pouvoir réagir [Probleme personnel]

Si je peux me permettre une remarque néanmoins:

Une conseillère est présente dans une ville (locaux principaux). On identifie une conseillère avec ses initiales.

Les initiales sont de très mauvais idantifiants car très sensibles au doublon.
Laetitia Richard (LR) laurie Roux (LR)(meme si je me doute que vous devez avoir des variantes pour contourner cela)
Une solution pour éviter de bousculer leurs habitudes est de les identifier par un identifiant numérique, qui ne servira que pour la base de données, et qui leur sera totalement invisible.

[eigna_42000]

le lien image c mon schéma. Sinon soit plus précis concernant le schéma, modele ou exemple.

Concernant les initial des conseillères, oui je le sais, mais il fonctionne déjà avec les initial et en car de "Laetitia Richard (LR) laurie Roux (LR)" on s'arange du genre:
Laetitia Richard (LR)
Laurie Roux (LRO)

C'est vrai que ce n'est pas encore arrivé et qu'elle sont tres attaché a leur systeme d'initial. Tout fonctionne avec les initiales. mais je ne suis pas contre une l'ajout d'un champs du genre (id_conseillere) avec un num automatique

[gototog]

Ah, le problème vient peut être de mon navigateur, mais je ne vois aucun lien ni pièce jointe dans le message ^^'
Si un membre peut confirmer/infirmer?
Edit: Merci CinePhil, c'est un probleme de mon coté [ politique d'entreprise empechant d'aller sur des sites d'hebergement d'images]. Excuse moi de mes remarques alors !

[CinePhil]

L'image cliquable est bien présente avec Firefox sous Mandriva.

[f-leb]

bonjour,

juste une 'tite remarque au passage...

tu as décidé d'utiliser un champ multi-valué RDV.Type_Rdv. C'est parfois bien pratique et acceptable pour des petits projets mais cela peut poser des problèmes qu'on ne soupçonnait pas auparavant si la base était amenée à évoluer.

Préférer une table de jointure:
RDV-1------*-Typer RDV-*------1-TypeRDV

[gototog]

-> Une conseillère est présente dans une ville (locaux principaux). On identifie une conseillère avec ses initiales.
-> Une formation a plusieurs session (même nom mais plusieurs date de début et de fin différentes).
-> Un emploi est d'un certain type (CDD, CDD saisonnier, CDI, Contrat de pro...) chaque contrat des différents et a des dates très différentes de début et de fin.

c'est ok

-> l'identifiant d'un jeune est son identifiant de Pole Emploi. Le statut Pole emploi du jeune est aussi présent (Inscrit, Radié, Autres) avec la date d'inscription, de radiation...

Donc Statut_PE est relié a jeune, jusque la aucun soucis.
ce qui me pose problème c'est ta propriété date dans l'entité Jeunes.

Je t'illustre ce que tu vas généré coté bdd pour te montrer:

Jeune
id=1, nom=gototog, prenom = developpez, conseillere=3 , Statut=2. (aucun soucis ici)

Statut_PE
Inscrit, 06/11/58.

Maintenant si on essaye d'avoir un deuxieme jeune, si il est lui aussi Inscrit, quelle va etre la date de ton statut Inscrit?

La date du statut n'est donc pas propre au statut, mais lié au jeune. En phrase de règle de gestion, ceci peut se traduire ainsi:

Un Jeune a un Statut. Un Statut peut etre obtenu par plusieurs jeunes.
On conserve la date du Statut du Jeune.
[la propriété date va donc dans l'entité Jeune]

Au passage, une chaine de caractère d'un statut peut-etre amené a évoluer (Nouveaux termes choisit par politique ou facteurs externe, par exemple si Pole emploi ne veux plus utiliser Radier mais Banni, tu dois changer l'identifiant du statut, alors qu'un identifiant doit etre immuable, il faut bien souvent lui préférer un identifiant numérique, m'enfin la c'est du chipotage )

-> Plusieurs type de rendez-vous (1er accueil, Suivi, Suite d’absence...). Un jeune aura plusieurs rendez-vous au long de son accompagnement. Chaque rendez-vous est vérifier (Présent, Absence, Reporter, Annuler...)

Comme l'a dit f-leb, le type de Rendez vous est a sortir de l'entité.

Rajouter la propriété Statut ou un lien vers une entité statut_rdv selon votre convenance?

-> Les absences sont soumises à une procédure particulière. Quand un jeune est absent la 1ère fois, on récupère date de l'absence, ensuite le jeune est contacter par téléphone mais il existe plusieurs situations de retour de l'appel (Message, Communication ok, Problème de numéro…)

non modélisé

-> Si le jeune a une 2ème absence, on récupère la date de la seconde absence, puis on lance une procédure appelé GL2 qui dans notre base aura pour valeur : Saisie manuelle/ PAGM/ Envoyé) la GL2 possède une date pour chaque valeur. Ensuite selon le retour de la GL2, on complète les champs abandon procédure (oui/ non) ; un champ d’informations complémentaire est présent pour toute remarque (libre) ; Alerte possède 2 valeurs : Traité /A faire

non modélisé

[eigna_42000]

Merci pour vos réponse. Voila un nouveau schéma selon certaine des remarque que vous m'avez fait part. Concernant les ABS la non modélisation étai une erreur de ma part et vu les modifications que j'ai fais je crois (j'en suis même sur que cette table est fausse)

Concernant la question sur la 'date inscrit' pour le statut Pole Emploi, la date d'inscription est a titre indicatif, ce qui nous intéresse vraiment c'est la date de 'radiation', car au bout de mois de radiation nous demandons a Pole Emploi la fin de l'accompagnement comme le prévois la convention.



Néanmoins un grand merci pour votre aide, j'apprécie énormément

[fsmrel]

Bonsoir,

Concernant les initial des conseillères, oui je le sais, mais il fonctionne déjà avec les initial et en car de "Laetitia Richard (LR) laurie Roux (LR)" on s'arange du genre:
Laetitia Richard (LR)
Laurie Roux (LRO)

C'est vrai que ce n'est pas encore arrivé et qu'elle sont tres attaché a leur systeme d'initial. Tout fonctionne avec les initiales. mais je ne suis pas contre une l'ajout d'un champs du genre (id_conseillere) avec un num automatique

gototog a totalement raison quand il dit, je le cite : « une solution pour éviter de bousculer leurs habitudes est de les identifier par un identifiant numérique, qui ne servira que pour la base de données, et qui leur sera totalement invisible. »

Il faut effectivement définir un attribut Id_Conseillere qui fasse l’objet de la clé primaire de la table CONSEILLERES. Vous conservez bien sûr l’attribut INITIAL, mais celui-ci fera l’objet d’une clé alternative (pour conserver la propriété d’unicité des initiales des conseillères). Comme vous utilisez ACCESS, vous pouvez lui signifier que l’attribut INITIAL est indexé, sans doublons.

Par ailleurs, c’est l’attribut Id_Conseillere qui sera référencé par l’attribut #Conseillère de la table JEUNES.


Au sujet de la justification du caractère artificiel des clés primaires, donc de leur stabilité et de leur absence de signification, voyez ici.

[Richard_35]

Bonjour à tous,

gototog a totalement raison quand il dit, je le cite : « une solution pour éviter de bousculer leurs habitudes est de les identifier par un identifiant numérique, qui ne servira que pour la base de données, et qui leur sera totalement invisible. »

==> j'ajouterais même que c'est impératif.

D'autre part, ton schéma semble être effectué sous Access ; si c'est le cas, n'oublies pas l'intégrité référentielle minimum qui soulignera les relations 1---n.

[eigna_42000]

oui concernant l'identifiant des conseillère c'est bon je l'ai fait. Mais ne vous bloquez pas à ACCESS, comme je l'ai dit au début, ma base va être faite en SQL pour un développement web