OBJECT ORIENTED DATABASE

Presentazione sul tema: "OBJECT ORIENTED DATABASE"— Transcript della presentazione:

1 OBJECT ORIENTED DATABASE
introduzione

2 OGGETTO Ha due componenti:
stato: valore di alcune variabili (variabili di istanza) comportamento: insieme delle operazioni mediante le quali è possibile operare sull’oggetto Un oggetto è quindi simile ad una variabile di un programma (se è intera ha un valore intero e si può operare su di essa con le operazioni su interi +,-,*,/), ma può avere una struttura dati complessa operazioni specifiche definite dal programmatore

3 ODBMS vs OOPL oggetti persistenti
continuano ad esistere (su memoria di massa) anche dopo la terminazione del programma che li ha creati e possono essere condivisi da più programmi non completo incapsulamento degli oggetti le variabili di istanza sono visibili per consentire interrogazioni estemporanee Differenze tra il concetto di oggetto nei linguaggi di programmazione orientati agli oggetti e il concetto di oggetto nei sistemi di basi di dati orientati agli oggetti. Il non completo incapsulamento vuole evitare che si debba definire un’operazione ad hoc per ogni possibile interrogazione in quanto ci possono essere interrogazione che non sono prevedibili al momento in cui si progetta la base di dati. Grazie al non completo incapsulamento (attributi visibili e attributi nascosti) l’utente può specificare liberamente condizioni di selezione per ricuperare particolari oggetti. Tuttavia esistono sistemi che richiedono l’incapsulamento completo (si può accedere alle variabili di istanza solo attraverso le operazioni e le funzioni che definiscono il comportamento dell’oggetto)

4 ODBMS vs DBMS RELAZIONALI
Corrispondenza 1:1 tra oggetti reali e oggetti memorizzati: ad ogni oggetto è assegnato dal sistema un OID (object identifier) immutabile non riutilizzabile non visibile all’utente utilizzato dal sistema per creare e gestire associazioni tra oggetti IMMUTABILE: Nelle BD relazionali l’ identificazione avviene attraverso la chiave che può essere modificata dando luogo ad una tupla diversa dalla precedente anche se rappresenta lo stesso oggetto del mondo reale. Inoltre è possibile avere due chiavi per lo stesso oggetto (ad esempio uno studente può essere identificato sia dal suo numero di matricola che dal suo codice fiscale). Un OID può essere realizzato utilizzando l’indirizzo fisico dell’oggetto. Tale scelta, se da un lato permette un accesso rapido all’oggetto, crea problemi quando si sposta l’oggetto; inoltre contrasta con il requisito di “non riutizzabilità”. La scelta più comune è quello di realizzare un OID mediante un intero lungo e di utilizzare tabelle hash per recuperare l’indirizzo fisico dell’oggetto. Alcuni dei primi sistemi richiedevano che anche il singolo valore fosse rappresentato come un oggetto, ma questo porta ad una eccessiva proliferazione di oid.

5 ODBMS vs DBMS RELAZIONALI
Un oggetto può avere una struttura di complessità arbitraria Ad esempio è possibile definire un oggetto Reparto che “contiene” gli impiegati che lavorano nel reparto (nella definizione di reparto ci sarà un attributo che è un set di impiegati, rappresentati dai loro oid). Nel modello relazionale dovrei modellare questa situazione del mondo reale con due relazioni Reparto e Impiegato le cui tuple sono messe in relazione tramite la chiave di Reparto)

6 STATO DI UN OGGETTO Lo stato (valore) di un oggetto complesso è costruito a partire da altri oggetti/valori mediante costruttori di tipo (che possono essere annidati in modo arbitrario): Costruttore Stato dell’oggetto atomico un valore nel dominio base supportato dal sistema (intero, reale, ecc.) tupla <a1:i1,…,an:in> (coppie: attributo:oid) insieme {i1,…,in} multi insieme {i1,…,in}, ma ci possono essere ripetizioni lista (i1,…,in), c’è un ordinamento array (i1,…,in), ma c’è un limite al numero di elementi

7 COMPORTAMENTO DI UN OGGETTO
Il comportamento di un oggetto è definito dall’insieme di operazioni (creazione,distruzione,modifica,ricerca e altro) che possono essere applicate all’oggetto. Un’operazione è costituita da: segnatura (o interfaccia) nome e argomenti, visibile all’utente metodo implementazione, non visibile all’utente Nei sistemi orientati ad oggetti solo pochi vincoli di integrità sono predefiniti (es.: chiave). Generalmente i vincoli di integrità sono programmati all’interno dei metodi.

8 Vantaggi derivanti dall’incapsulamento
Possibilità di modificare sia la struttura interna di un oggetto sia l’implementazione della sue operazioni senza dover modificare i programmi che invocano tali operazioni (indipendenza dei dati e delle operazioni)

9 SPECIFICA DELLA PERSISTENZA
Ci sono due meccanismi per rendere persistente un ogetto: denominazione attribuire un nome unico persistente raggiungibilità rendere l’oggetto raggiungibile da oggetti persistenti

10 TIPO DI UN OGGETTO E’ definito da:
struttura (mediante costruttori di tipo si definisce l’insieme degli stati ammissibili per un oggetto) operazioni (mediante la segnatura) E’ identificato da un nome

11 ESTENSIONI La dichiarazione di una relazione in un DBMS relazionale definisce sia un tipo (schema della relazione) che un contenitore (l’istanza della relazione) di oggetti (tuple) di quel tipo. In un OODBMS occorre dichiarare esplicitamente un oggetto (estensione) il cui tipo è una collezione di oggetti dello stesso tipo.

12 GERARCHIE DI TIPI Un tipo può essere definito come sottotipo di un altro tipo (supertipo). Il sottotipo eredita struttura e operazioni del supertipo. Inoltre può avere ulteriori variabili di istanza e operazioni. I sistemi orientati ad oggetti consentono la definizione di tipi a partire da tipi già definiti conducendo ad una gerarchia di tipi.

13 POLIMORFISMO Un’ operazione può avere diverse implementazioni per diversi sottotipi di uno stesso tipo. La scelta dell’implementazione può essere fatta: a tempo di compilazione (binding statico) a tempo di esecuzione (binding dinamico)