A hálós adatmodell

A hálós modell történetileg a nagy mennyiségű, összekapcsolt adatok hatékony kezelésének igényére épült. A CODASYL adatbázis-munkacsoportjának leírásai a hetvenes évek elején tették széles körben ismertté ezt a megközelítést. A tervező nemcsak azt mondja meg, milyen rekordok léteznek, hanem azt is, milyen kapcsolatokon keresztül lehet egyik rekordtól a másikig eljutni.

A hálós elnevezés az adatbázis szerkezetére utal, nem számítógép-hálózatokra vagy internetes adattárolásra. Egy rekord több, különböző SET-típus tagjaként többféle kapcsolatban is szerepelhet. Ez a lehetőség oldja a szigorú, egyetlen szülőre épülő fa korlátait, de a szerkezetet tudatosan meg kell tervezni.

A modell navigációs szemléletű. A program gyakran egy rekordot választ ki, majd annak kapcsolatait követve keres további rekordokat. A „keresd meg a műhelyt, járd be a hozzá tartozó eszközigényeket, és keresd meg az eszközöket” műveletsor tipikus hálós gondolatmenet. Relációs környezetben ugyanezt a célt többtáblás lekérdezés is megfogalmazhatja.

A hálós modell nem egyszerűen hibás vagy elavult relációs modell: más logikai szervezési és elérési megközelítés. Tanulásakor azt vizsgáljuk, milyen szerkezetekkel fejez ki kapcsolatokat, és milyen többletmunkát kíván az útvonalak kezelése. A ma ismert gráfadatbázisokkal sem szabad automatikusan azonosítani: a klasszikus CODASYL SET kötött tulajdonos–tag szabályai sajátosak.

A MUHELY rekordtípus például a muhely_id, cim, kezdes és max_letszam mezőket tartalmazhatja. A Robotépítés műhely egy konkrét rekord: az azonosítója 101, kezdési időpontja 2026. november 6. 14 óra, létszámkorlátja 24. A rekordtípus a szerkezetet, a rekord az adott előfordulás értékeit adja.

Az adatelem a rekordban névvel és típussal megadott mező. Az azonosító lehet egész szám, a cím szöveg, a kezdés időpont. A típusok és a mezőhosszak a rendszer által elfogadott értékeket befolyásolják. Egy telefonszámot például rendszerint szövegként célszerű tárolni, mert a pluszjel és a kezdő nullák is jelentést hordozhatnak.

Összetett attribútum esetén az összetartozó részmezők csoportot alkotnak. Egy kapcsolattartó neve állhat családnévből és utónévből; a cím irányítószámból, településből és utcából. Ez a rekord szerkezetének felosztása, nem önálló SET-kapcsolat.

A többértékű attribútum hálós környezetben vektormezőként, az összetett többértékű tulajdonság pedig ismétlődő csoportként is megjelenhet. A konkrét lehetőségek és korlátok rendszerfüggők. Ha az értékeket önállóan azonosítani, más rekordokhoz kapcsolni vagy sokszor módosítani kell, külön rekordtípus jobb megoldás lehet.

Egy HELYSZIN rekordhoz több MUHELY rekord tartozhat. A HELYSZIN_MUHELY SET tulajdonos rekordtípusa HELYSZIN, tag rekordtípusa MUHELY. A típust bemutató Bachman-diagramon a kapcsolat a tulajdonostól a tag felé irányul. A kapcsolat neve a két rekordtípus között szerepel.

A SET nem azonos a matematikai halmazzal. Van kitüntetett tulajdonosa, a tagokhoz tartozik bejárási sorrend, és a tulajdonos típusa eltér a tagokétól. A rekordok sorrendjét adhatják mezőértékek, beszúrási szabályok vagy rendszerbeli döntések. A „halmaz” kifejezést ebben a sajátos adatbázis-értelemben használjuk.

Egy helyszín akkor is tulajdonosa lehet egy SET-előfordulásnak, ha még nincs hozzá rendelt műhely. A tulajdonos tehát nem követeli meg legalább egy tag létezését. Fordítva a tag önálló létezésének megengedettségét külön tagsági szabály határozza meg.

Egy adott SET-típusban egy tagrekord egy időben legfeljebb egy SET-előforduláshoz tartozik. A Robotépítés műhely a HELYSZIN_MUHELY típuson belül nem lehet egyszerre két helyszín tagja. Más SET-típusban azonban ugyanaz a műhely egy oktatóhoz is kapcsolódhat. E különbség adja a hálós szerkezet egyik lényeges sajátosságát.

A HELYSZIN_MUHELY típusból a Makerspace helyszínhez egy előfordulás tartozik, a Digitális laborhoz pedig egy másik. Az elsőben Robotépítés és 3D-prototípus műhely szerepelhet, a másodikban Adatvizualizáció. A két előfordulás a kapcsolat azonos szerkezetét valósítja meg, de más rekordokkal.

A tagok száma előfordulásonként különbözhet. Egy új helyszín előfordulása üres is lehet. Ha egy tagot szabályosan másik helyszínhez kapcsolunk, a tagság módosul, nem a HELYSZIN_MUHELY típus definíciója változik.

Az előfordulási diagramon konkrét azonosítókat és értékeket használunk. A típusdiagram mezőneveit nem helyettesítjük észrevétlenül konkrét nevekkel: az olvasónak mindig tudnia kell, hogy szerkezetet vagy adatállapotot lát.

Ha azt mondjuk, „a műhely több tulajdonoshoz tartozik”, meg kell nevezni a SET-típusokat is. Egy műhely HELYSZIN_MUHELY-beli tulajdonosa lehet Makerspace, OKTATO_MUHELY-beli tulajdonosa pedig Fekete Réka. Ez nem ugyanannak a SET-típusnak két külön tulajdonosa.

A klasszikus szemléltetésben a SET-előfordulás rekordjai körkörös láncot alkotnak. A tulajdonostól az első taghoz, a tagtól a következőhöz, az utolsótól pedig a kör lezárásához jutunk. Ez fizikai megvalósítási kép, nem új logikai kapcsolat a tagok között.

A first, next és prior jellegű mutatók az első, következő vagy előző rekord elérését segíthetik, az owner mutató a tulajdonos közvetlen megtalálását teszi lehetővé. A mutatók konkrét tárolási módja és rendelkezésre állása a DBMS-től függ; nem minden hálós rendszer belső rekordképe azonos.

A SET tagjainak sorrendje eltérhet a rekordok üzleti azonosítójának sorrendjétől. Ha kezdes szerint rendezzük a műhelyeket, a NEXT a következő időpontú műhelyt jelenti az adott előfordulásban. Ha beszúrási sorrendet használunk, ugyanez a parancs más rekordhoz vezethet.

A bejárási útvonal megválasztása teljesítmény és programozási szempontból is fontos. Ismert helyszínből gyorsan elérhetjük annak műhelyeit, de „minden műhely, amelynek címében robot szerepel” nem feltétlenül ugyanilyen természetes elérési út. Ehhez külön keresési lehetőség vagy más útvonal szükséges.

Egy rendszer által tulajdonolt MUHELYEK SET hozzáférést adhat a műhelyrekordok összességéhez. A tulajdonos nem egy felhasználói helyszín- vagy oktatórekord, hanem rendszerbeli kiindulópont. A bemutatott egyetlen rendszertulajdonos előfordulásban a műhelyek mind elérhetőek lehetnek.

A rendszertulajdonos kapcsolat nem ad új üzleti jelentést a rekordoknak. Nem azt állítja, hogy a rendszer szervezi az összes műhelyt, hanem egy nyilvántartási és hozzáférési szerkezetet fejez ki. Ezért a SYSTEM jelzés nem kezelhető közönséges alkalmazási egyedként.

Rekurzív példa a mentorálás: egy SZEMELY más SZEMELY előfordulásokat mentorál. A szerepek mentor és mentorált. Ha közvetlen azonos típusú tulajdonos–tag SET-et nem használhatunk, külön MENTORALAS kapcsolórekordot hozunk létre, amely két SET tagja: az egyik tulajdonosa a mentor, a másiké a mentorált személy.

A kapcsolórekord kezdési időpontot és megjegyzést is tárolhat. Ha a kapcsolat többször létrejöhet ugyanazon pár között, külön azonosító vagy időszak is szükséges az előfordulások megkülönböztetésére. A szerepek megnevezése akkor is fontos, ha mindkét tulajdonos ugyanabból a rekordtípusból származik.

Egy ER-egyedtípusból általában rekordtípus lesz. Az egyszerű attribútumok adatelemként, az összetett attribútumok csoportként jelenhetnek meg. Többértékű tulajdonságot vektormezővel vagy ismétlődő csoporttal is kezelhetünk, ha ez illeszkedik a rendszer képességeihez és a használathoz.

Az attribútum leképezése nem pusztán formai művelet. Egy önálló azonosítóval rendelkező eszköz nem ugyanaz, mint egy műhelyben felsorolt egyszerű szöveges címke. Ha az eszköz más kapcsolatokban is szerepel, saját rekordtípusra van szüksége.

Gyenge egyednél a tulajdonoshoz kötött létet is meg kell őrizni. Egy műhelyen belüli sorszámmal azonosított FELADAT rekordot a MUHELY_FELADAT SET-ben lehet elhelyezni. A sorszám csak az adott műhelyen belül egyedi, ezért a tulajdonosi környezet nélkül nem teljes az azonosítás.

Ha a gyenge egyed egyszerű ismétlődő adatcsoportként tárolható, és máshonnan nem kell rá hivatkozni, beágyazott csoport is szóba jöhet. Ha önálló kapcsolatai vannak vagy külön kezelendő, a saját rekordtípus és SET egyértelműbb. A választásnál a jelentést és a kezelési igényeket együtt vizsgáljuk.

Egy RESZTVEVO legfeljebb egy személyre szóló BELÉPŐ-t kaphat, minden kiadott BELÉPŐ pedig pontosan egy résztvevőhöz tartozik. A résztvevő részvétele lehet részleges, a belépőé teljes. A RESZTVEVO tulajdonos és BELEPO tag szerep kézenfekvő: a belépő nem létezhet résztvevő nélkül, résztvevő viszont belépő nélkül is nyilvántartható.

Egy SET alapértelmezett tulajdonos–tag szerkezete 1:N jellegű. Az 1:1 jelentés megőrzéséhez ezért külön kell biztosítani, hogy egy tulajdonoshoz legfeljebb egy tag tartozzon. A SET puszta felrajzolása nem teszi automatikusan egy-tagúvá az előfordulásokat.

A kapcsolat attribútuma, például a kiadás dátuma, a tagrekordba kerülhet, ha egyértelműen ahhoz az egy kapcsolathoz kötődik. A résztvevő általános neve vagy e-mail-címe ettől még a RESZTVEVO rekord tulajdonsága marad.

Ha mindkét oldalon teljes a részvétel, a tulajdonos választása további tervezési döntés. Ha egyik oldalon sem kötelező, a tagsági szabályokat és az előfordulási korlátokat különösen gondosan kell megfogalmazni. A szerkezet és az integritási előírás együtt adja vissza az ER-modell jelentését.

A HELYSZIN–MUHELY kapcsolatban a helyszín az 1 oldal, a műhely az N oldal. Egy műhely az adott SET-típus egyetlen helyszín-előfordulásához tartozik. Egy helyszínhez több műhely kapcsolódhat, így a SET természetes módon adja vissza az 1:N maximumot.

A részvétel minimumát itt is a tagsági szabályok és az üzleti követelmények határozzák meg. Ha egy műhelyet ideiglenesen helyszín nélkül is rögzíthetünk, opcionális tagság szükséges. Ha minden műhelyhez azonnal létező helyszín kell, a létrehozás és tagság együtt kezelendő.

A kapcsolat saját attribútuma, például egy adott helyszín használati díja az adott műhelynél, a tagrekordban tárolható, mert a műhely ebben a kapcsolatban egyetlen tulajdonoshoz tartozik. A helyszín állandó címe viszont a HELYSZIN rekordé.

A tulajdonos azonosítója a tagrekordban külön mezőként is szerepelhet, ha a rendszer vagy az alkalmazás megköveteli. A hálós kapcsolat tényleges bejárása azonban a SET kapcsolatán alapul. Nem szabad úgy tenni, mintha a kulcsérték beírása minden rendszerben automatikusan létrehozná a tagságot.

Egy MUHELY több ESZKOZ-t használhat, és ugyanaz az ESZKOZ több műhelyben is szerepelhet. Közvetlen egyetlen SET nem elegendő: az eszköz egy SET-típusban legfeljebb egy műhely előfordulásához tartozhatna. Ezért a használati kapcsolatot külön HASZNALAT rekordokkal írjuk le.

A MUHELY_HASZNALAT SET tulajdonosa MUHELY, tagja HASZNALAT. Az ESZKOZ_HASZNALAT SET tulajdonosa ESZKOZ, tagja ugyanaz a HASZNALAT rekordtípus. Egy konkrét használat így pontosan egy műhelyt és egy eszközt kapcsol össze, miközben mindkét tulajdonosnak több használati tagja lehet.

A darabszám vagy a foglalás időtartama a használat tulajdonsága. Nem a műhely általános mezője, mert eszközönként eltérhet; nem is az eszköz általános mezője, mert műhelyenként eltérhet. A kapcsolórekord éppen ezt a köztes jelentést őrzi.

A kapcsolórekord nem feltétlenül üres technikai segéd. A kapcsolat attribútumainak helye és a bejárás csomópontja is. Ha ugyanaz az eszköz ugyanabban a műhelyben több külön időszakban szerepelhet, a használatok azonosítását is meg kell tervezni, például hasznalat_id vagy időszak segítségével.

A KIADAS kapcsolat azt rögzíti, melyik MUHELY számára melyik ANYAG-ból melyik RAKTAR ad ki egy meghatározott mennyiséget. Az anyag–műhely kapcsolat mellé a kiadó raktár önálló résztvevőként kerül. A mennyiség a teljes hármashoz tartozik.

A KIADAS kapcsolórekord három SET tagja: MUHELY_KIADAS, ANYAG_KIADAS és RAKTAR_KIADAS. Egy kiadási előfordulásnak mindhárom kapcsolatban egy tulajdonosa van. A kiadas_id az ismétlődő kiadási események megkülönböztetésére szolgálhat.

A három részvevő összefüggését általában nem helyettesíti három egymástól független páronkénti kapcsolat. Abból, hogy egy raktár tárol anyagot és egy műhely használja azt, még nem derül ki, ténylegesen melyik raktárból adták ki a műhely részére. A kapcsolórekord az összetartozó szerepeket együtt tárolja.

Az owner művelethez a megfelelő SET-nevet is meg kell adni. Ugyanabból a KIADAS rekordból más tulajdonost kapunk MUHELY_KIADAS, mint ANYAG_KIADAS szerint. A több SET-ben való tagság hasznos, de az útvonalat pontosan kell megnevezni.

Automatikus beszúrásnál a rendszer a létrehozott rekordot a meghatározott SET-előfordulásba kapcsolja. A megfelelő tulajdonos kiválasztását a definíció és az aktuális környezet szabályozza. Nem elegendő csak azt mondani, hogy „automatikus”: azt is tudni kell, melyik előforduláshoz kerül az új tag.

Kézi beszúrásnál az új rekord tárolása és a tagság létrehozása két elkülönülő lépés. Egy tervezett műhelyet például előbb helyszín nélkül rögzítünk, majd később CONNECT művelettel hozzárendelünk egy helyszínhez. Ez csak akkor megengedett, ha az önálló létezésre vonatkozó szabályokkal összeegyeztethető.

A beszúrási szabály a tagság keletkezésének módjáról szól; nem azonos a későbbi megtartási szabállyal. Az automatikusan kapcsolt rekord későbbi leválasztása lehet megengedett vagy tiltott. A két döntést külön kell megfogalmazni.

A konkrét DBMS nem feltétlenül minden elméletben megkülönböztetett kombinációt támogat azonos módon. A tananyag a fogalmi különbséget mutatja meg, a végrehajtható definícióhoz a használt rendszer tagsági opcióit és állapotkezelését kell követni.

Optional tagságnál megengedhető, hogy a rekord SET-tagság nélkül is létezzen. Egy műhelyet leválaszthatunk a helyszínéről, majd később másikhoz kapcsolhatunk. A leválasztás a rekord többi SET-tagságát nem feltétlenül szünteti meg.

Mandatory tagságnál a már kapcsolt tagot nem hagyhatjuk egyszerűen az adott SET-típus előfordulásán kívül. Ha tulajdonosváltás megengedett, azt szabályos átkapcsolásként kell elvégezni. A beszúrás kezdeti állapotának részletei a választott opciókombinációtól és a rendszertől függenek; a kifejezést nem szabad minden DBMS-ben azonos életciklus-szabályként kezelni.

Fixed tagság erősebb kötöttséget jelent: a létrejött tulajdonosi kapcsolat nem cserélhető szabadon másik előfordulásra. Például egy műhelyen belül definiált, tulajdonoshoz kötött feladatot nem helyezünk át egyszerűen másik műhelyhez. A rekord törlése és a kapcsolat megszüntetése nem ugyanaz a művelet.

Tulajdonos törlésekor a tagok kezelése külön kérdés. A rendszer és a definíció szerint lehet tiltás, leválasztás vagy tagok törlése. Nem következik az optional szóból, hogy minden rekord automatikusan törlődik, és a mandatory sem minden esetben jelent általános kaszkád törlést. A törlési hatást külön kell ellenőrizni.

A SET NAME, OWNER és MEMBER jellegű elemek a név és a szereplők megadását szolgálják. Az INSERTION és RETENTION a tagság létrehozását és későbbi megőrzését írja le. A pontos parancsszöveg a DBMS nyelvétől függ; itt a szerkezet tartalmát tanuljuk, nem általános SQL-szintaxist.

A tulajdonos kiválasztása támaszkodhat az alkalmazás aktuális állapotára, megadott értékekre vagy a definícióban rögzített szerkezeti szabályra. Ha a program rossz helyszínt állít aktuálissá, az új rekord rossz előforduláshoz kapcsolódhat, ha más ellenőrzés nem védi. Ezért az aktuális tulajdonos kiválasztása tudatos programlépés.

A SET sorrendje lehet megadott kulcsmező szerinti növekvő vagy csökkenő rend. Más lehetőség az elejére vagy végére beszúrás, illetve az aktuális tag előtt vagy után elhelyezés. A rendszer alapértelmezett sorrendje is külön választás.

Rendezett SET esetén a rendezési mező módosítása a bejárási helyet is befolyásolhatja. A megvalósításnak meg kell őriznie a definícióban előírt rendet. A program nem támaszkodhat olyan sorrendre, amelyet a séma nem garantál.

SET NAME IS HELYSZIN_MUHELY
OWNER IS HELYSZIN
MEMBER IS MUHELY
INSERTION IS AUTOMATIC
RETENTION IS MANDATORY
ORDER IS SORTED BY kezdes ASCENDING
OWNER SELECTION: az alkalmazás által kijelölt helyszín

A hálós programnak nyilván kell tartania, hol tart a keresésben. Létezhet a futási egység aktuális rekordja, egy rekordtípus aktuális rekordja és egy SET-típus aktuális előfordulása. Ezek nem feltétlenül ugyanazt az állapotot írják le. A következő művelet értelmezése attól függ, melyik mutatót használja.

Az UWA, vagyis User Work Area a befogadó program változóinak munkaterülete. A rekord kiolvasott értékei ide kerülnek, és az új vagy módosítandó mezőértékeket is itt készítheti elő a program. Az adatbázisbeli rekord kiválasztása és értékeinek munkaterületre másolása két külön gondolat.

A FIND jellegű művelet navigálhat és megváltoztathatja az aktuális rekordot anélkül, hogy a program összes mezőváltozója már a kiválasztott rekord tartalmát kapná. A GET jellegű művelet olvassa be az értékeket. A konkrét DBMS-ben lehetnek összevont műveletek is; a fogalmi szétválasztás akkor is hasznos.

Minden művelet után státusz jelzi a sikert vagy a rendellenes állapotot. A „nincs több tag” gyakran szabályos bejárásvégi jelzés, nem adatromlás. Más státusz azonban valódi hibát jelezhet. A programnak ezeket meg kell különböztetnie, és nem szabad sikertelen keresés után az előző rekordot új találatként használni.

A FIND ANY rekordtípus USING mezők jellegű keresés a megadott keresési értékeknek megfelelő rekordot választja ki. A FIND FIRST, NEXT, PRIOR vagy LAST WITHIN SET az aktuális SET-előfordulás tagjai között mozog. A FIND OWNER WITHIN SET az adott tagság tulajdonosát keresi meg.

A GET ezután az aktuális rekord adatelemeit olvassa a munkaterületre. Ha több típus vagy több SET szerepel egy feladatban, a programnak tisztáznia kell, melyik rekord aktuális, és melyik előfordulás bejárási állapotát őrzi. Az útvonal „műhely → használat → eszköz” két külön kapcsolati szerepet érint.

Például M101 használatait felsorolva U1-ről az ESZKOZ_HASZNALAT owner művelettel E1-hez jutunk. Az eszköz kiolvasása után a következő használatot továbbra is a MUHELY_HASZNALAT előfordulásból kell keresni. Egy valós implementációban szükség lehet az aktuális állapot mentésére vagy tudatos újraállítására.

A ciklusnak a sikeres tagkereséshez kötöttnek kell lennie. Az utolsó tag után a bejárás véget ér; nem szabad a tulajdonost vagy a korábbi UWA-értékeket új tagként feldolgozni. A szemléltető algoritmus ezért külön státuszellenőrzést tartalmaz.

FIND MUHELY WHERE muhely_id = 101
IF sikeres THEN
  FIND FIRST HASZNALAT WITHIN MUHELY_HASZNALAT
  WHILE sikeres_tagkeresés DO
    GET HASZNALAT
    FIND OWNER WITHIN ESZKOZ_HASZNALAT
    IF sikeres THEN GET ESZKOZ
    feldolgoz(ESZKOZ, HASZNALAT.darabszam)
    állítsd_vissza_a_műhely_SET_bejárási_állapotát
    FIND NEXT HASZNALAT WITHIN MUHELY_HASZNALAT
  END
END

A STORE új rekordot tárol, a MODIFY mezőértéket módosít, az ERASE rekordot töröl. A CONNECT egy rekordot SET-előforduláshoz kapcsol, a DISCONNECT megszüntet egy megengedetten leválasztható tagságot, a RECONNECT jellegű művelet tulajdonosváltást végezhet. A nevek történeti navigációs nyelvek műveleteit szemléltetik.

A darabszám 6-ról 8-ra módosítása nem ugyanaz, mint az eszköz lecserélése. Az első HASZNALAT-mező módosítása; a második az ESZKOZ_HASZNALAT tagság másik tulajdonoshoz kapcsolását kívánhatja. Ha mindkettő történik, a változásokat összehangoltan kell kezelni.

Egy használati rekord eltávolítása után a műhely és az eszköz továbbra is megmaradhat. Ezzel szemben egy eszköz törlése előtt vizsgálni kell a hozzá tartozó használatokat. Az üzleti jelentés és a törlési szabály dönti el, hogy a törlés tiltott, a kapcsolórekordok törlendők vagy más rendezés szükséges.

Összetett módosításoknál nem maradhat olyan kapcsolórekord, amelynek valamely kötelező tulajdonosa hiányzik. A tranzakciós szemlélet itt is fontos: a több kapcsolati és adatváltozást egy logikai egységben kell sikerre vinni vagy rendezett módon visszavonni.

A műhelyhez eszközhasználat és anyagfelhasználás tartozik. Az ESZKOZ önálló rekordtípus, mert ugyanaz az eszköz több foglalkozásban használható. Az ANYAG szintén önálló típus, mert ugyanabból az anyagfajtából több műhely is igényelhet. A két kapcsolatnak más adatai vannak: eszköznél darabszám, anyagnál mennyiség és mértékegység.

A HASZNALAT rekord MUHELY és ESZKOZ tulajdonosokhoz kapcsolódik, a FELHASZNALAS rekord MUHELY és ANYAG tulajdonosokhoz. A kapcsolórekordok neve és mezői különböznek, mert eltérő üzleti kapcsolatokat írnak le. A MUHELY-ből két eltérő SET-ben indulhat bejárás.

Az ismétlődő műveleti lépéseket a MUHELY rekordban ismétlődő csoportként is tárolhatjuk, ha a konkrét rendszer ezt támogatja és nem igényelnek önálló kapcsolatokat. Ha külön értékelést, felelőst vagy eszközkapcsolatot kell hozzájuk rendelni, a LEPES rekordtípus és MUHELY_LEPES SET alkalmasabb.

A hálós rendszerek történeti képviselője az IDMS. A hálós szerkezet fölött egyes rendszerek más hozzáférési réteget, például SQL-felületet is biztosíthatnak. Ettől a belső kapcsolati és tárolási megoldások nem feltétlenül válnak relációssá. A felhasználói lekérdezési felület és a modell megkülönböztetése általánosan hasznos.