Wstęp Bazy danych to dziedzina informatyki, dynamicznie się rozwijająca i mająca szerokie zastosowanie w wielu miejscach wszędzie tam, gdzie niezbędne jest przetwarzanie jakichkolwiek danych. Rzadko spotykanym bowiem zjawiskiem jest aplikacja, która nie operuje na żadnych danych, a bazy niezwykle ułatwiają pracę z nimi. Zwykły użytkownik komputera, a nawet osoba, która z niego nie korzysta, spotyka się z bazami danych na każdym kroku. Czytelnik korzysta właśnie z serwisu, który nie istniałby bez bazy danych. Kupno biletu kolejowego, robienie zakupów czy nawet zwykłe wykonanie połączenia telefonicznego to czynności, które zazwyczaj nie kojarzą się z informatyką i z jej omawianym działem, a jednak korzystają z jego wytworów i mają z nim bardzo wiele wspólnego. Można zaryzykować stwierdzenie, że wiele innych dziedzin zarówno informatyki, jak i życia nie rozwijałoby się lub ich rozwój byłby ograniczony, gdyby nie istniały bazy danych. Problem przetwarzania informacji przez aplikacje istniał od początku istnienia programowania, a upływ czasu spowodował powstanie baz danych oraz systemów zarządzania bazami danych (silnikami baz danych). Jakiekolwiek operowanie na większych ilościach informacji implikuje bowiem rozwój tego działu informatyki.

Zwroty "operowanie na danych", "większe ilości informacji" jest oczywiście nieprecyzyjny, a np. "silnik bazy danych" może być kompletnie niezrozumiały. Warto byłoby z początku sprecyzować zatem, co one (oraz inne im podobne) oznaczają, a w późniejszym czasie sformalizować w pewien sposób obszar, w jakim się poruszamy.

Co to są bazy danych i systemy zarządzania bazą danych i dlaczego je stosować? Na początek warto zdefiniować samo pojęcie "baza danych". Termin ten zależnie od kontekstu znaczy bowiem coś innego. Często mówi się bowiem: „używam bazy danych”, „baza danych PostgreSQL pozwala na...”, „schemat bazy danych”, „nazwa bazy danych potrzebna do zalogowania”, „parametry połączenia z bazą” itp., a w każdym z wymienionych zwrotów mamy na myśli coś innego. Najogólniej rzecz biorąc, „baza danych” to zbiór informacji wraz z możliwością łatwego dostępu oraz ich zmiany (tj. modyfikacją, dodawaniem nowych i usuwaniem starych) z poziomu aplikacji z niej korzystającej. W taki właśnie sposób rozumiane jest to określenie w pierwszym z wymienionych zwrotów. „Używam bazy danych” oznacza „korzystam ze zbioru informacji, który łatwo odczytywać i zmieniać”.Patrząc na temat pod tym kątem, można powiedzieć, że np. plik tekstowy można uznać za bazę danych jeśli odczytanie i modyfikację zapisanych w nim informacji w konkretnym zastosowaniu uznamy za łatwe (i symetrycznie – jeśli nie uznamy tego za łatwe nie można będzie pliku nazwać „bazą danych”). Przykładowo niech program wyświetla krótki komunikat, który powinien mieć możliwość dowolnej zmiany. Zastosowanie wtedy zwykłego pliku z tekstem jest jak najbardziej dobrym rozwiązaniem i można go nazwać „bazą danych”. Na rysunkach poniżej przedstawiono schematycznie sposoby, w jaki aplikacja może korzystać z danych. I tak rysunek 1 przedstawia najprostszą sytuację, kiedy dane, z jakich program korzysta, są wbudowane do niego na stałe.

Trudno w takim przypadku mówić o bazie danych, gdyż zazwyczaj nie istnieje możliwość zmiany zawartych w programie informacji, a już na pewno jest to utrudnione. Rysunek 2 przedstawia sytuację pasującą do przykładu z zewnętrznym plikiem tekstowym.

Zbiór na dysku zawiera potrzebne informacje i jest wydzielony od samej aplikacji. Pozwala to na łatwą ich modyfikację oraz odczyt. Jak widać, elipsa reprezentująca program i bazę danych nachodzą na siebie. Symbolizuje to fakt, iż program musi znać strukturę pliku podczas odczytu informacji z bazy oraz bezpośrednio w nią ingerować w trakcie ich modyfikacji. Struktura pliku jest tutaj rozumiana jako sposób przechowywania danych, która może być bardziej złożona niż ta wspomniana wyżej. Przykładowo jeśli aplikacja wyświetla kilka tekstów, niezbędnym staje się rozdzielenie ich jakoś w pliku, tak aby program był w stanie przeczytać bądź modyfikować konkretny z nich. Trzeba zatem wymyślić sposób, w jaki dane przechowywane są w bazie. Można by założyć zatem, iż jedna linijka w pliku tekstowym to jeden komunikat i skutecznie rozwiąże to przedstawiony problem. Spowoduje to jednak pojawienie się też trudności, jeśli okaże się, że wyświetlane komunikaty będą mogły zawierać znaki nowej linii. Program musi rozróżnić taki znak w środku tekstów od tego, który je rozdziela w samym pliku. Ponadto np. w nowszej wersji aplikacji może pojawić się potrzeba przechowywania poza samym tekstem komunikatu także innych informacji go dotyczących, np. jego rodzaj (informacja, ostrzeżenie, pytanie) oraz nazwę obrazka wyświetlanego obok. Spowoduje to konieczność zmiany struktury pliku i np. ustaleniu, iż każda linijka zawiera informacje o jednym komunikacie rozdzielone specjalnym znakiem przy czym znak enter oraz znak rozdzielający w samych danych nie mogą się pojawiać, aby nie spowodować problemów z ich interpretacją. W każdym razie wymusi to zmianę sposobu przechowywania danych, a to pociągnie za sobą konieczność zmiany już napisanego kodu korzystającego z niego. Skomplikujmy jeszcze nieco nasz przykład i załóżmy że, komunikatów jest bardzo dużo, a my chcemy wyświetlić wszystkie których rodzaj obrazka mówi, iż jest to ważny komunikat ostrzegawczy. Przeszukiwanie wtedy pliku i sprawdzanie każdej linijki może okazać się za wolne. Sprytny programista mógłby pogrupować wyświetlane teksty na podstawie rodzaju i utworzyć dla każdej grupy oddzielny plik w specjalnym katalogu, ale to z kolei pociągnie kolejne zmiany już napisanego kodu. Co będzie jednak, jeśli chcielibyśmy także przyspieszyć odczytywanie komunikatów wyświetlanych obok konkretnego obrazka znając jego nazwę? A jeśli aplikacja ma umożliwić wymianę bardziej złożonych informacji (np. finansowych) pomiędzy osobami znajdującymi się w różnych częściach świata? Sam plik na dysku twardym komputera wtedy nie wystarczy. W takim przypadku można by umieścić go na komputerze z dostępem do Internetu i korzystając z np. serwera FTP, czytać i zapisywać go (rysunek 3). Rozwiąże to drugi problem, jednak zwiększy pierwszy. Przeszukiwanie danych będzie wymagało każdorazowego przesłania zawartości pliku przez łącze sieciowe, co drastycznie zmniejszy wydajność.

Proszę zwrócić uwagę, że sam plik nie jest już nazywany „bazą danych”, gdyż umieszczony na serwerze sam nie pozwala na dostęp do zawartych w nich danych ani na ich modyfikację. Dopiero dane wraz z serwerem FTP tworzą twór zdefiniowany wcześniej jako baza danych. Przedstawione rozwiązanie jest zadowalające jedynie w marginalnej części przypadków, bo (pomijając mało wydajne przeszukiwanie), co się stanie, jeśli więcej niż jedna kopia programu jednocześnie będą chciały zapisać dane do tego pliku (rysunek 4)?

Czy „wejdą sobie w drogę”? Czy trzeba samodzielnie opracować jakiś mechanizm blokady? Program nie ma jednak łatwej możliwości sprawdzenia, czy dany plik z serwera FTP próbuje odczytać inna aplikacja próbująca korzystać z tych samych danych. „Wie” to serwer, ale nie udostępnia tej wiedzy. Problem komplikuje się jeszcze bardziej, jeśli dołożymy do programu możliwość zmiany nie tylko samych danych, ale także ich rodzaju i dodawanie nowych typów przechowywanych informacji. Oczywiście można dodać do aplikacji kod, który na podstawie np. innych plików opisujących dane będzie „rozpoznawać”, jakie informacje są zapisane, i na tej podstawie dopiero będzie je same odczytywał (informacje opisujące inne informacje nazywane są „metadanymi”). Staje się to jednak niezwykle skomplikowane. Jak widać zatem, im bardziej wymagający jest program, tym bardziej złożona staje się obsługa danych i więcej pracy wymaga jego stworzenie, zarówno jeśli chodzi o stopień skomplikowania sposobu, w jaki trzymane są dane, jak i mechanizmy blokujące część informacji na czas ich modyfikacji oraz pozwalające na jednoczesny dostęp do nich wielu użytkownikom. Pisanie za każdym razem tak dużej części kodu byłoby nieefektywne i bardzo wydłużałoby proces tworzenia oprogramowania. Właśnie to ostatnie jest jednym z głównych powodów, dla których pomiędzy bazą danych (rozumianą jako zbiór informacji z określonym sposobem jego przechowywania) a programem wprowadza się dodatkowe „coś”, co rozwiązuje przestawione problemy. Tym czymś jest system zarządzania bazą danych, w skrócie SZBD (rysunek 5)

Często dla uproszczenia także nazywany bazą danych, tak jak miało to miejsce w zwrocie „baza danych PostgreSQL pozwala na...”, gdzie mowa o konkretnym takim systemie. Równie często spotyka się określenie „silnik bazy danych”. System zarządzania bazą danych przejmuje na siebie wiele obowiązków związanych z „technicznymi” aspektami przechowywania danych między innymi to, w jaki sposób są one trzymane na dysku. Dzięki temu, iż większość obecnie stosowanych silników bazy danych może działać jako oprogramowanie serwera możliwym staje się udostępnienie bazy dla komputerów na całym świecie. SZBD przejmuje na siebie także odpowiedzialność za blokowanie informacji na czas ich modyfikacji, by uniknąć konfliktów oraz pozwala dokonać wyszukiwania danych po stronie serwera, przez co do aplikacji trafiają tylko odfiltrowane dane, które są dla niej istotne. Program chcąc odczytać bądź zmodyfikować dane, musi korzystać z pośrednictwa SZBD. Aby to jednak było możliwe, SZDB i aplikacja muszą móc się „porozumieć”, co symbolizowane jest na rysunku przez przecinające się elipsy, lecz – jak widać – do danych bezpośredni dostęp ma jedynie SZBD.

Różne sposoby patrzenia na dane – ogólnie o modelach danych