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

1. Adatbázis-tervezés konzultáció 7. 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 Tér-, Személy-, Szervezet dimenziók szerkezete az MDH-ban • A Tér dimenzió maximális rugalmasságú szerkezete • A Személy dimenzió szerkezete • A Szervezet dimenzió szerkezete • Kitekintés a Termék dimenzió szerkezetére Szakirodalom

3. u : R d : R NapTipus Orszag PK NapTipusID int identity PK OrszagID int identity NapTipusLeir varchar ( 16 ) OrszagNev varchar ( 16 ) FK 1 NapTipusSzintID int FK 1 HivatalosNyelvID int PozitivHalmazDef bit FK 2 ValutaID int FK 2 SzuloID int TizedesJelolo varchar ( 1 ) FK 3 OrszagID int EzresJelolo varchar ( 1 ) u : R RekStatuszID int DatumElvalaszt varchar ( 1 ) d : R FelvivoID int IdoElvalaszt varchar ( 1 ) Felvive datetime DatumbanEvPozic tinyint ModositoID int DatumbanNapPozic tinyint Modositva datetime DatumbanHoPozic tinyint SzerverID int CsaladiNevPozic tinyint NaploID int NyariIdoKezd datetime NyariIdoVeg datetime NyariIdoEltol tinyint u : R d : R u : R d : R Regio PK RegioID int identity u : R RegioLeir varchar ( 16 ) d : R FK 1 OrszagID int u : R d : R IrSzam PK IrSzamID int identity IrSzamLeir varchar ( 16 ) u : R FK 2 RegioID int d : R FK 1 OrszagID int u : R u : R u : R d : R d : R d : R u : R Telepules TelepulesTipus d : R PK TelepulesID int identity PK TelepulesTipusID int identity TelepulesNev varchar ( 16 ) TelepulesTipusLeir varchar ( 16 ) FK 1 TelepulesTipusID int FK 3 IrSzamID int FK 4 FoTelepulesID int FK 6 RegioID int FK 5 OrszagID int IdoZona tinyint u : R d : R A Tér dimenzió maximális rugalmasságú szerkezete • A Session6–ban már láthattuk, hogyan kell a Tér di-menzió szerkezetét felépíteni MDH-ban, ha a tárolá-si hely minimalizálása és sok százezer cím gyors im-portja a cél. Most a „hivatalok packázásait” elviselő, maximális rugalmasságú szerkezetre mutatunk pél-dát (lásd: MintaERD1.vsd), amely azonban sebes-ség szerint messze nem optimális • Itt nem az irányítószámokat tároló IrSzám egyed áll a dimenzió fókuszában, akár át is ugorható, ha hi-ányzik, mert redundáns 1:több kapcsolatok biztosít-ják, hogy a hierarchia más úton is bejárható legyen (pl.Orszag>Regio > Telepules > Kozterulet > Cim) • A másik különbség, hogy ezt a dimenziót igyekez-tünk nemzetközileg használhatóvá tenni: az Orszag egyed tárolja a hivatalos nyelvet, a pénznemet a szám-, dátum-, időformátum és az időszámítás be-állításait, a rá hivatkozó idegen kulcs (OrszagID) el-helyezése a NapTipus egyedben pedig biztosítja, hogy adott ország munkaszüneti napot okozó nem-zeti/ vallási ünnepei tárolhatók lesznek naptípusként • A kevésbé szervezett országokban (pl. Magyaror-szág)az IrSzam:Telepules egyedek több:több kap-csolatban állnak (több kicsi település tartozhat egy irányítószámhoz, még nagy települések több irányí-tószámkörzetből állnak), ami zavarja hierarchikus szintekbe rendezésüket. Ezt úgy oldjuk fel, hogy az IrSzam alá rendeljük Telepulest 1:több kapcsolat-tal, de opcionális lesz az IrSzam idegen kulcs benne • Ezenkívül a Telepulesnek lesz egy önmagára muta-tó 1:több kapcsolata,így a ennek FoTelepules opci-onális idegen kulcsa segítségével több, önálló rányí-tószámú településrészt egy főbb település alá rendelünk, aminek viszont nem lesz irányítószáma. Így nem kell 2 egyed a kis és nagy településekhez!

4. u : R KozTerTipus KozTer d : R PK KozTerTipusID int identity PK KozTerID int identity KozTerTipusLeir varchar ( 16 ) KozTerNev varchar ( 32 ) FK 1 KozterTipusID int FK 2 TelepulesID int RekStatuszID int FelvivoID int Felvive datetime ModositoID int Modositva datetime SzerverID int NaploID int u : R d : R u : R Cim d : R PK CimID int identity PostaFiok varchar ( 16 ) SzobaSzam varchar ( 8 ) AjtoSzam varchar ( 4 ) Emelet varchar ( 16 ) HazSzam varchar ( 8 ) FK 4 KozTerID int u : R FK 2 TelepulesID int d : R FK 5 IrSzamID int FK 6 RegioID int FK 7 OrszagID int Telefon varchar ( 16 ) Mellek varchar ( 8 ) Fax varchar ( 16 ) FaxMellek varchar ( 8 ) u : R Email varchar ( 32 ) d : R URL varchar ( 128 ) RekStatuszID int FelvivoID int Felvive datetime ModositoID int Modositva datetime SzerverID int NaploID int A Tér dimenzió maximális rugalmasságú szerkezete 2 • A KozterTipus és KozTer egyedekkel leegy- szerűsített tárolást valósítunk meg, csak a közterület típusa fog legördülő menüből mű- ködni a cím rögzítésekor, a közterületnevet redundáns módon mindig kézzel kell újra ki- tölteni. Nemzetközi szinten gondolkodva azonban beláthatjuk, hogy a nyelvenként kb 180db közterület-tipus rekordot még belerakhatjuk előre egy legördülő menü forrástáblájába, de több ország és nyelv összes gyakori közterület nevével, ezt már nem olyan könnyű meg-tenni, a rendszer előzetes feltöltése adatokkal több erőfeszítést köve-telne, mint a redundás kézi kitöltögetés. A leegyszerűsített megoldásra nem csak a lassabb működés, hanem a címek bizonytalanabb azono-síthatósága is jelemző a Session6–ban tárgyalt megoldáshoz képest. Persze még mindig nagyságrendekkel megbízhatóbb a címek normali-zálatlan, egyetlen stringben történő tárolásához képest, és a nagyüze-mi ügyfélnyilvántartástól eltekintve a hivatali élet igényeit kiszolgálja. • Az MDH rendszer központi Cim egyedében megfigyelhetjük, hogy apostai cím szokásos normalizált elemei (PostaFiok, SzobaSzam, AjtoSzam, Emelet, HazSzam mezők, illetve KozTerID, TelepulesID, OrszagID kötelező és IrSzamID, RegioID opcionális idegen kulcsok) mellett azokat az elektronikus elérhetőségeket is tárolja, amelyek nem mobilak, hanem inkább az adott irodahelységhez kötődnek (Telefon, Mellek, Fax, FaxMellek, Email /nem otthoni, céges!/, URL) • Minden más elektronikus elérhetőség (pl. Mobil, SzemelyiEmail, Skype) majd a Szemely egyedhez csatolt Elerhetoseg egyedben fog tárolódni.

5. Az előadás tartalma A Tér-, Személy-, Szervezet dimenziók szerkezete az MDH-ban • A Tér dimenzió maximális rugalmasságú szerkezete • A Személy dimenzió szerkezete • A Szervezet dimenzió szerkezete • Kitekintés a Termék dimenzió szerkezetére Szakirodalom

6. A Személy dimenzió szerkezete 1 • Az MDH struktúra központi Szemely leíró egye-dében csak azok a tulajdonságai vannak, amelyek nagyon erősen 1:1 kapcsolódnak hozzá (kivéve talán az AllampolgID-t, de az állampolgárság időbeli nyomonkövetésére a legtöbb rendszerben nincs szükség) • A Szemely egyedhez egy csomó kód leíró egyed-re hivatkozik idegen kulcsokkal: Nyelv, Orszag, Megszolitas, Nem. Azon kódleíró egyedeket, amelyek általánosan használtak az egész rend-szerben (pl. Valuta, MertEgys, stb.), belerakjuk egy Kódtáblák dimenzióba (lásd: MintaERD1.vsd) • A Szemely egyed minden mezője és idegen kul-csa opcionális, mert azon személyek adatait is itt fogjuk tárolni, akiikről viszonylag keveset tudunk (pl. egy beszállító cég kapcsolattartója, akinek csak a nevét meg a telefonszámát tudjuk). Ezért majd a felhasználói felület űrlapjai segítségével oldjuk meg, hogy pl. saját alkalmazottaink esetén a mezőkel mégis kötelező legyen kitölteni: az űrlap fogja követelni a kötelező kitöltést. • Az Elerhetoseg egyfajta történet jellegű egyed-ként szerepel a Szemely alatt, adott időinterval-lumban érvényes, opcionális személyi elérhető-ségeket (CimID,Mobil, E-mail, Skype, BankSzla) tárol, de státuszok helyett inkább tipusleíró kód-táblát csatolunk hozzá, mert nem annyira az elér-hetőségek életciklusának a nyomonkövetése fon-tos, mind inkább a típusaié (pl. állandó/ ideiglenes/ otthoni/ munkahelyi, stb.). Az időintervallumot nemcsak egyszerire lehet megadni (KezdDatum, VegDatum), hanem ciklikus definícióra is lehető-séget adunk (NapTipusID, NapSzakTipusID, ld: Session5) elfoglalt emberek nyomonkövetésére!

7. A Személy dimenzió szerkezete 2 A Szemely egyedhez 1:több kapcsolódhatnak a kü-lönböző kvalifikációit leíró egyedek. Ezzel kapcso-latban két megoldás közül választhatunk. Előre nem lehet megmondani, hogy melyik lesz a jobb, az alkal-mazási környezet követelményei döntenek: • A kvalifikációkat leíró táblák (Jogsi, MunkaAlk-gi, NyelvVizg, Kepesit, stb.) szerkezete igen hasonló: • Mindegyikben van belső elsődleges kulcs (ID), • Mellette párhuzamosan tároljuk a külső azono-sítót sima mezőként (pl. diplomaszám, jogosít-ványszám, stb.), mert nem bízzuk az adatbázi-sunkat egy külső azonosító egyediségére, amire nincs befolyásunk, valamint több ország rendsze-reit áttekintve ezek egyáltalán nem egyediek!!! • SzemelyID (kire szól), KibocsatoID (melyik szer-vezet bocsátotta ki), Eredmeny vagy Minosites, érvényesség KezdDatum, Vegdatum • Ezért összevonhatjuk az összes kvalifikáció-leíró egyedet egyetlen egyedbe. Ezt a trükköt nevezzük hasonló adatstruktúrák klaszterezésének (Data Structure Clustering, DSC), ami egyszerűbb tárolást és jóval kevesebb felhasználó felület programozást eredményez, viszont nem tárolja olyan pontosan a részleteket. Pl, hogy egy nyelvvizsgának van nyelve, azon belül tipusa (pl. TOEFL csak angolból van, németből más a vizsgarendszer), azon belül szintjei • A másik megoldás, ha mindenféle kvalifikációt kibon-tunk külön egyedbe, ekkor csatolt leíró- és kódtáblák segítségével olyan összefüggések is ábrázolhatók, hogy egyKepesitTipushoz többKepesSzint tartoz-hat, amelyek közül valamelyik előfeltétele (ElofeltID) lehet a másiknak. Ez akkor fontos, ha a cég személy-zeti adattárát (HR Data Mart) építjük, és ábrázolni szeretnénk a cég saját belső képesítési rendszerét

8. Az előadás tartalma A Tér-, Személy-, Szervezet dimenziók szerkezete az MDH-ban • A Tér dimenzió maximális rugalmasságú szerkezete • A Személy dimenzió szerkezete • A Szervezet dimenzió szerkezete • Kitekintés a Termék dimenzió szerkezetére Szakirodalom

9. A Szervezet dimenzió szerkezete 1 • Az MDH rendszer központi Szervezet leíró egyede jelenít meg bármilyen szervezetet: a cég belső szer-vezetétől kezdve partnerei (felügyelő hatóság, be-szállítók, vevők, stb.) szervezetének ábrázolandó ré-szeiig. Ezért szinte minden mező opcionális benne, és a saját szervezetünk karbantartásakor a felhasz-nálói felület űrlapjai gondoskodnak a kötelező kitöl-tésről. A hozzá kapcsolódó SzervezetTipus kódleíró ábrázolja a gazdálkodó szervezetek jogi fomáit (Rt, ZRt, Kft, Bt). A Szervezet egyednek több önmagára mutató 1:több kapcsolata is van: a SzuloSzervezet-ID opcionális idegen kulcs a szervezet alapítójára vagy tulajdonos szervezetére mutat, ezáltal a szerve-zetek közti nem fix szintszámú tulajdoni hierarchiát modellezi. A BankID a szervezet számlavezető ban-ki szervezetére mutat. • Hasonló nem fix szintszámú hierarchia jelenik meg a dimenzió alsóbb két szintjén az Osztaly és Pozicio egyedekben, az alosztályok-főosztályok, és a szerve-zeti pozíciók közti hierarchia ábrázolására. Tipusleíró tábláik (OsztalyTipus és PozicioTipus) 1:több kap-csolattal fix szintszámú hierarchiába kapcsolódnak, hogy leírják, mely osztályon milyen pozíciókra lehet szükség • Figyeljünk rá, hogy a Poziciok sosem konkrét sze-mélyeket ábrázolnak, mert azokat fölvehetik-elbo-csáthatják, hanem posztokat, amelyek megfelelnek az üzleti folyamat diagramm (BPD, lásd: Session1) tevékenység végzőinek, illetékességi sávjainak. • Mivel a Rendszerleírás dimenzió FelhasznTipus egyedének hasonló jelentése volt (lásd: Session4), ezt itt meg is hivatkozzuk a FelhasznTipusID idegen kulccsal. Így kapcsolódik össze a cég szervezeti rendszere az adatbázis felhasználói rendszerével.

10. A Szervezet dimenzió szerkezete 2 • Ha a dimenzió célja a cég személyzeti adattárának ábrázolása, a Pozicio egyed alatt megjelenik egy virtuális történet-jellegű egyed, a Kvalifikacio. Ez tárolja a személyzetisek (Human Resources Mana-gement, HRM) képzési tervét, vagyis, hogy adott pozíció betöltőjének a kezdéstől számított relatív időintervallumokban (KezdDatum, VegDatum) milyen jogosítványokra, képzettségekre, munka-alkalmassági bizonyítványokra, stb. kell szert tennie. Ez azonban csak a virtuális tervet tárolja, és nem a ténleges teljesítését, ami lentebb az Alkalmazas-Tort egyedben tárolódik. • Azonban, mielőtt a pozíciók tényleges betöltésével foglalkoznánk, szükség van még az Alkalmazott egyedre, amely egy Szemely és egy Szervezet összekapcsolódásának körülményeit tárgyalja. Egy személy ugyanis egyszerre vagy időben egymás-után több pozícót betölthet a szervezetben, de vannak olyan dolgok (pl. Jutalmazások, Megrová-sok, Alapfizetés, Privilégiumok, Juttatások, Jártassá-gok, MagánNyugdíjalap), amit visz magával egyik pozícióból a másikba, mert nem pozícióhoz kötöttek. Ezeket lehet az Alkalmazott egyedhez kötögetni.

11. A Szervezet dimenzió szerkezete 3 Adott pozíció betöltésének adatait klasszikus MDH hierachia-szint táblanégyes írja le: • Az Alkalmazas egyed azt rögzíti, hogy valamely Alkalmazott betölt valamely Poziciot egy időintervallumban (Kezd-Datum, VegDatum) valamilyen Alkal-mazasTipusID jelleggel (pl. határozott idejű/határozatlan/helyettesítő, stb.) • Az AlkalmazasTort írja le, hogy ennek során mikor szerezte meg a Kvalifikacio tervben leírt képesítéseket és végzett-ségeket. Ez az információ redundáns, mert ezt már a Személy dimenzióban a Szemely táblához csatolt képesítésekben is tárolni tudjuk, az AlkalmazasTort azonban egy összesítést ad erről a könnyebb HR munka érdekében • Az AlkalmazasStatusz írja le az adott beosztás létrejöttének és megszűnésének okait (pl. Felmond, Kirúgják, Fegyelmivel elbocsátják, stb.)

12. A Szervezet dimenzió szerkezete 4 • Adott Pozicioban lévők a szervezet működése során időben műszakokra osztott tevékenységeket végeznek, ezt dokumentálni kell, a köznyelvben ezt hívják munkanaplózásnak vagy jelenléti ívekenek. A Session5-ben már láthattuk, hogy ezt úgy célszerű felépíteni, hogy egy VirtMuszak egyed műszakterveket tárol, amelyek időbeostását a fejlett Idő dimenzióra hivatkozó NapTipusID, NapSzakTipusID idegen kulcsok írják le, sok kézi-munkától megszabadító ciklikus definícióval. • Ez alá kapcsalódik a történet jellegű Muszak egyed, ami azt írja le, hogy adott konkrét naptári napon (NaptarID) megtörténtek-e az aznapra a VirtMuszakban tervezett műszakok • Mivel nem biztos, hogy ezek pont a tervezett idő intervallumban történnek meg az adott napon, a Muszak alá kapcsolódik még egy szint, a TulOra egyed, amely azt tartja nyilván, hogy adott mű-szakban a tervhez képest milyen NapSzakTarID időszeletekben jelentkezett túlóra (PozitivDef=1) vagy munkaidő kiesés (PozitivDef=0) • Hogy ez mi miatt volt, azt a TulOraTipusID-ben adhatjuk meg.

13. Az előadás tartalma A Tér-, Személy-, Szervezet dimenziók szerkezete az MDH-ban • A Tér dimenzió maximális rugalmasságú szerkezete • A Személy dimenzió szerkezete • A Szervezet dimenzió szerkezete • Kitekintés a Termék dimenzió szerkezetére Szakirodalom

14. A Termék dimenzió szerkezete Ezzel az MDH-dimenzióval a következő anyagrészben foglalkozunk majd részletesen, most csak olyan szempontból tekintünk előre, hogy hogyan épül rá a Tér, Személy és Szervezet dimenziókra: • Egy cégnek elég sokféle szervezet vagy személy lehet a partnere: a vevői, a beszállítói, a felügyelő hatóságai, a bankja, stb. Ezen szervezetek különböző szintjeiről számos személlyel állunk kapcsolatban, ráadásul, mivel őket is felveszik/ kirúgják, megváltozik az elérhetőségük a kontakt személyeket időben is nyomon kell követni. Ha nem tesszük meg a cég működése pusztán azért lelassulhat mert nem találja meg időben a kontak-tokat, és ez óriási anyagi kárt okozhat • Ezért nem kezdjük a külső logisztika leírását a vevők, beszállítók, stb. leírásával, hanem általá-nosítva, felveszünk egy Partner egyedet, amely bármely kontaktolható szervezet (KulsoSzervezet-ID), vagy annak egy osztálya (BelsoOsztályID) fele létesít hivatkozást, megjelölve a PartnerTipust • A Partner történet jellegű tábla is egyben, ezért KezdDatum, VegDatum van benne, és a Partner-StatuszID írja le, hogy tervezett/ élő kapcsolat, vagy milyen okból számoltuk fel • Az alatta lévő szint a Kontakt egyed, azt ábrázolja, hogy egyPartnerrel is többKontaktTipusú kap-csolatunk lehet (pl. értékesítés, vevőszolgálat, stb.) • Ráadásul ezeknek a kapcsolatoknak történetisége van, amit a KontaktTort egyed jelenít meg, össze-kötve a KontaktID-t a kontaktért felelős belső poszttal (BelsoPozicID), külső poszttal (Kulso-PozicID) vagy alkalmazottal (KulsoAlkalmazottID) vagy személlyel (KulsoSzemelyID)

15. Szakirodalom • Egyetemi személyzeti adatmodell Oracle-ben (angol): http://www.psmidatlanticrug.com/Presentations/The%20Person%20Model%20-%20Oracle%20081106.pdf • Az SAP személyzeti adatmodelljének tábláiról (angol): http://www.scribd.com/doc/454570/Total-SAP-Tables • Az SAP személyzeti adatok felhasználói felülete (angol): https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/40b0d690-0201-0010-2c86-9092407528c3 • ERP és személyzeti alkalmazásokkal foglalkozó honlap (angol): http://www.erpgenie.com/mysap/mysap_hr.htm • Adatbázistervezési honlap / ajánlások személyzeti adatstruktúrákhoz (angol): http://www.databaseanswers.org/data_models/hr_org_structure.htm