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

1
Modelli dei Dati e DBMS di Nuova
GenerazioneLabo di Basi di dati II

• Marco Mesiti
• mesiti_at_disi.unige.it
• http//www.disi.unige.it/person/MesitiM/teach.html

2
Organizzazione dei corsi
I due corsi sono complementari. Ha senso
inserire sono uno dei due nel piano di studi
3
Organizzazione di ogni corso

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

4
Orario

• Lunedi
• 1330 1430
• 1445 1600
• Mercoledi
• 1100 1200
• 1215 1330
• Orario ricevimento mercoledi 1430 1600
  (ufficio Prof. Bertino)

5
Introduzione

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

6
Introduzione

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

7
Introduzione

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

8
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
Introduzione - Evoluzione dei DBMS

• DBMS orientati ad oggetti
• DBMS programmazione orientata ad oggetti
• DBMS relazionali estesi o relazionali ad oggetti
• DBMS relazionali estesi con concetti ad oggetti
• DBMS attivi
• DMBS comportamento reattivo AI

10
Introduzione - Evoluzione dei DBMS

• Datawarehouse
• DBMS sistemi per il supporto alle decisioni
• Datamining
• DBMS statistica
• DBMS XML
• DBMS documenti XML
• DBMS deduttivi
• DBMS programmazione logica

11
Basi di dati orientate ad oggetti
12
Introduzione - 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
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. ERrelazionali)
• Nel ciclo di vita del software orientato ad
  oggetti le varie fasi si basano su un unico
  modello
• non si deve progettare separatamente la struttura
  della base di dati
• non si hanno problemi di comunicazione tra DBMS e
  linguaggio di programmazione

14
Introduzione - Integrazione di sistemi eterogenei

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

15
Introduzione - Definizione di OODBMS

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

16
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
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
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
Introduzione - Cenni storici

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

20
Introduzione

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

21
Introduzione

• Caratteristiche fondamentali
• ricchezza di strutture dati
• classi e tipi definiti 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
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
Introduzione

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

24
Allora perchè li studiamo?

• Storicamente importanti
• ci permettono di capire meglio i concetti alla
  base dei sistemi relazionali ad oggetti
• semplici da capire SE è nota la programmazione
  ad oggetti

25
Modelli dei dati ad oggetti - Concetti di base

• Oggetti ed identificatori di oggetti
• Oggetti complessi
• Incapsulazione
• Classi
• Associazioni
• Ereditarietà

26
Oggetti (riassunto caratteristiche)

• Entita del mondo reale contraddistinte da un
  identificatore (OID)
• 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
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
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
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
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
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
Oggetti ed identificatori - OID e chiavi Esempio
Chiave esterna
Impiegati 123 Mario Rossi 3
Dipartimenti 3 Ricerca
Riferimento tra oggetti
Impiegatoi Imp 123 NomeMario Cognome
Rossi Dip Dipartimentoj
Dipartimentoi Dip 3 NomeRicerca ...
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
Oggetti ed identificatori - Esempio di oggetti
uguali ma non identici
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
Oggetti ed identificatori - Condivisione di
oggetti esempio
37
Oggetti ed identificatori - Condivisione di
oggetti esempio
38
Oggetti ed identificatori - Condivisione di
oggetti esempio
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
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
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
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 lt125, 220, 321gt
• list 25, 20, 21
• possono a loro volta essere componenti di altri
  oggetti

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 Articoloi dipende
  dallapplicazione

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

• Interfaccia
• aggiorna_stip(int incr)
• Implementazione quando il metodo viene invocato
  su un oggetto o
• o.stipendio o.stipendio incr

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
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
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
Incapsulazione - Overloading esempio

• Oggetto Impiegatoi con metodo
  aggiorna_stip(incr)
• aggiunge incr allo stipendio di Impiegatoi
• Oggetto Managerj con metodo aggiorna_stip(incr)
  
• moltiplica lo stipendio di Managerj per incr

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
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
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
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
Classi - Esempio

• Classe Impiegato
• (
• string nome,
• int stipendio,
• METHOD aggiorna_stip(int incr)
• )

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
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
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
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
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
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
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
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
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
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
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
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
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
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 () -gt Persona

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 -gt Persona
• restituisce un nuovo oggetto istanza della classe
  Persona

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

PROGETTO
IMPIEGATO
CAPO
76
Associazioni Rappresentazione in UML
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
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 lttipogt ltnomegt
• inverse ltrelazionegt

79
Associazioni Esempio
80
Associazioni Esempio

• class Bar
• attribute string nome
• attribute string indirizzo
• relationship SetltBirragt serve inverse
  BirraservitaDa
• class Birra
• attribute string nome
• attribute string manuf
• relationship SetltBargt servitaDa inverse
  Barserve

81
Associazioni Tipi

• Il tipo di una associazioni puo essere
• Una classe, (ad es. Bar). Un oggetto di Birra
  puo essere associato a un solo oggetto di Bar.
• SetltBargt loggetto e associato con un insieme
  di oggetti di Bar.
• BagltBargt, ListltBargt, ArrayltBargt loggetto e
  associato ad un bag, list, o array di oggetti di
  Bar.

82
Associazioni Molteplicita

• Associazioni molti-a-molti hanno Setltgt come
  tipo della associazione e della sua inversa
• Associazioni molti-a-uno hanno Setltgt 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
Associazioni Esempio di moltiplicita

• class Bevitore
• relationship SetltBirragt ama inverse Birrafans
• relationship Birra birraTop inverse
  Birrasuperfans
• class Birra
• relationship SetltBevitoregt fans inverse
  Bevitoreama
• relationship SetltBevitoregt superfans inverse
  DrinkerbirraTop

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
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
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
Associazioni Esempio di classe di collegamento

• class BBP
• attribute prezzoreal
• relationship Bar ilBar inverse BaraBBP
• relationship Birra laBirra inverse BirraaBBP
• Bar e Beer devono essere modificate per contenere
  la relazione aBBP di tipo SetltBBPgt.

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 ltp,i,sgt che specifica che limpiegato
  i e assegnato al progetto p nella sede s.

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
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
Associazioni Esempio (ER)
92
Associazioni Esempio (UML)
93
Associazioni Esempio di modellazione con
attributi
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
Ereditarietà - esempio

• Si considerino i seguenti tipi di oggetti

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
Ereditarietà - esempio (continua)
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
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
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
Ereditarietà - overriding
102
Ereditarietà - overriding

• 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
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
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
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
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
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
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
Ereditarietà - ereditarietà multipla

• Permette ad una classe di avere più superclassi

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
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
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
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
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 gt
  2000
• accesso per nome
• tramite nomi esterni specificati dall'utente
• es. MioDoc.titolo

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
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
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
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
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() gt 10/11/1999

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
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 ATT, Digital, NCR, Bull, IBM, Olivetti
  
• ODMG (Object Database Management Group) è uno
  dei working group di OMG, che consiste dei
  maggiori produttori di OODBMS (circa il 90 del
  mercato)

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
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
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
ODMG 3.0 ODL - Esempio
126
ODMG 3.0 ODL - Esempio (continua)
127
ODMG 3.0 ODL - Esempio (continua)
128
ODMG 3.0 - OQL

• 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

129
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 gt 20 and
• t.responsabile.stipendio gt 2000
• il risultato è di tipo bag lt Task gt

130
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 gt 20
• il risultato è un letterale di tipo set lt date gt

131
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 gt 20
• il risultato è di tipo
• set lt struct(di date df date) gt

132
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

133
Modello dei dati ad oggetti - esempio di schema
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
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