Sistemi di Gestione di Basi di dati File System vs DBMS · Introduzione ai DBMS pag. 9 Lo schema...

Introduzione ai DBMS pag. 1

Sistemi di Gestionedi Basi di dati

File System vs DBMS

_ Un file è una collezione di dati cherisiede su un dispositivo di memoriaesterna ed è strutturata in accordo airequisiti di un'applicazione.

Anagrafeclienti

Ordini

Fatture

InserimentoOrdini

Registrofatture

La ripetizione dell'indirizzo del cliente consente alle applicazioni Registro fatture e inserimento ordini di operare allo stesso tempo

Emissionefatture

IndirizzoCliente

IndirizzoCliente

IndirizzoCliente

_ Programmi individuali accedono, disolito, in modo esclusivo ai file. Perraggiungere un ragionevole grado diefficienza, si introduce ridondanza nelleinformazioni


_ La ridondanza riduce il numero dirisorse che devono essere 'locked',quando più applicazioni sono attive.

_ Ciò comporta tuttavia l'adozione ditecniche atte a garantire la consistenzadelle informazioni.

_ A causa delle limitate possibilità dicooperazione tra file, le applicazionicostruite su un file system si basanosui metodi di accesso messi adisposizione dal sistema operativo esulle organizzazioni di file disponibilinel linguaggio di programmazione.

_ Di solito sono disponibili leorganizzazioni:

_ sequential

_ relative

_ indexed-sequential


_ Un database è una collezione dioggetti che richiede un dispositivo dimemoria esterna ad accesso diretto. UnDBMS (Data Base Management System)ha capacità di gestire grandi moli didati in un ambiente multiutente.

_ Dal punto di vista fisico, ovvero delsistema operativo, anche un databaseconsiste di file. Tuttavia un DBMSconsente elaborazione concorrente,mantiene la consistenza delleinformazioni minimizzando la ridondanza,offre supporto per test eprototipazione , permette indipendenzadel software dalla organizzazione fisicae logica delle strutture dati.

Anagrafeclienti

Ordini

Fatture

InserimentoOrdini

Registrofatture

Una granularita' piu' fine consente l'uso condiviso dellarisorsa indirizzo cliente

DBMS

Emissionefatture

Indirizzocliente


_ Un DBMS è costruito sopra il sistemaoperativo ed amplia la gamma dellestrutture di accesso messe a disposizionedal file system. In sintesi, in una basedi dati la gestione delle informazioni èlogicamente centralizzata in unarappresentazione integrata e nonridondante.

_ Dal punto di vista utente un databasee' visto come una collezione di dati chemodellano una certa porzione dellarealta' di interesse.

_ L'astrazione logica con cui i dativengono resi disponibili all'utentedefinisce un modello dei dati

Es:

* Un file è una sequenza di record:

type persona = recordcognome, nome: string[20];ntel: string[16];..........

end ;

Il concetto di file è legato ad una profonda conoscenza,da parte dell'utente, dei meccanismi di memorizzazionefisica e delle modalità di accesso.

* Una relazione è un'astrazione di file: un insieme diennuple ( tuple ) in cui non viene specificato l'ordine

PERSONE(Cognome, Nome, Ntel, ......)

Il concetto di relazione svincola ulteriormente l'utentedai dettagli della rappresentazione interna.


Peculiarità dei DBMS

_ gestione efficiente di grandi moli didati persistenti

_ supporto per almeno un modello deidati

_ linguaggi di alto livello per

_ definizione dati (DDL = Data Definition L.)_ manipolazione dei dati (DML=Data ManipulationL.)_ controllo dei dati (DCL=Data Control L.)

_ gestione delle transazioni

_ controllo degli accessi

_ resilienza

= capacita' di garantire l'integrita' dei dati inseguito 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


Livelli di astrazione neiDBMS

La "classica" architettura a tre livelli

vista 1

vista 2

vista n

Databasefisico

database concettuale

DDL per sottoschemi

DDL per schema integrato

realizzato sudispositivi fisici

La presenza del livello concettuale risponde allanecessita' di fornire caratteristiche di indipendenzafisica che possano consentire la riorganizzazione deidati su disco senza comportare effetti collaterali suiprogrammi applicativi che li usano. Allo stesso tempo illivello concettuale fornisce una visione integratadei dati.

La presenza del livello esterno (o delle viste ) vanella direzione di assicurare l' indipendenza logicadei dati: l'utente ha la possibilita' di "vedere" i dati(o solo parte di essi) scegliendo l'astrazione piu'conveniente.


Livello fisico (interno)

Il physical database e' una collezionedi archivi e relative strutture diaccesso che risiede permanentemente sumemorie di massa.

Il livello interno riguarda il modo incui le informazioni sono organizzate egestite sui dispositivi fisici.

La descrizione di una base di dati aquesto livello viene chiamata physicalschema (schema interno).

Il progetto fisico di un databaseriguarda problemi legati principalmentea:

_ criteri di allocazione dei datipartizionamento, ordinamento,

_ scelta dei metodi di accesso


Livello concettuale

Il conceptual database e' un'astrazionedel mondo reale come percepito(globalmente) dagli utenti.

Un DBMS mette a disposizione unlinguaggio DDL (Data DefinitionLanguage) per la descrizione delconceptual schema e per la sua(parziale) realizzazione in uncorrispondente schema fisico.

Il DDL consente di definire lo schemaconcettuale in termini di data model(modello dei dati). Si parla dunque dimodello relazionale , reticolare ,gerarchico , logico, a oggetti , aseconda del tipo di DBMS. Ad esempio,facendo uso del modello relazionale e dellinguaggio SQL (Structured QueryLanguage):

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 char(5) not null,CodCorso char(5) not null,Denominazione char(30) not null,Voto integer not null,Data char(6) not null);


Lo schema concettuale rende trasparentel'implementazione fisica dei dati

Per le relazioni STUDENTI ed ESAMI e' possibile averedue file distinti, oppure un unico file le cui paginecontengono un record di STUDENTI e N record di ESAMI (e'la soluzione adottata, ad es., dai DBMS ORACLE e SUPRA).

12045 Giuliani Marco 27/02/71 051-24451

Matricola Cognome Nome D atanas cita Tel.

12045 1027 Analisi I 25 4/6/91

Matricola CodCorso Denominazione

12045 1045 Fisica I 30 10/7/91

12045 112 TAMC 28 12/10/91

12045 1190 Al gebra 30 18/2/92

12045 1132 Geometria 27 21/5/92

Uno schema concettuale viene costruito inmodo da integrare le diverse esigenze ditrattamento delle informazioni degliutenti di uno stesso database.

Il processo che porta alla definizione,in sede di progetto, di una strutturaunificante viene detto database viewintegration ed implica l'unificazione dischemi concettuali parziali .


Limitazioni dei DDL

Spesso il formalismo impiegato per ilprogetto di un database è più riccosemanticamente del DDL del DBMS. E'necessario allora un ulteriore passo d iprogetto che traduca dallo schemaconcettuale impiegato per descrivere ilmondo reale allo schema concettuale (orachiamato piu' propriamente schemalogico ) disponibile nell'ambiente delDBMS. Si distingue pertanto tra progettoconcettuale e progetto logico .

Impiegato =persona caratterizzata da: codice (Cod)

nome (Nome)diretto superiore(Cod_dir)

Lo schema concettuale deve modellare l'entita' Impiegatoe 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 ereticolare non dispongono degli strumentinecessari per esprimere uno schema diquesto tipo. Occorre complementare il DDLa disposizione con strutture di altrotipo (ad es. funzioni C, regole Prolog,ecc)


Livello est erno

Una view (vista) o sottoschema è unaporzione di uno schema concettuale.

La costruzione di viste è il processoinverso dell'integrazione di schemiconcettuali parziali.

Molti DBMS forniscono una sintassi per ladefinizione di sottoschemi e per lamanipolazione delle viste generate.

Data la relazione:

PERSONE(Nome,CodFisc,Reddito,Indirizzo,Data_nascita)

si può definire una vista in SQL mediante :

create view PERSONE_RICCHEas select CodFisc,Nome

from PERSONEwhere Reddito > 100,000,000

La vista PERSONE_RICCHE non corrisponde ad un vero filefisico, pur essendo interrogabile come se lo fosse:

select Nomefrom PERSONE_RICCHEwhere CodFisc='TRLFLV51M27F839X'


Le viste consentono di:

a) raggiungere un livello di astrazionemaggiore rispetto al modelloconcettuale integrato del database.

Un ufficio vendite vuole disporre di una vista suipropri clienti che contenga l'attributo età .. Tuttavia,poichè l'età cambia di giorno in giorno, nel modelloconcettuale integrato sarà previsto di memorizzare ladata di nascit a per ogni cliente. Ciò implica chel'interrogazione di una vista può comportare un calcoloper rendere disponibile all'utente un dato checoncettualmente, nella sua visione esterna, fa parte delproprio sottoschema.

b) consentire un certo livello diindipendenza logica a fronte diristrutturazioni dello schemaconcettuale

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 definendola 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_Civicofrom S_Z,S_LLwhere S_LL.Nome = S_Z.Nome

che sfrutta la corrispondenza biunivoca tra le tuple diS_Z e S_LL


c) definire diverse classi di utenti,assegnando ad ognuna diversiprivilegi. Le viste costituiscono unsemplice meccanismo di sicurezza deidati realizzato attraversol'occultamento di informazione.

Facendo uso della vista PERSONE_RICCHE, il DBMS puo'distinguere, ad esempio, tra:

a) utenti con accesso in lettura e scrittura allarelazione PERSONE

b) utenti con accesso in sola lettura alla relazionePERSONE

c) utenti con accesso in sola lettura alla vistaPERSONE_RICCHE

Per distinguere i casi a) e b) occorronoaltri strumenti (autorizzazioni)

N.B . La classe

d) utenti con accesso in lettura e scrittura alla vistaPERSONE_RICCHE

non puo' esistere! Ad es.

insert into PERSONE_RICCHE(CodFisc,Nome)values ('TRLFLV51M27F839X','Flavia')

darebbe luogo ad un inserimento reale inPERSONE della tupla

('TRLFLV51M27F839X','Flavia',?,?,?)

che non soddisfa Reddito > 100,000,000


Modelli dei dati

Un modello dei dati e' una collezione diconcetti che possono venire usati perdescrivere un insieme di dati, le loroassociazioni, e le operazioni cheagiscono sui dati stessi.

Una distinzione importante suddivide imodelli dei dati in:

Modelli concettuali:

utilizzati per descrivere la porzionedi mondo che viene rappresentata nelDatabase, facendo uso di meccanismidi astrazione;

importanti per la fase diprogettazione concettuale di un DB.

Modelli logici:

forniscono una descrizione dei datiche e' direttamente supportata dalDBMS;rappresentano un target per la fasedi progettazione logica;permettono un mapping semplice con lestrutture del DB fisico;sono il punto di riferimento per chisviluppa applicazioni su DBMS.


Modello Entity-Relationship (E/R)[Chen 1970]

StudentiCorsi

Docenti

tenuti _da

in_gruppo_con

frequentan o

Lo schema modella una realta'descrivibile a parole come segue:

I Corsi sono tenuti da DocentiGli Studenti frequentano i CorsiGli Studenti sono in gruppo con altri Studenti

Lo schema non puo' fornire informazionisu quali gruppi sono presenti nei varicorsi (l'associazione in_gruppo_con nonriguarda 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 riferimento


For ni tor iPar ti

P_F (fornitu re)

Parte: caratterizzata da Codice (P#){unico}

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 omeno) facendo uso del formalismo del modello E/R


Modello Reticolare

Il modello reticolare scaturisce dalreport del 1971 del CODASYL DBTG (DataBase Task Group) mirante a fornire unostandard nel settore.Sistemi commerciali:

IDS II Honeywell

DBMS-11 Digital

VAX-DBMS "

IDMS Computer Associates

DMS 1100 Univac

IMAGE Hewlett-Packard

Il modello si basa sui due concetti basedi record type e set type .

record type: descrive la struttura di ungruppo di record che memorizzano lostesso tipo di informazioni

set type: descrive una associazioneesistente tra due record types (A eB) 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) .


Es:rappresentazione dei record typeDipartimenti e Impiegati e delrelativo set type

D1 DEIS 150 Bologna

Owner

Members

I 1 Mario I 4 Anna I 20 L uca

Per rappresentare la relazione tra Partie Fornitori (di tipo molti a molti, M:N),si rende necessario:

1) introdurre il record type Forniture(detto link type );

2) definire due set types con owner,rispettivamente una Parte ed unFornitore;

3) rendere le Forniture member dientrambi i set types.


S1 Smith 20 London S2 Jones 10 Paris

300 200 400 300 400

P1 Nut Red 12 London

P2 Bolt Green 17 Par is

P3 Screw Blue 17 Rome


Supporto fisico

Gli elementi di un record type possonoessere memorizzati secondo tre modalita'distinte:

DIRECT: allocazione esplicita sul dispositivo fisico;CALC: allocazione via funzione hash; overflow

gestito con open addressing a scansionelineare;

VIA SET: allocazione contigua per elementi memberdello stesso set type; l'opzione NEAR TOOWNER forza l'allocazione in prossimita' delrecord owner.

Per quanto riguarda i collegamenti tragli elementi di un set type, si puo'avere:

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 unavisita del DB che "naviga" sui camminidefiniti dalle istanze dei set.L'elaborazione e' "record-oriented", inquanto si accede ad un singolo recordalla volta.

Concetto di record corrente:

a) del programma (ultimo recordvisitato)

b) del record type R (idem, ma relativoa R)

c) del set type S (relativo a S, owner omember))


Istruzione FIND

FIND ANY <record type> [USING <fieldlist>]

trova un record sulla base dieventuali condizioni di eguaglianzasui campi. (N.B.: USING = WITH)

FIND ANY Impiegati USING Nome = "Luca"

FIND DUPLICATE <record type> [USING<field list>]

per trovare altri record chesoddisfano le condizioni.

FIND DUPLICATE Impiegati USING Nome = "Luca"FIND (FIRST|NEXT|PRIOR|LAST) <recordtype> WITHIN <set type> [USING <fieldlist>]

permette l'accesso ai membri di unset type.

FIND FIRST Impiegati WITHIN Lavora_inFIND OWNER WITHIN <set type>

trova l'owner del set corrente.

FIND OWNER WITHIN Lavora_inIstruzione GET

GET < record type >:

restituisce il record corrente nellavariabile di programma assegnata.GET DIPARTIMENTI;


Esempi:

stampa dei nomi di tutti gli impiegati diun dipartimento

Dipartimento.Codice = $DCod {$DCod : variabile diprogramma }FIND ANY Dipartimento USING Codiceif DB_STATUS = 0 {Flag di stato}then begin

FIND FIRST Impiegati WITHIN Lavora_inwhile DB_STATUS = 0do begin

GET Impiegatiwrite Impiegati.NomeFIND NEXT Impiegati WITHIN Lavora_inend

end;

stampa del nome del mio dipartimento edei nomi di tutti i suoi impiegati

Impiegati.Codice = $ICod {$ICod : e' il mio codice}FIND ANY Impiegati USING Codiceif DB_STATUS = 0then begin

FIND OWNER WITHIN Lavora_inGET Dipartimentowrite Dipartimento.NomeFIND FIRST Impiegati WITHIN Lavora_in ...........{ prosegue come sopra }end;


Modello Gerarchico

A differenza del modello relazionale, ilmodello gerarchico non e' mai statoformalmente definito. Ne' si e' avuto untentativo di standardizzazione simile aquello operato dal CODASYL DBTG per ilmodello reticolare.

L'origine e' industriale (IBM), e risentefortemente dell'influenza di aspetti piu'"fisici" che "logici"

Sistemi commerciali :

IMS (Information Management System)IBM

E' il sistema gerarchico piu' diffuso, che hapraticamente dominato il mercato dalla fine degli anni'60 agli inizi degli anni '80, fino all'avvento deisistemi relazionali. Il suo DML, detto DL/I (DataLanguage/I), non e' integrato nel sistema, e forzanecessariamente l'uso di un linguaggio ospite.

System 2000 MRI (ora SAS, Inc.)

L'aspetto piu' saliente dei sistemigerarchici e' sicuramente l'efficienzanell'esecuzione delle operazioni che sonoconformi alla struttura prescelta perrappresentare le associazioni tra i dati.


Un database gerarchico e' una foresta,ovvero una collezione di alberi.

La scelta della struttura degli alberipuo' indurre asimmetrie nellarappresentazione (logica e fisica), conconseguente sbilanciamento delleprestazioni.

S1 Smith 20 London 200

S2 Jones 10 Par is 400


P2 Bolt Gr een 17 Paris

P3 Screw Blue 17 Rome


S2 Jones 10 Paris 300



I concetti alla base di un DB gerarchicosono quelli di record type ( segment inIMS) e di parent-child relationshiptype (PCR type). Quest'ultimo e' unlegame 1:N tra un parent record type e unchild record type. In un DB gerarchico ilrecord type che non ha un parent e' dettoroot .

La rappresentazione di associazioni M:N(ad es. tra Fornitori e Parti) puo' darluogo a replicazione dei dati, a meno dinon fare uso di virtual (o pointer )record type .

200

400


P2 Bolt Gr een 17 Paris


S2 Jones 10 Paris 300

E' anche possibile avere due gerarchiedistinte, con root Parti e Fornitori.


Supporto fisico

Dato un albero di record types e PCRtypes, una sua istanza e' un albero incui viene stabilito un ordine lineare suirecord di ogni record type.

L'albero e' memorizzato (logicamente)secondo una visita in preordine dei nodi.

Dept.

Emp. Proj.

Funds

DM

John Mary Ann Stars Games

ToyfunRoblab FlyCo.

DM John Mary Ann

Stars Games ToyfunRoblab FlyCo.

....

....

....

databaseschema

occurrencetree

linearstor age


Organizzazioni fisiche in IMS

HSAM (Hierarchical Seq. Access Method):allocazione sequenziale, valida perarchivi storici.

HISAM (Hierarchical ISAM):gestione via ISAM (o VSAM), conaccesso indiciato alle root deglialberi.Un albero e' memorizzato in unapagina ad esso dedicata e, senecessario, nell'area di overflow.

HIDAM (Hierarchical Indexed Direct AM):simile all'HISAM, ma senza gestioneesclusiva delle pagine, e con uso dipuntatori per il mantenimentodell'ordinamento lineare dell'albero.

HDAM (Hierarchical Direct AM):i record root sono gestiti via hash;gli overflow sono in area primaria acatene non coalescenti.


DML

GET UNIQUE <record type> WHERE<conditions>

per reperire root record sulla basedi condizioni

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) figliodel padre corrente

GET NEXT WITHIN PARENT Impiegati

Esempio:

elenco dei progetti del dipartimento "DM"

GET UNIQUE Dipartimento WHERE Codice = "DM"while DB_STATUS = 0do begin

GET NEXT WITHIN PARENT Progettiwrite Progetti.Nomeend;


Nel caso di associazioni M:N si ha unaformulazione dell'interrogazione che,dipendendo fortemente dalla strutturadell'albero, facilita alcuneinterrogazioni a scapito di altre.

Esempio:

stampa di tutti i Fornitori che hannofornito la parte "P1"

GET UNIQUE Parti WHERE P# = "P1"while DB_STATUS = 0do begin

GET NEXT WITHIN PARENT Fornitoriwrite Fornitori.S#end;

stampa di tutti le Parti fornite dalFornitore "S1"

GET FIRST Partiwhile DB_STATUS = 0do begin

Found = FALSEwhile (DB_STATUS = 0) and not(Found)do begin

GET NEXT WITHIN PARENT Fornitoriif DB_STATUS = 0then if Fornitori.S# = "S1"

then beginFound = TRUEwrite Parti.P#end

endGET NEXT Partiend;

Modello Relazionale


A differenza dei modelli reticolare egerarchico, il modello relazionale haavuto origine nei laboratori di ricercae, solo successivamente, e’ statosupportato da sistemi commerciali.

La definizione formale degli elementi delmodello ha permesso lo sviluppo di unateoria in grado di supportareefficacemente il progetto logico di unDB.

1970: “A Relational Model of Data for LargeShared Data Banks”, di E.F. Codd (IBMRes. Lab., San Jose’, CA)

1974: prima versione del linguaggio SQL(allora SEQUEL)

1975-79: sviluppo del prototipo System R presso ilaboratori IBM di San Jose’

1981: SQL/DS, versione commerciale di SystemR

1983: IBM Database2 (DB2)

Altri sistemi :

SQL/SERVER Microsoft

ORACLE Oracle

INFORMIX Informix


La rappresentazione dei dati nel modellorelazionale 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 prodottocartesiano D1 x D2 x ... x Dn

Il valore di n e' detto grado (o"arita'") della relazione.

Esempi :D1 = { mela, pera };

D2 = { (10,12), (11,23), (4,20) }

Una possibile relazione (binaria) su D1 eD2 e’ data dalle tuple

R={ (mela, (11,23)), (pera, (10,12)),(mela, (10,17)) }

Una relazione ternaria contenuta in D1 xD2 x D1 e':

R' = { (mela,(11,23),pera),(pera,(11,23),mela) }


La rappresentazione piu' intuitiva di unarelazione e' di tipo tabellare

mela (11,23)

mela (10,17)

pera (10,12)

ma e' anche possibile unarappresentazione "spaziale" a ndimensioni

(11,23) (10,12) (10,17)

mela 1 0 1

pera 0 1 0

o anche una rappresentazione di tipoinsiemistico

mela

pera

(10,12)

(11,23)

(10,17)


Attributi e Domini

La definizione data di relazione e'ispirata direttamente al concettomatematico di relazione tra insiemi.

In quanto tale:

1) e' un insieme, e quindi non possonoesistere relazioni con tupleduplicate (anche se nei DBMS cio' e'normalmente tollerato!)

2) risulta dipendente dall'ordine deidomini o, considerando larappresentazione tabellare, dellecolonne.Es: La relazione

R''={ ((11,23),mela), ( (10,12),pera), ((10,17),mela) }

e' distinta da R vista in precedenza.

Un dominio specifica unicamente uninsieme di valori possibili, ma non dicenulla sull' uso che di tali valori vienefatto. Questo e' particolarmenteimportante nel caso di domini nondistinti. Per poter trattare agevolmenterelazioni con domini ripetuti, fornireun'intuizione sul significato dei valoridel dominio, e rendere irrilevantel'ordine delle colonne, si introduce ilconcetto di attributo

Un attributo e' una colonna di unarelazione designata da un nome.


Data la tupla t = (d1,...,di,...,dn), die' detta l'i-ma componente di t.

Si supponga che l'i-ma colonna dellarelazione sia designata con il nome Ai.Allora ci si puo' riferire all'i-macomponente di t con la notazione t.Ai ot[Ai].

Frutto X_Y

mela (11,23)

mela (10,17)

pera (10,12)

Gli attributi della relazione sono Frutto e X_Y,definiti rispettivamente sui domini D1 e D2.

Se t = (mela, (11,23)), allora t.X_Y = t[X_Y] = (11,23).

Facendo uso degli attributi l'ordinedelle colonne diventa irrilevante, acondizione che ogni attributo di unarelazione abbia un nome distinto.

Seconda definizione di relazione:

Una relazione di grado n e' un insieme dituple t, dove t e' una funzione t:Ai _ Di(i = 1,2,..,n) che assegna ad ogni (nomedi) attributo Ai un valore del dominioDi.

Esempio: La tupla (mela, (11,23)) e' definita dai duemapping t(Frutto) = mela

t(X_Y) = (11,23)


Linguaggi di interrogazione procedurali enon

L'uso di un linguaggio di programmazioneprocedurale convenzionale (Cobol, Basic,Pascal, C, etc.), che si appoggia ad unfile system, comporta una conoscenza didettaglio circa l'architettura dei file ela stesura di codice che "naviga" lestrutture 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')

endend;Un DBMS rende l'accesso ai file più semplice attraversol'uso di un query language : il livello di dettagliorichiesto all'utente dipende dal tipo di modello datiadottato.


Esempio di query : trova il Direttore di ROSSI

Modello Reticolare

Il modello dei dati prevede strutture multilista chemettono in connessione gli impiegati ai propridipartimenti e i dipartimenti ai direttori.

IMPIEGATI.Nome := 'ROSSI'find IMPIEGATI record by CALC_KEYfind owner of current IMP-DIP setfind first Direttore record in current DIP-DIR setprint Direttore.Nome

Modello Relazionale

IMPIEGATI(Nome,CodImp,CodDip,....)

DIPARTIMENTI(CodDip,Direttore,......)

in SQL :

select Direttorefrom IMPIEGATI,DIPARTIMENTIwhere IMPIEGATI.Nome = 'ROSSI'and IMPIEGATI.CodDip = DIPARTIMENTI.CodDip


Gestione delle transazioni

Un DBMS provvede alla gestione della concorrenza delletransazioni sulla base di dati. Si deve garantireinfatti che gli accessi ai dati, da parte di diverseapplicazioni, non interferiscano; al fine di conservarel'integrità dei dati è necessario far ricorso adopportuni meccanismi di controllo della concorrenza.

Esempio : transazione di prelievo di una quantità Qdal conto corrente con codice XXXmemorizzato 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 chevogliono prelevare, rispettivamente 80 e 50, dallostesso conto corrente con disponibilità 100, vengano asovrapporsi come segue, provocando un prelievo noncorretto:

CC.disponibi le i nC_Correnti

100 100 100 100 50 20

T1 leggi -80 aggiorna

T2 leggi -50 aggiorna

spaziodi lavoro T1

100 100 20 20 20 20

spaziodi lavoro T2

100 100 50 50


T1 e T2 devono accedere in modo esclusivo al record: ilDBMS deve rendere disponibili primitive per lock edunlock a diversi livelli di granularità :

la transazione si modifica come segue:

leggi con lock da C_Correnti il record CC con codiceXXX;

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 chetermina se la risorsa record CC è disponibile per unaccesso esclusivo.

Naturalmente con un DBMS evoluto non è responsabilitàdel programmatore la gestione della concorrenza, (taleresponsabilità è invece piena nel caso di uso direttodel file sytem da linguaggio di programmazione).

Il query language svincola l'utente dall'esplicitare imeccanismi di locking, ad esempio in SQL interattivo T1sarebbe:

update C_Correntiset disponibile = disponibile - 80where codice = 'XXX' and disponibile >= 80

Un altro problema che si può presentare, e che il DBMSdeve essere in grado di gestire, è il deadlock(stallo). Ad esempio : T1 e T2 che necessitano dell'usoesclusivo di due risorse R1 ed R2, richiedendole comesegue:

T1 : lock R1; T2 : lock R2;


usa R1; usa R2;lock R2; lock R1;usa R1 e R2; usa R1 e R2;unlock R1; unlock R1unlock R2; unlock R2;

La concorrenza di T1 e T2 può comportare un'attesainfinita da parte di entrambe le transazioni. Il nucleodi gestione della concorrenza deve rilevare condizionidi deadlock e procedere ad un ripristino consistente deldatabase. In caso di database distribuito su piùcomputer il controllo e la gestione della concorrenzaimplicano il ricorso a tecniche molto sofisticate.

Linguaggi di IV generazione

Un ambiente di sviluppo di database deve consentire unaelevata produttività e affidabilità del software,facilitare la prototipizzazione rapida, rendere semplicegli interventi di manutenzione e permettere il riuso peraltre applicazioni. Le possibilità offere devonocomprendere:

* Simple Query Language* Complex Query Language* Report Generator* Graphics Generator* Application Generator

Un linguaggio di IV generazione deve offrirecaratteristiche di sistema di supporto alle decisioni edi modellizzazione concettuale. Deve inoltre consentireinter-operabilità fra database che si appoggiano a varitipi di DBMS.


Sicurezza dei dati

Oltre ad offrire protezione dei dati in caso di guasto,un DBMS deve garantire la base di dati da accessi nonautorizzati. A tale scopo deve essere consentita ladefinizione di password e di particolari privilegidifferenziati per classi di utenti. Ad esempio in SQL èpossibile restringere, per certi utenti, la visibilitàdegli attributi di una relazione; infatti data larelazione:

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 relazionecon solo gli attributi Cognome,Nome,CodFisc.

ANAG(Cognome,Nome,CodFisc)

e non corrisponde ad un vero file fisico, pur essendointerrogabile 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'accessoall'archivio PERSONE, ad esempio:

a) utenti con accesso in lettura e modifica allarelazione PERSONE

b) utenti con accesso in lettura alla relazione PERSONEc) utenti con accesso in lettura alla vista ANAG

Alcuni sistemi consentono anche la materializzazionedelle viste. Il problema dell'aggiornamento delle vistein virtù di modifiche apportate allo schema del database


è normalmente compito del progettista ma in alcunisistemi può essere parzialmente facilitato da strumentiautomatici.

In fig. 1.5 un esempio di schema E/R che descrive leinter-relazioni che intercorrono fra le entità STUDENTE,CORSO, PROFESSORE e DIPARTIMENTO.

Uno studente, contraddistinto dagli attributi Cognome,Nome, Data di nascita, Matricola, può aver sostenutoesami in una certa Data esame riportando un certo Votocon riferimento ad un certo corso. Interessa memorizzareinformazioni di uno studente anche se non ha sostenutoesami. Per ogni corso si dispone delle informazioniCodCorso e NomeCorso; un corso può esistereindipendentemente dal fatto che vi siano o meno studentiche abbiano già sostenuto esami. Per un corso dunque vipossono essere dunque zero, uno o più studenti che hannosostenuto il relativo esame. Il legame associativo trale entità studente e corso è dunque di tipo molti amolti non obbligatoria, ovvero 1 ad N parziale inentrambe le direzioni, ed è espresso in fig. 1.5 dallarelationship (associazione) ESAME .

In fig. 1.5 si mostra anche un'altra associazioneTITOLARITA' tra l'entità CORSO e l'entità PROFESSORE. Unprofessore è obbligatoriamente titolare di un corso mapuò essere titolare anche di più corsi. Un corso invecepuò essere istituito, ma non attivato e quindi può nonancora avere un titolare. L'associazione è dunque totaledi tipo 1 ad N nella direzione professore-corso e ditipo 1 ad 1 parziale nella direzione corso-professore.Analoghe considerazioni valgono per l'associazioneAFFERENZA che mette in relazione le entità DIPARTIMENTOe PROFESSORE.

La semantica della notazione grafica usata per esprimerequanto detto a parole sarà precisamente introdotta nelcapitolo dedicato alla modellizzazione concettuale E/R.


Cognome, Nome

STUDENTE CORSOESAME

PROFESSOREDIPARTIMENTO AFFERENZA

TITOLARITA'

Data di nascita

Matricola Data esameVoto

CodCorso

NomeCorso

CodProf

Cognome,Nome

CodDip

Denominazione

Indirizzo

Figura 1.5

Lo schema E/R può essere mappato nel modello relazionalecome 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ò sembrarepiuttosto intuitivo la realizzazione proposta nelmodello relazionale, la fase di progetto logico, ingenerale, è piuttosto complessa e necessita dimetodologie e strumenti appropriati.


Il Livello vista (esterno)

Indipendenza dei dati

Due sono i livelli di indipendenza che si possonorealizzare in un database ben progettato. Il primo tipodi indipendenza, detto indipendenza fisica , consentedi apportare modifiche all'organizzazione fisica deidati senza alterare i programmi di interrogazione chesono stati scritti nel rispetto del modello dei daticoncettuale messo a disposizione dal DBMS. Lapossibilità di costruire viste consente inoltre direalizzare un' indipendenza logica. Infatti a voltepuò essere necessario apportare modifiche allo schemaconcettuale (logico) ed è probabile che alcunisottoschemi non debbano essere modificati, ovvero non ènecessario modificare tutti i programmi applicativi.Solo quelli che visitano la porzione di dati interessataai cambiamenti effettuati andranno rivisti edeventualmente modificati.


1.4 Linguaggi dei database

In un linguaggio di programmazione convenzionale lefrasi di dichiarazioni dei dati e gli statement dicomputazione vengono espressi in una sintassi unica,quella del linguaggio. In un database, invece, sidistinguono:

. 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 esistonoindipendentemente dai programmi applicativi.

Linguaggio di definizione dei dati

Il DDL non è un linguaggio procedurale ma piuttosto unanotazione per creare e manuntenere la struttura di unabase di dati; a seconda del modello concettuale adottatoil DDL consente di descrivere i tipi di entità in giocoe 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à Studentecreate 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 strutturedati definite.


Ad esempio:

insert into Studentivalues ('20111','Bianchi','Mario',23);

select Cognome,Nomefrom Studentiwhere Voto >= 18order by Cognome;

Linguaggio di controllo dei dati

Il DCL consente di effettuare operazioni di controlloquali ad esempio:

commit per terminare una transazione e renderepermanenti le modifiche effettuate alla base di dati;

rollback per ripristinare la base di dati ad unostato consistente annullando gli effetti prodotti damodifiche fatte dopo l'ultimo commit

grant per assegnare privilegi di accesso alleinformazioni

revoke per rimuovere privilegi

safepoint per creare un checkpoint


Linguaggi ospite

Oltre alle istruzioni che consentono la manipolazionedella base di dati è necessario, per realizzareapplicazioni, disporre di linguaggi general purpose. Atale scopo sono percorribili tre alternative:

a) il DBMS dispone di un linguaggio proprio, ad esempioin dBASE IV:

* un esempio di istruzioni procedurali

use Ordinido while .not. eof ()

clearlist next 5 N_Ordine,Descr_Parte,Costo?wait "Premi X:fine,B:indietro,spazio:continua" to

Mstopdo case

case Mstop $ "Xx" .or. eof()exit

case Mstop $ "Bb"skip -9

otherwiseskip

endcaseenddo

b) I comandi per la manipolazione dei dati vengonoinvocati 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 relativoprecompilatore, ad esempio PRO*C in ambiente ORACLE:


/* 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 */}


La fig. 1.6 illustra i componenti principali di un DBMSed evidenzia le diverse modalità di interazione,corrispondenti a differenti responsabilità e ruoli.

Componenti principali di un DBMS

Processore diistruzioni DML e DCL Compilatore

DDL

Gestore DB

Gestore file

Tavole diautorizzazione

Tavole per il controllodegli accessiconcorrenti

Tavole didescrizioneDB

DB

Interrogazioneestemporanea

Programmaapplicativo

Schema DB

Figura 1.6


1.5 Verso nuove applicazioni database

Applicazioni VLSI, CAD, Software Engineering, GIS, DDS,etc. necessitano di strumenti concettuali sofisticatiper modellare la realtà di pertinenza e di potentimeccanismi per le operazioni sulle informazioni.

Per queste applicazioni la separazione tra DML elinguaggio ospite crea notevoli difficoltà; si pensi adesempio alla memorizzazione di immagini costruitetramite un assemblaggio di immagini componenti ; in talcaso è necessario disporre di costrutti che consentanoricorsione (si noti ad esempio che in un DBMSrelazionale non è possibile esprimere interrogazioniricorsive). Si pensi, con riferimento alla fig. 1.7, aduno zoom che comporta un'interrogazione ricorsiva sullabase di dati, se la figura è memorizzata come insieme diriferimenti a componenti.

telefono 1

telefono 2

posacenere

fotocopiatrice

cestino

Figura 1.7


Integrazione tra DML e linguaggio ospite

Il problema di combinare capacità di rapido accesso alleinformazioni, tipiche di un DML, e caratteristichegeneral purpose di un linguaggio ospite, viene oggiaffrontato secondo due approcci :

* paradigma orientato agli oggetti

uso di un linguaggio che consenta di definire tipi didati astratti, che abbia capacità espressive, che possarappresentare il comportamento degli oggetti, chefaciliti l'uso di tecniche di ingegneria del software.

Ad esempio in IRIS definita la classe Persona e lafunzione Genitore è possibile definire la funzione Nonnocome segue:

Create function Nonno(Persona p) -> Persona asselect 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.nomefrom Persona X, Persona Ywhere X.genitore = Y.nome

immaginando di avere una relazione

Persona(nome,genitore)

e definendo un join fra X e Y sinonimi della stessarelazione Persona.

Si noti che nel modello ad oggetti definito, la funzionecorrisponde ad un metodo, ed il risultato è ancora unasottoclasse della classe Persona.

Un altro esempio : "Trova tutti i superiori di Rossi",potrebbe essere espresso nel modello di ORION come :

( select Impiegato


( recurse Superiore)(Nome = "Rossi"))

dove Impiegato è una classe con attributo Nome e unattributo Superiore. Il dominio dell'attributo Nome è laclasse Stringhe e il dominio dell'attributo Superiore èancora la classe Impiegato. L'espressione ( recurseSuperiore) dice che, una volta trovata un'istanza dellaclasse Impiegato che soddisfa al predicato (Nome="Rossi"), devono essere trovati ricorsivamente i valoridell'attributo Superiore.

Questa interrogazione non può essere espressanell'algebra relazionale.


* paradigma logicousa un linguaggio che applica regole logiche del tipo

if ...... then ......

Alcuni predicati sono considerati parte dello schemaconcettuale, altri consentono di definire viste, altriancora possono essere usati per costruire programmiapplicativi. Al contrario del paradigma ad oggetti, ilparadigma logico offre un linguaggio essenzialmentedichiarativo.

Ad esempio:

manager (Imp,Dir) :-impiegato (Imp,Dip)& dirige (Dip,Dir)

che asserisce : Dir è manager di Imp se sono verificatidue fatti contemporaneamente, ovvero Imp è impiegato neldipartimento 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 suoresponsabile 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 Orientato a Dichiarativo?

DML/host


La predizione di Ullman è che i KBMS sostituiranno gliOO-DBMS , rivestendo l'analogo ruolo svolto dai sistemirelazionali nei confronti dei sistemi gerarchici ereticolari. La ragione addotta è principalmentel'assenza di un linguaggio puramente dichiarativo el'orientamento non a valori, un passo indietro rispettoai sistemi relazionali. Personalmente questaaffermazione così categorica mi lascia sconcertato e miricorda certe affermazioni di coloro che, difendendo aspada tratta l'approccio relazionale, dimenticavanolungo 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 è dasottovalutare.

La differenza tra i tre livelli fisico,concettuale,vistapuò essere meglio compresa facendo un'analogia con ilinguaggi 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 elencodi persone, senza preoccuparsi di conoscere il formatointerno di rappresentazione. A livello fisico, ovvero in

1960 Gerarchici

Reticolari

oggetti No Separ

1970 Relazionale valore S ì Separ

1980 OO-DBMS oggetti No Integ

1990 KBMS valori S ì Integ


memoria principale, la dichiarazione porta come effettol'allocazione di una struttura di 100 blocchi di byteconsecutivi, ciascuno lungo 70 byte.

L'indirizzo fisico di un elemento Elenco[i] verràcalcolato come:

base + (i-1)*70

essendo base l'indirizzo in cui è stato allocato ilprimo elemento dell'array Elenco.

Il programmatore fa semplicemente uso del nome simbolicoElenco[i], ad esempio può scrivere

Elenco[i].qualifica:=impiegato

per assegnare la qualifica di impiegato alla persona i-esima dell'elenco,ignorando i dettagli del livellofisico.

Una vista sull'array Elenco potrebbe essere definitadichiarando una funzione, ad esempio:

function ContaImpiegati(m: integer ): integer ;var Conta:integer; i:integer;begin Conta:=0;

for i:=1 to mdo if Elenco[i].qualifica = impiegato

then Conta:=succ(Conta);ContaImpiegati := Conta

end ;

per calcolare quante persone tra le prime m in Elencohanno la qualifica di impiegato.


In tal modo la chiamata della funzione realizza unavisione diversa dell'array, come procedimento di calcolodi una quantità relativa solo ai primi m elementi diElenco che godono di una certa proprietà.

Alcuni sistemi consentono anche la materializzazionedelle viste. Il problema dell'aggiornamento delle vistein virtù di modifiche apportate allo schema del databaseè normalmente compito del progettista ma in alcunisistemi può essere parzialmente facilitato da strumentiautomatici.

Il livello esterno si riferisce al modoin cui le varie classi di utentepercepiscono la base di dati: ad unostesso schema concettuale (o ad unostesso schema logico) possonocorrispondere diverse viste esterne.


Ad esempio, con riferimento a databaserelazionali, allo scopo di differenziarequesti due tipi di rappresentazione, seper il progetto di un database si è fattouso di schemi basati sul modello Entity-Relationship :E/R, si è soliti usare iltermine schema concettuale perquest'ultimi ed il termine logicalschema per gli schemi basati sulmodello dei dati relazionale e derivatidagli schemi E/R. In altre parole loschema logico coincide con lo schemaconcettuale che sarà poi disponibileeffettivamente all'utente, in quanto imeccanismi di interrogazione sono fondatisul modello dei dati adottato dal DBMS enon sul modello concettuale impiegato peril progetto.


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 interfacciae stato (incapsulazione), classi, ereditarietà

6th Avenue

7th Avenue

Roadname:String;road type: {road, avenue, boulevard, lane, ...}segment list :sequence of Road segment|

IntersectionRoad Segment

in road:Road;shape of segment:Arc|Linestart: Intersectionend:Intersectiondirection:{one-way-SE, one-way-ES,two-way}address range:{Street Number,Street Number}odd side:{left,right}

Intersectionincoming roads:Set of Road Segmentposition:Coordinate

Sistemi di Gestione di Basi di dati File System vs DBMS · Introduzione ai DBMS pag. 9 Lo schema...

Documents

Transcript of Sistemi di Gestione di Basi di dati File System vs DBMS · Introduzione ai DBMS pag. 9 Lo schema...