11) pianificazione sistemi informativi: patrimonio dei dati

IL “PATRIMONIO” DI DATI E LE BASI DI DATI
Dopo aver chiarito quali tipi o classi di informazione sono trattati dal S.I.: ­ quali tipi di dati per rappresentare tali informazioni? ­ dove li memorizziamo? ­ in quali database e con quali strutture? PIANIFICARE IL “PATRIMONIO” DI DATI E LE BASI DI DATI
Il patrimonio dei dati • L’insieme dei dati memorizzati e gestiti nel S.I. • Il “valore” del patrimonio di dati: – è determinato dalla capacità di rispondere alle esigenze informative di chi vi fa ricorso – Dipende da: • Completezza dei dati rispetto ai problemi/obiettivi • Tempistica adeguata • Fruibilità/accessibilità • Omogeneità di rappresentazione • Gli strumenti e le modalità di archiviazione elettronica del patrimonio dei dati dovrebbero essere scelti e progettati in modo da garantire gli aspetti prima indicati
PROGETTAZIONE DELLE BASI DI DATI • Progettazione concettuale – rappresentazione dei dati secondo schemi di interesse per l’utente (quali dati, che relazione, come organizzarli) • progettazione logica – rappresentazione nel database informatico (quali strutture di dati, formati, ecc.) • progettazione fisica – rappresentazione nei termini delle unità fisiche di elaborazione (quali unità, come sono scritti e letti i dati, ecc.)
dato significato origine Unità di misura e/o processo di elaboraz. codifica
Il catalogo dei dati Esempio: codice prodotto (catena di supermercati) • SIGNIFICATO: identifica un tipo di articolo o una sua confezione particolare • ORIGINE: lettura codice a barre o immissione a mano • PROCESSO DI ELABORAZ: memorizzazione diretta dopo validazione • UNITA’ DI MISURA/CODIFICA: codice EAN
Esempio: costo del prodotto (catena di supermercati) • SIGNIFICATO: costo medio per unità di articolo • ORIGINE: costi dei lotti di prodotto acquistati • PROCESSO DI ELABORAZIONE: media del costo unitario rispetto ai lotti acquistati in un periodo prefissato • UNITA’ DI MISURA/CODIFICA: euro per unità
Catalogo dei dati e data dictionary • Catalogo dei dati ­ dal punto di vista degli utenti – inventario dei dati presenti nel patrimonio aziendale, significato di ciascun dato, modalità con cui può essere reperito, ecc. • data dictionary ­ per i programmatori e gestori del sistema: – definisce come i dati sono classificati nel o nei vari database, con quali attributi, quali sono specificatamente le procedure che li elaborano, da quali altri dati, ecc.
DOVE MEMORIZZARE I DATI? Possibili approcci alla memorizzazione e relative architetture
ESEMPIO il sistema di casse automatiche in un punto vendita • Ogni cassa deve accedere a un database contenente il listino prezzi dei prodotti (L) • Ogni cassa deve memorizzare gli scontrini in un apposito database (S) • I database degli scontrini (S) devono poi essere raccolti insieme • Nel caso di aggiornamenti dei prezzi, i database dei listini (L) devono essere aggiornati
Alternativa 1 cassa1 cassa2 cassa3 cassa4 L S1 L S2 L S3 L S4 = connessione occasionale o a cadenza stabilita
L S1 SISTEMA CENTRALE (?) Alternativa 2 cassa1 cassa2 cassa3 cassa4 S1 S2 S3 S4 = connessione L S1 occasionale o a cadenza stabilita = connessione in tempo reale
SISTEMA CENTRALE Alternativa 3 cassa1 cassa2 cassa3 L = connessione in tempo reale
S SISTEMA CENTRALE cassa4 Alternativa 4 …
Quale alternativa scegliere? Con che criteri? • Tecnici – Vincoli dei sistemi esistenti (compatibilità) – Coerenza con le altre funzionalità/sistemi implementati o che si intente realizzare – Fattibilità tecnica della soluzione • Economici (costi) – Costi delle attrezzature – Costi di gestione • Organizzativi – coerenza con le procedure / processi – Competenze e mansioni degli operatori • In relazione agli obiettivi specifici – Ad es.: maggiore efficienza? Minori costi? Rapidità di risposta/servizio al cliente?
Dal punto di vista tecnico: due approcci opposti alla memorizzazione dei dati
Database distinti – Ogni applicazione (programma/software) lavora sui propri archivi di dati a) Sia nel caso di sistemi distinti e scollegati tra loro b) Sia nel caso di unico sistema centrale – I singoli archivi sono organizzati in modo specifico – PRO: Facilità di progettazione e efficacia con riferimento al singolo programma – CONTRO: Frammentazione dei dati, ridondanze, incoerenze
Caso A Sistema operativo Sistema operativo Sistema operativo Programma A Programma B Programma C Caso B
Unico database centralizzato – Archivio unico (database centralizzato) – Tutte le applicazioni (programmi/software) attingono dallo stesso database centrale – Un software di gestione del database (DBMS: DataBase Management System) gestisce struttura e accessi del database – PRO: Patrimonio dei dati unitario e non frammentato – PRO: Limitate ridondanze; coerenza dei dati archiviati – CONTRO: Necessaria attenzione nello stabilire i diritti di accesso al database – CONTRO: Elevata complessità progettuale e di gestione
DBMS • Può essere usato da più applicazioni contemporaneamente • Organizza e gestisce i dati secondo un modello unitario e coerente • Risolve i problemi di • Integrità • Ridondanza • Sicurezza di accesso • Indipendenza dei dati dalle applicazioni
DBMS Data manipulation Language (DML) Data description Language (DDL)
Software di manutezione del database Architetture, piattaforme, tecnologie: scelta e dimensionamento
ELEMENTI CHE ANALIZZIAMO • L’ambiente hardware e software – componenti, tipologie e categorie di appartenenza, ecc. • L’architettura – come combinare insieme parti e moduli (ad es. architettura di una rete • Il dimensionamento del sistema – quanta capacità, quanta potenza di calcolo, quanti terminali, ecc.
AMBIENTE HW E SW le “ grandi” opzioni • sistemi standard … (es. Windows) – elevata compatibilità tra sw e hw di fornitori diversi – facile interconnessione tra sistemi e applicazioni – generalità d’uso • …. o sistemi non standard? – elevata specificità – difficile intercambiabilità ­ generalità d’uso ­ interoperabilità Sistemi standard ­ specificità ­ non interoperabilità
Sistemi non standard AMBIENTE HW E SW le “ grandi” opzioni • sistemi proprietari ….. (es. Windows) – proprietà e controllo (tecnico ed economico) del codice interamente nelle mani del fornitore (“copyright”) • … o sistemi “open source”? …. (es. Linux) – diritto dell’utente a disporre dei codici sorgente, a modificare e adattare il software, a utilizzarlo commercialmente senza vincoli economici (“copyleft”) ­non disponibilità del codice ­adattamenti solo richiedendoli al fornitore Sistemi proprietari ­disponibilità del codice ­Possibilità di personalizzazioni
Sistemi Open source AMBIENTE HW E SW: opzioni e combinazioni
• Best of Breed • assemblaggio di componenti (sw, hw) di fornitori diversi scelti per ottenere “il meglio” di ogni funzione specifica • necessaria la piena compatibilità • complessità di configurazione • Suite complete • sistemi realizzati da un unico fornitore • elevata compatibilità, ma non necessariamente prestazioni sempre ottimali per tutte le funzioni • Sistemi ad hoc • sistemi progettati per il caso specifico L’ARCHITETTURA • Architetture centralizzate – un sistema centrale (dove risiedono i dati) cui sono connesse unità “passive” (terminali) • Architetture distribuite – varie unità autonome di elaborazione (collegate o meno)
Dimensionamento del sistema: “ capacity planning” • Scegliere la dimensione (in termini fisici o prestazionali) che il sistema deve garantire per svolgere le funzioni per cui è progettato
Un tipico modo di procedere: “volumi” delle attività (ad es.: numero di ordini settimanali ricevuti) “volumi” delle applicazioni informatiche (ad es.: numero di operazioni di elaborazione per ciascun ordine, dimensione dei dati da memorizzare per ciascun ordine, ecc.) Dimensioni del sistema (ad es.: capacità/velocità di elaborazione, capacità di memoria, ecc.)