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

Presentación del tema: "Disseny de la persistència Introducció i mapping objecte/relacional"— Transcripción de la presentación:

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

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

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 relacional Atributs 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 relacional Equivalència tipus Java a columnes BDR
Tipus columna BDR Boolean, boolean bit, tinyint, smallint, byte, int2 Byte, byte tinyint, smallint, byte, int2 Character, char integer, char, varchar Short, short smallint,integer, number, int2 Integer, int integer, number, int4 Long, long bigint, decimal, int8 Float, float float, decimal, real Double, double double, number, decimal BigInteger decimal, number, bigint BidDecimal decimal, number,double String char, varchar, varchar2, longvarchar, clob Date timestamp, date, datetime

6 Conversió del model de classes a relacional Classes 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 Cap problema amb gestor de BDOO, però sí amb BDR 3 solucions Exemple:
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)
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)
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 i també rols múltiples (calen dades repetides) 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)
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 relacional Classes a taules: herència (resum)
Factor Una única taula Una taula per classe concreta Una taula per classe Acoblament Alt Mitjà Baix Facilitat d’implementació Fàcil Difícil Ús d’espai Dolent Bo Capacitat per múltiples rols i canvis de rol Mitjana Baixa Alta Llistat per un rol concret Lent Ràpid Accés a les dades d’una persona Llistat complet (tots els rols)

12 Conversió del model de classes a relacional Relacions
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 trencar-la, utilitzant una taula intermitja, en dues relacions 1-N

13 Conversió del model de classes a relacional Relacions (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)