Modellezési technikák

Bachman-ábra

A Bachman-ábra számos, kissé eltérő rajzváltozatban használatos, és általában az éppen rendelkezésre álló tervezőeszköz szabja meg, hogy melyik (al)változatot használjuk. Az ábrázolás lényege az egyedtípusok, azok fontosabb tulajdonságtípusainak, illetve az egyedtípusok közötti kapcsolatoknak az ábrázolása. A kapcsolatok puszta tényén túl a kapcsolat két jellemzőjét (vö. metaadatok) ábrázoljuk. Ezek a kapcsolat számossága és kötelezősége, mindkét irányban.

Fölmerül a kérdés, hogy miért pont a számosság és a kötelezőség a fontos jellemzője a kapcsolatnak.

Például azért, mert más-más keresési eljárásokat lehet alkalmazni abban az esetben, ha biztos, hogy létezik a keresett adat, mintha megengedjük annak lehetőségét, hogy esetleg nincs a feltételnek megfelelő elem. Ugyancsak nem mindegy, hogy a létező adatból csak egyetlen példány lehet, vagy esetleg több is. A keresések iránt mélyebben érdeklődőknek ajánlom szíves figyelmébe Knuth kiváló könyvét, amelyet már a Fizikai terv c. részben is szó volt.

Például azért, mert ezen jellemzők szoros kapcsolatban vannak az adatbázis szerkezeti épségével. Egy példával élve: egy videotéka esetében a kölcsönzések között nem szerepelhet olyan tétel, amely szerint nem létező tag kölcsönzött esetleg ugyancsak nem létező DVD-t.

Az alábbi ábrán két egyedtípus rajzjele látható. Az első ET neve TULAJDONOS, tulajdonságtípusai a Tulajkód, Tulajnév, Születési hely, Születési idő, Anyja neve és Lakcím. A Tulajkód, illetve a Rendszám aláhúzása jelzi, hogy az a TT az elsődleges kulcs (azonosító). A második ET neve KOCSI, tulajdonságtípusai a Rendszám, Szín, Tulajkód és Évjárat. A pont-pont-pont azt jelzi, hogy lehetnek még további leíró tulajdonságai is, azonban nem akarjuk bonyolítani velük az ábrát. A szaggatott vonallal aláhúzott Tulajkód idegen kulcs (azaz máshol elsődleges kulcs, itt kapcsoló szerepe van). Azaz kell létezzen valahol - ábránkon baloldalt - egy ET, amelynek elsődleges kulcsa, azonosítója a Tulajkód nevű TT. Ezen ET-nak lehet számos leíró tulajdonsága, és ezek együttesére itt hivatkozunk a Tulajkód nevű TT-sal mint idegen kulccsal. (L. a Kapcsolatok c. részben.)

ET2.jpg

Két egyedtípus

Vannak olyan modellező eszközök, amelyek az elsődleges kulcsot pl. nem aláhúzással, hanem a „PK” rövidítéssel (primary key) jelölik, az idegen kulcsot pedig az „FK” (foreign key) rövidítéssel.

Ha a két ET kapcsolatban van egymással, akkor azt úgy jelöljük, hogy összekötjük azokat. Az összekötő vonal végződése mutatja a számosságokat és kötelezőségeket az alábbiak szerint. Az egyszeres vonalvég (maximum) egyszerességet jelent, az elágazó vonalvég többszörös kapcsolatot jelent. Ha kis karika szerepel rajta, akkor a kapcsolat ebben az irányban opcionális, a merőleges vonalka pedig a kötelezőséget jelenti, egymástól függetlenül.

ET1-2.jpg

Két egyedtípus kapcsolatban van

A fenti ábrán jelölt kapcsolat tehát a következőt jelenti: egy (bármely) tulajdonoshoz több kocsi is tartozhat (elágazó vonalvég a KOCSI ET-nál), de lehet, hogy nem tartozik hozzá egyetlen egy sem (opcionális kapcsolat, kis karika jelzi). Ugyanakkor bármely kocsinak pontosan egy darab tulajdonosa van (egyszeres vonalvég a TULAJ ET-nál), illetve kell legyen (merőleges vonalka, kötelező kapcsolat).

Egyben ez példa a fogalomalkotás és az egyeztetés, dokumentálás problémájára is, mert jogosan merülhet föl valakiben a kérdés, hogy mitől tulaj valaki, ha lehetséges, hogy nincs kocsija. Például azért, mert a tulaj fogalmába - az adott modellben - azokat értjük bele, akik vagy tényszerűen már tulajdonosok, vagy potenciálisan azok (már van megrendelésüki, csak a kocsit még nem kapták meg). Az ilyenfajta kapcsolatokat nevezzük - számosságuk alapján - 1:N (egy-az-enhez, egy-a-sokhoz) kapcsolatnak.

Az ábra (bármilyen ábra) áttekinthetőségét zavarhatja az egyébként nélkülözhető részletek szerepeltetése. Éppen ezért az idegen kulcs szerepeltetése el is maradhat, hiszen a kapcsolat (tyúkláb) mentén helye nyilvánvaló. Ugyancsak nem feltétlenül szerepeltetünk az ábrán minden leíró tulajdonságot, a teljesség igényével, vagy legalábbis a modellezési folyamat kezdetén a hangsúly nem ezen van. Bármely egyedtípus kiegészítése további leíró tulajdonságokkal mondhatni mechanikus tevékenység, a kapcsolatok rendszerének kialakítása ennél sokkal nehezebb és problémásabb. Ezért - főleg kezdeti fázisban, vagy tankönyvi példák esetében - nem arra törekszünk, hogy a leíró tulajdonságokat a teljesség igényével megállapítsuk és pontosan, részletesen megadjuk. Természetesen, ha a modellezés célja működő rendszer kialakítása, akkor ezt a lépést a későbbiek folyamán nyilván nem lehet megtakarítani.

The art of computer programming Volume 3 (Sorting and searching) - Addison-Wesley, 1973.; magyar fordítása: Keresés és rendezés - Műszaki Könyvkiadó, Budapest, 1988.

1:N kapcsolatok

Tudatosítsuk az idegen kulcs mint kapcsoló szerepét. A jó adatmodell egyik igen fontos tulajdonsága a minimalitás, azaz olyan szerkezet kialakítása, amely biztosítja a redundancia kiküszöbölését. Emlékezzünk vissza az zonosítás elvi alapjára: az azonosítást az teszi lehetővé, hogy az egyedeknek vannak ún. elválaszthatatlan tulajdonságaik, amelyek az egyedet - dacára annak, hogy tulajdonságok - reprezentálják, képviselik.

Az 1:N kapcsolat egyes oldalán lévő azonosító ismétlődik az N-es oldalon mint idegen kulcs. Ez elég nyilvánvaló, ha táblázatokban (táblákban) képzeljük el a tényleges megvalósulást, az adatbáziskezelés relációs változatát feltételezve. Az 1:N kapcsolat, más néven egy-a-sokhoz kapcsolat esetén ugyanis az egyik oldali egy előforduláshoz a másik oldalon sok előfordulás tartozhat (tartozik). Ebből következik, hogy - példánkban - a TULAJDONOSnál nem tudjuk lajstromozni a birtokolt kocsikat, hiszen akárhányan lehetnek, és nem tudunk akárhány (meghatározhatatlan számú) rovatot erre a célra fenntartani. Ellenben a KOCSI esetében a helyzet egyértelmű: pontosan egy tulajdonosa van, ezen egyetlen tulaj hivatkozására pontosan egy rovatra van szükségünk, amely tartalmazza az adott kocsi tulajdonosát reprezentáló tulajdonság - esetünkben Tulajkód - értékét.

Kapcs_kocsi.jpg

Az azonosító teszi lehetővé a hivatkozást

Ha tehát tudni akarjuk, hogy Kovács Áginak milyen kocsija van (ha van), akkor először kikeressük Kovács Ági adatait (TULAJDONOS), azonosítójának értéke 1458, evvel az értékkel elmegyünk a KOCSI táblába, és kikeressük mindazon sorokat (kocsi egyedelőfordulásokat), amelyeknél a Tulajkód mint idegen kulcs értéke pont 1458. Ha van(nak) találat(ok), akkor megkaptuk Kovács Ági kocsijainak listáját, ha az eredmény az üres halmaz, akkor nincs kocsija.

N:M kapcsolatok

Az 1:N kapcsolatoknál láttuk, hogy a megoldás az, hogy az 1-es oldali kulcsot szerepeltetjük kapcsolóként (idegen kulcs) az N-es oldalon, mert így egyszeres adatmegadással lehet hivatkozni. De mi a teendő akkor, ha a kapcsolat N:M-es, sok-a-sokhoz típusú? Előbbi, tulaj-kocsi példánkat bővítsük az időtényező figyelembe vételével. Nyilvánvaló, hogy idők folyamán egy tulajnak akárhány kocsija is lehet (akárcsak egyidőben), viszont idők folyamán egy kocsinak is lehet sok tulajdonosa (persze egymás után).

ET1-3.jpg

Ekkor avval a problémával szembesülünk, hogy az 1:N kapcsolatoknál alkalmazott gondolatmenetet nem tudjuk alkalmazni, mivel mindkét oldal N-es. Bármelyik oldalt is választjuk, ott sok (akárhány) rovatra lenne szükség a kapcsolat nyilvántartásához. Ugyancsak nem tudjuk például a tulajdonlás kezdete és vége tulajdonságokat sem hova tenni.

Az N:M kapcsolatok tehát közvetlenül nem kezelhetők. A megoldás az, hogy felbontjuk azokat két darab 1:N-es kapcsolatra:

ET1-4b.jpg

Ez egy harmadik egyedtípus (esetünkben a BIRTOKLÁS) bevezetését igényli. Vegyük észre, hogy a kötelezőségek és a számosságok a kapcsoló ET oldalán ugyanazok, mint voltak az eredeti N:M kapcsolatban, a két új kapcsolat (tyúkláb) eredeti két ET felé eső vége pedig mindig egyszeres és kötelező. Másképpen: a birtoklás mint jelenségviszony mindig egyetlen adott, létező Tulaj és egyetlen adott, létező Kocsi (-előfordulás) közötti kapcsolat. A birtoklás mint jelenségviszony saját jellemzőkkel is rendelkezhet, mint például a birtoklás kezdete, vége stb., amelyeket az eredeti, N:M-es esetben nem tudtunk hová fölvenni. Itt ezeknek is megvan a helye. Ugyancsak itt lenne helye pl. a megszerzés (és tőle való megszabadulás) jogcímének is.

Vegyük észre, hogy a kapcsoló ET-ban összetett elsődleges kulcsunk van, amelynek részei a két idegen kulcs, és ehhez még hozzá kell venni pl. a Kezdete TT-t. Nem elképzelhetetlen ugyanis, hogy egy adott tulaj ugyanazt a kocsit később újból meg-, ill. visszavásárolja, tehát a két idegen kulcs együtteséről nem garantálható, hogy minden körülmények között egyedi értéke lesz. Az viszont már igaz, hogy ugyanaz a tulaj ugyanazt a kocsit ugyanabban az időpillanatban csak egyetlen egyszer tudja megszerezni. Ha később eladja, majd még később újra megveszi, akkor az összetett kulcs első két tagja ugyan nem változik, de a harmadik, a birtoklás kezdete már igen, s így teljesül az azonosító értékének egyediségére vonatkozó követelmény.

Ha tehát modellezés közben N:M kapcsolatra bukkanunk, nem kell kétségbe esni, hanem a fenti módon fel kell bontani. Elképzelhető azonban az is, hogy valaki úgy okoskodik, hogy az N:M kapcsolatot eleve kikerüli. Lehetséges gondolatmenet ugyanis a következő pl.: vannak tulajdonosok, kocsik, továbbá a tulajdonosok és a kocsik viszonya. Mindezen jelenségeknek saját tulajdonságaik vannak, tehát ezeket ET-kal kell tükrözni...


Lásd még (a teljesség igénye nélkül):

SSADM strukturált rendszerelmezési és tervezési módszer, MTA Információtechnológiai Alapítvány, 1993. Az ITB honlapján html formátumban olvasható, doc formátumban helyben itt

Kovácsné Cohner Judit dr. - Takács Tibor: Ismerkedés az SSADM-mel. Computerbooks, Budapest, 1999.

 

Vélemény

Nincs és nem is lehet.

impresszum