Database reverse engineering

Database reverse engineering
Il processo di database reverse engineering [Inmon et al. 82] consiste nell’analisi delle componenti di una base di dati al fine di recuperarne una sua documentazione completa e aggiornata, migliorarne la comprensione in vista di un suo rinnovamento oppure per individuarne eventuali problemi di prestazioni.
L’attività di database reverse engineering si compone di due fasi principali [King 81] :
1. Estrazione (Data structure extraction)
Si analizza l’intero livello fisico del database, dalla definizione delle tabelle alle viste, dai trigger agli indici, con lo scopo di recuperarne lo schema logico ovvero il modello dei dati implementabile da un particolare DBMS; lo schema logico rappresenta le informazioni usando strutture dati dette record e nella progettazione convenzionale di una base di dati, deriva immediatamente dallo schema concettuale, il quale descrive le informazioni mediante il modello entità­relazione o il linguaggio UML [Albano et al. 94]. La principale difficoltà di questa fase sta nell’individuazione delle informazioni o costrutti impliciti che definiscono l’organizzazione del livello fisico, come ad esempio record che possono avere un valore nullo (NULL value) oppure attributi multivalore ovvero attributi che possono avere più di un valore memorizzato: tali caratteristiche spesso non vengono specificate all’interno del livello fisico [Whittington 88].
2. Concettualizzazione (Data structure conceptualization)
Durante questa fase viene ripristinata l’intera descrizione funzionale del database che è appunto lo schema concettuale: a tale scopo viene quindi effettuata un’astrazione delle componenti dello schema logico prodotto dalla fase precedente. Inoltre, la concettualizzazione favorisce una maggiore e più completa comprensione del significato delle informazioni o entità contenute nel database e delle relazioni che associano due o più tipologie di entità.
3. Derivazione dei requisiti Viene effettuata con lo scopo di ottenere, in maniera descrittiva, i requisiti funzionali dell’intera base di dati. In questo modo i requisiti rappresentano il punto di partenza per le 1
successive operazioni di rinnovamento e soprattutto per la riprogettazione dello schema concettuale.
Le informazioni necessarie al reverse engineering di un database possono essere recuperate dalle seguenti componenti:
 Documentazione tecnica
Non sempre disponibile e completa; include anche i commenti al codice DDL (Data Definition Language) ed eventuali data dictionaries.
 Codice sorgente
Il codice sorgente delle applicazioni che fanno uso del database contiene informazioni utili per comprendere come i dati vengono acquisiti, manipolati, validati ed inoltre permette di chiarire le relazioni tra diversi tipi di dato.
 Viste
Una vista è una porzione delle tabelle memorizzate in un database e da essa è possibile trarre informazioni sui nomi dei record, sulle associazioni tra i dati, sui vincoli e sul significato delle informazioni.
 Report
Simile ad una vista ma a differenza di questa, contiene solo dati; può essere utile per raccogliere definizioni precise sui dati ed il loro formato.
 Trigger
I trigger sono regole specificate da azioni attivate automaticamente da determinati eventi, come ad esempio la modifica o la cancellazione di un record; da essi si possono recuperare informazioni sui vincoli di consistenza e d’integrità presenti nel database.
 Esperto del database o DBA (Data Base Administrator)
La persona che si è occupata dello sviluppo o della manutenzione del database è sicuramente la fonte d’informazione più completa ed efficace; tuttavia se il sistema non è recente, sarà poco probabile avere tale/i persona/e a disposizione.
La maggiore difficoltà nell’intero processo di database reverse engineering è la comprensione precisa del significato dei singoli dati [Inmon et al. 82], soprattutto poiché in molti casi i nomi che sono stati attribuiti in precedenza sono poco significativi e non riflettono la loro reale funzione. In 2
aggiunta a questo, anche l’individuazione di informazioni ripetute risulta difficoltosa: infatti, per quanto detto prima, nel caso i nomi dei dati memorizzati non siano significativi, l’individuazione di due o più tipologie di dato che rappresentano la stessa informazione ma con una nominazione diversa, è un’azione complessa e non immediata.
Come esempio concreto di reverse engineering, si consideri un sito web: esso è formato da un insieme di pagine proprio come un database rappresenta una raccolta d’informazioni; per effettuare il reverse engineering di un sito web è necessario inizialmente analizzarne la presentazione ovvero gli aspetti visivi e derivarne lo schema implementativo comprendente i costrutti di un linguaggio di programmazione web (Html o XHtml); questa fase corrisponde all’attività di estrazione (data structure extraction). In seguito, dall’ordinamento nella disposizione dei costrutti implementativi viene recuperato un modello progettuale del sito web che astrae dalla presentazione delle componenti e tale attività viene equiparata alla concettualizzazione (data structure conceptualization).
In conclusione, dal confronto con il processo tradizionale di progettazione di una base di dati, si nota che il database reverse engineering risulta essere inverso rispetto all’ordine in cui vengono svolte le diverse fasi: infatti, la progettazione di un database comincia con l’analisi dei requisiti e termina con la progettazione dello schema fisico; invece, per quanto appena esposto, il reverse engineering parte dall’analisi del livello fisico e si conclude con la raccolta dei requisiti derivati dallo schema concettuale. 3