[es] - poslovni dokumenti sa slicnim osobinama - kako predstaviti najednostavnijinacin

momsab
Momčilo
Beograd, R.Srbija

Član broj: 2804
Poruke: 3041
*.dynamic.sbb.co.yu.

Jabber: pitati@PP
Sajt: www.momsab.com

+1 Profil

poslovni dokumenti sa slicnim osobinama - kako predstaviti na"jednostavniji"nacin

^{15.02.2007. u 22:41 - pre 209 meseci}

Radimo projekat iz jednog predmeta na faxu. Uradili smo veci deo posla ali ja imam neke nedoumice pa bih jedan deo posla da se uradi ponovo, ovog puta dosta preglednije, tj. jasnije/jednostavnije.

U pitanju je firma koja se bavi veleprodajom odredjenih proizvoda. I kupci i dobavljaci su poslovni partneri (pravna lica) tako da postoji jedan objekat PoslovniPartner, posto moze da se desi da kupac u nekom trenutku bude dobavljac i obrnuto.

Citat:

Od dobavljaca se dobijaju sledeca dokumenta: Ponuda, Otpremnica, OdobrenjeZaUmanjenje.
Dobavljacu se salju: Porudzbina, Reklamacija.
Kupac salje: Porudzbina, Reklamacija.
A kupcu: Otpremnica, Povratnica, OdobrenjeZaUmanjenje.

Svi ovi objekti (dokumenti) su povezani sa objektom PoslovniPartner i svi imaju, kao slab objekat, stavku koja je povezana sa objektom Proizvod. Neki dokumenti su u vezi sa drugim dokumentima:

Citat:

PorudzbinaDobavljaca sa Ponudom,
OtpremnicaDobavljaca sa PorudzbinomDobavljacu,
ReklamacijaDobavljacu sa OtpremnicomDobavljaca,
OdobrenjeZaUmanjenjeDobavljaca sa ReklamacijomDobavljaca,
OtpremnicaKupcu sa PorudzbinomKupca,
ReklamacijaKupca sa OtpremnicomKupcu,
OdobrenjeZaUmanjenjeKupcu sa ReklamacijomKupcu.

_{(ne obracajte paznju na moguci nedostatak nekih dokumenata - tako su nam rekli u firmi da ide, s druge strane nisam bio kada su pricali za reklamacije itd)}

Slede atributi (kljucevi su podvuceni) - PoslovniPartner, Proizvod, Ugovor nisu dati sa atributima zato sto nema potrebe:

Citat:

Ponuda (PonudaID, PPid, DatumPonude, VremePlacanja, StatusPonude)
StavkaPonuda (PonudaID, RedniBrojStavkaPonuda, PPid, ProizvodID, KolicinaStavkaPonuda,CenaStavkaPonuda)

PorudžbinaDobavljac (PorudzbinaDobID, DatumPorudzbinaDob, PPid, PonudaID, UgovorID)
StavkaPorudžbinaDobavljac (PorudzbinaDobID, RedniBrojStavkaPorudzbinaDob, KolicinaStavkaPorudzbinaDob, ProizvodID)

OtpremnicaDobavljac (OtpremnicaDobID, PPid, StatusOtpremnicaDob, BrojOtpremnicaDob, DatumOtpremnicaDob, DatumPrometaOtpremnicaDob,PorudzbinaDobID)
StavkaOtpremnicaDobavljac (RedniBrojStavkaOtpremnicaDob, OtpremnicaDobID, PPid, CenaStavkaOtpremnicaDob, PDV, KolicinaStavkaOtpremnicaDob, ProizvodID)

ReklamacijaDobavljac (ReklamacijaDobID, DatumReklamacijaDob, OtpremnicaDobID, PPid)
StavkaReklamacijaDobavljac (ReklamacijaDobID,RedniBrojStavkaReklamacijaDob, KolicinaStavkaReklamacijaDob, ProizvodID, )

OdobrenjeneZaUmanjenjeDobavljac (OdobrenjeDobID, PPid, DatumOdobrenjeDob, UkupnoUmanjenjeOdobrenjeDob, ReklamacijaDobID)
StavkaOdobrenjeZaUmanjenjeDobavljac (OdobrenjeDobID, PPid, RedniBrojStavkaOdobrenjeDob, CenaStavkaOdobrenjeDob, KolicinaStavkaOdobrenjeDob, ProizvodID)

PorudžbinaKupac (PPid, PorudzbinaKupacID, DatumPorKup, MestoID, UgovorID)
StavkaPorudžbinaKupac (PorudzbinaKupacID, PPid, RedniBrojStavkaPorKup, KolicinaStavkaPorKup, ProizvodID)

OtpremnicaKupac (OtpremnicaKupacID, OverenoOtpKup, BrojOtpKup, DatumOtpKup, DatumPrometaOtpKup, PorudzbinaKupacID, PPid, MestoID)
StavkaOtpremnicaKupac (RedniBrojStavkaOtpKup, OtpremnicaKupacID, CenaStavkaOtpKup, PDV, KolicinaStavkaOtpKup, ProizvodID)

ReklamacijaKupac (ReklamacijaKupacID, PPid, DatumReklamacijaKupac, OtpremnicaKupID, MestoID)
StavkaReklamacijaKupac (ReklamacijaKupacID,RedniBrojStavkaReklamacijaKupac, PPid, KolicinaStavkaReklamacijaKupac, ProizvodID)

OdobrenjeneZaUmanjenjeKupac (OdobrenjeKupacID, DatumOdobrenjeKupac, UkupnoUmanjenjeOdobrenjeKupac, ReklamacijaKupacID, PPid, MestoID)
StavkaOdobrenjeZaUmanjenjeKupac (OdobrenjeKupacID, RedniBrojStavkaOdobrenjeKupac, CenaStavkaOdobrenjeKupac, KolicinaStavkaOdobrenjeKupac, ProizvodID)

Vidi se da objekti (dokumenti) koji stizu od poslovnih partnera imaju slozen kljuc - ID dokumenta i ID PoslovnogPartnera. Uobicajeno, stavke imaju slozen kljuc: RedniBroj i kljuc nadredjenog im objekta (da se tako izrazim).

E, da pocnem sa onim sto me muci :) Odradio sam IDEF1X model ovij objekata i stvarno je bilo cimanje to odraditi. Drugar mi rece da se svi ovi silni objekti mogu predstaviti samo preko tri objekta: DOKUMENT koji je u vezi sa PoslovnimPartnerom , sa samim sobom i sa TIPOM DOKUMENTA (drugi objekat) i STAVKA koja je u vezi sa Proizvodom.
Primetio sam da se tako radi gledajuci neke primere na ovom sajtu, konkretno ovaj, ovaj, ovaj, ovaj (Father of all Data Models), ovaj (Reference Data Manager), ovaj i ovaj primer. Ovaj, sta sam hteo reci... Da, ne kontam kako da to primenim na primer koji sam dao.

Mislim da bi trebalo napraviti 6 objekta: DOKUMENT_OD (koji ima slozen kljuc IDdok i PPid), TIP_DOK_OD, STAVKA_DOK_OD i DOKUMENT_ZA, TIP_DOK_ZA, STAVKA_DOK_ZA. Ono sto mene buni jeste TIP_DOKUMENTA (REference u nekim primerima na sajtu). U njemu bi trebalo da stoji sta je u pitanju (otpremnica, reklamacija...) al mi nije jasno kako da se podesi da se ne povezuju dokumenti koji ne bi trebalo da se povezuju (iako su indirektno u vezi) kao i za neke tipove mora u stavkama da stoji cena (otpremnice).
Nesto mi govori da se ovo ipak moze predstaviti preko samo tri objekta, kao sto mi je drugar rekao, al' ja ne vidim kako da predstavim u tipu dokumenta da neki objekti (dokumenti) imaju slozen kljuc.

Eto, mene muci lakse "predstavljanje" svega ovoga. Cini mi se da je nacin preko 3 objekta bolji i sa stanovista pisanja aplikacija. Nadam se da ce neko uspesti da mi sredi ove nedoumice. Valjda sam dobro izlozio problem, kucao sam sat vremena (dok sam kopirao i prepravljao liste atributa istovremeno sam ispravljao neke greske u radu koje nisam primetio ranije - pogubim se u ovoliko dokumenata). Izvinjavam se sto nisam okacio dijagrame za date objtekte (tabele, je'lte), to bi vec bilo preterivanje. Takodje, samo da naglasim da cu napisati i kardinalnost veza ako je potrebno (mada se moze i iz opisa veza na pocetku pretpostaviti kardinalnost). Ako sam napravio nege greske u kucanju ili opisu veza ili atributima izvinajvam se, pogubih se nacisto.
Trazio sam slicnu temu (kljucne reci stavka, stavke, refer, referentni) i nisam nasao :(

Žena u krevetu i vino na stolu nikako ne smeju da čekaju. Jer, vino se greje a žena hladi.

-vinolog

Odgovor na temu

dragancesu
subotica

Član broj: 38340
Poruke: 2189
*.eunet.yu.

+73 Profil

Re: poslovni dokumenti sa slicnim osobinama - kako predstaviti na"jednostavniji"nacin

^{17.02.2007. u 15:35 - pre 209 meseci}

Teoretski bi ovo moglo da se odradi sa samo nekoliko tabela, samo je pitanje koliko je to prakticno.

Tabele podelis u dve grupe maticni i prometni podaci.

Jasno ti je da su maticni podaci sifarnici: dokumenata, poslovnih partnera, proizvoda i slicno.

Prometni podaci bi mogli da se stave u jednu tabelu a kljuc bi bio dokument i broj. A kad pravis aplikaciju za svaki dokument napravis posebnu formu i popunjavas samo potrebna polja.

Ovu prometnu tabelu bi poceo sa dokument, broj, partner, proizvod, pa teras sa poljima koja ce ti trebati redom u nekom dokumentu...

Prakticno promet obicno ide u dve tabele: nalog i stavke. U prvom su opsti podaci: dokument, broj, partner, datum nastanka, osnov, neki opis,... U drugoj tabeli su dokument i broj, pa proizvod, cena, kolicina ulaza, kolicina izlaza, ... Neko bi za ovo rekao model Master-Detail ako ti je lakse.

Pomozite Micro$oftu u borbi protiv piraterije, poklonite prijatelju Linux

Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.suonline.net.

Sajt: www.baze-podataka.net

+4 Profil

Re: poslovni dokumenti sa slicnim osobinama - kako predstaviti na"jednostavniji"nacin

^{19.02.2007. u 10:03 - pre 209 meseci}

Ja sam protiv model sa tri entiteta (Tipovi_Dokumenata, Dokumenti i Stavke) iz nekoliko razloga.

1.

Entiteti Dokumenti i Stavke bi imali puno atributa cije vrednosti mogu biti NULL. Puno ovakvi atributa je meni uvek alarm da model podataka nije dobar.

2.

Predpostavljam da u originalnom modelu vazi integritet:
ReklamacijaDobavljac [OtpremnicaDobID] JE_PODSKUP_OD OtpremnicaDobavljac [OtpremnicaDobID]

Ovakav integritet se ne moze forsirati u modelu sa tri entiteta, a da se ne mesaju podaci i metapodaci.

Primer:

Code:

CREATE TABLE tipovi_dokumenata (
  tip_dokumenta CHAR(3) NOT NULL,
  ime_domkumenta VARCHAR(50) NOT NULL,

  CONSTRAINT pk_tdo PRIMARY KEY (tip_dokumenta)
);

INSERT INTO TABLE tipovi_dokumenata
       (tip_dokumenta, ime_domkumenta)
VALUES ('OTD', 'Otpremnica Dobavljac');

INSERT INTO TABLE tipovi_dokumenata
       (tip_dokumenta, ime_domkumenta)
VALUES ('RED', 'Reklamacija Dobavljac');

-- izostavljani su atributi nebitni za primer
CREATE TABLE dokumenati (
  tip_dokumenta CHAR(3) NOT NULL,
  broj_dokumenta INTEGER NOT NULL CHECK(broj_dokumenta > 0),
  tip_dokumenta_2 CHAR(3), -- lose ime atributa!
  broj_dokumenta_2 INTEGER, -- opet lose ime atributa!

  CONSTRAINT pk_dok PRIMARY KEY (tip_dokumenta, broj_dokumenta),

  -- dokument moze da referencira drugi dokument
  -- npr. reklamacija se poziva na otpremnicu
  CONSTRAINT fk_dok_dok FOREIGN KEY (tip_dokumenta_2, broj_dokumenta_2)
  REFERENCES dokumenti (tip_dokumenta, broj_dokumenta)

  -- dokument nesme da referenci samog sebe
  CONSTRAINT ch_dok_referenciranje
  CHECK (NOT (     (tip_dokumenta = tip_dokumenta_2)
               AND (broj_dokumenta = broj_dokumenta_2)))
);

INSERT INTO dokumenati
       (tip_dokumenta, broj_dokumenta, tip_dokumenta_2, broj_dokumenta_2)
VALUES ('OTD', 1, NULL, NULL);

INSERT INTO dokumenati
       (tip_dokumenta, broj_dokumenta, tip_dokumenta_2, broj_dokumenta_2)
VALUES ('RED', 1, 'OTD', 1);

Kako spreciti da se unese los podatak u kome se reklamacija poziva na drugu reklamaciju?

Code:

-- lose jer se reklamacija poziva na drugu reklamaciju, a sme samo na otpremnicu
INSERT INTO dokumenati
(tip_dokumenta, broj_dokumenta, tip_dokumenta_2, broj_dokumenta_2)
VALUES ('RED', 2, 'RED', 1);

Da bi se gornje sprecilo moraju se podaci izmesati sa meta-podacima, poput:

Code:

ALTER TABLE dokumenti
  ADD CONSTRAINT ch_dok_RED_referencira_OTD
  CHECK (   (tip_dokumenta <> 'RED')
         OR (    (tip_dokumenta = 'RED')
             AND (tip_dokumenta_2 = 'OTD')
            )
        );

3.

Poput gornjeg integriteta i sve ostale provere ispravnosti podataka je teze realizovati. Na primer:

Code:

-- dopuna atributima potrebnim za primer
ALTER TABLE dokumenti
ADD datum_dokumenta DATE NOT NULL;

ALTER TABLE dokumenti
ADD datum_prometa DATE;

Kako obezbediti da reklamacija nema datum prometa?
Odgovor:

Code:

ALTER TABLE dokumenti
  ADD CONSTRAINT ch_dok_treba_datum_prometa
  CHECK (   ((datum_prometa IS NULL) AND (tip_dokumenta = 'RED'))
         OR ((NOT datum_prometa IS NULL) AND (tip_dokumenta = 'OTD'))
        );

Kako obezbediti da datum optremnice nebude veci od datuma prometa?
Odgovor:

Code:

ALTER TABLE dokumenti
  ADD CONSTRAINT ch_dok_ispravni_datumi
  CHECK (   (datum_prometa IS NULL)
         OR (datum_prometa <= datum_dokumenta)
        );

Stalno se u constraint-ima borim sa NULL vrednostima atributa (sa pravilnom upotrebom tog NULL-a) i sa podacima o tipovima dokumenata! Ovo ni malo ne ubrzava programiranje.

4.
Sta ce se desiti kada sada dodam nov tip dokumenta?

Code:

INSERT INTO TABLE tipovi_dokumenata
(tip_dokumenta, ime_domkumenta)
VALUES ('OUK', 'Odobrenje Za Umanjenje Kupac);

Moram menjati neke od check comstraint-a uvedenih pod 3!
Zbog unosa novog PODATKA moram menjati META-PODATKE!

Code:

ALTER TABLE dokumenti
  DROP CONSTRAINT ch_dok_treba_datum_prometa;

-- dodat je tip doumenta OUK
ALTER TABLE dokumenti
  ADD CONSTRAINT ch_dok_treba_datum_prometa
  CHECK (   ((datum_prometa IS NULL) AND (tip_dokumenta IN ('OUK', 'RED')))
         OR ((NOT datum_prometa IS NULL) AND (tip_dokumenta = 'OTD'))
        );

Sta ako sam propusti da izmenim sve constraint-e?

Da rezimiram: Originalni model nema NULL vrednosti atributa i ne mesa metapodatke i podatke te ga ja smatram boljim.

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Odgovor na temu

momsab
Momčilo
Beograd, R.Srbija

Član broj: 2804
Poruke: 3041
*.dynamic.sbb.co.yu.

Jabber: pitati@PP
Sajt: www.momsab.com

+1 Profil

Re: poslovni dokumenti sa slicnim osobinama - kako predstaviti na"jednostavniji"nacin

^{20.02.2007. u 20:23 - pre 209 meseci}

zahvaljujem na iscrpnom odgovoru i ukazivanju na mane

ovo kako sam zamislio se ne bi moglo odraditi sa 3 tabele (i) zbog dokumenata koji imaju slozen kljuc (tip_dokumenta,broj_dokumenta, PPid)
moglo bi se odraditi sa 6 (ili 5, tj. da TIP_DOKUMENTA bude zajednicki za DOKUMENT_OD i DOKUMENT_ZA) tabela, sto je opet bolje nego sa 18 s pogleda kvantiteta
zeznuto je zbog mesanja podataka i metapodataka i zbog vece paznje kako ne bi promakla neka ogranicenja (neka je chachka objasnio)
odraditi sa 6 i paziti na sva ogranicenja ili odraditi sa 18 i uvoditi manji broj ogranicenja pitanje je sad

sa gledista pravljenja aplikacije pozivaju se 6 (ili 5) tabela i pravi se za svaki dokument posebna forma, da bi korisniku bilo lakse mada to isto moze da se uradi tako da bude za svaki dokument forma (9 dokumenata sa svojim stavkama i 9 formi) ili jedna forma u kojoj se bira sta se prikazuje, korisniku je svejedno, bitno je da radi i da moze da se snadje

Primer 5 tabela:

Citat:

DokumentOd (BrojDokOd, TipID, PPid, Datum, VremePlacanja, StatusPonude, UkupnoUmanjenje, MestoID, RefDokID, RefTipID)
StavkaDokOd (Rbr, BrojDokOd, TipID, PPid, PDV, Cena, Kolicina, ProizvodID)

DokumentZa (BrojDokOd, TipID, PPid, Datum, VremePlacanja, StatusPonude, UkupnoUmanjenje, MestoID, RefDokID, RefTipID, RefPPid)
StavkaDokOd (Rbr, BrojDokOd, TipID, PPid, PDV, Cena, Kolicina, ProizvodID)

TipDok (TipID, NazivTipa)

nadam se da nisam izostavio neke atribute, ume da bude zeznuto ovako; posle ovoga ide opet mesanje podataka i metapodataka

najverovatnije cemo odraditi sa pocetnim modelom, ovo sa 3 ili 6 tabela sam pitao zato sto me zanima da li je moguce odraditi "bezbolno" (nije moguce)

pitanje za chachku: da li bi mogao da mi obajsnis integritet ReklamacijaDobavljac [OtpremnicaDobID] JE_PODSKUP_OD OtpremnicaDobavljac [OtpremnicaDobID] ?

p.s. chachka, nije OUK i RED nego OUD i RED (OdobrenjeZaUmanjenjeDobavljac,a ne OdobrenjeZaUmanjenjeKupcu, je u vezi sa ReklamacijomDobavljacu)

_{[Ovu poruku je menjao momsab dana 21.02.2007. u 23:03 GMT+1]}

_{[Ovu poruku je menjao momsab dana 22.02.2007. u 01:55 GMT+1]}

Žena u krevetu i vino na stolu nikako ne smeju da čekaju. Jer, vino se greje a žena hladi.

-vinolog

Odgovor na temu

chachka
Srđan Mijatov
Programer
BUS Computers
Kikinda

Član broj: 53780
Poruke: 576
*.dialup.neobee.net.

Sajt: www.baze-podataka.net

+4 Profil

Re: poslovni dokumenti sa slicnim osobinama - kako predstaviti na"jednostavniji"nacin

^{22.02.2007. u 00:13 - pre 209 meseci}

Citat:

momsab: ... nadam se da nisam izostavio neke atribute, ume da bude zeznuto ovako; ...

Tek si postavio model, a već se pitaš da nisi nešto propustio. Da, zaista je zeznuto i govori u prilog da je takav model loš.

Citat:

momsab:da li bi mogao da mi obajsnis integritet ReklamacijaDobavljac [OtpremnicaDobID] JE_PODSKUP_OD OtpremnicaDobavljac [OtpremnicaDobID] ?

Neka je:

R = relacija
A = (delimična) lista atributa relacije R

Ostalo mi je nekako u glavi da se projekcija relacije R po listi atributa A može zapisati sa:

R[A]

kao alternativa notaciji

P_A(R)

Čini mi se da ovakvu notaciju ( R[A] ) za projekciju koristi prof. Pavle Mogin i/ili njegovi (bivsi) asistenti. Voleo bih da mi neko ovo potvrdi ili demantuje.

U svako slučaju, recimo da sam usvojio notaciju
R[A]
za relacionu operaciju projekcije.

Tada mi ReklamacijaDobavljac [OtpremnicaDobID] prevedeno u SQL znači

Code:

SELECT OtpremnicaDobID
FROM ReklamacijaDobavljac

Slicno mi OtpremnicaDobavljac [OtpremnicaDobID] znači

Code:

SELECT OtpremnicaDobID
FROM OtpremnicaDobavljac

Rečima JE_PODSKUP_OD sam jednostavno zamenio onaj matematički znak za podskup (izvrnuto U sa crticom ispod).

Celom konstrukcijom ReklamacijaDobavljac [OtpremnicaDobID] JE_PODSKUP_OD OtpremnicaDobavljac [OtpremnicaDobID] sam označio da su vrednosti atributa OtpremnicaDobID iz relacije ReklamacijaDobavljac podskup vrednosti atributa OtpremnicaDobID iz relacije OtpremnicaDobavljac, odnosno prevedeno u SQL:

Code:

  ALTER TABLE ReklamacijaDobavljac
    ADD CONSTRAINT fk_red_otd FOREIGN KEY (OtpremnicaDobID)
    REFERENCES OtpremnicaDobavljac(OtpremnicaDobID);

Zašto sam upotrebio baš takvu konstrukciju?
U originalnom postu je model predstavljen notacijom:

Citat:

OtpremnicaDobavljac (OtpremnicaDobID, PPid, StatusOtpremnicaDob, BrojOtpremnicaDob, DatumOtpremnicaDob, DatumPrometaOtpremnicaDob,PorudzbinaDobID)
ReklamacijaDobavljac (ReklamacijaDobID, DatumReklamacijaDob, OtpremnicaDobID, PPid)

Opet mi se čini da sam od gore pomenutog profesora pokupio da se u takvoj notaciji referencijalni integriteti predstavljaju kombinacijom projekcije i podskupa (Opet bih cenio potvrdu/demant).

Predpostavku sam jednostavno načinio zato što u originalnom postu nisu naznačeni referencijalni integriteti, već moraju da se nagađaju (odnosno predpostavljaju).

PS: Kada sam sve ovo sažeo, primećujem da je ispravnija predpostavka:
ReklamacijaDobavljac [PPid, OtpremnicaDobID] JE_PODSKUP_OD OtpremnicaDobavljac [PPid, OtpremnicaDobID]

_{[Ovu poruku je menjao chachka dana 22.02.2007. u 01:29 GMT+1]}

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Odgovor na temu