Normalizimi i databazës
Ky artikull ose seksion duhet të përmirësohet sipas udhëzimeve të Wikipedia-s. Ju lutemi ndihmoni edhe ju në përmirësimin e këtij artikulli. |
Ky artikull nuk citon asnjë burim, prandaj mund të mos jetë i saktë. |
Normalizimi i databazës është procesi i organizimit të atributeve dhe tabelave të një databaze relacionale për minimizimin e përseritjes së të dhënave. Normalizimi përfshin dekompozimin e një tabele në tabela më pak redudante(dhe më të vogla) por pa e humbur informacionin; definimin e çëlesave të huaj në një tabele të vjetër që i referencohen çëlesave primarë të tabelave të reja.Objektivi është të izolohen të dhënat ashtu që shtimi,fshirja dhe modifikimi i një atributi mund të bëhet vetëm në një tabele dhe të përcillet tek të gjitha tabelat tjera duke përdorur çëlesat e huaj. Edgar F.Codd, krijuesi i modelit relacional, paraqiti konceptin e normalizimit dhe atë se çka e njohim sot si Forma parë e normalizimit(1NF) në vitin 1970.[1] Codd definoj gjithashtu edhe Formën e dytë(2NF) dhe Formën e tretë normale(3NF) në vitin 1971,[2] ndërsa Codd dhe Raymond F.Boyce definuan Formën normale të Boyce-Codd-it në vitin 1974.[3] Jozyrtarisht, një databazë shpesh e përshkruajm si të normalizuar nëse është në Formën e tretë normale. Shumica e tabelave 3NF janë të pastruara nga anomalitë e insertimit,modifikimit dhe fshirjes së të dhenave.
Modeli relacional ndanë dizajnin logjikë nga dizajni fizikë: DBMS performanca është çështje e përdorimit të indeksave, konkretizimit të pamjeve, baferave të mëdhenjë, etj.Nuk është çështj e të ndryshuarit dizajnin lokal.
Një shembull tipik i normalizimit është së një ID-ja unike e një entiteti ruhet kudo në sistem por emri tij përmbahet në vetëm një tabele.Emri mund të ndryshohet më lehtë në një rreshtë të një tabele.Modifikim tipik i një shembulli të këtillë do të ishte ndryshimi i emrit të Universitetit Haxhi Zeka në Universiteti i Pejës.Ai modifikim do të ndodhte vetëm në një vend dhe menjëherë do të shfaqej emri i ndryshuar përgjatë sistemit.
Objektivat
RedaktoObjektiv bazë i formës së parë të normalizimit i definuar nga Codd-i në 1970 ishte autorizimi i të dhenave që të krijohen pyetsorë në to dhe manipulimi i tyre duke përdorur një "nën-gjuhë univerzale e të dhënave" e bazuar në "logjikën e renditjes së të parit". (SQL është një shembull i një nën-gjuhë të tillë, megjithëse Coddi e cilësonte me të meta.)[4]
The objectives of normalization beyond 1NF (First Normal Form) were stated as follows by Codd: Objektivat e normalizimit përtej 1NF(Formës së parë të normalizimit) ishin deklaruar nga Codd si në vijim:
- 1. Lirimi i kolekcioneve të relacioneve nga insertimet e padëshirueshme,pavarësia e modifikimit dhe fshirjes;
- 2. Reduktimi i nevojës për ristrukturimin e kolekcioneve të relacioneve, pasi të shtohen të dhëna të reja, dhe njëkohësisht të ngritet jetë-gjatësia e programit;
- 3. Krijimi i nje modeli relacional sa më informativ për përdoruesit;
- 4. Krijimi i kolekcioneve të relacioneve neutrale për statistikat e pytësoreve, ku statistikat janë përgjegjëse të ndryshojnë me kalimin e kohës.
— E.F. Codd, "Normalizimi i mëtutjshem i modelit relacional të databazës"[5]
Seksionet më poshtë japin detaje për secilen nga këto objektiva.
Lirimi i databazës nga anomalit e modifikimit
RedaktoKur kryhet një qëllim për modifikim(freskim,insertim,apo fshirje nga) një tabelë, efekte anësore të padëshirueshme mund të ndodhin.Jo të gjitha tabelat mund të vuajn nga këto efekte anësore; më tepër efektet anësore mund të rrjedhin vetëm në tabelat që nuk kanë qenë të normalizuara sa duhet. Një tabelë jo e normalizuar sa duhet mund te këtë një apo më shumë nga karakteristikat në vijim:
- Informacioni i njejtë mund të shprehet në rreshta të shumtë; kështu rifreskimet në tabelë mund të rezultojn në mospërputhje logjike.Për shembull, çdo rekord tek tabela "Aftësitë e punëtorit" mund të përmbajë një ID të punëtorit,adresë të punëtorit dhe aftësit e tij; kështu një ndryshim i adresës për një punëtor do të duhet të aplikohet tek rekorde të shumta(një për çdo aftësi të punëtorit).Nëse rifreskimi i tabelës nuk bartet me sukses, kështu, adresa e punëtorit është ndryshuar në disa rekorde por jo tek disa tjera, atëherë tabela ëshë në gjendje jo të rregullt.
Në veçanti, tabela ofron përgjigje konfliktuoze tek pytja se cila është adresa e saktë e atij punëtori.Ky fenomen njihet si anomalia e rifreskimit.
- Ekzistojn kushte në të cilat fakte të sigurta nuk mund të regjistrohen fare.Për shembull, çdo rekord në tabelën "Fakulteti dhe kurset e tij" mund të përmbaj një ID të fakultetit, emrin e fakultetit, datën e themëlimit te fakultetit, dhe kodin e kursit-kështu ne mund të regjistrojm detajet e cilitdo anëtari të fakultetit që ligjeron së paku një kurs, por nuk mund të regjistrojm detaje të një anëtari të sapo punësuar që ende nuk është caktuar të ligjerojë ndonjë kurs përpos së të vendosim vlerën e kursit në NULL(pa vlerë).Ky fenomen njihet si anomalia insertimit.
- Nën kushte të caktuara, fshirja e të dhënave që përfaqsojn fakte të sigurta ka nevojë për fshirjen e të dhënave që përfaqsojn komplet fakte tjera.Tabela e "Fakulteti dhe kurset e tij" përshkruante në shembullin e kaluar demët nga kjo anomali, në qoftë se një anëtarë i fakultetit përkohësisht ndërpren ligjerimin e ndonjë kursi, ne duhet ta fshijm rekordet e fundit në të cilat ai anëtarë paraqitet, në mënyzë efektive të fshijm anëtarin e fakultetit, përpos nëse vendosim kodin e kursit në null në atë rekord.Ky fenomen njihet si anomalia fshirjes.
Minimizo ridizajnimin gjatër zgjërimit të strutkurës së databazës
RedaktoKur një databazë e normalizuar totalisht zgjerohet për t'u bërë gati të lejoj të dhëna të reja, aspektet para-ekzituese të strukturës së tabelës mund të mbesin kryesisht të pandryshuara apo totalisht të pandryshuara. Si rezultat, aplikcaionet që ndërveprojn me databazën janë minimalisht të afektuara.
Shembull
RedaktoKrijimi i pytësorve dhe manipulimi me të dhëna brenda një strukture të të dhënave që nuk është e normalizuar, si prezantimi i transakcioneve të kredit kartelave të konsumatorëve në tabelën e më poshtme, përfshin më shumë kompleksitet sesa që është e nevojshmeË
Konsumatori | Transakcioni | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Blend |
| ||||||||||||
Drilon |
| ||||||||||||
Arian |
|
Çdo konsumatori i korespondon një grupë i transkacioneve.Evaluimi i ndonjë pytësori lidhur me transakcioneve të konsumatorëve në përgjithësi do të përfshinte dy fazaË
- Shpaketimi i një apo më shum grupe të transkacioneve duke lejuar transakcionet individuale në një grup të ekzaminohen, dhe
- Derivimi i një rezultati të një pytësori bazuar në rezultatet e fazës së parë
Për shembull, në mënyrë që të gjejmë shumën totale të parave të transkacioneve të kryera në prill të vitit 2015 për të gjithë konsumatoret, sistemi duhet të dijë që së pari duhet të shpaketojë grupin e transakcioneve të secilit konsumatorë, atëherë t'i mbledh shumat e transakcioneve ku data e transakcionit është prill 2015.
Një nga mprehtësitë e Codd-it ishte se ky kompleksitet strukturor mundet gjithmonë komplet të largohet, duke na dhenë pytësor më të fuqishem dhe më fleksibil në mënyren se si ata formulohen(nga përdoruesit dhe aplikcationet) dhe evaluohen(nga DBMS).Forma e normalizuar e tabelës më lartë do të dukej kështu:
Konsumatori | Konsumatori ID |
---|---|
Blend | 1 |
Drilon | 2 |
Arian | 3 |
Konsumatori ID | Tr. ID | Data | Shuma |
---|---|---|---|
1 | 12890 | 14-shkurt-2015 | 87 |
1 | 12904 | 22-prill-2015 | 50 |
2 | 12898 | 11-prill-2015 | 21 |
3 | 12907 | 15-janar-2015 | 18 |
3 | 14920 | 20-prill-2015 | 70 |
3 | 15003 | 27-qershor-2015 | 60 |
Tani secili rreshtë përfaqson një transakcion individual, dhe DBMS mund të jap përgjigjen në interesat e përdoruesit, thjeshtë duke gjetur të gjithë rreshtat në datat e muajit prill, dhe duke mbledhur shumën e tyre. Verzioni i normalizuar i databazes e lejon përdoruesin të ndryshojë emrin e përdoruesit në një vend dhe na mbron nga gabimet që shfaqen nese emri gabohet në ndonjë rekord.
Shih edhe
RedaktoShënime dhe referenca
Redakto- ^ Codd, E.F. (qershor 1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM. 13 (6): 377–387. doi:10.1145/362384.362685. Arkivuar nga origjinali më 12 qershor 2007. Marrë më 12 qershor 2015.
{{cite journal}}
: Mungon ose është bosh parametri|language=
(Ndihmë!) - ^ Codd, E.F. "Further Normalization of the Data Base Relational Model". (Presented at Courant Computer Science Symposia Series 6, "Data Base Systems", New York City, May 24–25, 1971.) IBM Research Report RJ909 (August 31, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972.
- ^ Codd, E. F. "Recent Investigations into Relational Data Base Systems". IBM Research Report RJ1385 (April 23, 1974). Republished in Proc. 1974 Congress (Stockholm, Sweden, 1974). , N.Y.: North-Holland (1974).
- ^ Codd, E.F. Chapter 23, "Serious Flaws in SQL", in The Relational Model for Database Management: Version 2. Addison-Wesley (1990), pp. 371–389
- ^ Codd, E.F. "Further Normalization of the Data Base Relational Model", p. 34