Basi di Dati Relazionali ad Oggetti

241
1 Basi di Dati Relazionali ad Oggetti

description

Basi di Dati Relazionali ad Oggetti. RDBMS: panorama attuale. Gestiscono e manipolano dati semplici (tabellari) Hanno un linguaggio di interrogazione (SQL) semplice, dichiarativo e standard - PowerPoint PPT Presentation

Transcript of Basi di Dati Relazionali ad Oggetti

Page 1: Basi di Dati Relazionali ad Oggetti

1

Basi di Dati Relazionali ad Oggetti

Page 2: Basi di Dati Relazionali ad Oggetti

2

RDBMS: panorama attuale

Gestiscono e manipolano dati semplici (tabellari)

Hanno un linguaggio di interrogazione (SQL) semplice, dichiarativo e standard

Tool consolidati per lo sviluppo di applicazioni (Oracle Developer, Sybase Power Builder, Microsoft Visual Basic)

Page 3: Basi di Dati Relazionali ad Oggetti

3

RDBMS: panorama attuale

Portabili su diverse piattaforme Esempi di RDBMS: IBM DB2, Oracle, Sybase,

Informix, Microsoft SQL Server Buone prestazioni Affidabilità, gestione transazioni Basati su una architettura client-server supportano

efficientemente un gran numero di utenti Forniscono meccanismi di controllo dell’accesso

Page 4: Basi di Dati Relazionali ad Oggetti

4

RDBMS: panorama attuale

Oggi il mercato mondiale dei RDBMS supera i 50 billioni di dollari all’anno, ma… i RDBMS presentano anche alcuni limiti

Page 5: Basi di Dati Relazionali ad Oggetti

5

RDBMS: problemi

Prevalentemente connessi alle caratteristiche intrinseche del modello relazionale:– SQL-92 fornisce solo un insieme limitato di tipi di

dato– le tabelle hanno una struttura flat e non forniscono

un buon supporto per strutture annidate, quali insiemi ed array

– non è possibile definire relazioni di sotto-tipo tra gli oggetti di un database

Page 6: Basi di Dati Relazionali ad Oggetti

6

RDBMS: problemi

Le associazioni tra entità vengono modellate per valore e questo nel caso di associazioni complesse può richiedere la creazione di parecchie tabelle/colonne “fittizie”

Gli RDBMS non sfruttano gli approcci object-oriented per la progettazione e realizzazione di software che oggi stanno diventando pressochè uno standard

Page 7: Basi di Dati Relazionali ad Oggetti

7

OODBMS: panorama attuale

Permettono di modellare direttamente oggetti complessi e le loro associazioni

Object-orientation sempre più diffuso in ambito software engineering e programmazione: unicità del paradigma

Buone prestazioni per applicazioni navigazionali

Limitato supporto per concorrenza, parallelismo e distribuzione

Page 8: Basi di Dati Relazionali ad Oggetti

8

OODBMS: panorama attuale

Semplici modelli transazionali Limitate funzionalità di controllo dell’accesso Coprono un mercato di nicchia che richiede

accessi navigazionali efficienti (disegno di chip, ecc.)

Page 9: Basi di Dati Relazionali ad Oggetti

9

OODBMS: problemi

Il progetto del database è strettamente legato al progetto delle applicazioni

Mancanza di un modello dei dati e di un linguaggio di query standard pienamente accettati

Mancanza di un linguaggio di query dichiarativo (SQL-like)

Page 10: Basi di Dati Relazionali ad Oggetti

10

RDBMS vs. OODBMS

RDBMS forniscono un supporto efficiente ed efficace per applicazioni che manipolano dati semplici

OODBMS forniscono un supporto efficiente per alcune classi di applicazioni su dati complessi, ma senza molti degli aspetti positivi dei RDBMS

Page 11: Basi di Dati Relazionali ad Oggetti

11

Il modello relazionale ad oggetti

I DBMS relazionali ad oggetti (object-relational) nascono dall’esigenza di assicurare le funzionalità dei RDBMS rispetto alla gestione di dati tradizionali, estendendo il modello dei dati con la possibilità di gestire dati complessi tipica degli OODBMS

Page 12: Basi di Dati Relazionali ad Oggetti

12

ORDBMS: caratteristiche generali

Nuovi tipi di dato:– testi, immagini, audio/video, dati geografici, ecc.– tipi di dato user-defined– tipi collezione

Metodi per modellare le operazioni sui tipi definiti dall'utente (es. Java, C)

Nuovi modi per modellare le associazioni

Page 13: Basi di Dati Relazionali ad Oggetti

13

ORDBMS: caratteristiche generali

La filosofia per la gestione dei dati è però ancora quella relazionale:– Tutti gli accessi ai dati avvengono tramite SQL– Tutti le entità di interesse sono modellate tramite

tabelle

Page 14: Basi di Dati Relazionali ad Oggetti

14

ORDBMS: panorama attuale

Oggi quasi tutti i principali produttori di RDBMS (Oracle, Informix, DB2,..) hanno esteso i loro DBMS con caratteristiche object-relational

Tali estensioni presuppongono anche una estensione del linguaggio SQL

Allo stato attuale ogni RDBMS ha un’estensione proprietaria object-relational

Page 15: Basi di Dati Relazionali ad Oggetti

15

ORDBMS: panorama attuale

Le estensioni differiscono per:– Le funzionalità che supportano– Il modo di realizzarle– Le estensioni apportate ad SQL

E questo nonostante SQL-99 ...

Page 16: Basi di Dati Relazionali ad Oggetti

16

Lo standard SQL-99

SQL-99 è un tentativo di standardizzazione dell’estensione object-relational del modello relazionale

Al momento della definizione di SQL-99 i maggiori produttori di RDBMS avevano già la loro versione delle estensioni object-relational

SQL-99 non standardizza tutte le funzionalità object-relational presenti nei DBMS commerciali

Page 17: Basi di Dati Relazionali ad Oggetti

17

Lo standard SQL-99

E’ quindi ancora presto per capire quando e in che misura lo standard sarà recepito a livello commerciale

La sensazione è che sarà necessario un ulteriore standard che medi tra tutte le estensioni proprietarie

Page 18: Basi di Dati Relazionali ad Oggetti

18

Nel seguito …

Discutere le caratteristiche generali di un ORDBMS

discuteremo come queste caratteristiche vengono gestite dallo standard– se non altrimenti specificato, utilizzeremo la sintassi

di SQL-99

introdurremo le caratteristiche relazionali ad oggetti di Oracle

Page 19: Basi di Dati Relazionali ad Oggetti

19

Estensione del sistema di tipi

Page 20: Basi di Dati Relazionali ad Oggetti

20

Sistema dei tipi in SQL92

In SQL-92 i tipi di un attributo in una relazione possono essere:– numerici (interi, reali, ecc.)– carattere (stringhe di lunghezza fissa o variabile,

caratteri singoli)– temporali (date, time, datetime, interval)– booleani (true, false)– non strutturati (BYTE, TEXT, BLOB, CLOB)

Page 21: Basi di Dati Relazionali ad Oggetti

21

Sistema dei tipi in SQL92

Per ogni tipo built-in esistono un insieme fisso e predefinito di operazioni che su di esso possono essere eseguite

Queste limitazioni rendono spesso difficile la rappresentazione di dati reali

Page 22: Basi di Dati Relazionali ad Oggetti

22

Estensione del sistema di tipi

Tipi semplici Abstract data types

– User-defined types

Tipi riferimento Tipi complessi:

– tipi record e tipi collezione

Page 23: Basi di Dati Relazionali ad Oggetti

23

Tipi semplici

I tipi semplici (o distinct type) sono la forma più semplice di estensione del sistema dei tipi fornita da un ORDBMS

Consentono agli utenti di creare nuovi tipi di dati, basati su un solo tipo (built-in o user-defined)

Page 24: Basi di Dati Relazionali ad Oggetti

24

Tipi semplici

Sono usati per definire tipi di dati che richiedono operazioni diverse rispetto al tipo su cui sono definiti

I tipi semplici sono considerati dal DBMS totalmente distinti dal tipo su cui si basano

I valori del tipo semplice non sono direttamente confrontabili con quelli del tipo su cui si basano (strong typing)

Page 25: Basi di Dati Relazionali ad Oggetti

25

Tipi semplici

Confronti con il tipo base o con altri tipi semplici definiti sullo stesso tipo base richiedono operazioni di cast

l’ORDBMS crea automaticamente una funzione di cast quando un nuovo tipo semplice viene creato

Non è fornito alcun meccanismo di ereditarietà e subtyping per i tipi semplici

Page 26: Basi di Dati Relazionali ad Oggetti

26

Esempio

Si supponga di creare un nuovo tipo id_impiegato basato sul tipo intero

Come il tipo intero, id_impiegato è utilizzato per memorizzare valori numerici ma il DBMS tratterà i due tipi come tipi distinti

Per i due tipi possono essere definite operazioni diverse (ad esempio la somma di due identificatori non ha senso, mentre potrebbe essere utile una operazione di confronto)

Page 27: Basi di Dati Relazionali ad Oggetti

27

Tipi semplici in SQL-99

SQL-99 consente di definire tipi semplici basati solo su tipi built-in

CREATE TYPE <name> AS <built-in type> FINAL

Vedremo in seguito il significato della clausola FINAL

Page 28: Basi di Dati Relazionali ad Oggetti

28

Esempio

CREATE TYPE id_impiegato AS INTEGER FINAL;

CREATE TABLE Impiegati(

id id_impiegato,

nome VARCHAR(50),

età INTEGER,

id_manager id_impiegato);

Page 29: Basi di Dati Relazionali ad Oggetti

29

Casting

I valori dei distinct type sono considerati come distinti dai valori del tipo di base– il casting non è automatico

le funzioni di cast (se necessarie) vanno implementate esplicitamente, eventualmente direttamente dal sistema

Page 30: Basi di Dati Relazionali ad Oggetti

30

Esempio - assegnazione

SELECT nome

FROM Impiegati

WHERE id_manager = 123; errore

Page 31: Basi di Dati Relazionali ad Oggetti

31

Esempio - confronto

CREATE TYPE Euro AS Decimal(8,2) FINAL;

CREATE TYPE Dollaro_USA AS Decimal(8,2) FINAL;

CREATE TABLE Vendite_Europee(

n_cliente INTEGER,

n_ordine INTEGER,

totale Euro);

CREATE TABLE Vendite_USA(

n_cliente INTEGER,

n_ordine INTEGER,

totale Dollaro_USA);

Page 32: Basi di Dati Relazionali ad Oggetti

32

Esempio: confronto

SELECT n_cliente,n_ordine

FROM Vendite_Europee ERP, Vendite_USA USA

WHERE ERP.n_ordine = USA.n_ordine

AND ERP.totale > USA.totale; errore!!!

Page 33: Basi di Dati Relazionali ad Oggetti

33

Casting in SQL-99

Il DBMS definisce due funzioni di casting per ogni nuovo tipo semplice:– una per passare dal distinct type al tipo built-

in– una per passare dal tipo built-in al distinct

type

Page 34: Basi di Dati Relazionali ad Oggetti

34

Funzioni di casting in SQL-99

CREATE CAST (<source type> AS <target type>)

WITH <segnatura funzione>

[AS ASSIGNMENT]

<source type>: tipo input <target type>: tipo output almeno uno tra <source type> e <target type> deve

essere un tipo definito dall’utente l’altro può essere un tipo qualunque

Page 35: Basi di Dati Relazionali ad Oggetti

35

<segnatura funzione> è la segnatura di una qualunque funzione

la funzione deve essere definita come segue:

FUNCTION <name> (<source type>) RETURNS <target type>

… codice ...

Funzioni di casting in SQL-99

Page 36: Basi di Dati Relazionali ad Oggetti

36

Se la clausola AS ASSIGNMENT è specificata, il casting è invocato implicitamente quando necessario

per ogni coppia di tipi può esistere una sola funzione di casting definita dall’utente

Funzioni di casting in SQL-99

Page 37: Basi di Dati Relazionali ad Oggetti

37

Funzioni di casting in SQL-99

Le funzioni di casting per i tipi semplici vengano create automaticamento dal sistema con la clausola AS ASSIGNMENT

Page 38: Basi di Dati Relazionali ad Oggetti

38

Casting in SQL-99

La funzione di casting può essere invocata:– esplicitamente

CAST(<source type> as <target type>)– implicitamente, senza invocare la funzione CAST

la stessa funzione può essere invocata per casting su tipi built-in (esempio: integer in real)

Page 39: Basi di Dati Relazionali ad Oggetti

39

Esempio

SELECT nome

FROM Impiegati

WHERE id_manager = CAST(123 AS id_impiegato);

SELECT nome

FROM Impiegati

WHERE id_manager = 123;

Page 40: Basi di Dati Relazionali ad Oggetti

40

Esempio

SELECT n_cliente,n_ordine

FROM Vendite_Europee ERP, Vendite_USA USA

WHERE ERP.n_ordine = USA.n_ordine

AND CAST(ERP.totale AS Decimal(8,2) > CAST(USA.totale AS Decimal(8,2));

Page 41: Basi di Dati Relazionali ad Oggetti

41

Esempio - alternativa

Per passare da Euro a Dollaro_USA posso anche definire una nuova funzione di cast

CREATE FUNCTION f(e Euro) RETURNS Dollaro_USA

BEGIN

DECLARE g DECIMAL(8,2);

SET g = e;

RETURN g;

END;

CREATE CAST(Euro AS Dollaro_USA)

WITH FUNCTION f(Euro);

Page 42: Basi di Dati Relazionali ad Oggetti

42

ADT

Un abstract data type include:– uno o più attributi– uno o più metodi

Page 43: Basi di Dati Relazionali ad Oggetti

43

ADT in SQL-99

Gli attributi possono essere dichiarati come gli attributi di una tabella– possono usare clausole default– non è possibile specificare vincolo NOT NULL

il tipo può essere instanziabile oppure no– vedremo meglio dopo

Page 44: Basi di Dati Relazionali ad Oggetti

44

ADT in SQL-99

Se ci sono solo attributi (completeremo in seguito la definizione):

CREATE TYPE <nome tipo>

AS <lista definizione attributi>

[{INSTANTIABLE|NOT INSTANTIABLE}]

{FINAL|NOT FINAL}

INSTANTIABLE è il default

Page 45: Basi di Dati Relazionali ad Oggetti

45

Esempio

Si supponga di voler rappresentare l’indirizzo di un impiegato in un RDBMS

Sono possibili due opzioni:– indirizzo: VARCHAR(n)– rappresentare ogni componente dell’indirizzo come

un attributo separato

Page 46: Basi di Dati Relazionali ad Oggetti

46

Esempio

CREATE TYPE t_indirizzo AS

numero_civico INTEGER,

via VARCHAR(50),

città CHAR(20),

stato CHAR(2),

cap INTEGER

NOT FINAL;

t_indirizzo è un tipo complesso i cui attributi hanno tipi predefiniti

Page 47: Basi di Dati Relazionali ad Oggetti

47

ADT

Gli ADT possono anche essere annidati:

CREATE TYPE t_impiegato AS

id id_impiegato,

nome CHAR(20),

curriculum TEXT,

indirizzo t_indirizzo

NOT FINAL;

Page 48: Basi di Dati Relazionali ad Oggetti

48

ADT

Gli ADT possono essere usati come:

– tipi di una colonna in una relazione

– tipi di una tabella (row type)

Page 49: Basi di Dati Relazionali ad Oggetti

49

ADT come tipo di colonna

Gli ADT possono essere usati come tipi di una colonna di una relazione

CREATE TABLE Impiegati (

imp# id_impiegato,

nome CHAR(20),

curriculum TEXT,

indirizzo t_indirizzo);

Page 50: Basi di Dati Relazionali ad Oggetti

50

ADT come tipo di colonna

Tabella Impiegati

nomeimp# curriculum indirizzo

numero_civico via città stato cap

Page 51: Basi di Dati Relazionali ad Oggetti

51

Metodi

Sugli ADT possono essere definiti (segnature di) metodi come parte della definizione del tipo:

CREATE TYPE t_libro AStitolo CHAR(20),prezzo_vendita DECIMAL(9,2),prezzo_acquisto DECIMAL(9,2)NOT FINAL

METHOD guadagno() RETURNS DECIMAL(9,2);

Page 52: Basi di Dati Relazionali ad Oggetti

52

Metodi

I metodi sono funzioni definite dall’utente associate ai tipi Possono essere scritti in linguaggi proprietari del DBMS

o in linguaggi di programmazione standard (es. Java) La sintassi varia notevolmente a seconda del DBMS

utilizzato definizione simile a quella delle funzioni

– differenza: i metodi hanno un parametro implicito che rappresenta l’oggetto su cui il metodo viene invocato

Page 53: Basi di Dati Relazionali ad Oggetti

53

Metodi in SQL-99

Vengono creati con il comando CREATE METHOD

CREATE METHOD <nome metodo>

(lista parametri)

RETURNS <output data type>

FOR <nome UDT>

<corpo metodo>

Page 54: Basi di Dati Relazionali ad Oggetti

54

Esempio

CREATE METHOD guadagno()

RETURNS DECIMAL(9,2)

FOR t_libro

RETURN (SELF.prezzo_vendita - SELF.prezzo_acquisto);

CREATE FUNCTION guadagno(l t_libro)

RETURNS DECIMAL(9,2)

RETURN (l.prezzo_vendita - l.prezzo_acquisto);

Page 55: Basi di Dati Relazionali ad Oggetti

55

Incapsulazione

Gli ADT possono essere incapsulati in questo caso, la loro manipolazione può

avvenire solo mediante apposite funzioni automaticamente create dal DBMS al momento della creazione dell’ADT

Page 56: Basi di Dati Relazionali ad Oggetti

56

Incapsulazione in SQL-99

Incapsulazione stretta Tre tipi di metodi predefiniti

– costruttore: per creare una nuova istanza di ADT– metodi observer: per formulare interrogazioni su

ADT– metodi mutator: per cambiare valori ad istanze di

ADT TIPO = CLASSE

Page 57: Basi di Dati Relazionali ad Oggetti

57

Metodo costruttore

Ad ogni ADT è automaticamente associato un metodo (costruttore) con lo stesso nome del tipo

Il costruttore crea un'istanza del tipo al costruttore possono in genere essere

passati i valori da assegnare alle componenti dell’istanza creata

Page 58: Basi di Dati Relazionali ad Oggetti

58

Costruttori in SQL-99

Per ogni ADT T, esiste un costruttore T( )

t_indirizzo() ----> t_indirizzo

crea una nuova istanza del tipo t_indirizzo con gli attributi inizializzati ai valori di default (tali valori possono anche essere NULL)

t_indirizzo(39, ‘Comelico', 'Milano', 'IT', 20135)

crea una nuova istanza del tipo t_indirizzo con gli attributi inizializzati in base ai valori forniti

Page 59: Basi di Dati Relazionali ad Oggetti

59

Esempio - inserimento 1

INSERT INTO Impiegati

VALUES(SM123,‘Smith’,NULL,t_indirizzo(14,‘Sauli', ‘Milano’,'IT', 20135));

nomeimp# curriculum indirizzonumero_civico via città stato

capSmithSM123 NULL 14 Sauli Milano IT 20135

Page 60: Basi di Dati Relazionali ad Oggetti

60

Metodi mutator

Servono per modificare istanze di un ADT

numero_civico(INTEGER) --> t_indirizzo

via(VARCHAR(50)) --> t_indirizzo

città(CHAR(20)) --> t_indirizzo

stato(CHAR(2)) --> t_indirizzo

cap(INTEGER) --> t_indirizzo

vale anche per SQL-99

Page 61: Basi di Dati Relazionali ad Oggetti

61

Esempio

Vogliamo inserire la tupla nella tabella impiegati:

In due passi:– creo la tupla inizializzando il campo indirizzo– aggiorno i valori del campo indirizzo

nomeimp# curriculum indirizzonumero_civico via città stato

capSmithSM123 NULL 14 Sauli Milano IT 20135

Page 62: Basi di Dati Relazionali ad Oggetti

62

Esempio - inserimento 2

INSERT INTO Impiegati

VALUES(SM123,‘Smith’,NULL,t_indirizzo());

UPDATE Impiegati

SET indirizzo = indirizzo.numero_civico(14)

WHERE imp# = ‘SM123’;

UPDATE Impiegati

indirizzo = indirizzo.via(‘Sauli’)

WHERE imp# = ‘SM123’;

….

Page 63: Basi di Dati Relazionali ad Oggetti

63

Esempio - inserimento 3

BEGIN

DECLARE i t_indirizzo;

SET i = t_indirizzo();

SET i = i.numero_civico(14);

SET i = i.via(‘Sauli’);

SET i = i.città(‘Milano’);

SET i = i.stato(‘IT’);

SET i = i.cap(20135);

INSERT INTO impiegati VALUES (‘SM123’,’Smith’,NULL,i);

END;

Page 64: Basi di Dati Relazionali ad Oggetti

64

Metodi observer

Per ogni componente di un ADT è automaticamente creato dal sistema un metodo observer con lo stesso nome della componente:

numero_civico( ) ----> INTEGER

via( ) ----> VARCHAR(50)

città( ) ----> CHAR(20)

stato( ) ----> CHAR(2)

cap( ) ----> INTEGER

Anche in SQL-99

Page 65: Basi di Dati Relazionali ad Oggetti

65

Esempi di selezione

SELECT nome

FROM Impiegati

WHERE indirizzo.città( ) = ‘Milano’

OR indirizzo.città( ) = ‘Roma’;

SELECT indirizzo.città()

FROM impiegati

WHERE nome = ‘Smith’;

Page 66: Basi di Dati Relazionali ad Oggetti

66

Istanze di un ADT

Dato un ADT T con attributi attr1,…,attrn, un’istanza per T viene indicata con T(v_attr1,…,v_attrn), dove v_attr1,…,v_attrn valori per gli attributi attr1,…,attrn

t_indirizzo(14,’Sauli’,’Milano’,’IT’,20135)

Page 67: Basi di Dati Relazionali ad Oggetti

67

Selezione

La selezione di una colonna ADT restituisce un’istanza di quel tipo

SELECT indirizzo

FROM Impiegati

WHERE imp# = ‘SM123’

si ottiene

t_indirizzo(14,’Sauli’,’Milano’,’IT’,20135)

Page 68: Basi di Dati Relazionali ad Oggetti

68

Cancellazione

DELETE FROM Impiegati

WHERE indirizzo = t_indirizzo(14,’Sauli’,’Milano’,’IT’,20135);

Page 69: Basi di Dati Relazionali ad Oggetti

69

Update

UPDATE Impiegati

SET indirizzo = indirizzo.n_civico(18)

WHERE imp# = ‘SM123’ ;

UPDATE Impiegati

WHERE indirizzo =

t_indirizzo(18,’XX Settembre’,’Genova’,’IT’,16100);

Page 70: Basi di Dati Relazionali ad Oggetti

70

Uso di metodi nelle query

CREATE TYPE t_libro AStitolo CHAR(20),prezzo_vendita DECIMAL(9,2),prezzo_acquisto DECIMAL(9,2)NOT FINALMETHOD guadagno() RETURNS DECIMAL(9,2);

CREATE TABLE biblioteca(codL# INTEGER, libro t_libro);

SELECT b.libro.guadagno( )FROM biblioteca bWHERE b.libro.titolo() = ‘La Divina Commedia’;

Page 71: Basi di Dati Relazionali ad Oggetti

71

Vincoli di integrità

Non è possibile definire vincoli di PRIMARY KEY, UNIQUE, FOREIGN KEY su un campo ADT

Motivazione– concettualmente tutto è OK– problemi legati all’efficienza

Page 72: Basi di Dati Relazionali ad Oggetti

72

Operazioni

Casting definito dall’utente tra ADT e altro tipo possibilità di definire funzioni di ordinamento e

di confronto– non le vediamo

Page 73: Basi di Dati Relazionali ad Oggetti

73

Cancellazione e modifica tipi

DROP TYPE <nome_tipo> {CASCADE|RESTRICT};

ALTER TYPE <nome_tipo> <operazione_di_modifica>;

<operazione_di_modifica>::=

ADD ATTRIBUTE <definizione_attributo>|

DROP ATTRIBUTE <nome_attributo>

Page 74: Basi di Dati Relazionali ad Oggetti

74

Row type

Un ADT può anche essere usato come tipo di una intera tabella (row type)

Le righe della tabella sono istanze del tipo mentre le colonne coincidono con gli attributi del tipo

Page 75: Basi di Dati Relazionali ad Oggetti

75

Row type

Permettono di:– definire un insieme di tabelle che condividono la stessa struttura

(typed tables)– modellare in modo intuitivo le associazioni tra dati in tabelle diverse

(referenceable tables)– definire gerarchie di tabelle

TUPLA DI UNA TYPED TABLE = OGGETTO ogni tupla è associata ad un identificatore, che rappresenta

un campo aggiuntivo per ogni tabella ed è unico nel sistema per default, gli identificatori sono generati dal sistema

– esistono altre modalità, non le vediamo

Page 76: Basi di Dati Relazionali ad Oggetti

76

Typed tables in SQL-99

CREATE TABLE <nome_tabella>

OF <nome_tipo_complesso>

[(REF IS <nome_campo_TID>)]

la clausola REF IS indica il nome di un attributo (distinto dai precedenti) nel quale verranno inseriti gli identificatori di tupla (TID - tuple identifier)

il campo identificatore è sempre il primo campo nello schema della tabella

se la clausola manca, il campo contenente gli identificatori esiste, è generato dal sistema ma è trasparente all’utente (non selezionabile)

Page 77: Basi di Dati Relazionali ad Oggetti

77

Esempio

Si supponga di voler memorizzare informazioni sui progetto a cui gli impiegati lavorano

CREATE TYPE t_progetto AS

prj# INTEGER,

nome VARCHAR(20),

descrizione VARCHAR(50),

budget INTEGER

NOT FINAL;

Page 78: Basi di Dati Relazionali ad Oggetti

78

Esempio

CREATE TABLE Progetti OF t_progetto

(REF IS my_TID);

Progetti

prj#

16454 12 Oracle ORDBMS

nome

descrizione budget

10,000,000

my_TID

Page 79: Basi di Dati Relazionali ad Oggetti

79

Row type

Nessun meccanismo di incapsulazione L’incapsulazione c’e’ solo quando un ADT è

usato come tipo di una colonna Gli attributi del row type sono visti come

colonne della tabella (inclusa la colonna TID, che può essere selezionata)

Le interrogazioni sono eseguite nel modo standard

Page 80: Basi di Dati Relazionali ad Oggetti

80

Selezione

SELECT prj#

FROM Progetti

WHERE budget > 1,000,000;

SELECT my_TID

FROM Progetti

WHERE budget > 1,000,000;

Page 81: Basi di Dati Relazionali ad Oggetti

81

Inserimento

INSERT INTO Progetti(Prj#,Nome,Descrizione,Budget)

VALUES(14,’sviluppo DB’,’sviluppo DB in Oracle’,’20,000,000);

nessun valore viene specificato per il campo identificatore

Page 82: Basi di Dati Relazionali ad Oggetti

82

Tipi riferimento

I row type possono essere combinati con i tipi riferimento (REF type)

Permettono di rappresentare facilmente le associazioni tra istanze di tipi

Tali tipi permettono ad una colonna di riferire una tupla in un'altra relazione

Una tupla in una relazione viene identificata tramite il suo TID

Page 83: Basi di Dati Relazionali ad Oggetti

83

Esempio

Si supponga di voler memorizzare informazioni sugli impiegati ed i progetti a cui lavorano

In un RDBMS avrei due tabelle Impiegati e Progetti

Nella tabella Impiegati è presente una colonna che indica il progetto a cui l’impiegato lavora (chiave esterna)

Page 84: Basi di Dati Relazionali ad Oggetti

84

Esempio

Impiegati

prj#

Progetti

prj#

SM123 12 12 Oracle ….

imp#

...

nome

Page 85: Basi di Dati Relazionali ad Oggetti

85

Tipi riferimento

In un ORDBMS ho due opzioni in più:– definire un ADT t_progetto e usare questo come

tipo di una colonna della relazione Impiegati (ridondanza dei dati perché lo stesso progetto può essere memorizzato molte volte in Impiegati)

– definire una tabella basata su un nuovo tipo complesso e riferire le colonne istanza di questo nuovo tipo

tipo riferimento

Page 86: Basi di Dati Relazionali ad Oggetti

86

Tipi riferimento in SQL-99

REF (<tipo_ADT>)

[SCOPE <nome_tabella> [<reference_scope_check>]]

la clausola SCOPE specifica una typed table su <tipo_ADT> e indica che i valori ammessi per il tipo riferimento sono i puntatori alle tuple della type table indicata

se la clausola di scope non è specificata, lo scope implicito è rappresentato da tutti i puntatori a tuple con row type <tipo_ADT>

Page 87: Basi di Dati Relazionali ad Oggetti

87

Tipi riferimento in SQL-99

La clausola di SCOPE rappresenta una sorta di vincolo di chiave esterna nel modello relazionale

problema integrità referenziale anche in questo contesto

<reference_scope_check> è una clausola che indica come è possibile mantenere l’integrità, analogamente a quanto visto per le chiavi esterne

Page 88: Basi di Dati Relazionali ad Oggetti

88

Tipi riferimento in SQL-99

<reference_scope_check> =

REFERENCES ARE [NOT] CHECKED

[ON DELETE

{CASCADE | SET NULL | SET DEFAULT |

RESTRICT | NO ACTION}] significato analogo al contesto relazionale poichè il TID è considerato immutabile, nessuna clausola

ON UPDATE default: RESTRICT

Page 89: Basi di Dati Relazionali ad Oggetti

89

Esempio

CREATE TABLE Impiegati(

imp# id_impiegato,

nome VARCHAR(50),

indirizzo t_indirizzo,

assegnamento REF(t_progetto) SCOPE Progetti

REFERENCES ARE CHECKED

ON DELETE CASCADE);

Si associa un impiegato ad un progetto

Uno stesso progetto può essere associato a più impiegati

Se si cancella un progetto, si cancellano anche tutti gli impiegati assegnati a quel progetto

Page 90: Basi di Dati Relazionali ad Oggetti

90

Esempio

CREATE TABLE Impiegati(

imp# id_impiegato,

nome VARCHAR(50),

indirizzo t_indirizzo,

assegnamentoREF(t_progetto) SCOPE Progetti

REFERENCES ARE CHECKED

ON DELETE RESTRICT);

Un progetto può essere cancellato sono se non ci sono impiegati assegnati a quel progetto

Page 91: Basi di Dati Relazionali ad Oggetti

91

Esempio

CREATE TYPE t_impiegato AS

imp# id_impiegato,

nome CHAR(20),

curriculum TEXT,

indirizzo t_indirizzo,

dipartimento REF(t_dipartimento)

NOT FINAL;

CREATE TABLE Impiegati OF t_impiegato (REF IS my_tid);

Page 92: Basi di Dati Relazionali ad Oggetti

92

Esempio

CREATE TYPE t_dipartimento AS

dip# INTEGER,

nome VARCHAR(30),

manager REF (t_impiegato)

NOT FINAL ;

CREATE TABLE Dipartimenti OF t_dipartimento (REF IS my_tid);

Page 93: Basi di Dati Relazionali ad Oggetti

93

EsempioImpiegati

imp# nome

... dipartimento

Dipartimenti

dip# nome

manager

Page 94: Basi di Dati Relazionali ad Oggetti

94

Esempio

La colonna dipartimento di Impiegati punta ad una tupla della tabella Dipartimenti (quelle corrispondente al dipartimento in cui lavora l’impiegato)

La colonna impiegati di Dipartimenti punta ad una tupla della tabella Impiegati (quella che corrisponde al manager del dipartimento)

Page 95: Basi di Dati Relazionali ad Oggetti

95

Tipi riferimento in SQL-99

Possibilità di estendere la definizione di una typed table con ulteriori attributo con reference type

Page 96: Basi di Dati Relazionali ad Oggetti

96

Esempio

CREATE TABLE Progetti OF t_progetto

(prog_ref REF(t_progetto));

Progetti

prj#

12 Oracle ORDBMS

nome

descrizione budget

10,000,000

Prog_ref

Page 97: Basi di Dati Relazionali ad Oggetti

97

Tipi riferimento in SQL-99 - manipolazione

Valori di tipi riferimento possono essere confrontati solo utilizzando = e <>

Casting può essere definito tra reference type e ADT target o tipo built-in

Page 98: Basi di Dati Relazionali ad Oggetti

98

Tipi riferimento in SQL-99 - manipolazione

Funzione di deferenziazione DEREF:– riceve in input un’espressione che restituisce un valore

(puntatore) per un tipo riferimento con scope non vuoto– restituisce il valore puntato dallo stesso (quindi la tupla

puntata)

Funzione di riferimento ->– riceve in input un’espressione che restituisce un valore di tipo

riferimento e un attributo dell’ADT a cui punta il tipo riferimento – restituisce il valore per quell’attributo per la tupla puntata

Page 99: Basi di Dati Relazionali ad Oggetti

99

Esempio

SELECT manager

FROM Dipartimenti

WHERE nome = “Dischi”;

Restituisce un puntatore ad un impiegato (cioè l’oid dell’impiegato che è manager del dipartimento Dischi)

Page 100: Basi di Dati Relazionali ad Oggetti

100

Esempio

SELECT deref(manager)

FROM Dipartimenti

WHERE nome = “Dischi”;

Restituisce informazioni sul manager del dipartimento Dischi (un’intera riga della tabella Impiegati)

Page 101: Basi di Dati Relazionali ad Oggetti

101

Esempio

SELECT deref(manager).nome

FROM Dipartimenti

WHERE nome = “Dischi”;

Restituisce il nome del manager del dipartimento Dischi

Page 102: Basi di Dati Relazionali ad Oggetti

102

Esempio

SELECT manager -> nome

FROM Dipartimenti

WHERE nome = “Dischi”;

Restituisce il nome del manager del dipartimento Dischi

Equivalente all’interrogazione precedente

Page 103: Basi di Dati Relazionali ad Oggetti

103

Integrità referenziale

Gli identificatori vengono assegnati dal sistema l’utente non li conosce a priori Problema:

– Come garantire l’integrità referenziale di una tabella che contiene un tipo riferimento?

Soluzione:– si utilizzano sottoquery per determinare gli

identificatori da assegnare alle nuove tuple

Page 104: Basi di Dati Relazionali ad Oggetti

104

Esempio

CREATE TABLE Impiegati(

imp# id_impiegato,

nome VARCHAR(50),

indirizzo t_indirizzo,

assegnamento REF(t_progetto) SCOPE Progetti

REFERENCES ARE CHECKED

ON DELETE RESTRICT);

CREATE TABLE Progetti OF t_progetto

(REF IS My_TID,

prog_ref REF(t_progetto));

Page 105: Basi di Dati Relazionali ad Oggetti

105

Integrità referenziale

Quando inseriamo una tupla nella tabella impiegati, al campo assegnamento dobbiamo assegnare l’identificatore di una tupla della tabella Progetti

Due passi:– inseriamo la tupla assegnando NULL al campo con

tipo riferimento– modifichiamo il contenuto del campo con un UPDATE

Page 106: Basi di Dati Relazionali ad Oggetti

106

Esempio

INSERT INTO Impiegati

VALUES (2,’Mario Rossi’, t_indirizzo( ),NULL);

UPDATE Impiegati

SET assegnamento =

(SELECT my_tid

FROM Progetti

WHERE nome = ‘Oracle’)

WHERE imp# = 2;

Page 107: Basi di Dati Relazionali ad Oggetti

107

Tipi riferimento in SQL-99 -restrizioni

PRIMARY KEY, UNIQUE, FOREIGN KEY non possono essere definiti

Page 108: Basi di Dati Relazionali ad Oggetti

108

Informazione aggiuntiva 1

Quando si crea una typed table è possibile aggiungere vincoli di integrità sugli attributi dell’ADT su cui si basa (purché il tipo corrispondente lo permetta)

CREATE TABLE <nome_tabella>

OF <nome_tipo_complesso>

[(REF IS <nome_campo_TID>)

<vincoli>]

Page 109: Basi di Dati Relazionali ad Oggetti

109

Esempio

CREATE TYPE t_progetto AS

prj# INTEGER,

nome VARCHAR(20),

descrizione VARCHAR(50),

budget INTEGER

NOT FINAL;

CREATE TABLE progetti OF t_progetto

(PRIMARY KEy (prj));

Page 110: Basi di Dati Relazionali ad Oggetti

110

Informazioni aggiuntiva 2

I metodi possono essere:– metodi per le istanze (INSTANCE)

invocabili a partire da un’istanza del tipo

– metodi di tipo (STATIC) invocabili sul tipo

il default è INSTANCE

Page 111: Basi di Dati Relazionali ad Oggetti

111

Esempio

CREATE TYPE t_libro AStitolo CHAR(20),prezzo_vendita DECIMAL(9,2),prezzo_acquisto DECIMAL(9,2)NOT FINALINSTANCE METHOD guadagno() RETURNS DECIMAL(9,2),STATIC METHOD max_prezzo_vendita() RETURNS DECIMAL(9,2);

Page 112: Basi di Dati Relazionali ad Oggetti

112

Tipi collezione e tipi tupla

Page 113: Basi di Dati Relazionali ad Oggetti

113

Tipi collezione

I tipi collezione definiscono dei contenitori per oggetti con struttura simile

Non esiste ancora una standardizzazione sull’insieme di tipi collezione supportati dai vari ORDBMS– set– bag– liste– array

Page 114: Basi di Dati Relazionali ad Oggetti

114

Tipi collezione in SQL-99

Il solo tipo collezione incluso in SQL-99 è ARRAY– <nome campo> <tipo> ARRAY[<dimensione>]

<dimensione> è un valore intero Costruttore:

– ARRAY[<valore_1>,…,<valore_n>]

accesso:– <nome_campo>[i] dove i è un valore intero tra 1 e n

Page 115: Basi di Dati Relazionali ad Oggetti

115

Tipi collezione in SQL-99

Il numero di elementi in un array è un qualunque numero tra 0 (ARRAY[ ]) e il numero massimo di elementi per l’array dichiarato

implicitamente, esiste un parametro “lunghezza”, gestito direttamente dal sistema

Page 116: Basi di Dati Relazionali ad Oggetti

116

Esempio

CREATE TABLE Impiegati(

imp# id_impiegato,

nome VARCHAR(50),

competenze VARCHAR(20) ARRAY[3]);

Page 117: Basi di Dati Relazionali ad Oggetti

117

Esempio

INSERT INTO Impiegati

VALUES (2,’Mario Rossi’,ARRAY[‘Oracle’,’Unix’,’Java’]);

SELECT *

FROM Impiegati

WHERE competenze[2] = ‘Unix’;

Page 118: Basi di Dati Relazionali ad Oggetti

118

Esempio

CREATE TYPE t_impiegato AS

imp# id_impiegato,

nome VARCHAR(30),

indirizzo t_indirizzo,

manager REF(t_impiegato),

progetti REF(t_persona) ARRAY[10],

figli REF(t_persona) ARRAY[10],

hobby VARCHAR(20) ARRAY[5]

NOT FINAL;

CREATE TABLE Impiegati OF t_impiegato;

Page 119: Basi di Dati Relazionali ad Oggetti

119

Esempio

UPDATE Impiegati

SET competenze = ARRAY[‘Oracle’,’Unix’];

UPDATE Impiegati

SET competenze = ARRAY[‘SQL Server’];

il nuovo array contiene un solo elemento (la lunghezza viene cambiata)

Page 120: Basi di Dati Relazionali ad Oggetti

120

Tipi collezione in SQL-99 - manipolazione

Casting– cast sul tipo degli elementi e eventuale riduzione

numero elementi

assegnamento:– usuale– troncamento genera errore

confronto:– =, <>

Page 121: Basi di Dati Relazionali ad Oggetti

121

Tipi collezione in SQL-99 - manipolazione

funzioni– concatenazione

CONCATENATE (<array_expression> WITH <array_expression>

– cardinalità CARDINALITY(<array_expression>)

Page 122: Basi di Dati Relazionali ad Oggetti

122

Tipi collezione in SQL-99 - restrizioni

Per i campi di tipo array non possono essere definiti vincoli UNIQUE, PRIMARY KEY, FOREIGN KEY

Page 123: Basi di Dati Relazionali ad Oggetti

123

Tipi tupla in SQL-99

SQL-99 mette a disposizione un nuovo dominio per la rappresentazione di tipi record

chiamati row type non richiedono la definizione di un ADT ma

possono essere direttamente associati al tipo

Page 124: Basi di Dati Relazionali ad Oggetti

124

Tipi tupla in SQL-99

TipoROW (<def campo_1>,…,<def campo_n>)

esempio:

ROW(numero_civico INTEGER,

via VARCHAR(50),

città CHAR(20),

stato CHAR(2),

cap INTEGER)

Page 125: Basi di Dati Relazionali ad Oggetti

125

Esempio

CREATE TABLE Impiegati (

imp# id_impiegato,

nome CHAR(20),

curriculum TEXT,

indirizzo ROW( numero_civico INTEGER,

via VARCHAR(50),

città CHAR(20),

stato CHAR(2),

cap INTEGER) );

Page 126: Basi di Dati Relazionali ad Oggetti

126

Tipi tupla in SQL-99

Valori:– ROW(<valore tipo_1,…,valore tipo_n>)

Esempio:– ROW(3,’XX Settembre’,’Genova’,’IT’,16100)

anche le tuple restituite da una query sono viste come valori del tipo tupla

le componenti di una tupla possono essere accedure utilizzando la dot notation

Page 127: Basi di Dati Relazionali ad Oggetti

127

Esempio

INSERT INTO Impiegati

VALUES (3,’Rossi’,NULL,

ROW(3,’XX Settembre’,’Genova’,’IT’,16100))

Page 128: Basi di Dati Relazionali ad Oggetti

128

Esempio

CREATE TABLE Indirizzi

( Iid INTEGER,

Via VARCHAR(20),

Città VARCHAR(20),

Stato VARCHAR(20),

cap INTEGER);

UPDATE Impiegati

SET Indirizzo = (SELECT t from Indirizzi t WHERE Iid = 3)

WHERE nome = ‘Rossi’;

Page 129: Basi di Dati Relazionali ad Oggetti

129

Esempio

SELECT Nome

FROM Impiegati

WHERE Indirizzo.città = ‘Genova’;

Page 130: Basi di Dati Relazionali ad Oggetti

130

Tipi tupla in SQL-99 - manipolazione

Assegnamento:– stesso numero di campi– tipi compatibili

confronto:– =, <>, <, <=, >, >=– ordinamento lessicografico, basato sui tipi delle

componenti– i valori devono avere lo stesso numero di elementi– la presenza di NULL può ovviamente generare UNKNOWN

Page 131: Basi di Dati Relazionali ad Oggetti

131

Esempio

ROW(1,1,1) = ROW(1,1,1) TRUEROW(1,1,1) = ROW(1,2,1) FALSEROW(1,NULL,1) = ROW(2,2,1) FALSEROW(1,NULL,1) = ROW(1,2,1) UNKNOWNROW(1,1,1) <> ROW(1,2,1) TRUEROW(2,NULL,2) <> ROW(2,2,1) TRUEROW(2,2,1) <> ROW(2,2,1) FALSEROW(1,NULL,1) <> ROW(1,2,1) UNKNOWNROW(1,1,1) < ROW(1,2,0) TRUEROW(1,NULL,1) < ROW(2,NULL,0) TRUEROW(1,1,1) < ROW(1,1,1) FALSEROW(3,NULL,1) < ROW(2,NULL,0) FALSEROW(1,NULL,1) < ROW(1,2,0) UNKNOWNROW(NULL,1,1) < ROW(2,1,0) UNKNOWN

Page 132: Basi di Dati Relazionali ad Oggetti

132

Tipi tupla in SQL-99

Non possono essere associati a vincoli di PRIMARY KEY, UNIQUE, FOREIGN KEY

Page 133: Basi di Dati Relazionali ad Oggetti

133

Ereditarietà

Page 134: Basi di Dati Relazionali ad Oggetti

134

Ereditarietà

Possibilità di definire relazioni di supertipo/sottotipo

L’ereditarietà consente di specializzare i tipi esistenti a seconda delle esigenze dell’applicazione

Page 135: Basi di Dati Relazionali ad Oggetti

135

Ereditarietà

Un sottotipo eredita gli attributi, i metodi, ed i vincoli definiti per i suoi supertipi

Il sottotipo può raffinare il supertipo con nuovi attributi e metodi

Nel sottotipo è anche possibile ridefinire metodi ereditati

Page 136: Basi di Dati Relazionali ad Oggetti

136

Ereditarietà

Si possono distinguere due tipi di ereditarietà– Ereditarietà di tipi– Ereditarietà di tabelle

Page 137: Basi di Dati Relazionali ad Oggetti

137

Ereditarietà di tipi

Si considerino le seguenti entità:

Camion:

modello CHAR(20),

n_licenza INTEGER,

ultima_revisione DATE,

peso INTEGER,

prox_revisione() DATE

Bus:

modello CHAR(20),

n_licenza INTEGER,

ultima_revisione DATE,

n_posti INTEGER,

prox_revisione() DATE

Page 138: Basi di Dati Relazionali ad Oggetti

138

Ereditarietà di tipi

Nel modello relazionale sono necessarie due tabelle e due procedure

In un ORDBMS, camion e bus possono essere considerati specializzazioni di un tipo comune: Veicolo

Si definisce quindi un tipo veicolo contenente le caratteristiche comuni di camion e bus

Camion e bus sono definiti come sottotipi di Veicolo, con delle caratteristiche aggiuntive

Page 139: Basi di Dati Relazionali ad Oggetti

139

Ereditarietà di tipi in SQL-99

Per ADT ereditarietà singola

CREATE TYPE <nome_tipo>

UNDER <nome_superclasse>

AS … altri attributi

[NOT] FINAL;

il supertipo deve essere stato dichiarato con la clausola NOT FINAL

Page 140: Basi di Dati Relazionali ad Oggetti

140

Ereditarietà di tipi in SQL-99

Clausola FINAL: – non si possono definire sottotipi

Clausola NOT FINAL:– si possono definire sottotipi

la clausola NOT FINAL è necessaria se la dichiarazione non specifica una superclasse

in caso contrario si può scegliere

Page 141: Basi di Dati Relazionali ad Oggetti

141

Esempio

CREATE TYPE t_veicolo ASmodello CHAR(20),n_licenza INTEGER,ultima_revisione DATE,

METHOD prox_revisione( ) RETURNS DATE

NOT FINAL;

Page 142: Basi di Dati Relazionali ad Oggetti

142

Esempio

CREATE TYPE t_camion ASUNDER t_veicoloASpeso INTEGERNOT FINAL;

CREATE TYPE t_bus AS

UNDER t_veicolo

AS

n_posti INTEGER

NOT FINAL;

Page 143: Basi di Dati Relazionali ad Oggetti

143

Metodi & ereditarietà

CREATE TYPE t_persona ASnome CHAR(20),id INTEGER,data_di_nascita DATE,indirizzo t_indirizzo,

METHOD età() RETURNS INTEGERNOT FINAL;

CREATE TYPE t_insegnante ASUNDER t_persona

stipendio DECIMAL(9,2),data_assunzione DATE,corso t_corsoNOT FINAL;

Page 144: Basi di Dati Relazionali ad Oggetti

144

Metodi & ereditarietà

I metodi sono ereditati dai sottotipi allo stesso modo degli attributi:

CREATE TABLE Insegnanti OF t_insegnante;

SELECT nome, I.età( )

FROM Insegnanti I

WHERE stipendio > 3000;

Page 145: Basi di Dati Relazionali ad Oggetti

145

Metodi & ereditarietà

E’ possibile ridefinire un metodo ereditato non è possibile ridefinire gli attributi Ad esempio al tipo t_insegnante può essere associato un

metodo età che restituisce l’anzianità di servizio (overriding)CREATE TYPE t_insegnante AS

UNDER t_persona stipendio DECIMAL(9,2),

data_assunzione DATE,corso t_corsoOVERRIDING METHOD età RETURNS INTEGERNOT FINAL;

Page 146: Basi di Dati Relazionali ad Oggetti

146

Tipi non instanziabili

La dichiarazioni di un tipo specifica se il tipo può essere instanziato (quindi ha istanze proprio) oppure noCREATE TYPE <nome tipo>

AS <lista definizione attributi>

[{INSTANTIABLE|NOT INSTANTIABLE}]

{FINAL|NOT FINAL}

Il default è INSTANTIABLE un tipo non instanziabile corrisponde ad una classe

astratta: server solo per riuso di codice

Page 147: Basi di Dati Relazionali ad Oggetti

147

Sostituibilità

Negli OODBMS vale il principio della sostituibilità Un’istanza di un tipo può essere utilizzata

ovunque ci si aspetti un’istanza del suo supertipo Questo principio non vale negli attuali ORDBMS per garantire sostituibilità:

– funzione di CAST

Page 148: Basi di Dati Relazionali ad Oggetti

148

Ereditarietà di tabelle

Le typed tables possono essere organizzate in gerarchie di ereditarietà

questo è possibile solo i tipi su cui si basato sono in relazione d’ereditarietà

permette di estendere operazioni SQL alle istanze di una tabella e di tutte le sue sottotabelle

Page 149: Basi di Dati Relazionali ad Oggetti

149

Esempio

CREATE TABLE persone OF t_persona;

CREATE TABLE insegnanti of t_insegnante UNDER persone;

E’ stata creata una gerarchia tra le tabelle persone e insegnanti

Page 150: Basi di Dati Relazionali ad Oggetti

150

Interrogazioni

La gerarchia d’ereditarietà definita sulle tabelle influenza i risultati delle interrogazioni

Una interrogazione fatta su una tabella si propaga automaticamente alle sottotabelle

Lo stesso vale per le operazioni di cancellazione e modifica mentre una operazione di inserimento coinvolge solo una specifica tabella

se si vuole restringere l’operazione alle istanze di una certa tabella: ONLY

Page 151: Basi di Dati Relazionali ad Oggetti

151

Esempio

Persone

nome id data_di_nascita indirizzo

Smith 74 16/8/68

John 86 3/2/48

nome id data_di_nascita indirizzo

Allen 82 9/7/67

Mark 81 3/5/58

Insegnanti

stipendio ….

30ml

60ml

Page 152: Basi di Dati Relazionali ad Oggetti

152

Esempio

SELECT nome

FROM Persone

WHERE data_di_nascita > 1/1/1967;

Il risultato sarà: Smith e Allen

SELECT nome

FROM ONLY Persone

WHERE data_di_nascita > 1/1/1967;

Il risultato sarà: Smith

Page 153: Basi di Dati Relazionali ad Oggetti

153

Esempio

DELETE FROM Persone

WHERE id > 80;

Cancellerà John dalla tabella Persone e Allen e Mark dalla tabella Insegnanti

Page 154: Basi di Dati Relazionali ad Oggetti

154

Relazioni tra OODBMS e ORDBMS

Valori complessi– array– row

Oggetti: – tuple di typed tables– identificatore– incapsulazione

Classi– ADT (è presente il costruttore)– metodi (overloading e overriding)– collezioni: typed table– aggregazioni: tipi REF

Page 155: Basi di Dati Relazionali ad Oggetti

155

Relazioni tra OODBMS e ORDBMS

Ereditarietà– singola– riuso di codice– no sostituibilità– su tipi e typed tables

linguaggio– SQL con estensioni per la manipolazione dei nuovi tipi di dato– accesso navigazione e associativo– un’interrogazione restituisce sempre un insieme di tuple

Page 156: Basi di Dati Relazionali ad Oggetti

156

Progettazione di ORDBMS

Page 157: Basi di Dati Relazionali ad Oggetti

157

Progettazione di ORDBMS

Non esiste ancora una metodologia di progettazione consolidata come per gli ORDBMS né tool a supporto dell’attività di progettazione

Page 158: Basi di Dati Relazionali ad Oggetti

158

Approccio partendo da schemi ER

Progettazione concettuale:– schema ER

Ristrutturazione:– inesistente– non si eliminano attributi multivalore/compositi e

gerarchie di generalizzazione

Page 159: Basi di Dati Relazionali ad Oggetti

159

Approccio partendo da schemi ER

Progettazione logica:– attributo composito:

tipo tupla oppure ADT

– Ogni attributo multivalore viene tradotto in un tipo collezione (ARRAY per SQL-99)

– Ogni entità: se non ha metodi può essere tradotta in una tabella, o tramite

l’opzione successiva se ha metodi viene tradotta in un tipo su cui basare una tabella

– Le gerarchie di generalizzazione vengono tradotte mediante relazioni di sottotipo

Page 160: Basi di Dati Relazionali ad Oggetti

160

Approccio partendo da uno schema OO

Ogni tipo composito (struct)– tipo tupla o tipo complesso

ogni tipo multivalore (set, bag, list)– tipo collezione

Page 161: Basi di Dati Relazionali ad Oggetti

161

Approccio partendo da uno schema OO

ogni classe– se non ha metodi:

si crea direttamente la tabella i tipi degli attributi vengono modificati in base a quanto sopra

– se ha metodi: si crea un opportuno ADT si crea tabella basata su quell’ADT

– per ogni attributo aggregato: aggregazione semplice: si specifica un tipo riferimento con scope

uguale alla tabella corrispondente alla classe riferita aggregazione complessa: si specifica un tipo collezione definito su un

tipo riferimento

Page 162: Basi di Dati Relazionali ad Oggetti

162

Aspetti relazionali ad oggetti di Oracle 9i

Page 163: Basi di Dati Relazionali ad Oggetti

163

Il sistema di tipi di Oracle

Non distinct type Tipi oggetto tipi riferimento tipi collezione ereditarietà

Page 164: Basi di Dati Relazionali ad Oggetti

164

Tipi oggetto

Possibilità di definire tipi oggetto (ADT):

specifica Dichiarazione di attributiSpecifica dei metodi

corpo Body dei metodi

Page 165: Basi di Dati Relazionali ad Oggetti

165

Esempio

CREATE TYPE Complesso AS OBJECT(

parte_r FLOAT,

parte_i FLOAT,

MEMBER FUNCTION somma(x Complesso) RETURNS Complesso,

MEMBER FUNCTION sottrazione(x Complesso)

RETURNS Complesso,

MEMBER FUNCTION moltiplicazione(x Complesso)

RETURNS Complesso,

MEMBER FUNCTION divisione(x Complesso)

RETURNS Complesso);

Page 166: Basi di Dati Relazionali ad Oggetti

166

Esempio

CREATE TYPE BODY Complesso AS MEMBER FUNCTION somma(x Complesso)

RETURN Complesso ISBEGIN RETURNS Complesso(parte_r + x.parte_r,parte_i + x.parte_i);END somma;MEMBER FUNCTION sottrazione(x Complesso)

RETURN Complesso ISBEGIN RETURNS Complesso(parte_r - x.parte_r,parte_i - x.parte_i);END sottrazione;….END;

Page 167: Basi di Dati Relazionali ad Oggetti

167

Tipi oggetto

Vale tutto quello che abbiamo detto per SQL-99 con le seguenti differenze:– concetto di body– incapsulazione non stretta: accesso diretto agli

attributi tramite dot notation

Page 168: Basi di Dati Relazionali ad Oggetti

168

Metodi

Possono essere sia procedure che funzioni due tipi:

– MEMBER definiti sulle istanze parametro implicito: SELF

– STATIC definiti sul tipo

Page 169: Basi di Dati Relazionali ad Oggetti

169

Esempio

CREATE TYPE Rational AS OBJECT

(num INTEGER,

den INTEGER,

MEMBER PROCEDURE normalize,

...

);

CREATE TYPE BODY Rational AS

MEMBER PROCEDURE normalize IS

g INTEGER;

BEGIN

g := gcd(SELF.num, SELF.den);

g := gcd(num, den); -- equivalent to previous line

num := num / g;

den := den / g;

END normalize;

...

END;

Page 170: Basi di Dati Relazionali ad Oggetti

170

Metodi speciali

Costruttori– come in SQL-99

Metodi MAP Metodi ORDER

Page 171: Basi di Dati Relazionali ad Oggetti

171

Metodi MAP

Permettono di confrontare istanze di ADT mappando le istanze a valori di tipi built-in (DATE, NUMBER, VARCHAR)

rappresentano quindi un casting tra un ADT e uno dei tipi precedenti

se esiste un metodo MAP per un ADT, i confronti su oggetti di quel tipo vengono effettuati convertendo prima le istanze nei valori del tipo built-in considerato

Page 172: Basi di Dati Relazionali ad Oggetti

172

Esempio

CREATE TYPE Rectangle_typ AS OBJECT (

len NUMBER,

wid NUMBER,

MAP MEMBER FUNCTION area RETURN NUMBER,

...

);

CREATE TYPE BODY Rectangle_typ AS

MAP MEMBER FUNCTION area RETURN NUMBER IS

BEGIN

RETURN len * wid;

END area;

...

END;

Page 173: Basi di Dati Relazionali ad Oggetti

173

Esempio

Se o1 e o2 sono istanze del tipo rectangle_typ:– o1 < o2 è equivalente a o1.area() < o2.area()– la relazione viene stabilita su due istanze del tipo

NUMBER

Page 174: Basi di Dati Relazionali ad Oggetti

174

Metodi ORDER

Implementano una relazione d’ordine tra le istanze di un certo tipo

hanno sempre un parametro di tipo uguale a quello per cui il metodo viene definito

utili per confrontare tipi di dato molto complessi che non potrebbero facilmente essere confrontati con un metodo MAP

se esiste un metodo ORDER, il metodo viene automaticamente chiamato quando si confrontano istanze del tipo considerato

Page 175: Basi di Dati Relazionali ad Oggetti

175

Metodi ORDER

L’output è sempre un intero che vale:– - 1 : SELF < parametro– 0 : SELF = parametro– +1 : SELF > parametro

per un ADT, può esistere al più un metodo MAP o ORDER

se nessuno dei due viene definito, il sistema supporta solo = e <>

Page 176: Basi di Dati Relazionali ad Oggetti

176

Esempio

CREATE TYPE Customer_typ AS OBJECT (

id NUMBER,

name VARCHAR2(20),

addr VARCHAR2(30),

ORDER MEMBER FUNCTION match (c Customer_typ) RETURN INTEGER

);

Page 177: Basi di Dati Relazionali ad Oggetti

177

Esempio

CREATE TYPE BODY Customer_typ ASORDER MEMBER FUNCTION match (c Customer_typ) RETURN INTEGER

ISBEGINIF id < c.id THENRETURN -1; -- any negative number will doELSIF id > c.id THENRETURN 1; -- any positive number will doELSERETURN 0;END IF;END;END;

Page 178: Basi di Dati Relazionali ad Oggetti

178

Tabelle tipate

Anche in Oracle un tipo ADT può essere utilizzato secondo due modalità:– come tipo per un attributo di una tabella– come tipo di base per la definizione di una typed

table

non può essere specificata una colonna per gli identificatori (no clausola REF IS)

Page 179: Basi di Dati Relazionali ad Oggetti

179

Tipi oggetto: accesso

Accesso tramite dot notation ad attributi e metodi

se si usa la dot notation, è sempre necessario utilizzare un alias per la tabella acceduta

Page 180: Basi di Dati Relazionali ad Oggetti

180

Esempio

CREATE TYPE person AS OBJECT (ssno VARCHAR(20));

CREATE TABLE ptab1 OF person;

CREATE TABLE ptab2 (c1 person);

SELECT ssno FROM ptab1 ; OK

SELECT c1.ssno FROM ptab2 ; Errore

SELECT ptab2.c1.ssno FROM ptab2 ; Errore

SELECT p.c1.ssno FROM ptab2 p ; OK

Page 181: Basi di Dati Relazionali ad Oggetti

181

Sintassi Comandi

CREATE TYPE typename AS OBJECT

(attrname datatype {, attrname datatype}); CREATE OR REPLACE TYPE BODY typename IS metodo {metodo}; CREATE TABLE tablename OF typename

([attrname NOT NULL]

{,attrname NOT NULL}

[,PRIMARY KEY (attrname {,attrname })]); DROP TYPE typename; DROP TABLE tablename; ALTER TYPE typename REPLACE AS OBJECT (nuova definizione

tipo) CREATE OR REPLACE TYPE BODY typename IS metodo {metodo};

Page 182: Basi di Dati Relazionali ad Oggetti

182

Tipi riferimento

Vale quanto visto per SQL-99 – cambia un minimo la sintassi– REF <nome tipo> SCOPE IS <nome_tabella>

Page 183: Basi di Dati Relazionali ad Oggetti

183

Tipi riferimento - manipolazione

Tre funzioni principali:– referenziazione ref( ): dato un oggetto di un certo

tipo, restituisce l’identificatore per quell’oggetto– dereferenziazione deref( ): dato un identificatore,

restituisce l’oggetto– value ( ): prende un alias di relazione e restituisce

l’oggetto tupla associato (utilizzando il costruttore opportuno)

Page 184: Basi di Dati Relazionali ad Oggetti

184

Tipi riferimento

CREATE TYPE t_persona AS OBJECT(

nome VARCHAR2(10),

cognome VARCHAR2(15),

data_di_nascita DATE,

indirizzo t_indirizzo,

madre REF t_persona,

padre REF t_persona);

CREATE TABLE Persone OF t_persona;

Page 185: Basi di Dati Relazionali ad Oggetti

185

Tipi riferimentoPersone

nome cognome ... madre padre

Page 186: Basi di Dati Relazionali ad Oggetti

186

Tipi riferimento

INSERT INTO Persone

VALUES(‘Mario’,’Rossi’, …,NULL,NULL);

INSERT INTO Persone

VALUES(t_persona(‘Maria’,’Bianchi’,…,NULL,NULL));

INSERT INTO Persone

VALUES(‘Giovanni’,’Rossi’,…,NULL,NULL);

Page 187: Basi di Dati Relazionali ad Oggetti

187

Tipi riferimento

Persone

nome cognome ... madre padre

Mario Rossi NULL NULL

Maria Bianchi NULL NULL

Giovanni Rossi NULL NULL

Page 188: Basi di Dati Relazionali ad Oggetti

188

Tipi riferimento

UPDATE Persone p

SET p.madre = (SELECT ref(d1) FROM Persone d1

WHERE nome = 'Maria')

WHERE nome = ’Giovanni';

La madre di Giovanni Rossi è Maria Bianchi

Page 189: Basi di Dati Relazionali ad Oggetti

189

Tipi riferimento

Persone

nome cognome ... madre padre

Mario Rossi NULL NULL

Maria Bianchi NULL NULL

Giovanni Rossi NULL

Page 190: Basi di Dati Relazionali ad Oggetti

190

Tipi riferimento

SELECT value(p) FROM Persone p

si ottiene:

t_persona(‘Mario’,’Rossi’,NULL,NULL)

t_persona(‘Maria’,’Bianchi’,NULL,NULL)

t_persona(‘Giovanni,’Rossi’,xxxyyywww,NULL)

dove xxxyyywww è l’identificatore della tupla di Maria Bianchi

Page 191: Basi di Dati Relazionali ad Oggetti

191

SELECT deref(p.madre)FROM Persone pWHERE nome = ‘Giovanni’;

Seleziona tutte le informazioni contenute in Persone relative alla madre di Giovanni

restituisce

t_persona(‘Maria’,’Bianchi’,NULL,NULL)

Tipi riferimento

Page 192: Basi di Dati Relazionali ad Oggetti

192

Tipi collezione

Due tipi collezione:– nested table– varray

I tipi collezione possono avere come elementi istanze di tipi oggetto

Un tipo oggetto può avere un attributo di tipo collezione

Page 193: Basi di Dati Relazionali ad Oggetti

193

Tipi collezione

Le nested table possono essere considerate come una tabella con una sola colonna

differenze tra varray e nested table:– gli array hanno dimensione fissa mentre le nested table

hanno dimensione variabile– gli array sono memorizzati all’interno della tabella nella

quale sono utilizzati o come BLOB mentre le nested table sono memorizzate in tabelle separate, con una colonna in più che identifica una tupla della tabella a cui appartengono

Page 194: Basi di Dati Relazionali ad Oggetti

194

Tipi collezione

Non possono essere direttamente usati nella definizione di un attributo

è sempre necessario dare un nome al tipo collezione prima di usarlo

per ogni tipo, esiste un costruttore per creare un’istanza, è necessario passare al

costruttore un’insieme di elementi del tipo su cui il tipo collezione si basa

Page 195: Basi di Dati Relazionali ad Oggetti

195

Varray - creazione

CREATE TYPE Progetto AS OBJECT(id INTEGER,titolo VARCHAR2(25),costo NUMBER(7,2));

CREATE TYPE Lista_Progetti AS VARRAY(50) OF Progetto;

CREATE TYPE Dipartimento AS OBJECT(id INTEGER,nome VARCHAR2(15),budget NUMBER(11,2),progetti Lista_Progetti);

CREATE TABLE Dipartimenti OF Dipartimento;

Page 196: Basi di Dati Relazionali ad Oggetti

196

Varray - inserimento

INSERT INTO Dipartimenti

VALUES(30,’R&D’,1000000000,

Lista_Progetti(Progetto(1,’DBMS’,10000000),

Progetto(3,’C++’,20000000)));

INSERT INTO Dipartimenti

VALUES(32,’Marketing’,1000000000,

Lista_Progetti(Progetto(1,’Nuova Pubblicità’,10000000),

Progetto(3,’Incentivi Personale’,20000000)));

Page 197: Basi di Dati Relazionali ad Oggetti

197

Nested table - creazione

CREATE TYPE Corso AS OBJECT(id NUMBER(4),nome VARCHAR2(25),crediti NUMBER(1));

CREATE TYPE Lista_Corsi AS TABLE of Corso;

Page 198: Basi di Dati Relazionali ad Oggetti

198

Nested table - creazione

CREATE TYPE Dipartimento AS OBJECT(nome VARCHAR2(20),direttore VARCHAR2(20),corsi Lista_Corsi)NESTED TABLE corsi STORE AS corsi_tab;

CREATE TABLE Dipartimenti OF Dipartimento

NESTED TABLE corsi STORE AS corsi_tab;

Page 199: Basi di Dati Relazionali ad Oggetti

199

Nested Table - creazione

Notare la clausola NESTED TABLE nel lucido precedente Questa clausola è necessaria perché le colonne definite

come nested table sono memorizzate come tabelle separate Il formato generale della clausola è

NESTED TABLE colname STORE AS tablename

La tabella tablename si dice “child-table” della tabella al cui interno è definita (detta “parent-table”)

Una child-table può essere acceduta solo tramite la parent-table

Page 200: Basi di Dati Relazionali ad Oggetti

200

Nested table: inserimento

INSERT INTO Dipartimenti

VALUES(‘Informatica’,’Italiani’,

Lista_Corsi(Corso(1000,’Programmazione I’,2),

Corso(1001,’Logica Matematica’,1),

Corso(1002,’Basi di Dati’,2),

Corso(1003,’Grafica’,1)));

Page 201: Basi di Dati Relazionali ad Oggetti

201

Tipi collezione - interrogazione

Due possibilità– selezionare la collezione annidata

una tupla per ogni collezione

– selezionare la collezione, non annidata una tupla per ogni elemento della collezione funzione TABLE

applicabili sia a VARRAY che NESTED TABLE

Page 202: Basi di Dati Relazionali ad Oggetti

202

Selezione annidata - esempio

SELECT corsi

FROM Dipartimenti;

il risultato è

Lista_Corsi(Corso(1000,’Programmazione I’,2),

Corso(1001,’Logica Matematica’,1),

Corso(1002,’Basi di Dati’,2),

Corso(1003,’Grafica’,1))

Page 203: Basi di Dati Relazionali ad Oggetti

203

Selezione non annidata - esempio

SELECT t.*

FROM Dipartimenti d, TABLE(d.corsi) t;

il risultato è

Corso(1000,’Programmazione I’,2)

Corso(1001,’Logica Matematica’,1)

Corso(1002,’Basi di Dati’,2)

Corso(1003,’Grafica’,1)

Page 204: Basi di Dati Relazionali ad Oggetti

204

Funzione TABLE

La funzione TABLE prende un valore di tipo collezione e permette di utilizzarlo come una tabella

la query precedente realizza un join di ogni tupla della tabella dipartimento con ogni elemento dell’oggetto collezione

può anche essere applicata a query che restituiscono un singolo valore di tipo collezione

Page 205: Basi di Dati Relazionali ad Oggetti

205

Esempio

SELECT d.nome, t.*

FROM Dipartimenti d, TABLE(d.corsi) t;

il risultato è

‘Informatica’ Corso(1000,’Programmazione I’,2)

‘Informatica’ Corso(1001,’Logica Matematica’,1)

‘Informatica’ Corso(1002,’Basi di Dati’,2)

‘Informatica’ Corso(1003,’Grafica’,1)

Page 206: Basi di Dati Relazionali ad Oggetti

206

Esempio

SELECT * FROM

TABLE(SELECT corsi FROM Dipartimenti

WHERE nome = ‘Psicologia’);

restituisce le informazioni sui corsi del dipartimento Psicologia

SELECT crediti FROM

TABLE(SELECT corsi FROM Dipartimenti

WHERE nome = ‘Psicologia’);

restituisce i crediti di tutti i corsi del dipartimento Psicologia

le interrogazioni sono corrette se le query a cui viene applicata la funzione TABLE restituiscono un solo elemento

Page 207: Basi di Dati Relazionali ad Oggetti

207

Tipi collezione - DML

Nested table:– la funzione TABLE può essere utilizzata per modificare una

collezione

VARRAY:– A differenza delle nested table, i singoli elementi di un varray

non possono essere manipolati mediante istruzioni SQL– Per selezionare o fare l’update di un certo elemento di un

VARRAY è necessario usare PL/SQL– supporto di funzioni specifiche per la manipolazione degli

array

Page 208: Basi di Dati Relazionali ad Oggetti

208

Nested tables

UPDATE

TABLE(SELECT corsi FROM Dipartimenti

WHERE nome = ‘Psicologia’)

SET crediti = crediti + 1

WHERE id IN (2200,3540);

DELETE FROM TABLE(SELECT corsi FROM Dipartimenti

WHERE nome = ‘Inglese’) p

WHERE p.crediti = 2;

Page 209: Basi di Dati Relazionali ad Oggetti

209

Varray

DECLARE miei_progetti lista_progetti;

SELECT progetti INTO miei_progetti.

FROM dipartimenti.

WHERE id = 30;

IF miei_progetti(i).Titolo = ‘DBMS’ …

Page 210: Basi di Dati Relazionali ad Oggetti

210

Ereditarietà

Solo a livello di tipi vale quanto detto per SQL-99 in più:

– sia tipi che metodi possono essere definiti FINAL/NOT FINAL

FINAL: overriding non possibile

– sostituibilità– late binding

Page 211: Basi di Dati Relazionali ad Oggetti

211

Sostituibilità

Possibilità di utilizzare istanze di un sottotipo in ogni contesto in cui può essere utilizzato un supertipo

sostituibilità a livello di – attributo– tupla

Page 212: Basi di Dati Relazionali ad Oggetti

212

Sostituibilità a livello di attributo

Attributo con tipo REF(<tipo1>) può contenere valori di tipo REF(<tipo2>) se <tipo2> sottotipo di <tipo1>

Attributo con tipo ADT <tipo1> può contenere valori di tipo ADT <tipo2> se <tipo2> sottotipo di <tipo1>

Attributo con tipo collezione su tipo <tipo1> può contenere valori di tipo <tipo2> se <tipo2> sottotipo di <tipo1>

Page 213: Basi di Dati Relazionali ad Oggetti

213

Sostituibilità a livello di tupla

Una tabella tipata su tipo <tipo1> può contenere istanze del tipo <tipo2> se <tipo2> sottotipo di <tipo1>

Page 214: Basi di Dati Relazionali ad Oggetti

214

Esempio

CREATE TYPE Person_typ AS OBJECT

( ssn NUMBER,

name VARCHAR2(30),

address VARCHAR2(100)) NOT FINAL;

CREATE TYPE Student_typ UNDER Person_typ

( deptid NUMBER,

major VARCHAR2(30)) NOT FINAL;

CREATE TYPE PartTimeStudent_typ UNDER Student_typ

( numhours NUMBER);

Page 215: Basi di Dati Relazionali ad Oggetti

215

Esempio (su attributi)

CREATE TABLE Dipartimenti( Id INTEGER,

nome VARCHAR(20),manager Person_typ);

INSERT INTO dipartimentiVALUES (1,’ricerca’, Person_typ(1243, 'Bob', '121 Front St'));

INSERT INTO dipartimentiVALUES (2,’sviluppo’,Student_typ(3456, 'Joe', '34 View', 12, 'HISTORY'));

INSERT INTO dipartimentiVALUES (3, ‘testing’,PartTimeStudent_typ(5678, 'Tim', 13, 'PHYSICS', 20));

Page 216: Basi di Dati Relazionali ad Oggetti

216

Esempio (su tuple)

CREATE TABLE persons OF Person_typ;

INSERT INTO persons

VALUES (Person_typ(1243, 'Bob', '121 Front St'));

INSERT INTO persons

VALUES (Student_typ(3456, 'Joe', '34 View', 12, 'HISTORY'));

INSERT INTO persons

VALUES (PartTimeStudent_typ(5678, 'Tim', 13, 'PHYSICS', 20));

Page 217: Basi di Dati Relazionali ad Oggetti

217

Limitare sostituibilità

CREATE TABLE Dipartimenti( Id INTEGER,

nome VARCHAR(20),manager Person_typ)

COLUMN manager NOT SUBSTITUTABLE AT ALL LEVELS;

Manager può solo essere una persona (sottotipi non ammessi)

CREATE TABLE persons OF Person_typ NOT SUBSTITUTABLE AT ALL LEVELS;

la tabella persons può contenere solo persone

Page 218: Basi di Dati Relazionali ad Oggetti

218

Limitare sostituibilità

CREATE TABLE Dipartimenti( Id INTEGER,

nome VARCHAR(20),manager Person_typ)

COLUMN manager IS OF (ONLY Student_typ);

Si può specificare solo un sottotipo

Page 219: Basi di Dati Relazionali ad Oggetti

219

Interrogazioni

Funzioni utili:– REF– DEREF– VALUE– IS OF TYPE– ...

REF, DEREF, VALUE già viste

Page 220: Basi di Dati Relazionali ad Oggetti

220

Esempio

Si consideri la tabella Dipartimenti presentata in precedenza (senza limitazioni di sostituibilità)

SELECT *

FROM Dipartimenti p

WHERE p.manager IS OF (Student_typ,PartTimeStudent_typ)

restituisce i dipartimenti i cui manager sono studenti o studenti part-time

Page 221: Basi di Dati Relazionali ad Oggetti

221

Esempio

Si consideri la tabella Persons presentata in precedenza (senza limitazioni di sostituibilità)

SELECT *

FROM Persons p

WHERE VALUE(p) IS OF (Student_typ,PartTimeStudent_typ)

restituisce le persone che sono studenti o studenti part-time

Page 222: Basi di Dati Relazionali ad Oggetti

222

Differenze principali con SQL-99

Tipi collezione– SQL-99: solo ARRAY– Oracle: VARRAY e NESTED TABLE

Ereditarietà– SQL-99: su tipi e tabelle, no sostituibilità– Oracle: solo su tipi sostituibilità

Page 223: Basi di Dati Relazionali ad Oggetti

223

Utilizzo di funzionalità OR da JDBC

Consideriamo JDBC 3 (ma molte estensioni già presenti in JDBC 2)

Nuove interfacce per implementare mapping di tipi object relational in tipi Java

Page 224: Basi di Dati Relazionali ad Oggetti

224

Creazione nuovi tipi

Essendo un comando DDL, si utilizza il metodo executeUpdate

String type = ‘CREATE TYPE t_indirizzo AS

numero_civico INTEGER,

via VARCHAR(50),

città CHAR(20),

stato CHAR(2),

cap INTEGER’;

Statement st = con.createStatement( );

st.executeUpdate(type);

Page 225: Basi di Dati Relazionali ad Oggetti

225

Manipolazione valori nuovi tipi da Java

Nuove interfacce (solo per tipi standard):– STRUCT

per mappare ADT

– REF per mappare valori di tipo riferimento

– ARRAY per mappare valori di tipo array

– SQLDATA per semplificare mapping di ADT

Page 226: Basi di Dati Relazionali ad Oggetti

226

Manipolazione valori nuovi tipi da Java

Per ogni interfaccia, il driver prescelto specificherà una classe che implementa l’interfaccia

questo permette di gestire le eventuali differenze esistenti tra DBMS

Page 227: Basi di Dati Relazionali ad Oggetti

227

Tipi semplici

Nessuna nuova interfaccia si manipolano utilizzando i metodi del tipo di

base Esempio

– CREATE TYPE id_impiegato AS INTEGER FINAL;

– Si usano i metodi getInt e setInt per leggere e scrivere campi di tipo id_impiegato

Page 228: Basi di Dati Relazionali ad Oggetti

228

ADT

Le istanze di tipi ADT vengono mappate in istanze di classe Struct

un oggetto di tipo Struct contiene un valore per ogni attributo dell’ADT a cui si riferisce

i metodi per poter leggere e scrivere valori di attributi con tipo ADT sono

– ResultSet - getObject(int): per accedere attributi di tipo ADT– Struct - getAttributes(): per accedere le componenti di un’istanza– PreparedStatement - setObject(int, Struct): per settare parametri

di tipo ADT

Page 229: Basi di Dati Relazionali ad Oggetti

229

Esempio

CREATE TABLE Impiegati (

imp# INTEGER PRIMARY KEY,

nome CHAR(20),

indirizzo t_indirizzo);

vogliamo attribuire l’indirizzo dell’impiegato 12 a Verdi

Page 230: Basi di Dati Relazionali ad Oggetti

230

Esempio (continua)

String query = “select indirizzo from Impiegati where imp# = 12”;

Statement st = con.createStatement();

ResultSet rs = st.executeQuery(query);

rs.next();

Struct indirizzo = (Struct) rs.getObject(1); //si ottiene l’istanza

Object[ ] ind_attr = indirizzo.getAttributes(); //si accedono gli attributi

System.out.print( “Via ” + ind_attr[1] + “ “ + ind_attr[0] + “ “ + ind_attr[2] + “ “ + ind_attr[4] + “ “ + ind_attr[3]);

Page 231: Basi di Dati Relazionali ad Oggetti

231

Esempio (continua)

String up = “update Impiegati set indirizzo = ? where nome =‘Verdi’”;

PreparedStatement pst = con.prepareStatement(up);

pst.setObject(1, indirizzo);

pst.executeUpdate( );

Page 232: Basi di Dati Relazionali ad Oggetti

232

Tipi riferimento

Le istanze di tipi riferimento (puntatori) vengono mappate in istanze di classe Ref

i metodi per poter leggere e scrivere valori di attributi con tipo riferimento sono

– ResultSet - getRef(int): per accedere attributi di tipo riferimento– Ref - getObject( ): dato un valore di tipo riferimento, restituisce

l’oggetto puntato (solo JDBC 3)– Ref - setObject(Struct): il parametro diventa il nuovo oggetto

puntato (solo JDBC 3)– PreparedStatement - setRef(int, Ref): per settare parametri di

tipo riferimento

Page 233: Basi di Dati Relazionali ad Oggetti

233

Esempio

CREATE TYPE t_progetto ASprj# INTEGER,nome VARCHAR(20),descrizione VARCHAR(50),budget INTEGER;

CREATE TABLE Progetti of t_progetto;

CREATE TABLE Impiegati(imp# INTEGER PRIMARY KEY,nome VARCHAR(50),indirizzo t_indirizzo,assegnamento REF(t_progetto));

Page 234: Basi di Dati Relazionali ad Oggetti

234

Esempio (continua)

Si vuole associare il progetto dell’impiegato 12 a Verdi e visualizzare le informazioni su tale progetto

Page 235: Basi di Dati Relazionali ad Oggetti

235

Esempio (continua)

String query = “select assegnamento from Impiegati where imp# = 12”;

Statement st = con.createStatement(query);

ResultSet rs = st.executeQuery();

rs.next();

Ref assegn_ref = rs.getRef(1); //si ottiene l’identificatore

String update = ‘”update impiegati set assegnamento = ? where nome = “Verdi”;

PreparedStatement pst = con.prepareStatement(update);

pst.setRef(1,assegn_ref);

pst.executeUpdate( );

Page 236: Basi di Dati Relazionali ad Oggetti

236

Esempio (continua)

Struct progetto = (Struct) assegn_ref.getObject( );

Object [ ] prog_attr = progetto. getAttributes();

System.out.print(ind_attr[0] + “ “ + ind_attr[1] + “ “ + ind_attr[2] + “ “ + + ind_attr[3]);

Page 237: Basi di Dati Relazionali ad Oggetti

237

Tipi array

Le istanze di tipi array vengono mappate in istanze di classe Array rappresentano puntatori alla base di dati (il contenuto non viene

copiato) i metodi per poter leggere e scrivere valori di attributi di tipo array

sono– ResultSet - getArray(): per accedere attributi di tipo array (restituisce un

puntatore all’istanza)– Array - getArray( ): permette di copiare i dati contenuti nell’array in

strutture locali al programma– Array - getResultSet (): restituisce un result set che contiene una tupla

per ogni elemento dell’array, con due colonne. La prima contiene l’indice (partendo da 1), la seconda il valore

– PreparedStatement - setArray(int,Array): per settare parametri di tipo Array

Page 238: Basi di Dati Relazionali ad Oggetti

238

Esempio

CREATE TABLE Impiegati(imp# INTEGER PRIMARY KEY,nome VARCHAR(50),indirizzo t_indirizzo,competenze VARCHAR(20) ARRAY[10]);

si vogliono stampare tutte le competenze dell’impiegato 12

Page 239: Basi di Dati Relazionali ad Oggetti

239

Esempio (continua)

String query = “select competenze from Impiegati where imp# = 12”;

Statement st = con.createStatement(query);

ResultSet rs = st.executeQuery();

rs.next();

Array comp = rs.getArray(1); //restituisce un puntatore all’array

String [ ] comp_arr = (String [ ]) comp.getArray( );

for (int i = 0; i < comp_arr.length(); i++)

System.out.print(comp_arr[i])

Page 240: Basi di Dati Relazionali ad Oggetti

240

Tipi collezione

Come abbiamo visto i sistemi non sono conformi allo standard per quanto riguarda i tipi collezione

il driver potrà eventualmente utilizzare la classe Array anche per gestire altri tipi collezione– in JDBC le nested table di Oracle si mappano in

oggetti di tipo Array

Page 241: Basi di Dati Relazionali ad Oggetti

241

SQL Data

Interfaccia ogni classe che implementa SQLData permette di

definire un mapping esplicito tra un tipo SQL e una classe Java– casting definito esplicitamente dall’utente

semplifica l’accesso agli oggetti strutturati– la lettura di un oggetto restituisce un’istanza della classe

associata dal mapping– non si devono piu’ utilizzare Struct e Object

non lo vediamo