Architettura - Progetto Atena

◊ Con riferimento alla parte di definizione dei dati si distinguono i ruoli necessari
per una corretta amministrazione di una base di dati (DBA: Data Base Administrator) :
Architettura dei RDBMS
• Architettura
ANSI/X3/SPARC
◊
Alla fine degli anni 80 il gruppo di studio ANSI/X3/SPARC propose
un'architettura di riferimento per i sistemi di gestione di basi di dati.
◊
L'architettura funzionale distingue tre livelli di organizzazione con riferimento ai
compiti di amministrazione di una base di dati e altrettanti livelli di funzionalità di
manipolazione dei dati.
◊
L'architettura si divide in due parti con riferimento al dizionario dei dati : parte
descrittiva dei dati e parte orientata alla manipolazione dei dati.
◊
I ruoli sono indicati da esagoni in figura, mentre i rettangoli indicano moduli
funzionali detti processori nella terminologia ANSI.
1
3
6
INTERNAL
SCHEMA
PROCESSOR
CONCEPTUAL
SCHEMA
PROCESSOR
3
DATA
definisce lo schema concettuale attraverso l'interfaccia 1; lo schema concettuale viene
compilato dal conceptual schema processor e viene memorizzato nel data dictionary, che
contiene tutti gli schemi e le regole di corrispondenza.
♦
Application Administrator :
definisce schemi esterni attraverso un linguaggio di descrizione (interfaccia 2); per
definire le regole di corrispondenza tra uno schema esterno e schema concettuale può
consultare lo schema concettuale attraverso l'interfaccia 3. Gli schemi esterni prodotti,
insieme alle regole di corrispondenza, vengono forniti, tramite l'interfaccia 4,
all'external schema processor che li compila e li memorizza nel data dictionary.
♦
System Administrator :
◊
Le varie interfacce per la definizione dei dati ai vari livelli sono anche note con il
nome di DDL (Data Description Language); più precisamente si distinguono:
APPLICATION
ADMINISTRATOR
4
2
7
Enterprise Administrator :
definisce lo schema interno e le regole di corrispondenza con lo schema concettuale; a
tale scopo usa un linguaggio descrittivo (interfaccia 6). Lo schema interno prodotto viene
compilato dall'internal schema processor e memorizzato nel data dictionary.
ENTERPRISE
ADMINISTRATOR
DATABASE
ADMINISTRATOR
♦
EXTERNAL
SCHEMA
PROCESSOR
5
DICTIONARY
♦
conceptual DDL source format
♦
conceptual DDL compiled format
♦
conceptual DDL report format
♦
external DDL source format
♦
external DDL compiled format
♦
internal DDL source format
♦
internal DDL compiled format
14
INT ERNAL
STORAGE
TRANSFORMER
11
10
CONCEPTUAL
INT ERNAL
TRANSFORMER
EXTERNAL
CONCEPTUAL
TRANSFORMER
9
12
STORAGE
SUBSYSTEM
APPLICATION
8
8
13
SECONDARY
MEMORY
PROGRAMMER
END USER
ANSI/X3/SPARC functional architecture
BASI DI DATI
Architettura
p a g .1
BASI DI DATI
Architettura
p a g .2
◊
• Architettura di IBM DB2
Con riferimento alla manipolazione dei dati si distinguono:
♦
Application Programmer :
produce il software applicativo
◊
L'architettura di DB2 è derivata da quella di System R.
◊
A grandi linee DB2 è costituito da tre principali componenti :
♦
♦
Application End User:
usa software applicativo
♦
◊
Le richieste al DBMS si manifestano all'interno di programmi applicativi o
vengono introdotte direttamente in interattivo. In ogni caso, dopo una fase di parsing,
esse devono essere ricevute da un external-conceptual transformer (interfaccia 9). Si può
concepire una pluralità di processori, ad esempio uno per ogni schema esterno. La
trasformazione è bidirezionale e il data dictionary funge da deposito di consultazione per
le corrispondenze (interfaccia 14).
◊
Il conceptual-internal transformer riceve richieste dai processori suddetti e le
mappa sullo schema interno. Anche in questo caso è necessario risolvere il problema
opposto. Il data dictionary viene consultato attraverso l'interfaccia 14.
♦
system services
operazioni di sistema, comunicazioni all'operatore, logging
locking services
controllo e gestione degli accessi concorrenti
database services
definizione, ricerca, aggiornamento dei dati
◊
Le prime due componenti sono per lo più trasparenti per l'utente finale e per il
programmatore di applicazioni.
◊
Ad ogni componente é assegnata una macchina virtuale ovvero uno spazio di
indirizzi separato di MVS (sistema operativo Multiple Virtual Systems).
CICS
◊
IMS/DC
IMS/DB
TSO
L'internal-storage transformer riceve richieste riguardanti lo schema interno e le
soddisfa accedendo alla memoria secondaria. Normalmente viene realizzato
appoggiandosi al file system.
◊
Le varie interfacce per la manipolazione dei dati ai vari livelli sono per lo più
DML (Data Manipulation Language); più precisamente si distinguono:
♦
external DML source format
♦
external DML compiled format
♦
conceptual DML source format
♦
internal DML compiled format
Database
Services
User
Data
Catalog
System
Services
Operator
Active
Logs
BSDS
Directory
♦
storage subsystem language compiled
♦
secondary storage interface
♦
data dictionary access interface
BASI DI DATI
Locking
Services (IRLM)
Architettura
Archive
Logs
format
Struttura di DB2
p a g .3
BASI DI DATI
Architettura
p a g .4
◊
◊
System Services
♦ Controllo connessioni con altri sottosistemi di MVS (CICS, IMS/DC, IMS/DB, TSO).
♦
Gestione operazioni di system startup, shutdown e comunicazioni per l'operatore.
♦
Gestione log di sistema a cui viene dedicato un insieme predefinito di disk data sets.
Il sottosistema RDS realizza l'interfaccia relazionale a livello esterno, provvedendo
a fornire primitive di definizione, controllo, ricerca e manipolazione dei dati. I compiti
principali svolti sono:
♦analisi sintattica e semantica
♦controlli di autorizzazione
♦verifica di vincoli di integrità
♦gestione del catalogo
♦ottimizzazione degli accessi
♦generazione del codice
♦
Quando un active log data set viene riempito, DB2 ne attiva uno nuovo e
copia il vecchio su un archive log data set su disco o su nastro. In caso di
riempimento di tutti gli active log data set , essi vengono riciclati a partire dal
primo. (Per maggiore sicurezza può essere mantenuta una copia di tutti gli active
data set e degli archive log data set).
♦
♦ Le informazioni relative ai log data set sono memorizzate nel BSDS (Boot
Strap Data Set).
◊
Uno degli scopi principali di DB2 è consentire l'elaborazione di due differenti
categorie di transazioni :
♦
SQL stand alone statements
eseguiti una volta sola isolatamente
Estrazione di statistiche circa le prestazioni del sistema e gli accessi. Queste
informazioni vengono collezionate con l'Instrumentation Facility di DB2 e possono essere
presentate sotto forma di report facendo uso di DB2PM (performance monitor di DB2).
◊
Locking Services
♦
Questi servizi vengono resi a cura del sottosistema IRLM (IMS Resource Lock
Manager). Nonostante la presenza del termine IMS, questo modulo non ha nulla a che
fare con il gestore IMS, poichè di fatto viene invocato da DB2 per il controllo degli
accessi concorrenti al database indipendentemente dalla presenza di IMS nel sistema.
◊
Database Services
A questo modulo sono demandati i compiti relativi alla definizione, reperimento e
aggiornamento dei dati. È costituito da due sottosistemi che insieme sovraintendono
alla preparazione di un'applicazione e alla sua successiva esecuzione, così organizzati :
♦
Bind
♦
Runtime Supervisor
BASI DI DATI
Data Manager
♦
Buffer Manager
Architettura
Precompiler
Il precompilatore è un preprocessore per applicazioni scritte in un linguaggio
ospite (PL/I, COBOL,...) che includono statement SQL. Il precompilatore analizza il
modulo sorgente e sostituisce gli statement SQL con chiamate nel linguaggio ospite al
Runtime Supervisor. Per ogni statement SQL il precompilatore genera un DBRM :
Database Request Module, che chiama in causa l'ottimizzatore per la produzione di un
piano di accesso.
Dopo la precompilazione e la susseguente compilazione di un programma in
linguaggio ospite esteso con primitive relazionali, viene generato un modulo di accesso,
cioè un codice eseguibile su RSS. Per contro una transazione ad hoc viene ottimizzata al
tempo di esecuzione e il suo corrispondente modulo di accesso viene generato
dinamicamente.
Dal punto di vista del carico di lavoro l'esecuzione di un canned program non
include, una volta installato, operazioni di compilazione, ottimizzazione e generazione di
codice.
♦
◊
Bind
La funzione del componente Bind è quella di compilare uno o più DBRM per
produrre un piano di accesso ottimizzato, che contiene chiamate al Data Manager. Il
piano di accesso contiene un insieme di strutture interne di controllo che rappresentano
la forma compilata degli statement SQL, evidenziando le modalità di esecuzione delle
interrogazioni al database e in particolare le strutture di accesso ai dati scelte.
RSS (Research Storage System)
♦
♦
◊
◊
RDS (Relational Data System)
Precompiler
canned programs
eseguiti più di una volta e corrispondenti ad applicazioni di una certa complessità
◊
♦
♦
♦
p a g .5
BASI DI DATI
Architettura
p a g .6
♦
◊
Runtime Supervisor
Il Runtime Supervisor è residente in memoria principale e sovraintende
all'esecuzione di una applicazione. Per ogni richiesta di accesso, il supervisore usa le
informazioni contenute nel piano di accesso e invoca il relativo servizio offerto dal Data
Manager.
Source
Module
◊
Il sottosistema RSS realizza un'interfaccia con il sottosistema di gestione dei file,
ovvero fornisce primitive per l'accesso ai singoli record nelle tabelle. Rende inoltre
disponibile operatori per il recovery, la gestione della concorrenza, etc. All'interno di
RSS un buffer di pagine agisce come memoria di appoggio conservando le pagine dati
usate più recentemente. Le funzioni principali svolte sono:
Modified
Source
Module
♦gestione della memoria di lavoro ed esterna
♦gestione di indici e links per l'accesso ai dati
♦controllo della concorrenza
♦logging e recovery
♦
Data Manager: Questo componente interagisce con il database a livello fisico e
mette a disposizione sofisticati metodi di accesso, locking, logging e recovery.
♦
Buffer Manager: È responsabile della gestione dei trasferimenti tra memoria di
massa e memoria principale (virtuale). Si prefigge lo scopo di minimizzare il traffico di
I/O attraverso il ricorso a tecniche di read-ahead buffering e look-aside buffering.
♦ System tables
DBRM
Compiler
Bind
Object
Module
Application
Plan
Linkage
Editor
(Load Module)
◊
(Application Plan)
Il componente preposto ai servizi database si occupa anche di gestire una serie di
tabelle di sistema che memorizzano informazioni e statistiche sulle relazioni, sulle
strutture di accesso, sulle operazioni di backup, etc.
Load
Module
Runtime Supervisor
Data Manager
◊
DB
Buffer Manager
Le tabelle di sistema sono organizzate in un system catalog e in una directory.
Mentre il catalog è accessibile al DBA tramite interrogazioni SQL, la directory è solo
per uso interno di DB2.
♦
Precompiler
(Other)
Main Storage
Utilities sono servizi accessori quali ad esempio:
♦caricamento di relazioni
♦riorganizzazione
♦backup completo o incrementale
♦recovery
♦statistiche sulle relazioni e sugli indici
BASI DI DATI
Architettura
DB2 application preparation and execution
p a g .7
BASI DI DATI
Architettura
p a g .8
◊
Il DBRM prodotto dal precompilatore per un programma P contiene copia degli
statement SQL e altre informazioni aggiuntive, e costituirà input per il Bind.
◊
Il Bind svolge essenzialmente funzioni di syntax checking (necessarie anche se
effettuate già dal precompiler in quanto quest'ultimo può essere stato attivato senza la
disponibilità di DB2) e di optimization (scelta del migliore piano di accesso ai dati per
l'esecuzione dell'interrogazione SQL).
PL/I Source Module P
Decoupled
from Rest
of System
EXEC SQL
SELECT
INTO
FROM
WHERE
-
CITY
:XCIT
SUPP
S#='S4';
DBRMs
- Source Listing
- Diagnostics
- Cross-Reference
etc.
Precompiler
CALL
Language-interface
-
-
Modified PL/I Source
Module P
- Listing
- Diagnostics
etc
Member
of Partitioned
Data Set
Bind
Catalog
+
Directory
DBRM for P
(SQL Statements,
etc.
- Parsing Syntax Checking
- Optimization (Access Path
Selection)
- Plan Generation
- Authorization Checking
Application Plan
Built and Stored in
Directory
Bind
Precompilation
BASI DI DATI
Architettura
p a g .9
BASI DI DATI
Architettura
p a g .1 0
◊
L'ottimizzatore sceglie una fra le possibili strategie per l'esecuzione di
un'interrogazione sulla base di considerazioni che riguardano:
◊
Un programma PL/I è stato suddiviso in un load module e in un application plan.
Il load module viene caricato in memoria ed eseguito. Quando si incontra una chiamata
al language interface module il runtime supervisor cerca il piano di accesso e se ancora
valido lo carica in memoria e gli passa il controllo.
♦quali e quante relazioni sono coinvolte
♦la cardinalità delle relazioni
PL/I Load Module P
CALL Language
Interface
-
♦il numero e il tipo di indici disponibili
♦la selettività degli indici
Language
Interface Module
♦la disposizione dei record nelle pagine dati
♦la forma della clausola where
Runtime
Supervisor
♦ ....
On First Call
Fetch Plan
◊
Il piano generato dall'ottimizzatore dipende dunque dalla situazione corrente del
database; pertanto può succedere, in caso di canned programs che sono stati
preottimizzati , che all'atto dell'esecuzione non esistano più le condizioni che hanno
portato l'ottimizzatore a scegliere il particolare piano d'accesso. In questo caso a run
time viene riattivato il bind visto che gli originali statement SQL sono sempre disponibili
in modo da produrre un nuovo piano.
Catalog
+
Directory
Application
Plan
(for P)
Data
Manager
Databases
Execution time
BASI DI DATI
Architettura
p a g .1 1
BASI DI DATI
Architettura
p a g .1 2