H10: Persistentie MSO, 2 e deel: Ontwikkeling

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

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

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.

4. Uitdaging • 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 • “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 • 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 • Meest gebruikte DB  relationeel  bewezen technologie. • In wiskunde, een relatie R : A×B×C is een verzameling van tupels uit A×B×C zoals: { (a1,b1,c1), (a2,b2,c2) } • Een tabel is een relatie:

8. Typische architectuur Presentatie (User Interface) laag Bedrijfslogica (Probleemdomein /PD ) laag Klant Product bestelt * Persistentie (Data Access Management / DAM) laag save, load, query DB

9. Impendance mismatch… • 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 • Mappingframeworks

10. Entity Relationship (ER) Diagram Product ID {PK} Naam Prijs Klant ID {PK} Naam Leeftijd bestelt * Klant Product Bestelling

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

12. ERD en klasse diagram Auto Naam = “Toyota” Prijs = 2000 € Bouwjaar = 2000 Product Naam Prijs Auto Bouwjaar Product ID {PK} Naam Prijs traditioneel ERD kent geen inheritence. Auto ID {PK} Bouwjaar is extensie van 0..1 1 Auto Product Auto_Product

13. Nog meer vraagstukken… Persoon Naam = “Bob” Leeftijd = 6 Persoon Naam = “Octo” Leeftijd = 7 Vrienden • 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? Persoon Persoon Persoon

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

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

16. Object-Relationele DB / ORDB CREATE TYPE Persoon AS OBJECT (Naam CHAR(20) VriendenSET (REFPersoon) ) CREATE TYPE KlantUNDERPersoon( lidnr INT ) 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.

18. Java Persistence Architecture / JPA • javax.jpa, implementatie: Apache OpenJPA • Entity manager  gratis DAO • Je moet nog een “mapping” specificeren… EntityManagerem = 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? @Entity @Table(name=“PERSOON”) class Persoon { @Id @Column(name=“ID”) private int id @Column(name=“NAAM”) private String naam @ManyToMany private Collection<Persoon> 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.

21. OO DB • Zoals DB4O • Er is geen relationele mapping • Objecten zijn ‘direct’opgeslagen. Persoon Naam = “Octo” Vrienden Persoon Persoon

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

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 historie klacht klacht klacht arts medicijn 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 Persoon Naam = “Octo” Vrienden geef alle vrienden van vrienden van x Persoon Persoon

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

26. Verbeteringen op je ontwerp • Op je db-schema: normalisatie en de-normalisatie • Op fysieke dataontwerp : indexing en clustering 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 leidt tot problemen met query en joint. 1NF : geen herhalende groepen, en heeft een primaire sleutel.

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. Partiële afhankelijkheid  redundantie.

29. 2NF • 2NF: 1NF en de tabel bevat geen partiële afhankelijkheid. Tabel BESTELLING Tabel PERSOON Tabel 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. Tabel PERSOON 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. Tabel PERSOON Tabel 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

33. Index fysieke opslag • Hoe vind je persoon x in de opslag?  de records een voor een aflopen  • Aflopen van een index-tabel is veel sneler! Tabel PERSOON 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 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 Tabel PERSOON Tabel OUDER App vraagt vaak naar joint van PERSOON en OUDER  cluster. cluster block, kan geindexeerd cluster sleutel

36. Cluster • niet goed als je: • vaak update/delete doet • vaak PERSOON afzonderlijk moet aflopen

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

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.