I. Основи на субд 2



Изтегляне 1.28 Mb.
страница11/14
Дата23.02.2017
Размер1.28 Mb.
#15584
1   ...   6   7   8   9   10   11   12   13   14

2.Теория на нормализацията

2.1.Въведение


Въпросът, на който ще търсим отговор в този раздел: дадена е някаква съвкупност от данни, която трябва да бъде представена в БД, как ние ще решим каква е подходящата логическа структура за тези данни?

Или по-прецизирано: как ще решим какви релации са необходими и какви атрибути ще имат те? Това е проблем на логическото проектиране на БД.

Най-общо казано, нормализацията е процес на подреждане на данните в релации. Целта на логическият дизайн на базата данни е да представи обектите в базата данни чрез релации, които да съдържат необходимите данни, за да може представяния обект да бъде конструиран; освен това да могат да бъдат лесно добавяни, изтривани и модифицирани записи без нарушаване на консистентността на записаните данни.

Нормализацията е един от най-предизвикателните аспекти на традиционния дизайн на бази данни. Въпреки че е смятан за труден процес, той всъщност е относително прост веднъж след като са разбрани три основни концепции:



  • Цялостните предпоставки за нормализация;

  • Аномалиите на промените;

  • Зависимостите между данните.

Процесът на нормализация е декомпозиция на големи, неефективно структурирани таблици, в по-малки, по-ефективно структурирани таблици, като при този процес не трябва да има каквито и да било загуби на данни. Нормализацията поддържа твърдението, че добре дефинираната база данни не съдържа дублираща се информация и излишните данни са сведени до минимум. Това гарантира интегритета (съгласуваността) на данните и тяхната коректност при извличането им.

Декомпозирането на некоректно структурираните таблици не е произволен процес. Това е методичен и последователен процес на привеждане на определена таблица в целевата нормална форма.

Нормалната форма е алгоритъм, който се използва за тестване на структурата на таблицата, помагащ за премахване на аномалиите на промените и ефективно структуриране на таблиците и полетата в тях.

Съществуват седем нормални форми, всяка от които е създадена да се справи със специфични типове проблеми:



  • Първа нормална форма – базирана на функционалните зависимости;

  • Втора нормална форма - базирана на функционалните зависимости;

  • Трета нормална форма - базирана на функционалните зависимости;

  • Четвърта нормална форма – базирана на мулти-стойностни (multi-valued) зависимости;

  • Пета нормална форма – базирана на JOIN зависимости;

  • Boyce/Codd нормална форма – базирана на функционалните зависимости;

  • Domain/Key нормална форма – базирана на дефиницията на домейни и ключове.


На фигура 12-1 са представени нормалните форми. Смисълът на това подреждане е, че ако искаме да достигнем 3-та нормална форма, то задължително трябва да преминем през първа и втора нормални форми преди това. По такъв начин всяка следваща нормална форма специфицира по-тясно изискванията, на които трябва да отговаря релация в тази нормална форма.


2.2.Аномалии на промените


Основната причина за нормализиране на таблиците е осигуряването на смислената им и ефективна структура. Некоректно проектираните таблици обикновено проявяват лош интегритет на данните и са субект на аномалии на промените и проблеми, породени от зависимости между данните. Ако не бъдат решени тези проблеми можем на по-късен етап да открием, че данните, които извличаме, са неконсистентни, неточни и дори напълно неверни.

За да бъде осъзната нуждата от добро проектиране на таблиците трябва да бъдат разбрани проблемите, които те проявяват. Ще дискутираме три типа аномалии на промените – на добавянето, изтриването и обновяването на данни.


2.2.1.Аномалия на добавянето


Аномалия на добавянето възниква, когато има ненужно и безпричинно ограничение при опит за добавяне на нов запис в таблицата или когато добавянето на нов запис води до ненужно и безпричинно излишество от данни.

На фигура 12-2 е показана таблица, която съдържа данни за служители и отдели.



Тъй като данните за служителите и отделите са в една таблица. Не можем да добавим нов отдел преди да имаме поне един служител, който да е зачислен към новия отдел. От друга страна, не можем да добавим нов служител ако той не е зачислен към някой от отделите. По този начин имаме налице ненужно ограничение при въвеждането на данните.

Другият тип аномалия на добавянето е при добавяне на нов служител за определен отдел, при което всички данни за отдела се повтарят. Това води до излишество на данните.

2.2.2.Аномалия на изтриването


Аномалия на изтриването е налице, когато при изтриване на определени данни биват изтрити и други данни, които не сме възнамерявали да изтрием. Да вземем за пример таблицата с аномалията на добавянето. Ако изтрием отдел “Администрация” ще изтрием и данните за служителя Петър Станев. Ако изтрием служителя Никола Петров ще изтрием и единствените данни за отдел “Човешки ресурси”.

На фигура 12-3 е представена таблица, съдържаща данни за служители и продажби, които те са осъществили. Тук аномалията на изтриването налага изтриването на повече от един запис, което може да доведе до много по-сериозна загуба на данни. Например, ако искаме да изтрием данните за Илия Колев това ще доведе до изтриване на данните за продажби с номера 1 и 3, което би довело до сериозна промяна на баланса на продажбите.




2.2.3.Аномалия на обновяването


Аномалия на обновяването е налице, когато промяната на една стойност предизвиква необходимост от същата промяна на стойността в други записи на таблицата. Да вземем за пример таблицата от фигура 12-2. Ако отдел счетоводство промени вътрешния си телефон, то тази промяна ще трябва да бъде направена в записите за всички служители, което води до риск от възможно пропускане на обновяването на някои записи. По този начин данните в таблицата ще бъдат неточни, защото ще има срещания на различни телефони за един и същ отдел.

2.2.4.Обобщение


Освен споменатите аномалии ясно се вижда от таблиците, че често срещано е повтарянето на едни и същи данни. От тази гледна точка добър принцип при проектирането би бил “един факт на едно място”.

Нормализирането на базата данни решава в различни степени проблемите, свързани с описаните аномалии. Когато става въпрос за нормализиране на база данни говорим не дали е нормализирана, а до каква степен е нормализирана тази база данни. Тази степен на нормализация се изразява във вид на нормална форма.

Да припомним, че релациите са винаги нормализирани в смисъл, че прилежащите области съдържат само неделими стойности.

2.3.Нормални форми


Теорията на нормализацията се изгражда около концепцията за нормални форми. Нормалната форма е една добре дефинирана стандартна мярка за степента на нормализация, която една релация (таблица) притежава.

Нормализацията се извършва на степени. Всяка следваща нормална форма означава по-висока степен на нормализация. Въпреки факта, че нормализацията е желателна, възможно е да изпаднем в свръхнормализация. Колкото по-висока е степента на нормализация, толкова повече са таблиците, което прави схемата по-сложна, а също така може да намали ефективността и производителността на базата данни.

В оригинала на своите разработки Codd дефинира:


  • първа;

  • втора;

  • трета нормална форма.

Мотивацията според дефинициите на Codd е, че 2NF е "по-желана" от 1NF и 3NF е по-желана от 2NF, т.е. проектантът ще цели предимно 3NF. Но това твърдение (че проектантът ще се стреми към 3NF) не трябва да се приема като закон. Понякога съществуват добри причини да се променят принципите на нормализацията. Единственото твърдо изискване е релациите да бъдат най-малко в първа нормална форма. В действителност това е добра причина за твърдения от рода, че проектирането на БД е много сложен проблем. Теорията за нормализацията е използваемо помощно средство в този процес, но тя не е панацея. Всяко проектиране на БД трябва да е точно обмислено да кореспондира с основните техники на нормализацията, но ние не искаме да внушаваме, че то се базира само на принципите на нормализацията.

Има няколко неща, които трябва да бъдат проверени преди да се започне процесът на нормализация:



  • Всяка таблица трябва да има първичен ключ;

  • Таблица не може да съдържа повтарящи се групи от данни.

Всяка таблица трябва да отговаря на тези условия, за да бъде процесът на нормализация ефективен.

Фигура 12-4 представя една ненормализирана таблица, съдържаща поръчки на стоки. Тази таблица има първичен ключ – OrderID, и не съдържа повтарящи се групи от данни (има повтарящи се групи от стойности в полето Items), така че е в приемливо състояние за започване на процес на нормализация.



Полето Items има 2 очевидни проблема – съдържа повече от една част за данни (количество, стока и номер на стоката в склада) и повече от една стойност на данните, т.е. една стойност на OrderID е асоциирана с повече от една стойност на Items, а това е мулти-стойностна зависимост на ниво поле.

2.3.1.Първа нормална форма


Дефиниция: релационна променлива е в първа нормална форма, ако във всеки един момент всички атрибути на всеки ред съдържат единични стойности.

Целта на първа нормална форма е да гарантира, че полетата на таблицата не съдържат данни от много части или мулти-стойностни данни, а всяко поле съдържа единична стойност за всеки запис.

Сега процесът на нормализация може да стартира с реорганизиране на мулти стойностните полета.

В резултат на реорганизацията се появиха повтарящи се групи данни – Item1, Qty1, Item2, Qty2, Item3, Qty3. Тези данни могат да бъдат групирани в полета за стока и количество – Item, Qty. Освен това трябва да се премахнат многото части данни от полето Item като се раздели на две отделни полета за стоката (продукта) и номерът й в склада.



В таблицата на фигура 12-6 първичният ключ вече ще трябва да бъде комбинация от полетата OrderID и ItemID, защото стойностите на полето OrderID вече не са уникални. По този начин ще можем еднозначно да определим чрез номер на поръчка и номер на продукт какво количество от този продукт е поръчано.

Въпреки че тази таблица не е перфектна, тя е в първа нормална форма.

2.3.2.Втора нормална форма


Дефиниция: релационна променлива е във втора нормална форма, ако тя е в първа нормална форма и всеки не ключов атрибут е несъкратимо зависим от първичния ключ, т.е. всеки не ключов атрибут е зависим от целия първичен ключ.

Втора нормална форма гарантира, че всяко не ключово поле в таблицата е функционално зависимо от целия първичен ключ и че таблицата не съдържа полета с изчислени (калкулирани) стойности. Ако първичният ключ на таблицата се състои от едно поле, то тя е автоматично във втора нормална форма.

Таблицата Orders не е във втора нормална форма, защото тя има три отделни проблема:


  • Представя два отделни обекта – поръчки и детайлите на поръчките (стоките, които са поръчани, количества и цени);

  • Полетата Item и Price зависят от първичния ключ (OrderID, ItemID), но те са функционално зависими и само от полето ItemID;

  • Съдържа поле с изчислена стойност – Total.

Първото нещо, което трябва да се направи, е декомпозирането на таблицата на две по-малки – Orders и OrderDetails.

Новата таблица Orders сега е във втора нормална форма. Остава да се заемем с OrderDetails. Не е проблем да се справим с полето с изчислена стойност, трябва само да бъде премахнато от таблицата. Но наличието на зависимост от част от ключа означава, че таблицата трябва да се декомпозира отново на две по-малки – едната за детайлите на поръчката (OrderDetails), а другата за стоките (Products). При това разделяне полетата Item и Price, които са зависими от ItemID ще трябва да присъстват само в таблицата за стоките.




2.3.3.Трета нормална форма


Дефиниция: релационна променлива е в трета нормална форма тогава, когато тя е във втора нормална форма и всеки не ключов атрибут е не-транзитивно зависим от първичния ключ, т.е. няма транзитивни зависимости между атрибутите.

Трета нормална форма гарантира, че таблицата притежава следните характеристики:



  • Всяко не-ключово поле в таблицата е функционално зависимо от целия първичен ключ;

  • Всеки атрибут представлява специфична характеристика на обекта, който таблицата представя;

  • Таблицата представя само един обект, т.е. няма транзитивни зависимости.

Ако приемем, че всяка таблица с ключ от една колона е във втора нормална форма, то тогава на пръв поглед лесно ще решим проблема за достигане на тази нормална форма чрез добавяне на подобен ключ за всяка таблица. Но тогава ще се изправим пред основния проблем, който трета нормална форма е предназначена да разреши – функционалните зависимости между не ключови атрибути.

Нека разгледаме таблицата OrderDetails от фигура 12-7. Ще добавим едно поле (ID) за ключ, при което таблицата ще стане във втора нормална форма – фигура 12 9.

Ако погледнем таблицата OrderDetails от фигура 12-9 ще забележим, че тя притежава транзитивна зависимост между полетата ID, Item и Price чрез ItemID – т.е. таблицата представя повече от един обект. Тук ясно се вижда, че полето Price, например, не представя специфична характеристика на детайл от поръчката, а представлява само единична цена на продукта, т.е. характеристика на продукт, а не на детайл от поръчката. Следователно, ще трябва да декомпозираме таблицата така, че тя да представя само един обект, т.е. да няма транзитивни зависимости между неключовите атрибути. Декомпозицията е следната: атрибутите, които представят характеристики на продукт ще бъдат отделени в нова таблица, като по този начин в старата ще останат само атрибути, характеризиращи детайлите на поръчката. На фигура 12-10 е представена декомпозицията, след която таблиците са в трета нормална форма.


2.4.Boyce/Codd нормална форма


Дефиниция: релация е в BCNF, ако и само ако всеки детерминант е ключ кандидат.

BCNF е друга версия на трета нормална форма и е създадена, за да я усъвършенства и допълни. Целта на BCNF е от две части:



  • Да гарантира, че поле, което определя стойността на някое или всички не-ключови полета от таблицата трябва да бъде кандидат-ключ за тази таблица;

  • Да гарантира, че таблицата представя точно един обект.

BCNF е малко по-строга от трета нормална форма по отношение на ситуацията, когато една таблица има повече от едно поле, което може да бъде първичен ключ. Дефинирана е за точно определяне на всички кандидат ключове, като по този начин може да бъде гарантирана липсата на транзитивни зависимости и като следствие от това таблицата да не е субект на аномалиите на промените.

На фигура 12-11 е представена таблицата OrderDetails, съдържаща три детерминанта:



  • OrderID, LineNumber;

  • OrderID, ItemID;

  • ItemID.

За да бъде таблицата в BCNF нормална форма трябва да гарантираме, че всички детерминанти са кандидат-ключове.

Но от фигурата ясно се вижда, че ItemID не е ключ кандидат, но въпреки това то определя Item и Price. Това означава, че Item и Price са в транзитивна зависимост от двата кандидат-ключа. Следователно тези две полета ще трябва да бъдат премахнати от таблицата. След като тези полета бъдат премахнати таблицата вече е в BCNF – фигура 12-12.

Повечето таблици, които са в BCNF няма да имат нужда от по-висока степен на нормализация. Обаче, процесът на нормализация ще трябва да продължи, ако таблицата съдържа мулти-стойностни зависимости.


2.5.Четвърта нормална форма


Дефиниция: релационната променлива R е в четвърта нормална форма тогава и само тогава, когато съществуват подмножества A и В от атрибути на R такива, че МСЗ AB да е удовлетворена, тогава всички атрибути на R са функционално зависими от А.

Целта на четвърта нормална форма е да гарантира, че таблицата не съдържа MСЗ и представя един единствен обект.

По-рано споменахме, че таблица с МСЗ представя два или повече обекта, в зависимост от броя на зависимостите. На фигурите 12-13 и 12-14 са представени таблици с МСЗ съответно на ниво поле и запис. И в двата варианта прилагането на четвърта нормална форма ще породи еднакви резултати.



При прилагането на четвърта нормална форма на таблица, съдържаща МСЗ, трябва да създадем нова таблица, съдържаща копие на първичния ключ и полето, съдържащо множеството стойности. Използването на първичния ключ като част от новата таблица е важно, защото то осъществява връзката между новата и оригиналната таблица. И остава да декомпозираме оригиналната таблица чрез премахване на мулти-стойностното поле. Фигура 12-15 демонстрира получения резултат.



Ако имаме налице таблица с две или повече МСЗ просто се повтаря същата процедура за всяка МСЗ. Фигура 12-16 показва таблица с две независими МСЗ.

Ще обработим всяка МСЗ, както направихме в предишния пример:


  • Създаваме нова таблица, съставена от първичния ключ EmpID и едното мулти-стойностно поле – Language;

  • Създаваме друга нова таблица, съставена от първичния ключ EmpID и другото поле с множество стойности – Certificate;

  • Премахваме двете мулти-стойностни полета Language и Certificate от оригиналната таблица.

Така получените три таблици са в четвърта нормална форма – показани са на фигура 12-17.




2.5.1.Пета нормална форма


Дефиниция: релационна променлива R е в пета нормална форма, също наричана Projection/Join Normal Form (PJ/NF), ако и само ако всяка нетривиална JOIN зависимост, която е в сила за R, се базира на кандидат-ключовете на R.

Споменахме, че JOIN зависимост съществува, ако таблицата и всички нейни оригинални записи могат да бъдат реконструирани чрез SQL JOIN операция, която съединява всички таблици, създадени при декомпозицията.

След като таблицата е достигнала четвърта нормална форма приемаме, че тя няма транзитивни и мулти-стойности зависимости. В повечето случаи няма да е необходимо таблицата да бъде декомпозирана по-нататък. Обаче, ако мислите, че можете (или трябва) да декомпозирате таблицата още веднъж, трябва да проверите дали е налице валидна JOIN зависимост в таблицата. Има няколко въпроса, на които трябва да се отговори преди да се премине към по нататъшна декомпозиция:


  • Може ли да бъде създадена таблица (или таблици), използвайки първичния или кандидат-ключ като част от новата таблица? (Това беше изискване за решаване на транзитивните и мулти-стойностните зависимости.)

  • Може ли да бъде пресъздадена оригиналната таблица чрез SQL JOIN операция, която съединява всички таблици, създадени след декомпозицията?

  • Ще бъде ли декомпозицията без загуба на записи?

Ако отговорът на всички тези въпроси е “да”, то таблицата е в пета нормална форма и декомпозицията може да бъде направена уверено. Обаче фактът, че таблицата може да бъде декомпозирана без загуба на данни, не означава, че това трябва да бъде направено.

Фигура 12-18 показва таблица, която може да бъде декомпозирана на по-малки таблици.



Тази таблица може да бъде декомпозирана като за част от новата се използва първичния ключ EmpID или кандидат-ключа SocialNumber. По този начин декомпозицията ще бъде без загуба и оригиналната таблица ще може да бъде възпроизведена.

Какво би наложило декомпозицията на тази таблица? Една възможна причина би била разделянето на поверителната информация от останалата. Пример е показан на фигура 12-19.


EmpID

SocialNumber

PrivateCellular

BirthDate

101

111

0887658909

12.03.1945

102

222

0899498776

04.12.1982

103

333

0888446323

21.11.1968

104

444

0897622315

24.09.1976



При тази декомпозиция командата, генерираща оригиналната таблица ще бъде тази, показана на фигура 12-20.




2.5.2.Domain/Key нормална форма


Дефиниция: релационна променлива R е в DKNF, ако и само ако всяко ограничение на R е логическо последствие от ограниченията за домейни и ключове, приложени в R.

DKNF е сравнително нова нормална форма и е подобна на BCNF по това, че частично се базира на правилата, наложени от първични и кандидат-ключове. Но тя също се базира на идеята за домейните. Домейните не са просто множество от стойности – те имат логическа и физическа част. Логическата част дефинира стойност по подразбиране, диапазон от стойности, дали наличието на стойност да бъде задължително или може да има NULL стойност. Физическата част определя неща като тип на данните, дължина, позиция на десетичната запетая и позволени символи.

За да бъде една таблица в DKNF, тя трябва да отговаря на следните изисквания:


  • Всяко поле трябва да бъде цялостно и коректно дефинирано;

  • Всяко поле трябва да представя характеристика на обекта, който таблицата представя;

  • Всяко не ключово поле от таблицата трябва да бъде функционално зависимо от целия първичен ключ;

  • Всяка таблица трябва да представя само един обект.

Таблица, намираща се в DKNF няма да има транзитивни и мулти-стойностни зависимости, няма да бъде субект на аномалии на промените.

Фигура 12-21 показва таблица, която може да бъде нормализирана до DKNF.



Едно от изискванията на DKNF е първичният ключ да определя стойността на всяко не ключово поле. Това в случая не е изпълнено – полето Department е функционално зависимо от DepartmentID. То ще трябва да бъде премахнато, за да бъде достигната желаната нормална форма. Резултатът от промяната е показан на фигура 12-22.

Използването на тази нормална форма зависи много от интуицията. Концепциите за домейни и ключове трябва да се разбират много добре преди да може да бъде извлечена полза от тази нормална форма.


2.5.3.Денормализация


Едни от най-често срещаните причини, каращи разработчиците да пристъпват към денормализация, са недостатъчна бързина и ефективност на базата данни.

Въпреки, че бихме могли в определени случаи да оправдаем известна степен на денормализация поради чисто практически причини, тази стъпка трябва да е винаги последна, когато всички други варианти са неприложими. Преди нея могат да бъдат предприети редица действия за повишаване на ефективността на работа на базата данни. Някои от тях са:



  • Обновяване на компютърното оборудване;

  • Оптимизиране на операционната среда, увеличаване на скоростта на мрежовия трафик;

  • Оптимизиране на софтуера на СУБД – осигуряване на това, че няма стартирани допълнителни процеси от софтуера на СУБД, които не са необходими, но заемат процесорно време и памет;

  • Ефективно използване на индекси – индексите могат реализират огромно ускорение процеса на извличане на данни;

  • Писане на добър, стегнат и ефективен процедурен код;

  • Писане на добре структурирани и ефективни SQL заявки.

Най-важното е да се запомни, че когато се извършва денормализация се прави стъпка назад към проблемите с целостта на данните. Ще трябва добре да се прецени и реши дали ползите от денормализацията ще си струват допълнителните усилия, които ще коства поддържането на такава база данни.

2.6.Правила за съставяне на релации


Да не забравяме, че в този раздел се опитваме да открием най-добрия начин да групираме атрибутите в релации. Резултатните релации трябва да удовлетворяват две изисквания:

  • Те трябва да съдържат необходимите данни за конструиране на обекта, който представят;

  • Не трябва да възникват аномалии на промените при манипулиране на данните им.

Както видяхме, някои комбинации от атрибути са ефективни, други – не.

Два атрибута A и B могат да се отнасят един към друг по три основни начина:



    1. Всеки да определя другия: AB и BA. Това е връзка “едно към едно”.

    2. Единият определя другия: AB, но B не определя A. Това е връзка “много към едно”.

    3. Няма функционална зависимост между тях: A не определя B и B не определя A. Такава връзка се нарича “много към много”.

2.6.1.Връзка “едно към едно”


Ако A определя B и B определя A, тогава стойностите на тези атрибути са във връзка “едно към едно”. Ето защо: знаем, че A определя B, следователно връзката от A към B е много към едно. Но B определя А, следователно връзката от B към А трябва да е много към едно. Единственият начин тези две твърдения да са истина едновременно е връзката да е едно към едно.

Като пример можем да дадем релация, която има за атрибути ЕГН и номер на осигуровка, и двата уникални за всеки човек. Всеки от тези атрибути уникално идентифицира човек, следователно ЕГН отговаря на точно един номер на осигуровка и обратно. Три еквивалентни заключения могат да бъдат направени от този пример:



  • Ако два атрибута са функционално зависими един от друг, връзката между стойностите им е едно към едно;

  • Ако два атрибута уникално идентифицират един и същ обект, връзката между стойностите им е едно към едно;

  • Ако два атрибута са във връзка едно към едно, тогава те функционално се определят един друг.

Атрибути, които имат връзка едно към едно, трябва да се срещат заедно поне в една релация. Други атрибути, които са функционално зависими от тях, също могат да бъдат в същата релация. Атрибути, които не са във функционална зависимост от тях, не трябва да присъстват в същата релация.

2.6.2.Връзка “много към едно”


Ако атрибутът A определя B, но B не определя A, тогава връзката между стойностите им е много към едно.

В таблицата с преподавателите от фигура 12-23 един факултет определя много преподаватели, които са негови служители. Но всеки преподавател може да е служител само на един факултет. Това е много към едно връзка.




NAME

FACULTY

LECTION

Стоян Колев

ФМИ

Алгебра

Владимир Петров

Филология

Методика на обучението

Мария Тодорова

ФМИ

Информатика 1

Илия Желев

Право

Гражданско право



Ако А определя B, то всички други атрибути, които добавяме в релацията, трябва да зависят само от А. В противен случай ще възникнат транзитивни зависимости и степента на нормализация ще се понижи.


2.6.3.Връзка “много към много”


Ако А не определя B и B не определя А, тогава връзката между стойностите им е много към много.

Например, ако в една релация имаме преподаватели и дисциплини и един преподавател може да преподава повече от една дисциплина, а една дисциплина може да бъде преподавана от повече от един преподавател, то имаме налице връзка много към много.

При наличие на такава връзка комбинацията от двата атрибута трябва да бъде ключ. При добавяне на нов атрибут трябва да се съобразяваме с изискването той да бъде функционално зависим от целия ключ.
Обобщение на типовете връзки и правилата за конструиране на релации





Едно към едно

Много към едно

Много към много

Релация

R (A, B)

R (A, B)

R (A, B)

Зависимости

A  B

B  A


A  B

Но B не определя A
А не определя B и

B не определя А

Ключ

A или B

A

(A, B)

Добавяне на атрибут

Ако A или B  C

A  C

(A, B)  C


Едно към едно


  • Атрибутите с такава връзка трябва да присъстват заедно поне в една релация;

  • Един от двата А или B трябва да бъде ключ;

  • Към релацията може да бъде добавен атрибут ако той е функционално зависим от A или B;

  • Ако атрибутът не е функционално зависим от A или B не може да бъде добавян в релацията;

  • А и B трябва да се срещат заедно в R, но не трябва да се срещат заедно в друга релация;

  • А или B трябва последователно да се използва в други релации, за да представя двойката.


Много към едно

  • Атрибути с такава връзка могат да се срещат една релация. Да приемем, че A  B в R;

  • А трябва да е ключ в R;

  • Атрибут може да бъде добавян ако е функционално зависим от A;

  • Атрибут, който не е функционално зависим от А не може да бъде добавян.


Много към много

  • Атрибути с такава връзка могат да присъстват в една релация;

  • Ключ трябва да е (А, B);

  • Атрибут може да бъде добавян ако е функционално зависим от (A, B);

  • Атрибут, който не е функционално зависим от (А, B) не може да бъде добавян;

  • Ако добавим нов атрибут, който разширява ключа на (A, B, C), тогава се променя смисълът на релацията.

2.7.Заключителни бележки


В тази раздел ще разгледаме техниката на lossless decomposition като помощно средство за конструиране на една БД. Основната идея е следната: дадена е някаква релация R в първа нормална форма и някакъв списък от ограничения, които се прилагат върху R. Ние систематично редуцираме R в едно множество от по-малки релации в един добре дефиниран смисъл и по някакъв начин по-приемливи от R. Всяка стъпка представлява процес на проекции на релациите, получени като резултат от предишната стъпка. Дадените ограничения се използват на всяка стъпка, за да се направи изборът коя от проекциите да стане следваща.

Най-важната цел на редукционния процес е да се намали излишеството и следователно да се предотвратят някои update аномалии. Но трябва да подчертаем още веднъж, че нормализацията е една препоръка - във всеки конкретен случай трябва да се решава в зависимост от индивидуалните изисквания.

Накрая на този раздел ще повторим още веднъж, че предметът на нормализацията е от различен вид от този на разглежданите механизми в предишните глави. Нормализацията на зависимостите има семантичен характер. С други думи тя се занимава със значението (смисъла) на данните. За разлика от нея релационната алгебра и езиците за програмиране като SQL, изградени върху тези механизми, се занимават само със стойностите на данните. Всяка интерпретация на тези стойности се налага отвън (от потребителя). Тези формализми и езици нямат други изисквания към релациите, които ще обработват, с изключение на това те да бъдат в 1NF.


Каталог: sites -> default -> files
files -> Образец №3 справка-декларация
files -> Р е п у б л и к а б ъ л г а р и я
files -> Отчет за разкопките на праисторическото селище в района на вуз до Стара Загора. Аор през 1981 г. ХХVІІ нац конф по археология в Михайловград, 1982
files -> Медии и преход възникване и развитие на централните всекидневници в българия след 1989 година
files -> Окръжен съд – смолян помагало на съдебния заседател
files -> Семинар на тема „Техники за управление на делата" 18 19 юни 2010 г. Хисар, Хотел „Аугуста спа" Приложение
files -> Чинция Бруно Елица Ненчева Директор Изпълнителен директор иче софия бкдмп приложения: програма
files -> 1. По пътя към паметник „1300 години България

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

Сподели с приятели:
1   ...   6   7   8   9   10   11   12   13   14



©obuch.info 2024
отнасят до администрацията
    Начална страница
Автореферат
Анализ
Бизнес-план
Биография
Глава
Диплом
Доклад
Задача
Закон
Занятие
Заседание