Šta je novo?
Od:
Filteri

Kafic-access..

I

ironman2

Cenjen
Učlanjen(a)
06.02.2011
Poruke
34
Poena
159
potreban mi je savet u vezi baze podataka o kaficu,preciznije o tabeli prodaja,kako bih mogao da izvedem to ja sam nesto uradio,ali imam problema u vezi narucivanja vise artikla za jedan sto ? ko moze da mi pomogne poslacu mu da vidi to.. :D
 
A sto ne napises ovde pa svi da vidimo :). Da li ti treba dizajn same baze ili cele aplikacije?
 
---- +----------------+-----------------+---------------- МАГАЦИН-------------+----------------+------------------
Р.Бр.|Назив артикла |Јединица мере |Количина(стање) |Набавна цена |Рок трајања | Датум пријема


----+---------------+---------ШАНК-------------+--------------
Р.Бр.|Назив артикла | Стање Продајна цена | Порез %

ПРОДАЈА
Р.Бр. Назив артикла(шанк) Количина Датум Време Радник Шифра стола Бр.Рачуна

sta bih mogao ovde da odradim,izmenim i dodam ?
 
Napravi neki dijagram da vidimo, kakve su ti relacije izmedju tabela, sta je problem?
 
Najbolje bi bilo da postavis celu bazu koju radis. Ne razumem kako tacno hoces da napravis to sa porudzbinama za sto? Pa napravis jednu tabelu sa popisom stolova i napravis tabelu sa porudzbinama po stolivama i povezes tako da jednom upisan sto moze da se koristi vise puta u tabeli Porudzbine na primer.
 
Poslednja izmena:
Ni meni nije skroz jasno, i dalje, ali cenim da je Switch resio, ili je blizu. Tabela sa porudzbinama mislim da bi bila dovoljna i neka m:n relacija prema svim proizvodima koje imas. To bi znacilo jos jednu tabelu koja bi imala kljuc porudzbine i po jedan kljuc proizvoda, kako se vec prave m:n relacije :D. Ovo zvuci pomalo teoretski, jer i jeste nisam imao previse ovozivotnih (vanispitnih :D ) iskustva sa bazama, ali valjda bi ovo radilo :) .
 
@ WebWolf
Bas to. U tabeli Porudzbine primarni kljuc bi trebao da bude i broj stola koji kupi iz tabele Stolovi i sifra Robe koju kupi iz neke tabele gde su popisani artikli. I onda kombinacijom ta dva polja dobija jedinstveni identifikator za tu tabelu porudzbine. Nego, najbolje bi bilo, opet kazem, da mi vidimo tu aplikaciju.
 
Poslednja izmena:
mediafire.com
pa kopiras link ovde

ili ides na reply to thread pa onda kliknes na manage attachments
 
Switch je napisao(la):
@ WebWolf
Bas to. U tabeli Porudzbine primarni kljuc bi trebao da bude i broj stola koji kupi iz tabele Stolovi i sifra Robe koju kupi iz neke tabele gde su popisani artikli. I onda kombinacijom ta dva polja dobija jedinstveni identifikator za tu tabelu porudzbine. Nego, najbolje bi bilo, opet kazem, da mi vidimo tu aplikaciju.
Kliknite za proširenje...

Ok, razumemo se, ali sam sto i proizvod nije dovoljan identifikator, vec mora jos neki jedinstveni broj u sklopu porudzbine. Ako bi imao samo broj i artikal ti tu ne mozes da diferenciras sta je kada naruceno, da li odjednom, mozda vreme porudzbine i slicno. Imas samo sto, i sta je otislo za taj sto i nista vise osim toga. Sto se takve organizacije tice, mogao si da imas 1000 ljudi tog dana u istom momentu za tim stolom koji su narucili sve odjednom ili da su se celog dana smenjivale druge osobe.

Da pojasnim, po tvojoj ideji islo bi:

Porudzbina:
Sto | artikal
001 | 1225
001 | 515
001 | 612

Dakle, ne vidis kako su porudzbine grupisane.
 
Poslednja izmena:
Onda treba da se naprave cetiri tabele - Roba,Stolovi,Porudzbine i StavkePorudzbine. U tabeli porudzbine bi trebalo da se nadju polja - ID, BrojStola (koji bi bilo povezano sa tabelom Stolovi),datum i vreme. U tabeli StavkePorudzbine - ID porudzbine (iz tabele Porudzbine) i artikli (iz tabele Roba). I onda bi u toj tabeli dva polja - ID porudzbine i artikli bili primarni kljuc.
 
Upravo tako :) .
 
Nije mi jasno zasto hoce da okaci .doc file? :) Nek' okaci samo bazu na kojoj radi da vidimo kako je on zamislio to.
 
Ko te natera da stavis ime fajla cirilicom, ne mogu da otvorim?!

Cek, ovo tebi treba za neku vezbu, ne za ozbiljan posao? Ako je tako, ne vidim kojom to putanjom razvoja idete :D .
 
Da prvo na papiru tako uce u skoli, a kad prodjes prvi dead line zaboravis papirice :) Sto se tice vise artikala za jedan sto. Imas tabelu gde su ti podaci sa artiklima, ok. Svaki artkal ima svoj id. Napravi skolski sistem. Napravi tabelu stolovi. Napravi tabelu 'porudzbine', kada neko naruci 5 artikala u porudzbine upisi ID stola i ID artikla znaci 5 redova. Dodaj tu i jedno bool polje 'isporuceno' i eventualno naplaceno, da se konobar ne zaboravi ;) Dalje imas kolone koje mozes da izdvojis u posebne tabele: profesija, nivo pristupa, radnik, artikli. To ti je generalno. Napravi nesto pa javi ako zapnes. Imas problem sa tim stolovima jer nisi normalizovao bazu, kao sto sam rekao gore razdvoj sve kljucne entitete i organizuj relacije.
 
1110 je napisao(la):
Da prvo na papiru tako uce u skoli, a kad prodjes prvi dead line zaboravis papirice :) Sto se tice vise artikala za jedan sto. Imas tabelu gde su ti podaci sa artiklima, ok. Svaki artkal ima svoj id. Napravi skolski sistem. Napravi tabelu stolovi. Napravi tabelu 'porudzbine', kada neko naruci 5 artikala u porudzbine upisi ID stola i ID artikla znaci 5 redova. Dodaj tu i jedno bool polje 'isporuceno' i eventualno naplaceno, da se konobar ne zaboravi ;) Dalje imas kolone koje mozes da izdvojis u posebne tabele: profesija, nivo pristupa, radnik, artikli. To ti je generalno. Napravi nesto pa javi ako zapnes. Imas problem sa tim stolovima jer nisi normalizovao bazu, kao sto sam rekao gore razdvoj sve kljucne entitete i organizuj relacije.
Kliknite za proširenje...
pogledaj ovo sto sam uradio pa mi reci sta nije dobro ..:D
 
Nisam navikao da pisem R.Br umesto toga pisem ID dakle neko moje misljenje, na brzaka...

tbl_Radnici {RadnikId, Ime, Prezime, Adresa, ProfesijaId, Plata, NivoPristupaId}
tbl_Profesije {ProfesijaId, Naziv, Opis}
tbl_NivoPristupa {NivoPristupaId, Naziv, Opis}

tbl_Artikli {ArtikalId, Naziv, Opis, Cena} -- Ovo su artikli koji se prodaju u sanku, dakle ne magacin

tbl_Stolovi {StoId, Lokacija}

tbl_Sank {SankId, Naziv}
tbl_ArtikliUSanku {SankId, ArtikalId, Stanje}
tbl_Porudzbina {PorudzbinaId, StoId, ArtikalId, RadnikId, Datum, Vreme}

Ne vidim ulogu tabele prodaja buduci da sve mozes da obracunas preko tabele porudzbina.

Takodje ovaj magacin ti je kako ja vidim potpuno odvojena celina. Ako je to eksterni magacin koji dostavlja robu u razne sankove sirom grada, tako da za to treba malo pojasnjenja o cemu se zapravo radi?
tbl_Magacin {ArtikalId, JednicaMere, Kolicina, NabavnaCena, RokTrajanja, DatumPrijema}
 
Poslednja izmena:
Ni ja ne vidim smisao tabele porudzbina. Ali vidim potrebu za tabelom u kojoj bi bili samo brojevi porudzbina i podaci o njima, recimo. Mada se to sa tehnicke strane moze resiti View-om ili indeksom. U nju bi mogao da smestis i ID radnika, datum i vreme i broj stola, jer bi po ovakvoj arhitekturi imao dosta ponavljanja podataka u ovom smislu:

Fiktivna porudzbina:

001 | Sto1 | 515 | Djole | 01.04.2011 | 00:00
001 | Sto1 | 314 | Djole | 01.04.2011 | 00:00
001 | Sto1 | 802 | Djole | 01.04.2011 | 00:00

A bez toga bi imao samo ID porudzbine i artikle u sklopu porudzbine u jednoj tabeli, i ostale podatke o narudzbini u drugoj. Po mom misljenju to je urednije i preglednije. Nadam se da je jasno.

Jesi to tako zamislio?
 
eee to majstore(WebWolf), ja sam hteo na tu foru da odradim ali nisam uspeo.A i u mom primeru sto sam radio ja sam na taj nacin hteo da odradim,da li bi mogao ako imas vremena da mi to odradis u word sa nekim sazetim objasnjenjem,ako si dobre volje?
 
Da pitao si i sta ne valja to sam zaboravio. Baza tj. tabele u bazi treba da budu u relacijama da ne bi dolazilo do redudantnosti podataka. Izguglaj obavezno pojam 'normalizacija' to je osnov za svaki dizajn baze. Kada dizajniras bazu treba da prepoznas njene glavne igrace (entitete) i od njih napravis tabele (tipa...radnik...artikal...itd) i onda koristis kombinovane tabele kao sto sam ti napisao gore, a WebWolf ti napisao primer popunjavanja tabele (Porudzbina). Ne znam za koji nivo radis ali dobro normalizovana i robustna baza sigurno donosi dobru ocenu :)
 
@1110

A sad ti meni malo da pomognes :D . Ja sam sa bazama radio samo na faxu, i radili smo normalizaciju ali nisu nam prikazali bas koji je znacaj toga. I kada kazes normalizacija, koju normalizaciju podrazumevas jer smo ih radili 5 valjda? Znaci, malo pojasnjenje svega toga bi mi dobrodoslo :) .

@ironman2

Sta ti tacno treba objasnjeno i jel moze sutra prepodne, ranije popodne? :D

I jos nesto, ne znam koja je skola ili fax u pitanju, jeste radili vi EER ili UML dijagrame kod konceptualnog projektovanja baza? Deluje kao da niste, a meni su oni prilicno pomogli jer odmah vidim sta fali bazi i koji slucaj nije pokriven i sl.
 
Poslednja izmena:
Covece, sto ga ovoliko komplikujes sa word-om? Treba to da se procita sve. Kao seminarski da pises. :) Mnogo bi bolje bilo da napravis te tabele u access-u, bilo bi nam svima jasnije. I onda odmah vidis sta ne valja, a ovako u teoriji je tesko sve da se predvidi.
 
Poslednja izmena:
Covek je donekle u pravu, ipak je mnogo lakse dok se uradi "na papiru", rekao bih, jer posle kada shvatis da nesto nije ok moras da menjas tabele sto vuce posledice po druge tabele, ali ovo nije bas neki nacin za konceptualno projektovanje...
 
ja sam 4. godina E.T.S. prvi put se susrecemo sa tim,nismo spominjali.meni treba za utorak, pa nije nikakav problem,to je tvoja dobra volja :D
 
@1110

A sad ti meni malo da pomognes . Ja sam sa bazama radio samo na faxu, i radili smo normalizaciju ali nisu nam prikazali bas koji je znacaj toga. I kada kazes normalizacija, koju normalizaciju podrazumevas jer smo ih radili 5 valjda? Znaci, malo pojasnjenje svega toga bi mi dobrodoslo .
Kliknite za proširenje...

Ovde je jako dobar primer normalizacije http://www.phlonx.com/resources/nf3/
Kada kazem normalizacija mislim na prve 3. Jer se na trecoj baza smatra dovoljno dobro dizajniranom
4. i 5. normalna forma se gotovo nikada ne srecu (moze samo da se smislja teorija, da se muce studenti :) ).

U sustini normalizacija se samo na faksu i radi i to je jedino mesto gde treba da se radi, Razlog za to je sto je to u praksi ocigledno. I kada god dizajniras bazu podsvesno stvarajuci tabele i relacije izmedju njih ti ispunjavas normalne forme.
Primer 1NF kaze da ne sme da se ponavljaju kolone, tipa {PorudzbinaID, Artikal1, Artikal2, Artikal3} jer sta radis u slucaju da imas vise od 3 artikla. Logicno ovako niko ne bi projektovao bazu, ali za to ne treba da se razmislja o teoriji vec se odmah vidi da su u pitanju dve tabele. Jedan moj profesor na faksu je prodavao neku njegovu knjigu gde je tabla imala 3 kolone telefona, svadja se zavrsila mojim odsustvom sa predavanja i 10-kom na kraju semestra :).
Ili recimo 2NF ako korisnik na sajtu moze da ima 'role'. Jedan korisnik moze da ima sledece role: Admin, Member, Moderator. I sada imas neku tabelu koja izlistava ove podatke:
name |role |city
pera Admin london
pera Member london
pera Moderator london
Normalniji dizajn bi bio sa tabelama
Role {RoleId, Title, Description}
UsersInRoles {UserId, RoleId}
User {Name, City}
Jer grad ipak zavisi samo od korisnika, nema veze sa njegovom rolom.

Ne treba se previse smarati sa ovim jer kada napravis par baza na faksu i nekoliko u realnoj situaciji vidis da je ta teorija u sustini ocigledna.
Ja radim evo vec 3 godine, kroz ruke mi je proslo x baza i ta teorija mi nikada nije trebala, ali na faksu mi je citanje toga pomoglo da shvatim generalno kako relaciona baza treba da izgleda.
 
Meni neke stvari nisu jasne u ovom objasnjenju. Prvo, kako se npr. "prebacuje" roba iz magacina u sank? Da li postoji neki poseban dokument za ta "prebacivanja" ili se samo u tabeli sank odabere artikal i upise kolicina tog artikla u sanku i onda se to oduzme od kolicine u tabeli Magacin?
Najjednostavnije resenje je da se naprave dve tabele za porudzbine - jedna npr. Narudzbina koja ce da cuva osnovne podatke svake narudzbine i druga NarudzbinaStavke koja ce izlistava sve stavke razvrstane po id-jevima narudzine. u tabeli Narudzbina bi trebalo da se nadju polja ID, datum, konobar i broj stola. Stolove popises u posebnu tabelu, kao i konobare u tabeli Radnici. Tabela Narudzbina vuce podatke o artiklima iz tabele sank i mora da ih skida sa stanja slicno kao sto tabela Sank skida sa stanja u tabeli Magacin. To mozes resiti update query-ijem.
Ono sto ne valja jeste nacin na koji se racuna Iznos u tabeli Narudzbina. Ukoliko se cena proizvoda nalazi u relaciji sa tabelom Sank (a nalazi se), onda ce svaka izmena cene tog proizvoda da utice na iznos u svim arhiviranim racunima i porudzbinama i da se menja u skladu sa promenom cene u tabeli Sank, a to ne sme da se desi. :) Racun i narudzbina treba da se nekako arhiviraju i ne samo da ne sme da se stampa dva i vise puta, nego ne sme vise da se menja kad se jednom odstampa. Tabela Prodaja je zapravo upit koji filtrira podatke iz tabele Narudzbina sa kriterijumom broj stola.
 
Evo je neka ideja, na brzaka...
 

Prilozi

  • Untitled.png
    Untitled.png
    45 KB · Pregleda: 123
odabere se artikal i upise kolicina tog artikla u sanku i onda se to oduzme od kolicine u tabeli Magacin, isto ako moze neko objasnjenje u vezi izvestaja
 
Morate se prijaviti ili registrovati da odgovorite ovde.
Vrh Dno