Introduction OLEDB


OLE DB est une nouvelle interface de bas niveau qui introduit une notion d'accès " universel " aux données. C'est-à-dire que l'interface OLE DB n'est pas réservée à ISAM, Jet, ni même aux sources de données relationnelles, mais qu'elle est capable de traiter n'importe quel type de données indépendamment de leur format ou de leur méthode de stockage. Dans la pratique, cette souplesse signifie que vous pouvez accéder aux données résidant dans un tableur Excel, dans des fichiers texte ou même sur un serveur mail comme Microsoft Exchange.

Dans Visual Basic 6.0, vous augmentez la souplesse de OLE DB par l'intermédiaire du modèle ADO, l'interface programmation vers OLE DB. Vous pouvez même créer vos propres fournisseurs OLE DB dans Visual Basic.

OLE DB et ADO

Les interfaces complexes de OLE DB ne permettent pas d'y accéder directement à partir de Visual Basic. En revanche le modèle ADO encapsule et rend virtuellement accessibles toutes les fonctionnalités de OLE DB.

Fournisseurs OLE DB

Visual Basic vous permet effectivement de créer votre propre fournisseur OLE DB en affectant à la propriété DataSourceBehavior la valeur vbOLEDBProvider dans un projet de DLL ActiveX. L'événement OnDataconnection devient ainsi disponible pour indiquer qu'une connection a été réalisée.

Au fur et à mesure que les sociétés commencent à mettre en oeuvre de nouveaux systèmes d'informations basés sur le Web, les technologies d'accès aux données doivent répondre à de nouveaux scénarios, plus complexes. Alors que la précédente génération d'applications n'accédait aux données que sur mainframe, désormais les développeurs qui créent des applications Web doivent pouvoir accéder à des données distribuées dans toute leur organisation, sur des plates-formes matérielles, sous des systèmes d'exploitation et dans des magasins de données différents.

Les informations importantes d'une société sont disponibles dans des sources et des magasins de données très variés, parmi lesquels ceux de la liste suivante:

  • CICS (Customer Information Control System
  • IMS (Information Management System)
  • VSAM (Virtual Sequential Access Method)
  • Fichiers AS/400
  • Bases de données relationnelles (telles que Microsoft® SQL Server et Oracle)
  • Tableurs personnels (tels que Microsoft® Excel)
  • Bases de données personnelles (telles que Microsoft Jet)
  • Plans de projet
  • Documents de traitement de texte
  • Fichiers texte
  • Courrier électronique

Tous ces types de données peuvent être nécessaires à votre application d'entreprise; or, chacun est stocké dans un format différent, selon une méthode de stockage de données différente, et accessible d'une façon fondamentalement différente.

L'idéal ne serait-il pas une méthode commune permettant d'accéder à des données stockées dans des formats différents? Vous pourriez alors utiliser la même technologie pour accéder à une base de données relationnelle, à une base de données mainframe, à une feuille de calcul Excel et à un document de texte.

Du point de vue de la conception d'application, l'utilisation efficace de différents magasins de données est plus compliquée qu'elle ne semble. Non seulement il vous faut coder différentes méthodes d'accès aux données, mais encore toutes les interfaces de programmation d'application (API), les interfaces COM, les interfaces Automation et les interfaces procédurales vous empêchent d'utiliser les transactions comme méthode fiable pour effectuer des modifications. Dans ce genre de situation, il est parfaitement impossible d'empaqueter une transaction.

Une solution consiste à placer tous les types de données différents dans un même magasin de données, comme par exemple une base de données relationnelle. Bien que cette approche vous permette une méthode commune d'accès aux données, elle s'avère irréaliste pour un certain nombre de raisons. Premièrement, vous devez déplacer d'énormes quantités de données vers la base de données commune et récrire tous les outils utilisateur pour accéder aux données uniquement sur l'emplacement commun. Deuxièmement, chaque utilisateur doit être formé à l'utilisation des nouveaux outils. Troisièmement, la plupart de ces données ne vous appartiennent probablement pas, ce qui ne simplifie pas les problèmes de propriété et de contrôle. Quatrièmement, une base de données relationnelle, comme toute autre technologie unique de stockage de données, n'est pas le meilleur moyen de gérer tous les types de données car la structure de données appropriée dépend des données dont il s'agit et de la façon dont celles-ci sont utilisées et gérées. Accès universel aux données avec OLE DB et ADO

Si la solution n'est pas un seul magasin de données pour tous les types de données, quelle possibilité reste-t-il? La solution permettant d'accéder à différents types de données dans toute l'entreprise consiste à utiliser OLE DB comme fournisseur de données et ADO (ActiveX® Data Objects) comme technologie d'accès aux données. L'accès aux données basé sur OLE DB et ADO convient à une vaste palette de besoins de la conception d'applications, des petits processus monopostes aux applications Web à grande échelle.

OLE DB est un ensemble complet d'interfaces COM (Component Object Model) capable d'offrir un accès uniformisé aux données stockées dans différentes sources d'informations. Ces interfaces, à leur tour, sont améliorées pour prendre en charge de façon spécifique les fonctionnalités d'accès propres à chaque source de données. Les interfaces OLE DB permettent à un magasin de données individuel d'exposer facilement ses fonctions natives.

OLE DB convient aux sources de données relationnelles et non relationnelles, y compris VSAM et les fichiers AS/400 sur mainframe, les données dans les zones CICS, les bases de données hiérarchiques IMS et de nombreux autres magasins de données, comme le montre l'illustration suivante.

Les composants OLE DB sont formés de fournisseurs de données qui exposent les données, de consommateurs de données qui utilisent ces données et de composants de service qui traitent et transportent les données (comme par exemple des processeurs de requêtes, des moteurs de curseur et des services de gestion).

Les interfaces OLE DB et ADO étant basées sur COM, elle prennent en charge toute une gamme de services intégrés (parmi lesquels les transactions, la sécurité et la mise en file d'attente des messages) afin de pouvoir répondre aux scénarios d'accès aux données d'application les plus divers. Les développeurs bénéficient ainsi d'un support riche et homogène de fonctionnalités de conception d'accès aux données. Les méthodes, propriétés et événements des composants sont utilisables uniformément par tous les langages de développement d'applications et par tous les produits Microsoft® Office.

Le caractère universel de cette approche apparaît clairement dans la liste suivante, qui présente tous les langages Microsoft de développement d'applications et de script capables d'utiliser les technologies d'accès aux données OLE DB et ADO, basées sur COM.

  • Microsoft® Visual Basic®
  • Microsoft® Visual C++®
  • Microsoft® Visual J++
  • Microsoft® Visual FoxPro®
  • VBScript (y compris les extensions Active Server Pages)
  • JScript (y compris les extensions Active Server Pages)
  • Visual Basic pour Applications (y compris l'ensemble de Microsoft Office)

Il est important de noter que la technologie OLE DB avec ADO apporte un avantage significatif en matière de performances et de coût de développement par rapport à ODBC (Open Database Connectivity), et ce par deux aspects. Tout d'abord, les pilotes ODBC doivent mettre en oeuvre un moteur relationnel SQL pour exposer les données non relationnelles. Ensuite, les services tels que les curseurs et le traitement de requêtes doivent être mis en oeuvre par chacun des pilotes ODBC. Cela se traduit par des coûts de développement pour le pilote ODBC ainsi que par une consommation de ressources sous la forme de nombreux moteurs de curseur et processeurs de requêtes. Avec OLE DB, les composants de service réutilisables gèrent les routines de traitement pour toute une gamme de fournisseurs de données.

Pour permettre l'intégration des données ODBC dans tous les autres types de données, Microsoft offre un fournisseur de données OLE DB-ODBC, ce qui assure la prolongation de la prise en charge de la gamme étendue des pilotes ODBC de base de données relationnelle disponibles aujourd'hui. Vous pouvez ainsi accéder aux données par l'intermédiaire d'OLE DB avec les mêmes performances que si vous y accédiez par ODBC.

Votre application utilisera probablement ADO pour s'adresser à différents magasins de données par l'intermédiaire des fournisseurs OLE DB existants, bien que vous ayez la possibilité d'utiliser directement les interfaces OLE DB. En règle générale, il n'est pas nécessaire de développer des fournisseurs OLE DB personnalisés. Cependant, si votre application d'entreprise requiert un accès aux données spécial qui n'est pas actuellement pris en charge par un fournisseur OLE DB existant, la meilleure option technique consiste à écrire un fournisseur de données personnalisé avec OLE DB.

Remarque Du fait que les interfaces OLE DB utilisent des pointeurs, des structures et une gestion explicite de la mémoire pour optimiser la façon dont les données sont exposées et partagées entre les composants, elles ne peuvent pas être appelées directement à partir d'applications ou de composants Visual Basic ou Visual J++. De plus, le codage direct dans les interfaces OLE DB impose une période d'apprentissage non négligeable. En règle générale, vous devez utiliser ADO (ActiveX Data Objects) pour accéder aux magasins de données OLE DB et les manipuler.

En utilisant les fournisseurs de données OLE DB avec ADO, vous pouvez:

  • accéder à la plupart des magasins de données à l'aide d'une technologie unique et homogène;
  • tirer parti des outils de développement les plus récents;
  • réduire les besoins en formation et assistance;
  • réduire les coûts de mise en oeuvre et de maintenance.

En général, le concept d'accès universel aux données recouvre un modèle d'application facile à créer et peu onéreux utilisant une approche cohérente d'accès aux données OLE DB avec ADO, capable de fonctionner avec toutes les sources de données d'une société.

Modernisation de votre application avec OLE DB et ADO Voyons brièvement comment utiliser OLE DB et ADO pour moderniser une application existante. Supposons que votre application accède à des données d'un magasin de données ISAM (Indexed Sequential Access Method) propriétaire et exploite également des données d'une base de données relationnelle Oracle utilisant l'interface de programmation d'application (API) d'Oracle. Cette application est difficile à écrire, à maintenir et à étendre du fait des deux interfaces propriétaires et du code nécessaire pour développer des fonctionnalités qui ne sont pas proposées par les différents types de magasins de données (par exemple, l'absence de processeur de requêtes dans ISAM). Si votre application nécessite ensuite un accès à des données SQL Server, il vous faut encore ajouter une troisième interface.

La première étape pour adapter votre application consiste à remplacer ces API propriétaires par des fournisseurs de données OLE DB et par ADO (ActiveX Data Objects). Vous placez un fournisseur de données OLE DB devant chaque magasin de données et vous utilisez ADO pour accéder à ces données selon une approche commune. L'application est désormais plus simple à écrire car elle n'utilise qu'une seule interface, et elle est plus polyvalente car plus facile a étendre à d'autres magasins de données.

À ce stade, votre application dispose toujours de l'interface utilisateur et de certains services de gestion d'origine. Elle possède toujours le composant curseur client, car celui-ci continue à s'adresser à certains types de données, telles que les données SQL, qui pourraient ne pas prendre en charge le défilement arrière, et un processeur de requêtes pour effectuer des requêtes sous HTML.

L'étape suivante consiste à ajouter un processeur de requêtes, qui dans ce cas est un composant de service OLE DB. Lorsque l'application s'adresse à un fournisseur de données qui prend en charge les requêtes, comme par exemple une base de données relationnelle, elle peut s'adresser directement à ces données SQL par ADO. Lorsque l'application s'adresse à des données ISAM, qui ne disposent pas de processeur de requêtes SQL, elle le fait toujours par ADO mais le nouveau processeur de requêtes est appelé sur demande de l'application afin de mettre en oeuvre les requêtes. Ceci est important pour un certain nombre de raisons. Placer ce processeur de requêtes en un autre lieu signifierait que chaque application devrait écrire son propre processeur de requêtes pour chaque magasin de données. Dans le cadre d'une stratégie générale, vous pouvez insérer différents processeurs de requêtes pour prendre en charge différentes syntaxes ou fonctions.

Pourquoi ne pas retirer de l'application les services de gestion? Les services de gestion ne varient généralement pas d'une application à l'autre. Plutôt que de recréer dans chaque application des services de gestion similaires, vous pouvez les mettre en oeuvre sous la forme de composants réutilisables. Selon le modèle OLE DB, les services de gestion ne doivent pas nécessairement se trouver dans l'application. Au contraire, ils peuvent rester de côté et, par des notifications prises en charge par OLE DB pour coordonner différents utilisateurs, signaler aux autres composants l'apparition de certains événements précisés.

L'architecture de votre application constitue désormais un ensemble moderne, souple et réutilisable de composants logiciels coopératifs, faciles à modifier pour satisfaire à de futurs besoins en matière d'accès aux données.



Dernière mise à jour le mardi 30 novembre 1999



Afficher: