V. rész: Az információtechnológia menedzselése

V. rész:

Az információtechnológia menedzselése

Bevezetés 1. Technológia-menedzsment, alkalmazásportfólió-menedzsment, szoftvermenedzsment 2. Információs rendszer fejlesztése 3. Információs rendszer mőködtetése – üzemeltetés- és szolgáltatásmenedzsment 4. Informatikai biztonság

248

SZERVEZÉSTECHNOLÓGIA

Bevezetés

1. Technológia-menedzsment, alkalmazásportfólió-menedzsment, szoftvermenedzsment

AZ INFORMÁCIÓTECHNOLÓGIA MENEDZSELÉSE

2. Információs rendszer fejlesztése 2.1. A fejlesztési folyamat áttekintése

2.2. Követelményelemzés

249

250


2.3. Tervezés a szoftverfejlesztésben A követelmények meghatározása után elkezdıdhet a szoftverrendszer tervezése. Ezt az állítást azonban finomítani kell: • A klasszikus vízesés modell felfogása szerint az állítás úgy értendı, hogy a rendszer teljes egészére nézve lezajlott a (követelményelemzés), döntés született az érvényes rendszerszervezési változatról, és ekkor elkezdıdhet a rendszer egészének a tervezése. • A különféle iteratív-inkrementális életciklusmodellek (módszertanok) felfogásában viszont a fenti sorrend nem a rendszer egészére kiterjesztetten érvényes, hanem csak egy-egy inkrementumra korlátozottan, illetve iterációnként ismétlıdıen. A szoftvertervezés és minden más komplex termék tervezése esetében a siker alapvetı feltétele, hogy a tervezés termékének és a hozzá vezetı tervezési folyamatnak megtalálják egy olyan felépítését (architektúráját), amely egyszerre alkalmas: • az összetett feladat „megszelídítésére”; • ahol lehetséges, a készen adott komponensek befogadására; • könnyen áttekinthetı, tesztelhetı, változtatható termék elállítására. Fontos technológiai elv: Egymástól független problémák között a fejlesztı ne létesítsen mesterséges függést azzal, hogy a megoldásukat egyazon – nem bontható – komponensre bízza.

Módszertantól függetlenül érvényes, hogy a fenti elv teljesítése a terv (és a megvalósított kód) olyan tagolását igényli, amelyben az egymástól független döntéseket és megoldásokat különálló alapkomponensek hordozzák. Emlékeztetünk rá, hogy a Gazdasági informatika alapja c. jegyzet 5.2.6. szakasza kétféle olyan tagolási sémával is foglalkozott, amelyek mindegyike az egymástól független problémák elkülönítését segíti: • A hagyományos (elsısorban strukturált) megközelítési mód a tervezés szintekre (fogalmi, logikai és fizikai szint), valamint vetületekre (adatvetület, feldolgozási vetület és környezetvetület) tagolását javasolta. • Az objektumorientált megközelítési módot követı SunTone módszertan az elıbbinél bonyolultabb háromdimenziós tagolást (osztályozást) javasolt olyan dimenziókkal mint a szintek (hardver, alsó platform, felsı platform, virtuális platform és alkalmazás), a rétegek (kliens, megjelenítés, üzleti logika, integráció és adatforrás), valamint a rendszerminıségek (felhasználói, mőködési, fejlesztıi, fejlıdési). Az elıbb említetteken túl a szoftvertervezés során alkalmazott modellezésnek / modelleknek is létezik egy osztályozása, mégpedig megkülönböztetnek sztatikus modellezést (a rendszer idıtıl független szerkezetének modelljeit) és dinamikus modellezést (az idıbeliséget, sorrendiséget figyelembe vevı


251

modelleket), de ezek mellé harmadik kategóriaként mi még odatesszük az ember-gép párbeszéd tervezését is. – E modellezési kategóriákban egyfelıl a strukturált módszertan vetületei köszönnek vissza (pl. a sztatikus modellezés a strukturált módszertanra visszavetítve éppen az adatvetületnek – az adatmodellezésnek – felel meg); másfelıl az objektumorientált megközelítési mód szemléletével is összhangban állnak, amennyiben a sztatikus modellezés a programot alkotó objektumok szerkezetének leírására, a dinamikus modellezés pedig az objektumok viselkedésének feltárására szolgál. Összefoglalóan elmondható, hogy e modellezési kategóriák megkülönböztetése is bizonyos döntések függetlenségének felismerését segíti; az együttes alkalmazásuk pedig azt célozza, hogy a tervezett konstrukciókat (egyedeket, objektumokat, adat- és szoftver-építıelemeket) többoldalú megfontolásnak vessük alá.

2.3.1. Sztatikus modellezés – Adatmodell és objektummodell A szoftverrendszerek tervezése során alkalmazott sztatikus modellezés körébe tartozik • a hagyományos megközelítési módok esetében az adatmodellezés (lényegét tekintve az adatbázisok szerkezetének tervezése) valamint az egyes feldolgozások be- és kimenetét képezı adatszerkezetek tervezése; • az objektumorientált megközelítési esetében pedig az objektummodellezés, azaz az objektumok osztályainak valamint az azok között fennálló viszonyoknak (asszociációknak, leszármazási kapcsolatoknak és egyéb függéseknek) a specifikálása. Az alfejezetnek nem lehet célja, hogy tövirıl hegyire megismertesse az olvasót az üzleti információrendszerek (szoftverrendszerek) tervezése során alkalmazott összes módszerrel (az több kötetre rúgna), így a jelen szakasz is csak egy szőkre szabott ízelítıt ad a sztatikus modellezés során követett elvekbıl, racionális meggondolásokból. – A korszerő objektumorientált technológia1 megértése sajnos alaposabb elıtanulmányokat igényelne, ezért itt csak adatmodellezés tárgyalására fogunk szorítkozni.

Adatmodellezés Az adatmodellezés speciális adatszerkezetek – mégpedig az adatbázisban tárolt adatszerkezetek – tervezését jelenti. Az IT fejlıdése során különféle típusú adatbázisok alakultak ki. Legkorábban (1970-es évek) a hierarchikus-hálós adatbázisok terjedtek el, de ezeket az 1980-as évek második felétıl kezdıdıen fokozatosan kiszorították a relációs adatbázisok, melyek mára – legalábbis a végrehajtást támogató alkalmazások alatt – szinte egyeduralkodókká váltak (igaz, ma már inkább az objektumrelációs hibrid változatban). Pontosításként meg kell említeni, hogy 1

Ha valakit mégis érdekelne, létezik egy Objektumorientált elemzés és tervezés c. BGF-jegyzet is a jelen tankönyv szerzıjétıl (bár a külsı borítóján – a kiadó hibájából – Objektumorientált tervezés és elemzés álcím olvasható).

252


az 1990-es években valamennyire megélénkült az objektumorientált adatbázisok forgalma is, de ezek üzleti alkalmazása nem számít jelentısnek. Külön kell szólni a vezetıi információs rendszerekrıl, mert azok adatbázisainak (adattárházainak) céljára technikailag elınyösebb lehet az ú.n. többdimenziós adatbázist alkalmazni; ennek ellenére gyakran itt is valamilyen relációs adatbázisra esik a választás. Az adatbázisok tervezése is a fentiekben már említett szintekre tagoltan történik: • Idıben a fogalmi szintő adatmodell (más névvel a szakterületi adatmodell) megszerkesztése az elsı feladat. Ez a modell kizárólag az alkalmazási területet jellemzı összefüggéseket tükrözi, egyéb informatikai megvalósítási szempontok iránt, a használható eszközök korlátai iránt közömbös, így tökéletesen hordozható. • A következı lépés a logikai tervezés, amely már a hatékonysági, biztonsági szempontokat és a szervezeti korlátokat is figyelembe veszi. • Végül a fizikai tervezés a logikai tervet a megvalósító eszköz, a konkrét adatbáziskezelı korlátaihoz igazítja. Ebben a szakaszban csak a fogalmi (szakterületi) szintő adatmodellezés elveire szorítkozunk.

Az adatmodellezés alapfogalmai A fogalmi / szakterületi adatmodell megszerkesztése során feltárják az alkalmazási terület (szakterület) azon jelenségeit, egyedeit (tárgyakat, személyeket, eseményeket stb.), amelyekre vonatkozóan a tervezett adatbázisban adatokat szeretnének nyilvántartani. Meghatározzák, hogy a szakterületi igények szerint az egyedek leírására milyen tulajdonságokat (adatfogalmakat) kell nyilvántartani; továbbá kiderítik azokat a (szakterületi / üzleti) szabályokat, amelyekbıl a tulajdonságok közötti valamilyen függések, egyedek közötti kapcsolatok, a tulajdonságok értékeire vagy a kapcsolatokra vonatkozó valamilyen korlátok / megszorítások következnek. Az elmondottakkal összhangban az adatmodellezés olyan alapfogalmakat használ, mint • az egyed (entitás), • a tulajdonság (attribútum) • és a kapcsolat.

Egyed, tulajdonság, kapcsolat Egyed (entitás) minden olyan tárgy, jelenség, esemény (cikk, vevı, szállító, rendelés stb.), amelyrıl valamilyen jellemzı adatokat nyilván kell tartani a rendszerünkben. Tulajdonságok (attribútumok) alatt éppen a nyilvántartott jellemzıket (név, ár, szín, idıpont stb.) értjük. A kapcsolatok az egyedek közötti viszonyok. A tervezı persze nem konkrét egyedekkel (szállítókkal, számlákkal) és nem konkrét adatértékekkel foglalkozik, hanem csak ezek típusaival: nem a konkrét egyedeket külön-külön, hanem azok közös szerkezetét kell megtervezni. Ezért meg kell különböztetni a fentebb bevezetett fogalmak elıfordu-


253

lásszintő és típusszintő értelmezését. Így beszélünk konkrét egyedelıfordulásról (pl. egy konkrét szállítói számla) és egyedtípusról. Az egyedtípus egyrészt valamilyen, azonos típusú egyedelıfordulások halmazát (pl. a számla egyedtípus a számlák halmaza), másrészt a típusba tartozó elıfordulások közös szerkezeti sémáját képviselı kategória. Hasonlóan meg kell különböztetni a konkrét tulajdonságértéket (pl. zöld) a tulajdonságtípustól (pl. szín). Ezen felül egy tulajdonságtípussal foglalkozhatunk magában mint értékhalmazzal, másrészt pedig mint valamely egyedtípus jellemzıjével. A tulajdonság értékhalmazát (értéktartományát) doménnek (vagy doméjnnek – eredetileg domain) nevezik, az egyedtípushoz rendelt tulajdonságot pedig attribútumnak. Példa doménre és attribútumra: Amikor egy vállalkozás kidolgozza számlarendjét, azon belül a számlatükröt, azzal meghatározza a fıkönyvi számlaszám lehetséges értékeinek halmazát, azaz a fıkönyvi számlaszám domént. Amikor egy bizonylat kontírozásakor elıálló könyvelési tételben feltüntetik az arra vonatkozó fıkönyvi számlaszámot, akkor azt mint a könyvelési tétel egyedtípus attribútumát használják. Könyvelési tétel egyedtípus: A következı táblázat egy gépi beruházás számlájáról készült négy könyvelési tételt mutat. A bizonylatszám értéke éppen azért azonos a tételekben, mert mindet azonos bizonylat kontírozása eredményezte. Hasonlóan a tételekben a Követel számlaszám azért azonosan 449, mert mindegyikben a Beruházási szállítók fıkönyvi számla "követel". A táblázat sorai a könyvelési tétel egyed elıfordulásai, oszlopai ugyanezen egyedtípus attribútumai. Az egyedtípus Tartozik számlaszám és Követel számlaszám attribútumainak a doménje azonos: a fıkönyvi számlaszám domén. Számlatétel azonosító 1111 1112 1113 1114

Könyvelés Bizonylatdátum kód

Tartozik Követel Forgalom- Megjegyzés szlaszám szlaszám érték

19970908 19970908 19970908 19970908

16 4661 16 4661

2222 2222 2222 2222

449 449 449 449

8000000 2000000 1000000 120000

A gép számlázott ára A gép árára 25 %-al felszámított ÁFA Számlázott szállítási költség A szállítási költség 12 %-os ÁFA-ja

V.1. táblázat: Könyvelési tételek táblája

Különbözı egyedelıfordulások éppen attól azonos típusúak (azért tartoznak egy egyedtípusba), mert mindegyiket a tulajdonságtípusok (attribútumok) azonos együttese jellemzi. Az azonos egyedtípusba tartozó elıfordulások közös szerkezete, azaz az egyedtípus szerkezete nem más, mint a jellemzı attribútumok felsorolása és közülük az azonosító attribútum kijelölése. Az azonosító attribútum (másképpen elsıdleges kulcs) az egyedtípus olyan tulajdonsága, amely a1) az egyed minden elıfordulására értelmezhetı (mindegyikhez tartozik valamilyen értéke); a2) értékei és az egyed elıfordulásai között kölcsönösen egyértelmő megfelelés áll fenn; a3) stabil, azaz valamely egyedelıforduláshoz tartozó értéke az elıfordulás élettartama alatt nem változik; a4) minimális, azaz nincs olyan része, amely szintén teljesítené az a1)– a3) feltételeket.

254


1. megjegyzés: Az a2) feltétel teljesülésébıl logikailag az a1) teljesülése is következik, azaz elméletben elegendı lett volna az a2)-a4) feltételeket kikötni. Azonban a gyakorlat azt bizonyítja, hogy az a1)-re mégis célszerő külön ráirányítani a figyelmet. Példa erre az 1996. évi XX. Törvény 1. sz. melléklete (lásd a következı keretezett szöveget). 1. számú melléklet az 1996. évi XX. Törvényhez: Az adózó polgár adóazonosító jelének képzési szabályai 1. Az adóazonosító jel tízjegyő szám. 2. Az adóazonosító számot az alábbiak szerint kell képezni: a) az 1. számjegy konstans 8-as szám, mely az adóalany magánszemély voltára utal, b) a 2-6. számjegyek a személy születési idıpontja és az 1867. január 1. között eltelt napok száma, c) a 7-9. számjegyek az azonos napon születettek megkülönböztetésére szolgáló véletlenszerően képzett sorszám, d) a 10. számjegy az 1-9. számjegyek felhasználásával matematikai módszerekkel képzett ellenırzı szám. 3. Az adóazonosító jel 10. számjegyét úgy kell képezni, hogy a 2. a)-c) pontok szerint képzett 9 számjegy mindegyikét szorozni kell azzal a sorszámmal, ahányadik helyet foglalja el az azonosítón belül. (Elsı számjegy szorozva eggyel, második számjegy szorozva kettıvel és így tovább.) Az így kapott szorzatok összegét el kell osztani 11-gyel, és az osztás maradéka a 10. számjeggyel lesz egyenlı. A 2. c) pont szerinti születési sorszám nem adható ki, ha a 11-gyel való osztás maradéka egyenlı tízzel. *** A szerzı kommentárja: Ha valóban a fentebb elıírt módon osztaná az APEH rendszere az adóazonosító jelet, akkor abból nem jutna minden magyar állampolgárnak: Az idézett törvényszövegbıl kitőnik, hogy az adóazonosító jel 7-9 pozícióin álló véletlenszámnak kellene megkülönböztetni az egy napon születetteket. Erre a 000-999 tartományba esı értékhalmaz elvben elegendı is lenne, mivel naponta 1000-nél jóval kevesebb magyar állampolgár születik. A jogászok azonban nem számoltak azzal a számelméleti ténnyel, hogy a születési dátum által egyértelmően meghatározott 2-6. pozíción bizonyos dátumok esetén olyan érték is adódhat, amely mellett a 000-999 tartományból a szabály 3. pontja miatt annyira sok nem osztható ki, hogy végül kevesebb kiosztható marad, mint amennyien a szóban forgó dátummal adott napon születnek. A hibát az APEH adóalany-nyilvántartó rendszerét fejlesztı cég programozója vette észre, és ı talált ki egy olyan kivételszabályt, amely a kritikus dátumok esetén a 2-6. pozíciók értékét a nem a 2.b) szabály szerint képezi, viszont garantálja, hogy minden magyar állampolgárnak osztható adóazonosító jel. Az egy másik történet, hogy a jogalkotók (immár 12 éve fittyet hányva azokra a bosszúságokra, amiket ezzel egyes állampolgároknak okoznak), azóta sem javították ki az általuk elkövetett hibát, azaz nem egészítették ki a törvény szövegét a programozó által kitalált kivételszabállyal. Ami jó hír, a problémát megoldó programozó ellen sem indítottak eljárást törvényszegésért. Egyelıre.

2. megjegyzés: Az a4) nem feltétlenül azt jelenti, hogy az azonosító attribútum rövid. Lehetséges, hogy két különbözı módon konstruált azonosítójelölt közül a hosszabb minimális, a rövidebb viszont nem az. Példa nem valódi azonosítóra: Magyarországon az adószámmal2 rendelkezı adóalanyok esetén az adószám tekinthetı-e az ilyen adóalanyok azonosítójának? A megoldás: Nem. A tizenegy pozíciós adószám így épül fel: 1–8. pozíció: törzsszám, 9. pozíció: ÁFA-kód 10– 11. pozíció: illetékes igazgatóság kódja. Az ÁFA-kód azt mutatja, hogy az adóalany (az ÁFA tv. 49.§-ban meghatározott feltételek teljesülése mellett) az aktuális adóévben az alanyi ÁFAadómentességet választotta-e vagy sem3. Az ÁFA tv. 51.§ szerint az adóalany az alanyi adómentességet az adóév végéig választja, azt követıen ismét élhet választási jogával. 2 3

Az adószám nem keverendı össze a megelızı példában szerepelt adóazonosító jellel! Nem ÁFA-alany esetén még megkülönbözteti az EVA-alanyiságot is.

255


Az illetékes igazgatóság kódja szintén változik, amikor az adóalany székhelyét vagy az illetékességet meghatározó telephelyét olyan címre helyezi át, amely szerint a korábbitól különbözı adóigazgatóság illetékes (Art. 50.§) Az APEH nyilvántartásában az ilyen adóalanyok esetében csak a törzsszám változatlan, következésképpen a törzsszámnak magában pontosan meg kell határozni az adóalanyt. Végeredményben tehát az adószám nem stabil és nem is minimális. Az igazi azonosító a törzsszám. Ehhez az adószámban csak azért kapcsoltak hozzá más jellemzıket, hogy abból az adóalany ÁFA-alanyisága és az illetékességi hovatartozása anélkül látható legyen, hogy a törzsszám felhasználásával ezeket az adóalanyi törzsadattárból lekérdeznék.

A kapcsolat egyedek közötti viszony. Pontosabban egy kapcsolatelıfordulás konkrét egyedelıfordulások viszonya, a kapcsolattípus pedig az azonos tartalmú viszonyt kifejezı kapcsolatelıfordulások halmazaként áll elı. A kapcsolatokat az alkalmazási terület összefüggései (üzleti, szakterületi szabályok) definiálják. (Pl. az a tény, hogy a számlát egy szállító állította ki, egyfajta kapcsolatot definiál a számla és a szállító egyedek között.) A kapcsolatok fontos jellemzıi: • a foka és • az, hogy kötelezı vagy csak lehetséges (opcionális), • valamint hogy stabil vagy instabil a benne részvevı egyedtípusokra nézve. SZÁLLÍTÓ

kiállítja

SZÁMLA

felettes alárendelt

SZÁLLÍTÓ

szállít-vesz

VEVÕ

SZÁLLÍTÓLEVÉL

szállítmányról

SZÁMLA

SZERVEZETI EGYSÉG

BIZONYLAT

FÕKÖNYVI SZÁMLA

INGATLAN forrás TÁRGYI ESZKÖZ

MÛSZAKI BERENDEZÉS

fõtípus és altípusai

JÁRMÛ

tartozik követel

SZINTETIKUS KÖNYV. TÉTEL

V.2. ábra: Néhány kapcsolat ERD-je

Az egyedek közötti kapcsolatok ábrázolása az adatmodellezésben egyedkapcsolat-diagramokon (angolul: Entity Relationship Diagram – ERD) történik. Ilyen diagramot mutat a V.2. ábra. A következı bekezdések példaként az ezen ábrán látható kapcsolatokat elemzik. Az ERD diagramon a dobozok az egyedtípusokat, az összekötı vonalak pedig a kapcsolatokat képviselik.

256


A szállító és a számla közötti kapcsolat egy-a-többhöz (1:n) fokú, mert egy szállító több számlát állíthat ki, megfordítva egy számla határozottan egy szállítótól érkezhet. Az 1:n fokú kapcsolatokat másképpen hierarchikus kapcsolatnak is nevezik. Benne az 1-es oldalon álló egyedtípust fölérendeltnek, az n-es oldalon állót pedig alárendeltnek mondják. Az V.2. ábrán a kapcsolóvonal az alárendelt egyednél "tyúklábban" végzıdik. A szállító és a vevı közötti kapcsolat több-a-többhöz (m:n) fokú, mert azonos szállító több vevınek is szállíthat, illetve azonos vevı több szállítótól is rendelhet. Mindezt az V.2. ábrán az jelzi, hogy a kapcsolóvonal mindkét végén "tyúkláb" látható. Egy-az-egyhez (1:1) fokú kapcsolatban állhat a szállítólevél a számlával, ha a szállító minden szállítmányt külön számláz, és egy szállítmányról egy számlát állít ki. A szállító (mint a számla kiállítója) és a kiállított számla közötti kapcsolat a számla egyedtípusra nézve kötelezı, mert minden számlához kell lenni azt kiállító szállítónak; viszont a szállító egyedtípusra nézve opcionális, mert lehet olyan szállítója a cégnek, akitıl még nem érkezett számla. Az V.2. ábrán a kapcsolat opcionális végét karika jelöli. Ugyanez a kapcsolat a számla egyedtípusra nézve stabil is, mert az a tény, hogy egy számlát X szállító állította ki, akármennyi idı elteltével is tény marad. A munkaadó szervezetek és az alkalmazottak közötti kapcsolat viszont értelemszerően instabil mindkét egyedtípusra nézve. Az V.2. ábrán a kapcsolat stabil végét rövid keresztezı vonal jelöli. A hierarchikus kapcsolatok kitüntetett szerepet játszanak az adatmodellezésben. Az m:n fokú kapcsolatok mindig visszavezethetık hierarchikus kapcsolatokra. Az 1:1 fokú kapcsolatok egy része megszüntethetı a kapcsolódó egyedtípusok egy egyedtípusba aggregálásával, más része pedig egyszerően az 1:n fokú kapcsolat speciális esetének tekinthetı. Az elsı csoportba a stabil, a második csoportba az instabil 1:1 fokú kapcsolatok tartoznak. Az 1:1 fokú kapcsolatok leggyakoribb esete a fıtípus-altípus kapcsolat. Ilyen kapcsolatot alkot a tárgyi eszköz egyedtípus az ingatlan egyedtípussal. Egy ingatlan azonos egy tárgyi eszközzel. A tárgyi eszköz egyedtípus elıforduláshalmaza részhalmazként tartalmazza az ingatlan egyedtípus elıforduláshalmazát. Ezért a tárgyi eszköz képezi az általánosítást: a fıtípust; az ingatlan képezi a specializációt: az altípust. Hasonló kapcsolat áll fenn a tárgyi eszköz és a mőszaki berendezés, illetve a tárgyi eszköz és a jármő egyedtípusok között. A tárgyi eszköz három kapcsolatát reprezentáló kapcsolóvonalakat ívelt vonal metszi. Ez jelöli azt, hogy e kapcsolatok egymást kizáróak, azaz egy konkrét tárgyi eszköz nem lehet egyszerre ingatlan is, meg jármő is. Elıfordulhat az is, hogy egy egyedtípus önmagával alkot valamilyen kapcsolatot. Ezt visszamutató kapcsolatnak nevezik, de használatos még rá a rekurzív kapcsolat vagy a homogén kapcsolat megnevezés is. Ilyen kapcsolat pl. egy szervezet egységei közötti alárendeltségi viszony (X osztály alárendeltje az Y fıosztálynak, az utóbbi meg alárendeltje egy Z igazgatóságnak). Ebben a viszonyban a szervezet egyedtípus önmagával alkot 1:n fokú


257

kapcsolatot. Természetesen az "önmagával" határozó csak típusszinten igaz, ebben az esetben elıfordulásszinten nem. Az adatbázisok definíció szerinti jellemzıje, hogy nemcsak az adatokat, hanem azok kapcsolatait is tárolják (kifejezik). A különbözı típusú adatbázisok ez eltérı módon valósítják meg. Tipikusan a relációs adatbázisok sajátja a következı megoldás: Mivel egy hierarchikus kapcsolatban alárendelt egyedelıfordulás legfeljebb egy fölérendelt elıforduláshoz tartozhat, az alárendelt egyedtípus szerkezetébe beilleszthetı a fölérendelt egyedtípus azonosítója (elsıdleges kulcsa), ami minden alárendelt elıfordulásnál a fölérendelt elıfordulás azonosító értékét veszi fel. A fölérendelt egyed elsıdleges kulcsát, ha az alárendelt egyed szerkezetében megjelenik, ott idegen kulcsnak nevezzük. Ilyen idegen kulcsok a V.1. táblázat szerinti könyvelési tétel egyedtípus szerkezetében a "Bizonylatkód", a "Tartozik számlaszám" és a "Követel számlaszám" attribútumok. Történetesen a "Bizonylatkód" a könyvelési tételnek azon bizonylattal való kapcsolatát mutatja, amelyik a tétel forrása volt. A "Tartozik számlaszám" és a "Követel számlaszám" pedig mint fıkönyvi számlaszámok a fıkönyvi számla egyedtípusból vett idegen kulcsok, bennük a (szintetikus) könyvelési tételnek a fıkönyvi számla egyedtípussal alkotott két különbözı tartalmú kapcsolata fejezıdik ki. (Lásd még a V.2. ábrát!) A V.2. ábrán a BIZONYLAT és a SZINTETIKUS KÖNYVELÉSI TÉTEL egyedek kapcsolatának jelölésében van egy hiba, amely egyszerő könyvelési ismeretek birtokában észrevehetı. – Felismerte-e már az olvasó?4

Az adatbázistervezés során a kapcsolatokhoz (pontosabban azok végeihez) ún. hivatkozásteljességi (hivatkozásintegritási) szabályok rendelhetık. Ezekkel a szabályokkal elıírhatók, hogy meghatározott helyzetekben az adatbáziskezelı rendszernek milyen mőveleteket kell visszautasítani, illetve milyen mőveleteket kell külön kérés nélkül is automatikusan végrehajtani annak érdekében, hogy az adatbázis tartalma konzisztens maradjon. – Az adatbázis konzisztens, ha ellentmondásmentes és hivatkozásteljes. A hivatkozásteljesség azt jelenti, hogy ha egy adatsor hivatkozik egy másik adatsorra (például a rendelés-adatsor egy vevı-adatsorra), akkor a hivatkozott adatsornak (példánk esetében vevı-adatsornak) is jelen kell lenni az adatbázisban.

Az adatmodell kialakítása – Normalizálás Ebben a szakaszban az egyedtípusok szerkezetének kialakítására vonatkozó olyan szabályokkal foglalkozunk, amelyek a következı feltételezések mellett optimális modellre vezetnek: 1. feltételezés: Az adatmodell valamilyen relációs adatbázissal lesz megvalósítva. Ez közelebbrıl azt jelenti, hogy az adatmodell egyedtípusaiból 4

A modell jelölése szerint a kapcsolat a SZINTETIKUS KÖNYVELÉSI TÉTEL egyedre nézve opcionális, de ez a valóságban nem igaz, mert nem létezhet könyvelési tétel forrásbizonylat nélkül. A modellezıt az zavarhatta meg, hogy vannak olyan könyvelési tételek, amelyek nem közvetlenül eredeti bizonylatról, hanem ú.n. feladásból keletkeznek, és nem volt tisztában vele, hogy a feladást rögzítı dokumentum is bizonylatnak számít.

258


táblázatok lesznek; ami azonban az adatmodellezési szempontjából lényegesebb: a relációs adatbázis-koncepciónak megfelelıen az egyedtípusok közötti hierarchikus kapcsolatokat idegen kulcsokkal fejezzük ki. 2. feltételezés: Az adatbázis egy végrehajtást támogató – on-line tranzakciókezelı (OLTP) – rendszert fog kiszolgálni, azaz dominánsan karbantartási / aktualizálási (létrehozási, módosítási, törlési) mőveleteknek lesz kitéve, az adatmodellt ennek megfelelıen kell optimalizálni. Tehát kerülnünk kell az adatok többszörös tárolását, mert abból a többszörös aktualizálás igénye következne, ami pedig lerontja az aktualizálási mőveletek hatékonyságát. E két feltételezésbıl két modellezési követelmény adódik. Az egyedtípusok szerkezetét úgy határozzuk meg, hogy m1) bennük idegen kulcsok képviseljék az egyedtípusok közötti hierarchikus kapcsolatokat, azaz egy kapcsolatban alárendelt egyedtípus szerkezetében jelenjen meg idegen kulcsként az ugyanazon kapcsolatban fölérendelt egyedtípus elsıdleges kulcsa; m2) az adatmodell minimalizálja az ismételt adattárolásból eredı redundanciát, konkrétabban: a kapcsolatok kifejezéséhez szükséges idegen kulcsokon felüli redundanciát ne tartalmazzon. Megjegyzés: Ha történetesen a 2. feltételezéssel ellenkezıleg egy (felsı)vezetıi információrendszer adatbázisát (adattárházát) terveznénk, akkor az adatbázismőveletek hatékonysága javításának célkitőzése az m2) követelmény érvényesítését nem indokolná. Ugyanis azokban a rendszerekben a lekérdezés a domináns mővelet, és a lekérdezések hatékonysága éppen a redundancia növelésével javítható. – Azonban a redundanciát minimalizáló modellnek van egy másik haszna is, nevezetesen javítja a modellezık (az adatbázistervezık) tisztánlátását. Ugyanis a minimálisat meghaladó redundanciát tartalmazó modell nehezebben elemezhetı, mert benne több, különbözı jelentéső dolog egyetlen fogalomba olvad össze. Márpedig, ha különbözı dolgok nem jelennek meg önálló fogalomként, nem jelenhetnek meg azok kapcsolatai sem, miáltal teljesen lehetetlenné válik ezen kapcsolatok elemzése is. Ezért a vezetıi információs rendszerek adatbázisának tervezésénél is gyakori megoldás, hogy elıbb elvégzik a modellezést az itt leírtak szerint, tehát az m2) követelmény érvényesítésével; majd az így kapott modellt utóbb „elrontják” a lekérdezéseket javító redundancia hozzáadásával.

Normalizálás Az m2) szerinti – minimális redundanciájú – egyedszerkezetek kialakítására szolgáló eljárást normalizálásnak nevezik. Ez az eljárás nagymértékben épít a tulajdonságtípusok között értelmezett funkcionális függés fogalomra (lásd alább). A normalizálásnak két változata van: • Az egyik a lebontás (dekompozíció) módszere, amelynél már adottak valamilyen egyedszerkezetek, amelyek azonban esetleg a minimálisnál több redundanciát tartalmaznak, azaz sértenek valamilyen megszorító (tiltó) szabályokat, az ú.n. normálforma-szabályokat. Ilyenkor a normalizálás domináns mozzanat az, hogy az adott egyedtípusokat fel-


•

259

bontják olyan egyedtípusokra, amelyek együttesen már megfelelı normálformájú modellt alkotnak. (Mellékesen megjelenhet az egyesítés mozzanata is, amikor a lebontással kapott egyedtípusok között két vagy több egyedtípusról felismerik, hogy azok tulajdonképpen azonosak, és azokból – a szerkezetük egyesítésével – egy egyedtípust alkotnak.) A másik változat a szintézis (vagy szintetikus modellezés), amelynél nincsenek elıre adott egyedtípusok, csak a tulajdonságok közötti funkcionális függések ismertek, és ezekbıl egy konstrukciós szabály segítségével eleve normalizált egyedszerkezeteket raknak össze.

Funkcionális függés Az adatmodellezésben egy A és B tulajdonságtípusok közötti viszonyt funkcionális függésnek nevezzük, ha az adott viszonyban az A bármely értékéhez legfeljebb egy érték tartozik a B-bıl. Az ilyen funkcionális függés jele: A→ →B, és szokás úgy is mondani, hogy az A-tól funkcionálisan függ B, vagy az A funkcionálisan meghatározza B-t. Megjegyzés: Ha nem csupán érintılegesen tárgyalnánk az adatmodellzést, a fogalmi tisztaság érdekében meg kellett volna különböztetni az doménekre értelmezett funkcionális függést az attribútumokra értelmezett funkcionális függéstıl, mivel a kettı némileg másképpen viselkedik.

A tulajdonságtípusok függéseit a modellezett alkalmazási területen (adott szervezetnél) érvényes viszonyok definiálják. Pl. az a tény, hogy egy adóazonosító jelhez egy állandó lakcím érték tartozik, egy adóazonosító jel → állandó lakcím funkcionális függést definiál. Látszik, hogy ez a függésfogalom nem szimmetrikus, fordított irányban nem áll fenn: azonos címen több adóalany is lakhat. Ha a függés szimmetrikusan teljesül, akkor kölcsönös függésrıl beszélünk (jelölése: A ↔ B). Például fennáll az adóazonosító jel ↔ tajszám kölcsönös függés (legalábbis doménszinten). Ha a függésben a meghatározó tulajdonság nem minden értékéhez tartozik érték a meghatározott tulajdonságból (a "legfeljebb egy" zérussal teljesül), akkor opcionális (más szóval gyenge) függésrıl beszélünk. Így opcionális például a tárgyi eszköz azonosító → helyrajzi szám függés, mert pl. a jármővekhez értelemszerően nem tartozik helyrajzi szám. Ha a meghatározó tulajdonság (több egyszerő tulajdonságból) összetett, akkor összetett függésrıl beszélünk. Ilyen összetett függés például a következı: adóazonosító jel + adóév → éves szja összege. Vegyük észre, hogy a funkcionális függés a definíciójából adódóan eleget tesz a következı két szabálynak: • Tranzitivitás: ha A→B és B→C, akkor A→C. • Projektivitás: mindig teljesül, hogy A+B→A, illetve A+B→B. (Például a vezetéknév + utónév → vezetéknév, illetve vezetéknév + utónév → utónév). Meg kell különböztetnünk a közvetlen és közvetett funkcionális függéseket.

260


Közvetlen, illetve közvetett funkcionális függés Egy modell keretein belül az A→ →B funkcionális függés közvetlen, ha a modellben nincs olyan C tulajdonság, amellyel egyidejőleg az A→C és a C→B függések úgy is fennállnak, hogy az A→C nem azonos az A↔C kölcsönös függéssel, és a C→B függés nem projekció (azaz a C nem azonos egy B+X vagy egy X+B összetett tulajdonsággal. – Minden más esetben – egy modell keretein belül – az A→ →B funkcionális függés közvetettnek számít. Ezen a ponton már minden szükséges fogalom rendelkezésre ahhoz, hogy megfogalmazzuk a korábban m2)-vel jelölt követelmény teljesítését célzó normálforma-szabályokat. Az adatmodellezés elmélete több ilyen szabályt fogalmazott meg, nevezetesen az elsı (1NF), a második (2NF), a harmadik normálforma (3NF), azután a Boyce-Codd normálforma5 (BCNF), legutoljára pedig a negyedik (4NF) és az ötödik normálforma (5NF) szabályokat. A gyakorlat azt mutatja, hogy a felsoroltak közül elegendı az 1NF és a BCNF szabályokat ismerni, amelyek a következık: 1NF: Az egyedtípus minden attribútumának funkcionálisan függnie kell az egyedtípus azonosítójától (elsıdleges kulcsától). BCNF: Az egyedtípus minden attribútumának közvetlenül függnie kell az egyedtípus azonosítójától (elsıdleges kulcsától). A fenti követelményeket kielégítı egyedtípusokat 1NF, illetve BCNF egyedtípusoknak is nevezik. Vegyük észre, hogy a BCNF teljesülésébıl logikailag az 1NF is következik, azaz elvben elegendı lett volna a BCNF szabályt kimondani. Azonban a gyakorlatban egyszerőbb a normalizálás végrehajtása, ha azt két lépésben teszszük meg: elıbb 1NF-re hozzuk a modellt, majd ezt alakítjuk át BCNF-re. Ennek két oka van: (1) Egy 1NF modellben sokkal könnyebb megállapítani az egyes egyedszerkezeteken belüli funkcionális függések közvetlen, illetve közvetett voltát. (2) Egy E egyedtípusról az 1NF-re hozás olyan egyedtípusokat bont le, amelyek az E alárendeltjei lesznek; ezzel szemben egy 1NF-ben lévı E egyedtípusról a BCNF-re hozás olyan egyedtípusokat bont le, amelyek az E fölérendeltjei lesznek. A rend kedvéért a V.3. ábra összefoglalja a dekompozíciós adatmodellezés normálforma fokozatait a közöttük lévı viszonyt is mutatva. (Az olvasó a részleges és a tranzitív függésre az V.7. ábra kapcsán kap magyarázatot.) 1NF 2NF 3NF BCNF 4NF

Minden tulajdonság funkcionálisan függ az elsıdleges kulcstól. 1NF + Nem tartalmaz részleges függést. 2NF + Nem tartalmaz tranzitív függést. Minden tulajdonság közvetlenül függ az elsıdleges kulcstól.

5NF

1NF + Nem tartalmaz olyan többértékő függést, amelyben a meghatározó tulajdonság különbözik az elsıdleges kulcstól. 1NF + Nem tartalmaz olyan join-függést, amelyben a kapcsoló tulajdonság különbözik az elsıdleges kulcstól.

V.3. ábra: A dekompozíciós adatmodellezés normálformái 5

A BCNF normálforma Boyce-ról és Coddról, a relációs adatanalízist megalapozó két matematikusról kapta nevét. Értelmezésének itteni megfogalmazása nem azonos az eredetivel, annak javított változata.


261

Eredetileg a normalizálás kettınél több lépésben végrehajtott eljárás volt: az 1NF-re hozás után elıször a közvetett függések különbözı – könnyebben felismerhetı – fajtáit küszöbölték ki a vizsgált egyedtípus szerkezetébıl. Így kapták a második, illetve harmadik normálformát. Volt idı, amikor úgy gondolták, hogy a 3NF jelenti a tökéletességet (még ma is írnak olyan „szakkönyveket”, amelyek ezt állítják), azonban amikor világossá vált, hogy a közvetett függéseknek további olyan változatai is lehetnek, amelyeket a 3NF nem küszöböl ki, az öszszes közvetett függést kizáróként definiálták a BCNF normálformát. Ma már a hagyományokhoz ragaszkodáson kívül semmi nem indokolja, hogy a normalizálás 2NF és 3NF lépéseivel is foglalkozzunk. – A 4NF és az 5NF normálformákról csak annyit jegyzünk meg, hogy ezek már nem a funkcionális függésen, hanem a többértékő függésen, illetve a joinfüggésen alapuló kritériummal különíthetık el. Mélyebben azért nem foglalkozunk velük, mert a gyakorlati jelentıségük nagyon csekély; ugyanis minden olyan BCNF egyedtípus, amely az elsıdleges kulcson (annak komponensein) kívül más attribútumot is tartalmaz, automatikusan az 5NF-et is teljesíti. (Tehát csak egy csupakulcs BCNF egyedtípusról derülhet ki, hogy az történetesen nem 5NF.)

Míg az 1NF és a BCNF szabályok inkább tiltásokat fogalmaztak meg, a szintetikus modellezés konstrukciós szabálya pozitívan arról szól, hogy milyen egyedtípusoknak kell lenni a modellben: KSz: Ha fennáll az A → B közvetlen függés akkor kell létezni (pontosan egy) olyan E egyedtípusnak, amelynek a szerkezete tartalmazza az A és B attribútumokat, és az elsıdleges kulcsa az A tulajdonság vagy egy olyan C tulajdonság, amelyre fennáll a mindkét irányban kötelezı A ↔ C kölcsönös függés. A fenti szabály némileg bonyolultnak tőnik a közbejött C tulajdonság miatt, ezért egy egyszerősítı magyarázat is jár hozzá: A mindkét irányban kötelezı A ↔ C kölcsönös függés fennállása esetén a C→B funkcionális függés is fennáll, és az is közvetlen. Ezért kell lenni egy olyan egyedtípusnak, amelynek a szerkezetében az emlegetett A, B, C tulajdonságok mindegyike jelen van, továbbá az A és a C tulajdonságok bármelyike egyenértékően választható elsıdleges kulcsnak. Tehát nem mondható ki, hogy biztosan az A lesz az elsıdleges kulcs, mert elıfordulhat, hogy a modellezı inkább a C mellett dönt.

Normalizálás lebontással Itt bemutatjuk a lebontási szabályokat alkalmazó normalizálást. Példa 1NF-re átalakításra: A V.4. táblázat az ALKALMAZOTT egyedtípus reprezentációja, benne a Törzsszám képezi az egyedtípus azonosítóját. A táblázatban csupán a Név és a Munkakör függnek funkcionálisan a Törzsszámtól, mert ezekre igaz, hogy csak egy érték tartozik belılük a Törzsszám bármely értékéhez. Ezért olyan átalakítást fogunk végezni, hogy az ALKALMAZOTT szerkezete 1NF legyen, de ne vesszen el az az információ, hogy melyik járandóságtétel mely alkalmazotthoz tartozik. Átalakítás 1NF-re: A Törzsszámtól nem függı attribútumokat egy másik táblázatba (egyedtípusba) választjuk le, így az ALKALMAZOTT (V.5. táblázat) mellett kapunk még egy JÁRANDÓSÁGTÉTEL egyedtípust is (V.6. táblázat). A Törzsszám az utóbbinak is attribútuma, éppen ezáltal ırzıdik meg az az információ, hogy melyik járandóságtétel melyik alkalmazotté. Az eredeti ALKALMAZOTT tábla három sorából a JÁRANDÓSÁGTÉTEL táblában nyolc sor keletkezett, ezért az utóbbi azonosítójául már nem a Törzsszám, hanem a Törzsszám+Kifiz.dátum+Jogcímkód összetett attribútum választható. (Ez arra az esetre is példa, amikor az idegen kulcs beépül az elsıdleges kulcsba.)

262


ALKALMAZOTT (még nem 1NF) TörzsKifiz. JogcímNév szám dátum kód 1111 AAAA 97.01.05 21 97.01.05 26 97.01.10 27 97.01.10 34 1112 BBBBB 97.01.05 21 97.01.05 34 1113 CCCCC 97.01.05 44 97.02.03 44 ... ... ... ...

Járandóság SzJA SzJA kategória összege kód neve Alapbér 50000 01 Bérjövedelem Prémium 25000 01 Bérjövedelem Külszolg. Térítés 25000 03 Külszolgálati térítés Táppénz 4000 01 Bérjövedelem Alapbér 45000 01 Bérjövedelem Táppénz 25000 01 Bérjövedelem Szerzıi jogdíj 120000 11 Szellemi alkotás jöved. Szerzıi jogdíj 10000 11 Szellemi alkotás jöved. ... ... ... ... Járandóság neve

Munkakör UUUU

UUUU GGGG ...

V.4. táblázat: Normalizálatlan ALKALMAZOTT egyedtípus ALKALMAZOTT TörzsNév szám 1111 AAAA 1112 BBBBB 1113 CCCCC ... ...

Munkakör UUUU UUUU GGGG ...

Vegyük észre, hogy az 1NF-re átalakítás (felbontás) fogalmi szinten a következık miatt hasznos:  Miután a felbontás leválasztotta az önálló JÁRANDÓSÁGTÉTEL egyedtípust, vizsgálhatókká válnak annak más egyedtípusokkal alkotott kapcsolatai is (teljesség), továbbá az ALKALMAZOTT értelmezése is tisztább lett (egyértelmőség).  Könnyebben felismerhetıkké és így elvégezhetıkké válnak a BCNF eléréséhez szükséges átalakítások.

V.5. táblázat: Normalizált ALKALMAZOTT egyedtípus JÁRANDÓSÁGTÉTEL TörzsKifiz. szám dátum 1111 97.01.05 1111 97.01.05 1111 97.01.10 1111 97.01.10 1112 97.01.05 1112 97.01.05 1113 97.01.05 1113 97.02.03 ... ...

Jogcím-kód 21 26 27 34 21 34 44 44 ...

Járandóság neve Alapbér Prémium Külszolg. térítés Táppénz Alapbér Táppénz Szerzıi jogdíj Szerzıi jogdíj ...

Járandóság összege 50000 25000 25000 4000 45000 25000 120000 10000 ...

SzJA kód 01 01 03 01 01 01 11 11 ...

SzJA kategória neve Bérjövedelem Bérjövedelem Külszolgálati térítés Bérjövedelem Bérjövedelem Bérjövedelem Szellemi alkotás jöved. Szellemi alkotás jöved. ...

V.6. táblázat: A leválasztott JÁRANDÓSÁGTÉTEL egyedtípus

Az elıbbi példa megoldásában kapott JÁRANDÓSÁGTÉTEL szerkezete nem elégíti ki a BCNF követelményt, mert több közvetett függést tartalmaz. Az V.7. ábra függési diagramjáról az alábbi közvetett függések olvashatók le: Törzsszám+Kifiz.dátum+Jogcímkód → Jogcímkód → Járandóság neve Törzsszám+Kifiz.dátum+Jogcímkód → Jogcímkód → SzJA kód Jogcímkód → SzJA kód → SzJA kategória neve A történeti hőség kedvéért, valamint az V.3. ábra egyes részeinek utólagos magyarázatául megemlítjük, hogy az V.6. táblázattal reprezentált JÁRANDÓSÁGTÉTEL egyedtípus szerkezetében, illetve az V.7. függési diagramon a közvetett funkcionális függések két olyan típusával ismerkedhetünk meg, amelyeket az adatmodellezés elmélete a legkorábban felismert, és sokáig csak ezek kiküszöbölését tartotta fontosnak. Ezek a részleges függés és a tranzitív függés. A részleges függés az A→B→C közvetett függés olyan esete, amelynél a B komponense az A-nak, a C viszont nem komponense sem az A-nak, sem a B-nek. A tranzitív függés az A→B→C közvetett függés olyan esete, amelynél semelyik attribútum sem komponense a másik kettı valamelyikének.


263

A fentebb felsorolt három konkrét közvetett funkcionális föggés közül az elsı kettı a részleges függést, az utolsó pedig a tranzitív függést példázza. Annak bizonyítására, hogy ezeken felül más típusú közvetett függések is léteznek, megemlítjük a kulcstörı függést. A kulcstörı függés az A→B→C közvetett függés olyan esete, amikor a B attribútum nem komponense az A-nak, a C viszont igen. Példa kulcstörı függésre: Ilyen függést tartalmaz egy olyan TRANZAKCIÓ egyedtípus szerkezete, amelyben az azonosító Számlatulajdonos+Mozgásszám, és fennáll benne a következı közvetett függés: Számlatulajdonos+Mozgásszám → Számlaszám → Számlatulajdonos.

Törzsszám

Járandóság összege

Kifizetés dátum

Járandóság neve

Jogcímkód

SzJA kód

SzJA kategória neve

V.7. ábra: A JÁRANDÓSÁGTÉTEL attribútumainak függési diagramja

A normalizálás folytatása: Az elızı példában kapott JÁRANDÓSÁGTÉTEL egyedtípus szerkezetében (új egyedtípusokba) leválasztással megszüntetjük a közvetett függéseket. Ezt úgy tesszük, hogy közben nem veszik el az az információ, hogy melyik járandóságtétel milyen jogcímő, és hogy az egyes jogcímek mely SzJA kategóriába tartoznak! Segítségül felhasználjuk az V.7. ábrát és a KSz konstrukciós szabályt. Az elızı példában és az itteni lépésben együttesen végrehajtott normalizálással kapott összes egyedtípus kapcsolatait az V.9. ábra mutatja.

JÁRANDÓSÁGTÉTEL(új) Törzsszám Kifiz.dátum Jogcímkód 1111 97.01.05 21 1111 97.01.05 26 1111 97.01.10 27 1111 97.01.10 34 1112 97.01.05 21 1112 97.01.05 34 1113 97.01.05 44 1113 97.02.03 44 ... ... ...

Járandóság összege 50000 25000 25000 4000 45000 25000 120000 10000 ...

Kulcs: Törzsszám + Kifiz.dátum + Jogcímkód

JOGCÍM Jogcímkód Járandóság neve SzJA kód 21 Alapbér 01 26 Prémium 01 27 Külszolg. térítés 03 34 Táppénz 01 44 Szerzıi jogdíj 11 … … … Kulcs: Jogcímkód SZJA KATEGÓRIA SzJA kód SzJA kategória neve 01 Bérjövedelem 03 Külszolgálati térítés 11 Szellemi alkotás jövedelme … … Kulcs: SzJA kód

V.8. ábra: A JÁRANDÓSÁGTÉTEL egyedtípus lebontásával BCNF egyedtípusok

264


SZJA KATEGÓRIA

ALKALMAZOTT

JOGCÍM

JÁRANDÓSÁGTÉTEL

V.9. ábra: A normalizálással kapott egyedtípusok kapcsolatai

A JÁRANDÓSÁGTÉTEL felbontása (BCNF-re hozása) kapcsán meg tudjuk mutatni, hogy a közvetett függések kiküszöbölésének elve nem egy öncélú szabály, az alkalmazásának jól megfogható gyakorlati hasznossági indoka van. Az V.8. ábra szerinti felbontás a következı haszonnal jár: h1) Miután a JOGCÍM egyedtípust és az SZJA KATEGÓRIA egyedtípust leválasztottuk a JÁRANDÓSÁGTÉTEL egyedtípusról, egy konkrét jogcímet vagy SzJA kategóriát, anélkül is nyilvántarthatunk, hogy létezne reá vonatkozó konkrét járandóságtétel. h2) Az eredeti JÁRANDÓSÁGTÉTEL táblából valamely konkrét jogcímre (vagy SzJA-kategóriára) vonatkozó utolsó járandóságtételt is törölve, elveszik a nyilvántartásból az adott jogcím (vagy SzJA-kategória is). A felbontás után ezek a gondok megszőnnek. h3) Az eredeti JÁRANDÓSÁGTÉTEL táblában a járandóság (jogcímének) nevét vagy az SzJA kategória nevét sok helyen kell nyilvántartani, így egy esetleges változtatáskor többszörösen kell aktualizálni is. A felbontás után ezeket csak egy helyen kell módosítani. h4) A JOGCÍM és az SZJA KATEGÓRIA egyedtípusok más egyedtípusokkal is alkothatnak kapcsolatokat, ezek azonban a felbontás elıtt nem fedezhetık fel és nem vizsgálhatók, mert még a kapcsolódó egyedtípusok sem léteznek önállóan, csak a JÁRANDÓSÁGTÉTEL-be rejtve. A h1)h3) tények éppen annak a megnyilvánulásai, hogy a normalizálás az aktualizálási mőveletekre (nyilvántartásba vételre, törlésre, módosításra) tekintettel optimalizálja a modellt. A h4) pedig azt példázza, hogy a normalizálás elısegíti a tisztánlátást, könnyebben ellenırizhetıvé teszi a modell egyértelmőségét és teljességét.


265

Normalizálás szintézissel A következı keretezett rész egy olyan adatmodellezési feladatot mutat, amelyet a normalizálás szintetikus változatával vagyis a közvetett függésekbıl kiinduló konstrukciós szabály (KSz) alkalmazásával lehet megoldani. Egy normalizálási feladat kiinduló állapota a szintézis alkalmazása esetén: Az alábbi függések egyidejőleg állnak fenn. A függések és bennük szereplı tulajdonságtípusok felhasználásával kell kialakítani a normalizált (BCNF) adatmodellt. 1. Számlasorszám + Tételsorszám Mértékegység 14. VT-szám VTSZ megnevezés 2. Számlasorszám + Tételsorszám Mennyiség 15. Árazonosító Termékkód 3. Számlasorszám + Tételsorszám Tételérték 16. Árazonosító Egységár 4. Számlasorszám + Tételsorszám Partnernév 17. Árazonosító VTSZ megnevezés 5. VTszám + Érvényesség kezdete ÁFA mérték 18. Partnerkód Partnernév 6. Termékkód VT-szám 19. Számlasorszám Partnerkód 7. Számlasorszám + Tételsorszám Termékkód 20. Termékkód VTSZmegnevezés 8. Számlasorszám Teljesítés dátuma 21. Számlasorszám Fizetési mód 9. Számlasorszám Fizetési határidı 22. Termékkód Terméknév 10. Számlasorszám + Tételsorszám + Szövegsorszám Terméknév 11. Számlasorszám + Tételsorszám + Szövegsorszám Tételszöveg 12. Számlasorszám + Tételsorszám VTSZ megnevezés 13. Számlasorszám + Tételsorszám + Szövegsorszám Fizetési határidı

Számolni kell azzal, hogy az adott függések között esetleg közvetettek is vannak, ezeket a KSz alkalmazása elıtt ki kell szőrni. A közvetett függéseket azon függések között kell keresni, amelyekben a függı tulajdonság más főggésekben is függı szerepben fordul elı. A közös függı tulajdonságok miatt példánkban az alábbi függésekre vetül a közvetettség gyanújának árnyéka: 4. Számlasorszám + Tételsorszám Partnernév 18. Partnerkód Partnernév 7. Számlasorszám + Tételsorszám Termékkód 15. Árazonosító Termékkód 9. Számlasorszám Fizetési határidı 13. Számlasorszám + Tételsorszám + Szövegsorszám Fizetési határidı 10. Számlasorszám + Tételsorszám + Szövegsorszám Terméknév 22. Termékkód Terméknév 12. 14. 17. 20.

Számlasorszám + Tételsorszám VTSZ megnevezés VT-szám VTSZ megnevezés Árazonosító VTSZ megnevezés Termékkód VTSZmegnevezés

A fenti felsorolás az eredeti sorrendtıl azért tért el, hogy a közös függı tulajdonságot tartalmazó függések egymás mellé kerüljenek.

Azonban nem minden „gyanús” függés közvetett, mert egyazon függı T tulajdonság olyan okból is megjelenhet több függésben, hogy ez a T elsıdleges kulcsa egy egyedtípusnak, amely pedig közös fölérendeltje több más egyedtípusnak. Tehát a „gyanús” függések közvetettségét további elemzéssel kell bizonyítani.

266


A „gyanús” függések közül csak a következıkrıl bizonyítható, hogy valóban közvetettek. 4. Számlasorszám + Tételsorszám Partnernév 10. Számlasorszám + Tételsorszám + Szövegsorszám Terméknév 12. Számlasorszám + Tételsorszám VTSZ megnevezés 13. Számlasorszám + Tételsorszám + Szövegsorszám Fizetési határidı 17. Árazonosító VTSZ megnevezés 20. Termékkód VTSZmegnevezés A fenti függések közül csak 4-re és a 13-ra mutatjuk meg a közvetettség bizonyítását, a többinél ezt az olvasóra bízzuk. 4. bizonyítása: A funkcionális függések projektív tulajdonságából, a 19. függésbıl, valamint a 18. függésbıl kapjuk: Számlasorszám + Tételsorszám Számlasorszám Partnerkód Partnernév 13. bizonyítása: A funkcionális függések projektív tulajdonságából és a 9. függésbıl kapjuk: Számlasorszám+Tételsorszám+SzövegsorszámSzámlasorszámFizetési határidı

A közvetett függések kiejtése után a maradék függéseket felhasználva és a KSz-t alkalmazva módszeresen kialakíthatók az eleve BCNF szerkezető egyedtípusok. A megmaradt (közvetlen) függésekbıl a következı egyedtípusok adódnak: SZÁMLATÉTEL (Számlasorszám + Tételsorszám, Mértékegység, Mennyiség, Tételérték, Termékkód) ÁFAMÉRTÉK (VTszám + Érvényesség kezdete, ÁFA mérték) TERMÉK (Termékkód, VTszám, Terméknév) SZÁMLAFEJ(Számlasorszám, Teljesítés dátuma, Fizetési határidı, Partnerkód, Fizetési mód) TÉTELSZÖVEG (Számlasorszám + Tételsorszám + Szövegsorszám, Tételszöveg) VTSZ (VTszám, VTSZmegnevezés) TERMÉKÁR (Árazonosító, Termékkód, Egységár) PARTNER (Partnerkód, Partnernév)

2.3.3. Dinamikus modellezés

2.3.4. Az ember-gép párbeszéd tervezése

2.4. Kivitelezés és az egységtesztek


2.5. Szoftverintegráció, rendszerintegráció és az integrációs tesztek 2.6. A rendszer bevezetése 2.7. A szoftverfejlesztés támogató folyamatai

267

268


3. Információs rendszer mőködtetése – üzemeltetés- és szolgáltatásmenedzsment


4. Informatikai biztonság

269

V. rész: Az információtechnológia menedzselése

Recommend Documents