ODMG

L’ODMG L’Object Data Management Group è un consorzio di produttori di ODBMS che ha proposto uno standard per: il modello a oggetti il linguaggio di definizione dei dati (ODL) il linguaggio di interrogazione (OQL) i binding ai linguaggi di programmazione orientati a oggetti Vantaggi derivanti dalla definizione di uno standard: portabilità: un’applicazione sviluppata per un particolare sistema può essere eseguita , apportandovi poche modifiche, su un altro sistema Interoperabilità: un’applicazione può accedere a dati memorizzati su sistemi diversi Maggiore facilità nel confrontare sistemi diversi

Il modello ODMG: elementi base e costruttori Gli elementi base del modello sono: oggetti letterali I costruttori sono: struct (tupla) costruttori di collezioni: set<t>, bag<t> (multi insieme), list<t>, array<t>

Il modello ODMG: letterali un letterale ha un valore ma non ha un identificatore può avere una struttura semplice o complessa

Il modello ODMG: letterali Un valore letterale può essere: atomico (long,short,unsigned long, unsigned short,float,double,boolean,char,string,enum) strutturato possono essere predefiniti (es: Date) o definiti dall’utente mediante il costruttore struct di tipo collezione di oggetti o di valori

Il modello ODMG: oggetti un oggetto ha un identificatore (Object_ID) e può avere un nome un oggetto può essere persistente o transitorio un oggetto può essere atomico o di tipo collezione L’identificatore deve essere unico nel sistema. Il nome deve essere unico nella base di dati. Generalmente solo pochi oggetti (di tipo collezione) hanno un nome e cotituiscono punti di ingresso alla base di dati: una volta che si accede ad un oggetto tramite il nome è possibile reperire gli altri oggetti collegati ad esso

Il modello ODMG: oggetti oggetto atomico è ogni oggetto definito dall’utente che non sia di tipo collezione oggetto collezione

Il modello ODMG: oggetti atomici Un oggetto atomico: è specificato mediante il costrutto class può avere: proprietà (attributi e associazioni) operazioni Le proprietà definiscono lo stato dell’oggetto. Le operazioni descrivono il comportamento dell’oggetto. reparto impiegato

Il modello ODMG: oggetti atomici La specifica di un attributo è preceduta dalla parola attribute. Il valore di un attributo può essere: un letterale (semplice o complesso) l’Object_ID di un altro oggetto il risultato di un’operazione reparto impiegato

Il modello ODMG: oggetti atomici la specifica di un’associazione è preceduta dalla parola relationship. vengono rappresentate solo associazioni binarie per ogni relationship è definita l’inversa (preceduta dalla parola inverse) reparto impiegato

Il modello ODMG: oggetti atomici La specifica di un oggetto atomico può contenere segnature di operazioni. Una segnatura specifica: il nome dell’operazione (unico all’interno dell’oggetto) i tipi degli argomenti ed eventualmente: il tipo del risultato nomi di eccezioni reparto impiegato

Il modello ODMG: specifica di tipi Due costrutti per la specifica di tipi: class (specifica dello stato e del comportamento di un tipo di oggetto) interface (specifica del comportamento di un tipo di oggetto) e, corrispondentemente, due tipi di relazioni di ereditarietà.

Il modello ODMG: specifica di tipi Il costrutto class specifica stato comportamento di un tipo di oggetto. Una class è istanziabile: è possibile creare (mediante il costrutto extent nella specifica di una class) un oggetto di tipo set<t> (detto estensione della class) dove t è il tipo atomico specificato nella class. reparto impiegato

Il modello ODMG: specifica di tipi Il costrutto interface specifica solo il comportamento di un tipo di oggetto. Le proprietà (attributi e associazioni) di una interface non possono essere ereditate. Una interface non è istanziabile OggGeom

Il modello ODMG: ereditarietà Le interface vengono usate per specificare operazioni che possono essere ereditate da altre interface o class (ereditarietà di comportamento, rappresentata mediante “:”). Le class vengono usate per specificare proprietà e operazioni che possono essere ereditate da altre class (ereditarietà extends, rappresentata mediante la parola extends). Se a è l’estensione di una class A e b è l’estensione di una class B e A extends B allora a è un sottoinsieme di b. Una class può ereditare da una sola class, mentre può ereditare da molte interface (ereditarietà multipla).

Il modello ODMG: interface predefinite Object ereditata da tutti gli oggetti (copy,delete,same_as) Collection ereditata da tutti gli oggetti di tipo collezione (cardinality,is_empty,insert_element, remove_element,contains_element,create_iterator) Set, Bag, List, Array Iterator (reset,next_position,get_element) ObjectFactory (new)

Il modello ODMG: interface predefinite Database bind : per assegnare un nome ad un oggetto rendendolo \\ persistente lookup : per ricercare l’oggetto con un certo nome

Il linguaggio ODL Il linguaggio ODL consente di specificare i costrutti del modello ODMG indipendentemente dal linguaggio di programmazione. Il binding di un linguaggio di programmazione (C++, Java, Smalltalk) specifica come mappare i costrutti del modello ODMG in quelli del linguaggio.

Il linguaggio OQL E’ il linguaggio di interrogazione per il modello ODMG. Ha una sintassi simile a quello di SQL: select … from … where …

Il linguaggio OQL In ogni interrogazione è necessario un punto di ingresso alla base di dati, cioè un oggetto persistente avente un nome (tipicamente un’estensione, cioè una collezione di oggetti). Se il punto di ingresso è un’estensione occorre usare una variabile iteratore. Il risultato è di tipo bag o di tipo set se presente la clausola distinct.

Il linguaggio OQL select r.numero_r from r in reparti where r.nome_r = ‘giocattoli’ punto di ingresso: reparti variabile iteratore: r tipo risultato: bag<string> In generale il risultato di una select è di tipo bag, mentre il risultato di una select distinct è di tipo set reparto

Il linguaggio OQL Ogni oggetto avente un nome è un’interrogazione il cui risultato è un riferimento all’oggetto. reparti reparto_gioc

Il linguaggio OQL Per specificare il cammino da un punto di ingresso ai suoi attributi o ad oggetti ad esso correlati (mediante associazioni) si può usare una path expression. reparto_gioc.sedi (tipo risultato: set<string>) reparto_gioc.ha_imp (tipo risultato: set<Impiegato>) Una path expression può iniziare sia con il nome di un oggetto persistente sia con una variabile iteratore reparto

Il linguaggio OQL reparto_gioc.ha_imp.nome NO tipo risultato ambiguo: set<string> o bag<string>? reparto

Il linguaggio OQL select i.nome from i in reparto_gioc.ha_imp tipo risultato: bag<string> select distinct i.nome from i in reparto_gioc.ha_imp tipo risultato: set<string>

Il linguaggio OQL interrogazioni con risultato complesso select struct (direttore: r.dir_rep.direttore.nome, impiegati: (select struct (nome: i.nome età: i.età) from i in r.ha_imp) from r in reparti Per ogni reparto: il nome del direttore e nome ed età di ogni impiegato

class impiegato { extent impiegati key cod_fis } { attribute string nome; attribute string cod_fis; attribute date data_nasc; attribute enum genere(M,F) sesso; attribute short età; relationship reparto lavora_in inverse reparto::ha_imp; void riassegna_imp(in string nuovo_nome_r); raises(nome_r_non_valido)

class reparto { extent reparti key nome_r,numero_r } { attribute string nome_r; attribute string numero_r; attribute struct direz(impiegato direttore, date data_iniz) dir_rep; attribute set<string> sedi; attribute struct prog(string nome_p, time ore_settim) progetto; relationship set<impiegato> ha_imp inverse impiegato::lavora_in; void cambio_dir(in string nuovo_nome_dir; in date data_iniz);

interface OggettoGeometrico { attribute enum Forma(rettangolo,triangolo,cerchio) forma; attribute struct punto(short x, short y) punto_riferim; float perimetro(); float area(); void ruota(in float angolo); } class cerchio: OggettoGeometrico { extent cerchi } {attribute struct punto(short x, short y) punto_riferim; attribute short raggio;

class persona { extent persone key cof_fis } { attribute string nome; attribute string cod_fis; attribute date data_nasc; attribute enum genere(M,F) sesso; class impiegato extends persona { extent impiegati } { attribute short età; relationship reparto lavora_in inverse reparto::ha_imp; void riassegna_imp(in string nuovo_nome_r); raises(nome_r_non_valido)