Architecture fédérée - Définition
La liste des auteurs de cet article est disponible ici.
Développements actuels et futurs
Actuellement, la norme qui s’impose en matière de SGBDF est conçue par IBM et se nomme DB2 UDB Federated System (supporté par MS SQL server, Oracle et Sybase). Malheureusement, ce système ne supporte pas encore parfaitement l’écriture et est, en général, seulement en lecture seule. L’alternative la plus simple de développement d’une fédération en lecture / écriture (au moins partielle) à l’aide de la technologie existante, semble résider dans le respect absolu des standards relationnels. Dans ce cas, il serait possible d’intégrer différentes bases de données en transférant chacune sur un même modèle de SGBD et en créant notre fédération comme un système de données réparties. L’autonomie des différentes bases de données est conservée car le transfert d’une base de données relationnelle conçue d’une manière standard sur un autre SGBDR ne devrait pas causer de gros problèmes. Le standard SQL-99 intégrant les « triggers » et les fonctions (PL/SQL) permet de créer les conversions et vérifications de contraintes nécessaires au maintien de la fédération. Par contre, l’obligation que tous les membres respectent les standards relationnels semble utopique vu le nombre aberrant de « legacy system » en entreprise.
Si plus de quinze ans après la parution de l’article de Sheth et Larson, aucun véritable produit commercial complet de SGBDF n’existe, cela semble indiquer un sérieux problème avec cette approche : «…plusieurs problèmes restent à résoudre avant que cette approche devienne commercialisable. Ni les aspects de conception (comment construire une vision commune des données partagées), ni les aspects système (où les techniques doivent être adaptées à un environnement distribué) ne sont complètement résolus … L'intégration de bases de données est un problème complexe. Un nombre considérable d'articles en ont étudié différents aspects : il en résulte une multitude de contributions techniques, quelques méthodologies et quelques prototypes. »
La situation actuelle n’a guère changé et l’apparition de l’approche par médiation semble avoir définitivement tué dans l’œuf l’approche par fédération fortement couplée.
Les fédérations fortement couplées
Pratiquement tous les auteurs dans le domaine de la médiation de données attribuent à [Sheth & Larson, 1990] le concept de fédération de données et en général, le concept de fédération se ramène à l’approche fortement couplée. Pourtant, ces auteurs ont pour seul mérite d’avoir synthétisé et catégorisé les différentes approches fédératives existantes à l’époque et d’avoir proposé une architecture de référence pour l’approche fédérée fortement couplée (sans concevoir de système opérationnel). Voici la listes des systèmes existants à l’époque (selon Sheth et Larson) : ADDS, CALIDA, DQS, DDTS, IISS, Mermaid, MRDSM, Multibase, OMNIBASE.
Il s’agit essentiellement du même diagramme que celui présenté par Sheth et Larson. Seule la ligne pointillée a été rajoutée, celle-ci sépare la partie supérieure que nous baptiserons intégrateur et qui est responsable de l’intégration des différentes BD de la partie inférieure que nous appellerons traducteur, qui permet la traduction d’un schéma d’une BD dans un modèle canonique. Il est naturel de concevoir un déploiement de cette architecture avec les traducteurs sur les mêmes hôtes que les SGBD locaux et l’intégrateur sur un hôte particulier. Un tel système peut être baptisé SGBDF pour Système de Gestion de Bases de Données Fédérées et possède de multiples points en commun avec les SGBD traditionnels et répartis. En fait, nous pouvons considérer ces systèmes comme des SGBD répartis pour lesquels les schémas internes sont des SGBD traditionnels. Il est donc naturel de concevoir un SGBDF comme une évolution des SGBD répartis.
Tous les systèmes de type fédéré fortement couplé suivent d’une manière plus ou moins heureuse l’architecture générique établie par Sheth et Larson. Cette architecture est composée essentiellement de processeurs et de schémas. Voici les différentes catégories de ces composantes dégagées par les deux auteurs et se retrouvant dans le diagramme.
Processeurs de transformations
Ces processeurs traduisent une commande effectuée dans un langage (ex.: SQL) en une requête dans un autre langage (ex. : CODASYL). Pour pouvoir effectuer cette tâche, ils offrent une vision transparente des modèles de données. Ils convertissent donc un schéma conçu selon un modèle en un autre (ex. : modèle réseau en modèle relationnel et vice versa).
Processeurs filtres
Ces processeurs vérifient les commandes envoyées à un processeur ou les résultats retournés par un processeur pour s’assurer qu’ils ne violent pas des règles d’intégrité syntaxique et/ou sémantique. Ces processeurs peuvent s’occuper également de la vérification des droits d’accès aux données. Concrètement, ils sont responsables du maintien de la fédération en offrant des mécanismes explicites permettant de résoudre les contraintes du schéma global.
Processeurs de constructions
Ces processeurs divisent les commandes ou les données envoyées par un processeur en commandes ou données destinées à plusieurs processeurs. Ou encore, à l’inverse, intègrent des commandes ou des données envoyées par plusieurs processeurs. Les tâches pouvant être accomplies par ces processeurs sont les suivantes : intégration de schémas, négociation de protocoles entre processeurs, optimisation de requêtes et décomposition des requêtes pour différents processeurs, gestion des transactions (atomicité et concurrence). Processeurs d’accès : Ces processeurs acceptent les commandes effectuées par différents processeurs et manipulent directement les données en fonction des commandes. Ils correspondent à des SGBD locaux.
Schémas locaux
Ils correspondent aux schémas des bases de données participantes, exprimés dans leurs modèles de données propres (relationnel, réseau, hiérarchique). Schémas des composants : Ils correspondent aux schémas des bases de données participantes une fois que les schémas sont traduits dans un modèle de données commun (pivot). Schémas d’exportation : Ils correspondent à la portion des schémas des composants destinés à l’intégration au sein de la fédération.
Schéma fédéré
Il s’agit du schéma de la fédération proprement dit.
Schémas externes
Équivalents aux schémas externes de l’architecture Ansi/Sparc mais au niveau de la fédération.
