Les BDBO répondent aux besoins de gérer une quantité volumineuse de données décrites par ré-férence à des ontologies (données à base ontologique). Elles permettent de stocker, dans une base de données, des ontologies et les instances qu’elles décrivent. Les instances peuvent être structurées par un schéma comme dans une base de données traditionnelle. Les éléments de ce schéma sont alors liés à une ontologie pour en définir la sémantique. Le schéma des instances peut être construit à partir de l’ontolo-gie. Il peut également avoir été conçu indépendamment d’une ontologie (indexation sémantique). Dans les BDBO utilisant une représentation générique (binaire ou verticale) pour les instances, celles-ci sont directement liées à une ontologie sans être structurées par un schéma significatif pour un utilisateur de la base de données. Néanmoins, dans bien des cas, le schéma des données, implicite dans ces repré-sentations, pourrait être explicité. La tendance actuelle des BDBO est de gérer des données de plus en plus volumineuses, de séparer ontologies et données, et de permettre d’importer/exporter ontologies et données représentées avec différents modèles d’ontologies.
5 Conclusion : application du concept d’ontologie aux bases de données
Ayant analysé le concept d’ontologie, les modèles d’ontologies et les BDBO dans le contexte des bases de données, nous allons maintenant conclure ce chapitre en proposant un apport des ontologies aux bases de données.
Un des buts essentiels d’une base de données est d’une part d’assurer une gestion efficace des don-nées et d’autre part de permettre l’accès aux dondon-nées indépendamment de leur représentation physique. L’architecture ANSI/SPARC [ANSI/X3/SPARC, 1975] a été proposée pour remplir ces objectifs. Elle distingue les deux niveaux d’accès suivants :
– le niveau physique. Il définit comment les données sont stockées et gérées en utilisant le système de gestion de fichiers ;
– le niveau logique. Il définit comment les données sont structurées en utilisant le modèle de données de la base de données (par exemple, le modèle relationnel ou objet).
La conception d’une base de données suivant cette architecture passe par la transformation d’un modèle conceptuel en un modèle logique. Cette transformation s’accompagne d’une perte de sémantique des données ce qui pose des problèmes lorsque, par exemple, il est nécessaire d’échanger des données entre deux bases de données, ou de générer une interface d’accès aux données pour un utilisateur final.
En tant que modèle permettant d’exprimer la sémantique des données, les ontologies semblent une solution pertinente à ces problèmes. Dans ce chapitre, l’analyse que nous avons effectuée des multiples
notions d’ontologie que l’on rencontre actuellement dans la littérature nous ont conduit aux résultats suivants :
– la description sémantique des données par une ontologie peut se faire selon trois couches (cano-niques, non canoniques et linguistiques) que l’on peut lier selon le modèle en oignon (cf. sec-tion 2) ;
– les modèles d’ontologies sont complémentaires pour la conception d’ontologies et possèdent tous un noyau commun (cf. section 3) ;
– les BDBO permettent de gérer un volume important de données à base ontologique. La tendance actuelle des BDBO est de séparer ontologie et données. Le faible typage proposé par les modèles d’ontologies tels que OWL conduit à des structures de BDBO où le schéma des données, au sens traditionnel des bases de données, n’est pas représenté. En pratique, dans beaucoup de cas, les données sont néanmoins fortement typées. Ceci est même obligatoire avec les ontologies PLIB et F-Logic. Il est donc raisonnable de s’intéresser aux BDBO qui permettent la représentation du schéma des données pour chaque classe d’une ontologie. Ceci permet d’aborder différents pro-blèmes de bases de données tels que la conception de bases de données, l’indexation sémantique de bases de données ou l’intégration de bases de données à l’aide de ces structures (cf. section 4). Ces trois résultats nous ont conduits à généraliser les architectures de BDBO existantes en proposant l’extension de l’architecture ANSI/SPARC avec le niveau ontologique. Ce niveau définit la sémantique des données. Il est constitué des descriptions sémantiques fournies par une ontologie. Il peut être décom-posé selon les trois couches du modèle en oignon. Il n’est pas lié à un modèle d’ontologies particulier. Cette architecture étendue est présentée sur la figure 1.12.
Niveau physique Niveau logique Niveau conceptuel
Niveau physique Niveau logique
Niveau ontologique OL OCNC OCC
(A) Architecture traditionnelle des bases de données (B) Architecture proposée Aspect conceptuel
F. 1.12 – Notre proposition d’architecture de bases de données
L’architecture traditionnelle de bases de données est présentée dans la partie (A) de cette figure, située à gauche. Un modèle conceptuel représenté dans un formalisme tel que le modèle Entité/Relation est conçu. Il est ensuite souvent utilisé pour générer automatiquement le modèle logique des données constitué d’un ensemble de tables dans les SGBD relationnels ou relationnels-objets. Ce modèle logique est lui même représenté au niveau physique à l’aide d’un ensemble de fichiers.
Dans la partie (B) nous proposons l’extension de cette architecture en intégrant les deux éléments suivants :
– le niveau ontologique. Il est composé d’ontologies qui définissent les concepts de différents do-maines d’étude sous la forme de classes et de propriétés. Ces ontologies sont indépendantes des besoins des applications pour lesquelles la base de données est conçue. Cependant, ces ontolo-gies peuvent être spécialisées pour représenter les éventuels concepts manquants par rapport à ces besoins. Lorsqu’elles sont conçues selon le modèle en oignon, ces ontologies comportent tou-jours une couche canonique. Elles peuvent éventuellement comporter une couche non canonique. Elles comportent toujours un minimum d’aspects linguistiques et, en particulier, des termes qui dénotent les concepts représentés ;
– l’aspect conceptuel. Cet aspect est représenté par le lien entre le niveau ontologique et le niveau logique. Ce lien indique l’ensemble des concepts des ontologies qui sont exploités pour satis-faire les besoins des applications pour lesquelles la base de données est conçue. Cet ensemble de concepts, une fois choisi, peut être utilisé pour générer automatiquement le modèle logique des données.
Le problème abordé dans cette thèse est de fournir un langage de définition, manipulation et inter-rogation de données pour l’architecture ANSI/SPARC étendue que nous proposons. Les trois niveaux de cette architecture (physique, logique et ontologique) sont actuellement implantés dans différentes ap-proches avec des techniques différentes comme l’a montré notre étude des BDBO. Cependant, peu de travaux se sont intéressés à la définition d’un langage d’exploitation qui (1) soit homogène, c’est-à-dire qu’il permette l’accès aux différents niveaux significatifs pour un utilisateur de cette architecture et (2) tire profit des spécificités de ces différents niveaux. En effet, outre le langage SQL qui a été défini pour permettre d’exploiter les niveaux physique et logique de l’architecture ANSI/SPARC, d’autres langages comme SPARQL [Prud’hommeaux and Seaborne, 2006] ou RQL [Karvounarakis et al., 2002] ont été définis. Mais, ces nouveaux langages n’exploitent pas les caractéristiques particulières des différents ni-veaux définis par cette extension de l’architecture ANSI/SPARC. Nous montrons ceci dans le chapitre suivant en identifiant les besoins d’exploitation induits par l’architecture de bases de données proposée.