La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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

Presentazioni simili


Presentazione sul tema: "1 Modelli dei Dati e DBMS di Nuova Generazione + Labo di Basi di dati II Marco Mesiti"— Transcript della presentazione:

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

2 2 Organizzazione dei corsi 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 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 Parte COMUNE I sistemi di data warehouse Tecniche di data mining Regole di associazione Alberi di decisione I sistemi di data warehouse Tecniche di data mining Regole di associazione Alberi di decisione Modelli dei dati Organizzazione dati su memoria secondaria Strategie di elaborazione delle interrogazioni Organizzazione dati su memoria secondaria Strategie di elaborazione delle interrogazioni Basi di dati II I due corsi sono complementari. Ha senso inserire sono uno dei due nel piano di studi I due corsi sono complementari. Ha senso inserire sono uno dei due nel piano di studi

3 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 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 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 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 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 8 Introduzione - requisiti nuove applicazioni 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 I DBMS tradizionali soddisfano solo i primi quattro requisiti

9 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 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 11 Basi di dati orientate ad oggetti

12 12 Introduzione - Lorientamento 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 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 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 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 16 Introduzione - Funzionalità di un OODBMS object identity oggetti complessi incapsulazione ereditarietà overloading e late binding completezza computazionale estensibilità Persistenza condivisione sicurezza affidabilità linguaggio di interrogazione efficienza

17 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 18 Introduzione - Prodotti e prototipi 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)

19 19 Introduzione - Cenni storici : – 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 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 21 Introduzione Caratteristiche fondamentali: – ricchezza di strutture dati – classi e tipi definiti dallutente – 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 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 allindietro) nel frattempo, i più diffusi DBMS relazionali (Informix, Sybase, DB2, Oracle) sono stati estesi con caratteristiche ad oggetti …

23 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 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 25 Modelli dei dati ad oggetti - Concetti di base Oggetti ed identificatori di oggetti Oggetti complessi Incapsulazione Classi Associazioni Ereditarietà

26 26 Oggetti (riassunto caratteristiche) Entita del mondo reale contraddistinte da un identificatore (OID) LOID e indipendente dallo stato delloggetto 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 27 Oggetti ed identificatori - Identità Ogni entità del mondo reale è modellata come un oggetto Ogni oggetto ha un identificatore (OID) che lo distingue da tutti gli altri oggetti nella base di dati L'identificatore è immutabile ed indipendente dal valore dell'oggetto l'oggetto può essere visto come coppia (OID, valore) Gli OID in genere non sono visibili agli utenti

28 28 Oggetti ed identificatori - Identità : Esempio La persona Mario Rossi, residente in via Piave, è un oggetto può essere identificato dallOID 417 se cambia indirizzo, il suo OID rimane 417

29 29 Oggetti ed identificatori - OID e chiavi Una chiave (valore di uno o più attributi) può essere modificata, l'OID è invece immutabile Usando le chiavi, il programmatore deve: – selezionare gli attributi da utilizzare come chiave – assicurare l'unicità dei valori di chiave Gli OID sono gestiti completamente dal sistema

30 30 Oggetti ed identificatori - OID e chiavi Le chiavi sono uniche all'interno di una relazione Gli OID sono unici all'interno dell'intero sistema Poiché gli oggetti sono riferiti in modo uniforme è più semplice gestire collezioni di oggetti eterogenei (es. insieme di persone e di dipartimenti)

31 31 Oggetti ed identificatori - OID e chiavi Rappresentazione di associazioni tra entità – Modello relazionale: value-based le associazioni tra entità sono rappresentate tramite chiavi esterne (join) – Modello ad oggetti: identity-based tramite riferimenti tra oggetti (puntatori) navigazione (direzionale) del riferimento

32 32 Impiegati 123 Mario Rossi … 3 Oggetti ed identificatori - OID e chiavi: Esempio Dipartimenti 3 Ricerca … Impiegato[i] Imp#: 123 Nome:Mario Cognome: Rossi … Dip#: Dipartimento[j] Dipartimento[i] Dip#: 3 Nome:Ricerca... Chiave esterna Riferimento tra oggetti

33 33 Oggetti ed identificatori - identità e uguaglianza Il concetto di OID introduce due tipi di uguaglianza tra oggetti: – identità se i due oggetti hanno lo stesso OID – uguaglianza per valore se i due oggetti hanno lo stesso valore deep: gli attributi corrispondenti sono uguali (per valore) shallow: gli attributi corrispondenti sono identici

34 34 Oggetti ed identificatori - Esempio di oggetti uguali ma non identici

35 35 Oggetti ed identificatori - Condivisione di oggetti Gli OID permettono la condivisione (sharing) di oggetti Nel caso di oggetti condivisi lo stato delle componenti è unico I cambiamenti alle componenti sono visibili da tutti gli oggetti che li riferiscono

36 36 Oggetti ed identificatori - Condivisione di oggetti: esempio

37 37 Oggetti ed identificatori - Condivisione di oggetti: esempio

38 38 Oggetti ed identificatori - Condivisione di oggetti: esempio

39 39 Oggetti complessi Ogni applicazione richiede tipi di dato specifici Nella maggioranza delle applicazioni, i dati sono oggetti con strutture complesse – figure geometriche di base e vettori (applicazioni CAD) – matrici (applicazioni CAM movimenti dei bracci dei robot) – un articolo ha un titolo, una lista di autori, un insieme di parole chiave, una lista di capitoli, ognuno con un titolo e una lista di sezioni...

40 40 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

41 41 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)

42 42 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 list [25, 20, 21] possono a loro volta essere componenti di altri oggetti

43 43 Oggetti complessi - Oggetti e valori Molti sistemi non richiedono che ogni entità sia rappresentata come oggetto, ma distinguono tra valori (o letterali) e oggetti differenze: – i valori sono astrazioni universalmente conosciute (stesso significato per ogni utente) – gli oggetti hanno un significato che dipende dallapplicazione Il valore del numero 4 è universalmente noto – in ogni applicazione, 4 mantiene lo stesso significato la struttura delloggetto Articolo[i] dipende dallapplicazione

44 44 Oggetti complessi - Oggetti e valori I valori sono built-in nel sistema gli oggetti devono essere definiti linformazione rappresentata da un valore è se stesso linformazione di un oggetto è rappresentata dalle relazioni con altri oggetti e valori i valori sono utilizzati per descrivere altre entità gli oggetti sono le entità che devono essere descritte

45 45 Oggetti complessi - oggetti e valori: esempi Esempi tipici di valori: – interi, reali, booleani, caratteri, stringhe in alcuni sistemi si hanno anche valori strutturati – insiemi, liste, tuple, array – valori strutturati possono contenere (riferimenti ad) oggetti come componenti

46 46 Oggetti complessi Vantaggi di un modello che fornisce oggetti complessi: – rappresentazione diretta di oggetti strutturati quali testi, mappe, disegni CAD senza bisogno di decomporli in unità più piccole (tuple o record) – ricerca e ricomposizione più veloce

47 47 Oggetti complessi Molti sistemi permettono di memorizzare valori di grandi dimensioni non strutturati e non interpretati dal sistema BLOB (binary large object): valori di grandi dimensioni come bitmap di immagini o lunghe stringhe di testo Non strutturati: il DBMS non conosce la loro struttura, ma è l'applicazione che li usa che sa come interpretarli utili per rappresentare informazione multimediale (ad esempio immagini) – lo vedremo meglio nel seguito

48 48 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 laccesso ad un attributo a o metodo m di un oggetto o si indica con la seguente path expression: – o.a – o.m

49 49 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 alloggetto sul quale il metodo viene invocato

50 50 Esempio Interfaccia: – aggiorna_stip(int incr) Implementazione: quando il metodo viene invocato su un oggetto o: o.stipendio = o.stipendio + incr

51 51 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

52 52 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 dellimpedence 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

53 53 Incapsulazione - Metodi Un metodo è invocato mandando un messaggio ad un oggetto – o.aggiorna_stip(incr) mando il messaggio aggiorna_stip alloggetto 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

54 54 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

55 55 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 – laccesso ai valori degli attributi è diretto

56 56 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

57 57 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

58 58 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

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

60 60 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

61 61 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

62 62 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''

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

64 64 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)

65 65 Classi - persistenza degli oggetti Approcci per linserimento 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

66 66 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

67 67 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

68 68 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

69 69 Classi -Estensione Per creare gli oggetti, le classi supportano sempre un metodo di creazione (new) – new_persona(): crea un nuovo oggetto di classe persona il metodo di creazione è un metodo di classe – si veda oltre

70 70 Classi - estensione Quando la classe non ha funzione estensionale, le interrogazioni sono applicate a collezioni (insiemi) Possono esserci più insiemi che contengono istanze della stessa classe Lestensione automatica ha il vantaggio della semplicità Lestensione gestita dall'utente ha il vantaggio della flessibilità

71 71 Classi - estensione: possibili approcci In alcuni sistemi (es. ObjectStore, GemStone e O2) la classe definisce solo la specifica e l'implementazione degli oggetti Le interrogazioni e gli indici sono definiti su collezioni di oggetti In altri (es. Orion) la classe definisce la specifica e l'implementazione, ed inoltre mantiene lestensione (insieme delle istanze)

72 72 Classi - estensione Nei sistemi con estensione non automatica l'utente mantiene generalmente lestensione della classe esempio: classe Persona – si associa un nome esterno (es. Persone) ad un oggetto di tipo Set(Persona) – dopo ogni new su Persona si inserisce l'oggetto in Persone – per cancellare un oggetto, lo si rimuove da Persone

73 73 Classi - attributi e metodi di classe Caratterizzano la classe, intesa come un oggetto Non si applicano alle istanze della classe, ma alla classe stessa Esempio: – class Persona (nome, stipendio, eta') – class-attribute maxstipendio – class-method trovailpiu'ricco () -> Persona

74 74 Classi - metodi di classe: costruttori Metodi invocati al momento della creazione di un oggetto il body consiste nell'inizializzazione degli attributi Non hanno tipo di ritorno ed il nome coincide con quello della classe é possibile definire più costruttori per ogni classe (ovviamente con numero di argomenti diverso) Esempio – Classe Persona – costruttore: new_persona -> Persona restituisce un nuovo oggetto istanza della classe Persona

75 75 Associazioni Una associazione e un legame tra due classi Simile al concetto di associazione del modello ER Nel modello ad oggetti sono supportate solo associazioni binarie PROGETTOIMPIEGATO CAPO

76 76 Associazioni: Rappresentazione in UML

77 77 Associazioni: Traversal path Unassociazione del modello ad oggetti viene dichiarata definendo una coppia di traversal path, uno per ogni direzione di attraversamento dellassociazione Ogni traversal path rappresenta il legame logico tra le due classi (es: un impiegato e il capo di un progetto e un progetto ha un responsabile)

78 78 Associazioni: Traversal path I traversal path quindi permettono di specificare lassociazione da una classe A ad una classe B e la sua inversa Per definire un traversal path in una classe C, si usa la seguente notazione: relationship inverse ;

79 79 Associazioni: Esempio

80 80 Associazioni: Esempio class Bar { attribute string nome; attribute string indirizzo; relationship Set serve inverse Birra::servitaDa; } class Birra { attribute string nome; attribute string manuf; relationship Set servitaDa inverse Bar::serve; } Il tipo dellassociazione serve e un insieme di oggetti Birra. Loperatore :: lega il nome sulla destra al contesto in cui si trova tale nome, sulla sinistra

81 81 Associazioni: Tipi Il tipo di una associazioni puo essere: 1. Una classe, (ad es. Bar). Un oggetto di Birra puo essere associato a un solo oggetto di Bar. 2. Set : loggetto e associato con un insieme di oggetti di Bar. 3. Bag, List, Array : loggetto e associato ad un bag, list, o array di oggetti di Bar.

82 82 Associazioni: Molteplicita Associazioni molti-a-molti hanno Set come tipo della associazione e della sua inversa Associazioni molti-a-uno hanno Set come tipo della associazione dal lato uno e solo la classe per lassociazione dal lato molti Associazioni uno-a-uno hanno classi come tipo in entrambe le direzioni

83 83 Associazioni: Esempio di moltiplicita class Bevitore { … relationship Set ama inverse Birra::fans; relationship Birra birraTop inverse Birra::superfans; } class Birra { … relationship Set fans inverse Bevitore::ama; relationship Set superfans inverse Drinker::birraTop; } Molti-a-molti usa Set in entrambe le direzioni. Molti-a-uno usa Set solo dalla parte di uno.

84 84 Associazioni: Associazioni n-arie e binarie con attributi ODL non supporta: – associazioni binarie con attributi – associazioni ternarie o di grado superiore E possibile modellare tali situazioni attraverso una classe di connessione, i cui oggetti rappresentano le tuple di oggetti che si vorrebbero mettere in relazioni atttraverso lassociazione (eventualmente con i relativi attributi).

85 85 Associazioni: Classi di connessione Si supponga di voler connettere le classi X, Y, e Z attraverso lassociazione R. Si crea una classe C, i cui oggetti rappresentano triple di oggetti (x, y, z) presi dalle classi X, Y e Z, rispettivamente. Sono necessarie tre associazioni molti-a-uno da (x, y, z) per ogni x, y e z.

86 86 Associazioni: Esempio di classe di collegamento Si supponga di avere le classi Bar e Birra e di voler rappresentare il prezzo a cui un bar vende una birra – Una associazione molti-a-molti tra Bar e Birra non puo avere un attributo prezzo come nel modello E.R. Una soluzione: Creare una classe BBP che ad ogni birra e bar associa il prezzo relativo. La classe BBP deve contenere due associazioni molti-a-uno tra un suo oggetto e gli oggetti di Bar e Birra che rappresenta.

87 87 Associazioni: Esempio di classe di collegamento class BBP { attribute prezzo:real; relationship Bar ilBar inverse Bar::aBBP; relationship Birra laBirra inverse Birra::aBBP; } Bar e Beer devono essere modificate per contenere la relazione aBBP di tipo Set.

88 88 Associazioni: Un altro esempio Si supponga di avere le classi: – Progetto – Impiegato – Sede E di voler rappresentare lassociazione AssegnatoA che rappresenta il fatto che un impiegato e assegnato ad un progetto in una sede Questa associazione viene modellata inserendo una quarta classe AssegnatoA che contiene le triple di oggetti che specifica che limpiegato i e assegnato al progetto p nella sede s.

89 89 Associazioni: Implementazioni Molti OODBMS non supportano direttamente le associazioni Le associazioni vengono modellate attraverso attributi In questi casi: – E possibile specificare una sola direzione di attraversamento della associazione – Se vengono specificati entrambi gli attributi, non ho garanzia della loro reciprocita

90 90 Gerarchie di aggregazione Le associazioni stabiliscono una gerarchia di aggregazione tra classi In particolare, nella modellazione delle associazioni attraverso attributi, se una classe C è il dominio di un attributo A di una classe C, si dice che cè una relazione di aggregazione (o clientship) tra C e C

91 91 Associazioni: Esempio (ER)

92 92 Associazioni: Esempio (UML)

93 93 Associazioni: Esempio di modellazione con attributi

94 94 Ereditarietà Lereditarietà è un importante meccanismo di riutilizzo del codice Permette ad una classe, detta sottoclasse, di essere definita a partire dalla definizione di una classe già esistente, detta superclasse La superclasse eredita attributi, messaggi e metodi dalla superclasse Può introdurre attributi, messaggi e metodi addizionali Può ridefinire (override) attributi, messaggi e metodi ereditati (con alcune restrizioni)

95 95 Ereditarietà - esempio Si considerino i seguenti tipi di oggetti:

96 96 Ereditarietà - esempio (continua) Nel modello relazionale sono necessarie due tabelle e tre procedure Con l'approccio ad oggetti Camion e Bus sono riconosciuti essere veicoli Si introduce quindi una nuova classe Veicolo e le classi Camion e Bus sono definite come specializzazione di Veicolo è necessario definire solo le caratteristiche aggiuntive delle classi

97 97 Ereditarietà - esempio (continua)

98 98 Ereditarietà - vantaggi Evita ridondanza di codice Fornisce un potente meccanismo di progettazione le classi possono essere raffinate in più passi Permette una rappresentazione dello schema della basi di dati più concisa e meglio organizzata

99 99 Ereditarietà - sostituibilità Un'istanza di una sottoclasse può essere utilizzata ovunque ci si aspetti un'istanza della superclasse ad una variabile di tipo Persona può essere assegnato oggetto istanza della classe Impiegato Ogni variabile ha quindi – un tipo statico: tipo di cui è dichiarata – un tipo dinamico: classe più specifica dell'oggetto cui la variabile è istanziata

100 100 Ereditarietà - overriding Consideriamo i seguenti tipi di oggetti: bitmap, window, impiegato (record) e un'applicazione che debba visualizzare oggetti di tali tipi In un sistema convenzionale bisogna scrivere tre procedure – display bitmap, display window, display impiegato

101 101 Ereditarietà - overriding

102 102 Nell'approccio ad oggetti: – si definisce una classe generale (astratta) Screen Object con tre sottoclassi: bitmap, window, impiegato – si definisce un'operazione display – in ogni sottoclasse si ridefinisce opportunamente l'operazione display for x in X do x.display() Questo tipo di operazione va sotto il nome di overriding.

103 103 Ereditarietà - overloading Una conseguenza dell'overriding è che allo stesso nome di operazione corrispondono differenti implementazioni – stesso nome usato per scopi diversi – overloading Nellesempio l'operazione display() ha almeno tre implementazioni differenti in bitmap, window, impiegato L'overloading si può avere anche in assenza di ereditarietà (es. operazione =)

104 104 Ereditarietà - late binding L'overriding implica l'utilizzo del late binding Il metodo da utilizzare per rispondere ad un messaggio non può cioè essere deciso a compile time ma solo a run-time Un oggetto risponde ad un messaggio eseguendo il metodo più specifico, che non è necessariamente noto a compile time

105 105 Ereditarietà - method lookup (dispatching) È l'operazione effettuata dal sistema per determinare il metodo da eseguire per rispondere ad un messaggio Si determina la classe più specifica cui l'oggetto ricevente appartiene (il suo tipo dinamico) Si determina la superclasse più specifica di tale classe che fornisca un'implementazione per il metodo invocato (risalendo la gerarchia di ereditarietà)

106 106 Ereditarietà - Method lookup: esempio Classe Persona con metodo aggiorna_stip Classe Manager, sottoclasse di Persona, ridefinisce aggiorna_stip Nel codice: – p: persona – p.aggiorna_stip(incr) il tipo statico di p è Persona – a run-time, a p può essere associato un Manager il tipo dinamico di p è manager si sceglie limplementazione di aggiorna_stip contenuta in Manager

107 107 Ereditarietà - estensibilità delle applicazioni E possibile costruire applicazioni che possono essere estese senza modificarne il codice Modifiche allo schema (aggiunta o cancellazione di una classe) non impattano il codice applicativo Se si devono visualizzare anche informazioni relative a studenti, basta definire una nuova classe studente come sottoclasse di Screen Object Non si deve modificare né ricompilare il codice che effettua la visualizzazione degli oggetti

108 108 Ereditarietà - ridefinizione del dominio degli attributi Poiché il dominio rappresenta un vincolo di integrità non è ammissibile lasciarlo ridefinire arbitrariamente nelle sottoclassi Sembrerebbe ragionevole lasciar raffinare il dominio sostituendogli un sottotipo del dominio ereditato Questa sostituzione può generare problemi di tipo a run-time – esistono regole per evitare problemi di tipo (non le vediamo)

109 109 Ereditarietà - ereditarietà multipla Permette ad una classe di avere più superclassi

110 110 Ereditarietà - ereditarietà multipla Risoluzione dei conflitti alternative: – implicita basata su un ordinamento delle superclassi le caratteristiche per cui vi è conflitto sono ereditate dalla prima superclasse se ad esempio Sottomarino è definito come Veicolo a Motore Nucleare e Veicolo Acquatico le caratteristiche comuni (es. dimensioni) sono ereditate dalla classe Veicolo a Motore Nucleare

111 111 Ereditarietà - ereditarietà multipla Risoluzione dei conflitti alternative: – esplicita l'utente specifica da quali superclassi una caratteristica per cui c'è conflitto debba essere ereditatata ad esempio in Sottomarino: attribute dimensioni from Veicolo Acquatico

112 112 Ereditarietà - ereditarietà multipla Risoluzione dei conflitti alternative: – impedire conflitti di nome è possibile definire sottoclasse solo se le superclassi non hanno caratteristiche con nomi comuni problema del diamante – ad esempio attributo peso in Sottomarino

113 113 Ereditarietà - diversi aspetti gerarchia di specializzazione (subtype hierarchy) – consistenza fra le specifiche dei tipi (sostituibilità) – comportamento degli oggetti come visto dallesterno gerarchia di implementazione – condivisione del codice fra le classi gerarchia di classificazione – relazioni di inclusione tra collezioni di oggetti

114 114 Accesso agli oggetti accesso navigazionale: – dato un OID il sistema accede direttamente (e in modo efficiente) all'oggetto riferito – possibilità di accedere agli oggetti navigando da uno all'altro – es. X.progetto.capo.stipendio accesso associativo: – attraverso linguaggio di interrogazione – es. select nome from Impiegato where stipendio > 2000 accesso per nome: – tramite nomi esterni specificati dall'utente – es. MioDoc.titolo

115 115 Accesso agli oggetti - accesso navigazionale l'accesso navigazionale è cruciale in molte applicazioni sfrutta la gerarchia di aggregazione tra gli oggetti e la presenza di riferimenti espliciti (direzionali) nei sistemi relazionali è estremamente inefficiente perchè richiede molte operazioni di join (una per ogni.)

116 116 Accesso agli oggetti - accesso associativo i linguaggi di interrogazione sono cruciali per lavorare su grandi quantità di oggetti l'avere a disposizione un linguaggio di interrogazione dichiarativo ad alto livello riduce i tempi di sviluppo delle applicazioni i linguaggi di interrogazione dichiarativi sono alla base del successo dei DBMS relazionali – più importante caratteristica che gli OODBMS ne hanno ereditato

117 117 Accesso agli oggetti - nomi esterni i nomi esterni forniscono agli utenti riferimenti semanticamente significativi agli oggetti i nomi esterni permettono di definire entry point nella base di dati: – oggetti per cui è possibile accesso diretto

118 118 Accesso agli oggetti le varie modalità di accesso non sono esclusive, ma complementari esempio: – si seleziona un insieme di oggetti da una classe (o collezione) con un'interrogazione dichiarativa – si naviga a partire da ogni oggetto per visualizzare le sue componenti una delle caratteristiche che distinguono un OODBMS da un Persistent Object System è proprio la presenza di un linguaggio di interrogazione dichiarativo

119 119 Linguaggi di interrogazione Caratteristiche principali – uso di path expressions Progetto.capo.nome – scope delle interrogazioni: singola classe gerarchia di ereditarietà – invocazione di metodi Select all from Veicoli where prox_revisione() > 10/11/1999

120 120 Linguaggi di interrogazione la maggioranza dei linguaggi di interrogazione ad oggetti sono estensioni dei linguaggi relazionali la maggiore ricchezza del modello dei dati introduce nuove problematiche – es. chiusura del linguaggio di interrogazione mancanza di base formale (algebra/calcolo ad oggetti) nuove problematiche per l'ottimizzazione (metodi, tecniche di indicizzazione specializzate)

121 121 Lo standard ODMG OMG (Object Management Group) – associazione privata nata nel 1989 con lo scopo di promuovere l'uso di standard nell'area oo – Data General, HP, Sun, Canon, American Airlines, Unisys, Philips, Prime, Gold Hill, SoftSwitch, 3 Com AT&T, Digital, NCR, Bull, IBM, Olivetti ODMG (Object Data[base] Management Group) è uno dei working group di OMG, che consiste dei maggiori produttori di OODBMS (circa il 90% del mercato)

122 122 Lo standard ODMG - scopo del consorzio Sviluppare una serie di standard per favorire portabilità, riusabilità e interoperabilità degli OODBMS commerciali successo dei RDBMS legato allesistenza di standard, differenze tra i modelli dei vari OODBMS sono un ostacolo alla loro diffusione ODMG nel contesto OO stesso ruolo di SQL in quello relazionale

123 123 ODMG - risultati 1993: ODMG 93 standard – [R. Cattell, The Object Database Standard: ODMG93, MorganKaufmann, 1993] 1997: ODMG 2.0 standard – [R. Cattell et al., The Object Database Standard: ODMG 2.0, MorganKaufmann, 1997] 1999: ODMG 3.0 standard – [R. Cattell et al., The Object Database Standard: ODMG 3.0, MorganKaufmann, 1999]

124 124 ODMG - componenti Object Model (modello dei dati ad oggetti) Object Definition Language (ODL) la base è l'interface definition language (IDL) di CORBA Object Query Language (OQL) linguaggio di interrogazione dichiarativo (la base è SQL) Bindings per linguaggi, per C++, Smalltalk, Java

125 125 ODMG 3.0 ODL - Esempio

126 126 ODMG 3.0 ODL - Esempio (continua)

127 127

128 128 lo standard ODMG comprende un linguaggio di interrogazione dichiarativo OQL che è stato fortemente influenzato dal linguaggio di interrogazione di O 2 molti OODBMS ODMG compliant non implementano (ancora) OQL, o ne implementano solo un sottoinsieme ODMG OQL

129 129 ODMG OQL: esempi determinare i task con almeno 20 mesi uomo il cui responsabile guadagna almeno 2000 select t from Tasks t where t.mes_uomo > 20 and t.responsabile.stipendio > 2000 il risultato è di tipo bag

130 130 ODMG OQL: esempi determinare la data di inizio dei task con almeno 20 mesi uomo select distinct t.dat_in from Tasks t where t.mes_uomo > 20 il risultato è un letterale di tipo set

131 131 ODMG OQL: esempi determinare la data di inizio e la data di fine dei task con almeno 20 mesi uomo select distinct struct(di: t.dat_in, df: t.dat_fine) from Tasks t where t.mesi_uomo > 20 il risultato è di tipo set

132 132 ODMG OQL: esempi determinare i rapporti tecnici che hanno lo stesso titolo di un articolo select tr from Rapporti_Tecnici tr, Articoli a where tr.titolo = a.titolo

133 133 Modello dei dati ad oggetti - esempio di schema

134 134 Progettazione di schemi ad oggetti Metodologie di progettazione ad oggetti (es. UML) La componente strutturale/statica (es. class diagrams) non è molto diversa dai diagrammi Entità-Relazione

135 135 Progettazione di schemi ad oggetti Entità – oggetto – Diverse modalità di identificazione (non è necessario introdurre codici se non semanticamente significativi per l'applicazione) – Possibilità di rappresentare direttamente attributi multivalore e strutturati insieme di entità – classe (collezione) – attributi – metodi (non distinguiamo tra interfaccia e implementazione) – attributi complessi – Aggregazione/associazione


Scaricare ppt "1 Modelli dei Dati e DBMS di Nuova Generazione + Labo di Basi di dati II Marco Mesiti"

Presentazioni simili


Annunci Google