Adatbazis

Front 1

Adatbázis:

Back 1

Adatok gyűjteménye (összessége), mely egy szervezet tevékenységérevonatkozik

Front 2

Adatbázis-kezelo rendszer (ABKR):

Back 2

Egy programrendszer (soft), melyet arra terveztek, hogy nagy mennyiségű adatot tudjon tárolni és használni.

Front 3

Adatbázisok ANSI/SPARC architekturája:

Back 3

Az adatbázisszerű ismeretkezelésben megkülönböztetjük az adatbázis általános elvi felépítését (absztrakt kép) és az abban őrzött aktuális ismereteket (konkrét tartalom). Az adatbázis általános struktúráját adatmodellnek nevezzük.

Front 4

Mely harom szintet kulonbozteti meg az ANSI/SPARC architektura?

Back 4

Egy elfogadott nézőpont azANSI/SPARC architektúra, mely 3 szintet különböztet meg: fogalmi, belső és külső szint.

Front 5

Mit nevezunk nezetnek?

Back 5

Az adatmodellnek a felhasználó által kezelésre kiválasztott részét nézetnek (angolul: view) nevezzük.

Front 6

Peldak ertekorientalt modellekre:

Back 6

Relációs, logikai.

Front 7

Objektum alapu modellek:

Back 7

Hierarchikus, hálós, egyed/kapcsolat, objektumorientált modell

Front 8

Egyed:

Back 8

Egy olyan dolog, mely létezik és megkülönböztethető. (Vagyis egyik egyed megkülönböztethető a másiktól).

Front 9

Egyedek halmaza:

Back 9

Egyedek halmaza: az összes „hasonló” egyed egyedhalmazt alkot. Egy egyedhalmaznak több attribútuma is van. Minden egyednek az egyedhalmazból megfelel egy-egy érték minden attribútum értékeinek halmazából.

Front 10

Kulcs:

Back 10

egy vagy több attribútum, mely egyértelműen meghatároz egy egyedet az egyedhalmazban

Front 11

Az_egy hierarchiak:

Back 11

A „az_egy” B (A "is_a" B), ha a B egyedhalmaz az A egyedhalmaz egyáltalánosítása, vagy másképp A egy speciális B. A örökli B attribútumait, és ezek mellett még lehetnek más attribútumai is. B-nek a kulcsa lesz A-nak a kulcsa is.

Front 12

Egyedhalmazok közötti kapcsolat:

Back 12

Az egyedhalmazok egy rendezett listája. Egy adott halmaz nem csak egyszer jelenhet meg.

Front 13

Mit nevezunk relaciosemanak?

Back 13

A reláció nevét és a reláció attribútumainak a halmazát együttrelációsémának nevezzük.

Front 14

Adatmodell értelmezése:

Back 14

egy matematikai formalizmus, mely a következő részekből áll:

• egy jelölés az adat leírása érdekében

• műveletek halmaza, melyeket az illető adatok esetén használhatunk

Front 15

ABKR értelmezése

Back 15

egy programrendszer (soft), melyet arra terveztek, hogy nagy mennyiségű adatottudjon tárolni és használni

Front 16

Egy ABKR által használt technikák:

Back 16

• programozási nyelvek

• operációs rendszerek

• konkurens programozás

• adatstruktúrák

• algoritmusok

• párhuzamos és osztott rendszerek

• felhasználói felületek

• mesterséges intelligencia

• statisztika

Front 17

Milyen adatmodelleket ismertek?

Back 17

• értékorientált modellek- relációs logikai

• objektum alapú modellek- hierarchikus, hálós, egyed/kapcsolat, objektumorientált

Front 18

Értékorientált modellek előnye az objektumorientálttal szemben:

Back 18

• a lekérdezések optimalizálhatóak

• támogatja a deklarativitást

• az adatismétlést normalizálással oldják meg

Front 19

Objektumorientált modellek előnye az értékorientálttal szemben:

Back 19

• nem szüks.ges egy plusz mező bevezetése az azonos attríbútum értékekkelrendelkező egyedek esetén, ezt megoldja az objektumazonosító

• hatékonyan tudnak nagy mennyiségű adatot kezelni

• az adatismétlést mutatókkal oldják meg, minden objektum csak egyszer vantárolva

Front 20

Miből áll az egyed/kapcsolat adatmodell?

Back 20

egyedek, egyedek halmazai, ezek attribútumai, ill. kulcsok

Front 21

ABKR-ek képességei. Tulajdonságok amelyek megkülönböztethetik más programrendszerektől:

Back 21

• azon képessége, hogy állandóan létező adatokat tud kezelni

• azon képessége, hogy hatékonyan tud kezelni nagyon nagy mennyiségű adatot

• egy adatmodellre .pül, melynek segítségével a felhasználó megtervezheti azadatbázist, ugyanakkor segít a felhasználónak abban, hogy az adatot ne csak biteksorozataként lássa, hanem érthetőbb formában

• magas szintű programozási nyelvekkel rendelkezik az adatok szerkezetének aleírására, adatkezelésre és lekérdezésre

• egyidejűleg több felhasználó között megosztja az adatbázist, ellenőrzi ahozzáférési jogokat

• rendszerhibák esetén képes egy helyes adatbázist visszaállítani

Front 22

ABKR-ek előnyei

Back 22

Adatfüggetlenség, hatékony hozzáférés az adatokhoz, adatok helyességére vonatkozó megszorítások és biztonség

Front 23

Adatfüggetlenség:

Back 23

a felhasználói programok függetlenek az adatok ábrázolásától és tárolásától. AzABKR egy absztrakt nézet (képet) ad az adatokról

Front 24

ANSI-SPARC architektúra:

Back 24

A számítógép és a felhasználó között több elvonatkoztatási szint lehetséges.Egy elfogadott nézőpont az ANSI/SPARC architektúra, mely 3 szintet különböztetmeg: fogalmi, belső és külső szint. E három szint között az ABKR teremtkapcsolatot.

Front 25

Mit nevezünk fogalmi szintnek?

Back 25

Adatbázis tervezés esetén a fogalmi szintet kell először megterveznünk. Ezen aszinten egy alkalmazási környezet valamennyi ismeretét és azok valamennyi összefüggését egyetlen közös adatmodellben kell leírnunk. Ez a reprezentációfüggetlen az adatbázis kezelő rendszer típusától. Általában az egyed/kapcsolatadatmodellt használják a fogalmi szint megtervezésére.

Front 26

Mit nevezünk belső szintnek?

Back 26

A belső szint a fizikai adatbázisra hivatkozik. A fizikai adatbázist az állományokösszessége és a hozzájuk tartozó indexállományok alkotják. Az adatok a fogalmiszinten megadott szerkezet szerint állományokban vannak tárolva. Azindexállományok az adatokhoz való hatékony hozzáférést segítik. A fizikaiadatbázis a háttértárolón van. Egy ABKR több fizikai adatbázist is képes kezelni.

Front 27

Mit nevezünk külső szintnek?

Back 27

A harmadik a külső szint. Minden fogalmi szintű adatbázisnak több felhasználójavan. Az egyes felhasználók az adatbázis kül.nb.ző részleteiben érdekeltek. Azadatmodellnek a felhasználó által kezelésre kiválasztott részét nézetnek nevezzük.A nézetnek levezethetőnek kell lennie a fogalmi szinten megtervezettadatmodellből. A nézetek fontosak az adatvédelem szempontjából, egy bizonyosfelhasználócsoportnak csak bizonyos nézetekre van joga.

Front 28

Honnan kapta nevét a relációs adatmodell?

Back 28

Olyan adatmodell, amelynek legfontosabb eleme a matematikai relációfogalma.

Front 29

Adjuk meg a kulcs értelmezését relációs adatmodell esetén!

Back 29

Egy S attribútum halmaz az R reláció kulcsa, ha:

• R relációnak nem lehet két sora, melynek értékei megegyeznek az S halmazminden attribútumára

• S egyetlen valódi részhalmaza sem rendelkezik az előbbi tulajdonsággal

Front 30

Mi a hasonlóság és különbség a PRIMARY KEY és UNIQUE megszorításokközött?

Back 30

Mindkét megszorítás azt eredményezi, hogy az adott attribútumok egyedieklegyenek. Ezt az ABKR számon tartja, és adott esetben ellenőrzi, hogy PRIMARYKEY-ből csak egy legyen egy reláció (tábla) esetén. Egy másik táblában külsőkulcsként csak PRIMARY KEY szerepelhet, UNIQUE kulcs nem.

Front 31

Mi a szuperkulcs? Mi a kapcsolat szuperkulcs, a reláció kulcsa és a prímattribútum között?

Back 31

Szuperkulcsoknak nevezzük azon attribútum halmazokat, melyek tartalmaznakkulcsot. Minden kulcs szuperkulcs. Az R (A1, A2, A3, …, An) reláció esetén Aiattribútum prím, ha létezik egy C kulcsa az R-nek, úgy, hogy Ai eleme C. Tehát aprím attribútum része a kulcsnak, így a szuperkulcsnak is.

Front 32

Mit jelent a DDL?

Back 32

Data Definition Language

• Olyan adatleíró nyelvre vonatkozik, amely nem procedurális. Egy jelölés azegyedek és a k.ztük levő kapcsolatok leírására, az illető adatmodellen belül.

Front 33

Mit jelent a DML?

Back 33

Data Manipulation Language

• Olyan adatmódosító nyelv, amely képes megvalósítani az adatbázisban tároltadatokkal végezhető műveleteket: beszúrás, módosítás és törlés.

Front 34

Milyen helyességi megszorításokat léteznek?

Back 34

• egyedi kulcs feltétel

• hivatkozási épség feltétel

• értelmezéstartomány-megszorítások

• általános megszorítások

Front 35

Hányféleképpen lehet a hivatkozási épség megszorítást fenntartani? Rövidenismertesse mindegyiket!

Back 35

• Alapértelmezés szerinti eljárás: ha a feltétel megsérülne a módosítást az ABKR visszautasítja. •Továbbgyűrűzik eljárás (CASCADE): a hivatkozott (apa) táblában történ törlés és módosítás esetén alkalmazható. A törölt sorral együtt a hivatkozott (apa) táblából törli a neki megfelel értékeket a hivatkozó (fiú) táblából.

• Ha módosítunk egy értéket a hivatkozott (apa) táblában, az ABKR módosítja a hivatkozó (fiú) táblában is a megfelel értékeket NULL értékre állítás módszere (SET NULL): a törölt vagy módosított apa sorhoz tartozó fiú sorokban a külső kulcs értékét NULL- ra változtatja.

Front 36

Mi a külső kulcs?

Back 36

Külső kulcs egy KK attribútum egy R1 relációból. Értékeinek halmazaugyanaz, mint egy R2 reláció elsődleges kulcsának értékhalmaza, és az a feladata,hogy R1 és R2 közötti kapcsolatot modellezze.

Front 37

Funkcionális függőség értelmezése.

Back 37

R(A1, A2, … , An) relációA = (A1, A2, …, An), X, Y eleme A (része)Ha X funkcionálisan meghatározza Y-t (Y funkcionálisan függ X-től), akkor ha Rbármely két sora megegyezik az X attribútumain, akkor meg kellett egyezniük az Yattribútumain is.Jelölés: X → Y

Front 38

Tranzitív függőség értelmezése.

Back 38

Y ⊂ A; B ∉ Y

Y → B tranzitív függőség, ha:• Y nem szuperkulcs R relációban• Y nem valódi részhalmaza R egy kulcsának.Példa, mert az előbbi 5 sor érthetetlen:Y nem kulcs, nem része a kulcsnak, tehát C → Y és Y → B , és erre mondhatjuk,hogy B tranzitív függőséggel függ C-től.

Front 39

Parciális függőség értelmezése

Back 39

Ha C egy kulcsa az R relációnak, Y ⊂ C , B ∉ Y ,

Y → B egy parciális függőség. (B függ a kulcs egy részétől)

Front 40

Triviális funkcionális függőség értelmezése

Back 40

Triviális funkcionális függőségről besz.lünk, ha Y ⊂ X , akkor X→Y.

Front 41

Egy attribútum prím ha:

Back 41

Az R (A1, A2,..., An) reláció esetén Ai attribútum prím, ha létezik egy C kulcsaaz R-nek, úgy, hogy Ai ∈ C.

Front 42

1NF értelmezése

Back 42

Egy R reláció 1NF-ban van, ha az attribútumoknak csak elemi értékei vannak.Ez minimális feltétel, melynek egy reláció eleget kell tegyen, hogy a létező relációsABKR-ek kezelni tudják.

Front 43

2NF értelmezése

Back 43

Egy reláció 2NF formában van, ha első normál formájú és nem tartalmaznakY → B alakú parciális függőséget, ahol B nem prím attribútum. Csak akkor tevődikfel, hogy egy reláció nincs 2 NF-ban, ha a kulcs összetett.

Front 44

3NF értelmezése

Back 44

Egy R reláció harmadik normál formában van és nem tartalmaz Y → B alakútranzitív funkcionális függőséget, ahol B nem prím attribútum.

Front 45

BCNF értelmezése

Back 45

Az R reláció Boyce-Codd normál formában (BCNF) van akkor és csak akkor, haminden olyan esetben, ha az R-ben érvényes egy Y → B nem triviális függőség,akkor az Y attribútum halmaz az R reláció szuperkulcsa kell legyen. A BCNF eseténelmarad a B-re vonatkozó megszorítás, hogy nem prím, tehát B lehet kulcs része.

Front 46

Milyen típusú join műveletek léteznek?

Back 46

• right outer join

• left outer join

• full outer join

• inner join (természetes összekapcsolás)

Front 47

Mi a hasonlóság és a különbség a trigger és a tárolt eljárás között?

Back 47

Mindkettő valójában tárolt eljárás, meg lehet bennük valósítani lekérdezéseket és tartalmaznak programozási nyelvbeli elemeket. A tárolt eljárást EXECUTE-tal futtatjuk le, triggert táblához társítunk. A trigger lehet insert, update vagy delete trigger és az illető műveletnél a megfelelő tábla esetén hívódik meg.

Front 48

Relációs adatmodell tulajdonságai

Back 48

• a tábla nem tartalmazhat két teljesen azonos sort, azaz két sornak legalább egyattribútum konkrét értékében különböznie kell

• kulcsot értelmezünk vele kapcsolatosan, amely egyértelműen meghatároz egyattribútum halmazt. Ez lehet összetett is, de felt.tlenül szüks.ges egyetlenelsődleges kulcsot kijelölni minden reláció esetén, aminek értéke nulla vagyNULL egyaránt nem lehet

• a táblázat sorainak sorrendje lényegtelen

• a táblázat oszlopaira, vagyis az attribútumokra a nevükkel hivatkozunk, tehátkét attribútum neve nem lehet azonos

• a táblázat oszlopainak sorrendje is lényegtelen

Front 49

Adjuk meg a tárolt eljárások előnyeit és hátrányait!

Back 49

• A tárolt eljárás bonyolultabb feladatok megoldására alkalmazható (amiket akáregy bonyolultabb lekérdezéssel sem tudunk megoldani), megosztható több kliensközött, biztonságosabb, hiszen bizonyos felhasználóknak megadjuk a jogot, hogymeghívja ezeket, de ne változtathasson direkt módon az adatokon, az eljárásmegírásakor (és nem futtatáskor) ez optimalizálható, és elrejthetők a felhasználóelől a rendszer, illetve az adatbázis-specifikus részleteket, így nagyobbadatfüggetlenséget biztosítva.

• Ezzel szemben ha a lekérdezéseket tárolt eljárásokkal valósítjuk meg, nagy ahatékonyságuk, viszont mindez a hordozhatóság rovására megy. Az ABKRkicserélése a tárolt eljárások újraírását vonja maga után. Ha viszont az SQLparancsokat a kliens alkalmazásban írjuk meg, akkor az ABKR-t kevesebbmunkával lecser.lhetjük.

Front 50

Mi a hasonlóság és a különbség a temporális tábla és a sormutató(kurzor)között?

Back 50

Lekérdezés eredménye mindkettőbe bekerülhet, a temporális tábla ugyanúgyviselkedik, mint egy hagyományos tábla, a sormutatóval oszlop értékeit egyenként belehet járni.

Front 51

Adjuk meg a nézettáblák előnyeit!

Back 51

• korlátozzuk a hozzáférést az adatbázishoz

• komplex lekérdezéseket egyszerűbbé tehetünk (makró lehetőség)

• a nézet nem tárolódik el a háttértárolón

• biztosíthatjuk az adatfüggetlens.get

• egy adat különböző nézeteit adhatjuk meg

Front 52

Adjuk meg a veszteségmentes felbontás értelmezését!

Back 52

Az R reláció R1, R2, …, Rk felbontása veszteségmentes az F függőségi halmazszerint, har = ΠR1(r) ⋈ ΠR2(r) ⋈ … ⋈ ΠRk(r) az R minden r előfordulására.

Front 53

Hogyan osztódik meg a munka a kliens és a szerver között adatbázis applikációkesetén?

Back 53

A kliens adatokat kér, és feldolgozza a szervertől kapott válaszokat, a szerverkiszolgálja a kliensei kéréseit, azaz meghatározza a választ a kérésekre (végrehajtja akért műveleteket az adatbázis adatain), és visszaküldi a választ. Az adatbázishoz tehátcsak a szervernek van hozzáférése.

Front 54

Adjuk meg azokat az axiómákat, melyek egy funkcionális függőségi halmazlezártjának meghatározására használnak!

Back 54

Front 55

Adjuk meg az Armstrong axiómákat!

Back 55

Front 56

Két funkcionális függőségek halmaza mikor ekvivalens?

Back 56

Front 57

Adjuk meg az algoritmust, mely egy relációs BCNF-ra veszteségmentesenfelbont.

Back 57

Front 58

Adjuk meg egy X attribútum halmaz F funkcionális függőségek szerinti lezártjameghatározásának algoritmusát!

Back 58

Front 59

Adjuk meg a 3NF-ra alakító algoritmust, mely a függőségeket megőrzi!

Back 59

Front 60

Adjuk meg egy funkcionális függőségek halmazának minimális fedésénekértelmezését!

Back 60

Front 61

Adjuk meg egy funkcionális függőségek halmazának minimális fedését generálóalgoritmust!

Back 61

Front 62

Adjuk meg a szerver oldal feladatait a kliens-szerver architektúra esetén!

Back 62

• mivel task orientált, képes kell legyen a műveletek gyors elvégzésére

• nagy mennyiségű információ tárolása, módosítása, gyors keresése

• adatok helyességének az ellenőrzése

Front 63

Milyen kapcsolattípusok léteznek?

Back 63

nincs kapcsolat az egyedhalmazok között.

egy-egy (1:1) kapcsolat. Az egyik egyedhalmaz minden egyes elemének egy és csakegy elem felel meg a másik halmazból, és viszont.

egy-sok (1:N) vagy a másik irányból sok-egy (N:1) kapcsolat. Az egyik halmazelemeinek több elem is megfelelhet a másik halmazból, a másik halmaz mindeneleméhez viszont csak egy elem tartozik az első halmazból.

sok-sok (M:N) kapcsolat. Mindkét egyedhalmaz bármely eleméhez több elemtartozhat a másik egyedhalmazból.

Front 64

Példa funkcionális függőségre:

Back 64

ÁruID → MértEgys (azzal a feltevéssel, ha más mértékegységbenárulják az árut, más ID-t is kap).

SzállID → {SzállNév, SzállCím}

ÁruID → {ÁruNév, MértEgys}

Front 65

Példa parciális függőségre:

Back 65

parciális függőségre: SzállID → SzállNév.SzállításiInformációk kulcsa {SzállID, ÁruID}{SzállID, ÁruID}→SzállNév

Front 66

Példa tranzitív függőségre:

Back 66

Rendelések (RendelésSzám, Dátum, Vev ID, Vev Név, Részletek),RendelésSzám els dleges kulcs RendelésSzám →Vev ID.V ev ID→V ev Név

Front 67

Helytelen adatbázis esetében milyen problémák léphetnek fel?

Back 67

Redundancia, módosítási problémák, törlési problémák, illesztési problémák.

Front 68

Redundancia:

Back 68

Az információk feleslegesen ismétl dnek több sorban,mint például a SzállításiInformációk reláció esetében a szállító címeismétl dik.

Front 69

Módosítási problémák:

Back 69

Megváltoztatjuk az egyik sorban tároltinformációt, miközben ugyanaz az információ változatlan marad egymásik sorban. Például, ha a szállító címe változik, de csak egy sorbanváltoztatjuk meg, nem tudjuk, melyik a jó cím. Jó tervezésselelkerülhetjük azt, hogy ilyen hibák felmerüljenek.

Front 70

Törlési problémák:

Back 70

Ha az értékek halmaza üres halmazzá válik, akkorennek mellékhatásaként más információt is elveszthetünk. Ha példáultöröljük a Rolicom által szállított összes árut, az utolsó sor törlésévelelveszítjük a cég címét is.

Front 71

Illesztési problémák:

Back 71

Ha hozzáilleszteni akarunk egy szállítót, amelynem szállít egy árut sem, a szállító címét kitöltjük úgy, hogy az áruhoz„null” értékeket viszünk be, melyet majd utólag ki kell törölni, ha elnem felejtjük.