Discussion :

[Miko95]

Bonjour,
J'ai un mini projet à faire en base de données cette année. J'ai fais un diagramme entité-association et j'aimerais avoir des conseils de votre part sur ce qui est bon ou non.
La base de données gère un réseau de centre médicaux. Dans chaque centre médical travaillent plusieurs personnes: des professionnels de la santé et des secrétaires. La BDD gère une liste de patients pour tout le réseau. Chaque patient est affilié à un centre médical par rapport à sa commune. Chaque employé est affilié au centre médical dans lequel il travaille.
Chaque patient possède un dossier médical.
Un travailleur(professionnel de la santé ou secrétaire) peut aussi être patient et donc prendre un RDV avec un professionnel de la santé.

Je vous joins le diagramme réalisé sous Dia.

Merci d'avance

[CinePhil]

Tu écris en français sans problème, pourquoi avoir fait ton schéma en anglais ?

Tu peux externaliser la "city" dans une autre entité puisqu'elle apparait en relation avec les entités "Person" et "MedicalCenter".

Je crois comprendre que le "o" entre les deux branches de l'héritage sous l'entité "Person" signifie une exclusion :
"Une personne est un employé ou (exclusif) un patient."

Or dans tes règles de gestion il est dit :

Un travailleur(professionnel de la santé ou secrétaire) peut aussi être patient et donc prendre un RDV avec un professionnel de la santé.

Par contre, ne faudrait-il pas mettre une exclusion entre "Secretary" et "Physician" ?

Que signifie le double ovale autour de l'attribut "TelNumber" ? Clé alternative ?

Pourquoi avoir mis, pour l'entité "MedicalCenter", cet attribut au pluriel : "TelNumbers" ?
Si le centre médical peut avoir plusieurs numéros de téléphone, il vaut mieux créer une entité "TelNumber" et l'associer aux entités "Person" et "MedicalCenter".

[Miko95]

Merci pour la réponse. Pour ce qui est de la langue, c'est que je dois rendre le devoir en anglais.
Le "o" dans l'héritage signifie "overlapp", ce qui le contraire du ou exclusif. Quand le symbole "o" est absent, c'est un ou exclusif.
Le double ovale pour "TelNumber" signifie un attribut qui peut prendre plusieurs valeurs, dans ce cas, plusieurs numéros de téléphone. Pour ce qui est du "TelNumbers" au pluriel, c'est une erreur, c'est juste par rapport au fait que cet attribut peut prendre plusieurs valeurs.

Maintenant pour les attributs "City" et "TelNumber", tu penses qu'il est préférable de les externaliser dans de nouvelles entités même au stade du modèle conceptuel?

[CinePhil]

Le double ovale pour "TelNumber" signifie un attribut qui peut prendre plusieurs valeurs, dans ce cas, plusieurs numéros de téléphone. Pour ce qui est du "TelNumbers" au pluriel, c'est une erreur, c'est juste par rapport au fait que cet attribut peut prendre plusieurs valeurs.

Tu veux dire qu'une personne peut avoir plusieurs téléphones ? Et tu veux les stocker dans une seule colonne ? Conceptuellement, ce n'est pas bon !

Maintenant pour les attributs "City" et "TelNumber", tu penses qu'il est préférable de les externaliser dans de nouvelles entités même au stade du modèle conceptuel?

Oui bien sûr ! Surtout pour les numéros de téléphone parce qu'on ne met pas plusieurs données dans une colonne mais aussi pour la ville afin d'éviter les répétitions de noms de villes et les faux doublons (Saint-Etienne, Saint-Étienne, Saint Etienne, St Etienne St-Etienne).

[Miko95]

Voila le nouveau schéma.
J'aimerais savoir aussi au sujet du MedicalFile, sous quelle forme on représente cela dans le modèle conceptuel?

[CinePhil]

Si ton schéma se lit comme un MCD Merise, les cardinalités sur les nouvelles associations ne sont pas bonnes. En MCD, ça donnerait putôt ça :
Person -1,1----Person_City-------------------0,n- City
MedicalCenter -1,1----MedCenterCity----0,n-----|

Person -1,n----hasA----1,1- PhoneNumber
MedicalCenter -1,n----hasA----1,1----|

Person -1,1----isAffiliatedTo----0,n- MedicalCenter

J'aimerais savoir aussi au sujet du MedicalFile, sous quelle forme on représente cela dans le modèle conceptuel?

Ben c'est un attribut du patient comme tu l'as représenté. S'il s'agit d'un fichier physique, cette colonne contiendra l'URL du fichier. S'il s'agit de stocker en BDD tous les attributs d'un MedicalFile, il faut compléter le modèle de données en faisant une entité MedicalFile et peut-être des entités pour les maladies, les soins...
A toi de voir.

[fsmrel]

Si ton schéma se lit comme un MCD Merise, les cardinalités sur les nouvelles associations ne sont pas bonnes.

Les cardinalités du modèle de Chen ne se lisent pas comme celle des MCD Merise, voyez l’article de Chen :

http://csc.lsu.edu/news/erd.pdf

[Miko95]

En effet, au sujet des cardinalités, c'est le modèle de Chen qui est utilisé.
Comment pourrais je choisir entre utiliser un fichier ou des entités pour représenter un fichier médical("MedicalFile")? Autrement dis, quels sont les avantages et inconvénients de chaque méthode et qu'est qui est utilisé en général?

[CinePhil]

Les cardinalités du modèle de Chen ne se lisent pas comme celle des MCD Merise, voyez l’article de Chen :

http://csc.lsu.edu/news/erd.pdf

OK si je comprends bien, c'est à l'envers ? Comme les multiplicités d'un diagramme de classes ?

Comment pourrais je choisir entre utiliser un fichier ou des entités pour représenter un fichier médical("MedicalFile")? Autrement dis, quels sont les avantages et inconvénients de chaque méthode et qu'est qui est utilisé en général?

Si le dossier médical est seulement un fichier (de traitement de texte par exemple), il est plus simple de stocker en base de données le chemin d'accès au fichier stocké ailleurs sur le disque.
Si on veut extraire des informations du dossier médical, il vaut mieux modéliser celui-ci en enregistrant chaque information du dossier médical dans la base de données. Par exemple, il peut y avoir les associations suivantes (toujours en MCD Merise, c'est ce que je maîtrise le mieux) :
patient -0,n----attrapper----0,n- maladie
|-----------0,n----prescrire----0,n- traitement
|-----------0,n----bénéficier----0,n- soin
|-----------0,n----subir----0,n- opération
|-----------0,n----avoir----0,n- allergie
|-----------0,n----avoir----0,n- antécédent_familial
...

[fsmrel]

Les cardinalités du modèle de Chen ne se lisent pas comme celle des MCD Merise

OK si je comprends bien, c'est à l'envers ? Comme les multiplicités d'un diagramme de classes ?

Chen vous dira que ce sont les cardinalités merisiennes qui sont à l’envers...

Quant aux cardinalités dans un diagramme de classes, les permuter serait une erreur, car il n'y a pas la barrière de l'ovale pour se permettre ce genre de fantaisie et donner du sens à la lecture.

[CinePhil]

Chen vous dira que ce sont les cardinalités merisiennes qui sont à l’envers...

OK, je corrige en complétant ma phrase qui pouvait laisser penser à un jugement de ma part :
"OK si je comprends bien, c'est à l'envers par rapport à Merise ?"

[Miko95]

Voilà j'ai fais quelques changements.
Mais j'ai une autre question: dans le cas de l'entité "Speciality" par exemple, logiquement, deux spécialités ne peuvent avoir le meme nom car on ne pourrait pas les distinguer. Dans ce cas, est ce qu'il est raisonnable d'enlever l'attribut "IdSpeciality" et de définir l'attribut "NameSpeciality" comme clé?

[CinePhil]

Voilà j'ai fais quelques changements.

Attention ! Un code postal peut concerner plusieurs cities et une city peut avoir plusieurs codes postaux. Mais vous avez mis en clé primaire composée les deux attributs donc c'est acceptable, même si ça fait une clé de mauvaise qualité.
Ce qui amène à repondre par la négative à la question suivante :

Mais j'ai une autre question: dans le cas de l'entité "Speciality" par exemple, logiquement, deux spécialités ne peuvent avoir le meme nom car on ne pourrait pas les distinguer. Dans ce cas, est ce qu'il est raisonnable d'enlever l'attribut "IdSpeciality" et de définir l'attribut "NameSpeciality" comme clé?

Au niveau conceptuel, on pourrait dire effectivement que le nom de la spécialité est une clé candidate mais en prévision de l'implémentation de la future BDD, il vaut mieux prévoir de suite une clé anonyme de type entier.
Lire à ce sujet l'article de SQLPro sur la qualité d'une bonne clé.

[Miko95]

Merci et donc la réponse s'applique aussi pour le type entité "PhoneNumber"?
Autrement dis, dois-je prévoir une clé de type entier autre que le numéro de téléphone?

[CinePhil]

Merci et donc la réponse s'applique aussi pour le type entité "PhoneNumber"?
Autrement dis, dois-je prévoir une clé de type entier autre que le numéro de téléphone?

Je dirais oui.

[fsmrel]

Bonsoir à vous deux,

Voilà j'ai fais quelques changements.
Mais j'ai une autre question: dans le cas de l'entité "Speciality" par exemple, logiquement, deux spécialités ne peuvent avoir le même nom car on ne pourrait pas les distinguer. Dans ce cas, est ce qu'il est raisonnable d'enlever l'attribut "IdSpeciality" et de définir l'attribut "NameSpeciality" comme clé?

Au niveau conceptuel, on pourrait dire effectivement que le nom de la spécialité est une clé candidate mais en prévision de l'implémentation de la future BDD, il vaut mieux prévoir de suite une clé anonyme de type entier.

De fait, lors du passage au niveau SQL, l’entité-type SPECIALITY fera l’objet d’une table, laquelle comportera deux clés :

La 1re sera celle que CinePhil préconise, c'est-à-dire une clé prenant des valeurs dépourvues de signification (le choix du type, entier ou autre, est ici secondaire c’est le critère d’invariance qui prime). C’est elle qui sera utilisée pour les opérations de jointure.

La 2e sera celle qui vous tient à cœur et dont l’objet sera seulement de garantir l’unicité des valeurs pour l’attribut NameSpeciality et servira à l’utilisateur pour accéder aux données (l’attribut IdSpeciality devrait lui être caché) :

Code :

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

1
2
3
SPECIALITY {IdSpeciality, NameSpeciality, ...}
    PRIMARY KEY {IdSpeciality}
    UNIQUE {NameSpeciality} ;

Le double ovale pour "TelNumber" signifie un attribut qui peut prendre plusieurs valeurs, dans ce cas, plusieurs numéros de téléphone.

Tu veux dire qu'une personne peut avoir plusieurs téléphones ? Et tu veux les stocker dans une seule colonne ? Conceptuellement, ce n'est pas bon !

Conceptuellement la représentation de Miko est parfaitement acceptable et Dominique Nanci préconise cette solution en Merise (Ingénierie des systèmes d’information Merise, Deuxième Génération (3e édition, page 137)). Il fournit à cette occasion l’exemple suivant :



Toujours d’un point de vue conceptuel, j’ajouterai que l’attribut TelNumber est une propriété non pas mono, mais multivaluée et qu’il n’y a aucune raison d’en faire une entité-type. Dans le cadre de la théorie relationnelle, TelNumber peut donner lieu à une RVA (Relation Valued Attribute), manipulable par les opérateurs relationnels traditionnels, plus les opérateurs GROUP et UNGROUP. Par contre, il est recommandé en SQL de mettre en oeuvre une table des numéros de téléphone.

Si l’AGL (CASE tool) utilisé pour la construction du MCD est capable de dériver la propriété multivaluée sous forme d’une table, autant conserver le double ovale du 1er MCD. Accessoirement ça allège le MCD et surtout ça permet d’éviter de mettre en œuvre une entité-type forte (regular entity) PhoneNumber. Si l’AGL ne traduit pas le double ovale par une table, on peut se rabattre sur l’utilisation d’une entité-type faible (weak entity) permettant de préserver la vraie nature de la propriété multivaluée. Dans l’article de Chen, une entité-type faible est représentée par un double rectangle (fig. 11).

En outre, pourquoi factoriser dans l’entité-type PhoneNumber les numéros de téléphone des centres avec ceux des personnes ? Pour rester cohérent, il faudrait en faire autant pour les attributs Street et NoStreet... Je note par ailleurs que, sauf erreur d’interprétation de ma part de la représentation « chenienne », un numéro de téléphone donné fait référence à la fois à un centre et à une personne. Si l’on corrige en disant qu’un n° de téléphone peut être celui d’un centre et pas d’une personne (et réciproquement), alors au niveau SQL on aura une table avec des clés étrangères polluées par le bonhomme NULL. A mon sens, cette entité-type PhoneNumber n’est pas saine. Il vaut mieux revenir à la solution initiale ou définir deux entités-types faibles.

Si l’on veut factoriser les téléphones et dans la foulée tous les attributs communs aux entités-types MEDICALCENTER et PERSON, on peut toujours procéder à une généralisation et définir une entité-type ENTITY ayant pour sous-types MEDICALCENTER et PERSON (avec exclusion entre sous-types) et dotée des attributs communs (sans oublier les associations-types communes, par exemple avec l’entité-type CITY).

[Miko95]

Bonjour,

Merci pour les réponses, j'ai converti le MCD en modèle relationnel, j'ai joins le diagramme au post. Est ce qu'il y aurait des choses à arranger ou des erreurs dans la conversion? Sinon pour les attributs, je ne sais pas si c'est juste, je ne m'y connais pas trop dans les types en SQL sous ORACLE. Pour les attributs Salary et HoursWorked, je veux que ce soit un nombre décimal mais je ne sais pas quel type utiliser.

Merci d'avance pour votre aide

[fsmrel]

Bonjour,


Comme l’a fait observer CinePhil, les identifiants des entités-types — donc les clés primaires des tables qui en sont dérivées — doivent de préférence être du type ENTIER, conseil que vous appliqué pour les entités-types MedicalCenter, Allergy, etc., mais vous avez oublié de le faire pour l’entité-type Person.

Comme je l’ai déjà fait observer, les clés primaires sont invisibles pour l’utilisateur et servent plutôt à réaliser les jointures entre tables. En revanche, il faut que l’utilisateur ait un moyen d’accéder aux informations qui le concernent. Ainsi, un centre médical devait être doté d’un numéro contrôlé par l’utilisateur, le SGBD devant seulement garantir l’unicité des valeurs de ce numéro (cf. la clause UNIQUE que j’ai déjà mentionnée). Même principe pour les personnes. A noter que le sous-type Patient devrait normalement être porteur d’un attribut NIR (numéro de sécurité sociale).

Table MedPhoneNumber : l’attribut MedCenterId compose la clé étrangère permettant de référencer MedicalCenter, très bien. Mais cet attribut n’a pas à faire partie de la clé primaire de la table MedPhoneNumber, sinon vous autorisez les numéros de téléphone en double.

Pourquoi avoir conservé une entité-type PPhoneNumber pour les personnes ? Qu’est-ce qui vous empêche de faire comme pour les centres médicaux ?

Lien entre les tables Person et Patient : vous avez défini une cardinalité N côté Person : il faut remplacer par 1, sinon cela voudrait dire qu’une personne peut être N fois patient. Cela vaut évidemment pour tous les autres liens entre types et sous-types.

Corriger les autres cardinalités défectueuses : entre Patient et Allergy, Patient et Disease, etc.

Concernant les attributs Salary et HoursWorked, je ne connais pas particulièrement les types utilisables en Oracle, mais peut-être pouvez-vous essayer quelque chose comme NUMBER(10,2). Vous pouvez aussi consulter le forum Oracle à ce sujet.

[Miko95]

Merci pour la réponse détaillée.
J'ai fais plusieurs modifications suite à vos conseils.J'ai aussi modifié les cardinalités, j'espère ne pas m'etre trompé dans le sens parcque là je commence à m'embrouiller par rapport au modèle relationnel,conceptuel(merise et chen).

Pour ce qui est de la table PPhoneNumber, le cas est différent par rapport aux centres médicaux car dans ce cas, une personne peut avoir plusieurs numéros de téléphone et un numéro de téléphone peut correspondre à plusieurs personnes(ex: pére et fils ayant le meme téléphone).

[fsmrel]

J'ai aussi modifié les cardinalités, j'espère ne pas m'etre trompé dans le sens parcque là je commence à m'embrouiller par rapport au modèle relationnel,conceptuel(merise et chen).

Il y a effectivement de quoi s’embrouiller, mais les cardinalités sont correctes.

Pour ce qui est de la table PPhoneNumber, le cas est différent par rapport aux centres médicaux car dans ce cas, une personne peut avoir plusieurs numéros de téléphone et un numéro de téléphone peut correspondre à plusieurs personnes(ex: pére et fils ayant le meme téléphone).

Je suis moins que moyennement d’accord. En effet, si deux personnes peuvent avoir le même n° de téléphone — le père et le fils pour reprendre votre exemple — elles peuvent aussi porter le même nom mais pour autant vous n’avez pas jugé utile de mettre en oeuvre une table des noms. Conceptuellement, les téléphones ne méritent pas plus que les noms de faire l’objet d’une entité-type forte. Par ailleurs, en conservant la table PPhoneNumber, vous vous compliquerez la vie lors des opérations (une jointure de plus). Pour conserver cette table, il faudrait faire valoir des arguments sémantiquement plus charpentés que celui que vous avancez. Pour ma part, je l’évacuerais. Et en l’occurrence, si un numéro de téléphone peut exister en plus d’un exemplaire, il suffit que la clé primaire de la table Person_PPhoneNumber soit composée de la paire {IdPerson, IdPhoneNumber}. Dans votre MLD, cela revient simplement à supprimer la table PPhoneNumber.


Table Person : l’attribut NoStreet est du type Integer : que se passe-t-il si la personne habite au 14 bis ?

Table MedicalCenter : même remarque.