643 lines
11 KiB
Markdown
643 lines
11 KiB
Markdown
# Ticket #023
|
|
|
|
## Titre
|
|
|
|
Consolider le schéma métier initial de l'enquête.
|
|
|
|
---
|
|
|
|
## Objectif
|
|
|
|
Transformer le schéma SQLite préparé lors des premières phases du projet en
|
|
un schéma métier officiel, cohérent, documenté et testable.
|
|
|
|
La base existante sert de fondation.
|
|
|
|
Le travail ne consiste pas à repartir de zéro, mais à :
|
|
|
|
- conserver les concepts métier déjà définis ;
|
|
- corriger les incohérences ;
|
|
- renforcer les contraintes ;
|
|
- uniformiser les conventions ;
|
|
- intégrer le schéma au module `Database`.
|
|
|
|
---
|
|
|
|
## Base de travail
|
|
|
|
La base historique contient notamment les tables suivantes :
|
|
|
|
```text
|
|
preuves
|
|
entites
|
|
personnes
|
|
chronologie
|
|
sources
|
|
recherche
|
|
hypotheses
|
|
journal
|
|
tags
|
|
types_preuve
|
|
types_entite
|
|
types_source
|
|
types_outils
|
|
associations
|
|
personnes_entites
|
|
entite_tags
|
|
preuves_tag
|
|
```
|
|
|
|
Les tables créées au ticket #022 restent également obligatoires :
|
|
|
|
```text
|
|
metadata
|
|
investigation
|
|
```
|
|
|
|
Le schéma officiel doit donc préserver ces concepts tout en les consolidant.
|
|
|
|
---
|
|
|
|
## Architecture
|
|
|
|
```text
|
|
InvestigationProject
|
|
│
|
|
▼
|
|
Database
|
|
│
|
|
▼
|
|
Schéma SQLite versionné
|
|
│
|
|
├── Métadonnées
|
|
├── Enquête
|
|
├── Preuves
|
|
├── Entités
|
|
├── Personnes
|
|
├── Sources
|
|
├── Chronologie
|
|
├── Recherches
|
|
├── Hypothèses
|
|
├── Journal
|
|
└── Tags et relations
|
|
```
|
|
|
|
Le module `Database` reste le seul autorisé à exécuter du SQL.
|
|
|
|
---
|
|
|
|
## Décisions de conception à officialiser
|
|
|
|
### Identifiants
|
|
|
|
Les entités métier utiliseront des identifiants texte de type UUID.
|
|
|
|
Exemple :
|
|
|
|
```text
|
|
550e8400-e29b-41d4-a716-446655440000
|
|
```
|
|
|
|
Les identifiants sont générés par l'application avec :
|
|
|
|
```c
|
|
g_uuid_string_random()
|
|
```
|
|
|
|
Les tables de référence simples peuvent utiliser des identifiants entiers.
|
|
|
|
---
|
|
|
|
### Dates
|
|
|
|
Les dates techniques sont stockées en UTC au format ISO 8601 :
|
|
|
|
```text
|
|
YYYY-MM-DDTHH:MM:SSZ
|
|
```
|
|
|
|
Exemple :
|
|
|
|
```text
|
|
2026-07-15T08:42:17Z
|
|
```
|
|
|
|
---
|
|
|
|
### Nommage
|
|
|
|
Les noms SQL utilisent uniquement :
|
|
|
|
- des minuscules ;
|
|
- du `snake_case` ;
|
|
- aucun accent ;
|
|
- aucun espace.
|
|
|
|
Les noms des tables de liaison sont uniformisés.
|
|
|
|
Exemple :
|
|
|
|
```text
|
|
preuve_tags
|
|
entite_tags
|
|
personne_entites
|
|
```
|
|
|
|
Aucune forme singulier/pluriel incohérente ne doit subsister.
|
|
|
|
---
|
|
|
|
### Clés étrangères
|
|
|
|
Toutes les relations métier doivent utiliser des clés étrangères explicites.
|
|
|
|
Le module `Database` doit activer :
|
|
|
|
```sql
|
|
PRAGMA foreign_keys = ON;
|
|
```
|
|
|
|
à chaque ouverture de connexion.
|
|
|
|
Les comportements `ON DELETE` doivent être décidés pour chaque relation.
|
|
|
|
---
|
|
|
|
### Tables de liaison
|
|
|
|
Chaque table de liaison doit empêcher les doublons grâce à :
|
|
|
|
- une clé primaire composite ;
|
|
- ou une contrainte `UNIQUE`.
|
|
|
|
Exemple :
|
|
|
|
```sql
|
|
PRIMARY KEY (preuve_id, tag_id)
|
|
```
|
|
|
|
---
|
|
|
|
## Tables métier à consolider
|
|
|
|
### `preuves`
|
|
|
|
Responsabilité :
|
|
|
|
- représenter un élément de preuve ;
|
|
- mémoriser son nom ;
|
|
- son chemin relatif ;
|
|
- son type ;
|
|
- sa description ;
|
|
- ses dates ;
|
|
- son hash éventuel ;
|
|
- son statut.
|
|
|
|
Contraintes minimales :
|
|
|
|
- identifiant obligatoire ;
|
|
- nom obligatoire ;
|
|
- chemin relatif obligatoire ;
|
|
- type obligatoire ;
|
|
- date de création obligatoire ;
|
|
- chemin unique au sein d'une enquête.
|
|
|
|
---
|
|
|
|
### `entites`
|
|
|
|
Responsabilité :
|
|
|
|
- représenter une entité identifiée pendant l'enquête.
|
|
|
|
Exemples :
|
|
|
|
- adresse email ;
|
|
- compte bancaire ;
|
|
- profil social ;
|
|
- pseudonyme ;
|
|
- téléphone ;
|
|
- document d'identité.
|
|
|
|
Contraintes minimales :
|
|
|
|
- identifiant obligatoire ;
|
|
- type obligatoire ;
|
|
- valeur obligatoire ;
|
|
- date de création obligatoire.
|
|
|
|
---
|
|
|
|
### `personnes`
|
|
|
|
Responsabilité :
|
|
|
|
- représenter une personne physique ou un profil humain étudié.
|
|
|
|
Le modèle ne doit pas obliger à connaître l'identité civile complète.
|
|
|
|
Une personne peut n'avoir qu'un pseudonyme ou une désignation temporaire.
|
|
|
|
---
|
|
|
|
### `sources`
|
|
|
|
Responsabilité :
|
|
|
|
- représenter l'origine d'une information ou d'une preuve.
|
|
|
|
Exemples :
|
|
|
|
- site web ;
|
|
- email ;
|
|
- réseau social ;
|
|
- document ;
|
|
- témoignage ;
|
|
- outil OSINT.
|
|
|
|
---
|
|
|
|
### `chronologie`
|
|
|
|
Responsabilité :
|
|
|
|
- mémoriser les événements importants de l'enquête ;
|
|
- relier éventuellement un événement à une preuve, une entité ou une source.
|
|
|
|
---
|
|
|
|
### `recherches`
|
|
|
|
Responsabilité :
|
|
|
|
- documenter une opération de recherche ;
|
|
- mémoriser la requête ;
|
|
- l'outil employé ;
|
|
- la date ;
|
|
- le résultat ;
|
|
- les observations.
|
|
|
|
---
|
|
|
|
### `hypotheses`
|
|
|
|
Responsabilité :
|
|
|
|
- enregistrer une hypothèse de travail ;
|
|
- mémoriser son statut ;
|
|
- sa justification ;
|
|
- les éléments qui la soutiennent ou la contredisent.
|
|
|
|
---
|
|
|
|
### `journal`
|
|
|
|
Responsabilité :
|
|
|
|
- conserver la trace des actions significatives réalisées dans l'enquête.
|
|
|
|
Exemples :
|
|
|
|
- création d'une preuve ;
|
|
- modification d'une entité ;
|
|
- calcul d'un hash ;
|
|
- génération d'un rapport ;
|
|
- import d'un fichier.
|
|
|
|
---
|
|
|
|
### `tags`
|
|
|
|
Responsabilité :
|
|
|
|
- permettre une classification libre des preuves et des entités.
|
|
|
|
---
|
|
|
|
## Tables de référence
|
|
|
|
Les tables suivantes doivent être consolidées :
|
|
|
|
```text
|
|
types_preuve
|
|
types_entite
|
|
types_source
|
|
types_outils
|
|
```
|
|
|
|
Elles doivent comporter au minimum :
|
|
|
|
```sql
|
|
id INTEGER PRIMARY KEY
|
|
code TEXT NOT NULL UNIQUE
|
|
label TEXT NOT NULL
|
|
description TEXT
|
|
```
|
|
|
|
Les valeurs initiales sont insérées lors de la création de la base.
|
|
|
|
---
|
|
|
|
## Tables de liaison
|
|
|
|
Les relations suivantes doivent être prévues :
|
|
|
|
```text
|
|
preuve_tags
|
|
entite_tags
|
|
personne_entites
|
|
```
|
|
|
|
Le schéma existant contient également une table générique :
|
|
|
|
```text
|
|
associations
|
|
```
|
|
|
|
Cette table doit être auditée avant conservation.
|
|
|
|
Elle ne doit être gardée que si son rôle est clairement défini et ne fait pas
|
|
doublon avec des relations spécialisées.
|
|
|
|
---
|
|
|
|
## Audit obligatoire
|
|
|
|
Avant d'écrire le schéma définitif, chaque table de la base historique doit
|
|
être classée dans l'une des catégories suivantes :
|
|
|
|
```text
|
|
CONSERVER
|
|
MODIFIER
|
|
RENOMMER
|
|
FUSIONNER
|
|
SUPPRIMER
|
|
```
|
|
|
|
La décision doit être documentée dans :
|
|
|
|
```text
|
|
docs/database/SCHEMA_AUDIT_V1.md
|
|
```
|
|
|
|
Le document doit contenir au minimum :
|
|
|
|
```text
|
|
Nom historique
|
|
Décision
|
|
Nom final
|
|
Justification
|
|
Modifications prévues
|
|
```
|
|
|
|
---
|
|
|
|
## Organisation du module Database
|
|
|
|
Le code SQL est organisé par domaine métier.
|
|
|
|
```
|
|
include/
|
|
└── database/
|
|
├── database.h
|
|
├── schema.h
|
|
├── preuve.h
|
|
├── entite.h
|
|
├── personne.h
|
|
├── source.h
|
|
├── chronologie.h
|
|
├── recherche.h
|
|
├── hypothese.h
|
|
├── journal.h
|
|
├── tag.h
|
|
├── type_preuve.h
|
|
├── type_entite.h
|
|
├── type_source.h
|
|
└── type_outil.h
|
|
|
|
src/
|
|
└── database/
|
|
├── database.c
|
|
├── schema.c
|
|
├── preuve.c
|
|
├── entite.c
|
|
├── personne.c
|
|
├── source.c
|
|
├── chronologie.c
|
|
├── recherche.c
|
|
├── hypothese.c
|
|
├── journal.c
|
|
├── tag.c
|
|
├── type_preuve.c
|
|
├── type_entite.c
|
|
├── type_source.c
|
|
└── type_outil.c
|
|
|
|
database/
|
|
├── schema_v1.sql
|
|
├── indexes.sql
|
|
├── triggers.sql
|
|
└── reference_data.sql
|
|
```
|
|
|
|
---
|
|
|
|
### Responsabilités
|
|
|
|
`database.c`
|
|
|
|
- ouverture de SQLite ;
|
|
- fermeture ;
|
|
- transactions ;
|
|
- erreurs ;
|
|
- point d'entrée du module Database.
|
|
|
|
`schema.c`
|
|
|
|
- installation du schéma ;
|
|
- migrations ;
|
|
- exécution des scripts SQL.
|
|
|
|
Chaque module métier est responsable exclusivement de son objet métier.
|
|
|
|
Exemple :
|
|
|
|
```
|
|
preuve.c
|
|
```
|
|
|
|
gère uniquement :
|
|
|
|
- création ;
|
|
- lecture ;
|
|
- modification ;
|
|
- suppression logique ;
|
|
- gestion des tags de la preuve.
|
|
|
|
Les tables de liaison simples ne possèdent pas de module dédié.
|
|
|
|
Exemples :
|
|
|
|
```
|
|
preuve_tags
|
|
personne_entites
|
|
entite_tags
|
|
```
|
|
|
|
Leur manipulation est réalisée par le module métier correspondant.
|
|
|
|
---
|
|
|
|
## Intégration dans `Database`
|
|
|
|
Le module `database_initialize()` doit exécuter le schéma officiel contenu
|
|
dans :
|
|
|
|
```text
|
|
database/schema_v1.sql
|
|
```
|
|
|
|
Deux approches sont acceptables :
|
|
|
|
1. intégrer le schéma au binaire via une ressource GLib ;
|
|
2. générer une chaîne C depuis le fichier SQL lors de la compilation.
|
|
|
|
Le logiciel installé ne doit pas dépendre d'un chemin relatif fragile vers le
|
|
dépôt source.
|
|
|
|
---
|
|
|
|
## Principe d'organisation
|
|
|
|
Une table métier importante implique systématiquement :
|
|
|
|
- une structure C ;
|
|
- un module C ;
|
|
- des tests ;
|
|
- une documentation.
|
|
|
|
La correspondance est la suivante :
|
|
|
|
| SQL | C |
|
|
|-----|---|
|
|
| preuves | preuve.c |
|
|
| entites | entite.c |
|
|
| personnes | personne.c |
|
|
| sources | source.c |
|
|
| chronologie | chronologie.c |
|
|
| journal | journal.c |
|
|
| recherches | recherche.c |
|
|
| hypotheses | hypothese.c |
|
|
|
|
---
|
|
|
|
## Version du schéma
|
|
|
|
Le numéro de version reste :
|
|
|
|
```text
|
|
1
|
|
```
|
|
|
|
tant que Labfy Investigation n'a pas produit de base officiellement publiée.
|
|
|
|
Une fois le schéma V1 considéré comme stable et distribué, toute modification
|
|
incompatible nécessitera :
|
|
|
|
- une nouvelle version ;
|
|
- une migration dédiée ;
|
|
- une mise à jour de `schema_version`.
|
|
|
|
---
|
|
|
|
## Hors périmètre
|
|
|
|
Ce ticket ne doit pas :
|
|
|
|
- développer les fonctions CRUD ;
|
|
- créer les structures C `Preuve`, `Entite` ou `Personne` ;
|
|
- connecter les tables à GTK ;
|
|
- importer les anciennes données automatiquement ;
|
|
- créer les migrations V2 ;
|
|
- produire un rapport ;
|
|
- ajouter la recherche plein texte.
|
|
|
|
---
|
|
|
|
## Contraintes techniques
|
|
|
|
- C17 ;
|
|
- SQLite3 ;
|
|
- GLib ;
|
|
- aucune dépendance GTK ;
|
|
- toutes les tables utilisent des contraintes explicites ;
|
|
- toutes les clés étrangères sont documentées ;
|
|
- toutes les tables de liaison empêchent les doublons ;
|
|
- aucun SQL métier hors du module `Database` ;
|
|
- aucun identifiant généré par SQLite pour les objets métier en UUID ;
|
|
- compilation sans warning.
|
|
|
|
---
|
|
|
|
## Tests
|
|
|
|
Faire évoluer :
|
|
|
|
```text
|
|
tests/test_database.c
|
|
```
|
|
|
|
Les tests doivent vérifier :
|
|
|
|
- la présence de toutes les tables officielles ;
|
|
- la présence des tables de référence ;
|
|
- l'insertion des valeurs initiales ;
|
|
- l'activation des clés étrangères ;
|
|
- le refus d'une clé étrangère invalide ;
|
|
- le refus d'un doublon dans une table de liaison ;
|
|
- le refus des colonnes obligatoires manquantes ;
|
|
- l'unicité des codes des tables de référence ;
|
|
- la valeur `schema_version = 1` ;
|
|
- l'intégrité SQLite avec :
|
|
|
|
```sql
|
|
PRAGMA integrity_check;
|
|
```
|
|
|
|
---
|
|
|
|
## Critères d'acceptation
|
|
|
|
- [ ] Le schéma historique a été audité.
|
|
- [ ] Chaque table possède une décision documentée.
|
|
- [ ] Un schéma V1 officiel existe.
|
|
- [ ] Les conventions de nommage sont uniformes.
|
|
- [ ] Toutes les clés primaires sont explicites.
|
|
- [ ] Toutes les clés étrangères sont explicites.
|
|
- [ ] Les relations empêchent les doublons.
|
|
- [ ] Les colonnes obligatoires utilisent `NOT NULL`.
|
|
- [ ] Les tables de référence sont initialisées.
|
|
- [ ] `database_initialize()` installe le schéma complet.
|
|
- [ ] `PRAGMA integrity_check` retourne `ok`.
|
|
- [ ] Tous les tests restent valides.
|
|
- [ ] Aucune dépendance GTK.
|
|
|
|
---
|
|
|
|
## Livrables
|
|
|
|
```text
|
|
docs/database/SCHEMA_AUDIT_V1.md
|
|
database/schema_v1.sql
|
|
include/database/database.h
|
|
src/database/database.c
|
|
tests/test_database.c
|
|
```
|
|
|
|
---
|
|
|
|
## Commit attendu
|
|
|
|
```text
|
|
feat(database): consolidate initial investigation schema
|
|
```
|