200
Chapitre 8 • Construction d’une base de données
problème est simple, un utilisateur un tant soit peu habile pourra exprimer directement ses besoins en termes de tables, colonnes et contraintes.
Cependant, lorsque le domaine d’application présente une certaine complexité, il
devient difficile, voire périlleux, de raisonner à son sujet en termes de tables et de
colonnes. En effet, une base de données réelle contiendra plusieurs centaines de
tables, dotées chacune de plusieurs dizaines de colonnes. Sans même envisager de
telles bases de données, qui restent le domaine d’activité réservé des informaticiens
spécialisés en systèmes d’information, il n’en reste pas moins qu’un niveau de
raisonnement indépendant des outils de gestion de données tels que les SGBD SQL
s’avère rapidement utile, voire indispensable 1 . C’est pour cette raison qu’on fera
appel à un autre mode de description du domaine d’application, le modèle Entitéassociation. Ce modèle, qui est le plus populaire à l’heure actuelle, permet de
décrire plus naturellement les concepts du domaine, sans s’attacher à la manière
dont ils seront représentés en tables et colonnes. Il offre en particulier une représentation graphique des concepts qu’il décrit, ce qui en fait un outil de raisonnement et
de spécification particulièrement attrayant. La description du domaine s’exprimera
sous la forme d’un schéma conceptuel.
Nous utiliserons une variante simplifiée du modèle Entité-association et nous
adopterons des conventions graphiques plus simples que celles qui sont communément admises. On consultera par exemple [Bodart, 1994], [Batini, 1992], ou les
différentes références sur MERISE [Nancy, 1996] pour une définition de modèles
plus complets. Certaines extensions du modèle présenté seront cependant mentionnées dans la section 7.8 tandis que le modèle de classes d’UML 2 est étudié dans la
section 7.9.
Le schéma conceptuel est un modèle mental, abstrait, et n’est donc pas directement implantable dans un ordinateur. Il faut par conséquent le traduire en un schéma
de base de données sous la forme de tables, de colonnes et de contraintes d’intégrité.
Ici encore, nous limiterons le processus de traduction à des règles simples et systématiques. On trouvera dans [Hainaut, 1986], [Batini, 1992], [Blaha, 1998] et
[Akoka, 2001] une description plus complète de ce processus.
La démarche de conception de bases de données proposée consiste donc en deux
phases (figure 8.1) :
• l’analyse conceptuelle, durant laquelle les besoins en information des utilisateurs sont traduits en un schéma conceptuel;
• la production de la base de données, par laquelle le schéma conceptuel est
traduit en structures de tables exprimées en SQL.
1. Il existe d’autres arguments en faveur d’un niveau d’abstraction supérieur. Citons entre autres
le fait que les mêmes structures de données peuvent être réalisées à l’aide d'autres outils que les
SGBD SQL : SGBD orientés-objet ou relationnels-objet, SGBD plus anciens tels que CODASYL
ou IMS, fichiers classiques, tableurs, XML, etc.
2. Variante du modèle Entité-association dérivée des approches orientées-objets.
Chapitre 8 • Construction d’une base de données
problème est simple, un utilisateur un tant soit peu habile pourra exprimer directement ses besoins en termes de tables, colonnes et contraintes.
Cependant, lorsque le domaine d’application présente une certaine complexité, il
devient difficile, voire périlleux, de raisonner à son sujet en termes de tables et de
colonnes. En effet, une base de données réelle contiendra plusieurs centaines de
tables, dotées chacune de plusieurs dizaines de colonnes. Sans même envisager de
telles bases de données, qui restent le domaine d’activité réservé des informaticiens
spécialisés en systèmes d’information, il n’en reste pas moins qu’un niveau de
raisonnement indépendant des outils de gestion de données tels que les SGBD SQL
s’avère rapidement utile, voire indispensable 1 . C’est pour cette raison qu’on fera
appel à un autre mode de description du domaine d’application, le modèle Entitéassociation. Ce modèle, qui est le plus populaire à l’heure actuelle, permet de
décrire plus naturellement les concepts du domaine, sans s’attacher à la manière
dont ils seront représentés en tables et colonnes. Il offre en particulier une représentation graphique des concepts qu’il décrit, ce qui en fait un outil de raisonnement et
de spécification particulièrement attrayant. La description du domaine s’exprimera
sous la forme d’un schéma conceptuel.
Nous utiliserons une variante simplifiée du modèle Entité-association et nous
adopterons des conventions graphiques plus simples que celles qui sont communément admises. On consultera par exemple [Bodart, 1994], [Batini, 1992], ou les
différentes références sur MERISE [Nancy, 1996] pour une définition de modèles
plus complets. Certaines extensions du modèle présenté seront cependant mentionnées dans la section 7.8 tandis que le modèle de classes d’UML 2 est étudié dans la
section 7.9.
Le schéma conceptuel est un modèle mental, abstrait, et n’est donc pas directement implantable dans un ordinateur. Il faut par conséquent le traduire en un schéma
de base de données sous la forme de tables, de colonnes et de contraintes d’intégrité.
Ici encore, nous limiterons le processus de traduction à des règles simples et systématiques. On trouvera dans [Hainaut, 1986], [Batini, 1992], [Blaha, 1998] et
[Akoka, 2001] une description plus complète de ce processus.
La démarche de conception de bases de données proposée consiste donc en deux
phases (figure 8.1) :
• l’analyse conceptuelle, durant laquelle les besoins en information des utilisateurs sont traduits en un schéma conceptuel;
• la production de la base de données, par laquelle le schéma conceptuel est
traduit en structures de tables exprimées en SQL.
1. Il existe d’autres arguments en faveur d’un niveau d’abstraction supérieur. Citons entre autres
le fait que les mêmes structures de données peuvent être réalisées à l’aide d'autres outils que les
SGBD SQL : SGBD orientés-objet ou relationnels-objet, SGBD plus anciens tels que CODASYL
ou IMS, fichiers classiques, tableurs, XML, etc.
2. Variante du modèle Entité-association dérivée des approches orientées-objets.