praca_magisterska/pytania/odpowiedzi/04-baza-danych-fundament.md

Pytanie 4: Baza danych jako fundament systemów informatycznych

Pytanie

"Dlaczego baza danych stanowi dobry fundament do budowy wielu systemów informatycznych?"

Przedmiot: BD2 (Bazy Danych 2)

---

📚 Odpowiedź główna

Wprowadzenie

Baza danych to centralny komponent większości systemów informatycznych, ponieważ zapewnia:

• Trwałe przechowywanie danych
• Współbieżny dostęp
• Integralność i spójność
• Niezależność danych od aplikacji

---

1. Kluczowe właściwości baz danych (ACID)

Transakcyjność - gwarancje ACID

Właściwość	Opis	Znaczenie
Atomicity (Atomowość)	Transakcja wykonuje się w całości lub wcale	Brak częściowych zmian
Consistency (Spójność)	Dane przechodzą z jednego spójnego stanu w drugi	Reguły biznesowe zawsze spełnione
Isolation (Izolacja)	Równoległe transakcje nie widzą swoich zmian	Brak efektów ubocznych
Durability (Trwałość)	Zatwierdzone zmiany przetrwają awarie	Bezpieczeństwo danych

Przykład znaczenia ACID

Przelew bankowy:

BEGIN TRANSACTION;
    UPDATE Konta SET saldo = saldo - 1000 WHERE id = 1;  -- Odejmij
    UPDATE Konta SET saldo = saldo + 1000 WHERE id = 2;  -- Dodaj
COMMIT;

Bez ACID:

• Awaria po pierwszym UPDATE = utrata pieniędzy (brak atomowości)
• Saldo < 0 mimo ograniczenia (brak spójności)
• Inna transakcja widzi stan pośredni (brak izolacji)
• Po zatwierdzeniu dane giną (brak trwałości)

---

2. Niezależność danych

Trójpoziomowa architektura ANSI/SPARC

┌─────────────────────────────────────────┐
│     Poziom zewnętrzny (widoki)          │  ← Aplikacje widzą różne "okna"
├─────────────────────────────────────────┤
│     Poziom konceptualny (logiczny)      │  ← Struktura logiczna danych
├─────────────────────────────────────────┤
│     Poziom wewnętrzny (fizyczny)        │  ← Sposób przechowywania
└─────────────────────────────────────────┘

Rodzaje niezależności

1. Niezależność fizyczna

Zmiana sposobu przechowywania (indeksy, partycjonowanie, kompresja) nie wpływa na aplikacje.

Przykład: Dodanie indeksu przyspiesza zapytania bez zmiany kodu aplikacji.

2. Niezależność logiczna

Zmiana struktury logicznej (dodanie kolumn, widoków) minimalizuje wpływ na aplikacje.

Przykład: Podział tabeli na dwie + widok łączący = stare aplikacje działają bez zmian.

---

3. Współbieżność i wielodostęp

Problem współbieżności

Wiele aplikacji/użytkowników jednocześnie korzysta z tych samych danych.

Mechanizmy kontroli współbieżności

Mechanizm	Opis	Zastosowanie
Blokady (Locks)	Pesymistyczne - blokuj przed dostępem	Wysokie konflikty
MVCC	Optymistyczne - wersjonowanie	Dużo odczytów
Timestamp Ordering	Szeregowanie po czasie	Systemy rozproszone
Snapshot Isolation	Izolacja migawkowa	Analityka

Poziomy izolacji (SQL Standard)

Poziom	Dirty Read	Non-repeatable Read	Phantom Read
READ UNCOMMITTED	Możliwy	Możliwy	Możliwy
READ COMMITTED	Niemożliwy	Możliwy	Możliwy
REPEATABLE READ	Niemożliwy	Niemożliwy	Możliwy
SERIALIZABLE	Niemożliwy	Niemożliwy	Niemożliwy

---

4. Integralność danych

Mechanizmy wymuszania integralności

1. Ograniczenia deklaratywne

CREATE TABLE Zamowienia (
    id INT PRIMARY KEY,                          -- Klucz główny
    klient_id INT NOT NULL,                      -- NOT NULL
    data DATE DEFAULT CURRENT_DATE,              -- Wartość domyślna
    kwota DECIMAL(10,2) CHECK (kwota > 0),       -- Warunek CHECK
    FOREIGN KEY (klient_id) REFERENCES Klienci(id)  -- Klucz obcy
);

2. Wyzwalacze (Triggers)

CREATE TRIGGER sprawdz_saldo
BEFORE UPDATE ON Konta
FOR EACH ROW
BEGIN
    IF NEW.saldo < 0 THEN
        SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Brak środków';
    END IF;
END;

3. Procedury składowane

Logika biznesowa w bazie = jednolite reguły dla wszystkich aplikacji.

---

5. Wydajność i optymalizacja

Optymalizator zapytań

SZBD automatycznie:

1. Analizuje zapytanie (parsing)
2. Generuje plany wykonania (alternatywy)
3. Szacuje koszty (statystyki)
4. Wybiera najlepszy plan (optymalizacja)

Mechanizmy wydajności

Mechanizm	Funkcja
Indeksy	Szybkie wyszukiwanie (B-tree, Hash, GiST)
Buforowanie	Cache często używanych danych
Partycjonowanie	Podział dużych tabel
Materializowane widoki	Prekompilowane złączenia
Query cache	Cache wyników zapytań

---

6. Bezpieczeństwo

Wielopoziomowe zabezpieczenia

┌─────────────────────────────────────────┐
│  Autoryzacja (GRANT/REVOKE)             │
├─────────────────────────────────────────┤
│  Autentykacja (użytkownicy, role)       │
├─────────────────────────────────────────┤
│  Szyfrowanie (TDE, SSL/TLS)             │
├─────────────────────────────────────────┤
│  Audyt (logi, śledzenie zmian)          │
└─────────────────────────────────────────┘

Kontrola dostępu

-- Tworzenie roli
CREATE ROLE analityk;
GRANT SELECT ON Sprzedaz TO analityk;

-- Przypisanie użytkownika
GRANT analityk TO jan_kowalski;

-- Widok ograniczający dane
CREATE VIEW MojeZamowienia AS
    SELECT * FROM Zamowienia WHERE sprzedawca = CURRENT_USER;

---

7. Skalowalność i dostępność

Skalowanie pionowe (Scale-up)

• Więcej RAM, szybsze CPU, dyski SSD
• Proste, ale ograniczone

Skalowanie poziome (Scale-out)

• Replikacja - kopie do odczytu
• Sharding - podział danych między serwery
• Klastry - wysoka dostępność

Wysoka dostępność (HA)

Rozwiązanie	Opis
Replikacja Master-Slave	Odczyty z replik
Replikacja Master-Master	Zapisy na wielu węzłach
Failover automatyczny	Przełączanie przy awarii
Backup/Recovery	Odtwarzanie po katastrofie

---

8. Standaryzacja i ekosystem

SQL jako lingua franca

• Standardowy język - SQL:2016, SQL:2023
• Przenośność - kod działa na różnych SZBD
• Narzędzia - uniwersalne IDE, ORM, ETL

Bogaty ekosystem

• ORM (Hibernate, Entity Framework, SQLAlchemy)
• Narzędzia migracji (Flyway, Liquibase)
• Monitorowanie (Grafana, Datadog)
• Backup (pg_dump, mysqldump, RMAN)

---

9. Różnorodność modeli danych

Jeden fundament, wiele modeli

Model	SZBD	Zastosowanie
Relacyjny	PostgreSQL, MySQL, Oracle	OLTP, dane strukturalne
Dokumentowy	MongoDB, CouchDB	JSON, elastyczne schematy
Klucz-wartość	Redis, DynamoDB	Cache, sesje
Grafowy	Neo4j, Amazon Neptune	Relacje, sieci społeczne
Kolumnowy	Cassandra, ClickHouse	Analityka, time-series
Czasowy	TimescaleDB, InfluxDB	IoT, metryki

Polyglot Persistence

Nowoczesne systemy często używają wielu baz - każda do swojego celu.

---

📊 Porównanie: z bazą vs bez bazy

Aspekt	Bez bazy (pliki)	Z bazą danych
Współbieżność	Ręczne blokady	Automatyczna
Integralność	W kodzie aplikacji	Deklaratywna
Zapytania	Parsowanie plików	SQL/indeksy
Backup	Kopiowanie plików	Spójne snapshoty
Skalowanie	Trudne	Replikacja/sharding
Bezpieczeństwo	OS-level	Granularne uprawnienia

---

🧠 Mnemoniki

"ACID" - już sam w sobie mnemonik:

• Atomowość - All or nothing
• Consistency - Correct always
• Isolation - Independent transactions
• Durability - Data survives

"BDSM" dla korzyści bazy danych:

• Bezpieczeństwo (autoryzacja, audyt)
• Dane niezależne (od aplikacji)
• Skalowalność (replikacja, sharding)
• Mechanizmy integralności (FK, CHECK)

"CIA" dla bezpieczeństwa:

• Confidentiality - kto może czytać
• Integrity - kto może zmieniać
• Availability - dostępność usługi

"CRUD = baza umie wszystko":

• Create - INSERT
• Read - SELECT
• Update - UPDATE
• Delete - DELETE

---

❓ Możliwe pytania dodatkowe (follow-up)

Q1: "Wyjaśnij różnicę między blokadami pesymistycznymi a optymistycznymi"

Odpowiedź:

Cecha	Pesymistyczne	Optymistyczne
Założenie	Konflikty są częste	Konflikty są rzadkie
Działanie	Blokuj przed dostępem	Sprawdź przy zatwierdzeniu
Implementacja	Locki (S, X, IS, IX)	Wersjonowanie (MVCC)
Zaleta	Gwarancja sukcesu	Brak blokowania
Wada	Deadlocki możliwe	Rollback przy konflikcie
Zastosowanie	Dużo zapisów	Dużo odczytów

MVCC (Multi-Version Concurrency Control):

• Każdy zapis tworzy nową wersję wiersza
• Odczyt widzi "migawkę" z początku transakcji
• Brak blokowania między odczytem a zapisem

---

Q2: "Co to jest CAP theorem i jak wpływa na projektowanie?"

Odpowiedź:

Twierdzenie CAP (Brewer, 2000): W systemie rozproszonym można mieć co najwyżej 2 z 3 właściwości:

• Consistency - wszystkie węzły widzą te same dane
• Availability - każde żądanie otrzymuje odpowiedź
• Partition tolerance - system działa mimo podziału sieci

Konsekwencje:

Wybór	Poświęca	Przykład
CA	Partition tolerance	Tradycyjne RDBMS (single node)
CP	Availability	MongoDB, HBase
AP	Consistency	Cassandra, DynamoDB

Praktyka: Systemy rozproszone MUSZĄ być P (partycje się zdarzają), więc wybór to C vs A.

---

Q3: "Kiedy baza relacyjna, a kiedy NoSQL?"

Odpowiedź:

Kryteria	Relacyjna (SQL)	NoSQL
Struktura danych	Stała, dobrze zdefiniowana	Zmienna, elastyczna
Transakcje	ACID wymagane	BASE akceptowalne
Relacje	Złożone złączenia	Proste lub brak
Skala	Pionowa (scale-up)	Pozioma (scale-out)
Przykłady	Finanse, ERP, CRM	Social media, IoT, gaming

BASE (dla NoSQL):

• Basically Available - zazwyczaj dostępny
• Soft state - stan może być nieaktualny
• Eventually consistent - ostatecznie spójny

---

Q4: "Jak baza danych wspiera architekturę mikroserwisów?"

Odpowiedź:

Wzorzec: Database per Service

• Każdy mikroserwis ma własną bazę
• Brak bezpośredniego dostępu do cudzych danych
• Komunikacja przez API/eventy

Wyzwania:

1. Rozproszone transakcje → Saga pattern
2. Spójność danych → Event sourcing, CQRS
3. Złączenia → Denormalizacja, API composition

Rozwiązania:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Zamówienia │     │   Klienci   │     │  Produkty   │
│  (MongoDB)  │     │ (PostgreSQL)│     │   (Redis)   │
└─────────────┘     └─────────────┘     └─────────────┘
       ↓                  ↓                   ↓
       └──────── Message Broker (Kafka) ─────┘

---

Q5: "Co to jest indeks i jakie są rodzaje?"

Odpowiedź:

Indeks = struktura danych przyspieszająca wyszukiwanie.

Typ	Struktura	Zastosowanie
B-tree	Zbalansowane drzewo	Ogólne, zakresy, sortowanie
Hash	Tablica mieszająca	Równość (=), bardzo szybki
GiST	Drzewo uogólnione	Geodane, full-text
GIN	Inverted index	Tablice, JSONB, full-text
BRIN	Block Range Index	Duże tabele, dane posortowane

Kompromis:

• Indeks przyspiesza SELECT
• Indeks spowalnia INSERT/UPDATE/DELETE
• Indeks zajmuje miejsce na dysku

---

Q6: "Wyjaśnij pojęcie normalizacji vs denormalizacji w kontekście wydajności"

Odpowiedź:

Aspekt	Normalizacja	Denormalizacja
Redundancja	Minimalna	Celowa
Złączenia	Wymagane	Minimalne
Zapisy	Szybkie	Wolniejsze
Odczyty	Wolniejsze	Szybsze
Spójność	Łatwa	Trudniejsza
Zastosowanie	OLTP	OLAP, cache

Praktyka:

• OLTP (transakcje) → 3NF/BCNF
• OLAP (analityka) → Star/Snowflake schema
• Cache → Pełna denormalizacja (Redis)

---

🎯 Kluczowe punkty do zapamiętania

1. ACID = gwarancje transakcyjne fundamentem niezawodności
2. Niezależność danych = zmiany struktury nie psują aplikacji
3. Współbieżność = tysiące użytkowników jednocześnie
4. Integralność = reguły biznesowe wymuszone w bazie
5. Optymalizator = automatyczne przyspieszanie zapytań
6. Bezpieczeństwo = wielopoziomowa kontrola dostępu
7. Skalowalność = od jednego serwera do klastra globalnego

---

📖 Źródła do pogłębienia

1. Date, C.J. - "An Introduction to Database Systems"
2. Kleppmann, M. - "Designing Data-Intensive Applications"
3. Garcia-Molina, Ullman, Widom - "Database Systems: The Complete Book"
4. Hellerstein, Stonebraker - "Readings in Database Systems" (Red Book)