Différences

Ci-dessous, les différences entre deux révisions de la page.

--- database:import-formats [2026/06/17 08:21] – [Transmission des fichiers] jpmilcent
+++ database:import-formats [2026/11/02 14:54] (Version actuelle) – [Évolutions] jpmilcent
@@ Ligne 67: / Ligne 67: @@
     * les actions suivantes //parser// le fichier CSV, //copier// le CSV préparé dans la base, //insérer// les lignes dont //meta_last_action// vaut "I" et //mettre à jour// les lignes dont //meta_last_action// vaut "U" sur les entités dans l'ordre suivant : ''source'', ''organism'', ''user'', ''acquistion_framework'', ''dataset'', ''synthese''.
     * enfin, il est possible de //supprimer// les lignes dont //meta_last_action// vaut "D" sur les entités dans l'ordre suivant : ''synthese'', ''dataset'', ''acquistion_framework'', ''user'', ''organism'', ''source''.
+=== Gestion du différentiel dans la base des locale d'un administrateur de données ===
+Il faut gérer un différentiel par rapport à la date du dernier export vers le SINP.
+Seules les données ajoutées, modifiées ou supprimées depuis le dernier export doivent être transmises.
+Pour les données ajoutées :
+  * ''meta_last_acton'' doit prendre la valeur "''I''"
+  * ''meta_create_date'' doit indiquer la date et heure de création de l'enregistrement.
+Pour les données modifiées (1 ou plusieurs fois) :
+  * ''meta_last_action'' doit prendre la valeur "''U''"
+  * ''meta_update_date'' doit indiquer la date et heure de **la dernière** modification depuis l'export précédent
+Pour les données supprimées :
+  * ''meta_last_action'' doit prendre la valeur "''D''".
+Cas particuliers :
+  * une donnée ajoutée (et éventuellement modifiée), puis supprimée depuis le dernier export n'est pas à transmettre ;
+  * une donnée ajoutée puis modifiée doit être transmise avec ''meta_last_action''  = "''I''" (ajout) et non "''U''" (mise à jour).
 ==== Format du fichier des métadonnées de l'archive "meta_archive.ini" ====
@@ Ligne 117: / Ligne 138: @@
   * si nécessaire utiliser le caractère **guillemet** (") pour préfixer et suffixer une valeur de champ
   * si nécessaire utiliser **deux guillemets** successifs ("") pour échapper le caractère guillemet dans une valeur de champ préfixé et suffixé par des guillemets.
+  * respecter l'ordre des champs décrits dans cette documentation
+  * si possible fournir les fichiers avec l'ensemble des champs décrits même s'ils doivent contenir des valeurs nulles
 Il faut vous assurer d'avoir supprimé, remplacé ou protégé les caractères suivant dans les valeurs des champs :
@@ Ligne 137: / Ligne 160: @@
   * si les champs ne sont pas valables pour toutes les lignes, 1 seule possibilité :
     * utiliser le champ //additional_data// dont les valeurs doivent être [[https://www.json.org/json-fr.html|au format JSON]] et [[https://jsonformatter.curiousconcept.com/|être valide]]. Le JSON en question devra correspondre à un objet d'un seul niveau avec attribut et valeur. Ex. : <code json>{"attribut1": "valeur1", "attribut2": "valeur2"}</code>
-  * si les champs sont valables pour toutes les lignes du fichier d'import, 2 possibilités :
+  * si les champs sont valables pour toutes les lignes du fichier d'import, <del>2</del> 1 possibilité<del>s</del> :
-    * ajouter des colonnes supplémentaires au fichier
     * utiliser le champ //additional_data// (voir ci-dessus)
+    * <del>ajouter des colonnes supplémentaires au fichier</del> : non implémenté !
 Afin de respecter le standard, il est nécessaire de fournir les méta-données de ces champs additionnel en fournissant le fichier //meta_additional_data.csv// (voir META_ADDITIONAL_DATA). Ce fichier contient la descriptions des champs additionnels.
-Pour faciliter l'intégration des données, l'utilisation du champ //additional_data// est conseillée.\\
+Pour permettre l'intégration des données, l'utilisation du champ //additional_data// est nécessaire car la possibilité d'ajouter des colonnes supplémentaires aux fichiers CSV n'est pas implémentée.\\
 Les champs additionnels ne seront pas forcément traités pour toutes les ressources. Seuls les champs de la ressource SYNTHESE seront transmis au niveau national.
@@ Ligne 165: / Ligne 188: @@
 ==== Évolutions ====
+  * 2026-11-02 :
+    * Champs ''code_nomenclature_territorial_level'' et ''code_nomenclature_financing_type'' sont maintenant obligatoires dans ''ACQUISITION_FRAMEWORK''.
+  * 2026-06-17 :
+    * Ajout des statuts des différents fichiers.
+    * Ajout de complément sur le format des fichiers CSV attendus.
+    * Mise à jour des textes introductifs.
   * 2026-04-02 :
     * Utilisation de ''VARCHAR(50)'' pour tous les champs ''code_nomenclature_...'' de SYNTHESE.
+  * 2026-03-13 :
+    * Ajout du format VALIDATION. Nécessaire pour intégrer un historique des validations à la Synthese ou dans le cadre de l'utilisation du format OCCTAX.
   * 2025-04-30 :
-    * Ajout du format OccTax supporté pour les ajouts uniquement. Non nécessaire pour l'instant dans le cadre des SINP.
+    * Ajout du format OCCTAX supporté pour les ajouts uniquement. Non nécessaire pour l'instant dans le cadre des SINP.
   * 2024-10-23 :
     * Nous privilégions maintenant l'utilisation des UUID comme identifiant de lien entre les ressources à la place des codes ou noms.
@@ Ligne 380: / Ligne 411: @@
   * **name** [VARCHAR(255)] (=//acquisition_framework_name//) : nom complet du cadre d'acquisition. Sert de le lien avec la ressource DATASET et son champ "//code_acquisition_framework//" mais aussi avec le champ //parent_code//.
   * **desc** [TEXT] (=//acquisition_framework_desc//) : description du cadre d'acquisition.
-  * code_nomenclature_territorial_level [VARCHAR(25)] (=//id_nomenclature_territorial_level//) : code alphanumérique de la valeur du type de nomenclature //NIVEAU_TERRITORIAL// ([[https://inpn.mnhn.fr/docs-web/docs/download/263010|NiveauTerritorialValue|84|page23]]).
+  * **code_nomenclature_territorial_level** [VARCHAR(25)] (=//id_nomenclature_territorial_level//) : code alphanumérique de la valeur du type de nomenclature //NIVEAU_TERRITORIAL// ([[https://inpn.mnhn.fr/docs-web/docs/download/263010|NiveauTerritorialValue|84|page23]]).
   * territory_desc [TEXT] : description du territoire concerné.
   * keywords [TEXT] : mot(s)-clé(s) représentatifs du cadre d'acquisition, séparés par des virgules.
-  * code_nomenclature_financing_type [VARCHAR(25)] (=//id_nomenclature_financing_type//) : code du type de financement pour le cadre d'acquisition, tel que défini dans la nomenclature //TYPE_FINANCEMENT// ([[https://inpn.mnhn.fr/docs-web/docs/download/263010|TypeFinancementValue|88|page28]]).
+  * **code_nomenclature_financing_type** [VARCHAR(25)] (=//id_nomenclature_financing_type//) : code du type de financement pour le cadre d'acquisition, tel que défini dans la nomenclature //TYPE_FINANCEMENT// ([[https://inpn.mnhn.fr/docs-web/docs/download/263010|TypeFinancementValue|88|page28]]).
   * target_description [TEXT] : description de la cible taxonomique ou géologique pour le cadre d'acquisition (Ex. : pteridophyta).
   * ecologic_or_geologic_target [TEXT] : champ composé de //cd_nom// de TaxRef, séparés par des points virgules, s'il s'agit de taxons, ou de //cd_hab// de HabRef, séparés par des points virgules, s'il s'agit d'habitats.
@@ Ligne 456: / Ligne 487: @@
   * Table GeoNature : "//pr_occtax.*//".
   * Standard : [[https://inpn.mnhn.fr/docs-web/docs/download/221989|OccTax v2]]\\
-  * Statut : ** 🔍 Bêta (fonctionnel mais des corrections peuvent subvenir) **
+  * Statut : **🔍 Bêta (fonctionnel mais des corrections peuvent subvenir)**
 ==== Description du format OCCTAX ====
@@ Ligne 531: / Ligne 562: @@
   * Table GeoNature : ''//gn_commons.t_validations//''.
   * Standard : [[http://standards-sinp.mnhn.fr/occurrences-de-taxon|OccTax v2]]\\
-  * Statut : ** 🔍 Bêta (fonctionnel mais des corrections peuvent subvenir) **
+  * Statut : **🔍 Bêta (fonctionnel mais des corrections peuvent subvenir)**
 ==== Description du format VALIDATION ====