Losa je ideja da se u jednu kolonu trpaju raznorodni podaci. Na papirnom obrascu, moguce je ustu kolonu upisati nekad datum, nekad adresu a nekad radnu jedinicu, a nekad bilo sta. Covek kad pogleda, zna sta je sta. Medjutim, kompjuter nije toliko pametan. Sam si se uverio da ne ide da trpas razlicite podatke u jedno isto polje. Imas nekoliko opcija, od kojih su neke bolje neke losije. Ne mozemo da kazemo sta je bolje, jer ne poznajemo situaciju. Ovo su ti opcije:
1. uvedes 4 kolone
- string - sta ti je ovaj string? bilo koji tekst? Komentar?
- datum
- naziv i adresa
- broj Organizacijske jedinice
Onda uopises sta ti treba gde treba. Ovo generalno nije dobra opcija, jer:
- ce neka polja ostati prazna (NULL) i nikad ne znas da li su prazna zato sto treba da budu prazna ili zato sto smo zaboravili podatke, ili ih nemamo. Jos gore je kad podaci postanu dostupni kasnije.
- moze se desiti da je dozvoljeno da samo jedno od ovih polja bude popunjeno, a ostala da su NULL. Treba ti CONSTRAINT koji dozvoljava samo jedno polje da je popunjeno. Moze da se napise, ako treba. Ovo je bolja situacija nego kad polja mogu biti proizvoljno popunjena.
Resenje 2: Uvedes dodatnu tabelu, Oznaka pa imas
GlavnaTabela (ID, datum)
Razvodjenje (ID, VrsatRazvodjenja, Razvodjenje, DatumRazvodjenja) gde se ID koristi u FK
Ovo je malo bolje nego 4 kolone u istoj tabeli. Unosis sta imas, kad imas. Ovako .Ovako bi zgledalo:
Code:
GlavnaTabela:
ID Datum
------------
1, '20080101'
Razvodjenje:
ID, VrsatRazvodjenja, Razvodjenje, DatumRazvodjenja
--------------------------------------------------------------------------
1, 'Naziv i Adresa', 'Narodnih heroja 115, Beograd, srbija', '20080101'
1, Broj Org. Jedinice', 115, '20080101'
Problem sa ovim je sto u koloni Razvodjenje imas podatke razlicitog tipa, datumske, numericke i tekstualne. To stvara probleme pri validaciji. Naravno, lako je reci 'neka paze sta unose'. Medjutim, tako ne rade profesionalci. Profesionalci moraju da stite integritet podataka i od samog korisnika.
Reasnje 3:
Za svaki tip razvodjenja (ima ih tacno 4) uvedes po jednu tabelu, slicno kao u (2). Ovog puta nema mesanja tipova podataka i lako se uspostavljaju CONSTRAINTS.
IMa jos varijanti, ove tri su mi pala na pamet. Dalja analiza je nemoguca bez poznavanja biznis procesa koji se pokusava podrzati modelom baze podatka.
Malo sam pod utiskom da je sitem dizajniran doslovnim preslikavanjem papirnog obrasca. To e moze raditi u Excelu, ali ne i u SQL bazi podataka.