Introduzione - Progetto Atena

Sistemi di Gestione
di Basi di dati
File System vs DBMS
_ Un file è una collezione di dati che
risiede su un dispositivo di memoria
esterna ed è strutturata in accordo ai
requisiti di un'applicazione.
Emissione
fatture
Inserimento
Ordini
Registro
fatture
Indirizzo
Cliente
Anagrafe
clienti
Indirizzo
Cliente
Ordini
Indirizzo
Cliente
Fatture
La ripetizione dell'indirizzo del cliente consente alle applicazioni
Registro fatture e inserimento ordini di operare allo stesso tempo
_ Programmi individuali
accedono, di
solito, in modo esclusivo ai file. Per
raggiungere
un
ragionevole
grado
di
efficienza, si introduce ridondanza nelle
informazioni
Introduzione ai DBMS
pag. 1
_ La ridondanza riduce il numero di
risorse
che
devono
essere
'locked',
quando più applicazioni sono attive.
_ Ciò comporta tuttavia l'adozione di
tecniche atte a garantire la consistenza
delle informazioni.
_ A causa delle limitate possibilità di
cooperazione tra file, le applicazioni
costruite su un file system si basano
sui
metodi
di
accesso
messi
a
disposizione dal sistema operativo e
sulle organizzazioni di file disponibili
nel linguaggio di programmazione.
_ Di
solito
organizzazioni:
sono
disponibili
_
sequential
_
relative
_
indexed-sequential
Introduzione ai DBMS
pag. 2
le
_ Un database
è una collezione di
oggetti
che richiede un dispositivo di
memoria esterna ad accesso diretto. Un
DBMS (Data Base Management
System)
ha capacità di gestire grandi moli di
dati in un ambiente multiutente.
_ Dal punto di vista fisico, ovvero del
sistema operativo, anche un database
consiste di
file.
Tuttavia
un
DBMS
consente
elaborazione
concorrente,
mantiene
la
consistenza
delle
informazioni minimizzando la ridondanza,
offre
supporto
per
test
e
prototipazione, permette indipendenza
del software dalla organizzazione fisica
e logica delle strutture dati.
Emissione
fatture
Indirizzo
cliente
Inserimento
Ordini
DBMS
Ordini
Registro
fatture
Fatture
Una granularita' piu' fine consente l'uso condiviso della
risorsa indirizzo cliente
Introduzione ai DBMS
Anagrafe
clienti
pag. 3
_ Un DBMS è costruito sopra il sistema
operativo ed
amplia
la
gamma
delle
strutture di accesso messe a disposizione
dal file system. In sintesi, in una base
di dati la gestione delle informazioni è
logicamente
centralizzata
in
una
rappresentazione
integrata
e
non
ridondante.
_ Dal punto di vista utente un database
e' visto come una collezione di dati che
modellano
una
certa
porzione
della
realta' di interesse.
_ L'astrazione logica con cui i dati
vengono
resi
disponibili
all'utente
definisce un modello dei dati
Es:
* Un file è una sequenza di record:
type persona = record
cognome, nome: string[20];
ntel:
string[16];
..........
end;
Il concetto di file è legato ad una profonda conoscenza,
da parte dell'utente, dei meccanismi di memorizzazione
fisica e delle modalità di accesso.
* Una relazione è un'astrazione di file: un insieme di
ennuple (tuple) in cui non viene specificato l'ordine
PERSONE(Cognome, Nome, Ntel, ......)
Il concetto di relazione svincola ulteriormente l'utente
dai dettagli della rappresentazione interna.
Introduzione ai DBMS
pag. 4
Peculiarità dei DBMS
_
gestione efficiente di grandi moli di
dati persistenti
_ supporto
dati
_
per
almeno
un
modello
dei
linguaggi di alto livello per
_
definizione dati
(DDL = Data Definition L.)
_
manipolazione dei dati (DML=Data
Manipulation
L.)
_
controllo dei dati
(DCL=Data Control L.)
_
gestione delle transazioni
_
controllo degli accessi
_
resilienza
= capacita' di garantire l'integrita' dei dati in
seguito a anomalie di funzionamento di varia natura
_
ambiente di sviluppo
_
_
_
_
_
_
generatori di applicazioni
linguaggi di IV generazione
interfacce evolute
strumenti di riorganizzazione archivi
strumenti di analisi delle prestazioni
strumenti di ausilio al progetto
Introduzione ai DBMS
pag. 5
Livelli di astrazione nei
DBMS
La "classica" architettura a tre livelli
vista 1
database concettuale
vista 2
Database
fisico
vista n
DDL per
sottoschemi
DDL per schema
integrato
realizzato su
dispositivi
fisici
La presenza del livello concettuale risponde alla
necessita' di fornire caratteristiche di indipendenza
fisica che possano consentire la riorganizzazione dei
dati su disco senza comportare effetti collaterali sui
programmi applicativi che li usano. Allo stesso tempo il
livello concettuale fornisce una visione integrata
dei dati.
La presenza del livello esterno (o delle viste) va
nella direzione di assicurare l'indipendenza logica
dei dati: l'utente ha la possibilita' di "vedere" i dati
(o solo parte di essi) scegliendo l'astrazione piu'
conveniente.
Introduzione ai DBMS
pag. 6
Livello fisico (interno)
Il physical database e' una collezione
di archivi
e
relative
strutture
di
accesso che risiede permanentemente su
memorie di massa.
Il livello interno riguarda il modo in
cui le informazioni sono organizzate e
gestite sui dispositivi fisici.
La descrizione di una base di dati a
questo livello viene chiamata physical
schema (schema interno).
Il progetto
fisico
di un database
riguarda problemi legati principalmente
a:
_
criteri di allocazione dei dati
partizionamento, ordinamento,
_
scelta dei metodi di accesso
Introduzione ai DBMS
pag. 7
Livello concettuale
Il conceptual database e' un'astrazione
del
mondo
reale
come
percepito
(globalmente) dagli utenti.
Un
DBMS
mette
a
disposizione
un
linguaggio
DDL
(Data
Definition
Language)
per
la
descrizione
del
conceptual
schema
e
per
la
sua
(parziale)
realizzazione
in
un
corrispondente schema fisico.
Il DDL consente di definire lo schema
concettuale in termini di data model
(modello dei dati). Si parla dunque di
modello
relazionale,
reticolare,
gerarchico,
logico,
a
oggetti,
a
seconda del tipo di
DBMS. Ad esempio,
facendo uso del modello relazionale e del
linguaggio
SQL
(Structured
Query
Language):
create table STUDENTI
(
Matricola
char(5)
not null,
Cognome
char(20) not null,
Nome
char(20)
not null,
Data_di_nascita
char(6)
not null,
Telefono
char(10)
);
create table ESAMI
(
Matricola
CodCorso
Denominazione
Voto
Data
Introduzione ai DBMS
char(5)
char(5)
char(30)
integer
char(6)
pag. 8
not
not
not
not
not
null,
null,
null,
null,
null);
Lo schema concettuale rende trasparente
l'implementazione fisica dei dati
Per le relazioni STUDENTI ed ESAMI e' possibile avere
due file distinti, oppure un unico file le cui pagine
contengono un record di STUDENTI e N record di ESAMI (e'
la soluzione adottata, ad es., dai DBMS ORACLE e SUPRA).
Matric
ola
Cognome
Nome D atanascita
12045
Giuliani
Marco 27/02/71
12045
1027
Analisi I
25
4/6/91
12045
1045
Fisica
30
10/7/91
12045
112
TAMC
28
12/10/91
12045
1190
Algebra
30
18/2/92
12045
1132
Geometria
Matricola
Co
dCorso
I
27
Tel.
051-24451
21/5/92
Denominazione
Uno schema concettuale viene costruito in
modo da integrare le diverse esigenze di
trattamento
delle
informazioni
degli
utenti di uno stesso database.
Il processo che porta alla definizione,
in sede di progetto, di una struttura
unificante viene detto database
view
integration ed implica l'unificazione di
schemi concettuali parziali.
Introduzione ai DBMS
pag. 9
Limitazioni
dei D D L
Spesso il formalismo impiegato per il
progetto di un database è più ricco
semanticamente del DDL del DBMS. E'
necessario allora un ulteriore passo d i
progetto
che
traduca
dallo
schema
concettuale impiegato per descrivere il
mondo reale allo schema concettuale (ora
chiamato
piu'
propriamente
schema
logico) disponibile nell'ambiente del
DBMS. Si distingue pertanto tra progetto
concettuale e progetto logico.
Impiegato =
persona caratterizzata da: codice (Cod)
nome (Nome)
diretto superiore(Cod_dir)
Lo schema concettuale deve modellare l'entita' Impiegato
e la relazione transitiva di "superiore".
impiegato(Cod,Nome,Cod_dir).
superiore(Cod_sup,Cod_imp) :impiegato(Cod_imp,_,Cod_sup).
superiore(Cod_sup,Cod_imp) :impiegato(Cod_imp,_,Cod_dir),
superiore(Cod_sup,Cod_dir).
I
modelli
relazionale,
gerarchico
e
reticolare non dispongono degli strumenti
necessari per esprimere uno schema di
questo tipo. Occorre complementare il DDL
a disposizione con strutture di altro
tipo (ad es. funzioni C, regole Prolog,
ecc)
Introduzione ai DBMS
pag. 10
Livello esterno
Una view (vista) o sottoschema è
porzione di uno schema concettuale.
La costruzione di viste è
inverso
dell'integrazione
concettuali parziali.
una
il processo
di
schemi
Molti DBMS forniscono una sintassi per la
definizione di sottoschemi e per la
manipolazione delle viste generate.
Data la relazione:
PERSONE(Nome,CodFisc,Reddito,Indirizzo,Data_nascita)
si può definire una vista in SQL mediante :
create view PERSONE_RICCHE
as select CodFisc,Nome
from
PERSONE
where Reddito > 100,000,000
La vista PERSONE_RICCHE non corrisponde ad un vero file
fisico, pur essendo interrogabile come se lo fosse:
select
Nome
from
PERSONE_RICCHE
where CodFisc='TRLFLV51M27F839X'
Introduzione ai DBMS
pag. 11
Le viste consentono di:
a) raggiungere un livello di astrazione
maggiore
rispetto
al
modello
concettuale integrato del database.
Un ufficio vendite vuole disporre di una vista sui
propri clienti che contenga l'attributo età.. Tuttavia,
poichè l'età cambia di giorno in giorno, nel modello
concettuale integrato sarà previsto di memorizzare la
data di nascita per ogni cliente. Ciò implica che
l'interrogazione di una vista può comportare un calcolo
per
rendere
disponibile
all'utente
un
dato
che
concettualmente, nella sua visione esterna, fa parte del
proprio sottoschema.
b) consentire
un
certo
livello
di
indipendenza
logica
a
fronte
di
ristrutturazioni
dello
schema
concettuale
Si supponga che la relazione
STRADE(Nome,Lung,Larg,Zona,Max_Civico)
venga ridefinita come
S_Z(Nome,Zona,Max_Civico)
S_LL(Nome,Lung,Larg)
E' possibile preservare la visione originaria definendo
la vista:
create view STRADE(Nome,Lung,Larg,Zona,Max_Civico)
as select S_LL.Nome,S_LL.Lung,S_LL.Larg,
S_Z.Zona,S_Z.Max_Civico
from
S_Z,S_LL
where S_LL.Nome = S_Z.Nome
che sfrutta la corrispondenza biunivoca tra le tuple di
S_Z e S_LL
Introduzione ai DBMS
pag. 12
c) definire diverse classi di utenti,
assegnando
ad
ognuna
diversi
privilegi. Le viste costituiscono un
semplice meccanismo di sicurezza dei
dati
realizzato
attraverso
l'occultamento di informazione.
Facendo uso della vista PERSONE_RICCHE, il DBMS puo'
distinguere, ad esempio, tra:
a)
b)
c)
utenti con accesso in lettura e scrittura alla
relazione PERSONE
utenti con accesso in sola lettura alla relazione
PERSONE
utenti con accesso in sola lettura alla vista
PERSONE_RICCHE
Per distinguere i casi a) e b) occorrono
altri strumenti (autorizzazioni)
N.B. La classe
d)
utenti con accesso in lettura e scrittura alla vista
PERSONE_RICCHE
non puo' esistere! Ad es.
insert into PERSONE_RICCHE(CodFisc,Nome)
values ('TRLFLV51M27F839X','Flavia')
darebbe luogo ad un inserimento reale in
PERSONE della tupla
('TRLFLV51M27F839X','Flavia',?,?,?)
che non soddisfa Reddito > 100,000,000
Introduzione ai DBMS
pag. 13
Modelli dei dati
Un modello dei dati e' una collezione di
concetti che possono venire usati per
descrivere un insieme di dati, le loro
associazioni,
e
le
operazioni
che
agiscono sui dati stessi.
Una distinzione importante
modelli dei dati in:
Modelli
suddivide
i
concettuali:
utilizzati per descrivere la porzione
di mondo che viene rappresentata nel
Database, facendo uso di meccanismi
di astrazione;
importanti
per
la
fase
di
progettazione concettuale di un DB.
Modelli
logici:
forniscono una descrizione dei dati
che e' direttamente supportata dal
DBMS;
rappresentano un target per la fase
di progettazione logica;
permettono un mapping semplice con le
strutture del DB fisico;
sono il punto di riferimento per chi
sviluppa applicazioni su DBMS.
Introduzione ai DBMS
pag. 14
Modello
Entity-Relationship (E/R)
[Chen 1970]
Corsi
Studenti
fr equentan o
tenuti _da
in_gru ppo_con
D ocenti
Lo
schema
modella
una
realta'
descrivibile a parole come segue:
I Corsi sono tenuti da Docenti
Gli Studenti frequentano i Corsi
Gli Studenti sono in gruppo con altri Studenti
Lo schema non puo' fornire informazioni
su quali gruppi sono presenti nei vari
corsi (l'associazione in_gruppo_con non
riguarda i Corsi)
Lo schema scheletro non dice:
quanti Corsi puo' tenere un Docente;
cos'e' un Corso (se e' sdoppiato o meno), ecc.
Esempio
di
Introduzione ai DBMS
riferimento
pag. 15
Par ti
For ni tor i
P_F (for nitu re)
Parte: caratterizzata da
{unico}
Codice (P#)
Nome (PName)
Colore (Color)
Peso (Weight)
Citta' (City)
Fornitore: caratterizzato da Codice (S#)
{unico}
Nome (Sname)
Livello (Status)
Citta' (City)
Fornitura: caratterizzata da Codice Parte
(P#)
Codice Fornitore (S#)
Quantita' (Qty)
Informazioni aggiuntive:
Una Parte puo' essere fornita da piu' Fornitori
Un Fornitore puo' fornire piu' Parti
N.B. Tutto cio' puo' essere espresso (graficamente o
meno) facendo uso del formalismo del modello E/R
Introduzione ai DBMS
pag. 16
Modello
Reticolare
Il modello reticolare scaturisce dal
report del 1971 del CODASYL DBTG (Data
Base Task Group) mirante a fornire uno
standard
nel
settore.
Sistemi commerciali:
IDS II
DBMS-11
VAX-DBMS
Honeywell
Digital
"
IDMS
Computer Associates
DMS 1100
Univac
IMAGE
Hewlett-Packard
Il modello si basa sui due concetti base
di record type e set type.
record type: descrive la struttura di un
gruppo di record che memorizzano lo
stesso tipo di informazioni
set
type:
descrive una associazione
esistente tra due record types (A e
B) di tipo 1:N, ovvero:
un record di tipo A, detto owner , e'
posto in relazione a uno o piu'
record di tipo B, detti member(s).
Introduzione ai DBMS
pag. 17
Es: rappresentazione
Dipartimenti
e
relativo set type
dei
record
Impiegati
e
type
del
Ow ner
D1
I1
DEI S
M ario
150
I4
Bologna
Anna
I 20
L uca
Members
Per rappresentare la relazione tra Parti
e Fornitori (di tipo molti a molti, M:N),
si rende necessario:
1) introdurre il record
(detto link type);
type
Forniture
2) definire due set types con owner,
rispettivamente
una
Parte
ed
un
Fornitore;
3) rendere
le
Forniture
entrambi i set types.
Introduzione ai DBMS
pag. 18
member
di
S1
Smith
300
P1
20
200
Nut
P2
400
Red
Bolt
12
Jones
300
10
Paris
400
London
Green
P3
Introduzione ai DBMS
S2
London
17
Par is
Screw
pag. 19
Blue
17
Rome
Supporto
fisico
Gli elementi di un record type possono
essere memorizzati secondo tre modalita'
distinte:
DIRECT:
CALC:
VIA SET:
allocazione esplicita sul dispositivo fisico;
allocazione
via
funzione
hash;
overflow
gestito con open addressing a scansione
lineare;
allocazione contigua per elementi member
dello stesso set type; l'opzione NEAR TO
OWNER forza l'allocazione in prossimita' del
record owner.
Per quanto riguarda
gli elementi di un
avere:
i collegamenti tra
set type, si puo'
MODE IS CHAIN:
lista circolare;
MODE IS POINTER ARRAY:lista lineare;
INDEX:
struttura ad albero per i members.
DML
Le operazioni di ricerca si basano su una
visita del DB che "naviga" sui cammini
definiti
dalle
istanze
dei
set.
L'elaborazione e' "record-oriented", in
quanto si accede ad un singolo record
alla volta.
Concetto di record corrente:
a) del
programma
(ultimo
record
visitato)
b) del record type R (idem, ma relativo
a R)
c) del set type S (relativo a S, owner o
member))
Introduzione ai DBMS
pag. 20
Istruzione
FIND ANY
list>]
FIND
<record
type>
[USING
<field
trova
un
record
sulla
base
di
eventuali condizioni di eguaglianza
sui campi. (N.B.: USING = WITH)
FIND ANY Impiegati USING Nome = "Luca"
FIND
DUPLICATE
<field list>]
<record
type>
[USING
per
trovare
altri
record
soddisfano le condizioni.
che
FIND DUPLICATE Impiegati USING Nome = "Luca"
FIND
(FIRST|NEXT|PRIOR|LAST)
<record
type> WITHIN <set type> [USING <field
list>]
permette l'accesso
set type.
ai
membri
di
un
FIND FIRST Impiegati WITHIN Lavora_in
FIND
OWNER
WITHIN
trova l'owner del set
<set
type>
corrente.
FIND OWNER WITHIN Lavora_in
Istruzione
GET
GET < record type >:
restituisce il record corrente nella
variabile di programma assegnata.
GET DIPARTIMENTI;
Introduzione ai DBMS
pag. 21
Esempi:
stampa dei nomi di tutti gli impiegati di
un dipartimento
Dipartimento.Codice = $DCod
{$DCod : variabile
programma }
FIND ANY Dipartimento USING Codice
if DB_STATUS = 0
{Flag di stato}
then begin
FIND FIRST Impiegati WITHIN Lavora_in
while DB_STATUS = 0
do
begin
GET Impiegati
write Impiegati.Nome
FIND NEXT Impiegati WITHIN Lavora_in
end
end;
di
stampa del nome del mio dipartimento
dei nomi di tutti i suoi impiegati
e
Impiegati.Codice = $ICod {$ICod : e' il mio codice}
FIND ANY Impiegati USING Codice
if DB_STATUS = 0
then begin
FIND OWNER WITHIN Lavora_in
GET Dipartimento
write Dipartimento.Nome
FIND FIRST Impiegati WITHIN Lavora_in
...........
{ prosegue come sopra }
end;
Introduzione ai DBMS
pag. 22
Modello
Gerarchico
A differenza del modello relazionale, il
modello gerarchico non e' mai stato
formalmente definito. Ne' si e' avuto un
tentativo di standardizzazione simile a
quello operato dal CODASYL DBTG per il
modello reticolare.
L'origine e' industriale (IBM), e risente
fortemente dell'influenza di aspetti piu'
"fisici" che "logici"
Sistemi commerciali:
IMS (Information Management System)
IBM
E' il sistema gerarchico piu' diffuso,
che
ha
praticamente dominato il mercato dalla fine degli anni
'60 agli inizi degli anni '80, fino all'avvento dei
sistemi relazionali. Il suo DML, detto DL/I (Data
Language/I), non e' integrato nel sistema, e forza
necessariamente l'uso di un linguaggio ospite.
System 2000
MRI (ora SAS, Inc.)
L'aspetto
piu'
saliente
dei
sistemi
gerarchici e' sicuramente l'efficienza
nell'esecuzione delle operazioni che sono
conformi alla struttura prescelta per
rappresentare le associazioni tra i dati.
Introduzione ai DBMS
pag. 23
Un database gerarchico e' una foresta,
ovvero una collezione di alberi.
La scelta della struttura degli alberi
puo'
indurre
asimmetrie
nella
rappresentazione (logica e fisica), con
conseguente
sbilanciamento
delle
prestazioni.
P1
Nut
Red
S1
Smith
S2
P2
Screw
S1
Introduzione ai DBMS
10
20
Jones
Smith
17
300
Paris
London
200
Par is
17
20
300
Paris
10
Blue
London
London
Gr een
Smith
S2
P3
20
Jones
Bolt
S1
12
Rome
London
pag. 24
400
400
I concetti alla base di un DB gerarchico
sono quelli di record type (segment in
IMS) e di parent-child
relationship
type
(PCR type). Quest'ultimo e' un
legame 1:N tra un parent record type e un
child record type. In un DB gerarchico il
record type che non ha un parent e' detto
root.
La rappresentazione di associazioni M:N
(ad es. tra Fornitori e Parti) puo' dar
luogo a replicazione dei dati, a meno di
non fare uso di virtual (o pointer)
record type.
P1
Nut
S1
Red
Smith
S2
P2
Bolt
12
20
Jones
Gr een
London
London
10
Paris
17
300
300
Paris
200
400
E' anche possibile avere due gerarchie
distinte, con root Parti e Fornitori.
Introduzione ai DBMS
pag. 25
Supporto
fisico
Dato un albero di record types e PCR
types, una sua istanza e' un albero in
cui viene stabilito un ordine lineare sui
record di ogni record type.
L'albero e' memorizzato
(logicamente)
secondo una visita in preordine dei nodi.
database
schema
D ept.
Emp.
occurrence
tree
Proj.
DM
Funds
John
M ary
Ann
.... Stars
Roblab
DM
John
Stars
Introduzione ai DBMS
M ary
FlyCo.
Ann
....
Games
Toyfun
....
linear
stor age
Roblab FlyCo. Games Toyfun
pag. 26
Organizzazioni
fisiche
in
IMS
HSAM (Hierarchical Seq. Access Method):
allocazione sequenziale, valida per
archivi storici.
HISAM (Hierarchical ISAM):
gestione via ISAM (o
VSAM),
con
accesso indiciato alle root
degli
alberi.
Un albero e' memorizzato
in
una
pagina
ad
esso
dedicata
e,
se
necessario, nell'area di overflow.
HIDAM (Hierarchical Indexed Direct AM):
simile all'HISAM, ma senza gestione
esclusiva delle pagine, e con uso di
puntatori
per
il
mantenimento
dell'ordinamento lineare dell'albero.
HDAM (Hierarchical Direct AM):
i record root sono gestiti via hash;
gli overflow sono in area primaria a
catene non coalescenti.
Introduzione ai DBMS
pag. 27
DML
GET
UNIQUE
<conditions>
<record
per reperire root
di condizioni
type>
record
WHERE
sulla
base
GET UNIQUE Dipartimenti WHERE Codice = "DM"
GET NEXT <record type> WHERE <conditions>
per il successivo record di un tipo
GET NEXT WITHIN PARENT <record type>
per reperire il (successivo)
del padre corrente
figlio
GET NEXT WITHIN PARENT Impiegati
Esempio:
elenco dei progetti del dipartimento "DM"
GET UNIQUE Dipartimento WHERE Codice = "DM"
while DB_STATUS = 0
do
begin
GET NEXT WITHIN PARENT Progetti
write Progetti.Nome
end;
Introduzione ai DBMS
pag. 28
Nel caso di associazioni M:N si ha una
formulazione
dell'interrogazione
che,
dipendendo
fortemente
dalla
struttura
dell'albero,
facilita
alcune
interrogazioni a scapito di altre.
Esempio:
stampa di tutti i Fornitori
fornito la parte "P1"
che
hanno
GET UNIQUE Parti WHERE P# = "P1"
while DB_STATUS = 0
do
begin
GET NEXT WITHIN PARENT Fornitori
write Fornitori.S#
end;
stampa di tutti
Fornitore "S1"
le
Parti
fornite
GET FIRST Parti
while DB_STATUS = 0
do
begin
Found = FALSE
while (DB_STATUS = 0) and not(Found)
do
begin
GET NEXT WITHIN PARENT Fornitori
if DB_STATUS = 0
then if Fornitori.S# = "S1"
then begin
Found = TRUE
write Parti.P#
end
end
GET NEXT Parti
end;
Modello
Introduzione ai DBMS
Relazionale
pag. 29
dal
A differenza dei modelli reticolare e
gerarchico, il modello relazionale ha
avuto origine nei laboratori di ricerca
e,
solo
successivamente,
e’
stato
supportato da sistemi commerciali.
La definizione formale degli elementi del
modello ha permesso lo sviluppo di una
teoria
in
grado
di
supportare
efficacemente il progetto logico di un
DB.
1970:
“A Relational Model of Data
Shared Data Banks”, di E.F.
Res. Lab., San Jose’, CA)
1974:
prima
versione
(allora SEQUEL)
del
for Large
Codd (IBM
linguaggio
SQL
1975-79: sviluppo del prototipo System R presso i
laboratori IBM di San Jose’
1981:
SQL/DS, versione commerciale di SystemR
1983:
IBM Database2 (DB2)
Altri sistemi:
SQL/SERVER
ORACLE
INFORMIX
Introduzione ai DBMS
Microsoft
Oracle
Informix
pag. 30
La rappresentazione dei dati nel modello
relazionale e’ in forma di relazioni.
Piu’ formalmente:
Definizioni:
Un dominio e’ una collezione di valori.
Il prodotto cartesiano dei domini D1,
D2,...,Dn (non necessariamente distinti)
e’ l’insieme di tutte le possibili n-ple
(o tuple) ordinate t = (d1,d2,,...,dn),
tali che
d1__D1,
d2__D2, ...,
dn__Dn.
Una relazione definita sui domini D1,
D2,...,Dn e’ un sottoinsieme del prodotto
cartesiano D1 x D2 x ... x Dn
Il valore di n e' detto
"arita'") della relazione.
grado
(o
Esempi:
D1 = { mela, pera };
D2 = { (10,12), (11,23), (4,20) }
Una possibile relazione (binaria) su D1 e
D2 e’ data dalle tuple
R={ (mela, (11,23)),
(mela, (10,17)) }
(pera,
(10,12)),
Una relazione ternaria contenuta in D1 x
D2 x D1 e':
R' = { (mela,(11,23),pera),
(pera,(11,23),mela) }
Introduzione ai DBMS
pag. 31
La rappresentazione piu' intuitiva di una
relazione e' di tipo tabellare
mela
(11,23)
mela
(10,17)
pera
(10,12)
ma
e'
anche
possibile
rappresentazione
"spaziale"
dimensioni
a
una
n
(11,23)
(10,12)
(10,17)
mela
1
0
1
pera
0
1
0
o anche una
insiemistico
rappresentazione
di
(10,12)
mela
(11,23)
pera
(10,17)
Introduzione ai DBMS
pag. 32
tipo
Attributi e Domini
La definizione data di relazione e'
ispirata
direttamente
al
concetto
matematico di relazione tra insiemi.
In quanto tale:
1) e' un insieme, e quindi non possono
esistere
relazioni
con
tuple
duplicate (anche se nei DBMS cio' e'
normalmente tollerato!)
2) risulta dipendente
dall'ordine
dei
domini
o,
considerando
la
rappresentazione
tabellare,
delle
colonne.
Es: La relazione
R''={ ((11,23),mela), ( (10,12),pera), ((10,17),mela) }
e' distinta da R vista in precedenza.
Un
dominio
specifica
unicamente
un
insieme di valori possibili, ma non dice
nulla sull'uso che di tali valori viene
fatto.
Questo
e'
particolarmente
importante
nel
caso
di
domini
non
distinti. Per poter trattare agevolmente
relazioni con domini ripetuti, fornire
un'intuizione sul significato dei valori
del
dominio,
e
rendere
irrilevante
l'ordine delle colonne, si introduce il
concetto di attributo
Un attributo e' una colonna
relazione designata da un nome.
Introduzione ai DBMS
pag. 33
di
una
Data la tupla t = (d1,...,di,...,dn), di
e' detta l'i-ma componente di t.
Si supponga che l'i-ma colonna della
relazione sia designata con il nome Ai.
Allora ci si puo' riferire all'i-ma
componente di t con la notazione t.Ai o
t[Ai].
Frutto
X_Y
mela
(11,23)
mela
(10,17)
pera
(10,12)
Gli attributi della relazione sono Frutto
definiti rispettivamente sui domini D1 e D2.
e
X_Y,
Se t = (mela, (11,23)), allora t.X_Y = t[X_Y] = (11,23).
Facendo uso degli attributi l'ordine
delle colonne diventa irrilevante, a
condizione che ogni attributo di una
relazione abbia un nome distinto.
Seconda definizione di relazione:
Una relazione di grado n e' un insieme di
tuple t, dove t e' una funzione t:Ai _ Di
(i = 1,2,..,n) che assegna ad ogni (nome
di) attributo Ai un valore del dominio
Di.
Esempio: La tupla (mela, (11,23))
mapping t(Frutto)
= mela
t(X_Y)
= (11,23)
Introduzione ai DBMS
pag. 34
e' definita dai due
Linguaggi di interrogazione procedurali e
non
L'uso di un linguaggio di programmazione
procedurale convenzionale (Cobol, Basic,
Pascal, C, etc.), che si appoggia ad un
file system, comporta una conoscenza di
dettaglio circa l'architettura dei file e
la stesura di codice che "naviga" le
strutture dati in modo esplicito.
Pur utilizzando librerie di software è
responsabilità del programmatore "cucire"
i
vari
"pezzi"
in
modo
opportuno.
Un esempio dal Database ToolBox del TurboPascal:
procedure ListaClienti(var Clienti:DataSet);
var Contatore:longint; CodiceCliente:codice;
begin
Contatore:=0; TAReset(Clienti);
repeat
TANext(Clienti,RecordCliente,CodiceCliente);
if Ok then
begin
Display(RecordCliente);
Contatore:=succ(Contatore)
end
until not Ok;
if Contatore >0
then
begin
writeln;
writeln(Contatore,' clienti')
end
end;
Un DBMS rende l'accesso ai file più semplice attraverso
l'uso di un query language : il livello di dettaglio
richiesto all'utente dipende dal tipo di modello dati
adottato.
Introduzione ai DBMS
pag. 35
Esempio di query : trova il Direttore di ROSSI
Modello Reticolare
Il modello dei dati prevede strutture multilista che
mettono
in
connessione
gli
impiegati
ai
propri
dipartimenti e i dipartimenti ai direttori.
IMPIEGATI.Nome := 'ROSSI'
find IMPIEGATI record by CALC_KEY
find owner of current IMP-DIP set
find first Direttore record in current DIP-DIR set
print Direttore.Nome
Modello Relazionale
IMPIEGATI(Nome,CodImp,CodDip,....)
DIPARTIMENTI(CodDip,Direttore,......)
in SQL :
select Direttore
from IMPIEGATI,DIPARTIMENTI
where IMPIEGATI.Nome = 'ROSSI'
and IMPIEGATI.CodDip = DIPARTIMENTI.CodDip
Introduzione ai DBMS
pag. 36
Gestione delle transazioni
Un DBMS provvede alla gestione della concorrenza delle
transazioni sulla base di dati. Si deve garantire
infatti che gli accessi ai dati, da parte di diverse
applicazioni, non interferiscano; al fine di conservare
l'integrità dei dati è necessario far ricorso ad
opportuni meccanismi di controllo della concorrenza.
Esempio :
transazione di prelievo di una quantità Q
dal
conto
corrente
con
codice
XXX
memorizzato in un archivio C_Correnti.
Se il nucleo della transazione fosse del tipo :
leggi da C_Correnti il record CC con codice XXX;
if CC.disponibile >= Q
then begin
CC.disponibile := CC.disponibile - Q;
eroga la somma Q;
aggiorna il record CC su C_Correnti
end
else messaggio('operazione non possibile');
potrebbe accadere che due transazioni T1 e T2 che
vogliono prelevare, rispettivamente 80 e 50,
dallo
stesso conto corrente con disponibilità 100, vengano a
sovrapporsi come segue, provocando un prelievo non
corretto:
CC.disponibil 100
e
in
C_Correnti
T1
leggi
T2
spazio
di lavoro T1
100
100
spazio
di lavoro T2
Introduzione ai DBMS
50
-80
leggi
100
100
20
aggiorn
a
-50
aggiorn
a
100
20
20
20
100
100
50
50
pag. 37
20
T1 e T2 devono accedere in modo esclusivo al record: il
DBMS deve rendere disponibili primitive per lock ed
unlock a diversi livelli di granularità:
la transazione si modifica come segue:
leggi con lock da C_Correnti il record CC con codice
XXX;
if CC.disponibile >= Q
then begin
CC.disponibile := CC.disponibile - Q;
eroga la somma Q;
aggiorna il record CC su C_Correnti
end
else messaggio('operazione non possibile');
unlock il record CC;
dove leggi con lock realizza un ciclo di attesa che
termina se la risorsa record CC è disponibile per un
accesso esclusivo.
Naturalmente con un DBMS evoluto non è responsabilità
del programmatore la gestione della concorrenza, (tale
responsabilità è invece piena nel caso di uso diretto
del file sytem da linguaggio di programmazione).
Il query language svincola l'utente dall'esplicitare i
meccanismi di locking, ad esempio in SQL interattivo T1
sarebbe:
update C_Correnti
set disponibile = disponibile - 80
where codice = 'XXX' and disponibile >= 80
Un altro problema che si può presentare, e che il DBMS
deve essere in grado di gestire, è il deadlock
(stallo). Ad esempio : T1 e T2 che necessitano dell'uso
esclusivo di due risorse R1 ed R2, richiedendole come
segue:
T1 : lock R1;
Introduzione ai DBMS
T2 : lock R2;
pag. 38
usa R1;
lock R2;
usa R1 e R2;
unlock R1;
unlock R2;
usa R2;
lock R1;
usa R1 e R2;
unlock R1
unlock R2;
La concorrenza di T1 e T2 può comportare un'attesa
infinita da parte di entrambe le transazioni. Il nucleo
di gestione della concorrenza deve rilevare condizioni
di deadlock e procedere ad un ripristino consistente del
database. In caso di database distribuito su più
computer il controllo e la gestione della concorrenza
implicano il ricorso a tecniche molto sofisticate.
Linguaggi di IV generazione
Un ambiente di sviluppo di database deve consentire una
elevata produttività e affidabilità del software,
facilitare la prototipizzazione rapida, rendere semplice
gli interventi di manutenzione e permettere il riuso per
altre applicazioni.
Le
possibilità
offere
devono
comprendere:
*
*
*
*
*
Simple Query Language
Complex Query Language
Report Generator
Graphics Generator
Application Generator
Un
linguaggio
di
IV
generazione
deve
offrire
caratteristiche di sistema di supporto alle decisioni e
di modellizzazione concettuale. Deve inoltre consentire
inter-operabilità fra database che si appoggiano a vari
tipi di DBMS.
Introduzione ai DBMS
pag. 39
Sicurezza dei dati
Oltre ad offrire protezione dei dati in caso di guasto,
un DBMS deve garantire la base di dati da accessi non
autorizzati. A tale scopo deve essere consentita la
definizione di password e di particolari privilegi
differenziati per classi di utenti. Ad esempio in SQL è
possibile restringere, per certi utenti, la visibilità
degli attributi di una relazione; infatti data la
relazione:
PERSONE(Cognome,Nome,CodFisc,Reddito,Indirizzo)
si può definire una vista:
create view ANAG as
select Cognome,Nome,CodFisc
from PERSONE
La vista così definita è equivalente ad una relazione
con solo gli attributi Cognome,Nome,CodFisc.
ANAG(Cognome,Nome,CodFisc)
e non corrisponde ad un vero file fisico, pur essendo
interrogabile come se lo fosse:
select Cognome,Nome
from ANAG where CodFisc='TRLFLV51M27F839X'
E' possibile dunque definire alcune classi di utenti,
assegnando vari privilegi per ciò che concerne l'accesso
all'archivio PERSONE, ad esempio:
a)
b)
c)
utenti con accesso in lettura e modifica alla
relazione PERSONE
utenti con accesso in lettura alla relazione PERSONE
utenti con accesso in lettura alla vista ANAG
Alcuni sistemi consentono anche la materializzazione
delle viste. Il problema dell'aggiornamento delle viste
in virtù di modifiche apportate allo schema del database
Introduzione ai DBMS
pag. 40
è normalmente compito del progettista ma in alcuni
sistemi può essere parzialmente facilitato da strumenti
automatici.
In fig. 1.5 un esempio di schema E/R che descrive le
inter-relazioni che intercorrono fra le entità STUDENTE,
CORSO, PROFESSORE e DIPARTIMENTO.
Uno studente, contraddistinto dagli attributi Cognome,
Nome, Data di nascita, Matricola, può aver sostenuto
esami in una certa Data esame riportando un certo Voto
con riferimento ad un certo corso. Interessa memorizzare
informazioni di uno studente anche se non ha sostenuto
esami. Per ogni corso si dispone delle informazioni
CodCorso
e
NomeCorso;
un
corso
può
esistere
indipendentemente dal fatto che vi siano o meno studenti
che abbiano già sostenuto esami. Per un corso dunque vi
possono essere dunque zero, uno o più studenti che hanno
sostenuto il relativo esame. Il legame associativo tra
le entità studente e corso è dunque di tipo molti a
molti non obbligatoria, ovvero 1 ad N parziale in
entrambe le direzioni, ed è espresso in fig. 1.5 dalla
relationship (associazione)ESAME .
In fig. 1.5 si mostra anche un'altra associazione
TITOLARITA' tra l'entità CORSO e l'entità PROFESSORE. Un
professore è obbligatoriamente titolare di un corso ma
può essere titolare anche di più corsi. Un corso invece
può essere istituito, ma non attivato e quindi può non
ancora avere un titolare. L'associazione è dunque totale
di tipo 1 ad N nella direzione professore-corso e di
tipo 1 ad 1 parziale nella direzione corso-professore.
Analoghe considerazioni valgono per
l'associazione
AFFERENZA che mette in relazione le entità DIPARTIMENTO
e PROFESSORE.
La semantica della notazione grafica usata per esprimere
quanto detto a parole sarà precisamente introdotta nel
capitolo dedicato alla modellizzazione concettuale E/R.
Introduzione ai DBMS
pag. 41
Cognome, Nome
Data di nascita
Matricola
STUDENTE
Voto
Data esame
CodCorso
NomeCorso
CORSO
ESAME
TITOLARITA'
DIPARTIMENTO
AFFERENZA
PROFESSORE
CodProf
CodDip
Cognome,Nome
Indirizzo
Denominazione
Figura 1.5
Lo schema E/R può essere mappato nel modello relazionale
come segue:
STUDENTE(Matricola,Cognome,Nome,DataNascita)
ESAME(Matricola,CodCorso,Voto,DataEsame)
CORSO(CodCorso,NomeCorso,CodProf)
PROFESSORE(CodProf,Cognome,Nome,CodDip)
DIPARTIMENTO(CodDip,Denominazione,Indirizzo)
Anche se per l'esempio qui riportato può sembrare
piuttosto intuitivo la realizzazione proposta nel
modello relazionale, la fase di progetto logico, in
generale,
è
piuttosto
complessa
e
necessita
di
metodologie e strumenti appropriati.
Introduzione ai DBMS
pag. 42
Il Livello vista (esterno)
Indipendenza dei dati
Due sono i livelli di indipendenza che si possono
realizzare in un database ben progettato. Il primo tipo
di indipendenza, detto indipendenza fisica, consente
di apportare modifiche all'organizzazione fisica dei
dati senza alterare i programmi di interrogazione che
sono stati scritti nel rispetto del modello dei dati
concettuale
messo
a
disposizione
dal
DBMS.
La
possibilità di costruire viste consente inoltre di
realizzare un'indipendenza logica. Infatti a volte
può essere necessario apportare modifiche allo schema
concettuale
(logico)
ed
è
probabile
che
alcuni
sottoschemi non debbano essere modificati, ovvero non è
necessario modificare tutti i programmi applicativi.
Solo quelli che visitano la porzione di dati interessata
ai
cambiamenti
effettuati
andranno
rivisti
ed
eventualmente modificati.
Introduzione ai DBMS
pag. 43
1.4 Linguaggi dei database
In un linguaggio di programmazione convenzionale le
frasi di dichiarazioni dei dati e
gli statement di
computazione vengono espressi in una sintassi unica,
quella del linguaggio. In un database, invece, si
distinguono:
.
.
.
un linguaggio di definizione dei dati (DDL)
un linguaggio di manipolazione dei dati (DML)
un linguaggio per il controllo dei dati (DCL)
D'altra parte, in un database, i dati
indipendentemente dai programmi applicativi.
esistono
Linguaggio di definizione dei dati
Il DDL non è un linguaggio procedurale ma piuttosto una
notazione per creare e manuntenere la struttura di una
base di dati; a seconda del modello concettuale adottato
il DDL consente di descrivere i tipi di entità in gioco
e le relazioni tra le entità.
Ad esempio in SQL:
create table Studenti
(
Matricola char(5)
not null,
Cognome
char(20) not null,
Nome char(20)
not null,
Voto
integer
);
specifica gli attributi dell'entità Studente
create
unique index MatrStud
on Studenti(Matricola);
provoca la creazione di un indice sul campo Matricola
Linguaggio di manipolazione dati
Il DML consente di esprimere operazioni sulle strutture
dati definite.
Introduzione ai DBMS
pag. 44
Ad esempio:
insert into Studenti
values ('20111','Bianchi','Mario',23);
select Cognome,Nome
from Studenti
where Voto >= 18
order by Cognome;
Linguaggio di controllo dei dati
Il DCL consente di effettuare operazioni di controllo
quali ad esempio:
commit per
terminare
una
transazione
e
rendere
permanenti le modifiche effettuate alla base di dati;
rollback
per ripristinare la base di dati ad uno
stato consistente annullando gli effetti prodotti da
modifiche fatte dopo l'ultimo commit
grant
per
informazioni
assegnare
privilegi
revoke per rimuovere privilegi
safepoint per creare un checkpoint
Introduzione ai DBMS
pag. 45
di
accesso
alle
Linguaggi ospite
Oltre alle istruzioni che consentono la manipolazione
della base di dati è necessario, per realizzare
applicazioni, disporre di linguaggi general purpose. A
tale scopo sono percorribili tre alternative:
a) il DBMS dispone di un linguaggio proprio, ad esempio
in dBASE IV:
* un esempio di istruzioni procedurali
use Ordini
do while .not. eof()
clear
list next 5 N_Ordine,Descr_Parte,Costo
?
wait "Premi X:fine,B:indietro,spazio:continua" to
Mstop
do case
case Mstop $ "Xx" .or. eof()
exit
case Mstop $ "Bb"
skip -9
otherwise
skip
endcase
enddo
b) I comandi per la manipolazione dei dati vengono
invocati all'interno di un linguaggio convenzionale (C,
Cobol, Pl/I,...), ad esempio in ORACLE da linguaggio C è
possibile invocare le procedure del gestore :
/* si dichiarano due array */
int A[10]; char S[10][50];
/* si invocano istruzioni SQL */
osql3(cursor,"insert into T values(:var1,:var2)",-1)
obndrv(cursor,":var1",-1,A[0],4,3,...);
obndrv(cursor,":var2",-1,S[0],50,1,...);
c) Si dispone di un linguaggio esteso e di un relativo
precompilatore, ad esempio PRO*C in ambiente ORACLE:
Introduzione ai DBMS
pag. 46
/* frammento di programma in PRO*C */
#include <stdio.h>
EXEC SQL BEGIN DECLARE SECTION;
varchar uid[20];
varchar pwd[20];
/* altre dichiarazioni */
EXEC SQL END DECLARE SECTION;
EXEC SQL INCLUDE SQLCA;
main()
{
/* login ad ORACLE */
strcpy(uid.arr,"ROSSI");/* copia lo username */
uid.len=strlen(uid.arr);
strcpy(pwd.arr,"NEMO");/* copia la password */
pwd.len=strlen(pwd.arr);
EXEC SQL WHENEVER SQLERROR STOP;
EXEC SQL CONNECT :uid IDENTIFIED BY :pwd;
printf("Connessione utente:%s \n",uid.arr);
/* altre istruzioni */
}
Introduzione ai DBMS
pag. 47
La fig. 1.6 illustra i componenti principali di un DBMS
ed evidenzia le diverse modalità di interazione,
corrispondenti a differenti responsabilità e ruoli.
Componenti principali di un DBMS
Interrogazione
estemporanea
Programma
applicativo
Schema DB
Processore di
istruzioni DML e DCL
Compilatore
DDL
Tavole di
autorizzazione
Gestore DB
Tavole per
il controllo
degli accessi
concorrenti
Tavole di
descrizione
DB
Gestore file
DB
Figura 1.6
Introduzione ai DBMS
pag. 48
1.5 Verso nuove applicazioni database
Applicazioni VLSI, CAD, Software Engineering, GIS, DDS,
etc.
necessitano di strumenti concettuali sofisticati
per modellare la realtà di pertinenza
e di potenti
meccanismi per le operazioni sulle informazioni.
Per queste applicazioni la separazione tra DML e
linguaggio ospite crea notevoli difficoltà; si pensi ad
esempio alla memorizzazione di immagini costruite
tramite un assemblaggio di immagini componenti ; in tal
caso è necessario disporre di costrutti che consentano
ricorsione (si noti ad esempio che in un DBMS
relazionale non è possibile esprimere interrogazioni
ricorsive). Si pensi, con riferimento alla fig. 1.7, ad
uno zoom che comporta un'interrogazione ricorsiva sulla
base di dati, se la figura è memorizzata come insieme di
riferimenti a componenti.
posacenere
telefono 1
fotocopiatrice
telefono 2
cestino
Figura 1.7
Introduzione ai DBMS
pag. 49
Integrazione tra DML e linguaggio ospite
Il problema di combinare capacità di rapido accesso alle
informazioni, tipiche di un DML, e caratteristiche
general purpose di un linguaggio ospite, viene oggi
affrontato secondo due approcci :
* paradigma orientato agli oggetti
uso di un linguaggio che consenta di definire tipi di
dati astratti, che abbia capacità espressive, che possa
rappresentare il comportamento degli oggetti, che
faciliti l'uso di tecniche di ingegneria del software.
Ad esempio in IRIS definita la classe Persona e la
funzione Genitore è possibile definire la funzione Nonno
come segue:
Create function Nonno(Persona p) -> Persona as
select n for each Persona n
where n=Genitore(Genitore(p));
Si noti come questa funzione può essere espressa in SQL,
come segue :
select X.nome,Y.nome
from Persona X, Persona Y
where X.genitore = Y.nome
immaginando di avere una relazione
Persona(nome,genitore)
e definendo un join fra X e Y sinonimi della stessa
relazione Persona.
Si noti che nel modello ad oggetti definito, la funzione
corrisponde ad un metodo, ed il risultato è ancora una
sottoclasse della classe Persona.
Un altro esempio : "Trova tutti i superiori di Rossi",
potrebbe essere espresso nel modello di ORION come :
(select Impiegato
Introduzione ai DBMS
pag. 50
(recurse Superiore)
(Nome = "Rossi"))
dove Impiegato è una classe con attributo Nome e un
attributo Superiore. Il dominio dell'attributo Nome è la
classe Stringhe e il dominio dell'attributo Superiore è
ancora la classe Impiegato. L'espressione (recurse
Superiore) dice che, una volta trovata un'istanza della
classe Impiegato che soddisfa al predicato (Nome
="Rossi"), devono essere trovati ricorsivamente i valori
dell'attributo Superiore.
Questa
interrogazione
non
nell'algebra relazionale.
Introduzione ai DBMS
può
pag. 51
essere
espressa
* paradigma logico
usa un linguaggio che applica regole logiche del tipo
if ...... then ......
Alcuni predicati sono considerati parte dello schema
concettuale, altri consentono di definire viste, altri
ancora possono essere usati per costruire programmi
applicativi. Al contrario del paradigma ad oggetti, il
paradigma logico offre un linguaggio essenzialmente
dichiarativo.
Ad esempio:
manager(Imp,Dir)
impiegato(Imp,Dip)&dirige(Dip,Dir)
:-
che asserisce : Dir è manager di Imp se sono verificati
due fatti contemporaneamente, ovvero Imp è impiegato nel
dipartimento Dip e Dir dirige il dipartimento Dip. E'
immediato mostrare che è necessario un join in SQL.
Un altro esempio di potenza espressiva della logica :
Superiore(Imp,Sup):-Responsabile(Imp,Sup)
Superiore(Imp,Sup):Responsabile(Imp,X)&Superiore(X,Sup)
ovvero un Superiore di un impiegato Imp o è il suo
responsabile diretto o è Superiore di qualcuno che è
responsabile diretto di Imp. E ciò implica ricorsione,
pertanto non esprimibile in algebra relazionale.
Passato e futuro (secondo Ullman!?)
Decade
Sistemi
Introduzione ai DBMS
Orientato
pag. 52
a Dichiarativ
o?
DML/host
1960
Gerarchici
oggetti
No
Separ
Reticolari
1970
Relazionale
valore
Sì
Separ
1980
OO-DBMS
oggetti
No
Integ
1990
KBMS
valori
Sì
Integ
La predizione di Ullman è che i KBMS sostituiranno gli
OO-DBMS , rivestendo l'analogo ruolo svolto dai sistemi
relazionali nei confronti dei sistemi gerarchici e
reticolari.
La
ragione
addotta
è
principalmente
l'assenza di un linguaggio puramente dichiarativo e
l'orientamento non a valori, un passo indietro rispetto
ai
sistemi
relazionali.
Personalmente
questa
affermazione così categorica mi lascia sconcertato e mi
ricorda certe affermazioni di coloro che, difendendo a
spada tratta l'approccio relazionale, dimenticavano
lungo la strada le esigenze delle applicazioni. Insomma,
l'intuito e l'esperienza mi fanno sospettare che la meta
è ancora lontana e forse un approccio ibrido non è da
sottovalutare.
La differenza tra i tre livelli fisico,concettuale,vista
può essere meglio compresa facendo un'analogia con i
linguaggi di programmazione.
In TurboPascal le dichiarazioni:
const N = 100;
type nomi = string[30]; data = string[6];
qualifiche = (operaio,impiegato,dirigente);
persona=record
cognome,nome:nomi;
qualifica : qualifiche;
data_nascita : data
end;
var Elenco : array[1..N] of persona;
permettono di modellare a livello concettuale un elenco
di persone, senza preoccuparsi di conoscere il formato
interno di rappresentazione. A livello fisico, ovvero in
Introduzione ai DBMS
pag. 53
memoria principale, la dichiarazione porta come effetto
l'allocazione di una struttura di 100 blocchi di byte
consecutivi, ciascuno lungo 70 byte.
L'indirizzo fisico
calcolato come:
di
un
elemento
Elenco[i]
verrà
base + (i-1)*70
essendo base l'indirizzo in cui è stato allocato il
primo elemento dell'array Elenco.
Il programmatore fa semplicemente uso del nome simbolico
Elenco[i], ad esempio può scrivere
Elenco[i].qualifica:=impiegato
per assegnare la qualifica di impiegato alla persona iesima dell'elenco,ignorando i dettagli del livello
fisico.
Una vista sull'array Elenco potrebbe essere
dichiarando una funzione, ad esempio:
definita
function ContaImpiegati(m:integer):integer;
var Conta:integer; i:integer;
begin
Conta:=0;
for i:=1 to m
do if Elenco[i].qualifica = impiegato
then Conta:=succ(Conta);
ContaImpiegati := Conta
end;
per calcolare quante persone tra le prime m in Elenco
hanno la qualifica di impiegato.
Introduzione ai DBMS
pag. 54
In tal modo la chiamata della funzione realizza una
visione diversa dell'array, come procedimento di calcolo
di una quantità relativa solo ai primi m elementi di
Elenco che godono di una certa proprietà.
Alcuni sistemi consentono anche la materializzazione
delle viste. Il problema dell'aggiornamento delle viste
in virtù di modifiche apportate allo schema del database
è normalmente compito del progettista ma in alcuni
sistemi può essere parzialmente facilitato da strumenti
automatici.
Il livello esterno si riferisce al modo
in
cui
le
varie
classi
di
utente
percepiscono la base di dati: ad uno
stesso schema concettuale (o ad uno
stesso
schema
logico)
possono
corrispondere diverse viste esterne.
Introduzione ai DBMS
pag. 55
Ad esempio, con riferimento a database
relazionali, allo scopo di differenziare
questi due tipi di rappresentazione, se
per il progetto di un database si è fatto
uso di schemi basati sul modello EntityRelationship :E/R, si è soliti usare il
termine
schema
concettuale
per
quest'ultimi
ed
il
termine
logical
schema
per gli schemi basati sul
modello dei dati relazionale e derivati
dagli schemi E/R. In altre parole lo
schema logico coincide con lo schema
concettuale che sarà poi disponibile
effettivamente all'utente, in quanto i
meccanismi di interrogazione sono fondati
sul modello dei dati adottato dal DBMS e
non sul modello concettuale impiegato per
il progetto.
Introduzione ai DBMS
pag. 56
Modello ad oggetti
Idoneo per applicazioni a carattere multimediale: GIS,
CAD/CAM, CAE, CASE,CIM, OA, ES,DSS, ...
concetti di base:
oggetti, oggetti complessi , separazione tra interfaccia
e stato (incapsulazione), classi, ereditarietà
6th Avenue
7th Avenue
Road
name:String;
road type: {road, avenue, boulevard, lane, ...}
segment
list
:sequence
of
Road
segment|
Intersection
Road Segment
in road:Road;
shape of segment:Arc|Line
start: Intersection
end:Intersection
direction:{one-way-SE, one-way-ES,two-way}
address range:{Street Number,Street Number}
odd side:{left,right}
Intersection
incoming roads:Set of Road Segment
position:Coordinate
Introduzione ai DBMS
pag. 57