Bases de Données Réparties - LP GSR 2007/2008

Transcription

Bases de Données :
ARCHITECTURES CLIENT – SERVEUR
Bases de Données Réparties
Couches de connectivités ODBC
Architectures 2 Tiers et 3 Tiers
n
n
n
Licence GSR
Franck Le Douarin
J.Siroux
LP/cours/cours1_ue62
1
Sommaire
BDD - ARCHITECTURES CLIENT – SERVEUR
n
1. Les différentes architectures
è
è
è
è
n
2. Les Bases de données Réparties
è
è
è
è
n
A quoi cela sert-il ?
L’état de l’art des éditeurs
Niveau Physique
Niveau logique d’implémentation
3. Mise en application d’ODBC sur un client Windows
è
è
è
è
n
1.1. Architecture 2-Tiers
1.2. Architecture 3-Tiers
1.3. ODBC et JDBC
1.4. Bases de données réparties
Séquence Pas à Pas
Renseignement des données
Test d’application
Tuning et optimisation
4. Différences majeures entre JDBC et ODBC
J.Siroux
2
1. Les différentes architectures
è
è
è
Architecture 2-Tiers
Architecture 3-Tiers
Couche de connectivité ODBC et JDBC
l ODBC = Open DataBase Connectivity (MS, IBM, Borland, Novell):
Librairie de fonctions appelées à partir d'applications sous
Windows. Accès à tout SGBD Relationnel (ou tableur, ou fichiers) à
condition de disposer d'un pilote (ODBC Driver). En général les
éditeurs de SGBD fournissent le pilote ce qui permet une ouverture
vers de nombreuses applications.
l
è
JDBC pour Java, Web & BD : interface avec le SGBD
Bases de données réparties
l Une base de données répartie est un assemblage de différentes
bases de données mises en relations les unes avec les autres à
travers un réseau d'ordinateurs.
J.Siroux
3
2. Bases de données réparties
è
Plusieurs actions de recherches et de développement depuis
le milieu des années 70
è
Prototypes et produits commerciaux années 80
è
Différents aspects :
- BD Relationnelles et BD Orientées Objets,
- Architectures de Systèmes et de Machines
- SGBD sur tout type de machine (serveur au Palm !)
- Réseaux Locaux et Généraux (LAN, WAN),
- Clients/Serveurs et Architectures n -tiers
- BD mobiles
- Parallélisme des données et des traitements
J.Siroux
4
Client / Serveur BD
n Client : Terminal ou Station de Travail
n
Station de Travail: capacité de traitement et de stockage
n
Protocole CLIENT - SERVEUR
CLIENT : gestionnaire d'interface BD
CLIENT & SERVEUR : gestionnaire des communications
n
n
Protocoles de communication Client/Serveur : exemple RPC
Choix de transfert données ou requêtes (function shipping vs
data shipping) ==> différentes architectures
J.Siroux
5
Architectures distribuées & Serveurs de BD
n RPC = Remote Procedure Call (OSI), demande d'exécution
(a)synchrone et distante de procédure
n RDA = Remote Data Access (SQL Access Group OSI92)
requête et
exécution asynchrone, spécialisée SQL2
n Accès à différents SGBD (CLI: Call Level Interface)
n ODBC et JDBC
n SGBD Orientés Objets et Serveurs d'Objets (ou de pages)
(exemple, O2)
n Notion de "middleware"
J.Siroux
6
Systèmes relationnels et serveurs SQL
n SGBD RELATIONNELS :Informix, Oracle, SQL Server, Sybase, DB2...
n Serveurs parallèles : DBC / 1012 (Data Base Computer, Teradata)
- Basé sur SQL
- Architecture par passage de messages (de 2 à 1024 noeuds - Intel
n
80386)
- Réseau organisé en arbre de processeurs (Y net)
- Supporte différents hôtes (MVS, VM/CMS, UNIX, etc.)
NONSTOP -SQL (Tandem)
- SQL et UNIX
- Architecture par passage de messages (de 2 à 32 noeuds de
processeurs spécialisés)
- "Fault tolerant architecture" : tout est en double
J.Siroux
7
• Interface usager & code
de l’application
• Code du SGBD
• Système d’exploitation
• Une seule ou plusieurs
machines
• Différents composants
reliés par un moyen de
communication (bus,
canal, réseau)
J.Siroux
8
Composants distribués
è
è
è
è
è
è
è
Problème de construction d’applications
Réutilisation de composants
Objets, Composants
Composants distribués (médiateurs)
Rôles des langages à objets (C++, Java)
Outils divers et Web
Serveur d’Application
Caractéristiques générales
è
è
è
è
Architecture distribuée, client/serveur, parallèle
WEB et architectures 3-tier (3 strates)
Langages SQL, LP+ (C, C++, Java, etc.)
Support de nouveaux types de données dont le
multimédia (datablades, extenders, cartridges)
è
è
è
Extensibilité et modularité
Méthodes d’accès spécifiques (eg. spatial)
Data warehouse & Data mining
J.Siroux
9
Serveurs d’applications
n
Equivalents modernes des Moniteurs Transactionnels (TP Monitors)
Tous, sauf Microsoft sont basés sur Java 2 Enterprise Edition (J2EE)
Produits: BEA WebLogic , IBM WebSphere, Oracle9i Application Server,
Sun ONE (iPlanet), Sybase EAServer , HP, Iona, Hitachi, NEC, Computer
Associates, ..., Microsoft .NET
Open Source: JBoss, JOnAS
J2EE is to Java what SQL was to databases"
WithoutJ2EE, it is not an application server«
n
Différences sur :
Facilité d’utilisation, passage à l’échelle, disponibilité, fiabilité, intégration des
données existantes (legacy data), produits complémentaires (ex, personalisation,
commerce, workflow)
J.Siroux
10
BDR = BD + RESEAU
n Nombreuses applications permettant de concilier centralisation
des données pour accès locaux et mise en place des applications
faisant intervenir des données décentralisées.
Cas de grosses entreprises ou organismes ayant des agences
géographiquement distribuées:
n
- Banques, transferts électroniques
- Fabrication (plusieurs usines)
- Médicales (ex :. Banques d'organes)
- Militaires...
- Systèmes de réservation de compagnies aériennes
- Chaînes d'hôtels
- Systèmes d'information dans une organisation décentralisée
J.Siroux
11
Avantages:
n
n
n
données locales traitées localement
fiabilité plus grande (plusieurs machines indépendantes)
construction progressive, disponibilité accrue si duplication sur
plusieurs sites.
Deux mots clés : PARTIONNEMENT & DUPLICATION
Ils s'appliquent à différents niveaux :
n données
n schémas ou catalogues ou dictionnaires de la BD
n SGBD (composants logiciels, le code du système)
n machine (composants matériels: les processeurs, les
mémoires et les disques)
J.Siroux
12
n
n
Plusieurs approches des BDR, selon :
1/ les caractéristiques du réseau (général, local),
2/ la coopération de données existantes,
3/ la répartition contrôlée des données,
4/ l'homogénéité ou l'hétérogénéité des systèmes locaux.
5/ l'évolution de l'architecture des machines (parallélisme)
6/ l'évolution de l'architecture des systèmes (client / serveur)
QUESTION : cacher ou non la répartition aux utilisateurs ?
Différentes réponses selon les approches, les applications, les
environnements, etc.
- "location transparency"
- "partition transparency"
- "duplication transparency"
J.Siroux
13
n
Approche descendante: (Distributed DB, schéma de
gauche) découper une BD en plusieurs Bases Locales
n
Approche ascendante: (Multidatabase, schéma de droite)
faire coopérer des BD existantes
J.Siroux
14
J.Siroux
15
J.Siroux
16
Photographies ou Snap-Shots
n
n
n
n
En général, les photos locales ne sont accessibles qu'en lectu re.
La seule opération qui modifie la photo est le rafraichissement.
Méthode brutale = ré-executer la requête qui définit la photo
Appliquer les Deltas :P = Q(R1, R2, …Rn)
Supposons que seule R1 change en R1U t (insertion de t).
La nouvelle valeur P' de P est Q(R1 U t, R2,…Rn).
Selon les opérateurs de Q on peut écrire :
Q(R1 U t, R2,…Rn) = Q(R1, R2…Rn)U Q(t)
Ce qui revient à n'évaluer Q que sur le delta
J.Siroux
17
Site de naissance (ne change pas),Site de stockage (peut changer)
n Site de l'usager : Michel de S1 crée une relation R et la stocke sur
S2 (langage PL/SQL sous Oracle)
CREATE TABLE WAGON(NW, TYPE, POIDS, GARE, ETAT) ON S2
S1 = site de naissance (WAGON@S1)
S2 = site de stockage
Michel de S1 déplace la relation de S2 vers S3
MIGRATE TABLE WAGON@ S1 TO S3
Rôle des catalogues: ici WAGON est connu de S1, S2 et S3
Vues pour données partitionnées
n Duplication
DUPLICATE TABLE WAGON@ S1 ON S4, S5
n Photo
CREATE SNAPSHOT MESWAGON AS SELECT * FROM WAGON
WHERE GARE="Grenoble« REFRESH EVERY WEEK
n
J.Siroux
18
Optimisation des lectures sur une BDR
n
Indépendance des données : même requête si l’organisation
physique est différente.
Pas d'ordre dans les opérations de PRODUIT
n
n
n
OPTIMISER?
Optimizer = composant essentiel des SBD centralisés ou
répartis
– Modèle basé sur les coûts d'accès (Cost based )
– Modèle basé sur des règles d'optimisation ( Rule Based )
(ex. Oracle V8/9, choix des modes)
Grands principes :
– Appliquer les OPTIMISATIONS ALGEBRIQUES et
– Tenir compte des CHEMINS D'ACCES qui existent sur chaque
relation de la requête.
J.Siroux
19
Optimisation : fonction de coût
n - TRANSFERTS DISQUE ===> MEMOIRE
n - TRAITEMENTS EN U.C. + en répartie COMMUNICATION entres
sites
CTA = ? * NBPAGES + ??? NBNUPLETS (+ ????NBMESSAGES)
n POIDS des COUTS:
n ? = poids des E/S PAGES (exemple 1)
n ? = poids du traitement en UC (exemple 1/3)
n ? = poids des messages
PROBLEME: EVALUER NBPAGES, NBNUPLETS, NBMESSAGES
avant d'accéder aux données de la bd
n SOLUTION: faire des estimations basées sur des informations (+ ou fraîches) conservées dans les catalogues du SGBD
n Rôle de l'administrateur
n SQL compilé ou interprété ?
J.Siroux
20
2. Bases de données Réparties
Interrogation d’une Base de Données Réparties
n Plusieurs phases à partir de la soumission de la requête au site
global (SG) :
è
(1) Remplacer les relations globales par leurs expressions. Cela
revient à remplacer chaque relation globale par son expression ne
faisant intervenir que des fragments locaux.
è
è
è
è
è
è
è
(2) Localisation des opérandes
(3) Décomposition de la requête globale en sous -requêtes locales
et envoi aux sites concernés
(4) Exécution répartie: parallélisme, synchronisation, transfert
RG =< RL1; RL2; (RL3 || RL4); RL5>
Le parallélisme intra-requête (globale, RL3, RL4) ou inter-requêtes
(le SGBDR exécute plusieurs requêtes pour x usagers)
(6) Mise en forme des résultats
(7) Retour des résultats au site global.
J.Siroux
21
2. Bases de données Réparties
n
n
n
n
n
n
n
n
Etude de cas
• M(MAG, VILM, DIR)
• P(NP,PA,PV,DESC)
• L(NP,NF,MAG,QL)
• F(NF,VILF)
M = ensemble de magasins,
P = produits prix d'achat (PA), et prix de vente (PV)
L = livraisons effectuées
F = fournisseurs
On suppose, pour simplifier que S et L caractérisent le mois en cours et
qu'ainsi la quantité en stock est remise à zéro au début de chaque mois.
Répartition : sites | relations
-------|-------------
S1 | M, P
S2 | L, F
J.Siroux
22
n
n
n
n
Exemple de RG
SELECT NF,MAG FROM P, F, L
WHERE F.VILF= "grenoble"
AND F.NF=L.NF AND P.PA > 50
AND P.NP=L.NP
a) cardinalités des relations:
F : 10 000 ; P: 100 000 L: 1 000 000
b) il y a 10 fournisseurs à Grenoble et 1000 produits
ayant PA > 50
c) les n-uplets ont tous la même taille de 100 octets
d) caractéristiques du réseau:
- 1 seconde pour le temps d'accès
è - 100 000 octets/seconde pour le débit du transfert,
coût total de communication CC entre deux sites
è
n
CC = nombre de messages * temps d'accès + nombre de bits transmis/débit
J.Siroux
23
n
Solution 1 :
-Transfert ( P, S2)
- Executer RG surS2
CC1 = 1 + (105*100) /10 5 = 101 secondes (1,5min)
n
Solution 2 :
-Transfert ( F, S1)
-Transfert ( L, S1)
- Executer RG sur S1
- CC2 = 2 +( (10 4 + 106)*100)) /10 5 = 1012 secondes (17 min)
J.Siroux
24
n
n
Solution 3 :
S1: TS1 := SELECT * FROM P WHERE PA > 50 ;
- Transfert (TS1, S2)
- SurS2: SELECT NF,MAG FROM F, L, TS1
WHERE F.VILF="Grenoble" AND F.NF=L.NF AND
L.NP =TS1.NP
- CC3 = 1 + (103*100) /10 5 = 2 secondes
Solution 4 :
S2: TS2 := SELECT * FROM F, L WHERE F.VILF="Grenoble«
AND F.NF=L.NF ;
- Transfert (TS2, S1)
- SurS1: SELECT NF,MAG FROM P, TS2 WHERE P.PA > 50
AND P.NP =TS2.NP
- CC4 = 1 + (107*100) /10 5 = 10001 secondes (2,5h)
J.Siroux
25
BD Parallèles
n
Les Opérateurs relationnels se prêtent bien à la parallélisation :
opérateurs uniformes sur des flots uniformes de données
n
Fermés sur la composition : R := f(R1, R2, …Rn)
Chaque opérateur consomme 1 ou 2 flots d'entrée
Chaque flot est une collection uniforme de données
Données séquentielles en entrée et en sortie : "pure dataflow “
Déjà des SGBD et des architectures adéquat (plus abouti :
Oracle // Server, coût 60 K€) mais encore du travail
n
n
n
n
n
Parallélismes inter ou intra requêtes ?
J.Siroux
26
Exemple : Requête parallèle
SELECT IMAGE
FROM LANDSAT
WHERE DATE BETWEEN 1970 AND 1990 {temporal}
AND OVERLAPS(LOCATION, :Rockies) {spatial}
AND SNOW_COVER(IMAGE) > .7 {image}
n Affecter un processus à chaque processeur/disque et rechercher les
images sur leurs attributs et sur leur contenu en séquence ou en
parallèle
n
Problèmes de performance: Jeux de Test (Benchmarks)
- TPC-A, TPC-B, TPC-C, TPC-D, …( Transaction Processing
Performance Council). Se reporter à http://www.tpc.org
J.Siroux
27
Balayage des données en // ?
n Disques : 3MO/s à 10MO/s
n Tuple (record) de 100 à 200 Octets (donc théoriquement traitement de
10kr/s à 100kr/s)
n Requête de type : Select count(*) from T where x < valeur
n T a 1M de tuples stockés sur un disque classique
n pas d'anticipation par le système d'exploitation ou le SGBD (readahead)
n blocs d'E/S petits (2kO)
n les données ne sont pas regroupées sur le disque
n Le parallélisme n'est pas toujours la solution à ce type de problème
n Balayage parallèle:
n 4 disques, 4 controleurs , 4 processeurs, 4 fois plus de tuples mais
partitionnés, processeurs, même requête:même temps?
J.Siroux
28
n
n
SGBD //
• "Shared nothing"
- Teradata (400 noeuds)
- Tandem (110noeuds )
- IBM/SP2/DB2 (128 noeuds)
- Informix/SP2 (48 noeuds)
- ATT & Sybase (8*14 noeuds)
• Disques partag és
- Oracle (170noeuds )
- RdB(24 noeuds)
• Mémoire partag ée
- Informix (9 noeuds)
- Redbrick (?noeuds)
DBC/1012 TERADATA
n Machine BD pour traiter de gros
volumes (>1984)
n MIMD mémoires privées
n Intel 80386, 80486
n Plus grosse installation : 476 noeuds ,
2,4 TB
n Architecture extensible
n Regroupement de processeurs (shared
nothing)
-IFP Interface Processor, COP
Communication Processor, AMP Access
Module Processor, Bus (doublé) Ynet
(arbre binaire)
-Données partitionnées par Hash -code,
fragment, Bonnes performances (balayage
de 1TB en 12’)
J.Siroux
29
Mise à jour BDR (1)
n PB : insertion, suppression des données réparties dépendent des cas
n de répartition ( modification = suppression ; insertion)
n Relation locale: la mise à jour est faite localement (voir transactions)
n Duplication la mise à jour doit être faite partout où il y a une copie.
n Ceci n'est viable que si la relation n'a pas un fort taux de mis e à jour.
n Plusieurs stratégies :
- Copie Primaire / copies secondaires : la mise à jour est faite sur la copie
primaire et transmise aux secondaires. Certaines lectures peuvent être
impropres et cela pose le problème de la panne du site primaire
- Double primaire : La mise à jour ne sera validée que si elle a été faite sur les
deux copies primaires.
- Vote majoritaire: La mise à jour est acceptée ssi il n'y a pas de conflit de
mise à jour et si la mise à jour est acceptée par une majorité de sites.
J.Siroux
30
Mise à jour BDR (2)
n
n
n
Partition Horizontale: RG := UNION(RL1, RL2…RLn)
Insérer(RG, t) ==> un seul insérer(RLj , t) sur site j
Problèmes:
(1) déterminer le fragment concerné :
- se servir du critère de partionnement
- lancer en // l'insertion partout et défaire si plus d'un site a
inséré.
(2) vérifier l'unicité des clés. Il faut interroger tous les si tes ayant un
fragment pour vérifier si la clé proposée n'existe pas déja.
J.Siroux
31
Mise à jour BDR - Transactions distribuées
n
n
Chaque transaction globale TG peut correspondre à une ou plusieurs
transactions locales TLi
ACID en BDR?
Atomicité : la TG doit être entièrement exécutée ou non (càd
TOUTES les Tli)
è Cohérence : la TG doit respecter les contraintes GLOBALES sur
la BDR
è Isolation : tout doit se passer comme si la TG était seule à utiliser
la BDR
è • Durabilité : Si TG valide, alors TOUT ce qu’elle a fait sur TOUS
è les sites doit survivre quoi qu’il arrive.
J.Siroux
32
3. Couches de connectivité - ODBC
n
n
n
Le gestionnaire ODBC est présent sur les systèmes Windows 9x, 2000.
Sous Windows 95 et 98 le gestionnaire ODBC est disponible dans le panneau
de configuration sous l'icône suivant:
Inconvénients de la technologie ODBC
Bien que ODBC permette un interfaçage avec des bases de données
indépendamment du SGBD, cette technologie reste une solution propriétaire de
Microsoft. Cela se traduit par une dépendance de la plateforme (fonctionne
uniquement sous Windows).
D'autre part, ODBC est fortement lié au langage C (utilisation de pointeurs), et
ODBC utilise des paramètres non standards, ce qui le rend parfois incompatible
avec certaines fonctions évoluées d’une base de données.
J.Siroux
33
n
Drivers par défaut
J.Siroux
34
Déclaration d’un DSN
ODBC permet de relier un client à une base de données en déclarant
une source de données (correspondant généralement à une base de
données) dans le gestionnaire ODBC (communément appelé
administrateur de source de données ODBC).
Rappel : La source de données peut être aussi bien une base de
données qu'un fichier Access, Excel ou bien même un fichier.
On appelle donc DSN (Data Source Name) la déclaration de la source
de données qui sera accessible par l'intermédiaire de ODBC.
Déclaration de la source de données
L'administrateur de source de données ODBC (parfois appelé ODBC32
bits), disponible dans le panneau de configuration, permet de déclarer
le type de données auxquelles il est possible d'accèder et de leur
associer un nom. L'onglet DSN système permet de voir la liste de DSN
déjà installés sur le système :
J.Siroux
35
J.Siroux
36
Pour déclarer une source de données il faut :
n
Créer les données (créer une ou plusieurs tables dans une base de
données ou bien créer un fichier Excel ou Access)
n
Installer le driver ODBC pour la base de données si celle-ci n'est pas
installée par défaut sous l'administrateur de source de données
n
Etablir la liaison ODBC dans l'onglet DSN système de l'administrateur
de source de données, en cliquant sur Ajouter... puis en sélectionnant
le type de driver à utiliser.
J.Siroux
37
J.Siroux
38
n
L'administrateur de source de données va ensuite demander le nom à
affecter à la source de données (Il s'agit du nom par lequel la base de
données sera accessible), puis de sélectionner la source de données.
J.Siroux
39
n
Il faut ensuite donner le chemin d'accès à la base de données
physique (Path File) en cliquant sur le bouton sélectionner de la
fenêtre précédente
n
La base de données devrait alors être accessible via ODBC
n
Suivant les bases de données, la procédure peut varier et des
options supplémentaires peuvent-être demandées, mais la
configuration d'un DSN système reste globalement la même.
J.Siroux
40
3. Couches de connectivité - JDBC
n
La technologie JDBC (Java DataBase Connectivity) est une API
fournie avec Java (depuis sa version 1.1) permettant de se
connecter à des bases de données, c'est-à-dire que JDBC
constitue un ensemble de classes permettant de développer
des applications capables de se connecter à des serveurs de
bases de données (SGBD).
n
L'API JDBC a été développée de telle façon à permettre un
programme de se connecter à n'importe quelle base de
données en utilisant la même syntaxe, c'est-à-dire que l'API
JDBC est indépendante du SGBD.
n
De plus, JDBC bénéficie des avantages de Java, dont la
portabilité du code, de qui lui vaut en plus d'être
indépendant de la base de données d'être indépendant
de la plate-forme sur laquelle elle s'exécute.
J.Siroux
41
3. Couches de connectivité – JDBC
n
Dans un système client/serveur, l'accès aux bases de données avec
JDBC peut s'effectuer selon un modèle à deux couches ou bien un
modèle à trois couches.
n
Pour le modèle à deux couches, une application Java est intimement
liée avec une base de données. A cet effet, il faut bien évidemment
disposer, pour la base de données concernée, d'un pilote JDBC
adéquat. Les instructions SQL sont directement envoyées à la base,
cette dernière renvoyant les résultats par un biais tout aussi direct. La
base de données peut être exécutée sur la machine locale (celle sur
laquelle l'application Java fonctionne) ou bien sur tout autre ordinateur
du réseau (Intranet ou Internet).
J.Siroux
42
n
Dans le modèle à 3 couches, une troisième couche (le serveur
d'application) vient s'intercaler entre l'application Java et la base de
données. Les instructions SQL et les résultats livrés en retour y
transitent. Ce modèle présente l'avantage d'intégrer dans cette couche
un contrôle d'accès.
J.Siroux
43
Les types de pilotes JDBC
n Les pilotes JDBC actuels sont classés en quatre catégories :
n Pilotes de type 1: Pilotes accédant à une base de données par l'intermédiaire
d'une autre technologie (on parle de passerelle). Les passerelles JDBC-ODBC,
permettant une connexion via un pilote ODBC en sont l'exemple le plus courant.
Le pilote convertit les appels de données Java en appel ODBC valide, et les
exécute ensuite à l'aide du pilote ODBC
n Pilotes de type 2: Pilotes d'API natifs. Il s'ait d'un mélange de pilotes natifs et
de pilotes Java. Les appels JDBC sont convertis en appels natifs pour le serveur
de bases de données (Oracle, Sybase, ou autres) généralement en C ou en
C++.
n Pilotes de type 3: Pilotes convertissant les appels JDBC en un protocole
indépendant du SGBD. Un serveur convertit ensuite ceux-ci dans le protocole
SGBD requis (modèle à 3 couches)
n Pilotes de type 4: Pilotes convertissant les appels JDBC directement en un
protocole réseau exploité par le SGBD. Ces pilotes encapsulent directement
l'interface cliente du SGBD et sont fournis par les éditeurs de base de données.
Cette solution est à préconiser dans le cadre d'un intranet.
J.Siroux
44
Connection à la base de données
n L'API (Application Programming Interface) JDBC, c'est-à-dire la
bibliothèque de classes JDBC, se charge de trois étapes indispenables
à la connexion à une base de données:
- la création d'une connexion à la base
- l'envoi d'instructions SQL
- l'exploitation des résultats provenant de la base
Le package java.sql.
n
Tous les objets et les méthodes relatifs aux bases de données sont
présentes dans le package java.sql, il est donc indispensable
d'importer java.sql dans tout programme se servant de la technologie
JDBC.
J.Siroux
45
Connection à la base de données
n Pour se connecter à une base de données il est essentiel de charger dans un
premier temps le pilote de la base de données à laquelle on désire se connecter
grâce à un appel au DriverManager (gestionnaire de pilotes) :
Class.forname("nom.de.la.classe");
Cette instruction charge le pilote et crée une instance de cette classe. Exemple :
Pour se connecter à une base de données déclarée dans l'administrateur ODBC, il
faut charger le pilote JDBC-ODBC (appelé pont JDBC-ODBC) :
Class.forname("sun.jdbc.odbc.JdbcOdbcDriver");
n Certains compilateurs refusant cette notation, il faut parfois appeler le driver de la
façon suivante :
Class.forname("sun.jdbc.odbc.JdbcOdbcDriver").newInstance();
n Pour se connecter à une base de données particulière, il s'agit ensuite de créer une
instance de la classe Connection grâce à la méthode getConnection de l'objet
DriverManager en indiquant la base de données à charger à l'aide de son URL
String url = "jdbc:odbc:base_de_donnees"; Connection con =
DriverManager.getConnection(url);
n Le nom de la base de données (ici base_de_donnees) étant celle
du DSN déclaré dans le panneau de configuration ODBC, c'est-àdire le nom du DSN.
J.Siroux
46
Exécution d'une requête SQL
n Pour exécuter une requête SQL, il s'agit dans un premier temps de
créer un objet Statement, pouvant être obtenu à partir de l'objet
Connection. Un objet ResultSet permettra de récupérer les données
en provenance de l'objet Statement.
String query = "SELECT * FROM Ma_Table;"; ResultSet results;
try {
Statement stmt = con.createStatement();
results = stmt.executeQuery(query);
}
catch(Exception(e){
System.out.println("exception du a la requete");
}
J.Siroux
47
Accès aux données
n Une fois la connection à la base de données établie, il est possible de
demander des informations sur le nom des tables et le contenu de chaque
colonne, ainsi que d'exécuter des requêtes SQL afin de récupérer des
informations, d'en ajouter ou bien de les modifier.
n Les objets utilisables pour obtenir des informations sur la base sont:
DataBaseMetaData: Un objet contenant les informations sur la base de
données en général (des métadonnées), c'est-à-dire le nom de la table, les
index, la version de la base, ...
n ResultSet: Un objet contenant les informations sur une table ou le résultat d'une
requête. L'accès aux données se fait colonne par colonne, mais il est
éventuellement possible d'accèder indépendamment à chaque colonne par son
nom
n ResultSetMetaData: Un objet contenant des informations sur le nom et le type
des colonnes d'une table
J.Siroux
48
n
L'objet ResultSet est l'objet le plus important de la technologie
JDBC, car il s'agit d'une abstraction de la table ou de la réponse à une
requête (généralement un sous-ensemble d'une table). Ainsi, presque
toutes les méthodes et requêtes retournent les données sous forme
d'un objet ResultSet. Cet objet contient un nombre donné de colonnes
repérées chacune par un nom, ainsi qu'une ou plusieurs lignes
contenant les données, et auxquelles il est possible d'accèder
séquentiellement une à une du haut vers le bas. Ainsi, afin d'exploiter
un objet ResultSet, il est nécessaire de récupérer le nombre de
colonnes de celui-ci, à l'aide de l'objet ResultSetMetaData.
ResultSetMetaData rsmd;
rsmd = results.getMetaData();
numcols = rsmd.getColumnCount();
Lors de l'obtention d'un objet ResultSet, le descripteur pointe avant la
première ligne
J.Siroux
49
Les principales méthodes de l'objet ResultSet sont les suivantes:
n getInt(int): récupère sous forme d'entier le contenu d'une colonne désignée par
son numéro
n getInt(String): récupère sous forme d'entier le contenu d'une colonne désignée
par son nom
n getFloat(int): récupère sous forme de flottant le contenu d'une colonne désignée
par son numéro
n next(): déplace le pointeur de colonne sur la colonne suivante
n close(): ferme l'objet ResulSet
n getMetaData(): retourne les métadonnées de l'objet (l'objet ResultSetMetaData)
L'objet ResultSetMetaData (obtenu de l'objet ResultSet) permet de connaître le
nombre, le nom et le type de chaque colonne à l'aide des méthodes suivantes:
n getColumnCount(): récupère le nombre de colonnes
n getColumnName(int): récupère le nom de la colonne spécifiée
n getColumnLabel(int): récupère le label de la colonne spécifiée
n getColumnType(int): récupère le type de données de la colonne spécifiée
J.Siroux
50
Création d'objets JDBC de plus haut niveau
n Puisque l'accès à une base de données nécessite l'utilisation conjointe
de plusieurs objets, il peut être intéressant de créer quelques objets de
plus haut niveau encapsulant la plupart des comportements cités cidessus.
n
Ainsi la création d'un objet DataBase pour permettre d'encapsuler
l'ensemble des objets nécessaires à la connection à une base de
données (Connection, Statement, DataBaseMetaData), ainsi que de
(re)définir des méthodes simples permettant de rendre plus simples
certaines opérations, comme la création de la connection, la
récupération du nom des tables, ainsi qu'une méthode Execute rendant
l'exécution de requête triviale.
J.Siroux
51
class Database
{
Connection con;
resultSet results;
ResultSetMetaData rsmd;
DatabaseMetaData dm;
String catalog;
String types[];
//---------------------------public Database(String Driver)
{
types = new String[1];
types[0] = "TABLES";
try {
Class.forName(driver);
}
catch(Exception e){
System.out.println("Erreur lors du chargement du driver:"+
e.getMessage());
}
}
J.Siroux
52

Bases de Données Réparties - LP GSR 2007/2008

Transcription

Documents pareils

Architecture client serveur l`état de l`art

Java et les bases de données: JDBC et SQLJ

Fiche examen 2

Java et les bases de données

Sujet de Thèse (2016-19) Identification du comportement

Impacts environnementaux des couches pour bébé

Le système de bases de données du futur

l`IP - Quonex

2.Objectifs et Architecture

SICO EXPERT 871-6XX

Exercice MapInfo

Thèse de Anne-Sophie OURTH