fy59/labfy-investigation

Fork 0

Consolider le schéma métier initial de l'enquête. #24

New issue

Closed

opened 2026-07-18 08:42:50 +02:00 by fy59 · 0 comments

fy59 commented

2026-07-18 08:42:50 +02:00

Owner

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 :

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 :

metadata
investigation

Le schéma officiel doit donc préserver ces concepts tout en les consolidant.

Architecture

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 :

550e8400-e29b-41d4-a716-446655440000

Les identifiants sont générés par l'application avec :

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 :

YYYY-MM-DDTHH:MM:SSZ

Exemple :

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 :

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 :

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 :

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 :

types_preuve
types_entite
types_source
types_outils

Elles doivent comporter au minimum :

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 :

preuve_tags
entite_tags
personne_entites

Le schéma existant contient également une table générique :

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 :

CONSERVER
MODIFIER
RENOMMER
FUSIONNER
SUPPRIMER

La décision doit être documentée dans :

docs/database/SCHEMA_AUDIT_V1.md

Le document doit contenir au minimum :

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 :

database/schema_v1.sql

Deux approches sont acceptables :

intégrer le schéma au binaire via une ressource GLib ;
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 :

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 :

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 :

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

docs/database/SCHEMA_AUDIT_V1.md
database/schema_v1.sql
include/database/database.h
src/database/database.c
tests/test_database.c

Commit attendu

feat(database): consolidate initial investigation schema

## 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 - [x] Le schéma historique a été audité. - [x] Chaque table possède une décision documentée. - [x] Un schéma V1 officiel existe. - [x] Les conventions de nommage sont uniformes. - [x] Toutes les clés primaires sont explicites. - [x] Toutes les clés étrangères sont explicites. - [x] Les relations empêchent les doublons. - [x] Les colonnes obligatoires utilisent `NOT NULL`. - [x] Les tables de référence sont initialisées. - [x] `database_initialize()` installe le schéma complet. - [x] `PRAGMA integrity_check` retourne `ok`. - [x] Tous les tests restent valides. - [x] 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 ```

TICKET-023.md

11 KiB

fy59 closed this issue

2026-07-18 08:43:16 +02:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fy59/labfy-investigation#24

No description provided.

Consolider le schéma métier initial de l'enquête. #24

Titre

Objectif

Base de travail

Architecture

Décisions de conception à officialiser

Identifiants

Dates

Nommage

Clés étrangères

Tables de liaison

Tables métier à consolider

preuves

entites

personnes

sources

chronologie

recherches

hypotheses

journal

tags

Tables de référence

Tables de liaison

Audit obligatoire

Organisation du module Database

Responsabilités

Intégration dans Database

Principe d'organisation

Version du schéma

Hors périmètre

Contraintes techniques

Tests

Critères d'acceptation

Livrables

Commit attendu

`preuves`

`entites`

`personnes`

`sources`

`chronologie`

`recherches`

`hypotheses`

`journal`

`tags`

Intégration dans `Database`