SQL skrót pochodzi od angielskiej nazwy [1]„Structured Query Language”. Początkowo był to prosty język do definiowania, formułowania zapytań oraz modyfikowania i kontroli danych w relacyjnej bazie danych. Jest to język , jakim „mówi” relacyjna baza danych. W praktyce SQL jest standardowym językiem zapytań dla relacyjnych baz danych. Twórcą modelu relacyjnego jest E. F. Codd. Podał on szczegółową listę warunków , jakie musi spełnić model relacyjny. Ta lista często nazywana jest „prawami Codda” obejmuje ona używaną terminologię i kwestie teoretyczne.

Model relacyjny

            Pierwsze prawo Codda mówi, że wszystkie informacje w relacyjnych bazach danych są przedstawiane przez wartości zapisane w tabelach. W modelu relacyjnym tabele mają (poziome) wiersze) i pionowe kolumny. Tylko w takiej formie przedstawiane są dane w bazie danych.

Wprowadzenie do baz danych

Rys. Tabela zawierająca dane samochodów

Czasami zamiast tabeli, wiersza i kolumny używa się pojęć: relacja, krotka (encja) i atrybut. Obie formy są poprawne, trzy ostatnie pojęcia  pochodzą z ogólnego słownika przetwarzania danych.

Zbiór powiązanych ze sobą danych tworzy bazę danych . Wszystkie tabele są jednakowo ważne nie ma czegoś takiego jak hierarchia tabel. Możemy to zaobserwować na rysunku 1.1.

Wszystkie tabele składają się ze zbioru wierszy i kolumn. Wiersze opisują każde pojedyncze wykonanie encji, np. samochody, osoby. Kolumny opisują charakterystyczną cechę encji, np. nr rejestracyjny samochodu, markę lub model.

W modelu  relacyjnym dane są nie zależne na dwóch poziomach: fizycznym i logicznym.

Na poziomie fizycznym oznacza to że niezależnie od tego jak dane są fizycznie zapamiętane nie ma to wpływu na to w jaki sposób dane zostaną zaprezentowane użytkownikowi. W istocie pamięć fizyczna może być zmieniana lub przeorganizowana bez wpływu na logiczny projekt bazy danych.  Drugi poziom niezależności logicznej oznacza, że relacje między tabelami, kolumnami i wierszami mogą być zmienne, nie mając wpływu na funkcjonowanie zapytań. Użytkownik może podzielić tabele na wiersze lub kolumny a i tak może dostać odpowiedz na dowolne zapytanie nawet jeżeli logiczna koncepcja uległa zmianie.

 Budowa bazy danych

Podczas projektowania bazy danych musimy podjąć wiele decyzji, co do wyglądu.

Musimy określić:

  • Jakie tabele będą się znajdowały w naszej bazie;
  • Jakie kolumny wchodzą w skład tabeli;
  • Jakie tabele i kolumny będą połączone relacjami;

Projektowanie bazy danych dotyczy jedynie jej logicznej struktury. Niezależnie od tego w jaki fizyczny sposób przechowywane są dane, końcowy efekt może być przedstawiony jak tylko chcemy przeglądać dane. Również struktura logiczna nie jest zależna od tego, co zobaczymy w końcowym efekcie. Projektowanie relacyjnej bazy danych daje kilka korzyści.

Uniezależnienie od struktury logicznej i fizycznej od końcowego wyglądu bazy danych. W dowolnym monecie możemy zmienić strukturę logiczną a wygląd końcowy pozostanie taki sam.

Decyzje projektanta nie ograniczają dalszego rozwoju bazy danych i zapytań, jakie możemy zadawać o danych w przyszłości. Model relacyjny nie wymaga definiowania konkretnych ścieżek zapytań między danymi. Można w dowolny logiczny sposób zestawiać ze sobą tabele.

Przechodząc do projektowania bazy danych należałoby przeanalizować dwie rzeczy, które mogą nam pomóc przy budowie bazy danych takie jak: normalizacja i modelowanie związków encji. Są to wytyczne, którymi powinniśmy się kierować przy projektowaniu baz danych. Lecz nie są one sztywnymi regułami, których powinniśmy się bezwzględnie trzymać. Mają one nas jedynie pokierować, wybór najlepszego sposobu opisania danej sytuacji zależy od nas. Każdy projekt bazy danych jest indywidualny, każdy może podejść do tego w inny sposób. Często zdarza się że do opisania danego modelu istnieje więcej niż jedno poprawne rozwiązanie, niekiedy zdarza się, że odejście od zasad projektowania będzie lepszym rozwiązaniem.

Reguły normalizacji bazy danych skupiają się na ochronie spójności danych przez unikanie powielania ich. Polega to na podzieleniu tabeli na dwie lub więcej tabel, które mogą być „ponownie złączone” za pomocą operacji złączenia. Z technicznego punktu widzenia jest to proces bezstratnej dekompozycji, polegający na podzieleniu tabeli na kilka tabel bez utraty zawartych w nich informacji.

Związki encji

Modelowanie związków encji to nic innego jak zidentyfikowanie rzeczy (encji), które będą gromadzone w naszej bazie danych. A także właściwości tych rzeczy oraz zachodzących związków miedzy nimi.

Analizując bazę danych dotyczącą wypożyczalni samochodów można wyróżnić listę występujących encji:

  • klienci, którzy wypożyczyli samochód;
  • samochody, wypożyczane przez wypożyczalnię;
  • sposób zapłaty;
  • zamówienia klientów

Wszystkie z przedstawionych encji  są niezależną tabelą zawierającą dane. Posiadają one również właściwości, które są zapamiętane w bazie danych.  W przypadku bazy danych dla wypożyczalni diagram związków encji będzie wyglądał następująco:

tabele-bazy-danych

Rys. tabele bazy danych wypożyczalni samochodów

Każda z tabel musi posiadać unikatowy identyfikator, w ramach swojej własnej struktury. PRIMARY KEY identyfikuje każdy wiersz (rekord), spełnia przy tym reguły normalizacji i jednocześnie jest łącznikiem między innymi tabelami. Aby lepiej to zrozumieć  (patrz rys.2.1), każda tabela ma swój unikatowy identyfikator. Patrząc na tabelę klienci dzięki Id klienta możemy jednego klienta od drugiego. Możemy sobie zadać pytanie, dlaczego by nie zrobić klucza głównego posługując się nazwiskiem i imieniem czy nawet peselem. Otóż użycie imienia i nazwiska, jako identyfikatora z czasem rozbudowywania danych w tabeli mogło by się okazać, że będziemy mieli dwóch Janów Kowalskich i wtedy pojawi się problem ponieważ nasz klucz nie będzie już unikatowy. Kolejnym problemem  związanym z identyfikacją po nazwisku jest błąd przy wprowadzaniu danych przez człowieka. Wystarczyłaby jedna literówka i mielibyśmy problem ze znalezieniem naszego klienta. W przypadku nadania Id klienta numeracja nadawana jest automatycznie, w ten sposób wyeliminowany jest błąd czynnika ludzkiego. Jeżeli chodzi o numer pesel wydawało by się, że jest on wartością unikatową i nie ma dwóch osób o takim samym peselu. Lecz w czasami zdarzały się błędy w numeracji pesel, dlatego bezpieczniej jest każdemu klientowi nadać swój własny identyfikator. Najlepszym pomysłem na tworzenie klucza głównego jest używanie identyfikatorów, które są nadawane przez instytucje np. numery rejestracyjne (tabela samochody), numery dowodów, legitymacji studenckich. Przyjęcie odpowiednich rekordów jako klucze główne jest jednym z ważniejszych kroków przy tworzeniu baz danych.

Związki między tabelami

Związek jeden-do-wielu 1:N

 

zwiazek-jeden-do-wiele

Rys. Przykład związku jeden do wielu 1:N

Spoglądając na tabele w naszej bazie danych można zaobserwować pewne związki między tabelami (Patrz rys. 3). Tabela zamówienie informuje nas, jaki klient został przypisany do konkretnego zamówienia oraz jaki wybrał on sposób zapłaty. Każdy taki związek między klientem a zamówieniem możemy opisać, jako związek jeden do wiele. Każdy klient może mieć wiele zamówień, lecz każde zamówienie może mieć tylko jednego klienta.

Rekord  Id klienta w tabeli zamówienie jest kluczem obcym. Możemy go użyć do określenia wskazanych rekordów w tabeli klienci i w ten sposób połączyć informacje dotyczące zamówień i klientów. Przy takim rozwiązaniu w dwóch tabelach mamy dwa jednakowe rekordy. Przy projektowaniu baz danych celem jest unikanie redundancji, lecz w takim przypadku lepszym rozwiązaniem jest użycie klucza obcego. Przy dodaniu nowego zamówienia od razu możemy przypisywać do niego klienta który został już wcześniej zdefiniowany nie musimy nic dodawać do tabeli klienci, gdyż jest ona jest już wcześniej zdefiniowana, wystarczy, że do zamówienia w wierszu Id klienta  wprowadzimy odpowiednią wartość. W tabeli klienci rekord Id klienta jest kluczem głównym, lecz w tabeli zamówienia rekord Id klienta jest kluczem obcym. W modelu relacyjnym wymagane jest aby związek jeden do wiele był przedstawiony za pomocą parę klucz główny- klucz obcy.

Klucz obcy jest encja lub kombinacją rekordem w jednej tabeli, których wartości określają wartości znajdujące się w kluczu głównym innej tabeli. Podczas projektowania baz danych używa się tego typu zabiegów aby zapewnić spójność od wołań miedzy kluczem głównym a kluczem obcym.

Kiedy w tabeli klienci zaktualizujemy lub usuniemy identyfikator wtedy automatycznie ta zmiana powinna być wprowadzona w tabeli zamówienia. Powinno to się odbyć przez aktualizacje odpowiednich wartości w rekordzie Id klienta w tabeli zamówienia lub kaskadowo zaczynając do tabeli klienci.

Kiedy dodamy nowe zamówienie , wtedy powinniśmy mieć możliwość sprawdzenia czy powiązany z nim Id klient jest poprawny i czy znajduje się w tabeli Klienci.

Związki wiele do wiele N:N

zwiazek-wiele-do-wiele

Rys. Przykład związku wiele do wiele N:N

Związek wiele do wiele czasami też nazywany asocjacją. Zgodnie z teorią związków encji asocjacje w relacyjnych bazach danych reprezentowane są przez tabele same w sobie. W bazie danych wypożyczalni potrzebujemy tabeli dla klientów i tabeli dla samochodów która reprezentowała by związek miedzy nimi(Patrz rys.4). W naszym przypadku jest to tabela zamówienia która reprezentuje związek wiele do wiele. Tabele zamówienia i samochody łączą się przez kolumny Nr rejestracyjny. Tabele klienci i zamówienia łączą się przez kolumny  Id klienta każdej tabeli. Można powiedzieć, że Id klienta w zamówienia jest kluczem obcym zgodnym z kluczem głównym w Id klienta w Klienci zaś Nr rejestracyjny w zamówienia jest kluczem obcym zgodnym z kluczem głównym Nr rejestracyjny w samochody. Ani numer rejestracyjny, ani identyfikator klienta nie są nie wyznaczają jednoznacznie encji w tabeli zamówienia. W modelu relacyjnym elementy asocjacji przedstawiane są za pomocą kluczy obcych w tabeli przedstawiającej asocjację.

 Związki jeden do jeden 1:1

Najczęściej związek jeden do jeden stosuje się ze względu na szybkość wykonywania zapytań. Jeśli w bazie używa się informacji, które są rzadko wykorzystywanie, można je przetrzymywać w osobnej tabeli, aby nie musieć ich przetwarzać przy każdym zwykłym zapytaniu. Taki związek encji rzadko używany, ponieważ dość trudno jest określić, kiedy powinien występować taki związek. Dlatego odradza się używania takiej struktury.

[1] „Co to jest SQL?” Serwis: Strony malowanehttp://stronymalowane.pl/sql/

Dodaj komentarz