Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Baza za galeriju slika -problem!!!

[es] :: Baze podataka :: Baza za galeriju slika -problem!!!

Strane: 1 2

[ Pregleda: 6654 | Odgovora: 25 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

bakasoka
student

Član broj: 192522
Poruke: 23
*.dynamic.sbb.rs.



Profil

icon Baza za galeriju slika -problem!!!22.05.2017. u 13:50 - pre 83 meseci
Pozdrav svima!!!

Pokušavam da napravim SQL bazu za prodajnu galeriju slika i trenuto sam zapela na jednom problemu:
Nabavka i prodaja dela???
Pošto su umetnička dela jedinstvena, moram da obezbedim da se jedno delo može kupiti samo jednom i prodati samo jednom...
To trenutno sa mojom bazom nije slučaj.

Evo i sličice...pa pišite vaše sugestije.

Prikačeni fajlovi
 
Odgovor na temu

bakasoka
student

Član broj: 192522
Poruke: 23
*.dynamic.sbb.rs.



Profil

icon Re: Baza za galeriju slika -problem!!!23.05.2017. u 12:50 - pre 83 meseci
Niko nema neki komentar? Getsbi, captPicard, Zidar..bilo ko?
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Baza za galeriju slika -problem!!!23.05.2017. u 13:46 - pre 83 meseci
Je'l ti Delo_ID Unique u svim tabelama? :)
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Baza za galeriju slika -problem!!!23.05.2017. u 14:39 - pre 83 meseci
Gde god u nekoj tabeli postoji DeloId a sme da se pojavi samo jednom, to polje proglasi da je Unique i neće biti moguće uneti dva sloga sa istim DeloId.

 
Odgovor na temu

captPicard
programer
more i planine

Član broj: 216084
Poruke: 1119



+19 Profil

icon Re: Baza za galeriju slika -problem!!!23.05.2017. u 14:41 - pre 83 meseci
Citat:
nkrgovic: Je'l ti Delo_ID Unique u svim tabelama? :)


Nije mu :)

Po meni je to dovoljno dobro rješenje, samo pazi da se ne bi dogodilo da u budućnosti stigne upit da se jedno djelo može prodati više puta, pa da si sada ne napraviš probleme odmah u startu.
F
 
Odgovor na temu

anon115774

Član broj: 115774
Poruke: 1656



+920 Profil

icon Re: Baza za galeriju slika -problem!!!23.05.2017. u 15:51 - pre 83 meseci
^ Upravo to. Bolje sada napravi da za svako delo postoji "stanje u magacinu" i da se ne moze prodati ako je stanje 0. A onda kada se unosi novo delo neka bude hardcoded 1 za stanje pa ako u buducnosti bude trebalo da se menja lakse ce se izmeniti nego ako se sada napravi da je uvek samo jedno.
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 09:11 - pre 83 meseci
Citat:
captPicard:
Citat:
nkrgovic: Je'l ti Delo_ID Unique u svim tabelama? :)


Nije mu :)

Po meni je to dovoljno dobro rješenje, samo pazi da se ne bi dogodilo da u budućnosti stigne upit da se jedno djelo može prodati više puta, pa da si sada ne napraviš probleme odmah u startu.

Da, ja kao probao onako, Sokratovski, da ga propitujem ne bi li sam spoznao odgovor... :D
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

bakasoka
student

Član broj: 192522
Poruke: 23
*.dynamic.sbb.rs.



Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 09:43 - pre 83 meseci
Hvala vam svima, što ste se uključili...

Delo_ID je primary key, ne znam kako da ga definišem kao unique...kako smo učili - svaki Primary key je jedinstvena vrednost...i u mojoj bazi svako delo ima svoj Delo_ID (različiti), ali pri insertu podataka u bazu, ako pokušam da jedno delo kupim od dva različita dobavljača,i isto, ako unesem da je jedno delo kupilo više klijenata... ne prijavljuje nikakvo ograničenje ili grešku ( Moram li ga posebno definisati kao unique i kako)...
Evo DDL:
Code:

create table Delo
(Delo_ID int Primary key IDENTITY (500,1)NOT NULL,
Naziv varchar (50) NULL,
Godina_Nastanka int NULL,
Visina_dela numeric (10,2) NULL,
Širina_dela numeric (10,2) NULL,
Autor_ID int NOT NULL,
Potpis bit NULL,
Napomena varchar (MAX) NULL,
Foreign key (Autor_ID) references Autor (Autor_ID))
;
create table Nabavka_dela
(Broj_nabavke int Primary key IDENTITY (1000,1)NOT NULL,
Dobavljač_ID numeric(13,0) NOT NULL,
Delo_ID int NOT NULL,
Datum_nabavke date NULL,
Cena_nabavke numeric (20,2) NULL,
Foreign key (Dobavljač_ID) references Dobavljač (Dobavljač_ID),
Foreign key (Delo_ID) references Delo (Delo_ID))
;
create table Prodaja_dela
(Broj_prodaje int Primary key IDENTITY (5000,1)NOT NULL,
Klijent_JMBG numeric(13,0) NOT NULL,
Delo_ID int NOT NULL,
Datum_Prodaje date NULL,
Cena_prodaje numeric (20,2) NULL,
Foreign key (Klijent_JMBG) references Klijent (Klijent_JMBG),
Foreign key (Delo_ID) references Delo (Delo_ID))


 
Odgovor na temu

bakasoka
student

Član broj: 192522
Poruke: 23
*.dynamic.sbb.rs.



Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 09:52 - pre 83 meseci
Citat:
Po meni je to dovoljno dobro rješenje, samo pazi da se ne bi dogodilo da u budućnosti stigne upit da se jedno djelo može prodati više puta, pa da si sada ne napraviš probleme odmah u startu.


Delo se odnosi na umetničku sliku, tako da ne može da postoji više istih dela, pa se ne može desiti nabavka ili prodaja više puta za isto delo- kako u realnosti, tako i u bazi.

Ova moja baza se ponaša kao da se radi o prodaji ili nabavci običnih artikala (kojih može biti više na stanju)...
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 10:02 - pre 83 meseci
Citat:
bakasoka:
Delo_ID je primary key, ne znam kako da ga definišem kao unique...kako smo učili - svaki Primary key je jedinstvena vrednost...i u mojoj bazi svako delo ima svoj Delo_ID (različiti), ali pri insertu podataka u bazu, ako pokušam da jedno delo kupim od dva različita dobavljača,i isto, ako unesem da je jedno delo kupilo više klijenata... ne prijavljuje nikakvo ograničenje ili grešku ( Moram li ga posebno definisati kao unique i kako)...


U tabeli Dleo jeste PK ali u ostalim tabelema nije a nije ni unique a moralo bi biti ako u tim tabelama ne sme da se unese isto delo više puta.

Kako se to radi vidi u dokumentaciji baze koju korsitiš. Negde se definiše na nivou polja a negde se definiše preko indeksa.
 
Odgovor na temu

bakasoka
student

Član broj: 192522
Poruke: 23
*.dynamic.sbb.rs.



Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 10:17 - pre 83 meseci
Citat:
Kako se to radi vidi u dokumentaciji baze koju korsitiš. Negde se definiše na nivou polja a negde se definiše preko indeksa.


Nema dokumentacije baze, ja treba da ju napravim...
Može li ovako:

Code:

create table Delo
(Delo_ID int Primary key IDENTITY (500,1)NOT NULL,
Naziv varchar (50) NULL,
Godina_Nastanka int NULL,
Visina_dela numeric (10,2) NULL,
Širina_dela numeric (10,2) NULL,
Autor_ID int NOT NULL,
Potpis bit NULL,
Napomena varchar (MAX) NULL,
Foreign key (Autor_ID) references Autor (Autor_ID))
;
create table Nabavka_dela
(Broj_nabavke int Primary key IDENTITY (1000,1)NOT NULL,
Dobavljač_ID numeric(13,0) NOT NULL,
Delo_ID int UNIQUE NOT NULL,
Datum_nabavke date NULL,
Cena_nabavke numeric (20,2) NULL,
Foreign key (Dobavljač_ID) references Dobavljač (Dobavljač_ID),
Foreign key (Delo_ID) references Delo (Delo_ID))
;
create table Prodaja_dela
(Broj_prodaje int Primary key IDENTITY (5000,1)NOT NULL,
Klijent_JMBG numeric(13,0) NOT NULL,
Delo_ID int UNIQUE NOT NULL,
Datum_Prodaje date NULL,
Cena_prodaje numeric (20,2) NULL,
Foreign key (Klijent_JMBG) references Klijent (Klijent_JMBG),
Foreign key (Delo_ID) references Delo (Delo_ID))

 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3445

Jabber: djoka_l


+1462 Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 10:53 - pre 83 meseci
Citat:
Delo se odnosi na umetničku sliku, tako da ne može da postoji više istih dela, pa se ne može desiti nabavka ili prodaja više puta za isto delo- kako u realnosti, tako i u bazi.


Moram malo da se nasmejem na naivnost
Ja sam čuo da se neke slike i po više puta kupuju i prodaju Šta ako se za neku sliku koju je galerija već prodala, pojavi novi kupac sa boljom ponudom, pa se vlasnik polakomi i preproda? Ili vlasnik umre pa naslednici žele da ponude sliku na prodaju?

JMBG - najbolje da zaboraviš da tako nešto postoji. Počevši od toga da je jedan format za fizička lica, drugi za pravna lica. Da je u velikom broju slučajeva JMBG pogrešan, ili pogrešno upisan ili pogrešno generisan. Da ti ne pričam koliko sam puta imao priliku da vidim ljude rođene 31. novembra, muškarce sa ženskim JMBG-om i obrnuto. A šta je sa strancima koji bi od tebe hteli da kupe sliku? NIKADA NE KORISTI JMBG KAO PRIMARNI KLJUČ! U stvari, ništa što je EKSTERNO generisano kao unique id NE KORISTI za PK (recimo poštanski broj može da izgleda kao dobar primarni ključ ali on to nije - to je interna oznaka pošte za njenu filijalu i pošta povremeno menja numeraciju).

Sama baza nije baš dobra. Recimo, iz dijagrama, potencijalni kupac se interesuje samo za autora ali ne i za konkretno delo. Zašto tamo nema datuma - recimo potencijalni kupac se interesuje za više dela, pa onda promeni mišljenje. U tvojoj bazi je večito zainteresovan samo za neke autore. Kako zamišljaš da obavestiš potencijalnog kupca da imaš nešto da mu ponudiš? Recimo imaš od autora X 3 slike, ali kupac nije zainteresovan ni za jednu od njih, nego za neke druge slike od istog autora koje ti planiraš da otkupiš. Kupovina i prodaja treba da budu jedna tabela. Treba ti neki status dela (kod dobavljača, kod kupca, u galeriji...).
Ako je ograničenje samo na slike OK, ali šta je sa grafikama? Grafike su vrlo slične slikama samo što ih može biti više, recimo serija od 50 komada.

EDIT:
Tabela tehnika, potpuno bez veze. Izgleda da si je stavio samo da popuniš normu po broju tabela. Ako je vezana za samo jedno delo i ima samo jedan prikaz dela, zašto ta dva polja nisu deo tabele delo. Ako si hteo da pokažeš da znaš normalizaciju, nisi uspeo. Ima nekog smisla da napraviš šifarnik tehnika (ulje na platnu, pastel, ...) pa da onda u delo staviš id tehnike, ali prikaz dela nema smisla sklanjati iz tabele delo.

Ah, da. Po čemu se razlikuju Dobavljač fizičko lice i Klijent. To su po svojim atributima dva potpuno ista entiteta, ali stavio si ih u dve tabele. U stvari u tri, zato što si dobavljaču izbacio adresne podatke u drugu tabelu. A šta ćemo, ako, ne daj bože, kupac/dobavljač imaju više telefona, kao u malo verovatnom slučaju da imaju mobilni i fiksni? Ili više e-mail adresa? Ili više adresa - jednu za kontakt drugu za isporuku/preuzimanje dela.



[Ovu poruku je menjao djoka_l dana 24.05.2017. u 12:07 GMT+1]
 
Odgovor na temu

bakasoka
student

Član broj: 192522
Poruke: 23
*.dynamic.sbb.rs.



Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 10:58 - pre 83 meseci
Hvala vam svima! :* :* :* Obožavam ovaj forum i sve vas!

Baš mi je to trebalo...i naučila sam nešto novo...sad sve funkcioniše kako treba!!!
Kiss

P.S.
Javljam se opet, kad zapnem (a sigurno će se desiti)
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3445

Jabber: djoka_l


+1462 Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 11:29 - pre 83 meseci
U stvari, ovo je tipični studentski "projekat". Mislim da bi čak i sa ovakvim dizajnom dobila (studentkinja, zar ne) prelaznu ocenu 7 ili 8. Pa bi se pitala gde je greška. Meni bi, u stvari, bio najveći problem gde da prestanem. Recimo, galerija može da ima zaposlene, zaposlenima možda treba dati bonus na osnovu zarade od prodaje. Pa onda dela, stavio bih neka polja kao što je žanr i gomilu nekih drugih tagova, tako da bih, recimo, ako se kupac interesuje za neko impresionističko delo, moga da mu ponudim drugo impresionističko delo od drugo autora. Pa onda gomila ljudi još može da učestvuje. Recimo restaurator ako je delo oštećeno, pa onda procenitelj, ako je ponuđeno delo na prodaju, a vlasnik nema pojma koliko može da dobije za njega. Pa, recimo, stari trgovački moto, što nema u izlogu ima u radnji. Ako se neko interesuje za neko delo, a ti ga nemaš, nikada ne kažeš nema, nego se raspituješ kod drugih galerija pa onda javiš kupcu, e baš sad nađoh u podrumu...
 
Odgovor na temu

bakasoka
student

Član broj: 192522
Poruke: 23
*.dynamic.sbb.rs.



Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 12:02 - pre 83 meseci
Citat:
Moram malo da se nasmejem na naivnost


Jesam, naivna, pogotovo u programiranju...svaka mi je sugestija dobro došla, zato i jesam tu...

Citat:
Ja sam čuo da se neke slike i po više puta kupuju i prodaju Šta ako se za neku sliku koju je galerija već prodala, pojavi novi kupac sa boljom ponudom, pa se vlasnik polakomi i preproda? Ili vlasnik umre pa naslednici žele da ponude sliku na prodaju?


Ako to bude slučaj, ponovo ulazi u galeriju sa novim ID-jem. Meni je samo bitna evidencija trenutnog stanja u galeriji...gornji problem, koji je rešen sa Unique key je dovodio do toga da se uopšte ne zna da li je delo prodato ili nije (moglo se prodati mnogo puta)...

Citat:
JMBG - najbolje da zaboraviš da tako nešto postoji.


Znam za to, u realnosti i praksi, ali u školskim zadacima insistiraju da se, ako je to moguće, jedno polje tabele (ili više polja) identifikuje kao Primary key...(ne znam zašto, pretpostavljam da je to da se pokaže da smo shvatili da PK mora biti jedinstvena vrednost...)


Citat:
Recimo, iz dijagrama, potencijalni kupac se interesuje samo za autora ali ne i za konkretno delo. Zašto tamo nema datuma - recimo potencijalni kupac se interesuje za više dela, pa onda promeni mišljenje. U tvojoj bazi je večito zainteresovan samo za neke autore. Kako zamišljaš da obavestiš potencijalnog kupca da imaš nešto da mu ponudiš? Recimo imaš od autora X 3 slike, ali kupac nije zainteresovan ni za jednu od njih, nego za neke druge slike od istog autora koje ti planiraš da otkupiš.


Ta tabela je informativnog karaktera, ti u svakom slučaju kupcima nudiš sve što imaš, ali je dobro znati (ima ljudi koji stvarno kupuju samo Janoša Mesaroša...šta god da je naslikano).
Planiram da bazu implementiram u C#-u, pa sam mislila da mi na formi izađe interesovanje nekog klijenta, ukoliko specifično postoji...ta informacija može da stoji i u napomeni tabele Klijenti (ali ovako bih imala i pregled sveukupnih interesovanja klijenata, pa bi vlasnik galerije znao šta je traženo i šta da juri)...ako se interesovanje klijenta promeni, jednostavno ga promeniš i u svojoj bazi...

Citat:
Kupovina i prodaja treba da budu jedna tabela. Treba ti neki status dela (kod dobavljača, kod kupca, u galeriji...).


Molim te da mi ovo malo pojasniš, ako nije problem...Zašto kupovina i prodaja treba da budu jedna tabela?

Galerija ne zna, u realnosti, status dela kod dobavljča i kupca-funkcioniše ovako:

Primer 1.: Naslednik prodaje šta je nasledio (nema pojma šta je to)-on je u ovom slučaju dobavljač
Primer2: Ljudi koji cene umetnost i,nekada su mnogo kupovali umetnine, sad su u finansijskom škripcu-dobavljač
Primer3.: Aukcijska kuća organizuje aukcijsku prodaju i vlasnik ove galerije vidi neke dobre prilike za kupovinu -dobavljač
Primer 4.: Autor (slikar) hoće da proda svoje radove, a vlasnik galerije je zainteresovan -dobavljač

Primer 5.: Ljudi idu na svadbu, useljenje...-kupac
Primer 6.: Ljubitelj umetnosti, kolekcionari...-kupci
Primer 7.: Drugi trgovci umetninama, preprodavci...-kupci i dobavljači...

Citat:
Grafike su vrlo slične slikama samo što ih može biti više, recimo serija od 50 komada.


Slažem se da, ali nije isto da li kupiš Autorski otisak ili prvi ili 50-ti...nije ista cena, ni kvalitet otiska i moraju zasebno da se vode.

Citat:
Tabela tehnika, potpuno bez veze. Izgleda da si je stavio samo da popuniš normu po broju tabela. Ako je vezana za samo jedno delo i ima samo jedan prikaz dela, zašto ta dva polja nisu deo tabele delo. Ako si hteo da pokažeš da znaš normalizaciju, nisi uspeo. Ima nekog smisla da napraviš šifarnik tehnika (ulje na platnu, pastel, ...) pa da onda u delo staviš id tehnike, ali prikaz dela nema smisla sklanjati iz tabele delo.


Moja ideja je bila sledeća:

TblTehnika: je slabi objekat tabele delo, može biti Ulje, Akvarel, Crtež, Pastel,Grafika, Kombinovana, a čitala sam savete da je bolje Prikaz dela (sliku(fotografiju)),odnosno putanju do fajla u kojem se nalazi fotografija, odvojiti u zasebnu tabelu u bazi..
...to je bila moja logika, a za sve savete i sugestije sam otvorena...iskustvo uvek više cenim od udžbenika.

Hvala, unapred!












 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 12:04 - pre 83 meseci
Citat:
bakasoka:
Citat:
Kako se to radi vidi u dokumentaciji baze koju korsitiš. Negde se definiše na nivou polja a negde se definiše preko indeksa.


Nema dokumentacije baze, ja treba da ju napravim... :(



Ok loše sam se izrazio. Mislio sam na dokumentaciju servera baze ili šta već koristiš.

 
Odgovor na temu

Shadowed
Vojvodina

Član broj: 649
Poruke: 12846



+4783 Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 12:08 - pre 83 meseci
Citat:
bakasoka:
Delo se odnosi na umetničku sliku, tako da ne može da postoji više istih dela

Zavisi od vrednosti slike. Sto je vrednost veca to i verovatnoca za spontano pojavljivanje novih primeraka raste :)

[Ovu poruku je menjao Shadowed dana 24.05.2017. u 22:33 GMT+1]
 
Odgovor na temu

bakasoka
student

Član broj: 192522
Poruke: 23
*.dynamic.sbb.rs.



Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 12:33 - pre 83 meseci
Citat:
Zavisi od vrednosti slike. Sto je vrednost vece to i verovatnoca za spontano pojavljivanje novih primeraka raste


 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 13:05 - pre 83 meseci
Citat:
bakasoka:
Citat:
JMBG - najbolje da zaboraviš da tako nešto postoji.


Znam za to, u realnosti i praksi, ali u školskim zadacima insistiraju da se, ako je to moguće, jedno polje tabele (ili više polja) identifikuje kao Primary key...(ne znam zašto, pretpostavljam da je to da se pokaže da smo shvatili da PK mora biti jedinstvena vrednost...)


U svari je sam stvar vremena kada će ti postati problem to što ti je neko polje koje ima značenje PK. Bolje je za PK uvesti polje bez značenja, na primer autoincrement.

Svako polje koje ima značenje kad tad može da promeni značenje (ili vrednost) a menjanje vrednosti PK je nešto što ne treba da se radi.

Gledaj to ovako: svaka tabela ima primarni ključ i prirodni ključ. Svrha primarnog ključa je da jedinstveno identifikuje jedan slog tabele i samo to. Prirodni ključ takođe jedinstveno identifikuje jedan slog tabela li sam ključ ima i neko značenje, predstavlja neko svojstvo entiteta opisanog u slogu.

Primarni ključ i prirodni ključ mogu da budu isti ali je bolje da je primarni ključ bezznačenjski (pomenti autoinkrement). To ti omogućava da u bilo kom trenutku možeš da menjaš prirodni ključ tabele ali inegritet baze nećeš narušiti jer su tabele u relaicjama preko primarnog ključa, koji, pošto nema nikakvo značenje, praktično ikad nećeš morati da menjaš.

Na primer u tabeli klijent (usput dobar je običaj da se tabele nazivaju u množini jer sadrže više entiteta iste vrste) imaš poilje Klijent_JMBG koje ima ulogu primarnog ključa a ujedno je i prirodni ključ. Bolje je da uvedeš novo polje ID koje je autoinkrement i da ono postane PK, a da polje Klijent_JMBG bude samo Unique (čime se obezbeđuje da je i ono jednoznačno). AK bi se nakad desilo da drava odluči da sredi loš sistem JMBG i počne da menja JMBG, bazi to neće smetati, jer JMBG nije PK i možeš slobodno da ga menjaš.

U stvari, prirodni ključ može biti i složen i obuhvatati više polja, što tek nije dobro da se koristi i za Primarni ključ. Primarni ključ treba da bude jedno polje (mada ne mora) jer to MNOGO olakšava rad sa bazom. Složeni PK je recept za ogromne komplikacije. Čim u tabeli imaš složen prirodni ključ, to je znak d atreba odmah d auvedeš posebno namensko polje za PK da izbegneš da ti taj složeni ključ bude primarni. U svom primeru imaš par tabela u bazi koje su upravo takve i koje prosto vište da dobiju polje ID koje je autoinkrement i koje je PK.

Ako usvojiš ovo sa uvođenjem polja koje se zove ID, nema značenje i služi samo kao PK, to prvilo možeš da uvedeš na sve tabele jer ti na svakoj treba PK. Ako to uradiš, kasnije u razvoju aplikacije koja radi sa bazom možeš napraviti razne automatske mehanizme koji će lako raditi sa svakom tabelom jer će znati da svaka tabela ima polje ID koje je primarni ključ.

Citat:

Citat:
Recimo, iz dijagrama, potencijalni kupac se interesuje samo za autora ali ne i za konkretno delo. Zašto tamo nema datuma - recimo potencijalni kupac se interesuje za više dela, pa onda promeni mišljenje. U tvojoj bazi je večito zainteresovan samo za neke autore. Kako zamišljaš da obavestiš potencijalnog kupca da imaš nešto da mu ponudiš? Recimo imaš od autora X 3 slike, ali kupac nije zainteresovan ni za jednu od njih, nego za neke druge slike od istog autora koje ti planiraš da otkupiš.


Ta tabela je informativnog karaktera, ti u svakom slučaju kupcima nudiš sve što imaš, ali je dobro znati (ima ljudi koji stvarno kupuju samo Janoša Mesaroša...šta god da je naslikano).
Planiram da bazu implementiram u C#-u, pa sam mislila da mi na formi izađe interesovanje nekog klijenta, ukoliko specifično postoji...ta informacija može da stoji i u napomeni tabele Klijenti (ali ovako bih imala i pregled sveukupnih interesovanja klijenata, pa bi vlasnik galerije znao šta je traženo i šta da juri)...ako se interesovanje klijenta promeni, jednostavno ga promeniš i u svojoj bazi...

Citat:
Kupovina i prodaja treba da budu jedna tabela. Treba ti neki status dela (kod dobavljača, kod kupca, u galeriji...).


Molim te da mi ovo malo pojasniš, ako nije problem...Zašto kupovina i prodaja treba da budu jedna tabela?


Ne moraju da budu jedna tabela li u tvomslučaju nema razloga da ne budu jer obe tabel imaju potuno istu strukturu samo im se naziv razlikuje.

Da krenemo od kupaca, dobavljača, klijenata... tu ti imaš više tabela i nepotrebno si zakomplikovala. Kupac, dobavljaš, klijent, šta god, sve se to može svesti na isto: id, naziv (ime), adresni podaci, kontakt podaci. Dobro je da ti svi oni budu u istoj tabeli jer se zaista radi o potpuno istim podacima. Postoji samo razliku tipu (kupac, dobavljac, klijent).

Još ako kažeš dapostoji mogućnost da isti entitet može d abude i u svojstvu kupca i dobavljač ai klienta to samo upućuje da svi moraju biti u sitoj tabeli a to da li je neko kupac, dobavljač ili klijent treba da se naznači nekim svojstvom tabele, jer nema nikakvog smisla da iste podatke moraš da unosiš u više tabela smao zato što je neko i kupac i dobavljaš i klijent ili šta već. To sve treba da se unese u jednu tabelu.

Ja bih recimo uveo ili tri logička polja kao identifikatore kupac, dobavljač i klijent pa ako neko spada u datu grupu njemu staviš logičku jedinicu. Tako isti entitet može biti u više tih grupa. Mana tog pristupa je da, ako ti se pojavi četvrti tip, odna moraš da menjaš strukturu tabele. Ako to očekuješ onda ti treba tabela sa listom tipova i jedna M-N tabela za vezu kontakta sa tipovima. Ako ti treba pojasnjenje te strukture, reci.

Ako svaki tip ima neka specifična svojstva onda to možeš rešiti kao što si već delom i rešavala: uvedeš dodatne tabele za ta svojstva i povežeš ih 1-1 vezom sa osnovnom tabelom za kontakte.

Kad sko kod specifičnosti ti si opred tabele dobavljač uvela dve tabele za fizička i pravna lica jer si pravilno prepoznala specifična svosjtva za te tipove entiteta. Međutim, ovo kako si uradili je nepraktično. Jednostanvije je da u tabeli dobavljaci uvedeš polja Naziv1 i Naziv2 pa da se popunjavaju prema potrebi - negde ime i prezime, negde naziv ili šta već.

Ovo kako si ti napavila JESTE BOLJE, ali zahteva da aplikacija zna da se sa tim pozabavi tkaoda ne moraš da pravi posebno pregled fizickih a posebno pravnih lica vec da mozes sve da ih vidis kao jednu tabelu (jer oni suu paogramu svi dobavljaci, da li su fizicka ili pravnalica, manje je važno). Moguće je raditi ovako kakosi ti planirala i u ozbiljnijim apliakcijama se tako i radi, ali mislim da je to previse komplikovano za nivo apliakcije koju ti planiras da uradis.

Citat:

Citat:
Grafike su vrlo slične slikama samo što ih može biti više, recimo serija od 50 komada.


Slažem se da, ali nije isto da li kupiš Autorski otisak ili prvi ili 50-ti...nije ista cena, ni kvalitet otiska i moraju zasebno da se vode.


Ipak, realno je da ako ima više kopija istog dela, da imaš neku vezu između njih čak i ako ih vodiš kao sasvim zasebna dela. Za očekivati je da ako imaš 50 kopija iste grafike ne prikazuješ to kao 50 dela nego kao jedno delo u 50 kopija. Zamisli da na osnovu ove baze praviš web shop i da treba da prikažeš sliek svih dela koja su u ponudi. Šta bi ti rekli posetioci sajta ako bi morali da listaju tri strane sliak jednog te istog dela zato što ima 50 kopija?

Ja bih u bazi predvideo da pod novim ID evidentiram samo različito delo. Znači ako imaš autorski otisak to je jedno deloa ako imaš kopiju tog autorskog otiska to je drugo delo (i opet terba da postoji veza između njih da bi neko kome je možda original preskup video da može jeftinije da kupi kopiju). Ali ako imaš 50 kopija, onda je to sve jedno te isto, vodi se pod istim ID samo se vodi i količina.

Čim si pomenula autorsko delo i kopiju, eto ti još jednog svojstva koje treba da imaš u tabeli dela, da možeš da razlikuješ autorska dela od kopija.

Citat:

Citat:
Tabela tehnika, potpuno bez veze. Izgleda da si je stavio samo da popuniš normu po broju tabela. Ako je vezana za samo jedno delo i ima samo jedan prikaz dela, zašto ta dva polja nisu deo tabele delo. Ako si hteo da pokažeš da znaš normalizaciju, nisi uspeo. Ima nekog smisla da napraviš šifarnik tehnika (ulje na platnu, pastel, ...) pa da onda u delo staviš id tehnike, ali prikaz dela nema smisla sklanjati iz tabele delo.


Moja ideja je bila sledeća:

TblTehnika: je slabi objekat tabele delo, može biti Ulje, Akvarel, Crtež, Pastel,Grafika, Kombinovana, a čitala sam savete da je bolje Prikaz dela (sliku(fotografiju)),odnosno putanju do fajla u kojem se nalazi fotografija, odvojiti u zasebnu tabelu u bazi..


Ako jedno delo može da bude rašeno samo jednm tehnikom onda ovo kako si napravila nema smisla. Dovoljno je da tabela tehnika sadrži popis mogućih tehnika a da se u tabeli Delo u namensko polje upisuje kojom tehnikom je rađeno to delo.

Ako pak može da se desi da je jedno delo rađeno sa više tehnika, tabela tehnika treba opet da sadrži samo popis mogućih tehnika a da uvedeš novu tabelu za M:N vezu kojom bi dela povezivala sa primenjenim tehnikama. U stvari ova tvoaj tabela tehnika je po strukturi ta MN tabela a fali ti tabela sa listom svih tehnika.

 
Odgovor na temu

bakasoka
student

Član broj: 192522
Poruke: 23
*.dynamic.sbb.rs.



Profil

icon Re: Baza za galeriju slika -problem!!!24.05.2017. u 13:35 - pre 83 meseci
Citat:
U stvari, ovo je tipični studentski "projekat". Mislim da bi čak i sa ovakvim dizajnom dobila (studentkinja, zar ne) prelaznu ocenu 7 ili 8. Pa bi se pitala gde je greška. Meni bi, u stvari, bio najveći problem gde da prestanem. Recimo, galerija može da ima zaposlene, zaposlenima možda treba dati bonus na osnovu zarade od prodaje. Pa onda dela, stavio bih neka polja kao što je žanr i gomilu nekih drugih tagova, tako da bih, recimo, ako se kupac interesuje za neko impresionističko delo, moga da mu ponudim drugo impresionističko delo od drugo autora. Pa onda gomila ljudi još može da učestvuje. Recimo restaurator ako je delo oštećeno, pa onda procenitelj, ako je ponuđeno delo na prodaju, a vlasnik nema pojma koliko može da dobije za njega. Pa, recimo, stari trgovački moto, što nema u izlogu ima u radnji. Ako se neko interesuje za neko delo, a ti ga nemaš, nikada ne kažeš nema, nego se raspituješ kod drugih galerija pa onda javiš kupcu, e baš sad nađoh u podrumu...

Sve si u pravu...može to da se razlaže na mnogo strana: organizovanje izložbi, aukcija...zastupanje autora, uzimanje dela na revers...dela koja su za prodaju i ona koja vlasnik želi da zadrži za sebe...sve mi je to jasno...
Moja baza jeste studentski projekat, koji je ustvari Windows forms aplikacija, koja jednostavno treba da vodi evidenciju o kupovini i prodaji dela, klijentima i dobavljačima...evo ustvari opis projekta pa će vam biti jasnije...


Zahtevi za izradu projekta:
Prodajna galerija umetničkih slika se bavi preprodajom umetničkih slika. Informacioni sistem galerije sadrži bazu podataka u kojoj vodi evidenciju o klijentima kojima prodaje dela (ime, prezime, adresa, telefon) , o dobavljačima od kojih nabavlja dela, o autorima dela ( ime, prezime, godina rođenja, godina smrti, kratka biografija) i o samim umetničkim delima (naziv, godina nastanka, dimenzije). Umetnička dela su klasifikovana u tehnike izrede dela (Ulja, akvareli, crteži, grafike, kombinovana tehnika) i tu se čuva fotografija određenog dela.
Pored toga, vodi se evidencija o interesovanjima, odnosno, koji klijent je posebno zainteresovan za nekog autora.
IS galerije omogućava praćenje procesa nabavke slika, procesa prodaje slika, kao i pretragu po određenim kriterijumima.
Prilikom nabavke dela, galerija bira dela od dobavljača i plaća račun, nakon čega dobavljač isporučuje delo galeriji. Zaposleni unosi u bazu podatke o dobavljaču, podatke o delu, datumu nabavke dela i nabavnoj ceni. Dobavljač može biti fizičko lice ili pravno lice (neka druga galerija ili aukcijska kuća).
Prilikom prodaje dela, nakon što klijent izabere delo koje želi da kupi, galerija naplaćuje delo i uručuje ga klijentu. Zaposleni unosi podatke o klijentu koji je kupio delo, prodatom delu, datumu prodaje i prodajnoj ceni. Ukoliko je klijent stalni klijent galerije, zaposleni u IS galerije može da vidi za kojeg je autora klijent posebno zainteresovan, da u sistemu pronađe dela određenog autora koja galerija poseduje i ponudi ih klijentu.

Neophodno je obezbediti insert, update, delate podataka u bazi, kao i pretragu po određenom kriterijumu (select).
 
Odgovor na temu

[es] :: Baze podataka :: Baza za galeriju slika -problem!!!

Strane: 1 2

[ Pregleda: 6654 | Odgovora: 25 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.