Disseny de la persistència Introducció i mapping objecte/relacional

1. Disseny de la persistència Introducció i mapping objecte/relacional Toni Navarrete Enginyeria del Software II – UPF 2004

2. Continguts • Objectiu: com fer per guardar les dades dels objectes (els seus atributs) de forma persistent, típicament a una BDR? Com després els objectes accedeixen a les dades guardades? • Conversió (mapping) de model de classes (model estàtic UML) a model relacional • Formes per gestionar la persistència en Java • Serialization • Amb un middleware: JDBC • A la pròpia classe, o a una classe de connexió per a cada classe de domini, o bé a una classe DBManager? • Utilitzant EJB, una plataforma més genèrica estandaritzada per Sun al J2EE, i en concret els ejbs d’entitat • Amb un framework de persistència: JDO

3. Conversió del model de classes a relacional • Durant el disseny construim un model de classes • Les dades es guarden a una BDR • Quin haurà de ser el model relacional corresponent al nostre model de classes? • En principi, un objecte es correspon amb una fila d’una taula

4. Conversió del model de classes a relacionalAtributs a columnes • Els atributs d’una classe passen a ser 0 o més columnes d’una taula • El cas habitual: 1 atribut d’un tipus primari o String passa a ser una columna • 0 perquè hi ha atributs no persistents. Ex: total d’una factura • En Java es marquen com transient • Més d’1 perquè els atributs que no siguin primaris o Strings passaran (recursivament) a formar vàries columnes (de vàries taules) • És freqüent que s’utilitzi l’OID (nombre enter) dels objectes com a primary key de les taules

5. Conversió del model de classes a relacionalEquivalència tipus Java a columnes BDR

6. Conversió del model de classes a relacionalClasses a taules • En general una classe passa a ser una taula • Després veurem què passa amb les associacions i agregacions (passen a ser relacions) • Hi ha situacions en què un objecte pot passar a ser un atribut • Exemple codi postal • Classe CodiPostal té un atribut codi i un mètode validar • La classe Empresa té un atribut codiPostal, instància de CodiPostal • En relacional, codiPostal serà una columna de la taula Empresa • Herència

7. Conversió del model de classes a relacional: Classes a taules: herència • Cap problema amb gestor de BDOO, però sí amb BDR • 3 solucions • Exemple: Classe abstracta

8. Conversió del model de classes a relacional: Classes a taules: herència (solució 1) • Solució 1 • Una única taula per tota la jerarquia amb tots els atributs de totes les classes • Els camps no usats es posen a null • Es pot afegir un camp que indiqui el tipus (la subclasse) • Característiques • La forma més simple • Suporta que una persona tingui més d’un rol i és fàcil fer un canvi de rol • Totes les dades d’una persona estan en una única taula • Molt ineficient quant a espai • Molt dolent si molts atributs específics • Molt acoblat: un canvi en un atribut d’una subclasse afecta a tot el conjunt • Fer un llistat de tots els alumnes és més lent que en els altres esquemes, ja que hi ha més files a la taula Taules: Persona (ID,nom,dni,data_naixement,nia,nSS)

9. Conversió del model de classes a relacional: Classes a taules: herència (solució 2) • Solució 2 • Definir una taula per cada classe no abstracta, que contindrà tant els atributs propis com els de la superclasse • Característiques • Continuen estant totes les dades d’una persona en una mateixa taula • Llistats per rol (d’alumnes o de professors) eficients • Si modifiquem un atribut de la superclasse, l’hem de modificar a moltes taules. Per exemple afegir telèfon a Persona • És difícil manegar canvis de rol (calen dades repetides) i també rols múltiples Taules si Persona no fos abstracta: Persona (ID,nom,dni,data_naixement) Estudiant (ID,nom,dni,data_naixement,nia) Professor (ID,nom,dni,data_naixement,nSS) Taules: Estudiant (ID,nom,dni,data_naixement,nia) Professor (ID,nom,dni,data_naixement,nSS)

10. Conversió del model de classes a relacional: Classes a taules: herència (solució 3) • Solució 3 • Definir una taula per cada classe (tant subclasses com superclasses) • Cada taula contindrà només els atributs propis de la classe i estarà relacionada amb la superclasse • Característiques: • És la que millor s’acosta al model OO (gens acoblat) • Les dades d’una persona estan repartides a més d’una taula, amb la qual cosa les lectures/escriptures són més lentes • Suporta bé els múltiples rols i els canvis de rol • Millor amb vistes 0..1 Estudiant Taules: Persona (ID,nom,dni,data_naixement) Estudiant (ID_persona -FK-,nia) Professor (ID_persona -FK-,nSS) 1 Persona 1 Professor 0..1

11. Conversió del model de classes a relacionalClasses a taules: herència (resum)

12. Conversió del model de classes a relacionalRelacions • Les associacions i agregacions es converteixen en relacions • La diferència entre associació i agregació és més bé de la capa de domini que de la de dades • No hi ha distinció en relacional • Les relacions es basen en mantenir foreign keys • Per implementar una relació 1-1 o 1-N, simplement cal afegir la clau d’una taula en l’altra com a FK • En cas de relacions N-M, cal trencarla, utilitzant una taula intermitja, en dos relacions 1-N

13. Conversió del model de classes a relacionalRelacions (exemples) 1 N A B Taules: A (idA,...) B (idB,...,idA -FK-) Taules: A (idA,...) B (idB,...) AB(idA -FK-,idB -FK-,...) 1 N N 1 A AB B

14. Una reflexió • No sempre els mètodes de desenvolupament conduïts per casos d’ús (use-case driven) són els més adequats • També hi ha els mètodes conduïts per la informació (information-driven) • S’ajusten més a aplicacions molt centrades en la BDR • La part central no és el model de classes sinó el relacional • No són realment OO (són procedimentals)