Java et les bases de données

2 452 vues

Publié le

Publié dans : Technologie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 452
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
69
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • faire correspondre de manière bijective une table (appelée aussi relation) à une liste d’objets une ligne d’une table (appelée aussi tuple) à un objet un champs de base de données à un attribut d’objet une valeur d’un champs à une valeur d’attribut d’un objet Des modifications du modèle de données ont des répercussions sur les requêtes aux bases, ce qui implique de faire évoluer individuellement les appels jdbc. La maintenance est de ce fait couteuse.
  • 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
  • On voit que la maintenance est difficile pour la gestion du mapping
  • Il est possible migrer facilement en utilisant le fichier hibernate.cfg.xml On peut utiliser plusieurs contextes en parallèle pour utiliser plusieurs référentiels de données
  • La représentation en clé-valeur est la plus simple et est très adaptée aux caches ou aux accès rapides aux informations. Elle considère la valeur stockée comme un bloc de données opaque, la base de données étant agnostique de son contenu. Ce postulat permet en général d’atteindre des performances bien supérieures dans la mesure où les lectures et écritures sont réduites à un accès disque simple.
  • La représentation en clé-valeur est la plus simple et est très adaptée aux caches ou aux accès rapides aux informations. Elle considère la valeur stockée comme un bloc de données opaque, la base de données étant agnostique de son contenu. Ce postulat permet en général d’atteindre des performances bien supérieures dans la mesure où les lectures et écritures sont réduites à un accès disque simple.
  • La représentation en document est particulièrement adaptée au monde du Web. Il s’agit d’une extension du concept de clé-valeur qui représente la valeur sous la forme d’un document. Un document contient des données organisées de manière hiérarchique à l’image de ce que permettent XML ou JSON. Étant consciente du contenu qu’elle stocke, la base de données peut alors effectuer des indexations de différents champs et offrir des requêtes plus élaborées.
  • La représentation orientée colonnes s’oppose à la représentation des tables dans les bases de données relationnelles. En effet, les SGBDR manipulent les colonnes d’une ligne d’une manière statique. Les bases de données orientées colonnes ont une vision bien plus flexible permettant d’avoir des colonnes différentes pour chaque ligne et de multiplier de manière conséquente le nombre de colonnes par ligne. Il en résulte une capacité à stocker des listes d’informations pour chaque clé, et à accéder à des intervalles de colonnes.
  • Propriétés ACID ? Atomicité Cohérence Isolation Durabilité
  • Java et les bases de données

    1. 1. Java et les bases de donnéesEtat de l’art14 juin 2012
    2. 2.  ARESU (Architectures, réseaux, Expertise & Support aux unités)  Appui et accompagnement des projetsP. 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. 3. P. 3 1. Introduction 2. Bases de données relationnelles 3. La mouvance NoSQL 4. Conclusion SOMMAIRE Guillaume HARRY l ARESU
    4. 4. P. 4 Java et la sérialisation 1. INTRODUCTION Guillaume HARRY l ARESU
    5. 5. 1. Introduction : Java et la sérialisationP. 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. 6. 1. Introduction : Java et la sérialisationP. 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. 7. 1. Introduction : Java et la sérialisationP. 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. 8. 1. Introduction : Java et la sérialisationP. 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. 9. P. 9 1. Besoins 2. ORM 3. JPA 4. Les limites 2. BASES DE DONNÉES RELATIONNELLES Guillaume HARRY l ARESU
    10. 10. 2.1 Bases de données relationnelles : BesoinsP. 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. 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. 12. 2.2 Bases de données relationnelles : ORMP. 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. 13. 2.2 Bases de données relationnelles : ORMP. 13  Exemple avec Hibernate  Configuration 1 fichier de configuration Hibernate (hibernate.cfg.xml) Déclaration de l’entité Guillaume HARRY l ARESU
    14. 14. 2.2 Bases de données relationnelles : ORMP. 14  Exemple avec hibernate  Mapping 1 fichier de description XML (classe.hbm.xml) par classe Guillaume HARRY l ARESU
    15. 15. 2.2 Bases de données relationnelles : ORMP. 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. 16. 2.2 Bases de données relationnelles : ORMP. 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. 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. 18. 2.3 Bases de données relationnelles : JPAP. 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. 19. 2.3 Bases de données relationnelles : JPAP. 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. 20. 2.3 Bases de données relationnelles : JPAP. 20  Exemple  Mapping Déclaration de l’entité Déclaration de l’identifant Guillaume HARRY l ARESU
    21. 21. 2.2 Bases de données relationnelles : JPAP. 21  Exemple  Outil Plugin Eclipse inclus dans Eclipse WTP  Gestion des accès au SGBDR Avec Hibernate Guillaume HARRY l ARESU
    22. 22. 2.2 Bases de données relationnelles : JPAP. 22  Exemple avec Hibernate  Gestion des accès au SGBDR • Avec Hibernate • Génération automatique des ordres SQL Guillaume HARRY l ARESU
    23. 23. P. 23 1. Besoins 2. ORM 3. JPA 4. Limites 2. SÉRIALISER DANS UN SGBDR Guillaume HARRY l ARESU
    24. 24. 2.4 Bases de données relationnelles : LimitesP. 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. 25. P. 25 1. Technologies 2. Limites 3. Et JPA alors? 3. LA MOUVANCE NOSQL Guillaume HARRY l ARESU
    26. 26. 3.1 NoSQL : TechnologiesP. 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. 27. 3.1 La mouvance NoSQL : TechnologiesP. 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. 28. 3.1 La mouvance NoSQL : TechnologiesP. 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. 29. 3.1 La mouvance NoSQL : TechnologiesP. 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. 30. 3.1 La mouvance NoSQL : TechnologiesP. 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. 31. 3.1 La mouvance NoSQL : TechnologiesP. 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. 32. P. 32 1. Technologies 2. Limites 3. Et JPA alors? 3. LA MOUVANCE NOSQL Guillaume HARRY l ARESU
    33. 33. 3.2 La mouvance NoSQL : LimitesP. 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. 34. P. 34 1. Technologies 2. Limites 3. Et JPA alors ? 3. LA MOUVANCE NOSQL Guillaume HARRY l ARESU
    35. 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. 36. P. 36 4. CONCLUSION Guillaume HARRY l ARESU
    37. 37. ConclusionP. 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. 38. Java et les bases de donnéesEtat de l’art14 juin 2012

    ×