Adatbziskezels 2 3 Elads Dr Pauler Gbor egyetemi
Adatbáziskezelés 2 3. Előadás Dr. Pauler Gábor, egyetemi docens PTE-TTK BRTT, 7624 Pécs, Ifjúság u. 6. F 104 Mobil: 30/9015 -488, Skype: gjpauler E-mail: pauler@t-online. hu Facebook: Pécs Gazdinfo Adatbázis http: //www. facebook. com/groups/278606362188127/ ftp: //gamma. ttk. pte. hu/pub/pauler/Database 2/
Az előadás tartalma Relációs adatbáziskezelők Normalizációs folyamat 2. Normálforma: Relációk Elsődleges kulcsok kiválasztása 1: több relációk tárolása Több: több relációk tárolása Egyedkapcsolati diagramm (ERD) Relációk ERD-n 1: több Kapcsolat ábrázolása 1: több Hibalehetőségek: Idegen kulcs elfelejtése, Oldalcsere Több: több Kapcsolat ábrázolása Több: több Hibalehetőségek: Relációs tábla kifelejtése, Csirkelábak megfordítása A minimális számosságú csatolás szabálya 3. Normálforma: Rejtett függések kibontása Hasznossága Kinézegető táblák A normalizált tárolási szerkezet és a GUI szerkezete közti különbség Elrettentő népmese
Relációs adatbáziskezelés: Normalizáció: 2. Normálforma: Elsődleges kulcsok 2. Normálforma: a gyakorlati adatstruktúrák adattartamának megőrzése miatt a szétbontott egyedeket/táblákat össze kell kötni relációkkal (Relations). Ehhez először Elsődleges kulcsmezőt (Primary Key, PK) adunk minden egyedhez, mely: Egyedileg azonosítja (Unique ID) az előfordulásokat, nem lehetnek benne ismétlődő értékek, nem tartalmazhat NULLt. Mindig mesterséges kulcs (Artificial Key) mező: Numerikus (Numeric): 10× gyorsabban működik, mint szöveges kulcsok Auto-számozott (Auto-Numbered): a felhasználó ne tudja összekutyulni az értékeit Ha az egyednek van természetes azonosítója (Natural Key), azt egyszerű adatmezőként tároljuk a mesterséges elsődleges kulcs mellett: (pl. a Számlának van természetes egyedi azonosítója, a Számla. Szám, mégis egy mesterséges Számla. ID-t használunk elsődleges kulcsnak) Miért? Mert különben a természetes azonosítóban bekövetkező bármely hiba (pl. két hajléktalannak azonos a személyi igazolvány száma) vagy változás (pl. magyar számlaszámokról EU-kompatibilisra átállás) bedöntené az adatbázist Az elsődleges kulcs neve mindig legyen Egyed. Logikai. Név+ID Ez azért fontos, mert ha minden táblában egyszerűen „Kód”-nak hívnánk az elsődleges kulcsot, amikor majd más táblákban meghivatkozzuk őket, a sok azonos mezőnév ott ütközne egymással, és könnyen összekeverhetők lennének Mivel az egyedek logikai neve egyedi az adatbázisban, a belőlük képzett elsődleges kulcs nevek soha nem keveredhetnek össze! Az elsődleges kulcsot mindig narancs színnel jelöljük
Relációs adatbáziskezelés: Normalizáció: 2. Normálforma: Relációk: 1: több 1: 1 reláció tárolódása adatbázisban: Ilyen normalizált adatbázisban nincs, mert az 1: 1 kapcsolódó mezők egyedbe kerülnek az egyed-tulajdonság szabály alapján! 1: több reláció tárolódása adatbázisban: pl. 1 Eladóhoz több Számla tartozhat, de 1 Számlához 1 Eladó tartozik. Számlák Számla. I Számla. Sz D ám 1 CZ 184788 Kibocs. Dát Fizetv ÖsszÉ EladóI um e rt D 2004. 03. 29 Igen 11400 1 41250 2 CZ 184789 2004. 01 Igen 0 1 Eladók EladóI D Név Adószám Magyar Szőnyeg 12549499 -02 1 Kft. -2 Giga Szőnyeg 33821244 -03 2 ZRt. -2 Az 1 oldali tábla (Eladók) elsődleges (EladóID) kulcsára hivatkozunk a több oldali Multi Szőnyeg 55551231 -02 táblába (Számlák) rakott idegen kulcsmezővel (Foreign Key, FK), aminek: 3 ZRt. -2 Neve (EladóID), típusa megegyezik a hivatkozott elsődleges kulcséval, Varászszőnyeg 66616718 -03 Ismétlődhetnek benne értékek (pl. sok Számla kaphat azonos EladóID-t, így 1 4 Bt. -3 Eladóhoz korlátlan sok Számla csatolható) Kötelező kitöltésű az idegen kulcs (Reqired FK) (nem lehet benne NULL), ha a reláció 1: több, független: függő pl. Számla nem létezhet Eladó nélkül, muszáj hogy hivatkozzon egyre Opcionális kitöltésű az idegen kulcs (Optional FK) (lehet benne NULL), ha a reláció 1: több, független: pl. 1 Ember több Könyv. Példányt kölcsönözhet, de 1 Könyv. Példány 1 Emberek Ember által kölcsönözhető Ember. I Könyv. Példányok D Név Könyv. Pld Ember. I 1 Nagy József ID Író Cím D 2 Kiss Katalin 1 Jókai Mór Arany ember 1 Kovács Kőszívű ember 3 Mihály 2 Jókai Mór fiai Null 4 Török István Jancsó Szeretőim Könyv. Példány úgy is létezik, hogy épp senki nem kölcsönzi, ilyenkor az Szabó 3 Miklós listája 1 Ember. ID idegen kulcsa NULL 5 Miklós Krúdy
Relációs adatbáziskezelés: Normalizáció: 2. Normálforma: Relációk: Több: több reláció tárolódása adatbázisban: pl. 1 Számlának több Termék lehet Tétele, és 1 Termék több Számlán lehet Tétel 2 db 1: több kapcsolatra bontva tárolható, ahol mindkét rész-kapcsolat több oldala a relációs tábla (Relation. Table) amit kék színnel jelölünk (pl. Tételek): ez 2 idegen kulcsot tartalmaz (pl. Vonal. Kód, Számla. ID) amelyek az összekötött törzstáblák (Master Table) (pl. Számlák és Termékek) elsődleges kulcsaira hivatkoznak: Termékek Számlák Vonal. Kód Leírás Számla. I Számla. Sz Kibocs. Dát Fizetv ÖsszÉ 1 -52355 -PVC D ám um e rt 14299 -9 szegély 1 CZ 184788 2004. 03. 29 Igen 22800 1 -52355 -Padlószőny 2 CZ 184789 2004. 01 Igen 33200 13233 -7 eg Tételek 2 -13422 Tétel. I Menny BrutÉr Számla. I 07813 -4 Parketta D Vonal. Kód is t D 1 -523551 14299 -9 60 11400 1 1 -523552 13233 -7 50 11400 1 Engedmények 1 -52355 Engedm Érté Tétel. I 3 13233 -7 65 16600 2 ID Fajta k D 2 -13422 Mennyisé 4 07813 -4 55 16600 2 1 gi 600 1 A relációs táblához is mindig adunk elsődleges kulcsot (pl. Tétel. ID), de Mennyisé 2 gi 600 2 ennek nincs szerepe a több: több reláció tárolásában. Azért kell, hogy később a relációs táblára más táblákat tudjunk kötni (pl. Engedmények). A relációs táblának lehetnek saját adatmezői is (pl. Mennyiség) amelyek gyakran másból számított mezők (pl. BruttóÉrték)
Az előadás tartalma Relációs adatbáziskezelők Normalizációs folyamat 2. Normálforma: Relációk Elsődleges kulcsok kiválasztása 1: több relációk tárolása Több: több relációk tárolása Egyedkapcsolati diagramm (ERD) Relációk ERD-n 1: több Kapcsolat ábrázolása 1: több Hibalehetőségek: Idegen kulcs elfelejtése, Oldalcsere Több: több Kapcsolat ábrázolása Több: több Hibalehetőségek: Relációs tábla kifelejtése, Csirkelábak megfordítása A minimális számosságú csatolás szabálya 3. Normálforma: Rejtett függések kibontása Hasznossága Kinézegető táblák A normalizált tárolási szerkezet és a GUI szerkezete közti különbség Elrettentő népmese
Relációs adatbáziskezelés: Normalizáció: 2. Normálforma: Egyedkapcsolati diagramm A relációs adatbázis szerkezete mintatáblákkal nehezen áttekinthető, Kód ezért egyedkapcsolati diagramm (Entity-relationship Diagram, ERD) Kód. ID segítségével modellezhetjük, melynek jelölései: Kód. Név Az egyedek lekerekített blokkok, Egyed. Nev aláhúzva Elsődleges kulcs( ): Egyed. Nev. ID Félkövérek az auto-kitöltött mezők (pl. és rendszernaplózó mezők: Módosító, Módosítva, Állapot={0: terv, 1: aktív, 2: archív, 3: törlendő}) A kötelező mezők normál, az opcionálisak dőlt szedésűek A sima adatmezők előtt adat-típus ikonok: ( , , ) A kötelező/ opcionális idegen kulcsok ikonja: ( ) A tranzakció egyedek (Transaction Entity) - amelyek gyorsan változó adatokat tartalmaznak - háttere sárga, bennük a rekordok életciklusát leíró rendszernaplózó mezők (System Logging Fields) találhatók A ritkán változó törzs/kód egyedek (Master/Code Entity) háttere kék Reláció(Relation): derékszögben törő összekötő vonal, ahol: Több oldalon csirkeláb (Crows leg, ) van, ezt mindig az idegen Egyed. Név kulcs mellé kötjük az egyed blokkon Egyed. Név. ID 1 oldalon vonal, az egyed-blokk aljára/tetejére kötjük Szöveg A vonal az egzisztenciálisan függő oldalon folytonos ( ), füg. Egész. Szám getlenen szaggatott( )(ha ez több oldal, akkor az opcionális) Tört. Szám A relációk működésének 3 hibás adatok elleni védelmi beállítása: Bináris Hivatkozás integritás (Referential Integrity)ellenőrzés be/ki( , ): Dátum Ha aktív, nem törölhető olyan 1 oldali rekord, amire több ol- Idő dali rekordok hivatkoznak, előbb azokat kell letörölni, ÉS Kép A több oldalon idegen kulcsmezőbe nem vihető be olyan Hang érték, ami nem szerepel az 1 oldal elsődleges kulcsában Mozi Hivatkozás-átkapcsolás (Switch) tiltása/engedése ( , ): az Köt. Ideg. Kulc Opc. Ideg. Kulc idegen kulcs módosítható-e, vagy csak létrehozni/törölni lehet Módosító Kaszkádolt törlés (Cascade Delete) tiltása/engedése ( , ): ha az 1 oldali tábla rekordját törlik, törlődjenek-e a rá hivatkozó több Módosítva oldali rekordok, valamint az azokra hivatkozók is, láncreakcióban Állapot
Relációs adatbáziskezelés: Normalizáció: 2. Normálforma: Relációk ERD-n 1 Az egyedkapcsolati diagram tömören és jól áttekinthetően ábrázolja az adatbázis szerkezetét, de szükség van némi absztrakciós készségre a megértéséhez: Példa 1: több reláció ábrázolására ERD-n: Számla. ID Számla. Szám Tétel. Szám NetÖsszÉrt BrtÖsszÉrt ÁFAÖssz Több oldal Fizetve Kibocs. Dátum Kibocs. Idő Idege n EladóID EladóNév Elad. AdóSzám Mobil 1 E-mail oldal URL Elsődleg es kulcs több oldali tábla 1 oldali tábla Számlák Eladók Számla. I Számla. Sz Kibocs. Dát Fizetv ÖsszÉ EladóI D ám um e rt D D Név Adószám 1 CZ 184788 2004. 03. 29 Igen 11400 1 Magyar Szőnyeg 12549499 -02 41250 1 Kft. -2 Idege Elsődleg 2 CZ 184789 2004. 01 Igen 0 n 1 es kulcs Giga Szőnyeg 33821244 -03 2 ZRt. -2 kulcs Multi Szőnyeg 55551231 -02 VIGYÁZAT, TIPIKUS KEZDŐ HIBA! Egy egyed-dobozka nem csak azt a 3 ZRt. -2 pár mezőt jelenti, amit magunk előtt látunk, hanem képzeljük mögé az Varászszőnyeg 66616718 -03 Bt. lehet, különben -3 adatbázis táblát is, amiben akár több millió rekord 4 is nem fogjuk érteni, hogy a reláció hogy képes letárolni nem fix strukturális hosszúságú adatokat!
Relációs adatbáziskezelés: Normalizáció: 2. Normálforma: Hibák 1 VIGYÁZAT, TIPIKUS KEZDŐ HIBA!: Ne felejtsük el az idegen kulcsot a több oldali táblából! A csirkeláb önmagában NEM jelent kapcsolatot, csak kijelzi azt. Ha nincs idegen kulcs, a kapcsolat nem tud hol tárolódni!!! Számla. ID Számla. Szám Tétel. Szám NetÖsszÉrt BrtÖsszÉrt ÁFAÖssz Fizetve Kibocs. Dátum Kibocs. Idő EladóID EladóNév Elad. AdóSzám Mobil E-mail URL Eladók EladóI Számlák D Név Adószám Számla. I Számla. Sz Kibocs. Dát Fizetv ÖsszÉ Magyar Szőnyeg 12549499 -02 D ám um e rt 1 Kft. -2 1 CZ 184788 2004. 03. 29 Igen 11400 Giga Szőnyeg 33821244 -03 41250 2 ZRt. -2 VIGYÁZAT, TIPIKUS KEZDŐ HIBA!: Ne cseréljük fel az 1 és több oldalt! 2 CZ 184789 2004. 01 Igen 0 Multi Szőnyeg 55551231 -02 Az elsődleges kulcs van az 1 oldalon, az idegen kulcs a több oldalon 3 ZRt. -2 Ha felcseréljük, a kapcsolat csak 1: 1 -et tud tárolni és adatot fogunk veszteni: Varászszőnyeg 66616718 -03 Osztán hol Számla Eladó 4 Bt. -3 Számla. ID Számla. Szám Tétel. Szám NetÖsszÉrt BrtÖsszÉrt ÁFAÖssz Fizetve Kibocs. Dátum Kibocs. Idő Számlák Számla. I Számla. Sz Kibocs. Dát Fizetv ÖsszÉ D ám um e rt 1 CZ 184788 2004. 03. 29 Igen 11400 tárolod a EladóID cég által EladóNév Elad. AdóSzámadott többi 612781 Mobil számlát, E-mail Öcsi-sajt!? URL Mer’ ide Számla. ID csak 1 db Számla. ID Számla. I fér! Adószám D Eladók EladóI D Név Magyar Szőnyeg 125494991 Kft. 02 -2 Giga Szőnyeg 33821244 - 1
Relációs adatbáziskezelés: Normalizáció: 2. Normálforma: Relációk ERD-n 2 Példa több: több kapcsolat ábrázolására ERD-n: Törzs egye d Termék Vonal. Kód Leírás EgységÁr 1 oldal Törzs tábla Több oldal Reláció Tétel. ID s egyed Mennyis NetÉrt BrutÉrt Számla. ID Vonal. Kód Több oldal Törzs Számla. ID egye Számla. Szám d Tétel. Szám NetÖsszÉrt BrtÖsszÉrt 1 ÁFAÖssz oldal Fizetve Kibocs. Dátum Kibocs. Idő Törzs tábla Termékek Számlák Vonal. Kód Leírás Számla. I Számla. Sz Kibocs. Dát Fizetv ÖsszÉ 1 -52355 -PVC D ám um e rt 14299 -9 szegély 1 CZ 184788 2004. 03. 29 Igen 22800 1 -52355 -Padlószőny 2 CZ 184789 2004. 01 Igen 33200 Relációs 13233 -7 eg tábla Tételek Elsődleg 2 -13422 Tétel. I Menny BrutÉr Számla. I es kulcs 07813 -4 Parketta. D Vonal. Kód is t D 1 -523551 14299 -9 60 11400 1 Idege 1 -52355 n n 2 13233 -7 50 11400 1 kulcs Különösen fontos az egyedek mögötti táblákat elképzelni a több: több 1 -52355 kapcsolat ábrázolásánál: a relációs táblában (pl. Tételek) rengeteg rekord 3 13233 -7 65 16600 2 2 -13422 lehet, ezért képes leírni bármilyen kapcsolódást a törzstáblák rekordjai közt: 4 07813 -4 55 16600 2 Pl. ugyanazon ismétlődő Vonal. Kódhoz sok eltérő Számla. ID rendelődik számos rekordon keresztül, ha egyfajta Termék sok Számlán szerepel Vagy ugyanazon ismétlődő Számla. IDhez sok eltérő Vonal. Kód rendelődik számos rekordon keresztül, ha egy Számlán sokfajta Termék szerepel
Relációs adatbáziskezelés: Normalizáció: 2. Normálforma: Hibák 2 VIGYÁZAT, TIPIKUS KEZDŐ HIBA!: Ne felejtsük el, hogy a több: több kapcsolat tárolásához kell egy harmadik relációs tábla! Gyakori hiba, hogy ehelyett a 2 törzstáblát kötik szembe fordított irányú 1: több relációkkal: Ez azonban működésképtelen: pl. ha van olyan Termékfajta, ami több Számlán is szerepel, és ezen Számlák közt is van olyan, amin többfajta Termék szerepel, a kapcsolatok letárolásához meg kellene többszörözni azonos rekordokat mind a Termékek és Számlák táblában, ami ismétlődést okozna az elsődleges kulcsaikban, és totálisan összezavarná a rájuk szóló hivatkozásokat! Számla. ID Termék Számla. Szám Vonal. Kód Tétel. Szám Leírás NetÖsszÉrt EgységÁr BrtÖsszÉrt Számla. ID Ezek közül most melyik az igazi, Öcsisajt? ! Termékek ÁFAÖssz Fizetve Kibocs. Dátum Kibocs. Idő Vonal. Kód Számlák Számla. I Számla. Sz Kibocs. Dátu Fizetv ÖsszÉ Vonal. Kód Leírás D ám m e rt Vonal. Kód 1 -52355 -PVC 1 -5235514299 -9 szegély 1 1 CZ 184788 2004. 03. 29 Igen 22800 14299 -9 1 -52355 -Padlószőny 1 -5235513233 -7 eg 1 1 CZ 184788 2004. 03. 29 Igen 22800 13233 -7 VIGYÁZAT, TIPIKUS KEZDŐ HIBA!: Ne tévesszük el a csirkelábak irányát a relációs 1 -52355 -Padlószőny 1 -52355 táblánál! Gyakran úgy rajzolják fel a 2 csirkelábat, hogy a törzstáblák vannak a több 13233 -7 eg 2 2 CZ 184789 2004. 01 Igen 33200 13233 -7 oldalon, mert így néz ki a „több: több” csirkeláb. De a relációs táblában vannak az 2 -13422 idegen kulcsok, ezért az mindkét részkapcsolat több oldala! 07813 -4 Parketta 2 2 CZ 184789 2004. 01 Igen 33200 07813 -4 Számla. I D
Vevő Eladó VevőID EladóID Kereszt. Név Cég. Név A 2. normálformában a gyakorlati adatstruktúrák Számla Vezeték. Név Jogi. Forma EladóNév R a következő összekötött egyedekre esnek szét: Ajtó EladóAdóSz EladóCím R 1 Eladóhoz több Számla tartozhat, de 1 Emelet Ajtó EladóAdóSzám R Számlához 1 Eladó tartozik Épület Emelet VevőNév CRU Ház. Szám Épület 1 Vevőhöz több Számla tartozhat, de 1 VevőCím CRU Köz. Ter. Név Ház. Számla. Szám R Számlához 1 Vevő tartozik Köz. Ter. Tip Köz. Ter. Név ÉrtékesítőNév CRU 1 Értékesítőhöz több Számla tartozhat, de 1 Város Köz. Ter. Tip ÖsszÉrték= Számlához 1 Értékesítő tartozik Irány. Szám Város Sum(Tétel. BruttóÉrték) 1 Számlához több Tétel tartozhat, de 1 Ország Irány. Szám Fizetve CRUD Mobil Ország Tételhez 1 Számla tartozik Dátum E-mail Telefon Kérdés, hogy melyikhez érdemes kötni új egyed- Idő Mobil Tétel Számla ként a Termék(fajtát)? Erre 3 lehetőség is van: E-mail Tétel. Leír R Számla. ID 1 Értékesítő több Terméket adhat el, és 1 URL Mért. Egys R Számla. Szám Termék(fajtát) több Értékesítő adhat el Vonal. Kód CR Tétel. Szám Értékesítő 1 Vevő több Terméket vehet, és 1 ITJKód R ÉrtékesítőID NetÖsszÉrt Termék(fajtát) több Vevő vehet Mennyis CRUD BrtÖsszÉrt Kereszt. Név EgységÁr R 1 Termék(fajta) több Tételhez tartozhat, Vezeték. Név ÁFAÖssz ÁFA% R Fizetve de 1 Tételhez 1 Termék(fajta) tartozik Ajtó BruttóÉrték= Kibocs. Dátum Emelet Amikor a Termék(fajtát) az Értékesítőhöz (EgységÁr* Kibocs. Idő Épület vagy az Eladóhoz kapcsoljuk, ezek több: több Mennyis*(+ EladóID Ház. Szám ÁFA%/100)) kapcsolatok lennének, és elveszítjük az infót, VevőID Köz. Ter. Név Értékesít. ID hogy a Termék(fajta) mely Tételekben szerepelt. Köz. Ter. Tip Módosító Város Amikor a Tételhez csatoljuk, ez 1: több Módosítva Irány. Szám kapcsolat lesz, és a Számlán keresztül vissza Állapot Ország tudjuk hozzá keresni az Értékesítőt és az Tétel Telefon Eladót, így nem vesztünk infót. Tétel. ID Mobil Ez a legalacsonyabb számosság szabálya (Mini. Mennyis E-mail NetÉrt mal cardinality rule): ha egy új egyedet több Termék BrutÉrt meglévő egyedhez is csatolhatunk, akkor a leg. Vonal. Kód Számla. ID alacsonyabb számosságú, legfüggőbb kapcso. Leírás Vonal. Kód EgységÁr lattal csatoljuk (pl. 1: több, független: függő Modosító ITJKód Modosítva több: több, független: független helyett) Mért. Egys Állapot RDM: Normalizáció: 2. Normálforma: Minimális számosság
Az előadás tartalma Relációs adatbáziskezelők Normalizációs folyamat 2. Normálforma: Relációk Elsődleges kulcsok kiválasztása 1: több relációk tárolása Több: több relációk tárolása Egyedkapcsolati diagramm (ERD) Relációk ERD-n 1: több Kapcsolat ábrázolása 1: több Hibalehetőségek: Idegen kulcs elfelejtése, Oldalcsere Több: több Kapcsolat ábrázolása Több: több Hibalehetőségek: Relációs tábla kifelejtése, Csirkelábak megfordítása A minimális számosságú csatolás szabálya 3. Normálforma: Rejtett függések kibontása Hasznossága Kinézegető táblák A normalizált tárolási szerkezet és a GUI szerkezete közti különbség Elrettentő népmese
Relációs adatbáziskezelés: Normalizáció: 3. Normálforma 1 Jogi. Forma A 3. Normálforma az egyeden belüli rejtett függések Jogi. Forma (Hidden Dependencies) kibontásáról szól: Forma. Név 1 Eladóhoz/Vevőhöz/Értékesítőhöz 1 Irány. Szám, Település, Ország tartozik (1 időpontban) ezért ezek egyszerű (nem kulcs) mezők lettek ezen táblákban, így az adatrögzítőnek minden rekordban kézzel kell kitölteni Köz. Ter. Tip mind a hármat (pl. „ 8688”, „Vasmacskakovácsi”, „Közép- Köz. Ter. Tipus. Név Kelet Abszurdisztán”) Előfordulhat azonban, hogy egyszerű adatmező értéke egyértelműen meghatározza egy másik értékét: 1 IrányítóSzám 1 Településhez tartozik (Mo. -n vannak Ir. Szám ritka kivételek aprófalvalban de hanyagolhatók), de 1 Településhez több IrányítóSzám tartozhat Ország Település: IrányítóSzám=1: több, független: függő Irány. Szám egyértelműen meghatározza a Települést Ország Hasonlóképpen: Ország: IrányítóSzám=1: több, füg. Ország Orsz. Név getlen: függő Ir. Szám meghatározza az Országot Ekkor érdemes az Ir. Számok és az Országok táblákat külön kibontani a fenti relációkkal összekötve, mert így az adatrögzítő csak a rövid, nehezen elírható Ir. Szám idegen kulcsot viszi be a címeknél (pl. „ 8688”), a többi adat automatikusan lekérdezhető hozzá a táblákból a ÁFA relációkon keresztül Órási adatrögzítési- és időÁFASáv ÁFA% megtakarítás! (pl. áruházakban ÁFÁs számlázásnál!) Sőt, egyáltalán nem tud elírni semmit, ha az Ir. Szám idegen kulcs, nem egyszerű szövegdoboz (Textbox) ITJ kontrollként jelenik meg, hanem olyan legördülő lista ITJKód Leírás (Dropdown list/Combo Box), ami a tartalmát a hivatÁFASáv kozott 1 oldali tábla (Ir. Számok) elsődleges kulcsából (Ir. Szám) és annak leírásából (Települ) szedi fel. Ezt nevezzük kinézegető táblának (Lookup table) Mért. Egys Hasonló okokból bontjuk ki a Jogi. Forma, Köz. Ter. Tip, VevőID Kereszt. Név Vezeték. Név Ajtó Emelet Épület Ház. Szám Köz. Ter. Név Köz. Ter. Tip Ir. Szám Mobil E-mail Számla. ID Számla. Szám Tétel. Szám Értékesítő NetÖsszÉrt ÉrtékesítőID BrtÖsszÉrt Kereszt. Név ÁFAÖssz Vezeték. Név Fizetve Ajtó Kibocs. Dátum Emelet Kibocs. Idő Épület EladóID Ház. Szám VevőID Köz. Ter. Név Értékesít. ID Köz. Ter. Tip Módosító Ir. Szám Módosítva Telefon Állapot Mobil E-mail Tétel. ID Mennyis NetÉrt Termék BrutÉrt Vonal. Kód Számla. ID Leírás Vonal. Kód EgységÁr Modosító IITJKód Modosítva Állapot MEgys. Név Mért. Egys EladóID Cég. Név Jogi. Forma EladóAdóSz Ajtó Emelet Épület Ház. Szám Köz. Ter. Név Köz. Ter. Tip Ir. Szám Telefon Mobil E-mail URL
Relációs adatbáziskezelés: Normalizáció: 3. Normálforma: Hol tartunk most? Eladok Jogi. Forma Eladó Vevő Elado. I Nev Haz. Sza Emel Laka Koz. Te. N Jogi. Forma Koz. Te. T Ir. Sza VevőID EladóID Forma. Név Kereszt. Név D m et s ev ip m Cég. Név Vezeték. Név Jogi. Forma 1 Magyar 57 Pécsi Út 7300 Vevok Ajtó EladóAdóSz Kft. Emelet Vevo. I Nev Haz. Sza Emel Laka Koz. Ter. N Koz. Ter. TAjtó Ir. Sza Épület Emelet D m et s ev Köz. Ter. Tip ip m Ház. Szám Épület 1 Pauler 2 2 9 Kisréti Köz. Ter. Tip Utca 7636 Köz. Ter. Név Ház. Szám Ertekesito Ir. Szamok ITJk Tipus. Név Köz. Ter. Név Gábor Köz. Ter. Tip Értékes. I Elado. I Ir. Sza Telep Afa. Sa Nev Ir. Szám Köz. Ter. Tip D D m ul ITJKod Nev Mobil Ir. Szám v. Telefon 1 Szalai 1 7300 Koml E-mail Ir. Szám Mobil 231816 Melegbu 2 S. ó Számla Ir. Szám AFAk Termekek E-mail Számla. ID 7636 Pécs Egys 12 Települ rk Afa. Sa Afa URL Számla. Szá Ország SELECT Vonal. Kod Nev Mert. Egys Ar ITJKod v % Szamlak. Szla. Szam, Tétel. Szám Szamlak. Datum, Értékesítő NetÖsszÉr 1 0. 12 175194586197 PVCFolyómét 190 Ország 231816 Szamlak. Veg. Osszeg, Szamlak ÉrtékesítőID BrtÖsszÉrt Szamlak. Fizetve, 2 0. 25 78 szegély er 12 Ország Kereszt. Név ÁFAÖssz Szamla. I Datum Veg. Ossze Fizetv Elado. I Vevo. I Szamlak. Elado. Kod, Orsz. Név Vezeték. Név Fizetve D g e D D Szamlak. Vevo. Kod, Eladok. Nev, Ajtó Kibocs. Dátu Eladok. Ado. Szam, CZ 1847 11, 400 Yes 1 1 Emelet Kibocs. Idő Tetelek 03/29/0 Ertekesitok. Nev, 88 4 Épület Cimek. Haz. Szam, EladóID Tetel. I Mennyise Ertek Szamla. I Vonal. Kod Cimek. Emelet, Ház. Szám VevőID Cimek. Lakas. Szam, D g D Köz. Ter. Név Értékesít. ID Cimek. Koz. Ter. Nev, 1 60. 0011, 40 CZ 1847 17519458619 Köz. Ter. Tip ÁFA Módosító Cimek. Irany. Szam, A normalizáció következtében egyszerű kis ÁFÁ-s szám. Ir. Szamok. Telepul, Ir. Szám ÁFASáv Módosítva 0 88 778 la adatai is rémisztően sok táblára esnek szét, és a norma. Vevok. Nev, ÁFA% Telefon Állapot Vevok. Haz. Szam, Mobil lizált, minimális helyfoglalásra és adatrögzítési igényre opti. Vevok. Emelet, E-mail Vevok. Lakas. Szam, Tétel malizált tárolási szerkezet teljesen más, mint a papír-alapú! ITJVevok. Koz. Ter. Nev, Tétel. ID Vevok. Irany. Szam, Ezért a tervet a fejlesztő is csak ERD-n tudja áttekinteni, de a ITJKód Mennyis Ir. Szam_1. Telepul Leírás NetÉrt FROM felhasználónak erre esélye sincs Termék ((Irany. Szamok AS Irany. Szamok_1 ÁFASáv BrutÉrt Ezért a tárolási rendszer adatbázis táblái és a GUI űrlapjai INNER JOIN Vonal. Kód Vasarlok Számla. ID ON Irany. Szamok_1. Irany. Szam = Leírás (Form) közt majd egy nézettáblás lekérdezés (View Table) Vonal. Kód Vasarlok. Irany. Szam) EgységÁr INNER JOIN(((Irany. Szamok INNER Modosító teremt kétirányú adatkapcsolatot: felhozza a tárolt adatokat Mért. Egys JOIN Cegek IITJKód Mért. Egys Modosítva ON Irany. Szamok. Irany. Szam = Mért. Egys és visszaviszi a felhasználó által rögzítetteket MEgys. Név Állapot Cegek. Irany. Szam) INNER JOIN Eladok ON Cegek. Ado. Szam Emiatt a GUI-n a felhasználó szinte ugyanazt láthatja majd, = Eladok. Ado. Szam) mint papíron, de az elektronikus űrlap korlátlan kapacitással INNER JOIN Szamlak ON Eladok. Elado. Kod = fog működni (pl. max. 12 tétel helyett sok 100 -at bevihetünk) Szamlak. Elado. Kod) ON Vasarlok. Vasarlo. Kod = DE SOHA NE KEVERJÜK ÖSSZE A TÁROLÁSI STRUKSzamlak. Vasarlo. Kod); TÚRÁT A GUI-N LÁTHATÓVAL!!!
Szakirodalom Relációs adatbáziskezelés: E. F. Codd: http: //en. wikipedia. org/wiki/Edgar_F. _Codd, http: //www. itworld. com/nl/db_mgr/05072001/ Normalizáció: www. inczedy. hu/~szikszai/adatbazis/ab 2. ppt http: //support. microsoft. com/kb/283878/hu
- Slides: 16