praca_magisterska/pytania/odpowiedzi/28-fazy-ewolucji-modelu-danych.md

Pytanie 28: Fazy ewolucji modelu danych

Pytanie

"Omówić typowe fazy ewolucji modelu danych i pożądane cechy modelu w każdej z faz."

Przedmiot: MODA (Modelowanie Danych)

---

📚 Odpowiedź główna

1. Przegląd faz ewolucji

┌─────────────────────────────────────────────────────────────────┐
│                   FAZY EWOLUCJI MODELU DANYCH                   │
│                                                                 │
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────┐       │
│  │  KONCEPTUALNY │ → │   LOGICZNY   │ → │   FIZYCZNY   │       │
│  │    (CDM)      │   │    (LDM)     │   │    (PDM)     │       │
│  └──────────────┘   └──────────────┘   └──────────────┘       │
│         │                  │                  │                │
│         ↓                  ↓                  ↓                │
│    CO przechowujemy   JAK strukturyzujemy  JAK implementujemy │
│    (biznes)           (logika)            (technologia)       │
└─────────────────────────────────────────────────────────────────┘

---

2. Model konceptualny (Conceptual Data Model)

Cel

• Zrozumienie dziedziny biznesowej
• Komunikacja z interesariuszami (nietechnicznymi)
• Identyfikacja głównych encji i relacji

Cechy pożądane

Cecha	Opis
Prostota	Zrozumiały dla biznesu
Abstrakcja	Brak szczegółów technicznych
Kompletność	Wszystkie koncepcje biznesowe
Poprawność	Zgodność z rzeczywistością biznesową

Notacja i narzędzia

Diagram ERD (Entity-Relationship) - uproszczony:

    ┌──────────┐         ┌──────────┐
    │ KLIENT   │ składa  │ZAMÓWIENIE│
    │          │ 1────M  │          │
    └──────────┘         └──────────┘
                              │
                              │ zawiera
                              │ M
                              │
                         ┌──────────┐
                         │ PRODUKT  │
                         │          │
                         └──────────┘

Brak typów danych, kluczy, atrybutów szczegółowych!
Tylko encje i relacje (z krotnością).

Przykład

Model konceptualny dla e-commerce:

Encje: Klient, Zamówienie, Produkt, Kategoria, Dostawca, Płatność

Relacje:
- Klient składa Zamówienia (1:N)
- Zamówienie zawiera Produkty (M:N)
- Produkt należy do Kategorii (N:1)
- Dostawca dostarcza Produkty (M:N)
- Zamówienie ma Płatność (1:1)

---

3. Model logiczny (Logical Data Model)

Cel

• Szczegółowa struktura danych
• Normalizacja
• Definicja atrybutów i kluczy
• Niezależność od DBMS

Cechy pożądane

Cecha	Opis
Normalizacja	Minimum 3NF, często BCNF
Integralność	PK, FK, constraints
Kompletność atrybutów	Wszystkie pola z typami logicznymi
Dokumentacja	Słownik danych
Niezależność	Bez szczegółów implementacji

Notacja

ERD szczegółowy (np. Crow's Foot):

┌────────────────────────┐       ┌────────────────────────┐
│ KLIENT                 │       │ ZAMÓWIENIE             │
├────────────────────────┤       ├────────────────────────┤
│ PK klient_id           │───┐   │ PK zamowienie_id       │
│    imie                │   │   │ FK klient_id           │──┐
│    nazwisko            │   └──<│    data_zamowienia     │  │
│    email (UNIQUE)      │       │    status              │  │
│    data_rejestracji    │       │    suma                │  │
└────────────────────────┘       └────────────────────────┘  │
                                          │                   │
                                          │ 1                 │
                                          │                   │
                                 ┌────────────────────────┐  │
                                 │ POZYCJA_ZAMOWIENIA     │  │
                                 ├────────────────────────┤  │
                                 │ PK pozycja_id          │  │
                                 │ FK zamowienie_id       │──┘
                                 │ FK produkt_id          │
                                 │    ilosc               │
                                 │    cena_jednostkowa    │
                                 └────────────────────────┘

Normalizacja

1NF: Atomowe wartości, brak powtarzających się grup
2NF: 1NF + brak częściowych zależności od PK
3NF: 2NF + brak zależności przechodnich
BCNF: Każdy determinant jest kluczem kandydującym

---

4. Model fizyczny (Physical Data Model)

Cel

• Implementacja w konkretnym DBMS
• Optymalizacja wydajności
• Definicja indeksów, partycji, storage

Cechy pożądane

Cecha	Opis
Wydajność	Indeksy, denormalizacja gdzie potrzeba
Specyfika DBMS	Typy danych, funkcje specyficzne
Skalowalność	Partycjonowanie, sharding
Bezpieczeństwo	Uprawnienia, szyfrowanie
Backup/Recovery	Strategia archiwizacji

Przykład DDL (PostgreSQL)

CREATE TABLE klient (
    klient_id SERIAL PRIMARY KEY,
    imie VARCHAR(50) NOT NULL,
    nazwisko VARCHAR(50) NOT NULL,
    email VARCHAR(100) UNIQUE NOT NULL,
    data_rejestracji TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    status klient_status DEFAULT 'aktywny'
);

CREATE INDEX idx_klient_email ON klient(email);
CREATE INDEX idx_klient_nazwisko ON klient(nazwisko);

CREATE TABLE zamowienie (
    zamowienie_id SERIAL PRIMARY KEY,
    klient_id INTEGER NOT NULL REFERENCES klient(klient_id),
    data_zamowienia TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    status zamowienie_status DEFAULT 'nowe',
    suma DECIMAL(10,2) NOT NULL CHECK (suma >= 0)
) PARTITION BY RANGE (data_zamowienia);

CREATE TABLE zamowienie_2024 PARTITION OF zamowienie
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

Optymalizacje fizyczne

Technika	Zastosowanie
Indeksy	B-tree, Hash, GIN, GiST
Partycjonowanie	Range, List, Hash
Denormalizacja	Materialized views, redundancja
Kompresja	Kolumnowe storage
Clustering	Fizyczne uporządkowanie

---

5. Porównanie faz

Aspekt	Konceptualny	Logiczny	Fizyczny
Odbiorcy	Biznes	Analitycy, projektanci	DBA, developerzy
Abstrakcja	Wysoka	Średnia	Niska
DBMS	Niezależny	Niezależny	Specyficzny
Typy danych	Brak	Logiczne	Natywne DBMS
Indeksy	Brak	Brak	Tak
Normalizacja	Nie	Tak (3NF+)	Może być denorm.

---

6. Transformacje między fazami

┌──────────────────────────────────────────────────────────────────┐
│ Konceptualny → Logiczny:                                         │
│ • Encje → Tabele                                                 │
│ • Atrybuty → Kolumny                                             │
│ • Relacje M:N → Tabele asocjacyjne                              │
│ • Generalizacja → Opcje: single table, class table, concrete    │
│ • Normalizacja do 3NF/BCNF                                       │
├──────────────────────────────────────────────────────────────────┤
│ Logiczny → Fizyczny:                                             │
│ • Typy logiczne → Typy DBMS (VARCHAR, INTEGER, TIMESTAMP...)    │
│ • Dodanie indeksów (na FK, WHERE, ORDER BY)                     │
│ • Partycjonowanie dużych tabel                                   │
│ • Kontrolowana denormalizacja (wydajność)                        │
│ • Tablespace, storage parameters                                 │
└──────────────────────────────────────────────────────────────────┘

---

7. Ewolucja w czasie (produkcja)

Wersja 1.0 → 1.1 → 2.0 → ...

Narzędzia migracji:
- Flyway
- Liquibase
- Django migrations
- Alembic (SQLAlchemy)

Zasady:
✓ Backward compatible (add, nie remove)
✓ Expand-Contract pattern
✓ Zero-downtime migrations
✓ Rollback plan

---

🧠 Mnemoniki

"C-L-F = Concept, Logic, Physical":

Trzy fazy ewolucji modelu

"Konceptualny = CO, Logiczny = JAK, Fizyczny = GDZIE":

• CO przechowujemy (biznes)
• JAK strukturyzujemy (normalizacja)
• GDZIE i jak wydajnie (DBMS)

"3NF w logicznym, denorm w fizycznym":

Normalizuj w logicznym, optymalizuj w fizycznym

---

❓ Pytania dodatkowe

Q1: "Kiedy pominąć fazę konceptualną?"

Odpowiedź: Małe projekty, proste dziedziny, doświadczony zespół znający domenę. Ale ryzyko: brak wspólnego zrozumienia z biznesem, pominięte wymagania.

Q2: "Jak dokumentować model danych?"

Odpowiedź: ERD (draw.io, Lucidchart, dbdiagram.io), słownik danych (Data Dictionary), komentarze w DDL, wiki z opisem biznesowym, generowana dokumentacja (SchemaSpy).

Q3: "Co to jest reverse engineering modelu?"

Odpowiedź: Generowanie modelu logicznego/konceptualnego z istniejącej bazy (fizycznej). Narzędzia: ERwin, PowerDesigner, DBeaver. Przydatne dla legacy systems.

---

🎯 Kluczowe punkty

1. Konceptualny: Biznes, encje, relacje, bez technologii
2. Logiczny: Normalizacja, PK/FK, typy logiczne
3. Fizyczny: DBMS-specific, indeksy, partycje
4. Transformacja: Konceptualny → Logiczny → Fizyczny
5. Ewolucja: Migracje, backward compatibility

---

📖 Źródła

1. Teorey et al. - "Database Modeling and Design"
2. Silberschatz - "Database System Concepts"
3. Ambler - "Agile Database Techniques"