Ces dernières années, le domaine des bases de données a beaucoup évolué. De nombreux modèles ont émergé de part et d'autre : XML, ODBMS, Map Reduce... Ces modèles ont pour objectif de résoudre les problèmes existants du modèle relationnel. Et pourtant, aucun n'a réussi à détrôner SQL, la variante la plus connue du modèle relationnel. Cela révèle tout d'abord un problème vis-à-vis du modèle relationnel tel qu'implémenté par SQL qui ne s'adapte pas à toutes les applications. Cela révèle aussi l'incapacité des nouveaux modèles à pallier les lacunes de SQL tout en conservant ses forces : son expressivité et sa capacité à assurer l'intégrité des données. Ces caractéristiques restent primordiales pour de nombreuses applications et ne peuvent donc pas être ignorées. Notre intuition est donc qu'il ne faut pas totalement mettre de côté le modèle relationnel de Codd [10], mais plutôt l'améliorer. Étant donné que seul le langage relationnel SQL a su s'imposer, l'évaluation des SGBD relationnels s'est toujours faite en ne considérant que celui-ci. De plus, les bancs d'essai existants considèrent le facteur de l'efficience comme le plus important à évaluer, probablement car c'est le critère qui dépend davantage de l'implémentation du langage faite par les SGBD que des variantes dialectiques du langage. Nous nous sommes donc donnée [i.e. donnés] pour objectif de définir un banc d'essai plus large permettant d'évaluer des modèles relationnels différents en prenant en compte des critères plus variés et tout aussi importants tels que la validité, la disponibilité, la sécurité et l'expressivité. Le banc d'essai ainsi défini a été implémenté pour deux SGBDR basés sur SQL : Oracle et PostgreSQL. L'implémentation pour des SGBDR basés sur des modèles différents étant laissée pour des travaux futurs. Les résultats obtenus nous ont tout d'abord permis de démontrer la pertinence de notre banc d'essai. Malgré le fait que les deux SGBD soient basés sur le langage SQL, le banc d'essai a révélé des différences pour la majorité des critères définis. Ainsi, Oracle se démarque en ce qui concerne la validité des données. Contrairement à PostgreSQL, il ne présente pas de lacunes pouvant compromettre l'intégrité des données. Oracle se démarque aussi en ce qui concerne la sécurité. Les mécanismes présents y sont plus complets et plus flexibles. PostgreSQL, lui, se démarque par rapport à l'expressivité du dialecte SQL utilisé. Des fonctionnalités primordiales sont présentes tandis qu'elles sont absentes sous Oracle. Au niveau de l'efficience, nos résultats révèlent une différence quant à la gestion des optimisations, car selon les fonctionnalités testées, le SGBD le plus efficient est différent. Cependant, aucun des SGBD ne se démarque. Pour finir, en ce qui concerne le critère de disponibilité des données, les résultats sont identiques pour les deux SGBD. Cette identification des lacunes propres à ces deux SGBD nous permettra par la suite de tirer des enseignements de ces problèmes de manière à ne pas les reproduire pour notre nouveau modèle.
| Identifer | oai:union.ndltd.org:usherbrooke.ca/oai:savoirs.usherbrooke.ca:11143/5742 |
| Date | January 2012 |
| Creators | Ottavi, Aurélie |
| Contributors | Lavoie, Luc |
| Publisher | Université de Sherbrooke |
| Source Sets | Université de Sherbrooke |
| Language | French |
| Detected Language | French |
| Type | Mémoire |
| Rights | © Aurélie Ottavi |
Page generated in 0.0091 seconds