РЕЛАЦИОНИ БАЗИ НА ПОДАТОЦИ 1. Вовед Релација е датотека која:
содржи само записи од еден вид; записите не се снимени по некаков редослед. записите имаат поле (клуч) кое единствено го идентификува записот.
Општиот приказ на една релација е следниот: Ime_r ( kluc1, kluc2, atr1, atr2, ...)
Ime_r : име на релацијата; kluc1, kluc2, atr1, atr2, .. : атрибути на релацијата Клуч составен од повеќе атрибути е сложен клуч. На пример: kluc1 и kluc2 го создаваат примарниот клуч - единствен идентификатор на записот, кој во случајот е и сложен клуч. Како пример да ја земиме следната релација: Vraboten (br_vrab, adresa, ime _v, plata). plata ). Состојбата на релацијата во базата би можела да биде:
Релацијата се претставува како табела. Колоните ги претставуваат вредностите на атрибутите, а секоја редица претставува еден запис или торка на релацијата. Секој запис кој што е идентификуван преку вредноста на примарен клуч се вика торка. Во случајов 4 атрибути формираат торка. Всушност следниве концепти се користат како еквивалентни: Релација ⇔ Табела Торка ⇔ Редица или Запис Атрибут ⇔ Колона или Поле Примарен клуч ⇔ Единствен идентификатор
Ако се навратиме на ЕА моделот, треба да кажеме дека кај релациониот модел на бази на податоци и ентитетите и дел од асоцијациите се претставуаат како релации, т.е. како табели. Врските помеѓу две релации се решаваат со т.н. надворешни клучеви кои што се однесуваат кон вредности на некој клуч од некоја торка од др друга уга релација. релација.
Релационата база на податоци се состои од повеќе табели поврзани меѓу себе само преку надворешните клучеви. Кај релационите БП разликуваме неколку типови клучеви во однос на една табела: кандидати, примарни и алтернативни. Некој атрибутот на некоја релација е кандидат-клуч за таа релација ако и само ако ги задоволува особините на единственост и минималност. Притоа ЕДИНСТВЕНОСТ значи дека нема две торки од релацијата со иста вредност за тој атрибут, а МИНИМАЛНОСТ значи дека нема атрибут што може да се отстрани од клучот, а да не се наруши претходната особина. Секоја релација мора да има најмалку еден кандидатклуч и за дадена релација се избира еден кандидат-клуч како примарен! Другите, ако ги има, се алтернативни клучеви. Нормални форми
I нф: Сите вредности на податоците се атомични. Не постојат групи податоци што се повторуваат. II нф: Секој атрибут што не е дел од примарниот клуч е наполно функционално зависен од примарниот клуч. III нф: Во релацијата да нема транзитни зависности (пр. за транзитна зависност е: ако C е функционално зависна од B и B е функционално зависна од A ⇒ C е функционално зависна од A). Првите две нормални форми најдобро ќе бидат објаснети со пример, близок за студентите, а тоа е евиденцијата што се води при запишување на студентот во нов семестар. Секој семестар студентот внесува податоци за семестарот што го запишува студентот, број на индекс, име и презиме, матичен број, датум на раѓање, место на раѓање, адреса на живеење, име на средно училиште, насока на средното училиште, кога првпат се запишавте на факултетов, степен на образование на двата родители и нивно занимање, занимање на студентот. Овие атрибути се доволни за нашата илустрација. Првата нормална форма кажува дека два пати не запишувате една иста работа, на пример, да има две графи за индекс број, т.е. два пати да треба да се внесува. Во сите примери со кои ќе работиме ќе биде задоволена првата нормална форма, бидејќи е тривијална. Со запишувањето на факултетов, секој студент добива единствен индекс број, и тој број служи за единствено идентификување на еден студент. Значи индекс_број е кандидат клуч. Алтернативен клуч би бил матичен_број бидејќи државата гарантира единственост на матичниот број за секој граѓанин на Македонија. Ако нема странски студенти на факултетот, тогаш може да се користи и матичниот број како клуч, но во случај да има и странски студенти на факултетот, тие немаат матичен број, па затоа не можеме да го користиме матичниот број како клуч. Името и презимето се менлива категорија. Секој полнолетен граѓанин може да си го промени самиот името. Ако ние сакаме да ја изразиме таа можност и во нашата
евиденција, тогаш би требало да го прашуваме студентот за името и презимето при упис во секој семестар. Сепак, не мора да водиме евиденција за тоа во кој семестар студентот си го променил името, можно е името и презимето на студентот да се чуваат во евиденција во една табела и ако има промена на името и презимето, тогаш во евиденцијата за студентите треба да се промени (ажурира) записот за тој ст удент. Матичниот број е непроменлив во текот на животот. Затоа нема смисла да го прашуваме студентот за тој долг број секој семестар. Не само што информацијата за матичниот број би завземала повеќе простор на дискот, бидејќи внесувањето е деветкратна (па и повеќе кратна) работа, туку притоа се можни и грешки. Што ако студентот (ненамерно или намерно) внесе различни матични броеви при уписот на секој семестар. Кој матичен број ќе се земе како точен? Тој што најчесто се појавувал при уписите? Заради тоа се гледа дека треба да ги раздвоиме податоците во две табели, во една да се внесуваат непроменливите податоци за студентот во текот на студиите, а во другата променливите податоци. Засега табелите се: студент (индекс_број, име_презиме, матичен број) запишан_во (индекс_бр*, име_презиме, семестар)
каде * кажува дека атрибутот индекс _ бр е надворешен клуч во оваа релација (се однесува на клучот индекс _ број од релацијата студенти). Датумот и местото на раѓање се непроменливи нешта, за секого, па и за студентите и затоа не треба секој семестар да се прашува некој каде и кога е роден. Замислете како би изгледала една такава релација: запишан_во (индекс_бр*, семестар, датум_р, место_р, општина_р)
и замислете како би излгедале податоците во таква една табела:
Едно што се можни грешки (забележете дека не се исти сите датуми на раѓање на студентот со индекс број 339/04, како и дека има печатни грешки), второ, се завзема многу повеќе меморија отколку решението податоците за раѓање да се водат во
табелата за студенти, а за запишување на семестар да се води евиденција само за индекс_број и број_на_семестар): студент (индекс_број, име_презиме, мат_бр, датум_р, место_р, општина_р) запишан_во (индекс_бр*, семестар)
Адресата на живеење (како и некои други слични податоци за пронаоѓање на студентот, како: тел. број, e-mail и сл.) може да се менува секој семестар, па затоа има смисла тој атрибут да се води во релацијата за запишување: запишан_во (индекс_бр*, семестар, тековна_адреса)
Податоците во врска со претходното образование на ст удентот ние ќе ги сметаме за непроменливи во текот на студиите (иако е можно, многу тешко може да се најде некој да завршил уште еднаш гимназија, на друга насока, откако се запишал на факултет). Заради тоа, атрибутите во врска со гимназијата каде што завршил претходно студентот ги приклучуваме во релацијата студенти, а податоците за тоа треба да се внесат само при запишувањето на студентот на студии, а не при запишувањето на секој семестар. Истото важи и за учебната година во кој првпат сте се запишале на студии. студент (индекс_број, мат_бр, датум_р, место_р, општина_р, гимназија, насока_гим, успех_гим, година_на_упис)
Степенот на образование на родителите, нивното занимање како и занимањето на студентот може да се променат во текот на студиите. Сега треба да си одговориме на прашањето дали сакаме да водиме историјат за развојот и напредувањето на родителите и на студентот или пак ни треба само последната состојба. Ако ни треба само последната состојба, ваквите атрибутите треба да се приклучат кон релацијата студенти и во случај на промена на состојбата да се променат (ажурираат) и соодветните записи во табелата. Бидејќи се работи за статистички податоци, сепак ние ќе се одлучиме да водиме историјат за степенот на образование на родителите, нивните занимања, како и за занимањето на студентот по семестри. запишан_во (индекс_бр*, семестар, тековна_адреса, образ_м, образ_т, заним_м, заним_т, заним_студент)
Во претходниот пример немаше транзитни (преносни) зависности. Во сите примери, покрај опишаните објекти и односи меѓу нив, ќе користиме и знаења за областа за која се однесува задачата.
ЗАДАЧИ 1. Да се извлечат релациите за задачата за резервација на авионски билети преку дадениот ЕА дијаграм.
ПАТНИК (Пат#, имеПатник, адреса, телефон) ПОЛЕТУВАЊЕ (брПолет, датум, брЛет*) ЛЕТ (брЛет, одМесто, доМесто, полетува, слетува) ВРАБОТЕН (шифра, име, адреса, плата) ПИЛОТ (шифра*) ТИПАВИОН (тип#, производител, имеМодел, брМодел) АВИОН (авион#, состојба, брСедишта, серискиБрој, тип#*) УЧЕСТВУВА_ВО (шифра*, брПолет*) РЕЗЕРВАЦИЈА (Пат#*, брПолет*, датум, брЛет) УПРАВУВА_СО (шифра*, тип#*)
2. Да се напишат релациите од кои ќе биде составена релационата база на податоци за библиотечното работење преку дадениот ЕА диј аграм.
СТАВКА (ст#, наслов, инвБр, брПримероци) СПИСАНИЕ (спис#*, број) КНИГА (книг#*, брСтрани, автор#*) АВТОР (автор#, годРаѓање, конт#*) ПРИМЕРОК (прим#, број, статус, заСтавка*) ЧЛЕН (члБрој, адреса, конт#*) ПОЗАЈМИЦА (члБрој*, прим#*, старт, крај, активна) КОНТАКТ (конт#, име, презиме)