Discussion :

[lolodij21]

Bonjour à tous.
Je dois réaliser une petite base de données visant à enregistrer des demandes de communication de dossiers personnels. Or je bute dès le début, ce qui est des plus encourageant...
Dans les grandes lignes, une personne effectue une demande de communication de dossier :

Voici les règles qui me posent problème, en espérant être assez précis :
Une personne demande soit son propre dossier, soit le dossier d'une autre personne, si elle est en droit de le faire (pour être précis, on peut demander le dossier de son enfant mineur, ou d'un parent décédé)
Et je ne vois pas du tout comment modéliser cela...
Dois je utiliser une relation réflexive sur les personnes ( 0,n .... 0,n me semble difficile car cela impliquerait je crois l'impossibilité qu'une personne effectue par exemple deux fois la demande du dossier de son enfant par exemple...).
Est il préférable de créer 2 entités distinctes du style Personne_Demandeur et Personne_Demandée ?
ou alors 2 relations entre personne et demande ( 1 relation "Faire" et 1 relation "concerner", ce qui permettrait de remonter 2 clés étrangères dans la table demande ? )
Bref, je suis un peu perdu et très demandeur de vos conseils avisés, même si j'ai surement sorti beaucoup d'inepties en quelques lignes.
Merci d'avance...

[escartefigue]

Bonjour,

Une relation réflexive ne vous empêche pas de faire plusieurs demandes

Je pense que ce modèle correspond à votre besoin :

Pièce jointe 245474

Ce qui donne le MPD suivant :
Pièce jointe 245475

Afin de vérifier que le demandeur est habilité à demander le dossier de la personne concernée, vous devrez créer une contrainte dans la table Demande_DE qui pointe sur la table Habiliter.
Le DDL ressemblera à quelque chose comme suit (en fonction du SGBD choisi, la syntaxe varie) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
create table DEMANDE_DE 
  (PE_ID                numeric              not null,
   DE_ID                numeric              identity,
   DOS_PE_ID            numeric              not null,
   DO_ID                char(10)             not null,
   TY_ID                numeric              not null,
   DE_REF               char(6)              not null,
   constraint PK_DEMANDE_DE 
              primary key (PE_ID, DE_ID)
   constraint FK1_ref_habilitation
              foreign key(PE_ID, DOS_PE_ID)
              references Habiliter(PE_ID, PER_PE_ID)
  )

Pour que cette solution fonctionne, il faut que chaque personne soit "auto-habilitée" relation de la personne sur elle même
Après il faudra préciser si plusieurs personne ont le droit ou non de déposer des demandes pour un même dossier ?

[lolodij21]

Bonjour Escartefigue, et avant tout un grand merci pour vous être penché sur mon problème.
Votre schéma a éclairé un peu ma lanterne, mais je ne comprends pas bien le rôle de l'entité Type_TY dans le MCD ?
En revanche mes contraintes ont changé ce matin : ce n'est pas simplement une personne physique qui peut demander un dossier, mais également une société ( sans contrainte de lien de parenté ). C'est pourquoi je pense devoir abandonner l'idée de relation réflexive et m'orienter vers de l'héritage. ( peux être est ce stupide ? )
Quoi qu'il en soit, je joins le schéma de mon travail en l'état actuel, en espérant que vous pourrez m'apporter quelques conseils.
Je pense qu'il est plein d'incohérences, mais mes quelques cours de conception de BDD remontent à loin....
Pour répondre à votre question, oui plusieurs personnes peuvent être à même de demander un même dossier.
Encore merci.

[escartefigue]

J'avais pensé à une entité-type pour typer les demandes si besoin : demande de consultation de dossier, de résiliation, de clôture, de modification etc...
D'ailleurs si j'avais été au bout de la démarche, l'attribution aurait du elle aussi bénéficier d'un typage (droit de consulter, de résilier etc...)

Concernant votre évolution, il me semble que vous pouvez maintenir une relation réflexive de personne à personne, une personne en autorise une autre à consulter son dossier, peu importe que l'une ou l'autre de ces personnes soit physique ou morale.

Attention :
- en cas de modélisation par héritage, les attributs nom, prénom et civilité doivent être dans le sous-type "PERSONNE PHYSIQUE"
- dans tous les cas, le(s) téléphone(s) doivent être modélisés dans une entité-type spécifique, en dehors de la personne et de ses sous-types, il en va de même avec les adresses et les courriels

[lolodij21]

Je vais retravailler les entités téléphone et mail ( puis je selon vous les regrouper en une unique entité contact par exemple ?) ainsi que l'emplacement des attributs.
Est ce gênant à votre avis si je choisis de conserver la modélisation de l'héritage ? elle me semble plus compréhensible pour un débutant en modélisation comme moi ou est ce une erreur grossière ?
Sinon que pensez vous à vue d’œil du MCD ? n'y a t il pas trop d'erreurs ou d'incohérences ? c'est surtout la façon que j'ai de stocker le lien de parenté éventuel qui me laisse perplexe.
Merci beaucoup à vous.

[escartefigue]

Si vous êtes puriste, il ne faut pas regrouper courriel et téléphone car courriel se modélise avec 2 entité-type une pour l'adresse une pour la DNS
Mais j'avoue qu'à titre personnel, j'y fais entorse sans que ça ne m'empêche de dormir

Vous avez tout à fait raison de procéder par héritage, ainsi vous mutualisez ce qui doit l'être et séparez ce qui est spécifique
Vous pouvez considérer que le médecin et les patients sont également des personnes physiques :
- ca vous évite les redondances (nom, prénom etc...)
- ca qui facilite la gestion des adresses, surtout si vous utilisez l'identification relative pour que l'adresse hérite de l'identifiant personne comme composante de sa PK (et accessoirement ça optimisera vos requêtes)
Du coup il faudra déterminer quels sont les sous-types de personnes qui sont en relation avec la demande
Est-ce que les professionnels et les médecins sont les mêmes personnes ?

Par contre, qu'est ce qui différencie les deux relations "créer" et "réaliser" (mêmes cardinalités, pas d'attribut) ? n'y a -t- il pas une seule relation entre la personne (quelque soit son type) et la demande

Entre patient et séjour, il faut une cardinalité mini de zéro coté patient (je suppose que tout patient ne fait pas obligatoirement un séjour)
Pourquoi ne pas modéliser PATIENT(ID, nom, prénom...) 0,n --- sejourner (date debut, date fin, motif) --- 0,n SERVICE 1,1 --- Appartenir --- 1,n ETABLISSEMENT
Avec l'attribut MOTIF de la relation séjourner qui peut bien sur faire l'objet d'une typologie (en ce cas, relation à 3)

[lolodij21]

Bonjour Escartefigue. Voici les modifications que j'ai apportées à mon MCD suivant vos conseils :

Est-ce que les professionnels et les médecins sont les mêmes personnes ?

Non, ce ne sont pas les mêmes : "Professionnels" serait par exemple une compagnie d'assurances, à même de demander un dossier.

qu'est ce qui différencie les deux relations "créer" et "réaliser" (mêmes cardinalités, pas d'attribut) ? n'y a -t- il pas une seule relation entre la personne (quelque soit son type) et la demande

Vous avez tout à fait raison, grossière méprise de ma part. En fait, j'ignorais s'il était correct d'affecter une relation à une entité qui au final sera une classe "abstraite" dans mon futur code Java.. J'ai donc tenté de modifier le MCD en conséquences.

Entre patient et séjour, il faut une cardinalité mini de zéro coté patient (je suppose que tout patient ne fait pas obligatoirement un séjour)

Après vérification, il apparait que toute demande "validée" par l'application devra concernée un patient ayant effectué un séjour, donc puis je laisser ma cardinalité à 1 ?

Pourquoi ne pas modéliser PATIENT(ID, nom, prénom...) 0,n --- sejourner (date debut, date fin, motif) --- 0,n SERVICE 1,1 --- Appartenir --- 1,n ETABLISSEMENT

Vous avez encore une fois raison. Cela ne m'est pas utile pour l'instant, mais ayant pu poser la question ce matin, il semble qu'à terme l'application pourrait gérer des dossiers d'autres établissement. J'ai donc essayé de modéliser tout ceci comme suit :


Qu'en pensez vous ? Est ce que je me rapproche du but ?
Encore merci pour le temps que vous me consacrez...

[escartefigue]

Après vérification, il apparait que toute demande "validée" par l'application devra concernée un patient ayant effectué un séjour, donc puis je laisser ma cardinalité à 1 ?

Si vous laissez 1, alors la FK est "not nul" dans la table, du coup, vous êtes contraint de créer le patient ET le séjour simultanément.
Si vous voulez pouvoir créer un patient, puis une consultation quelques jours plus tard, alors il faut mettre zéro

Pour le reste en regardant rapidement

- Vous avez laissé les attributs propres à une personne physique dans l'ET personne au lieu de les déplacer dans la personne physique
- La séparation demandeur / autre fait qu'un patient ne peut pas être demandeur, Est-ce une règle, un patient ou ancien patient ne peut il demander pour lui même ou pour autrui ? Que se passe -t- il si un ancien demandeur devient lui même patient...
- Un patient est une personne, vous pouvez donc en faire un sous-type d'un particulier et éviter ainsi les redondances nom, prénom etc... et il faut en ce cas distinguer autrement la notion de demandeur et autre (point précédent)
- Vous avez inversé les cotés des cardinalités autour de l'ET personne (pour adresse et contact) , là aussi, il faut peut être prévoir des card mini de zéro plutôt que 1 ?

[lolodij21]

Bonjour Escartefigue.
Concernant les cardinalités Personne/Contact et Personne/Adresse : le 0 en mini est effectivement une bien meilleure solution. Mais si je les inverse, ne vais je pas me retrouver coincé si une adresse correspond à plusieurs personnes ( cas de 2 personnes habitant le même immeuble par exemple ? )
Pour la relation patient/sejour vous avez raison également je vais faire les modifications.
Pour les attributs que j'ai laissé dans l'entité personne, je pensais (certainement à tort ?) qu'en les laissant là cela permettrait à toute mes classes Java d'hériter des attributs ( professionnel, Personnes, Médecin, patients ont à mon sens tous un nom, prénom, civilité en plus des attributs spécifiques, comme la raison sociale de l'entité professionnel)
Pour ce qui est de mes relations demandeur patient, c'est la que je ne suis pas au clair. je pense que ma modélisation est mauvaise et je vais essayer de vous détailler au mieux les règles de gestion dont je dispose:
la base vise a enregistrer des demandes de dossiers, dans le cadre de la loi permettant à chaque personne l'accès à son dossier médical. Ainsi :
une personne peut demander son dossier médical auprès d'un établissement de soins. (la personne physique est donc dans ce cas également le "patient")
une personne peut également demander le dossier :

• d'un autre patient mineur, si et seulement si elle en est le tuteur légal (on son père/ sa mère).

• d'un autre patient dont elle est ayant droit (une personne peut ainsi demander le dossier de son père décédé).

Cela se complique un peu car une entité tiers ( ce que j'ai appelé "professionnel" ) peut également demander un dossier ( si elle en à l'autorisation ) pour le compte de quelqu'un ( par exemple un avocat, notaire,assureur... peut demander le dossier d'un client )
C'est ce qui génère les demandes, accompagnées de pièces justificatives ( mon entité Fichier)
le traitement de ces demandes impose que le dossier soit envoyé soit à l'adresse du demandeur, soit à un médecin ( raison pour laquelle j'ai crée l'entité médecin.)
Je crois que c'est tout ce bloc personne/patient/demandeur que je ne parviens pas à modéliser efficacement . Qu'en pensez vous ?

[escartefigue]

Bonjour Escartefigue.
Concernant les cardinalités Personne/Contact et Personne/Adresse : le 0 en mini est effectivement une bien meilleure solution. Mais si je les inverse, ne vais je pas me retrouver coincé si une adresse correspond à plusieurs personnes ( cas de 2 personnes habitant le même immeuble par exemple ? )

En modélisant PERSONNE 0,n --- Resider --- (1,1) ADRESSE vous donnez la possibilité à une personne d'avoir plusieurs adresses
C'est intéressant pour les personnes physiques (adresse domicile, de villégiature...) et surtout pour les personnes morales (adresse de livraison, de facturation, du siège...)
Le même raisonnement tient aussi pour les téléphones (fixe pro, fixe domicile, portable perso, portable pro, portable d'astreinte ...)
Dans l'autre sens, si plusieurs personnes partagent la même adresse, par exemple les membres d'une même famille, il faut en effet dupliquer les données, mais c'est la bonne méthode. Quand par exemple un enfant quitte le foyer, vous pourrez modifier son adresse, et seulement la sienne, sans modifier celle des autres membres de la famille.
Et si vous avez utilisé l'identification relative, vous conserverez en outre la proximité physique des données pour chaque membre de la famille dans mon exemple, quelque soient les mises à jour (dans les faits c'est un peu plus compliqué que ça, il y a des notions de fragmentation et autres qui interviennent, mais je simplifie )

Pour les attributs que j'ai laissé dans l'entité personne, je pensais (certainement à tort ?) qu'en les laissant là cela permettrait à toute mes classes Java d'hériter des attributs ( professionnel, Personnes, Médecin, patients ont à mon sens tous un nom, prénom, civilité en plus des attributs spécifiques, comme la raison sociale de l'entité professionnel)

C'est que de mon coté, j'avais supposé que certains professionnels étaient des entreprises, auquel cas pas de nom, prénom, date de naissance, mais une raison sociale, un SIREN, un NIC, un code NAF...

Pour ce qui est de mes relations demandeur patient, c'est la que je ne suis pas au clair. je pense que ma modélisation est mauvaise et je vais essayer de vous détailler au mieux les règles de gestion dont je dispose:
la base vise a enregistrer des demandes de dossiers, dans le cadre de la loi permettant à chaque personne l'accès à son dossier médical. Ainsi :
une personne peut demander son dossier médical auprès d'un établissement de soins. (la personne physique est donc dans ce cas également le "patient")
une personne peut également demander le dossier :

• d'un autre patient mineur, si et seulement si elle en est le tuteur légal (on son père/ sa mère).

• d'un autre patient dont elle est ayant droit (une personne peut ainsi demander le dossier de son père décédé).

Cela se complique un peu car une entité tiers ( ce que j'ai appelé "professionnel" ) peut également demander un dossier ( si elle en à l'autorisation ) pour le compte de quelqu'un ( par exemple un avocat, notaire,assureur... peut demander le dossier d'un client )
C'est ce qui génère les demandes, accompagnées de pièces justificatives ( mon entité Fichier)
le traitement de ces demandes impose que le dossier soit envoyé soit à l'adresse du demandeur, soit à un médecin ( raison pour laquelle j'ai crée l'entité médecin.)
Je crois que c'est tout ce bloc personne/patient/demandeur que je ne parviens pas à modéliser efficacement . Qu'en pensez vous ?

On en revient donc aux habilitations. Vous devez gérer une relations entre les personnes pour savoir qui habilite qui, et éventuellement pour quel type d'habilitation et éventuellement aussi, de telle date à telle date

[lolodij21]

Que de douleur....
Alors voila ou j'en suis. ( j'ai supprimé les entités étrangère à mon problème.)
Suppression de l'entité "Autre" ( inutile je pense...)
Je n'ai toujours pas fait hériter "patient" de "particulier" car l'entité "patient" représente peut être davantage une sorte "d'identité cible" de la demande plutôt qu'une personne physique et en conséquence elle ne pourrait effectuer une demande ?
Je ne comprends vraiment pas comment exprimer le fait qu'une personne physique puisse demander soit son propre dossier soit celui d'une autre personne ( ou alors en dupliquant les infos de particulier vers l'entité patient dans le cas d'une demande pour elle même ? c'est surement ridicule mais bon...)
Bref, plus j'essaie d'avancer et plus j'ai l'impression de me mélanger les pinceaux....

[lolodij21]

Alors.... J'ai quelque peu modifié la situation....
J'ai choisi de supprimer mon entité "Patient", considérant qu'un patient est de toutes manières une personne et qu'en fait une personne autorisée demande le dossier d'elle même ou d'une autre personne.
J'ai tenté de représenter les notion de parenté et d'autorisation pour un professionnel par la relation récursive sur "Particulier" et la relation "autoriser" entre "Particulier" et "Professionnel"
J'ai créer la relation "cibler" pour illustrer le fait qu'une demande "vise" un particulier.
En bref, le cœur de mon MCD ressemble dorénavant à ceci :

Cela me semble "brouillon", mais je commence à être à cour d'idées....
Un grand merci pour vos futurs commentaires.

[escartefigue]

Bonjour,

Voici un modèle assez proche, qui permet de mutualiser les attributs communs aux personnes physiques, et évite la répétition des attributs n° de téléphone dans l'ET contact.
Il suffit dans les types de contact de créer un type tel fixe pro, tel fixe privé, tel portable pro, courriel pro etc...

Je n'ai pas modélisé les adresses dont le principe est exactement le même que pour les contacts

J'ai considéré qu'un médecin pouvait également être patient, c'est pourquoi l'héritage2 n'est pas exclusif

Avec ce modèle, toute personne, physique ou morale, peut effectuer une demande de dossier.
Avec votre modèle un membre de la famille ou un autre médecin ne pouvait pas demander de dossier, ici c'est possible

Vous vérifierez que la personne effectuant la demande est habilitée grâce à une contrainte (cf. mon post du 17-02 à 9h02)

Bien sur les attributs et leur type sont mis à titre d'exemple, à compléter et corriger si besoin

Le MCD :
Pièce jointe 247700


Le MPD (ici généré pour SQL server 2012) :
Pièce jointe 247707

[lolodij21]

Bonjour Escartefigue. Merci infiniment. C'est beaucoup plus clair après tous vos éclaircissements.
Je dispose enfin d'une base solide, grâce à vous.
Je passe le sujet en résolu,en espérant vous recroiser sur le forum prochainement.

[escartefigue]

Avec plaisir

N'oubliez pas de prototyper la solution (et notamment de faire tourner les requêtes les plus critiques) avant de vous lancer bille en tête, les échanges aux moyens du forum sont certes riches, mais des choses ont pu m'échapper, des règles ont pu évoluer ou être mal comprises, et un prototype est toujours une étape nécessaire

Je profite de cette réponse pour corriger un oubli de ma part :
J'avais enrichi la relation Habilitation d'un type habilitation, ce qui fait que la table résultante a une clef primaire composée de 3 attributs.
Par contre, j'ai oublié de faire de même coté demande, si la demande n'est pas typée, alors la contrainte de type référence ne sera pas applicable

Il faut donc ajouter le typage des demandes, ou ne pas typer les habilitations

Bon courage pour la suite