Adatbázis kezelés 1. előadás Hochrein Ákos Hodosy Gábor

Tudnivalók Félév során elméleti és gyakorlati órák is Feladatok megoldása eleinte papíron: Relációs Algebra Később gépen: SQL Számonkérés: írásbeli vizsga Elmélet és gyakorlat nagyjából egyenlő arányban Félév végére a leadott anyag tükrében részletesebben megadjuk a várható feladatokat Elérhetőségek hoch.akos@gmail.com hodosyg@gmail.com Diák elérhetőek lesznek: http://hakos.web.elte.hu

Tematika I. Bevezetés Relációs algebra /SQL-1(gyakrolati) Adatbázis kezelés alapjai, motivációk Adatbázis kezelők felépítése, feladatai, típusai Relációs adatmodell bevezető Relációs algebra /SQL-1(gyakrolati) Relációs adatbázis kezelők matematikai alapjai Relációs algebra alapműveletei, illesztések SQL-re való áttérés relációs algebrából Oracle alapok (gépes óra) Oracle RDBMS rövid bemutatása: felépítés, felhasználói objektumok, adattípusok Grafikus felületen táblák létrehozása, adatok bevitele, törlése Kényszerek (elsődleges/idegen kulcs, check)

Tematika II. SQL-2 SQL-3 SQL-4 DDL: tábladefiníciók létrehozása, módosítása, törlése; kényszerek menedzselése DML: adatok beszúrása, módosítása, törlése, lekérdezése Szekvenciák használata SQL-3 Aggregátumok, rendezések, illesztések, halmazműveletek, case struktúra Fontosabb beépített függvények: dátumkezelés, konverzió, szövegkezelés, NULL Függvények SQL-4 Beágyazott lekérdezések Data dictionary

Tematika III. Lesz még: Optimalizálások Fizikai fájlszervezés Tranzakció kezelés PL/SQL Asatbázis kezelés nagyvállalati környezetben

Adatbázisrendszerek világa Informatikában már szinte mindenhol Webes rendszerek Cégek üzleti adatai Kutatási területeken információk rendszerezése Nagy mennyiségű adat hosszú időn keresztüli tárolása Mi ebbe a pláne? Semmi Ami lényegessé teszi: ABKR Adatbázis Kezelő Rendszer Hatékony eszköz, ami lehetővé tesz minden szükséges kezelési funkciót az adatokon Egészen bonyolult rendszerek lehetnek

ABKR - Elvárások Rendelkezésre álljon egy Adatdefiníciós nyelv - DDL és egy Adatmanipulációs nyelv – DML Lehetőség legyen nagyon nagy mennyiségű adat hatékony tárolására és kezelése hosszú távon is Tartósság – rendszer helyreállíthatóság Konkurencia kezelés – több (sok) tranzakció kiszolgálása egy időben

(1.) DDL Létre tudjunk hozni új Adatbázisokat Táblákat, nézeteket Ezeknek a sémáját és struktúráját megfelelő pontossággal megadhassuk Típusok Kulcsok Megszorítások SQL-ben legjellemzőbb: CREATE, ALTER

(2.) DML Az adatbázis sémáját nem befolyásolja Meglévő adatok megfelelő pontossággal történő Lekérdezése Módosítása: Beszúrás, Frissítés, Törlés SQL-ben: SELECT, INSERT, UPDATE, DELETE DML utasítások tranzakciókba csoportosulnak Tranzakciók feldolgozása alapján garantálható a Konkurencia kezelés Tartósság

Tranzakciók Atomosság Konzisztencia Elkülönítés Tartósság Több DML utasításból állhat egy tranzakció, de végrehajtását tekintve egy feladatnak kell tekinteni Vagy az egész fusson le vagy egyik része se Konzisztencia Az adatbázis konzisztens állapotból konzisztensbe kell vinnie Elkülönítés Minden tranzakciónak úgy kell lefutnia, mintha nem lenne rajta kívül másik aktív tranzakció Tartósság Lefutott tranzakció eredménye mindenképpen érvényesítésre kerüljön az adatbázisban Semmilyen körülmények közt nem veszhet el

(3.) Nagy mennyiségű adat tárolása A hangsúly a hatékonyságon és a hosszú távú tároláson van DML utasítások minél hatékonyabb végrehajtása Hatékonyság elősegítésére eszközök Adatbázis rendszer tárkezelője Lekérdezés fordító Algebrai optimalizálás Indexelés

(4.) Tartósság Biztosítani kell a helyreállíthatóságot Meghibásodások Rongálások Hiba esetén mindig egy konzisztens állapotot akarunk visszaállítani Elsődleges eszköz: Naplózás Tranzakciók műveleteiről napló bejegyzések először pufferbe Majd egyeztetés az adatbázis állapotával és ha jó írás lemezre A tranzakciók atomosságára figyelni kell -> visszaállítási pontok Többféle naplózási technika van, lényeg hogy bármikor történik a hiba vissza kell tudni állítani egy konzisztens állapotot

(5.) Konkurencia Több felhasználó egy időben lehet, hogy ugyanazt az adatot akarja lekérdezni/módosítani -> biztosítani kell az adatok konzisztenciáját Azaz figyelni és szabályozni kell a felhasználók módosításait, hogy ne jöhessenek létre hibás adatok Tranzakciókkal szembeni elvárásokból (elkülöníthetőség) következik, hogy szükség van egy ütemezőre Zárolásokkal megoldott Újabb probléma merül fel: holtpontok A holtpontfeloldás is a tranzakció kezelő feladata

Történelmi áttekintés I. Első adatbázisok 60-as években fájlkezelő rendszerekből (1.): csak könyvtárszerkezet megadása (2.): nincs konkrét lekérdező nyelv (3.): részben eleget tesz-> nagy mennyiségű adat tárolható ugyan, a hatékony elérés viszont nem garantált (nincs is lekérdező nyelv) (4.): biztonsági mentésekkel részben eleget tehet a tartósságnak (5.): konkurens hozzáférés nem megoldott Először banki rendszereknél és vállalati nyilvántartásoknál Kezdeti modellekkel nagyon körülményes volt a munka, az adatokat a tárolásuk szerint kellett ábrázolni (pl fa vagy gráf) Nem támogattak magas szintű lekérdező nyelvet

Történelmi áttekintés II. 1970: Ted Codd -> Relációs modell A felhasználó felé az adatokat táblázatokban (relációkban) Így nem kell törődni az adatok belső tárolásával Ettől még lehetnek összetett struktúrák Hatékony lekérdező nyelv alkalmazható: Relációs algebra Jelentős mértékben növeli az adatbázis programozók hatékonyságát Relációs algebra -> SQL (Structured Query Language) 1990-re meghatározóvá váltak a relációs adatbázisok Folyamatos fejlődés különböző igények szerint

„Új” technológiák Google például már nem relációs alapon dolgozik Bigtable (A distributed storage system for structured data) Több dimenziós adat összekapcsolásokat használ Petabyte szintű adattárolásra és rengeteg gép közötti kommunikációra tervezték Amazon: rugalmasságra és elérhetőségre törekvő rendszer Simple DB/Dynamo Kevés adminisztrátori feladat (elvileg) Földrajzilag elosztott servereken másolatokat tárol az adatokról Hátrányaik is vannak persze..

Adatmodellek Adat struktúrája Adaton végezhető műveletek Alacsonyabb szinten mint az adatmodellek Adaton végezhető műveletek Műveletek véges halmazával adjuk meg Általában lekérdezés és módosító műveletek Adatra tett megszorítások Korlátozhatjuk, hogy milyen adatokat engedünk meg Egészen összetettek is lehetnek Jellemző modellek: Relációs Félig strukturált -> rugalmasabb, pl. XML

Relációs adatmodell Táblás szerkezet (tábla = reláció) A táblákon értelmezve használjuk a relációs algebra műveleteit Pl. név város telefon email Annabelle Griffeth Austin 123456789 ag@ag.com Fernando Vong Portland 987654321 fv@fv.com

Attribútumok A reláció oszlopainak adnak nevet Általában megadják az oszlopban tárolt adatok jelentését is Jelölés: Jellemzően az attribútum neveket kis betűvel kezdjük, a tábla nevet nagy betűvel Absztrakt szinten való tárgyaláskor minden nagybetű Séma: A reláció neve és az attribútumai zárójelben Az attribútumok halmazt alkotnak nem listát, de amikor a reláció adatairól beszélünk meg kell határozni egy sorrendet Séma megadása az előzőek szerint: Ügyfelek(név, város, telefon, email) vagy R(A, B, C)

Sorok A reláció attribútumain kívüli soraiban tároljuk a konkrét adatokat (ezeket nevezzük csak sornak) Minden sornak minden attribútumhoz van egy komponense Egy sor a táblától függetlenül történő felírása: Komponensek a séma szerinti sorrendben Pl.: (Annabelle Griffeth, Austin, 123456789, ag@ag.com) Meg kell adni referenciaként a séma leírását, hogy tudjuk attribútumokhoz kötni a komponenseket

Elsődleges kulcs Célja, hogy egy sort egyértelműen azonosítani tudjunk bizonyos attribútumok alapján Egyik leggyakrabban használt megszorítás Egy táblára adhatjuk meg Lehet egy vagy több attribútum Szokás egy külön ID attribútum bevezetése, ha nem egyértelmű a tárolt adatok alapján Példa táblában: e-mail cím egy jó elsődleges kulcs

Köszönjük a figyelmet!