Niet-relationele d atabase s & intern management & gedistribueerde db systemen

1. Niet-relationele databases &intern management &gedistribueerde db systemen Literatuur: Rolland, “The Essence of Databases”, Hfdst 6, 7, 9, 10

2. De laatste hoofdstukken: • 6: traditionele datamodellen • 7: object-georiënteerde databases • 8: NIET • 9: intern management (2) • 10: gedistribueerde databases

3. Geschiedenis van datamodellen

4. Traditioneel • Hierarchic databases • Network databases • Inferior to relational databases • handling one record at a time only, • difficult to design, • difficult to maintain and use (‘programmer needs to know a lot about the design’). • But … still widely in use in “legacy” systems

5. Hierarchic databases • Eén root. • Alléén 1-M relaties. • Elk record moet precies één ouder hebben. • … zeer veel redundantie. Faculteit Cursus Docent Student

6. Voorbeeld UvA • Cursus weg … student weg • SELECT en UPDATE: eindeloos pointers volgen FMG FNWI c#123CIM c#789Kennis repr c#456Robotica s#124561pim persoon s#982745jaap jansen s#33245hans hanson s#124561pim persoon s#124561pim persoon s#33245hans hanson

7. Netwerk databases • Geen root. • Aantal en richting van de links is niet beperkt. • M..N relaties mogelijk • Reductie van redundancy. Faculteit Cursus Docent Student

8. Voorbeeld • Cursus weg … student weg? • SELECT en UPDATE: nog meer pointers volgen FMG FNWI c#123CIM c#789Kennis repr c#456Robotica s#124561pim persoon s#33245hans hanson s#982745jaap jansen

9. Hfst 7: OODBMS

10. “Gewone” RDBMSs • Goed in opslag van grote aantallen van instanties van niet al te complexe gegevens. • Goed in opslag van gegevens van een eenvoudig type (getallen, strings, booleans). • Goed in gegevens die min of meer statisch zijn.

11. Relationele Databases: beperkingen • Semantiek van de gegevens is beperkt: • Het relationele model heeft slechts één construct (de relationele tabel) voor entiteiten en voor relaties • M.a.w. het relationele model is “semantically overloaded” • Slechts beperkte ondersteuning van integriteits-bewaking: • entiteit-integriteit • referentiële integriteit • organisatorische constraints • Er is slechts een beperkte verzameling voor-gedefinieerde operaties.

12. Beperkingen van “gewone” RDBMSs (2) • Homogene datastructuur: • horizontaal (de attributen liggen vast) • verticaal (de waarden zijn van een bepaald type) • … maar … BLOBs (Binary Large Objects) als datatype is een (povere) ontsnappingsmogelijkheid. • Geen voorziening voor recursieve datastructuren en recursieve vragen. • ‘Impedance mismatch’ • Meeste DMLs zijn niet “computationeel compleet”, daarom inbedding van SQL in een “echte” programmeertaal, maar die heeft “eigen” datastructuren en datatypen: voortdurende conversie van gegevens.

13. Voorbeeld recursieve datastructr. (b) bevat de “impliciete” gegevens

14. RDBMS vaak niet “voldoende” • Computer-Aided Design (CAD) • Computer-Aided Manufacturing (CAM) • Computer-Aided Software Engineering (CASE) • Multimedia Systems • Digitaal publiceren • Geografische Informatie Systemen (GIS) • Kennisintensieve systemen

15. Complexe gegevens • De gegevens hebben een complexe en vaak speciale structuur. • Vaak juist weinig instanties maar grote variëteit • Soms zijn de gegevens procedureel.

16. Beperkingen van “gewone” RDBMSs (3) • Alleen geschikt voor “snelle” transacties (o.m. controle op samenloop m.b.v. een “locking” mechanisme). • De database-schema's zijn maar moeilijk aanpasbaar. • Vraag voor vraag afhandeling, geen of beperkte navigatie mogelijkheden (i.e. van record naar record).

17. Derde generatie DBMSs • Twee min of meer gescheiden ontwikkelingen: • 1. Overname van technieken uit de Object-oriëntatie: • Object-oriënted DBMSs (OODBMSs). • 2. Upgrading van het relationele model: • Object-Relational DBMSs (ORDBMSs).

18. (7.2) Object-oriëntatie • Elk object heeft een eigen unieke en gegarandeerde identiteit. • Definitie van klassen van objecten. • klasse-hiërarchie (sub-klassen en super-klassen), • overerving (langs IS A-relatie naar sub-klassen, langs AKO-relatie naar instanties). • Het object sluit “gegevens” en “gedrag” (methoden) in zich op [encapsulation]. • Communicatie tussen objecten door “messages” (bijv: naar het “branch” object “is er een instantie in Glasgow?”)

19. Object-oriëntatie (2) • Overloading: hergebruik van een en dezelfde methode-naam binnen verschillende objecten. • Polymorfisme en dynamische (late) binding van variabelen (de juiste methode wordt pas gekozen als de klasse bekend is. bijv: list[i].print). • Het runtime systeem beslist welke print methode gebruikt moet worden. • Complexe objecten mogelijk; bijvoorbeeld een object “bestaande uit” veel onderdelen (PART-OF).

20. Objecten • Uniek identificeerbare entiteit. • Een object representeert de essentie (wat het object IS en wat het object DOET). • beschrijft (in geval van klasse) / bevat (in geval van instantie) de gegevens van een “real-world” object. • beschrijft OOK de bijbehorende methodes (gedrag). • Interne details, zoals hoe de gegevens opgeslagen zijn, zijn afgeschermd voor buitenwereld (vgl. ANSI/SPARC-architectuur). • vergelijk relationele entiteiten die alleen de gegevens bevatten of beschrijven ...

21. Voorbeeld klasse en instanties

22. Object-identity (OID) • Systeem gegenereerd, uniek en onveranderbaar. • Onafhankelijk van de attribuutwaarden. • Onzichtbaar voor de gebruiker (in het ideale geval). Vergelijk “primary keys” in relationele model …. De identiteit is afhankelijk van de waarde en de identiteit kan veranderen. • Voordelen OID: • Efficiënt (compact) en snelle toegang (direct of indirect via een mapping). • Onafhankelijk van de inhoud van het object.

23. Objecten attributen • De attributen van een object krijgen als waarde een object, waaronder: • basis-objecten (simpel/ primitief) (char, string, integer). • verzamelingen van objecten (set, tuple, list). • referenties naar andere objecten (middels OID). • De laatste twee maken willekeurig complexe objecten mogelijk.

24. Object-georiënteerde DBs • Elke entiteits-instantie (tupel) is een object-instantie met een uniek OID. • Is instantie van een klasse-object (ook met uniek OID). • Het klasse-object definieert methodes (bijvoorbeeld integriteitsregels, ‘insert into’): m.a.w. de methoden zijn ingekapseld.

25. Nodig voor realisatie OODBMSs • Uitbreiding van Object-georiënteerde Programmeertaal met een “persistent datastore”. • persistent datastore: de gegevens “overleven” de executie van een programma. • Definitie van een eenvoudige vraag-taal. • Ontwikkelen van beveiligingsmechanismen • identificatie van gebruiker en autorisatie • “views” mechanismen

26. Bronnen van Object-georiënteerd Datamodel

27. Voorbeeld 1:1 relatie

28. Voorbeeld 1:M relatie

29. Voorbeeld M:N relatie

30. M:N relatie: alternatief

31. 3 soorten van methoden • Constructors en destructors: • nieuwe instantie bij een klasse (ofwel tupel toevoegen) en weggooien van instanties. • Bevragingsmethoden: • waarde van een attribuut / set van attributen, eventueel methode voor een afgeleid attribuut (e.g. leeftijd), of methode voor een attribuut van de klasse (e.g. aantal personeelsleden, gemiddelde salaris). • Transformatiemethoden: • bijvoorbeeld een update van een (set van) attribuutwaarden.

32. Ontwerp van OODB • ER-diagrammen ondersteunen niet de modellering van methodes; • gebruik hiervoor bijvoorbeeld UML. • Top-down: vanuit de benodigde functionaliteit • Bottum-up: vanuit de belangrijke objecten/entiteiten • Publieke methoden (zichtbaar voor de “andere” objecten) • Private methoden (alleen zichtbaar binnen de klasse)

33. ODMG standaard • Object Database Management Group (ODMG). Standaard; versie ODMG 3.0, 1999). • een Object Model (OM) • een Object Definitie Taal (ODL) • een Object Query Taal (OQL) • een Object Request Broker (ORB) • een COmmon Request Broker Architecture (CORBA) • www.odmg.org

34. Object-Relational DBMSs • Uitbreidingen van het “relationele model” • Ook wel genoemd: • Extended Relational DBMS (ERDBMS) • Universal Server • Universal DBMS (UDBMS)

35. ORDBMS & OODBMS ‘evolution’ ‘revolution’

36. ORDBMS: features • The 3rd-generation Database System Manifesto: • van het “Committee for Advanced DBMS Function” (CADF) • The 3rd Manifesto: • van: Darwin & Date (1995, 1998)

37. CADF wensen • een rijk data-type systeem met enige notie van ‘object’, • specificatie van ‘collections’, • graag overerving, • SQL gebaseerd.

38. Darwin & Date wensen • OO-features zijn leuk, maar ze staan haaks op het relationele model. • Het relationele datamodel verdraagt “no extension, no correction, no subsumption and above all, no perversion”. • Verbetering gezocht in betere definitie van DOMEIN. • Maar SQL is al een grote zonde. Voorstel voor de taal D.

39. Voordelen van OODBMSs • Heeft een rijke semantiek voor de representatie van gegevens. • Is uitbreidbaar met nieuwe datatypen. • Geen “impedance mismatch”, alles in OOPL. • Rijkere bevragingsmogelijkheden. • Uitbreiding van dataschema's mogelijk. • Ondersteuning van langdurige transacties. • Ondersteunt complexe applicaties (CAD/CAM, GIS etc.). • Verbeterde performance.

40. Nadelen OODBMS benadering (1) • Complex (en dus duur in aanschaf en gebruik). • Geen onderliggende theorie. • Geen universeel datamodel. • Geen formeel gedefinieerde ontwerpmethode (zoals normalisatie voor relationele databases). • Ad hoc bevraging. • Vraag-optimalisatie doorbreekt vaak de gegevens-inkapseling: • niet erg want wordt afgehandeld door DBMS … • wel erg want doorbreekt object-oriëntatie filosofie ... ...

41. Nadelen OODBMS benadering (2) • Locking is inefficiënt (komt door overervingstructuur). • Geen ondersteuning van “views”. • Weinig ondersteuning van beveiligingmechanismen. • Ad hoc integriteitsbewaking. • Weinig ervaring. • Weinig standaarden.

42. Nadelen ORDBMS benadering • Complex. • Duurder en slechts nodig voor een kleine subset van toepassingen. • Aan de eenvoud en zuiverheid van relationele model wordt afbreuk gedaan. • OO-aanhangers zijn er ook al niet van gecharmeerd … … • SQL is niet langer een eenvoudige taal …

43. OQL versus SQL3 • Er zijn overeenkomsten, • Er wordt gewerkt aan compatibiliteit, • ODMG probeert OQL volledig compatibel met SQL SELECT te maken, • Met name verschillen in Object Identity (OID), die is bij ORDBMSs gerelateerd aan plaats van rij in tabel, dus kan veranderen ...

44. Hoofdstuk 9: Internal management (2) • 4 onderwerpen: • 1. Management van transacties • 2. Concurrency • 3. Optimalisatie van zoekvragen • 4. Database administratie taken

45. 1. Internal management • Complexe transacties bestaan uit meerdere deel-transacties. • transacties worden uitgevoerd op een ‘image’ van de database, • veranderingen pas vastleggen met een COMMIT, • daarvoor ‘undoable’ met een ROLLBACK.

46. 2. Samenloop (concurrency) • Problemen: • Twee updates tegelijk: 2e update overschrijft resultaat van de 1e update. • Afhankelijkheid tussen transactie A en nog niet gecommitteerde complexe transactie B. • Inconsistente analyse: transactie A is aan het tellen, terwijl transcatie B aan het wijzigen is. • Oplossing: locks • Serialisatie principe

47. 2. Samenloop (2) • Locking van objecten: • S-locks (read-only: e.g. SELECT) meerdere mogelijk. • X-locks (change: e.g.INSERT / UPDATE) kan alleen geplaatst als er geen S- of X-lock op zit. • 2-fase locking: • een lock is verboden als je in dezelfde transactie zojuist een lock op hetzelfde object hebt vrijgegeven.

48. 3. Vraag-optimalisatie Er bestaan uitkomst-invariante transformaties. bijvoorbeeld: • de volgorde van JOINs heeft geen invloed. • een JOIN van 2 tabellen, gevolgd door een RESTRICT kan efficiënter als: eerst RESTRICT op de relevante tabel. • een JOIN van 2 tabellen, gevolgd door een PROJECT kan efficiënter als: eerst PROJECT op alle relevante tabellen, daarna JOIN. • een RESTRICT en vervolgens een PROJECT is equivalent aan een PROJECT (met mogelijk extra attribuut) en vervolgens een RESTRICT.

49. Vraag-optimalisatie (2) • Query equivalentie • Probleem: runtime uitvinden wat efficiënte volgorde is. • Daarvoor is statistiek nodig: • lengte van tabellen (aantal tuples), • formaat van tuples (aantal attributen, datatypen), • proportie van foreign key matches tussen tabellen. • Meestal alleen simpele heuristiek: doe alle joins laatst.

50. 4. Database administratie • Onderwerpen: • 1. Recovery • 2. Security • 3. Performance • 4. Administratie