ADATBÁZISKEZELÉS 1. Struktúrált adatok kezelése adatbáziskezelővel és anélkül. (Redundancia – adatok, funkcionalitás – konkurrens hozzáférés, tranzakciók, fizikai adattárolás/ adatfüggetlenség, adatvédelem, adatbiztonság, alapfogalmak: DBMS, DB..) . Adatainkat tárolhatjuk rendszerezetten fájlrendszerben is, ám ez számos hátulütővel járhat: - egy információt redundánsan szerepeltetünk (például a dolgozóknál feltüntetjük az adott osztály címét, ahol dolgozik, és így ez a cím többször szerepel a rendszerben) - a fentiekből következően a funkcionalitás is redundáns lesz (a cím megváltoztatásakor minden sorban külön át kell azt írni) - a fájloknak különböző a formátuma (az egyik részleg .pdf-ben, a másik .doc-ban küldi el alkalmazottjai listáját) - minden új feladatra, lekérdezésre külön programot kell írni - az adat izolációja: különböző fájlokban, formátumokban tároljuk az egyébként összetartozó adatokat - integrity constrains: nehezebb a kezelésük, utólag hozzáadni, vagy megváltoztatni őket nagyon nehéz, elvesznek a kódban (például egy érték nem lehet negatív, vagy NULL, legyen unique, kulcsok, check, stb…) Atomicity: adataink inkonzisztensek lesznek részleges frissítés miatt (a pénzt csak levonjuk, nem adjuk hozzá a másik számlához) Konkurrens hozzáférés: egyszerre több felhasználó akarja használni az adatot, ami szintén inkonzisztenciához vezethet (egyszerre akarnak 50 egységet ugyanazon számláról levonni, a számláról cask 50 tűnik el, de ők kapnak 50-50-et) Adatvédelem: fájlban történő adattárolás esetén nehéz megoldani, hogy a felhasználó bizonyos sorokat lásson, másokat pedig nem. Adattárolásunkank 3 absztrakciós szintje van: fizikai – a memóriában hogyan tároljuk az adatot; logikai – az adatok milyenek és milyen kapcsolatban vannak; külső megjelenés – amit ebből a felhasználó érzékel. Schema: az adatbázis logikai leírása, mint a típusdefiníció. Instance: a “változó”, séma pillanatnyi értéke. Fizikai adatfüggetlenség: az adat tárolásának fizikáját, hogy hogyan tároljuk, megváltoztathatjuk anélkül, hogy a logikaiba bele kellene nyúlnunk. Az alkalmazások a logikai sémától függenek. Adatbiztonság: (durability) ne léphessen fel adatvesztés, például egy áramszünet esetén. Ezért minden művelet elvégzésekor a háttértáron tároljuk a változtatásokat, (in memory adatbázisoknál ez kérdéses!), log file-ok alkalmazása. Ha adatbáziskezelőt használunk, gyakorlatilag az összes fent említett hiba kiküszöbölhető.
DBMS: Database Management System. Egy kényelmes és hatékony környezet, melyben egy adott vállalat adatait kezelhetjük. Programok együttese az adatok eléréséhez és kezeléséhez. Nyelve a DML. DB: Database. Maga az adatbázis, az adatok együttese. Nyelve a DDL. DBS =DBMS+DB Database system. 2. Relációs model (adatbázis séma, tábla séma, attribútumok, constraint-ek, elsődleges kulcs, külső kulcs) Data models: eszközök együttese, melyekkel leírhatjuk az adatot magát, azok kapcsolatát, a constraineket és a szemantikát. Fajtái: relációs, entity-relációs, objektum-elvű (object-oriented, -relational), semistructured (XML), más, régebbi modellek (network, hierarchical). Schema: az adatbázis logikai leírása, mint a típusdefiníció. Milyen kapcsolatban és milyen adatokat tárolunk. (Relációs sémák jó halmaza). Instance: a “változó”, séma pillanatnyi értéke. Relációs model “Táblás” módszer. Adottak attribútumok (tulajdonságok, a tábla oszlopai), ezek (rész)halmaza a relációs séma. Ezek értékei (instances) a tuple-ök, azaz a tábla egy-egy sora. A table sémáját tehát a benne tárolt adatok típusa határozza meg. A sorok rendezetlenek. Attribútumok: A megengedett értékek együttese az attribútum értelmezési tartománya (domain). Ezek lehetőleg legyenek atomiak, azaz tovább nem bontható egységekből álljanak. (Első normal forma!). A NULL érték minden attribútum értelmezési tartományában benne van (ami sok függvénynél komplikációt okoz). SQL-ben: char, varchar, number, float, real, bool sbt… Constrain: Az attribútum értékeire megszorításokat tehetünk. Unique – az érték cask egyszer fordulhat elő a táblában (a primary key ilyen). Not NULL – az adott attribútumnak mindenképpen kell értéket adnunk. CHECK – feltételt adhatunk meg, amivel értékek közés szoríthatjuk például a domaint. Primary key, foreig key. Kulcsok: Szuperkulcs: attribútumhalmaz, mely képes egyértelműen azonosítani a reláció (tábla) sorait. Candidate key: egy szuperkulcs candidate-key, ha minimális, azaz nincs olyan részhalmaza, ami szintén szuperkulcs, vagy nála kevesebb attribútumból álló másik kulcs. Primary key: egy kijelölt candidate key, amit ténylegesen a sorok megkülönböztetésére fogunk használni. Foreign key: táblák közötti kapcsolatok leírására használjuk őket. A referencing tábla értékeinek meg kell jelennie a referred tábla értékei között.
3. SQL alapok (szabványosítás, deklaratív megközelítés, DDL és egyszerűbb DML parancsok, beleértve a join-okat és a GROUP BY-t) SQL Adatok leírására, deklaratív, egyszerű lekérdező struktúra, egyéb egyszerű műveletek (set, nulla), aggregálás, egymásba ágyazott lekérdezések, adatbázis módosítása. IBM-> széles körben elterjedt, ANSI és ISO szabvány, szinte minden népszerű adatbáziskezelőnek ez az alapja. DBMS-ekben kisebb eltérések lehetnek (+/- funkciók), újabb verziókat lépésenként követik. Data Definition Language (DDL) Kapcsolatok leírása, a séma megszerkesztése. Adatbázis létrehozása/átalakítása (create table, alter table…add, drop table, modify, drop) Változók típusai (numeric, char…) Tábla mintákat hoz létre a DDL fordító, data dictionaryban tárolja: (metadata = adat az adatról) Adatbázis séma, megszorítások (PK, FK…) , hozzáférés (autentikáció), indexek, adatok fizikai tárolása Data Manipulation Language (DML) Query nyelv, az adatbázisban lévő adatokhoz való hozzáférés, módosítás (select … from … joinok, where, order by, having, insert into). Lekérdezés eredménye is egy reláció. Procedurális: felhasználó határozza meg, hogy milyen adatra van szüksége, és azt hogy HOGYAN szeretné megkapni. Declaratív: felhasználó határozza meg, hogy milyen adatra van szüksége, de NEM azt, hogy hogyan (Ide tartozik az sql). Azt a querybuilder határozza meg. Join-ok 2 relációból egy 3.-at ad vissza (azokat a sorokat ahol egyezés van bizonyos feltételek mellett (join condition)) pl: select name, course_id from instructor inner join teaches on instructor.ID = teaches.ID Vagy: select name, course_id from instructor, teaches where instructor.ID = teaches.ID Join types: Natural join: 2 tábla minden sorát összeegyezteti, az eredmény táblában csak azok a sorok maradnak meg (nem duplikálódnak) amelyeknek midnen attributuma megegyezik a 2 táblában outer join: Nincs infó veszteség, ahol nincs pár, ott null értékekkel tölti fel (left, right, full)
Inner join: csak azok maradnak meg az eredmény táblában, ahol egyezés van az adott feltétel alapján. Group by Csoportokat lehet létrehozni, és azokon aggregálni. select Deptno, avg(sal) from emp group by deptno having Deptno < 30; A where és having közötti különbség a futási sorrendben van, (where előbb, having később), ezért van, hogy egy aggregált értékre vonatkozó feltételt a having-ben adunk meg.
4.
Összetett SQL lekérdezések (halmazműveletek, outer join-ok, aggregálás – veszélyek: fan trap, chasm trap –, egymásba ágyazott lekérdezések, Windowing aggregates, NULL értékek) www.orafaq.com/node/55 (Windowing Aggregates) 1. Halmazműveletek (itt érdemes emlékezni arra, hogy a reláció valójában szinté egy halmaz: tkp. a tábla sorainak a halmaza): a. Kiválasztás: az alsó indexbe írt feltételt teljesítő elemeit kiválasztjuk az „r” relációnak: Jele: σA=>2(r) SQL szintaxis: SELECT * FROM r WHERE A>=2 b. Vetítés: Az alsó indexbe írt oszlop(ok) és az összes hozzájuk tartozó érték Jele: ΠA(r) SQL szintaxis: SELECT A FROM r c. Únió: „r”-be vagy „s”-be tartozó sorok: Jele: r ∪ s SQL szintaxis: SELECT
FROM UNION SELECT FROM ; UNION ALL: a duplikátumok is megjelennek. Megj1.: itt pl. az „r” az első, „s” a második lekérdezés eredménye, és a kettő únióját vesszük! A sima union költségesebb, hiszen kiszűrjük a duplikátumokat. Megj2.: Az egyes lekérdezések eredményeiben szerepelhetnek eltérő nevű attribútomok, de a típusaiknak rendre meg kell egyezniük. Ez a két megjegyzés a további két műveletre is igaz. d. Metszet: „r”-be és „s”-be is beletartozó sorok Jele: r ∩ s SQL szintaxis: SELECT FROM INTERSECT SELECT FROM ; INTERSECT ALL: a duplikátumok is megjelennek. e. Különbség: Azon sorok, amik benne vannak r-ben, de nincsenek benne s-ben Jele: r-s
SQL szintaxis: SELECT FROM MINUS SELECT FROM ; f. IN – az adott elem, tuple szerepel-e a halmazban g. EXIST – a lekérdezett halmaz nullelemű-e h. Descartes-szorzat: Jele: r×s Az „r”-beli összes sort összepárosítja az „s”-beli összes sorral minden lehetséges módon (az nem számít két különböző párnak, ha az „r”-beli sor van előbb, utána az „s”-beli, vagy ha az „s”-beli van előbb és utána az „r”-beli). SQL szintaxis: SELECT FROM r, s; i. Natural join: Innentől az „r” és „s” relációk helyett az őket reprezentáló táblákat tekintjük, így egyszerűbb a definiálás. Tekintsük az „r”-ben és „s”-ben közös tulajdonságokat, és vegyük r és s azon sorait, ahol a közös attribútumoknak megfelelő oszlopokban olyan értékek vannak, amik mind „r”ben, mind „s”-ben előfordulnak (az adott oszlopokban), és ezeket a sorokat Descartesszorozzuk össze. Azokat a sorokat, amelyek kimaradtak, lógó soroknak nevezzük. Ezeket eldobjuk (abban az értelemben, hogy nem szerepelnek eredményül kapott táblában). SQL szintaxis: SELECT FROM NATURAL JOIN ; j. Inner join: A natural joinhoz hasonló, de mi adjuk meg, hogy az „r” és „s” tábláknak melyek azok az oszlopai, amelyeket vizsgálunk. Azokat a sorokat, amelyekben a kijelölt oszlopban olyan érték van, ami megtalálható a másik reláció adott oszlopában is megtartjuk és Descartszorzatukat vesszük, így kapunk eredményül egy újabb táblát. k. SQL szintaxis: SELECT FROM INNER JOIN ON =; l. Outer join: Az inner jointól annyiban különbözik, hogy a lógó sorokat nem dobjuk el. i. left: A bal oldali tábla lógó soraihoz hozzáveszünk egy fiktív, csupa „null”-okból álló sort a jobb oldali táblából. A jobb oldali tábla lógó sorait eldobjuk. ii. right: A jobb oldali tábla lógó soraihoz veszünk hozzá egy fiktív, csupa „null”okból álló sort a bal oldali táblából. A bal oldali tábla lógó sorait eldobjuk iii. full: Mindkét tábla lógó soraihoz hozzáveszünk egy fiktív, csupa „null”-okból álló sort a másik táblából. SQL szintaxis: SELECT FROM LEFT/RIGHT/FULL OUTER JOIN ON =; 2. NULL értékek: Minden attribútum értelmezési tartományának eleme, az ismeretlen értéket jelzi, segítségével három értékű logika állítható elő, és sajátos aritmetika jellemzi (a szabályok abból következnek, hogy ha a NULL értékre mint egy ismeretlenre gondolunk, ami az attribútum értelmezési tartományának minden értékét felveheti, legyenek ezek számok, vagy igaz/hamis értékek). IGAZ∧NULL=NULL, HAMIS∧NULL=HAMIS, HAMIS∨NULL=NULL, IGAZ∨NULL=IGAZ, NULL negáltja NULL, 5+NULL=NULL, 0*NULL=0, stb.
3. Egymásba ágyazott lekérdezések: SELECT FROM WHERE ; Ha a lekérdezés FROM vagy WHERE részében egy másik lekérdezés van, akkor egymásba ágyazott lekérdezésről beszélünk. Ha a WHERE rész ilyen pl.: SELECT … FROM … WHERE 10>(SELECT … FROM … WHERE …), akkor ha nem egy értékkel tér vissza a beágyazott lekérdezés, hibát kapunk. Ekkor használható pl. az ALL, SOME, IN, NOT IN utasítások valamelyike a következő módon: SELECT … FROM … WHERE 10> SOME/ALL (SELECT … FROM … WHERE …), (azaz a lekérdezés ekkor egy oszloppal térhet vissza, és a feltétel igazra értékelődik ki, ha a visszakapott oszlopban minden/valahány elem kisebb, mint 10). Vagy: SELECT … FROM … WHERE 10 IN/NOT IN (SELECT … FROM … WHERE …), azaz igaz a feltétel, ha a beágyazott lekérdezés visszaadott oszlopában benne van a 10 (vagy nincs benne). 4. Aggregálás: Táblák sorozatos összekapcsolása, két gyakori hiba a fan trap (nem kívánt sorok lesznek az eredményül kapott táblában) és a chasm trap (sorokat vesztünk). Legegyszerűbb példával szemléltetni: lesz 3 tábla: tulajdonosok, autók és kutyák, kérdés, hogy melyik tulajnak hány autója és hány kutyája van:
Első lekérdezés: SELECT t.id as id_tulaj, a.id as id_autó, k.id as id_kutya FROM tulaj t INNER JOIN auto a ON t.id=a.tulaj_id INNER JOIN kutya k ON t.id=k.tulaj_id; Ekkor az első inner join-nál elvesztettük a Bélára vonatkozó sort, a másodiknál pedig mivel minden lehetséges sorpárt képeztünk, extra sorokhoz jutottunk, így az első tulajdonosnak négy autója és négy kutyája, van, a másodikra vonatkozóan nincs adat. A sorvesztés (chasm trap) kivédésére LEFT OUTER JOIN-t használunk, a sornyerés (fan trap) kivédésére pedig beágyazott lekérdezést: SELECT id_tulaj, auto_szam, count(k.id) as kutya_szam FROM (SELECT t.id as id_tulaj, count(a.id) auto_szam FROM tulaj t LEFT OUTER JOIN auto a ON t.id=a.tulaj_id GROUP BY t.id) b LEFT OUTER JOIN kutya k ON b.id_tulaj=k.tulaj_id GROUP BY id_tulaj, auto_szam; 5. Window aggregates: ezt példán keresztül mutatom be. A count, sum, min, max, avg ún. aggregáló függvények: adott egy tábla, GROUP BY-jal csoportosítjuk valamely attribútumai alapján a sorait, és a csoportokhoz hozzárendeljük a függvény által képzett értéket. Végeredményben a csoport több sora helyett egyetlen sort kapunk vissza a tulajdonságokkal, ami alapján adott sorok egy csoportba tartoztak és a count, stb. által kiszámolt értékkel (természetesen minden csoport több sora helyett csoportonként egy sort kapunk vissza). Pl. SELECT tulaj_id, COUNT(id) FROM kutyák GROUP BY tulaj_id; eredménye:
tulaj_id 1 2
COUNT(id) 2 1
Ezek az előbbi függvények GROUP BY nélkül használhatók ún. analitikus függvényként, ha a SELECT-ben pl. COUNT() OVER() szintaxissal használjuk. Ekkor nincs csoportosítás, képezzük az összes, a megadott attribútumnál szereplő érték átlagát/minimumát, darabszámát, pl.: SELECT tulaj_id COUNT(id) OVER() FROM kutyák; eredménye: tulaj_id COUNT… 1 3 1 3 2 3 A csoportosítás a PARTITION BY kifejezéssel itt is lehetséges: SELECT tulaj_id, COUNT(id) OVER(PARTITION BY tulaj_id) FROM kutyák; eredménye: tulaj_id COUNT… 1 2 1 2 2 1 És itt jön a lényeg: lehetséges egyfajta ablakozás, pl. kiszámoljuk a „kutyák” táblában az adott, és a megelőző egy sorhoz tartozó tulaj_id-k átlagát (a példa csak az illusztrácót szolgálja): SELECT id, AVG(tulaj_id) OVER(ORDER BY id ROWS 1 PRECEDING) FROM kutyák; id 1 2 3
AVG… 1 1 1,5
Itt fontos, hogy valami alapján rendezni kell. Az id alapján rendezett táblán végigfut egy kétsoros ablak: először vesszük az 1-es id-jú kutyához tartozó és az előző sorba tartozó tulaj_id-k átlagát (ilyen nincs, ez null, így az átla nem veszi figyelembe, az eredménye 1), majd a 2-es id-jú kutyához tartozó és az 1-es id-jú kutyához tartozó tulaj_id-k átlagát:(1+1)/2=1. Végül a 3-as id-jú kutyához és az előtte lévő, 2-es id-jú kutyához tartozó tulaj_id-k átlagát: (2+1)/2=1,5; Egyéb lehetőségek: beírhatók az OVER-be PARTITION BY, ekkor csak csoporton belül ablakozunk, vagy ROWS BETWEEN 3 PRECEDING AND 1 FOLLOWING (ekkor az adott, a 3-mal megelőző, és a következő sorba tartozó értékekkel operálunk), ROWS UNBOUNDED PRECEDING (az adott, és az összes előző sorral operálunk. Tehát GROUP BY eseteén egy csoporthoz egy sort kapunk vissza, windowing function-nál pedig minden sorhoz megkapjuk az aggregált értéket. 5. ER modellezés (egyed halmazok, kapcsolat halmazok, összetett és többértékű attribútumok, IS-A kapcsolat/öröklődés, notációs változatok, ER alapján relációs séma készítése -különböző kardinalitású kapcsolatok relációs átírása, IS-A kapcsolat relációs átírása; kiemelten fontos kérdések!!) ER= Entity – Relationship model= Egyed-kapcsolat adatmodell= logikai modell Az adatbázis logikai sémájának leírására használjuk.
1. Egyed halmaz: a. Egyed (entity, entitás): Az a valami, dolog, amit ismeretekkel akarunk leírni; valami ami van és megkülönbözhető. Az egyedek a valóság azon elemei, melyek számunkra valamilyen lényeges információt hordoznak, egymástól megkülönböztethetőek. Az egyed egy konkrét értékét egyed előfordulásnak, az előfordulások összességét pedig egyedhalmaznak nevezzük. b. Egyedhalmaz= hasonló egyedek halmaza. Az egyed halmaz aktuális „értéke” a hozzá tartozó egyedek listája c. Attribútum=az egyed halmaz egyedeinek tulajdonsága. Például az egyetem egyed esetén egyed előfordulás lehet az ELTE, egyedhalmaz pedig az összes egyetem; másfelől ha az egyed alatt az iskolatípusokat értjük, akkor az egyetem, mint előfordulás szerepel, egyedhalmaz pedig az összes iskolatípus. 2. Kapcsolat halmaz: a. Kapcsolat: entitások közti asszociáció. Az azonos típusú kapcsolatok halmaza a kapcsolathalmaz. (Pl. a „tanul valahol” kapcsolatok halmazának egy tagja: Gipsz Jakab tanuló mérnök informatikusnak tanul, másik tagja: Nagy Tihamér molekuláris bionikusnak tanul.) A kapcsolat halmaz „értéke” az aktuálisan kapcsolatban álló egyedek listája. Például a kocsmák és sörök entitások közötti kapcsolat az árul kapcsolat halmaza. b. Kardinalitás: i. egy-egy (1:1) kapcsolat - Az egyik egyedhalmaz minden egyes elemének legfeljebb egy elem felel meg a másik halmazból, és viszont. ii. egy-sok (1:N) kapcsolat – Az egyik halmaz elemeinek több elem is megfelelhet a másik halmazból, a másik halmaz minden eleméhez viszont csak legfeljebb egy elem tartozik az első halmazból. iii. sok-sok (M:N) kapcsolat: Mindkét egyedhalmaz bármely eleméhez több elem tartozhat a másik egyedhalmazból. iv. Opcionalitás: Azt mutatja meg, hogy az adott egyedtípusból hány példány vehet, és hány vesz kötelezően részt adott kapcsolatban. (Ez független a kapcsolat egy/több az egyhez/többhöz jellegétől! Pl. egy TDK-zó diák, ha elég ügyes, több munkában is részt vehet, több tanárnál, és egy tanárhoz tartozhat több diák is, de ez még önmagában semmit nem mond arról, hogy a diákhoz kötelezően tartozik tanár, fordítva viszont nem így van.) c. Egyéb kapcsolatfajták: i. IS-A kapcsolat – öröklődés: Azt mondjuk, hogy A egyedhalmaz isa kapcsolatba van B egyedhalmazzal (A isa B), ha az A egyedhalmaz részhalmaza B -nek, vagy másképpen B kiterjesztése A-nak. Ebben az esetben A örökli B halmaz valamennyi tulajdonságát (attribútumát), de ezen kívül A rendelkezhet még egyéb attribútumokkal is, melyek nem jellemzik B azon elemeit, amelyek nem elemei A-nak is. 3. Adatbázis notációk: Chen, UML, IDE1FX, ERA a. Logikai modellnél az iparban elterjedtebb notációknál a kapcsolat/relationship csak egy vonal. Más, elsősorban a Chen notációnál a kapcsolat/relationship egy rombusz szakítja meg a vonalat. A vonalas notációnál a kapcsolatoknak nem lehetnek további attribútumaik. De ebben az esetben nyugodtan bevezethetünk egy újabb egyedet/entity-t a
két eredeti egyed közé. Information engineering notációnál a kapcsolatoknál az „egy” oldalon szimpla vonalat húzunk az entitásokhoz keresztben áthúzva, a „több” oldalon szétágazót („varjúlábat”). b. A logikai modellnél bizonyos notációknál szerepelnek a külső kulcsok attribútumai, bizonyos notációknál nem szereplnek. c. A kardinalitásokat az information engineering notációnál úgy jelöljük, hogy az opcionális oldalra kört teszünk, a kötelező oldalra (1 kapcsolat esetén újabb) áthúzást. d. IS-A notáció:piros nyíl a gyerekekből a szülőbe vagy, a gyerekek a szülőbox hasában („box in box”). 4. Összetett és többértékű attribútum: a. Az összetett attribútum kisebb értelmes egységekre bontható. (Ellentétben az egyszerű attribútummal, ami nem.) Például a ’cím’ felbontható ’irszám’, ’település’, ’utca’, ’házszám’ részekre. b. A többértékű attribútumok tartalmazhatnak ugyanazon egyed-példány esetén több értéket ugyanarra az attribútumra. (Ellentétben az egyértékű attribútummal, ami pontosan egy értéket tartalmaz minden egyed-példány esetében.) Például egy ’könyv’ esetében a ’könyvcím’ egyértékű, a ’szerző’ viszont lehet többértékű. 5. ER alapján relációs séma készítése: a. Relációs modell: Minden adat táblákban (=relácókban) van eltárolva, a kapcsolatokra vonatkozó adatok is. A relációs modellben nincsen : n:m kapcsolat és IS-A (öröklődés) kapcsolat. A cél egy olyan modell képzése, amiből közvetlenül felírható a relációs adatbázis. (Azaz a relációs modell „buborékjai” közvetlenül a tábláknak felelnek meg.) b. Egyed leképezése: Az EK modell minden egyedéhez felírunk egy relációsémát, amelynek neve az egyed neve, attribútumai az egyed attribútumai, kulcsa az egyed kulcsattribútumai. A sémára épülő adattábla minden egyes sora egy egyed-előfordulásnak felel meg. c. Összetett attribútumok leképezése: Az összetett attribútumot ugyanabban a sémában felbontjuk rész-tulajdonságaira. d. Többértékű attribútumok leképezése: A többértékű tulajdonságot kiemeljük egy másik táblába és hozzávesszük az azonosító tulajdonságát is. e. Kapcsolatok leképezése: i. Az 1:1 és 1:n kapcsolatot a legcélszerűbb úgy leképezni, hogy az n oldalon (1:1 esetében valamelyik oldalon) felvesszük a másik tábla elsődleges kulcsát az attribútumok közé. Ezt külső kulcsnak állíthatjuk be. ii. Az n:m kapcsolatokhoz kapcsolati táblára van szükség, melyben mindkét kapcsolódó táblára (amik a kapcsolódó egyedekből készültek) külső kulcs mutat (a tábla az entitások elsődleges kulcsait tartalmazza). A kapcsolati táblában általában a két külső kulcs attribútumai adják együtt kapcsolati tábla elsődleges kulcsát. iii. A kapcsolat kötelezőségének megadása: Az a tábla, aminek minden sorához kötelezően tartozik valamilyen sor egy másik táblából a kötelező oldal (így fogom hívni, ez nem hivatalos definíció). Pl. a tanár-TDK-zó diák tábláknál a diák; az egyszerűség kedvéért most tegyük fel, hogy ez egy n:1 kapcsolat, egy diák csak egy tanárnál TDK-zhat. A kötelező oldalon felvesszük a másik oldal elsődleges
kulcsát az attribútumok közé, ezt külső kulcsnak állítjuk be, és NOT NULL constraint-et állítunk be rá. Így biztosan minden sorhoz tartozni fog valamilyen másik táblába tartozó sor. N:M kapcsolat átírásánál a kapcsolatnak külön táblát hoztunk létre, ha beállítjuk a nem kötelező oldalra mutató külső kulcsot NOT NULL-nak, akkor, ha a táblába beillesztünk egy új sort (azaz új kapcsolatot hozunk létre), a kötelező oldalnak megfelelő kulcshoz biztosan tartozni fog egy kulcs a másik oldalból. iv. Az IS-A (öröklődés) kapcsolat megvalósításakor a reláció modellben van lehetőség a három megvalósítási stratégiára: 1. Table for each entity: minden entitásnak létrehoz egy táblát, úgy, hogy a szülői táblában csak a szülői, a leszármazottak tábláiban a gyerekek tulajdonságai és a szülő elsődleges kulcsa, mint külső kulcs fog szerepelni. 2. Single table: egyetlen táblában egyesítjük a szülők és a gyermekek tulajdonságait. 3. Table per child: minden gyereknek külön táblát hozunk létre, amiben benne vannak a szülői tulajdonságok, és az adott gyerekre jellemző tulajdonságok (a szülő nem kap külön táblát). Megjegyzés: A reláció (relation) a táblára vonatkozik, NEM a ER modell relationship-jére (kapcsolatára)!!! Nagyon hasonlítanak a kifejezések, elég megtévesztő, de teljesen másról van szó, nem szabad összekeverni! 6.
Normalizálás (a normalizálás céljai, veszteséges és veszteségmentes dekompozíció, elsőfokú normálforma 2NF, harmadik normálforma, BCNF, 4NF, szuperkulcs, kulcs-jelölt, funkcionális függőség, többértékű függőség) 1. Kulcsjelöltek, Szuperkulcs: Legyen R=(A1,…,An) egy relációséma, Ai attribútum értelmezési tartománya Di. K⊆R szuperkulcsa az „r” relációnak (r⊆D1×,…,×Dn), ha a benne szereplő attribútumok értelmezési tartományainak keresztszorzata elegendően nagy elemszámú ahhoz, hogy a bennük szereplő elemek „r” minden elemét azonosítsák. (Magyarul egy tábla adott oszlopaiba elegendő fajta érték írható ahhoz, hogy a tábla minden sorába más értéket lehessen írni az adott oszlopokban). A kulcsjelöltek azok a szuperkulcsok, amikre a bennük szereplő attribútumok értelmezési tartományának elemszáma minimális. A kulcsjelöltek egyikét választjuk ki elsődleges kulcsnak. 2. Cél: A normál formák képzése során leegyszerűsítve, olyan relációk felírása a cél, melyekben csak a reláció kulcsra vonatkozó tényeket tárolunk. A logikai tervezés célja egy redundancia (fölösleges adatismétlés) mentes reláció rendszer, relációs adatbázis. Az első három normál forma a funkcionális függőségekben található redundanciák, míg a negyedik és ötödik a többértékű függőségekből adódó redundanciák megszüntetésére koncentrál. E.F. Codd szerint a normalizálás céljai: a. Az adatbázis módosításakor fellépő anomáliáktól való mentesség: i. Frissítési anomália: pl. redundáns adatbázisban ha egy adatot frissítünk, de nem frissítjük az ismétlődő változatait, akkor inkonzisztens állapotba jut az adatbázis (pl. egy alkalmazott fizetését többször tároljuk, és ez az alkalmazott
fizetésemelést kap: ha csak egy vagy néhány helyen írjuk át a fizetését, akkor inkonzisztens lesz az adatbázis). ii. Beillesztési anomália: pl. egy táblában tároljuk a tanárok azonosítóját, nevét, felvételük idejét , és a kurzusokat, amiket oktatnak. Ha felveszünk egy új tanárt, aki még nem oktat semmit, azt csak úgy tehetjük meg, ha a tanított kurzust NULL-ra állítjuk. iii. Törlési anomália: az előbbi táblában, ha egy tanár épp nem fog tanítani semmit, csak úgy törölhetjük a tanított kurzusára vonatkozó adatot, ha törlünk minden más, rá vonatkozó adatot is, így a tanár teljesen eltűnik az adatbázisból. b. Jól normalizált adatbázisban ha újfajta adatokat kell bevezetni, akkor kevés dolgot kell újratervezni c. Jól normalizált adatbázis a valóságot is jobban modellezi d. Jól normalizált adatbázisból sokféle, akár a tervezés pillanatában váratlan lekérdezésekkel is előhívható adat. Pl. egy könyvesbolt vásárlóinak a kívánságlistáját ha egyszerű szövegekként tároljuk, akkor egyedül ez az adat hívható le egyszerűen az adatbázisból. Ha viszont megfelelő módon, akkor egyéb adatok is könnyen lekérdezhetők, pl. hogy mekkora igény van egyes szerzők műveire. 3. Funkcionális függőség (functional dependency): Az egyed B tulajdonsága funkcionálisan függ A-tól, ha A egy értékéhez pontosan egy érték tartozik B-ből, vagyis A funkcionálisan meghatározza B-t. Pl.: szemelyi_szam → nev. Formálisan: adott r(R) instance esetén, ha α, β ⊆ R és „r” minden „t1”, „t2” elemére ahol t1[α]=t2[α] ott t1[β]=t2[β] akkor α→β. 4. Többértékű függőség (multivalued dependency): Formálisan: legyen r(R) instance, α, β ⊆ R. α->>β, ha minden t1, t2 ∈ r esetén ahol t1[α]=t2[α] létezik t3, t4 ∈ r is, hogy 1. t1[α]=t2[α]=t3[α]=t4[α] 2. t3[β]=t1[β] és t3[R-β]=t2[R-β] 3. t4[β]=t2[β] és t4[R-β]=t1[R-β]. (Itt valójában R-α-β is írható, mivel az α tulajdonságban eleve megegyeznek a sorok.)Intuitíve ez két dolgot jelent: egyrészt a relációban bizonyos sorok megléte más sorok jelenlétét vonja maga után, másrészt a relációban bizonyos tulajdonságok értékeihez egymástól függetlenül tartoznak más tulajdonságok értékei. Pl. egy kurzuson több könyvből több tanár tanít, így a leíró táblában minden könyv-tanár pár szerepel (a definíció a példán ellenőrizhető): Kurzus AH1 AH1 AH1 AH1
Könyv (csak az író) P. László L. Ferenc P. László L. Ferenc
Tanár Nagy Elemér Gipsz Jakab Gipsz Jakab Nagy Elemér
5. Veszteséges és vezteségmentes-összekapcsolás dekompozíció (lossy decomposition, losslessjoin decomposition): A dekompozíció során az induló séma felbontásával emeljük ki a nem kívánt függőségeket
6. -
-
-
-
külön relációkba. A felbontás célja a redundancia csökkentése információvesztés nélkül . Veszteségmentesség: a résztáblák joinjából előállítható az alaptábla. Veszteséges: az eredeti reláció nem állítható vissza természetes összekapcsolással (1NF) Egy reláció első normál formában van, ha minden attribútuma egyszerű, nem összetett adat. (2NF) Az első normál forma nem elegendő feltétel a redundanciák megszüntetésére. Egy reláció második normál alakjában nem tartalmazhat tényeket a reláció kulcs egy részére vonatkozóan. A második normál forma definíciója két feltétellel írható le. o A reláció első normál formában van o A reláció minden nem elsődleges attribútuma teljes funkcionális függőségben van az összes reláció kulccsal Azok a relációk, melyek reláció kulcsa csak egy attribútumból áll, mindig második normál formában vannak, ekkor ugyanis nem lehetséges, hogy csak a reláció kulcs egy részétől függjön egy nem elsődleges attribútum. (3NF) A második normál formájú relációkban nem lehetnek olyan tények, amelyek a reláció kulcs részeihez kapcsolódnak. Azonban ennek ellenére is lehet bennük redundancia, ha olyan tényeket tartalmaznak, amelyek a nem elsődleges attribútumokkal állnak kapcsolatban. Ezt a lehetőséget szünteti meg a harmadik normál forma. Egy reláció harmadik normál formában van, ha o A reláció második normál formában van. o A reláció nem tartalmaz funkcionális függőséget a nem elsődleges attribútumok között. (BCNF) A normál formák tárgyalása során eddig olyan relációkra mutattunk példákat, melyeknek csak egy reláció kulcsa van. A normál formák definíciója természetesen alkalmazható a több kulccsal rendelkező relációkra is. Ebben az esetben minden attribútum, mely valamely kulcsnak a része, elsődleges attribútum, de ez az attribútum függhet egy másik, ezt nem tartalmazó kulcs részétől. Ha ez a helyzet fennáll, redundanciát tartalmaz a reláció. Ennek a felismerése vezetett a harmadik normál forma egy szigorúbb definíciójához, a Boyce/Codd normál formához. o A reláció harmadik normál formában van o Minden elsődleges attribútum teljes funkcionális függőségben van azokkal a kulcsokkal, melyeknek nem része (4NF) Sajnos még a Boyce/Codd normál forma is tartalmazhat redundanciát. Mindeddig csak a funkcionális függőségeket vizsgáltuk, a többértékű függőségeket nem. A további két normál forma a többértékű függőségekből adódó redundancia kiszűrését szolgálja. Egy reláció negyedik normál formában van o Harmadik normál formában van és o egy X->>Y többértékű függőséget tartalmazó relációban csak az X és Y-ban megtalálható attribútumokat tartalmazza.
7. Tranzakciókezelés (ACID tulajdonságok, izolációs szintek, elosztott rendszerek) 1. Tranzakció: egy olyan programrészlet, ami a egy vagy több adatot olvas és/vagy módosít. 2. ACID tulajdonságok: a. Atomikus: egy tranzakción belüli műveletek vagy mind lefutnak vagy egyik se b. Konzisztencia(következetesség): Egy adatbázison belül nincsenek egymásnak ellentmondó adatok. Ilyen állapotból indul és érkezik. c. Izoláció (elkülönítés): párhuzamosan több tranzakció futása esetén egymástól nem függnek d. Tartósság: ha végbement a tranzakció, a végrehajtott változásokat eltároljuk, azok nem vesznek el (pl. nem csak a fő memóriában tároljuk el a változásokat, mert ekkor áramszünetkor elvesznének, hanem a másodlagos tárolón, pl. merevlemezen is, ahol az adatbázis tárolódik). 3. Fellépő jelenségek: a. Lost update:
Az első tranzakció által végrehajtott változás, mielőtt véglegessé válna eltűnik a második tranzakció miatt. (A kép a diasorból van.) b. Dirty read(nem commit-tolt adat olvasása; innentől a képek http://en.wikipedia.org/wiki/Isolation_%28computer_science%29-ről):
Az első tranzakció a második tranzakció által módosított adatot olvassa a második lépésben, amit viszont nem véglegesít, sőt visszagörget a második tranzakció.
c. Non-repeatable read(változó adat olvasása): egy tranzakció alatt kétszer is lekérjük ugyanazt a sort, és a sor tartalma a két lekérdezés alkalmával különböző:
d. Phantom read (fantom adat olvasása): a tranzakció során két azonos lekérdezést hajtunk végre, mégis más sorokkal térnek vissza:
4. Izolációs szintek: a. szerializálás: sorban, egymás után hajtódnak végre a tranzakciók, így az izoláció automatikusan teljesül, de nagyon lassú b. repeatable read: olvasott érték nem változik c. read commited: csak véglegesített adat olvasható d. read uncommited: nem véglegesített adat is olvasható
(Kép a diából.) 5. Elosztott rendszer, kétfázisú commit: Elosztott tranzakciónak nevezünk egy tranzakciót, ha tartalmaz legalább egy olyan utasítást, ami módosít legalább két különböző hálózati végpontokon lévő adatbázisokat. A kétfázisú elv biztosítja, hogy elosztott tranzakció minden adatbázisa konzisztens marad, vagyis az összes adatbázis vagy commitálja a tranzakciót, vagy visszagörgeti annak addigi hatásait. Először ellenőrizzük, hogy a tranzakció minden adatbázisban végrehajtható-e, és ha igen, akkor hajtjuk végre.
8.
PL/SQL – az SQL procedurális kiterjesztése (fv-ek, eljárások, SQL integrálási lehetőségei, alapvető programvezérlési struktúrák) PL=procedural language. Moduláris, újrahasznosítható. Szerver oldalon párhuzamosan futhatnak (csökkenő adatforgalom) hibakezelés (kivételkezelés), biztonság. set serveroutput on; DECLARE Variable declaration (constans, records, cursors ) [%type –egy érték, %rowtype –egy sor, cursor –lekérdezés eredményét tárolja, hibakezelés miatt egyébb értékei is lehetnek] BEGIN Program Execution (loop, conditions, statement, sql statement) [if...then-elsif...then-else-end if, loop...exit when...end loop, for...in...loop...end loop, while...loop...end loop, ] SELECT ename, id INTO v_ename, v_id –itt is lehet hibakezelési értéke FROM emp WHERE id = '112';
--integritási lehetőségek
dbms_output. put_line(your_string); dbms_output.put(your_string); EXCEPTION Exception handling [felhasználó is definiálhat] WHEN NO_DATA_FOUND THEN dbms_output.put_line('No data!'); WHEN TOO_MANY_ROWS THEN dbms_output.put_line('Too many!'); WHEN OTHERS THEN dbms_output.put_line(‘Error’); END; SQL integrálási lehetőségei: a deklaratív SQL-ben megismert lekérdezéseket itt is alkalmazhatjuk. Azokat eleve optimalizáltan írták meg, általában sokkal gyorsabbak, mintha ciklusokat, stb. alkalmaznánk. Programvezérlési struktúrák: Anonymous blocks, procedures, functions (visszatérési értéke is van) később is meghívható, nevük van, változóik in-out-inout. Ezekből programcsomagok, ún. package-ek készíthetőek. CREATE [OR REPLACE] PROCEDURE procedure_name [(parameter1 [mode1] datatype1,
parameter2 [mode2] datatype2, . . .)] IS|AS PL/SQL Block; CREATE [OR REPLACE] FUNCTION function_name [(parameter1 [mode1] datatype1, parameter2 [mode2] datatype2, . . .)] RETURN datatype IS|AS PL/SQL Block; Triggerek -nemtom ez mennyire kell, röviden: Ha valami (pl insert) változás van a db-n, akkor ezek automatikusan lefutnak (data is valid?) 9.
Lekérdezések erőforrásigénye (indexek, lekérdezés végrehajtás, lekérdezési tervek, költségalapú optimalizálás)
1 gyökérelem, onnan jönnek le az osztópontok (balra a kisebbek, jobbra a nagyobbak), innen a mutatók, amik a tényleges adatra mutatnak (data ponter) a fizikai háttértáron (itt rendezetlen az adatok sorrendje). A szomszédos elemekre is vannak mutatók, így gyorsabb
(sibling pointer) a keresés. Az adatokat blokkokban tároljuk, a blokk mérete határozza meg, hogy mennyivel gyorsul a lekérdezés. (Blokk mérete alapú logaritmus). A keresés sokkal gyorsabb, kevesebb, mint 10 lépésben minden adatot meg tudunk találni, bármilyen nagy is az adatbázis. Viszont az indexelés mérete nagyságrendileg azonos az adatbázis méretével (ha DB~ 100 Tb akkor indexelés is Tb-os nagyságú) Query, join, rendezett lekérdezéseknél. Több érték alapján is készíthetünk indexet(, vigyázzunk, hogy a második alapján már nem érdemes keresni, csak a kettőt együtt!) Arra érdemes indexet készíteni, aminek nagy a szelektivitása. Sql: What to retrieve, not how! Lekérdezési terv készül az sql kódból. Költség alapú optimalizáló: Kereséskor a feldolgozó a rendelkezésre álló, időközönként frissítendő rendszerstatisztikákat is figyelembe veszi, a legkisebb költségráfordítás alapján működik (IO műveletek száma, blokkok száma). Végrehajtás: deklaratív nyelv révén a fordító (query processzor) gépi kódra (lekérdezési tervre) alakítja több lépésben: 1, értelmezés, 2, transzformálás (operátor fa létrehozása): részeredmények minél kisebbek legyenek, alapján szelektálunk, productokat később, restriktív joinokat előbb. (statisztika alapján dönti el, hogy csökkenti-e a méretet vagy növeli) 3, optimalizálás (index, műveleti sorrend, részadatok szelektálása, összevont műveletek), 4, végrehajtás Ennek érdekében a rendszerről statisztikákat vezetünk, amiben tároljuk a sorok átlagos hosszát, a duplikátumok számát, a táblák méretét, lekérdezések szelektivitását, stb… 1. XML (alapvető fogalmak, felépítés, DTD, XML schema, Well-formed, valid, XPath, XQuery, XML adatbázisban) eXtensible Markup Language Ipari szabávány adatcserékhez (input, output, alkalmazások, kommunikációs protokoll, szolgáltatás leírás) HTML kiegészítése: html megjelenítésért felel, xml a mögöttes tartalmat írja le bővíthető, tagelhető (hierarchia) Semi structured data model (XML) Relational data model < XML Schema, e.g, for gene ontology < XML Schema for Gene Ontology (DTD or XML Schema) Database with records (according to the schema) < XML Document Instance A-101 Downtown 500
<depositor> A-101 <customer_name>Johnson Well-formed Minden elem egymásba ágyazott, nyitó-csukó tag párosokban Dokumentumban 1 gyökér elem van Ebben is lehet struktúrálatlan szöveg akár csak az XML-ben A sémák (Valid XML) fontosak az XML adatcsere folyamatokhoz, egyébként nem tudjuk automatikusan feldolgozni/interpretálni Document Type Definition (DTD) típus és struktúra leírás XML-hez: milyen attribútumainak milyen elemei lehetnek/kellenek, hogy legyenek al-elemekre ugyanez Nincsenek típusok, minden szövegként tárolódik egy alaptípusa lehet, az elemek sorrendje fix, nem lehet hívatkozni(No types for references) XML Schema Kifejezőbb és összetettebb, mint a DTD Lehetnek típusok (megkötés lehetnek a min/max értékekre) Felhasználó is definiálhat összetett típusokat Unique, FK, öröklődés XML szintaktikával írható le, bőbeszédű, namespace-ekben benne van Xpath Az Xpath parancs eredménye: csomópontok gyűjteménye (gráf) meghatározott mintával, URL jellegű, összehasonlítható Egy-egy csomópontról is megtudhatunk mindent location path, location step, axis, -- az aktuális node (kontextus) és a location step által kiválasztott node-ok kapcsolata. Pl. gyerek, leszármazott. node test, -- a node típusát illetve nevét adja meg. Pl. comment(), div, text(). predicate -- további kifejezésekkel finomítja a node-ok meghatározását. Pl. [position() = last()] Xquery
Kicsi, könnyen implementálható, olvasható, flexibilis query(lekérdező) nyelv XML adatbázisban tárolás(xml dokumentumok) sémák(dtd, xml schema…) programozási interfészek (sax, dom ,jdom) query languages (xpath, xquery) Központi szerepet tölt be az adatcsere, nyílt szabányos Beszédes, nagy mennyiségű adat Nincs benne gazdaságos tárolás, indexelés, biztonság, tranzakció és adat integrálás. De van több felhasználós hozzáférés, triggerek, több dokumentumot összekötő lekérdezések
2. Információ visszakeresés: alapvető tulajdonságok, fogalmak -- struktúrálatlan adatok, információs igény, relevancia, precision, recall, Boolean retrieval, tokenizálás, flexibilis lekérdezés) Information Retrieval (IR) is finding material of an unstructured nature that is relevant to the user’s information need and helps the user complete a task from within large collections (usually stored on computers). Struktúrálatlan adat: szöveges dokumentum, kép, audio/video, stb. Task (szabaduljunk meg az egerektől legálisan!) info need (hogyan szabaduljunk meg l egerektől gyilkolás nélkül?) verbal form (Mik a gyolkolásmentes egércsapdák?) relevant (egércsapda – erre keresünk rá). Keresőmotor eredmények keresés finomítása keresőmotor … Boolean retrieval – legegyszerűbb módszer az információ visszakeresésre. Az a dott kifejezés (szavak és/vagy kapcsolata, not) szerepel-e az adott dokumentumban. 3 évtizedig a fő módszer, könyvtárakban, e-mail rendszerekben még mindig használják. Relevancia: számunkra mennyire hasznos a megtalált dokument. Ez alapján ítélhetjük meg a lekérdezésünk hasznosságát. Precision: relevant/retrieved Recall: retrieved/relevant Tokenization: a keresett szöveget milyen részegységekre bontsuk? Problémák: Finland’s; Hewlett-Packard; San Francisco; numbers; kis betű- nagy betű; Flexibilis lekérdezés: normalization to terms ( windows – window, windows, Windows); lemmatization – is, am, are be; stemming – reducing everything to its root; spell correction; szinonimák, homonimák; soundex - chebyshev tchebycheff.
3. Információ visszakeresés: Vector space model, tf-idf, precision-recall görbe Szeretnék a keresési eredményeinket rangsorolni. A boolean módszer csak profiknak ad értelmezhető eredményt – vagy túl kevés, vagy túl sok. Hogyan rendeljünk számot az eredményünkhöz? Jaccard coefficient: A commonly used measure of overlap of two sets A and B. Jaccard(A,B) = |A ∩ B| / |A ∪ B|. Nem veszi figyelembe, hogy hánszor fordult elő a kifejezés a szövegben – a ritka kifejezések sokkal informatívabbak. Bag of words = vector model: a dokumentum szavak halmaza, a sorrend itt irreleváns. term frequency (tf): a kifejezés hányszor fordul elő a dokumentumban. A dokumentum relevanciája azonban nem növekszik ezzel lineárisan! document frequency: a kifejezés hány dokumentumban fordul elő (df). A ritkán előforduló szavak sokkal lényegesebbek - nekünk ennek inverzére és kisebb súlyban van szükségünk (idf). w t ,d log(1 tft ,d ) log10 ( N / df t ) Így minden dokumentumhoz egy |v| dimenziós vektort rendelhetünk tf-idf értékei szerint. A vektorterünkben a kifejezések a tengelyek, a dokumentumok és lekérdezések a vektorok. A lekérdezés- és dokumentumvektorok távolsága helyett a bezárt szög cosinuszát számoljuk. 1.0 0.8
Precision
A precision – recall görbe az ú.n. ranked retrievalnál van értelmezve, vagyis amikor az eredmény nem egy (rendezetlen) halmaz, hanem egy sorbarendezett találatlista.
0.6 0.4 0.2 0.0 0.0
0.2
0.4
0.6
0.8
1.0
Recall
4. Pagerank A Google alkalmazza. Egy oldal fontosságát a rá hivatkozó linkek száma határozza meg – ez egy rekurzív definíció. Minden link súlya arányos a forrásoldal fontosságával. Ha x fontosságú P oldalnak n kimenő linkje van, azok súlya x/n lesz. P fontosságát (x) a bejövő linkek súlyának összege adja meg.
A gráf leírható egy sztochasztikus mátrixként (oszlopösszegek 1-et adnak – most minden oldal fontossága 1, csak a ki- és bemenő linkeket nézzük). r vektor egy címszó/weblap: i. eleme az i. weblap fontossága, rank vector, |r|=1. r a sztochasztikus mátrix sajátvektora 1 sajátértékhez, r=Mr. (Mint a stabil eloszlás…) 5. Adattárházak (célok, OLAP, OLTP, architektúra, ETL folyamatok, csillag séma, elemző eszközök) „In computing, a data warehouse or enterprise data warehouse (DW, DWH, or EDW) is a database used for reporting and data analysis. It is a central repository of data which is created by integrating data from one or more disparate sources. Data warehouses store current as well as historical data and are used for creating trending reports for senior management reporting such as annual and quarterly comparisons.” Other areas: environmental monitoring, biomedical applications, research. Az OLAP (On-Line Analytical Processing) a nagyméretű adatbázisok szervezésének és a kapcsolati adatok támogatásának egyik módja. Az OLAP-adatbázisok megkönnyítik a kapcsolati adatok lekérdezését. Az OLAP egy olyan adatbázis-technológia, amelyet tranzakciók végrehajtása helyett lekérdezések és kimutatások használatára optimalizáltak. Az OLAP forrásadatai adattárházakban elhelyezkedő OLTP-adatbázisok (Online Transactional Processing). Az OLAP-adatok ezekből az előzményadatokból származnak, és olyan szerkezetekké vannak összevonva, melyek lehetővé teszik a kifinomult elemzések végrehajtását. Az OLAP-adatok szervezettsége hierarchikus, tárolásuk pedig kockákban (csillag-séma) történik, nem táblákban. Ez egy olyan fejlett technológia, amely többdimenziós szerkezetek révén biztosítja az adatok elemzési célú gyors elérését. Ezzel a szervezéssel a kimutatásokban és kimutatásdiagramokon nem jelent nehézséget az értékesítések magas szintű, például országos összegzésének megjelenítése, és a különösen alacsony vagy különösen magas forgalmat lebonyolító telephelyek adatainak kiemelése. csillagséma: az (üzleti) adattárházak jellemző adatbázis-sémája:
Vannak "tények": numerikus (m)értékek (pl. bevétel, nyereség, kiadás, profitabilitás....), amiket vizsgálunk, és "dimenziók", pl. régió, időszak (pl, év, negyedév, hónap), termékcsoport,...
A csillagsémában a tények és külső kulcsok a dimenziótáblákra egy ténytáblában (fact table) vannak. Ez jellemzően nagyon nagy, nagyon sok rekordot tartalmaz. A dimenziótáblákban pedig az adott dimenzióhoz tartozó értékek megnevezései vannak. A dimenziók egyébként gyakran hierarchikusak (pl. idő: év-negyedév-hónap, földrajzi régió vagy termékcsoport) Data cube: a jellemző lekérdezési eszköz üzleti adattárházakhoz: A mértékeket vizsgáljuk a dimenziók függvényében. Lehet egyes dimenziókban konkrét értékeket kiválasztani (pl. csak 2011. 1. negyedévet vizsgáljuk) , másik dimenziókban (pl. termékcsoport ill. régió) pedig az (aggregált) értékek eloszlását nézni. A kiválasztást, aggregálást, megjelenítést az adott keretek között nagyon rugalmasan tudja a végfelhasználó megválasztani, és így mintegy interaktívan felfedezi az adatokat.
OLTP: Online Transaction Processing (Traditional DBMS)is characterized by a large number of short on-line transactions (INSERT, UPDATE, DELETE). The main emphasis for OLTP systems is put on very fast query processing, maintaining data integrity in multi-access environments and an effectiveness measured by number of transactions per second. In OLTP database there is detailed and current data, and schema used to store transactional databases is the entity model (usually 3NF). Requirements in OLTP and in OLAP n n n n
Highly normalized, large number of tables Read/Write Few records (tens) Standardized, simple queries
n n n n
De-normalized, fewer tables Read-only (batch update) Large number of records (millions) n aggregations Ad-hoc queries, Aggregations
ETL folyamatok: -
Extracting data from outside sources Transforming it to fit operational needs, which can include quality levels Loading it into the end target (database, more specifically, operational data store, data mart or data warehouse)
Elemző eszközök: OLAP eszközök - Oracle (Essbase), Microsoft (Analysis Services) Excel, and SAP (Business Warehouse)—have made great strides in expanding the amount of data that cubes can contain by dynamically calculating data within cubes and joining data across cubes. Some of these vendors have also made it possible for users to input data values to perform planning, budgeting, and “what-if” analyses.
6. Objektumrelációs adatbázisok, földrajzi adatok kezelése Objektumorientált: cask kísérleteztek vele, nem volt olyan hatékony, mint a relációs, túl absztrakt. Objektum-relációs: relációs adatbázisokhoz készítettek objektum-elvű kiterjesztéseket. Az alapabsztrakció még mindig a relációs elv, de kihasználja az objektumorientáltság előnyeit, objektumok, classok, öröklődés, encapsulation (private, public, protected). Támogatja új, izgalmas adattípusok tárolását, például földrajzi adatokat, XML-t, multimédiás adatokat. Felhasználó definiál új típusokat – class egy struktúrával és metódusokkal. Spatial database offering (SDO_geometry object). Az objektumban tárolhatjuk a geometria minden paraméterét. Az összetett típusok (pl. geometria) mellett a velük való műveletek (pl. földrajzi, topologikus kapcsolatok vizsgálata) is lényeges. Egyébként az adattípusok és a műveletek mellett speciális indexeket is létre lehet hozni az objektumrelációs adatbáziskezelőkben. Pl. az Oracle földrajzi kiterjesztése ilyen speciális többdimenzionális, földrajzi indexeket is tartalmaz. Topologikus kapcsolatok: az objektum egy másikban, azon kívül, annak határán, átlapolva stb van, vagy akár egyenlőek. SDO_relate. További műveletek: veszi az objektumok “unióját” például. 7. In-memory adatbázisok (alapötlet, három lényeges különbség "hagyományos" (diszkalapú) adatbáziskezelőkhöz képest (vizsgán is ennyit mondtam) Az adatbázist a háttértár helyett a memóriában tároljuk. Ennek előnyei:
Memóriaelérés sokkal gyorsabb, mint a háttértáré, hiszen fizikailag is közelebb van a CPU-hoz. A háttértáron az adatok blokkokba (pl. 4, 8 vagy 16 kByte) vannak szervezve (lapozási, szegmentálási technikák), ennek a kezelése az adatbáziskezelő rendszerben meglehetősen bonyolult. Ha elsődlegesen a memóriában tárolunk adatokat, akkor lehet nagy, egybefüggő, lineáris címterekkel dolgozni, és sokkal egyszerűbbé (és gyorsabbá) válik az adatbáziskezelő rendszer. A hálózati kommunikáció az alkalmazás és az adatbáziskezelő rendszer között meglehetősen lassú. Egy in-memory adatbáziskezelőt egybe lehet építeni az alkalmazással, így ez a kommunikáció is sokkal gyorsabb lesz.
Hátrány: -
Durability könnyen sérülhet, hiszen egy áramszünet esetén a memória tartalma elveszhet. Ezt bonyolult log-fileokkal ki lehet küszöbölni, de ezek kezelése nem kényelmes.
8. Nosql adatbázisok: követelmények (Consistency, availability, partition-tolerance), adatmodellek (key-value, column-oriented, document-oriented, graph) Hatalmas mennyiségű adatok keletkeznek (Google, Facebook, eBay, CERN). A webalapú rendszerek esetén nem a legcélravezetőbb a hagyományos RDBMS. No Not only SQL. Rugalmas sémák, RDBMS normalizáltak, előre definiáltak. Gyorsabb és olcsóbb felállításuk. Masszív skálázhatóság: nagyobb gépek, virtuális gépek, commodity servers. A konzisztenciát rugalmasabban kezelik, így nagyobb az adatbázis elérhetősége, javul a teljesítménye. n Basically available: Nodes in the a distributed environment can go down, but the whole system shouldn’t be affected. n Soft State (scalable): The state of the system and data changes over time. n Eventual Consistency: Given enough time, data will be consistent across the distributed system. Az elérhetőségért képesek vagyunk áldozatot hozni – CAP theorem: “Of three properties of a shared data system: data consistency, system availability and tolerance to network partitions (data to be partitioned across network segments due to network failures), only two can be achieved at any given moment.” Adatmodellek: -
Relációs: MySQL, Postgre, Greenplum… Táblás modell, 2A tétel Key-Value: Dynamo, Voldemort, Berkeley DB… Pairs, mint a c++-ban. Operátoraik: insert, fetch, update, delete. A kulcsok alapján csomópontokat hozhatunk létre. Hatékony, skálázható, hiba-tűrés. Single-record transaction, eventual consistency.
-
Column-oriented, Tabular: Cassandra, Hbase, Vertica, Big Table… stores data tables as sections of columns of data rather than as rows of data, like most relational DBMSs. This has advantages for data warehouses, customer relationship management (CRM) systems, and library card catalogs, and other adhoc inquiry systems[1] where aggregates are computed over large numbers of similar data items.
-
Document oriented: Simple DB, Couch DB, Mongo DB… mint a key-value, csak a kulcs értéke egy dokumentum (XML, YAML, JSON, BSON, bináris formátumok – pdf, MSdokumetumok).
-
Graph DBs: Neo4J, Cyper ( a query language) Social/computer networks, maps, molekulák, prognyelvek szintaktikája…
9. Skálázható adatfeldolgozás számítógép klasztereken Map-reduce segítségével Olcsóbb több kisebb gép fenntartása egy adatközpontban. Nagyon nagyszámú,"közönséges" számítógépekből ("commodity machines") álló számítóközpontok, ezek gazdaságilag előnyösebbek, mint a speciális, pl. sokprocesszoros célhardverek -- ez egy nagyon lényeges pont: óriási adatmennyiséget akarunk ilyen hardver infrastruktúrával feldolgozni! Seamless scalability: az emberi munkaidő kevésbé kalkulálható adatfeldolgozáskor, mint a gépidő. Mennyi időre foglaljuk le a szervert? Execution framework: scheduling, synchronization, errors and faults. Vigyük a feldolgozást az adathoz! A klaszterek sávszélessége korlátozott. Ne random, hanem soros hozzáférést alkalmazzunk. Map-reduce: a map-reduce feldolgozás egy nagyon egyszerű és általános modell, mindenféle adatkezelési feladatot meg lehet ilyen alapon oldani (pl. a relációs adatbáziskezelőkből ismert műveleteket is) Kulcs-érték párok map-jét alkalmazzuk minden halmazbeli elemen, új kulcs-érték párokat kapunk eredményül. Ezután ezeket redukáljuk: összevonjuk az egy kulcshoz tartozó értékeket.
Például, számoljuk meg a szavakat a dokumentumban n n n
Input consists of (url, contents) pairs map(key=url, val=contents): n For each word w in contents, emit (w, “1”) reduce(key=word, values=uniq_counts): n Sum all “1”s in values list n Emit result “(word, sum)”
2000-es évek elején nagyon elterjedt.
