Discussion :

[PolkovnikMedved]

Bonjour,

Je voudrais vous demander de l'aide pour un exercice.
Je dois faire un schéma entité-association d'une inscription d'un enfant à la crèche. J'ai fait une partie du schéma mais certaines parties me semblent étranges.

Les données qu'on a :

On à une crèche dans laquelle travaillent des employés (puéricultrices et autres).
Les parents inscrivent leur enfant à la crèche ils doivent compléter le dossier de l'enfant avec les informations sur l'enfant tels que :
1) Photo, certificat médical d'entrée de l'enfant à la crèche, carnet médical.
2) Son dossier médical complet
3) Les personnes de contact autres que les parents
4) Les frères/sœurs de l'enfant.

Mon problème est de modéliser les frères/sœurs de l'enfant, les personnes de contact mais aussi la phrase : les parents inscrivent leur enfant dans une crèche.

Je vous remercie d'avance pour vos réponses.

[escartefigue]

Bonjour

Il y a plusieurs soucis dans votre modèle, le principal est qu'il n'y a aucun lien entre parent et enfant

Il faudrait modéliser quelque chose comme

PARENT 1,n -- inscrire -- 1,2 ENFANT
PARENT 0,N -- deposer -- 1,1 DOSSIER_MEDICAL
DOSSIER_MEDICAL 1,1 -- rediger -- 0,n CABINET_MEDICAL
DOSSIER_MEDICAL 1,1 -- concerner -- 0,n ENFANT

Par ailleurs, plutôt que modéliser à plat les moyens de contact, il est préférable de les externaliser dans une entité-type dédiée

PARENT 0,n --- communiquer ---1,1 MEDIA 1,1 -- typer -- 0,n TYPE MEDIA
dans média vous avez comme attribut un numéro (au format char) et un code type (téléphone fixe pro, fixe privé, portable pro, portable astreinte, portable privé etc...)
Le code type est associé à une entité-type "TYPE MEDIA" pour les libellés

[PolkovnikMedved]

Merci pour vos remarques escartefigue,

En attendant une réponse j'ai légèrement modifié mon schéma et je viens d'y ajouter vos remarques.

Par contre j'ai quelques questions :
1) Doit-on tout normaliser ?
car dans ce cas, je peux créer une entité pour les moyens de contact mais aussi pour les adresses (ex: Lieu(code_postal, localité)).

2) Vous avez écrit : DOSSIER_MEDICAL 1,1 -- rediger -- 1,1 CABINET_MEDICAL.
Mais à mon avis un cabinet médical rédige 1 à N dossiers médicaux, non ?

3) Si mon schéma actuel est +/- correct, il faut que j'y ajoute aussi les frères/sœurs de l'enfant inscrit à la crèche (et ils peuvent être inscrits à la crèche aussi) mais aussi les personnes de contact qui pourraient être de la famille ou pas et c'est là que je bloque. Comment représenter tout ça ? J'ai pensé a remplacer l'entité "Parents" par l'entité "Membre de famille" mais j'ai alors une relation réflexive "est parent de" ainsi qu'une relation réflexive "est membre de famille de " ?

Merci pour vos réponses.

[escartefigue]

1) Doit-on tout normaliser ?
car dans ce cas, je peux créer une entité pour les moyens de contact mais aussi pour les adresses (ex: Lieu(code_postal, localité)).

En effet, c'est d'ailleurs ce que l'on fait le plus souvent, pour pouvoir gérer plusieurs adresses pour une personne (domicile, travail, résidence temporaire etc...)

2) Vous avez écrit : DOSSIER_MEDICAL 1,1 -- rediger -- 1,1 CABINET_MEDICAL.
Mais à mon avis un cabinet médical rédige 1 à N dossiers médicaux, non ?

Exact, je l'avais corrigée entre temps ainsi que d'autres cardinalités mises à la hâte

3) Si mon schéma actuel est +/- correct, il faut que j'y ajoute aussi les frères/sœurs de l'enfant inscrit à la crèche (et ils peuvent être inscrits à la crèche aussi) mais aussi les personnes de contact qui pourraient être de la famille ou pas et c'est là que je bloque. Comment représenter tout ça ? J'ai pensé a remplacer l'entité "Parents" par l'entité "Membre de famille" mais j'ai alors une relation réflexive "est parent de" ainsi qu'une relation réflexive "est membre de famille de " ?

Vu que l'association entre parents et enfants a une cardinalité maxi n de chaque coté, elle va devenir une table, et du coup il sera très facile de trouver tous les enfants qui ont un parent en commun

Par ailleurs, les attributs téléphone, adresse etc.. ne doivent pas être dans l'entité-type dossier médical, mais dans le cabinet médical, et même idéalement dans une nouvelle ET en lien 0,n avec le cabinet médical (comme pour les parents)

[PolkovnikMedved]

Encore une fois merci pour vos réponses,

En tenant compte de toutes vos remarques (j'ose espérer !), je vous propose la dernière (?) version de mon schéma.

J'ai un peu réorganisé pour plus de clarté et normalisé certaines tables.

Qu'en dites-vous ?

Merci d'avance.

[escartefigue]

Dans cette nouvelle version, il y a beaucoup de liaisons circulaires, et j'ai le sentiment que certaines relations ne sont pas utiles

Par exemple, pour aller d'un enfant à sa crèche, on peut soit utiliser le chemin court via l'association registerd ou keep, soit passer par la relation avec ses parents, puis nursery_record pour arriver au même endroit.

• Pourquoi 2 relations courtes entre l'enfant et la crèche ? y a -t- il des cas où l'enfant est inscrit dans une crèche mais gardé dans une autre ?
• Pourquoi lier l'enfant ET ses parents à une crèche ? Des parents pourraient donc avoir à faire avec des crèches dans lesquelles ils n'ont pas d'enfant ?

La relation "is_located" avec ses 4 pattes correspond à quoi ? Une relation à 4 pattes c'est au moins une patte de trop

Pourquoi définissez vous un lien entre un dossier médical et une crèche ? Le dossier médical est en lien avec l'enfant et le cabinet médical
Par le lien enfant, vous pouvez connaitre la crèche (éventuellement à date si l'enfant change de crèche)

Je vois que vous avez défini à la fois des dossiers médicaux et des dossiers de nursery, quels sont les rôles respectifs, quel est la nature du lien entre les 2, l'association owns me semble suspecte

[PolkovnikMedved]

Merci pour votre réponse escartefigue,

Alors en effet, il y a beaucoup de relations circulaires et vos remarques me permettent de mieux comprendre le modèle E-R !

J'ai essayé de tenir compte de toutes vos remarques depuis le premier post, de virer les relations circulaires et voici ce que cela me donne (vois schéma).

J'ai viré les relations :
Parents --- déposer -- dossier_médical
Parents --- inscrire --- enfant
Parents --- rassembler -- dossier_crèche
Enfant --- inscrire --- crèche
Relation owns
J'ai séparé la relation is located en is located et live

Néanmoins, certaines nouvelles questions me sont apparues :

Votre remarque sur les medical/nursery record : en fait les parents en inscrivant leur enfant dans la crèche doivent remplir le formulaire par rapport à la crèche mais aussi par rapport à l'état de santé de l'enfant. Ceci dit, si dans la vie courante ce serait deux dossiers séparés, ici je pense qu'on peut dire que le dossier médical étend le dossier de la crèche et mettre une relation d'héritage. (?) On aurait alors : Enfant --1,N-- |concerne| Dossier_crèche --|héritage|-- Dossier_médical.

j'ai réussi à séparer la relation 'is located' qui avait 4 pattes mais je ne vois pas comment séparer la relation 'communicate' anciennement 'has'.

J'ai modélisé les horaires de la crèche avec une relation : crèche ---0,7--- |est ouverte| ---1,1--- Horaire. Ceci veut dire que à chaque fois qu'on enregistre une crèche, on va devoir avoir 7 entrées dans la table horaire ! Mais je suppose que c'est le seul moyen d'enregistrer les horaires par jour ? (Bon après, je parie que les crèches sont ouvertes tous les jours avec le même horaire mais on ne sait jamais.)

Finalement, j'ai suivi votre conseil pour les moyens de contact.

[escartefigue]

Bonjour,

Votre modèle est encore a priori trop compliqué, mais comme vous n'avez pas rédigé toutes les règles de gestion ce n'est pas facile de commenter.

J'ai fait quelques hypothèses qui me conduisent à un modèle comme suit :

Pièce jointe 223882

[PolkovnikMedved]

Merci pour votre réponse,

Bonjour,

Votre modèle est encore a priori trop compliqué, mais comme vous n'avez pas rédigé toutes les règles de gestion ce n'est pas facile de commenter.

Pour le moment, mon seul souci est de fournir une plate-forme sur laquelle une personne peut s'inscrire en introduisant ses données personnelles, définir si elle est gérante d'une crèche, travaille dans une crèche ou est un parent qui veut inscrire son enfant à une crèche déjà existante. L'enfant va alors avoir un dossier à la crèche avec des documents que les parents doivent remplir surtout par rapport à la santé de l'enfant. Un utilisateur inscrit peut bien entendu être gérant d'une crèche et parent d'un ou plusieurs enfants ou bien puéricultrice et parent d'un ou plusieurs enfants.

Merci pour votre schéma, mais vous n'avez pas parlé des questions qui me posent problème...

1) Dois-je faire les liens : Adresse -- Cabinet médical, Adresse -- Crèche ? (On ne doit pas gérer plusieurs adresses cette fois-ci, contrairement à l'utilisateur).
2) Dois-je faire les liens : Cabinet médical -- media -- type média, Crèche -- media -- type media ? (Encore une fois, on pourrait mettre le numéro de téléphone fixe et c'est tout).

Rem.: pour ces deux points je pourrais les insérer directement dans l'entité ?

3) Pourquoi avez-vous enlevé la notion d'héritage ? Le personnel de la crèche est un utilisateur du système tout comme le parent. L'enfant sera dans la même table que le parent (que je vais renommer en "membre_de_famille" quand on transforme ça en relationnel.

[escartefigue]

1) Dois-je faire les liens : Adresse -- Cabinet médical, Adresse -- Crèche ? (On ne doit pas gérer plusieurs adresses cette fois-ci, contrairement à l'utilisateur).

C'est la modélisation la plus riche, et qui peut le plus peut le moins, donc la réponse est plutôt oui.
Cela étant, si vous n'avez que faire des adresses des cabinet médicaux par exemple, à vous de choisir le modèle qui convient le mieux

2) Dois-je faire les liens : Cabinet médical -- media -- type média, Crèche -- media -- type media ? (Encore une fois, on pourrait mettre le numéro de téléphone fixe et c'est tout).

Même réponse que pour les adresses, tout dépend de vos besoins de gestion

Rem.: pour ces deux points je pourrais les insérer directement dans l'entité ?

A éviter car c'est la porte ouverte aux données nulles

3) Pourquoi avez-vous enlevé la notion d'héritage ? Le personnel de la crèche est un utilisateur du système tout comme le parent. L'enfant sera dans la même table que le parent (que je vais renommer en "membre_de_famille" quand on transforme ça en relationnel.

J'ai ignoré une partie de votre modèle (le personnel de la crèche, les documents administratifs...) pour zoomer sur les points qui me semblaient les plus à revoir
Vous pouvez bien sur rétablir cette entité-type "user" au dessus de parents et enfants de mon modèle, ce n'est pas gênant.

[SQLpro]

Les relations Parents et Enfants sont stupides. Il faut une seule relation Personne et de multiples liens internes.

Sinon vous violez la règle de nom redondance (les informations nom et prénom sont présentes plus d'une fois dans le modèle

A +

[PolkovnikMedved]

Les relations Parents et Enfants sont stupides. Il faut une seule relation Personne et de multiples liens internes.

Sinon vous violez la règle de nom redondance (les informations nom et prénom sont présentes plus d'une fois dans le modèle

A +

C'est justement pour éviter les redondances que j'ai mis l'entité "user" comme super-entité et ensuite les autres entités héritent de celle-la.
Je comprends pas pourquoi LES relations (alors que j'ai UNE relation "relashionship" avec un attribut role) dont stupides. Moi j'ai fini par remplacer l'entité "parent" par une entité "responsable" pour qu'elle gère les parents, les frères et soeurs et les personnes de contact éventuelles. Je vois pas ou sont les redondances la dedans...

[escartefigue]

Oui, et vous avez bien fait, encore une fois je n'ai modélisé qu'un extrait de votre MCD, la partie qui était la plus critique, et je n'ai mis des attributs qu'à titre d'exemple.
Si vous reprenez le principe de l'héritage, l'objection de SQLPro tombe (il n'a visiblement pas lu tous les échanges)

Il ne faut pas prendre ombrage des remarques acerbes de SQLpro, la diplomatie n'étant pas sa qualité première

[SQLpro]

C'est justement pour éviter les redondances que j'ai mis l'entité "user" comme super-entité et ensuite les autres entités héritent de celle-la.

Sémantiquement un "User" n'a rien à voir avec une personne.
Vous devez donc avoir une entité personne, une entité User héritée de Personne, et au moins une association réflexive de Personne à Personne permettant d'identifier parents d'un côté, et enfants de l'autre, sachant que vous pouvez voir revenir avant 20 ans des enfants en tant que parent pour mettre leurs propres enfants dans votre créche... Le lien étant souvent double entre parents et enfants, du fait que la plupart du temps un enfant à un père et une mère. Autrement dit les associations doivent êtres "sexuées"...

A +

[escartefigue]

Pas seulement sexuée, mais typée : il peut arriver que le représentant soit un tuteur, un grand-parent ou tout autre individu ayant autorité, et n'oublions pas les familles homoparentales.

[SQLpro]

Il ne faut pas prendre ombrage des remarques acerbes de SQLpro, la diplomatie n'étant pas sa qualité première

Non, mais ou t'as vu que j'étais diplomate bordel !!!!!!

[SQLpro]

.... n'oublions pas les familles homoparentales.

T'inquiète, ça va changer avec La mère le Pen ou Jean Marie Poison... Donc il faut faire du prospectif en devançant la politique de notre future président(e).

PS : avez-vous vu la faute de petite frappe intentionnelle ?

[escartefigue]

T'inquiète, ça va changer avec La mère le Pen ou Jean Marie Poison... Donc il faut faire du prospectif en devançant la politique de notre future président(e).

PS : avez-vous vu la faute de petite frappe intentionnelle ?

Et même 2 : Poison, bien vu et Jean-Marie ce qui n'est pas vraiment faux

[PolkovnikMedved]

Bon, une semaine pour faire un foutu schéma ça fait long !
Je me suis donc divisé la tache.

Tout d'abord, voici ce qu'on attend de moi en termes de fonctionnalités (incomplet, mais posez-moi des questions si jamais il le faut... ) :

On a une personne qui s'inscrit sur une plate-forme, elle introduit ses données personnelles et devient "USER".
Ensuite cette personne accède à un écran qui lui permet de choisir:
A) Si elle est responsable d'une crèche.
B) Si elle travaille dans une crèche.
C) Si elle veut inscrire des enfants à une crèche.

Dans le cas:
A) La personne introduit toutes les données par rapport à la crèche et attend la validation de l'admin.
B) La personne introduit ses données personnelles, choisit sa crèche et attend la validation du gérant de la crèche.
C) La personne introduit toutes les données par rapport à chaque enfant.
Elle constitue donc un dossier d'inscription valable uniquement au sein d'une certaine crèche.
Ce dossier est composé de certains documents (par facilité, il y a 3 documents + photo).
Elle constitue le dossier médical de l'enfant avec ses habitudes allergies etc.
Ce dossier est propre à l'enfant et la crèche a un droit de voir les informations pas de les modifier.
Elle introduit les informations relatives aux parents mais aussi aux contacts de l'enfant.
(Ex: une personne peut être parent d'un enfant mais n'est pas contact pour l'enfant pour une crèche donnée).


Alors j'ai procédé par étapes, en tenant compte de toutes vos remarques et j'ai divisé le problème.
Première partie : l'essentiel. On a un enfant avec son dossier médical qui est inscrit à une crèche.
Il a donc un dossier d'inscription. La crèche a des informations personnelles, un horaire et du personnel.



Deuxième partie : On traite l'objection de SQLPro. Effectivement, une fois qu'une personne s'inscrit sur le site
elle devient "USER" ensuite lorsqu'elle définit si elle est "Parent" ou "personnel d'une crèche" elle devient
ce qu'elle à défini. Ainsi, on a une entité "user" qui fait évite les redondances.
Ensuite on s'attaque à la problématique de la gestion enfants/parents/frères/sœurs etc.
J'ai fait une relation réflexive entre l'entité "Personne" et elle-même avec un rôle. Le rôle sera un domaine
de valeurs ou on pourra choisir si on est "père,mère,frère etc" et la relation possède l'identifiant de la source
et du destinataire. Par la présente, on vire l'entité enfant.



Schéma intermédiaire : On ajoute les deux schémas ensemble. On arrive sur une nouvelle problématique celle des personnes
de contact qui doivent être des "personnes" et qui ont une certaine priorité.


Voila, donc il faut que j'ajoute les entités adresse et de contact (Media--typeMedia) et le bureau du médecin.

A vos marques, prêts, commentez !

[escartefigue]

Tout d'abord, voici ce qu'on attend de moi en termes de fonctionnalités (incomplet, mais posez-moi des questions si jamais il le faut... ) :

On a une personne qui s'inscrit sur une plate-forme, elle introduit ses données personnelles et devient "USER".
Ensuite cette personne accède à un écran qui lui permet de choisir:
A) Si elle est responsable d'une crèche.
B) Si elle travaille dans une crèche.
C) Si elle veut inscrire des enfants à une crèche.

Je suppose qu'une personne qui travaille dans une crèche peut aussi inscrire ses propres enfants dans cette crèche ?

Sur ce nouveau modèle, je ne suis pas sur de comprendre ce que vous avez voulu représenter avec la relation "contact" entre "Person" et "Nursery", mais une association, au niveau conceptuel donc, ne saurait comporter des identifiants, sans compter que les id mentionnés ne sont dans aucune des entités-type en relation

Il me semble que le contact, il peut y en avoir plusieurs avec des priorités, est un attribut de la relation entre un enfant et son ou ses représentants.
Il faut donc ajouter dans la relation "Relationship" un attribut "priorité" par exemple (sans accent dans les noms de colonne de préférence )