Основни понятия на релационния модел на данни - файл Основни понятия на релационния модел на данни.doc. Как са проектирани базите данни. Основни концепции за релационни бази данни

Раздел 3. „Бази данни“

1. Информационна поддръжкаавтоматизирани системи.

Информационна поддръжка на автоматизирана система (АС) - набор от формуляри на документи, класификатори, нормативна уредбаи реализирани решения за обема, разположението и формите на съществуване на информацията, използвана в АС по време на нейното функциониране

Съгласно GOST 24.205-80 описанието на информационната поддръжка на автоматизираната система за управление трябва да се състои от следните раздели:

принципи на организиране на информационната поддръжка;

организиране на събиране и предаване на информация;

изграждане на система за класификация и кодиране;

организация на вътрешномаш информационна база;

организиране на извънмашинна информационна база.

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

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

Информационната поддръжка на автоматизирана система е набор от формуляри на документи, класификатори, регулаторна рамка и внедрени решения относно обема, разположението и формите на съществуване на информацията, използвана в автоматизираната система по време на нейната работа (GOST 34.003-90 (" Автоматизирани системи. Термини и определения")).

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

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

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

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

AI автоматизиран информационни системисе състои от извънмашинен и вътрешен AI.

Extra-machine включва система за класификация и кодиране на техническа и икономическа информация; документационна система; диаграма на информационния поток (документооборот: първични, резултатни, нормативни и справочни документи).

Вътрешномашинната информация съдържа масиви от данни на машинен носител и програма за организиране на достъпа до тези данни.

Извънмашинен AI - информация, която се възприема от човек без никаква технически средства(документация).

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

2. СУБД и приложения за бази данни.

Системата за управление на бази данни (СУБД) е комплекс от език и софтуер, които осигуряват контрол върху създаването и използването на бази данни.

Модерната СУБД се състои от:

ядра - части от СУБД програми, отговорни за управление на данни в паметта и логване; Езиков процесор за база данни, осигуряващ оптимизиране на заявки за извличане и промяна на данни и създаване на база данни;

Подсистеми за поддръжка по време на изпълнение, които интерпретират програми за манипулиране на данни, които създават потребителския интерфейс на СУБД;

Сервизни програми(външни помощни програми), които предоставят други възможности за поддържане на информационни системи.

Основните функции на СУБД са

Управление на данни, съхранявани във външна памет;

Управление на данни, качени в RAMизползване на дисков кеш; Регистриране на събития и промени, архивиранеи възстановяване на бази данни след повреди;

Поддръжка на езици за работа с бази данни (език за дефиниране на данни, език за манипулиране на данни);

СУБД класификации

Има няколко критерия, по които може да се класифицира СУБД.

СУБД, базирани на модела на данни, са:

Йерархична СУБД, Мрежова СУБД, Релационна СУБД, Обектно-ориентирана СУБД, Обектно-релационна СУБД. В момента последните 2 вида се използват в сериозни проекти. СУБД по степен на разпространение. Локална (СУБД е разположена само на един компютър) Разпределена (части от СУБД могат да бъдат разположени на 2 или повече компютъра).

Приложения за база данни

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

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

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

Механизмът за получаване и изпращане на данни осигурява връзка с източника на данни (често индиректно). Той трябва да „знае“ къде да отиде и какъв комуникационен протокол да използва, за да осигури двупосочен поток от данни.

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

Потребителски интерфейсосигурява преглед и редактиране на данни, както и управление на данните и приложението като цяло.

Бизнес логиката на приложението е набор от алгоритми за обработка на данни, внедрени в програмата.

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

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

3. Съвременна концепция за релационни бази данни.

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

Преди да разгледаме подробно всяка от тези стъпки, нека прегледаме основните концепции на релационните бази данни. В релационната теория едно от основните е понятието връзка. Математически съотношението се определя по следния начин. Нека са дадени n множества D1,D2,...,Dn. Тогава R е релация над тези набори, ако R е набор от подредени набори от формата , където d1 е елемент от D1, d2 е елемент от D2, ..., dn е елемент от Dn. В този случай набори от формата се наричат ​​кортежи, а множествата D1,D2,...,Dn се наричат ​​домейни. Всеки кортеж се състои от елементи, избрани от техните домейни. Тези елементи се наричат ​​атрибути, а техните стойности са стойности на атрибути, Фиг. 9-а ни представя графично изображениеотношения от различни гледни точки.

Лесно е да се види, че връзката е отражение на някаква същност на реалния свят (в в такъв случай- обект „подробност“) и от гледна точка на обработката на данни е таблица. Кортежът е ред в таблица или, еквивалентно, запис. Атрибутът е колона в таблица или поле в запис. Домейнът е представен като вид обобщен тип, който може да бъде източник за типове полета в запис. Следователно следните тройки термини са еквивалентни:

отношение, таблица

кортеж, низ, запис

атрибут, колона, поле.

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

Атрибут (или набор от атрибути), който може да се използва за уникално идентифициране на определен кортеж (ред, запис), се нарича първичен ключ. Първичният ключ не трябва да има допълнителни атрибути. Това означава, че ако произволен атрибут бъде изключен от първичния ключ, останалите атрибути няма да са достатъчни за еднозначно идентифициране на отделни кортежи. За да се ускори достъпът до първичния ключ, всички системи за управление на бази данни (СУБД) имат механизъм, наречен индексиране. Грубо казано, индексът е обърнат дървовиден списък, сочещ към истинското местоположение на запис за всеки първичен ключ. Естествено, индексите се изпълняват по различен начин в различните СУБД (в локалните СУБД, като правило, във формата отделни файлове), обаче принципите на организацията им са същите.

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

За да поддържат референтната цялост на данните, много СУБД имат механизъм на така наречените външни ключове. Смисълът на този механизъм е, че на определен атрибут (или група от атрибути) на една релация се присвоява връзка към първичния ключ на друга релация; като по този начин укрепва връзките на подчинение между тези взаимоотношения. В този случай релация, чийто първичен ключ е рефериран от външен ключ на друга релация, се нарича главна релация или основна релация; и връзката, от която идва връзката, се нарича детайлна връзка или подчинена връзка. След задаване на такава връзка, СУБД има възможност автоматично да наблюдава проблемите на „ненарушаване“ на връзките между връзките, а именно:

ако се опитате да вмъкнете запис в подчинена таблица, за който външният ключ няма съвпадение в основната таблица (например все още няма запис с такъв първичен ключ), СУБД ще генерира грешка;

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

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

ДОПЪЛНЕНИЕ

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

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

Тип данни

Концепция тип даннив релационния модел на данни е напълно адекватен на понятието тип данни в езиците за програмиране. Обикновено съвременните релационни бази данни позволяват съхранението на знаци, числови данни, битови низове, специализирани числови данни (като „пари“), както и специални „времеви“ данни (дата, час, интервал от време). Доста активно се развива подход за разширяване на възможностите на релационните системи с абстрактни типове данни (например системите от семейството Ingres / Postgres имат съответните възможности). В нашия пример имаме работа с три типа данни: символни низове, цели числа и "пари".

Домейн

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

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

Трябва също да се отбележи семантичното натоварване на концепцията за домейн: данните се считат за сравними само ако принадлежат към един и същи домейн. В нашия пример стойностите на домейна "Gap Numbers" и "Group Numbers" са от тип цяло число, но не са сравними. Имайте предвид, че повечето релационни СУБД не използват концепцията за домейн, въпреки че Oracle V.7 вече я поддържа.

Релационните бази данни са най-често срещаните в момента, въпреки че наред с общопризнатите предимства имат и редица недостатъци. Предимствата на релационния подход включват:

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

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

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

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

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

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

Концепция тип данни в релационния модел на данни е напълно адекватен на понятието тип данни в езиците за програмиране. Обикновено съвременните релационни бази данни позволяват съхранението на знаци, числови данни, битови низове, специализирани числови данни (като „пари“), както и специални „времеви“ данни (дата, час, интервал от време). Доста активно се развива подход за разширяване на възможностите на релационните системи с абстрактни типове данни (например системите от семейството Ingres / Postgres имат съответните възможности).

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

Таблицае основният тип структура от данни (обект) на релационния модел. Структурата на таблицата се определя от колекцията колони.Всеки ред от таблицата съдържа една стойност в съответния колона.В една таблица не може да има два еднакви реда. Общият брой на линиите не е ограничен.

Колонасъответства на някакъв елемент от данни – атрибут което е най-простата структура от данни. Една таблица не може да дефинира множество елементи, група или повтаряща се група, както в мрежовите и йерархичните модели, обсъдени по-горе. Всяка колона на таблицата трябва да има Имесъответния елемент от данни (атрибут).

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

Релационна таблица-релация.На фиг. Фигура 9 показва илюстрация на релационна таблица-релация Р. Формална дефиниция връзка R (релационна таблица) разчита на изглед на своя домейнид аз, (колони) и кортежи К j (линии). Връзка R, дефинирана върху набори от домейни (D i ), е подмножество Декартово (пряко) произведение на домейни D 1 *D 2 *…..*D n

Таблица-релация(виж фиг. 1) съдържа колони с имената на елементи от данни - атрибути (A 1, A 2, ...). Стойностите на d атрибутите са в съдържателната част на таблицата и образуват редове и колони. Множество стойности на атрибути в една колона образуват едно домейн D i. Множество стойности на атрибути в един ред образуват едно кортеж K j . Поведение R се образува от набор от подредени кортежи.

R=(Kj), J=1- m Kj=(d 1j, d 2 j,…d nj),

където n е броят на релационните области; определя релационно измерение;

j – номер на кортеж;

m е общият брой кортежи в релацията, наречена координационен номервръзка.

Фиг.9. Илюстрация на таблица за релационни релации

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

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

Трябва също да се отбележи семантичното натоварване на концепцията за домейн: данните се считат за сравними само ако принадлежат към един и същи домейн. В нашия пример стойностите на домейна "Gap Numbers" и "Group Numbers" са от тип цяло число, но не са сравними. Имайте предвид, че повечето релационни СУБД не използват концепцията за домейн, въпреки че вече се поддържа в август V.7.

Релационна схема, схема на база данни. Схемата на връзка е наименуван набор от двойки (име на атрибут, име на домейн (или тип, ако концепцията за домейн не се поддържа)). Степента или "арността" на релационна схема е кардиналността на този набор. Степента на връзката ПРИМЕР е ШЕСТ, тоест тя е 6-арна. Ако всички атрибути на една релация са дефинирани в различни домейни, има смисъл да се използват имената на съответните домейни, за да се наименуват атрибутите (като помните, разбира се, че това е просто по удобен начинименуване и не премахва разликата между понятията домейн и атрибут). Схемата на база данни (в структурен смисъл) е набор от наименувани схеми на релации.

Списък, който дава имената на релационните таблици, изброявайки техните атрибути (ключовете са подчертани) и дефиниции на външни ключове, се нарича схема на релационна база данни.Това е предварителен резултат от създаването на сцената жизнен цикълрелационна база данни. Пример:

РАБОТНИК [ РАБОТНИК-ID, ИМЕ, ПОЧАСОВА СТАВКА, ТИП УМЕНИЕ, SVPV-ID]

Външни ключове: SKILL-TYPE се отнася до SKILL

SVPV-ID се отнася за РАБОТНИК

ЗАДАНИЕ [ РАБОТНИК-ID, BLDG-ID, НАЧАЛНА ДАТА, БРОЙ-ДНИ]

Външни ключове: WORKER-ID се отнася за WORKER

BLDG-ID се отнася до BVILDING

BVILDING [ BLDG-ID, АДРЕС, ТИП, НИВО НА QLTY, STATVS]

УМЕНИЕ [ ТИП УМЕНИЕ, БОНУСНА СТАВКА, ЧАСОВЕ НА СЕДМИЦА]

Кортеж, родн. Кортеж, съответстващ на дадена схема на релация, е набор от двойки (име на атрибут, стойност), който съдържа едно срещане на всяко име на атрибут, принадлежащо на схемата на релация. „Стойност“ е валидна стойност за домейна на даден атрибут (или данни тип, ако концепцията за домейн не се поддържа). По този начин степента или „арността“ на кортеж, т.е. броят на елементите в него, съвпада с „арността“ на съответната релационна схема. Казано по-просто, кортежът е набор на именувани стойности от даден тип.

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

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

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

Релационна база данни е набор от релации, чиито имена са същите като имената на схемите на релациите в схемата на базата данни.

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

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

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

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

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

Свързана информация.

Обща характеристика на релационния модел на данни

Основите на релационния модел на данни бяха очертани за първи път в статия от E. Codd през 1970 г. Тази работа послужи като тласък за голям брой статии и книги, в които релационният модел беше доразвит. Най-често срещаната интерпретация на релационния модел на данни принадлежи на К. Дата. Според Date релационният модел се състои от три части:

• 
  Конструктивна част.
• 
  Цялата част.
• 
  Манипулационна част.

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

Манипулационна част описва два еквивалентни начина за манипулиране на релационни данни - релационна алгебра И релационно смятане .

Тази глава разглежда структурната част на релационния модел.

^ Типове данни

Всички данни, използвани в програмирането, имат свои собствени типове данни.

важно!Релационният модел изисква типовете използвани данни да бъдат просто.

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

• 
  Прости типове данни.
• 
  Структурирани типове данни.
• 
  Референтни типове данни.

Прости или атомарни типове данни нямат вътрешна структура. Този тип данни се наричат скалари . Простите типове данни включват следните типове:

• 
  Логично.
• 
  низ.
• 
  Числен.

• 
  Цял.
• 
  истински.
• 
  Дата на.
• 
  време.
• 
  Парични.
• 
  Изброими.
• 
  Интервал.
• 
  и т.н.

^

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

• 
  Масиви
• 
  Записи (структури)

Нарича се набор от индекси. Дисплей

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

Запис (или структура) е кортеж от някакво декартово произведение от множества. Наистина, записът е наименуван, подреден набор от елементи, всеки от които принадлежи към тип. Така че влизането е елемент от множеството . Чрез деклариране на нови типове записи на базата на съществуващи типове, потребителят може да конструира произволно сложни типове данни.

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

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

Когато работим с прости типове данни, например числови, ние ги манипулираме като неделими цели обекти. За да „видим“, че числовият тип данни всъщност е сложен (колекция от битове), трябва да преминем към по-ниско ниво на абстракция. На ниво програмен код това ще изглежда като вмъкване на асемблиране в кода на езика високо нивоили използването на специални битови операции.

^ Референтни типове данни

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

^ Типове данни, използвани в релационния модел

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

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

Точно така някои пост-релационни СУБД реализират работа с произволно сложни типове данни, създадени от потребителите.

Домейни

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

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

• 
  Домейнът има уникално име(в базата данни).
• 
  Домейнът е определен в някои простотип данни или в различен домейн.

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

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

Основното значение на домейните е това домейните ограничават сравненията. Логически е неправилно да се сравняват стойности от различни домейни, дори и да са от един и същи тип. Това разкрива семантичното ограничение на домейните. Синтактично правилна заявка„дава списък на всички части, чието тегло на детайла е по-голямо от наличното количество” не отговаря на смисъла на понятията „количество” и „тегло”.

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

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

Коментирайте. Не винаги е очевидно как да зададете булево условие, което ограничава възможните стойности на домейн. Ще бъда благодарен на всеки, който може да ми предостави условие за низов тип данни, който указва домейна "Фамилия на служител". Ясно е, че редовете, които са фамилни имена, не трябва да започват с цифри, служебни знаци, мек знак и др. Но приемливо ли е фамилното име „Ggggggyyyyy“? Защо не? Очевидно не! Или може би някой ще се нарече така от злоба. Трудности от този вид възникват, защото значението на реалните явления не винаги може да бъде формално описано. Просто ние, като всички хора, интуитивно разбираме какво е фамилно име, но никой не може да даде такава формална дефиниция, която да разграничи фамилните имена от низовете, които не са фамилни имена. Изходът от тази ситуация е прост - разчитайте на интелигентността на служителя, който въвежда имена в компютъра.

^ Релации, атрибути, релационни кортежи

Определения и примери

Основната концепция на релационния модел на данни е концепцията връзка . При дефинирането на понятието връзка ще следваме книгата на К. Дате.

Определение 1. Атрибут на връзката има няколко такива<Имя_атрибута: Имя_домена>.

Имената на атрибутите трябва да са уникални в рамките на връзката. Често имената на атрибутите на една връзка са същите като имената на съответните домейни.

Определение 2. Поведение , дефиниран в множество домейни (не непременно различни), съдържа две части: заглавка и тяло.

Заглавие на връзката съдържа фиксиран брой атрибути на релация:

Връзка на тялото съдържа много релационни кортежи. Всеки кортежна релация представлява набор от двойки на формата<Имя_атрибута: Значение_атрибута>:

Така че стойността на атрибута да принадлежи към домейна

Връзката обикновено се записва като:

Или по-кратко

,

Или просто

Броят на атрибутите в една релация се нарича степен (или -арност ) връзка.

Мощността на набор от кортежи на релация се нарича мощност връзка.

Връщайки се към математическата концепция за отношение, въведена в предишната глава, можем да направим следните заключения:

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

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

Пример 1 . Нека разгледаме релацията "Служители", дефинирана в домейните "Номер_на_служител", "Фамилия", "Заплата", "Номер_на_отдел". защото Тъй като всички домейни са различни, е удобно атрибутите на релацията да се именуват по същия начин като съответните домейни. Заглавката на релацията изглежда така:

Служители (Employee_number, Фамилия, Заплата, Department_number)

Нека релацията в момента съдържа три кортежа:

(1, Иванов, 1000, 1)

(2, Петров, 2000, 2)

(3, Сидоров, 3000, 1)

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

^ Таблица 1 Връзка „Служители“

Определение 3. Релационна база данни наречен набор от отношения.

Определение 4. Схема на релационна база данни

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

Термините, с които оперира релационният модел на данни, имат съответните „таблични“ синоними:

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

1. 
   ^ В една релация няма идентични кортежи . Всъщност тялото на връзката е няколкокортежи и като всяко множество не може да съдържа неразличими елементи (вижте концепцията за набор в глава 1.). Таблиците, за разлика от връзките, могат да съдържат еднакви редове.
2. 
   ^ Кортежите не са подредени (отгоре надолу) . Наистина, въпреки факта, че сме изобразили релацията „Служители” под формата на таблица, не може да се каже, че служител Иванов „предхожда” служител Петров. Причината е същата – тялото на релацията е множество, а множеството не е подредено. Това е втората причина, поради която връзките и таблиците не могат да бъдат идентифицирани - редовете в таблиците са подредени. Същата връзка може да бъде изобразенразлични таблици, в които редовете са в различен ред.
3. 
   ^ Атрибутите не са подредени (отляво надясно) . защото Всеки атрибут има уникално име в рамките на връзката, тогава редът на атрибутите няма значение. Това свойство донякъде отличава релация от математическата дефиниция на релация (вижте глава 1 - компоненти на кортежи там поръчан). Това е и третата причина, поради която връзките и таблиците не могат да бъдат приравнени - колоните в таблицата са подредени. Същата връзка може да бъде изобразенразлични таблици, в които колоните са в различен ред.
4. 
   ^ Всички стойности на атрибути са атомарни . Това следва от факта, че основните атрибути имат атомарни стойности. Това е четвъртата разлика между релациите и таблиците - можете да поставите всичко в клетките на таблицата - масиви, структури и дори други таблици.

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

• 
  Таблиците имат еднакъв брой колони.
• 
  Таблиците съдържат колони с еднакви имена.
• 
  Колоните с еднакви имена съдържат данни от едни и същи домейни.
• 
  Таблиците имат еднакви редове, но редът на колоните може да варира.

^ Първа нормална форма

Най-трудно е да се дефинират неща, които всички разбират. Ако не дадете стриктна, описателна дефиниция, тогава винаги има възможност за нейното неправилно тълкуване. Ако дадем строга формална дефиниция, тогава, като правило, тя е или тривиална, или твърде тромава. Точно такава е ситуацията с определението за връзка в Първа нормална форма (1NF ). Невъзможно е изобщо да не говорим за това, защото... Въз основа на 1NF се конструират по-високи нормални форми, които се обсъждат по-нататък в гл. 6 и 7. Трудно е да се дефинира 1NF поради неговата тривиалност. Затова нека дадем само няколко пояснения.

Обяснение 1. За една релация се казва, че е в 1NF, ако тя удовлетворява Определение 2.

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

Обяснение 2. Казва се, че една релация е в 1NF, ако нейните атрибути съдържат само скаларни (атомни) стойности.

Отново, Дефиниция 2 разчита на концепцията за домейн, а домейните се дефинират на прости типове данни.

Непървата нормална форма може да се получи, като се приеме, че атрибутите на релация могат да бъдат дефинирани върху сложни типове данни - масиви, структури или дори други релации. Лесно е да си представим таблица, в която някои клетки съдържат масиви, а други клетки съдържат масиви. дефиниран от потребителясложни структури, а в третите клетки – цели релационни таблици, които от своя страна могат да съдържат едни и същи сложни обекти. Това са възможностите, предоставени от някои съвременни пост-релационни и обектни СУБД.

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

Така възниква трето обяснение на първата нормална форма:

Обяснение 3. Една релация е в 1NF, ако е плоска таблица.

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

заключения

Релационният модел на данни се състои от три части:

• 
  Конструктивна част.
• 
  Цялата част.
• 
  Манипулационна част.

Домейни - Това са типове данни, които имат някакво значение (семантика). Домейните ограничават сравненията - неправилно е, макар и възможно, да се сравняват стойности от различни домейни.

Поведение се състои от две части - заглавка на релация И връзка на тялото . Заглавката на релацията е аналогична на заглавката на таблицата. Главата на релацията се състои от атрибути. Броят на атрибутите се нарича степен на връзка . Тялото на връзка е аналогично на тялото на таблица. Тялото на връзката се състои от кортежи . Релационният кортеж е аналогичен на ред от таблица. Броят на кортежите на една релация се нарича съотношение на мощността .

Отношението има следните свойства:

• 
  В една релация няма идентични кортежи.
• 
  Кортежите не са подредени (отгоре надолу).
• 
  Атрибутите не са подредени (отляво надясно).
• 
  Всички стойности на атрибути са атомарни.

Схема на релационна база данни data е набор от заглавки на релации, включени в базата данни.

Връзката е в Първа нормална форма (1NF ), ако съдържа само скаларни (атомни) стойности.

Което е приложение към проблеми с обработката на данни на такива клонове на математиката като теория на множествата и логика от първи ред.

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

Релационният модел на данни включва следните компоненти:

• Структурен аспект (компонент) - данните в база данни са набор от връзки.
• Аспект (компонент) на интегритета – връзките (таблиците) отговарят на определени условия за интегритет. RMD поддържа декларативни ограничения за интегритет на ниво домейн (тип данни), ниво на релация и ниво база данни.
• Аспект (компонент) на обработка (манипулиране) - RMD поддържа оператори за манипулиране на релации (релационна алгебра, релационно смятане).

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

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

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

Същност– някакъв изолиран обект или събитие, информацията за което трябва да се съхранява в базата данни и което има определен набор от свойства - атрибути. Субектите могат да бъдат както физически (реално съществуващи) обекти, например СТУДЕНТ (атрибути – номер на дневника, фамилия, име, бащино име, специалност, номер на група и др.), така и абстрактни, например ИЗПИТ (атрибути – дисциплина, дата , Учител, Публика и др.). Обектите се разграничават между тип и екземпляр. Типът се характеризира с име и списък от свойства, докато екземплярът се характеризира със специфични стойности на свойства.

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

1) идентифициращи и описателни.Идентифициращите атрибути имат уникално значение за обекти от даден тип и са потенциални ключове. Те ви позволяват да разпознавате уникално екземпляри на обект. Избран е един от потенциалните ключове първичен ключ.Първичният ключ обикновено е кандидат ключ, който се използва за по-често достъп до екземпляри на запис. Първичният ключ трябва да включва минималния брой атрибути, необходими за идентификация. Останалите атрибути се наричат ​​описателни;

2) прости и сложни.Един прост атрибут се състои от един компонент, неговата стойност е неделима. Композитен атрибут е комбинация от няколко компонента, вероятно принадлежащи на различни видоведанни (например адрес). Решението дали да се използва съставен атрибут или да се раздели на компоненти зависи от специфичните процеси на неговото използване и може да бъде свързано с разпоредбата висока скоростработа с големи бази данни;

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

4) основни и производни.Стойността на основния атрибут е независима от другите атрибути. Стойността на производен атрибут се изчислява въз основа на стойностите на други атрибути (например възрастта на дадено лице се изчислява въз основа на неговата дата на раждане и текущата дата).

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

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

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

кортеж, съответстваща на дадена схема на релация, е набор от двойки (име на атрибут, стойност), който съдържа едно срещане на всяко име на атрибут. Аргументът стойност е валидна стойност за домейна на този атрибут.

Първичен ключ(релационен ключ, ключов атрибут)Извиква се атрибут или набор от атрибути на релация, които уникално идентифицират всеки от своите кортежи. Първичният ключ по дефиниция е уникален: една връзка не може да има два различни кортежа с еднакви стойности на първичен ключ. Атрибутите, съставляващи първичния ключ, не могат да имат стойност НУЛА.Концепция НУЛАв теорията на релационните бази данни, той е предназначен да обозначи липсата на каквато и да е стойност на атрибута. За всяка връзка може да има само един първичен ключ.

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

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

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

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

Елементи на релационния модел на данни и формата на тяхното представяне

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

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

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

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

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

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

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

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

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

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

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

• relationalTable = обект;
• оформление = атрибути = имена на полета = заглавки на колони на обекти;
• екземпляр на обект = кортеж = запис = низ на таблица;
• стойност на атрибут = клетка на обект = поле.

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

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

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

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

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

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

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

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

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

Основни правила за нормализиране на релационна единица

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

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

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

Бази данни: релационни връзки между таблици

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

• „Едно-много“. Възниква, когато един ключов запис на таблица № 1 съответства на няколко екземпляра на втория обект. Икона на ключ в единия край на начертана линия показва, че обектът е от страната „едно“; другият край на линията често е маркиран със символ за безкрайност.

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

Наличие на ключове в релационна база данни

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

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

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

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

Необходимо е да се направят връзки, за да се създаде пълноценна релационна база данни. Записът „IN-41“, подобно на „IN-72“, може да се появи повече от веднъж в знака „Деканат“ и в редки случаи фамилните, собствените и бащините имена на студентите могат да съвпадат, така че тези полета не могат да бъдат направени първичен ключ. Нека да покажем обекта "Студенти".

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