UML 2 pour les bases de données
12
© Éditions Eyrolles
Que sont devenus les SGBD objet ?
Pendant un temps, les défenseurs de l’objet ont cru que les SGBD du même nom pourraient
supplanter, voire remplacer, les systèmes relationnels. Le marché leur a donné tort. Les systèmes
purement objet semblent cantonnés à des applications manipulant des données non structurées
avec des programmes écrits dans des langages objet. Ils concernent ainsi un segment très limité
du marché des SGBD.
Historique
Le premier SGBD objet a été Gemstone [COP 84], extension du langage objet Smalltalk.
Certains produits commerciaux existent, citons Java Data Objects de GemStone, FastObjects
de Poet Sofware, Ontos, Objectstore d’Object Design, Objectivity, Versant.
Les SGBD objet n’ont pas bénéficié de l’environnement d’exploitation performant auquel les
SGBD relationnels ont habitué les responsables informatique : requêtes efficaces, volume important d’informations à stocker, fiabilité, sauvegarde et restauration, performances transactionnelles
OLTP (On Line Transaction Processing), outils complémentaires, etc.
Les éditeurs de SGBD objet n’ont pas eu le succès qu’ils attendaient pour la bonne et simple
raison que l’existant des données des entreprises est toujours sous la forme relationnelle et
qu’aucun principe formel de migration n’a été et ne sera probablement jamais établi.
Structure des données
Alors que le modèle relationnel manipule des informations sous forme tabulaire, l’une des
principales extensions du modèle de données objet (reprise par le modèle objet-relationnel)
consiste à manipuler des structures de données complexes incluant des pointeurs et des tables
imbriquées (collections).
Les pointeurs facilitent la fonction de navigation dans le langage de requêtes en réduisant
considérablement le nombre de jointures. Les tables imbriquées permettent de s’affranchir de
la règle de la première forme normale, à savoir qu’un attribut peut être composé d’une liste de
valeurs. Le modèle de données est dit « NF2 » (Non First Normal Form) [MAK 77]. Les liens
entre objets se réalisent à l’aide d’OID (Object Identifier), qui sont des pointeurs physiques.
Certains détracteurs prétendent qu’avec ce modèle de données, on est revenu près de trente ans
en arrière au bon vieux temps des SGBD hiérarchiques.
Les SGBD objet-relationnels
Afin de rester en compétition avec les solutions voisines, les éditeurs de SGBD relationnels
ont, dans un premier temps, offert la possibilité de stocker des informations non structurées
dans des champs appelés « BLOB » (Binary Large OBject). Dans un second temps, ils ont
étendu le modèle relationnel à un certain nombre de concepts objet. Ce nouveau modèle hybride
a été appelé « objet-relationnel » (plus rarement relationnel-objet).
12
© Éditions Eyrolles
Que sont devenus les SGBD objet ?
Pendant un temps, les défenseurs de l’objet ont cru que les SGBD du même nom pourraient
supplanter, voire remplacer, les systèmes relationnels. Le marché leur a donné tort. Les systèmes
purement objet semblent cantonnés à des applications manipulant des données non structurées
avec des programmes écrits dans des langages objet. Ils concernent ainsi un segment très limité
du marché des SGBD.
Historique
Le premier SGBD objet a été Gemstone [COP 84], extension du langage objet Smalltalk.
Certains produits commerciaux existent, citons Java Data Objects de GemStone, FastObjects
de Poet Sofware, Ontos, Objectstore d’Object Design, Objectivity, Versant.
Les SGBD objet n’ont pas bénéficié de l’environnement d’exploitation performant auquel les
SGBD relationnels ont habitué les responsables informatique : requêtes efficaces, volume important d’informations à stocker, fiabilité, sauvegarde et restauration, performances transactionnelles
OLTP (On Line Transaction Processing), outils complémentaires, etc.
Les éditeurs de SGBD objet n’ont pas eu le succès qu’ils attendaient pour la bonne et simple
raison que l’existant des données des entreprises est toujours sous la forme relationnelle et
qu’aucun principe formel de migration n’a été et ne sera probablement jamais établi.
Structure des données
Alors que le modèle relationnel manipule des informations sous forme tabulaire, l’une des
principales extensions du modèle de données objet (reprise par le modèle objet-relationnel)
consiste à manipuler des structures de données complexes incluant des pointeurs et des tables
imbriquées (collections).
Les pointeurs facilitent la fonction de navigation dans le langage de requêtes en réduisant
considérablement le nombre de jointures. Les tables imbriquées permettent de s’affranchir de
la règle de la première forme normale, à savoir qu’un attribut peut être composé d’une liste de
valeurs. Le modèle de données est dit « NF2 » (Non First Normal Form) [MAK 77]. Les liens
entre objets se réalisent à l’aide d’OID (Object Identifier), qui sont des pointeurs physiques.
Certains détracteurs prétendent qu’avec ce modèle de données, on est revenu près de trente ans
en arrière au bon vieux temps des SGBD hiérarchiques.
Les SGBD objet-relationnels
Afin de rester en compétition avec les solutions voisines, les éditeurs de SGBD relationnels
ont, dans un premier temps, offert la possibilité de stocker des informations non structurées
dans des champs appelés « BLOB » (Binary Large OBject). Dans un second temps, ils ont
étendu le modèle relationnel à un certain nombre de concepts objet. Ce nouveau modèle hybride
a été appelé « objet-relationnel » (plus rarement relationnel-objet).