Obiekty bazy danych DB2 Obiektem bazy danych DB2 jest każdy składnik bazy danych DB2, jak: schematy, tabele, widoki, indeksy, sekwencje, aliasy, wyzwalacze, funkcje użytkownika (UDF-y), procedury zapamiętane, pakiety, itp. Obiekty bazodanowe zapewniają kontrolę nad tym, w jaki sposób wszystkie dane użytkownika (oraz niektóre dane systemowe) są przechowywane i zorganizowane w bazie DB2. Baza danych składa się ze schematów, których zadaniem jest logiczne grupowanie obiektów. Schemat jest kolekcją obiektów bazy danych i umożliwia ich klasyfikację i grupowanie na poziomie logicznym. Może zawierać tabele, indeksy, widoki, wyzwalacze, funkcje, itp. Nazwy obiektów w bazie danych są z reguły dwuczłonowe - pierwsza część to nazwa schematu (tzw. kwalifikator), druga część to nazwa obiektu, co umożliwia ich jednoznaczną identyfikację, np. aniaf.employee - aniaf to nazwa schematu, w którym znajduje się obiekt (w tym przypadku tabela) employee. Odwołując się do obiektu używamy składninazwa_schematu.nazwa_obiektu. Baza danych składa się ze schematów, których zadaniem jest logiczne grupowanie obiektów. Schemat jest kolekcją obiektów bazy danych i umożliwia ich klasyfikację i grupowanie na poziomie logicznym. Może zawierać tabele, indeksy, widoki, wyzwalacze, funkcje, itp. Nazwy obiektów w bazie danych są z reguły dwuczłonowe - pierwsza część to nazwa schematu (tzw. kwalifikator), druga część to nazwa obiektu, co umożliwia ich jednoznaczną identyfikację, np. aniaf.employee - aniaf to nazwa schematu, w którym znajduje się obiekt (w tym przypadku tabela) employee. Odwołując się do obiektu używamy składninazwa_schematu.nazwa_obiektu. Jeżeli nie podamy nazwy schematu, DB2 użyje domyślnej nazwy schematu, która jest przechowywana w zmiennej systemowej CURRENT SCHEMA. Zmienna ta jest ustawiana na początku danej sesji i domyślnie jest równa loginowi danego użytkownika (wartość zmiennej CURRENT SCHEMA można zmienić za pomocą instrukcji SET CURRENT SCHEMA, a odczytać za pomocą VALUES CURRENT SCHEMA). Schemat można stworzyć na dwa sposoby: niejawnie lub jawnie.
Schemat można stworzyć na dwa sposoby: niejawnie lub jawnie. Tworzenie schematu w sposób niejawny: taka sytuacja ma miejsce, gdy użytkownik tworzy inny obiekt, np. tabelę, i nie poda, w jakim schemacie obiekt ma zostać stworzony, wówczas używany jest domyślny schemat tego użytkownika (schemat ten zostanie w tym momencie stworzony, jeżeli nie powstał wcześniej; domyślnie, DB2 używa nazwy użytkownika (dokładniej - wartości zmiennej CURRENT SCHEMA) jako nazwy tak stworzonego schematu), np. CREATE TABLE test(id int); Niejawne tworzenie schematu ma też miejsce, gdy podczas tworzenia obiektu podamy nazwę schematu, którego nie ma w bazie, np. CREATE TABLE kadry.pracownik(nr int, imie varchar(15), nazwisko varchar(25)); Zostanie wówczas utworzony schemat kadry (o ile go wcześniej nie było). Uwaga. Właścicielem schematu utworzonego w sposób niejawny jest SYSIBM. Drugi sposób to jawne utworzenie schematu instrukcją CREATE SCHEMA <nazwa> AUTHORIZATION <nazwa_użytkownika>; Uwaga. Właścicielem tak utworzonego schematu jest użytkownik podany w instrukcji CREATE SCHEMA. Właściciel schematu ma uprawnienia do tworzenia, zmiany i usuwania obiektów wewnątrz schematu, usuwania schematu oraz może przekazywać te uprawnienia innym użytkownikom. Drugi sposób to jawne utworzenie schematu instrukcją CREATE SCHEMA <nazwa> AUTHORIZATION <nazwa_użytkownika>; Uwaga. Właścicielem tak utworzonego schematu jest użytkownik podany w instrukcji CREATE SCHEMA. Właściciel schematu ma uprawnienia do tworzenia, zmiany i usuwania obiektów wewnątrz schematu, usuwania schematu oraz może przekazywać te uprawnienia innym użytkownikom. W kolejnym kroku, można tworzyć obiekty wewnątrz wcześniej utworzonego schematu. CREATE SCHEMA test AUTHORIZATION db2admin tworzy schemat test, użytkownik db2admin jest właścicielem tego schematu; CREATE TABLE test.country (nr INT, nazwa VARCHAR(30)) tworzy tabelę country w obrębie schematu test.
Informacja, jakie schematy znajdują się w bazie danych, przechowywana jest w widoku systemowymsyscat.schemata. Aby wyświetlić, jakie schematy znajdują się w bazie danych, można użyć instrukcji SELECT schemaname, owner, definer FROM SYSCAT.SCHEMATA Uprawnienia na poziomie schematów można odczytać z widoku systemowegosyscat.schemaauth. Uwaga. Grupa PUBLIC posiada uprawnienie CREATEIN dla schematu stworzonego w sposób niejawny (uprawnienie to pozwala na tworzenie obiektów wewnątrz schematu; jest to domyślne ustawienie dla baz danych, które nie zostały stworzone z opcją RESTRICTIVE). Aby uzyskać listę tabel schematu, używamy instrukcji db2 list tables for schema <nazwa> Aby uzyskać listę tabel dla wszystkich schematów w bazie: db2 list tables for all Aby uzyskać listę tabel schematu, używamy instrukcji db2 list tables for schema <nazwa> Aby uzyskać listę tabel dla wszystkich schematów w bazie: db2 list tables for all Korzyści ze stosowania schematów: Eliminują konieczność żmudnego przeszukiwania całej bazy danych w celu znalezienia danego obiektu - schematy w sposób logiczny grupują obiekty. Nazwy obiektów muszą być unikalne w obrębie schematu (natomiast mogą się powtarzać w bazie danych). Ułatwiają kontrolę dostępu do danych - właściciel schematu może kontrolować, którzy użytkownicy mogą tworzyć, zmieniać lub usuwać obiekty w obrębie danego schematu.
Wbudowane typy danych DB2 Tabele Dane w relacyjnej bazie danych znajdują się w tabelach, składających się ze zbioru wierszy oraz kolumn. Każda kolumna tabeli ma określony typ danych. W bazie DB2 mamy dwa rodzaje tabel: tabele bazowe, definiowane przez użytkownika, które przechowują stałe dane, oraz tabele tymczasowe, służące do tymczasowego przechowywania danych, na potrzeby danej aplikacji. Tabele tymczasowe są tworzone w sposób jawny przez aplikację w razie potrzeby, oraz usuwane automatycznie w momencie, gdy aplikacja zamknie ostatnie połączenie z bazą danych. Tabele tymczasowe są przydatne, jeżeli aplikacja potrzebuje stworzyć wiele raportów używających tych samych danych. Wówczas użycie tabeli tymczasowej i skopiowanie do niej zbioru rekordów może być bardziej efektywne, niż wielokrotne wysyłanie zapytań SQL. Tworzenie tabeli tymczasowej: DECLARE GLOBAL TEMPORARY TABLE. Składnia tej instrukcji jest analogiczna, do składni instrukcji CREATE. Można też utworzyć tabelę tymczasową na wzór istniejącej tabeli bazowej, używając opcjilike <nazwa_tabeli_bazowej>. DECLARE GLOBAL TEMPORARY TABLE tempemployee LIKE employee Aby tabela tymczasowa zachowała wiersze po wykonaniu instrukcji COMMIT, należy dodać klauzulęon COMMIT PRESERVE ROWS (domyślnie wiersze są usuwane). Tabela tymczasowa istnieje tylko w obrębie danej sesji. Aby można było odwołać się to niej z poziomu polecenia SQL, należy użyć kwalifikatorasession. Uwaga. musi istnieć tymczasowa przestrzeń tabel użytkownika, aby można było tworzyć tabele tymczasowe. Przykład: tworzenie tabeli tymczasowej, o takich samych kolumnach, jak tabela employee, zachowującej wiersze po wykonaniu instrukcji COMMIT i kopiowanie do niej wierszy z tabeli employee: DECLARE GLOBAL TEMPORARY TABLE tempemployee LIKE employee ON COMMIT PRESERVE ROWS; INSERT INTO SESSION.tempemployee SELECT * FROM employee WHERE salary < 3000; SELECT * FROM SESSION.tempemployee; Po wykonaniu instrukcji COMMIT i zamknięciu połączenia z bazą, tabela tempemployee przestaje istnieć.
Tworzenie tabel bazowych Tworzenie tabel bazowych Tabele tworzymy instrukcjącreate TABLE, np. CREATE TABLE STAFF ( ID SMALLINT NOT NULL, NAME VARCHAR(9), DEPT SMALLINT NOT NULL WITH DEFAULT 10, JOB CHAR(5), YEARS SMALLINT, SALARY DECIMAL(7,2), COMM DECIMAL(7,2) WITH DEFAULT 15); Definiując kolumnę tabeli, można użyć wartości domyślnej DEFAULT dla tej kolumny. DB2 umożliwia też generowanie wartości za pomocą opcji GENERATED. W sytuacji, gdy klucz główny tabeli jest pojedynczą kolumną, zawierającą kolejne liczby całkowite, lub gdy wartość w kolumnie ma być wyliczana na podstawie innych kolumn, można skorzystać z automatycznego generowania wartości. Tworzenie tabel bazowych W definicji tabeli oprócz definicji kolumn można też określić ograniczenia (constraints): unikalności i integralności danych. Mamy trzy główne typy ograniczeń: Ograniczenia unique zapewnia unikalność kluczy (głównego oraz unikalnych) tabeli. Ograniczenia referencyjne wymusza ograniczenia referencyjne dotyczące operacji wstawiania, aktualizacji i usuwania, zapewnia, że wartości wszystkich kluczy obcych są odpowiednie. Ograniczenia check zapewnia zgodność danych ze zdefiniowanym dla danej tabeli ograniczeniem CHECK. Automatyczne generowanie wartości Wykorzystanie do generowania wartości kluczy głównych - używamy klauzuligenerated ALWAYS AS IDENTITY w definicji kolumny (kolumna IDENTITY powinna być: typu całkowitoliczbowego, może być tylko jedna w tabeli, DB2 niejawnie nadaje jej ograniczenie NOT NULL, nie można zdefiniować dla niej DEFAULT): CREATE TABLE EMPLOYEE (EMPNO INT GENERATED ALWAYS AS IDENTITY, NAME CHAR(10)); Wartości w kolumnie EMPNO są generowane automatycznie przez DB2 (domyślnie zaczynając od 1, z krokiem 1).
Automatyczne generowanie wartości Automatyczne generowanie wartości Wykorzystanie do generowania wartości kluczy głównych - używamy klauzuligenerated ALWAYS AS IDENTITY w definicji kolumny (kolumna IDENTITY powinna być: typu całkowitoliczbowego, może być tylko jedna w tabeli, DB2 niejawnie nadaje jej ograniczenie NOT NULL, nie można zdefiniować dla niej DEFAULT): Można zmienić krok lub wartość początkową: CREATE TABLE EMPLOYEE ( EMPNO INT GENERATED ALWAYS AS IDENTITY(START WITH 100, INCREMENT BY 10)), NAME CHAR(10)); Uwaga. zdefiniowanie kolumny w ten sposób nie jest równoznaczne z zapewnieniem jej unikalności. W tym celu należy nałożyć na kolumnę klucz główny lub indeks unikalny. Jeżeli wartości w kolumnie w tabeli są wyliczane na podstawie wartości w innych kolumnach, można skorzystać z automatycznego generowania wartości: CREATE TABLE EMPLOYEE ( EMPNO INT GENERATED ALWAYS AS IDENTITY, NAME CHAR(10), SALARY INT, BONUS INT, PAY INT GENERATED ALWAYS AS (SALARY+BONUS) ); Ograniczenia tabeli Ograniczenie unique: każda kolumna wchodząca w skład klucza unikalnego musi być zadeklarowana jako NOT NULL; ograniczenie typu unique definiujemy w instrukcji CREATE TABLE lub ALTER TABLE za pomocą klauzuli: PRIMARY KEY lub UNIQUE. w momencie tworzenie ograniczenia, zakładany jest automatycznie indeks unikalny, który służy do zapewnienia unikalności danych. Ograniczenie referencyjne: umożliwia zdefiniowanie związków pomiędzy tabelami; w tabeli podrzędnej określany jest klucz obcy, odwołujący się do klucza głównego lub unikalnego w tabeli nadrzędnej; zapewnia, że każda wartość w kluczu obcym odpowiada jednej z wartości klucza z tabeli nadrzędnej. Istnienie ograniczenia referencyjnego wpływa na działanie instrukcji INSERT, UPDATE oraz DELETE, wykonywanych na tabeli podrzędnej oraz nadrzędnej. Mianowicie, aby dana instrukcja była poprawna, musi spełniać określone reguły.
Reguły dla INSERT: wstawianie wierszy do tabeli nadrzędnej - bez ograniczeń; do tabeli podrzędnej można wstawiać tylko takie wiersze, dla których wartość klucza obcego odpowiada wartości klucza w tabeli nadrzędnej; jeżeli w jednym zapytaniu INSERT wstawiamy kilka wierszy, i dla jednego z nich jest naruszone ograniczenie, żaden wiersz nie zostanie wstawiony. Reguły dla DELETE: kiedy usuwamy wiersz z tabeli nadrzędnej, menadżer bazy danych sprawdza, czy są jakieś wiersze zależne w tabeli podrzędnej, odpowiadające usuwanym wierszom; jeżeli tak, to wówczas wykonywana jest jedna z następujących akcji (która z akcji ma być podjęta jest określane w definicji tabeli podrzędnej). Akcje te są definiowane za pomocą opcjion DELETE <akcja>. RESTRICT nie można usuwać wiersza z tabeli nadrzędnej, jeżeli istnieje odwołanie w tabeli podrzędnej; NO ACTION opcja domyślna; CASCADE DELETE automatycznie usuwane są wiersze w tabeli podrzędnej, zależne od usuwanego wiersza w tabeli nadrzędnej; SET NULL wartości klucza obcego w wierszach zależnych w tabeli podrzędnej są ustawiane na NULL (o ile dana kolumna akceptuje wartości puste). Reguły dla UPDATE: Menadżer bazy danych zapobiega zmienianiu wartości klucza w tabeli nadrzędnej w wierszu, dla którego istnieją wiersze zależne w tabeli podrzędnej. Wartości klucza obcego w tabeli podrzędnej nie można zmienić na wartość (niepustą), która nie występuje w kluczu w tabeli nadrzędnej. Dopuszczalne sa dwie opcje (określane za pomocą klauzulion UPDATE <akcja>): RESTRICT blokuje możliwość zmiany wartości klucza w tabeli nadrzędnej, jeżeli istnieje odwołanie w tabeli podrzędnej; The update for the parent key will be rejected if a row in the dependent table matches the original values of the key. NO ACTION blokuje operację zmiany wartości klucza w tabeli nadrzędnej, jeżeli po zakończeniu operacji UPDATE istnieje wiersz w tabeli podrzędnej nie mający odpowiednika w tabeli nadrzędnej; opcja domyślna. Ograniczenia CHECK: zapewniają spójność danych na poziomie tabeli. Przy każdej operacji INSERT, UPDATE ograniczenie CHECK jest sprawdzane. Jeżeli nie jest spełnione, instrukcja zostanie odrzucona. Ograniczenia CHECK można definować w instrukcji CREATE TABLE lub ALTER TABLE, np.: ALTER TABLE pracownik ADD CONSTRAINT check_stanowisko CHECK (stanowisko IN ( Inżynier, Księgowy, Kierownik )); Ograniczenia CHECK umożliwiają implementację reguł sprawdzania poprawności danych bezpośrednio w bazie, zamiast w każdej z aplikacji używającej bazy danych. Informacje o istniejących ograniczeniach CHECK i ich definicje są przechowywane w katalogu systemowym w tabelach SYSIBM.SYSCHECKS oraz SYSCAT.CHECKS.
Ograniczenia informacyjne Wszystkie wcześniej omawiane ograniczenia były sprawdzane i wymuszane przez DB2 na rzecz każdego wstawianego czy modyfikowanego wiersza. Może to prowadzić do dużego obciążenia systemu, szczególnie gdy wstawiamy (zmieniamy) duże ilości rekordów mających ograniczenia referencyjne. Jeżeli dane są wprowadzane do bazy za pomocą aplikacji, która weryfikuje ich poprawność, aby zwiększyć wydajność systemu, można zamiast normalnych ograniczeń użyć ograniczeń informacyjnych. Ograniczenia tego typu nie są sprawdzane przez DB2, ale system wykorzystuje je do optymalizacji zapytań SQL. Uwaga. jeżeli zrezygnujemy z więzów integralności na rzecz ograniczeń informacyjnych, zyskujemy szybsze działanie systemu, ale musimy mieć pewność, że wprowadzane dane spełniają te ograniczenia. Ograniczenia informacyjne Przykład zastosowania ograniczeń informacyjnych: CREATE TABLE pracownik (nr INT NOT NULL, płeć CHAR(1) NOT NULL CONSTRAINT płećok CHECK (płeć IN ( M, K )) NOT ENFORCED ENABLE QUERY OPTIMIZATION, zarobki INT NOT NULL, CONSTRAINT zarobkiok CHECK (zarobki BETWEEN 0 AND 100000) NOT ENFORCED ENABLE QUERY OPTIMIZATION ); W tabeli pracownik są dwa ograniczenia informacyjne:płećok i zarobkiok. W momencie dodania wiersza do tabeli, nie będą sprawdzane (odpowiada za to opcjanot ENFORCED), ale będą używane przez optymalizator zapytań (opcjaenable QUERY OPTIMIZATION). Ograniczenia informacyjne Jeżeli w tabeli użyto opcji NOT ENFORCED, zachowanie instrukcji INSERT może być zaskakujące, np. ta instrukcja wykona się bez błędu: INSERT INTO pracownik VALUES (1, M, 54200), (2, K, 28000), (3, M, 21240), (4, K, 89222), (5, Q, 34444), (6, A,132333); Pracownik nr 5 ma niewłaściwą płeć, nr 6 - płeć i zarobki spoza zakresu, ale ponieważ użyto opcji NOT ENFORCED, DB2 pozwolił na wstawienie tych wierszy. Natomiast zapytanie SELECT * FROM pracownik WHERE płeć= Q zwróci 0 wierszy, ponieważ użyto opcjienable QUERY OPTIMIZATION, więc optymalizator zapytań uznaje, że w kolumnie płeć mogą być tylko dwie wartości ( K lub M ). Aby wyłączyć tą opcję: ALTER TABLE pracownik ALTER CHECK płećok DISABLE QUERY OPTIMIZATION Zmiana definicji tabeli InstrukcjaALTER TABLE umożliwia zmiany dotyczące kolumn tabeli: dodanie kolumny ALTER TABLE <nazwa> ADD COLUMN <definicja> usunięcie kolumny ALTER TABLE <nazwa> DROP COLUMN <nazwa> zmianę typu kolumny ALTER TABLE <nazwa> ALTER COLUMN <nazwa> SET DATA TYPE <typ danych> usunięcie NOT NULL ALTER TABLE <nazwa> ALTER COLUMN <nazwa> DROP NOT NULL nałożenie NOT NULL ALTER TABLE <nazwa> ALTER COLUMN <nazwa> SET NOT NULL te zmiany wymagają wydania instrukcjireorg TABLE zanim będzie możliwa zmiana danych w tabeli.
Widoki i zmiany ograniczeń tabeli: nałożenie ograniczeniaalter TABLE <nazwa> ADD CONSTRAINT <definicja> usunięcie ograniczeniaalter TABLE <nazwa> DROP CONSTRAINT <nazwa> zmianę ograniczeniaalter TABLE <nazwa> ALTER CONSTRAINT <definicja> Widok (inaczej perspektywa) jest definiowany w oparciu o dowolne zapytanie SELECT, umożliwia zapisanie tego zapytania a następnie odwołanie się do niego w dowolnej chwili, bez konieczności ponownego wpisywania całej instrukcji. Widok nie przechowuje danych, jedynie definicja widoku jest zapisana w bazie. Widoki Widok (inaczej perspektywa) jest definiowany w oparciu o dowolne zapytanie SELECT, umożliwia zapisanie tego zapytania a następnie odwołanie się do niego w dowolnej chwili, bez konieczności ponownego wpisywania całej instrukcji. Widok nie przechowuje danych, jedynie definicja widoku jest zapisana w bazie. Widoki Widok (inaczej perspektywa) jest definiowany w oparciu o dowolne zapytanie SELECT, umożliwia zapisanie tego zapytania a następnie odwołanie się do niego w dowolnej chwili, bez konieczności ponownego wpisywania całej instrukcji. Widok nie przechowuje danych, jedynie definicja widoku jest zapisana w bazie. Widoki są wykorzystywane m.in., aby: ograniczyć dostęp do pewnych, bardziej istotnych lub wrażliwych, danych, zmienić sposób prezentacji danych, zaprezentować dane zapisane w różnych tabelach jako całość.
Widoki Widoki Widok może być tylko do odczytu (read-only) lub modyfikowalny. Widoki modyfikowalne umożliwiają zmianę danych w tabelach bazowych. Widok tworzy się instrukcją CREATE VIEW nazwa_widoku, usuwa za pomocą DROP VIEW nazwa_widoku. Widok może być tylko do odczytu (read-only) lub modyfikowalny. Widoki modyfikowalne umożliwiają zmianę danych w tabelach bazowych. Widok tworzy się instrukcją CREATE VIEW nazwa_widoku, usuwa za pomocą DROP VIEW nazwa_widoku. CREATE VIEW lista(nr, imie, nazwisko, dzial) AS SELECT t1.id, t1.imie, t1.nazwisko, t2.dzial FROM osoba t1 JOIN dzial t2 ON(t1.nr_dzialu=t2.nr_dzialu) Widoki zastosowania Widoki zastosowania 1. Wygoda użytkowników. Ułatwienie pracy poprzez utworzenie widoków zawierających często używane lub skomplikowane zapytania. 2. Możliwość prezentowania danych w takiej postaci, która odpowiada danemu użytkownikowi (można w ten sposób zmienić nazwy kolumn na bardziej czytelne dla użytkownika, przeprowadzić na danych pewne wstępne operacje, np. dane liczbowe można zaokrąglić do wymaganej dokładności, usunąć zbędne spacje, itp.). 3. Ukrywanie efektów normalizacji poprzez tworzenie widoków zawierających złączenia tabel. 4. Ograniczenie dostępu do danych. Zamiast nadać użytkownikowi uprawnienia do tabeli, można nadać uprawnienia do korzystania z widoków zawierających tylko te dane, które są potrzebne danemu użytkownikowi, np. dla danej tabeli można stworzyć widok zawierający tylko wybrane kolumny (lub wiersze) i w ten sposób ukryć pozostałe dane przed użytkownikiem. 5. Zapewnienie danym bezpieczeństwa. Widoki mogą być użyte do stworzenia warstwy abstrakcji pomiędzy użytkownikiem a tabelami bazowymi, w oparciu o które zostały zbudowane.
Klasyfikacja widoków W zapytaniach SELECT wszystkie widoki funkcjonują jak tabele. Dla widoków modyfikowalnych dopuszczalne jest także przeprowadzanie operacji na danych. Poprzez widoki modyfikowalne mamy możliwość zmiany danych w tabelach bazowych. Widoki można podzielić ze względu na typ operacji, na jakie pozwalają. Wyróżniamy widoki: Deletable Updatable Insertable Read-only Powyższa klasyfikacja wskazuje rodzaj operacji SQL, który jest dozwolony dla widoku (DELETE, UPDATE, INSERT). Widoki pierwszych trzech typów określamy jako modyfikowalne. Widok jest read-only, jeżeli nie spełnia chociaż jednej z reguł określonych dla widoków deletable. Kolumna READONLY w widoku systemowym SYSCAT.VIEWS wskazuje, czy widok jest read-only (R). Widoki modyfikowalne Warunki, jakie musi spełniać widok modyfikowalny, zależą od tego, którą z operacji DELETE, UPDATE czy INSERT chcemy wykonać. Ogólna reguła jest taka: każdemu wierszowi widoku musi odpowiadać dokładnie jeden wiersz w tabeli. Widok spełniający poniższe kryteria będzie widokiem deletable: 1. dane pochodzą z jednej tabeli; 2. nie zawiera klauzuli DISTINCT; 3. nie zawiera GROUP BY, HAVING; 4. nie zawiera funkcji agregacji (na liście SELECT); 5. nie zawiera operacji na zbiorach (UNION, EXCEPT, INTERSECT); 6. nie jest oparty o inny widok niemodyfikowalny. Widoki modyfikowalne Aby poprzez widok można było modyfikować dane z użyciem operacji INSERT lub UPDATE, to oprócz podanych wcześniej warunków, widok nie może zawierać wyrażenia na liście SELECT; aby można było wykonać INSERT na widoku, to każda kolumna NOT NULL bez wartości domyślnej w tabeli, o którą oparty jest widok, musi być w tym widoku odwzorowana. Widoki modyfikowalne Aby poprzez widok można było modyfikować dane z użyciem operacji INSERT lub UPDATE, to oprócz podanych wcześniej warunków, widok nie może zawierać wyrażenia na liście SELECT; aby można było wykonać INSERT na widoku, to każda kolumna NOT NULL bez wartości domyślnej w tabeli, o którą oparty jest widok, musi być w tym widoku odwzorowana. Uwaga. Jeżeli wykonujemy operację INSERT na widoku modyfikowalnym, to do tych kolumn, które nie są wymienione w widoku, zostaną wpisane ich wartości domyślne (o ile są zdefiniowane), NULL w przeciwnym przypadku.
Widoki modyfikowalne Aby poprzez widok można było modyfikować dane z użyciem operacji INSERT lub UPDATE, to oprócz podanych wcześniej warunków, widok nie może zawierać wyrażenia na liście SELECT; aby można było wykonać INSERT na widoku, to każda kolumna NOT NULL bez wartości domyślnej w tabeli, o którą oparty jest widok, musi być w tym widoku odwzorowana. Uwaga. Jeżeli wykonujemy operację INSERT na widoku modyfikowalnym, to do tych kolumn, które nie są wymienione w widoku, zostaną wpisane ich wartości domyślne (o ile są zdefiniowane), NULL w przeciwnym przypadku. Przykład widoku modyfikowalnego: CREATE OR REPLACE VIEW projektanci AS SELECT empno, firstnme, lastname, workdept,edlevel, hiredate, job, salary FROM employee WHERE job= DESIGNER ; Uwaga. W przypadku modyfikacji danych poprzez widok, dane są zmieniane w tabeli bazowej, w oparciu o którą widok został stworzony. Widoki modyfikowalne z klauzula WITH CHECK OPTION Jeżeli widok modyfikowalny został utworzony z klauzulą CHECK, to nie można dodać ani zmienić danych w tym widoku w taki sposób, że dane te nie będą już w tym widoku widoczne. Widoki modyfikowalne z klauzula WITH CHECK OPTION Poniższe instrukcje modyfikują lub wstawiają dane do widoku projektanci, nie naruszając warunku z klauzuli WHERE: Jeżeli widok modyfikowalny został utworzony z klauzulą CHECK, to nie można dodać ani zmienić danych w tym widoku w taki sposób, że dane te nie będą już w tym widoku widoczne. Zdefiniujmy widokprojektanci z opcją CHECK. CREATE OR REPLACE VIEW projektanci AS SELECT empno, firstnme, lastname, workdept,edlevel, hiredate, job, salary FROM employee WHERE job= DESIGNER WITH CHECK OPTION; UPDATE projektanci SET salary=salary*1.5; INSERT INTO projektanci VALUES(200341, Lolek, Nowak, D11,11, SYSDATE, DESIGNER, 2000);
Indeksy Poniższe instrukcje modyfikują lub wstawiają dane do widoku projektanci, nie naruszając warunku z klauzuli WHERE: UPDATE projektanci SET salary=salary*1.5; INSERT INTO projektanci VALUES(200341, Lolek, Nowak, D11,11, SYSDATE, DESIGNER, 2000); Natomiast ta instrukcja narusza warunek WHERE z definicji widoku, a ponieważ widok był zdefiniowany z klauzulą CHECK, taka instrukcja nie jest poprawna. UPDATE projektanci SET job= MANAGER WHERE empno=000150; Indeksy są mechanizmami umożliwiającymi szybką lokalizację danego wiersza w tabeli. Ich działanie można porównać do roli indeksów w książce - umożliwiają szybkie znalezienie miejsca, gdzie dana informacja jest zapisana, bez potrzeby przeglądania całej tabeli. Indeksy Indeksy Indeksy są mechanizmami umożliwiającymi szybką lokalizację danego wiersza w tabeli. Ich działanie można porównać do roli indeksów w książce - umożliwiają szybkie znalezienie miejsca, gdzie dana informacja jest zapisana, bez potrzeby przeglądania całej tabeli. Indeks jest uporządkowanym zbiorem kluczy, z których każdy wskazuje na wiersz w tabeli. Indeks jest tworzony w oparciu o jedną lub kilka kolumn tabeli, ale jest zapisany i przechowywany jako osobny obiekt. Indeks jest uporządkowanym zbiorem kluczy, z których każdy wskazuje na wiersz w tabeli. Indeks jest tworzony w oparciu o jedną lub kilka kolumn tabeli, ale jest zapisany i przechowywany jako osobny obiekt. Indeksy są wykorzystywane w celu: wymuszenia unikalności danych; jeżeli dla kolumny (lub grupy kolumn) w tabeli został założony indeks unikalny, dane w tej kolumnie nie moga się powtarzać. zwiększenia efektywności; indeks daje szybką i efektywną metodę znalezienia danego wiersza w tabeli zawierającej dużo danych; z reguły, dostęp do danych jest realizowany szybciej z wykorzystaniem indeksu, niż bez.
Indeksy Indeksy Indeks jest uporządkowanym zbiorem kluczy, z których każdy wskazuje na wiersz w tabeli. Indeks jest tworzony w oparciu o jedną lub kilka kolumn tabeli, ale jest zapisany i przechowywany jako osobny obiekt. Idea działania indeksów. W momencie, kiedy dane są dodawane do tabeli, umieszczane są na końcu tabeli. Nie jest określony żaden porządek wierszy w tabeli. W sytuacji, kiedy chcemy wyszukać w tabeli określony wiersz, każdy z wierszy tabeli musi zostać sprawdzony. Indeksy umożliwiają uzyskanie dostępu do danych w tabeli w określonej kolejności. Indeks jest uporządkowanym zbiorem kluczy, z których każdy wskazuje na wiersz w tabeli. Indeks jest tworzony w oparciu o jedną lub kilka kolumn tabeli, ale jest zapisany i przechowywany jako osobny obiekt. Idea działania indeksów. Klucz indeksu to kolumna (lub grupa kolumn), dla których dany indeks został zdefiniowany. Klucz może, ale nie musi, być unikalny. Indeks jest uporządkowany zgodnie z kolejnością wartości jego klucza. Z kolei wartość klucza udostępnia wskaźnik na odpowiedni wiersz w tabeli. Indeks umożliwia więc szybszy dostęp do danych w tabeli. Indeksy Indeks jest uporządkowanym zbiorem kluczy, z których każdy wskazuje na wiersz w tabeli. Indeks jest tworzony w oparciu o jedną lub kilka kolumn tabeli, ale jest zapisany i przechowywany jako osobny obiekt. Idea działania indeksów. Klucz indeksu to kolumna (lub grupa kolumn), dla których dany indeks został zdefiniowany. Klucz może, ale nie musi, być unikalny. Indeks jest uporządkowany zgodnie z kolejnością wartości jego klucza. Z kolei wartość klucza udostępnia wskaźnik na odpowiedni wiersz w tabeli. Indeks umożliwia więc szybszy dostęp do danych w tabeli. Indeksy Indeks jest uporządkowanym zbiorem kluczy, z których każdy wskazuje na wiersz w tabeli. Indeks jest tworzony w oparciu o jedną lub kilka kolumn tabeli, ale jest zapisany i przechowywany jako osobny obiekt. Definicja indeksu: CREATE [UNIQUE] INDEX nazwa_indeksu ON nazwa_tabeli (kolumna1 [ASC/DESC], kolumna2 [ASC/DESC],...) Opcje indeksu: indeks może być rosnący (ASC, domyślnie) albo malejący (DESC); klucze indeksu mogą być unikalne (opcja UNIQUE) lub nie; do stworzenia indeksu można użyć kilku kolumn (taki indeks nazywamy złożonym).
Indeksy Indeksy Uwagi 1. Nie ma możliwości zmiany definicji istniejącego indeksu. Należy go usunąć (instrukcja DROP INDEX) i stworzyć od nowa. 2. Jeżeli w tabeli, dla której tworzymy indeks są już dane, w momencie tworzenia indeksu zostaną też utworzone odpowiednie wpisy w indeksie. Jeżeli w tabeli nie ma jeszcze danych, tworzony jest jedynie opis indeksu. 3. Indeks unikalny pozwala na zapisanie wartości NULL w kolumnie, zatem samo nałożenie indeksu unikalnego na kolumnę nie jest równoznaczne ze zdefiniowaniem tej kolumny jako klucz główny. W tym celu należy nałożyć na kolumnę jeszcze ograniczenie NOT NULL. Indeksy traktują wartość NULL jako równą innej wartości NULL. Stąd jeżeli na kolumnie został założony indeks unikalny, to w tej kolumnie może być tylko jedna wartość NULL. Przykłady: 1. Indeks unikalny o nazwie UNIQUE_NAM dla tabeli PROJECT, na polu PROJNAME. Zadaniem tego indeksu jest zapewnienie, że dla żadnych dwóch wierszy z tej tabeli nazwa projektu (PROJNAME) nie może być taka sama. Wpisy w indeksie są posortowane w sposób domyślny, czyli rosnąco. CREATE UNIQUE INDEX UNIQUE_NAM ON PROJECT(PROJNAME) 2. Indeks złożony o nazwie JOB_BY_DEPT dla tabeli EMPLOYEE. Porządek wpisów w indeksie: nazwy stanowisk (JOB) są uporządkowane rosnąco w obrębie każdego działu (WORKDEPT). CREATE INDEX JOB_BY_DEPT ON EMPLOYEE (WORKDEPT, JOB) Indeksy dwukierunkowe Zalecenia dotyczace tworzenia indeksów OpcjaALLOW REVERSE SCANS w defnicji indeksu umożliwia stworzenie indeksu dwukierunkowego. Taki indeks pozwala na przeglądanie wartości zarówno w porządku rosnącym, jak i malejącym. Od wersji 9, każdy tworzony w DB2 indeks jest domyślnie tworzony z opcjąallow REVERSE SCANS. Zalety stosowania tego typu indeksów: usprawnia wyliczanie wartości funkcji MIN i MAX; jest wykorzystywany przy przeszukiwaniu danych zarówno w porządku rosnącym, jak i malejącym; zamiast tworzyć dla danej tabeli dwa indeksy: rosnący i malejący, wystarczy stworzyć jeden. Uwaga. DB2 automatycznie tworzy indeksy unikalne dla kluczy głównych i unikalnych. Indeksy te są tworzone w sposób domyślny, tzn. jako indeksy dwukierunkowe. Indeksy są używane albo w celu przyspieszenia dostępu do danych, albo aby zapewnić unikalność danych. Indeksy przyspieszają odczyt danych, ale spowalniają operacje modyfikacji danych (każda zmiana danych w tabeli pociąga za sobą uaktualnienie indeksów dla tej tabeli). Tworząc indeks należy wziąć pod uwagę, czy dany indeks poprawi wydajność bazy. Należy przeanalizować strukturę tabeli i rodzaj często wykonywanych zapytań. Automatycznie są tworzone indeksy dla kluczy głównych i unikalnych (chyba, że indeks taki został wcześniej stworzony przez użytkownika).
Zalecenia dotyczace stosowania indeksów Zalecenia dotyczace stosowania indeksów Warto nakładać indeksy na kolumny, które w często wykonywanych zapytaniach często występują w klauzuli WHERE lub GROUP BY; względem których często sortujemy; tworzą klucz obcy lub są często wykorzystywane w złączeniach; Warto nakładać indeksy na kolumny, które w często wykonywanych zapytaniach często występują w klauzuli WHERE lub GROUP BY; względem których często sortujemy; tworzą klucz obcy lub są często wykorzystywane w złączeniach; Kolejność kolumn w indeksie złożonym jest istotna z punktu widzenia wykorzystania indeksu do przyspieszenia wykonywania zapytań, np. indeks zdefiniowany poniżej CREATE INDEX lista_osob ON employee(first_name, last_name) nie będzie wykorzystany w zapytaniu SELECT first_name, last_name FROM employee ORDER BY last_name, first_name Zalecenia dotyczace stosowania indeksów Aliasy Indeks unikalny można tworzyć z opcją INCLUDE: CREATE UNIQUE INDEX COUNTRIES_PK ON COUNTRIES (ID) INCLUDE (NAME); Kolumna NAME jest włączona do indeksu, ale nie jako kolumna unikalna. Wpisy w indeksie są sortowane tylko ze względu na kolumnę CODE. W zapytaniach odwołujących się tylko do kolumn CODE i NAME wystarczy odczytać tylko dane z indeksu, co zwiększa wydajność takich zapytań. Uwaga. Indeksy zajmują przestrzeń na dysku. Ilość zajętej przestrzeni zależy od długości kolumn klucza indeksu i liczby poindeksowanych wierszy, która rośnie wraz z dodawaniem kolejnych wierszy do tabeli. Należy to brać pod uwagę podczas planowania rozmiaru bazy danych. Alias jest alternatywną nazwą tabeli lub widoku (lub innego aliasu). Aliasy tworzymy instrukcją CREATE ALIAS nazwa_aliasu FOR nazwa_obiektu; Obiektem może być tabela, widok lub inny alias. Nazwa aliasu nie może być taka sama, jak nazwa istniejącej w bazie tabeli, widoku lub aliasu. Aliasy są widoczne publicznie, żadne specjalne uprawnienia nie są wymagane aby korzystać z aliasu (ale oczywiście trzeba mieć odpowiednie uprawnienia do obiektu, na który alias wskazuje, aby mieć do niego dostęp). Zastosowanie aliasów: jeżeli zapytanie SQL odwołuje się do tabeli poprzez alias, a nie rzeczywistą nazwę, a zachodzi potrzeba odwołania się do innej tabeli, to wystarczy zmienić definicję aliasu tak, aby wskazywał na inną tabelę, natomiast nie ma potrzeby zmiany zapytania SQL.
Sekwencje Sekwencje generują unikalne liczby na poziomie całej bazy danych. Wygenerowane dane można wykorzystać jako wartości kluczy głównych. W odróżnieniu od kolumn identyfikujących, sekwencje nie są zależne od tabeli. Sekwencje Sekwencje generują unikalne liczby na poziomie całej bazy danych. Wygenerowane dane można wykorzystać jako wartości kluczy głównych. W odróżnieniu od kolumn identyfikujących, sekwencje nie są zależne od tabeli. Przykład użycia sekwencji: Niech tabela dzial będzie utworzona następująco: CREATE TABLE dzial (nr int, nazwa varchar(15)); Tworzymy sekwencję myseq (z wartością początkową 10, krokiem 1, nie cykliczną): CREATE SEQUENCE myseq START WITH 10 INCREMENT BY 1 NO CYCLE; Sekwencje Sekwencje generują unikalne liczby na poziomie całej bazy danych. Wygenerowane dane można wykorzystać jako wartości kluczy głównych. W odróżnieniu od kolumn identyfikujących, sekwencje nie są zależne od tabeli. Przykład użycia sekwencji: Niech tabela dzial będzie utworzona następująco: CREATE TABLE dzial (nr int, nazwa varchar(15)); Tworzymy sekwencję myseq (z wartością początkową 10, krokiem 1, nie cykliczną): CREATE SEQUENCE myseq START WITH 10 INCREMENT BY 1 NO CYCLE; Wstawienie danych pobranych z sekwencji do tabeli: INSERT INTO dzial VALUES (nextval for myseq, IT ); INSERT INTO dzial VALUES (nextval for myseq, HR ); INSERT INTO dzial VALUES (nextval for myseq, PR ); Sekwencje Sekwencje generują unikalne liczby na poziomie całej bazy danych. Wygenerowane dane można wykorzystać jako wartości kluczy głównych. W odróżnieniu od kolumn identyfikujących, sekwencje nie są zależne od tabeli. Przykład użycia sekwencji: Niech tabela dzial będzie utworzona następująco: CREATE TABLE dzial (nr int, nazwa varchar(15)); Tworzymy sekwencję myseq (z wartością początkową 10, krokiem 1, nie cykliczną): CREATE SEQUENCE myseq START WITH 10 INCREMENT BY 1 NO CYCLE; Wstawienie danych pobranych z sekwencji do tabeli: INSERT INTO dzial VALUES (nextval for myseq, IT ); INSERT INTO dzial VALUES (nextval for myseq, HR ); INSERT INTO dzial VALUES (nextval for myseq, PR ); Komenda PREVVAL zwraca aktualną wartości sekwencji, podczas gdy NEXTVAL dostarcza wartość następną.