adatbázis elmélet

1.Adat,információ,adatbázis,ABKR

Miért van szükség adatbázisokra?
- A külvilágból a nap 24 órájában információ árad felénk (tv-n, ismerõsök elmondása alapján). Ezek közül a számunkra legfontosabbakat próbáljuk meg kiszûrni. Ezeket azonban lehetetlen fejben tartani, így valahol tárolnunk kellene. Ha tároljuk fontos lenne, hogy gyorsan, hatékonyan hozzáférjünk, és a tárolás is biztonságos legyen.
- Ma már egyre több ember, egyre több számítógépen, egyre nagyobb mennyiségû tárolt adatot használ föl. (alkalmazott információs rendszerek: raktárkészlet nyilvántartás, betegnyilvántartás, menetrendek, tervezõi rendszerek, tanulói nyilvántartás)
Mindezekben az a közös jellemzõ, hogy nagy adathalmazt kezelnek, az adatok közt bonyolult kapcsolatok is fennállhatnak, és ezeket az adatokat hosszabb ideig is meg kell õrizni. Ezeken kívül
Követelmények, amiknek az ilyen rendszereknek feltétlenül meg kell felelni:
- Nagymennyiségû adat hatékony kezelése
- Egyszerre több felhasználó általi elérés támogatása
- Integritásõrzés
- Védelem
- Hatékony programfejlesztés

- Az elsõ adatbázis-kezelõ rendszerek a fájlkezelõ rendszerekbõl kezdtek kialakulni a 60-as évek végén.
- Ezek terjedelmes és drága programrendszerek voltak, melyek nagyméretû gépeken futottak.
- Azok a rendszerek voltak az elsõ jelentõségteljes alkalmazási területei, melyekben sok adatelemet tároltak és a rendszerben sok lekérdezést és módosítást hajtottak végre.
- Néhány példa: Vállalati nyilvántartások, banki rendszerek, repülõgép-helyfoglalási rendszerek.
- 1970-ben Ted Codd cikkének közzététele után – amiben azt javasolta, hogy az adatbáziskezelõ-rendszerek az adatokat táblázatok formájában jelenítsék meg a felhasználó felé – jelentõsen megváltoztak az adatbáziskezelõ rendszerek.
- A különbség a korábbi rendszerekkel szemben, hogy a felhasználónak nem kell az adatok tárolási struktúrájával foglalkoznia a relációs rendszerben, ugyan is a lekérdezések egy olyan magas szintû nyelv közvetítésével fejezhetõk ki, melyek alkalmazása igen csak megnöveli az adatbázis programozók hatékonyságát.
- Ebben a modellben nincsenek kitüntetett adatok, azaz a halmaz elemeirõl nyilvántartott tulajdonságok egyenrangúak.
- A rendszer ez által sokkal rugalmasabban használható, mivel a keresési feltételek szinte tetszõlegesen megfogalmazhatók.
- Az IBM volt az elsõ olyan cég, mely relációs modell elõtti, és a relációs modelleket támogató adatbáziskezelõ-rendszert is árusított.
- Napjainkra a relációs modellen alapuló adatbázisrendszerek ugyanolyan elterjedt számítógépes eszköznek számítanak, mint korábban a szövegszerkesztõ, táblázatkezelõ programok.

Adat és információ
Az információ észlelt, érzékelt, felfogott és a fogadó számára szükséges, újdonságot jelentõ adat, amit megszerzett ismereteinktõl függõen értelmezünk.
Az adat fogalmán valamilyen tény megjelenését értjük, amit rögzíteni, tárolni, átalakítani és továbbítani tudunk. Az adat fogalma igencsak tág.
Az adatbázis-kezelés szempontjából az adat a számítógépen tárolt információ nélküli jelsorozat, amelybõl a feldolgozás során nyerhetünk információt.
Adatbázis:
Ha adatokat gyûjtünk össze, és azokat a közöttük fennálló összefüggésekkel együtt egy helyen tároljuk, akkor az így létrehozott együttest adatbázisnak nevezzük: Például: betegek kartonjai a kórházban, autók adatai a rendõrségen, egy telefonkönyv bejegyzései.
Adatbázis az integrált, logikailag összetartozó információk összessége; az adatok és a köztük lévõ összefüggések rendszere, melyet egymás mellett tárolunk.
Az adatbázis egy olyan adatgyûjtemény, amely szervezett módon tárolja az adott feladathoz kapcsolódó adatokat, gondoskodik az adatokhoz való hozzáférésrõl, mindemellett az adatok integritásának megõrzését, és az adatok védelmét biztosítja. Az adatbázis-kezelõ rendszerek
Ahhoz, hogy a késõbbiekben hatékonyan tudjunk dolgozni az adatbázissal, fontos, hogy jól megtervezzük a szerkezetét.
Az adatbázis rendszer magába foglalja az adatbázisokat, a számítógépes erõforrásokat, sõt tágabb értelemben ide vehetjük az adatbázis-adminisztrátorokat, akik azok a személyek, akik az adatbázisok kezelését, tervezését végzik.

Az adatbázis kezelõ rendszerek (ABKR / DBMS)
- Az adatbázis-kezelõ rendszerek megkönnyítik az adatbázisok kezelését. Feladatuk az adatbázisban lévõ adatok rögzítése, tárolása, kezelése.

Az ANSI/SPARC modell a felhasználó és a számítógépes háttértárolón fizikailag tárolt adatok közötti kapcsolatot szemlélteti. Ez alapján három szintet különböztetünk meg:
• Külsõ szint, más néven felhasználói nézet, mely a felhasználó szemszögébõl vizsgálja az adatokat.
• Koncepcionális szint, mely magába foglalja az összes felhasználói nézetet. Az adatbázist ezen a szinten a logikai sémával adják meg.
• Belsõ szint, más néven fizikai szint, ez az adatoknak az adott számítógépes rendszerben való aktuális bemutatását jelenti.
Fizikai adatfüggetlenség:
A fizikai adatfüggetlenség azt jelenti, ha a belsõ szinten változtatást hajtunk végre, az nincs hatással a logikai sémára, így azon nem kell változtatásokat végrehajtanunk. Tehát, ha az adatok tárolásában változás történik, az nincs hatással a felette lévõ szintekre.
Logikai adatfüggetlenség:
A külsõ és a koncepcionális szint közötti adatfüggetlenség a logikai adatfüggetlenség.

Adatbázis-kezelõ rendszernek nevezik az olyan programrendszereket, melynek feladata az adatbázishoz történõ hozzáférések biztosítása és az adatbázis belsõ karbantartási feladatainak ellátása, azaz:
• Adatbázisok létrehozása
• Adatbázisok tartalmának definiálása
• Adatok tárolása
• Adatok lekérdezése
• Adatok védelme
• Adatok titkosítása
• Hozzáférési jogok kezelése
• Fizikai adatszerkezet szervezése

Fontos az adatbázis-architektúrák ismerete, mert nem igaz az, hogy bármely adatbázis-kezelõ ugyanúgy ki tudja szolgálni az igényeinket bármely környezetben!
1.) lokális adatbázisok
- az elsõ ilyen architekturális szint volt
- 1 gép, 1 adatbázis, 1 felhasználó
- 1980 körül (DBASE világ, DOS alapokon)
- A DOS eleve nem adott lehetõséget a több felhasználós üzemmódra, és a több szálon futtatásra - márcsak ezért sem volt hálózati ütközés, agy konkurens hozzáférés jellegû probléma.
- Ilyen adatbázisok voltak a dBase 3, 4, 5; ennek a továbbfejlesztett változata a Paradox 4, 5, 7; aminek stabilabb volt az adattábla–kezelése, de cserébe kaptunk egy sérülékeny indextáblát.
- egy adattábla – egy fájl; egy index – egy fájl; egy leíró tábla – egy fájl, check-feltételek egy táblához – egy fájl. Ha volt egy adatbázisom 100 táblával, akkor egy könyvtárban néhány 100 darab fájl jött létre és ezeket kezelte egy adatbázis–kezelõ motor.
- Fájl szinten dolgozott, bájtokat mozgatott és blokkokat kezelt. Mivel fájl szinten nyúlt hozzá, sérülékeny volt.
- sok fájl, sok sérülési, törlési lehetõség
- pl. MS Access (u.a. mint a paradox, vagy DBASE, csak mindent 1 file-ban tárol)
- sérülékeny ha nagy terheléssel akarjuk használni, de tanításra, ismerkedésre kiváló
- a forgalmi táblának, amiben folyamatosan növekszik a rekordok száma, vannak korlátaik - százezres nagyságrendig mûködik jól, onnantól belassul, és egyre gyakrabban jönnek a hibák
- a lokális-fájl alapú rendszereknek a teljesítõképessége kb. 100 000-es nagyságrendû.
- kicsiben jó, pl. mariska néni virágboltjába! (oda fölösleges oracle...)

2.) file-server architektúra
- kb. az 1990-es évek-ben
- Novell fénykora, megosztott könyvtár, abban a lokális adatbázis fájlok, mindenki számára írási-olvasási joggal
- ha ezeket többen akarták egyszerre használni, akkor konkurens hozzáférés probléma (a userek egyszerre akarták ugyanannak a táblának ugyanazt a rekordját módosítani)
- próbálkozás: DBASE-ben zárolták az adatbázist, vagy a táblát, - ez csak az enyém, csak én használom, ha végeztem, felszabadítom és te is használhatod.
- a zárolás nem a rendszer része volt, ezt a programozó vezérelte (sok probléma forrása, ha pl. elfelejtették felszabadítani a táblát...)
- karakteres felületen programozható, aránylag gyors a megfelelõ környezetben, csak nem túl megbízható
- nem volt eszköz a konkurens hozzáférés problémájának orvoslására
- Voltak próbálkozások, hogy amikor az egyik felhasználó dolgozik vele, akkor lemásolja, a teljes adatbázist magának, abban dolgozott, kinaplózta a különbségeket, amiket õ csinált, és amikor visszatöltötte, csak különbségeket vitte a napló alapján föl. De ezt csak este lehetett, amikor más nem nyúlt az adatbázishoz.

3.) Kliens-szerver architektúra
- van egy szerver, ez nyújt szolgáltatásokat, és vannak a kliensek, amik ezt használják
- adatbázis-kezelésnél a szerver nem feltétlenül egy "nagy böhöm gép" és a kliensek laptopok, hanem az a server, ami az adatbázis szolgáltatást nyújtja, ez akár egy kis laptop is lehet, és ugyanúgy csatlakozhatunk rá egy laptoppal, mint kliens.
- a serveren alapból nincs meg az adatbázis szolgáltatás, ezt telepítenünk kell! (SQL server)
- itt a kliens csak egy kérést küld a szervernek, ott az sql szerver szedi össze, és küldi vissza az eredményt
pl. oracle, IBM db2, MS SQL server , interbase - fizetõsök
firebird (ez is interbase), postgre, mysql - ingyenesek

3.) Multi-tier (többrétegû architektúra)
- itt már nem feltétlen hardverekre, hanem logikai rétegekre gondolunk
- van a kliens-szerver architektúra, e közé, a SQL szerver és kliens p	rogramok közé építünk be 1-2 köztes réteget
- ezt a réteget kereshetik meg a kliensek a kéréseikkel, és csak ez a réteg tud az adatbázishoz nyúlni, és választ adni a klienseknek
- a kliensek nem tudnak közvetlen az adatbázishoz kérdéssel fordulni, sem hozzányúlni!
- itt nem az SQL szerver által menedzselt adatbázisban tárolt eljárásokat hívogatja a kliens, hanem a köztes rétegben tároltakat (üzleti logika - BL - Business Logic Layer, ami egy eljárás-függvény-metódus gyûjtemény gyakorlatilag)
- tehát ezek a kliensek a BL-el kommunikálnak, ezt nem lehet megkerülni!
(pl. nem kell kliensprogit a gépre tenni, hanem böngészõbõl egy adott webcímen keresztül kommunikálok)

5.) Vastag kliens
- képes arra, hogy önmaga hajtson végre nagyobb adatmennyiségekkel feldolgozásokat, amikor a szerver inkább elsõdleges tárolóként viselkedik.
- Ennek ellenére, a kifejezés inkább a számítógép szoftverére vonatkozik
- egyre inkább alkalmazzák hálózati számítógépek esetén, ahol a számítógép jelentõs hálózati alkalmazásokat (is) futtat.

6.) Vékony kliens
- egy minimális eszközökkel rendelkezõ kliens
- a szükséges erõforrásokat is a távoli (host) gépen veszi igénybe.
- feladata többnyire kimerül az alkalmazás szerver által küldött adatok grafikus megjelenítésében
- a tényleges, nagy mennyiségû adat mozgatását, kezelését igénylõ feladatot az alkalmazás szerver végzi el.

Alapvetõ szerkezetek
- Séma: minden adatbázisnak van egy belsõ struktúrája, ami tartalmazza az összes adatelem és a közöttük lévõ kapcsolatok leírását. Ezt a struktúrát az adatbázis sémájának nevezzük.
- a legjelentõsebb metaadatok az adatok típusának definícióját, az egyes adatok azonosítására szolgáló neveket tartalmazzák, utalásokat arra, hogy milyen kapcsolatok, összefüggések vannak az adatok között, valamint az adatbázis adminisztrációjával kapcsolatos információkat. Azaz segítségükkel tudjuk tárolni a tényleges adatok melletti strukturális információt. Az adatbázis felépítése az
van néhány általános elv amelyet minden adatbázison alapuló alkalmazás használ:
- tábla, vagy adattábla: egy kétdimenziós tábla, mely a logikailag szorosan összetartozó adatokat szemlélteti. A tábla oszlopokból és sorokból áll.
- rekord: az adatbázis egy sora. Egy rekordban tároljuk az egymással összefüggõ adatokat.
- A tábla sorai tartalmazzák az egyes tulajdonságok konkrét értékeit.
- A mezõ, a tábla egy oszlopa. Minden egyes oszlop az adott dolog egy jellemzõjét jelenti, mely névvel és típussal van ellátva.
- Az elemi adatok, a tábla celláiban szereplõ értékek, melyek az egyed konkrét tulajdonságai.
- Az egyed az, amit le akarunk írni, amelynek az adatait tároljuk és gyûjtjük az adatbázisban. Az egyedet idegen szóval entitásnak nevezzük.
- Egyednek tekintünk például egy személyt. Egyednek nevezzük azokat a dolgokat, objektumokat, amelyek egymástól jól elkülöníthetõk, melyekrõl adatokat tárolunk és tulajdonságokkal jellemzünk. Egyedek lehetnek például a dolgozó, kifizetés, anyag, személy, stb.
- Ebben a formában az egyed mint absztrakt fogalom szerepel. Mondhatjuk azt is, hogy az egyed konkrét dolgok absztrakciója. Az absztrakt egyedekre szokás használni az egyedtípus kifejezést is.
- Az attribútum, a tulajdonság, az egyed valamely jellemzõje. Az egyed az attribútumok összességével jellemezhetõ.
- Egy személy egy jellemzõje lehet például a neve.
- Az egyed típus az egyedre vonatkozóan megadott tulajdonságok összessége.
- Például egy személy leírható a nevével, a születési dátumával, testmagasságával, haja és szeme színével együttesen.
- Az egyed elõfordulás az egyedre megadott konkrét tulajdonságok.
- Például Koltai Lea Kiara 5 éves, barna hajú, barna szemû, 110 cm magas, óvodás.
- Az egyed elõfordulások a rekordoknak felelnek meg.
- A gyakorlatban az egyedtípust szokás rekordtípusnak is nevezni. (rekord-vagy struktúratípus).
- Adatredundancia, amikor egy adatot egynél több helyen tárolunk egy számítógépes rendszerben, adatredundanciáról beszélünk.
- Mivel szinte lehetetlen elkerülni a redundanciát, arra kell törekednünk, hogy a többszörös elõfordulásokat minimálisra redukáljuk. Ennek módszere, hogy az ismétlõdõ adatokat az adatbázis tervezése során kiemeljük, és külön tároljuk, a megfelelõ helyen hivatkozva rá.



2.Adatmodellek fejlõdése , a relációs adatmodell jellemzése

Adatmodellek fejlõdése
- Az informatikában azokat a modelleket nevezzük adatmodelleknek, amelyek az adatok szerkezetének leírására szolgálnak.
- 3 modell terjedt el
- kialakulóban van a 4., az objektum orientált modell

1.) hierarchikus
- ez a legõsibb adatmodeel
- az adatokat hierarchikus szerkezetben tárolja, ez leginkább egy fához hasonlítható
- A fa mindegyik csomópontja egy rekordtípusnak felel meg.
- Az adatok között un. szülõ-gyermek kapcsolat van.
- Minden adatnak tetszõleges számú leszármazottja lehet, de csak egy õse.
- Ez a modell leginkább egy-egy és egy több jellegû kapcsolatok megvalósítására alkalmazható.
- Napjainkra ezt a modellt teljesen kiszorította a relációs adatmodell.
- Az adatbázis több egymástól független fából állhat.
- A fa csomópontjaiban és leveleiben helyezkednek el az adatok.
- A közöttük levõ kapcsolat, szülõ gyermek kapcsolatnak felel meg. Így csak 1:n típusú kapcsolatok képezhetõk le segítségével.
- Az 1:n kapcsolat azt jelenti, hogy az adatszerkezet egyik típusú adata a hierarchiában alatta elhelyezkedõ egy vagy több más adattal áll kapcsolatban.
- A hierarchikus modell természetébõl adódóan nem ábrázolhatunk benne n:m típus÷ kapcsolatokat (lásd a háló modellt).
- Emellett további hátránya, hogy az adatok elérése csak egyféle sorrendben lehetséges, a tárolt hierarchiának megfelelõ sorrendben.
- alkalmazására példa: családfa, fõnök-beosztott viszony, iskola szerkezete

2.) hálós
- ez a modell a hierarchikus modell továbbfejlesztése
- egy egyedtípusnak több õse is lehet, az adatok között tetszõleges kapcsolatrendszer alakítható ki.
- tehát nem csak fa, hanem tetszõleges gráf is kialakítható segítségével
- ebben az adatmodellben kezelhetõek a több-több kapcsolatok is.
- hátránya, hogy nagy a tárigénye
- nagy gépes környezetben fordul elõ
- mára elavult
- A hálós adatmodell esetén az egyes azonos vagy különbözõ összetételû adategységek (rekordok) között a kapcsolat egy gráffal írható le.
- A gráf csomópontok és ezeket összekötõ élek rendszere, melyben tetszõleges két csomópont között akkor van adatkapcsolat, ha õket él köti össze egymással.
- Egy csomópontból tetszõleges számú él indulhat ki, de egy él csak két csomópontot köthet össze.
- Azaz minden adategység tetszõleges más adategységekkel lehet kapcsolatban.
- ebben a modellben n:m típusú adatkapcsolatok is leírhatók az 1:n típusúak mellett.
- A hierarchikus és a hálós modell esetén az adatbázisba fixen beépített kapcsolatok következtében csak a tárolt kapcsolatok segítségével bejárható adat-visszakeresések oldhatók meg hatékonyan (sok esetben hatékonyabban, mint más modellekben).
- További hátrányuk, hogy szerkezetük merev, módosításuk nehézkes.

3.)Relációs
- kidolgozása Codd nevéhez fûzõdik (1971)
- A relációs adatszerkezet egyszerûen értelmezhetõ a felhasználók és az alkalmazás készítõk számára is, így ez lehet közöttük a kommunikáció eszköze.
- A logikai adatmodell relációi egy relációs adatbázis kezelõ rendszerbe módosítások nélkül átvihetõk.
- A relációs modellben az adatbázis tervezés a normál formák bevezetésével egzakt módon elvégezhetõ
- A relációs adatmodell jellemzõje, hogy az adatokat több, egymással összekapcsolt rendszerben ábrázolja.
- Manapság ez a legelterjedtebb adatmodell.
- Alapját a matematikában is használatos reláció jelenti.
- Egy új módszert alkalmaz az adatbázis lekérdezések megvalósítására a relációkon értelmezett mûveletek segítségével.
- Az SQL (Structured Query Language) Strukturált lekérdezõ nyelv egy komplex adatbázis-lekérdezõ nyelv, mellyel megvalósíthatjuk a lekérdezéseket és különbözõ adatbázis-kezelõ mûveleteket.
- Ebben a modellben az adatokat egy kétdimenziós táblában elrendezve ábrázoljuk, melyben az adatok egymással logikai kapcsolatban állnak.
- A reláció nem más mint egy táblázat, a táblázat soraiban tárolt adatokkal együtt.
- A relációs adatbázis pedig relációk és csak relációk összessége.
- Az egyes relációkat egyedi névvel látjuk el.
- A relációk oszlopaiban azonos mennyiségre vonatkozó adatok jelennek meg.
- Az oszlopok névvel rendelkeznek, melyeknek a reláción belül egyedieknek kell lenniük, de más relációk tartalmazhatnak azonos nevû oszlopokat.
- A reláció soraiban tároljuk a logikailag összetartozó adatokat.
- A reláció sorainak sorrendje közömbös, de nem tartalmazhat két azonos adatokkal kitöltött sort.
- Egy sor és oszlop metszésében található táblázat elemet mezõnek nevezzük, a mezõk tartalmazzák az adatokat.
- A mezõkben oszloponként különbözõ típusú (numerikus, szöveges stb.) mennyiségek tárolhatók.
- A reláció helyett sokszor a tábla vagy táblázat, a sor helyett a rekord, az oszlop helyett pedig az attribútum elnevezés is használatos.
- Az oszlopok elnevezésére célszerû a tartalomra utaló elnevezést  használni
- A relációktól általában megköveteljük, hogy ne tartalmazzanak más adatokból levezethetõ vagy kiszámítható információkat.
A táblázattal kapcsolatos alapkövetelmények:
- Minden táblázat egyértelmû azonosítóval bír.
- A sorok és oszlopok metszéspontjában található adatok egyértékûek, ezeket nevezi elemi adatmezõknek.
- Az oszlopokban lévõ adatok azonos jellegûek.
- Minden oszlopnak egyedi neve van.
- Ugyan annyi adat található a táblázat minden sorában.
- Nem lehet két azonos sor a táblázatban.
- A sorok és oszlopok sorrendje tetszõleges.
KULCS
- Fontos szerepe van azoknak a tulajdonságoknak, amelynek értékei a többi tulajdonság értékeit egyértelmûen meghatározzák.
- Ez azt jelenti, hogy ha az ilyen tulajdonságok értékeit megadjuk, akkor az egyértelmûen definiál egy elõfordulást.
- Azokat a tulajdonságokat, amelyek egyértelmûen meghatározzák az egyedtípus egy elemét, kulcsnak nevezzük.
- szerepük fontos, a tervezés során meg szokták adni, hogy mely tulajdonságok legyenek kulcsok, 1 egyednek több kulcsa is lehet, de 1-et szoktak megadni!
- ha ebbõl egy tábla esetében 1 darab van (tehát 1 tulajdonság ami alkalmas az egyértelmû azonosításra), akkor elsõdleges kulcs!
- Kulcsjellegû tulajdonság mindig található. Ha a tényleges adatok között nem lenne ilyen, akkor bevezethetünk egy olyan tulajdonságot, amelynek értékei sorszámok, kódszámok, speciális azonosítók.
KAPCSOLAT
- Kapcsolatnak nevezzük az egyedek közötti összefüggést, viszonyt.
- kapcsolatok az egyedhalmazok elemei között alakíthatók ki.
- osztályozhatjuk a kapcsolatokat aszerint, hogy egy-egy elemhez hány másik elem tartozik.  (1:1, 1:n, n:m)
- az egy egyed elõforduláshoz szintén 1 egyed elõfordulás tartozik (1:1)-et egyszerûbb megvalósítani, mint ha többhöz több tartozna! az elõbbihez elég lehet egy mutató, míg az utóbbihoz összetett adatstruktúra, halmaz, esetleg lista szükséges.
- 1:1, az egyik egyed minden egyes elõfordulásának a másik egyed pontosan egy elõfordulása tartozik. pl. a férfi és nõ között a házassági viszony
- 1:n, 1 egyed minden elõfordulásához, a másik egyed több elõfordulása tartozik. pl. bérszámfejtõ rendszerben a dolgozók- kifizetések. (1 dolgozóhoz több kifizetés, de 1 kifizetés csak 1 dolgozóhoz!)
- n:m, mindkét egyed elõfordulásaihoz a másik egyed több elõfordulása tartozhat. pl. Egy dolgozó több témában is tevékenykedhet és egy témán több dolgozó dolgozhat.
- minden sok-sok kapcsolat felbontható két 1-sok kapcsolatra. (mert ha 1 egyed szempontjából nézzük, akkor az 1-sok kapcsolat)
- ezek (1:1, 1:n, n:m) két egyed között létesíthetõ kapcsolatok, tehát bináris kapcsolatok!



3.Normalizálás,normál formák,funkcionális és tranzitív függések,kulcsok,elsõdleges és idegen kulcs

Normalizálás:
- A relációs adatbázis felépítésének alapja
- az adatok optimális elhelyezési módját megadó módszert jelenti.
- lehetõvé teszi az adatok megfelelõ strukturálását, valamint elõsegíti az anomáliák (ellentmondások az adatszerkezetben) kiküszöbölését és a redundancia csökkentését.
Anomáliák:
- Beszúrási anomália: egy rekord felvétele egy másik, hozzá logikailag nem kapcsolódó adat beszúrását kívánja meg.
- Törlési anomália: az elem törlésekor a nem hozzá tartozó adatcsoportot is elveszítjük.
- Módosítási anomália: egy adat megváltoztatása miatt, az adat összes elõfordulási helyén el kell végezni a módosításokat az adatbázisban.
Függõségek:
- Funkcionális függõség: ha egy rendszerben szereplõ egyik tulajdonságtípus bármely értékéhez egy másik tulajdonságtípusnak csakis egy értéke rendelhetõ hozzá.
- Például: egy személyi számhoz csak egy név tartozhat, de ugyanahhoz a névhez több személyi adatazonosító szám is kapcsolódhat. Egy a többhöz kapcsolat. A funkcionális függoség jobb oldalán több attribútum is állhat.
- Például az AUTÓ_RENDSZÁM -> TIPUS, TULAJDONOS funkcionális függoség azt fejezi ki, hogy az autó rendszámából következik a tipusa és a tulajdonos neve, mivel minden autónak különbözo a rendszáma, minden autónak egy tulajdonosa és tipusa van. Ezt diagrammal is ábrázolhatjuk.
- Kölcsönös funkcionális függõség: ha az elõbbi feltétel mindkét irányba igaz.
- Például: rendszám – motorszám. Egy az egyhez kapcsolat.
- Az is elõfordulhat, hogy két attribútum kölcsönösen függ egymástól. Ez a helyzet például a házastársak esetén FÉRJ_SZEM_SZÁMA -> FELESÉG_SZEM_SZÁMA FELESÉG_SZEM_SZÁMA <-FÉRJ_SZEM_SZÁMA. Mindkét funkcionális kapcsolat igaz és ezt a FÉRJ_SZEM_SZÁMA <-> FELESÉG_SZEM_SZÁMA jelöléssel fejezzük ki.
- A funkcionális függõség bal oldalán több attribútum is megjelenhet, melyek együttesen határozzák meg a jobb oldalon szereplõ attribútum értékét. Például hõmérsékletet mérünk különbözõ helyeken és idõben úgy, hogy a helyszínek között azonosak is lehetnek. Ebben az esetben a következõ funkcionális függõség áll fenn az attribútumok között: HELY, IDÕPONT -> HÕMÉRSÉKLET.
- Funkcionálisan függetlenek: ha ez elõbbi viszony a két tulajdonságtípus között nem áll fenn. Például: tanuló szemének a színe és az iskola helye.
- Tranzitív funkcionális függõség: ha az egyedtípuson belül egy leíró tulajdonságtípus konkrét értékei meghatároznak más leíró tulajdonság értékeit.

Reláció kulcs
- a reláció egy sorát azonosítja egyértelmûen.
- minden relációnak létezik kulcsa, mivel a definíció szerint sem tartalmazhat 2 azonos sort!
a reláció kulcsnak a következõ feltételeket kell teljesítenie:
- az attribútumok egy olyan csoportja, melyek csak egy sort azonosítanak (egyértelmûség)
- a kulcsban szereplõ attribútumok egyetlen részhalmaza sem alkot kulcsot
- a kulcsban szereplõ attribútumok értéke nem lehet definiálatlan (NULL)
(numerikus értékek esetén a null, és 0 nem azonos!)

- ha csak egy atribútum a kulcs, akkor az elsõdleges kulcs
- ha több atribútumból áll a kulcs, akkor az az összetett kulcs
- egy táblában több darab kulcs is lehet! (A KONZULTÁCIÓ relációban a tanár illetve a diák oszlopban olyan azonosítót képzelünk, mely a személyt egyértelmûen azonosítja (például személyi szám). Minden egyes diák több konzultáción vehet rész, minden tanár több konzultációt tarthat, sõt ugyanaz a diák ugyanannak a tanárnak más-más idõpontokban tartott konzultációin is részt vehet. Ezekbõl következik, hogy sem a TANÁR, sem a DIÁK, sem pedig ez a két azonosító együtt nem kulcsa a relációnak. De egy személy egy idõben csak egy helyen tartózkodhat. Ebbõl következik, hogy a TANÁR, IDÕPONT attribútumok kulcsot alkotnak, de ugyanilyen okból kifolyólag a DIÁK, IDÕPONT attribútumok is kulcsot alkotnak)
- a kulcsok nem önkényes döntések következtében alakulnak ki, hanem az adatok természetébõl következnek, mint a funkcionális vagy a többértékû függõség.
- idegen/külsõ kulcs: Ezek az attribútumok nem az adott relációban, hanem az adatbázis másik relációjában alkotnak kulcsot. Például ha a KONZULTÁCIÓ relációban a DIÁK azonosítására a személyi számot alkalmazzuk, akkor ez egy külsõ kulcs a személyi adatokat nyilvántartó relációhoz.

Adatmodell hibák:
- hibák(anomáliák) pl: (mert nem csak egy egyedre jellemzõ tulajdonságokat tárolunk egy táblában, vagy bizonyos tulajdonságokat többszörösen tárolunk).
- bõvítési anomália: nem tudunk a táblába új rekordot felvinni
- módosítási anomália: valamely attribútum értéket több táblában is tárolunk, de nem tudjuk egységesen módosítani
- törlési anomália: valamely táblában törlünk 1 adatot, és ezzel fontos információk is elvesznek
Redundancia:
- átfedést jelent
- gyakorlatban legtöbbször a fizikai átfedést értjük alatta - többször tárolunk 1 adatot az adatbázisban... logikai átfedésre is figyelni kell a tervezéskor!
- Logikai átfedés: Nyílt logikai átfedés: ugyanaz a tulajdonságtípus azonos elnevezéssel több egyednél is szerepel. Többszörös tárolást eredményez. Szükséges lehet biztonsági, vagy hatékonysági okból, vagy pl.: kapcsolatok megvalósításához (idegen kulcsként) Itt a logikai átfedés hiánya szintén hibának számít.
Rejtett logikai átfedés (szinonima jelenség): ugyanazt a tulajdonságot jelöljük különbözõ elnevezéssel.
Látszólagos logikai átfedés (homonima jelenség): különbözõ tulajdonságokra használjuk ugyanazon elnevezést.
-Fizikai átfedés: ugyanazon tulajdonságoknak vagy -szinonim névvel -egyednek többszörös tárolása az adatbázisban.
A redundancia hátrányai:
- mivel többször szerepel az adat, ha módosítani kell, akkor ezt többször kell megtennünk
... van még

- redundancia fordul elõ akkor is, ha levezetett vagy levezethetõ mennyiségeket tárolunk a relációkban. Levezetett adatokat tartalmazhat egyetlen reláció is abban az esetben, ha egyes attribútumok értéke egyértelmûen meghatározható a többi attribútum alapján, például, ha a kerületet is nyilvántartjuk az irányítószám mellett. A redundáns adatok
eltüntetésére 2 mód:
- A levezetett adatokat tartalmazó relációkat vagy attribútumokat el kell hagyni.
A relációkban tárolt redundáns tényeket a táblázatok szétbontásával, de kompozíciójával szüntethetjük meg !

A redundancia eltüntetése:
- ez a logikai tervezés célja (redundancia mentes relációs adatbázis)
- a módszer a normál formák alkalmazása
- 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.
Öt normál formát különböztetünk meg. A különbözõ normál formák egymásra épülnek, a második normál formában levõ reláció elsõ normál formában is van.
- A tervezés során alegmagasabb normál forma elérése a cél!
- 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.

- Elsõ normál forma: a relációban minden érték elemi, a reláció nem tartalmaz adatcsoportot. A reláció minden sorában oszloponként egy és csak egy érték áll, az értékek sorrendje minden sorban azonos, minden sor különbözõ. Van legalább egy vagy több tulajdonság, amelyekkel a sorok egyértelmûen megkülönböztethetõk egymástól.
- Második normál forma: a reláció elsõ normálformában van, valamint egyetlen másodlagos attribútuma sem függ egyetlen kulcsának valódi részhalmazától sem. (Elsõdleges attribútumok, azok az attribútumok, melyek valamely kulcshoz tartoznak, másodlagos attribútumok, amelyekre ez nem teljesül.)
- Harmadik normál forma: a reláció második normálformában van és a másodlagos attribútumok között nincs funkcionális függés. Ha „B” attribútum értéke függ „A” attribútum értékétõl, valamint „C” attribútum étéke tranzitíven függ „A” értékétõl. A harmadik normál forma elengedhetetlen követelménye az ilyen tranzitív függések kiküszöbölése. Ha az adatbázis táblája nem harmadik normálformájú, akkor két táblára kell bontani úgy, hogy az egyes táblák külön-külön már harmadik normálformájúak legyenek.
Boyce/Codd normál forma (BCNF)  : többkulcsos relációkra vonatkozik!
- 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.
- Minden elsõdleges attribútum teljes funkcionális függõségben van azokkal a kulcsokkal, melyeknek nem része
Negyedik normál forma (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, ha egy XY többértékû függõséget tartalmazó relációban csak az X és Y-ban megtalálható attribútumokat tartalmazza.
Ötödik normál forma (5NF)
Hosszú ideig a negyedik normál formát tartották a normalizálás utolsó lépésének. A többértékû függõségek külön relációkban tárolásával azonban információt veszthetünk.



4.DDL alapja

A DDL elemei

create
- create table <táblanév> parancsal hozunk létre táblákat
- 1 táblában max 1000 oszlop lehet
- Csak az a felhasználó hozhat létre táblákat, aki CREATE TABLE vagy CREATE ANY TABLE privilégiummal rendelkezik.
STORAGE ????

alter:
- módosításra szolgál
- Az oszlop hosszát lehet növelni még akkor is, ha a tábla adatokat tartalmaz. Az oszlop hosszát pedig csak akkor lehet csökkenteni, ha a tábla üres.
ALTER TABLE testtab ADD col2 VARCHAR2(100);
ALTER TABLE testtab MODIFY col2 VARCHAR2(150);
ALTER TABLE testtab DROP col1;

RENAME testtab TO testtab1;

DROP TABLE testtab;

- Amikor egy olyan táblára (vagy más Oracle-objektumra) hivatkozunk, melynek nem mi vagyunk a tulajdonosa, akkor a tábla nevén kívül meg kell adni a tulajdonos nevét is
tulajdonos.tábla_név


Megszorítások:

Hivatkozási integritás: biztosítja, hogy egy adott oszlop csak olyan értékeket vehessen fel, amelyek megjelennek egy másik oszlopban.
Integritási megszorításként lehet elõírni.
Megszorítás: egy szabály vagy korlátozás az adatok egy részén kerül ellenõrzésre.
Integritási megszorítás: olyan szabály, amely egy vagy több oszlop lehetséges értékeinek körét határolják be.
Táblamegszorítás – olyan integritási megszorítás, amelyet egy tábla több oszlopára alkalmazunk. Oszlopmegszorítás pedig egy olyan integritási megszorítás, amelyet egy tábla oszlopához rendelünk.

- A megszorítást a tábla létrehozásánál az oszlopokhoz lehet hozzárendelni.
- A CONSTRAINT záradékot a CREATE TABLE vagy ALTER TABLE parancsokban használhatjuk.
- A legtöbb megszorítás a CONSTRAINT záradék nélkül is megadható.

táblamegszorítások:
UNIQUE
PRIMARY KEY
FOREIGN KEY
REFERENCES ON DELETE CASCADE
CHECK
ENABLE
VALIDATE
DISABLE

oszlopmegszorítások:
NULL
NOT NULL
+ a tábláknál lévõk

ALTER TABLE tabla DISABLE UNIQUE oszlop, oszlop,..
ALTER TABLE tabla DISABLE PRIMARY KEY
ALTER TABLE tabla DISABLE CONSTRAINT megszorítás_név
DISABLE ALL TRIGGERS



5.A DML alapjai

DML - data manipulating language

- INSERT – új sor beszúrása
- UPDATE – adatok módosítása a már létezõ sorokban
- DELETE – sorok törlése
- TRUNCATE – az összes sorok gyors törlése

1.) INSERT

describe testtab - ezzel ellenõrizhetjük a táblát (megjeleníti)
INSERT INTO testtab(col1, col2) VALUES(’szöveg’, 123);  - beszúrjuk ezt a 2 sort
*INSERT INTO testtab VALUES (’szöveg’, 123);  - ugyanaz (gondolom mivel 1-1 ilyen mezõ van csak, így egyértelmû neki hogy melyik hova való az oszlopok megadása nélkül is?)
NULL-t is beszúrhatunk. ezt ugyan úgy nem kell idézõjelek közé tenni mint a számokat.

*INSERT INTO testtab (col1, col2) SELECT e_name, emp_no FROM emp - több sor beszúrása
CREATE TABLE table_copy AS SELECT * FROM table - tábla létrehozása egy másik tábla alapján
CREATE TABLE emp_copy2 AS SELECT emp_no, e_name FROM emp WHERE e_name LIKE ’%a%’; - ez is...

2.) Update
- Az UPDATE parancs módosítja az összes olyan sorokat, amelyekre teljesül a WHERE-feltétel.
- ha nincs benne where, akkor minden sorra végrehajtódik! (nagyon ritkán fordul elõ...)

update <táblanév> where ...

3.) delete
delete from <táblanév> where ...

truncate:
- Adatok gyors törlése. A tábla összes sorait gyorsan lehet törölni a TRUNCATE paranccsal:
- A parancs végrehajtása után a tábla struktúrája megmarad, de az egyetlen sort sem fog tartalmazni.

TRUNCATE TABLE <táblanév>;



6.Egy táblára vonatkozó lekérdezések oszlopok,rekordok,szûrés

Lekérdezések (SELECT):

- általánosan:
SELECT <oszlopnévlista> from <táblanév>;
SELECT * from table; - ez mindent megjelenít

- aliasnevet is adhatunk, ez csak a lekérdezés idejére jön létre:
SELECT nev as NÉV from table; - így az eredetileg nev mezõ NÉV nevûen fog megjelenni a lekérdezésben

ALL - ha egy rekord többször is elõfordul az eredménytáblában, akkor ez megjeleníti (alapértelmezésben is ígyvan)
DISTINCT - minden azonos elõfordulás csak egyszer jelenik meg az eredménytáblában


Aggregáló függvények:
- az adott oszlop függvény szerint aggregáltját adja vissza
Az <oszlopkifejezés> a következõ aggregáló függvényeket tartalmazhatja:
- COUNT: Megadja a tábla sorainak számát. A pontos eredmény elérése céljából használjuk a *-ot vagy az elsõdleges kulcs mezõt paraméternek.
- SUM: Megadja a paraméterében szereplõ oszlop adatainak az összegét az összes rekordra. Csak numerikus attribútumra alkalmazható.
- AVG: Megadja a paraméterében szereplõ oszlop adatainak az átlagát az összes rekordra. Csak numerikus attribútumra alkalmazható.
- MIN: Megadja a paraméterében szereplõ oszlop adatainak a minimumát az összes rekordra. Csak numerikus attribútumra alkalmazható.
- MAX: Megadja a paraméterében szereplõ oszlop adatainak a maximumát az összes rekordra. Csak numerikus attribútumra alkalmazható.

Példák:
dolgozó tábla használata esetén

- teljes tábla lekérdezése
SELECT * FROM dolgozo;
- lekérdezzük a dolgozók nevét a fizetésükkel együtt:
SELECT neve, fizetese FROM dolgozo;
- lekérdezzük a dolgozók nevét, fizetését, és egy új mezõben a 20%-al megemelt fizetést a "dolgozó megemelt fizetése" néven:
SELECT neve, fizetese, 1.2*fizetese AS emelt fizetés FROM dolgozo;
- jelenítsük meg a dolgozók városát úgy, hogy minden város csak egyszer fordul elõ:
SELECT DISTINCT varos FROM dolgozo;
- lekérdezés amely megadja az összes dolgozók számát, az összes, átlagos, legnagyobb és legkisebb fizetéseket:
SELECT COUNT(id) AS 'dolgozók száma', SUM(fizetes) AS 'összes fizetés', AVG(fizetes) AS 'átlagos fizetés', MIN(fizetes) AS 'legkisebb fizetés', MAX(fizetes) AS 'legnagyobb fizetés' FROM dolgozo;
- lekérdezés amely a dolgozó nevét és születési évét adja meg (az évet az oracle beépített függvényével) :
SELECT neve, TO_CHAR(szdatum, 'yyyy') AS 'év' FROM dolgozo;
A TO_CHAR függvény a szdatum mezõben tárolt dátum típusú értéket a megadott formátumúra alakítja, esetünkben 4 jegyû évvé.


WHERE(szûrés):
- a FROM után adhatjuk meg az alparancsot (WHERE <feltétel>)
- a feltételben operanduszok és operátorok szerepelhetnek
- operátorok lehetnek: összehasonlító (<,>,<=,>=,<>), aritmetikai (+,-,*,/) és logikai mûveletek (AND, OR, NOT,
- operanduszok lehetnek: konstansok, reláció attribútumok, (oszlopnevek), illetve függvényhivatkozások.
- a kifejezésnek mindig logikai értéket kell szolgáltatni
- az eredménytáblába csak a true értéket szolgáltató elõfordulások kerülnek bele.


Predikátumok:

BETWEEN
<oszlopkifejezés> BETWEEN <alsóérték> AND <felsõérték>
- a két érték szám vagy dátum, és az eredmény az egyenlõket is beleveszi, tehát zárt intervallumot fed le.
- csak akkor van értelme, ha a felsõérték nagyobb mint az alsó (értelem szerûen...)
- ez a predikátum helyettesíthetõ logikai operátorokból összerakott kifejezéssel is!
pl.: fizetes between 100000 and 200000 ugyan azt jelenti, mint (fizetes >= 100000) and (fizetes <= 200000)

IN
<oszlopkifejezés> IN <értéklista>
- megvizsgálja, hogy az <oszlopkifejezés> értéke szerepel-e az értéklistában
- ha igen, true-t ad vissza
- a NOT IN esetében akkor true, ha nem szerepel
- az <értéklista> paraméterben a kifejezés típusának megfelelõ értékeket kell vesszõvel elválasztva felsorolni
- kiemelt szerepe van a beágyazott lekérdezéseknél!

LIKE
<oszlopkifejezés> LIKE <karakterlánc>
- A <karakterlánc> konstansban idézõjelek között adhatunk meg karaktersorozatot.
- Ha a konstansban a % jelet használjuk, akkor a két karakterláncnak csak eddig a jelig kell egyezni ahhoz, hogy a feltétel igaz legye. (a % tetszõleges számú karaktert helyettesít)
- Az _ jel pontosan egy karaktert helyettesít.

Példák:
továbbra is a dolgozók tábla
- lekérdezés, amely megadja a dolgozók nevét és fizetését, akik 150 ezer forint felett keresnek:
SELECT neve, fizetese FROM dolgozo WHERE fizetese>=150000;
- lekérdezés amely megadja a dolgozók nevét, fizetését, azoknak akik egerben laknak és 150000 forint felett keresnek:
SELECT neve, fizetese FROM dolgozo WHERE (varos LIKE 'Eger') AND (fizetese>=150000);
- lekérdezés amely azon dolgozók nevét és fizetését adja meg, akik 150 és 200 ezer forint között keresnek:
SELECT neve, fizetese FROM dolgozo WHERE fizetese BETWEEN 150000 AND 200000;
SELECT neve, fizetese FROM dolgozo WHERE (fizetese>=150000) AND (fizetese<=200000);
- lekérdezés,ami megjeleníti azon dolgozók nevét, és városát akik egerben, debrecenben vagy szegeden laknak:
SELECT neve, varos FROM dolgozo WHERE varos IN 'eger','szeged','debrecen';
- lekérdezés, amely megadja a kovács nevû dolgozók adatait:
SELECT * FROM dolgozo WHERE neve LIKE 'Kovács%';



7.Csoportosító lekérdezések ,tovább-szûrés,rendezés

GROUP BY, HAVING (csoportosító lekérdezések), rendezés:

GROUP BY:
- A csoportosítás azt jelenti, hogy a rekordokat egy vagy néhány adott mezõ értékei szerint csoportokra bontjuk.
- Ezután a csoportokhoz tartozó rekordokra különbözõ mûveleteket hajthatunk végre, például alkalmazhatjuk a már ismert aggregációs függvényeket, esetleg a csoportokra vonatkozóan kiválasztó mûveletet alkalmazhatunk.
csoportosítani így lehet:
GROUP BY <oszlopnév>,[<oszlopnév>]…
- A csoportosítás a megadott oszlopnevek azonos értékei alapján fog történni.
- Amennyiben több oszlopot adunk meg, akkor az elsõ oszlop azonos értékein belül a második oszlop azonos értékei szerint csoportosít, majd a harmadik szerint, stb.
- Az egyes mezõkhöz tartozó értékeket a megadás sorrendjében egymás mellé rakja a rendszer, és az így kapott minta alapján csoportosít. A mûvelet végrehajtása után minden egyes csoportra egy sor keletkezik az eredménytáblában.
- Mivel speciális utasításról van szó, használata során a SELECT parancs egyéb részeire vonatkozóan is megkötéseket kell tennünk.
Így a lekérdezendõ oszlopok adataira vonatkozóan mindenképpen alkalmaznunk kell valamilyen aggregáló operátort, vagy ha ezt nem tesszük, akkor az oszlopnak szerepelnie kell a csoportosításban részt vevõ oszlopok között, azaz a GROUP BY után.

HAVING:
- Az SQL nyelv lehetõséget biztosít arra is, hogy az aggregálással keletkezett adatokra vonatkozóan feltételeket adhassunk meg.
- Ebben az esetben a HAVING szót kell használnunk. Az alparancs formája az alábbi:
HAVING <csoportfeltétel>
- A <csoportfeltétel> paraméterben a hagyományos módon adhatunk meg feltételeket, azzal a különbséggel, hogy a feltételben szereplõ oszlopneveknek tartalmazniuk kell valamilyen aggregáló operátort, és ennek ugyancsak szerepelnie kell a SELECT után.

ORDER BY:
- Az SQL lehetõséget biztosít arra, hogy lekérdezéseink eredményét rendezetten jelenítsük meg.
- ORDER BY alparancs. Formája a következõ:
ORDER BY <oszlopnév|oszlopsorszám> [ASC|DESC], <oszlopnév| oszlopsorszám> [ASC|DESC]]…
- A rendezés a megadott oszlopok szerint történik. Elsõ szempontként az elsõ oszlopot, további szempontként az utána megadott oszlopokat veszi figyelembe.
- Az oszlopok kétféleképpen adhatók meg. Egyrészt hagyományosan a nevükkel, másrészt egy számmal, ami a táblázatban az oszlop sorszáma. A számozás 1-tõl kezdõdik a táblázat fejrészében megadott sorrend szerint.
- A rendezési szempontként megadott oszlopnak szerepelni kell a SELECT parancs után is.
- ASC (alapértelmezés) - a rendezés növekvõ sorrendben történik
- DESC - a rendezés csökkenõ lesz a megadott szempontnál

Példák:
- lekérdezés amely megadja városonként, hogy az adottt városban hány dolgozó lakik
SELECT Varos, COUNT(id) as „DB” FROM dolgozo GROUP BY Varos
- lekérdezés, amely megadja városonként, hogy az ott lakó dolgozóknak mennyi az összes illetve az átlagfizetése:
SELECT SUM(fizetes) AS 'összes', AVG(fizetes) AS 'átlagos' FROM dolgozo GROUP BY varos;
- lekérdezés amely megadja azokat a városokat, amelyekre igaz, hogy az adott városban élõ dolgozóknak az átlagfizetése legfeljebb 150000 Ft:
SELECT varos, AVG(fizetes) AS 'átlag' FROM dolgozo GROUP BY varos HAVING(fizetes)<=150000;
- lekérdezés amely a dolgozók nevét és fizetését a fizetés szerint csökkenõ, illetve azonos fizetés esetén név szerint ábécé sorrendben adja meg:
SELECT neve, fizetes FROM dolgozo ORDER BY fizetes DESC neve;



8.Táblák összekapcsolása ,beágyazott lekérdezések

Táblák összekapcsolása:

feltételen alapuló összekapcsolás:
<táblanév> INNER JOIN <táblanév> ON <feltétel>
- Feltételként tetszõleges, a WHERE parancs után használható feltételt adhatunk meg.
- Esetek legnagyobb részében a két kapcsolt táblából az egyik tábla (Nevezzük master-nek) elsõdleges kulcs mezõjének értéke egyenlõ a másik tábla (nevezzük detail-nek) idegen kulcs mezõjének értékével.

Példa:
korábbi dolgozó tábla + kifizetés tábla, a kapcsolat a dolgozók id-je, és a kifizetés tábla dolgozó mezõje.etes.dolgozo
- lekérdezés amely a dolgozók nevét és a számukra kifizetett összeget, és a kifizetés dátumát név szerint ábécé sorrendben adja meg:
SELECT dolgozo.neve as „Név”, kifizetes.osszeg as „Összeg”, kifizetes.datum as „Dátum”
FROM dolgozo INNER JOIN kifizetes ON dolgozo.id = kifizetes.dolgozo ORDER BY 1;

Külsõ összekapcsolás:
- Amennyiben szeretnénk azokat a rekordokat is megjeleníteni, melyekhez nincs kapcsolt rekord a kapcsolt táblában külsõ összekapcsolást kell alkalmazni.
- Egy külsõ összekapcsolás abban különbözik a hagyományostól, hogy az eredménybe minden olyan sor is bekerül, amely a másik tábla egyetlen sorához sem kapcsolódik.
- Egy külsõ összekapcsolás háromféle módon valósulhat meg:
<táblanév> FULL OUTER JOIN <táblanév> ON <feltétel>
Ebben az esetben mindkét tábla "lógó" sorai bekerülnek az eredmény táblába.
<táblanév> LEFT OUTER JOIN <táblanév> ON <feltétel>
Ebben az esetben csak az elsõ <táblanév> paraméterben megadott tábla "lógó" sorai kerülnek be az eredmény táblába.
<táblanév> RIGHT OUTER JOIN <táblanév> ON <feltétel>
Ebben az esetben pedig a második <táblanév> paraméterben megadott tábla "lógó" sorai kerülnek be az eredmény táblába.

Példa:
- lekérdezés amely az elõzõ példában szereplõ feladatot úgy oldja meg, hogy a listába azok a dolgozók is belekerülnek, akiknek nem történt kifizetés:
SELECT dolgozo.neve AS 'név', kifizetes.dolgozo AS 'kifizetés, kifizetés.datum AS 'dátum' FROM dolgozo LEFT OUTERkifizetes ON dolgozo.nev=kifiz ORDER BY 1 ;

- Ha több táblát kell összekapcsolni, akkor minden összekapcsolás 1 JOIN lesz. (5 tábla esetén 4 JOIN lesz pl.)
- Szabály, hogy ha egy tábla nevét rövidítjük, akkor a teljes lekérdezésben a rövidített nevet kell használni.


Beágyazott lekérdezések:
- lehetõség van a kiválasztó lekérdezések feltételében is lekérdezõ parancsot használni
- ilyenkor megkülönböztetünk külsõ és belsõ select parancsot

attól függõen hogy a belsõ lekérdezés milyen eredményt szolgáltat, van többféle eset:
- A belsõ lekérdezés egyetlen értéket szolgáltat. Ez a legegyszerûbb eset, ugyanis ilyenkor minden a hagyományos módon történik, azzal a különbséggel, hogy a feltételként megadott kifejezésben a belsõ lekérdezés által szolgáltatott értéket használja fel a rendszer.

- A belsõ lekérdezés egyoszlopos relációt szolgáltat. Ekkor olyan feltételeket adhatunk meg, amelyek a belsõ lekérdezés által szolgáltatott oszlop adatait használja fel. Ebben az esetben különbözõ predikátumokat használhatunk.

Az alábbi három predikátum létezik:
<oszlopkifejezés> [NOT] IN <belsõ lekérdezés>
Ennél a típusnál az <oszlopkifejezés> paraméterben megadott kifejezés értékérõl fogja eldönteni a rendszer, hogy szerepel-e a belsõ lekérdezés által elõállított oszlop adatai között. Ha igen a feltétel értéke igaz, ha nem, akkor hamis lesz. A NOT kulcsszó hatására pontosan fordítva kell értelmezni a feltételt. A következõ predikátumok formája az alábbi:

[NOT] <oszlopkifejezés> <reláció> ALL|ANY <belsõ lekérdezés>
Ennél a típusnál az <oszlopkifejezés> paraméterben megadott kifejezés értékére vonatkozóan azt fogja vizsgálni a rendszer, hogy a megadott reláció teljesül-e a belsõ lekérdezés által elõállított oszlop adataira. Ha az ALL kulcsszót használjuk, a feltétel akkor lesz igaz, ha a reláció az oszlop minden elemére teljesül, míg az ANY használatakor elegendõ egyetlen elemre teljesülnie. A NOT kulcsszó itt is a feltétel ellentettjét jelenti.


A legáltalánosabb eset az, amikor a belsõ lekérdezés általános relációt szolgáltat. Ekkor csak kétféle feltételt vizsgálhatunk.
Az egyik az, hogy a keletkezett reláció üres vagy sem. Ehhez a vizsgálathoz az EXISTS kulcsszót kell használnunk, amit természetesen a NOT módosíthat. A parancs formája az alábbi:

[NOT] EXISTS <belsõ lekérdezés>
A másik eset hasonló az 2. pont elsõ részében leírtakhoz, azzal a különbséggel, hogy a feltételben több oszlopkifejezést adhatunk meg, amelyek egyezését külön külön fogja vizsgálni a rendszer a belsõ lekérdezés által adott tábla sorainak elemeivel. Természetesen a megadott lista és a lekérdezés eredménytáblája sorainak száma azonos kell hogy legyen. A pontos szintaxis a következõ:
(<oszlopkifejezés> [,<oszlopkifejezés>]…) [NOT] IN <belsõ lekérdezés>

példa
- Készítsünk olyan listát, amely a Dolgozó táblából kilistázza azon dolgozók nevét és fizetését, akik az átlag alatt keresnek!
SELECT Neve, Fizetes FROM Dolgozo WHERE Fizetes < (SELECT AVG(Fizetes) FROM Dolgozo)
- Készítsünk olyan listát, amely a Dolgozó táblából kilistázza azon dolgozók nevét és fizetését, akik a fizetése a legnagyobb fizetéstõl legfeljebb csak 50 000 Ft-tal tér el! Az alábbi parancsot használhatjuk:
SELECT Neve, Fizetes FROM Dolgozo WHERE Fizetes+50000 > (SELECT MAX(Fizetes) FROM Dolgozo)
- Az elõzõekben látott Kifizetés tábla felhasználásával készítsünk olyan listát, amely a Dolgozó táblából kilistázza azon dolgozók nevét és törzsszámát, akik számára még nem történt kifizetés! Az alábbi parancsot használhatjuk:
SELECT Neve, ID FROM Dolgozo WHERE ID NOT IN (SELECT ID FROM Kifizetes)
Egy másik lehetséges megoldás:
SELECT Neve, ID FROM Dolgozo WHERE NOT EXISTS (SELECT ID FROM Kifizetes WHERE Kifizetes.dolgozo = Dolgozo.ID)
Figyeljük meg, hogy ez a második megoldás egy olyan speciális esetet foglal magába, amikor a belsõ lekérdezésben felhasználjuk a külsõ lekérdezés táblájának egy mezõjét is.
példa Készítsünk olyan listát, amely a Dolgozó táblából kilistázza azon dolgozók adatait, akik minden Egerben vagy Szegeden lakó dolgozónál többet keresnek! Az alábbi parancsot használhatjuk:
SELECT * FROM Dolgozo WHERE Fizetes > ALL (SELECT Fizetes FROM Dolgozo WHERE Varos = "Eger" OR Varos = "Szeged")



9.Indexek,integrálási feltételek

10.Tervezés eszközei,kapcsolat típusok,adattípusok

Tervezés eszközei
- elsõsorban tudnunk kell, hogy milyen adatbázis-kezelõ programot akarunk használni
- az adatokat csoportosítjuk, és az egymással szoros összefüggésben lévõ adatokat ugyanabban a táblában tároljuk, majd meghatározzuk, hogy az így kapott táblák milyen kapcsolatban vannak egymással.
- úgy kell megtervezni az adatbázisokat, hogy eleget tegyenek bizonyos kritériumnak, például, hogy minimális legyen bennük az adatredundancia, teljesüljenek a különbözõ adatfüggetlenségek, stb.
- nincs általános tervezési technika, de van a tervezésnek menete, amit érdemes követni
1. meg kell határoznunk a célokat, melyek szoros kapcsolatban vannak a felhasználó igényeivel.
2.  logikai tervezés - eredménye az adatbázis logikai modellje
Ebben a szakaszban fõként az adatok és a közöttük lévõ kapcsolatokra helyezõdik a hangsúly. Itt történik az egyedek meghatározása, megadásra kerülnek az egyedeket leíró tulajdonságok, valamint feltérképezésre kerülnek az egyedek közötti kapcsolatok, mindemellett ügyelve az adatredundancia minimalizálására.
3. fizikai tervezés - fizikai szinten képezzük le a logikai modellt, a felhasználandó szoftver és hardver függvényében
az adatbázisok számítógépen történõ létrehozása valósul meg a korábbi tervek alapján. Elkészül a prototípus, arendszer elsõ verziója, ami még nem teljes, változtatásra, tökéletesítésre szorul.

a tervezés lépései:
1. követelményelemzés - meghatározzuk az adatbázis célját, hogy milyen adatokat tároljunk az egyedrõl, és hogy milyen információt szeretnénk kinyerni az adatbázisból
2. egyedek, táblák meghatározása - az összegyüjtött adatokat információrendszerbe szervezzük (egyedek a táblában, rekordpéldányok a sorokban, attribútumok az oszlopokban), 1 táblában csak egy témájú adatok legyenek, és csak egyszer tároljunk mindent!
3. mezõk, attribútumok meghatározása - a konkrét tervezés, ahol meghatározzuk a táblákat, és attribútumokat.
attribútum lehet:
- egyszerû, azaz tovább nem bontható, valamint összetett. Az összetett attribútum több egyszerû értékbõl áll.
-egyértékû: minden elõfordulásnál csak egy értéket vehet fel. A többértékû minden elõfordulásnál több értéket is felvehet.
-a tárolt attribútum értékeit az adatbázis tárolja. A származtatott értéke más attribútumok alapján határozható meg.
4. azonosítók meghatározása - elsõdleges kulcsok
kulcs lehet:
- számláló típusú - ilyenkor létrehozunk egy számláló típusú mezõt
- egy mezõbõl álló - ilyenkor egy mezõbõl áll a kulcs. (attribútum, ami alkalmas erre)
- több mezõbõl álló - több attribútumból képezzük egyszerre (összetett kulcs)
5. kapcsolatok meghatározása - összekapcsoljuk az egyedeket (1:1, 1:n, n:m)
6. ellenõrzés - ellenõrizzük a tervet, mielõtt élesben megcsinálnánk!
7. adatbevitel - ellenõrzés (és esetleges javítás) után bevihetjük az adatokat a már létezõ táblákba, aztán lekérdezések, jelentések készítése

Kapcsolat típusok

KAPCSOLAT
- Kapcsolatnak nevezzük az egyedek közötti összefüggést, viszonyt.
- kapcsolatok az egyedhalmazok elemei között alakíthatók ki.
- osztályozhatjuk a kapcsolatokat aszerint, hogy egy-egy elemhez hány másik elem tartozik.  (1:1, 1:n, n:m)
- az egy egyed elõforduláshoz szintén 1 egyed elõfordulás tartozik (1:1)-et egyszerûbb megvalósítani, mint ha többhöz több tartozna! az elõbbihez elég lehet egy mutató, míg az utóbbihoz összetett adatstruktúra, halmaz, esetleg lista szükséges.
- 1:1, az egyik egyed minden egyes elõfordulásának a másik egyed pontosan egy elõfordulása tartozik. pl. a férfi és nõ között a házassági viszony
- 1:n, 1 egyed minden elõfordulásához, a másik egyed több elõfordulása tartozik. pl. bérszámfejtõ rendszerben a dolgozók- kifizetések. (1 dolgozóhoz több kifizetés, de 1 kifizetés csak 1 dolgozóhoz!)
- n:m, mindkét egyed elõfordulásaihoz a másik egyed több elõfordulása tartozhat. pl. Egy dolgozó több témában is tevékenykedhet és egy témán több dolgozó dolgozhat.
- minden sok-sok kapcsolat felbontható két 1-sok kapcsolatra. (mert ha 1 egyed szempontjából nézzük, akkor az 1-sok kapcsolat)
- ezek (1:1, 1:n, n:m) két egyed között létesíthetõ kapcsolatok, tehát bináris kapcsolatok!

Adat típusok
- number (h, t) - szám, hossz (max 38), tizedesjegyek
- date - dátum és idõ típus
- varchar2(hossz) - szöveges, max 4000 karakter hosszú, változó hosszússágú
- char (méret) - max 2000 hosszú, fix hosszúságú
- nchar(méret) - olyan mint a varchar, csak a max hossz függ a karakterkésszlettõl
- lob - (large objects) - bináris vagy szöveges formátum - lehet kép, hang, vagy nagyméretû szöveges állomány
A LOB típuson belül lehetnek:
- LONG – szöveges adatok, max hossza<=2 Gbyte;
LONG RAW – bináris adatok, max hossza<=2 Gbyte;
- A LONG és LONG RAW típusokat csak egyszerû adatfeldolgozásban alkalmazzák.
CLOB, NCLOB, BLOB – belsõ LOB típusok, mivel az AB-ban tárolódnak, max hossza<=4 Gbyte;
CLOB – az adatokat tárolja az AB karakter-készlete alapján;
NCLOB – az adatokat tárolja a nemzeti karakter-készletben.
Az Oracle mindegyik táblába automatikusan helyez egy ROWID nevû pszeudooszlopot, amely a programozók ritkán szokták használni. ROWID – pszeudooszlop, amely tartalmazza a sor logikai egyedi címét. A ROWID nem változható meg, de a SELECT parancsban lekérdezhetõ:
SELECT rowid FROM tabla_1;
A Sor sorszáma – olyan szám, amely akkor rendelõdik a sorhoz, amikor az bekerül a táblába. Ez a szám része a ROWID-nek.