Ontologies et Bases de Données

Un schéma conceptuel de bases de données peut être vu comme une micro-ontologie, ou ontologie

du micro-domaine concerné. Définir les entités en jeu – de quoi on parle – et les relations qui les

lient, constitue la première étape d’une analyse. Cependant, contrairement aux ontologies où les

entités sont censées représenter les concepts d’un domaine indépendamment de toute application,

les entités d’un schéma conceptuel sont déterminées en fonction d’un objectif précis : la base de

données que l’on souhaite mettre en place, qui répond à des besoins déterminés. D’autres besoins

conduiraient à une autre organisation des données et donc à un schéma conceptuel différent. Aussi,

afin de respecter des contraintes informatiques, telles que l’unicité des données, l’optimisation des

accès, etc., les entités définies dans un schéma conceptuel de base de données peuvent ne pas

correspondre directement aux concepts d’une ontologie du domaine.

On peut noter que les modèles les plus utilisés actuellement pour la conception de schémas

conceptuels de bases de données, modèle Entité/Association et diagramme de classes UML, se

sont éloignés de la vision ontologique de l’univers concerné pour y introduire d’emblée des notions

liées à l’usage informatique qui va en être fait, telles que le choix des concepts qui doivent être

implémentés par des classes qui vont guider la programmation (Simonet 2010). Par ailleurs, les

outils de CAO (Conception Assisté par Ordinateur) privilégient la fonction d’édition de schéma

conceptuel (on sait ce que l’on veut et on le « dessine ») par rapport à la fonction d’aide à la

conception, c’est-à-dire l’aide à l’organisation des données et des programmes pour répondre à un

ensemble de besoins déterminé qu’il faut d’abord appréhender.

Nous illustrons cette opinion par un exemple simple, où il s’agit de modéliser les concepts

concernant les lieux où des interventions chirurgicales ont lieu. Nous considérons deux concepts :

Centre de santé et Niveau. Une représentation « naturelle » sous forme d’ontologie consiste à

représenter ces concepts et leurs interrelations (Figure 15).

Figure 15 : diagramme ontologique : concepts et relations

Dans une description ontologique, les concepts Centre de santé et Niveau jouent un rôle symétrique.

aPourCentre (Niveau, Centre de santé). On remarquera qu’une relation a toujours une relation inverse,

même si elle n’est pas explicitement nommée.

On peut aussi apporter des précisions sur deux catégories de contraintes qui sont en jeu dans ce

diagramme :

 contraintes de cardinalité (Figure 16), indiquant pour une relation R(A, B) les cardinalités

minimale et maximale de l’ensemble d’éléments de B associés par R à un élément de A.

Ainsi, la cardinalité de la relation aPourNiveau (Centre de santé, Niveau) étant (1,1), un centre de

santé a un et un seul niveau. Par ailleurs, la relation centreDeNiveau (Niveau, Centre de santé)

ayant une cardinalité (0, *), à un niveau peuvent correspondre plusieurs centres de santé,

éventuellement aucun.

 contraintes de domaine : Niveau  {Niveau1, Niveau2, Niveau3}

Figure 16: diagramme ontologique avec contraintes de cardinalité

En utilisant un modèle tel que celui d’UML, qui offre les concepts de classe et de sous-classe,

d’attribut, d’association, etc., le concepteur d’un schéma conceptuel de bases de données est

naturellement amené à définir des classes d’objets avec leurs attributs et les associations entre

classes. Pour cela, il doit choisir de représenter chaque concept de son univers par une classe

(sous-classe) ou par un attribut. En général, cette décision est soit une conséquence de son expérience

dans un domaine utilisant une ontologie « semblable », soit un réflexe qui tend à faire représenter

par une classe des abstractions de collections d’objets du monde physique. Par exemple, les centres

de santé ayant une existence physique, le concepteur d’un schéma conceptuel de bases de données

aura tendance à proposer la classe CentreDeSanté (cf. diagramme 1) et à considérer niveau comme

l’un de ses attributs.

Diagramme 1 : implémentation standard du concept Centre de Santé

On remarquera que l’on a perdu la symétrie initiale du diagramme ontologique et que l’on a aussi

perdu l’information que Niveau est un concept dont l’existence est indépendante du concept de

Centre de santé. Représenter Niveau comme un attribut de Centre de santé fait donc perdre à l’utilisateur

de cette micro-ontologie sa vision d’un monde réel disposant des concepts de Niveau et de Centre de

santé.

Par contre, dans l’univers des langages de programmation, si l’une des requêtes à privilégier est

« centres de Niveau3 d’une région (par exemple de l’Isère) », un programmeur expert proposera

plutôt le Diagramme 2 car il sait que l’un des chemins qu’il sera amené à privilégier est celui qui relie

Niveau à Centre de santé, chemin qui, pour un niveau donné, conduit aux centres de santé de ce

niveau.

Diagramme 2 : implémentation du concept Centre de Santé, optimisée pour la requête « Centres d’un niveau donné »

On remarquera que si à l’usage on s’aperçoit que le temps de réponse de la requête « centres de

Niveau3 d’une région (de l’Isère) » est trop important, l’administrateur de la base peut créer un

index sur l’attribut niveau afin d’obtenir un temps de réponse acceptable.

L’usage de modèles tels que le modèle de classe UML ou le modèle Entité-Association

sous-tendent donc des choix informatiques implicites dès la conception, et avant même que les besoins

spécifiques d’une application basée sur une telle ontologie aient été explicités. Ainsi, les choix

effectués sont fortement dépendants de l’expérience et du domaine d’expertise de celui qui est à

l’origine des choix. Comme nous le verrons plus loin, dans un modèle Relationnel-Binaire tel que

ISIS, cette « optimisation » informatique peut être faite automatiquement dès lors que l’on souhaite

générer un Système d’Information basé sur « une partie » d’une ontologie et qu’on a défini les

fonctionnalités attendues au travers de requêtes graphiques sur l’ontologie.