28
Chapitre 2 • Introduction
considérer comme formant la famille principale de SGBD, renvoyant les autres vers
des niches confidentielles. Cette situation découle sans doute des qualités intrinsèques du modèle relationnel et du langage SQL, mais aussi, plus prosaïquement, d’un
phénomène irrésistible de standardisation. Les arguments sont imparables : portabilité des applications, indépendance par rapport au fournisseur du SGBD, stabilité de
la formation, mobilité et interchangeabilité des développeurs, disponibilité d’outils
annexes, pour n’en citer que quelques-uns. SQL fait d’ailleurs l’objet d’efforts constants de normalisation au niveau de l’ANSI, mais aussi de l’ISO [ANSI, 1989], dont
il est le membre le plus actif. Nous verrons cependant que le concept de norme est
interprété avec beaucoup de sens poétique par les éditeurs de SGBD. Les extensions
vont actuellement (via la norme SQL:1999) vers une intégration avec le Web, un
enrichissement des structures de données, le couplage avec le langage Java et XML,
l’intégration de fonctions de gestion de données multimédia et de données spatiales,
ainsi que des fonctions de fouille de données ( data mining ).
2.3 CONSTRUCTION D’UNE BASE DE DONNÉES
L’interrogation, voire la gestion, d’une base de données sont donc désormais à la
portée de l’utilisateur averti et motivé. Qu’en est-il de la construction elle-même de
la base de données? Cette activité est traditionnellement le domaine réservé des
informaticiens. Ils disposent en effet non seulement de modèles et de méthodes
spécifiques qui leur permettent de définir progressivement les structures de la base
de données, mais ils utilisent aussi des outils qui les aident dans cette activité : les
ateliers logiciels. Le lecteur en contact avec des informaticiens aura sans doute
entendu parler du modèle Entité-association, de la méthode MERISE, des notations
UML ou des ateliers d’ingénierie logicielle AMC-Designor, Power-Designer, Rose,
Designer-2000 ou MEGA, pour n’en citer que quelques-uns.
Toutes les méthodes de conception sont basées sur la même idée : découpler
l’analyse du problème de l’implantation de la solution dans une machine. L’analyse
du problème conduit au schéma conceptuel de la base de données, qui est une solution abstraite, c’est-à-dire indépendante de la technologie, et qui s’exprime le plus
souvent sous une forme graphique du modèle Entité-association 3 . La seconde phase,
l’implantation, consiste à traduire le schéma conceptuel en une structure de tables et
en instructions SQL de création de ces tables. Le lecteur pressé comparera la
figure 12.1, qui décrit de manière abstraite la gestion d’un parc zoologique, avec le
texte SQL qui définit les tables devant contenir les données relatives à cette gestion
(section 12.2.4).
S’il est hors de question, dans un tel ouvrage, de tenter de former l’utilisateur à
ces méthodes et à ces outils, il est cependant possible d’en retirer un ensemble de
3. Appelé également Entité-Relation , ou Individuel ou Entity-Relationship . On utilise aussi le
terme de modèle de classes (UML), emprunté aux approches orientées-objets, mais qui recouvre
un concept similaire.
Chapitre 2 • Introduction
considérer comme formant la famille principale de SGBD, renvoyant les autres vers
des niches confidentielles. Cette situation découle sans doute des qualités intrinsèques du modèle relationnel et du langage SQL, mais aussi, plus prosaïquement, d’un
phénomène irrésistible de standardisation. Les arguments sont imparables : portabilité des applications, indépendance par rapport au fournisseur du SGBD, stabilité de
la formation, mobilité et interchangeabilité des développeurs, disponibilité d’outils
annexes, pour n’en citer que quelques-uns. SQL fait d’ailleurs l’objet d’efforts constants de normalisation au niveau de l’ANSI, mais aussi de l’ISO [ANSI, 1989], dont
il est le membre le plus actif. Nous verrons cependant que le concept de norme est
interprété avec beaucoup de sens poétique par les éditeurs de SGBD. Les extensions
vont actuellement (via la norme SQL:1999) vers une intégration avec le Web, un
enrichissement des structures de données, le couplage avec le langage Java et XML,
l’intégration de fonctions de gestion de données multimédia et de données spatiales,
ainsi que des fonctions de fouille de données ( data mining ).
2.3 CONSTRUCTION D’UNE BASE DE DONNÉES
L’interrogation, voire la gestion, d’une base de données sont donc désormais à la
portée de l’utilisateur averti et motivé. Qu’en est-il de la construction elle-même de
la base de données? Cette activité est traditionnellement le domaine réservé des
informaticiens. Ils disposent en effet non seulement de modèles et de méthodes
spécifiques qui leur permettent de définir progressivement les structures de la base
de données, mais ils utilisent aussi des outils qui les aident dans cette activité : les
ateliers logiciels. Le lecteur en contact avec des informaticiens aura sans doute
entendu parler du modèle Entité-association, de la méthode MERISE, des notations
UML ou des ateliers d’ingénierie logicielle AMC-Designor, Power-Designer, Rose,
Designer-2000 ou MEGA, pour n’en citer que quelques-uns.
Toutes les méthodes de conception sont basées sur la même idée : découpler
l’analyse du problème de l’implantation de la solution dans une machine. L’analyse
du problème conduit au schéma conceptuel de la base de données, qui est une solution abstraite, c’est-à-dire indépendante de la technologie, et qui s’exprime le plus
souvent sous une forme graphique du modèle Entité-association 3 . La seconde phase,
l’implantation, consiste à traduire le schéma conceptuel en une structure de tables et
en instructions SQL de création de ces tables. Le lecteur pressé comparera la
figure 12.1, qui décrit de manière abstraite la gestion d’un parc zoologique, avec le
texte SQL qui définit les tables devant contenir les données relatives à cette gestion
(section 12.2.4).
S’il est hors de question, dans un tel ouvrage, de tenter de former l’utilisateur à
ces méthodes et à ces outils, il est cependant possible d’en retirer un ensemble de
3. Appelé également Entité-Relation , ou Individuel ou Entity-Relationship . On utilise aussi le
terme de modèle de classes (UML), emprunté aux approches orientées-objets, mais qui recouvre
un concept similaire.