Adatbázis-tervezés konzultáció 8. Előadás Dr. Pauler Gá bor , egyetemi docens, ev.

1. Adatbázis-tervezés konzultáció 8. Előadás Dr. Pauler Gábor, egyetemi docens, ev. Adószám: 63673852-3-22 Számlaszám: 50400113-11065546 Telephely: 7666 Pogány, Széchenyi u. 1. Tel: 30/9015-488 E-mail: pauler@t-online.hu

2. Az előadás tartalma A Termék, Kódtáblák, Jármű, Külső logisztika dimenziók szerkezete az MDH-ban • Termék és Kódtáblák dimenzió • Disztribúciós csatorna-leírás • Objektum-hierarchia alapú termék/alkatrész leírás • Egymást kizáró relációk kezelése • Több oldalon • Egy oldalon • Termék tulajdonságok rugalmas tárolása • Sorozatok tárolása • Jármű dimenzió • Példa az objektum-paraméter alapú leírás használatára • Külső logisztika dimenzió bevezetés • Ciklikus szállítási definíciók az Idő dimenzió felhasználásával Szakirodalom

3. A Termék dimenzió 1 A Termék dimenzió (ld.: MintaERD2.vsd) célja, hogy leírja a szervezet tevékenysége során be- és kiá-ramló anyagokat, információkat, alkatrészeket. A dimenzió szerkezetének felső szintjeit a Session7-ben már ismertettük: a Partner, Kontakt, Kon-taktTort egyedek arról gondoskodnak, hogy az anyag/információ ki-beáramlás forrássait/végső célpontjait szervezetként, annak részeként vagy személyként azonosítani tudjuk. Ezalatt pedig: • Az anyag/információ áramlás több szervezetből álló disztribúciós csatornákon (Distribution Chan-nel) keresztül történik, amelyek eltérő számú tag-szervezetből állhatnak (pl. Gyártó, Nagyker, Kisker Ügynök, Vevő), de ezekhez nem csinálunk külön táblát, hanem a Disztribucio, illetve a történetét leíró DisztribucioTort egyedekdel ábrázoljuk az egészet: ez mindig két szervezetet (Disztributor-ID, FelhasznID) kötnek össze (Kezd/VegDatum) időintervallumban 1 DisztribucioTipusID tipusú (pl. beszerzési/értékesítési) csatorna Disztribuci-oSzintID-vel jelzett szintjén (pl. utolsó szint: ügy-nök-végfelhasználó). A Disztribucio önmagára mutató 1:több kapcsolatának FoDisztribucioID idegen kulcsa mindig a csatorna előző szintjére mutat, így nem fix szintszámú hierarchiaként tet-szőleges bonyolultságú csatornát tudunk ábrázolni a felelős kontaktokkal (Disztrib/FogyKontaktID) • Minden szint minden évben külön termékkataló-gust bocsáthat ki, melyeket a Katalogus egyed-ben ábrázolunk: a félreértések elkerülése végett minden katalógust belső mesterséges elsődleges kulccsal azonosítunk (KatalogusID), de eltároljuk sima mezőként a külső, kibocsátó által megadott azonosítóját (KulsoKatalogID). Ezt nevezzük a párhozamos külső kulcsolás (Parallel External Key) mód-szerének

4. A Termék dimenzió 2 • Természetesen semmi garancia nincs rá, hogy a külső kulcsok több gyártó és ország tekintetében egyediek. De az igazi káosz a termékkatalógusok-ban szereplő termékek, alkatrészek, anyagok azonosításánál van: ugyanazon gyártó két éves ka-talógusa közt teljesen megváltoztathatja a cikkszá-mozási rendszerét. Ezért soha nem bízunk meg semmilyen külső cikkszámozási rendszerben: • A Cikk egyedben központi cikkszámlistát vezetünk az általunk beszerzett/ raktározott/ gyártott/ eladott termékekről/ alkatrészekről/ anyagokról/ tervekről. Fontos! itt nem fizikailag létező konkrét dolgok adatait tároljuk, hanem termék/ anyag/ infó fajták leírását. A konkrétan legyártott dolgokat majd a Sorozat egyedben tároljuk. • A CikkTort egyed írja le, hogy a belső cikkszám (CikkID) mely gyártók mely katalógusában (Katalo-gusID) milyen helyi cikkszámú (KatalogCikkID) té-telnek felel meg adott (Kezd/VegDatum) közt. Ezt az egyeztetést periódikusan a beszerzési/ értékesí-tési osztályok munkatársai végzik el Fontos! Ez a történet tábla nem egymást kizáró (Non-Mutually Exclusive) időintervallumokat kezel (pl. 1 belső cikk megfelelhet egyszerre több külső cikknek és fordít-va), ezért nem alkalmazhatók rá a Session5–ben tárgyalt karbantartó eljárások. • Az egyes árucikkek tulajdonságait - amik alapján egyeztethetők - eltérő számú és tipusú (ParamTi-pusID) paraméterrel írhatjuk le (pl. 3.5×58mm fém-fúrószár, 1l-es 1.5% zsírtartalmú UHT tej), ezeket ábrázolja a CikkParam egyed. A CikkID kötelező idegen kulccsal csatolva írja le, milyennek kellene lennie ideálisan egy belső cikknek. Ezekben a rekordokban a CikkTortID opcionális kulcs Null Ha a CikkTortID is ki van töltve, akkor a ParamErtek azt írja le, milyen cuccot sikerült beszerezni az elő-írt helyett adott idő-intervallumban (ne feledjük, hogy Kelet-Európában vagyunk!!!)

5. A Kódtáblák dimenzió A cikkek paramétereinek pontosabb leírását egész csomó kis általános használatú kódtábla segíti, amelyek a Kódtábla dimenzióban (ld.: MintaERD2.vsd) kaptak helyet: • A ParamTipus egyedben a MezoTipusID azt írja le, hogy a CikkPa-ram.ParamErtek tartalma milyen típusú adatbázis tábla mezőként értelmezendő (egész szám, tört, dátum, szöveg, stb.) • Az ErtekCimke egyed azt írja le, hogy adott egész tipusú paraméter (ParamTipusID) adott Erteke mit jelent (pl. „A fűnyírótraktor üzem-anyaga”={1:”95-ös benzin”, 2:”98-as benzin”, 3:”Gázolaj”}) • A paraméterek és címkéik leírását nem sima szövegként adjuk meg, hanem a Megjegyz egyedre szóló hivatkozásként, ahol a rendszer alapnyelvén adjuk meg a leírást, de 1 rekordjára több csatolódhat a Szotar egyedből, többNyelvre fordítva az adott kifejezést. Ez a rendszer moduláris több nyelvűvé (Modular Multi-Linguistic, MML) tételének módszere, és nem az, hogy minden nyelv kedvéért külön mezőt hozunk létre az összes, leírást tartalmazó adatbázis táblában! Ennek az adatbázis-szerkezetnek az értékesítési osztály igen csak nagy hasznát veszi a rendszerint 8-10 nyelven készülő termékleírás és felhasználói tájékoztató készítésénél, elkerülve az alábbi gyöngysze-meket: „NAGY OROM. Vietnami jatek. Biztos nagy az orom! Elvezze jatek-nak egyfejű magánjáték akar tarsas. FÜTYÜLIM! Elektros razáto! Az telep hasnalni tserel kozben tilos! Mindig felnott!” „You want be king of bad: your manhood or your woman gone. Order Viagra now Nigeria! Free shipping Hungry!” • A SkalaTipus egyedre hivatkozó SkalaTipusID idegen kulcs azt írja le, milyen típusú skálán mért az adott tipusú paraméter (nominális:pl. vonalkód, ordinális:pl. iskolai végzettségek, intervallum:pl. dátmok, arány:pl. ár). Ha a paraméterekből továbbszámolunk, ez adja meg, hogy milyen számolások értelmesek (pl. nominális skálából nem lehet átlagot számolni, intervallum skálával nem lehet osztani, stb.)

6. Jármű JárműID TörzsSzám GyártásiIdő Módosító Módosítva Állapot Biztosít BiztosítID KötvSzám KötIdő Módosító Módosítva Állapot Tender TenderID TendSzám BontIdő Módosító Módosítva Állapot Árajánlat ÁrajánlatID KülsőAzon SzállítIdő Módosító Módosítva Állapot Cikk CikkID CikkLeírás JárműID BiztosítID TenderID AjánlatID Módosító Módosítva Állapot A Termék dimenzió 3 • A CikkKapcs egyed a különböző fajta termékek, alkatrészek, anyagok egymásba épülését, anyag-szükségleti tervét (Bill Of material, BOM) írja le, annak történetiségében: adott Kezd/VegDatum közt a CikkTolID cikkszámú dolog CikkTolMin/ Max számú egységéhez (CikkTolMertEgysID) hány CikkIgID cikkszámú dolog kell Min/Max (pl. 1db 14/4-es golyóscsapágyhoz 8db 6mm-es csapágygolyó kell). 2 cikkszám viszonylatában az időintervallumok itt egymást kölcsönösen kizáróak • A CikkKapcsTipus egyed a -Tol és -Ig oldali cikkek közti számos viszonyt kifejezhet (kötelező alkatrésze, opcionális alkatrésze, egymást kizáró helyettesítője, továbbfejlesztett változata, stb.) • A kapcsolati típusok történeti leírásához különböző CikkKapcsStatusz-ok tartozhatnak (pl. kötelező alkatrészhez: tervezett alkatrésze, aktuálisan használt alkatrésze, forgalomból kivont alkatrésze) A fenti szerkezet a termékek objektum hierarchia-alapú (Object Hierarchy Based) leírási modellje. Ennek elég rázós tervezési problémái vannak: • Elvileg az összes Cikk összes paramétere ábrázolható a CikkParam táblában, de ez elég nagy lesz és lassú benne keresni a paramétereket • Sokkal gyorsabb lenne a cikkekhez cikkleíró táblá-kat csatolni a saját paramétereiknek megfelelő táb-la szerkezettel (Pl.Jármű,Biztosít,Tender,Árajánl) • Szöveges elemzéssel: 1Cikkhezmax1Leírótáblatartozik, de 1LeírótáblatartozhattöbbCikkhez • Így ezt a Leírótáblák:Cikk közti 1:több, független: független kapcsolatokkal kellene megjeleníteni, amelyeket egy, a függetlenségi kapcsolatokat metsző opcionális Arc tesz egymást kölcsönösen kizáróvá (1 Cikk vagy Jármű, vagy Biztosít, stb.)

7. Jármű JárműID TörzsSzám GyártásiIdő CikkID Módosító Módosítva Állapot Biztosít BiztosítID KötvSzám KötIdő CikkID Módosító Módosítva Állapot Tender TenderID TendSzám BontIdő CikkID Módosító Módosítva Állapot Árajánlat ÁrajánlatID KülsőAzon SzállítIdő CikkID Módosító Módosítva Állapot Cikk CikkID CikkLeírás LeírTáblaID Módosító Módosítva Állapot Tábla TáblaID TáblaNév Módosító Módosítva Állapot A Termék dimenzió 4 • A fent leírt, hagyományos adatbázistervezési megoldás azon-ban itt óriási helypazarláshoz vezetne: mivel sokfajta cikknek lehet egyedi leíró táblája, az eleve sok rekordból álló Cikk táb-la szerkezetébe akár több 100 idegen kulcsot kellene betusz-kolni (minden cikkleíróhoz egyet), amelyek közül ráadásul csak max.1 kap értéket, a többi garantáltan Null az Arc miatt! Így az Arc csak helypazarlással tud relációk közti XOR-t ábrázolni. A probléma a paraméterezett tábla hivatkozás (Parametered Table Reference, PTR) trükkel oldható fel: • Fordítsuk meg a a Cikk:Leírótáblák kapcsolatainak számos-ságát 1:több-re, vagyis a leírótáblák hivatkoznak CikkID ide-gen kulccsal a Cikkre, így ott a helypazarlás megszűnik, és az Arc-hoz tartozó programkódra sem lesz többé szükség • A gond az, hogy így viszont a Cikk táblában semmi nem mutatná, hol van az adott cikkhez a leírás, és adott CikkID-t végig kellene keresni az összes leírótáblán keresztül, ami idő-rabló, és SQL-ben nehézkesen programozható dolog, és úgy is csak az egyik tábla írja le a cikket, sok fölös keresés lenne • Ezért a Cikk egyedben lesz még egy opcionális idegen kulcs (LeirTablaID), ami azt mutatja, hogy a leírás hol van, ha van. • Azért nem a tábla nevét tároljuk, mert az akár 32 karakter is lehet (32-64 byte-ot pazarolva), még hosszú egész típusú idegen kulcsot 4-byte-on tudunk tárolni • A korábban már tárgyalt Rendszerleírás (ld.: MintaERD2.vsd) dimenzió részeként pedig már úgy is van központi táblalistánk a Tábla egyedben, ahonnan a táblanév könnyen kikereshető • További gond, hogy az alap SQL nyelv nem engedi meg a táblanevek paraméterezését a FROM részben. De akár Oracle PL/SQL-ben, akár MSSQL Transact SQL-ben, akár Access Visual Basic makrókban lehetőség van arra, hogy egy lekérde-zés kódját stringként állítsuk össze szövegkezelő függvények-kel, és utána lefuttassuk, megoldva a paraméterezést. Lássuk ezt Transact SQL-ben:

8. Tender TenderID TendSzám BontIdő CikkID Módosító Módosítva Állapot Cikk CikkID CikkLeírás LeírTáblaID Módosító Módosítva Állapot Tábla TáblaID TáblaNév Módosító Módosítva Állapot CikkParam CikkParamID Érték CikkID ParamTipusID Módosító Módosítva Állapot ParamTipus ParamTipusID Leírás MezőTipusID MértEgysID SkálaTipusID FoParamTipusID Módosító Módosítva Állapot A Termék dimenzió 5 Írunk egy LeiroLekerd nevű tárolt eljárást, amelynek két paramétere van: • A Lekerdez az adott leírótábla lekérdezésének SQL kódja, ahol XXXXXXXX karaktersorozattal jelöljük a leírótábla nevét • A LeiroTablaID a leírótábla kódja, amit a Cikk tábla aktuális rekordja ad meg Create Proc LeiroLekerd @Lekerdez Text, @LeiroTablaID Int As Declare @TablaNev Varchar(32) Select @TablaNev = Select TablaNev From Tablak WHERE TablaID=@LeiroTablaID /*A táblanév kinyerése*/ Replace(@Lekerdez,’XXXXXXXX’,@TablaNev) /*Kicseréljük a kamu táblanevet az aktuálisra*/ Exec @Lekerdez /*Lekérdezés futtatása*/ Ezzel a módszerrel egy rugalmas tárolási szerkezetet kapunk a cikkek tulajdonságainak tárolására: • Adott fajtájú cikkekben (pl. versenytárgyalási-kiírások) közös tulajdonságokat (pl. TenderSzám, BontásiIdő) gyorsan elérhetően tudunk tárolni az ilyen fajta cikkek leíró egyedében (pl. Tender) • Az olyan tulajdonságokat, amelyek cikkről-cikkre más és más tipusúak és számúak (pl. adott versenytárgyalási kiírás értékelési szempontjai: az egyik tendernél lehet 77 különféle környezetvédelmi változó, a másik tenderben egyáltalán nincs ilyen!) a CikkParam egyedben tároljuk, sokkal lassabban lekérdezhető, de rugalmasan bővíthető módon! • Sőt a ParamTipus egyed a FoParamTipusID opcionális ide-gen kulcson keresztül önmagára mutató 1:több kapcsolata le-hetőséget ad arra, hogy ha egy cikknek nagyon sok paraméte-re van, akkor ezeket az áttekinthetőség kedvéért hierarchiába rendezzük (pl. 1Tenderhez több Értékelési szempont paramé- ter tartozik, és ezeknek mind van minimuma, maximuma, ideális értéke és értékelési súlya, sőt az értékelési súlyok egész halmaza tartozhat hozzá különféle döntéshozók véleményének ábrázolására!

9. A Termék dimenzió 6 • Ne feledjük, hogy a Cikk egyed és a rajta lógó egyedek, még nem fizikailag létező, eladható árucikkeket/ alkatrészeket/ anyagokat tárolnak, hanem ezek fajtáinak leírását. Az önmagára mutató 1:több kapcsolattal rendelkező Katego-ria egyed rendezi a cikkeket egy nem fix szint-számú funkcionális kategória-hierarchiába, ami a beszerzési/értékesítési statisztikák alapja lehet. • A Sorozat és a hozzá kapcsolódó egyedek tárolnak ténylegesen legyártott, fizikailag létező, eladható termékeket, lényegében megismételve a Cikk egyedhez kötődő teljes struktúrát (Soro-zatTort, SorozatParam, SorozatKapcs) Miért van erre szükség, mikor a Session7–ben a Data Structure Clustering (DSC) trükknél már megjegyeztük, hogy a hasonló struktúrákat inkább össze kell vonni az adatbázis szerkezet egyszerűsítése érdekében? • Azért kell különválasztani a cikkek virtuális leírásának tárolását a fizikailag legyártott egységek nyilvántartásától, hogy ne kelljen a terjedelmes leírást megismételni minden egyes fizikailag legyártott egységnél • Pl. Ha sorozatban gyártunk 150000db tök egyforma golyóscsapot, akkor a Cikk és csatolt táblái egyszer leírják részletesen az összes tulajdonságait (méretek, keresztmetszet, tömeg, stb.), és jó esetben 1db plusz rekordot generál a Sorozat táblában a Kezd/VegSorozatSzammal. A többi sorozat-jellegű táblára ilyenkor nem lenne szükség • Vannak azonban bonyolult, nehezen gyártható termékek, amelyeket hiába gyártanak sorozat-ban, minden termék más és más lehet 1 kicsit

10. Az előadás tartalma A Termék, Kódtáblák, Jármű, Külső logisztika dimenziók szerkezete az MDH-ban • Termék és Kódtáblák dimenzió • Disztribúciós csatorna-leírás • Objektum-hierarchia alapú termék/alkatrész leírás • Egymást kizáró relációk kezelése • Több oldalon • Egy oldalon • Termék tulajdonságok rugalmas tárolása • Sorozatok tárolása • Jármű dimenzió • Példa az objektum-paraméter alapú leírás használatára • Külső logisztika dimenzió bevezetés • Ciklikus szállítási definíciók az Idő dimenzió felhasználásával Szakirodalom

11. Sorozatok leírása: pl. Jármű dimenzió 1.Pl. A gyógyszerkutató labor hiába rendel meg egy iparági szabványt képező DNS-ű sejtvonalat, mivel a biológiában nem léteznek 100%-os garanciák, ez csak nagyjából gy sikerül, ahogy kellene, és az egyedi eltéréseket tárolni kell… • Ekkor rátjuk elő a kalapból a SorozatParam egyedet, ahol a sorozat tagjainak egyedi paraméter értékeit le tudjuk írni 2.Pl. Egy hadihajó építése olyan sokáig tart, hogy az elektronikája sosem lesz olyan mint az osztálya előző egységéé, mert a technika továbbfejlődik közben… • Ekkor vesszük elő a SorozatKapcs egyedet, hogy le tudjuk írni az alkatrészek hajónként megváltozó összeépülését Ezek a példák viszonylag extrémek voltak, viszont majdnem minden adatbázis foglalkozik Járművek leírásával (céges autók, haszonjárművek, tömeg-közlekedési eszközök,stb.) Meg fogjuk látni, hogy ezen elég bonyolult szerkezetű dimenzió leírását nagyban segíti az objektum-hierarchia elvű Ter-mék leíró dimenzió megléte: • A JarmuTipus, JarmuAlTipus, UzemanyagTi-pus egyedek elég részletes adatokat tartalmaz-nak járművek típusleírásához, de bármikor előállhat olyan helyzet, hogy szükség lehet újabb paramétereik tárolására. Hogy ekkor ne kelljen hozzányúlni az adatbiázis szerkezetéhez, vagy átprogramozni állandóan a felhasználói felületet,a CIkkID opcionális idegen kulcsok elhelyezésével cikként is definiáljuk őket a központi cikk listában, így bármikor kiegészíthetjük a leírásukat tetsző-leges számú paraméterrel. Itt jön vissza a bonyo-lultabb termékleírásba ölt munkamennyiség!!!

12. Jármű dimenzió 2 • Figyeljük meg, hogy a járművek tipizálása alatti szinten, a konkrét, fizikailag létező Jarmuveket leíró egyedet viszont már nem a Cikk, hanem a Sorozat egyedre kötjük SorozatID opcionális idegen kulccsal: ha szükség lenne a sorozatban gyártott, azonos fajta járműveink esetleges egye-di paramétereinek tárolására, ezt a SorozatPa-ram egyedben megtehetnénk • Nem érdemes cikként vagy sorozat elemeként ábrázolni olyan dolgokat, amelyeknek a jármű-vekkel való viszonya, illetve adatstruktúrája ható-ságilag előírt, és így kevés variácó lehetséges belőlük: Rendszam, Forgalmi, Felulvizsgalat • Figyeljük meg, hogy a Rendszam nem alantas szintje a Jarmu egyednek, mert köztük több:több kapcsolat lehet, aminek a relacios tablaja a Forgalmi • EgyForgalmihoz viszont többJarmuTort rekord tartozhat, ami adott forgalmi fenállása közben bekövetkező változásokat, eseményeket írja le

13. Jármű dimenzió 3 • Hasonlóképp a Forgalmihoz kötődnek a jármű periodikus FelulVizsgalatai, és ezeket sem érdemes cikként megjeleníteni • Egészen más a helyzet a járművek Biztositasai-val: ezek közvetlenül a járműhöz kapcsolódnak, mert nem feltételük a forgalomban tartás, és ren-geteg egyedi leíró tulajdonságuk lehet (pl. a ha-szonjárművek üzemeletőivel kötött flottabiztosí-tások közt nem biztos, hogy van két egyforma, mert az ügyfél ilyenkor olyan erős pozícióban van a biztosítóval szemben, hogy kiharcolhat minden-féle elvarázsolt egyedi kedvezményeket), aminek az ábrázolására nem biztos hogy érdemes több 100 mezős leírótáblákat tuszkolni az adatbázisba, hogy azután a mezőik nagy része üres legyen. • Ezért a BiztositasTipust rákötjük a Cikkre, a Biztositast a Sorozatra, és máris egyedi paraméterek tömkelegét tárolhatjuk le, nagy ronda táblastruktúrák definiálása nélkül • A JarmuAllok egy relációs egyed, amely a járművet összeköti a sofőrrel (FelelosPozicioID), illetve az Idő dimenzió elemeivel (pl. NapSzak-TarID). Tömegközlekedési és fuvarozó vállalatok esteén ez az adatbázisrész persze jóval bonyolultabb lehet, amint erre már utaltunk a Session5–ben.

14. Az előadás tartalma A Termék, Kódtáblák, Jármű, Külső logisztika dimenziók szerkezete az MDH-ban • Termék és Kódtáblák dimenzió • Disztribúciós csatorna-leírás • Objektum-hierarchia alapú termék/alkatrész leírás • Egymást kizáró relációk kezelése • Több oldalon • Egy oldalon • Termék tulajdonságok rugalmas tárolása • Sorozatok tárolása • Jármű dimenzió • Példa az objektum-paraméter alapú leírás használatára • Külső logisztika dimenzió bevezetés • Ciklikus szállítási definíciók az Idő dimenzió felhasználásával Szakirodalom

15. Külső logisztika dimenzió 1 • Még a Termék dimenzió az értékesítési csatorna elérhetőségeit, illetve a benne mozgó termékeket, alkatrészeket, anyagokat, információkat írta le, a Jármű dimenzió meg azt, hogy mi mozgatja ezeket, a Külső logisztika a mozgás folyamatát írja le. Felhívjuk a figyelmet, hogy itt a dimenzió legbonyolultabb változatához nyújtunk bevezetést, amikor nemzetközi kereskedelemben résztvevő cégek versenytárgyalásokat komplex ajánlatokkal megnyerve, többfajta szállítóeszközön, ciklikusan szállítanak le termékeket • Ha Mari néni őstermelői adatbázisát tervezzük, akkor nyilvánvaló, hogy ezen egyedek kicsiny töredékére lesz csak szükség, de mindig egysze-rűbb egy részletesebb tervből elhagyni dolgokat, mint egy alátervezett struktúrát utólag foltozgatni, kétségbeesetten, jóval a határidő után, kötbérben • A dimenzió lehetséges szintjei: Tender, Árajánlat, Szerződés, Számla, Szállítólevél, FuvarBiztos-Szerződ, VámárúNyilatkozat, RaktárBevétJegy1:több kapcsolatokkal csatlakoznak egymás alá, de mindegyik szint követi az MDH 4 táblás szint-leíró szerkezetét, mert az ISO szabvány minden szintre megköveteli a bizonylati elv (Documentary Principle) (lásd: Session5) érvényesülését: a fejléc leíró egyedhez tételeket leíró történet jellegű egyed csatlakozik 1:több kapcsolattal, a fejléc egy típusleíró kódtáblára, a történet egy státuszokat leíró kódtáblára hivatkozik. Ezen túl a tétel/történet egyedek szerkezete fontos: • Mindig van bennük CikkID cikkszám hivatkozás, hiszen a Tender, Arajanlat, Szerzodes egyedeknek pontosan le kell írni a megrendelt áruk fajtáját. Ha a rendelés valamely csatorna katalógu- sából történik, akkor erre a CikkTortID hivatkozik. Ha már konkrét fizikai áruk mozgatásáról van szó (pl. Szamla, Szallitolevel),akkor arra a pluszban be-rakott SorozatID hivatkozik.

16. Külső logisztika dimenzió 2 • Minden tétel egyedben szerepel Mennyiseg jellegű tulajdonság, illetve ennek mennyiség-egysége (MertekEgysID). Mivel a műszaki emberek imádják az elvarázsolt mértékegysé-geket (pl. öl/miatyánk a sebesség mérésére), a Kódtáblák dimenzióban mértékegység konverziós segédtáblázatot is tárolunk • Minden tételnek egyednek van EgysegAr jellegű tulajdonsága (árak, diszkontok), illetve ennek valutanemére szóló hivatkozás (Valuta-ID). A valuták átváltását a Kódtáblák dimenzi-óban átváltó táblázat segíti, amely a statikus mértékegység átváltóval szemben történet jellegű tábla: Kezd/VegDatum közt tárol adott bankok által kínált deviza/valuta vételi/eladási árfolyamokat • Minden tétel egyedhez tartoznak határidő jellegű tulajdonságok. Ezek lehetnek egyszeri abszolút idő intervallumok (Kezd/VegDatum), a művelet kezdetétől számított relatív intervallu-mok (Kezd/VegRelIdo), illetve ciklikus definíci-ók (NapTipusID, NapSzakTipusID) a fejlettebb Idő dimenzióra támaszkodva, amibe fektetett munka megint jócskán megtérül (pl. különben igen csak feladná a leckét egy ilyen szállítási szerződés: „szállíts X mennyiséget minden hónap második péntekjén az éjszakás műszak kezdetére Z-be”) • Minden tétel egyedhez tartozik FelelosID jellegű tulajdonság, amely nem konkrét emberre mutat, mert azt kirúghatják, hanem adott szervezet adott pozíciójára • A TetelStatuszID mutathatja, hogy a tétel elérte-e a neki szánt rendeltetési helyet időben

17. Szakirodalom • Az USA védelmi minisztériuma (DoD) által a hadiszállítók számára előírt logisztikai adatmodell (CLDM) (angolul): http://www.dla.mil/j-6/dlmso/eApplications/LogDataAdmin/CorpLogData/cldm.asp • Egyszerű, általános logisztikai adatmodell egy adatmodellezési honlapról: http://www.databaseanswers.org/data_models/logistics/index.htm • A Wallenius&Wilhelmsen cég nyilvánosságra hozott logisztikai adatmodellje: http://www.2wglobal.com/www/customerCentre/ElectronicDataIntegration/DataModels/index.jsp • Cikk a tétel-kozpontú logisztikai adatmodellezésről: http://www.tuta.hut.fi/logistics/publications/wp_item_centric_enterprise_data.pdf • Teradata szállítmányozási és térinformatikai modell: http://www.teradata.com/t/page/106751/index.html