1
1
Modelli dei Dati di Nuova Generazione
2
Organizzazione corso
� Introduzione� Introduzione al modello dei dati ad oggetti� I modelli dei dati relazionali ad oggetti
– il modello relazionale ad oggetti di Oracle
� Le basi di dati attive� Ricorsione in SQL-99� Le basi di dati multimediali
– testi
– immagini
2
3
Organizzazione corso
� Progetto– progettazione e sviluppo di una base di dati relazionale ad
oggetti, attiva su Oracle 9i– il progetto potrà essere svolto nella parte finale del corso
– valutazione: 0-2
� Esame:– 2 compitini o scritto
– progetto– orale obbligatorio solo in caso di sufficienza non piena (16-17)
o scarsa su determinati argomenti
4
Introduzione
� I sistemi di gestione di basi di dati relazionali (RDBMS) hanno permesso la realizzazione efficace ed efficientedi applicazioni di tipo gestionale, caratterizzate da
– persistenza, condivisione, affidabilità
– dati a struttura semplice, con dati di tipo numerico/simbolico
– transazioni concorrenti di breve durata (OLTP)
– interrogazioni complesse, espresse mediante linguaggidichiarativi e con accesso di tipo “associativo”
� La rapida evoluzioni tecnologica (miglioramento diprestazioni, capacità, e costi dell’hardware) ha fattoemergere nuove esigenze applicative per le quali la tecnologia relazionale è inadeguata
3
5
Introduzione - aree applicative emergenti
� Progettazione assistita da calcolatore– CASE (Computer-Aided Software Engineering)
– CAD (Computer-Aided Design)– CAM (Computer-Aided Manufacturing)
� Gestione di documenti– testi e automazione d’ufficio
– dati ipertestuali– dati multimediali
� Altro– scienza e medicina– sistemi esperti, per la rappresentazione di conoscenza
6
Introduzione - esempi di nuoveapplicazioni
� una base di dati con informazioni sui requisiti di adiacenza deicomponenti di un chip e l'esigenza di funzioni di ottimizzazione
� un archivio di 40.000 fotografie, con didascalie, coordinate geografiche ed esigenze di interrogazioni complesse:
– "trova le foto con un tramonto scattate a Roma o dintorni"
� archivio sinistri di una compagnia assicurativa (con foto, grafici, luogo) finalizzato alla ricerca delle frodi
� archivio del personale con informazioni sul curriculum, foto, residenza per una gestione integrata (riconoscimento, valutazionedelle competenze, proposta di "car-pool")
4
7
Introduzione - caratteristiche nuove aree applicative
� 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)
8
Introduzione - caratteristiche nuove aree applicative
� Oltre alle caratteristiche consuete di persistenza, condivisione e affidabilità, possiamo individuare
– dati a struttura complessa� dati non-numerici — immagini, dati spaziali, sequenze temporali, ...� tipi predefiniti e tipi definiti dall'utente (e riutilizzati)
� relazioni esplicite ("semantiche") tra i dati (riferimenti),aggregazionicomplesse
– operazioni complesse� specifiche per i diversi tipi di dato — es. multimedia
� associate anche ai tipi definiti dall'utente� transazioni di lunga durata� attivazione comportamento in automaticp
5
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
� DBMS multimediali– applicazione DBMS relationali ad oggetti
� DBMS deduttivi – DBMS + programmazione logica
– ricorsione
10
Basi di dati ad oggetti
6
11
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
12
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. DFD), 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
7
13
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
14
Basi di dati ad oggetti (ODBMS)
� Alcune delle precedenti caratteristiche suggeriscono l’introduzionedi nozioni dal paradigma orientato agli oggetti nel mondo dellebasi di dati
� A partire dalla metà degli anni '80, sono stati realizzati numerosisistemi di gestione di basi di dati a oggetti (ODBMS) — di tipoprototipale o commerciale
� I sistemi sono stati sviluppati indipendentemente, senza nessunastandardizzazione circa il modello dei dati o i linguaggi dautilizzare
� Dopo un periodo di “evoluzione,” inizia ad esserci unaconvergenza su modello e linguaggio, per far sì che sistemirealizzati da produttori diversi possano almeno interoperare
8
15
Tecnologia ODBMS
� La prima generazione di ODBMS è composta dai linguaggi diprogrammazione a oggetti persistenti, che realizzano solo alcunecaratteristiche delle basi di dati, senza supporto per l’interrogazione, in modo incompatibile con gli RDBMS
� Gli ODBMS della seconda generazione realizzano un maggiornumero di caratteristiche delle basi di dati, e generalmenteforniscono un supporto all’interrogazioneDue tecnologie diODBMS
– OODBMS (Object-Oriented): una tecnologia rivoluzionaria rispetto a quella degli RDBMS
– ORDBMS (Object-Relational): una tecnologia evoluzionaria rispetto a quella degli RDBMS
16
Basi di dati orientate ad oggetti(OODBMS)
9
17
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
18
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
10
19
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
20
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)
11
21
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
22
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)
12
23
Introduzione
� Caratteristiche fondamentali:– ricchezza di strutture dati– classi e tipi definiti dall’utente– stretta integrazione con linguaggi di
programmazione ad oggetti– accesso ai dati navigazionale
� gli OODBMS si sono imposti in nicchie di mercato che non trovavano adeguato supporto dai DBMS relazionali (es. CAD)
24
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
� nel frattempo, i più diffusi DBMS relazionali (Informix, Sybase, DB2, Oracle) sono stati estesi con caratteristiche ad oggetti (ORDBMS)
13
25
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
26
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
14
27
Modelli dei dati ad oggetti
� Una base di dati a oggetti è una collezione di oggetti� Quindi
– Entita’ = oggetto� Ciascun oggetto ha un identificatore, uno stato, e un
comportamento– l’identificatore (OID) garantisce l’individuazione in modo
univoco dell’oggetto, e permette di realizzare riferimenti traoggetti
– lo stato è l’insieme dei valori assunti dalle proprietàdell’oggetto è in generale un valore a struttura complessa
– il comportamento è descritto dall’insieme dei metodi chepossono essere applicati all’oggetto
28
Modelli dei dati ad oggetti –differenze con modello relazionale
� Due differenze fondamentali– struttura complessa:
� nidificata� con identificatori gestiti dal sistema
– comportamento
15
29
Tipo e classe
� Gli oggetti sono associati ad un tipo (intensione) e ad una classe (implementazione)
– un tipo è una astrazione che permette di descrivere (1) lo statoe (2) il comportamento di un oggetto
– una classe descrive l’implementazione di un tipo — strutturadei dati e implementazione di metodi tramite programmi
� Gli oggetti vengono raggruppati in collezioni(estensioni)
� Faremo le seguenti ipotesi semplificative– il concetto di classe descrive sia l’implementazione sia
l’estensione di un tipo
30
Tipi user defined
� 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 ...
16
31
Tipi user defined
� 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 (tipi user-defined )
32
Tipi – parte statica
� Un tipo descrive le proprietà di un oggetto (la partestatica) e l’interfaccia dei suoi metodi (la partedinamica)
� Relativamente alla parte statica, i tipi vengono costruitia partire da
– Tipi atomici : un insieme di tipi atomici (numeri, stringhe, ...)
– Tipi complessi : un insieme di costruttori di tipo, tra loroortogonali� record-of(A1:T1, ..., An:Tn)
� set-of(T), bag-of(T), list-of(T)� un riferimento, indicato con *T, ad altro tipo definito nello schema
è considerato un tipo, utilizzato per rappresentare relazioni traoggetti (associazioni)
17
33
Tipo complesso - esempio
automobile: record-of(targa: string, modello: string,il_costruttore: record-of(
nome: string,presidente: string,stabilimenti: set-of(
record-of(nome: string, citta: string,addetti: integer))),
colore: string, prezzo: integer,partiMeccaniche: record-of(
motore: string,ammortizzatore: string))
34
Tipo complesso - esempio
automobile: record-of(targa: string, modello: string,il_costruttore: costruttore_t,colore: string, prezzo: integer,partiMeccaniche: record-of(
motore: string,ammortizzatore: string))
costruttore: record-of(nome: string,presidente: string,stabilimenti: set-of(
record-of(nome: string, citta: string,addetti: integer)))
18
35
Valore complesso - esempio
� E’ possibile definire dei valori complessi compatibili con un tipocomplesso
V1: [targa: “MI67T891”, modello: “uno”,costruttore: [
nome: “FIAT”, presidente: “Agnelli”,stabilimenti: {
[nome: “Mirafiori”, citta: “Torino”, addetti: 10000],[nome: “Trattori”, citta: “Modena”,addetti: 1000]}],
colore: “blu”, prezzo: 15.5M,partiMeccaniche: [motore: “1100CV”, ammortizzatore: “Monroe”]]
36
Oggetti e valori
� L’uso di tipi e valori complessi permette di associare ad un singolo oggetto una struttura qualunque
� Un oggetto è una coppia (OID, Valore), dove OID (object identifier) è un valore atomico definito dalsistema e trasparente all’utente, e Valore è un valorecomplesso
� Il valore assunto da una proprietà di un oggetto puòessere l’OID di un altro oggetto (realizzando così un riferimento)
� L’uso dei riferimenti permette di “normalizzare” la rappresentazione di valori complessi.
19
37
Tipi complessi con riferimenti
automobile : record-of(targa: string, modello: string,il_costruttore: *costruttore,colore: string, prezzo: integer,partiMeccaniche: record-of(motore: string,ammortizzatore: string))
costruttore : record-of(nome: string, presidente: string,stabilimenti: set-of(*stabilimento))
stabilimento : record-of(nome: string, citta: string,addetti: integer)
38
Oggetti - esempio
� O1: <OID1, [targa: “MI67T891”, modello: “uno”, costruttore: OID2, colore: “blu”,prezzo: 15.5M, motore: “1100CV”, ammortizzatore: “Monroe”]>
– Oggetto di tipo automobile
� O2: <OID2, [nome: “FIAT”, presidente: “Agnelli”, stabilimenti: {OID3,OID4}]>
– Oggetto di tipo costruttore
� O3: <OID3, [nome: “Mirafiori”, citta: “Torino”, addetti: 10000]>– Oggetto di tipo stabilimento
� O4: <OID4, [nome: “Trattori”, citta: “Modena”, addetti: 1000]>– Oggetto di tipo stabilimento
20
39
Oggetti - identificatori
� 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
� Gli OID in genere non sono visibili agli utenti
40
Oggetti - identificatori : Esempio
� La persona “Mario Rossi”, residente in via Piave, è un oggetto
� può essere identificato dall’OID 417� se cambia indirizzo, il suo OID rimane 417
21
41
Oggetti – differenze tra identificatori e chiavi
� Immutabilita’– Una chiave (valore di uno o più attributi) può essere modificata– l'OID è invece immutabile
� Gestione– 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 � Unicita’
– Le chiavi sono uniche all'interno di una relazione – Gli OID sono unici all'interno dell'intero sistema
� Semplicita’ di gestione– Poiché gli oggetti sono riferiti in modo uniforme è più semplice gestire
collezioni di oggetti eterogenei (es. insieme di persone e di dipartimenti)
42
Oggetti - identità e uguaglianza
� Il concetto di OID introduce due tipi di uguaglianza tra oggetti: – identità (O1 = O2) se i due oggetti hanno lo stesso
OID – uguaglianza per valore se i due oggetti hanno lo
stesso valore� Shallow (O1 == O2): gli attributi corrispondenti sono
identici � Deep (O1 === O2): gli attributi corrispondenti sono uguali
(per valore)
22
43
Oggetti - Esempio
� O1 = <OID1, [a, 10, OID3]>� O2 = <OID2, [a, 10, OID4]>� O3 = <OID3, [a,b]>� O4 = <OID4, [a,b]>
� NOT O1 == O2� O1 === O2 � O3 == O4� O3 === O4
44
Oggetti - Esempio
NOT Articolo[i] == Articolo[k] NOT Autore[j] = Autore[h]Articolo[i] === Articolo[k] Autore[j] == Autore[h]
23
45
Oggetti e valori - differenze
� I sistemi in genere permettono di distinguere tra valori (anche complessi) e oggetti
� Tra valori atomici e oggetti le differenze sono nette� Tra valori complessi e oggetti, la differenza principale
e’ data dalla presenza di un identificatore per l’oggetto� Differenza 1
– i valori atomici sono astrazioni universalmente conosciute (stesso significato per ogni utente)� Ad esempio , il valore del numero 4 è universalmente noto, quindi
in ogni applicazione, 4 mantiene lo stesso significato– gli oggetti (ma anche i valori complessi) hanno un significato
che dipende dall’applicazione� la struttura dell’oggetto Articolo[i] dipende dall’applicazione
46
Oggetti e valori - differenze
� Differenza 2– I valori atomici sono built-in nel sistema
– gli oggetti (e i valori complessi) devono essere definiti
� Differenza 3– l’informazione rappresentata da un valore è se stesso
– l’informazione di un oggetto è rappresentata dalle relazioni conaltri oggetti e valori
� Differenza 4– i valori (atomici o complessi) sono utilizzati per descrivere altre
entità
– gli oggetti sono le entità che devono essere descritte
24
47
Oggetti- associazioni
� Le associazioni vengono rappresentate tramite riferimenti
� Il concetto di riferimento presenta analogie con quello di puntatorenei linguaggi di programmazione, e con quello di chiave esterna in un sistema relazionale. Tuttavia
– i puntatori possono essere corrotti (dangling, appesi);– i riferimenti a oggetti (in un buon ODBMS) vengono invalidati
automaticamente in caso di cancellazione di un oggetto referenziato– le chiavi esterne sono visibili, in quanto realizzate tramite valori; gli
identificatori d’oggetto non sono associati a valori visibili dall’utente– modificando gli attributi di una chiave esterna, è possibile perdere
riferimenti; modificando il valore di un oggetto referenziato, ilriferimento continua ad esistere
48
Oggetti – Associazioni : Esempio
25
49
Oggetti - Associazioni
� Modello relazionale:– value-based– le associazioni tra entità sono rappresentate per valore tramite chiavi
esterne– Bidirezionale– Necessita’ di dividere gli oggetti strutturati in piu’ tabelle
� Uso di join durante l’esecuzione di interrogazioni per ricomporre il valore
� Modello ad oggetti:– identity-based– tramite riferimenti tra oggetti (puntatori)– navigazione (direzionale) del riferimento – rappresentazione diretta di oggetti strutturati senza bisogno di
decomporli in unità più piccole (tuple o record) � ricerca e ricomposizione più veloce
50
Impiegati123 Mario Rossi … 3
Oggetti - Associazione: Esempio
Dipartimenti3 Ricerca …
Impiegato[i]
Imp#: 123 Nome:Mario
Cognome: Rossi …
Dip#: Dipartimento[j]
Dipartimento[i]
Dip#: 3 Nome:Ricerca
...
Chiave esterna
Riferimento tra oggetti
26
51
Tipi - Gerarchia di aggregazione
� Gerarchia tra tipi (vedremo poi anche tra classi)
� Se un tipo T compare nella definizione del dominio di un attributo A di un tipo T’, si dice che c’è una relazione di aggregazione (o clientship) tra T’ e T (indicato con T’ � T)
52
Tipi - Gerarchia di aggregazione
� La relazione di aggregazione puo’ essere:– Semplice , se A: T, cioe’ A e’ un valore di tipo T
� T’ � T– Complessa , se A ha tipo complesso definito su T. Per
esempio� A: set_of(T), A:tuple(…,T,…)� T’ � set_of(T)
– Semplice per riferimento , se A: *T, cioe’ A e’ un riferimentoad un oggetto di tipo T (contiene quindi il suo OID)� T’ �* T
– Complessa per riferimento , se A ha tipo complesso definitosu *T� T’ � set_of(*T)
27
53
Tipi - gerarchia di aggregazione
54
Tipi - gerarchia di aggregazione
� La gerarchia di aggregazione può contenere cicli
� Il dominio di un attributo può cioè essere la classe stessa
� Nell'esempio, l'attributo superiore della classe Impiegato ha come valori oggetti della stessa classe Impiegato
� I cicli possono ovviamente avere lunghezza arbitraria (cioè anche maggiore di uno)
28
55
Tipi dinamici - metodi
� Un metodo è un modulo (funzione o procedura) � E’ caratterizzato da due componenti
– Interfaccia (o segnatura) : comprende tutte le informazioni che permettono di invocare il metodo (nome del metodo, il nome (e i tipi) degli argomenti, ed eventualmente il tipo del risultato)
� definisce i messaggi cui l'oggetto risponde � descrive interazione dell'oggetto con il mondo esterno
– implementazione : codice del metodo, scritto in qualche linguaggio di programmazione (eventualmente esteso)
� Non visibile all’esterno� 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
� Il tipo specifica solo l’interfaccia del metodo
56
Metodi - classificazione
� Costruttori: per costruire oggetti a partire da parametridi ingresso (restituendo l’OID dell’oggetto costruito)
� Distruttori: per cancellare gli oggetti, ed eventuali altrioggetti ad essi collegati
� Accessori: funzioni che restituiscono informazioni sulcontenuto degli oggetti (proprietà derivate)
� Trasformatori: procedure che modificano lo stato deglioggetti, e di eventuali altri oggetti ad essi collegati
29
57
Metodi - esempio
automobile : record-of(targa: string, modello: string,costruttore: *costruttore,colore: string, prezzo: integer,partiMeccaniche: record-of(motore: string,ammortizzatore: string),public Init( // costruttore
targa_par: string,modello_par: string, colore_par: string,prezzo_par: integer): automobile,
public Prezzo(): integer, // accessorepublic Aumento( // trasformatore
ammontare: integer))
58
Metodi - esempio
� Se mia_auto e’ un oggetto di tipo automobile:– mia_auto.Aumento (300) aumenta il prezzo di
mia_auto di 300
30
59
Metodi - incapsulazione
� I metodi possono essere utilizzati per incapsulare lo stato di un oggetto
� Incapsulazione stretta– i valori degli attributi di un oggetto possono essere
letti e scritti solo tramite metodi accessori (getAttr) e trasformatori (setAttr)
– Si e’ forzati a scrivere molti metodi banali
� Incapsulazione non stretta– l’accesso ai valori degli attributi è diretto
60
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
31
61
Metodi – overloading
� Metodi con lo stesso nome possono esseredefiniti in tipi diversi
� Esempio– Oggetto Impiegato[i] con metodo aggiorna_stip(incr:
numeric)� aggiunge incr allo stipendio di Impiegato[i]
– Oggetto Manager[j] con metodo aggiorna_stip(incr: numeric)� moltiplica lo stipendio di Manager[j] per incr
62
Metodi – impedence mismatch
� 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 mismatchpresente 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
32
63
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 specifica lo scopo delle sue istanze
specificando: – Un tipo, che definisce la struttura, cioe’ un insieme di attributi,
e un’interfaccia per gli oggetti istanza della classe
– un insieme di implementazioni, per i metodi specificati nel tipo
� Le istanze (cioe’ gli oggetti) vengono creati utilizzando i metodi costruttori
64
Classi, tipi, interfacce
� 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
33
65
Classi, tipi, interfacce - differenze
� Tipo– É un concetto principalmente legato ai linguaggi di programmazione – fornisce la specifica di un insieme di oggetti o valori (e operazioni
invocabili su di essi) – è utilizzato a tempo di compilazione per controllare la correttezza dei
programmi � Classe
– Fornisce l'implementazione (stato + implementazione delle operazioni) per un insieme di oggetti dello stesso tipo
– fornisce primitive per la creazione di oggetti – è “first class object''
� Interfaccia– Fornisce la specifica del comportamento esterno di un insieme di
oggetti – può essere implementata da una classe – non può essere instanziata direttamente
66
Classi – gerarchia di aggregazione
� La gerarchia di aggregazione sui tipi induce una corrispondente gerarchia di aggregazionesulle classi
34
67
Classi - estensione
� In genere, la classe ha un significato intensionale� E’ un template che
– Permette di creare oggetti– Non corrisponde all’insieme di oggetti creati
� 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
68
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
� L’estensione automatica ha il vantaggio della semplicità
� L’estensione gestita dall'utente ha il vantaggio della flessibilità
35
69
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 l’estensione (insieme delle istanze)
70
Classi - estensione
� Nei sistemi con estensione non automatica l'utente mantiene generalmente l’estensione 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
36
71
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 RDBMS esistono comandi espliciti per inserire e rimuovere i dati nella/dalla base di dati (INSERT, DELETE)
� Nei OODBMS, sono possibili vari approcci
72
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
37
73
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
74
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
38
75
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: string, stipendio:numeric,
eta‘:integer)– class-attribute maxstipendio – class-method trova—il—piu'—ricco () � Persona
76
Classi - metodi di classe: costruttori
� Esempio comune di metodi di classe: costruttori (new)� Metodi invocati al momento della creazione di un
oggetto � il body consiste nell'inizializzazione degli attributi � Non hanno tipo di ritorno � é possibile definire più costruttori per ogni classe
(ovviamente con numero di argomenti diverso)
39
77
Ereditarietà
� L’ereditarietà è 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 sottoclasse 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)
78
Ereditarietà - esempio
� Si considerino i seguenti tipi di oggetti:
40
79
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
80
Ereditarietà - esempio (continua)
41
81
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
82
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
42
83
Ereditarietà - overriding
� Consideriamo un’applicazione che debba visualizzare oggetti di tipo camion e di tipo bus
� In un sistema relazionale, sarebbe necessario scrivere due procedure – display camion– display bus
84
Ereditarietà - overriding
� Nell'approccio ad oggetti: – si definisce una classe generale Veicolo– si definisce un'operazione display – in ogni sottoclasse si ridefinisce opportunamente
l'operazione display
– for x in X do x.display()
43
85
Ereditarietà - overloading
� Una conseguenza dell'overriding è che allo stesso nome di operazione corrispondono differenti implementazioni
– stesso nome usato per scopi diversi
– overloading
� Nell’esempio l'operazione display() ha almeno tre implementazioni differenti: veicolo, camion, bus
� L'overloading si può avere anche in assenza di ereditarietà (es. operazione =)
86
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
44
87
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à)
88
Ereditarietà - Method lookup: esempio
� Classe Veicolo con metodo display� Classe Camion, sottoclasse di Veicolo, ridefinisce
display� Nel codice:
– V: veicolo
– v.display� il tipo statico di v è Veicolo
– a run-time, a v può essere associato un Camion� il tipo dinamico di v è Camion
� si sceglie l’implementazione di display contenuta in Camion
45
89
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 ad Aerei, basta definire una nuova classe Aerei come sottoclasse di Veicoli
� Non si deve modificare né ricompilare il codice che effettua la visualizzazione degli oggetti
90
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)
46
91
Ereditarietà - ereditarietà multipla
� Permette ad una classe di avere più superclassi
92
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
47
93
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
94
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
48
95
Ereditarietà - diversi aspetti
� gerarchia di specializzazione (subtype hierarchy) – consistenza fra le specifiche dei tipi (sostituibilità)– comportamento degli oggetti come visto dall’esterno
� gerarchia di implementazione – condivisione del codice fra le classi
� gerarchia di classificazione – relazioni di inclusione tra collezioni di oggetti
96
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
49
97
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 ‘.’)
98
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
50
99
Accesso agli oggetti - nomi esterni
� i nomi esterni forniscono agli utenti riferimenti semanticamente significativi agli oggetti
� i nomi esterni permettono di definire entry pointnella base di dati: – oggetti per cui è possibile accesso diretto
100
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
51
101
Linguaggi di interrogazione
� Caratteristiche principali – uso di path expressions
� Progetto.capo.nome
– scope delle interrogazioni: � singola classe
� gerarchia di ereditarietà
– invocazione di metodiSelect all from Veicoliwhere prox_revisione() > 10/11/1999
102
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)