ODMG

1. ODMG

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

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

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

5. 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 costruttorestruct • di tipo collezione di oggetti o di valori

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

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

8. Il modello ODMG: oggetti atomici Un oggetto atomico: • è specificato mediante il costrutto class • può avere: • proprietà (attributi e associazioni) • operazioni

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

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

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

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

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

14. 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 interfacenon èistanziabile

15. 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 dauna sola class, mentre può ereditare da molte interface(ereditarietà multipla).

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

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

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

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

20. Il linguaggio OQL select r.numero_r from r in reparti wherer.nome_r = ‘giocattoli’ punto di ingresso: reparti variabile iteratore: r tipo risultato: bag<string>

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

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

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

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

25. Il linguaggio OQLinterrogazioni 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

26. class impiegato { extent impiegati key cof_fis } { attributestring nome; attributestring cod_fis; attributedate 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) }

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

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

29. class persona { extent persone key cof_fis } { attributestring nome; attributestring cod_fis; attributedate 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) }