Концепцията за релационна (англ. relation) се свързва с разработките на известния американски специалист в областта на системите за бази данни, служител на IBM, д-р Е. Код (Codd EF, A Relational Model of Data for Large Shared Data Banks CACM 13: 6, юни 1970 г.), който е пионер на термина „модел на релационни данни“.

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

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

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

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

База данни, изградена с помощта на релации, се нарича релационна база данни.

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

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

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

След като предложи модел на релационни данни, E.F. Код също създаде инструмент за удобна работа с връзки - релационна алгебра. Всяка операция на тази алгебра използва една или повече таблици (релации) като свои операнди и в резултат на това произвежда нова таблица, т.е. ви позволява да "режете" или "залепите" маси.

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

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

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

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

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

Този модел ви позволява да определите:

• · Операции за съхранение и извличане на данни;
• · Ограничения, свързани с осигуряване на целостта на данните.

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

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

Основното предимство на релационните СУБД е възможността за свързване въз основа на специфични съотношения на DB файлове.

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

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

• · Поддържа релационна структура от данни;
• · Изпълнява най-малкото операции по подбор, проектиране и свързване на отношения.

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

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

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

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

Но бяха идентифицирани и недостатъците на разглеждания модел на база данни:

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

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

Фундаментални модели

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2D схема на таблица на релационна база данни

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Това предполага, че "запис" означава "екземпляр на записа", а "поле" означава "име и тип поле".

Релационна база данни

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

Всяка таблица се състои от редове от един и същи тип и има уникално име; Редовете имат фиксиран брой полета (колони) и стойности (много

Общи полета и дублиращи се групи не са разрешени). С други думи, на всяка позиция в таблицата в пресечната точка на ред и колона винаги има точно една стойност или нищо;

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

Имената се присвояват уникално на колоните на таблицата и във всяка от тях се поставят хомогенни стойности на данни (дати, фамилни имена, цели числа или парични суми);

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

до 12 часа).

Манипулиране на релационни данни

След като предложи модел на релационни данни, E.F. Код също създаде инструмент за удобна работа с връзки - релационна алгебра. Всяка операция на тази алгебра използва една или повече таблици (релации) като свои операнди и в резултат на това произвежда нова таблица, т.е. ви позволява да "режете" или "залепите" маси (фиг. 1.5).

Ориз. 1.5. Някои операции на релационна алгебра

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

Език на заявки) и QBE (Quere-By-Example). И двете са

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

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

Проектиране на релационна база данни, цели на проектиране

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

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

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

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

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

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

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

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

Нормализирането е разделяне на таблица на две или повече, които имат по-добри свойства при включване, модифициране и изтриване на данни.

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

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

Всяка нормализирана таблица автоматично се счита за таблица в първа нормална форма, съкратено като 1NF. Така че, строго погледнато, "нормализирани" и "в 1NF" означават едно и също нещо. На практика обаче терминът "нормализиран" често се използва в по-тесен смисъл.

- "напълно нормализиран", което означава, че проектът не нарушава никакви принципи на нормализиране.

Сега, в допълнение към 1NF, допълнителни нива на нормалното

мализация - втора нормална форма (2NF), трета нормална форма

(3NF) и др. По същество една маса е във 2NF, ако е в 1NF

и освен това удовлетворява някакво допълнително условие, чиято същност ще бъде разгледана по-долу. Една таблица е в 3NF, ако е в 2NF и освен това удовлетворява друго допълнително условие

и т.н.

Така всяка нормална форма е в известен смисъл по-ограничена, но и по-желана от предишната. Това се дължи на факта, че "(N + 1)-та нормална форма" няма някои от непривлекателните характеристики на "N-та нормална форма". Общият смисъл на допълнителното условие, наложено на (N + 1)-та нормална форма по отношение на N-тата нормална форма, е да елиминира тези непривлекателни характеристики.

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

рационално и двусмислено.

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

Пълна функционална зависимост. Поле B е в пълна функция

функционална зависимост от съставно поле A, ако то функционално зависи от A и не зависи функционално от никое подмножество на полето A.

Многозначна зависимост... Поле A нееднозначно дефинира поле B, което

Релационна база данни – основни понятия

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

Всъщност, в тесния смисъл на думата, базата данни е определен набор от данни, необходими за работа (действителни данни). Данните обаче са абстракция; никой никога не е виждал "само данни"; те не възникват и не съществуват сами по себе си. Данните са отражение на обекти в реалния свят. Да предположим, например, че искате да съхранявате информация за части, получени в склада. Как ще бъде показан обект от реалния свят - част - в базата данни? За да отговорите на този въпрос, трябва да знаете кои знаци или страни на частта ще бъдат уместни, необходими за работа. Сред тях може да бъде името на частта, нейното тегло, размери, цвят, дата на производство, материал, от който е направена и др. В традиционната терминология обектите от реалния свят, информация за които се съхранява в базата данни, се наричат ​​​​същности (дори ако тази дума не плаши читателя - това е общоприет термин), а действителните им знаци се наричат ​​атрибути.

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

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

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

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

Модел на релационни данни

И така, имаме представа какво се съхранява в базата данни. Сега трябва да разберете как обектите, атрибутите и връзките се съпоставят със структурите от данни. Това се определя от модела на данните.

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

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

Той е разработен от Код още през 1969-70 г. на базата на математическата теория на отношенията и се основава на система от понятия, най-важните от които са таблица, релация, ред, колона, първичен ключ, външен ключ.

Релационна база данни е тази, в която всички данни се представят на потребителя под формата на правоъгълни таблици със стойности на данни и всички операции върху базата данни се свеждат до манипулиране на таблици. Таблицата се състои от редове и колони и има име, което е уникално в базата данни. Таблицата отразява вида на обекта в реалния свят (обект) и всеки от редовете й е специфичен обект. Например, таблицата с части съдържа информация за всички части, съхранявани в склада, а нейните редове са набори от стойности на атрибути за конкретни части. Всяка колона в таблицата е колекция от стойности за конкретен атрибут на обект. Например колоната Материал е набор от стойности "Стомана", "Калай", "Цинк", "Никел" и т.н. Колоната Количество съдържа цели неотрицателни числа. Стойностите в колоната Тегло са реални числа, равни на теглото на частта в килограми.

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

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

Фигура 1. Основни понятия на базата данни.

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

Връзката на таблиците е съществен елемент от релационния модел на данни. Поддържа се от външни ключове. Помислете за пример, в който базата данни съхранява информация за обикновените служители (таблицата на служителите) и мениджърите (таблицата на мениджъра) в някаква организация ( Ориз. 2). Първичният ключ на таблицата Supervisor е колоната Номер (например номер на персонала). Колоната Фамилия не може да действа като първичен ключ, тъй като двама мениджъри с еднакви фамилни имена могат да работят в една и съща организация. Всеки служител е подчинен на един мениджър, което трябва да бъде отразено в базата данни. Таблицата на служителите съдържа колоната Номер на мениджъра, а стойностите в тази колона се избират от колоната Номер на таблицата на мениджъра (вж. Ориз. 2). Колоната Номер на надзорник е външен ключ в таблицата на служителите.

Фигура 2. Връзка между таблиците на базата данни.

Таблиците не могат да се съхраняват и обработват, ако базата данни не съдържа "данни за данни", например дескриптори за таблици, колони и т.н. Те обикновено се наричат ​​​​метаданни. Метаданните също са представени в табличен вид и се съхраняват в речник на данни.

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

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

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

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

SQL език

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

Появата и развитието на този език като средство за описване на достъпа до база данни е свързано със създаването на теорията на релационните бази данни. SQL възниква през 1970 г. като част от изследователския проект System/R в лабораторията на IBM в Санта Тереза. SQL вече е стандарт за интерфейс със системи за управление на релационни бази данни. Популярността му е толкова голяма, че разработчиците на нерелационни СУБД (например Adabas) доставят на своите системи SQL-интерфейс.

Езикът SQL има официален стандарт - ANSI / ISO. Повечето разработчици на СУБД се придържат към този стандарт, но често го разширяват, за да внедрят нови възможности за обработка на данни. Нови механизми за управление на данни, които трябва да бъдат описани в Разд.Сървър за база данни , може да се използва само чрез специални SQL изрази, които обикновено не са включени в езиковия стандарт.

SQL не е традиционен език за програмиране. На него не се пишат програми, а заявки към базата данни. Следователно SQL е декларативен език. Това означава, че може да се използва за формулиране на това, което трябва да се получи, но не може да посочи как трябва да се направи. По-специално, за разлика от процедурните езици за програмиране (C, Pascal, Ada), в SQL езика липсват такива оператори като if-then-else, for, while и т.н.

Няма да навлизаме в подробности за синтаксиса на езика. Нека се докоснем до него само до степента, необходима за разбиране на прости примери. С тяхна помощ ще бъдат илюстрирани най-интересните механизми за обработка на данни.

SQL заявката се състои от един или повече изрази, един след друг, разделени с точка и запетая. Таблица 1 по-долу изброява най-важните оператори, които са включени в стандарта ANSI / ISO SQL.

Таблица 1. Основни оператори на езика SQL.

SQL заявките използват имена, които уникално идентифицират обектите на базата данни. По-специално, това е името на таблицата (Подробности), името на колоната (Име), както и имената на други обекти в базата данни, които принадлежат към допълнителни типове (например имената на процедури и правила) , което ще бъде обсъдено в Разд.Сървър за база данни ... В допълнение към простите имена се използват и сложни имена – например, квалифицираното име на колона определя името на колоната и името на таблицата, към която принадлежи (Part.Weight). За простота в примерите имената ще бъдат написани на руски, въпреки че на практика това не се препоръчва.

Всяка колона във всяка таблица съхранява данни от определен тип. Има основни типове данни - низове от знаци с фиксирана дължина, цели числа и реални числа и допълнителни типове данни - низове от знаци с променлива дължина, валутни единици, дата и час, логически данни (две стойности - "TRUE" и " НЕВЕРНО"). В SQL можете да използвате числови, низови, символни и константи за дата и време.

Нека разгледаме няколко примера.

Заявката "определяне на броя на наличните части за всички видове части" се изпълнява по следния начин:

ИЗБЕРЕТЕ Име, Количество

ОТ Част;

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

Запитването "кои части, изработени от стомана са на склад?", формулирано в SQL, изглежда така:

ОТ част

WHERE Материал = "Стомана";

Резултатът от тази заявка също ще бъде таблица, съдържаща само онези редове от таблицата източник, които имат стойността "Стомана" в колоната Материал. Тази заявка ви позволява да получите хоризонтална проекция на таблицата с части (звездичка в израза SELECT означава, че избирате всички колони от таблицата).

Искането „за определяне на наименованието и количеството на части в склада, които са изработени от пластмаса и тежат по-малко от пет килограма“ ще бъде написано, както следва:

ИЗБЕРЕТЕ Име, Количество

ОТ част

КЪДЕ Материал = "Пластмаса"

И Тегло< 5;

Резултатът от заявката е таблица от две колони - Име, Количество, която съдържа името и броя на пластмасовите части с тегло под 5 кг. Всъщност операцията по избор е операцията за формиране първо на хоризонтална проекция (намерете всички редове на таблицата с детайли, за които Материал = "Пластмаса" и Тегло< 5), а затем вертикальной проекции (извлечь Название и Количество из выбранных ранее строк).

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

Да приемем, че е формулирана заявка към базата данни Warehouse:

ИЗБЕРЕТЕ Име Количество, материал

ОТ част

WHERE Номер = "T145-A8";

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

Ако преди това е бил създаден индекс в колоната Част номер на таблицата, тогава времето за търсене в таблицата ще бъде намалено до минимум. Индексът ще съдържа стойности от колоната Номер и връзка към реда с тази стойност в таблицата Част. Когато изпълнява заявка, СУБД първо ще намери стойността "T145-A8" в индекса (и ще го направи бързо, тъй като индексът е подреден и редовете му са малки), а след това, чрез препратка в индекса, ще определете физическото местоположение на необходимия ред.

Индексът се създава с оператора SQL CREATE INDEX. В този пример операторът

СЪЗДАЙТЕ УНИКАЛЕН ИНДЕКС Индекс на част

ON част (номер);

ще създаде индекс с име Part Index в колоната Номер на таблицата с части.

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

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

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

За да завършим нашата дискусия за SQL езика, нека подчертаем още веднъж, че това е език за заявки. Невъзможно е да се напише някаква сложна приложна програма върху нея, която работи с база данни. За тази цел съвременните СУБД използват езика от четвърто поколение (Forth Generation Language - 4GL), който има както основните възможности на процедурните езици от трето поколение (3GL), като C, Pascal, Ada, така и възможността за вграждане SQL изрази в текста на програмата, както и контролите на потребителския интерфейс (менюта, формуляри, въвеждане от потребителя и т.н.). Днес 4GL е един от де факто стандартите за инструменти за разработка на приложения за бази данни.

Функции на СУБД.

Функциите на СУБД са от високо и ниско ниво.

Функции на високо ниво:

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

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

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

Функции на ниско ниво:

1. Управление на данни във външна памет;

2. Управление на RAM буфери;

3. Управление на транзакции;

4. Въвеждане на дневник на промените в базата данни;

5. Осигуряване на целостта и сигурността на базата данни.

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

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

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

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

Класификация на СУБД.

СУБД могат да бъдат класифицирани:

1. По видове програми:

а. Сървъри за бази данни (например MS SQL Server, InterBase (Borland)) - предназначени за организиране на центрове за данни в компютърни мрежи и изпълнение на функции за управление на база данни, поискани от клиентски програми, използващи SQL изрази (т.е. програми, които отговарят на заявки);

б. DB клиенти - програми, които изискват данни. PFSDBMS, електронни таблици, текстови процесори, програми за електронна поща могат да се използват като клиентски програми;

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

2. Според модела на данните на СУБД (както и на БД):

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

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

° С. релационни - чиито данни са разположени в таблици, между които има определени връзки;

д. Обектно ориентиран - съхраняват данни под формата на обекти и основното предимство при работа с тях е, че можете да приложите обектно-ориентиран подход към тях;

д. Хибрид, т.е. обектно - релационен - комбинират възможностите на релационни и обектно-ориентирани бази данни. Пример за такава база данни е Oracle (преди това беше релационна).

3. В зависимост от местоположението на отделните части на СУБД се прави разлика между:

а. местен - всички части на които са разположени на един компютър;

б. мрежа.

Мрежата включва:

- с организационен файл - сървър;

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

- с организация клиент-сървър;

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

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

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

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

Характеристики на релационните бази данни:

1. Данните се съхраняват в таблици, състоящи се от колони и редове;

2. Има една стойност в пресечната точка на всяка колона и ред;

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

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

Терминология на релационна база данни:

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

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

1. Връзка във формата 1:1 (едно към едно) означава, че всеки запис в основната таблица съответства на един запис в допълнителната таблица и, обратно, всеки запис в допълнителната таблица съответства на един запис в основната таблица.

2. Връзка тип 1: М (един към много) означава, че всеки запис в основната таблица съответства на няколко записа в допълнителната таблица и, обратно, всеки запис в допълнителната таблица съответства само на един запис в основната таблица.

3. Връзка като М: 1 (много към едно) означава, че един или повече записи в основната таблица съответстват само на един запис във вторичната таблица.

4. Връзка на формата M: M (много към много) - това е, когато няколко записа от допълнителната таблица съответстват на няколко записа от основната таблица и обратно.

5. Основните компоненти на MS Access.

Основните компоненти (обекти) на MS Access са:

1. Маси;

3. Формуляри;

4. Доклади;

5. Макроси:

модули.

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

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

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

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

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

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

6. Таблици в MS Access.

Има следните методи за създаване на таблици в MS Access:

1. Режим на маса;

2. Конструктор;

3. Съветник за таблица;

4. Внос на таблици;

5. Връзка с таблици.

V режим на маса данните се въвеждат в празна таблица. За въвеждане на данни е предвидена таблица с 30 полета. След като го запази, MS Access решава за себе си кой тип данни да присвои на всяко поле.

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

За да дефинирате поле в режима Конструктор са зададени:

1. Име на полето , който във всяка таблица трябва да има уникално име, което е комбинация от букви, цифри, интервали и специални знаци, с изключение на " .!” “ ". Максималната дължина на името е 64 знака.

2. Тип данни дефинира типа и диапазона от валидни стойности, както и количеството памет, разпределена за това поле.

Типове данни за MS Access

3. Най-важните свойства на полетата:

- Размер на полетозадава максималния размер на данните, съхранявани в полето.

- Формат на полетое формат за показване за даден тип данни и задава правилата за представяне на данни при показването им на екрана или при печат.

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

- Условие за стойностви позволява да контролирате въвеждането, задава ограничения за входните стойности, в случай на нарушаване на условията, забранява въвеждането и показва текста, определен от свойството съобщение за грешка;

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

Тип контрол- свойство, което е зададено в раздела Substitution в прозореца на дизайнера на таблици. Това свойство определя дали полето ще се показва в таблицата и в каква форма - като поле или като комбинирано поле.

Уникален (основен) ключтаблиците могат да бъдат прости или сложни с множество полета.

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

© 2015-2019 сайт
Всички права принадлежат на техните автори. Този сайт не претендира за авторство, но предоставя безплатно използване.
Дата на създаване на страницата: 2016-02-16