I.4.SGBD
a) Définition
Un Système de Gestion de Base de Données est un
ensemble de logiciels de haut niveau qui permettent de définir, de
créer et de manipuler les informations stockées dans une base de
données16.
En Informatique, un système de gestion de
base de données (abr. SGBD) est un logiciel
système destiné à stocker et à partager des
informations dans une base de données, en garantissant la
qualité, la constance et la confidentialité des informations,
tout en cachant la complexité des opérations17.
Un SGBD (en anglais DBMS pour data base
management system) permet d'inscrire, de retrouver, de modifier, de trier,
de transformer ou d'imprimer les informations de la base de données. Il
permet d'effectuer des comptes rendus des informations enregistrées et
comporte des mécanismes pour assurer la cohérence des
informations, éviter des pertes d'informations due à des pannes,
assurer la confidentialité et permettre son utilisation par d'autres
logiciels1. Selon le modèle, le SGBD peut comporter une
simple interface graphique jusqu'à des langages de programmation
sophistiqués.
Les systèmes de gestion de base de données sont
des logiciels universels, indépendants de l'usage qui est fait des bases
de données. Ils sont utilisés pour de nombreuses applications
informatiques, notamment ; les guichets automatique bancaires. Il existe de
nombreux
- 21 -
systèmes de gestion de base de données.
En 2008, Oracle détenait près de la moitié du
marché des SGBD avec MySQL et Oracle Data base. Vient
ensuite IBM avec près de 20 %, laissant peu de place pour les autres
acteurs3.
Les SGBD sont souvent utilisés par d'autres
logiciels ainsi que les administrateurs ou les
développeurs. Ils peuvent être sous forme de composant
logiciel, de serveur, de logiciel applicatif ou
d'environnement de programmation.
b) Evolution des SGBD
Comme beaucoup de technologies de l'informatique aujourd'hui
matures, les bases de données relationnelles sont nées des
travaux d'IBM entre les années 1960 et 1970. De nombreuses recherches
ont été menées au cours de cette période sur des
modèles de données hiérarchiques, réseaux et
relationnels.
Au cours des vingt dernières années,
l'évolution des Systèmes de Gestion de Bases de Données
s'est effectuée en trois étapes :
· SGBD relationnels mettant en oeuvre les théories
de Codd (INGRES par exemple) ;
· SGBD orientés objet afin de coller à la
conception et la programmation objet (O2 par exemple) ;
· SGBD relationnel objet (Oracle et IBM DB2 par
exemple).
1. SGBD relationnels
Voici ce qui fait le succès des SGBDR :
- Le modèle de données relationnel repose sur une
théorie rigoureuse (théorie des bases
de données et algèbre relationnelle) avec des
principes simples.
- L'indépendance données/traitements
améliore la maintenance des programmes
d'application (la modification
d'une structure de données a peu de répercussion en
théorie sur les programmes).
- Les données de la base sont indépendantes du
système d'exploitation et des couches
bases réseaux.
- La gestion des privilèges mixe éléments
de la base de données et actions pour une
sécurité
maximale.
- Les systèmes sont bien adaptés aux grandes
applications informatiques de gestion et
ont acquis une maturité sur
le plan de la fiabilité et des performances (évolution
d'échelle - « sociabilité »).
- 22 -
- Le langage SQL est puissant et concis ; il peut souvent
s'interfacer avec des langages
de troisième génération (C, Ada, Cobol),
mais aussi avec des langages plus récents (C ++, Java, C#).
- Les systèmes répondent parfaitement à
des architectures de type client-serveur
(passerelles ODBC et JDBC
notamment) et intranet ou Internet (configurations à plusieurs couches,
ou tiers).
Les limitations de la majorité des systèmes actuels
sont les suivantes :
- La simplicité du modèle de données et le
fait que le langage SQL soit natif et
déclaratif nécessitent d'interfacer le SGBDR
avec un langage de programmation évolué. De ce fait, le dialogue
entre la base et le langage n'est plus direct et implique de maîtriser
plusieurs technologies.
- La faible capacité de modélisation fait que
seules les structures de données tabulaires
sont permises. Il est
ainsi difficile de représenter directement des objets complexes.
- La normalisation conduit à l'accroissement du nombre
de relations. Ainsi, si deux
objets doivent être liés en
mémoire, il faut simuler ce lien au niveau de la base par un
mécanisme de clés étrangères ou de tables de
corrélations. Parcourir un lien implique souvent une jointure dans la
base. Il en résulte un problème de performance dès que le
style d'interrogation devient navigable : manipulation d'arbres, de graphes ou
toute autre application mettant en relation un grand nombre d'objets.
Ce dernier point est d'ailleurs moins crucial aujourd'hui
qu'autrefois. Les éditeurs ont, pour la plupart, trouvé des
algorithmes et des techniques pour rendre les jointures très
performantes, notamment en améliorant les techniques d'indexation et en
fournissant des générateurs de clés, au prix, cependant,
d'un léger décalage entre un modèle théorique
parfait et un modèle physique performant.
2. SGBD objet
Gemstone a été le premier SGBD objet,
dérivé du langage Smalltalk. Des produits commerciaux existent,
citons db4o, Objectivity, ObjectStore, Orient, Ozone, FastObjects, Versant
(produit issu du système O2). Ces systèmes permettent de
manipuler des objets persistants. Ils concernent un segment très
limité du marché des SGBD. Parallèlement à ces
initiatives individuelles, l'ODMG (Object Data base Management Group) propose
une API objet standard s'adaptant à tout SGBD par passerelles C ++, Java
et Small talk. En 1998, les compagnies qui soutenaient l'action de l'ODMG
étaient Computer
- 23 -
Associates, Object Design, Versant, Poet, Objectivity, Ardent
Software et Objectmatter. L'ODMG a soumis à la communauté Java la
partie « Java Binding » pour définir la spécification
JDO (Java Data Objects).
3. SGBD relationnel objet
La technologie relationnelle objet est apparue en 1992 avec
les SGBD UNISQL et Open ODB d'Hewlett-Packard (appelé par la suite
adopter). En 1993, la firme Montage Systems (devenue Illustra) achète la
première version commerciale du système Postgrès. À
la fin de l'année 1996, Informix adopte la technologie objet avec
l'achat du SGBD d'Illustra. La stratégie d'Informix repose sur la
spécialisation exclusive du SGBD. Il se différencie d'autres
éditeurs comme Oracle qui propose, outre son serveur de données,
une offre que certains jugent disparate (outils de messagerie, AGL, etc.). En
juillet 1995, IBM inclut des aspects objets dans DB2 puis rachète
Informix en 2001. Oracle 8 propose en juin 1997 des aspects objets mais les
premières versions (avant la 8.1.7) étaient bien limitées
en termes de fonctionnalités au niveau des méthodes et
l'héritage n'était pas supporté. Microsoft SQL Server
n'offre pas de fonctions objet dans son langage SQL.
En revanche, il permet d'intégrer des objets et
méthodes à SQL via un langage de la plateforme .NET, par
l'intermédiaire d'un run time (CLR, ou Common LanguageRuntime). Computer
Associates propose à son catalogue le produit Jasmine (fruit des travaux
menés depuis 1996 avec Fujitsu). Le système PostgreSQL est un
autre dérivé du SGBD objet Postgres développé en
1986 à l'université de Berkeley par les concepteurs d'Ingres.
PostgreSQL est aujourd'hui un SGBD libre (open source) fourni avec la
majorité des distributions Linux. Il est à noter que SAP DB (SGBD
libre issu du logiciel Adabas) propose des extensions objet. D'autres produits
commerciaux existent, citons UniSQL, Matisse, ObjectSpark.
Le succès de cette approche provient de :
? L'encapsulation des données des tables. Les
méthodes définies sur les types
composant les tables permettent de programmer explicitement
l'encapsulation (il faudra, simultanément, que le programmeur interdise
les accès directs aux objets par SQL).
? La préservation des acquis des systèmes
relationnels (indépendance données/traitements), fiabilité
et performances, compatibilité ascendante : l'utilisation de tables
relationnelles est possible à travers des vues objet, et leur mise
à jour à travers des procédures stockées.
- 24 -
? L'enrichissement du langage SQL par des extensions qui sont
désormais normalisées
(SQL : 1999).
? La mise en oeuvre des concepts objets (classes,
héritage, méthodes) qui ont
indéniablement
démontré leur intérêt dans la maintenance des
applications (modularité extensibilité et
réutilisabilité).
Les risques qu'encourent les programmeurs à tout miser
sur cette nouvelle façon de programmer les données mais aussi les
traitements sont les suivants :
? Le modèle de données ne repose plus sur une
théorie rigoureuse et sur des principes
simples. Il s'affranchit, par exemple, de la première
forme normale. La conception peut ainsi induire plus facilement des
redondances, synonymes de problèmes potentiels d'intégrité
des données et de performances dégradées.
? À l'exception d'IBM DB2 qui est fortement calé
sur la norme SQL : 1999, les
différents éditeurs n'ont pas
adopté une syntaxe commune pour décrire les extensions
proposées, d'autant plus que la norme autorise la coexistence de
langages externes pour l'utilisation d'objets dans SQL. En conséquence,
la migration d'une base relationnelle objet d'un SGBD vers un autre est un
travail très difficile.
? Le fait de migrer une base relationnelle vers l'objet pourra
se faire en douceur en
utilisant les vues objet. En revanche, le retour en
arrière sera bien plus périlleux. Il est possible mais fort peu
probable que la théorie de la normalisation évolue de
manière simple afin de prendre en compte ces nouveaux concepts.
Ces derniers sont aujourd'hui les plus répandus car ils
constituent une approche mixte (comme les langages C ++ ou java) reconnue et
entérinée par la norme SQL, car proposant une évolution
souple vers l'objet, en conservant les avantages et la simplicité de
l'approche relationnelle.
| 
