#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 zawartoci relacyjnych baz danych. Model relacyjnej bazy danych Większoć obecnych dzisiaj na rynku baz danych powstało w oparciu o model relacyjny. Podstawowa właciwoć 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 okrela 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łanie 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 odnonik od kolumny studio z tabeli 1.1 do odpowiedniej kolumny w innej tabeli. Podstawowš korzyciš 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 miecie, 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ójnoci 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, integralnoci 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 koniecznoci znajomoci 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, jestemy zmuszeni osobicie 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 wartoci. Innymi słowy, nie posługujemy się wskanikami 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 okrelonych 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 wartoci z zadanš grupš wartoci, jak w przykładzie: SELECT * FROM Movies WHERE studio IN ('MPM', 'Giant') Wartoci z kolumny studio sš porównywane z dwoma wartociami MPM i Giant. Predykat IN wymaga podania listy wartoci lub, stosujšc innš terminologię, tabeli zjednš kolumnš i pewnš liczbš wierszy. Zatem lista wartoci 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 wartoci studio sš porównywane. Zapytania zagnieżdżone omówiono w rozdziale 9. Zasady dotyczšce integralnoci danych Zasady integralnoci danych wymagajš, aby każdy wiersz tabeli zawierał wartoć lub grupę wartoci, które okrelałyby go w sposób jednoznaczny (unikalny). Te wybrane wartoci 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 cile zasad integralnoci danych. Pomimo że zasady integralnoci 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żliwoci bezwarunkowego przestrzegania reguł integralnoci. =================== 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 okrelić dod...
sliwak