Данни и програмен код

Фигура 3.3. Таблица в 1NF
Така за служителя Иванов в таблицата има два записа – по един за всяко от децата. Ако децата бяха три или повече, за всяко от тях щеше да има по един запис. Така в клетките на таблицата няма повтарящи се стойности и тя отговаря на изискванията на първа нормална форма.
Сега обаче старият ключ на таблицата вече не е уникален, защото идентификаторът на служителя Иванов стои пред всеки ред, съответстващ на неговите деца. Затова трябва да се направи промяна в ключа – той да стане съставен и да се състои от повече от едно поле. Логично е понеже различното в редовете за един служител са децата, към ключа да прибавим един от атрибутите, описващ децата. Ако добавим възрастта към ключа – губим възможността един служител да има близнаци (деца на еднаква възраст). В примера към ключа е прибавено името на детето, но така не позволяваме един родител да има две деца с еднакво име. В голямата част от случаите това ще върши работа, но ако това ограничение е важно, то можем да добавим допълнително изкуствено поле с номер на детето.
Тази таблица не е идеална, защото все още съдържа Null стойности, които усложняват обработката на данните. Освен това може да се предположи възможността за следните аномалии:

Аномалия при вмъкване на данни: не можем да добавим в базата данни информация за дете, преди да сме въвели служител;

Аномалия при изтриване на данни: ако изтрием служителя
Георгиев, ще загубим данните за детето Павел;

Аномалия при промяна на данни: ако променим заплатата на служителя Иванов, трябва да го направим във всички полета, където тя се среща, в противен случай ще имаме несъответствие в данните – на единия ред ще пише една заплата, на другия – друга.

За да избегнем тези неудобства трябва да преминем към по- висока нормална форма.
Една таблица е във втора нормална форма, ако отговаря на изискванията на първа нормална форма и всички неключови стойности са напълно функционално зависими от първичния ключ. Не са позволени частични зависимости.
Частична зависимост се получава, когато имаме съставен първичен ключ и дадено поле зависи само от част от ключа, а не от целия първичен ключ. Например в таблицата на фигура
3.2 имаме съставен ключ, който се състои от полетата ID на служителя и име на децата. Налице са няколко частични функционални зависимости – заплатата, стаята и телефонът на служителя зависят от неговия номер, но не и от името на детето, защото може да има двама служители, чиито имена да са еднакви.
За да преминем във втора нормална форма е необходимо да премахнем частичните зависимости - ако в една релация се съдържат атрибути, които са функционално зависими не от целия първичен ключ, а от части от него, то за тях трябва да се състави нова таблица. Преходът от първа към втора нормална форма се прави по следния начин:

определя се първичния ключ на таблицата в 1NF;

определят се функционалните зависимости в релацията;

При наличие на частични зависимости от първичния ключ, те се премахват, отделяйки ги в нова релация, заедно с копие на частта от ключа, която ги определя еднозначно.
За таблицата от горния пример това става по начина, показан на фигура
3.4.

Фигура 3.4. Таблици във 2NF
Сега в новите таблици могат да се забележат следните промени: първо в таблицата със служителите можем да върнем предишната стойност на първичния ключ да е полето
ID, тъй като сега децата са в отделна таблица и редовете в таблицата „Служители“ не се повтарят. В таблицата „Деца на служители“ е необходимо да имаме съставен ключ – ID на служителя + име на детето, за да позволим възможността различните служители да имат деца с еднакви имена и за да позволим един служител да има повече деца. Второ: за служителят, който няма деца не правим запис във втората таблица и така избягваме Null стойностите. Нямаме частични зависимости, тъй като в първата таблица ключът не е съставен, а във втората възрастта зависи и от името на детето и от номера на родителя.
Но все пак тези таблици могат да водят до аномалии:
• Аномалия при вмъкване на данни: не можем да добавим в базата данни стая и телефон, преди да сме назначили служител в тази стая;

• Аномалия при изтриване на данни: ако изтрием служителя
Георгиев, ще загубим данните за стая 102 и телефонния номер, който се намира в нея;
• Аномалия при промяна на данни: ако променим телефона на стая 101, трябва да го направим във всички полета, където тя се среща, в противен случай ще имаме несъответствие в данните – на единия ред ще пише един телефон, на другия – друг.
За да избегнем тези проблеми би следвало да преминем към по-висока нормална форма.
Релационната схема е в 3НФ, ако вече е във 2НФ и всеки непървичен атрибут зависи пряко (нетранзитивно) от първичния ключ. Транзитивна (непряка) зависимост имаме, когато едно поле е функционално зависимо от друго поле, а то от своя страна е зависимо от първичния ключ.
В горния пример имаме следната непряка зависимост: полето
„Телефон“ зависи от номера на стаята, което зависи от номера на служителя.
За да преминем в трета нормална форма, трябва да следваме следната последователност:

Определя се първичния ключ във 2NF;

Определят се функционалните зависимости в релацията;

Ако съществуват транзитивни (непреки) зависимости, те се премахват чрез отделяне в нова релация, заедно с копие на техния детерминант.

Фигура 3.5. Таблици във 3NF
Така нашата база данни добива вида, показан на фигура 3.5.
Сега вече можем да изтрием всички служители в дадена стая, без да загубим информацията за нея (телефонния и номер), можем да вмъкваме стаи, преди в тях да са настанени служители и можем да променяме телефонния номер на дадена стая без това да доведе до аномалии, тъй като тази информация се намира само на едно място в базата данни и промяната и не може да доведе до противоречие. ази форма отразява някои редки, но все пак възможни положения, при които една таблица може да бъде в трета нормална форма и да е податлива на аномалии. Това може да стане в случаите когато имаме два кандидат-ключа, които са съставни и едната част от двата кандидат-ключа съвпада.
Пример за такава таблица е показан на фигура 3.6.

Фигура 3.6. Илюстрация на BCNF
Ако името на доставчика е уникално, тогава имаме два кандидат ключа: (Доставчик_номер, Част_номер) и
(Доставчик_име, Част_номер). Както беше отбелязано и двата кандидат-ключа са съставни, като една част от двата съвпада
– полето „Част_номер“. Таблицата е в трета нормална форма, защото всяко поле зависи нетранзитивно от първичен ключ.
Но в нея може да има аномалии:

Аномалия при вмъкване – не можем да вмъкнем доставчик, докато той не достави поне една част;

Аномалия при изтриване – ако изтрием всички стоки на един доставчик губим името му;

Аномалия при актуализация – промяна на името на доставчика трябва да се направи на всички редове, в противен случай ще имаме противоречие.
Дефиницията на нормалната форма е: никой ключ, подключ или първичен атрибут не трябва да зависи функционално от непървичен атрибут. BCNF адресира някои, макар и редки ситуации, неограничени от 3НФ: за функционалната зависимост A->B 3НФ позволява B да е първичен ключ, а A да не е кандидат ключ, докато BCNF изисква А да е кандидат ключ. В повечето ситуации (например за релация с един кандидат ключ) двете форми съвпадат.
Алгоритъмът за преход от трета НФ към BCNF e:

Определяне на всички кандидат-ключове в релацията;

Определяне на всички функционални зависимости;

Ако съществува функционална зависимост, чиито детерминант не е кандидат ключ, тя се премахва, чрез отделяне в нова релация, заедно с копие на детерминанта.

Нормалната форма на Бойс-Код не е четвърта нормална форма, а усилена трета нормална форма и понякога се означава като 3,5NF.
За някои, макар и редки случаи трета нормална форма не е достатъчна. Такъв пример е показан на фигура 3.7.
Фигура 3.7. Илюстрация на 4НФ
В таблицата няма нетривиални зависимости, затова таблицата е в BCNF, но могат да съществуват аномалии, например ако трябва да добавим учебник, трябва да направим два записа – по един за всеки преподавател, в противен случай ще имаме несъответствие на дисциплината, преподавателя и учебника.
Понятието, което дефинира четвърта нормална форма се нарича многостойностна зависимост. В случая много преподаватели могат да преподават по една дисциплина, както и много учебници могат да се използват по същата дисциплина.
Четвърта нормална форма изисква премахване на многостойностните зависимости, чрез отделянето им в отделни таблици, както е показано на фиг. 3.8.
Фигура 3.8. Преминаване в 4НФ
При пета нормална форма се премахват цикличните зависимости. Циклична зависимост се получава когато едно поле зависи от друго поле а то от своя страна зависи директно

или индиректно от първото поле. Формата се нарича още
„Проекционна нормална форма” (Project-join normal form,
PJNF). Пример за такава таблица е показан на фигура 3.9.
Фигура 3.9. Илюстрация на 5НФ
В примера няколко вериги магазини продават няколко продукта, всеки от които може да е от няколко марки. Ако трябва да добавим нов продукт в базата, колко записа трябва да направим? Как да определим даден продукт от кой магазин е купен?
За да избегнем тези неудобства, трябва да премахнем цикличните зависимости, разделяйки таблицата на три отделни таблици, както е показано на фигура 3.10.
Фигура 3.10. Преминаване в 5НФ
За всяка следваща нормална форма трябва да са изпълнени условията на всички предишни нормални форми. Повечето релации в 3 NF не са податливи на аномалии. BCNF разрешава повечето възможни аномалии на 3NF. Постигането на нормална форма над 3NF/BCNF често е трудно в практиката.

Обикновено трета нормална форма е достатъчна за всяка база данни.
Прилагането на принципите на процеса на нормализация предполага да разделим всички данни в отделни таблици.
Това обикновено не позволява аномалии, но понякога може да доведе до лоши последици. Например при много връзки и таблици може да се наложи голям брой операции и чувствително забавяне на работата, в сравнение със случая когато данните са събрани в една таблица. Друг пример за необходимост от събиране на общи данни в една таблица, нарушавайки правилата за нормализация може да бъде при невъзможност за промяна на данни във вече издаден документ
– например ако сме продавали един артикул под едно име и номер, след което производителят промени неговото име. Ако таблицата е нормализирана – вероятно ще имаме таблица с продукти и таблица с фактури за продажба, които ще са свързани по номер на продукт. Промяната на името на продукта в таблицата с продукти ще доведе до промяна на името на продукта и за вече издадените фактури, което е нарушение. В този случай може да се наложи събиране на данните за фактурата и продуктите в една таблица.
В практиката понякога се налага таблиците на базата данни да се изграждат така, че да нарушават правилата за нормализация. При всички случаи това трябва да се прави внимателно, като разработчикът на базата данни и програмната система:

Знае какви са правилата;

Знае защо съществуват;

Знае последиците от нарушението;

Знае защо иска да ги наруши.
4. Работа с бази данни (1/13)
Както беше описано преди, при SQL базите данни клиентите изпращат запитвания към системата за управление на базата данни (СУБД), тя получава запитванията, обработва ги, като

извлича необходимите данни от базата, прави необходимите изчисления и връща резултата към потребителя. Запитванията се правят чрез стандартизирания език SQL (Structured Query
Language, език за структурирани запитвания). Въпреки че много ситеми, като Oracle, Microsoft SQL, MySQL и други използват същата концепция, при някои реализации синтаксиса на заявките се различава. В настоящата глава са описани заявки, които работят при MySQL, но може да не работят или да имат различен синтаксис при други системи.
При всички SQL бази данни запитванията се оформят във вид на стринг – текст, който описва заявката. При оформянето на заявките трябва да се има предввид, че не се преави разлика между главни и малки букви и като разделител може да се използва един или няколко интервала, един или няколко символа за табулация (Tab), нов ред или комбинация от тях.
Всеки ред завършва с точка и запетая (;), това е командата за изпълнение на реда.
В следващите точки ще бъдат разгледани основните операции, използвани при дефиниране и работа с бази данни при MySQL и други SQL базирани бази данни.
Възможно е на един сървър да съществуват много бази данни.
Върху коя база данни се отразяват командите се избира с командата Select. Например изборът на база данни с име
“University” може да се направи с:
Select university; create table instructor (
ID char(5), name varchar(20) not null, dept_name varchar(20), salary numeric(8,2));
Изразът създава таблица с име Instructor, която има полета:

Име на преподавател (name) от тип varchar(20) и не може да остава без стойност (Null), Име на катедра (dept_name) от тип varchar(20) и поле заплата (salary) от тип numeric с осем символа, два от които след десетичната запетая. create table instructor (
ID char(5), name varchar(20) not null, dept_name varchar(20), salary numeric(8,2), primary key (ID), foreign key (dept_name) references department);
Командата създава таблица, като в предишния пример, но дефинира, че първичният ключ е полето ID и вмъква чужд ключ от таблицата department, поле dept_name.
Друг начин за дефиниране на първичен ключ, когато се състои само от едно поле е: create table student (
ID varchar(8) primary key, name varchar(20) not null, dept_name varchar(20), credits numeric(3,0), foreign key (dept_name) references department) );
В примера се създава таблица „Student” с полета ID от тип varchar(8), name от тип varchar(20) без възможност за празни стойности, dept_name от тип varchar(20) и credits от тип numeric(3,0). Полето ID се дефинира като първичен ключ и се вмъква чужд ключ с име dept_name от таблицата department.

Изтегляне 1.13 Mb.

Сподели с приятели: