Базите данни са релационни. Концепцията за релационна база данни

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

Основни модели

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

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

Основната концепция на релационна база данни

Този модел е разработен през 70-те години от д-р Едгар Код. Това е логически структурирана таблица с полета, описващи данните, взаимоотношенията помежду им, извършените операции и, най-важното, правилата, които гарантират тяхната цялост. Защо моделът се нарича релационна? Тя се основава на отношенията (от латински отношения) между данните. Има много дефиниции за това вида на базата данни. Релационните таблици с информация са много по-лесни за организиране и обработка, отколкото в мрежа или йерархичен модел. Как може да се направи това? Достатъчно е да се познават характеристиките, структурата на модела и свойствата на релационните таблици.

Процесът на моделиране и съставяне на основните елементи

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

Моделирането на таблици и проектирането на релационни бази данни се извършват чрез безплатни инструменти като Workbench, PhpMyAdmin, Case Studio, dbForge Studio. След подробен дизайн, трябва да запазите графично готовия релационен модел и да го преведете в завършения SQL код. На този етап можете да започнете да работите със сортиране, обработка и систематизиране на данни.

Характеристики, структура и термини, свързани с релационния модел

Всеки източник описва неговите елементи по свой начин, така че за по-малко объркване бих искал да дам малка представа:

• релационна плоча = единица;
• layout = атрибути = наименования на полета = заглавието на колоните на обекта;
• entity instance = tuple = запис = ред на етикета;
• стойност на атрибута = целева клетка = поле.

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

1. Essence. Таблицата на релационна база данни може да бъде една и може да бъде цял набор от таблици, които характеризират описаните обекти, благодарение на данните, съхранени в тях. Те имат определен брой полета и променлив брой записи. Таблицата с модели на релационни бази данни се състои от редове, атрибути и оформление.
2. Записът представлява променлив брой редове, които представляват данните, характеризиращи описания обект. Записите се номерират автоматично от системата.
3. Атрибутите са данни, които показват описание на колоните на предприятието.
4. Field. Представлява колона за обект. Техният брой е фиксирана стойност, която е зададена в момента на създаване или промяна на таблицата.

Сега, знаейки съставните елементи на таблицата, можете да отидете на свойствата на базата данни за релационни модели:

• Елементите на релационния ПБ са двуизмерни. Поради тази собственост с тях е лесно да се правят различни логически и математически операции.
• Редът на стойностите на атрибутите и записите в релационната таблица може да бъде произволен.
• Колоната в рамките на една релационна таблица трябва да има свое собствено индивидуално име.
• Всички данни в колоната за обект имат фиксирана дължина и един и същ вид.
• Всеки запис по същество се счита за един елемент от данни.
• Съставните компоненти на линиите са уникални по рода си. В релационната единица няма идентични редове.

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

Основните характеристики на полетата на релационни бази данни

Имената на полетата трябва да са уникални в рамките на едно цяло. Типовете атрибути или полетата на релационни бази данни описват кои категории данни се съхраняват в полетата на обекта. Полето за релационна база данни трябва да има фиксиран размер, преброен с букви. Параметрите и формата на стойностите на атрибутите определят начина, по който коригират данните. Все още има такава концепция като "маска" или "шаблон за въвеждане". Целта е да се определи конфигурацията на въвеждането на данни в стойността на атрибута. Веднага, когато пишете погрешно вид данни в полето трябва да се появи съобщение за грешка. Също така се налагат известни ограничения върху елементите на полето - условията за проверка на точността и точността на въвеждането на данни. Има задължителна стойност на атрибута, която трябва да бъде уникално попълнена с данни. Някои от атрибутите могат да бъдат запълнени с NULL стойности. Разрешено е да въведете празни данни в атрибутите на полето. Подобно на известието за грешка, има и стойности, които се попълват автоматично от системата - това са данните по подразбиране. За да се ускори търсенето на каквито и да било данни, е предназначено индексирано поле.

Двуизмерна схема на таблицата за релационни бази данни

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

Основни правила за нормализиране на релационния обект

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

2. За таблица, която вече е намалена до 1НФ, името на всяка неидентифицираща се колона трябва да зависи от уникалния идентификатор на таблицата (2NF).

3. За цялата таблица, която вече е в 2NF, всяко не-идентифициращо поле не може да зависи от елемента на друга неидентифицирана стойност (3NF обект).

Бази данни: релационни отношения между таблици

Има 2 основни вид взаимоотношения релационни таблици:

• "One-много". Възниква, когато един ключ на таблица # 1 съвпада с няколко копия на второто лице. Иконата на ключа в единия край на линията показва, че обектът е на "една" страна, а вторият край на линията често е отбелязан със символа на безкрайност.

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

Съществуването на ключове в релационна база данни

Основните и вторичните ключове определят потенциалната връзка на базата данни. Релационните отношения между моделите на данни могат да имат само един потенциален ключ, това е първичният ключ. Какво е той? Първичният ключ е колона за обект или набор от атрибути, чрез които можете да осъществите достъп до данните на конкретен ред. Той трябва да е уникален, уникален и неговите полета не могат да съдържат празни стойности. Ако първичният ключ се състои само от един атрибут, тогава той се нарича прост, в противен случай той ще бъде компонент.

В допълнение към първичния ключ има и външен ключ. Мнозина не разбират каква е разликата между тях. Нека ги анализираме по-подробно по пример. Така че има 2 маси: "Офисът на Дийн" и "Студентите". Същността на "Deanery" съдържа полета: "Student ID", "Name" и "Group". Таблицата "Студенти" има такива стойности на атрибутите като "Име", "Група" и "Средна топка". Тъй като идентификационният номер на студента не може да бъде еднакъв за няколко студенти, това поле ще бъде първичният ключ. "Име" и "Груп" от "студентите" на масата може да бъде една и съща за няколко души, те се отнасят до номер на студента от същността на "Дийн", така че те могат да бъдат използвани като външен ключ.

Пример за модел на релационна база данни

За яснота даваме един прост пример за модел на релационна база данни, състоящ се от две единици. Има една таблица, наречена "Deanery".

Трябва да направите връзки, за да получите пълна релационна база данни. Влизане "ИН-41", както и "ИН-72", може да присъства повече от един път в таблицата "Дийн", както фамилия, име и презиме на студентите, в редки случаи, може да бъде един и същ, така че тези полета не могат да бъдат да се направи първичен ключ. Нека да покажем същността на "Студентите".

Както можете да видите, видовете полета на релационни бази данни са напълно различни. Има и цифрови и символични записи. Ето защо в настройките на атрибутите трябва да посочите стойностите на числото, char, vachar, date и др. В таблицата "Deccan" само идентификационният номер на ученика е уникална стойност. Това поле може да се разглежда като основен ключ. Името, групата и телефонният номер от организацията "Студенти" могат да се разглеждат като чужд ключ, посочващ идентификационния номер на студента. Създадена е комуникация. Това е пример за модел "един към един". Хипотетично една от таблиците е излишна, те лесно могат да се комбинират в една цялост. Идентификационните номера на студентите не стават всеобщо известни, но е напълно реално съществуване на две маси.