4- basi di dati Object Oriented Limiti delle basi di dati relazionali



Scaricare 445 b.
26.01.2018
Dimensione del file445 b.


4- Basi di dati Object Oriented


Limiti 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à, costi dell’hardware, ecc.) ha fatto emergere, fin dalla metà degli anni '80, nuove aree applicative (CASE, CAD, CAM, Gestione Documentale, ecc.)— per le quali la tecnologia relazionale è inadeguata.



Esempi di nuove applicazioni

  • un archivio di 40.000 fotografie, con didascalie, coordinate geografiche ed esigenze di interrogazioni complesse:

    • – "trova le foto con un tramonto scattate a Roma o dintorni"
  • • archivio sinistri di una compagnia assicurativa (con foto, grafici, luogo) finalizzato alla ricerca delle frodi

  • • archivio del personale con informazioni sul curriculum, foto, residenza per una gestione integrata ( riconoscimento, valutazione delle competenze, proposta di "car-pool")

  • • gestione di "codici parlanti" (ad esempio il codice fiscale)



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

  • Alcune delle precedenti caratteristiche suggeriscono l'utilità di introdurre, nel mondo delle basi di dati, idee proprie del paradigma orientato agli oggetti.

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



Tecnologia degli ODBMS

  • 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 evoluzionaria rispetto a quella degli RDBMS


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


Modello di dati a oggetti e modello relazionale

  • Due differenze fondamentali

    • struttura complessa:
      • • nidificata
      • • con identificatori gestiti dal sistema
    • comportamento


Tipi — Parte statica:schema

  • Un tipo descrive le proprietà di un oggetto - la parte statica e l’interfaccia dei suoi metodi - la parte dinamica

  • parte statica: i tipi vengono costruiti a partire da

    • – un insieme di tipi atomici (numeri, stringhe, ...)
    • – un insieme di costruttori di tipo, tra loro ortogonali
      • record-of(A1:T1, ..., An:Tn)
      • set-of(T), bag-of(T), list-of(T)
    • – un riferimento ad altro tipo definito nello schema è considerato un tipo, utilizzato per rappresentare relazioni tra oggetti (associazioni)


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



Tipi e valori complessi

  • 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 il tipo Automobile non è "normalizzata“ cioè presenta ridondanze: per ogni oggetto automobile, per esempio, ripetiamo il costruttore con tutte le informazioni:

    • Vediamo come decomporla utilizzando riferimenti tra tipi di oggetti.


Riferimenti nello schema

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



Valori e OID

  • 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 conforme al tipo dell’oggetto

  • Il valore assunto da una proprietà di un oggetto può essere l’OID di un altro oggetto realizzando così un riferimento.



Riferimenti tra oggetti

  • Un insieme di oggetti compatibili con lo schema

  • O1:

  • Costruttore: OID2, Colore: “blu”,

  • Prezzo: 9500, Motore: “1100CC”,

  • Ammortizzatore: “Monroe”]>

  • O2:

  • Stabilimenti: {OID3,OID4}]>

  • O3:

  • Addetti: 10000]>

  • O4:

  • 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 infatti, nel caso in esame, è OID3  OID4)
      • O1 =
      • O2 =
      • O3 =
      • O4 =


Esempio schema ad oggetti



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 i valori degli attributi di una chiave esterna, è possibile perdere riferimenti; modificando il valore di un oggetto referenziato, il riferimento continua ad esistere


Tipi — Parte dinamica : metodi

  • 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

  • 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



Esempio metodi

  • automobile: record-of(

  • targa: string, modello: string,

  • costruttore: *costruttore,

  • colore: string, prezzo: integer,

  • partiMeccaniche: record-of(

  • motore: string,

  • ammortizzatore: string),

  • public Init( // costruttore

  • targa_par: string,

  • modello_par: string, colore_par: string,

  • prezzo_par: integer): automobile,

  • public Prezzo(): integer, // accessore

  • public Aumento( // trasformatore

  • ammontare: integer)) // void



Classi — estensioni dei tipi

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

  • Due alternative:

    • una classe raccoglie tutti gli oggetti di uno stesso tipo
    • più classi possono avere lo stesso tipo
  • Una classe definisce anche l’implementazione dei metodi, che va specificata in qualche linguaggio di programmazione



Implementazione e invocazione di metodi

  • body Init(targa_par: string, modello_par: string,

  • colore_par: string, prezzo_par: integer):

  • automobile in class automobile

  • co2{

  • self->targa = targa_par;

  • self->modello = modello_par;

  • self->colore = colore_par;

  • self->prezzo = prezzo_par;

  • return(self);

  • }$

  • execute co2{ // in un programma

  • o2 automobile X; // dich. di variabile O2

  • X = new(automobile);

  • [X Init(“Mi56T778”, “Panda”, “blu”, 12M)]; }$



Disadattamento di impedenza

  • In un RDBMS, esiste un “disadattamento (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. Si usano allo scopo 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 linguaggio di programmazione 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.



Altre caratteristiche del paradigma ad oggetti

  • Tra i tipi (e le classi) di una base di dati a oggetti, è possibile definire una gerarchia di ereditarietà, con le usuali relazioni di sottotipo, l’ereditarietà dei metodi, la possibilità di overloading, overriding, late binding, ereditarietà multipla, ...

  • Tutto funziona come nei linguaggi di programmazione 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)


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.


The O-O Database Manifesto (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


Funzionalità obbligatorie “The golden rules”

  • 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



The 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



Funzionalita' quasi obbligatorie ("no consensus")

  • Dati derivati e definizione di viste

  • Funzionalità DBA

  • Vincoli di integrità

  • Funzionalità per la modifica di schemi



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 (standard ISO)
    • 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

  • 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


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



Un esempio ODL-OQL



Interfaccia Film



Interfaccia Attore



Interfaccia Studio



Espressioni di cammino

  • Se p è un attributo allora o.p è il valore di tale attributo per l’oggetto o

    • Es: miofilm.lunghezza
  • Se p è un’associazione allora o.p è l’oggetto o collezione di oggetti con cui o è in associazione attraverso p

    • Es: miofilm.attori
  • Se p è un metodo allora o.p è il risultato dell’applicazione di p ad o

    • Es : miofilm.lunghezza_in_ore()
    • Es: miofilm.nomiAttori(mieiAttori)


Select...From...Where... (Sintassi)

  • La parola chiave SELECT seguita da una lista di espressioni

  • La parola chiave FROM seguita da una lista di una o più dichiarazioni di variabili. Una variabile è specificata con:

      • Un’espressione il cui valore è di tipo collezione (set, bag,…)
      • La parola chiave opzionale as
      • Il nome della variabile
  • La parola chiave WHERE seguita da un’espressione boolean. Usa le variabili e/o costanti dichiarate nella clausola FROM.



Select...From...Where...(Semantica)

  • L’interrogazione produce in uscita un bag di oggetti

  • Il bag è calcolato per tutti i possibili valori delle variabili nel FROM in cicli annidati.

  • Se una qualsiasi delle combinazioni di valori per queste variabili soddisfa la condizione della clausola WHERE allora l’oggetto descritto nella clausola SELECT è aggiunto al BAG.

  • Nell’esempio:

  • SELECT f.anno

  • FROM Films f

  • WHERE f.titolo =“Via col vento”

  • SEMANTICA

    • FOR EACH f IN FILMS DO
    • IF f. titolo = “Via col vento”
    • ADD f.anno TO output_bag


Select...From...Where... in OQL

  • Query: Ritrovare il nome degli attori del film “Casablanca”.

  • SELECT a.nome

  • FROM Films f , f.attori a

  • WHERE f.titolo= “Casablanca”

  • SEMANTICA

  • FOR EACH f IN Films DO

  • FOR EACH a IN f.attori DO

  • IF f. titolo = “Casablanca” THEN

  • ADD a.nome TO output_bag.



Eliminazione di duplicati

  • Query: Cerca i nomi degli attori di Film della “Disney”.

  • SELECT DISTINCT a.nome

  • FROM Films f, f.attori a

  • WHERE f.possedutoDa.nome=“Disney”.



Tipi di output complessi

  • Query: Coppie di attori che vivono allo stesso indirizzo:

  • SELECT DISTINCT Struct(attore1:a1, attore2:a2)

  • FROM Attori a1, Attori a2

  • WHERE a1.indirizzo=a2.indirizzo AND a1.nome

    • l’ordine di comparsa degli attori nella coppia non interessa (cioè si tratta della stessa coppia che va pertanto eliminata).
    • tipo del risultato: SET ( Struct N  attore1:Attore,attore2:Attore)


Sotto-interrogazioni

  • Query: Trova gli attori dei film di DISNEY

  • SELECT DISTINCT a.nome

  • FROM(SELECT f

  • FROM FILMS f

  • WHERE f.posseduto_da.nome=“Disney”) d,

  • d.attori a

  • La clausola FROM contiene due cicli annidati:

  • nel primo la variabile d varia su tutti i film della “Disney”

  • nel secondo la variabile a varia su tutti gli attori del film d.



Ordinamento del risultato

  • Il risultato di questa interrogazione è una lista di oggetti della classe (extend) Films ordinata per:

    • Lunghezza del film
    • Titolo del film
  • come in SQL l’ordine, per default è crescente:

      • SELECT f
      • FROM Films f
      • WHERE f.posseduto_da.nome=“Disney”
      • ORDER BY f.lunghezza, f.titolo


Operatori insiemistici

  • UNION per ; INTERSECT per ; EXCEPT per

  • Producono BAG a meno che non sia espressamente indicato il DISTINCT

          • (SELECT DISTINCT f
          • FROM Films f, f.attori a
          • WHERE a.nome= “Harrison Ford”)
          • EXCEPT
          • (SELECT DISTINCT f
          • FROM Films f
          • WHERE f.possedutoDa.nome=“Disney”)
  • in questo caso il tipo del risultato è: SET < Film>



Espressioni di aggregazione

  • COUNT: Può essere applicato a qualsiasi collezione

  • SUM e AVG: Applicabile a collezioni di

  • tipi aritmetici come interi

  • MIN e MAX : Collezioni qualsiasi i cui

  • valori possono essere confrontati

  • AVG(

  • SELECT f. lunghezza

  • FROM Films f

  • )

  • La sottointerrogazione estrae le componenti lunghezza dai Films. Il risultato è il bag delle lunghezze.

  • A tale bag viene applicato l’operatore AVG che restituisce la lunghezza media di tutti i films.



Espressioni con quantificatori

  • E’ possibile controllare se tutti ( o almeno uno) i membri di un insieme soddisfano una condizione.

  • Posto:

      • x: variabile
      • S: insieme
      • C(x) condizione sulla variabile
    • FOR ALL x in S : C(x)
      • True se ogni xS soddisfa C(x), False altrimenti
    • EXISTS x in S : C(x)
      • True se almeno un x S soddisfa C(x), False altrimenti


Espressioni con quantificatori (Esempio)

  • Trovare tutti gli attori dei film della DISNEY

  • SELECT a

  • FROM Attori a

  • WHERE EXISTS f IN a.recitaIn:

  • f.posseduto_da .nome=“Disney”

  • Trovare gli attori che recitano solo in film della DISNEY

  • SELECT a

  • FROM Attori a

  • WHERE FOR ALL f IN a.recitaIn:

  • f.posseduto_da .nome= “Disney”






©astratto.info 2017
invia messaggio

    Pagina principale