Relacyjna baza danych

W poprzednim wpisie (tutaj) mówiłem o rodzajach baz danych. Wspominałem tam o relacyjnych bazach danych i dzisiaj chciałbym poszerzyć ten temat i od relacyjnego rodzaju baz zacząć prowadzić Cię po ścieżce baz danych.

Ok, a więc zaczynajmy 🙂
b
W relacyjnych bazach danych zawartość jest zorganizowana jako zbiór tabel, które mogą być ze sobą powiązane, zawierających kolumny i wiersze.
Do komunikacji z relacyjną bazą danych używa się języka zwanego SQL (Structured Query Language).
Przykładowymi bazami danych mogą być m.in. PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database. Dokładniej opiszę je w jednym z kolejnych wpisów.

Mamy już kilka podstawowych informacji, ale czas na przykład, przy pomocy którego pokażę o co chodzi z relacyjnymi bazami danych.

Za przykład weźmy sklep internetowy, w którym mamy produkty, kupujących, koszyk z zakupami, zamówienia.

Między tym wszystkim występują relacje.

• W sklepie mamy produkty
• Produkty mogą być w koszyku z zakupami
• Kupujący może mieć jeden koszyk z zakupami
• Kupujący może mieć wiele zamówień

Ok, zacznijmy w takim razie krok po kroku zamieniać sklep internetowy w bazę danych.

Encja

Zacznijmy od pojęcia encji. Encja to rodzaj “obiektu” przechowywanego w bazie danych np.: towar, koszyk z zakupami, kupujący, zamówienie. Jest to jedno z pojęć, z którym spotkasz się projektując swoje bazy danych w przyszłości.

Atrybut

To kolejne słowo klucz w bazach danych. Oznacza “właściwość” w encji. Każda encja posiada jakieś atrybuty np. produkt posiada m.in. nazwę, cenę, ilość sztuk dostępnych w sklepie, opis.
Koszyk posiada m.in. informacje o produktach oraz powiązanie do klienta. Kupujący posiada imię, nazwisko, nr karty kredytowej. Atrybuty posiadają swoje typy. Atrybut “imię” jest ciągiem znaków, a atrybut “cena” jest liczbą zmiennoprzecinkową.
Istnieją różne typy danych w różnych bazach dlatego będę je dokładnie opisywał potem w zależności od bazy danych.

Krotka

Krotka jest zbiorem atrybutów. Jest to instancja, czyli konkretne wartości np. dla produktu, który posiadał atrybuty: nazwę, cenę, ilość sztuk dostępnych w sklepie, opis. Jego krotką jest: koszulka, 39zł, 20 sztuk, t-shirt w kolorze niebieskim.
Inną krotką np. dla kupującego może być: imię, nazwisko, nr karty kredytowej – Adam, Nowak, nr 99 0000 0000 0000 1234).

Relacja

W relacyjnych bazach danych to nasze słowo klucz i tutaj może być to trochę mylące w stosunku do języka polskiego, ponieważ relacja to zbiór krotek nazywanych tabelą, np.:

Taki zbiór krotek najczęściej przedstawiany jest w formie tabeli tak jak powyżej, dlatego nazywany jest powszechnie tabelą.

Relacja pomiędzy tabelami np. pomiędzy tabelą produktów a koszykiem zakupów to “związek”.

Pamiętaj, że wszystkie te pojęcia pochodzą z języka angielskiego dlatego tutaj wkradł się mały chochlik :p ach ten nasz język polski sprawia trochę psikusów.

Klucz główny

Zbiór atrybutów w naszej tabeli (zbiorze krotek) tworzy klucz główny, czyli unikalny identyfikator, dzięki któremu będzie można wyłapać konkretną krotkę, konkretny wiersz w naszej tabeli. Po angielsku klucz główny to primary key i najczęściej jest to jakiś id w postaci liczby np. dla produktów.

Nic nie stoi na przeszkodzie, aby kluczem głównym była np. nazwa (ale wtedy musi ona być unikalna dla wszystkich wierszy w naszej tabeli. Istnieje też możliwość, aby klucz główny składał się z 2 wierszy (atrybutów) np. z nazwy i ceny. Najczęściej jednak używa się osobnego atrybutu o nazwie id (identyfikator).
Ważna informacja to taka, że bazy danych optymalizują wyciąganie zawartości bazy danych po kluczach głównych to znaczy, że wyciągnięcie produktu po id 1 (kluczu głównym) będzie szybsze niż wyciągnięcie produktu po np. cenie (która nie jest kluczem głównym). Bazy danych są szybkie i żeby zobaczyć różnice nasza baza musi mieć naprawdę ogromną ilość krotek (wierszy), ale warto o tym pamiętać, ponieważ gdy nasz sklep będzie wielkości Allegro albo Amazona, wtedy optymalizacja bazy danych ma duże znaczenie.

Klucz obcy

Tabele mogą być ze sobą powiązane. Aby dokonać powiązania robi się to za pomocą kluczy obcych (forign key). W naszym przypadku mamy Produkty i koszyk z zakupami.

Powiązania

Na podstawie informacji o kluczach obcych widać, że między tabelami mogą występować powiązania. W relacyjnych bazach danych mamy do czynienia z 3 rodzajami powiązań:

Powiązanie Jeden do jeden

To powiązanie, w którym jedna krotka odpowiada jednej krotce z innej tabeli. Przykładem może być sytuacja, w której klient może tylko raz skorzystać z unikatowego kodu rabatowego, wtedy konkretny kod rabatowy jest powiązany z konkretnym klientem.

Powiązanie Jeden do wielu

Tutaj mamy sytuację, w której jak nazwa wskazuje mamy powiązanie jeden do wielu. Przykładem może być powiązanie produkt producent, w którym producent może mieć wiele produktów, ale produkt może należeć do jednego producenta.

Powiązanie Wiele do wielu

To ostatni typ powiązania. W tym przypadku mamy do czynienia np. w powiązaniu koszyka z zakupami i produktami. Jeden produkt może być w wielu koszykach oraz jeden koszyk może mieć wiele produktów w sobie.
W tym przypadku mamy do czynienia z tabelą pośrednią, ponieważ nie da się inaczej przedstawić relacji wiele do wielu. Potrzebna jest nam jakaś tabela, która będzie to wszystko łączyła.

---

Ok, to na tyle, jeżeli chodzi o wstępne przedstawienie tematu relacyjnych baz danych. Wiem, że wpis był naprawdę długi, ale poruszyłem tutaj wszystkie podstawowe zagadnienia, z jakimi spotkasz się w ramach kroczenia ścieżką baz danych. W kolejnych wpisach będę przedstawiał kolejne zagadnienia relacyjnych baz danych oraz szczegółowo omawiał opisane w tym wpisie zagadnienia.