Bonsoir arguitxu,
Il y a encore des cardinalités à revoir. Si on les suivait, un service ne pourrait pratiquer qu’un seul type d’intervention, il ne pourrait programmer qu’une salle et n’y serait rattaché qu’un seul utilisateur. De même, un type d’intervention ne concernerait qu’une seule intervention...
Voyons voir la modélisation au stade MLD en court-circuitant l’étape MCD. L’idéal serait d’utiliser PowerAMC, mais l’AGL n’est pas gratuit (
voir les coûts, sachant que la version basique ne permet pas de réaliser des MCD).
MySQL Workbench (MWB) est gratuit, et si son ergonomie n’est pas au niveau de celle de l’autre, on s’en arrange. Pour voir à quoi ressemble l'outil et quelques conseils d’utilisation, voyez par exemple les discussions avec
jogodepau,
Drakuncorp,
Lei57,
chesko,
SmallFitz. Je pourrai vous aider (dans les limites de mes moyens !) si une difficulté particulière se présente à vous.
Prenons le cas de la spécialisation de l’entité-type PERSONNE.
Au niveau du MCD, si la représentation graphique est la suivante (PowerAMC) :
Specialisation_2_MCD.png)
Au niveau du MLD, avec MWB, émotionnellement parlant c’est rustique, minimal, mais mathématiquement suffisant :
Specialisation_2_UML_MWB.png)
On ne parle plus d’entités-types mais de tables.
Il n’y a pas d’ovale pour connecter deux tables.
Par lien identifiant on signifie que la clé d’une table (en l’occurrence PERSONNE) participe à la clé d’une autre table (MEDECIN par exemple).
La représentation des cardinalités est à l’inverse de celle qu’on a dans Merise. On lit ainsi :
Une personne peut être un médecin et un médecin est nécessairement une personne (c'est-à-dire au moins et au plus une fois).
Un médecin peut avoir effectué des prescriptions et une prescription a nécessairement été effectuée par un médecin.
Etc.
Disons que la lecture des cardinalités est arrêtée par un carré, alors qu’en Merise c’est par un rond :
SensLecture.png)
{MedecinId} est clé primaire de la table MEDECIN et en même temps clé étrangère par rapport à la table PERSONNE, c'est-à-dire que chaque valeur de l’attribut MedecinId de la table MEDECIN doit être une valeur de l’attribut PersonneId de la table PERSONNE (l’ensemble {MedecinId} — au sens de la théorie des ensembles — doit être un sous-ensemble de l’ensemble {PersonneId}).
L’attribut MedecinId de la table MEDECIN aurait pu s’appeler PersonneId, mais ça aurait été moins parlant (aspect bande dessinée). Par opposition à Merise où un attribut ne peut pas figurer deux fois dans le MCD (cf. ma remarque concernant Code_uf), dans le MLD c’est le contraire ! Observez que l’attribut MedecinId figure aussi dans la table PRESCRIPTION : ce principe de réplication d’attributs est en fait au cœur du Modèle Relationnel de Données inventé en 1969 par Ted Codd, et lui confère son caractère
associatif : on effectue les opérations relationnelles uniquement par association des valeurs des attributs (ce que l’opérateur relationnel
JOIN illustre parfaitement), tandis qu’en Merise on n’opère pas [sic !]. A l’époque ce fut une révolution car avec les SGBD pré-relationnels (je devrais dire préhistoriques) les données n’étaient pas répliquées car accessibles seulement en suivant des pointeurs (
pointer chasing).
Quant à la notation, peut-être préférerez-vous la notation « patte de corbeau » (
crow’s foot), à vous de voir :
Specialisation_2_crow_MWB.png)
Prise en compte de la CIF :
J’avais présenté une CIF symbolisée dans le MCD par un arc orienté et se lisant ainsi :
La prescription faite pour le patient P et pour la date D a été le fait d’un médecin et un seul.
Autant cette contrainte n’est pas très facile à prendre au compte dans un MCD, autant ça l’est dans un MLD PowerAMC. Avec MWB ça reste assez facile : à cet effet on définit ce qu’on appelle un
index, comportant les paires {PatientId, PrescriptionDate}. Cet index (nommé ici PRESCRIPTION_AK) est dit de type UNIQUE, c'est-à-dire que la paire ne peut pas prendre deux fois la même valeur :
Prescription_AK.png)
Cela dit, le concept d’index n’est pas au bon niveau car il ressortit au MPD (Modèle Physique de Données), là où l’on met en place tous les turbos et autres objets de quincaillerie servant à la performance, alors qu’au stade MLD on reste dans le cocon logico-mathématique. Nonobstant, on ne fera pas la fine bouche, car si on utilise un autre SGBD que MySQL, il sera très facile de modifier le code SQL, en remplaçant l’index par une contrainte :
Code pondu par MWB pour la table PRESCRIPTION :
1
2
3
4
5
6
7
8
9
10
| CREATE TABLE IF NOT EXISTS `mydb`.`PRESCRIPTION`
(
`PrescriptionId` INT NOT NULL,
`PatientId` INT NOT NULL,
`PrescriptionDate` DATE NOT NULL,
`MedecinId` INT NOT NULL,
PRIMARY KEY (`PrescriptionId`),
UNIQUE INDEX `PRESCRIPTION_AK` (`PatientId` ASC, `PrescriptionDate` ASC),
...
) ; |
Code après lifting rapide :
1
2
3
4
5
6
7
8
9
10
| CREATE TABLE PRESCRIPTION
(
PrescriptionId INT NOT NULL,
PatientId INT NOT NULL,
PrescriptionDate DATE NOT NULL,
MedecinId INT NOT NULL,
CONSTRAINT PRESCRIPTION_PK PRIMARY KEY (PrescriptionId),
CONSTRAINT PRESCRIPTION_AK UNIQUE (PatientId, PrescriptionDate),
...
) ; |
Cas du numéro de sécu.
Deux personnes ne peuvent pas avoir le même numéro de sécu (on l’acquiert à la naissance), l’attribut NumeroSecu de la table PATIENT doit donc faire l’objet d’une clé candidate (alternative en l’occurrence). Avec MWB, Vous pouvez définir cette clé au moyen d’un index comme ci-dessus, mais quand une clé candidate est mono-attribut, vous pouvez alternativement cocher la case UQ (UNIQUE) qui va bien (onglet Columns) :
NumeroSecu.png)
Maintenant, reste à voir les cas particuliers, par exemple celui des enfants, car s’ils ont acquis un numéro de sécu à leur naissance, ils ne sont pas encore assurés.
Les interventions
Ajoutons deux ou trois pièces au lego. Je vous laisse le soin de connecter les interventions et les places (sont-ce les salles ? merci de préciser !), ainsi que les interventions et les utilisateurs les programmant :
Intervention_MWB.png)
Une intervention se raccroche à une prescription et je suppose qu’une prescription donne lieu à une seule intervention. S’il en est ainsi, on procédera comme pour le numéro de sécu :
IntervPrescr_AK.png)
Comme je l’ai écrit dans mon message précédent, il s’agit aussi d’éviter les situations scabreuses du genre :
« A la date du 17 avril 2013 le lit 32 est occupé par les patients Fernand, Raoul, Mado. »
En conséquence :
IntervLit_AK.png)
Questions :
Une activité peut-elle être pratiquée par plus d’un service ?
Un service peut-il pratiquer plus d’une activité ?
Concernant la table PLACE :
Vecteur_places.png)
Que représentent les 5 Code_uf_lundi, etc. ? Quoi qu’il en soit, l’expérience montre qu’il faut les dégager de la table PLACE et créer une table ad-hoc. En effet, au fil du temps votre structure peut être mise à mal (évolution dans la gestion des affectations des places, nouvelle direction demandant une affectation sur un mois, etc.), j’ai observé plusieurs fois ce genre de phénomène conduisant à pas mal de temps consacré à revoir le modèle, la base de données et la programmation. Le paradigme relationnel et la vectorisation font très mauvais ménage.
Aide sur la modélisation
Répondre avec citation
Appartenir.png)
Specialisation_MOO.png)
Specialisation_MCD.png)
Service_chirurgien.png)
Service_chirurgien_MOO.png)
Service_chirurgien_MCD.png)
Envoyé par arguitxu
Citer.png)
Quote_debut.png)
Quote_all.png)
Prescrire.png)
: il faut évidemment les supprimer. Pour cela, il faut faire un double clic sur la table pour avoir accès à l’onglet Columns, puis sélectionner la colonne en cause, puis clic droit à la souris pour accéder à la fonction de suppression :by_A_MWB_delelte_column.png)
by_A_MWB_lien_non_identifiant.png)
Medcin_MWB.png)
affectation_activite.png)
Affectations.png)
Urbaniser_A.png)
Urbaniser_B.png)
Urbaniser_C.png)
Urbaniser_D.png)
Urbaniser_E.png)
Urbaniser_F.png)
Urbaniser_G.png)
Urbaniser_H.png)
Partager