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

Моделът на релационната база данни е метод за структуриране на данни с помощта на взаимоотношения, като се използват структури, подобни на решетка, състоящи се от колони и редове. Това е концептуалният принцип на релационните бази данни. Той е предложен от Едгар Ф. Код през 1969г.

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

Източник: pixabay.com

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

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

Управление на база данни

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

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

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

Повечето релационни бази данни използват SQL езика за запитване и дефиниране на данните. Понастоящем има много системи за управление на релационни бази данни или RDBMS (система за управление на релационни бази данни), като Oracle, IBM DB2 и Microsoft SQL Server.

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

- Всички данни се представят концептуално като подредено подреждане на данни в редове и колони, наречени отношение или таблица.

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

- Всички стойности са скалари. Тоест, при всяка позиция на ред / колона в таблицата има само една стойност.

-Elements

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

кортеж

Всеки ред данни е сборник, известен също като запис. Всеки ред е n-кортеж, но обикновено „n-“ се изхвърля.

Колона

Всяка колона в кортеж се нарича атрибут или поле. Колоната представлява набора от стойности, които може да има конкретен атрибут.

ключ

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

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

-Правила на целостта

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

Ключова цялост

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

За клавиш с много колони нито една от тези колони не може да съдържа NULL.

Референтна цялост

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

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

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

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

-Събиране на данни

Необходимите данни трябва да бъдат събрани, за да се съхраняват в базата данни. Тези данни са разделени в различни таблици.

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

-Определете първичните ключове

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

-Създаване на връзки между таблици

База данни, състояща се от независими, несвързани таблици, служи за малка цел.

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

Един към много

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

Тази връзка не може да бъде представена в една таблица. В базата данни «Списък на класовете» можете да имате таблица, наречена Учители, която съхранява информация за учителите.

За да съхранявате класовете, преподавани от всеки учител, бихте могли да създадете допълнителни колони, но ще срещнете проблем: колко колони да създадете.

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

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

Оформете две таблици

Следователно, трябва да проектирате две таблици: таблица Classes, която да съхранява информация за класовете, като Class_Id е първичен ключ и таблица Teachers за съхраняване на информация за учителите, като Teacher_Id е първичен ключ.

Връзката между един и много може да бъде създадена чрез съхраняване на основния ключ от таблицата Master (Master_Id) в таблицата Classes, както е показано по-долу.

Графата Master_Id в таблицата Classes е известна като чужд ключ или вторичен ключ.

За всяка стойност Master_Id в таблицата Master може да има нула или повече редове в таблицата Classes. За всяка стойност на Class_Id в таблицата Класове има само един ред в таблицата Учители.

Много на мнозина

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

Можете да стартирате базата данни "Продажби на продукти" с две таблици: Продукти и поръчки. Таблицата с продукти съдържа информация за продуктите, като productID е основен ключ.

От друга страна, таблицата Поръчки съдържа поръчките на клиента, като orderID е основен ключ.

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

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

За таблицата OrderDetails първичният ключ се състои от две колони: orderID и productID, уникално идентифициращи всеки ред.

Графите orderID и productID в таблицата OrderDetails се използват за справка в таблиците за поръчки и продукти. Следователно те също са чужди ключове в таблицата на OrderDetails.

Един по един

В базата данни "Продажба на продукти" един продукт може да има незадължителна информация, като допълнително описание и неговото изображение. Съхраняването му в таблицата „Продукти“ ще генерира много празни пространства.

Следователно може да се създаде друга таблица (ProductExtras), която да съхранява незадължителните данни. Ще бъде създаден само един запис за продукти с незадължителни данни.

Двете таблици, Продукти и ProductExtras, имат връзка едно към едно. За всеки ред в таблицата Продукти има максимум един ред в таблицата ProductExtras. Същият продуктID трябва да се използва като основен ключ и за двете таблици.

предимство

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

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

Когато е възможно да се правят промени в структурата на базата данни, без да се засяга способността на СУБД да получава достъп до данните, може да се каже, че е постигната структурна независимост.

Концептуална простота

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

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

Лесно проектиране, внедряване, поддръжка и употреба

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

Капацитет на специални заявки

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

Езикът на заявките на модела на релационна база данни, наречен структуриран език на заявките или SQL, превръща ad-hoc заявките в реалност. SQL е четвърто поколение език (4GL).

4GL позволява на потребителя да посочи какво трябва да се направи, без да посочва как трябва да се направи. По този начин, чрез SQL, потребителите могат да посочат каква информация искат и да оставят подробности как да получат информацията в базата данни.

Недостатъци

Хардуерни разходи

Моделът на релационната база данни крие сложността на нейното внедряване и подробностите за физическото съхранение на потребителски данни.

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

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

Лесността на дизайна може да доведе до лош дизайн

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

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

С нарастването на базата данни лошо проектираните бази данни ще забавят системата и ще доведат до влошаване на производителността и корупция на данните.

Феномен на «информационните острови»

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

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

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

пример

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

Всеки ред в таблицата на доставчиците се идентифицира с уникален номер на доставчика (SNo), уникално идентифициращ всеки ред в таблицата. По същия начин всяка част има уникален номер на част (PNo).

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

Връзката между таблиците за части и пратки е дадена, като общото поле PNo (номер на част) е общо и връзката между доставчиците и пратките възниква, като общото поле SNO (номер на доставчика) е общо.

Анализирайки таблицата за доставки, може да се получи информация, че от доставчици на Suneet и Ankit се изпращат общо 500 ядки, по 250 всеки.

По същия начин, общо 1100 болта са изпратени от три различни доставчици. 500 сини винта са изпратени от доставчика на Suneet. Няма пратки с червени винтове.

Препратки

1. Уикипедия, безплатната енциклопедия (2019). Релационен модел. Взета от: en.wikipedia.org.
2. Техопедия (2019). Релационен модел. Взета от: roofpedia.com.
3. Динеш Тхакур (2019). Релационен модел. Бележки за електронния компютър. Взета от: ecomputernotes.com.
4. Geeks за Geeks (2019). Релационен модел. Взета от: geeksforgeeks.org.
5. Nanyang Technological University (2019). Ръководство за бързо стартиране на дизайна на релационни бази данни. Взето от: ntu.edu.sg.
6. Адриен Ват (2019). Глава 7 Моделът на релационните данни. BC Open учебници. Взета от: opentextbc.ca.
7. Toppr (2019). Релационни бази данни и схеми. Взета от: toppr.com.