EJB3.1 - ORM - Object-Relational Mapping

Dimension: px
Commencer à balayer dès la page:

Download "EJB3.1 - ORM - Object-Relational Mapping"

Transcription

1 EJB3.1 - ORM - Object-Relational Mapping Chapitres traités Association d'une entité Durant cette étude, nous passerons en revue les bases des ORM (Object-Relational Mapping), qui consistent essentiellement à faire correspondre des entités à des tables et des attributs à des colonnes. Nous nous intéresserons ensuite à des associations plus complexes comme les relations, la composition et l'héritage. Un modèle objet est composé d'objets interagissant ensemble ; or les objets et les bases de données utilisent des moyens différents pour stocker les informations sur ces relations (via des pointeurs ou des clés étrangères). Les bases de données relationnelles ne disposent pas naturellement du concept d'héritage et cette association entre objets et bases n'est par conséquent pas évidente. Nous irons donc dans les détails et présenterons des exemples qui montrerons comment les attributs, les relations et l'héritage peuvent être traduits d'un modèle objet vers une base de données. Association d'une entité Comme premier exemple, commençons par l'association la plus simple possible que nous avons élaboré lors de l'étude précédente. Dans le modèle de persistance de JPA, une entité est un objet Java classique (POJO) : Ceci signifie qu'une entité est déclarée, instanciée et utilisée comme n'importe qu'elle autre classe Java. Une entité possède des attributs (son état) qui peuvent être manipulés au moyen de getters et de setters (notion de propriétés). Dans la base de données relationnelle, chaque attribut est stockée dans une colonne d'une table Le code source suivant présente l'entité simple Photo. package entité; entité.photo.java import java.awt.image.bufferedimage; import java.util.date; import query="select photo FROM Photo AS photo") public class Photo { // implements java.io.serializable { private String private Date instant; private int largeur; private int hauteur; private long poids; public String getid() { return id; public int gethauteur() { return hauteur; public Date getinstant() { return instant; public int getlargeur() { return largeur; public long getpoids() { return poids; public Photo() { public Photo(String nom, long poids) { id = nom; instant = new Date(); this.poids = poids; public void setdimensions(bufferedimage image) { largeur = image.getwidth(); hauteur = image.getheight();

2 @Override public String tostring() { return id+" ("+largeur+", "+hauteur+")"; Comme vous pouvez le constater, à part les annotations, cette entité ressemble exactement à n'importe quelle classe Java : elle possède plusieurs attributs (id, instant, largeur, hauteur et poids) de différents types (String, Date, int et long), plusieurs constructeurs dont celui par défaut, des getters pour chaque attribut avec un seul setter. Dans cette exemple là, l'état de l'objet est rapidement renseigné à l'aide du deuxième constructeur et de la méthode setdimensions(). Les annotations permettent d'associer très simplement cette entité à une table dans une base de données. 1. Tout d'abord, la classe est ce qui permet au fournisseur de persistance de la reconnaître comme une classe persistante et non comme une simple classe POJO. 2. Puis définit l'identifiant unique de l'objet. JPA étant destiné à associer des objets à des tables relationnelles, les objets doivent posséder un identifiant qui sera associé à une clé primaire. 3. La plupart des autres attributs (largeur, hauteur et poids) ne sont pas annotés et seront donc stockés dans la table en appliquant une association standard. Notez que cette entité Photo est une classe qui actuellement n'implémente aucune interface et qui n'hérite d'aucune classe. En fait, pour être une entité, une classe doit impérativement respecter les règles suivantes : 1. La classe de l'entité doit être annotée 2. doit être utilisée pour désigner une clé primaire simple. 3. La classe de l'entité doit posséder au moins un constructeur par défaut, public ou protégé. Bien entendu, elle peut également avoir d'autres constructeurs. 4. La classe de l'entité doit être une classe de premier niveau. Une énumération ou une interface ne peut pas être considérée comme une entité. 5. La classe de l'entité ne peut pas être finale et aucune méthode ou variable d'instance persistante ne peut être finale non plus. 6. Si une instance d'entité doit être passée par valeur sous forme d'objet détaché (via une interface distante, par exemple), la classe de l'entité doit alors implémenter l'interface Serializable (c'est très souvent le cas). L'entité Photo respectant ces règles simples, le fournisseur de persistance peut synchroniser les données entre les attributs de l'entité et les colonnes de la table PHOTO. Par conséquent, si l'attribut largeur est modifié par l'application, la colonne LARGEUR le sera également (si l'entité est gérée, si le contexte de transaction est actif, etc.). L'entité Photo est stockée dans une table PHOTO dont chaque colonne porte le nom de l'attribut correspondant de la classe (l'attribut largeur de type int est associée à une colonne LARGEUR de type INTEGER). Ces règles d'associations par défaut sont un aspect important du principe appelé "convention plutôt que configuration" (ou "configuration par exception"). Configuration par exception Java EE 5 a introduit l'idée de configuration par exception. Ceci signifie que, sauf mention contraire, le conteneur ou le fournisseur doivent appliquer les règles par défaut. En d'autres termes, fournir une configuration est une exception à la règle. Cette politique permet donc de configurer une application avec un minimum d'effort. Revenons à l'exemple précédent. Sans annotation, l'entité Photo serait traitée comme n'importe quel POJO et ne serait pas persistante - c'est la règle : sans configuration spéciale, le comportement par défaut s'applique et il consiste évidemment à considérer que la classe Photo est une classe comme les autres. 1. Comme nous souhaitons modifier ce comportement, nous annotons la classe avec. 2. Il en va de même pour l'identifiant : nous avons absolument besoin d'indiquer au fournisseur de persistance que cet attribut doit être

3 associé à une clé primaire, et c'est la raison pour laquelle nous l'annotons avec. Ce type de décision caractérise bien la politique de configuration par exception : les annotations ne sont pas nécessaires dans le cas général ; elles ne sont utilisées que pour outrepasser une convention. Ceci signifie donc que tous les autres attributs de notre classe (sauf instant) seront associés selon les règles par défaut : 1. Le nom de l'entité est associé à un nom de table relationnelle (l'entité Photo sera donc associée à une table PHOTO). Si vous désirez l'associer à une autre table, vous devrez utiliser comme nous le découvrirons dans un des chapitres qui suit). 2. Le nom des attributs sont associés à des noms de colonnes (l'attribut id, ou la méthode getid(), est associé à une colonne ID). Si vous changez ce comportement, vous devrez utiliser 3. Ce sont les règles JDBC qui s'appliquent pour associer les types primitifs de Java aux types de données de la base. Ainsi : Un String sera associé à un VARCHAR, Un Long à un BIGINT, Un Boolean à un SMALLINT, etc. La taille par défaut d'une colonne associée à un String est de 255 caractères - VARCHAR(255). Ces règles par défaut peuvent éventuellement varier en fonction du SGBDR : un String est associé avec un VARCHAR avec Derby, mais à un VARCHAR2 avec Oracle ; de la même façon, un Integer est associé à un INTEGER avec Derby, mais à un NUMBER avec Oracle. La plupart des fournisseurs de persistance, dont EclipseLink, permettent de produire automatiquement la base de données directement à partir des entités. Cette fonctionnalité est tout spécialement pratique lorsque nous sommes en phase de développement car, avec uniquement les règles par défaut, nous pouvons associer très simplement les données en se contentant des annotations et. Indépendamment de notre application d'entreprise, il peut arriver que nous souhaitions nous connecter au SGBDR de façon classique, à l'aide notamment de requête SQL. Dans ce cas de figure, pour que les développeurs de base de données classiques puissent s'y retrouver, JPA définit un nombre important d'annotations qui vont permettrent de personnaliser chaque partie de l'association (les noms des tables et des colonnes, les clés primaires, la taille des colonnes, les colonnes NULL ou NOT NULL, etc. ). Associations élémentaires D'importantes différences existent entre la gestion des données par Java et par un SGBDR. En Java, nous utilisons des classes pour décrire à la fois les attributs qui contiennent les données et les méthodes qui accèdent et manipulent ces données. Lorsqu'une classe est définie, nous pouvons créer autant d'instances que nécessaire. Dans un SGBDR, en revanche, seules les données sont stockées, pas les comportements (exception faite des triggers et des procédures stockées). La procédure de stockage est également totalement différente de la structure des objets puisqu'elle utilise une décomposition en ligne et colonnes. L'association d'objets Java à une base de données sous-jacente peut donc être simple et se contenter des règles par défaut ; parfois, ces règles peuvent ne pas convenir aux besoin, auquel cas nous sommes obligés de les outrepasser. Les annotations des associations élémentaires permettent ainsi de remplacer les règles par défaut pour la table, les clés primaires et les colonnes, et de modifier certaines conventions de nommage ou de contenu de colonnes (valeurs non nulle, longueur, etc.). Tables associées La convention établit que les noms de l'entité et de la table sont identiques (une entité Photo est associée à une table PHOTO, une entité Livre, à une table LIVRE, etc.). Toutefois, si vous le souhaitez, vous pouvez associer vos attributs à une table différente, voire associer une même entité à plusieurs permet de modifier les règles par défaut pour les tables. Vous pouvez, par exemple, indiquer le nom de la table dans laquelle vous voulez stocker vos attributs, le catalogue et le schéma de la base. Cette annotation possède différents attributs : 1. name (requis) : définit le nom de la table à utiliser pour le mapping. 2. catalog (optionnel) : définit le catalog utilisé. 3. schema (optionnel) : définit le schéma utilisé.

4 4. uniqueconstraints (optionnel) : définit les contraintes qui seront placées sur la table. Cet attribut est utilisé lorsque le conteneur génère les tables au déploiement et n'affecte en rien l'exécution même de l'entité. Le code source suivant montre comment associer la table T_PHOTO à l'entité public class Photo implements java.io.serializable { private String private Date instant; private int largeur; private int hauteur; private long poids; entité.photo.java Dans le nom de la table est en minuscule (t_photo). Par défaut, la plupart des SGBDR lui feront correspondre un nom en majuscules (c'est notamment le cas de Derby), sauf si vous les configurez pour qu'ils respectent la Jusqu'à maintenant, nous avons toujours supposé qu'une entité n'était associée qu'à une seule table, également appelée table primaire. Si nous possédons déjà un modèle de données, en revanche, nous voudrons peut-être disséminer les attributs sur plusieurs tables, ou tables secondaires. Cette annotation permet de mettre en place cette permet d'associer une table secondaire à une entité, alors (avec un "s") en associe plusieurs. Vous pouvez ainsi distribuer les données d'une entité entre les colonnes de la table primaire et celles des tables secondaires en définissant simplement les tables secondaires avec des annotations, puis en précisant pour chaque attribut la table dans laquelle il devra être stocké (à l'aide de que nous décrirons ultérieurement). Le code source suivant montre comment répartir les attributs d'une entité Adresse entre une table primaire et deux tables @SecondaryTable(name="pays") ) public class Adresse implements java.io.serializable { private String rue1; private String private String private String private int private String pays; Adresse.java Par défaut, les attributs de l'entité Adresse seraient associés à la table primaire ADRESSE. précise qu'il existe deux tables secondaires supplémentaires : VILLE et PAYS. Vous devez ensuite respectivement indiquer dans quelle table secondaire stocker chaque attribut - à l'aide de Le résultat d'une telle écriture est ainsi la création de trois tables distinctes se partageant les différents attributs d'une même entité, en ayant toutefois la même clé primaire (afin, bien entendu, de pouvoir les joindre).

5 Comme vous l'avez sûrement compris, la même entité peut contenir plusieurs annotations. Ainsi, si vous désirez renommer la table primaire, vous pouvez donc ajouter une à celles déjà ) public class Adresse implements java.io.serializable { private String rue1; private String private String private String private int private String pays; Adresse.java Vous devez être concient de l'impact des tables secondaires sur les performances car, à chaque fois que vous accéder à une entité, le fournisseur de persistance devra accéder à plusieurs tables et les joindre. En revanche, les tables secondaires peuvent être intéressantes si vous avez des attributs de grande taille, comme les BLOB (Binary Large Objects), car vous pourrez les isoler dans une table à part. Clés primaires Dans les bases de données relationnelles, une clé primaire identifie chaque ligne d'une table. Cette clé peut être une simple colonne ou un ensemble de colonnes. Les clés primaires doivent évidemment être uniques (et la valeur NULL n'est pas autorisée). Des exemples de clés primaires classiques sont un numéro de compte client, un numéro de téléphone, un numéro de commande et un ISBN. JPA exige que les entités aient un identifiant associé à une clé primaire qui suivra également les mêmes règles ; identifier de façon unique une entité à l'aide d'un simple attribut ou d'un ensemble d'attributs (clé composée). Une fois affectée, la valeur de la clé primaire d'une entité ne peut plus être modifiée. A retenir : Un bean entité doit impérativement posséder un attribut dont la valeur est unique, dit identificateur unique ou clé primaire. Ce champ permet de différencier chaque objet entité des autres. Cette clé primaire doit être définie une seule fois dans toute la hiérarchie du bean entité. et Une clé primaire simple (non composée) doit correspondre à un seul attribut de la classe de l'entité. L'annotation que nous avons déjà rencontrée sert à indiquer une clé simple. L'attribut qui servira de clé doit être de l'un des types suivants : 1. Les types primitifs de Java : byte, int, short, long, char. 2. Les classes enveloppes des types primitifs : Byte, Integer, Short, Long, Character. 3. Tableau de types primitifs ou de classes enveloppes : int[], Integer[], etc. 4. Chaîne, nombre ou dates : java.lang.string, java.math.biginteger, java.util.date, java.sql.date. Remarque : en général, les décimaux (nombre à virgule) ne sont pas utilisés en tant que clé primaire. Les entités utilisant ce type pour la clé primaire risquent de ne pas être portables. Lorsque nous créons une entité, la valeur de cet identifiant peut être produite manuellement par l'application, ou automatiquement par le fournisseur de persistance si nous précisons l'annotation. Celle-ci peut accepter l'une des quatre valeurs suivantes :

6 1. IDENTITY : Ce type indique au fournisseur de persistance d'assigner la valeur de la clé primaire en utilisant la colonne identité de la base de données. Sous MySQL, par exemple, la clé primaire auto-générée est marquée avec AUTO_INCREMENT. (strategy = GenerationType.IDENTITY) private int id; 2. SEQUENCE : Ce type, comme son nom l'indique, oblige le fournisseur de persistance à utiliser une séquence de la base de données. Celle-ci peut être déclarée au niveau de la classe ou au niveau du package grâce à et ses attributs : name (requis) : définit un nom unique pour la séquence qui peut être référencée par une ou plusieurs classes (suivant le niveau utilisé pour la déclaration de l'annotation). sequencename (optionnel) : définit le nom de l'objet séquence de la base de données qui sera utilisé pour récupérer les valeurs des clés primaires liées. initialvalue (optionnel) : définit la valeur à laquelle doit démarrer la séquence. allocationsize (optionnel) : définit le nombre utilisé pour l'incrémentation de la séquence lorsque le fournisseur de persistance y accède. Attention, la valeur par défaut est = "SEQ_USER", sequencename = "SEQ_USER") public class Utilisateur implements Serializable { (strategy = GenerationType.SEQUENCE, generator = "SEQ_USER") public int id; Ce type de génération est utile lorsque la base de données offre un système natif de séquence et qu'il est conseillé de l'utiliser par le fournisseur de celle-ci. 3. TABLE : Ce type demande au fournisseur de persistance de stocker le nom de la séquence et sa valeur courante dans une table et d'incrémenter cette valeur à chaque fois qu'une nouvelle instance de l'entité est stockée dans la base. Derby, par exemple, crée une table SEQUENCE de deux colonnes : une pour le nom de la séquence (qui est arbitraire) et l'autre pour la valeur (un entier incrémenté automatiquement par Derby). De façon annecdotique, nous pouvons pousser plus loin notre investigation en proposant qui permet de préciser les paramètres de création de la table annexe de génération dont les attributs sont les suivants : name : définit un nom pour cette définition de table annexe. table : définit le nom de la table dans la base de données. pkcolumnname : spécifie le nom de la colonne qui contient le compteur de clé primaire. pkcolumnvalue : spécifie la colonne de la clé primaire liée. allocationsize : définit le nombre d'incrémentations effectuées lorsque le fournisseur demande à la table une nouvelle valeur. Cela permet au fournisseur d'utiliser un système de cache afin de ne pas demander une nouvelle valeur à chaque demande d'un nouvel name="c0ntact_gen", table="generateur_table", pkcolumnname="clé", valuecolumnname="haut", pkcolumnvalue="id", allocationsize=25 ) public class Utilisateur implements Serializable { (strategy = GenerationType.TABLE, generator = "CONTACT_GEN") public int id; 4. AUTO : Ce type demande que la génération d'une clé s'effectue automatiquement par la base de données sous-jacente, qui est libre de choisir la technique la plus appropriée. C'est la valeur par défaut de l'annotation. Ainsi, ce type indique au fournisseur de persistance d'utiliser la meilleure stratégie (entre ENTITY, TABLE, SEQUENCE) suivant la base de données utilisée. Le générateur AUTO est le type préféré pour avoir une application portable. Même si l'incrémentation automatique de la clé primaire soulage le développeur, elle doit être utilisée avec parcimonie. En effet, il est préférable d'utiliser un attribut de l'entité plutôt que d'en rajouter un, spécialement pour la clé primaire. Par exemple, l'entité Compte peut contenir une propriété numérocompte qui se veut unique par la logique bancaire. Cette propriété est alors la meilleure candidate pour la clé primaire. En l'absence de, l'application est responsable de la production des identifiants à l'aide d'un algorithme qui devra renvoyer une valeur unique. Le code source suivant montre comment obtenir automatiquement un identifiant :

7 public class Livre implements java.io.serializable { (strategy = GenerationType.AUTO) private String titre; private double prix; private String description; private String isbn; private int nombredepages; private boolean illustrations; Livre.java GenerationType.AUTO étant la valeur par défaut de l'annotation, nous aurions pu omettre l'élément strategy. Notez également dans tous nos exemples que l'attribut id est annoté deux fois : avec et avec. Clés primaires composées Lorsque nous associons des entités, il est conseillé dans la mesure du possible de dédier une seule colonne à la clé primaire. Dans certains cas, toutefois, nous sommes obligés de passer par une clé primaire composée. Voici un exemple typique ou l'association emprunte correspond à une table de jointure qui relie la table Livre à la table Personne. Dans ce cas là, pour garder le caractère d'unicité, la clé primaire de cette table de jointure doit être composée respectivement des clés étrangères noliv et nopers avec en plus la date de sortie (le livre peut être emprunté plusieurs fois par la même personne) : CREATE TABLE emprunte ( nopers integer not null, noliv integer not null, sortie date default current_date, retour date, primary key (noliv, nopers, sortie), foreign key (noliv) references Livre(noliv), foreign key (nopers) references Personne(nopers) ); En réalité, dans la technologie relative à la couche de persistance, la plupart du temps, nous n'avons pas besoin de créer explicitement des entités représentant les tables de jointures. Celles-ci sont fabriquées automatiquement à partir des beans entités représentant les deux tables principales comme ici Livre et Personne. Nous le verrons utltérieurement, c'est au moment de la mise en relation de entre l'entité Livre et l'entité Personne que la table de jointure se génère automatiquement. Toutefois, dans cet exemple précis, cette table de jointure dispose de deux champs importants que sont la date d'emprunt et la date de retour. Ainsi, cette table de jointure, en même temps qu'elle sert de jonction entre les livres et les personnes, sert également à enregistrer des informations importantes. Du coup, il est finalement nécessaire de créer une entité relative afin de bien prendre en compte ces dates de stockage et de restitution. Nous étudierons cette possibilité au travers d'un projet complet de gestion de bibliothèque. Dans ce type de situation, dans la couche de persistance, nous devons créer spécialement une classe de clé primaire pour représenter la clé primaire composée. Pour cela, nous disposons de deux annotations spécifiques pour cette classe, en fonction de la façon dont nous envisageons de structurer l'entité et Class. Comme nous le découvrirons, le résultat final sera le même. Nous aboutirons au même schéma de base de données, mais cela modifiera légèrement la façon d'interroger l'entité. Imaginons un projet d'entreprise dans lequel le système prévoit de poster fréquemment des articles sur une page d'accueil pour signaler de nouveaux livres, des titres musicaux ou des artistes. Ces articles doivent possèder un contenu, un titre et, comme ils sont écrits dans des langues différentes, un code langue (EN pour l'anglais, FR pour le français, etc.) La clé primaire des articles pourrait donc être composée du titre et du code de la langue car un article peut être traduit en plusieurs langues tout en gardant son titre initial. La classe de la clé primaire sera composée des attributs de type String titre et langue. Afin de permettre la gestion des requêtes et des collections internes, les classes des clés primaires doivent : 1. Redéfinir les méthodes equals() et hashcode() ; 2. En outre, leurs attributs doivent être de l'un des types déjà mentionnés. 3. Elles doivent également être publiques et implémenter l'interface Serializable si elles doivent traverser les couches de l'architecture (elles peuvent être gérées dans la couche de peristance et être utilisées dans la couche de présentation, par exemple). 4. Enfin, comme d'habitude, elles doivent posséder un constructeur par

8 Comme nous le verrons plus loin, JPA utilise différentes sortes d'objets intégrés (embedded). Pour faire court, un objet intégré n'a pas d'identité propre (il n'a donc pas de clé primaire) et ses attributs sont stockés dans des colonnes de la table associée à l'entité qui le contient. Le code source suivant présente la classe NewsId comme une classe intégrable (embeddable). Il s'agit simplement d'un objet intégré composé de deux attributs (titre et langue). Cette classe doit : 1. Redéfinir les méthodes equals() et hashcode() ; 2. En outre, leurs attributs doivent être de l'un des types déjà mentionnés. 3. Elles doivent également être publiques et implémenter l'interface Serializable si elles doivent traverser les couches de l'architecture (elles peuvent être gérées dans la couche de peristance et être utilisées dans la couche de présentation, par exemple). 4. Enfin, comme d'habitude, elles doivent posséder un constructeur par défaut. Le code source suivant présente la classe NewsId comme une classe intégrable (embeddable). Il s'agit simplement d'un objet intégré composé de deux attributs (titre et langue). Cette classe doit avoir un constructeur par défaut, des getters() et redéfinir la méthode equals() et hashcode(). Vous remarquez que la classe n'a pas d'identité par elle-même (aucune annotation : c'est ce qui caractérise un objet intégrable. package entité; entité.newsid.java import java.io.serializable; import public class NewsId implements Serializable { private String titre; private String langue; public NewsId() { public NewsId(String titre, String langue) { this.titre = titre; this.langue = langue; public String getlangue() { return langue; public String gettitre() { return public boolean equals(object obj) { // généré automatiquement par NetBeans if (obj == null) { return false; if (getclass()!= obj.getclass()) { return false; final NewsId other = (NewsId) obj; if ((this.titre == null)? (other.titre!= null) :!this.titre.equals(other.titre)) { return false; if ((this.langue == null)? (other.langue!= null) :!this.langue.equals(other.langue)) { return false; return public int hashcode() { // généré automatiquement par NetBeans int hash = 7; hash = 89 * hash + (this.titre!= null? this.titre.hashcode() : 0); hash = 89 * hash + (this.langue!= null? this.langue.hashcode() : 0); return hash; L'entité News, présentée dans le code source qui suit, doit maintenant intégrer la classe de clé primaire NewsId à l'aide de Toutes les doivent désigner une classe intégrable annotée package entité; entité.news.java import java.io.serializable; import javax.persistence.*; public class News implements Serializable private NewsId id; private String contenu;

9 public News() { public News(String titre, String langue, String contenu) { id = new NewsId(titre, langue); this.contenu = contenu; public NewsId getid() { return id; public String getcontenu() { return contenu; Lors d'une prochaine étude, nous verrons plus précisément comment retrouver les entités à l'aide de leur clé primaire, mais l'exemple ci-dessous présente le principe général : La clé primaire étant une classe avec un constructeur, vous devez d'abord l'instancier avec les valeurs qui forment la clé, puis passer cet objet au gestionnaire d'entités : package session; import entité.*; import javax.ejb.*; public class Gestion private EntityManager persistance; public News recherche(string titre, String langue) { return persistance.find(news.class, new NewsId(titre, langue)); session.gestion.java Class L'autre méthode pour déclarer une clé primaire compsée consiste à utiliser l'annotation Class. Cette approche est différente de la précédente car, ici, chaque attribut de la classe de la clé primaire doit également être déclaré dans la classe entité et annoté avec. La clé primaire NewsId du code source suivant est maintenant un objet classique qui ne nécessite aucune annotation particulière : package entité; import java.io.serializable; import javax.persistence.embeddable; public class NewsId implements Serializable { // la classe de la clé primaire n'est pas annotée private String titre; private String langue; public NewsId() { public NewsId(String titre, String langue) { this.titre = titre; this.langue = langue; public String getlangue() { return langue; public String gettitre() { return public boolean equals(object obj) { // généré automatiquement par NetBeans if (obj == null) { return false; if (getclass()!= obj.getclass()) { return false; final NewsId other = (NewsId) obj; if ((this.titre == null)? (other.titre!= null) :!this.titre.equals(other.titre)) { return false; if ((this.langue == null)? (other.langue!= null) :!this.langue.equals(other.langue)) { return false; return public int hashcode() { // généré automatiquement par NetBeans int hash = 7; entité.newsid.java

10 hash = 89 * hash + (this.titre!= null? this.titre.hashcode() : 0); hash = 89 * hash + (this.langue!= null? this.langue.hashcode() : 0); return hash; L'entité News doit simplement définir la classe de la clé primaire à l'aide de l'annotation Class et annoter chaque attribut de la clé avec. Pour stocker l'entité News, vous devrez maintenant donner une valeur aux attributs titre et langue. package entité; entité.news.java import java.io.serializable; import javax.persistence.*; Class(NewsId.class) public class News implements Serializable { private String titre; private String langue; private String contenu; public News() { public News(String titre, String langue, String contenu) { this.titre = titre; this.langue = langue; this.contenu = contenu; public NewsId getid() { return id; public String getcontenu() { return contenu; Les deux et Class, donneront la même structure de table. Les attributs de l'entité et de la clé primaire se retrouveront bien dans la même table et la clé primaire sera formée des attributs de la classe clé primaire (titre et langue). CREATE TABLE emprunte ( CONTENU varchar(255), TITRE varchar(255) not null, LANGUE varchar(255) not null, primary key (TITRE, LANGUE) ); L'approche par Class est plus sujette aux erreurs car vous devez définir chaque attribut de la clé primaire à la fois dans la classe de clé primaire et dans l'entité, en vous assurant d'utiliser les mêmes noms et les mêmes types. La seule différence visible est la façon dont vous ferez référence à l'entité dans JQPL. Class : SELECT n.titre FROM News : SELECT n.newsid.titre FROM News n Attributs Une entité doit posséder une clé primaire (simple ou composée) pour être identifiable dans une base de données relationnelle. Elle dispose également de toutes sortes d'attributs qui forment son état, qui doit également être associé à la table. Cet état peut contenir quasiment tous les types Java que vous pourriez vouloir associer : 1. Les types primitifs de Java : byte, int, short, long, char, float, double. 2. Les classes enveloppes des types primitifs : Byte, Integer, Short, Long, Character, Float, Double. 3. Tableaux d'octets ou de caractères : byte[], Byte[], char[], Character[]. 4. Chaîne, nombre ou dates : java.lang.string, java.math.biginteger, java.math.bigdecimal, java.util.date, java.util.calendar, java.sql.date, java.sql.time, java.sql.timestamp. 5. Les types énumérés et types implémentant l'interface Serializable, définis par l'utilisateur. 6. des collections de type de base et de type intégrable. Bien sûr, une entité peut également avoir des attributs entités, collections d'entités ou d'instances de classes intégrables. Ceci implique d'introduire des relations entre les entités (que nous étudierons en détail ultérieurement). Comme nous l'avons vu, en vertu de la configuration par exception, les attributs sont associés selon des règles par défaut. Parfois, cependant, vous aurez besoin d'adapter certaines parties de cette association ; c'est là que les annotations JPA entrent une nouvelle fois en jeu.

11 @Basic : La politique de l'api de persistance est de considérer toute propriété comme un champ persistant. Cela signifie qu'il n'est pas nécessaire d'annoter les propriétés pour les désigner persistantes. Le conteneur considère par défaut que la propriété est annotée avec les valeurs par défaut des attributs suivants : 1. fetch (FetchType.EAGER par défaut) : définit si le contenu de la propriété doit être chargée à la demande (Lazy loading - FetchType.LAZY - paresseusement) ou au moment du chargement de l'entité (FetchType.EAGER - désireux). 2. optional (true par défaut) : définit si la propriété accepte la valeur null ou non. Cet attribut ne fonctionne pas pour les types primitifs (qui ne peuvent être nuls). Pour spécifier qu'un attribut ne doit pas être persistant, vous devez l'annoter Considérons, par exemple, l'entité Piste du code source suivant. Un CD est en effet constitué de plusieurs pistes ayant chacune un titre, une description et un fichier.wav d'une certaine durée. Ce dernier est un BLOB qui peut occuper plusieurs mégaoctets. Lorsque nous accédons à l'entité Piste, nous ne voulons pas charger immédiatement le fichier WAV : nous annotons donc l'attribut = FetchType.LAZY) pour que ces données ne soient lues dans la base que lorsqu'elles seront vraiment nécessaires (lorsque nous accéderons, par exemple, à l'attribut wav via son getter) public class Piste { private String titre; private = FetchType.LAZY) private byte[] = true) private String description; Piste.java Notez que l'attribut wav de type byte[] est également afin que sa valeur soit stockée comme un LOB (Large Object) - les colonnes pouvant stocker ces types de gros objets nécessitent des appels JDBC spéciaux pour être accessibles à partir de Java. Pour en informer le fournisseur, il faut donc ajouter une à l'association de : Ainsi, s'avère utile lorsque vous souhaitez stocker des tableaux de bytes (byte[] ou Byte[]) pour représenter le contenu d'un fichier par public byte[] fichierimage; s'applique également sur des propriétés de type java.sql.clob (Character Large Object) ou java.sql.blob (Binary Large Object). Nous avons volontairement ajouté le mode paressseux. Effectivement, le contenu de cette propriété risque d'être de grande définit toutes les propriétés possibles d'une colonne dans la table. Grâce à elle, nous pouvons modifier le nom de la colonne (qui, par défaut, est le même que celui de l'attribut), la taille du champ correspondant, et de nombreuses autres caractéristiques à utiliser pour une propriété persistante, comme notamment si la valeur dans la colonne peut être nulle ou pas. Voici une description des attributs, tous optionnels, de : 1. name : précise le nom de la colonne liée. Le nom de la propriété est utilisée par défaut. 2. unique : précise si la propriété est une clé unique ou non (la valeur est unique dans la table). 3. nullable : précise si la colonne accepte des valeurs nulles ou non. 4. insertable : précise si la valeur doit être incluse lors de l'exécution de la requête SQL INSERT. La valeur par défaut est true. 5. updatable : précise si la valeur doit être mise à jour lors de l'exécution de la requête SQL UPDATE. La valeur par défaut est true. 6. columndefinition : précise le morceau de code SQL pour la définition de la colonne dans la base de données. C'est avec cet attribut que l'on peut préciser le type SQL de la colonne. 7. table : précise la table utilisée pour contenir la colonne. La valeur par défaut est la table principale de l'entité. Cet attribut est utilisé lorsqu'un bean entité est mappé sur plusieurs tables. 8. length : précise la longueur que la base de données doit associer à un champ texte. La longueur par défaut est precision : précise le nombre maximum de chiffres que la colonne peut contenir. La précision par défaut est définie par la base de données. 10. scale : précise le nombre fixe de chiffre après le séparateur décimal (en général le point). Cet attribut n'est utilisable que pour des propriétés décimales (float, double, ). Le nombre de décimales par défaut est définie par la base de données.

12 Les nombreux paramètres par défaut de l'api de persistance offrent un avantage certain au développeur. Celui-ci peut rapidement tester ses entités. Toutefois, il ne doit pas en rester là, mais utiliser les possiblités exposées ici pour optimiser le mapping entre ses entités et les tables de la base de données. Pour redéfinir l'association par défaut de l'entité Livre initiale, nous pouvons utiliser de différentes façons Ci-dessous, nous modifions les noms des colonnes associées aux attributs titre et nombredepages, pour lesquels nous n'autorisons pas les valeurs NULL ; nous précisons également la longueur de la colonne associée à description. et enfin nous proposons un affichage spécifique pour le prix au niveau de la table si nous désirons la consulter extérieurement : public class Livre implements java.io.serializable { (strategy = = "titre_livre", nullable = false, updatable = false) private String = 5, scale = 2) private double = 2000) private String description; private String = "nombre_pages", nullable = false) private int nombredepages; private boolean illustrations; Livre.java CREATE TABLE LIVRE ( ID BIGINT not null, TITRE_LIVRE VARCHAR(255) not null, PRIX DOUBLE(5, 2), DESCRIPTION VARCHAR(2000), ISBN VARCHAR(255), NOMBRE_PAGES INTEGER not null, ILLUSTRATION SMALLINT, primary key (ID) ); Table associée 1. La plupart des éléments de influent sur l'association. Si nous fixons à 2000 la longueur de l'attribut description, par exemple, la taille de la colonne correspondante sera également de Par défaut updatable et insertable valent true, ce qui signifie que nous pouvons insérer ou modifier n'importe quel attribut dans la base de données. En les positionnant à false, nous demandons au fournisseur de garantir qu'il n'insérera ni ne modifiera les données des colonnes associées à ces attributs lorsque l'entité sera elle-même modifiée. Notez que ceci n'implique pas que l'entité ne pourra être modifiée en mémoire - elle pourra l'être mais, en ce cas, elle ne sera plus synchronisée avec la base car l'instruction SQL qui sera produite (INSERT ou UPDATE) ne portera pas sur ces De la même manière, les types java.util.date ou java.util.calendar utilisés pour définir des propriétés dites temporelles peuvent être paramétrées pour spécifier le format le plus adéquat à sa mise en persistance, en faisant le choix entre la date, l'heure ou des millisecondes. Ceci peut être précisé grâce à qui prend en paramètre en TemporalType (énumération) dont les valeurs sont les suivantes : 1. DATE : utilisé pour la date uniquement (java.sql.date), 2. TIME : utilisé pour l'heure uniquement (java.sql.time), 3. TIMESTAMP : utilisé pour les temps plus précis, date + heure à la milliseconde près private Calendar datedenaissance; L'entité Photo du code source ci-dessous sera associé à la table décrite plus bas. L'attribut instant est associé à une colonne de type TIMESTAMP : public class Photo implements java.io.serializable { private String private Date instant; private int largeur; private int hauteur; entité.photo.java

13 private long poids; CREATE TABLE PHOTO ( ID VARCHAR(255) not null, INSTANT TIMESTAMP, LARGEUR INTEGER, HAUTEUR INTEGER, POIDS BIGINT, primary key (ID) ); Table Avec JPA, tous les attributs d'une classe annotée par sont sont automatiquement associés à une table. Si vous ne souhaitez pas associer un attribut particulier, utilisez Au travers d'une entité Personnel, nous pouvons avoir besoin éventuellement d'un attribut âge, qui est tributaire d'un calcul en rapport avec la date de naissance, mais qui ne nécessite pas spécialement d'être stocké dans la base de données. Il peut donc être déclaré comme transitoire à l'aide de public class Personnel implements java.io.serializable { private String nom; private String prénom; private String ; private String private Date private int âge; // cet attribut n'aura pas de colonne AGE associée Personnel.java CREATE TABLE PERSONNEL ( ID BIGINT not null, NOM VARCHAR(255), PRENOM VARCHAR(255), VARCHAR(255), TELEPHONE VARCHAR(255), NAISSANCE DATE, primary key (ID) ); Table Depuis J2SE 5.0, le langage Java apporte un nouveau type de données : les énumérations. Ce type existe depuis plusieurs années au sein des bases de données. Il est enfin possible de les utiliser dans les beans entités. L'énumération permet de spécifier un ensemble de valeurs possibles pour une propriété. Par exemple, le sexe d'un utilisateur ne peut prendre que deux valeurs possibles : Masculin ou Féminin. La solution idéale dans cette situation est bien entendu l'utilisation de l'énumération. La valeur d'une énumération peut être enregistrée soit via une chaîne de caractères soit via un entier. prend en paramètre un objet EnumType qui définit la façon de stocker cette valeur. Les valeurs EnumType.STRING ou EnumType.ORDINAL sont utilisées respectivement pour l'enregistrement dans une chaîne de caractères ou dans un entier. public class Utilisateur implements Serializable { public enum Sexe {Masculin, public Sexe sexe; Les valeurs d'une énumération sont en réalité des constantes auxquelles est implicitement associée un numéro déterminé par leur ordre d'apparition dans l'énumération. Ce numéro ne peut pas être modifié en cours d'exécution mais sert à stocker la valeur du type énuméré dans la base de données. Voici, par exemple, le code source représentant une énumération de type cartes de crédit : public enum TypeCarteCrédit { Visa, MasterCard, TypeCarteCrédit.java

14 AmericanExpress Les numéros affectés lors de la compilation aux valeurs de ce type énuméré seront respectivement : 0 pour Visa, 1 pour MasterCard, 2 pour AmericanExpress. Par défaut, les fournisseurs de persistance associerons ce type énuméré à la base de données en supposant que la colonne est de type INTEGER. Le code source suivant montre l'entité CarteCrédit qui utilise l'énumération précédente avec une association par défaut : public class CarteCrédit { private String numéro; private String dateexpiration; private int numérocontrol; private TypeCarteCrédit typecarte; CarteCrédit.java Les règles par défaut feront que l'énumération sera associée à une colonne de type entier et tout ira bien. Imaginons maintenant que nous ajoutions une nouvelle constante au début de l'énumération. L'affectation des numéros dépendant de l'ordre d'apparition des constantes, les valeurs déjà stockées dans la base de données ne correspondront plus à l'énumération. Une meilleure solution consiste donc à stocker le nom de la constante à la place de son numéro d'ordre. C'est ce que nous proposons avec avec la valeur STRING (sa valeur par défaut est ORDINAL). public class CarteCrédit { private String numéro; private String dateexpiration; private int private TypeCarteCrédit typecarte; CarteCrédit.java Désormais, la colonne TYPECARTE de la table sera de type VARCHAR et une carte Visa sera stockée sous la forme "Visa". Collections de types de base Les collections sont très utilisées en Java. Lors de cette étude, nous aurons l'occasion d'étudier les relations entre entités (qui peuvent être des collections d'entités) : essentiellement, ceci signifie qu'une entité contient une collection d'autres entités ou d'objets intégrables. En terme d'association, chaque entité est associée à sa propre table et nous créons alors des références entre les clés primaires et les clés étrangères. Dans de nombreux cas, il n'est pas toujours nécessaire de créer plusieurs entités alors qu'une seule peut suffire. Comme vous le savez, une entité est une classe Java avec une identité et de nombreux attributs : mais la question qui se pose c'est comment faire pour stocker dans une base de données un attribut qui représente une simple collection de types Java comme les String et/ou des Integer? Depuis JPA 2.0, intégré dans Java EE6, il n'est plus nécessaire de créer spécifiquement une classe distincte pour encapsuler ces collections, car nous disposons de nouvelles 1. indique qu'un attribut de type java.util.collection contient les types de base prédéfinis de Java, 2. tandis permet de modifier les détails de la table de la collection - son nom, par exemple. Si cette dernière est omise, le nom de la table sera formé par la concaténation du nom de l'entité conteneur et de celui de l'attribut représentant la collection, séparé par le caractère souligné ("_", appelé aussi underscore). Reprenons une nouvelle fois l'entité Personnel et modifions l'attribut téléphones qui donnera, comme son nom l'indique, la liste des numéros de téléphones. Nous avons donc besoin de mettre en place une collection de chaînes pour stocker tous ces numéros : public class Personnel implements java.io.serializable { private String nom; private String prénom; private String ; private ArrayList<String> téléphones = new Personnel.java

15 private Date private int âge; La première démarche consiste à ne placer aucune annotation sur l'attribut téléphones. La base de données considère alors, vu qu'il s'agit d'une collection et qu'il peut y avoir un nombre conséquent de valeurs, qu'il est préférable de prendre le type BLOB au niveau de la colonne représentant ces informations. En effet, java.util.arraylist implémente l'interface Serializable et JPA sait associer automatiquement des objets sérializables à des BLOB. En revanche, si vous utilisez une collection java.util.list, vous obtiendrez alors une exception car List n'implémente justement pas Serializable. Cela fonctionne parfaitement. Le problème de ce choix toutefois, c'est qu'il est alors très difficile de consulter au niveau de la table le contenu d'une telle colonne. public class Personnel implements java.io.serializable { private String nom; private String prénom; private String private ArrayList<String> téléphones = new private Date private int âge; Personnel.java informe le fournisseur de persistance que l'attribut téléphones est une liste de chaînes qui devra être enregistrée dans une table séparée dont le nom est par défaut PERSONNEL_TELEPHONES avec deux colonnes, d'une part PERSONNEL_ID qui représente la clé primaire de la table PERSONNEL et TELEPHONES qui stocke l'ensemble des numéros. est un moyen plus élégant et plus pratique de stocker les types primitifs puisque cette fois-ci nous visualisons parfaitement chacun des numéros de téléphone alors que le stockage sous un format binaire opaque aux requêtes les rends inaccessibles.

16 public class Personnel implements java.io.serializable { private String nom; private String prénom; private String = FetchType.EAGER) private ArrayList<String> téléphones = new private Date private int âge; Personnel.java Attention, les collections sont gérées de façon paresseuse au niveau de la base de données. Si vous voulez être sûr que vos numéros soient immédiatement enregistrés, il serait alors préférable de stipuler la valeur FetchType.EAGER sur l'attribut fetch public class Personnel implements java.io.serializable { private String nom; private String prénom; private String = = = "Numéro") private ArrayList<String> téléphones = new private Date private int âge; Personnel.java En l'absence nous l'avons vu, le nom de la table est PERSONNEL_TELEPHONES. Grâce à cette annotation, il est tout-à-fait possible de choisir explicitement le nom de la table représentant la collection juste en spécifiant l'attribut name. Vous remarquez que j'ai ajouté une supplémentaire afin de renommer également la colonne en Numéro au lieu de Téléphones. Voici le résultat obtenu en tenant compte de ces modifications. Personnellement, je trouve que les noms proposés par défaut sont assez évocateurs et j'utilise assez rarement cette

17 Association des types de base Comme les collections, les tables de hachage, communément appelées les cartes, sont très utiles pour le stockage des données. Avec JPA 1.0, nous pouvions pas en faire grand chose en terme d'orm. Désormais, les cartes peuvent utiliser n'importe quelle combinaison de types de base, d'objets intégrables et d'entités comme clés ou comme valeurs : ceci apporte beaucoup de souplesse. Pour l'instant, nous nous intéressons uniquement aux cartes qui utilisent les types de base. Lorsqu'une carte emploie des types de base, vous pouvez vous servir des exactement comme nous venons de le voir pour les collections. En ce cas, les données relatives aux cartes sont également stockées dans une table spécifique, la table de collection. Prenons l'exemple d'un CD contenant un certain nombre de pistes. Une piste peut être considérée comme un titre et une position (la première piste de l'album, la seconde, etc.). Vous pourriez alors utiliser des cartes de pistes utilisant un entier pour représenter la position (la clé) et une chaîne pour représenter le titre (la valeur) : public class CD implements java.io.serializable { private String titre; private double private byte[] jacquette; private String description; private HashMap<Integer, String> pistes = new HashMap<Integer, String>(); CD.java Comme précédemment, je propose de ne spécifier aucune annotation particulière sur l'attribut pistes. Là aussi, la colonne représentative PISTES de la table CD est alors de type BLOB : Là aussi, nous obtenons qu'une seule table qui possède alors toutes les caractéristiques. Cela peut suffire et fonctionne parfaitement. Ceci dit, encore une fois, la colonne représentant les pistes est totalement illisible (mais ce n'est peut-être pas un problème). public class CD implements java.io.serializable { private String titre; private double private byte[] jacquette; private String = = = = "Titre") private HashMap<Integer, String> pistes = new HashMap<Integer, String>(); CD.java 1. Comme nous l'avons déjà indiqué, permet d'indiquer que les cartes seront stockées dans une table à part. L'annotation quant à elle, est encore une fois utilisée pour modifier le nom par défaut de la table de collection en PISTE. 2. La différence avec les collections est que nous introduisons ici une nouvelle pour préciser l'association correspondant à la colonne clé de la carte. En son absence, le nom de cette colonne est formé par concaténation du

18 nom de l'attribut qui référence la relation et du suffixe _KEY. Le code source précédent utilise cette annotation pour la renommer POSITION afin qu'elle porte un nom plus lisible. 3. indique que la colonne contenant les valeurs des cartes sera nommée TITRE. Objets intégrables (Agrégation et Composition) Dans le chapitre sur "les clés primaires composées" plus haut dans cette étude, nous avons rapidement vu comment une classe pouvait être intégrée pour servir de clé primaire avec Les objets intégrables sont des objets qui n'ont pas d'identité persistante par eux-mêmes. Une entité peut contenir des collections d'objets intégrables ainsi qu'un simple attribut d'une classe intégrable : dans les deux cas, ils seronts stockés comme faisant partie de l'entité et partageront son identité. Ceci signifie que chaque attribut de l'objet intégré est associé à la table de l'entité. Il s'agit donc d'une relation de propriété stricte (agrégation forte ou composition). Ainsi, quand l'entité est supprimée, l'objet intégré disparaît également. Cette composition entre deux classes passe par des annotations. 1. La classe incluse 2. L'entité qui inclut Prenons l'exemple d'un client possédant un identifiant, un nom, un et une adresse. Tous ces attributs pourrait se trouver dans une seule entité Client, mais, pour des raisons de modélisation, ils sont répartis en deux classes Client et Adresse. Cette dernière n'ayant pas d'identité propre mais étant simplement une composante de l'état du client, c'est une bonne candidate au status de classe public class Adresse { private String rue; private String ville; private int codepostal; private String pays; Adresse.java Comme vous pouvez le constater à la lecture de ce code source, la classe Adresse est annotée comme étant non pas une entité mais une classe intégrable - indique qu'adresse peut être intégrée dans une entité (ou dans une autre classe intégrable). A l'autre extrémité de la composition, l'entité Client doit utiliser pour indiquer qu'adresse est un attribut persistant qui sera stockée comme composante interne et qu'il partage son identité. public class Client implements java.io.serializable { private String nom; private String prénom; private String ; private String private Adresse adresse; Client.java Chaque attribut d'adresse est associé à la table de l'entité Client. Nous disposerons ainsi d'une seule table qui fusionne l'ensemble des attributs des deux classes.

19 Relations entre entités Nous venons d'étudier toutes sortes d'annotations permettant de mapper une classe (ou plusieurs) dans une seule table. Le monde orienté objet regorge aussi de relations entre les classes, agrégation comme nous venons de la voir, associations unidirectionnelles, associations multiples, héritage, etc. Il est possible de rendre persistante cette information de telle sorte qu'une classe peut être liée à une autre dans un modèle relationnel. Il s'avère qu'une entité ne travaille généralement pas seule mais qu'elle est reliée à d'autres entités. On parle de relations entre entités. Cela correspond, bien entendu, à une base de données relationnelle où les tables sont effectivement en relations les unes avec les autres. Une relation possède une direction. Elle peut être unidirectionnelle (un objet peut utiliser un autre objet) ou bidirectionnelle (un objet peut interroger un autre objet et vice versa). En Java, nous utilisons le point (.) pour naviguer entre les objets. Ainsi, lorsque nous écrivons, par exemple : client.getadresse().getpays(); nous navigons d'un objet de type Client vers un objet de type Adresse puis vers un objet de type Pays. En UML, une relation : 1. unidirectionnelle entre deux classes est représentée par une flèche indiquant la direction. Ainsi, par exemple, Classe1 (la source) peut naviguer vers Classe2 (la cible), mais pas l'inverse. 2. bidirectionnelle n'utilise pas de flèche : Classe1 peut naviguer vers Classe2 et vice versa. En java, ce type de relation est représentée par une classe Classe1 ayant un attribut instance de Classe2 et par une classe Classe2 ayant un attribut instance de Classe1. 3. possède également une cardinalité. Chaque extrémité peut préciser le nombre d'objets impliqués dans cette relation. Par exemple, une instance de Classe1 est en relation avec zéro ou plusieurs instances de Classe2. En UML, une cardinalité est un intervalle compris entre un minimum et un maximum : 0..1 : signifie qu'il existera au minimum zéro objet et au maximum un objet 1 : signifie qu'il n'existera qu'une et une seule instance, 1..* : qu'il existera une ou plusieurs instances, 3..6 : qu'il existera entre trois et six objets. En Java, une relation qui représente plusieurs objets utilise les collections de : 1. java.util.collection, 2. java.util.set, 3. Java.util.List, 4. java.util.map. Ces types de conteneur sont en réalités des interfaces. Il faudra bien sur prévoir des conteneurs concrets en correspondance avec l'interface choisie. Ainsi par exemple, nous pourrons créer un conteneur de type ArrayList lorsque nous choisissons l'interface Collection.

20 Une relation possède un propriétaire. Dans une relation unidirectionnelle, ce propriétaire est implicite. Dans une relation bidirectionnelle, il faut en revanche l'indiquer explicitement en désignant le côté propriétaire, qui spécifie l'association physique, et le côté opposé (non propriétaire). Au cours de ce chapitre, nous verrons comment associer des collections d'objets à l'aide des annotations JPA. Relations dans la base de données relationnelles Dans le monde relationnel, les choses sont différentes puisque, à proprement parler, une base de données relationnelle est un ensemble de relations (également appelées tables) : tout est modélisé sous forme de table - pour modéliser une relation, vous ne disposez ni de listes, ni d'ensembles, ni de cartes : vous ne possédez que des tables. Ainsi, une relation entre deux classes Java sera représentée dans la base de données par une référence à une table qui peut être modélisée de deux façons : 1. Avec une clé étrangère (une colonne de jointure) : A titre d'exemple, supposons qu'un client n'ait qu'une seule adresse, ce qui implique une relation 1-1. En Java, la classe Client aurait donc un attribut Adresse ; dans le monde relationnel, vous pourriez avoir ainsi une table Client pointant vers une table Adresse via la clé étrangère, comme vous le découvrez ci-dessous : 2. Avec une table de jointure : la seconde méthode, comme vous le voyez ci-dessus, consiste à utiliser une table de jointure. Ainsi, la table Client ne stocke plus la clé étrangère vers Adresse mais utilise une table intermédiaire pour représenter la relation liant ces deux tables. Cette relation est constituée par les clés primaires des deux tables. Nous n'utilisons jamais de table de jointure pour représenter une relation 1-1 car cela pourrait avoir des conséquences sur les performances (il faudrait effectivement toujours accéder à la troisième table pour obtenir l'adresse d'un client) ; elles sont généralement réservées aux relations 1-N ou N-M. Comme nous le verrons par la suite, JPA utilise ces deux méthodes pour associer les relations entre les objets à une base de données.. Relations entre entités Revenons maintenat à JPA. La plupart des entités doivent pouvoir référencer ou être en relation avec d'autres entités. JPA permet d'associer ces relations de sorte qu'une entité puisse être liée à une autre dans un modèle relationnel. Comme pour les annotations d'associations élémentaires, que nous avons déjà étudiées, JPA utilise une configuration par exception pour ces relations : il utilise un mécanisme par défaut pour stocker une relation mais, si cela ne convient pas, vous disposez de plusieurs annotations pour adapter l'association à vos besoins. Les annotations correpondantes aux cardinalités d'une relation entre deux entités sont les suivantes, en sachant que chacune d'elles peut être utilisée de façon unidirectionnelle ou bidirectionnelle : N N-1 N-M Unidirectionnelle et bidirectionnelle Du point de vue de la modélisation objet, la direction entre les classes est naturelle. Dans une relation unidirectionnelle, un objet de type Classe1 pointe uniquement vers un objet de type Classe2, alors que dans une relation bidirectionnelle, ils se font mutuellement référence.

21 Cependant, comme le montre l'exemple suivant d'un client et de son adresse, un peu de travail est nécessaire lorsque nous désirons représenter une relation bidirectionnelle dans une base de données. 1. Dans une relation unidirectionnelle, une entité Client possède un attribut de type Adresse. Cette relation ne va que dans un seul sens : on dit que le client est le propriétaire de la relation. D'un point de vue de la base de données, ceci signifie que la table CLIENT contiendra une clé étrangère (une colonne de jointure) pointant vers la table ADRESSE. Par ailleurs, le propriétaire de la relation peut personnaliser la traduction de cette relation : si vous modifiez le nom de la clé étrangère, par exemple, cette annotation aura lieu dans l'entité Client (le propriétaire). 2. Cependant, comme nous l'avons mentionné précédemment, les relations peuvent être également bidirectionnelles. Ainsi, pour naviguer entre Adresse et Client, nous devons ajouter également un attribut Client à l'entité Adresse. Notez que les attributs représentant une relation n'apparaissent pas dans les diagrammes UML. En termes de Java et d'annotations, ceci revient à posséder deux associations de type 1-1 dans les deux directions opposées. Nous pouvons donc considérer une relation bidirectionnelle comme une paire de relations unidirectionnelles dans les deux sens. Gestion de la bidirectionnalité Comment associer une bidirectionnalité à une base de données? Qui est le propriétaire de cette relation bidirectionnelle? A qui appartient l'information sur la colonne ou la table de jointure? Posons-nous ces questions une fois pour toutes. Les cas les plus fréquents restent l'unidirectionnalité que nous traiterons par la suite. Pour une fois, nous commençons par le plus difficile (ce qui est très relatif). Si les relations unidirectionnelles possèdent un côté propriétaire, les bidirectionnelles ont à la fois un côté propriétaire et un côté opposé, qui doivent impérativement être indiqué explicitement par l'élément mappedby mappedby identifie ainsi l'attribut priopriétaire de la relation : il est obligatoire pour les relations bidirectionnelles. Afin d'illustrer tout ceci, comparons ensemble le code Java de sa traduction dans la base de données. Comme vous pouvez le constater dans le codage, les deux entités pointent l'une vers l'autre au moyen des attributs respectifs : Client possède un attribut adresse annoté et l'entité Adresse possède l'attribut client également annoté. Au niveau de la base de données se trouvent les deux tables respectives CLIENT et ADRESSE. CLIENT est la table propriétaire de la relation car elle contient la clé étrangère vers ADRESSE. 1. L'entité Adresse utilise mappedby de son Ici, mappedby indique que la colonne de jointure (adresse) est

22 déclarée à l'autre extrémité de la relation. 2. De son côté, l'entité Client définit la colonne de jointure avec et renomme la clé étrangère en AdresseId. 3. Client est l'extrémité propriétaire de le relation et, en tant que telle, est la seule à définir l'association de la colonne de jointure. 4. Adresse est l'extrémité opposée et c'est donc la table de l'entité propriétaire qui contient la clé étrangère (la table CLIENT possède bien une colonne ADRESSEID). Il existe un élément mappedby pour mais pas Relation Un à Un unidirectionnelle Maintenant que nous connaissons comment gérer la bidirectionnalité, revenons à des cas plus classiques. Une relation 1-1 est utilisée pour lier deux entités uniques indissociables. Par exemple, un corps ne possède qu'un seul coeur, ou une personne n'a qu'une seule carte d'identité. Une relation 1-1 unidirectionnelle entre deux entités a une référence de cardinalité 1 qui ne peut être atteinte que dans une seule direction. Reprenons l'exemple d'un client et de son adresse en supposant qu'il ne dispose que d'une seule adresse (cardinalité 1). Il faut pouvoir naviguer du client (la source) vers l'adresse (la cible) pour connaître où habite le client. Dans ce cas de figure, nous n'avons pas besoin de faire le trajet inverse (cela suppose que nous n'avons pas besoin de retrouver quel client habite à une adresse donnée). En Java, ceci signifie que la classe Client possède tout simplement un attribut adresse.. public class Client implements java.io.serializable { private String nom; private String prénom; private String ; private String téléphone; private Adresse adresse; Client.java public class Adresse { private String rue; private String ville; private int codepostal; private String pays; Adresse.java Comme vous pouvez le constater à la lecture de ces différents codes sources, ces deux entités utilisent un nombre minimal d'annotations - plus et pour la clé primaire, c'est tout Grâce à la configuration par exception, le fournisseur de persistance les associera à deux tables et ajoutera une clé étrangère pour représenter la relation (allant du client à l'adresse). Cette relation 1-1 est déclenchée par le fait qu'adresse est déclarée comme une entité et qu'elle est incluse dans l'entité Client sous forme d'un attribut. Nous n'avons donc pas besoin parce que le comportement par défaut suffit. Comme vous le savez, si un attribut n'est pas annoté, JPA lui applique les règles d'association par défaut. Ainsi, la colonne de la clé étrangère s'appelera donc ADRESSE_ID, qui est la concaténation du nom de l'attribut (adresse, ici), d'un underscore et du nom de la clé primaire de la table de destination (ici, la colonne ID de la table ADRESSE). Notez également que, dans le langage de définition des données, la colonne ADRESSE_ID peut, par défaut, recevoir des valeurs NULL : par défaut, une relation 1-1 est donc associée à zéro (NULL) ou une valeur :

23 comme nous l'avons découvert dans la rubrique sur la bidirectionnalité, il existe deux annotations permettant d'adapter l'association d'une relation La première (car la cardinalité de la relation est un) : elle permet de modifier certains attributs de la relation ellemême, comme la façon dont elle sera parcourue : package javax.persistence; import = {ElementType.METHOD, = RetentionPolicy.RUNTIME) OneToOne { API de public Class targetentity() default void.class; public CascadeType[] cascade() default {; public FetchType fetch() default FetchType.EAGER; public boolean optional() default true; public String mappedby() default ""; public boolean orphanremoval() default false; 2. L'autre annotation (son API ressemble beaucoup à celle Elle permet de personnaliser la colonne de jointure, c'est-à-dire la clé étrangère du propriétaire de la relation : package javax.persistence; import = {ElementType.METHOD, = RetentionPolicy.RUNTIME) JoinColumn { API de public String name() default ""; public String referencedcolumnname() default ""; public boolean unique() default false; public boolean nullable() default true; public boolean insertable() default true; public boolean updatable() default true; public String columndefinition() default ""; public String table() default ""; Le codage suivant présente un exemple d'utilisation de ces deux méthodes : Client.java public class Client implements java.io.serializable { private String nom; private String prénom; private String ; private nullable=false) private Adresse adresse; Le code précédent, grâce à permet de renommer la colonne de la clé étrangère en ADRESSEID et rendre la relation obligatoire en refusant les valeurs NULL. quant à elle, demande au fournisseur de persistance d'enregistrer automatiquement l'adresse lorsque nous rendons persistant un client.

24 Relation Un à Un unidirectionnelle : Mêmes valeurs pour les clés primaires Dans certain cas très particulier, il peut être possible de faire en sorte que les deux tables possèdent la même clé primaire pour identifier leurs propres éléments respectifs. Cela permet d'éviter de manipuler une clé étrangère, et donc de s'affranchir d'une colonne supplémentaire. Vous pouvez alors préciser ce choix au travers de (jointure par clé primaire). Revenons un instant sur le projet concernant l'archivage des photos. Il peut être judicieux de rajouter des fonctionnalités et de prévoir des retouches possibles sur un certain nombre de photos tout en conservant les originales. La photo renvoyée au client serait alors la version retouchée dont le traitement serait exécutée juste au moment de la requête. Pour cela, il serait utile de prévoir une persistance qui conserverait les réglages propre à la retouche, comme l'intensité, le contraste, etc. public class Photo implements java.io.serializable { private String id; private int largeur; private int hauteur; private private Retouche retouche; Photo.java public class Retouche implements java.io.serializable { private String id; private int intensité; private int contraste; Retouche.java J'aimerais faire quelques remarques quand à la persistance de deux entités quelque soit la stratégie de l'élaboration de chacune des tables : 1. Nous devons systématiquement créer deux objets entités séparemment, un pour la Retouche et un pour la Photo. 2. Dans cet exemple précis, pour ces deux objets, vous devez définir la clé primaire qui doit être identique. 3. Le plus important encore, c'est que vous devez rendre persistant chacun de ces beans entités (sauf dans le cas d'une stratégie en cascade). Attention, dans ce genre de situation, vous devez gérer vous-même l'identifiant commun. Vous ne pouvez pas demander une génération automatique de vos clés primaires à l'aide de l'annotation. Voici la constitution des deux tables au niveau de la base de données associées à ces deux entités respectives : Relation Un à Zéro (valeur optionnelle) Une relation Un à Zéro est implémentée de la même manière qu'une relation Un à Un. La seule différence réside dans le fait qu'elle est optionnelle. En reprenant notre exemple, une photo n'est pas obligée d'avoir une retouche si le cliché est de bonne facture. Pour transformer une relation Un à Un en une relation Un à Zéro, il suffit d'autoriser la valeur null dans la colonne implémentant la relation. Pour cela, il est nécessaire de positionner l'attribut nullable de à true. En réalité, c'est la valeur par défaut. Nous n'avons donc pas besoin de le spécifier.

25 Attention, ne possède pas un tel attribut, ce qui sous-entends que l'aspect facultatif ne peut pas être prise en compte et que la seule relation possible dans ce cas là, ne peut être qu'une relation de type 1-1. Finalement, si vous désirez intégrer le caractère facultatif d'un élément, vous êtes obligé de passer par une clé étrangère. public class Photo implements java.io.serializable { private String id; private int largeur; private int hauteur; private private Retouche retouche; Photo.java public class Retouche implements java.io.serializable { private int intensité; private int contraste; Retouche.java Attention, dans l'entité Retouche, il est préférable de prendre un identifiant de type long avec une génération automatique.. Voici la constitution des deux tables dans la base de données associées à ces deux entités respectives : Relation Un à Plusieurs unidirectionnelle Dans une relation 1-N, l'entité source référence un ensemble d'entités cibles. Une commande, par exemple, est composée d'un ensemble d'articles. cela peut être évoqué au moyen de Inversement, un article pourrait faire référence à la commande dont elle fait partie à l'aide, cette fois-ci, d'une Dans le diagramme UML ci-dessous, l'entité Commande est l'extrémité "One" (la source) de la relation (composition), et l'entité Article est son extrémité "Many" (la cible). La cardinalité est multiple et la navigation ne se fait que dans le sens Commande vers Article. En Java, cette multiplicité est décrite par les interfaces Collection, List et Set du paquetage java.util. public class Commande implements java.io.serializable private Date datecréation; private List<Article> articles = new ArrayList<Article>(); Commande.java public class Article implements java.io.serializable { private String intitulé; Article.java

26 private double prixunitaire; private int quantité; Comme vous pouvez le constater à la lecture du code relatif à l'entité Commande, nous n'avons placé aucune annotation particulière sur la collection d'articles. Comme toujours, cela veut dire que nous restons dans une configuration par exception. 1. Ainsi, lorsqu'une entité possède un attribut qui est une collection d'une autre entité, le système déclenche automatiquement une association de type OneToMany par défaut. 2. Toujours par défaut, les relations 1-N unidirectionnelles utilisent une table de jointure pour représenter la relation. Cette table est une liste de couples de clés étrangères : une clé fait référence à la table COMMANDE avec le même type que sa clé primaire, l'autre désigne la table ARTICLE. Cette table de jointure s'appelle par défaut COMMANDE_ARTICLE. Comme précédemment, si vous n'aimez pas le nom de la table de jointure ou celui des clés étrangères, ou si vous désirez associer la relation à une table existante, vous pouvez vous servir des annotations JPA pour redéfinir ces valeurs par défaut. 1. Le nom d'une colonne de jointure est formée par défaut par la concaténation du nom de l'entité, de l'underscore et du nom de la clé primaire désignée par la clé étrangère (COMMANDE_ID et ARTICLE_ID). 2. Comme permet de modifier le nom des colonnes de clés fait de même pour la table de jointure. 3. Vous pouvez également utiliser qui, permet de personnaliser la relation elle-même. package javax.persistence; import = {ElementType.METHOD, = RetentionPolicy.RUNTIME) JoinTable { API de public String name() default ""; public String catalog() default ""; public String schema() default ""; public JoinColumn[ ] joincolumns() default { ; public JoinColumn[ ] inversejoincolumns() default { ; public UniqueConstraint[ ] uniqueconstraints() default { ; Dans l'api de vous pouvez remarquer deux attributs de : joincolumns et inversejoincolumns. Ils permettent de différencier l'extrémité propriétaire de la relation et son extrémité opposée. L'extrémité propriétaire de la relation est décrite dans l'élément joincolumns et, dans notre exemple, désigne la table COMMANDE. L'extrémité opposée, la cible de la relation, est précisée par l'élément inversejoincolumns et désigne la table ARTICLE. public class Commande implements java.io.serializable private Date private List<Article> articles = new ArrayList<Article>(); Commande.java

27 La règle par défaut pour une relation 1-N unidirectionnelle consiste à utiliser une table de jointure. Il est souvent plus judicieux de faire en sorte d'utiliser des clés étrangères par l'intermédiaire des colonnes de jointure. Pour cela, par exemple, l'entité COMMANDE doit explicitement utiliser une en lieu et place de : public class Commande implements java.io.serializable private Date private List<Article> articles = new ArrayList<Article>(); Commande.java Le nom d'une colonne de jointure est formée par défaut par la concaténation du nom de l'attribut associé à de l'underscore et du nom de la clé primaire désignée par la clé étrangère (ARTICLES_ID). Il est tout à fait possible de paramétrer le nom de cette colonne en renseignant l'attribut name de : public class Commande implements java.io.serializable private Date private List<Article> articles = new ArrayList<Article>(); Commande.java Attention, le mode de parcours par défaut dans une relation 1-N est le mode paresseux. Si vous désirez systématiquement avoir à votre possession l'ensemble des articles constituant une commande en spécifiant le mode EAGER dans Comme précédemment, vous pouvez également en profiter pour imposer une persistance automatique de l'ensemble des articles au moment de la persistance de la commande. public class Commande implements java.io.serializable private Date private List<Article> articles = new ArrayList<Article>(); Commande.java Relation Plusieurs à Plusieurs bidirectionnelle

28 Une relation N-M bidirectionnelle intervient lorsqu'un objet source fait référence à plusieurs cibles et qu'une cible fait elle-même référence à plusieurs sources. Un album CD, par exemple, est créé par plusieurs artistes, et un même artiste peut apparaître sur plusieurs albums. 1. Côté Java, chaque entité contiendra donc une collection d'entités cibles. 2. En terme de base de données relationnelle, la seule façon de représenter une relation N-M consiste à utiliser, bien entendu, une table de jointure (une colonne de jointure ne peut pas convenir) ; comme nous l'avons évoqué précédemment, il est également nécessaire de définir explicitement le propriétaire d'une relation bidirectionnelle à l'aide de l'élément mappedby. En supposant que l'entité Artiste est propriétaire de la relation, ceci implique que CD est l'extrémité opposée et qu'elle doit utiliser l'élément mappedby de son Ici, mappedby indique au fournisseur de persistance que présentsurcds est le nom de l'attribut correspondant dans l'entité propriétaire de la relation : public class Artiste implements java.io.serializable { private String nom; private String private List<CD> présentsurcds = new ArrayList<CD>(); Artiste.java public class CD implements java.io.serializable { private String titre; private double prix; private String private List<Artiste> artistes = new ArrayList<Artiste>(); CD.java La structure de la base de données obtenue est la suivante : Dans une relation N-M et 1-1 bidirectionnelle, chaque entité peut, en fait, être considérée comme la propriétaire de la relation. Quoi qu'il en soit, l'autre extrémité doit inclure l'élément mappedby : dans le cas contraire, le fournisseur considérera que les deux extrémités sont propriétaires et traitera cette relation comme deux relations 1-N unidirectionnelles distinctes. Ici, cela produirait donc quatre tables : ARTISTE et CD et deux tables de jointures, ARTISTE_CD et CD_ARTISTE. Vous comprenez bien que nous ne pouvons pas non plus utiliser un élément mappedby des deux côtés de la relation. Chargement des relations Toutes les annotations que nous venons définissent un attribut de chargement qui précise que les objets associés doivent être chargés immédiatement (chargement "glouton") ou plus tard (chargement "paresseux") et qui influe donc sur les performances. Vous pouvez optimiser les performances en chargeant les données de la base lors de la première lecture de l'entité (glouton) ou uniquement lorsqu'elle est utilisée (paresseux). Chaque annotation possède une stratégie de chargement par défaut que nous devons connaître et qu'il est souhaitable de pouvoir modifier si cela ne convient pas. Nous pouvons donc changer ce comportement au travers du paramètre fetch qui peut prendre les deux valeurs : LAZY (paresseux) ou EAGER Stratégie de chargement par défaut EAGER EAGER LAZY LAZY A titre d'exemple, prenons deux cas extrèmes :

29 1. Supposons que nous ayons quatre entités toutes reliées les unes aux autres avec des cardinalités différentes (1-1, 1-N). Dans le premier cas, elles ont toutes des relations "gloutonnes", ce qui signifie que, dès que nous chargeons une entité représentée par la classe Classe1 (par une recherche par l'identifiant ou par une requête spécifique), tous les objets qui en dépendent sont automatiquement chargés en mémoire, ce qui peut avoir certaines répercussions sur votre système. 2. Dans le scénario opposé, toutes les relations utilisent un chargement paresseux. Lorsque nous chargeons une entité représentée par Classe1, rien d'autre n'est placé en mémoire (sauf les attributs directs de la classe, bien sûr). Il faut explicitement accéder à Classe2 (via la méthode getter correspondante, par exemple) pour que le fournisseur de persistance charge les données à partir de la base, etc. Ainsi, pour manipuler le graphe complet des objets, il est nécessaire d'appeler explicitement chaque entité en particulier. Ne pensez pas qu'eager est le mal et LAZY, le bien. 1. EAGER placera toutes les données en mémoire à l'aide d'un petit nombre d'accès à la base (le fournisseur de persistance utilisera sûrement des jointures pour extraire ces données). 2. Avec LAZY, vous ne risquez plus de remplir la mémoire puisque vous contrôlez les objets qui seront chargés, mais vous devrez faire plus d'accès à la base à chaque fois. Le paramètre fetch est finalement très important car, mal utilisé, il peut pénaliser les performances.. Lorsque, par exemple, vous chargez une commande dans votre application, vous avez toujours besoin d'accéder aux différents articles de cette commande. Il est donc plutôt avantageux de changer le mode de chargement par défaut de en EAGER. public class Commande implements java.io.serializable private Date private List<Article> articles = new ArrayList<Article>(); Commande.java Tri des relations Avec les relations 1-N, les entités gèrent des collections d'objets. Du point de vue de Java, ces collections ne sont généralement pas triées et les bases de données relationnelles ne garantissent pas non plus d'ordre sur leurs tables. Si vous désirez obtenir une liste triée, vous devez donc soit trier la collection dans votre programme, soit utiliser une requête JPQL avec une clause Order By. Pour le tri des relations, JPA dispose de mécanismes plus simples reposant sur les permet de réaliser un tri dynamique à la volée : les éléments de la collection seront ainsi triés lors de leur récupération à partir de la base de données. En reprenant l'exemple de l'application d'entreprise sur les commandes, nous pouvons rajouter une entité Client qui possède événtuellement plusieurs commandes qui seraient souhaitables qu'elles apparaissent chronologiquement. Dans l'entité Client, nous trions la liste des commandes par ordre décroissant des dates de création de chaque commande, en combinant avec

30 public class Client implements java.io.serializable { private String nom; private String prénom; private String ; private desc") private Commande commandes; public class Commande implements java.io.serializable private Date private List<Article> articles = new ArrayList<Article>(); Client.java Commande.java prend en paramètre les noms des attributs sur lesquels portera le tri (datecréation, ici) et la méthode (représentée par la chaîne ASC ou DESC, pour signifier, respectivement, un tri croissant ou décroissant). Vous pouvez utiliser plusieurs paires attribut/méthode en les séparant par des virgules : immaginons, par exemple, qu'une entité supérieure ait besoin de trier les clients ; d'abord suivant leurs noms et ensuite suivant leurs prénoms. Voici ce que nous pourrions placer sur un attribut représentant une collection de asc", "prénom asc") Cette annotation n'a aucun impact sur l'association dans la base de données - le fournisseur de persistance est simplement informé qu'il doit utiliser une clause order by lorsque la collection est JPA 1.0 supportait le tri dynamique avec mais ne permettait pas de maintenir un ordre persistant. JPA 2.0 règle ce problème à l'aide d'une nouvelle qui informe le fournisseur de persistance qu'il doit gérer la liste triée à l'aide d'une colonne séparée contenant un index. L'API est semblable à celle : package javax.persistence; import = {ElementType.METHOD, = RetentionPolicy.RUNTIME) OrderColumn { API de public String name() default ""; public boolean nullable() default true; public boolean insertable() default true; public boolean updatable() default true; public String columndefinition() default ""; public boolean contiguous() default true; public int base() default 0; public String table() default ""; Reprenons l'exemple mise en place précédemment avec la gestion des clients avec leurs commandes en le modifiant légèrement. Dans l'entité Client, nous pouvons alors annoter la relation avec les commandes afin que cette fois-ci le

31 fournisseur de persistance associe l'entité Client à une table contenant une colonne supplémentaire pour stocker l'ordre. public class Client implements java.io.serializable { private String nom; private String prénom; private String ; private private Commande commandes; Client.java public class Commande implements java.io.serializable private Date private List<Article> articles = new ArrayList<Article>(); Commande.java prend éventuellement en paramètre le nom de la nouvelle colonne. Si ce nom n'est pas redéfini, cette colonne porte alors le nom formé de la concaténation de l'entité référencée et la chaîne _ORDER (COMMANDES_ORDER, ici). Le type de cette colonne doit absolument être numérique. Cette annotation a des conséquences sur les performances car le fournisseur de persistance doit maintenant également gérer les modifications de l'index. Il doit maintenir le tri après chaque insertion, suppression ou réordonnacement. Si les données sont insérées au milieu d'une liste triée, le fournisseur devra retrier tout l'index. Pour réaliser un tri, vous avez donc le choix entre ces deux Pour ma part, je préfère largement cette dernière puisqu'elle prend moins de ressources au niveau de la base de données. Par ailleurs, vous ne pouvait pas spécifier le critère d'ordonancement. Attention, quelque soit votre choix, ces deux annotations ne peuvent pas être utilisées en même temps. L'héritage L'héritage est une notion essentielle et fondamentale de la programmation objet qui se retrouve dans la quasi-totalité de tout les types d'applications. En programmation orientée objet, les développeurs réutilisent fréquemment le code existant en héritant des attributs et des comportements de classes existantes. Toutefois, la représentation relationnelle d'un héritage d'objets est tout à fait particulier au niveau des tables de la base de données. Nous venons de voir que les relations entre entités ont des équivalents directs dans les bases de données. Ce n'est pas le cas avec l'héritage car ce concept est totalement inconnu du modèle relationnel. Il impose donc plusieurs contorsions pour être traduit dans un SGBDR. Pour représenter un modèle hiérarchique dans un modèle relationnel plat, JPA propose alors trois stratégies possibles : 1. Une seule table unique pour l'ensemble de la hiérarchie des classes. L'ensemble des attributs de toute la hiérarchie des entités est mis à plat et regroupé dans une seule table (il s'agit d'ailleur de la startégie par défaut). 2. Une table pour chaque classe concrète. Chaque entité concrète de la hiérarchie est associée à une table. 3. Jointure entre sous-classes. Dans cette approche, chaque entité de la hiérarchie, concrète ou abstraite, est associée à sa propre table. Ainsi, nous obtenons dans ce cas là une séparation des attributs spécifiques de la classe fille par rapport à ceux de la classe parente. Il existe alors, une table pour chaque classe fille, plus une table pour la classe parente. Une jonction est alors nécessaire pour instancier la classe fille. Le support de la stratégie une table pour chaque classe concrète est encore facultatif avec JPA 2.0. Les applications portables doivent donc l'éviter tant que ce support n'a pas été officiellement déclaré comme obligatoire dans toutes les implémentations. Tirant parti de la simplicité d'utilisation des annotations, JP 2.0 fournit un support déclaratif pour définir et traduire les hiérérachies d'héritage comprenant des entités concrètes, des entités abstraites, des classes traduites et des classes transitoires. s'applique à une entité racine pour imposer une stratégie d'héritage à cette classe et à ses classes filles. JPA traduit aussi la notion objet de redéfinition qui permet aux attributs de la classe fille d'être redéfinis dans les classes filles. Stratégies d'héritage JPA propose donc trois stratégies pour traduire l'héritage. Lorsqu'il existe une hiérarchie d'entités, sa racine est toujours une entité qui peut définir la

32 stratégie d'héritage à l'aide de Si elle ne le fait pas, c'est la stratégie par défaut qui est appliquée, consistant à créer une seule table pout toute la hiérarchie. Attention : une seule clé primaire doit être définie dans une hiérarchie. Elle est généralement déclarée dans la classe ancêtre afin que toutes les classes filles puissent en bénéficier. Pour chaque cas, nous étudierons les annotations utilisées et la structure relationnelle engendrée. Ces annotations sont primordiales uniquement pour choisir l'organisation souhaitée au niveau de la base de données. Par contre, lorsque nous utilisons les beans entités, côté codage Java, nous restons dans une écriture et une utilisation tout à fait classique. Afin d'expliquer chacune de ces stratégies, nous étudierons comment traduire les entités CD et Livre, qui héritent toutes les deux de l'entité Document. Document est l'entité racine ; elle possède un identifiant unique qui servira de clé primaire pour l'ensemble de la hiérarchie. La clé primaire sera ainsi automatiquement récupérée par le mécanisme d'héritage. Chacune de ses classes filles ajoute également ses propres attributs supplémentaires comme genre pour l'entité Livre et duréetotale pour l'entité CD. Stratégie utilisant une seule table Il s'agit de la stratégie de traduction de l'héritage par défaut, dans laquelle toutes les entités de la hiérarchie sont mappées dans une même et unique table. Il n'est donc pas nécessaire d'utiliser sur l'entité racine, comme le montre le code suivant : public abstract class Document implements java.io.serializable { private String titre; private double prix; private String description; private Auteur auteur; Document.java Document est la classe parente des entités Livre et CD. Ces entités héritent des attributs de Document ainsi que de la stratégie d'héritage par défaut : elles n'ont donc pas besoin elles-même d'utiliser public class Livre extends Document { private String genre; private int nombrepages; private boolean illustration; public class CD extends Document { private double private List<String> pistes = new ArrayList<String>(); Livre.java CD.java Sans l'héritage, ces trois entités seraient traduites en trois tables distinctes. Avec la stratégie de traduction de l'héritage par une seule table, elles finiront toutes dans la table portant par défaut le nom de la classe racine : DOCUMENT.

33 Comme vous pouvez le constater, la table DOCUMENT rassemble tous les attributs des entités Document, Livre et CD. Cependant, elle contient une colonne supplémentaire qui n'est liée à aucun des attributs des entités : la colonne discriminante, DTYPE. La table DOCUMENT sera remplie de livres et de CD. Lorsqu'il accède aux données, le fournisseur de persistance doit savoir à quelle entité appartient chaque ligne afin d'instancier la classe d'objet appropriée (Livre ou CD) : la colonne discriminante est donc là pour préciser explicitement le type de chaque colonne. 1. Cette stratégie fournit un gain de performance important, car aucune jointure n'est réalisée. 2. En même temps, comme vous pouvez le constater, la stratégie avec une table possède quelques défauts. Nous voyons, par exemple, que toutes les colonnes ne sont pas nécessairement utiles à toutes les entités (cases violettes). Suivant le cas, nous pouvons obtenir de gros gaspillages. Lorsque nous enregistrons, par exemple, un disque dans la base de données, les colonnes GENRE, NOMBREPAGES et ILLUSTRATION deviennent totalement inutiles. La colonne discriminante, s'appelle DTYPE, par défaut, elle est de type String (traduit en VARCHAR avec une taille par défaut de 31) et elle contient tout simplement le nom de l'entité (ce qui offre une grande lisibilité au niveau de la table). Si ce comportement par défaut ne vous convient pas, il est tout-à-fait possible d'utiliser pour modifier le nom et le type de cette colonne. Les attributs de cette annotation sont alors : 1. name : nom de la colonne de discrimination qui sera utile pour indiquer le nom de la classe utilisée dans la hiérarchie. 2. discriminatortype : classe du discriminateur à utiliser via l'énumération DiscriminatorType. Celle-ci possède les attributs suivants : CHAR INTEGER STRING 3. length : taille de la colonne pour les discriminateurs à base de chaîne de caractères. 4. columndefinition : fragment SQL à utiliser pour la déclaration de la colonne (utilisé lors de la génération des tables par le conteneur). Dans le code suivant, nous renommons la colonne discriminante en DOCUMENT (au lieu donc de DTYPE). Nous proposons également de changer le type de cette colonne pour qu'elle soit de type char en lieu et place du type String. Du coup, chaque entité concrète change également sa valeur discrimante par défaut et propose la lettre "L" pour indiquer qu'il s'agit d'un document de type Livre, et la lettre "C" pour indiquer qu'il s'agit d'un CD discriminatortype=discriminatortype.char) public abstract class Document implements java.io.serializable { private String titre; private double prix; private String description; private Auteur auteur; Document.java L'entité racine Document définit la colonne discriminante pour toute la hiérarchie à l'aide de Pour que cela fonctionne correctement, chaque entité fille doit uniquement redéfinir sa propre valeur discriminante au moyen de Livre.java

34 @DiscriminatorValue("L") public class Livre extends Document { private String genre; private int nombrepages; private boolean public class CD extends Document { private double private List<String> pistes = new ArrayList<String>(); CD.java Voici le résultat obtenu par rapport au choix que nous venons de réaliser : Conclusion sur cette stratégie 1. Cette stratégie de table unique est donc la stratégie par défaut ; c'est la plus facile à comprendre et elle fonctionne très bien lorsque la hiérérachie est relativement simple et stable. En revanche, comme nous l'avons déjà évoqué, elle possède quelques défauts : notamment, l'ajout de nouvelles entités dans la hiérarchie ou d'attributs dans des entités existantes implique d'ajouter des colonnes à la table, de migrer les données et de modifier les index. 2. Cette stratégie exige également que les colonnes des entités filles puissent recevoir la valeur NULL : si GENRE de l'entité Livre n'était pas nullable, par exemple, nous serions dans l'incapacité de pouvoir insérer un CD puisque ce dernier ne possède pas cette rubrique. Pour terminer, il est également possible de mapper cette colonne DOCUMENT sur un attribut (typedocument) afin de pouvoir contrôler par programme les différents types d'objets enregistrés, à condition toutefois de bien préciser insertable=false et updatable=false discriminatortype=discriminatortype.char) public abstract class Document implements java.io.serializable { private String titre; private double prix; private String description; private Auteur insertable=false, updatable=false) private char typedocument; Document.java Stratégie par jointure Dans cette stratégie, chaque entité de la hiérarchie est associée à sa propre table. Ici, la classe ancêtre des entités est représentée par une table, avec, là aussi, une colonne discriminante. Ainsi, chaque sous-classe est représentée par une table distincte contenant ses propres attributs (non hérités de la classe racine) et une clé primaire qui fait référence à celle de la table racine. Les classes filles n'ont, en revanche, pas de colonne discriminante. Pour implémenter une stratégie par jointure, nous sommes cette fois-ci obligé d'utiliser sur l'entité racine en spécifiant le bon paramètre au niveau de l'attribut. Le seul attribut de cette annotation est strategy. Il permet de spécifier le type de stratégie à utiliser pour construire la ou les tables à mettre en oeuvre, via l'énumération InheritanceType. Pour indiquer que nous désirons une stratégie par jointure, nous prenons le paramètre InheritanceType.JOINED dans Par contre, les classes filles n'ont pas besoin d'autre annotation que (sauf éventuellement l'annotation propre à la valeur du discriminant). A ce sujet, nous pouvons là aussi utiliser dans l'entité racine afin de personnaliser la colonne discriminante.

35 Document.java discriminatortype=discriminatortype.char) public abstract class Document implements java.io.serializable { private String titre; private double prix; private String description; private Auteur auteur; public class Livre extends Document { private String genre; private int nombrepages; private boolean illustration; public class CD extends Document { private double private List<String> pistes = new ArrayList<String>(); Du point de vue du développeur, la stratégie par jointure est naturelle car chaque entité, qu'elle soit abstraite ou concrète, sera traduite dans une table distincte. 1. L'avantage de cette stratégie est d'avoir un modèle relationnel clair. C'est en quelque sorte le modèle idéal pour la base de données (pas de perte mémoire car tous les champs sont utilisés). La stratégie par jointure est également intuitive et proche de ce que nous connaissons du mécanisme de l'héritage. C'est un moyen de fournir un bon support au polymorphisme. 2. En contre parti, elle a un impact sur les performances des requêtes. En effet, pour recréer une simple instance d'une sous-classe, il faut joindre sa table à celle de la classe racine. Plus la hiérarchie est profonde, plus il faudra de jointures pour recréer l'entité feuille. Dans le cas de hiérarchies importantes (grande profondeur de l'héritage) cela peut entraîner de très mauvaises performances. Stratégie une table par classe Dans cette stratégie (une table par classe concrête), chaque entité est traduite dans sa propre table, comme avec la stratégie par jointure. La différence est qu'ici tous les attributs de l'entité racine seront également traduits en colonnes de la table associée à l'entité fille. Cela signifie que toutes les propriétés de la classe (avec celles récupérées par héritage) sont incluses dans la table liée à cette entité. Ici, nous n'avons pas de table partagée, pas de colonne partagée ni de colonne discriminante. La seule exigence est que toutes les tables de la hiérarchie doivent partager la même clé primaire. Pour spécifier cette stratégie, il faut juste choisir cette fois-ci InheritanceType.TABLE_PER_CLASS dans Encore une fois, les classes filles héritent simplement sans avoir besoin de préciser de spécifications supplémentaires autres public abstract class Document implements java.io.serializable { Document.java

36 private String titre; private double prix; private String description; private Auteur auteur; Livre.java public class Livre extends Document { private String genre; private int nombrepages; private boolean illustration; CD.java public class CD extends Document { private double private List<String> pistes = new ArrayList<String>(); Voici les tables obtenues. Vous remarquez que LIVRE et CD dupliquent les colonnes ID, TITRE, PRIX, DESCRIPTION et AUTEUR_ID de la table DOCUMENT et que les tables ne sont plus liées entre elles. 1. Cette stratégie est très performante lorsque nous interrogeons des instances d'une seule entité car nous nous retrouvons dans un scénario comparable à l'utilisation de la stratégie à une seule table - la requête ne porte que sur une seule table. 2. L'inconvénient est que les requêtes polymorphiques à travers une hiérarchie de classes sont plus coûteuses que les deux autres stratégies. Par exemple, pour rechercher tous les articles, que ce soit des livres ou des CD, il faut alors interroger toutes les tables des sous-classes avec une opération utilisant une UNION, ce qui est coûteux lorsque nous avons beaucoup de données. L'autre inconvénient est la duplication des colonnes dans chacune des tables des beans entités. Type de classes dans une hiérarchie d'héritage L'exemple utilisé pour expliquer les stratégies de traduction de l'héritage n'utilise que des entités, mais les entités n'héritent pas que d'entités. Une hiérarchie de classes peut contenir un mélange d'entités, de classes qui ne sont pas des entités (classes transitoires), d'entités abstraites et de superclasses déjà traduites. Hériter de ces différents types de classes a un impact sur la traduction de la hiérarchie. Entités abstraites Nous l'avons vu au travers de nos différents exemples, une classe abstraite comme Document peut tout-à-fait être désignée comme une entité. Elle ne diffère d'une entité concrète que parce qu'elle ne peut pas être directement instanciée, mais elle fournit une structure de données que partagerons toutes ses entités filles (Livre et CD) et elle respecte les stratégies de traduction d'héritage. Du point de vue du fournisseur de persistance, la seule différence se situe du côté de Java, pas dans la correspondnce avec les tables.. Non-entités Les non-entités sont également appelées classes transitoires. Une entité peut hériter d'une non-entité ou peut être étendue par une non-entité. La modélisation objet et l'héritage permettent de partager les états et les comportements ; dans une hiérachie de classes, les non-entités peuvent donc servir à fournir une structure de données commune à leurs entités filles. L'état d'une superclasse non entité n'est pas persistant car il n'est pas géré par le fournisseur de persistance (n'oubliez pas que la condition pour qu'une classe le soit est la présence de l'annotation ).

37 Dans le code source ci-dessous, Document devient une simple classe transitoire. public abstract class Document implements java.io.serializable { private String titre; private double prix; private String description; private Auteur auteur; Document.java L'entité Livre hérite toujours de Document ; le code Java peut donc accéder aux attributs titre, prix, description et auteur ainsi qu'à toutes les méthodes de Document. Que cette dernière soit concrète ou abstraite n'aura aucune influence sur la traduction finale. public class Livre extends Document { private String genre; private int nombrepages; private boolean illustration; Livre.java Livre est une entité qui hérite de Document, mais seuls les attributs de Livre seront stockés dans une table. Aucun attribut de Document n'apparaît dans la structure de la table ci-dessous. Pour qu'un Livre soit persistant, vous devez créer une instance de Livre, initialiser les attributs que vous souhaitez (titre, prix, description, etc.), mais seuls ceux de Livre (genre, nombrepages, etc.) seront stockés. Superclasse "mapped" JPA définit un type de classe spéciale, appelé superclasse "mapped", qui partage son état, son comportement ainsi que des informations de traduction des entités qui en héritent. 1. Cependant, les superclasses "mapped" ne sont pas des entités, elles ne sont pas gérées par le fournisseur de persistance, n'ont aucune table qui leur soit associée et ne peuvent pas être interrogées ni faire partie d'une relation. 2. En revanche, elles peuvent fournir des propriétés de persistance aux entités qui en héritent. 3. Les superclasses "mapped" ressemblent aux classes intégrables, sauf qu'elles peuvent être utilisées avec l'héritage. Elle sont annotées Dans le code source ci-dessous, la classe racine Document est annotée pas par. Elle définit une stratégie de traduction de l'héritage (JOINED) et annote certains de ses attributs Cependant, les superclasses "mapped" n'étant pas associées à des tables, n'est public abstract class Document implements java.io.serializable nullable=false) private String titre; private double private String description; Document.java L'entité Livre hérite toujours de Document ; le code Java peut donc accéder aux attributs titre, prix, description et auteur ainsi qu'à toutes les méthodes de Document. Que cette dernière soit concrète ou abstraite n'aura aucune influence sur la traduction finale. public class Livre extends Document { private String genre; private int nombrepages; private boolean illustration; Livre.java

38 Livre est une entité qui hérite encore de Document. Cette hiérarchie sera traduite en une seule table. Document n'est pas une entité et n'a donc aucune table associée. Les attributs de Document seront traduits en colonnes de la table LIVRE - les superclasses "mapped" partageant également leurs informations de traduction, les de Document seront donc également héritées.

Applications orientées données (NSY135)

Applications orientées données (NSY135) Applications orientées données (NSY135) 10 Lecture de données Auteurs: Raphaël Fournier-S niehotta et Philippe Rigaux (philippe.rigaux@cnam.fr,fournier@cnam.fr) Département d informatique Conservatoire

Plus en détail

Relation many-to-one. Implémentation de l'association. Relation bidirectionnelle

Relation many-to-one. Implémentation de l'association. Relation bidirectionnelle Ajoutons maintenant la classe User et l'association many-to-one qui la lie avec la classe Event. L'arborescence du projet est maintenant la suivante : Implémentation de l'association Relation bidirectionnelle

Plus en détail

Java EE Approfondi - Cours 2. Cours de 2 e année ingénieur Spécialisation «Génie Informatique»

Java EE Approfondi - Cours 2. Cours de 2 e année ingénieur Spécialisation «Génie Informatique» Java EE Approfondi - Cours 2 Cours de 2 e année ingénieur Spécialisation «Génie Informatique» Présentation Lier l'orienté objet et la base de données relationnelle peut être lourd et consommateur en temps.

Plus en détail

Java Licence professionnelle CISI 2009-2010

Java Licence professionnelle CISI 2009-2010 Java Licence professionnelle CISI 2009-2010 Cours 10 : Type générique (c) http://manu.e3b.org/java/tutoriels/avance/generique.pdf 1 Introduction La programmation générique - nouveauté la plus significative

Plus en détail

1. Installation d'un serveur d'application JBoss:

1. Installation d'un serveur d'application JBoss: EPITA Ala Eddine BEN SALEM App-Ing2 J2EE T.P. 4 EJB3, Serveur d'application JBoss 1. Installation d'un serveur d'application JBoss: télécharger l'archive du serveur JBoss à l'adresse: http://sourceforge.net/projects/jboss/files/jboss/jboss-5.0.0.ga/jboss-5.0.0.ga.zip/download

Plus en détail

Quelques patterns pour la persistance des objets avec DAO DAO. Principe de base. Utilité des DTOs. Le modèle de conception DTO (Data Transfer Object)

Quelques patterns pour la persistance des objets avec DAO DAO. Principe de base. Utilité des DTOs. Le modèle de conception DTO (Data Transfer Object) Quelques patterns pour la persistance des objets avec DAO Ce cours présente des modèles de conception utilisés pour effectuer la persistance des objets Université de Nice Sophia-Antipolis Version 1.4 30/8/07

Plus en détail

Application web de gestion de comptes en banques

Application web de gestion de comptes en banques Application web de gestion de comptes en banques Objectif Réaliser une application Web permettant à un client de gérer ses comptes en banque Diagramme de cas d'utilisation 1 Les cas d'utilisation Connexion

Plus en détail

TP6 EJB : Création d'un EJB3 Entité

TP6 EJB : Création d'un EJB3 Entité TP6 EJB : Création d'un EJB3 Entité Objis : nous allons vous faire aimer JAVA - www.objis.com 1 Table des matières Formation EJB - TP 'Développement EJB3 entity avec Eclipse' Propriété du document...3

Plus en détail

Compte Rendu d intégration d application

Compte Rendu d intégration d application ISMA 3EME ANNEE Compte Rendu d intégration d application Compte Rendu Final Maxime ESCOURBIAC Jean-Christophe SEPTIER 19/12/2011 Table des matières Table des matières... 1 Introduction... 3 1. Le SGBD:...

Plus en détail

Chapitre 10. Les interfaces Comparable et Comparator 1

Chapitre 10. Les interfaces Comparable et Comparator 1 Chapitre 10: Les interfaces Comparable et Comparator 1/5 Chapitre 10 Les interfaces Comparable et Comparator 1 1 Ce chapitre a été extrait du document "Objets, Algorithmes, Patterns" de [René Lalement],

Plus en détail

DB Main Bien débuter.

DB Main Bien débuter. DB Main Bien débuter. Downloader depuis http://www.info.fundp.ac.be/~dbm/ L élaboration d une base de données se fait en 4 étapes : 1. L analyse conceptionnelle 2. Le MCD modèle conceptuel de données.

Plus en détail

Cours Bases de données 2ème année IUT

Cours Bases de données 2ème année IUT Cours Bases de données 2ème année IUT Cours 6 : JDBC : ou comment lier ORACLE avec Java 1ère partie Anne Vilnat http://www.limsi.fr/individu/anne/cours Plan 1 Introduction 2 les étapes de la connexion

Plus en détail

Création et Gestion des tables

Création et Gestion des tables Création et Gestion des tables Version 1.0 Z Grégory CASANOVA 2 Sommaire 1 Introduction... 3 2 Pré-requis... 4 3 Les tables... 5 3.1 Les types de données... 5 3.1.1 Les types de données Sql Server... 5

Plus en détail

La gestion de la persistance avec Hibernate. Hibernate et la gestion de persistance. La gestion de la persistance (1/2) Introduction

La gestion de la persistance avec Hibernate. Hibernate et la gestion de persistance. La gestion de la persistance (1/2) Introduction La gestion de la persistance avec et la gestion de persistance Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon - BP 540 76058 LE HAVRE CEDEX Claude.Duvallet@gmail.com

Plus en détail

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile Dans ce TP, vous apprendrez à définir le type abstrait Pile, à le programmer en Java à l aide d une interface

Plus en détail

Pour signifier qu'une classe fille hérite d'une classe mère, on utilise le mot clé extends class fille extends mère

Pour signifier qu'une classe fille hérite d'une classe mère, on utilise le mot clé extends class fille extends mère L'héritage et le polymorphisme en Java Pour signifier qu'une classe fille hérite d'une classe mère, on utilise le mot clé extends class fille extends mère En java, toutes les classes sont dérivée de la

Plus en détail

Licence Professionnelle Développeur Web Programmation Orientée Objets Gestion de comptes en banque (Philippe.Genoud@imag.fr)

Licence Professionnelle Développeur Web Programmation Orientée Objets Gestion de comptes en banque (Philippe.Genoud@imag.fr) Grenoble 1 IMA Informatique & Mathématiques Appliquées UNIVERSITE JOSEPH FOURIER Sciences, Technologie, Médecine Licence Professionnelle Développeur Web Programmation Orientée Objets Gestion de comptes

Plus en détail

Document d'aide phpmyadmin et MySQL

Document d'aide phpmyadmin et MySQL Document d'aide phpmyadmin et MySQL GPA775 Base de données École de Technologie Supérieure 23 juin 2009 Ce document sert de guide de base pour travailler avec l'interface phpmyadmin (interface par un navigateur

Plus en détail

SQL SERVER 2008 Le 20/10/2010

SQL SERVER 2008 Le 20/10/2010 Définitions SQL SERVER 2008 Le 20/10/2010 Une base de données est un objet particulièrement difficile à définir puisqu il est abordé en pratique selon différents points de vue : Pour un administrateur,

Plus en détail

Compte-rendu de projet de Système de gestion de base de données

Compte-rendu de projet de Système de gestion de base de données Compte-rendu de projet de Système de gestion de base de données Création et utilisation d'un index de jointure LAMBERT VELLER Sylvain M1 STIC Université de Bourgogne 2010-2011 Reponsable : Mr Thierry Grison

Plus en détail

Génération de codes. à partir d un modèle UML sous PowerAMC. La génération de code, ça n est pas immédiat : processus en 3 étapes

Génération de codes. à partir d un modèle UML sous PowerAMC. La génération de code, ça n est pas immédiat : processus en 3 étapes Génération de codes à partir d un modèle UML sous PowerAMC Véronique Deslandres, IUT, Département Informatique Université de Lyon MàJ: 8/10/2013 Introduction La génération de code, ça n est pas immédiat

Plus en détail

Chapitre 3 LE MODELE RELATIONNEL

Chapitre 3 LE MODELE RELATIONNEL Chapitre 3 LE MODELE RELATIONNEL Le modèle relationnel a été inventé en 1960 et a fait l'objet de très nombreuses recherches qui ont débouché sur la réalisation et commercialisation de SGBDs relationnels.

Plus en détail

Diagramme de classes

Diagramme de classes Diagramme de classes Un diagramme de classes décrit les classes et leurs relations (associations, généralisation/spécialisation, ). classe association méthodes attributs héritage Diagramme de classes :

Plus en détail

Construire un service web Java EE avec l'ide Netbeans 6.5 et le serveur Java EE Glassfish

Construire un service web Java EE avec l'ide Netbeans 6.5 et le serveur Java EE Glassfish Construire un service web Java EE avec l'ide Netbeans 6.5 et le serveur Java EE Glassfish Serge Tahé, février 009 http://tahe.developpez.com /78 Le texte qui suit fait référence aux documents suivants

Plus en détail

Chapitre 4 La base de données

Chapitre 4 La base de données Chapitre 4 La base de données La Base de données INTRODUCTION 4 La Base de données INTRODUCTION Vectorworks permet de lier les objets du dessin à des formats de base de données (BDD), c'est-à-dire d'associer

Plus en détail

Table des matières. TP JEE (2) Logic metier et Entreprise Java Beans. IUT Bordeaux 1 - Département Informatique

Table des matières. TP JEE (2) Logic metier et Entreprise Java Beans. IUT Bordeaux 1 - Département Informatique IUT Bordeaux 1 - Département Informatique Semestre 4 JEE 20112012 TP JEE (2) Logic metier et Entreprise Java Beans Les EJB (Enterprise JavaBeans) 3.0 permettent de découpler la logique de présentation

Plus en détail

Algorithmique Programmation

Algorithmique Programmation Algorithmique Programmation 2ème partie DUT en alternance CNAM 2007-2008 2 Table des matières 1 Premiers Pas en Programmation Objet : les Classes et les Objets 7 1.1 Définir une Classe........................................

Plus en détail

1.Programmation en Java : notions de base, orienté objet et héritage

1.Programmation en Java : notions de base, orienté objet et héritage Travaux pratique de Méthodologie et Langage de Programmation,, TP1 1 1.Programmation en Java : notions de base, orienté objet et héritage Cette séance de TP a pour objectif d'introduire à la programmation

Plus en détail

SQL pour. Oracle 10g. Razvan Bizoï. Tsoft, Groupe Eyrolles, 2006, ISBN : 2-212-12055-9, ISBN 13 : 978-2-212-12055-4

SQL pour. Oracle 10g. Razvan Bizoï. Tsoft, Groupe Eyrolles, 2006, ISBN : 2-212-12055-9, ISBN 13 : 978-2-212-12055-4 SQL pour Oracle 10g Razvan Bizoï Tsoft, Groupe Eyrolles, 2006, ISBN : 2-212-12055-9, ISBN 13 : 978-2-212-12055-4 Ce guide de formation a pour but de vous permettre d'acquérir une bonne connaissance du

Plus en détail

1/28. I Utiliser à bon escient les types de données proposés par SQL, ou. Introduction 3/28

1/28. I Utiliser à bon escient les types de données proposés par SQL, ou. Introduction 3/28 Introduction 1/28 2/28 Anne-Cécile Caron Licence MIAGE - BDD 2015-2016 Objectifs Après ce cours, les TD et TP correspondants, vous devez être capables de I Créer des tables à partir d un modèle I Utiliser

Plus en détail

Génie logiciel avancé

Génie logiciel avancé Université Paris-Sud L3 MIAGE apprentissage Année 2014-2015 Génie logiciel avancé Conception Delphine Longuet delphine.longuet@lri.fr Documentation du processus de GL Cahier des charges Analyse des besoins

Plus en détail

Conception et Programmation par Objets GLIN404. Langages et paradigmes de programmation

Conception et Programmation par Objets GLIN404. Langages et paradigmes de programmation Conception et Programmation par Objets GLIN404 Marianne Huchard, Clémentine Nebut LIRMM / Université de Montpellier 2 2013 Langages et paradigmes de programmation Le raisonnement classicatoire paradigme

Plus en détail

Introduction aux bases de données

Introduction aux bases de données 1/73 Introduction aux bases de données Formation continue Idir AIT SADOUNE idir.aitsadoune@supelec.fr École Supérieure d Électricité Département Informatique Gif sur Yvette 2012/2013 2/73 Plan 1 Introduction

Plus en détail

Objectifs. Comprendre l architecture typique d une application web Exemple: Expérimenter avec:

Objectifs. Comprendre l architecture typique d une application web Exemple: Expérimenter avec: Cedric Dumoulin Objectifs Comprendre l architecture typique d une application web Exemple: Application permettant de lister un catalogue d articles, et de créer des articles Expérimenter avec: EJB, JPA

Plus en détail

Documentation technique

Documentation technique MEEVY Documentation technique Juillet 200 MEEVY a pour but de fournir aux artistes des outils pour promouvoir leur musique sur internet et proposer à l auditeur une plateforme de musique en ligne gratuite

Plus en détail

Enregistrer un nouvel évènement

Enregistrer un nouvel évènement Maintenant que nous avons géré les utilisateurs, voyons l'enregistrement d'un nouvel évènement créé par l'utilisateur qui sera connecté au client. Là encore, nous utiliserons une couche DAO formée d'une

Plus en détail

Chapitre 3: Modèle relationnel et conception

Chapitre 3: Modèle relationnel et conception LOG660 - Base de données de haute performance Solutions: Chapitre 3: Modèle relationnel et conception QUESTION 1 Plusieurs schémas sont acceptables. Les points à considérer sont: 1. L'agrégation entre

Plus en détail

Chap. 5 : Langage SQL (Structured Query Language) Pr. : Mohamed BASLAM Contact : baslam.med@gmail.com Niveau : S4 BCG Année : 2014/2015 1

Chap. 5 : Langage SQL (Structured Query Language) Pr. : Mohamed BASLAM Contact : baslam.med@gmail.com Niveau : S4 BCG Année : 2014/2015 1 Chap. 5 : Langage SQL (Structured Query Language) Pr. : Mohamed BASLAM Contact : baslam.med@gmail.com Niveau : S4 BCG Année : 2014/2015 1 Plan Généralités Langage de Définition des (LDD) Langage de Manipulation

Plus en détail

TD 15 ème chapitre Bases de données

TD 15 ème chapitre Bases de données TD 15 ème chapitre Bases de données Nous allons travailler dans un premier temps avec le sgbd SQLite qui, à proprement parler, ne s'installe pas vraiment. Les bases de données SQLite tiennent sur un fichier

Plus en détail

GeOxygene : travaux pratiques Exercices pour la version PostGIS version 1.2

GeOxygene : travaux pratiques Exercices pour la version PostGIS version 1.2 Institut Géographique National Laboratoire COGIT GeOxygene : travaux pratiques Exercices pour la version PostGIS version 1.2 28 février 2007 Eric Grosso Résumé : Ce document a pour but de comprendre GeOxygene

Plus en détail

PHP 5. La base de données MySql. A. Belaïd 1

PHP 5. La base de données MySql. A. Belaïd 1 PHP 5 La base de données MySql A. Belaïd 1 Base de données C est quoi une base de données? Une base de données contient une ou plusieurs tables, chaque table ayant un ou plusieurs enregistrements Exemple

Plus en détail

Généralités sur le Langage Java et éléments syntaxiques.

Généralités sur le Langage Java et éléments syntaxiques. Généralités sur le Langage Java et éléments syntaxiques. Généralités sur le Langage Java et éléments syntaxiques....1 Introduction...1 Genéralité sur le langage Java....1 Syntaxe de base du Langage...

Plus en détail

1/ Présentation de SQL Server :

1/ Présentation de SQL Server : Chapitre II I Vue d ensemble de Microsoft SQL Server Chapitre I : Vue d ensemble de Microsoft SQL Server Module: SQL server Semestre 3 Année: 2010/2011 Sommaire 1/ Présentation de SQL Server 2/ Architerture

Plus en détail

Programmation Orientée Objet

Programmation Orientée Objet Programmation Orientée Objet Initiation à Java Saber HENI saber.heni02@univ-paris8.fr http://handiman.univ-paris8.fr/~saber/ Plan du cours Chapitre 1 : Introduction au langage Java Chapitre 2 : Classes

Plus en détail

TP N 4 Création d un projet Web Avec EJB JSF et Glassfish

TP N 4 Création d un projet Web Avec EJB JSF et Glassfish TP N 4 Création d un projet Web Avec EJB JSF et Glassfish I. Les objectifs :... 1 II. L architecture de l atelier... 1 III. Rappel... 1 IV. L environnement de développement... 2 V. Création d un projet

Plus en détail

GRAILS L'ARCHITECTURE GRAILS

GRAILS L'ARCHITECTURE GRAILS GRAILS L'ARCHITECTURE GRAILS Grails est un serveur d'application web basé sur le langage Groovy, et le framework Spring. Il est édité par la société : SpringSource. Une application Grails se décompose

Plus en détail

Le language SQL (2/2)

Le language SQL (2/2) Les commandes de base sous Unix SQL (Première partie) Walter RUDAMETKIN Bureau F011 Walter.Rudametkin@polytech-lille.fr Création d'une base ([] facultatif) : createdb nombase [ -U comptepostgres ] Destruction

Plus en détail

Héritage presque multiple en Java (1/2)

Héritage presque multiple en Java (1/2) Héritage presque multiple en Java (1/2) Utiliser deux classes ou plus dans la définition d'une nouvelle classe peut se faire par composition. class Etudiant{ int numero; Diplome d; float passeexamen(examen

Plus en détail

Optimisations des SGBDR. Étude de cas : MySQL

Optimisations des SGBDR. Étude de cas : MySQL Optimisations des SGBDR Étude de cas : MySQL Introduction Pourquoi optimiser son application? Introduction Pourquoi optimiser son application? 1. Gestion de gros volumes de données 2. Application critique

Plus en détail

Programmation orientée objet en langage JAVA

Programmation orientée objet en langage JAVA Programmation orientée objet en langage JAVA Connexion à une base de données avec JDBC Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon - BP 540 76058 LE HAVRE CEDEX

Plus en détail

S. Laporte C# mode console DAIGL TS1

S. Laporte C# mode console DAIGL TS1 Bases du langage C# I. C# en mode console (mode texte) Avantages par rapport au mode graphique (Application Windows): - C'est un mode plus proche de l'approche algorithmique (pas de notions de composants,

Plus en détail

Conseil, Etudes et Edition de logiciels NORMES & CONVENTIONS DE DEVELOPPEMENT JAVA ET SQL

Conseil, Etudes et Edition de logiciels NORMES & CONVENTIONS DE DEVELOPPEMENT JAVA ET SQL Conseil, Etudes et Edition de logiciels NORMES & CONVENTIONS DE DEVELOPPEMENT JAVA ET SQL Table des matières Système d'exploitation... 3 Environnement de développement intégré... 3 Le workspace... 3 Le

Plus en détail

11. MySQL. Cours Web. MySQL. 11. MySQL. 11. MySQL. Structured Query Language. Lionel Seinturier. Université Pierre & Marie Curie

11. MySQL. Cours Web. MySQL. 11. MySQL. 11. MySQL. Structured Query Language. Lionel Seinturier. Université Pierre & Marie Curie Cours Web Lionel Seinturier Université Pierre & Marie Curie Lionel.Seinturier@lip6.fr Structured Query Language Langage de manipulation des données stockées dans une base de données interrogation/insertion/modification/suppression

Plus en détail

Fonctionnement du serveur Z39.50

Fonctionnement du serveur Z39.50 Fonctionnement du serveur Z39.50 Table des matières 1 Configuration du serveur...2 1.1 Comportement du serveur...2 1.2 Configuration de la traduction z39.50 -> base de données...2 1.3 Configuration du

Plus en détail

Avant de programmer en Java DOS Set Path=C:\JDK\bin Path=C:\JDK\bin C:\JDK\bin Set Path=%Path%;C:\JDK\bin C:\JDK\bin C:\JDK\

Avant de programmer en Java DOS Set Path=C:\JDK\bin Path=C:\JDK\bin C:\JDK\bin Set Path=%Path%;C:\JDK\bin C:\JDK\bin C:\JDK\ Exercices corrigés de programmation OO Java Préparés par : Mlle Imene Sghaier Année Académique : 2006-2007 Premiers Pas I. Avant de programmer en Java Le JDK de Sun (Java Development Kit) est l outil essentiel

Plus en détail

2 Grad Info Soir Langage C++ Juin 2007. Projet BANQUE

2 Grad Info Soir Langage C++ Juin 2007. Projet BANQUE 2 Grad Info Soir Langage C++ Juin 2007 Projet BANQUE 1. Explications L'examen comprend un projet à réaliser à domicile et à documenter : - structure des données, - objets utilisés, - relations de dépendance

Plus en détail

Programmation orientée objet en langage JAVA

Programmation orientée objet en langage JAVA Connexion à une base de données avec JDBC Programmation orientée objet en langage JAVA Connexion à une base de données avec JDBC Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe

Plus en détail

SGBDR et conception d'un système d'information avec MERISE

SGBDR et conception d'un système d'information avec MERISE 1 SGBDR et conception d'un système d'information avec MERISE Séminaires Codes & Travaux @ IRISA 26 Avril 2007 Anthony ASSI Ingénieur Expert R&D Plateforme Bio Informatique / Equipe Symbiose 2 SGBDR : Système

Plus en détail

Arité variable, énumérations. Arité variable. Arité des méthodes. Utilisation de la surcharge

Arité variable, énumérations. Arité variable. Arité des méthodes. Utilisation de la surcharge Arité variable, énumérations Théorie et pratique de la programmation Michel Schinz 2013-05-13 Arité variable 1 2 Arité des méthodes Utilisation de la surcharge Il est parfois utile d'offrir des méthodes

Plus en détail

Instructions SQL. Première partie : Langage de description et de gestion des données

Instructions SQL. Première partie : Langage de description et de gestion des données Instructions SQL Première partie : Langage de description et de gestion des données Quelques instructions et leur syntaxe 1. Introduction Trois principales catégories d instructions. Instructions de création

Plus en détail

CRÉER UNE BASE DE DONNÉES AVEC OPEN OFFICE BASE

CRÉER UNE BASE DE DONNÉES AVEC OPEN OFFICE BASE CRÉER UNE BASE DE DONNÉES AVEC OPEN OFFICE BASE 2 ème partie : REQUÊTES Sommaire 1. Les REQUÊTES...2 1.1 Créer une requête simple...2 1.1.1 Requête de création de listage ouvrages...2 1.1.2 Procédure de

Plus en détail

Cours 1 : Introduction Générale + Objet I

Cours 1 : Introduction Générale + Objet I Organisation du cours Équipe pédagogique DUT Informatique S3 - Programmation Java Jean-Claude MARTIN MARTIN@LIMSI.FR Cours 1 : Introduction Générale + Objet I Jean-Claude MARTIN (Responsable, Cours, TD

Plus en détail

Mémento Site Dynamique / PHP

Mémento Site Dynamique / PHP Mémento Site Dynamique / PHP Pour faire fonctionner site statique : Navigateur Éditeur de texte Apache/PHP/MySQL (qu'on peut retrouver dans WampServer (uniquement Windows)) Inclure les portions de page

Plus en détail

Le Langage De Description De Données(LDD)

Le Langage De Description De Données(LDD) Base de données Le Langage De Description De Données(LDD) Créer des tables Décrire les différents types de données utilisables pour les définitions de colonne Modifier la définition des tables Supprimer,

Plus en détail

Introduction au langage SQL

Introduction au langage SQL Introduction au langage SQL 1. Description SQL est un acronyme pour Structured Query Language qui a été conçu par IBM, et a succédé au langage SEQUEL. C est maintenant le langage le plus utilisé dans les

Plus en détail

SQL (Première partie) Walter RUDAMETKIN

SQL (Première partie) Walter RUDAMETKIN SQL (Première partie) Walter RUDAMETKIN Bureau F011 Walter.Rudametkin@polytech-lille.fr Les commandes de base sous Unix Création d'une base ([] facultatif) : createdb nombase [ -U comptepostgres ] Destruction

Plus en détail

Cours: Administration d'une Base de Données

Cours: Administration d'une Base de Données Bases de Données Avancées Module A IUT Lumière, License CE-STAT 2006-2007 Pierre Parrend Cours: Administration d'une Base de Données Table of Contents Principes...1 Structure d'un Base de Données...1 Architecture...1

Plus en détail

JDBC et objet-relationnel

JDBC et objet-relationnel Types de données de SQL3 JDBC et objet-relationnel Université de Nice - Sophia Antipolis Version 1.6.4 5/11/11 Richard Grin JDBC supporte les types suivants de SQL3 qui sont des ouvertures vers le relationnelobjet

Plus en détail

Le langage SQL pour Oracle - partie 1 : SQL comme LDD

Le langage SQL pour Oracle - partie 1 : SQL comme LDD Le langage SQL pour Oracle - partie 1 : SQL comme LDD 1 SQL : Introduction SQL : Structured Query Langage langage de gestion de bases de donn ees relationnelles pour Définir les données (LDD) interroger

Plus en détail

Langage SQL : créer et interroger une base

Langage SQL : créer et interroger une base Langage SQL : créer et interroger une base Dans ce chapitre, nous revenons sur les principales requêtes de création de table et d accès aux données. Nous verrons aussi quelques fonctions d agrégation (MAX,

Plus en détail

TP SPRING. https ://lipn.univ-paris13.fr/ fortier/enseignement/spring/tp/

TP SPRING. https ://lipn.univ-paris13.fr/ fortier/enseignement/spring/tp/ Institut Galilée Année 2015-2016 TP SPRING Programmation et Logiciels sûrs Master 2 PLS Résumé L objectif de ce TP est d être capable de réaliser une application Java de gestion de location de véhicules,voiture

Plus en détail

Traitement et navigation

Traitement et navigation 12 Traitement et navigation Au chapitre précédent, nous avons vu comment créer des pages web avec différentes technologies (HTML, JSP, JSTL, etc.) en insistant sur le fait que JSF est la spécification

Plus en détail

NF26 Data warehouse et Outils Décisionnels Printemps 2010

NF26 Data warehouse et Outils Décisionnels Printemps 2010 NF26 Data warehouse et Outils Décisionnels Printemps 2010 Rapport Modélisation Datamart VU Xuan Truong LAURENS Francis Analyse des données Avant de proposer un modèle dimensionnel, une analyse exhaustive

Plus en détail

Chapitre 1 : Introduction aux bases de données

Chapitre 1 : Introduction aux bases de données Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données

Plus en détail

TD BD dynamique. DECLARE déclaration des variables, constantes, exceptions et curseurs locaux au bloc

TD BD dynamique. DECLARE déclaration des variables, constantes, exceptions et curseurs locaux au bloc TD BD dynamique Un déclencheur est utilisé pour complémenter les contraintes d'intégrité de la base. Une partie des contraintes ne peut souvent pas être définie avec les fonctionnalités décrites jusqu'ici.

Plus en détail

La persistance des données dans les applications : DAO, JPA, Hibernate... COMPIL 2010 francois.jannin@inp-toulouse.fr 1

La persistance des données dans les applications : DAO, JPA, Hibernate... COMPIL 2010 francois.jannin@inp-toulouse.fr 1 La persistance des données dans les applications : DAO, JPA, Hibernate... COMPIL 2010 francois.jannin@inp-toulouse.fr 1 Plan 1. Généralités sur la persistance des données dans les applications 2. La connection

Plus en détail

Introduction aux Systemes d Information et aux Bases de Données

Introduction aux Systemes d Information et aux Bases de Données Introduction aux Systemes d Information et aux Bases de Données L2 Informatique Serenella Cerrito Département d Informatique Évry 2014-2015 Quels valeurs peut prendre un attribut? Ici, les types les plus

Plus en détail

1. Introduction... 2. 2. Création d'une macro autonome... 2. 3. Exécuter la macro pas à pas... 5. 4. Modifier une macro... 5

1. Introduction... 2. 2. Création d'une macro autonome... 2. 3. Exécuter la macro pas à pas... 5. 4. Modifier une macro... 5 1. Introduction... 2 2. Création d'une macro autonome... 2 3. Exécuter la macro pas à pas... 5 4. Modifier une macro... 5 5. Création d'une macro associée à un formulaire... 6 6. Exécuter des actions en

Plus en détail

Mise à niveau en Java

Mise à niveau en Java Mise à niveau en Java Cours 1 Stéphane Airiau Université Paris-Dauphine Stéphane Airiau (Université Paris-Dauphine) - Java Cours 1 1 Aujourd hui Eléments de base Variables, opérateurs, type d une expression

Plus en détail

TP3 : Ajout d'un modèle. Ajouter des Classes de modèle. 1- L approche Code First

TP3 : Ajout d'un modèle. Ajouter des Classes de modèle. 1- L approche Code First TP3 : Ajout d'un modèle 1- L approche Code First Dans cette section, vous ajouterez quelques classes pour gérer les films dans une base de données. Ces classes vont constituer la partie «modèle» de l'application

Plus en détail

Procédures Stockées WAVESOFT... 12 ws_sp_getidtable... 12. Exemple :... 12. ws_sp_getnextsouche... 12. Exemple :... 12

Procédures Stockées WAVESOFT... 12 ws_sp_getidtable... 12. Exemple :... 12. ws_sp_getnextsouche... 12. Exemple :... 12 Table des matières Les Triggers... 2 Syntaxe... 2 Explications... 2 Les évènements déclencheurs des triggers... 3 Les modes de comportements des triggers... 4 Les pseudo tables... 5 Exemple... 6 Les procédures

Plus en détail

L héritage Encore un petit topo des familles. Je pense qu'avec ce genre de chapitre, ce n'est pas du luxe...

L héritage Encore un petit topo des familles. Je pense qu'avec ce genre de chapitre, ce n'est pas du luxe... L héritage Encore un petit topo des familles. Je pense qu'avec ce genre de chapitre, ce n'est pas du luxe... Une classe hérite d'une autre classe par le biais du mot clé extends. Une classe ne peut hériter

Plus en détail

1 Partie A : administration d une base de donnée à travers PhpMyAdmin

1 Partie A : administration d une base de donnée à travers PhpMyAdmin Ce TP se compose en 2 sections : une section de prise en main (sur ordinateur) et une section d exercice (sur papier) concernant l algèbre relationnelle. 1 Partie A : administration d une base de donnée

Plus en détail

Rapport Gestion de projet

Rapport Gestion de projet IN56 Printemps 2008 Rapport Gestion de projet Binôme : Alexandre HAFFNER Nicolas MONNERET Enseignant : Nathanaël COTTIN Sommaire Description du projet... 2 Fonctionnalités... 2 Navigation... 4 Description

Plus en détail

Création d une application JEE

Création d une application JEE Création d une application JEE Rédacteurs : Alexandre Baillif, Philippe Lacomme, Raksmey Phan et Michaël PLAN Date : juillet 2010 Mise à jour : Michaël PLAN Date : octobre 2014 Avertissement : - ce document

Plus en détail

T.P. 3 Base de données, JDBC et Mapping Objet-relationnel

T.P. 3 Base de données, JDBC et Mapping Objet-relationnel EPITA Ala Eddine BEN SALEM App-Ing2 J2EE T.P. 3 Base de données, JDBC et Mapping Objet-relationnel L'objectif de ce TP est de vous faire pratiquer l'api JDBC qui permet d'accéder à une base de données

Plus en détail

Pour les débutants. langage de manipulation des données

Pour les débutants. langage de manipulation des données Pour les débutants SQL : langage de manipulation des données Les bases de données sont très utilisées dans les applications Web. La création, l interrogation et la manipulation des données de la base sont

Plus en détail

Université Laval Faculté des sciences et de génie Département d'informatique et de génie logiciel IFT-3101. Travail pratique #2

Université Laval Faculté des sciences et de génie Département d'informatique et de génie logiciel IFT-3101. Travail pratique #2 Université Laval Faculté des sciences et de génie Département d'informatique et de génie logiciel IFT-3101 Danny Dubé Hiver 2014 Version : 11 avril Questions Travail pratique #2 Traduction orientée-syntaxe

Plus en détail

Spécialisation / généralisation évolutive

Spécialisation / généralisation évolutive Spécialisation / généralisation évolutive Comparaison de complexité avec une solution statique conventionnelle Créé: Juin 2005 Rédigé : Léonard Sandoz Modifié: Dirigé : Pierre-André Sunier Laboratoire

Plus en détail

Refonte front-office / back-office - Architecture & Conception -

Refonte front-office / back-office - Architecture & Conception - Refonte front-office / back-office - Architecture & Conception - GLG204 - Architectures Logicielles Java 2008/2009 Nom : Cédric Poisson Matricule : 06-49012 Version : 1.0 Jeudi 28 mai 2009 1 / 23 Table

Plus en détail

Cours 3 Le langage SQL

Cours 3 Le langage SQL DUT SRC IUT de Marne-la-Vallée 05/02/2014 M2203 Bases de données Cours 3 Le langage SQL Philippe Gambette Sources Cours de Tony Grandame à l'iut de Marne-la-Vallée en 2010-2011 Cours de Mathieu Mangeot,

Plus en détail

Programmation objet. Objectifs - maitriser le paradigme de Programmation Orientée Objet - savoir utiliser efficacement et pleinement le langage Java

Programmation objet. Objectifs - maitriser le paradigme de Programmation Orientée Objet - savoir utiliser efficacement et pleinement le langage Java Programmation objet Objectifs - maitriser le paradigme de Programmation Orientée Objet - savoir utiliser efficacement et pleinement le langage Java - notions de bases d'algorithmique - bases syntaxiques

Plus en détail

Les procédures stockées et les fonctions utilisateur

Les procédures stockées et les fonctions utilisateur Les procédures stockées et les fonctions utilisateur Z Grégory CASANOVA 2 Les procédures stockées et les fonctions utilisateur [08/07/09] Sommaire 1 Introduction... 3 2 Pré-requis... 4 3 Les procédures

Plus en détail

2011 Hakim Benameurlaine 1

2011 Hakim Benameurlaine 1 Table des matières 1 CRÉATION DES OBJETS DE BASES DE DONNÉES... 2 1.1 Architecture d une base de données... 2 1.1.1 Niveau logique... 2 1.1.2 Niveau physique... 3 1.2 Gestion d une base de données... 3

Plus en détail

TP J2EE GUIDE DE DEPLOIEMENT DE L APPLICATION WEB DE GESTION DES COMPTES

TP J2EE GUIDE DE DEPLOIEMENT DE L APPLICATION WEB DE GESTION DES COMPTES 2008 UFR Ingénieurs 2000 Vivien Boistuaud Julien Herr TP J2EE GUIDE DE DEPLOIEMENT DE L APPLICATION WEB DE GESTION DES COMPTES Ce document a été réalisé par V. Boistuaud et J. Herr dans le cadre des travaux

Plus en détail

Chapitre 2. Classes et objets

Chapitre 2. Classes et objets Chapitre 2: Classes et Objets 1/10 Chapitre 2 Classes et objets Chapitre 2: Classes et Objets 2/10 Approche Orientée Objet Idée de base de A.O.O. repose sur l'observation de la façon dont nous procédons

Plus en détail

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base)

Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) Chapitre 1 : Introduction aux Systèmes de Gestion de Bases de Données (Eléments de base) 1. Généralités sur l'information et sur sa Représentation 1.1 Informations et données : a. Au sen de la vie : C

Plus en détail

Informatique / Programmation

Informatique / Programmation Informatique / Programmation Programmation orientée objet avec Java 07 : Chaînes de caractères Jacques Bapst jacques.bapst@hefr.ch Chaînes de caractères (String) En Java les chaînes de caractères sont

Plus en détail

Java - Historique. Une introduction à Java. Premier exemple. Aperçu de Java. Processus d obtention d un exécutable. Compilation/interprétation

Java - Historique. Une introduction à Java. Premier exemple. Aperçu de Java. Processus d obtention d un exécutable. Compilation/interprétation Java - Historique Une introduction à Java IFT 287 (Semaine 1) UNIVERSITÉ DE SHERBROOKE 1 Développé par Sun Microsystems en 1994 Inventeur James Gosling (canadien!) Objectif langage sûr (fortement typé)

Plus en détail