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.

Slides:



Advertisements
Hasonló előadás
A Savaria Egyetemi Könyvtár Katalógusa Böngészés Keresés Találatok megjelenítése Adatbázis választás Olvasói tranzakciók.
Advertisements

Oktatásszervezési változások. Mintatantervi változások.
Kérem válassza ki azt a pozíciót, ami Önt érdekli, ha a pozíció nevére kattint megjelenik a leírása (munkakör célja, munkaköri követelmények, konkrét feladatok).
Statisztika 2008 Az elektronikus program használata.
A weboldalunkon regisztrált felhasználó neveddel és jelszavaddal tudsz belépni. Amennyiben még nem regisztráltál oldalunkon, abban az esetben kérjük,
Miskolci Egyetem Gépészmérnöki és Informatikai Kar Alkalmazott Informatikai Tanszék 2012/13 1. félév 4. Előadás Dr. Kulcsár Gyula egyetemi docens.
ADATBÁZISOK.
E-learning alapú távoktatásos képzés
A normalizálás az adatbázis-tervezés egyik módszere
Adatbázis-kezelés.
E.ON – Versenyben Önökért!
Rendszertervezés GIMP.
AVIR – intézményi adatmodell Csulyák Gábor Informatikai igazgató Educatio Nonprofit Kft február 2.
A projekt az Európai Unió támogatásával, az Európai Szociális Alap társfinanszírozásával valósul meg A projekt az Európai Unió támogatásával, az Európai.
Savaria Egyetemi Könyvtár Katalógusa Böngészés Keresés Találatok megjelenítése Adatbázis választás Olvasói tranzakciók.
Adatbázis (alapfogalmak).
AlertPay Internetes Számlához Bankszámla hozzárendelése és pénz feltöltése az AP. -re Lépj be az AlertPay oldaladra:
Fekvőbeteg adatbázis szervezés GyógyinfokPirisa Levente.
Az egyed-kapcsolat modell
Értékteremtő folyamatok menedzsmentje
Microsoft Access V. Készítette: Rummel Szabolcs Elérhetőség:
Információ kezelés Az információ visszakeresésének lehetőségei.
Adatbázis-kezelés.
KOVÁCS DÁVID. ALAPFOGALMAK Adatbázis: Olyan adatgyűjtemény, amely egy adott feladathoz kapcsolódó adatokat szervezett módon tárolja, és biztosítja az.
16. Tétel. Adatbázis: Olyan adatgyűjtemény, amely egy adott feladathoz kapcsolódó adatokat szervezett módon tárolja, és biztosítja az adatokhoz való hozzáférést,
Vállalati folyamatok, alrendszerek, tömegszerűség, külső környezet, belső adottságok, hierarchia, kultúra.
Hernyák Zoltán XML validálás.
2011. szeptember Az információtechnológia menedzselése Az információs rendszer fejlesztése Image of the slide: www2.raritanval.edu/departments/busadmin/.../Ch07-IntrotoBusiness.ppt.
Raktári jelzet a könyvtárakban
AlertPay internetes számlához bankszámla hozzárendelése és pénz feltöltése az AP -re Lépj be az AlertPay oldaladra:
AlertPay regisztráció Az AlertPay regisztráció feltételei közt szerepel a legalább 18 éves korhatár betartása. Az alábbi regisztrációs lehetőségek közül.
MSACCESS Bevezetés. Üzemeltetés Hozzáférés Jogosultságok Karbantartás Mentés Stb. Felhasználói felület Űrlapok Jelentések Menük Stb. Adatnézetek, funkcionalitás.
Statisztika, kutatásmódszertan I.
Adatbázis-tervezés konzultáció 10. Gyakorlat Dr. Pauler Gábor, egyetemi docens, ev. Adószám: Számlaszám: Telephely: 7666.
Adatbázis-tervezés konzultáció 6. Gyakorlat Dr. Pauler Gábor, egyetemi docens, ev. Major László Adószám: Számlaszám: Telephely:
Adatbázis-tervezés konzultáció 9. Gyakorlat Dr. Pauler Gábor, egyetemi docens, ev. Adószám: Számlaszám: Telephely: 7666.
Adatbázis-tervezés konzultáció 2. Gyakorlat Dr. Pauler Gábor, egyetemi docens, ev. Adószám: Számlaszám: Telephely: 7666.
Adatbázis-tervezés konzultáció
Adatbázis-tervezés konzultáció 8. Gyakorlat Dr. Pauler Gábor, egyetemi docens, ev. Adószám: Számlaszám: Telephely: 7666.
Többtáblás adatbázisok
XHTML 1. óra. Miért térjünk át HTML-ről XHTML- re? HTML-szabványban tartalom és forma összemosódott HTML 4.0 szabványban stíluslapok használatát javasolták.
11. tétel Adatbázis táblái közti kapcsolatok optimalizálása
Adatbázis kezelés. Az adatbázis tágabb értelemben egy olyan adathalmaz, amelynek elemei – egy meghatározott tulajdonságuk alapján – összetartozónak tekinthetők.
Törzsek-Partnerek A partnerek menüpont alatt végezhetjük a partnerek nyilvántartásával kapcsolatos műveleteket. A partnertörzsben vesszük fel a partnerek.
Adatbázis kezelés.
A regisztráció megkezdése: Kattints a SIGN UP NOW gombra
Adatbázis-kezelés.
Adatbázis-kezelés Probléma: az excel kezelhetetlen túl sok adat esetén
Adatbázis-kezelés.
Kulcsok meghatározása a táblákban
Adatbázis alapfogalmak
A kis- és közepes vállalkozások információs rendszerei Erdős Ferenc.
Webprogramozó tanfolyam
Adatbáziskezelés. Adat és információ Információ –Új ismeret Adat –Az információ formai oldala –Jelsorozat.
Az iOS 8 egy ideje már elérhet ő - aki már frissítette az Apple készülékét (vagy vett egy újat), az már sok apró trükkre rájöhetett az aktuális almás.
Munkakörelemés és –tervezés röviden
DNS. Az interneten használt osztott név adatbázis, a DNS (Domain Name Service) folyton használatos: –minden web lap letöltésnél, –levél közvetítésnél.
 Adatbázis:  Valamilyen szempont szerint rendszerezett adathalmaz.  Adatbázis kezelés:  Adatok tárolása  Műveletek végzése az adatbázison; (Adatok.
- Regisztrációs útmutató - Participant Portal (URF)
Adatbázisszintű adatmodellek
Pécsi Tudományegyetem Pollack Mihály Műszaki Kar Műszaki Informatika Szak Data Mining 11. Gyakorlat Dr. Pauler Gábor, Egyetemi Docens PTE-PMMK Számítástechnika.
Gazdasági informatika II (SZIE GTK GVAM 1. évfolyam) 2009/2010. tanév 2. félév.
A szaktudás dokumentálása – Europass. Ahány ország, annyi…  Oktatási és képzési rendszerek különbözőek  A kompetenciák és képzettségek különbözőek,
Készítette: Kiss András
Országos Statisztikai Tanács
Az adatforrásokról és aktualizálási rendjéről
Adatbáziskezelés.
Relációs adatmodell, normálformák
Adatbázis-kezelés 2. Relációs adatbázisok.
A rendszer felépülése Fenntartó – engedélye(k), ha közvetlenül nyújt szolgáltatást Intézmény/ Szolgáltató – székhely típusú szolgáltatás nyújtási hely.
Előadás másolata:

Adatbázis-tervezés konzultáció 7. Előadás Dr. Pauler Gábor, egyetemi docens, ev. Adószám: Számlaszám: Telephely: 7666 Pogány, Széchenyi u. 1. Tel: 30/

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

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álisSession6MintaERD1.vsd 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!

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.Session6 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, /nem otthoni, céges!/, URL) Minden más elektronikus elérhetőség (pl. Mobil, Szemelyi , Skype) majd a Szemely egyedhez csatolt Elerhetoseg egyedben fog tárolódni.

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

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)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, , 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! Session5

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 egy KepesitTipushoz több KepesSzint 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

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

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.Session1 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.Session4

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.

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.)

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.Session5 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.

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

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 egy Partnerrel is több KontaktTipusú 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)

Egyetemi személyzeti adatmodell Oracle-ben (angol): %20Oracle% pdf %20Oracle% pdf Az SAP személyzeti adatmodelljének tábláiról (angol): Az SAP személyzeti adatok felhasználói felülete (angol): c c c c3 ERP és személyzeti alkalmazásokkal foglalkozó honlap (angol): Adatbázistervezési honlap / ajánlások személyzeti adatstruktúrákhoz (angol): Szakirodalom