Introduzione ai database SQL locali

La funzionalità di database SQL locale di AIR può essere utilizzata in tutti i casi in cui si desideri memorizzare i dati delle applicazioni sul computer locale dell'utente. Adobe AIR dispone di vari metodi per la memorizzazione locale dei dati, ciascuno dei quali presenta vantaggi diversi. Di seguito suggeriamo alcuni impieghi possibili dei database SQL locali nelle applicazioni AIR.

• Nel caso delle applicazioni la cui funzione principale è la gestione dei dati, ad esempio le rubriche, è possibile utilizzare un database per memorizzare i dati fondamentali dell'applicazione.

• Nel caso delle applicazioni la cui funzione principale è la gestione dei documenti che vengono creati dagli utenti a scopo di memorizzazione e magari condivisione, ciascun documento può essere salvato come file di database in un percorso designato dall'utente. (Tenete tuttavia presente che, a meno che il database sia crittografato, qualsiasi applicazione AIR è in grado di aprire il file di database. La crittografia è consigliata per i documenti potenzialmente riservati).

• Nel caso delle applicazioni che esistono su una rete, il database può essere impiegato per la memorizzazione di una cache locale di dati delle applicazioni o per la memorizzazione temporanea di dati nei momenti in cui la rete non è disponibile. È possibile poi creare un metodo che garantisca la sincronizzazione del database locale con i dati memorizzati centralmente sulla rete.

• In tutti i tipi di applicazioni, il database può venire utilizzato per memorizzare per ciascun utente le impostazioni dell'applicazione come le opzioni utente o le informazioni sulle dimensioni e la posizione della finestra principale.

I database SQL locali di Adobe AIR individuali vengono memorizzati sotto forma di file singolo nel file system del computer. Il runtime comprende il motore di database SQL che gestisce la creazione e la struttura dei file di database e la manipolazione e il recupero dei dati da tali file. Il runtime non specifica le modalità di memorizzazione o la posizione dei dati del database nel file system; ciascun database viene invece memorizzato interamente all'interno di un solo file. È l'utente a specificare la posizione all'interno del file system in cui il file di database viene memorizzato. Una singola applicazione AIR può accedere a un singolo database o a più database diversi (cioè a più file di database separati). Dal momento che il runtime memorizza ciascun database come file singolo nel file system, è possibile scegliere la posizione del database secondo le esigenze del design dell'applicazione in oggetto e i vincoli di accesso ai file in vigore nel sistema operativo. A ciascun utente può essere assegnato un file di database separato per i suoi dati specifici o, in alternativa, è possibile fare sì che tutti gli utenti dell'applicazione abbiano accesso a un file di database che risiede su un solo computer, al fine di condividere i dati. Poiché i dati sono locali per un solo computer, essi non vengono automaticamente condivisi dagli utenti su computer diversi. Il motore di database SQL locale non fornisce funzioni che eseguano le istruzioni SQL nell'ambito di un database remoto o basato su un server.

Il database relazionale è un metodo che rende possibile la memorizzazione e il recupero dei dati su un computer. I dati sono organizzati in tabelle: le righe rappresentano i record (o gli elementi) e le colonne (dette talvolta “campi”) dividono ciascun record nei singoli valori che lo costituiscono. Ad esempio, un'applicazione rubrica può contenere una tabella “amici”. Ciascuna riga della tabella rappresenta un amico memorizzato nel database. Le colonne della tabella contengono dati come il nome, il cognome, la data di nascita e così via. Per ciascuna riga (amico) della tabella, il database memorizza un valore diverso per ciascuna colonna.

I database relazionali sono progettati in modo da essere in grado di gestire dati complessi in cui un elemento è associato o correlato a elementi di un altro tipo. Nei database relazionali, i dati che hanno una relazione “uno a molti”, cioè in cui un singolo record può essere correlato a più record di tipo diverso, devono venire divisi fra tabelle diverse. Supponiamo ad esempio di volere che l'applicazione rubrica memorizzi più numeri di telefono per ciascun amico: si tratta di una relazione uno a molti. La tabella "amici" conterrà tutte le informazioni personali di ciascun amico. Una tabella separata, “numeri di telefono”, conterrà tutti i numeri di tutti gli amici.

Oltre a memorizzare i dati degli amici e i numeri di telefono, ciascuna tabella necessiterà di un gruppo di dati che tengano traccia della relazione fra le due tabelle al fine di far corrispondere i record dei singoli amici con i relativi numeri di telefono. Tali dati sono detti “chiave primaria” e costituiscono un identificatore univoco che distingue ciascuna riga di una tabella dalle altre righe di quella stessa tabella. La chiave primaria può essere una “chiave naturale”, vale a dire uno degli elementi di dati che distingue naturalmente ciascun record della tabella. Nella tabella “amici”, se ad esempio nessuno degli amici ha la stessa data di nascita, si può usare la colonna della data di nascita come chiave primaria (chiave naturale) della tabella “amici”. Se non è presente una chiave naturale, create una colonna di chiave primaria distinta, ad esempio “friend id”, ovvero un valore artificiale di cui l'applicazione fa uso per distinguere le diverse righe.

Tramite la chiave primaria potete impostare relazioni tra più tabelle. Supponete ad esempio che la tabella “friends” comprenda una colonna “friend id” che contiene un numero univoco per ciascuna riga (cioè ciascun amico). La tabella correlata ”numeri di telefono” può avere una struttura su due colonne, una con l'“id amico” della persona a cui appartiene il numero di telefono e una con il numero di telefono in questione. In questo modo, tutti i numeri di telefono di un singolo amico, indipendentemente dalla quantità, possono essere memorizzati nella tabella “numeri di telefono” ed essere collegati all'amico in oggetto tramite la chiave primaria "id amico". Quando si utilizza la chiave primaria di una tabella in una tabella correlata, al fine di specificare il collegamento fra i record, il valore contenuto nella tabella correlata è detto “chiave esterna”. A differenza di molti altri database, il motore di database locale AIR non consente la creazione di vincoli per la chiave esterna, cioè di vincoli che controllano automaticamente che un certo valore della chiave esterna inserito o aggiornato possieda una riga corrispondente nella tabella della chiave primaria. Ciò nonostante, le relazioni con chiave esterna rappresentano una parte importante della struttura dei database relazionali e, quando si crea un database, si devono utilizzare le chiavi esterne per la creazione delle relazioni tra le tabelle.

Structured Query Language (SQL) viene impiegato nei database relazionali per la manipolazione e il recupero dei dati. SQL è un linguaggio descrittivo e non procedurale: invece di dare istruzioni al computer descrivendo il modo in cui deve recuperare i dati, le istruzioni SQL descrivono il gruppo di dati che si desidera recuperare. È il motore del database a decidere in che modo recuperarli.

Il linguaggio SQL è stato standardizzato dall'American National Standards Institute (ANSI). Il database SQL locale di Adobe AIR supporta gran parte dello standard SQL-92.

Per descrizioni specifiche del linguaggio SQL supportato in Adobe AIR, vedete Supporto di SQL nei database locali .

Per lavorare con i database SQL locali in ActionScript 3.0 si utilizzano le seguenti classi nel pacchetto flash.data.

Per ottenere informazioni di schema che descrivono la struttura di un database si utilizzano le seguenti classi del pacchetto flash.data.

Altre classi contenute nel pacchetto flash.data forniscono costanti utilizzate con la classe SQLConnection e la classe SQLColumnSchema, come segue.

Inoltre, le seguenti classi del pacchetto flash.events rappresentano gli eventi (e le costanti di supporto) da utilizzare, come segue.

Per concludere, le seguenti classi del pacchetto flash.errors forniscono informazioni sugli errori relativi alle operazioni del database.

Quando si crea il codice per l'utilizzo con un database SQL locale, si deve specificare l'esecuzione delle operazioni di tale database in una di due modalità: esecuzione asincrona o sincrona. In genere, gli esempi che illustrano il codice mostrano come eseguire l'operazione in entrambi i modi, così da dare la possibilità di scegliere l'esempio del tipo più appropriato alle necessità del momento.

Nella modalità di esecuzione asincrona l'utente dà un'istruzione al runtime ed esso crea un evento dopo che l'operazione richiesta viene completata o non riesce. Prima di tutto, si comanda al motore del database di eseguire un'operazione. Il motore esegue il comando in background, mentre l'applicazione continua ad essere in esecuzione. Alla fine, dopo che l'operazione è stata completata o non è riuscita, il motore del database crea un evento. Il codice creato dall'utente, attivato dall'evento, esegue poi le operazioni successive. Questo approccio presenta un notevole vantaggio: il runtime esegue le operazioni del database in background mentre il codice dell'applicazione principale continua ad essere in esecuzione. Anche se l'operazione del database impiega molto tempo, l'applicazione continua comunque ad essere eseguita; inoltre, cosa molto importante, l'utente può continuare a interagire con essa senza che il display si blocchi. Il problema è che il codice per le operazioni asincrone è in genere più complesso e difficile da compilare degli altri tipi. La complessità è di solito in evidenza nei casi in cui è necessario dividere più operazioni dipendenti fra vari metodi listener degli eventi.

Dal punto di vista concettuale, è più facile creare il codice per le operazioni in una sequenza di passi singola, cioè un set di operazioni sincrone, invece che un set di operazioni divise fra vari metodi listener degli eventi. Oltre a consentire l'esecuzione delle operazioni di database asincrone, Adobe AIR consente anche quella delle operazioni sincrone. Nella modalità di esecuzione sincrona le operazioni non vengono eseguite in background: vengono invece eseguite nell'ambito della stessa sequenza di esecuzione del codice di tutte le altre applicazioni. Per prima cosa, si comanda al motore del database di eseguire un'operazione. Il codice si ferma quindi a quel punto in attesa che il motore esegua il comando. Al termine dell'operazione, l'esecuzione prosegue con la riga successiva del codice.

L'esecuzione sincrona o asincrona delle operazioni si imposta al livello SQLConnection. Se si usa una sola connessione per il database, non è possibile eseguire alcune delle operazioni o delle istruzioni in modo sincrono ed altre in modo asincrono. Per specificare se SQLConnection opera in modalità di esecuzione sincrona o asincrona si chiama un metodo SQLConnection per l'apertura del database. Se si chiama SQLConnection.open() , la connessione funziona in modalità di esecuzione sincrona e se si chiama SQLConnection.openAsync() la modalità sarà invece asincrona. Una volta che l'istanza SQLConnection è connessa al database tramite open() o openAsync() , la modalità di esecuzione viene fissata su sincrona o asincrona a meno che non si chiuda e poi si riapra la connessione al database.

Ciascuna modalità di esecuzione presenta dei vantaggi. Sebbene vi siano moltissime similarità, quando si lavora in ciascuna modalità è bene tenere presenti alcune importanti differenze. Per ulteriori informazioni su questi argomenti, e per ulteriori suggerimenti per lavorare in ciascuna delle modalità, consultate Utilizzo delle operazioni di database sincrone e asincrone .