A propos des bases de données SQL locales

La fonctionnalité de base de données SQL locale de l’application AIR peut répondre à tout objectif de stockage des données d’application sur l’ordinateur local d’un utilisateur. Adobe AIR inclut plusieurs mécanismes de stockage local des données, chacun présentant des avantages distincts. Voici quelques utilisations possibles d’une base de données SQL locale dans votre application AIR :

• Avec une application orientée données (par exemple, un carnet d’adresses), une base de données peut être utilisée pour stocker les données de l’application principale.

• Avec une application orientée documents, dans laquelle les utilisateurs créent des documents à enregistrer et éventuellement à partager, chaque document peut être enregistré sous forme de fichier de base de données, à l’emplacement désigné par l’utilisateur. (Notez, toutefois, que si la base de données n’est pas chiffrée, toute application AIR peut ouvrir le fichier de bases de données. Le chiffrement est donc recommandé pour tous les documents potentiellement sensibles.)

• Avec une application réseau, il est possible d’utiliser une base de données pour stocker un cache local des données d’application ou pour stocker temporairement des données lorsque la connexion réseau n’est pas disponible. Un mécanisme de synchronisation peut dans ce cas être créé pour synchroniser la base de données locale avec le magasin de données en réseau.

• Quelle que soit l’application, une base de données peut être utilisée pour stocker les paramètres d’application des utilisateurs individuels, tels que les informations relatives aux applications ou aux options des utilisateurs, comme la taille et la position de la fenêtre.

Une base de données SQL locale Adobe AIR individuelle est stockée sous la forme d’un seul fichier dans le système de fichiers de l’ordinateur. Le moteur de base de données SQL du moteur d’exécution gère la création et le formatage des fichiers de base de données, de même que la manipulation et la récupération des données dans un fichier de base de données. Le moteur d’exécution ne spécifie pas comment ni où les données de la base de données sont stockées dans le système de fichiers, mais chaque base de données est stockée dans son intégralité dans un seul fichier. Vous spécifiez l’emplacement de stockage du fichier de base de données dans le système de fichiers. Une même application AIR peut accéder à une ou plusieurs bases de données distinctes (c’est-à-dire à des fichiers de base de données distincts). Le moteur d’exécution stockant chaque base de données sous forme d’un seul fichier dans le système de fichiers, vous pouvez localiser votre base de données selon vos besoins, en fonction de la conception de votre application et des contraintes d’accès aux fichiers du système d’exploitation. Chaque utilisateur peut disposer d’un fichier de base de données distinct pour ses données spécifiques, ou tous les utilisateurs de l’application peuvent accéder à un fichier de bases de données sur un ordinateur dans le cas de données partagées. Les données étant stockées localement sur un seul ordinateur, elles ne sont pas automatiquement partagées avec les utilisateurs d’autres ordinateurs. Le moteur de la base de données SQL locale ne permet pas d’exécuter des instructions SQL sur une base de données distante ou basée sur un serveur.

Une base de données relationnelle est un mécanisme de stockage (et de récupération) des données sur un ordinateur. Les données sont organisées en tables : les lignes représentent les enregistrements ou les éléments, et les colonnes (parfois appelées « champs ») divisent chaque enregistrement en valeurs individuelles. Par exemple, une application de carnet d’adresses peut contenir une table nommée « amis ». Chaque ligue de la table représente alors un ami stocké dans la base de données. Les colonnes de cette table représentent des données telles que le prénom, le nom, la date de naissance, etc. Pour chaque ligne de la table, la base de données stocke une valeur distincte dans chaque colonne.

Les bases de données relationnelles sont conçues pour stocker des données complexes, chaque élément étant associé ou relié à des éléments d’un autre type. Dans une base de données relationnelle, toute donnée présentant une relation « un à plusieurs » (où un seul enregistrement peut être relié à plusieurs enregistrements de types différents) doit être répartie parmi les différentes tables. Par exemple, si vous souhaitez stocker plusieurs numéros de téléphone pour chaque ami dans votre application de carnet d’adresses, il s’agit d’une relation « un à plusieurs ». La table « amis » contiendrait alors toutes les informations personnelles de chaque ami. Une table distincte « numéros de téléphone » contiendrait tous les numéros de téléphone de tous les amis.

Outre le stockage des données de vos amis et de leurs numéros de téléphone, chaque table a besoin d’un élément de données qui lui permette de relier les deux tables (pour mettre en correspondance les enregistrements individuels des amis et leurs numéros de téléphone). Ces données sont appelées clé primaire (identifiant unique qui différencie chaque ligne de la table des autres lignes de cette même table). La clé primaire peut être une « clé naturelle », c’est-à-dire un élément de données qui différencie naturellement chaque enregistrement d’une table. Dans le cas de la table « amis », si vous savez qu’aucun de vos amis n’a la même date de naissance, vous pouvez utiliser la colonne date de naissance comme clé primaire (clé naturelle) de cette table. S’il n’existe pas de clé naturelle, vous pouvez créer une colonne de clé primaire distincte telle que « ID ami » (valeur artificielle utilisée par l’application pour différencier les lignes).

L’utilisation d’une clé primaire permet de définir les relations existant entre plusieurs tables. Supposons par exemple que la colonne « ID ami » de la table « amis » contienne un numéro unique pour chaque ligne (chaque ami). La table reliée « numéros de téléphone » peut être structurée sur deux colonnes : l’une contenant l’identifiant de l’ami à qui le numéro de téléphone appartient, l’autre contenant le numéro de téléphone lui-même. Ainsi, quel que soit le nombre de numéros de téléphone d’un ami, tous peuvent être stockés dans la table « numéros de téléphone » et reliés à l’ami associé via la clé primaire « ID ami ». Lorsque la clé primaire d’une table est utilisée dans une table reliée pour spécifier la connexion entre les enregistrements, la valeur de la table reliée est appelée clé étrangère. Contrairement à de nombreuses bases de données, le moteur de base de données locale de l’application AIR ne vous permet pas de créer des contraintes de clé étrangère. Ces contraintes vérifient automatiquement qu’une valeur de clé étrangère mise à jour ou insérée correspond à une ligne de la table de clés primaires. Les relations entre les clés étrangères sont toutefois un élément important de la structure d’une base de données relationnelle, et les clés étrangères doivent être utilisées lors de la création de relations entre les tables de votre base de données.

Le langage SQL (Structured Query Language) est utilisé avec les bases de données relationnelles pour manipuler et récupérer les données. SQL est davantage un langage descriptif qu’un langage procédural. Au lieu de donner à l’ordinateur des instructions sur la façon dont les données doivent être récupérées, une instruction SQL décrit le jeu de données désiré. Le moteur de base de données détermine lui comment récupérer ces données.

Le langage SQL a été normalisé par l’institut ANSI (American National Standards Institute). La base de données SQL locale d’Adobe AIR prend en charge la plupart des standards SQL-92.

Pour consulter des descriptions spécifiques du langage SQL pris en charge dans Adobe AIR, voir Prise en charge de SQL dans les bases de données locales .

Pour travailler avec des bases de données SQL locales dans ActionScript 3.0, vous utilisez les occurrences des classes suivantes du package flash.data :

Pour obtenir les informations du schéma décrivant la structure d’une base de données, utilisez les classes suivantes du package flash.data :

Les autres classes du package flash.data fournissent des constantes utilisées avec les classes SQLConnection et SQLColumnSchema :

De plus, les classes suivantes du package flash.events représentent les événements (et les constantes prises en charge) que vous utilisez :

Enfin, les classes suivantes du package flash.errors fournissent des informations sur les erreurs des opérations de base de données :

Lorsque vous écrivez du code pour travailler avec une base de données SQL locale, vous spécifiez que les opérations de cette base de données doivent s’exécuter dans l’un des deux modes d’exécution suivants : asynchrone ou synchrone. En général, les exemples de code montrent comment effectuer chaque opération des deux manières. Vous pouvez donc utiliser l’exemple répondant le mieux à vos besoins.

En mode d’exécution asynchrone, vous envoyez une instruction au moteur d’exécution et ce dernier distribue un événement lorsque l’opération demandée se termine ou échoue. Vous commencez par indiquer au moteur de base de données d’effectuer une opération. Celui-ci travaille en arrière-plan pendant que l’application poursuit son exécution. Enfin, lorsque l’opération est terminée (ou lorsqu’elle échoue), le moteur de base de données distribue un événement. Votre code, déclenché par l’événement, effectue les opérations consécutives. Cette approche présente un avantage important : le moteur d’exécution effectue les opérations de base de données en arrière-plan pendant que le code de l’application principale poursuit son exécution. Si l’opération de base de données prend un certain temps, l’exécution de l’application n’est pas interrompue. Plus important encore, l’utilisateur peut continuer à interagir avec elle sans que l’écran ne se fige. Toutefois, la rédaction du code d’opérations asynchrones peut se révéler plus complexe que la rédaction d’autres codes. Cette complexité survient généralement lorsque plusieurs opérations dépendantes doivent être réparties entre diverses méthodes d’écouteur d’événement.

De façon conceptuelle, il est plus simple de coder les opérations sous forme d’une seule séquence d’étapes (ensemble d’opérations synchrones) plutôt que sous forme d’un ensemble d’opérations divisées en plusieurs méthodes d’écouteur d’événement. Outre les opérations de base de données asynchrones, Adobe AIR vous permet également d’exécuter des opérations de base de données de façon synchrone. Dans ce mode, les opérations ne s’exécutent pas en arrière-plan mais dans la même séquence d’exécution que le reste du code de l’application. Vous indiquez au moteur de base de données d’effectuer une opération. Le code s’interrompt alors à ce stade pendant que le moteur de base de données effectue son travail. Lorsque l’opération est terminée, l’exécution se poursuit avec la ligne suivante de votre code.

L’exécution asynchrone ou synchrone des opérations est définie au niveau de l’occurrence de SQLConnection. L’utilisation d’une seule connexion de base de données ne permet pas d’exécuter certaines opérations ou instructions de façon synchrone et d’autres de façon asynchrone. Pour indiquer si une occurrence de SQLConnection fonctionne en mode d’exécution synchrone ou asynchrone, appelez une méthode SQLConnection pour ouvrir la base de données. Si vous appelez SQLConnection.open() , la connexion opère en mode d’exécution synchrone, et si vous appelez SQLConnection.openAsync() , le mode d’exécution asynchrone est utilisé. Lorsqu’une occurrence de SQLConnection est connectée à une base de données à l’aide de open() ou openAsync() , elle est figée en mode d’exécution synchrone ou asynchrone, sauf si vous fermez et rouvrez la connexion à la base de données.

Chaque mode d’exécution a ses propres avantages. Bien que similaires dans la plupart de leurs aspects, chaque mode présente des différences que vous devez connaître pour les exploiter correctement. Pour plus d’informations et pour obtenir des suggestions quant au choix de chaque mode, voir la section Utilisation des opérations de base de données synchrones et asynchrones .