Informacje o lokalnych bazach danych SQL

Lokalna baza danych SQL środowiska AIR może służyć do dowolnego celu, dla którego konieczne może być zapisanie danych aplikacji lokalnie na komputerze. Środowisko Adobe AIR zawiera kilka mechanizmów przeznaczonych do lokalnego zapisywania danych, a każdy charakteryzuje się osobnymi zaletami. Poniżej przedstawiono możliwe zastosowania lokalnej bazy danych SQL w aplikacji AIR:

• W przypadku aplikacji zorientowanej na dane (np. książka adresowa) baza danych może służyć do zapisywania danych aplikacji głównej.

• W przypadku aplikacji zorientowanej na dokumenty, w której użytkownicy tworzą dokumenty zapisywane oraz współużytkowane, każdy dokument może zostać zapisany jako plik bazy danych, w lokalizacji określonej przez użytkownika. (Należy jednak zwrócić uwagę, że dowolna aplikacja AIR będzie mogła otworzyć plik bazy danych, o ile nie będzie on zaszyfrowany. Zaleca się szyfrowanie dokumentów podlegających szczególnej ochronie).

• W przypadku aplikacji sieciowej baza danych może służyć do zapisu lokalnej pamięci podręcznej danych aplikacji lub do tymczasowego zapisu danych, gdy nie istnieje połączenie z siecią. Możliwe jest utworzenie mechanizmu synchronizacji lokalnej bazy danych z sieciowym magazynem danych.

• Dla każdej aplikacji baza danych może służyć do zapisania ustawień użytkownika aplikacji, np. opcji użytkownika lub informacji o aplikacji, takich jak wielkość i położenie okien.

Pojedyncza lokalna baza danych SQL w środowisku Adobe AIR jest zapisana jako jeden plik w systemie plików. Środowisko wykonawcze zawiera mechanizm bazy danych SQL, który zarządza tworzeniem i strukturą plików bazy danych, a także manipulowaniem danymi i odzyskiwaniem danych z pliku bazy danych. Środowisko wykonawcze nie określa sposobu ani miejsca zapisu danych w systemie plików; zamiast tego każda baza danych jest zapisywana w całości w jednym pliku. Lokalizację pliku bazy danych określa się w systemie plików. Pojedyncza aplikacja AIR może uzyskiwać dostęp do jednej lub wielu osobnych baz danych (tj. do osobnych plików baz danych). Środowisko wykonawcze zapisuje każdą bazę danych jako osobny plik w systemie plików, dlatego możliwe jest dowolne umiejscowienie bazy danych poprzez określenie struktury aplikacji i ograniczeń dostępu do pliku w systemie operacyjnym. Każdy użytkownik może korzystać z osobnego pliku bazy danych dla własnych danych lub możliwy jest dostęp do bazy danych przez wszystkich użytkowników aplikacji, w przypadku danych współużytkowanych. Dane są lokalne tylko względem pojedynczego komputera, dlatego dane nie są automatycznie współużytkowane przez użytkowników na różnych komputerach. Lokalny mechanizm bazy danych SQL nie umożliwia wykonywania instrukcji SQL dotyczących zdalnych lub serwerowych baz danych.

Relacyjna baza danych to mechanizm przeznaczony do zapisywania (i pobierania) danych na komputerze. Dane są zorganizowane w tabelach: wiersze reprezentują rekordy lub pozycje, a kolumny (czasami nazywane „polami”) dzielą każdy rekord na osobne wartości. Na przykład: aplikacja książki adresowej może zawierać tabelę „znajomi”. Każdy wiersz w tej tabeli reprezentuje jednego znajomego zapisanego w bazie danych. Kolumny tabeli reprezentują dane, takie jak imię, nazwisko, data urodzenia itp. W wierszu każdego znajomego baza danych zawiera osobną wartość dla każdej kolumny.

Relacyjne bazy danych zawierają dane złożone, a jeden element danych jest skojarzony lub powiązany z elementami innego typu. W relacyjnej bazie danych dane, dla których istnieje relacja „jeden do wielu” — w której jeden rekord może być powiązany z wieloma rekordami różnego typu — powinny być rozdzielone na różne tabele. Przykład: załóżmy, że wymagane jest, aby aplikacja książki telefonicznej zawierała wiele numerów telefonów dla każdego znajomego; to jest relacja „jeden do wielu”. Tabela „znajomi” będzie zawierała wszystkie dane osobowe dla każdego znajomego. Osobno tabela „numery telefonów” będzie zawierała wszystkie numery telefonów dla wszystkich znajomych.

Oprócz danych dotyczących znajomych i numerów telefonów każda tabela może zawierać dane przeznaczone do śledzenia relacji między dwiema tabelami — w celu dopasowania rekordów poszczególnych osób do ich numerów telefonów. Te dane są określane jako klucz podstawowy — unikalny identyfikator, który odróżnia każdy wiersz w tabeli od innych wierszy w tej tabeli. Klucz podstawowy może być „kluczem naturalnym”, co oznacza, że jest to jeden z elementów danych, które w naturalny sposób odróżniają każdy rekord w tabeli. Jeśli wiadomo, że żadne osoby z tabeli „znajomi” nie mają takiej samej daty urodzenia, wówczas kolumna daty urodzenia może być używana jako klucz podstawowy (klucz naturalny) tabeli „znajomi”. Jeśli nie ma klucza naturalnego, można utworzyć osobną kolumnę klucza podstawowego, taką jak „id. znajomego” — będzie to sztuczna wartość, z której aplikacja korzysta w celu odróżniania wierszy.

Za pomocą klucza podstawowego można skonfigurować relacje między wieloma tabelami. Na przykład: załóżmy, że tabela „znajomi” zawiera kolumnę „id. znajomego”, która zawiera unikalny numer dla każdego wiersza (znajomego). Powiązana tabela „numery telefonów” może zawierać dwie kolumny: jedną z id. znajomego, do którego należy numer telefonu, a drugą z rzeczywistym numerem telefonu. Dzięki temu niezależnie od liczby numerów telefonów, z których korzysta określona osoba, wszystkie te numery mogą być zapisane w tabeli „numery telefonów” i mogą być połączone z powiązanym znajomym za pomocą klucza podstawowego „id. znajomego”. Jeśli klucz podstawowy z jednej tabeli jest używany w tabeli powiązanej w celu określenia połączenia między rekordami, wówczas wartość w tabeli powiązanej jest określana jako klucz obcy. Mechanizm lokalnej bazy danych AIR — inaczej niż większość baz danych — nie umożliwia tworzenia ograniczeń dot. kluczy obcych. Są to ograniczenia, które powodują automatyczne sprawdzanie, czy wstawiony lub zaktualizowany klucz obcy ma odpowiadający wiersz w tabeli klucza podstawowego. Jednakże relacje kluczy obcych stanowią istotną część struktury relacyjnej bazy danych i powinny być używane w przypadku tworzenia relacji między tabelami w bazie danych.

Język SQL (Structured Query Language) jest używany z relacyjnymi bazami danych w celu manipulowania danymi oraz w celu uzyskiwania danych. SQL jest językiem opisowym, a nie proceduralnym. Instrukcja SQL nie stanowi dla komputera instrukcji uzyskania danych — jest to opis wymaganego zestawu danych. Sposób uzyskiwania danych określa mechanizm bazy danych.

Standardy języka SQL zostały określone przez instytut ANSI (American National Standards Institute). Lokalna baza danych SQL środowiska Adobe AIR obsługuje większą część standardu SQL-92.

Opis języka SQL obsługiwanego w środowisku Adobe AIR można znaleźć w sekcji Obsługa języka SQL w lokalnych bazach danych.

W celu pracy z lokalnymi bazami danych SQL w języku ActionScript 3.0 należy korzystać z instancji następujących klas z pakietu flash.data:

W celu uzyskania schematów dotyczących struktury bazy danych należy użyć następujących klas z pakietu flash.data:

Inne klasy z pakietu flash.data udostępniają stałe, które są używane z klasą SQLConnection oraz klasą SQLColumnSchema:

Ponadto poniższe klasy z pakietu flash.events reprezentują zdarzenia (oraz obsługujące stałe) używane przez użytkownika:

Poniższe klasy z pakietu flash.errors udostępniają informacje o błędach działania baz danych:

Podczas pisania kodu przeznaczonego do pracy z lokalną bazą danych SQL należy określić wykonanie operacji bazy danych w jednym z dwóch trybów: tryb wykonywania asynchronicznego i tryb wykonywania synchronicznego. Najczęściej przykłady kodu przedstawiają wykonywanie określonych operacji na dwa sposoby, dlatego możliwe jest wybranie sposobu, który najbardziej odpowiada określonym potrzebom.

W trybie wykonywania asynchronicznego środowisko wykonawcze otrzymuje instrukcję i wówczas środowisko wywołuje zdarzenie, gdy żądana operacja zakończy się pomyślnie lub zakończy się niepowodzeniem. Najpierw mechanizm bazy danych musi otrzymać instrukcję dotyczącą wykonania operacji. Mechanizm działa w tle, a w tym czasie działa również aplikacja. Na koniec, gdy operacja powiedzie się (lub nie powiedzie), mechanizm bazy danych wywołuje błąd. Kod wywoływany przez zdarzenie powoduje wykonanie kolejnych operacji. Takie podejście ma znaczące zalety: środowisko wykonawcze wykonuje operacje bazy danych w tle podczas działania kodu aplikacji głównej. Jeśli wykonanie operacji bazy danych zajmuje pewną ilość czasu, wówczas aplikacja nadal działa. Najważniejsze jest to, że użytkownik może oddziaływać na aplikację i nie powoduje to efektu zamrożenia” ekranu. Jednakże kod operacji asynchronicznej może być znacznie bardziej złożony niż inne rodzaje kodu. Taka złożoność występuje przede wszystkim w przypadkach, gdy konieczne jest rozdzielenie wielu niezależnych operacji między różne metody detektora zdarzeń.

Koncepcyjnie łatwiejsze jest kodowanie operacji jako pojedynczej sekwencji kroków — zestawu operacji synchronicznych — zamiast zestawu operacji podzielonych na kilka metod detektora zdarzeń. Oprócz asynchronicznych operacji na bazie danych środowisko Adobe AIR umożliwia również synchroniczne wykonywanie operacji na bazie danych. W trybie wykonywania synchronicznego operacje nie działają w tle. Zamiast tego działają w tej samej sekwencji wykonywania, w której działa cały kod aplikacji. Użytkownik zleca mechanizmowi bazy danych wykonanie operacji. Następnie kod jest wstrzymywany na czas działania mechanizmu bazy danych. Gdy operacja zostanie zakończona, następuje wznowienie wykonywania kodu od kolejnej linii.

To, czy operacje są wykonywane w sposób synchroniczny czy asynchroniczny, jest określone na poziomie SQLConnection. W przypadku korzystania z pojedynczego połączenia z bazą danych nie ma możliwości wykonania jednych operacji w sposób synchroniczny, a innych w sposób asynchroniczny. To, czy instancja SQLConnection działa w trybie wykonywania synchronicznego czy asynchronicznego, określa się poprzez wywołanie metody SQLConnection w celu otwarcia bazy danych. Jeśli zostanie wywołana metoda SQLConnection.open(), połączenie działa w trybie wykonywania synchronicznego, a jeśli zostanie wywołana metoda SQLConnection.openAsync(), wówczas połączenie działa w trybie wykonywania asynchronicznego. Gdy instancja SQLConnection zostanie połączona z bazą danych za pomocą metody open() lub openAsync(), zostaje przypisana do trybu wykonywania synchronicznego lub asynchronicznego, chyba że nastąpi zamknięcie i ponowne otwarcie połączenia z bazą danych.

Każdy tryb wykonywania ma pewne zalety. Większość aspektów każdego trybu jest podobna, jednak istnieją różnice, o których należy pamiętać podczas pracy z każdym trybem. Więcej informacji na ten temat oraz sugestie dotyczące pracy w każdym trybie zawiera sekcja Korzystanie z synchronicznych i asynchronicznych operacji bazy danych.