RDBMS-Fondamenti

- I DATABASE -
ANALISI INIZIALE

Tutte le applicazioni software non banali, hanno l’esigenza di poter salvare e mantenere le informazioni. La memorizzazione di tali informazioni può essere più o meno complessa a seconda dei tipi di dati trattati, della loro frequenza di aggiornamento, del loro interesse ad essere facilmente disponibili e/o facilmente modificabili ed inoltre è strettamente connessa ai tipi di dati trattati e delle possibili relazioni che tra essi intercorrono. Se si proviene da una prima esperienza di programmazione, sicuramente, dopo aver appreso le fondamenta del linguaggio e scritto i primi programmi, si sentirà l’esigenza di scrivere applicazioni collegate ad una qualche fonte o archivio di dati. Quindi, sino dalle prime fasi di sviluppo e di analisi di un programma software, si evidenzia una forte esigenza riguardante la trattazione dei dati e le classiche domande che ci si porrà sono:

• Cosa vogliamo salvare o meglio quali tipi di dati vengono trattati?
• In che modo salviamo i dati?
• Chi manterrà aggiornati i nostri dati e in che modo?
• Chi leggerà i nostri dati? Tutti? Solo alcuni specifici utenti? Quale è la visibilità che desideriamo dare ai nostri dati?

Ebbene il metodo più diffuso per la memorizzazione dei dati è l’utilizzo di un database, meglio conosciuti come Database Management System (abbreviato in DBMS). In particolare, oggi vengono usati i Realtional Database Management System (abbreviato in RDBMS), in grado di memorizzare le relazioni e le connessioni fra i diversi dati.
Per eventuali approfondimenti in merito si rimanda a:
http://it.wikipedia.org/wiki/DBMS
http://it.wikipedia.org/wiki/Modello_relazionale

Attualmente esistono diversi motori di database disponibili, alcuni gratuiti ed Open Source, altri invece commerciali e purtroppo a pagamento.
Tra i più comuni possiamo sicuramente annoverare i seguenti che a mio avviso sono anche i più conosciuti ed i più utilizzati, sia per la loro diffusione sia anche per le loro performance tecniche:

PREMESSA

L’utilizzo dei database non è l’unico sistema con il quale sia possibile la memorizzazione persistente dei dati. Infatti nel corso degli anni si sono susseguite diverse e svariate metodologie atte a tale scopo. Oltre alle metodologie si sono evoluti anche i supporti di memorizzazione stessi. Abbiamo così assistito ad esempio all’evoluzione dei fogli di calcolo elettronici
(per esempio Microsoft Excel), algoritmi di ricerca, alberi binari, serializzazione degli oggetti etc. etc.

MA ALLORA PERCHE’ USARE UN RDBMS?

A mio avviso perchè:

• ridotto tempo di archiviazione delle registrazioni
• ridotto tempo di estrazione dei dati
• ordine di estrazione flessibile
• formato di presentazione flessibile
• accesso simultaneo multiutente alle registrazioni
• accesso remoto alle registrazioni: le registrazioni su carta vi costringono a stare dove queste sono conservate; le registrazioni in formato elettronico, invece, consentono l’accesso remoto e la loro trasmissione in formato elettronico.

Quindi la domanda principale che sorgerà ora è: «come è possibile progettare / realizzare un database»?

A NORMALIZZAZIONE DEI DATABASE:
REGOLE D’ORO

  Affinchè un database sia funzionale deve necessariamente soddisfare alcune regole basilari note anche come regole di normalizzazione.

PRIMA FORMA NORMALE (abbreviazione 1 NF): portare i dati in prima forma normale è abbastanza semplice. I dati devono essere in una struttura a tabella e devono soddisfare i seguenti criteri:

• Ogni colonna deve contenere un valore "atomico". Questo significa che ci sarà solo un valore per cella.
• Ogni colonna deve avere un nome unico.
• La tabella deve avere un insieme di valori che identificano univocamente le righe. Questa è conosciuta come chiave primaria della tabella.
• Due righe non possono essere identiche.
• Non sono ammessi gruppi ripetuti di dati.

SECONDA FORMA NORMALE: questa forma entra in gioco solo quando si hanno delle chiavi primarie su più colonne. Per passare in seconda forma normale, sarà necessario spostare in una tabella separata le righe che sono solo parzialmente dipendenti da una chiave primaria composta da più colonne. Quindi si può dire che una base dati è in 2NF (seconda forma normale) quando è in 1NF e per ogni tabella tutti i campi non chiave dipendono funzionalmente dall'intera chiave primaria e non da una parte di essa. Siccome la definizione sopra descritta mi sembra molto complessa, proviamo a descriverla con un breve esempio per chiarire meglio il concetto.Prendiamo come esempio la seguente tabella di dati:

Dovreste essere in grado di vedere che si presenta un'anomalia di inserimento se si aggiunge un'altra riga per BigCo Company. Si troverebbe il nome del direttore, Bill Hurt, ripetuto in un'altra riga, e questo non è bene. Si può portare questa tabella in 2NF rimuovendo le righe che sono solo parzialmente dipendenti dalla chiave primaria.
In questo caso, il direttore è dipendente solo dalla colonna company _name.
Non è dipendente dalla colonna company _location; quindi per passare in 2NF, spostiamo le righe che sono solo parzialmente dipendenti da una chiave primaria su più colonne, in una tabella separata.
La seconda forma normale non si applica alle tabelle che hanno una chiave primaria su singola colonna.

TERZA FORMA NORMALE:Una base dati è in 3NF (terza forma normale) se è in 2NF e per ogni dipendenza funzionale X -> Y è vera una delle seguenti condizioni:

• X è una superchiave della relazione
• Y è membro di una chiave della relazione

Ogni relazione può essere portata in 3NF.
Proviamo a tradurre il tutto....:)
La terza forma normale è quella che consolida la struttura del database. Questa regola impone che tutte le colonne che non sono chiavi devono essere reciprocamente indipendenti. Cioè, tutte le colonne che non sono chiavi primarie non devono eseguire nessun calcolo e nessuna operazione. Ogni tabella non uniforme dovrà essere scomposta in piccole tabelle.
In questo caso risulterà forse, più oneroso interfacciarsi al database e, sarà più ostico prelevare le informazioni, ma per questo problema potremmo creare delle viste adeguate, sfruttando così tutta la robustezza del database creato.
D'altro canto viene a migliorarsi la struttura del database riducendo duplicazioni di dati (quindi si risparmia spazio) ed al tempo stesso risulterà migliorata la robustezza della gestione per le operazioni di inserimento e modifica a scapito di una maggiore complessità di gestione (normalmente delegata agli analisti, agli sviluppatori e/o a personale dell'IT).

Post successivo