#23
Część I
Projektowanie i tworzenie bazy danych

#25
Rozdział 1.
SQL

Strukturalny Język Zapytań (ang. Structured Query Language), nazywany zwykle językiem SQL, jest zbiorem komend używanych do wprowadzania, modyfikowania i przeglądania zawartości relacyjnych baz danych.

Model relacyjnej bazy danych

Większość obecnych dzisiaj na rynku baz danych powstało w oparciu o model relacyjny. Podstawowa właściwość tego modelu polega na tym, że informacje przechowywane są w tabelach, a każda tabela składa się z wierszy i kolumn. Wiersz tabeli jest pojedynczym rekordem składającym się z kolumn. Element znajdujący się na przecięciu kolumny i wiersza to pole. Pole zawiera najmniejszą, niepodzielną wartość, to znaczy taki kawałek informacji, który nie może być dalej dzielony ze względu na spójność logiczną. Przedstawmy to na przykładzie bazy danych zawierającej informacje o pracownikach firmy. W takiej bazie można by przechowywać imiona i nazwiska pracowników w jednym polu, oddzielając je przecinkami lub innymi separatorami. Jednak tego rodzaju organizacja danych utrudnia dostęp do niektórych informacji. Na przykład, chcąc wyszukać nazwisko pracownika, musimy je specjalnie wydzielić z pola zawierającego również imiona. Jak widać, pojawiający się problem wynika z przechowywania w jednym polu złożonej informacji. Rozdzielenie imion i nazwisk do oddzielnych pól eliminuje powstałe kłopoty i daje możliwość dowolnego przeszukiwania bazy danych. Zasygnalizowany tu problem będzie szczegółowo przedstawiony w rozdziale 2. "Projektowanie bazy danych" przy okazji omawiania normalizacji.

===============
Uwaga
Relacyjny model bazy danych wymaga, aby zgromadzone w bazie danych informacje były prezentowane w postaci tabel, choć fizycznie mogą być przechowywane w sposób dowolny. Tabela jest pojęciem abstrakcyjnym, które stanowi podstawę idei relacyjnych baz danych, rozdzielających warstwę prezentacji i zarządzania danymi od sposobu ich przechowywania w systemie komputerowym. Na przykład dane zgromadzone w bazie danych Oracle są prezentowane w postaci tabel, choć tak naprawdę są zapamiętane w jednym pliku binarnym, tak aby można było szybko je modyfikować i wyszukiwać.
===============
#26
Teoria relacyjnych baz danych została opisana przez matematyka E. F. Codd'a w pracy "Relacyjny model danych dla dużych banków danych". Nie używa się tam pojęć tabeli, kolumny i wiersza, lecz tabele określa jako relacje, kolumny jako atrybuty i wiersze jako krotki. W tej książce będziemy korzystać z pojęć tabeli, kolumny i wiersza, ponieważ język SQL używa tej właśnie terminologii.
================
Uwaga
Teoria dr Codd'a, dotycząca zarządzania bazami danych, została opracowana w latach 1969-1970. W 1968 roku dr Codd zastosował matematyczne teorie do zarządzania bazami danych i tak powstał relacyjny model baz danych. Choć żadna komercyjna implementacja relacyjnej bazy danych nie jest w pełni zgodna z teorią Codd'a, to jednak stanowi ona podstawę teoretyczną dla wielu współczesnych systemów relacyjnych baz danych.
===============
Tabela 1.1 przedstawia przykład tabeli (relacji). Jak widać każda kolumna zawiera jeden typ danych, a każdy rekord (wiersz) składa się z danych przechowywanych w poszczególnych kolumnach.

Tabela 1.1. Przykładowa tabela
id Title Studio budget
1 Minerał House Giant 20
2 Prince Kong MPM 3,25
3 The Code Warrior MPM 10,3
4 Bili Durham Delighted Artists 10,1

W tabeli 1.1 każdy wiersz (rekord) składa się z czterech kolumn id, title, studio, budget. Każde pole tabeli 1.1, zgodnie z ideą niepodzielnych kawałków informacji przechowywanych w poszczególnych polach, zawiera jedną nie dającą się już podzielić informację. Relacyjne bazy danych składają się z wielu tabel podobnych do tabeli 1.1 połączonych ze sobą relacjami. Jeżeli w bazie danych znajduje się inna tabela zawierająca dane dotyczące studia, można takie informację powiązać tworząc odnośnik od kolumny studio z tabeli 1.1 do odpowiedniej kolumny w innej tabeli.
Podstawową korzyścią wynikającą z wykorzystania relacji między tabelami jest unikanie powielania danych w kilku miejscach bazy danych. Na przykład, chcąc przechowywać informację o mieście, gdzie wybrane studio jest zlokalizowane, możemy utworzyć w tabeli dodatkową kolumnę studio_city. Ta metoda prowadzi do powielanie danych w przypadku, gdy do tablicy wprowadzony zostaje drugi lub następny film z tego samego studia (filmy 2. i 3. miałyby taką samą wartość w polu studio_city, ponieważ są wyprodukowane przez to samo studio). Lepszym rozwiązaniem jest rozdzielenie informacji do dwóch tabel i łączenie ich w razie potrzeby.
Pierwsza tabela pozostałaby bez zmian, natomiast druga składałaby się z dwóch kolumn: studio, studio_city.
#27
Projektowanie bazy danych, tak aby informacje niepotrzebnie nie były powielane, nazywa się normalizacją. Normalizacja zapobiega powstawaniu niespójności w bazie danych, minimalizując ilość miejsc, w których przechowywane są te same dane.
Zasady normalizacji są przedstawione w rozdziale 2. "Projektowanie bazy danych".
Model relacyjnych baz danych opisuje kilka podstawowych zasad. Zasady te dotyczą struktury danych, integralności danych oraz przetwarzania danych.
=============
Uwaga
W tej części książki nie zagłębiamy się w szczegóły relacyjnego modelu baz danych. Po szczegółowe informacje odsyłam do pracy "Wprowadzenie do systemów baz danych" C. J. Date.
==============

Zasady dotyczące struktury danych

W modelu relacyjnych baz danych informacja dostępna jest dla użytkownika poprzez tabele. Jest to model abstrakcyjny, nie związany z fizycznym sposobem przechowywania danych, umożliwiający oddzielenie danych od aplikacji i platformy sprzętowej, zawsze obsługiwany w ten sam sposób.
W przypadku pisania programów współpracujących z relacyjną bazą danych unikamy konieczności znajomości struktury plików danych, do których chcemy mieć dostęp. Na przykład, gdy tworzymy bazę danych przechowującą informacje w zwykłym pliku nie należącym do relacyjnej bazy danych, jesteśmy zmuszeni osobiście panować nad całą strukturą danych (tworzyć separatory między polami albo ustalić podział na pola przez ilość znaków dla każdego pola - 40 pierwszych znaków dla pola imię, następne 60 znaków dla pola adres, ostatnie 25 dla pola zawód). Relacyjna baza danych ukrywa przed użytkownikiem tę warstwę zarządzania danymi.
Kolejna zasada wymaga, żeby w bazie danych przechowywać tylko konkretne wartości. Innymi słowy, nie posługujemy się wskaźnikami do danych.

Zasady dotyczące przetwarzania danych

Jest wiele operacji, które mogą być przeprowadzane w relacyjnej bazie danych. Tak jak operatory matematyczne służą do przeprowadzania działań matematycznych, tak operatory relacyjne służą do dokonywania rozmaitych operacji na tabelach.
Zapytania służą do wykonania jednej lub więcej operacji relacyjnych na tabeli lub grupie tabel. SQL jest językiem, który umożliwia programistom stosowanie operatorów ...., relacyjnych w bazie danych. Tak jak liczby są wynikiem wykonywania działań matematycznych, tak tabele są wynikiem zapytań SQL. Nie ma znaczenia sposób ostatecznej prezentacji wyszukanych danych, ponieważ zawsze są one dostępne w formie tabeli. Zapytania, które zwracają pojedynczy rekord, prezentują to w postaci tabeli o jednym wierszu a zapytania, które zwracają pojedynczą wartość, prezentują ją w tabeli o jednym wierszu i jednej kolumnie.
#28
Wyszukane w wyniku zapytania dane niekoniecznie muszą być przedstawione w ostatecznej formie jako tabela; mogą pojawić się jako wartość na stronie WWW lub w określonych miejscach wypełnić formularz.
Dzięki temu, że w relacyjnej bazie danych wyniki wszystkich zapytań są zwracane w formie tabel, możliwe jest zagnieżdżanie zapytań. Język SQL wykorzystuje tabele jako źródła danych i -jak wiadomo - wynik zwraca w postaci kolejnej tabeli. Na przykład predykat IN jest używany do porównania wartości z zadaną grupą wartości, jak w przykładzie:

SELECT *
FROM Movies
WHERE studio IN ('MPM', 'Giant')

Wartości z kolumny studio są porównywane z dwoma wartościami MPM i Giant. Predykat IN wymaga podania listy wartości lub, stosując inną terminologię, tabeli zjedną kolumną i pewną liczbą wierszy. Zatem lista wartości może być zastąpiona przez zapytanie, jak pokazuje listing 1.1.
-----------------
Listing 1.1. Przykład zapytania zagnieżdżonego

SELECT *
FROM Movies
WHERE studio IN (SELECT Name FROM Studios)
-----------------

Tabela będąca wynikiem wewnętrznego wyrażenia SELECT dostarcza danych, z którymi wartości studio są porównywane. Zapytania zagnieżdżone omówiono w rozdziale 9.

Zasady dotyczące integralności danych

Zasady integralności danych wymagają, aby każdy wiersz tabeli zawierał wartość lub grupę wartości, które określałyby go w sposób jednoznaczny (unikalny). Te wybrane wartości nazywane są kluczem głównym (ang. primary key). W tablicy 1.1 klucz główny znajduje się w kolumnie id.

==================
Rada
Większość baz danych nie wymusza ściśle zasad integralności danych. Pomimo że zasady integralności wymagają, aby każdy wiersz bazy danych zawierał unikalną wartość klucza głównego, większość baz danych pozwala naruszyć tę zasadę, choć istnieją też możliwości bezwarunkowego przestrzegania reguł integralności.
===================

Kolumna lub grupa kolumn z innej tablicy, która odpowiada kluczowi głównemu tablicy pierwszej, jest nazywana kluczem obcym (ang. foreign key). Na przykład rozważmy relację pomiędzy tablicami studios oraz Movies. W tablicy studios kluczem głównym jest kolumna name. Kolumna studio w tablicy Movies jest kluczem obcym, który odpowiada kolumnie name w tablicy studios. Każda wartość klucza obcego musi mieć swój odpowiednik w tablicy, do której się odnosi. Spełnienie tych warunków zapewnia bazie danych integralność.
#29
Na przykład można określić dodatkową regułę, która wymusza, aby wszystkie wartości w tablicy Pracownicy w kolumnie pensja zawierały się w przedziale pomiędzy 10 000 a 90 000. Te dodatkowe reguły można wprowadzić używając ograniczenia CHECK, które jest omówione w dalszej części książki w rozdziale 3.
Dodatkowe reguły integralności danych mogą być nałożone na wybrane kolumny.
Zasady integralności są wymagane przez każdy system, który jest zbudowany w oparciu o relacyjny model baz danych. Jednak większość baz danych posiada opcję niewymuszania integralności danych, jak również nie wymaga określania kluczy głównych i obcych w tworzonych tabelach.

Język SQL

Model relacyjnej bazy danych wymaga, aby wszelką komunikację z bazą danych zapewniał jeden język. Język ten powinien umożliwiać przetwarzanie, definiowanie oraz administrowanie bazą danych. Z tego względu w większości przypadków wszystkie dane konfiguracyjne i niezbędne do administracji systemem są przechowywane w tabelach bazy danych.
W większości systemów relacyjnych baz danych język SQL w pełni spełnia wymogi modelu relacyjnych baz danych. Pełen standard języka SQL jest opisany na ponad 600 stronach, jednak żaden komercyjny system nie spełnia w całości wszystkich wymagań standardu. W tej książce opisano te elementy języka SQL, które są najczęściej wprowadzone w rozwiązaniach komercyjnych. Jest wiele powodów dla których pełen standard języka SQL nie został zaimplementowany, choć najważniejszym wydaje się fakt, że nowe elementy języka są wprowadzane zbyt pośpiesznie, aby można je było zastosować w produktach komercyjnych.
Język SQL został przygotowany, tak aby spełnić trzy podstawowe zadania - przetwarzanie danych, definiowanie danych i administracja bazą danych.

Przetwarzanie danych

Do przetwarzania danych wykorzystujemy dwie kategorie komend: komendy do wyszukiwania danych oraz komendy do modyfikacji danych. Instrukcja SELECT służy do wyszukiwania danych. Dzięki bogatym możliwościom języka SQL można formułować bardzo szczegółowe kryteria wyszukiwania danych w jednym zapytaniu. Bogactwo tych możliwości niech potwierdzi fakt, że aż pięć rozdziałów w drugiej części książki jest poświęconych wykorzystaniu samej instrukcji SELECT.

===============
Uwaga
Wyrażenia SQL wykorzystujące instrukcje SELECT są nazywane zapytaniami.
===============
#30
--------------------
Listing 1.2. Instrukcja SELECT

SELECT *
FROM Studios

STUDIO_ID STUDIO_NAME STUDIO_CITY ST
--------- ----------- ----------- --
1 Giant Los Angeles CA
2 MPM Burbank CA
3 Delighted Artist Austin TX
4 FKG Apex NC
5 Metaversal Los Angeles LA
----------------------

Instrukcje wykorzystywane do manipulacji danymi to UPDATE, INSERT oraz DELETE. Instrukcja UPDATE jest wykorzystywana do wprowadzania zmian w rekordach, instrukcja INSERT umożliwia dodawanie nowych rekordów do tabel, a instrukcja DELETE usuwa rekordy z tabeli.
Listing 1 .3 przedstawia przykłady zastosowania tych trzech instrukcji.

--------------------
Listing 1.3. Instrukcje przetwarzające dane

UPDATE Studios
SET studio_city = 'Huston'
WHERE st='TX'

1 row updated

DELETE FROM Studios
WHERE studio_name = 'Giant'

1 row deleted

INSERT INTO Studios
(studio_id, studio_name, studio_city, st)
VALUES
(5, 'Big Pictures', 'Culver City', 'CA')

1 row created
-----------------------

Definiowanie danych

Instrukcje definiowania danych pozwalają na tworzenie i modyfikację struktury bazy danych oraz zasobów używanych przez bazę. Wśród instrukcji należących do tej grupy najważniejsza jest instrukcja CREATE. Umożliwia ona utworzenie bazy danych, perspektywy lub nowej tabeli.
Listing 1.4 przedstawia wykorzystanie instrukcji CREATE do utworzenia tabeli.

----------------
Listing 1.4. Instrukcja CREATE - tworzenie nowej tabeli

CREATE TABLE przykład
(nazwa VARCHAR2(60),
stopień CHAR(10),
nr_seryjny NUMBER)

Table created
--------------
#31
W niektórych przypadkach po stworzeniu elementu bazy danych, na przykład tabeli, zachodzi potrzeba wprowadzenia zmian. Takie możliwości daje instrukcja ALTER, która umożliwia zmianę definicji tabeli. W naszym przykładzie można zmienić typ danych kolumny nr_seryjny z typu numerycznego na znakowy. Pokazuje to listing 1.5.

-----------------
Listing 1.5. Przykład użycia instrukcji ALTER

ALTER TABLE przykład
MODIFY nr_seryjny CHAR(10)

Table altered
-----------------
===================
Rada
Instrukcja ALTER nie umożliwia jednak zmian typów danych w sposób całkowicie dowolny. Zwykle, aby taka operacja się powiodła, musi być zapewniona zgodność istniejących danych z nowym typem danych lub modyfikowana kolumna musi być pusta.
===================

Zarządzanie bazą danych

Komendy związane z administracją bazą danych służą do zakładania kont użytkowników, przydzielania lub usuwania przywilejów dla użytkowników oraz do wykonywania innych zadań administracyjnych.
W większości przypadków informacje dotyczące konfiguracji bazy danych są przechowywane w odpowiednich tabelach wewnętrznych. Dostęp do tych tabel jest możliwy tylko przez konto administratora. W tym wypadku, po zalogowaniu do bazy przez konto administratora, w celu konfiguracji systemu można używać wszystkich standardowych komend do przetwarzania danych.

================
Uwaga
Większość systemów baz danych dostarcza specjalnych narzędzi do konfiguracji bazy danych. W bazach danych, w których informacje o konfiguracji i parametrach systemu nie są przechowywane w wewnętrznych tabelach, konieczne jest użycie specjalnych narzędzi w celu zmiany konfiguracji.
===============

Standardy języka SQL

Język SQL posiada wiele niewątpliwych zalet, jak na przykład łatwość użytkowania. Jednak największa korzyść, jaką oferuje swoim użytkownikom, to bogaty wybór wśród produktów komercyjnych. SQL jest standardowym językiem do komunikacji z relacyjną bazą danych i chociaż wersje języka mogą się nieznacznie różnić pomiędzy produktami różnych dostawców, podstawowe elementy języka pozostają niezmienne, niezależnie od wykorzystywanej konkretnej bazy danych.
#32
Standard języka SQL jest sprawdzany i zatwierdzany przez międzynarodową organizację International Standards Organization (ISO). W Stanach Zjednoczonych zatwierdzenia dokonuje National Institute of Standards and Testing (NIST).
Obecny standard języka to SQL-92, który został zatwierdzony w 1992 roku. Niestety, jak na razie żaden komercyjny system nie jest w pełni zgodny z tym standardem. Wiele z nich wspiera większość cech nowego standardu i posiada dodatkowo firmowe rozszerzenia charakterystyczne dla konkretnego dostawcy.
W książce nie został przedstawiony oficjalny, pełny standard języka, a raczej te elementy, które są stosowane w komercyjnych systemach, zwłaszcza że niektóre elementy standardu nie zostały dotychczas zaimplementowane w żadnym produkcie. Poprzedni standard języka SQL - SQL-89 znalazł swoje pełne implementacje w wielu komercyjnych produktach.

Składnia języka SQL

Język SQL, jak każdy inny język, opisują pewne reguły gramatyczne. Zanim pokażemy konkretne komendy języka, omówione zostaną reguły podstawowe. W języku SQL, w odróżnienie od języków proceduralnych jak C lub Perl, nie pisze się programów, lecz wysyła pojedyncze instrukcje do bazy danych. Te instrukcje są interpretowane przez bazę danych, a w wyniku wykonania instrukcji zwracany jest wynik i pobierana jest kolejna instrukcja do wykonania.
Inne podstawowe zasady języka SQL to: nierozróżnianie wielkich i małych liter, pomijanie "białych" znaków, możliwość zagnieżdżania instrukcji. Ważne jest także zrozumienie zasad używania apostrofów i nawiasów.

Nierozróżnianie wielkich i małych liter

W języku SQL nie ma znaczenia czy instrukcje są pisane wielkimi, czy małymi literami. Poniższe przykłady pokazują instrukcję SQL zapisaną w różnych konwencjach:

select *
from table

lub

SELECT *
FROM TABLE

lub

Select *
FROM table

Z formalnego punktu widzenia są one identyczne. Można pisać instrukcje SQL formatując je zgodnie z własną konwencją. Należy jednak pamiętać, że niektóre bazy danych umożliwiają zadeklarowanie, czy system rozróżnia wielkość liter.
#33
W takim wypadku, choć dalej nie jest istotny zapis słów kluczowych, dla innych elementów instrukcji wielkość liter może mieć znaczenie. Na listingu 1 .6 słowa kluczowe pojawiają się jako pogrubione dla odróżnienia ich od nazw elementów danych.
---------------------
Listing 1.6. Zapytanie z wyróżnionymi słowami kluczowymi

SELECT imię_osoby, Imię_osoby
FROM Ludzie
WHERE Województwo = 'śląskie'
-----------------

Jeżeli w bazie danych zostało włączone rozróżnianie wielkości liter, to w zapytaniach imię_osoby oraz imię_Osoby wskazują dwa różne pola tabeli, podczas gdy domyślnie jest to odwołanie do tej samej kolumny tabeli. Niektóre programy narzędziowe do pracy z systemami baz danych wymagają, aby baza danych rozróżniała nazwy elementów danych wprowadzane wielkimi lub małymi literami.

==============
Rada
W tej książce stosuję konwencję używania wielkich i małych liter zaproponowaną przez Joe Celko, eksperta od języka SQL. Słowa kluczowe są pisane wielkimi literami, nazwy tabel rozpoczynają się od wielkich liter, a nazwy kolumn są pisane małymi literami.
===============

"Białe" znaki

Inna właściwość języka SQL polega na pomijaniu "białych" znaków: nadmiarowych spacji, tabulatorów, znaków końca linii. Jeśli tylko niezależne elementy zapytania są od siebie oddzielone, będą prawidłowo przekazane do bazy danych. Nie ma wymogów, aby elementy jednej instrukcji znajdowały się w jednej linii. Przy pomocy tabulatora możesz wyróżniać początek kolejnych sekcji albo zaczynać kolejne wyrażenia od nowego wiersza.
Poniżej przedstawiono tę samą instrukcję zapisaną w różnych formatach:

SELECT * FROM Table

SELECT *
FROM Table

SELECT
*
FROM
Table

Dla języka SQL nie ma znaczenia, jak graficznie rozmieszczona jest instrukcja, jeśli tylko pomiędzy elementami instrukcji znajdują się odstępy. Oczywiście, instrukcja zapisana w następujący sposób nie będzie działać prawidłowo:

SELECT*FROMTable

Przyjąłem zasadę zapisu każdej części instrukcji SQL w osobnej linii. Z tego względu instrukcja składająca się z kilku części wygląda następująco:

SELECT *
FROM Table
WHERE kolumna_1 = ' wartość'
ORDER BY kolumna1
#34
Zagnieżdżanie

Inna cenna właściwość języka SQL polega na tym, że umożliwia on zagnieżdżanie zapytań. Oznacza to, że jedno zapytanie może być wstawione do innego zapytania, a wynik zapytania może być wykorzystany jako argument funkcji lub innego zapytania. Zagnieżdżanie jest bardzo istotną własnością języka SQL, dającą możliwości tworzenia zapytań realizujących skomplikowane zadania.
Istnieją dwa typy elementów, które mogą być zagnieżdżane wewnątrz zapytania SQL: inne zapytanie lub wywołanie funkcji. W przypadku osadzenia w zapytaniu drugiego zapytania mówimy o podzapytaniu.
Listing 1.1 zawiera przykład podzapytania. Instrukcja SELECT jest zagnieżdżona wewnątrz wyrażenia IN, należącego do zewnętrznego wyrażenia SELECT. Drugi przypadek dotyczy zagnieżdżania funkcji. Wtedy wewnątrz wywołania jednej funkcji znajduje się wywołanie drugiej i obie funkcje wykonują operacje na tym samym wyrażeniu. Listing 1.7 pokazuje przykładowe użycie funkcji zagnieżdżonych. Zapytanie usuwa spacje z prawej strony wyrażenia oraz przekształca w zapis wielkimi literami.
----------------------
Listing 1.7. Zagnieżdżanie wywołań funkcji w "wyrażeniu SELECT"

SELECT RTRIM(UPPER('Łańcuch przykładowy '))
FROM Dual
RTRIM(UPPER( 'Ł
____________________
ŁAŃCUCH PRZYKŁADOWY '))
-----------------------

===================
Rada
Dual jest specjalną tablicą istniejącą w bazie danych Oracle. Jest to tablica bez wierszy i kolumn. Używamy jej w przypadku pisania zapytań, które nie odwołują się do danych z żadnej tablicy.
====================

W przykładzie wywołanie funkcji UPPER () jest zagnieżdżone wewnątrz wywołania funkcji RTRIM (). Funkcja RTRIM () usuwa spacje z prawej strony wyrażenia, a funkcja UPPER () zamienia w wyrażeniu małe litery na wielkie.
Funkcje są omówione w rozdziale 6. "Zastosowanie klauzuli WHERE".

Używanie cudzysłowów

Łańcuchy znaków używane w języku SQL są umieszczane wewnątrz pojedynczych cudzysłowów. Na przykład, gdybyśmy chcieli porównać wartość z jakiejś kolumny tablicy z zadanym łańcuchem znaków, powinien on być zawarty pomiędzy pojedynczymi cudzysłowami. W przypadku porównywania wartości z liczbą lub z wartością z innej kolumny cudzysłowy nie są używane.

SELECT *
FROM Ludzie WHERE Imię = 'Hania'
#35
Pojedynczy cudzysłów wokół słowa Hania wskazuje, że wartość z kolumny imię będzie porównywana ze słowem Hania. Gdyby wyrażenie było skonstruowane bez cudzysłowów

SELECT *
FROM Ludzie
WHERE Imię = Hania

to wartość z kolumny imię byłaby porównywana z wartością z kolumny Hania. W przypadku porównywania wartości w kolumnie z liczbą, również nie jest potrzebne użycie cudzysłowów.

SELECT *
FROM Ludzie
WHERE Pensja = 100000

Pojawia się problem, gdy chcemy wewnątrz łańcucha zawrzeć apostrof.

SELECT *
FROM Businesses
WHERE business name = 'Rafe's Place'

Taki łańcuch będzie błędnie zinterpretowany, bo tylko do pozycji wystąpienia drugiego cudzysłowu, czyli "Rafe". Reszta łańcucha " 's Place" pozostanie odrzucona i pojawi się komunikat o błędzie. Poprawny zapis tego wyrażenia wymaga użycia dwóch pojedynczych cudzysłowów. Taki zapis wskazuje, że cudzysłów jest elementem łańcucha, a nie znakiem końca tego łańcucha.

SELECT *
FROM Businesses
WHERE business name = 'Rafe''s Place'

Nawiasy

Standardowym operatorem grupowania w języku SQL są nawiasy. Używamy ich w celu określenia kolejności wykonywania działań w wyrażeniach matematycznych, w złożonych porównaniach oraz do wyróżniania zapytań zagnieżdżonych.
---------------------
Listing 1.8. Zapytanie z podzapytaniem

SELECT movie_title
FROM Movies
WHERE studio
IN (SELECT name FROM Studios)

MOVIE_TITLE
_____________
Minerał House
Codependence Day
The Rear Windows
Prince Kong
The Linux Files
The Code Warrior
Bili Durham
SQL Strikes Back
The Programmer
Hard Code

10 rows selected
#36
Nawiasów używamy w celu oddzielenia zapytań zagnieżdżonych od reszty wyrażenia. Najpierw wykonywane jest podzapytanie, a jego wynik jest wykorzystany przez zapytanie główne. Nawiasy w wyrażeniach SQL pełnią taką samą funkcję jak w wyrażeniach algebraicznych, ustalając kolejność wykonywania działań. Wyrażenia w najbardziej wewnętrznych nawiasach wykonywane są zawsze jako pierwsze. W przypadkach gdy nawiasy nie rozstrzygają jednoznacznie kolejności wykonania wyrażeń, zadanie ustalenia kolejności przejmuje wbudowany w każdej bazie danych optymalizator zapytań, który ustala kolejność wykonywania działań.
Porównajmy wyniki dwóch przedstawionych zapytań:

SELECT 8 + 2*5
FROM Dual

8 + 2*5
--------
18

SELECT (8 + 2)* 5
FROM Dual

(8 + 2)* 5
----------
50

Jak widać w pierwszym przykładzie, najpierw wykonane jest mnożenie 2*5, a wynik (10) jest dodany do 8, co daje ostateczny wynik 18. W drugim przykładzie nawiasy ustalają kolejność działań - najpierw wykonane jest dodawanie (8+2), następnie wynik pomnożony przez 5.

Operacje relacyjne

Przedstawię teraz podstawowe typy operacji, występujące we wszystkich relacyjnych bazach danych. Wynikiem wszystkich tych operacji są dane w postaci tabel.

Selekcja

Operacja selekcji zwraca wynik w postaci grupy rekordów z tablicy. Operacja ta najczęściej polega na wyborze w oparciu o pewne kryteria grupy rekordów z tablicy. Nie jest konieczne określanie kryteriów wyboru - operacja selekcji może zwrócić wszystkie wiersze z tablicy. Kryteria wyboru decydują, które rekordy tabeli zostaną zwrócone jako wynik. Wynik zawsze zawiera wszystkie kolumny tabeli. Przykład operacji selekcji prezentuje poniższy listing.
------------------------------------
Listing 1.9. Zapytanie dokonujące operacji selekcji tabeli

SELECT *
FROM Studios
WHERE studio state = 'TX'

STUDIO_ID STUDIO_NAME STUDIO_CITY ST
-------- ----------- ------------ ----
3 Delighted Artist Austin TX
-----------------------
#37
Projekcja

Projekcja pozwala określić kolumny, które będą zwracane przez zapytanie. Jest to bardzo przydatne, szczególnie w przypadku tabel z wieloma kolumnami, gdyż często interesują nas wartości tylko z kilku kolumn. Ograniczenie listy kolumn zwracanych przez zapytanie realizujemy poprzez wypisanie w wyrażeniu SELECT nazw kolumn oddzielanych przecinkiem, jak w listingu 1.10.
-------------------
Listing 1.10. Wybór określonych kolumn z tabeli za pomocą operacji projekcji

SELECT studio_name, studio_state
FROM Studios

STUDIO NAME ST
----------- ---
Giant CA
MPM CA
FKG NC
Delighted Artist TX
Metaversal Studios CA
----------------------------

W praktyce często wykorzystuje się w jednym zapytaniu selekcję oraz projekcję. Listing 1.11 pokazuje przykładowe zapytanie łączące te dwie operacje.
--------------------
Listing 1.11. Użycie selekcji i projekcji w jednym zapytaniu

SELECT studio_name, studio_state
FROM Studios
WHERE studio state = 'TX'

STUDIO_NAME ST
-------------- ---
Delighted Artist TX
----------------

Złączenie

Operacja złączenia (ang. join) umożliwia wykorzystanie wielu tabel jako źródła danych dla zapytania. Wybranie wielu tabel realizowane jest poprzez wpisanie nazw tabel w części FROM wyrażenia SQL. Złączenia zostały opisane szczegółowo w rozdziale 8.
W praktyce operację złączenia stosuje się równocześnie z operacjami wyboru i projekcji - dzięki temu wynik zwracany przez zapytanie jest bardziej zrozumiały i przydatny. Operację złączenia ilustruje listing 1.12.
------------------
Listing 1.12. Operacja złączenia

SELECT movie_title, studio_name
FROM Movies, Studios
WHERE Movies.studio_id = Studios.studio_id

MOVIE_TITLE STUDIO_NAME
------------------------------
Minerał House Giant
Codependance Day Giant
The Rear Windows Giant
#38
Prince Kong MPM
The Linux Files MPM
The Code Warrio MPM
Bili Durham Delighted Artists
SQL Strikes Back Delighted Artists
The Programmer Delighted Artists
Hard Code FKG

10 rows selected.
------------------------

Rozwój aplikacji baz danych

Zanim zajmiemy się szczegółowym opisem języka SQL zboczymy trochę od tematu głównego w celu zarysowania szerszego kontekstu problematyki baz danych. Chociaż często polecenia języka SQL są przesyłane do wykonania bezpośrednio bazie danych, równie często są one zagnieżdżone jako komponenty w większych aplikacjach. W ciągu lat istnienia języka SQL aplikacje obsługujące bazy danych bardzo się zmieniły.

Systemy scentralizowane

Początki rozwoju systemów relacyjnych baz danych sięgają dawnych czasów, gdy programy były wykonywane na dużych komputerach, do których użytkownik miał dostęp przez nieprzyjazne interfejsy tekstowe.
Ten model przetwarzania danych dominował aż do 1980 roku, kiedy to rozpoczął się gwałtowny rozwój komputerów klasy PC. Systemy scentralizowane w porównaniu z PC były łatwe w administrowaniu i niezawodne. Nie istniały problemy z wieczną konfiguracją oprogramowania dla setek użytkowników, z których każdy miał na swoim komputerze poinstalowane przeróżne programy. Wystarczało zadbać jedynie o prawidłową konfigurację i funkcjonowanie komputera centralnego.
To były czasy niesławnych dzisiaj zielonych ekranów. Nieme, powolne terminale z zielonymi lub bursztynowymi monitorami, skomplikowany i nieintuicyjny sposób obsługi, tak można by scharakteryzować ówczesny standard. Jednak trzeba przyznać, że w rękach fachowca stanowiły całkiem wydajne narzędzie pracy.
Czasy te skończyły się wraz z narodzeniem się komputerów klasy PC. Mimo że komputery PC dają znacznie większe możliwości swoim użytkownikom, do dziś działa jeszcze wiele systemów opartych na tamtej technologii i sprzęcie.

Systemy klient-serwer

W wyniku upowszechniania komputerów PC taniała komputerowa siła robocza i nastąpił okres wypierania dużych komputerów. IBM czy Digital ustępowały miejsca nowym rozwijającym się firmom, takim jak Microsoft, Intel i Compaq.
#39
Równocześnie pojawiła się koncepcja przetwarzania danych w architekturze klient-serwer lub architekturze n-warstwowej. Ten nowy model przenosił część obciążenia, jakie do tej pory spoczywało na dużym komputerze (ang. mainframe), do komputera użytkownika, jakim stał się PC. Baza danych pozostała na serwerze, ale interfejs użytkownika i pewna część przetwarzania (tzw. logika biznesowa) zostały przeniesione na komputer klienta. W tej architekturze często pojawiał się dodatkowy serwer, pracujący jako serwer aplikacji i pośredniczący w komunikacji pomiędzy klientami a serwerem bazy danych.
Był to czas znacznego rozwoju narzędzi do szybkiej budowy aplikacji w rodzaju Visual Basic'a, Delphi czy PowerBuilder'a. Świadectwem znaczenia architektury klient-serwer jest fakt, że Visual Basic w szybkim czasie stał się najbardziej rozpowszechnionym językiem programowania. Wszystkie wymienione narzędzia programistyczne umożliwiają programowanie interfejsu użytkownika niezależnie od struktury bazy danych, do której dostęp uzyskujemy przy pomocy języka SQL.
Takie zmiany w podejściu do budowy aplikacji zaowocowały rozwojem graficznych interfejsów użytkownika, które znacznie uprościły obsługę systemu. Kolejne korzyści to przyspieszenie działania aplikacji dzięki temu, że wiele operacji jest wykonywanych bezpośrednio na komputerze klienta, a przesyłanie danych przez sieć do serwera zostało ograniczone.
Architektura klient-serwer poza licznymi zaletami ma również słabe punkty. Z powodu rozmieszczenia części aplikacji na komputerach klienta wzrosły znacznie problemy administracyjne. Szczególnie kłopotliwe jest to w przypadkach wprowadzania zmian do aplikacji, bo często konieczne są też poprawki w oprogramowania na komputerach klientów.
W przypadku dużej liczby użytkowników stanowi to poważne wyzwanie dla administratorów. Inne problemy wynikają stąd, że komputer PC z samej swojej natury wymaga więcej zabiegów konfiguracyjnych, niż stary, niemy terminal. W przypadku dzisiejszych systemów operacyjnych, składających się z tysięcy plików, stopień niezawodności pozostawia wiele do życzenia, gdyż często skasowanie lub modyfikacja jednego pliku może unieruchomić cały komputer. Wtedy znów tęsknimy za starym terminalem, który po włączeniu zasilania i kabla sieciowego bez dodatkowych zabiegów logował nas na komputerze centralnym.
Podsumowując można stwierdzić, że architektura klient-serwer daje programistom duże możliwości budowania bardziej przyjaznych dla użytkowników aplikacji jednak za cenę większych problemów przy administrowaniu oprogramowaniem.

Bazy danych na stronach WWW

Obecnie dominującym modelem systemów baz danych jest architektura klient serwer działająca w oparciu o systemy operacyjne Windows NT oraz komercyjne wersje UNIX-a.
W 1993 roku Tim Berners Lee wprowadził World Wide Web. Stworzył on przeglądarkę Web oraz własny serwer. Ciekawe, czy przewidywał tak ogromną eksplozję popularności i wszechobecność swojego wynalazku pod koniec XX wieku.
#40
Strony Web były początkowo wykorzystywane do przekazywania tekstu i obrazów. W zastosowaniach biznesowych stały się nową platformą dla relacyjnych baz danych. Jak już wyjaśniałem, głównym problemem architektury klient-serwer jest konieczność wprowadzania zmian do oprogramowania klienta przy każdej zmianie programu, z kolei systemy scentralizowane, pozbawione tej wady, oferowały prymitywny interfejs użytkownika.
Wydaje się, że nowa platforma oparta o strony Web oferuje połączenie zalet dwóch poprzednich systemów. Przeglądarka stron Web może być uniwersalnym programem po stronie klienta z graficznym interfejsem użytkownika. Tak jak w systemach scentralizowanych, zmiany w aplikacji nie wymagają uaktualnień w oprogramowaniu klientów. Poza tym aplikacja nie musi być dedykowana konkretnej platformie, gdyż każdy komputer, na którym może być zainstalowana przeglądarka, uzyska dostęp do bazy danych.
Z tego względu powstaje wiele pakietów dla programistów wyposażonych w narzędzia do budowy aplikacji Web, inne są wzbogacane o takie możliwości.
Pokazany tutaj model nowej platformy jest bardzo podobny w swojej idei do starej technologii, opierającej się na przetwarzaniu scentralizowanym. Dlatego dziś IBM może reklamować swoje komputery mainframe jako platformę dla aplikacji Web.
Aplikacje Web nie kończą drogi rozwoju aplikacji sieciowych tak jak w przeszłości było z systemami scentralizowanymi, czy modelem klient-serwer. Stanowią obecnie rozwiązanie, którego popularność stale rośnie i jak się wydaje w najbliższej przyszłości kierunek ten będzie utrzymany.

Wiersz poleceń

Większość komercyjnych systemów baz danych zawiera wbudowany program umożliwiający pisanie zapytań SQL. Narzędzia te są szczególnie przydatne przy tworzeniu prostych raportów, testowaniu programu oraz do celów administracyjnych.
Bardzo prawdopodobne, że testując zapytania omawiane w tej książce, będziesz używać właśnie takiego interfejsu. Niestety, nie ma jednej konwencji dotyczącej nazywania tych programów. W bazie Oracle jest to sqlplus, w bazie Sybase isql. Podobne narzędzia są również dostępne w systemach dla Windows, takich jak Access, SQL Server, czy Sybase SQL.

W praktyce

W związku z dynamicznym rozwojem aplikacji Web obserwujemy rosnące znaczenie systemów relacyjnych baz danych. Do tej pory rozwiązania oparte o model relacyjnych baz danych stosowano głównie w tradycyjnych, dużych, drogich systemach opartych na komputerach typu mainframe. Jednak od pewnego czasu są też dostępne tańsze systemy relacyjne małych serwerów i komputerów stacjonarnych.
#41
Początki relacyjnych baz danych na stronach Web polegały na uzyskaniu dostępu przez strony WWW do tradycyjnych aplikacji.
Do modelu relacyjnych baz danych pasuje również struktura informacji związana z handlem elektronicznym. Dane zawarte w katalogach, karty zakupów internetowych, historia transakcji - wszystkie te elementy handlu elektronicznego posiadają doskonałą reprezentację w relacyjnej bazie danych.
Pojawia się tendencja, aby zawartość stron przechowywać wewnątrz relacyjnych baz danych. Na przykład wiele gazet zapisuje swoje artykuły jako rekordy bazy danych. Następnie serwer Web na żądanie wyszukuje informację z bazy i umieszcza ją w przygotowanym wzorcu strony. Zgromadzenie informacji w tej postaci znacznie ułatwia i upraszcza dostęp do danych oraz sposób ich prezentacji. Uwalnia od przechowywania tysięcy plików zawierających pojedyncze artykuły i łączenia ich z odpowiednimi szablonami stron www.
Wciąż rozszerzający się rynek zastosowań relacyjnych baz danych jest dobrą informacją dla wszystkich programistów baz danych, w tym też specjalistów od języka SQL. Rosnący apetyt społeczeństwa na dostęp do coraz większej liczby informacji spowoduje, że w najbliższym czasie pracy dla nich nie zabraknie.