5.EA_Gondolatterkep

Honelako gehiago

PORTFÓLIÓ TERV

by Judit Kaali

DML utasítások és tranzakciókezelés

by Zsófia Szombati

A jövő tervezése

by Csőke Jázmin

Kényszerek

by Petra Páncsity

Atomi attribútum

Azokat az attribútumokat, amelyeket nem bontunk részekre, egyszerű vagy atomi attribútumoknak nevezzük.

• Forrás: http://www.tankonyvtar.hu/hu/tartalom/tamop425/0046_fejezetek_az_adatbazisrendszerek_elmeletebol/ch03s03.html

Indexek

"An index is an optional structure, associated with a table or table cluster, that can sometimes speed data access." - Az index egy szerkezet, amely kapcsolatba hozható táblákkal vagy táblacsoportokkal, ezáltal felgyorsítva az adatokhoz való hozzáférést.

Forrás: https://docs.oracle.com/cd/E11882_01/server.112/e40540/indexiot.htm#CNCPT721

"A relációkban tárolt információk visszakeresését az indexek nagymértékben meggyorsíthatják, így a tervezés során nagy hangsúlyt kell fektetni a helyes indexek kiválasztására, szem előtt tartva azt is, hogy az indexek számának növelésével az adatok beviteléhez illetve módosításához szükséges idő megnövekszik az indexek frissítése miatt. A relációkhoz kapcsolt indexek segítségével az index kulcs ismeretében közvetlenül megkaphatjuk a kulcsot tartalmazó sor fizikai helyét az adatbázisban. Az indexek képzésére két módszer terjedt el, a hash kódok és a bináris fák."

Forrás: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.6.1

Redundancia

A logikai adatbázis tervezés egyik fő célja a redundanciák megszüntetése. Redundanciáról akkor beszélünk, ha valamely tényt vagy a többi adatból levezethető mennyiséget ismételten (többszörösen) tároljuk az adatbázisban. A redundancia, a szükségtelen tároló terület lefoglalása mellett, komplikált adatbázis frissítési és karbantartási műveletekhez vezet, melyek könnyen az adatbázis inkonzisztenciáját okozhatják. Egy adatbázis akkor inkonzisztens, ha egymásnak ellentmondó tényeket tartalmaz. Megjegyezzük, hogy a fizikai tervezés során az adatbázis műveletek gyorsítása érdekében esetleg redundáns attribútumokat is bevezetünk.

A redundancia egyik fajtája amikor ugyanazt a tényt többször tároljuk.

Forrás: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.4

Elemző/Tervező

• Megrendelnek tőle egy „testreszabott” (nem dobozos) informatikai rendszert – illetve annak a megtervezését.
• Elemzőként megérti az illető szakterület üzleti szabályait (pl. sok-sok interjún és beszélgetésen keresztül).
• Megállapítja, hogy adatbázis-centrikus a rendszer.
• Kiválasztja azt, hogy milyen fogalmakról milyen tényeket kell tárolnunk az adatbázisban.
• Megalkotja az adatmodellt. A folyamat végén CREATE TABLE utasítások születnek (kényszerek is).
• Ez egy hosszú, gyakran sok hónapos tervezői munka.
• Néha többen – csapatban - végzik.
• Ha ezt rosszul csináljuk, vagy nem csináljuk, akkor rendszerint kevésbé hasznos, rövid életű szoftverek keletkeznek (manapság ez gyakori hiba).

Forrás: Előadás diasor

Rendundáns

Rendundáns

• új információt nem tartalmazó;
• párhuzamos, egymást helyettesítő

Forrás: http://idegen-szavak.hu/redund%C3%A1ns

Normálformák

Ahhoz, hogy elkerülhessük az anomáliákat, a relációink sémái meghatározott feltételeket kell, hogy teljesítsenek.

• Ezeket normálformáknak nevezzük.
• Létezik elég sok normálforma: ezek közül a legfontosabbak az 1NF, 2NF, 3NF, BCNF (Boyce-Codd normálforma)

Forrás: Előadás diasor

BCNF

Boyce/Codd normál forma (BCNF)

A normál formák tárgyalása során eddig olyan relációkra mutattunk példákat, melyeknek csak egy reláció kulcsa van. A normál formák definíciója természetesen alkalmazható a több kulccsal rendelkező relációkra is. Ebben az esetben minden attribútum, mely valamely kulcsnak a része, elsődleges attribútum, de ez az attribútum függhet egy másik, ezt nem tartalmazó kulcs részétől. Ha ez a helyzet fennáll, redundanciát tartalmaz a reláció. Ennek a felismerése vezetett a harmadik normál forma egy szigorúbb definíciójához, a Boyce/Codd normál formához.

• A reláció harmadik normál formában van.
• Minden elsődleges attribútum teljes funkcionális függőségben van azokkal a kulcsokkal, melyeknek nem része.

Forrás: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.5.4

3NF

Harmadik normálforma (3NF)



• Egy 1NF relációs séma 3NF alakú, ha egyetlen másodlagos attribútuma sem függ tranzitívan egyetlen kulcstól sem.
• Ami nem 3NF alakú, abban rejtett függőségek vannak, és ezeket meg kell bontani több sémára.

Forrás: Előadás diasor

A második normál formájú relációkban nem lehetnek olyan tények, amelyek a reláció kulcs részeihez kapcsolódnak. Azonban ennek ellenére is lehet bennük redundancia, ha olyan tényeket tartalmaznak, amelyek a nem elsődleges attribútumokkal állnak kapcsolatban. Ezt a lehetőséget szünteti meg a harmadik normál forma. Egy reláció harmadik normál formában van, ha:

• A reláció második normál formában van.
• A reláció nem tartalmaz funkcionális függőséget a nem elsődleges attribútumok között.

Forrás: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.5.3

2NF

Második normálforma (2NF)



• Elsődleges attribútum az, amely valamelyik kulcs része.
• Másodlagos attribútum az, amely nem elsődleges, tehát olyan attribútum, amely nem része egyik kulcsnak sem.
• Egy 1NF relációs séma 2NF alakú, ha egyik másodlagos attribútuma sem függ a kulcs egy részhalmazától, hanem kizárólag a teljes kulcstól függ.

Forrás: Előadás diasor

Az első normál forma nem elegendő feltétel a redundanciák megszüntetésére. Egy reláció második normál alakjában nem tartalmazhat tényeket a reláció kulcs egy részére vonatkozóan. A második normál forma definíciója két feltétellel írható le:

• A reláció első normál formában van
• A reláció minden nem elsődleges attribútuma teljes funkcionális függőségben van az összes reláció kulccsal

Forrás: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.5.2

1NF

Első normálforma (1NF)



• Egy relációs séma 1NF alakú (1NF normalizált) ha benne csak atomi attribútum-értékek szerepelnek.
• Köznyelven mondva: a tábla sorai és oszlopai „metszetében” lévő „mezők” csak 1 értéket tárolnak.
• Érdekesség, hogy az Oracle adatbáziskezelő rendszer az objektumorientáltság kedvéért megengedi ennek az alapszabálynak a megszegését is akár

Forrás: Előadás diasor

"Egy reláció első normál formában van, ha minden attribútuma egyszerű, nem összetett adat. A könyvben eddig szereplő valamennyi reláció kielégíti az első normál forma feltételét."

Forrás: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.5.1

Database Design

Az adatbázis logikai tervezése (Database Design)

Az adatbázis a "világ egy darabjának" egy leegyszerűsített képét képes visszaadni (lásd "Gajdos Sándor: Adatbázisok")

Forrás: Előadás diasor

"Az adatbázistervezés egy folyamat, mely több lépésből tevődik össze. Először az adatbázisban leképezendő rendszert elemzésnek vetjük alá és meghatározzuk a tárolandó adatok körét, azok egymás közötti kapcsolatait és az adatbázissal szemben felmerülő igényeket (fogalmi séma - Conceptual schema). Ezután következik a rendszer tervezés, melynek eredménye az adatbázis logikai modellje. Végül fizikai szinten képezzük le a logikai adatbázis modellt az alkalmazott szoftver és hardver függvényében."

Forrás: http://www.agt.bme.hu/szakm/adatb/db3.htm

Anomáliák

Ha egy relációban valamely attribútum értékét a relációban található más attribútom(ok) értékéből ki lehet következtetni, akkor a relációt redundánsnak nevezzük.

A redundáns adatok tárolásakor egy sor kellemetlen jelenség állhat elő. Ezeket anomáliáknak nevezzük.

Forrás: Előadás diasor

"Az anomália az adatbázisban olyan rendellenesség, mely valamely karbantartási műveletnél plusz műveletek beiktatását igényli, ezzel felesleges redundanciát okozva."

Forrás: http://tudasbazis.sulinet.hu/hu/informatika/informatika/informatika-9-12-evfolyam/kapcsolatok-tablak-kozott/anomaliak

Törlési anomália

• Ha csak egy attribútum értékét szeretnénk törölni, akkor előfordulhat, hogy ez nem lehetséges (pl. mivel része valamely kulcsnak)
• Ilyenkor az egész sort törölhetjük, de akkor meg más információt (adatot) is elveszíthetünk.

Forrás: Előadás diasor

"Amennyiben egy adat törlésével

másik, hozzá logikailag nem kapcsolódó adatcsoportot is elveszítünk, törlési anomáliáról beszélünk."

Forrás: http://tudasbazis.sulinet.hu/hu/informatika/informatika/informatika-9-12-evfolyam/kapcsolatok-tablak-kozott/anomaliak

Beszúrási anomália

• Nem tudunk egy új adatot nyilvántartásba venni, ha nem ismert egy másik adat.
• Nem tudunk felvenni egy újabb sort, ha az egyik attribútuma nem lehet NULL érték, de nem áll rendelkezésünkre, az az attribútum.

Forrás: Előadás diasor

Az előző példánál maradva (http://i.imgur.com/HDdnLFq.png) nem tudunk újabb sort felvenni, ha pl. a Pozíció oszlopban a NULL érték nem megengedett, de az új sor esetében nem áll rendelkezésünkre az az attribútum.

"Beszúrási anomáliáról beszélünk abban az esetben, amikor egy adatrekord beszúrása egy másik, hozzá logikailag nem kapcsolódó adatcsoport beszúrását kívánja meg."

Forrás: http://tudasbazis.sulinet.hu/hu/informatika/informatika/informatika-9-12-evfolyam/kapcsolatok-tablak-kozott/anomaliak

Módosítási anomália

http://i.imgur.com/HDdnLFq.png

Ha a fenti linken látható táblázat második sorában az Ország oszlop értékét megváltoztatjuk Magyarországra, akkor a második és negyedik sor egymásnak ellent fog mondani.

"Abban az esetben, ha egy relációban egy adat módosítása több helyen történő módosítást igényel, akkor módosítási anomáliáról beszélünk."

Forrás: http://tudasbazis.sulinet.hu/hu/informatika/informatika/informatika-9-12-evfolyam/kapcsolatok-tablak-kozott/anomaliak

Fizikai adatbázis

Az adatbázis fizikai szerkezete

• A mai üzleti gyakorlatban leginkább relációs szerkezetű.
• Leginkább a számítógép lemezein elhelyezett fájlok.
• Ha relációs, akkor a fájlokban táblák, indexek, nézetek és egyéb fogalmak sokasága tárolódik.
• Egy komplex szoftver – az adatbáziskezelő rendszer (pl. az Oracle RDBMS) működése révén férnek hozzá a felhasználók az adatbázisban tárolt adatokhoz.
• A fizikai adatbázist az adatbázis rendszergazdája (DBA) hozza létre és működteti - adminisztrálja. A DBA leginkább egy mérnök, aki „üzemeltet”.

Forrás: Előadás diasor

"A relációs adatbázisok esetében a logikai tervezés során a relációk már elnyerhetik végleges alakjukat, melyeket egyszerűen leképezhetünk az adatbázis-kezelőben. A fizikai tervezés során inkább arra koncentrálunk, hogy a logikai szerkezet mennyire felel meg a hatékony végrehajtás feltételeinek, illetve milyen indexeket rendeljünk az egyes relációkhoz. A relációkon végrehajtott művelet együttest tranzakciónak nevezzük és általában a tranzakciók gyors végrehajtását kívánjuk elérni.

A fizikai tervezés során előfordulhat, hogy a relációkba szándékosan redundanciákat építünk a hatékonyabb tranzakció kezelés érdekében. Ez visszalépésnek tűnhet a logikai tervezés során követett következetes redundancia megszüntető tevékenységünkhöz képest. A lényeges különbség viszont az, hogy itt a redundancia ellenőrzött módon kerül be a relációba, nem csak véletlenül maradt ott a hiányos tervezés miatt. Gyakran előfordul például az, hogy a sűrűn együtt szükséges adatokat egy relációban tároljuk a lehető leggyorsabb visszakeresés érdekében."

Forrás: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.6

Adatbázis típusok

Hálós

• 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. 1971-ben az adatrendszer nyelvek konferenciáján (CODASYL) definiálták.

• 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.

Forrás: http://www.agt.bme.hu/szakm/adatb/db1.htm#p1.4.2

Ábra: http://i.imgur.com/sRlpw31.png (Forrás: Előadás diasor)

Relációs

A relációs az egyik legáttekinhetőbb és a 80-as évektől kezdve a legelterjedtebb adatmodell. Kidolgozása E. F. Codd (1923-2003) nevéhez fűződik, 1970-ben jelent meg alapvető műve a ""A Relational Model Data Large Shared Data Banks". A relációs modellben az adatokat táblázatok soraiban képezzük le. A legfontosabb eltérés a Hierarchikus- és Hálós modellhez képest az, hogy itt nincsenek előre definiált kapcsolatok az egyes adategységek között, hanem a kapcsolatok létrehozásához szükséges adatokat tároljuk többszörösen. Ezzel egy sokkal rugalmasabb és általánosabb szerkezetet kapunk.

Forrás: http://www.agt.bme.hu/szakm/adatb/db1.htm#p1.4.3

Ábra: http://i.imgur.com/r5h6t0g.png (Forrás: Előadás diasor)

Hierarchikus

• A hierarchikus modell volt a legelső az adatbáziskezelőkben és egyben a leginkább korlátozott. A hierarchikus modell az 1960-s évek végén alakult ki és az 1970.s évek végéig használták. Például az IBM IMS adatbáziskezelő rendszer alkalmazta ezt a modellt. A neve is utal rá, hogy az adatokat egy hierarchiában kell elrendezni. Ezt egy fa szerkezettel tehetjük szemléletessé.

• 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. 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.

Forrás: http://www.agt.bme.hu/szakm/adatb/db1.htm#p1.4.1

Ábra: http://i.imgur.com/qvBiGxT.png (Forrás: Előadás diasor)

E-R

Egyed-Kapcsolat (Entity-Relationship, E-R)

• "Az elemző/tervező választja ki mind az egyedeket, mind az egyedek tulajdonságait."
• Új entitást „költséges” utólag bevezetni, új attribútumot általában jóval könnyebb.

Forrás: Előadás diasor

Ábrázolási konvenciók: https://docs.oracle.com/cd/A87860_01/doc/java.817/a81358/05_dev1.htm

Relationship

Kapcsolat („Relationship”): entitások névvel ellátott viszonya.

• Az egyedek ritkán léteznek elszigetelten. Tipikus az, hogy kapcsolatban állnak egymással.

• Pl. Emberek cégeknél dolgoznak. Itt a dolgoznak a kapcsolat az ember és a cég az entitások.
• Pl. a házasság a reláció egy ember és egy másik ember között.
• Pl. a tanár „tanit”-ja a diákot. Itt a „tanít” a reláció.

A kapcsolatokat a következőkkel jellemezzük:

• a kapcsolat neve
• a kapcsolat foka: 1:N, M:N, 1:1
• a kapcsolat típusa lehet kötelező vagy opcionális

Forrás: Előadás diasor

Entity

Egyed („Entity”): a valós világban létező, logikai vagy fizikai szempontból saját léttel rendelkező dolog, amelyről adatokat tárolunk.

• A rendszer szempontjából jelentős objektum (valós, vagy képzeletbeli).
• Az egyed neve szerepel a diagramon a dobozban nagy betűkkel.
• Nem adatbázistáblák láthatók ezen a szinten, hanem a valós fogalmak!

Forrás: Előadás diasor

Tulajdonság

Tulajdonság (attribútum, „Attribute”): az entitás néhány kiválasztott jellemzője, ami az entitásokat jellemzi. Ez, vagy ezek segítségével különböztetjük meg az entitásokat.

Az egyedek tulajdonságai vagy jellemzői, amelyekkel azonosítjuk, leírjuk, minősítjük, osztályozzuk vagy állapotát fejezzük ki az egyednek.

Forrás: Előadás diasor

Logikai adatbázis

Az adatbázis fogalmi szerkezete

• A valós (vagy ritkábban a „kitalált”) világ adatait tárolja.
• Az adatok részhalmazát tartjuk csupán tárolásra „alkalmasnak”.
• Az adatoknak csak egy szűk körét tárolhatjuk.
• Azért tároljuk őket, hogy később ebből információt nyerhessünk (mert könnyebb onnan, mint a valóságból megszerezni ugyanazt az információt).
• A tárolandó adatok kiválasztása klasszikus elemzési és modellezési feladat.
• Ez a logikai adatbázis tervezés (Logical Database Design).
• Aki ezt végzi, azt „elemző/tervezőnek”, adatmodellezőnek is nevezzük.

Forrás: Előadás diasor



"A logikai tervezés célja egy redundancia mentes reláció rendszer, relációs adatbázis."

Forrás: http://www.agt.bme.hu/szakm/adatb/db3.htm#p3.5