Adatbázis tervezése feladatok

Adatbázis tervezése feladatok

adatbázis

Adatbázis tervezése - feladatok

Adatbázis

Adatbázis tervezése - feladatok

Normalizáld az alábbi relációt:
SZAKÁCS(név, születési év, ételkód, ételnév, adag, cím, fajtakód, fajtanév)

Az 1NF (Első Normál Forma) biztosítja, hogy:

  1. Az oszlopok értékei atomiak, azaz minden mező csak egyetlen értéket tartalmaz (nincs többértékű attribútum, például egyetlen cellában nem szerepel több ételkód vagy cím).
  2. Minden sorban az oszlopok száma és sorrendje konzisztens.

A jelenlegi relációban (SZAKÁCS):

  • "név", "születési év", "ételkód", "ételnév", "adag", "cím", "fajtakód", "fajtanév" mezők vannak.
  • A reláció megfelel az 1NF követelményeinek, mivel minden attribútum atomi, és nincs többértékű érték egy mezőben.

Második Normál Forma (2NF)

A 2NF követelményei:

  1. Az előfeltétel az, hogy a reláció már 1NF-ben van.
  2. Minden nem kulcs attribútum teljesen funkcionálisan függ az elsődleges kulcstól, azaz:
    • Egyik nem kulcs attribútum sem függhet az elsődleges kulcs egy részétől (ez a részleges függőség kiküszöbölése).

Elemzés a példára (SZAKÁCS táblázat):

A reláció elsődleges kulcsa: (név, ételkód)

Függőségek az adatok alapján:
  1. Név → születési év, cím
    Ez azt jelenti, hogy egy szakács neve alapján egyértelműen meghatározható a születési év és a cím. Ezek nem függnek az ételkódtól.
  2. Ételkód → ételnév, fajtakód, fajtanév
    Ez azt jelenti, hogy az ételkódhoz kapcsolódik az étel neve, illetve az ételhez tartozó fajtakód és fajtanév. Ezek sem függnek a szakács nevétől.
  3. (Név + Ételkód) → adag
    Ez az egyetlen olyan attribútum, amely teljesen függ az elsődleges kulcstól (a név és az ételkód együtt).

A táblázat részleges függőségei:

  • Név → születési év, cím: részleges függőség, mert csak a kulcs egyik része (név) határozza meg az attribútumokat.
  • Ételkód → ételnév, fajtakód, fajtanév: részleges függőség, mert csak a kulcs egyik része (ételkód) határozza meg az attribútumokat.

Megoldás: 2NF normalizálás

A részleges függőségek megszüntetése érdekében szétbontjuk a relációt három táblára:

  1. SZAKÁCS(név, születési év, cím)
    • Tartalmazza a szakácsokkal kapcsolatos attribútumokat, amelyeket a "név" egyértelműen meghatároz.
  2. ÉTEL(ételkód, ételnév, fajtakód, fajtanév)
    • Tartalmazza az ételekhez kapcsolódó adatokat, amelyeket az "ételkód" egyértelműen meghatároz.
  3. KÉSZÍT(név, ételkód, adag)
    • Kapcsoló tábla, amely a szakácsok és az általuk készített ételek kapcsolatát tárolja, valamint az ehhez tartozó adagot.

Eredmény (2NF-ben):

  1. SZAKÁCS tábla:
    Név Születési év Cím
    Kovács Anna 1985 Budapest
    Nagy Péter 1990 Debrecen
  2. ÉTEL tábla:
    Ételkód Ételnév Fajtakód Fajtanév
    101 Gulyás 1 Leves
    102 Túrógombóc 2 Desszert
  3. KÉSZÍT tábla:
    Név Ételkód Adag
    Kovács Anna 101 50
    Nagy Péter 102 30

Összegzés:

A 2NF elérése során megszüntettük a részleges függőségeket:

  • A szakácsokkal kapcsolatos attribútumok egy külön táblába kerültek.
  • Az ételekhez kapcsolódó attribútumok szintén egy külön táblába kerültek.
  • A szakácsok és az ételek közötti kapcsolatot egy harmadik, kapcsoló tábla rögzíti.

Harmadik Normál Forma (3NF)

A 3NF feltételei:

  1. Az előfeltétel az, hogy a reláció már 2NF-ben van.
  2. Egy reláció akkor van 3NF-ben, ha:
    • Minden nem kulcs attribútum kizárólag az elsődleges kulcstól függ.
    • Nem lehet tranzitív függőség, vagyis egy nem kulcs attribútum nem függhet másik nem kulcs attribútumtól.

Elemzés a példára (SZAKÁCS tábla):

2NF után kapott táblák:

  1. SZAKÁCS(név, születési év, cím)
  2. ÉTEL(ételkód, ételnév, fajtakód, fajtanév)
  3. KÉSZÍT(név, ételkód, adag)

Tranzitív függőség vizsgálata:

  1. Az SZAKÁCS tábla rendben van: a "név" egyértelműen meghatározza a "születési év" és "cím" attribútumokat, nincs tranzitív függőség.
  2. Az ÉTEL táblában azonban van tranzitív függőség:
    • Ételkód → fajtakód → fajtanév
      • Az "ételkód" meghatározza a "fajtakódot", és a "fajtakód" meghatározza a "fajtanév" attribútumot. Ez egy tranzitív függőség, amelyet el kell távolítani.

Megoldás: 3NF normalizálás

A tranzitív függőség megszüntetése érdekében szétbontjuk az ÉTEL táblát:

  1. ÉTEL(ételkód, ételnév, fajtakód)
    • Az "ételkód" alapján meghatározható az étel neve és a fajtakód.
  2. FAJTA(fajtakód, fajtanév)
    • A "fajtakód" alapján meghatározható a fajta neve.

 

 

Eredmény (3NF-ben):

  1. SZAKÁCS tábla:
    Név Születési év Cím
    Kovács Anna 1985 Budapest
    Nagy Péter 1990 Debrecen
  2. ÉTEL tábla:
    Ételkód Ételnév Fajtakód
    101 Gulyás 1
    102 Túrógombóc 2
  3. FAJTA tábla:
    Fajtakód Fajtanév
    1 Leves
    2 Desszert
  4. KÉSZÍT tábla:
    Név Ételkód Adag
    Kovács Anna 101 50
    Nagy Péter 102 30

Összegzés:

  • A 3NF elérése érdekében megszüntettük a tranzitív függőségeket.
  • Az ÉTEL táblából eltávolítottuk a "fajtanév" attribútumot, és egy külön FAJTA táblába helyeztük.
  • Most már minden nem kulcs attribútum kizárólag az elsődleges kulcstól függ, nincs tranzitív függőség

 

Boyce-Codd Normál Forma (BCNF) és a Különbség a 3NF-hez Képest

Miért lehet szükség BCNF-re?

A BCNF szigorúbb, mint a 3NF. Egy reláció 3NF-ben lehet, de még mindig tartalmazhat olyan függőségeket, amelyek nem felelnek meg a BCNF kritériumainak.

  • 3NF kritériuma: Minden nem kulcs attribútum kizárólag az elsődleges kulcstól függ.
  • BCNF kritériuma: Minden funkcionális függőség bal oldala szuperkulcs kell, hogy legyen.

Ez azt jelenti, hogy BCNF-ben nem lehet olyan funkcionális függőség, ahol a bal oldalon nem egy szuperkulcs található.

 

Elemzés a példára (SZAKÁCS tábla)

3NF után kapott táblák:

  1. SZAKÁCS(név, születési év, cím)
  2. ÉTEL(ételkód, ételnév, fajtakód)
  3. FAJTA(fajtakód, fajtanév)
  4. KÉSZÍT(név, ételkód, adag)

BCNF vizsgálat:

  1. SZAKÁCS: Nincs további függőség. A "név" egyértelműen meghatározza a "születési év" és "cím" attribútumokat. Ez már BCNF-ben van.
  2. ÉTEL: Nincs további függőség. Az "ételkód" szuperkulcs, és minden attribútum tőle függ. Ez is BCNF-ben van.
  3. FAJTA: Nincs további függőség. A "fajtakód" szuperkulcs, és meghatározza a "fajtanév" attribútumot. Ez BCNF-ben van.
  4. KÉSZÍT: Vizsgáljuk meg az esetleges függőségeket.

 

BCNF probléma a KÉSZÍT táblában

A KÉSZÍT(név, ételkód, adag) tábla tartalma:

Név Ételkód Adag
Kovács Anna 101 50
Kovács Anna 102 30
Nagy Péter 101 20
Nagy Péter 102 40

Funkcionális függőségek:

  1. (Név, Ételkód) → Adag (minden kombináció meghatározza az adagszámot).
  2. Nincs olyan további függőség, amely sértené a BCNF-et, mert:
    • A "Név" és "Ételkód" páros szuperkulcs, és minden attribútum kizárólag ettől függ.

Eredmény (BCNF-ben):

A 3NF után a táblák már teljesítik a BCNF kritériumait is, mert:

  • Minden funkcionális függőség bal oldala szuperkulcs.
  • Nincs olyan további függőség, amely felbontást igényelne.
Adatbázis tervezése

Adatbázis tervezése

adatbázis

Adatbázis tervezése

Adatbázis

Normalizálás, adatbázis tervezése

 

Normalizálás

A normalizálás az adatbázis tervezésének egyik kulcsfontosságú folyamata, amelynek célja az adatok redundanciájának minimalizálása és az adatstruktúra logikai átláthatóságának növelése. A folyamat során az adatokat kisebb, egymással összefüggő táblázatokra bontjuk, miközben biztosítjuk, hogy az adatok közötti kapcsolatok egyértelműek és konzisztens módon kezelhetők legyenek.

Normalizálás definíciója (magyarázattal):

A normalizálás egy táblázatbontó relációs művelet, amely során:

  • Az adatok szervezése oly módon történik, hogy az ismétlődő vagy redundáns adatokat eltávolítjuk.
  • Az adatbázisban tárolt információk strukturáltan, egymással logikailag összefüggő módon helyezkednek el.
  • Minden tárolt adat egyértelműen kapcsolódik egy elsődleges kulcshoz.

Miért fontos a normalizálás?

  • Csökkenti a tárolási igényt: Az adatok redundanciájának megszüntetésével kevesebb helyet foglalnak az adatbázisban.
  • Megszünteti az anomáliákat: A módosítási, beszúrási vagy törlési műveletek során fellépő hibalehetőségeket minimalizálja.
  • Átláthatóságot biztosít: A jól normalizált adatbázis könnyen kezelhető, módosítható és bővíthető.

A relációs adatbázisok és az 1NF követelménye:

Minden relációs adatbázis-kezelő rendszer alapfeltétele az 1. normál forma teljesítése. Ez biztosítja, hogy az adatbázis alapvető struktúrája megfeleljen az adatok hatékony és konzisztens kezelésének.

Normalizálás alapvetések

A normalizálás célja az adatbázis szerkezetének optimalizálása, amely során megszüntetjük a redundáns adatokat, elkerüljük az anomáliákat, és biztosítjuk az adatok konzisztens szervezését. Lássuk részletesen, mit jelent mindez, és hogyan kapcsolódnak hozzá a funkcionális függőségek.

Mi az a redundancia és miért kerülendő?

A redundancia többszörös, felesleges adattárolást jelent. Ez az alábbi problémákat eredményezheti:

  • Felesleges helyfoglalás: Az ismétlődő adatok növelik az adatbázis méretét.
  • Anomáliák keletkezése:
    • Módosítási anomália: Egy adat módosításakor az ismétlődő példányokat is frissíteni kell; ennek elmulasztása ellentmondásokat okozhat.
    • Beszúrási anomália: Bizonyos attribútumok hiánya akadályozhatja új adatok beszúrását.
    • Törlési anomália: Egy rekord törlése olyan adatokat is eltávolíthat, amelyekre még szükség lenne.

Az adatbázis konzisztenciájának fontossága

Az adatbázis akkor konzisztens, ha csak egymással logikailag összefüggő, valós adatokat tartalmaz. A redundancia és az anomáliák azonban az adatok inkonzisztenciájához vezethetnek, amelyeket a normalizálással előzhetünk meg.

Funkcionális függőség: A normalizálás alapja

A funkcionális függőség az attribútumok közötti logikai kapcsolatot írja le. Ha egy attribútum (X) értéke meghatározza egy másik attribútum (Y) értékét, azt mondjuk, hogy Y funkcionálisan függ X-től.

Példa:

  • Egy alkalmazotti nyilvántartásban az "azonosító" meghatározza a "név" attribútumot. Ez azt jelenti, hogy az azonosítóból egyértelműen levezethető a név.

Főbb tulajdonságok:

  • X → Y igaz, de ebből nem következik, hogy Y → X.
  • Ha K egy kulcs a relációban, akkor K funkcionálisan meghatározza az összes attribútumot a relációban.

A funkcionális függőségek következményei: Armstrong-axiómák részletesen

Az Armstrong-axiómák a funkcionális függőségek alapvető következtetési szabályai, amelyek segítenek új függőségeket levezetni meglévő függőségek alapján. Ezek az axiómák biztosítják, hogy az adatbázis logikai szerkezete helyesen legyen meghatározva.

1. Reflexivitás

Ha Y egy részhalmaza X-nek, akkor X → Y igaz.

  • Magyarázat: Ha egy attribútumhalmaz már tartalmaz egy másik attribútumot vagy annak halmazát, akkor az egyértelműen levezethető.
  • Példa:
    • X = {azonosító, név, születési év}
    • Y = {név, születési év} (részhalmaz)
    • Következmény: {azonosító, név, születési év} → {név, születési év}

2. Bővítés (Augmentáció)

Ha X → Y, akkor tetszőleges Z attribútumhalmaz hozzáadása után XZ → YZ is igaz.

  • Magyarázat: Ha egy halmaz már meghatároz egy másik halmazt, akkor a közös kiegészítésük is meghatározó lesz.
  • Példa:
    • X = {azonosító}, Y = {név}, ahol azonosító → név
    • Z = {beosztás}
    • Következmény: {azonosító, beosztás} → {név, beosztás}

3. Tranzitivitás

Ha X → Y és Y → Z, akkor X → Z is igaz.

  • Magyarázat: Ha az egyik attribútumhalmazból levezethetünk egy másikat, és abból további attribútumokat, akkor az elsőből közvetlenül levezethető a harmadik.
  • Példa:
    • X = {azonosító}, Y = {név}, Z = {osztály}
    • Ha azonosító → név és név → osztály, akkor azonosító → osztály is igaz.

4. Szétvágási szabály

Ha X → YZ, akkor X → Y és X → Z is igaz.

  • Magyarázat: Ha egy halmaz meghatározza két attribútum együttes értékét, akkor ezek külön-külön is levezethetők.
  • Példa:
    • X = {azonosító}, YZ = {név, beosztás}
    • Ha azonosító → {név, beosztás}, akkor:
      • azonosító → név
      • azonosító → beosztás

5. Egyesítési szabály

Ha X → Y és X → Z, akkor X → YZ is igaz.

  • Magyarázat: Ha egy attribútumhalmaz külön-külön meghatározza két másik halmaz értékét, akkor azok együtt is levezethetők.
  • Példa:
    • X = {azonosító}, Y = {név}, Z = {beosztás}
    • Ha azonosító → név és azonosító → beosztás, akkor:
      • azonosító → {név, beosztás}

6. Pseudotranzitivitás

Ha X → Y és WY → Z, akkor WX → Z is igaz.

  • Magyarázat: Ha egy attribútumhalmazból (X) egy másik attribútumhalmazt (Y) levezethetünk, és egy harmadik halmaz (W) ezt kiegészítve levezet egy további attribútumot (Z), akkor az első kettő együtt is meghatározó.
  • Példa:
    • X = {azonosító}, Y = {beosztás}, W = {név}, Z = {osztály}
    • Ha azonosító → beosztás és {név, beosztás} → osztály, akkor:
      • {azonosító, név} → osztály

Az Armstrong-axiómák biztosítják az attribútumok közötti kapcsolatok pontos meghatározását és logikai következményeinek levezetését. Ezek a szabályok segítenek az adatbázis helyes tervezésében és a funkcionális függőségek megfelelő kezelésében.

A normalizálás folyamata

0NF, UNF vagy 0. Normál forma

Ez a normalizálatlan relációs séma. Vesszük az összes mezőt, melyet az adatbázisnak tartalmaznia kell. Leírjuk egy nagy táblázatba, ahol minden szükséges mező szerepel, de még nem teljesíti a relációs modell követelményeit, például:
- többértékű attribútumot tartalmaz
- beágyazott táblázatot tartalmaz
- nincs elsődleges kulcsa

Név Szak Hobbi
Kék Ibolya Informatika Olvasás, Zene


1NF vagy első normálforma 

- az oszlopok szám és sorrendje minden sorban azonos
- minden oszlop csak meghatározott értéket vehet fel az attribútum értéktartományból
- minden mező csak egy értéket vehet fel
- nincs összetett attribútum
- nincs beágyazott reláció (olyan tulajdonság, melynek értéke nem atomi)
- minden sorhoz egy egyedi kulcs tartozik, amitől az összes többi mező funkcionálisan függ (nincs két egyforma sor)

A hobbit külön sorokba bontjuk:

Név Szak Hobbi
Kék Ibolya Informatika Olvasás
Kék Ibolya Informatika Zene


2NF - második normálforma

1NF-ben van (előfeltétel) ÉS a nem kulcs attribútumok funkcionálisan függnek az elsődleges kulcstól. Megszünteti a részleges függőségeket, amelyek akkor fordulnak elő, ha egy nem kulcs attribútum csak a kulcs egy részétől függ.

 

Teljes funkcionális függőség

Egy attribútum teljes mértékben egy másik attribútumhalmaztól függ, azaz az adott attribútumot nem lehet meghatározni a kulcs egyetlen részhalmazából. Minden nem kulcs attribútum kizárólag a teljes elsődleges kulcstól függ.

Példa: Egy adatbázis, amely egyetemek kurzusainak részleteit tárolja:

Kurzus ID Hallgató ID Jegy
101 201 5
101 202 4
102 201 3
  • Elsődleges kulcs: {Kurzus ID, Hallgató ID}
  • Jegy attribútum teljes funkcionális függőségben van a {Kurzus ID, Hallgató ID} kulccsal. Ez azt jelenti, hogy a Jegy értéke csak a teljes kulcs (Kurzus ID és Hallgató ID) alapján egyértelműen meghatározható.

Miért teljes függőség?

  • Ha csak a Kurzus ID van megadva, nem tudjuk, melyik hallgató jegyéről van szó.
  • Ha csak a Hallgató ID van megadva, nem tudjuk, melyik kurzus jegyéről van szó.
  • Csak a {Kurzus ID, Hallgató ID} együttes megléte adja meg a Jegy értékét.

Részleges funkcionális függőség

Egy attribútum csak a kulcs egy részétől függ, nem pedig a teljes kulcstól. Ez redundanciát okozhat, és ellentmond az 2NF követelményeinek.

Példa: Egy adatbázis, amely tanárok által tartott kurzusokat tárolja:

Kurzus ID Tanárok ID Kurzus neve Tanár neve
101 T1 Matematika Kovács Béla
102 T2 Fizika Nagy Anna
  • Elsődleges kulcs: {Kurzus ID, Tanárok ID}
  • Kurzus neve attribútum teljes funkcionális függőségben van a Kurzus ID-tól.
  • Tanár neve attribútum részleges funkcionális függőségben van, mert csak a Tanárok ID-tól függ, nem a teljes kulcstól.

Miért részleges függőség?

  • A Tanár neve attribútumot meg tudjuk határozni csak a Tanárok ID alapján, függetlenül a teljes kulcstól.

Átalakítás 2NF-re:

  1. Hozzunk létre külön táblát a tanároknak:

    Tanárok ID Tanár neve
    T1 Kovács Béla
    T2 Nagy Anna
  2. Az eredeti táblát átalakítjuk:

    Kurzus ID Kurzus neve Tanárok ID
    101 Matematika T1
    102 Fizika T2

Összegzés

  1. Teljes funkcionális függőség:

    • Az attribútum a teljes elsődleges kulcstól függ.
    • Nincs redundancia vagy részleges kapcsolat.
    • Példa: Egy kurzuson belüli jegyek, amelyek a kurzus és hallgató kombinációjától függnek.
  2. Részleges funkcionális függőség:

    • Az attribútum csak a kulcs egy részétől függ.
    • Redundanciát okoz, amelyet külön táblázatokba helyezéssel szüntethetünk meg.
    • Példa: Tanárok neve, amely csak a tanár azonosítójától függ, nem a teljes kulcstól.

3NF - harmadik normálforma

A 3NF célja, hogy eltávolítsa a tranzitív függőségeket az adatbázisból. Egy tábla akkor van 3NF-ben, ha:

  1. 2NF-ben van, és
  2. Nincs olyan nem elsődleges attribútum, amely tranzitív (közvetett) módon függ az elsődleges kulcstól.

Tranzitív funkcionális függőség:

Egy X → Z függőség tranzitív, ha létezik olyan Y attribútumhalmaz, amelyre:

  • X → Y és
  • Y → Z is teljesül.

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

Dolgozó ID (Szsz) Osztályszám (Oszám) Főnök neve
1 101 Kovács Béla
2 101 Kovács Béla
3 102 Nagy Anna
  • X → Y: Dolgozó ID → Osztályszám (egy dolgozó csak egy osztályhoz tartozik).
  • Y → Z: Osztályszám → Főnök neve (egy osztályhoz egy főnök tartozik).
  • X → Z (tranzitív): Dolgozó ID → Főnök neve (közvetett függőség).

Probléma: Ha a főnök neve megváltozik, az adatot több helyen kell módosítani, ami redundanciát okoz.

 

3NF-re normalizálás

  1. Bontás külön táblákra:

    • Hozzunk létre egy külön Osztályok táblát, amelyben tároljuk az osztályok azonosítóját és a hozzájuk tartozó főnök nevét.
    • Az eredeti táblában csak a Dolgozó ID és az Osztályszám marad.
  2. Átalakított táblák:

    • Dolgozók tábla:

      Dolgozó ID (Szsz) Osztályszám (Oszám)
      1 101
      2 101
      3 102
    • Osztályok tábla:

      Osztályszám (Oszám) Főnök neve
      101 Kovács Béla
      102 Nagy Anna

Miért fontos a 3NF?

  • Redundancia megszüntetése: Az adatok csak egyszer kerülnek tárolásra, így csökken a redundancia.
  • Egyszerűbb adatkezelés: Ha egy adat megváltozik (pl. egy osztály főnöke), csak egy helyen kell módosítani.
  • Karbantartás megkönnyítése: A tranzitív függőségek eltávolításával kevesebb adatkonfliktus és inkonzisztencia lép fel.
    A Harmadik normál forma (3NF) célja, hogy az adatbázist tovább optimalizálja azáltal, hogy megszünteti a tranzitív függőségeket. Ezáltal az adatok még strukturáltabbak, könnyebben kezelhetők és karbantarthatók lesznek.

Egyéb normálformák

Boyce-Codd normál forma (BCNF)

Definíció:
Egy reláció sémája BCNF-ben van, ha minden X → Y funkcionális függőség esetén X szuperkulcs. Ez azt jelenti, hogy X attribútumainak egyedi módon kell azonosítaniuk az adott reláció összes sorát.
A Boyce-Codd normál forma (BCNF) egy szigorúbb változata a harmadik normál formának (3NF). A különbség lényege, hogy a BCNF kizárja azokat a funkcionális függőségeket is, amelyeket a 3NF megenged, ha azok nem kulcs attribútumokat érintenek.

  • A 3NF lehetővé teszi, hogy egy nem kulcs attribútum függjön egy másik nem kulcs attribútumtól, ha ez nem sérti a tranzitív függőségek szabályait.
  • A BCNF ezt a megengedést szünteti meg: minden attribútum függősége esetén a függőség bal oldala (determináns) szuperkulcs kell, hogy legyen.

     

    BCNF és 3NF közötti különbség

    1. 3NF: Egy reláció 3NF-ben van, ha:

      • Minden funkcionális függőség esetén legalább az egyik oldal kulcsjelölt.
      • Megengedett, hogy nem kulcs attribútum függjön más nem kulcs attribútumtól (tranzitív függőség), ha a tranzitív függőség nem sérti az adatbázis integritását.
    2. BCNF: Egy reláció BCNF-ben van, ha:

      • Minden funkcionális függőség bal oldala (a determináns) szuperkulcs. Ez azt jelenti, hogy a bal oldali attribútumok egyedileg azonosítják a teljes relációt.

👉 Példa:

Tanár Tantárgy Tanári szoba
Kiss Anna Matematika 101
Kovács Béla Fizika 102
Kiss Anna Informatika 101


Függőségek a táblában:

  1. Tanár → Tanári szoba
    • Egy tanárhoz mindig ugyanaz a tanári szoba tartozik.
  2. Tanár, Tantárgy → Tanári szoba
    • Egy tanár és a tantárgy együttesen meghatározza a tanári szobát.

3NF

  • Egy reláció 3NF-ben van, ha:
    1. Minden attribútum közvetlenül az elsődleges kulcstól függ.
    2. Nincs tranzitív függőség a nem kulcs attribútumok között.

3NF alkalmazása a példánkra:

  • Az elsődleges kulcs: Tanár, Tantárgy
  • A függőségek:
    • Tanár → Tanári szoba → Ez nem sérti a 3NF-et, mert a "Tanár" attribútum lehet nem kulcs attribútum is, ha ez az adatbázis szervezését nem bonyolítja vagy nem vezet redundanciához.

A táblázat tehát 3NF-ben van.

 

BCNF

  • Egy reláció BCNF-ben van, ha:
    1. Minden függőség bal oldala szuperkulcs.

Mi a probléma BCNF szempontjából?

  • A függőség: Tanár → Tanári szoba → Itt a bal oldali attribútum (Tanár) nem szuperkulcs (mert nem azonosítja egyedileg a táblázat sorait).
  • Emiatt a tábla nincs BCNF-ben, mert "Tanár" nem az elsődleges kulcs része.

BCNF normalizálása

A táblát két részre kell bontani, hogy minden függőség bal oldala szuperkulcs legyen:

  1. Első tábla (Tanár és Tanári szoba kapcsolata):
Tanár Tanári szoba
Kiss Anna 101
Kovács Béla 102
  1. Második tábla (Tantárgy és Tanár kapcsolata):
Tanár Tantárgy
Kiss Anna Matematika
Kovács Béla Fizika
Kiss Anna Informatika
  • 3NF-ben maradhat egy olyan függőség, ahol a bal oldali attribútum nem szuperkulcs, ha ez nem okoz redundanciát vagy adatvesztést.
  • BCNF-ben minden függőség bal oldalának szuperkulcsnak kell lennie, ami azt jelenti, hogy minden bal oldali attribútumnak egyedileg azonosítania kell a táblázat minden sorát.

4NF - negyedik normál forma

Definíció:

Egy reláció sémája 4NF-ben van, ha:

  • Minden X → Y többrétű függőség esetén X szuperkulcs.
  • Többrétű függőség: Egy X attribútum több, egymástól független Y és Z attribútumhoz kapcsolódik.

👉 Példa:

  • Adattábla (Diákok):
Diák neve Nyelv Sport
Anna Angol Kosárlabda
Anna Német Kosárlabda
Anna Angol Röplabda
Anna Német Röplabda

Függőségek:

  1. Diák neve → Nyelv
  2. Diák neve → Sport

Probléma:
A táblázatban redundancia lép fel, mert a "Nyelv" és a "Sport" független egymástól.

Megoldás (4NF-re normalizálás):

  1. Tábla 1: Diák neve → Nyelv

    Diák neve Nyelv
    Anna Angol
    Anna Német
  2. Tábla 2: Diák neve → Sport

    Diák neve Sport
    Anna Kosárlabda
    Anna Röplabda

5NF - ötödik normál forma

Definíció:
Egy reláció sémája 5NF-ben van, ha nincs nem-triviális összekapcsolási függőség. Ez azt jelenti, hogy a táblák kapcsolatai nem bonthatók fel további táblákra anélkül, hogy információt veszítenénk.

👉 Példa:

  • Munkatárs Projekt Szerep
    Anna A Tervező
    Anna B Fejlesztő
    Bence A Fejlesztő
    Bence B Tesztelő


    Probléma:

    Az adatok redundánsak, és nincs biztosítva, hogy az "Anna" és "Bence" kapcsolatai a projektekhez és a szerepekhez helyesek maradjanak, ha új adatot vezetünk be. Ha például Anna egy új projektben "Tervező" szerepet kap, a redundancia miatt több sor is frissítésre szorul.



    5NF Normalizálása

    Az 5NF célja: Az összekapcsolási függőségeket úgy bontja szét, hogy minden reláció információvesztés nélkül helyreállítható legyen.

     

    1. Táblázat: Munkatárs → Projekt

    Munkatárs Projekt
    Anna A
    Anna B
    Bence A
    Bence B


    2. Táblázat: Projekt → Szerep

    Projekt Szerep
    A Tervező
    A Fejlesztő
    B Fejlesztő
    B Tesztelő


    3. Táblázat: Munkatárs → Szerep

     

    Munkatárs Szerep
    Anna Tervező
    Anna Fejlesztő
    Bence Fejlesztő
    Bence Tesztelő
  • 6NF - Hatodik normál forma 

    Definíció:
    Elméleti normál forma, amely a relációkat teljes mértékben dekomponálja időbeli függőségek kezelésére. Gyakorlatban ritkán alkalmazzák.

Access – alapfogalmak

Access – alapfogalmak

adatbázis

Access - Alapfogalmak

Adatbázis

Access - Alapfogalmak

 

Adat

Az adat tények, fogalmak olyan megjelenési formája, mely alkalmas emberi eszközökkel történő értelmezésre, feldolgozásra, továbbításra


Adatbázis rendszerek

Adatbázisnak az adatoknak kapcsolataikkal együtt való redundancia nélküli ábrázolását, tárolását értjük. Azokat a szoftvereket, melyek ezt kezelik, adarbáziskezelő-rendszernek nevezzük. Az adatbáziskezelő rendszer az alábbi feladatokat látja el:
- adatrögzítés
- adattárolás
- műveletek az adatokkal
- változások követése

Adatmodellek és az adatbázis szerkezete

Az Access használata során az adatmodellek ismerete az alapja az adatbázis tervezésének. Minden adatbázis mögött egy gondosan megtervezett adatmodell áll, amely meghatározza, hogy az adatok hogyan kapcsolódnak egymáshoz. Ez az alapozás segíti a hatékony táblák létrehozását és azok kapcsolatainak kialakítását.

  1. Adatmodellek:

    • Az adatmodellek meghatározzák az adatok logikai struktúráját.
    • Az entitások (például „Tanulók” vagy „Könyvek”) határozzák meg a táblák tartalmát.
    • Az attribútumok (például „Név” vagy „ISBN”) határozzák meg, hogy milyen adatokat tárolsz az egyes táblákban.
    • Az kapcsolatok (például „Kölcsönzés”) határozzák meg, hogyan függnek össze az entitások egymással.
  2. Táblák létrehozása:

    • A táblák az adatmodellek fizikai megvalósításai. Minden táblának egyértelmű célja van: például a „Tanulók” tábla a diákokról tárol adatokat, míg a „Kölcsönzések” tábla a könyvkölcsönzési adatokat tartalmazza.
    • Az adatmodellek ismerete alapján tudjuk, hogy milyen mezők szükségesek egy adott táblában, és hogy milyen típusú adatok kerülnek oda.
  3. Kapcsolatok kialakítása:

    • Miután a táblákat létrehoztad, az entitások közötti kapcsolatokat kell megtervezni. Például:
      • Egy tanuló (entitás) több könyvet is kölcsönözhet.
      • Egy könyvet (entitás) több tanuló is kölcsönözhet.
    • Az Access-ben ezek a kapcsolatok a táblák közötti elsődleges kulcsok és idegen kulcsok révén valósíthatók meg.
  4. Az összefüggés megértése:

    • Az adatmodellek felépítése után egyértelművé válik, hogyan fog a rendszer működni. Például:
      • Az adatmodellek segítenek eldönteni, milyen adatokat kell rögzítened.
      • A táblákba csoportosítva tárolod az adatokat, így hatékonyabb lesz a keresés és lekérdezés.
      • A táblakapcsolatok biztosítják, hogy az adatok következetesek maradjanak, és az adatbázis redundanciamentes legyen.

Access szerkezeti felépítése

 

Menüszalag

menüszalag

Általános parancslapok: 


Kezdőlap: itt találhatóak a legtöbbet használt parancsok (nézet, vágólap, rendezés és szűrés, keresés...)
Létrehozás: itt találhatók azok a parancsok, melyekkel új adatbázis-objektumut tudunk az adatbázisban létrehozni (tábla, űrlap, jelentések ...)
Külső adatok: azon parancsok csoportjának lapja, melyekkel külső adatokat tudunk importálni, exportálni illetve frissíteni
Adatbáziseszközök: az adatbázis-objektumok közötti kapcsolatok megjelenítésére, elrejtésére, létrehozására valamint makrók futtatására szolgáló parancsokat tartalmaz

Gyorselérési eszköztár

gyorselérési eszköztár

Azok a parancsok vannak rajta, melyeket a leggyakrabban szokás használni, például: mentés, visszavonás, mégis. Bővíteni is lehet újabb gombokkal a mellette levő nyílra kattintva, de jobb egérgombbal el is távolíthatunk gomokat innen. 

Navigációs ablak

Oldalt a Minden Access-objektum alatt kategóriákat jelenít meg, azon belül csoportokra is bontja. A leggyakoribb objektumok: 
Tábla: sorokból és oszlopokból álló objektum, amely egymással kapcsolatban álló információkat tartalmaz
Lekérdezés: bizonyos feltételeknek eleget tevő adatok szűrésére vonatkozó keresés
Űrlap: adatok egyszerű bevitelére alkalmas ablak
Jelentés: az adatbázisban tárolt adatokról készített könnyen áttekinthető kimutatás

Állapotsor

A képernyő alján húzódó sáv az Állapotsor a dokumentuminformációkat és Office parancsokat jelenít meg. Itt is megtalálható a nézetválasztó gomb is. 

Nézetek

 

 

Adatlap nézet: az adatokat jeleníti meg a táblákban, űrlapokon, lekérdezésekben és jelentésekben. Ha az adatokat itt visszük be, akkor gépelés közben hozza létre a táblát. 

Tervező nézet: az objektumok megtervezéséhez jelenít meg beállítási lehetőséget és parancsokat.

 

Adatbázis létrehozásához fontos fogalmak

Elsődleges kulcs: azok a mezők, melyek egyértelműen azonosítják a tábla rekordjait, vagyis minden sor esetében egyedi. A relációs adatbázisban minden táblának rendelkeznie kell elsődleges kulccsal.
Tulajdonságai:
- minden sort egyedileg azonosít
- értéke nem lehet üres vagy null
- az értéke nem változik
Ha nem tudunk elsődleges kulcsot létrehozni, akkor egy számláló adatmezőt kell használni. Ezt az Access automatikusan létrehozza. 

Táblakapcsolatok: azért, hogy megszüntessük az adatok redundanciáját, az adatokat tematikus táblába kell osztani, hogy egy tény csak egyszer legyen rögzítve. Ehhez találni kell egy olyan mezőt, amelynek a használatával az egyik tábla rekordjait össze tudjuk kapcsolni a másik tábla rekordjaival. 
A közös mezőként használt mező a forrástáblán az elsődleges kulcs,  kapcsolt táblán az idegen kulcs

Táblakpcsolatok típusai: 
egy-egy: az első tábla minden rekordjához egyetlen rekord tartozik a másik táblán
egy-több: az első tábla rekordjaihoz több rekord is tartozhat a másik tábla rekordjai közül
több-több: az első tábla minden rekordjához több rekord tartozhat a másik tábla rekordjai közül és ez fordítva is igaz. 

Hivatkozási integritás:

- új rekord hozzáadása a kapcsolt táblához csak akkor lehetséges, ha a csatolás alapján megegyező rekord létezik az elsődleges táblán.
- az elsődleges tábla elsődleges kulcsát nem módosíthatjuk, ha létezik hozzá kapcsolt rekord a kapcsolt táblán
- az elsődleges tábláról nem törölhetünk olyan rekordot, amelyhez kapcsolódik rekord a másik táblán. 
Ha szükségünk van az elsődleges kulcs módosítására, akkor válasszuk  kapcsolt mezők kaszkádolt frissítését, ha pedig rekordot kell törölnünk, akkor a kapcsolt mezők kaszkádolt törlését. 

hivatkozási integritás

Táblakapcsolatok létrehozása: 
Adatbáziseszközök -> Kapcsolatok. Táblák beszúrása gombbal oldalt megjelennek az előhívott táblák, jelöld ki, mely táblák között szeretnél kapcsolatot kialakítani a kijelölt táblák hozzáadása gombbal. 
Húzd át az elsődlegeskulcs-mezőt az egyik tábláról a másik tábla közös mezőjére (idegen kulcs mezőre). Ha több mezőt szeretnél áthúzni, akkor tartsd lenyomva a CTRL billentyűt. 
Egy párbeszédpanel jelent meg, ezen szerkeszthetjük a kapcsolat tulajdonságait (hivatkozási integritás, illesztés típusa), majd nyomj a létrehozás gombra. A kapcsolat létrejött, ha egy vonal köti össze a két táblát. 
A kapcsolatot a kapcsolatok szerkesztése ablak Törlés gombjával lehet törölni.
Módosíthatjuk is,  vonalra kattintva elő lehet hívni a párbeszédpanelt hozzá, vagy a Kapcsolattervezés > Kapcsolatok szerkesztése gomb segítségével juthatunk el ugyanide, 

Relációs adatmodell

Relációs adatmodell

adatbázis

Relációs adatmodell

Adatbázis

Relációs adatmodell

Relációs adatmodell alapelemei

Relációk és attribútumok

  • Reláció (tábla): A reláció az adatok szervezésének két dimenziós megjelenítése, amely sorokból (rekordok) és oszlopokból (attribútumok) áll.

    • Példa: Filmek(filmcím, év, hossz, műfaj)

    Attribútumok: a reláció minden oszlopának egyedi neve van, például a filmcím az adott film címét reprezentálja.

  • Attribútum típusok:

    • Atomikus attribútumok: Egyszerű, nem bontható értékek. (Pl. film címe)
    • Kompozit attribútumok: Több elemből állhatnak (pl. cím attribútum, amely tartalmazza az utcát, várost, irányítószámot).
    • Többértékű attribútumok: Egy rekordhoz több érték tartozhat (pl. film több rendezővel rendelkezhet).
    • Származtatott attribútumok: Más attribútumokból számíthatóak ki (pl. film korát az év alapján).

Értéktartományok és séma

  • Az attribútumok értéktartománya meghatározza az adott oszlopban tárolható adat típusát (pl. év:integer, filmcím:string).
    integer: egész számokat tárol, ezek lehetnek pozitívak, negatívak, de nem tartalmazhat tizedesjegyeket
    String: karakterlánc. Ez lehet betű, számjegy, vagy speciális karakterek bármilyen kombinációja. Pl.: Csillagok háborúja
    Miért fontos ez?
    SQL lekérdezésben az integer tpusú oszlopokat könnyen össze leht hasonlítani (pl.: WHERE év > 2000)
    Megakadályozza, hogy hibás adatokat adjunk meg, nem lehet az integer mezőbe betűket írni
    Egyéb adattípusok:
    float - lebegőpontos szám - pl.: film értékelési pontszámához
    bolean: igaz/hamis értékek
    date: dátum típus 
  • Relációs séma: A reláció attribútumainak szerkezeti definíciója. (Pl. Filmek(filmcím:string, év:integer, hossz:integer, műfaj:string))

A relációs adatmodell tulajdonságai

  1. Egyediség: Minden relációnak egyedi neve van az adatbázis-sémán belül.
  2. Atomi értékek: Minden cella pontosan egy értéket tartalmaz, vagy üres (nem lehet lista vagy halmaz). Egy attribútum értékei ugyanabból a domain-ből származik
  3. Nem tartalmazhat két azonos sort
  4. Azonosítás: Minden egyes attribútum egyedi névvel rendelkezik 
  5. Tetszőleges sorrend: A rekordok és attribútumok sorrendje nem befolyásolja az adatok jelentését.
  6. NULL értékek: Hiányzó adatok reprezentálása.

A relációs adatbázis felépítése

  1. Adatbázis: összekapcsolt relációk (táblák) halmaza
    2. Reláció: kétdimenziós táblázat, amely oszlopokból és sorokból áll. Minden táblázat egyedi névvel rendelkezik
    3. Rekord: egy sor a táblázatban, amely az egymással kapcsolatban levő adatokat jelenti
    4. Attribútum: egy oszlop a táblázatban, amelyre a nevével hivatkozhatunk (oszlop fejléce)
    5. Elsődleges kulcs: olyan attribútum, amely a relációban (táblában) tárolt rekordokat (sorok) egyértelműen azonosítja. Aláhúzással jelöljük, pl.: TAJ szám
    6. Idegen kulcs: ezen keresztül hivatkozhatunk egy másik tábla valamely rekordjára.

    Egyéb fogalmak:
    Domain: az attribútum által felvehető értékek halmaza
    Fokszám: az attribútumok száma
    Kardinalitás: a rekordok száma (új rekordok beszúrásával, vagy törlésével változik)

Reláció és Descartes-szorzat kapcsolata

A relációs modell matematikai alapjait a reláció és a Descartes-szorzat fogalma adja.

Descartes-szorzat magyarázata

A Descartes-szorzat, más néven direkt szorzat, két halmaz összes lehetséges kombinációját tartalmazza. Ha adott két halmaz:
D1 = {1, 3, 5}
D2 = {2, 4}
Akkor a Descartes-szorzatuk: D1xD2={(1,2), (1,4), (3,2), (3,4), (5,2), (5,4)}
Ez a szorzat a relációs modell alapját képezi, mivel minden reláció egy ilyen Descartes szorzat részhalmaza. Tehát minden elempár az egyik halmaz egy eleméből és a másik halmaz egy eleméből áll. 

Reláció a Descartes-szorzaton belül

Egy reláció úgy definiálható, mint a Descartes-szorzat egy részhalmaza. Például, ha csak azokat az elemeket akarjuk megadni, ahol az első elem nagyobb, mint a második, akkor a fenti szorzatból egy relációt képezhetünk:
r= {(3,2), (5,2), (5,4)}
Ez a reláció tartalmazza az összes olyan rendezett párt, amely megfelel az adott feltételnek. 

Adottak a következő halmazok (domainek): D1, D2, ..., Dn
A Descartes-szorzat ezeknek a halmazoknak az összes lehetséges kombinációját tartalmazza: D1xD2x ... xDn
A reláció (r) a Descartes-szorzat egy részhalmaza: r ⊆ D1xD2x ... xDn
A reláció n-elemű sorok halmaza (a1, a2, ..., an) ahol
                                                    ai​∈Di​
Egyszerűsítve:
- a Descartes-szorzat minden lehetséges kombinációt tartalmaz
- egy reláció ezek közül csak azokat az elemeket választja ki, amelyek megfelelnek bizonyos feltételeknek. 

Relációs séma

A relációs séma meghatározza, hogy milyen típusú adatokat tárolunk egy relációban. A séma megadja:

  1. A reláció nevét.
  2. Az attribútumok listáját (az oszlopok nevét).

Példa

Egy reláció neve lehet „Személy”, amely három attribútumot tartalmaz:

  • Szigetszám (pl. azonosító szám),
  • Név (pl. egy személy neve),
  • Születési_dátum (pl. egy személy születési dátuma).

A relációs séma jelölése:
R(A1, A2, ..., An)
Konkrétan: Személy(SzigSzám, Név, Születési dátum)
Ez azt jelenti, hogy a Személy reláció egy olyan táblázat, amely minden személyről a fent felsorolt adatokat tartalmazza.

Egy adatbázisban több reláció található, amelyek mind különböző típusú adatokat tárolnak. Az adatbázis sémája ezeknek a relációknak az összessége.

Példa

Egy cég adatbázisa tartalmazhat több relációt:

  1. Dolgozók(DolgozóID, Név, Osztály) - a cég alkalmazottainak adatai.
  2. Osztályok(OsztályID, OsztályNév) - a cég osztályai.
  3. Projektek(ProjektID, ProjektNév, Határidő) - a cég projektjei.

Az adatbázis-séma ezeknek a relációknak a halmaza.

 

A relációs modell műveletei

A relációs algebra segítségével végezhető műveletek:

  • Lekérdezések (SELECT): Adatok szűrése és megjelenítése meghatározott feltételek alapján.
  • Módosítások: Új rekordok beszúrása (INSERT), meglévő adatok frissítése (UPDATE), rekordok törlése (DELETE).

Gyakorlás: Relációs adatmodell

Egyed-kapcsolat modell

Egyed-kapcsolat modell

adatbázis

Egyed-kapcsolat modell

Adatbázis

Egyed-kapcsolat modell

E/K vagy ER modell

az adatok grafikus ábrázolását teszi lehetővé egyértelmű struktúrák segítségével. A cél az, hogy az adatbázisban tárolt információkat jól definiált formában írjuk le, beleértve az egyedeket (entitásokat), azok tulajdonságait (attribútumokat) és az egyedek közötti kapcsolatokat.

E/K vagy ER modell elemei és tulajdonságai

1. Egyedhalmazok (entitások)

  • Az egyedhalmazok olyan absztrakt objektumok, amelyek egy adott típusú adatot képviselnek a valós világban.
  • Egy egyedhalmaz tartalmazza az adott típusú egyedek összes előfordulását.
    Példák: a diákok egy iskolai adatbázisban, ahol minden diák egy egyed.
    Autók egy járműnyilvántartási adatbázisban, ahol minden autó egy egyed.

    Minden egyednek egyedi azonosítója van, amely biztosítja az egyértelműséget az adatbázisban. Ez lehet egy egyszerű attribútum (pl. diák azonosító) vagy egy összetett attribútum (pl. név és születési dátum kombinációja).

2. Attribútumok

Az attribútumok további tulajdonságokkal is bővíthetők, például:

  • Atomikus/egyszerű attribútumok:

    • Olyan egyszerű értékeket tartalmaznak, amelyeket tovább nem lehet bontani.
    • Példa: Egy diák neve.
    • Jelölése: egy kör
  • Kompozit/összetett attribútumok:

    • Több elemből állnak, például egy cím attribútum, amely tartalmazza az utcát, várost és irányítószámot.
  • Többértékű attribútumok:

    • Egy egyedhez több érték is tartozhat.
    • Példa: Egy személy több telefonszáma.
  • Származtatott attribútumok:

    • Más attribútumok alapján számíthatók ki.
    • Példa: Az életkor kiszámítása a születési dátumból.
attribútumok jelölése
Attribútum korlátozások:
  • Domainek: Meghatározzák az attribútumok lehetséges értékeit.
    Példa: Egy „kor” attribútum csak pozitív egész szám lehet.

 3. Kapcsolatok

A kapcsolatok az egyedek közötti viszonyokat írják le.

Kapcsolatok attribútumai:
  • A kapcsolatok is rendelkezhetnek attribútumokkal, például egy „Dolgozik” kapcsolatban a munkavállaló és a munkaadó közötti szerződés kezdési dátuma.
Kapcsolatok fajtái:

Binaritás:
Két egyedhalmaz között jön létre.
Példa: Egy diák egy adott tanfolyamra iratkozik be.

Ternaritás:
Három egyedhalmaz között jön létre.
Példa: Egy ügyfél több bankfiókban különböző számlákkal rendelkezhet.

Sokágú kapcsolatok:
Több egyedhalmaz között jön létre, ahol egy kapcsolat több szereplőt foglal magában.
Példa: Egy filmhez tartozik egy rendező, egy stúdió és több színész.

Kapcsolatok kardinalitása:

A kapcsolatokban meghatározzuk, hogy az egyedek milyen mértékben vesznek részt a kapcsolatban.

  • 1:1 kapcsolat: Egy diákhoz egy bizonyos TAJ-szám tartozik.
  • 1:N kapcsolat: Egy tanár több hallgatót taníthat.
  • N:M kapcsolat: Egy hallgató több tanfolyamot vehet fel, és egy tanfolyamon több hallgató is részt vehet.

Előfordulás / egyed:

az egyedtípus egy konkrét értéke, pl.: Példa Péter

Az E/K diagramok kiterjesztései

1. Gyenge egyedhalmazok

  • Azokat az egyedhalmazokat nevezzük gyengének, amelyek nem rendelkeznek önálló azonosítóval, ezért más egyedhalmazhoz kapcsolódva azonosíthatók.
  • Példa: Egy munkavállaló gyermekei, ahol a gyermekek a szülő azonosítójával együtt azonosíthatók.

2. Generalizáció és Specializáció

  • Generalizáció: Több egyedhalmaz közös tulajdonságainak összevonása egy általánosabb kategóriába.
    Példa: „Szállítójármű” lehet a „Teherautó” és a „Személygépkocsi” általánosítása.
  • Specializáció: Egy általános egyedhalmaz specifikusabb részhalmazokra bontása.
    Példa: Egy „Jármű” lehet „Motorbicikli” vagy „Autó”.

Az E/K Modell Előnyei

Egyszerűség:
Az E/K modell intuitív, könnyen érthető mind a tervezők, mind a végfelhasználók számára.
Rugalmasság:
Alkalmazható bármilyen környezetben, például vállalati rendszerek, oktatási adatbázisok, könyvtári katalógusok.
Struktúra:
Segít a valós világ adatelemeinek pontos leképezésében és kapcsolataik meghatározásában.
Implementációs alap:
Az E/K diagramok könnyen leképezhetők relációs adatbázisokká.

Tervezési Alapelvek az E/K Modellnél

1. Valósághű modellezés

A modellnek tükröznie kell a valós világ szerkezetét. Például:

  • Egy „Film” attribútumai között ne szerepeljen egy színész neve, hanem kapcsolattal kell összekötni a két egyedhalmazt.

2. Redundancia elkerülése

A redundancia anomáliákhoz vezethet:

  • Törlési anomália: Ha egy színész adatait töröljük, elveszíthetjük a hozzá kapcsolódó filmeket is.
  • Módosítási anomália: Egy adat több helyen történő módosítása hibákhoz vezethet.

3. Egyszerűség

Az adatbázis-tervezés során ne használjunk több elemet, mint amennyi feltétlenül szükséges.

4. Megfelelő kapcsolatok kiválasztása

Fontos, hogy a kapcsolatok valóban tükrözzék a valós világ viszonyait.
Példa: Egy színész és egy stúdió közötti kapcsolat csak akkor releváns, ha az közvetlen munkakapcsolatot jelent.

Link tanuláshoz: ER-modell

 

Adatmodellek

Adatmodellek

adatbázis

Adatmodellek

Adatbázis

Adatmodellek

Adatmodell

Az adatmodell alapvető szerepet játszik az adatok kezelésében, tárolásában és megértésében. Lényegében egy olyan keretrendszer, amely a valóság elemeit, azok közötti kapcsolatokat és az adatok jelentését írja le. Az adatmodellezés célja a rendszerek hatékony tervezése, amely átláthatóvá és kezelhetővé teszi az adatokat mind az informatikai szakemberek, mind a végfelhasználók számára.
Fő funkciói:

  • Az adat struktúrájának meghatározása: Leírja, hogy az adatok milyen szerkezetben tárolódnak (pl. táblák, objektumok, gráfok).
  • Kapcsolatok feltárása: Meghatározza az entitások (egyedek) közötti kapcsolatokat.
  • Szemantikai jelentés hozzáadása: Megmagyarázza az adatok értelmét és szerepét a valós világban.
  • Korlátozások bevezetése: Szabályokat határoz meg az adatok érvényességének biztosítására (pl. kulcsok, függőségek).

Az adatmodellek használata elengedhetetlen a modern informatikai rendszerekben, különösen az adatbázisok tervezésében és működtetésében. Az adatmodell a valós világ elemeit egyszerűsíti le egy strukturált, kezelhető formába, amelyet később implementációs szinten is alkalmazhatunk.

Az Adatmodellek Főbb Típusai

Az adatmodelleket többféle módon osztályozhatjuk, attól függően, hogy milyen szinten írják le az adatokat.

1. Strukturált Adatmodellek

Ezek az adatmodellek pontosan meghatározzák az adatok szerkezetét és a kapcsolataikat.

      • Koncepcionális (magas szintű) modell:

        • Az implementáció részleteitől független.
        • Közérthető, a valós világ fogalmaira épül.
        • Példa: Egy könyvtári rendszerben a „Könyv”, „Olvasó”, és „Kölcsönzés” entitások és azok kapcsolatai jelennek meg.
      • Logikai (implementációs) modell:

        • Az adatbázis logikai szerkezetét írja le, például relációs vagy objektum-orientált modellek segítségével.
        • Példa: Egy relációs modellben táblák ábrázolják a könyveket ISBN szerint, kapcsolva a kölcsönzési adatokhoz.
      • Fizikai (alacsony szintű) modell:

        • Az adatok tényleges tárolási módját határozza meg, pl.: adattípusok, indexek. Informatikai szakemberek számára készült. 
          Példa: indexek használata az adatok gyors kereséséhez.

2. Félig strukturált adatmodellek

  • Az adatok nem merev szerkezetben vannak, de van némi strukturális mintázatuk.
  • Példák: XML, JSON. Ezek lehetővé teszik, hogy az adatok hierarchikusan vagy kulcs-érték párok formájában legyenek tárolva.

3. Nem strukturált adatmodellek

  • Az adatoknak nincs meghatározott szerkezete.
  • Példa: Szöveges dokumentumok, képek.

Az Adatmodellezés főbb fogalmai

1. Entitások és attribútumok

  • Entitás: A valós világban létező dolgok modellje.
    • Példa: Egy hallgató vagy egy könyv.
  • Attribútum: Az entitás tulajdonságai:
  • Egyszerű attribútumok: Tovább nem bonthatók.
  • Összetett attribútumok: Több részből állnak (pl. cím: utca, házszám, város).
  • Egyértékű attribútumok: Egyetlen értéket vesznek fel.
  • Többértékű attribútumok: Több értéket is felvehetnek, például egy személynek több telefonszáma lehet​

2. Kapcsolatok

  • Az entitások közötti viszonyok meghatározása.
    • Példa: Egy „Hallgató” „Kölcsönöz” egy „Könyvet”.
    • 1:1 kapcsolat: Egy személyhez egy TAJ-szám tartozik.
    • 1:N kapcsolat: Egy tanár több hallgatót taníthat.
    • N:M kapcsolat: Egy hallgató több kurzusra járhat, és egy kurzusnak több hallgatója lehet​

3. Kardinalitás

  • Azt mutatja meg, hogy hány entitás kapcsolódhat egy másik entitáshoz.
    • Maximális kardinalitás: Egy kapcsolat felső határa (pl. egy kurzusnak legfeljebb 50 hallgatója lehet).
    • Minimális kardinalitás: Egy kapcsolat alsó határa (pl. minden kurzushoz legalább egy tanár tartozik).

Az adatmodellezés folyamata

  1. Koncepcionális modellezés: A valós világ entitásainak és kapcsolataiknak meghatározása.
  2. Logikai modellezés: Az entitások relációkká és attribútumokká alakítása.
  3. Fizikai tervezés: Az adatok tárolásának részleteinek kidolgozása (pl. tárolási struktúra, indexek).

Az adatmodellezés gyakorlati jelentősége

Az adatmodellezés révén az adatok:

  1. Érthetőbbek lesznek: Mindenki számára, aki az adatokat használja.
  2. Könnyen kezelhetők: Az adatstruktúrák tervezésének köszönhetően.
  3. Továbbfejleszthetők: A koncepcionális modellek könnyen implementációs modellekké alakíthatók.
  4. Skálázhatók: Az adatbázisok bővítése és optimalizálása egyszerűbb.
    Az adatmodellek megértése és alkalmazása elengedhetetlen az informatikai rendszerek tervezésében és működtetésében. Legyen szó egy egyszerű adatbázisról vagy egy összetett vállalati rendszerről, az adatmodellezés biztosítja, hogy az információk szervezetten és hatékonyan álljanak rendelkezésre.

    Tanuláshoz link: https://quizlet.com/hu/988327826/adatmodellek-flash-cards/?i=69qf1l&x=1jqt