ER veglegesitese es dokumentacioja

[lordblendi]

Veglegesiteni kell az ER-t, es feltenni olyan mind vsdx-ben, mind pdf-ben (hogy non-windows userek is meg tudjak nezni).

[jmarton]

Erre egy másik lehetséges út, amit @Kisfejes írt tegnap slacken:

Egy másik kérdés, hogy jó lenne összerakni egy olyan ER diagram-ot, ami mindig aktuális, és tárolni valahol, verziókövetéssel (pl egy JSON, git-ben). Egy ötlet erre, hogy mivel backend oldalon úgyis ORM-et használunk, ami azt jelenti hogy a kódban tárolva vannak az entitások leírásai, illetve a közöttük lévő kapcsolat, hogy használjuk ezt, illetve lehetne írni olyan tool-t, ami ebből a kódból generál ER diagram-ot.

[lordblendi]

Igen, de szerintem egy pdf mindenkeppen kell, hogy kirajzolva is lathassuk. :) On 2017. Mar 7., Tue at 16:51, József Marton notifications@github.com wrote:

Erre egy másik lehetséges út, amit @Kisfejes https://github.com/Kisfejes írt tegnap slacken:

Egy másik kérdés, hogy jó lenne összerakni egy olyan ER diagram-ot, ami mindig aktuális, és tárolni valahol, verziókövetéssel (pl egy JSON, git-ben). Egy ötlet erre, hogy mivel backend oldalon úgyis ORM-et használunk, ami azt jelenti hogy a kódban tárolva vannak az entitások leírásai, illetve a közöttük lévő kapcsolat, hogy használjuk ezt, illetve lehetne írni olyan tool-t, ami ebből a kódból generál ER diagram-ot.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bme-db-lab/szglab5-main/issues/2#issuecomment-284761474, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFmwFiM5rQ6Q6M18TqSHGKco1qZJvVqks5rjXz_gaJpZM4MVk99 .

[lordblendi]

ER-rel kapcsolatban felmerult kerdesek es az eddig erkezett valaszok:

1. amit furcsálok az a News entitás, hogy nem kapcsolódik semelyik másikhoz az ER diagramban. Erre elképzelhető, hogy van racionális magyarázat, azonban számomra logikusnak tűnne egy StudentGroups célcsoport, illetve esetlegesen egy User (Staff?) létrehozó.

Nora: A News entitas az nekem ujdonsag, meg nem lattam, az en szakdolgozatomban nem volt benne.

Golda Bence: Régen volt, szerintem jó, hogy ismét lesz/lett és most már van is mihez kötni a hírek elemeit -- bár első körben feleslegesnek tűnik számomra a kapcsolata a szemeszterrel, de holnap majd megmagyarázzák, hogy mi lesz erre a támogatott use-case.

---

_2. miért van a Users attribútumai közt displayname, ha van givenname/surname és loginname is. Számomra minden elképzelhető eset redundáns

3. A diagram számomra érthető, a specifikációval összhangban van, egy apró kivételt (display name, ha már van név és felhasználónév is, és hogy miért generált) leszámítva_

Bence es Nora: Eleg a login nev es a display name

---

_4. Azzal tisztában vagyok hogy a jogköröknek külön szerepe az adatokat leíró ER diagramban nincs, viszont (ha felteszem az appointment a labor alkalmat jelöli) a laborvezetőknek és javítóknak a megkülönböztetésére nincs indok?

5. A Staff egyedosztályt kissé absztraktnak érzem. (Például külön Javítók - Deliverables kapcsolat és külön Laborvezetők - Appointments kapcsolat)_

Nora:
Harom kulon ISA szamomra azt sugallna, hogy egy user az csak az egyikbe tartozhat, ezzel kizarva azt, hogy valaki egyszerre javito es laborvezeto. Ugyanakkor az olyan attributumbok, hogy isAdmin, isEvaluator, isDemonstrator meg olyan hekkelosnek hangzik picit, de kozelebb all hozzam, mint a 3 ISA.

Bence: Mindenképp külön engedély(eke)t tároló relációt javaslok, nekem a fenti kettő rugalmatlannak tűnik -- pláne ha egy általános megoldást szeretnénk készíteni.

Az elmúlt években a legjobb (legrugalmasabb) megoldás az alábbi volt:

• legyen egy Account, ami a belépéshez szükséges adatokat tárolja,

• legyen egy általános Object, ami egy általános -- a rendszerben szereplő bármilyen -- példányt tud ábrázolni,

• legyen egy általános Class, ami egy általános -- a rendszerben szereplő bármilyen -- osztályt tud ábrázolni és

• legyen egy általános Role, ami egy a rendszer egészére vonatkozó általános jogosultságot tud ábrázolni,

• majd az Account és a fentiek között teremtsünk kapcsolatot akkor, ha egy adott objektumra, osztályra vagy szerepkörre szeretnénk egy adott felhasználónak engedélyt adni.

Igazából a fenti két táblával megvalósítható:

Accounts:

• user_id
• authentication_token

Permissions/Grants:

• object_id (nullable),
• object_class (nullable),
• role_name
• user_id

Ami kellően jó megoldás tud(hat) lenni, ha tartjuk magunkat ahhoz, hogy:

• nincsenek összetett kulcsok,
• minden egyednek van egy *_id elsődleges (pl. szám) kulcsa.

Igazából ami most az ER-ben le van rajzolva fedi a fentit, ha Users===Accounts és Roles===(Permissions/Grants).

Így pl. támogathatóvá válik az is, hogy egy X. évben hallgató diákból az account megtartásával egy (X+1). évben laborvezetőt, (X+5). évben pedig egy-két kattintással gurut csináljunk. :)

[lordblendi]

Kedves Hallgatok!

Tudomasom szerint a legutolso verziot @szaszm keszitette, mely itt talalhato: https://www.szaszm.tk/files2/ER.pdf Tekintettel arra, hogy a felvezetett valtozasokrol en semmilyen informaciot nem talalok egyik csatornankon sem, igy ezek nelkul nem fogunk tudni tovabb haladni az ER-rel. Ezert szuksegem lenne a kovetkezo informaciokra az ER veglegesitesehez:

• Az eredeti (altalunk kikuldott) ER-hez kepest mi es miert valtozott: ugy ertem melyik entitasra es kapcsolatra miert van szukseg, melyik mit szimbolizal?
• Az attributumok listajara es a kapcsolatok neveire (FK-kent ez leirhato): gondolva az altalunk kuldott doksiban szereplo attributumokra, es hogy abban mi valtozott illetve mi lett hozzaadva.
• Mit szimbolizal a Languages entitas?
• Miert tuntek el az ISA kapcsolatok?
• Miert valtozott at az EventType es a DeliverableType EventTemplate es DeliveriableTemplate entitasokka? Mi a kulonbseg?
• Az Evaluates entitas miert nem lehet egy kapcsolat?
• A Pilot soran modellezett dolgokrol en semmit sem latok az ER-en. Ezeket hogy terveztetek megjeleniteni az ER-en?

A miertekre azert van szuksegunk, hogy tudjuk tenyleg azt modellezzuk le, amire szuksegunk van.

A kerdeseimre a valaszt, indoklast itt kommentben tegyetek meg. Az entitasok es attributumok listajat pedig a docs/ER-description.md fajlba tegyetek bele.

@szaszm Kerlek kuldd el nekem a legutolso Visio fajlt.

Udv, Nora

[csutorasr]

Az erd-t @szaszm keszitette. Nekem egy megjegyzesem volt, hogy nem kell a fajlfeltoltes bele, csak a gites, igy annak a kapcsolatait levette. A tobbit majd o tudja megmondani. Szerintem a holnapi nap folyaman biztosan.

A velemenyem, hogy elobb csinaljuk meg a pilot-ot, mert itt kiderulnek a hianyossagok, de mar van tervem, hogy hogyan kene tovabb haladni. De ez raer majd szerda utan is megbeszelni, addig mindenki erre koncentraljon szerintem.

[jmarton]

Megjegyzés: néhány kérdésre a válasz azon fog alapulni, hogy az adatmodell terv legfrissebb változata a Ruby ActiveRecord alapú implementáció, amit egy ruby_code tag jelöl az szglab5-backend repositorban, és múltheti kérésemre ezt is áttekintette @szaszm

https://github.com/bme-db-lab/szglab5-backend/tree/ruby_code

[lordblendi]

A Specifikaciot @gbence szerda estere tervezi kiegesziteni, ezutan az ER-nek is veglegesednie kell. Ahhoz, hogy mihamarabb tudjuk, hogy kinek mi a feladata es mindannyian dolgozhassatok egy vegleges modellel, ezekre az informaciokra mindenkeppen szuksegem van. A fenti kerdesekre a valasz hozzam valo eljuttatasanak hatarideje 2017.03.16. 23:00.

[szaszm]

Az ER diagramot én csak továbbvittem @lordblendi szakdolgozatából.

1. Az eredeti (altalunk kikuldott) ER-hez kepest mi es miert valtozott: ugy ertem melyik entitasra es kapcsolatra miert van szukseg, melyik mit szimbolizal?

Az Ismerkedesre tárgyú emailekben volt néhány megjegyzés, ezek alapján változott:

• StudentGroups -> Students kapcsolat bekerült, ez tagságot jelöl
• Courses -> EventTemplates kapcsolat bekerült, ennek igazából nem értem a szerepét
• átnevezve az EventTypes EventTemplates-re
• átnevezve a DeliverableTypes DeliverableTemplates-re (később ez megszűnt és a Repositories/RepositoryTemplates vették át a helyüket)
• Bekerült az Evaluates kapcsolótábla az ExerciseTypes és a Staffs közé
• Bekerült egy új, Languages entitás, amire az ExerciseTypes-ból mutat idegen kulcs
• A Students és a Staffs ISA kapcsolatból kapcsolótáblává váltak a Users és a Semesters között

A specifikáció alapján bekerült két új entitás:

• News (itt még kapcsolatok nélkül)
• Roles, több-több kapcsolattal a Usershez

Múlt héten beszéltünk @jmarton -nal, ez alapján a következők változtak:

• A Courses és Semesters közötti kapcsolat egy-több, nem több-több, mivel a Semesters egy adott tárgy egy félévbeli futását reprezentálja
• A News entitás a Semesters-hez kapcsolódik. Valamihez kapcsolni szerettük volna a híreket, és a tárgy szemeszterbeli lefutása értelmes választásnak tűnt.

2. Az attributumok listajara es a kapcsolatok neveire (FK-kent ez leirhato): gondolva az altalunk kuldott doksiban szereplo attributumokra, es hogy abban mi valtozott illetve mi lett hozzaadva.

Ezeket az ER diagramon nem követtem, viszont legkésőbb holnap össze tudom szedni őket. Feltűnt azonban néhány ellentmondás/kérdés, ezeket kérlek, hogy tisztázzuk:

• Az EventTemplates és az Appointments között a diagramon több-több kapcsolat, viszont a szakdolgozatban és a Ruby-s schema.rb-ben is több-egy kapcsolat van, az appointmentsben lévő idegen kulccsal. Ha nem érkezik válasz estig, akkor ezt javítom több-egy kapcsolatra.
• Ugyanez az Appontments és a StudentGroups között.
• Ugyanez az ExerciseCategories-Courses között
• A fentebb említett Courses->EventTemplates kapcsolat nincs ábrázolva egyik attribútumlistában sem. Lehetséges javítás: töröljük ezt a kapcsolatot, ha nincs értelme.
• A szakdolgozatban szerepel egy RegisteredStaffs entitás az attribútumlistában, de a diagramon nem. A schema.rb-ben sem szerepel. Ez miért van?
• A szakdolgozat attribútumlistájában és a schema.rb-ben az Events és a StudentGroups entitások a Staffs-szal egy Events->Staffs (demonstrator) és StudentGroups->Staffs (demostrator) idegen kulcsokkal vannak kapcsolatban, de a diagramon ezek egy több-több kapcsolattal vannak ábrázolva. Szerintem ezek legyenek több-több kapcsolatok a végleges sémában is.

3. Mit szimbolizal a Languages entitas?

A többnyelvűséget szolgálja. A StudentGroups, Students és ExerciseTypes entitások tartalmaznak rá mutató idegen kulcsot a schema.rb-ben. Ebből következően az egyes csoportok, hallgatók és feladattípusok nyelvét reprezentálja. Ebből kiindulva lehet majd a UI nyelvét is megválasztani. Az ER diagramon egyelőre csak az ExerciseTypes->Languages kapcsolat van ábrázolva, ezt javítani fogom.

4. Miert tuntek el az ISA kapcsolatok?

A Users/Students és a Users/Staffs esetét fentebb említettem, lásd az "Ismerkedésre" tárgyú emailben lévő hozzászólásokat. A Deliverables/Files és a Deliverables/Repositories azért tűnt el, mert az a döntés született, hogy a fájlfeltöltést nem kell támogatnia a rendszernek, csak a repositoryba beküldést. Ennek megfelelően alakult a DeliverableTemplates is.

5. Miert valtozott at az EventType es a DeliverableType EventTemplate es DeliveriableTemplate entitasokka? Mi a kulonbseg?

Erre én is kíváncsi lennék, de a fenti emailből származott ez a változás is.

6. Az Evaluates entitas miert nem lehet egy kapcsolat?

Lehet, csak ezt azonnal felbontottam kapcsolótáblára, mert így explicitebbnek éreztem.

7. A Pilot soran modellezett dolgokrol en semmit sem latok az ER-en. Ezeket hogy terveztetek megjeleniteni az ER-en?

Még nem volt időm foglalkozni ezekkel, ma este és holnap fogom átnézni és alkalmazni ezeket a változtatásokat. Ezekről jelenleg a https://github.com/bme-db-lab/szglab5-backend/issues/8 issuen keresztül tudok, ez alapján dolgozzak?

Javaslataim/terveim:

• Az Events, Students és ExerciesTypes között lévő kapcsolatot nevezzük Exercises néven kapcsolótáblának.
• Töröljük a Courses->EventTemplates kapcsolatot, hacsak nincs értelme
• Javítsuk az Appointments kapcsolatait több-egy típusúra.
• Javítsuk at ExerciseCategories-Courses kapcsolatot több-egy típusúra.
• A Pilot során modellezett dolgoknak utánanézni és alkalmazni őket az ER diagramra

Az ER diagram PDF (most nem változott): https://www.szaszm.tk/files2/ER.pdf A Visio fájlja: https://www.szaszm.tk/files2/ER.vsdx

Mindezekkel és az infrastruktúrával kapcsolatos feladataimmal ma (kedd) este, és holnap (szerda) fogom folytatni a munkát.

[lordblendi]

Szia!

Koszonom a valaszodat! valaszaim remelhetoleg inline latszodni fognak. Amire nem reagalok, az szerintem OK.

• StudentGroups -> Students kapcsolat bekerült, ez tagságot jelöl
• Courses -> EventTemplates kapcsolat bekerült, ennek igazából nem értem a szerepét

Ez azert kerult bele, mert annakidejen ugy terveztuk, hogy az ER modell nem csak a Adatbazisok labor targyat, hanem barmely mas targyat tudjon kezelni, akar egyszerre tobbet is.

átnevezve a DeliverableTypes DeliverableTemplates-re (később ez megszűnt és a Repositories/RepositoryTemplates vették át a helyüket)

Igen, valoban, mivel a fajlfeltoltes elmarad, igy mar nincs is szukseg a tobbire

Bekerült az Evaluates kapcsolótábla az ExerciseTypes és a Staffs közé

@jmarton: ER szinten mi legyen: kapcsolotabla, vagy kapcsolat? Akarjuk, hogy az Evaluates rendelkezzen sajat lettel vagy eleg, ha csak osszekapcsoljuk a feladattipust es a javitot?

• Bekerült egy új, Languages entitás, amire az ExerciseTypes-ból mutat idegen kulcs

Szerintem ez folosleges, mert az ExerciseCategories pont azt modellezi le, hogy valami melyik laborhoz tartozik (ld kuldott anyag 2. oldal elso sor). Es azt, hogy valami milyen nyelven van (angol/magyar) pedig az ExerciseType-on belul van egy attributumkent.

• A Students és a Staffs ISA kapcsolatból kapcsolótáblává váltak a Users és a Semesters között

@jmarton: ER szinten mi legyen: kapcsolotabla, vagy ISA?

• Az EventTemplates és az Appointments között a diagramon több-több kapcsolat, viszont a szakdolgozatban és a Ruby-s schema.rb-ben is több-egy kapcsolat van, az appointmentsben lévő idegen kulccsal. Ha nem érkezik válasz estig, akkor ezt javítom több-egy kapcsolatra.

Az EventTemplate es az Appointments kozott szerintem tobb-tobb kapcsolatnak kellene lennie, hisz egy idoponthoz tobb feladatsor is tartozik, es egy feladatsor tobb idoponthoz is tartozik. Szerintem ez el van irva a szakdolgozatban.

• Ugyanez az Appontments és a StudentGroups között.

Egy student grouphoz minimum 5 appountment tartozik, hisz minimum 5 laborja lesz egy csoportnak. Es egy Appointmenthez viszont szerintem 1 StudentGroup, mert a locationt is itt taroljuk, es egyszerre tobb csoport nem lehet ugyanabban a teremben szerintem. @jmarton, szerinted?

• Ugyanez az ExerciseCategories-Courses között

Ez szerintem attol fugg, hogy most hany targyat akarunk lemodellezni. Szukseg van egyaltalan a Courses-re, ha csak a szoftlab5-ot modellezuk? Akkor akar az ExerciseCategories a Semesterhez is kapcsolodhatna, nem? @jmarton szerinted?

• A fentebb említett Courses->EventTemplates kapcsolat nincs ábrázolva egyik attribútumlistában sem. Lehetséges javítás: töröljük ezt a kapcsolatot, ha nincs értelme.

Szerintem ennek a kapcsolatnak nincs ertelme. @jmarton ezt miert raktuk bele?

• A szakdolgozatban szerepel egy RegisteredStaffs entitás az attribútumlistában, de a diagramon nem. A schema.rb-ben sem szerepel. Ez miért van?

Valoszinuleg azert, mert elfelejtettem kitorolni.

• A szakdolgozat attribútumlistájában és a schema.rb-ben az Events és a StudentGroups entitások a Staffs-szal egy Events->Staffs (demonstrator) és StudentGroups->Staffs (demostrator) idegen kulcsokkal vannak kapcsolatban, de a diagramon ezek egy több-több kapcsolattal vannak ábrázolva. Szerintem ezek legyenek több-több kapcsolatok a végleges sémában is.

Szerintem egy oktatasi esemenyhez (laborhoz) alapvetoen 1 demonstratort szoktunk kotni. Szintugy egy csoportnak egy demonstratora szokott lenni.

3. Mit szimbolizal a Languages entitas?

A többnyelvűséget szolgálja. A StudentGroups, Students és ExerciseTypes entitások tartalmaznak rá mutató idegen kulcsot a schema.rb-ben. Ebből következően az egyes csoportok, hallgatók és feladattípusok nyelvét reprezentálja. Ebből kiindulva lehet majd a UI nyelvét is megválasztani. Az ER diagramon egyelőre csak az ExerciseTypes->Languages kapcsolat van ábrázolva, ezt javítani fogom.

Jelenleg (a pilot alatt) az tarolodik a Languages entitasban, hogy melyik laborhoz tartoznak a beugro kerdesek (SQL, Oracle...), ami hibas, hisz ez az ExerciseCategories-ban mar szerepel. A feladattipus nyelve pedig megtalalhato az ExerciseTypes language attributumaban. Ezutan en nem latom szukseget a Languages entitasnak, tekintettel arra, hogy amikor belep egy hallgato, akkor tudnia kell a rendszernek, hogy azon hallgatohoz melyik feladatsor tartozik, es igy a nyelvet is.

5. Miert valtozott at az EventType es a DeliverableType EventTemplate es DeliveriableTemplate entitasokka? Mi a kulonbseg? Erre én is kíváncsi lennék, de a fenti emailből származott ez a változás is.

Nekem a template es a tipus az ket kulonbozo jelentessel bir. Template az valami minta, mig a Type az pedig megkulonboztetest (pl, hogy valami gyumolcs vagy zoldseg). En a Type nevre szavaznek.

6. Az Evaluates entitas miert nem lehet egy kapcsolat? Lehet, csak ezt azonnal felbontottam kapcsolótáblára, mert így explicitebbnek éreztem.

Ez attol fugg, hogy szeretnenk-e, hogy az Evaluates sajat lettel, egyediseggel rendelkezzen, vagy eleg, ha azok biztositjak az egyediseget, amiket osszekapcsol.

Még nem volt időm foglalkozni ezekkel, ma este és holnap fogom átnézni és alkalmazni ezeket a változtatásokat. Ezekről jelenleg a bme-db-lab/szglab5-backend#8 https://github.com/bme-db-lab/szglab5-backend/issues/8 issuen keresztül tudok, ez alapján dolgozzak?

Szerintem nem. Hol talalhatoak a vegleges modellek @csutorasr es @Kisfejes? En szemely szerint ezek kozul valasztanek valamit: https://github.com/bme-db-lab/szglab5-frontend/tree/dev/app/models vagy https://github.com/bme-db-lab/szglab5-backend/tree/dev/models

Mindezekkel és az infrastruktúrával kapcsolatos feladataimmal ma (kedd) este, és holnap (szerda) fogom folytatni a munkát.

Tekintettel arra, hogy viszonylag sokat foglalkoztal az ER reszelgetesevel, esetleg szeretned Te (/kozosen) megcsinalni a veglegesitest vagy csinaljam en egyedul? Utobbi csak akkor lehetseges, ha pentekre mindenben megegyezunk, mert ha aznap nem tudom megcsinalni, akkor marcius 25-e elott nem fogok tudni foglalkozni vele.

[jmarton]

• Courses -> EventTemplates kapcsolat bekerült, ennek igazából nem értem a szerepét

Ez azert kerult bele, mert annakidejen ugy terveztuk, hogy az ER modell nem csak a Adatbazisok labor targyat, hanem barmely mas targyat tudjon kezelni, akar egyszerre tobbet is.

A több tárgy kezelése jellegű általánosítást szerintem adatmodell szintjén ne adjuk fel, mert sem az ORM-ben, sem az API-ban, sehol sem érzem, hogy többet bonyolítana, mint egy-két plusz végpont/tábla/osztály generálása

btw: a Courses, EventTemplates viszony szerintem fordítva több:egy, azaz EventTemplates--->Courses

Bekerült az Evaluates kapcsolótábla az ExerciseTypes és a Staffs közé

@jmarton: ER szinten mi legyen: kapcsolotabla, vagy kapcsolat?

Kapcsolattípus legyen.

• Bekerült egy új, Languages entitás, amire az ExerciseTypes-ból mutat idegen kulcs

Szerintem ez folosleges, mert az ExerciseCategories pont azt modellezi le, hogy valami melyik laborhoz tartozik (ld kuldott anyag 2. oldal elso sor). Es azt, hogy valami milyen nyelven van (angol/magyar) pedig az ExerciseType-on belul van egy attributumkent.

Szerintem nem haszontalan, ha van egy Languages egyedtípus, márcsak az i18n/l10n miatt is, de ha erre a BE más megoldást javasol, akkor itt akár el is tekinthetünk tőle.

• A Students és a Staffs ISA kapcsolatból kapcsolótáblává váltak a Users és a Semesters között

@jmarton: ER szinten mi legyen: kapcsolotabla, vagy ISA?

ER szinten megtartanám az ISE + kapcsolattípus kombinációját.

• Az EventTemplates és az Appointments között a diagramon több-több kapcsolat, viszont a szakdolgozatban és a Ruby-s schema.rb-ben is több-egy kapcsolat van, az appointmentsben lévő idegen kulccsal. Ha nem érkezik válasz estig, akkor ezt javítom több-egy kapcsolatra.

Az EventTemplate es az Appointments kozott szerintem tobb-tobb kapcsolatnak kellene lennie, hisz egy idoponthoz tobb feladatsor is tartozik, es egy feladatsor tobb idoponthoz is tartozik. Szerintem ez el van irva a szakdolgozatban.

A ruby-s modelben leírt változatnál az járt a fejemben, hogy a feladattípus az csak az Events-ben jelenik meg, a template-ben nem. Ezért készült a Appointments-->EventTemplates irányú több:egy.

• Ugyanez az Appontments és a StudentGroups között.

Egy student grouphoz minimum 5 appountment tartozik, hisz minimum 5 laborja lesz egy csoportnak. Es egy Appointmenthez viszont szerintem 1 StudentGroup, mert a locationt is itt taroljuk, es egyszerre tobb csoport nem lehet ugyanabban a teremben szerintem. @jmarton, szerinted?

Így van, Appointments-->StudentGroup irányban több:egy

• Ugyanez az ExerciseCategories-Courses között

Ez szerintem attol fugg, hogy most hany targyat akarunk lemodellezni. Szukseg van egyaltalan a Courses-re, ha csak a szoftlab5-ot modellezuk? Akkor akar az ExerciseCategories a Semesterhez is kapcsolodhatna, nem? @jmarton szerinted?

Én megtartanám adatmodell szintjén a több tárgyat, és benne az ExerciseCategories-->Courses irányba a több:egy kapcsolattípust.

Persze mondhatjuk, hogy évről évre változhat a program, és pl. XSQL mérés helyett jövőre Erlang lesz, de ennek a historizálásával ne bonyolítsuk.

• A fentebb említett Courses->EventTemplates kapcsolat nincs ábrázolva egyik attribútumlistában sem. Lehetséges javítás: töröljük ezt a kapcsolatot, ha nincs értelme.

Szerintem ennek a kapcsolatnak nincs ertelme. @jmarton ezt miert raktuk bele?

HA lenne egy olyan több:egy kapcsolattípus-láncolat, hogy EventTemplates-->ExerciseCategories-->Courses, akkor a Courses--EventTemplates törölhető.

• A szakdolgozat attribútumlistájában és a schema.rb-ben az Events és a StudentGroups entitások a Staffs-szal egy Events->Staffs (demonstrator) és StudentGroups->Staffs (demostrator) idegen kulcsokkal vannak kapcsolatban, de a diagramon ezek egy több-több kapcsolattal vannak ábrázolva. Szerintem ezek legyenek több-több kapcsolatok a végleges sémában is.

Szerintem egy oktatasi esemenyhez (laborhoz) alapvetoen 1 demonstratort szoktunk kotni. Szintugy egy csoportnak egy demonstratora szokott lenni.

Így van, szóval ezek az itt leírt irányba több:egy kapcsolattípusok. Mivel különböző event X hallgató 1. és 2. mérése, így kezelhető, ha laborvezető-csere történt.

Elnézést, egyelőre ennyi részemről.

[szaszm]

Amit változtattam:

• Visszaalakítottam kapcsolattá az Evaluates entitást.
• Töröltem a Courses->EventTemplates kapcsolatot, mivel legfeljebb ellenkező irányba lett volna értelme, de ezt ellátja a javított EventTemplates->ExerciseCategories kapcsolat.
• Megfordítottam az EventTemplates<-ExerciseCategories kapcsolatot EventTemplates->ExerciseCategories irányúra, mivel a másik irányt értelmetlennek láttam, ezt viszont hasznosnak.
• Appointments->StudentGroups több:egy lett
• Az Events->Staffs és a StudentGroups->Staffs több:egy kapcsolatok lettek.
• EventTemplate visszanevezve EventType-ra
• RepositoryTemplate visszanevezve RepositoryTypera
• Új entitások: Questions->Tests, Test->ExerciseCategories
• Repositories->RepositoryType több:egy-re alakítva, mivel szerintem egy példánynak csak egy típusa van.
• Students->Languages felvéve. A Languages alatt emberi nyelvet értünk.
• StudentGroups->Languages felvéve.

Amit nem csináltam:

• A Students és Staffs maradtak önálló entitások, mivel ha ezt eldobjuk, akkor újra előkerül a korábbi hallgató később demonstrátorrá válásának problémája. Ha megerősítitek, hogy ennek ellenére ER szinten megtartanátok az ISA kapcsolatot, akkor visszaalakítom, de akkor a megvalósításnál körültekintőbbnek kell lenni.
• Ha a beugrók eredményeit vezetni akarjuk, akkor fel kell még venni egy több:egy kapcsolatot Tests->Event között. Akarjuk?

A tartalom frissítve, a linkek változatlanul: https://www.szaszm.tk/files2/ER.pdf https://www.szaszm.tk/files2/ER.vsdx

[lordblendi]

Koszonom a frissitett valtozatokat!

A Students és Staffs maradtak önálló entitások, mivel ha ezt eldobjuk, akkor újra előkerül a korábbi hallgató később demonstrátorrá válásának problémája. Ha megerősítitek, hogy ennek ellenére ER szinten megtartanátok az ISA kapcsolatot, akkor visszaalakítom, de akkor a megvalósításnál körültekintőbbnek kell lenni.

Nekem tetszik ez most igy, hirtelen nem is latok hibat az ER-ben, remelem semmit sem neztem rosszul. @jmarton ?

Ha a beugrók eredményeit vezetni akarjuk, akkor fel kell még venni egy több:egy kapcsolatot Tests->Event között. Akarjuk?

A beugrojegyek eredmenyeit mindenkeppen vezetni kellene, de szerintem nem a Tets->Event kozott. Egyreszt, mert a Tests jelenleg kerdescsoportokat tartalmaz a PILOT soran. Viszont ez nem jelenti azt, hogy egy laborvezeto tenyleg csak egy kerdescsoportbol valogat majd kerdeseket, es esetleg nem ir hozza egyet fejbol. Valamint ugye a beugrojegyek nem Eventhez, hanem hallgatokhoz tartoznak laboronkent. Emlekeim szerint annak idejen a Deliverable-ben volt benne. Csak most ugye az eltunt. Szerintem azt valahogy vissza lehetne hozni. @jmarton ? :)

Az attributumlista az valtozott valamiben? Ugy ertem azoknal, amik eddig voltak, hisz az uj dolgokhoz meg nem vettunk fel semmit sem. De ezzel egyutt akkor elnevezhetnenk a kapcsolatokat. Talan az ER-re is erdemes lenne rarakni nevekkel oket.

[lordblendi]

A jegyekhez nekem a kovetkezo otletem tamadt:

Van az a kapcsolat, ami osszekoti az Events, Students es ExerciseType entitasokat. Szerintem vagy a kapcsolat attributumai kozott tarolhatnank a jegyeket es a kommenteket, vagy pedig a egy kulon entitashalmazkent fel lehetne venni a Grade-t, es akkor az is csatlakozna ehhez a kapcsolathoz. Nekem az elobbi egyebkent jobban tetszene. Mi a velemenyetek?

Ha ez megvan, akkor szerintem az ER keszen lenne, legalabbis en hirtelen mar nem latok hianyossagot. Csak annyi, hogy nem Excercise hanem Exercise helyesen leirva. Ez mar az en szakdolimban is el volt irva.

[lordblendi]

@jmarton es en megcsinaltuk az uj ER-t. Ehhez egy readme-t, a pdf-et es a hozza tartozo Visio fajlt becommitoltam a master branchbe. Itt talalhato: https://github.com/bme-db-lab/szglab5-main/tree/master/docs/ER

A hallgatokat arra kernem, hogy az attributumlistat keszitsek el illetve a readme-t egeszitsek ki a hianyzo entitashalmazokkal!

[lordblendi]

Ezzel foglalkozik valaki? El fog keszulni mondjuk pentek (2017.03.24.) estig?

[mdaniszabo]

@lordblendi @gbence @csutorasr @szaszm @Kisfejes Elkészültem a módosított ER dokumentálásával. Nagyobb részt @lordblendi szakdolgozatából indultam ki, leírásokat lefordítottam és átjavítottam ami változott, illetve kiegészítettem az új egyedtípusokkal. 1-2 dolog van ami nem volt világos, ezeket [ ]-be beleírtam. Arra kérnék minden a modell terén kompetenciával bíró kollégát, hogy nézze át, hogy megfelel-e az elképzeléseinek. Jó lenne ha konzisztens és működő modellünk lenne.

[lordblendi]

Amiket most hirtelen lattam:

• Deliverable-nel nem csak jegy van, hanem megjegyzes is. Ugyan nem mindenutt, de pl laborjegy es jkvjegy melle tartozik egy szoveges ertekeles is
• DeliverableTemplate -> igen, jelenleg 7 nap az esemeny idejetol.
• Event -> az ExerciseSheet szerintem mar tartalmazza, hogy milyen feladatsort tart, tehat itt a title felesleges. Ugyanugy nem latom ertelmet hirtelen a number es a shortdescription attributumoknak.
• EventTemplates -> ebben a tantargyban csak meres van, viszont a rendszert ugy tervezzuk, hogy tobb kulonbozo targyat is lehessen benne kezelni, pl gyakorlatot es eloadast is.
• Users -> Elirtad a publickeyt :)
• User/Staff -> lehet olyan is, akinek csak adunk hozzaferest, de nem demonstator, javito vagy admin. Illetve olyan is, aki egyszerre tobb feladatkort is ellat.
• News -> tudnunk kell azt is, hogy ki irta, illetve azt is, hogy meddig es milyen feluleten jelenjen meg (pl csak javitoknak marc3 es marc 31 kozott). Lehetseges esetek (tobb is valaszthato): login page, adminoknak, javitoknak, demonstratoroknak

[mdaniszabo]

A news esetében a "szerző" neve elég plain textben, vagy kapcsolat kéne legyen közte és egy user/staff között? Mert utóbbi esetben akkor a diagramot is javítanom kell. Illetve a megjelenés helyét miféle attribútumként vegyem fel? Készítsek új egyedhalmazt egy külön plain text attribútummal?

[gbence]

A szerző mindenképp legyen a user/staff egy egyede -- tehát kérünk oda egy kapcsolatot.

A megjelenés helye pedig lehet valamiféle flag vagy egyszerű elemek listája. Pl. ha egy adott hírt a főoldalon és a laborvezetők oldalán szeretnénk megjeleníteni (itt-is-ott-is), akkor ezt egy felsorolásban érdemes átadni a kliensnek. A tárolás módját te választod meg. :)

[lordblendi]

@Mordekk A StudentGroup-nal miert van language? Az a diagrammon nincs osszekotve a Language-el, szerintem felesleges.

[mdaniszabo]

@lordblendi A szakdolgozatodból indultam ki. Ott láttam, hogy van és arra asszociáltam, hogy akkor biztos számít egy StudentGroup nyelve (pl angol, német kurzus?) ezért hagytam bent. Nem vettem észre, hogy az új ER-ben nincs. Kiveszem a doksiból. Ha mégis indokolt lenne a létezése, kérlek jelezd.

[lordblendi]

Vedd ki nyugodtan, mert a StudentRegistrationben, amiben egy hallgatok adott targyjelentkezeset kezeljuk, mar tarolva lesz a nyelv. A ER felulirja a szakdolgozatomban levo adatokat.

[jmarton]

Ezt késznek tekintem és lezárom. Ha valami felmerül, majd külön issue-ban kezeljük.