none
UDT, UDA, UDF c'est très bien , ensuite une structure d'indexe définie par l'utilisateur ? RRS feed

  • Discussion générale

  • Bonjour tous le monde,

    Dernièrement j'ai travaillé beaucoup avec les UDT, UDA et UDF pour des besoins spécifiques. Le dernier cas pratique que je suis en train de traiter est l'indexation d'une base de données images (une hiérarchie de répertoire contenant des fichier .jpeg). En faite, j'ai créer des UDT (C#) pour définir des types complexes tels des histogrames, ensemble d'entier qui héritent (les classes -UDT-) de la classe ArrayList. Finalement ces types servent pour stocker des descripteurs d'images.

     

    Dans SQL SERVER 2008, j'ai crée une base de données dans laquelle il y a la table relationnelle

    DescriptionImage(fileName varchar, histo Histogram)

    L'UDT Histogram est une classe (C#) qui hérite de ArrayList, elle sert a représenter un histogramme qui est un ensemble de couples "{('Bleu',0.5);('Rouge',0.3);('Vert',0.3)}".

    La table DescriptionImage contient 300000 tuples. Je me demande s'il y a moyen de créer un indexe sur l'attribut "histo".

     

    A mon avis, cela m'étonnerais car un UDT est un moyen de sérialiser des données sous une forme binaire, et donc créer un indexe sur un type binaire je ne vois pas trop comment je pourrais faire ...

    Est-il possible, dans ce cas, de créer un indexe définie par l'utilisateur ?


    PhD - Student
    • Modifié OmarioS mercredi 4 août 2010 10:02
    mardi 3 août 2010 14:49

Toutes les réponses

  • Bonjour,

    Un examen sommaire de la doc laisse penser que c'est possible :
    http://msdn.microsoft.com/fr-fr/library/ms131082.aspx l'idée étant apparemment d'implémenter éventuellement soi-même la séralisation pour garantir que la réprésentation binaire a effectivement un sens.

    Le premier problème serait sans doute la pertinence d'un tel index.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    mercredi 4 août 2010 09:50
  • Bonjour,

    Un examen sommaire de la doc laisse penser que c'est possible :
    http://msdn.microsoft.com/fr-fr/library/ms131082.aspx l'idée étant apparemment d'implémenter éventuellement soi-même la séralisation pour garantir que la réprésentation binaire a effectivement un sens.

    Le premier problème serait sans doute la pertinence d'un tel index.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

    Effectivement, la doc parle de la nécessité d'une sérialisation détérministe, et donc le seul moyen de garantir cela est d'utiliser la sérialisation native. Donc cela confirme mes soupçons : le type ArrayList ne peut être sérialisé nativement malgré que les éléments d'une instance de ArrayList sont des objets qui peuvent être sérialisés.

    y aurait il un moyen pour contourner cela ?

    merci d'avance


    PhD - Student
    mercredi 4 août 2010 10:12
  • Humm. Je ne vois pas en quoi seule la sérialisation native serait déterministe. Je suis surpris aussi que ArrayList ne se sérialize pas par défaut (Edit : finalement je suis plutôt surpris d'avoir été surpris !). Il faudrait que j'essaie, je n'ai jamais essayé cela.

    Pour l'instant, ce qui me gène plus est que je ne vois en quoi la présence d'un index sur un "histogramme" permettrait de faciliter les requêtes (en gros cela va juste permettre de tout classer par rapport au premier élement ?) sauf justement peut-être en mettant une valeur calculée en en-tête qui serait représentative de ce que l'on veut.

    Déjà sait on classer un histogramme par rapport à l'autre avec du code .NET ?


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    • Modifié Patrice ScribeMVP mercredi 4 août 2010 14:34 Surpris d'avoir été surpris
    mercredi 4 août 2010 14:18
  • Déjà sait on classer un histogramme par rapport à l'autre avec du code .NET ?

    En faite, si je dispose d'un fonction de similarité entre deux histogrammes (par exemple distance euclidienne) je peux appliquer un algorithme de classification pour classer ces histogrammes

     

    Pour l'instant, ce qui me gène plus est que je ne vois en quoi la présence d'un index sur un "histogramme" permettrait de faciliter les requêtes (en gros cela va juste permettre de tout classer par rapport au premier élement ?) sauf justement peut-être en mettant une valeur calculée en en-tête qui serait représentative de ce que l'on veut.

     

    L'intérêt est que une fois j'ai classé les histogrammes, je peux effectuer des recherches pertinentes (selon la fonction de similarité utilisée) pour retrouver l'histogramme le plus proche.

     

    De façon plus générale, cela serait aussi vrai si jamais j'utilise un autre (que l'histogramme) descripteurs d'images qui sont connus dans la littérature du traitement d'images quitte à définir une mesure de similarité entre deux instances de ce descripteur.

     

     

     


    PhD - Student
    mercredi 4 août 2010 15:03
  • Mais cette fonction produit-elle un résultat propre à un histogramme, résultat que l'on compare ensuite avec celui produit par un autre histogramme ? Si oui, je pense q'en s'assurant que cette valeur est en premier cela devrait marcher.

    Si par contre, cela n'a de sens qu'en prenant deux histogrammes en entrée pour produire une distance alors cela ne pourra pas convenir (sauf à tout précalculer sans doute dans une autre table qui ferait 300000x300000 lignes ?).

    Au pire si "Par conséquent, chaque instance d'un objet UDT ordonné par octet peut avoir une seule représentation sérialisée." veut dire que deux histogrammes identiques ne doivent pas avoir la même représentation, il serait peut-être possible de "tricher" en incluant un "guid d'instance" permettant de garantir cette représentation unique.

    Je ne sais pas ce que fournit la classe CLR comme autres fonctionnalités, mais je me demande si il n'aurait pas être plus simple de stocker les histogrammes sous forme de lignes dans une table...


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    mercredi 4 août 2010 16:10
  • Mais cette fonction produit-elle un résultat propre à un histogramme, résultat que l'on compare ensuite avec celui produit par un autre histogramme ? Si oui, je pense q'en s'assurant que cette valeur est en premier cela devrait marcher

    La fonction de similarité "fs" est une fonction définie par fs : H²-->R+ avec H est l'ensembles des histogrammes et R+ est l'ensemble des nombres réels positifs.

    ensuite, en appliquant un algorithme de classification sur la base de cette fonction, je peux construire (par exemple avec l'algorithme k-means) des ensembles (admettons n ensembles) d'histogrammes similaires. Les couples d'histogrammes dans un même ensemble minimisent fs. chaque ensemble d'histogramme est représenté par la moyenne de ses histogrammes. Dans ce cas la, si je produit milles d'ensembles E1, ... E1000 d'histogrammes, les valeurs de mes indexes seront les 1000 moyennes d'histogrammes.

    Donc pour chercher les k histogrammes les plus  similaires à un histogramme cible Hi, je vais chercher d'abord dans les valeurs des indexes ensuite à les histogrammes référencé par ces indexes.

    Si par contre, cela n'a de sens qu'en prenant deux histogrammes en entrée pour produire une distance alors cela ne pourra pas convenir (sauf à tout précalculer sans doute dans une autre table qui ferait 300000x300000 lignes ?).

    une table avec 300000x300000 lignes, ce n'est pas vraiment une solution efficace : j'envisage de traiter le problème de façon générale. Donc la taille de la table va exploser rapidement en terme de volume.

    Au pire si "Par conséquent, chaque instance d'un objet UDT ordonné par octet peut avoir une seule représentation sérialisée." veut dire que deux histogrammes identiques ne doivent pas avoir la même représentation, il serait peut-être possible de "tricher" en incluant un "guid d'instance" permettant de garantir cette représentation unique.

    Dans mon cas, l'intérêt d'utiliser l'indexe que j'ai "décrit" ci dessus, c'est pour réduire la taille de l'indexe qui au lieu de produire une valeur pour chaque image (300000 en total) je vais produire que 1000 valeurs d'indexe (pour les moyennes d'histogramme). Etant donné que les élément d'un histogramme sont ordonnée, donc pour deux histogrammes identiques je dois avoir une sérialisation identiques : justement c'est déterministe.

    Je ne sais pas ce que fournit la classe CLR comme autres fonctionnalités, mais je me demande si il n'aurait pas être plus simple de stocker les histogrammes sous forme de lignes dans une table...

    C'est peut être vrai, mais je travaille dans le cadre de ma thèse pour répondre à une problématique spécifique et j'utilise SQL SERVER 2008 pour réutiliser des fonctions de bases déjà existante. Pour info, j'ai défini un modèle de traitement de données presque indépendant de celui fournit par SQL SERVER 2008. donc j'ai mes propres opérateur algébriques qui implantent des itérateurs et qui ont une sémantique différente de l'algèbre relationnelle ... bon c'est comme ça que ça fonctionne dans l'académie :)

     

     

     


    PhD - Student
    jeudi 5 août 2010 09:00