IM InfoSphere Identity Insight, Version 8.0

Paramètres de stockage des données d'attribut volumineuses

Pour permettre au système de stocker et de traiter des données d'attribut volumineuses pour le score, les métadonnées doivent être converties au format UMF (Universal Message Format) et stockées dans les colonnes appropriées.

Utilisez les colonnes ATTR_VALUE et ATTR_LARGE_DATA pour stocker des données d'attribut volumineuses ou non structurées pour les applications d'attribut et de score personnalisées.

Colonne et nom de balise UMF Type de données et taille Obligatoire Explication
ATTR_VALUE varchar(255) (par défaut) redimensionnable jusqu'à 8k Oui Données utilisées en tant que l'un des attributs d'un processus ETL avec les plug-in de score de base.

Si les données sont plus volumineuses que 8k et au format binaire, stockez les données dans le colonne ATTR_LARGE_DATA et créez un identificateur unique pour ces données dans la colonne ATTR_VALUE. L'identificateur ATTR_VALUE est utilisé pour la comparaison et le score. Par exemple, créez un hachage unidirectionnel MD5 (Message-Digest algorithm 5) qui peut être comparé et affiché dans le Visualizer et les rapports.

La taille maximale de la colonne dépend de la base de données. Pour les données binaires supérieures à 255/3 qui doivent être stockées dans ATTR_VALUE, la colonne doit être redimensionnée. Pour des raisons de performance, vous devez penser à régler à nouveau le cache de la base car il est probable que très peu de lignes entrent dans le cache.

ATTR_LARGE_DATA Objet CLOB à utiliser pour les données supérieures à 8k. Non Stockez-les sous forme de données de type caractères. Par exemple, utilisez le codage Base64 des données binaires.

Utilisez cette colonne pour stocker les données d'attribut qui sont trop volumineuses pour la colonne ATTR_VALUE.

ATTR_LARGE_DATA est une colonne de type CLOB (character large object) et peut gérer des données de taille illimitée.

Ces données sont disponibles pour la résolution d'entité. La structure des données doit être connue de l'auteur du plug-in de comparaison personnalisé. Le Visualizer n'affichera pas ces données car le format n'est pas standard et sera différent pour des types de systèmes différents.

Un objet CLOB ne fonctionnera pas aussi bien qu'une colonne varchar car un objet CLOB ne peut pas être mis en cache et nécessite une lecture de disque ; c'est pourquoi ATTR_VALUE est préférable. Si très peu de données d'attribut sont mises en cache à cause de l'augmentation de la taille de ATTR_VALUE, il peut être préférable d'utiliser seulement ATTR_LARGE_DATA pour les données inférieures à 8k afin de s'assurer que les autres attributs non volumineux, comme le genre et DOB, sont mis en cache correctement. Sur ce point, c'est à l'architecte de juger. Pensez à consulter votre administrateur de base de données.

Exemple

Voici un exemple de sortie de hachage MD5 de données binaires volumineuses :
<ATTRIBUTE><ATTR_TYPE>BIOMETRIC-1</ATTR_TYPE><ATTR_VALUE>214b21fc3e040f844a07710b1bb451a0
</ATTR_VALUE><ATTR_LARGE_DATA><![H4sICBRTqkgAA2Zvby50eHQAK0ktLuHlAgDkTqoPBgAAAA==]>
</ATTR_LARGE_DATA></ATTRIBUTE>
Il est probable que les valeurs ATTR_LARGE_DATA réelles soient bien plus volumineuses que dans cet exemple.


Commentaires en retour

Dernière mise à jour : 2009