3 - 2 Linguaggi per la modellazione dei dati - DIMES...

1

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

2

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.

3

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

SECONDO

TERZO SECONDO

FINALE

SCHEMA DATI SCHEMA FUNZIONI

FINALE

SCHEMA FUNZIONI

SCHEMA FUNZIONI

SCHEMA DATI

SCHEMA DATI

SCHEMA DATI

PRIMO

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

4

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

5

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.

UFFICIO GESTIONE

DEL PERSONALE

Matricola

Cognome

Nome

Titolo studio

Livello

Stato civile

Valutazioni

UFFICIO

ORGANIZZAZIONE

Ufficio

Cognome Nome Matricola Livello Mansione

UFFICIO

AMMINISTRAZIONE

DEL PERSONALE

LivelloMatricolaCognomeNomeAssegniPremioMeseOre

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.

6

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

7

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).

MODELLO RELAZIONALEMODELLO GERARCHICO

PARTITA-IVA NOME INDIRIZZO

LIBRERIA

CODICE-L TITOLO NUMEROCOPIE

EDITORE

CODICE-A NOME COGNOMEDATA

NASCITA SESSO

LIBRO

AUTORE

CITTA'

PAGINE

NOME- CODICE NUMEROLIBRERIA LIBRO COPIEDISPONIBILITA'

TITOLO COGNOMESCRITTO

AUTORE CODICE NOME COGNOME NAZIONALITA' SESSO

LIBRO CODICE-L TITOLO EDITORE PAGINE

LIBRERIA PARTITA-IVA NOME INDIRIZZO CITTA'

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.

8

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

Classificazione

Astrazione di classificazione

PERSONA

Generalizzazione

UOMO DONNA

Astrazione di generalizzazione Astrazione di aggregazione

PERSONA

Aggregazione

NOME COGNOMEETA' SESSO

(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.

9

STRUTTURA DI CLASSIFICAZIONE SIMBOLO

ENTITA' nome

GENERALIZZAZIONE

RELAZIONE nome

ATTRIBUTO

SEMPLICEnome

ATTRIBUTO

AGGREGATO nome nomenome

SOTTOINSIEME

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

10

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.

11

Fig. 3.10: Schema concettuale di un campionato di calcio

PARTITA

TRA

SQUADRA

GIRONEGIORNATANUMERO

GIOCA_IN_CASA

NOMECITTA'

ALLENATORE

DATAGIORNO

MESEANNO

DATANASCITA

GIORNOMESE

ANNO

NOMECOGNOMERUOLO

GIOCATORE

GIOCAIN

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

12

(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

13

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.

UOMO DONNA

MILITARE LAVORATRICEFA

SERVIZIO

PERSONA

NATA

NATO

RISIEDE

CITTA'

NOME

PROVINCIAREGIONE

NOME

COGNOME

ETA'

ALTEZZA

ETA'

ETA'

Figura 9 - Schema concettuale dell'esempio

14

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:

15

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.

Secondo schema Primo schema

COGNOMEPERSONA

CITTA'

NOME

ETA'

NATO

NOME

SESSOCITTA' NASCITA

PERSONA

UOMO DONNA

SITUAZIONE MILITARE

NOMECOGNOMEETA'

PROVINCIA-NASCITA

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.

16

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.

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

La strategia top-down

RAFFINAMENTI

La strategia bottom-up

17

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.

DATIANAGRAFICI

DATISULLE PERSONE

DATISUI 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.

18

(a) Un insieme di trasformazioni top-down

(b) Lo schema dopo la applicazione delle trasformaziomi

NATO

LAVORA

PERSONA

OCCUPATO NONOCCUPATO

PERSONA

STATO DATI SUICOMUNIESTERO

LUOGO

VIVE

Trasformazione primitiva

sulle persone

DATISULLE

PERSONE

PERSONA

OCCUPATONON

OCCUPATO

Trasformazione primitivasui luoghi

DATI SUI

LUOGHI

LUOGO

STATOESTERO

DATI SUICOMUNI

Trasformazione primitivasulle relazioni

RIFERITOA

NATO VIVE LAVORA

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.

19

POPOLAZIONE

NATO

LAVORA

PERSONA

OCCUPATO NONOCCUPATO

PERSONA

STATOCOMUNEESTERO

LUOGO

VIVE

NOME

COGNOME

SESSOETA'

NOME

HA LAVORATO?

NOME

REGIONE

(1,1)

(1,n)

(1,n)

(1,n)

(1,1)

(1,1)

IN

PROVINCIA

(1,n)

(1,1)

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à.

NOMECOGNOME

SESSOETA'

HA LAVORATO?OCCUPATO

NON

OCCUPATO

PERSONA

Figura 15 - Ristrutturazione degli attributi

20

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

21

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).

22

(b) Unica base dati centralizzata

(c) Base dati distribuita

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

(e) Base dati federataadaccoppiamento debole

(a) Basi di dati separate

DBMS

DBMS

DBMS

DBMS

DBMS

DBMS

(c) Base dati federata adaccoppiamento forte

DBMS

DBMS

DBMS

DBMS

DBMS

DBMS

DBMS

DBMS

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

Utenti

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

23

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”

24

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à.

Processi/ 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

25

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.

TR

ASF

ER

IME

NT

O F

ON

DI

A

EN

TI

LO

CA

LI

PE

R E

NT

I P

UIB

BL

ICI

CA

PIT

OL

I D

I SP

ESA

TRASPORTI COMUNICAZIONIPRODUZIONELAVOROCULTURAEDILIZIA

AMBIENTEISTRUZIONESANITA'SICUREZZA GIUSTIZIADIFESAAFFARI ESTERI

ASSICURAZIO- NE SOCIALE

CERTIFICA- ZIONE

SERVIZI SOCIALI E TERRITORIALI

STATISTICARISORSE DI SUPPORTO

RISORSE FINANZIARIE

RISORSE STRUMENTALI E IMMOBILIARI

RISORSE UMANE

PRO

TO

CO

LL

O

OR

GA

NI

CO

LL

EG

IAL

I

FISC

O

DO

GA

NE

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



RISORSE SERVIZI

SERVIZI GENERALI SERVIZI DIRETTISERVIZI SOCIALI ED ECONOMICI

STR

UM

EN

TI

AU

TO

ME

ZZ

I

BE

NI

IMM

OB

ILI

DIP

EN

DE

NT

I

FOR

MA

ZIO

NE

RA

PP

RE

SEN

TA

NZ

E

EN

TI

TE

RR

ITO

RIA

LI

CE

RT

IFIC

AZ

ION

I

CA

TA

STO

PR

EV

IDE

NZ

A

RE

LA

ZIO

NI

EST

ER

E I

N I

TA

LIA

RE

LA

ZIO

NI

ITA

LIA

NE

AL

L' E

STE

RO

AT

TIV

ITA

' GIU

RID

ICA

CR

IMIN

AL

ITA

'

SIC

UR

EZ

ZA

IN

TE

RN

A

ASS

IST

EN

ZA

SER

VIZ

IO S

AN

ITA

RIO

IST

RU

ZIO

NE

AM

BIE

NT

E

BE

NI

CU

LT

UR

AL

I

LA

VO

RO

AZ

IEN

DE

AG

RIC

OL

E

AZ

IEN

DE

IN

DU

STR

AL

I

TR

ASP

OR

TI

SERVIZI SOCIALI SERVIZI ECONOMICI

2/93

2/12

8/29

3

6/69

3/18

2

3/30

2/89

3/59

2/65

37/3

36

3/75

6/95

4/12

1 3/66

9/11

8

4/36

6/53 10

/76

6/76

6/13

0

5/56

6/15

5

3/13

4

8/21

3

10/1

00

9/11

8

3/53

9/11

2

10/1

78

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).

26

BeneSoggetto

Documento

Unitàorganizzativa

Riferimentoterritoriale

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.

Persona fisica

scuola

giustizia

affari esteri

lavoro

pensioni

Salute ed assistenza

fisco

politica

vitasociale

pensionato

di guerra

invalidità civile

Ricorrente per invalidità civile

164

91

161

520

162

163MI, MT, MD

lavoratore

disoccupato

studente

autonomodipendente

detenuto

contribuente

straniero

assistitocasalinga

candidato

volontario

italiano

residente all’estero

straniero

con handicap

condannato

in attesa di giudizio

borsista

segnalato

utente anagrafetributaria

Contribuente ufficio iva

appartenente catasto

Segretario comunale

tossicodipendente

Tossicodipendente segnalato

Alla ricerca di nuova occupazione

Alla ricerca di prima occupazione

Richiedente cittadinanza

Richiedente visto

1902

4

6

7

910

1 112

1 6

182 0 2 4 252 7

353637

393 8

40

45

474 8

5 1

53

54

5 5

59

6 3

64

65

68

7172

73

7480

8 2

87

88

89

93 9697

98

101

104105

108

110

120

131137

153

160

171

165

173

174

180

501

506507

515516

526

600

603

602

650

651

653

654

663

5

1 9

52

6 6

81

86

90

92

99

111

132

136

142

170

172

531

656

MAE, MF, MGG, MI,

MIBCA, MLP, MLPS, MT,MTN, MCE,MD, MURST

MAE, MURST, MPI

MAE, MGG,MI

MAE, MI, MLPS

MF, MTMGG, MI,MIBCA , MT, MTN

MI

MI, MS

601

2 1

109

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

27

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

28

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

29

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 dipendentepubblico

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.

matricolacognome

nomedata di nascita

codice fiscale

sesso

stipendioufficio


Figura 22 - Attributi iniziali dell'entità

30

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

nomedata di nascita

codice fiscale

sesso

matricolastipendio

ufficio


Lavoratore

Dipendente di uffici centrali Dipendente di uffici periferici

Candidato Aspirante ad impiegopubblico

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.

31


matricolacognome

nomedata di nascita

codicefiscale

sesso

Situazione familiare

Situazione amministrativa

Ufficio

Competenze e ritenute

Provvedimenti

Concorso

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.

32

Ufficio

Ufficio pagatore Ufficio gestore del personale Sede di lavoro

Sede estera

Comune

Ente o amministrazione

Ministero Ente locale Organismo scolastico


matricolacognome

nomedata di nascita

codicefiscale

sesso

Richiesta di trasferimento

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.

33

Competenza o ritenuta

Indennità di amministrazione

Stipendio base Indennità integrativa speciale Retribuzione individuale dianzianità

Tredicesima

Straordinario

Indennità aggiunta di famiglia

Assegno ad personam Assegno codificato

Indennità di funzione

Detrazione di imposta Ritenuta extraerariale Altra competenza o ritenutaRivalutazione monetariainteressi legali

Competenza accessoriaRiduzione di stipendio perscioperi o ritardi

Arretrato Competenza fissa

Indennità di incentivazione eproduttività

Altra competenza accessoria

Incentivo alla produttività Indennità per progettofinalizzato

Indennità budget di struttura

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

34

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 complessità (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%.

35

Ufficio pagatore Ufficio gestore delpersonale

Sede di lavoro

Sede estera

Ente o amministrazione

Ministero Ente locale Organismo scolastico

Ufficio

Comune


matricolcognomenome

data di codicefiscalesesso

Richiesta di trasferimento

Competenza o ritenuta

Indennità diamministrazione

Stipendio base Indennità integrativaspeciale

Retribuzione individuale dianzianità

Tredicesima

Straordinario

Indennità aggiunta difamiglia

Assegno ad personam Assegno codificato

Indennità di funzione

Detrazione di imposta Ritenuta extraerariale Altra competenza o ritenutaRivalutazione monetariainteressi legali

Competenza accessoriaRiduzione di stipendio perscioperi o ritardi

Arretrato Competenza fissa

Indennità di incentivazionee produttività

Altra competenza accessoria

Incentivo alla produttività Indennità per progettofinalizzato

Indennità budget di struttura

Figura 28 - Schema finale dello studio di caso

36

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.

3 - 2 Linguaggi per la modellazione dei dati - DIMES...

Documents

Transcript of 3 - 2 Linguaggi per la modellazione dei dati - DIMES...