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