Mapping OO ontwerp naar DB Optimaliseren van DB ontwerp (normalisatie, indexeren, enz) H10: Persistentie MSO, 2 e deel: Ontwikkeling.

Presentatie over: "Mapping OO ontwerp naar DB Optimaliseren van DB ontwerp (normalisatie, indexeren, enz) H10: Persistentie MSO, 2 e deel: Ontwikkeling."— Transcript van de presentatie:

1 Mapping OO ontwerp naar DB Optimaliseren van DB ontwerp (normalisatie, indexeren, enz) H10: Persistentie MSO, 2 e deel: Ontwikkeling

2 Persistentie Org. term: “persistence”, to pesist  te blijven bestaan. Een applicatie kan ineens crashen (bugs, stroom uitval, enz). Je wil je data redden! Persistentie  onderdeel van je applicatie die data op een permanente medium opslaat. Files Database 2

3 Hoe belangrijk ? Erg belangrijk  in een bedrijfsapplicatie zijn data vaak erg waardevol. Omdat je app kan op ieder moment crashen, in de praktijk wordt data vaak na iedere “save/submit” van de klant ook direct in de db opgeslagen. 3

4 Uitdaging 4 Betrouwbaar geen data verlies of stuk backup, rollback Prestatie (performance)  snel je data te kunnen querien / updaten Concurrentie  apps met meerdere cliënten zijn nu gewoon.

5 Concurrentie  ACID transacties 5 “Atomic”  een transactie wordt nooit half uitgevoerd (volledig of helemaal niet). “Consistent”  een transactie die de DB’s constraints zou breken wordt geweigerd. “ge-Isoleerd”  tussen toestanden van een transactie zijn niet door andere transacties zichtbaar. “Durabel”  als een transactie voltooit, effect op DB is persistent.

6 File vs DB 6 File goedkoop minder boilerplate je zou rollback, query, concurrentie, enz zelf moeten programmeren (voor zover nodig) geschikt voor kleine apps DB  andersom

7 Relationeel DB 7 Meest gebruikte DB  relationeel  bewezen technologie. In wiskunde, een relatie R : A×B×C is een verzameling van tupels uit A×B×C zoals: { (a 1,b 1,c 1 ), (a 2,b 2,c 2 ) } Een tabel is een relatie: ABC a1a1 b1b1 c1c1 a2a2 b2b2 c2c2

8 Typische architectuur 8 Presentatie (User Interface) laag Bedrijfslogica (Probleemdomein /PD ) laag Persistentie (Data Access Management / DAM) laag Persistentie (Data Access Management / DAM) laag DB Klant Product * bestelt OrderNrKlantIDNaamStaatTax 2391035BlackMD0.05 2411123WilliamCA0.08 2901123WilliamCA0.08 2372242BerryDC0.06 2342242BerryDC0.06 save, load, query

9 Impendance mismatch… 9 Je ontwerpt met UML, en implementeert in een OO taal. Echter, de meeste DB technologieën zijn relationeel. Data zijn in tabellen georganiseerd. Geen direct ondersteuning voor het opslaan van objecten. Oplossing ? Zelf de mapping implementeren ?  veel werk! Object-relationele DB OO DB Mapping frameworks

10 Entity Relationship (ER) Diagram 10 Klant ID {PK} Naam Leeftijd Klant ID {PK} Naam Leeftijd Product ID {PK} Naam Prijs Product ID {PK} Naam Prijs * bestelt IDNaamLeeftijd 10Bob6 11Patrick7 Klant IDNaamPrijs 1Appel10 2Peer15 Product KlantIDProdID 101 111 2 Bestelling

11 ERD en klasse diagram 11 Klant Naam Leeftijd Klant Naam Leeftijd Product Naam Prijs Product Naam Prijs * bestelt Klant ID {PK} Naam Leeftijd Klant ID {PK} Naam Leeftijd Product ID {PK} Naam Prijs Product ID {PK} Naam Prijs * bestelt Impliciet ID Navigatie Expliciet PK Geen concept van navigatie

12 ERD en klasse diagram 12 Auto Bouwjaar Auto Bouwjaar Product Naam Prijs Product Naam Prijs Auto ID {PK} Bouwjaar Auto ID {PK} Bouwjaar Product ID {PK} Naam Prijs Product ID {PK} Naam Prijs 0..1 is extensie van traditioneel ERD kent geen inheritence. Auto Naam = “Toyota” Prijs = 2000 € Bouwjaar = 2000 1 IDNaamPrijs 1Appel10 2Totoya2000 3Toyota5000 Product IDBouwjaar 2002000 2102004 AutoIDProdID 2002 2103 Auto_Product Auto

13 Nog meer vraagstukken… 13 Persoon Naam = “Bob” Leeftijd = 6 IDNaamLeeftijd 10Bob6 11Octo7 Persoon Naam = “Octo” Leeftijd = 7 Vrienden Persoon Hoe sla je een complexe object “Octo” op in tabellen ? Hoe haal je het terug? Navigatie door objecten vs relationele query. Hoe zit het met object encapsulatie? Hoe sla je een complexe object “Octo” op in tabellen ? Hoe haal je het terug? Navigatie door objecten vs relationele query. Hoe zit het met object encapsulatie?

14 Zelf doen… 14 Persoon Naam Persoon Naam heeft vrienden * Persoon Naam = “Octo” Vrienden Persoon PersoonDAO find(id) : Persoon insert(persoon) getVrienden(id) : Collection DB *

15 Zelf doen… 15 Persoon Naam = “Octo” Vrienden Persoon PersoonDAO find(id) : Student insert(persoon) getVrienden(id) : Collection DB find(id) { qry = “select * from PERSOON where ID = ” + id result = connection.executeQry(qry) return new Persoon(result.getString(“Naam”)) } find(id) { qry = “select * from PERSOON where ID = ” + id result = connection.executeQry(qry) return new Persoon(result.getString(“Naam”)) } geef een plat object terug! Navigatie nu indirect via deze.

16 Object-Relationele DB / ORDB 16 CREATE TYPE Klant UNDER Persoon ( lidnr INT ) CREATE TYPE Klant UNDER Persoon ( lidnr INT ) CREATE TYPE Persoon AS OBJECT ( Naam CHAR(20) Vrienden SET (REF Persoon) ) CREATE TYPE Persoon AS OBJECT ( Naam CHAR(20) Vrienden SET (REF Persoon) ) CREATE TABLE PERSOON OF TYPE Persoon INSERT INTO PERSOON VALUES (Klant (“Bob", 123, 10)) SELECT p.Vrienden FROM Persoon p WHERE p.Naam = “Bob

17 Object-Relationele DB / ORDB Relationele DB, uitgebreid met OO concepten: User Defined Type  class Inheritence REF  object ID Ingebouwde navigatie  auto.eigenaar.vrienden SET (van REFs)  to represent navigable OO one-to- many Zoals in SQL 1999 Producten: Oracle, PostgreSQL Niet native in bijvb. Java. Je zou je DAO nog steeds zelf moeten bouwen…maar minder ingewikkeld. 17

18 Java Persistence Architecture / JPA javax.jpa, implementatie: Apache OpenJPA Entity manager  gratis DAO Je moet nog een “mapping” specificeren… 18 EntityManager em = get … em.getTransaction().begin() em.find(Persoon.class, 20) em.persist(bob) em.getTransaction().commit() EntityManager em = get … em.getTransaction().begin() em.find(Persoon.class, 20) em.persist(bob) em.getTransaction().commit()

19 Object-Relationeel Mapping /ORM In welke tabel sla je objecten van klasse C op ? In welke kolommen sla je de attributen van je object? 19 @Entity @Table(name=“PERSOON”) class Persoon { @Id @Column(name=“ID”) private int id @Column(name=“NAAM”) private String naam @ManyToMany private Collection vrienden …. @Entity @Table(name=“PERSOON”) class Persoon { @Id @Column(name=“ID”) private int id @Column(name=“NAAM”) private String naam @ManyToMany private Collection vrienden …. getId() { return id } getNaam() { return naam } getVrienden() { return vrienden } getId() { return id } getNaam() { return naam } getVrienden() { return vrienden } @JoinTable( ….)

20 ORM … Je moet ook nog een persistence descriptor maken. In een XML bestand, specificeer: Waar is je implementatie van EntityManager? Waar is de DB, hoe maak je verbinding met DB? Welke klassen neem je mee in de O/R mapping? Nog steeds gedoe, maar je hebt nu veel minder boiler plate… Vergelijkbaar technologie: ‘ORM framework’ zoals Hibernate. 20

21 OO DB Zoals DB4O Er is geen relationele mapping Objecten zijn ‘direct’opgeslagen. 21 Persoon Naam = “Octo” Vrienden Persoon IDNaamPrijs 1Appel10 2Peer15 IDNaamLeeftijd 10Bob6 11Patrick7

22 OO DB Code is schoner : OODB of RDB? Coding overhead is belangrijk, maar er zit nog meer … -  later. 22 db = Db4o.openFile(“MijnOODB”) db.get(new Persoon(0,”Bob”)) db.set(octo) List result = db.query( …. p.leeftijd >= 5) db.close() db = Db4o.openFile(“MijnOODB”) db.get(new Persoon(0,”Bob”)) db.set(octo) List result = db.query( …. p.leeftijd >= 5) db.close() native query in Java … goed of slecht ?

23 Terug: OODB of RDB ? Medische historie van een persoon  wat willen we zien? Adres, lijst van klachten, lijst van voorgeschreven medicijnen. lijst of tabel achtige informatie  makkelijk met een joint op RDB. Je wil een rijke structuur  OO, of ORDB 23 historie klacht arts aantekening medicijn

24 OODB of RDB ? Recursieve navigatie … Je moet complexe objecten persisten, je doet veel navigatie  OODB is beter en sneller. Platte objecten, je doet vaak query op basis van data- domein (ipv navigatie)  RDB 24 Persoon Naam = “Octo” Vrienden Persoon geef alle vrienden van vrienden van x

25 ORDB vs OODB ORDB Eigen (uitgebreid) query taal (SQL) ondersteunt zowel navigatie en SQL query OODB Zoals in DB40: geen abstracte query taal Integreert goed met Java Voorstellen voor query taal: Xpath, CTL 25

26 Verbeteringen op je ontwerp Op je db-schema: normalisatie en de-normalisatie Op fysieke dataontwerp : indexing en clustering 26 IDNaamProdProdNaam 1035Bob555Appel 1123Patrick444Peer 2242Octo111Aardbei 444Peer Data redundatie  niet zuinig, en leid ook tot problemen en anomalieën.

27 Normalisatie Transformatie op je tabellen om data redundantie te minimaliseren  geen informatie verlies! 1NF.. 3NF 27 IDNaamProdProdNaam 1035Bob555Appel 1123Patrick444Peer 2242Octo111Aardbei 444Peer 1NF : geen herhalende groepen, en heeft een primaire sleutel. leidt tot problemen met query en joint.

28 Identificeer attribuut-afhankelijkheden In een tabel T, A,B  C (de combo van attributen A,B bepaalt C) als aan de hand van de waarden van A en B kunnen we de waarde van C in T bepalen. 28 IDNaamProdProdNaam 1035Bob555Appel 1123Patrick444Peer 2242Octo111Aardbei 2242Octo444Peer Partiële afhankelijkheid  redundantie.

29 2NF 2NF: 1NF en de tabel bevat geen partiële afhankelijkheid. 29 IDNaamProdProdNaam IDNaam IDNaam 555Appel 444Peer IDProdID Tabel BESTELLING Tabel PERSOONTabel BESTELLING Tabel PRODUCT

30 3NF Transitieve afhankelijkheid A  A’  B in T (Of, er is A’  B waar A’ geen onderdeel is van prim.sleutel)  weer redundantie. 3NF: 2NF, en geen trans. afhankelijkheden. 30 IDNaam Stad Prov 0BobUtrechtUTR 1PatrickUtrechtUTR 2BobAmsterdamNH Tabel PERSOON IDNaam Stad Prov UtrechtUTR AmsterdamNH Tabel PERSOON Tabel STAD

31 Denormalisatie Als je app vaak naar de stad en prov van persoon x vraagt  moet je nu eerst een join doen. Denormalisatie  zet het terug naar 2NF. Overweeg de tradeoff tussen query snelheid en anomalieën tgv redundantie. 31 IDNaam Stad Prov Tabel PERSOONTabel STAD

32 Fisieke db-ontwerp Uiteindelijk worden tabellen in fysieke bestanden in H-schijven opgeslagen. De formaat en technieken van deze bestanden bepalen ook de prestatie. Je beslist: Welk formaat ? (vb: heap, of met index) Mate van indexatie Wel of niet te clusteren 32

33 Index Hoe vind je persoon x in de opslag?  de records een voor een aflopen  Aflopen van een index-tabel is veel sneler! 33 IDNaam Stad Tabel PERSOON fysieke opslag 0 10 15 20 ID als index

34 Secundaire indexen Je mag ook meerdere indextabellen introduceren… Trade off : Extra ruimte nodig per indextabel rekentijd overhead bij update en delete 34 IDNaam Stad Tabel PERSOON met ID als index Geef de record van persoon x met naam Bob  moet je weer hele tabel aflopen  intro “Naam” als index!

35 Cluster IDNaamKind 0Bob100 0Bob105 0Bob107 1Patrick0 35 IDNaam PIDKind Tabel PERSOONTabel OUDER App vraagt vaak naar joint van PERSOON en OUDER  cluster. cluster sleutel cluster block, kan geindexeerd

36 Cluster niet goed als je: vaak update/delete doet vaak PERSOON afzonderlijk moet aflopen 36 IDNaamKind 0Bob100 0Bob105 0Bob107 1Patrick0

37 Ruimte estimatie Hoeveel ruimte heb ik nodig  medebepalend voor keuze DB engine en hardware. Kijk ook vooruit! Stappen (met een voorbeeld) tabel BESTELLING, 1M records groei 15% per jaar  2M in 5 jaar tijd. Gemiddelde ruimteverbruik per rij, of maak een schatting: ID  VARCHAR(10)  10 bytes Naam  VARCHAR(100)  50 bytes … Totaal 200 bytes 37

38 Ruimte estimatie Totaal voor tabel BESTELLING 200 * 2M bytes Bereken ruimte overhead van indextabellen Stel ID, en Postcode als indexen In de orde van d*2M per indextabel Andere overhead  DB engine specifiek Doe dit voor de rest van tabellen. 38