Pomoć - IS menze

[dusandevic]

Pravim kao projekat za ispit informacioni sistem studentskog restorana. DBMS je MySQL, baza je distribuirana i koristim PHP.

U bazi koristim nekoliko tabela: studenti, fakulteti, jelovnik, potrošnja i uplata. E sad, zapeo sam kod sledećeg: potrebno je da se obavi realizacija obroka. Student ima neki novac na svom računu i pri tom bira jelo sa jelovnika, koje ima svoju cenu. Kada on odabere obrok (potrošnja), sistem treba da zaduži njegov račun za cenu obroka.

Takođe, ne znam na koji način da realizujem uplatu na račun, tj. da se uplaćen iznos doda iznosu koji već postoji na računu. Da li je bolje da postoji zasebna tabela (entitet) RAČUN, ili da ga vodim samo kao atribut u tabeli STUDENTI?

Problem je što poznajem samo osnovnu sintaksu SQL-a. Pretpostavljam da će se problem rešiti nekako preko komande UPDATE, ali ne znam tačno kako i molim vas za pomoć!

[dusandevic]

Rešio sam problem sa dodavanjem sredstava na račun.
Ukoliko nekom ikada bude trebalo, radi se update, i to:
$updateSQL = sprintf("UPDATE tab_racun SET RACUN_STANJE = (RACUN_STANJE + %s) WHERE STUD_ID=%s"

A i ovo što je ostalo rešavam uskoro...

[holodoc]

Evo par saveta

Kao prvo da bi očuvao integritet svojih podataka prvo i osnovno pravilo dobrog dizajna relacionih baza podataka je da u bazu nikada ne skladištiš rezultate obrade podataka već same podatke kako bi kasnije izbegao neke ozbiljne probleme koji mogu da se jave recimo ako dođeš na ideju da proširuješ sistem ili poželiš da se baciš na ozbiljniju optimizaciju relacija putem normalizacije.

Dakle, da pređem na konkretnu stvar. Svaki student ima po jedan račun i svaki račun je vezan za jednog studenta nezavisno od toga kom fakultetu pripada. Ovo te automatski navodi na to da je u bazu potrebno da ubaciš relaciju racuni u okviru koje bi pamtio svako zaduživanje vlasnika računa odnosno dodavanje novca na račun. Primarni ključ relacije bi trebao da bude prost i veštački tj. autoinkrementirajući broj dok bi preostali bitni argumenti trebali da budu vidljivi u sledećoj relaciji.

idRacuna, idStudenta, iznos, tip, datum

    CREATE  TABLE `racuni` ( `idRacuna` INT NOT  NULL  AUTO_INCREMENT ,
 `idStudenta` INT NOT  NULL ,
 `iznos` INT NOT  NULL ,
 `tip` ENUM(  'uplata',  'zaduzenje'  )  NOT  NULL ,
 `datum` DATETIME NOT  NULL ,
 PRIMARY  KEY (  `idRacuna`  ) 
) ENGINE  = InnoDB

Iznos bi trebalo da sadrži vrednost koja se dodaje ili oduzima, tip bi bilo polje tipa enumerisanih vrednosti (ENUM) koje može da ima jednu od dve vrednosti ('uplata', 'zaduzenje') a datum je jasan sam po sebi.

Kako bi koristio ovu tabelu? Pa jednostavno. Svaki put kada student uplati neki iznos dodaš novi unos u tabelu.

INSERT INTO racuni (idRacuna, idStudenta, iznos, tip, datum) VALUES (NULL, ODGOVARAJUCI_ID_STUDENTA, IZNOS, 'uplata', NOW())

Svaki put kada student zaduži svoj račun takođe dodaš novi unos.

INSERT INTO racuni (idRacuna, idStudenta, iznos, tip, datum) VALUES (NULL, ODGOVARAJUCI_ID_STUDENTA, IZNOS, 'zaduzenje', NOW())

Kako da znaš kakvo je trenutno "stanje" studenta? Jednostavno

SELECT tip, SUM(iznos) FROM racuni WHERE idStudenta = 1 GROUP BY tip

Dobićeš rezultat upita koji se sastoji od dva rezutujuća reda sa po dva polja, nešto sledećeg tipa.

uplata      1500
zaduzenje 1000

Sa takvim rezultatom možeš u PHP-u jednostavno da nađeš razliku vrednosti za oba rezultata i da jednostavno vrednost iznosa za zaduzenje oduzmeš od uplata

PHP kod:

<?php
$idStudenta = 1;
$sql = "SELECT tip, SUM(iznos)FROM racuni WHERE idStudenta = ".(int)$idStudenta." GROUP BY tip" ;
$result = mysql_query($sql) or die("Nece ti nesto ovaj upit bato :)");
if(mysql_num_rows($result)){
    while($record = mysql_fetch_assoc($result)){
            switch($record['tip']){
                case 'zaduzenje':
                    $zaduzenje = $record['iznos'];
                    break;
                case 'uplata' :
                    $uplata = $record['iznos'];
                    break;
            }
    }
} else {
    die("E nece da moze jer nema ama bas nikakijih rezultata za tvoj upit!");
}
echo "Traženo stanje za studenta iznosi ".$uplata-$zaduzenje." dinara!"
?>

Preterah opet jel da?

Elem, @dusandevic, volim kada se neko zaista trudi da odradi stvari samostalno i tada takvim ljudima pružam maksimalnu pomoć tako da ako bilo gde ponovo zapneš slobodno pitaj a nadam se da ti je ovo što sam istrtljao do sada bilo bar malo od pomoći

[dusandevic]

Okačiću ovde ER dijagram iz PowerDesigner-a, ali trenutno nemam na ovom kompu.

Ja sam to predvideo da ide u dve tabele, uplata u jednu a potrošnja u drugu, ali to nije nužno. Može i ovako kako predlažeš.

Staviću ja to i na neki server pa da vidite kako funkcioniše.

[holodoc]

Ne znam da li na faksu imate obavezu da koristite nešto od softvera za dizajn relacionih baza tipa ERWin i sl. ali svakako jedno od jako kvalitetnih savremenih rešenja sa istom namerom je MySQL Workbench Tačno je da se aplikacija prevashodno orijentiše na MySQL ali putem ODBC-a kompletan model možeš puterm "Forward engineer" opcije da prebaciš u bilo koji RDBMS Ne treba da spominjem naravno da su dostupne i sve važnije notacije za ERmodel tipa IDEF1X, "crows foot" itd.

Evo malo više o programu ovde s tim što je to malo stariji tekst a novje verzije imaju sve opcije dostupne koje u vreme te recenzije nisu bile dostupne

http://www.sk.rs/2008/11/skpd03.html

[dusandevic]

Znam, koristio sam "Radnu klupu"
Nemamo obavezu da koristimo CASE alate, ali je poželjno...

[dusandevic]

Evo i obećanog dijagrama. Prokomentarisao sam i kardinalitete, nadam se da je sve ok. PowerDesigner prilikom provere modela nije primetio nijednu grešku.

[dusandevic]

A evo i fizičkog modela koji PDesigner napravi.

Ovde imam par zamerki:

• u tabeli student neću posebno da pratim stud_id i racun_id, jer su to potpuno isti podaci (veza sa računom je 1 na 1)
• u tabeli racun neću da pratim fax_id studenta, dovoljan mi je jedinstveni stud_id
  
• u tabelama uplata, odnosno potrosnja takođe me ne zanima sa kog fakulteta je student koji uplaćuje novac, odnosno jede hranu
• u tabeli uplata polje uplata_id za moj pojam treba da bude primarni ključ, a ostali atributi (osim datuma, naravno) su strani ključevi

Zato sam posle potpuno eliminisao entitet, odnosno tabelu uplata. Jednostavno, prilikom uplaćivanja izvršim UPDATE polja na računu na način koji sam ranije opisao, i to radi savršeno. Znači, zamislite model bez tabele uplata i veza sa njom.

Mora li da postoji direktna veza između jelovnika i računa, zbog poslednje i suštinske stvari koju još nisam rešio: kada student jede, skine mu se sa računa cena obroka iz jelovnika?

Bilo bi mi interesantno da ubacim i neka ograničenja. Na primer:

• student može uplatiti najviše "NEKA SUMA" sredstava u toku jednog meseca na račun.
• Račun može biti u minusu najviše 100 dinara.

Pretpostavljam da to rešavaju triggeri, ali ovo nije neophodno.

Kao što sam i obećao, ceo projekat je dostupan online na www.mksirmium.com/menza/default.php (zašto neće automatski da pokrene tu stranu kada dođem u /menza). Podaci za pristup su user: dusan i pass: dusan. Slobodno malo eksperimentišite...

[holodoc]

Pošto sam trenutno u gužvi prokomentarisaću za sada samo da glavnu stranicu preimenuješ iz default.php u index.php ili ako imaš pristup httpd.conf fajlu svog servera da potražiš liniju sa DirectoryIndex direktivom i i na kraju joj dodaš default.php. Recimo da izgleda kao recimo sledeći red

DirectoryIndex index.php index.html index.htm default.php