adatbÁzis rendszerek · 2017-05-05 · o ilyen pl. a merevlemez, de nem ilyen a mágnesszalag. •...

Fazekas Gábor ____________________________________________________________________________ Debreceni Egyetem IK

1

ADATBÁZIS RENDSZEREK (bevezetés)

Dr. Fazekas Gábor egyetemi docens


2

„…ma már a csapból is adatbázis folyik”: alapfogalmakat kell tisztázni!•

• Adatbázis • Adatbáziskezelő rendszer • Adatbázis rendszer

• „… mert attól még. hogy egy törzsadatállományt nagyon sokáig megőrzünk, nem lesz belőle adatbázis!” (Idézetek tőlem)


3

• Adatbázis • Munkadefiníció (Engles, 1972.): Egy vállalat működési adatainak strukturált

módon tárolt együttese, amelyek a vállalat tevékenysége során keletkeznek és amelyeket a vállalat működéséhez felhasznál.

o Vállalat (enterprise): itt gyűjtőfogalom, azaz közös elnevezése azoknak a szervezeteknek (rendszereknek) , amelyek folyamatos / hosszú távú működése szorosan kötődik a napi működés során keletkező adatokhoz. Pl.: termelő vállalat, könyvtár, kórház, egyetem, polgármesteri hivatal, minisztérium, „ország”, stb.

o Működési adat: a működést jellemző adat, pl. egy könyvtár esetén ilyen az olvasó adat, bibliográfiai adat, kölcsönzési adat, de nem tartozik ebbe a körbe a havi látogatottsági statisztika!

• A definíció korrekt, de számos kiegészítést igényel!

• Naiv felfogású emberek - sokszor fennhéjazva - akkor is adatbázist emlegetnek, ha nem arról van szó


4

Adatbázis: kiegészítések a fogalomhoz • (i) Föltételezzük, hogy az adatbázis adatai közvetlen elérésű számítógépes

háttértárban tárolódnak.

o Ilyen pl. a merevlemez, de nem ilyen a mágnesszalag.

• (ii) Az adatbázis „sok” adatot tartalmaz.

o Olyan „sokat”, hogy az adatok mennyisége miatt a kezelésükhöz speciális hozzáállás és módszerek szükségesek.

o Pl. másképp kell az adatbevitelt megszervezni egy 300 bemenő adattal működő programban, mint egy 3 bemenő adatot igénylő programban!

• (iii) Az adatbázis rendszerint sok felhasználó adatait tartalmazza.

• (iv) A tárolt adatok sok felhasználási célt szolgálnak.

• (v) Az adattárolás módja (a tárolt adatok struktúrája) sokféle feldolgozási módot támogat.

o (ii – v)-re példa egy légiközlekedési helyfoglalást nyilvántartó rendszer (GABRIEL)

• (vi) A (iii),(iv),(v)-re együtt azt mondjuk, hogy az adatbázis integrált!


5

• Adatbázis: kiegészítések a fogalomhoz • (vii) Az adatbázis logikailag osztott.

o A felhasználók (nem feltétlenül diszjunkt) csoportokra oszlanak. o Az adatbázisban tárolt adatok (nem feltétlenül diszjunkt) részstruktúrákat képeznek. o Minden egyes csoport és részstruktúra párra egyértelműen rögzítve vannak az illető

csoport adatmanipulációs jogai az adott részstruktúrára nézve. o Adatmanipuláció: visszakeresés, bővítés, törlés, módosítás. o Ehhez szükséges az adatstruktúra és a részstruktúrák leírásainak, illetve a

csoportoknak és adatmanipulációs jogaiknak megfelelően kódolt formában történő tárolása. Erre szolgál a metaadatbázis: az „adatokat leíró adatok” együttese.

• (viii) Metaadatbázis: az adatok szerkezetének és kezelési kompromisszumainak leírása, azaz az adatbázis „információs tartalomjegyzéke”, szemantikája.

• (ix) Adatbázis: adatok és metaadatok (adat és szemantika) együtt tárolása lényegi választóvonal a hagyományos adatfeldolgozás és az adatbáziskezelés között.

o A hagyományos adatfeldolgozásban a szerkezetet és a kezelési kompromisszumokat az adatokat kezelő programok implementálták!


6

• Adatbáziskezelő rendszer • Szoftver (rendszer), amely professzionális támogatást nyújt az alábbi feladatok

megoldásához:

o az adatok szerkezetének és kezelési kompromisszumainak leírása (metaadatbázis létrehozása),

o adatmanipuláció: visszakeresés, bővítés, törlés, módosítás,

o egyéb: felhasználó-kezelés, folyamat/tranzakció kezelés, stb!

(ez nem releváns!)

• A támogatás nyelvi megalapozása, nyelvi eszközök.

o Adatdefiníciós nyelv (DDL ~ Data Definition Language).

o Adatmanipulációs nyelv (DML ~ Data Manipulation Language).

• Egyéb: DCL, DMCL, stb!

• Implementáció: Önálló- és befogadó nyelvű rendszerek.

• SQL.


7

• Adatbázis rendszer • Adatbázis +

• Adatbáziskezelő rendszer +

• Absztrakt felhasználó/működtető környezet


8

• Adatbázis szemlélet • Működési adatok = erőforrás a vállalat számára

• Ugyanolyan tulajdonságokkal rendelkeznek, mint más erőforrások (nyersanyag, energia, munkaerő, stb.):

o Biztosításuk időt és költséget igényel.

o Nem állnak korlátlanul rendelkezésre (pl. elavul, elévül, elfogy).

o Racionális felhasználásuk a vállalati működés eredményességét növeli („jólértesültség, bennfenntesség”).

o Példák.

• Következmény, probléma: versenyfutás az erőforrásokért (a vállalaton belül).

• Megoldás: központi erőforrás-gazdálkodásra van szükség!

o Az adatokat integrálni kell!

• Adatbáziskezelés: az adattal, mint erőforrással történő gazdálkodás.

• Adatbáziskezelő rendszer: ezen erőforrás-gazdálkodás automatizált eszköze.


9

• A hagyományos adatkezelés problémái A gondok forrása: „Magán jelleg” (Nincs vállalati szintű adatkezelési stratégia, szervezés. Egyéni megoldások, nincsenek szabványok.)

• Többszörös adattárolás (redundancia) és a következtében fellépő adatösszeférhetetlenség (inkonzisztencia).

• Rugalmas változtathatóság hiánya és a magas karbantartási igény:

o Az adatok szerkezetét a programokon belül írták le, kapcsolataikat eljárási úton realizálták.

• A felhasználói logikából nem következő programozási többlet:

o Adatfüggőség: az alkalmazói program függ az adatok szerkezetétől, tárolási és elérési módjától.

• Az adatvédelem kívánt szintje nem biztosítható.

Egyéb gondok:

• Rendszertervezési módszerek elavultak.

• Emberi és gépi hatékonyság ellentmondása.


10

• A modern adatbázis tervezés folyamata


11

• Adatmodellezés Adatmodellezés: valamely rendszer (vállalat) működését jellemző adatok (típusok) feltárása és ennek valamilyen konvencionális jelölő rendszer segítségével történő rögzítése (tárolt adatmodell).

Az adatmodellezés „számítógéptől független”.

Jelölő rendszer: szöveges, szemigrafikus, formális, stb…

Modell = szemlélet, elképzelés (illúzió). Hitelesség?


12

I. Entities (objects, things)

II. Attributes (characteristics, properties)

III. Relationships between entities Types & Occurrences

• Adatmodellezés A modellezés „modellje” (C.W. Bachman, 1969)

• Dimenziók: o Egyedek o Tulajdonságok o Kapcsolatok

• Típus és előfordulás o Absztrakt és konkrét jellemzés o Típus képzés = absztrakció (csoportosítás + névadás)


13

• Adatmodellezés • CODASYL (Conference on Data Systems Languages, 1969. október.)

• DBTG (DataBase Task Group)

• DBTG report: 1971. április. Jelentősége:

o Helyzetelemzés

o Követelmény specifikáció

o Útmutatás (módszertan)

o letölthető(?): http://dl.acm.org/citation.cfm?id=1387569


14

• Adatmodellezés A CODASYL modellezés alapfogalmai:

• Tulajdonos (owner) és tag (member) rekordtípusok

o Adategyüttes (set)

• Set konstrukciós szabályok

o Kezelési kopromisszumok (integritási megszorítások)

• Setek belső ábrázolása

o Listák

o Homogén állományok, homogenitás fontossága

• A „több-több” kapcsolat ábrázolása setek segítségével

• Codasyl rendszerek (IDMS, C-Tree, SÁMÁN)


15

Example: Közkönyvtár

Entity types Occurrences associated to the type Book Virginia Woolf: Mrs

Dalloway Oscar Wilde: De Profundis

James Joyce: Dubliners

Jane Austen: Persuasion

Reader Smith Scott Black Jones

Attribute types Occurrences associated to the typeCODE B01 B02 B03 B04 ISBN 1 85326 191 2 1 84022 401 0 1 85326 048 7 1 85326 056 8 Author Virginia Woolf Oscar Wilde James Joyce Jane Austen Title Dalloway Profundis Dubliners Persuasion Publisher Wordsworth Ed. Ltd. Wordsworth Ed. Ltd. Wordsworth Ed. Ltd. Wordsworth Ed. Ltd.Publishing year 2003 1999 1993 1993 EUR_price 3,0 2,5 3,5 2,0

Attribute types Occurrences associated to the type CODE R01 R02 R03 R04Name John Smith Robert Scott Jane Black Tom Jones Address Long str.3., London Small sqr. 2., Dover Wide str. 33., Eaton Old str. 39., Etteln Phone +48 234 5657322 +48 245 5657432 +48 255 5634522 +48 267 4647322 Relationship types Occurrences associated to the type

1: N Reader_borrows_book M:N Author_writes_book 1:1 Reader_has_ID-Card


16

A Bachman-féle modellezési probléma megoldása a CODASYL hálós (NETWORK) modell segítségével

• Az entitás típusok leírhatók a rekord típusok segítségével (a hagyományos adatfeldolgozásból örökölt módon).

• Attribútum (típus) a rekord (típus) mezője (a hagyományos adatfeldol-gozásból örökölt módon).

• A kapcsolatok leírásához újabb modellezési eszközre (modelling primitive) SET van szükség!

• Egy SET típus két rekordtípus névvel ellátott(!) 1:N kapcsolata. A kapcsolatban részt

vevő rekordtípusokat rendre gazdának (owner), illetve tagnak (member) nevezzük. Az owner rekordtípus minden egyes előfordulásához tartozhat a member rekordtípus változó számú előfordulása, míg a member rekordtípus minden egyes előfordulása pontosan egy owner előforduláshoz tartozhat.

• A rekord típusok jelölése: téglalap benne a típusnév.

• A rekordtípus előfordulásainak jelölése: „köröcske”

(benne esetleg jellemző adatok): • A rekord előfordulások rendszerint rendelkeznek egy egyedi azonosítóval (kulcs).

READER

A03/ Scott


17

• Egy SET típus és előfordulásai az alábbi módon jelölhetők:

• Egy SET-nek annyi előfordulása van, ahány előfordulása létezik az owner

rekordtípusának! • Egy SET lényegében egy csoportosítási/osztályozási elvet reprezentál a member

rekord típus előfordulásainak halmazában!

OWNER_A

MEMBER_B

SET A-B

A04/ Black

A01/ Smith

A02/ Jones

A03/ Scott

B02/ Book2

B01/ Book1

B03/ Book3

B05/ Book5

B09/ Book9

B08/ Book8


18

• SET-konstrukciós szabályok:

I. Egyszerű hierarchia (Simple hierarchy) Example: Occurrences:

• Az egyszerű hierarchia előfordulásai egy “erdő”-gráfot képeznek.

CUSTOMER

ORDER

CUS_OR

ORDER_ITEM

OR_DET

OWNER_A

MEMBER*_B

SET A-B

MEMBER_C

SET B-C

C01/ Smith

Or01/ Smith

Or02/ Smith

C02/ Black

Or03/ Black

I01/ Or03

I02/ Or03

I01/ Or01

I02/ Or01

I01/ Or02


19


II. Komplex hierarchia (Complex/compound hierarchy) Example:

Occurrences:

CUSTOMER

ORDER

CUS-ORD

BILL

CUS-BL

OWNER_A

MEMBER_B

SET A-B

MEMBER_C

SET A-C

C01/ Smith

C02/ Black

Or01/ Smith

Or02/ Smith

Or03/ Black

Bl01/ Smith

Bl02/ Smith

Bl03/ Smith

Bl02/ Black

Bl01/ Black


20


III. Egyszerű hálós szerkezet (Simple network structure) Example:

Occurrences:

• M:N kapcsolat reprezentációja (midig lehetséges) !

OWNER_B OWNER_A

MEMBER_C

SET B-C SET A-C

OWNER_B OWNER_A

MEMBER_C

SET A-C SET B-C SET A-C SET B-C SET A-C SET A-C SET A-C SET B-C OR_LIST

PR_LIST OR_LIST

PR_LIST OR_LIST

OWNER_B OWNER_A

SET B-C

MEMBER_C

SET A-C

ORDER PRODUCT

ORD_ITEM

PR_LIST OR_LIST

P1/ pen

P2/ mappe

P3/ pencil

C01/ O01

C01/ O02

C02/ O04

C03/ O03

O01/ P1/10

O02/ P1/60 O01/

P2/70

O04/ P2/40

O02/ P3/90

O04/ P3/20 O02/

P2/80

O04/ P3/50

O03/ P3/25

O03/ P3/45


21

• Integritási megszorítások SET-ekre:

o “Membership” (tagság) kötelező és automatikus. ( A member előfordulásban található „Set

Item” azonosítja az ownert.)

Member előfordulás nem vihető be az ownerje(i) hiányában!

Owner előfordulás nem törölhető, míg van memberje

• SET előfordulások implementációja (adatszerkezetek)

o Láncolt lista (egy, vagy kétirányú).

o A lista feje az owner előfordulásban van.

o Minden member előfordulás tartalmaz egy pointert a következő előfordulásra.

• Előny: a homogén fájl tulajdonság így megőrizhető

• A hálós (network) modell és a hierarchikus (hierarchical) modellek.

• Adatmanipulácó = “navigáció” a hálózatban.


22

• Az ER (egyed-kapcsolat) modell o Bevezető megjegyzés (modellezési szintek, szempontok):

Külső szint (external level) az adatbázis adatait felhasználók nézőpontját tükrözi.

Konceptuális szint (conceptual level) a teljes adatbázis logikai struktúráját írja le (az adatok szerkezete és kapcsolatai).

Belső szint (internal level) megadja, rögzíti az adatbázis számítógépen történő fizikai tárolásával kapcsolatos részleteket.

o Példa: (Telecom adatbázis) External view Billing officers view: System analysts’ view: Conceptual view

• Internal view

• struct string CALL_ID; double sum; string CallersLastName; string CallersFirstName; ...

Callers’ name Date_Time Duration Category Sum

… Date_Time Duration Category Location…

Callers’ name … Sum Date_Time Duration Category Location…


23

• Történet & fő forrás: PETER PIN-SHAN CHEN (MIT, Massachusetts Institute of Technology): The Entity-Relationship Model-Toward a Unified View of Data, ACM Transactions on Database Systems, Vol. 1, No. 1. March 1976, Pages 9-36. ( letölthető: http://www.inf.unibz.it/~nutt/IDBs1011/IDBPapers/chen-ER-TODS-76.pdf )

• Definícó:

Az ER (egyed-kapcsolat) modell (Entity-Relationship (ER) model) egy magas szintű, grafikus adatmodell, amely jól alkalmazható adatbázisok konceptuális tervezésénél.

• Az ER modell alapfogalmai: o Egy egyed (entity, entitás) egy önmagában értelmezhető/létező dolog, vagy

fogalom. Az egyed összes lehetséges „előfordulásainak” halmaza az egyed típus (entity type, entitás típus).

o ER diagram jelölés a student (Hallgato) egyed típus esetén:


24

o Egy attribútum (attribute, tulajdonság) az egyed olyan jellemzője, ami az

egyed előfordulását más egyedektől megkülönbözteti. Az attribútum összes lehetséges értékeinek a halmaza az attribútum tartomány (attribute domain).

Null egy speciális attribútum érték, amely az ismeretlen/hiányzó adatot helyettesíti.


25

o Egyszerű attribútum (simple attribute), amelynek csak egy komponense van (atomikus).

o Összetett attribútum (composite attribute) több komponenssel rendelkezik.

o Ha egy egyed valamely attribútuma az egyed minden egyes előfordulása esetén egy értéket vehet fel, akkor egyértékű (single-valued) attribútumról beszélünk, egyébként az attribútum

o többértékű (multi-valued attribute); jele:


26

o Származtatott attribútum (derived attribute) értéke meghatározható más attribútumok értékeiből. Jele: Szaggatott vonal.

o Egy attribútum (,vagy attribútumok halmaza), amelynek értéke(i) egyértelműen meghatároznak egy egyed előfordulást az egyed kulcsa (key).

o Összetett kulcs (composite key) egynél több attribútum alkotja. o Jele: aláhúzás


27

o A kapcsolat típus (relationship type) egyed típusok közötti viszony. (pl. könyv ~ személy : írta, olvasta, árulta, stb.)

o A kapcsolat (relationship), vagy kapcsolat példány (relationship instance) rendezett pár adott egyed előfordulásokból képezve.

o A kapcsolat típus foka (degree) a résztvevő egyedtípusok száma o Ha ez kettő, akkor a kapcsolat típus bináris (binary). o A szerep név (a kapcsolattípus neve, role name) megadja az egyedek

szerepét (a kapcsolat tartalmát). o A kapcsolat típus megszorítások (constraints) a résztvevő egyedek

száma, minimális elemszám.


28

o Egy kapcsolat(típus)-hoz szintén tartozhatnak attribútumok.

o Példa: order összekapcsolja a chemical és supplier egyedtípusokat. …


29

o Gyenge egyedtípus (weak entity): csak valamely más egyedtípussal együtt létezik. Pl. személyi igazolvány, forgalmi engedély, fizetés lista, átutalás, stb.

o Nincs saját kulcsa, azonosító kapcsolat szükséges. o Jele: kettős vonal.


30

• A relációs adatmodell

• Történet & fő forrás: Edgar Frank Codd: "A Relational Model of Data for Large Shared Data Banks," Communications of the ACM(Vol. 13, No. 6, June 1970, pp. 377-87).

• Korábban: IBM research report RJ599, August 19th, 1969. • letölthető: (pl.) http://www.cs.nott.ac.uk/~psznza/G51DBS/codd.pdf

• Relációs adatmodell: Az a felhasználói szemlélet, amely szerint a

felhasználó az adatbázist időfüggő, normalizált táblázatok együttesének tekinti. o időfüggő: a táblázatok változhatnak a beszúrás, törlés, módosítás során o normalizált: teljesülnek bizonyos formai/tartalmi követelmények (l.:később)

• Előnyei:

o A táblázat az emberek számára az egyik legfontosabb rendező eszköz. o A relációk elmélete egy matematikailag megalapozott deduktív elmélet, az

állítások bizonyíthatók!


31

• Reláció definíció 1.: Legyenek D1, D2, … , Dn nem üres (attribútum-

érték) halmazok (Di egyben az i-edik attribútum neve)! Egy D1, D2, … , Dn fölötti R reláció alatt az R ⊆ D1x D2x … x Dn halmazt értjük. R elemei rendezett n-esek. D1, D2, … , Dn a reláció értelmezési tartományai, n az R reláció foka, R(D1, D2, … , Dn) a reláció sémája.

• Reláció definíció 2.: Legyen Ω = D1, D2, … , Dn ! Ω-n értelmezett függvények egy R halmazát Ω fölötti relációnak nevezzük. Feltesszük, hogy ha f € R, akkor f(Di ) € Di , minden i=1,2, … , n-re.

• Megjegyzések: A két definíció ekvivalens! Ha R véges, mindkettőnél egy táblázattal adható meg. R egy táblázata az R (sémájának megfelelő) példány/előfordulás.

• Példák reláció sémákra: NEV(Vezeteknev, Keresztnev); DATUM(Ev,Honap,nap); IDOPONT(Ora,Perc,Masodperc,Zona); CÍM(Ir_szam,Varos,Utca,Hazszam); TAG(NEV,CÍM,DATUM); VIZSGA(NEVa,NEVb,TARGY,DATUM,JEGY)


32

• Normalizált táblázat (Első normálforma, 1NF) • Az R reláció (táblázata) normalizált (1NF), ha

o Nincs két azonos sor. o A sorok sorrendje lényegtelen. (Nem informatív!) o Az oszlopok sorrendje lényegtelen. o Minden táblaelem elemi (atomikus).

Megjegyzés: egy táblázat „normalizálható”.


33

• A relációs adatmodellezés folyamata • Ősreláció (séma): Ha egy „vállalat” működési adatait feltárjuk és

felsoroljuk, automatikusan egy reláció sémát hozunk létre. • Példa: Közkönyvtár kölcsönzési rendszere ősreláció sémája BIBL(OLV_ID,OLV_NEV,OLV_CIM,OLV_TEL,OLV_FOGL, … , K_ID, K_SZERZ, K_CIM, K_RAKT, … , DATUM, MEGJ) • Problémák (anomáliák)

o Ha BIBL séma 1NF, akkor sok redundanciát tartalmaz. (pl. olvasó adatai ismétlődhetnek).

o Bővítési anomália: hogyan vigyünk fel egy új könyvet/olvasót. (NULL adat!!!) o Módosítási anomália: megváltozik egy olvasó címe. (példa: Német IR-sz). o Törlési anomália: „fürdővízzel a gyereket!”; adatvesztés! o Az anomáliák közös háttere: valamilyen önmagában érdekes dolgot

kapcsolatain keresztül ábrázoltunk. o Kézenfekvő megoldás:Bontsuk fel az őstáblázatot célszerűen kisebb

táblázatokra úgy hogy minden információ megmaradjon, amit az őstáblázat tartalmazott:

OLV(OLV_ID,OLV_NEV,OLV_CIM,OLV_TEL,OLV_FOGL, …) KONYV(K_ID, K_SZERZ, K_CIM, K_RAKT, … ) KOLCS(OLV_ID, K_RAKT, DATUM, MEGJ)


34

• Funkcionális függőségek Legyen R(D1, D2, … , Dn) = R(Ω) egy reláció séma és legyen A,B ⊆ Ω. Azt mondjuk, hogy az R sémában B funkcionálisan függ az A-tól (jele: A → B),

ha tetszőleges f,g € R esetén abból, hogy f(x)=g(x) minden x€A-ra,

következik, hogy f(x)=g(x) minden x€B-re.

• Ez azt jelenti, hogy az R táblázataiban minden egyes sor A-beli (oszlop-) értékei egyértelműen meghatározzák a sor B-beli (oszlop-) értékeit.

• Funkcionális (=függvényszerű), egyértelmű kapcsolat van az A-beli és B-beli értékek között.


35

• A funkcionális függőségek tulajdonságai Legyen R(D1, D2, … , Dn) = R(Ω) egy reláció séma és legyen X,Y,Z,V⊆ Ω.

1. Reflexivitás: Ha Y⊆X, akkor X→Y. 2. Augmentivitás: Ha X→Y, akkor XUZ→YUZ. 3. Tranzitivitás: Ha X→Y és Y→Z, akkor X→Z. 4. Dekompozíció: Ha X→YUZ, akkor X→Y. 5. Additivitás: Ha X→Y és X→Z, akkor X→YUZ. 6. Pszeudotranzitivitás: Ha X→Y és VY→Z, akkor VX→Z.

• 1.-6.: bebizonyítható tételek. • Amstrong axiómák: 1-6 – ból bármely funkcionális függőség

levezethető! • „Megfordítás” problémája! • Függetlenség problémája!

• A funkcionális függőség, mint az adatmodellező eszköze: az

adatok tulajdonságai és kapcsolatai a funkcionális függőségek nyelvén fogalmazódnak meg.


36

• Normálformák • Alapvető definíciók: Legyen R(D1, D2, … , Dn) = R(Ω) egy reláció séma és legyen X,Y,Z,V⊆ Ω. • X-től teljesen funkcionálisan függ az Y R-ben, ha X→Y és Y nem

függ X egyetlen valódi részhalmazától sem. • Ha X→Ω, akkor X kulcsjelölt R-ben. • Ha az X→Ω függés teljes, akkor X kulcs R-ben. • X elsődleges kulcs R-ben, ha az adatmodellező annak nyilvánítja! • R egy Di attribútuma elsődleges, ha eleme R valamely kulcsának,

egyébként az attribútum másodlagos.

• Megjegyzés: o ha egy reláció 1NF, akkor van benne kulcsjelölt / kulcs. o „Kívánatos”, hogy az elsődleges kulcs kulcs legyen!

Pl. nev, anyja_neve • A funkcionális függés és a redundancia kapcsolata.


37

• Normálformák • Egy 1NF R reláció második normálformájú (2NF), ha minden

másodlagos attribútum teljesen funkcionálisan függ R minden kulcsától. o Gyengítés: „minden” kulcs helyett „elsődleges” kulcs! o Példa: BIBL(OLV_ID,OLV_NEV,OLV_CIM,OLV_TEL,OLV_FOGL, … ,

K_ID, K_SZERZ, K_CIM, K_RAKT, … , DATUM, MEGJ) 1NF, de nem 2NF!

• Tranzitív függés: Egy Z attribútumhalmaz tranzitívan függ az X-től R-ben, ha van olyan Y, hogy X→Y→Z, de nem teljesül X←Y←Z.

• Egy 2NF R reláció harmadik normálformájú (3NF), ha egyetlen másodlagos attribútumhalmaz sem függ egy másik másodlagos attribútumhalmazon keresztül tranzitív módon valamely kucstól.

• Megjegyzés: o Vannak további (erősebb) normálformák is. o A gyakorlatban addig „normalizálunk”, míg 3NF táblázatokhoz nem

jutunk. o Követelmény: Ha egy táblázatot több másikkal helyettesítünk, nem

veszíthetünk információt!


38

Ajánlott forrás: http://www.inf.unideb.hu/kmitt/konvkmitt/fejezetek_az_adatbazisrendszerek_elmeletebol/book.xml.html


39

• A relációs modell és az adatmanipuláció • Alapvetés:

o a reláció halmaz! o az adatmanipuláció során halmazokból újabb halmaz(oka)t

származtatunk! • Technikák:

o Kalkulus: megadjuk a származtatni kívánt halmaz elemeinek jellemző tulajdonságát (ítélet, predikátum).

o Algebra: megadunk egy kifejezést, amely leírja, milyen műveletek eredményeként adódik a származtatni kívánt halmaz ismert halmazokból.

• Példa: o A = szőke lányok , B = barna szemű lányok o Kalkulus: szőke és barna szemű lányok o Algebra: A ∩ B


40

• A reláció algebra • Műveletek:

o Hagyományos halmazalgebrai műveletek. unió (U), metszet (∩), kivonás (\), Descartes-szorzat (X), Kapcsolatuk az adatmanipulációval, unió-kompatibilitás.

o Reláció táblákon értelmezett speciális műveletek. projekció (oszlopok kiválasztása), szelekció (sorok kiválasztása), összekapcsolás (Join, Descartes-szorzaton alkalmazott szelekció)

osztás (join „inverz”-e)


41

• A relációs modell és az SQL • SQL DDL:

o CREATE … • SQL DML

o SELECT … o INSERT … o DELETE … o UPDATE …

• SQL DCL: o …

adatbÁzis rendszerek · 2017-05-05 · o ilyen pl. a merevlemez, de nem ilyen a mágnesszalag. •...

Documents