ovo sto si nacrtala nije ER dijagram, skini mysql workbench u njemu
mozes da nacrtas er dijagram

pa kreni odatle, ovo sto si nacrtala ne valja, za korisnika ti treba i
neki ID, taj ID ce ti u tabeli korisnik biti PK, u tabeli plata treba da
koristis taj ID kao foreign key na tabelu korisnik, u tabeli poruka i
primalac i posiljalac su isto foreign key na tabelu korisnik

ovo je realno 3-4min zadatak, ne znam u kojoj skoli (nadam se da je osmi
osnovne/prvi srednje max al obzirom na pitanje u septembru bojim se da
nije) necu namerno da ti napisem odgovor ali kontam da imas vise nego
dovoljno informacija da napravis kako treba... baci sledecu iteraciju
(sliku iz workbench-a) sta si uradila pa da vidimo dalje

Posto ti neces da reklamiras sebe, ja cu da reklamiram tebe:

https://mysql.rs/support/prva-normalna-forma/

Evo šta sam do sad uradila...
Kako sada dodati korisnika ispravno, pomoću skripte ? naravno, ako sam dobro uradila ovo do sada... https://files.fm/u/q6rpzw23d
evo sličice na linku...

ja bi reko da ti ovo ne valja :(

koja je poenta veze izmedju poruke i plate?

nisam siguran sta ovo treba da predstavlja :( mislim sta je poenta / cilj

da li imas N tipova plata pa useru assigneujes taj jedan tip plate ili imas sve plate za sve usere svaki mesec i ta plata treba da nosi kom useru pripada? .. nije definisano zadatkom kako ces ovo da uradis ali sta si zelela da postignes, po dizajnu gadjas ovo prvo (ako ces to opet koristi pilot tabelu), ali mnogo realnije i logicnije je ovo drugo (tu ti onda ne treba pilot tabela ali tabela plata mora da sadrzi user_id fk)

sta su ti posiljaoc i primaoc kao varchar u tabeli plata?!

sta su prouke u celoj ovoj prici i kako su povezane sa bilo cim?

ako pogledamo test zadatka, nigde se ne vidi da poruke imaju ikakve veze sa platom, znaci poruka treba da bude ko je primio, ko je poslao, kada, sta i neki id poruke... nema to sa platom nikakve veze ... dalje korisnik ima podatke koje pise u zadatku da ima i nista drugo, ako bilo sta drugo treba da dodas useru dodajes kroz pilot tabele a ne direktno u user tabelu

:( :(
Onda mi baš treba pomoć oko razumijevanja svega ovoga...

na linku koji ti je nidza postavio (moj blog) imas jednu po jednu normalizaciju objasnjenu, procitaj za prvu, drugu i trecu (dalje nema potrebe da citas za ovo sto ti se trazi) pa pitaj sta nije jasno, kada to razumes onda probaj ponovo uz ove sugestije iz proslog posta pa opet pitaj sta nije jasno

Kreni postepeno.

Na primer, ako treba da povežeš entitet korisnik sa entitetom plata. Razmisli kako su oni povezani. Možda bi bilo lakše ako bi preimenovala korsinika u zaposlenog, jer je to prirodnije.

Dakle imaš zaposlene i imaš plate.

Zaposleni je uvek samo jedan. U tabeli zaposleni sme da bude samo jedan slog koji opisuje zaposlenog. da bi povezivala tog zaposlenog sa drugim podaciam treba ti njegov identifikator, recimo polje id. Pošto je zaposleni jedinstven, tako i ovo polje mora biti jedinstveno (unique). To se zove prirodni ključ. Prirodni ključ je jedinstvena vrednost kojom se određuje entitet koji se opisuje u tabeli (u ovom slučaju zaposleni).

Jednostavnosti radi, ovo polje možeš da koristiš i kao primarni ključ. Primarni ključ je vrednost kojim se određuje slog u tabeli i po kome se taj slog povezuje sa drugim tabelema. Dakle, id u tabeli korisnik će ti biti primarni ključ te tabele.

Obavezno proučio smisao prirodnog i primarnog ključa, to je vrlo važno.



Plata može da bude više, svaki mesec po jedna, a možda i dve mesečno, ali je svaka plata opet jedinstvena samo za sebe. To znači da i u tabeli plata treba da imaš polje id koje je jedinstveno. Ono će takođe služiti kao prirodni i primarni ključ u tabeli.



Kako su povezani zaposleni i plate? Jedan zaposleni može da ima više plata. To se zove 1:m veza (jedan slog u jednoj tabeli, može da ima vezu sa više slogova u drugoj tabeli). To znači da u tabeli plata treba da imaš polje u kome će da piše kom zaposlenom pripada ta plata. U to polje će se upisivati ID zaposlenog. Polje može da se zove baš tako id_zaposlenog. Ovolje ima funkicju spoljnog ključa - veze sloga sa nekom drugm tabelom.

Sad je na redu veza između tabele zaposleni i tabele poruka. Kako su povezani? Jedan zaposleni može da šalje više poruka, i to je 1:m veza, i tabela poruka mora da sadrži kolonu kojoj će biti upisan ID zaposlenog u funkciji pošiljaoca. Polje može da se zove id_primaoca i to je spoljni ključ prema tabeli zaposleni.

Međutim, zaposleni može i da prima poruke. Kakva je veza? Opet jedan zaposleni može da primi više poruka - još jedna 1:m veza. Dakle u tabeli poruka ti treba još jedno polje u koje će da sadrži ID zaposlenog koji prima poruku. Nek se zove id_primaoca i to je spoljni ključ prema tabeli zaposleni.

Probaj ponovo da nacrtaš model pa pošalji da vidimo.

https://files.fm/u/rmets9377

aj za pocetak nauci da zakacis slike direkt ovde na forum :(

Pozdrav, imas li resenje za ovaj zadatak?

Isti zadatak i ja imam i muku mucim sa povezivanjem tabela, poseban problem mi pravi veza izmedju tabela poruka-korisnici(kod tebe zaposleni)??

srednja skola ili fax u pitanju? koji?

ovo je previse jednostavan zadatak da bi se vas toliko tako zabolo?! kreni bar donekle, napisi dokle si stigao i zasto si se / gde zabo pa ce neko da ti pomogne... nece niko da ti uradi zadatak

Neće nikad nacrtati ako ne objašnjavaš lepo ..

Ovo je zadatak sa IT akademije. Ceo predmet mySQL je objasnjen na jednom primeru i naravno da ljudi koce i ne znaju da urade zadatak jer to nije dosta (ocigledno!). Mnogo toga u tom primeru nije ni navedeno, a trazi se u ovom zadatku.

U kombinaciji ovog foruma i interneta se moze mnogo vise nauciti nego na toj akademiji i to besplatno. Bitna je samo volja.
Problem sa tom akademijom je sto moraju svi da je zavrse "uspesno" i zato se daju najjednostavniji zadaci koji bi trebali svi da rese, ali ocigledno ni to ne mogu. A oni koji ga rese imaju lazni osecaj genijalnosti i da su savladali predmet.
U normalnom okruzenju ovo je zadatak posle prva dva-tri casa o bazama podataka.

nemoj bas da ih toliko ubijas u pojam :D ... nije bas tako ... posle par casova ce neko da da ovakav zadatak da ti pokaze koliko pojma nemas i kako ces vremenom kako ucis dalje drugacije da organizujes sve to ... posle par casova ovo samo sa mongom i slicnim budalastinama ovo moze da se resi :D

Ćao ljudi,

upravo pokušavam riješiti ovaj zadatak i malo se mučim, pa sam odlučio da potražim pomoć od Vas ovdje. Prvo ste me malo uplašili kada ste rekli ovo je zadatak za učenike nakon 2 časa pa mi nije bilo svejedno što se ja mučim sa njim ali onda sam skontao da ga i pokušavam riješiti nakon 2časa.

Ovako, ja sam kreirao novu schemu sa tri tabele: Zaposleni, Plata, Poruke. Za svaku od njih sam definisao PK: id_zaposlenog, id_plate, id_poruke.









Znaci sada bih ove tabele trebao povezati sa FK. Npr. iz tabele plata cu da povezem kolonu id_zaposlenog sa kolonom zaposleni_id iz tabele zaposleni. (trebao sam ih isto imenovati ali sada sam primjetio).
Isto tako iz tabele poruke, kolone id_primaoca i id_posiljaoca da povezem sa kolonom zaposleni_id? ako sam dobro pohvatao?

takođe me interesuje u tabeli plata, kod kolona status_isplate i tip_zaposlenja, posto bi tu trebalo da se unuse podatci: isplacena/neisplacena i određeno/neodređeno da li treba da se stavi određeni tip podataka, da ograničimo unos na samo to ili može da ostane ovako?

unaprijed se zahvaljujem na odgovoru, u međuvremenu ću ja probati da ovo rješavam dalje sam. :)

Ali ljudi moji... ne bih da zvucim "nacitano" ovde svima na forumu, ali niko vas ne tera da pisete SQL upite vec da nacrtate dijagrame, znaci plan kako bi se baza organizovala, kako bi se tabele ukomponovale na najbolji nacin. I ja sam pravio razne gluposti u startu, ali Vand...

Kako ce id_zaposlenog da bude varchar? Ako radis sa brojevima, zasto koristis varchar kao tip podatka koji ces cuvati u bazi?

UVEK koristite iste tipove u jednoj tabeli i drugoj na koju vodi FK. Ako je bigint, onda je bigint, nema integer obican da se stavlja, kamoli tekstualni podatak.

Niste svesni toga, na 10 redova, sve ce da radi za par milisekundi, na 1k redova par desetina ms, a onda najednom dodje par miliona redova i ode sve dodjavola sa par losih joina i where-ova...

Gledajte na to ovako, narodski objasnjeno:

PK i FK posmatrajte kao REFERENCE ka nekim nezavisnim entitetima - plata, zaposleni, itd. Brojevi sluze da oznace samo KO JE TO (PK) ili CIJE JE TO (FK).

Nista sem toga!

Znaci imate zaposlenog 1. On je primio 12 plata. Svih 12 plata ce imati FK "zaposleni_id" = 1. Zaposleni ne treba da ima dodatnu kolonu za referencu ka platama, uvek je dovoljno imati samo PK u prvoj tabeli ako je ovakav princip relacije.

I ovo nije schema, ovo je baza, scheme su nesto drugo.

Mozda je problem sto je u sve ovo ukljuceno vise entiteta i tabela sa porukama zbunjuje ljude. Morate da razmislite da li je neki entitet zavisan od drugog.

Da li je poruka zavisna od plate? Nije. Da li treba da ima referencu ka plati? Ne treba. Ako nekim slucajem i treba, kako da nadjem tog zaposlenog ciju platu gledam i vidim neku poruku, kako to da vidim? Lako. Pogledam kome pripada plata, nadjem tog zaposlenog. Onda od tog zaposlenog iscitam poruke.

Sto se tice ovih daljih pitanja, ovde je zadatak vec "nedovoljno objasnjen". Ti u idealnom slucaju, kako ja volim da radim, nikad neces "hardkodovati" tipove zaposlenja. Imao bi novu tabelu "tipovi_zaposlenja" gde bi imao (id(int)|tip_zaposlenja(varchar)) i onda to vezao preko stranog kljuca, za recimo platu.

Hteo sam da kazem da se "tip zaposlenja" cuva u tabeli "zaposleni", ali zaposleni moze da promeni tip zaposlenja, i onda se ne bi videlo da li je u trenutku primanja te plate bio zaposlen ili ne. To je jos jedna stvar koju treba imati na umu.

Cela poenta price... sto manje tabele, sto vise stranih kljuceva, mnogo lakse se barata s podacima. I nemoj da vas varaju da cuvate slike u bazi :)

Ovo je najmanji problem za sve vas da vam nacrtamo, ali necete nista nauciti iz toga. Ako je vec ovo "finalni zadatak" ili sta god, krenite sa prostijim stvarima, pa onda sirite dalje. Napravite prvo tabelu "dopisivanja" zaposlenih, manite se plata u potpunosti. Onda posle im dajte plate :)

Plata pripada zaposlenom.
Poruka pripada dvoma zaposlenih (jedan id za onog sto salje, jedan id za onog sto prima).

Nigde ne cuvajte duplo podatke. Ako u jednoj tabeli postoji ID zaposlenog, ne unosite njegovo ime u tabelu gde postoji FK ka tom zaposlenom.

Ja sad tek vidim da si ti u "plate" stavio unique na "zaposleni_id" na poslednjoj slici.

...

Molim te, objasni mi samo zasto si to uradio, i zasto si stavio varchar za FK id-jeve, i dacu ti kompletan dijagram sa celim objasnjenjem.

Hvala ti na dugom i mukotrpnom objasnjenju, znam da vam je to neshvatljivo ali jednostavno se slijeva previse informaciija u kratkom vremenu. Ja sam nešto sam čačkao i prilikov povezivanja tabela sam vidio da su mi kolone različitih tipova i sve sam ih promijenio na INT, shvatio sam grešku odmah nakon sto sam stavio ovdje objavu.
Da, svjestan sam ja da poruka ne zavisi od plate i da preko poruka necu traziti podatke o plati tog zaposlenog.
Nama je u zadatku navelo da u tabeli plata stavimo i tip zaposljavanja, samo iz tog razloga i jeste tu.
Ja sam to sada povezao ovako.

[url=https://postimg.cc/RN5YFQ9m][/url]

Naravno da nisam ocekivao da mi neko drugi nacrta tako ne bi ni bilo smisla, cisto sam htio par savjeta i hvala ti svakako.

Ovo je skroz ok s obzirom na scope zadatka. Ovakva baza moze da funkcionise.

Generalno, razmisljanje kad radis sa relacijama treba da ti se svodi na to da svaki "entitet" ima neki svoj broj, nikakav tekst ne gledas, samo te brojeve kojim su povezani i to je to.

Iskreno, iznad u teksu u nekom objasnjenju sam procitao da se id zaposlenog mora oznaciti sa unique pa sam stavio, ocigledno nisam dobro shvatio.
A za varchar sam objasnio da mi je jednostavno promaklo i kada sam dalje nastavio raditi sam promijenio.

Hvala, mnogo mi znaci da ovo moze da funkcionise posto sada za trebam odraditi i drugi dio zadatka, a ne bih da zapocinjem ako nista nije uredno.

U drugom dijelu trebam :
definisati indekse – postaviti indekse na mesta na kojima bi najviše odgovaralo; uzeti u obzir i postavljanje Full Text Indexa;
kreirati pogled – kreirati pogled kojim će se omogućiti dobijanje samo osnovnih informacija o korisniku: ime, prezime, datum i mesto rođenja;
napraviti uskladištene procedure za brisanje, unos i izmenu korisnika;
napraviti uskladištene procedure za unos, brisanje i izmenu podataka o platama;
napraviti uskladištene procedure za unos, brisanje i izmenu samih poruka;
napraviti funkciju koja će za prosleđeni parametar identifikacionog broja korisnika da prebroji i vrati ukupan broj njegovih poslatih poruka.

ovo sad mi je tek zbunjujuce ali idem polako da se zabavljam sa time, ako gdje zapnem sada znam gdje da se obratim. :)

Gledaj, ovde ima par zamerki, ali nisam siguran da nisu dati tako unutar zadatka. Realno, mene uvek iznervira kad neko sliku stavi kao BLOB u bazu, ali opet - kapiram da to cesto traze jer im treba "nesto sto moze u BLOB". Jako mi se, na primer, svidja sto je plata DECIMAL.

U svakom slucaju, ovo je zadatak za osobu koja tek uci. Na tom nekom nivou, ovo je skroz u redu. Za ucenika meni je ovo odlicno. Realno, pricamo o uceniku.

meni bi znacilo da cujem i te kritike i zamjerke, jer ipak ja ucim to da naucim, a ne da samo dobijem prolaznu ocjenu na zadatku, i svaki savjet od vas iskusnih je dobrodosao.

kako onda inace da cuvam slike?

Ne cuvas slike u bazi vec na nekom storidzu kao fajl, jpg/png/gif/webp, sta god ti radi posao, a u bazi cuvas linkove do tih slika i koristis ih u krajnjoj aplikaciji po potrebi. I ja sam napisao da je "prevara" uciti nekoga da cuva slike na taj nacin. To unistava celu poentu baze podataka. Okej, ima slucajeva gde moooooozda treba, ali to je vrlo retko. Em zauzimas zlata vredan prostor (baza trci po nvme danas, storidz moze i na hdd da bude, pa cak i neki cold storage ako brzina nije bitna), bekapi ti imaju nenormalnu velicinu i ne mozes da tarujes/zipujes... sad ti je najmanji problem to.

Indeksi... nauka sama za sebe i verovatno dok ih ne budes koristio u praksi neces imati pojma sta znace. Zamisli da tih zaposlenih imas milion. Ti sad hoces da nadjes od Petra Petrovica podatke o poslednjih 30 plata. Nemas kompjuter, sve cuvate na papiru. Prvo moras da nadjes u nekoj prostoriji gde je "fascikla" koja sadrzi podatke o Petru Petrovicu. Bez indeksa, ulazis u prostoriju u kojoj su fascikle na sve strane na rafovima. Uzmes jedan raf, ono Ana Nikolic, ispod njene fascikle Marija Nikolic, ispod nje Ivan Ivanovic. Pojma nemas gde vise da trazis fasciklu sa podacima o Petru Petrovicu vise jer vidis da je na sve strane haos.

Lupis indeks na "id" zaposlenog.

Ulazis opet u prostoriju. Sada imas (metaforicki) rafove sa slovima od A do Z, i vidis slovo P. Ides do tog rafa i imas mnogo manje posla da nadjes Petra Petrovica.

I sad idemo na poentu oko indeksa i zasto su po meni besmisleni u ovoj fazi ucenja...

Ti ces logicno skapirati da ti indeks olaksava posao u upitima koje budes pisao. Lupaces indekse ko blesav na sve kolone. Imaces opet prostoriju sa razbacanim stvarima. Ne treba ti to.

Kako zapravo treba da lupis indeks? Vidis koji podaci ti trebaju u upitu koji cesto koristis a zahteva obradu velike kolicine podataka. Onog trenutka kad budes trazio da su ti, recimo po adresi razvrstani na tim rafovima zaposleni, lupices indeks na kolonu "adresa".

Po difoltu vec imas index na PK. Dok ne budes znao sta zapravo treba da radis sa ovim tabelama, nijedan indeks ti nece gotovo nista znaciti. Ali... recimo da hoces da dobijes dopisivanje korisnika 1500 i korisnika 1501. Znaci trebaju ti posiljalac 1501, primalac 1500, i obrnuto. To vec postaje sporo. Onda stavis multi-column (cuo sam razne nazive za ovaj tip indeksa) na (posiljalac_id, primalac_id) i imas brz pristup tim podacima. To ima smisla, a na slepo lupati indekse bez scenarija nema i trosenje je sistemskih resursa gde potencijalno mozes i da usporis celu bazu i da je bloatujes, jer pri svakoj promeni podataka, indeksi moraju da se refreshuju s vremena na vreme (ovo se radi automatski) i to je to.

Full-text index... moze... al' je skup k'o djavo. Po meni su to vec naprednije stvari, gde na primer ja koristim postgreSQL poslednjih x godina, zavisi i koji tip indexa postavljam i sta ti ja znam... zavisi i da li je upit koji radis "jednako" ili "like"...

Jos jedna stvar - indeksi su vrlo, vrlo uprostena stvar, ali vrlo efikasna. Maltene se sve svodi na postavljanje pravog indexa, a to su ti uvek uslovi u upitu. Poenta je kako ih postaviti dovoljno da ih ima, a ne preterano da gube smisao. Sve vise i vise gledam ljude koji bi kesirali u 512GB RAMa celu bazu da mogu i imaju flat tabele odakle odrade jedan select i dobiju sta im treba bez icega.

Ako mozes, idemo lepo redom jedan po jedan zadatak pa cemo da objasnjavamo svi. Petak vece, cime se ES zanima :)

Naravno da ja imam vremena ako vi imate strpljenja haha,
Otprilike sam shvatio sta su i cemu sluze indexi, omogucavaju nam laksu i brzu pretragu u bazi, sa manje upita. Ako sam dobro pohvatao.

Ja sada kada sam usao da izmjenim tabelu plata tu vec imaju dva indexa, primary tip primary, i id_zaposlenog_unique tip unique
takodje u zaposleni ima zaposleni_id_unique tip unique i u porukama imaju id_posiljaoca_idx i i primaoca tip index i poruka_id_unique
pretpostavljam da su se ti indexi sami napravili zbog fk i oznake uq na kolonama
da li je potrebno da ja oznacavam neke nove?

Sad vidim ovaj post :)

Primary key, osim sto je po difoltu index, isto je i unique. Znaci ne mozes imati zaposlenog koji ce imati isti id kao neki drugi zaposleni.

Ako stavis unique na polje zaposleni_id u platama, bukvalno si blokirao da zaposleni primi vise od jedne plate u ovom slucaju :D

Unique constraint ti oznacava polje koje mora biti, po svaku cenu unikatno. Takodje, ne mora biti jedno polje, mozes da stavis na 2 polja unique, i onda kombinacija ta 2 polja ne sme da se ponovi u toj tabeli.

sada sam probao da ga otkacim ali mi iskace greska, kaze cannot drop index id_zaposlenog needed in a foreign key constraint

Ne treba da dropujes index vec unique constraint :) Ako sam nesto prevideo, probaj u bazu da ubacis dve plate za jednog korisnika u bazu, ako baci gresku, mora da se sklanja.