Pomoć oko kreiranja baze podataka

Imam zadatak : Potrebno je napraviti bazu podataka za elektornski sistem jedne kompanije. Sistem treba da biljezi informacije o korisnicima njihovim platama te korespodenciji kroz poruke. Za korosnike je potrebno cuvati sledece podatke : ime, prezime, datum rodjenja, e mail adresu, korisnicko ime, biografija, fotografija.

Za plate je potrebno cuvati informacije o datumu plate, njenom iznosu, kao i o tome kome taj unos pripada.Takodje ,otrebno je imati status o tome da li je pata isplaćena ili ne, kao i o tome o kojem se tipu zaposlenja radi.
Za korespodenciju,odnosno same poruke, potrebno je cuvati samu poruku, datum same poruke, njen satus(procitana ili ne ) ,kao i to koji korisnik šalje samou poruku (naglasiti primaoca i pošljiaoca)

Potrebno je sve to svakako prikazati i u EER dijagramu...

Počela sam ovako, na slici mozete vidjeti dijagram koji sam prvobitno napravila... Da li je to Ok ? https://ibb.co/dkWkrGP
Trebam napravti 3 tabele , pa onda povezati ih ?
Sad sam zapela ...
Da li mi moze neko pomoci?

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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

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

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

:( :(
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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

https://files.fm/u/rmets9377

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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

Potpis

Nemoj da pricas?

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.

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Ć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.

Potpis

THE ONLY EASY DAY WAS YESTERDAY

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.

Potpis

THE ONLY EASY DAY WAS YESTERDAY