Vider une entité Master Data Services

Bon un petit post rapide pour un truc tout bête: comment vider une entité dans MDS. La technique la plus simple que je connaisse est de déverser le contenu d’une vue de souscription dans la table de staging, avec un marqueur de suppression.

Lorsque l’on insère dans la table de staging feuille d’une entité – en général pour ajouter de nouveaux membres dedans – on doit renseigner plusieurs choses obligatoiremement (dans la table Entity Based, ce qui est une nouveauté 2012 rappelons le, ces champs sont marqués NOT NULL):

  • Le statut d’import ImportStatus_ID (généralement 0, qui signifie « à traiter »)
  • Le Code du membre à traiter
  • Le marqueur ImportType qui détermine ce que le processus doit faire avec cette ligne. Ses valeurs vont de 0 à 6 et signifient:
    • O : « Créer un nouveau membre si le Code n’existe pas, mettre à jour le membre s’il existe mais uniquement si les valeur de propriétés ne sont pas nulles »
    • 1 : « Créer un nouveau membre si le Code n’existe pas, lever une erreur s’il existe. »
    • 2 : « Créer un nouveau membre si le Code n’existe pas,  mettre à jour le membre s’il existe. »
    • 3 : « Désactiver le membre, lever une erreur s’il est référencé par un membre d’une autre entité. »
    • 4 : « Supprimer le membre, lever une erreur s’il est référencé par un membre d’une autre entité. »
    • 5 : « Désactiver le membre. Les colonnes de référence passent à NULL s’il est référencé par une autre entité. »
    • 6 : « Supprimer le membre. Les colonnes de référence passent à NULL s’il est référencé par une autre entité. »
  • Un nom de Batch pour la ligne, nommé BatchTag

Pour supprimer un membre de manière définitive, il suffit de le réinsérer dans le Staging avec un ImportType à 4 ou 6 et d’envoyer la procédure de staging:


DECLARE @VersionName NVARCHAR(50) = 'VERSION_1'
DECLARE @BatchTag NVARCHAR(50) = 'Deletion'

INSERT stg.Entity_Leaf
(
   ImportStatus_ID,
   ImportType,
   Code,
   BatchTag
)
SELECT 0, 6, Code, @BatchTag
FROM mdm.SubscriptionView

EXECUTE stg.udp_Entity_Leaf
      @VersionName = @VersionName,
      @LogFlag = 1,
      @BatchTag = @BatchTag

Voilà un truc simple et rapide :)!
A bientôt!

Master Data Services 2012, toutes les raisons de l’implémenter

Une petite discussion de la semaine dernière avec mon excellent petit collègue Charles-Henri amène ce post sur MDS, l’outil de MDM (Master Data Management, gestion de référentiel) de Microsoft, qui est sorti en mars dernier dans sa seconde version (qui a dit « première version utilisable? » :)). Pour résumer:

  • Je pense que non seulement nous allons être amenés à en mettre de plus en plus en place dans le cadre de projets décisionnels,
  • Mais en plus  que le produit répond à une problématique décorrélée de la BI qui peut elle même être génératrice de projets

Un bref historique

Le terme MDM, vous l’entendez depuis quelques temps – probablement depuis les années 2006-2007 je n’ai pas vérifié mon Décidéo. Ce vocable en vogue à l’époque – et toujours aujourd’hui d’ailleurs – verbalise simplement le fait que les applications d’une entreprise ont potentiellement vocation à partager un certain volume de référentiels.

Diantre la belle affaire.

On parle à cette époque déjà depuis longtemps d’outils de CDI (pas les contrats, la Customer Data Integration, le fait de disposer d’un seul référentiel client), et de PIM (pas l’onomatopée, Product Information Management, pour les produits). Le MDM est simplement la mise sous le même chapeau de ces deux domaines, en considérant que l’intégration des référentiels d’une entreprise se doit d’aller plus loin que le traditionnel diptyque Client-Produit.

Quel rapport avec la BI et le Data Warehousing en particulier?

Je suis moins bon en schémas que le pote Florian Eiden mais je vais m’y coller. Quand on parle d’alimentation d’entrepôt et spécifiquement de dimension, on désigne les opérations réalisées par les environnements de stockage.

  • On procède d’abord à un Staging des données: l’intégration dans un environnement technologique unique de données hétérogènes.
  • Puis on rapproche et on nettoie ces données dans un Operational Data Store non historisé.
  • Très schématiquement l’historisation de l’ODS donne la dimension du Data Warehouse.

<Flagellez moi si vous êtes en désaccord hein>

Si on enlève ces barbarismes technologiques, et sachant qu’un certain nombre de transformations peuvent s’effectuer dans un environnement ou un autre selon le doigt mouillé l’expérience (i.e. le nettoyage des données…), j’ai tendance à plutôt voir le boulot comme ça, indépendamment de l’emplacement où les tâches se font, et ce bien avant l’apparition du terme MDM

Flux

Pour un produit par exemple on va intégrer des « référentiels » hétérogènes (Excel, Access, SGBD loufoques), que l’on va rapprocher au moyen de méthodes floues et de règles métier.  A ce stade, on dispose de Master Data (données de référence). Une dimension sur ces Master Data en est simplement une potentielle historisation (SCD) en plus de modification structurelles liées au frontal ou aux principes de Ralph.

Dit autrement: la BI s’occupe de Master Data depuis un petit bout de temps, mais uniquement pour son petit besoin analytique.

Comment partager le travail réalisé sur un projet BI avec les application métier?

Un ancien chef de produit SQL Server, très bon en MDX, fondateur de l’ex-Winsight et inventeur d’expressions célèbres comme « la première année de souris » décrivait ce genre d’usage par l’anaphore « boucler la boucle analytique ».

C’est joli et cela sied bien à l’usage présent je trouve: en effet pourquoi vouloir tenir à l’écart le reste de l’entreprise des efforts de normalisation effectués en aval dans la BI? On le fait bien parfois en ouvrant les ODS à certaines applis non décisionnelles. Aller plus loin est donc possible technologiquement.

Bon pour être honnête, rien de ne l’a jamais empêché dans l’absolu, sauf à mon humble avis des besoins fonctionnels assez peu conciliables entre la BI et les utilisateurs des référentiels.

– Les utilisateurs ont besoin d’outil intuitifs pour modifier un faible volume de données, réaliser des insertions, avec une restitution compréhensible: en gros ils font de l’Access ou achètent un outil de PIM.

L’IT et la BI en particulier de solution industrialisables, permettant du chargement en bloc de données de référence depuis des systèmes tiers: ils font de l’ETL.

Mettre sous le même chapeau ETL et PIM étendu à tout le spectre des référentiels: c’est ce que fait MDS en 2012.

Principe de Master Data Services 2012

Master Data Services, comme en 2008R2, s’installe avec une base de données dédiée sur laquelle tourne un jeu de services WCF. Un site Web permet la configuration, la création de modèles de données (Client, Produit…), des règles métier associées en utilisant ces services… Il est installé et sa base créée un peu comme RS via un Configuration Manager.

D’un point de vue process, les données sont exposées entité par entité via des vues SQL, donc facilement interrogeables. Le CRUD sur les entités peut se faire directement à travers SQL via des tables de staging SQL Server ou à travers l’API de services WCF.

7840.MDS Architecture

Deux principales choses changent par rapport à 2008R2:

  1. La modification côté utilisateur se base sur Excel. WCF – qui n’est en effet pas le moyen le plus facile d’intéragir de manière graphique avec un client final sans développement tiers – a été utilisé pour proposer un addin Excel en VSTO très choupi. Cet addin, destiné aux clients qui maintenaient leur référentiel local de manière autonome, va leur permettre de modifier le référentiel central que vous mettez en place, tout en respectant de potentielles règles métier (celles-ci étant définies dans le client Web). Cet addin est téléchargeable depuis le site MDS (comme Report Builder depuis Report Manager, tiens tiens). Il est puissant puisqu’il permet de créer des entités et de modifier intégralement leur structure et/ou leur contenu si on possède les droits ad-hoc.  (NB: Pour Office 2013, bien télécharger la toute dernière version sur le site de Microsoft en revanche, sinon vous aurez un bug d’affichage assez rédhibitoire )
  2. L’import des données en bloc se fait désormais par des tables de staging par entité (dit autrement une table pour les Produits, les Couleurs de Produit, les Catégories… avec une colonne par information à renseigner, un truc normal quoi), plutôt qu’avec les inutilisables tables clé/valeur de 2008R2 (vous pouvez regarder le tutorial en 2008R2 de l’équpe produit, c’était à vomir original). En plus, les codes des entités sont maintenant auto-générés (oui pour les fans de SSAS Multidim dans MDS on a un code et un libellé par entité). C’est fini, plus de script dans SSIS pour faire de la surrogate. Une fois ces tables remplies de données source, on peut déclencher le processus de chargement en WCF, via une procédure stockée SQL, ou depuis le frontal Silverlight. En cas de présence de l’entité considérée dans le référentiel, c’est la propriété ImportType de la ligne de l’entité dans la table de staging qui gouverne la mise à jour ou pas des données, avec ou sans erreur levée. En fin de chargement, il est bien sûr possible de consulter le résultat de l’import, comme depuis l’addin Excel (et donc les raisons d’un éventuel échec: infraction vis à vis d’une règle métier… etc…).

Excel Conclusion: l’avenir des projets BI?

Un certain volume d’ETL sur les phases amont des projets BI a, à mon avis, vocation à disparaître tant il est anormal que seule la mise en place de solutions décisionnelles  entraîne un effort d’intégration/standardisation de données.

La qualité de données commence dès sa saisie et l’analyse n’est que le sommet de la pyramide. Donc la prochaine fois que vous constituerez un référentiel juste pour la BI en vous alimentant depuis des bases Access/DBase/MySQL gérées par les métier en local, demandez vous si par hasard votre référentiel ne leur serait pas utile, et testez MDS 🙂

[MDS] Master Data Services, pourquoi et comment?

Cela fait quelques mois que l’on parle de l’ajout de Master Data Management dans SQL Server, au travers de Master Data Services (issu du rachat de Stratature). Cependant il semble que le principe et l’utilité du MDM dans une entreprise ne soit pas encore une notion bien appréhendée, d’où l’utilité de ce petit article.


Pourquoi du Master Data Management?

Dans une entreprise, les applications horizontales (Comptabilité, GRH, Ventes, Finance…) disposent souvent de bases de données séparées. Si beaucoup de ces données sont spécifiques, un certain nombre d’entre elles sont communes à l’ensemble de l’organisme et donc dupliquées dans les différents systèmes: ce sont les Master Data. (Les données de ce type les plus connues sont les Clients, les Produits vendus par l’entreprise…)
Comme ces données sont dupliquées et stockées dans des systèmes hétérogènes, il y a un fort risque d’incohérences, et il est difficile d’extraire rapidement une vision unifiée de ce type de données.

Cas extrême: un client d’une entreprise la contacte car il ne reçoit plus ses factures. Le service client vérifie qu’il possède bien la bonne adresse pour ce client dans sa base CRM. Cependant le service de facturation ne possède pas la même vision de cet attribut du client dans l’application de facturation: il y a incohérence difficile à tracer et à résoudre. Sans compter l’image désastreuse si ce cas est généralisé.

Etant très souvent amené à concevoir et alimenter des Data Marts relationnels, la race des consultants BI – dont je fais partie – a souvent maille à partir avec ce genre de problèmes, dont l’entreprise n’était généralement pas consciente avant la centralisation entreprise par les différents Data Marts.

C’est donc du Data Warehousing?

Non mais le processus est très lié. Sans MDM, l’alimentation de chaque Data Mart doit se faire en prévoyant l’application de règles métier strictes en cas de problèmes de cohérence dans les Master Data. C’est un processus lourd qu’il serait souhaitable de ne pas recommencer à chaque Data Mart… L’idée est donc que le MDM devienne la source de Master Data pour toute application désirant connaître la version corporate de la réalité pour les données importantes.

Pour insister sur la parenté avec les entrepôts de données les Master Data sont historisées et représentées conceptuellement sous forme d’entités, disposant d’attributs et de hiérarchies. Ces concepts sont effectivement très proches du Data Warehousing classique, à ceci près que MDS gère aussi la définition de règles de validation dans le modèle, ce qui n’est pas typiquement le cas d’un DW.

Et techniquement?

Master Data Services est avant tout basé sur une base de données SQL Server. Les Master Data sont stockées dans cette base dédiée, dont les tables sont générées automatiquement lors de l’import de données.
Tout le cycle de vie des données (import, versionning, validation, notification, publication) est géré en SQL(le stockage comme le code) bien que les tables au nom doux comme [tbl_3_12_MS] ne doivent pas être utilisées directement: une API est disponible via WCF, API qu’utilise le frontal web de définition d’entités installé avec MDS.

La donnéee stockée peut aussi être récupérée via des vues, qui permettront entre autres d’alimenter des Data Marts.

Conclusion

Master Data Services est le quatrième « Services » (Après Integration, Analysis et Reporting, non Notification ne compte pas!) et de mon point de vue la quatrième « brique BI » de SQL Server. Il va permettre de décorréler la gestion des données sensibles de l’alimentation de Data Marts, tant cette gestion revêt une importance bien plus grande au sein des entreprises.

Intercalé entre les sources et les bases d’analyse, il va permettre aux projets BI de se concentrer sur leur but: fournir des outils d’analyse appropriées sans perdre du temps sur la redéfinition de règles d’alimentation en systèmes hétérogènes.

Reste maintenant à manoeuvrer les leviers nécessaires pour vaincre les réticences politiques qui ne manqueront pas de se faire jour, mais prenons le pari qu’avec une architecture ouverte, reconnue (Stratature), intégrée et une préoccupation du MDM de plus en plus prégnante dans les entreprises, cette nouvelle brique de SQL Server ne tardera pas à s’imposer…