Bonsoir arguitxu,
Je reviens sur le modèle que j’ai proposé le 03/05/2013. Il y manque un lien entre SERVICE et TYPE_INTERVENTION : en effet, vous aviez précisé :
Envoyé par
arguitxu
Un type d'intervention ne peut être pratiqué que par un seul service (spécialité).
Comme par ailleurs à la question :
Une activité peut-elle être pratiquée par plus d’un service ?
Vous avez répondu affirmativement, et qu’à la question :
Un service peut-il pratiquer plus d’une activité ?
Vous avez répondu négativement, il s’ensuit que les types d’intervention pour une activité sont connus par le biais des types d’intervention pratiqués par les services liés à cette activité, en conséquence de quoi l’association ACTIVITE - TYPE_INTERVENTION est inférable, donc à ne pas matérialiser (la matérialisation de l'association se traduirait dans le modèle ci-dessous, par l'implication de la table TYPE_INTERVENTION dans ce qu’on appelle un viol de la troisième forme normale, horresco referens !)
Modélisation correspondante :
Activites.png)
A propos des quotas.
Je vous cite à nouveau :
Les salles de Chirurgie Ambulatoire sont disponibles en première intention à la journée. Elles sont dédiées en première intention à une activité. Chaque activité a donc un cota de salles libres par journée et par semaine (ex : lundi : 5 salles, mercredi : 4 salles et jeudi : 5 salles pour l’activité Odontologie).
Il faut prendre en compte les quotas dans le modèle, sinon comment vérifier qu’un service ne dépasse pas ceux qu’on lui a alloués ?
Quotas.png)
A propos des affectations.
La table AFFECTATION que j’ai précédemment définie se justifie si les secrétaires des services demandeurs effectuent des réservations de place avant même de programmer les interventions. En revanche, si ces réservations « anticipées » n’ont pas lieu d’être, c'est-à-dire si les réservations ne se font qu’au moment de la programmation des interventions, cette table peut ne pas être matérialisée.
Scénario 1 : effectivement, on préfère ne pas conserver la table AFFECTATION :
IntervSansAffectation.png)
Remarques :
1. Le service (attribut ServiceId) ne figure pas dans la table INTERVENTION : en effet, du fait de la présence de l’attribut TypeInterventionId, il y aurait viol de la troisième forme normale (3NF) s’il était présent. On connaît le service via le type d’intervention (jointure naturelle de TYPE_INTERVENTION et INTERVENTION).
2. Il ne faudra pas oublier de s’assurer que dans la table INTERVENTION, les attributs InterventionDate et JourId font bien référence au même jour de la semaine.
Scénario 2 : on préfère conserver la table AFFECTATION :
IntervAvecAffectation.png)
Remarques :
1. Si vous préférez nommer autrement la table AFFECTATION, n’hésitez pas.
2. Eu égard à la règle : « Pour un jour donné, une salle (place) donnée est affectée à seul service », la clé de la table AFFECTATION est réduite à la paire {PlaceId, JourId}. En cela, je fais référence à votre tout 1er message.
Toutefois, vous avez aussi écrit :
Envoyé par
arguitxu
Une salle est réservé pour la journée, mais cela pourra etre modifié si c'est vraiment nécessaire par le secrétariat ambulatoire qui aura pratiquement tous les droits dans l'application.
En l’occurrence il y a ambiguïté : on ne sait pas si voulez signifier qu’une réservation peut être annulée ou bien si le secrétariat ambulatoire décide que le même jour, il pourra y avoir dans la même salle des interventions de services demandeurs différents : veuillez en l'occurrence être précis et exhaustif...
3. Il ne faudra pas oublier de s’assurer que dans la table INTERVENTION, les attributs InterventionDate et JourId font bien référence au même jour de la semaine.
4. Toujours pour la table INTERVENTION, il faudra s’assurer que le service déterminé par le type d’intervention mentionné par l’intervention est identique à celui qui est déterminé par l’affectation mentionnée par l’intervention.
A propos des utilisateurs.
Envoyé par
arguitxu
la table utilisateur doit permettre d'affecter des droits sur l'application, ex: un service donné pourra planifier des intervention, visualiser son planning alors qu'un autre pourra annuler, réserver et modifier le planning des autres services
Je suppose que lorsque vous dites « qu’un autre pourra annuler réserver et modifier le planning des autres services », cet « autre » n’est pas un utilisateur d’une UF (service) mais seulement un utilisateur du secrétariat du service de chirurgie ambulatoire ?
Par ailleurs, j’ai bien pris note de ceci :
Envoyé par
arguitxu
Une fois la planification de l’intervention effectuée, aucune modification ne peut être apportée par le secrétariat du service demandeur. Une demande doit être faite par téléphone ou mail au service de Chirurgie Ambulatoire.
Je prends note qu’il n’est pas possible de modifier une intervention, à ceci près que si je conçois que le service de Chirurgie Ambulatoire puisse changer l’heure d’une intervention (par exemple parce qu’il y a une urgence ou que le patient ne peut être opéré pour une raison quelconque à l’heure prévue), je suppose que ce service ne peut pas remplacer une intervention concernant le service S1 par une intervention concernant le service S2... Qu’en est-il exactement ?
Dans le cas du 2e scénario ci-dessus, en ce qui concerne l’affectation des places (table AFFECTATION), donc avant qu’’on ne crée les interventions, quelles sont les règles du jeu au sujet des modifications ? Seul le service de Chirurgie Ambulatoire est habilité à toucher à quoi que ce soit ? Sinon, si Jojo qui n’est pas du secrétariat ambulatoire mais du service (UF) S2 avait le droit de modifier ce qu’a saisi Loulou qui est du service S1, ça serait bien pour attribuer à S2 ce qui appartenait jusque-là à S1 (affectation) ?
Autrement dit :
— Que peut-on modifier pour une intervention programmée ? La date de l’intervention ? L’heure ? La place ? L’UF ? (Je sous-entends que seul le service de Chirurgie ambulatoire est habilité à modifier).
— Que peut-on modifier pour une affectation ? Le jour ? La place ? l’UF ? Par ailleurs, qui est habilité à modifier ? Un service demandeur (donc autre que le service de Chirurgie ambulatoire) peut-il modifier des données qui ne concernent que lui seul ? Les autres services ?
Proposition de modèle pour les utilisateurs
De même qu’on a spécialisé les personnes en médecins, chirurgiens et patients, je propose qu’on spécialise les utilisateurs en fonction des droits qui leurs sont octroyés. Par exemple, l’utilisateur Louis qui n’appartient pas à une UF mais au secrétariat du service ambulatoire sera reconnu comme tel et fera partie de la table ADMIN des utilisateurs du secrétariat ambulatoire habilités à modifier le planning (vous pouvez remplacer ce nom de table comme bon vous semble). Seuls les utilisateurs appartenant aux UF demandeuses seront répertoriés dans la table UTILISATEUR_UF.
Dans la mesure où les utilisateurs UF n’ont pas tous les mêmes droits, on peut éventuellement leur affecter un profil (table PROFIL) : habilitation à affecter les salles pour leur service, habilitation à programmer les interventions (toujours pour leur service), etc., à vous de voir si cela vaut le coup :
Utilisateurs.png)
Je ne tire pas les liens avec les autres tables (INTERVENTION, AFFECTATION), j’attends que vous vous prononciez par rapport aux scénarios proposés pour ces tables et aux diverses questions que j’ai posées.
A propos des intentions :
J’avais posé la question suivante :
Qu’est-ce qu’une 1re intention ? Donc par contraste, une 2e, une 3e, une nième intention ?
Et vous avez répondu :
Une salle est réservée pour la journée, mais cela pourra être modifié si c'est vraiment nécessaire par le secrétariat Ambulatoire qui aura pratiquement tous les droits dans l'application.
Ce qui ne répond pas à ma question, donc je la repose : quel sens donner au mot « intention » ? Quel sens donner à l’adjectif « première » ? Ces choses-là ont-elles un rapport avec les autorisations de modification ?
Répondre avec citation
)
IntervSansAffectation_bis.png)
programmation_UF.png)
programmation_UF_et_admin.png)
Autre question, les salles sont paramétrées pour 1 seul service chaque jour et que seul le service concerné peut réserver la salle ce jour là. Affectations_Habilitations(Viol_3NF).png)
En théorie, l’attribut ServiceId n’a pas à être présent dans la structure de la table AFFECTATION. En effet, connaissant l’utilisateur ayant réalisé l’affectation, comme celui-ci appartient à un seul service, de la connaissance de l’utilisateur on infère celle du service pour lequel l’affectation est réalisée. En termes plus précis, on dit qu’il existe une dépendance fonctionnelle transitive {UtilisateurId} -> {ServiceId} provoquant un viol de 3NF pour la table AFFECTATION. En conséquence, soit vous contrôlez cette situation par le biais d’une contrainte d’inclusion comme quoi chaque valeur de la paire {UtilisateurId, ServiceId} de la table AFFECTATION existe aussi en tant que valeur de la paire {UtilisateurId, ServiceId} de la table UTILISATEUR_UF, soit vous normalisez en 3NF et le modèle devient :Affectations_Habilitations(pas_viol_3NF).png)
Les écrits sont terminés et clos mon parcours MIAGE ..... un vrai bonheur car plus de stress et je n'aurai plus à courir plusieurs lièvres, enfin jusqu'au prochain défie.Interventions_by_a_rectif.png)
Partager