Prikazi cijelu temu 28.08.2010 21:04
Getsbi Van mreze
Moderator
Registrovan od:04.02.2009
Lokacija:Vršac


Predmet:Re: Update podataka
Kad je u pitanju ULAZ-IZLAZ, mogao bih se složiti sa iznetim mišljenjem. Razlog je, da je to u stvari neki promet robe ili novca, te se stavljanje na lager i oduzimanje, kao i dotok na račun i odliv sa račana dešava u okviru jednog magacina ili jednog računa.
Treba obratiti pažnju na deo modelovanja koji se zove logički ili konceptualni. Radi se o tome da se pre nego se pristupi pravljenju tabela, kolona, vrsta i relacija, valja posvetiti logičkom projektovanju baze podataka na nivou entiteta, atributa, torki i veza.
Najčešće je loša praksa zanemarivanje takozvanog informacionog modelovanja i izbegavanje pravljenja takvog modela. Uz korišćenje nekog od alata ili makar samo na papru postiže se da se ceo poslovni problem razmotri, razloži, proanalizira i grafičko-tekstualno prikaže.
Tu dolazimo do toga da u većini poslovnih problema nećete osoblje, goste, komintente i dobavljače držati u jednoj tabeli ili eventualno dve. Razlog su poslovna pravila koja će vas na to naterati. Gosti mogu da konzumiraju uslugu i za nju plaćaju. Treba ih izdvojiti i vezati za entitet "Evidencija pruženih usluga", kao konzumenta. Dobavljači i komintetnti (poslovni partneri ili ma šat god to značilo) ne bi trebalo da su u vezi sa prethodno pomenutim entitetom, kao što gosti ne treba da budu u vezi sa entitetom "Evidencija nabavljene i utršene robe".
Osoblje treba da bude poseban entitet jer ima specifičnu funkciju u poslovanju. Na taj način neće vam se dogoditi da se neko od osblja zaduži za noćenje u hotelskoj sobi niti da vam gost nabavi dimljenu pršutu. Neće vam se dogoditi da dobavljač menja peškire u sobi 302 ili da poslovni partner bude odgovoran za prebukiranu sobu.
Drugo, samo dobavljače i komintente možemo podeliti na pravna i fizička lica. Za goste i osoblje to nije moguće.
Dakle, smatram da ****lje na početku razmotriri funkcionalsnost osobe u odnosu na poslovni problem i ne opteretiti jedan entitet sa suviše poslovnih pravila, iz kojih se kasnije teško možemo izvući bez dodatnog kodiranja. SQL iskazi su mnogo jednostavniji i manje zahtevni.
I da ponovim još jednom, važno je dobro promisliti o poslovnom problemu koji obrađujemo i crtati ga na papru ili elektronski. Nema apsolutnih pravila. Započeću sutra jednu temu oko informacionog modelovanja, normalnih formi i načina realizacije istih u Access-u.
Ovaj post je ureden 4 puta. Posljednja izmjena 28.08.2010 21:13 od strane Getsbi.