La Technologie IDBD :

Interface Directe avec les Bases de Données



Présentation Technique

Objectifs et Avantages de l'IDBD

Synthèse. L'Interface Directe avec les Bases de Données (IDBD) est une technologie avancée permettant d'accéder aux bases de données. Cette technologie de pointe, développée par StatSoft, permet d'interfacer directement des données externes situées sur des serveurs distants avec les fonctionnalités analytiques des produits de la gamme STATISTICA. La technologie IDBD a été développée pour faciliter l'accès aux données contenues dans des bases de données gigantesques, en utilisant un processus direct ne nécessitant pas la création de copies du fichier de données en local. L'IDBD augmente significativement les performances de STATISTICA ; elle est particulièrement adaptée pour les tâches importantes de data mining et d'analyse exploratoire des données.

La source de gains de performances de l'IDBD. Les gains en rapidité de la technologie IDBD - par rapport à la manière traditionnelle d'accéder aux données - ne vient pas simplement du fait que l'IDBD permet à STATISTICA d'accéder directement aux données contenues dans des bases de données sans avoir à les importer au préalable ni à créer de copie du fichier en local. Son architecture "multi-tâches" (d'un point de vue technique, en traitement asynchrone et en calcul distribué) permet également de gagner significativement en rapidité puisque l'IDBD va utiliser les ressources des différents ordinateurs du serveur de bases de données (et ses différentes CPU) pour exécuter les opérations des requêtes, extraire les enregistrements souhaités et les envoyer à l'ordinateur où STATISTICA est installé, tout en permettant à STATISTICA de traiter ces enregistrements à mesure qu'ils arrivent.

Compatibilité avec les logiciels STATISTICA

La technologie IDBD peut être utilisée à la fois avec les versions bureautiques et Entreprise des logiciels de la gamme STATISTICA et s'intègre parfaitement avec l'architecture Client-Serveur de WebSTATISTICA (vous pouvez envoyer vos requêtes par l'intermédiaire du Web et les données vont être traitées de façon asynchrone par les ordinateurs de WebSTATISTICA Server eux-même connectés aux ordinateurs du serveur de la base de données (tiers suivant) qui vont se charger d'exécuter les requêtes). L'IDBD est également optimisée pour une intégration efficace avec STATISTICA Data Miner qui permet d'utiliser plusieurs sources de données IDBD en entrée.

Architecture et Accès par Programmation

La technologie IDBD est mise en oeuvre autour d'un objet COM qui englobe un objet Microsoft ActiveX Data Object (ADO) Recordset et implémente une fraction de l'interface COM des Spreadsheet de la bibliothèque d'objets de STATISTICA 6. Ceci est rendu possible dans la mesure où toutes les Analyses de STATISTICA 6 accèdent aux données de la Spreadsheet source par l'intermédiaire de l'interface de la Spreadsheet (en fait, l'interface de l'InputSpreadsheet, qui dispose d'une partie des méthodes de l'interface Spreadsheet. Cette interface InputSpreadsheet est habituellement cachée dans l'Explorateur d'Objets mais vous pouvez la faire apparaître en cliquant avec le bouton droit de la souris dans l'Explorateur d'Objets et en sélectionnant la commande "Afficher les Membres Cachés"). Par conséquent, pour une Analyse STATISTICA, l'IDBD est identique à une Feuille de données (Spreadsheet). En fait, les utilisateurs expérimentés de STATISTICA ont la possibilité d'englober toute source de données autour d'une interface InputSpreadsheet, et réaliser des Analyses STATISTICA dessus par programmation grâce au Modèle-Objet de STATISTICA 6.

En arrière-plan, l'objet englobant la feuille de données doit réaliser certaines étapes pour que les Analyses puissent se dérouler efficacement. Par exemple, si une Analyse a besoin de connaître le nombre d'observations d'un Ensemble d'Enregistrements avant que cette information ne soit connue, une requête distincte de "comptage" sera exécutée de façon synchrone (c'est-à-dire que l'analyse devra attendre que la requête de comptage renvoie les informations nécessaires avant de pouvoir poursuivre) et les résultats seront renvoyé à l'analyse, ou une limite supérieure arbitraire d'observations sera renvoyée immédiatement. Vous pouvez configurer ce paramétrage dans l'onglet Interface Directe avec les Bases de Données de la boîte de dialogue des options de STATISTICA. En outre, si vous utilisez un curseur de type 'suivant uniquement' (voir ci-dessous) et que l'Analyse doit effectuer plusieurs passages sur les données ou qu'elle accède aux données de façon aléatoire, toute requête sur une observation antérieure (ligne) oblige l'IDBD à requêter à nouveau la base de données et à avancer le curseur jusqu'à l'observation souhaitée, puisque le curseur ne peut pas revenir en arrière. L'Analyse va simplement attendre la fin du processus et que les données demandées lui soient transmises.

Il existe deux grands types d'interfaces dans la Bibliothèque de Type IDBD. L'interface DBTable offre un accès par programmation au Document IDBD, de la même manière que les interfaces Macro, Graph, et Spreadsheet donnent accès aux Macros, Graphiques, et Feuilles de Données STATISTICA. En plus des méthodes et propriétés standard des documents (Visible, Activate, Close, etc...), elle donne accès à toutes les options spécifiques de l'IDBD (type de curseur, position, chaîne de la requête, etc...). Sa propriété "Spreadsheet" en lecture seule renvoie l'enveloppe de la Spreadsheet autour de l'Ensemble d'Enregistrements de l'ADO.

La seconde interface est DBSpreadsheet. Cette interface est utilisée en interne par l'IDBD pour créer l'objet enveloppant la Feuille de Données (Spreadsheet), et peut également être utilisée par des utilisateurs écrivant leurs propres macros ou programmes, bien que dans la plupart des cas, l'interface DBTable soit suffisante et utilise elle-même un objet DBSpreadsheet. Cette interface possède deux méthodes, Open et CreateNew. Open exécute la requête et ouvre un ADO Recordset. Elle crée un objet enveloppant la Feuille de Données et y attache l'ADO Recordset, puis renvoie cet objet Spreadsheet. CreateNew crée un objet enveloppant la Feuille de Données qui n'est pas attaché à un Recordset et donc n'est pas utilisable jusqu'à ce que vous appeliez sa méthode "SetRecordset" pour y attacher un objet ADO Recordset de votre création.

Forum Utilisateurs - Foire Aux Questions

Exécutez vos analyses depuis votre navigateur Web STATISTICA Base offre une gamme complète de statistiques indispensables dans un logiciel convivial alliant la performance, la puissance et la facilité d'utilisation des logiciels de la gamme STATISTICA.

Comment fonctionne l'IDBD ?

L'IDBD crée un objet mettant en oeuvre l'interface COM de la feuille de données STATISTICA et enveloppant un objet Microsoft ADO Recordset. Puisque toutes les analyses de STATISTICA 6 accèdent aux données de la feuille de données d'origine par cette interface, cet objet (enveloppe) est semblable à toute Feuille de Données du point de vue de l'Analyse.

Pourquoi l'IDBD n'affiche parfois qu'une seule observation quand je sélectionne un nombre d'enregistrements supérieur à 1 dans l'Aperçu des n premiers enregistrements ?

Lorsque vous utilisez un curseur de type 'suivant uniquement', l'IDBD n'avance pas le Recordset au delà de la première observation (ligne), sans quoi les n premières lignes seraient perdues et si une Analyse avait requêté ces données, elle devrait être exécutée à nouveau. L'option "Aperçu des n premiers enregistrements" s'applique uniquement avec un curseur statique.

Quel est le but de la méthode "nombre d'observations" dans la boîte de dialogue des options de STATISTICA ?

En fonction des options choisies, le nombre exact d'observations est parfois encore inconnu lorsqu'une analyse a besoin de cette information. Si c'est le cas, une des deux options suivantes va s'appliquer, selon le paramétrage de cette option. Soit une requête distincte de "comptage" sera exécutée, soit une limite supérieure arbitraire, personnalisée sera renvoyée à l'Analyse.

Dans quel cas le nombre d'observations exact ne peut être connu ?

Le nombre exact d'observations est inconnu dans les cas suivants :

    a) En utilisant un curseur de type 'suivant uniquement' et que vous n'êtes pas encore arrivé(e) à la fin
    b) En utilisant un curseur statique avec une requête et/ou une récupération asynchrone et que la requête et/ou la récupération n'est pas encore terminée.

Lorsque vous utilisez un curseur statique avec une requête et une récupération synchrones, le nombre d'observations est connu dès l'exécution de la requête.

Quelles sont les avantages et inconvénients de l'option "Nombre d'observations déterminé automatiquement" ?

Lorsque le nombre d'observations n'est pas connu mais qu'une analyse requiert cette information, une requête de "comptage" distincte est exécutée et l'analyse attend le résultat. Si la requête est complexe, le processus peut être lent. En outre, si des modifications ont été apportées dans la base de données entre le moment où vous avez exécuté votre première requête et le le moment où la requête de "comptage" est exécutée, les résultats pourront être incohérents ; c'est-à-dire que si quelqu'un a ajouté ou supprimé des enregistrements, le nombre d'enregistrements dans votre curseur ne sera pas cohérent avec le nombre d'enregistrements reporté dans l'analyse. En revanche, si la requête n'est pas trop complexe et que la base de données n'a pas été modifiée, l'avantage est vous pouvez obtenir le nombre d'observations exact sans avoir à utiliser un type de curseur plus lent pour obtenir la même information.

Quelles sont les avantages et inconvénients de l'option "Nombre d'observations supposé inférieur à [x]" ?

Cette méthode évite d'exécuter une requête distincte pour déterminer le nombre d'observations en renvoyant systématiquement une constante pour le nombre d'observations, ce qui est beaucoup plus rapide. Si l'Ensemble d'Enregistrements (Recordset) comporte en fait davantage d'observations, les observations au delà de cette limite seront ignorées dans les analyses. S'il existe moins d'observations que spécifié, les observations attendues par l'analyse, mais qui n'existent pas, seront traitées comme des données manquantes. S'il existe vraiment beaucoup moins d'observations dans le Recordset que la limite supérieure indiquée, l'analyse va perdre du temps en cherchant à traiter des observations qui n'existent pas.

Qu'est ce qu'un curseur ?

Un curseur est une structure de données qui stocke les résultats d'une requête. Le type de curseur détermine la fonctionnalité disponible. Certains curseurs vous permettent d'avancer (vers l'avant) dans les résultats de votre requête, tandis que d'autres vous permettent d'avancer et de reculer. Les principaux types de curseurs sont statiques, dynamiques, suivant-uniquement et keyset. L'Interface Directe avec les Bases de Données de STATISTICA est compatible avec les curseurs de type 'suivant-uniquement' et statique.

Qu'est-ce qu'un curseur statique?

Un curseur statique permet un déplacement vers l'avant ou vers l'arrière dans les données, et permet ainsi un accès aléatoire aux données. Ce type de curseur constitue une "photographie" des résultats de votre requête - les enregistrements modifiés, ajoutés, ou supprimés de la base de données après que le curseur ait été alimenté, ne seront pas visibles. Un curseur statique, côté serveur, peut mettre un poids énorme sur le système de base de données, voire le saturer. Un curseur côté client est toujours statique. Si une analyse ou une autre occurence de l'IDBD nécessite un accès aléatoire aux données ou plusieurs passages dans les données, ce type de curseur peut être nécessaire.

Qu'est-ce qu'un curseur de type 'suivant uniquement' ?

Le curseur de type 'suivant-uniquement' (également appelé 'vers l'avant uniquement') est le curseur le plus élémentaire ; il permet uniquement d'avancer (vers l'avant) dans les résultats de votre requête. Après être passé à l'enregistrement suivant, l'enregistrement précédent n'est plus disponible dans le curseur. Ce type de curseur donne un accès rapide aux données, et utilise un minimum de ressources au niveau du système de la base de données. Dans le contexte de l'IDBD, si un utilisateur ou une analyse doit effectuer plusieurs passages sur les données ou doit y accéder de façon aléatoire, la requête devra être réexécutée pour revenir à un enregistrement précédent. Si des enregistrements sont modifiés, ajoutés, ou supprimés dans la base de données pendant ce laps de temps, cette requête (réexécutée) pourra produire des données différentes ou un nombre différent d'enregistrements. Si une analyse ou une occurence particulière de l'IDBD nécessite un seul passage vers l'avant dans vos données, ce type de curseur sera vraisemblablement le plus rapide.

Qu'est-ce qu'un curseur 'côté client' ?

Le curseur reste sur la machine client (de l'utilisateur), avec le Microsoft ActiveX Data Objects (ADO) Cursor Engine. Cela signifie que tous les enregistrements récupérés par la requête sont copiés en local sur la machine de l'utilisateur. Un curseur côté client est toujours un curseur statique.

Qu'est-ce qu'un curseur 'côté serveur' ?

Le curseur reste sur le serveur de la base de données. Le nombre d'enregistrements défini par la "taille du cache" est copié en local sur la machine de l'utilisateur, tandis que les autres demeurent sur le serveur. Dès qu'un enregistrement qui n'est pas présent dans le cache local est demandé, un nouvel ensemble d'enregistrements est copié depuis le serveur vers la machine cliente. Ce type de curseur peut placer des contraintes considérables sur le système de la base de données, dans la mesure où ce dernier doit stocker les résultats de toutes les requêtes de ce type.

Quel est le meilleur type et la meilleure position du curseur ?

La réponse à cette question dépend de nombreux facteurs, comme la manière dont vous envisagez d'utiliser vos données, la fréquence à laquelle les données de la base de données que vous utilisez sont modifiées , etc..., et il n'existe donc pas de réponse "universelle". D'une manière générale, le curseur le plus rapide se trouve du côté du serveur, avec un type 'suivant-uniquement', mais si vous avez besoin d'effectuer plusieurs passages ou d'accéder aux données de façon aléatoire, les multiples requêtes nécessaires (réexécutions) pourront dégrader considérablement les performances, et les données pourront changer d'un passage à l'autre. Un curseur côté client avec une requête et une récupération asynchrones est généralement très performant, permet un accès aléatoire aux données, et les données ne changent jamais en cours d'analyse. Sachez cependant que tous les enregistrements récupérés par la requête sont copiés sur votre machine en local.

Peut-on utiliser un curseur de type Keyset ou Dynamique avec l'IDBD ?

Ces types de curseur, qui sont disponibles avec l'ADO, ne sont pas compatibles avec l'IDBD. Ces types de curseurs permettent notamment de mettre à jour la base de données, ou de voir les modifications apportées par d'autres utilisateurs. Toutefois, ces fonctionnalités ne sont pas nécessaires pour l'IDBD puisque l'IDBD n'a pas vocation à mettre à jour la base de données. En outre, les fonctionnalités supplémentaires apportées par ces types de curseurs les rendent beaucoup plus lents que les curseurs de type 'suivant-uniquement' et statique. Vous pouvez toutefois utiliser ce type de curseur par programmation en utilisant le Modèle-Objet de l'IDBD.

Qu'est-ce que la "taille du cache" ?

Lorsque vous utilisez un curseur côté-serveur, le nombre d'enregistrements est placé dans le cache de la machine cliente. Si vous faites appel à des enregistrements absents du cache local, le Recordset ADO doit aller chercher d'autres données depuis la base de données distante.

Qu'est-ce qu'une "requête asynchrone" ?

L'IDBD n'a pas besoin d'attendre la fin de la requête pour redonner la main à STATISTICA. Rien de l'ensemble d'enregistrements (Recordset) récupéré n'est connu tant que la requête n'est pas terminée ; en revanche, dès la fin de la requête, le nombre de champs (variables) est connu, ainsi que leurs noms. En fonction du type de curseur, le nombre d'enregistrements (observations) peut également être connu. À la fin de la requête, les enregistrements individuels peuvent être récupérés à partir du curseur. Lorsque vous utilisez cette fonctionnalité, vous pouvez continuer à utiliser STATISTICA, voire même commencer une analyse sur cette IDBD avant même la fin de la requête. Naturellement, si vous commencez une analyse avant la fin de la requête, l'analyse elle-même devra attendre que la requête soit terminée pour pouvoir s'achever. Pour toutes les requêtes sauf les plus simples, il est conseillé d'utiliser cette option.

Qu'est-ce qu'une "récupération asynchrone" ?

La "récupération" est un processus qui va copier tous les enregistrements sur la machine cliente en local ; par conséquent, cette option ne s'applique que lorsque vous utilisez un curseur au niveau du client. Lorsque vous utilisez ce type de curseur, ADO exécute la requête spécifiée en arrière-plan et ouvre un curseur interne de type 'suivant uniquement'. Il effectue un passage complet avec ce curseur en copiant tous les enregistrements sur la machine en local. Lorsque cette étape est réalisée de manière synchrone, toute autre opération est suspendue jusqu'à ce que l'intégralité des enregistrements soit transféré au client. Si cette étape est réalisée de manière asynchrone, la récupération s'effectue dans un canal d'exécution distinct, ce qui permet de poursuivre le traitement. Les enregistrements sont disponibles dès qu'ils sont récupérés, et les demandes portant sur les enregistrements qui n'ont pas encore été récupérés sont "bloquées" (en attente) jusqu'à leur récupération. Ainsi, avec cette option, l'IDBD n'attend pas que tous les enregistrements soient copiés sur la machine en local avant de redonner la main à STATISTICA. Vous pouvez donc continuer à utiliser STATISTICA, voire même commencer une analyse sur cette IDBD avant que les enregistrements ne soient tous récupérés. Une analyse portant sur un Recordset en cours de récupération n'aura besoin d'attendre que si des enregistrements qui n'ont pas encore été récupérés sont nécessaires. Hormis pour des requêtes qui ne vont récupérer que quelques enregistrements, cette option est recommandée, puisque la copie de centaines de milliers d'enregistrements sur votre machine en local de manière synchrone va occuper STATISTICA jusqu'à la fin du transfert.

Pourquoi l'option "nombre maximum d'enregistrements à renvoyer avec la requête" ne fonctionne pas toujours ?

Cette option est transmise à ADO, qui ne la met pas véritablement en oeuvre, mais qui la transmet au fournisseur OLE DB. À l'heure actuelle, cette fonctionnalité est disponible pour les pilotes OLE DB Provider pour SQL Server, SQL Server ODBC Driver, ainsi que pour les pilotes OLE DB Provider pour Oracle et ODBC Driver pour Oracle.

Je veux créer mon porpre objet ADO Recordset par programmation et l'attacher à une session d'IDBD pour réaliser une analyse STATISTICA dessus. Est-ce possible ? P>Oui. Utilisez la méthode DBSpreadsheet CreateNew, qui renvoie un objet Feuille de Données (Spreadsheet), et appelle la fonction SetRecordset de cet objet pour l'attacher à un ADO Recordset existant. Vous pouvez également utiliser la propriété Spreadsheet de l'interface DBTable pour obtenir la feuille de données et définir le Recordset dessus.

J'écris du code STATISTICA Visual Basic et j'accède à une base de données par l'interface de type feuille de données de l'IDBD. Certaines méthodes Spreadsheet semblent échouer systématiquement. Pourquoi ?

Toutes les méthodes/propriétés de l'interface Spreadsheet ne sont pas implémentées sur la feuille de données IDBD. La plupart d'entre elles n'auraient aucun sens ou ne pourraient pas être mises en oeuvre. D'une manière générale, vous ne pouvez pas appeler de méthode ni de propriété de la feuille de données pour modifier les données de la feuille de données ; les données sont en lecture seule.

Haut de la Page