[DOC] Mise à jour avec le nouveau nom de l'application

Merge pull request #35 from 1024pix/rename-application

.gitignore

@@ -2,3 +2,4 @@
 .env
 .idea
 restore.list
+backup.tar.gz

README.md

@@ -1,18 +1,42 @@
-# Réplication de la base de données Pix
+# Application de datawarehouse Pix
 
-Ce projet a pour but d'automatiser la réplication de la base de données de
-production de Pix via les sauvegardes automatiques de Scalingo.
+Ce projet a pour but de mettre à disposition
+- des utilisateurs internes (développeurs, PO, support, métiers)
+- des utilisateurs externes (partenaires, membres d'une organisation dans PixOrga)
+les possibilités suivantes:
+- exécuter des rapports dans Metabase
+- exécuter des requêtes SQL 
 
-## Utilisation
+Les contraintes majeures sont:
+- disposer des données les plus récentes
+- ne pas impacter la performance de la BDD
+- ne donner accès qu'aux utilisateurs autorisés.
+
+La solution est la suivante:
+- importer chaque nuit les données de production complète dans une BDD dite "interne"
+- importer chaque nuit une partie des données de production dans une BDD dite "externe"
+- dans Metabase, ne donner accès aux externes que sur cette BDD "externe"
+- suite à l'import, créer des objets supplémentaires pour assurer un temps d'exécution des rapport acceptables (index, vues matérialisées,..) 
+
+Pour importer les données, récupérer le backup créé automatiquement par Scalingo.
+Afin de garder un seul repository partagé par les applications, utiliser les variables d'environnement. 
+
+## Pré-requis
 
 Ce projet est prévu pour être déployé sur une application Scalingo associée à
 une base de donnée PostgreSQL.
 
-### Conteneurs
+## Déploiement application
 
-Pour satisfaire les contraintes de déploiement Scalingo, le `Procfile` déclare un conteneur de type `web` qui démarre un serveur Web "vide". Une fois l'application créée et déployée une première fois, il faut mettre à 0 le nombre de conteneurs de type `web` sur l'application Scalingo, et à 1 le nombre de conteneurs de type `background`.
+Pour satisfaire les contraintes de déploiement Scalingo, le `Procfile` déclare un conteneur de type `web` qui démarre un serveur Web "vide".
+
+Une fois l'application créée et déployée une première fois, il faut: 
+- mettre à 0 le nombre de conteneurs de type `web` 
+- mettre à 1 le nombre de conteneurs de type `background`.
+
+## Paramétrage
 
-### Environnement
+Variables d'environnement :
 
  * `SCALINGO_APP` : cette variable est utilisée automatiquement par l'outil CLI de Scalingo, et doit contenir le nom de l'application portant la base de données _source_ (`pix-api-production` typiquement).
 
@@ -22,27 +46,33 @@ Pour satisfaire les contraintes de déploiement Scalingo, le `Procfile` déclare
 
  * `DATABASE_URL` : URL d'accès à la base _cible_ qui sera écrasée et alimentée depuis le _backup_ à chaque exécution. Cette variable est en principe automatiquement alimentée par Scalingo lors de l'ajout d'une base PostgreSQL.
 
- * `MAX_RETRY_COUNT` : cette variable est utilisée pour indiquer le nombre maximum de tentative de rejout.
+ * `MAX_RETRY_COUNT` : cette variable est utilisée pour indiquer le nombre maximum de tentative de rejeux
 
  * `RESTORE_FK_CONSTRAINTS` : restaurer ou non les contraintes de clés étrangères. Si non renseignée, les contraintes de clés étrangères ne sont pas restaurées. Si "true", les contraintes de clés étrangères sont restaurées.
 
  * `RESTORE_ANSWERS_AND_KES` : restaurer ou non les tables `answers` et `knowledge-elements`. Si non renseignée, ces tables ne sont pas restaurées. Si "true", ces tables sont restaurées.
 
-### Exécution individuelle
 
-En cas de besoin, une opération de réplication peut être lancée immédiatement en exécutant le script `run.js` dans un conteneur individuel Scalingo :
+## Exécution hors tâche planifiée
+
+Une opération de réplication peut être lancée immédiatement (hors tâche planifiée) en exécutant le script `run.js` dans un conteneur individuel Scalingo :
 
-    $ scalingo run --region osc-secnum-fr1 -a pix-production-db-replication --size M --detached node run.js
+Sur la BDD destinée aux internes
+    $ scalingo run --region osc-secnum-fr1 -a pix-datawarehouse-production --size M --detached node run.js
 
+Sur la BDD destinée aux externes
+    $ scalingo run --region osc-secnum-fr1 -a pix-datawarehouse-ex-production --size M --detached node run.js
+
 ## Développement et exécution en local
 
-Certaines étapes de la procédure de réplication sont spécifiques à l'environnement Scalingo et pas pertinentes à exécuter en local lors du développement sur le script. Un exemple d'exécution d'une partie des étapes, en supposant un _backup_ déjà téléchargé et un serveur PostgreSQL disponible en local:
+Certaines étapes de la procédure de réplication sont spécifiques à l'environnement Scalingo et pas pertinentes à exécuter en local lors du développement sur le script. 
+Un exemple d'exécution d'une partie des étapes, en supposant un _backup_ déjà téléchargé et un serveur PostgreSQL disponible en local:
 
     $ DATABASE_URL=postgres://postgres@localhost/pix_restore node -e "steps=require('./steps'); steps.dropCurrentObjects(); steps.restoreBackup({compressedBackup:'backup.tar.gz'})"
 
-### Tests
+## Tests
 
-#### Manuels sur Scalingo
+### Manuels sur Scalingo
 
 Application Scalingo hors osc-secnum-fr1 pour éviter les considérations de sécurité des données 
 
@@ -58,9 +88,9 @@ Vérifier le résultat
 $ scalingo -a pix-db-replication pgsql-console
 `SELECT id, email FROM "users" LIMIT 5;`
 
-#### Automatisés
+### Automatisés
 
-##### Intégration
+#### Intégration
 
 Déroulement : 
 - une BDD est créé en local sur l'URL $TEST_POSTGRES_URL (défaut: `postgres://postgres@localhost`), instance `pix_replication_test`