Progettare un database relazionale

speciale (Mondo) Database
di
Massimo Ruocchio > [email protected]
Progettare un database
relazionale
La definizione della struttura dei dati è
il primo passo da compiere nella realizzazione di un’applicazione basata su
database. Ecco un semplice esempio.
Q
uasi tutte le applicazioni software sviluppate nell’ultimo decennio utilizzano un database relazionale per memorizzare i dati. Per questo, di solito, uno dei primi passi da compiere nella realizzazione di un nuovo sistema informatico è la progettazione del database. In quest’articolo saranno descritti i capisaldi dell’analisi dei dati e delle altre attività di progettazione dei database. Per non restare troppo nel
vago ci faremo accompagnare passo per passo da un esempio, una semplice biblioteca. La prima domanda che ci si
deve porre è la seguente: “Quali dati bisogna gestire?”
FIGURA 1
Schema concettuale dei dati per
l’esempio
Quali dati?
Questa domanda non ha una risposta assoluta. Solo il destinatario finale dell’applicazione, quello che dovrà utilizzarla,
può stabilire quali dati servono e quali no. Dunque bisogna
chiedere all’utente finale, ma ci sono due problemi di fondo:
le informazioni fornite sono spesso imprecise e, quasi sempre, pure incomplete. Tocca all’analista aiutare il suo interlocutore a chiarirsi le idee e spingerlo a non tralasciare dettagli importanti. Ciò può essere fatto richiedendo e proponendo spesso esempi semplici ed enumerazioni complete dei
casi possibili e delle informazioni utili. Nel caso del nostro
esempio, dopo una chiacchierata col bibliotecario sono venu-
RIQUADRO 1
Specifiche utente per la biblioteca
d’esempio
La biblioteca si occupa di dare in prestito libri ai clienti.
La durata del prestito varia da caso a caso e spesso i
libri vengono restituiti dopo il termine previsto. In media
prestiamo circa 10000 volumi l’anno. Abbiamo bisogno
di conservare la storia dei prestiti degli ultimi cinque
anni. I clienti sono registrati in un apposito schedario. A
parte l’indirizzo ed il numero di telefono, abbiamo bisogno di registrare per ogni cliente il numero di un documento di riconoscimento. Attualmente i clienti registrati
sono circa 1000, mediamente questo numero si incrementa di circa 150 unità l’anno. I dati dei clienti non vengono mai rimossi dall’archivio. In biblioteca ci sono circa
10000 opere in varie edizioni, talvolta in lingue diverse.
Spesso di un libro abbiamo più copie. In tutto i libri in
biblioteca sono circa 25000. Ogni anno acquistiamo in
media 250 libri di 100 opere diverse. Dei libri ci interessa conservare la collocazione in biblioteca, l’autore,
l’editore lo stato di conservazione (Ottimo, Sufficiente,
Mediocre, Pessimo), la lingua. Una breve biografia dell’autore ed un abstract dell’opera aiutano il cliente nella
scelta dei volumi da richiedere.
>> 30
te fuori le informazioni contenute in Riquadro 1. Il primo
passo è, dunque, realizzare un documento chiaro e semplice
che riporti ciò che è stato concordato con l’utente. Se il sistema da realizzare ha fini commerciali, è bene che
l’utente/cliente approvi esplicitamente questo documento.
Lo schema concettuale dei dati
Una volta chiarite le informazioni da gestire bisogna realizzare uno schema che descriva i dati a livello “concettuale”. Che
significa? Lo schema deve descrivere i dati a prescindere
dalla tecnologia e dagli strumenti che saranno utilizzati per
archiviarli. Ci disinteressiamo di come sarà realizzata praticamente la base dati. Vogliamo descrivere i dati da trattare,
nient’altro. Per realizzare lo schema concettuale si utilizza di
norma il modello Entità-Relazioni. Questo modello è stato
introdotto da Peter Chen nel 1976 ed ha assunto, negli anni,
un ruolo di assoluto protagonista nella progettazione dei
sistemi informatici. Questa tecnica ha subito negli anni continui affinamenti e miglioramenti fino a giungere ai moderni
“diagrammi delle classi” utilizzati in UML per descrivere le
classi dei sistemi orientati agli oggetti. In quest’articolo introdurremo solo i concetti fondamentali del modello E-R, in
bibliografia ci sono i riferimenti per approfondire l’argomento.
I due elementi fondamentali di un diagramma E-R sono le
entità e le relazioni. Tralasciando la filosofia, possiamo dire
che un’entità è una classe di oggetti (materiali o immateriali) particolarmente rilevanti nella realtà che stiamo analizzando. Nel nostro esempio è sicuramente un’entità il cliente,
inteso come classe di tutti i clienti e non come singolo. Altre
entità sono il libro, l’autore, l’editore. Ogni entità ha delle proprietà, per il cliente si può pensare al nome, al cognome,
all’indirizzo, al documento di riconoscimento, eccetera.
Queste proprietà sono dette attributi delle entità. Le entità
sono in relazione tra loro. Il prestito è una relazione tra cliente e libro. Un cliente richiede uno o più libri ed ogni libro è
prestato ad un cliente. Anche le relazioni possono avere degli
attributi, basti pensare, per il prestito, alla data di inizio, alla
DEV > n. 107 maggio 2003
(Mondo) Database
Progettare un database relazionale
data di prevista riconsegna, alla data di effettiva riconsegna.
Nella versione “classica” del modello E-R, ogni entità è rappresentata da un rettangolo, ogni attributo da un piccolo cerchio collegato mediante una linea all’entità che descrive,
ogni relazione è rappresentata da un rombo. In Figura 1 è
rappresentato lo schema concettuale del nostro esempio.
Della relazione “prestito”, che associa il cliente al libro che
questo richiede, abbiamo già detto. Le altre relazioni sono
“scrittura” (Un libro è scritto da uno o più autori ed ogni autore può scrivere uno o più libri) e “edizione” (un editore pubblica uno o più libri ed un libro è pubblicato da un solo editore). I numeri tra parentesi indicano la cardinalità minima e
massima di ogni verso delle relazioni. Gli attributi neri identificano in maniera univoca l’entità che descrivono: il cliente è
identificato dal suo codice, il libro è identificato dal codice
ISBN e da un progressivo in quanto potrebbero esserci in
biblioteca più libri con lo stesso ISBN. Esistono diversi strumenti che consentono di disegnare i diagrammi E-R. Ogni
strumento utilizza simboli propri, spesso fornendo anche una
versione non “classica” del modello E-R. Per lo schema concettuale del nostro esempio è stato utilizzato Dia, un software open source che consente di disegnare diagrammi di tutti
i tipi. Per lo schema logico (e per lo schema fisico) è stato utilizzato Erwin di Computer Associates [1].
Lo schema logico dei dati
Eccoci al terzo passo da compiere. Abbiamo un documento
che descrive i dati da trattare ed uno schema concettuale.
Il cliente ha approvato, si spera, entrambi. Ora bisogna realizzare uno nuovo schema in cui si applichi lo schema concettuale alla tecnologia che abbiamo deciso di utilizzare. In
questa fase ci interessa sapere che tipo di archiviazione
utilizzeremo (relazionale, gerarchica, in file sequenziali, in
documenti XML, …), non ci interessa ancora sapere quale
database utilizzeremo. Lo schema che dobbiamo realizzare
andrà bene per Oracle, per DB2, SQL Server e per qualunque altro DB relazionale. Per trasformare lo schema concettuale in schema logico, nel caso di modello relazionale,
si possono effettuare due passaggi:
1) una prima traduzione “grossolana” di entità e relazioni in tabelle e chiavi esterne,
2) la normalizzazione dello schema.
Per la prima traduzione si possono seguire le seguenti regole generali che non sono esaustive di tutti i casi che si possono verificare in un diagramma E-R (alcune strutture del
modello E-R non le abbiano neanche menzionate):
• Ogni entità diventa tabella, ad esempio l’entità
Cliente diventa la tabella Clienti
• Ogni attributo di Cliente diventa colonna della tabella
Clienti
• Ogni attributo identificatore diventa chiave univoca
nella tabella
• Ogni relazione dotata di attributi diventa tabella, ad
esempio la relazione Prestito diventa la tabella
Prestiti
• Gli attributi di Prestito diventano colonne di Prestiti
• Sulla tabella Prestiti devono essere aggiunte le chiavi
esterne relative alle tabelle Clienti e Libri
• Le relazioni non provviste di attributi diventano chiavi
esterne, con molta attenzione alle cardinalità massime dei due versi.
Quest’ultima regola va spiegata meglio. Se la relazione è uno
(o zero) a molti, cioè se le cardinalità massime sono uno (o
DEV > n. 107 maggio 2003
zero) ed N, la chiave esterna va messa nella tabella dalla cui
parte c’è la cardinalità uno. Ad esempio consideriamo la relazione “Edizione”. Questa relazione collega libri ed editori con
cardinalità (1,1) dalla parte del libro e (1,N) dalla parte dell’editore (un libro è pubblicato da uno ed un solo editore, un
editore pubblica uno o più libri). Le cardinalità massime sono
dunque uno dalla parte del libro ed N dalla parte dell’editore. La chiave esterna deve essere messa nella tabella dei
libri. Nella tabella dei libri ci sarà la colonna “codice editore”.
Se la relazione è molti a molti, cioè se entrambe le cardinalità massime sono N, c’è bisogno di creare una nuova tabella composta unicamente dalle chiavi esterne delle due tabelle interessate. Ad esempio vediamo il caso della relazione
“Scrittura”. Un autore può scrivere più libri ed un libro può
essere scritto da più autori. Si tratta di una relazione molti a
molti. Non è possibile mettere la colonna “codice autore”
nella tabella dei libri (ci potrebbero essere più autori per lo
stesso libro) e non è possibile mettere la colonna “codice
libro” nella tabella degli autori (ci potrebbero essere più libri
per lo stesso autore). Bisogna creare la tabella Libri_Autori
che è composta dalle due chiavi delle tabelle libri e autori, in
questa tabella vanno archiviate tutte le coppie Libro-Autore.
Se un libro è stato scritto da cinque autori avremo un record
nella tabella Libri che non fa riferimento all’autore, cinque
record nella tabella Autori che non fanno riferimento al libro
e cinque record nella tabella Libri_Autori che associano il
libro agli autori.
Applicando le regole suddette, alla fine della prima traduzione abbiamo individuato le seguenti tabelle.
Clienti (ID_Cliente, Documento, Telefono, Indirizzo,
Cognome, Nome)
Prestiti (ISBN, Progressivo, Data_inizio, ID_Cliente,
Data_Fine, Data_Restituzione, Stato, Commento)
Libri (ISBN, Progressivo, Lingua, Anno, Titolo,
ID_Editore, Stato, Collocazione, Abstract)
Autori (ID_Autore, Nome, Cognome, Biografia)
Editori (ID_Editore, Nome, Indirizzo)
Libri_Autori (ID_Autore, ISBN, Progressivo)
Dove le chiavi delle tabelle sono sottolineate. Questo
schema deve essere raffinato perché presenta ancora
molti difetti. Il processo di raffinamento, detto “normalizzazione” è l’argomento del prossimo paragrafo.
La normalizzazione
La normalizzazione è un processo di trasformazione delle
tabelle che mira ad eliminare la ridondanza dei dati ed altri
sgradevoli fenomeni molto comuni negli schemi relazionali.
Sono state definite molte “forme normali”, alcune delle quali
hanno senso solo nei libri universitari e sono improponibili in
un database reale.
Molti ritengono che uno schema logico sia sufficientemente
raffinato se soddisfa la terza forma normale. Per questo
motivo, e per ragioni di spazio, ci limiteremo a descrivere le
prime tre forme normali.
Uno schema logico è in prima forma normale se è privo di
attributi non atomici. Facciamo un esempio. Volendo registrare in un database relazionale il nome di un padre e dei
suoi figli, potremmo definire la seguente tabella
Padri (CodiceFiscale, Nome, Cognome, NomeFiglio).
Poiché un padre può avere più figli, NomeFiglio è un attributo non atomico. Non è possibile inserire nella tabella
padri più righe relative allo stesso padre ed a figli diversi,
poiché la chiave della tabella è composta del solo Codice
31 <<
speciale (Mondo) Database
Progettare un database relazionale
volta. Le due tabelle individuate sono in seconda forma normale. Ma è possibile ancora migliorare la prima. In effetti il
titolo (il titolo originale) e l’abstract non dipendono dall’edizione del libro e dunque dall’ISBN. Possiamo ancora raffinare il nostro schema come segue:
Opere (ID_Opera, TitoloOriginale, Abstract)
Libri (ISBN, Lingua, Anno, ID_Editore, Titolo, ID_Opera)
Copie (ISBN, Progressivo, Stato, Collocazione)
Solo per chiarezza utilizzeremo il nome “Edizioni” al posto
di “Libri” di qui in avanti. In seguito a queste modifiche
cambiano anche altre tabelle, gli autori sono in relazione
con l’opera e non con il libro/edizione, dunque la tabella
Libri_Autori diventa
Opere_Autori (ID_Opera, ID_Autore).
FIGURA 2
Schema logico dei dati per l’esempio
Fiscale del padre. Per soddisfare la prima forma normale ci
sono due possibilità:
• Soluzione 1) aggiungere la colonna NomeFiglio alla
chiave di Padri:
Padri (CodiceFiscale, Nome, Cognome, NomeFiglio).
In questo modo si potranno inserire più record per i
padri che hanno più figli.
Uno schema logico si dice in terza forma normale se è in
seconda forma normale e non esistono attributi che dipendono transitivamente dalla chiave della propria tabella.
Facciamo un esempio. La seguente tabella contiene dati
anagrafici:
Abbonati (CodiceFiscale, Nome, Cognome, ComuneResidenza,
RegioneResidenza).
La tabella non è in terza forma perché la regione di residenza dipende dalla persona, ma questa dipendenza è transitiva
per mezzo dell’attributo ComuneResidenza. Una volta stabilito il comune, la regione è automaticamente determinata. La
tabella dovrebbe essere divisa nelle due che seguono:
• Soluzione 2) dividere la tabella Padri nelle due tabelle:
Abbonati (CodiceFiscale, Nome, Cognome, ComuneResidenza)
Padri (CodiceFiscale, Nome, Cognome)
Comuni (Comune, Regione).
Figli (CodiceFiscalePadre, NomeFiglio)
Dove un padre con cinque figli avrà un record nella
tabella Padri e cinque record nella tabella Figli. Nella
nostra biblioteca non ci sono attributi multipli, quindi il
nostro schema logico è in prima forma normale.
Uno schema logico è in seconda forma normale se è in
prima forma normale e ogni attributo che non fa parte della
chiave dipende dall’intera chiave e non da un suo sottoinsieme. Nel caso della tabella padri della soluzione 1, in cui
avevamo aggiunto la colonna NomeFiglio alla chiave, gli
attributi Nome e Cognome dipendono solo dal codice fiscale del padre e non dal nome del figlio. La tabella non è in
seconda forma normale. Le tabelle Padri e Figli della
Soluzione 2, invece, sono in seconda forma normale poiché
tutti gli attributi (Nome e Cognome) dipendono dall’intera
chiave della tabella cui appartengono.
Tornando alla nostra biblioteca, guardiamo la tabella Libri.
L’anno di edizione, la lingua, il titolo, l’editore e l’abstract
dipendono solo dall’ISBN. Se abbiamo più copie dello stesso
libro con lo stesso ISBN, gli attributi suddetti non cambieranno di valore. La tabella Libri non è in seconda forma normale. Per portarla in seconda forma normale bisogna dividerla come segue:
Nel nostro schema logico non ci sono dipendenze transitive, quindi possiamo dire di avere terminato il processo di
normalizzazione e di avere uno schema in terza forma normale. In Figura 2 è visualizzato lo schema logico finale del
nostro esempio. Adesso bisogna applicare lo schema logico allo strumento che abbiamo deciso di utilizzare per realizzarlo.
Lo schema fisico dei dati
Alcune scelte progettuali dipendono dallo strumento che si
utilizza per archiviare i dati. Nel nostro esempio utilizzere-
Libri (ISBN, Lingua, Anno, Titolo, ID_Editore, Abstract)
Copie (ISBN, Progressivo, Stato, Collocazione)
Questo per evitare di ripetere la lingua, l’anno di edizione,
il titolo, l’editore e l’abstract per ogni copia del libro.
Queste informazioni possono essere specificate una sola
>> 32
FIGURA 3
Schema fisico dei dati per l’esempio
DEV > n. 107 maggio 2003
(Mondo) Database
Progettare un database relazionale
LISTATO 1
Istruzioni SQL/DDL per la creazione
del database d’esempio
CREATE TABLE Prestiti (
Data_restituzione
Data_Fine
Data_Inizio
Commento
Stato
Progressivo
ISBN
ID_Cliente
DATE NULL,
DATE NOT NULL,
DATE NOT NULL,
VARCHAR2(200) NULL,
VARCHAR2(1) NOT NULL
CHECK (Stato IN (‘A’, ‘C’, ‘R’)),
NUMBER(5) NOT NULL,
VARCHAR2(20) NOT NULL,
NUMBER(8) NOT NULL
);
ALTER TABLE Prestiti
ADD ( PRIMARY KEY (Data_Inizio, ISBN, Progressivo) ) ;
CREATE TABLE Clienti (
Documento
Telefoni
Indirizzo
Cognome
Nome
ID_Cliente
);
VARCHAR2(30) NOT NULL,
VARCHAR2(50) NOT NULL,
VARCHAR2(100) NOT NULL,
VARCHAR2(30) NOT NULL,
VARCHAR2(30) NOT NULL,
NUMBER(8) NOT NULL
ALTER TABLE Clienti
ADD ( PRIMARY KEY (ID_Cliente) ) ;
CREATE TABLE Copie (
Progressivo
stato
Collocazione
ISBN
...segue...
ID_editore
Nome
Indirizzo
NUMBER(5) NOT NULL,
VARCHAR2(100) NOT NULL,
VARCHAR2(200) NULL
);
ALTER TABLE Editori
ADD ( PRIMARY KEY (ID_editore) ) ;
CREATE TABLE Autori (
Bio
Cognome
Nome
ID_AUTORE
);
VARCHAR2(2000) NULL,
VARCHAR2(30) NOT NULL,
VARCHAR2(30) NOT NULL,
NUMBER(5) NOT NULL
ALTER TABLE Autori
ADD ( PRIMARY KEY (ID_AUTORE) ) ;
ALTER TABLE Prestiti
ADD ( FOREIGN KEY (ID_Cliente)
REFERENCES Clienti ) ;
ALTER TABLE Prestiti
ADD ( FOREIGN KEY (ISBN, Progressivo)
REFERENCES Copie ) ;
NUMBER(5) NOT NULL,
VARCHAR2(3) NOT NULL
CHECK (stato IN (‘OTT’, ‘SUF’,
‘MED’, ‘PES’)),
ARCHAR2(100) NOT NULL,
VARCHAR2(20) NOT NULL
);
ALTER TABLE Copie
ADD ( PRIMARY KEY (ISBN, Progressivo) ) ;
CREATE TABLE Edizioni (
Anno
Titolo
ISBN
ID_opera
ID_editore
Codice_lingua
);
LISTATO 1
ALTER TABLE Copie
ADD ( FOREIGN KEY (ISBN)
REFERENCES Edizioni ) ;
ALTER TABLE Edizioni
ADD ( FOREIGN KEY (Codice_lingua)
REFERENCES Lingue ) ;
ALTER TABLE Edizioni
ADD ( FOREIGN KEY (ID_editore)
REFERENCES Editori ) ;
NUMBER(4) NOT NULL,
VARCHAR2(2000) NOT NULL,
VARCHAR2(20) NOT NULL,
NUMBER(5) NOT NULL,
NUMBER(5) NOT NULL,
VARCHAR2(3) NOT NULL
ALTER TABLE Edizioni
ADD ( FOREIGN KEY (ID_opera)
REFERENCES Opere ) ;
ALTER TABLE Opere_Autori
ADD ( FOREIGN KEY (ID_opera)
REFERENCES Opere ) ;
ALTER TABLE Edizioni
ADD ( PRIMARY KEY (ISBN) ) ;
CREATE TABLE Lingue (
Descrizione
Codice_lingua
);
ALTER TABLE Opere_Autori
ADD ( FOREIGN KEY (ID_AUTORE)
REFERENCES Autori ) ;
VARCHAR2(100) NOT NULL,
VARCHAR2(3) NOT NULL
ALTER TABLE Lingue
ADD ( PRIMARY KEY (Codice_lingua) ) ;
CREATE TABLE Opere_Autori (
ID_AUTORE
NUMBER(5) NOT NULL,
ID_opera
NUMBER(5) NOT NULL
);
ALTER TABLE Opere_Autori
ADD ( PRIMARY KEY (ID_AUTORE, ID_opera) ) ;
CREATE TABLE Opere (
Titolo
ID_opera
Abstract
);
VARCHAR2(2000) NOT NULL,
NUMBER(5) NOT NULL,
VARCHAR2(2000) NULL
ALTER TABLE Opere
ADD ( PRIMARY KEY (ID_opera) ) ;
CREATE TABLE Editori (
DEV > n. 107 maggio 2003
...continua...
mo Oracle, uno dei database commerciali più diffusi. Per
completare la progettazione del database bisogna compiere molte altre attività. Nel seguito di questo paragrafo si
accenna rapidamente ad alcune di esse, che si possono
approfondire in altri articoli di questo speciale oppure consultando la bibliografia ed i riferimenti.
Prima di tutto bisogna scegliere i tipi di dato da utilizzare
per le colonne (gli attributi) delle tabelle, dopo averne stimato attentamente le dimensioni. In Figura 3 è rappresentato lo schema fisico della nostra biblioteca. L’unica differenza significativa rispetto allo schema logico è l’indicazione dei tipi di dato. Alcune ulteriori attività di progettazione
possono essere, in questo contesto, solo menzionate:
• Stimare il volume dei dati da gestire tabella per
tabella. Da questa stima segue il dimensionamento
delle stesse tabelle ma anche il numero e la dimensione dei tablespace (insiemi logici di più oggetti di
database) e dei datafile (i file di sistema che contengono effettivamente i dati).
33 <<
speciale (Mondo) Database
Progettare un database relazionale
• Scegliere gli indici da creare, ricordandosi che un
indice inutile danneggia le prestazioni di un database almeno quanto un indice utile le incrementa.
• Prevedere eventuali progressivi automatici da utilizzare per valorizzare le chiavi delle tabelle.
• Prevedere eventuali viste sui dati che semplifichino
l’accesso al database delle applicazioni.
• Prevedere i domini da applicare a quei campi che possono assumere solo un ristretto numero di valori.
• Prevedere eventuali meccanismi di replica dei dati
realizzabili, ad esempio, mediante snapshot.
• Partecipare all’organizzazione del sistema di alta
affidabilità, se il database deve essere disponibile
24 ore al giorno per sette giorni alla settimana.
Bibliografia
[1] M. Ruocchio – “Erwin 4.0”, Computer Programming nr.
120, 2003
[2] R. S. Pressman - “Principi di Ingegneria del Software”,
McGraw-Hill, 1997
[3] P. Chen – “The Entity Relationship Model - Toward A
Unified View of Data”, ACM Transactions on Database
Systems, Vol. 1, No. 1, pp. 9-36, 1976
[4] E.F. Codd – “A relational model of data for large shared
data banks”, Communications of the ACM, Vol. 13, No.
6, 1970
[5] C.J. Date – “An introduction to database systems, 7th
Edition”, Addison Wesley, 2000
Riferimenti
Fatto tutto ciò si può passare alla realizzazione della base
dati, lo script di creazione della nostra biblioteca è in
Listato 1.
Conclusioni
La progettazione di un database è un processo lungo e
molto delicato. Mettere a posto un errore di progettazione
quando l’intero sistema è già stato completato può avere
un impatto pesantissimo. Bisogna quindi fare ricorso a
tutte le armi di cui si dispone per cercare di ridurre al minimo gli interventi successivi.
La risorsa più impor tante a disposizione del progettista è
sicuramente l’utente del database. È l’unico che sa esattamente cosa gli ser ve, anche se spesso deve essere guidato nella ricerca e nella formalizzazione dei requisiti.
[6] http://www.oracle.com (Home page di Oracle)
[7] http://www3.ca.com/Solutions/Product.asp?ID=260
(Erwin)
[8] http://www.lysator.liu.se/~alla/dia/ (Dia)
[9] http://www.peterchen.com/ (Home page di Peter Chen)
[10] http://bit.csc.lsu.edu/~chen/pdf/erd.pdf (L’articolo
di Chen)
[11] http://www.css.tayloru.edu/~sbrandle/310/codd
1970.pdf (L’articolo di Codd)
Massimo Ruocchio
È laureato in matematica ed è cer tificato “Oracle
Application Developer” ed “XML Engineer”. Si occupa di
analisi, progettazione e sviluppo di applicazioni software.
CHI E’ CAUSA
DEL SUO MAL...
a cura di Luigi Morelli > [email protected]
Horizon
Non esistono sistemi perfetti né assolutamente sicuri. Ma chi vende ed utilizza
sistemi che si mostrano lesivi persino nei propri confronti come può definirsi?
>> 34
Ci risiamo.
Lo scorso gennaio decine di migliaia di server sono rimasti bloccati dall’ennesimo
verme informatico; stavolta a consentire l’infezione è stato un buco nella sicurezza del
prodotto Microsoft SQL Server, un buco la
cui patch era stata rilasciata sin dallo scorso giugno, secondo fonti Microsoft. “Peggio
per coloro che non hanno installato la patch
a tempo debito” è stata la risposta dei PR
del gigante di Redmond. Ricordiamo infatti
che Microsoft aveva fatto della sicurezza dei
propri sistemi un punto d’onore, dichiarazione suffragata dallo stesso Bill Gates rilasciando un e-mail circolare diretta a ciascun
membro della propria azienda informatica.
Tuttavia ciò non è apparso sufficiente a
Russ Cooper, della TruSecure Corp. che
riguardo alle affermazioni Microsoft ha
dichiarato recisamente: “Se l’affidabilità dei
servizi informatici meritava lo scorso anno
un D-, quest’anno sono precipitati ad F
(insufficienza piena)”. Tanto per iniziare,
prendiamo in esame l’assistenza Microsoft
relativa alle patch da installare sui propri server: il messaggio più descrittivo e lungo risulta essere “mantenete il vostro sistema
aggiornato con le patch” secondo il Chief
Security Officer Microsoft Scott Charney. Ma
la filosofia del “tappabuchi” contiene delle
inefficienze di fondo, e tende comunque a
mantenere vulnerabile l’azienda che la utilizza, continua Cooper. Ad esempio, la stessa
Microsoft non ha seguito le proprie istruzioni, dal momento che alcuni quadri esecutivi
hanno confermato di essere rimasti colpiti
dal verme nella propria rete interna.
“Microsoft è risultata del tutto inerme
(verso Slammer). Sono occorsi ben due giorni per eliminarne ogni traccia dalla rete interna” ha spiegato Bruce Schneier, chief technology officer della Counterpane Internet
Security, un service provider che si occupa di
network monitoring, ed esperto di crittografia. Mike Nash, corporate vice president dell’unità d’affari sicurezza di Microsoft, ha
ammesso che “Avremmo dovuto fare un
lavoro migliore” nel proteggere la rete interna dell’azienda. In questo modo pare che
siano venute alla luce le mille piccole e
stressanti inefficienze alle quali vanno incontro i clienti di Redmond; chissà che questo
mettersi nei panni dell’utente permetta a
tutti noi di usufruire di migliori servizi nel
futuro.
Certo, si potrà dire: “Prevenire è sempre
meglio che curare”. E invece no. Russ
Cooper, nell’ambito dell’analisi svolta, si è
reso conto di un altro passo falso compiuto
da Microsoft nello spinoso ambito delle
patch. Ad ottobre infatti Microsoft aveva rilasciato un correttivo per un diverso problema
relativo a SQL Server che, qualora installato
secondo le istruzioni fornite, avrebbe praticamente reso nuovamente vulnerabili i sistemi che avevano installato a suo tempo la fix
di giugno contro il buco poi utilizzato da SQL
Slammer. Come dire: “Se segui le istruzioni
ti proteggi dal buco di ottobre ma riapri quello di giugno”.
Fantascienza? Sarebbe bello credervi, ma la
storia è stata raccontata con dovizia di particolari (e di relativi nomi) dalla stessa CNN.
Certo, se detieni la maggioranza assoluta
del mercato dei Personal Computer nel
mondo sei sotto i riflettori ed ogni tuo più piccolo passo falso viene amplificato dalla fama
che riveste il tuo nome, tuttavia… Tuttavia
continuo a ripetere che secondo me è stato
un errore proporre una campagna commerciale basata sul computer facile da utilizzare:
oggi tutti si sentono (falsamente) capaci di
padroneggiarne le configurazioni grazie ad
icone, cartoni animati, suoni e grafica assolutamente inutile grazie all’interfaccia grafica
“semplice ed intuitiva”. Ma la sicurezza è un
valore ben più importante per un’azienda, e
non è più possibile affidarla a chi ha cercato
di rendere il computer semplicemente un
buffo giocattolo facile da utilizzare.
DEV > n. 107 maggio 2003