Basi di dati: evoluzioni recenti Organizzazione corso Introduzione



Scaricare 471 b.
02.06.2018
Dimensione del file471 b.


Basi di dati: evoluzioni recenti


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

  • Problematiche di analisi dei dati

    • i sistemi di data warehousing
    • il data mining


Organizzazione corso

  • Progetto

    • progettazione e sviluppo di una base di dati relazionale ad oggetti su Oracle
    • 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


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



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


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



Introduzione - requisiti nuove applicazioni

  • Condivisione dei dati

  • Persistenza dei dati

  • Grandi quantità di dati

  • Affidabilità dei dati

  • Interoperabilità



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 deduttivi

    • DBMS + programmazione logica
  • Sistemi di Data Warehousing



Basi di dati orientate ad oggetti



Introduzione - L’orientamento ad oggetti

  • Object-orientation sempre più diffuso in ambito software engineering e linguaggi di programmazione

  • 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à

    • 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


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



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



Introduzione - Funzionalità di un OODBMS

  • object identity

  • oggetti complessi

  • incapsulazione

  • ereditarietà

  • overloading e late binding

  • completezza computazionale

  • estensibilità



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


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)



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


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)



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)



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 …



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



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



Modelli dei dati ad oggetti - Concetti di base

  • Oggetti ed identificatori di oggetti

  • Oggetti complessi

  • Incapsulazione

  • Classi

  • Ereditarietà



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



Oggetti ed identificatori - Identità : 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



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



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)



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


Oggetti ed identificatori - OID e chiavi: Esempio



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


Oggetti ed identificatori - Esempio di oggetti uguali ma non identici



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



Oggetti ed identificatori - Condivisione di oggetti: esempio



Oggetti ed identificatori - Condivisione di oggetti: esempio



Oggetti ed identificatori - Condivisione di oggetti: esempio



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


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



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)


Oggetti complessi

  • Assemblati a partire da oggetti atomici mediante costruttori

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



Oggetti complessi - Esempio



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 dall’applicazione
  • Il valore del numero 4 è universalmente noto

    • in ogni applicazione, 4 mantiene lo stesso significato
  • la struttura dell’oggetto Articolo[i] dipende dall’applicazione



Oggetti complessi - Oggetti e valori

  • I valori sono built-in nel sistema

  • gli oggetti devono essere definiti

  • l’informazione rappresentata da un valore è se stesso

  • l’informazione 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



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


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


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


Incapsulazione - Componenti di un oggetto

  • In un OODBMS i dati e le operazioni su di essi sono incapsulati in un'unica struttura (l'oggetto)

  • Un oggetto consiste quindi di:

    • un OID, o identificatore
    • uno stato, o valore, costituito dai valori per un certo numero di attributi, o campi
      • tali campi possono contenere riferimenti ad altri oggetti
    • un comportamento costituito da un insieme di metodi o operazioni
  • l’accesso ad un attributo “a” o metodo “m” di un oggetto “o” si indica con la seguente path expression:

    • o.a
    • o.m


Incapsulazione - Metodi

  • La definizione di un metodo consiste di due componenti:

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



Esempio

  • Interfaccia:

    • aggiorna_stip(int incr)
  • Implementazione: quando il metodo viene invocato su un oggetto “o”:

      • 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

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


Incapsulazione - Metodi

  • Un metodo è invocato mandando un messaggio ad un oggetto

    • o.aggiorna_stip(incr)
      • mando il messaggio aggiorna_stip all’oggetto o
  • Mandando lo stesso messaggio a due oggetti di due classi differenti questi possono esibire comporatamenti differenti

    • overloading: metodi con lo stesso nome ma comportamento differente


Incapsulazione - Overloading: esempio

  • Oggetto Impiegato[i] con metodo aggiorna_stip(incr):

    • aggiunge incr allo stipendio di Impiegato[i]
  • Oggetto Manager[j] con metodo aggiorna_stip(incr):

    • moltiplica lo stipendio di Manager[j] per incr


Incapsulazione e basi di dati

  • Incapsulazione stretta

    • i valori degli attributi di un oggetto possono essere letti e scritti solo tramite metodi accessor (getAttr) e mutator (setAttr)
  • Incapsulazione non stretta

    • l’accesso ai valori degli attributi è diretto


Incapsulazione e basi di dati

  • Metodi accessor:

    • restituiscono il valore associato ad un attributo di un oggetto
      • getStipendio(o): restituisce lo stipendio di un impiegato o
  • Metodi mutator:

    • modificano il valore di un attributo di un oggetto
      • setStipendio(o,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
      • 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


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:

    • 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(impiegato self, int incr)

  • )



Classi - tipo, classe, interfaccia

  • Nel modello ad oggetti sono presenti diversi concetti legati alla descrizione delle caratteristiche di un insieme di oggetti:

  • La separazione tra tali concetti è piuttosto confusa e le differenze con cui i termini vengono utilizzati varia da sistema a sistema



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



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



Classi - interfaccia

  • Fornisce la specifica del comportamento esterno di un insieme di oggetti

  • può essere implementata da una classe

  • non può essere instanziata direttamente



Classi - Gerarchia di aggregazione

  • Per ogni attributo viene in genere specificato un dominio, che specifica il tipo dei possibili valori dell'attributo

  • La definizione di una classe include la specifica dei domini degli 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



Classi - gerarchia di aggregazione



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



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)



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


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


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



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



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


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à



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)



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


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 trova—il—piu'—ricco () -> Persona


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 ed il nome coincide con quello della classe

  • é possibile definire più costruttori per ogni classe (ovviamente con numero di argomenti diverso)



Esempio

  • Classe Persona

  • costruttore: new_persona -> Persona

    • restituisce un nuovo oggetto istanza della classe Persona


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

  • Si considerino i seguenti tipi di oggetti:



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



Ereditarietà - esempio (continua)



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



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


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


Ereditarietà - overriding



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


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 in bitmap, window, impiegato

  • L'overloading si può avere anche in assenza di ereditarietà (es. operazione =)



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



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



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 l’implementazione di aggiorna_stip contenuta in Manager


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



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)


Ereditarietà - ereditarietà multipla

  • Permette ad una classe di avere più superclassi



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


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


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


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


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


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 ‘.’)



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


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


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



Linguaggi di interrogazione

  • Caratteristiche principali

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


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)



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)



Lo standard ODMG - scopo del consorzio

  • 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

    • [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]


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)

  • Language Bindings, per C++, Smalltalk, Java



ODMG 3.0 ODL - Esempio



ODMG 3.0 ODL - Esempio (continua)



ODMG 3.0 ODL - Esempio (continua)



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



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 >


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


Modello dei dati ad oggetti - esempio di schema



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

  • Noi utilizzeremo una meta-notazione



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


Progettazione di schemi OO - differenze con relazionale

  • Associazioni tra dati

    • direzionalità dei riferimenti
    • non tutti gli OODBMS supportano le associazioni in modo esplicito
    • aggregazione rappresenta un caso particolare di associazione
    • mancano comunque associazioni n-arie e associazioni con attributi (rappresentate in genere tramite classi)
  • generalizzazione

    • ereditarietà






©astratto.info 2017
invia messaggio

    Pagina principale