ptitspas-ynov-bdd/docs/FK_POLICIES.md

4.0 KiB
Raw Blame History

FK_POLICIES.md — Politiques de clés étrangères

Ce document recense lensemble des relations entre tables dans la base PtitsPas, avec leurs règles de suppression et les implications fonctionnelles.

Objectif : assurer la cohérence entre la DB, le backend et le fonctionnel métier. Toute nouvelle relation ou modification doit être ajoutée ici avant migration DB.


Conventions générales

  • Les FK sont définies en REFERENCES ....
  • Sauf précision, ON UPDATE est implicite = NO ACTION.
  • Les comportements documentés sont côté PostgreSQL.

1) Table assistantes_maternelles

  • FK : id_utilisateur → utilisateurs.id
  • ON DELETE CASCADE
  • 🔎 Si un utilisateur AM est supprimé, son profil AM est supprimé automatiquement.

2) Table parents

  • FK : id_utilisateur → utilisateurs.id

    • ON DELETE CASCADE → suppression dun parent entraîne suppression automatique du parent.
  • FK : id_co_parent → utilisateurs.id

    • ON DELETE NO ACTION (par défaut) → suppression du co-parent interdite si référence active.

3) Table enfants_parents

  • FK : id_parent → parents.id_utilisateur

    • ON DELETE CASCADE → si le parent est supprimé, le lien avec lenfant disparaît.
  • FK : id_enfant → enfants.id

    • ON DELETE CASCADE → si lenfant est supprimé, toutes ses associations avec des parents disparaissent.

4) Table dossiers

  • FK : id_parent → parents.id_utilisateur

    • ON DELETE CASCADE → si le parent est supprimé, ses dossiers disparaissent.
  • FK : id_enfant → enfants.id

    • ON DELETE CASCADE → si lenfant est supprimé, les dossiers liés disparaissent.

5) Table messages

  • FK : id_dossier → dossiers.id

    • ON DELETE CASCADE → si un dossier est supprimé, les messages disparaissent.
  • FK : id_expediteur → utilisateurs.id

    • ON DELETE CASCADE → si un utilisateur est supprimé, ses messages disparaissent.

6) Table contrats

  • FK : id_dossier → dossiers.id

    • UNIQUE + ON DELETE CASCADE → si un dossier est supprimé, le contrat disparaît.

7) Table avenants_contrats

  • FK : id_contrat → contrats.id

    • ON DELETE CASCADE → si un contrat est supprimé, ses avenants disparaissent.
  • FK : initie_par → utilisateurs.id

    • ON DELETE NO ACTION → suppression interdite tant que des avenants existent.

8) Table evenements

  • FK : id_enfant → enfants.id

    • ON DELETE CASCADE → si un enfant est supprimé, ses événements disparaissent.
  • FK : id_am → utilisateurs.id

    • ON DELETE NO ACTION → suppression interdite si des événements liés.
  • FK : id_parent → parents.id_utilisateur

    • ON DELETE NO ACTION → suppression interdite si des événements liés.
  • FK : cree_par → utilisateurs.id

    • ON DELETE NO ACTION → suppression interdite si référence encore utilisée.

9) Table signalements_bugs

  • FK : id_utilisateur → utilisateurs.id

    • ON DELETE NO ACTION → utilisateur non supprimable si bug référencé.

10) Table uploads

  • FK : id_utilisateur → utilisateurs.id

    • ON DELETE SET NULL → si un utilisateur est supprimé, ses fichiers restent, mais sans lien utilisateur.

11) Table notifications

  • FK : id_utilisateur → utilisateurs.id

    • ON DELETE CASCADE → si un utilisateur est supprimé, ses notifications disparaissent.

12) Table validations

  • FK : id_utilisateur → utilisateurs.id

    • ON DELETE NO ACTION → suppression interdite si validations liées.
  • FK : valide_par → utilisateurs.id

    • ON DELETE NO ACTION → suppression interdite si validations effectuées par lutilisateur.

📌 Mainteneur : Équipe BDD 📌 Dernière mise à jour : alignée sur init.sql (septembre 2025)