Dizze twa ienfâldige regels sille helpe it normearjen fan jo database
Earste Normal Form (1NF) pleatst de basisregels foar in organisearre databank:
- Elk meitsje duplicative kolommen út deselde tabel.
- Stel iepen tabellen foar elke groep relatearre data en identifyearje elke rige mei in unyk kolom (de primêre kaai).
Wat dogge dizze regels betsjutte by it konsultearjen fan it praktyske ûntwerp fan in database? It is eins krekt ienfâldich.
1. Ferwiderje duplikaasje
It earste regel bepaalt dat wy datum net duplikearje moatte yn deselde rige fan in tabel. Binnen de database-mienskip wurdt dit konsept as de atomiteit fan in tafel neamd. Tafels dy't dit regel hâlde, wurde as atomysk sein. Litte wy dit prinsipe ûndersiikje mei in klassike foarbyld: in tabel binnen in humoristyske database dat de manager-ûndersteande relaasje bewarret. Foar 't doel fan ús foarbyld bringe wy it bedriuwsregel yn' e hichte dat elke manager ien of mear subordinate hawwe kin, wylst elts ûndersteande allinich ien behearder hawwe.
Intuitively, as jo in list of spreadsheet meitsje om dizze ynformaasje te folgjen, kinne wy in tabel meitsje mei de folgjende fjilden:
- Behearder
- Subordinate1
- Subordinate2
- Subordinate3
- Subordinate4
Tink derom op it earste regel oplein troch 1NF: Helje duplikaat kolommen út deselde tabel. Faaks binne de kolommen ûnderwerp1-subordinate4 duplikaat. Nim in momint en probearje de problemen dy't makke binne troch dit senario. As in behearder allinich ien ûndersteande hat, binne de Spesjale subordinate2-subordinate4 justjes ferplichte opslachromte (in kostbere database-commodity). Fierders foarkom it gefal dêr't in manager al 4 ûndersteld hat - wat bart as sy op in oare meiwurker nimt? De hiele tabelstruktuer soe feroare wêze.
Op dit punt komt in twadde ljochte idee meastal oan databankommissarissen: Wy wolle net mear as ien kolom hawwe en wy wolle in fytsere bedrach fan opslach fan data oanmeitsje. Litte wy dit sa besykje:
- Behearder
- Underwerp
En it ûnderwerpfjild soe meardere yngongen hawwe yn 'e foarm "Mary, Bill, Joe".
Dizze oplossing is tichter, mar it falt ek koarte fan it mark. De subordinate kolom is noch duplikatyf en net-atoom. Wat bart as wy in subordinate tafoegje of fuortsmite moatte? Wy moatte de hiele ynhâld fan 'e tafel lêze en skriuwe. Dat is net in grut bedrach yn dizze situaasje, mar wat as ien manager mei hûndert meiwurkers hie? Ek it komplisearret it proses fan it selektearjen fan gegevens fan de database yn takomstige fragen.
Hjir is in tafel dy't de earste regel fan 1NF befettet:
- Behearder
- Subordinate
Yn dit gefal hat elke subordinate ien inkele yngong, mar behearder kinne meardere yntekenings hawwe.
2. Identifiearje de Primary Key
No, wat oer de twadde regel: elke rige identifisearje mei in unyk kolom of set fan kolommen (de primêre kaai )? Jo kinne in sjogge nei de hjirboppe tabel en befetsje it gebrûk fan de ûndersteande kolom as in primêre kaai. Yn 't feil is de ûnderrinnende kolom in goeie kandidaat foar in primêre kaai, mei it feit dat ús bedriuwregels oantsjutte dat elk subordinate mar ien behearder hawwe. De gegevens dy't wy keazen hawwe om yn ús tabel te reservearjen, makket dat in minder as ideale oplossing. Wat bart as wy in oare meiwurker neamd Jim? Hoe meitsje wy syn behearder-ûndersteande relaasje yn 'e database?
It is it bêste om in echt unyk identifier te brûken (lykas in meiwurker ID) as primêre kaai . Us lêste tafel soe dit folgje:
- Manager ID
- Subordinate ID
No, ús tafel is yn 'e earste gewoane foarm! As jo graach fierder learje oer normalisearring, lês de oare artikels yn dizze searje: