125 lines
2.9 KiB
Plaintext
125 lines
2.9 KiB
Plaintext
Vendredi 20 février 2009
|
|
A63 Persistance de données
|
|
M. LACHICHE
|
|
|
|
====== Cours ======
|
|
|
|
===== Shadow information =====
|
|
|
|
Toplink permet d'épargner toute l'instrumentation des attributs d'un objet pour renseigner son état d'insertion, de mise à jour, etc dans la base de données.
|
|
|
|
===== Mapping de l'héritage =====
|
|
|
|
Les BDD relationnel ne prennent pas en compte l'héritage => pas une raison pour éviter l'héritage.
|
|
|
|
Classe abstraite = classe qui ne peut pas avoir d'instance (abstract en java)
|
|
|
|
Personne est une classe abstraite.
|
|
|
|
Pour //mapper// l'héritage on a 4 solutions :
|
|
* Tout mettre dans une table
|
|
* Faire une table par classe concrète
|
|
* Faire une table par classe, y compris les abstraites
|
|
* Représenter les classes par une structure de classe générique
|
|
|
|
Les 3 premières solutions sont gérées par TopLink.
|
|
|
|
====== Exercice ======
|
|
|
|
On a une couche métier avec des Oiseaux, des Lézards, des Dragons.
|
|
|
|
Le dragon hérite du lézard et de l'oiseau.
|
|
|
|
L'oiseau possède les attributs suivants :
|
|
* vitesseMaximal
|
|
* tailleAiles
|
|
|
|
Le lézard possède les attributs suivants :
|
|
* nombreGriffes
|
|
* nombreCouleurs
|
|
|
|
Le dragon possède les attributs suivants :
|
|
* nom
|
|
* puissanceFeu
|
|
|
|
Intitulé de l'exercice : Adapter ce modèle métier aux 4 modèles de base de données expliqués dans le cours.
|
|
|
|
===== Corrigé =====
|
|
|
|
==== Solution 1 ====
|
|
|
|
On doit créer une table : ANIMAL.
|
|
|
|
Attributs :
|
|
* identifiant
|
|
* typeAnimal
|
|
* nombreGriffe
|
|
* nombreCouleur
|
|
* tailleAiles
|
|
* vitesseMaximale
|
|
* nom
|
|
* puissanceFeu
|
|
|
|
==== Solution 2 ====
|
|
|
|
Trois tables :
|
|
* Oiseau
|
|
* Lézard
|
|
* Dragon
|
|
|
|
Attributs pour Oiseau :
|
|
* id
|
|
* vitesseMaximale
|
|
* tailleAiles
|
|
|
|
Attributs pour Lézards :
|
|
* identifiant
|
|
* nombreGriffes
|
|
* nombreCouleurs
|
|
|
|
Attributs pour Dragons :
|
|
* identifiant
|
|
* vitesseMaximal
|
|
* tailleAiles
|
|
* nombreGriffes
|
|
* nombreCouleurs
|
|
* puissanceFeu
|
|
* nom
|
|
|
|
==== Solution 3 ====
|
|
|
|
Trois tables :
|
|
* Oiseau
|
|
* Lézard
|
|
* Dragon
|
|
|
|
Avec chacune leur propres attributs (pas de redondance d'attributs dans Dragon.
|
|
|
|
Plusieurs solutions :
|
|
* soit on met idAnimal partagé par tout le monde, comme avant
|
|
* soit on adapte : on met idOiseau et idLézard en clé primaire pour dragon, et idOiseau et idLézard dans leur table respective
|
|
|
|
==== Solution 4 ====
|
|
|
|
On reprend le même modèle que dans le cours.
|
|
|
|
On remplit alors les classes, voilà tout.
|
|
|
|
----
|
|
|
|
Séance 3
|
|
|
|
====== Mapping des associations ======
|
|
|
|
Dans les SGBD, relation voulait dire association des domaines de la table.
|
|
|
|
Cependant, cela est actuellement utilisé pour des relations entres les tables.
|
|
|
|
Clés artificielles pour être indépendant du domaine d'application : si on a besoin de deux objets identiques mais différents pour nous (exemple : code barre des produits)
|
|
|
|
====== Mapping des propriétés de classe ======
|
|
|
|
Ne peuvent pas être géré comme des attributs ordinaires car sont là pour UNE classe pas pour ses instances si on veut.
|
|
|
|
|