SGBD relationnelsobjets

1
SGBD relationnels-objets

• Partie II architectures et concepts

2
Modules à modifier (I)

• Modules à modifier
• méthodes d'accès et de stockage
• "parser"
• optimiseur
• moteur d'exécution
• paralléliseur

fonction
Select name from EMP where beard(picture) gt 0.7
and age gt 60 and location in
circle ((10,10),5)
point
opérateur
3
Modules à modifier (II)

• méthodes d'accès index méthode de classement
  on ne classe pas des images comme des données
  alphanumériques
• définir des index adaptés aux nouveaux types de
  données
• fonder les index sur des fonctions
• "parser" nouveaux types gt nouvelles opérations
  légales
• optimiseur optimiser définir le meilleur plan
  d'exécution possible gt statistiques
  (sélectivité/coûts des nouveaux
  opérateurs/fonctions)

4
Modules à modifier (III)

• moteur d'exécution opérateurs/fonctions
  défini(e)s désormais par l'utilisateur gt plus
  possible de coder en "dur" ltgt liaison dynamique
  indispensable
• parallélisme nouveaux types de données gt
  nouvelles heuristiques de répartition et de
  traitement

5
Architectures (I)

• I- Plugs-in
• avec connexion vers des modules externes définis
  par l'utilisateur
• II- Intégration SGBD - Serveurs ad hoc

S1
S2
S3
SGBD
API
API
API
6
Architectures (II)

• III-Simulateur
• IV- Redéfinir un système "from scratch"

Module d'intégration
Moteur SQL
Simulateur d'objets
S1
S2
S3
SGBD
7
Architectures (III)

• V- Garder le gestionnaire de données, le moteur
  transactionnel et le module de reprise après
  panne et modifier les autres modules

8
Proposition d'Oracle data cartridges

• 1 ou plusieurs types spécifiques à un domaine
  (attributs, méthodes (PL/SQL, Java, C...)
• Définition de nouveaux types d'index
• structure d'index
• stockage d'index (dans/hors SGBD)
• gestion/utilisation des index
• Définition de nouveaux opérateurs
• utilisables dans des requêtes SQL
• généralement liés à des fonctions spécifiques
• informations pour l'optimiseur
• statistiques (index spécifiques gt stats
  spécifiques)
• sélectivités (opérateurs, fonctions, méthodes
  spécifiques)
• coûts (CPU, E/S, réseau)

9
Proposition d'Informix data blades

• Collections d'(objets code) ( librairie C)
• Types de données spécifiques à une application
  avec héritage de méthodes
• Fonctions opérant sur les nouveaux types de
  données
• Index et méthodes d'accès intégrables
• Codes client API pour accéder à la base de
  données

10
Proposition d'IBM/DB2 extenders

• Packages spécifiques à certaines
  applications-cibles
• Types/opérateurs/méthodes
• Approche de type intégration de modules

11
Proposition de SYBASE Adaptative Server/Java
(component integration layer)

• Java virtual machine JDBC interface intégrés
• Objets Java ? tuples relationnels (classes
  colonnes)
• Packages spécifiques à certaines applications
  (SIG, multimédia, données dynamiques (time
  series)...)

12
Discussion (I)

• Le modèle objet est très puissant
• héritage
• polymorphisme
• surcharge d'opérateurs
• souplesse/généricité
• dynamicité
• formalisation
• Cependant, un SGBD-OO n'est qu'un SGB-Données
• absence de notion de point de vue
• pas de contradiction possible
• pas d'évolutivité
• pas d'incertitude
• pas de schémas cognitifs

13
Discussion (II)

• Modèles relationnels-objets
• différentes architectures pour différents besoins
• architecture intégrée/simulation/connexions
  externes
• packages "carrés" vs modules utilisateur
• langages ?
• efficacité ?
• cibles applicatives
• convergence extensions intégrées, architecture
  intégrée, langages diversifiés
• pb de performance intrinsèque aux classes
  utilisateur
• marché porteur et bien identifié vendeurs
  "lourds"

14
Discussion (III)

• Perspectives
• au-delà de l'objet convergence BDD/BDC
• BDD-OO ???
• logiques, algèbres et BDD
• intégration de services et coopération
• nouvelles applications