Ki kinek a vezetője?

OrganogramAz SQL lekérdezések újabb típusát adják a hierarchikus lekérdezések. Az Oracle adatbázis-szerver már régóta támogatja ezt a lehetőséget. A hierarchia legtöbbször valamilyen fa adatszerkezethez kötődik. Ezek természetesen nem közvetlenül tárolódnak egy normalizált, relációs adatbázisban, de az adatok közötti kapcsolat értelmezése során felépíthető rekurzív módon a fa struktúra.

Hasonló feladat: Organogram készítése, reflexióra építve. Érdemes összehasonlítani a kétféle szemléletmódot.

Ki kinek a vezetője?

Az Oracle HR sémában az EMPLOYEES és DEPARTMENTS táblák között kétirányú 1:N kapcsolat van. Egy EMPLOYEE_ID egyedi kulccsal azonosított alkalmazotthoz tartozik egy nem kötelező DEPARTMENT_ID külső kulcs az EMPLOYEES táblában. Egy kivétellel minden alkalmazott részleghez hozzárendelt.

Oracle HR séma

Egy DEPARTMENT_ID egyedi kulccsal azonosított részleghez tartozik egy nem kötelező MANAGER_ID külső kulcs a DEPARTMENTS táblában. Minden olyan részlegnek van vezetője, amelyikhez legalább egy alkalmazott hozzárendelt. A DEPARTMENTS táblában csak olyan MANAGER_ID szerepelhet, amelyik megtalálható az EMPLOYEES táblában EMPLOYEE_ID-ként. A „legfelsőbb” szinten lévő vezetőnek nincs vezetője.

Előfordulhat, hogy egy-egy részlegen belül többszintű hierarchiát találunk az organogramban, ha a részlegek helyett az alkalmazottak oldaláról közelítjük meg a problémát. Ekkor építhetünk arra, hogy az EMPLOYEES tábla saját magával is kapcsolatban áll (reflexió): egy MANAGER_ID-hez több EMPLOYEE_ID is tartozhat. Másképpen: egy adott vezetőnek több beosztottja is lehet.

A hierarchikus (rekurzív) lekérdező parancs

Ki kinek a vezetője? - Hierarchikus SQL lekérdező parancs

A lekérdező utasítást bele kell építeni egy Java kliensprogramba (MVC architekturális tervezési minta szerint a modell rétegbe), ami JDBC alapon kapcsolódik az Oracle adatbázis-szerver HR sémájához olyan felhasználó nevében, aki csatlakozhat és lekérdezhet. Meg kell tervezni és felügyelni kell a biztonságos kapcsolatot (kivételkezeléssel), annak életciklusát (nyit, lekérdez, zár), valamint gondoskodni kell az eredménytábla megjelenítéséről.

Az eredménytábla (részlet)

Ki kinek a vezetője? - Eredménytábla

A keletkező eredménytábla exportálható Excel-be (XLS, XLSX formátumokba). Az első vagy utolsó oszlop adatait feldolgozva könnyen készíthető egy dinamikus adatmodellel rendelkező, fa struktúrát megjeleníteni képes komponens/felület, ahol szabadon böngészhető a szervezeti hierarchia.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladat a Java adatbázis-kezelő tanfolyam 9-12. óra: Oracle HR séma elemzése, 13-16. óra: Konzolos kliensalkalmazás fejlesztése JDBC alapon, 1. rész, 33-36. óra: Grafikus kliensalkalmazás fejlesztése JDBC alapon, 2. rész alkalomhoz kapcsolódik.

Az SQL forráskód formázásához a Free Online SQL Formatter-t használtam.


Ajánljuk a Java adatbázis-kezelő tanfolyam kategóriából

“Ki kinek a vezetője?” bejegyzéshez 9 hozzászólás

  1. Az a gond, hogy a valóságban egy dolgozónak több managere lehet (Pl.: 3 igazgató és 5 team leader, két különböző departmentnél).

    A departmenten belül is lehet több department. Pl. egy resortnál több szálloda vagy challet van ugyanazon a helyen és az intézményen belül is különféle departmentek vannak: shop, splash, restaurant, hr (restaurant, hotel, office hr), illetve azokon kívül is helyezkedhetnek a departmentek.

    A department funkció szerepet is tölthet be, ez esetben semmiképp nem tanácsos egy közös táblában tárolni (csak elvont adatait), mert csak azok szerepelhetnek pl. „restaurant” departmentben, akik közzé nem sorolható más department, pl.: hr.

    Egy dolgozónak több pozíciója lehet ez alap: egy HR-es dolgozhat a Payrollnál is, aminek a bérezése lehet más, de lehet ugyanaz is! Illetve a bérezés az függhet a pozícióktól is (ki mikor melyik pozícióban dolgozik; illetve lehet állandó is vagy emberenként más (felülbírálható), illetve kortól is más, illetve a bérezés típusától.

    Ezek csak a valóságból levont következtetések. Amúgy egy kis cégnek (vagy pl. egyéninek) jó az SQL adatmodell.

    Válasz
    • Jó példákat írtál, köszönöm. Ez a HR minta adatbázis kiinduló állapota, amit készen kapunk. Egy tutorial-on végighaladva, sok mindennel bővül még. Specifikációjánál törekedtek arra, hogy lefedjék a tipikus igényeket.

      Például:
      – van többszintű (max. 4) hierarchia: az Executive részleg De Haan nevű alkalmazottja vezetője Hunoldnak, aki az IT részleg vezetője négy alkalmazottal (Austin, Ernst, Lorentz, Pataballa). A kapcsolat közvetlenül az alkalmazottak szerepei miatt valósul meg, közvetve pedig a részlegek között is megjelenik,
      – van munkakörökhöz kötődő kezdetleges „életpálya modell”: a JOB_ID-hez tartozik MIN_SALARY és MAX_SALARY, és az adott tartományba esik minden alkalmazott fizetése tapasztalat és HIRE_DATE alapján egyaránt.

      Persze sok-sok egyéb hétköznapi dolog nem szerepel ebben az adatbázisban: ki gyakorolja a munkáltatói jogokat, ki kit helyettesíthet, egyenlő bánásmód, utasítási rend, kooperatív csoportmunka esetén ki a felelős a projektért, de azért bőven lehet izgalmas dolgokat lekérdezni belőle.

      Válasz
    • Tibor: dehogynem, de akkor az eredménytáblát feldolgozó Java kliensprogram jóval összetettebb. Van ilyen kliensprogramunk is. Hamarosan odaérünk a tematikában és megmutatom majd az órán. Mindig egyensúlyozunk a terhelés elosztása során a szerver és a kliens között. A blogban mutatott megoldás inkább a szervert terheli.

      Válasz
    • Elvi korlát nincs Anikó. A gyakorlatban 3-5 szintnél nem nagyon megyünk lejjebb a fastruktúrában. Például: webáruházak termékkatalógusai, blogok menüpontjai, kategóriái, címkéi.

      Válasz
  2. Családfát szeretnék gyakorlásként tervezni és Java nyelven kódolni. Hasonlót, mint ez az szöveges eredménytábla, vagy esetleg olyat, mint a Fát építünk swing JTree-s példában. Ha szöveges, akkor táblázatos is jó lenne, mint például II. Erzsébet ősei.
    Sanyi: tudnál erre ajánlani mintaprogramot?
    Az adatszerkezetet már értem: POJO lesz rekurzív mezővel.

    Válasz
    • A swing tutorial-ból ezt javaslom Tamás: Genealogy Example.
      Oda-vissza képes JTree GUI komponensben megjeleníteni a családfában található ősöket és leszármazottakat (navigálni is köztük).

      A POJO saját magára hivatkozó mezővel alkalmas a fa adatszerkezethez. Azt javaslom, hogy könnyen szerkeszthető XML-ben tárold az adatokat, például így: Evaluation: XML And Your Family Tree. Ezután ebből építsd fel a POJO-kbó álló fa szerkezetet, amit megjelenítesz a GUI-n. Ne égesd bele a Java forráskódba konstansként az objektumok deklarációit.

      Válasz

Szólj hozzá!