Pelikant A. - Bazy danych. Pierwsze starci

r o*-

Bazy ^amw©fe PIERWSZE STARCIE

W; . 'i ź l |F ~

Zobacz, jakie to proste - naucz się tworzyć baz Jak tworzyć formularze i raporty? ■ Jak modyfikować strukturę tabel? ■ Jak stosow ać mechanizmy wymiany danych? ■

• 7

,

‘t ,

• t r-,‘

„ . "■■.Ml 'J:) '

1 ‘ W ł v ł *t' P ' i

'

A

, r. t r t ó r i A i /

■2'- . ^ \py.

A

IU I

'

PI

ADAM PELIKANT tSMłSkWi r •Ślb'iii

W s tę p ............................................................................................................. 5 Rozdział 1.

Zakres b a d a ń ................................................................................................ 7 Podstawy teorii m nogości.......................................................................................................... 8 Normalizacja .............................................................................................................................10

Rozdział 2.

Projektowanie bazy danych — narzędzia wizualne ................................15 Tworzenie tabel .........................................................................................................................15 Wizualne tworzenie zapytań................................................................................................... 23 Tworzenie formularzy ............................................................................................................. 29 Tworzenie raportów................................................................................................................. 48 Zaawansowane metody obsługi aplikacji ..............................................................................54 Synchronizacja zawartości podformularza z kontrolką................................................ 54 Zapytanie przez form ularz................................................................................................ 64 Wykorzystanie zapytań modyfikujących z poziomu form ularzy........................................75

Rozdział 3.

Strukturalny język zapytań SQL w wersji MS Jet SQL ........................... 85 Informacje podstawowe...........................................................................................................85 Zapytania wybierające — SELECT ...................................................................................... 86 Składnia podstawowa........................................................................................................86 Sortowanie w zapytaniach................................................................................................ 88 Filtrowanie w zapytaniach................................................................................................ 89 Grupowanie i funkcje agregujące.................................................................................... 94 Zapytania do wielu tabel — złączenia................... 97 Zapytanie z podzapytaniem............................................................................................ 102 Unia — koniunkcja zbiorów (krotek)............................................................................ 109 Inne formy zapytań wybierających................................................................................ 115 Zapytania modyfikujące d a n e ................................................................................................122 Zapytania modyfikujące strukturę b a z y ............................................................................... 127 Tworzenie ta b e l................................................................................................................ 127 Modyfikowanie struktury tabel ......................................................................................134

Rozdział 4.

Zastosowanie języka zapytań SQL z poziomu formularzy ................... 139 Zastosowanie zapytań wybierających jako dynamicznych źródeł danych...................... 139 Wywoływanie zapytań modyfikujących dane z poziomu form ularza.............................. 145

Rozdział 5.

Mechanizmy wymiany danych ................................................................ 155 Zastosowanie obiektów DAO (Data Access Objecls) ....................................................... 155 Remote Data Objects (R D O ).................................................................................................169 ActiveX Data Objects (A D O )................................................................................................170

4

Rozdział 6.

Bazy danych. Pierwsze starcie

Zastosowanie mechanizmów wymiany danych przy tworzeniu aplikacji .......................................................................... 183 Zadanie magazynowe ............................................................................................................ 183 Obliczanie wyniku meczu na podstawie strzelonych bram ek...........................................189 Wyświetlanie zawartości b a zy .............................................................................................. 190 Zakończenie .............................................................................................193 Skorowidz ................................................................................................. 195

W otaczającej nas rzeczywistości w sposób lawinowy przybywa danych, które chcemy i musimy przetwarzać. Można próbować przenieść prawo Moore’a mówiące, że „moc obliczeniowa komputerów co dwa lata podwaja się, bez wzrostu ceny procesora”, na zadania przetwarzania danych. Jednak od pewnego czasu coraz dobitniej mówi się o ograniczeniach stosowalności prawa Moore’a ze względu na ograniczenia technolo­ giczne, jak chociażby najbardziej trywialne, że szerokość ścieżki nie może być mniej­ sza niż średnica atomu. W przypadku przyrostu przetwarzanych danych możemy wysnuć hipotezę, że ich przyrost jest szybszy niż liniowy i może być opisany funkcją x“, gdzie a e ( l, 2>. Bardziej w oparciu o intuicję niż rzeczywiste przesłanki skłaniam się ku hi­ potezie, że wykładnik ten powinien wynosić ■Niestety brak dostatecznie precy­ zyjnych badań skazuje nas w tej mierze na spekulacje. Pomimo to wzrost liczby prze­ twarzanych danych jest faktem. Dodatkowo możemy zakładać, że nie jest to proces, który będzie kiedykolwiek spowolniony, ograniczony. Przytoczone tutaj fakty wskazują na wagę poruszanej problematyki. Głównym narzędziem przetwarzania da­ nych są systemy zarządzania danymi i tej tematyce poświęcona jest niniejsza książka. Pierwsze próby tworzenia baz danych powinny opierać się na środowisku, które po­ zwala na łatwą autokontrolę poprawności tworzonych projektów. Takim środowiskiem jest MS Access. Dodatkowo na korzyść tej aplikacji przemawia integracja w jednym miejscu narzędzi do tworzenia struktury relacyjnej oraz programowania końcówki klienta. Atutem jest również duża zgodność ze standardem języka zapytań SQL. Książka jest przeznaczona dla osób, które rozpoczynają swoją przygodę z bazami da­ nych, i ma stanowić łagodne wprowadzenie w tę tematykę. Głównymi adresatami opra­ cowania są studenci studiów technicznych, kierunku informatyka. Nie wyklucza to odbiorców studiujących na innych kierunkach, pragnących poszerzyć swoją wiedzę o nowoczesne metody przetwarzania danych. W zasadzie dla opanowania materiału zawartego w książce nie jest potrzebna żadna wstępna wiedza, a jedynie ogólne wy­ kształcenie. Jednakże wskazana jest umiejętność posługiwania się notacją matematyczną ze szczególnym uwzględnieniem teorii mnogości. Przydatne jest posiadanie podstawo­ wych umiejętności programowania w językach wyższego rzędu, ze wskazaniem na umie­ jętność kodowania w języku Yisual Basic lub innym pokrewnym.

6

Bazy danych. Pierwsze sta rcie

Na treść książki składają się głównie praktyczne przykłady, które szczegółowo omó­ wiono. Każdy z nich został przetestowany, dlatego precyzyjne jego odtworzenie musi prowadzić do uzyskania przedstawionych rezultatów. Takie podejście spowodowało, że nie są prezentowane pełne schematy składni poleceń zawarte w dokumentacji w po­ staci zapisów z wieloma opcjami. Bardziej istotne jest przedstawienie praktycznego wykorzystania możliwości środowiska niż poznanie wszystkich potencjalnych moż­ liwości, nawet tych, których zastosowanie w praktyce jest znikome. Największy nacisk położono na przedstawienie języka SQL oraz jego zastosowania do budowania końcó­ wek klienta. Język ten jest podstawą wszystkich współczesnych systemów relacyjnych, a duża zgodność ze standardem pozwala przenieść zdobyte doświadczenie na inne środowiska. Równie istotnym elementem jest szerokie przedstawienie mechanizmów wymiany danych DAO i ADO, które, chociaż zilustrowane na przykładzie MS Access, stanowią ważne metody dostępu do danych (szczególnie ADO) dla każdego języka wyższego rzędu. Jedną z najważniejszych przesłanek wpływających na formę tej książki są słowa, jakie w sławetnej rozmowie padły z ust Bohra do jego ucznia Heisenberga — „...piszę o trudnych sprawaclt tak, aby moja żona mogła to zrozumieć”. Prostota wywodu nie ma być świadectwem „populamonaukowości”, jak to się często słyszy, a jedynie dowo­ dem zrozumienia przez autora materii, którą opisuje. Słowa te nie są świadectwem braku skromności autora wobec szerokiego zakresu omawianej tematyki, a jedynie wyrazem jego głębokiego przeświadczenia o tym, że wykłady powinny być tworzone w oparciu o wła­ sne badania i doświadczenia z konstruowaniem aplikacji — to sprzyja prostocie formuło­ wania tez. Podobnego zdania był autor najlepszego podręcznika z fizyki, R. Feynman. Książka ta jest sumą doświadczeń z wieloletniego prowadzenia wykładów z porusza­ nej w niej tematyki, zarówno na Politechnice Łódzkiej, jak i w Wyższej Szkole In­ formatyki. Od wielu lat wykłady te są oparte na tworzeniu przeze mnie „on-line” — na oczach studentów bazy danych zawierającej materiał prezentowany w tej książce. Nie bez znaczenia jest fakt kilkunastoletniej opieki nad kołem naukowym baz danych. Uwagi studentów tego gremium miały znaczący wpływ na postać tej publikacji.

Rozdział 1. la t o © ©

Om

ig

Om

W zasadzie każdy sposób rozpoczęcia tego wywodu ma istotne wady ze względu na zło­ żoną materię, w której przyszło nam się poruszać. Trudno jest jak w każdej dojrzałej na­ uce wskazać jednoznacznie miejsce, w którym się ona zaczyna. Dlatego spróbujmy tak. W najszerszym rozumieniu możemy przyjąć definicję: Każdy uporządkowany zestaw informacji nazywamy bazą danych. Abstrahujemy przy tym od sposobu organizacji i zakresu, jaki ta informacja obejmuje. Możemy zatem powiedzieć, że po pierwsze bazy danych istnieją od czasów, gdy czło­ wiek zgromadził jakiekolwiek informacje; po drugie skoro nie ograniczamy zakresu tematycznego baz danych do żadnego konkretnego zbioru ograniczonego, to opisują one wszystko. Ponieważ bazy danych w tym rozumieniu istnieją „od zawsze” i opisują „wszystko”, badania nad nimi są bez wątpienia najważniejszą dziedziną nauki. Taki wywód, mimo że jest tylko popisem „retoryki”, wskazuje jednak na wagę badania po­ ruszanych tutaj zagadnień. Dodatkową weryfikacją tego twierdzenia jest ciągle rosnące zapotrzebowanie na specjalistów z zakresu baz danych w firmach. Współcześnie interesują nas aplikacje, które zarządzają danymi zawartymi w bazie danych i przetwarzają je. Nazywamy je systemami zarządzania bazą danych (SZBD). Wielokrotnie pojęcia bazy danych i systemu zarządzania bazą danych są utożsamiane. Od początku lat 70. ubiegłego wieku króluje relacyjny model przetwarzania danych i pomimo różnych prób wprowadzenia innych rozwiązań, w zastosowaniach stanowi on ponad 90% całego rynku. W celu opisania podstaw matematycznych tego modelu wskazane jest przypomnienie podstawowych informacji z zakresu teorii mnogości.

Bazy danych. Pierwsze sta rcie

8

iP@d]sttawy fte©™ mnogości! Oznaczenia: A — zbiór, Ak— k-ty zbiór, A — kwantyfikator ogólny, nazywany również dużym, symbolizuje zwrot dla każde­ go k (zastosowano tzw. notację polską, w notacji międzynarodowej zapisujemy go w postaci V ), V — kwantyfikator szczegółowy, nazywany również małym, symbolizuje zwrot ist­ nieje takie k, że... (w notacji międzynarodowej zapisujemy go w postaci 3), ~ — operator negacji, która jest jednoargumentowym działaniem przyporządkowu­ jącym każdemu zdaniu p zdanie nieprawda, że p — czasami oznaczany również przez albo przez napis NOT, A —>B — odwzorowanie, każdemu elementowi zbioru A jest przyporządkowany je­ den element zbioru B. A <-> B — odwzorowanie wzajemnie jednoznaczne, każdemu elementowi zbioru A jest przyporządkowany jeden element zbioru B oraz każdemu elementowi zbioru B jest przypisany jeden element zbioru A, A —»—> B — odwzorowanie wielowartościowe, każdemu elementowi zbioru A jest przyporządkowany jeden lub więcej elementów zbioru B. 0 — zbiór pusty — pojęcie to jest wprowadzane jako aksjomat — każdy zbiór zawiera zbiór pusty — natomiast można próbować to pojęcie opisać przez zależności (~ Y (at * 0 )Js 0 lub Ą (at * 0 ) e 0 , {ar a2,...a n} — zbiór skończony o elementach av az,...a n. Zależności podstawowe: aŁ e At — akjest elementem zbioru Ak, u, e Al — ak nie jest elementem zbioru Ak, B c A — inkluzja zbiorów — zbiór B zawiera się w zbiorze A (B jest podzbiorem zbioru /(), czyli A (bt <=B=> bL e //), {o, s At : w(at )} — zbiór wszystkich elementów ak należących do zbioru Ak mających własność ir(aA). Rodziną zbiorów//*jest zbiór 'Jł spełniający warunek Ą /i, c '.U .

Rozdział 1. ♦ Z akres badań

9

Rodzinę zbiorów złożoną ze wszystkich zbiorów Ak, gdzie k e K , oznaczamy przez {At : k e K } . Zbiór K jest wtedy zbiorem wskaźników. Niech / będzie ustalonym niepustym zbiorem, nazywanym dalej przestrzenią ~ \ I A . cl 1. UK k Klasą zbiorów /l* jest zbiór G spełniający warunek A K e At : w(at )} => {at e G : w(a, )}. Wielokrotnie pojęcia przestrzeni, klasy i rodziny traktowane sąjako tożsame. A' = {a £ I :a £ A} — dopełnienie zbioru A do przestrzeni I. Działania na zbiorach w przestrzeni / Suma

Iloczyn

W szczególności dla pary zbiorów A i B, takich

żc A cz I a

B cl I:

Suma zbiorów A i B A u B s {a e A v a e Iloczyn zbiorów A i B A c \B = {a e A a o e B }s [a e A: a e B)= {a e B :a e A} Różnica zbiorów A i B A \ B = {a e A a a £ B} = [a e A : a e B} Jeżeli A jest przestrzenią, różnica A\B jest dopełnieniem zbioru B do przestrzeni A. Prawa de Morgana dla przestrzeni I:

10

Bazy danych. Pierwsze sta rcie

dla dwóch zbiorów A i B

Produkt (iloczyn) kartczjański Zbiór uporządkowanych par elementów a e A i b e B , gdzie a jest poprzedni­ kiem. a b następnikiem tej pary, nazywamy iloczynem kartezjańskim zbiorów A oraz B i oznaczamy przez A x B . Uporządkowany układ n elementów możemy zdefiniować rekurencyjnie

Czasami układ uporządkowany (parę uporządkowaną) nazywamy krotką. Produktem kartezjańskim zbiorów .-U, k= 1,2,...,// A. x W, x ... x A„ s X A,

nazywamy zbiór wszystkich układów uporządkowanych o postaci (at, a2, ..., o „ ), gdzie a\ s /l, dla /c = 1,2,...,//

Produkt kartezjański zbioru /I wziętego // razy A x A x . . . x A = X A s A"

Relacje Relacjąp na produkcie kartezjańskim X xY nazywamy każdy podzbiór tego produktu, czyli p c (X x y ), jeżeli przyjmiemy, że x e X oraz y e Y zapisujemy w postaci xp)\ Zbiór poprzedników par uporządkowanych {.v,y} nazywamy dziedziną relacji i ozna­ czamy przez Dp, co daje x e Dp co V (.\yąi') vef lub

Rozdział 1. ♦ Z akres badań

11

Podobnie możemy określić relację nad produktem kartezjańskim zbiorów Ak, k = 1,2,...,/?. jako dowolny jego podzbiór.

Podstawowym sposobem graficznej prezentacji danych w modelu relacyjnym jest ta­ bela. Pojęcie taicie nie jest wprowadzane w teorii mnogości, jest jednak bardzo intuicyjne. Stąd też chwilowo sformalizujmy je, przyjmując, że wiersz tabeli (RJt j = 1,2,...,/;) stanowi uporządkowany ulclad zbiorów A k, k = 1,2,...,/;,, z których każdy należy do klasy Gk

Stąd tabela stanowi uporządkowany układ wierszy RP j= l,2,...,n

Taka definicja formalna obrazuje nieznormalizowany układ danych. Należy zauważyć, że tabela jest również relacją, w której klasy Gk są dziedzinami atrybutów Ak. Pierwsza postać normalna Doprowadzenie relacji (tabeli) do pierwszej postaci normalnej jest niezbędnym krokiem posługiwania się modelem relacyjnym i pociąga za sobą dwa postulaty: Bt ^ Ak =>~ V Bk c Ak, co implikuje, że zbiory Ak są jednoelementowe skalanie; A G. n G. = 0 . co oznacza, że klasy, z których pochodzą zbiory Ak. są rozłączne.

i,J * K

J

i*J

Nie oznacza to, że nie istnieje nadrzędna klasą która zawiera kilka klas Gk. Pierwsza postać normalna jest warunkiem koniecznym istnienia schematu relacyjnego. Stąd też należy przedefiniować zgodnie z nią wiersz oraz tabelę do zapisu formalnego. Wiersz tabeli (Rj_ j - 1,2,....n) stanowi uporządkowany układ elementów ak, k=T,2,...n, z których każdy należy do zbioru Gk

Stąd tabela stanowi uporządkowany układ wierszy RjJ= l,2,...,n

Tak jak to miało miejsce w przypadku zbioru nieznormalizowanego, tabela w pierw­ szej postaci normalnej jest relacją. Jeśli relacja (tabela) jest w pierwszej postaci nor­ malnej, to zbiór wszystkich dopuszczalnych wartości atrybutów stanowi ich dziedziny.

Bazy danych. Pierwsze sta rcie

12

Inaczej mówiąc, KROTKj [ jest zbiór wszystkich uporządkowanych układów, których wartości pochodzą z ich dziedzin. KROTłwl jest przeliczalna wtedy i tylko wtedy, gdy dziedziny każdego z atrybutów są przeliczalne. Druga postać normalna Doprowadzenie relacji (tabeli) do drugiej postaci normalnej wiąże się z wprowadzeniem pojęcia klucza podstawowego. Kluczem podstawowym uporządkowanego układu ele­ mentów {Rt ,J = U ,...,n } = ( a 1,o,,...,£71) jest pewien jego podzbiór n elementów ( n e N c K Ak

e

K ), {p .,j = 1,2,...,/?}=

. Taicie określenie klucza pod­

stawowego nie wymaga istnienia elementu wiersza niewchodzącego w skład klucza, ale w praktyce jest to wyjątkowo rzadki przypadek. Stąd relacja jest w drugiej postaci nor­ malnej wtedy, gdy jest w pierwszej postaci normalnej i każdy atrybut niekluczowy zależy funkcyjnie od klucza. Wobec klucza podstawowego stawia się trzy postulaty: unikalności, zupełności oraz minimalności. Klucz jest unikalny, gdy A Pt # P . Klucz jest zupełny wtedy, gdy A a, eC,

a //?
(a1,a;,...,a„)-^{al,a;,...,a„) jeśli //? = /?, to wobec unikalności

klucza warunek ten jest zawsze spełniony. Klucz jest minimalny, gdy ~ V (m e M c K

aM

*K

an

eNc M

a

M * jV a k

e

/f )

(a„a2, . . . , a „ ) ^ ( a l,a3,...,a ,)A (a 1,a3, . . . , a i) - > ( a 1,a ,,...,a 1) Trzecia postać normalna Warunek minimalności klucza jest zapowiedzią trzeciej postaci normalnej mówiącej, że ~ V (m * M * K A n e N * K A N * M

a

k

e

(a,,a,,...,c?m) —>(o,,a2,...,a n) a

K) —>(a,,a:,...,a,}

Co pociąga za sobą lakt, że nie istnieje zależność przechodniości między kluczem głównym a żadną parą pól niekluczowych. Najbardziej trywialną konsekwencją trze­ ciej postaci normalnej jest fakt, że w tabeli (relacji) nie można przechowywać pól sta­ nowiących wyniki przekształceń deterministycznych (obliczeń) dokonywanych na którymkolwiek z pozostałych pól. Również nie powinniśmy przechowywać pól, które mogłyby być alternatywnie użyte jako klucz podstawowy, np. NIP i PESEL. Niestety z przyczyn formalnych (prawnych, administracyjnych etc.) nie zawsze ten postulat może być w praktyce spełniony. Postać normalna Boycc’a-Codda Postać Boyce’a-Codda tabeli jest uogólnieniem trzeciej postaci normalnej i mówi, że klucz podstawowy jednoznacznie określa rekord, czyli A Pf
Rozdział 1. ♦ Z akres badań

13

Wyższe postaci normalne dotyczą zależności wielowartościowych. Czwarta postać normalna ~

V(m e M

* K

An e

N * K

a

(av a2,...,a m) —>-» (ap a ,,...,a ,)

N

*

a

^

M

a

k

€

K ')

o, , . . . , ^ )

» (av a2,...,a l s)

Konsekwencją czwartej postaci normalnej jest fakt, że jeśli chcemy przechowywać właściwości mogące przechowywać wiele wartości, a dotyczące różnych cech, to po­ winny być one przechowywane w oddzielnych tabelach. Dla pracownika informacje dotyczące jego wypłat i urlopów muszą być przechowywane rozłącznie, chociaż do­ tyczą tej samej osoby. Piąta postać normalna V (m e M * K A n e N * K A N * M / \ k e K) - » — > (av a2,...,a ^ j a

(ar a2,...,a n) -> ->

(a ,, a , , . . . , a , ) a

Podstawowym skutkiem tej postaci normalnej jest konieczność umieszczania nieroz­ łącznych cech (właściwości), pochodzących z tabel podrzędnych, we wspólnej tabeli (rysunek 1.1). Przykładem może być sposób przechowywania ocen końcowych z przed­ miotów. Informacja wspólna powinna zawierać dane przedmiotu, prowadzącego oraz studenta We wszystkich przypadkach reprezentowane przez klucze obce. Nie wyklu­ cza to istnienia tabel łączących pary tych cech, ale będą one opisywały zupełnie inne zależności. Para student —» przedmiot opisuje plan studiów (roku, semestru); prowa­ dzący -> przedmiot obrazuje przydział zajęć (potencjalne kwalifikacje); prowadzący —> student wskazuje na opiekunów roku, grupy, specjalności etc. W dominującej liczbie przypadków doprowadzenie relacji do trzeciej postaci normalnej zapewnia zgodność z czwartą i piątą postacią normalną. Rysunek 1.1. Przykład piątej

postaci normalnej — reprezentacja graficzna

14

Bazy danych. Pierwsze sta rcie

Rozdział 2. [P ir< Q > jS ® l]^ < s > w a n D D @ b a z y

© ]s io !iy © & D

=

w lk o a & iO o i]©

Jako przykład omawianych w książce metod posłuży baza danych dla potrzeb zarządza­ nia małą hurtownią (sklepem). Zasadniczą częścią struktuiy relacyjnej, wykorzystywaną w większości rozważań, jest fragment składający się z trzech tabel o nazwach Działy, Osoby, Zarobki (rysunek 2.1). Pierwsza z nich opisuje strukturę organizacyjną przed­ siębiorstwa Druga zawiera dane osobowe pracowników firmy wraz z ich przypisaniem do odpowiednich działów. Ostatnia zawiera informacje o wszystkich wypłatach, każdej z zatrudnionych w firmie osób. Rysunek 2.1.

Diagram podstawowej części bazy danych

W całej książce przyjęto pewne zasady nazewnictwa. Najbardziej istotną było niesto­ sowanie polskich znaków diakrytycznych. Pomimo że narodowe wersje MS Access dopuszczają używanie znaków z rodzimych alfabetów, to ze względu na wygodę póź­ niejszego programowania zrezygnowano z tej możliwości. Podobnie nie stosowano w nazwach pól i tabel rozdzielników w postaci „spacji”. Jeśli wskazane jest stosowanie

16

Bazy danych. Pierwsze sta rcie

rozdzielników w przypadku używania długich nazw, zaleca się stosowanie znaku _ (podkreślenie) zamiast spacji. Jeśli będziemy stosowali jednak spację, to odwołanie się do pola o nazwie np. Icl Osoby wymusi stosowanie ogranicznika nazwy w postaci na­ wiasów kwadratowych — [lei Osoby], Podobnie stosowanie rodzimych znaków dia­ krytycznych może (ale nie musi, jak w przypadku spacji) wymuszać zastosowanie ogranicznika nazwy w postaci [ ] — (nawiasy kwadratowe). Definicje poszczególnych pól tabel części podstawowej opisane są w tabelach 2.1 - 2.3. Tabela 2.1 . Tabela Działy


Nazwa

Typ

Rozmiar

IdDzialu

Autolnkrementacja

4

Opis

Tekst

18

Tabela 2.2. Tabela Osoby

‘jj’

Nazwa

Typ

Rozmiar

IdOsoby

Autolnkrementacja

4

IdDzialu

Liczba całkowita długa

4

Nazwisko

Tekst

20

linie

Tekst

20

RokUrodz

Liczba całkowita długa

4

Wzrost

Pojedyncza precyzja

4

Tabela 2 .3 . Tabela Zarobki


Nazwa

Typ

Rozmiar

IdZarobku

Autolnkrementacja

4

IdOsoby

Liczba całkowita długa

4

Brutto

Waluta

8

Ważnym zadaniem jest utworzenie na kolumnach, których wartości pobierane są z ta­ beli nadrzędnej (kluczach obcych), odnośników pozwalających posługiwać się listami wartości zawartych w obiekcie nadrzędnym (rysunek 2.2). Domyślnym typem formantu jest Pole tekstowe, co oznacza, że wartości wpisywane są ręcznie, czyli odnośnik nie jest ustawiony. W definicji odnośnika dostępne są dwa typy list: Pole listy i Pole kombi o zbliżonej funkcjonalności (rysunek 2.3). Ponieważ wybór wartości dla odnośnika powinien być jednoznaczny (pole listy umożliwia wybór wielokrotny), wybieramy pole kombi, które ponadto posiada bardziej ogólną listę parametrów. Sprawdzenie różnic dla wyboru pola listy pozostawiam czytelnikowi.

17

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

Standardowo odnośnik dla pola nie jest ustawiany

Rysunek 2.2. Standardowe ustawienie właściwości Odnośnik

Odnośnik dla pola może być polem kombi lub listą

Rysunek 2.3 . Wybór typu listy dla właściwości Odnośnik

Zarówno w przypadku wyboru pola list. jak i pola kombi musimy zdefiniować typ źró­ dła danych (rysunek 2.4). Mamy do wyboru typy: Tabela/Kwerenda — dane stanowią wartości zapisane w tabeli lub zwracane przez zapytanie wybierające. Lista wartości — danymi są statyczne wartości wpisane ręcznie, oraz Lista pól — danymi są nazwy pól tabeli lub nazwy pól zapytania wybierającego. W przypadku wybrania jako źródła danych tabeli lub zapytania musimy zdecydować się na wybranie odpowiedniego obiektu źródłowego (rysunek 2.5). W opisywanym przypadku dane dla pola IdDzialu tabeli Osoby będą pobierane z tabeli Działy (rysu­ nek 2.6).

Bazy danych. Pierwsze sta rcie

18

Źródłem danych może być tabela (zapytanie), lista wartości (wpisywana ręcznie) lub lista nazw pól tabeli (zapytania)

Rysunek 2.4 . Wybór typu danych dla listy we właściwości Odnośnik

Jeśli źródłem danych jest tabela (zapytanie), możliwe jest zdefiniowanie jej nazwy

Rysunek 2 .5 . Wybór źródła wierszy dla list}’ we właściwości Odnośnik

|3

,

CHoby > |

IdOsoby

]« J g

__________

idD zlalu 4 3 4 1

/ *J-

N azw isko

-J fv KO W AU K NOWICKI

|

Imle

| RokUrodz

*

MICHAŁ

1360

'ŁUKASZ

1970

5 I p

6 3 7 4

W zrost

*|

I-Diljlu

1,60 l.B z i] ___ _____1.50

PIOTROWSKI •KRZYSZTOF

1980

1.67,

PAWLIK

'TO M ASZ

1967

1,74

1PIOTR

b !;••

8 5

KO W AL

1576

1.72

9 4

JAKÓ W

WIKTOR

1977

1.76

!2

10 3

BUŁHAKOW

EUGENIUSZ

1566

1,B3

i Ó

•|

Opis

___ Ifyiekrji

__2Tetaar.y 3 tóurJsinąa ____ 1 Handlowy 5 TtJrapcn

Rysunek 2.6 . Działanie odnośnika w przypadku kolumny związanej I oraz liczby kolumn 1

19

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

Po wybraniu tabeli Działy i pozostawieniu pozostałych parametrów w stanie domyśl­ nym lista danych jest ograniczona do tych wartości IdDzialu, które zostały wpisane do tabeli źródłowej. Należy zwrócić uwagę na parametr Kolumna związana. Określa on, z kolumny o jakim numerze w tabeli źródłowej dane przekazywane są do pola, na którym określamy odnośnik. W opisywanym przypadku kolumna IdDzialu jest pierw­ szą kolumną tabeli Działy i to ona przekazuje wartości do pola IdDzialu tabeli Osoby (strzałka na rysunku 2.6). Kolejnym istotnym parametrem odnośnika jest Liczba kolumn — co należy rozumieć jako liczbę kolumn przeznaczonych do przetworzenia w definicji pola kombi. War­ tość ta jest liczona, począwszy od pierwszej kolumny w definicji tabeli nadrzędnej do ostatniej, którą chcemy widzieć przy wyborze za pomocą pola kombi. Ponieważ inte­ resuje nas nazwa działu, która jest drugą kolumną w tabeli Działy — liczba kolumn ustawiona będzie na 2 (rysunek 2.7).

s

1

_ Sj

a' 5i| jap Si El s| |E|

M

IdOsoby

3 a J ii s! 2 i] 3 7j 4 85 9l4 joj 3 1 4

IdDzialu

Nazwisko

ES KOWAUK

3

|Dyrekcja Techniczny Administracja Handlowy Transport

| NOWICKI

-

Imle

1MICHAŁ ŁUKASZ

JANIK PIOTROWSKI

KRZYSZTOF

PAWLIK KOWAL

TOMASZ PIOTR

JAKÓW

WIKTOR

PIOTR

1BUŁHAKOW

EUGENIUSZ

|KOW

WIT

*| Wzrost * 1 1,60 1360 1370 _____ 1,821 1,90. 1375; 1380 1,671 1,74: 1367 1376 1.72 1377 1,75; 1,83 I______ 1366_ 1374: 1,75|

* j| RokUrodz

Rysunek 2.7 . Działanie odnośnika w przypadku kolumny związanej 1 oraz liczby kolumn 2

Dotychczas przeprowadzona definicja odnośnika powoduje, że pomimo wyświetlenia na liście nazw działów po wybraniu jednego z nich w oknie pola kombi wyświetlana jest informacja o jego numerze. Wynika to z tego, że w takim stanie jest wyświetlana pierwsza widoczna kolumna definicji — IdDzialu. Aby kolumna nie była widoczna, jej szerokość na liście kolumn należy ustawić na 0. Ustawianie szerokości kolumn odbywa się zgodnie z formatem -0;2;0 (pierwsza i trzecia kolumna niewidoczna, druga ma szerokość 2 cm). Jeśli format będzie o postaci — 0;;0 (opuszczono definicję szerokości drugiej kolumny), to jej szerokość zostanie ustawiona automatycznie przez MS Access (rysunek 2.8, 2.9). Według takiego samego schematu możemy zdefiniować odnośnik w tabeli Zarobki na polu IdOsoby, tak aby posługiwać się nazwiskami pracowników (tabela Osoby) (ta­ bela 2.4). Sformułowanie takiego odnośnika, w którym wyświetlane jest imię i nazwisko pracownika, wymaga stworzenia zapytania i będzie przedstawione później. W niektórych przykładach, gdzie konieczne okaże się odwołanie do bardziej złożonej struktury danych, używany będzie model relacyjny wzbogacony o tabele związane z realizacją zadań handlowych firmy (rysunek 2.10). Definicje pozostałych tabel aplikacji zawarto w tabelach 2.5 -2 .9 .

Bazy danych. Pierwsze starcie

20

2 3 Owby

Nazwa pola

Typ danych lAutonum erow anle | Liczba |Tekst |Tekst (Liczba i Liczba

^ JdOsoby IdDzialu Nazwisko Imię RokUrodz Wzrost

Opis i

▼

Wlasciwolcl nola | Oflólne | Odnośnik | jTypformanlu 1Pole kombi |Typ źródła wierszy lTabelaA'werenda .Źródło witrsry lOziaiy Kolumna związana ll |liczba kolumn |2 (Nagłówki kolumn {Nie Szerokości kolumn |0cm;2cm| Liczba wierszy listy |B Szerokość listy (Automatyczna (Ogranicz do listy (Tal: Zezwalaj na wiele wart oś 1Nie IZerwalJl na edytlę listy W Nie (Formularz edycji element* iPok32 tylko wartości żród Nie

Szerokości kolumn w wielokolumnowej liście tub polu kombi.

Rysunek 2.8 . Ostateczne ustawienie parametrów dla właściwości Odnośnik

3J E S E I?] E E s" b'

_____ __ - I IdDzialu ' Nazwisko _31!recrnicznv^B(W(iB8SflL’' |KOWALIK

IdOsoby

4 | Dyrekcja

5P*ećhn»czny 6 Administracja 7, Handloy/y a Transport Handlowy

10Administracja

-

|NOWICKI JANIK PIOTROWSKI PAWUK KOWAL JAKÓW BUŁHAKOW

j

Imię

- 1 RokUrodz

MICHAŁ__ ŁUKASZ PIOTR KRZYSZTOF TOMASZ PIOTn WIKTOR EUGENIUSZ

*|

1960 1970 1975. 1980 19S7i 1976 1977, 1966

Wzrost

-] 1.60 1,82| 1.90j_ 1,67| 1,74! 1.72] 1.76 1,83!

Rysunek 2.9 . Działanie odnośnika w przypadku ostatecznego ustawienia parametrów Tabela 2.4. Zarobki definicja odnośnika Nazwa

Odnośnik param etr

Odnośnik w artość

IdOsoby

.KolumnaZ wiązana:

1

.LiczbaKoluinn:

3

.SzcrokościKolumn:

0;0

.TypFormantu:

Pole kombi

.TypŹródlaWierszy:

Tabel a/Kwcrenda

.Źródło Wierszy:

Osoby

Również dla pozostałych tabel zawierających klucze obce możemy zbudować odno­ śniki. W podstawowym przypadku mogą one być zdefiniowane tak, jak pokazano w tabelach 2.10 - 2.12. Tak samo jak w przypadku poprzednio omawianych tabel definicje odnośników zo­ staną zmodyfikowane po omówieniu sposobu tworzenia zapytań wybierających.

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

Rysunek 2 .1 0 . Diagram bazy danych Tabela 2.5. Tabela Faktura

^

Nazwa

Typ

Rozmiar

IdFaktura

Autolnkrementacja

4

IdKlient

Liczba całkowita diuga

4

Data

Data/Godzina

8

IdOsoby

Liczba całkowita długa

4

Tabela 2.6. Tabela Klient

^

Nazwa

Typ

Rozmiar

IdKlient

Autolnkrementacja

4

Nazwisko

Tekst

20

Imic

Tekst

20

Tabela 2.7 . Tabela Producent

^

Nazwa

Typ

Rozmiar

IdProducenta

Autolnkrementacja

4

Nazwa

Tekst

15

Tabela 2.8. Tabela Towar

^

Nazwa

Typ

Rozmiar

IdT owaru

Autolnkrementacja

4

Nazwa

Tekst

15

Cena

Waluta

8

IdProducenta

Liczba całkowita długa

4

21

22

Bazy danych. Pierwsze sta rcie

Tabela 2.9 . Tabela Transakcja


Nazwa

Typ

Rozmiar

ldTransakcji

Autolnkrementacja

4

IdFaktura

Liczba całkowita długa

4

IdTowaru

Liczba całkowita długa

4

Tabela 2.1 0 . Tabela Faktura— definicja odnośnika Nazwa

Odnośnik param etr

IdKlient

.KołumnaZwiązana:

1

.LiczbaKolumn:

2

.SzerokościKolumn:

0

IdOsoby

Odnośnik w artość

.TypFormantu:

Pole kombi

.TypŻródlaWierszy:

Tabela/Kwcrenda

.ŹródłoWierszy:

Klient

.Kol umnaZ wiązana:

I

.LiczbaKolumn:

3

.SzerokościKolumn:

0;0

.TypFormantu:

Pole kombi

.TypŻródłaWicrszy:

Tabela/Kwerenda

.ŹródłoWierszy:

Osoby;

Tabela 2 .11. Tabela Towar— definicja odnośnika Nazwa

Odnośnik param etr

IdProducenta

.KołumnaZwiązana:

1

.LiczbaKolumn:

2

.SzerokościKolumn:

0

.SzerokośćKolumny:

Domyślny

Odnośnik w arto ść

.TypFormantu:

Pole kombi

.TypŻródlaWierszy:

Tabela/Kwerenda

.ŹródłoWierszy:

Producent;

Tabela 2 .1 2 . Tabela Transakcja— definicja odnośnika Nazwa

Odnośnik param etr

Odnośnik w artość

IdTowaru

.KołumnaZwiązana:

1 2

.LiczbaKolumn: .SzerokościKolumn:

0

.TypŻródlaWierszy:

Tabela/Kwerenda

.ŹródłoWierszy:

Towar

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

23

WDZMaDm©tworzenie zapytam Jednym z kardynalnych zadań, jakie są stawiane przed bazą danych, jest zapewnienie możliwości sprawnego wybierania interesujących nas danych. Podstawowym narzę­ dziem służącym temu zadaniu są zapytania, w polskiej wersji MS Access nazywane kwerendami. Ponieważ w terminologii baz danych utarło się stosowanie tej pierwszej nazwy, w dalszej części rozważań będzie ona konsekwentnie używana (niezgodnie z nazewnictwem zaproponowanym w tym środowisku). Autor uważa, że przetłuma­ czenie angielskiego Oueiy na „kwerenda” świadczy o braku doświadczenia z zakresu baz danych u twórców polskiego nazewnictwa stosowanego w bazach danych. Jedną z potencjalnych możliwości budowania zapytań stanowi zastosowanie narzędzia do ich wizualnego konstruowania Narzędzie to jest chętnie wykorzystywane zwłaszcza przez osoby o małej biegłości w zakresie baz danych. Osoby z większym doświadcze­ niem z reguły wolą posługiwać się językiem zapytań SQL, który oferuje o wiele większe możliwości (dokładny opis składni z przykładami jest zawarty w kolejnym rozdziale). Zbudujmy zapytanie, które wyświetli IdOsoby, Imię i Nazwisko. Natomiast rekordy będą sortowane najpierw względem pola Nazwisko, a w obrębie grupy takich samych nazwisk po zawartości pola Imię (rysunek 2.11).

Rysunek 2 .1 1 . Wizualna definicja zapytania wybierającego z sortowaniem

Należy zwrócić uwagę, że o kolejności sortowania decyduje kolejność pól, na których określono właściwość Sortuj, licząc od lewej strony do prawej. Stąd pojawiła się ko­ nieczność ponownego użycia pola Imię, gdyż kolejność wyświetlanych pól różni się od kolejności sortowania. Ponieważ powielenie informacji zawartych w tymi polu nie jest konieczne, stąd właściwość Pokaż ustawiono na nie (niezaznaczone pole typu check box). W poprzednim zapytaniu wyprowadzana była tylko zawartość pól zdefiniowanych w tabeli źródłowej. Możliwe jest także wyświetlenie informacji stanowiącej wyrażenie o te pola oparte (rysunek 2.12).

24

Bazy danych. Pierwsze sta rcie

Rysunek 2 .1 2 . Wizualna definicja zapytania wybierającego z wyrażeniami

Zapylanie zawiera bardzo często występujące w praktyce pole zawierające konkalenację (połączenie zmiennych łańcuchowych) pól Nazwisko i Imię. Aby nie nastąpiło „sklejenie” obu składników wyrażenia, zastosowano trzeci łańcuch zawierający znak „spacja” (możliwe jest użycie innych znaków rozdzielających). Napis występujący przed dwukropkiem poprzedzającym definicję pola jest tzw. aliasem pola, czyli nazwą, pod którą wyrażenie będzie wyświetlane podczas przetwarzania zapytania. Możliwe jest stosowanie, jak pokazano w przykładzie, innych (wszystkich dostępnych w środowisku) operatorów. W czwartej kolumnie definicji zapytania obliczany jest współczynnik Wzrost/RokUrodz. Nie ma on żadnego znaczenia praktycznego, a jest oczywiście tylko ilustracją potencjalnych możliwości. W trzeciej kolumnie pole zawiera wyrażenie oparte o wewnętrzną funkcję środowiska— Ucase(Nazwisko), powodującą wypisanie zawartości pola Nazwisko dużymi literami. Tak samo jak w przypadku operatorów, tak i w przypadku funkcji prawdziwym jest stwierdzenie, że do definicji pola wynikowego możliwe jest zastosowanie każdej funkcji zdefiniowanej w środowisku systemu zarządzania bazą danych. Kolejną wmzną czynnością, którą można zdefiniować w zapytaniu, jest możliwość filtrowania rekordów' (rysunki 2.13 do 2.16).

Rysunek 2 .1 3 . Wizualna definicja zapinania wybierającego zfiltrowaniem (niejawne ićy>cie operatora AND)

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

25

W celu wyświetlenia części rekordów zapisanych w tabeli możliwe jest wpisanie we właściwości Kryteria wyrażenia logicznego. Wyświetlane będą tylko te rekordy, dla któ­ rych wartość wyrażenia jest prawdziwa (TRUE). Możliwe jest również łączenie pro­ stych wyrażeń za pomocą operatorów logicznych. Niejawnie można wykorzystać cechę, że gdy dwa warunki dotyczą różnych kolumn, to niejawnie łączone są one operatorem logicznym AND (rysunek 2.13). Po zapisaniu reprezentacja takiego warunku staje się jednak jawna zgodnie z tym, co pokazano na rysunku 2.14. Oczywiście taką postać warunku można od razu wpisać w definicji zapytania, nie czekając, aż mechanizmy wizualnej prezentacji zapytań wykonają to zamiast nas. Rysunek 2.14. Wizualna definicja zapytania wybierającego z filtrowaniem (jawne użyjcie operatora AND)

Podobnie możemy postąpić, gdy chcemy zastosować do połączenia operator logiczny OR (rysunek 2.15). Tym razem jednak dokonujemy tego w sposób niejawny, wpisując składniki wyrażenia „piętrowo” w kolejnych komórkach „lub:” właściwości Kryteria. Rysunek 2.1 5 . Wizualna definicja zapytania wybierającego z filtrowaniem (niejawne użycie operatora OR)

Możliwe jest również użycie jawne operatora OR. analogicznie jak to miało miejsce w przypadku operatora AND (rysunek 2.16). W środowisku SQL zdefiniowane są wszyst­ kie operatory algebraiczne oraz jednoargumentowy operator przeczenia NOT. Lista do­ puszczalnych operatorów w MS Jet SQL jest precyzyjnie omówiona w rozdziale dotyczącym składni języka SQL.

Bazy danych. Pierwsze starcie

26

Rysunek 2.16. Wizualna definicja zapylania wybierającego z filtrowaniem (jawne ui)’cie operatora OR)

51 nrin ^ Osoby IdO so by

IdDzialu tlajwisko

Imię RcLUmcJ: Wzrost

lEL Pole IdOsoby Tabelo: Osoby Sortuj: Pokaż: 0 Kryteria: lub: *

Nazwisko Osoby 0

flokUrodz Osoby 0 <1970 0r>1930

n

Ważna uwaga dotyczy separatorów stosowanych w listach operatorów i argumentów wy­ wołania funkcji. W części wizualnej jest to zawsze znak średnik (;), podczas gdy pisząc 10 samo wyrażenie w SQL, używamy jako separatora znaku przecinka (,) (tabela 2.13). Tabela 2 .13. Przykład różnic w interpretacji separatorów w części wizualnej i SOL Znaczenie

W części wizualnej

W SQL

Lisia wartości

IN (1987; 1970; 1975)

IN (1987, 1970, 1975)

Funkcja warunkowa

IIF (a>2; 1;0)

IIF (a>2, 1,0)

Ta dwojakość reprezentacji wywodząca się w części wizualnej od innych aplikacji MS Office, a w SQL ze standardu tego języka, bywa bardzo uciążliwa, zwłaszcza dla mniej doświadczonych programistów. Oczywiście w tym miejscu można by poświęcić przynajmniej jeden bardzo obszerny rozdział omówieniu funkcji wbudowanych. Jednakże dokonywane było to tak często i w tak wielu pozycjach dotyczących zarówno Accessa, jak i innych składowych pa­ kietu Office, że nie wydaje się to szczególnie zasadne. Ważną cechą projektow'ania zapytań jest możliwość parametryzowania warunków tak, aby zmiana filtra nie wiązała się z koniecznością ponownego jego projektow'ania (udo­ stępnienie użytkownikowi końcowemu możliwości edytowania struktury zapytań wiąże się z bardzo dużym, praktycznie 100-procentowym, prawdopodobieństwem „zniszcze­ nia" bazy). Parametrem (zmienną) w wizualnej definicji zapytania jest dowolny napis umieszczony w nawiasie kwadratowym, różny od nazwy jakiegokolwiek pola w ta­ beli (tabelach), w oparciu o którą jest ono budowane (rysunek 2.17). Uruchomienie takiego zapytania powoduje wyświetlenie przed jego wykonaniem okienka typu input box pozwalającego na wprowadzenie aktualnej wartości parametru (rysu­ nek 2.18). Wartość ta jest podstawiana pod nazwrę parametru, a następnie po wyczer­ paniu wszystkich wartości parametrów' zapytanie jest wykonywane tak jak zapytanie ze statyczną postacią wyrażenia filtrującego. Nazwa parametru jest jednocześnie komu­ nikatem umieszczonym na tym okienku dialogowym. Stąd też w większości przypad­ ków' używ-ane być powinny dłuższe, bardziej opisowe nazwy parametrów. Pozwalają one na lepsze zrozumienie przez obsługę, jaka wartość jest wprowadzana. Niestety

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

27

Rysunek 2.17. Wizualna definicja zapytania wybierającego z filtrowaniem parametrycznym

Rysunek 2 .18. Widok okienka Input Box służącego do wprowadzenia wartości parametru

stosowanie długich nazw jest również źródłem błędów przy parametryzacji zapytań. Jeżeli w definicji zapytania użyjemy większej ilości parametrów, to kolejność wy­ świetlania okienek dialogowych input box będzie odpowiadała kolejności występowa­ nia parametrów w definicji zapytania, patrząc od lewej do prawej strony jego wizualnej postaci. Wybranie na którymkolwiek okienku przycisku Anuluj spowoduje przerwanie przetwarzania zapylania. Ponieważ dla okienka dialogowego typu input box nie można jawnie zdefiniować po­ staci wprowadzanych danych, możliwe jest wprowadzenie zarówno wartości liczbowej, jak i tekstowej czy też daty. Może to powodować w większości przypadków błędy przetwarzania. Częściowym rozwiązaniem tego problemu jest zdefiniowanie typu pa­ rametru z poziomu menu — jak to pokazuje rysunek 2.19 oraz 2.20.

Rysunek 2.19. Wizualna definicja zapytania wybierającego z filtrowaniem (definiowanie typu parametru)

28

Bazy danych. Pierwsze sta rcie

Rysunek 2.2 0 . Wizualna definicja zapylania wybierającego z filtrowaniem (definiowanie typu parametru)

Patrząc na definicję typu parametru, widzimy takie same typy danych, jakie mogą nam posłużyć do określenia typów pól w definicji tabeli (rysunek 2.20). Po wybraniu typu parametru i po jego wprowadzeniu wykonywane jest sprawdzenie jego zgodności z zadeklarowanym typem. W przypadku braku zgodności wyświetlany jest komunikat o błędzie, po zatwierdzeniu którego ponownie pojawia się monit o wprowadzenie błęd­ nie uprowadzonej wartości. Procedura odbywa się cyklicznie aż do momentu wpro­ wadzenia poprawnej co do typu wartości lub wybrania przycisku Anuluj na okienku dialogowym (rysunek 2.21).

Rysunek 2 .2 1 . Komunikat w przypadku niezgodności typu wprowadzanych danych z ich definicją

Wydawać by się mogło, że rozwiązanie takie pozwala na pełną kontrolę nad typem wprowadzanych danych. Niestety nie jest to prawdą. Rozróżnienie typu odbywa się na poziomie rozróżnienia typów znakowych, liczbowych i daty, a nie na poziomie ich szczegółowej definicji. Na przykład jeśli zdefiniujemy liczbę jako całkowitą, zaakcep­ towane zostaną zarówno liczby całkowite, jak i rzeczywiste, co znacznie zmniejsza funk­ cjonalność takiego rozwiązania. Ponadto czym innym jest parametr zdefiniowany (typ),

Rozdział 2. ❖ Projektow anie bazy danych — narzędzia wizualne

29

a czym innym parametr użyty w zapytaniu. Jeżeli parametr zostanie zdefiniowany, a nie będzie użyty w definicji zapytania, to i tak pojawi się monit o podanie jego wartości. Pojawiają się dość często (zwłaszcza przy stosowaniu długich nazw) błędy literowe, które powodują, że mogą pojawić się „fałszywe" dodatkowe parametry' podczas wyko­ nywania zapytania. Innym często spotykanym przypadkiem jest wyświetlenie zachęty do wprowadzania wartości parametru, podczas gdy w definicji zapytania programista świadomie ich nie definiował. Wynika to również najczęściej z błędów literowych podczas definiowania pól wyświetlanych przez zapytanie (głównie podczas tworzenia wyrażeń). Jak to zostało zdefiniowane, parametrem może być dowolny napis różny od nazwy pól, stąd jeśli popełnimy błąd przy zapisie nazwy połą traktowane jest ono tak jak nazwa parametru. Należy pamiętać, że zgodność dwóch napisów jest sprawdzana z dokładnością co do znaku (wliczając w to znaki niewidoczne, np. spacje), natomiast nie jest rozróżniana wielkość liter. Rozważmy przypadek, że nasza baza obsługuje firmę, w której po upływie określonego okresu rozliczeniowego wykonywane są bilanse, które oparto o zapytania z parame­ trami. W każdym z wykonywanych zapytań definiowany jest parametrycznie okres rozliczeniowy (od - do). Powoduje to, że w każdym zapytaniu konieczne jest podanie dwóch wartości (w każdym z nich takich samych). Osoba obsługująca musi więc n-krotnie podać te wartości. Po pierwsze jest to bardzo irytujące, gdyż wystarczyłoby podać je raz i przekazać jakąś metodą do zapytania. Po drugie zawsze w takim przy­ padku istnieje duża szansa pomyłki (głównie spowodowana czynnikiem pierwszym oraz znużeniem przy powielaniu takiej samej informacji), co może prowadzić do otrzymania części podsumowań dla nieprawidłowego zakresu. Rozwiązaniem większości problemów związanych ze stosowaniem zapytań z parametrem jest zastąpienie ich mechanizmem zapytanie przez formulaiz (query by form), opisanym w kolejnym podrozdziale.

¥

w

® o°z ©

biid ©

^ m ra m o H a rz y

Omawiane dotąd elementy systemu zarządzania bazą danych, zarówno tabele, jak i zapytanią nie powinny być używane do wprowadzania czy też edycji danych. Pomimo tego, że dane mogą być wprowadzane bezpośrednio do tabel, powinny one stanowić tylko miejsce ich przechowywania. Również w przypadku zapytań wybierających bez zdefiniowanych wyrażeń (opartych bezpośrednio o pola w pojedynczej tabeli) możliwe jest w wielu przypadkach wprowadzanie danych, jednak ich funkcją zasadniczą (głów­ nie ze względu na postać graficzną ale również ze względu na brak możliwości pre­ cyzyjnego zdefiniowania metod walidacji i obsługi zdarzeń) jest przetwarzanie danych. Aby do tabeli wprowadzić dane za pomocą zapytania wybierającego, pomijane pola powinny spełniać co najmniej jeden z trzech postulatów: ❖ pole umożliwia przyjęcie wartości pustej, nieokreślonej (NULL); ❖ pole ma zdefiniowaną wartość domyślną (przyjmowaną wtedy, gdy jawnie nie określimy jego wartości); ❖ pole jest automatycznie inkrementowane (kolejne wartości tego pola są generowane na podstawie już istniejących — najczęściej zgodnie z kolejnymi wartościami liczb naturalnych, rzadziej losowo).

30

Bazy danych. Pierwsze sta rcie

Zapytanie wybierające zapisane w bazie danych w większości aplikacji nazywane jest perspektywą lub widokiem ( View). Elementem systemu zarządzania bazą danych specjalnie dedykowanym dla potrzeb edycji danych w tabelach pozostaje formularz. W większości przypadków jest on oparty o ta­ belę. dość często również o perspektywę, czyli zapisane zapytanie wybierające. Pierwszym krokiem jest próba zbudowania formularza za pomocą kreatora (tysunek 2.22). Aby nie rozpoczynać od zagadnień trywialnych, spróbujmy zbudować formularz oparty o dwie tabelę. Ma on pozwolić na wprowadzanie i edytowanie danych osób, a dla każdej z nich wprowadzanie i edycję ich zarobków brutto. Rysunek 2.2 2 .

Zastosowanie kreatora do tworzenia formularzy

W tym celu z dwóch zdefiniowanych poprzednio tabel wybierzmy pola: JdDzialu, Nazwisko, Imię, RokUrodz, Wzrost z tabeli Osoby oraz Brutto z tabeli Zarobki (rysu­ nek 2.23). Rysunek 2.2 3 . Zastosowanie kreatora do tworzenia form ularzy— wybór pól wyświetlanych w formularzu

31

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

Przy próbie przejścia do kolejnej funkcji kreatora (przycisk Dolej) otrzymujemy ko­ munikat mówiący, że wybrane zostały pola z tabel niepowiązanych ze sobą (dokładną treść wyświetlanego komunikatu przedstawia rysunek 2.24). Rysunek 2.24.

in jim iM iJjm i.rm i.ffi, a a i

Zastosowanie kreatora do Morzenia formularz)’ — komunikat o wybraniu pól z niepowiązanych tabel

Krcnlor (otmul.u/y Jakiś pcte moją być urrtenacne w forooJoraj?

'Kreator formularzy

A „ti

Wybrano poło 2 następujących taheł: Osoby, Zarobki; przynajmn*) jrdna z tych tabel r-*e jest pcwlyaru* relację 2 myrri. Klkmj prryask Ck', aby edytować relacje systemowe. Musisz michcrneć ponownie Izeatcra. KJknłj Anuluj, eby powrócić do beatera Iusunęć niektóre pda.

Ma |>> I Nazwtsko

----- Imco

Grup L2J

CU

lA i

RckJJrodz Wzrost

E3

Anuluj

Wstucj "~l1

Qale| >

11

Zabote

Zatwierdzenie okienka typu message box przenosi użytkownika do miejsca tworzenia diagramu bazy danych, w Accessie nazywanego dość niefortunnie relacjami (rysunek 2.25). Mechanizm tworzenia diagramu (relacji) jest przy założeniu wymuszania więzów in­ tegralności równoważny tworzeniu kluczy obcych w tabeli podrzędnej (szczegółowe wyjaśnienie zawiera rozdział poświęcony SQL). Brak zdefiniowanych połączeń między tabelami uniemożliwia funkcjonowanie kreatorów, ale nie jest niezbędny dla poprawne­ go działania bazy ani zbudowanych „ręcznie” formularzy. W tym miejscu musimy doko­ nać wyboru tabel, które będą ze sobą połączone (będą wymieniać między sobą informacje — dane). W naszym przypadku musimy wybrać obie tabele, w oparciu o które chcemy zbudować formularz (Osoby i Zarobki) — rysunek 2.25. Rysunek 2.25. Zastosowanie kreatora do Morzenia formularzy’ — diagram baz)’ danych („relacje"), wybór tabel

r~

~~ |ldOsoby IdDcliu .Narwłsko Imto

jRcftJrcdt Wzrost

_______ pre—nr. IdOsoby

Brutto

i

32

Bazy danych. Pierwsze starcie

Po wybraniu obu tabel i zamknięciu okienka dialogowego Pokazywanie tabeli należy zdefiniować, które pola wymieniają między sobą informacje. W naszym przypadku będą to pola o nazwie IdOsoby pochodzące z obu tabel (rysunek 2.26). Stosowanie takich samych nazw dla łączonych pól (najczęściej klucz główny i klucz obcy) nie jest ko­ nieczne. ale zapewnia większą czytelność bazy— jej diagramu. Połączenie pól jest wykonywane przez przeciągnięcie nazwy jednego pola na nazwę odpowiedniego pola w drugiej tabeli (kierunek przeciągania nie odgrywa żadnej roli). W wyniku tego dzia­ łania pojawia się okienko Edytowanie relacji, na którym widoczne są łączone pola. Rysunek 2.2 6 . Diagram bazy danych— tworzenie połączenia miądzy tabelami

Z poziomu tego okienka dialogowego możliwe jest przejście do kolejnego formularza w celu zdefiniowania typu tworzonego sprzężenia (rysunek 2.27). Określamy tutaj, w jaki sposób mają być wyświetlane rekordy z połączonych tabel. Domyślnym stanem jest taki, gdzie wyświetlane są te rekordy z obu tabel, dla których prawdziwy jest warunek łączący — czyli powiązane pola w obu tabelach mają tę samą wartość. Jeżeli zatem istnieje taka osoba, która nie pobierała jeszcze wynagrodzenia, to skutkiem takiego połączenia nic zostanie wyświetlona w zapylaniu wynikowym opartym o takie złączenie. Również jeśli istnieje wyplata, która nie ma właściciela (w potocznym rozumieniu „lewa kasa”), także nie zostanie uwzględniona w zapytaniu wynikowym. Na szczęście w przypadku tworzenia formularzy zespolonych takie obostrzenia nic wy­ stępują — dotyczą one tylko tworzenia zapytań — w związku z tym możemy pozo­ stawić domyślny stan złączenia. Oprócz kierunku złączenia (rysunek 2.28) możliwe jest ustawienie również wymuszania więzów integralności (rysunek 2.26, 2.29). Wymuszenie więzów integralności zapew­ nia, że nie jest możliwe wpisanie do tabeli podrzędnej wartości nieistniejącej w tabeli nadrzędnej. Eliminuje to przedstawiony przy omawianiu kierunku złączenia problem „lewej kasy”. Jednak takie podejście nie zawsze jest uzasadnione. Rozważmy przykład, kiedy w naszej firmie chcemy zatrudnić praktykanta Nie jest wtedy konieczne przypisy­ wanie go do jakiegoś działu — niestety wymuszenie więzów integralności powoduje ko­ nieczność wykonania taicie] operacji lub stworzenia nowego, fikcyjnego z punktu widzenia

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

33

Rysunek 2 .27. Diagram bazy danych — wybór typu sprzężenia

Zawiera tyła te wiersze, w Hćrych sprzęzcnc pda 2 obu tabds^rćwne. Uwzględnia WSZYSTKIE rekordy z 'Osoby' I ty ła te rekordy z ‘Zarobki*, cfa których sprzężone pola są równe. Uwzględnia WSZYSTKIE rekordy z *Zarobk' I ty ła to rekordy 'Osoby', da Itćrych sprzę cns pda są równe.

2

2

OK

Rysunek 2.29. Diagram bazy danych, połączenie: A) bez wymuszenia więzów integralności B) z wymuszeniem lrręróii’ integralności

_ O soby IdOsoby IdDzlaiu Nazwisko Imię Roltlrodz Wzrost

ZŁ

Rysunek 2 .2 8 . Diagram baz)’ danych — definiowanie kierunku złączenia: A) złączenie „ lewe " B) złączenie „prawe ”

3C

Anuluj

i

.........

IldZarabhj IdOscby 1Brutto

1IdOsoby IbDzidu Nazwisko |lm£s RckUrodz Wzrost

IjldZoroUaj IdOscby [iBrutto

* £ R o la c jo

§39 L t o s iijy

I d Z a r t t iu Id O s c b y JB r u t t o

j ld D z Ł s łu fJ a im k o l lm c IR d U ro d z iW z r o s t

A

B

funkcjonowania firmy, działu Praktykanci. Mnożenie fikcyjnych bytów, czyli działanie niezgodne z zasadą Ockhama. prowadzi zawsze do bałaganu. W związku z tym przy wyborze między wymuszaniem więzów lub pozostawieniem stanu domyślnego powin­ niśmy dobrze rozważyć argumenty za i przeciw podjęciu którejś z decyzji. Kolejnym skutkiem wprowadzenia wymuszania więzów jest blokowanie usuwania re­ kordów lub modyfikacji pól klucza. Wyobraźmy sobie dwie tabele: O soby i N agrody. połączone za pomocą pola IdOsoby. Załóżmy, że zatrudniamy pana Nowaka, który już na początku wykazał się wyjątkową pracowitością, za co został nagrodzony. W związku z tym w tabeli N agrody pojawi się wpis z kluczem obcym o wartości równej identyfi­ katorowi pana Nowaka. Jeżeli teraz nasz pracownik będzie musiał zostać zwolniony

34

Bazy danych. Pierwsze starcie

— czy na skutek reorganizacji, czy też jego działalności — to pojawi się pewien pro­ blem. Próba usunięcia rekordu z tabeli Osoby zakończy się niepowodzeniem na skutek istnienia powiązanego rekordu w tabeli Nagrody. Jeżeli więc będziemy chcieli usunąć ten rekord, najpierw musimy usunąć wszystkie powiązane rekordy — czyli wszystkie nagrody przyznane panu Nowakowi. Dopiero po tym kroku możliwe jest usunięcie tego rekordu z tabeli Osoby, który zawiera dane zwalnianej osoby. Rozważmy teraz przypadek, kiedy identyfikator (IdOsoby) nie jest tylko generowanym automatycznie numerem unikatowym, ale pełni też funkcję logiczną, np. jest numerem karty identy­ fikacyjnej (przypuśćmy, że jest to karta magnetyczna pełniąca funkcję klucza, która pozwala na wejście do różnych pomieszczeń w zależności od uprawnień pracownika). Tak jak poprzednio pan Nowak po przyjęciu do pracy został nagrodzony, następnie zgubił swoją kartę identyfikacyjną. Musimy teraz unieważnić starą kartę naszego pra­ cownika i wydać mu nową. W bazie danych odpowiada to zmianie wartości klucza pod­ stawowego dla rekordu opisującego pana Nowaka. Ze względu na wymuszenie więzów integralności oraz istnienie powiązanych rekordów w tabeli podrzędnej próba zmiany wartości klucza kończy się komunikatem o błędzie. Oczywiście możliwe jest obejście tego problemu w ten sposób, że najpierw tworzymy wpis dla pana Nowaka z nową wartością pola klucza. Następnie przepisujemy wszystkie nagrody, które on uzyskał, z nową wartością klucza obcego (po stronie tabeli Nagrody). Na koniec kasowany jest wpis dotyczący pana Nowaka ze starą wartością klucza (po stronie tabeli Osoby). Oba te kłopotliwe przypadki możemy uprościć, zaznaczając opcje kaskadowego usu­ wania lub aktualizacji połączonych rekordów (rysunek 2.26). Jednakże o ile w przy­ padku kaskadowej aktualizacji pól działanie takie nie budzi większych oporów, o tyle ustanowienie kaskadowego usuwania połączonych rekordów może wiązać się z dużymi perturbacjami. Jeśli w naszej strukturze podstawowej wszystkie tabele połączymy z wy­ muszeniem więzów i kaskadowym usuwaniem, możemy dojść do następującej sytuacji. W trakcie reorganizacji zmieniono strukturę podziału na działy, przy czym część ze starych jednostek organizacyjnych została zlikwidowana. Podczas reorganizacji bazy danych mamy sytuację, w której część osób jest przypisanych do starych jednostek, a część do nowych. Jeśli w takim stanie pojawi się „nadgorliwy” operator, który wyka­ suje nie do końca zwolniony z pracowników dział, to nie dość, że stracimy informa­ cje o nieprzeniesionych jeszcze pracownikach, to jeszcze usunięte zostaną wpisy doty­ czące ich wypłat — co daje z punktu widzenia księgowości manko — niedobór środków finansowych. Taki stan jest już z punktu widzenia prawnego groźny. Oczywiście mo­ żemy zawsze odzyskać dane z kopii bezpieczeństwa (o ile je robiliśmy?!), ale to zaw­ sze pociąga za sobą dodatkowe koszty, choćby w postaci dodatkowego nakładu czasu. Czyli wymuszenie kaskadowego usuwania powiązanych rekordów może okazać się groźne. Należy podkreślić, że podstawowym zadaniem bazy danych jest przechowywanie jak najszerszej informacji. W związku z tym dane powinny być do niej dodawane, a ich usu­ wanie powinno pojawiać się tylko epizodycznie (o ile jest absolutnie niezbędne). Czasami również aspekty prawne zabraniają nam usuwania danych, np. zaksięgowanej faktury się nie zmienia (edytuje, modyfikuje), natomiast wystawia się drugą, korygującą, fakturę. Ta tendencja do pozornego porządku polegającego na usuwaniu informacji historycznej jest jednym z częstszych błędów początkujących twórców baz danych. Jeśli chodzi o przypadek z numerem karty magnetycznej pana Nowaka, to nie musi on być identyfikatorem (kluczem podstawowym) — wystarczy, aby spełniał postulat

35

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

unikalności. Można również rozważyć przypadek, kiedy zapisujemy wszystkie nu­ mery kart kiedykolwiek wydanych pracownikowi — takie rozwiązanie (bardzo uzasad­ nione) wymaga dodatkowej tabeli. Poruszone w tym miejscu problemy stanowią najbardziej podstawowe dylematy, przed którymi staje programista w momencie projektowania schematu relacyjnego. Z punktu widzenia języka SQL, który jest podstawowym narzędziem projektowania i przetwa­ rzania danych, poruszane tutaj kwestie są związane z tworzeniem kluczy obcych i zo­ staną omówione w kolejnym rozdziale. Powróćmy teraz do zasadniczego nurtu — tworzenia formularza zespolonego (zespolo­ nego podformularzem). Po ustaleniu złączeń pomiędzy tabelami mającymi tworzyć taki formularz możemy wybrać interesujące nas pola. Tym razem kreator pozwoli nam prze­ nieść się do kolejnego okna dialogowego określającego sposób organizacji (wyświe­ tlania) tworzonego formularza (rysunek 2.30). Rysunek 2.30. Zastosowanie kreatora do tworzenia formularzy — definiowanie sposobu wyświetlania formularza

u program u A c c c ;' 20 0 2

2003

I^Diulu, fteM ko, brie, RcłUrod;, WtrEJł, Eiieto

.

Pojedyngy fcrmiAsrz

AfuJu)

11

< Wstecz

Ptitfzar*.

(atńiina 11

Da!a| >

[|

Zalcńcz~

Jeśli zdecydujemy, aby dane były wyświetlane „patrząc od strony” tabeli podrzędnej, zawsze otrzymamy pojedynczy formularz. Ten sposób prezentacji danych jest z reguły mało przejrzysty, dlatego w większości przypadków decydujemy się na prezentację danych "patrząc od strony” tabeli nadrzędnej. Dostajemy wtedy możliwość wyboru prezentacji danych w postaci albo formularza z podformularzem (rysunek 2.31), albo formularzy po­ łączonych (rysunek 2.32). Obie fonny prezentacji są w zasadzie równoważne. Różnica sprowadza się do sposobu synchronizacji danych między formularzami. Natomiast jako­ ściowa informacja pozostaje taka sama. W tym miejscu ograniczymy się tylko do spo­ sobu działania kreatora, natomiast szczegółowe omówienie metod synchronizacji i ich „ręczna” realizacja zostaną omówione w dalszej części tego rozdziału. Najczęstszym wyborem, jeśli chodzi o sposób połączenia, jest formularz z podformula­ rzem — dlatego dalszy sposób działania kreatora zostanie przedstawiony dla tego przy­ padku.

36

Bazy danych. Pierwsze starcie

Rysunek 2 .3 1 . Zastosowanie kreatora do tworzenia formularzy — definiowanie sposobu wyświetlania formularza

Rysunek 2.32. Zastosowanie kreatora do tworzenia formularzy — definiowanie sposobu wyświetlania formularza

I Kreator formularzy W (itj sposób dan: ma]ąbyd wyfwlctiane?

-Y) j-11' przez ZaiobW

IdDcału, Haiwtslo, Iroc, Rflłlłoć:,

WOTKt

, Bn-Uo

O Łcmstiarz2

DodfomniarremdimO

Kolejnym etapem jest określenie sposobu wyświetlenia podformularza (rysunek 2.33). Najczęściej stosowane są postaci: arkusza danych (tak jak w przypadku wyświetlania wyników działania zapytania — stan domyślny) oraz postać tabelaryczna. Ta druga postać pozwala na bardziej precyzyjne panowanie nad formatowaniem — wyglądem podformularza. Dwie pozostałe postaci są stosowane sporadycznie, przeznaczone są one dla potrzeb analizy danych, a nie ich wprowadzania czy modyfikacji. Kolejnym krokiem automatycznego tworzenia formularza (rysunek 2.34) jest wybór kolorystyki. Właściwie nie jest to element istotny z punktu widzenia sposobu działa­ nia. Jedyna uwaga jest związana z tym, że początkujący programiści starają się ubar­ wiać swoje aplikacje, stosując bardzo wyszukaną, krzykliwą kolorystykę. Jeżeli jed­ nak spróbujecie się postawić w sytuacji osoby, która przez kilka godzin dziennie będzie obsługiwała Wasz produkt, to łatwo zrozumiecie, że wybór stonowanej kolorystyki jest jak najbardziej uzasadniony z punktu widzenia praktyki. Dlatego pozostawienie do­ myślnej palety (odcienie szarości) jest bardzo słusznym wyborem.

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne Rysunek 2 .33. Zastosowanie kreatora do tworzenia formularzy — definiowanie sposobu wyświetlania podformularza

37

Hurlownlrt : Ua?a danych jformal pliKu programu Accck 7002 ■2003)

ĘgOfc

Kreator formularzy Jaki ma być uUad podłemu! irra ?

O labelarycsny © 'Arlri;; danych O

|

prrestawna

O Wykres przestawny

&

Rysunek 2.34. Zastosowanie kreatora do tworzenia formularzy — definiowanie kolorystyki

ęaiffl

Anićul

Ea!e|>

..... ■ ..... - .................................

—

te] lal

JaH ma być styf?

Ekspedycja Kanseń Mcdzynarodowy Heszanki Obraz sumi Papier ryjowy Piasek pustyni Przemysłowy

Etykieta [Dane

Swiatlokcpia

I ;

Hale)> Ostatnim etapem jest nadanie nazw (rysunek 2.35) tworzonemu formularzowi i podformularzowi (stanowią one oddzielne obiekty). Należy zauważyć, że przyjęcie do­ myślnej terminologii — nazwa formularza pochodzi od nazwy tabeli (najwyższej w hierarchii, jeśli formularz jest oparty o wiele tabel) lub nazwy zapytania— jest do­ brym pomysłem na tworzenie nazw. Niestety, jeśli o jedną tabelę oparty będzie wię­ cej niż jeden formularz, kolejne z nich po nazwie tabeli będą miały dopisane kolejne numery porządkowe. Utrzymanie takiego nazewnictwa może być wtedy kłopotliwe (mało czytelne). Dlatego w takich przypadkach wskazane jest stosowanie bardziej opisowych nazw, np. Osoby_Nagrody. Jeżeli chodzi o domyślne nazewnictwo podformularzy, to burzy ono przyjętą i uzasadnioną na wstępie zasadę niestosowania separa­ torów w postaci spacji. Najprostszym wyjściem jest zastąpienie znaku spacji separato­ rem w postaci znaku podkreślnika _.

Bazy danych. Pierwsze sta rcie

38

Rysunek 2 .3 5 .

Zastosowanie kreatora do Morzenia formularz}’ — definiowanie nazw formularza i podfonnularza

W ten sposób dobiegliśmy do finalnego wyglądu naszego formularza z podformularzem (rysunek 2.36). Po uzyskaniu wprawy proces ich tworzenia za pomocą kreatora nie powi­ nien zająć więcej niż minutę. Jednak opis tego, co dzieje się podczas pracy, zajął nam kilka stron. Część z niuansów działania nie została jeszcze precyzyjnie opisana, ale już przy opisie metod synchronizacji zostaną one szczegółowo przedstawione. Na tym etapie skoncentrujmy się przez chwilę na części wizualno-estetycznej naszego obiektu. Głów­ nym problemem są bardzo małe i słabo widoczne standardowe elementy nawigacyjne. Szczególnie kłopotliwe jest to w przypadku podformularza, bo trudno czasami rozróżnić, czy przycisk dotyczy elementu podrzędnego, czy nadrzędnego, zwłaszcza wtedy, kiedy elementów podrzędnych jest kilka. Dodatkowo w naszym przypadku zamiast przyci­ sków wystarczającym elementem nawigacyjnym w podformularzu byłby pionowy pasek przewijania. Rysunek 2 .3 6 . Zastosowanie kreatora do tworzenia formularzy— widok formularza (arkusz danych) po zakończeniu pracy kreatora

.iwfHurlownfa : 5 5 $ danych (format pliku programu Access 2002 •2003) f R i Otwórz

Projektu) ‘'3 Nowy. | X | a a Vr jn: [lii

[TJ~

IdDrialu Nazwisko

Rok.Urodz

Wami Zarobki

Rsterd: Q D 3 | Rekord:

[TT]

< \f

TCZXEDt±Hl z 1 i BCEDiE] * ks

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

39

Jeśli otworzymy nasz formularz w widoku Projekt (albo z poziomu menu, albo wybiera­ jąc ikonę ; fcGk 10 będziemy mogli edytować zarówno główny formularz, jak i wszystkie osadzone w nim obiekty, w tym podformularze. Właściwości podformularza możemy wyświetlić, wybierając jego górny prawy róg (rysunek 2.37) i naciskając prawy przycisk myszki. Aby pominąć zbędne elementy nawigacyjne, ustawmy następujące właści­ wości — tabela 2.14: ~ ~ ~ ~ '

J Ucmoll ł
L-->

-F*-

j g : .H rj ą - fm in

17“ i " ”

— “ i 'i i / i j

W Ł.

-'a "~o■« '[ą^] ^ : a'f51iV£ n-' «H

|iL

jM

1

U;'-g °

• I -V U jZ łJ.-'

-

' i

____________ !__

Właściwości podformularza

Fcmidrz

-i 9 .0 -I

j

l|a»uea ^

Fermat | P ara I Izśsrz-rtn j Irra wcrutM | xr*sst*ro v*rjreeła +n słrś±w >...... «-- .. lic PynU jm ir.-a yr_ tfc*łla r*ozcn» r« p łtw fjru ........ |T>iło p ow y»j_ SćcilayrckriM .............>Xa FYryralr*w^icyjTa....... fia Ałlowrł«rw*ri« ....... ITtfc ........... ils_ Lkm pals-słu ........................|1*{~

#Slrr^j fimiyti

roAyaw............i;. ...te

Rysunek 2 .37. Widok projektu form ularza— usuwanie elementów nawigacyjnych we właściwościach podformularza Tabela 2.1 4 . Zmieniane właściwości podformularza W łaściw ość

W artość

Paski przewijania

Tylko pionowy

Selektory rekordów

Nic

Przyciski nawigacyjne

Nie

Linie podziału

Nie

Podobne modyfikacje możemy wprowadzić dla głównego formularza (rysunek 2.38), ustawiając podane w tabeli 2.15 właściwości. Tabela 2 .1 5 . Zmieniane właściwości formularza W łaściw ość

W artość

Paski przewijania

Żaden

Selektory rekordów

Nie

Przyciski nawigacyjne

Nie

Linie podziału

Nie

Pole menu sterowania

Nie

Przyciski Min Maks

Żaden

Przycisk zamknij

Nie

Bazy danych. Pierwsze sta rcie

40

Właściwości formularza

Rysunek 2 .3 8 . Widok projektu form ularza— usuwanie elementów nawigacyjnych i menu sterowania we właściwościach formularza

Po wskazanych zmianach nasz formularz powinien mieć bardziej przejrzystą postać graficzną (rysunek 2.39). W zestawie niezmienionych właściwości należy zwrócić uwagę na Styl obramowania dający możliwość regulowania wyglądu, łącznie z ustawieniem typu bez obramowania {Brak). Bardzo ważną cechą jest również modalność dialogu pozwalająca na wymuszenie pełnego obsłużenia dialogu bez możliwości przejścia do innych okienek aplikacji. Rysunek 2 .3 9 . Widok formularza (arkusz danych) po zakończeniu modyfikacji


B

fil!

Osoby IdDzialu

|3 E S 2 3

Nazwisko

| Kowalski

Imię

pen

Hokllioćz

|

Wzrost Zarobki

|

L*d

1377 V5

Niestety dotychczasowe działania przy edycji wyglądu formularza pozbawiły nas moż­ liwości nawigacji oraz zamknięcia formularza (za wyjątkiem pozycji menu — Zamknij). W kolejnym kroku postaramy się stworzyć własne, bardziej czytelne przyciski do nawigowania i obsługi formularza.

Rozdział 2. * Projektow anie bazy danych — narzędzia wizualne

41

Jeżeli otworzymy formularz w widoku projektowania, to dobrym miejscem na umiesz­ czenie przycisków pozwalających na obsługę jest jego nagłówek. Równoważny jest wybór stopki formularza — wadą takiego wyboru jest tylko to. że w przypadku dużych formularzy przy zbyt niskiej rozdzielczości ekranu przyciski umieszczone w stopce mogą być w pierwszej chwili niewidoczne na ekranie. Z przybornika wybieramy przycisk polecenia (rysunek 2.40) i umieszczamy go w obrębie naglów'ka. Przy włączonym kreatorze powmduje to pojawienie się okienka dialogo­ wego, w którymi widoczne są dwie listy. Lewa lista zawiera grupy akcji, natomiast kon­ kretne polecenia grupy zawarte są na liście z prawej strony. Wybierzmy grupę Operacje na formularzach, a w niej akcję Zamknij formularz (rysunek 2.41). Rysunek 2.40. Widok projektu formularza — definiowanie przycisków za pomocą_ kreatora na przykładzie pizycisku zamykającego formularz

Przycisk polecenia

Rysunek 2 .4 1 . Widok projektuformularza— definiowanie p o c iskó w za pomocą kreatora, uybór sposobu prezentacji przycisku

42

Bazy danych. Pierwsze sta rcie

Kolejny krok stanowi wybór napisu bądź ikony występującej na przycisku polecenia. Zaznaczenie opcji Pokaż wszystkie obrazy pozwala na wybór z pełnego zakresu predefi­ niowanych ikon, natomiast przycisk Przeglądaj pozwala na wybranie rysunku zapisa­ nego na dysku (ikony lub bitmapy). Dokonany w tym miejscu wybór ma drugorzędne znaczenie. Należy zwracać uwagę na to, aby komunikaty były zrozumiale, a ikony jasno sugerowały akcje. Pozostaje nam tylko nadanie nazwy przyciskowi (rysunek 2.42), i tworzenie przycisku zamykającego formularz jest zakończone.

Rysunek 2 .4 2 . Widok projektuformularza— definiowanie przycisków za pomocą kreatora, definiowanie nazwy przycisku

Według podobnego schematu tworzymy przyciski nawigacyjne (rysunek 2.43). Tym razem wykorzystamy akcje należące do grupy Nawigowanie pomiędzy rekordami. Po zdefiniowaniu przycisków: Przejdź do pierwszego rekordu, Przejdź do następnego rekordu’. Przejdź do poprzedniego rekordu’, Przejdź do ostatniego rekordu oraz z grupy Operacje na rekordach — Dodaj nowy rekord, możemy uznać zadanie za zakończone. Wynik przedstawia rysunek 2.44. Do tej pory omawialiśmy sposób obsługi kreatora, nie zagłębiając się w to, co jest two­ rzone w warstwie programistycznej. Jeżeli wybierzemy którykolwiek z przycisków', to w jego właściwościach zobaczymy, że dla zdarzenia Przy kliknięciu została stworzona procedura obsługi zdarzenia (rysunek 2.45). Wybranie przycisku po prawej stronie dialogu pozwala na przejście do poziomu kodu. Językiem zintegrowanym ze śro­ dowiskiem MS Access jest Yisuał Basic for Applications (rysunek 2.46).

Rozdział 2. ❖ Projektow anie bazy danych — narzędzia wizualne

43

Rysunek 2 .4 3 . Widok projektu form ularza— definiowanie przycisków za pomocą kreatora na p o k ła d z ie przycisku nawigacji do pierwszego rekordu Rysunek 2 .44. Widokformularza (arkusz danych) po zakończeniu definiowania przycisków nawigacyjnych

Na rysunku 2.46 widzimy okienko środowiska programistycznego MS Access (w tym przypadku z przedstawioną obsługą zdarzenia Przy kliknięciu dla przycisku zamyka­ jącego formularz) (listing 2.1). Należy zwrócić uwagę, że po lewej stronie lista ze strukturą hierarchiczną (tree) zawiera wszystkie elementy tworzonej przez nas bazy danych wraz z dołączonymi bibliotekami oraz ze wszystkimi formularzami i raportami, do których zbudowaliśmy jakąkolwiek obsługę z poziomu VB. Dwie listy typu kombi (nad okienkiem z kodem) pozwalają na dostęp do wszystkich elementów formularza (lista po lewej stronie) oraz do wszystkich metod dostępnych dla elementu wybranego z listy (lista po prawej stronie). Pojawia się tutaj pewna niekonsekwencja polegająca na tym, że o ile we właściwościach kontrolki nazwy zdarzeń są spolszczone, o tyle na poziomie kodowania stosuje się oryginalne nazewnictwo angielskie. Zdaniem autora

44

Bazy danych. Pierwsze starcie

Rysunek 2 .4 5 . Widok projektu formularza — właściwości przycisku, obsługa zdarzeń

Łp Osoby: Formularz

□r 4 Nagłówek fcrrrtiarza

■<

► M

-

0

1

_____.JI sal i t i 4- 5tcpJ^a formularza

y-zry rr;:,

'

i

F ”

Rysunek 2 .4 6 . Widok projektu modułu prywatnego formularza ze zdefiniowaną obsługą zdarzenia Pizy kliknięciu przycisku zamykającego formularz

pomysł nadawania lokalnych nazw zdarzeniom jest niepotrzebny i tylko wprowadza bałagan nazewniczy. Wszystkie wersje narodowe powinny pozostać przy nazewnictwie oryginalnym (każdy informatyk, przynajmniej w zakresie słownictwa fachowego, powi­ nien władać językiem angielskim). Listing 2.1, Kod procedury obsługującej zdarzenie Prz)1kliknięciu przycisku zamykającego formularz Private Sub Polecem el2_Click() On Error GoTo Err_Polecemel2_Click DoCmd.Close Exi t_Pol ecemel2_Cl i ck: E xit Sub Er r_Po1ecen i el2_C11c k : HsgBox Err.Description Resume Exit_Polecem el2_Click End Sub

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

45

Kod procedury zamieszczony na rysunku 2.46 został powielony w bardziej czytelnej formie na listingu 2.1. Pozwólmy sobie na bardziej precyzyjne jego omówienie, jako pierwszego przykładu zastosowania języka VB do obsługi zdarzeń. Jako obsługa zdarzenia została utworzona procedura prywatna (Private Sub) o nazwie P o le c e n ie l2 _ C lic k . To, że procedura jest prywatna, oznacza, że może być ona wy­ woływana tylko z poziomu obiektu, dla którego została utworzona (formularza). Wy­ wołanie jest wykonywane przez podanie nazwy procedury. Jeśli chodzi o przyjęte na­ zewnictwo procedur, to nazwa składa się zawsze z: nazwy kontrolki, której zdarzenie dotyczy (Polecem elż), separatora w postaci znaku podkreślnika _ oraz angielskiej nazwy zdarzenia, które jest obsługiwane (C lick ). Pierwszą linię kodu stanowi zawsze dyrektywa obsługi błędów (On E rror). Dyrektywa różni się od instrukcji tym. że wykonywana jest nie w miejscu, w którym występuje w kodzie, ale w każdym miejscu kodu, gdzie pojawi się dotyczące jej zdarzenie (błąd). W przypadku zastosowania wariantu GoTo E ty k ie ta w wyniku pojawienia się błędu w trakcie przetwarzania kodu przenosimy się do wskazanej etykiety — w naszym przypadku do etykiety E rr_ P o le ce n ie l2 _ C l ick;. W VB etykietąjest dowolny napis (zgodny z zasadami nazewniczymi) zakończony dwu­ kropkiem. Najistotniejszym elementem kodu jest instrukcja zamknięcia formularza. Ko­ rzystamy w tym miejscu z obiektu DoCmd (Do Command — wykonaj polecenie, w domyśle Accessa), który daje nam dostęp do większości użytecznych w tym środowisku metod. W naszym przypadku wykonywana jest metoda Close — zamykająca aktywny obiekt (posiadający fokus). W przypadku pozytywnego wykonania polecenia procedura jest kończona bezwarunkowym wyjściem — Exit Sub. Jeśli natomiast pojawił się błąd przetwarzania, wykonywane są polecenia po etykiecie, do której przekierowala nas dyrektywa obsługi błędu. Najpierw jest wyświetlany komunikat za pomocą procedur)' MsgBox, będącej standardowym narzędziem dla tego celu. Pierwszym parametrem tej procedury jest napis komunikatu. W naszym przykładzie odwołujemy się do obiektu Err, przechowującego informacje o ostatnio występującym błędzie. Wykorzystana została właściwość Description, zawierająca systemowy komunikat związany z tym błędem. W kolejnej linii wykonywane jest polecenie (Resume) pomijające nieprzetworzony kod i zwalniające odpowiednie zasoby. Jak widać, ten bardzo prosty kod zawiera w sobie naprawdę bardzo wiele ważnych informacji. Według podobnego schematu wykony­ wana jest obsługa pozostałych zdarzeń związanych z wprowadzonymi przez nas przyciskami. Jedyną różnicą jest wykorzystywana metoda obiektu DoCmd, np.: MoveNext — przejdź do następnego rekordu, MovePrev — przejdź do poprzedniego rekordu, etc. W tym miejscu warto również powiedzieć kilka słów o obiekcie Err. Oprócz właściwości mamy do dyspozycji i inne, takie jak Number — zawierającą numer ostat­ niego błędu, oraz Source — zawierającą informacje o aplikacji, w której błąd wystąpił. Ponadto możemy użyć metody C le a r — usuwającej informacje o błędzie, oraz Raise (z parametrami takimi samymi jak metody tego obiektu) — pozwalającej na wymuszenie wystąpienia błędu o podanych: opisie, numerze czy źródle. D e s c rip tio n

Przy tej okazji nie można pominąć procedury MsgBox o wywołaniu przedstawionym na listingu 2.2. Listing 2 .2. Ogólna postać uywolama procedury MsgBox MsgBox komunikat, wygląd, tytuł

46

Bazy danych. Pierwsze sta rcie

W przypadku pierwszego parametru zawierającego komunikat problemem może być przypadek, kiedy jest on bardzo długi, wtedy zawinięcie wiersza następuje zgodnie z we­ wnętrznymi prawidłami tego obiektu. Jeśli natomiast chcemy w sposób jawny wymusić zmianę linii (rysunek 2.47, listing 2.3), stosujemy złączenie dwóch lub więcej części przez podane przez kod ASCII znaki sterujące: zmianę linii (linę feed) i powrót ka­ retki (carriage return). Listing 2.3. Podział komunikatu na dwie linie (rysunek 2.47) HsgBox "komunikat!" & Chr(10) & Chr(13) & "komunikat2”

Rysunek 2 .4 7 . Widok okienka generowanego przez procedurę MsgBos z podzielonym na dwie linie komunikatem

Microsoft Acc

!E

—‘J

komunikat! komunikalż

OK

Drugi parametr opisujący wygląd okienka komunikatu zawiera wzór bitowy kodujący poszczególne elementy wyglądu. Kod ten możemy uzyskać, sumując predefiniowane parametry, które możemy podzielić na kilka grup w zależności od ich funkcji (ta­ bela 2.16. 2.17). Tabela 2 .1 6 . Parametry opisujące wygląd okienka wyświetlanego za pomocą procedury AIsgBos Grupa

Param etry

Liczba i rodzaj przycisków

vbOKOnly vbOKCancel vbAbortRetryIgnore vbYesNoCancel vbYesNo vbRetryCancel

ikona w rogu okienka

v b C ritica l vbQuestion vbExclamation vb Information

Numer domyślnego przycisku

vbDefaultButtonl vbDefaultButton2 vbDefaultButton3 vbDefaultButton4

Modalność

vbAppllcationModal

Czy wyświetlany jest przycisk pomocy

vbMsgBoxHelpButton

vbSystemModal

Rozdział 2. ❖ Projektow anie bazy danych — narzędzia wizualne

47

Tabela 2 .1 7 . Przykład ustawienia bitów przy kodowaniu niektórych właściwości dialogu wyświetlanego przy pomocy MsgBox

Kodowana wartość

Numer bitu

12

11

10

9

7

6

5

4

3

2

0

Na drobny komentarz zasługuje rozróżnienie modalności względem aplikacji i systemu. Jeśli mamy ustawioną modalność względem aplikacji (vbApplicationModal — stan domyślny), to nie jest możliwe przejście do żadnego okienka tej aplikacji przed za­ kończeniem obsługi dialogu, natomiast możliwe jest przełączenie się do innej aktyw­ nej aplikacji (czy przez wybranie myszką, czy klawiszami Alt+Tab) oraz uruchomienie kolejnej aplikacji w systemie. Natomiast modalność względem systemu nie pozwala ani na przełączanie się między okienkami bieżącej aplikacji czy pomiędzy aktywnymi aplikacjami, ani też na uruchomienie kolejnej aplikacji przed zakończeniem obsługi dialogu. Wymusza to porządek w obsłudze aplikacji, w naszym przypadku tylko w ra­ mach wyświetlania komunikatów, ale może być również wykorzystane przy tworzeniu własnych formularzy (listing 2.4). Nie można łączyć ze sobą parametrów występują­ cych w obrębie tej samej grupy, gdyż prowadzi to do ustawienia innego kodu binarnego i otrzymujemy wygląd dialogu zupełnie inny niż spodziewany — tabela 2.15. Listing 2.4. Złożona postać wywołania procedury MsgBox (rysunek 2.4S) MsgBox "komunikatl". vbYesNoCance1 + v b C ritic a l + _ vbDefaultButton3 + vbSystemModal

Rysunek 2.48. Widok okienka generowanego przez procedurą MsgBox ze złożonym opisem wyglądu

kcm urJcad

iP

1.

Mfe

AraJui

B M M B B B IB

W przypadku wywoływania MsgBox jako procedury nie jest możliwe odczytanie, który z przycisków został wybrany (ma to sens tylko w przypadku dialogu typu vb0k0nly). Jeżeli na dialogu jest większa liczba przycisków, zasadne jest używanie wywołania MsgBox jako funkcji. W tym przypadku następuje podstawienie wartości zwracanej do zmiennej, natomiast lista parametrów musi być ujęta w nawiasy (listing 2.5).

Bazy danych. Pierwsze sta rcie

48

Listing 2.5. Wywołanie funkcji MsgBox a = MsgBox ("komunikat!". vbYesNoCancel)

Zmienna a będzie zawierała kod naciśniętego klawisza według kodu przedstawionego w tabeli 2.18. Tabela 2.1 8 . Wartości zwracane prze: funkcję MsgBox Naciśnięty przycisk

W artość

OK

1

Cancel

2

A bort

3

Retiy

4

Ignore

5

Yes

6

No

7

W tej części rozdziału drugiego udało nam się stworzyć i zmodyfikować formularz. Po­ mimo dość precyzyjnego omówienia licznych aspektów projektowania formularzy' wiele zostało pominiętych. W większości przypadków z powodu ich oczywistości albo dużego podobieństwa do omawianych mechanizmów czy metod. Jednak również w dalszej części tej książki będziemy wracać do problematyki związanej z obsługą formularzy.

IworzemiDe raportów Kolejnym elementem, który zawsze jest tworzony w obrębie bazy danych, jest raport. O ile formularze są przeznaczone głównie do wprowadzania nowych czy edycji istnie­ jących danych, o tyle raporty są tworami statycznymi. Wynika to z faktu, że są prze­ znaczone w postaci finalnej do wydruku. Pomimo różnicy sposobu prezentacji i prze­ znaczenia raporty i formularze są do siebie formalnie bardzo podobne. Również sposób działania narzędzi do ich tworzenia jest bardzo zbliżony. Spróbujmy w związku z tym utworzyć za pomocą kreatora (rysunek 2.49) raport oparty, tak jak poprzednio formularz, o dwie połączone ze sobą tabele — Osoby i Zarobki. Pierwsze okienko dialogowe kreatora do tworzenia raportów (rysunek 2.50) pozwala na wybór pól z tabel. Tak samo jak w przypadku formularza z podformularzem, w przy­ padku wybrania pól z niepowiązanych ze sobą tabel (nieuwzględnionych w diagramie bazy — relacjach) generowany jest komunikat o błędzie i twórca może przenieść się automatycznie do odpowiedniego narzędzia wizualnego. Załóżmy, że tabele były już połączone tak jak w poprzednim rozdziale — dodatkowo została połączona jeszcze tabela Działy. Wybrano pola Opis (tabela Działy), Nazxvisko, linie, RokUrodz (tabela Osoby) oraz Brutto (tabela Zarobki).

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne Rysunek 2.49. Zastosowanie kreatora do Morzenia raportów

49

& Huriownla: Baza danych (format pliku programu Access 2002 - 2003) u i PwWąd ^ P ro jek tu j

OtieKry □

E]

O Nowy. | X | a n utwór: raport w wkjohj projaliu

Tabela

3 ] Kwerendy

5 3 FcrmJa... LJ

RaDurty

Slrony £2 Ui

Makra MotKiy

Grupy Cii Uubicne

Rysunek 2.50. Zastosowanie kreatora do Morzenia raportów — wybór pól wyświetlanych ii' raporcie

Podobnie jak w przypadku formularza, kolejne okienko dialogowe pozwala wybrać spo­ sób prezentacji raportu — patrząc od strony każdej z tabel stanowiących źródło danych dla formularza. Jeżeli wybierzemy którąkolwiek najbardziej podrzędną tabelę, raport będzie „plaski” (rysunek 2.51). Jeżeli wybierzemy którąś z nadrzędnych tabel, stworzona zostanie hierarchia wyświetlania danych, począwszy od poziomu tej tabeli w strukturze. Jeżeli wybrana będzie tabela stojąca najwyżej w hierarchii, uzyskamy najbardziej złożoną strukturę wyświetlania da­ nych (rysunek 2.52). Pozwala ona na grupowanie na każdym z poziomów hierarchii, a zatem, przez analogię do zapytań z funkcjami agregującymi, wyznaczenie wartości tych funkcji dla każdego z poziomów grupowania, np. sumy, wartości średniej etc. Struktura hierarchiczna wygenerowana na skutek automatycznego działania kreatora może zawierać co najwyżej tyle poziomów, ile jest łączonych tabel. Pomimo tego, że na tym etapie może być już dość złożona, możliwe jest jej rozszerzenie. Jeżeli na

50

Bazy danych. Pierwsze sta rcie

Rysunek 2.51. Zastosowanie kreatora do tworzenia raportów— wybór sposobu wyświetlania raportu

Rysunek 2 .5 2 . Zastosowanie kreatora do tworzenia raportów— wybór sposobu wyświetlania raportu

którymkolwiek poziomie pozostanie więcej niż jedna dana, potencjalnie każda z nich może posłużyć do zdefiniowania dodatkowych poziomów grupowania (dodatkowych poziomów, na których można dokonywać podsumowań) — rysunek 2.53. W naszym przykładzie pokazano, że można wyznaczyć poziom spowodowany zmianą wartości pola Imię w tabeli Osoby. Taki wybór powoduje, że jeśli w danym dziale (poziom Opis) pracują osoby o takim samym imieniu, to najpierw zostaną podsumowane konkretne osoby (Nazwisko, RokUrodz) o tym imieniu. Później zbiorczo otrzymamy podsumowa­ nie dla kilku osób z tego działu noszących to samo imię. Na końcu otrzymamy pod­ sumowanie dla danego działu. Sytuacja powtórzy się tyle razy, ile działów liczy nasze przedsiębiorstwo. Na końcu możemy otrzymać globalne podsumowanie wszystkich osób naszej firmy. Ponieważ wprowadzenie takiego poziomu grupowania nie ma żadnego uza­ sadnienia praktycznego, w dalszej części pracy zrezygnujemy z jego wprowadzania.

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

51

Rysunek 2.53. Zastosowanie kreatora do tworzenia raportów — wybór dodatkowych poziomów grupowania raportu

W kolejnym oknie dialogowym istnieje możliwość zdefiniowania pól, względem któ­ rych wykonywane będzie sortowanie (rysunek 2.54). Wybierać możemy tylko spośród pól znajdujących się na najniższym poziomie hierarchii — w naszym przypadku jest to pole Brutto. Ważniejszym elementem tego okna jest jednak możliwość przejścia do definicji opcji sumowania (przycisk na dole okna). Rysunek 2.54. Zastosowanie kreatora do tworzenia raportów— wybór sposobu sortowania raportu

W oknie opcji sumowania możemy wybrać funkcje agregujące dla wszystkich pól typu numerycznego występujących na najniższym poziomie grupowania— w naszym przypadku jest to pojedyncze pole Brutto (rysunek 2.55). Należy zwrócić uwagę. że w kreato­ rze zostały wyprowadzone tylko cztery funkcje: suma, średnia, maksimum i minimum. Jeżeli chcielibyśmy skorzystać z innych funkcji agregujących (w'ariacja, odchylenie standardowe lub zlicz), możemy to wykonać z poziomu projektu raportu. W postaci opcji wyboru możemy zaznaczyć, czy wyświetlane będą wszystkie składniki (rekordy) wchodzące w skład wyznaczanych funkcji agregujących, czy też tylko podsumowania.

52

Bazy danych. Pierwsze sta rcie

Opcje podsumowania Jafcia waitośd podsumowujące chcesz ofclcryć? Pob

Suma

Anulu |

□

0

Pokaż -

Pi

E i

Lźi

i i

0

©

Szczegóły I podśmiewanie

O

ły k o podsumowanie jofalaaj udziały procentowe sum

| Opcja podsumowania... | r,. > W "p i» £

“

m

Araiuj

Dalej >

Rysunek 2.5 5 . Zastosowanie kreatora do tworzenia raportów— wybór opcji podsumowania dla raportu

W praktyce oznacza to. że albo sekcja szczegółów w definicji raportu jest widoczna, albo nie. Oprócz tego możliwe jest uwzględnienie udziałów procentowych — czyli stosunku sumy wartości pola na danym poziomie grupowania do sumy wartości tego pola dla wszystkich rekordów wyświetlanych w raporcie. Wielkość ta jest wyświetlana w' formacie procentowym. Kolejne etapy tworzenia raportów za pomocą kreatora nie sąjuż tak istotne z meryto­ rycznego punktu widzenia. Pierwszy z nich pozwala na określenie ułożenia pól na ra­ porcie oraz ich adiustację (rysunek 2.56). Rysunek 2 .56. Zastosowanie kreatora do tworzenia raportów — wybór szablonu wyświetlania raportu (układ)

i!* Hurtownia : Dora danych (format pliku programu Access 7002 • 2003)

a g a t

li PodKreator raportów Jaki ma być uWad raportu? Orientacja XXXXXXXX kxxx

KOOOi

im

xxxa xxzs i m

xx>‘.a XXXXk xxxxx xooo< xxxxx xxxxx koom

x«oo« kx>»x >;ooo» ttOOOt XXXXX KOOQ< łccoot xxxxx >:ooc<

Lrl

,___

@ Eionowa

O

Sokowy

OPC^oroa

O

Kontur 1

O

Kontur Z

O

Wyrównaj do tw ó j 1

i O

Wyrównaj do |cwo) Z

0

Anukij

© Ktptowy |

Dostosuj noTotosć pól tok, aby wszystkie pola byty widoczne na stronie

j j
Qaie) >

11

Ząiyńcz

I

53

Rozdział 2. * Projektow anie bazy danych — narzędzia wizualne

Kolejny etap stanowi wybór szablonu dotyczącego kolorystyki oraz elementów deko­ racyjnych — podkreślenia, ramki etc. (rysunek 2.57). Rysunek 2.57. Zastosowanie kreatora do tworzenia raportów— wybór szablonu wyświetlania raportu (kolorystyka)

i * Hurtownia: Baza danych (format pliku programu Access 20(12 • Kreator raportów Jaki ma być styl?

Formalny Kompaktowy Pogrubienie Przypadkowy Tradycyjny

Qdcj >

Anulu)

Ostatni krok to nadanie nazwy generowanemu raportowi (iysunek 2.58). Tale jak w przy­ padku formularzy domyślna nazwa jest taka sama jak nazwa najwyżej usytuowanej w hierarchii tabeli lub zapylania Możliwe jest stosowanie własnej strategii nazewniczej, jednak dobry zwyczaj nakazuje, aby tworzone przez użytkowników nazwy miały zwią­ zek z obiektem źródłowym. Rysunek 2.5 8 . Zastosowanie kreatora do tworzenia raportów— wybór nazwy raportu

Hurtownia : Unra danych (format pliku programu Access 2002 ■2003)

a**!Kreator raportów' o:

Jaki ma być ty tti raportu?

□

set

©

13 U •a' a

A • G

To jui wszystkie Informacjo potrzebno kreatorowi do utworzenia raportu. Co chcesz zrobić, ędy kreator zakończy pracą? © Epdęląd raportu 0

Kodyfikuj projekt raportu

GO 1 IWyćwietCć Pomoj dotyczącą pracy z raportem?

___

Anuiu)

]|

< Wstecz

11

£ e : e j !|

Zakończ

|

Końcowym efektem działania kreatora jest raport przedstawiony w postaci podglądu wydruku na rysunku 2.59. Niestety wyświetleni pracownicy mają do tej pory po jednej wypłacie, stąd suma dla pracowmikajest równa tej wartości.

54

Bazy danych. Pierwsze sta rcie

Rysunek 2 .5 9 . Zastosowanie kreatora do tworzenia raportów— wygląd wygenerowanego za pomocą kreatora raportu

Zaawaotsowaiira© m©tod]y ©Ibsi/MgD aplikasjii Synchronizacja zawartości podformularza z kontrolką Jednym z pierwszych problemów, z jakimi spotykamy się przy okazji obsługi danych, jest szybkie wyszukanie interesujących nas danych. Jeżeli objętość bazy nie jest szcze­ gólnie duża. możemy posłużyć się przyciskami nawigacji po rekordach. Jednak nawet dla niezbyt wielkiej bazy ta metoda wyszukiwania może być kłopotliwa, a na pewno zawsze czasochłonna. Podobnym w swojej istocie zagadnieniem jest filtrowanie da­ nych. tak aby na formularzu czy raporcie znalazły się tylko dane określonej kategorii — spełniające pewne kryterium. Pierwszym rozwiązaniem przedstawionym w pod­ rozdziale Wizualne tworzenie zapytań’' bieżącego rozdziału było zastosowanie zapyta­ nia parametrem i oparcie o nie formularza łub raportu. Jednak omówione poprzednio niedogodności związane z posługiwaniem się tym mechanizmem zachęcają do znale­ zienia innego, bardziej skutecznego rozwiązania. Pierwszym pomysłem na uzyskanie

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

55

pożądanych rezultatów może być mechanizm synchronizacji podformularza z kontrolką umieszczoną na formularzu. Aby prześledzić metodologię postępowania, stwórzmy w naszej bazie nowy, pusty formularz. Kolejnym etapem będzie umieszczenie na formularzu kontrolki, z którą będziemy syn­ chronizować podformularz. Kontrolka może być praktycznie dowolnego typu, np. typu pole tekstowe. Jednak ze względu na większą elastyczność zastosujemy pole kombi. Umieśćmy na formularzu ten typ kontrolki wybrany z przybornika (rysunek 2.60). Pamiętajmy, aby aktywny był umieszczony w przyborniku kreator kontrolek. Rysunek 2.60. Zastosowanie kreatora do tworzenia pól kombi — wybór typu źródła danych dla kontrolki

Kreator Pole kombi | Kttfltor pil kombi

F="— ą fa r j

■ TcnbaJL* im k r r ii, Ułry luę ••srtcid rc £brrG\ dj wyboru. V/ ^»l JTOłib pste kcr£i rr-S PCitrtti l»«rtsU? 0*fjarł J pois IzrŁi r*-* rrirrfsi r»*ftaci t Inbri li) ŁłłWfńJy O

j

cna tMrtsłd

|

Łua

|

1 0 *1 >

1

Osij-a

Pierwszą decyzją, jaką musimy podjąć, jest wybór typu danych dla pola (rysunek 2.60). Dane mogą być wpisywane ręcznie (lista statycznych wartości) albo pobierane z ta­ beli lub zapytania (lista dynamiczna). Proces jest podobny do omówionego wcześniej mechanizmu tworzenia odnośników w tabeli. Przyjmijmy, że w naszym zadaniu będziemy chcieli w podformularzu wyświetlić tylko osoby pracujące w wybranym polem kombi dziale. Stąd jako źródło danych zostanie wybrana tabela Działy (rysunek 2.61). Nic nie stoi na przeszkodzie, aby utworzyć spe­ cjalne zapytanie dla potrzeb zasilania danymi kontrolki, ale powinniśmy pamiętać, aby nie generować dodatkowych obiektów, niewnoszących żadnej dodatkowej informacji. Dla potrzeb tworzenia kontrolki wykorzystamy obydwa pola tabeli IdDzicilu i Opis (rysunek 2.62). Pierwsze z tych pól zostanie wykorzystane do synchronizacji z podformularzem, a drugie będzie widocznym elementem listy (pełna analogia z odnośni­ kami). Działanie kreatora jest takie, że nawet jeśli nie zostanie jawnie wybrane pole klucza podstawowego, jest ono automatycznie dodawane do źródła danych pola kombi. Kolejny etap to wybór sortowania (rysunek 2.63). Warto wybierać sortowanie w opar­ ciu o pole, które będzie widoczne na liście. Pozwala to na szybsze jej przeszukiwanie, jeżeli zawiera ona dużo wartości. Dodatkową przyjazną cechą pól kombi jest to, że jeżeli zaczniemy wpisywać poszukiwaną frazę, to lista automatycznie zostanie prze­ winięta do pierwszego elementu, którego początek jest zgodny z wpisywanym tekstem. Czyli w przypadku posortowanej listy wystarczy wpisać początek nazwy, a wszystkie rozpoczynające się od tej samej frazy znajdą się za pozycją, do której przewinęła się lista. Ma to szczególnie duże znaczenie przy długich listach.

56

Bazy danych. Pierwsze starcie

Rysunek 2.61. Zastosowanie kreatora do tworzenia pól kombi — wybór źródła danych dla kontrolki

Rysunek 2 .6 2 . Zastosowanie kreatora do tworzenia pól kombi— wybór przetwarzanych pól dla kontrolki

B? Formularzl : Formularz

JE3532E2 L J W IS s L . •11 •

□ I - tt-t • fS z c z tgdy

J / i i ab l f l

^orw

ty»

i iT

I •U

- I

U -s a i ■ ja io L -t la m ia

I

‘Kreator pól kombi

(d*x:i ixxi*n : In |n» UX u

Które pola cawisrają wartości, Itóre mają być umtesjnone w formands pola Kombi? Wybrane pola staną uę kolumnami w formanda pola kombi.

Dostępne pola:

AniAi)

| | < Wstecz | [

Qala[ > ~] j

Zaksr.c

Kolejnym elementem jest wybór, czy kolumna kluczy ma zostać ukryta (rysunek 2.64). Powoduje to, że na liście wyświetlane jest drugie z pól. Ukrycie pierwszej kolumny, tak samo jak w przypadku definiowania odnośników, powoduje tylko ustawienie jej szerokości na wartość 0. Pomimo iż kolumna kluczy jest niewidoczna, to wybranie któregoś z widocznych elementów listy powoduje, że przekazywana jest wartość klu­ cza odpowiadającego tej pozycji. Inaczej można powiedzieć, że wartością pola kombi jest wartość klucza dla wybranego pola.

57

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne Rysunek 2.63. Zastosowanie kreatora do tworzenia pól kombi— wybór sortowania dla kontrolki

Jahsj kclajnoid sortowania chcesz ożyć dla to) Łsty? Rckcrdy moina sortować według najwyżej czterech pól, zarówno w porządhj rosnącym, jaki malejącym. 1 E3 (erah) 2 IdDzialu

EŹTZ

|vc| |

j

Rosnąco

|

1.______ *22*°, I

3

v | ]

Rusną-p

■ł |

v |

Rosnąco

|

AreAij

j

| | < Wstecz

| |

Qa!c| >

| j

Zcteiicz

i

Rysunek 2.64. Zastosowanie kreatora do tworzenia pól kombi— ukrywanie kolumny klucza dla kontrolki

Ostatnim elementem tworzenia pola kombi za pomocą kreatora jest nadanie mu etykiety (rysunek 2.65). Pamiętać musimy, że etykieta nie jest równoznaczna z nazwą kon­ trolki. Pola kombi tworzone za pomocą kreatora mają przypisywane nazwy według klucza — Kombi + kolejna liczba parzysta, np. KombiO, Kombi2 etc. Standardowo nada­ ne nazwy kontrolki możemy zmienić z poziomu jej właściwości.

58

Bazy danych. Pierwsze starcie

Rysunek 2 .6 5 . Zastosowanie kreatora do tworzenia pól kombi— nadawanie nazwy (etykieta kontrolki)

11

A j alil

3____ L 0 ____ ■

aaaP

- B a iaJfc

S iseę óly . 1 . 1

Ć, P & 3 'j s £3 ŚSffil

L . v ; ____

□ Li 1 □

Kreator pól kombi

etyHeta ma być prryptsana do obiegu: pole kcmfci7

Ba................. To )uź wszystHs odpowtedd, Hćrych kreatcr potrzebował do utworzenia formariu; pdo fcrria.

------------

□ WyświetJ pomoc d o t y c z y dostosowania fcrmantu pcła hombl.

Anulu) | | | | Zajyfe | Drugim obiektem umieszczonym na formularzu ma być synchronizowany z polem kombi podformularz. Tak samo jak w przypadku pola kombi skorzystamy z przybor­ nika i kreatora formularzy (rysunek 2.66). W pierwszym kroku mamy do wyboru, czy chcemy użyć istniejącego formularza, czy też z tego miejsca stworzymy nowy. Po­ nieważ wybór istniejącego formularza niesie ze sobą mniej informacji, skorzystajmy z drugiej opcji. W tym celu zaznaczamy pozycję Użyj istniejących tabel. Rysunek 2 .66. Zastosowanie kreatora do tworzenia pod/ornndarza — wybór typu źródła danych dla kontrolki

Kreator Podformularz Podraport Kriwlor podfoimuUr/f

O ftfyl M.Tryyytti [.łbul Ibwarend

O btriefragofcrrxLrl»

ll

a*!* I I '**<=

Jako źródło danych wybierzemy tabelę Osoby, z której pobierzemy do definicji formu­ larza pola: IdDzialu, Nazwisko, Imię. Oczywiście tak samo jak w przypadku tworze­ nia niezależnych formularzy możliwe jest użycie do definicji pól z więcej niż jednej tabeli. Należy pamiętać o tym, że powinny być one ze sobą powiązane w schemacie bazy (relacje).

Rozdział 2. ❖ Projektow anie bazy danych — narzędzia wizualne

59

Rysunek 2 .6 7 . Zastosowanie kreatora do tworzenia podfortmdarza— wybór źródła danych oraz wyświetlanych przez kontrolką pól

Ostatnim krokiem jest nadanie nazwy tworzonemu podformularzowi (rysunek 2.68). Pod taką nazwą będzie on występowa! zarówno jako kontrolka na formularzu, jak i formularz w bazie danych. Czasami na tym etapie kreator potrafi zachowywać się mało stabilnie i pod obiekt źródłowy (właściwości podformularza) podstawiany jest nieodpowiedni formularz. Po wykonaniu opisanych dotychczas czynności otrzymujemy projekt formularza (ry­ sunek 2.69), który w widoku roboczym jest przedstawiony na rysunku 2.70. Niestety dotychczasowe działania nie doprowadziły do synchronizacji obu kontrolek (pole kombi i podformularz). Wnioskujemy stąd, że wstawiane kontrolki nie mają automatycznego mechanizmu synchronizacji, a nasza praca wymaga uzupełnień. W widoku projektu wybierzmy podformularz traktowany jako całość (kontrolka), a na­ stępnie prawym przyciskiem myszy przejdźmy do ustawiania jego właściwości (rysu­ nek 2.71). Interesują nas pozycje: Nadrzędne pola łączące oraz Podrzędne pola łączące. Nadrzędnym polem łączącym jest kontrolka w formularzu głównym — w naszym przypadku pole kombi KombiO. Natomiast ponieważ pole kombi, tak jak to pokazano przy jego definiowaniu, zwraca pole klucza IdDzialu, podrzędnym polem jest to pole z podformularza.

60

Bazy danych. Pierwsze starcie

Rysunek 2 .6 8 . Zastosowanie kreatora do tworzeniapod/onmtlarza— nadanie nazwy’ kontrolce Rysunek 2 .6 9 . Końcowy wygląd projektu formularza po umieszczeniu dwóch kontrolek (pole kombi i podformularz)

Jak można zobaczyć na iysunku 2.72, teraz występuje synchronizacja Po wybraniu z listy działu Administracja w podformularzu wyświetlani są tylko pracownicy tego działu. Jeżeli z tego podformularza wprowadzany byłby nowy rekord, to nasz pracownik auto­ matycznie zostanie przypisany do danego działu. Zwróćmy uwagę na nadmiarowość informacji zawartych w formularzu. Ponieważ pole kombi pokazuje nazwę wybranego

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

61

Rysunek 2.70. Końcowy wygląd formularza do edycji danych po umieszczeniu dwóch kontrolek (pole kombi i podformularz) — bez synchronizacji

Rysunek 2.71. Projekt formularza — definiowanie pól synchronizujących podformularz z polem kombi (właściwości podformularza)

działu, to można pole IdDzialu usunąć z podformularza. Nie spowoduje to utraty syn­ chronizacji, gdyż wystarczy, aby pole podrzędne było elementem; polem obiektu źró­ dłowego formularza natomiast nie musi być koniecznie, aby było jawnie wyświetlane. Do tej pory synchronizacja dotyczyła pojedynczej kontrolki na formularzu. Użyta we właściwościach liczba mnoga (pola łączące) wskazuje, że możliwa jest synchronizacja dla kilku kontrolek, a co za tym idzie pól. Spróbujmy opracować formularz pozwalający na wyświetlenie informacji, który' pra­ cownik wystawił faktury któremu klientowi (rysunek 2.73). W tym celu musimy zdefi­ niować dwa pola kombi pobierające dane, jedno z tabeli Osoby, drugie — Klienci. W de­ finicji wybrane zostaną pola kluczy, natomiast drugą kolumnę będzie stanowiło wyrażenie = Nazwisko & ' ’ &

Im ię

Bazy danych. Pierwsze sta rcie

62

Rysunek 2 .7 2 . Końcowy wygląd formularza do edycji danych ze zdefiniowaną synchronizacją pomiędzy podformularzem a polem kombi

Rysunek 2 .7 3 . Projekt formularza — definiowanie pól synchronizujących podformularz z dwoma polanu kombi (właściwości podformularza)

Dodatkowo na formularzu umieszczamy podformularz utworzony w oparciu o tabelę Faktura, a zawierający pola: IdOsoby, Data, IdKlienta. Jako Nadrzędne pola łączące wykorzystano tym razem listę (pozycje oddzielane średnikami) zawierającą obie kontrolki — KombiO;Kombi2. Podrzędne pola łączące to również lista, zawierająca IdOsoby;IdKlienta. Synchronizacja odbywa się teraz w ten spo­ sób, że porównywane są odpowiednie pozycje na liście elementów łączących (KombiO= *-►IdOsoby AND Kombi2=IdKlienta). Proszę zwrócić uwagę na łączący obie równości operator logiczny AND. Powoduje on. że aby cokolwiek zostało wyświetlone w formu­ larzu, oba pola kombi muszą mieć wybrane elementy. Przy otwarciu formularza żadna z list nie ma wybranej wartości — bo nie zdefiniowano wartości domyślnych. Końcowy wygląd formularza ze zdefiniowaną synchronizacją pomiędzy' podformularzem a dwoma polami kombi przedstawia rysunek 2.74.

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

63

Rysunek 2.74. Końcowy wygląd formularza do edycji danych ze zdefiniowaną synchronizacją pomiędzy podformularzem a dwoma polami kombi

Powróćmy do wywodów dotyczących tworzenia formularza z podformularzem. W trak­ cie ich tworzenia z zastosowaniem kreatora okazało się konieczne zdefiniowanie po­ łączenia między tabelami źródłowymi. Jednakże jeśli teraz obejrzymy utworzony przez nas formularz w widoku projektu (rysunek 2.75) i wyświetlimy jego właściwości jako kontrolki, to zobaczymy, że do synchronizacji został użyty taki sam mechanizm jak do synchronizowania formularza z polem kombi.

Rysunek 2 .7 5 . Projekt formularza— definiowanie pól synchronizujących podformularz z formularzem (właściwości podformularza)

Ustanowiona została synchronizacja dzięki wprowadzeniu nazw odpowiednich pól we właściwościach Nadrzędne i Podrzędne pola łączące. Zatem do poprawnego funkcjo­ nowania tego obiektu nie jest konieczne tworzenie żadnych połączeń między tabelami.

Bazy danych. Pierwsze sta rcie

64

Można się o tym upewnić, usuwając w schemacie połączenia między tabelami, a następ­ nie tabele (kolejność obowiązkowa — usunięcie tabel z diagramu nie usuwa połącze­ nia między nimi!). Stąd możemy wnioskować, że połączenie tabel w diagramie jest po­ trzebne tylko dla poprawnego funkcjonowania kreatora. Na zakończenie tego rozdziału komentarz bardziej ogólnej natury. Korzystanie z kre­ atorów jest bardzo użyteczne, wychodzi bowiem naprzeciw wrodzonemu lenistwu ga­ tunku ludzkiego. Jednak po pierwsze trzeba dobrze zdawać sobie sprawę z tego, co tak naprawdę dzieje się pod wierzchnią warstwą tego narzędzia. Po drugie zaś — kre­ ator jest narzędziem do wstępnego przygotowania obiektu, który następnie powinien być wzbogacony (poprawiony, uzupełniony) przez programistę. Możemy to wykonać tylko pod warunkiem spełnienia pierwszego z warunków — gdyż tylko wtedy wiemy, co i jak modyfikować.

Zapytanie przez formularz Poprzedni podrozdział poświęcony został metodzie synchronizacji kontrolek. Słabą stroną tego mechanizmu jest to, że możemy do synchronizacji używać tylko warunków rów­ nościowych, ewentualnie połączonych operatorem logicznym AND. Często interesują nas nie konkretne wartości filtrowanych danych, ale pewien ich zakres. Dodatkowo ze względu na sposób realizacji w przypadku niewybrania (niewpisania) wartości w kon­ trolce element synchronizowany nie będzie zawierał żadnych wartości. Obie te niedo­ godności można pominąć, stosując mechanizm zapytania przez formularz (query by form), który jest przedmiotem niniejszego rozdziału. Opracujemy, wykorzystując kreator, formularz, który będzie wyświetlał po naciśnięciu klawisza kolejny formularz zawierający osoby urodzone w roku danym przez wartość pola tekstowego zawartego w głównym formularzu. W tym celu stwórzmy nowy, pusty formularz, na którym umieścimy pole tekstowe (rysunek 2.76). Nadajmy temu polu we właściwościach nazwę Minimum (domyślne nazwy pól tekstowych mają postać Tekst + kolejny numer nieparzysty, np.: Tekst], Telcst3 etc.). Kolejnym etapem jest umieszczenie przy włączonym kreatorze przycisku polecenia. Pierwszy krok działania kreatora przycisku (rysunek 2.76) wymaga wybrania grupy akcji (Operacje na formula­ rzach) oraz konkretnego zadania z tej grupy (Otwórz formularz). Należałoby zwrócić uwagę na szeroki potencjalnie wybór akcji związanych z działaniami na formularzach. Kolejnym etapem jest wybór otwieranego formularza (rysunek 2.77). Nie istnieje w tym miejscu możliwość stworzenia nowego formularza, a tylko odwołania się do wcześniej zapisanego obiektu. Następnym elementem jest określenie, które dane mają być wyświetlone (rysunek 2.78). Do wyboru są dwie opcje: wyświetlenie wszystkich rekordów albo tylko określonych danych. Pierwsza z opcji nie pozwala na zdefiniowanie żadnego filtrowania (na po­ ziomie działania kreatora). Druga z nich pozwala na sformułowanie prostego, opartego o równość pola w formularzu głównym i otwieranym, warunku do wyświetlania kon­ kretnych danych.

65

Rozdział 2. ❖ Projektow anie bazy danych — narzędzia wizualne

Rysunek 2.76.

Zastosowanie kreatora do Morzenia przycisku otwierającego formularz

Kreator Przycisk polecenia Kreator prrychkdw polecęA JaM tścK na spo^adwłać rvadr*^» prtytb>u? U i IaMsI k J r y r l cfcdtyrtt p ró żn e ak)e. K itjyrte łUiN*y>wjr»e 1eicrdan n i rekerdarh Opwecja fti repcitsth RĆZr*

Dniid U tty y fCTTTŁŁsrj Cniii) fcrmiari Eć/tuJ f t r Inrttens O diW t dsna Icrtmiana Otwćłr strzraz ZAninl IzmJ^n Zzilsaj) ftts formulxrj

ArUcl

j

< y g f f?

i

r

j|

>

Rysunek 2.77.

Zastosowanie kreatora do tworzenia przycisku otwierającego formularz— uybór otwieranego formularza

z ........ ||

^Szcteoćły

□

iTekstl

u1 1

D _

Po.rscervs2

|Ntewi$zany

i ____ i iL Z J

ii____ i i --i— Kreator przyctikdwpoleceń

o ssssa A i abl Q

0 l?5

_ s l p i -j

Jak) fomniarz ma być unriicm icny za pomocą przycisku pclsceria? IFaktura podfornuiarz [Osoby Osoby oodfwmtfarr

Sychrol Synchro

Zarobki PcdformuLarz

Anuluj

< Wstecz

QdeJ >

Zcfcończ

Dalszy wybór dotyczy określenia porównywanych pól (rysunek 2.79): pola w formu­ larzu głównym (lista po lewej stronie okna) oraz pola w otwieranym formularzu (lista po prawej stronie). Kolejne etapy mają tylko znaczenie formalne (wizualne) i dotyczą sposobu przedsta­ wienia przycisku na formularzu (rysunek 2.80) oraz nadania nazwy temu przyciskowi (rysunek 2.81). Najważniejszym elementem, z którymi powinniśmy sic zapoznać, jest kod obsługi zda­ rzenia Przy kliknięciu, który' został automatycznie wygenerowany na skutek działania kreatora (listing 2.6).

66

Bazy danych. Pierwsze sta rcie

Rysunek 2.7 8 . Zastosowanie kreatora do tworzenia przycisku otwierającego form ularz— wybór trybu otwarcia formularza

Rysunek 2 .7 9 . Zastosowanie kreatora do Morzenia przycisku otwierającego formularz — iwybór porównywanych pól ii’formularzu nadrzędnym i otwieranym

Listing 2.6 . Kod procedury obsługującej zdarzenie Przy kliknięciu przycisku otwierającego formularz z filtrowaniem — zapytanie przez formularz (ąuery by form) Private Sub Polecenie3_Click() On Error GoTo Err_Polecenie3_Click Dim stDocName As String Dim stL in k C rite ria As String stDocName = "Osoby podformularz"

Rozdział 2. $ Projektow anie bazy danych — narzędzia wizualne

67

Rysunek 2.80. Zastosowanie kreatora do tworzenia przycisku obierającego formularz — wybór sposobu wyświetlania prz)'ctsku

Rysunek 2 .81. Zastosowanie kreatora do tworzenia przycisku obierającego formularz — wybór nazwy przycisku

Jaką nazwę chcesz nadać przyciskowi? Nazwa opisowa pomoże później w odwoływaniu się do tego przydsJu.

| To już wszystko informacje potrzebne kreatorowi do utworzenia przycisku pcfecema.

□

WyiwictJ Eorr.cc dotyczącą dostosowywania przyciski.

Anuluj

stL in k C rite n a = "[Rokllrodz]=" & Me![Minimum] DoCmd.OpenForm stDocName. . . stL in k C rite ria Exit_Po1ecen i e3_C1i ck: E xit Sub Err_Polecen i e3_Cli c k : MsgBox Err.D escnption Resume Exit_Polecenie3_Click End Sub

11 < Wstecz

|

[V e j >

.|

Zakończ

68

Bazy danych. Pierwsze sta rcie

Omówmy szczegółowo kod powyższej procedury. Tak samo jak w przypadku zdarzeń obsługujących nawigację utworzona została procedura prywatna, w której pierwszej linii zdefiniowano dyrektywę obsługi błędów. Również końcówka kodu związana z działaniem w przypadku pojawienia się błędu przetwarzania, a zasadzająca się na wyświetleniu komunikatu o błędzie, jest praktycznie dokładną kopią obsługi przyci­ sków nawigacyjnych. Środkową część procedury stanowią deklaracje dwóch zmiennych lokalnych (Dim Zmienna AS typ — oznacza, że jest ona określonego typu, a zasięg jej widoczności ogranicza się tylko do wnętrza procedury) — stDocName i s t L in k C r it e r ia . Obydwie zmienne są typu znakowego. Pod zmienną stDocName jest podstawiana war­ tość będąca nazwą otwieranego formularza. Natomiast zmienna S tL in k C r ite r ia zawiera w sobie wyrażenie filtrujące. Najważniejszym elementem jest odwołanie się do metody OpenForm obiektu DoCmd. Metoda ta wymaga podania kilku parametrów. Pierwszym jest nazwa otwieranego formularza (stDocName). Drugi parametr zawiera tryb otwarcia i może przyjmować jedną z sześciu postaci: ❖ acDesign — do projektowania; ❖ acFormDS — tak jak arkusz danych; ❖ acForm PivotChart — w postaci wykresu przestawnego; ❖ acFormPivotTable — w postaci tabeli przestawnej; ❖ acNormal — (domyślna) w postaci do wprowadzania danych; ❖ acPrevi ew — w postaci podglądu do wydruku. Ponieważ domyślną postacią jest widok formularza, ten parametr może pozostać nieustawiony (domyślny). Kolejnym parametrem jest nazwa filtra, która wbrew nazwie nie zawiera kryterium filtrowania, a nazwę zapisanego w bazie zapytania, które zostanie podstawione pod dane. Kolejnym, najważniejszym z naszego punktu widzenia, parame­ trem jest klauzula WHERE (Where condition), zawierająca właśnie wyrażenie filtrujące. Kolejne parametry to — tryb dostępu do danych: ❖ acFormAdd — użytkownik może dodawać nowe rekordy, ale nie może modyfikować istniejących; ❖ acForm Edit — użytkownik może dodawać nowe rekordy oraz modyfikować istniejące; ❖ acForm PropertySettings — (tryb domyślny) — formularz ma takie właściwości, jakie zostały ustawione przez twórcę; ❖ acFormReadOnly — użytkownik może tylko przeglądać istniejące rekordy; sposób wyświetlenia formularza: ❖ acDi alog — formularz ma ustawione właściwości Modalny i Podręczny na Tak; 0 acHidden — formularz jest ukryty; ❖ aclcon — formularz jest otwierany w postaci zminimalizowanej na pasku zadań Windows; ❖ acWindowNormal (tryb domyślny) — formularz ma takie właściwości, jakie zostały ustawione przez twórcę;

Rozdział 2. ❖ Projektow anie bazy danych — narzędzia wizualne

69

oraz dodatkowe argumenty — użyteczne w przypadku stosowania mechanizmów wy­ miany danych. Przyjrzyjmy się bliżej wyrażeniu nitrującemu (stLinkC riteria), które zostało wyge­ nerowane przez kreator. Składa się ono z dwóch elementów połączonych operatorem konkatenacji: napisu ("[Rokllrodz]=") i zmiennej (Me! [Minimum]). Należy zwrócić uwagę, że nazwy kontrolki oraz pola w otwieranym formularzu ujęto w nawiasy kwadratowe. Jeśli w nazewnictwie, zgodnie z wcześniejszymi ustaleniami, nie używaliśmy separatorów w postaci spacji oraz polskich znaków diakrytycznych, to oba nawiasy mogą zostać usunięte. Druga część to odwołanie do właściwości kontrolki obiektu Me. Obiekt Me zastępuje nazwę bieżącego obiektu (podobnie jak w języku C -u- — th is), w naszym przypadku jest to formularz. Kreator stosuje stare, pochodzące jeszcze z początków Accessa odwołanie do właściwości przez znak wykrzyknika (/). Wskazane jest jednak używanie, tak jak się to robi współcześnie, odwołania przez znak kropki (.). Takie po­ dejście m atę zaletę, że wpisanie po nazwie obiektu separatora (kropki) wyświetla listę wszystkich dostępnych dla obiektu właściwości i metod. Zgodnie z tymi ustaleniami mo­ żemy wyrażenie filtrujące zmodyfikować do postaci przedstawionej na listingu 2.7. Listing 2 .7 . Fragment kodu procedury obsługującej zdarzenie Przy kliknięciu przycisku otwierającego formularz z filtrowaniem — skorygowane wyrażenie filtrujące— klauzula WHERE (Where condition) S tLin kC riteria = "RokUrodz=” & Me.Minimum

Możemy teraz zmienić działanie formularza, modyfikując kod obsługi zdarzenia dla przy­ cisku, a dokładnie tylko linijkę opisującą warunek filtrowania. Jeżeli w formularzu wsta­ wimy kolejną kontrolkę typu pole tekstowe i nadamy mu nazwę Maksimum, to możemy tak zmodyfikować wyrażenie filtrujące, że wyświetlane będą tylko osoby urodzone w latach z przedziału danego tymi wartościami (listing 2.8). Listing 2 .8 . Fragment kodu procedmy obsługującej zdarzenie Przy kliknięciu przycisku otwierającego formularz z filtrowaniem — skorygowane uyrażenie filtrujące dla przypadku wybierania osób urodzonych ii’przedziale lat danym dwoma polami tekstowymi stL in k C rite ria = "RokLIrodz >" & Me.Minimum & " AND Rokllrodz <’’ & He.Maksimum

Warto zauważyć, że w wyrażeniu filtrującym operator logiczny ANDjest częścią napisu oraz poprzedzająca go spacja jest obowiązkowa. W przeciwnym przypadku doszłoby do „sklejenia” zawartości pola Minimum z tym operatorem. Działanie formularza z tak zdefiniowanym filtrem przedstawia rysunek 2.82. Podobnie, wprowadzając kolejną parę pól tekstowych {Pocz oraz Kon) i kolejny przy­ cisk, możemy sparametryzować danymi z formularza filtr wyświetlający osoby, których pierwsza litera nazwiska zawiera się w przedziale danym tymi wartościami. Statyczną postać filtru oraz jej realizację dynamiczną przedstawia listing 2.9.

70

Bazy danych. Pierwsze sta rcie

Rysunek 2 .8 2 . Końcowy wygląd formularza wywołanego z zastosowaniem mechanizmu „zapytanie pizez formularz ” ii' przypadku wybierania osób urodzonych it’przedziale lat

S&ajal

' /apytanłcPr7C2rormu!flr2: formularz

jE

[T [ ;twćrz

Maksimum

(iseó

O b a li Tab

fi5

H g H

Osoby Podformutarz IdOtofcy IdDaaki

_

Nazwisko

lirie

RokUrada "V

I

1 |Hand!owy

lvl (Kowalski

pan

|

2 [Aćrninistiacja

ly] |Nowak

pćzef

5 jHandbwy

ivl |Janlk

|FoU

1975

jpiotl

197B

1977 ;

1379

!

8 |Henc£owy

|Kowal

9 |Handawy

ty] |Jokow

Jwikla

j

11 [Handlowy

te) |Kow

JWit

12 |Techrw::ny

tyj |Polakow

paiosław

|

1974

13 [gasB Ę B

ly] |Lew

iKonslenly

|

1975

IMi|

1

i-

| T

| lAutcnumeroweniaJ [i Rekord: IM H 4 l |

J C | ► ]| M

1977 j

1974

75 1 M ||

i B(KŁr)

Listing 2 .9 . Postać statyczna filtru wybierającego nazwiska, których pierwsza litera zawiera się it’ obustronnie domkniętym pizedziale , oraz je j postać parametiyczna dla potrzeb mechanizmu zapytania przez formularz Nazwisko LIKE ' [k-n]*' s tL in k C n te ria = "Nazwisko LIKE '[" & Me.Pocz &

& Me.Kon &

Kolejny przykład parametryzacji wymaga wprowadzenia kolejnej pary pól tekstowych (OD oraz DO), a także kolejnego przycisku. Tym razem interesują nas pracownicy zatrudnieni (DataZatr) w przedziale dat wpisanych do pól tekstowych. Przykład ten jest pretekstem do pokazania parametryzacji operatora przedziału BETWEEN oraz pokazania, że aby zawartość pola tekstowego była traktowana (przetwarzana) jak zmienna typu data. musi być ujęta w znaki II (hash). Innymi słowy, możemy powiedzieć, że o ile ogranicznikiem pola tekstowego jest para znaków ' ' (apostrof), to ograniczni­ kiem pola daty jest para znaków U # (hash) (listing 2.10). Przydatną w tym miejscu wiadomo.ściąjest to, że kombinacja klawiszy CTRL+; wpisuje do pola tekstowego bieżącą datę systemową. Pozwala to na ominięcie wielu problemów wynikających z lokalnych ustawień formatowania daty. Listing 2 .1 0 . Postać statyczna filtru wybierającego nazrwiska pracowników, którzy zatrudnieni zostali ii’ obustronnie domkniętym przedziale dat, oraz je j postać parametryczna dla potrzeb mechanizmu zapylania przez formularz DataZatr BETWEEN #1995-06-06# AND #1999-12-11# s tL in k C rite ria = "DataZatr BETWEEN #" & Me.Od & "# AND #" & Me.Do & "#”

Kolejnym ciekawym problemem, który daje się rozwiązać przy zastosowaniu mecha­ nizmu zapytania przez formularz, jest problem braku wartości (wartości NULL) w kon­ trolkach służących do definiowania filtra. W opracowanych przed chwilą trzech przy­ kładach brak podania jednej z wartości powoduje wyświetlenie komunikatu o błędzie

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

71

błąd składniowy w wyrażeniu. Rzeczywiście, jeśli wrócimy do pierwszego przykładu, przyjmując, że np.: wartość mimmum=1970 oraz brak jest wartości w polu maksimum, po podstawieniu filtr ma postać Rokllrodz 1970 AND RokUrodz <

Jeśli chcemy tego uniknąć, możemy założyć, że: ❖ jeśli nie podamy żadnego z pól, wyświetlane będą wszystkie rekordy; ❖ jeśli nie podamy pola minimum, wszystkie mniejsze niż maksimum; ❖ jeśli nie podamy pola maksimum, wszystkie większe niż minimum; ❖ jeśli podane są oba pola, rekordy z przedziału od minimum do maksimum. Najbardziej oczywistym rozwiązaniem jest sprawdzenie po kolei wszystkich warun­ ków podanych na liście i dla każdego z nich wygenerowanie odpowiedniego warunku — wartości zmiennej użytej w metodzie OpenForm w charakterze klauzuli WHERE. Można również użyć wybiegu pozwalającego na składanie wyrażenia z łańcuchów składowych. Wstępną wartością łańcucha musi w tym przypadku być wyrażenie, o któ­ rym wiemy, że jest zawsze prawdziwe, np. /=7. Następnie możemy dokładać składniki wyrażenia, sprawdzając dla pojedynczego pola tekstowego warunek „czy jest NULL” (listing 2.11). Listing 2. UL Fragment kodu obsługując}’przypadki. gdy me zostały wpisane wartości do obu pól filtru u1s)'tuacji wybierania osób urodzonych w przedziale lat danym dwoma polami tekstowymi — dla potrzeb mechanizmu zapytania przez formularz____________________ stL in k C rite ria = "1=1" I f (Not IsNull(Me.Minimum)) Then stL in k C rite ria = stL in k C rite ria & “ AND RokUrodz >" & Me.Minimum End If I f (Not IsNull(Me.Maksimum)) Then stL in k C rite ria = stL in k C rite ria & " AND RokUrodz <" & Me.Maksimum End If

Przedstawiony schemat postępowania pozwala na ograniczenie liczby instrukcji wa­ runkowych IF, co powoduje uproszczenie opracowanego kodu. Zastosowana tu meto­ dologia jest słuszna tylko dla przypadku warunków wyrażanych za pomocą operatorów algebraicznych połączonych operatorami logicznymi AND. Dla połączenia za pomocą operatorów logicznych OR wydaje się zasadne stosowanie jako wyrażenia bazowego warunku, który jest zawsze fałszywy, np. 1=2. Jeśli używano mieszanych połączeń AND/OR lub też warunek jest wyrażony za pomocą operatorów specjalnych, należy posłużyć się bardziej ogólnym rozwiązaniem ze sprawdzeniem po kolei wszystkich możliwych przypadków. Pomimo ograniczonego zastosowania pokazanego rozwiązania jest ono bardzo użyteczne, gdyż większość w praktyce spotykanych filtrów da się sprowadzić do przedziału. Oczywiście istnieje możliwość zastosowania mechanizmu zapytania przez formularz w przypadku otwierania raportów. Dla zilustrowania takiego przypadku wykorzystajmy zbudowany przez nas formularz, dodając do niego kolejny przycisk. Będziemy two­ rzyć filtr pozwalający na wyświetlenie osób z przedziału lat — tak jak w pierwszym

72

Bazy danych. Pierwsze sta rcie

z przypadków analizowanych dla formularza. W tym celu wstawmy z przybornika do formularza dodatkowy przycisk polecenia, tym razem określmy kategorię jako Opera­ cje na raportach, akcją, będzie natomiast Podgląd raportu (rysunek 2.83). Autor uważa, że bezpośrednie przesyłanie raportu na drukarkę, bez wcześniejszej weryfikacji jego zawartości na ekranie, jest błędem. Rysunek 2 .8 3 . Zastosowanie kreatora do tworzenia piz)’cisku otwierającego raport

delt jfiPjZapytanloPrzezrormularz: Formularz

0@ _xj • u • Wl

Tebt |l~~]f Kwei Fcm Rep Strc.'

Mak

IM

* d lQ 'MWmujnl E3 jfłeowtązsny a .c a -g S I 'j g t£śt. m

|M eK ń« n

|w.e zw ijany

-

i -

a

Pd;cęnlei7

Kreator przycisków poleceń Jaką akcj- ma spowodować n&dśnłęcie przycisku?

Dła każdej kateęcri dostępna są różne akxje.

£Jxjs:

Katwjorłe:

1Nawigowania pcrrJ-dzy rekordami 1 |D n Jłil report Ooefada na rekordach |Operach na formularzach IWyśSJ report do pUu Operacie naracortsch W yil) report pocztą Ap£Kec(e fióine

[

AraĄj)

11

< Wttecz

11

Ęa!e| >

j[

Sajjańc

Kolejne okienka dialogowe pozwalają, na wybranie nazwy otwieranego raportu oraz przypisanie do przycisku napisu lub ikony, a na koniec nadanie temu przyciskowi nazwy. Proszę zwrócić uwagę, że podczas pracy tego kreatora (odmiennie niż w przypadku akcji otwierania formularza) nie wystąpiło pytanie o to, czy wyświetlić wszystkie dane, czy tylko wybrane. W związku z tym nie ma również możliwości skonstruowania w tym miejscu wyrażenia filtrującego (listing 2.12). Czyli kreator akcji Otwórz raport „zakłada”, że będą zawsze wyświetlane wszystkie dane występujące w raporcie, co oczywiście w praktyce nie jest twierdzeniem poprawnym (klient nie chce, aby mu wydrukowano wszystkie faktury, tylko jedną dotyczącą jego transakcji; bilanse też nie są tworzone ze wszystkich danych zgromadzonych w bazie, ale tylko z tych dotyczących danego okresu rozrachunkowego). Listing 2.1 2 . Kod procedury obsługującej zdarzenie Przy kliknięciu prz)>cisku otwierającego raport wygenerowany przez kreator____________________ Private Sub Poleceniel7_Click() On Error GoTo Err_Polecemel7_Click Dim stDocName As String stDocName = "Osoby" DoCmd.OpenReport stDocName. acPreview Exi t_Poleceniel7_Cli ck: E xit Sub

Rozdział 2. ❖ Projektow anie bazy danych — narzędzia wizualne

73

Err_Poi eceni el7_Cl i ck: MsgBox Err.Description Resume Exit_Poleceniel7_Click End Sub

W porównaniu z kodem procedury obsługującej otwarcie formularza zmieniła się tylko metoda obiektu DoCmd na OpenReport (listing 2.13). Zgodność parametrów obu metod jest pełna, natomiast nieco zmieniają się dostępne wartości. Dla trybu otwarcia do­ stępne są tylko trzy wartości: ❖ acVi ewDesign — widok projektu raportu; ❖ acViewNormal — wysianie raportu na drukarkę (wartość domyślna); ❖ acViewPreview — otwarcie raportu w widoku podglądu wydruku. Listing 2 .13. Fragment kodu procedur}' obsługującej zdarzenie Pizy kliknięciu przycisku otwierającego raport z filtrowaniem — wyrażenie filtrujące dla prz)>padku wybierania osób urodzonych it>przedziale lat danym dwoma polami tekstowymi Dim Where As String Where = "RokUrodz >" & Me.Minimum & " AND RokUrodz <” _ & Me.Maksimum DoCmd.OpenReport stDocName. acViewPreview. . Where

Aby uzyskać filtrowanie, konieczne jest uzupełnienie kodu o (listing 2.13): ❖ zdefiniowanie zmiennej filtra, ❖ podstawienie pod nią właściwego wyrażenia filtrującego ❖ oraz użycie tej zmiennej w wywołaniu metody. Można posłużyć się kopią utworzonego wcześniej kodu otwierającego formularz. Po­ mimo, jak się wydaje, dużej prostoty tworzenia wyrażeń filtrujących, w praktyce, jak to wynika z doświadczeń dydaktycznych autora, ten element w początkowej fazie na­ uki sprawia studentom bardzo dużo problemów. Jest to głównie związane z małym doświadczeniem programistycznym. Najczęściej pojawiającym się błędem jest umiesz­ czanie operatorów logicznych poza wyrażeniami znakowymi i traktowanie ich tak jak operatora konkatenacji łączącego elementy wyrażenia. Na tym tle kolejny element jest zdecydowanie mniej istotny. Otóż w przypadku otwierania raportu, aby cokolwiek zobaczyć na podglądzie, zwykle maksymalizujemy okienko, w którym jest on wyświetlany. Natomiast po jego zamknięciu chcielibyśmy przywrócić ustawione w trakcie projektowania wymiary formularza, zamiast wyświetlać go na całym ekranie. Operacje te możemy zautomatyzować, tworząc procedury' obsługi zdarzeń raportu: Przy otwarciu DoCitid.Maximize

oraz Przy zamknięciu DoCmd. Restore

74

Bazy danych. Pierwsze sta rcie

Przejście między obsługą różnych zdarzeń może być wykonane nie tylko z poziomu projektu raportu (właściwości — zdarzenia), ale również z poziomu kodu VB dzięki zmianie zdarzenia na liście zdarzeń (lista nad kodem po prawej stronie). Jeżeli nasz raport ma opcje sumowania, to „ciekawy” efekt otrzymamy przy stosowaniu filtrowania, jeśli chodzi o obliczanie udziałów procentowych. Spróbujmy wyświetlić nasz raport z poziomu formularza Osoby tak, aby zawiera! tylko podsumowanie dla jednej osoby — tej, która jest w tej chwili na formularzu wyświetlana. Powoduje to koniecz­ ność sformułowania wyrażenia filtrującego o postaci przedstawionej na listingu 2.14. Listing 2 .14. Fragment kodu obsługi zdarzenia dla otwierania raportu z zastosowanym filtrowaniem Dim Where As String Where = "IdOsoby" & Ke.IdOsoby DoCmd.OpenReport stDocName, acViewPreview. . Where

Jeśli w ten sposób otworzymy raport, to udział procentowy będzie zawsze wynosił 100%, ponieważ jest liczony w stosunku do sumy wyświetlonych rekordów, a nie do sumy wszystkich rekordów w tabeli. Czyli problemem jest obliczenie na raporcie całkowitej sumy zarobków. Możemy to uzyskać, wpisując jako źródło danych dla pola tekstowego dodanego do stopki dla IdOsoby wyrażenia opartego o funkcję agregatu domenowego (listing 2.15). Listing 2 .1 5 . Zastosowanie funkcji agregatu domenowego do wyznaczenia sumy wszystkich zarobków = DSum("Brutto";"Zarobki")

Należy zwrócić uwagę, że wszystkie parametry funkcji agregatu domenowego (w tym DSum) muszą być podane w postaci łańcucha lub, w przypadku ich wykorzystania w kodzie VB, zmiennej znakowej. Jeśli chcemy wykorzystać tę metodę do wyświetlenia udziału procentowego, to przedstawione wyrażenie będzie tym razem mianownikiem ilorazu, którego licznikiem jest zwykła suma (dla IdOsoby) (listing 2.16). Dodatkowo format pola należy ustawić na procentowy. Listing 2 .1 6 . Zastosowanie funkcji agregatu domenowego do wyznaczenia udziału procentowego ire wszystkich zarobkach____________________________________________________________________ =Sum(Brutto)/ DSumt"Brutto";"Zarobki")

Niekiedy możemy potrzebować wyznaczenia na raporcie funkcji agregującej odfiltro­ wanej dla pewnego zakresu. W naszym przypadku wyznaczmy w sposób konkurencyjny sumę zarobków dla każdego z pracowników, stosując zamiast zwykłej funkcji agregują­ cej funkcję agregatu domenowego. W tym celu umieszczamy w stopce IdOsoby ko­ lejne pole tekstowe o nazwie Razem. Jeśli chcemy użyć statycznego filtru, możemy to wyrażenie napisać jak poprzednio w źródle danych dla kontrolki. Jeśli jednak nasz filtr zmienia się dynamicznie, konieczne jest zastosowanie podejścia programistycznego. W tym celu stwórzmy procedurę obsługi zdarzenia Przy formatowaniu dla stopki grupy IdOsoby (listing 2.17).

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

75

Listing 2 .17. Zastosowanie funkcji agregatu domenowego do wyznaczenia udziału procentowego dla odfiltrowanych zarobków (dla każdego pracownikaj f i l t r “ “ IdOsoby & He.IdOsoby Me.Razem = DSumCBrutto". "Osoby", f i l t r )

W procedurze musimy zdefiniować zmienną filtrującą odwołującą się do pola IdOsoby, której następnie użyjemy jako trzeciego parametru w funkcji DStitn (ponieważ filtr jest nazwą zmiennej, a nie obiektu czy pola, nie jest ujęty w cudzysłów). Wartość tej funkcji jest podstawiana do pola tekstowego. Jeśli jednak na raporcie nie jest jawnie wyświetlone pole IdOsoby, to otrzymamy komunikat o błędzie — Odnalezienie przez MS Access pola. do którego odwołuje się IdOsoby je s t niemożliwe. W przeciwień­ stwie do formularza w obszarze raportu możemy odwołać się tylko do wyświetlanych pól (mogą mieć co najwyżej ustawioną opcję Widoczny— Nie). W przypadku formula­ rza wystarczało, aby pole było elementem jego źródła danych. Omówiony w tym podrozdziale mechanizm zapytania przez formularz jest bardzo wygodnym i bardzo często wykorzystywanym sposobem wyświetlania odfiltrow'anych danych. Jego zalety wynikają zarówno z pełnej kontroli nad zawartością i formatowaniem pól danych wejściowych, jak i możliwości wykorzystywania raz zdefiniow'anych wartości określających zakres filtrowania w wielu formularzach czy raportach. Jako klasyczny przykład można wymienić zadanie księgowe polegające na sporządzeniu wielu sprawozdań (raportów) dla tego samego okresu rozliczeniowego. Z punktu wi­ dzenia obsługi sprowadzi się to do wpisania dwóch dat, początkowej i końcowej, oraz n-krotnego wywołania różnych raportów' przez wybranie odpowiedniego przycisku na formularzu, co znacznie usprawni obsługę i zminimalizuje możliwość pomyłki przy wprowadzaniu danych. Pomimo że prezentowana tu realizacja programistyczna dotyczy tylko środowiska VB i MS Access, mechanizm ten jest bardzo ogólny, a rozwiązania dla innych środowisk są bardzo do prezentowanego tutaj podobne.

WytoirzysftaiHiii© sapyŁam [msdłyffnikaojjącyelhi z p©ZD@mimo świnmanDairzy Tworzenie zapytań modyfikujących dane w aplikacji ma sens wtedy, kiedy odwołujemy się do nich z poziomu formularza. Dostęp do kontenera zapytań, tak samo jak i tabel, dla końcowego użytkownika powinien zostać zablokowany. Zilustrujmy ten problem przez zbudowanie formularza zawierającego podformularz, którego zawartość będzie modyfikowana zgodnie z wybraną z listy funkcją. Na początek zdefiniujmy dwa zapytania aktualizujące (rysunek 2.84), których zadaniem będzie zmiana zawartości tabeli Osoby tak, aby pola Nazwisko i linie przepisywane były odpowiednio małymi lub dużymi literami. Do zdefiniowania sposobu modyfikacji danych zastosowano wbudowane funkcje konwersji UCase oraz LCase. Zapytania te zostały nazwane Małe i Duże zgodnie z ich przeznaczeniem.

76

Bazy danych. Pierwsze sta rcie

!

■

;

Pola: Tabeli:

’ Aktualzada da: >' : H

I

Nazwisko Osoby UCaseffNazwisko])

lmia Osohy UCasefflnie])

Kryteria: lub: w in

"t-r w\

Rysunek 2 .8 4 . Definicja zapytań aktualizujących

W kolejnym kroku stwórzmy nowy pusty formularz, w którym z przybornika wsta­ wimy pole kombi (rysunek 2.85). Zawartość tego pola stanowi statyczna lista wartości odpowiadająca nazwom utworzonych wcześniej zapytań: Dttze; Małe. Zarówno wiel­ kość liter, jak i kolejność usytuowania nie mają znaczenia dla funkcjonowania przy­ kładowego formularza. Sposób definiowania wartości za pomocą kreatora przedstawia rysunek 2.86.

Rysunek 2 .8 5 . Wstawianie pola kombi z danymi u»postaci statycznej listy wartości

Następną czynnością jest wstawianie, również z przybornika, formularza. Będzie on oparty o tabelę Osoby i będzie zawierał dwa modyfikowane pola — Nazwisko, Imię. Fragment procesu definiowania formularza przedstawia rysunek 2.87.

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

i

“]N;£Zwi$Z£ny

|Kreator poi kombi

—

—

mm ' ? A n iu]

|

< yfctec:

|

Bi*) >

i< lr ~ i

Rysunek 2.8 6 , Wstawianie pola kombi z danymi w postaci statycznej listy wartości— definiowanie wartości

Rysunek 2 .8 7 . Wstawianie formularza— definiowanie pól

77

78

Bazy danych. Pierwsze sta rcie

Kolejny etap stanowi oprogramowanie zdarzenia dla pola kombi (rysunek 2.88). Mamy wybór pomiędzy dwoma podobnymi zdarzeniami: Po aktualizacji oraz Przy zmianie. Pierwsze z nich jest obsługiwane, kiedy za pomocą myszki lub klawiszy wybrana zo­ stanie nowa pozycja na liście. Natomiast Przy zmianie dotyczy dowolnej zmiany za­ wartości okienka pola kombi, czyli dotyczy również przypadku, kiedy wpisujemy do okienka wyboru poszukiwaną frazę. Ponieważ zawartość zmienia się z każdym wpi­ sanym znakiem, to i zdarzenie pojawia się równie często. Ponieważ nasza lista zawiera tylko dwie wartości, sensowne jest odwołanie do pierwszego zdarzenia. W drugim z przypadków okienko kombi może zwracać „niedokończone” nazwy zapytań — po­ nieważ ktoś z klawiatury zaczął wpisywać nazwę, np. Duże, i po pierwszej wpisanej i zatwierdzonej literze pole kombi zwróci wartość "D" zamiast pełnej nazwy zapytania. Bez zatwierdzenia (Enter) pole będzie zawierać wartość NULL. Rysunek 2 .8 8 . Definiowanie procedury obsługi zdarzenia dla pola kombi

Najprostszym kodem obsługującym wybrane zdarzenie jest taki, w którym zasto­ sowano metodę OpenQuery obiektu DoCmd. Pozwala on zarówno na otwarcie w widoku Ar­ kusz danych zapytania wybierającego, jak również na wykonanie dowolnego zapisa­ nego w kontenerze zapytania modyfikującego dane lub strukturę bazy (listing 2.18). Listing 2 .1 8 . Definicja procedmy obsługi zdarzenia dla poła kombi P n v a te Sub Zapytam e_ A fterllp d ate() DoCmd.OpenOuery Me.Zapytanie End Sub

Przy tak ubogim, podstawowymi oprogramowaniu zdarzenia otrzymujemy kilka nieko­ rzystnych dla obsługi efektów. Pierwszym są komunikaty systemowe związane z wy­ konywaniem zapytania modyfikującego (rysunek 2.89) oraz liczbą modyfikowanych wierszy (rysunek 2.90). Oba komunikaty po pierwsze sugerują, że użytkownik ma jakiś wybór (może nie wykonać zapytania). Podczas gdy programista po to oprogramował ten fragment, aby został on przetworzony bez ingerencji operatora, bez prawa wyboru.

Rozdział 2. $ Projektow anie bazy danych — narzędzia wizualne

79

Rysunek 2.89. Komunikat informujący o wykonywaniu zapytania modyfikującego dane

Rysunek 2.90. Komunikat informujący o liczbie modyfikowanych wierszy podczas wykonywania zapytania modyfikującego dane

Z a p y l u flic .m u d rO k u ja c c : I o rm u lu r .* Osoby pod; am U ar;

Zapytania

Nszy/tsko Kowalski Nowak Kowalik

|Ms]a

Janik Piotrowski Pawlik Microsoft Office Access

n

m

Jan

Łukasz Piotr Krzysztof iTomasz

mm

Masz zamiar zaktualizować 15 wlcrsz(c).

P

RelocdMjrmf

Po lilr i» o u Tak rso bi^fcw )ul n a ln s w jfcn ać pcfecenia C c/rij I odwróci! zmian. Czy na pewno c lice K zsłiuaizow ać te re«onfy7

i IŻ tsig l • i

Dodatkowo komentarze nieniosące istotnej dla operatora informacji powodują, że prze­ staje on w ogóle czytać jakiekolwiek komunikaty i wszystko, co się dzieje, zatwierdza bez analizy. Dlatego warto byłoby wyłączyć wyświetlanie komunikatów na czas trwania przetwarzania tego fragmentu kodu. Kolejny problem wynika z ogólnej przypadłości Windows (ogólnie produktów MS), a mianowicie niskiego priorytetu odświeżania zawartości ekranu. Możemy zauważyć, że pomimo pozytywnego wykonania zapytania zawartość podformularza nie ulega zmianie. Dopiero przeciągnięcie myszką nad nim albo wybranie jakiegoś pola powoduje całkownte lub częściowe przeliczenie zawartości (rysunek 2.91). Musimy więc wymusić ponowne przeliczenie pól programistycznie (listing 2.19).

Bazy danych. Pierwsze sta rcie

80

Rysunek 2 .9 1 . Częściowe (wymuszone działaniem użytkownika) odświeżanieformularza po wykonaniu modyfikacji danych bez wymuszenia automatycznego odświeżania z poziomu kodu

Listing 2 .19. Definicja procedur}' obsługi zdarzenia dla pola kombi z odświeżaniem Private Sub Zapytanie_Afterl)pdate() DoCmd.SetWarnings False DoCmd.OpenQuery He.Zapytanie DoCmd.SetWarnings True Me.Recalc End Sub

W celu wyłączenia komunikatów systemowych odwołujemy się do właściwości (flagi systemowej) SetW arnings obiektu DoCmd, ustawiając jej wartość na F a ls e . Dobrym zwyczajem programisty jest, aby przy używaniu flag systemowych, po wykorzystaniu ich niestandardowych wartości, przywrócić im stan domyślny. W naszym przypadku flaga SetW arnings ma ustawioną wartość True po wykonaniu zapytania modyfikują­ cego (listing 2.19). Od tej pory komunikaty będą się z powrotem pojawiać (dotyczy to przede wszystkim komunikatów o błędach). W celu wymuszenia odświeżenia zawartości formularza odwołano się do metody Recalc bieżącego obiektu. W MS Access dostępne są cztery metody odświeżania, różniące się w sposób zasadniczy realizacją i zakresem działania (tabela 2.19). Tabela 2 .1 9 . Metody odświeżania obiektów M etoda

Opis

Refresh

Odświeżenie zawartości kontrolki (przerysowanie) oparte o komunikat Windows (niski priorytet)

Repaint

Przerysowanie formularza oparte o komunikat Windows (niski priorytet) Przerysowanie formularza wraz z przeliczeniem wartości dla bieżącego rekordu Przerysowanie formularza wraz z przeliczeniem wartości dla wszystkich rekordów źródłowej tabeli (zapytania)

Recalc Requery

Zastosowanie metody Recalc w naszym przypadku jest uzasadnione tym, ze nadrzędny formularz nie jest oparty na żadnym źródle danych — zawiera jeden (pusty) rekord.

Rozdział 2. ♦ Projektow anie bazy danych — narzędzia wizualne

81

Zatrzymajmy się jeszcze przez chwilę przy problemach związanych z odświeżaniem (przerysowywaniem) kontrolek formularzy. Ilustracją będzie przypadek, kiedy z po­ ziomu formularza otwierany jest automatycznie inny formularz, w którym wykonują się jakieś trwające znaczącą chwilę obliczenia, a następnie ten formularz jest automatycznie zamykany. Przykład został zrealizowany przez wprowadzenie na nowy pusty formu­ larz przycisku i oprogramowanie dla niego zdarzenia Przy kliknięciu. W takim przypadku również mamy do czynienia ze zjawiskiem braku odświeżania (ry­ sunek 2.91). Tak jak poprzednio wymuszenie przeliczenia uzyskano, stosując metodę Recalc tuż po otwarciu formularza. Proces długotrwałego przeliczenia uzyskano przez „sztuczne” wprowadzenie pętli, w której wyznaczono wartość funkcji Sin dla zmien­ nych wartości argumentu (listing 2.20). Rysunek 2.91. Brak odświeżania formularza po jego otwarciu z poziomu kodu (nie zastosowano metody Recalc)

flagi sfcrmulorz

1 “T-ntf.Ky 221I_J E3 O ioby Podfo Listing 2 .20. Definicja procedury obsługi zdarzenia dla przycisku z odświeżaniem Private Sub PolecenieO_Click() On Error Resume Next stDocName = "Osoby" DoCmd.OpenForm stDocName Me.Recalc For i = 1 To 500000 a = S in (i / 10000) Next i DoCmd.Close End Sub

W celu automatycznego zamknięcia formularza zastosowano metodę Cl ose obiektu DoCmd. Skutek działania przykładowego kodu z zastosowaniem metody Recalc przedstawia rysunek 2.92. Przerysowanie w naszym przykładzie możemy również uzyskać, stosując zamiast me­ tody Recalc metodę Reąuery (listing 2.21). Ponieważ jednak dotyczy ona źródła danych, musimy dodatkowo (odmiennie niż w przypadku Recalc) zasymulować jakieś działa­ nie na rekordach źródła. W naszym przypadku wybrana została operacja nawigacji po rekordach z parametrem acLast, powodująca przejście do ostatniego rekordu w źródło­ wym zestawie rekordów. Oczywiście można zastosować również inne, obojętne wzglę­ dem wartości danych metody. W ostatnim, najbardziej rozbudowanym przykładzie (listing 2.22) przedstawiono dwie kolejne flagi systemowe. Pierwsza z nich, Hourglass, powoduje, że kursor myszki jest rysowany w postaci klepsydry. Flaga ta jest użyteczna właśnie w czasie wykonywania

82

Bazy danych. Pierwsze sta rcie

Rysunek 2 .9 2 . Skutek programistycznego wymuszenia odświeżania fornmlaiza po jego otwarciu z poziomu kodu

Listing 2.2 1 . Definicja procedur}’ obsługi zdarzenia dla przycisku z odświeżaniem Pr1vate Sub PolecenieO_Click() On Error Resume Next stDocName = "Osoby" DoCmd.OpenForm stDocName DoCmd.GoToRecord . . acLast Me.Requery For i = 1 To 500000 a = S in (i / 10000) Next i DoCmd.Close End Sub

złożonych, długo trwających obliczeń do zasygnalizowania operatorowi stanu zajętości aplikacji. Tak jak w przypadku flagi komunikatów (ostrzeżeń) SetWarnings wska­ zane jest przywrócenie stanu domyślnego po zakończeniu obliczeń. Jeśli zapomnimy wykonać tę operacje, kursor będzie miał kształt klepsydry aż do zamknięcia bieżą­ cego formularza. Pomimo że jest on w dalszym ciągu aktywny, mniej doświadczony operator może przypuszczać, że aplikacja jest w dalszym ciągu zajęta (np. obliczenia „zapętliły się’', czy też aplikacja „zawiesiła się”), co może go skłaniać do wymuszania zakończenia przetwarzania z poziomu systemu (zamknięcie aplikacji). Listing 2.22. Definicja procedury’ obsługi zdarzenia dla przycisku z odświeżaniem — klepsydra i przerysowanie Pnvate Sub Poleceme0_Clicl:() On Error Resume Next stDocName = "Osoby” DoCmd.Hourglass True DoCmd.Echo False DoCmd.OpenForm stDocName For i = 1 To 500000 a = S in (i / 10000) Next i DoCmd.Close DoCmd.Echo True DoCmd.Hourglass False End Sub

Rozdział 2. ❖ Projektow anie bazy danych — narzędzia wizualne

83

Ostatnia, ale bardzo ważna jest flaga Echo odpowiadająca za aktywację lub dezaktywację procesu przerysowania w obrębie MS Access. W naszym przykładzie zamiast wymu­ szać przerysowanie, możemy w ogóle zrezygnować z odświeżania na czas wykonywa­ nia obliczeń w obrębie otwieranego, a chwilę później zamykanego formularza. Uzy­ skujemy to dzięki ustawieniu dla flagi Echo wartości FALSE. Tak samo jak poprzednio po zamknięciu formularza przywracamy fladze stan domyślny, aby możliwe były kolejne operacje przerysowania. Jeśli zapomnimy o przywróceniu stanu domyślnego tej flagi, to konsekwencje tego faktu mogą być dość poważne. Mianowicie, przerysowywanie jest zatrzymane” przed otwarciem formularza. Powoduje to „zamrożenie” stanu ekranu, czyli po zamknięciu formularza zawartość ekranu nie jest zawartością bieżącą, a tylko stanem historycznym, „duchem” — pomimo tego, że wygląda on tak, jak powinien wy­ glądać po przerysowaniu. Powoduje to, że niedostępne są żadne kontrolki na fonnularzu. Jedynym wyjściem z tej sytuacji jest zamknięcie aplikacji. Przy bardziej niesprzyjają­ cych okolicznościach (ustawienie modalności na poziomie systemu) może okazać się, że możliwe jest tylko zresetowanie komputera. Tale więc przy korzystaniu z tej flagi zalecana jest duża staranność przy programowaniu. Ostatnim elementem wartym omówienia jest metoda Cl ose. W przytoczonym kodzie wywołana ona została bez parametrów. W takim stanie powoduje ona zamknięcie bie­ żącego obiektu bazy — tego, który aktualnie ma fokus. Może to prowadzić do pro­ blemów, niejednoznacznego zachow'ania się, jeśli operatorowi uda się przenieść fokus do innego z obiektów. Możemy tego uniknąć, używając bardziej rozbudowanego wywolanią jawnie wskazującego na zamykany obiekt (listing 2.23). Listing 2 .23. Pełna definicja metody Close DoCmd.Close typ_objektu. nazwa_objektu. tryb_zapisu

Typ obiektu wskazuje, czy zamykamy formularz, raport etc. Natomiast tryb zapisu wska­ zuje na sposób zachowanią jeśli przed zamknięciem pojawiły się w obiekcie zmiany (tabela 2.20) Tabela 2 .2 0 . Definicja wartości dla parametru tiyb zapisu metody Close Nazwa param etru

Opis

acSaveNo

Zmiany nie są zapisywane.

acSavePrompt

Pytanie o zapisywanie lub niezapisywanic zmian (wartość domyślna). W przypadku zamykania modułu jest równoważna acSaveNo.

acSaveYes

Zmiany są zapisywane.

84

Bazy danych. Pierwsze starcie

Rozdział 3.

Strukturalny J ęiy E k l a p y S a n

3

(§)[L

w wersji MS Jet SQL [Informacje pocHsftawow© Dla baz danych o strukturze relacyjnej podstawowym narzędziem dostępu do danych i manipulowania nimi jest strukturalny język zapytań SQL. Na iynku nie istnieje liczące się środowisko zarządzania bazą danych, w którym nie stosowano by tego narzędzia. Tworzenie kodu SQL stanowi najbardziej podstawowy, niejednocześnie najwszechstron­ niejszy sposób programowania w środowiskach bazodanowych. Pomimo znacznie po­ suniętej standaryzacji nie istnieje w praktyce pełna zgodność między,.językami SQL” stosowanymi przez różnych twórców oprogramowania. Nawet produkty tej samej firmy mogą stosować różne warianty SQL. Na szczęście różnice między poszczególnymi „klonami’'języka są niewielkie, tak że dogłębne poznanie jednego z nich pozwala na sprawne posługiwanie się tym językiem w innych środowiskach. W książce skupiono się na MS Jet SQL będącym językiem stosowanym w systemie zarządzania bazą danych Access, jako najbardziej podstawowym zakresie tego języka. Inne klony zostaną przed­ stawione w pracy dotyczącej rozszerzeń proceduralnych SQL. W wielu publikacjach stosowany jest podział na trzy części: instrukcje wybierające (SELECT), język manipulowania danymi (DML — Data Manipulation Language) oraz język definicji baz danych (DDL — Database Definition Language). Podział ten jest sztuczny, dodatkowo sugeruje, że mamy do czynienia z różnymi językami programo­ wania, co jest ewidentnym mijaniem się z prawdą. W związku z tym taki podział nie będzie stosowany w niniejszej książce. W języku SQL nie jest rozróżniana wielkość liter (w niektórych środowiskach nie doty­ cz)' to łańcuchów będących argumentem funkcji), stąd zapis wielkimi lub małymi lite­ rami czy też dowolną ich kombinacją jest równoważny, np.:

Bazy danych. Pierwsze starcie

86

select nazwisko from osoby SELECT NAZWISKO FROM OSOBY

są równoważne

Select Nazwisko From Osoby W celu poprawienia czytelności poleceń w całej książce wprowadzono specjalną no­ tację. Polecenia SQL, nazwy operatorów i funkcji będą pisane wielkimi literami, nato­ miast nazwy tabel i pól małymi (pierwsza wielka) literami. Polecenia SQL mogą być pisane w wielu liniach. Jedynym ograniczeniem jest to, aby po­ dział na linie nie następował w obrębie słów kluczowych, poleceń, operatorów, nazw pól itp.: SELECT SELECT Nazwisko FROM Osoby = ^

1Sko

Osoby Standardowo znacznikiem końca polecenia w SQL jest znak średnika (;) jednak w więk­ szości środowisk, w tym również w MS Jet SQL, może on być pominięty. Dlatego nie będzie on używany w tej książce. Czytelnik powinien jednak pamiętać o jego roli, gdyż w przypadku rozwinięć proceduralnych często pominięcie średnika nie jest do­ puszczalne (trudno zinterpretować sens poleceń). Możliwe jest pokazanie składni języka na przykładzie ogólnych postaci poleceń, czy też ich grafów. Jednakże autor uważa, że o wiele bardziej dydaktyczne jest operowanie przykładami, przy wprowadzaniu najpierw najprostszych postaci poleceń i stopniowym dochodzeniu do postaci bardziej rozbudowanych. Rozpocznijmy od stanu, gdy mamy już zdefiniowane tabele oraz wpisane do nich przy­ kładowe dane, a naszym zadaniem jest wybranie tylko pewnych interesujących nas danych. Innymi słowy zaczynamy od poznania najpotężniejszego polecenia SQL, jakim jest SELECT.

Sapyuamóa wytoiieirajjąj©® = SILE©? Składnia podstawowa W celu wybrania wszystkich pól i wszystkich rekordów z tabeli o nazwie Osoby mo­ żemy wykonać następujące zapytanie: SELECT * FROM Osoby

gdzie symbol gwiazdki jest znakiem specjalnym i zastępuje nazwy wszystkich pól. Formalnie znakiem oznaczającym koniec zapytania jest symbol ; (średnik), ale więk­ szość parserów pozwala na jego pominięcie, stąd w książce nie będzie on stosowany. Jednak w niektórych systemach zarządzania bazami danych może on być niezbędny, o czym czytelnicy powinni pamiętać.

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS J e t SQL

87

Jeżeli chcemy ograniczyć się do wybrania tylko niektórych pól z tabeli, musimy w spo­ sób jawny podać ich nazwy, np.: SELECT Nazwisko. Imię. RokUrodz FROM Osoby

W tym przypadku wyświetlona będzie zawartość trzech pól ze wszystkich rekordów tabeli Osoby. W części głównej zapytania wybierającego dozwolone jest stosowanie wyrażeń. Mo­ żemy na przykład wyświetlić zawartość dwóch pól: Imię i Nazwisko, w postaci jednego połączonego pola: SELECT Nazwisko & ' ' & Imię FROM Osoby

Należy zwrócić uwagę, że operatorem konkatenacji (łączenia) łańcuchów (zmiennych znakowych) jest znak ampersand (c£). Operator ten jest charakterystyczny dla MS Jet SQL. W innych systemach jest on zastępowany przez plus (+) lub podwójny znak morę (||). Łańcuch zawierający spację jest dołączony, aby rozdzielić zawartość pól. Przy tak skonstruowanym zapytaniu nazwa pola obliczeniowego jest nadawana przez system zarządzania bazą danych i charakterystyczna dla tego systemu. Jeśli w sposób jawny chcemy nazwać pole obliczeniowe lub zmienić nazwę pola wyświetlaną przy wykonaniu zapytania, stosujemy tzw. alias nazwy, na przykład poprzednie zapytanie możemy przepisać do postaci: SELECT Nazwisko & ' ‘ & Imię AS Osoba FROM Osoby

Tak samo wyrażenia te mogą dotyczyć pól numerycznych oraz w części głównej za­ pytania może występować ich wiele. SELECT Brutto. 0.8*Brutto AS Dochod. 0.2*Brutto AS Podatek FROM Zarobki

Dostępne są podstawowe operatory algebraiczne i logiczne (tabela 3.1) Tabela 3 .1 . Podstawowe operatory dostępne w MS Jet SOL Arytm etyczne

Logiczne i bitow e

Znakow e

+ dodawanie - odejmowanie * mnożenie / dzielenie \ dzielenie całkowito!iczbowe mod modulo

AND iloczyn bitowy

&konkatenacja łańcuchów

OR suma

bitowa NOT przeczenie bitowe

Oprócz przedstawionych powyżej operatorów dostępnych jest szereg funkcji operujących na każdym z dostępnych typów danych, charakterystycznych dla danego środowiska. Ponieważ ich liczba jest znaczna, nie jest sensowne omawianie ich w tym miejscu. Nazwy aliasów pól muszą być w obrębie pojedynczego zapytania różne od siebie i nie mogą być nazwami pól tabeli, a także nie mogą być słowami zastrzeżonymi języka SQL (nazwy poleceń, klauzul etc.). Aliasy mogą być również stosowane do określenia zmie­ nionej nazwy nie tylko pola, ale również tabeli.

Bazy danych. Pierwsze sta rcie

88

SELECT Nazwisko AS Nazwa FROM Osoby AS 0

Z reguły do określenia pola wystarcza podanie jego nazwy w tabeli, jednakże czasami konieczne jest stosowanie tzw. nazwy kwalifikowanej, składającej się z nazwy tabeli lub jej aliasu oraz nazwy pola, tak jak to pokazują dwa równoważne przykłady: SELECT Osoby.Nazwisko AS Nazwa FROM Osoby SELECT 0 .Nazwisko AS Nazwa FROM Osoby AS 0

Przy czym jeśli przy nazwie tabeli występuje alias, to w nazwie kwalifikowanej musi się pojawić ten alias, a nie właściwa nazwa tabeli. Przy tworzeniu aliasów nazw tabel dopuszczalne jest pominięcie słowa kluczowego AS. SELECT 0 .Nazwisko AS Nazwa FROM Osoby 0

Sortowanie w zapytaniach Do lej pory rekordy wyprowadzane były w kolejności występującej w tabeli, w kolej­ ności wpisywania (dokładniej rzecz ujmując, w kolejności narzuconej przez indeks grupujący — o czym później). Można jednak narzucić kolejność wyprowadzania re­ kordów w' definicji zapytania. Za sortow'anie rekordów odpowiada klauzula ORDER BY. SELECT Nazwisko. Imię FROM Osoby ORDER BY Nazwisko

W tym przypadku rekordy zostaną posortowane według nazwiska, a domyślnym spo­ sobem sortowania jest sortowanie rosnące. W jawny sposób rosnący kierunek sortowa­ nia możemy wskazać przez użycie operatora ASC (ascending — rosnąco) w klauzuli ORDER BY. SELECT Nazwisko. Imię FROM Osoby 0R0ER BY Nazwisko ASC

Jeśli chcemy wymusić sortowanie w kierunku malejącym, możemy użyć operatora DESC {descending — malejąco). SELECT Nazwisko. Imię FROM Osoby ORDER BY Nazwisko DESC

Sortowanie może być hierarchiczne, czyli np. w obrębie grupy takich samych nazwisk możemy zastosować sortowanie względem imienia. Przy czym kierunek sortowania (rosnący lub malejący) jest niezależny dla każdego z poziomów sortowania. SELECT Nazwisko. Imię FROM Osoby ORDER BY Nazwisko DESC. Imię ASC

Sortowanie zaw;sze jest rozpoczynane od pierwszego pola występującego po klauzuli ORDER BY. Nie istnieje ograniczenie liczby poziomów sortowania. Wskaźnikiem sorto­ wania może być nie tylko pojedyncze pole, ale także dowolne wyrażenie oparte o pola tej tabeli. SELECT RokUrodz*Wzrost AS Iloczyn FROM Osoby ORDER BY Rokllrodz*Wzrost

W składni standardu SQL możliwe jest sortowanie w oparciu o alias pola, metoda ta nie jest jeszcze zaimplementowana w MS Jet SQL.

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

89

Dodatkowo należy pamiętać, iż pola użyte do sortowania nie muszą być wyświetlane (nie muszą występować w części głównej zapytania wybierającego) oraz że klauzula sortująca (ORDER BY) jest zawsze ostatnią z klauzul występujących w zapytaniu, co zo­ stanie pokazane w dalszej części książki.

Filtrowanie w zapytaniach W poprzednich przykładach zawsze wyświetlane były informacje obejmujące wszystkie rekordy tabeli. W celu wybrania (odfiltrowania) interesującej nas informacji możemy użyć klauzuli WHERE. SELECT Nazwisko. Imię FROM Osoby WHERE RokUrodz >1970

Przy czym po klauzuli WHERE wpisywane jest wyrażenie logiczne. Zapytanie wyświetli te rekordy, dla których wartość wyrażenia jest prawdziwa (TRUE). Powyższy przykład pokazuje wyświetlenie tych osób, które urodziły się po 1970 roku. W wyrażeniu zo­ stał użyty operator algebraiczny większości. Poza tym w wyrażeniach mogą być uży­ wane operatory logiczne oraz specjalne, tak jak to pokazuje tabela 3.2. Tabela 3 .2 . Operatory dostępne w MS Jet SOL Operatory algebraiczne

Operatory logiczne

Operatory specjalne

= równe

NOT przeczenie

BETWEEN przedział

< mniejsze niż

0R suma logiczna

IN lista

<° mniejsze lub równe

AND iloczyn logiczny

LIKE podobieństwo

> większe niż

S0ME lista z operatorem

>= większe lub równe

ANY lista z operatorem

o różne

ALL lista z operatorem

! = nierówne

EXISTS istnieje

W najprostszym przypadku możemy mieć połączenie operatorem logicznym dwóch wyrażeń algebraicznych, np.: wyświetlenie danych osób urodzonych po roku 1960, a przed rokiem 1970. SELECT Nazwisko. Imię FROM Osoby WHERE RokUrodz>1960 AND RokUrodz<1970

lub osób urodzonych przed rokiem 1960 oraz po roku 1970: SELECT Nazwisko. Imię FROM Osoby WHERE RokUrodz<1960 0R RokUrodz>1970

Przy tworzeniu bardziej skomplikowanych wyrażeń filtrujących należy pamiętać, że wyrażenia przetwarzane są zawsze od strony lewej do strony prawej, chyba że zade­ cydujemy inaczej, grupując odpowiednie elementy nawiasami. _WHERE RokUrodz>1950 AND RokUrodz<1960 0R Wzrost>180 _WHERE RokUrodz>1950 AND (Rokllrodz<1960 0R Wzrost>180)

90

Bazy danych. Pierwsze sta rcie

W podanych wyżej przykładach wyrażenia filtrujące nie są tożsame, gdyż w pierwszym zapytaniu zostanie wyprowadzona osoba urodzona przed 1950 rokiem, o ile tylko jest wyż­ sza niż 180 cm, natomiast w drugim zapytaniu taka osoba nie zostanie wyprowadzona W poprzednich przykładach zakładano, że zawsze wszystkie pola tabeli są wypełnione. Jednak może się zdarzyć, że posiadamy informacje niekompletną albo że informacja zawarta w którymś polu nie dotyczy tego rekordu czy też nie może być dla niego uzy­ skana. W takim przypadku zawartość pola pozostaje „pusta” — ściśle mówiąc, ma wartość NULL (nieznaną, niezidentyfikowaną). W ten sposób wchodzimy w zakres lo­ giki trójwartościowej, gdzie dwa dotychczasowe stany są uzupełnione o wartość NULL. Stąd musimy wprowadzić nowe definicje operatorów logicznych obowiązujących w tej logice, przedstawione w postaci tabelarycznej (tabele 3.3 - 3.5). Tabela 3.3. Wartości operatora AND w logice trójwartościowej AND

TRUE

FALSE

NULL

TRUE

TRUE

FALSE

NULL

FALSE

FALSE

FALSE

FALSE

NULL

NULL

FALSE

NULL

Tabela 3.4. Wartości operatora OR w logice trójwartościowej 0R

TRUE

FALSE

NULL

TRUE

TRUE

TRUE

TRUE

FALSE

TRUE

FALSE

NULL

NULL

TRUE

NULL

NULL

Tabela 3 .5 . Wartości operatora N O T n’ logice trójwartościowej A

NOT A

TRUE

FALSE

FALSE

TRUE

NULL

NULL

Jednym z najważniejszych wniosków płynących z tych tabel jest to, że ponieważ: NULL AND NULL = NULL

to (NULL=NULL) => NULL

stąd aby wykryć wartości niezdefiniowane (nieznane) występujące w jakimś polu, należy użyć specjalnego operatora IS NULL: SELECT Nazwisko. Imię FROM Osoby WHERE RokUrodz IS NULL

Bardziej szczegółowego omówienia wymagają operatory specjalne. Pierwszym z nich jest operator przedziału BETWEEN. Ilustracją niech będzie zapytanie:

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

91

SELECT Nazwisko. Imię FROM Osoby WHERE RokUrodz BETWEEN 1960 AND 1980

które zwraca rekordy z przedziału obustronnie domkniętego, ograniczonego dwoma podanymi parametrami (dalami). Tak więc zapytanie to jest równoważne zapytaniu: SELECT Nazwisko. Imię FROM Osoby WHERE RokUrodz >=1960 AND RokUrodz >=1980

w którym obie nierówności ograniczające przedział są nieostre. Kolejnym przykładem operatora specjalnego jest operator IN pozwalający na dokona­ nie wyboru tych elementów, które zawiera lista. Na przykład możemy wyprowadzić dane dotyczące osób urodzonych w konkretnych (wymienionych latach): SELECT Nazwisko. Imię FROM Osoby WHERE RokUrodz IN (1960. 1970. 1980)

Jest ono równoważne wielokrotnemu porównaniu z wartościami, jak pokazano niżej: SELECT Nazwisko. Imię FROM Osoby WHERE (RokUrodz = 1960 0R RokUrodz = 1970 OR RokUrodz = 1980)

Przewaga operatora IN jest widoczna w przypadku długich (o wielu elementach) list lub. co zostanie podane dalej, list dynamicznych — o bliżej nieokreślonej liczbie elementów. Operator listy IN może być wykorzystywany z dowolnym typem danych, np. dla zmien­ nych znakowych możemy zapisać zapytanie: SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko IN ( 'Kowalski'. 'Nowak'):

które jest równoważne zapytaniu: SELECT Nazwisko. Imię FROM Osoby WHERE (Nazwisko = 'Kowalski' OR Nazwisko= 'Nowak')

W wersji statycznej jednak operator listy najczęściej jest wykorzystywany z danymi numerycznymi, natomiast do danych znakowych używany jest najczęściej operator po­ dobieństwa LIKE. W podstawowej postaci np.: SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE 'K0W'

jest on równoważny operatorowi równości: SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko = 'KOW'

Czyli wyprowadzone będą dane osób o nazwisku KOW. Zwrócić uwagę należy na to. iż w zależności od systemu rozróżniana jest lub nie wielkość liter. W przypadku MS Jet SQL wielkość liter nie odgrywa roli, w związku z tym łańcuchy znaków (KOW, kow, Kow) są równoważne. Silę operatora podobieństwa można ocenić dopiero, jeżeli zastosujemy znaki specjalne, dla MS Jet SQL są to znaki opisane w tabeli 3.6.

Bazy danych. Pierwsze sta rcie

92

Tabela 3 .6 . Znaki specjalne dla operatora podobieństwa LIKE * dowolny ciąg znaków (w tym ciąg pusty) ? dokładnie jeden znak

Zapylanie wyświetlające dane dla osób, których nazwiska rozpoczynają się od frazy KOIV: SELECT Nazwisko. Inne FROM Osoby WHERE Nazwisko LIKE 'KOW*'

Wybrane zostaną dane np. dla nazwisk: Kowalski, Kowalczyk, Kowal etc., ale również dla nazwiska Kow. Zapytanie wyświetlające dane dla osób, których nazwiska kończą się frazą KOW: SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE '*K0W

Wybrane zostaną dane np. dla nazwisk: Jaków, Bułhakow etc., ale również dla nazwi­ ska Kow. Zapytanie wyświetlające dane dla osób, których nazwiska posiadają w środku frazę KOW: SELECT *Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE ’ *K0W*’

Wybrane zostaną dane np. dla nazwisk: Jankowski, Ziółkowski, Kwiatkowski etc., ale również dla nazwisk rozpoczynających się frazą KOW: Kowalski, Kowalczyk, Kowal etc., oraz nazwisk kończących się frazą KOW: Jaków, Bułhakow etc., a także dla na­ zwiska Kow. Zapytanie wyświetlające dane dla osób, których nazwiska rozpoczynają się od litery K, a kończą literą/: SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE 'K*I'

Wybrane zostaną dane np. dla nazwisk: Kowalski, Kwiatkowski, Kamieński etc., ale również dla nazwiska Ki — o ile oczywiście takie istnieje. Zapytanie wyświetlające dane dla osób, w których nazwisku na trzeciej pozycji wystę­ puje litera W: SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE '??W*'

Wyświetlone zostaną dane np. dla nazwisk: Kowal, Nowak, Pawlak etc., ale również dla nazwisk: Kow, Now etc. Gdyby we wzorcu nie została użyta kończąca frazę gwiazdka, wybrane zostałyby dane tylko dla nazwisk drugiego typu — składających się dokładnie z trzech znaków. Zapytanie wyświetlające dane dla osób, w których nazwisku pierwsza litera zawiera się w przedziale od k do

Rozdział 3. ❖ Strukturalny język zapytań SQL w wersji MS Je t SQL

93

SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE '[k-n]*'

Wyświetlone zostaną dane np. dla nazwisk: Kowalski, Lwów, Makowski, Nowak etc.; należy zauważyć, że przedział jest przedziałem obustronnie domkniętym. Zapytanie wyświetlające dane dla osób, w których nazwisku pierwsza litera nie za­ wiera się w przedziale od k do n: SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE *[!k-n]*’

Wypisane zostaną dane dla nazwisk, których pierwsza litera poprzedza k, np.: Adamczyk, Ciesielski, Janik, oraz nazwisk, których pierwsza litera występuje za n, np.: Olszewski. Pawlak, Zięba etc. Zapytanie wyświetlające dane dla osób, w których nazwisku pierwsza litera jest jedną z listy znaków: k, z, a, n: SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE ’ [kzan]*'

Wyświetlone zostaną dane np. dla nazwisk: Kowal, Zięba. Adamczyk, Nowak etc. Należy zauważyć, że w liście ujętej w nawias kwadratowy nie występuje żaden znak separatora W przypadku zastosowania jakiegokolwiek separatora np. (, spacja;) zostanie on potraktowany jak kolejny znak listy — dosłownie. SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE ’ [k.z a:n]*'

Zostałyby wyświetlone nazwiska rozpoczynające się od tych znaków. Oczywiście w praktyce, poza błędami przy wpisywaniu, trudno się spodziewać nazwisk rozpoczy­ nających się od znaków niebędących literami, ale dla pól zawierających inne dane, np.: kody, symbole, jest to już bardziej prawdopodobne. Poniżej pokazano zapytanie wyświetlające dane dla osób, których nazwiska zaczynają się od cyfry. SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE , [0-9]*'

W przypadku MS Jet SQL przedział obejmujący cyfry można zastąpić znakiem hash (U), czyli następne zapytanie jest równoważne poprzedniemu. SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE ’#*'

Ponieważ symbole ujęte w nawias kwadratowy są traktowane dosłownie, to poniższe zapytanie wyświetli dane dla osób, w których nazwisku na dowolnej pozycji występuje znak *: SELECT Nazwisko, Imię FROM Osoby WHERE Nazwisko LIKE ’ *[*]*’

94

Bazy danych. Pierwsze starcie

Można postawić pytanie, jak wyświetlić dane osób, których nazwisko zaczyna się od jednego ze znaków k - n. Zastosowanie wzorca ’[k-n]*’ zwraca przedział od k do ale wystarczy zamienić kolejność znaków, aby otrzymać poszukiwane rozwiązanie. SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko LIKE ’ [-kn]*'

Przedstawione tutaj przykłady wzorców mogą być oczywiście w dowolny sposób łączone, dając bardzo złożone sposoby filtrowania; świadczy to dobitnie o sile ope­ ratora LIKE. Pozostałe operatory specjalne (ALL, SOME, ANY, EXISTS) zostaną omówione w części po­ święconej podzapytaniom.

Grupowanie i funkcje agregujące Obliczenia wykonywane do tej pory dotyczyły pojedynczego wyprowadzanego rekordu. Możemy dokonywać operacji algebraicznych dotyczących wszystkich rekordów lub też ustalonych ich grup. Na przykład wyznaczmy sumę wszystkich zarobków (dla całej tabeli — wszystkich osób): SELECT SUM(Brutto) AS Razem FROM Zarobki

Funkcję występującą w części głównej zapytania (w naszym przypadku SUM) będziemy nazywać funkcją agregującą lub agregatem. Wyznaczenie funkcji agregującej jest rów­ nież możliwe dla grupy (w naszym przypadku — dla każdej osoby): SELECT SUMCBrutto) AS Razem FROM Zarobki GROUP BY IdOsoby

W celu wyznaczenia grup, względem których wyznaczane są funkcje agregujące, sto­ sujemy klauzulę GROUP BY. W zaprezentowanym przykładzie pokazane sąjedynie sumy i nie wiadomo, komu je wypłacono, w związku z tym możemy w części głównej wymie­ nić pole grupujące — IdOsoby: SELECT IdOsoby. SUM(Brutto) AS Razem FROM Zarobki GROUP BY IdOsoby

Jak widać, w części głównej zapytania agregującego nie musi występować pole (pola) grupowania, ale jeżeli w części głównej pojawi się jakiekolwiek pole bez funkcji agregującej, to musi się ono pojawić w klauzuli GROUP BY. Tak jak przy każdym z pól tak i przy polu z funkcją agregującą może pojawić się alias nazwy. W części głównej zapytania może pojawić się wiele funkcji agregujących, dotyczyć mogą one wielu pól oraz możliwe jest wykonywanie na nich działań algebraicznych. SELECT IdOsoby. SUM(Brutto) AS Razem. AVG(Brutto) AS Średnio, COUNT(IdZarobku) AS Ile. MAX(Brutto)/AVG(Brutto) AS Wskaźnik FROM Zarobki GROUP BY IdOsoby

W MS Jet SQL dostępne są funkcje agregujące wymienione w tabeli 3.7.

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

95

Tabela 3 .7 . Funkcje agregujące dostępne w MS Jet SOL AVG wartość średnia

x

= — S\x,

5UH suma

ż x,

MAX maksimum MIN minimum FIRST pierwszy w grupie LAST ostatni w grupie

STDEV odchylenie standardowe

VAR wariancja

(» -I) COUNT zlicz

Zastanówmy się nad skutkiem działania następującego zapytania: SELECT C0UNT(*). COUNTtIdOsoby). COUNT(RokUrodz) FROM Osoby

Czy zawsze zwrócone zostaną trzy takie same liczby? Jeżeli przypomnimy sobie infor­ macje dotyczące wartości NULL, oczywistym się stanie, że nie. Przy czym różnica może dotyczyć trzeciego z wyprowadzanych pól. Pierwsza liczba zawsze pokaże liczbę wszyst­ kich rekordów (gwiazdka oznacza wszystkie pola — jeśli nie ma żadnego pola, nie ma rekordu), druga również zlicza wszystkie rekordy (IdOsoby jako klucz podstawowy okre­ śla rekord, ponadto z definicji nie może mieć wartości NULL). Inaczej rzecz się ma w przy­ padku zliczania pola niebędącego kluczem podstawowym. Jeżeli nie postanowiono inaczej, wprowadzając dodatkowe ograniczenia, może się w nim pojawić wartość NULL. Zliczane są tylko te rekordy, które są określone (RolcUrodz jest określony, nie ma wartości NULL). Rozważmy działanie: NULL 9 A = NULL

gdzie A to dowolna wartość, S jest dowolnym operatorem. Ta właściwość powoduje, że jeśli w którymkolwiek z rekordów pola, na którym wyzna­ czamy funkcję agregującą, byłaby NULL, funkcja ta byłaby także NULL. Aby tego uniknąć, do wyznaczania funkcji agregujących brane są tylko wartości określone (niebędące NULL). Reguła ta dotyczy wszystkich funkcji agregujących — również zliczania (COUNT) W podanych przykładach występował jedynie pojedynczy poziom grupowania istnieje możliwość grupowania na wielu poziomach, ale ponieważ wymaga to operacji na wię­ cej niż jednej tabeli, zostanie pokazane po wprowadzeniu złączeń.

96

Bazy danych. Pierwsze sta rcie

W przypadku zapytań agregujących możliwe jest również filtrowanie. W takim typie zapytania możliwe jest filtrowanie na dwóch poziomach. Pierwszy na poziomie rekor­ dów jest oparty o znaną nam już klauzulę WHERE. SELECT IdOsoby. SUM(Brutto) AS Razem FROM Zarobki WHERE Brutto >100 GROUP BY IdOsoby

Wykonanie takiego zapytania powoduje wyprowadzenie sum brutto składających się ze składników większych niż 100, przykładowe działanie ilustruje tabela 3.8. Tabela 3 .8 . Skutek wykonania zapytania agregującego z filtrowaniem na poziomie rekordu Kowalski

Nowak

Janik

100

100

300

100

200

200

100

100

100 RAZEM bez filtrowania

400

400

500

RAZEM z filtrowaniem

Niewyświetlane

200

500

Jeżeli chcemy zastosować filtrowanie względem funkcji agregujących, używamy klau­ zuli HAVING. Ponieważ dotyczy ona funkcji wyznaczanych przy zmianie grupy, musi zawsze występować po klauzuli GROUP BY, np.: SELECT IdOsoby. SUM(Brutto) AS Razem FROM Zarobki GROUP BY IdOsoby HAVING SUM(Brutto)>400

Wyświetlone będą te rekordy, których suma przekroczy 400, czyli te, które wskazano w tabeli 3.9. Tabela 3.9 . Skutek wykonania zapytania agregującego z filtrowaniem na poziomie grupy rekordów Kowalski

Nowak

100

100

300

100

200

200

100

100

Janik

100 RAZEM

400

400

500

Niewyświetlane

Niewyświetlane

W yświetlane

Należy zauważyć, że funkcja, względem której odbywa się filtrowanie w klauzuli HAVING, nie musi być tą samą funkcją, której rezultat jest wyświetlany (jest podana w części głównej zapytania). Oczywiście możliwe jest stosowanie obu rodzajów filtrowania (na poziomie rekordu oraz na poziomie grupy — funkcji agregującej) jednocześnie, w jednym zapytaniu: SELECT IdOsoby. SUM(Brutto) AS Razem FROM Zarobki WHERE Brutto >100 GROUP BY IdOsoby

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS J e t SQL

97

HAVING SUM(Brutto)>400 ORDER BY SUM(Brutto)

W takim przypadku przykładowe wyniki będą wyglądały tak, jak pokazano w tabeli 3.10. Tabela 3 .1 0 . Skutek wykonania zapytania agregującego z filtrowaniem na poziomie rekordu i grupy rekordów Kowalski

Nowak

100

100

Janik 300

100

200

200

100

100

100 RAZEM bez filtrowania RAZEM z filtrowaniem

400

400

500

NULL

200

500

Niewyświetlane

Niewyświetlane

W yświetlane

Należy zwrócić uwagę, że klauzula ORDER BYznajduje się na końcu, a sortowanie może się odbywać zarówno w oparciu o pole grupujące, jak i funkcję agregującą. Przy czym w przypadku funkcji agregującej nie musi być to ta sama funkcja, która występuje w części głównej, oni ta, która jest używana z klauzulą filtrującą HAVING.

Zapytania do wielu tabel — złączenia Dotychczas prezentowane zapytania wyświetlały dane z pojedynczej tabeli. Jednakże często interesują nas dane zgromadzone w kilku tabelach, taka organizacja danych jest przecież charakterystyczna dla modelu relacyjnego. W przypadku danych zgro­ madzonych w dwóch tabelach (Osoby i Zarobki) możemy wykonać zapytanie: SELECT Nazwisko. Brutto FROM Osoby. Zarobki

gdzie Nazwisko jest polem tabeli Osoby, natomiast Brutto polem tabeli Zarobki. Za­ pytanie takie jest poprawne składniowo, a skutkiem jego wykonania jest iloczyn kartezjański (krotka) na wartościach wybranych pól ze wszystkich rekordów obu tabel. Czyli wyświetlone zostaną dla każdego nazwiska wszystkie wartości brutto. W więk­ szości przypadków interesuje nas, aby dla danego Nazwiska zostały wyświetlone tylko wartości Brutto jego zarobków (wynagrodzeń). To zadanie realizowane jest poprzez złączenie tabel — najczęściej na polach zawierających takie same dane (pomiędzy kluczem głównym jednej a kluczem obcym drugiej tabeli). Pierwszą metodą realizacji złączenia jest zastosowanie znanej już klauzuli filtrującej WHERE. SELECT Nazwisko. Brutto FROM Osoby. Zarobki WHERE Osoby. IdOsoby=Zarobki. IdOsoby

Warunkiem złączenia jest najczęściej równość wartości pól. Ponieważ z reguły mają one taką samą nazwę w obu tabelach, w takim przypadku konieczne jest użycie nazwy kwalifikowanej pól. Natomiast warunkiem koniecznym realizacji złączenia jest tylko zgodność typów pól. Ponieważ w produktach Microsoft wszystkie zmienne są przeka­ zywane przez typ variant (dopasowujący się do typu danych), zgodność typu w tym

98

Bazy danych. Pierwsze sta rcie

przypadku można traktować szerzej jako możliwość automatycznej konwersji między typami danych. Pomimo tak elastycznego traktowania zgodności danych w produk­ tach Microsoft wskazane byłoby, aby łączone ze sobą pola były dokładnie tego samego typu. Pozwala to na wyeliminowanie ewentualnych konfliktów przy innych operacjach na danych. Według takiego samego schematu możemy złączyć dowolną ilość tabel. Na przykład chcąc uzyskać informację o nazwach działów, nazwiskach pracowników, którzy w nich pracują, oraz o ich zarobkach, możemy wykonać następujące zapytanie: SELECT Opis. Nazwisko. Brutto FROM Osoby. Zarobki. Działy WHERE Osoby. IdOsoby = Zarobki.IdOsoby AND Działy.IdD zialu = Osoby.IdDziału

Zwróćmy uwagę na to, iż kolejność wymieniania tabel, z których pochodzą dane, jest dowolną tak samo jak dowolna jest kolejność warunków złączenia między tabelami w' klauzuli WHERE. Wszystkie warunki są połączone operatorem iloczynu logicznego AND. Tak realizowane złączenie zostało zastąpione przez bardziej wydajny mechanizm sto­ sujący operator JOIN (w MS SQL występujący w pełnej postaci INNER JOIN). Zastoso­ wanie takiej formy złączenia powoduje, że informacja o osobach i ich zarobkach jest uzyskiwana dzięki wykonaniu zapytania: SELECT Nazwisko. Brutto FROM Zarobki INNER JOIN Osoby ON Osoby.IdOsoby^Zarobki.IdOsoby

Natomiast złączenie trzech tabel może być zrealizowane w następujący sposób: SELECT Opis. Nazwisko. Brutto FROM (Zarobki INNER JOIN Osoby ON Osoby.IdOsoby = Zarobki.IdOsoby) INNER JOIN Działy ON Działy.IdD zialu = Osoby.IdDzialu

W przypadku łączenia więcej niż jednej tabeli konieczne jest zachowanie porządku łączenią czyli możemy łączyć tabelę, począwszy od najbardziej ogólnej do najbardziej szczegółowej (Działy— Osoby— Zarobki), albo rozpoczynając od najbardziej „pod­ rzędnej” (Zarobki— Osoby— Działy). Żaden inny porządek łączenia nie jest dopusz­ czalny, o czym należy szczególnie pamiętać, łącząc większą liczbę tabel. W standardzie SQL stosowanie nawiasów w celu wyodrębnienia kolejno łączonych tabel składowych nie jest konieczne. Natomiast parser MS Jet SQL nie jest na tyle „silny”, aby popraw­ nie przetworzyć wielokrotne złączenie bez zaznaczonej nawiasami kolejności lączenią i generowany jest przez system zarządzania bazy błąd składni. W czterech poprzednich przykładach zarówno przy realizacji złączeń za pomocą klauzuli WHERE, jak i operatora INNER JOIN tabele były łączone za pomocą warunku równości odpowiadających sobie pól. Jest oczywiste, że przy realizacji złączenia klauzulą WHERE ze względów składnio­ wych możliwe jest stosowanie kryterium nierównościowego lub innego bardziej zło­ żonego wyrażenia bazującego na theta operatorach. Tak samo jest to składniowo po­ prawne w przypadku realizacji złączenia przy użyciu operatora JOIN. Jednak zmiana znaku = na np. <> w złączeniach tabel Osoby i Zarobki spowoduje wyprowadzenie dla każdego nazwiska wszystkich wartości Brutto za wyjątkiem tych, które zostały wypła­ cone tej osobie. Z punktu widzenia logiki stosowanie takiego zapytania nie ma sensu praktycznego. Przykłady zastosowania złączeń nierównościowych znajdzie czytelnik w dalszej części tego rozdziału.

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

99

Rozpatrzmy teraz przypadek, że w naszej firmie rozpoczął pracę nowy pracownik i jeszcze nie zdążył pobrać żadnej wypłaty. W takim przypadku w pokazywanym za­ pytaniu łączącym tabele Osoby i Zarobki nie istniałby rekord zawierający jego nazwi­ sko, gdyż brakuje rekordu po stronie tabeli Zarobki. Zastosowanie złączenia nierównościowego, jak pokazano wyżej, także nie prowadzi do wyświetlenia nazwiska nowego pracownika z właściwą dla niego kwotą (brak wartości, czyli NULL). Jedynym rozwią­ zaniem jest użycie operatora JOIN ze wskazaniem na „kierunek” złączenia — w naszym przypadku zastosujemy RIGHT JOIN: SELECT Nazwisko. Brutto FROM Zarobki RIGHT JOIN Osoby ON Osoby.IdOsoby=Zarobki.IdOsoby

Oznacza to, że z tabeli wymienionej po prawej stronie operatora RIGHT JOIN będą zawsze wybierane wszystkie rekordy (chyba że inaczej wskazano klauzulą WHERE), natomiast z tabeli występującej po lewej stronie tego operatora tylko te, które speł­ niają warunek złączenia (w naszym przypadku mające równą wartość pola IdOsoby). W ten sposób przy nazwisku nowo zatrudnionego pracownika w polu Brutto pojawi się wartość NULL. Podobną sytuację będziemy mieli, jeśli przy wypłacaniu wynagrodzenia nie wpisano do tabeli Zarobki wartości pola IdOsoby (oznacza to, że wyplata nie ma właściciela — „lewa kasa”) lub błędnie podano identyfikator osoby (spoza wartości pola IdOsoby występujących w tabeli Osoby). W tym przypadku możemy użyć operatora LEFT JOIN: SELECT Nazwisko. Brutto FROM Zarobki LEFT JOIN Osoby ON Osoby.IdOsoby=Zarobki.IdOsoby

W standardzie SQL’92 istnieje jeszcze złączenie FULL JOIN będące złożeniem LEFT i RIGHT JOIN, ale w MS Jet SQL ten typ złączenia nie jest obsługiwany. Rozważmy przypadek, gdzie w tabeli o nazwie ttt mamy dane osób ograniczone do li­ sty składającej się z pól Nazwisko, Imię i RolcUrodz. W tabeli tej nie zdefiniowano żadnego klucza. Możemy sobie wyobrazić, że tabela ta powstała na skutek importu z pliku tekstowego czy też skoroszytu Excela. Naszym zadaniem jest wybranie z tabeli Osoby tych nazwisk, które występują w tabeli ttt. Pierwszym rozwiązaniem jest zasto­ sowanie operatora listy IN z dynamicznym źródłem danych. Źródłem tym będzie za­ pytanie wybierające oparte na tabeli ttt. SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko IN (SELECT Nazwisko FROM t t t)

Zapytaniu taicie często jest nazywane podzapytaniem. Wymagania stawiane takiemu zapytaniu to zgodność typu wyprowadzanych danych z polem, które jest porównywane z listą (w produktach Microsoft możliwość automatycznej konwersji do typu pola), oraz, co najważniejsze, zapytanie to musi zawierać dokładnie jedno pole (zwracany jest wektor — tabela jednokolumnowa). Załóżmy teraz, że chcemy badać jednoczesną zgodność imienia i nazwiska. Pierwszym pomysłem na drodze do rozwiązania tego problemu wydaje się być rozszerzenie po­ przedniego zapytania o sprawdzenie zgodności z listą imion.

100

Bazy danych. Pierwsze starcie SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko IN (SELECT Nazwisko FROM t t t ) AND Inne IN (SELECT Imię FROM t t t )

Niestety takie rozumowanie jest biedne! Jak to pokazano na rysunku 3.1, zgodnie z na­ szymi warunkami zarówno nazwisko, jak i imię znajdują się na liście. Jednak ponieważ iloczyn dotyczy dwóch list, a nie konkretnych rekordów, stąd, pomimo że Kowalskiego Jana nie ma na liście w tabeli ttt, zostanie on wyświetlony na skutek wykonania po­ wyższego zapytania. Wystarczy, aby w dowolnych rekordach pojawiło się jego imię i nazwisko. Takie rozwiązanie jest błędne. Podkreślam to, ponieważ w znanych pu­ blikacjach wskazuje się na nie jako poprawne. Oczywiście istnieje możliwość sformu­ łowania poprawnego zapytania SQL, które wykona poprawnie postawione przez nas zadanie w oparciu o operator listy. SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko & Imię IN (SELECT Nazwisko & Imię FROM t t t )

Rysunek 3.1. Ilustracja błędnego utycia odwołania do dwóch list

^

Kowalski

Jan

ttt

Kowalski

Karol

Nowak

Jan

Wykorzystano tutaj zarówno w warunku, jak i w zapytaniu będącym źródłem dla operato­ ra listy konkatenację (połączenie) łańcuchów imienia i nazwiska. W praktyce, zwłaszcza przy znacznej objętości przeszukiwanych list, taka realizacja może być bardzo mało wydajna. Dużo lepszym rozwiązaniem wydaje się być zastosowanie złączenia. Dla przypadku sprawdzenia zgodności pojedynczego pola zapytanie będzie wyglądało następująco: SELECT Osoby .Nazwisko. Osoby.Imię. Osoby.RokUrodź. ttt.Nazwisko, ttt.Im ię . ttt.RokUrodz FROM Osoby INNER JOIN t t t ON Osoby.Nazwisko = ttt.Nazwisko

Konieczne jest w tym przypadku użycie kwalifikowanych nazw pól, gdyż ich nazwy w obu tabelach są takie same. Pola z tabeli ttt wyprowadzono tylko, aby można było sprawdzić poprawność wykonanego zapytania. Oczywiście pola linie i RokUrodz w ta­ belach Osoby i ttt mogą dla tego przypadku różnić się, zgodność dotyczy tylko zgodno­ ści wartości pól Nazwisko. Zapytanie to może być zilustrowane diagramem przedstawio­ nym na rysunku 3.2. Rysunek 3.2. Ilustracja złączenia

irrHMJ IdOsoby tdDdalu Nazwisko Imia RokUrodz Wzrost

WM

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS J e t SQL

101

Możemy oczywiście, używając operatora JOIN, dokonać połączenia na większej licz­ bie pól. Wykorzystajmy wszystkie dostępne pola z tabeli ttt. SELECT Osoby.Nazwisko. Osoby.Imię. Osoby.RokUrodz. ttt.Nazwisko, ttt.Im ię . ttt.RokUrodz FROM Osoby INNER JOIN t t t ON Osoby.Nazwisko = ttt.Nazwisko AND Osoby.Imię = ttt.Im ię AND Osoby.RokUrodz = ttt.RokUrodz

Mamy tutaj do czynienia z wielokrotnym złączeniem na polach niekluczowych (rysu­ nek 3.3). Odpowiada to w algebrze wyznaczeniu części wspólnej (przecięcia) obu zbiorów danych (Osoby n ttt). Bardzo często autorzy sugerują, jakoby nie było możliwe, a przy­ najmniej nie miało zastosowania praktycznego, tego typu rozwiązanie. Przytoczony tutaj przykład wskazuje zarówno na poprawność składniową jak i możliwość praktycz­ nego zastosowania tego typu zliczeń. Rysunek 3.3.

Ilustracja złączenia wielokrotnego na polach, z których żadne niejest elementem klucza

Spróbujmy teraz rozwiązać zadanie polegające na wybraniu z tabeli Osoby tych osób, których nie ma w tabeli ttt. Przy czym porównywane są tak jak poprzednio wszystkie pola z tabeli ttt z ich odpowiednikami w tabeli Osoby — co odpowiada wyznaczeniu różnicy (Osoby — ttt) Zastosowanie złączenia nierównościowego nie prowadzi do uzy­ skania poprawnego rozwiązania. Możemy natomiast zastosować „kierunkowość” ope­ ratora JOIN. Pamiętajmy, że dla złączenia typu LEFT JOIN z tabeli występującej po lewej stronie operatora wybierane są wszystkie rekordy, natomiast ze stojącej po jego prawej stronie te, które spełniają warunek. Jeśli w tabeli po prawej stronie nie ma odpowiadają­ cych rekordów, w ich miejscu pojawia się wartość NULL. Zastosujmy te informacje, ograniczając się tylko do wyświetlenia tych rekordów. SELECT Osoby.Nazwisko. Osoby.Imię. Osoby.RokUrodź. t t t .Nazw-i -sko. t t t .-Imię:—tt-t--. RokUrodz FROM Osoby LEFT JOIN t t t ON Osoby.Nazwisko = ttt.Nazwisko AND Osoby.Imię = ttt.Im ię AND Osoby.RokUrodz = ttt.RokUrodz WHERE ttt.Nazwisko IS NULL AND ttt.Im ię IS NULL AND ttt.RokUrodz IS NULL

Przekreślono pola z tabeli ttt, gdyż zawierają nieistotne wartości NULL. Również warunek filtrujący należy uznać za nadmiarowy. Jeśli tylko mamy pewność, że dane w tabelach Osoby i ttt są pełne (wszystkie pola wypełnione), to wystarczające jest sprawdzenie jednego dowolnego warunku występującego w klauzuli WHERE. Diagram ilustrujący po­ wyższe złączenie jest przedstawiony na rysunku 3.4.

Bazy danych. Pierwsze starcie

102

Rysunek 3.4. Ilustracja złączenia „ lewego ", wielokrotnego

W prosty sposób możemy przekształcić to zapytanie do takiego, które wyświetla dane z tabeli lit niemające odpowiedników w tabeli Osoby (tu — Osoby). Wystarczy zmienić tylko „kierunek” złączenia i sprawdzać warunek IS NULL po stronie tabeli Osoby. SELECT Osoby.Nazwisko. Osoby.Imię. Osoby.RokUrodz. ttt.Nazwisko. ttt.Im ie . ttt.RokUrodz FROM Osoby RIGHT JOIN t t t ON Osoby.Nazwisko = ttt.Nazwisko AND Osoby.Imię ° ttt.Im ie AND Osoby.RokUrodz = ttt.RokUrodz WHERE Osoby.Nazwisko IS NULL AND Osoby.Imię IS NULL AND Osoby.RokUrodz IS NULL

Tak jak poprzednio przekreślono pola niosące nieistotną informację oraz zastosowano nadmiarowy warunek w klauzuli WHERE. Schemat tego złączenia przedstawiono na ry­ sunku 3.5. Rysunek 3.5. Ilustracja złączenia „prawego", wielokrotnego

Zapytanie z podzapytaniem Rozważmy zadanie, w którym mamy wyświetlić te z wypłat, które są większe od war­ tości średniej wszystkich zarobków. Wartość średnią wszystkich wypłat wyświetla za­ pytanie: SELECT AVG(Brutto) FROM Zarobki

Zapytanie takie zwraca jedną wartość (skalar), w związku z tym nazywamy je zapyta­ niem skalarnym. Zapytanie skalarne może być użyte bezpośrednio w wyrażeniu klau­ zuli WHERE, stąd rozwiązaniem naszego zadania będzie zapytanie: SELECT Idosoby. Brutto FROM Zarobki WHERE Brutto > (SELECT AVG(Brutto) FROM Zarobki)

Według tego samego schematu możemy zbudować zapytanie wyświetlające nazwiska i wzrost osób wyższych niż wzrost średni.

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS J e t SQL

103

SELECT Nazwisko. Wzrost FROM Osoby WHERE Wzrost > (SELECT AVG(Wzrost) FROM Osoby)

Jeżeli każdy z działów będzie chciał stworzyć ze swoich pracowników drużynę ko­ szykówki, pomocnym może być zapytanie wyświetlające osoby, których wzrost jest wyższy od średniej w dziale, w którym pracują. Dodatkowo wyświetlmy numer tego działu, dla sprawdzenia — średni wzrost w tym dziale, a wyniki posortujmy względem numeru działu oraz malejąco względem wzrostu. SELECT Osoby.IdDzialu. Nazwisko. Wzrost. Średni FROM Osoby INNER JOIN (SELECT IdDzialu. AVG(Wzrost) AS Średni FROM Osoby GROUP BY IdDzialu) AS Xxx ON Osoby.IdDzialu = Xxx.IdDzialu AND Osoby.Wzrost > Xxx.Średni ORDER BY Osoby.IdDzialu. Wzrost DESC

Otrzymujemy dość skomplikowane wyrażenie SQL, które dla osób zaczynających kon­ struować zapytania może być bardzo kłopotliwe do zbudowania, a nawet do analizy (w przypadku kiedy wyrażenie już istnieje). Jak zatem postępować przy konstruowa­ niu złożonych zapytań SQL, które mają zawierać w sobie podzapytania? Najprostszą we­ dług autora metodą postępowania jest rozłożenie zagadnienia na prostsze składniki, a następnie składanie zapytania z mniejszych fragmentów. Składanie rozpoczynamy od fragmentu, który jest najniżej w hierarchii (najgłębiej zagnieżdżone podzapytanie). W rozwiązywanym zagadnieniu możemy rozpocząć od wyznaczenia średniego wzrostu w dziale, czyli: SELECT IdDzialu. AVG(Wzrost) AS Średni FROM Osoby GROUP BY IdDzialu

To zapytanie potraktujmy jako dynamiczną tabelę (podzapytanie) i nadajmy jej nazwę (alias) Xxx. Taką tabelę możemy traktować jak fizycznie istniejącą tabelę o nazwie Xxx. Złączmy ją teraz z tabelą Osoby, używając do tego pola IdDzialu'. SELECT Osoby.IdDzialu. Nazwisko. Wzrost. Średni FROM Osoby INNER JOIN (SELECT IdDzialu. AVG(Wzrost) AS Średni FROM Osoby GROUP BY IdDzialu) AS Xxx ON Osoby.IdDzialu = Xxx.IdDzialu

Stworzony w podzapytaniu alias wartości średniej Średni przydaje się nam teraz do wyprowadzenia w zapytaniu głównym tego pola W wyniku wykonania takiego zapyta­ nia otrzymamy teraz dane osoby połączone z wartością średnią wzrostu w jej dziale. Teraz tylko dodajemy złączenie nierównościowe — tak aby wyświetlane były te osoby, dla których wzrost jest większy niż średnia: SELECT Osoby.IdDzialu. Nazwisko. Wzrost. Średni FROM Osoby INNER JOIN (SELECT IdDzialu. AVG(Wzrost) AS Średni FROM Osoby GROUP BY IdDzialu) AS Xxx ON Osoby.IdDzialu = Xxx.IdDzialu AND Osoby.Wzrost > Xxx.Średni

Możemy zastanawiać się, dlaczego w złączeniu nierównościowym użyto kwalifikowanych nazw pól? Nazwy tych pól są przecież różne! Jest to kolejny przykład kłopotów parsera

104

Bazy danych. Pierwsze starcie

MS Jet SQL z przetwarzaniem bardziej skomplikowanych wyrażeń. W „silniejszych” systemach zarządzania bazą danych wystarczy podać nazwy pól. Pozostaje nam teraz tylko posortować rekordy klauzulą ORDER BY umieszczoną na końcu zapytania. Możemy według przedstawionego schematu skomplikować nasze pierwsze zadanie, tak aby wyświetlane były rekordy z wypłatami brutto większymi niż średnia z działu, w którym pracuje pracownik, dodatkowo wyprowadźmy tę średnią, a całość posortujmy według numeru działu oraz malejąco względem wrartości brutto: SELECT Zarobki. IdOsoby. Brutto. Średnio EROM (Osoby INNER JOIN Zarobki ON Osoby. IdOsoby = Zarobki.IdOsoby) INNER JOIN (SELECT IdDzialu. AVG(Brutto) AS Średnio FROM Osoby INNER JOIN Zarobki ON Osoby. IdOsoby = Zarobki.IdOsoby GROUP BY IdDzialu) AS xxx ON Osoby.IdDzialu=xxx.IdDzialu AND Zarobki.Brutto>xxx.Średni o ORDER BY Osoby. IdDzialu. Brutto DESC

Autor do rozwiązania postawionych zadań użył operatora złączenia JOIN, ale jest moż­ liwe zrealizowanie tych zapytań przy wykorzystaniu jedynie klauzuli WHERE. Spróbujmy rozwiązać jeszcze kilka tego typu przykładów. Pierwszym z nich jest tzw. zadanie włoskie (zostało sformułowane w tym kraju), które pojawiło się jakiś czas temu na listach dyskusyjnych. Opiera się ono o pojedynczą tabelę zawierającą trzy pola (rysunek 3.6). Pierwsze stanowi unikatowy identyfikator — numer indeksu stu­ denta. Drugie jest kodem literowym grupy, natomiast trzecie jest numerem studenta w' grupie (numer jest unikatowy w obrębie grupy, natomiast może powtarzać się w' innych grupach). Zadanie polega na wyświetleniu wszystkich pól osób, których nu­ mer w' grupie jest najwyższy. Rysunek 3 .6 . Struktura tabeli dla zadania „włoskiego ”

Przykładowy, skrócony zestaw danych jest przedstawiony w tabeli 3.11. Tabela 3.1 1 . P o kła d o w e dane dla zadania „włoskiego"

indeks

grupa

id_w_grupie

1 4

A B A

1 1 3

2 5 7 6 3

B

3

C C A

3 4 5

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

105

Pierwszym pomysłem na rozwiązanie naszego zadania jest zastosowanie złączenia INNER JOIN między tabelą Grupy a podzapytaniem wyznaczającym wartości maksymalne w obrębie każdej z grup. Złączenie jest dokonywane na symbolu grupy (pole Grupa) tabeli i zapytania oraz na numerze w grupie (Id_w_Grupie) i polu zawierającym w'artość maksymalną w obrębie grupy {MAX(Id_\v_G rupie)) o aliasie Maxim. SELECT Grupy.Indeks. Grupy.Grupa. Grupy.Id_w_Grupie FROH Grupy INNER JOIN (SELECT Grupa. MAX(Id_w_Grupie) AS Maxim FROM Grupy GROUP BY Grupa) AS Tmp ON (Tmp.Grupa=Grupy.Grupa) ANO (Grupy.Id_w_Grupie=Tmp.Maxim)

Kalką tego rozwiązania jest zastąpienie złączenia opartego o operator JOIN złączeniem między tabelą i podzapytaniem w oparciu o klauzulę WHERE: SELECT Grupy.Indeks. Grupy.Grupa. Grupy.Id_w_Grupie FROM Grupy . (SELECT Grupa. MAX(Id_w_Grupie) AS Maxim FROM Grupy GROUP BY Grupa) AS Tmp WHERE (Tmp.Grupa=Grupy.Grupa) AND (Grupy.Id_w_Grupie=Tmp.Maxim)

Ten sam rezultat uzyskamy, wykorzystując zapytanie skalarne jako źródło dla opera­ tora listy. Ponieważ podzapytanie ma wyznaczać wartość maksymalną tylko w grupie aktualnie wybranej, w zapytaniu głównym konieczne jest zastosowanie warunku łączą­ cego opartego o klauzulę WHERE i wykorzystującego aliasy tabeli, na której oparte są zarówno zapytanie, jak i podzapytanie. SELECT Indeks. Grupa. Id_w_Grupie FROM grupy AS SI WHERE Id_w_Grupie ° (SELECT MAX(Id_w_Grupie) FROM Grupy AS S2 WHERE S2.Grupa=Sl.Grupa) ORDER BY Grupa

Przytoczone tutaj rozwiązania świadczą, że w bardzo wielu przypadkach metoda roz­ wiązania nie jest ściśle deterministycznie określona. Mamy przecież trzy rozwiązania dające dokładnie takie same wyniki. W takim przypadku czynnikiem decydującym o wyborze jednego z nich powinien być test efektywności przetwarzania (rysunki 3.7, 3.8). Przeprowadźmy badania wydajności przetwarzania dla powyższych zapytań. Badania wydajności wykonano, tworząc procedurę w Visual Basic for Applications. Zastosowano mechanizm kolejnego generowania rekordów o losowym rozkładzie w'artości pól. W badaniu podstawowym przetestowano tabelę o zmiennej do 1000 liczbie rekordów. Począwszy od setnego rekordu, co 100 wykonywano czterokrotnie po trzy warianty zapytania do tabeli. Próbę powtórzono cztery razy. Wielokrotne wykonywa­ nie prób przy tej samej liczbie rekordów w tabeli miało na celu wyeliminowanie przy­ padkowych zaburzeń spowodowanych innymi procesami wykonywanymi przez kom­ puter, zmiennym czasem przesyłu danych na urządzenie wyjściowe czy odświeżaniem ekranu oraz innymi zakłóceniami przetwarzania. Do obróbki wykorzystano wartości średnie pomiaru czasu przetwarzania dla tej samej liczby przetwarzanych rekordów. Jak można było łatwo przewidzieć, najwolniej wykonywany był wariant rozwiązania

106

Bazy danych. Pierwsze starcie

Rysunek 3.7. Porównanie czasów przetwarzania zadania „ włoskiego ” w zależności od sposobu sformułowania zapytania i liczby przetwarzanych rekordów

Rysunek 3.8. Porównanie czasów przetwarzania zadania „ włoskiego ” w zależności od sposobu sformułowania zapytania i liczby przetwarzanych rekordów

0

20000

40000

60000

80000

100000

Liczba re kordów

oparty na skorelowanym zapytaniu skalarnym. Natomiast pomimo teoretycznych różnic w metodzie przetwarzania zapytań opartych o klauzulę WHERE i złączenie J0IN czasy ich wykonywania były praktycznie takie same (rysunek 3.7). Świadczy to o sto­ sowaniu przez producenta wbudowanego optymalizatora zapytań, który unifikuje pla­ ny wykonywania obu typów złączeń. Aby pokazać to dokładniej, powtórzono testy dla złączeń JOIN i WHERE dla większej liczby wygenerowanych rekordów — ich liczba maksymalna wyniosła 100 000. Dodatkowo dołączono zapytanie oparte o klauzulę WHERE z zamienioną kolejnością podzapytania i tabeli. Wyniki potwierdzają słuszność tezy o równoważności wszystkich analizowanych przypadków (rysunek 3.8). Jako kolejne postawmy sobie zadanie polegające na tym, że do każdego zarobku brutto dołożymy pole opisujące słownie jego wartość w zależności od przedziału, w którym się ona mieści. W tym celu zbudujmy dodatkową tabelę — Kategorie, w której pola OD i DO wyznaczają zakres, dla którego stosou'any jest opis umieszczony w polu Kategoria (tabela 3.12).

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

107

Tabela 3 .12. Podstawowa postać tabeli Kategorie OD

DO

Kategoria 500 1000

1000

100 000 000

Mało Średnio Dużo

Ostatnią wartość w polu DO stanowi górne ograniczenie wartości brutto i powinno być ustawione na maksymalną wartość, jaką można wpisać do pola typu walutowego (dla poprawy czytelności wpisano wartość 100 000 000). Zapytanie realizujące postawione zadanie będzie miało postać: SELECT IdOsoby. Brutto. Kategoria FR0M Zarobki INNER J0IN Kategorie ON (Zarobki.Brutto BETWEEN Kategorie.00 AND Kategorie.00)

Ten przykład jest poprawny składniowo, ale niestety niepoprawnie realizuje postawione zadanie. Wynika to z pokrywania się krańców przedziałów oraz tego, że operator BETWEEN zwraca nam przedział obustronnie domknięty. Natomiast przykład ten potwier­ dza fakt, że złączenie między tabelami można zrealizować, używając dowolnego operato­ ra (theta operatora). Poprawne rozwiązanie uzyskamy, zastępując operator BETWEEN operatorami algebraicznymi: SELECT IdOsoby. Brutto. Kategoria FR0M Zarobki INNER J0IN Kategorie ON ((Zarobki.Brutto >= Kategorie.OD) AND (Zarobki.Brutto < Kategorie.DO))

Jeśli dobrze przeanalizujemy tabelę Kategorie, to dojdziemy do wniosku, że nie jest ona dobrze skonstruowana. Wymaga bowiem, aby operator przepisywał do pola OD wartość pola DO z poprzedniego rekordu. Może to powodować pomyłki oraz jest źró­ dłem redundancji (powtarzania) danych. Zupełnie wystarczającą informacją do wyzna­ czenia zakresu jest podanie jednego z jego kresów (dolnego albo górnego). W związku z tym tabelę Kategorie możemy uprościć do postaci przedstawionej w tabeli 3.13. Tabela 3 .1 3 . Uproszczona postać tabeli Kategorie DO

Kategoria 500 1000 100 000 000

Mało Średnio Dużo

Tak jak w przypadku zadania „włoskiego” możemy stworzyć kilka równoważnych (w sen­ sie otrzymanego wyniku, a nie wydajności czy też sposobu przetwarzania) zapytań. Pierwsze z zaproponowanych rozwiązań wykorzystuje tylko operator złączenia J0IN. SELECT Brutto. Kategoria FR0M Kategorie INNER J0IN (SELECT Brutto. MIN(DO) AS Maks FR0M Zarobki INNER J0IN Kategorie ON Zarobki.Brutto < Kategorie.DO GROUP BY IdOsoby. Brutto) AS Tmp ON Tmp.Maks = Kategorie.DO

108

Bazy danych. Pierwsze sta rcie

Jak zwykle rozpocznijmy analizę zapytania od zagnieżdżonego podzapytania. Zapy­ tanie to stanowi nierównościowe złączenie pomiędzy tabelami Zarobki oraz Kategorie. Wybierane są wartość Brutto oraz minimalna wartość DO większa od danej wartości Brutto. Zewnętrzne zapytanie wybiera właściwą kategorię (opis) dla wybranego brutto, wykorzystując w złączeniu z podzapytaniem porównanie minimalnej wartości DO więk­ szej od danej wartości Brutto z odpowiadającą jej wartością pola DO. Kolejne rozwiązanie jest kopią poprzedniego, z tym że zewnętrzny operator złączenia JOIN zastąpiony został odpowiadającą mu klauzulą WHERE wykorzystującą ten sam co poprzednio warunek. SELECT Brutto. Kategoria FROM Kategorie. (SELECT IdOsoby. Brutto. MIN(DO) AS Maks FROM Zarobki INNER JOIN Kategorie ON Zarobki.Brutto < Kategorie.DO GROUP BY IdOsoby. Brutto) WHERE Maks = DO

Kolejna modyfikacja polegała na zamianie obu operatorów złączenia na odpowiadające im klauzule WHERE, z takimi samymi jak poprzednio warunkami. SELECT Brutto. Kategoria FROM Kategorie. (SELECT IdOsoby. Brutto. MIN(OO) AS Maks FROM Zarobki. Kategorie WHERE Brutto < DO GROUP BY IdOsoby. Brutto ) WHERE Maks = DO

Widocznym jest, że, tak samo jak w poprzednim przykładzie, w przypadku bardziej złożonych zapytań istnieje kilka poprawnych składniowo rozwiązań. Ponieważ, jak to pokazano przy zadaniu „włoskim”, rozwiązanie wykorzystujące operator listy ze sko­ relowanym podzapytaniem jest zdecydowanie mniej wydajne, zrezygnowano z po­ szukiwania takiego rozwiązania dla tego zadania (oczywiście rozwiązanie takie istnieje — uważnego czytelnika zachęcam do jego sformułowania). Tak jak poprzednio przeprowadzono testy, mając nadzieję, że w tym przypadku po­ jawią się różnice w szybkości otrzymania rozwiązania (rysunek 3.9). Poza przedstawio­ ną trójką zapytań stworzono czwarte z wewnętrznym sprzężeniem w oparciu o klauzulę WHERE i zewnętrznym stosującym operator złączenia JOIN. Do testów zastosowano tabelę Kategorie o wygenerowanych 625 rekordach opisujących przedziały zarobków oraz tabelę Zarobki o zmiennej liczbie rekordów. Tak jak poprzednio tabela generowana była czterokrotnie, a w każdym punkcie wszystkie testowane zapytania były wykony­ wane trzy razy. Metodologia ta, lak jak poprzednio, miała na celu wyeliminowanie zakłóceń wpływających na czas przetwarzania zapytań. Otrzymane w badaniach rezultaty świadczą, że w tym przypadku nieznacznie wydaj­ niejsze okazało się rozwiązanie stosujące klauzulę WHERE do realizowania złączeń. Jest to sprzeczne z poglądami reprezentowanymi przez większość specjalistów. Autor natomiast przestrzega przed uogólnianiem tego wniosku na inne złożone zapytania, szczególnie w przypadku stosowania indeksowania (o czym piszę w dalszej części książki). Szczególnie zawodne może być takie postępowanie w przypadku przewidy­ wania wydajności różnej realizacji zapytań w innych środowiskach — systemach zarzą­ dzania bazą danych.

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

109

Rysunek 3.9. Porównanie czasów przetwarzania zadania z kategoriami ii' zależności od sposobu sformułowania zapytania i liczby przetwarzari)’ch rekordów

Unia — koniunkcja zbiorów (krotek) Powróćmy do operacji na zbiorach. Jak to pokazano w przypadku wybierania wspól­ nych rekordów z tabel Osoby i ttt, część wspólną (przecięcie, iloczyn zbiorów) możemy uzyskać, stosując złączenie za pomocą operatora INNER JOIN, natomiast różnicę — wy­ korzystując operator LEFT JOIN (RIGHT JOIN) z warunkiem sprawdzającym wartość NULL odpowiednich pól. Do kompletu brakuje nam tylko sumy zbiorów. W tym celu wpro­ wadzono specjalny operator UNION— sprawdźmy jego działanie, łącząc rekordy z dwóch wymienionych tabel: SELECT Nazwisko. Imię FROM Osoby UNION SELECT Nazwisko. Imię FROM t t t

Wyznaczana jest tutaj suma rekordów pochodzących z dwóch zapytań. Zwróćmy jed­ nak uwagę na to, że elementy wspólne (powtarzające się rekordy) są eliminowane, bez względu na to, czy to powtarzanie dotyczy tej samej tabeli, czy co najmniej dwóch rekordów pochodzących z dwóch różnych tabel. Niezbyt precyzyjnie można byłoby to zapisać w postaci (Osoby UNION Ttt) = (Osoby u Ttt) - (Osoby n Ttt) Jeśli chcemy dokładnie wyznaczyć sumę dwóch zapytań, musimy użyć operatora UNION ALL: SELECT Nazwisko. Imię FROM Osoby UNION ALL SELECT Nazwisko, Imię FROM t t t

Otrzymujemy sumę dwóch zbiorów rekordów pochodzących z dwóch różnych zapytań. Oczywiście liczba zapytań łączonych operatorem UNION może być większa od dwóch.

110

Bazy danych. Pierwsze sta rcie

Rozważmy przypadek, gdy nazwy pól łączonych zapytań są różne. Możemy ten stan zasymulować przez zamianę miejscami pól w drugim z łączonych zapytań. SELECT Nazwisko. Imię FROM Osoby UNION ALL SELECT Imię. Nazwisko FROM t t t

W takim przypadku o nazwie pól wyprowadzanych przez zapytanie decyduje pierwsze z zapytań wybierających. Dotyczy to zarówno przypadku, kiedy stosujemy oryginalne nazwy pól tabeli, jak też przypadku, kiedy używamy aliasów nazw tych pól. Zawsze nazwa pola jest tą. której użyto w pierwszym zapytaniu. Oczywiste wymagania ko­ nieczne dla poprawności zapytania wykorzystującego operator UNION to: aby w zapy­ taniach składowych była taka sama liczba kolumn i aby typy danych były dla odpo­ wiadających sobie pól takie same. W produktach Microsoftu — aby typy danych pól z drugiego i kolejnych zapytali składowych dały się przekonwertować na odpowiednie typy pierwszego zapytania — oczywiście dotyczy to odpowiadających sobie pozycji na liście. Spróbujmy ten fragment zilustrować przykładem. Tworzymy bazę danych opisującą rozgrywki piłkarskie. Jej najistotniejszy fragment stanowią dwie tabele. Pierwsza 0 nazwie Drużyny opisująca nazwy drużyn piłkarskich (oczywiście liczba pól niekluczowych może być znacznie obszerniejszą np.: data zalożenią siedzibą logo etc.). Druga opisująca rozgrywki, o nazwie Mecze. Zawiera ona numer kolejki (IdKolejki) 1 numer meczu w kolejce rozgrywek (IdMeczu). Te dwa pola stanowią złożony klucz główny tabeli. Kolejne dwa pola (IdGosp, IdGosc) są kluczami obcymi wskazującymi na to, które drużyny rozgrywają ze sobą spotkanie (rysunek 3.10). Pozostałe dwa pola zawierają liczbę bramek zdobytych w tym meczu przez drużyny gości i gospodarzy. Tak jak i w tabeli Drużyny możliwe jest w tabeli Mecze wstawienie dodatkowych pól niekluczowych, np. data meczu, sędzia etc. Mamy w tym przykładzie do czynienia z cie­ kawym przypadkiem złączenia między tabelami. Łączone są bowiem dwa pola kluczy obcych tabeli Mecze z jednym polem tabeli Drużyny. Zarówno gospodarz, jak i gość spotkania są przecież drużynami, czyli ich dane znajdują się w tej samej tabeli. Rysunek 3 .10. Ilustracja złączenia wielokrotnego

Takie złączenie jest równoważne dwóm złączeniom: tabeli Mecze z tabelą Drużyny oraz tabeli Mecze z kopią tabeli Drużyny o aliasie nazwy Drużyny_1, jak pokazuje ry­ sunek 3.11. Taka ilustracja złączenia może jednak sugerować istnienie dwóch nieza­ leżnych tabel, co jest niezgodne z prawdą a z punktu widzenia normalizacji byłoby źródłem redundancji i niejednoznaczności danych. Jeśli drużyna została zdegradowana do niższej ligi (klasy rozgrywek), należałoby ten fakt uwzględnić w obu tabelach. Ta­ kie same kłopoty dotyczą awansu, czy też zmiany nazwy klubu. Czyli w takim stanie objawiłyby się wszystkie trzy rodzaje anomalii (usuwanią wstawiania i modyfikacji), z którymi tak usilnie w procesie normalizacji walczymy.

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

111

Rysunek 3 .1 1 . Dekompozycja złączenia wielokrotnego na dwa pojedyncze

Nasze zadanie jest z punktu widzenia kibica bardzo łatwe. Należy zapytaniem SQL (pojedynczym) stworzyć tabelę rozgrywek po wybranej kolejce. Tabela ma zawierać nazwy drużyn, sumę zdobytych punktów, sumę zdobytych bramek oraz sumę straco­ nych bramek. Przy czym zgodnie z regułami za zwycięstwo przyznajemy trzy punkty, za remis jeden punkt, a za przegrany mecz zero punktów. Oczywiście wygrywa dru­ żyna zdobywająca większą liczbę bramek. O kolejności w tabeli decyduje suma liczby punktów — im wyższa, tym wyższe miejsce w tabeli. W przypadku równej liczby punktów wyższe miejsce w tabeli zajmuje drużyna, która zdobyła sumarycznie więk­ szą liczbę bramek. Jeśli i to nie rozstrzygnie o pozycji w tabeli, wyżej notowana jest ta z drużyn, której różnica między sumą bramek zdobytych a sumą bramek straconych jest większa. Tak określone reguły powodują, że zapytanie rozwiązujące nasze zadanie może wyglądać następująco: SELECT Nazwa. COUNT(Nazwa) AS Ilosc5potkan. 3*SUM(Winner) + SUM(Remis) AS IloscPunktow. SUM(Strzelone) AS BramkiStrzelone. SUM(Stracone) AS Bramki Stracone. BramkiStrzelone - BramkiStracone AS RoznicaBramek FROM (SELECT Nazwa. ABS(BramkiGosc > BramkiGosp) AS Winner. ABS(BramkiGosc = BramkiGosp) AS Remis. BramkiGosc AS Strzelone. BramkiGosp AS Stracone FROM Drużyny INNER JOIN Mecze ON Drużyny.IdDruzyny = Mecze.IdGosc WHERE IdKolejki <= NrKolejki UNION ALL SELECT Nazwa. ABS(BramkiGosc < BramkiGosp) AS Winner. ABS(BramkiGosc = BramkiGosp) AS Remis, BramkiGosp AS Strzelone. BramkiGosc AS Stracone FROM Drużyny INNER JOIN Mecze ON Drużyny.IdDruzyny = Mecze.IdGosp WHERE IdKolejki <= NrKolejki ) GROUP BY Nazwa ORDER BY 3*SUM(Winner) + SUM(Remis) DESC. SUM(Strzelone) DESC. SUM(Stracone)

Rozwiązanie składa się z podzapytania zawierającego dwa składniki połączone ope­ ratorem unii. Zapytania składowe analizują dwie możliwe sytuacje: kiedy drużyna jest gościem i kiedy jest gospodarzem meczu. Rozważmy pierwszy z przypadków. SELECT Nazwa. ABS(BramkiGosc > BramkiGosp) AS Winner. ABS(BramkiGosc = BramkiGosp) AS Remis. BramkiGosc AS Strzelone, BramkiGosp AS Stracone FROM Drużyny INNER JOIN Mecze ON Drużyny. IdDruzyny = Mecze.IdGosc WHERE IdKolejki <= NrKolejki

112

Bazy danych. Pierwsze starcie

Podzapytanie to operuje na złączeniu za pomocą operatora JOIN dwóch tabel (Mecze i Drużyny) na polu IdGosc. Czyli operacje wykonywane sq tylko na tych rekordach, gdzie drużyna jest gościem — pozostałe rekordy nie są wyświetlane. Zwróćmy uwagę na dwa wyrażenia służące do wskazywania na wygrane oraz zremisowane mecze. W pierwszym przypadku mamy do czynienia z wyrażeniem: ABS(BramkiGosc > BramkiGosp) AS Winner

Wewnętrzne wyrażenie (BramkiGosc > BramkiGosp) zwraca wartość TRUE, gdy ilość bramek zdobytych przez gościa spotkania jest większa od liczby bramek zdobytych przez gospodarza. Wartość TRUE oznacza ustawienie wszystkich bajtów na wartość 1, np. przy zapisie zmiennej logicznej na ośmiu bajtach, co w dziedzinie liczb całkowitych ze znakiem jest interpretowane jako wartość -1. Dlatego wykorzystano funkcję ABS wy­ znaczającą wartość bezwzględną. Czyli w przypadku, gdy liczba bramek zdobytych przez gościa spotkania jest większa od liczby bramek zdobytych przez gospodarza, wyrażenie o aliasie Winner zwraca wartość jeden, a w przeciwnym przypadku (FALSE w dziedzinie liczb całkowitych ma wartość 0) ustawiana jest w tym polu wartość 0. Analogiczny mechanizm jest wykorzystywany w przypadku remisu. W podzapytaniach wykorzystywane jest filtrowanie w klauzuli WHERE z wyrażeniem zawierającym parametr NrKolejki, wskazującym, do której kolejki rekordy z tabeli Mecze brane są pod uwagę przy wyznaczaniu wyrażeń. Teraz w zapytaniu nadrzędnym wystarczy tylko wy­ brać nazwę drużyny, policzyć liczbę rekordów, i wyznaczyć wyrażenia na liczbę punktów (3*SUM(lVinner) + SUM(Remis) AS IloscPunktow) oraz zsumować bramki zdobyte i stracone, a następnie wyznaczyć ich różnicę. Grupowanie odbywa się oczywiście po nazwie drużyny — każda z drużyn ma obliczane powyższe wyrażenia oddzielnie. Ko­ lejność w tabeli ustalana jest na skutek odpowiedniego sortowania w klauzuli ORDER BY. Tak jak przy większości złożonych problemów rozwiązywanych przy pomocy SQL nie jest to rozwiązanie jedyne. Główną różnicą będzie oczywiście sposób wyznaczania sumy punktów. SELECT Nazwa. COUHT(IdDr) AS IloscSpotkan. 5UM(Punkty) AS IloscPunktow. SUM(SGosp) AS Bramki Strzel one. SUM(SGosc) AS Bramki Stracone. BramkiStrzelone - BramkiStracone AS RoznicaBramek FROM (SELECT IdGosp AS IdDr. COUNTGdGosp )*3 As Punkty. Sum(BramkiGosp) AS SGosp. Sum(BramkiGosc) AS SGosc FROM Mecze WHERE BramkiGosp > BramkiGosc AND IdKolejki <= NrKolejki GROUP BY IdGosp UNION ALL SELECT IdGosp AS IdDr. C0UNT(IdGosp)*l AS Punkty. Sum(BramkiGosp) AS SGosp. Sum(BramkiGosc) AS SGosc FROM Mecze WHERE BramkiGosp = BramkiGosc AND IdKolejki <= NrKolejki GROUP BY IdGosp UNION ALL SELECT IdGosp AS IdDr. C0UNT(IdGosp)*0 AS Punkty. SunUBramkiGosp) AS SGosp. Sum(BramkiGosc) AS SGosc FROM Mecze WHERE BramkiGosp < BramkiGosc AND IdKolejki <= NrKolejki GROUP BY IdGosp

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS J e t SQL

113

UNION ALL SELECT IdGosc AS IdDr. COUNKIdGosc )*3 As Punkty. Sum(BramkiGosc) AS SGosp. Sum(BramkiGosp) AS SGosc FROM Mecze WHERE BramkiGosp < BramkiGosc AND IdKolejki <= NrKolejki GROUP BY IdGosc UNION ALL SELECT IdGosc AS IdDr. COUNTCIdGosc)*1 AS Punkty, Sum(BramkiGosc) AS SGosp. Sum(BramkiGosp) AS SGosc FROM Mecze WHERE BramkiGosp = BramkiGosc AND IdKolejki <= NrKolejki GROUP BY IdGosc UNION ALL SELECT IdGosc AS IdDr. C0UNT(IdGosc)*0 AS Punkty. Sum(BramkiGosc) AS SGosp. Sum(BramkiGosp) AS SGosc FROM Mecze WHERE BramkiGosp > BramkiGosc AND IdKolejki <= NrKolejki GROUP BY IdGosc ). Drużyny WHERE iddruzyny=IdDr GROUP BY Nazwa ORDER BY SUM(Punkty) DESC. SUM(SGosp) DESC. SUM(SGosc)

W powyżej przytoczonym rozwiązaniu rozważamy aż sześć przypadków elementarnych, które są składnikami unii tworzącej wewnętrzne podzapytanie, a mianowicie: ❖ drużyna jest gospodarzem i strzeliła więcej bramek niż przeciwnik — wygrała mecz; ❖ drużyna jest gospodarzem i strzeliła tyle samo bramek co przeciwnik — remis; ❖ drużyna jest gospodarzem i strzeliła mniej bramek niż przeciwnik — przegrała mecz; ❖ drużyna jest gościem i strzeliła więcej bramek niż przeciwnik — wygrała mecz; ❖ drużyna jest gościem i strzeliła tyle samo bramek co przeciwnik — remis; ❖ drużyna jest gościem i strzeliła mniej bramek niż przeciwnik — przegrała mecz. Dla każdego z wymienionych przypadków dokonuje się częściowego sumowania punk­ tów zgodnie z regułami: za zwycięstwo 3, za remis 1 oraz za porażkę 0. Może dziwić trzecia z sum, gdyż zawsze daje ona zero — jest natomiast konieczna, jeśli chcemy znać całkowitą liczbę spotkań rozegranych przez drużynę, która jest wyznaczana w nad­ rzędnym zapytaniu — COUNT( IdD r ) AS IloscSpotkan. Każde z podzapytań jest grupo­ wane według identyfikatora drużyny i ograniczane do liczby kolejek mniejszej bądź równej od parametru N r K o le jk i. Należy zwrócić uwagę na konieczność stosowania operatora UNION ALL, aby nie eliminować mogących się powtórzyć sum składowych. W zapytaniu nadrzędnym sumowane są odpowiednie sumy cząstkowe. Kolejność w ta­ beli tak jak poprzednio wyznacza właściwe sortowanie rekordów w klauzuli ORDER BY. SELECT Nazwa. COUNTCIdDr) AS IloscSpotkan. SUM(Punkty) AS IloscPunktow. SUM(SGosp) AS BramkiStrzelone.

114

Bazy danych. Pierwsze sta rcie

SUM(SGosc) AS BramkiStracone. BramkiStrzelone - BramkiStracone AS RożnicaBramek FROM ( SELECT IdGosp AS IdDr. 3 As Punkty. BramkiGosp AS SGosp. BramkiGosc AS SGosc FROM Mecze WHERE BramkiGosp > BramkiGosc AND IdKolejki <= NrKolejki UNION ALL SELECT IdGosp AS IdDr. 1 AS Punkty. BramkiGosp AS SGosp. BramkiGosc AS SGosc FROM Mecze WHERE BramkiGosp = BramkiGosc AND IdKolejki <= NrKolejki UNION ALL SELECT IdGosp AS IdDr. 0 AS Punkty. BramkiGosp AS SGosp. BramkiGosc AS SGosc FROM Mecze WHERE BramkiGosp < BramkiGosc AND IdKolejki <= NrKolejki UNION ALL SELECT IdGosc AS IdDr. 3 As Punkty. BramkiGosc AS SGosp. BramkiGosp AS SGosc FROM Mecze WHERE BramkiGosp < BramkiGosc AND IdKolejki <= NrKolejki UNION ALL SELECT IdGosc AS IdDr. 1 AS Punkty. BramkiGosc AS SGosp. BramkiGosp AS SGosc FROM Mecze WHERE BramkiGosp = BramkiGosc AND IdKolejki <= NrKolejki UNION ALL SELECT IdGosc AS IdDr. 0 AS Punkty. BramkiGosc AS SGosp. BramkiGosp AS SGosc FROM Mecze WHERE BramkiGosp > BramkiGosc AND IdKolejki <= NrKolejki ) AS Temp INNER JOIN Drużyny ON Drużyny.IdDruzyny = Temp.IdDr GROUP BY Nazwa ORDER BY SUM(Punkty) DESC. SUM(SGosp) DESC. SUM(SGosc)

W powyższym rozwiązaniu przykładu piłkarskiego zrezygnowano z wyznaczania sum częściowych, zastępując je jednokrotnym wykonaniem agregacji na poziomie zapyta­ nia nadrzędnego. Powinno to doprowadzić do poprawienia wydajności przetwarzania dzięki ograniczeniu wyrażeń algebraicznych występujących w całym zapytaniu. Spraw­ dzenie poprawności tego wnioskowania pozostawiam uważnemu czytelnikowi. SELECT Nazwa. SUM BramkiGosc)*2)+l AS Punkty. BramkiGosp AS BrZdobyte. BramkiGosc AS BrStracone FROM Mecze WHERE BramkiGosp >= BramkiGosc AND IdKolejki <= NrKolejki UNION ALL SELECT IdGosc AS idDruzyny. (ABSCBramkiGosc > BramkiGosp)*2)+l AS Punkty.

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

115

BramkiGosc AS BrZdobyte. BramkiGosp AS BrStracone FROM Mecze WHERE BramkiGosc >= BramkiGosp AND IdKolejki <= NrKolejki UNION ALL SELECT IdGosp AS idDruzyny. 0 AS Punkty, BramkiGosp AS BrZdobyte. BramkiGosc AS BrStracone FROM Mecze WHERE BramkiGosp < BramkiGosc AND IdKolejki <= NrKolejki UNION ALL SELECT IdGosc AS idDruzyny. 0 AS Punkty. BramkiGosc AS BrZdobyte. BramkiGosp AS BrStracone FROM Mecze WHERE BramkiGosc < BramkiGosp AND IdKolejki <= NrKolejki ) AS Temp ON Temp.IdDruzyny = Drużyny.IdDruzyny GROUP BY Drużyny.IdDruzyny. Nazwa ORDER BY SUM(Punkty) DESC

Powyższy przykład nie jest całkowicie odmienny od poprzednich, jednak tutaj zasto­ sowano ciekawy sposób wyznaczania punktów, stosując wyrażenie — (ABSCBramkiGosp > '-► BramkiGosc)*2)+l AS Punkty. W składnikach uwzględniono tylko przypadek prze­ granej lub innego wyniku dla gospodarza i gościa traktowanych oddzielnie. Przypadek uwzględnienia przegranej wynika z konieczności obliczenia łącznej liczby spotkań oraz wszystkich bramek łącznie z tymi, które uzyskano w przegranych meczach. Dla tego zadania liczba potencjalnych rozwiązań wynikających z mutowania wyrażeń wy­ znaczających sumę punktów, różnych metod łączenia tabel czy sposobu filtrowania może być bardzo duża. Czytelnikowi zostawiam przyjemność znalezienia kolejnych rozwiązań tego problemu. Równie interesująca może być próba sformułowania rze­ czywistego (związanego z życiem) problemu powodującego konieczność budowania tak złożonych (pięknych) zapytań.

Inne formy zapytań wybierających Wielokrotnie potrzebne jest stworzenie listy rekordów w taki sposób, aby nie zawierała ona powtarzających się pozycji. Na przykład chcemy stworzyć listę imion występują­ cych w tabeli Osoby. W tym celu możemy zastosować dyrektywę DISTINCT: SELECT DISTINCT Imię FROM Osoby

Powtarzanie się pozycji dotyczy wszystkich wyświetlanych pól, czyli w przypadku: SELECT DISTINCT Imię. Nazwisko FROM Osoby

Mogą powtórzyć się zarówno nazwiska, jak i imiona, ale nie pojawią się powtarzające się pary (Imię, Nazwisko). Innym często pojawiającym się problemem jest potrzeba wyświetlenia tylko N pierw­ szych rekordów zapytania— możemy to osiągnąć, stosując dyrektywę TOP N. SELECT TOP 5 Imię FROM Osoby

116

Bazy danych. Pierwsze sta rcie

Nie istnieje dyrektywa powodująca wyświetlenie N ostatnich rekordów. O kolejności wyboru rekordów decydować możemy tylko przez zastosowanie odpowiedniego sor­ towania— klauzuli ORDER BY. SELECT TOP 5 Imię FROM Osoby ORDER BY Imię ASC

lub SELECT TOP 5 Imię FROM Osoby ORDER BY Imię DESC

Po dyrektywie TOP musi pojawić się stała. Niedopuszczalne jest w tym miejscu stoso­ wanie wyrażeń czy też parametrów. W środowiskach, gdzie nie zaimplementowano dy­ rektywy TOP, uzyskanie powyższego rezultatu może być rozwiązane przez zastosowanie podzapytania skorelowanego. SELECT Tl.Im ię. COUNT(Tl.Imie) FROM (SELECT DISTINCT Imię FROM Osoby ORDER BY Imię) AS T l. (SELECT DISTINCT Imię FROM Osoby ORDER BY Imię) AS T2 WHERE Tl.Im ię >= T2.Imię GROUP BY Tl.Im ię HAVING COUNT(Tl.Imie)<=N

Realizowane jest tutaj samozlączenie tabeli Osoby w oparciu o pole Imię. Ponieważ musimy rozróżniać pola pochodzące z dwóch różnych „kopii” tej samej tabeli, zostały nadane im aliasy nazw TI oraz 72. Sprawdzenie, czy liczba rekordów wyprowadzanych z pierwszej „kopii” tabeli jest mniejsza od parametru N, powoduje, że tylko N pierw­ szych rekordów jest wyświetlonych. Zauważmy, że zastosowanie dyrektywy DISTINCT powoduje, że wyprowadzone są tylko niepowtarzające się imiona. Gdyby imiona w ta­ beli nie były unikalne, pominięcie parametru DISTINCT powodowałoby tylokrotne po­ większenie wartości C O U N T d l.Im ię ), ile razy występuje powtórzenie tego imienia W efekcie imię, które byłoby trzecie na liście, a powtarzałoby się dwa razy (niezależ­ nie od miejsca wystąpienia), otrzymałoby numer sześć (zamiast trzy). Celko podaje prostsze rozwiązanie odnoszące się tylko do tabel, a nie podzapytań. SELECT Tl.Im ię. C0UNT(T1. Imię) FROM Osoby AS T l, Osoby AS T2 WHERE Tl.Im ię >= T2.Imie GROUP BY Tl.Im ię HAVING C0UNT(T1. Imie)<=N

Zapytanie to w oryginalnej formie dotyczy zmiennych numerycznych i domyślnie za­ kłada brak powtarzających się rekordów. Rozwiązanie takie jest, jak widać, wielce niedoskonale. Jeśli nie mamy pewności, że pola w rekordach nie są unikalne, musimy wesprzeć się o pole identyfikatora, które dodajemy jako identyfikator nieunikalnego pola w klauzuli grupowania. SELECT Tl.Im ię. C0UNT(T1.imię) FROM (SELECT IdOsoby. Inne FROM Osoby ORDER BY Imię) AS T l. (SELECT IdOsoby. Inne FROM Osoby ORDER BY Imię) AS T2 WHERE Tl.Im ie & Tl.Idosoby >= T2.Imie & T2.Idosoby GROUP BY Tl.Im ie. Tl.Idosoby HAYING COUNT(Tl.Imie) <= N

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

117

Zamiast filtrowania na funkcję agregującą możemy zastosować filtrowanie rekordów w oparciu o klauzulę WHERE, ale konieczne jest wtedy zbudowanie kolejnego (wyższego) poziomu zapytania. Zwiększenie liczby zagnieżdżeń w zapytaniu zawsze pociąga za sobą wydłużenie czasu przetwarzania— spadek wydajności. SELECT Imię. Ile FROM (SELECT Tl.Imie. COUNT(Tl.imie) AS Ile FROM (SELECT IdOsoby. Imię FROM Osoby ORDER BY Imię) AS Tl. (SELECT IdOsoby. Imię FROM Osoby ORDER BY Imię) AS T2 WHERE Tl.Imie & Tl.Idosoby >= T2.Imie & T2.Idosoby GROUP BY Tl.Idosoby. Tl.Imie) AS Temp WHERE Ile <= N

Idealnym rozwiązaniem w przypadku powtarzających się rekordów oraz braku moż­ liwości wskazania pola, które stanowiłoby wyróżnik powtarzających się rekordów, np. braku klucza podstawowego, byłaby możliwość grupowania po każdym rekordzie postaci GROUP BY * Niestety nie jest ono implementowane w żadnym znanym autorowi systemie zarządzania bazą danych. Druga postać predykatu TOP N PERCENT pozwala na wyprowadzenie N procent pierw­ szych rekordów zapytania. W przypadku analogicznym do poprzedniego otrzymamy zapytanie o postaci: SELECT TOP 5 PERCENT Imię FROM Osoby

Realizacja takiego zadania bez użycia predykatu TOP może zostać zrealizowana jak niżej: SELECT Tl.Imie. COUNT(Tl.imie) FROM (SELECT IdOsoby. Imię FROM Osoby ORDER BY Imię) AS Tl. (SELECT IdOsoby. Imię FROM Osoby ORDER BY Imię) AS T2 WHERE Tl.Imie & Tl.Idosoby >= T2.Imie & T2.Idosoby GROUP BY Tl.Imie. Tl.Idosoby HAVING COUNT(Tl.Imie) <= (N/100)*(SELECT COUNT(Imie) FROM Osoby)

Wykorzystaliśmy tutaj zapytanie skalarne wyznaczające liczbę rekordów w tabeli (re­ kordów o niepustym polu Imię), pomnożone przez wyrażenie N/I00 wyznaczające N procent wszystkich rekordów. Rozważmy teraz przypadek wyszukiwania powtarzających się wartości pól w tabeli, np. wyświetlmy powtarzające się w tabeli Osoby imiona. SELECT Imię FROM Osoby GROUP BY Imię HA7ING COUNT(Imie) >1

Czyli innymi słowy sprawdzamy, czy liczebność grupy jest większa niż jeden. Mamy tutaj do czynienia z ciekawym przykładem zastosowania grupowania bez konieczno­ ści obliczenia funkcji agregującej w głównej części zapytania. Oczywiście jeśli chcemy, to wyprowadzenie tej funkcji jest możliwe: SELECT COUNT(Imie). Imię FROM Osoby GROUP BY Imię HAVING COUNT(Imie) >1

118

Bazy danych. Pierwsze starcie

W tym przypadku wyprowadzone dane informują nie tylko o fakcie powtarzania się wartości w polu. ale i o liczbie powtórzeń w obrębie grupy. Jeżeli chcielibyśmy zdo­ być większą liczbę informacji o osobach noszące to samo imię, to nie możemy po prostu dopisać kolejnych pól do części głównej zapytania, gdyż pociąga to za sobą konieczność umieszczenia ich w klauzuli grupującej. W takim przypadku warunek wy­ stępujący w klauzuli HAVING dotyczyłby tylko tej zawężonej grupy, np. osób noszących to samo imię i nazwisko. Czyli wyprowadzone byłyby dane: liczba osób o tym samym imieniu i nazwisku oraz ta właśnie para pól {Imię i Nazwisko). Jeżeli informacja ma być pełniejsza dla powtarzających się imion bez względu na to, czy nazwiska są takie same, czy nie, musimy zbudować zapytanie z podzapytaniem o postaci: SELECT Imię. Nazwisko FROH Osoby WHERE Imię IN (SELECT Imię FROH Osoby GROUP BY Imię HAVING COUNT(Imie) >1 )

Oczywiście, że w takim przypadku możemy wyprowadzić w zapytaniu nadrzędnym dowolnie wiele pól. Czasami chcielibyśmy, aby nazwami kolumn były nie nazwy pól, ale wartości zawarte w tych polach. W takim przypadku MS Jet SQL oferuje nam tzw. zapytanie krzyżowe, które jest charakterystyczne dla tego środowiska. TRANSFORM SUM(Brutto) AS Wartość SELECT Opis. SUM(Brutto) AS SumaBrutto FROM (Działy INNER JOIN Osoby ON Działy.IdDzialu = Osoby.IdDzialu) INNER JOIN Zarobki ON Osoby. IdOsoby = Zarobki. IdOsoby GROUP BY Opis PIV0T Nazwisko

Klauzula PIV0T (obrót) powoduje, że wartości pola występującego po niej stają się nagłówkami kolumn. Dopuszczalne jest użycie dokładnie jednej kolumny lub wyra­ żenia. Klauzula TRANSFORM wskazuje na to, jaka funkcja agregująca będzie wyznaczana w tabeli — musi być dokładnie jedna. Natomiast wszystkie pola wyprowadzone w części głównej zapytania stanowią naglóu’ki wierszy i może ich być dowolnie wiele. Klauzule PI V0T i TRANSFORM stanowią zewnętrzne ,.obramowanie" zapytania wybierającego z gru­ powaniem. Funkcja agregująca nie musi być wyprowadzana, ale klauzula GROUP BY musi wystąpić, aby zapewnić składniową poprawność zapytania. Możemy przeanalizować działanie zapytania krzyżowego na podstawie bardziej zło­ żonego zapytania: TRANSFORM Sum(Liczba_sztuk*cena) AS Wartość SELECT Osoby.Nazwisko & ’ ’ & osoby.Imię AS Sprzedawca. KIient.Nazwisko & ’ ’ & klient.Im ię AS Klient. Sum(Liczba_sztuk*cena) AS Razem FROH Klient INNER JOIN (Osoby INNER JOIN (Faktura INNER JOIN (Towar INNER JOIN Transakcja

Rozdział 3. ❖ Strukturalny język zapytań SQL w wersji MS Je t SQL

119

ON Towar.IdTowaru = Transakcja.IdTowaru) ON Faktura.IdFaktura = Transakcja.IdFaktura) ON Osoby. IdOsoby = Faktura.IdOsoby) ON K lient.IdK lient = Faktura. IdKllent GROUP BY Osoby.Nazwisko & ' ' & osoby.Imię. Klient.Nazwisko & ' ’ & klient.Im ię PIVOT Nazwa:

Pozwala ono wyświetlić w postaci tabelarycznej dane opisujące zdarzenie „który' sprze­ dawca sprzedał któremu klientowi jakiego towaru za jaką kwotę”. Oprócz operatora IN w celu skorelowania zapytania nadrzędnego z podrzędnym możemy użyć kilku innych operatorów. Operator EXISTS (istnieje) zwraca wartość logicznąTRUE, gdy podzapytanie będące jego argumentem zwraca przynajmniej jeden wiersz. Możemy tego operatora użyć w celu wyświetlenia danych tych osób, które miały jakąkolwiek wypłatę. SELECT Nazwisko. Imię FROM Osoby WHERE EXISTS (SELECT Brutto FROM Zarobki WHERE Zarobki. Idosoby = Osoby.Idosoby)

Należy zwrócić uwagę, że korelacja między odpowiednimi rekordami zapytania i podzapytania została dokonana dzięki użyciu klauzuli WHERE w podzapytaniu z odpowiednim warunkiem. Odwrotny przypadek, czyli wyświetlenie osób, które nie pobrały żadnego wynagrodzenia, możemy uzyskać przez zaprzeczenie operatora EXISTS: SELECT Nazwisko. Imię FROM Osoby WHERE NOT EXISTS (SELECT Brutto FROM Zarobki WHERE Zarobki.Idosoby = Osoby.Idosoby)

Obydwa przypadki mogą być zrealizowane bez użycia podzapytania skorelowanego, a przez złączenie za pomocą operatora JOIN: SELECT DISTINCT Nazwisko. Imię FROM Osoby INNER JOIN Zarobki ON Zarobki. Idosoby = Osoby.Idosoby

Osoby, które pobrały wynagrodzenie. Zwrócić należy uwagę na dyrektywę DISTINCT, która powoduje niewyświetlanie powtarzających się rekordów w przypadku, gdy któ­ raś z osób pobrała więcej niż jedną wypłatę. SELECT Nazwisko. Imię FROH Osoby LEFT JOIN Zarobki ON Zarobki. Idosoby = Osoby. Idosoby WHERE Brutto IS NULL

Osoby, które nie pobrały wynagrodzenia. Złączenie LEFT JOIN z warunkiem braku od­ powiadających rekordów w tabeli występującej po prawej stronie operatora złączenia. Wróćmy na chwilę do operatora listy IN. Odpowiada on porównaniu pola z każdym z elementów listy. Jeśli chociaż jeden z elementów spełnia warunek równości, zwracana jest wartość logiczna TRUE. Gdybyśmy zamiast znaku równości chcieli użyć innego

120

Bazy danych. Pierwsze starcie

operatora, np. mniejszy niż czy większy niż. to w takim przypadku zastosowanie ope­ ratora IN jest niedopuszczalne. Dla porównań niekoniecznie równościowych mają za­ stosowanie operatory SOME, ANY i ALL. Jeśli chcemy, aby zwracana była wartość TRUE, jeśli choć jeden z elementów listy spełnia warunek, możemy zastosować operator SOME. SEIECT Nazwisko. Inne. Wzrost FROM Osoby WHERE Wzrost > SOME (SELECT AVG(wzrost) FROM Osoby GROUP BY IdDzialu)

W tym zapytaniu wyprowadzone są dane osób, których wzrost jest większy od śred­ niego wzrostu w dowolnym dziale. Operator ANYjest inną postacią (notacją) operatora SOME — działają dokładnie tak samo. SELECT Nazwisko. Inne. Wzrost FROM Osoby WHERE Wzrost > ANY (SELECT AVG(wzrost) FROM Osoby GROUP BY IdDzialu)

Taki sam rezultat możemy uzyskać, stosując zapytanie skalarne wyznaczające odpo­ wiednią funkcję agregującą. W naszym przypadku (tylko jeśli operatorem jest >) rów­ noważne użyciu operatora SOME/ANYjest zapytanie skalarne wyznaczające minimum. SELECT Nazwisko. Imię. Wzrost FROM Osoby WHERE Wzrost > (SELECT MIN(Sr) FROM (SELECT AVG(wzrost) AS Sr FROM Osoby GROUP BY IdDzialu))

Gdyby znale byl nieostry 2, to funkcją agregującą pozostałoby minimum (MIN), a zmia­ nie uległby jedynie operator przed zapytaniem skalarnym, na znak Natomiast w przy­ padku operatorów „mniejszości” < lub ^ funkcją agregującą byłoby maksimum (MAX) z odpowiednim operatorem arytmetycznym przed zapytaniem skalarnym. Należy zauważyć, że jeśli użyjemy operatora równości, to skutek działania operatorów IN oraz SOME, ANYjest równoważny. SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko IN (SELECT Nazwisko FROM t t t )

SELECT Nazwisko. Imię FROM Osoby WHERE Nazwisko = SOME (SELECT Nazwisko FROM t t t )

Natomiast jeżeli chcemy, aby w przypadku warunku (niekoniecznie równościowego) w odniesieniu do listy wartości wyprowadzana była wartość TRUE, gdy jest on spełniony dla każdego z elementów listy, musimy zastosować operator ALL: SELECT Nazwisko. Imię. Wzrost FROM Osoby WHERE Wzrost >ALL (SELECT AVG(wzrost) FROM Osoby GROUP BY IdDzialu)

Tak samo jak w przypadku operatora SOME/ANY użycie operatora ALL może zostać za­ stąpione zapytaniem skalarnym z odpowiednią funkcją agregującą: SELECT Nazwisko. Imię. Wzrost

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

121

FROM Osoby WHERE Wzrost > (SELECT MAX(Sr) FROM (SELECT AVG(wzrost) AS Sr FROM Osoby GROUP BY IdDzialu))

Wyświetliliśmy w obu przypadkach dane osób, których wzrost jest większy niż średnia wzrostu w każdym z działów. Wszystkie dotychczasowe zapytania były wykonywane przy założeniu, że tabele, do których w tym zapytaniu się odwołujemy, znajdują się w tej samej bazie. Access po­ zwala na formułowanie zapytań do tabel znajdujących się w innych plikach MS Access (obcych bazach Access): SELECT Działy.Opis, Osoby.Nazwisko. Zarobki.Brutto FROM Działy INNER J01N (Osoby INNER JOIN Zarobki ON Osoby.IdOsoby = Zarobki. IdOsoby) ON Działy.IdDzialu = Osoby.IdDzialu IN 'C:\ADAM\cwiczenia\Baza.MDB'

Wybrano rekordy z trzech połączonych tabel (Działy, Osoby, Zarobki), które wszyst­ kie znajdują się w pliku o nazwie Baza.MDB w folderze C:\ziDAM\cwiczenia\. Gdyby każda z tabel znajdowała się w innej lokalizacji, to parametr IN (proszę odróżniać od operatora listy, mimo dokładnie takiej samej nazwy) musiałby się znaleźć przy każdej z wymienianych tabel. Możemy również sięgać do danych zawartych w plikach o innych formatach danych, „rozpoznawanych” przez MS Access, np. w pliku dBase: SELECT Opis FROM dzialy_db IN 'D:\temp\ ’ [dBASE IV:]

Możliwe jest skorzystanie z innych niż dBase źródeł danych. Po słowie kluczowym IN występuje tutaj parametr zwany „connection string” (łańcuch połączenia — opis połą­ czenia). Parametr ten ma postać takąsamąjak właściwość CONNECT obiektu ADO. W przy­ padku „silnych” systemów zarządzania bazą danych (serwerów baz danych) możliwe jest zastosowanie mechanizmu wymiany ODBC. W tym przypadku np. dla bazy danych Microsoft SQL Server connection string może mieć postać: ’ODBC:DSN=plik:UlD=user:PWD=password:DATABASE=baza:’

Metody łączenia ze źródłami danych za pomocą mechanizmu ADO zostaną opisane w dalszej części książki. Należy pamiętać, że dużo bardziej wydajne (optymalizacja producenta) niż budowanie zapytań do „obcych” źródeł jest zastosowanie równoważnego mechanizmu połączenia tabel. Wtedy zapytania budowane są do dynamicznych kopii tabel źródłowych, które znajdują się w bieżącej bazie danych.

122

Bazy danych. Pierwsze sta rcie

Do tej pory zapytania SQL służyły nam wyłącznie do wyświetlania w różnej postaci istniejących, wpisanych wcześniej danych. Jest to podstawowy zakres stosowania SQL, ale nie jedyny. Przy pomocy tego języka możemy modyfikować, zmieniać czy wpro­ wadzać dane. Jak na złość przedstawiona poniżej składnia pierwszego przykładu łączy w sobie zarówno cechy zapytania wybierającego, modyfikującego dane, jak i opisywa­ nych w kolejnym rozdziale zapytań zmieniających strukturę danych. Stąd właściwie trudno określić precyzyjnie miejsce, w którym to zapytanie powinno zostać przedsta­ wione. Ponieważ jest ono oparte o polecenie SELECT używane w zapytaniach wybierają­ cych, przedstawmy je w tym miejscu, choć równie dobrze można byłoby to uczynić zarówno w poprzednim, jak i następnym rozdziale. Spróbujmy utworzyć na podstawie istniejącej tabeli (szablonu) nową tabelę o nazwie Nowa. Użyjemy w tym celu polecenia SELECT o następującej składni: SELECT Nazwisko. Imię. RokUrodz INTO Nowa FROM Osoby

Na skutek wykonania tego zapytania na podstawie nazw oraz typów pól wybranych z istniejącej tabeli szablonu (w naszym przypadku Osoby) zostanie stworzona tabela o nazwie Nowa, do której zostanie przepisana zawartość wszystkich rekordów tabeli źródłowej Osoby. Jeżeli przy otwartym okienku projektu SQL wybierzemy przycisk arkusz danych QO, to skutkiem będzie tylko wyświetlenie wybranych rekordów. Rze­ czywiste uruchomienie zapytania modyfikującego (dotyczy to wszystkich tego typu zapytań) nastąpi po naciśnięciu przycisku UD. To samo można wykonać po zamknię­ ciu widoku Projekt i otwarciu zapytania z poziomu kontenera zapytania. MS Access przed każdą modyfikacją danych wyświetla dwa komunikaty: pierwszy informujący 0 próbie wykonania modyfikacji, a drugi — o liczbie modyfikowanych rekordów. Jeżeli spróbujemy wykonać to zapytanie ponownie, to system zarządzania bazą danych wykryje, że już istnieje w bazie tabela o tej nazwie. W przypadku MS Access zostanie wyświetlony komunikat, w którym zostaniemy zapytani, czy na pewno chcemy nadpi­ sać dane na istniejącym obiekcie. Jeżeli odpowiemy przecząco — akcja zostanie anu­ lowana. Przy odpowiedzi twierdzącej tabela docelowa Nowa zostanie wykasowana 1proces tworzenia tabeli na podstawie tabeli (szablonu) zostanie powtórzony. Jeśli chcemy ograniczyć liczbę wierszy przepisywanych do nowo stworzonej tabeli z tabeli źródłowej, musimy użyć klauzuli filtrującej WHERE, np.: SELECT Nazwisko. Imię. RokUrodz INTO Nowa FROM Osoby WHERE RokUrodz < 1980

W ten sposób w tabeli docelowej znajdą się tylko dane osób urodzonych przed 1980 rokiem. Wielokrotnie chcemy, aby „kopiowana” była tylko struktura, natomiast nie chcemy przepisywać żadnych danych — w tym celu należy postawić w klauzuli WHERE warunek, który nigdy nie będzie spełniony, np.:

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

123

SELECT Nazwisko. Imię. RokUrodz INTO Nowa FROM Osoby WHERE RokUrodz > 99999

Z punktu widzenia logiki trudno sobie wyobrazić sytuację, że ktokolwiek będzie uro­ dzony po roku 99999, ale czy to z powodu świadomego podania abstrakcyjnej daty urodzenia, czy też nieświadomego błędu przy wpisywaniu danych, nie da się wyklu­ czyć pojawienia się takiego wpisu — chyba że ustanowiono dodatkowe ograniczenia. Stąd też wygodniej w warunku odwołać się do klucza podstawowego: SELECT Nazwisko. Imię. RokUrodz INTO Nowa FROM Osoby WHERE IdOsoby IS NULL

Z definicji klucz podstawowy musi być określony, czyli nie może przybrać wartości NULL. Zwróćmy uwagę na to, że tak jak we wszystkich poprzednich przypadkach in­ strukcji SELECT pole służące do filtrowania nie musi pojawiać się na liście wybieranych pól. Pozostaje jeszcze do rozważenia przypadek, gdy w tabeli źródłowej nie został zde­ finiowany klucz podstawowy, w tym przypadku należy użyć do filtrowania takiego wyrażenia, o którym wiemy, że nigdy nie będzie prawdziwe, np.: SELECT Nazwisko. Imię. RokUrodz INTO Nowa FROM Osoby WHERE 1 = 2

Takiego typu warunek, ponieważ może być zastosowany do każdej tabeli, jest naj­ ogólniejszy, a co za tym idzie najbezpieczniejszy w stosowaniu. Access pozwala również przy zastosowaniu polecenia SELECT INTO tworzyć (kopio­ wać) tabele w zewnętrznej bazie danych, dzięki wskazaniu docelowego pliku (pełna nazwa ze ścieżką) po klauzuli IN. SELECT Nazwisko. Imię. RokUrodz INTO Nowa IN 'C:\sciezka\plik.m db' FROM Osoby

Metodologia jest analogiczna jak w przypadku zapytań wybierających odwołujących się do zewnętrznych źródeł, ale ogranicza się tylko do plików MS Access. Jeśli już istnieje tabela Nowa, to możemy do niej dodawać kolejne rekordy: INSERT INTO Nowa VALUES ('Kowalski1. 'Ja n '. 1976)

W ten sposób został dopisany do tabeli jeden rekord, w którym zdefiniowano warto­ ści wszystkich pól. Kolejność wartości podawanych w nawiasie po słowie kluczowym VALUES wynika z kolejności pól w definicji tabeli. Ogranicznikiem pól tekstowych jest znak ' (apostrof). Nie jest to pokazane w tym zapytaniu, ale należy o tym pamiętać, że separatorem dziesiętnym w SQL jest zawsze . (kropka). Natomiast ogranicznikiem pola daty jest hash (")• Czasem zdarza się, że posiadana przez nas informacja nie jest kompletna. Znamy tylko część wartości pól rekordu. Na przykład w kolejnym rekordzie nieznany jest rok urodzenia osoby. Aby wprowadzić niekompletne dane, należy po na­ zwie tabeli podać listę wstawianych pól.

124

Bazy danych. Pierwsze starcie

INSERT INTO Nowa (Nazwisko. Imię) VALUES ('Nowak'. 'K arol')

Kolejność wstawianych wartości nie wynika z kolejności pól w tabeli, ale z kolejności na liście w zapytaniu. Zapytanie zostanie poprawnie przetworzone, gdy możliwe jest wpisanie w pomijane przy wpisywaniu pola wartości niezdefiniowanej NULL (nie za­ stosowano do nich ograniczenia NOT NULL). INSERT INTO Nowa (Nazwisko, Imię) VALUES ( 'Karol ’ . 'Nowak')

Czyli wykonanie powyższego zapytania spowoduje wpisanie do pola Nazwisko war­ tości Karol, a do pola Imię wartości Nowak. Poprawne składniowo jest również po­ niższe zapytanie: INSERT INTO Nowa (Nazwisko, Imię) VALUES ('Nowak'. 44)

Ponieważ w produktach Microsoft dane są przekazywane przez typ variant, możliwe jest wpisanie do pola tekstowego liczby nawet wtedy, gdy nie zastosowano ogranicz­ nika charakterystycznego dla zmiennych znakowych (apostrof). Wpisanie do zmiennej typu numerycznego zmiennej znakowej jest możliwe wtedy, gdy zawiera zgodny z no­ tacją zapis liczby. Ciekawy przypadek występuje wtedy, gdy mamy w tabeli zdefiniowane pole z automa­ tyczną inkrementacją(autonumer), tak jak ma to miejsce w tabeli Osoby. INSERT INTO Osoby VALUES (14. 1. 'Kowal'. 'P i o t r '. 1966. 1.78)

Jak widać, pomimo ustawionej automatycznej numeracji konieczne jest podanie warto­ ści wstawianej w pole IdOsoby. Możliwe jest wstawianie rekordów w miejsca braku­ jących rekordów, co nie jest możliwe w części wizualnej MS Access. Należy jednak bardzo ostrożnie korzystać z tej możliwości. Po pierwsze możliwe jest, że kiedyś bę­ dziemy chcieli z danych archiwalnych odtworzyć brakujące, usunięte wpisy. Po dru­ gie, co bardziej istotne, burzy to porządek automatycznej numeracji, co może dopro­ wadzić do sytuacji, w której kolejny generowany automatycznie numer pokryje się z już istniejącym w bazie i trzeba będzie „ręcznie” ustawiać jego wartość zapytaniem jak wyżej. Natomiast jeśli chcemy skorzystać z dobrodziejstwa automatycznej numeracji, konieczne jest jawne podanie nazw wstawianych pól z pominięciem tego, na którym automatyczna numeracja została ustanowiona. INSERT INTO Osoby (IdDzialu. Nazwisko. Imię. RokUrodz. Wzrost) VALUES ( 1 .'K o w a l'.'P io tr'.1966.1.78)

W każdym z poprzednich przykładów jednorazowo dopisywany był dokładnie jeden rekord. Istnieje jednak możliwość dopisywania wielu rekordów jednocześnie wtedy, gdy źródłem danych jest inna tabela (zapytanie). Zastępujemy wtedy słowo kluczowe VALUES z listą wartości zapytaniem wybierającym SELECT. INSERT INTO Nowa SELECT Nazwisko. Imię. Wzrost FROM Osoby

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

125

W ten sposób z tabeli Osoby przepisywane są dane ze wszystkich rekordów do wszyst­ kich pól tabeli Nowa. Jeśli chcemy wpisywać dane tylko do części pól, musimy po nazwie pola wymienić listę tych pól, do których wartości mają być wstawiane. INSERT INTO Nowa (Nazwisko. Imię) SELECT Nazwisko. Imię FROM Osoby

Tak jak poprzednio przepisane będą wartości ze wszystkich pól tabeli Osoby do od­ powiadających im pól tabeli Nowa. Tale samo jak w przypadku użycia słowa kluczowego VALUES kolejność listy pól musi zgadzać się z listą pól w zapytaniu SELECT. Oczywiście ze względów składniowych musi być zgodna tylko liczba pól na obu listach. Ze wzglę­ du na błędy przetwarzania konieczna jest również zgodność typów odpowiednich pól (rozumiana szerzej, czyli że możliwa jest konwersja wartości źródłowej do typu docelo­ wego). Natomiast absolutnie nie jest wymagana zgodność nazw odpowiednich pól, np.: INSERT INTO Nowa (Nazwisko. Imię) SELECT Imię. Nazwisko FROM Osoby

Również kolejne zapytanie jest poprawne, ponieważ dane z pola numerycznego dają się konwertować do docelowego typu znakowego. INSERT INTO Nowa (Nazwisko. Imię) SELECT Nazwisko. Rokllrodz FROM Osoby

W prezentowanych do tej pory przykładach instrukcji INSERT przepisywane były do tabeli docelowej wszystkie rekordy tabeli źródłowej. Aby ograniczyć liczbę przepi­ sywanych rekordów, należy zastosować w podzapytaniu klauzulę filtrującą WHERE: INSERT INTO Nowa (Nazwisko. Imię) SELECT Imię. Nazwisko FROM Osoby WHERE RokUrodz < 1984

Do tabeli docelowej zostaną przepisane tylko te rekordy, które spełniają kryterium fil­ trowania. W naszym przypadku przepisane zostaną dane tych osób, które urodziły się przed 1984 r. Można oczywiście prowadzić dalsze dywagacje nad strukturą podzapytania wybierającego będącego źródłem danych (rekordów) dla instrukcji INSERT. Wy­ godniejszym jest jednak stwierdzenie, że źródłem danych dla instrukcji INSERT może być dowolne poprawne składniowo zapytanie wybierające — może one zawierać dowolne elementy składni, pod warunkiem, że dane są zgodne z typami pól w tabeli docelowej. Zapytanie wstawiające wiersze pozwala również, podobnie jak SELECT INTO, operować na zewnętrznych danych. Również analogicznie zestaw źródeł zewnętrznych jest ogra­ niczony tylko do plików MS Access. INSERT INTO Nowa (Nazwisko. Imię) IN 'C:\sciezka\plik.m db' VALUES C K arol'. 'Nowak')

126

Bazy danych. Pierwsze starcie

Dotyczy to także składni, w której źródłem danych jest zestaw rekordów pochodzących z innej tabeli, nawet wtedy, gdy również tabela źródłowa nie jest zawarta w bieżącej bazie danych. INSERT INTO Nowa (Nazwisko. Imię) IN ’C:\sciezka\plik.mdb' SELECT Nazwisko. RokUrodz FROM Osoby IN 'C:\ADAM\cwiczenia\Baza.MDB-

Jeśli mamy już jakiś zestaw danych (rekordów) w tabeli, to możemy modyfikować, zmie­ niać (aktualizować) istniejące dane. W tym celu wykonamy instrukcję UPDATE, która po słowie kluczowym SET zawiera wyrażenie opisujące dokonywaną zmianę. UPDATE Nowa SET Nazwisko = UCase(Nazwisko)

Wykonanie powyższego zapytania spowoduje, że wszystkie dane zawarte w tabeli Nowa w polu Nazwisko zastąpione będą tymi samymi wartościami pisanymi przy użyciu tylko dużych liter — wbudowana funkcja UCase. UPDATE Nowa SET Nazwisko = LCase(Nazwisko)

Uzupełnieniem tej funkcji jest funkcja LCase(zrmenna) przepisująca wartość zmiennej na pisaną małymi literami. Istnieje możliwość jednoczesnego modyfikowania wartości więcej niż jednego pola tabeli. UPDATE Nowa SET Nazwisko = UCase(Nazwisko). Imię = UCase(Imie)

W tym przypadku jednoczesnej modyfikacji (przepisaniu wartości na pisaną dużymi literami) podlegają pola Imię i Nazwisko. UPDATE Nowa SET Nazwisko = Imię. Imię = Nazwisko

Natomiast to zapytanie powoduje zamianę wartości między dwoma polami tego samego rekordu. Wszystkie omawiane przypadki modyfikują wszystkie rekordy w tabeli. Ograni­ czenie modyfikowanej liczby rekordów można uzyskać, stosując klauzulę filtrującąWHERE: UPDATE Nowa SET RokUrodz = 0 WHERE RokUrodz IS NULL

W ten sposób rekordy, dla których nie podano wartości pola RokUrodz, będą miały przypisaną wartość zero. Istnieje możliwość modyfikowania danych w oparciu o dane zgromadzone w innej tabeli. Jeżeli dostawy towarów są przechowywane w oddzielnej tabeli Doslmiy, za­ wierającej między innymi pola: ldDostawy, IdTowam; szt, to możemy zwiększyć stan magazynowy (tabela Towary), używając skorelowanego podzapytania. UPDATE Towar SET stan =stan + szt FROM (SELECT sz t. IdTowaru FROM Dostawy) AS aaa WHERE Towar.IdTowaru=aaa.IdTowaru AND IdDostawy=77

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

127

Korelacja między modyfikowaną tabelą a tabelą źródłową odbywa się za pomocą pól IdTowaru z obydwu tabel. Drugi z warunków wskazuje na identyfikator aktualnej (ostat­ niej) dostawy i oczywiście jego wartość jest przykładowa. Kolejną manipulacją danymi będzie ich usunięcie. W składni MS Jet SQL przy instruk­ cji DELETE wymagane jest podanie nazwy pola lub gwiazdki. Sugerować to by mogło, że modyfikacja (usuwanie) dotyczy tylko wymienianego pola. W rzeczywistości bez względu na to, jakie pole wystąpi po instrukcji DELETE, zawsze usunięte będą wszystkie rekordy DELETE Nazwisko FROM Nowa

a

DELETE Inne FROM Nowa

D

DELETE * FROM Nowa

Tak jak przy poprzednio omawianych instrukcjach ograniczenie działania instrukcji usu­ wającej uzyskujemy przez zastosowanie klauzuli WHERE: DELETE Nazwisko FROM Nowa WHERE Nazwisko LIKE 'Now*’

W ten sposób usunięte zostaną z tabeli Nowa te rekordy, w których nazwisko rozpo­ czyna się od frazy Now. DELETE Nazwisko FROM Nowa WHERE Nazwisko LIKE '[param]*'

Przez analogię możemy skonstruować zapytanie, w którym filtr dany jest za pomocą parametru.

ZapyŁanrańa oira®cflyffDlk[U]Ją@e s&rm M oarę Ibagy Tworzenie tabel Omawiając przykłady, zakładano dotychczas, że istnieje już jakaś struktura bazy danych — stworzone wcześniej zostały tabele. Spróbujmy teraz przyjrzeć się bliżej metodzie definiowania tabel za pomocą języka MS Jet SQL. Podstawowa składnia polecenia CREATE TABLE poza nazwą tworzonej tabeli obejmuje definicję pola bądź pól ujętą w nawias zwyczajny. CREATE TABLE Inna (Nr in t)

Powstała tabela o nazwie Inna, która składa się z jednego pola o nazwie Nr typu cał­ kowitego — integer. CREATE TABLE Inna ( Nr in t. Opis text(30)

128

Bazy danych. Pierwsze sta rcie

Tym razem tabela Inna składa się z dwóch pól: całkowitego Nr oraz znakowego opis. Na polach nie zostały zdefiniowane żadne dodatkowe ograniczenia. W celu zdefinio­ wania typu znakowego użyto nazwy typu /er/, tak jak ma to miejsce w części wizualnej MS Access. Ponieważ w standardzie SQL do definiowania typów łańcuchowych używa się typu varchar, polecam stosowanie takiego zapisu. CREATE TABLE Inna

( Nr in t. Opis varchar(30)

) Dodatkowym argumentem używania takiego nazewnictwa jest fakt, że typ text może być mylony z nazywanym tak w niektórych środowiskach typem zawierającym długi dokument tekstowy (odpowiednik Noty w części wizualnej MS Access). Pierwszym nasuwającym się ograniczeniem jest ustawienie dla tabeli pola klucza pod­ stawowego — PRIMARY KEY. Powoduje to, że w polu mogą się pojawić tylko unikatowe wartości oraz wartości te muszą być zdefiniowane (niemożliwe jest użycie wartości NULL dla pola klucza podstawowego). CREATE TABLE Inna

( Nr in t PRIMARY KEY. Opis varchar(30)

) Podobną rolę jak ustawienie klucza podstawowego odgrywa ograniczenie UNIQUE. Za­ pewnia ono, że nie mogą być wpisywane do pola z tym ograniczeniem wartości powta­ rzające się — wartości w polu są unikatowe. Natomiast w przeciwieństwie do klucza podstawowego możliwe jest wpisanie (ustawienie) do tego pola wartości niezdefinio­ wanej NULL. Przy czym wpisy NULL mogą się powtarzać. Jest to uzasadnione tym, że skoro wartość jest nieznana, to nie wiadomo, jaką będzie wartością, kiedy już ją pozna­ my (uzupełnimy). Założono ,.optymistycznie‘\ że dwie wartości nieznane nie są równe. W logice trójstanowej zapisano, że (NULL=NULL)oNULL. CREATE TABLE Inna

( Nr in t UNIOUE. Opis varchar(30)

) W przypadku umieszczenia ograniczenia bezpośrednio w definicji pola, rola nazwa­ nia tego ograniczenia jest przekazywana systemowi. Dlatego też, aby jawnie odwołać się do tego ograniczenia (przez nazwę), musimy tę nazwę odczytać z tabel systemowych. Jeżeli chcemy, aby nazwa ograniczenia została nadana w sposób jawny, przy jej two­ rzeniu musimy użyć słowa kluczowego CONSTRAINT (więzy, ograniczenia). CREATE TABLE Inna

( Nr in t CONSTRAINT numer PRIMARY KEY. Liczba in t CONSTRAINT nzero NOT NULL

)

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

129

W tym przykładzie poza znanym już ograniczeniem PRIMARY KEY (klucz podstawowy) wprowadzono dla pola Liczba ograniczenie NOT NULL niezezwalające na pominięcie jego wartości (wartość tego pola zawsze, dla każdego rekordu, musi być podana). Istnieje również ograniczenie NULL pozwalające na pominięcie wartości dla pola. Jest to stan domyślny, dlatego może nie być ustawiany w sposób jawny. Ponieważ dla żadnej tabeli nie może być ustanowiony więcej niż jeden klucz podsta­ wowy, to aby wymusić stan, w którym pole zachowuje się tak, jakby ustawiono na nim ograniczenie PRIMARY KEY, wystarczy połączyć ze sobą w jednym polu ograniczenia UNIQUE i NOT NULL: CREATE TABLE Inna ( Nr in t CONSTRAINT numer PRIMARY KEY. Liczba in t CONSTRAINT aaa NOT NULL UNIOUE

) Oczywiście możemy to uczynić bez nadawania nazwy ograniczeniom, czyli bez użycia słowa kluczowego CONSTRAINT. CREATE TABLE Inna

( Nr in t PRIMARY KEY. Liczba in t NOT NULL UNIOUE )

Jak już wiemy, nie jest możliwe ustawienie na jednej tabeli więcej niż jednego klucza podstawowego, ale możemy sobie zażyczyć, aby byl on kluczem złożonym (byl oparty o więcej niż jedno pole). CREATE TABLE Inna ( Nr in t. Liczba in t. CONSTRAINT numer PRIMARY KEY(Nr.Liczba)

) Zapewnia nam to, że pary pól nie powtarzają się oraz że do żadnego z nich nie można wpisać wartości niezdefiniowanej NULL. Ze względu na wydajność przetwarzania za­ leca się unikanie kluczy wielokrotnych, nawet za cenę niezapewnienia trzeciej postaci normalnej. Tak samo ograniczenie unikalności możemy ustanowić dla pary lub większej liczby pól. CREATE TABLE Inna

( Nr in t. Liczba in t. CONSTRAINT numer UNIQUE(Nr.Liczba)

) Tego typu ograniczenie nie może zostać ustanowione w wizualnej części MS Access, a tylko z poziomu MS Jet SQL. W tym przypadku możliwe jest ustanowienie warto­ ści dowolnego z pól na NULL. Możliwe jest również, aby oba pola miały wartość nie­ zdefiniowaną. Unikalność nie obejmuje wartości NULL, czyli dwie pary pól o wartościach

130

Bazy danych. Pierwsze sta rcie

(1, NULL) (1, NULL) spełniają zdefiniowany wyżej warunek unikalności pary, gdyż nie wiadomo, jaką wartość przybierze (o ile w ogóle przybierze) drugie z pól. Ogranicze­ nie NOT NULL nie może być ustanowione dla pary lub większej ilości pól jednocześnie. Ciekawą formą ograniczenia, które należałoby nazywać sekwencją, jest automatyczna inkrementacja wartości pól. Nie jest ona jednak ustawiana jako CONSTRAINT, ale jako wy­ dzielony typ pola (liczbowe, całkowite z nadbudowaną funkcjq automatycznej numeracji). CREATE TABLE Inna

( Nr autoincrement. Liczba in t

) Nie jest możliwe w części wizualnej zapanowanie nad sposobem generowania sekwencji numerów (dla pustej tabeli — zawsze od jedynki co jeden). CREATE TABLE Inna ( Nr autoincrement(5.7). Liczba in t

) W tym przypadku wymusiliśmy, aby kolejne numery były generowane, począwszy od wartości 5, a kolejne były wyższe o 7 od poprzedniego. Jednym z ważniejszych ograniczeń służących do wymuszania więzów integralności jest klucz obcy. CREATE TABLE Nagrody

( IdNagrody in t PRIMARY KEY . IdNagrodzonego in t. CONSTRAINT klucz FOREIGN KEY (IdNagrodzonego) REFERENCES Osoby. Nagroda varchar(15)

) Stworzona dzięki wykonaniu tego polecenia tabela Nagrody ma ustawiony klucz obcy na polu IdNagrodzonego, który odnosi się do klucza głównego tabeli Osoby. Wyma­ gane jest, aby klucz obcy i klucz główny obejmowały taką samą liczbę pól, a także by były zgodne co do typu. Powoduje to, że do pola klucza obcego możliwe jest wpi­ sanie tylko takich wartości, które są już wpisane do pola klucza głównego tabeli nad­ rzędnej (nagrodzony może być tylko zatrudniony pracownik — mający przypisany klucz główny). Jeśli nie zastosowano żadnych dodatkowych ograniczeń, możliwe jest jednak ustawienie w tym polu wartości NULL — nagroda przyznana nie wiadomo której osobie. Aby uniemożliwić taki przypadek, na polu klucza obcego ustanawia się dodatkowe ograniczenie NOT NULL. Możliwe jest ustawienie klucza obcego do pola tabeli nadrzędnej niebędącego kluczem głównym (mało przydatne praktycznie, ale dopuszczalne) pod warunkiem, że pole to zawiera wartości unikalne — UNIQUE.

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

131

CREATE TABLE Nagrody ( IdNagrody in t PRIMARY KEY . IdNagrodzonego in t. CONSTRAINT klucz FOREIGN KEY (IdNagrodzonego) REFERENCES Osoby(IdOsoby). Nagroda varchar(15)

) W naszym przykładzie posłużono się przypadkiem, gdzie relacja dotyczy pola klucza IdNagrodzonego, ale równie dobrze możemy sobie wyobrazić, że w naszej tabeli Osoby stworzone zostało unikatowe pole PESEL, do którego możemy odnieść klucz obcy. Możliwe jest również ustawienie klucza obcego opartego o więcej niż jedno pole, np. o parę pól. CREATE TABLE InnaX ( Nr in t . Liczba in t . CONSTRAINT klucz FOREIGN KEY(Nr.Liczba) REFERENCES InnaY (Nr.Liczba)

) Warunkiem jest, aby w nadrzędnej tabeli InnaY został ustawiony klucz podstawowy na odpowiadającej parze pól. CREATE TABLE InnaY ( Nr in t. Liczba in t. CONSTRAINT numer PRIMARY KEY(Nr.Liczba)

) lub przynajmniej para odpowiednich pól była unikatowa CREATE TABLE InnaY ( Nr in t. Liczba in t. CONSTRAINT numer UNIQUE(Nr.Liczba)

)

Uwaga

Nie jest możliwe stworzenie klucza obcego do tabeli połączonej.

W tym miejscu konieczne jest przedstawienie kilku uwag autora do tego, co niebacz­ nie w MS Access zostało nazwane relacjami. Jeśli wykonamy powyższe zapytania, to w narzędziu zwanym w MS Access relacje (wg autora powinno być raczej „diagram bazy danych”) po dodaniu tabel InnaY oraz Inna pojawi się następujący schemat — ry­ sunek 3.13.

132

Bazy danych. Pierwsze sta rcie

Rysunek 3.13, Reprezentacja graficzna klucza obcego — wymuszanie więzów

Pojawienie się symbolu złączenia {1:oo — jeden do wielu na rysunku 3.13) odpowiada w oknie właściwości ustawieniu wymuszania więzów integralności (rysunek 3.14). Jest to graficzne odwzorowanie ustawienia klucza obcego w tabeli podrzędnej, odnoszącego się do pola (pól) tabeli nadrzędnej. Trudno tu więc mówić o relacjach, które z definicji są podzbiorem listy uporządkowanej na zbiorach atrybutów. Rysunek 3 .1 4 . Ilustracja złączenia wielokrotnego

Jeśli zaniechamy ustawienia klucza obcego (czyli nie będziemy wymuszali więzów in­ tegralności), obraz złączenia między tabelami nie będzie zawierał określenia jego typu (rysunek 3.15). W takim przypadku możliwe jest wpisanie do tabeli podrzędnej wartości niewystępujących w tabeli nadrzędnej. Możliwe jest również usuwanie danych z obu tabel oraz modyfikowanie wartości złączonych pól bez względu na to, czy istnieją po­ wiązane między sobą dane, czy też nie. Rysunek 3 .1 5 . Reprezentacja graficzna złączenia wielokrotnego bez wymuszania więzów

Jeśli po ustawieniu klucza obcego do tabeli podrzędnej wpiszemy kilka rekordów, to usunięcie rekordu z tabeli nadrzędnej będzie możliwe tylko wtedy, gdy nie ma on powiązanych ze sobą rekordów w tabeli podrzędnej. Jeśli takie rekordy istnieją, ko­ nieczne jest w pierwszej kolejności usunięcie ich z tabeli podrzędnej, a dopiero potem usunięcie rekordu z tabeli nadrzędnej. Jak widać na rysunku 3.14, przedstawiającym właściwości złączenia między tabelami, możliwe jest ustawienie również kaskadowe­ go usuwania oraz kaskadowej aktualizacji rekordów. W takim przypadku możliwe jest usunięcie rekordu z tabeli nadrzędnej, ale pociąga ono za sobą automatyczne usunięcie wszystkich powiązanych rekordów tabeli podrzędnej. Możliwa jest również

Rozdział 3. ♦ Strukturalny Język zapytań SQL w wersji !VIS J e t SQL

133

zmiana w tabeli nadrzędnej wartości łączonego pola, gdyż odpowiednie wartości w polu klucza obcego zostaną również automatycznie zmienione (zsynchronizowane). Z po­ ziomu MS Jet SQL ustawienie kaskadowego usuwania czy tez aktualizacji jest niemoż­ liwe — dopiero silniejsze środowiska oparte o SQL standard 92 umożliwiają ustawienie tej właściwości. Z praktycznego punktu widzenia bezpieczniejsze jest nieustawianie ka­ skadowego (automatycznego) usuwania połączonych rekordów oraz wymuszanie kaska­ dowej aktualizacji tych pól. Kolejnym zastosowaniem wymuszenia więzów integralności jest realizacja złączenia typu jeden do jednego. Konieczność zastosowania takiego rozwiązania pojawia się wtedy, gdy z jakichś przyczyn (np. poziomu poufności informacji lub zbyt dużej liczby kolumn w definicji tabeli) musimy dokonać podziału danych opisujących tę samą rzecz/osobę na dwie różne tabele. Przeanalizujmy to na przykładzie tabeli DaneDod: Create table DaneDod ( IdOsoby in t PRIHARY KEY REFERENCES Osoby( IdOsoby). Opis varchar(15)

) Jak widać, referencje (wymuszenie więzów) w tabeli DaneDod zostały ustanowione dla pola klucza podstawowego. Należy zwrócić również uwagę na to, że odnoszą się one do pola klucza podstawowego w tabeli Osoby. Powoduje to, że w tabeli DaneDod wartości klucza głównego mogą być tylko tymi wartościami, które zostały uprzednio wpisane jako klucz główny do tabeli Osoby. Ze względu na właściwości klucza głów­ nego wartości te nie mogą zarówno się powtarzać, jak i przyjmować wartości NULL. Trudno w przypadku takiego złączenia mówić o nadrzędności lub podrzędności któ­ rejkolwiek z połączonych w ten sposób tabel. Zwłaszcza że możliwe jest ustanowienie integralności „zwrotnej” od tabeli Osoby do tabeli DaneDod, co zostanie pokazane w następnym podrozdziale przy omawianiu modyfikacji struktury tabel. Nie jest bowiem możliwe stworzenie więzów do nieistniejącej tabeli. Któraś z tabel musi zostać utwo­ rzona wcześniej. Kolejny przykład zastosowania wymuszenia więzów dotyczy realizacji tzw. samozłączenią czyli wymuszenia zgodności danych dla pól należących do tej samej tabeli. Prze­ śledzimy ten problem dla rozszerzonej definicji tabeli Osoby. CREATE TABLE Osoby (IdOsoby autoincrement PRIMARY KEY. IdDzialu in t, CONSTRAINT fk FOREIGN KEY (IdDzialu) REFERENCES D zia ly(Id D zialu). Nazwisko varchar(15). Imię varchar(15). RokUrodź in t. Wzrost r e a l. IdSzefa in t. CONSTRAINT nad FOREIGN KEY (IdSzefa) REFERENCES Osoby(IdOsoby)

) Załóżmy, że w naszej tabeli musimy przechowywać nie tylko informacje dotyczące każdego z pracowników, ale również strukturę podległości w firmie — kto jest czyim przełożonym, szefem. Dlatego w definicji tabeli dodane zostało pole IdSzefa. Jednak przełożony jest również pracownikiem naszej firmy, stąd informacja o nim będzie

Bazy danych. Pierwsze starcie

134

zawierała się w tej samej tabeli. Stąd dla tego pola został ustawiony klucz obcy z od­ wołaniem się do pola klucza głównego tej samej tabeli. Gwarantuje to, że przełożonym pracownika może być tylko pracownik firmy. Natomiast ze względu na właściwości ograniczenia klucza obcego (dopuszczalna wartość NULL) naczelny szef (szef szefów) w polu IdSzefa może nie mieć podanej żadnej wartości (czasami stosuje się metodę, że szefem naczelnego jest on sam — ta sama wartość klucza głównego i obcego Id Osoby=IdSzefa). Zagadnienie przechowywania grafów (w naszym przypadku mamy do czynienia z drzewem — graf skierowany, acykliczny) w relacyjnej strukturze danych jest dość złożonym problemem. Jeszcze bardziej kłopotliwe jest manipulowanie danymi w takiej strukturze. Usunięcie osoby, która miała jakiś podwładnych, a ci swoich pod­ władnych. najczęściej pociąga za sobą konieczność modyfikacji danych w wielu re­ kordach. To samo dotyczy degradacji czy też awansu w strukturze. Jeszcze trudniejsze zadania związane są z przechowywaniem grafów cyklicznych (sieci), wymaga to z re­ guły tworzenia pomocniczych tabel łączących. Trudność zagadnienia może również wzrosnąć na skutek konieczności synchronizowania drzew (przełożony nie może być pracownikiem działu podległego względem działu, w którym pracuje podwładny) lub też wynikać z nieplanarności grafu (grafu nie można przedstawić bez przecinania się krawędzi na płaszczyźnie), co pojawia się np. przy analizie połączeń między wieloma miejscami z zastosowaniem różnych środków transportu, np. samochodu, kolei, sa­ molotu etc.

Modyfikowanie struktury tabel Załóżmy, że stworzyliśmy tabelę o nazwie Nowa o dwóch polach, wykonując poniższe zapytanie: CREATE TABLE Nowa

( Nr in t. Liczba in t

) Chcemy, aby do tabeli została dodana kolejna kolumna o nazwie Kod. W tym celu możemy wykonać zapytanie modyfikujące strukturę o postach ALTER TABLE Nowa ADD COLUMN Kod in t

Nowa kolumna będzie jak widać typu calkowitoliczbowego — in te g e r ( in t) . Jeśli zde­ cydujemy się na zmianę typu danych dla tej kolumny, to możemy wykonać zapytanie: ALTER TABLE Nowa ALTER COLUMN Kod varchar(l)

Zmiana typu danych w przypadku, kiedy kolumna nie zawiera danych (albo tabela jest pusta, albo w tej kolumnie występują tylko wartości nieokreślone NULL), jest zaw­ sze możliwa, bez względu na typ wyjściowy i docelowy. Chyba że jeden z typów jest LOB (Large Object Binary — Nota. Obiekt). Natomiast gdy w kolumnie są już dane, zmiana typu jest wtedy możliwa, gdy możliwa jest konwersja typu wartości pól typu wyjściowego do wartości typu docelowego. Przedstawiona tutaj konwersja od typu liczbowego do typu znakowego, zgodnie z tym, co powiedziano wcześniej, jest zaw­ sze możliwa. Konwersja odwrotna (typ znakowy —> liczba) jest możliwa tylko wtedy,

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS Je t SQL

135

gdy pole tekstowe zawiera poprawnie wpisane liczby. Access nie sygnalizuje w takim przypadku błędu przetwarzania, dokonuje zamiany typu danych, przy czym wartości pola, które nie dają się przekształcić na typ docelowy, są ustawiane na wartość nie­ określoną NULL. Czyli zamiana typu danych może prowadzić do utraty' części danych. Ponieważ nie jest generowane żadne ostrzeżenie, tego typu zapytanie powinno być wykonywane ze szczególną ostrożnością i rozwagą. Według podobnych zasad możemy dodać do tabeli ograniczenie: ALTER TABLE Nowa ADD CONSTRAINT Uni UNIQUE(Kod)

W tym przykładzie dodajemy ograniczenie unikalności na kolumnie Kod, które zosta­ nie nazwane Uni. Jeśli tabela jest pusta, dodanie ograniczenia jest zawsze możliwe. Natomiast w przypadku tabeli wypełnionej danymi zapytanie wykona się wtedy, gdy wartości kolumny (kolumn), na której ustawiamy to ograniczenie, będą spełniać to ograniczenie. W naszym przypadku muszą być unikatowe (nieliczone są wartości nie­ określone NULL, które mogą się powtarzać). Jeśli dane nie spełniają wymogów ograni­ czenia, generowany jest komunikat o błędzie i zapytanie nie będzie wykonane. Załóżmy, że w tym stanie chcielibyśmy usunąć kolumnę Kod, wykonując zapytanie: ALTER TABLE Nowa DROP COLUMN Kod

Okaże się, że został wyświetlony komunikat o błędzie, ponieważ usiłujemy usunąć ko­ lumnę należącą do indeksu (dotyczy to ograniczeń typu UNIOUE, PRIMARY KEY, FOREIGN KEY). W celu usunięcia kolumny najpierw musimy usunąć ograniczenie (ograniczenia) z nią związane, na przykład tak, jak pokazano niżej: ALTER TABLE Nowa DROP CONSTRAINT Uni

Dopiero następnie możemy usunąć kolumnę, wykonując wcześniejsze zapytanie. Przy wykonywaniu tego zapytania nie jest generowany żaden komunikat, co wymaga za­ chowania szczególnej rozwagi przez programistę. Usunięte podczas usuwania kolumny dane nie mogą być odzyskane, chyba że z kopii pliku bazy. Jeśli natomiast chcemy usunąć tabelę (definicję oraz zawartość), możemy posłużyć się zapytaniem; DROP TABLE Nowa

Ostatnim elementem omawianym przy okazji MS Jet SQL jest tworzenie indeksów, czyli elementów porządkujących. Wykonanie poniższego zapytania powoduje stworzenie indeksu na kolumnie Liczba tabeli Nowa: CREATE INDEX zzz ON Nowa(Liczba)

Tak określony indeks pozwala na istnienie w polu, na którym został określony, po­ wtarzających się wartości. Powoduje on ponadto stworzenie niewidocznej dla użyt­ kownika kolumny, która numeruje rekordy w kierunku rosnących wartości pola.

136

Bazy danych. Pierwsze starcie

Oprócz tego możemy stworzyć indeks unikatowy (w innych środowiskach nazywany grupującym), który7wymusza brak powtarzających się wartości pola. CREATE UNIOUE INDEX zzz ON Nowa(Liczba)

Jeśli na tabeli istnieje jeden indeks unikatowy (grupujący), to rekordy są fizycznie przestawiane w kierunku rosnących wartości pola indeksu. Można przekonać się o tym, otwierając tabelę lub wykonując zapytanie wybierające bez sortowania dla indeksów unikatowych ustanowionych dla różnych kolumn (pól) tabeli. W większości systemów zarządzania bazą danych w jednej tabeli może istnieć co najwyżej jeden indeks uni­ katowy. W MS Access dopuszczalne jest stworzenie większej ich ilości. Wtedy ten, który jest usytuowany na wcześniejszej (patrząc według definicji tabeli) kolumnie, porządkuje rekordy, natomiast kolejne ustanawiają tylko niewidoczną kolumnę z nu­ meracją jak przy zwykłym (nieunikatowym) indeksie. Możliwe jest również ustano­ wienie indeksu na więcej niż jednej kolumnie, analogicznie jak to miało miejsce przy definicji ograniczeń (UNIOUE, PRIMARY KEY, FOREIGN KEY). CREATE UNIOUE INDEX

yyy

ON Nowa(Liczba. Nr)

W przypadku stworzenia indeksu unikatowego na parze pól wymagane jest, aby para wartości była niepowtarzalna, natomiast w obrębie pojedynczego pola wartości mogą powtarzać się. W takim przypadku o kolejności rekordów decyduje kolejność pól w definicji indeksu. Najpierw sortujemy względem rosnących wartości pierwszego z pól, a dopiero w obrębie grupy rekordów o tej samej wartości pierwszego pola wzglę­ dem pola drugiego (reguła podobna jak przy sortowaniu — klauzula ORDER BY). Jeśli chcemy usunąć którykolwiek z omawianych typów indeksów, możemy posłużyć się zapytaniem: DROP INDEX

zzz

ON Nowa

W przypadku braku jakiegokolwiek indeksu unikatowego rekordy są przechowywane zgodnie z kolejnością ich wpisywania. Stosowanie indeksów pozwala na przyspieszenie wykonywania zapytań wybierających. Dotyczy to zarówno sortowania, jak i filtrowania wyników zapytania. W przypadku sortowania wystarczy bezpośrednio skorzystać z numeratora, który tworzy indeks, lub w przypadku indeksu unikatowego wyprowadzić rekordy tak, jak są zapisane. Przy filtrowaniu korzysta się z przedziałów numeratorów wierszy, które spełniają kryterium. Na przykład wybranie rekordów, które mieszczą się w przedziale „od do”, może się ograniczyć do znalezienia numeru w indeksie dolnego ograniczenia i górnego ograni­ czenia i wyświetlenia wszystkich rekordów o numerze z tego przedziału. Szczególną rolę odgrywają indeksy przy tworzeniu złączeń (zapytania do wielu połączonych lub skorelowanych tabel). Ponieważ większość złączeń wykonywana jest na polach klu­ cza głównego i klucza obcego, indeksy na polach z tymi ograniczeniami tworzone są automatycznie. Na kluczu głównym — unikatowy, na kluczu obcym — zwykły (z powtórzeniami). Dodatkowo automatycznie indeks tworzony jest na polu z ograni­ czeniem UNIQUE, jak to pokazano przy dodawaniu i usuwaniu ograniczeń. Natomiast w przypadku zapytań modyfikujących dane (INSERT, UPDATE, DELETE) indeksy spowal­ niają przetwarzanie, gdyż konieczne jest „przenumerowanie” lub reorganizacja tabeli po każdej dokonanej zmianie. Wymagany jest dodatkowy czas na wykonanie tych

Rozdział 3. ♦ Strukturalny język zapytań SQL w wersji MS J e t SQL

137

operacji. Dlatego zalecane jest, aby tworzyć tylko niezbędną liczbę indeksów. Na szczę­ ście dla większości programistów różnice w czasie przetwarzania są widoczne tylko dla bardzo dużych tabel. Rzadkie, ale możliwe do pomyślenia jest połączenie jeden do jednego wraz z wymusze­ niem zgodności wierszy na polach klucza głównego. Przykładowe zapytanie tworzące ta­ belę Osoby ze wszystkimi dodatkowymi polami może mieć postać jak poniżej. W definicji pominięto klucz podstawowy na polu IdOsoby oraz klucz obcy na polu IdSzefa. CREATE TABLE Osoby (IdOsoby autoincrement . IdDzialu in t. CONSTRAINT fk FOREIGN KEY (IdDzialu) REFERENCES D ziały!IdD zialu). Nazwisko varchar(15). Imię varchar(15). RokUrodz in t. Wzrost re a l. IdSzefa in t )

Pamiętajmy o tym, że referencja musi dotyczyć pola indeksowanego. Klucz podstawo­ wy z natury ma ustawione indeksowanie unikatowe na kolumnie — wszystkich kolum­ nach wchodzących w jego skład. W przykładzie ograniczmy się jedynie do stworzenia in­ deksu unikatowego na polu IdOsoby. CREATE UNIOUE INDEX U_Ind ON Osoby(IdOsoby)

Teraz możliwe jest utworzenie tabeli z dodatkowymi danymi pracownika (np. dane poufne). W przykładzie ograniczymy się jedynie do poła klucza z referencją do tabeli Osoby oraz pola Opis symbolizującego wszystkie niekluczowe pola mogące pojawić się w tej tabeli. Należy zwrócić uwagę, że odniesienie do pola tabeli zewnętrznej w defi­ nicji klucza podstawowego jest tożsame z jej definicją przy kluczu obcym. CREATE TABLE DaneDod (IdOsoby in t PRIMARY KEY REFERENCES Osoby( IdOsoby). Opis varchar(15)

) Dodatkowym elementem jest realizacja samozłączenia na polu IdSzefa dzięki zasto­ sowaniu polecenia SQL ALTER TABLE: ALTER TABLE Osoby ADD CONSTRAINT ffk FOREIGN KEY (IdSzefa) REFERENCES Osoby( IdOsoby)

Ostatni z prezentowanych w tym podrozdziale przykładów zasługuje raczej na miano czysto akademickiego. Cłiodzi o to bowiem, aby uzyskać zwrotną referencję między dwoma polami tej samej tabeli. Stwórzmy więc przykładową tabelę zawierającą dwa pola całkowitoliczbowe. CREATE TABLE Dziwna (Pierwsza in t. Druga in t)

Bazy danych. Pierwsze sta rcie

138

Jak to pokazano wcześniej, klucz obcy może być połączony (referencja) tylko z po­ lem, na którym stworzony został indeks unikatowy. Utwórzmy odpowiednie indeksy na każdym z pól przykładowej tabeli. CREATE UNIOUE INDEX I_pierwsza ON Dziwna (Pierwsza) CREATE UNIOUE INDEX I_druga ON Dziwna (Druga)

Utwórzmy, przez wykonanie instrukcji ALTER TABLE, odnośnik od pierwszej do drugiej kolumny tabeli. W tym przypadku nie jest konieczne określenie rodzaju ograniczenia, wystarczy określić referencje. W praktyce odpowiada to niejawnemu ustawieniu klucza głównego na tym polu: ALTER TABLE Dziwna ALTER COLUMN Pierwsza in t REFERENCES Dziwna(Druga)

Możemy także w sposób jawny określić typ ograniczenia, np. jako klucz obcy. Z punktu widzenia późniejszego zachowania tabeli nie wnosi to żadnych zmian. ALTER TABLE Dziwna ADD CONSTRAINT hh FOREIGN KEY (Pierwsza) REFERENCES Dziwna(Druga)

Ustanowienie drugiej referencji wymaga już ustalenia typu ograniczenia na kluczu ob­ cym. Wynika to z faktu, że na tabeli może zostać założony tylko jeden klucz podstawowy — nawet wtedy, gdy nie jest to wykonywane w sposób jawny. ALTER TABLE Dziwna ADD CONSTRAINT gg FOREIGN KEY (Druga) REFERENCES Dziwna(Pierwsza)

Skutkiem wykonania takiego zwrotnego złączenia jest to, że zawartość obu kolumn musi być dokładnie taka sama. Zakres praktycznego znaczenia takiego rozwiązania jest dość niewielki. Można go wykorzystać jako metodę weryfikacji zgodności danych dokonywanąjuż na poziomie definicji tabeli. Mimo że ten przykład nie pokazuje waż­ nego zastosowania języka zapytań SQL, to po raz kolejny daje dowód jego siły i pla­ styczności pomimo pozornej prostoty i wielu ograniczeń. Pomimo dużej liczby narzędzi wizualnych do tworzenia różnego rodzaju zapytań lub możliwości korzystania z kreatorów nie wszystkie czynności mogą być wykonane bez odwołania się do znajomości SQL. Dotyczy to zarówno zapytań wybierających, mo­ dyfikujących dane, jak i tworzących lub modyfikujących strukturę bazy — tabele. Za­ pytania SQL mogą być ponadto wykorzystywane przy przetwarzaniu z poziomu koń­ cówki klienta, przy budowie formularzy czy raportów. Tym zagadnieniom będzie poświęcony kolejny rozdział. Ponadto przy dużej biegłości w posługiwaniu się języ­ kiem SQL zapytania tworzone bez udziału kreatorów stają się bardziej czytelne dla programisty.

Rozdział 4.

Zastosowanie języka zapytań SQL z poziomu formularzy Język zapytań SQL może nam nie tylko posłużyć do definiowania zapytań zapisywa­ nych w odpowiednim kontenerze bazy danych. Zapytania mogą być wykorzystywane bezpośrednio z poziomu końcówki klienta — formularza. Zastosowanie ich może być wielorakie. W dość ogólny sposób można powiedzieć, że mogą stanowić dynamiczne źródła danych dla elementów klienta (formularze, listy) lub być wykorzystywane do modyfikowania danych na podstawie informacji zawartej po stronie klienta (w formula­ rzu). Zakres ten oczywiście nie wyczerpuje wszystkich potencjalnych możliwości, ale daje ogólne pojęcie o potencjalnych możliwościach zastosowania.

2

astl®s©wainiń© za p yftam wyy@[rajją©y©l]n

J a t o cayoTiaBm0ffiziii]y©llii źrścflefl cSamycIfti Jednym z potencjalnych zastosowań SQL po stronie formularza jest możliwość dy­ namicznej zmiany zawartości kontrolki w zależności od potrzeb. Przeanalizujmy to zastosowanie na prostym przykładzie. Wyobraźmy sobie, że nasza firma organizuje tur­ niej, np. piłki nożnej. W turnieju tym będą brały udział drużyny reprezentujące poszcze­ gólne działy. Stwórzmy formularz pozwalający na dobieranie drużyn parami — w tym celu na formularzu umieszczamy dwa pola kombi, których źródłem rekordów jest ta­ kie samo zapytanie wybierające SELECT IdDzialu. Opis FROM Działy:

140

Bazy danych. Pierwsze sta rcie

Dla czytelności nadajmy polom kombi nazwy Gosp i Gosc (Gospodarze, Goście). Po­ nadto wprowadźmy trzecie pole kombi, którego zawartością będzie lista nazwisk i imion pracowników. Polu temu nadajmy nazwę Zawodnik. Wszystkie trzy pola zwracają przez wartość klucz podstawowy odpowiedniej tabeli. SELECT IdOsoby. Nazwisko & ’ ‘ & Imię FROM Osoby:

Jeśli teraz otworzymy formularz, okaże się, że możliwy jest mecz między tą samą drużyną. Naszym zadaniem jest teraz uniemożliwienie takiej sytuacji. Czyli jeśli z pierw­ szej listy rozwijalnej wybrana zostanie drużyna A, to nie może być wyświetlona na drugiej liście rozwijalnej, i odwrotnie — wybranie z drugiej listy rozwijalnej drużyny B spowoduje, że nie będzie ona dostępna na pierwszej liście. Dodatkowo chcemy, aby w' trzecim polu kombi dostępne były tylko dane pracowników z działów rozgrywają­ cych mecz. Docelowo będziemy chcieli uzyskać efekt taki, że trzecie z pól kombi bę­ dzie zawierało listę strzelców bramek w rozgrywanym właśnie meczu. Zadanie to zrealizujemy przez napisanie kodu obsługi zdarzenia Po Aktualizacji dla obu pól kombi (listing 4.1 - 4.2). Listing 4 .1 . Definicja procedury obsługi zdarzenia Po aktualizacji dla pola kombi Gosc Private Sub Gosc_Afterllpdate() zap = "SELECT IdDzialu. Opis FROM Działy WHERE IdDzialu <>“ & _ Me.Gosc Gosp.RowSource = zap zap = "SELECT IdOsoby, Nazwisko & ’ ’ & Imię FROM Osoby " & _ "WHERE IdDzia 1u=” & He.Gosc & " OR IdDzialu^” & Me.Gosp Zawodnik.RowSource = zap Me.Recalc End Sub Listing 4.2. Definicja procedury>obsługi zdarzenia Po aktualizacji dla pola kombi Gosp Private Sub Gosp_AfterUpdate() zap = "SELECT IdDzialu. Opis FROM Działy WHERE IdDzialu o " & Me.Gosp Gosc.RowSource = zap zap = "SELECT IdOsoby. Nazwisko & 1 ’ & Inie FROM Osoby ” & _ "WHERE IdDzialu=" & Me.Gosc & " OR IdDzialu=" & Me.Gosp Zawodnik.RowSource = zap Me.Recalc End Sub

Głównym elementem kodu jest zdefiniowanie zmiennej zawierającej dynamiczną po­ stać zapytania wybierającego. Dla definicji drużyn klauzula WHERE zawiera wyrażenie zapewniające, że na liście są drużyny różne od wybranej na liście Gosc. W drugim przypadku zmienna zawiera zapytanie wybierające z warunkiem, że pracownik pocho­ dzi z jednego z dwóch działów wybranych na listach drużyn. Należy zwrócić uwagę, że operator logiczny OR jest elementem łańcucha oraz poprzedzająca go spacja jest obowiązkowa. Pominięcie znaku spacji spowoduje „sklejenie” elementów warunku IdDzialu=10R IdDzi a 1u=2, co zaowocuje błędem przetwarzania zapytania. Wartość zmiennej zawierającej zapytanie jest kolejno podstawiana jako źródło wierszy (wła­ ściwość .RowSource) dla odpowiednich pól kombi.

Rozdział 4. ♦ Z astosow anie języka zapytań SQL z poziomu formularzy

141

W przypadku obsługi zdarzenia drugiego z pól kombi zmienia się tylko odwołanie do wartości pierwszej z list i podstawienie zapytania jako źródła do drugiej. Reszta kodu jest taka sama. Zaprezentowane rozwiązanie jest wielce ułomne, pozwala bowiem rozegrać tylko je ­ den mecz, a z listy strzelców daje się wybrać najwyżej jednego zawodnika. Co więcej, dane zawarte w formularzu nie są nigdzie zapisywane, czyli zamknięcie i powtórne otwarcie formularza powoduje, że nie są na nim wyświetlone żadne dane. Wynika to z faktu, że zbudowany został formularz niezależny — nieoparty o żadne źródło danych. Problem ten zostanie rozwiązany dzięki wprowadzeniu dwóch dodatkowych tabel: Mecze (rysunek 4.1) i Bramki (rysunek 4.2). Pierwsza z nich, wzorem prezentowanej w części poświęconej zapytaniom SQL i zastosowaniu w nich operatora UNION, poza polem klucza zawiera informacje o grających drużynach (w postaci identyfikatorów tych drużyn) oraz dacie spotkania. Pola IdGosp oraz IdGosc są kluczami obcymi od­ noszącymi się do pola IdDzialu w nadrzędnej tabeli Działy. Rysunek 4.1. Definicja pól tabeli Mecze

| B Mecze: Tabela Ma;wa pola IdMeczu □ IdGoso IBS IdGosc i _ Data

m Rysunek 4.2. Definicja pól tabeli Bramki

1

1 & B ra m k i: Tabela Nazwa bota

!

Tvó danych R 1 Autonumerowar Liczba Liczba Data/Godzina

IdMeczu IdZawodnika Minuta

Tyo danych Autnnumerowanie Liczba Uczba Liczba

1

Ponieważ oba pola opisujące grające drużyny są kluczami obcymi, wygodne jest zde­ finiowanie dla nich odnośników do tabeli nadrzędnej. SELECT IdDzialu. Opis FROM Działy:

Tabela Bramki poza polem klucza zawiera identyfikator meczu, w którym padła bramka: identyfikator zawodnika, który bramkę zdobył, oraz informację o minucie meczu, w której bramka została zdobyta. Ponieważ pole IdZawodnika stanowi klucz obcy, wygodne jest zbudowanie na nim odnośnika w postaci pola kombi do nadrzędnego pola IdOsoby z tabeli Osoby. SELECT IdOsoby. Nazwisko & ' ' & Imię FROM Osoby:

Jeżeli w oparciu o tabele Mecze i Zawodnicy zbudujemy formularz z podformularzem (pamiętając o tym, że aby skorzystać z pomocy kreatora, konieczne jest połączenie tabel za pomocą pól IdMeczu z obu tabel), to tak jak w poprzednio realizowanym formularzu niezwiązanym konieczne jest oprogramowanie obsługi zdarzeń. Po pierw­ sze przy przechodzeniu między rekordami nadrzędnego formularza konieczne jest, aby zmieniane było źródło wierszy dla pola IdZawodnika w podformularzu. Tak aby niezależnie od tego, których drużyn mecz analizujemy, jako strzelcy bramek byli do­ stępni tylko zawodnicy drużyn znajdujących się na formularzu.

142

Bazy danych. Pierwsze sta rcie

Wykonanie tego zadania wymaga oprogramowania zdarzenia Przy bieżącym formula­ rza (listing 4.3). Zdarzenie to jest wywoływane przy każdej zmianie rekordu, również w momencie otwierania formularza, czyli przejścia do pierwszego rekordu z zestawu rekordów. Przypisanie źródła wierszy do pola kombi znajdującego się w formularzu nie jest już tak proste jak w przypadku formularza niezwiązanego. Wymaga odwoła­ nia się do podformularza Bramki traktowanego jako kontrolka (stąd właściwość FORM), a następnie do kontrolki tego podformularza o nazwie IdZawodnika (stąd Controls. ^►Item( "IdZawodnika")), która dopiero posiada właściwość RowSource, którą stanowi zmienna zawierająca zapytanie wybierające. Listing 4.3. Procedura obsługi zdarzenia Prz}’ bieżącym dla formularza opartego o tabelą Mecze P nvate Sub Form_Current() zap = "SELECT IdOsoby. Nazwisko & ' ’ & Imię EROM Osoby ” & _ "WHERE ldDzialu=" & Me.IdGosc & " OR IdDzialu=" & Me.IdGosp Me.Bramki.Form.Controls.Item(“IdZawodnika").RowSource = zap Me.Recalc End Sub

Oprogramowania zdarzenia Po aktualizacji wymagają również pola kombi w formu­ larzu (listingi 4.4 i 4.5), tak aby definiując drużyny grające mecz, nie można było do­ prowadzić do rozgrywki między tą samą drużyną, oraz aby tak samo jak w poprzednim przypadku wymusić odpowiednią zawartość list zawodników (strzelców bramek). Listing 4 .4 . Procedura obsługi zdarzenia Po aktualizacji dla pola IdGosc z formularza opartego o tabelą Mecze_____________________________________________________________________________ Private Sub IdGosc_AfterUpdate() zap = "SELECT IdDzialu. Opis FROM Działy WHERE IdDzialu o " & _ Me.IdGosc IdGosp.RowSource - zap zap = "SELECT IdOsoby. Nazwisko & ' ‘ & Imię FROM Osoby " & _ "WHERE IdDzialu=" & Me.IdGosc & " OR IdDzialu=" & Me.IdGosp Me.Bramki.Form.Controls.Item("IdZawodnika”).RowSource » zap Me.Recalc End Sub Listing 4.5, Definicja źródła rekordów dla odnośnika ir postaci pola kombi Prw ate Sub IdGosp_AfterUpdate() zap = "SELECT IdDzialu. Opis FROM Działy WHERE IdDzialu <>" & Me.IdGosp IdGosc.RowSource = zap zap = "SELECT IdOsoby. Nazwisko & ’ ' & Imię FROM Osoby ” & _ "WHERE IdDzialu=" & Me.IdGosc & " OR IdDzialu=" a Me.IdGosp Me.Bramki.Form.Controis.Item<"IdZawodnika") .RowSource = zap Me.Recalc End Sub

Oba pola kombi formularza mają analogiczne procedury obsługi zdarzeń, różniące się tylko odwołaniem do innego pola w definicji warunku dla pola kombi i podstawieniem zapytania jako źródła danych do przeciwnej listy rozwijalnej. O tych procedurach możemy powiedzieć, że są antysymetryczne.

Rozdział 4. ♦ Z astosow anie języka zapytań SQL z poziomu formularzy

143

Pozostaje nam do rozwiązania jeszcze jeden problem. Możemy przyjąć, że bramka jest przyznawana tej drużynie, której zawodnik ją zdobył. Możemy założyć, że nie ma bramek samobójczych. Założenie to jest zgodne z przepisami gry w piłkę nożną gdzie tzw. bramkę samobójczą przypisuje się ostatniemu z zawodników drużyny przeciw­ nej, który dotknął piłki. Jeżeli nie jest możliwe wskazanie takiego zawodnika (po wzno­ wieniu gry bramkarz sam sobie wrzucił piłkę do bramki), bramkę przypisuje się kapi­ tanowi drużyny przeciwnej. Dla tak przyjętych założeń możliwe jest na podstawie danych zawartych w formularzu i podibrmularzu obliczenie bieżącego wyniku meczu. Rozwiązanie tego zadania może być wielorakie, na tym etapie zastosujemy pomocniczy podformularz. W tym celu zbudujmy formularz o nazwie Wynik, dla którego wstępne, predefiniowane źródło danych ma postać zapytania. SELECT SUM(Gosp) AS BGosp. SUM(Gosc) AS BGosc FROM (SELECT COUNT( IdZawodnika) AS Gosp . 0 AS Gosc FROM Bramki INNER JOIN Osoby ON Bramki. IdZawodnika = Osoby.IdOsoby UNION ALL SELECT 0 AS Gosp. C0UNT(IdZawodnika) AS Gosc FROM Bramki INNER JOIN Osoby ON Bramki. IdZawodnika = Osoby.IdOsoby) AS xxx:

Podstawą jego jest unia dwóch zapytań wybierających: pierwsze z nich liczy zawod­ ników strzelających bramki, a na drugiej pozycji ustawia wyrażenie o wartości zero, drugie wykonuje operację odwrotną— na pierwszej pozycji ustawia zero, a na dru­ giej zlicza zawodników. Polom nadano odpowiednie aliasy. Źródłem rekordów dla obu zapytań składowych jest złączenie tabel Bramki i Osoby. Tak skonstruowane za­ pytanie zawsze zwraca dwa rekordy. Na najwyższej warstwie pola są sumowane, co powoduje, że wyświetlany będzie tylko jeden rekord o dwóch polach. Sumowanie to jest zabiegiem formalnym wobec faktu, że jeden z dwóch składników obu sum jest zerem, mającym za zadanie redukcję do jednego liczbę zwracanych rekordów. Cała ta złożona konstrukcja ma posłużyć temu, aby w wersji sparametryzowanej w pierwszym zapytaniu było dokonywane filtrowanie względem identyfikatora drużyny gospodarzy, a w drugim — identyfikatora gości. To uzasadnia stosowanie operatora UNION oraz złączenia tabeli Bramki i Zawodnicy, gdyż dopiero w tej drugiej możemy odwołać się do pola IdDzialu będącego odpowiednikiem identyfikatora drużyny. W obu składni­ kach wystąpi filtr względem identyfikatora meczu, co wydaje się oczywiste. Utworzenie takiego zapytania ma na celu przede wszystkim ułatwienie późniejszej jego parametryzacji. Zawsze łatwiej „zapanować” nad postacią statyczną zapytania— utwo­ rzyć, testować j ą — niż nad jego dynamicznym odpowiednikiem. Ważnym elementem z punktu widzenia niniejszej książki jest dydaktyczna wartość takiej formy zapytania. Natomiast czysto formalną korzyścią płynącą ze zbudowania zapytania jest możli­ wość korzystania z kreatora do tworzenia formularza lub skorzystania z listy pól przy „ręcznym” jego budowaniu. Zysk ten nie ma specjalnego znaczenia w przypadku pro­ gramistów o dużym doświadczeniu w budowaniu aplikacji. Teraz pozostaje tylko obsługa zdarzenia aktualizującego zawartość formularza Wynik (listing 4.6). Ponieważ formularz ten jest podformularzem formularza Mecze, posta­ nowiono dokonać przeliczenia wyniku meczu przez oprogramowanie zdarzenia Przy bieżącym dla formularza nadrzędnego. Dokładnie rzecz ujmując, przez rozszerzenie funkcjonalności istniejącego kodu procedur}' obsługi tego zdarzenia.

144

Bazy danych. Pierwsze sta rcie

Listing 4.6. Obsługa zdarzenia Przy bieżącym dla formularza Mecze wymuszająca przeliczenie wartości wyniku oraz zmianę źródeł dla poła kombi ii' podformularzu Pnvate Sub Form_Current() IF ( IsNul1(Me.IdGosc) OR IsNull(Me.IdGosp) OR IsNull(He.IdMeczu)) THEN zap = " SELECT SUM(O) AS BGosp. SUM(O) AS BGosc FROM Bramki” E1se zap = "SELECT SUM(Gosp) AS BGosp. SUM(Gosc) AS BGosc FROM ” zap = zap & "(SELECT COUNT( IdZawodnika) AS Gosp . 0 AS Gosc " zap = zap & "FROM Bramki INNER JOIN Osoby " zap = zap & ”0N Bramki. IdZawodnika = Osoby.IdOsoby " zap = zap & " WHERE IdMmeczu= " & Me.IdMeczu zap = zap & " AND IdDzia1u=” & Me.IdGosp zap = zap & ” UNION ALL " zap = zap & "SELECT 0 A5 Gosp. COUNT( IdZawodnika) AS Gosc FROM" zap = zap & " Bramki INNER JOIN Osoby ” zap = zap& " ON Bramki. IdZawodnika = Osoby.IdOsoby" zap = zap & " WHERE IdMeczu= " & Me.IdMeczu " zap = zap & " AND IdDzialu=" & Me.IdGosc" zap = zap & ") AS xxx" End I f Me.Wynik.Form.RecordSource = zap zap = “SELECT IdOsoby. Nazwisko & ' ' & Imię FROM Osoby " zap = zap & "WHERE IdDzialu=" & Me.IdGosc zap = zap & " OR IdDzialu=" & Me.IdGosp Me.Bramki .Form.Controls.Item("IdZawodnika"LRowSource = zap Me.Recalc End Sub

Dodany został fragment ujęty instrukcją wyboru IF . . . THEN . . . ELSE. Sprawdzany jest warunek, czy którekolwiek z pól identyfikujących drużyny (IdGosp, IdGosc) lub mecz (IdMeczu) nie przyjmuje wartości nieokreślonej (NULL). Może mieć to miejsce np. przy tworzeniu nowego rekordu — wpisaniu nowego meczu. W tym przypadku zmienna łańcuchowa zap zawiera zapytanie zwracające w jednym rekordzie na dwóch polach wartości zero. Zastosowanie w nim funkcji agregującej SUM powoduje właśnie wymuszenie sytuacji, w której będzie zwracany dokładnie jeden rekord. Oczywiście można to uzyskać inaczej, np. stosując dyrektywę TOP 1. Przyjęcie takiego rozwiąza­ nia jest uzasadnione chęcią formalnego upodobnienia go do późniejszej, bardziej roz­ budowanej i sparametryzowanej postaci występującej w sekcji ELSE instrukcji warun­ kowej. Nieuwzględnienie warunku występowania wartości nieokreślonych mogłoby doprowadzić do błędów przetwarzania. Jeżeli żadne ze sprawdzanych pól nie przyjmuje wartości NULL, co oznacza, że mecz został już zdefiniowany, a być może nawet rozegrany, konieczne jest podsumowanie bramek zdobytych przez zawodników obu drużyn. Wykonujemy to, jak było zaznaczone wcześniej, przez sparametryzowanie statycznej postaci zapytania będącego predefinio­ wanym źródłem rekordów dla formularza Wynik. W pierwszym zapytaniu składowym unii dokonano filtrowania w ramach bieżącego meczu tylko dla drużyny gości, w dru­ gim w ramach bieżącego meczu tylko dla drużyny gospodarzy. Ostatnim elementem jest przypisanie zmiennej (bez względu na to, w której sekcji instrukcji warunkowej została przypisana jej wartość) jako źródła rekordów RecordSource dla formularza Wynik. Aby rezultat naszej pracy był satysfakcjonujący, należy jeszcze zmienić sposób wyświetlania formularza przez usunięcie obramowania, przycisków nawigacyjnych etc.

Rozdział 4. ♦ Z astosow anie języka zapytań SQL z poziomu formularzy

145

Pozostaje jeszcze bieżące przeliczanie wyniku wraz z dopisywaniem kolejnych strzel­ ców bramek w bieżącym meczu. Można tego dokonać przez obsługę zdarzenia Po aktualizacji dla pola kombi IdZawodnika w podformularzu Bramki. Zawartość tej procedury mogłaby być kopią prezentowanej poprzednio (listing 4.6). Jednak możemy ten sam efekt uzyskać prościej — wymuszając z poziomu podformularza odświeżenie formularza nadrzędnego, co z kolei spowoduje odświeżenie wszystkich obiektów w nim występujących, w tym podformularza Wynik (listing 4.7). Odświeżenie innego formula­ rza z poziomu bieżącego jest możliwe tylko wtedy, gdy odświeżany formularz jest otwarty, przy próbie odświeżenia zamkniętego formularza generowany jest błąd i jeśli nie zastosowano dyrektywy obsługi wyjątków (ON ERROR), przetwarzanie jest zatrzy­ mywane. W analizowanym przypadku mamy pewność, że formularz Bramki nie zo­ stanie nigdy otwarty jako obiekt samodzielny, gdyż w takim stanie jego działanie nie ma żadnego sensu. Wymuszenie odświeżania uzyskano, odwołując się do obiektu Forms, będącego klasą wszystkich formularzy. Poprzez metodę Item odwołano się do kon­ kretnego z nich, podając jego nazwę, a następnie wykonana została metoda Recalc — przelicz. Listing 4.7. Obsługa zdarzenia Po aktualizacji pola kombi dla podformularza Bramki wymuszająca przeliczenie wartości wyniku na skutek odświeżenia Private Sub IdZawodnika_AfterUpdate() Forms. Item("Mecze") . Reca1c End Sub

Można sobie wyobrazić o wiele więcej przykładów stosowania dynamicznej wymiany źródeł danych, chociażby jako kolejnej z metod filtrowania zestawu rekordów na podstawie danych zawartych w formularzu. Wydaje się jednak, że przedstawione tutaj rozwiązania są reprezentatywne i stanowią wystarczającą ilustrację.

Wyw@Sywamió© zapyuam oira©s3yffótajiąi©y©[ft] dianu© z p©zó®oiraao Uwow Dacza Drugim ważnym aspektem wywoływania zapytań z poziomu formularza jest możliwość skorzystania z zapytań modyfikujących dane. Co pozwoli na aktualizację, usuwanie czy też wstawianie danych zgodnie z danymi zawartymi w formularzu. Zakres stosowalno­ ści wspomnianych mechanizmów jest naprawdę bardzo szeroki, chociaż odwołuje się do bardzo małego wycinka języka SQL. W zasadzie możemy mówić, że operować bę­ dziemy na trzech zapytaniach SQL (UPDATE, DELETE, INSERT) w różnych ich postaciach. Wydaje się, że dwa pierwsze są najistotniejsze. Bardziej radykalnie można powiedzieć, że tak naprawdę tylko aktualizacja danych zasługuję na uwagę. W tym podrozdziale zajmiemy się właśnie praktycznym zastosowaniem zapytań mo­ dyfikujących z poziomu końcówki klienta — z poziomu formularza. Pierwszy przykład będący wprowadzeniem w poruszaną tematykę, i może być traktowany jako rozwiąza­ nie o charakterze akademickim. Zapewnia ono poglądowość prezentowanych mecha­ nizmów, ale trudno mówić o jego zastosowaniu praktycznym.

146

Bazy danych. Pierwsze sta rcie

Chcielibyśmy, aby dane w tabeli Osoby (pola Nazwisko i Imię) były zmieniane na pi­ sane małymi albo dużymi literami, zależnie od nazwy funkcji wybranej na liście rozwijalnej (UCase, LCase) (rysunek 4.3). Podobne zadanie było realizowane przy po­ mocy zapisanych zapytali w części poświęconej narzędziom wizualnym. Rysunek 4 .3 . Definicja zawartości listy rozwijalnej (pola kombi)

|B^ Form ufaral: Formutory

KcmbiO

iezwiązary

{Kreator pot kombi Które wartości mają byś widocne w obiekcje pcśe kombi? Wprowadź tobą kolom, które mają' być umieucKne na Iście, a następnie wpisz wartości w każda) z komórek. Aby dostosować szerokość kokjmny, należy przeciągnąć jej prawą Irawędi ru żądane miejsce lub liśnąć dmkrotnie lewą krawędź nagłówka kokjmny, aby otrzymać optymalno dooasowame. Ucha k e W

(T l

1“ :
~~

---Anuluj

| ' ! < Wstecz

|

W celu prezentacji rozwiązania zasygnalizowanego problemu stwórzmy pusty formu­ larz. W kolejnym kroku z przybornika (przy włączonym kreatorze) wstawmy pole kombi. Jako źródło danych wybierzmy statyczną listę wartości, do której wpiszmy nazwy funkcji operacji na łańcuchach (UCase, LCase) — rysunek 4.3. We właściwościach utworzo­ nej liście nadajmy nazwę FUN. Aby możliwe było natychmiastowe obejrzenie skutków działania zapytań, w formularzu naieży umieścić pomocniczy podformularz zawierający modyfikowane pola (Nazwisko i Imię) z tabeli Osoby. Jeżeli chcemy zrealizować zmianę zawartości pól w tabeli zgodnie z wybraną na liście nazwą funkcji, możemy obsłużyć zdarzenie Po aktualizacji dla listy rozwijalnej (li­ sting 4.8). Budowane jest wyrażenie będące sparametryzowaną postacią zapytania aktu­ alizującego, które jest przypisywane do zmiennej znakowej zap. W celu wykonania zapytania modyfikującego w postaci SQL z poziomu formularza (procedury obsługi zdarzenia) odwołujemy się do metody RunSQL obiektu DoCmd. Parametrem tej metody jest łańcuch albo zmienna zawierające poprawne składniowo zapytanie SQL. Przy użyciu metody RunSOL możemy wykonywać tylko zapytania modyfikujące dane lub strukturę bazy danych. Nie jest możliwe przy użyciu tej metody wykonanie żadnego typu za­ pytania wybierającego. Listing 4 .8 . Definicja procedury obsługi zdarzenia dla pola kombi________________________________ Private Sub FUN_AfterUpdate() zap = "UPDATE Osoby SET Nazwisko=" & Me.FUN & "(Nazwisko). Imie=’’ & He.FUN & "(Imię)"

147

Rozdział 4. ♦ Z astosow anie języka zapytań SQL z poziomu formularzy DoCmd.SetWarnings False DoCmd.RunSOL zap DoCmd.SetWarnings False Me.Recalc End Sub

Analogicznie jak przy wykonywaniu zapisanych zapytań modyfikujących dane rów­ nież w przypadku wykonywania modyfikujących zapytań SQL pojawiają się komuni­ katy systemowe informujące, ze takie zapytanie zostanie wykonane oraz że N wierszy zostanie zmienionych (wstawionych, usuniętych). Jeśli chcemy, aby nie były one wy­ świetlane, musimy ustawić odpowiednią flagę systemową— SetWarmngs. Po zakoń­ czeniu modyfikacji, aby możliwe było natychmiastowe obejrzenie rezultatu, musimy wymusić odświeżenie zawartości metodą Recalc. Można również zrealizować przypadek taki, w którym nie oba, ale tylko jedno wy­ brane pole jest aktualizowane zgodnie z wybraną funkcją. W tym celu na formularz zostanie wprowadzona kolejna lista rozwijalna, której źródłem wierszy będzie zapy­ tanie wybierające pola znakowe z tabeli Osoby {Nazwisko i Imię), a typ źródła wierszy zostanie ustalony na Listą pól (rysunek 4.4). W ten sposób na liście wyświetlone zo­ staną nazwy wybieranych pól, a nie ich zawartość. Ten sam efekt można uzyskać, stosując listę statycznych wartości. Obie definicje zawartości pola kombi są równo­ ważne. Dopiero gdy w zapytaniu źródłowym zastosujemy znak specjalny * wyświe­ tlający wszystkie kolumny dostępne w tabeli, nie zawsze możliwe jest zastąpienie takiej definicji danych dla pola kombi statyczną listą. Możliwe jest bowiem, że w trakcie funkcjonowania aplikacji definicja tabeli ulegnie zmianie. Wprowadzona lista została nazwana Pole. Rysunek 4 .4 . Definicja zawartości listy rozwijalnej (pola kombi)

Run5QL: Formularz

■ H 2-I-3 - l»4 - 1*5* l» G

n

H

H i •

M

H

9■ i • 10• I • tt

2

■I •t

\4 Szczegóły )soby P łdrórroif arz |

)M1ezwiazany

I-fil

4 • t • S • i ££.

'4

fifaezwlązary

I N~afil'E>vet;"forinulaaa~ yśzczeg ó ly

liki— dou*I

Im

fia Pole kombi: Pole

4

i Pole 1

WszystUe | F o rm at . .

................7.T."1____________________

Miejsca dziesiętne.................... Auto_____________________ Maska wprowadzania.............. I_________________________ Typ źródła wierszy.................. Usta pól Źródło wierszy........................ iSEIECT Nazwisko. Imię FROM Osobytl

P Id ja

liczba kolum n...................................[1___________________________________ Majówki kolumn.........................Nie_______________________________

Szerokości kolumn.................... 1

d

148

Bazy danych. Pierwsze sta rcie

Taka modyfikacja wymaga również zmiany kodu procedury obsługującej zdarzenie Po aktualizacji dla pierwszego z pól kombi (listing 4.9). Zmieniana jest tylko wartość zmiennej zawierającej zapytanie modyfikujące SQL. Reszta kodu — ustawienie flagi systemowej, wykonanie zapytania modyfikującego oraz odświeżenie — pozostają bez zmian. Listing 4.9. Definicja procedury obsługi zdarzenia dla poła kombi Prw ate Sub FUN_AfterUpdate() zap = "UPDATE Osoby SET " & Me.Pole & ”=" & Me.FUN & " ( ” & He.Pole & ")" DoCmd.SetWarnings False DoCmd.RunSOL zap DoCmd.SetWarnings False Me.Recalc End Sub

Kolejny przykład zastosowania zapytali modyfikujących dane z poziomu formularza może już mieć zastosowanie praktyczne. Jest oczywiste, że skład osobowy firmy z bie­ giem czasu ulega zmianie — przyjmowani są nowi pracownicy, inni są zwalniani. Ze względów formalnych nie możemy pozwolić sobie na zwykłe usuwanie rekordów dotyczących zwolnionych pracowników, gdyż utracilibyśmy informacje o ich zarobkach, co z punktu widzenia księgowości jest niedopuszczalne. Z drugiej strony, jeśli zmiany personalne są dość duże, trudno sobie wyobrazić, że przetwarzamy zawsze wszystkie rekordy. W większości przypadków interesowała nas będzie informacja dotycząca osób aktualnie pracujących, natomiast dane historyczne o dawno już zwolnionych pracow­ nikach będą nam potrzebne sporadycznie. Rozważmy więc pierwszą realizację zwalniania pracowników. Zastosujemy w tym celu dwie tabele dodatkowe, będące składnicami archiwaliów o nazwach Osoby_arch i Zarobki arch. Obie tabele są w sensie struktury kopiami istniejących tabel przecho­ wujących dane bieżące. W celu ich utworzenia możemy skorzystać z narzędzi wizualnych lub wykonać zapytanie tworzące tabelę na podstawie istniejącej tabeli — SELECT ... INTO. SELECT * INTO Osoby_arch FROM Osoby WHERE IdOsoby IS NULL: SELECT * INTO Zarobki_arch FROM Zarobki WHERE IdZarobku IS NULL:

W celu zapewnienia tego, że przy tworzeniu nie będą przepisane do tabel przeznaczo­ nych na archiwalia żadne dane z tabel wzorcowych, w obu zapytaniach stosujemy klau­ zulę WHERE odwołującą się do pola klucza podstawowego i sprawdzającą, czy klucz ma wartość NULL (klucz z definicji nie może przyjąć stanu NULL). Możemy teraz na formularzu Osoby (został stworzony w części opisującej narzędzia wizualne) umieścić przycisk polecenia, którego wybranie spowoduje zwolnienie bie­ żącego (wyświetlanego w aktualnie wybranym rekordzie) pracownika. Dla tego przy­ cisku stwórzmy procedurę obsługi zdarzenia Przy kliknięciu (listing 4.10).

Rozdział 4. ♦ Z astosow anie języka zapytań SQL z poziomu formularzy

149

Listing 4 .1 0 . Definicja procedury obsługi zdarzenia Przj’ kliknięciu dla prz)’cisku polecenia Zwolnij Private Sub Zw olnij_Click() DoCmd.SetWarnings False zap = "INSERT INTO Osoby_arch SELECT * FROM Osoby " & _ "WHERE IdOsoby=” & Me.IdOsoby DoCmd.RunSOL zap zap = "INSERT INTO Zarobki_arch SELECT * FROM Zarobki " & "WHERE IdOsoby=" & Me.IdOsoby DoCmd.RunSOL zap zap - "DELETE * FROM Zarobki WHERE IdOsoby=" & Me.IdOsoby DoCmd.RunSOL zap zap = "DELETE * FROM Osoby WHERE IdOsoby=" & Me.IdOsoby DoCmd.RunSOL zap DoCmd.SetWarnings True Me.Requery End Sub

Procedura ta zawiera wykonanie za pomocą metody RunSQL czterech zapytali modyfi­ kujących dane, których treść zawarta jest w pomocniczej zmiennej zap. W kolejności wykonywane jest: wstawienie do tabeli Osoby arch rekordu zawierającego dane o zwal­ nianej osobie; wstawienie do tabeli Zarobki_arch rekordów zawierających zarobki zwalnianego pracownika; usunięcie z tabeli Zarobki rekordów zawierających zarobki zwalnianego pracownika; usunięcie z tabeli Osoby rekordu zawierającego dane o zwal­ nianej osobie. We wszystkich przypadkach do stworzenia warunku filtrującego (klau­ zula WHERE) skorzystano z identyfikatora bieżącego pracownika; rekordu formularza. Zapytania wstawiające dane do tabel z archiwaliami muszą poprzedzać zapytania usu­ wające dane, co jest dość oczywiste. Ponadto najpierw należy usunąć dane z tabeli Zarobki, dopiero potem Osoby, tak aby do końca operacji możliwe było odwołanie się do identyfikatora zwalnianego pracownika. Kolejność wykonywania zapytań mogłaby zostać ustalona dowolnie, gdyby identyfikator zwalnianego pracownika został zapisany do pomocniczej zmiennej. W przedstawionym przykładowym kodzie została użyta jedna zmienna dla wszystkich poleceń SQL. Nie jest to z punktu widzenia praktyki najlepsze rozwiązanie. Oczywiście oszczędzamy na pamięci potrzebnej do przecho­ wywania danych, ale skutkiem tego zapytania wykonują się w pewnych odstępach od siebie. W analizowanym przykładzie czas między kolejnymi wywołaniami zapytań jest bardzo krótki i z punktu widzenia czasu przetwarzania nieistotny. Łatwo sobie jednak wyobrazić takie zadanie, gdzie do sparametryzowania zapytania potrzebny jest dość duży czas. Wtedy odstęp czasowy między wykonaniami metody RunSQL będzie znaczący. W takim przypadku w celu możliwie pewnego wykonania wszystkich za­ pytań lepsze jest podstawienie sparametryzowanych postaci poleceń SQL pod różne zmienne i wykonanie ich jedno pod drugim. Tym bardziej jest to istotne, gdy zapytania są od siebie zależne. W naszym przykładzie dodatkowo jak przy każdym wywołaniu zapytania modyfikującego ustawiono flagę odpowiadającą za komunikaty systemowe oraz dokonano odświeżenia całego źródła danych (zapytania— tabeli). Jeżeli nie dokonamy odświeżenia zawartości formularza (pominiemy polecenie Me. Reąuery) lub zastosujemy inny typ odświeżenia, np. Recalc, otrzymamy informację w postaci napisu #Usumęty we wszystkich polach rekordu. Konieczność zastosowania metody Reąuery (przeliczenia wszystkich rekordów zapytania będącego źródłem danych dla formularza — ponowne wykonanie zapytania) wynika z faktu, że po usunięciu rekordu

150

Bazy danych. Pierwsze sta rcie

w dalszym ciągu „stoimy” w miejscu, gdzie on się znajdował. Jeżeli nawet spróbujemy wymusić przejście do kolejnego rekordu, to i tak formularz „nie wie” o tym, że dane zawarte w rekordzie zostały usunięte, opiera się bowiem o stary, historyczny zestaw rekordów. Na tym etapie mamy do czynienia z dwoma parami identycznych co do struktury tabel. 0 ile jednak para Osoby i Zarobki ma swoją reprezentację w postaci formularza z podformularzem, o tyle para Osoby_arch Zarob ki_ arch takiej reprezentacji nie posiada. Można oczywiście szybko sporządzić taki formularz przy użyciu kreatora, ale można też, wykorzystując fakt tożsamości strukturalnej tabel źródłowych, użyć już istniejącego 1 zmienić tylko źródła. Wymiany źródła danych dokonamy, wprowadzając na formularzu dodatkowy przycisk polecenia i programując zdarzenie Przy kliknięciu (listing 4.11). W instrukcji warun­ kowej sprawdzane jest, czy bieżącym źródłem danych dla formularza jest tabela Osoby. Jeżeli tak. źródło jest wymieniane na tabelę Osoby_arch, natomiast źródło danych podformularza jest zmieniane na Zarobki_arch. W tym miejscu również wymieniany jest napis na obu przyciskach oraz zmieniany jest kolor napisu dla jednego z nich. Po­ nieważ możemy założyć, że zwolnionym pracownikom nie można przypisać żadnych dodatkowych wynagrodzeń, podformularz ma zablokowaną właściwość Enabled, co nie pozwala ani na edytowanie starych wpisów, ani na dodawanie nowych. To samo można byłoby uczynić z formularzem głównym. W sekcji ELSE instrukcji warunkowej wykonywane są te same operacje ze zmienionymi (na zwrotne) wartościami. Listing 4 .1 1 . Definicja procedury’ obsługi zdarzenia Przy' kliknięciu dla przycisku polecenia Archiwum Private Sub Archiwum_Click() I f {Me.RecordSource = "Osoby") Then Me.RecordSource = "Osoby_arch" Me.Zarobki_Podformularz.Form.RecordSource = "Zarobki_arch" Me.Archiwum.Caption = "Bieżące" He.Zwolnij.Caption = "Przyjm ij” Me.Zwolnij.ForeColor = RGB(0. 0. 255) Me.Zarobki_Podformularz.Enabled = False Elsę Me.RecordSource = "Osoby" Me.Zarobki_Podformularz.Form.RecordSource = "Zarobki" Me.Archiwum.Caption = "Archiwum" Me.Zwolnij.Caption = "Zw olnij” Me.Zwolnij.ForeColor = RGB(255. 0. 0) Me.Zarobki_Podformularz.Enabled = True End If Me.Requery End Sub

Po takiej modyfikacji formularza obsługującego teraz dwie pary tabel jednocześnie, działanie przycisku Zwolnij jest niekompletne. Jeżeli bowiem źródłem danych są tabele z archiwaliami, naciśnięcie go nie powoduje żadnej akcji. Odwołujemy się bo­ wiem do identyfikatora pracownika, którego nie ma ani w tabeli Osoby, ani w tabeli Zarobki, a akcja przycisku ma obsługiwać dane z tych właśnie tabel. Można pomyśleć o oprogramowaniu akcji odwrotnej. Jeśli danymi są tabele archiwalne, to wybranie przycisku powinno spowodować przywrócenie do pracy. Czyli zwrotne przepisanie pra-

Rozdział 4. ♦ Z astosow anie języka zapytań SQL z poziomu formularzy

151

cownika z tabeli Osoby_arch do tabeli Osoby, a jego zarobków z tabeli Zarobki_arch do tabeli Zarobki. Przepisane dane powinny być następnie usunięte z tabel źródłowych. Realizacja takiego pomysłu wymaga rozbudowania procedury obsługi zdarzenia Przy kliknięciu dla przycisku Zwolnij, przy wykorzystaniu pomysłów zawartych w poprzed­ nim rozwiązaniu oraz sprawdzeniu bieżącego źródła danych (listing 4.12). Listing 4 .1 2 . Definicja procedury>obsługi zdarzenia Przy kliknięciu dla przycisku polecenia Zwolnij Private Sub Zw olnij_Click() DoCmd.SetWarnings False I f (Me.RecordSource = "Osoby” ) Then zap = "INSERT INTO Osoby_arch SELECT * FROM Osoby " & _ "WHERE IdOsoby=" & Me.IdOsoby DoCmd.RunSOl zap zap = "INSERT INTO Zarobki_arch SELECT * FROM Zarobki “ & _ "WHERE IdOsoby=" & Me.IdOsoby DoCmd.RunSOl zap zap = "DELETE * FROM Zarobki WHERE IdOsoby=" & Me.IdOsoby DoCmd.RunSOL zap zap = "DELETE * FROM Osoby WHERE IdOsoby=" & Me.IdOsoby OoCmd.RunSOL zap Elsę zap = "INSERT INTO Osoby SELECT * FROM Osoby_arch ” & _ "WHERE IdOsoby=” & Me.IdOsoby DoCmd.RunSOL zap zap = "INSERT INTO Zarobki SELECT * FROM Zarobki_arch " & "WHERE IdOsoby=" & Me.IdOsoby DoCmd.RunSOL zap zap = "DELETE * FROM Zarobki_arch WHERE IdOsoby=” & _ Me.IdOsoby DoCmd.RunSOL zap zap = "DELETE * FROM Osoby_arch WHERE IdOsoby=" & _ Me. IdOsoby OoCmd.RunSOL zap End I f DoCmd.SetWarnings True Me.Requery End Sub

Jak widać, w obrębie sekcji IF „ THEN (czyli gdy źródłem danych dla formularza jest tabela Osoby) kod jest dokładną kopią kodu z przykładu dla obsługi pary tabel Osoby, Zarobki. Natomiast w sekcji ELSE w kodzie zastąpiono tabele, z kolei idea obsługi zdarzenia jest tożsama z tą, którą zastosowano w poprzedniej sekcji. W naszym przykładzie wzorem przykładu dotyczącego meczów możliwe jest doko­ nanie sumowania. W tym celu na formularzu dodajmy dodatkowe niezwiązane pole tekstowe o nazwie Razem. W celu otrzymania podsumowania zarobków Brutto dla każdego pracownika, przy zmianie rekordu oprogramujmy zdarzenie Przy bieżącym formularza (listing 4.13). Skorzystajmy przy tym ze znanej nam funkcji agregatu domenowego {DSUM), która wymaga podania trzech argumentów: sumowanego pola (wyrażenia); tabeli lub zapytania, z której rekordy są sumowane, oraz wyrażenia filtrującego (trzeci parametr nie jest obowiązkowy, a gdy nie zostanie podany, sumowane są wszystkie re­ kordy). Należy zwrócić uwagę, że nazwy obiektów są ujęte w cudzysłów (są traktowane

152

Bazy danych. Pierwsze sta rcie

jak łańcuch z nazwą, a nie nazwa obiektu). Zmienna łańcuchowa filtr zawiera wyra­ żenie oparte o identyfikator bieżącego rekordu (pracownika). Ponieważ sumowanie ma działać zarówno dla pary tabel Osoby, Zarobki, jak i Osoby_arch i Zarobkijarclt, za­ stosowano instrukcję warunkową pozwalającą na wskazanie właściwej tabeli. Dla nowego rekordu zmienna a zawiera wartość NULL, stąd podpisanie w tym przypadku wartości zero — bezpośrednie podstawienie wartości NULL do pola tekstowego jest błędem przetwarzania. Wyznaczona w ten sposób zmienna a jest podstawiana do pola tekstowego Razem. Dodatkowo można powiedzieć, że nadmiarowo zastosowano dy­ rektywę obsługi wyjątków On Error Resume Next, powodującą pominięcie linii, w której występuje błąd przetwarzania. Listing 4 .13. Definicja procedury obsługi zdarzenia Przy’ bieżącym dla formularza u' celu wyznaczenia posumowania Pnvate Sub Form_Current() On Error Resume Next a *> 0 f i l t r = “ IdOsoby=" & Me.ldOsoby I f (Me.RecordSource = "Osoby") Then a = DSUM("Brutto". "Zarobki", f i l t r ) Elsę a = DSUM("Brutto". "Zarobki_Arch". f i l t r ) End I f I f (IsN ull(a)) Then a =0 End If He.Razem = a End Sub

Końcowym elementem jest dodanie obsługi zdarzenia Po aktualizacji dla pola Brutto podformularza (listing 4.14). Powoduje ona ponowne przeliczenie sumy zarobków dla pracowników w chwili wprowadzenia nowej wypłaty. Idea procedury jest podobna do przedstawianej poprzednio i opiera się o funkcję DSUM. Różnica zawarta jest w sposo­ bie podstawienia wyniku. Ponieważ docelowa kontrolka leży w formularzu nadrzęd­ nym, konieczne jest odwołanie się do niej poprzez nazwę formularza oraz nazwę kontrolki w kontenerze Controls. Wyjaśnienia wymaga również wymuszenie odświe­ żenia przed sumowaniem. Wynika ono z konieczności zapewnienia, że nowo wstawiany rekord zostanie utrwalony w źródłowej tabeli. Należy' przypomnieć, że rekord w Accessie jest zapisywany w momencie przejścia do innego rekordu (kolejny, poprzedni, nowy...) bez względu na to. czy dodajemy rekord, czy też modyfikujemy istniejący. Można powiedzieć z dość dobrym przybliżeniem, że w naszym kodzie polecenie Me.Recalc pełni rolę polecenia zapisz rekord. Listing 4 .1 4 . Definicja procedury»obsługi zdarzenia Po aktualizacji dla pola Brutto w podformtilarzu u' celu wyznaczenia posumowania Private Sub Brutto_AfterUpdate() Me.Recalc f i l t r = "IdOsoby=” & Me.ldOsoby a = DSunH"Brutto". "Zarobki", f i l t r ) Forms.Item("Osoby” ).Controls("Razem") = a End Sub

Rozdział 4. ♦ Z astosow anie języka zapytań SQL z poziomu formularzy

153

Przedstawiona powyżej metodologia przechowywania danych archiwalnych ma jednak poważne wady. Jeżeli bowiem dokonujemy podsumowań np. wynagrodzeń wypłaconych w określonym przedziale czasu, to najczęściej interesują nas wszystkie wypłaty doko­ nywane w analizowanym okresie, bez względu, czy w momencie wykonywania zapytania pracownik jest zatrudniony, czy nie. Rozwiązaniem tego problemu jest oczywiście stoso­ wanie unii zapytań wyświetlających osoby obecnie i kiedykolwiek zatrudnione. Jest to rozwiązanie po pierwsze dość dziwne, po drugie w przypadku wykonywania pod­ sumowań zmniejszające nieco wydajność. Wykonanie operatora UNION wbrew pozo­ rom nie jest wcale czasochłonne. Rozwiązanie to posiada natomiast liczne zalety dydaktyczne. W praktyce możemy zamiast stosowania oddzielnych tabel zastosować flagę określającą czy dany pracownik jest obecnie zatrudniony (aktywny — zawodowo) (listing 4.15 i 4.16). Konieczne jest więc dodanie do definicji tabeli Osoby pola o na­ zwie Aktywny, które będzie typu logicznego. Listing 4.1 5 . Definicja procedury>obsługi zdarzenia Przy’ kliknięciu dla przycisku polecenia Archiwum Private Sub Archiwum_Click() IF (Me.Aktywny = -1) THEN Me.RecordSource = "SELECT * FROM Osoby WHERE Aktywny=0" Me.Archiwum.Caption = "Bieżące" Me.Zwolnij.Caption = "Przyjm ij" Me.Zwoi nij.ForeColor = RGB( 0. 0. 255) ELSE Me.RecordSource = "SELECT * FROM Osoby WHERE Aktywny=-1" Me.Archiwum.Caption = "Archiwum” Me.Zwolnij.Caption = "Zwolnij" Me.Zwoi nij.ForeColor = RGB(255. 0. 0) END IF Me.Requery End Sub

Listing 4 .16. Definicja procedury obsługi zdarzenia Przy kliknięciu dla przycisku polecenia Zwolnij Private Sub Zw olnij_Click() DoCmd.SetWarnings False If (Me.Aktywny = -1) Then zap = "UPDATE Osoby SET Aktywny=0 WHERE Id0soby=" & Me.ldOsoby DoCmd.RunSOL zap Elsę zap = "UPDATE Osoby SET Aktywny=-1 WHERE IdOsoby=“ & Me.ldOsoby DoCmd.RunSOL zap End If DoCmd.SetWarnings True Me.Reąuery End Sub

W przypadku zastosowania pola flagi, zamiana wyświetlanych rekordów na aktualne czy archiwalne, sprowadzi się do testowania wartości pola Aktywny i ustawieniu w klau­ zuli WHERE warunku dotyczącego tego poia (listing 4.15, 4.16). Należy pamiętać, że

154

Bazy danych. Pierwsze sta rcie

przy reprezentacji liczbowej ze znakiem zmiennej logicznej wartości fałsz odpowiada 0, natomiast wartości prawda — wartość -1 (ponieważ pierwszy bit reprezentuje znak, a reszta tzw. uzupełnienie do dwóch). Proces zwalniania pracownika jest równie prosty i sprowadza się do sprawdzenia warto­ ści pola Aktywny i za pomocą zapytania aktualizującego przypisania mu wartości prze­ ciwnej dla bieżącego rekordu w formularzu (tabeli Osoby). Upraszcza się również obsługa procedury zdarzenia Przy bieżącym dla formularza (li­ sting 4.17), gdyż to, czy wyświetlamy dane bieżącego pracownika, czy też już zwol­ nionego, nie ma wpływu na sumowanie — i tak dotyczy pracownika o danym identy­ fikatorze, bez względu na jego status. Listing 4 .1 7 . Definicja procedury obsługi zdarzenia Przy bieżącym dla formularza ii' celu wyznaczenia podsumowania Prw ate Sub Form CurrentO ON ERROR RESUME ŃEXT a =0 f i l t r = "IdOsoby=" & Me.IdOsoby a = DSum("Brutto” . “Zarobki", f i l t r ) I f (IsN ull(a)) Then a =0 End If Me.Razem = a End Sub

Przykładów praktycznego powiązania zapytań SQL z programowaniem zdarzeń na poziomie budowy końcówek klienta można mnożyć bez liku. W tym miejscu możemy przyjąć, że przedstawione w tym rozdziale są wystarczająco reprezentatywne, a zara­ zem wystarczająco ogólne, mogące być przydatne przy rozwiązywaniu własnych pro­ blemów programistycznych czytelnika.

Rozdział 5.

Mechanizmy wymiany dany©Cd Pomimo tego, że omówione do tej pory mechanizmy pozwalają na budowę złożonych aplikacji, to pozostaje do pokonania kilka ważnych problemów. Najbardziej podsta­ wowym jest wyszukanie i odczytanie z dowolnej tabeli bazy koniecznych do obliczeń wartości, bez uciekania się do budowy pomocniczego, często zupełnie zbędnego ze względu na przetwarzaną informację formularza. Problem ten dotyczy zarówno bie­ żącej bazy danych, jak i zewnętrznych źródeł danych różnych typów. Jednym z naj­ bardziej wszechstronnych narzędzi pozwalających na wykonanie takich operacji jest zastosowanie mechanizmów wymiany danych. Oczywiście zakres stosowania tych na­ rzędzi i metod nie ogranicza się tylko do tego zadania, ale bez wątpienia jest najbardziej podstawowym ich elementem. Twórcy oprogramowania stworzyli wiele tego typu mechanizmów: ODBC, OLEDB, JDBC. Należy dodać, że mechanizm ODBC (Open DataBase Connectmty) był pierw­ szą udaną próbą ujednolicenia sposobu dostępu do danych. Ze względów praktycznych w przedstawianych rozważaniach ograniczymy się do dwóch nakładek obiektowych na dwa pierwsze ogólne mechanizmy. Oczywiście nic nie stoi na przeszkodzie, aby korzystać bezpośrednio z podstawowych mechanizmów, jednak stosowanie nakładek obiektowych z reguły ułatwia programowanie.

Zastos©waoi]D© obiektów ©A® (Data A c se ss ©tojjeefts) Pierwszym zastosowanym w środowisku MS Access mechanizmem wymiany danych był DAO {Data Access Objects) (rysunek 5.1). Obecnie domyślnym mechanizmem wymiany stosowanym w Accessie jest ADO. Jednak ze względu na chronologię wpro­ wadzenia rozważania rozpoczniemy od starszego mechanizmu DAO. Stanowi on "na­ kładkę" obiektową na niskopoziomowy mechanizm wymiany danych ODBC (Open

Bazy danych. Pierwsze sta rcie

156

DataBase Connectivity). Model ten zorganizowany jest w postaci struktury hierar­ chicznej, której pierwszym węzłem (korzeniem) jest najbardziej ogólny obiekt — silnik bazy danych. W obrębie tego obiektu możemy wyróżnić przestrzenie robocze, które stanowią otoczenie dla otwieranych w ich obrębie baz danych. Wynika z tego, że w jednej aplikacji może zostać stworzonych wiele obszarów roboczych, z których każdy może zawierać jedną lub więcej różnych baz danych. Na poziomie bazy danych mamy dostęp do definicji tabel oraz zapytań, ale przede wszystkim do zestawów rekordów. Takie obiekty pozwalają nam na dostęp do danych zawartych w tabelach. Wszystkie obiekty z wyjąt­ kiem DBEngine tworzą kolekcje (tabela 5.1). Kolekcje obiektów są opatrzone względnie stalą liczbą właściwości związanych z liczebnością kolekcji, nazwami kolekcji itp.

Rysunek 5.1. Hierarchia obiektów DAO

Aby można było skorzystać z biblioteki DAO, należy j ą dołączyć do projektu (bazy danych) z poziomu języka Yisual Basic for Applications (rysunek 5.2). 'm M icrosoft Uisual Dosie • H urtow nio

1: 0* i @

L* • a

50**?

Im rrt

1

■

E.^n 1iJ o d jJ fidi-lro

W)nd>«

£e/erenc«...

• ą

ft-d ł

fcłftaw...

n.-aJló] ..

i

a -0 3 Mocsoft Cffice AcceA*i '-E J FcrmJ3r«T*J EJ Fcrm_Fla$ .

r

J J

.

Optrns...

1

bdZjfibSPropęrtiti..,

■

S^wture...

Rysunek 5.2. Dopisywanie referencji do obiektów DAO z poziomu Yisuai Basic fo r Applications

Rozdział 5. ❖ Mechanizmy wymiany danych

157

Tabela 5.1. Definicja kolekcji i obiektów mechanizmu DAO Kolekcja

Obiekt

Opis

brak

DBEngine

Aparat bazy danych Microsoft Jet

Workspaces

Workspace

Sesja aparatu bazy danych Microsoft Jet

Connections

Connection

Informacje o połączeniu ze źródłem danych ODBC (tylko obszary robocze ODBCDirect

Databases

Database

Otwarta baza danych

Relations

Relation

Związek między polami tabel i zapytań (tylko obszary robocze Microsoft Jet)

Groups

Group

Grupa kont użytkowników (tylko obszary robocze Microsoft Jet)

Users

User

Konto użytkownika (tylko obszary robocze Microsoft Jet)

Errors

Error

Informacje o dowolnych błędach związanych z tym obiektem

Containers

Container

Kontener na informacje o predefiniowanym typie obiektu (tylko obszary robocze Microsoft Jet)

Documents

Document

Informacje o zapisanym, predefiniowanym obiekcie (tylko obszary robocze Microsoft Jet)

TableDefs

TableDef

Zapisana definicja tabeli (tylko obszary robocze Microsoft Jet)

OueryDefs

OueryDef

Zapisana definicja zapytania

Recordsets

Recordset

Rekordy z tabeli bazowej lub zapytania

Fields

F ie ld

Kolumna będąca częścią tabeli, zapytania, indeksu, relacji lub zestawu rekordów

Indexes

Index

Predefiniowana kolejność i unikatowość wartości w tabeli (tylko obszary robocze Microsoft Jet)

Parameters

Parameter

Parametr dla zapytania parametrycznego

Properties

Property

Właściwość wbudowana lub zdefiniowana przez użytkownika

Podstawowym mechanizmem oferowanym w technologii DA O jest możliwość połą­ czenia się ze źródłem danych. W podstawowym zastosowaniu połączenie to jest two­ rzone do dowolnej dostępnej lokalnie lub przez sieć bazy MS Access. W celu nawiązania połączenia konieczne jest zadeklarowanie zmiennej typu DAO. Database. Użycie nazwy kwalifikowanej, czyli poprzedzonej nazwą biblioteki, nie jest w tym miejscu konieczne. Jednakże ze względu na to, że standardowym mecha­ nizmem wymiany danych jest ADO, w którym znajduje się obiekt o nazwie Recordset, takiej samej jak obiekt w bibliotece DAO — zdecydowano się na stosowanie wszędzie nazw kwalifikowanych, pomimo że to nie jest z wyjątkiem nielicznych przypadków bezwzględnie konieczne. W dalszej części rozdziału zostały opracowane krótkie przykłady kodów, które są prze­ kształceniem i rozszerzeniem przykładów dostępnych w wersji elektronicznej na stro­ nach MSDN (http://msdn.microsoft.com/archive/default.asp). Otwarcie bazy danych (li­ sting 5.1) odbywa się poprzez przypisanie do zmiennej obiektowej db wyniku działania funkcji OpenDatabase, pochodzącej oczywiście z biblioteki DAO. Jej parametrem jest pełna (wraz z pełną ścieżką) nazwa pliku bazy danych MS Access. Jedynym warunkiem

158

Bazy danych. Pierwsze starcie

poprawności wykonania tej operacji jest fakt istnienia pliku danych i jego dostępność, albo lokalnie, albo w otoczeniu sieciowym komputera, na którym aplikacja jest uru­ chomiona. Listing 5.1. Połączenie z zewnętrzną bazą prz)> zastosowaniu mechanizmu DAO Dim nazwa As Stnng Dim ok As Boolean Dim db As DAO.Database ok = plik(nazwa) I f (ok) Then Set db = DBEngine.OpenDatabase(nazwa) MsgBox "Otworzona została baza " & db.Name. . "SUKCES” End If db.Close

W prezentowanym kodzie (listing 5.1) założono istnienie funkcji plik obsługującej standardowe okienko dialogowe Otwórz plik {API GetOpenFile), która zwraca przez nazwę zmienną logiczną— TRUE, jeśli wybrano plik, a FALSE w sytuacji przeciwnej. Parametr nazwa zawiera natomiast kwalifikowaną nazwę wskazanego pliku. Po otwarciu bazy danych w postaci okienka komunikatu wyświetlana jest informacja o otwartej bazie danych. W przykładzie ograniczono się tylko do nazwy, ale obiekt Database zawiera wiele innych informacji o pliku bazy. Ta linijka kodu symbolizuje miejsce, w którym wykonywane są operacje na otwartej bazie danych. Na koniec, zgodnie z dobrym oby­ czajem programowania, otwarty wcześniej obiekt zostaje zamknięty. Najczęstszym praktycznym przypadkiem jest sytuacja, kiedy odwołujemy się do otwartego pliku aktualnie używanej (bieżącej) bazy danych MS Access (listing 5.2). W takim przypadku kod może zostać uproszczony przez zastosowanie metody CurrentDB obiektu Application zamiast podawania pełnej nazwy bieżącej bazy danych — co również jest dopuszczalne. Listing 5.2. Połączenie z bieżącą bazą, przy zastosowaniu mechanizmu DAO________________________ Dim db As DAO.Database Set db = CurrentDb() MsgBox "Otwarto bazę " & db.Name. . "SUKCES" db.Close

Zastosowanie metody CurrentDB odpowiada zastosowaniu mechanizmu DAO do bazy bieżącej. Powoduje to, że większość operacji na bieżącej bazie może być wykonywana bez potrzeby jawnego odwoływania się do biblioteki DAO. Ponieważ jest to jednak mechanizm ogólniejszy, będzie tematem dalszych rozważań. Po nawiązaniu połączenia z bazą danych (zarówno w przypadku pliku zewnętrznego, jak i bazy bieżącej) możliwe jest wykonanie szeregu operacji na rekordach. W prezen­ towanym przykładowym kodzie procedury (listing 5.3) poza niezbędnymi do otwarcia bazy zdefiniowano obiekty typów Recordset oraz Field. Po otwarciu bazy danych obiekt Recordset został zasilony pojedynczym (pierwszym) rekordem z tabeli Osoby otwar­ tej bazy' danych, przy użyciu metody obiektu Database — OpenRecordset. Obiekt Field zasilono zawartością pola Nazwisko zawartego w zestawie rekordów. Wykorzystano

Rozdział 5. ♦ M echanizm y wymiany danych

159

w tym celu kolekcję Fields obiektu Recordset, gdzie przez nazwę pola odwołaliśmy się do jego zawartości. Odwołanie się do konkretnego pola zestawu rekordów przy za­ stosowaniu kolekcji Fields możliwe jest na dwojaki sposób: albo dzięki podaniu na­ zwy pola w postaci literału lub zmiennej, albo dzięki podaniu numeru pola w zestawie rekordów (numeracja pól rozpoczyna się od zera — pierwsze pole zestawu ma numer 0, a indeksy kolejnych zwiększane są o jeden). Listing 5.3. Nawiązanie połączenia z bazą danych ptzry zastosowaniu mechanizmu DAO i odesłanie zawartości pola z pierwszego rekordu Dim Dim Dim Set Set Set

dbs rs t f ld dbs rs t f ld

As DAO.Database As DAO.Recordset As DAO.Field = OpenDatabaseCC:\temp\temp.mdb’’ ) = dbs.OpenRecordset("Osoby". dbOpenDynaset) = rst.Fields("Nazw isko")

Mechanizm wymiany DAO pozwala również na nawiązanie połączenia z bazami in­ nymi niż MS Access. Niestety wymaga to dodatkowo skonfigurowania sterownika ODBC i pliku wymiany DSN. W przykładzie (listing 5.4) założono, że skonfigurowany został sterownik do MS SQL Server o nazwie sql, w podstawowym stanie skonfigurowane zostały również domyślna baza danych oraz autoryzacja z poziomu systemu operacyj­ nego. Ponieważ skonfigurowane zostały wszystkie niezbędne parametry, możliwe jest zastosowanie definicji ograniczającej się do podania typu źródła danych. Listing 5.4. Nawiązanie połączenia z bazą danych przy’zastosowaniu mechanizmu DAO za pośrednictwem pliku wymiany DSN i odczytanie zawartości poła z pierwszego rekordu______________________ ~ Dim db As DAO.Database Dim rec As DAO.Recordset Set db = OpenDatabase(”sql “ . dbDrwerNoPrompt. Fa1se. "ODBC:DATABASE=ap:DSN=sql” ) Set rec = db.OpenRecordsetCdzialy” ) który = re c .F ie ld s(l).V alu e

W takim przypadku minimalne wywołanie metody powodującej otwarcie bazy za po­ średnictwem ODBC ma postać Set db = O p e n D a ta b a se ("sq ld b D riv e rP ro m p t. F a ls e . "ODBC:"). Trzeci parametr określa, czy baza jest otwierana tylko do odczytu, i może przyjmować wartości (TRUE lub FALSE) Odczytanie pełnej informacji dotyczącej łańcu­ cha połączeniowego otrzymamy dzięki odwołaniu się do właściwości db.Connect. Ponieważ możliwe jest zdefiniowanie autoryzacji za pośrednictwem wbudowanego na SQL Server systemu, możliwe jest użycie innych wartości stałych określających akcję konieczną do nawiązania połączenia (tabela 5.2). Dalsze rozważania i przykłady dotyczyć będą tylko baz MS Access, ale zmiana źródła danych nie zmienia niczego w kolejno prezentowanych kodach programów. Jeżeli nie znamy nazw pól w tabeli oraz nie znamy ich liczby, dostęp do wszystkich pól możemy uzyskać dzięki zastosowaniu pętli FOR EACH, która przemieszcza się przez wszyst­ kie pozycje w kolekcji rekordów (listing 5.5). Przypadek taki nie jest czysto akade­ micki i występuje, kiedy źródłem rekordu jest zapytanie postaci SELECT * FROM Tabela,

160

Bazy danych. Pierwsze starcie

Tabela 5.2. Wykaz stałych określających tiyb otwarcia baz)’ za pośrednictwem pliku ■wymiany DSN Stała

Opis

dbDriverNoPrompt

Sterownik ODBC wykorzystuje informacje zawanc w łańcuchu połączeniowym. Jeśli dane nie są wystarczające, pojawia się komunikat błędu.

dbDriverPrompt

W yświetlane jest okno dialogowe sterownika ODBC, w którym należy podać brakujące informacje — użytkownik, hasło etc.

dbDriverComplete

(Dom yślne) Jeżeli definicja połączenia nie zawiera wystarczającej liczby informacji, do ich uzupełnienia wykorzystywany jest łańcuch połączeniowy. M ożliwe je s t odwołanie się do okna dialogowego sterowmika ODBC, w’ którym należy podać brakujące informacje.

dbDriverCompleteRequired

Jeżeli definicja połączenia nie zawiera wystarczającej liczby informacji, do ich uzupełnienia wykorzystywany jest łańcuch połączeniowy. Musi być to informacja wystarczająca do zrealizowania połączenia.

a z danych dotyczących tabeli znamy tylko jej nazwę. Może to być spowodowane próbą analizy słabo (w niepełny sposób) opisanego źródła danych lub wtedy, kiedy tabela może dynamicznie zmieniać swoją strukturę (liczbę lub nazwy kolumn). Takie tabele mogą pełnić rolę tabel tymczasowych lub też być wykorzystywane jako źródła danych definiowane dynamicznie przez użytkownika. Niekiedy na etapie projektowa­ nia aplikacji nie jesteśmy w stanie przewidzieć wszystkich danych niezbędnych do określenia jakiegoś obiektu, ale aby nie było konieczne przeprojektowanie bazy, da­ jemy użytkownikowi możliwość dodania własnych pól. W takim przypadku przeszu­ kanie całej tabeli wymaga zastosowania opisanego mechanizmu. Listing 5.5. Dostęp do pól rekordów Fields prz)> zastosowaniu mechanizmu DAO___________________ Dim db As DAO.Database Dim rst As DAO.Recordset Dim fld As DAO.Field Dim 1 As String

1 = ••••

'O tw ó r : b a z ę d a n y c h

Set db = DBEngine.OpenDatabaseC.\dao_adol.mdb") 'O tw ó rz z e s ta w r e k o r d ó w

Set rst = db.OpenRecordset _ ("SELECT nazwisko, tmie FROH Osoby". dbOpenForwardOnly. dbReadOnly) For Each f ld In rs t.F ie ld s 1 = 1 & fld.Value & Next 'P o k a z w a r to ś c i p ó l p ie r w s z e g o r e k o r d u w fo r m u la r z u

Me.Lista.RowSource = 1 r s t . Cl ose 'Z a m k n ij z e s ta w db.C1ose 'Z a m k n ij b a z ę

\rp o lu

listy

rekordów

Dla uproszczenia przykładu zamiast stosować ogólną postać zapytania wybierającego, wybrano tylko dwa konkretne pola tabeli. Jeżeli jednak zmienimy w przykładowym kodzie źródło danych, dodając do listy kolejne pole lub zastępując listę pól znakiem *, to prezentowany przykład (listing 5.6) dalej będzie działał poprawnie. W prezentowanym kodzie zastosow'ano ogólną postać wywołania metody OpenDatabase, przez odwołanie się do niej jako elementu obiektu silnika bazy danych — DBEngine, ale wywołanie

161

Rozdział 5. ♦ Mechanizmy wymiany danych

skrócone prezentowane poprzednio jest również poprawne. Tryb otwarcia został ustawio­ ny na dbOpenForwardOnly, dbReadOnły, co oznacza, że możemy poruszać się w zestawie rekordów tylko do przodu oraz nie jest możliwe modyfikowanie jego zawartości (tylko odczyt). Zmienna typu F ie ld (wskaźnik pętli) została zadeklarowana jawnie, natomiast kolekcja rekordów (F ie ld s — zakres pętli) została podana jako metoda obiektu RecordSet. W kodzie została wykorzystana pomocnicza zmienna znakowa /, która na początku kodu jest „czyszczona”. Będzie ona wykorzystywana jako źródło wierszy dla pola kombi umieszczonego na formularzu, stąd po każdym przejściu pętli jest uzupełniana na końcu znakiem średnik (;), który jest separatorem listy wartości dla kontrolek typu pole kombi i pole listy. Schemat prezentacji skutku działania kodu w postaci wyświetla­ nia wyników za pomocą list w formularzu jest jednym z częściej stosowanych mechani­ zmów stosowanych w tym rozdziale książki. Dlatego w dalszej jej części elementy kodu związane z częścią prezentacyjną pomimo tego, że będą zamieszczane w prezen­ towanych przykładach, nie będą opisywane. Listing 5.6. Wyświetlanie zbioru rekordów przy zastosowaniu mechanizmu DAO Dim db As DAO.Database Dim rst As DAO.Recordset Dim 1 As String Dim I As Long

1=

Set db = DBEngine.OpenDatabaseC.\dao_adol.mdb") Set rst = db.OpenRecordsett "SELECT imię. nazwisko FROH Osoby". dbOpenForwardOnly. dbReadOnły) Do U ntil rst.EOF

I =0 For Each f ld In rs t.F ie ld s 1 = 1 & fld.Value & 1= 1+ 1 Next rst.MoveNext Loop Me.Lista.ColumnCount = I Me.Lista.RowSource = 1 'P o k a ż z a w a r to ś c i r e k o r d ó w n a fo r m u la r z u

wp o lu

lis ty

rst.Close db.Close

Kolejny kod (listing 5.7) ma na celu jedynie pokazanie właściwości A b s o lu te P o s itio n obiektu Recordset zwracającej indeks bieżącego rekordu w zestawie rekordów. Głównym przesłaniem tego przykładu jest stwierdzenie, że numeracja rekordów' przy zastosowa­ niu mechanizmu DAO rozpoczyna się od zera. Tak więc ostatni rekord zestawu ma nu­ mer n-1. Dodatkowo zastosowano tryb otwarcia dbOpenDynaset, który pozwala nie tylko na nawigację do przodu MoveNext, ale też na zastosowanie dowolnego sposobu nawigacji (M oveFirst, MoveLast, MovePrevious lub M ove(LiczbaW ierszy)). Listing 5.7. Nawigacja między rekordami przy zastosowaniu mechanizmu DAO_____________________ Dim db As DAO.Database Dim rst As DAO.Recordset Set db = DBEngine.OpenDatabaset".\dao_adol.mdb") Set rs t = db.OpenRecordsett"SELECT * FROM Osoby". dbOpenDynaset)

162

Bazy danych. Pierwsze sta rcie

' P o k a z p o z y c ję ir ta b e li MsgBox rst.AbsolutePosition, . "Pozycja przed”

' P r z e jd ź d o

o s ta tn ie g o re k o r d u

rst.HoveLast

' P o k a z p o n o w n ie p o z y c ję tr ta b e li MsgBox rst.AbsolutePosition. . "Pozycja po" rst.Close db.Close

Listing 5.8 pokazuje możliwość przeszukiwania zestawu rekordów po stronie koń­ cówki klienta z zastosowaniem mechanizmu DAO. W tym celu zastosować musimy metodę F in d F ir s t obiektu Recordset, której parametrem jest wyrażenie odpowiadające zawartości klauzuli WHERE zapytania wybierającego. Metoda ta znajduje pierwszy rekord zestawu, dla którego wyrażenie ma wartość TRUE. Kolejne rekordy spełniające zadane kryterium wyszukiwane są dzięki zastosowaniu metody FindNext z takim samym wyra­ żeniem (jest to sposób odmienny niż np. w funkcjach API, gdzie FindNext nie zawiera parametru, a dziedziczy go po ostatnim wywołaniu F in d F irs t). Możliwe jest zatem zasto­ sowanie różnych wyrażeń w obu metodach, co nie powoduje sygnalizowania błędu, ale może spowodować działanie procedury niezgodne z zamierzeniem programisty! W przykładzie do zorganizowania pętli zastosowano instrukcję Do U n t il z wyraże­ niem rst.N oM atch, które przyjmuje wartość TRUE, gdy nie zostanie znaleziony re­ kord spełniający kryterium wyszukiwania. Dodatkowo zastosowano jawne odwołanie się do nazw pól tabeli (zapytania) w celu wyświetlenia ich zawartości we właściwości F ie ld s C N a zw a P o la ") .Value.

Listing 5.8, Filtrowanie danych przy zastosowania mechanizmu DAO_____________________________ Dnu Dim Set Set

db As DAO.Database rst As DAO.Recordset db = DBEngine.OpenDatabaseC.\dao_adol.mdb") rst = db.OpenRecordsett"Osoby” . dbOpenflynaset)

'Z n a jd ź p ie r w s z y re k o rd ,

ir k tó r y m

n a z w is k o z a c z y n a s ię n a lite r ę " K ”

rs t.F in d F irs t "Nazwisko lik e 'K*'" 'P r z e s z u k a j la k c a łą b a z ę i p o k a z u j w y n ik i

ii’o k n ie d ia lo g o w y m

Do U ntil rst.NoMatch MsgBox rst.FieldsCN azw isko").Value & ” ” & rst.Fie ld s("im ie ").V a lu e . . "ZNALAZŁEM" rst.FindNext "Nazwisko lik e ' K*'" Loop rst.C lose

Kolejny przykład (listing 5.9) odnosi się do wyszukiwania rekordów względem poła indeksowanego, w naszym przypadku pola klucza podstawowego, co definiuje wła­ ściwość Index obiektu RecordSet, z warunkiem równościowym zawartym w metodzie Seek obiektu R ecordSet. Należy zwrócić uwagę, że operator warunku jest zawarty w zmiennej tekstowej. Możliwe jest użycie dowolnego z operatorów algebraicznych zdefiniowanych w środowisku. Podobnie jak poprzednio do stwierdzenia, czy został znaleziony odpowiedni rekord (zestaw rekordów), użyta została właściwość NoMatch, a dokładniej mówiąc, jej zaprzeczenie. Wynik jest prezentowany w oknie dialogowym typu Message Box. W przypadku gdy zastosowane wyrażenie spowoduje wygenerowa­ nie nie pojedynczego rekordu, a zestawu rekordów', wyświetlany jest pierwszy rekord tego zestawm. Pozostałe rekordy mogą być odczytane przez zastosowanie pętli z na­ wigacją metodą MoveNext, jak to zostało pokazane w poprzednich przykładach.

163

Rozdział 5. ♦ Mechanizmy wymiany danych Listing 5.9. Przeszukiwanie z użyciem klucza podstawowego przy zastosowaniu mechanizmu DAO Dim Dim Set Set

db As DAO.Database rs t As DAO.Recordset db = DBEngine.OpenDatabaseC.\dao_adol.mdb") rs t = db.OpenRecordset("Osoby". dbOpenTable)

' U sta w

in d e k s o w a n ia p o k lu c z u p o d s ta w o w y m

ir ta b e li

rst.Index = "PrimaryKey"

' Z n a jd ź r e k o r d o

k lu c z u n u m e r 10

rst.Seek "=". 10

' W przyp a d ku

o d s z u k a n ia p o k a ż r e z u lta t

w o k n ie d ia lo g o w y m

I f Not rst.NoMatch Then MsgBox rst.Fields("Nazwisko").Value & " " & rst.Fields("idosoby").Value, , "ZNALAZŁEM" End I f rst.Close db.Close

Mechanizm DAO pozwala również na filtrowanie pobranego zestawu rekordów. Tak jak pokazano w następnym przykładzie (listing 5.10), gdzie zdefiniowane zostały dwa obiekty typu RecordSet. Pierwszy z nich jest zasilony zawartością tabeli, tak jak poka­ zywano to w poprzednich przykładach. Natomiast drugi z nich, na skutek zastosowania właściwości F i l t e r na źródłowym zestawie rekordów, jest zasilony na skutek otwarcia źródłowego zestawu rekordów z odfiltrowanym zestawem rekordów. Taki mechanizm pozwala na tworzenie hierarchicznego filtrowania: drugi zestaw zawiera dane spełniające pierwsze kryterium, trzeci — pierwsze i drugie kryterium itd. Listing 5.10. Określenie filtru na danym zbiorze rekordów przy’ zastosowaniu mechanizmu DAO Dim db As DAO.Database Dim rs t As DAO.Recordset Dim r s t F lt As DAO.Recordset Set db = DBEngine.OpenDatabaseC.\dao_adol.mdb") Set rs t = db.OpenRecordsett"Osoby". dbOpenDynaset) ' U s ta w ie n ie fi ltr o w a n ia d la r e k o r d ó w

r s t . F ilt e r = "imię Is Not Nuli" 'O tw a rc ie o d filtr o w a n e g o z b io r u r e k o r d ó w

Set r s t F lt = rst.OpenRecordsett) Do Until rstFlt.EOF MsgBox rstFlt.Fields("N azw isko").Value & _ ” " & rs tF lt.F ie ld s T im ie ").V a lu e . . "ZNALAZŁEM" rstFlt.MoveNext Loop

Podobnie do filtrowania przebiega sortowanie rekordów (listing 5.11). Wymagane jest tylko zdefiniowanie właściwości Sort, która powinna zawierać listę pól analogicznie jak w klauzuli ORDER BYzapytania wybierającego. Listing 5.1 1 . Sortowanie zbioru rekordów przy zastosowaniu mechanizmu DAO Dim Dim Dim Set Set

db As DAO.Database rst As DAO.Recordset rstSort As DAO.Recordset db = DBEngine.OpenDatabaseC.\dao_adol.mdb") rs t = db.OpenRecordsett"Osoby". dbOpenDynaset)

164

Bazy danych. Pierwsze sta rcie

' U sta w ie n ie s o r to w a n ia

r e k o r d ó w r o sn ą c o

wg lin ie n ia i n a z w is k a

rs t.S o rt = "imię. nazwisko"

'O tw a r c ie p o s o r lw a n e g o z b io r u

rekordów

Set rstSort = rst.OpenRecordsett) ' W y ś w ie tle n ie p o s o r to w a n e g o z b io r u w o k n a c h d ia lo g o w y c h Do U ntil rstSort.EOF MsgBox rstS ort.Fie lds("im ie ").V alue & " ” & _ rstSort.Fields("nazw isko").Value. . "ZNALAZŁEM" rstSort.MoveNext Loop rst.Close rstSort.Close db.Close

Kolejne przykłady, które będą pokazywane, wymagają komentarza. Już w przypadku filtrowania czy sortowania rekordów po stronie końcówki klienta uważny czytelnik może mieć wątpliwości związane z tym, że każda z tych czynności da się zastąpić do­ brze zdefiniowanym źródłem danych dla obiektu RecordSet — zastosowanie zapyta­ nia wybierającego z klauzulą WHERE albo ORDER BY. Negatywnym objawem stosowania obu metod po stronie końcówki klienta jest w większości przypadków nadmiarowe prze­ chowywanie dwóch zestawów rekordów, co ma wpływ na rozmiar pamięci. Ponadto dwukrotne pozyskiwanie zestawu rekordów powoduje zwiększenie czasu przetwarza­ nia. Stosowanie tych dwóch metod wydaje się uzasadnione tylko w przypadkach, gdy chcemy dokonać porównań obu zestawów rekordów, np. przed filtrowaniem i po. W takim przypadku omijamy jedno połączenie z serwerem, ponieważ odwołanie dotyczy już pobranego na stronę klienta zestawu rekordów. Dużo większe obiekcje budzi natomiast stosowanie metod modyfikujących dane po stronie klienta i odsyłanie ze­ stawu rekordów na serwer. W tym przypadku bardziej opłacalne wydaje się przesianie zapytania modyfikującego dane do serwera i wykonanie go po jego stronie. Ta metodyka zostanie opisana później. W tym miejscu zamieszczam przykłady związane z modyfi­ kowaniem danych po stronic klienta, mając jednak przekonanie, że ich stosowanie po­ winno zostać ograniczone tylko do bezwzględnie niezbędnych warunków i stosowane w praktyce w ograniczonym zakresie. Kolejny przykład (listing 5.12) pokazuje możliwość dopisania nowego rekordu do ta­ beli definiowanej przez zapytanie wybierające (perspektywa). Pierwszym etapem jest stworzenie przestrzeni na nowo wstawiany rekord przez wywołanie metody AddNew. Trudno tu mówić o dodaniu pustego rekordu, mając świadomość, że definiowany ze­ staw rekordów może dotyczyć tabeli nieposiadającej automatycznie inkrementowanego klucza podstawowego (w tym przypadku próba dodania pustego rekordu składającego się z samych wartości NULL zakończyłaby się komunikatem o błędzie). Kolejny krok to podstawienie pod pola zestawu rekordów danych przy zastosowaniu właściwości F ie ld s z odpowiednim wskazaniem do pola, podobnie jak to miało miejsce przy ich odczytywaniu. Ostatnim etapem jest przesianie danych do serwera i wpisanie ich do tabeli przez użycie metody Update dla obiektu RecordSet. Warto zauważyć, że pomi­ jane przy wstawianiu do tabeli pola muszą spełniać (podobnie jak w przypadku za­ pytania INSERT) co najmniej jeden z trzech warunków: pozwalać na przyjęcie wartości NULL, być automatycznie inkrementowane lub mieć zdefiniowaną wartość domyślną. W prezentowanym przykładzie zastosowano również właściwość LastM od ifie d obiektu RecordSet w celu pokazania ostatnio zmodyfikowanego rekordu (w naszym przypadku nowo dodanego rekordu).

Rozdział 5. ❖ Mechanizmy wymiany danych

165

Listing 5.12. Poderwanie nowych rekordówprz}1zastosowaniu mechanizmu DAO____________ Dim Dim Set Set

db As DAO.Database rs t As DAO.Recordset db = DBEngine.OpenDatabaseC.\dao_adol.mdb") rs t = db.OpenRecordsetCSELECT nazwisko, imię FROH osoby", dbOpenDynaset)

'N o w y r e k o r d d o

d o d a n ia

rst.AddNew

' O k r e ś le n ie

w a r to ś c i p ó l r e k o r d u d o d o d a n ia

rst.Fields("nazw isko” ).Value = "Nowacki" rst.F ie ld st"im ię ").V alu e = "Karol”

'Z a p is a n ie n o w e g o

rekordu d o b a zy

rst.Update 'P o k a ż o s ta tn io z m o d y fik o w a n y r e k o r d —tu ta j d o p is a n y

rst.Bookmark ** rst.LastModified MsgBox rst!im ię & ” ” & rstlnazwisko. . "DODANO" rst.Close db.Close

Według bardzo podobnego schematu przebiega modyfikowanie danych (listing 5.13). Pierwszym krokiem jest otwarcie (przygotowanie) do edycji zdefiniowanego zestawu re­ kordów. Następnie definiujemy wartość dla każdego z modyfikowanych pól. Modyfikacja jest zatwierdzana dzięki wykonaniu metody Update. Należy zwrócić uwagę, że zakres modyfikowanych rekordów jest definiowany przez zestaw rekordów w klauzuli WHERE. Listing 5.13. Modyfikacja rekordów przy zastosowaniu mechanizmu DAO_________________________ Dim db As DAO.Database Dim rs t As DAO.Recordset Set db = OBEngine.OpenDatabaseC.\dao_adol.mdb") Set rs t - db.OpenRecordset ("SELECT * FROM Osoby WHERE imię IS NULL". dbOpenDynaset)

' U sta w ie n ie r e k o r d u

d o m o d y fik a c ji

rs t.E d it

' U s ta w ie n ie w a r to ś c i m o d y fik o w a n y c h p ó l rst.Fie1ds("im ie").Value = "????"

'Z a p is z z m ia n y a k tu a ln e g o

re k o r d u

rst.Update rst.Close db.Close

Podobnie jak do rekordów tabeli możliwe jest odczytanie rekordów z poziomu zdefi­ niowanego i zapisanego w kontenerze zapytania (listing 5.14). Mechanizm ten jest analo­ giem dostępu do danych za pośrednictwem perspektyw. Należy podkreślić, że zdefi­ niowane zapytanie może zawierać dowolne elementy dostępne przy definiowaniu zapytań wybierających — filtrowanie, sortowanie, wyrażenia, w tym funkcje agregujące, etc. W pokazanym przykładzie odczytujemy wszystkie wypłaty wyższe od średniej wypłaty w firmie (tak skonstruowano zapytanie wybierające). Listing 5 .1 4 . Przeszukiwanie bazy z metodą FOR EACH w odniesieniu do zapisanego u> kontenerze zapytania przy zastosowaniu mechanizmu DAO_____________________________________________ Dim db As DAO.Database Dim rst As DAO.Recordset Dim fld As DAO.Field

166

Bazy danych. Pierwsze sta rcie Dim opis As String Set db = DBEngine.OpenDatabaseC.\dao_adol.mdb") Set rs t = db.OpenRecordset("Zarobki_ponad_srednia". dbOpenForwardOnly. dbReadOnly)

' W y ś w ie tl r e k o r d y «■o k n ie d ia lo g o w y m

z u ży c ie m m e to d y F o r F a c h ...

Do U ntil rst.EOF opis = For Each fld In rs t.F ie ld s opis = opis & fld.Value & " " Next MsgBox opis. . "WYBRANO" rst.MoveNext Loop rst.C lose

Ponieważ zapisane w kontenerze zapytanie może zawierać parametry, mechanizm DAO pozwala na przypisanie im wartości (listing 5.15), a następnie odczytanie rekordów zwracanych przez takie zapytanie. Należy zwrócić uwagę, że w tym przypadku ko­ nieczne jest odwołanie się do kolekcji QueryDefs w celu określenia wartości parametru. W naszym przypadku jego wartość określa kontrolka minimum znajdująca się w obrębie formularza, z którego wywołano procedurę. Kolejne rekordy wyświetlane są w oknach dialogowych typu MessageBox. Listing 5.15. Dostęp do zapytań zapisanych «»kontenerze bazy ze zdefiniowanym parametrem przy zastosowaniu mechanizmu DAO Dim Dim Dim Dim Dim Set

db As DAO.Database qdf As DAO.Quer.yDef rs t As DAO.Recordset fld As DAO.Field opis As String db = DBEngine.OpenDatabaseC.\dao_adol.mdb")

'P o b ie r z d e fin ic ję z a p y la n ia z z a p y ta ń

lr k o n te n e r z e

bazy

Set qdf = db.OueryDefst”Zarobki_ponad_wartosc")

' O k r e ś l p a r a m e tr y za p y ta n ia qdf .Parameterst"minimum") = He.minimum

'O tw ó r z z e s ta w

r e k o r d ó w b ę d ą c y c h w y n ik ie m z a p y ta n ia

Set rs t = qdf.OpenRecordset(dbOpenForwardOnly. dbReadOnly) 'W y ś w ie tl r e k o r d y

u>o k n ie d ia lo g o w y m

Do U ntil rst.EOF opis = For Each f ld In rs t.F ie ld s opis = opis & fld.Value & " " Next HsgBox opis. . "WYBRANO" rst.MoveNext Loop rst.Close

Jedną z ważniejszych funkcjonalności oferowanych przez mechanizmy wymiany da­ nych jest możliwość wykonania po stronie bazy danych zapytania zdefiniowanego po stronie końcówki klienta (listing 5.16). Najczęściej definicja takiego zapytania jest „skła­ dana" z fragmentów w postaci zmiennej znakowej. Mamy tutaj do czynienia z często wykorzystywanym tzw. dynamicznym językiem SQL, tzn. takim, gdzie ostateczna postać

Rozdział 5. ♦ Mechanizmy wymiany danych

167

zapytania jest generowana dopiero podczas przetwarzania. Możliwość wykonania po stronie bazy danych dotyczy zarówno zapytań modyfikujących dane, jak i tworzących lub modyfikujących obiekty bazy. Pomimo dość dużej prostoty to właśnie ten mecha­ nizm wydaje się najważniejszym elementem oferowanym przez mechanizmy wymiany danych. Przekazanie zapytania do realizacji na poziomie bazy danych (w silniejszych środowiskach serwera danych) powoduje wydajne jego przetwarzanie. Wymaga tylko przesłania do bazy łańcucha, w przeciwieństwie do metod wykonywanych po stronie klienta, które z reguły wymagają przekazania zestawu rekordów. Nawet jeśli ten zestaw jest bardzo ograniczony, to jego przetworzenie angażuje więcej zasobów, niż potrzeba na wygenerowanie nawet bardzo złożonego zapytania w postaci zmiennej znakowej. Taka metodyka budowy końcówek klienta, w której przetwarzanie jest w całości przeka­ zane na stronę bazy danych, nosi nazwę „cienkiego klienta” i jest coraz silniej propa­ gowana wśród twórców oprogramowania. W prezentowanym przykładzie zastosowano właściwość RecordsAffected w celu zapewnienia kontroli nad liczbą przetworzonych na skutek wykonania zapytania rekordów. Listing 5.16. Wykonywanie zapytań po stronie bazy — metodą Execute przy zastosowaniu mechanizmu DAO Dim db As DAO.Database Set db = DBEngine.OpenDatabaseC.\dao_adol.mdb")

' W y k o n a j z a p y ta n ie a k tu a liz u ją c e n a

ta b e li O s o b y

db.Execute "UPDATE Osoby SET nazwisko = ” & Me.TYP & "(nazwisko)"

' W y k o n a j z a p y ta n ie a k tu a liz u ją c e n a MsgBox "Przetworzono db.Close

'P r z e lic z j e s z c z e

ta b e li O s o b y

= “ & db.RecordsAffected & " wierszy". . "UWAGA"

ra z fo r m u la r z d la o d ś w ie ż e n ia d a n y c h

Me.Recalc

Ważnym elementem tworzenia oprogramowania klienckiego jest możliwość spraw­ dzenia, jakie obiekty zostały stworzone po stronie bazy danych (listing 5.17). Dotyczy to zarówno tabel, jak i zapytań (perspektyw). W kolejnym przykładzie dzięki odwoła­ niu do kolekcji TabłeDefs możemy sprawdzić, jakie tabele zostały zapisane w bazie. Jeżeli w naszym przykładzie kolekcję TabłeDefs zastąpilibyśmy kolekcją OueryDefs. otrzymalibyśmy listę zapytań, na której znalazłyby się wszystkie typy zapytań, nie tylko wybierające. Należy zwrócić uwagę na zapytania, których nazwa zaczyna się od znaku tylda ~, a których nie widać w kontenerze zapytań nawet wtedy, kiedy w opcjach ustawimy wyświetlanie obiektów systemowych i ukiytych. Zapytania o tak skonstru­ owanych nazwach stanowią źródła danych dla formularzy lub raportów. Zapytania ta­ kie są tworzone nawet wtedy, gdy obiekt źródłowy jest oparty o całą zawartość tabeli, co odpowiada zapytaniu wybierającemu SELECT * FROM T abela;. Listing 5.1 7 . Przeszukiwanie bazy— tabel przy zastosowaniu mechanizmu DAO____________________ Dim db As DAO.Database Dim tbł As DAO.TableDef Dim 1 As String

1 = •••• ' O tw ó r z b a z ą d a n y c h

Set db = DBEngine.OpenDatabaseC".\dao_ado2.mdb")

'P r z e c h o d ź p o

ta b e la c h b a z y d a n y c h i w y ś w ie tla j ic h n a z w y

For Each tbl In db.TabłeDefs 1 =1 & t b l .Name & ":"

168

Bazy danych. Pierwsze sta rcie

Next Me.Lista.RowSource = 1 db.Close

Przeszukiwanie zawartości bazy danych może być również wykonane w oparciu o ko­ lekcja C o n ta m e rs i kolekcję jej podrzędną Documents (listing 5.18). Odpowiada to przeglądaniu bazy danych w oparciu o graficznąjej prezentację w postaci zakładek (kontenerów) głównego okna bazy danych. W prezentowanym przykładzie z kolekcji C o ntam ers wyodrębniono tylko fragment należący do kategorii Tables. Przeszukanie wszystkich dokumentów tej kolekcji spowoduje wyświetlenie wszystkich tabel i zapy­ tań (również tabel i zapytań ukrytych i systemowych) oraz tak jak poprzednio zapytań stanowiących źródła danych dla formularzy i raportów. Nie istnieje kontener odpo­ wiadający samym zapytaniom czy tabelom, natomiast programista ma do dyspozycji ponadto kontenery o nazwach: Databases, Forms, Reports, DataAccessPages, S c rip ts . Modules, R e la tio n sh ip s, SysRel. Jeśli nie wymienimy konkretnego kontenera, wyświe­ tlone zostaną informacje o wszystkich dokumentach bazy. Listing 5.18. Przeszukiwanie bazy— tabelprz)> zastosowaniu mechanizmu DAO Dim Dim Dim Dim Dim Dim

11

=

db As Database c tr As Container doc As Document 11 As String aa bb "

'O tw ó r z b a z ę d a n y c h Set db = CurrentDb Set c tr = db.Containers("Tables'') ' P r z e c h o d ź p o d o k u m e n ta c h z k o n te n e r a T a b e le i w y ś w ie tla j ic h n a z w y

For Each doc In ctr.Documents aa = doc.Name 'bb = doc.Properties 11 =11 & aa & Next doc Me.Listal.RowSource = 11 Me.Refresh db.Close

Pomimo tego, że za pomocą metody Execute możemy wykonać dowolne zapytanie, również modyfikujące strukturę bazy, to mechanizm DAO oferuje możliwość tworze­ nia i modyfikacji definicji tabeli z poziomu końcówki klienta (listing 5.19). W pre­ zentowanym przykładzie kodu w oparciu o trzy pola tekstowe, z których pierwsze zawiera nazwę tabeli, a dwa pozostałe nazwy pól tabeli, tworzona jest tabela. Pierw­ szym krokiem jest wykonanie metody CreateTableDef, kolejnym dodanie pól (w przy­ kładzie założono, że oba pola są tekstowe), z ewentualną możliwością zdefiniow-ania dla nich dodatkowych ograniczeń (tutaj zdefiniowano, że pierwsze z pól nie jest wy­ magane — co i tak jest stanem domyślnym). Zapisanie tabeli, którą przed chwilą zde­ finiowaliśmy, odbywa się na skutek wykonania metody Append kolekcji T ableD efs. W celu pokazania skuteczności działania kodu lista pól jest wyświetlana w obrębie pola kombi L is t a .

Rozdział 5. ♦ Mechanizmy wymiany danych

169

Listing 5.19. Tworzenie nowej tabeli przy zastosowaniu mechanizmu DAO Dim db As DAO.Database Dim tbl As DAO.TableDef Dim table As Stnng Dim Polel As String Dim pole2 As String Dim t t As String Table = Me.Tabela Polel = Me.Polel Pole2 = Me.Pole2

' O tw ó r z b a z ę d a n y c h Set db = DBEngine.0penDatabaseC.\dao_ado2.mdb")

' U tw ó r : n o w ą ta b e lę Set tbl = db.CreateTableDef(Table) With tbl

'Z a n im ta b e la z a s ta n ie d o d a n a d o b a z y d a n y c h , ' u tw ó r : p o la i d o d a j j e d o u tw o r z o n e j ta b e li .Fields.Append .C reateField (Polel. dbText) .Fields.Append .CreateField(pole2. dbText) .Fields(l).R equired = False End With ' D o d a j u tw o r z o n ą ta b e lę d o b a z y d a n y c h

db.TableDefs.Append tbl db.Close t t = "SELECT " & Polel & Me.Lista.RowSource = t t Me.Recalc

& Pole2 & " FROM " & Tabela

Mechanizm wymiany danych DAO ma podstawową niedogodność wynikającą z kło­ potliwego realizowania połączenia z bazami innego typu niż MS Access, wymagają­ cego zdefiniowania pliku wymiany DSN. Krokiem do przodu było opracowanie me­ chanizmu RDO (Remote Data Objects), który pozwalał na komunikację z dowolną bazą bez konieczności konfiguracji ODBC (rysunek 5.3).

Rysunek 5.3. Hierarchia obiektów RDO

170

Bazy danych. Pierwsze sta rcie

Nawiązanie połączenia z bazą danych, w naszym przykładzie MS SQL Server (li­ sting 5.20), polega na zdefiniowaniu pełnego łańcucha połączeniowego. Ponieważ ustalono autoryzację na poziomie systemu operacyjnego, podawanie nazwy użytkow­ nika UID=; oraz hasła PWD=; można pominąć, pociąga to za sobą konieczność posiada­ nia uprawnień administratora w systemie operacyjnym. Przy autoryzacji na poziomie SQL Servera konieczne jest podanie obu parametrów łub ustawienie opcji zestawienia połączenia pozwalającej na skorzystanie z okienka dialogowego definiującego jego parametry', np. rdDnverPrompt. Takie rozwiązanie jest sensowniejsze z punktu widzenia ochrony danych. Po zestawieniu połączenia zdefiniowane zostało zapylanie do tabeli bazy danych, które zostało otwarte dla potrzeb obiektu rdoResultset. Obiekt ten pozwala na odczytanie zawartości kolumn, które są indeksowane od 0, tale jak w DAO. Listing 5.20. Nawiązanie połączenia przy zastosowaniu mechanizmu RDO i odczytanie pierwszego zapytania

rekordu

Dim rdb As New RDO.rdoConnection Dim rdoO As New RDO.rdoOuery Dim rdoR As RDO.rdoResultset Dim rdoE As RDO.rdoErwironment rdb.Connect = "UID=;PWD=:Database=ap: " & _ "Server=pc226-31:Driver={SQL Server) rdb.EstablishConnection rdDriverNoPrompt. True Set rdoQ.ActiveConnection = rdb rdoQ.SQL = "Select Nazwa FROM Działy ” Set rdoR = rdoO.OpenResultset(rdOpenForwardOnly) co = rdoR.rdoColumns(0).Value

Pozostałe metody dostępne w RDO są podobne do DAO, a jeszcze bardziej do omawia­ nego w kolejnym rozdziale ADO. Można powiedzieć, że czas życia RDO w świadomości programistów był bardzo krótki. Eliminując wady DAO, RDO stał się „ofiarą” nowo­ cześniejszego mechanizmu ADO, który wprowadzono prawie natychmiast po zaistnieniu tego pierwszego. Dlatego omówienie tego mechanizmu zostało ograniczone do niezbęd­ nego minimum.

Patia ©fojjesiis (AP©) Trudno powiedzieć, że mechanizm ADO (rysunek 5.4) jest prostym spadkobiercą RDO, poniew'aż w przeciwieństwie do RDO nie wykorzystuje on technologii ODBC, ale jest nakładką obiektową na znacznie nowocześniejszą technologię OLEDB (Object Linking and Embedding Database). Nie jest również kontynuatorem DAO. Można natomiast stwierdzić, że jest on najnowocześniejszym rozwiązaniem w zakresie wymiany danych. Na szczęście dla osób dobrze znających którykolwiek z pozostałych mechanizmów od strony formalnej jest w wielu miejscach bardzo do nich podobny. Trudno powiedzieć, że model ADO jest w pełni hierarchiczny jak jego protoplaści, jest raczej kolekcją w-zajemnie powiązanych hierarchii tematycznych (rysunek 5.4). Górna pozioma linia wiążąca te hierarchie ma na celu bardziej zobrazowanie wspólnej biblioteki je zawierającej, a w tym znaczeniu równoważności ich obiektów nadrzędnych, niż rze­ czywistej łączności czy powiązania.

Rozdział 5. ♦ Mechanizmy wymiany danych

171

Rysunek 5.4. Modni Obiektowy ADO

Jak zwykle podstawowym problemem zastosowania mechanizmu wymiany jest ze­ stawienie połączenia z bazą danych (listing 5.21). Metodologia stosowana w ADO przypomina bardziej to, co można było zobaczyć w przypadku RDO, niż DAO. Defi­ niowany jest bowiem pełny opis łańcucha połączeniowego wykorzystującego OLEDB i opis parametrów bazy, z którą będziemy chcieli to połączenie nawiązać. Ponieważ OLEDB pozwala na zdefiniowanie połączenia z każdym typem danych, konieczne jest w pierwszym rzędzie określenie dostarczyciela usługi Provider. W prezentowanym przykładzie zrealizujemy połączenie z serwerem MS SQL Server. Zadeklarowana zo­ stała zmienna biblioteki ADO będąca nowym obiektem reprezentującym połączenie Connection. Definicja połączenia została zrealizowana dzięki ustawieniu właściwości obiektu Connection: dostarczyciela usługi (" P ro v id e r " — w przypadku serwera MS wartość = "sqloledb"), nazwy serwera ("Data Source" — odpowiada nazwie komputera, hosta, na którym zainstalowano SQL Server), nazwy bazy danych " I n i t i a l Catalog" oraz nazwy użytkownika "User Id" i hasła "Password". Pozostałe parametry nie są obowiązkowe, w przykładzie reprezentowane są przez czas oczekiwania na połączenie "ConnectionTimeout". Zdefiniowane mogą być również kolejne właściwości, np. zablo­ kowana w przykładzie zintegrowana ochrona "In te g ra te d S e c u r it y " pozwalająca korzystać z autoryzacji na poziomie systemu operacyjnego — zbędne są wtedy dane dotyczące autoryzacji na serwerze SQL. Ostatecznym krokiem jest nawiązanie po­ łączenia przy zastosowaniu metody Open. Listing 5.21. Nawiązanie połączenia przj’ zastosowaniu mechanizmu ADO_________________________ Dim cn As New ADODB.Connection UserName = "sa" Password = "hasło” ServerName = "serwer” DBName = "baza" cn. ConnectionTimeout = 25 cn.Provider = “sqloledb" cn.PropertiesCData Source").Value = ServerName c n .P ro p e rtie sC In itia l Catalog"),Value = DBName 'cn.PropertiesOIntegrated Security").Value = "SSPI”

Bazy danych. Pierwsze sta rcie

172 cn.PropertiesCU ser IcT).Value = UserName cn.Properties(“password” ).Value = Password cn.Open

Zamiast definiować kolejne wartości właściwości obiektu Connection, możemy zdefi­ niować bezpośrednio łańcuch połączeniowy C onnectionString (listing 5.22), wskazując w nim separowane średnikami elementy związane z dostarczycielem usługi, nazwą hosta oraz bazą danych. Uzupełnieniem są dane związane z autoryzacją, które również można umieścić bezpośrednio w definicji łańcucha połączeniowego. Listing 5.2 2 . Nawiązanie połączenia przy zastosowaniu mechanizmu ADO_________________________ nazwabazydanych = in it ia l cata1og=” & Me.baza.Text nazwaserwera = "data source= " & He.servername.Text db.ConnectionString = "Provider=SQLOLEDB.l:" & nazwaserwera & _ nazwabazydanych db.Propertiest"User id").Value = Me.Textl.Text db.Properties("Password").Value = Me.Text2.Text cn.Open

Najprostszym rozwiązaniem jest podanie tych danych w postaci łańcucha bezpośrednio w miejscu nawiązywania połączenia metodą Open (listing 5.23). Listing 5.23. Nawiązanie połączenia przy>zastosowaniu mechanizmu ADO Db.open "Provider=SQLOLEDB.l:" & nazwaserwera & nazwabazydanych. Me.Textl.Text. Me.Text2.Text

Największa zaletą mechanizmu ADO, podobnie jak RDO, jest możliwość nawiązania bezpośredniego połączenia (bez potrzeby definiowania pliku wymiany — DAO), jeśli tylko dysponujemy odpowiednimi sterownikami. Jednak za tę cechę trzeba zapłacić skomplikowaną postacią łańcucha połączeniowego, którego składnia jest różna dla praktycznie każdego z dostarczycieli usług. Kolejnym przykładem jest nawiązanie połą­ czenia z bazą danych MS Access w wersji 2000 lub nowszej. W takim przypadku do­ starczyciel usług jest definiowany jako Microsoft. Jet.OLEDB.4.0 (we wcześniejszych wersjach 3.5). Tę informacje w przypadku niestosowania ochrony systemem użytkow­ ników i haseł należy uzupełnić jeszcze o nazwę bazy, z którą połączenie ma być na­ wiązane — nazwa kwalifikowana ze ścieżką. W przypadku zdefiniowania użytkowników informacja ta musi być wzbogacona o dane niezbędne do autoryzacji. W przykładzie (li­ sting 5.24) pokazano możliwość odczytania pełnej informacji związanej z połączeniem dzięki odczytaniu właściwości C on n e ction S trin g . Listing 5.24. Nawiązanie połączenia przy zastosowaniu mechanizmu ADO Dim cnn As New ADODB.Connection cnn.Open "Provider=Hicrosoft.Jet.0LEDB.4.0;" & "Data_ Source= ” & nazwa & ” MsgBox "otwarto bazę " & cnn.ConnectionString. . _ "SUKCES" cnn.Close

Rozdział 5. ♦ Mechanizmy wymiany danych

173

W przypadku łączenia się z bazą danych MS Access w większości przypadków będziemy chcieli się połączyć z bieżącą bazą (tą samą. z której piszemy kod VBA). W tym przypadku zamiast definiować własnoręcznie łańcuch połączeniowy, możemy użyć metody Connection obiektu CunrentProject (listing 5.25), która zwraca pełną informację o po­ łączeniu do aktualnie otwartej bazy. Listing 5.25. Nawiązanie połączenia przy zastosowaniu mechanizmu ADO Dim cnn As New ADODB.Connection Set cnn = CurrentProject.Connection MsgBox "otwarto bazę " & cnn.ConnectionString. . "SUKCES" cnn.Close

Ponieważ, tak jak powiedziano, nie istnieje żadna ogólna metoda tworzenia łańcucha połączeniowego, przytoczone zostaną przykłady dla kilku najpopularniejszych baz. Pierwszą niebędącą produktem Microsoftu jest MySQL (listing 5.26), dla której zde­ finiować poza dostawcą powinniśmy: nazwę komputera (tutaj dana przez IP, można również stosować nazwy logiczne — tu odpowiednikiem byłby lo c a lh o s t), numer portu, na którym łączy się baza, nazwę bazy danych oraz dane niezbędne do autoryzacji — użytkownik, hasło. Listing 5,26. Nawiązanie połączenia przy zastosowaniu mechanizmu ADO_________________________

Dim oConn As New ADODB.Connection oConn.Open ”Driver={mySQL}&_ "Server=127.0.0.1:" &_ "Port=3306:” &_ "Database=baza:" &_ ”Uid=uzytkownik:" &_ "Pwd=haslo:" Nieco inaczej wygląda sprawa w przypadku połączenia z bazą dBase (listing 5.27), dla której należy podać identyfikator numeryczny sterownika oraz pełną nazwę ścieżki, w której znajdują się pliki bazy (baza lego typu przechowuje każdą z tabel w oddzielnym pliku, oddzielne pliki przydzielane są również na indeksy, o ile je zdefiniowano). Listing 5.27. Nawiązanie połączenia przy zastosowaniu mechanizmu ADO Dim oConn As New ADODB.Connection oConn.Open ”Driver={Microsoft dBASE Driver (*.dbf)}:" & _ "DriverID=277:" & _ ”Dbq=c:\path;"

Często wykorzystywany jest dostęp do danych w postaci arkuszy Excela (listing 5.28), do tej pory znaczna ilość cenników jest tworzona w takiej postaci, ale możemy również znaleźć wiele innych danych, które mogą nam posłużyć za słowniki dla potrzeb bazy. Podobnie jak w przypadku dBase konieczne jest podanie identyfikatora sterownika, ale dla odmiany w tym przypadku wskazujemy konkretny plik — nazwa kwalifikowana. Możliwe jest również wskazanie domyślnego katalogu — opcjonalne.

174

Bazy danych. Pierwsze sta rcie

Listing 5.28. Nawiązanie połączenia przy’zastosowaniu mechanizmu ADO Dim oConn As New ADODB.Connection oConn.Open "Driver={Microsoft Excel Driver (* .x ls)}:" & ”DriverID=790:" & "Dbq=c:\arkusz.xls:" & _ "DefaultDir=c:\:"

W przypadku serwera Sybase (serwer, z którego wywodzi się MS SQL Server w swej pierwotnej formie), należy wskazać domyślną ścieżkę do bazy, nazwę pliku bazy oraz dane do autoryzacji (listing 5.29). Możliwe jest określenie pliku wymiany użytkownika. Listing 5.29. Nawiązanie połączenia przy>zastosowaniu mechanizmu ADO_________________________ Dim oConn As New ADODB.Connection oConn.Open "ODBC: Dnver=Sybase SQL Anywhere 5.0:” & "DefaultDir=c:\path\:“ & _ "Dbf=c:\path\baza.db:” & _ "Uid=user:" & _ "Pwd=pass:” & _ "Dsn="":“

Możemy również połączyć się z bazą ORACLE (listing 5.30), korzystając z mechanizmu ODBC (bez definiowania pliku wymiany). W tym celu oprócz dostarczyciela usługi należy wskazać serwis (bardzo często utożsamiany z nazwą instancji serwera) oraz dane dla uwierzytelnienia. Niestety sama definicja połączenia nie jest wystarczająca do na­ wiązania połączenia z ORACLE. Oprócz tego koniecznym jest, aby na komputerze, z którego nawiązujemy połączenie, były zainstalowane usługi sieciowe ORACLE — wiąże się to z koniecznością zainstalowania części oprogramowania klienta tej firmy. Listing 5.30. Nawiązanie połączenia przy zastosowaniu mechanizmu ADO Dim oConn As New ADODB.Connection oConn.Open "Driver={Microsoft ODBC for Oracle}:" & _ "Server=serwis:" & "Uid=uzytkownik:" & _ "Pwd=haslo:"

Tak samo jak w przypadku stosowania mechanizmu ODBC do nawiązania połączenia z ORACLE możemy wykorzystać mechanizm OLEDB. W takim przypadku zmienia się tylko nazwa dostarczyciela usługi (listing 5.31). Uwaga dotycząca instalacji usług sieciowych ORACLE pozostaje bez zmian. Listing 5 .31. Nawiązanie połączenia przy zastosowaniu mechanizmu ADO_________________________ Dim oConn As New ADODB.Connection oConn.Open "Provider=msdaora:" & "Data Source=serwis:” & _ "User Id=zytkowmk:" & _ "Password=haslo:"

Rozdział 5. ♦ Mechanizmy wymiany danych

175

Po nawiązaniu połączenia możliwe sąjuż operacje na danych, z których najważniejszą jest nawigowanie po zestawie rekordów i możliwość ich odczytania (listing 5.32). Dalsze przykłady będą realizowane tylko dla połączenia z bazą MS Access, ale w przypadku zmiany łańcucha połączeniowego, a co z tym związane połączenia się z innym źródłem danych, będą nadal poprawne. Struktura przykładów jest taka sama jak dla DAO. za­ chowano sposób wyświetlania wyników — albo w postaci listy, albo okna dialogowego MsgBox. Listing 5.32. Nawigacja po polach i rekordach przy zastosowaniu mechanizmu ADO________________ Dim Dim Dim Dim Dim

1=

cnn As New ADODB.Connection rst As New ADODB.Recordset f ld As ADODB.Field 1 As String i As Long

' O tw ó r z p o łą c z e n ie

cnn.Open "Provider=Microsoft.Jet.0LEDB.4.0:” & _ "Data_Source=.\dao_adol.mdb:” ' T ry b o tw ie r a n ia fo r w a r ii- o n ly , r e a d -o n ly

rst.Open _ "SELECT nazwisko, imię FROM osoby", cnn. adOpenForwardOnly. adLockReadOnly ' W y ś w ie tl w a r to ś c i d la p ó l z r e k o r d ó w

wp o s ta c i lis ty k o m b i

Do U ntil rst.EOF i =0 For Each fld In rs t.F ie ld s i =i +1 1 = 1 & fld.Value & V Next rst.MoveNext Loop Me. l i sta.ColumnCount = i Me.lista.RowSource = 1 ' Z a m k n ij z e s ta w r e k o r d ó w

rst.Close cnn.Close

Jak pokazano w kolejnym przykładzie, rozwiązania programistyczne wykorzystane do wyświetlenia pełnej zawartości zestawu danych są analogiczne jak w przypadku stosowania mechanizmu DAO. Zadeklarowane zostały trzy zmienne obiektowe: od­ powiadająca za nawiązanie połączenia, przechowująca zestaw rekordów oraz zmienna przechowująca dane o konkretnym polu. Po nawiązaniu połączenia z bazą (w oma­ wianym przykładzie MS Access) otwarto zestaw rekordów zdefiniowany zapytaniem wybierającym. Wykorzystano metodę Open obiektu Recordset, której podstawowymi parametrami są definicja zestawu rekordów (zmienna zawierająca zapytanie wybie­ rające, nazwa zapisanego w kontenerze zapytania lub tabeli) oraz definicja połączenia zawarta w zmiennej typu Connection. Parametry związane ze sposobem nawigowania i trybem otwarcia są opcjonalne, w przykładzie ustalone na nawigację tylko do przodu oraz pozwalające tylko na odczyt danych. Operacje odczytu z otwartego zestawu re­ kordów są prostym analogiem prezentowanych w DAO. Zastosowano przewijanie w obrębie pętli Do U n til rst.EOF, z warunkiem opartym o wartość właściwości End Of F i l e EOF, natomiast w obrębie rekordu pola odczytywane są w obrębie pętli For Each ze zmienną typu F ie ld przebiegającą przez wszystkie wartości z kontenera F ie ld s .

176

Bazy danych. Pierwsze starcie

Kolejny przykład (listing 5.33) pokazuje metodę odczytywania bieżącego położenia w zestawie rekordów, tutaj pozycji po otwarciu zestawu rekordów i po przejściu do ostatniego z nich. Najważniejszy wniosek, jaki płynie z tego przykładu, to fakt, że numeracja rekordów w tym mechanizmie wymiany rozpoczyna się od wartości 1. Czyli ostatni rekord w zestawie będzie miał numer N. Listing 5.33. P o rc ja kursora pizzy zastosowaniu mechanizmu ADO Dim Dim Dim Dim Dim

cnn As New ADODB.Connection rs t As New ADODB.Recordset f ld As ADODB.Field 1 As String i As Long

' Otwórz połączenie cnn.Open ''Provider=Microsoft.Jet.OlEDB.4.0;“ & "Data_Source=.\dao_adol.mdb:"

' T ry b

o tw ie r a n ia fo r w a r d - o n ły , r e a d -o n ly . O tw ó r z r e c o r d s c t

rst.CursorLocation = adUseClient rst.Open "SELECT * FROM osoby", cnn. adOpenKeyset. adLockOptimistic. adCmdText

' P o d a j b e z w z g lę d n e p o ło ż e n ie MsgBox rst.AbsolutePosition. . "Pozycja przed"

'I d ź d o

o s ta tn ie g o r e k o rd u

rst.MoveLast

'P o d a j

b e z w z g lę d n e p o ło ż e n ie

MsgBox rst.AbsolutePosition. . "Pozycja po"

' Z a m k n ij z e s ta w

reko rd ó w

rst.C lose cnn.Close

Podobnie jak DAO mechanizm ADO oferuję metodę wyszukiwania rekordów spełniają­ cych określone kryterium (listing 5.34). W przeciwieństwie do poprzedniego rozwią­ zania tym razem wykorzystywana jest tylko jedna metoda Find. Listing 5.34. Wyszukiwanie rekordów przy zastosowaniu mechanizmu ADO Dim cnn As New ADODB.Connection Dim rs t As New ADODB.Recordset

'O tw ó r z p o łą c z e n ie cnn.Open "Prbvider=Microsoft.Jet.0LEDB.4.0:" & "Data Source=.\dao_adol.mdb:"

'O tw ó iz z e s ta w

rekordów

rst.Open "Osoby", cnn. adOpenKeyset. adLockOptimistic

' Z n a jd ź p ie r w s z e n a z w is k o ,

k tó r e z a c z y n a s ie o d "k o w "

rst.F in d "nazwisko 1ike ’ kow*‘ "

' W y p isz w s z y s tk ie

re k o r d y , d la k tó ry c h n a z w is k o r o z p o c z y n a s ię o d "k o w "

Do U ntil rst.EOF MsgBox rst.FieldsCN azw isko” ).Value & " " & rs t.F ie ld st"im ię ").V a lu e . ._

"ZNALAZŁEM" rst.F in d "nazwisko lik e 'kow*'” . 1 Loop

’Z a m k n ię c ie z e s ta w u rst.Close cnn.Close

reko rd ó w

Rozdział 5. ♦ M echanizmy wymiany danych

177

Również filtrowanie w WDO jest analogiem starszego rozwiązania (listing 5.35). jed­ nak należy zwrócić uwagę na brak możliwości filtrowania hierarchicznego. Listing 5.35. Filtrowanie rekordów przy* zastosowaniu mechanizmu ADO Dim cnn As New ADODB.Connection Dim rs t As New ADODB.Recordset

' O tw ó r : p o łą c z e n ie cnn.Open "Provider=Microsoft.Jet.0LEDB.4.0:" & "Data Source=.\dao_adol.mdb:"

'O tw ó r z z e s ta w

reko rd ó w

rst.Open "Osoby", cnn. adOpenKeyset. adLockOptimistic 'F iltr o w a n ie r e k o r d ó w ta k, a b y w y k lu c z y ć p r z y p a d k i, g d y u n ie

N U LL

r s t . F ilt e r = "imię <> N u li” Do Until rst.EOF MsgBox rst.FieldsCN azw isko") .Value & " " & r s t .F ie ld s ( ”im ie").Value. "ZNALAZŁEM" rst.HoveNext Loop 'Z a m k n ię c ie z e s ta w u r e k o r d ó w

rst.Close cnn.Close

Kolejna, tym razem ścisła analogia między obydwoma mechanizmami wymiany danych występuje w przypadku sortowania zestawu rekordów (listing 5.36). Listing 5 .3 6 . Sortowanie rekordów przy* zastosowaniu mechanizmu ADO__________________________ Dim cnn As New ADODB.Connection Dim rs t As New ADODB.Recordset

' O tw ó r z p o łą c z e n ie cnn.Open ”Provider=Microsoft.Jet.OLEDB.4.0:” & "Data Source=.\dao_adol.mdb:"

'O tw ó r z z e s ta w

reko rd ó w

rst.CursorLocation = adUseClient rst.Open "Osoby", cnn. adOpenKeyset. adLockOptimistic

'P o s o r tu j r e k o r d y w e d łu g k lu c z a

u n ie , n a z w is k o (r o sn ą c o )

rst.S o rt = "imię, nazwisko" Do U ntil rst.EOF MsgBox rst.F ie lds("im ie ").V a lu e & " " & rst.FieldsCnazw isko").Value. . "ZNALAZŁEM" rst.MoveNext Loop

'Z a m k n ij z e s ta w

reko rd ó w

rst.Close cnn.Close

Dodanie nowego rekordu z poziomu ADO (listing 5.37) wymaga po otwarciu połą­ czenia ustanowienia nowego rekordu metodą AddNew, przypisaniu w:artości odpowied­ nim polom, a następnie zatwierdzeniu zmiany przez wykonanie metody Update. Listing 5.3 7 . Dodawanie rekordu przy’ zastosowaniu mechanizmu ADO Dim cnn As New ADODB.Connection Dim rst As New ADODB.Recordset

' U tw ó r z p o łą c z e n ie cnn.Open "Provider=Microsoft.Jet.0LEDB.4.0:" & "Data Source=.\dao_adol.mdb:"

178

Bazy danych. Pierwsze sta rcie

' O tw ó r : z e s ta w

reko rd ó w

rst.Open "SELECT nazwisko, imię FROM osoby", cnn. adOpenKeyset. adLockOptimistic

'D o d a j n o w y r e k o r d rst.AddNew

' W p is : w a r to ś c i u»p o la rst.nazwisko = "Nowacki” rst.im ie = "Karol"

' Z a p is : z m ia n y

w p r o w a d zo n e d o a k ty w n e g o r e k o r d u

u’z e s ta w ie

reko rd ó w

rst.Update

' W y ś w ie tl k o m u n ik a t o w p is ie MsgBox rs t. inne & “ ”

' Z a m k n ij z e s ta w

&

rst.nazwisko. . "DODANO"

rekordów

rst.C lose cnn.Close

Aktualizacja danych (listing 5.38) wymaga natomiast otwarcia zestawu rekordów, podania nowych wartości pól i zatwierdzenia metodą Update. Należy pamiętać, że aktualizacji — zmianie na nowe wartości — podlegają pola wszystkich rekordów otwartego zestawu. Należy w związku z tym zwracać baczną uwagę na stosowanie klauzuli WHERE przy definiowaniu zestawu rekordów. Listing 5.38. Aktualizacja— modyfikacja rekordu przy zastosowaniu mechanizmu ADO_____________ Dim cnn As New ADODB.Connection Dim rst As New ADODB.Recordset

' O tw ó r z p o h ic z e n ie cnn.Open ”Provider=Microsoft.Jet.0LEDB.4.0:" & "Data Source=.\dao_adol.mdb:"

'O tw ó r : z e s ta w

rekordów

rst.Open "SELECT * FROM Osoby WHERE imię IS NULL". cnn,_ adOpenKeyset. adLockOptimistic

'Z a k tu a liz u j p o le

o n a z w ie Im ię

u>p ie r w s z y m

r e k o r d z ie

rst.F ie ld s("Im ie “ ).Value = " ! ! ! ”

'Z a p a m ię ta j z m ia n y w p r o w a d z o n e d o a k ty w n e g o

reko rd u

rst.Update

' Z a m k n ij z e s ta w

reko rd ó w

rst.C lose cnn.Close

Jeśli przy pomocy ADO będziemy chcieli otworzyć zestaw rekordów zdefiniowany w postaci zapisanego w kontenerze zapytania (listing 5.39), postępujemy tak samo jak przy otwieraniu tabeli lub zapytania zdefiniowanego ad hoc, za wyjątkiem tego, że pa­ rametr określający typ otwieranego obiektu musi zostać ustawiony na wartość odpowia­ dającą predefiniowanej zmiennej adCmdStoredProc. Sygnalizuje to sytuację występującą na poziomie dużych baz danych, w których tworzone mogą być perspektywy (odpowied­ nik zapisanych zapytań wybierających) oraz procedury zwracające wynik w postaci zestawu rekordów. W tych środowiskach zarówno perspektywą jak i procedura (funkcja) określane są przez ten sam parametr adCmdStoredProc. Listing 5.39. Otwarcie zapytania (procedur}’) przy zastosowaniu mechanizmu ADO________________ Dim Dim Dim Dim

cnn As New ADODB.Connection rs t As New ADODB.Recordset f ld As ADODB.Field opis As String

Rozdział 5. ♦ M echanizmy wymiany danych

179

' O tw ó r z p o łą c z e n ie cnn.Open "Provider=Microsoft.Jet.0LEDB.4.0:" & “Data Source=.\dao_adol.mdb:" ' O tw ó r z z e s ta w r e k o r d ó w

rst.Open "zarobki_ponad_srednia". cnn. adOpenForwardOnly. adLockReadOnly. adCmdStoredProc ‘W y ś w ie tla j r e k o r d y

w o kn ie

Do Until rst.EOF opis = " n For Each fld In rs t.F ie ld s opis = opis & fld.Value & " “ Next HsgBox opis. . "WYBRANO" rst.MoveNext Loop

'Z a m k n ij z e s ta w

reko rd ó w

rst.Close cnn.Close

Oprócz dostępu do danych w tabelach mechanizm ADO oferuje możliwość wykony­ wania zapytań modyfikujących dane oraz modyfikujących i tworzących elementy bazy (listing 5.40) dzięki zastosowaniu metody Execute obiektu Connection. Listing 5.40. Wykonanie zapytania modyfikującego (procedury) przy zastosowaniu mechanizmu ADO Dim cnn As New ADODB.Connection Dim iAffected As Integer

'O tw ó r z p o łą c z e n ie cnn.Open "Provider=Hicrosoft.Jet.0LEDB.4.0:" & "Data Source=.\dao_adol.mdb:"

' W y k o n a j z a p y la n ie cnn.Execute "UPDATE Osoby SET nazwisko = " & Me.TYP & "(nazwisko)". iAffected. adExecuteNoRecords MsgBox "Przetworzono = " & iAffected & " w ierszy". . "UWAGA"

' Z a m k n ij p o łą c z e n ie cnn.Close Me.Recalc

Mechanizm ADO zapewnia również możliwość odczytania nazw elementów bazy (tabele, perspektywy) (listing 5.41). W tym przypadku należy jednak użyć biblioteki ADOX, która stanowi uzupełnienie dotychczas stosowanej biblioteki ADODB między innymi o omawianą tutaj funkcjonalność. Nawiązanie połączenia odbywa się tym ra­ zem za pomocą metody A ctive C o n n e ctio n , o postaci takiej samej jak dotąd stosowane Connection. W prezentowanym przykładzie należy zwrócić uwagę na fakt, że tabele i zapisane zapytania są traktowane tak samo, stąd zastosowano dodatkowy warunek dotyczący właściwości Type obiektu Table, eliminujący zapytania (perspektywy). Listing 5.41. Nawigacja po obiektach (tabelach) przy zastosowaniu mechanizmu ADO_____________ Dim cat As New ADOX.Catalog Dim tbl As AD0X.table Dim 1 As String

1=' O tw ó r z p o łą c z e n ie

cat.ActiveConnection = "Provider=Microsoft.Jet.0LEDB.4.0:" &

180

Bazy danych. Pierwsze sta rcie "Data Source=.\dao_ado2.mdb:"

' P r z e s u w a j s ię p o

w s z y s tk ic h ta b e la c h i w y św ie tla j ic h n a z w y

For Each tbl In cat.Tables

If tbl.Type <> "VIEW" Then 1 = 1 & tbl.Name & Next He.Lista.RowSource = 1

Kolejnym elementem jest możliwość zdefiniowania i utworzenia na poziomie mechani­ zmu ADO tabeli (listing 5.42). Należy wykorzystać bibliotekę A DOK do ustanowienia połączenia. Następnie w kolejności: nadać tabeli nazwę oraz podać definicję pól tabeli łącznie z typem i ewentualnymi ograniczeniami, proces musi zostać zakończony dopisa­ niem takiej definicji do katalogu (fizyczne utworzenie tabeli) przez wykonanie metody Append. Listing 5.4 2 . Tworzenie nowej tabeli przy zastosowaniu mechanizmu ADO Dim cat As New ADOX.Catalog Dim tb l As New ADOX.table Dim t t As String

' O tw ó r z k a ta lo g cat.ActiveConnection = "Provider=Hicrosoft.Jet.0LEDB.4.0:" & _ "Data Source=.\dao_ado2.mdb:" ' U tw ó r z n o w y o b ie k t ta b e li

tbl.Name = He.Tabel a

' U tw ó r z p o la

i d o d a j j e d o n o w e g o o b ie k tu ta b lic y

tbl.Columns.Append Me.Polel. adVarWChar tbl.Columns.Append He.pole2. adVarWChar tbl.Colum ns(l).Attributes = adColNullable

' D o d a j n o w ą ta b e lę d o

b a zy danych

cat.Tables.Append tbl Set cat = Nothing t t = "select " & Polel & He.Lista.RowSource = t t He.Recalc

& pole2 & " frm " & Tabela

Ciekawą możliwością oferowaną w tym mechanizmie jest możliwość definiowania tabel połączonych (listing 5.43). Również tutaj korzystamy z biblioteki AD O X do zde­ finiowania połączenia Rozróżnienie między tworzeniem fizycznej tabeli a jej dynamicz­ nej kopii (tabeli połączonej) ogranicza się od strony formalnej do podania charakterystycz­ nych dla tego typu obiektu właściwości. Poza ustawieniem " J e t OLEDBiCreate L in k " na wartość TRUE pozostałe parametry definiują sposób połączenia z bazą źródłową do­ kładnie jak w A ctive C onne ction. Listing 5.43. Definiowanie tabeli połączonej przy zastosowaniu mechanizmu ADO__________________ Dim cat As New ADOX.Catalog Dim tbl As New ADOX.table ' O tw ó r z k a ta lo g

cat.ActiveConnection = ”Provider=Microsoft.Jet.0LEDB.4.0:" & _ "Data Source=.\dao_ado2.mdb:"

' U sta w

n a z w ę i k a ta lo g b a z y n a d r z ę d n e j d la d o łą c z a n e j ta b lic y

tbl.Name = "Osoby2” Set tbl.ParentCatalog = cat

R ozdział 5 . ♦ M ech anizm y wymiany danych

' U sta w

181

w ła ś c iw o ś c i d la tw o r z o n e j ta b e li p o łą c z o n e j

tbl .P ro p e rtie sC Je t OLEDBiCreate Link") = True tbl .P ro p e rtie sC Je t OLEDB:Link Datasource") = ".\dao_adol.mdb" ’ tbl .P ro pe rtie sC Je t OLEDB:Link Provider S tn n g ” ) = “ :pwd=:" tbl .P ro pe rtie sC Je t OLEDB:Remote Table Name” ) = "osoby"

'D o d a j

ta b lic ę d o z b io r u

cat.Tables.Append tbl Set cat = Nothing

Przedstawiony tutaj zakres nie wyczerpuje wszystkich potencjalnych możliwości ofe­ rowanych przez mechanizmy wymiany danych, ale prezentuje najważniejsze zdaniem autora spośród nich.

182

Bazy d anych. P ierw sze s t a r c ie

Rozdział 6.

Zastosowani© mechanizmów wymiany danych przy tworzeniu apSikacji ZasOaotoe magazynowe Bardzo wiele zagadnień praktycznych daje się rozwiązać bez konieczności odwoływa­ nia się do stosowania mechanizmów wymiany danych. Jak wskazano w poprzednim rozdziale, wymagają one dużego nakładu czasu związanego chociażby z zestawieniem połączenia. Jednak wielokrotnie stajemy przed koniecznością odczytania w'artości zawar­ tych we wskazanym zestawie rekordów, a tutaj bez odwołania się do tych mechanizmów nie możemy liczyć na skuteczne rozwiązanie. Przykładem takiego problemu pojawiającego się w praktyce jest zadanie, które można nazwać zadaniem magazynowym. Wyobraźmy sobie mianowicie, że wystawianie faktury odbywa się na stanowisku poza magazynem, (co pokrywa się z praktyką), a my chcemy zapewnić, że liczba jednostek sprzedawanego towaru ma pokrycie w stanie magazynowym. Oczywiście możemy przejść do widoku podglądu formularza stanu magazynu — w naszym przypadku rolę tę będzie odgrywała tabela (formularz o nią oparty) Towar z dodanym polem Liczba_sztuk prezentującym aktualny stan magazynu. Jednak zamiast zdawać się na działanie operatora, lepiej byłoby, aby proces sprawdzenia został zautomatyzowany. W związku z tym formularz Faktura (rysunek 6.1) został zmodyfikowany poprzez dodanie pola kombi z listą towarów, po­ zwalającym wybierać sprzedawany towar (na zasadzie takiej samej jak w przypadku podformularza Transakcja), pola tekstowego reprezentującego liczbę sztuk wybranego towaru oraz przycisku realizującego przedstawiony powyżej problem. Od tego momentu sprze­ daż będzie wykonywana w oparciu o te trzy kontrolki, a nie jak dotąd przez bezpo­ średnie zastosowanie podformularza Transakcja. Podformularz ten będzie jedynie elemen­ tem pozwalającym kontrolować poprawność wystawiania faktury (tylko do odczytu).

184

Bazy dan ych . P ierw sze s t a r c ie

R ysu nek 6 . 1 . P ro jekt fo r m u la r z a F a ktu ra d la p o trze b z a d a n ia m a g a zjw o w eg o

Dla tak wzbogaconego formularza opracowano procedurę obsługi zdarzenia Przy klik­ nięciu dla dodanego przycisku, która wykorzystuje mechanizm wymiany danych DAO. Kod procedury realizującej zadanie magazynowe zawiera listing 6.1. Listing 6 .1 . K o d p ro c e d u r}’ o b słu g u ją ce j zd a rze n ie P rzy klik n ię c iu p rz y c is k u re a lizu ją ceg o za k u p lub zw ro t to w a ru z za sto so w a n iem D A O

Private Sub Polecem e8_Click() Dim db As DAO.Database Dim rec As DAO.Recordset Dim zakup As Integer Dim ilo s c As Integer ilo s c = M e.ile Set db = CurrentDb zap = "SELECT stan FROM Towar WHERE IdTowaru=" & Me.co Set rec = db.OpenRecordset(zap) stan = rec.Fields(O).Value I f (stan >= ilo sc ) Then zap = “SELECT COUNT( Idtowaru) FROM Transakcja WHERE IdTowaru=" & Me.co zap = zap & " AND ldFaktura=“ & Me.IdFaktura Set rec = db.OpenRecordset(zap) czy = rec.Fields(O).Value I f (czy = 1) Then I f ( ilo s c >= 0) Then zap = “UPDATE Transakcja SET Liczba_sztuk=Liczba_sztuk+" & Me.ile zap = zap & " WHERE IdTowaru=" & Me.co & “ AND IdFaktura=" & Me.IdFaktura Elsę zap = "SELECT Liczba_sztuk FROM Transakcja WHERE IdTowaru°" & Me.co zap = zap & " AND IdFaktura=" & Me.IdFaktura Set rec = db.OpenRecordset(zap) zakup = rec.Fields(0).Value I f ((zakup + ilo sc ) > 0) Then zap = "UPDATE Transakcja SET Liczba_sztuk=Liczba_sztuk+ & Me. ile zap = zap & " WHERE IdTowaru=" & Me.co & " AND IdFaktura= <♦ " & Me.IdFaktura End If I f ((zakup + ilo sc ) = 0) Then zap = "DELETE FROM Transakcja

R ozdział 6 . ♦ Z a sto so w a n ie m echanizm ów wymiany danych przy tworzeniu a p lik acji

185

zap = zap & " WHERE IdTowaru=" & Me.co & " AND IdFaktura= & Me.IdFaktura End If I f ((zakup + ilo s c ) < 0) Then zap = "" MsgBox "Nie można zwrócić więcej, n iż kupiono". . "UWAGA" End If End I f Elsę If (ilo s c > 0) Then zap = "INSERT INTO Transakcja(IdFaktura.IdTowaru.Liczba_sztuk) VALUES zap = zap & " (" & Me.IdFaktura & "." & Me.co & "." & M e.ile & ")" Elsę zap = "" MsgBox "Nie można zwrócić niezakupionego towaru". . "UWAGA" End I f End If DoCmd.SetWarnings False I f zap o "" Then DoCmd.RunSOL zap zap = "UPDATE Towar SET stan=stan - (" & ilo s c & " )" zap = zap & " WHERE IdTowaru=" & Me.co DoCmd.RunSOL zap End If M e.ile = 0 DoCmd.SetWarnings True Elsę MsgBox "Zbyt mały stan magazynu". . "UWAGA" M e.ile = stan End I f Me.Recalc End Sub

Pierwszym krokiem jest zadeklarowanie zmiennych reprezentujących bazę danych i ze­ staw rekordów — zmienne reprezentujące obiekty muszą być zadeklarowane. Dodat­ kowo konieczne jest zadeklarowanie zmiennej pomocniczej ile jako typu calkowitoliczbowego (integer), wynika to z przyjęcia założenia upraszczającego, że jednostką sprzedaży mogą być tylko liczby całkowite, np. sztuki, ale przyjęcie liczb rzeczywistych w celu odzwierciedlenia niecałkowitej miary sprzedawanego towaru nie wnosi niczego nowego. Faktycznym powodem konieczności deklaracji tej zmiennej jest fakt, że Visual Basic „nie radzi sobie” z niejawną (za pomocą niejawnej zmiennej typu variant) konwersją pól tekstowych z formatki, zawierających znak minus, i traktuje je jak na­ pis (zmienna tekstowa). Natomiast jawne przypisanie pola tekstowego do zmiennej licz­ bowej (zarówno całkowitej, jak i rzeczywistej) rozwiązuje ten problem. Ponieważ Visual Basic nie wymaga deklaracji używanych zmiennych, w celu ograniczenia rozmiaru kodu pozostałe deklaracje (te, które nie są niezbędnie konieczne) został}' pominięte. Po ustanowieniu zmiennej db na reprezentującą bieżącą bazę danych (ustanowieniu po­ łączenia) definiowano kolejne zestawy rekordów, zawsze w oparciu o zmienną zap zawierającą za każdym razem definicję zapytania wybierającego, zawierającego poje­ dynczy rekord. W pierwszym przypadku wybierany jest z tabeli Towar stan magazy­ nowy towaru o identyfikatorze określonym na skutek dokonanego w polu kombi wyboru.

186

Bazy dan ych . P ierw sze s t a r c ie

Jeśli stan magazynu jest mniejszy niż liczba sprzedawanego towaru, wyświetlany jest komunikat, a w pole Ile formularza wpisywany jest aktualny stan (sekcja ELSE instrukcji warunkowej). Jeśli stan magazynu jest większy niż liczba sprzedawanego towaru, należy rozważyć kilka przypadków. Po pierwsze należy sprawdzić, czy wybrany towar juz nie został wybrany w obrębie transakcji obsługiwanej faktury (warunek dotyczy zarówno IdTowaru, jak i IdFciktwy) — w takim przypadku należy zmodyfikować za­ wartość odpowiedniego rekordu w tabeli Transakcja. Jeśli istnieje w obrębie faktury transakcja dotycząca wybranego towaru, to należy rozważyć kilka możliwości — liczba zamawianych towarów jest dodatnia, czyli realizujemy modyfikację rekordu (UPDATE); jeśli liczba jest ujemna (zwracamy sprzedawane towary), to znów należy rozpatrzyć warianty. Jeśli po dodaniu zamówienia i wybranej w polu tekstowym ilości wartość jest dodatnia (zwracamy tylko część towarów — np. pomyłka przy wpisywaniu), to również możemy zastosować zapytanie modyfikujące Transakcje. Jeżeli liczba ta jest zerem (oznacza to, że rezygnujemy z zakupu określonego towaru), należy usunąć daną transakcję z faktury — zapytanie usuwające DELETE. Jeśli suma zamówienia i ilości na fakturze jest ujemna — oznacza to, że próbujemy oddać na magazyn więcej, niż ku­ piliśmy — powinien być wyświetlany odpowiedni komunikat. Jeśli w transakcji nie istnieje zamawiany produkt, to należy do tabeli dodać odpowiedni rekord — polecenie INSERT. Należy zwrócić uwagę, że w przypadku generowania komunikatów pod re­ prezentującą zapytanie zmienną podstawiano pusty łańcuch, jest to jedna z możliwości rozwiązania hierarchicznej postaci warunków, dla których części nie powinna być po­ dejmowana żadna akcja. Innym rozwiązaniem jest wykonanie zapytania bezpośrednio w sekcji obsługi konkretnego warunku. W naszym przypadku po sprawdzeniu, że zmienna zawierająca zapytanie nie jest pusta, zostaje ono wykonane metodą RunSQL. W ten sposób modyfikowany jest stan transakcji związanych z obsługiwaną fakturą. Kolejnym krokiem jest wykonanie zapytania odpowiednio modyfikującego stan towa­ rów' w tabeli Towar. Dodatkowo na czas wykonywania zapytań modyfikujących dane zablokowane zostało wyświetlanie komunikatów' systemowych dzięki odpowiedniemu ustawieniu flagi systemowej SetWarnings. Jeśli zechcemy użyć mechanizmu ADOzamiast DAO, kod obsługi zdarzenia wymaga tylko niewielkiej korekty' — wskazane wytłuszczonym drukiem na listingu 6.2. Jak widać, zmiany dotyczą deklaracji zmiennych, reprezentujących tym razem nowe instan­ cje obiektów' ADO, a także sposobu realizacji połączenia metodą Connection obiektu CurrentProject, jako że łączymy się z bieżącą bazą danych, oraz sposobu otwarcia zestawu rekordów'. Należy zwrócić uwagę na fakt konieczności jawnego zamknięcia zestawu rekordów', co nie jest wymagane przy stosowaniu DAO. Linijki dotyczące zestawm rekordów należy powielić trzykrotnie w obrębie procedury, wszędzie tam, gdzie było to zrealizowane poprzednią metodą. Nie zrealizowano tego w tabeli, aby nie po­ wielać prawie dosłownie cytowanego kodu. L isting 6 .2 . P o c zą te k ko d u p ro c e d u ry o b słu g u ją ce j zd a rze n ie Przy’ klik n ię c iu p rz y c is k u realizującego za k u p lub zw ro t to w a ru z za sto so w a n iem A D O

Pnvate Sub Pol ecen i el3_Cl ick () Dim eon As New ADODB.Connection Dim rec As New ADODB.Recordset Dim zakup As Integer Dim ilo s c As Integer ilo s c = H e.ile

Rozdział 6. ♦ Z astosow anie mechanizmów wymiany danych przy tworzeniu aplikacji

187

Set eon = CurrentProject.Connection zap = "SELECT stan FROH Towar WHERE IdTowaru=" & He.co rec.Open zap. eon stan = rec.Fields(0).Value rec.Close End Sub

Postawione i rozwiązane powyżej zadanie magazynowe nie jest dokładnym odzwier­ ciedleniem praktyki. Jeśli bowiem stan magazynu będzie bezpośrednio zmieniany w tabeli Towar, utracimy informację o tym, kiedy towar został dostarczony, co dla wielu produktów (np. spożywczych) jest informacją bardzo istotną. Wprowadźmy do­ datkową tabelę dostawy o strukturze przedstawionej na rysunku 6.2. Nasze zadanie zmodyfikujmy teraz tak, że w przypadku, kiedy jest dostateczna liczba sprzedawanego produktu, rozumiana jako suma sztuk wszystkich dostaw danego towaru, to stan jest zmniejszany, począwszy od najstarszego, czyli najmniejszej wartości pola D atajiost. Ponieważ zachowanie mechanizmu zwracania części lub całości zakupionego towaru spowodowałoby konieczność wprowadzenia dodatkowej struktury „pamiętającej” daty sprzedawanych artykułów po zdjęciu ze stanu, co z kolei znacznie rozbudowałoby kod, ta funkcjonalność w rozszerzonym zadaniu magazynowym nie zostanie zachowana. Rysunek 6.2. P ro jekt ta b eli Dostcrwy d la p o trze b rozszerzo n eg o za d a n ia m a g a zyn o w eg o

Nazwa pola 9

IdDost

Typ danych

IdTowaru

A u to n u m e ro w a n le liczb a

szt

Liczba

Data dost

D ata/G odzlna T

Podobnie jak poprzednio programujemy zdarzenie Przy kliknięciu (listing 6.3) dla wpro­ wadzonego na formularz przycisku (klawisza). Tym razem rozwiązanie oparto o me­ chanizm ADO, ale ponieważ w poprzednim przykładzie pokazano, jak niewielkich ko­ rekt wymaga przejście do innych mechanizmów wymiany danych, uważny czytelnik nie powinien mieć kłopotów z transformacją kodu. Tak jak poprzednio po zdefiniowa­ niu połączenia z bieżącą bazą danych definiowany jest zestaw rekordów pozwalający tym razem stwierdzić, czy suma wybranego towaru we wszystkich dostawach pokrywa zapotrzebowanie na fakturze. Jeśli niewyświetlany jest komunikat, następuje właściwy proces aktualizacji transakcji i stanów magazynowych. Podobnie jak poprzednio spraw­ dzane jest, czy dany towar już występuje w obrębie transakcji wystawianej faktury. W takim przypadku liczba sprzedawanych sztuk jest powiększana. Jeżeli jeszcze się na fakturze nie pojawił, dodawana jest kolejna transakcja — kolejny rekord w tabeli. Listing 6 .3. K o d procedury’ o bsługującej zda rzen ie Pizy’ kliknięciu p rzycisku realizującego za k u p tow aru z za sto so w a n iem A D O p r z y zm o d yfiko w a n ym za d a n iu m a g a zyn o w ym ____________________________________ Private Sub Polecenie!4_Click() Dim eon As New ADODB.Connection Dim rec As New ADODB.Recordset Dim ilo s c As Integer ilo s c = H e.ile Set eon = CurrentProject.Connection zap = "SELECT SUM(szt) FROH Dostawy WHERE idTowaru=" & He.co

188

Bazy d an ych . P ierw sze s t a r c ie

rec.Open zap. eon stan = rec.Fields(0).Value rec.Close I f (stan >= ilo sc ) Then zap = "SELECT COUNT( Idtowaru) FROM Transakcja WHERE IdTowaru=" & Me.co zap = zap & " AND IdFaktura=" & Me.IdFaktura rec.Open zap. eon czy = rec.Fields(O).Value rec.Close I f (czy = 1) Then zap = "UPDATE Transakcja SET Liczba_sztuk=Liczba_sztuk+" & ilo s c zap = zap & “ WHERE IdTowaru=" & Me.co & " AND IdFaktura=" & Me.IdFaktura Elsę zap = "INSERT INTO Transakcja(IdFaktura.IdTowaru.Liczba_sztuk) VALUES ” zap = zap & "(" & Me.IdFaktura & V & Me.co & & ilo s c & " ) “ End If DoCmd.SetWarnings False DoCmd.RunSQL zap zap = "SELECT szt. IdDost FROM Dostawy WHERE IdTowaru=” & Me.co zap = zap & " AND szt>=0 ORDER BY Data_dost ASC" rec.Open zap. eon Do While Not rec.EOF ile_tow = rec.Fields(O).Value która = re c.F ie ld s(l).V a lu e If (ile_tow >= ilo sc ) Then zap = "UPDATE Dostawy SET szt=szt-" & ilo s c zap = zap & ’’ WHERE IdDost=" & która Elsę zap = "UPDATE Dostawy SET szt=0" zap = zap & " WHERE IdDost=" & która End If DoCmd.RunSOL zap ilo sc = ilo s c - ile_tow If ( ilo sc <= 0) Then E xit Do End I f rec.MoveNext Loop rec.Close DoCmd.SetWarnings True Elsę MsgBox "Zbyt mały stan magazynu". . "UWAGA" M e.ile = stan End If Me.Recalc End Sub

Następnie definiowany jest zestaw rekordów zawierający dane z wszystkich dostaw danego towaru, w których stan jest wyższy niż zero. W pętli, której koniec zdefinio­ wany jest jako wyjście poza zestaw rekordów, kolejno zdejmowane są stany z pozycji uszeregowanych względem daty. Przy czym sprawdzany jest warunek, czy liczba sztuk

Rozdział 6. ♦ Z astosow anie mechanizmów wymiany danych przy tworzeniu aplikacji

189

w danej dostawie jest większa od liczby pozostałych do wyczerpania zamówienia sztuk (w pierwszym przebiegu jest to całkowita liczba sztuk zamawianego towaru). Jeśli jest większa, to stan w tej pozycji jest ustawiany na zero, w przeciwnym przypadku stan ten jest pomniejszany o liczbę pozostałych do zrealizowania sztuk. Następnie liczba sztuk pozostałych do realizacji zamówienia jest pomniejszana. Aby nie wykonywać zbędnych kroków, w momencie zaspokojenia liczby zamawianych sztuk następuje wy­ muszenie wyjścia z pętli.

©[Mnezamtó® wyouilkiLo mrasezaa ma [p®dls1ław0e steeltomyelh) [biranmelk Powróćmy do przykładu, w którym wyznaczaliśmy wynik meczu na podstawie strzelo­ nych bramek. Poprzednio budowaliśmy pomocnicze zapytanie sumujące bramki dla każdej drużyny w meczu, a następnie wstawialiśmy oparty na nim formularz do for­ mularza głównego oraz dokonywaliśmy ich synchronizacji przy pomocy pola zawie­ rającego wspólną informację IdMeczu. Tym razem zastosujemy zdecydowanie bardziej eleganckie rozwiązanie bazujące na mechanizmie wymiany danych ADO. W tym celu w formularzu dodajemy dwa niezwiązane pola tekstowe o nazwach WGosp i łVGosc. W celu wyznaczenia wyniku meczu musimy oprogramować dwa zdarzenia, które po­ wodują zmianę wyniku. Pierwsze to zmiana rekordu w formularzu nadrzędnym, przej­ ście do kolejnego rekordu (zdarzenie Przy bieżącym). Drugie to dopisanie kolejnej bramki, czyli wybranie nowego Strzelca bramki lub jego zmiana w kontrolce ComboBox podformularza — IdStrzeica (zdarzenie Po aktualizacji). Kody obsługi obu zdarzeń są takie same, a fragment ich, bez obsługi wyjątków, zawiera listing 6.4. Listing 6.4. F ra g m en t kodu p ro c ed u ry o b sługującej zd a rzen ie P o aktu alizacji p o la ko m b i w ybierającego Strzelca bra m ki o ra z Przy’ b ieżą cym d la fo r m u la r z a z za sto so w a n ie m A D O I f Not IsNulKMe.IdMeczu) Then Set eon = CurrentProject.Connection zap = “SELECT IdGosp FROM Mecze WHERE IdMeczu=" & Me.IdMeczu rec.Open zap. eon gosp = rec.Fields(O).Value rec.Close zap = "SELECT C0UNT(IdBramki) FROM Bramki WHERE IdMeczu=” & _ Me.IdMeczu & " AND IdStrzeica IN (SELECT Idosoby FROM Osoby " & _ "WHERE IdDzialu = " & gosp & ")" rec.Open zap. eon BGosp “ rec.Fields(0).Value rec.Close zap = "SELECT IdGosc FROM Mecze WHERE IdMeczu=“ & Me.IdMeczu rec.Open zap. eon gosc = rec.Fields(0).Value rec.Close zap = "SELECT COUNT( IdBramki) FROM Bramki WHERE ldMeczu=” & Me.IdMeczu & " AND IdStrzeica IN (SELECT Idosoby FROM Osoby =” & "WHERE IdDzialu = " & gosc & ” )” rec.Open zap. eon Bgosc = rec.Fields(O) .Value

190

Bazy d an ych . P ierw sze s t a r c ie

rec.Close Elsę BGosp = O Bgosc = O End I f Forms("mecze") .WGosp = BGosp Forms("mecze").WGosc = Bgosc

Po ustanowieniu połączenia z bieżącą bazą danych otwierane są odpowiednie zestawy' rekordów. W podstawowym rozwiązaniu do ich definicji zastosowano po dwie pary zapytań SQL. Pierwsze wyznacza drużynę na podstawie identyfikatora meczu (do­ stępny zarówno w formularzu, jak i podformularzu) Drugie oblicza sumę bramek dla wybranej w ten sposób drużyny, na podstawie zgodności listy strzelców bramek z listą zawodników tej drużyny. Należy zwrócić uwagę na konieczność zamykania zestawu rekordów RecordSet przed kolejnym jego otwarciem, zmianą definicji. Całość przetwa­ rzania wykonywana jest po sprawdzeniu w instrukcji warunkowej, czy identyfikator meczu jest zdefiniowany. Zapobiega to powstawaniu błędów podczas definiowania nowego meczu — wyjście poza ostatni zdefiniowany dotąd mecz. Dla bardziej zaawansowanych osób pokazano rozwiązanie oparte na pojedynczym za­ pytaniu dla każdej z drużyn (listing 6.5). Oprócz sprawdzenia przynależności Strzelca do danej drużyny w kolejnym podrzędnym zapytaniu sprawdzany jest udział drużyny w meczu albo w charakterze gościa, albo gospodarza. W tym miejscu możliwe jest zastąpienie operatora listy IN zwykłą równością, ponieważ to podzapytanie jest ska­ larne — zwraca jedną kolumnę w jednym wierszu. Ponadto dla obu prezentowanych rozwiązań nie jest wymagane odświeżanie formularza po wstawieniu wyniku do od­ powiednich pól tekstowych. L isting 6 .5 . F ra g m en t ko d u sk o iy g o w a n e j p ro c e d u ry w y k o rzy stu ją c e j złocone za p y ta n ie obsługującej zd a rze n ie Po a k tu a liza c ji p o la ko m b i w y b ie ra ją ceg o Strzelca b ra m ki o raz P rzy bieżącym d la fo r m u la iz a z za sto so w a n iem A D O

zap = "SELECT COUNTCldBramki) FROM Bramki WHERE IdMeczu =" & _ Me.IdMeczu & " AND IdStrzelca IN (SELECT Idosoby FROM Osoby " & "WHERE IdDziatu IN (SELECT IdGosp FROM Mecze WHERE IdMeczu=” & _ Me.IdMeczu & ” ))“ rec.Open zap. eon BGosp = rec.Fields(O) .Value

WyświSeUDara© zawsurtośco [bazy Kolejnym prostym przykładem zastosowania mechanizmów wymiany danych jest wy­ świetlenie zawartości bazy danych (listing 6.6). W zaproponowanej realizacji nazwy prezentowane są w postaci kontrolki ListBox o nazwie Lista. Zdarzeniem inicjującym przetwarzanie może być np. wybranie wirtualnego przycisku narysowanego na formula­ rzu. Oczywiście zmiana tego zdarzenia na inne, np. Pizy otwarciu formularza, nie po­ woduje żadnych zmian w pokazanym kodzie.

Rozdział 6. ♦ Z astosow anie mechanizmów wymiany danych przy tworzeniu aplikacji

191

Listing 6.6. F ragm ent kodu procedury pozw alającej na w yświetlenie tabel b ccy d a iy c h z zastosow aniem A D O Dim cnn As New ADODB.Connection Dim rs t As ADODB.Recordset Dim 1 As String

1 = »»

Set cnn = CurrentProject.Connection Set rs t = cnn.OpenSchema(adSchemaTables) Do lln t il rst.EOF I f rst.Fields("TABLE_TYPE") <> "VIEW" Then 1 = 1 & rst.FieldsCTABLEJIAME") & End If rst.MoveNext Loop Me.Lista.RowSource = I

Po zdefiniowaniu połączenia na podstawie metody Connection obiektu CurrentProject jest ono otwierane. Zestaw rekordów jest generowany metodą OpenSchema obiektu Connection. Ustawienie parametru na wartość kodowaną stałą adScemaTabl es sprawi, że zestaw rekordów będzie zawierał nazwy tabel i zapytań bazy danych. Spowoduje to potrzebę odfiltrowania ich przez instrukcję warunkową— sprawdzenie, czy typ obiektu jest różny od View (zapytanie, perspektywa). Aby wyświetlić nazwy zapytań albo zmienić wyrażenie filtrujące, należy zastosować parametr adSchemaProcedures (listing 6.7). Jak już to odnotowano wcześniej, zapytania są traktowane tak jak procedury lub dynamiczne tabele. W silniejszych serwerach da­ nych rozróżnienie między procedurami składowanymi a perspektywami definiowanymi przez zapytania wybierające jest bardziej kategoryczne. Listing 6 .7. F ra g m en t ko d u p ro c ed u ry’p o zw a la ją c e j n a wy>świetlenie n a zw za p y ta ń bazy d anych z za sto so w a n iem A D O Set rst = cnn.OpenSchema(adSchemaProcedures) Do Until rst.EOF 1 = 1 & rst.Fields("PROCEDURE_NAME") & rst.MoveNext Loop

192

Bazy dan ych . P ierw sze s t a r c ie

7Łmh©ń©2Ł®m(B Bazy danych, tak samo jak cala informatyka, są bardzo dynamicznie rozwijającą się dzie­ dziną wiedzy. Przenosi się to bezpośrednio na aplikacje i rozwiązania komercyjne. Dlatego zawsze musimy mieć świadomość konieczności ciągłego pogłębiania wiedzy oraz uzupełniania umiejętności praktycznych.. Również w przypadku książki, podręcz­ nika zdajemy sobie sprawę z tego, że nie umieściliśmy jeszcze wielu ciekawych przy­ kładów, że można jeszcze omówić wiele istotnych z punktu widzenia praktyki technik. Każdy zainteresowany opisywanym środowiskiem oczekuje dodatkowych, nieznanych informacji — trików i sztuczek, a przecież nie sposób wszystkie je zamieścić. Miałem bardzo wiele wątpliwości, czy koniec powinien nastąpić właśnie w tym miejscu. Moje długoletnie doświadczenia, zarówno z tworzeniem baz danych, jak i dydaktyką w tym zakresie, wskazują, że jest to wybór uzasadniony. Jak napisał Terry Pratchett, „Mówią, że niepełna wiedza jest rzeczą niebezpieczną, ale jednak nie tak złą jak cał­ kowita ignorancja”. Po wnikliwej lekturze tej książki moim zdaniem przede wszystkim należy wytrenować poznane tutaj techniki projektowania i programowania. Zrozumienie zawartości każ­ dego przykładu z osobna nie zagwarantuje jeszcze umiejętności samodzielnego opra­ cowania kompletnego rozwiązania praktycznego. Chcę zaznaczyć, że to, co wydaje się najłatwiejsze, czyli zbudowanie właściwego schematu relacyjnego (tabel i powiązań między nimi), stanowi dla większości początkujących adeptów baz danych najtrudniej­ szy krok. Niestety, błędy popełnione na tym etapie rzutują bezpośrednio na całą apli­ kację i w wielu przypadkach próba ich usunięcia kończy się koniecznością budowy aplikacji od początku. Jeśli fragmentarycznie udało się nam nasze niezbyt udane roz­ wiązanie wdrożyć, to czeka nas jeszcze konwersja danych — z reguły bardzo uciąż­ liwa i mozolna. Proces ten jest również bardzo stresujący, zwłaszcza wtedy, kiedy mamy świadomość, że nie możemy pozwolić sobie na utratę żadnych danych. Dlatego zachęcam do treningu tego właśnie elementu, przez budowanie diagramów dla zagad­ nień, które widzimy w życiu codziennym: przyjmowania zamówień w restauracji, wi­ zyt w przychodni, wypożyczania książek czy filmów, organizowania przewozów w firmie transportowej etc. Takie przykłady można mnożyć, wystarczy się tylko mvażnie przyj­ rzeć, w jakiej działalności może przydać się baza danych. Wniosek jest jeden — w każdej — co daje duże pole do popisu.

194

Bazy d an ych . P ierw sze s t a r c ie

Bardzo ważnym elementem jest dogłębne poznanie języka zapytań SQL, który stanowi w zasadzie uniwersalne narzędzie porozumiewania się specjalistów z zakresu baz danych. Chociaż istnieją różne klony składni, starałem się pisać prezentowane przykłady w tak uniwersalny sposób, jak tylko na to pozwala środowisko. Pozwala to na zastosowanie zdobytej wiedzy w wielu innych środowiskach, również w silnych serwerach baz danych. Zawartość przedstawionej Państwu pracy wynika z wielu lat doświadczeń dydaktycz­ nych w zakresie baz danych. Zarówno prowadzenia wykładów, jak i laboratoriów z podstaw nie tylko baz danych, ale również dużo silniejszych serwerów. Nie bez znacze­ nia jest doświadczenie wynikające z wymiany poglądów ze studentami w ramach pro­ wadzonego od wielu lat kola naukowego. Książka ta jest dedykowana dla osób rozpoczynających swoją przygodę z bazami da­ nych, stawiających pierwsze kroki w tworzeniu rozwiązań praktycznych, co rzutowało na wybór prezentowanych narzędzi. Wybór środowiska został podyktowany głównie bardzo dobrą wizualizacją, pozwalającą na łatwe zobaczenie tego, co do tej pory stwo­ rzyliśmy. Za Epiktetem (50 - 130 r. n.e.) możemy powiedzieć, że raz zobaczyć jakąś rzecz znaczy więcej, niż sio razy o niej usłyszeć. Daje to możliwość szybkiego wykry­ cia błędów oraz właściwej ich korekty. Z drugiej strony za takim wyborem przema­ wiała też duża zgodność ze standardem języka SQL. To z kolei pozwala na przeniesienie dobrych nawyków oraz wzorców programowania na silniejsze środowiska serwerów baz danych. Ponieważ dla dociekliwych przygoda z bazami danych na tym poziomie się nie za­ kończy, pragnę Was zachęcić do sięgnięcia do pozycji poświęconych serwerom baz danych. Mam nadzieję, że tym razem napisanie kolejnej książki zajmie mi zdecydowa­ nie mniej czasu. Opanowanie umiejętności tworzenia struktur relacyjnych oraz pro­ gramowania baz danych stanowi gwarancję znalezienia ciekawej, rozwijającej pracy zawodowej. Popyt na specjalistów z tej dziedziny jest bardzo duży i mogę również zagwarantować, że jeszcze długo będzie wzrastał — ponieważ bazy danych to najważ­ niejsza z dziedzin nauki.