É quivalence aux Objets dans un SGBD

4.4.1 Modèles finals

Après avoir réalisé le modèle objet, dont la construction fait l’objet d’une partie importante de ce chapitre (§ 4.5.3.4, p.124), nous nous sommes inspiré de la méthode Merise [Collongues_89,Tardieu_91], pour réaliser leMCDdu système, dont le rapport figure en Annexe 6.4, p.195.

Deux heuristiques assez simples nous ont ensuite guidé dans la répartition des méta-données dans deux ensembles (le modèle Merise ne s’intéresse pas beaucoup aux problèmes de distribution et de réplication des données) :

1. isoler les données nécessaires à l’ensemble des serveurs de celles qui peuvent rester locales ;

2. assurer un minimum de redondance qui minimise les effets d’une panne locale. L’application de ces heuristiques nous a ainsi conduit à concevoir la méta-base correspondante comme l’union de deux bases attachées (selon la terminologie MS-Access) :

1. une première base, répliquée sur l’ensemble des serveurs, grâce aux

mécanismes de synchronisation intrinsèques, et qui implémente la première heuristique ;

2. une seconde base qui comporte les données spécifiquement locales au serveur. Cette répartition remplit les objectifs classiques des bases fédérées [Gardarin_90] :  indépendance à la localisation : permettre aux utilisateurs de consulter

n’importe quel document sans qu’ils n’aient besoin de savoir s’il est local ou distant ;

 indépendance à la fragmentation : favoriser les accès locaux en divisant les relations en un ensemble de sous-relations (fragmentation verticale) et en stockant sur chaque site l’ensemble des données nécessaires à son fonctionnement (fragmentation horizontale) ;

 indépendance à la duplication : dupliquer sur chaque serveur les informations nécessaires à son bon fonctionnement (classes, méthodes, etc.) ;

 autonomie des bases : la duplication et la fragmentation, permettant de disposer localement de toutes les informations relatives à un serveur, lui assurent son autonomie (il n’est que très faiblement affecté par la panne des autres serveurs) ;

 extensibilité : pouvoir enrichir le réseau par la mise en place incrémentale de nouveaux serveurs ;

 performances : la réplication et la duplication des données favorisant les accès locaux aux données assurent des performances comparables à celles d’une base locale.

Le schéma physique des bases suivant, indique la répartition et le placement des différentes propriétés et relations :

Figure 4. 5. Schéma physique de la base fédérée de RICERCAR. Rappel (cf. § 0.4.2, p.9) : les tables en MAJUSCULES sont répliquées sur l’ensemble des serveurs.

L’implémentation d’un concept objet, à partir d’un langage procédural qui interface des bases relationnelles, se révèle néanmoins délicate [Rumbaugh_96,

Bouzeghoub_97]. Les représentations des objets et de leurs relations sont matérialisées par des tables et une classe est parfois réalisée à partir de relations entre plusieurs tables.

La nécessité de gérer un changement constant de paradigme peut, d’une part, s'avérer très coûteuse en raison des multiples jointures (si les bases sont

correctement normalisées, cf. § 2.3 p.43) et , d’autre part, nécessiter de maintenir la sémantique de l’application dans des représentations différentes.

De nombreuses études ont néanmoins été menées pour accommoder des structures d’objets à des langages procéduraux ou à des formats de stockage relationnels d’autant que [Gardarin_89,Coad_91,Coulouris_95,Linthicum_97b] ont souligné l’intérêt d’une approche objet au niveau conceptuel, indépendamment du fait que l’implémentation soit ou non objet (X-Window est l’exemple d’un tel

environnement, totalement écrit en C [Young_90]).

Cet enchevêtrement de niveaux d’interprétations simultanés entretient une confusion dans l’explication d’ensemble (ce chapitre notamment) et impose un surcroît de clarté et de structuration dans le style de programmation pour décrire l’implémentation des fonctionnalités naturelles des objets à partir d’une base des méta-données.

En pratique, le nombre restreint des classes ainsi que la relative simplicité du

modèle d’un intranet nous ont cependant permis d’optimiser le placement des

objets (notamment la possibilité offerte par Cold Fusion de stocker le résultat des jointures dans le cache du serveur, à la première exécution d’une requête) et de réduire les inconvénients d’une implémentation relationnelle de RICERCAR. La reconstitution d'une classe d'objets se ramène effectivement à une vue de la base de données et les méthodes sont, selon le cas, des colonnes calculées ou des procédures écrites en CFML, qui procèdent à des calculs ad hoc (éventuellement d’autres requêtes SQL) en fonction de ces vues.

Ainsi, par exemple, une classe des Parisiens pourrait-elle être vue par : <CFQUERY Name="Parisiens" DataSource="Source_ODBC">

SELECT NOM, PRENOM, ADRESSE, DATE_NAISSANCE

FROM PERSONNE

WHERE VILLE = ‘Paris’ </CFQUERY>

Il serait ensuite possible de se référer à Parisiens.nom, Parisiens.prenom pour référencer les attributs correspondants, alors que la méthode âge devrait être calculée en fonction de l’attribut date_naissance.

L'envoi de messages (cf. paragraphe 4.5.2.1, p.108) est, quant à lui, réalisé par des redirections HTTP paramétrées :

<CFLOCATION URL="http://serveur/méthode?obj=objet?param=arg..> L'héritage y est simulé « à la main » par agrégation et par délégation et l’encapsulation des données privées n’est assuré que par des conventions de nommage (nous verrons plus loin que CFML permet de gérer une réelle encapsulation).

Il est certain que la fragilité des classes représente la principale faiblesse d'une telle représentation, dans la mesure où le schéma est complètement dynamique, soumis à l'interprétation de requêtes SQL.

L’insertion d’un niveau d’interprétation supplémentaire (cf. § 4.5.3.1) permet cependant de rigidifier l’ensemble par l’introduction d’une couche fonctionnelle qui implémente le modèle et réalise une encapsulation qui masque la faiblesse d’expression du modèle objet originel.