Normalisasyon (database)
Ang artikulong ito ay nangangailangan pa ng mga link sa ibang mga artikulo upang makatulong isama ito sa ensiklopedya. (Marso 2022) |
Sa database, ang normalisasyon ay isang pormal na prosesong matematiko na nagtitiyak na ang bawat entity ay magiging representasyon ng isang relation. Sa isang normalized database maiiwasan ang anomalya habang binabago ang data at nalilimitahan ang pagkakaroon ng pag uulit ulit ng data na hindi magugulo ang kaubuuan ng impormasyon.
Depinisyon
[baguhin | baguhin ang wikitext]Ang normalisasyon ang unang hakbang sa pagdidisenyo ng maayos at mahusay na sistema ng impormasyon. Ito ang proseso ng pag-ayos ng pagkagrupo-grupo ng datos base sa pagkakaugnay ugnay ng mga ito. Ang pinaka layunin nito ay makahanap ng paraan ng paggrupo sa impormasyon upang maging pinakamadaling maimanipula at madaling bumagay sa iba't ibang pagpoproseso sa mga ito.
Buhat sa isang sistema ng impormasyon ay dadaanan ang iba’t ibang normal form hanggang makadating sa pangatlong normal form kung saan handa nang trabahuhin ito patungo sa paggawa ng information system. Ang datos na nasa pangatlong normal form ay nasa ikalawa, una, at nasa zeroth normal form bilang unang kailangan bago marating ang normal form tulad ng datos na nasa ikalawang normal form ay nasa una at zeroth normal form at patuloy pa. Maaaring di na pagdaanan ang bawat isang hakbang ng normalisasyon at dumiretso na sa ikatlong normal form kung kaya na itong gawin. Ang mga hakbang na ito ay gabay lamang para sa sistematikong pagdating sa ikatlong normal form.
Mga normal form
[baguhin | baguhin ang wikitext]Iminungkahi ni E.F.Codd and naunang tatlong normal forms;
1NF Ang first normal form ay nagsasaad na ang mga tuples (rows) sa isang relation(table) ay kinakailangan maging natatangi (unique), at ang attributes ay kinakailangang maging atomic
ang unique rows ay maaaring gawin sa pamamagitan ng unique key para sa table.
2NF Para sa isang candidate key, lahat ng non-key attribute ay kinakalingang nakadepende sa buong candidate key
3NF Lahat ng non-key attributes ay kinakilangang maging nakadepende sa candidate key non-transitively
Mayroon pang ibang normal forms maliban sa naunang tatlo.
Zeroth Normal Form
[baguhin | baguhin ang wikitext]Ang zeroth normal form ay ang pinkaunang basehan ng pagnonormalize. Kahit anong grupo ng impormasyon ay masasabing nasa zeroth normal form. Gamitin natin ang halimbawa sa ibaba ng isang resibo:
Receipt No. | Date | Buyer | Sales Agent | Counter No. | Item Code | Item | Quantity |
---|---|---|---|---|---|---|---|
1 | 1/1/11 | Juan | Juana | 01 | A | Mansanas | 3 |
B | Saging | 5 | |||||
2 | 1/1/11 | Miguel | Angelo | 04 | B | Saging | 3 |
C | Tinapay | 1 | |||||
D | Tubig | 2 | |||||
3 | 1/1/11 | Maria | Juana | 01 | A | Mansanas | 1 |
C | Tinapay | 1 | |||||
E | Mangga | 1 | |||||
4 | 1/2/11 | Paulo | Bea | 03 | D | Tubig | 1 |
Unang Normal Form
[baguhin | baguhin ang wikitext]Ang unang normal form ay dapat walang umuulit na grupo ng datos. Kung meron man ay dapat ilipat sila sa sariling grupo ng datos kung saan kokopyahin ang tinatawag na “primary key” o ang pinakabasehan kung saan magiging katangi-tangi ang datos na iyon.
Base sa halimbawa, sa bawat resibo ay maraming posibleng bilhin ang isang mamimili. Umuulit ang item code, item, at quantity sa bawat receipt number. Kung gawing unang normal form ay mahihiwalay sa dalawang grupo ng datos ang halimbawa kung saan ang receipt number ang tatawaging primary key ng unang grupo, at magiging dalawa o concatenated ang primary key ng pangalawang grupo dahil nakadepende ito sa item code bukod sa receipt number:
Receipt No. | Date | Buyer | Sales Agent | Counter No. |
---|---|---|---|---|
1 | 1/1/11 | Juan | Juana | 01 |
2 | 1/1/11 | Miguel | Angelo | 04 |
3 | 1/1/11 | Maria | Juana | 01 |
4 | 1/2/11 | Paulo | Bea | 03 |
Receipt No. | Item Code | Item | Quantity |
---|---|---|---|
1 | A | Mansanas | 3 |
1 | B | Saging | 5 |
2 | B | Saging | 3 |
2 | C | Tinapay | 1 |
2 | D | Tubig | 2 |
3 | A | Mansanas | 1 |
3 | C | Tinapay | 1 |
3 | E | Mangga | 1 |
4 | D | Tubig | 1 |
Pangalawang Normal Form
[baguhin | baguhin ang wikitext]Bukod sa dapat nasa unang normal form, ang pangalawang normal form ay tinitingnan ang mga concatenated key at sinisiguradon sa buong concatenated key nakadepende ang lahat ng nasa grupo nito. Kung hindi ay dapat gawan ito ng sariling grupo kasama ng sarili nitong primary key.
Base sa halimbawa sa unang grupo, hindi naman concatenated ang primary key nito ngunit sa pangalawang grupo ay concatenated. Sa kasong ito, ang item ay nakadepende lamang sa item code at hindi na kinakailangan ang receipt number. Kung gawing pangalawang normal form ay mahihiwalay nang ganito ang pangalawang grupo, kung saan ang primary key ng bago at pangatlong grupo ay ang item code:
Receipt No. | Date | Buyer | Sales Agent | Counter No. |
---|---|---|---|---|
1 | 1/1/11 | Juan | Juana | 01 |
2 | 1/1/11 | Miguel | Angelo | 04 |
3 | 1/1/11 | Maria | Juana | 01 |
4 | 1/2/11 | Paulo | Bea | 03 |
Receipt No. | Item Code | Quantity |
---|---|---|
1 | A | 3 |
1 | B | 5 |
2 | B | 3 |
2 | C | 1 |
2 | D | 2 |
3 | A | 1 |
3 | C | 1 |
3 | E | 1 |
4 | D | 1 |
Item Code | Item |
---|---|
A | Mansanas |
B | Saging |
C | Tinapay |
D | Tubig |
E | Mangga |
Pangatlong Normal Form
[baguhin | baguhin ang wikitext]Bukod sa dapat nasa pangalawang normal form, ang pangatlong normal form ay dapat din sundan ang patakaran na ang lahat ng datos sa loob ng isang grupo ay dapat nakadepende sa primary o concatenated key lamang ng kaniyang grupo. Kung hindi ay dapat gawan ng sariling grupo ang mga eksepsiyon kasama ng sarili nitong primary key.
Base sa halimbawa, sa unang grupo, ang sales agent ay nakadepende lamang sa counter number at hindi sa primary key nitong receipt number. Kailangan itong ihiwalay sa pang-apat na grupo kung saan ang counter number ang magiging primary key ng sales agent. Kunwari ay napagalam nating sa counter number 2 ay ang sales agent na si Mario ang tagapangasiwa, kasama siya sa pang-apat na grupo. Magmumukhang ganito ang ikatlong normal form:
Receipt No. | Date | Buyer | Counter No. |
---|---|---|---|
1 | 1/1/11 | Juan | 01 |
2 | 1/1/11 | Miguel | 04 |
3 | 1/1/11 | Maria | 01 |
4 | 1/2/11 | Paulo | 03 |
Receipt No. | Item Code | Quantity |
---|---|---|
1 | A | 3 |
1 | B | 5 |
2 | B | 3 |
2 | C | 1 |
2 | D | 2 |
3 | A | 1 |
3 | C | 1 |
3 | E | 1 |
4 | D | 1 |
Item Code | Item |
---|---|
A | Mansanas |
B | Saging |
C | Tinapay |
D | Tubig |
E | Mangga |
Counter No. | Sales Agent |
---|---|
01 | Juana |
02 | Mario |
03 | Bea |
04 | Angelo |
Konklusyon
[baguhin | baguhin ang wikitext]Ang ganitong paraan ng pagsasaayos ng datos ay napakahalaga para sa paggawa ng software sapagkat kailangan ng ganitong klase ng mainam na klasipikasyon para maging malinaw ang pagkaugnay-ugnay ng datos at maayos ang lohikal na pagtakbo ng sistema. Ito ri’y malaking tulong para sa madaliang pagdagdag o kaya’y pag-iba ng impormasyon kung kailangan. Halimbawa ay babaguhin mo ang item code A para ito ay ubas imbis na mansanas. Mas madali mo itong mababago sa iyong information system kapag normalized na ang iyong datos sapagkat ang ikatlong grupo nalang kailangan mong baguhin. Kung sa zeroth normal form ka magmumula, kailangan mo pang baguhin ang bawat pagkakataon na may bumili ng mansanas.