Martin Gruber
SQL
Wprowadzenie
Systemy relacyjnych baz danych są obecnie najczęściej używanymi systemami baz danych. Rozwiązały one wiele problemów występujących wcześniej w bazach nierelacyj-nych. Nierelacyjne bazy danych wymagały od programistów i administratorów szczegółowej wiedzy na temat rozmieszczenia danych i struktury bazy. Utrudniało to bardzo rozbudowę i modyfikację aplikacji. Natomiast relacyjne bazy pozwalają na pracę z danymi na wyższym poziomie. Wszystkie operacje na danych są wykonywane za pomocą programu SZBD — systemu zarządzania bazą danych (database management system — DBMS). Odpowiada on na instrukcje wyrażone w języku wysokiego poziomu. Chociaż niektóre produkty mają własny język, za standard we wszystkich znaczących systemach uznano SQL. Zatem każdy, kto planuje korzystać z relacyjnych baz danych, powinien używać SQL-a.
Pierwsza część tej książki zawiera krótki opis SQL-a i relacyjnych baz danych. Umożliwi ci ona orientację i wgląd w zagadnienie. W pozostałych częściach znajdują się szczegółowe informacje, które będą dla ciebie bardzo przydatne.
Co nowego w standardzie SQL-a?
Od 1986 roku SQL jest oficjalnym standardem (zatwierdzonym przez Międzynarodowe Stowarzyszenie Normalizacyjne ISA i jego amerykański odpowiednik Amerykański Narodowy Instytut Normalizacji ANSI). Poprzedni oficjalny standard był ratyfikowany na wspólnym gruncie pomiędzy istniejącymi produktami, jednak końcowa postać zależała od twórców danej implementacji SQL-a. Pewnym problemem dla użytkowników i aplikacji jest obsługiwanie i łączenie różnych typów baz danych. Będzie to łatwiejsze, gdy do wszystkich baz danych można będzie się odwoływać w jednakowy sposób. W dodatku badania i doświadczenia zasugerowały wiele nowych rozwiązań, które mogły znaleźć się w standardzie języka i wielu użytkowników chciało je mieć zaimplementowane w swoich systemach. Doprowadziło to do powstania nowego standardu SQL-a 92.
SQL 92 wprowadza nowe elementy i uznaje za standard rozwiązania zaimplementowa-ne już w różnych systemach. Intencją ISO było, abyś mógł się uczyć SQL-a 92 jedynie z niewielką wiedzą o poszczególnych systemach i operować na danych bezpośrednio lub za pomocą aplikacji. W nowym standardzie możesz korzystać z baz danych we wszystkich systemach w jednakowy sposób i łączyć ich dane. Standard 92 jest bardziej złożony i lepszy od poprzedniego.
SQL 92 z niewielkimi wyjątkami, opisanymi w dodatku Niezgodność z SQL-em 89 i wychodzące z użycia elementy języka, opiera się na poprzednich standardach — SQL 86 i SQL 89. Oznacza to, że wszystkie elementy języka przedstawione w poprzednich standardach dotyczą także SQL-a 92. W książce tej wyraźnie wskazano, co jest częścią starego standardu, a co należy do SQL-a 92. Możesz zatem używać tej książki bez względu na to. z jakim standardem jest zgodny twój system. Jeśli twój system nie jest zgodny z SQL-em 92, jest bardzo prawdopodobne, że w następnej jego wersji zostanie wprowadzony nowy SQL, więc możesz się już zacząć uczyć SQL-a 92. Oczywiście możesz zasięgnąć informacji o planach wprowadzenia nowego SQL-a do twojego programu w fftriś', która go stworzyła.
Podczas pracy nad tą książką wyłoniło się kilka niezgodności w standardzie ISO SQL-a 92. Zrobiliśmy wszystko, co było w naszej mocy, aby wyrazić intencje ISO. Książka odzwierciedla stan standardu w chwili jej pisania (lipiec 1993).
Dla kogo przeznaczona jest ta książka?
Książka ta przedstawia raczej standard języka, niż jakiś określony produkt i dlatego też może okazać się nieoceniona dla każdego, kto używa systemów baz danych zgodnych ze starym lub nowym standardem.
Z SQL-a korzystają głównie programiści, administratorzy baz danych, projektanci, analitycy systemów i końcowi użytkownicy. Osoby należące do tej ostatniej grupy będą być może chciały używać SQL-a interaktywnie w celu przechowywania i wyszukiwania informacji w bazie. Można to także uczynić za pomocą aplikacji, co będzie łatwiejsze dla użytkowników nie znających SQL-a.
Organizacja książki
Książka składa się z trzech części:
Pierwsza część wyjaśnia zasady relacyjnych baz danych i języka SQL wraz z nowymi elementami standardu 92. Nawet jeśli znasz już SQL, dobrze będzie, gdy przeczytasz rozdział: SQL dzisiaj, zawierający podsumowanie nowości standardu 92.
Część druga książki zawiera opis instrukcji. Dla każdej instrukcji SQL-a (polecenia SQL-a zarówno w standardzie, jak i w literaturze nazywa się instrukcjami) znajdziesz tam składnię, opis użycia (w standardzie 92), a także uwagi dotyczące różnic i zgodności z poprzednim standardem. Znajdują się tam również odsyłacze do powiązanych tematycznie terminów oraz w razie potrzeby przykłady użycia danej instrukcji.
Część trzecia opisuje wspólne elementy języka. Materiał tu przedstawiony dotyczy kilku instrukcji i jest za bardzo szczegółowy, aby go umieścić w opisach odpowiednich instrukcji.
Dodatki zawierają opis zanurzonego i dynamicznego SQL-a, język modułowy, słowa kluczowe i konwencje, niezgodności pomiędzy SQL-em 89 i 92 oraz kody błędów. W dodatku Słowniczek pojęć umieszczono wyjaśnienie podstawowych terminów dotyczących baz, danych.
Na wewnętrznych okładkach znajdują się elementy języka opisane w książce pogrupowane tematycznie. Ułatwi to znalezienie instrukcji nieznanych ci z nazwy. Znajdują się tam także odpowiedniki typów danych SQL-a w językach bazowych.
Zasady SQL-a i relacyjnych baz danych
SQL (Structured Query Language — strukturalny język zapytań) został opracowany przez firmę IBM w latach siedemdziesiątych. SQL jest standardem w systemach zarządzania bazami danych (SZBD), takich jak: Oracle, INGRES, Informix, Sybase, SQLbase, Microsoft SQL server, Paradox, Access, Approach, w produktach IBM-a: DB2 i SQL/DS i innych. Poza tym niektóre programy, jak na przykład: dBASE lub Interbase, oprócz swoich własnych interfejsów mają także (lub właśnie wprowadzają) SQL. Jak ostatnio obliczono, SQL jest zaimplementowany w ponad 140 produktach. Można więc śmiało stwierdzić, że jeśli w przyszłości masz zamiar używać relacyjnych baz danych, będziesz korzystać z SQL-a.
Typowy system relacyjnych baz danych składa się nie tylko z SZBD. SZBD jest często nazywany „tyłem bazy danych" (back end) lub „mechanizmem" (engine). W odpowiedzi na instrukcje SQL-a wyszukuje on lub modyfikuje dane, a także odpowiada za ich przechowywanie. W środowisku klient-serwer SZBD jest zwykle zainstalowany na serwerze. Systemy relacyjnych baz mają także wbudowane narzędzia nazywane „frontem bazy danych" (front end). Ułatwiają one komunikację z tyłem bazy oraz zawierają różne udogodnienia w wyszukiwaniu danych. Możesz się natknąć na następujące narzędzia: formularze, generatory raportów, języki czwartej generacji (4GL), graficzne języki zapytań, generatory interfejsu użytkownika, oprogramowanie multimedialnych prezentacji, systemy hipertekstu, systemy CAD/CAM, arkusze kalkulacyjne i stare dobre bezpośrednie interfejsy. Wszystkie te wyżej wymienione narzędzia wymagają SZBD do wykonania różnych akcji. SZBD jest odpowiedzialny za przechowywanie, organizację i wyszukiwanie danych. Odpowiada także za ich integralność i ochronę. Podczas współbieżnej pracy kilku użytkowników na danych nie dopuszcza, aby sobie wzajemnie przeszkadzali. W tej książce skupimy się bardziej na współpracy tyłu i frontu bazy niż na samych narzędziach lub szczegółach implementacji „mechanizmu" bazy danych.
Postać SQL-a
SQL jest „podjęzykiem danych", ponieważ służy on tylko do komunikowania się z bazą. Za pomocą samego SQL-a nie można napisać kompletnego programu. SQL jest używany na trzy sposoby:
1. Interaktywny lub samodzielny SQL używany jest do wprowadzania albo wyszukiwania informacji do/z bazy danych. Na przykład użytkownik może poprosić o listę aktywnych kont w bieżącym miesiącu. Wynik może być wysłany na ekran, skierowany do pliku albo wydrukowany.
Statyczny SQL jest to stały kod SQL-a napisany przed wykonaniem programu. Są dwie wersje statycznego SQL-a. W zanurzonym SQL-u kod SQL-a znajduje się w źródłowym programie innego języka. Większość tych aplikacji jest napisana w językach C lub COBOL, natomiast odwoływania do bazy danych są w SQL-u. Inna wersja statycznego SQL-a to język modułowy. W tym przypadku moduły SQL-a są łączone z modułami kodu innych języków. W standardzie 86 zanurzony SQL nie został oficjalnie uznany za cześć języka, chociaż opisano go w dodatku. Zanurzony SQL okazał się bardzo popularny wśród twórców oprogramowania i dlatego też obecnie obydwie wersje języka są jednakowo traktowane przez standard. Więcej informacji na ten temat znajdziesz w dodatkach Specyfikacja zanurzonego SQL-a i Specyfikacja języka modułowego.
3. Dynamiczny SQL jest to kod SQL-a generowany przez aplikację w czasie jej wykonywania się. Jest używany zamiast statycznego SQL-a, gdy potrzebny kod nie może być określony podczas pisania programu, ponieważ zależy on od wyboru użytkownika. Ten rodzaj kodu SQL-a jest często generowany w odpowiedzi na działania użytkownika za pomocą takich narzędzi jak np. graficzne języki zapytań. W dodatku Specyfikacja dynamicznego SQL-a znajdziesz więcej informacji na ten temat.
Te trzy postacie SQL-a mają różne wymagania, co jest odzwierciedlone w ich konstrukcjach językowych. W odpowiednich sytuacjach samodzielny SQL jest uzupełniany dynamicznym lub statycznym. Książka ta przedstawia wszystkie rodzaje SQL-a , zwracając uwagę na instrukcje odnoszące się do poszczególnych form języka. Znaczna jednak część języka dotyczy wszystkich trzech form.
Wprowadzenie do relacyjnych baz danych
Relacyjne bazy danych i standard SQL-a oparte są na kilku prostych zasadach:
1. Wszystkie wartości danych są typów prostych. W przeciwieństwie do innych znanych ci języków programowania, w SQL-u nie ma tablic, wskaźników, wektorów i innych złożonych typów .
2. Wszystkie dane w relacyjnej bazie są zapisane w dwuwymiarowej tablicy (table) relacji (relation). Tablica składa się z wierszy (rows) — zwanych inaczej krotkami oraz z kolumn (columnś) — zwanych też atrybutami. Tablica może nie mieć wierszy, ale musi zawierać przynajmniej jedną kolumnę. Wszystkie wiersze w tablicy mają taką samą kolejność kolumn, w których zazwyczaj znajdują się różne wartości. Rysunek 1.1. przedstawia prostą tablicę.
3. Po wprowadzeniu danych do bazy możesz porównać wartości z różnych kolumn, także znajdujących się w różnych tablicach oraz łączyć odpowiadające sobie wiersze. Umożliwia ci to wykonywanie skomplikowanych operacji na danych znajdujących się w całej bazie.
4. Operacje są definiowane logicznie, a nie poprzez pozycje wiersza w tablicy. Na przykład pytasz się o wiersze, dla których x=3, a nie o wiersz pierwszy, trzeci, piąty. Wiersze w relacyjnej bazie danych są dowolnie uporządkowane. Porządek, w jakim się pojawiają, niekoniecznie odzwierciedla kolejność ich wprowadzenia do bazy, bądź przechowywania na dysku.
5. Ponieważ nie można identyfikować wierszy za pomocą ich pozycji, rozróżnia się je poprzez jedną lub więcej unikalnych kolumn, nazywanych kluczem głównym (primary key). Na rysunku 1.1. rolę klucza głównego pełni pierwsza kolumna.
Klienci
NR IDENT NAZWISKO IMIĘ MIASTO
1809 Kowalski Jan Warszawa
1996 Nowak Marcin Wrocław
1777 Piotrowski Adam Kielce
Rysunek 1.1. Prosta tablica relacyjnej bazy danych
Teraz zobacz, co oznaczają te zasady w praktyce. Jedną z mocnych stron relacyjnych baz jest to, że operujesz na danych jak na informacjach i nie przejmujesz się szczegółami ich fizycznej reprezentacji w bazie. Konieczność znajomości struktury fizycznej bazy sprawiło, że stare systemy sieciowe i hierarchiczne stały się niewygodne i trudne do zarządzania. Jeśli wcześniej miałeś do czynienia z tymi systemami, będziesz musiał trochę zmienić swój sposób myślenia.
Uwaga
Terminy: rekord — oznaczający wiersz i pole — oznaczające kolumnę są nadal czasami używane. Pochodzą one ze starszych systemów i w rzeczywistości odnoszą się do sposobu organizacji informacji na dysku. Chociaż wiele systemów relacyjnych baz używa nazw rekord i pole, korzystanie z tych terminów nie jest zalecane.
Projektowanie bazy danych
Jedną z zalet relacyjnych baz danych jest ich prostota. Wszystkie dane i wyniki wyjściowe są w postaci prostych tablic. Czasem trudno zamodelować złożoną rzeczywistość za pomocą prostych tablic, lecz na świecie trudno o doskonałość. Czy jest możliwe, aby ta sama kolumna danego wiersza zawierała wiele wartości? Przypuśćmy, że musimy dodać do naszej tablicy kolumnę zawierającą numer telefonu. Większość ludzi ma przynajmniej dwa numery telefoniczne: domowy i do pracy; mogą też jednak posiadać faks, pager, e-mail itp. Jedną z przesłanek relacyjnego modelu są atomowe wartości kolumn — jedna wartość w jednej kolumnie. Jeśli zapiszesz do kolumny więcej niż jedną wartość, będą one interpretowane przez SZBD jako jedna.
Rozwiązaniem tego problemu jest stworzenie drugiej tablicy (o nazwie, powiedzmy, Klienci_Telefony). Tablica ta będzie zawierać jedną kolumnę z numerem telefonu, drugą z opisem numeru (dom, faks, e-mail itp.) i kolumnę informującą, kiedy należy dzwonić, aby zastać daną osobę. Oczywiście chcemy wiedzieć, do której osoby z pierwszej tablicy odnosi się dany numer telefonu. Jednym słowem musimy w jakiś sposób powiązać ze sobą dwie tablice.
Możemy to zrobić poprzez dołączenie klucza głównego — unikalnej kolumny tablicy Klienci do tablicy Klienci_Telefony. Każdy klient ma swój unikalny numer, po którym go rozpoznajemy. Moglibyśmy także dołączyć nazwisko do tablicy Klienci_Telefony, ale spowodowałoby to redundancję i zajęło więcej miejsca na dysku. Za pomocą numeru łączącego dwie tablice możemy zawsze określić nazwisko. Kolumna NR_IDENT w tablicy Klienci_Telefony jest kluczem obcym (foreign key) i mówimy, że odnosi się do klucza głównego w tablicy Klienci (w tej książce klucze, do których odnoszą się klucze obce, nazywamy kluczami-rodzicami —parent key). Rysunek 1.2. przedstawia ten związek. System jest integralny, jeśli wszystkie wartości kluczy obcych w Klien-ci_Telefony znajdują się faktycznie w tablicy Klienci. Jeśli się okaże, że ich tam nie ma, to będziemy mieć kłopot. Będzie to oznaczać, że baza zawiera telefony nie istniejących, bądź nie dających się zidentyfikować klientów.
Klienci_Telefony
NR_IDENT TELEFON TYP DOSTEPNY
1809 415 555 8956 dom po 18tej
1809 510 555 6220 praca 9-17
1996 212 555 0199 praca 10-19
1996 212 555 7878 pager zawsze
1777 503 555 2279 fax zawsze
1777 503 555 9188 dom po 19tej
Rysunek 1.2. Tablica Klienci_Telefony
W tablicy Klienci_Telefony także będzie potrzebny główny klucz — każda tablica powinna go zawierać. Nie możemy jako klucza użyć NR_IDENT, ponieważ nie jest on unikalny (powtarza się dla każdego numeru tego samego klienta). A co z numerem telefonu, czy może być kluczem? Jest to lepsze rozwiązanie, ale może się zdarzyć, że będziemy mieć kilku klientów w jednym domu lub biurze. W tym przypadku chcielibyśmy prawdopodobnie przechowywać ich numery oddzielnie.
Klucz główny lub obcy nie musi być pojedynczą kolumną. Możemy go złożyć z dwóch kolumn: NR_IDENT i TELEFON. Takie złożenie powinno być zawsze unikalne, ponieważ jeśli drugi raz wpiszemy ten sam numer telefonu dla tej samej osoby, powtórzymy informację znajdującą się już w bazi...
LucjaR