Upit za pravljenje naloga za kuhinju

Gledao sam access bazu sa teme koju je pokrenuo SCELLE i zanima me kako bi mogao da se napravi upit za pravljenje naloga za kuhinju na osnovu odredjenog datuma ili raspona datuma.

Recimo:
za sobu 206 prijavljivanje pocinje 23.7 i traje do 27.7.
za sobu 205 prijavljivanje pocinje 24.7 i traje do 26.7

Nalog kuhinji:
za 23.7 - 1 x rucak i vecera: 24.7 - 1 x dorucak, 2 x rucak i vecera, 25.7 - 2 x dorucak i rucak i vecera, 26.7 - 2 x dorucak i 1 x rucak i vecera, 27.7 - 1 x dorucak.

Ovo je sve za po jednog gosta u sobama, a za vise gostiju bi se mnozilo sa brojem gostiju.


Saljem link fajla koji je sa teme "Pracenje rezervacija u malom hotelu"

http://static.elitesecurity.or...1/6/1653040/Rezervacije_ZS.zip

Primer koji si zakacio ima sufix _Z, znaci ja sam poslednji koji je nesto dodao u fajlu. Ova verzija ne lici na zavrsnu verziju, ni blizu. Ne sacam se sta smo tacno tada radili, deluje mi da sam samo pomogao oko kverija, a dizajn je odradio Scelle, ili je cak u pitanju ne ki provizrni dizajn baze, tek koliko da pokazemo kako se pisu trazeni kveriji. Ako moze neko na forumu da pronadje ovu temu, da se podsetiomo, a mozda ima I nesto dalje uradjeno. Ovo je vazno, jer ponudjena verzija nije dobra osnova za dalji rad.

Ponudjena verzija pokazuje samo kako se iz tabele rezervacija pokazuje status soba u odredjenom vremenskom interval, I nista vise. Pretpostavke su da su svi podaci u tabeli rezervacije dobri, sto znaci nema duplih rezervzcija, nema preklapanja rezervacija, rezrvacije su povezane sa tabelom Nosioci I tako dalje. Pretpostavke su delimicno tacne za prikazani primer, ali nema garancija da ce se to odrzati u buducnosti. Ni u dizajnu baze, ni u programskom kodu nema nicega sto bi garantovalo integritet podataka.(koji ionako ne pokriva sve aspekte rezervacija). Najverovatnije da je svrha pitanja bila da se pokaze kako se pisu kveriji koji pokazuju stanje soba u zadatom period I nista vise. Zato smo dozvolili nekompletan I nedovoljno pouzdan dizajn baze.

Ako mozemo da prihvatimo pretpostavke da su podaci u tabeli Rezervacije dobri, onda se moze govoriti o pisanju kverija koji prave nalog za kuhinju. Ukoliko je cilj pravljenje aplikacije/sistema koji bi radio rezervacije, registrovao goste i slao naloge u kuhinju, onda je to druga prica, nimalo jednostavna. Prica je slozena zato sto se zahteva veoma visok nivo poznavanja relacione teorije, dizajna baze i pisanja slozenih kverija (graficki interfejs ne pomaze). Ovo sve moze da se izbegne, ako ste odlican programer pa sve kontrole integriteta podataka odradite u programskom kodu. Ja ne poznajem bas mnogo tako dobrih programera, 4-5 mozda, na dva kontinenta, pa je ta opcija malo verovatna.

Dakle, ako su samo kveriji u pitanju, a tabela Rezervacije izgleda kao u zakacenom primeru, verovatno cemo moci da dodjemo do kverija. Za bilo sta dalje od kverija, forum nije mesto za tako slozene stvari.

Sta se u stvari trazi? Samo kveriji ili ceo sistem?

Postovani Zidar,
tema je dosta stara (http://www.elitesecurity.org/t...cenje-rezervacija-malom-hotelu) ali mogla bi da bude aktuelna. Slazem se sa tvojim misljenjem da je sa dosta nedostataka, ali takodje smatram da moze da posluzi kao polazna osnova i za ozbiljnije stvari, tj ozbiljniji sistem, ali za koji ovaj forum nije mesto. Zato, ne bih ovde govorio o takvom sistemu vec o konkretnom problemu.

Ono sto mene sada konkretno zanima, je to sto sam na pocetku i napisao - izrada upita na osnovu navedene tabele (iz baze koju si ti odradio zajedno sa Scelle-om i ostalima tada).

OK, napisacemo kverije. Ja ne mogu pre ponedeljka, ako neko moze ranije - izvolite

Ponavljam, zakaceni primer je dobar samo da se pokaze kako se pisu kveriji koje je Scelle trazio. Cela tema je dobra da se zapocne raditi sa datumima. Tabele traze preradu - da se dodaju neke vazne stvari. Inace ce ceo posao propasti (nema veze u nasem slucaju, posto samo zelimo da napisemo kverije).

Za pocetak daj nam pravila, na primer (samo primer, ti imas realna pravila):

1) Gost izlazi iz sobe u 11 ujutru, a novi gost ulazi u 14:00.
3) Gost na dan dolaska ima rucak i veceru.
3) Gost na dan dolaska ima samo dorucak.
4) U sve ostale dane gost ima tri obroka, ili neki aranzman po zelji

Pravila treba da mogu da se menjaju - neko uplati samo dorucak, neko dorucak i veceru, a neko nista.
Mozda bi bilo dobro da gosti imaju opciju da biraju aranzman za hranu, za dane kada su tu ceo dan.
Treba u stvari dozvoliti da svaki od vrsta dana {dan dolaska, dan odlaska , dan boravka} gost izabere raspored obroka. Ako ne izabere nista posebno, podrazumeva se raspored po pravilima 1,2,3,4

Kad nam napises pravila, mozemo da pocnemo, ili da trazimo da se pravila pojasne.

Ja nastavljam u ponedeljak, a ko moze i hoce da proba, neka pocne i ranije. Ako se nadje resenje onda ja u ponedeljak ne moram nista da radim.

Slazem se sto se tice tabela, ali one ovde mogu da posluze kao primer za izradu ovih upita.

Pravila si ispravno definisao na osnovu prvog posta, ali samo da preciziram i pojednostavim:
1) Gost izlazi iz sobe pre podne, a novi gost dolazi posle podne
2) Gost moze da bira - nocenje sa doruckom, pun pansion (dorucak, rucak i vecera) ili polupansion (dorucak i vecera).

Ako izabere pun pansion:
3) Gost na dan dolaska ima rucak i veceru.
4) Gost na dan odlaska ima samo dorucak.
5) U sve ostale dane gost ima tri obroka

Ako izabere polupansion:
3_1) Gost na dan dolaska ima veceru.
4_1) Gost na dan odlaska ima samo dorucak.
5_) U sve ostale dane gost ima dva obroka

Ako izabere nocenje sa doruckom:
3_2) Gost na dan dolaska nema nista.
4_2) Gost na dan odlaska ima samo dorucak.
5_2) U sve ostale dane gost ima samo dorucak

Ovo se odnosi na rezervaciju smestaja sa ishranom, a ako se gost odluci za neki dodatni obrok to se posebno evidentira i nije predmet ovog upita.

Dobro, sad znamo nesto vise. Hajde ovako:
1) napravi Access fajl, MDB, ne ACCDB
2) napravi jednu tabelu, na osnovu one koju si video u primeru ZauzeteSobe, sa kolonama:
Soba - oznaka sobe
DatumDolaska - ocigledno, ali cuvamo samo datumski deo, sati i minuti se ne smeju pojaviti
DatumOdlaska - isto kao i za dolazak, nema sati, nema minuta, samo datumski deo
BrojOsoba - zbog jednostavnosti, pretpostavicemo da se broj osoba ne menja tokom celog boravka
Aranzman - iz skupa {'Pansion','Polu Pansion','Nocenje sa doruckom'}

Ogranicenja na tabeli:
a) Sev kolone su "required = YES"
b) [DatumOdlaska ] > [DatumDolaska] = pretpostavka je da ce sobe biti zauzete najmanje jedan dan (ne izdajemo na sat, to bi bilo nevaspitano
c) Primary Key: (Soba, DatumDolaska )
d) Alternate Key: (Soba, DatumOdlaska)

Bilo bi lepo da se onemoguci preklapanje intervala zauzetosti soba. Za nasu svrhu pretpostavicemo da nem preklapanja intervala boravka, da je to nekako vec uspostavljeno, u bazi, ili u kodu.

3) Popuni tabelu test podacima, sa desetak redova. Pokusaj da pokrijes razne slucajeve. Na primer (spisak nije konacan!):
a) dolazak i odlazak posle jednog dana
b) odlazak, soba ostaje prazna nekoliko dana posle toga
c) jedan gost odlazi ujutru, a posle podne ulazi novi gost
d) bar jedan slucaj gde je samo jedan gost
e) bar jedan slucaj gde je vise gostiju
f) bar po jedan slucaj za svaki od aranzmana

Onda cemo da poradimo na kverijima. Dakle, na posao, napravi tabelu i popuni je korektnim podacima (nema preklapanja intervala zauzetosti, nema praznih kolona)

Evo fajla sa trazenim podacima i tabelama. Tokom rada provericemo da li je potrebna jos neka varijanta sa podacima.

Fajl prepravljen prema @Zidarevim smjernicama. Broj rezervacije nije potreban jer kombinacija Soba,DatumDolaska jednoznačno označavaju zapis i ne može se pojaviti još jedan zapis sa istim podatkom. U indeks dodat AlternateKey koji je trazen i u Table Validation Rule dodato trazeno ogranicenje.

Potpis

Sve sam fino smislio...
Još samo da propadne. :-)

Evo jedno moguce resenje. Dodao sam nekoliko sitnih tabela i ukupno 3 kverija.

Nove tabele:

1) _tblDatumNaloga - tacno jedan rekord, tu se uoisuje dan za koji zelimo da uradimo nalog za kuhinju.
2) ztblStatusiBoravka - lista status boravka na zadati dan: (Ceo Dan,Dolazak,Odlazak), izracunava se kverijem qryStanjeSobaZaNalogKuhinji. Ako se menjaju vrednosti u tabeli, onda se mora promeniti i kveri - vrednosti su hard-kodirane.
3) ztblObroci - lista obroka koje hotel nudi (Dorucak, Rucak, Vecera) Mogu se dodavati novi obroci po potrebi.
4) ztblObrociZaAranzmaneRazniSlucajevi - Pravilia za pokrivanje aranzmana obrocima - koji obrok se nudi u kom aranzmanu, za svaki statusa boravka. Mogu se dodavati nove kombinacije ako treba. Query z_qryMakeTable_ObrociZaAranzmaneRazniSlucajevi je upotrebljen da se napuni tabela. Nema potrebe da izvrsavate ovaj kveri, to je samo ilustracija kako se mgu kreirati tabele koje kombinuju razlicte paramatre.


Kveriji:

Q1) qryStanjeSobaZaNalogKuhinji = izracunava status boravka (Ceo Dan,Dolazak,Odlazak) za sobe koje na zadati dan ulaze u nalog za kuhinju.
Q2) qryObrociZaNalogKuhinji = ovde povezujemo status boravka u sobama na zadati dan sa pravilima za pokrivanje aranzmana obrocima - ztblObrociZaAranzmaneRazniSlucajevi

Q3) qryNalogKuhinji = zavrsni kveri


Mislio sam da ce biti teze ali je ispalo OK. Valjda to dolazi s godinam

Ponavljam, tabela tblRezervacije nije potpuno bezbedna. Treba obezbediti u kodu da se dve rezervacije ne mogu preklapati, osim na dan odlaska/dolaska. To uradite u kodu. Moze i u tabelama, ali je prekomplikovano za svakodnevni rad.

@Zidar, vjerovatno ste zaboravili da zakačite odrađeni primjer uz zadnju poruku

Potpis

Sve sam fino smislio...
Još samo da propadne. :-)

@Zidar, nedostaje primer uz poruku.

Budem se kasnije uključio, samo bi dao hint: Mislim da bi bilo dovoljno upisati kod prijave gosta PocetniObrok (D, R ili V) i uz to Aranzman (BB, HB, FB) i po tome se onda zna na šta i kada gost ima pravo.

Potpis

F

Primer zakacen za originalni post. Izvinjavam se za gresku. Meni je izgledalo da je upload uspeo, ali ocigledno da nije.

Bila je tema sa slicnim problemom na sajtu Icentar, nekad davno, koju nismo doveli do kraja. Cini mi se da smo se bili izgubili upravo na delu sa rezervacijama i pracenjem statusa soba. Ako neko moze da iskopa neki primer sa te teme, bilo bi korisno, jer tamo ima mnogo detalja o procesu.

Ako stignem, negde iduce sedmice pokusacu da postavim kako bi mogla da izgleda tabela za pracenje promena statusa soba. Ko prati ovaj forum pazljivo setice se da smo imali nekoliko tema o pracenju promena ovoga ili onoga. Ovo bi bilo nesto na tu temu, ali treba da se razradi tako da pokriva ove hotelske primere.

Pretražio sam ICentar forum i nema te teme. Usled promene provajdera forum se selio i pogubio neke teme.
U svojoj ličnoj evidenciji pronašao sam fajl iz 2009. godine te ga kačim u nadi da će pomoći.

Potpis

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Hvala Getsbiju veliko. Voleo bih da sam bar priblizno toliko pedantan i organizovan.

Sad kad pogledam, cela ta stara shema uopste ne valja. Tda smo rdili kako smo najbolje znali. Posto sada verovatno znam nesto bolje, prvo cemo objasniti kako treba, pa onda mozemo da komentarisemo zasto stara shema ne valja. Dajte mi samo malo vremena da se organizujem. Dotle - necemo komentarisati i pitati nista o ovoj staroj shemi.

U medjuvremenu, dobrodosla su pitanja o poslednjoj shemi koju koristiom za mich07. Malo se pozabavite tom shemom, vidite da li bas sve razumete. Veoma je uputno razumeti kako iz tabele tblRezervacije i zadatog dana odredjujemo za koga treba pripremiti koji obrok. Dobro je primetiti da mozemo da dodamo jos obroka, jos aranzmana, po volji. Moguci su i aranzmani bez i jednog obroka (cuveni dnevni odmor, ili nocenje bez dorucka ) Razmislite malo o resenju sa posebnom tabelom koja cuva dan za koji radimo nalog, umesto da se mucimo sa parametrima. Pokusajte da razjasnite kako je napravljeno da tabela koja cuva datum za koji se pravi nalog prima tacno jedan rekord. Sta bi bilo kad bi dozvolili vise rekorda? Da li bi to bilo lose ili dobro, ili zavisi od situacije. Ako ima pitanja - pitajte. Ako vidite neko drugo, jednostavnije resenje - izlozite ga. Ako imate poboljsanje za postavljeno resenje, makar i kozmeticko - obznanite ga.

Čini mi se da nešta nije dobro odrađeno ili ja ne razumijem poentu.
Ako tu naprimjer ukucam datum 13.4.2015 koji uopšte nije pokriven rezervacijama u upitu qryNalogKuhinji dobijemo da je potrebno pripremiti 9 doručaka, 9 ručaka i 10 večera. Ako ukucam 15.1.2015 kada u sobi broj 1 ima samo jedan gost( koji tog dana odlazi i može imati samo doručak ) dobijem u upitu opet 9,9,9 .
??? Slike u prilogu

Potpis

Sve sam fino smislio...
Još samo da propadne. :-)

Svaka cast za primedbu, zahvaljujem.

Izvinjavam se, nije bilo namerno, ali se sada vidi vrednost timskog rada. Neko proizvodi greske, a neko ih pronalazi Sad bar vidimo ko detaljno proucava postove. Srecom, nije nists strasno. U kveriju qryStanjeSobaZaNalogKuhinji, stoji OR umesto AND u WHERE uslovu

Moze i na slici da se vidi kako treba:

SVAKA CAST ZIDAR!!!

Mislim da je to ono sto sam trazio.
Ostaje samo da se uradi mala ispravka u tabeli ztblObrociZaAranzmaneRazniSlucajevi, a to je da se za polupansion cekira dorucak i vecera (jer je to usluga PP), umesto rucak i vecera i sve funkcionise kako treba!

No kad smo vec kod te teme, kako bi moglo da se iskombinuje, na osnovu ovih podataka, da se napravi kveri - nalog sobaricama.
Radi se o sledecem zahtevu:
1) postoji GC - generalno ciscenje i DC - dnevno ciscenje.
2) GC - se izvodi kada gost napusta sobu (znaci na datum odjavljivanja), a DC - tokom boravka gosta (ne ukljucuje datum prijavljivanja i datum odjavljivanja).

@mich07: pogledaj kveri qryStanjeSobaZaNalogKuhinji. Tamo lepo pise svaki 'odlazak' (napustanje sobe) i svaki 'ceo dan' (celodnevni boravak gosta).

To ti se zove dva za jedan :-p