Salut à tous,

Il y a quelques temps j'ai travaillé sur un projet qui m'a donné pas mal de fil à retordre dans la conception de la base de données.
Je suis finalement arrivé à faire ce que je voulais mais je pense que certaines choses ne vont pas et j'aimerais retravailler tout ça pour que ce soit le plus logique possible.

L'application permet en faite de créer des bulletins d'inscriptions à des voyages. J'ai beaucoup d'informations à traiter dans les formulaires d'inscription et surtout j'ai plusieurs type d'inscriptions possible qui ne contiennent pas tous les mêmes champs.

Aujourd'hui j'ai une base de données qui contient les différents champs possibles répartis dans différentes tables. Je ne sais pas si c'était le mieux mais quand je l'ai réalisé c'est ce que j'ai trouvé de plus simple.

Voici un schéma de la base actuelle

Je n'ai pas représenté la table "utilisateur" qui est une table classique et chaque inscription est lié à un utilisateur.

Pour le reste, j'ai une table "destination" contient toutes les destinations possible et pour chaque destination je peux avoir un ou plusieurs séjour qui contient des dates.

Ensuite j'ai ma fameuse table "inscription" qui contient pas mal d'informations et les tables "scolaire", "medical" et "voyage" qui lui sont rattachées et qui contiennent d'autres informations. Chaque inscription possède des informations sur la scolarité du participant, les informations médicales du participant et le voyage choisi avec diverses informations.

La table "participant" contient les informations du participant et chaque participant possède un ou plusieurs parent donc on a une table "parent" qui s'occupe de ça.

Qu'est-ce que je pourrais améliorer là dedans ?

J'ai déjà remarqué que dans ma table "voyage" j'avais des informations en doublon car aller et retour. Je pourrais peut-être faire un champ dans lequel je stock "A" ou "R" et je fais une entrée à chaque fois en précisant si c'est aller ou retour non ?

Désolé pour les champs moitié français, moitié anglais, j'étais pas très inspiré au moment de la conception

Merci d'avance

Bonjour,

Je ne sais pas quel est réellement le but recherché, mais voici quelques remarques, sans aucun ordre d'importance :

Je créerais une table personne pour regrouper participant et parent avec une table de relation réflexive pour formaliser les parents.

Les données médicales et scolaires seraient pour moi liées à la table personne vue précédemment.

Si une personne s'inscrit à plusieurs séjours on récupère son compte au lieu d'en recréer un à chaque fois, donc ses données médicales avec. Cela permet au passage de supprimer les colonnes inscription.deja_sejourne et inscription.ancien_sejour.

sejour.duree ? tu as la date de début et la date de fin, pourquoi stocker une durée ?

-
Edité par Benzouye 8 juillet 2021 à 15:38:41

Bonjour,

Merci pour ta réponse.

Le principal but recherché c'est d'améliorer un peu l'organisation, j'ai l'impression que certaines tables ne sont pas logiques.

C'est noté pour la table personne, par contre la table parent ça veut dire qu'elle possède 2 clefs étrangères mais à chaque fois seulement une sera renseignée si j'ai bien compris c'est ça ?

J'avais pensé à l'origine à récupérer les données pour chaque inscription plutôt que recréer à chaque fois des doublons mais la personne à l'origine de l'application préférait dupliquer les données. Mais dans cette seconde version je vais voir pour mettre en place cette logique.

Par contre, avec cette logique, au niveau scolaire par exemple si un participant revient l'année suivante, ses informations scolaires vont sans doute changer, ce qui veut dire que dans les précédentes inscriptions ça va changer aussi non ?

Aucune idée pourquoi j'ai stocké la durée, c'est vrai que je peux la calculer à partir de la date de début et de fin.

Merci pour ses premières remarques, ça m'aide à avancer

brizy a écrit:

la table parent ça veut dire qu'elle possède 2 clefs étrangères mais à chaque fois seulement une sera renseignée si j'ai bien compris c'est ça ?

Non, c'est une table de relation n,n qui relie un enfant à son parent. Tu as en effet deux id clés étrangères (dans ce cas vers la même table personne) et une clé primaire composée sur ces deux colonnes, l'une identifie l'enfant, l'autre identifie le parent. Cela permet d'avoir un enfant et plusieurs parents. On peut même imaginer de rajouter un attribut "rôle" dans cette table qui préciserai quel rôle a le parent (père, mère, sœur, tante, etc.).

brizy a écrit:

la personne à l'origine de l'application préférait dupliquer les données

C'est bizarre ... Tu pourrais proposer une solution "sexy" où l'utilisateur saisi simplement le nom, le prénom et la date de naissance, et le système propose de remplir automatiquement le formulaire si un enregistrement existe déjà avec des données ... C'est quand même bien plus rigoureux pour le suivi à long terme. Après, cela ne vaut le cas que si le cas est assez récurrent ...

brizy a écrit:

si un participant revient l'année suivante, ses informations scolaires vont sans doute changer, ce qui veut dire que dans les précédentes inscriptions ça va changer aussi non ?

Oui ... pas glop en effet si tu veux garder l'historique ... mais vu la remarque précédente sur la resaisie, cela n'a pas l'air très important

Sinon, oui, il faut garder ces données liées à l'inscription ...

D'accord je comprends le système de la table parent, merci pour les explications.

Oui j'aurais aimé aussi que tout soit rempli automatiquement avec les données du participant, après c'est vrai que ça doit arriver au minimum une fois par an je pense, pas plus donc ça vaut peut-être pas le coup effectivement.

Je vais réfléchir et essayer de voir ce qui est le mieux de ce côté là.

Encore merci pour toutes les explications