prova prodotto
INFORMATICA
Abbiamo provato la versione 4.0 di ERwin,
prodotto per la progettazione e la manutenzione
di database distribuito da Computer Associates.
Proviamo a disegnarne un breve profilo
ERwin 4.0
di Computer Associates
[email protected] di Massimo Ruocchio
È laureato in matematica ed è certificato “Oracle Application Developer” ed “XML Engineer”. Si occupa di analisi, progettazione e sviluppo di applicazioni software
D
ovete costruire dal nulla un database, oppure l’avete già costruito ma dovete modificarlo, o ancora il
database c’è ma non è in alcun modo documentato
da un progetto. Che vi serve? Un diagramma entità-relazioni, naturalmente!
La progettazione della base dati è uno dei passaggi più
importanti del processo di ingegneria del software [1]. Per
aiutarci in questa delicata attività esistono svariati tool detti
CASE (Computer Aided Software Engineering), ERwin è
uno di questi. Il prodotto fa parte della suite AllFusion, un
insieme di strumenti per la gestione dell’intero ciclo di vita
del software. Prima di entrare nei dettagli, chiariamo subito
cosa si può fare con ERwin:
G
G
G
G
G
G
Disegnare un diagramma Entità-Relazioni (modello logico
dei dati)
Ottenere automaticamente un modello fisico dei dati
Generare gli script per la creazione del DB
Tenere sempre allineato il modello con la struttura effettiva del DB
Creare un modello partendo da un DB esistente
Ottenere degli utili report
Nel seguito entreremo nel dettaglio delle attività elencate
sopra.
Modello logico e modello fisico
Ogni diagramma di ERwin può essere un modello logico dei
dati, un modello fisico oppure l’insieme dei due. Nel modello
logico s’inseriscono le entità del sistema con gli attributi che le
caratterizzano e le relazioni che le collegano. Il modello fisico
contiene informazioni simili a quelle disponibili nel database
reale, si introducono i datatype specifici del DB che si intende
utilizzare, ci si preoccupa di tablespace, rollback segment e volumi delle tabelle. Se si sceglie di creare un diagramma di tipo
Logico e Fisico, le due rappresentazioni sono sempre allineate.
In una rappresentazione si parla di entità ed attributi, nell’altra di tabelle e colonne, ma la sostanza non cambia.
Questo costante allineamento tra le due rappresentazioni
richiede che il modello logico sia fortemente orientato alla creazione di strutture relazionali e, dunque, non molto
astratto. Vediamo perché. ERwin si allontana dalla teoria
classica dei diagrammi ER in quanto non consente di specificare attributi di relazione.
Una relazione in ERwin non è altro che una linea che
congiunge due entità. Nell’analisi dati classica, invece, è
consentito specificare gli attributi propri della relazione. Un
esempio classico: date le entità “Uomo” e “Donna”, consideriamo la relazione “Matrimonio”. La data del matrimonio
è un attributo proprio della relazione. In ERwin questa
data può essere specificata solo creando una terza entità,
“Matrimonio” appunto, e collegata con “Uomo” e “Donna”
mediante due relazioni.
Altra mancanza di astrazione (o eccessiva praticità): le relazioni “N a M”. La teoria relazionale non consente di mettere in relazione, in maniera diretta, due tabelle in modo che
N–uple della prima siano collegate a M–uple della seconda.
Per ottenere questo tipo di relazione è necessario creare
una terza tabella (chiamiamola “tabella di relazione”) che
contenga le chiavi primarie delle due tabelle principali. Ma
non c’è motivo per cui il modello logico non debba gestire
pienamente questo tipo di relazione!
In ERwin è possibile definire una relazione “N a M” ma
per ottenere la tabella di relazione nel modello fisico bisogna
necessariamente esplicitare l’entità di relazione anche nel
modello logico. Ultima considerazione sul modello logico.
Creando una relazione di tipo Padre/Figlio, automaticamente la chiave dell’entità padre viene aggiunta alle colonne
dell’entità figlia. Anche questa è una cosa indispensabile
nel modello fisico basato sulla teoria relazionale, ma non è
necessaria a livello logico.
La gestione del DB
ERwin non è utile solo per progettare basi di dati. È di
grande supporto soprattutto per tenere allineato il progetto
originale con le continue modifiche che vengono apportate
in fase d’esercizio. Le funzioni principali che consentono la
gestione del database sono:
G
G
G
G
Schema generation
Reverse engineer
Complete compare
Data browser
Schema generation è un’utility per la generazione del codice
DDL per la creazione e la modifica del database. Consente di
applicare in maniera semplice al database le modifiche apportate al progetto.
Raramente le modifiche in corso d’opera vengono apportate
prima al progetto e poi al database. Molto spesso si modifica
diretta mente il database e poi, appena si ha un po’ di tempo,
si riportano le modifiche sul progetto. Complete compare è
utile alla gestione delle modifiche in corso d’opera. Questa
19
CP 120
prova prodotto
utility fornisce un elenco molto completo e dettagliato delle
differenze esistenti tra un modello ed un database (o tra due
modelli).
Reverse engineer consente di definire automaticamente il
modello partendo da un database già esistente. È utile per
controllare l’evoluzione del DB ma anche, e soprattutto, per
ristrutturare applicazioni esistenti per le quali non si dispone
di un progetto completo.
Data browser è un insieme di report che forniscono informazioni molto utili sia sul modello che sul database effettivo.
La cosa più interessante è che possono essere creati report
su misura utilizzando la funzione Report builder. La funzione
consente di selezionare, mediante un’interfaccia grafica, le
informazioni che si intendono visualizzare nel report.
Molte altre funzioni aiutano nella gestione del database.
Ad esempio il Partitioning wizard che consente di realizzare
in maniera semplice il partizionamento sia verticale (per
colonne) che orizzontale (per righe) delle tabelle di grande
volume. Proprio per la definizione dei volumi è disponibile
l’utility Volumetrics. Questa elabora le informazioni relative
alla struttura ed al numero dei record e degli indici previsti,
ed effettua il calcolo del dimensionamento degli oggetti.
Molto potente, ma un po’ complessa, la funzione che consente di progettare script generici che poi devono diventare
procedure (o trigger) del database. La funzione si basa su
macro generiche predefinite. Una macro non è un insieme di
istruzioni sequenziali (come nei prodotti Office di Microsoft)
ma una stringa che a runtime viene sostituita da un certo
valore (come in C). Ad esempio la macro %TableName può
essere utilizzata per scrivere una generica procedura di cancellazione:
CREATE OR REPLACE PROCEDURE delete%TableName is
Begin
delete %TableName;
end;
Successivamente la procedura generica può essere associata
alla tabella “Autori”. In fase di generazione dalla tabella, sarà
creato anche lo script:
VALUTAZIONE
C’è una gran somiglianza tra ERwin ed il CASE prodotto da
Oracle. Ovviamente Oracle Designer gestisce anche la parte
“Analisi delle Funzioni” che Computer Associates copre con
BPwin, prodotto gemello di ERwin.
La prima assonanza tra i due prodotti è l’impostazione fortemente orientata al disegno “Fisico” più che “Logico” dei dati.
Anche in Designer le relazioni sono viste solo come collegamento tra entità, e quindi prive di attributi propri. La presenza
di uno schema “Logico” e di uno schema “Fisico” paralleli e
molto simili accomuna i due prodotti. Mentre in ERwin, però, i
due schemi sono sempre automaticamente allineati, in Designer per ottenere uno schema “Fisico” bisogna eseguire un
apposito programma che crea degli oggetti separati dai corrispondenti logici. Da quel momento, in Designer, i due modelli
vivono vite separate e devono essere allineati dall’utente.
Quasi tutte le ottime utility di ERwin, di cui abbiamo parlato
nella prova, hanno un omologo in Designer: il generatore di
DDL, la reverse engineer, il generatore di report e così via.
Il fatto che ERwin “strizzi l’occhio” ad Oracle Designer è confermato dalla presenza, nel prodotto di Computer Associates,
di una utility per l’import/export di diagrammi da Designer.
L’import crea un nuovo diagramma leggendo le opportune
informazioni dal repository di Designer.
L’export si occupa di creare un codice PL/SQL basato sull’API e
sulle macro di ERwin. L’API di ERwin è una collezione di procedure e funzioni PL/SQL che devono essere create sul database
dov’è installato il repository di Oracle Designer e che interagiscono con esso direttamente e mediante l’API di Designer.
L’API di Designer è una collezione di package Oracle che consentono di inserire e modificare i dati presenti nel repository
via codice.
Alla versione 4.0, ERwin gestisce il repository di Oracle Designer versione 1.3.2, meglio noto come Designer/2000.
RIQUADRO 1 ERwin ed Oracle Designer
CREATE OR REPLACE PROCEDURE deleteAutori is
Begin
delete Autori;
end;
Le macro disponibili sono moltissime e consentono la
realizzazione (con un po’ di pazienza) di procedure molto
complesse.
Quali database possono essere gestiti con ERwin? La lista è
decisamente lunga, i più noti sono Oracle (versioni 7.3 ed 8 ma
ho utilizzato 9i senza alcun problema), DB2, Informix, SQL Server, Access, ODBC generico e chi più ne ha più ne metta…
Conclusioni
Voto complessivo
Funzionalità
Interfaccia ed usabilità
Prestazioni
Tempestività sul mercato
Prezzo:
a partire da 3.875 USD
inaccettabile
pessimo
insufficiente
soddisfacente
discreto
ottimo
per informazioni:
Computer Associates S.p.A.
Pal. Leonardo - Via F. Sforza, 3
20080 Milano 3 City – Basiglio (MI)
tel. 02-904641
www.ca.com
CP 120
20
CASE in circolazione ce ne sono molti, le funzionalità che
offrono per la fase di progettazione sono grossomodo equivalenti. ERwin offre il meglio di sé nelle relazioni con il database
reale più che nella parte di disegno.
L’unico CASE con cui ERwin comunica, grazie ad una
utility di import/export, è Oracle Designer. I due strumenti
sono effettivamente molto simili (condividono pure alcune
pecche concettuali). Un breve parallelo tra Oracle Designer
ed ERwin è stato realizzato in Riquadro 1.
Volendo dare un giudizio conclusivo possiamo dire che, nel
complesso, lo strumento è ben fatto, semplice e di utilizzo intuitivo. Ha qualche carenza nella parte di disegno logico ma
recupera ampiamente nelle fasi successive del lungo e faticoso
processo di analisi, progettazione, realizzazione e manutenzione di una base dati.
BIBLIOGRAFIA
[1] R. S. Pressman - “Principi di Ingegneria del Software”, McGraw-Hill, 1997
