Denormalizacija baze

Preturajuci po postovima sa foruma saznao sam da je skakljiva tema i da treba biti oprezan pri denormalizaciji ali posto je akademski rad ne moze biti velika steta:) Zahtev je da se odradi denormalizacija unutar baze nabavke. Imam jednu ideju ali mi je potrebna pomoc da je realizujem. Tabele koje bi ucestvovale u denormalizaciji su:

NabavniNalog ( SifraNaloga #, Datum, ZatvorenNalog, SifraSektora #, JMBG #, JMBG` #)
StavkaNabavnogNaloga (SifraNaloga #, Rb #, SifraPro #, TrebovanaKolicina, RokNabavke, ZatvorenaStavka)

Narudzbenica (SifraNarudzbenice #, DatumPrometaDobara, DatumValute, DatumIzdavanja, SifraDob #, SifraPonude #, JMBG#)
StavkaNarudzbenice (SifraNarudzbenice #, Rb #, NarucenaKolicina, SifraPro #)

Prijemnica (SifraPrijemnice #, Datum, Ukupno, JMBG #, SifraOtpremnice #)
StavkaPrijemnice (SifraPrijemnice #, Rb #, PrimljenaKolicina, Cena, IznosPDV, Iznos, SifraPro #)

Proizvod (SifraPro #, Naziv, JedMere, KolicinaUSkladistu, Opis)

Na osnovu njih ja bih napravio jednu tabelu izvestavanja npr. Promet proizvoda koja bi davala kumulativne vrednosti iz ovih gore tabela po proizvodima:

PrometProizvoda (SifraPP#, SifraPro#, Naziv, TrebovanaKolicina, NarucenaKolicina, PrimljenaKolicina)

Znaci svaki put kada se kreira neki od dokumenata NabavniNalog, Narudzbenica, Prijemnica da se to upisuje u novoformiranu tabelu. Da li sam na dobrom putu i da li je moguce realizovati ideju? I kako ispovezivati tabele? Preko SifraPro# ili? Takodje je dobrodosao svaki savet i ideja o denormalizaciji u ovom primeru. Mozda u novu tabelu uvesti polje datum.
Podvuceni su PK, dok su FK oznaceni sa #.

Imas srece ovaj put. Tvoje tabele vec izgledaju dovolno denormalizovane, tako da nemas sta da radis.

Ovako:

A)
Verovatno vazi
Iznos = PrimljenaKolicina * Cena + IznosPDV
Zanci da je Iznos racunata kolona i ne bi trebalo da bude u normalizovanoj tabeli. Znaci, ova tabela je denormalizovana dodavanjem kolone koja nije nazavisna nego se racuna.

B)
I ova tabela je denormalizovana. Kolona KolicinaUSkladistu teorijski ne bi trebala da postoji. Kolicina u skladistu se racuna kao razlika ukupnog ulaza i izlaza. Prema tome, i ovo je zavisna kolona - zavisi od svih ostalih redova u nekim drugim tabelama.

Da su ti tabele normalizovane, ovo pod B) bi doslo u ozbzir ka nekakva 'razumna' denormalizacija. Kad god roba udje u mgacin, neki triger poveca KolicinaUSkladistu u tabeli proizvod. Kad god roba izadje iz magacina, onda neki triger smanji kolicinu u tabeli Proizvod. Zasto? zato sto se KolicinaNaSkladistu racuna kao zbir svih ualza u nekoj tabeli koja prati ulaz minus szbir svih izlaza u nekoj tabeli koja prati izlaz. I tako za sve proizvode. I programeri koji su radili u COBOLu znaju da je to spora operacija i plase se toga. U SQL bazama to nije spora operacija i ne treba raditi, ali neki to po navici rade. Niko ne razmislaj da je sporije pozivati triger na dve tabekle da bi se yuraduio UPDATE na trecoj tabeli, ali sta da radis, stare navike i stari strahovi ne umiru lako.

Ono pod A), Iznos = Kolicina*cena se ne radi jer je absolutno nepotrebno, uvek se moze dobiti u kveriju i kveri prakticno ne bi bio nista sporiji.

Posto si unapred normalizovao bazu, sada treba da vodis racuna da se ove izracunate vrednosti azuriraju svaki put kad se nesto promeni na izvoru podatka. A to znaci pisanje trigera. A to je strasno zabavno, pa zasto da ne.

Hvala na brzom odgovoru, Zidar. Citajuci postove razmisljao sam da bi bilo lepo videti tvoj post na temi:)

Znao sam da su izvedeni rezultati denormalizacija ali pretpostavljao sam da mogu uraditi nesto malo sire. U nekim radovima sam naisao na primer u kom se denormalizuje baza pravljenjem ovih tabela za izvestavanje a takodje i vertikalnom i horizontalnom podelom tabele, pa sam pomislio da ne bi bilo lose pokusati tako nesto. A sto se tice att KolicinaUSkladistu mislis da bi ga trebalo brisati? Ja parkticno izlaze i nemam, jer gledamo samo proces vezan za dobavljaca, nema izdavanja materijala sa skladista. Ako uspem do veceras da uradim kompletan MOV u visio-u okacicu ga ovde, sada ga imam samo iz delova. Dobro mi doslo par saveta za poboljsanje, jer na faksu naucis jedan nacin i onda te guraju da to radis copy-paste. A trigeri su svejedno obavezni da se urade tako da se nadam da cu uzivati sa njima:)

[QUOTE]U nekim radovima sam naisao na primer u kom se denormalizuje baza pravljenjem ovih tabela za izvestavanje a takodje i vertikalnom i horizontalnom podelom tabele, pa sam pomislio da ne bi bilo lose pokusati tako nesto.[/QUOTE]

Seti se da normalizacija vodi do manje vise jedinstvenog resenja. Denormalizacija je otvoren proces i ima beskonacno mnogo resenja. kao sistem jednacina sa pet nepoznatih i samo 3 jednacine. Za dve nepoznate mozes da pretpostavis sta god hoces. Teorijski, svaki upit koji korisniku moze da zatreba, moze se pretvoriti u flat tabelu. Medjutim, to se tada ne zove vise denormalizacija, nego gradjene neceg sto se zove Data Warehouse. A to nije tvoj zadatak.

Predlazem da nista vise ne denormalizujes. Ostavi KolicinaUSkladistu, to ce ti neko kad tad traziti u praksi, pa zasto da ne probas. Ostavi dakle da se kolicina u skladistu menja kad god se unese ili promeni neki red u tabeli StavkaPrijemnice. Trebace ti triger na StavkaPrijemnice koji pri unosu ili promeni kolone Kolicina azurira tabelu Proizvodi. Ti nemas nikakvu tabelu koja bi vodila ulaz, ali ne mari, princip je isti. Bice ti veoma zabavno da pises triger koji treba da radi sa vise od jednim rekordom u jednoj transakciji.

Ono Iznos = Kolicina*Cena definitivno izbaci jer je besmisleno. To ti niko nece traziti ni u praksi, za razliku od kolicine u skladistu.

Ako bas hoces, uradi vertikalnu podelu, recimo hoces da vodis tabelu Prijemnica i StavkePrijemnice posebno za svaku godinu. Tako ces imati Prijemnica_2010, StavkePrijemnice_2010, pa sledece godine novi par tabela Prijemnica_2011, StavkePrijemnice_2011 i tako dalje svake godine. Tabela Proizvod ostaje ista. Sada ces morati da onaj triger koji azurira tabelu Proizvod pravis nanovo, kad god kreiras novu tabelu StavkePrijemnice_2011. Plus, kad ti bud etrebao neki visegodisnji pregled, moraces da radis UNION izmedju razlicitih tabela. Da bude gore, taj kveri ce morati da se manja kad god dodas novi par tabela. I sve ovo radis jednom godisnje, taman dovoljno da zaboravis sta si radio prosle godine.

Kako rekoh, denormalizacija je otvoreno pitanje i ima beskonacno odgovora, ni jedan ne valja, ali s eu izvesnim situacijam u praksi moze prihvatiti. Sve zavisi od situacije.

Izbacen ce biti taj iznos, a samim tim bih izbacio i Ukupno sa Prijemnice, jer to je sum iznosa po stavkama?

Sad, cini mi se da ce ovo sa prijemnicama da mi zada glavobolje pa bih pre radio vertikalnu podelu npr nove tabele Dobavljac (SifraDob#, NazivDob, Adresa, Telefon, Mail, Pib, TekuciRacun, Delatnost) i to na Dobavljac1(SifraDob#, NazivDob) --- sadrzi najcesce koriscen podatak o dobavljacu
Dobavljac2(SifraDob#, NazivDob, Adresa, Telefon, Mail, Pib, TekuciRacun, Delatnost)

Da li bi to znacilo da obe ove tabele moram da vezujem sa svim drugim tabelama u modelu? Npr imam tabelu Katalog(SifraKat#, Datum, SifraDob#) i posto je ovde SifraDob FK morao bih vezati tabelu i sa Dobavljac1 i sa Dobavljac2?

Vezano za tbl Proizvod, meni je ta tabela povezana sa StavkaReklamacije preko SifraPro, veza je tbl Proizvod 0,m---1,1 tbl StavkaReklamacije. Kojom od tehnika denormalizacije bi se smatralo ubacivanje att KolicinaUSkladistu? Mozda Pre-joining Tables?

_{[Ovu poruku je menjao laden dana 24.02.2010. u 02:56 GMT+1]}

Nemoj da izbacujes UkupnoNaSkaldistu. Jeste denormalizovano, ali se cesto trazi i radi u praksi i jeste ono sto hoces da demonstriras.

Ako razbijes tabelu Dobavljaci na dve, koje ce biti u vezi 1:1, to je OK. Za sve ostale atbeel treba da vezes samo
Dobavljac1(DobID, ImeDobavljaca).
Onu sa dresom vezujes samo za Dobavljac1.

Primeti da u Dobavljac2 imas ImeDobavljaca. To ti je denormalizacija, ponovio si kolonu koja nije PK na dva mesta. Razbijanje tabele na dve koje su u vezi 1:1 tehnicki jeste denormalizacija ali je najbezazlenija od svih (pogotovo ako osim PK nemas zajednickih kolona). To s eu praksi takodje radi i korisno jaj znati akko se to radi.

Primer za Pre-joining bi bila na primer tabela PregledDugovanjaDobavljacu (DobavlajcID,VrednostIsporuceneRobe, KolikoSmoPlatili)

Kad god dobavljac isporuci robu (stavke prijemnice) dodas ukupnu vrednost iz te prijemnice na kolonu VrednostIsporuceneRobe.
Kad god nesto platimo dobavljacu, dodas taj iznos koloni KolikoSmoPlatili. Tako onaj ko hoce da vidi kome sta dugujemo u svakom momentu, moze da otvori tabelu PregledDugovanjaDobavljacu i vidi sve odmh, bez potrebe da se izvrsava kveri koji bi vratio iste rezultate.


Ne znam, nisam teorijski mnogo potkovan. Denormalizacija nije zasnovana na teoriji pa u principu ne postoje 'tehnike'. Mozda je pre-joinig, ali sa agregacijom - jer ti treba i JOIN i GROUP BY SUM() u kveriju koji racuna KolicinuUSkladistu.

Generalno, koji god metod denormalizacije su ti opisali i zadali, uvek mozes da napravis kveri koji vraca zahtevane rezultate. Sad zamisli da je taj kveri tabela koju treba da popunjavas kad se nesto desi u drugim tabelama. Denormalizacija jednostavno materijalizuje kverije. A kverija moze biti beskonacno mnogo. Koji ce se izabrati, zavisi od konkretnih uslova. Ti sebi zamisli neke uslove i pusi masti na volju.

Sto vise problema budes imao da napravis denormalizovano resenje, tim bolje, naucices da izbegavas takva resenja u praksi.

Veoma mi koristi ova diskusija i polako shvatam bazicne ideje. Tako su nam siromasno govorili o ovome na faksu a sada traze da se uradi. Trigere cak nisu ni predavali a ja cu sada morati u radu da odradim i specifikaciju i implementaciju istih:( Hvala jos jednom na velikoj pomoci, Zidar. Trudicu se da u daljoj diskusiji iznosim konkretne predloge. Kad zavrsim sa tri ili cetiri primera denormalizacije i specifikaciju trigera za njih javljam se i pokusacu da ih okacim u temi.

Pomoci cu sa zadovoljstvom. Samo budi oprezan da te ne odvucem od teme ili zadatka. Sta se desava u praksi je jedna stvar, a sta ti traze da uradis je nesto sasvim drugo.

Ja sam u ovom poslu manje vise samouk i moras dobro da pazis sta ces da prihvatis od mene, da se ne uvalis u nevolju. Radi sta ti profesor kaze, a ja ti mogu pomoci ako negde nesto zapne oko tehnickih detalja. Ne samo ja, imas gomilu ljudi na forumu koji znaju isto ili vise, a zavrsili su istu ili slicnu skolu koju ti sad ucis.

Srecan rad.

Evo ga prvi primer denormalizacije i specifikacija trigera. Nadam se da je dobro:)

Okacio sam i ostale primere.

_{[Ovu poruku je menjao laden dana 25.02.2010. u 02:02 GMT+1]}

Meni izgleda OK, ali proveri sa profesorom da li je to sto si uradio u stvari ono sto se trazi. Ne bih da padnes na ispitu pa posle ja budem kriv. Sve sto si napisao deluje OK, ali vidi sa profsorima da li je to ono sto su oni zamislili.

Srecno

Po shvatanjima profesora samo je primer sa tranzitivnoscu denormalizacija, na ostalo gledaju kao na optimizaciju. Mogli su nam to bar i reci:( No dobro, imam novi termin da to popravim i da napisem trigere, tako da se nadam da cu naici na ovako dobru vasu pomoc i kad krenem to da radim.

Denormalizacija je obrnuto od normalizacija. Ništa novo, ali je ključ za rešenje :)

Normalizaciju radimo tako da šemu baze redom prebacujemo iz 1nf u 2nf pa u 3nf.

Denormalizacija je obrnuto iz 3nf pa u 2nf pa u 1nf.

Primer na delu polazne šeme koja je u 3NF:

Narudzbenica (SifraNarudzbenice #, DatumPrometaDobara, DatumValute, DatumIzdavanja, SifraDob #, SifraPonude #, JMBG#)
StavkaNarudzbenice (SifraNarudzbenice #, Rb #, NarucenaKolicina, SifraPro #)
Proizvod (SifraPro #, Naziv, JedMere, KolicinaUSkladistu, Opis)

Prebacimo je u 2NF:

Narudzbenica (SifraNarudzbenice #, DatumPrometaDobara, DatumValute, DatumIzdavanja, SifraDob #, SifraPonude #, JMBG#)
StavkaNarudzbenice (SifraNarudzbenice #, Rb #, NarucenaKolicina, SifraPro #, Naziv, JedMere, KolicinaUSkladistu, Opis)

Sad ovo prebacimo u 1NF:

Narudzbenica (SifraNarudzbenice #, DatumPrometaDobara, DatumValute, DatumIzdavanja, SifraDob #, SifraPonude #, JMBG#, Rb #, NarucenaKolicina, SifraPro #, Naziv, JedMere, KolicinaUSkladistu, Opis)

Potpis

"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

Uvek znam da je nesto briljantno kad vidim resenje i kazem "Tako jednostavno, pa zasto se ja nisam ovoga setio?"

:-)

Korisnički programi koji komuniciraju sa nekom bazom podataka mogu se podeliti u dve grupe:

1. Programi kojima se vrši obuhvat i memorisanje podataka u bazu (interaktivno ili u BATCHu). Ovo su tzv "Analizatori podataka", kojima se ulazni podaci raščlanjuju i memorišu u tabele baze podataka.

2. Programi kojima se se vrši izveštavanje. Ovo su tzv. "Sintetizatori podataka" koji na osnovu podataka iz baze generišu izveštaje.

Normalizacijom se omogućuje da programi prvog tipa funkcionišu na najbolji način. Postupak normalizacije je nezavisan od vrste podataka i dokumenata koje treba "analizirati" (dokumenata sa kojih se unose podaci). Nažalost, normalizovana baza ne omogućuje bezuslovno dobre performanse za programe drugog tipa (za izveštavanje). Štaviše, normalizovana baza je skoro uvek uzrok slabijih performansi programa drugog tipa. Zbog toga se na kontrolisan način uvode izvedeni objekti u bazu - baza se denormalizuje. Kako će se vršiti denormalizacija baze veoma zavisi od izlaznih (sintetizovanih) dokumenata - izveštaja pa se postupak denormalizacije ne može dati generalno. U prilogu se nalazi dokumenat u kome je pokušano da se ipak napravi gruba sistematizacija postupaka denormalizacije.

Da prokomentarišem i:



Ako je npr. izvedeni atribut IZNOS jednak proizvodu KOLIČINE i CENE, tada ipak tranzitivno zavisi od ključa relacije kojoj pripada pa je i baza koja ga sadrži denormalizovana.



_{[Ovu poruku je menjao Fitopatolog dana 03.03.2010. u 18:07 GMT+1]}

Ovde treba postaviti i pitanje - U kojoj to normalnoj formi treba da bude šema baze da bi je profesor smatrao denormalizovanom? Da li je to 1nf, 2nf ili 3nf?

Ili obrnuto pitanje - Koju to normalnu formu treba da zadovoljava šema da bi je profesor proglasio normalizovanom? Onda je, naravno, sve ispod toga denormalizovano.

Potpis

"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

Normalizacija je radjena do trece normalne forme. Ali to je sada ok, problem je nastao jer ja nisam znao sta oni pod denormalizacijom smatraju pa sam tako uradio neke stvari koje su po njima optimizacija, mada je svuda u literaturi na netu do koje sam ja dosao to denorm.

Druže,
Sigurno je u pitanju FON, predmet Baze podataka 2 i profesor Marijanović? Jesam li u pravu?

Imam isti problem kao i ti, tačnije, prošao sam kod profe isto kao i ti. Sve što sam uradio su svrstali u optimizaciju a ne u denormalizaciju!

Hoću sad sa tobom da vidim da li sam dobro razumeo šta treba da se uradi pod denormalizacijom.

NPR:

Student (Br_Ind #, Ime i prezime, Adresa, telefon.....)
Predmet(ID_PRED#, Naziv_Predmeta, Profesor)
Položio(Br_Ind #, ID_PRED#, Ocena )

Denormalizacija:

Položio(Br_Ind #, ID_PRED#, Naziv_Predmeta, Ocena )

Ubacili smo Naziv predmeta u tabelu Položio, time narušili 3NF, ali smo, kao, dobili na performansama jer sad kad izlačimo izveštaj o položenim ispitima za nekog studenta, ne moramo da povezujemo tabele Položio i Predmet već to sve čitamo iz tabela Položio. Možda je primer glup ali mislim da si shvatio poentu. Znači, ne ubacuješ neku novu izvedenu vrednost (to je optimizacija) već povlačiš neki atribut iz druge tabele kako bi dobio na performansama.

A drugi primer, odnosno narušavanje 2nf, bi bilo kad bi umesto nekog neljučnog atributa (u ovom primeru ime i prezime) povukao neki spoljni ključ i tako poboljšao povezivanje tabela. Odnosno, umesto da povežeš tri tabele da dođeš do nekog podatka, uradiš denormalizaciju, ubaciš spoljni ključ u jednu od tabela i onda povežeš samo dve tabele i tako poboljšaš performance. :)

Jesam li dobro shvatio priču oko denormalizacije ili ne?

I posle uspešne denormalizacije, treba da uradiš triggere koji bi se odnosili samo na ove denormalizacije.
NPR. Promena Br_indeka u tabeli Položio treba da aktivira trigger koji će ažurirati Ime studenta u tabeli položio.

Potpis

Miki

Ja mislim da je ovo sto si ti opisao resenje naseg problema. Jesu BP2 na FON-u :) Ja cu tako i uraditi, s tim sto su sada za trigere izbacili semu na sajtu koja ne sadrzi deo za proveru PK jer je to odradjeno preko ref. integriteta.

Da vam se i ja pridruzim :)
Pitanje za denormalizaciju:da bih narusila III NF ako npr. imam:
DepoKarton (IDDepoKartona#, ..., BrojRačuna#), pa ovo denormalizujem kao DepoKarton (IDDepoKartona#, ..., BrojRačuna#, BrojModela, PozivNaBroj) posto je Račun(BrojRačuna#, BrojModela, PozivNaBroj, Suma...).
Prvo pitanje: stavljam samo neke atribute, ne moram sve?

Zatim, da bih narusila II NF iz:
DepoKarton(IDDepoKartona#, DostavaIzvoda, DatumDK)
StavkeDepoKartona(IDDepoKartona#, RBStavkeDK#, Samostalno, ....)
dobijam:
DepoKarton(IDDepoKartona#, DostavaIzvoda, DatumDK, {RBStavkeDK#, Samostalno, ...})
Zanima me je li ovo ok?

Zatim, kod trigera, moze li neko da napise primer pseudo-koda... Meni je nekako glupo da pisem: "ako postoje stavke depo kartona, zabranjuje se brisanje depo kartona, u suprotnom... bla bla"

III NF ti je dobra i bas tako nesto sam i ja uradio, a naravno da ne moras da stavljas sve atribute, samo one koje mislis da bi bili korisni gledano sa aspekta poslovne logike.
Ovo razbijanje II NF ja nisam radio, to mi je bas previse da strpam sve te stavke u jednu tabelu:( Ja sam odradio iz jednog od mojih prethodnih postova denormalizaciju i trigere 1 pa pogledaj. A za pseudo kod mislim da ti je bolje da se drzis ovih njihovih primera sa sajta, jer svako svoje dete voli najvise na svetu:)

E sad, ja imam problema sa implementacijom trigera, u ms sql serveru 2000 sam ih pokusao uraditi. Ako neko moze da pomogne, sta je potrebno izmeniti da bi ovaj kod proradio


Triger inace treba da kad se azurira naziv JedMere u tabeli Proizvod to azuriranje odradi i u tabeli StavkaPrijemnice, za odgovarajuci proizvod(po SifraPro).

Tabele su:
StavkaPrijemnice (SifraPrijemnice#,Rb#, PrimljenaKolicina, Cena, SifraPro#, Naziv, JedMere)
Proizvod(SifraPro#, Naziv, JedMere, Opis)

RESENO, evo triger, nadam se da je to to. Radi ali ako neko ima zamerke neka ih slobodno iznese


<sub>[Ovu poruku je menjao laden dana 07.03.2010. u 00:35 GMT+1]

[Ovu poruku je menjao laden dana 07.03.2010. u 00:41 GMT+1]</sub>