Adatbázis kezelés 1. előadás

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

2. 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

3. Tematika I. • Bevezetés • 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)

4. Tematika II. • SQL-2 • 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, casestruktú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

5. 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

6. 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

7. 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

8. (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

9. (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

10. Tranzakciók • Atomossá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

11. (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

12. (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

13. (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

14. 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

15. 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 (StructuredQueryLanguage) • 1990-re meghatározóvá váltak a relációs adatbázisok • Folyamatos fejlődés különböző igények szerint

16. „Új” technológiák • Google például már nem relációs alapon dolgozik • Bigtable (A distributedstoragesystemforstructureddata) • 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..

17. Adatmodellek • Adat struktúrája • 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

18. 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.

19. 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)

20. 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

21. 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

22. Köszönjük a figyelmet!