TIS2022-FMFI / transport-audit

Verification of transport packages based on barcodes
0 stars 2 forks source link

Dátový model perzistentných údajov #6

Closed JozefKolek closed 1 year ago

JozefKolek commented 1 year ago

3 fáza projektu

JozefKolek commented 1 year ago

Okej zaciname tvorit

JozefKolek commented 1 year ago

image Takze poprosim o kontrolu ci moze takto vyzerat databaza pre patterny pouzivatelov a kamiony s spz

murodrap commented 1 year ago

Ešte treba doplniť, akého typu sú jednotlivé atribúty. V patterne asi pri rôznych zákaníkoch budú rozdielne počty používaných typov vozíka, takže by mohlo byť vhodnejšie dať samostatnú tabuľku pattern, ktorá bude mať atribúty id a zákazník, a potom zvlášť tabuľku s jednotlivými typmi vozíkov a ich počtom, ktoré sa budú odkazovať na pattern, do ktorého patria.

JozefKolek commented 1 year ago

Dakujem ano dorobim plus suhlasim tie patterny bude lepsie mat samostatne aby vedel zadavatel nove typy vozikov pridat

JozefKolek commented 1 year ago

image image Zatial takto ostalo viacero otazok ci nahodou neoddelit zakaznika od patternu pretoze sa mi nevidi zeby pri odstraneni zakaznika musel odist aj jeho pattern, a bolo by fajn mat tabulku vozik ale z praktickeho hladiska nas to nezaujima a ani zadavtel asi nebude chciet viest si databazu vozikov. JLR header dorobim este ale este musim nastudovat

murodrap commented 1 year ago

Config bude asi treba doriešiť, zakaznik a uzivatel kod by mali byť podľa informácií od zadávateľa zoznamy hodnôt, primary key by tu mal byť iný atribút tabuľky, celkovo by sa ešte hodilo ujasniť, ako presne by mal config fungovať

murodrap commented 1 year ago

Screenshot from 2022-10-21 22-47-41

Takto nejak som to myslela s tými patternami

JozefKolek commented 1 year ago

image Este ostal JLR header ale to musim kuknut ci treba tabulku alebo staci len obrazok

murodrap commented 1 year ago

Tabuľa record v sebe kombinuje záznamy pre audit celého kamiónu a údaje pre jednotlivé vozíky v kamióne, aby sme sa vyhli duplicite, bolo by dobré record rozdeliť na dve tabuľky. Inak by sa zbytočne veľakrát ukladalo napríklad v ktorom vozidle je vozík, aj keď všetky vozíky jednoho auditu musia byť v tom istom vozidle.

Môže byť tabuľka shippment, bude mať atribúty id, špz, customer_id a user_code. To sú spoločné informácie, ktoré sú zhodné pre všetky vozíky obsiahnuté v audite/zásielke.

Potom tabuľka record bude mať zvyšné atribúty, týkajúce sa už konkrétneho vozíka. Shippment_id bude foreign key do tabuľky shippment a bude odkazovať na zásielku, ktorej je tento vozík súčasťou.

JozefKolek commented 1 year ago

image

Este som time_close dal do shippment lebo sa to netyka udajov suvisiacimi s vozikmi priamo Malo by to byt skoro final poslem potom este popis k tomu

JozefKolek commented 1 year ago

Datovy_model_navrh.pdf Posielam aj s popisom s tym ze stale ostava dost otvorenych otazok

JozefKolek commented 1 year ago

image posielam zmeny @murodrap tvoj nazor co prerobit este/dorobit este

JohnyCarrot commented 1 year ago

Teraz začínam nahadzovať tabuľky do databázy a napadla mi nasledujúca vec: Napr keď nahadzujem Stillage, dáva zmysel, že jeho číslo je primary key, pretože je to jeho unikátne označenie, Čo sa týka rozsahu, ak je môj predpoklad správny, že je to rozsah TLS - teda sekvencia, ktorá sa (po čase) môže meniť, nemalo by to byť "obyč číslo" a nie primary key ?

JozefKolek commented 1 year ago

image pche zmenene a lepsie, plus pripomienky zahrnute ako gratis

murodrap commented 1 year ago

Z config ešte treba odstrániť atribút user_code, keďže namiesto neho teraz používame tabuľku advanced_user

JozefKolek commented 1 year ago

imagecize toto je finalny model pridam popis a mozme to poslat zadavatelovi

JozefKolek commented 1 year ago

Finalna verzia vami schvalena aj s dokumentaciou Datovy_model_navrh.zip