ITBlog

1. przed erą baz danych: problemy systemów plikowych

Zanim powstały współczesne systemy bazodanowe, dane były zarządzane za pomocą systemów opartych na plikach (ang. file-based systems). Każda aplikacja miała własny zestaw plików z danymi, a ich struktura była zdefiniowana bezpośrednio w kodzie programu. Takie podejście, choć proste w założeniach, generowało lawinę problemów w miarę wzrostu złożoności i ilości danych.

Główne wady systemów plikowych:

• Redundancja i niespójność danych: Te same informacje (np. adres klienta) były powielane w wielu plikach należących do różnych aplikacji (np. system fakturowania, system CRM). Zmiana adresu w jednym miejscu nie gwarantowała aktualizacji w innych, prowadząc do niespójności.
• Trudności w dostępie do danych: Aby uzyskać nowy raport, trzeba było napisać dedykowany program, który odczytywał i przetwarzał odpowiednie pliki. Nie istniały uniwersalne języki zapytań.
• Brak niezależności danych: Struktura danych była ściśle powiązana z aplikacją. Zmiana formatu pliku (np. dodanie nowego pola) wymagała modyfikacji i rekompilacji wszystkich programów, które z niego korzystały.
• Problemy z współbieżnością: Kontrola jednoczesnego dostępu wielu użytkowników do tych samych danych była niezwykle trudna do zaimplementowania i często prowadziła do konfliktów i uszkodzenia danych.
• Kwestie bezpieczeństwa i integralności: Wymuszanie reguł (np. że pensja pracownika musi być liczbą dodatnią) musiało być implementowane w każdej aplikacji z osobna, co było nieefektywne i podatne na błędy.

Te ograniczenia stały się impulsem do poszukiwania nowego paradygmatu, który scentralizowałby zarządzanie danymi i oddzielił je od logiki aplikacji.

2. pionierskie modele nawigacyjne: hierarchiczny i sieciowy

Model hierarchiczny: struktura drzewa

Pierwszym komercyjnym sukcesem był model hierarchiczny, zaimplementowany w systemie IBM IMS (1968). Dane organizowane są w strukturę drzewiastą, gdzie każdy rekord (segment) ma dokładnie jednego „rodzica”, z wyjątkiem korzenia. Relacje są wyłącznie typu jeden-do-wielu (1:N).

Schemat - Model Hierarchiczny (Struktura firmy):

      [ Firma ]
          |
      [ Dział IT ]
      /     |     \
[Proj. A] [Proj. B] [Proj. C]
             |
         [ Zadanie 1 ]
         [ Zadanie 2 ]

Zalety: Model ten był bardzo wydajny dla zapytań podążających wzdłuż predefiniowanych ścieżek (np. „znajdź wszystkie zadania w projekcie B”).
Wady: Reprezentacja relacji wiele-do-wielu (M:N) była niemożliwa bez duplikacji danych. Na przykład, jeśli jedno zadanie należało do dwóch projektów, trzeba było je zapisać dwukrotnie, co prowadziło do redundancji i problemów ze spójnością.

Model sieciowy: uogólniony graf

Model sieciowy, zaproponowany przez CODASYL (1971), był ewolucyjnym krokiem naprzód. Zezwalał, aby rekord mógł mieć wielu „rodziców”, co naturalnie modelowało relacje wiele-do-wielu (M:N). Struktura przypominała graf, a powiązania definiowano za pomocą tzw. zbiorów (ang. sets).

Schemat - Model Sieciowy (System uniwersytecki):

[ Student: Jan ] <----> [ Kurs: Bazy Danych ] <----> [ Wykładowca: prof. X ]
      ^   \                      /   ^
      |    \                    /    |
      |     `--> [ Kurs: AI ] <--'    |
      `------------------------------'

Zalety: Większa elastyczność i redukcja redundancji w porównaniu do modelu hierarchicznego.
Wspólna wada obu modeli: Oba modele były nawigacyjne i proceduralne. Programista musiał znać fizyczną strukturę danych i pisać kod, który krok po kroku „nawigował” po wskaźnikach od rekordu do rekordu. To powodowało brak niezależności danych – zmiana struktury bazy wymagała zmiany kodu aplikacji.

3. rewolucja relacyjna: deklaratywność i niezależność danych

Przełom nastąpił w 1970 roku dzięki pracy Edgara F. Codda, który zaproponował model relacyjny. Jego fundamentem nie były fizyczne wskaźniki, lecz solidna teoria matematyczna (algebra relacyjna i teoria zbiorów). Dane są w nim postrzegane jako zbiór tabel, zwanych relacjami.

Kluczowe koncepcje modelu relacyjnego:

• Relacja (Tabela): Dwuwymiarowa struktura składająca się z wierszy i kolumn.
• Krotka (Wiersz/Rekord): Reprezentuje pojedynczy obiekt lub fakt.
• Atrybut (Kolumna): Nazwana właściwość obiektu.
• Klucz główny: Atrybut (lub zbiór atrybutów), który unikalnie identyfikuje każdą krotkę w relacji.
• Klucz obcy: Atrybut w jednej relacji, który odwołuje się do klucza głównego w innej, tworząc w ten sposób powiązanie.

Największą innowacją było wprowadzenie deklaratywnych języków zapytań, z których najpopularniejszym stał się SQL (Structured Query Language). Użytkownik określa co chce uzyskać, a nie jak to zrobić. System zarządzania bazą danych (RDBMS) sam optymalizuje i wykonuje zapytanie.

Przykład w SQL: połączenie danych

-- Tabela Pracownicy
CREATE TABLE Pracownicy (
    ID_Pracownika INT PRIMARY KEY,
    Nazwisko VARCHAR(100),
    ID_Dzialu_FK INT
);

-- Tabela Dzialy
CREATE TABLE Dzialy (
    ID_Dzialu INT PRIMARY KEY,
    Nazwa_Dzialu VARCHAR(100)
);

-- Zapytanie deklaratywne: "Pokaż nazwiska pracowników i nazwy ich działów"
SELECT P.Nazwisko, D.Nazwa_Dzialu
FROM Pracownicy P
JOIN Dzialy D ON P.ID_Dzialu_FK = D.ID_Dzialu;
            

Model relacyjny zapewnił pełną niezależność danych i rygorystyczne gwarancje spójności dzięki transakcjom ACID (Atomicity, Consistency, Isolation, Durability). Stał się dominującym standardem na dziesięciolecia.

4. era big data i narodziny nosql

Na początku XXI wieku, wraz z eksplozją danych internetowych (Big Data), pojawiły się nowe wyzwania: ogromna skala, potrzeba elastyczności schematu i obsługa systemów rozproszonych. W odpowiedzi na te potrzeby powstały bazy NoSQL (ang. Not Only SQL).

Kluczową cechą systemów NoSQL jest skalowalność horyzontalna (dodawanie kolejnych serwerów), w przeciwieństwie do skalowalności wertykalnej (zwiększanie mocy jednego serwera), typowej dla RDBMS. Często rezygnują one z rygorystycznej spójności na rzecz wyższej dostępności i odporności na awarie, co opisuje twierdzenie CAP.

Twierdzenie CAP (consistency, availability, partition tolerance)

Stwierdza, że w systemie rozproszonym niemożliwe jest jednoczesne zagwarantowanie wszystkich trzech właściwości:

• Spójność (Consistency): Każdy odczyt zwraca najnowszy zapis lub błąd.
• Dostępność (Availability): Każde żądanie otrzymuje odpowiedź (niebędącą błędem), ale bez gwarancji, że zawiera najnowszy zapis.
• Tolerancja na partycjonowanie (Partition Tolerance): System działa nadal pomimo utraty komunikacji między niektórymi węzłami.

Systemy rozproszone muszą tolerować partycjonowanie, więc wybór sprowadza się do kompromisu między spójnością a dostępnością (CP lub AP). Wiele baz NoSQL wybiera dostępność, oferując model spójności ostatecznej (ang. eventual consistency).

Główne typy baz nosql

5. podsumowanie: wybór właściwego narzędzia

Ewolucja baz danych to fascynująca podróż od prostych plików do wysoce wyspecjalizowanych systemów. Dziś wybór technologii zależy od konkretnego problemu do rozwiązania.

Współczesne architektury często wykorzystują podejście hybrydowe, znane jako Polyglot Persistence, gdzie różne typy baz danych są używane do różnych zadań w ramach jednego systemu, aby w pełni wykorzystać ich unikalne zalety.