3b-Basi di dati relazionali ad oggetti

Transcript

1 Approccio Object Object-Relational (ORDBMS) 3b-Basi di dati relazionali ad oggetti I database orientati agli oggetti non hanno allo stato avuto adeguato successo perché non hanno offerto efficienza pari ai collaudati RDBMS. L approccio Object-Relational invece si presenta come evolutivo rispetto alle basi dati relazionali, ponendosi come obiettivo: estensioni compatibili con la nozione di tabella. la possibilità di esprimere la maggior parte dei concetti dei DB puri ad oggetti. 1 2 Modello dei dati di SQL:1999 E compatibile con il modello relazionale ad es: create table PERSONE( Nome varchar(30) not null Residenza varchar(30) Codfisc char(16)primary key ); L approccio ORDBMS suggerisce di definire prima il tipo tupla (row) della tabella PERSONE, chiamiamolo TipoPersona, per renderlo riusabile. L uso di tipi strutturati, che estendono la nozione classica di dominio ( tipo distinto in SQL:1999), consente essenzialmente di costruire la struttura delle tuple (row) da inserire in tabella. Tipi strutturati parte statica Definizione della tabella persona : create type TipoPersona as( Nome varchar (30), Residenza varchar(30), CodFisc char(16) ) ; create table PERSONE of TipoPersona; : il tipo ammette la definizione di sottotipi; 3 4

2 Tipi strutturati Tecnicamente una relazione - come PERSONE, dichiarata con il tipo riga - TipoPersona, non è un insieme di triple bensì una relazione unaria, le cui tuple sono oggetti con tre componenti: (Nome, Residenza, Codfisc). Riferimenti Se T è un tipo, allora REF T è il tipo di un riferimento to T, cioè, un puntatore ad un oggetto di tipo T. Viene spesso chiamato nei sistemi Object Oriented un ID di oggetto, OID. A differenza degli OID, un REF è visibile, anche se normalmente non ha significato 5 6 Riferimenti (2) create type TipoCostr( Presidente ref (TipoPersona), Stabilimento ref (TipoStabilimento) Nome varchar (20) ); Gli oggetti TipoCostr hanno il seguente aspetto: Tipi strutturati approfondimento (1) Definizione della tabella persona in SQL:1999 create type TipoPersona as (Nome varchar (30), Residenza varchar(30), CodFisc char(16)) ref from (CodFisc) create table PERSONE of TipoPersona ( ref is CodFisc derived); Ad un oggetto TipoPersona F I A T Ad un oggetto TipoStabilimento 7 ref from (CodFisc): Codfisc è l attributo da utilizzare per realizzare riferimenti a istanze del tipo. ref is CodFisc derived: specifica che l identificatore è derivato dal valore dell attributo CodFisc. 8

3 Tipi strutturati approfondimento (2) Possibile riuso del tipo persona Esempio di tipi strutturati Create table INDUSTRIALI of TipoPersona ( Ref is CodFisc derived) Create table PILOTI of TipoPersona ( Ref is Codfisc derived ) Si notino le corrispondenze: (tupla, oggetto) (tabella, classe) conformemente ai DB ad oggetti Esempio tipi strutturati Consideriamo la definizione dei corrispondenti tipi tupla per la fig. precedente che includono TipoPersona già visto. Si noti l uso del costrutto: multiset per denotare il costruttore di insiemi previsto nella versione di SQL-3. ref is system generated: l attributo da utilizzare per realizzare riferimenti a istanze del tipo ( OID = REF) è automaticamente generato dal sistema. 11 Codice esempio tipi strutturati create type TipoStab as ( Nome varchar (25), Citta varchar (7), Addetti integer) create type TipoCostr as( Nome varchar (25), Presidente ref(tipopersona), Stabilimenti TipoStab multiset) ref is system generated create type TipoPartiAuto as ( Motore char(10), Ammortizzatore char(5)) create type TipoAuto as TipoAuto as( Targa char(7), Modello varchar (30), Costruttore ref(tipocostr), PartiMeccaniche TipoPartiAuto) ref is system generated 12

4 Complessità strutturale TipoStab presente nell ambito di TipoCostr e TipoPartiAuto presente nell ambito di TipoAuto, sono usati senza introdurre il costrutto ref e cioè senza che vengano introdotti oggetti e quindi tipi indipendenti. Questo perché si possono costruire oggetti (tuple) che comprendono al loro interno sotto-oggetti (sotto-tuple) garantendo una arbitraria complessità strutturale. Le tabelle (classi) dell esempio Create table INDUSTRIALI of TipoPersona ( Ref is CodFisc derived) Create table PILOTI of TipoPersona ( Ref is Codfisc derived Create table AUTOMOBILI of TipoAuto ( Ref is AutoId system generated Create table COSTRUTTORI of TipoCostr ( Ref is CostrId system generated, Presidente with options scope INDUSTRIALI) Definizione di identificatori Nella definizione di TipoAuto (e TipoCostr) non compare esplicitamente il nome dell attributo da utilizzare per realizzare riferimenti a istanze del tipo. Grazie alle definizioni (ref is ) nelle Tabelle AUTOMOBILI, COSTRUTTORI vengono introdotti esplicitamente i relativi identificatori AutoId, CostrId, per utilizzarli nelle relazioni. with options Il costrutto with options consente di fornire maggiori dettagli o imporre restrizioni su componenti del tipo quando esso viene utilizzato nell ambito di una tabella. Qui viene usato per associare la clausola scope all attributo Presidente (componente del TipoCostr): Presidente with options scope INDUSTRIALI che impone il vincolo che i valori di Presidente debbano essere dei riferimenti alle tuple di TipoPersona appartenenti alla tabella INDUSTRIALI

5 Gerarchie di tipo In SQL:1999 vi sono gerarchie di tipo e di tabella Le Gerarchie di tipo estendono i tipi già definiti, come nel caso di TipoAuto dell esempio seguente: create type TipoAutoStorica under TipoAuto as( AnnoCostr integer) dove TipoAutoStorica aggiunge l attributo AnnoCostr a TipoAuto. Gerarchie sulle tabelle Le gerarchie sulle tabelle sono analoghe alle gerarchie sulle classi: Le sotto-tabelle hanno per tipo un sotto-tipo delle tabelle da cui ereditano. Ogni tupla (oggetto) presente in una sotto-tabella appare (è fisicamente presente) come tupla nelle tabelle di livello gerarchicamente superiore. Definizione di Automobile Storica: create table AUTOMOBILISTORICHE of TipoAutoStorica under AUTOMOBILI Alternativamente (ma con tipo non riutilizzabile ): create table AUTOMOBILISTORICHE under AUTOMOBILI( AnnoCostr integer) Anche la gestione dei riferimenti viene ereditata Tipi instanziabili e non I tipi definiti dall utente possono essere: [not] instantiable cioè etichettati come instanziabili o meno I tipi non instanziabili non possono essere utilizzati direttamente nella definizione delle tabelle ma possono essere utilizzati come base nelle definizione dei sottotipi o come componenti all interno della definizione di altri tipi o tabelle. Il comportamento è analogo a quello delle classi astratte di Java o del modello ad oggetti. 19 Metodi parte dinamica 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 20

6 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 E possibile negare agli utenti i privilegi di accesso ai metodi, che vengono definiti come privilegi speciali, ottenendo come effetto l incapsulamento dei dati. 21 Metodi Vediamo un esempio di Definizione del TipoPartiAuto che comprende i metodi PotUnitaria calcolo della potenza di ciascun cilindro del motore e MaggiorPotUnitaria (confronto tra l istanza su cui viene invocato il metodo e un altra istanza dello stesso tipo che viene passata come parametro) create type TipoPartiAuto as( Motore char(10), NumCilindri integer, Potenza integer, Cilindrata integer ) not instantiable method PotUnitaria() returns float, method DisegnoDisponibile () returns boolean language C 22 Metodi: implementazione I metodi definiti possono essere realizzati in SQL:1999 oppure in un linguaggio esterno (vedi nell esempio C per DisegnoDisponibile); Occorre definire la segnatura con i parametri di ingresso e quello di uscita e poi l implementazione: Calcolo della potenza di ciascun cilindro del motore Create instance method PotUnitaria() returns float for TipoPartiAuto return (cast(self.potenza as float)/ Self.NumCilindri) Metodi: implementazione Confronto tra l istanza di TipoPartiAuto su cui viene invocato il metodo con un altra istanza dello stesso tipo che viene passata come parametro Create instance method MaggiorPotUnitaria (ParteCfr TipoPartiAuto) returns boolean for TipoPartiAuto Return ((Self.PotUnitaria > ParteCfr.PotUnitaria) or((self.potunitaria > ParteCfr.PotUnitaria) and(self.cilindrata > ParteCfr.Cilindrata))) 23 24

7 Metodi: implementazione Nelle implementazioni i valori degli attributi sono raggiunti con una notazione a punto (dot notation) per estrarre l attributo referenziato da una variabile. E da notare che nel metodo MaggiorPotUnitaria venga utilizzato il metodo PotUnitaria. In SQL:1999 si fa riferimento a una implementazione esterna realizzata in uno specifico linguaggio con: Create instance method DisegnoDisponibile() return boolean external name Mia ProceduraC Interrogazioni in SQL:1999 Le interrogazioni SQL-2 sono completamente ammesse in SQL:1999 select Nome from PERSONE where CodFisc = TRESFN56D23S541S La navigazione lungo i riferimenti tra i tipi richiede l operatore di dereferenziamento ; tale operatore consente di accedere da un oggetto sorgente x ad un attributo A di un oggetto y referenziato in x con x -> A Interrogazioni in SQL:1999 Il seguente esempio mostra l uso dell operatore di dereferenziamento per accedere al valore dell attributo Nome dell oggetto della tabella INDUSTRIALI puntato dall oggetto della tabella COSTRUTTORI che è puntato a sua volta dall automobile che soddisfa il predicato Targa= DB123MS : select Costruttore -> Presidente -> Nome from AUTOMOBILI where Targa = DB123MS 27 Interrogazioni in SQL:1999 In SQL:1999 gli attributi di tipo REF possono essere esplicitamente utilizzati nelle interrogazioni e confrontati con l operatore = con i riferimenti a tuple dello stesso tipo: Select INDUSTRIALE.Nome From AUTOMOBILE, COSTRUTTORE, INDUSTRIALE where AUTOMOBILE.Targa= DB123MS and AUTOMOBILE.Costruttore=COSTRUTTORE.CostrId and COSTRUTTORE.Presidente=INDUSTRIALE.CodFisc L interrogazione costruisce un join tra le tabelle AUTOMOBILE, COSTRUTTORE, INDUSTRIALE, in cui: l attributo Costruttore di AUTOMOBILE viene confrontato con l identificatore CostrId di COSTRUTTORE e l attributo Presidente di COSTRUTTORE viene confrontato con l identificatore CodFisc di INDUSTRIALE. 28

8 The Third Generation Database System Manifesto (Stonebraker, Rowe, Lindsay, Gray, Carey, Brodie, Bernstein, Beech) Un articolo a sostegno dei sistemi object relational - nato in risposta al manifesto delle basi di dati ad oggetti (OODBMS)- la cui intuizione nel tempo si è dimostrata profetica: "I DBMS della prossima generazione dovranno essere ottenuti come risultato dell'evoluzione dei DBMS esistenti (relazionali)" I PRINCIPI DEL 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 I CONCETTI DEL MANIFESTO Un 3GDBMS deve avere un sistema di tipi ricco, che tra l altro possegga costruttori ortogonali per array, sequenze, record e set. Un 3GDBMS deve consentire gerarchie di generalizzazione tra tipi possibilmente anche con ereditarietà multipla. Le funzioni (includendo procedure e metodi) sono caratteristiche utili specie se accompagnate dall incapsulamento. Ha senso che il sistema assegni OID agli oggetti solo se non è disponibile una chiave primaria tra gli attributi definiti dall utente; altrimenti è meglio ricorrere a quelli chiave per identificare gli oggetti. Regole attive (trigger) e passive (vincoli di integrità) diventeranno una componente essenziale dei 3GDBMS. Indipendentemente da quanto questo fattore sia desiderabile, SQL è il linguaggio di riferimento dei 3GDBMS. 31