5. MODELL, TERV, SZÓTÁR
5.5 Adatmodell és adatbázisterv
−
−−
−
Az adatmodell nem adatbázisterv, hanem annak csak alapja.Magyarázat: Nagyon sokan élnek abban a félreértésben, hogy amikor ők adatmodellt készíte-nek, akkor ezzel összeállítják az adatbázis tervét is és megfordítva, amikor adott eszközzel adat-bázistervet alkotnak, akkor adatmodellezést hajtanak végre. Mindez azt mutatja, hogy nincsenek tisztában a tervezési síkokkal ( Absztrakciós szintek). Mivel pedig a legtöbb tervezési segédlet is ezt a hamis benyomást kelti, nem kerülhetjük el, hogy a két lényeg viszonyát alaposabban körüljárjuk.
5.5.1 Hatókör
−
−−
−
Az adatmodell - térben és időben - mindig egy. Az adatbázis több is lehet.Példa: Az X segédlettel valaki elkészíti a könyvelés információs rendszerének a tervét. Tőle teljesen függetlenül másvalaki ugyanezzel az eszközzel összeállíthatja a szerződések
Probléma: Az ismeretek egy része funkciókhoz kötött. A funkciókat pedig általában meghatá-rozott szervezeti egységek hajtják végre. Az informatikai fejlesztések többnyire a funkciókat, kevésbé szerencsés esetben az egységeket szolgálják ki. (Ez azért nagyobb baj, mert hasonló funkciókat több egység is elláthat.) A fejlesztés közben nem figyelnek arra, hogy az ismeretek másik része (vö. Partner) funkciótól/egységtől független lényeg. Ezért a partneradatokat tárol-hatják ugyan több fizikai adatbázisban is, de csak azután, ha a közös fogalomról egységes képet (modellt) alakítottak ki.
Példa: A biztosítási rendszerben a Szerződésszámot Körzetkód+Sorszám összetételként határozzák meg.
Probléma: Az azonosítónak tértől és időtől független lényegnek kellene lennie. Mármost ha a szerződést az egyik körzet átadja a másiknak (ami gyakran előfordul), akkor a kulcs megváltozik és maga a jelenség előbb-utóbb követhetetlenné válik. Tehát nem az a baj, hogy nincs egyetlen központi adatbázis, hanem az, hogy a lokális adatbázisok (több) nem követnek közös modellképet (egy). Azért nem, mert az ismeretek földrajzi helyhez és/vagy időtartamokhoz kötöttek.
Példa: Egy rendőrségi információs rendszerben senki sem akarta megérteni, hogy magát a rendőrt is személyként - bár sajátosként - kell modellezni.
Probléma: A rendőr is bűnözővé válhat. Ha kettős, egymástól szétválasztott ismeretsort veze-tünk róla, akkor redundáns, inkonzisztens, nehezen kezelhető adatbázishoz jutunk. Azért, mert nem látjuk meg a többen (adatbázis sík) az egyet (adatmodell sík). Vagyis nem alkalmazzuk korrekten a szemléletek lehetőségét ( Absztrakciós vetületek), hanem eleve nézetorientált terveket készítünk.
Összegzés: Az adatmodell a közös és tartós tényezőket tükrözi. A két jelző összefügg: ami ma még nem közös, az holnap már az lehet. A nem-közös és nem-tartós vonások alapján létre-hozhatunk funkcionális, szervezeti, területi, időleges adatbázisokat. Ez csak akkor nem jár totális dezintegrációval, ha van egyetlen integráló erejű adatmodellünk.
5.5.2 Szint és nézet
−
−−
−
Az adatmodellezés a globális nézetű fogalmi szintre irányul. Viszont az adatbázis logikai/fizikai szintű, adott esetben parciális nézetű lényeg.Példa: Ha valamit eladunk egy vevőnek, akkor általában számlának nevezzük a dolog közvetlen következményét. „Modellünkben” vevő és számla egyedtípusokat alkalmazunk.
Probléma: Ez a megközelítés se nem fogalmi szintű, se nem globális nézetű. Nem globális nézetű, mert a raktáros, a piackutató stb. is érdekelt az eladott cikk/szolgáltatás nevében, darab-számában stb., de egyikük sem igazán kíváncsi a könyvelési/elszámolási vonzatokra. A „számla”
szó csak a könyvelő nézetének felel meg. Kétségtelen tény, hogy az adás/vétel számlával is jár. A fogalmi szintű lényeg azonban nem ez, hanem az, hogy eladás történt. Vegyük észre, hogy mindez nem játék a szavakkal. A mérnök műszaki objektumnak nevezi ugyanazt a dolgot, amit a közgazda vagyontárgynak hív. A kétféle nézet miatt két adatbázist alakítanak ki, holott pl. egy épület mindig azonos önmagával.
Példa: Az egyik alkalmazásban a számlát a Számlaszám azonosítja, amit sorszámként kezel-nek. A másikban azt a Vevőkód+Relatív sorszám párosaként határozzák meg. A Vevőkód karak-teres, mnemonikus - emlékeztetően rövidítő - adat.
Probléma: Az adatnak van jelentése, tartalmi elrendezése és formátuma. Ugyanaz a lényeg (jelentés - fogalmi szint) számtalan eltérő módon rendezhető el és önthető alakba (logikai és fizikai szint). Az adatmodellben tökéletesen lényegtelen, hogy a számlaszámot karakteresen vagy numerikusan ábrázolják-e. Csak az a fontos, hogy a számláknak kell, hogy legyen egy egyértelmű azonosító tulajdonsága. Viszont az adatbázistervben le kell írni, hogy a Számlaszám pl. hatjegyű numerikus adat.
Példa: A biztosítási adatbázisban az ügynök neve 30, a biztosítotté 40 karakteres.
Probléma: Az ügynök maga is biztosított. Nem tisztázták a fogalmak összefüggéseit, hanem azonnal logikai/fizikai szintű tervezésbe fogtak. Biztosan korszerű segédlettel...
Összegzés: Az adatmodellezés a fogalmak lényegének a megértésére irányul. A fogalmi szinten kell belátni, hogy az ügynök és a biztosított egyaránt - partner, tehát közös lényeg. Az adat-bázistervezés jó esetben a már elrendezett fogalmaknak a tartalmi (logikai szint) elrendezésére és a formai részletezésére (fizikai szint) törekszik. Rosszabb esetben a fogalmi összefüggések tisztázása nélkül azonnal a „rekordképek” leírásával kezdődik.
5.5.3 Alapegység
−
−−
−
A modellt mindig természetes elemi tényezők alkotják. Viszont a tervben szerepelhetnek mesterséges és összetett alkotóelemek is.Példa: Ismét hivatkozunk a Számlaszám = Vevőkód+Relatív sorszámra mint kulcsra.
Probléma: Egyáltalán nem baj, ha az adatbázistervben ilyen összetételű azonosítót alkalma-zunk. Baj az, ha a tervben a Számlaszám tétel összetétele rejtett (implicit) marad, mert sehol nem fejtjük ki (expliciten) az összefüggéseket. Nagyon sokszor előfordul, hogy egy adatbázistervből egyszerűen nem lehet kiolvasni a lényegi viszonyokat, mert a nevek alá rejtik a különböző tar-talmakat. Az ember nem érti, hogy a számla hogyan kapcsolódik a vevőhöz, mire az „adatbázis-tervező” közli, hogy a számlaszámban benne van a vevőkód is. A probléma lényege az, hogy az ilyen tervező azonnal adatban, nem pedig jelentésben, fogalmakban gondolkodik és fogalmazza meg elképzeléseit.
Példa: A Személyi szám első karaktere adott értékek esetén a nemre, mások esetében a származási helyre és/vagy a születés évszázadára utal.
Probléma: A logikai/fizikai tervezési szinteken a fejlesztő az adatokon takarékoskodik (amivel
gondolkodni. Előbb látni kell a nem, a származási hely, a születési évszázad lényegét, csak azután lehet eltöprengeni a technikai megoldáson.
Példa: A személy fájlban a férfit F, a nőt N értékkel kódolják. A származási ország meg-jelölésére egy háromkarakteres egyezményes kódot alkalmaznak.
Probléma: Egyesek teletűzdelik a fogalmi modellt kód-megnevezés párosokat kifejező úgymond egyedtípusokkal. Ez alapvető hiba. Ha a nemet és a származási országot senki nem akarja érdemi ismeretekkel leírni, akkor azok nem tekinthetők egyedeknek. A nem kódja és az ország kódja pusztán csak mesterséges adatok. Mint ilyenek a logikai/fizikai adatbázistervezés szintjére tartoznak. Fogalmi szinten csak annyit kell tudnunk, hogy a „nem” fogalom természetes lényege szerint az emberek nők vagy férfiak. Ha akarjuk, az ismeretet kódoljuk. Ha kódoljuk, akkor azt megtehetjük ezerféle módon. Mindez már nem a fogalmi modellezés gondja, mert hatékony-sági/ábrázolási megfontolásokról van szó.
Kivétel: A településkód is mesterséges adat. Azonban ennek nem egyetlen célja a méret csökkentése, ha egy ismeretekkel leírandó jelenség - a TELEPÜLÉS - azonosítására is szolgál. A nominális kulcsok ( Azonosító) a legtöbb esetben ilyen mesterséges tényezők.
Összegzés: Az adatbázistervező ezernyi ok miatt és módokon különböző mesterséges és összetett adatokat alkalmazhat. Sőt, ezt meg is kell tennie. Azonban egyrészt a célszerű megoldáshoz neki is tisztában kell lennie az elemi és természetes fogalmak lényegével. Másrészt az semmiképpen sem engedhető meg, hogy a fogalmi-logikai leképezés rejtve maradjon és valakiknek utólagosan és nagy kínnal kelljen visszafejtenie azt, hogy az adatbázistervben az X valójában azt jelenti, hogy ... , valójában úgy összetett, hogy ... stb.
5.5.4 Tartalmi kör
−
−−
−
A fogalmi modell és az azt megvalósító adatbázisok egymással metszet viszonyban állnak.Magyarázat: A fogalmi adatmodell és a logikai adatbázisterv egyaránt tényezőknek a szervezett együttese, de a két tényezőkör nem azonos. Az adatmodellben vannak olyan elemek is, amelyek nem szerepelnek az adatbázisban és megfordítva, az adatbázisban léteznek olyan tényezők is, amelyek nem kerülnek modellezésre. Az előző alpontban már volt szó egy ilyesfajta jelenségről, a mesterséges kódokról. Ebben az alpontban a további különbségekre hívjuk fel a figyelmet.
Fogalmi tényezők: A legtöbb tervezési segédlet módot ad arra, hogy meghatározzuk az egyedek közötti kapcsolatokat. A relációs adatbázisokban a kapcsolat nem önálló lényeg: például az adatkezelés során nem lehet rá névvel hivatkozni. A kapcsolat adattételekben ( Kapcsoló-tulajdonság) testesül meg úgy, hogy bizonyos korlátok ellenőrzését váltja ki. Hasonlóképpen fogalmi szinten lényeges strukturális tényező a csoport és a szerepnév, de logikai szinten egyik sem nyilvános (explicit), hanem rejtetten (impliciten) valósul meg.
Logikai tényezők: Az adatbázisokat gyakran kötegelten dolgozzák fel. A bemenetekből a validálás kedvéért képeznek kötegeket. A kimeneteket kiíratás előtt így-úgy rendezendő kötegek-ben gyűjtik. Többszörös további műveletek esetén a kezelés közben leválogatott adatokat olykor
átmenetekben tárolják. A be-, át- és kimenetek maguk is adatállományok. Ezeket is meg kell tervezni, vagyis meg kell határozni a tábla- azaz rekordképeiket. Ezért az adatbázisterv egésze felöleli a felsorolt tényezők struktúráit is.
Azonban világos, hogy ezek a dolgok nem képezhetik az adatmodell részét. A bemenet nem tükröz(het) más fogalmi lényeget, mint a modellben lévő egyedek. Az abban tárolt ismeretek az érdemi egyedek tartalmaihoz képest redundánsak (pl. a partner bemeneten a partner egyed adatai találhatók). Ráadásul a bemenet - de főleg a kimenet - nem is a valós egyedeket tükrözi, mert több egyednek néhány tulajdonságát ölelheti fel. A „...menetek” nem a valós jelenségek tükörképei, hanem az adott feldolgozás jellegéből adódó technikai megoldások. Lehet „modellszerűen”
tervezni azokat is, de nem a modell alkotórészei.
Technikai tényezők: Az adatbázisokban gyakran felvesznek olyan állományokat illetve mező -ket, amelyek a kezeléstechnikával kapcsolatosak. Ezek rendkívül sokfélék lehetnek. Utalhatnak a kiíratás módjára; arra, hogy megtörtént-e és mikor a kiíratás; mikor és ki ellenőrizte utoljára a tartalmat; ki és hogyan rögzítette az adatot; ki tette a bizonylatot a levéltárba és hová; stb. stb. Ide sorolhatjuk a biztonsági/hozzáférési ismereteket is. Például azt, hogy ki és milyen módon jogosult bizonyos adatok kezelésére.
−− −
−
Az adatmodell nem tartalmazhat technikai adatokat.Magyarázat: Természetesen megint csak igaz, hogy a felsorolt és egyéb tényezőknek is el kell készíteni a tervét. Méghozzá az adatmodellel összhangban, mert például miközben a felhasználó valós egyed is, rá hivatkozni kell tudni a jogosultság technikai táblájából is. A fenti szabály azt mondja ki, hogy az érdemi ismereteket (adatmodell) el kell választani a technikai/mened-zselési/adminisztrációs adatoktól (technikai adatbázisrész).
Nem szabad például a Partner egyed tulajdonságaként felvenni az Utolsó kiírás adatot. Ezt a megkötést több érv támasztja alá. Ad 1) Nemcsak a partnerek, hanem a szerződések adatait is ki kell írni. Ezért ki tudja hány egyedben lesz Utolsó kiírás adat. Ad 2) Maga a kiírás egy technikai esemény, amit éppen ezért egy külön technikai táblában kell vezetni. Ad 3) Ezt azért is meg kell tenni, mert általában a technikai adatok többszörösek. Erre utal az „utolsó” jelző is.
Kiegészítés: Az adatmodell és az adatbázisterv tartalmi köre még további tényezőkben is eltér egymástól. Lásd a következő pontot.