disseny de la persistència introducció i mapping objecte/relacional
DESCRIPTION
Disseny de la persistència Introducció i mapping objecte/relacional. Toni Navarrete Enginyeria del Software II – UPF 2003. Continguts. Objectiu: com fer per guardar les dades de forma persistent, típicament a una BDR? - PowerPoint PPT PresentationTRANSCRIPT
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Disseny de la persistènciaIntroducció i mapping objecte/relacional
Toni Navarrete
Enginyeria del Software II – UPF 2003
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 2 Continguts• Objectiu: com fer per guardar les dades de
forma persistent, típicament a una BDR?• 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
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 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
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 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
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 5
Conversió del model de classes a relacionalEquivalència tipus Java a columnes BDR
Tipus Java 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
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 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
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 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:-nom-dni-data_naixement
Persona
-nia
Estudiant
-nSS
Professor
Classe abstracta
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 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 (OID,nom,dni,data_naixement,nia,nSS)
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 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:Estudiant (OID,nom,dni,data_naixement,nia)
Professor (OID,nom,dni,data_naixement,nSS)
Taules si Persona no fos abstracta:Persona (OID,nom,dni,data_naixement)
Estudiant (OID,nom,dni,data_naixement,nia)
Professor (OID,nom,dni,data_naixement,nSS)
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 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
Taules:Persona (OID,nom,dni,data_naixement)
Estudiant (IDpersona -FK-,nia)
Professor (IDpersona -FK-,nSS)
Persona
Professor
Estudiant1
1
0..1
0..1
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 11
Conversió del model de classes a relacionalClasses 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 Mitjà Difícil
Accés a les dades d’una persona
Ràpid Ràpid Mitjà
Capacitat per múltiples rols i canvis de rol
Mitjana Baixa Alta
Llistat per rol Mitjà Ràpid Depén
Ús d’espai Dolent Mitjà Bo
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 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
• 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
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 13
Conversió del model de classes a relacionalRelacions (exemples)
A B
1..1 1..*
A B
1..* 1..*
Taules:
A (idA,...)
B (idB,...,idA -FK-)
Taules:
A (idA,...)
B (idB,...)
AB(idA -FK-,idB -FK-,...)
A B1 N
A AB1 N
BN 1
En
gin
yeri
a d
el S
W II
: Dis
sen
y d
e la
pe
rsis
tèn
cia
Pàgina 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)