Bases de Données Relationnelles (SGBDR

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.
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
FROM employé E
WHERE E.adresse..ville= « Marseille »