Différences entre les versions de « Archéo Lex/Base de données »

De Wiki Seb35
Aller à la navigation Aller à la recherche
(→‎Structure : typo)
(+explication de <s>texte</s> base de données)
Ligne 1 : Ligne 1 :
Archéo Lex importe dans un base de données SQLite les données parsées des textes de loi à partir des bases XML ouvertes (LEGI, KALI, etc.). Pour l’instant, seule la base LEGI a été testée. Cette base de données SQLite permet d’avoir de pouvoir requêter facilement afin de créer les textes de loi dans les formats demandés, ainsi que de pouvoir recréer des textes déjà compilés (''reproductible data'') sous réserve d’avoir encore les textes des articles dans leur version d’alors.
Archéo Lex importe les codes de la base LEGI dans un base de données SQLite. Cette base de données SQLite permet d’avoir de pouvoir requêter facilement afin de créer les textes de loi dans les formats demandés, ainsi que de pouvoir recréer des textes déjà compilés (''reproductible data''), sous réserve d’avoir encore les textes des articles dans leur version d’alors puisqu’ils ne sont pas enregistrés pour des questions de place.


La base de données contient toutes les métadonnées utiles extraites des bases XML ainsi que les intitulés des sections (généralement quelques mots). En particulier, elle ne contient pas les articles (dans cette version de la base de données SQLite) car cela prendrait beaucoup de place, pas forcément utilement.
== Structure ==
 
La base de données comprend deux types d’informations :
# la base LEGI en tant que donnée brute importée : tables <tt>texte</tt>, <tt>section</tt>, <tt>article</tt> avec diverses métadonnées ;
# les versions consolidées des codes tels que calculés par le programme, puisque cette information n’est pas donnée explicitement dans la base LEGI (il faut rassembler toutes les dates de consolidation mentionnées pour obtenir l’ensemble des versions consolidées) : tables <tt>version_texte</tt>, <tt>version_section</tt>.
 
De plus, pour permettre de modifier de façon incrémentale les dépôts Git en sortie au fur et à mesure de la mise à jour de la base LEGI, chaque enregistrement dans la base de données est également étiqueté avec la date de la dernière mise à jour du code dans la base LEGI <span style="color:red">[il faut ajouter ces tags dans la BDD]</span>. Ainsi, lorsqu’une section est mise à jour dans la base LEGI, un enregistrement dans <tt>version_section</tt> est créé <u>ainsi qu’un nouveau lien entre <tt>article</tt> et <tt>version_section</tt></u> <span style="color:red">[il faut ajouter une table version_section_article ou version_article]</span>. De même, lorsqu’un article est mis à jour dans la base LEGI, un enregistrement dans <tt>article</tt> <span style="color:red">[ou version_article]</span> ainsi qu’un lien <span style="color:red">[même remarque que précédemment]</span>.


== Structure ==
== Schéma SQL ==


; texte
; texte

Version du 21 décembre 2014 à 17:44

Archéo Lex importe les codes de la base LEGI dans un base de données SQLite. Cette base de données SQLite permet d’avoir de pouvoir requêter facilement afin de créer les textes de loi dans les formats demandés, ainsi que de pouvoir recréer des textes déjà compilés (reproductible data), sous réserve d’avoir encore les textes des articles dans leur version d’alors puisqu’ils ne sont pas enregistrés pour des questions de place.

Structure

La base de données comprend deux types d’informations :

  1. la base LEGI en tant que donnée brute importée : tables texte, section, article avec diverses métadonnées ;
  2. les versions consolidées des codes tels que calculés par le programme, puisque cette information n’est pas donnée explicitement dans la base LEGI (il faut rassembler toutes les dates de consolidation mentionnées pour obtenir l’ensemble des versions consolidées) : tables version_texte, version_section.

De plus, pour permettre de modifier de façon incrémentale les dépôts Git en sortie au fur et à mesure de la mise à jour de la base LEGI, chaque enregistrement dans la base de données est également étiqueté avec la date de la dernière mise à jour du code dans la base LEGI [il faut ajouter ces tags dans la BDD]. Ainsi, lorsqu’une section est mise à jour dans la base LEGI, un enregistrement dans version_section est créé ainsi qu’un nouveau lien entre article et version_section [il faut ajouter une table version_section_article ou version_article]. De même, lorsqu’un article est mis à jour dans la base LEGI, un enregistrement dans article [ou version_article] ainsi qu’un lien [même remarque que précédemment].

Schéma SQL

texte
CREATE TABLE "texte" ("cid" VARCHAR(20) NOT NULL PRIMARY KEY, "nor" VARCHAR(20) NOT NULL, "nature" VARCHAR(20) NOT NULL, "date_texte" DATE, "date_publi" DATE);
version_texte
CREATE TABLE "version_texte" ("id" INTEGER NOT NULL PRIMARY KEY, "texte_id" VARCHAR(20) NOT NULL, "titre" VARCHAR(200) NOT NULL, "titre_long" VARCHAR(200) NOT NULL, "etat_juridique" VARCHAR(25) NOT NULL, "debut" DATE, "fin" DATE, "base_id" INTEGER, FOREIGN KEY ("texte_id") REFERENCES "texte" ("cid"), FOREIGN KEY ("base_id") REFERENCES "version_texte" ("id"));
CREATE INDEX "version_texte_base_id" ON "version_texte" ("base_id");
CREATE INDEX "version_texte_texte_id" ON "version_texte" ("texte_id");
section
CREATE TABLE "section" ("cid" VARCHAR(20) NOT NULL PRIMARY KEY, "cid_parent_id" VARCHAR(20), "niveau" INTEGER NOT NULL, "texte_id" VARCHAR(20) NOT NULL, FOREIGN KEY ("cid_parent_id") REFERENCES "section" ("cid"), FOREIGN KEY ("texte_id") REFERENCES "texte" ("cid"));
CREATE INDEX "section_cid_parent_id" ON "section" ("cid_parent_id");
CREATE INDEX "section_texte_id" ON "section" ("texte_id");
version_section
CREATE TABLE "version_section" ("id" VARCHAR(20) NOT NULL PRIMARY KEY, "cid_id" VARCHAR(20) NOT NULL, "id_parent_id" VARCHAR(20), "nom" VARCHAR(200) NOT NULL, "etat_juridique" VARCHAR(25) NOT NULL, "niveau" INTEGER NOT NULL, "numero" INTEGER NOT NULL, "debut" DATE NOT NULL, "fin" DATE, "texte_id" VARCHAR(20) NOT NULL, "version_texte_id" INTEGER, FOREIGN KEY ("cid_id") REFERENCES "section" ("cid"), FOREIGN KEY ("id_parent_id") REFERENCES "version_section" ("id"), FOREIGN KEY ("texte_id") REFERENCES "texte" ("cid"), FOREIGN KEY ("version_texte_id") REFERENCES "version_texte" ("id"));
CREATE INDEX "version_section_cid_id" ON "version_section" ("cid_id");
CREATE INDEX "version_section_id_parent_id" ON "version_section" ("id_parent_id");
CREATE INDEX "version_section_texte_id" ON "version_section" ("texte_id");
CREATE INDEX "version_section_version_texte_id" ON "version_section" ("version_texte_id");
article
CREATE TABLE "article" ("id" VARCHAR(20) NOT NULL PRIMARY KEY, "nom" VARCHAR(200) NOT NULL, "etat_juridique" VARCHAR(25) NOT NULL, "num" VARCHAR(200) NOT NULL, "debut" DATE NOT NULL, "fin" DATE, "texte_id" VARCHAR(20) NOT NULL, "version_section_id" VARCHAR(20) NOT NULL, "version_texte_id" INTEGER NOT NULL, FOREIGN KEY ("texte_id") REFERENCES "texte" ("cid"), FOREIGN KEY ("version_section_id") REFERENCES "version_section" ("id"), FOREIGN KEY ("version_texte_id") REFERENCES "version_texte" ("id"));
CREATE INDEX "article_texte_id" ON "article" ("texte_id");
CREATE INDEX "article_version_section_id" ON "article" ("version_section_id");
CREATE INDEX "article_version_texte_id" ON "article" ("version_texte_id");