Bazy danych, schematy, SQL - co to znaczy?

8 september 2022
Jakub Rojek Jakub Rojek
Wygenerowane za pomocą: https://openai.com/dall-e-2/
Categories: For clients, IT fundamentals, Databases

Pojęcie "baza danych" jest znane praktycznie wszystkim, nawet osobom niemającym za wiele wspólnego z branżą IT. Zresztą sam termin jest dość intuicyjny - dane mogą być magazynowane w pewnym miejscu i w ten sposób tworzyć bazę, ew. katalog danych. Nie musi mieć postaci cyfrowej - większość z nas doskonale zna miejsca, w których przechowuje się dokumenty, akta czy kartoteki i jak najbardziej ma to formę bazy danych, aczkolwiek dość prymitywnej i "ręcznej". Dlatego wydaje się, że to określenie powinno być kojarzone przez każdego, ale czy rzeczywiście tak jest i używany go poprawnie?

Z bazą danych związanych jest wiele sformułowań, które czasami są błędnie wykorzystywane. Wiadomo, że wynika to z pośpiechu i podejścia "przecież wiesz, o co mi chodzi, to co głupio pytasz", ale okazuje się, że nie każdy wie, co powinno się kryć pod pewnymi zwrotami i jak należy je intuicyjnie rozumieć. Stąd ten tekst, który będzie stanowił coś w rodzaju słowniczka do rozmów o bazach danych, zarówno w środowisku biznesowym, jak i stricte technicznym.

Co to jest baza danych?

Wróćmy do początku tego tekstu - sama baza danych to zbiór informacji zgromadzonych w pewien usystematyzowany i zorganizowany sposób. Jest to zatem pojęcie ogólne, aczkolwiek najczęściej utożsamiane z instancją bazy danych, czyli konkretnym wystąpieniem bazy (aczkolwiek nie jest to takie proste - o tym potem), z której korzysta dany system informatyczny czy aplikacja. Przykładowo, konkretny blog (taki jak ten) ma swoją bazę danych, Twitter ma swoją, Onet.pl swoją itd. Serwisy mogą mieć po kilka baz danych, a kilka serwisów może mieć wspólną. Każda baza to żyjący organizm, z którego odczytywane są dane i na bieżąco mogą do niej przybywać nowe.

Dlatego formalnie bazą danych nie jest choćby MySQL czy pobrany plik z danymi znajdujący się na komputerze. Natomiast faktycznie, czasami skrótowo mówi się o tym w ten sposób, jednak są to zwykle albo wewnętrzne rozmowy osób technicznych, którzy i tak wiedzą o co chodzi, albo zwroty wypowiadane do laika, aby ten był w stanie choćby w przybliżeniu zrozumieć intencje osób z IT. Czasem przy omawianiu pewnych specjalistycznych zagadnień dobrze jest czasem nieco "skłamać", aby złapać kontakt, a dopiero później ewentualnie "odkłamywać", aby to, co zostało zrozumiane, stało się jeszcze jaśniejsze. I właśnie to drugie czynię w dzisiejszym tekście.

Co to jest system do zarządzania bazą danych (SZBD)?

Baza danych nie istnieje w próżni - jest obsługiwana przez pewien program, a raczej cały silnik bazodanowy i konkretny mechanizm stanowiący magazyn oraz interfejs dostępu do informacji. To właśnie system do zarządzania bazą danych, a raczej bazami danych, gdyż - oczywiście - jeden system może zawierać w sobie wiele baz dla różnych aplikacji.

W ogólności SZBD dzielą się na relacyjne (SQL) oraz nierelacyjne (NoSQL). Te pierwsze mają uporządkowaną strukturę w postaci tabelek (zwanych relacjami), pomiędzy którymi mogą występować powiązania, nie tylko integrujące dane, ale też pomagające sprawdzać ich poprawność. Jest to najpopularniejszy sposób obsługi baz danych i to właśnie tak działają znane MySQL, PostgreSQL czy Oracle. Wszystkie udostępniają swoją implementację języka zapytań SQL (ang. Structured Query Language), który umożliwia użytkownikom i aplikacjom na dostęp i modyfikowanie informacji oraz schematu. Zatem SQL to też nie jest baza danych - to język, którym możemy się z nią porozumieć.

Z kolei systemy nierelacyjne, jak sama nazwa mówi, nie opierają się na relacjach, a dużo luźniejszych strukturach przechowywania informacji. Nie jest to jednorodna grupa - można wyróżnić bazy dokumentowe (MongoDB), kolumnowe (Apache Cassandra), typu klucz-wartość (Redis) czy grafowe (Neo4j). Od baz SQL-owych różnią się nie tylko sposobem komunikacji (mają swoje języki) i strukturą, ale także wydajnością w konkretnych sytuacjach czy skalowalnością.

Pamiętacie, gdy wspomniałem o tym, że czasem warto "nakłamać", a potem "odkłamać"? W tym akapicie też to zrobiłem, bowiem system do zarządzania bazą danych niekoniecznie jest tym samym, co silnik bazodanowy. Przykładowo, znany MySQL ma dwa - InnoDB (domyślny, relacyjny) i starszy MyISAM. Jednak w przypadku większości systemów nie ma to większego znaczenia i akurat tutaj ujednolicenie tych terminów jest wyjątkowo zrozumiałe.

Co to jest schemat bazy danych?

Wspominałem o tym, że relacyjne bazy danych są konstruowane poprzez tabelki, powiązania między nimi oraz inne pomocnicze elementy. Odpowiednie ułożenie relacji ma duże znaczenie zarówno dla spójności przechowywanych informacji, jak i dla wydajności późniejszego korzystania z takiej bazy. Należy zatem dogłębnie przemyśleć, jakie tabelki rzeczywiście są potrzebne i w jaki sposób dane powinny być uporządkowane. Czyli zaprojektować schemat bazy danych - tym właśnie on jest. To szkielet, na którym opierają się rekordy (zwane też krotkami) i który służy do ich odpowiedniej obsługi za pomocą zapytań SQL. Sama sztuka tworzenia schematów to bardzo szeroki temat, który często jest wykładany przez całe semestry na studiach, ale przede wszystkim ćwiczony praktycznie na podstawie kolejnych projektów i dostosowywany do konkretnej sytuacji.

Krótko mówiąc, schemat bazy danych to baza danych bez jakichkolwiek danych, jedynie z informacjami o strukturze tabelek. Dlatego przy tworzeniu kopii zapasowej za pomocą odpowiednich programów, użytkownik ma zazwyczaj do wyboru tworzenie kopii samego schematu lub schematu wraz z danymi.

Co to jest obraz bazy danych?

Wspomnieliśmy o tym, że baza danych to "żyjący" twór, w którym dane mogą się zmieniać. A ponieważ zdarzają się awarie lub potrzeba wykonania jakichś operacji na innym komputerze lub serwerze, w cenie jest robienie kopii zapasowanych (backupów) bazy. Czyli zachowanie konkretnego stanu danych z danego momentu w czasie, najczęściej w formie pliku. To właśnie obraz, zwany też kopią.

Co to jest instancja bazy danych?

Tutaj z kolei z musimy wrócić do kwestii skalowania, czyli przygotowania systemu informatycznego w taki sposób, aby można było go "rozrzucić" po kilku serwerach. Dotyczy to też bazy danych, która może być replikowana, czyli w razie potrzeby mogą powstać jej kopie, które się wzajemnie synchronizują. Jest to związane nawet nie tyle z wydajnością, co odpornością na awarie i możliwością przywrócenia danych. Każda z tych kopii to osobna instancja bazy danych, a więc jej "wystąpienie".

W ogóle słowo "instancja" jest szeroko używane w informatyce. Programistom w większości zapewne kojarzy się z programowaniem obiektowym i tym, że obiekt to instancja danej klasy (a więc tak jakby już konkretny przykład wykorzystania danego schematu). Jeśli mamy na komputerze trzy razy uruchomiony program "Kalkulator", to mamy jego trzy instancje. Podobnie jest z aplikacjami na serwerze oraz właśnie bazami danych. Oczywiście, w większości przypadków mamy tylko i wyłącznie jedną instancję danej bazy, jednak w przypadku ogromnych systemów lub tych o szczególnym znaczeniu strategicznym nie jest już to takie oczywiste.

Co to jest hurtownia bazy danych?

Większość aplikacji korzysta z baz danych w tzw. modelu OLTP, a więc transakcyjnym. Każda sesja zapisu danych do bazy jest transakcją, czyli nieprzerwanym (atomowym) procesem, który kończy się zachowaniem wszystkiego lub niczego. Ponownie to temat rzeka, natomiast clou tej koncepcji jest takie, że jest to standardowe wykorzystanie, dotyczące systemów, w których danych może być dużo, ale nie jest to ogromna ilość, w dodatku szybko rosnąca. Można powiedzieć, że 99% serwisów w Internecie, z których korzystacie, opiera się o OLTP.

Co innego z OLAP-em, a więc modelem analitycznym, który jest podstawą właśnie hurtowni danych. To też bazy danych, ale kolosalne, zawierające i ciągle zasilane gigantyczną ilością danych, których mechanizmy nie są dostosowane do korzystania z nich na bieżąco. Zamiast tego OLAP-y skupiają się na zapewnieniu metod do tworzenia analiz, raportów i wyszukiwania pewnych wzorców, które mogą ułatwić np. opracowanie modelu sprzedażowego. Jak najbardziej mogą obok siebie istnieć też dwie bazy - jedna OLTP-owa, do standardowego korzystania z danej aplikacji oraz druga, OLAP-owa, w której "odkładane" są dane do dalszej analizy.

Czy baza danych może być nazywana katalogiem danych?

W teorii tak, jednak w praktyce rzadko się słyszy, aby ujednolicano te pojęcia. Przy projektowaniu słowo "katalog" kojarzy się bardziej ze spisem możliwych opcji do wyboru w danym polu. Przykładowo, jeśli w systemie przechowujemy klientów i chcemy analizować, skąd u nas się pojawili, powinniśmy zapisywać taką informację, ale dodatkowo, żeby późniejsze raportowanie było rozsądne, powinniśmy utworzyć katalog możliwych źródeł klientów. Wspominam o tym bardziej dla porządku - z założenia "baza" kojarzy się z czymś większym.

Podsumowanie

Dzisiejszy artykuł był bardziej terminologiczny i mam nadzieję, że niektórym uświadomił znaczenie fraz, z których wcześniej nie zdawali sobie sprawy, a czasami się z nimi stykali. Jeśli tak się stało, to tym bardziej mi miło, ale nawet w innym przypadku warto co jakiś czas systematyzować i odświeżać sobie wiedzę, która ciągle się przydaje, jeśli chcemy dobrze się komunikować, zarówno wewnątrz zespołu IT, jak i w kontakcie z klientami.

Pozdrawiam i dziękuję - Jakub Rojek.

We write not only blog articles, but also applications and documentation for our clients. See who we have worked with so far.

About author

Jakub Rojek

Lead programmer and co-owner of Wilda Software, with many years of experience in software creation and development, but also in writing texts for various blogs. A trained analyst and IT systems architect. At the same time he is a graduate of Poznan University of Technology and teaches at this university. In his free time, he enjoys playing video games (mainly card games), reading books, watching american football and e-sport, discovering heavier music, and pointing out other people's language mistakes.

Jakub Rojek