1. Java et les bases de données
Etat de l’art
14 juin 2012

2.  ARESU (Architectures, réseaux, Expertise & Support aux unités)
 Appui et accompagnement des projets
P. 2
 Veille technologique
 Capitalisation des compétences techniques
 Participation aux communautés informatique
 Guillaume HARRY
 11 ans d’expérience en tant que DBA
 7 ans d’expérience en J2E
Expertise accès aux données
 Responsable des cellules « Bases de données » et
« Gestion des identités »
 Participation à la cellule « Développement »
 Étude sur les failles de sécurité des applications Web
https://aresu.dsi.cnrs.fr/IMG/pdf/failles_de_securite_v1-3.pdf
Guillaume HARRY l ARESU

3. P. 3
1. Introduction
2. Bases de données relationnelles
3. La mouvance NoSQL
4. Conclusion
SOMMAIRE
Guillaume HARRY l ARESU

4. P. 4
Java et la sérialisation
1. INTRODUCTION
Guillaume HARRY l ARESU

5. 1. Introduction : Java et la sérialisation
P. 5  Modèle en couche
 L’interface graphique ne doit pas manipuler directement
les données stockées
 La couche d’accès aux données doit être la seule
responsable de la sérialisation des objets métiers
 Qu’est-ce que la sérialisation ?
 Rendre les objets persistants
 Ecrire des données présentes en mémoire vers un flux
de données binaires
Guillaume HARRY l ARESU

6. 1. Introduction : Java et la sérialisation
P. 6  Développement spécifique
 XML
 Structure le contenu
 Pas de véritable outil de gestion des données
 SGBDOO
 Outil idéal mais ne s’est pas imposé
 NoSQL
 Outil idéal pour un besoin bien défini
 Pas de standards (langage, interface d’accès)
 Conclusion
 SGBD Relationnel reste un standard
Guillaume HARRY l ARESU

7. 1. Introduction : Java et la sérialisation
P. 7  Pour les bases de données relationnelles
 Standard d’accès : JDBC
 Langage SQL largement répandu
 Maintenance couteuse
 SQL propre à chaque SGBDR
 Besoin de redévelopper les frameworks de gestion des
accès
 Développement spécifique au SGBDR utilisé
Guillaume HARRY l ARESU

8. 1. Introduction : Java et la sérialisation
P. 8  JDO (JSR243)
 Interface standard pour la sérialisation
 Indépendance vis-à-vis de la solution de stockage
 Trop complexe à mettre en œuvre
 Peu d’implémentations
Guillaume HARRY l ARESU

9. P. 9
1. Besoins
2. ORM
3. JPA
4. Les limites
2. BASES DE DONNÉES
RELATIONNELLES
Guillaume HARRY l ARESU

10. 2.1 Bases de données relationnelles : Besoins
P. 10  Faciliter le développement de la couche DAO
 Ne pas gérer les accès à la base de données
 Automatiser la corrélation Objet ↔ Base de données
Guillaume HARRY l ARESU

11. P. 11
1. Besoins
2. ORM
1. Modèle
2. Exemple avec Hibernate
3. JPA
4. Limites
2. BASES DE DONNÉES
RELATIONNELLES
Guillaume HARRY l ARESU

12. 2.2 Bases de données relationnelles : ORM
P. 12  Objectifs
 Faciliter
 Ne pas gérer
 Automatiser
 Modèle
 Implémentations Java
 Hibernate (Jboss)
 TopLink (Oracle)
 MyBatis (mapping par requête et non par table)
Guillaume HARRY l ARESU

13. 2.2 Bases de données relationnelles : ORM
P. 13  Exemple avec Hibernate
 Configuration
1 fichier de configuration Hibernate (hibernate.cfg.xml)
Déclaration de l’entité
Guillaume HARRY l ARESU

14. 2.2 Bases de données relationnelles : ORM
P. 14  Exemple avec hibernate
 Mapping
1 fichier de description XML (classe.hbm.xml) par classe
Guillaume HARRY l ARESU

15. 2.2 Bases de données relationnelles : ORM
P. 15  Exemple avec Hibernate
 Outil
Hibernate Tools pour faciliter la génération JavaXML et SGBDRJava
 Gestion des accès au SGBDR
Guillaume HARRY l ARESU

16. 2.2 Bases de données relationnelles : ORM
P. 16  Exemple avec Hibernate
 Gestion des accès au SGBDR
• 1 classe HibernateUtil pour obtenir
une session dans la base de données
• Génération automatique des ordres SQL
Guillaume HARRY l ARESU

17. P. 17
1. Besoins
2. ORM
3. JPA
1. Modèle
2. Exemple
4. Limites
2. SÉRIALISER DANS UN SGBDR
Guillaume HARRY l ARESU

18. 2.3 Bases de données relationnelles : JPA
P. 18  Objectifs
 Bénéficier des avantages des frameworks ORM
 Indépendance du framework utilisé
 Langage standard JP-QL (inspiré de HQL)
 Modèle
 Implémentations Java
 Hibernate (Jboss)
 TopLink (Oracle)
 EclipseLink (Fondation Eclipse)
Guillaume HARRY l ARESU DataNucleus Access Platform


19. 2.3 Bases de données relationnelles : JPA
P. 19  Exemple
 Configuration
1 fichier de description
• Contexte de persistance
• Déclarations des classes
Déclaration de l’entité
 Permet de faciliter la gestion des contextes de test
Guillaume HARRY l ARESU

20. 2.3 Bases de données relationnelles : JPA
P. 20  Exemple
 Mapping
Déclaration de l’entité
Déclaration de l’identifant
Guillaume HARRY l ARESU

21. 2.2 Bases de données relationnelles : JPA
P. 21  Exemple
 Outil
Plugin Eclipse inclus dans Eclipse WTP
 Gestion des accès au SGBDR
Avec Hibernate
Guillaume HARRY l ARESU

22. 2.2 Bases de données relationnelles : JPA
P. 22  Exemple avec Hibernate
 Gestion des accès au SGBDR
• Avec Hibernate
• Génération automatique des ordres SQL
Guillaume HARRY l ARESU

23. P. 23
1. Besoins
2. ORM
3. JPA
4. Limites
2. SÉRIALISER DANS UN SGBDR
Guillaume HARRY l ARESU

24. 2.4 Bases de données relationnelles : Limites
P. 24  Complexité du modèle
 Implémentation des associations
 Implémentation de l’héritage
• 1seule table, somme de tous les attributs des classes filles (par défaut)
• 1 table par classe
 Persistance par transitivité
 Performances
 Comment faire avec des données non structurées ?
Guillaume HARRY l ARESU

25. P. 25
1. Technologies
2. Limites
3. Et JPA alors?
3. LA MOUVANCE NOSQL
Guillaume HARRY l ARESU

26. 3.1 NoSQL : Technologies
P. 26  Not Only SQL
 Répondre aux besoins
 Explosion du volume de données (Big Data)
 Données non structurées
 Gestion des relations entre les données
Guillaume HARRY l ARESU

27. 3.1 La mouvance NoSQL : Technologies
P. 27  Clé-valeur
 Données représentée par couple clé/valeur
 Accès rapides
 Type de données simples
…
 Exemple :
Clé 1
stockage de résultats d’expérience, statistiques valeur
Système de cache
Clé 2 valeur
 Implémentations
Voldemort (LinkedIn) Clé 3 valeur
Redis
Riak …
MySQL Cluster 7.2
Guillaume HARRY l ARESU

28. 3.1 La mouvance NoSQL : Technologies
P. 28  Orientée document
 Ensemble de clés-valeurs stockées dans un document
 Données semi-structurées Document
 Pas de support des transactions Champ 1 valeur
Champ 2 valeur
 Exemple :
Champ 3 valeur
Catalogue de produits
Champ 4 valeur
CMS …
 Implémentations Clé 1 Document
MongoDB Champ 1 valeur
CouchDB Clé 2 Champ 2 valeur
OrientDB
Clé 3
Document
Champ 1 valeur
…
Champ 2 valeur
Champ 3 valeur
Guillaume HARRY l ARESU

29. 3.1 La mouvance NoSQL : Technologies
P. 29  Orientée colonne
 Contrairement aux SGBDR,
colonnes différentes pour chaque ligne
 Ecritures rapides
 Evite des colonnes à NULL SuperColonne
SuperColonne
 Exemple Nom CNRS
Valeur
Stockage de journaux d’activité
Colonne
 Implémentation Nom Organisme
Hbase Valeur CNRS
Cassandra
BigTable (google) Colonne
Nom Secteur
Valeur public
Guillaume HARRY l ARESU

30. 3.1 La mouvance NoSQL : Technologies
P. 30  Orientée graphe
 Information représentée par des nœuds et des relations
entre nœuds Nœud
 Accès aux données par les liaisons Champ 1 valeur
 Exemple : Arc
Champ 2 valeur
Champ 3 valeur
Réseaux sociaux : apprend
Libellé
Champ 4 valeur
 Implémentation
Neo4j Nœud
HypergraphDBChamp 1 valeur
FlockDB Champ 2 valeur
OrientDB
Nœud
Arc Champ 1 valeur
Libellé : connait
Champ 2 valeur
Champ 3 valeur
Guillaume HARRY l ARESU

31. 3.1 La mouvance NoSQL : Technologies
P. 31  Choix de la technologie dépend du besoin, pas du volume à
gérer
 Ne sont pas NoSQL
 Orientées objet
 Hierarchique
 Datagrids (hors clé-valeur)
Guillaume HARRY l ARESU

32. P. 32
1. Technologies
2. Limites
3. Et JPA alors?
3. LA MOUVANCE NOSQL
Guillaume HARRY l ARESU

33. 3.2 La mouvance NoSQL : Limites
P. 33  NoSQL est encore récent
 Pas de solution idéale
 Théorème CAP
 Cohérence
 Availability
Chaque client a la
 Partition tolerance même vue de
chaque donnée à
tout instant
Systèmes CP Systèmes AC
Le système Chaque client
fonctionne malgré la peut toujours lire
partition physique Systèmes AP et écrire
des données
Guillaume HARRY l ARESU

34. P. 34
1. Technologies
2. Limites
3. Et JPA alors ?
3. LA MOUVANCE NOSQL
Guillaume HARRY l ARESU

35. 3.3 La mouvance NoSQL : Et JPA alors?
P. 35  OrientDB est nativement écrit en JPA
 Datanucleus : JPA et JDO pour accès
 SGBDR,
 MongoDB,
 Hbase,
 LDAP,
 Excel,
 XML …
Guillaume HARRY l ARESU

36. P. 36
4. CONCLUSION
Guillaume HARRY l ARESU

37. Conclusion
P. 37  JPA et ORM
 Orientés CRUD
 Tuning complexe dépendant du framework
 Moins performants que des accès bas niveau
 NoSQL
 Ne remplace pas SGBDR
 Administration/exploitation non triviale
Guillaume HARRY l ARESU

38. Java et les bases de données
Etat de l’art
14 juin 2012