BD Relationnelles versus BD Objets Fariza Tahi

SGBD Relationnels Avantages des SGBD Relationnels (SGBDR) : simplicité des concepts et du schéma un bon support théorique, la théorie des ensembles un haut degré d’indépendance des langages de manipulation de haut niveau, SQL (langage déclaratif) amélioration de l’intégrité et de la confidentialité optimisation des requêtes d’accès à la BD.

SGBD Relationnels Limites et inconvénients des SGBDR: trop grande simplicité du modèle, adapté pour des données à structure simple, pour des applications traditionnelles …. -> nécessité de modèles de données possédant un pouvoir d’expression plus riche pour les applications manipulant des objets complexes tels que le multimédia, la biologie, etc. des langages de manipulation trop limités malgré leur puissance relative ; les langages déclaratifs de haut niveau des SGBDR (SQL) ne permettent pas de programmer entièrement une application (on doit connecter à SQL des langages traditionnels comme JAVA, PHP, …).

Limites et inconvénients des SGBDR (suite): la normalisation permet de construire des BD en limitant des redondances d’information ; -> accroissement des liens par les clés étrangères et les tables de corrélation -> jointures -> coût - Pas de traitement des objets complexes ; stockage possible sous forme de BLOBs (Binary Large Objects) mais pas de requêtes car leur contenu n’est pas compréhensibles par le SGBDR.

Les Bases de Données à Objets Une Base de Données à objets peut être décrite par spécification d’un schéma de classes, incluant les définitions de classes, d’attributs et d’opérations, ainsi que les liens entre les classes. La notion de base de données à objets s’est précisé au début des années 90. Pour mériter le nom de SGBD objet (SGBDO), un système doit d’abord supporter les fonctionnalités d’un SGBD. Pour ce faire, il doit obligatoirement assurer :

La persistance des objets : tout objet doit pouvoir persister sur disque au-delà du programme qui le créé. Un objet peut être persistant ou transient. Objet persistant : objet stocké dans la base de données et dont la durée de vie est supérieure au programme qui le créé. Objet transient : objet restant en mémoire, dont la durée de vie ne dépasse pas celle du programme qui le créé.

La concurrence d’accès : la base doit pouvoir être partagée simultanément par les transactions qui la consultent et la modifient. La fiabilité des objets : les objets doivent être restaurés en cas de panne d’un programme, dans l’état où ils étaient avant la panne. Les transactions doivent être atomiques, c.a.d. totalement exécutées ou pas du tout. La facilité d’interrogation : il doit être possible de retrouver un objet à partir de valeurs de ses propriétés.

SGBD Orienté Objets Avantages des SGBDOO : Capacité de gérer des données persistantes grâce à l’intégration d’un langage de programmation orienté objet avec les fonctionnalités d’un SGBD. Langages de définition des données (ODL : Object Definition Language) et de manipulation des données (OML : Object Manipulation Language contenant OQL : Object Query Language). Capacité d’accéder à une grande quantité de données de façon performante. Sécurité : les objets peuvent être privés ou publics.

SGBD Orientés Objets Inconvénients des SGBDOO : Problèmes techniques : optimisation des requêtes nécessite de connaître l’implantation des objets. problème de portabilité sur plusieurs types de plateformes, d’évolution du schéma, de la gestion de la concurrence d’accès. Carences de OQL, et faible compatibilité avec SQL. Résistance organisationnelle

Intégration de l’objet au relationnel Pourquoi intégrer l’objet au relationnel ? Faiblesses du modèle relationnel : Absence de pointeurs visibles par l’utilisateur Non support de domaines composés Non intégration des opérations Apport des modèles objets : L’identité d’objet permet l’introduction de pointeurs invariants pour chaîner les objets entre eux. L’encapsulation des données permet d’isoler certaines données dites privées. L’héritage d’opérations et de structures facilite la réutilisation des types de données.

Les SGBD Relationnels Objets et SQL3 Les SGBD Relationnels Objets (SGDBRO) : combinaison d’un moteur relationnel et d’un système objet. SGBDOO : permettent des requêtes simples sur des objets complexes. - SGBDR : permettent des requêtes complexes sur des objets simples. => SGBDRO : tout type de requête sur tout type d’objet. Exemples : PostgreSQL, Oracle 8i, Sybase 11. SQL3 : extension de SQL2 par l’intégration de propriétés objets au relationnel.

Concepts objets additionnés au relationnel Types de données utilisateur : Permettent la définition de types extensibles utilisables comme domaines et supportant l’encapsulation. => Le système n’est plus limité aux types alphanumériques de base. Ils sont appelés « types abstraits » (ADT) en SQL3. Patron de collections : Type de données générique permettant de supporter des attributs multivalués et de les organiser selon un type de collection. Ex : tableau, liste, ensemble, etc. Le patron LISTE(X) par exemple pourra être instancié pour définir des lignes sous forme de listes de points : Lignes LISTE(point).

Concepts objets additionnés au relationnel (suite) Référence d’objet : type de données particulier permettant de mémoriser l’adresse invariante d’un objet ou d’un tuple. Ce sont les identifiants d’objets (OID). Héritage de type : forme d’héritage impliquant la possibilité de définir un sous-type d’un type existant, celui-ci héritant alors de la structure et des opérations du type de base. On a ainsi la possibilité de définir un sous-type d’un type SQL ou d’un type utilisateur. Héritage de table : forme d’héritage impliquant la possibilité de définir une sous-table d’une table existante, celle-ci héritant alors de la structure et des opérations de la table de base.

Extension du langage de requêtes : SQL3 1/ Les types abstraits (ADT : abstract data type): Commande CREATE TYPE Syntaxe : CREATE [DISTINCT] TYPE <nom ADT> [WITH OID VISIBLE] [UNDER <super-type>, [,<super-type>…] [AS] (<corps de l’ADT>); Le mot clé DISTINCT est utilisé pour renommer un type de base existant déjà. Ex : CREATE DISTINCT TYPE num-agence AS (char (5)); La clause WITH OID VISIBLE permet de préciser la visibilité de l’OID pour chaque instance. Par défaut, une instance de type est une valeur sans OID.

Les types abstraits (suite) : La clause UNDER <super-type>, [,<super-type>…] permet de spécifier les super-types dont le type hérite. < corps de l’ADT> se compose d’une ou plusieurs clauses membres : <clause membre> := <définition de colonne> <clause égale> <clause inférieur> <clause cast> <déclaration de fonction> <déclaration d’opérateur>

Les types abstraits (suite) : <déclaration d’opérateur> : fonction particulière déclarée comme opérateur. <déclaration de fonction> : permet de définir les fonctions publiques qui encapsulent le type. Il existe différents types de fonctions : - constructeurs : permettent de construire des instances du type. Elles portent en général le nom du type. - destructeurs : détruisent les instances et doivent être appelés explicitement pour récupérer la place disque ( pas de ramasse miettes)

Les types abstraits (suite) : - acteurs : agissent sur une instance en manipulant les attributs du type. On peut distinguer : les observateurs : qui ne font que lire l’état les mutateurs : qui le modifient. Syntaxe d’une fonction : [CONSTRUCTOR/ACTOR/DESTRUCTOR] FUNCTION <nom fonction> <liste paramètres> RETURNS <résultats fonction> {<procédure SQL>/<nom fichier>} END FUNCTION

Les types abstraits (suite) : <corps de l’ADT> : <définition de colonne> : permet de spécifier les attributs du type sous la forme <nom> <type>. Un type peut être un type de base ou un type précédemment créé par une commande : CREATE TYPE. <clause égale> : permet de définir l’égalité de deux instances du type. <clause inférieur> : définit le comparatif <, important pour comparer et ordonner les valeurs de type. <clause cast> : permet de convertir le type dans un autre type.

Ce sont des types génériques fournis par SQL3. 2/ Les constructeurs d’objets complexes : Ce sont des types génériques fournis par SQL3. Ce sont : SET, MULTISET, LIST. SQL3 propose aussi des types additionnels multiples : piles (stack), files (queue), tableaux dynamiques (varray), tableaux insérables (irray) Ces types sont optionnels : ils ne sont pas intégrés dans le langage de base mais peuvent être ajoutés .

3/ Les tables : Les tables sont inchangées et restent comme dans le SQL de base, sauf que le domaine d’un attribut peut être un type créé par la commande CREATE TYPE. On peut aussi encapsuler des fonctions. Il est possible de créer une table à partir d’un type. Ex : CREATE TABLE Employés OF Employés. On peut créer en même temps une table et un type. Ex : CREATE TABLE personne (nss int, nom varchar, …) of NEW TYPE personne; L’héritage est possible : Ex : CREATE TABLE <Table> UNDER <Table> [WITH (liste d’attributs typés)]

4/ L’appel des fonctions et des opérateurs dans les requêtes : SQL3 permet l’appel de fonctions dans les termes SQL. Ex : SELECT E.nom, age(E) FROM employé E WHERE age (E) < 35. La notation « .. » permet aussi d’accéder aux attributs composés. Ex : SELECT nom WHERE E.adresse..ville= « Marseille »