• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Java et les bases de données
 

Java et les bases de données

on

  • 1,572 views

 

Statistics

Views

Total Views
1,572
Views on SlideShare
1,572
Embed Views
0

Actions

Likes
1
Downloads
35
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Java et les bases de données Presentation Transcript

  • Java et les bases de donnéesEtat de l’art14 juin 2012
  •  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
  • P. 3 1. Introduction 2. Bases de données relationnelles 3. La mouvance NoSQL 4. Conclusion SOMMAIRE Guillaume HARRY l ARESU
  • P. 4 Java et la sérialisation 1. INTRODUCTION Guillaume HARRY l ARESU
  • 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
  • 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
  • 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
  • 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
  • P. 9 1. Besoins 2. ORM 3. JPA 4. Les limites 2. BASES DE DONNÉES RELATIONNELLES Guillaume HARRY l ARESU
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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 
  • 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
  • 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
  • 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
  • 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
  • P. 23 1. Besoins 2. ORM 3. JPA 4. Limites 2. SÉRIALISER DANS UN SGBDR Guillaume HARRY l ARESU
  • 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
  • P. 25 1. Technologies 2. Limites 3. Et JPA alors? 3. LA MOUVANCE NOSQL Guillaume HARRY l ARESU
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • P. 32 1. Technologies 2. Limites 3. Et JPA alors? 3. LA MOUVANCE NOSQL Guillaume HARRY l ARESU
  • 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
  • P. 34 1. Technologies 2. Limites 3. Et JPA alors ? 3. LA MOUVANCE NOSQL Guillaume HARRY l ARESU
  • 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
  • P. 36 4. CONCLUSION Guillaume HARRY l ARESU
  • 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
  • Java et les bases de donnéesEtat de l’art14 juin 2012