Modélisation, production et optimisation des programmes SQL

No. attribué par la bibliothèque

THÈSE

Pour l’obtention du titre de DOCTEUR EN INFORMATIQUE (Arrêté du 7 Août 2006)

Modélisation, production et optimisation des programmes SQL

Candidate :

Sonia GUEHIS

Directeur de thèse : Philippe RIGAUX

LAMSADE, Université Paris Dauphine Rapporteurs : Salima BENBERNOU

LIPADE, Université Paris V Bruno DEFUDE

SAMOVAR, TELECOM SudParis Suffrageants : David GROSS-AMBLARD

Le2i, Université de Bourgogne Geneviève JOMIER

LAMSADE, Université Paris Dauphine Maude MANOUVRIER

LAMSADE, Université Paris Dauphine

Introduction 9

I

_{A        ´}

-

17

1 DocQL : un langage de publication de données 18

1.1 Introduction . . . 19

1.1.1 Motivations et objectifs . . . 19

1.2 Représentation des données et modèle de requêtes . . . 20

1.2.1 Exemple illustratif . . . 20

1.2.2 La base de données relationnelle . . . 20

1.2.3 Exemples de documents dynamiques engendrés . . . 21

1.2.4 Le graphe de données . . . 23

1.3 Présentation informelle du langage DQL . . . 24

1.3.1 Requête DQL . . . 24

1.3.2 L’évaluation des requêtes DQL . . . 25

1.4 Le modèle . . . 26

1.4.1 Le graphe de données . . . 26

1.4.2 Le langage . . . 28

1.4.3 Syntaxe des règles et exemples . . . 29

1.5 L’évaluation des requêtes . . . 32

1.5.1 Stratégies de matérialisation . . . 32

1.5.2 Représentation en graphe requête . . . 33

1.5.3 Règles de réécriture . . . 35

1.6 Implémentation et perspectives . . . 37

1.6.1 Implémentation dans MR . . . 37

1.7 Travaux existants dans la littérature . . . 37

2 Publication par l’exemple 40 2.1 Introduction . . . 40 2.1.1 Contexte d’étude . . . 40 2.1.2 Motivations et objectifs . . . 41 2.2 Vue d’ensemble . . . 42 2.3 Modèle de données . . . 43 2.3.1 Exemple illustratif . . . 43 2.3.2 Le graphe de données . . . 43

2.4 Modèle de publication par l’exemple . . . 45

2.4.1 Documents canoniques . . . 45

2.4.2 Instances canoniques . . . 49

2.5 Interface de production d’un programme de publication . . . 52

2.5.1 Présentation générale de l’interface . . . 52

2.5.2 Création du bloc racine . . . 53

2.5.3 Création de sous-blocs . . . 56

2.6 État de l’art . . . 57

2.7 Conclusion . . . 59

3 Réingénierie d’applications basées sur des documents dynamiques 60 3.1 Introduction . . . 60

3.1.1 Contexte d’étude . . . 60

3.1.2 Motivations et objectifs . . . 61

3.2 Vue d’ensemble . . . 62

3.3 Processus de rétro-ingénieurie . . . 63

3.3.1 Dissociation des parties statiques et dynamiques du document . . . 63

3.3.2 Production du sous-graphe de données . . . 65

3.3.3 Génération du programme de publication . . . 67

3.4 Discussion des limites du processus . . . 70

3.5 État de l’art . . . 71

3.6 Conclusion . . . 72

II

_{T ’   SQL}

73

4.1.1 Solutions basiques déployées pour la persistance des données . . . 75

4.1.2 Vers une solution de persistance objet-relationnel . . . 76

4.1.3 Mappingobjet-relationnel . . . 76

4.1.4 Solutions ORM existantes sur le marché . . . 77

4.2.1 Définition d’une session, d’une sessionFatcory et d’une transaction : . . . 78

4.2.2 Mapping des tables vers les objets ou entités . . . 79

4.3 Requêtes par critères . . . 79

4.3.1 Stratégies de chargement des données . . . 80

4.3.2 Mode de chargement des associations : quelle(s) requête(s) utiliser ? . . . 80

4.3.3 A quel moment charger les associations : immédiat ou tardif ? . . . 81

4.4 Problématique des N+1 requêtes . . . 82

4.4.1 Présentation et définition du problème dit des N+1 requêtes . . . 82

4.4.2 Solutions possibles pour la résolution du problème N+1 requêtes . . . 83

4.4.3 Utilisation des statistiques d’Hibernate lors de l’étude de performance . . . . 85

4.5 Conclusions . . . 86

5 Techniques d’optimisation dans les programmes SQL 87 5.1 Introduction . . . 88 5.1.1 Contexte d’étude . . . 88 5.1.2 Motivations et objectifs . . . 88 5.2 Vue d’ensemble . . . 89 5.2.1 Stratégie de matérialisation . . . 90 5.2.2 Synopsis du programme . . . 91 5.3 Synopsis du programme . . . 93 5.3.1 Graphe de données . . . 93 5.3.2 Synopsis du programme . . . 93 5.4 Matérialisation . . . 95

5.4.1 L’espace d’optimisation : jointure externe, union et décorrélation . . . 96

5.4.2 Le modèle de coût . . . 98

5.4.3 Algorithme d’optimisation . . . 101

5.5 Expérimentations . . . 102

5.5.1 Configuration matérielle et logicielle . . . 102

5.5.2 Distribution de données et choix de programmes . . . 103

5.5.3 Coût constant des opérations open et fetch . . . 104

5.5.4 Coûts relatifs des opérations open, fetch et decode . . . 105

5.5.5 Étude comparative des stratégies de matérialisation . . . 106

5.6 Travaux similaires . . . 109

5.6.1 Les méthodes de publication de bases de données relationnelles en vue XML 109 5.6.2 Les méthodes basées sur les stratégies de décorrélation . . . 110

5.7 Conclusion . . . 111

1 Vue d’ensemble des sous-problématiques étudiées . . . 15

1.1 Le schéma relationnel de la base de données du système MR (extrait) . . . 20

1.2 Une instance de la base de données . . . 21

1.3 Une partie du graphe virtuel . . . 24

1.4 Évaluation d’une requête DQL q . . . 26

1.5 Le schéma du graphe de données . . . 27

1.6 Graphes requête . . . 33

1.7 Quelques règles de réécriture . . . 36

1.8 Imprime écran de l’interface de MR associée aux requêtes DQL. . . 38

2.1 Vue d’ensemble du processus . . . 42

2.2 Un échantillon de la base Films . . . 44

2.3 Graphe de données . . . 45

2.4 Création de cycles dans une instance canonique . . . 50

2.5 Vision générale de l’interface, dans l’état initial . . . 53

2.6 Après sélection du chemin initial Film . . . 54

2.7 Edition du bloc par ajout de texte libre . . . 55

2.8 Navigation dans les blocs du document . . . 56

2.9 Ajout et édition d’un sous-bloc . . . 57

3.1 Vue d’ensemble du processus de rétro-ingénieurie . . . 62

3.2 Le schéma du graphe de données . . . 68

3.3 L’arbre de connexion découpé en blocs . . . 69

4.1 Persistance des données prise en charge par le développeur . . . 75

4.2 Persistance des données par ORM . . . 77

4.3 Partie du schéma de la base TPC-H . . . 78

5.1 Architecture générale du système . . . 90

5.2 A simple invoice program. . . 91

5.3 Le programme facture, réécrit moyennant les jointures externes . . . 92

5.5 A part of the virtual graph . . . 93

5.6 The schema of the data graph . . . 94

5.7 A program summary and its interpretation . . . 95

5.8 Illustration de l’algorithme d’optimisation . . . 101

5.9 Summaries of the Psimple, Pcustand Ppartprograms . . . 103

5.10 Évolution du coût par rapport au nombre des open et fetches . . . 106

5.11 Temps de réponse des programmes Pcustet Ppartexécutés sur SQLServer . . . 107

5.12 Temps de réponse des programmes Psimple, Pcustet Ppartexécutés sur SQLServer . . 108

4.1 Liste des Frameworks ORM de persistance Java . . . 78

5.1 Analyse des coûts relatifs aux règles de réécriture d’un synopsis de la forme @t1[p1]{@t2[p2]} 99 5.2 Coût d’exécution de l’opération open (côté serveur uniquement) . . . 105

5.3 Coût d’exécution de l’opération open . . . 105 5.4 Impact de la taille des tuples sur l’opération fetch (La communication client/serveur) 105 5.5 Impact du nombre de open sur l’exécution du programme . . . 106 5.6 Impact du nombre de fetch sur l’exécution du programme . . . 106 5.7 Execution time of Psimple, Pcustand Ppart, in seconds . . . 107

Les années 90 furent marquées par l’expansion d’Internet comme le réseau informatique mon-dial. Les internautes se partagent désormais les fichiers, s’échangent des messages et publient des informations.

Par ailleurs, les systèmes d’informations ont envahi le marché industriel. La gestion des tâches avec un support papier est révolue et a cédé place aux traitements informatisées basés sur des docu-ments électroniques, plus facile à manipuler, à gérer, à sauvegarder et à diffuser. Ces documents sont pour la plupart engendrées d’une manière automatique à partir des informations extraites d’une base de données moyennant des applications informatisées.

Dans ce contexte, les bases de données constituent le noyau et le cœur des systèmes d’informa-tion. En effet, les données sont gérées par le système de gestion des bases de données (SGBD) d’une manière cohérente, non redondante et efficace.

Les applications informatiques répondent aux besoins des industriels, des commerçants ainsi que des usagers individuels. Bon nombre de ces applications optent pour le choix des bases de données relationnelles comme moyen de sauvegarde et de gestion des données. La structure des programmes générant ces applications est le plus souvent composée de routines associées aux traitements ainsi que des requêtes d’interrogation de la base. Notre thèse se positionne dans ce contexte et s’intéresse à la modélisation, production et optimisation de ce type de programmes.

A- Contexte et problématiques

Pour des raisons de clarté et de cohérence, une terminologie propre à cette thèse a été adoptée tout au long de notre manuscrit. Nous définissons ci-après la terminologie associée aux concepts les plus récurrents dans ce manuscrit.

. Les programmes SQL : Le noyau dur de cette thèse s’articule autour de l’importation des données depuis une base de données relationnelle et plus particulièrement les programmes invoquant des requêtes SQL pour l’importation de ces données. Nous désignerons ces pro-grammes par le terme propro-grammes SQL. Les propro-grammes SQL représentent concrètement un code source écrit en un langage de programmation (Java, C, C++, PHP, etc.) contenant des requêtes SQL imbriquées.

. Document dynamique : Nous mettons l’accent sur la problématique de génération automa-tique de documents dynamiques dont nous attribuons la définition suivante : Un document dynamique est tout document composé de fragments textuels à caractère statique et de frag-ments de données importées à partir d’une bases de données. Un document dynamique peut être un fichier texte, une page Web, un tableur Excel, un documents LA_{TEX ou un message}

élec-tronique.

. Les programmes de publication de bases de données relationnelles : Nous définissons par ailleurs, les programmes de publication de bases de données relationnelles comme étant tout programme produisant une chaîne de caractères contenant des données extraites d’une base de données relationnelle. Un exemple typique et très répandu de programme de publication de bases de données relationnelles est la production dynamique de pages HTML dans les sites Web.

Cette thèse se répartit en deux parties. Nous proposons dans la premières partie des solutions de modélisation et de production des programmes de publication de bases de données relationnelles. La deuxième partie traitera des techniques d’optimisation dans les programmes SQL.

1. Autour des programmes de publication de bases de données relationnelles

Dans le but d’automatiser la génération de documents dynamiques dans un contexte donné, les développeurs ont recours à un ensemble de techniques pour la mise en place de leurs programmes. Un programme de publication est composé d’un ensemble de routines associées aux opérations de tests, les boucles, etc., écrites en un langage de programmation (tel que Java, C, PHP et autres). Les données dynamiques extraites de la base sont importées de la base de données moyennant des requêtes écrites en un langage d’interrogation des bases de données relationnelles. SQL est le langage le plus souvent utilisé et le plus connu en tant que langage d’interrogation des bases de données relationnelles. Par ailleurs, la formulation des requêtes nécessite la connaissance préalable du schéma relationnel de la base.

En prenant en considération les contraints techniques de mise en place des programmes SQL et des compétences requises par d’éventuels utilisateurs amenés à élaborer ces programmes, nous dévelop-pons la première problématique considérée dans cette thèse : proposer un langage de publication de bases de données relationnelles assez simple pour les usagers.

Par ailleurs, le succès connus par certaines approches tel que QBE [53] (Query By Example), Mi-crosoft Access [17], XQBE [11](XQuery By Example), etc. revient essentiellement à leur simplicité d’utilisation. L’idée fédératrice de ces solutions étant la génération du résultat à partir d’un exemple formulé par l’utilisateur. Ces solutions s’adressent en partie, à des usagers ne maîtrisant pas le langage de base mais souhaitant en tirer profit. Nous nous sommes inspirés de ce constat afin de développer notre deuxième problématique, à savoir la proposition d’un framework de publication de bases de

données relationnelles par l’exemple. En d’autres termes, définir un outil interactif permettant la gé-nération automatique de programmes de publication.

D’autres part, considérant le même contexte des programmes de publication, nous nous sommes interrogés sur la maintenance de ces programmes. Plus particulièrement, nous avons imaginé le cas des applications Web qui, soit sont générées automatiquement par des outils existants sur Internet et dont le code n’est pas fournit, soit ont été mal documentées et donc difficiles à mettre à jour. Ignorant la structure de ces programmes, le processus de maintenance et de mise à jour de ces pro-grammes s’avère quasiment impossible. Nous définissons dans ce contexte notre troisième probléma-tique comme étant la proposition d’une solution de rétro-ingénierie des programmes Web basée sur les documents dynamiques. Autrement dit, mettre en place une approche décrivant la structure d’un programme de publication inconnu en se basant sur l’analyse des documents en résultant.

2. Techniques d’optimisation des programmes SQL

Dans un contexte plus général, à savoir celui associé aux programmes SQL, nous nous sommes intéressés au problème d’optimisation. La structure des programmes SQL est souvent régis par la logique des traitements et non par le soucis de performance de ces programmes. En effet, il n’est souvent pas à la charge des développeurs d’écrire un code qui soit optimisé et performant, d’autant plus qu’ils n’ont généralement pas assez de temps pour le faire. La manière la plus intuitive et la plus courante de structurer les programmes SQL peut se résumer en un flux de requêtes élémentaires, successivement émises au serveur. Le coût d’exécution des requêtes, les échanges clients/serveur et le coût associé aux transmissions des résultats constituent des facteurs très important qui ont une incidence directe sur les performances des programmes [10, 47].

Nous étudions dans ce contexte la problématique suivante : la définition d’une approche globale d’optimisation pour les programmes SQL, minimisant le nombre de requêtes émises au serveur et limitant les échanges client/serveur.

B- Contributions

1. Nous proposons comme première contribution un langage de publication de bases de données relationnelles, déclaratif, simple et concis nommé DQL. Notre objectif principal est de li-miter la tâche de l’utilisateur à un ensemble d’instructions nécessaires à produire le document résultat. DQL est un langage qui évite le recours aux langages classiques de programmation et épargne la maîtrise de SQL. Il s’agit d’une solution se basant sur le schéma et l’instance de la base, uniformément représentés sous forme de graphe. Nous définissons les caractéristiques principales du langage (la syntaxe, les sémantiques opérationnelles, l’évaluation des requêtes) et montrons que DQL supporte des techniques d’optimisation à travers des règles de réécri-ture qui ont été définies. Nous décrivons l’implémentation de DQL et son usage au sein du système de gestion des conférence MYREVIEW. Ce travail a été publié dans [29]

2. Notre deuxième contribution se positionne dans la continuité de la première. Nous décrivons un framework de publication par l’exemple qui se base sur le langage DQL. L’idée est basée sur la génération du programme de publication (le programme DQL) à partir d’un document exemple construit d’une manière interactive avec l’utilisateur. La solution repose sur deux no-tions fondamentales : document canonique et instance canonique.

Une instance canonique est une instance artificielle engendrée automatiquement par un généra-teur. Une instance canonique d’un schéma de base de données est destinée à offrir à l’utilisateur toutes les possibilités de navigation permises par la structure du schéma. En d’autres termes, proposer une instance canonique revient à rendre possible la production, par l’exemple, de toutes les requêtes de publication qui peuvent être exprimées sur le schéma.

Le document canonique constitue le document exemple sur lequel se base la solution pour générer le document final. L’utilisateur interagit avec un éditeur afin de construire le docu-ment canonique à partir d’une instance canonique. L’éditeur permet la saisie libre des parties statiques du document canonique, ainsi qu’une navigation dans l’instance canonique afin de pouvoir insérer le contenu dynamique.

Nous décrivons l’interface homme-machine interactive permettant la production du document canonique ainsi que la génération du document final résultat du programme de publication. Cette solution a fait l’objet de publication dans [27, 28]

3. Nous proposons par la suite une méthode de réingénierie d’applications basées sur des docu-ments dynamiques. Il s’agit d’un processus de rétro-ingénierie dans les applications Web. Le processus fait recours au langage DQL et à la notion d’instance canonique définie lors de la deuxième contribution. L’idée se résume en trois points : (i) la séparation des parties statiques et dynamiques du document (ii) l’identification des données qui sont extraites de la base (les noms d’attributs et des tables ainsi que les associations entre différents tuples) (iii) en dernier lieu, la génération d’une description de l’architecture du programme et ce via la production de la requête DQL associée. L’approche a été présentée dans [26].

4. La quatrième contribution met l’accent sur les techniques d’optimisation apportées aux pro-grammes SQL. Nous décrivons une approche, basée sur un modèle de coût, proposant une stra-tégie de réécriture du programme et un algorithme d’optimisation.L’approche se base sur une description de la structure du programme définie par un utilisateur expert.À partir de cette des-cription, la solution décide de la meilleure stratégie d’exécution du programme et ce moyennant certains facteurs tel que le choix des requêtes (des selections imbriquées, une jointure externe ou autres) et la stratégie de mise en cache. Des expérimentations menées sur le TPC-H bench-mark, permettent la validation du modèle et confirment l’apport considérable de notre approche en terme de temps d’exécution .

C- Vue d’ensemble des sous-problématiques étudiées

Notre manuscrit est dépourvu d’un chapitre état de l’art. Bien que traitant des problématiques relatives à un même contexte, et nos différentes contributions divergent sur les objectifs respectifs. Nous venons d’énoncé dans la précédente section les majeurs problématiques considérées dans cette thèse, que nous pouvons résumer en ces quatre points :

⇒ la proposition d’un langage de publication de bases de données relationnelles ; ⇒ un framework interactif de publication par l’exemple ;

⇒ une méthode de rétro-ingénierie des programmes de publication ; ⇒ des techniques d’optimisation dans les programmes SQL.

Lors de la réflexion menée sur la mise en place de chacune de nos solutions, nous avons été amené à étudier, se positionner ou élucider d’autres sous-problématiques. La figure 1 décrit un aperçu de ces points, que nous présentons brièvement ci-après.

√

Publication en vue XML des bases de données relationnelles : Il s’agit de définir une repré-sentation XML de la base de données. Les vues XML sont considérées comme support pour les requêtes en utilisant les langages d’interrogation tel que XPath [48] ou XQuery [39]. Nous avons étudié cette problématique de part le fait qu’il s’agisse d’un problème de publication de bases de données relationnelles même si le résultat en sortie est différent. Notre approche rejoint les solutions qui sont associées à ce problème sur l’emploi de vues virtuelles qui se matérialisent lors de l’exécution du programme. Par ailleurs, tout comme dans DQL, les solutions sont souvent dotées d’un module qui décide du meilleur plan d’exécution et d’une stratégie de matérialisation qui soit optimisée.

√

Représentation sous forme de graphe de l’instance de la base de données : L’instance de la base est représentée sous forme de graphe de données, où les nœuds non feuilles sont les tables, les feuilles constituent les valeurs d’attributs et les arcs correspondent aux associations reliant les différents nœuds. Ce type de représentation offre plusieurs avantages notamment en terme de primitives de navigation, particulièrement pratiques dans le contexte des instances de bases de données. En effet, il est souvent question, dans un problème de publication, d’instancier un flux de données, qui correspond à une navigation dans une partie de la base moyennant l’interprétation des différentes associations reliant les tables.

√

Requêtes par l’exemple : Le principe de base ici est de formuler des requêtes, non pas à travers un langage d’interrogation de la base, mais à travers un exemple du résultat que l’on souhaite obtenir. il s’agit du même principe que nous considérons pour mettre en place notre solution. Nous étudions dans la section 2.6 des exemples d’approches qui ont eu recours aux requêtes par l’exemple.

√

La rétro-ingénierie des applications Web : Cette problématique peut être définie de plusieurs manières selon les objectifs et les entrées considérées. Nous nous sommes positionnés dans un contexte où le programme Web est inconnu et où l’objectif principal est de fournir une descrip-tion de sa structure. Nous avons étudié d’autres soludescrip-tions disponibles traitant la rétro-ingénierie des programmes Web. Nous nous sommes positionnés par rapport à celles-ci. Ces approches

considèrent d’autres objectifs et utilisent d’autres démarches. Certains s’intéressent à la pro-duction de diagrammes UML comme description du programme Web, d’autres s’intéressent uniquement au volet graphique ou statiques de l’application etc.

√

Recherche par mots clés dans une base de données relationnelle : Nous avons croisé ce volet, lors du traitement de la proposition de l’approche de réingénierie. Identifier des données dans une base de données est un problème très connu dans le contexte des bases de données relationnelles. Nous n’avons pas apporté de contributions sur le sujet, mais avons étudié les solutions existantes sur le marché et avons utilisé l’approche qui nous semblait la plus adéquate à notre besoin.

√

Solutions de persistance : Dans la deuxième partie du manuscrit nous étudions la notion de persistance des données et plus particulièrement dans un contexte orienté objet. La persistance des objets est relative à la possibilité permanente d’accès et de modification de l’objet. Les approches les plus courantes se basent sur une couche de persistance objet-relationnel appelés frameworks ORM(object/relationnel mapping). Nous nous attardons sur Hibernate une solution ORM, qui nous servira de noyau pour la mise en place de notre stratégie d’optimisation dans les programmes SQL.

√

Problème des N+1 requêtes : Il s’agit d’un problème récurrent en programmation dans le contexte des programmes SQL. La formulation d’un ensemble de requêtes imbriquées dans des curseurs nous induit à ce type de problème. Ce dernier donné lieu à une dégradation des performance du programme. Notre quatrième contribution a pour objectif d’éviter ce genre de problème comme première partie de la solution et proposer d’autres techniques d’optimisation. Conclusion : La description des sous-problématiques traitées dans cette thèse a pour vocation d’expliciter les raisons pour lesquelles nous ne développons pas de chapitre état de l’art. L’étude des approches se trouvant dans la littérature relative à chaque point n’est pas en total concordance et harmonie avec les autres points. Nous faisons alors le choix de présenter l’étude de l’existant propre à chaque contribution dans le chapitre correspondant.

D- Organisation du document

Le présent document est organisé comme suit.

Chapitre 1 - DocQL : un langage de publication de données. Ce chapitre propose le langage relationnel DQL. Nous définissons en premier lieu la représentation des données et le modèle de requêtes. Par la suite, nous présentons le langage : la syntaxe, la sémantique et les règles d’évaluation. Nous décrivons en dernier lieu la partie évaluation des requêtes ainsi que les techniques d’optimisa-tion mises au point à travers des règles de réécriture.

Chapitre 2 - Publication par l’exemple. Nous introduisons dans ce chapitre une approche inté-ractive de publication par l’exemple. Un aperçu général du processus est décrit en début de chapitre. Nous présentons le modèle de données et la base de données exemple adoptée. Nous décrivons

for-importation des données Applications Web Requetes par l’exemple Publication en vue XML Programmes SQL

Couche de persistance (ORM)

000000000

000000000

000000000

000000000

000000000

000000000

000000000

000000000

111111111

111111111

111111111

111111111

111111111

111111111

111111111

111111111

F. 1 – Vue d’ensemble des sous-problématiques étudiées

mellement le modèle de publication par l’exemple avec la définition des notions phares : document canoniqueet d’instance canonique. Nous validons ce modèle par la description d’une courte session illustrant l’utilisation d’une interface utilisateur pour construire interactivement des documents cano-niques.

Chapitre 3 - Réingénierie d’applications basées sur des documents dynamiques. Ce chapitre propose en premier temps un aperçu général de l’approche proposée. Par la suite, nous décrivons le processus de rétro-ingénierie avec ses trois phases principales : (i) la dissociation des parties statiques et dynamiques (ii) la génération du sous-graphe de données associé au contenu dynamique et enfin (iii) la phase de production de la requête DQL associée au programme de publication. Le dernier paragraphe du chapitre présente et discute les limites de la solution proposée.

Chapitre 4 - Persistance des données et étude de performance d’Hibernate.Nous présentons dans ce chapitre la notion de persistance des données. Nous étudions l’historique des solutions qui ont abordé le sujet et apporté des éléments de réponse. Nous mettons l’accent plus particulièrement sur la solution Hibernate, un framework ORM (Object Relational Mapping) répandu actuellement sur

le marché.

Chapitre 5 - Techniques d’optimisation dans les programmes de bases de données basées sur le profil de navigation. Ce chapitre se résume en trois grandes parties : (i)introduction au problème et présentation de l’architecture générale de la solution (ii) définition de la notion du synopsis du pro-grammeet description de la stratégie de matérialisation des données : présentation du modèle de coût et de l’algorithme d’optimisation et enfin (iii) validation du modèle à travers des expérimentations menées sur la base du TPC-H benchmark et faisant appel à des primitives d’Hibernate.

DocQL : un langage de publication de

données

Sommaire

1.1 Introduction . . . 19

1.2 Représentation des données et modèle de requêtes . . . 20

1.3 Présentation informelle du langage DQL . . . 24

1.4 Le modèle . . . 26

1.5 L’évaluation des requêtes . . . 32

1.6 Implémentation et perspectives . . . 37

1.7 Travaux existants dans la littérature . . . 37

1.8 Conclusions . . . 39

Ce chapitre propose un langage de publication de bases de données relationnelles. Nous définis-sons la « publication » comme tout programme permettant la production de documents dynamiques contenant des données extraites d’une base relationnelle. Le processus de publication repose sur le mappingde la bases de données en un graphe virtuel de données supportant des opérateurs de navi-gation. Les applications de publication ont recours à la navigation dans le graphe de données pour accéder aux données requises. Le résultat est alors obtenu par la production, durant la navigation, des fragments textuels dont la concaténation produit le document final.

Nous définissons un langage déclaratif de requêtes sur des graphes virtuels de données nommé DQL. Une requête DQL est évaluée par l’exécution d’un ensemble de requêtes SQL corrélées sur une instance de base de données. L’approche proposée a été publiée dans [29]

1.1

Introduction

Le succès des bases de données relationnelles revient essentiellement aux divers avantages que présentent les langages d’interrogation : simplicité d’utilisation, richesse d’expressivité, etc. SQL constitue le langage le plus connu et le plus utilisé. Toutefois, en pratique il s’avère nécessaire de l’intégrer dans un langage de programmation traditionnel tel que C ou Java. En effet, au-delà de la richesse de ce langage dans l’expression des requêtes, il reste néanmoins très limité en tant que lan-gage de programmation : incapacité d’exprimer des opérations simples (tel que la lecture et l’écriture sur des fichiers), manque de flexibilité (tel que l’accès à des bibliothèques externes) et autres tâches couramment requises dans les applications .

Dans la majorité des cas, les développeurs ont donc recours à l’intégration de SQL dans un autre langage de programmation, ce qui implique quelques inconvénients :

• D’une part, l’intégration du SQL dans un langage de programmation dépasse sans doute les capacités des utilisateurs non experts.

• D’autre part, les développeurs experts sont susceptibles de programmer certaines routines qui ne tirent pas profit de l’optimisateur du SGBD. Le code ainsi écrit par le programmeur est certes fonctionnel mais pas optimal.

1.1.1 Motivations et objectifs

Dans ce cadre d’étude et dans le but de s’affranchir des contraintes techniques associées à la génération des programmes de publication (l’intégration de SQL dans un langage de programmation), nous proposons de définir un langage simple, direct et concis regroupant l’ensemble des spécifications de publication. Nos travaux sont motivés par la conviction que les besoins de publication peuvent être satisfaits par des routines de programmation restreintes avec deux conséquences :

1. une spécification déclarative de haut niveau de ces programmes peut être envisagée, apportant, entre autres avantages, la simplicité aux usagers non experts ;

2. une spécification globale et déclarative de ces programmes permet à l’optimisateur une manipu-lation en tant qu’un tout et non pas en tant qu’un ensemble de requêtes SQL traitées séparément par le SGBD.

Pour ce faire, nous proposons un langage relationnel, nommé DQL, qui combine des primitives de navigation dans une bases de données relationnelle ainsi qu’un mécanisme d’instantiation des fragments contribuant au document final. DQL ne communique pas directement avec l’instance de la base, il interagit plutôt avec une représentation de cette instance sous forme de graphe (virtuel) de données. Ce choix a pour avantage un gain en terme de simplicité et d’expressivité. En effet, la structure du document en output constitue une structure hiérarchique pouvant être représentée sous forme de graphe, il est plus facile de considérer en input une instance sous forme de graphe. D’autre part, ce type de représentation offre un support de navigation beaucoup plus adapté que les curseurs SQL, qui sont limités à des parcours linéaires des résultats de la requête.

Nous décrivons dans ce chapitre en premier lieu la syntaxe et la sémantique du langage. Par la suite, nous démontrons qu’une requête DQL peut être facilement représentée dans un formalisme, qui donne lieu à des techniques de réécriture et d’optimisation. La dernière section de ce chapitre porte sur l’implémentation d’une version de test de DQL qui repose sur le schéma relationnel as-socié à la base de données de MR, un système de gestion de conférences. Nous avons choisi ce système pour la validation de notre proposition puisqu’il s’agit d’un système engendrant plusieurs sortes de documents de publication.

Dans la suite de ce chapitre, nous présentons dans la section 1.2 une description informelle de notre approche. Le modèle est détaillé dans la section 1.4. La section 1.5 et 1.6 décrivent respective-ment les techniques d’évaluation des requêtes et l’implérespective-mentation de la solution. La dernière section conclue ce chapitre.

1.2

Représentation des données et modèle de requêtes

Nous décrivons dans cette section le choix de représentation de la base de données relationnelle sous forme de graphe virtuel. Nous introduisons en premier lieu l’exemple qui nous servira de support illustratif tout au long de ce chapitre. Par la suite, différents formats de documents exemples seront proposés.

1.2.1 Exemple illustratif

Nous illustrons nos travaux avec le système de gestion de conférences MR. Il s’agit d’une application Web où les auteurs soumettent des articles en précisant quelques propriétés (résumé, titre et thème), alors que les rapporteurs sont affectés à des articles afin d’apporter des évaluations. Un rapport d’évaluation est constitué de plusieurs fragments textuels (commentaires, résumé, etc), ainsi qu’un rapport de notes, un pour chaque critère d’évaluation défini par le responsable.

• Paper (idPaper, title, year)

• Person (email, firstName, lastName) • Author ( idPaper, email)

• Review (idPaper, email, comment)

• ReviewMark (idPaper, email, criterion, mark)

F. 1.1 – Le schéma relationnel de la base de données du système MR (extrait)

1.2.2 La base de données relationnelle

La figure 1.1 présente un extrait du schéma relationnel de la base MR. Les clés primaires sont en gras et les clés étrangères sont en italiques. La figure 1.2 décrit un exemple d’instance de la base de données. Chaque article correspond à un tuple dans la table Paper et est associé à un ou

plusieurs auteurs (table Author). Les personnes sont identifiées par leurs adresses électronique dans chaque table. La table Person contient le nom et le prénom de la personne correspondant au message électronique. La correspondance entre un article et ses rapporteurs est représentée par les tuples de la table Review. Les rapporteurs donnent leurs commentaires (dans la table Review) et la liste des notes (dans la table ReviewMark), pour chaque critère d’évaluation.

idPaper title year

128 Do computer think ? 1951 Paper

email firstName lastName

turing@nw.com Alan Turing

r1@sw.com John Doe

r2@ew.com Bill Smith

Person

idPaper email

128 turing@nw.com

Author

email idPaper comment

r1@sw.com 128 Ridiculous

r2@ew.com 128 Outstanding Review

email idPaper criterion mark

r1@sw.com 128 quality 3

r1@sw.com 128 relevance 4

r2@ew.com 128 quality 5

ReviewMark

F. 1.2 – Une instance de la base de données

La représentation est tout à fait standard. Chaque tuple est composé d’un ensemble de valeurs d’attributs et est identifié par sa clé. La clé primaire est utilisée pour référencer un tuple t : par exemple le rapporteur d’un article (table Review) est référencée par son adresse électronique, qui est la clé des tuples Person. Dans la suite, nous supposons que la base de données est en troisième forme normale.

1.2.3 Exemples de documents dynamiques engendrés

Le système MR, comme d’autres applications du même genre, engendre un ensemble de documents à partir d’informations extraites de la base. La majorité des requêtes transmises par l’utili-sateur au système consiste en la production à la demande de pages HTML et autre types de documents. Par exemple, le rapport d’évaluation des rapporteurs associé à un article donné, existe dans le format suivant :

• une page HTML ;

• un document LA_{TEX dont le contenu peut être édité par le responsable de la conférence ;}

• un message, envoyé à l’auteur à la date de notification.

Pour chaque format considéré, l’objectif est toujours le même : publier un document qui est conforme à une grammaire spécifique (ou sans grammaire dans le cas des mails) et qui contient des informations extraites de la base. Ci dessous quelques exemples de documents dynamiques produits à partir de l’instance de la figure 1.2 :

. . . P a p e r : Do c o m p u t e r t h i n k ? <br / > Author : Alan Turing <br / >

<br / > A b s t r a c t : . . . < br / > <h2>Reviewer : John Doe </ h2>

<ol > < l i >Comments : R i d i c u l o u s </ l i > < l i > Q u a l i t y : 3 </ l i > < l i >Relevance : 4 </ l i > </ ol > <h2>Reviewer : B i l l Smith </ h2> <ol > < l i >Comment : O u t s t a n d i n g </ l i > < l i > Q u a l i t y : 5 </ l i > </ ol > . . .

2. La version LA_{TEX est une autre représentation :}

. . .

\ s e c t i o n {Do computer t h i n k ?} P a p e r w r i t t e n by A l a n T u r i n g

\ s u b s e c t i o n ∗{ Review of John Doe} \ begin { enumerate } \ item \ t e x t b f {Comments } : R i d i c u l o u s \ item \ t e x t b f { Q u a l i t y } : 3 \ item \ t e x t b f { Relevance } : 4 \ end { enumerate } . . .

3. Voici, un dernier exemple décrivant un message de notification envoyé aux auteurs. Le message contient le rapport de l’article de l’auteur en question. Le document conserve la structure géné-rale des documents précédemment définis avec la précision du statut "accepté" ou "refusé" de l’article. D e a r A l a n T u r i n g , We a r e p l e a s e d t o i n f o r m you t h a t y o u r p a p e r e n t i t l e d "Do c o m p u t e r t h i n k ? " h a s b e e n a c c e p t e d [ . . . ] P l e a s e t a k e i n t o a c c o u n t t h e s u g g e s t i o n s o f o u r r e v i e w e r s . We a r e l o o k i n g f o r w a r d . . .

R e v i e w e r 1 : Q u a l i t y : 3 R e l e v a n c e : 4 R e v i e w e r ’ s comments : R i d i c u l o u s R e v i e w e r 2 : . . .

Remarques et observations : Il n’existe aucune façon de produire de tels documents avec SQL. En pratique, il s’agit donc d’écrire un programme avec des requêtes SQL intégrées. De tels pro-grammes suivent tous la même organisation interne, étant donné que même si les formats de ces documents différent, ils reposent tous sur le même squelette : un article est associé à une liste de rapports d’évaluation et chaque rapport est associé à son tour à une liste de notes. La spécification de cette organisation est extrêmement simple : il s’agit juste de suivre le chemin débutant à partir de l’article jusqu’à ses rapports, puis à partir de chaque rapport d’évaluation, s’acheminer vers les notes qui lui sont associées. Il est important de souligner que ce mécanisme inclut en premier lieu une itération sur les instances trouvées dans la base (les différents auteurs, ou les différents articles, etc.). D’autre part, dans certains cas, des décisions sont occasionnellement prises pour instancier ou pas quelques parties spécifiques du document (une structure différente du document quand il s’agit d’un article accepté et quand il s’agit d’un article refusé).

Quelques parties du message de notification changent selon que l’article est accepté ou non. Le choix dépend des valeurs de quelques attributs de la base, qui déterminent le comportement du pro-cessus de publication. En réalité, la plupart des fonctionalités usuelles requises pour publier des do-cuments textuels à partir d’une base de données relationnelle sont conformes au mécanisme général illustré dans les exemples précédents. En particulier, les programmes couramment utilisés pour pro-duire de tels documents se basent essentiellement sur des itérateurs et des tests dont l’expression des conditions se fait à partir de valeurs récupérées de la base.

1.2.4 Le graphe de données

Afin de mettre en place le mécanisme de navigation énoncé ci-avant, nous modélisons la base de données comme un graphe dirigé où :

• chaque tuple dans la base est représenté par un nœud du graphe ;

• chaque lien (clé étrangère, clé primaire) est modélisé comme un arc dirigé entre les tuples correspondants.

Le graphe est virtuel et doit être partiellement matérialisé durant la phase d’évaluation de requêtes. Une partie du graphe de données est décrite dans la figure 1.3 pour notre instance (le contenu de la table ReviewMark par exemple est partiellement représenté).

email Doe r2@cw.com email Paper firstName firstName firstName lastName comment lastName Turing Alan Outstanding Bill Smith r1@sw.com turing@nw.com lastName Review id Person Review comment Ridiculous Review Person criterion Quality mark Review Person ReviewMark 128 1951 year

Can computer think?

title accepted Y John 3 Review

F. 1.3 – Une partie du graphe virtuel

L’avantage d’une telle représentation est la simplicité et la concision des concepts : chaque nœud correspond à un tuple ou à une valeur ; chaque arc est étiqueté et représente une association entre deux nœuds. Les arcs sont associés aux liens de la base du type tuple-attribut et tuple-tuple.

1.3

_{Présentation informelle du langage DQL}

Nous proposons un langage déclaratif, simple et concis permettant la génération de documents dynamiques à partir d’une instance de base de données, représentée sous forme de graphe. DQL permet l’intégration des données extraites de la base aux fragments textuels. Ces fragments sont par la suite regroupés de sorte à constituer le document final.

1.3.1 Requête DQL

Une requête DQL est constituée des composants suivants :

1. un arbre d’expressions de chemins (parfois appelé graphe requête), spécifiant la partie du graphe de données (dénommée le sous-graphe) contenant les données utiles à la construction du document final.

2. chaque expression de chemin c dans le graphe requête fait réfèrence à un ensemble de nœuds, appelés nœuds terminaux de c ; c est associé à un fragment (ou template) textuel à produire pour chaque nœud terminal.

L’exemple suivant décrit une requête DQL à exécuter sur notre instance de base de données (on suppose l’existence d’un attribut supplémentaire accepted dans la table Paper). La requête produit un document à l’attention du président de la conférence regroupant le statut de l’article ainsi que la liste

des rapports qui lui sont associés. Les expressions de chemins et les templates sont organisés comme des règles de la forme @chemin{cor ps}. Les détails seront explicités plus tard.

@paper [ i d P a p e r=128]{ T h i s p a p e r , e n t i t l e d @ t i t l e , w r i t t e n by @ a u t h o r . p e r s o n . f i r s t N a m e @ a u t h o r . p e r s o n . l a s t N a m e , h a s b e e n e v a l u a t e d a s f o l l o w s : @ a c c e p t e d [ ’Y ’ ] { The p a p e r i s g o i n g t o be a c c e p t e d . . . } @ a c c e p t e d [ ’N ’ ] { The p a p e r i s g o i n g t o be r e j e c t e d . . . } @review { − R e v i e w e r name : @ r e v i e w e r { @ f i r s t N a m e @lastName } − Comments : @comment − Marks :

@reviewMark { name : @mark} }

}

L’interprétation de cette requête sur l’instance de la figure 1.3 peut être décrite comme suit : • La première étape consiste à l’accès à l’article dont l’id est 128 (nœud encadré par un rectangle

dans la figure).

• À partir de ce nœud, les chemins title, author.person.firstName and author.pe- rson.lastName donnent lieu à des nœuds terminaux dont les valeurs sont insérées dans le document.

• La règle accepted décrit la décision d’instancier le fragment associé à la valeur de l’attribut accepted.

• Par la suite, une nouvelle règle est activée pour chaque chemin review débutant à partir du nœud courant. L’interprétation de ces règles se fait d’une manière similaire.

1.3.2 L’évaluation des requêtes DQL

Intuitivement, l’évaluation d’une requête DQL q peut être décomposée en deux étapes, comme indiquée dans la figure 1.4.

Le graphe de données GI, supportant le processus d’interrogation, est virtuel et est défini par

un mapping M de la base de données I. Les opérateurs de navigation nécessaires à la production du résultat de la requête doivent visiter un sous graphe du graphe de données : la première étape est la matérialisation du sous-graphe. Ceci est effectué par l’exécution d’un programme SQL Pq,

dynamiquement produit, qui récupère tous les tuples nécessaires à partir des tables concernées et effectue la représentation de ces tuples en tant que nœuds du graphe. Durant la deuxième phase du processus, le document final est produit à partir de la navigation dans ce sous-graphe.

être décomposée en un graphe requête qui définit un sous-graphe q(GI) et en templates produisant le

document à partir de ce sous-graphe. L’évaluation de la requête exécute un programme SQL imbriqué Pqsur l’instance I, tel que M(Pq(I))= q(GI). Les templates décoratives peuvent être alors appliqués

au sous-graphe q(GI).

Graphe de données virtuel GI

Requête graphe −−−−−−−−−−−→ Sous-graphe q(GI) T emplates −−−−−−−−→ document M x      x      M

Base de données relationelle I −−−−−−−−−−−−−−→

programme SQL Pq

Pq(I)

F. 1.4 – Évaluation d’une requête DQL q

La description de la figure 1.4 est conceptuelle et donne lieu à plusieurs variations en pratique. En particulier, le processus d’évaluation n’est pas forcément décomposé en deux phases successives tel qu’expliqué ci-dessus, mais peut permettre une intéraction entre l’étape de matérialisation et celle de décoration. Nous pouvons noter aussi que l’imbrication des instructions associées au programme (essentiellement les boucles et les tests) et les requêtes SQL est désormais sous le contrôle total de l’évaluateur qui choisit la stratégie appropriée. Nous discutons ces aspects dans la section associée à l’évaluation.

Nous décrivons dans la section suivante, d’une manière plus formelle, le langage exprimant ce processus de navigation. Par ailleurs, nous montrons que ceci correspond, en terme de requêtes SQL intégrées, à une simple classe de programmes donnant lieu à plusieurs perspectives d’optimisation.

1.4

Le modèle

Cette section présente les définitions formelles associées à DQL : le graphe de données, le lan-gage et l’expression des règles d’évaluation des requêtes DQL.

1.4.1 Le graphe de données

Nous définissons notre langage sur une vue de la base de données relationnelle représentée sous forme de graphe de données dont nous présentons ci dessous les définitions formelles.

Soient T , R, A des ensembles de symboles disjoints deux à deux, T fini et R, A infinis. Les éléments de T sont appelés types atomiques, ceux de R sont désignés par les noms des relations et ceux de A les noms d’attributs.

Définition 1 (Schéma). Un graphe de données est un graphe dirigé étiqueté (V, E, λ, µ) ayant la structure suivante :

2. λ est une fonction d’étiquetage de E à R ∪ A tel que, si e et e0sont deux arcs ayant le même nœud initial r, alors λ_{(e) , λ(e}0) ;

3. µ est la fonction multiplicité allant de E à {1, ∗} ; si µ(e)= 1, alors il existe au plus une instance de e dans la base pour un nœud initial donné ;

si µ(e)= ∗, des instances multiples sont permises ;

4. si e ∈ E est de la forme r λ(e)→ s, avec r, s ∈ R, il existe alors un arc e0 ∈ E de la forme sλ(e

0

)

→ r, appelé l’arc inverse of e ;

string _{multiplicité 1 multiplicité *}

title string year integer paper review paper author person paper review review person string reviewMark integer string comment mark criterion reviewMark review email string string firstName lastName

F. 1.5 – Le schéma du graphe de données

Dans ce qui suit, nous adoptons la terminologie standard des graphes. Un arc e est une paire (a, b), où a est le nœud initial, dénoté initial(e) et b est le nœud terminal dénoté terminal(e). La figure 1.5 décrit le graphe du schéma de notre base exemple.

Le choix adopté ici pour la fonction d’étiquetage est celui d’associer à chaque arc r → v soit le nom de l’attribut qui lui est associé si v ∈ T , soit le nom de la table référencée si v ∈ R. En général, le schéma peut être un multi-graphe, autrement dit, deux nœuds peuvent être connectés par plus qu’un arc. Dans un tel cas, un simple mécanisme d’étiquetage associé au schéma de la figure 1.5 peut être mis en place. L’extension est triviale.

À présent, soit I un ensemble infini d’identifiants de tuples et pour chaque type atomique τ ∈ T l’ensemble des valeurs de ce type, dénoté [τ].

Définition 2 (Instance). Soit S = (V, E, λ, µ) un schéma. Une instance GI = (VI, EI) de S est le

mapping de S à un graphe étiqueté ainsi défini : 1. pour chaque v ∈ V        VI(v) ⊂ I si v ∈ R (tuple − − tuple) VI(v) ⊂ [v] si v ∈ T (tuple − − valeur)

2. si e ∈ E, alors chaque instance de e est de la forme x → y, avec x ∈ Va I(initial(e)), y ∈

VI(terminal(e)) et a = λ(e) ; de plus, si µ(e) = 1, il n’existe pas deux instances de e avec le

même nœud initial ;

3. il existe unnœud racine db dans VI tel que, pour chaque r ∈ V ∩ R et pour chaque v ∈ VI(r),

Remarques :

• Si r le nom d’une relation, VI(r) est l’ensemble des nœuds dans r.

• Tout accès à la base doit se faire par le nœud racine db, dont les arcs sortants font référence à tous les nœuds/ tuples de l’instance de la base.

1.4.2 Le langage

Nous nous concentrons désormais sur la définition du langage. Il s’agit d’un ensemble d’expressions de chemindans le graphe de données et de règles qui sont déclenchées pour chaque nœud dénoté par un chemin.

1.4.2.1 Expression de chemin

Syntaxiquement parlant, les expressions de chemins correspondent à un sous ensemble du lan-gage XPath [51]. Dans sa forme la plus simple, une expression de chemin est une séquence d’arcs étiquetés, deux à deux connectés dans un graphe schéma S . Une expression de chemin peut contenir des prédicats qui sont des combinaisons booléenes de formules atomiques de la forme q= valeur où qest une expression de chemin. Plus précisément

• si l est une étiquette ou l= db, l est une expression de chemin ;

• si q est une expression de chemin et l est une étiquette, q.l est une expression de chemin ; • si q est un chemin et p est un prédicat, q[p] est une expression de chemin.

La forme générale d’une expression de chemin est l1[p1].l2[p2]. · · · .ln[pn]. Une expression de

chemin est valuée si sa dernière étiquette est un nom d’attribut. Il est valide si le chemin dénoté par l1.l2. · · · .ln est connecté dans le schéma graphe et si chaque expression de chemin d’un prédicat est

valuée. Une expression de chemin est absolue si elle commence avec db, sinon elle est relative. Exemple 1. Voici quelques exemples d’expressions de chemin exprimées sur notre schéma exemple.

• db.paper[id = 128].review.person.lastName • db.paper[id = 128].review

• person.lastName

Une expression de chemin (valide) q est interprétée par rapport à un nœud v dans le graphe instance, dénommé le nœud initial de q. Contrairement à XPath, l’interprétation se résume au sous graphe constitué de toutes les instances de q qui sont connectées à v.

Définition 3 (Interprétation de chemin). Soit q une expression de chemin dans S , GI = (VI, EI) une

instance de S et v un nœud de VI. L’interprétation de q par rapport à GI à partir de v est le graphe

q(GI, v) = (VI(q, v), EI(q, v)) défini comme suit.

1. si q= db, EI(q, v)= ∅ et VI(q, v)= {db}.

2. si q = l, où l est une étiquette, EI(q, v) = {e ∈ EI | e est de la f orme v l

→ v0_{} et V}

I(q, v) =

3. si q= q0.l, où q0est une expression de chemin, l est une étiquette, alors        EI(q, v)= EI(q0, v) ∪ {e ∈ EI| initial(e) ∈ VI(q0, v) et λ(e) = l} VI(q, v)= VI(q0, v) ∪ {terminal(e), e ∈ EI(q, v)}

4. si q= q0[p] où q0est une expression de chemin, p est un prédicat de la forme chemin= valeur alors        VI(q, v)= {v0∈ VI(q0, v) | valeur ∈ VI(path, v0)} EI(q, v)= EI(q0, v) ∪ {e ∈ EI(q0, v) | terminal(e) ∈ VI(q, v)} 1.4.2.2 Règles

En considérant le graphe de données de la figure 1.3. L’interprétation de db.paper[id= 128].revi− ew.person.lastNameest un sous-graphe connecté composé de deux chemins avec un nœud initial db (non décrit dans la figure) et un œud terminal, respectivement « Smith » et « John ». SoitΣ un alphabet fini et ’.’ l’opérateur de concaténation dansΣ∗. Les règles sont définies comme suit :

Définition 4 (Règles). Une règle est un triplet (q, b, e), où q est une expression de chemin, b et e sont des séquences finies de mots et de règles surΣ, appelées respectivement le corps et l’exception de la règle.

Une requête est tout simplement une règle r(q, b, e) tel que q est un chemin absolu.

Définition 5 (Sémantique des règles). Soit GIune instance de S et v un nœud dans GI, appelé lenœud

initial. La sémantique [r(GI, v)] de r(q, b, e) sur GIà partir de v est définie inductivement comme suit :

1. Soit q(GI, v) = {v1, . . . , vk}, k ≥ 0, alors        si k >0, [r(GI, v)] = kb(GI, v1)k. · · · .kb(GI, vk)k sinon[r(GI, v)] = ke(GI, v)k

2. si s est une séquence de mots et de règles de la forme s₀.r₁.s₁. · · · .rn.sm, m ≥ 0, et w est un

nœud du GI, alors ks(GI, w)k = s0.[r1(GI, w)].s1. · · · .[rn(GI, w)].sn.

Comme cas particulier, la sémantique de la requête r est [r(GI, db)]. La définition est constructive.

Le nombre d’étapes est la profondeur k d’imbrication des règles dans le programme et la taille d’une étape dépend du nombre de nœuds retournés par les chemins d’une étape.

1.4.3 Syntaxe des règles et exemples

La syntaxe correcte pour les règles est @p{b}{e}. L’exception de la règle peut être omise, dans un tel cas il s’agit du caractère vide. Lorsque le chemin d’une règle est valuée (autrement dit, la dernière étiquette est le nom d’un attribut), le corps peut être aussi omis et est supposé être la valeur de l’attribut. La syntaxe présente aussi quelques extensions syntaxiques qui sont utiles en pratique. Ces extensions sont illustrées avec quelques exemples, encore basés sur le graphe de données de la figure 1.3.

1.4.3.1 Le nœud initial :’db’

La requête suivante produit un document avec le nom et le prénom des rapporteurs.

@db . P e r s o n { F i r s t name=@firstName L a s t name=@lastName }

Cette requête contient trois règles avec respectivement les trois expressions de chemin db.Pers-on, firstName and lastName. La première expression est évaluée par rapport au nœud initial db. On obtient un ensemble de chemins dont les nœuds terminaux correspondent aux tuples de la table Person. Chacun de ces nœuds est utilisé à son tour en tant que nœud initial pour l’évaluation des règles @firstName et @lastName. Nous obtenons alors la liste des noms et des prénoms des rapporteurs.

1.4.3.2 Chemin inverse ou nœud parent :’initial’

La requête suivante produit un document avec le titre de l’article 128 et les commentaires des rapporteurs : @db . P a p e r [ i d=128]{ @Review{ Comment f o r t h e p a p e r ’ @ i n i t i a l . t i t l e ’ : @comment } }

Il peut exister plusieurs rapports associés à un article, donc le titre de l’article est répété pour chaque rapport. Le résultat de cette requête sur une instance de la figure 1.3 est :

Comment f o r t h e p a p e r ’ Can c o m p u t e r t h i n k ? ’ : O u t s t a n d i n g

Comment f o r t h e p a p e r ’ Can c o m p u t e r t h i n k ? ’ : R i d i c u l o u s

Cette requête illustre un type particulier d’expression de chemin, à savoir initial, qui fait ré-férence, au sein du corps de la requête, au nœud initial de la règle d’évaluation. Dans ce cas, la règle @Review est toujours évaluée par rapport au nœud initial Paper, qui peut être référencée par le chemin relatif initial dans le corps de la règle.

Notons que initial fait toujours référence à un nœud qui a été déjà visité dans le graphe de données. Il peut être parfois équivalent à une autre expression de chemin : dans l’exemple précédent, initial est équivalent à Paper, le chemin inverse de Review. Toutefois, ceci n’est toujours pas le cas, comme le montre l’exemple suivant produisant le nom du rapporteur :

@db . P a p e r [ i d=128]{ @Review{ @Person { Comment o f @ f i r s t N a m e @lastName f o r t h e p a p e r ’ @ i n i t i a l . i n i t i a l . t i t l e ’ : @ i n i t i a l . comment } } }

Par conséquent, l’expression de chemin initial.comment dans le corps de la règle @Person n’est pas équivalent à Review.comment : le premier fait référence au nœud Review de l’article 128 (qui lui-même peut être référencé par le chemin initial.initial), alors que le deuxième fait référence aux rapports de tous les articles associés au rapporteur.

1.4.3.3 Les variables

Pour des raisons de facilité syntaxique, nous autorisons la définition de variables pour faire ré-férence au nœud initial d’une règle. La requête suivante est équivalente à la précédente, avec les variables $P et $R pour faire référence respectivement aux nœuds Paper et Review.

@db . P a p e r [ i d= 1 2 8 ] : : P{ @Review : : R{ @Person { Comment o f @ f i r s t N a m e @lastName f o r t h e p a p e r ’ P.title0:R . comment } } }

1.4.3.4 Expression de condition : si-alors-sinon

Il est possible d’exprimer des conditions moyennant des branchements du type si-alors-sinon. Il s’agit de définir un prédicat exprimant la condition, le corps de la règle pour mentionner la partie « alors » et finalement une exception définissant la partie « sinon ». L’exemple suivant subdivise l’ensemble des articles soumis en deux catégories, « acceptés » et « rejetés », selon la valeur de l’attribut accepted. @db . P a p e r { @ s e l f [ a c c e p t e d= ’Y’ ]{ The p a p e r @ t i t l e i s a c c e p t e d . } { The p a p e r @ t i t l e i s r e j e c t e d . } }

Le mot clé self est l’expression de chemin qui fait référence au nœud initial lui-même. Notons bien que la partie « exception » de la règle est instanciée lorsque l’évaluation d’une expression de chemin d’une règle retourne un ensemble vide. Le nœud initial dans la partie exception de la règle r est alors le nœud initial de r lui-même.

Il n’aurait pas été possible d’exprimer la condition de l’exemple précédent sans le mot clé self. En effet, si l’on aurait placé le prédicat directement au nœud initial (db.Paper), alors l’exception serait

engendrée lorsque l’évaluation de l’expression de chemin « @db.paper[accepted=’Y’] » retourne un ensemble vide. Cela veut dire que l’on aurait engendrée une exception quand il n’y a aucun article accepté, ce qui n’est pas le but de cet exemple.

L’exemple suivant décrit comment exprimer la négation (l’exception est instanciée pour tous les articles qui n’ont pas de rapporteur) :

@db . P a p e r [ i d=128]{ @Review{ ( . . . ) } { The p a p e r @ t i t l e h a s n o t y e t b e e n a s s i g n e d ! } }

1.5

L’évaluation des requêtes

Toute requête DQL est traduite en un programme SQL imbriqué. Ce dernier n’est autre qu’un ensemble de requêtes SQL intégrées nécessaires à l’importation des données requises depuis la base de données et d’un ensemble de routines (boucles, conditions, etc.) utiles pour la construction du document résultat.

Étant donnée que le graphe représente une vue de la base de données relationnelle, nous devons engendrer et exécuter, pour chaque requête DQL, un programme SQL imbriqué qui matérialise la partie appropriée du graphe (voir figure 1.4). Cette matérialisation peut être alors utilisée comme support pour les opérateurs de navigation (autrement dit les chemins) et l’instanciation des templates (corps et exceptions).

1.5.1 Stratégies de matérialisation

Dans un programme SQL imbriqué traditionnel, les requêtes SQL sont formulées par le program-meur et chaque requête est optimisée d’une manière indépendante. En revanche, une requête DQL ne mentionne pas les opérations SQL et fournit une vue globale des données requises pour produire le résultat. Le module interpréteur de DQL a par conséquent la liberté de produire le « meilleur » programme possible. Ici, « meilleur » peut être interprété de plusieurs manières :

1. le programme matérialise une partie du graphe de données qui est minimal par rapport aux besoin de la requête. Il s’agit en effet de matérialiser le sous-graphe nécessaire et suffisant pour la production du résultat.

2. le programme est le plus « efficace » ( ici l’efficacité peut être définie par rapport à plusieurs critères : coût entrée/sortie, coût de l’échange client/serveur, etc.) ;

La stratégie d’évaluation décrite dans cette section a pour objectif la matérialisation du sous-graphe minimal, nécessaire et suffisant pour la production du résultat. Nous essayons aussi d’éviter une matérialisation redondante (des requêtes SQL retournant le(s) même(s) tuple(s)), même si ce cas de figure peut se produire dans certains cas spécifiques (par exemple des chemins indépendants aboutissant aux mêmes nœuds).

1.5.2 Représentation en graphe requête

Nous modélisons une requête DQL q comme un graphe requête. Ce graphe représente une abstraction d’un programme SQL imbriqué qui matérialise le sous-graphe associé à l’évaluation de q. Le programme alterne des curseurs sur les résultats des requêtes SQL et des tests sur certaines valeurs de ces résultats. La représentation en graphe de la requête se fait comme suit :

1. chaque nœud est une expression de chemin ; 2. chaque arc est étiqueté avec un prédicat.

Lorsqu’une requête DQL est compilée, une représentation initiale est créée avec un nœud pour chaque règle, chaque arc étant labélisé avec true. Considérons l’exemple suivant :

@db . a { @b[ p1 ] . c . d { @e @db . h { . . . } } @b[ p2 ] . c { @f @g } } true a _h db true true b.c true true b. Aprés réécriture e p1 d p2 self f g true true a. Représentation initiale db.a b[p1].c.d db.h e true true true true b[p2].c f g true F. 1.6 – Graphes requête

La transformation directe en graphe requête est donnée dans la partie gauche de la figure 1.6. Globalement, le graphe représente le programme SQL imbriqué suivant (la syntaxe étant intuitive) :

f o r e a c h v1 i n ( SELECT ∗ FROM a ) l o o p

map ( v1 ) / / é t a b l i t l a c o r r es p o n d a nc e e n t r e l e l e t u p l e e t l e g r a p h e de d o n n é e s

f o r e a c h ( v2 i n SELECT ∗ FROM ( v1 JOIN b JOIN c JOIN d ) WHERE p1 ) l o o p map ( v2 ) f o r e a c h ( v3 i n SELECT ∗ FROM h ) l o o p map ( v3 ) end l o o p end l o o p

f o r e a c h ( v5 i n SELECT ∗ FROM ( v1 JOIN b JOIN c ) WHERE p2 )

l o o p map ( v5 ) end l o o p end l o o p

Ainsi, chaque nœud dans le graphe requête, mis à part les feuilles (correspondant aux noms d’at-tributs) représente un curseur sur le résultat d’une requête SQL. Chaque tuple est transformé selon la représentation en graphe de données en utilisant la fonction map. L’exécution du programme produit le sous-graphe à partir duquel la requête DQL peut être évaluée.

Le précédent programme est inefficace. En effet, le curseur sur la relation h, par exemple, est ré-itérée plusieurs fois. De même, la jointure entre $v1, b et c est effectuée à deux reprises. Notre objectif est de définir un ensemble de règles de réécriture afin d’éviter ces évaluations SQL redondantes ou invariantes. Pour le même exemple considéré plus haut, notre stratégie de réécriture produit le graphe requête de la partie droite de la figure 1.6. La transformation directe en tant que programme SQL imbriqué est désormais décrite comme suit :

f o r e a c h v1 i n ( SELECT ∗ FROM a ) l o o p map ( v1 )

f o r e a c h ( v2 i n SELECT ∗ FROM ( v1 JOIN b JOIN c ) ) l o o p

map ( v2 )

i f ( p1 ) , f o r e a c h v3 i n ( SELECT ∗ FROM v2 JOIN d ) l o o p map ( v3 ) end l o o p end l o o p i f ( p2 ) . . . end l o o p

f o r e a c h v4 i n ( SELECT ∗ FROM h ) map ( v4 )

La requête h est maintenant exécutée une seule fois et la jointure entre b et c est représentée comme une seule requête SQL. Ceci limite le coût de la transformation et de l’optimisation côté serveur et permet une transmission ensembliste des tuples. Le précédent programme est une transfor-mation « directe » étant donnée que chaque nœud du graphe requête est transformé en une requête SQL. Il existe plusieurs autres possibilités. Par exemple, à partir de la représentation de la figure 1.6.b, nous pouvons obtenir le programme suivant qui joint a, b et c au lieu d’utiliser une boucle imbriquée.

f o r e a c h v1 i n ( SELECT ∗ FROM a JOIN b JOIN c ) l o o p map ( v1 )

i f ( p1 ) , f o r e a c h v3 i n ( SELECT ∗ FROM v2 JOIN d ) l o o p map ( v3 ) end l o o p i f ( p2 ) . . . end l o o p f o r e a c h v4 i n ( SELECT ∗ FROM h ) map ( v4 )

L’expression map(v1) matérialise les tuples à partir de a, b et c, créant un sous-graphe qui constitue une représentation alternative de la représentation tabulaire résultante de la jointure. Ce programme exécute une seule fois la jointure a Z b Z c, au lieu de programmer un plan d’exécution qui parcourt en premier lieu la table a, puis envoie au serveur la jointure b Z c pour chaque tuple de a. La plupart des programmeurs ont tendance à opter pour cette dernière solution, étant donné que cela leurs évite le fardeau du décodage du résultat tabulaire de la jointure globale, contenant plu-sieurs données redondantes (un tuple de a doit être répété pour chaque tuple associé de b et de c). En masquant les primitives de programmation bas niveau (les tests et les boucles), le développeur a la possibilité de concevoir son programme en se basant sur des concepts appropriés (la navigation dans le graphe), mais encore, dispose de techniques de réécriture afin d’obtenir une organisation efficace et non redondante de l’échange client-serveur. Cette idée sera plus détaillée et fera l’objet du dernier chapitre de ce manuscrit.

1.5.3 Règles de réécriture

Les règles de réécriture présentées ci-dessous élaborent des techniques de réorganisation du graphe requête, résultat de la transformation directe de la requête DQL. Ces règles s’appliquent aux chemins redondants et aux chemins invariants.

Si e est une expression de chemin dans un graphe requête et e1, e2 sont deux fils de e, e1 et e2

sont redondants s’ils ont un préfixe non vide en commun. Si e1 (resp e2) est de la forme p.e0₁(resp.