database normalization tutorial
Този урок ще обясни какво е нормализиране на базата данни и различни нормални форми като 1NF 2NF 3NF и BCNF с примери за SQL код:
Нормализирането на базата данни е добре позната техника, използвана за проектиране на схема на база данни.
Основната цел на прилагането на техниката за нормализиране е да се намали излишъкът и зависимостта на данните. Нормализацията ни помага да разделим големи таблици на множество малки таблици, като дефинираме логическа връзка между тези таблици.
Какво ще научите:
- Какво е нормализиране на базата данни?
- Заключение
Какво е нормализиране на базата данни?
Нормализирането на базата данни или SQL нормализирането ни помага да групираме свързани данни в една единствена таблица. Всички атрибутивни данни или косвено свързани данни се поставят в различни таблици и тези таблици са свързани с логическа връзка между родителските и дъщерните таблици.
През 1970 г. Едгар Ф. Код излезе с концепцията за нормализация. Той сподели статия, наречена „Релационен модел на данни за големи споделени банки“, в която предложи „Първа нормална форма (1NF)“.
Предимства на нормализирането на СУБД
Нормализирането на базата данни предоставя следните основни предимства:
- Нормализирането увеличава последователността на данните, тъй като избягва дублирането на данни, като съхранява данните само на едно място.
- Нормализирането помага при групирането на подобни или свързани данни по същата схема, като по този начин се получава по-доброто групиране на данни.
- Нормализацията подобрява търсенето по-бързо, тъй като индексите могат да се създават по-бързо. Следователно, нормализираната база данни или таблица се използва за OLTP (онлайн обработка на транзакции).
Недостатъци на нормализирането на базата данни
Нормализацията на СУБД има следните недостатъци:
- Не можем да намерим свързаните данни за да речем продукт или служител на едно място и трябва да се присъединим към повече от една таблица. Това води до забавяне при извличането на данните.
- По този начин Нормализирането не е добра опция в транзакциите на OLAP (онлайн аналитична обработка).
Преди да продължим по-нататък, нека разберем следните термини:
- Обект: Обектът е обект от реалния живот, където данните, свързани с такъв обект, се съхраняват в таблицата. Примерът за такива обекти са служители, отдели, студенти и т.н.
- Атрибути: Атрибутите са характеристиките на обекта, които дават известна информация за Обекта. Например, ако таблиците са обекти, тогава колоните са техните атрибути.
Видове нормални форми
# 1) 1NF (Първа нормална форма)
По дефиниция обект, който няма повтарящи се колони или групи данни, може да се нарече Първа нормална форма. В първата нормална форма всяка колона е уникална.
Следва как би изглеждала таблицата на нашите служители и отдели, ако беше в първата нормална форма (1NF):
| empNum | фамилия | първо име | deptName | deptCity | deptCountry |
|---|---|---|---|---|---|
| 1001 | Андрюс | Джак | Сметки | Ню Йорк | Съединени щати |
| 1002 | Швац | Майк | Технология | Ню Йорк | Съединени щати |
| 1009 | Купа | Хари | HR | Берлин | Германия |
| 1007 | Харви | Паркър | Администратор | Лондон | Великобритания |
| 1007 | Харви | Паркър | HR | Лондон | Великобритания |
Тук всички колони на таблици на служители и отдели са обединени в едно и няма нужда от свързване на колони, като deptNum, тъй като всички данни са налични на едно място.
Но таблица като тази с всички задължителни колони в нея би била не само трудна за управление, но и трудна за извършване на операции, а също и неефективна от гледна точка на съхранението.
# 2) 2NF (втора нормална форма)
По дефиниция обект, който е 1NF и един от неговите атрибути се дефинира като първичен ключ, а останалите атрибути зависят от първичния ключ.
Следва пример за това как биха изглеждали таблицата на служителите и отдела:
Таблица на служителите:
| empNum | фамилия | първо име |
|---|---|---|
| 1001 | Андрюс | Джак |
| 1002 | Швац | Майк |
| 1009 | Купа | Хари |
| 1007 | Харви | Паркър |
| 1007 | Харви | Паркър |
Таблица на отделите:
| deptNum | deptName | deptCity | deptCountry |
|---|---|---|---|
| 1 | Сметки | Ню Йорк | Съединени щати |
| две | Технология | Ню Йорк | Съединени щати |
| 3 | HR | Берлин | Германия |
| 4 | Администратор | Лондон | Великобритания |
Таблица EmpDept:
| empDeptID | empNum | deptNum |
|---|---|---|
| 1 | 1001 | 1 |
| две | 1002 | две |
| 3 | 1009 | 3 |
| 4 | 1007 | 4 |
| 5 | 1007 | 3 |
Тук можем да забележим, че сме разделили таблицата във формата 1NF на три различни таблици. таблицата Служители е обект за всички служители на дадена компания и нейните атрибути описват свойствата на всеки служител. Първичният ключ за тази таблица е empNum.
По същия начин таблицата на отделите е обект за всички отдели в дадена компания и нейните атрибути описват свойствата на всеки отдел. Първичният ключ за тази таблица е deptNum.
В третата таблица сме комбинирали първичните ключове на двете таблици. Първичните ключове на таблиците Служители и отдели са посочени като външни ключове в тази трета таблица.
Ако потребителят иска изход, подобен на този, който имахме в 1NF, тогава потребителят трябва да се присъедини към всичките три таблици, използвайки първичните ключове.
Примерна заявка ще изглежда както е показано по-долу:
SELECT empNum, lastName, firstName, deptNum, deptName, deptCity, deptCountry FROM Employees A, Departments B, EmpDept C WHERE A.empNum = C.empNum AND B.deptNum = C.deptNum WITH UR; # 3) 3NF (трета нормална форма)
По дефиниция таблица се разглежда в трети нормал, ако таблицата / обектът вече е във втората нормална форма и колоните на таблицата / обекта не са преходно зависими от първичния ключ.
Нека разберем непреходната зависимост с помощта на следния пример.
Кажете таблица с име, Клиентът има следните колони:
Клиентски номер - Първичен ключ, идентифициращ уникален клиент
Клиент ZIP - Пощенски код на населеното място, в което клиентът живее
CustomerCity - Град, в който клиентът пребивава
моите sql интервюта въпроси и отговори
В горния случай колоната CustomerCity зависи от колоната CustomerZIP, а колоната CustomerZIP зависи от CustomerID.
Горният сценарий се нарича преходна зависимост на колоната CustomerCity от CustomerID, т.е. първичен ключ. След като разберем преходната зависимост, нека сега обсъдим проблема с тази зависимост.
Възможно е да има възможен сценарий, при който се прави нежелана актуализация на таблицата за актуализиране на CustomerZIP до пощенски код на различен град, без да се актуализира CustomerCity, като по този начин базата данни се оставя в несъответстващо състояние.
За да разрешим този проблем, трябва да премахнем преходната зависимост, която би могла да бъде направена чрез създаване на друга таблица, да речем, таблица CustZIP, която съдържа две колони, т.е. CustomerZIP (като първичен ключ) и CustomerCity.
Колоната CustomerZIP в таблицата Customer е външен ключ към CustomerZIP в таблицата CustZIP. Тази връзка гарантира, че няма аномалия в актуализациите, при които се актуализира CustomerZIP, без да се правят промени в CustomerCity.
# 4) Нормална форма на Бойс-Код (3,5 нормална форма)
По дефиниция таблицата се счита за нормална форма на Бойс-Код, ако тя вече е в третата нормална форма и за всяка функционална зависимост между A и B, A трябва да бъде супер ключ.
Това определение звучи малко сложно. Нека се опитаме да го разчупим, за да го разберем по-добре.
- Функционална зависимост: Казва се, че атрибутите или колоните на таблица са функционално зависими, когато атрибут или колона на таблица уникално идентифицират друг атрибут (и) или колона (и) от същата таблица.
Например, колоната empNum или Номер на служител уникално идентифицира останалите колони като Име на служител, Заплата на служител и т.н. в таблицата на служителя. - Супер ключ: Един ключ или група от множество ключове, които могат еднозначно да идентифицират един ред в таблица, могат да бъдат наречени Супер ключ. Като цяло познаваме такива клавиши като Composite Keys.
Нека разгледаме следния сценарий, за да разберем кога има проблем с третата нормална форма и как нормалната форма на Бойс-Код идва на помощ.
| empNum | първо име | empCity | deptName | deptHead |
|---|---|---|---|---|
| 1001 | Джак | Ню Йорк | Сметки | Реймънд |
| 1001 | Джак | Ню Йорк | Технология | Доналд |
| 1002 | Хари | Берлин | Сметки | Самара |
| 1007 | Паркър | Лондон | HR | Елизабет |
| 1007 | Паркър | Лондон | Инфраструктура | Том |
В горния пример служителите с empNum 1001 и 1007 работят в два различни отдела. Всеки отдел има началник отдел. Може да има няколко ръководители на отдели за всеки отдел. Подобно на счетоводния отдел, Реймънд и Самара са двамата ръководители на отдели.
В този случай empNum и deptName са супер ключове, което предполага, че deptName е основен атрибут. Въз основа на тези две колони можем да идентифицираме всеки отделен ред по уникален начин.
Също така, deptName зависи от deptHead, което предполага, че deptHead е не-главен атрибут. Този критерий дисквалифицира таблицата от част от BCNF.
За да разрешим това, ще разделим таблицата на три различни таблици, както е споменато по-долу:
Таблица на служителите:
| empNum | първо име | empCity | deptNum |
|---|---|---|---|
| 1001 | Джак | Ню Йорк | D1 |
| 1001 | Джак | Ню Йорк | D2 |
| 1002 | Хари | Берлин | D1 |
| 1007 | Паркър | Лондон | D3 |
| 1007 | Паркър | Лондон | D4 |
Таблица на отдела:
| deptNum | deptName | deptHead |
|---|---|---|
| D1 | Сметки | Реймънд |
| D2 | Технология | Доналд |
| D1 | Сметки | Самара |
| D3 | HR | Елизабет |
| D4 | Инфраструктура | Том |
# 5) Четвърта нормална форма (4 нормална форма)
По дефиниция таблицата е в Четвърта нормална форма, ако няма две или повече независими данни, описващи съответния обект.
# 6) Пета нормална форма (5 нормална форма)
Таблица може да се разглежда в пета нормална форма само ако отговаря на условията за четвърта нормална форма и може да бъде разделена на множество таблици без загуба на данни.
Често задавани въпроси и отговори
В # 1) Какво е нормализация в база данни?
Отговор: Нормализирането на базата данни е техника за проектиране. Използвайки това, ние можем да проектираме или препроектираме схеми в базата данни, за да намалим излишните данни и зависимостта на данните чрез разбиване на данните на по-малки и по-подходящи таблици.
В # 2) Кои са различните видове нормализация?
Отговор: Следват различните видове техники за нормализиране, които могат да се използват за проектиране на схеми на база данни:
- Първа нормална форма (1NF)
- Втора нормална форма (2NF)
- Трета нормална форма (3NF)
- Нормална форма на Бойс-Код (3.5NF)
- Четвърта нормална форма (4NF)
- Пета нормална форма (5NF)
В # 3) Каква е целта на нормализацията?
Отговор: Основната цел на нормализацията е да се намали излишъкът на данните, т.е. данните трябва да се съхраняват само веднъж. Това се прави, за да се избегнат аномалии в данните, които могат да възникнат, когато се опитваме да съхраняваме едни и същи данни в две различни таблици, но промените се прилагат само към едната, а не към другата.
В # 4) Какво е денормализация?
Отговор: Денормализацията е техника за увеличаване на производителността на базата данни. Тази техника добавя излишни данни към базата данни, за разлика от нормализираната база данни, която премахва излишъка на данните.
Това се прави в огромни бази данни, където изпълнението на JOIN за получаване на данни от множество таблици е скъпа работа. По този начин излишните данни се съхраняват в множество таблици, за да се избегнат JOIN операции.
Заключение
Досега всички сме преминали през три форми за нормализиране на базата данни.
Теоретично има по-високи форми на нормализиране на базата данни като нормална форма на Бойс-Код, 4NF, 5NF. Въпреки това 3NF е широко използваната форма за нормализиране в производствените бази данни.
Честито четене !!
Препоръчително четене
- Тестване на база данни с JMeter
- MongoDB Създаване на резервно копие на база данни
- MongoDB Създаване на урок за база данни
- Топ 10 Инструменти за проектиране на бази данни за изграждане на сложни модели данни
- Производителност на MongoDB: Заключване на производителността, грешки на страници и профилиране на база данни
- Преглед на релационна база данни на Altibase с отворен код
- MongoDB Database Profiler за наблюдение на заявки и производителност
- Как да тествате базата данни на Oracle