ullman204 (2)

414 6. WIĘZY 1 WYZWALACZE W JĘZYKU SQL

♦    Więzy kratkowe typu CIIEC.K (tuple-based check constraints): Sprawdzenie, żc wartości składowej lub składowych krotek pewnej relacji zawsze spełniają określone warunki, może następować w wyniku dołączenia do deklaracji relacji słowa kluczowego CHECK oraz warunku, który ma być przestrzegany.

♦    Asercje (asserlions): Do schematu bazy danych można dołączyć asercje jako element schematu, korzystając ze słowa kluczowego CHECK oraz określenia warunku. W warunku może występować więcej niż jedna nazwa relacji ze schematu bazy danych, a także asercja może dotyczyć relacji jako całości, jeśli warunek dotyczy np. pewnego agregatu.

♦    Wykonywanie sprawdzeń (invoking the checks): Asercje są sprawdzane zawsze wtedy, kiedy następuje jakakolwiek modyfikacja relacji, która może naruszać warunek ascrcji. Warunki określone dla wartości atrybutów oraz dla krotek są sprawdzane tylko wówczas, gdy zmienia się wartość atrybutu lub składowej relacji, którą obejmują więzy, w wyniku wstawiania nowej krotki lub zmiany wartości w istniejącej krotce. Zatem te więzy mogą zostać naruszone, jeśli zawierają podzapytania odnoszące się do innych relacji lub innych krotek tej samej relacji.

♦    Wyzwalacze (triggers) w SOL3: W standardzie SQL3 zostały zawarte wyzwalacze, które mogą zawierać określenie zdarzeń (np. wstawień, usunięć lub zmian w określonej relacji) powodujących wykonanie sprawdzenia. Przy spełnieniu warunku wyzwalacze powodują wykonanie wyspecyfikowanego ciągu akcji (zapisanych jako ciąg instrukcji SQL, takich jak zapytania lub modyfikacje bazy danych).

♦    Asercje w SQL3: Pojęcie asercji w SQL3 rożni się od koncepcji z SQL2. Podobnie jak wyzwalacze w $QL3, tak i asercje mogą działać pod wpływem zajścia określonych zdarzeń, np. wstawienia krotki do relacji. Po uruchomieniu asercji jest sprawdzany warunek dotyczący albo relacji, albo krotek, i jeśli nic jest on spełniony, to nie dochodzi do wykonania modyfikacji.

6.8. Literatura do rozdziału 6

Sposób dostępu do dokumentacji standardu SQL2 i SQL3 został zawarty w bibliografii przedstawionej po rozdziale 5. Pozycja [4] jest źródłem informacji o wszystkich elementach aktywnych w systemach baz danych. Z kolei w [11 przedstawiono rozważania na temat elementów- aktywnych w SQL3 i pomysłów następnych standardów. W [21 i [3] omówiono HiPAC - system w fazie wczesnego prototypu, który zawiera elementy aktywne bazy danych.

1.    Cochrane R.J., Pirahesh H.. Mattos N.: Integrating triggers and dcclarative constraints in SQL database Systems, łntl. Conf. on Very Large Datahase Systems, s. 567-579, 1996.

2.    Dayal IJ. i inni: The HiPAC project: combining activc databases and timing constraints. SIGMOD Record 17:1, s. 51 -70. 1988.

3.    McCarthy D.R., Dayal U.: The archilecture of an active database managernent system. Proc. ACM SIGMOD lntl. Conf. on Management of Data. s. 215-224, 1989.

4.    Widom J., Ceri S.: Active Datahase Systems. Morgan-Rautmann, San Francisco, 1996.

7_

Systemowe aspekty języka SQL

Skoncentrujemy teraz uwagę na zagadnieniu, jak dopasować $QL d< środowiska programistycznego. Żaden z tematów związanych z tym zagad nieniem, które poruszamy poniżej, nie narusza standardu SQL2. W podroż dziale 7.1 zobaczymy, żc najczęściej używa się kodu $QL jako fragmcnti innego programu napisanego w pewnym popularnym języku programowani? np. w C. SQL zawiera szereg mechanizmów, które umożliwiają przekazywa nic wartości między relacjami a zmiennymi z języka programu zewnętrznego czy mówiąc inaczej języka podstawowego”.

W podrozdziale 7.2 zostanie wprowadzone pojęcie transakcji, czyli poc stawowej jednostki wykonywanego zadania. Mimo że szereg działań możn wykonywać równolegle, w wielu zastosowaniach baz danych, takich jak n przykład bankowość, wymaga się jednak, aby działania na danych tworzył niepodzielne „atomy”. SQL dostarcza struktury służące do specy fi kowani transakcji, a systemy realizujące SQL zapewniają, że to co zostało zdefmic wane jako transakcja rzeczywiście wykona się jako działanie atomowe.

W podrozdziale 7.3 zostaną opisane pozostałe elementy^- systemu SQ1 takie jak na przykład mechanizmy wsparcia dla modelu obliczeniowego typ klient-serwer, a następnie w podrozdziale 7.4 sposoby autoryzowania dostęp do danych oraz metody jego nadzoru z poziomu systemu.

7.1. SQL w środowisku programistycznym

Dotychczas w przykładach używaliśmy języka SQL w sposób bezp< średni. Zakładaliśmy więc, żc istnieje interpreter $QL, który umożliw wprowadzenie oraz wykonanie poznawanych zapytań i poleceń. Jednak, rzadko się zdarza, aby praca przebiegała w takim trybie. W praktyce pewt instrukcje SQL stanow ią fragmenty większego programu lub zbioru funkcj Zatem bardziej realistyczne jest postrzeganie kodu SQL jako elementu więł