Database Management System - Basi di Dati

11
1 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu www.francescomanu.it · [email protected] Titolo: Database Management System - Basi di Dati di Francesco Manu

Transcript of Database Management System - Basi di Dati

1 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

Titolo: Database Management System - Basi di Dati

di Francesco Manu

2 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

INDICE:

1. Generalità ........................................................................................................ 3

2. DBMS - Database Management System ............................................ 4

2.1. Definizioni e terminologie ...................................................................................... 4 2.2. Funzioni tipiche ...................................................................................................... 4

2.3. Tipologie del DB ..................................................................................................... 4

2.4. Evoluzione del "File System" .................................................................................. 5

2.5. Ciclo di vita ............................................................................................................. 6 2.6. Linguaggi ad alto livello .......................................................................................... 7

2.7. Possibili criticità ..................................................................................................... 8

3. Assiomi di Armstrong ................................................................................ 8

3.1. Dipendenze funzionali ............................................................................................ 8

3.2. Assiomi ................................................................................................................. 10

3.3. Caso pratico .......................................................................................................... 10

4. Bibliografia ................................................................................................... 11

3 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

1. Generalità Il database (DB) è una collezione logicamente correlata e condivisa di dati, con lo scopo di soddisfare i fabbisogni informativi di una specifica organizzazione. I dati, congiuntamente con la loro descrizione, sono gestiti da un unico sistema, chiamato DBMS (Data Base Management System), che ne permette la gestione e ne regola gli accessi. Va inteso in due differenti modalità; ma di sostanziale importanza: - l'archivio a livello fisico (Hardware - HW) cioè il sistema con i supporti di memorizzazione, come gli hard disk che contengono i dati stessi e il processore per l'elaborazione di questi (database server) - l'archivio a livello logico cioè i dati strutturati (Software - SW) cioè il database management system (DBMS) ovvero quella vasta categoria di applicazioni che consentono la creazione, manipolazione, la gestione ed un' interrogazione efficiente dei dati. Inoltre un DBMS deve avere le seguenti caratteristiche: • Facilità di accesso • Indipendenza dalla struttura logica dei dati • Indipendenza dalla struttura fisica dei dati • Eliminazione della ridondanza • Eliminazione dell’inconsistenza • Integrità dei dati • Utilizzo da parte di più utenti • Controllo della concorrenza • Sicurezza dei dati Dobbiamo pensare che il dato (informazione) è necessario e fondamentale per qualsiasi pianificazione e per il controllo delle attività aziendali; nella quasi totalità degli ambienti lavorativi ed è indispensabile storicizzare e gestire i dati acquisiti. Talvolta le aziende sono costrette a gestire milioni e milioni di dati, e le normali basi di dati non offrono le soluzioni adeguate per la gestione di questi. Il fenomeno della corretta e fruibile gestione dei dati nasce proprio dall’enorme accumulo di questi e dalla pressante richiesta di utilizzarli attivamente per scopi che superino quelli, di routine, legati all’elaborazione giornaliera. Il campo di utilità dei sistemi, non è ristretto al dominio aziendale: esso spazia ulteriormente dall’area sanitaria a quella delle scienze naturali. Caratteristica comune a tutti questi campi è la necessità di strumenti di archiviazione e interrogazione per ottenere facilmente, e in tempi sempre più ridotti, dall’enorme quantità di dati immagazzinati nei database, informazioni di sintesi che permettano la valutazione di un fenomeno. Spesso il dato, fine a se stesso, può essere secondario o quanto meno non indica nulla; ma sempre di più diventa qualità sostanziale la velocità, l'integrazione ed il confronto tra gli stessi.

4 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

2. DBMS - Database Management System

2.1. Definizioni e terminologie

Database: Collezione di dati correlati Dati: Fatti noti che possono essere memorizzati ed avere un significato intrinseco Dominio: Parte del mondo reale che è memorizzata nel database Database Management System (DBMS): Pacchetto software o sistema per facilitare la creazione e la gestione di un database computerizzato

2.2. Funzioni tipiche

• Implementazione del modello logico sul sistema di elaborazione (definizione dei dati derivati dallo schema logico, definizione dei sottoschemi (viste), organizzazione fisica dei dati su supporti di memorizzazione) • Manipolazione e interrogazione sulla base di dati (inserimento modifica e cancellazione dei dati nel database, interfaccia tra programmi degli utenti e la base di dati, accesso ai contenti del database per le interrogazioni) • Controllo dell’integrità dei dati (integrità dei dati in relazione ai valori che possono assumere, integrità definite dall’utente) • Sicurezza e protezione (garanzia di sicurezza dei dati contro i danni causati da malfunzionamenti di componenti HW e SW, protezione dei dati da eventuali danneggiamenti offrendo la possibilità di attivare procedure di recovery, autorizzazione degli utenti che accedono alla base di dati, controllo degli accessi in modo concorrente e scalare) • Supporto alle transazioni (garanzia che tutte le operazioni che compongono la transizione siano eseguite) • Elaborazione ‘attiva’ per intraprendere azioni interne sui dati

2.3. Tipologie del DB

Gerarchico: Il modello gerarchico è particolarmente adatto per rappresentare situazioni nelle quali è possibile fornire all’insieme dei dati una struttura nella quale ci sono entità che stanno in alto e entità che stanno in basso, secondo uno schema ad albero, nel quale i nodi rappresentano le entità e gli archi rappresentano le associazioni. Reticolare: Nel modello reticolare le entità rappresentano i nodi e le associazioni rappresentano gli archi di uno schema a grafo orientato: si tratta di un’estensione del modello di albero gerarchico, essendo consentite anche associazioni tra entità che stanno in basso, e non solo dall’alto verso il basso come avviene nel modello precedentemente analizzato.

5 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

Relazionale: Il modello relazionale rappresenta il database come un insieme di tabelle. Esso viene considerato attualmente il modello più semplice ed efficace, perché è più vicino al modo consueto di pensare i dati, e si adatta in modo naturale alla classificazione e alla strutturazione dei dati.

2.4. Evoluzione del "File System"

I DBMS sono sostanzialmente strumenti software che gestiscono in maniera efficace ed efficiente le informazioni contenute in un database. Prima dello sviluppo di questi DBMS l’approccio che veniva applicato al problema dell’archiviazione prevedeva l’uso diretto delle strutture del File System (vedi

imm. 1).

imm. 1 "File system"

Nella soluzione file system, le applicazioni accedono direttamente agli archivi, quindi ognuna deve conoscere la struttura interna degli archivi e le relazioni tra i dati e deve evitare la duplicazione degli stessi, con un'interrogazione singola. Inoltre la non volatilità dei dati e la gestione degli accessi contemporanei di più applicazioni agli archivi viene relegata a strati software non specializzati per tali compiti, quali il sistema operativo. La caratteristica saliente che differenzia un sistema per la gestione di database (DB) è la presenza di un componente specializzato a tale ruolo. (vedi imm. 2).

App - A

App - B

App - C DB

DB

DB

6 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

fig. 2 "DBMS"

La figura 2 mostra come le applicazioni rivolgono si al DBMS con le proprie richieste di accesso alla base di dati, il quale gestisce i dati svincolando le applicazioni da tale onere. Quindi il DBMS è un modulo, specializzato nella gestione del DB; a cui tutte le applicazioni si rivolgono per accedere ai dati. Si ottiene così un triplice scopo: da una parte le funzionalità di gestione del database sono raggruppate in un unico insieme, dall’altra le applicazioni risultano alleggerite e quindi più veloci da realizzare e, soprattutto, nessuna potrà effettuare operazioni scorrette sul database, generando ed ancor peggio moltiplicando errori.

2.5. Ciclo di vita

La progettazione di una base dati costituisce solo una componente del processo di sviluppo, all’interno di una organizzazione, di un sistema informativo complesso e va quindi inquadra a in un contesto più ampio, quello del ciclo di vita dei sistemi informativi. Come illustrato (vedi imm. 3), il ciclo di vita di un sistema informativo comprende, generalmente, le seguenti attività.

imm. 3 "Ciclo di vita di un sistema informativo"

App - A

App - B

App - C

DBMS

DB

Fattibilità Requisiti Progettazione

Funzionamento Collaudo Implementazione

7 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

Studio di fattibilità: Serve a definire, in maniera per quanto possibile precisa, i costi delle varie alternative possibili e a stabilire le priorità di realizzazione delle varie componenti del sistema. Raccolta e analisi dei requisiti: Consiste nella individuazione e nello studio delle proprietà e delle funzionalità che il sistema informativo dovrà avere. Questa fase richiede un'interazione con gli utenti del sistema e produce una descrizione completa, ma generalmente informale, dei dati coinvolti (anche in termini di previsione sulla loro frequenza). Vengono inoltre stabiliti i requisiti software e hardware del sistema informativo.

Progettazione: Si divide generalmente in progettazione dei dati e progettazione delle applicazioni. Nella prima si individua la struttura e l’organizzazione che i dati dovranno avere, nell’altra si definiscono le caratteristiche dei programmi applicativi. Le due attività sono complementari e possono procedere in parallelo o in cascata. Le descrizioni dei dati e dei programmi prodotte in questa fase sono formali e fanno riferimento a specifici modelli.

Implementazione: Consiste nella realizzazione del sistema informativo secondo la struttura e le caratteristiche definite nella fase di progettazione. Viene costruita e popolata la base di dati e viene sviluppato il codice dei programmi. Validazione e collaudo: Serve a verificare il corretto funzionamento e la qualità del sistema informativo. La sperimentazione deve prevedere, per quanto possibile, tutte le condizioni operative. Funzionamento: In questa fase il sistema informativo diventa operativo e richiede, a meno di malfunzionamenti o revisioni delle funzionalità del sistema, solo operazioni di gestione e manutenzione.

2.6. Linguaggi ad alto livello

Un DBMS supporta tradizionalmente tre tipi di linguaggi, distinti in base alle funzioni eseguite sui dati. Tale distinzione è dovuta alla separazione delle funzioni dichiarative da quelle di elaborazione e di controllo, a differenza di quanto avviene in un comune linguaggio di programmazione. Il motivo è che, mentre in un normale programma i dati esistono solo mentre esso è in esecuzione, in un DB i dati sono permanenti e possono essere dichiarati una volta per tutte. Per la definizione dello schema logico del database viene usato il DDL (Data Definition Language).

Esso non è un linguaggio procedurale, piuttosto è una notazione per definire le informazioni e le relazioni intercorrenti fra esse, secondo un particolare modello dati. Per le operazione di interrogazione ed aggiornamento dei dati quali inserimento, modifica, cancellazione, e così via, viene usato il DML (Data Manipulation Language). Esso può essere disponibile come linguaggio a se stante o come un insieme di istruzioni richiamabili da un linguaggio di programmazione che svolge il ruolo di linguaggio host.

8 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

Per le operazioni di controllo dei dati, la gestione degli utenti, l’assegnazione dei diritti di accesso, l’ottimizzazione del funzionamento del DBMS viene usato il DCL (Data Control Language). Solitamente il DML è utilizzato dai programmatori che realizzano i programmi applicativi destinati agli utenti finali, mentre il DCL e il DDL sono usati dal DBA (Data Base Administrator), la persona o il gruppo di persone che partecipa alla progettazione e al mantenimento del database. Un’altra figura che partecipa alla progettazione del DB è il DA (Data Administrator), figura di più alto livello rispetto al DBA, che si occupa dei dati come patrimonio del sistema informativo aziendale, indipendentemente dalla loro localizzazione all’interno di un DB.

2.7. Possibili criticità

I DBMS sono prodotti costosi anche solo nella manutenzione e gestione ordinaria, complessi e abbastanza diversi da molti altri strumenti informatici. La loro introduzione comporta quindi notevoli investimenti, diretti (acquisto del prodotto) e indiretti (acquisizione delle risorse hardware e software necessarie, conversione delle applicazioni, formazione del personale). I DBMS forniscono, in forma integrata, una serie di servizi, che sono necessariamente associati ad un costo. Nei casi in cui questi servizi non sono tutti necessari, è difficile scorporare i servizi effettivamente richiesti dagli altri, e ciò può comportare una riduzione di prestazioni.

3. Assiomi di Armstrong

3.1. Dipendenze funzionali

Un tema fondamentale è il concetto di dipendenza funzionale. Le sue principali proprietà, in particolare si introdurranno alcuni strumenti formali per la manipolazione di insiemi di dipendenze funzionali e per l’eliminazione di ridondanza da tali insiemi (calcolo della copertura minima). Definizione (Dipendenza funzionale) Sia data una relazione sullo schema e siano . Si dice che soddisfa la dipendenza funzionale se `e verificata la seguente condizione:

Si dice inoltre che la dipendenza funzionale è valida sullo schema se per ogni istanza di risulta che soddisfa . La dipendenza funzionale è un vincolo di integrità, ovvero è soddisfatta da tutte le istanze della base di dati.

9 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

Vediamo alcune dipendenze funzionali valide sullo schema della seguente tabella:

MATR INSEGN COGN NOME DATA_N VOTO DATA_AP 00100 Basi Rossi Paolo 01.01.1980 25 17.7.03 00200 Progr. Bianchi Mario 10.10.1981 27 18.06.04 00100 Reti Rossi Paolo 01.01.1980 30 5.9.04

Possiamo osservare che: • la dipendenza indica che gli attributi e hanno ”vita comune” e che l’attributo determina gli altri; • la dipendenza indica che gli attributi e determinano la data e il voto dell’esame; • infine, la dipendenza viene detta inutile o banale, infatti è ovvio che se due tuple sono uguali sugli attributi e allora saranno uguali anche sul singolo attributo . Inoltre possiamo osservare come, a partire da alcune delle dipendenze funzionali riconosciute valide, se ne possano identificare delle altre. Diremo che quest’ultime sono logicamente implicate dalle prime, denotando tale relazione con il simbolo , dove perciò significa che la dipendenza funzionale è logicamente implicata da (dove è un insieme di dipendenze funzionali). Per quanto appena detto segue che: ed ovviamente che: quindi è superchiave per la tabella RISULTATO, in quanto determina tutti gli attributi della tabella. Abbiamo notato quindi come sia possibile, partendo da un insieme di dipendenze funzionali, ”derivare” da esso altre dipendenze funzionali per implicazione logica. Introduciamo ora un insieme di regole di inferenza che consentono di calcolare facilmente le dipendenze funzionali implicate da altre dipendenze funzionali. Tali regole si basano su un insieme di assiomi detti assiomi di Armstrong. Tale insieme di assiomi gode delle proprietà di correttezza e completezza. La correttezza permette di affermare che tutto ciò che viene derivato da un insieme di dipendenze funzionali tramite

10 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

assiomi di Armstrong è effettivamente derivabile da (in altre parole non è possibile dedurre alcuna falsa dipendenza). La completezza permette invece di affermare che, dato un insieme di dipendenze funzionali, tramite gli assiomi di Armstrong è possibile individuare l’insieme di tutte le dipendenze logicamente derivabili da .

3.2. Assiomi

Dato un insieme di dipendenze funzionali su un insieme di attributi si definiscono i seguenti assiomi: à

3.3. Caso pratico

Sia una relazione sull'insieme di attributi e siano . Verificare la veridicità nel caso di e , allora ? I caso affermativo fornire una derivazione di da e con l'utilizzo degli assiomi di Armstrong. --- SOLUZIONE --- La regola di inferenza e' vera. Siano , con Allora:

11 Francesco Manu Skype: manufrancesco · http://it.linkedin.com/in/francescomanu

www.francescomanu.it · [email protected]

4. Bibliografia

Analisi, progettazione e sviluppo di una warehouse per un'azienda ospedaliera - Dossi

Ullman J. D. - Basi di dati e basi di conoscenza – Jackson, 1991 Yourdon E. – Analisi strutturata dei sistemi. Concetti e metodi. – Jackson, 1990.

Costal D., Teniente E., Urpì T., Farrè C. – Handling Conceptual Model Validation by Planning

Teoria della Normalizzazione - Alberto Belussi