Modele de donnees
24 entites, reparties en quatre sous-domaines : catalogue, ingredients et stock, commande, controle d'acces. MariaDB 11.4, requetes preparees, encodage utf8mb4.
Le dictionnaire
docs/merise/dictionary.md — chaque entite, chaque attribut, son type, son caractere obligatoire, sa valeur par defaut et la regle qui le justifie. C'est le document de reference du modele.
docs/merise — les modeles conceptuels et les diagrammes, un par sous-domaine.
Du modele au schema reel
db/migrations
— 20 migrations (0001 a 0021, le numero 0004 est saute volontairement ; compte du 29/09), appliquees dans l'ordre et suivies par nom de fichier : rejouer
n'applique que les nouvelles.
db/seeds — 10 jeux de donnees de reference et de demonstration, suivis de la meme facon.
Une consequence a connaitre : modifier un jeu de donnees n'a aucun effet sur une
installation existante, puisque son nom est deja enregistre. Corriger une donnee
deja en place demande une migration. C'est pourquoi la migration 0016 existe :
elle pose les accents sur les libelles affiches d'une base deja installee, pendant
que les jeux de donnees les portent pour une installation neuve. Meme logique pour 0017
(familles d'ingredients) et 0018 (le responsable recoit la lecture et l'annulation des
commandes).
Ce que le modele protege
- Chaque relation du modele conceptuel devient une cle etrangere reelle, avec un comportement de suppression choisi, pas par defaut.
- Chaque ligne de commande fige le libelle, le prix et le taux de TVA appliques : une hausse de prix ne reecrit pas l'histoire.
- Le prix final est recalcule depuis la base a la creation de la commande ; celui que le client envoie ne sert pas.
- L'anonymisation au titre du RGPD conserve la ligne utilisateur et vide ses donnees personnelles, pour ne pas casser l'historique des commandes. Voir docs/adr/0007-rgpd-anonymisation-tombstone.md.
Controle d'acces
23 permissions figees au jeu de donnees, 5 roles par defaut (administrateur 23, responsable 15, cuisine 5, comptoir 8, drive 8). Le code verifie une permission, pas un nom de role : un role personnalise dote des bonnes permissions ouvre les memes fonctions sans changement de code.
docs/demo/matrice-rbac.md — qui peut quoi, et ce que chaque role se voit refuser.