4a-Basi di dati relazionali ad oggetti

1
4a-Basi di dati relazionali ad oggetti
2
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.
• Lapproccio 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.

3
Modello dei dati di SQL1999

• E compatibile con il modello relazionale ad es
• create table Persona(
• Nome varchar(40) not null
• Residenza varchar(30)
• Codfisc char(16)primary key
• )
• Lapproccio ORDBMS suggerisce di definire
  prima il tipo (riga, row) Persona, chiamiamolo
  TipoPersona, per renderlo riusabile.
• Luso di tipi strutturati, che estendono la
  nozione classica di dominio ( tipo distinto in
  SQL1999), consente di costruire innanzitutto la
  struttura delle tuple (row) da inserire in
  tabella.

4
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

5
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

6
Riferimenti

• create type TipoCostr(
• Presidente ref (TipoPersona),
• Stabilimento ref (TipoStabilimento) Nome
  varchar (20)
• )
• Gli oggetti TipoCostr hanno il seguente aspetto

F I A T
Ad un oggetto TipoPersona
Ad un oggetto TipoStabilimento
7
Tipi strutturati approfondimento

• Definizione della tabella persona in SQL1999
• 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 è lattributo da
  utilizzare per
• realizzare
  riferimenti a istanze del tipo.
• ref is CodFisc derived specifica che
  lidentificatore è derivato dal valore
  dellattributo CodFisc.

8
Tipi strutturati - approfondimento

• Possibile riuso del tipo persona
• Create table Presidente of TipoPersona (
• Ref is CodFisc derived)
• Create table Pilota of TipoPersona (
• Ref is Codfisc derived
• Si noti la corrispondenza
• (Tupla, oggetto)
• (tabella, classe)
• conformemente ai DB ad oggetti.

9
Esempio tipi strutturati
10
Esempio tipi strutturati

• Consideriamo la definizione dei corrispondenti
  tipi tupla per la fig. precedente che includono
  TipoPersona già visto.
• Si noti luso del costrutto
• varray il costruttore di insiemi set of non è
  previsto in SQL1999
• ref is system generated lattributo da
  utilizzare per realizzare riferimenti a istanze
  del tipo ( OID REF) è automaticamente generato
  dal sistema.

11
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 VARRAY10of TipoStab)
• not final
• ref is system generated
• create type TipoPartiAuto(
• Motore char(10),
• Ammortizzatore char(5))
• not final
• create type TipoAuto(

12
Complessità strutturale

• TipoStab presente nellambito di TipoCostr e
  TipoPartiAuto presente nellambito 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.

13
Le tabelle (classi) dellesempio

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

14
Definizione di identificatori

• Nella definizione di TipoAuto (TipoCostr) non
  compare esplicitamente il nome dellattributo 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.

15
with options

• Il costrutto with options consente di fornire
  maggiori dettagli o imporre restrizioni su
  componenti del tipo quando esso viene utilizzato
  nellambito di una tabella .
• Qui viene usato per associare la clausola scope
  allattributo 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.

16
Supporto per lintegrità referenziale

• In SQL1999 occorre, se sul tipo è imposta
  lintegrità 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.

17
Gerarchie di tipo

• In SQL1999 vi sono gerarchie di tipo e di
  tabella
• Le Gerarchie di tipo estendono i tipi già
  definiti , come nel caso di TipoAuto dellesempio
  seguente
• create type TipoAutoStorica(
• AnnoCostr integer)
• under TipoAuto
• not final
• dove TipoAutoStorica aggiunge lattributo
  AnnoCostr a TipoAuto.

18
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

19
Tipi instanziabili e non

• I tipi definiti dallutente 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
  allinterno della definizione di altri tipi o
  tabelle.
• Il comportamento è analogo a quello delle classi
  astratte di Java o del modello ad oggetti.

20
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
• linterfaccia comprende tutte le informazioni che
  permettono di invocare un metodo (il tipo dei
  parametri)
• limplementazione 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

21
Metodi

• In prima approssimazione, i metodi possono essere
  dei seguenti tipi
• costruttori per costruire oggetti a partire da
  parametri di ingresso (restituendo lOID
  delloggetto 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
  lincapsulamento dei dati

22
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
  listanza su cui viene invocato il metodo e
  unaltra 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

23
Metodi implementazione

• I metodi definiti possono essere realizzati in
  SQL1999 oppure in un linguaggio esterno (vedi
  nellesempio C per DisegnoDisponibile)
• Occorre definire la segnatura con i parametri di
  ingresso e quello di uscita e poi
  limplementazione
• Calcolo della potenza di ciascun cilindro del
  motore
• Create instance method PotUnitaria()
• returns float
• for TipoPartiAuto
• return (cast(Self.Potenza as float)/
  Self.NumCilindri)

24
Metodi implementazione

• Confronto tra listanza di TipoPartiAuto su cui
  viene invocato il metodo con unaltra istanza
  dello stesso tipo che viene passata come
  parametro
• Create instance method MaggiorPotUnitaria
• (ParteCfr TipoPartiAuto)
• returns boolean
• for TipoPartiAuto
• Return
• ((Self.PotUnitaria gt ParteCfr.PotUnitaria)
  or((Self.PotUnitaria gt ParteCfr.PotUnitaria)
  and(Self.Cilindrata gt ParteCfr.Cilindrata)))

25
Metodi implementazione

• Nelle implementazioni i valori degli attributi
  sono raggiunti con una notazione a punto (dot
  notation) per estrarre lattributo referenziato
  da una variabile.
• E da notare che nel metodo MaggiorPotUnitaria
  venga utilizzato il metodo PotUnitaria.
• In SQL1999 si fa riferimento a una
  implementazione esterna realizzata in uno
  specifico linguaggio con
• Create instance method DisegnoDisponibile()
• return boolean
• external name Mia ProceduraC

26
Interrogazioni in SQL1999

• Le interrogazioni SQL-2 sono completamente
  ammesse in SQL1999
• select Nome
• from Persona
• where CodFisc TRESFN56D23S541S
• La navigazione lungo i riferimenti tra i tipi
  richiede loperatore 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 -gt A

27
Interrogazioni in SQL1999

• Il seguente esempio mostra luso delloperatore
  di dereferenziamento per accedere al valore
  dellattributo Nome delloggetto della tabella
  INDUSTRIALE puntato dalloggetto della tabella
  COSTRUTTORE che è puntato a sua volta
  dallautomobile che soddisfa il predicato
  TargaDB123MS
• select Costruttore -gt Presidente -gt Nome
• from Automobile
• where Targa DB123MS

28
Interrogazioni in SQL1999

• In SQL1999 gli attributi di tipo REF possono
  essere esplicitamente utilizzati nelle
  interrogazioni e confrontati con loperatore
  con i riferimenti a tuple dello stesso tipo
• Select Industriale,Nome
• From Automobile, Costruttore, Industriale
• where Automobile.TargaDB123MS
• and Automobile.CostruttoreCostruttore.Cos
  trId
• and Costruttore.PresidenteIndustriale.Cod
  Fisc
• Linterrogazione costruisce un join tra le
  tabelle AUTOMOBILE, COSTRUTTORE, INDUSTRIALE, in
  cui
• lattributo Costruttore di AUTOMOBILE viene
  confrontato con lidentificatore CostrId di
  COSTRUTTORE e
• lattributo Presidente di COSTRUTTORE viene
  confrontato con lidentificatore CodFisc di
  INDUSTRIALE.

29
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)"

30
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

31
I CONCETTI DEL MANIFESTO

• Un 3GDBMS deve avere un sistema di tipi ricco,
  che tra laltro 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
  caratteristi-che utili specie se accompagnate
  dallincapsulamento.
• Ha senso che il sistema assegni OID agli oggetti
  solo se non è disponibile una chiave primaria tra
  gli attributi definiti dallutente 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.

32
Manifesto 3GDBMS dettagli

• 1.1 rich type system1.2 inheritance1.3
  functions and encapsulation1.4 OID's only if
  there are no keys1.5 rules and triggers
• 2.1 non procedural, high level access
  languages2.2 specification techniques for
  collections2.3 updatable views2.4
  transparency of physical parameters
• 3.1 multiple high level languages3.2
  persistent x, for many x's3.3 SQL is a
  standard (even if you don't like it)3.4
  queries and their results are the lowest level of
  communication