[ mika @ 14.03.2005. 13:46 ] @
Zdravo svima.

Predamnom se postavio jedan zanimljiv problem: potrebno je da napravim bazu preduzeća, i relaciju fakturisanja između preduzeća.

Dakle, postoji jedna tabela, pojednostavljeno:

Code:

+-----------+
|Preduzeca  |
+-----------+
|IdPreduzeca|
|Naziv      |
+-----------+


I potrebno je da se napravi ovakva relacija (strelice prikazuju relaciju "fakturiše"):



Kao što se vidi sa slike, svako preduzeće može svakome da fakturiše, i to jedno preduzeće može da fakturiše više preduzeća, a i tom jednom preduzeću mogu da fakturišu više preduzeća. Dakle, mreža je u pitanju (dobro, nije to standardan naziv, ja ga tako zovem).

Kontam da je u pitanju veza tabele same sa sobom, ali me buni ta relacija "više prema više", pa sam odlučio da napravim tabelu "Fakturisanja" koja izgleda ovako:

Code:
+------------+
|Fakturisanja|
+------------+
|IdFakturise |
|IdPreduzeca |
+------------+


... dakle, prikazuje koje preduzeće fakturiše kome. Primarni ključ je složeni, sastoji se od kombinacije ova dva.

Moje pitanje: da li je ovo OK, tj. da li je moglo optimalnije da se napravi baza? Napominjem da još uvek nisam završio sve, pa zato i pitam.

10x!
[ jablan @ 14.03.2005. 14:38 ] @
Sve je OK sem primarnog ključa. Koliko kapiram, tabela fakturisanja ustvari drži fakture, ne? Ako je tako, onda treba i tako da se zove (fakture, a ne fakturisanja). Možda deluje cepidlački, ali pravilno razumevanje i rešavanje problema počinje dobrim imenovanjem činilaca. Ako je u pitanju tabela faktura, primarni ključ treba da bude novo polje FakturaID.

S druge strane, ako tabela fakturisanja ustvari ne drži fakture, već uređene parove preduzeća koja jedna drugima mogu da fakturišu, onda su i ime tabele i primarni ključ koji si ti predložio u redu.
[ mika @ 14.03.2005. 15:11 ] @
Tabela "fakturisanja" sadrži samo parove preduzeća, dakle ne i fakture, i izgleda baš tako kako je nacrtano (ima samo dva polja). Tabela "preduzeća" je namerno uprošćena-u bazi ta tabela ima preko 30 polja ali to je irelevantno za problem.

Dakle, dobro je koncept napravljen? Zadovoljan sam.
[ CandyMan @ 15.03.2005. 15:09 ] @
Nisam baš siguran da će ovo što si napisao da drži vodu...

U fakturi se preduzeće javlja u dva pojma: prodavac i kupac. Pretpostavljam da je cilj da se ograniči koje preduzeće kojem može da fakturiše. Da bi se ovo realizovalo potrebno je definisati još jednu tabelu npr. RELACIJA koja će imati polja PREDUZECE_PRODAVAC i PREDUZECE_KUPAC koje će svako za sebe biti spoljni ključ iz tabele PREDUZEĆE. Zajedno će ta dva polja činiti primarni ključ za tabelu RELACIJA.
E, sad, pri formiranju fakture, kada se odredi prodavac, na osnovu podataka iz tabele RELACIJA se sužava spisak kupaca za zadatog prodavca.
Mislim da nije dobro stavljati bilo kakva ograničenja na nivou tabela ili aplikacije da bi se omogućile izmene opisanih odnosa kupac/prodavac u budućnosti.

Nadam se da sam shvatio šta je pisac hteo da kaže.

[ mika @ 15.03.2005. 15:24 ] @
Pa upravo to sam i uradio, znači doslovce kako si ti napisao, samo što ti možda iz konteksta mojih odgovora nisi skontao. Dakle, jedino što nisam stavio takva imena polja i tabela, ali je rešenje identično.

10x!