[ FOX028 @ 03.06.2015. 06:02 ] @
Zamolio bih iskusnije članove foruma ako su u mogućnosti da mi daju neke smernice oko izrade ove baze, da napomenem ne tražim da mi neko uradi bazu.


Projektovati bazu za čuvanje i pretraživanje farmakoloških podataka.
U osnovi, ova baza sadrži pretražive podatke o simptomima i farmakološkim preparatima.
Svaka bolest se ispoljava kao skup nekih simptoma. Svaki simptom se ispoljava u tri jačine : blag, izražen, jak.
Svaki farmakološki preparat utiče na više simptoma istovremeno. Uticaj nekog farmakološkog preparata na svaki od ovih simptoma posebno može biti u tri jačine: slab, srednji, i jak.
Projektovati bazu podatak za skupove simptoma i farmakoloških preparata. Uzeti u obzir i jačinu simptoma i jačinu dejstva preparata.

Može li mi neko takođe objasniti šta se podrazumeva pod ovim:

Pokazati da projektovana baza podataka zadovoljava sledeće normalne forme : prva, druga, treća, četvrta, i Bojs-Kodova (BCNF) normalna forma.

Hvala unapred.


[Ovu poruku je menjao Getsbi dana 03.06.2015. u 08:10 GMT+1]
[ Getsbi @ 03.06.2015. 07:08 ] @
Oko normalnih formi ćeš morati da uzmeš knjigu i da naučiš teoriju. To baš nije takvog obima da se može iskazati u jednoj poruci.
Model tvoje baze bi mogao da izgleda otprlilike ovako:
[ Zidar @ 05.06.2015. 22:12 ] @
Odgovor:
Iz primera koji je postavio Getsbi mogu se videti osnovni principi normalizacije.

Glavne normalne fome su: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, 6NF. Ovakav redosled navodjenja samo znaci da ako je tabela u formi n onde je tabela automatski u formama k < n. NZaci, ako dokazemo da je tabela na primer u BCNF, onda je ona automatski u 1,2,3 NF. Za praksu su vazne 1NF, BCNF i 5NF. 4NF i jos neke, su od teorijskog znacaja, u praksi nas ne zanimaju.

Prvo da resimo trivijalne slucajeve.
Teorema 1: (bez dokaza, iz knjiga C.J. Date database Design and Relational Theory":
"Sve tabele koje pored kljuca imaju tacno jedno polje koje nije deo kljuca su u 6 (sestoj) NF.

To znaci da su automatski i u 5,4,3,2,1 NF. Ovaj uslov zadovoljavaju tabele sifranici: Jacina, Bolest, Uticaj. relacija je u 6 NF ako se ne moze vise rastaviti na komponente a da se ne izgubi informacija. Ovo je ogicno, jer ako tabela ima samo jednu kolonu plus kljuc, onda je ne mozete rastaviti na dve table. Ako ima tri kolone plus kljuc, onda moze da se rastavi na tri tabele (Kljuc, Kol1), (Kluc, Kol2), (Kluc, Kol3).

Drugo, svaka tabela koja predstavlja valjano napravljenu relaciju je u najmanje 1 NF. Valjano napravljena relacija:
1) redosled redova nije vazan
2) redosled kolona nije vazan
3) redovi su medjusobno razliciti, nema duplikata, znaci imamo jedinstveni kljuc)
4) Presek svakog reda i kolone sadrzi tacno jednu vrednost koja odgovara tipu te kolone
5) Sve kolone su regularne.

Uslovi 1-3 su opstepoznati i poznati. Uslovi 3 i 4 zahtevaju objasnjenje. Evo primer tabela koja narusava pravilo 4:
Code:

[Bolest]            [Simptomi]
-------------------------------------------------------------------------------------
grip                'visoka temperatura', 'glavobolja', 'bol u misicima'
tuberkuloza            'suvi kasalj', 'iskasljava se krv', 'opsta slabost organizme'
zubni karijes        'zadah iz usta', 'zubobolja', 'zubna gledj se raspada'


Pravilo 4. je naruseno zato sto u koloni [Simptom] vidimo grupe simptoma, vise njih a ne samo jedan. Shodno, data tabela ne predstavlja relaciju, pa se o 1NF ne moze ni govoriti. verovatnoi svi znaju resenje za ovo - razbiti tabelu na dve:
Code:

[Bolest]    
-------------
grip        
tuberkuloza    
zubni karijes

i

[Bolest]            [Simptomi]
-----------------------------------------
grip                visoka temperatura
grip                glavobolja
grip                 bol u misicima
tuberkuloza            suvi kasalj
tuberkuloza            kaslje se krv
tuberkuloza            opsta slabost organizma
zubni karijes        zadah iz usta
zubni karijes        zubna gledj se raspada

I gle cuda, od tabele koja nije ni u 1NF, dobismo dve od kojih je jedna cak u 6NF (Bolesti) - ne moze se razbiti na dve tabele.

Druga, SimptomiBolesti je barem u BCNF, sto znaci da je automatski u 3NF,2NF i 1NF. Zasto? Zato sto cika C.J> Date daje jos jednu teoremu:

Teorema 2: Tabela u kojoj sve kolne cine kljuc, i nema drugih kolona, je u BCNF. Ovo vazi za tabele. Za relacije, ima teorijska zackoljica koj kaze da u nekim specijalnim slucajevima kod binarnih relacija (dve kolone) ovo ne vazi, ali u praksi teorema 2 iteko vazi.

U primeru koji je ostavio Getsbi, tabele BolestSimptom i PreparatSimptom su barem u BCNF, po Teoremi 2.sto je za praksu sasvim dovoljno. Moze se dokazati da su i u 5NF, mada se ne moze tvrditi da je u 5NF svaka tabela koja nema atributa koji nisu kljuc ili deo kljuca. U vecini slucajeva, tabele koje su u BCNF jesu i u 5NF ali nam to ne znaci mnogo.

Primetite da nije bilo potrebno da u nasem slucaju dovedemo tabelu u 1NF, pa 2NF pa 3NH i tako dalje. Razbijanjem liste podataka odvojenih zarezima u zasebne redove postigli smo odmah 'njavisi stepen' normalizacije. Lista podataka odvojenih zarezom, ako se cuva u celiji )presek reda i kolone) naziva se ponavljajuca grupa. Svi smo culi da su ponavljajuce grupe anatema relacionih baza, a sada znamo i zasto - ako imamo ponavljajuce grup, onda nemamo relaciju uopste i ceo posao pada u vodu u startu. U praksi medjutim, pod pojmom ponavljajuca grupa cesto se pogresno podrazumeva nesto drugo.

Sta bi bila tabela u 1NF, a jos nije nu 2 ili 3NF? Evo primer:
Code:

Bolest Simptom1 Simptom2 Simptom3
-----------------------------------------
x1         y             z         w
x2         a             y         w
x3         z             w         NULL


U praksi se ovo pogresno podrazumeva tabelom koja nije u 1NF jer ima ponavljajuce grupe - grupe kolona - Simptom1, Simptom2, Simptom3. teorijski, to nije tacno. zasto? Zato sto definicija ponvlajuce grupe znaci "lista podataka odvojenih zarezom u jednon celiji". Ova razlika u shvatanju 1NF nije tako vazna za praksu, jer jedno je gotovo sigurno tabela sa atrinbutima (Bolest Simptom1 Simptom2 Simptom3) - nije dobro dizajnirana. Ovo pak znaci da normalizacija i dobar dizajn nisu uvek identicni pojmovi. Evo jedna tabela sa 4 slicne kolone koje se ponavljaju, a da dizajn nije pogresan:

PrihodPoKvratalima: {Godina (PK), Q1, Q2, Q3, Q4}.

Ne vidim posaban razlog da razbijanje ova tabele na dve donosi neki veliki dobitak. Ako nam odgovara bas ovakva struktura, onda je tabela zasigurno u BCNF, jer svaka kolona zavisi iskljucivo od kljuca (Godina) i niceg vise.
Isto tako, ovakva tabela KolicinaKiseUBeogradu:{Godina (PK), Jan, feb, Mar, April, Maj, Juni, juli, Aug, sep, okt, Nov, Dec} garantovano postoji u hidro-meteoroloskom zavodu, i sasvim lepo sedi na nekom SQL erveru, ORACLE il cak Access bazi. Sve zavisi od koncepcije resenja i konkretnog problema, ali u vecini slucajeva su resenja sa ponavljajucim kolonama u najmanju ruku sumnjiva. Ali ne uvek.

U praksi nas uglavnom interesuje da tabele dovedemo do BCNF. Vrlo retko treba da se bavimo sa 5NF, zato sto u 99% slucajeva kad dovedete tabelu u BCNF, onda je ona i u 5NF. To je zbog ovih teorema:

Teorema 3: Ako je tabela u 3NF (ne mora da bude cak ni BCNF, 3NF je dovoljno), i nema slozenih kljuceva (nema kljuceva koji se sastoje od dva ili vise atributa), onda je tabela u stvari u 5NF.

Teorema 4: Ako je tabela u BCNF, i neka postoji bar jedan atribut koji nije deo nekog kljuca, onda je ta tabela u 5NF.

Posledica T3,T4: ako je tabela u BCNF, i svi atributi ucestvuju u nekom od kljuceva, onda se ne primenjuju ni T4 ni T5, a to znaci da se ne garantuje 5NF, ali se ne tvrdi ni da nije moguca 5NF. Ovo se u literaturi srece pod nazivom 'trenarne relacije', koje se sastoje od 3 atributa, od kojih su dva i dva kljucevi, to jest jedan od atributa je deo oba kljuca. na srecu, treba biti majstor ili maler, pa se dovesti u tu situaciju, da ste u BCNF, ale ne i u 5NF i da vam to stvara probleme.

Zapazanje C.J. date o 3NF i BCNF: vecina primera u literaturi, gde se objasnjava 3NF u stvari predstavlkjau BCNF. Ispostavlja se da nije lako naci primer tabele koja je u 3NF ali ne jos u BCNF.

Preskocili smo drugu, cetvrtu i one teorijske NF. Pokazacemo da se jednostavno dolazi do BCNF, a to uglavnom znaci i do 5NF i bez one price koja se daje u lietraturi o Iz cele price proizilazi da sve sto treba da uradite u procesu normalizacije jeste:

1) Da proverite da li vase tabele (sve) zaista predstavljaju neke relacije - nemaju ponavlajucih grupa elementaa odvojenih zarezom u jednoj celiji.
Ako je tako, tabele su u najmanju ruku u 1NF, a time je i baza podataka normalizovana. Opet odstupanje od prakse. U praksi se misli da je baza normalizovana ako smo sve tabele doveli barem do BCNF, sto je opet nebitno za praksu.

2. Ako tabele imaju ponavlajuce grupe kolona, proverite da li vam to bas tako treba, pa ako ne treba, razbijte takve tabele na dve ili vise. Tu ste vec u BCNF sa velikom sansom da vaze T3,T4, sto znaci da set u 5NF.

3. Proverite da li neka tabela ima slozeni kljuc. Svi atributi koji nisu deo kljuca, moraju da zavise iskljucivo od kljuca i niceg vise (ne smaju da zavise od dela kljuca, od samo nekih kljucnih atributa). Ako je ovo OK, ond je tabela u BCNF, gotovo kraj price. Ako nije, onda ste u 2NF, ali vas to ne zanima, vazno je da izadjete iz te situacije.

Kako se to onda dolazi do baze gde je sve barem u BCNF, a time i u 5NF, to jest 'potpuno normalizovano'. odgovor se nalazi izvan relacione teorije i zove se dijagrami objekti veze, ER dijagrami i slicno, sto je uglavnom ista stvar.

Ajde da pogledamo na kraju prelozenu bazu, tabela po tabela:
1) U 6 NF su tabele Jacina, Bolest, Uticaj. ako dodamo jos atributa, one ce doci u 5NF ali to ne smeta nista.
2) Tabele u BCNF:Simptom, BolestSimptom, PreparatSimptom ( takodje u 5NF). Ako tabelama BolestSimptom i PreparatSimptom kasnije dodamo jos atributa, treba proveriti da li svaki doati atribut zavisi od celog kluca i od niceg drugog, da se ne vratimo u 2NF, zbog slozenih klucva.

Tabela Preparat je malo sumnjiva, ali nisam siguran 100%, zavisi od prirode problema. Buni me kolona NezeljenoDejstvo. lekovi (preparati) gneralno imaju dugacku listu nezeljenih dejstava, pa je moguce da ovde imamo problema sa ponavljajucim grupama. Na primer:
Code:

[PreparatID]    [NazivPreparata]    [UticajPreparata]    [NezeljenoDejstvo]
--------------------------------------------------------------------------------------------------------------------------------------
X                Xanax                Jak                    glavobolja, pospanost, suicidalne misli, povisen krvni pritisak, razjeda jetru


Ako je kao u primeru, onda imamo problem, Zbog ponavlajucih grupa, tabela ne predstavlaj relaciju. Da bi ucinili da tabela predstavlja relaciju, moramo se resiti ponavlajucih grupa, na opisani nacin. NAjverovatnije je da ce taj korak dovesti do cepanja tabele u dve ili tri, koje ce sve biti u BCNF, i verovatno 5NF.

Medjutim, treba znati da normalizacija <=> dobar dizajn, iako los dizajn cesto ima za koren nedovoljan stepen normalizacije. Isto tako, kad ste upotrebom ER dijagrama dosli do normalizovane baze, tu ni izdaleka nije kraj posla. Nazalost, vecina ljudi tu stane i zato su E.F. Codd i C.J. Date bili veliki protivnici ER metoda, ali su bitku izgubili. Njihova poenta je bila, a vazi i danas, normalizacija ne znaci uvek i dobar dizajn i nikada nije dovoljna da bi dizajn bio dobar. Tehnika ER dijagrama nije pogodna za dokumentovanje i prikaz vaznih ogranicenja koja treba da vaze u bazi, pa se zbog toga ta ogranicenja najcesce potpuno zaboravlaju ili ignorisu. ER dijagrami su odlicna tehnika za postavljanje JEDNE vrste ogranicenja, FOREIGN KEYS, ali za sve ostalo je nedovoljno. Koje kolone smeju a koje ne smeju biti NULL, ima li ogranicenja na nivou tabele, koja nisu FK, ima li ogranicenja na pojedinacnim kolonama (>0, samo slova, samo brojevi i slova, struktura e-mail adrese...)

Postoji i jedna cela klasa ogranicenja koja zahtevaju da bazu dovedete do BCNF ili 5NF, i da onda uradite neke stvari koje efektivno skidaju stepen normalizacije, pa formalno gledano vi sidjete na 2NF ili jos cesce na 1NF. To medjutim ne smeta, jer samo dodajemo nova ogranicenja, a ne ponistavamo ona koja smo postavili normalizacijom. Ako nekog zanima, mozemo o tome da pricamo, ili da stavim text na blog 'Baze Podataka'. Iz te grupe ogrnicenja dolazi ona moja (ne)cuvena prica o promenama stanja, vremenskim ogranicenjima i slicno.

Ako nije bilo bas premnogo dosadno, mozemo da objasnimo kako se ER dijagrami brzo crtaju i tacno, na osnovu relacija koje slede iz opisa sistema. Ovaj primer sa lekovima je dobar za tako nesto.









[ Getsbi @ 07.06.2015. 19:21 ] @
....." Tabela Preparat je malo sumnjiva, ali nisam siguran 100%, zavisi od prirode problema. Buni me kolona NezeljenoDejstvo. lekovi (preparati) gneralno imaju dugacku listu nezeljenih dejstava, pa je moguce da ovde imamo problema sa ponavljajucim grupama. Na primer: "

Što se tiče neželjenih dejstava, Zidar je u pravu. Mogu da se ponavljaju, pa sam dodao još jednu tabelu i proširio model.
[ BiloKoje @ 07.06.2015. 20:51 ] @
Nije li bolje da se relacija Preparat - Neželjeno dejstvo postavi kao i relacija Preparat - Simptom? Jedan lek može imati više neželjenih efekata a više lekova može imati isti neželjeni efekat. Dakle, potrebna je međutabela Preparati-Neželjena dejstva.
[ Getsbi @ 08.06.2015. 06:05 ] @
Citat:
BiloKoje: Nije li bolje da se relacija Preparat - Neželjeno dejstvo postavi kao i relacija Preparat - Simptom? Jedan lek može imati više neželjenih efekata a više lekova može imati isti neželjeni efekat. Dakle, potrebna je međutabela Preparati-Neželjena dejstva.


Pitanje je na mestu, a odgovor bi bio:
Možda, ako je od interesa za poslovni problem informacija: Koji sve preparati imaju ista neželjena dejstva. Međutim, to je po mom mišljenju sekundarna informacija za ovaj zadatak.
Uz prošireni broj atributa moći će da se odštampaju uputstva za upotrebu, koja su sastavni deo svakog pakovanja leka-preparata.

Ograničio sam se na zadatak iz prve poruke i ono što sam razumeo kao zahtev. Kad sam malo bolje pročitao jedno takvo štampano uputstvo (nakon Zidareve sugestije), broj mogućih zahteva za informacijama se povećao:
1. Šta je konkretni preparat i čemu je namenjen.
2. Šta treba znati pre uzimanja preparata.
3. Kako se preparat upotrebljava.
4. Moguća neželjena dejstva.
5. Kako čuvati preparat.
6. .........................

Sve ove informacije su manje-više opisnog karaktera.

Ono što zadatku nedostaje je funkcionalni model. Iz njega bi se videlo gde treba stati sa informacionim modelovanjem, odnosno šta je granica zadatka. Bez toga svako od nas može da proširi ovaj informacioni model po svojoj želji i saznanjima.


PS.
Što duže gledam model sve mi se manje dopada. Možda bismo mogli da OpisNeželjenogDejstva postavimo kao skup ili kombinaciju više njih i formatiramo kao memo polje.

[Ovu poruku je menjao Getsbi dana 08.06.2015. u 09:21 GMT+1]
[ BiloKoje @ 08.06.2015. 13:59 ] @
Tipično, Zidar je pomenuo neželjeno dejstvo, ti si ubacio u model, ja, iako sam pročitao sve, a tek je nekoliko postova, nisam konstatovao da u uvodnom postu nema zahteva po pitanju neželjenog dejstva. Da nisi naglasio sme bih da se opkladim da je to jedan od zahtevanih zadataka.
Kao i uvek, najbitnije je da se dobro raspravi šta je zadatak, šta je cilj projekta, pa se fokusirati na to, a i baza može imati nusprodukte, korisne ili ne.
Ako se unose neželjeni efekti, verovatno bi i kod njih išao i intenzitet. Dakle, kolega Fox028 je na potezu.