Zaczynamy ćwiczyć z DB2 Tworzymy procedurę, która wstawia do dwóch tabel: osoba i adres

Transkrypt

1 Zaczynamy ćwiczyć z DB2 Tworzymy procedurę, która wstawia do dwóch tabel: osoba i adres Autor: Artur Wroński, IBM artur.wronski@pl.ibm.com i przy okazji poznamy mechanizmy pozwalające na tworzenie optymalnych zapytań SQL Wykonując to ćwiczenie dowiesz się: Jak wygenerować identyfikator dla klucza głównego? Jak napisać procedurę składowaną? Jak sprawdzić, czy zapytanie SQL jest optymalnie wykonywane przez bazę? Co ma wpływ na optymalizację zapytań? Jak sprawdzić, jakie indeksy przydadzą się dla zapytania? Jak przekazywać zbiory wynikowe z procedury do aplikacji? Co to są wyrażenia common table expressions? 1

2 Projekt tabel imie nazwisko tabela: osoba id_osoby bigint (PK) imie varchar(50) nazwisko varchar(50) miejscowosc ulica nr_domu kod_pocztowy tabela: adres id_osoby bigint (FK) miejscowosc varchar(80) ulica varchar(80) nr_domu varchar(15) kod_pocztowy char(5) Założenia: imię i nazwisko nie może się powtarzać id_osoby musi być wygenerowane usunięcie osoby powinno usunąć rekordy z adresem osoba może posiadać tylko jeden adres Na przykładzie bardzo prostego ćwiczenia poznasz elementy przydatne dla dewelopera aplikacji działających na DB2. Ćwiczenie będzie polegało na napisaniu procedury składowanej, która dostaje na wejściu zestaw danych i wstawia je do dwóch tabel: osoba i adres. 2

3 Tworzymy tabelę OSOBA create table osoba ( id_osoby bigint not null, imie varchar(50) not null, nazwisko varchar(50) not null ); alter table osoba add constraint osoba_id_osoby_pk primary key (id_osoby); alter table osoba add constraint osoba_naz_uq unique (nazwisko,imie); Czy stosować reguły integralnościowe (constrains)? Jak wykonać przedstawione na slajdzie instrukcje? Jest wiele metod. Możesz uruchomić narzędzie graficzne Centrum Sterowania (DB2 Control Center), wybrać z menu Narzędzia -> Edytor Komend. W edytorze połącz się z wybraną bazą danych, wklej polecenie i wykonaj. Zwróć uwagę, że każda instrukcja zakończona jest średnikiem w narzędziach DB2 jest to domyślny znak kończący instrukcję. Możesz uruchomić okno poleceń tekstowych DB2 (w systemie Windows: db2cmd, na Linuksie/Uniksach jest to po prostu powłoka systemu operacyjnego), następnie przygotować plik z w/w instrukcjami i go wywołać go: db2 connect to baza1 db2 -tvf plik_z_instrukcjami.sql Opcja -t oznacza, że instrukcja jest zakończona znakiem specjalnym (terminated), domyślne takim znakiem jest średnik (;). Opcja -v wyświetla echo instrukcji (verbose), natomiast opcja -f czyta polecenia z pliku (file) Jeśli, chciałbyś przygotować i zarządzać bardziej złożonym modelem danych, IBM ma do tego odpowiednie narzędzie: IBM Rational Data Architect (na bazie Eclipse). Niektórzy deweloperzy unikają reguł integralnościowych (constraints), ponieważ spowalniają modyfikacje danych. Jednak tylko w taki sposób jesteśmy zagwarantować spójność danych w bazie. Zwróć uwagę, że baza danych wykorzystuje reguły integralnościowe przy optymalizacji zapytań, co może przyspieszyć wykonywanie zapytań. Pewnie zdziwisz się, ale w DB2 można zaznaczyć, by reguły integralnościowe nie były sprawdzane przy modyfikacji (NOT ENFORCED), a były wykorzystywane do optymalizacji (ENABLE QUERY OPTIMIZATION) zapytania działają szybciej, a modyfikacje nie są spowalniane. Takie więzy spójności (informational constraints) mają jednak sens, jeśli mamy 100% przekonanie, że dane są spójne. 3

4 Generowanie id alter table osoba alter column id_osoby set generated always as identity (start with 100); generated always - baza zawsze generuje dane insert into osoba (imie, nazwisko) values ('Adam', 'Mickiewicz'); Co zostało wygenerowane? values identity_val_local() Ostatnie w sesji wygenerowane ID. select id_osoby from new table ( insert into osoba (imie, nazwisko) values ('Adam', 'Mickiewicz') ) as t; SELECT z INSERT-a Jednym ze sposobów określenia nowej wartości klucza głównego są pola generowane. Pola generowane przechowują wartości, które zostały wygenerowane dowolną funkcją SQL. IDENTITY jest przykładem funkcji pozwalającej wygenerować kolejny numer, który bardzo przydaje się przy tzw. sztucznych kluczach głównych. Jeśli pole zdefiniowane było z atrybutem ALWAYS, wtedy w aplikacji nie mamy możliwości określenia wartości pola (musimy je pominąć w instrukcji wstawiającej, bądź modyfikującej). Jeśli pole zdefiniowane było z atrybutem BY DEFAULT, wtedy możemy mu także przypisać wartość jawnie. Wygenerowaną ostatnio wartość IDENTITY możemy pobrać specjalną funkcją identity_val_local(), ale także możemy wykorzystać specjalny rodzaj zapytania SELECT z instrukcji INSERT, który zwróci nam dane, które rzeczywiście zostały zapisane przez bazę danych. Na pierwszy rzut oka taka funkcjonalność może wydawać się zbędna, bo przecież wiemy, co zapisywaliśmy do bazy danych jednak w praktyce taka konstrukcja bardzo się przydaje. Zwróć uwagę, że każdą próbę modyfikacji danych możemy podmienić wyzwalaczem TRIGGER INSTEAD OF wtedy jedną instrukcją SQL możemy sprawdzić, co było zapisane. Zapytanie SELECT z INSERTa jest dużo bardziej wydajne niż zapisanie danych instrukcją INSERT i odczytanie rekordu dodatkowym zapytaniem. Zwróć uwagę, że SELECT można robić także na instrukcjach UPDATE, DELETE i zwrócić rekordy modyfikowane, bądź sprzed modyfikacji. 4

5 Generowanie id Jeśli baza zawsze generuje wartości to jak migrować tak założone tabele IMPORT-em? alter table osoba alter column id_osoby set generated by default; generated by default - baza pozwala na INSERT, UPDATE import from plik1 of del insert into osoba IMPORT alter table osoba alter column id_osoby set generated always; alter table osoba alter column id_osoby restart with 999; Zmiana na ALWAYS oraz ustawienie licznika Skoro tylko baza danych może wygenerować wartość pojawia się pytanie jak przenieść dane pomiędzy tak utworzonymi tabelami bądź pomiędzy bazami danych? Klauzula BY DEFAULT pozwala nam także na ręczne modyfikowanie generowanych pól, dzięki czemu będziemy mogli użyć standardowych narzędzi do migracji danych wykorzystujących SQL INSERT, takich jak IMPORT. Na czas ładowania danych zmieniamy definicję pola generowanego na GENERATED BY DEFAULT. Ładujemy dane IMPORT-em. W przykładzie ładowany plik ma postać pliku tekstowego z separtorem klauzula of del (delimited). Po załadowaniu danych zmieniamy definicję pola generowanego, tak by zagwarantować, że nikt ręcznie nie nadpisze wartości pola generowanego oraz zwiększamy wartość licznika związanego z polem IDENTITY. Import jest przykładem narzędzia do ładowania danych. Import czyta dane z pliku bądź z kursora. Plik może mieć postać tekstową (of del) bądź binarną ixf (integrated exchange format). Format ixf jest przenośny pomiędzy różnymi systemami DB2 i dodatkowo zawiera definicję tabeli, tzn. na podstawie pliku ixf możemy odtworzyć strukturę tabeli. Dane z bazy możesz wyeksportować poleceniem export. Oto przykłady exportu: db2 export to plik.del of del select * from tabela db2 export to plik.ixf of ixf select * from tabela 5

6 Generowanie id, cz. II Jeśli baza zawsze generuje wartości to jak migrować tak założone tabele IMPORT-em? alter table osoba alter column id_osoby drop identity; Usunięcie IDENTITY import from plik1 of del insert into osoba IMPORT alter table osoba alter column id_osoby set generated always as identity (start with 100); alter table osoba alter column id_osoby restart with 999; Założenie IDENTITY oraz ustawienie licznika Atrybut IDENTITY możemy także usunąć, a następnie odtworzyć po załadowaniu danych. Klauzula (start with 100) określa definicję pola generowanego (narzędzia do przenoszenia schematu bazy odczytają wartość początkową równą 100), natomiast klauzula restart with 999 określa bieżącą wartość licznika. Wartość licznika mogliśmy nadać tylko jednym poleceniem (start with 999), lecz w ten sposób tracilibyśmy informację, od jakiego numeru rozpoczęliśmy generowanie kluczy. Jeśli chciałbyś sprawdzić definicję tabeli możesz zrobić to przy pomocy narzędzia db2look (opcja e pochodzi od słowa extract): db2look -d baza1 -e -t tabela1 DDL (data definition language) tabeli możesz wygenerować także w Centrum Sterowania DB2: kliknij prawym klawiszem na wybraną tabelą i wybierz Generuj DDL. 6

7 Generowanie id, cz. III Jeśli baza zawsze generuje wartości to jak migrować tak założone tabele LOAD-em? load from plik1 of del modified by identityoverride insert into osoba LOAD alter table osoba alter column id_osoby restart with 999; Ustawienie licznika Tabelę z polem generowanym możemy także nadpisać na siłę, narzędziem LOAD, które zapisuje dane bezpośrednio na dysk z pominięciem dziennika transakcji oraz silnika SQL. W przykładzie wykorzystaliśmy modyfikator identityoverride, który pozwala na nadpisanie pól IDENTITY z opcja GENERATED ALWAYS. LOAD jest zupełnie inna metodą ładowania danych niż IMPORT. Przede wszystkim jest dużo szybszy. Narzędzie jest wielowątkowe i automatycznie powołuje odpowiednią ilość agentów, tak by w maksymalnym stopniu wykorzystać dostępne procesory. Indeksy budowane są dopiero po załadowaniu danych (mogą być budowane przyrostowo). Oczywiście zysk na szybkości musi odbywać się jakimś kosztem. Podczas ładowania danych obszar tabel, w którym znajduje się ładowana tabela dostępny jest tylko do odczytu. Dodatkowo, narzędzie LOAD nie sprawdza reguł integralnościowych, dlatego też po załadowaniu danych należy uruchomić specjalną komendę SET INTEGRITY, która sprawdza spójność danych i ponownie aktywuje więzy spójności (np. klucz główny klucz obcy). 7

8 Czy są inne metody generacji ID? CREATE SEQUENCE seq1 AS BIGINT START WITH 1; VALUES NEXTVAL FOR seq1 ; VALUES PREVVAL FOR seq1 ; ALTER SEQUENCE seq1 RESTART WITH 100 ; Jak jest różnica pomiędzy INDENTITY as SEQUENCE? - INDENTITY związane jest z tabelą, a SEQUENCE jest niezależnym obiektem, wykorzystywanym przez aplikacje. Kolejny identyfikator możemy także wygenerować przy wykorzystaniu sekwencji. Sekwencje jednak nie są skojarzone z danym obiektem bazy danych aplikacja musi być świadoma faktu istnienia sekwencji. Kolejne wartości sekwencji generuje się funkcją NEXTVAL (NEXT VALUE). Funkcja PREVVAL (PREVIOUS VALUE) podaje ostatnią wygenerowaną w sesji wartość dla danej sekwencji. Warto zaznaczyć, że sekwencje, jak i pola generowane generują po prostu następny numer i nie sprawdzają wartości, które są aktualnie w tabeli. Jeśli chcemy wygenerować wartość, która jest unikalna możemy skorzystać z funkcji GENERATE_UNIQUE(). 8

9 Po co wykorzystywać IDENTITY albo SEQUENCE? także dla WYDAJNOŚCI! db2look -d baza1 -e -t osoba /.../ "ID_OSOBY" BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY ( START WITH +100 INCREMENT BY +1 MINVALUE +100 MAXVALUE NO CYCLE CACHE 20 NO ORDER, "IMIE" VARCHAR(50) NOT NULL, "NAZWISKO" VARCHAR(50) NOT NULL CACHE - generacja kolejnej paczki jest zapisywana do logu. Kluczowe dla wydajności! Atrybut IDENTITY oraz sekwencje przede wszystkim ułatwiają tworzenie aplikacji, ale także są dużo bardziej wydajne, niż własnoręczne metody generowania wartości. Kluczowym atrybutem wpływającym na wydajność generowanych sekwencji jest CACHE. Silnik bazy danych przygotowuje w pamięci paczkę wartości, które następnie rozdziela pomiędzy aplikacje (klauzula NO ORDER oznacza, że aplikacje niekoniecznie muszą dostawać generowane numerki w określonej kolejności wtedy jest jeszcze szybciej). 9

10 Tworzymy tabelę ADRES create table adres ( id_osoby bigint not null, miejscowosc varchar(80), ulica varchar(80), nr_domu varchar(15), kod_pocztowy char(5) ); alter table adres add constraint adres_id_osoby_fk foreign key(id_osoby) references osoba(id_osoby) on delete cascade on update restrict; alter table adres add constraint adres_id_uq unique (id_osoby); comment on table adres is 'Powiazane z tabela osoba'; Tworząc klucz obcy z klauzulą on delete cascase wymuszamy usuwanie rekordów zależnych, przy usunięciu rekordu głównego. Komentarze (instrukcja comment) opisujące znaczenie tabel i kolumn są przechowywane w słowniku systemowym bazy danych warto z nich korzystać, gdyż schemat bazy danych staje się bardziej czytelny. Struktura tabel osoba, adres: 10

11 Tworzymy procedurę Jeśli będziesz chciał tworzyć i śledzić procedury w narzędziu graficznym możesz sięgnąć po DB2 Developer Workbench. Narzędzie zostało oparte o środowisko Eclipse i jest bezpłatne, niezależnie od wykorzystywanej przez Ciebie edycji DB2. 1) Database Explorer w tym oknie możesz nawiązać połączenie z bazą danych i zobaczyć, jakie obiekty zostały w bazie utworzone. 2) Data Project Explorer tu tworzysz projekty, w których będziesz mógł budować procedury składowane, zapytania SQL oraz XQuery. 3) Okno pokazuje kod edytowanej procedury DODAJ_OSOBE. Procedurę możesz wdrożyć na dowolnej bazie danych (Deploy ) i wykonać. Procedurę możesz także debuggować po uruchomieniu odpowiedniej perspektywy. DB2 Developer Workbench możesz pobrać z adresu: 11

12 Tworzymy procedurę dodaj_osobe create procedure dodaj_osobe ( in p_imie varchar(50), in p_nazwisko varchar(50), in p_miejscowosc varchar(80), in p_ulica varchar(80), in p_nr_domu varchar(15), in p_kod_pocztowy char(5) ) specific dodaj_osobe begin atomic -- ciało procedury -- wstawienie do tabel: osoba i adres begin atomic -- blok nierozerwalny, traktowany jak pojedyncza, choć złożona instrukcja Jeśli tworzymy procedurę z interfejsu tekstowego, musimy przygotować plik z treścią procedury, a na końcu procedury musimy umieścić unikalny znak końca instrukcji (lub dwa znaki, w przykładzie Procedura składowana jest przykładem tzw. złożonej instrukcji SQL. Utworzenie procedury z tak przygotowanego skryptu: db2 -td@ -f twój_plik (opcje: -t = terminated, -d = defined). Oczywiście wcześniej musisz połączyć się z bazą danych. W procedurze zdefiniowana sześć parametrów wejściowych. Nazwy parametrów poprzedzono przedrostkiem p_ by później ułatwić rozróżnienie parametrów od zmiennych oraz nazw obiektów SQL. Blok: begin atomic end Instrukcja 1 Instrukcja 2 traktowany jest jak jedna złożona instrukcja, co oznacza, że wszystkie instrukcje SQL w bloku wykonają się w całości, albo się nie wykonają w ogóle. Jeśli wystąpi błąd, i błąd ten nie będzie obsłużony, wtedy żadna z elementarnych instrukcji zawartych w bloku nie wykona się. Działanie bloków nierozerwalnych można odnieść np. do pojedynczej instrukcji, która usuwa wiele rekordów z bazy (np. delete from tab1 where id > 1000). W wyniku działania takiej instrukcji usuną się wszystkie rekordy spełniające kryterium usuwania, albo żaden jeśli dla dowolnego rekordu wystąpi błąd. 12

13 Ciało procedury dodaj_osobe begin atomic declare v_id_osoby bigint; select id_osoby into v_id_osoby from new table( insert into osoba(imie,nazwisko) values (p_imie, p_nazwisko)) as t; insert into adres (id_osoby,miejscowosc,ulica,nr_domu,kod_pocztowy) values (v_id_osoby,p_miejscowosc,p_ulica, p_nr_domu, p_kod_pocztowy); Dzięki wykorzystaniu bloku nierozerwalnego możemy wstawić w jednej logicznej części osobę i adres. Mamy gwarancję, że jeśli wystąpi błąd przy wstawianiu adresu to wstawienie osoby zostanie automatycznie anulowane. Zwróć uwagę, że nie jest to wycofanie transakcji (rollback). Na zewnątrz bloku można umieścić instrukcję COMMIT bądź ROLLBACK, która będzie obejmowała także instrukcje wywołane przed uruchomieniem procedury (bloku). W programach funkcjonalność podobną do BEGIN ATOMC można uzyskać poprzez punkty zapisu transakcji (SAVEPOINT, ROLLBACK TO SAVEPOINT). Dla pseudo kodu poniżej: OK oznacza poprawne wykonanie, BŁĄD oznacza zakończenie instrukcji z błędem. instrukcja1; -- OK begin atomic end; instrukcja2; -- OK instrukcja3; -- BŁĄD instrukcja4; instrukcja5; -- OK commit; Transakcja niejawnie rozpoczyna się w momencie wykonania instrukcji1. Błąd, który wystąpił w instrukcji3 spowoduje, że modyfikacje dokonane w instrukcji2 będą anulowane. Instrukcja4 nie będzie wykonana ze względu na nieobsłużony błąd w instrukcji3. Instukcja commit zatwierdzi modyfikacje z instukcji1 oraz instrukcji5. 13

14 Testowanie procedury dodaj_osobe call dodaj_osobe( 'Anna', 'Kalinowska', 'Nowa Iwiczna', 'Biała', '23/14', '12123 '); commit; call dodaj_osobe( 'Anna', 'Kalinowska', 'Nowa Iwiczna', 'Biała', '23/14', '12123 '); SQLCODE Czy drugie wywołanie się powiedzie? SQL0803N One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "2" constrains table "PL38219.OSOBA" from having duplicate rows for those columns. SQLSTATE=23505 SQLSTATE O jaką regułę spójności chodzi? Powtórne wywołanie procedury dodaj_osobę () z tymi samymi argumentami nie powiedzie się, ze względu na wcześniej zdefiniowaną regułę niepowtarzalności. Baza w komunikacie o błędzie podaje kod błędu oraz SQLSTATE. Kod błędu ma charakter specyficzny dla DB2, natomiast SQLSTATE ma charakter ogólny (standard ANSI) i jest zgodny z bazami danych innych producentów. Zwróć uwagę na wyjaśnienie kodu błędu. 14

15 Sprawdzenie błędu dodaj_osobe db2? SQL0803N db2? Sprawdzenie błędu SELECT INDNAME, INDSCHEMA, COLNAMES FROM SYSCAT.INDEXES WHERE IID = 2 AND TABSCHEMA = 'PL38219' AND TABNAME = 'OSOBA' ; Wynika z opisu błedu PL38219.OSOBA_NAZ_UQ (+NAZWISKO+IMIE) Informacja o naruszonym warunku Podając w linii poleceń tekstowych znak zapytania i kod błędu bądź SQLSTATE możemy szybko uzyskać opis błędu. Zwróć uwagę, że komunikat błędu dla SQLSTATE jest bardzo lakoniczny. db2? SQLSTATE 23505: Wystąpiło naruszenie ograniczenia narzuconego przez indeks unikalny lub ograniczenie przez unikalność (UNIQUE). Dużo dokładniejszy opis błędu można uzyskać wykorzystując kod błędu, który będzie zawierał także szczegółowe instrukcje objaśniające, jak dowiedzieć się która reguła integralnościowa została naruszona. W opisie wygenerowanym poleceniem db2? SQL0803N podane zostało zapytanie pozwalające na identyfikację nazwy naruszonej reguły niepowtarzalności. 15

16 Sprawdzenie błędu w proced. dodaj_osobe Modyfikujemy procedurę (trochę inaczej ): -jeśli OSOBA istnieje to uaktualnij ADRES begin atomic declare v_id_osoby bigint; zakres działania handler-a begin declare continue handler for sqlstate '23505' begin select id_osoby into v_id_osoby from osoba where imie = p_imie and nazwisko = p_nazwisko; end; select id_osoby into v_id_osoby from new table(insert into osoba(imie,nazwisko) values (p_imie, p_nazwisko)) as t; end; [..] W powyższym przykładzie najpierw próbujemy wstawiać nowy rekord i jeśli okaże się, że dany rekord już istnieje (to samo imię i nazwisko), wtedy pobieramy z bazy id_osoby. W ciele procedury zdefiniowaliśmy handler, czyli kod obsługi wyjątków, który będzie wywołany, jeśli wystąpi dany błąd. Handler typu kontynuuj oznacza, że po wystąpieniu błędu zostanie wywołany kod obsługi błędu (na rysunku na niebiesko), a następnie procedura zostanie kontynuowana od instrukcji, gdzie wystąpił błąd. Zwróć uwagę na zakres działania handlera. Gdybyśmy zdefiniowali exit handler, wtedy po wykonaniu kodu handlera, opuścilibyśmy blok begin end, a następnie dalej kontynuowalibyśmy wykonywanie procedury, ale od pierwszej instrukcji znajdującej się po bloku, z którego wyszliśmy. Innymi słowy, handler odnosi się do danego bloku, a nie całej procedury. Exit handler wychodzi z bloku begin..end a nie z całej procedury. Zwróć uwagę, że w naszym przykładzie wykorzystaliśmy dodatkowy, zagnieżdżony blok. Jeszcze jedna uwaga: deklaracje handlerów, jak i deklaracje zmiennych dopuszczane są tylko na początku bloku (zaraz po begin, a przed jakąkolwiek instrukcją SQL). 16

17 Zakres działania handlera begin atomic declare v_id_osoby bigint; begin declare continue handler for sqlstate '23505' [..] end; Na razie nie modyfikujmy tej części kodu insert into adres (id_osoby,miejscowosc,ulica,nr_domu,kod_pocztowy) values (v_id_osoby,p_miejscowosc,p_ulica, p_nr_domu, p_kod_pocztowy); Czy teraz powtórne wywołanie procedury z tymi samymi argumentami powiedzie się? SQL0803N One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "1" constrains table "PL38219.ADRES" from having duplicate rows for those columns. SQLSTATE=23505 Gdybyśmy teraz chcieli wykonać tak utworzoną procedurę z tymi samymi argumentami jak wcześniej, dostaniemy znów błąd związany z naruszeniem reguły niepowtarzalności, ale tym razem już innej niż poprzednio (reguły mówiącej, że dana osoba może mieć tylko jeden adres sprawdź schemat tabeli adres ze wcześniejszych slajdów). 17

18 Uaktualnienie adresu merge into adres using table( values ( v_id_osoby, p_miejscowosc, p_ulica, p_nr_domu, p_kod_pocztowy) ) tmp (id_osoby,miejscowosc,ulica,nr_domu,kod_pocztowy) Zbiór wierszy, zwykle wynik SELECT-a on ( adres.id_osoby = tmp.id_osoby) when matched then update set (miejscowosc, ulica, nr_domu, kod_pocztowy) = (tmp.miejscowosc,tmp.ulica,tmp.nr_domu,tmp.kod_pocztowy) when not matched then insert (id_osoby,miejscowosc,ulica,nr_domu,kod_pocztowy) values (tmp.id_osoby,tmp.miejscowosc,tmp.ulica, tmp.nr_domu, tmp.kod_pocztowy); By nie dostawać błędu związanego z istnieniem danego adresu przyjmijmy, że w takiej sytuacji uaktualnimy dane adresowe. Można to zrobić jedną instrukcją SQL MERGE, która pozwala scalać nie tylko jeden rekord ale wiele rekordów z tabelą docelową. Po słowie kluczowym using można podać nazwę tabeli, albo zapytanie SQL.W przykładzie podaliśmy konstrukcje table, która tworzy wirtualną tabelę składającą się z jednego rekordu zbudowanego na podstawie parametrów wejściowych procedury: table( values ( v_id_osoby, p_miejscowosc, p_ulica, p_nr_domu, p_kod_pocztowy) ) tmp (id_osoby,miejscowosc,ulica,nr_domu,kod_pocztowy) Rekord ten będzie scalony z tabelą adres. Jeśli rekord o id_osoby będzie istniał w tabeli adres, wtedy wykona się uaktualnienie rekordu, jeśli nie będzie istniał, wtedy zostanie wstawiony nowy rekord. Klauzulę table(..) możemy zastąpić zapytaniem na specjalnej tabeli systemowej, która zawiera dokładnie jeden rekord: ( select v_id_osoby, p_miejscowosc, p_ulica, p_nr_domu, p_kod_pocztowy from sysibm.sysdummy1 ) Klauzula values dokonuje po prostu ewaluacji wyrażenia, np.: values zwróci

19 Wstawienie osoby - lepiej begin atomic declare v_id_osoby bigint default null; select id_osoby into v_id_osoby from osoba where imie = p_imie and nazwisko = p_nazwisko; if v_id_osoby is null then select id_osoby into v_id_osoby from new table(insert into osoba(imie,nazwisko) values (p_imie, p_nazwisko)) as t; end if; [..] Dlaczego lepiej niż sprawdzanie błędu? Ponieważ nieudana próba wstawienia niepotrzebnie zwiększa licznik pola generowanego i ogólnie jest kosztowna. Oczywiście fragment kodu związany ze sprawdzeniem, czy dana osoba już istnieje najlepiej poprawić, tak by nie wywoływać obsługi błędu, która z natury jest kosztowna. Dużo lepiej jest sprawdzić na wstępie, czy rekord istnieje, a dopiero potem ewentualnie go wstawić (chyba, że sytuacja, w której wstawiamy osobę, która istnieje już w bazie występuje niezmiernie rzadko). Przy wstawianiu osoby i pobraniu wygenerowanego identyfikatora wykorzystaliśmy klauzulę zapytanie ze wstawienia. 19

20 A co jeśli ktoś wprowadzi imię dużymi literami? call dodaj_osobe( 'Stanisława', 'Kowalska',... call dodaj_osobe( 'Stanisława', 'KOWALSKA',... alter table osoba drop constraint osoba_naz_uq; alter table osoba add column imie_szuk varchar(50) not null generated always as ( ucase( imie) ); alter table osoba add column nazwisko_szuk varchar(50) not null generated always as ( ucase( nazwisko) ); Teraz warunek unikalności dotyczy dużych liter alter table osoba add constraint osoba_naz_uq unique (nazwisko_szuk,imie_szuk) Tak jednak nie pójdzie A gdyby był warunek biznesowy mówiący, że nie możemy wstawić drugi raz osoby o tym samym imieniu i nazwisku, porównując dane dużymi literami? Rozwiązanie: wystarczy dodać pole generowane, które przechowuje imię i nazwisko dużymi literami a następnie założyć regułę niepowtarzalności na tak utworzonych polach. Pokazane na slajdzie instrukcje jednak nie zadziałają, ponieważ na czas dodania pola generowanego należy wyłączyć sprawdzanie integralności i przegenerować wartości dla istniejących rekordów (patrz następny slajd). 20

21 Teraz lepiej alter table osoba drop constraint osoba_naz_uq; set integrity for osoba off; alter table osoba add column imie_szuk varchar(50) not null generated always as ( ucase( imie) ); alter table osoba add column nazwisko_szuk varchar(50) not null generated always as ( ucase( nazwisko) ); set integrity for osoba, adres immediate checked force generated; alter table osoba add constraint osoba_naz_uq unique (nazwisko_szuk,imie_szuk); Tabela adres jest powiązana kluczem z tabelą osoba, stąd wymienione są dwie tabele Tak wygląda poprawny ciąg instrukcji SQL, pozwalający dodać nowe pole i wygenerować dla niego wartości. Zwróć uwagę na instrukcję, która włącza sprawdzanie integralności: set integrity for osoba, adres immediate checked force generated; Integralność należało włączyć nie tylko dla tabeli osoba, ale także dla tabeli adres. Dlaczego? Dlatego, iż tabele są powiązane ze sobą regułami referencyjnymi (klucz podstawowy klucz obcy). Wyłączając integralność tabeli osoba automatycznie wyłączyliśmy integralność tabel powiązanych (tu: adres). By sprawdzić, które tabele są w stanie wyłączenia sprawdzania integralności, najlepiej sięgnąć do systemowego słownika bazy danych (system catalog). 21

22 Modyfikacja kodu procedury - obsługa dużych liter begin atomic declare v_id_osoby bigint default null; select id_osoby into v_id_osoby from osoba where ucase(imie) = ucase(p_imie) and ucase(nazwisko) = ucase(p_nazwisko); [..] A co z wydajnością? Teraz sprawdzimy, czy osoba istnieje w bazie danych w następujący sposób: Funkcją UCASE podniesiemy do dużych liter zmienne będące argumentami procedury, a następnie porównamy je zawartością pól imię i nazwisko podniesionych do dużych liter także funkcją UCASE. Pewnie zadajesz sobie pytanie, a co z wydajnością?. Czy baza nie będzie nie będzie musiała sekwencyjnie odczytać całą tabelę (by podnieść do dużych liter)? Odpowiedź na następnych slajdach. 22

23 Plan wykonania zapytania dla pola generowanego (tekstowo) db2 -tf "%DB2PATH%\misc\EXPLAIN.DDL" Utworzenie tabel dla wyjaśnionych zapytań set current explain mode = EXPLAIN; Zapytania będą wyjaśniane oraz nie wykonywane select id_osoby from osoba where ucase(imie) = ucase('jerzy') and ucase(nazwisko) = ucase('pasula'); Plan zapytania jest zapisany w utworzonych tabelach db2exfmt -d %DBNAME% -e %USERNAME% -n %% -s %% -g TIC -o %1.exfmt -w -1 -# 0 Prezentowanie planów zapytań w formacie tekstowym To, jak baza danych wykonuje zapytanie najlepiej sprawdzić przy pomocy tzw. planu wykonania zapytania. W środowisku graficznym DB2 Centrum Sterowania jest to trywialne (klikasz prawym klawiszem na bazą danych i wybierasz Wyjaśnij zapytanie). W środowisku tekstowym będziesz musiał najpierw utworzyć zestaw tabel, w których będą pamiętane wyjaśnione plany zapytań (narzędzie graficzne robi to za Ciebie). Jeśli wykonasz następującą instrukcję: set current explain mode = EXPLAIN wtedy zapytania dla bieżącej sesji będą tylko wyjaśniane (bez wykonywania). Plan wykonania zapytania zostanie przechowany we wcześniej utworzonych (skryptem EXPLAIN.DDL) tabelach. Narzędzie db2exfmt podłącza się do bazy danych, sięga do tabel z wyjaśnionymi zapytaniami i formatuje wyniki zapisując je do pliku tekstowego. W przykładzie wykorzystano zmienne ustawione w systemie Windows (tak naprawdę jest to fragment skryptu): %DBNAME% nazwa bazy danych %USERNAME% nazwa użytkownika %1.exfmt plik, do którego będzie zapisany plan wykonania zapytania. W systemach Linux/UNIX użyj pojedynczego znaku % zamiast %%. 23

24 exfmt.ksh -- skrypt dla Linuksa/UNIX if [[ $1 = '' ]]; then echo Brak argumentow: <plik SQL> <poziom optymalizacji>" exit fi DBNAME="BAZA1" QF=${1:-'sql.filename'} QO=${2:-'7'} db2 set current query optimization = $QO db2 set current explain mode = EXPLAIN db2 -tvf $QF db2exfmt -d ${DBNAME} -e ${USER} -n % -s % -g TIC -o $QF.exfmt -w -1 -# 0 db2 set current explain mode = NO Oto przykładowy skrypty shell-owy exfmt.ksh dla systemów Linux/UNIX, który można wykorzystać do generowania planu wykonania zapytania. Skrypt tworzy plik ze sformatowanym planem zapytania o takiej nazwie, jak plik zawierający analizowane zapytanie, z doklejonym rozszerzeniem.exfmt Przykład wywołania: exfmt.ksh zapytanie.sql 5 Plik wynikowy: zapytanie.sql.exfmt Oto odpowiednik skryptu dla systemu Windows: exfmt.bat (zmień nazwę bazy danych wskrypcie) set DBNAME=BAZA1 set OPTLEVEL=%2 db2 set current query optimization = %OPTLEVEL% db2 set current explain mode = EXPLAIN db2 -tvf %1 db2exfmt -d %DBNAME% -e %USERNAME% -n %% -s %% -g TIC -o %1.exfmt -w -1 -# 0 db2 set current explain mode = NO 24

25 Plan wykonania zapytania - skrypt exfmt.bat Rows RETURN ( 1) Cost I/O 1 FETCH ( 2) / \ 1 18 IXSCAN ( 3) OSOBA INDEX: PL38219 OSOBA_NAZ_UQ TABLE: PL38219 Original Statement select id_osoby from osoba where ucase(imie) = ucase('jerzy') and ucase(nazwisko) = ucase('pasula') Optimized Statement SELECT Q1.ID_OSOBY AS "ID_OSOBY" FROM PL38219.OSOBA AS Q1 WHERE ( Q1.NAZWISKO_SZUK = UCASE('Pasula')) AND (Q1.IMIE_SZUK = UCASE('Jerzy')) Oto plan wykonania zapytania wyszukującego imię i nazwisko dużymi literami. Zwróć uwagę, że DB2 wykorzystało indeks OSOBA_NAZ_UQ. Na grafie węzeł (3) odszukuje dany rekord z wykorzystaniem indeksu, a następnie doczytuje z tabeli pozostałe kolumny węzeł (2). Analizując plan wykonania zapytania zwróć uwagę na zoptymalizowaną postać zapytania. DB2 przepisało zapytanie do postaci, w której sięga do pól generowanych (pola nazwisko_szuk, imie_szuk) i dlatego mogło wykorzystać indeks, który był na nich założony. Jak czytać graf? Zwróć uwagę, że korzeń grafu zawiera wyjaśniającą legendę. Czytając graf analizuj, w których gałęziach drzewa przyrasta koszt. 1 FETCH ( 2) Liczba zwróconych wierszy Wykonywana operacja Numer węzła, do którego nawiązuje dalsza część raportu Umowny koszt (jednostka: timeron) służący do porównywania różnych planów wykonania tego samego zapytania Umowny koszt operacji dyskowych IXSCAN - oznacza odczytanie wewnętrznego adresu rekordu z wykorzystaniem indeksu. FETCH - doczytuje pozostałe kolumny, dla rekordu o danym adresie wewnętrznym. 25