Bases de datos SQL locales

La funcionalidad de la base de datos SQL local de AIR se puede usar para cualquier fin para el que desee almacenar datos de aplicación en el equipo local del usuario. Adobe AIR incluye varios mecanismos para almacenar datos de forma local, cada uno con diferentes ventajas. Los siguientes son algunos usos posibles para una base de datos SQL local en la aplicación de AIR:

• Para una aplicación orientada a datos (por ejemplo una agenda de direcciones) se puede usar una base de datos para almacenar los datos de la aplicación principal.

• Para una aplicación orientada a documentos, donde los usuarios crean documentos para guardar y posiblemente compartir, se puede guardar cada documento como un archivo de base de datos, en una ubicación designada por el usuario. (Sin embargo, se debe tener en cuenta que a no ser que la base de datos esté cifrada, cualquier aplicación de AIR podría abrir el archivo de base de datos. El cifrado se recomienda para documentos que pueden llegar a ser de especial importancia.)

• Para una aplicación de red, se puede usar una base de datos para almacenar caché local de los datos de aplicación o almacenar datos temporalmente cuando no se encuentra disponible una conexión de red. Se puede crear un mecanismo para sincronizar la base de datos local con el almacén de datos de red.

• Para cualquier aplicación, se puede usar una base de datos para almacenar la configuración de aplicación individual de un usuario, como opciones de usuario o información de aplicación como color y posición de la ventana.

Una base de datos SQL local de Adobe AIR individual se almacena como un solo archivo en el sistema de archivos del equipo. El motor de ejecución incluye el motor de la base de datos SQL que gestiona la creación y estructura de los archivos de bases de datos y la manipulación y recuperación de datos de un archivo de base de datos. El motor de ejecución no especifica cómo ni dónde se almacenan los datos de la base de datos en el sistema de archivos; sino, cada base de datos se almacena completamente dentro de un único archivo. Se especifica la ubicación en el sistema de archivos donde se almacena el archivo de la base de datos. Una sola aplicación de AIR puede acceder a una o muchas bases de datos por separado (es decir, archivos de base de datos por separado). Dado que el motor de ejecución almacena cada base de datos como un único archivo en el sistema de archivos, se puede encontrar la base de datos según sea necesario por el diseño de la aplicación y las restricciones de acceso a los archivos del sistema operativo. Cada usuario puede tener un archivo de base de datos individual para sus datos específicos o todos los usuarios de la aplicación pueden acceder a un archivo de base de datos en un solo equipo para datos compartidos. Dado que los datos son locales para un solo equipo, los datos no se comparten automáticamente entre usuarios en diferentes equipos. El motor de la base de datos SQL local no proporciona ninguna prestación para ejecutar declaraciones SQL para comparar con una base de datos remota o de servidor.

Una base de datos relacional es un mecanismo para almacenar (y recuperar) datos en un equipo. Los datos se organizan en tablas: las filas representan registros o elementos y las columnas (a veces denominados “campos”) dividen cada registro en valores individuales. Por ejemplo, una aplicación de agenda de direcciones puede tener una tabla “amigos”. Cada fila en la tabla representa un amigo almacenado en la base de datos. Las columnas de la tabla representan los datos como nombre, apellido, fecha de nacimiento etc. Para cada fila de amigo en la tabla, la base de datos almacena un valor por separado para cada columna.

Las bases de datos relacionales están diseñadas para almacenar datos complejos, donde un elemento está asociado o relacionado con elementos de otro tipo. En una base de datos relacional, los datos que tienen una relación de uno a muchos —donde un solo registro puede relacionarse con múltiples registros de un tipo diferente— se debe dividir entre diferentes tablas. Por ejemplo, supongamos que desea que la aplicación de la agenda de direcciones almacene múltiples números de teléfono para cada amigo, esta es una relación de uno a muchos. La tabla “amigos” contiene toda la información personal de cada amigo. Una tabla por separado de “números de teléfono” tiene los números de teléfono de todos los amigos.

Además de almacenar los datos sobre amigos y números de teléfono, cada tabla necesita datos para hacer un seguimiento de la relación entre las dos tablas, para hacer coincidir los registros individuales de los amigos con sus números de teléfono. Estos datos se conocen como clave principal, un identificador exclusivo que distingue cada fila en una tabla de otras filas en dicha tabla. La clave principal puede ser una “clave natural”, lo que significa que es uno de los elementos de los datos que naturalmente distingue cada registro en una tabla. En la tabla “amigos”, si supiera que ninguno de sus amigos tienen la misma fecha de nacimiento, podría usar la columna de fechas de nacimiento como la clave principal (una clave natural) de la tabla “amigos”. Si no hay ninguna clave natural, debe crear una columna de clave principal por separado como “ID de amigo”, un valor artificial que usa la aplicación para distinguir entre filas.

Al usar una clave principal, se pueden configurar las relaciones entre múltiples tablas. Por ejemplo, supongamos que la tabla “amigos” tiene una columna “ID de amigo” que contiene un número exclusivo para cada fila (cada amigo). La tabla “números de teléfono” relacionada se puede estructurar con dos columnas: una con el “ID de amigo” del amigo al que le pertenece el número de teléfono y una con el número de teléfono real. De ese modo, no importa la cantidad de números de teléfono que tenga un amigo, se pueden almacenar todos en la tabla “números de teléfono” y se pueden vincular al amigo relacionado usando la clave principal “ID de amigo”. Cuando se usa una clave principal de una tabla en una tabla relacionada para especificar la conexión entre los registros, el valor en la tabla relacionada se conoce como clave externa. A diferencia de muchas bases de datos, el motor de base de datos local de AIR no permite crear restricciones para la clave externa, que son restricciones que verifican automáticamente que el valor de una clave externa insertada o actualizada tiene una fila correspondiente en la tabla de la clave principal. No obstante, las relaciones de las claves externas son una parte importante de la estructura de una base de datos relacional y las claves externas se deben usar cuando se crean relaciones entre tablas en la base de datos.

Structured Query Language, SQL (del inglés Lenguaje de consulta estructurado) se utiliza con bases de datos relacionales para manipular y recuperar datos. SQL es un lenguaje descriptivo en vez de un lenguaje de procedimientos. En vez de impartir instrucciones al equipo sobre cómo debería recuperar datos, una declaración SQL describe el conjunto de datos que necesita. El motor de base de datos determina la manera de recuperar esos datos.

El lenguaje SQL ha sido estandarizado por el American National Standards Institute, ANSI (del inglés Instituto Nacional Estadounidense de Normas). La base de datos SQL local de Adobe AIR admite la mayoría de las normas SQL-92.

Para obtener descripciones específicas del lenguaje SQL admitido en Adobe AIR, consulte Compatibilidad de SQL en bases de datos locales .

Para trabajar con bases de datos SQL locales en ActionScript 3.0, se usan las instancias de estas clases en el paquete flash.data:

Para obtener la información de esquemas que describen la estructura de una base de datos, se usan estas clases en el paquete flash.data:

Otras clases en el paquete flash.data proporcionan restricciones que se usan con la clase SQLConnection y la clase SQLColumnSchema:

Además, las siguientes clases en el paquete flash.events representan los eventos (y constantes admitidas) que usa:

Por último, las siguientes clases en el paquete flash.errors proporcionan información sobre los errores de operación de la base de datos:

Cuando se escribe código para trabajar con una base de datos SQL local, se especifica la ejecución de las operaciones de la base de datos en uno de los dos modos de ejecución: modo de ejecución asíncrono o sincrónico. En general, los ejemplos de código muestran la manera de realizar cada operación en ambos modos, para que pueda usar el ejemplo que sea más apropiado para sus necesidades.

En el modo de ejecución asíncrono, se suministra una instrucción al motor de ejecución y este distribuye un evento cuando la operación solicitada se completa o falla. Primero se indica al motor de la base de datos que realice una operación. El motor de la base de datos hace su trabajo en segundo plano mientras la aplicación continúa ejecutándose. Por último, cuando se completa la operación (o cuando falla) el motor de la base de datos distribuye un evento. El código, activado por el evento, lleva a cabo las operaciones subsiguientes. Este enfoque tiene una gran ventaja: el tiempo motor ejecución realiza las operaciones de la base de datos en segundo plano mientras el código de la aplicación principal continúa ejecutándose. Si la operación de la base de datos tarda considerablemente, la aplicación continúa ejecutándose. Lo más importante es que el usuario puede seguir interactuando sin que se bloquee la pantalla. No obstante, el código de operación asíncrono puede ser más complejo de escribir que otro código. Esta complejidad es generalmente en casos donde varias operaciones dependientes se deben dividir entre diferentes métodos de detectores de evento.

Conceptualmente, es más fácil codificar operaciones como una sola secuencia de pasos, un conjunto de operaciones sincrónicas, en vez de un conjunto de operaciones divididas entre varios métodos de detectores de evento. Además de las operaciones de base de datos asíncronas, Adobe AIR también permite ejecutar operaciones de base de datos sincrónicas. En el modo de ejecución sincrónico, las operaciones no se ejecutan en segundo plano. En cambio se ejecutan en la misma secuencia de ejecución que el resto del código de aplicación. Se le indica al motor de la base de datos que realice una operación. Este código hace una pausa en ese punto mientras que el motor de base de datos hace su trabajo. Cuando se completa la operación, la ejecución continúa con la siguiente línea de código.

Si las operaciones se ejecutan de forma asíncrona o sincrónicamente se define en el nivel SQLConnection. Si se usa una sola conexión de base de datos, no se pueden ejecutar algunas operaciones o sentencias sincrónicamente y otras de forma asíncrona. Especifique si una SQLConnection funciona en el modo de ejecución asíncrono o sincrónico llamando a un método SQLConnection para abrir la base de datos. Si llama a SQLConnection.open() la conexión funciona en el modo de ejecución sincrónico y si llama a SQLConnection.openAsync() la conexión funciona en el modo de ejecución asíncrono. Una vez que una instancia SQLConnection se conecta a una base de datos usando open() o openAsync() , se fija en el modo de ejecución asíncrono o sincrónico a menos que elija cerrar y volver a abrir la conexión a la base de datos.

Cada modo de ejecución tiene sus ventajas. Mientras que la mayoría de los aspectos son similares, hay algunas diferencias que debe tener en cuenta cuando trabaja con cada modo. Para más información sobre estos temas y sugerencias para trabajar en cada modo, consulte Uso de operaciones sincrónicas y asíncronas de base de datos .