Basi di dati a oggetti

Transcript

1 Basi di dati a oggetti Tecnologia delle basi di dati relazionali I sistemi di gestione di basi di dati relazionali (RDBMS) hanno permesso la realizzazione efficace ed efficiente di applicazioni di tipo gestionale, caratterizzate da persistenza, condivisione, affidabilità dati a struttura semplice, con dati di tipo numerico/simbolico transazioni concorrenti di breve durata (OLTP) interrogazioni complesse, espresse mediante linguaggi dichiarativi e con accesso di tipo associativo La rapida evoluzione tecnologica (miglioramento di prestazioni, capacità, e costi dell hardware) ha fatto emergere nuove esigenze applicative per le quali la tecnologia relazionale è inadeguata Alcune aree applicative emergenti Progettazione assistita da calcolatore CASE (Computer-Aided Software Engineering) CAD (Computer-Aided Design) CAM (Computer-Aided Manufacturing) Gestione di documenti testi e automazione d ufficio dati ipertestuali dati multimediali Altro scienza e medicina sistemi esperti, per la rappresentazione di conoscenza Caratteristiche delle nuove aree applicative Oltre alle caratteristiche consuete di persistenza, condivisione e affidabilità, possiamo individuare dati a struttura complessa dati non-numerici immagini, dati spaziali, sequenze temporali,... tipi pre-definiti e tipi definiti dall'utente (e riutilizzati) relazioni esplicite ("semantiche") tra i dati (riferimenti), aggregazioni complesse operazioni complesse specifiche per i diversi tipi di dato es. multimedia associate anche ai tipi definiti dall'utente transazioni di lunga durata Basi di dati a oggetti Tecnologia degli ODBMS Alcune delle precedenti caratteristiche suggeriscono l introduzione di nozioni dal paradigma orientato agli oggetti nel mondo delle basi di dati A partire dalla metà degli anni '80, sono stati realizzati numerosi sistemi di gestione di basi di dati a oggetti (ODBMS) di tipo prototipale o commerciale I sistemi sono stati sviluppati indipendentemente, senza nessuna standardizzazione circa il modello dei dati o i linguaggi da utilizzare Dopo un periodo di evoluzione, inizia ad esserci una convergenza su modello e linguaggio, per far sì che sistemi realizzati da produttori diversi possano almeno interoperare La prima generazione di ODBMS è composta dai linguaggi di programmazione a oggetti persistenti, che realizzano solo alcune caratteristiche delle basi di dati, senza supporto per l interrogazione, in modo incompatibile con gli RDBMS Gli ODBMS della seconda generazione realizzano un maggior numero di caratteristiche delle basi di dati, e generalmente forniscono un supporto all interrogazione Due tecnologie di ODBMS OODBMS (Object-Oriented): una tecnologia rivoluzionaria rispetto a quella degli RDBMS ORDBMS (Object-Relational): una tecnologia evolutiva rispetto a quella degli RDBMS

2 Un modello dei dati a oggetti Una base di dati a oggetti è una collezione di oggetti Ciascun oggetto ha un identificatore, uno stato, e un comportamento l identificatore (OID) garantisce l individuazione in modo univoco dell oggetto, e permette di realizzare riferimenti tra oggetti lo stato è l insieme dei valori assunti dalle proprietà dell oggetto è in generale un valore a struttura complessa il comportamento è descritto dall insieme dei metodi che possono essere applicati all oggetto Tipi parte statica Un tipo descrive le proprietà di un oggetto (la parte statica) e l interfaccia dei suoi metodi (la parte dinamica) Relativamente alla parte statica, i tipi vengono costruiti a partire da un insieme di tipi atomici numeri stringhe OID booleani tipi enumerativi... Per rappresentare il valore nullo si usa nil, un valore polimorfo Ogni definizione di tipo associa un nome (etichetta) a un tipo Tipi complessi Con i costruttori di tipo si definiscono tipi complessi I costruttori di tipo, tra loro ortogonali, sono: record-of(a 1 :T 1,..., A n :T n ) set-of(t) bag-of(t) list-of(t) Dato un tipo complesso T, un oggetto che ha per tipo T si dice istanza di T Non tutti i sistemi offrono tutti i costruttori Un esempio di tipo complesso Automobile: record-of( Targa: string, Modello: string, Costruttore: record-of( Nome: string, Presidente: string, Stabilimenti: set-of( record-of( Nome: string, Citta: string, Addetti: integer))), Colore: string, Prezzo: integer, PartiMeccaniche: record-of( Motore: string, Ammortizzatore: string)) Un esempio di valore complesso E possibile definire dei valori complessi compatibili con un tipo complesso V1: [Targa: DB123MS, Modello: Punto, Costruttore: [ Nome: FIAT, Presidente: Agnelli, Stabilimenti: { [Nome: Mirafiori, Citta: Torino, Addetti: 10000], [Nome: Trattori, Citta: Modena, Addetti: 1000]}], Colore: blu, Prezzo: 9500, PartiMeccaniche: [ Motore: 1100CC, Ammortizzatore: Monroe ]] Oggetti e valori L uso di tipi e valori complessi permette di associare ad un singolo oggetto una struttura qualunque Viceversa, nel modello relazionale alcuni concetti devono essere rappresentati tramite più relazioni Tuttavia, la rappresentazione proposta per Automobile non è "normalizzata": vediamo come decomporla utilizzando dei riferimenti tra oggetti Un oggetto è una coppia (OID, Valore), dove OID (object identifier) è un valore atomico definito dal sistema e trasparente all utente, e Valore è un valore complesso Il valore assunto da una proprietà di un oggetto può essere l OID di un altro oggetto (realizzando così un riferimento)

3 Riferimenti Automobile: record-of( Targa: string, Modello: string, Costruttore: *Costruttore, Colore: string, Prezzo: integer, PartiMeccaniche: record-of( Motore: string, Ammortizzatore: string)) Costruttore: record-of( Nome: string, Presidente: string, Stabilimenti: set-of(*stabilimento)) Stabilimento: record-of( Nome: string, Citta: string, Addetti: integer) Riferimenti Un insieme di oggetti compatibili con lo schema O1: <OID1, [Targa: DB123MS, Modello: Punto, Costruttore: OID2, Colore: blu, Prezzo: 9500, Motore: 1100CC, Ammortizzatore: Monroe ]> O2: <OID2, [Nome: Fiat, Presidente: Agnelli, Stabilimenti: {OID3,OID4}]> O3: <OID3, [Nome: Mirafiori, Citta: Torino, Addetti: 10000]> O4: <OID4, [Nome: Trattori, Citta: Modena, Addetti: 1000]> Identità e uguaglianza Tra gli oggetti sono definite le seguenti relazioni identità (O1=O2) richiede che gli oggetti abbiano lo stesso identificatore uguaglianza superficiale (O1==O2) richiede che gli oggetti abbiano lo stesso stato, cioè stesso valore per proprietà omologhe uguaglianza profonda (O1===O2) richiede che le proprietà che si ottengono seguendo i riferimenti abbiano gli stessi valori (non richiede l uguaglianza dello stato) O1 = <OID1, [a, 10, OID3]> O2 = <OID2, [a, 10, OID4]> O3 = <OID3, [a,b]> O4 = <OID4, [a,b]> Semantica dei riferimenti Il concetto di riferimento presenta analogie con quello di puntatore nei linguaggi di programmazione, e con quello di chiave esterna in un sistema relazionale. Tuttavia i puntatori possono essere corrotti (dangling, appesi); i riferimenti a oggetti (in un buon ODBMS) vengono invalidati automaticamente in caso di cancellazione di un oggetto referenziato le chiavi esterne sono visibili, in quanto realizzate tramite valori; gli identificatori d oggetto non sono associati a valori visibili dall utente modificando gli attributi di una chiave esterna, è possibile perdere riferimenti; modificando il valore di un oggetto referenziato, il riferimento continua ad esistere Classi Un modello dei dati a oggetti Gli oggetti sono associati a un tipo (intensione) e a una classe (implementazione) un tipo è una astrazione che permette di descrivere (1) lo stato e (2) il comportamento di un oggetto una classe descrive l implementazione di un tipo struttura dei dati e implementazione di metodi tramite programmi La definizione di una classe è normalmente separata in due parti L interfaccia descrive il tipo degli oggetti appartenenti alla classe e la segnatura di tutti i metodi L implementazione descrive il codice dei metodi e talvolta le strutture fisiche usate per la memorizzazione Gli oggetti vengono raggruppati in collezioni (estensioni) Faremo le seguenti ipotesi semplificative il concetto di classe descrive sia l implementazione sia l estensione di un tipo i tipi sono quindi astrazioni che descrivono sia lo stato che il comportamento In questo modello, quindi: tipi e classi sono distinti ogni classe è associata a un solo tipo non esiste un concetto apposito per l estensione

4 Classi ed estensioni I concetti di classe e di estensione non sono identici Una classe è una implementazione di un tipo significa che uno stesso tipo può avere implementazioni diverse. Questo è particolarmente importante non per assegnare semantiche diverse a oggetti di uno stesso tipo (assolutamente da evitare!), ma ad esempio per implementare una (unica) semantica di un tipo in riferimento a piattaforme architetturali diverse (nel caso di una base di dati a oggetti distribuita) Una estensione è una collezione di oggetti aventi lo stesso tipo; un oggetto può appartenere a più collezioni, essere rimosso da una collezione, ecc. Metodi parte dinamica Il paradigma OO deriva dal concetto di tipo di dato astratto Un metodo è una procedura utilizzata per incapsulare lo stato di un oggetto, ed è caratterizzato da una interfaccia (o segnatura) e una implementazione l interfaccia comprende tutte le informazioni che permettono di invocare un metodo (il tipo dei parametri) l implementazione contiene il codice del metodo Il tipo di un oggetto comprende, oltre alle proprietà, anche le interfacce dei metodi applicabili a oggetti di quel tipo Ipotizziamo che i metodi siano assimilabili a funzioni, ovvero possono avere più parametri di ingresso ma un solo parametro di uscita Metodi Metodi In prima approssimazione, i metodi possono essere dei seguenti tipi costruttori per costruire oggetti a partire da parametri di ingresso (restituendo l OID dell oggetto costruito) distruttori per cancellare gli oggetti, ed eventuali altri oggetti ad essi collegati accessori funzioni che restituiscono informazioni sul contenuto degli oggetti (proprietà derivate) trasformatori procedure che modificano lo stato degli oggetti, e di eventuali altri oggetti ad essi collegati Un metodo può essere pubblico o privato add method Init( // Costruttore Targa_par: string, Modello_par: string, Colore_par: string, Prezzo_par: integer): Automobile in class Automobile is public; add method Prezzo(): integer // accessore in class Automobile is public; add method public Aumento( // trasformatore Ammontare: integer)) // void in class Automobile is public; Classi estensioni dei tipi Abbiamo ipotizzato che una classe raccolga tutti gli oggetti di uno stesso tipo Una classe è un contenitore di oggetti, che possono essere dinamicamente aggiunti o tolti alla classe (tramite costruttori e distruttori) Ad una classe è associato un solo tipo, quindi gli oggetti in una classe sono tra loro omogenei (hanno le stesse proprietà e rispondono agli stessi metodi) Una classe definisce anche l implementazione dei metodi, che va specificata in qualche linguaggio di programmazione Implementazione e invocazione di metodi Ref<Automobile> Automobile::init (string Targa_par, string Modello_par, string Colore_par, integer Prezzo_par) { self->targa = Targa_par; self->modello = Modello_par; self->colore = Colore_par; self->prezzo = Prezzo_par; return(self); } Ref<Automobile> X; //dichiarazione di variabile X = new(automobile); X -> init( Mi56T778, Panda, blu, 7000);

5 Implementazione e invocazione di metodi void Automobile::Aumento(integer Ammontare) { self->prezzo += Ammontare; } Ref<Automobile> X; X = new(automobile); (X -> Init( Mi56T778, Panda, blu, 7000)) -> Aumento(1200); Mismatch (o disaccoppiamento) di impedenza In un RDBMS, esiste un mismatch di impedenza tra i linguaggi con i quali vengono scritte le applicazioni (che manipolano variabili scalari) e l SQL, che estrae insiemi di ennuple. Il problema viene risolto usando i cursori Si dice che gli ODBMS risolvono questo problema, in quanto gli oggetti persistenti possono essere manipolati direttamente tramite le istruzioni del linguaggio di programmazione (procedurale) Il PL di un ODBMS deve permettere l accesso alle componenti di un valore complesso ad esempio, i record con l operatore dot., i riferimenti con l operatore ->, le collezioni con opportuni iteratori Criteri di progettazione dei metodi E importante sfruttare le potenzialità per il riuso che l approccio object-oriented offre La metodologia OMT (Object Modeling Technique) propone le seguenti linee guida per la definizione dei metodi brevità coerenza (una sola funzione) e consistenza (stile comune) separazione tra politica e implementazione anticipazione dei requisiti futuri autonomia ereditarietà Gerarchie di ereditarietà Tra i tipi (e le classi) di una base di dati a oggetti, è possibile definire una gerarchia di ereditarietà Una sotto-classe eredita lo stato e il comportamento della super-classe e può, in aggiunta, rendere più specifici lo stato e il comportamento Tutti gli oggetti delle sotto-classi appartengono automaticamente alle sopra-classi Vale la proprietà transitiva: se C1 è sotto-classe di C2 e C2 è sotto-classe di C3, implica che C1 è sotto-classe di C3 Esempio di gerarchia add class AutoSportiva inherits Automobile type tuple(maxvelocita:integer, Pilota:Persona) add class AutoStorica inherits Automobile type tuple(annocostr:integer) Ref<AutoStorica> X; X = new(autostorica); X->init( MI56543, Ferrari, rossa,150000); X->AnnoCostr = 1957;

6 Considerazioni sulle gerarchie Il ruolo della gerarchia di ereditarietà è lo stesso dei linguaggi di programmazione orientati agli oggetti Esiste tuttavia una importante differenza: gli oggetti di un programma sono oggetti di breve durata, gli oggetti di una base di dati sono oggetti di lunga durata, con conseguenze non banali Migrazione tra classi Nel corso della propria esistenza, un oggetto deve mantenere la propria identità, in modo che sia possibile riferirsi ad esso in modo univoco Tuttavia, è possibile che un oggetto cambi tipo: una persona diviene uno studente, poi uno studente lavoratore, poi un lavoratore, poi una persona sposata,... Sembra quindi necessario un meccanismo di acquisizione e perdita di tipi, normalmente tramite operazioni di specializzazione (si diventa membri di una sotto-classe) generalizzazione (si perde l appartenenza a una sotto-classe) Alcuni sistemi richiedono che un oggetto appartenga a una sola classe più specializzata, altri non pongono questo vincolo Ereditarietà multipla In alcuni sistemi è possibile che una classe erediti da più super-classi Esempio: add class AutoSportivaStorica inherits AutoSportiva, AutoStorica type tuple(garestorichevinte:set(string)) Ogni esemplare di AutoSportivaStorica appartiene sia ad AutoSportiva che ad AutoStorica Ci possono essere oggetti che appartengono sia ad AutoSportiva sia ad AutoStorica, ma che non appartengono ad AutoSportivaStorica Conflitti L ereditarietà multipla può generare conflitti di nome, qualora due o più sopra-classi posseggano proprietà o metodi con lo stesso nome Possibili soluzioni non consentire definizioni con conflitti definire dei meccanismi per la risoluzione del conflitto (es., ordinamento statico o valutazione dinamica) ridefinizione locale di proprietà e metodi Persistenza Gli oggetti possono essere temporanei (come nei programmi tradizionali) o persistenti. La persistenza può essere specificata in vari modi (non sempre tutti disponibili in uno stesso sistema): inserimento in una classe persistente raggiungibilità da oggetti persistenti (garantisce l integrità referenziale, ma richiede un garbage collector) "denominazione": si può definire un nome ("handle") per un oggetto Ridefinizione dei metodi L overriding consiste nel ridefinire il corpo di un metodo nell ambito di una sotto-classe (es., il metodo display) Si hanno quindi diverse versioni dello stesso metodo (overloading) La scelta del metodo da invocare dipende dalla classe cui appartiene l oggetto; se la classe non è nota al momento della compilazione, è necessario effettuare il late binding

7 Ridefinizione dei metodi con raffinamenti di tipo La modifica dell interfaccia dei metodi richiede una certa attenzione Se si ridefinisce un metodo in una sotto-classe, i suoi parametri possono essere definiti in due modi co-variante: i parametri sono sotto-tipi dei parametri della sopra-classe contro-variante: i parametri sono sopra-tipi dei parametri della sopra-classe La soluzione co-variante è più diffusa, ma crea dei problemi nei parametri d ingresso Definizione co-variante add class Programmatore inherits Utente add class File method init(nome:string,owner:utente) add class Sorgente inherits File... method init(nome:string,owner:programmatore) Non è possibile garantire a compile-time che l invocazione del metodo su File sia corretta (il file può essere un Sorgente, ma il parametro Owner passato non è un Programmatore) Il manifesto delle basi di dati a oggetti (Atkinson, Bancilhon, DeWitt, Dittrich, Maier, Zdonik) Una lista di funzionalità per la definizione (e la valutazione) di OODBMS. Include: Funzionalità obbligatorie (the "golden rules") Funzionalità opzionali Scelte aperte Le Golden Rules Thou shalt support complex objects Thou shalt support object identity Thou shalt encapsulate thine objects Thou shalt support types or classes Thine classes or types shalt inherit from their ancestors Thou shalt not bynd prematurely Thou shalt be computationally complete Thou shalt be extensible Thou shalt remember thy data Thou shalt manage very large databases Thou shalt accept concurrent users Thou shalt recover from hardware and software failures Thou shalt have a simple way of querying data Funzionalità obbligatorie Oggetti complessi Identità di oggetto Incapsulamento Tipi e/o classi Gerarchie di classi o di tipi Overriding, overloading e late binding Completezza computazionale Estensibilità Persistenza Gestione della memoria secondaria Concorrenza Recovery Linguaggio o interfaccia di interrogazione Funzionalita' quasi (?) obbligatorie ("no consensus") Dati derivati e definizione di viste Funzionalità DBA Vincoli di integrità Funzionalità per la modifica di schemi

8 Funzionalità opzionali Ereditarietà multipla Verifica dei tipi ed inferenza su di essi Distribuzione "Design transactions" (transazioni lunghe e nidificate) Gestione delle versioni Scelte libere Paradigma di programmazione Realizzazione Sistema di tipi Uniformità Object Database Management Group e ODMG-93 ODMG è composto da partecipanti di tipo accademico e industriale, ed in particolare i principali produttori di OODBMS. ODMG-93 è una proposta di standard per OODBMS, che i partecipanti intendono realizzare o supportare un modello a oggetti ODL, un linguaggio di definizione basato su IDL (OMG) OQL, un linguaggio di interrogazione, basato su SQL3 Language bindings per C++, Smalltalk e Java ODMG-93 non è uno standard formale né una specifica di OODBMS Un esempio di schema ODL interface Automobile ( extent Automobili key Targa ) { attribute String Targa; attribute String Modello; attribute String Colore; attribute String Prezzo; attribute Structure PartiMeccaniche {String Motore, String Ammortizzatore}; relationship <Costruttore> Costruttore inverse Costruttore::Costruisce; Automobile init(in String Targa_par, in String Modello_par, in String Colore_par, in String Prezzo_par); void Aumento(in Integer Ammontare) raises(prezzoeccessivo);} interface AutoSportiva: Automobile { attribute Integer MaxVelocita } Il modello ODMG-93 Le proprietà e le operazioni di un tipo sono chiamate caratteristiche E possibile definire una gerarchia di tipi, alcuni dei quali sono astratti (non istanziabili) L estensione di un tipo è l insieme di tutte le sue istanze Un tipo ha una o più implementazioni (classi) ad esempio, una classe può richiedere di implementare una proprietà di tipo Set come Set_as_Btree Alcuni oggetti possono avere un nome, per riferirsi ad essi esplicitamente nei programmi altri possono essere identificati mediante interrogazioni OQL Object Query Language Linguaggio SQL-like per basi di dati a oggetti, inizialmente sviluppato per O2, adottato (con modifiche) da ODMG, basato sui seguenti principi non è computazionalmente completo, ma può invocare metodi, e i metodi possono includere interrogazioni permette un accesso dichiarativo agli oggetti si basa sul modello ODMG ha una sintassi astratta ed almeno una sintassi concreta, simile a SQL ha primitive di alto livello per le collezioni non ha operatori di aggiornamento può essere ottimizzato in quanto dichiarativo

9 Interrogazioni OQL OQL permette di interrogare interattivamente oggetti, partendo dai loro nomi Alternativamente, comandi OQL possono essere immersi in un linguaggio di programmazione utilizzandoli come argomenti (di tipo String) di metodi che li eseguono e ne restituiscono il risultato Interrogazioni OQL Facciamo riferimento ad uno schema con tipi Impiegato (Nome, Nascita:(Citta, Data), Stipendio, Subordinati, Età(), AssegnaSubordinato(...)) con estensione Impiegati Dipartimento (NomeDip, Sedi:{(NomeSede, CittaSede)}, Direttore) con estensione Dipartimenti Un impiegato è designato come Presidente Schema di lavoro typedef Struct Nascita_t { attribute String Citta; attribute Date Data }; interface Impiegato ( extent Impiegati keys Nome ) { attribute String Nome; attribute Nascita_t Nascita; attribute Integer Stipendio; relationship Set<Impiegato> Subordinati; // inversa opzionale Integer Eta (); Void AssegnaSubordinato (in Impiegato Sub); }; typedef Struct Sede_t { attribute String NomeSede; attribute String CittaSede }; interface Dipartimento ( extent Dipartimenti ) { attribute String NomeDip; attribute Set<sede_t> Sedi; relationship Impiegato Direttore; Void AssegnaDirettore (in Impiegato Dir); }; Impiegato Presidente; // un oggetto con un nome simbolico OQL per esempi (1) Seleziona il presidente Presidente Seleziona i subordinati del presidente Presidente.Subordinati Seleziona gli stipendi degli impiegati di nome Pat select distinct X.Stipendio from X in Impiegati where X.Nome = Pat Seleziona nome e età degli impiegati di nome Pat select distinct struct(n: X.Nome, E: X.Eta()) from X in Impiegati where X.Nome = Pat OQL per esempi (2) Attraversamento di una relazione select struct (Dip: X.NomeDip, Dir: X.Direttore.Nome) from X in Dipartimenti Dovrebbe essere equivalente a select struct (Dip: X.NomeDip, Dir: Y.Nome) from X in Dipartimenti, Y in Impiegati where X.Direttore = Y E possibile definire valori a struttura complessa struct(e: 36, Nome: Pat ) E possibile creare nuovi oggetti Impiegato(Nome: Pat,...) OQL per esempi (3) Per ciascun impiegato, seleziona il nome e l insieme dei subordinati con stipendio maggiore di select distinct struct(nome: X.Nome, Spp: ( select Y from Y in X.Subordinati where Y.Stipendio > )) from X in Impiegati La clausola select può comparire anche entro la clausola from select struct(n: X.Nome, E: X.Eta()) from X in ( select Y from Y in Impiegati where Y.Stipendio > ) where X.Nome = Pat

10 OQL per esempi (4) Creazione di viste e accesso a un attributo composto define Romani as select X from X in Impiegati where X.Nascita.Citta = Roma Appartenenza select X.Eta() from X in Impiegati where X in Romani Quantificatori (queste sono query booleane) for all X in Impiegati: X.Stipendio > exists X in Impiegati: X.Eta() < 19 OQL per esempi (5) Subordinati di subordinati select distinct struct(imp: X, Subsub: Y) from X in Impiegati, Z in X.Subordinati, Y in Z.Subordinati Conversione di tipologia di collezione listtoset(list(1,2,3,2)) Restituisce la lista degli impiegati, ordinata per nome sort X in Impiegati by X.Nome OQL per esempi (6) Partiziona gli impiegati in base allo stipendio group X in Impiegati by ( Low: X.Stipendio < 1000, Mid: X.Stipendio >= 1000 and X.Stipendio < 5000), High: X.Stipendio >= 5000) Questa espressione ha tipo set<struct(low: boolean, Mid: boolean, High: boolean, partition: set<impiegato>)> Una versione estesa dell operatore group permette il calcolo di funzioni aggregate The Third Generation Database System Manifesto (Stonebraker, Rowe, Lindsay, Gray, Carey, Brodie, Bernstein, Beech) Una risposta al manifesto OODMS "I DBMS della prossima generazione dovranno essere ottenuti come risultato dell'evoluzione dei DBMS esistenti (relazionali)" I principi del contro-manifesto I DBMS di terza generazione dovranno essere una generalizzazione (compatibile) con DBMS della seconda generazione Oltre a fornire i servizi tradizionali di gestione dei dati, dovranno permettere la definizione di oggetti complessi e regole Dovranno essere aperti ad altri sottosistemi Manifesto 3GDBMS: dettagli [1.1] rich type system [1.2] inheritance [1.3] functions and encapsulation [1.4] OID's only if there are no keys [1.5] rules and triggers [2.1] non procedural, high level access languages [2.2] specification techniques for collections [2.3] updatable views [2.4] transparency of physical parameters [3.1] multiple high level languages [3.2] persistent x, for many x's [3.3] SQL is a standard (even if you don't like it) [3.4] queries and their results are the lowest level of communication

11 Basi di dati Object-Relational Modello dei dati Linguaggio di interrogazione SQL:1999 è la versione più recente di SQL (SQL-3 è il nome informale) Si tratta di una estensione compatibile di SQL-2 il codice SQL-2 è valido anche come SQL:1999 Modello dei dati di SQL:1999 È possibile definire tipi: tipi ennupla, con struttura anche complessa e con gerarchie: utilizzabili per definire tabelle con lo stesso schema utilizzabili come componenti utilizzabili nell ambito di relationship tipi astratti Tipi ennupla create type TipoPersona (Nome varchar (30), Residenza varchar(30), CodFisc char(16)) not final ref from CodFisc create table Persona of type TipoPersona ( ref is CodFisc derived) Le ennuple sono gli oggetti Le relazioni le classi Gli identificatori possono essere manipolabili Si possono usare riferimenti e/o incorporare oggetti Tipi ennupla create type TipoStab( Nome varchar (25), Citta varchar (7), Addetti integer) not final create type TipoCostr( Nome varchar (25), Presidente ref(tipopersona), Stabilimenti TipoStab array[10]) create type TipoPartiAuto( Motore char(10), Ammortizzatore char(5)) not final create type TipoAuto( Targa char(7), Modello varchar (30), Costruttore ref(tipocostr), PartiMeccaniche TipoPartiAuto) not final ref is system generated Tipi ennupla create table Automobile of type TipoAuto ( ref is AutoId system generated) create table Costruttore of type TipoCostr ( ref is CostrId system generated, Presidente with options scope Industriale references are checked) create type TipoAutoStorica( AnnoCostr integer) under TipoAuto not final create table AutomobileStorica of type TipoAutoStorica under Automobile Alternativamente (ma con tipo non riutilizzabile ): create table AutomobileStorica( AnnoCostr integer) under Automobile Metodi e funzioni E possibile associare funzioni, definite in SQL:1999 o in linguaggi esterni create type TipoPartiAuto ( Motore char(10), NumCilindri integer, Potenza integer, Cilindrata integer ) not instantiable not final method PotUnitaria() returns float, method DisegnoDisponibile ( ) returns boolean language C

12 Interrogazioni in SQL:1999 Le interrogazioni SQL-2 sono completamente ammesse in SQL:1999 Inoltre: si possono seguire i riferimenti si possono citare gli OID (se visibili) si può accedere alle strutture interne Interrogazioni in SQL:1999 select Nome from Persona where CodFisc = TRESFN56D23S541S select Costruttore -> Presidente -> Nome from Automobile where Targa = DB123MS select Industriale.Nome from Automobile, Costruttore, Industriale where Automobile.Targa = DB123MS and Automobile.Costruttore = Costruttore.CostrId and Costruttore.Presidente = Industriale.CodFisc Basi di dati multimediali Tipi di dati multimediali Immagini: diversi formati, compressi o meno; grandi dimensioni Audio: si rappresenta il campionamento del segnale audio; anche utilizzando tecniche di compressione, si devono gestire grandi dimensioni Video: Sequenza di immagini (frame); rispetto ai tipi precedenti, dimensioni ancora più elevate Documenti: testi, con eventualmente immagini, con un grado di ricchezza strutturale variabile Annotazioni: informazioni semi-strutturate normalmente associate ai documenti Interrogazioni su dati multimediali Le query devono spesso integrare due diversi aspetti condizioni sulla parte strutturata delle informazioni (es., il valore di un campo delle schede che accompagnano un documento) condizioni di somiglianza, che richiedono tecniche specifiche e producono normalmente risultati di tipo probabilistico (un oggetto multimediale soddisfa un certo criterio di similarità con una certa probabilità) Sono utili tecniche adattative, che permettono di guidare gli utenti nella ricerca Ricerca di documenti La ricerca all interno di testi è il caso più tipico di query su dati multimediali (es., i motori di ricerca) Tecniche tipiche esclusione di parole irrilevanti riduzione a parole chiave (stem) considerazione delle frequenze delle parole La realizzazione deve essere fatta ad hoc per ogni linguaggio naturale Due misure della ricerca precisione: percentuale di documenti rilevanti tra quelli estratti richiamo: percentuale di documenti rilevanti estratti rispetto a quelli rilevanti presenti nella base di dati Tecniche fisiche: matrici, indici invertiti, segnature,... Rappresentazione dei dati spaziali I GIS (Geographical Information System) sono sistemi specifici per la gestione di informazioni geografiche e spaziali Problema principale è la scelta di una struttura dati che permetta di rispondere in modo efficiente alle query Le strutture 2d-tree e quad-tree costruiscono una rappresentazione ad albero di punti nello spazio che permette la gestione efficiente di query spaziali

13 2d-tree quad-tree Tecnologia delle basi di dati a oggetti La realizzazione di sistemi di gestione di basi di dati a oggetti solleva un insieme di problemi tecnologici specifici Alcune di queste problematiche rappresentazione dei dati e degli identificatori indici complessi architettura client-server modello transazionale architettura a oggetti distribuiti Rappresentazione dei dati Possiamo pensare a rappresentazioni relazionali di una base di dati a oggetti facendo riferimento a gerarchie di classi approccio orizzontale ogni oggetto viene rappresentato in modo contiguo entro la classe più specifica di appartenenza approccio verticale gli oggetti sono suddivisi nelle proprie componenti (proprietà), le quali sono memorizzate contiguamente L approccio orizzontale favorisce l accesso agli oggetti nel loro complesso, l approccio verticale la ricerca di oggetti sulla base di una loro proprietà I BLOB sono rappresentati su file specifici Rappresentazione degli identificatori Esistono diversi approcci per la rappresentazione degli OID mediante indirizzo fisico, ovvero riferimento alla memoria di massa mediante surrogato, cioè un valore simbolico associato univocamente ad un oggetto. L accesso all oggetto avviene mediante strutture di accesso Nel caso (frequente) di oggetti distribuiti su più sistemi, bisogna garantire l univocità degli identificatori Indici complessi I linguaggi di accesso prevedono l uso di path expressions, per navigare la struttura degli oggetti e accedere oggetti a essi collegati Gli operatori. e -> sono utilizzati per accedere le proprietà di un tipo record, per seguire riferimenti, e talvolta per accedere le componenti di una collezione select x.subordinati.subordinati.citta_nascita from x in Impiegati Sui cammini più utilizzati, deve essere possibile definire degli indici, che consentano un accesso in avanti (determina le città di nascita dei sub-subordinati) oppure in indietro (trova i sup-superiori dei nati a Milano) Meccanismi di indicizzazione per tipi di dato specifici (dati multimediali, spaziali, sequenze temporali)

14 Architettura client-server Modello transazionale Nel mondo relazionale, il paradigma client-server è abbastanza ben compreso, ed il problema maggiore è determinare come suddividere la logica applicativa tra client e server Nei sistemi a oggetti, un meccanismo possibile è quello di delegare al server le operazioni di check-out e check-in degli oggetti, importando gli oggetti sul client e manipolandoli localmente In generale, esistono delle nuove problematiche ad esempio, se un client richiede gli oggetti che soddisfano un predicato implementato da un metodo, l esecuzione del metodo entro l interrogazione deve essere eseguita dal client o dal server? Applicazioni orientate alla progettazione richiedono modelli transazionali più complessi che non quelli basati sul locking transazioni di lunga durata (minuti, ore, o anche giorni) transazioni complesse: transazioni nidificate saga: transazioni con transazioni compensatrici Idee utilizzate check-out e check-in di oggetti versioni di oggetti, versioni di collezioni di oggetti, versioni dello schema degli oggetti Architettura a oggetti distribuiti Architetture a oggetti distribuiti: CORBA, DCOM di Microsoft (ActiveX, ex OLE, ex OCX), Enterprise Java Beans di Sun/IBM,... CORBA è l acronimo di Common Object Request Broker Architecture, proposta di standard dell OMG (Object Management Group) con lo scopo di garantire l interoperabilità di oggetti distribuiti mediante un ORB (Object Request Broker) L ORB è un bus software per oggetti distribuito, responsabile della comunicazione tra oggetti In generale, gli scopi di un ODBMS e di un ORB sono diversi, e ciascuno può offrire servizi all altro CORBA Ciascun oggetto ha una interfaccia (in un linguaggio comune, IDL), una implementazione (in un qualsiasi linguaggio), e risiede su un nodo del sistema Un client può invocare un metodo di un oggetto in modo statico, facendo riferimento all interfaccia dell oggetto. L invocazione avviene con un meccanismo simile al Remote Procedure Call (RPC), basato su un linking di tipo statico con lo stub dell oggetto Questo meccanismo rende trasparente la distribuzione dell oggetto, l effettiva allocazione, la selezione dell oggetto, la conversione di formato dei parametri L invocazione dei metodi degli oggetti può essere anche di tipo dinamico Remote Procedure Call Architettura CORBA

15 Architettura CORBA L adattatore degli oggetti offre servizi per registrare oggetti e implementazioni, e per accedere alle implementazioni degli oggetti L architettura è basata su quattro componenti principali l ORB servizi degli oggetti alcune funzionalità (standard) di base per gli oggetti (es., gestione della sicurezza, della persistenza e delle transazioni) servizi comuni alcuni servizi opzionali per i clienti, orientati all uso degli oggetti (e.g., interfacce utenti) gli oggetti applicativi definiti dall utente per l applicazione