03.08.2013 Views

Rapport de fin de phase I - Haute école du paysage, d'ingénierie et ...

Rapport de fin de phase I - Haute école du paysage, d'ingénierie et ...

Rapport de fin de phase I - Haute école du paysage, d'ingénierie et ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

elationnel. Il est aussi possible <strong>de</strong> les utiliser pour partager <strong>de</strong>s références sur <strong>de</strong>s<br />

obj<strong>et</strong>s volumineux <strong>et</strong> ainsi économiser <strong>de</strong> l'espace <strong>de</strong> stockage. La majorité <strong>de</strong>s critiques<br />

liées aux pointeurs sont justifiées, mais il serait dommage <strong>de</strong> se priver <strong>de</strong> leurs<br />

avantages au niveau <strong>de</strong>s SGBD, uniquement à cause <strong>de</strong> ces critiques, d'autant plus que<br />

les problèmes qui leurs sont liés sont connus, <strong>et</strong> donc évitables.<br />

1.9.2. Apports <strong>du</strong> modèle obj<strong>et</strong><br />

• L'i<strong>de</strong>ntité d'obj<strong>et</strong>:<br />

L’i<strong>de</strong>ntité d’obj<strong>et</strong> appelé OID (Object I<strong>de</strong>ntifier) perm<strong>et</strong> <strong>de</strong> référencer <strong>de</strong> manière unique<br />

dans une base <strong>de</strong> données n'importe quel obj<strong>et</strong> <strong>de</strong> c<strong>et</strong>te base. Il perm<strong>et</strong> aussi l'utilisation<br />

<strong>de</strong> pointeurs sur l'obj<strong>et</strong>. Ces pointeurs perm<strong>et</strong>tent <strong>de</strong> créer <strong>de</strong>s structures complexes<br />

d'obj<strong>et</strong>s (graphes, chaînes) <strong>et</strong> aussi <strong>de</strong> parcourir <strong>de</strong>s suites d'associations très<br />

rapi<strong>de</strong>ment car elles ne <strong>de</strong>man<strong>de</strong>nt plus l'utilisation <strong>de</strong> jointures longues <strong>et</strong> coûteuses.<br />

• L'encapsulation <strong>de</strong>s données:<br />

L’encapsulation a pour but <strong>de</strong> présenter une structure <strong>de</strong> données stable à l'utilisateur,<br />

même si la structure interne <strong>de</strong> la base change complètement. Les données, au lieu<br />

d'être directement accessible par l'utilisateur, sont cachées <strong>et</strong> <strong>de</strong>s métho<strong>de</strong>s perm<strong>et</strong>tant<br />

la lecture <strong>et</strong> la modification sont mises en place.<br />

C<strong>et</strong>te couche d'abstraction entre les données <strong>et</strong> l'utilisateur facilite gran<strong>de</strong>ment la tâche<br />

<strong>du</strong> programmeur, qui peut gérer comme il le désire son application en interne avec pour<br />

seule contrainte la fourniture d'une interface stable à l'utilisateur.<br />

• L'héritage:<br />

L’héritage perm<strong>et</strong> la réutilisation <strong>de</strong>s types <strong>de</strong> données, car il perm<strong>et</strong> la dé<strong>fin</strong>ition<br />

d'obj<strong>et</strong>s génériques (tables, types <strong>de</strong> données abstraits) pouvant être spécialisés suivant<br />

les utilisations. Il facilite le travail <strong>du</strong> développeur qui ne doit plus se soucier <strong>de</strong>s détails<br />

d'implémentation pour chaque obj<strong>et</strong>.<br />

1.9.3. Le modèle obj<strong>et</strong>-relationnel<br />

Le modèle obj<strong>et</strong>-relationnel se fon<strong>de</strong> sur l'extension <strong>du</strong> modèle relationnel par les<br />

concepts essentiels <strong>de</strong> l'obj<strong>et</strong>. Le cœur <strong>du</strong> système reste donc relationnel, mais tous les<br />

concepts clés <strong>de</strong> l'obj<strong>et</strong> y sont ajoutés dans une forme particulièrement prévue pour<br />

faciliter l'intégration <strong>de</strong>s <strong>de</strong>ux modèles. On peut citer en particulier, le support <strong>de</strong>s obj<strong>et</strong>s<br />

complexes qui est sans aucun doute, l'apport le plus important <strong>de</strong> ce modèle. Il a été<br />

intro<strong>du</strong>it pour perm<strong>et</strong>tre le support <strong>de</strong>s types <strong>de</strong> données ne respectant pas la première<br />

forme normale <strong>de</strong> Boyce-Codd, aussi appelé NF 2 (Not First Normal Form). Ainsi tous les<br />

types <strong>de</strong> données multimédias peuvent aussi être considérés comme <strong>de</strong>s types <strong>de</strong><br />

données complexes, par exemple <strong>de</strong>s données cartographiques ou géométriques<br />

nécessitent <strong>de</strong>s colonnes <strong>de</strong> tables capables <strong>de</strong> stocker <strong>de</strong>s listes <strong>de</strong> points.<br />

Faisant suite à la proposition <strong>du</strong> modèle persistant obj<strong>et</strong> appelé manifeste, le modèle<br />

relationnel obj<strong>et</strong> est principalement basé sur <strong>de</strong>ux références incontournables.<br />

Le second manifeste ou contre-manifeste, dont le principal auteur, Stonebraker place les<br />

SGBD obj<strong>et</strong>s comme ne possédant pas <strong>de</strong> langage d'interrogation.<br />

Dans le troisième manifeste, Date <strong>et</strong> Darwen proposent une base théorique à<br />

l'intégration <strong>de</strong>s concepts obj<strong>et</strong>s dans un contexte relationnel. Ils affirment que<br />

l'utilisation <strong>de</strong> pointeurs dans les bases <strong>de</strong> données obj<strong>et</strong>-relationnelles brise la notion<br />

22.06.2005 10/78

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!