2 Adatbázis típusok részletesen
A következőkben részletesen megvizsgáljuk az öt legfontosabb adatbázis-típust.
2.1 Lapos (flat file) adatbázisok
A lapos adatbázis a legegyszerűbb forma: egyetlen táblázat, amelyben sorok és oszlopok vannak. Minden sor egy rekord, minden oszlop egy mező. Nincs kapcsolat más táblákkal.
2.1.1 Példa: Levéltári fondlista
| Fond | Megnevezés | Kezdő_év | Záró_év | Terjedelem_ifm |
|---|---|---|---|---|
| XIX-A-1 | Miniszterelnökség | 1944 | 1949 | 79 |
| XIX-I-1 | Vallás- és Közoktatásügyi Minisztérium | 1945 | 1951 | 447 |
| XXVIII-M-19 | Magyar Nők Demokratikus Szövetsége | 1948 | 1955 | 1.6 |
2.1.2 Mikor működik jól?
- Kis adatmennyiség
- Nincs kapcsolat az adatok között
- Egyszerű lista
- Ideiglenes adatgyűjtés
2.1.3 A redundancia problémája
Ha kutatók látogatásait is nyilvántartjuk:
| Kutató_név | Telefon | Dátum | Fond | |
|---|---|---|---|---|
| Kovács János | kovacs@elte.hu | 06-1-123 | 2024-11-05 | XXV-1 |
| Kovács János | kovacs@elte.hu | 06-1-123 | 2024-11-05 | XXV-2 |
| Kovács János | kovacs@elte.hu | 06-1-123 | 2024-11-12 | XXV-1 |
Kovács János adatai háromszor ismétlődnek! Ez redundancia.
Problémák: - Helypazarlás (3x tárolás) - Frissítés nehéz (3 helyen kell módosítani) - Inkonzisztencia veszély (elfelejtünk egy helyet)
2.2 Hierarchikus adatbázisok
2.2.1 Történeti háttér
Az 1960-as években születtek az első hierarchikus adatbázisok, amelyeket a NASA Apollo programjában használtak. A legismertebb: IBM IMS (1968).
2.2.2 A fa struktúra
A hierarchikus adatbázis egy fa struktúra: - Van egy gyökér (root) - Minden elemnek egy szülője van (kivéve a gyökér) - Egy szülőnek több gyereke lehet
2.2.3 Levéltári példa: Fond-hierarchia
LEVÉLTÁR (gyökér)
│
├─── MNL Országos Levéltára
│ │
│ ├─── XIX fondfőcsoport
│ │ │
│ │ ├─── XIX-A-83 fond
│ │ └─── XIX-A-84 fond
│ │
│ └─── XX fondfőcsoport
│
└─── Budapest Főváros Levéltára
│
└─── IV. fondfőcsoport2.2.4 Előnyök
- Természetes modellezés: Sok dolog eleve hierarchikus (szervezet, földrajz, levéltári rendszer)
- Gyors navigáció: Szülőtől gyerekhez, gyerektől szülőhöz
- Adatintegritás: Gyerek mindig tartozik valahova
- Hatékony tárolás: Nincs redundancia 1:N kapcsolatoknál
2.2.5 Korlátok
- Merev struktúra: Új szint beszúrása nagyon nehéz
- Sok-sok kapcsolatok: Csak duplikálással megoldható
- Procedurális lekérdezések: Pontosan le kell írni a navigációt
- Nincs szabvány: Minden rendszer más
2.2.6 Miért vesztették el népszerűségüket?
Az 1980-as évekre a relációs modell (SQL) kiszorította őket, mert: - Rugalmasabb - Egyszerűbb lekérdezések (SQL) - Szabványos nyelv
Ma XML adatbázisok formájában élnek tovább: - TEI XML kódolt történeti szövegek - EAD (Encoded Archival Description) levéltári leírások - Konfigurációs fájlok —
2.3 Hálós (network) adatbázisok
2.3.1 A sok-sok kapcsolat problémája
A hierarchikus modell nem tudja kezelni a sok-sok kapcsolatokat. Példa: - Egy színész több előadásban játszik - Egy előadásban több színész játszik
2.3.2 CODASYL hálós modell (1969)
A CODASYL (Conference on Data Systems Languages) bizottság 1969-ben fejlesztette ki a hálós modellt, amely lehetővé teszi, hogy egy elemnek több szülője is legyen.
2.3.3 Működés
- Rekord típusok: Entitások (pl. KUTATÓK, TÉMÁK, FONDOK)
- Set típusok: Kapcsolatok (pl. KUTATÓ-TÉMÁK set)
- Owner-member: Tulajdonos és tagok
2.3.4 Példa: Kutatási hálózat
KUTATÓK ←──[KUTATÓ-TÉMÁK set]──→ TÉMÁK
↓ ↓
[KUTATÓ-FONDOK set] [TÉMA-FONDOK set]
↓ ↓
FONDOK ←─────────────────────────→ FONDOK2.4 Relációs adatbázisok
1970-ben Edgar F. Codd, IBM kutató publikálta a relációs modellt.
2.4.1 Mi az újdonság?
Táblázatok és kapcsolatok: - Adatok táblákban (relációkban) - Táblák matematikailag definiált kapcsolatokkal - SQL - deklaratív lekérdező nyelv - ACID tulajdonságok (megbízhatóság)
2.4.2 Kulcsok
Elsődleges kulcs (Primary Key - PK): - Egyedileg azonosít minden rekordot - Nem lehet NULL - Nem változik
Idegen kulcs (Foreign Key - FK): - Másik tábla PK-jára hivatkozik - Létrehoz kapcsolatot
2.4.3 Példa: Kutatószolgálat
KUTATÓK tábla:
| Kutató_ID (PK) | Név | |
|---|---|---|
| 1 | Kovács János | kovacs@elte.hu |
| 2 | Nagy Anna | nagy@ppk.hu |
LÁTOGATÁSOK tábla:
| Látogatás_ID (PK) | Kutató_ID (FK) | Dátum |
|---|---|---|
| 101 | 1 | 2024-11-05 |
| 102 | 1 | 2024-11-12 |
| 103 | 2 | 2024-11-06 |
A Kutató_ID a LÁTOGATÁSOK táblában idegen kulcs - hivatkozik a KUTATÓK tábla elsődleges kulcsára.
2.4.4 Kapcsolat típusok
1:N (Egy a többhöz): - Egy kutató → Több látogatás - Egy fond → Több doboz
N:M (Sok a sokhoz): - Egy látogatás → Több fond - Egy fond → Több látogatás - Megoldás: Kapcsoló tábla (KÉRÉSEK)
1:1 (Egy az egyhez): - Ritka - Egy munkatárs → Egy bejelentkezési fiók
2.4.5 Normalizálás - Az adatredundancia elleni harc
A normalizálás az a folyamat, amellyel az adatbázis struktúráját úgy alakítjuk, hogy minimalizáljuk a redundanciát (ismétlődést) és maximalizáljuk az adatintegritást.
A normálformák olyan szabályrendszerek, amelyek fokozatosan szigorúbbak. Minden magasabb normálforma tartalmazza az alacsonyabb szintűek követelményeit is. A gyakorlatban általában a 3. normálforma (3NF) elég - a magasabb szintek ritkán szükségesek.
2.4.5.1 1. Normálforma (1NF) - Atomicitás
Szabály: Minden mező atomi (tovább nem bontható) értéket tartalmaz, és egyetlen értéket tartalmaz.
Mit TILOS: - Lista egy cellában - Több érték vesszővel elválasztva - Összetett adatok
Rossz példa (NEM 1NF):
| Kutató_ID | Név | Kutatási_témák |
|---|---|---|
| 1 | Kovács János | Kádár-kor, Színház, 1956-os forradalom |
| 2 | Nagy Anna | Levéltártan, Digitalizálás |
Probléma: A “Kutatási_témák” mező három értéket tartalmaz egy cellában! Ez nem atomi.
Miért rossz? - Nem tudsz keresni: “Kik kutatják a színházat?” → Nehéz szűrni - Nem tudsz rendezni témák szerint - Nem tudsz statisztikát készíteni: “Hány kutató kutatja a Kádár-kort?”
Jó példa (1NF-ben):
Megoldás 1: Több sor
| Kutató_ID | Név | Kutatási_téma |
|---|---|---|
| 1 | Kovács János | Kádár-kor |
| 1 | Kovács János | Színház |
| 1 | Kovács János | 1956-os forradalom |
| 2 | Nagy Anna | Levéltártan |
| 2 | Nagy Anna | Digitalizálás |
Most minden mező egyetlen értéket tartalmaz!
Megoldás 2: Külön tábla (jobb!)
KUTATÓK tábla:
| Kutató_ID | Név |
|---|---|
| 1 | Kovács János |
| 2 | Nagy Anna |
KUTATÁSI_TÉMÁK tábla:
| Téma_ID | Téma_neve |
|---|---|
| 1 | Kádár-kor |
| 2 | Színház |
| 3 | 1956-os forradalom |
| 4 | Levéltártan |
| 5 | Digitalizálás |
KUTATÓ_TÉMÁK kapcsoló tábla:
| Kutató_ID | Téma_ID |
|---|---|
| 1 | 1 |
| 1 | 2 |
| 1 | 3 |
| 2 | 4 |
| 2 | 5 |
Ez tiszta 1NF és könnyen kezelhető!
2.4.6 Referenciális integritás
Garantálja, hogy idegen kulcsok mindig létező elsődleges kulcsra hivatkoznak.
CASCADE DELETE: Ha törlöd a szülőt, törlődnek a gyerekek is
CASCADE UPDATE: Ha megváltozik a PK, frissülnek az FK-k
2.5 NoSQL adatbázisok - A 21. század kihívásai
2.5.1 A Big Data kihívás: Miért kellett valami új? (2000-es évek)
Az ezredforduló után az internet robbanásszerű növekedésével olyan új típusú problémák jelentek meg, amelyekre a hagyományos relációs adatbázisok nem adtak jó választ.
A Google problémája: - Több milliárd weboldal indexelése naponta - Keresési lekérdezések másodpercenként: milliók - Adatmennyiség: több petabyte (1 petabyte = 1.000.000 GB!) - Relációs adatbázis erre: összeomlik
A Facebook problémája: - Több mint 2 milliárd felhasználó - Minden felhasználónak más-más adatstruktúrája (ki kitölt mit a profilban) - Posztok, fotók, kommentek, reakciók: trilliónyi rekord - Kapcsolatok: ki kivel barátkozik, ki mit lájkol - hatalmas hálózat - Relációs adatbázis erre: túl lassú, nem skálázható
Az Amazon problémája: - Több százmillió termék - Minden terméknek különböző tulajdonságai (könyv: ISBN, szerző; TV: képátló, felbontás; ruha: méret, szín) - Vásárlások, kosár, ajánlások: folyamatos írás-olvasás - Black Friday: másodpercenként százezernyi vásárlás - Relációs adatbázis erre: merev séma, lassú
A közös problémák:
- Extrém nagy adatmennyiség (Volume)
- Petabyte vagy akár exabyte (1.000.000.000 GB) méretű adatok
- Egyetlen szerveren lehetetlen tárolni
- Több ezer szerverre kell elosztani
- Nagyon gyors írás (Velocity)
- Másodpercenként százezernyi vagy milliónyi új rekord (tweet, log, szenzor adat)
- A relációs adatbázisok ACID tranzakciói túl lassúak
- Kell a “gyors és piszkos” írás - ellenőrzés később
- Változó struktúra (Variety)
- Nem minden felhasználó tölti ki ugyanazokat a mezőket
- Új mezők jelennek meg naponta (pl. új termékattribútumok)
- Relációs fix séma: minden táblamódosításhoz ALTER TABLE kell → lassú
- Kell a rugalmas séma: minden dokumentum lehet más
- Horizontális skálázhatóság
- Relációs adatbázisok vertikálisan skáláznak: veszünk egy nagyobb szervert (több RAM, gyorsabb CPU)
- De: van felső határ (a legnagyobb szerver is véges), és nagyon drága
- Kell a horizontális skálázás: több olcsó szervert adunk hozzá, és eloszlatjuk az adatokat
- “Divide and conquer” - oszd meg és uralkodj
2.5.2 Mi az a NoSQL?
A NoSQL kifejezés Not Only SQL-t jelent - nem azt, hogy “nincs SQL”, hanem hogy “nem csak SQL, hanem más megközelítések is léteznek”.
Fontos: A NoSQL nem egyetlen technológia vagy termék, hanem egy gyűjtőfogalom különböző, nem-relációs adatbázis-modellekre. Közös bennük: - Elutasítják a relációs modell merevségét - Rugalmasságot preferálnak konzisztencia helyett - Horizontális skálázásra optimalizáltak
Közös jellemzők:
- Nincs fix séma (Schema-less vagy Schema-free)
- Minden rekord/dokumentum különböző mezőkkel rendelkezhet
- Új mezők hozzáadása: egyszerűen beírjuk, nincs ALTER TABLE
- Rugalmas, gyors fejlesztés
- Horizontális skálázás (Scale-out)
- Könnyű több szervert hozzáadni
- Adatok automatikusan elosztódnak (sharding, partitioning)
- Több olcsó szerver > egy drága szerver
- Eventual consistency (Végül konzisztens)
- Nem garantált az azonnali konzisztencia
- Kis késleltetéssel (milliszekundumok/másodpercek) minden szerver frissül
- “Végül” minden adat egyezni fog
- Nagy teljesítmény nagy terhelésnél
- Optimalizáltak gyors írásra/olvasásra
- Nincs bonyolult JOIN, nincs komplex tranzakció → gyorsabb
- Specializáltság
- Minden NoSQL típus más-más problémára optimalizált
- Nincs univerzális megoldás (mint a relációs)
2.5.3 NoSQL típusok részletesen
A NoSQL adatbázisokat négy fő kategóriába soroljuk:
2.5.3.1 1. Dokumentum-orientált adatbázisok (pl. MongoDB)
Alapelv: Az adatok JSON vagy XML dokumentumokban tárolva, ahol minden dokumentum egy önálló egység.
Előnyök:
- Rugalmas séma: Minden kutató dokumentuma különböző lehet
- Van akinek van “publikációk_száma”, van akinek nincs
- Van aki több nyelvet beszél, van aki egyet
- Új mezőt bármikor hozzáadhatunk
- Beágyazott struktúrák: Az
intézményéskutatási_területekbeágyazva- Nincs szükség JOIN-ra
- Egy lekérdezés mindent megad
- Gyors olvasás: Minden adat egy dokumentumban
- Nem kell 3-4 táblát összekapcsolni
- Egy keresés = teljes adathalmaz
- Természetes JSON: Webalkalmazásokkal könnyen integrálható
- Frontend JavaScript közvetlenül használja
- API válaszok JSON formátumban
Hátrányok:
- Nincs JOIN: Kapcsolatok nehezen kezelhetők
- Ha a kutató több fondot kutat, azokat ismételni kell, vagy külön táblában
- Redundancia: Ha ugyanaz az intézmény adat sok kutatónál szerepel
- “ELTE BTK” címe duplikálva van
- Frissítés: minden kutatónál külön kell módosítani
- Nincs séma-validáció: Bárki bármit beírhat
- Egyik dokumentumban
születési_év: 1985(szám) - Másikban
születési_év: "ezerkilencszáznyolcvanöt"(szöveg) - Nincs automatikus ellenőrzés
- Egyik dokumentumban
Mikor használjuk?
Content Management rendszerek (CMS) - Blog bejegyzések: különböző mezők (cím, szöveg, képek, videók, címkék) - Termékleírások: minden termék különböző attribútumokkal
Katalógusok - Könyv: ISBN, szerző, kiadó - Film: rendező, szereplők, időtartam - Ruha: méret, szín, anyag - Mindegyik más mezők → MongoDB rugalmasan kezeli
Felhasználói profilok - Közösségi média: mindenki mást tölt ki a profiljában - Nincs fix séma
Levéltári példa:
Digitális born-digital iratok metaadatai MongoDB-ben:
## Összefoglalás
| Típus | Mikor ideális? | Fő előny | Fő hátrány |
|-------|----------------|----------|------------|
| Lapos | Kis lista | Egyszerű | Redundancia |
| Hierarchikus | Fa struktúra | Gyors navigáció | Merev |
| Hálós | *(elavult)* | Sok-sok | Bonyolult |
| Relációs | Legtöbb eset | SQL, integritás | Vertikális skálázás |
| NoSQL | Big Data | Skálázható | Nincs ACID |Levéltári munka: 90% esetben relációs (Access, MySQL)
2.6 Ellenőrző kérdések
- Mi a redundancia? Miért probléma?
- Milyen előnyei vannak a hierarchikus modellnek?
- Miért vesztették el népszerűségüket a hálós adatbázisok?
- Mi volt Edgar F. Codd forradalmi ötlete?
- Mi a különbség az elsődleges és idegen kulcs között?
- Milyen kapcsolat típusokat vannak?
- Mit jelent a normalizálás?
- Mi az a NoSQL? Mikor használjuk?
- Milyen NoSQL típusokat vannak
- Melyik adatbázis-típust választana egy levéltári fondnyilvántartáshoz? Miért?