Sei sulla pagina 1di 36

LINGUAGGI PER LA MODELLAZIONE DEI DATI AZIENDALI

Carlo Batini, Daniele Tatti

1. Introduzione alla fase di analisi dati e funzioni


Nel ciclo di vita di un sistema informativo, la fase di analisi ha lo scopo di descrivere in
maniera formale ed esente da ambiguità (per quanto possibile) le specifiche del sistema,
intendendo per specifiche del sistema l’insieme dei servizi che gli utenti del sistema
informativo richiedono ad esso.

Esempio
Gli utenti di un sistema informativo che fornisca servizi di posta elettronica richiedono
di poter spedire messaggi a qualunque destinazione, specificando l’indirizzo finale in
modo semplice e simbolico, avendo la possibilità di allegare file con diverso formato,
potendo ottenere una ricevuta di ritorno, avendo la sicurezza che il messaggio non è letto
se non dal ricevente, ecc.

Esempio
Gli utenti di un sistema di prenotazione analisi cliniche hanno l’esigenza di disporre di
una prenotazione nel più breve tempo possibile, eventualmente con servizio presso
l’abitazione, su un insieme di analisi che può richiedere diverse tipologie di prelievi, con
diverse modalità di tariffazione a seconda del tipo di assistenza di cui dispongono, ecc.

L'analisi coinvolge usualmente tre diverse caratteristiche del sistema informativo,


riguardanti rispettivamente i dati oggetto del sistema, le funzioni che devono esse svolte
dal sistema, usualmente mediante elaborazioni di varia natura, le risorse tecnologiche
utilizzate per realizzare tali funzioni.

Più precisamente:
• i dati riguardano tutte le tipologie di informazioni codificate e strutturate utilizzate
dalle funzioni di elaborazione e memorizzate temporaneamente o permanentemente
nel sistema informativo. Nel sistema di posta elettronica di cui all’esempio 1
tipologie significative di dati riguardano gli indirizzi degli utenti, i siti ove sono
allocate le caselle degli utenti, diverse caratteristiche degli utenti, quali l’istituzione
cui appartengono, il client associato all’utente, il profilo, le modalità di accounting,
ecc.
• le funzioni riguardano tutte le tipologie di elaborazioni, interrogazioni, acquisizioni,
stampe o archiviazioni, trasferimenti di informazioni disponibili nel sistema per gli

1
utenti. Nel sistema di posta elettronica le tipologie di funzioni riguardano la
composizione, l’invio, la lettura e la stampa di un messaggio, la selezione,
l’inserimento, l’apertura e il salvataggio di un allegato, la consultazione e la
gestione di una rubrica di indirizzi di posta, e così via;
• le risorse tecnologiche sono i sistemi di elaborazione, memo rizzazione,
trasmissione, di ingresso uscita, che devono essere acquisiti installati e gestiti per
rendere il sistema funzionante. Nel sistema di posta elettronica. Le risorse sono i
client associati agli utenti, i server (es. il domain name server, le reti locali, i
collegamenti con reti geografiche, ecc.

In genere, la fase di analisi viene associata alle prime due tipologie di risorse, ma
abbiamo citato anche le risorse tecnologiche per completezza, essendo un qualunque
sistema informativo associabile alle tre risorse costituite dai dati, dalle funzioni, e dalle
tecnologie informatiche.

Dati e funzioni devono essere specificati in questa fase del ciclo di vita, perché senza una
qualche forma di specifica non è possibile procedere alle fasi successive. Possiamo dire
che l’oggetto fondamentale della attività di analisi è proprio quello di fornire una
specifica dei dati e delle funzioni, a partire da una descrizione usualmente informale
delle esigenze degli utenti, descrizione che chiameremo requisiti degli utenti. I requisiti
degli utenti sono usualmente espressi come esito di interviste, e sono quasi sempre
espressi in linguaggio naturale orale o scritto. Anche la specifica dati funzioni può
essere fornita in linguaggio naturale scritto, ovvero a voce, ovvero può semplicemente,
per piccoli sistemi, essere definita "nella testa" del singolo analista. Questi modi di
descrivere la specifica sono da evitare perché non sarà più possibile (o sarà molto
complicato e fonte di contenziosi) successivamente verificare in fase di test o collaudo in
che misura il sistema operante rispetta le specifiche iniziali.

Specificare in modo non ambiguo dati e funzioni costituenti un sistema informativo può
farsi:
• con un prototipo, cioè con un sistema funzionante, realizzato con ridotto numero di
risorse ed in tempi brevi, che in genere non rispetta i livelli di qualità legati alla
efficienza e alla robustezza, e che invece "in piccolo" realizza tutte le funzionalità
del sistema, su tutte le tipologie dei dati.
• con un modello formale di specifica, cioè mediante la loro descrizione in termini di
un insieme di strutture di rappresentazione dei dati e delle funzioni, strutture di
rappresentazione usualmente descritte in un linguaggio dotato di una sintassi e
semantica formale, che nel loro insieme sono chiamate modello. Le descrizioni
formali dei dati e delle funzioni nel modello scelto sono chiamate schema dei dati e
schema delle funzioni. Uno schema dei e uno schema delle funzioni sono perciò
una descrizione formale dei dati e delle funzioni di interesse in un particolare
sistema informativo, definite a partire dai requisiti degli utenti.

Quando le specifiche sono descritte per mezzo di un modello formale, la scelta del
modello è importante anche per scegliere le modalità o fasi con cui condurre la analisi.

2
In particolare, è possibile scegliere un unico modello per descrivere dati e funzioni, cioè
un modello che abbia al suo interno strutture di rappresentazione che permettano di
descrivere sia le proprietà statiche (ciò che abbiamo chiamato i dati) delle risorse
informative gestite dal sistema informativo, sia le loro proprietà dinamiche o
comportamentali (le funzioni), ovvero due modelli distinti, uno per i dati e uno per le
funzioni. A seconda della scelta, sarà diverso il percorso o metodo con cui condurre la
analisi, e il suo prodotto finale.

Per quanto riguarda il prodotto finale della analisi, nel caso di due modelli diversi per i
dati e per le funzioni, si arriverà a produrre due schemi distinti, quelli che abbiamo
appunto chiamato schema dei dati e schema delle funzioni. Nel caso di un unico
modello, si produrrà evidentemente uno schema complessivo.

Per quanto riguarda il metodo, in entrambi i casi sarà necessario che le specifiche dei
dati e delle funzioni rispettino una imp ortante proprietà chiamata completezza delle
specifiche. Le specifiche sono dette complete quando ogni requisito sui dati descritto
nelle specifiche dati ha corrispondentemente rappresentati nelle specifiche funzioni tutti i
requisiti funzionali ad esso logicamente correlati, e viceversa. In altro parole, non può
accadere che vi sia una funzione per la quale non sono rappresentati i dati da essa
utilizzati, e viceversa. Per arrivare a produrre specifiche dati e funzioni complete sarà
necessario seguire opportune strategie, nei due contesti che abbiamo delineato. Ad
esempio nel caso si utilizzino due modelli si potrà seguire la strategia evidenziata in
figura 1.

Requisiti

PRIMO

SCHEMA DATI

SECONDO PRIMO

SCHEMA DATI
SCHEMA FUNZIONI

TERZO SECONDO

SCHEMA DATI SCHEMA FUNZIONI

SCHEMA DATI SCHEMA FUNZIONI

FINALE FINALE

Figura 1 - Strategia per l’analisi dati funzioni nel caso di utilizzo di due modelli distinti

3
2. L’analisi dei dati
In questo contributo presenteremo un modello per la descrizione di sistemi informativi
nella fase di analisi dei dati. Prima di parlare del modello, e del suo utilizzo,
introdurremo alcun i concetti preliminari utili nel contesto dei sistemi informativi, quali
archivio e base di dati.

2.1. Archivi e basi di dati


La parola archivio è utilizzata in informatica ad indicare un insieme di dati aventi tutti la
stessa struttura, chiamati spesso record, ognuno strutturato a sua volta in un insieme di
campi elementari caratterizzati da un particolare valore. Ad esempio in un archivio
anagrafico i record sono gli insiemi di dati relativi alle singole persone, i campi sono il
nome, il cognome, il luogo e data di nascita, l’indirizzo, il CAP e il luogo di residenza. I
valori che possono essere assunti dai campi appartengono a domini, quali gli interi, le
stringhe di caratteri, i booleani.

Le informazioni rappresentate in un archivio possono essere organizzate in molti modi:


ad esempio, ordinandole per cognome, ovvero per data di nascita. Si suole perciò
distinguere negli archivi un aspetto che chiameremo concettuale, che descrive la natura
delle informazioni rappresentate, ed un aspetto fisico, che descrive le modalità di
rappresentazione. Secondo un' altra coordinata, possiamo distinguere in un archivio un
aspetto intensionale, che riguarda il significato delle informazioni rappresentate
nell’archivio, indipendentemente dal loro valore (ad es. l’archivio PERSONE, l’archivio
FORNITORI, il campo DATA-DI-NASCITA, il campo COGNOME), ed un aspetto
estensionale, costituito dai valori rappresentati ('PAOLO’, 'ROMA, '7 giugno 1949',
'00134'). La parte intensionale non cambia nel tempo, mentre la parte estensionale è
soggetta a continui aggiornamenti, aggiunte, cancellazioni di informazioni.

Esempio
Nella nostra vita quotidiana accade spesso che le informazioni da noi gestite siano
frammentate in diversi 'contenitori': agende, bollette, calendari, fogli sparsi. Ed è proprio
tale frammentazione che pone talvolta vari problemi nella gestione delle informazioni.
Se ad esempio teniamo due agende, una a casa e una al posto di lavoro, la variazione di
un numero di telefono ci obbligherà a due diversi aggiornamenti.

Un analogo problema è sorto per le Amministrazioni statali, le imprese manifatturiere e


produttrici di servizi, gli enti di credito, che hanno progressivamente utilizzato i sistemi
informatici per automatizzare archivi di varia natura, iniziando dai dati operativi (ad
esempio, i dati necessari alla produzione di un certificato richiesto da un cittadino in una
anagrafe comunale) fino agli archivi utilizzati per esigenze di previsione e
pianificazione (ad esempio, i dati sulle nascite e sulle morti in un dato intervallo di anni,
necessari per prevedere lo sviluppo edilizio e le esigenze di istruzione).

La tecnologia disponibile ha incoraggiato inizialmente una automazione che possiamo


definire "a pelle di leopardo": ogni volta che nasceva una nuova esigenza, veniva
realizzata una nuova applicazione (un insieme di programmi), e creati uno o più archivi

4
utilizzati dalla applicazione. In questo modo (vedi un esempio in figura 2: il simbolo di
cilindro è tradizionalmente utilizzato per rappresentare archivi) accade che le stesse
informazioni possano essere rappresentate in diversi archivi, dando luogo a ridondanza
di rappresentazione, rischi di incoerenze nelle diverse rappresentazioni della stessa
informazione, e scarsa trasparenza da parte di un utente nella possibilità di utilizzare
informazione prodotta da altri, essendo tale informazione sotto il diretto controllo del
settore organizzativo che la ha originata.

Matricola
Cognome
UFFICIO GESTIONE
Nome
DEL PERSONALE Titolo studio
Livello
Stato civile
Valutazioni

Ufficio
UFFICIO
Cognome
ORGANIZZAZIONE Nome
Matricola
Livello
Mansione

Livello
Matricola
UFFICIO Cognome
AMMINISTRAZIONE Nome
Assegni
DEL PERSONALE Premio
Mese
Ore
Figura 2 - Struttura di un insieme di archivi tradizionali

Le basi di dati nascono proprio per dare una risposta a questi problemi. Una base di dati
(vedi anche figura 3) può essere definita come un insieme di archivi in cui ogni
informazione di interesse viene rappresentata una sola volta, e acceduta da un insieme di
applicazioni secondo criteri di riservatezza che sono stabiliti in modo centralizzato. La
base di dati è dunque anzitutto un concetto organizzativo, prima ancora che tecnologico:
integrare le informazioni aziendali in un unico contenitore logico significa aumentare la
possibilità di circolazione delle informazioni e quindi integrare maggiormente la stessa
organizzazione. Peraltro, è possibile fare questo in modo efficace solo disponendo di
opportuni sistemi software di gestione, detti sistemi di gestione di basi di dati, o DBMS,
Data Base Management System, sviluppati negli anni '70 ed '80, e ormai diventati di
uso comune. Un sistema di gestione di basi di dati permette ai vari utenti di utilizzare in
modo coordinato i dati memorizzati, per mezzo di linguaggi di manipolazione ed
interrogazione efficienti e facili da utilizzare.

5
APPLICAZIONE 1

APPLICAZIONE 1

APPLICAZIONE 1

Figura 3 - Struttura di una base di dati

Anche in una base di dati, come in un insieme di archivi tradizionali, possiamo


distinguere un aspetto intensionale, detto anche schema logico (o schema) della base di
dati, ed un aspetto estensionale, costituito dai dati memorizzati. I sistemi software di
gestione di basi di dati utilizzano per descrivere lo schema logico un insieme di modelli
chiamati usualmente modelli logici: i più utilizzati sono stati nel passato il modello
gerarchico, il modello reticolare e oggi il modello relazionale. In figura 4 riportiamo
una stessa realtà di interesse rappresentata per mezzo dei modelli gerarchico e
relazionale; la realtà che vogliamo rappresentare è quella delle librerie, che vendono
libri, scritti da vari autori. I due modelli descrivono tale realtà nel seguente modo:
1. nel modello gerarchico si distinguono due tipi di strutture di rappresentazione, i
record e i legami logici tra record. I record hanno il significato già introdotto
all’inizio del capitolo, sono cioè insiemi di campi; i legami logici descrivono le
corrispondenze definite tra record. Nel nostro esempio, si hanno tre record,
LIBRERIA, LIBRO, AUTORE, e due legami, uno tra LIBRERIA e LIBRO, che
descrive per ogni libreria, i libri venduti, e l’altro tra LIBRO e AUTORE, che
descrive per ogni libro, i suoi autori.
2. nel modello relazionale le informazioni di interesse sono raggruppate in relazioni,
rappresentate in modo naturale da tabelle. Ogni relazione (LIBRERIA, LIBRO,
ecc.) è costituita da un insieme di attributi, che costituiscono i dati elementari
rappresentabili (nel caso di LIBRERIA, PARTITA-IVA, NOME, INDIRIZZO). Le
relazioni sono utilizzate uniformemente nel modello per rappresentare entrambe le
strutture del modello gerarchico, i record e i legami logici. Ad esempio il record
LIBRERIA del modello gerarchico è rappresentato con una relazione LIBRERIA
nel modello relazionale (e gli attributi corris pondono esattamente ai campi), e
l’insieme tra i record LIBRERIA e LIBRO è rappresentato con una seconda
relazione DISPONIBILITÀ, in cui, come si vede, la corrispondenza tra ogni libreria

6
ed i libri che presso di essa sono disponibili è rappresentata riportando nella
relazione l’attributo NOME-LIBRERIA (che corrisponde a NOME nella relazione
LIBRERIA) e l’attributo CODICE-LIBRO (che corrisponde a CODICE-L nella
relazione LIBRO).

LIBRERIA LIBRERIA INDIRIZZO CITTA'


PARTITA-IVA NOME

PARTITA-IVA NOME INDIRIZZO CITTA'


LIBRO CODICE-L TITOLO EDITORE PAGINE

LIBRO
AUTORE CODICE NOME COGNOME NAZIONALITA' SESSO
NUMERO
CODICE-L TITOLO EDITORE
COPIE PAGINE

NOME- CODICE NUMERO


COPIE
DISPONIBILITA' LIBRERIA LIBRO
AUTORE

DATA
CODICE-A NOME COGNOME NASCITA SESSO SCRITTO
TITOLO COGNOME

MODELLO GERARCHICO MODELLO RELAZIONALE

Figura 4 - Librerie e libri descritti nei modelli gerarchico e relazionale

2.2. I modelli concettuali e le astrazioni


In fase di analisi, per rappresentare le specifiche, si preferisce non utilizzare i modelli
logici, in quanto troppo vicini al modo in cui i dati sono rappresentati nel sistema
informatico, ed in particolare nel sistema di gestione della base di dati. Le specifiche
vengono piuttosto descritte per mezzo di un modello ancora astratto, formale,
indipendente dal modello scelto per la realizzazione tecnologica, producendo in questo
modo uno schema concettuale dei dati; nella fase di progettazione, lo schema
concettuale viene tradotto in termini dello schema logico, rappresentazione dei dati
espressa nel modello logico.

In questa sezione esamineremo il meccanismo fondamentale di rappresentazione dei


modelli concettuali, le astrazioni; nella prossima sezione esamineremo un particolare
modello concettuale, il modello Entità Relazione.

I modelli concettuali non sono rivolti tanto a descrivere la realizzazione informatica,


quanto piuttosto la realtà di interesse; sono, per cosi' dire, modelli rivolti verso la realtà,
più che verso il sistema di gestione di basi di dati. Per essere in grado di rappresentare
classi di dati in modo semplice, comprensibile, indipendente dalla tecnologia
informatica, un modello concettuale deve essere in grado di descrivere astrazioni.
Intendiamo per astrazione un procedimento mentale che permette di evidenziare alcune
proprietà, ritenute significative, degli oggetti osservati, escludendone altre giudicate
non rilevanti. Ogni processo di astrazione è applicato ad un insieme di oggetti ed il suo
risultato è la definizione di un nuovo oggetto, che, come spesso si dice, si trova ad un
livello di astrazione superiore rispetto agli altri.

7
Come esempio di astrazione (vedi Figura 5.a) consideriamo il processo mediante il
quale a partire dalle singole persone e considerando le proprietà che le accomunano, si
giunge al concetto di persona, cioè alla definizione di una classe, che rappresenta un
insieme di oggetti (le singole persone). Il precedente tipo di astrazione, presente in tutti i
modelli concettuali, è chiamato astrazione di classificazione. Altre due astrazioni
usualmente considerate sono:
• la aggregazione, mediante la quale si può giungere alla definizione di una classe
come astrazione di un insieme di parti componenti o proprietà. Ad esempio,
definite le classi NOME, COGNOME, ETÀ, SESSO, STIPENDIO, una loro
astrazione di aggregazione è la classe PERSONA (vedi Figura 5.b).
• la generalizzazione, mediante la quale si può giungere alla definizione di una
classe come unione di un insieme di classi, ognuna delle quali è contenuta della
classe data. Cosi', ad esempio, definite le classi UOMO e DONNA, possiamo
definire come loro generalizzazione la classe PERSONA (vedi Figura 5.c).

Corrispondentemente, possiamo definire i procedimenti inversi alle precedenti


astrazioni, che permettono di raffinare concetti in termini di concetti più elementari. Ad
esempio, tra essi, possiamo definire la specializzazione come il procedimento che
permette di definire oggetti a partire da classi.

PERSONA
PERSONA
PERSONA

Classificazione Aggregazione
Generalizzazione

NOME COGNOMEETA' SESSO UOMO DONNA

Astrazione di classificazione Astrazione di aggregazione Astrazione di generalizzazione

(a) b) (c)

Figura 5 - Le astrazioni utilizzate nei modelli concettuali

Come si vede, si può arrivare ad uno stesso concetto (quello di PERSONA), per mezzo
di tre procedimenti di astrazione diversi, ognuno dei quali, cioè, utilizza una diversa
astrazione. Si può anche osservare che ognuna delle tre astrazioni coglie un aspetto della
realtà che non può essere rappresentato per mezzo delle altre due.

2.3. Il modello Entità Relazione


In questa sezione descriviamo un particolare modello concettuale, che adotta in certa
misura le astrazioni descritte nella sezione precedente. Una caratteristica interessante del
modello è la adozione per i concetti di una rappresentazione grafica, che riportiamo in
Figura 6.

8
STRUTTURA DI CLASSIFICAZIONE SIMBOLO

ENTITA' nome

RELAZIONE nome

ATTRIBUTO
nome
SEMPLICE

ATTRIBUTO
nome
AGGREGATO nome nome

SOTTOINSIEME

GENERALIZZAZIONE

Figura 6 - Rappresentazione grafica dei concetti nel modello Entità Relazione

Nel modello sono definiti cinque tipi di strutture di rappresentazione: entità, relazioni,
attributi, sottoinsiemi, generalizzazioni. Sono anche definibili alcuni vincoli di integrità,
che rappresentano proprietà esprimibili sui concetti presenti nello schema. Nel seguito
esamineremo un particolare tipo di vincolo di integrità, le cardinalità.

Entità
Le entità corrispondono a classi di oggetti del mondo reale (oggetti che chiameremo in
seguito istanze della entità) che hanno proprietà omogenee ai fini della applicazione. Tra
queste le proprietà elementari (cioè non strutturabili in proprietà più atomiche) sono
dette attributi semplici. A un attributo semplice è associato un insieme di valori, detto
anche dominio, che rappresentano l’insieme dei valori elementari che l’attributo può
assumere. Cosi', ad esempio, PERSONA è una entità tipica di uno schema anagrafico, e
NOME, COGNOME, ETÀ, SESSO, sono proprietà elementari che noi siamo interessati

9
a descrivere di ogni persona, e quindi sono nel modello attributi della entità PERSONA;
la entità può quindi vedersi come astrazione di classificazione delle singole persone e
come astrazione di aggregazione delle quattro proprietà NOME, COGNOME, ETÀ,
SESSO. Accanto agli attributi semplici è comodo poter definire attributi composti, che
costituiscono aggregazioni di attributi. Ad esempio DATA può vedersi come attributo
composto dagli attributi GIORNO, MESE, ANNO.

Relazioni
Le relazioni corrispondono a classi di fatti del mondo reale che sono significativi ai fini
della applicazione; tali fatti mettono in relazione istanze di due o più entità. Ad esempio,
in un censimento della popolazione possiamo essere interessati ad esprimere la relazione
tra le persone e le città in cui sono nati, e chiamare tale relazione È-NATO; tale
relazione può vedersi come astrazione di aggregazione applicata alle due entità
PERSONA e CITTÀ. Accanto ad essa, possiamo essere interessati ad altre relazioni
definite sulle stesse entità: ad esempio la relazione tra la persona e il luogo di residenza
(relazione RISIEDE), la relazione tra persona e luoghi in cui ha avuto residenza (HA-
RISIEDUTO). Mostriamo lo schema costituito dalle tre relazioni e le due entità in
Figura 3.9.
Ancora riguardo alle relazioni, è bene osservare che accanto a relazioni definite tra due
entità, come tutte le precedenti, ci possono essere relazioni definite su più di due entità.
Un esempio è la relazione FORNITA, tra le entità FORNITORE, PARTE,
PRODOTTO. Una parte può essere fornita da diversi fornitori, e per diversi prodotti. Se
vogliamo cogliere la situazione più generale possibile, dobbiamo rappresentare questo
tipo di fatti per mezzo di terne di informazioni (un fornitore, una parte, un prodotto), e
dunque, nello schema, per mezzo di una relazione tra tre entità. In questo caso, la
relazione ha un attributo, che rappresenta la generica QUANTITÀ che un fornitore
fornisce per una certa parte e per un certo prodotto.

Esempio
Mostriamo alcuni esempi di schemi concettuali. Lo schema di Figura 7 rappresenta la
realtà informativa di un campionato di calcio.

10
GIRONE
PARTITA GIORNATA
NUMERO
GIORNO
DATA MESE
ANNO

TRA
GIOCA_IN_CASA

NOME
SQUADRA CITTA'
ALLENATORE

GIOCA
IN

NOME
GIOCATORE COGNOME
RUOLO
GIORNO
DATA
NASCITA MESE
ANNO

Fig. 3.10: Schema concettuale di un campionato di calcio


Figura 7 - Lo schema concettuale di un campionato di calcio

Nello schema compaiono:


1. La entità SQUADRA rappresenta l’insieme delle squadre che partecipano al
campionato. Delle squadre vogliamo conoscere il NOME (ad esempio Juventus,
Roma, Milan), la CITTÀ (nei tre casi precedenti Torino, Roma, Milano), ed il
COGNOME dell’allenatore.
2. La entità GIOCATORE rappresenta i giocatori che giocano nelle squadre (in tutte le
squadre). Per ogni giocatore vogliamo ricordare il NOME, il COGNOME, la
DATA-DI-NASCITA (attributo composto dagli attributi GIORNO, MESE, ANNO)
ed il RUOLO che ricopre nella squadra. Riguardo al RUOLO, facciamo per il
momento la ipotesi che ogni giocatore abbia un unico ruolo, sempre fisso nel
tempo. Facciamo anche la ipotesi che anche l’insieme dei ruoli sia fisso nel tempo

11
(ad es. Portiere, Terzino sinistro, Ala destra, ecc.), ed in tutte le squadre si adottino
gli stessi ruoli.
3. La entità PARTITA rappresenta l’insieme delle partite svolte nel campionato (ad
esempio ROMA - MILAN della seconda giornata del girone di ritorno, JUVENTUS
- VERONA della settima giornata del girone di andata, ecc.). Di ogni partita si
vuole ricordare il GIRONE e la GIORNATA in cui si è svolta, la DATA (anche in
questo caso distinta in GIORNO, MESE ed ANNO), ed il NUMERO della partita
nell’ambito della giornata (ad esempio prima partita, seconda partita, ecc.).

Accanto alle precedenti entità sono definite nello schema le seguenti relazioni:
1. GIOCA-IN tra le entità GIOCATORE e SQUADRA, che rappresenta per ogni
giocatore la squadra in cui gioca, ovvero, simmetricamente, per ogni squadra
l’insieme dei giocatori che giocano nella squadra.
2. TRA, definita tra le due entità SQUADRA e PARTITA, che rappresenta per ogni
partita le squadre coinvolte (ad es. nella partita ROMA - MILAN sono coinvolte le
squadre ROMA e MILAN). La relazione TRA ha un attributo, chiamato GIOCA-
IN-CASA, che per ognuna delle due squadre coinvolte nella partita dice se la
squadra gioca o meno in casa. Il dominio di questo attributo è formato dai due
valori [SI, NO]. È importante convincersi che l’attributo GIOCA-IN-CASA è una
proprietà della relazione TRA, e non della entità PARTITA o della entità
SQUADRA. Infatti per assegnargli un valore noi dobbiamo conoscere la partita e la
squadra cui si riferisce: è perciò una proprietà della relazione tra le due entità.

Generalizzazioni
Le Generalizzazioni mettono in relazione un insieme di entità (dette nel seguito entità
figlie) con una nuova entità (detta entità padre) che di esse è astrazione appunto di
generalizzazione. Possiamo ad esempio affermare che PERSONA è generalizzazione di
UOMO e DONNA, ovvero che LUOGO è generalizzazione di COMUNE e STATO
ESTERO. Nelle generalizzazioni potranno essere definiti attributi e relazioni che sono
significativi solo per una delle entità figlie. È questo il caso dello schema di Figura 8 in
cui l’attributo SITUAZIONE-MILITARE (che rappresenta lo stato della persona dal
punto di vista del servizio militare: esente, arruolato, ecc.) ha senso solo per gli uomini.

PERSONA

UOMO DONNA

SITUAZIONE MILITARE
Figura 8 - Un esempio di generalizzazione

12
Una fondamentale proprietà delle generalizzazioni è la seguente: in una astrazione di
generalizzazione, ogni proprietà della entità padre è anche proprietà delle entità figlie.
Per proprietà intendiamo gli attributi, le relazioni e le generalizzazioni cui partecipa la
entità. Così se ETÀ è attributo di PERSONA e PERSONA è generalizzazione di UOMO
e DONNA, ETÀ è chiaramente attributo anche di tali due nuove entità.
Si noti che una entità può essere l’entità padre di più generalizzazioni: ad esempio, in
una applicazione scolastica, la entità PERSONA può essere da una parte
generalizzazione nelle entità PROFESSORE e STUDENTE, e dall’altra nelle entità
UOMO e DONNA.

Sottoinsiemi
Un sottoinsieme è un caso particolare di generalizzazione, quella che sussiste tra l’entità
padre e una sola entità figlia. Ad esempio la entità ATTACCANTE è sottoinsieme di
GIOCATORE nello schema del campionato, perché ogni giocatore attaccante è anche
un giocatore, ma esistono giocatori che non sono attaccanti (per fortuna!). Anche per i
sottoinsieme è definita la proprietà in precedenza definita per le generalizzazioni. Ad
esempio tutti gli attributi e le relazioni associati a GIOCATORE nello schema di Figura
3.10 vanno automaticamente associati anche alla entità ATTACCANTE.

Esempio
Considerare lo schema Entità Relazione di Figura 9.

NATA

NOME

RISIEDE
PERSONA
COGNOME

NOME
CITTA' PROVINCIA
REGIONE

ETA' ETA'
NATO
UOMO DONNA

ALTEZZA

ETA'
FA
SERVIZIO MILITARE LAVORATRICE

Figura 9 - Schema concettuale dell'esempio

13
Lo schema rappresenta varie proprietà di uomini e donne rilevanti, ad esempio,
nell’analisi di un sistema anagrafico. Ipotizziamo che l’interesse degli utenti di tale
sistema sia legato agli effetti del servizio di leva obbligatorio sulla capacità delle
famiglie di produrre reddito. Vorremmo rappresentare quindi le persone, le città in cui
vivono, la loro relazione con il servizio militare ecc. Attraverso astrazioni di
classificazione vengono perciò definite alcune entità principali (PERSONA, CITTÀ),
mentre operazioni di generalizzazione producono le altre entità (UOMO, DONNA,
MILITARE, LAVORATRICE).
Da questo primo frammento di schema possiamo poi passare a considerare le proprietà
fondamentali delle entità fin qui trovate, ricordando che le entità sono null’altro che
aggregazioni di attributi (definizione intensionale di entità). Del numero potenzialmente
illimitato di attributi, è facile identificare quelli più immediatamente rilevanti per il
nostro universo del discorso: il nome ed il cognome (elementi di identificazione
personale), l’età e l’altezza (legati all’idoneità al servizio di leva), la provincia e la
regione di residenza (vincoli alla destinazione finale del militare di leva).
Si può notare che accanto all’entità CITTÀ non sono state introdotte anche le entità
PROVINCIA e REGIONE, malgrado i citati vincoli sulle destinazioni dei militari di
leva facciano riferimento ala regione di residenza. Nel caso di classi di oggetti la cui
estensione è delimitata, magari in seguito a norme o a standard di qualsiasi natura, come
è il caso della CITTÀ o della REGIONE, vale una evidente regola di economia che
suggerisce di elevare al rango di entità soltanto una, normalmente la più numerosa, e
rappresentare le altre come attributi della prima. Al termine di questo passo, gli attributi
sono sparsi nello schema senza un particolare ordine.
Passando alle relazioni, si può notare che i concetti anagrafici di luogo di residenza e di
luogo di nascita sono stati rappresentati non tramite nuove entità (ad esempio
CITTÀ_DI_RESIDENZA) ma come relazioni tra entità esistenti (PERSONA e CITTÀ):
appare chiaramente che la relazione è il costrutto che permette di introdurre nuove classi
“mettendo a fattore” quelle già definite.
Detto questo, si lascia al lettore la scelta di procedere con i seguenti passi.
1. Ristrutturare lo schema tenendo conto della proprietà fondamentale delle
generalizzazioni descritta in precedenza.
2. Lo schema rappresenta solo le lavoratrici donne; modificare lo schema
rappresentando ora tutti i lavoratori, uomini e donne.
3. Tra le proprietà delle città, l’attributo regione può essere visto anche come un
attributo del concetto PROVINCIA. Ristrutturare lo schema in tal senso.

Cardinalità
Le cardinalità sono proprietà di relazioni; la cardinalità minima di una entità definita in
una relazione è il minimo numero di volte che ogni occorrenza della entità può essere
coinvolta in una occorrenza della relazione. Il valore 0 significa che può esistere una
occorrenza di entità non coinvolta in alcuna occorrenza di relazione. Il valore 1 (n)
significa che non può esistere occorrenza senza essere coinvolta in 1 (n) relazioni.
Analoga definizione vale per la cardinalità massima. Le cardinalità minime e massime n
ed m di una entità in una relazione sono indicate con il simbolo (n,m) accanto alla entità.
Ad esempio, nella relazione TRA dello schema di Figura 3.11, le cardinalità sono:

14
1. (2,2) per la entità PARTITA (una partita si svolge esattamente tra due squadre).
2. (1,1) per la entità SQUADRA (una squadra è coinvolta esattamente una volta in una
partita).
Nella relazione GIOCA-IN le cardinalità sono:
1. (11, n) per la entità SQUADRA (una squadra deve avere come minimo 11 giocatori,
ma in generale ne ha molti di più).
2. (1,1) per la entità GIOCATORE (un giocatore, in un campionato, gioca esattamente
in una squadra).

3. La progettazione di schemi concettuali: un esempio


Vogliamo in questa sezione approfondire alcuni problemi connessi con le attività legate
all’utilizzo di schemi, descritte nella precedente sezione. Ci riferiamo in particolare alle
attività di progettazione.

Nel corso del progetto di uno schema noi siamo interessati a produrre schemi che siano
la fedele e completa descrizione dei requisiti, ed allo stesso tempo siano chiari e facili da
comprendere. Riguardo alla facilità di comprensione, occorre notare che nel modello
Entità Relazione le stesse informazioni possono essere rappresentate in generale in molti
modi possibili. Consideriamo ad esempio gli schemi di Figura 10.

NOME
COGNOME NOME
PERSONA ETA' PERSONA COGNOME
SESSO ETA'
CITTA' NASCITA
PROVINCIA-
NASCITA
NATO

UOMO DONNA
NOME
CITTA'
SITUAZIONE MILITARE

Primo schema Secondo schema

Figura 10 - Due schemi concettuali che rappresentano gli stessi requisiti

I due schemi rappresentano le stesse informazioni, alcune volte allo stesso modo, altre
volte con strutture diverse. Infatti, ad esempio:
1. la città in cui è nata una persona è rappresentata nel primo schema per il tramite di
una relazione associata a PERSONA, nel secondo semplicemente mediante un
attributo.

15
2. gli uomini sono rappresentate nel primo schema come le persone di sesso maschile,
nel secondo mediante la entità UOMO.

I due schema hanno lo stesso contenuto informativo (rappresentano cioè lo stesso


insieme di requisiti), ed ognuno enfatizza determinati aspetti mettendone, per cosi' dire,
altri in secondo piano.
Passando ora più specificatamente al progetto di uno schema, vogliamo ora mostrare e
discutere a titolo di esempio alcune strategie con cui possiamo procedere nel corso del
progetto. Le più importanti strategie sono le seguenti:
1. La strategia top-down produce lo schema finale attraverso una serie di raffinamenti
successivi (vedi Figura 11a), partendo da uno schema iniziale con pochi concetti
molto astratti, e raffinando via via lo schema con trasformazioni che aumentano
progressivamente il grado di dettaglio nella rappresentazione della realtà di
interesse. Mostriamo in Figura 3.15 alcuni esempi di trasformazioni elementari (o
primitive, nel seguito) tipiche della strategia top-down. Come si vede, ogni
primitiva raffina un concetto elementare (una entità o relazione) in una struttura più
complessa.
2. La strategia bottom-up (Figura 11b) procede rappresentando ogni aspetto
elementare della realtà di interesse per mezzo di un semplice schema concettuale,
procedendo poi a fondere questi schemi fin quando non si ottiene lo schema finale.

RAFFINAMENTI

La strategia top-down La strategia bottom-up


a) (b)
Figura 11 - Le strategie top-down e bottom -up

Esempio
Mostriamo un esempio di applicazione delle due metodologie progettando lo schema
concettuale di una applicazione anagrafica, in cui si vuole rappresentare dati relativi ad

16
un insieme di persone. Partiamo dalle seguenti specifiche. Vogliamo rappresentare un
insieme di dati relativi ad una applicazione anagrafica. In particolare i dati riguardano:
1. Le persone, di cui si vuole rappresentare il nome, il cognome, il sesso, e l’età.
2. I posti dove le persone vivono e dove sono nati. I posti possono essere di due tipi:
comuni, o stati esteri. Nel caso siano comuni, si vuole ricordare la provincia e
regione in cui è situato il comune. Nel caso di stati esteri, si vuole rappresentare la
popolazione.
3. Per le persone occupate si vuole ricordare il posto dove lavorano; per le persone non
occupate si vuole ricordare se abbiamo o meno lavorato nel passato.

DATI
SULLE PERSONE

DATI
ANAGRAFICI
DATI
SUI LUOGHI

Figura 12 - La trasformazione top-down primitiva

Possiamo inizialmente rappresentare l'applicazione per mezzo di una unica entità (vedi
Figura 12), che racchiude l’intero significato dello schema, chiamata DATI
ANAGRAFICI. Possiamo poi raffinare questa entità per mezzo di una trasformazione
che individua all’interno della applicazione due gruppi di dati, DATI-SULLE-
PERSONE e DATI-SUI-LUOGHI, in relazione tra di loro. Se ora consideriamo i
concetti dello schema possiamo osservare quanto segue:
1. La entità DATI-SULLE-PERSONE può essere raffinata in tre entità distinte,
PERSONA, OCCUPATO e NON-OCCUPATO, tra cui è definita una gerarchia di
generalizzazione.
2. La entità DATI-SUI-LUOGHI può esser raffinata, con un ragionamento simile, in
una gerarchia di generalizzazione formata da LUOGO, STATO-ESTERO e DATI-
SUI-COMUNI. Quest' ultimo nome è meno preciso dei precedenti perchè al
contrario degli stati esteri, vogliamo rappresentare vari tipi di proprietà dei comuni:
comune è perciò ancora un concetto provvisorio, che va ulteriormente raffinato.
3. La relazione RIFERITO-A è troppo generica; la possiamo raffinare in tre relazioni
distinte, NATO, VIVE e LAVORA. Le prime due sono riferite alla entità
PERSONA, la terza alla entità OCCUPATO.

Le trasformazioni applicate sono mostrate in Figura 13a. Come risultato di queste


trasformazioni otteniamo lo schema di Figura 13b.

17
PERSONA

Trasformazione primitiva DATI


SULLE
sulle persone PERSONE
NON
OCCUPATO OCCUPATO

LUOGO

Trasformazione primitiva DATI SUI


sui luoghi
LUOGHI

STATO DATI SUI


ESTERO COMUNI

Trasformazione primitiva RIFERITO NATO VIVE LAVORA


sulle relazioni A

(a) Un insieme di trasformazioni top-down

LAVORA

NATO LUOGO
PERSONA
PERSONA

VIVE

STATO DATI SUI


NON ESTERO
OCCUPATO OCCUPATO COMUNI

(b) Lo schema dopo la applicazione delle trasformaziomi

Figura 13 - Un insieme di trasformazioni top-down ed il corrispondente schema prodotto

Lo schema di Figura 13 non descrive ancora tutto il contenuto informativo delle


specifiche. In particolare:

1. Non abbiamo ancora descritto gli attributi di PERSONA.


2. Per quanto riguarda i comuni, noi vogliamo rappresentare sia la provincia che la
regione. Possiamo rappresentare queste informazioni espandendo la entità DATI-
SUI-COMUNI in due entità COMUNE e PROVINCIA, associando alle due entità
gli attributi NOME-COMUNE, NOME-PROVINCIA e REGIONE.
3. Infine, dovremo aggiungere gli attributi alla entità NON- OCCUPATO.

Aggiungendo ora allo schema finale tali concetti e le cardinalità, otteniamo lo schema di
Figura 14.

18
LAVORA

(1,1) (1,n)
COGNOME NOME
(1,n)
NOME NATO LUOGO
PERSONA (1,1)
SESSO
ETA'
(1,1) (1,n)
VIVE

STATO
NON ESTERO COMUNE
OCCUPATO POPOLAZIONE
OCCUPATO
HA LAVORATO?
(1,1)

IN

(1,n)
NOME
PROVINCIA
REGIONE

Figura 14 - Lo schema finale

Applicando la strategia bottom-up, possiamo procedere secondo il seguente ordine:


1. le proprietà elementari, cioè gli attributi;
2. un primo insieme di aggregazioni, rappresentate dalle entità;
3. le generalizzazioni ed i sottoinsiemi definiti tra entità;
4. un secondo insieme di aggregazioni rappresentate dalle relazioni.

Seguendo questo procedimento c'è in genere necessità di ristrutturare di volta in volta lo


schema, poiché una visione unitaria della proprietà dello schema si può avere solo
quando i diversi concetti siano stati rappresentati; ad esempio (vedi figura 15), è
possibile che siano stati individuate le due entità UOMO e DONNA, e ad entrambe
siano state associati gli stessi attributi. Dopo aver individuato la entità PERSONA,
generalizzazione di entrambe, è necessario ristrutturare lo schema assegnando gli
attributi alla nuova entità.
NOME
COGNOME
PERSONA
SESSO
ETA'

NON
HA LAVORATO?
OCCUPATO
OCCUPATO

Figura 15 - Ristrutturazione degli attributi

19
Riassumendo i vantaggi e gli svantaggi delle due strategie, possiamo affermare che la
strategia top-down, disciplinando le modalità di raffinamento dello schema, produce
sempre schemi che rappresentano l’intera applicazione in modo integrato e strutturato,
senza richiedere la necessità di modifiche o aggiornamenti su parti dello schema; allo
stesso tempo, è talvolta difficile da applicare in maniera rigorosa, proprio per questa sua
caratteristica di richiedere sempre una visione complessiva della realtà di interesse. Il
metodo bottom-up è in un certo senso nella situazione opposta: apparentemente è facile
da applicare, ma può dar luogo a sorprese.

4. Possibili ulteriori utilizzi degli schemi dei dati nei sistemi informativi
In questo capitolo abbiamo visto l’attività di produzione di uno schema dei dati come
strettamente legata alla attività di analisi. In effetti gli schemi dei dati possono essere
prodotti e utilizzati anche in diversi altri contesti. Essi sono:
• la individuazione del contenuto informativo comune a due o più basi di dati;
• la individuazione delle ridondanze e delle incoerenze tra più basi di dati;
• la produzione dello schema dati della organizzazione;
• l’integrazione di due o più schemi dati.

Per ciascuno di essi vediamo il significato, l’utilità nel ciclo di vita dei sistemi
informativi come possa essere svolta la attività, e qualche esempio di utilizzo.

4.1. Individuazione del contenuto informativo comune a due o più basi di dati
Abbiamo detto che le basi di dati del sistema informativo di una grande organizzazione
sono sempre sviluppate nel tempo in maniera disorganica. Per esempio la sola Pubblica
Amministrazione centrale italiana gestisce circa 600 basi di dati di dimensione maggiore
di un gigabyte, sviluppate negli ultimi 30 anni. Può essere utile per molte ragioni
comprendere quale sia il contenuto informativo comune a due o più basi di dati, ed in
particolare:
• per capire se sia opportuno unificare o fondere le due basi di dati, allo scopo di
aumentare il numero di interrogazioni o elaborazioni che possono essere effettuate
sull’insieme delle due basi di dati, e semplificarne la gestione e l’aggiornamento.
• per capire, anche mantenendo distinte le due basi di dati, quali interrogazioni o
elaborazioni ulteriori potrebbero essere fatte collegando le due basi di dati in un
sistema distribuito.
• Per capire quali ulteriori informazioni dovrebbero essere descritte in una o in
entrambe le basi di dati per accrescere il contenuto informativo complessivo delle
basi di dati.

Per individuare le eventuali ridondanze, intendendo per ridondanza la presenza delle


stesse tipologie di informazioni nelle diverse basi di dati. In un sistema distribuito, la
presenza di ridondanze è una scelta che va fatta con molta cura, perché ogni ridondanza
obbliga a gestire gli aggiornamenti delle diverse copie della stessa informazione
attraverso elaborazioni che possono essere anche molto complesse, quanto più
l’informazione è duplicata nel sistema. Avendo a disposizione gli schemi concettuali di

20
partenza, il contenuto informativo comune può essere individuato analizzando le entità e
le relazioni dei due schemi e selezionando le entità e relazioni con gli stessi nomi, e
quelle che pur non avendo gli stessi nomi risultato corrispondere allo stesso concetto del
mondo reale (sinonimi).

4.2. Individuazione delle incoerenze tra più basi di dati


In questo caso vogliamo comprendere quanto le scelte progettuali effettuate in termini di
informazioni rappresentate negli schemi abbiamo portato ad introdurre scelte concettuali
diverse nella rappresentazione della stessa tipologie di informazione. Per esempio, in
una base dati anagrafica è possibile modellare l’indirizzo di residenza con diverse
modalità concettuali:
a. con un unico attributo INDIRIZZO, rappresentato con una stringa di caratteri di
lunghezza fissata (esempio, 50 caratteri alfabetici)
b. con quattro attributi VIA, NUMERO CIVICO, CODICE AVVIAMENTO
POSTALE, CITTÀ, rappresentati rispettivamente con una stringa di caratteri, un
numero, un numero, una stringa di caratteri.
c. Con opportune varianti delle scelte precedenti.

Spesso nel passato, al fine di ottimizzare lo spazio occupato in memoria, sono state
effettuate scelte di tipo a, che portano ad una riduzione del numero degli attributi. Ma
anche in questo caso, se ci si trovava a realizzare diverse basi di dati in cui compariva lo
stesso attributo Indirizzo, potevano essere scelte per le stringhe di caratteri diverse
lunghezze. Nella Pubblica amministrazione centrale esistono decine di basi di dati in
cui è rappresentato un attributo indirizzo: le basi di dati fiscali, quelle catastali, quelle
previdenziali, e cosi via.
Una diversa rappresentazione delle stesse informazioni in basi di dati diverse porta a
diversi effetti indesiderati: prima di tutto non è più possibile, o, meglio, diventa molto
più difficile, collegare le basi di dati per il tramite della informazione rappresentata in
modo incoerente, perché essa può assumere valori diversi. In secondo luogo, diventa
molto oneroso l’aggiornamento delle diverse copie. In terzo luogo diventa onerosa
qualunque progetto di integrazione delle basi di dati, perché è necessario ricostruire la
versione corretta della informazione.

4.3. Integrazione di due o più schemi dati


Avere a disposizione gli schemi concettuali delle basi di dati diventa importante anche in
qualunque attività di integrazione delle stesse.(vedi figura 16).

21
DBMS Utenti Utenti
DBMS

Utenti
DBMS Utenti (b) Unica base dati centralizzata

(a) Basi di dati separate

DBMS Utenti Utenti


DBMS
Utenti
DBMS Utenti Utenti
Utenti DBMS
DBMS

(c) Base dati distribuita (c) Base dati federata ad (e) Base dati federata
accoppiamento forte adaccoppiamento debole

Utenti DBMS Utenti


DBMS
DBMS Utenti

Utenti DBMS Utenti


DBMS DBMS
Utenti
(h)Data warehouse
(f) Uso di traduttori (g) Base di dati con estrazione di dati

Figura 16 - Forme di integrazione tra basi di dati

La forma più stretta di integrazione tra basi di dati si ottiene mediante la integrazione
delle diverse basi di dati in una unica base dati (figura 16.b), cioè il ritorno alla
precedente situazione di totale centralizzazione. In questo caso, avere a disposizione gli
schemi concettuali delle basi di dati da integrare permette di arrivare ad una integrazione
di natura semantica tra le diverse basi di dati, che tiene cioè conto del significato delle
informazioni presenti, e facilita perciò la comprensione tra gli utenti e la correttezza
delle elaborazioni. Per fare un esempio, se nelle attuali basi di dati compaiono due
archivi in uno dei quali sono riportati in distinte tabelle i fatturati di un insieme di
aziende nei dodici distinti mesi dell’anno, espressi in migliaia di lire e nell’altro tale
insieme di informazioni è rappresentato in una unica tabella, espressi in milioni, nella
base dati integrata tali differenze di rappresentazione vengono rimosse, dando luogo ad
una unica omogenea rappresentazione. Questa forma di integrazione è in realtà molto
difficile da attuare, per la grande rapidità con cui dati e basi di dati evolvono nelle
organizzazioni, e spesso inopportuna o non realizzabile, per la autonomia che utenti e
gruppi di utenti intendono mantenere sulle basi di dati da essi create e aggiornate.

Una variante della precedente scelta è quella delle basi di dati distribuite, in cui la base
dati è ancora gestita da un unico DBMS, ma può essere frammentata in tante basi di dati
locali. Ciò in genere migliora l’efficienza per accessi locali, ma rende più complessi
problemi di aggiornamento su diverse basi di dati. In questa soluzione, usualmente, lo

22
schema concettuale dell’insieme delle basi di dati è l’elemento di partenza per compiere
le scelte razionali sulle modalità di distribuzione.
Tutte le soluzioni successivamente esposte indeboliscono progressivamente il tipo di
integrazione tra le diverse basi di dati. In una base dati federata ad accoppiamento forte
le diverse basi di dati vengono gestite autonomamente da diversi DBMS, ma esiste un
nuovo componente software che ha la possibilità di accedere omogeneamente alle
diverse basi di dati, coordinandone le operazioni. In questo caso lo schema concettuale è
indispensabile per permettere a tale componente software di comprendere dove siano
allocate nella federazione le diverse tipologie di informazione, e in quale formato
concettuale e logico. In una base di dati federata ad accoppiamento debole, rispetto alla
precedente, il nuovo componente garantisce soltanto una visione virtuale integrata, ma
non ha potere di intervento gestionale sui sistemi che rimangono fortemente autonomi.

Le tecnologie a gateway (traduttori o filtri tecnologici) permettono di tradurre richieste


formulate in un linguaggio per un DBMS A in termini di richieste per il linguaggio
adottato dal DBMS B. Hanno il vantaggio che non richiedono nessuno o limitato
sviluppo di software aggiuntivo, ma richiedono componenti ad hoc per ogni singola
relazione tra sistemi distinti, e fanno perdere la trasparenza resa possibile dalle soluzioni
precedenti.

Il meccanismo più debole di integrazione tra basi di dati è quello della estrazione e
trasferimento di dati, con aggiornamento periodico della base dati locale a partire dalla
base dati remota.

In tutte le precedenti forme di integrazione, questa viene instaurata operando sulle basi di
esistenti con nuovi componenti architetturali. Nei data warehouse (magazzini o depositi
di dati) viene creata (periodicamente) una nuova base dati, che nasce dalla integrazione
stretta delle basi di dati esistenti, e tale nuova base dati viene resa accessibile con potenti
linguaggi per l’analisi e la estrazione di informazioni rilevanti a fini decisionali. La
produzione dello schema concettuale integrato delle basi di dati è il passo preliminare
fondamentale a tutte le attività di produzione del data warehouse.

4.4. Produzione dello schema dati della organizzazione


Nella vita di una organizzazione, esistono momenti, ad esempio nella fase di
pianificazione dei sistemi informativi, in cui si ha necessità di acquisire una visione
integrata e di alto livello, indipendente ciò dalle tecnologie utilizzate e dalle scelte
contingenti effettuate, dello stato del sistema informativo della organizzazione. Si pensi
ad una Pubblica Amministrazione nella quale sia in corso un processo di
riorganizzazione delle competenze, modifica delle strutture organizzative con fusione di
alcune, introduzione di strutture di coordinamento, accorpamento delle stesse funzioni
in una unica struttura, ecc.

In tali situazioni, può essere molto utile costruire lo schema concettuale di alto livello
delle informazioni trattate nella organizzazione, chiamato talvolta “Enterprise schema”

23
o Schema di organizzazione. Naturalmente tale schema può essere prodotto a diversi
livelli di dettaglio, e quindi, nella sua versione più estesa può contenere centinaia di
entità e relazioni differenti. È ragionevole arrivare alla definizione di uno Schema di
organizzazione in cui il numero di entità e relazioni sia contenuto nell’ordine delle
decine, non superando mai le 40-50, che possono considerarsi una soglia al di sopra
della quale diventa molto complesso e costoso produrre lo schema. Le entità e relazioni
che compariranno nello Schema di organizzazione saranno di conseguenza macroentità
e macrorelazioni, cioè entità e relazioni che nascono dalla aggregazione di informazioni
elementari utilizzate nella organizzazione.

Come conseguenza del procedimento di costruzione accennato, lo Schema di


organizzazione contiene le tipologie di informazioni più importanti trattate nella
organizzazione. Collegando in una matrice tali tipologie di informazione, ma soprattutto
le entità, con i processi che creano, aggiornano e utilizzano le informazione (vedi figura
17) si ha una visione sintetica ma efficace dei flussi informativi tra processi, che
permette di individuare le entità aggiornate da più processi, ovvero i gruppi di processi
ed entità caratterizzati da alta coesione interna, chiamati in alcune metodologie Aree di
business. Una simile matrice può essere prodotta collegando le Unità Organizzative e le
Entità.

P rocessi/ Entità Entità1 Entità2 Entità3 Entità4 Entità5 Entità6 Entità7


Processo1 Crea Crea Usa
Processo2 Usa Usa Crea Usa
Processo3 Usa Aggiorna Usa Crea
Processo4 Usa Crea
Processo5 Crea Crea Usa

Figura 17 - Matrice Processi/Entità

Esempio
Negli anni 1993–1995 l’AIPA ha condotto una rilevazione dello stato dei sistemi
informativi della Pubblica Amministrazione centrale che ha portato a costruire circa 260
schemi concettuali delle principali basi di dati, con circa 4200 entità e relazioni
rappresentate. Tali schemi sono stati successivamente raggruppati secondo criteri di
omogeneità di materia in 31 diverse aree (vedi figura 17): protocollo, organi collegiali,
fisco, dogane, ecc., producendo per ciascuna area uno schema concettuale. Tale schema
concettuale è il risultato della integrazione di tutti gli schemi di partenza che
appartengono alla stessa area, e di una successiva attività di selezione delle macroentità
principali dello schema integrato. La scelta delle aree è stata effettuata secondo criteri di
similitudine degli schemi, e come conseguenza la numerosità degli schemi che sono
ricaduti in ciascuna area (riportata in figura insieme al numero delle entità) è molto
disomogenea.

A questo punto i 31 schemi concettuali di area sono stati ulteriormente integrati in 19


schemi di materia, ove le materie sono state scelte sulla base di classificazioni esistenti

24
nella Pubblica Amministrazione: risorse di supporto, risorse finanziarie, giustizia,
sicurezza, ecc. Per ciascuna materia, è stato costruito uno schema concettuale secondo i
due procedimenti di integrazione e scelta delle macroentità principali. Tale
procedimento è stato utilizzato per costruire gli ulteriori schemi integrati corrispondenti
ai servizi sociali ed economici, ai servizi generali, i servizi diretti, raggruppati
successivamente in un unico schema dei servizi, che insieme allo schema delle risorse è
stato infine integrato in quello che possiamo definire lo Schema di organizzazione della
Pubblica Amministrazione, rappresentato a tre diversi livelli di aggregazione.

SCHEMA INTEGRATO DELLE BASI DI DATI DELLA PA DI 1° LIVELLO

SCHEMA INTEGRATO DELLE BASI DI DATI DELLA PA DI 2° LIVELLO

SCHEMA INTEGRATO DELLE BASI DI DATI DELLA PA DI 3° LIVELLO

RISORSE SERVIZI

SERVIZI SOCIALI ED ECONOMICI


SERVIZI GENERALI SERVIZI DIRETTI

SERVIZI SOCIALI SERVIZI ECONOMICI

RISORSE SERVIZI
RISORSE DI RISORSE RISORSE
FINANZIARIE STRUMENTALI E UMANE SOCIALI E CERTIFICA-
STATISTICA ASSICURAZIO- AFFARI
DIFESA EDILIZIA
GIUSTIZIA SICUREZZA SANITA' ISTRUZIONE CULTURA
TRASPORTI
LAVORO PRODUZIONE COMUNICAZIONI
SUPPORTO IMMOBILIARI ZIONE
TERRITORIALI NE SOCIALE ESTERI AMBIENTE
RELAZIONI ITALIANE ALL' ESTERO
RELAZIONI ESTERE IN ITALIA
A ENTI LOCALI PER ENTI PUIBBLICI

BENI IMMOBILI

RAPPRESENTANZE
STRUMENTI

AUTOMEZZI
ORGANI COLLEGIALI
PROTOCOLLO

FORMAZIONE
DIPENDENTI

CERTIFICAZIONI

AZIENDE INDUSTRALI
ENTI TERRITORIALI

AZIENDE AGRICOLE
BENI CULTURALI
TRASFERIMENTO FONDI

ATTIVITA' GIURIDICA

SICUREZZA INTERNA

LAVORO
CRIMINALITA'

TRASPORTI
SERVIZIO SANITARIO
CATASTO
CAPITOLI DI SPESA

PREVIDENZA

ISTRUZIONE
ASSISTENZA

AMBIENTE
DOGANE
6/69 FISCO

2/89

3/59

9/118
2/65
2/93

37/336
8/293

3/182

3/75

3/66

10/178
6/76

5/56
4/121

8/213
6/95

3/134

10/100
9/118
2/12

4/36

3/53
10/76

9/112
6/130
3/30

6/155
6/53

Figura 18 - Le attività per la produzione degli schemi concettuali della Pubblica Amministrazione

Riportiamo in figura lo schema più astratto, in cui comp aiono le entità:


• Soggetto, cui corrispondono i soggetti fisici e giuridici che chiedono servizi alla
Pubblica amministrazione.
• Bene, che corrisponde all’insieme dei Beni mobili e Immobili su cui la Pubblica
Amministrazione ha responsabilità ed eroga servizi.
• Documento, che corrisponde all’insieme dei documenti che la Pubblica
Amministrazione utilizza e produce nei processi amministrativi.
• Riferimento Territoriale, costituito dall’insieme di tutte le modalità
amministrative e geografiche con cui è possibile descrivere il territorio (es, comune,
provincia, particella catastale, ecc.).
• Unità Organizzativa, che descrive tutte le suddivisioni organizzative in cui si
articola la Pubblica Amministrazione centrale (ministeri, direzioni generali,
divisioni, uffici, unità periferiche).

25
Unità
Bene organizzativa
Soggetto

Riferimento Documento
territoriale

Figura 19 - Lo schema concettuale delle macroentità principali della Pubblica Amministrazione

Rappresentiamo infine in figura 20 una descrizione grafica di matrice Unità


Organizzative/Entità, in cui per le entità Organizzative sono rappresentate le Pubbliche
amministrazioni Centrali (descritte da acronomi, es. MF è il Ministero delle Finanze) e le
entità sono la macroentità Persona Fisica e tutte quelle per cui Persona fisica è negli
schemi una Generalizzazione: si vede ad esempio come moltissime siano le
amministrazioni che hanno competenza amministrativa sui lavoratori. La figura è un
possibile punto di partenza per procedere ad una razionalizzazione nella gestione delle
informazioni sulle persone fisiche che porti alla individuazione di una o un numero
limitato di amministrazioni con responsabilità di aggiornamento sulle singole sottoentità
e alla creazione di una rete di accesso per tutte le amministrazioni che abbiano rilevante
esigenze di utilizzo.
MGG, MI,
47 MF, MT MIBCA ,
40 48 165 180 650 MT, MTN
MI, MS 526
38 37 36 110
39 35 174
82 59 MAE, MURST,
89 Contribuente utente anagrafe 98 MPI
153 ufficio iva tributaria
appartenente casalinga 6 600
163 assistito catasto
MI, MT, MD borsista
162 tossicodipendente volontario 16 601
contribuente
520 Ricorrente per con handicap
invalidità civile 142
161 invalidità civile Salute ed fisco vita
sociale studente
91 pensionato assistenza straniero

164 di guerra scuola


pensioni Segretario 81
Persona fisica comunale
politica
Alla ricerca di disoccupato MI
prima occupazione lavoro candidato
653
giustizia
160 Alla ricerca di
52 lavoratore affari esteri segnalato 80
nuova occupazione
74 92 Tossicodipendente
101 segnalato
190 autonomo straniero italiano detenuto
654 dipendente
2 in attesa di giudizio 66
88 104
54 105 663 Richiedente
4 condannato
171 cittadinanza 99
53 71 603
87 MAE, MF, 7 19
Richiedente residente
72
11 108 visto all’estero
12 MGG, MI, 10 120 MAE, MGG,
651 MIBCA, MLP, 9 21 63 MI
65 MLPS, 2 0 MT,2 4 25 18
97 109
68MTN,5MCE, 93 96 27 90
501 1
MD, MURST 131 5
45 73
172 137 132
656 64 173
55 86
136
516 515 531 506 MAE, MI,
111 MLPS
602 170 507

Figura 20 - Entità che ricadono nella tipologia delle persone fisiche e amministrazioni interessate alla loro
creazione, aggiornamento e utilizzo nei processi amministrativi su cui hanno competenza

26
5. Uno studio di caso
In questa sezione verrà discusso un caso di analisi e modellazione dei dati ispirato alla
gestione del personale della pubblica amministrazione. Come vedremo, questo tema
presenta allo stesso tempo degli aspetti familiari ed intuitivi insieme ad aspetti di una
certa complessità e problematicità.

5.1. Introduzione
L’ambito informativo di cui ci vogliamo occupare è stato oggetto di innumerevoli
analisi in conseguenza della sua evidente centralità sociale e politica. Le recenti norme
sul pubblico impiego, ad esempio la legge 421/1992 e il decreto legislativo 29/1993,
hanno affrontato finalità di razionalizzazione della gestione e di contenimento della
spesa che non possono evidentemente prescindere dalla disponibilità di migliori
strumenti informatici e quindi di un’analisi approfondita della realtà. A questo fine la
Presidenza del Consiglio dei Ministri ha dato impulso a diverse attività realizzative e di
studio, e l’Autorità per l’Informatica nella Pubblica Amministrazione ha curato tra
l’altro una rilevazione delle funzioni di amministrazione del personale e uno studio
delle basi di dati del personale nella pubblica amministrazione.

Alcuni dati possono fare intuire le dimensioni di questo ambito di analisi. Come è noto,
della gestione del trattamento economico del personale pubblico è investito
istituzionalmente il Ministero del Tesoro, e precisamente la Ragioneria Generale dello
Stato per quanto riguarda circa 60.000 dipendenti degli uffici centrali e la Direzione
Generale dei Servizi Periferici per circa 1.300.000 dipendenti degli uffici periferici.
Anche le singole amministrazioni però gestiscono talvolta parte delle stesse
informazioni, e in ogni caso devono gestire molte altre informazioni non di competenza
del Ministero del Tesoro. Nel complesso sono utilizzate a questi fini non meno di 37
basi di dati che presentano un’enorme varietà di copertura dei dati e delle funzioni
effettivamente presenti rispetto a quelle desiderabili.

Le origini di questa situazione sono facilmente riconducibili alla naturale autonomia


delle singole amministrazioni, alla loro diversa consistenza in termini di personale, e
alla lunga storia dei sistemi per la gestione del personale, storicamente tra i primi ad
essere stati automatizzati e poi informatizzati.

Per dare un’idea della complessità funzionale insita nella gestione del personale della
pubblica amministrazione, si può notare che la rilevazione appena citata ha identificato,
limitatamente al comparto dei ministeri, ben 150 funzioni elementari, suddivise in tre
livelli di aggregazione, che possono essere visti come una sorta di modello funzionale di
riferimento. Al livello più alto sono state distinte otto macrofunzioni:
1. gestione delle presenze ed assenze
2. acquisizione del personale e cessazione del rapporto di lavoro
3. sviluppi professionali e modificazione del rapporto
4. trattamento economico di servizio
5. trattamento di previdenza e di quiescenza; infermità e causa di servizio
6. contenzioso e disciplina

27
7. formazione del personale
8. funzioni accessorie

Ciascuna delle 150 funzioni elementari identificate al livello di maggiore dettaglio,


invece, deve la propria esistenza ad una lista di disposizioni normative che ne regola lo
svolgimento. Per fare solo alcuni esempi, sono considerate funzioni elementari la
gestione
• del trattamento economico di missione (regolato dalla legge 836/1973),
• dei ricorsi amministrativi straordinari presso il Presidente della Repubblica (quattro
riferimenti normativi a partire dal regio decreto 1054/1924),
• della liquidazione dell’indennità di rischio per centralinisti non vedenti (legge
113/1985),
• delle assenze per incarichi di direzione presso aziende sanitarie locali (decreto
legislativo 502/1992).

Quando i requisiti di un sistema sono il risultato di una stratificazione durata molti


decenni, come in questo caso, non può stupire che anche gli archivi, da quelli cartacei
alle basi di dati, soffrano di disorganicità. Lo studio sulle basi di dati del personale ha
evidenziato infatti come alcune amministrazioni, soprattutto nel passato, abbiano gestito
fino a dieci basi di dati diverse al proprio personale, spesso dedicando una specifica base
di dati alla gestione di un aspetto minore, ad esempio le donazioni volontarie di sangue
dei dipendenti.

5.2. Raccolta dei requisiti


Soprattutto in un ambito così complesso, l’analisi dei dati non può partire che da una
descrizione testuale delle attività e delle funzioni di gestione del personale, che potrà
presentare inizialmente carattere di incompletezza e di incoerenza. Come si è visto, parte
integrante dei requisiti è l’intero corpo normativo che regola il settore del pubblico
impiego, e che comprende molte decine di testi di interpretazione talvolta non
immediata. Per il nostro scopo, ci limiteremo qui a considerare i requisiti fondamentali,
già anticipati in precedenza.

Un sistema informativo del personale della pubblica amministrazione deve gestire tutte
gli aspetti riassunti dalle macrofunzioni elencate precedentemente e che risultano dalle
norme vigenti (leggi, regolamenti, contratti collettivi eccetera).

Questa formulazione dei requisiti ha una prima conseguenza niente affatto banale: il
sistema informativo del personale della pubblica amministrazione è regolato da requisiti
normativi in parte comuni a tutte le amministrazioni, e quindi la sua realizzazione
attuale, come insieme debolmente coordinato di sistemi informativi eterogenei, è da
riguardarsi come accidentale. Alcune delle funzioni del sistema del personale,
solitamente indicate come funzioni “di governo” e che comprendono ad esempio la
pianificazione delle assunzioni o l’elaborazione del conto annuale, oppure la definizione
di indirizzi strategici nella formazione del personale, indicano chiaramente la natura
“unitaria” di tale sistema informativo, pur nel rispetto dei confini di responsabilità di

28
ciascuna amministrazione. Si tratta quindi di un buon esempio di sviluppo “a pelle di
leopardo” di un sistema informativo.

Ricordando quanto detto nella sezione 3 sulla progettazione dei dati, possiamo ora
applicare i due procedimenti top-down e bottom-up e sottoporre a verifiche di coerenza e
di completezza gli schemi di dati via via disegnati. Nel nostro caso, in considerazione del
materiale a nostra disposizione rappresentato dagli studi specifici condotti
sull’argomento, faremo un esempio di applicazione del procedimento top-down.
L’obiettivo finale sarà un modello dei dati “unitario” che possa rappresentare i dati
relativi a tutte le funzioni identificate dallo studio citato, e rispetto al quale sia anche
possibile valutare il grado di copertura e di integrazione dei sistemi del personale di
ciascuna amministrazione. Accenneremo anche al procedimento bottom-up che ha
condotto allo schema unitario del personale. Analogamente, facendo riferimento alla
sezione 4, esamineremo ulteriori usi degli schemi di dati nei sistemi informativi.

5.3. Modellazione dei dati e raffinamento di schemi


Partiamo da un primo schema il cui scopo è delimitare in modo chiaro l’ambito
informativo. Lo schema contiene un solo oggetto, l’entità “lavoratore dipendente
pubblico”.

Lavoratore dipendente
pubblico

Figura 21 - Entità iniziale

Per definire meglio questa entità da un punto di vista intensionale è possibile ora
aggiungere i primi attributi. Notare che a questo stadio tutti i dati rilevanti devono
necessariamente comparire come attributi dell’unica entità, e ciò può rendere illeggibile
lo schema. È quindi conveniente procedere gradualmente prima al raffinamento del
modello e poi all’arricchimento delle entità con i rispettivi attributi. Gli attributi
identificati fin qui sono quelli indispensabili all’identificazione del lavoratore.
matricola
cognome Lavoratore dipendente codice fiscale
nome pubblico stipendio
data di nascita ufficio
sesso

Figura 22 - Attributi iniziali dell'entità

29
Passiamo a considerare alcune naturali generalizzazioni. Accade il più delle volte che
l’entità che rappresenta l’ambito informativo di un sistema si trovi al centro di una
catena di generalizzazioni che introduce nel modello nuove entità. Per fare un esempio,
dal momento che evidentemente anche un dipendente di una azienda privata può
concorrere a posti nella pubblica amministrazione, un’amministrazione che bandisce
concorsi pubblici può essere tenuta a gestire dati relativi a qualifica ed anzianità di
dipendenti privati. È opportuno quindi introdurre un’entità “lavoratore”, i cui attributi
rappresenteranno dati su lavoratori generici, mantenendo gli attributi specifici
dell’ambito di interesse nella entità “lavoratore dipendente pubblico”.

cognome
Lavoratore
nome codice fiscale
data di nascita
sesso

matricola Lavoratore dipendente Candidato Aspirante ad impiego


stipendio pubblico pubblico
ufficio

Dipendente di uffici centrali Dipendente di uffici periferici

Figura 23 - Gerarchia sull'entità LAVORATORE

Tra l’altro, l’introduzione di una “superentità” e la conseguente ridistribuzione degli


attributi contribuisce ad una maggiore chiarezza dello schema di dati.

Riprendiamo ora il procedimento top-down e aggiungiamo nuovi oggetti attorno


all’entità di base. Per il momento è possibile lasciare le relazioni senza un nome, in
quanto i nomi attribuiti sarebbero ancora generici ed arbitrari.

30
Concorso Situazione amministrativa

cognome
matricola
nome
Ufficio Lavoratore dipendente codice Provvedimenti
data di nascita pubblico fiscale
sesso

Situazione familiare Competenze e ritenute

Figura 24 - Risultato dell'aggiunta di oggetti attorno all'entità iniziale

Per quanto riguarda le entità, alcuni degli attributi (“ufficio”, “stipendio”) vengono a
chiarirsi come attributi complessi, o meglio come nuove entità e nuove relazioni
collegate all’entità iniziale. Ad esempio, raffinando ulteriormente la relazione “ufficio”-
“lavoratore dipendente pubblico” racchiusa nel rettangolo tratteggiato si ottiene lo
schema seguente.

31
cognome
matricola
nome Lavoratore dipendente codice
data di nascita pubblico fiscale
sesso

Comune

Ufficio Richiesta di trasferimento

Ente o amministrazione Ufficio pagatore Ufficio gestore del personale Sede di lavoro

Ministero Ente locale Organismo scolastico Sede estera

Figura 25 - Raffinamento di una relazione

Si può sottolineare che l’introduzione di generalizzazioni nello schema non è


evidentemente il risultato di un esercizio astratto o arbitrario ma riflette piuttosto
l’accrescimento della conoscenza conseguente al processo di analisi. Ad esempio,
l’entità “ufficio” appare ora come vertice di una generalizzazione che permette di
distinguere tra “ufficio pagatore”, “ufficio gestore” e “sede di lavoro”. Questa
generalizzazione discende da una distinzione probabilmente familiare al lettore, ma
soprattutto riflette differenze a livello di dati: tra gli attributi dell’entità “sede di lavoro”
possiamo facilmente ipotizzare il numero degli addetti che vi lavorano, dato scarsamente
pertinente per l’entità “uffico pagatore” di cui potranno forse interessare gli estremi
bancari.

Per fare un esempio un po’ meno intuitivo, la generalizzazione con vertice l’entità “ente
o amministrazione” rispecchia alcune specificità che sconsigliano un trattamento
informatico omogeneo dei trasferimenti del personale del Ministero della Pubblica
Istruzione rispetto a quello degli altri ministeri e degli enti locali. Analoga
considerazione si può fare per la gestione dei trasferimenti da o verso sedi di lavoro
situate all’estero.

Applichiamo ora il procedimento di raffinamento all’entità “competenza o ritenuta”,


racchiusa in un rettangolo tratteggiato nella figura 24. L’articolazione della
generalizzazione rappresentata nella figura è la più complessa tra quelle contenute nello
schema dei dati unitario.

32
Competenza o ritenuta

Rivalutazione monetaria Detrazione di imposta Ritenuta extraerariale Altra competenza o ritenuta


interessi legali

Arretrato Competenza fissa Riduzione di stipendio per Competenza accessoria


scioperi o ritardi

Stipendio base Indennità integrativa speciale Retribuzione individuale di Tredicesima


anzianità

Assegno ad personam Straordinario Indennità di incentivazione e Assegno codificato


produttività

Altra competenza accessoria Indennità aggiunta di famiglia Indennità di amministrazione

Indennità di funzione

Incentivo alla produttività Indennità per progetto Indennità budget di struttura


finalizzato

Figura 26 - Raffinamento di un’entità

Continuando ad applicare il procedimento top-down potemmo ottenere l’intero schema


di dati integrato contenuto nello studio dell’AIPA. Lo studio stesso è invece un
importante applicazione del procedimento bottom-up che, partendo da 37 basi di dati e
dai relativi schemi concettuali per un totale di 526 tra entità e relazioni, ha permesso di
ottenere uno schema integrato contenente solo 140 oggetti (96 entità e 44 relazioni).

5.4. Schemi di dati e contenuto informativo: indici di copertura


Nella sezione 4. sono stati discussi gli utilizzi degli schemi di dati diversi dalla
modellazione a scopo progettuale. Questi usi sono essenzialmente legate ad una
maggiore conoscenza della realtà informativa di uno o più sistemi informatici. In
particolare, come abbiamo appena visto, lo studio dei sistemi informativi del personale
delle pubbliche amministrazioni può essere condotto per tutti e quattro gli scopi elencati
nella sezione 4.

La disponibilità di uno schema integrato o di uno schema dati dell’organizzazione, sia


pure limitato ad un ambito specifico come quello del personale, rende possibile misurare

33
la completezza e, indirettamente, la coerenza del contenuto informativo delle basi di dati
all’interno di una organizzazione complessa.

Si possono introdurre due misure del grado di frammentazione informativa delle basi di
dati, utilizzate nella rilevazione più volte citata. La prima misura il contenuto
intensionale, cioè la “complessità” della base di dati, attraverso il numero di oggetti
informatici. La seconda misura il contenuto estensionale, cioè le “dimensioni” della base
di dati, attraverso il numero di occorrenze associate a ciascuna entità o relazione. La
complessità delle basi di dati del personale rilevate varia da 3 oggetti (in pratica due
entità e una relazione) a 68, mentre le dimensioni variano grosso modo tra il migliaio di
occorrenze di diverse basi di dati minori presso molte amministrazioni e i dieci milioni
di occorrenze di una grande base di dati del Ministero del Tesoro. Questi dati sono
riassunti nella seguente tabella.

minimo massimo
comp lessità (n° oggetti) 3 68
dimensioni (n° occorrenze) ~103 ~107
Figura 27 - Complessità e dimensioni delle basi di dati del personale

È possibile anche definire una semplice misura del grado di copertura delle basi di dati
del personale, ottenuta dividendo il numero di oggetti rappresentati in una base di dati
con il numero complessivo degli oggetti contenuti in uno schema integrato di
riferimento. Ricordiamo che per oggetto intendiamo un’entità o una relazione.

Nello schema finale dello studio di caso (figura 28), che contiene 43 oggetti, sono stati
evidenziati i 6 oggetti presenti in uno schema dei dati di una ipotetica amministrazione.
L’indice di copertura, calcolato su questo schema parziale, è pari al 14%. In realtà, lo
studio AIPA contiene degli indici di copertura calcolati sull’intero schema dei dati
unitario, che contiene 140 oggetti. Ciò ha permesso di classificare le basi di dati del
personale esistenti presso le amministrazioni in base al loro grado di copertura, compresi
tra l’11% e il 64%.

34
cognome
matricol
nome codice
data di Lavoratore dipendente
sesso pubblico fiscale

Comune

Ufficio Richiesta di trasferimento

Ente o amministrazione Ufficio pagatore Ufficio gestore del Sede di lavoro


personale

Ministero Ente locale Organismo scolastico Sede estera

Competenza o ritenuta

Rivalutazione monetaria Detrazione di imposta Ritenuta extraerariale Altra competenza o ritenuta


interessi legali

Arretrato Competenza fissa Riduzione di stipendio per Competenza accessoria


scioperi o ritardi

Stipendio base Indennità integrativa Retribuzione individuale di Tredicesima


speciale anzianità

Assegno ad personam Straordinario Indennità di incentivazione Assegno codificato


e produttività

Altra competenza accessoria Indennità aggiunta di Indennità di


famiglia amministrazione
Indennità di funzione

Incentivo alla produttività Indennità per progetto Indennità budget di struttura


finalizzato

Figura 28 - Schema finale dello studio di caso

35
6. Riferimenti
A. ALBANO, R. ORSINI - Basi di dati - Boringhieri Editore, Torino, 1986.
P. ATZENI, C. BATINI, V. DE ANTONELLIS - La teoria relazionale dei dati -
Boringhieri Editore, Torino, 1986.
C. BATINI, S. CERI , S.B.NAVATHE – Conceptual Database Design: An Entity
Relationship Approach - Benjamin & Cummings, 1991.
C. BATINI, G. DE PETRA, M. LENZERINI, G. SANTUCCI - La progettazione
concettuale dei dati - F. Angeli Editore, Milano, 1986.
C. BATINI, M. LENZERINI - Basi di dati, in G. CIOFFI, V. FALZONE (a cura di)
Manuale di Informatica - Calderini Editore, Bologna, seconda edizione, 1988.
C. BATINI, G. LONGOBARDI, M. MAGGI - Le basi di dati del personale nella
pubblica amministrazione: analisi del livello di integrazione e copertura - AIPA.
R. EL MASRI, S. NAVATHE - Foundamentals of Database Systems - Benjamin and
Cummings, 1989.
P. NAGGAR, M. MELLONE - Progetto SIUP - Rilevazione sulle funzioni di
amministrazione del personale - AIPA, 1998.
J. ULLMAN - Principles of Database and Knowledge base Systems - Computer Science
Press, Seconda Edizione, 1988.

36