Actualité‎ > ‎

Data Warehouse, BI et intégrité des données.

publié le 24 avr. 2014 à 11:38 par Thomas Gauchet

Le système décisionnel traditionnel repose sur un Data Warehouse alimenté par un ETL, sur le quel on branche des outils de reporting ou d’interrogation interfacés ou non par une couche OLAP relationnelle ou tabulaire. Généralement, le Data Warehouse est le point clé du système car il renferme un historique important de données propres et validées, construit grâce à de nombreuses itérations de l’ETL. J’ai pour habitude de me poser à sa fondation la question de l’intégrité des données qu’il concentre. Comment allons nous assurer que ces données soient stockées intègres. Il ne peut y avoir 2 produits du même code, ou une même sous famille attachée à deux familles différentes, cas rendus possibles par la clé technique et la dénormalisation. 

Il y a d’un côté l’intégrité des colonnes et de l’autre, l’intégrité référentielle. L’intégrité des colonnes comprend les valeurs que la colonne peut contenir, par exemple, non nulles, ‘Oui/Non’, et l’interdiction des doublons (Il ne peut y avoir 2 produits pour un seul code produit). L’intégrité référentielle est bien connue des systèmes OLTP, mais s’étend en décisionnel à des références dénormalisées plus difficiles à gérer.

Pour chaque cas, la règle de gestion de l’intégrité doit être définie et aboutit à la rédaction d’une nouvelle règle de développement. Ma préférence est pour l’utilisation des contraintes du moteur de bases de données pour assurer l’intégrité des colonnes, et  la conception des flux ETL pour assurer l’intégrité référentielle. Pour être plus prudent, il est possible d’activer en plus l’intégrité relationnelle dans le moteur de bases de données, mais cela à un coût sur les performances et aussi sur les manipulations de conception, la cuisine, opérée en développement, en intégration et en qualification sur les données.

Lorsque des enregistrements dans le système sources sont supprimés, ils sont généralement conservés dans le Data Warehouse. Dans le cas d’une dimension dénormalisée ils conservent leur mémoire relationnelle. Dans certains cas les modifications opérées dans la source peuvent alors aboutir à une corruption de la dimension. Par exemple un produit P1 appartient à une sous famille SF1 elle même attachée à une famille F1. Ce produit est créé tel quel dans le Data Warehouse, puis le produit est supprimé du système source, ou bien son code produit est modifié ce qui est équivaut à une suppression/création. Supprimé dans la source, il existe toujours dans le Data Warehouse. On crée alors un nouveau produit P2 attaché à SF1, mais désormais SF1 est relié à F2. La dimension dénormalisée contient alors 2 lignes avec SF1, la première la rattachant à P1, la seconde à P2: l’intégrité est violée. Ce cas doit être gérée. En amont, on peut interdire toute suppression physique (hard delete) et modification des clés métiers dans le système source. En aval on peut opter pour un schéma en flocon

Il existe d’autres stratégies pour résoudre ce cas, et encore bien d’autres cas à résoudre... Cela dépasse le périmètre de cet article.


 

Comments