Modelli dei Dati e DBMS
di Nuova Generazione
+
Labo di Basi di dati II
Marco Mesiti
[email protected]
http://www.disi.unige.it/person/MesitiM/teach.html
1
Parte COMUNE
Organizzazione
dei corsi
• Modello dei dati ad oggetti
• Modelli dei dati relazionali ad oggetti
• Il modello relazionale ad oggetti di Oracle
• Le basi
di corsi
dati attive
particolare Oracle)
I due
sono (in
complementari
.
XML DBMS
Ha• senso
inserire sono uno dei due nel piano di studi
Modelli dei dati
•I sistemi di data warehouse
•Tecniche di data mining
•Regole di associazione
•Alberi di decisione
2
Basi di dati II
•Organizzazione dati su
memoria secondaria
•Strategie di elaborazione
delle interrogazioni
Organizzazione di ogni corso

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:
–
–
–
3
Approfondimento di uno degli argomenti visti a lezione
Progetto + Seminario
–
–
–

progettazione e sviluppo di una base di dati relazionale ad
oggetti su Oracle
2 compitini (o scritto)
Progetto + Seminario
orale obbligatorio solo in caso di sufficienza non piena (16-17)
o scarsa su determinati argomenti
Orario

Lunedi’:
–
–

Mercoledi’
–
–

4
13:30 – 14:30
14:45 – 16:00
11:00 – 12:00
12:15 – 13:30
Orario ricevimento: mercoledi’ 14:30 – 16:00
(ufficio Prof. Bertino)
Introduzione



5
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
Introduzione

Esempi di tali applicazioni sono:
–
–
–
–
–
–
–
–
6
(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
Introduzione

Tali nuove applicazioni possono essere
caratterizzate come data-intensive
programming in the large
–
–

7
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
Introduzione - requisiti nuove
applicazioni





Condivisione dei dati
Persistenza dei dati
Grandi quantità di dati
Affidabilità dei dati
Interoperabilità





8
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
Introduzione - Evoluzione dei
DBMS

DBMS orientati ad oggetti
–

DBMS relazionali estesi o relazionali ad oggetti
–

DBMS relazionali estesi con concetti ad oggetti
DBMS attivi
–
9
DBMS + programmazione orientata ad oggetti
DMBS + comportamento reattivo AI
Introduzione - Evoluzione dei
DBMS

Datawarehouse
–

Datamining
–

DBMS + documenti XML
DBMS deduttivi
–
10
DBMS + statistica
DBMS XML
–

DBMS + sistemi per il supporto alle decisioni
DBMS + programmazione logica
Basi di dati orientate ad oggetti
11
Introduzione - L’orientamento ad
oggetti

Object-orientation sempre più diffuso in ambito
software engineering e linguaggi di programmazione
–




12
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
Introduzione - Unicità del
paradigma

Nel tradizionale ciclo di vita del software si devono
superare diverse barriere ognuna delle quali comporta
problemi di comunicabilità
–

Nel ciclo di vita del software orientato ad oggetti le
varie fasi si basano su un unico modello
–
–
13
dal dominio del problema all'analisi (es. Data Flow Diagram),
alla programmazione (es. C) alle basi di dati (es.
ER+relazionali)
non si deve progettare separatamente la struttura della base di
dati
non si hanno problemi di comunicazione tra DBMS e
linguaggio di programmazione
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
–

14
sistemi eterogenei
Il paradigma ad oggetti, grazie all'incapsulazione,
permette di risolvere problemi di integrazione
Introduzione - Definizione di
OODBMS

Un OODBMS è un sistema con le funzionalità
e le caratteristiche di:
–
–

15
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
Introduzione - Funzionalità di un
OODBMS







16
object identity
oggetti complessi
incapsulazione
ereditarietà
overloading e late
binding
completezza
computazionale
estensibilità






Persistenza
condivisione
sicurezza
affidabilità
linguaggio di
interrogazione
efficienza
Introduzione - A chi è adatto un
OODBMS?

Organizzazioni che:
–
–
–
–
17
hanno necessità di tempi di sviluppo brevi
adottano programmazione ad oggetti
hanno necessità di condividere informazione
complessa
sviluppano sistemi intelligenti
Introduzione - Prodotti e prototipi








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 - Cenni storici

1986-1989:
–
–

1990:
–
–
–

primi OODBMS con funzionalità complete
architettura client/server, piattaforme comuni
es: Ontos, ObjectStore, Objectivity, Versant, Itasca, O2 ,
Zeitgeist
1991:
–
–
19
lancio dei primi linguaggi ad oggetti con persistenza (sistemi
standalone, non adottano piattaforme standard industriali)
es: GBase, GemStone, Vbase
–
nasce ODMG necessità di uno standard
1993,1997: ODMG93 e ODMG 2.0
1999: ODMG 3.0 object data management
Introduzione


20
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)
Introduzione

Caratteristiche fondamentali:
–
–
–
–

21
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)
Introduzione

Tali DBMS non hanno avuto il successo di mercato
sperato
–
–
–

22
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 …
Introduzione

Gli OODBMS forniscono persistenza a oggetti creati in
Java, C++, Smalltalk:
–


23
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
Allora perchè li studiamo?



24
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
Modelli dei dati ad oggetti Concetti di base





25
Oggetti ed identificatori di oggetti
 Oggetti complessi
Incapsulazione
Classi
Associazioni
Ereditarietà
Oggetti (riassunto caratteristiche)






26
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
Oggetti complessi



40
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
Oggetti complessi

Gli OODBMS forniscono:
–
–
–
–
41
tipi di dato strutturati
oggetti complessi
tipi di dato (ADT) specifici dell'applicazione
tipi di dato non strutturati es. binary large objects
(Blobs)
Oggetti complessi

Assemblati a partire da oggetti atomici
mediante costruttori
–
–
Oggetti atomici true, false, 25, ''this is an atom''
Costruttori





42
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
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

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
–

48
tali campi possono contenere riferimenti ad altri oggetti
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)



49
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
Esempio

Interfaccia:
–

aggiorna_stip(int incr)
Implementazione: quando il metodo viene
invocato su un oggetto “o”:

50
o.stipendio = o.stipendio + incr
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
–
–
51
definisce i messaggi cui l'oggetto risponde
descrive interazione dell'oggetto con il mondo
esterno
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


–
in OODBMS: un unico linguaggio, che permette di definire
operazioni mediante metodi associati agli oggetti

52
due linguaggi diversi
problemi di gestione codice
L'intera applicazione può quindi essere completamente scritta in
termini di oggetti
Incapsulazione - Metodi

Un metodo è invocato mandando un
messaggio ad un oggetto
–
o.aggiorna_stip(incr)


Mandando lo stesso messaggio a due oggetti
di due classi differenti questi possono esibire
comporatamenti differenti (vedi dopo)
–
53
mando il messaggio aggiorna_stip all’oggetto o
overloading: metodi con lo stesso nome ma
comportamento differente
Incapsulazione - Overloading:
esempio

Oggetto Impiegato[i] con metodo
aggiorna_stip(incr):
–

Oggetto Manager[j] con metodo
aggiorna_stip(incr):
–
54
aggiunge incr allo stipendio di Impiegato[i]
moltiplica lo stipendio di Manager[j] per incr
Incapsulazione e basi di dati

Incapsulazione stretta
–

Incapsulazione non stretta
–
55
i valori degli attributi di un oggetto possono essere
letti e scritti solo tramite metodi accessor (getAttr) e
mutator (setAttr)
l’accesso ai valori degli attributi è diretto
Incapsulazione e basi di dati

Metodi accessor:
–
restituiscono il valore associato ad un attributo di un
oggetto


Metodi mutator:
–
modificano il valore di un attributo di un oggetto


56
o.getStipendio: restituisce lo stipendio di un impiegato o
o.setStipendio(stip): lo stipendio di o diventa stip
si è forzati a scrivere molti metodi banali
Incapsulazione e basi di dati

Diversi approcci:
–
attributi possono essere acceduti (letti e scritti)
direttamente

–
si forza incapsulazione stretta

–
es. GemStone
si permette di specificare quali attributi possono
essere acceduti direttamente e quali no (attributi
pubblici e privati)

57
es. Orion
es. ODMG, O2, ObjectStore
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:
–
–
–
58
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
Classi - Esempio
Classe Impiegato
(
string nome,
int stipendio,
METHOD aggiorna_stip(int incr)
)
59
Classi - tipo, classe, interfaccia

Nel modello ad oggetti sono presenti diversi
concetti legati alla descrizione delle
caratteristiche di un insieme di oggetti:
–

60
tipo, classe, interfaccia
La separazione tra tali concetti è piuttosto
confusa e le differenze con cui i termini
vengono utilizzati varia da sistema a sistema
Classi - tipo



61
É 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
Classi - classe




62
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''
Classi - interfaccia



63
Fornisce la specifica del comportamento
esterno di un insieme di oggetti
può essere implementata da una classe
non può essere instanziata direttamente
Classi - persistenza degli oggetti

Persistenza degli oggetti significa:
–
–

oggetti transienti:
–
–

64
come gli oggetti sono inseriti nella base di dati
come gli oggetti sono rimossi dalla base di dati
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)
Classi - persistenza degli oggetti

Approcci per l’inserimento degli oggetti
–
persistenza automatica


–
radici di persistenza


65
ogni oggetto diventa automaticamente persistente quando
viene creato
non c'è bisogno di un comando di inserimento esplicito
gli oggetti creati sono transienti
per renderli persistenti bisogna assegnare loro un nome o
associarli, come componente ad un oggetto persistente
Classi - persistenza degli oggetti

Approcci per la cancellazione degli oggetti:
–
–

il secondo approccio assicura l'integrità referenziale,
ma necessita di un meccanismo di garbage collection
–
66
tramite un comando di cancellazione esplicito (es. Orion, Iris)
dal sistema quando non è più riferito da altri oggetti (es.
GemStone, O2)
il sistema deve supportare un algoritmo in grado di capire
quando un oggetto non è più riferito ed invocare tale algoritmo
periodicamente
Classi - persistenza degli oggetti


67
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
Classi - estensione



68
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
Classi -Estensione

Per creare gli oggetti, le classi supportano
sempre un metodo di creazione (new)
–

il metodo di creazione è un metodo di classe
–
69
new_persona(): crea un nuovo oggetto di classe
persona
si veda oltre
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:
–
–
–
73
class Persona (nome, stipendio, eta')
class-attribute maxstipendio
class-method trova—il—piu'—ricco () -> Persona
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

74
restituisce un nuovo oggetto istanza della classe Persona
Associazioni


Una associazione e’ un legame tra due classi
Simile al concetto di associazione del modello
ER
PROGETTO

75
CAPO
IMPIEGATO
Nel modello ad oggetti sono supportate solo
associazioni binarie
Associazioni: Rappresentazione in UML
Progetto
nome: String
Documenti
capo
progetto
76
Documento
titolo: String
stato: String
commento: ...
autori
Impiegato
nome: String
stipendio: Numbers
telefono: Numbers
superiore
Associazioni: Traversal path


77
Un’associazione del modello ad oggetti viene
dichiarata definendo una coppia di traversal
path, uno per ogni direzione di attraversamento
dell’associazione
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)
Associazioni: Traversal path


78
I traversal path quindi permettono di
specificare l’associazione 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 <tipo> <nome>
inverse <relazione>;
Associazioni: Esempio
BAR
BAR
BAR
79
serve
serve
servitaDA
BIRRA
BIRRA
BIRRA
Associazioni: Esempio
class Bar {
Il tipo dell’associazione serve
attribute string nome;
e’ un insieme di oggetti Birra.
attribute string indirizzo;
relationship Set<Birra> serve inverse Birra::servitaDa;
}
L’operatore :: lega il nome sulla
class Birra {
destra al contesto in cui si trova
attribute string nome;
tale nome, sulla sinistra
attribute string manuf;
relationship Set<Bar> servitaDa inverse Bar::serve;
}
80
Associazioni: Tipi

Il tipo di una associazioni puo’ essere:
1.
2.
3.
81
Una classe, (ad es. Bar). Un oggetto di Birra
puo’ essere associato a un solo oggetto di Bar.
Set<Bar>: l’oggetto e’ associato con un insieme
di oggetti di Bar.
Bag<Bar>, List<Bar>, Array<Bar>: l’oggetto e’
associato ad un bag, list, o array di oggetti di
Bar.
Associazioni: Molteplicita’



82
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 l’associazione dal lato “molti”
Associazioni “uno-a-uno” hanno classi come
tipo in entrambe le direzioni
Associazioni: Esempio di
moltiplicita’
class Bevitore { …
relationship Set<Birra> ama inverse Birra::fans;
relationship Birra birraTop inverse Birra::superfans;
}
Molti-a-molti usa Set<…>
class Birra { …
in entrambe le direzioni.
relationship Set<Bevitore> fans inverse Bevitore::ama;
relationship Set<Bevitore> superfans inverse
Drinker::birraTop;
}
Molti-a-uno usa Set<…>
solo dalla parte di “uno.”
83
Associazioni: Associazioni n-arie e
binarie con attributi

ODL non supporta:
–
–

84
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
l’associazione (eventualmente con i relativi
attributi).
Associazioni: Classi di
connessione



85
Si supponga di voler connettere le classi X, Y,
e Z attraverso l’associazione 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.
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
–


86
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.
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<BBP>.
87
Associazioni: Un altro esempio

Si supponga di avere le classi:
–
–
–


88
Progetto
Impiegato
Sede
E di voler rappresentare l’associazione 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 <p,i,s> che specifica che l’impiegato i e’
assegnato al progetto p nella sede s.
Associazioni: Implementazioni



Molti OODBMS non supportano direttamente le
associazioni
Le associazioni vengono modellate attraverso
attributi
In questi casi:
–
–
89
E’ possibile specificare una sola direzione di
attraversamento della associazione
Se vengono specificati entrambi gli attributi, non ho
garanzia della loro reciprocita’
Gerarchie di aggregazione


90
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
Associazioni: Esempio (ER)
data
titolo
numero istituzione
Rapporto
Tecnico
stato commento
nome
1..*
Progetto
1..*
1
documenti
Documento
rivista
data_pubbl
1..*
1
1..*
capo
Articolo
autore
nome stipendio
parti
0..*
partecipa
telefono
1..*
1
mesi_uomodata_in
1..*
data_fin
0..*
Impiegato
1..*
responsabile
1
91
Task
lavora
1
1..*
1
superiore
Associazioni: Esempio (UML)
Progetto
nome: String
1..*
1
Documenti
Documento
titolo: String
stato: String
commento: ...
1..*
1..*
1..*
capo
autori
tasks
1..*
progetto
1
92
Task
mesi_uomo: Number
data_in: Date
data_fin: Date
responsabile
tasks
1
1..*
Impiegato
nome: String
stipendio: Numbers
telefono: Numbers
1..*
1..*
1
superiore
Rapporto
Tecnico
istituzione:String
numero:Number
data: Date
Articolo
rivista: String
data_pubbl: Date
Associazioni: Esempio di
modellazione con attributi
93
Ereditarietà





94
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 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)
Ereditarietà - esempio

95
Si considerino i seguenti tipi di oggetti:
Ereditarietà - esempio (continua)




96
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
Ereditarietà - esempio (continua)
97
Ereditarietà - vantaggi




98
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
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
–
–
99
un tipo statico: tipo di cui è dichiarata
un tipo dinamico: classe più specifica dell'oggetto cui la
variabile è istanziata
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
–
10
0
display bitmap, display window, display impiegato
Ereditarietà - overriding
10
1
Ereditarietà - overriding

Nell'approccio ad oggetti:
–
–
–

10
2
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.
Ereditarietà - overloading

Una conseguenza dell'overriding è che allo stesso
nome di operazione corrispondono differenti
implementazioni
–
–


10
3
stesso nome usato per scopi diversi
overloading
Nell’esempio l'operazione display() ha almeno tre
implementazioni differenti in bitmap, window, impiegato
L'overloading si può avere anche in assenza di
ereditarietà (es. operazione =)
Ereditarietà - late binding



10
4
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
Ereditarietà - method lookup
(dispatching)



10
5
È 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à)
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)

–
a run-time, a p può essere associato un Manager

10
6
il tipo statico di p è Persona

il tipo dinamico di p è manager
si sceglie l’implementazione di aggiorna_stip contenuta in
Manager
Accesso agli oggetti

accesso navigazionale:
–
–
–

accesso associativo:
–
–

11
4
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
attraverso linguaggio di interrogazione
es. select nome from Impiegato where stipendio > 2000
accesso per nome:
–
–
tramite nomi esterni specificati dall'utente
es. MioDoc.titolo
Accesso agli oggetti - accesso
navigazionale



11
5
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 ‘.’)
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
–
11
6
più importante caratteristica che gli OODBMS ne
hanno ereditato
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:
–
11
7
oggetti per cui è possibile accesso diretto
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
–

11
8
Linguaggi di interrogazione

Caratteristiche principali
–
uso di path expressions

–
scope delle interrogazioni:


–
Progetto.capo.nome
singola classe
gerarchia di ereditarietà
invocazione di metodi
Select all from Veicoli
where prox_revisione() > 10/11/1999
11
9
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
–


12
0
es. chiusura del linguaggio di interrogazione
mancanza di base formale (algebra/calcolo ad oggetti)
nuove problematiche per l'ottimizzazione (metodi,
tecniche di indicizzazione specializzate)
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
+1991 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)
–

12
1
Lo standard ODMG - scopo del
consorzio



12
2
Sviluppare una serie di standard per favorire
portabilità, riusabilità e interoperabilità degli
OODBMS commerciali
successo dei RDBMS legato all’esistenza 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
ODMG - risultati

1993: ODMG 93 standard
–

1997: ODMG 2.0 standard
–

[R. Cattell et al., The Object Database Standard:
ODMG 2.0, MorganKaufmann, 1997]
1999: ODMG 3.0 standard
–
12
3
[R. Cattell, The Object Database Standard:
ODMG93, MorganKaufmann, 1993]
[R. Cattell et al., The Object Database Standard:
ODMG 3.0, MorganKaufmann, 1999]
ODMG - componenti




12
4
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
ODMG 3.0 ODL - Esempio
12
5
ODMG 3.0 ODL - Esempio
(continua)
12
6
ODMG 3.0 ODL - Esempio
(continua)
12
7
ODMG 3.0 - OQL


12
8
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 3.0 - 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 < Task >
12
9
ODMG 3.0 - 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
13
0

il risultato è un letterale di tipo set < date >
ODMG 3.0 - 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

13
1
il risultato è di tipo
set < struct(di : date; df : date) >
ODMG 3.0 - 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
13
2
Modello dei dati ad oggetti esempio di schema
13
3
Progettazione di schemi ad oggetti


13
4
Metodologie di progettazione ad oggetti (es.
UML)
La componente strutturale/statica (es. class
diagrams) non è molto diversa dai diagrammi
Entità-Relazione
Progettazione di schemi ad oggetti

Entità
–
–
–

insieme di entità
–
–
–
–
–
13
5
oggetto
Diverse modalità di identificazione (non è necessario introdurre codici se
non semanticamente significativi per l'applicazione)
Possibilità di rappresentare direttamente attributi multivalore e strutturati
classe (collezione)
attributi
metodi (non distinguiamo tra interfaccia e implementazione)
attributi complessi
Aggregazione/associazione