Az EER-modell

Egy projektközpontban személyeket tartunk nyilván: mindenkinek van azonosítója, neve és e-mail-címe. Nem mindenki mentor, és nem mindenki résztvevő. A mentorhoz szakterület és mentorálási kapcsolat tartozhat, a résztvevőhöz évfolyam és projektcsapat. A minden személyre érvényes és csak egyes szerepekre érvényes tulajdonságokat külön szeretnénk kifejezni.

Az egyszerű ER-modellben felvehetnénk sok opcionális attribútumot egy SZEMELY egyedtípushoz, vagy külön egyedeket és 1:1 kapcsolatokat rajzolhatnánk. Ez azonban kevésbé mutatná világosan, hogy a mentor nem egy másik személy, hanem ugyanannak a személynek speciális szerepe.

Az EER-ben a SZEMELY főosztályhoz MENTOR és RESZTVEVO alosztály tartozhat. A mentor örökli a személy azonosítóját és nevét, és emellett saját szakterülete is van. Egy személy mindkét szerepben is részt vehet, ha a követelmények ezt megengedik.

Az EER koncepcionális modell: a jelentést és korlátozásokat írja le, nem választ automatikusan táblastruktúrát vagy SQL-megvalósítást. Ugyanazon EER-séma több helyes relációs megoldásra is leképezhető, eltérő előnyökkel és ellenőrzési igénnyel.

Legyen C a SZEMELY főosztály egyedeinek halmaza, S pedig a MENTOR alosztály. Ekkor S ⊆ C: minden mentor személy. Fordítva nem kötelező, hogy minden személy mentor legyen. Ez a részhalmazviszony az EER egyik alapjelentése.

A 17 azonosítójú Kovács Mira személy és a 17 azonosítójú Kovács Mira mentor ugyanaz a valós személy. Nem két egymástól független rekordazonosságot modellezünk, hanem ugyanannak az egyednek két szintű leírását. A főosztály azonosítója az alosztály azonosításának alapja is.

A főosztály–alosztály viszonyt gyakran „is-a”, vagyis „egy fajtája” kifejezéssel értelmezzük. MENTOR is-a SZEMELY. Ez nem azt jelenti, hogy a mentor egy másik személyhez tartozik; a „has-a” vagy „része” kapcsolatok más jelentésűek.

A modellezésnél az egyedtípus és az aktuális egyedhalmaz is megkülönböztetendő. Az ábra a típusviszonyt írja le; a konkrét adatállapotban az dönti el az alosztálytagságot, hogy mely személyek felelnek meg a szabálynak vagy kerültek az adott szerepbe.

A MENTOR örökli a SZEMELY id, nev és email attribútumait. Ez fogalmi érvényesség: minden mentor személy, ezért minden személyre előírt tulajdonság rá is vonatkozik. A relációs tárolásban ezek lehetnek külön főosztálytáblában, nem kell őket minden alosztálytáblában fizikailag megismételni.

A szakterulet a mentor saját attribútuma. A RESZTVEVO saját attribútuma lehet az evfolyam. Nem célszerű minden személyhez kötelező mentori szakterületet rendelni, ha sok személy nem mentor. Az alosztály világosan megmutatja, kikre értelmes a speciális tulajdonság.

Ha a SZEMELY részt vehet egy KAPCSOLATTARTAS kapcsolatban, azt a mentorok is megtehetik. Emellett MENTOR vezethet PROJEKT-et, olyan kapcsolatban, amelyet nem minden személy számára kívánunk megengedni. A kapcsolatban való részvétel az alosztály sajátossága is lehet.

Az öröklés lefelé érvényes. Nem állítjuk, hogy minden SZEMELY rendelkezik a MENTOR összes speciális tulajdonságával. Az alosztály saját mezőinek hiányát nem szabad ugyanúgy kezelni, mint egy mindenki számára értelmes, de ismeretlen főosztályadatot.

Felülről lefelé indulva SZEMELY-t veszünk fel, majd megállapítjuk, hogy egyes személyek mentorok, mások résztvevők, esetleg mindkettők. Ez specializáció: a főosztály egyedeit a feladat szempontjából fontos sajátosságok szerint további csoportokba soroljuk.

Alulról felfelé indulva először külön MENTOR és RESZTVEVO adatokat gyűjthetünk. Mindkettőnek van személyazonosítója, neve és e-mail-címe. Ezeket közös SZEMELY főosztályba emeljük: ez általánosítás. A saját attribútumok az eredeti speciális típusokon maradnak.

A két tervezési irány ugyanahhoz a kész típusviszonyhoz vezethet. Nem feltétlenül kell a végső ábrán külön rajzolni, hogy történetileg melyik gondolkodási irányt alkalmaztuk. A főosztály–alosztály jelentés és a korlátozások a lényegesek.

Az általánosítás nem pusztán egyforma mezőnevek összevonása. Két külön természetű adat azonos nevű mezője nem feltétlenül indokol közös főosztályt. A név és azonosító mellett valódi közös egyedazonosságot és jelentést kell felismerni.

Egy személy szerep szerint mentor vagy résztvevő lehet, elérési mód szerint helyszíni vagy online közreműködő. A két csoportosítás nem ugyanazt a kérdést teszi fel. Egy mentor lehet online közreműködő, egy résztvevő pedig helyszíni közreműködő.

Az egyik specializációban megengedett átfedés nem dönti el automatikusan a másik specializáció korlátait. Ha a munkavégzés módját egyetlen időpontra nézve két kizáró kategóriára osztjuk, ott diszjunkt szabályt használhatunk. A szerepek csoportja közben lehet átfedő.

Az időbeli értelmezést tisztázni kell. A valaki egy időszakban online, máskor helyszíni állítás nem azonos az ugyanabban az adatállapotban egyszerre két alosztály tagja állítással. Ha történetet tárolunk, szerepérvényességi időszakra vagy külön eseményre is szükség lehet.

Az ábrán két elkülönült csoportosítási csomópont egyértelműbb, mint egyetlen körből minden alosztályt vegyesen levezetni. Az utóbbi azt sugallhatná, hogy minden felsorolt osztályra ugyanaz a kizárási és teljességi szabály vonatkozik.

A d jelzés a diszjunkt szabályra utal. Egy meghatározott közreműködői nyilvántartásban a BELSO és KULSO munkatárs kategória kizárhatja egymást, ha a belső státusz és a külső státusz az adott időpontra nézve egyértelműen eltérő. Az üzleti szabály, nem az elnevezés teszi őket diszjunkttá.

Az o jelzés megengedett átfedést jelent. SZEMELY esetén a MENTOR és RESZTVEVO szerep átfedhet: egy tapasztalt résztvevő mentorálhat másik csapatot. Az átfedés megengedése nem követeli meg, hogy minden adatállapotban ténylegesen legyen közös tag.

A diszjunkt szabály sem mondja meg, hogy minden főosztálytag valamely alosztályba tartozik-e. Csak a legfeljebb egy feltételt írja elő. Egy személy egyik alosztályban sem lehet, ha a specializáció részleges.

A csoportok közötti átfedést példarekordokkal jól ellenőrizhetjük. Ha a követelmények szerint P17 egyszerre mentor és résztvevő lehet, d jelzés hibás volna. Ha egy dokumentált státuszkód csak egyetlen alosztályt választhat, o jelzés indokolatlanul gyengítené a szabályt.

Teljes esetben az alosztályok uniója a teljes főosztályhalmazt adja. Ha minden KÖZREMŰKÖDŐ belső vagy külső, nem maradhat olyan egyed, amelyik egyik státuszba sem tartozik. Az ábrán a főosztály és a csoportosítási kör közötti kettős vonal jelzi a teljességet.

Részleges esetben létezhet főosztálytag alosztálytagság nélkül. A SZEMELY főosztályban lehet kapcsolattartó, aki se nem mentor, se nem résztvevő. Az egyszeres felső vonal ezt megengedi. Nem állítja, hogy biztosan van ilyen személy minden adatállapotban.

A kizárás és a teljesség két független dimenzió. Diszjunkt és teljes esetben pontosan egy alosztály szükséges. Átfedő és teljes esetben legalább egy, de több is megengedett. Diszjunkt és részleges esetben nulla vagy egy; átfedő és részleges esetben nulla, egy vagy több.

E két szabályt nem helyettesíti egyetlen „típus” szó. A modellrajz és a tárolási terv helyességéhez mindkettőt meg kell adni. Egy relációs megoldásban a teljesség biztosítása több táblára kiterjedő ellenőrzést is igényelhet.

A HALADO résztvevő alosztály feltétele lehet teljesitett_modulok ≥ 4. Itt egy predikátum, vagyis igaz vagy hamis értékű állítás határozza meg, ki tartozik a csoportba. Az alosztályt nem kézzel választott, a feltétellel ellentétes tagságként kezeljük.

A KOZREMUKODO státusz szerinti alosztályaihoz a statusz = belso és statusz = kulso feltételeket rendelhetjük. Ha ugyanazon egyértékű attribútum különböző értékei különböző alosztályt választanak, a csoportosítás diszjunkt. A teljességhez azonban minden megengedett értéket le kell fedni, és a hiányzó érték kérdését is rendezni kell.

A szerepkörök nem minden esetben egyetlen attribútummal jellemezhetők. Mentor és résztvevő átfedhet, ezért egy kizárólag mentor vagy resztvevo értékű egyértékű mező nem képes minden megengedett állapotot leírni. Több logikai jelzés vagy külön tagsági táblák szükségesek lehetnek.

A tagsági feltétel megváltozásának következményeit is tisztázni kell. Ha a teljesített modulok száma csökken egy adatjavítás után, a HALADO tagságot is a definícióval összhangba kell hozni. A főosztályadat és az alosztálytagság nem mondhat tartósan ellent egymásnak.

Alosztályba kerüléskor az egyednek a főosztályban is léteznie kell. Egy új mentor nem lehet olyan id-vel nyilvántartva, amelyhez nincs személy. Fizikailag a rekordok beszúrásának sorrendje és ellenőrzése a relációs megoldás feladata, a fogalmi követelmény azonban azonos.

Teljes specializációnál új főosztálytag nem maradhat egyik alosztályhoz sem rendelve. A főosztály és alosztály adatainak létrehozását ezért összehangoltan kell elvégezni. Diszjunkt esetben ugyanazon csoport két alosztályába egyidejűleg nem kerülhet.

Egy mentor szerepének megszüntetése nem feltétlenül törli a SZEMELY egyedet. Részleges specializációban megmaradhat általános személy, vagy továbbra is lehet résztvevő. Teljes specializációban azonban az utolsó alosztálytagság megszüntetése a főosztályelem további sorsát is rendeznünk kell.

A főosztály egyedének törlése fogalmilag minden alosztálybeli megjelenését is megszünteti, mert ugyanarról az egyedről van szó. Ez nem jelenti, hogy a DBMS automatikusan minden séma esetében kaszkád törlést végez: a megvalósítási megszorításokat és műveleteket külön meg kell adni.

A SZEMELY-ből elkülönített MENTOR tovább bontható BELSO_MENTOR és KULSO_MENTOR alosztályokra. Minden külső mentor mentor, és minden mentor személy, ezért minden külső mentor személy is. Ez a részhalmazviszony tranzitivitása.

A KULSO_MENTOR örökli a személy id, név és e-mail attribútumát, a mentor szakterületét, és saját szerződésazonosítót kaphat. Az örökölt attribútumokat fogalmilag nem kell minden szinten újként felvenni. Az alsó szint tulajdonságkészlete a teljes láncból áll össze.

Az egyes szintek szabályai eltérhetnek. A SZEMELY → MENTOR viszony részleges lehet, mert nem minden személy mentor. A MENTOR → BELSO_MENTOR/KULSO_MENTOR csoport viszont teljes és diszjunkt lehet, ha minden mentor pontosan egy státuszhoz tartozik.

A több szint nem indokol végtelen osztályozást. Csak olyan csoportot hozunk létre, amelynek önálló jelentése, speciális attribútuma, kapcsolata vagy üzletileg fontos korlátozása van. Egy kizárólag elnevezésében eltérő alosztály feleslegesen bonyolíthatja a tervet.

A SZEMELY-ből MENTOR és TECHNIKAI_SEGITO alosztály is képezhető. A MENTOR_TECHNIKUS megosztott alosztály tagja egyszerre mentor és technikai segítő. Az id mindenütt ugyanazon személyt azonosítja.

A megosztott alosztály mindkét főosztály tulajdonságait örökli: a mentor szakterületét és a technikai segítő jogosultsági szintjét is. A közös SZEMELY-ős attribútumai fogalmilag egyszer tartoznak az egyedhez, még ha több öröklési út is vezet hozzájuk.

A tagság feltétele a mindkét főosztályban való részvétel. Nem elég, hogy valaki mentor vagy technikai segítő legyen. Ugyanakkor nem kötelező minden olyan személyt a megosztott alosztályba sorolni, aki mindkét csoportban szerepel, ha a megosztott alosztályhoz további feltételt is rendelünk.

Az öröklési szerkezet ilyenkor már nem tiszta fa, hanem rácsszerű szerkezet. Ez EER-öröklési viszony, nem a klasszikus hierarchikus adatmodell két valódi szülőjű rekordjának hibája. A két modell ugyanazt a „hierarchia” szót más jelentésben is használhatja.

Felülről lefelé előbb a közös egyedtípust és általános attribútumait keressük. Utána kiválasztjuk azokat a szerepeket, amelyeknek önálló adatuk vagy kapcsolatuk van. SZEMELY-ből így juthatunk MENTOR, RESZTVEVO és TECHNIKAI_SEGITO alosztályokhoz.

Alulról felfelé előbb a külön nyilvántartott szerepek adatait gyűjtjük, majd azonosítjuk a közös tulajdonságokat. Nem minden hasonló típusból készítünk közös főosztályt: a közös valós jelentés és az egyedazonosság fontosabb az oszlopnevek egyezésénél.

A gyakorlatban a két irány váltakozik. Egy új kapcsolat miatt indokolttá válhat egy alosztály, majd a további vizsgálat rámutathat, hogy annak egyes mezői valójában minden főosztálytagra jellemzők. A tervet ilyen esetben javítjuk, nem ragaszkodunk az első rajzhoz.

A végső modell ellenőrzéséhez példaszemélyeket veszünk fel: csak mentor, csak résztvevő, mindkettő, egyik sem. A dokumentált szabályokból eldöntjük, mely állapot megengedett. Ez megmutatja, hogy a d/o jelzés és a teljes/részleges lefedés helyes-e.

A projektközpont támogatója lehet MAGANSZEMELY vagy CEG. A személyt személyazonosító és név, a céget cégkód és cégnév írja le. A TAMOGATO kategória azokat az egyedeket fogja össze, amelyek támogatói szerepben részt vesznek. Nem kell a céget személynek tekintenünk.

A kategória tagja személy VAGY cég. Ez az unió jelentése. Ezzel szemben a MENTOR_TECHNIKUS megosztott alosztály tagja mentor ÉS technikai segítő. A két konstrukciót nem a rajz hasonlósága, hanem a tagság logikája különbözteti meg.

A kategória csak a támogatói szerep számára kiválasztott forrásegyedeket tartalmazhatja. Lehet sok személy vagy cég, amely nem támogat semmit. Ez részleges kategória. Teljes kategória esetén az összes meghatározó osztály minden elemét bevonjuk az unióból.

Különböző típusok kulcsai eltérő jelentésűek lehetnek. A P17 személyazonosító és C17 cégkód nem ugyanaz az azonosság. Ezért a kategória relációs leképezésekor gyakran külön támogatói azonosítót vezetünk be, és megőrizzük, mely forrásegyedet képviseli.

A TAMOGATO és PROJEKT között TAMOGATAS kapcsolat lehet. Egy támogató több projektet támogathat, egy projekt több támogatótól kaphat hozzájárulást. Az összeg és a dátum az adott támogatási esemény adata. A kategória lehetővé teszi, hogy a kapcsolatban egységesen szerepeljen személy vagy cég.

Ha többféle támogatási eszközt is nyilvántartunk, PÉNZBELI és TÁRGYI hozzájárulásból külön kategória is készíthető, ha valóban eltérő forrástípusokról van szó. Nem szükséges minden külön megnevezett értéket kategóriává tenni: sok esetben egyszerű típusattribútum vagy alosztály megfelelőbb.

A kategóriatag forrását egyértelműen azonosítani kell. Egy támogatói sor nem jelenthet egyszerre két külön személyt vagy egy egymástól független személyt és céget. A bemutatott példában a forrástípusokat különböző egyeduniverzumokként kezeljük, ezért pontosan egy forrásegyedet rendelünk minden támogatóhoz.

Az univerzum és az azonosság szabályát dokumentálni kell. Ha egy valós szereplő több forrástípusban is ugyanazon egyedként szerepelhet, nem szabad a külön táblakulcsok alapján automatikusan két külön kategóriatagot létrehozni. Ilyen helyzetben közös azonosságkezelésre vagy más, pontosabb modellre van szükség.

Ha G főosztályhoz S1, S2, …, Sn alosztály tartozik, minden Si ⊆ G. Teljes specializációban S1 ∪ S2 ∪ … ∪ Sn = G. Részleges specializációban a lefedési egyenlőséget nem követeljük meg; az unió minden esetben G részhalmaza.

Diszjunkt csoportban az eltérő alosztályok metszete üres: Si ∩ Sj = ∅, ha i ≠ j. Átfedő csoportban ezt az ürességi követelményt nem írjuk elő. Nem állítjuk, hogy a metszetnek kötelezően nem üresnek kell lennie az aktuális adatok között.

Predikátummal definiált S alosztály a G főosztály feltételt teljesítő elemeiből áll: S = {x ∈ G | p(x)}. Megosztott alosztályra például T ⊆ S1 ∩ S2 érvényes. A kategóriánál K ⊆ D1 ∪ D2 ∪ … ∪ Dn; teljes kategória esetén egyenlőség áll fenn.

A formális jelölés akkor hasznos, ha példákat is társítunk hozzá. MENTOR_TECHNIKUS esetén a metszet jelentése, hogy mindkét szerep szükséges. TAMOGATO esetén az unió azt jelenti, hogy egy megfelelő személy vagy cég is elegendő forrás lehet a kategóriatagsághoz.

A korábbi ER–relációs szabályok továbbra is érvényesek az egyszerű egyedekre és kapcsolatokra. Az EER új feladata az öröklés, a specializáció és a kategória tárolása. Nem minden részhalmazviszonyhoz kell önálló kapcsolat-attribútum vagy teljesen új, független kulcs.

A főosztály id kulcsát az alosztályokban is használjuk, ha ugyanazt az egyedet azonosítja. Az első leképezési változatban az alosztály id-je egyszerre elsődleges kulcs és a főosztályra mutató idegen kulcs. Ez biztosítja, hogy alosztálysor csak létező főosztályhoz tartozzon.

A részhalmazt biztosító idegen kulcs nem ellenőrzi automatikusan a teljességet vagy a diszjunkt szabályt. A két alosztálytábla ugyanazt az id-t is tartalmazhatja, ha nincs külön kizárás. A főosztálytábla pedig tartalmazhat mindkét alosztályból hiányzó id-t, ha nincs lefedési ellenőrzés.

Ezért a táblaséma mellett mindig külön felsoroljuk, milyen EER-szabályt biztosít a kulcs, és milyenhez kell további támogatott megszorítás, tranzakciós alkalmazáslogika vagy rendszerbeli megoldás. Egy szép táblarajz nem bizonyítja a teljes fogalmi szabályrendszer érvényesítését.

A SZEMELY(id, nev, email) tábla minden személyt tartalmaz. A MENTOR(id, szakterulet) és RESZTVEVO(id, evfolyam) csak a megfelelő alosztály tagjait tárolja. Az alosztály id elsődleges kulcs, és SZEMELY.id-re mutató idegen kulcs is.

P17 átfedő tagsága úgy jelenik meg, hogy id 17 mindhárom táblában szerepel. A nev és email csak a SZEMELY sorban található. P20 szerep nélkül kizárólag SZEMELY-ben szerepelhet, ha a specializáció részleges.

A teljes mentori adatok kiolvasásához a két táblát id alapján összekapcsoljuk. A saját attribútumokhoz nem kell a másik alosztály mezőit tárolni vagy kitölteni. Ez a megoldás áttekinthető és jól bővíthető új szerepekkel.

A költség a több tábla és az összekapcsolások igénye. Diszjunkt esetben ellenőrizni kell, hogy ugyanaz az id ne jelenjen meg két kizáró alosztályban. Teljes esetben a SZEMELY minden id-jének legalább egy alosztályban meg kell jelennie. E két szabály nem következik pusztán az idegen kulcsokból.

A KOZREMUKODO teljes és diszjunkt BELSO/KULSO specializációjánál BELSO(id, nev, email, belso_azonosito) és KULSO(id, nev, email, szerzodes_szam) táblát készíthetünk. Minden közreműködő pontosan egyikben szerepel, így a külön főosztálytábla elhagyható.

Részleges specializációban ez nem általánosan helyes: az alosztály nélküli főosztálytag számára nem marad tárolási hely. A csak általános P20 személyt nem lenne hová felvenni. Ezért a változat alkalmazásakor a lefedést ellenőrizni kell.

Átfedő és teljes specializációban ugyanaz az egyed több táblában is szerepelhet, közös adatainak ismétlésével. A név és e-mail összhangját ilyenkor biztosítani kell. A konstrukció tárolhatja az adatokat, de a redundancia és módosítási kockázat jelentős.

Az azonosítók globális értelmezését is megőrizzük. Ha két külön táblában id 17 két külön egyedet jelölhetne, nem lehetne egyszerűen a táblák uniójával rekonstruálni a főosztályt. A közös egyedazonosságot az id-k képzésével és a korlátozásokkal is biztosítani kell.

A KOZREMUKODO tábla az id, nev, email, tipus, belso_azonosito és szerzodes_szam mezőket tartalmazza. Ha tipus = belso, a belso_azonosito értelmes; ha tipus = kulso, a szerzodes_szam. A másik alosztály saját mezője nem alkalmazható az adott egyedre.

Teljes specializációban a tipus mező kötelező és csak a megengedett alosztályokat választhatja. Részleges diszjunkt esetben külön semleges jelölés vagy megengedett hiányzó típus reprezentálhatja az alosztály nélküli főosztálytagot. A választást következetesen kell rögzíteni.

Egyetlen típusmező nem írja le a mentor és résztvevő megengedett egyidejű tagságát. Ha az átfedést „mentor_resztvevo” új értékkel próbáljuk kezelni, minden további szerepkombináció külön esetet kívánhat. Az egyszerű változat lényegében diszjunkt felosztáshoz illeszkedik.

A sok alosztályspecifikus mező miatt sok nem alkalmazható érték keletkezhet. Ellenőrizni kell a típus és mezők összhangját: belső rekordnál legyen megfelelő belső azonosító, és ne szerepeljen értelmetlen külső szerződésadat. Az alkalmazhatatlanság és az ismeretlen adat nem ugyanaz a jelentés.

A SZEMELY táblában mentor_e és resztvevo_e jelzőt használunk. P17 esetén mindkettő igaz, P18-nál csak mentor_e igaz, P20-nál mindkettő hamis lehet, ha részleges a specializáció. A közös nev és email egyszer szerepel.

A szakterulet és evfolyam mezők a megfelelő szerephez kötődnek. Ha mentor_e hamis, a szakterület nem mentori adatként értelmezendő. Ha a mentorhoz kötelező szakterület tartozik, igaz jelzőnél értékét is biztosítani kell. A jelzők és a speciális mezők együtt adnak helyes tárolási szabályt.

Teljes specializációban legalább egy tagságjelző legyen igaz. Diszjunkt változatban legfeljebb egy lehet igaz. Átfedő részleges esetben mindegyik hamis is megengedett. A két korlát itt közvetlenül a sor jelzőin vizsgálható, ha azok érvényes, nem hiányzó logikai értékek.

Az egytáblás forma egyszerű közös lekérdezéseket adhat, de sok szerepnél széles és nehezen áttekinthető lehet. Egy új alosztály új jelzőt és új saját oszlopokat kíván. A főosztály + alosztálytáblák megoldása gyakran tisztábban bővíthető, különösen sok szerep és kapcsolat esetén.

A MENTOR_TECHNIKUS(id, szakmai_szint) id mezője egyszerre elsődleges kulcs és a MENTOR, illetve TECHNIKAI_SEGITO id-jére mutató idegen kulcs lehet. A két hivatkozás azt biztosítja, hogy az id mindkét főosztálytáblában létezzen. A közös SZEMELY-azonosság megőrzése itt alapkövetelmény.

TAMOGATO esetén a személyazonosító és cégkód nem helyettesíthető egymással. Bevezetünk tamogato_id pótkulcsot, és megadjuk a forrást. A példában egy támogató pontosan egy személyt vagy céget képvisel, ezért a két forráshivatkozás közül pontosan egy kitöltött. A forrásmezők egyedisége azt is biztosíthatja, hogy ugyanaz a forrásegyed ne kapjon több támogatói azonosságot.

A pótkulcsos hozzárendelés megoldható a forrástáblákban tárolt kategóriahivatkozásokkal vagy a kategóriatáblában tárolt forráshivatkozásokkal. Itt az utóbbit mutatjuk: TAMOGATO(tamogato_id, szemely_id, cegkod). Az idegen kulcsok mellett a pontosan egy forrás szabályt és az egyediséget is érvényesíteni kell.

A TAMOGATAS tábla ezután tamogato_id alapján kapcsolódik a közös szerephez, és projekt_id alapján a projekthez. A pótkulcs nem tünteti el a forrásazonosságot, hanem közös hivatkozási pontot ad. A kategória forrását és a konkrét támogatási esemény adatait külön tartjuk.

A projektközpont közös SZEMELY főosztályához MENTOR, RESZTVEVO és TECHNIKAI_SEGITO szerepek kapcsolódhatnak. A mentori és résztvevői csoport átfedő és részleges. A mentor a PROJEKT vezetője lehet; a résztvevő a projektcsapat tagja. E két kapcsolat az alosztályhoz tartozik, nem minden személy általános tulajdonsága.

A MENTOR_TECHNIKUS mindkét megfelelő szerep tagja, ezért metszetszerű megosztott alosztály. A TAMOGATO viszont személyek és cégek kiválasztott uniója. Ugyanabban a modellben szerepelhet mindkét konstrukció, de nem cserélhetők fel.

A relációs tervben a személyszerepekhez az első leképezési változatot választjuk, így a közös személyadatok egyszer szerepelnek. A megosztott alosztály id-je mindkét szereptáblához kapcsolódik. A támogató saját pótkulcsot kap, a támogatási esemény pedig külön kapcsolat- vagy eseménytábla.

A végső ellenőrzéshez a jelentéstől a konkrét adatokig haladunk: minden mentor személy; minden mentor-technikus mindkét szerepben létezik; minden támogató érvényes forrást képvisel; minden támogatás konkrét projektet érint. Ezután vizsgáljuk a d/o és teljességi szabályokat, a mezőalkalmazhatóságot és az életciklust. Az EER kiegészíti, nem helyettesíti az alap ER-modellezési ismereteket.