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

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

Hochrein ÁkosHodosy Gábor

TudnivalókFélév során elméleti és gyakorlati órák is

Feladatok megoldása eleinte papíron: Relációs AlgebraKésőbb gépen: SQL

Számonkérés: írásbeli vizsgaElmélet és gyakorlat nagyjából egyenlő aránybanFélév végére a leadott anyag tükrében részletesebben

megadjuk a várható feladatokatElérhetőségek

hoch.akos@gmail.comhodosyg@gmail.comDiák elérhetőek lesznek: http://hakos.web.elte.hu

Tematika I.1. 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ő

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

3. Oracle alapok (gépes óra)Oracle RDBMS rövid bemutatása: felépítés, felhasználói

objektumok, adattípusokGrafikus felületen táblák létrehozása, adatok bevitele, törléseKényszerek (elsődleges/idegen kulcs, check)

Tematika II.4. 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

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

6. SQL-4 Beágyazott lekérdezések Data dictionary

Tematika III.Lesz még:

OptimalizálásokFizikai fájlszervezésTranzakció kezelésPL/SQLAsatbázis kezelés nagyvállalati környezetben

Adatbázisrendszerek világaInformatikában már szinte mindenhol

Webes rendszerekCégek üzleti adataiKutatási területeken információk rendszerezése

Nagy mennyiségű adat hosszú időn keresztüli tárolásaMi ebbe a pláne?

SemmiAmi lényegessé teszi: ABKR

Adatbázis Kezelő RendszerHatékony eszköz, ami lehetővé tesz minden szükséges

kezelési funkciót az adatokonEgészen bonyolult rendszerek lehetnek

ABKR - Elvárások1. Rendelkezésre álljon egy Adatdefiníciós nyelv -

DDL2. és egy Adatmanipulációs nyelv – DML3. Lehetőség legyen nagyon nagy mennyiségű adat

hatékony tárolására és kezelése hosszú távon is4. Tartósság – rendszer helyreállíthatóság5. Konkurencia kezelés – több (sok) tranzakció

kiszolgálása egy időben

(1.) DDLLétre tudjunk hozni új

AdatbázisokatTáblákat, nézeteket

Ezeknek a sémáját és struktúráját megfelelő pontossággal megadhassukTípusokKulcsokMegszorítások

SQL-ben legjellemzőbb: CREATE, ALTER

(2.) DMLAz adatbázis sémáját nem befolyásoljaMeglévő adatok megfelelő pontossággal történő

LekérdezéseMódosítása: Beszúrás, Frissítés, Törlés

SQL-ben: SELECT, INSERT, UPDATE, DELETEDML utasítások tranzakciókba csoportosulnakTranzakciók feldolgozása alapján garantálható a

Konkurencia kezelésTartósság

TranzakciókAtomossá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 seKonzisztencia

Az adatbázis konzisztens állapotból konzisztensbe kell vinnieElkü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ásaA hangsúly a hatékonyságon és a hosszú távú

tároláson vanDML utasítások minél hatékonyabb

végrehajtásaHatékonyság elősegítésére eszközök

Adatbázis rendszer tárkezelőjeLekérdezés fordító Algebrai optimalizálás Indexelés

(4.) TartósságBiztosítani kell a helyreállíthatóságot

MeghibásodásokRongálások

Hiba esetén mindig egy konzisztens állapotot akarunk visszaállítani

Elsődleges eszköz: NaplózásTranzakciók műveleteiről napló bejegyzések először pufferbeMajd egyeztetés az adatbázis állapotával és ha jó írás lemezreA tranzakciók atomosságára figyelni kell -> visszaállítási pontokTö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.) KonkurenciaTö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őreZárolásokkal megoldottÚjabb probléma merül fel: holtpontokA 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 modellA 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ákHatékony lekérdező nyelv alkalmazható: Relációs

algebra Jelentős mértékben növeli az adatbázis programozók

hatékonyságátRelációs algebra -> SQL (Structured Query Language)1990-re meghatározóvá váltak a relációs adatbázisokFolyamatos fejlődés különböző igények szerint

„Új” technológiákGoogle 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álPetabyte szintű adattárolásra és rengeteg gép közötti

kommunikációra terveztékAmazon: rugalmasságra és elérhetőségre törekvő

rendszerSimple DB/DynamoKevés adminisztrátori feladat (elvileg)Földrajzilag elosztott servereken másolatokat tárol az

adatokrólHátrányaik is vannak persze..

Adatmodellek1. Adat struktúrája

Alacsonyabb szinten mint az adatmodellek

2. Adaton végezhető műveletek Műveletek véges halmazával adjuk meg Általában lekérdezés és módosító műveletek

3. Adatra tett megszorítások Korlátozhatjuk, hogy milyen adatokat engedünk meg Egészen összetettek is lehetnek

Jellemző modellek:1. Relációs2. Félig strukturált -> rugalmasabb, pl. XML

Relációs adatmodellTáblás szerkezet (tábla = reláció)A táblákon értelmezve használjuk a relációs

algebra műveleteitPl.

név város telefon email

Annabelle Griffeth

Austin 123456789 ag@ag.com

Fernando Vong Portland

987654321 fv@fv.com

AttribútumokA reláció oszlopainak adnak nevetÁltalában megadják az oszlopban tárolt adatok

jelentését isJelö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)

SorokA 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

komponenseEgy sor a táblától függetlenül történő felírása:

Komponensek a séma szerinti sorrendbenPl.: (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 kulcsCélja, hogy egy sort egyértelműen azonosítani

tudjunk bizonyos attribútumok alapjánEgyik leggyakrabban használt megszorításEgy táblára adhatjuk megLehet egy vagy több attribútumSzokás egy külön ID attribútum bevezetése, ha

nem egyértelmű a tárolt adatok alapjánPélda táblában: e-mail cím egy jó elsődleges kulcs

Köszönjük a figyelmet!