sabato 11 giugno 2011

La progettazione di una base di dati (seconda parte)

La progettazione logica realizza a partire da uno schema concettuale uno schema logico, aggiungendo altri dettagli allo schema finale. Prima di effettuare la traduzione dallo schema concettuale a quello logico è necessario compiere un ulteriore passaggio, solitamente detto di ristrutturazione. Ciò è indispensabile poiché non tutti i costrutti usati dal modello ER hanno un equivalente per lo schema logico. Basti pensare al costrutto usato dal modello ER per le generalizzazioni, quest'ultimo, infatti, va ridisegnato mettendo in relazione le entità figlie con l'entità padre. Per i motivi detti sopra suddivideremo la progettazione logica in due fasi: ristrutturazione e traduzione dello schema concettuale.
Prima di analizzare in dettaglio le due fasi dette sopra occorre affrontare un importante discorso ovvero quello sulle prestazioni offerte dallo schema ER. In questa fase, infatti, vanno analizzati alcuni parametri prestazionali come l'occupazione in memoria dei dati e il costo di una operazione (inteso come numero medio di entità e associazioni che il sistema informativo necessita per realizzare una operazione). Per stimare i parametri detti sopra abbiamo bisogno di altre informazioni:
  • volume dei dati: inteso sia come numero di entità e relazioni che compongono lo schema che come dimensione (massima) di ogni attributo;
  • caratteristiche delle operazioni: richiede la suddivisione delle operazioni per tipo (operazione interattiva, operazione batch) e una stima della frequenza per le operazioni del sistema informativo (anche in relazione ai dati che essa coinvolge);
Le informazione viste sopra sono solitamente riassunte all'interno di tabelle: tavola delle operazioni e tavola dei volumi. Nella tavola delle operazioni si riporta per ogni operazione il tipo e la frequenza prevista o stimata. Nella tavola dei volumi si riporta, invece, il numero medio di partecipazioni delle occorrenze di un'entità con le occorrenze di un'associazione (questo parametro è evidentemente condizionato dalla cardinalità delle associazioni).
Per la fase di ristrutturazione occorre applicare sullo schema concettuale i seguenti passi:
  • analisi delle ridondanza: per ridondanza si intende la presenza di un dato all'interno dello schema che può essere ricavato da altri dati dello schema. Occorre analizzare gli attributi di ogni entità e stabilire se questi siano fra loro dipendenti, eliminando quindi quelli derivabili. La scelta dell'attributo da eliminare va fatto considerando le operazioni sui dati. Per scongiurare la ridondanza degli attributi vanno analizzati anche gli attributi delle entità in relazione. All'interno di uno schema possono essere presenti anche ridondanze di associazioni, l'analisi va sempre condotta considerando le tavole dette prime;
  • eliminazione delle generalizzazioni: occorre tradurre le generalizzazione effettuando a seconda dei casi l'accorpamento delle entità che vi partecipano. Le entità figlie possono essere accorpate nell'entità padre, in tal caso l'entità padre prenderà gli attributi delle entità figlie (utile quando la distinzione fra le entità figlie e padre e degli attributi non incide sul costo delle operazioni). Altra possibilità è quella di accorpare l'entità padre nelle entità figlie, in tal caso le entità figlie prenderanno gli attributi dell'entità padre e parteciperanno alle relazioni dell'entità padre (questa soluzione è possibile solo se la generalizzazione è totale, altrimenti le occorrenze dell'entità padre non sarebbero rappresentate nelle occorrenze delle entità figlie). L'ultima possibilità per eliminare le generalizzazioni prevede la sostituzione del costrutto con associazioni fra entità padre e entità figlie (da usare quando la generalizzazione non è totale e conviene tenere nello schema, a causa di alcune operazioni, tutte le entità);
  • partizionamento e/o accorpamento di entità e/o associazioni: il partizionamento di una entità è utile quando la stessa contiene troppi attributi e le operazioni accedono, solitamente, a un sottoinsieme di tali attributi (decomposizione verticale). Anche l'eliminazione di un attributo multi-valore avviene attraverso il partizionamento dell'entità. L'attributo multi-valore viene messo in una nuova entità che va quindi messa in relazione con l'entità di partenza. Se le operazioni del sistema informativo insistono su insieme di attributi appartenenti a due o più entità si può pensare a un'accorpamento degli stessi all'interno di un'unica entità;
  • scelta degli identificatori primari: ha lo scopo di stabilire le chiavi primarie per le entità dello schema. Meglio scegliere un identificatore costituito da pochi attributi, possibilmente interno all'entità;

(generalizzazione)

(soluzione 1)

(soluzione 2)

(soluzione 3)

Lo schema concettuale ristrutturato ci permette di avviare, finalmente, la traduzione verso uno schema logico equivalente. Le regole per la traduzione prevedono che per ogni entità dello schema ci sia una relazione (in questo contesto bisogno si intende per relazione la rappresentazione tabellare dei dati, organizzati dunque su righe e colonne) avente lo stesso nome, gli stessi attributi dell'entità e come chiave primaria il suo identificatore. Anche le associazioni vengono tradotte in relazioni, gli attributi e il nome della relazione saranno gli attributi e il nome dell'associazione, la chiave primaria sarà composta dagli identificatori delle entità che partecipano all'associazione.
In base alla cardinalità delle entità partecipanti a una relazione è possibile avere uno dei seguenti casi di traduzione: molti a molti, uno a molti, uno a uno. Nella traduzione molti a molti ogni entità e ogni associazione viene tradotta in una relazione. L'informazione rappresentata dal seguente schema concettuale:


può essere rappresentate dal seguente modello:

studente(matricola, nome, cognome)
esame(nome,crediti)
sessione(studente, esame, voto, data)

con i vincoli di integrità referenziale fra gli attributi studente ed esame della relazione sessione e gli attributi matricola e nome. Nella traduzione uno a molti occorre prestare attenzione alla cardinalità delle occorrenze. Se la cardinalità minima di una occorrenza è 0 possono esserci più traduzioni (la scelta ricadrà su quella che garantisce le prestazioni migliori), in tal caso la traduzione è come il caso già analizzato sopra (ci sarà, pertanto, una relazione per ogni entità o associazione). Se la partecipazione di un'entità all'associazione è obbligatoria la traduzione tenderà ad accorpare in essa anche gli attributi dell'associazione. L'informazione rappresentata dal seguente schema concettuale:


può essere rappresentata dal seguente modello:

impiegato(cf, nome, cognome, settore, data)
settore(nome, città)

con il vincolo di integrità referenziale fra l'attributo settore della relazione impiegato e l'attributo nome della relazione settore. Nella traduzione uno a uno possiamo avere due casi, anche in questo caso occorre analizzare la cardinalità minima delle singole partecipazione. Possiamo avere una partecipazione obbligatoria oppure opzionale. Per la partecipazione obbligatoria sono possibili più traduzioni del modello poiché gli attributi dell'associazione possono essere accorpati in una qualunque delle relazioni. L'informazione rappresentata dal seguente schema concettuale:


può essere rappresentata dal seguente modello:

utente(login, nome, cognome, upgrade, stats)
upgrade(codice, nome, descrizione)

oppure dal modello:

utente(login, nome. cognome)
upgrade(codice, nome, descrizione, utente, data)

Per la partecipazione opzionale va invece escluso uno dei possibili modelli (essendo la cardinalità minima di una partecipazione pari a 0). L'informazione rappresentata dal seguente schema concettuale:


può essere rappresentata dal seguente modello:

utente(login, nome, cognome)
upgrade(codice, nome, descrizione, utente, data)

In seguito analizzeremo un esempio completo di progettazione di una base di dati, dal modello concettuale al quello fisico.

mercoledì 8 giugno 2011

Arduino: leggere i valori dal microfono

Il microfono è stato uno dei primi trasduttori inventati dall'uomo, la pressione delle onde sonore che impatta sulla superficie del microfono viene trasformata in un segnale elettrico. Se avete una vecchia radio oppure un telefono cellulare da rottamare potete procurarvi un piccolo microfono a capsula! Possiamo provarne il funzionamento misurandone la resistenza interna con un multimetro, soffiando oppure parlando nel microfono la sua resistenza interna aumenterà. Il segnale generato dal microfono risulta debole e va quindi amplificato prima di poterne apprezzare i valori con Arduino. Nel datasheet del circuito integrato LM386 ho trovato lo schema di un semplice amplificatore:


Se vogliamo utilizzare questo circuito per leggere il segnale generato da un microfono dobbiamo usare l'uscita Vout del condensatore C3 come pin di ingresso per la nostra scheda Arduino. In fase di realizzazione, per favorire il setup del circuito, ho sostituito i resistori R1 ed R2 con due resistori variabili. Il condensatore C2 permette di ottenere un guadagno pari a 200 (se omesso il guadagno scende a 20).


Il led sul pin numero 13 (variabile LED) si accenderà non appena il segnale generato dal microfono supera un valore limite (variabile NOISE_MARGIN). Il segnale di input generato dal microfono (la sua versione amplificata) è mappato sul pin (analogico) numero 0 (variabile MIC) ed è aggiornato ogni 20ms circa (variabile SAMPLING). La frequenza di campionamento e la soglia minima di rumore possono essere modificate solo all'interno del codice sorgente che trovate qui. Alcune regolazioni in fase di setup possono essere fatte attraverso i resistori R1 ed R2 che regolano il volume in ingresso.
int MIC=0;
int LED=13;
int NOISE_MARGIN=489;
int SAMPLING=10;

int value=0;

void setup() {
pinMode(MIC,INPUT);
pinMode(LED,OUTPUT);
Serial.begin(9600);
}

void loop() {
value=analogRead(MIC);
if(value>NOISE_MARGIN) digitalWrite(LED,HIGH);
else digitalWrite(LED,LOW);
Serial.println(value);
delay(SAMPLING);
}
Spero di aver disegnato bene lo sketch per Arduino, se avete problemi scrivete. Ecco un video del circuito in funzione:

venerdì 3 giugno 2011

Xubuntu: risolvere i problemi con il tema Ambiance

Ambiance è il nuovo tema usato di defautl in Ubuntu 11.04 (Natty Narwhal), nulla ci vieta di usarlo anche in Xubuntu. Alcune icone, tuttavia, possono apparire in modo non uniforme al tema in questione:


Se ho capito bene il problema sembra essere causato da un uso errato dei nomi dei vari widget all'interno del file gtkrc (ogni tema ha un file gtkrc). Per risolvere questo problema date il comando sudo mousepad /usr/share/themes/Ambiance/gtk-2.0/gtkrc per editare il file detto prima, aggiungete in coda al file queste righe:
#Aggiunti da me
widget "*Panel*" style "menubar"
class "*Panel*" style "infobar"
widget_class "*Panel*" style "panel_task_button"
widget "*panel*" style "panel_task_button"
class "*panel*" style "infobar"
widget_class "*panel*" style "darkmenu"
Non dimenticate di salvare le modifiche. Riavviate il sistema operativo oppure solo il pannello, con i comandi sudo killall xfce4-panel && xfce4-panel &. Il risultato dovrebbe essere il seguente: