МОДЕЛ РЕЛАЦИОНЕ БАЗЕ ПОДАТАКА: ЕЛЕМЕНТИ, КАКО ТО УРАДИТИ, ПРИМЕР - ТЕХНОЛОГИЈА - 2025

Модел релационе базе података је метода структурирања података користећи односе, користећи структуре сличне мрежи, које се састоје од ступаца и редова. То је концептуални принцип релацијских база података. Предложио га је Едгар Ф. Цодд 1969. године.

Од тада је постао доминантан модел базе података за пословне апликације, у поређењу са другим моделима база података, као што су хијерархијски, мрежни и објектни.

Извор: пикабаи.цом

Цодд није имао појма колико ће бити изузетно важан и утицајан његов рад као платформа за релацијске базе података. Већина људи је врло добро упозната са физичким изразом односа у бази података: табела.

Релацијски модел је дефинисан као база података која омогућава груписање његових елемената података у једну или више независних табела, које се могу међусобно повезати употребом поља заједничких за сваку сродну табелу.

Управљање базама података

Табела базе података слична је табели. Међутим, односи који се могу створити између табела омогућавају да релациона база података ефикасно чува велику количину података, што се може ефективно дохватити.

Сврха релацијског модела је пружити декларативну методу за специфицирање података и упита: корисници директно изјављују које податке садржи база података и које информације желе од њих.

С друге стране, они га остављају софтверу система за управљање базама података како би описали структуре података за складиштење и поступак преузимања како би одговорили на упите.

Већина релацијских база података користи СКЛ језик за постављање упита и дефинирање података. Тренутно постоји много система за управљање релацијским базама података или РДБМС (систем за управљање релацијском базом података), као што су Орацле, ИБМ ДБ2 и Мицрософт СКЛ Сервер.

Карактеристике и елементи

- Сви подаци су концептуално представљени као уређени распоред података у редовима и ступовима, који се називају релација или табела.

- Свака табела мора имати заглавље и тело. Заглавље је једноставно листа ступаца. Тело је скуп података који испуњава табелу, организован у редове.

- Све вредности су скалари. То јест, у било којој позицији ретка / ступца у табели постоји само једна вредност.

-Елементс

Следећа слика приказује табелу са именима њених основних елемената, који чине потпуну структуру.

Тупле

Сваки ред података је збир, познат и као запис. Сваки ред је н-тавор, али "н-" се углавном одбацује.

Ступац

Сваки се ступац у збиру назива атрибутом или пољем. Ступац представља скуп вредности које одређени атрибут може имати.

Кључ

Сваки ред има један или више ступаца који се називају кључ таблице. Ова комбинована вредност је јединствена за све редове у табели. Помоћу овог кључа сваки ће се крафник јединствено идентификовати. Односно, кључ се не може дуплирати. Зове се примарним кључем.

С друге стране, страни или секундарни кључ је поље у табели које се односи на примарни кључ неке друге табеле. Користи се за референцу на примарну табелу.

- Правила интегритета

Приликом дизајнирања релацијског модела, дефинишете неке услове који морају бити испуњени у бази података, а називају се правила интегритета.

Кључни интегритет

Примарни кључ мора бити јединствен за све туполе и не може бити нула (НУЛЛ). У супротном, нећете моћи јединствено идентификовати ред.

За кључ са више ступаца, ниједан од тих ступаца не може садржавати НУЛЛ.

Референтна интегритет

Свака вриједност страног кључа мора одговарати вриједности примарног кључа референциране или примарне таблице.

Редак са страним кључем може бити убачен у секундарну табелу само ако та вредност постоји у примарној табели.

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

Како направити релациони модел?

-Прикупља податке

Потребни подаци морају се прикупити да би се сачували у бази података. Ови подаци су подељени у различите табеле.

За сваку колону мора бити изабран одговарајући тип података. На пример: цели бројеви, бројеви с помичним зарезом, текст, датум итд.

-Дефинисати примарне кључеве

За сваку таблицу као примарни кључ мора бити изабран ступац (или неколико ступаца), који ће јединствено идентификовати сваки ред у табели. Примарни кључ се такође користи за упућивање на друге табеле.

-Направите односе између табела

База података која се састоји од независних, неповезаних табела мало служи.

Најважнији аспект у дизајнирању релацијске базе података је идентификација односа између табела. Типови односа су:

Један многима

У бази података „Класе с пописом класа“, наставник може подучавати нулу или више часова, док један разред предава један наставник. Ова врста односа позната је као један-многима.

Тај однос не може бити представљен у једној табели. У бази података «Листа часова» можете имати табелу под називом Учитељи, у којој се чувају информације о наставницима.

Да бисте сачували часове које подучава сваки наставник, могли бисте да направите додатне ступце, али суочили бисте се са проблемом: колико ступаца да креирате.

С друге стране, ако имате табелу под називом Класе која чува информације о предавању, можете да креирате додатне ступце за смештање података о учитељу.

Међутим, будући да наставник може да предаје многе часове, његови подаци ће се умножити у више редова у табели Класе.

Дизајнирајте две табеле

Стога је потребно да дизајнирате две табеле: таблицу класе за чување информација о класама, са Цласс_Ид као примарним кључем, и табелу наставника за спремање података о наставницима, са Теацхер_Ид као примарним кључем.

Однос један према многима се тада може створити чувањем примарног кључа из матичне таблице (Мастер_Ид) у табели Класе, као што је илустровано у наставку.

Ступац Мастер_Ид у табели Цлассес познат је као инострани или секундарни кључ.

За сваку вриједност Мастер_Ид у табели Мастер може бити нула или више редова у табели Цлассес. За сваку вриједност Цласс_Ид у табели Цлассес постоји само један ред у табели Теацхерс.

Многи до многих

У бази података „Продаја производа“ наруџба купца може садржати више производа, а производ се може појавити у више поруџбина. Ова врста односа је позната као многима.

Базу података "Продаја производа" можете започети са две табеле: Производи и поруџбине. Табела производа садржи информације о производима, а продуцтИД је примарни кључ.

С друге стране, табела Наруџбенице садржи наруџбе корисника, а ордерИД је примарни кључ.

Наручене производе не можете похранити у табелу Наруџбе јер не знате колико ступаца да резервишете за производе. Наручивања се такође не могу чувати у табели Производи из истог разлога.

Да бисте подржали однос многих према многима, морате да направите трећу табелу, познату и као табела придруживања (ОрдерДетаилс), где сваки ред представља ставку одређеног реда.

За таблицу ОрдерДетаилс примарни кључ састоји се од два ступца: ордерИД и продуцтИД, јединствено идентификујући сваки ред.

Ступци ордерИД и продуцтИД у табели ОрдерДетаилс користе се за упућивање у таблице Наруџбе и производи. Стога су и страни кључеви у табели ОрдерДетаилс.

Један по један

У бази података "Продаја производа" производ може имати опционе информације, као што су додатни опис и његова слика. Ако га задржите у табели Производи, створићете пуно празних простора.

Због тога се може креирати друга табела (ПродуцтЕктрас) која чува факултативне податке. Створиће се само један запис за производе са опционим подацима.

Две табеле, производи и ПродуцтЕктрас, имају однос један на један. За сваки ред у табели Производи налази се највише један ред у табели ПродуцтЕктрас. Исти продуцтИД мора се користити као примарни кључ за обје табеле.

Предност

Структурна независност

У моделу релационе базе података, промене у структури базе података не утичу на приступ подацима.

Када је могуће извршити промене у структури базе података без утицаја на способност ДБМС-а да приступа подацима, може се рећи да је постигнута структурна независност.

Концептуална једноставност

Модел релацијске базе података је још концептуално једноставнији од хијерархијског или мрежног модела базе података.

Будући да модел релационе базе података дизајнеру олакшава детаље физичког чувања података, дизајнери се могу фокусирати на логички приказ базе података.

Једноставност дизајна, имплементације, одржавања и употребе

Модел релационе базе података постиже и независност података и неовисност структуре, што дизајн, одржавање, управљање и употребу базе података чини много лакшим од осталих модела.

Капацитет ад-хоц упита

Присуство веома моћне, флексибилне и лако упитане могућности један је од главних разлога огромне популарности модела релационе базе података.

Језик упита модела релационе базе података, зван структурирани језик упита, или СКЛ, ад-хоц упите чини стварношћу. СКЛ је језик четврте генерације (4ГЛ).

4ГЛ омогућава кориснику да прецизира шта треба учинити, без навођења начина на који то треба учинити. На тај начин, помоћу СКЛ-а, корисници могу одредити које информације желе и оставити детаље о томе како да дођу до података у базу података.

Недостаци

Трошкови хардвера

Модел релационе базе података скрива сложености његове имплементације и детаље физичког чувања корисничких података.

Да бисте то учинили, системима релацијских база података потребни су рачунари са снажнијим хардвером и уређајима за чување података.

Због тога је РДБМС-у потребне снажне машине како би се несметано одвијао. Међутим, како моћ обраде савремених рачунара расте експоненцијално, потреба за већом процесорском снагом у данашњем сценарију више није велики проблем.

Једноставност дизајна може довести до лошег дизајна

Релативна база података је једноставна за дизајн и употребу. Корисници не морају знати сложене детаље физичког чувања података. Не морају знати како се подаци заправо чувају да би им приступили.

Ова једноставност дизајнирања и употребе може довести до развоја и примене лоше дизајнираних система за управљање базама података. Пошто је база података ефикасна, ове неефикасности у пројектовању неће доћи до изражаја када је база података дизајнирана и када постоји само мала количина података.

Како база података расте, лоше дизајниране базе података успорит ће систем и довести до погоршања перформанси и корупције података.

Феномен „информационих острва“

Као што је већ поменуто, релациони системи база података су лако имплементирани и употребљени. То ће створити ситуацију када ће превише људи или одељења стварати сопствене базе података и апликације.

Ова острва информација ће спречити интеграцију информација, што је неопходно за несметано и ефикасно функционисање организације.

Ове појединачне базе података такође ће створити проблеме као што су недоследност података, умножавање података, редундантност података, итд.

Пример

Претпоставимо базу података која се састоји од табела добављача, делова и пошиљки. Структура табела и неких примера је следећа:

Сваки ред у табели добављача идентификован је јединственим бројем добављача (СНо), јединствено идентификујући сваки ред у табели. Исто тако, сваки дио има јединствени број дијела (ПНо).

Надаље, не може бити више пошиљака за дату комбинацију добављача / дијелова у табели пошиљака, јер је ова комбинација примарни кључ пошиљки, који служи као синдикална таблица, јер је однос између многих и многих.

Однос између таблица дијелова и пошиљака је дан заједничким пољем ПНо поља (број дијела), а однос између добављача и пошиљака настаје заједничким снагом СНо поља (добављачког броја).

Анализом таблице испорука може се добити информација да се од добављача Сунеет и Анкит шаље укупно 500 ораха, сваки са 250.

Слично томе, укупно је испоручено 1.100 вијака од три различита добављача. 500 плавих шрафова испоручено је од добављача Сунеет. Нема испорука црвених шрафова.

Референце

1. Википедија, бесплатна енциклопедија (2019). Релативни модел. Преузето са: ен.википедиа.орг.
2. Техопедиа (2019). Релативни модел. Преузето са: роофпедиа.цом.
3. Динесх Тхакур (2019). Релативни модел. Е-компјутерске белешке. Преузето са: ецомпутернотес.цом.
4. Геекс за Геекс (2019). Релативни модел. Преузето са: геексфоргеекс.орг.
5. Нанианг Технолошки универзитет (2019). Водич за брзи почетак о дизајну релативних база података. Преузето са: нту.еду.сг.
6. Адриенне Ватт (2019). Поглавље 7 Модел релационих података. БЦ Отворени уџбеници. Преузето са: опентектбц.ца.
7. Топпр (2019). Релативне базе података и шеме. Преузето са: топпр.цом.