# FK\_POLICIES.md — Politiques de clés étrangères

Ce document recense l’ensemble des **relations entre tables** dans la base **P’titsPas**, 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 d’un 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 l’enfant disparaît.
* **FK** : `id_enfant → enfants.id`

  * **ON DELETE CASCADE** → si l’enfant 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 l’enfant 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 l’utilisateur.

---

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

---