A modellezési hibák gyökerei

6.2.9 A példa megoldása

Az olvasónak most megadjuk a 6.1 példa helyes megoldását:

TULAJDONOS

Törzsszám Tulajtípus Tulajnév Foglalkozás Telephely Felügyelet 111111 Magán Kovács R. Ápolónő Á Budapest -

222222 Kft AB Kft. - Szeged -

333333 Magán Kovács R. Mérnök M Pécs -

444444 Rt XY Rt. - Budapest Z

KOCSI KOCSITÍPUS

Rendszám Kocsitípus Törzsszám Tárolóhely Kocsitípus Férőhely

ABC 134 Lada 111111 Budapest BMW 5 fő

BCD 265 BMW 222222 Szeged Lada 5 fő

DEF 896 Lada 333333 Pécs Polski 4 fő

FGH 333 Polski 444444 Veszprém KÁR KÁR/KOCSI

Kárszám Dátum Kárszám Rendszám Kárösszeg

23000 99.05.14 23000 ABC 134 X

34000 99.06.06 23000 BCD 265 Y

45000 99.06.30 34000 DEF 896 Z

45000 ABC 134 Q

6.8 ábra: A hibákat kiküszöbölő adatmodell

Magyarázat: A járatlan olvasó számára a 6.1 ábra példája az első áttekintésre nem is tűnt annyira rémesen rossznak. A fejezet során kiderült, hogy jóformán nincs egyetlen egy ép porcikája sem. Pedig az összes problémát nem is tártuk fel. Az olvasónak remélhetőleg feltűnt, hogy a volt KÁR egyed negyedik sorában megjelenő dátum - 99.06.31 - helytelen, megenged-hetetlen értéket tartalmaz. Azt, hogy miképpen lehet eljutni az itt mutatott jó megoldásra, majd a következő fejezetek során fejtjük ki.

Kérdés: Lehet, hogy a 6.8 ábra modellje nem teljes? Nem kellene kódolni a Tulajtípust létrehozva egy TULAJDONOSTÍPUS egyedet?

Válasz: Először is a kódolás nem fogalmi szintű kérdés. Másodszor a tervezők túlzottan gyakran alkalmaznak „kódegyedeket”, holott egyednek az ismerettel leírni kívánt dolgot nevezzük. A kocsitípust saját ismeretekkel írtuk le, de nem is „kódegyeddel” tükröztük! Ha csak az értékkészlet ellenőrzésére van szükség, akkor nem kell létrehozni új egyedet, hanem az általános tulajdonság fogalmi tényezőjéhez kell fordulni (Értéktartomány).

segítségével készült „adatmodelleket”, amelyek minden szempontból megsértik az optimum-kritériumokat. Ennek a helytelen modellezési szemléletmód az oka. Nincs az az eszköz, technika, módszer, amely garanciát nyújtana a hibák ellen. A tervezőnek négy ponton kell szemléletmódot váltania, ha optimális adatmodellt óhajt készíteni.

6.3.1 Nézetvakság

A fejlesztők nem figyelnek a gyakorlatban az absztrakciós vetületek elméletére. Nem a valós jelenségeket tükrözik az adatmodellben, hanem azt, ahogyan a valóságot az őket éppen aktuálisan megbízó felhasználó látja. A 6.1 ábra KÁR egyede a káreseményekben érdekelt ügyintéző oldaláról nézi az összefüggéseket („kár ∏ kocsi”). Az eszébe sem jut, hogy lesz majd olyan alkal-mazás is - vagy már folyik is a fejlesztése -, amelyben pont az ellentétes irányú („kocsi ∏ kár”) nézet dominál. Eláruljuk, hogy a vonatkozó ábra példája azért olyan rossz, mert három egymástól független szervezeti egység dolgozta ki a tervet, egymásról nem is tudva. Csak mi toltuk az egyedeket egymás mellé, didaktikai okokból.

A bajokon a CASE használata semmit sem segít. Az egymástól független projekteket a segédletekben teljesen szeparáltan lehet dokumentálni, ezért nincs integráló erő. Csak egy dolog óvhat meg bennünket a teljesen rossz tervektől. Ha elsajátítjuk az alábbi szabályt:

−− −

−

Magyarázat: Erre az axiómára már utaltunk. Azonban nem győzzük hangsúlyozni a korrekt szemlélet elsajátításának a fontosságát. Erre két szinten van szükség. Egyrészt az egyéni fejlesztő a 12.8 ábra helyes megoldására akkor is el tud jutni, ha nem látja más felhasználók igényeit. Csak annyit kell tennie, hogy a valóságot modellezi (külön a kárt, a kocsit, a tulajdonost), nem pedig annak adott nézetét (a kárt és a kocsit egyben). Másrészt a kollektív fejlesztésben kerülni kell a párhuzamosságokat. Nem megengedhető például az, hogy öt részleg ötféle partnernyilvántartást alakítson ki.

Kiegészítés: Az egyféle modell nem zárja ki a többféle megvalósítást, vagyis adatbázist.

6.3.2 Szintkeverés

A legtöbb adatbáziskezelő rendszer strukturálási képességei korlátosak. Ugyanakkor az adat-bázis sémájában megkövetelik, hogy együtt adjuk meg a logikai szintű (tartalmi) és a fizikai szintű (ábrázolási, indexelési stb.) jellemzőket.

Ez a kettős tény arra ösztönzi a fejlesztőket, hogy azonnal a korlátos szerkezetekben gondolkodjanak és azonnal a tárolási/formai paramétereknek megfelelően lássák maguk előtt a tényezőket. Még nincs is jól strukturált tervük, de máris kijelentik, hogy például a Számlaszám a Vevőkód+Relatív sorszám együttese lesz 9 numerikus jelben és a tételre indexet fognak húzni.

Elfeledkeznek a következő axiómáról:

Attól, hogy modellnek nevezzük a jelentést, a tartalmi elrendezést és a megvalósítási formát összekeverő tervünket, az még nem lesz valódi modell. Ha a fenti elvet nem tartjuk be, akkor helytelen szemléletünk két alapvető problémát fog okozni.

Vannak olyan struktúrák (visszamutató kapcsolat, csoport, szerepnév, altípus), amiket a kezelő nem vagy nem megfelelően támogat. Ha ezeket magukat nem rögzítjük sehol sem, hanem azonnal egyféle saját megoldást alkalmazunk, akkor a legkisebb modellváltozás is kín lesz a saját magunk illetve utódaink számára. Mert nem lehet tudni, hogy milyen eredeti problémát oldottunk meg az adott módon.

Az optimumkritériumok sem vizsgálhatók a vegyes logikai/fizikai szintű terven, hiszen az már mesterséges - az eredeti természeteseket elrejtő/eltorzító - tényezőket is tartalmaz. Optimalizálni a szó modellezési értelmében csak fogalmi szintű tervet lehet. Aki tehát lemond a tisztán fogalmi modell megalkotásáról, az nem törődik a terv jóságával sem.

6.3.3 Szerepkörtévesztés

A fejlesztéseknek három résztvevője van: vezető, felhasználó és fejlesztő. Nevük azt sejtetné, hogy mindegyik adott szerepkört lát el a fejlesztésben. A vezető elrendeli, majd erőforrásokkal támogatja a fejlesztést, végül ellenőrzi annak eredményét. A felhasználó a maga laikus módján megfogalmazza az igényeit és várja a megfelelő kiszolgálást. Végül a fejlesztő informatikai megoldásra konvertálja az adott igényeket a követelmények szerint. Ezzel az ideális képpel szemben a valóság a következő:

A vezető beleszól a modell apró részleteibe is. Ez a kisebbik baj. Nagyobb az, hogy igen sokszor ő maga hozza meg az integrálás elleni döntéseket. Megengedi, hogy a főkönyvelő saját partner-nyilvántartást vezessen, eközben megbíz egy külső céget szintén a partnerek adatainak a kidolgozásával, miközben folyik a szerződésekkel kapcsolatos projekt, amiben természetesen egy harmadikféle partnerismeretsort dolgoznak ki.

A felhasználó nem tudja kifejteni az igényeit, mert nincsen tisztában azon fogalmakkal, amelyek saját munkaköre ellátásához nélkülözhetetlenek. Saját maga talál ki olyan új kódokat - osztályozási ismérveket, azonosítókat -, amelyek teljesen ellentmondanak a már létrehozott adatbázis szerkezetének, tartalmának és formájának. Ragaszkodik ahhoz, hogy az állományok struktúrái az ő egyéni szemléletmódját tükrözzék.

A fejlesztő nagyon sokszor nem problémát old meg, hanem szoftvert alkalmaz. Nem az köti le a figyelmét, hogy miképpen kellene optimálisan kialakítani egy modellrészletet, hanem az, hogy az eszköz milyen technikai megoldásait fogja bevetni. Emellett kitalál olyan adatokat, állomá-nyokat, megoldásokat, amelyek csakis az ő kényelmét szolgálják.

Ezeken a szemléleteken változtatni kellene.

−

−−

−

Nem jó, ha a fejlesztő túl hamar utasítja el a felhasználót „az úgy nem lehet” jelszóval illetve ha magától próbál meg kitalálni új tényezőket. Nem szerencsés, ha a felhasználó nem látja be, hogy adott esetben a fejlesztő bizonyos korlátos megoldásokra kényszerül vagy ha - éppen meg-fordítva - ő kényszerít ki szuboptimális modellrészleteket. Létezik egy célszerű munkamegosztás, de a modell optimalitásáért minden szereplő együtt felelős.

6.3.4 Bemenet/kimenet szemüveg

A fenti három problémakör egy közösben is ötvöződni szokott annak következtében, hogy a fejlesztés résztvevői nincsenek tisztában az adatmodellezés szakmai lényegével. Ez főleg abban mutatkozik meg, hogy a felhasználó - de olykor a fejlesztő is - papírokban gondolkodik, nem pedig valós jelenségekben.

A 6.1 ábra KOCSI egyedének az alkotója bemenetorientált tervet készített. Elétették a kocsi nyilvántartási papírját (ami voltaképpen egy inputbizonylat) és ő arról átvette az adatokat függet-lenül attól, hogy a tulajdonos és a kocsi két valós lényeg. Az ilyen tervben mindig nagymérvű lesz a fizikai redundancia, mert hiszen egy tulajdonosnak több kocsija is lehet, tehát a tulajdonos ismeretei kocsinként megismétlődnek.

A 6.1 ábra KÁR egyede tipikus kimenetorientált tervrészlet. A felhasználó olyan statisztikai kimutatást akart, amely kocsitípus szerint összesíti a károkat. A fejlesztő pedig átvette a nézetét.

Elfelejtette, hogy holnap a kapacitás, holnapután pedig a férőhely vagy a gépkocsi színe szerinti kimutatást fognak kérni. Mivel egyensúlytalan szerkezetet alkotott ( Kiegyensúlyozatlanság), a strukturális átalakítások elkerülhetetlenek.

−

−−

−

A papírokon lévő ismeretek - ritka kivételtől eltekintve - rejtett hierarchikus vagy hálós szerkezeteket alkotnak. A fenti szabály nem azt mondja ki, hogy a modellt a bemeneti és a kimeneti igényektől függetlenül kell megalkotni, hiszen az lehetetlen. Hanem azt, hogy a modell szerkezetének kell önállónak lennie. A tervezőnek az a feladata, hogy a mondott rejtett összetett szerkezeteket feltárja és azok elemi tényezőiből építse fel a modellt. Ezt csak akkor tudja megtenni, ha modellezőszemüvegét veszi fel, vagyis elsajátítja a szabály által sugallt szemléletet.