📦 Architecture de la base de données EasyGroup

Cette base de données est conçue pour répondre aux besoins de l’application EasyGroup, dont l’objectif est de permettre la création intelligente de groupes d’apprenants à partir de listes partagées, tout en tenant compte de critères variés (âge, expérience, profils, etc.).

---

🧱 Structure générale

L’architecture repose sur 7 tables relationnelles, cohérentes et normalisées :

• user
• list
• list_share
• person
• draw
• group
• group_person

---

📋 Détail des tables

1. user – Utilisateurs

Représente les comptes créés sur la plateforme.

Champ	Type	Contraintes
id	int	PK, auto-incrémenté
email	varchar(255)	NOT NULL, UNIQUE
first_name	varchar(255)	-
last_name	varchar(255)	-
password	varchar(255)	NOT NULL
cgu_date	date	Date d’acceptation des CGU
is_activated	boolean	NOT NULL
created_at	datetime(6)	NOT NULL, défaut: now()
updated_at	datetime(6)	NOT NULL, défaut: now()
role	enum('USER','ADMIN')	NOT NULL, défaut: 'USER'

---

2. list – Listes de personnes

Chaque utilisateur peut créer plusieurs listes, partageables avec d’autres utilisateurs.

Champ	Type	Contraintes
id	int	PK, auto-incrémenté
name	varchar(255)	NOT NULL
user_id	int	FK vers user.id, NOT NULL
is_shared	boolean	NOT NULL, défaut: false

🔐 Contrainte : (name, user_id) doit être unique (nom de liste unique par utilisateur).

---

3. list_share – Partage de listes

Permet à un utilisateur de voir une liste créée par un autre.

Champ	Type	Contraintes
id	int	PK, auto-incrémenté
list_id	int	FK vers list.id, NOT NULL
shared_with_user_id	int	FK vers user.id, NOT NULL

🔐 Contrainte : (list_id, shared_with_user_id) est unique (un même utilisateur ne peut pas recevoir plusieurs fois la même liste).

---

4. person – Personnes d'une liste

Stocke les caractéristiques de chaque personne d'une liste.

Champ	Type	Contraintes
id	int	PK, auto-incrémenté
name	varchar(50)	NOT NULL, longueur 3–50
gender	enum('FEMALE','MALE','OTHER')	NOT NULL
age	int	NOT NULL, entre 1 et 99
french_level	int	NOT NULL, de 1 à 4
old_dwwm	boolean	NOT NULL
tech_level	int	NOT NULL, de 1 à 4
profile	enum('A_LAISE','RESERVE','TIMIDE')	NOT NULL
list_id	int	FK vers list.id, NOT NULL

---

5. draw – Tirages

Un tirage correspond à la création de groupes aléatoires à partir d'une liste.

Champ	Type	Contraintes
id	int	PK, auto-incrémenté
created_at	datetime(6)	Timestamp optionnel
list_id	int	FK vers list.id, NOT NULL
title	varchar(255)	Titre personnalisé

---

6. group – Groupes

Groupes générés à partir d’un draw.

Champ	Type	Contraintes
id	int	PK, auto-incrémenté
name	varchar(255)	Nom du groupe
draw_id	int	FK vers draw.id, NOT NULL

---

7. group_person – Association groupe/personne

Table de jointure entre les personnes et les groupes auxquels elles appartiennent.

Champ	Type	Contraintes
group_id	int	FK vers group.id, NOT NULL
person_id	int	FK vers person.id, NOT NULL

---

🔗 Relations clés

• Un user possède plusieurs list
• Une list contient plusieurs person et peut être partagée (via list_share)
• Une list peut avoir plusieurs draw
• Un draw génère plusieurs group
• Un group contient plusieurs person (via group_person)

---

🛡️ Contraintes d’intégrité

• Clés primaires (id) sur toutes les entités.
• Contraintes NOT NULL pour garantir la complétude des données essentielles.
• Contraintes de type ENUM pour des champs à choix restreints.
• Index et clés uniques (UNIQUE) pour éviter les doublons de listes.

---

🗃️ Bonnes pratiques respectées

• Nommage explicite des tables et colonnes
• Suppression des colonnes calculables (count) en faveur de méthodes backend
• Typage fort (enum, boolean, datetime)
• Relations bien définies via clés étrangères
• Prise en compte du partage et de l’historique

---

🧪 Évolutivité

Le schéma est conçu pour :

• Être dockerisable avec MySQL/PostgreSQL
• Intégrer une séparation entre utilisateurs et groupes via les draw
• Permettre un TDD facile (schéma stable et modulaire)
• S'adapter à des futurs modules : filtres intelligents, versions de tirage, statistiques…

---

📎 Notes

• Pour éviter les regroupements identiques, l’algorithme de tirage peut se baser sur un historique calculé en back à partir des group_person associés à chaque draw.
• La base n’inclut volontairement aucune donnée sensible inutile : RGPD-friendly.

---

Exemple de requête SQL JOIN:

SELECT g.name AS group_name, p.name AS person_name FROM group g JOIN group_person gp ON g.id = gp.group_id JOIN person p ON p.id = gp.person_id WHERE g.draw_id = :drawId;

Format de réponse:

[ { "group_name": "Groupe 1", "person_name": "Alice", ... }, { "group_name": "Groupe 1", "person_name": "Bob", ... }, { "group_name": "Groupe 2", "person_name": "Claire", ... } ]

documentation BDD.md