Quelles sont les politiques de conservation et de suppression des données d'iDBQuery ?

La conservation est plus simple avec iDBQuery qu'avec une stack fondée sur un entrepôt de données, parce qu'il y a bien moins à conserver dès le départ.

Comme iDBQuery interroge vos sources sur place et construit un modèle vivant par-dessus, vos enregistrements sous-jacents restent dans vos propres bases de données et fichiers — iDBQuery n'en est pas une seconde copie permanente. Ce qu'il conserve est d'ordre opérationnel :

• La configuration de connexion et les identifiants chiffrés de chaque source.
• Les métadonnées de schéma et la couche sémantique qu'il apprend afin de comprendre vos données.
• Les résultats mis en cache, rapports et tableaux de bord que vous avez créés.
• Les journaux d'audit et d'activité.

Vous en gardez le contrôle intégral. Retirer une source supprime ses métadonnées stockées, ses résultats mis en cache et ses identifiants. Supprimer un espace de travail retire les données stockées qui lui sont associées. Lorsque vous résiliez, vous pouvez exporter ce que vous avez construit puis faire supprimer l'espace de travail.

Le déploiement change entièrement la donne. Dans un déploiement auto-hébergé, mono-serveur ou isolé (air-gapped), chacun de ces artefacts vit à l'intérieur de votre propre infrastructure, de sorte que les durées de conservation, les sauvegardes et la suppression sont régies par vos politiques, non par les nôtres — il n'y a aucune copie dans un cloud fournisseur dont il faudrait se soucier. C'est aussi ce qui rend iDBQuery simple à aligner sur les demandes de suppression des personnes concernées : vous pouvez tracer un chiffre jusqu'à ses lignes sources exactes, et vous contrôlez l'endroit où les données dérivées sont stockées et le moment de leur purge.