Retour : page principale > sommaire eFlore v5 > Coel
Dans une deuxième temps :
Les tables de liaisons composées des clés primaires des tables principales quelles lient, ne possède généralement pas de clé étrangère vers la table projet.
Ainsi, si pour un projet donnée nous devons gérer des codes ou identifiants particuliers, il est nécessaire de prévoir des champs spécifiques.
Par ailleurs les version des projets sont gérées via les dates des enregistrements et les tables d'historiques.
Quand un enregistrement est ajouté :
Ce type de champ :
Ce type de champ :
Ce type de champ :
Pour les super-admins, seul la table "personne" servira Ă indiquer leur rĂ´le vis Ă vis de l'ensemble des projets.
Pour les administrateurs, leur rôle vis à vis d'un projet particulier est défini via la table "personne_a_relation" qui contiendra l'identifiant du coordinateur (= personne) à la fois dans le champ "id_personne_01" et "id_personne_02".
Pour les coordinateurs, leur rôle vis à vis d'un projet particulier est défini via la table "personne_a_relation" qui contiendra l'identifiant du coordinateur (= personne) à la fois dans le champ "id_personne_01" et "id_personne_02".
Pour savoir quels utilisateurs un coordinateur coordonne, il suffit de regarder quels sont les gestionnaire des structures du projet.
Pour les contributeurs a une structure en particulier (et donc aux collections quelle contient), il faudra utiliser la table "structure_a_personne" avec la valeur pour le champ "id_role" correspondant Ă "est administrer par".
Pour connaître le(s) coordinateur(s), il suffit de regarder a quel projet appartiennent ces structures, puis de regarder quels sont les coordinateurs de ces projets.
Les différents rôles des utilisateurs sont les suivants:
(Les rôles ci-dessous sont classé par importance décroissante. Chacun d'eux possède les droits du suivant.)
- Super Administrateur : il désigne les Administrateurs et crée les projets
- Administrateur : lié à un projet, il peut le modifier et désigner des coordinateurs
- Coordinateur : Lié à une structure, il peut les modifier
- Contributeur: Il peut modifier une structure, il peut désigner des contributeurs
Cela consiste en :
Si le projet hébergeant ces données a été autorisé à être publié sur Tela, les données marquées seront collecté par Tela Botanica et mise en ligne sur le site.
Périodiquement, Tela Botanica récupèrera les modifications apportées à ces données "publiques" pour mettre à jour le site de consultation.
Nous distinguons deux types de référentiels :
Un référentiel simple peut devenir complexe et inversement.
Au niveau des bases de données, un référentiel simple sera géré dans la table "liste_valeur" du module "Métadonnées", un référentiel complexe aura son propre module (Ex. : zones géographiques, langues, nomenclature botanique...).
Pour ce faire, tout référentiel simple pourra être mise à jour avec un référentiel complexe présent sur la base de référence grâce au champ "code/abréviation" (exemple : nn, code insee, code iso...) et à la date de dernière modification d'une valeur. La date de dernière modification de la liste de cette valeur permettra de connaître la date de dernière synchronisation.
Logiquement, la base de référence (eFlore) devrait contenir à la fois les référentiels complexes et les référentiels simples.
SELECT h.cmhl_id_historique_ligne, h.cmhl_ce_table, h.cmhl_cle_ligne, MAX(h.cmhl_date_modification) AS date_max, hp.cmhl_date_modification AS date_max_pre
FROM coel_meta_historique_ligne AS h LEFT JOIN coel_meta_historique_ligne AS hp ON (h.cmhl_ce_table = hp.cmhl_ce_table AND h.cmhl_cle_ligne = hp.cmhl_cle_ligne)
WHERE h.cmhl_ce_table IN (101, 106)
AND hp.cmhl_date_modification < h.cmhl_date_modification
GROUP BY h.cmhl_ce_table, h.cmhl_cle_ligne
Cahier des charges et notes
L'application devra :- gérer les standards : NCD, BIOCASE -> les tables de base correspondront à ce modèle
- gérer un historique des modifications -> utilisation de l'historisation en mode ligne
- gestion multi-projets versionnables (plusieurs inventaires doivent pouvoir être gérés en parallèle et chacun d'entre eux doit pouvoir être versionné).
Dans une deuxième temps :
- le fonctionnement hors-ligne quand GWT supportera l'API du HTML5 concernant le mode déconnecté
- gérer l'ajout de données spécifiques au projet Herbier LR/PACA -> utilisation de la technique des métadonnées.
Mise en ligne d'une nouvelle version
- Si c'est une version majeure :
- créer une branche sur le svn avec nom et numéro de version
- créer un tag sur le svn avec nom et numéro de version
- modifier dans la branche le fichier A_LIRE.txt
- dans tous les cas :
- dans la branche modifier le fichier : war/apropos.defaut.js en indiquant le numéro de version et le nom de la version majeure
- dans la branche créer/modifier le fichier : war/apropos.js en indiquant le numéro de version et le nom de la version majeure
- faire un merge avec la branche principale.
- Lancer le script : mise_en_ligne qui va : ./mise_en_ligne.sh -h 193.54.123.169 -u telabotap -p MOT_DE_PASSE
- compiler l'application dans le dossier war
- envoyer sur le serveur le dossier war
- envoyer sur le serveur le dossier Jrest
- Si la base de données a changé lancer via phpmyadmin le fichier sql de mise à jour.
- Si c'est le premier envoie ou si la configuration à changée modifier ou créer sur le serveur les fichiers :
- config.js de Coel
- .htacces de Coel ( Php5 + Utf-8)
- config.ini.php de Jrest
- .htacces de Jrest (Redirection vers les services)
Notes sur le modèle de la base de données
Projet
Les tables principales du modèle possèdent une clé primaire auto incrémentée et sont liées à la table des projets par une clé étrangère.Les tables de liaisons composées des clés primaires des tables principales quelles lient, ne possède généralement pas de clé étrangère vers la table projet.
Ainsi, si pour un projet donnée nous devons gérer des codes ou identifiants particuliers, il est nécessaire de prévoir des champs spécifiques.
Par ailleurs les version des projets sont gérées via les dates des enregistrements et les tables d'historiques.
Structures et collections
- Une structure ne peut pas être supprimée si elle possède des collections liées
Historisation
Concernant l'historisation, le principe retenu consiste à noter dans une table d'historique des lignes les informations sur un enregistrement et ses versions précédentes. Donc, nous aurons soit des enregistrements : ajoutés, modifiés ou supprimés.Quand un enregistrement est ajouté :
- un nouvel enregistrement est créé dans la table d'historique des lignes. Elle permet de savoir : qui a fait la modification, pourquoi, quand et depuis où (adresse IP).
- une ligne est créée et les données (dont l'identifiant des métadonnées) sont insérées dans sa table.
- ses champs modifiés ont leurs anciennes valeurs stockées dans une table d'historique des colonnes. Elle contient seulement les valeurs des champs d'un enregistrement : ajouté ou modifiés Pour un champ d'un enregistrement donnée, nous pouvons savoir : quelle valeur il avait et quand il a été enregistrée.
- un nouvel enregistrement est créé dans la table d'historique des lignes
- on met à jour les champs modifié (dont l'identifiant des métadonnées).
- un nouvel enregistrement est créé dans la table d'historique des lignes
- les valeurs de tous les champs de l'enregistrement supprimé sont stockées au format XML de la table d'historique des lignes.
- l'enregistrement est supprimé de sa table
Relation de type 0,n - 0,n liant une table de donnée à une table de liste de valeurs
Pour les champs de type cases à cocher ou liste de choix multiples, qui peuvent contenir plusieurs valeurs et même un champ "autre", nous utiliserons un champ dénormalisé. Cela permettra de simplifier la gestion et d'augmenter les performances.Ce type de champ :
- possédera dans son nom l'abreviation "_truk_"
- sera au format VARCHAR(255)
- stockera plusieurs valeurs séparées par deux points virgules consécutifs ";;".
- le mot en majuscule "AUTRE" sera séparé de la valeur défini par l'utilisateur par deux symboles dièse consécutif "##".
- le mot en majuscule "TOTAL" sera séparé de la valeur défini par l'utilisateur par deux symboles dièse consécutif "##". Il permettra de stocker les totaux des autres valeurs.
- au sein d'une valeur, un éventuel identifiant sera séparé de la valeur par deux symboles dièse consécutif "##". Cela permet de gérer plusieurs référentiels. Exemple : pour les codes géographiques on peut avoir ISO-3116-1, ISO-3166-2 et ISO-3116-3 ; pour les acronymes des structures on pourra avoir : IH (Index Herbarium) ou MNHN (Muséum National d'Histoire Naturelle). Dans ce cas, le fichier contenant le vocabulaire du modèle devra contenir la liste des identifiants avec leur signification.
Relation de type 0,1 - 0,n liant une table de donnée à une table de liste de valeurs
Pour les champs contenant une seule valeur provenant d'une liste, nous utiliserons la table "valeur" du module métadonnées pour lister l'ensemble des valeurs possible et leur identifiant.Ce type de champ :
- possèdera dans son nom l'abréviation "_ce_"
- sera le plus souvent au format INTEGER(3)
- contiendra l'identifiant de la valeur choisi
- possèdera dans son nom l'abréviation "_ce_truk_"
- sera le plus souvent au format VARCHAR(255)
- contiendra seulement l'identifiant de la valeur choisi si le champ autre n'est pas rempli
- stockera plusieurs valeurs séparées par des points virgule ";" (uniquement si une sélection est faite et que le champ autre est rempli).
- le mot en majuscule"AUTRE" sera séparé de la valeur défini par l'utilisateur par le symbole dièse "#".
Champ de formatage
Certains champs peuvent contenir des données pré-formatées correspondant à la concaténation de plusieurs autres champs de la table.Ce type de champ :
- possèdera dans son nom l'abréviation "_fmt_"
Droits et rĂ´les des utilisateurs
La table "personne" indique le rôle de plus grande importance que possède l'utilisateur vis à vis de l'ensemble des projets.- super-admin : vis à vis de tous les projets.
- admin : vis Ă vis de tous d'un ou plusieurs projets.
- coordinateurs : vis Ă vis d'un ou plusieurs projets (voir table "personne_a_relation").
- contributeurs : vis Ă vis d'une structure d'un ou plusieurs projets (voir table "structure_a_personne").
Pour les super-admins, seul la table "personne" servira Ă indiquer leur rĂ´le vis Ă vis de l'ensemble des projets.
Pour les administrateurs, leur rôle vis à vis d'un projet particulier est défini via la table "personne_a_relation" qui contiendra l'identifiant du coordinateur (= personne) à la fois dans le champ "id_personne_01" et "id_personne_02".
Pour les coordinateurs, leur rôle vis à vis d'un projet particulier est défini via la table "personne_a_relation" qui contiendra l'identifiant du coordinateur (= personne) à la fois dans le champ "id_personne_01" et "id_personne_02".
Pour savoir quels utilisateurs un coordinateur coordonne, il suffit de regarder quels sont les gestionnaire des structures du projet.
Pour les contributeurs a une structure en particulier (et donc aux collections quelle contient), il faudra utiliser la table "structure_a_personne" avec la valeur pour le champ "id_role" correspondant Ă "est administrer par".
Pour connaître le(s) coordinateur(s), il suffit de regarder a quel projet appartiennent ces structures, puis de regarder quels sont les coordinateurs de ces projets.
Les différents rôles des utilisateurs sont les suivants:
(Les rôles ci-dessous sont classé par importance décroissante. Chacun d'eux possède les droits du suivant.)
- Super Administrateur : il désigne les Administrateurs et crée les projets
- Administrateur : lié à un projet, il peut le modifier et désigner des coordinateurs
- Coordinateur : Lié à une structure, il peut les modifier
- Contributeur: Il peut modifier une structure, il peut désigner des contributeurs
Comment réaliser les versions des projets ?
Dans l'interface d'administration d'un projet, il y aura la possibilité d'indiquer les dates de début et de fin d'une version qui indiquera ainsi les étapes clés d'un projet.Comment se fera la publications des données sur Tela Botanica ?
Via l'interface de gestion des projets, l'administrateur ou super-administrateur pourra demander une autorisation de publication sur le site de Tela Botanica.Cela consiste en :
- l'utilisation du protocole UDDI fournit dans le TapirLink installé avec le COEL
- le client UDDI appellera un service d'eFlore (nommé UDDI) qui va récupérer toutes les infos nécessaires pour synchroniser un projet (voir Tapir metadata) et les stocker dans eFlore.
- ce service UDDI d'eFlore préviendra aussi le COEL si le projet a été autorisé ou pas...
- un flux RSS préviendra des nouvelles demandes les administrateurs de la base eFlore
- le champ "esws_ce_projet_eflore" de la table eflore_structure_web_service permettra d'autoriser la synchronisation (à faire manuellement). Ce champ contiendra l'id du projet au sein d'eFlore quand la synchro est autorisée.
- périodiquement sur le serveur où eFlore est hébergé (cron) une script (nommé Tapirus) sera lancé et se connectera aux TapirLink fournit avec le COEL, il récupérera les nouveautés autorisées a être publié depuis la dernière synchronisation et mettra à jour eFlore
- le transfert entre eFlore et un fournisseur COEL se fera selon le protocole Tapir
DĂ©tail du fonctionnement de Tapirus vis Ă vis du COEL
- Pour chaque projet d'un COEL demandant une synchro avec eFlore une ressource TapirLink sera crée.
- Cette ressource principale contiendra toutes les métadonnées liées au projet et sera liée à une table de la bdd COEL contenant 3 champs principaux : id_projet, id_table, date_modification. Ces 3 champs permettrons de savoir la date de dernière modification d'un enregistrement d'une table au sein d'un projet donné.
- D'une façon globale, une ressource par table de la bdd COEL sera créée au sein de TapirLink
- Tapirus se chargera d'appelé chacun des services liée à une table si le service principal indique que la table a été mise à jour. Il mettra un filtre en fonction de l'id du projet principal.
Quelles données seront rendues publiques sur le site de Tela Botanica ?
Dans l'interface d'administration, un utilisateur pourra marquer les structures et collections qu'il gère comme "données transmises à Tela Botanica".Si le projet hébergeant ces données a été autorisé à être publié sur Tela, les données marquées seront collecté par Tela Botanica et mise en ligne sur le site.
Périodiquement, Tela Botanica récupèrera les modifications apportées à ces données "publiques" pour mettre à jour le site de consultation.
Notions de référentiels, liste de valeurs (typologie)
Par référentiels nous entendons tout ensemble homogène, c'est à dire une liste, de valeurs, chaque valeur étant constituées d'au moins 3 caractéristiques : nom, code et description.Nous distinguons deux types de référentiels :
- simple : contient seulement des données constitué de ces 3 caractéristiques : nom, code (= abréviation) et description.
- complexe : le référentiel possèdes des données plus détaillées. Exemple : des communes françaises avec indication de latitude et longitude de leurs barycentres...
Un référentiel simple peut devenir complexe et inversement.
Au niveau des bases de données, un référentiel simple sera géré dans la table "liste_valeur" du module "Métadonnées", un référentiel complexe aura son propre module (Ex. : zones géographiques, langues, nomenclature botanique...).
Synchronisation des référentiels
Via l'interface de paramétrage d'une application (ici COEL), un super-admin pourra réaliser la synchronisation des référentiels avec la base de référence (eFlore).Pour ce faire, tout référentiel simple pourra être mise à jour avec un référentiel complexe présent sur la base de référence grâce au champ "code/abréviation" (exemple : nn, code insee, code iso...) et à la date de dernière modification d'une valeur. La date de dernière modification de la liste de cette valeur permettra de connaître la date de dernière synchronisation.
Logiquement, la base de référence (eFlore) devrait contenir à la fois les référentiels complexes et les référentiels simples.
Référentiels dans le cadre de l'application COEL
Les référentiels "complexes" :- Pour les collecteurs, auteurs... intégrer les standard suivant dans le module Personne :
- APN = Authors of Plant Names (http://www.tdwg.org/standards/101/)
- BP = Brummitt & Powell's (1992) Authors of Plant Names
- HUH = Harvard University Herbaria Index of Botanists (http://asaweb.huh.harvard.edu:8080/databases/botanist_index.html)
- Pour les noms de pays... intégrer le standard suivant dans la table "liste_valeur" du module Métadonnées :
- ISO-3166-1 (http://fr.wikipedia.org/wiki/ISO_3166-1)
- Pour les noms de département... intégrer les standards suivant dans la table "liste_valeur" du module Métadonnées :
- ISO-3166-2 (http://fr.wikipedia.org/wiki/ISO_3166-2)
- INSEE Départements français
- Pour les noms de communes... intégrer le standard suivant dans la table "liste_valeur" du module Métadonnées :
- INSEE Communes françaises
- Si besoin pour les langues... intégrer le standard suivant dans la table "liste_valeur" du module Métadonnées :
- les standards ISO-613 (http://fr.wikipedia.org/wiki/ISO_639)
Insertion du schéma de la base de données et des listes de valeurs
Pour les listes de valeurs, les insérer dans cet ordre :- les valeur d'état d'enregistrement [0-10]
- les tables [11-200]
- la liste des listes [201-999]
Références
Notes
- Si on veut distinguer numéros de téléphone, fax, courriels, url... du domicile / bureau, il faudrait utilisait la table structure_a_personne (pour stocker les infos "bureau" d'une personne vis à vis d'une structure), personne (pour les infos du domicile) et structure (pour les infos propres au bureau).
- Le registre devrait seulement servir à stocker des paramêtres de l'appli chargé depuis un fichier de config. Préférer les variables de classes à l'utilisation du registre. Cela sera plus facile à tester.
A faire
- VĂ©rifier les types de champ : _ce_, _ce_truk_ et _truk_ lors de la mise en place des formulaires dans l'appli
- Rajouter les relations entre les champs de type ..._ce_..., ..._ce_truk_... et la table coel_meta_liste_valeur
- Rajouter les relations entre .._ce_meta et la table coel_meta_historique_ligne
- Supprimer la taille pour le type INTEGER dans le modèle
- VĂ©rifier la suppression des valeurs "Autres" du fichier de vocabulaire pour les champs de type "_ce_truk_"
- Ajouter au script Perl dbd_rapport un squelette pour la création du fichier SQL de structure de la base de données avec commentaires
- Créer un script PHP qui automatise l'insertion des informations dans les tables de métadonnées depuis le fichier ".ini" contenant le vocabulaire et le fichier sql de création de la base de données
- Régler le problème des champs pour les Collections de l'ancienne appli Herbiers non présent dans la nouvelle enquête : Mode de conservation des spécimens, Nombre de spécimens, Caractériser le dénombrement de spécimens, Nombre d'espèces, Caractériser le dénombrement d'espèces, État de la présentation, État du classement, État de la présentation, État de la documentation, % de la documentation en base de données
- Il faudra peut être créer un module commentaire pour gérer les notes...
- Tester si c'est plus intéressant de laisser un champ *_ce_etat dans les tables pour reconnaître les champs supprimés des autres (ajoutés et modifiés). Plutôt que de tout mettre dans la table "coel_meta_historique_ligne".
- Tester les différents types d'historisation
A faire pour la compatibilité Coel / eFlore
- mettre en place dans le modèle DBD une seule table de méta-données "liste_valeur" dans un nouveau module "Métadonnées".
- Modifier le script SQL de mise Ă jour d'eFlore.
- Créer le fichier texte tabulé gérant les référentiels "simples"
- Modifier le script de génération du SQL pour la bdd COEL
- Créer une méthode générant un rapport dans le script de génération du SQL. Il doit permettre de charger le contenu de la table "liste_valeur" présent pour la bdd eFlore.
A faire sur le service Coel-Tapir vers eFlore
- Tester la chaine complète sur un petit ensemble de données (une seule table : structure) :
- mise à jour du sql d'eFlore pour gérer les fournisseurs
- Service de demande d'autorisation ( EfloreFournisseur)
- Service Tapir Coel
- créer un schéma XML permettant de mapper une table du COEL
- Ajouter le champ dernière modification et état pour tester les dernière modifications.
- Script eFlore géré par cron pour récupérer les données,
- intérogation d'un TapirLink via les données stockées dans la table "eflore_structure_web_service"
- récupération et insertion de toutes les données d'une table dans eFlore lors d'une première synchronisation
- ajouter des messages d'info quand des métadonnées sont modifiées
- prendre en charge les préférences d'indexation pour la mise à jour
- historisation des données dans eFlore, lors d'une mise à jour.
Améliorations possibles
- Utiliser la champ _truk_telephone pour stocker les numéros de fax. Il pourrait porter le type "FAX". Nous avons déjà : "FIX" pour les numéros de téléphone fixe, "GSM" pour les portables et "PAG" pour les pagers.
RequĂŞte pour le flux RSS
SELECT h.cmhl_id_historique_ligne, h.cmhl_ce_table, h.cmhl_cle_ligne, MAX(h.cmhl_date_modification) AS date_max, hp.cmhl_date_modification AS date_max_pre
FROM coel_meta_historique_ligne AS h LEFT JOIN coel_meta_historique_ligne AS hp ON (h.cmhl_ce_table = hp.cmhl_ce_table AND h.cmhl_cle_ligne = hp.cmhl_cle_ligne)
WHERE h.cmhl_ce_table IN (101, 106)
AND hp.cmhl_date_modification < h.cmhl_date_modification
GROUP BY h.cmhl_ce_table, h.cmhl_cle_ligne