Modelli dei Dati e DBMS di Nuova Generazione + Labo di Basi di dati II

1. Modelli dei Dati e DBMS di Nuova Generazione+Labo di Basi di dati II Marco Mesiti mesiti@disi.unige.it http://www.disi.unige.it/person/MesitiM/teach.html

2. Parte COMUNE • Modello dei dati ad oggetti • Modelli dei dati relazionali ad oggetti • Il modello relazionale ad oggetti di Oracle • Le basi di dati attive (in particolare Oracle) • XML DBMS Modelli dei dati Basi di dati II • I sistemi di data warehouse • Tecniche di data mining • Regole di associazione • Alberi di decisione • Organizzazione dati su • memoria secondaria • Strategie di elaborazione • delle interrogazioni Organizzazione dei corsi I due corsi sono complementari. Ha senso inserire sono uno dei due nel piano di studi

3. Organizzazione di ogni corso • Progetto • progettazione e sviluppo di una base di dati relazionale ad oggetti su Oracle • Seminario • Approfondimento di uno degli argomenti visti a lezione • Progetto + Seminario • Da svolgere in gruppi da 2 o 3 persone • Valutazione complessiva: [-2,2] • Se il seminario viene svolto entro la fine del corso, il range di valutazione e’ [-1,3] • Esame: • 2 compitini (o scritto) • Progetto + Seminario • orale obbligatorio solo in caso di sufficienza non piena (16-17) o scarsa su determinati argomenti

4. Orario • Lunedi’: • 13:30 – 14:30 • 14:45 – 16:00 • Mercoledi’ • 11:00 – 12:00 • 12:15 – 13:30 • Orario ricevimento: mercoledi’ 14:30 – 16:00 (ufficio Prof. Bertino)

5. Introduzione • Le prime e più rilevanti applicazioni dei DBMS sono state in campo finanziario ed amministrativo • questo ha influenzato l'organizzazione e l'utilizzo dei dati nei DBMS • innovazioni hardware hanno aperto il mercato a nuove applicazioni che richiedono strumenti software adeguati

6. Introduzione • Esempi di tali applicazioni sono: • (Iper)testi, multimedia • Progettazione: CAD/CAM, CASE • Computer integrated manufacturing • Sistemi esperti/basi di conoscenza • Office automation • Reti intelligenti (telecomunicazioni) • Sistemi di supporto delle decisioni • Sistemi informativi geografici/cartografici

7. Introduzione • Tali nuove applicazioni possono essere caratterizzate come data-intensive programming in the large • data intensive: un programma data-intensive produce e/o richiede grandi quantità di dati • programming in the large: programmi molto grandi e complessi, progettati e sviluppati da molti programmatori (software engineering) • Sistemi software molto grandi e complessi che richiedono di gestire grandi quantità di dati

8. Condivisione dei dati Persistenza dei dati Grandi quantità di dati Affidabilità dei dati Interoperabilità Dati strutturati (tipi complessi) Semantica dei dati Modellazione del comportamento attivazione comportamento in automatico manipolazioni complesse Introduzione - requisiti nuove applicazioni I DBMS tradizionali soddisfano solo i primi quattro requisiti

9. Introduzione - Evoluzione dei DBMS • DBMS orientati ad oggetti • DBMS + programmazione orientata ad oggetti • DBMS relazionali estesi o relazionali ad oggetti • DBMS relazionali estesi con concetti ad oggetti • DBMS attivi • DMBS + comportamento reattivo AI

10. Introduzione - Evoluzione dei DBMS • Datawarehouse • DBMS + sistemi per il supporto alle decisioni • Datamining • DBMS + statistica • DBMS XML • DBMS + documenti XML • DBMS deduttivi • DBMS + programmazione logica

11. Basi di dati orientate ad oggetti

12. Introduzione - L’orientamento ad oggetti • Object-orientation sempre più diffuso in ambito software engineering e linguaggi di programmazione • vantaggio di unicità del paradigma • L'object-orientation è una tecnologia chiave per architetture software avanzate e piattaforme di sviluppo di applicazioni • Richiede maggior tempo di progettazione iniziale • Riduce significativamente la dimensione del codice • Richiede minor tempo totale e meno sviluppatori

13. Introduzione - Unicità del paradigma • Nel tradizionale ciclo di vita del software si devono superare diverse barriere ognuna delle quali comporta problemi di comunicabilità • dal dominio del problema all'analisi (es. Data Flow Diagram), alla programmazione (es. C) alle basi di dati (es. ER+relazionali) • Nel ciclo di vita del software orientato ad oggetti le varie fasi si basano su un unico modello • non si deve progettare separatamente la struttura della base di dati • non si hanno problemi di comunicazione tra DBMS e linguaggio di programmazione

14. Introduzione - Integrazione di sistemi eterogenei • Un requisito importante è che le nuove applicazioni possano interagire con le applicazioni esistenti e accedere ai dati gestiti da tali applicazioni • La scelta di uno specifico linguaggio o DBMS dipende dai requisiti correnti dell'applicazione e dalla tecnologia disponibile, che variano nel tempo • sistemi eterogenei • Il paradigma ad oggetti, grazie all'incapsulazione, permette di risolvere problemi di integrazione

15. Introduzione - Definizione di OODBMS • Un OODBMS è un sistema con le funzionalità e le caratteristiche di: • un linguaggio di programmazione ad oggetti • un DBMS • Il progetto di un OODBMS richiede l'integrazione della tecnologia delle basi di dati con la tecnologia object-oriented

16. object identity oggetti complessi incapsulazione ereditarietà overloading e late binding completezza computazionale estensibilità Persistenza condivisione sicurezza affidabilità linguaggio di interrogazione efficienza Introduzione - Funzionalità di un OODBMS

17. Introduzione - A chi è adatto un OODBMS? • Organizzazioni che: • hanno necessità di tempi di sviluppo brevi • adottano programmazione ad oggetti • hanno necessità di condividere informazione complessa • sviluppano sistemi intelligenti

18. ObjectStore(Object Design) GemStone (Serviologic) O2 (Ardent Software) POET (POET Software) Jasmine (Computer Associates) Orion (MCC) /Itasca Ontos (Ontologic) Objectivity/DB (Objectivity) Iris/OpenODB(HewlettPackard) Versant (Versant Technology) Vision (Innovative Systems) GBase (Graphael) Statice (Symbolics) Trellis (Digital) Zitgeist (Texas Instr.) Matisse (Matisse Software) Introduzione - Prodotti e prototipi

19. Introduzione - Cenni storici • 1986-1989: • lancio dei primi linguaggi ad oggetti con persistenza (sistemi standalone, non adottano piattaforme standard industriali) • es: GBase, GemStone, Vbase • 1990: • primi OODBMS con funzionalità complete • architettura client/server, piattaforme comuni • es: Ontos, ObjectStore, Objectivity, Versant, Itasca, O2 , Zeitgeist • 1991: • nasce ODMG necessità di uno standard • 1993,1997: ODMG93 e ODMG 2.0 • 1999: ODMG 3.0 object data management

20. Introduzione • OODBMS sono stati fortemente influenzati da linguaggi di programmazione ad oggetti e fortemente contrapposti a DBMS relazionali • prodotti da piccole compagnie (non quelle che dominano il mercato dei DBMS)

21. Introduzione • Caratteristiche fondamentali: • ricchezza di strutture dati • classi e tipi definiti dall’utente • stretta integrazione con linguaggi di programmazione ad oggetti • accesso navigazionale ai dati • gli OODBMS si sono imposti in nicchie di mercato che non trovavano adeguato supporto dai DBMS relazionali (es. CAD)

22. Introduzione • Tali DBMS non hanno avuto il successo di mercato sperato • più carenti per quanto riguarda le funzionalità DBMS dei consolidati prodotti relazionali • mancanza o limitatezza di accesso associativo ai dati • problema dei legacy system (problemi nel garantire compatibilita’ all’indietro) • nel frattempo, i più diffusi DBMS relazionali (Informix, Sybase, DB2, Oracle) sono stati estesi con caratteristiche ad oggetti …

23. Introduzione • Gli OODBMS forniscono persistenza a oggetti creati in Java, C++, Smalltalk: • estensione di un ambiente di programmazione ad oggetti • gli ORDBMS (come i relazionali) introducono una API separata (basata su SQL) per lavorare con i dati memorizzati e hanno un loro sistema dei tipi che non è puramente object-oriented • oggi la quota di mercato che utilizza OODBMS è piuttosto bassa

24. Allora perchè li studiamo? • Storicamente importanti • ci permettono di capire meglio i concetti alla base dei sistemi relazionali ad oggetti • “semplici da capire” SE è nota la programmazione ad oggetti

25. Modelli dei dati ad oggetti - Concetti di base • Oggetti ed identificatori di oggetti • Oggetti complessi • Incapsulazione • Classi • Associazioni • Ereditarietà

26. Oggetti (riassunto caratteristiche) • Entita’ del mondo reale contraddistinte da un identificatore (OID) • L’OID e’ indipendente dallo stato dell’oggetto • Diversi concetti di uguaglianza/identita’ tra oggetti • Gli OID degli oggetti non sono “chiavi” degli oggetti • La presenza degli OID permettono la condivisione (sharing) di oggetti • Gli oggetti complessi sono oggetti che presentano una struttura specifica per una applicazione

27. Oggetti complessi • Non è possibile sviluppare un DBMS che fornisca tutti i possibili tipi di dato che potrebbero servire in un'applicazione • Gli oggetti del mondo reale devono poter essere “mappati'' in oggetti della base di dati nel modo più diretto possibile • La soluzione è quella di fornire agli utenti dei “building blocks'' con cui costruire i tipi di dato necessari

28. Oggetti complessi • Gli OODBMS forniscono: • tipi di dato strutturati • oggetti complessi • tipi di dato (ADT) specifici dell'applicazione • tipi di dato non strutturati es. binary large objects (Blobs)

29. Oggetti complessi • Assemblati a partire da oggetti atomici mediante costruttori • Oggetti atomici true, false, 25, ''this is an atom'' • Costruttori • tuple [fname: John, lname: Doe] • set {John, Susan, Mary } • array <1:25, 2:20, 3:21> • list [25, 20, 21] • possono a loro volta essere componenti di altri oggetti

30. Incapsulazione - Componenti di un oggetto • In un OODBMS i dati e le operazioni su di essi sono incapsulati in un'unica struttura (l'oggetto) • Un oggetto consiste quindi di: • un OID, o identificatore • uno stato, o valore, costituito dai valori per un certo numero di attributi, o campi • tali campi possono contenere riferimenti ad altri oggetti • un comportamento costituito da un insieme di metodi o operazioni • l’accesso ad un attributo “a” o metodo “m” di un oggetto “o” si indica con la seguente path expression: • o.a • o.m

31. Incapsulazione - Metodi • La definizione di un metodo consiste di due componenti: • segnatura: specifica il nome del metodo, il nome (e i tipi) degli argomenti, ed eventualmente il tipo del risultato • body: consiste di codice scritto in qualche linguaggio di programmazione (eventualmente esteso) • ObjectStore: C++ o Java • O2: CO2 (estensione del C) • ogni metodo ha sempre un parametro implicito che corrisponde all’oggetto sul quale il metodo viene invocato

32. Esempio • Interfaccia: • aggiorna_stip(int incr) • Implementazione: quando il metodo viene invocato su un oggetto “o”: • o.stipendio = o.stipendio + incr

33. Incapsulazione - Metodo: messaggi e implementazione • L'implementazione (body) delle operazioni è nascosta, cioè non è visibile dall'esterno • l'interfaccia di un oggetto è l'insieme delle segnature delle operazioni • definisce i messaggi cui l'oggetto risponde • descrive interazione dell'oggetto con il mondo esterno

34. Incapsulazione - metodi • I dati e le operazioni sono progettati insieme e sono memorizzati nello stesso sistema • maggiore indipendenza logica dei dati • si supera il problema dell’impedence mismatch presente in SQL: • in SQL: è necessario utilizzare SQL + linguaggio di programmazione per avere un completo potere espressivo • due linguaggi diversi • problemi di gestione codice • in OODBMS: un unico linguaggio, che permette di definire operazioni mediante metodi associati agli oggetti • L'intera applicazione può quindi essere completamente scritta in termini di oggetti

35. Incapsulazione - Metodi • Un metodo è invocato mandando un messaggio ad un oggetto • o.aggiorna_stip(incr) • mando il messaggio aggiorna_stip all’oggetto o • Mandando lo stesso messaggio a due oggetti di due classi differenti questi possono esibire comporatamenti differenti (vedi dopo) • overloading: metodi con lo stesso nome ma comportamento differente

36. Incapsulazione - Overloading: esempio • Oggetto Impiegato[i] con metodo aggiorna_stip(incr): • aggiunge incr allo stipendio di Impiegato[i] • Oggetto Manager[j] con metodo aggiorna_stip(incr): • moltiplica lo stipendio di Manager[j] per incr

37. Incapsulazione e basi di dati • Incapsulazione stretta • i valori degli attributi di un oggetto possono essere letti e scritti solo tramite metodi accessor (getAttr) e mutator (setAttr) • Incapsulazione non stretta • l’accesso ai valori degli attributi è diretto

38. Incapsulazione e basi di dati • Metodi accessor: • restituiscono il valore associato ad un attributo di un oggetto • o.getStipendio: restituisce lo stipendio di un impiegato o • Metodi mutator: • modificano il valore di un attributo di un oggetto • o.setStipendio(stip): lo stipendio di o diventa stip • si è forzati a scrivere molti metodi banali

39. Incapsulazione e basi di dati • Diversi approcci: • attributi possono essere acceduti (letti e scritti) direttamente • es. Orion • si forza incapsulazione stretta • es. GemStone • si permette di specificare quali attributi possono essere acceduti direttamente e quali no (attributi pubblici e privati) • es. ODMG, O2, ObjectStore

40. Classi - Instaziazione • L'istanziazione è un meccanismo che permette di “riutilizzare'' la stessa definizione per generare oggetti simili • il concetto di classe è la base per l'istanziazione • Una classe descrive le sue istanze specificando: • una struttura, cioè un insieme di attributi • un insieme di messaggi che definiscono l'interfaccia esterna degli oggetti • un insieme di metodi che sono invocati da tali messaggi

41. Classi - Esempio Classe Impiegato ( string nome, int stipendio, METHOD aggiorna_stip(int incr) )

42. Classi - tipo, classe, interfaccia • Nel modello ad oggetti sono presenti diversi concetti legati alla descrizione delle caratteristiche di un insieme di oggetti: • tipo, classe, interfaccia • La separazione tra tali concetti è piuttosto confusa e le differenze con cui i termini vengono utilizzati varia da sistema a sistema

43. Classi - tipo • É un concetto principalmente legato ai linguaggi di programmazione • fornisce la specifica di un insieme di oggetti o valori (operazioni invocabili su di essi) • è utilizzato a tempo di compilazione per controllare la correttezza dei programmi

44. Classi - classe • Fornisce l'implementazione (stato + implementazione delle operazioni) per un insieme di oggetti dello stesso tipo • fornisce primitive per la creazione di oggetti • Fornisce primitive per la creazione di associazioni tra classi • è “first class object''

45. Classi - interfaccia • Fornisce la specifica del comportamento esterno di un insieme di oggetti • può essere implementata da una classe • non può essere instanziata direttamente

46. Classi - persistenza degli oggetti • Persistenza degli oggetti significa: • come gli oggetti sono inseriti nella base di dati • come gli oggetti sono rimossi dalla base di dati • oggetti transienti: • non persistenti • esistono solo durante la sessione di lavoro • Nei sistemi relazionali esistono comandi espliciti per inserire e rimuovere i dati nella/dalla base di dati (INSERT, DELETE)

47. Classi - persistenza degli oggetti • Approcci per l’inserimento degli oggetti • persistenza automatica • ogni oggetto diventa automaticamente persistente quando viene creato • non c'è bisogno di un comando di inserimento esplicito • radici di persistenza • gli oggetti creati sono transienti • per renderli persistenti bisogna assegnare loro un nome o associarli, come componente ad un oggetto persistente

48. Classi - persistenza degli oggetti • Approcci per la cancellazione degli oggetti: • tramite un comando di cancellazione esplicito (es. Orion, Iris) • dal sistema quando non è più riferito da altri oggetti (es. GemStone, O2) • il secondo approccio assicura l'integrità referenziale, ma necessita di un meccanismo di garbage collection • il sistema deve supportare un algoritmo in grado di capire quando un oggetto non è più riferito ed invocare tale algoritmo periodicamente

49. Classi - persistenza degli oggetti • Molti sistemi permettono di avere istanze persistenti e transienti di una stessa classe • Le applicazioni accedono gli oggetti in modo uniforme, indipendentemente dal fatto che siano transienti o persistenti

50. Classi - estensione • Oltre ad essere un template, la classe in alcuni sistemi denota anche la collezione delle sue istanze (estensione) • Questo aspetto è importante perchè la classe diventa la base su cui sono formulate le interrogazioni • Le interrogazioni sono significative solo se applicate a collezioni di oggetti