Pomoć oko izbora baze i načina pristupa

Hajde sada da se pozabavimo samo ovim:

Mogao sam da napravim tabele tblNasaFirma i tblNasiZaposleni i tblKlijenti i tblZaposleni ona ne bi bilo problema o kojem govoriš. No (moja) poenta je da je struktura osnovnih podataka (tj. polja) o našoj firmi i firmama sa kojima radimo -- ista, što važi i za zaposlene. Zato ti se možda čini da idemo u krug.

(I)
Svaka firma, pa i naša, ima više zaposlenih (1-n).
Jedan od naših zaposlenih otvara unose za nove firme (1-n).
Jedan od naših zaposlenih je project manager u više firmi (1-n), dok firma s kojom radimo može imati jednog našeg project managera.
(*) na ovom mestu si uputio primedbu i rekao da to nije dobro. I da zaposleni ne može da postoji bez firme. Ovo je nešto između klasičnog ER modela (čiji je problem veliki broj tabela sa sličnim/istim poljima) i objektnog modela. Zato se čini da ide u krug.

Možemo li da modeliramo samo ove tabele: tblFirme i tblZaposleni?


(II)
Naša firma je "prodavac", zaposleni u našoj firmi su "prodavci" a druge firme su "firme kupci" ili "firme klijenti", pa su njihovi zaposleni "kupci" ("klijenti") - sinonimi, koristio sam reč "klijent". Mi prodajemo, klijenti kupuju.

Kalendar kontakta, Dnevnik dontakata, Delovodna knjiga (kako god da se zove - sinonimi) zamišljena je da se beleže sve interakcije prodavca i kupca (data je simplifikovana verzija).
U toj tabeli će se ponavljati naši prodavci, kao i naši klijenti, dok je svaki prodavac zaposlen u jednoj firmi (našoj) a svaki klijent radi za jednu firmu (n-1).

Gledam u tabelu koju sam napravio i meni je sasvim jasna. Naravno da možda nije tačna ili dobra, i ti/vi ćete mi na to skrenuti pažnju. Ako smo uspešno modelirali pod (I), možemo li da napravimo primer modela kako bi trebalo da izgleda (I) + (II)?


(III)

Radim u firmi. Naša firma ima svoje zaposlene, među kojima sam i ja.
Prodajemo usluge.
Zaposleni u našoj firmi su sekretarica, prodavci i product manageri, treneri, supervizori, itd.
Prodavac može da bude i product manager (kasnije) za tu firmu klijenta (kupca), ili samo inicijalno da ugovori posao.
Takođe, taj isti prodavac može da bude i product manager (ista osoba je u pitanju) za neku firmu klijenta i da u njoj vrši jednu vrstu treninga, a i da u drugoj firmi (klijentu) da vrši drugu vrstu treninga (nad nekim drugim zaposlenima).
(*) Ovo je deo koji sam u ER-modelu iznostavio, Projekti-Usluge (gde spadaju, npr. treninzi), što sam sad letimično spomenuo.

Naši prodavci kontakturaju firme i njihove zaposlene nude im svoju uslugu, tako što prolaze kroz seriju susreta sa raznim zaposlednima tokom vremena (Kalendar Kontakata).
(*) "Susret" je zavravo "vrsta kontakta" koja može biti: telefonon, email, SMS, prezetacija, sastanak 1:1, grupni sastanak, dopis, itd.

Sve vreme dok ne zaključi posao on je prodavac i ništa više od toga. Nakon toga, prodavac (ili neko drugi iz naše firme) za klijenta drži treninge i prodavac (ili neko drugi) može da postane project manager za tu firmu (klijenta) ili supervizor, itd.

* * *

Nisam bukvalno odgovorio na svako pitanje, ali imaš daleko više uvida sada u to šta radimo. Izostavio sam ceo modul sa psihološkim testovima (o kojima sam pisao na početku teme), jer su oni tek deo Projekti-Usluge šeme koju sam sad prvi put uveo u priču.

Naših zaposlenih biće 20-ak, a naših klijentata 50-ak (u bazi), a njihovih zaposlenih 50-ak * 100-ak. To je srednji okvir baze. Hoću da kažem da nije obimna i ne sadrži veliki broj transakcija i samo je za internu upotebu (do dela sa testovima, ali taj most ćemo preći kad stignemo do njega).

Za početak bio bih srećan kad bih dobio dobro modelovan ER-model na osnovu datih podataka (modifikaciju mog modela). Onda bih sa tom osnovom, mogao da se igram s alatima, a to je već priča za sledeći post. :)

Zidar, veliko hvala na šarmu, duhovitosti, surovoj realnosti i vremenu. Saveti koji dobijam od tebe su objašnjenja za kojima tragam, šliht, šliht :)

Dobro, ovako je bolje.

Da se razumemo nesto pre nego sto pocnemo:


Kazes "struktura osnovnih podataka (tj. polja) o našoj firmi i firmama sa kojima radimo -- ista, što važi i za zaposlene. Zato ti se možda čini da idemo u krug."
A: Podaci o firmi u kojoj ti radis nisu bitni za bazu podataka. Prema tome, to sto je struktura ista, nema veze.

Kazes "I da zaposleni ne može da postoji bez firme. Ovo je nešto između klasičnog ER modela (čiji je problem veliki broj tabela sa sličnim/istim poljima) i objektnog modela. Zato se čini da ide u krug."
A: ne cini se meni d aidemo u krug nego struktura ne valja. A ne valaj jer pokusavas da koristis "nešto između klasičnog ER modela (čiji je problem veliki broj tabela sa sličnim/istim poljima) i objektnog modela. '. dakle, ti si namerio da popravis osobine klasicnog ER modela, tako sto ces ga ukombinovati sa objektnim modelom. Zasto/ Da bi manje kucao kad kreirs tabele? Batali. Na ovom forumu akd kazemo model baze podataka mi mislim na relacioni model i sve relaciono. Objektna teorija moze da se primeni na programiranje, ali to je kasnije, bne u ovoj fazi. Ako radis sa mnon, zaboravi na objektni model, to ne postoji, tacka. Ne shvati me krivo, nista ne fali objektnom modelu ali kad se nevesto kombinuje sa relacionim ne bude dobro.

Dobro je sto si dao opis procesa. Nije dobro sto trcis pred rudu i iodmah gledas u nekakve odnose 1:vise i slicno. Batali to, doci ce vreme za to, ali ne sada. Evo ja cu da svojim recima ispricam ono sta viradite, na osnovu onog sto si napisao:



Nas cilj je da se ova price prevede u skup tabela u nekoj relacionoj bazi podataka. Ima raznih metoda da se to psotigne. ER modeliranje je jedan nacin, ali samo jedan nacin, nekompletan, ali moze da dovede blizu cilja. Kad stignemo blizu cilja, onda proverimo da li nas skup tabela zadovoljava uslove normalizacije. Ako zadovoljava, tu smo - imamo model baze podataka.

Kako se modeluje ER dijagram, na parcetu papira, bez softwerskih paketa? Pogledas opis procesa. Recenice predstavljaju relacije (odnose) izmedju nekih entiteta. Entiteti su imenice u recenicama, dakle subjekti i objekti. Relacije su glagoli i glagolski prilozi, dakle predikati i prilozi koji ih odredjuju. Prvo sta treba uraditi jeste oznaciti sve imenice u recenicama koje opisuju proces. To su nasi entiteti i mozemo da im damo imena i bacimo na papir. Intuicijom znamo koji atributi se mogu dodeliti kom antitetu, pa mozemo i to da uradimo na istom papiru (popunimo kucice u kutijama koje predstavljaju entitete). Jos ne spominjemo nikakve ID, PK, FK i slicno. To dolazi malo kasnije.

U tvom slucaju ovo bi bili entiteti:
- Firme koje kontaktiraet (potencijalni kupci)
- Vasi zaposleni
- Ostvareni kontakti
- Utanaceni poslovi (Projekti)
- projekt manageri

Za deo koji jis opisao entiteti bi bili:
- Ankete
- Pitanja koja cine anketu
- ponudjeni odgovori na pitanja
- ispitanici
- odgovori koje su ispitanici dali
Ovo mora da se razmatra sada, ne mnogo detaljno, ali da se zna da postoji. ne moze se raditi analiza sistema na parce. Necemo cekati da nam dodje taj most, palniravcemo ga sada. I arhitekte kad crtaju kucu, crtaju i krov i temelje. Krov se ne resava tek kad za njega dodje vreme. Opis vaseg posla u jednoj recenici je "Moja firma prodaje psihometrijska ispitivanja" Kako cemo da izbacimo iz analize osnovnu stvar koju vi radite? Kontaktiranje klijenata i evidancija kontakta, proejct manageri, to je sva samo mehanizam (jedan od vise mogucih) koji dovodi do glavnog cilja - psihometrijskog ispitivanja. Pojam sustine procesa i mehanizme mozes da nadjes u kjigama o ORACLE CASE Stuies - to ti je ORACLE zvanicna metodologija za analizu. Ali moze da se primeni i na MS Access i MS SQL Sever podjednako dobro.

Sta ti sad treba da uradis? Ovo sto sam naveo ako entitete, da pretvoris u tabele. nemoj da ih trpas zajedno, nek bude kako sam naveo, osim ako sam nesto debelo promasio. U tom slucaju prvo pitaj, pa tek onda menjaj. Ne trebaju ti u ovom momentu nikakvi ID, autonumberi, kljucevi, nista. Hocu da vidim tabele, samo one koje mozemo napraviti od imenica.

U sledecm koraku cemo da vidimo u kakvoj su vezi (relciji) ti entiteti. Mozes da koristis i rec 'objekti' umesto entiteti, neko kaze model objekti veze (MOV) a neko 'entiety relationship diagram' (ER diagram), to ti je isto. Pazi, to nisu bas 100% objekti kako ih definise objektna teorija, tako da necemo da mesamo objektnu teoriju u ovo, da se ne zapetljamo bez veze.

Ti si na potezu. Daj tabele. To je pocetak RAD metoda. Prvo temelj, pa cemo dalje.





<sub>[Ovu poruku je menjao misk0 dana 02.06.2009. u 21:13 GMT+1]

[Ovu poruku je menjao misk0 dana 02.06.2009. u 21:13 GMT+1]</sub>