© Éditions Eyrolles
7
Introduction
Bougez pas !… Les mains sur la table ! Je vous préviens
qu’on a la puissance de feu d’un croiseur et des flingues
de concours.
Les Tontons flingueurs, B. Blier
G. Lautner, dialogues M. Audiard, 1963
Dans cette introduction, nous verrons pourquoi il est encore nécessaire de travailler avec des
systèmes de gestion de bases de données relationnels et comment ces systèmes ont évolué
pour inclure peu à peu certains concepts de l’approche objet. Nous expliquerons aussi pourquoi
le diagramme de classes d’UML s’est imposé en tant que notation, comme support du modèle
conceptuel, en remplacement du modèle entité-association.
Évolution des SGBD relationnels
On pourrait croire que le modèle relationnel a maintenant vécu tant il semble inadapté à la
gestion d’informations de plus en plus complexes. Élaboré en 1969 par E.F. Codd [COD 69],
chercheur chez IBM, ce modèle est à l’origine des premiers SGBD relationnels, devenus des
systèmes incontournables.
Certains éditeurs comme IBM ou Oracle ayant près de 30 ans d’expérience, leurs produits sont
assurément d’une grande fiabilité. Standardisé, SQL, le langage utilisé, peut s’interfacer avec
des langages de troisième génération (C, Cobol...), mais aussi avec des langages plus évolués
(comme C++ ou Java).
Ces systèmes intègrent des outils de développement comme les précompilateurs, les générateurs
de code, d’états ou de formulaires. Enfin, ces systèmes répondent bien à des architectures de
type client-serveur et Intranet ou Internet. Ces architectures présentent une interface utilisateur
(le plus souvent graphique), fonctionnent grâce à des applications dont une partie s’exécute
sur le client et l’autre sur le serveur, et manipulent des données. L’adoption généralisée du
client-serveur repose sur le besoin croissant de services réclamés par la partie cliente. Les
grands éditeurs de progiciels profitent ainsi de l’occasion pour se concentrer, côté serveur, sur
le cœur des applicatifs et sur l’optimisation des moteurs de bases de données (aspects transactionnels, montée en charge, équilibrage). Il reste donc à programmer, du côté client, les
aspects de présentation des données et d’interfaces graphiques.
7
Introduction
Bougez pas !… Les mains sur la table ! Je vous préviens
qu’on a la puissance de feu d’un croiseur et des flingues
de concours.
Les Tontons flingueurs, B. Blier
G. Lautner, dialogues M. Audiard, 1963
Dans cette introduction, nous verrons pourquoi il est encore nécessaire de travailler avec des
systèmes de gestion de bases de données relationnels et comment ces systèmes ont évolué
pour inclure peu à peu certains concepts de l’approche objet. Nous expliquerons aussi pourquoi
le diagramme de classes d’UML s’est imposé en tant que notation, comme support du modèle
conceptuel, en remplacement du modèle entité-association.
Évolution des SGBD relationnels
On pourrait croire que le modèle relationnel a maintenant vécu tant il semble inadapté à la
gestion d’informations de plus en plus complexes. Élaboré en 1969 par E.F. Codd [COD 69],
chercheur chez IBM, ce modèle est à l’origine des premiers SGBD relationnels, devenus des
systèmes incontournables.
Certains éditeurs comme IBM ou Oracle ayant près de 30 ans d’expérience, leurs produits sont
assurément d’une grande fiabilité. Standardisé, SQL, le langage utilisé, peut s’interfacer avec
des langages de troisième génération (C, Cobol...), mais aussi avec des langages plus évolués
(comme C++ ou Java).
Ces systèmes intègrent des outils de développement comme les précompilateurs, les générateurs
de code, d’états ou de formulaires. Enfin, ces systèmes répondent bien à des architectures de
type client-serveur et Intranet ou Internet. Ces architectures présentent une interface utilisateur
(le plus souvent graphique), fonctionnent grâce à des applications dont une partie s’exécute
sur le client et l’autre sur le serveur, et manipulent des données. L’adoption généralisée du
client-serveur repose sur le besoin croissant de services réclamés par la partie cliente. Les
grands éditeurs de progiciels profitent ainsi de l’occasion pour se concentrer, côté serveur, sur
le cœur des applicatifs et sur l’optimisation des moteurs de bases de données (aspects transactionnels, montée en charge, équilibrage). Il reste donc à programmer, du côté client, les
aspects de présentation des données et d’interfaces graphiques.