4a-Basi di dati relazionali ad
oggetti
1
Approccio “Object-Relational”(ORDBMS)
• 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.
2
Modello dei dati di SQL:1999
• E’ compatibile con il modello relazionale ad es:
create table Persona(
Nome varchar(40) not null
Residenza varchar(30)
Codfisc char(16)primary key
);
• L’approccio ORDBMS suggerisce di definire “prima” il
tipo (riga, row) Persona, chiamiamolo “TipoPersona”,
per renderlo riusabile.
• L’uso di tipi strutturati, che estendono la nozione classica
di dominio ( tipo distinto in SQL:1999), consente di
costruire innanzitutto la struttura delle tuple (row) da
inserire in tabella.
3
Tipi strutturati – parte statica
• Definizione della tabella persona :
create type TipoPersona(
Nome varchar (30),
Residenza varchar(30),
CodFisc char(16)
) not final;
create table Persona of
TipoPersona;
not final: il tipo ammette la definizione di sottotipi;
4
Tipi strutturati e riferimenti
• 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).
• 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
Riferimenti
create type TipoCostr(
Presidente
ref (TipoPersona),
Stabilimento ref (TipoStabilimento)
Nome
varchar (20)
);
• Gli oggetti TipoCostr hanno il seguente aspetto:
FIAT
Ad un
oggetto
TipoPersona
Ad un oggetto
TipoStabilimento
6
Tipi strutturati – approfondimento
• Definizione della tabella persona in SQL:1999
create type TipoPersona
(Nome varchar (30),
Residenza varchar(30),
CodFisc char(16))
not final
ref from CodFisc
create table Persona of
TipoPersona (
ref is CodFisc derived);
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.
7
Tipi strutturati - approfondimento
• Possibile riuso del tipo persona
Create
Ref
Create
Ref
table Presidente of TipoPersona (
is CodFisc derived)
table Pilota of TipoPersona (
is Codfisc derived
• Si noti la corrispondenza:
– (Tupla, oggetto)
– (tabella, classe)
conformemente ai DB ad oggetti.
8
Esempio tipi strutturati
9
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:
– varray : il costruttore di insiemi set of non è previsto
in SQL:1999
– ref is system generated: l’attributo da utilizzare per
realizzare riferimenti a istanze del tipo ( OID = REF) è
automaticamente generato dal sistema.
10
Codice esempio tipi strutturati
create type TipoStab(
Nome varchar (25),
Citta varchar (7),
Addetti integer)
not final
create type TipoCostr(
Nome varchar (25),
Presidente ref(TipoPersona),
Stabilimenti VARRAY[10]of TipoStab)
not final
ref is system generated
create type TipoPartiAuto(
Motore char(10),
Ammortizzatore char(5))
not final
create type TipoAuto(
Targa char(7),
Modello varchar (30),
Costruttore ref(TipoCostr),
PartiMeccaniche TipoPartiAuto)
not final
ref is system generated
11
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.
12
Le tabelle (classi) dell’esempio
Create table Industriale of TipoPersona (
Ref is CodFisc derived)
Create table Pilota of TipoPersona (
Ref is Codfisc derived
Create table Automobile of TipoAuto (
Ref is AutoId system generated
Create table Costruttore of TipoCostr (
Ref is CostrId system generated,
Presidente with options scope
Industriale references are checked)
13
Definizione di identificatori
• Nella definizione di TipoAuto (TipoCostr) non
compare esplicitamente il nome dell’attributo
da utilizzare per realizzare riferimenti a
istanze del tipo.
• Grazie alle definizioni (ref is …) nelle Tabelle
Automobile, Costruttore vengono introdotti
esplicitamente i relativi identificatori AutoId,
CostrId, per utilizzarli nelle relazioni.
14
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:
Presidente with options scope Industriale
che impone il vincolo che i valori di
Presidente debbano essere dei riferimenti
alle tuple di TipoPersona appartenenti alla
tabella Industriale.
15
Supporto per l’integrità referenziale
•
•
In SQL:1999 occorre, se sul tipo è imposta
l’integrità referenziale, introdurre:
... references are checked
cioè che i riferimenti sono sempre
mantenuti consistenti dal sistema.
In questo caso, qualsiasi modifica al
contenuto della tabella Industriale che può
causare anomalia farà scattare un Trigger
per rifiutare eventualmente la modifica.
16
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(
AnnoCostr integer)
under TipoAuto
not final
– dove TipoAutoStorica aggiunge l’attributo
AnnoCostr a TipoAuto.
17
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 AutomobileStorica of
type TipoAutoStorica
under Automobile
• Alternativamente (ma con tipo “non riutilizzabile”):
create table AutomobileStorica(
AnnoCostr integer)
under Automobile
• Anche la gestione dei riferimenti viene ereditata
18
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
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 (
Motore char(10),
NumCilindri integer,
Potenza integer,
Cilindrata integer )
not instantiable
not final
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)
23
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)))
24
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
25
Interrogazioni in SQL:1999
• Le interrogazioni SQL-2 sono completamente
ammesse in SQL:1999
select Nome
from Persona
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”
26
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 INDUSTRIALE “puntato”
dall’oggetto della tabella COSTRUTTORE che è puntato a
sua volta dall’automobile che soddisfa il predicato
Targa=‘DB123MS’:
select Costruttore -> Presidente -> Nome
from
Automobile
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
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)"
29
I principi del contro-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
30
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
Manifesto 3GDBMS: dettagli
[1.1] rich type system
[1.2] inheritance
[1.3] functions and encapsulation
[1.4] OID's only if there are no keys
[1.5] rules and triggers
[2.1] non procedural, high level access languages
[2.2] specification techniques for collections
[2.3] updatable views
[2.4] transparency of physical parameters
[3.1] multiple high level languages
[3.2] persistent x, for many x's
[3.3] SQL is a standard (even if you don't like it)
[3.4] queries and their results are the lowest level of
communication
32