Ўвод базы дадзеных у другой нармальнай форме
За апошні месяц мы разгледзелі некалькі аспектаў нармалізацыі табліцы базы дадзеных. Па-першае, мы абмеркавалі асноўныя прынцыпы нармалізацыі баз дадзеных. У мінулы раз мы разгледзелі асноўныя патрабаванні, выкладзеныя ў першай нармальнай форме (1НФ). Цяпер, давайце працягнем наша падарожжа і ахопліваюць прынцыпы другі нармальнай форме (2НФ).
Нагадаем, агульныя патрабаванні 2НФ у:
- Выдаліць падмноства дадзеных, якія адносяцца да некалькіх радках табліцы і змясціць іх у асобных табліцах.
- Стварэнне адносін паміж гэтымі новымі табліцамі і іх папярэднікаў за кошт выкарыстання знешніх ключоў.
Гэтыя правілы могуць быць сумаваныя ў простым сцвярджэнні: 2NF спрабуе паменшыць колькасць залішніх дадзеных у табліцы, здабываючы яго, змясціўшы яго ў новай табліцы (ы) і стварэння сувязяў паміж гэтымі табліцамі.
Давайце паглядзім на прыклад. Уявіце, інтэрнэт-крама, які падтрымлівае інфармацыю пра кліента ў базе дадзеных. Яны маглі б адну табліцу пад назвай Кліенты з наступнымі элементамі:
- CustNum
- Імя
- Прозвішча
- адрас
- горад
- стан
- ZIP
Кароткі агляд гэтай табліцы паказвае невялікая колькасць залішніх дадзеных. Мы захоўванне «Sea Cliff, NY 11579» і «Маямі» 33157 запісаў два разы. Цяпер, гэта можа здацца не занадта шмат дабаўленай памяці ў нашым простым прыкладзе, але ўявіце сабе, выдаткаванае марна месца, калі б мы мелі тысячы радкоў у нашай табліцы. Акрамя таго, калі паштовы індэкс для Sea Cliff быў змяніць, мы павінны былі б зрабіць гэта змена ў многіх месцах па ўсёй базе даных.
У 2НФ-сумяшчальнай структуры базы дадзеных, гэтая залішняя інфармацыя здабываецца і захоўваецца ў асобнай табліцы. Наша новая табліца (назавем яго маланкі) можа мець наступныя поля:
- ZIP
- горад
- стан
Калі мы хочам быць супер-эфектыўным, мы можам нават запоўніць гэтую табліцу загадзя - паштовае аддзяленне прадастаўляе каталог усіх дапушчальных кодаў ZIP і іх горад / дзяржаўных адносін. Вядома, вы сутыкнуліся з сітуацыяй, дзе выкарыстоўвалі гэты тып базы дадзеных. Хтосьці прымае заказ мог бы спытаць Вас за паштовы індэкс, а затым ведаў горад і заявіць вы тэлефануеце. Гэты тып размяшчэння памяншае памылку аператара і павышае эфектыўнасць.
Цяпер, калі мы выдалілі дубляваныя дадзеныя з табліцы Customers, мы задаволены першае правіла другі нармальнай формы. Нам усё яшчэ трэба выкарыстоўваць знешні ключ , каб звязаць дзве табліцы разам. Мы будзем выкарыстоўваць ZIP код (першасны ключ з табліцы Маланкі) , каб стварыць гэтыя адносіны. Вось наша новая табліца кліентаў:
- CustNum
- Імя
- Прозвішча
- адрас
- ZIP
Цяпер мы мінімізавалі колькасць залішняй інфармацыі, якая захоўваецца ў базе дадзеных і наша структура ў другой нармальнай форме!
Калі вы хочаце, каб пераканацца, ваша база дадзеных нармалізаваная, даследаваць нашы іншыя артыкулы ў гэтай серыі:
- Асновы Нармалізацыя базы дадзеных
- Паклаўшы базы дадзеных у першай нармальнай форме
- Паклаўшы базы дадзеных у другой нармальнай форме
- Паклаўшы базы дадзеных у трэцяй нармальнай форме